Enterprise CORD (E-CORD) is a CORD use-case that offers enterprise connectivity services over metro and wide area networks, using open source software and commodity hardware.
E-CORD builds on the CORD infrastructure to support enterprise customers, and allows Service Providers to offer enterprise connectivity services (L2 and L3VPN). It can go far beyond these simple connectivity services, as it includes Virtual Network Functions (VNFs) and service composition capabilities to support disruptive cloud-based enterprise services. In turn, enterprise customers can use E-CORD to rapidly create on-demand networks between any number of endpoints or company branches. These networks are dynamically configurable, implying connection attributes and SLAs can be specified and provisioned on the fly. Furthermore, enterprise customers may choose to run network functions such as firewalls, WAN accelerators, traffic analytic tools, virtual routers, etc. as on-demand services that are provisioned and maintained inside the service provider network.
The section provides a list of the basic terms used in E-CORD
A typical E-CORD deployment is made of one orchestrator “global node” and multiple (min 2) CORD sites (PODs), connected to the same transport network.
Each site is a “typical” CORD POD comprised of one or more compute nodes, and one or more fabric switches (see here for details). The transport network provides connectivity between the CORD sites. It can be anything from a converged packet-optical network, to a single packet switch. The transport network can be composed of white-box switches, legacy equipment, or a mix of both. The minimum requirement in order to deploy E-CORD is to provide Layer 2 connectivity between the PODs, specifically between the leaf fabric switches, facing the upstream/metro network of the COs.
INFO Usually, for lab trials, the leaf switches of the two sites (PODs) are connected directly through a cable, or through a legacy L2 switch.
The global node is responsible for orchestrating users’ requests and to manage the connectivity and the services provisioning.
It runs only an instance of the orchestrator, XOS, and an instance of ONOS, in specific the ONOS_CORD one.
The ONOS instance (ONOS_CORD) manages the end-to-end traffic forwarding between the sites.
The global ONOS is composed of three modules:
Local sites are responsible for collecting users’ traffic and forward it either to other local sites or to Internet. Each local site comes with two ONOS controllers that are part of the reference architecture of CORD: ONOS_CORD and ONOS_Fabric.
The Carrier Ethernet application of E-CORD uses both controllers to provision the physical network:
The added components to ONOS_CORD ONOS are these applications:
The added components to ONOS_Fabric ONOS are these applications:
The CE-API, the bigswitch service and the HTTP channel are common to both ONOS_CORD and ONOS_Fabric. They are used to put in communication the ONOS running on the global node and the ones running on the local sites. The local sites abstract their network topology and expose it to the global node, they receive requests from the global ONOS, and provision the network for the EVCs setup.
XOS is the default CORD orchestrator. More info about it can be found here.
The Global pod only implements a single service called vNaaS, virtual Network as a Service that is responsible for orchestrating the end to end connectivity between the PODs.
E-CORD local sites implement multiple services -wired together- that control the underlying hardware and software, and are thus able to connect the Enterprise Subscriber from the edge of the Central Office to the upstream network.
A representation of the default E-CORD local site service chain is shown in the picture below.
The local chain comprises of 5 different services with different responsibilities each.
The global node maintains an abstract view of the underlying topology for the sake of scalability and to separate domain-specific and domain-agnostic concerns. Note that in a single CORD PODs there are two independent ONOS controllers: ONOS_CORD and ONOS_Fabric. For each local site, the E-CORD application exposes two abstract devices to the global node: one is exposed by the ONOS_CORD and the other by the ONOS_Fabric. They represent an aggregation of the real network elements that compose the topology of a local site.
The picture below shows how the two topologies get abstracted and exposed to the ONOS instance running on the global node.
This way, the global ONOS has fewer devices and link data structures to deal with. Path computation will involve only these aggregated items, while the actual network provisioning will be achieved by the local site controllers.
The relevant topology information for the global node include
The NNI ports are annotated with an interlinkId so that the global node can understand which ports are at the ends of which inter-domain links. An inter-domain link, from now on simply called interlink, is a link that connects to devices controlled by different ONOS controllers at local level (see the ONOS_FABRIC and ONOS_CORD json configuration sections in the installation guide for more examples).