I worked on the design and implementation of AT&T IP VPN services for several years. AT&T was the first Service Provider which introduced MPLS/BGP VPN technology in its WAN network in 1999. MPLS/BGP VPN technology (RFC 4364) has proven to be able to scale to a large number of VPNs (tens of thousands) and customer routes (millions) while providing for aggregated management capability. MPLS/BGP VPNs provide secure connectivity between sites across wide-area network. This is a direct alternative to Internet-based IP tunneling VPNs which suffer from security concerns and lack of performance guarantees. MPLS/BGP VPN access can provide additional capabilities compared with public Internet access, such as QoS, OAM, multicast service, VoIP service, video conferencing, and secure wireless access.
Currently, Service Providers offer MPLS/BGP VPN service to ten of thousands of enterprises and institutions.
MPLS-based VPNs are very scalable and simple to implement. They do not require IP access lists to form closed user groups or point-to-point tunnels. The same technology can be used for both intranets and extranets. The only requirement for implementing an intranet or extranet is that the addressing plan within the VPN be consistent, i.e., there is no duplication of host addresses within the VPN.
In traditional WAN deployments of MPLS/BGP VPNs, a Customer Edge (CE) is a physical router, which is a routing peer of a Provider Edge (PE), which is also a physical router, that is attached via an attachment circuit. With the onset of virtualization and cloud computing, Service Providers wanted to offer a Virtual Private Cloud service. A Virtual Private Cloud is a secure collection of compute, storage, and network resources that is seamlessly and securely connected to one or more enterprise sites. What this meant is that MPLS/BGP VPN technology needed to be able to evolve and adapt to new virtualized environments by extending the VPN service to x86 servers.
This is what Juniper Contrail as an SDN system provides. With Contrail software, Service Providers are able to tie their server-based offerings to their MPLS/BGP VPN services and provide secure and latency-optimized remote connectivity to the virtualized resources in SP’s data center. MPLS/BGP VPN customers are able to have simultaneous and uniform access to resources in both SP and their own data centers.
With the Juniper Contrail solution, the benefits to enterprise customers are isolation of their compute and network resources end-to-end, simplification of deployment since the cloud resource appears the same as a local resource, direct routing, end-to-end QOS, reliability and security for user access. Service Providers are able to “spin up” the L3VPN access to data center VPNs as dynamically as they spin up compute and other virtualized resources. This is achieved by an integrated control plane and unified orchestration of network and virtualized server resources.
Network Functions Virtualization
The ingenuity of the Contrail solution is that the same mechanism that is used for virtual network forwarding is also used for so-called service chaining of appliances. A service chain is a deployment where a sequence of appliances intermediate traffic between networks. In Contrail’s SDN approach, the service chain is configured and managed in software that adds and removes services from the chain in an automated way.
Connecting appliances in a sequence has been done for many years using VLANs. However, “service-chaining” cannot be implemented without solving the problem of how to bring in traffic from a routed network into the set of appliances. The issue is always how to attract the traffic in and forward it out of the service-chain, i.e., how to integrate the service-chain with routing. By using the same mechanism to route traffic in and out of a service chain as well as through its intermediate hops, Contrail’s implementation of service-chaining comes with integrated routing built in.
Besides the integration with routing, which is necessary, the main aspect of service-chaining is not the number of services or hops in a chain but rather how to implement a service that is conceptually one hop away but scales horizontally to tens or hundreds of virtual appliances. By using a routing instance (or VRF) construct to implement service chaining, the load balancing is the integral part of Contrail’s solution.
Contrail’s network virtualization solution is applicable to 3GPP networks where IP services offered to wireless subscribers are inherently service chains of appliances. So called Gi or SGi network interfaces in 3GPP provide IP services and connects wireless subscribers to external public or private packet networks (Internet, intranet, private and public cloud, IMS, etc).
Examples of SGi services are:
- Web proxies (HTTP header enrichment, parental control, cashing)
- TCP optimization
- Video optimization
- Intrusion Detection/Preventions Systems (IDS/IPS)
- Deep Packet Inspection (DPI)
- CGNAT
- firewall, etc.
The wireless access IP services are my current area of work at AT&T.
In the past, SGi service-chains (also called SGi IP flows) have been built of physical appliances which are complex to design and manage because of mismatched capacities, diverse resiliency strategies, and incompatible networking. It is complex to add new flows or to change the existing flows because the appliances are “hard-wired” to the chain. It is difficult or often not possible to independently scale individual services.
Wireless Service Providers are resolving those limitations by deploying service appliances as software running on virtualized server COTS hardware and using SDN-based service chaining. This is also referred to as Network Functions Virtualization.
Contrail’s solution to Network Functions Virtualization allows pushing the complexity of service chaining implementation to the re-usable portion of Contrail’s SDN system (that is, to a reusable code). This code translates (compiles) network requirements to a physical topology.
In my view, this is SDN!
