Service Chaining - Cloud Network Services at Scale

Editor's Notes

• #2: Scaling Secure Virtual Networks Within and Across Data Centers and Clouds With OpenContrail, virtual network workloads are able to leverage automation and policy-based IP network services within and across data centers and heterogeneous cloud environments.  OpenContrail’s standards based interoperability means that virtual networks can be extended from the data center overlay to existing multi-tenant WAN environments.  This is critical to support emerging application environments required to efficiently scale simplified, interoperable and elastic cloud networks.
• #5: This is the Contrail software stack that we are going to discuss in detail in this section. As we mentioned earlier, Contrail consists of two parts: a logically centralized but physically distributed controller, and a set of vRouters that serve as software forwarding elements implemented in the hypervisors of general purpose virtualized servers. Contrail Controller provides northbound REST APIs used by applications. These APIs are used for integration with the cloud orchestration system, for example for integration with OpenStack via a neutron plug-in. The REST APIs can also be used by other applications and/or by the operator’s OSS/BSS. Finally, the REST APIs are used to implement the web-based GUI included in the Contrail System. The Contrail System provides three interfaces: a set of north-bound REST APIs that are used to talk to the Orchestration System and the Applications, southbound interfaces that are used to talk to virtual network elements (vRouters) or physical network elements (gateway routers and switches), and an east-west interface used to peer with other controllers. OpenStack and CloudStack are the supported orchestrators, standard BGP is the east-west interface, XMPP is the southbound interface for vRouters, BGP and Netconf and the southbound interfaces for gateway routers and switches. Internally, the controller consists of three main components: Configuration nodes, which are responsible for translating the high-level data model into a lower level form suitable for interacting with network elements; Control nodes, which are responsible for propagating this low level state to and from network elements and peer systems in an eventually consistent way; Analytics nodes, which are responsible for capturing real-time data from network elements, abstracting it and presenting it in a form suitable for applications to consume.
• #6: The compute node is a general-purpose x86 server that hosts VMs. Those VMs can be tenant VMs running customer applications, such as web servers, database servers, or enterprise applications, or those VMs can be host virtualized services used to create service chains. The standard configuration assumes Linux is the host OS and KVM or Xen is the hypervisor. The vRouter forwarding plane sits in the Linux Kernel, replacing the Linux Bridge or OVS module; and the vRouter Agent is the local control plane sitting in the Linux user space. Other host OSs and hypervisors such as VMware ESXi or Windows Hyper-V may also be supported in future. The vRouter functions at Layer 3 instead of Layer 2, so it has enhanced service capabilities to carry out Security Policies, NAT, Multicast, Mirroring and Load Balancing right at the server hypervisor. Each VM is mapped into one or more VRFs on the vRouter. The vRouter Agent populates the VRFs using information learnt over XMPP. The traffic that leaves the server is MPLS over GRE traffic, so only IP transport is needed to instrument these VNs. The performance numbers are very close to Linux bridge performance.
• #7: Let me walk you through how communications are happening between two VMs (VM1 and VM2) with IP addresses VN-IP1 and VN-IP2 on different physical servers but belonging to the same virtual network. We will worry about how the forwarding tables on both routers are set up but let’s assume that they are there already. 1. An application in VM1 sends an IP packet with destination IP address of VM 2a VN-IP2. 2. VM1 has a default route pointing to a 169.254.x.x link-local address in routing instance 1. 3. VM 1a sends an ARP request for that link local address. The ARP proxy in routing instance 1 responds to it. 4. VM 1a sends the IP packet to routing instance 1. 5. IP FIB on routing instance 1 contains a /32 route to each of the other VMs in the same virtual network including VM2. This route was installed by using the control node using XMPP. The next-hop of the route does the following: Imposes an MPLS label, which was allocated by vRouter 2 for routing instance 2. Imposes a GRE header with the destination IP address of Compute Node 2. 6. vRouter 1 does a lookup of the new destination IP address of the encapsulated packet (IP address of Compute Node 2) in global IP FIB 1. 7. vRouter on compute node 1 sends the encapsulated packet to Compute Node 2. How exactly this happens depends on whether the underlay network is a Layer 2 switched network or a Layer 3 routed network. For now we will skip this part and assume the encapsulated packet makes it to Compute Node 2. 8. Compute Node 2 receives the encapsulated packet and does an IP lookup in its global IP FIB. Since the outer destination IP address is local, it decapsulates the packet, i.e., it removes the GRE header which exposes the MPLS header. 9. Compute Node 2 does a lookup of the MPLS label in the global MPLS FIB 2 and finds an entry which points to routing instance 2. It decapsulates the packet, i.e., it removes the MPLS header and injects the exposed IP packet into routing instance 2a. 10. Compute Node 2 does a lookup of the exposed inner destination IP address in IP FIB 2. It finds a route that points to the virtual interface connected to VM2. 11. Compute Node 2 sends the packet to VM2.
• #8: VM’s can deploy virtualized L4-L7 network services such as firewalls, Deep Packet Inspection (DPI), HTTP header enrichment, caching, L7 load balancing, etc. The coordination with local and global control planes is designed to support the concept of service chaining. The actual services logic running on top of VM’s does not need to worry about the mechanics of chaining. Contrail supports service chaining, which allows virtual networks to be connected subject to policy constraints. A simple rule allows HTTP traffic to flow from virtual network Red to virtual network Green and forces the traffic through a service chain which consists of service svc 1 followed by service svc 2. The rules are applied to entire virtual networks, not to individual virtual machines. In the above example, the rule applies when any virtual machine in virtual network Red sends traffic to any virtual machine in virtual network Green. A service is simply a virtual machine. Contrail is only concerned with traffic steering, i.e. with injecting the traffic flows into the right virtual machines using a virtual interface. The provisioning of the services themselves is outside of the scope of Contrail. The traffic is steered: By manipulating the route targets for routes to influence importing and exporting routing from one routing instance to another routing instance. By manipulating the next-hops and/or the labels of the routes as they are leaked from routing instance to routing instance to force the traffic through the right sequence of routing instances and the right sequence of corresponding virtual machines.
• #10: Typical Services LAN are based on physical boxes delivering functions like Load Balancing, Parental Control, Deep Packet Inspection (DPI), Video optimization, Network Address Translation (NAT) and Firewall. Issues for scaling those services are based on different scaling requirements per service / hardware, which has to be always designed for a maximum capacity. If the projection is not correct it is hard to quickly react and scale a given service. In general, due to changes in the user behavior and adaptation to new trends or application usage in the Internet (IOS9 as example last week crashed the Apple service), it is hard to dynamically adjust the resources on the Service Provider site. So today Service Providers have to deploy each service for the expected peak utilization. This is clearly a problem that can be addressed with a flexible service offering leveraging the Contrail’s services chaining and SCG to enable Service Providers to transition from a physical to more virtualized service components.
• #11: the Juniper Service Control Gateway (SCG), based on the Juniper MX-3D platform, acts as a subscriber- and application-aware edge node integrated with an existing wireline or mobile edge that enables implementation of per-subscriber control of services through policy actions. The enhanced Traffic Detection Function (TDF) provides per subscriber policy and charging control at the application level by using L3-4 policies or up to layer 7 through Deep Packet Inspection (DPI) signatures. It performs policy controlled steering of subscriber/application flows into service chains that concatenate a set of Value Added Services (VAS) resources, deployed on physical or virtualized resources. Virtualized resources could be managed by the Juniper Contrail SDN Controller, which automates the provisioning and establishment of the Service chain (which is implemented by creating an overlay MPLS/GRE tunnel between the Service chain attachment points (the SCG)).
• #12: An MX acting as a Services Control Gateway requires a dedicated JUNOS version, running on an MX-240, 480 or 960. In addition you must have at least one service card. On the service card you host two functions. At least one service PIC and one session PIC need to be configured.   A session PIC supports access subscriber session setup and management, enabling the steering of subscriber traffic to the correct services PIC. The session PIC also sets up a session with the policy and charging rules function (PCRF) so it can receive subscriber PCC rules from the PCRF and send application-start messages to the PCRF.   A service PIC provides subscriber-aware policy enforcement and traffic steering that is application-aware. Traffic steering refers to the capability to direct or traverse traffic from a specified source to an endpoint or the adjacent network element in a routing path. The service PIC is configured with software plugins to perform the configured or requested services, which include the policy and charging enforcement function (PCEF), application detection and control, HTTP header enrichment, HTTP redirect, and network address translation. There are multiple types of service chains – Open and Close, where you may see specific requirements for supporting Asymmetric or Symmetric traffic across a single or multiple service hop chain.
• #13: Open service chain starts wide open to remote service complex and is not closed by the subscribers interface in order to take a decision how to send the packet. So, only single service chain will be used to steer upstream traffic to virtual service complex. In open type service chain, NAT can be used to steer return traffic to service complex back again to develop symmetric path. Using NAT is very simple and easy way to solve a symmetric path issue, as return traffic’s destination address will be part of NAT pool prefix. This means you do have a simple routing look up decision in the core network and you will forward return traffic back to NAT service. Closed service chain type contains all service chain complex under MX GW control (more specifically the subscriber interface) here – traffic steering, service chain start/end – there is no major external impact on the access and core facing network at all. Compared to open service chain, NAT does not need to be applied on last leaf node of service chain path as the MX GW can provide symmetric path without using NAT.
• #15: The current setup on most of the with business customers is based on multiple devices providing different functionality such as switching, firewalling, deep packet inspection, WAN optimization, etc. on the customer premises. This assumes that each and every device has specific capacity which shall cover maximum capacity without any possibility to upgrade without HW replacement. Deploying new services (for example proxy or content filtering) requires new device, down-time, re-configuring the devices etc. and the whole process from ordering the service until deploying it on site may take months. On another hand the Cloud CPE allows to replace the complex layer 3 CPEs on site by simple layer 2 or L3 CPEs. The CPE functions are moved to the data center on the MX (or external x86 appliances), which is acting as a provider edge in the service provider network. The network consists of MXs providing L3 connectivity to CPEs at customer sites and providing Internet and VPN access. The Cloud CPE context for each customer site is implemented by a routing instance to provide separate routing, DHCP, SNMP, and other services.L3 Services like IPSec, NAT for Internet access, and stateful firewalls are implemented by either on the services cards or VM’s running on top of hypervisor. The management and provisioning solution is based on Junos Space. Network Activate can optionally be used to provision the network, create end customers, and associate L3 VPN services with customers. Service templates providing Cloud CPE specific functions (for example routing protocols, DHCP servers or relay, and NAT services) can be attached to Network Activate services for provisioning of Cloud CPE functionality when L3 VPNs are deployed.
• #16: Walk through the provisioning flow to describe Contrail/Openstack configuration step. Tearing down the service works in the opposite direction and the monitoring is seen on a per Service instance.