Most of those who follow topics in SDN and NFV will recognize the ONOS or Open Network Operating System project. It’s been covered regularly in the media, but much of the coverage seems to present it as a kind of alternative OPNFV. It’s true that ONOS and OPNFV, as projects, could be considered to have overlapping goals, but if you look at the two side by side, you see profound differences. Those differences may be critical to the evolution of next-gen network technologies—both SDN and NFV.
ONOS, as the name suggests, is an operating system, a hardened version of Linux with middleware added but designed with the goal of standardizing white-box software switching. In this respect it is very similar to OPNFV, which has started (at the bottom or infrastructure level) with its own OS approach. Where the difference lies isn’t in these OSs, but in the framework in which they’re evolving.
OPNFV is in many ways an explicit satellite of the ETSI NFV efforts, and ONOS is aimed at a broader mission. To quote their website: “The Open Network Operating System (ONOS) is bringing the promise of software defined networking (SDN) to service providers.” The details make it clear that ONOS generalizes the term “SDN” to mean all software-based virtualization of networking. If you want to understand the value of ONOS, you need to skip the low-level OS details and look at two projects within the group, CORD and XOS.
CORD stands for “Central Office Rearchitected as a Data Center”. That’s important because operators build central offices and because CORD is really a higher-level goal and not just a technology, like SDN or NFV. The details are doubly important because, as the CORD presentation points out, “CORD=SDN+NFV+Cloud”, which means that CORD unites the technology revolutions of our time. It’s never been possible for operators to visualize a next-gen network as the somehow-combination of three revolutions; CORD makes it one revolution.
Hardware-wise, CORD is a set of server resources combined with white-box switches, connecting to GPON on the access side and ROADM on the trunk side. The “virtual functions” of CORD include NFV’s VNFs but also white-box virtual-features created through central control of forwarding. OpenStack is presumed to deploy VNFs and ONOS (from which the name of the body is taken) is the switch operating system.
Toward the customer CORD establishes Access-as-a-Service (ACCaaS) through a series of subscriber VLANs under central access control that creates virtual line terminations (vOLT). Virtual Ethernet connections are provided, but switching is not directly virtualized but rather is a service of the central white-box SDN array. CPE is logically a part of the access side, of course, but “CPE” here means the real and necessary service termination; vCPE functions would be hosted in the server farm of CORD.
This structure, as I’ve noted, is designed around a GPON access network, but it would be applicable to cable and even DSL technology as well; the key point is that access is a collective service of a communal infrastructure under central control. Similarly, the trunk side is presumed to be ROADM but in theory is abstracted as a BNG (broadband network gateway) and so could represent any suitable technology.
What sits on top of both OpenStack and ONOS is XOS, which stands for, apparently, “anything-as-a-service operating system”. XOS can be visualized as a manager or orchestrator, but first and foremost it’s an abstraction of SDN, NFV, and the cloud. XOS is to services what CORD is to infrastructure, so the two combine to create the “network” of the future. Services are the highest level of abstraction, and are made up of multiple Slices, each of which is a set (zero to some number) of VMs hosted in CORD and VNs (virtual networks) which are part of the SDN fabric of CORD. VMs are committed through OpenStack and VNs through a Neutron-like interface to ONOS.
Services are hierarchical, meaning that a retail service has Tenant Services, and this lets you model complex service structures made up of several high-level components (that the TMF would call “Customer-Facing Services or CFSs). XOS manages the data plane connections needed to stitch Tenant Services together, but also the control/management connections. Each Service is represented by a Service Controller through which its functionality can be accessed. XOS takes its approach from UNIX/LINUX, meaning it’s very software-centric; a nice touch given that all this stuff is software.
Another very interesting feature of XOS is the “view” concept, which roughly corresponds to what I’ve called “derived operations”. Services expose management views appropriate to the community, which means that cloud services are managed like EC2 and a service operator has roughly what a customer service rep or NOC agent would have.
Unlike CORD, which defines a single CO and thus a single site, XOS has the ability to define, deploy, and manage services that span multiple locations and (at least in theory) multiple jurisdictions. CORD services are logically “above” XOS and thus also spread across sites. Since hosted functions and virtual network services are tenants of XOS, XOS can also unify and combine both SDN and NFV across the same scope.
The relationship between XOS and NFV is described in the XOS paper in what I think is a limiting and apologetic way. They show XOS as being equivalent to the VNF Manager (VNFM) and running “under” MANO. I think that XOS could easily supplant both VNFM and MANO and that would make more sense, since XOS would give NFV that scope of service across sites (and maybe networks) that it needs.
For all the gains ONOS has secured from its approach, it still has challenges to face. It doesn’t have the broad vendor support that the NFV ISG has, though that can be a benefit as well as a challenge. The programmatic approach it takes is hard to relate to non-programmers and the documents available don’t rise to the challenge. Finally, there is an implicit reliance on OpenStack that could be a problem for operators looking for a different cloud strategy or who want to move networking forward faster or in a different direction than OpenStack Neutron will take it.
The last of these items is the most critical. You can see in the base services defined for CORD that ONOS is highly public-Internet-centric. There’s no model for private Ethernet services or clear provision to expand the base of services. Part of this may be due to the fact that Neutron is highly IP-Internet centric, or it may be that Neutron and Internet-centricity are inherited from a common bias. Offsetting this is the fact that some very important operators, including Verizon, seem committed to ONOS.
There’s no reason why ONOS, ONF, the ETSI NFV ISG, and OPNFV couldn’t cooperate and harmonize. The recent modeling session hosted at CableLabs may be an indication that ETSI at least is trying to make that happen. The risk I see is that ONOS could be dragged into the morass of standardization, with all the delays and vendor-centric accommodations. If that happens then ONOS might lose its advantage, to the disadvantage of the SDN and NFV markets.