If I try to sell you a shiny new tool by telling you all the accessories you can buy and all the little construction functions that they can perform, you'd probably ask "But what can I build with it?" SDN and NFV standards groups and the OPNFV open source project are focusing on perfecting technology tools, not on how those tools reshape infrastructure. That's where ONOS and its derivative CORD and XOS initiatives are different, and why the ONOS initiative may end up as the real driver of NFV.
CORD stands for "Central Office Rearchitected as a Datacenter," and it focuses directly on what a CO would look like after an SDN/NFV transformation. If NFV is going to have major impact, it has to target the COs simply because COs are the most numerous (about ten thousand in the US alone) concentrations of network equipment. Operators are already jumping on the CORD bandwagon; the two largest US carriers have both announced their support and CORD has followers in every major market for network services.
Functionally, CORD is a set of servers connected to each other through a fabric that is presumed to be built by white-box switches that run ONOS , which was developed by ON.Lab . This fabric provides three critical "as-a-service" elements. Access-as-a-Service (ACCaaS) represents each user termination (made in CORD through an optical line terminal) as a virtual connection (vOLT). Subscribers are represented by a Container agent process, (Subscriber-as-a-Service or SUBaaS) and network connectivity as Internet-as-a-Service or INTaaS. The physical connection to broadband networks are made through a virtual broadband gateway (vBNG).
All of this "as-a-service" stuff shows that CORD can be extended to define new virtual things, including users, services and devices. That capability means that you could represent something such as mobile broadband's Enhanced Packet Core (EPC) as "EPCaaS" in CORD, which some operators are already looking to do. You could also define vCPE services, various IP and Ethernet private-network services, and even IoT services. The model lets operators extend the services of the CO in any useful way, both higher-than-IP stuff like EPC or even new forwarding services beyond the Ethernet and IP of today.
There's a lot operators like here. CORD is a model of what the CO of the future would look like, so it offers operators something specific to which they can build. The CORD model also unites SDN and NFV by providing a means of driving connectivity (through the ONOS fabric) and deployment of virtual elements (through OpenStack). Another initiative of ONOS unites these two pieces into a common orchestration model that eventually controls how those virtual services actually deploy. The orchestration element is called XOS, which seems to stand for X-Orchestration Services where "X" is just about anything you'd want to orchestrate.
XOS combines the hosted-feature elements of a service that would be deployed by NFV or as cloud components, and the connectivity elements the CORD fabric offers. CORD as-a-service abstractions (ACCaaS, SUBaaS, INTaaS and collective user services like CDN) are all mapped to model representations in XOS. The XOS models describe how specific elements of these "aaS" features are implemented using OpenStack or SDN (or legacy service components). XOS also exposes explicit management views, so unlike the current definition of SDN or NFV it has an explicit way not only to represent service/network/cloud management but a facility to show how all the stakeholders in a service (within the operator or customer) would manage the service and its resources.
The ONOS material illustrates a relationship with NFV's specification in their material, but it is in my view more limited than it would have to be. XOS is shown as being responsible for the lifecycle management processes NFV assigns to the VNF Manager (VNFM), but it seems to me that XOS would be perfectly capable of handling everything that MANO -- the management and network orchestration part of NFV -- handles (the NFV Orchestrator and VNFM). If you drew NFV using this expanded XOS mission, then function deployment and connectivity -- which in NFV are the responsibility of one or more Virtual Infrastructure Managers (VIMs) -- would now be directly connected to XOS orchestration and all of MANO would be subsumed into XOS.
Operators already modeling their own next-generation network deployments based on ONOS, CORD and XOS tell me that they like this model because it reflects the outcome of the transformation they're undertaking, not just a bunch of seemingly loosely related technologies. The ONOS/CORD/XOS architecture also starts with models that look a lot like programming elements, which means that the ONOS/CORD/XOS combination is software-like, which is nice if you are defining things with software.
Since SDN and NFV are also about virtualization, it's fair to ask how the ONOS approach moves the ball. After all, you can build networks with SDN and deploy functions with NFV. The difference is that ONOS, CORD and XOS are top-down-driven visions of the network of the future. CORD, for example, starts with the notion of a rearchitected data center and then defines how that rearchitecting happens. The top of the network of the future is where benefits -- to both customers and operators -- have to be connected. By starting there, and by making a place for SDN and NFV, ONOS/CORD/XOS may be our best hope for deploying the New IP.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP