Terminology can be tricky. The following offers guidance about how to talk about CORD so as to confuse as few people as possible.
- CORD – In addition to being an acronym (Central Office Re-architected as a Datacenter), CORD is a purposely overloaded term. It implies a vision (building network edge facilities from cloud hardware and software technologies), an architecture (the collection of abstractions, interfaces, and data models that define a particular way to achieve that vision), and an open reference implementation (a particular implementation of the architecture, instantiated in a CORD POD).
OpenCORD – Some people use this term to refer to the open reference implementation of CORD, presumably to distinguish it from potential closed/commercial versions, but OpenCORD is redundant. CORD implies the open reference implementation. Confusingly, the website is called opencord.org, but that’s because cord.org was not available.
- CORD POD – Generally refers to a physical manifestation of the hardware/software that implements the CORD reference implementation. In some contexts, people will say “POD” when talking about just the hardware elements. (See also CORD-in-a-Box.)
CORD-in-a-Box – An alternative manifestation of the CORD reference implementation, involving the CORD software running on a single physical or virtual machine. In this case some aspects of CORD are necessarily emulated (e.g., the switching fabric and access devices), but the software is sufficiently complete to do development work on many aspects of CORD, such as adding a new service. (See also CORD POD.)
- CORD Platform – The subset of software components that are common to all configurations of CORD. Subject to change, this currently includes XOS, ONOS (including VTN and Fabric Control), OpenStack, and Docker. Technically, it is possible to configure a CORD POD that does not include the full switching fabric (in which case the Fabric Control ONOS application is not required), and similarly, there are scenarios where OpenStack can be omitted. One way to think about the CORD Platform is it is the analog of an OS kernel, with OpenStack and the Fabric Control app corresponding to kernel modules one may or may not load. In any case, since "CORD Platform" refers to the open reference implementation, and implementations change over time, being more precise about “the platform” is only so helpful. If you’re looking for something more fundamental, see Core Abstractions.
- Core Abstractions (or Models) – The data models and interfaces that define the CORD architecture, independent of any services that have been configured (on-boarded) into a particular POD. XOS it the component of CORD that codifies these abstractions, in the form of a data model. The key abstractions (models) include Services, Controllers, Slices, Networks, Instances, Tenants, Users, and Roles. Each service on-boarded into CORD extends this set of core models with a service-specific model, which a sub-class of the core Service model.
- Service Profile (or Manifest) – The set of services configured (on-boarded) into a given CORD POD.
- Lifecycle Management – CORD has three timeframes of note. The first is Service On-Boarding, which is the process of adding a service (e.g., vOLT, vSG, vRouter) to a running instance of a CORD POD. This involves extending the CORD data model with a specification for the service being on-boarded. The second is Runtime Control, which is the process of (a) provisioning the resources allocated to a collection of services, and (b) creating and controlling instances of those services (e.g., per-subscriber features). This involves REST API calls on a running system. The third is Booting or Installing CORD, which is the process of (a) bringing up a CORD POD from bare metal, and (b) on-boarding an initial Service Profile. This is designed around the DevOps principle of Continuous Integration / Continuous Delivery (CI/CD).
Domains of Use – Typically used to refer to various configurations of CORD targeted at different access technologies, market segments, or business units. Examples are Residential CORD (R-CORD), Mobile CORD (M-CORD), and Enterprise CORD (E-CORD). In practice, a domain of use corresponds more to a community than to a technical artifact. This is because each CORD POD is configured to run a particular Service Profile, which may or may not include multiple access technologies. Or said another way, Service Profiles are not necessarily disjoint based on Domains of Use.