I understand the general idea of CORD, but what is it exactly?
CORD — besides being a catchy acronym — is simultaneously a vision, an architecture, and a reference implementation. The vision goes beyond the obvious buzzwords, and includes a collection of requirements that guide CORD's design. If you are looking for something tangible, today that would be the reference implementation. It's a specific set of hardware and software components, and a recipe for integrating those components into a coherent system. There is also a first draft of a CORD architecture, complete with data models and APIs. Given more time and experience integrating additional access technologies and services into CORD, we expect the architecture to evolve and for the reference implementation to include a broader set of options. Read about the CORD ecosystem for more guidance about how to talk about CORD.
What's the relationship between CORD and ONOS?
CORD started as an ONOS use case, but has now been spun off into an independent open source project. The CORD reference implementation uses ONOS as its network operating system, but like the rest of the reference implementation, this is a technology choice necessary to build a complete system; alternative network operating systems can be integrated into the CORD architecture in the future. It is also the case that CORD — as a service delivery platform — currently includes many ONOS-based services. For this reason, ONOS and CORD will likely continue to be two very synergistic open source projects.
What is the relationship between CORD and XOS?
At a technical level, XOS brings the Everything-as-a-Service organizing principle to the CORD architecture. In doing so, it addresses several of CORD's high-level design requirements, including a means to seamlessly integrate control plane (SDN) and data plane (NFV) based services; the ability to support both access services and conventional cloud services; support for multiple security domains; and the "end-to-end glue" needed to make CORD both extensible and controllable. At a project level, while XOS is a self-contained component of CORD (just like ONOS), it is not an independent open source project — it is managed under CORD's project governance.
Are ONOS and XOS mandatory parts of CORD?
No. They are technology choices made for the initial reference implementation of CORD, but will not necessarily be the only options in future releases. The only "fixed point" for CORD is its architecture, and even that will evolve over time as the community gains experience with a wider array of services and access technologies.
What's the relationship between CORD and OPNFV and the ETSI NFV Architecture?
CORD's roots go back to the initial NFV Proof-of-Concept (the one that coined the term "Network functions Virtualization" in the first place), but CORD has evolved mostly parallel to the ETSI architecture and the OPNFV initiative. With respect to the ETSI architecture, it is possible to describe CORD in terms of the ETSI reference framework (which is one of the main values of the ETSI framework). With respect to OPNFV, today there is no formal relationship between the two efforts, but we view CORD as a candidate OPNFV project, one that pushes the boundaries of exploiting merchant silicon and white-box switches. It is also the case that CORD takes a somewhat broader perspective than OPNFV — one that tries to seamlessly support both NFV-based and SDN-based services, both access services and conventional cloud services, and both legacy bundled services and disaggregated greenfield services.
Can I adopt bits-and-pieces of CORD without using the whole thing?
Yes. CORD is an open source project and anyone is free to incorporate any or all of its components into their open source or proprietary solutions. But part of the value of CORD is that it is a fully integrated system, complete enough to support field trials. An important part of this "completeness" is CORD's Northbound Interface, which plumbs all the features (elements) inside CORD through to any OSS/BSS that an operator might layer on top of CORD. This completeness, in turn, means all the separable sub-pieces are themselves complete – built for deployment rather just a short-lived Proof-of-Concept. So deconstructing CORD for the purpose of integrating its individual elements into a particular deployment scenario is great, but contributing to CORD means adding value to this complete and fully integrated solution.
How are R-CORD, M-CORD, and E-CORD related to plain old CORD?
CORD is a general-purpose platform (combining elements of SDN, NFV, Cloud) that can be used to deliver everything from Access-as-a-Service to Software-as-a-Service. A given instantiation of CORD hosts a configurable set of services, which due to existing market segments and Telco/CableCo business units, tends to be tailored (today) for Residential, Mobile, or Enterprise subscribers. But the CORD architecture does not require such disjoint deployments. One can imagine many services in common across those three usage domains, as well as one instantiation of CORD that includes access technologies from all three domains. The most important thing to understand is that R-CORD, E-CORD, and M-CORD are not three different versions of CORD, but rather, they are three different service profiles running on the common CORD platform. Many other service profiles with less rigid boundaries are also possible.
Is there such a thing as being "CORD compliant" or "CORD certified"?
Not today, at least in any formal sense, but to the extent CORD becomes a go-to platform for evaluating or deploying edge services, we're likely to develop a set of interoperability tests that can be used to certify services and access technologies. Today, the best we can say is that some set of services are part of the official release, while others are still in an experimental/development stage (see Service Inventory).
Is CORD model-based and what (if any) role does YANG play?
A data model is at the heart of CORD's design, but it goes beyond being "model-based" to actually being structured around a particular set of model definitions. These models (and the APIs they imply) effectively define the CORD architecture. The current reference implementation implements these models in Django (rather than YANG), which has turned out to be an an effective way to prototype the CORD architecture. The reference implementation could be augmented to represent the CORD models in YANG, and in fact, a project to do this is underway. See the CORD Guide for more information.