Created by Saurav Das, last modified on Jun 28, 2016

Virtual Tenant Networks & Service Composition

Services in CORD are composed using the best practices of Cloud operations. In CORD, services are instantiated by the network operator using XOS (Figure 5). In turn XOS presents ONOS with a service graph for subscriber traffic. This graph is then decomposed into flow-rules that are programmed in the CORD networking infrastructure by the VTN application in ONOS. Details of XOS and service graphs are discussed in other design notes. This section gives a brief overview of the implementation choices made for realizing service composition in the network infrastructure.

Slide18.png

Figure 5. Service Composition.

In CORD, service composition is implemented using overlay-networks and network virtualization. At a high level,

  • Services have their own virtual networks (VNs)—the VMs or containers that instantiate the service are part of the same virtual network, and these instances can be created in any part of the CORD cloud (ie. on any compute-node in any rack).

  • It is possible to dynamically grow and shrink the number of VMs/containers (and hence the virtual network) that instantiate a service. This feature is essential for achieving scale in the cloud.

  •  Each compute node hosts VMs or containers (belonging to multiple service VNs) that are connected to OVS acting as a highly programmable OpenFlow controlled hypervisor switch.

  •  Each Virtual Network (or service) has its own Load-Balancer distributed across every OVS in the network. The load-balancers job is to select a VM instance instantiating the service, amongst all the VM’s within the service’s virtual network.

  • Service composition walkthrough: Let’s say a VM S1B, which is an instance in Service 1 VN, figures out that the next service some traffic needs to go to is Service 2. Instead of sending it directly to a VM in service 2, it sends the traffic to the load-balancer for Service 2, which then selects the VM (say S2C). It is also possible that the operator wishes that traffic goes directly from S2C specifically to VM S3A, instead of the load-balancer for Service 3.

  • XOS and ONOS’s VTN app coordinate to keep the virtual infrastructure state updated. As VMs are added/deleted for a service, and service chains are created, VTN updates tables in a special purpose OVS pipeline to reflect the desired subscriber service flow. A functional block-diagram of the OVS forwarding pipeline is shown in Figure 6.

  • Subscriber traffic is NATted by the vSG. After the vSG, subscriber traffic can directly head out to the Internet, or proceed through a series of services and then head out to the Internet. To transport subscriber traffic between services, we use VxLAN encapsulation. VxLAN tunnels are used to interconnect VMs and services. The encapsulated traffic is routed or bridged by the underlay fabric (which we describe next) using infrastructure IP/MAC address belonging to the fabric and the compute nodes. Finally, when routing out to the Internet and back, the fabric routes non-encapsulated NATted IP packets, with help from BGP routes learned by the vRouter application.

 

Figure 6. CORD OvS Pipeline.