Simplifying Private Cloud Delivery: IP VPNs and Private Cloud Connect

Private Cloud

Simplifying Private Cloud Delivery: IP VPNs and Private Cloud Connect

It’s All About IP

In the last issue of Cloud Computing magazine, we talked about Private Cloud Connect, which provides a standardized Layer 2 connection using Carrier Ethernet EVPL to connect an Enterprise to a Cloud Provider. With this basic connection in place there is another aspect that needs standardization: the IP layer. A successful model must account for the fact that while the Private Cloud service is being delivered over Carrier Ethernet at Layer 2, the cloud service transport is IP at Layer 3.  As a result, IP routes or subnets need to be coordinated between the Enterprise and the Cloud Provider. The candidate approaches for coordination of routing information include:

  • Static routes
  • RIPv2
  • OSPF
  • IS-IS
  • BGP

The preferred protocol for this is external BGP (E-BGP). The Customer Edge (CE) and the Cloud Provider’s Virtual Customer Edge (V-CE) use E-BGP to exchange routing information on a per EVC/Cloud Provider basis.

Figure1: BGP Peering

E-BGP is a standard part of Layer 3 or IPVPNs, which are widely deployed across Enterprises to interconnect branch, data center and head offices. The next figure shows a scenario where the Private Cloud Connect and IPVPN services are handled in parallel.

Figure2: Parallel IPVPN and Private Cloud Access

An extension of the parallel model is to extend reachability of the IPVPN into the Cloud Provider, as shown in Figure 3. This combination allows all sites on the IPVPN to securely access resources from the Cloud Provider. Integrating cloud services and IPVPNs is therefore a key requirement Service Providers.

Figure 3: Combined IPVPN and Private Cloud Access

The Private Cloud Connect model delivers a VLAN based handoff which aligns with option A of the IPVPN Inter-provider model. It again standardizes on the Private Cloud Connect model with an E-BGP routing overlay between the Provider Edge (PE) and the Cloud Provider’s V-CE.

What about Class of Service (COS)?

The fundamental use of CoS is to ensure that business-critical applications get prioritized over non-critical applications during times of congestion. Some Enterprises and or Cloud Providers may not need a CoS-enabled Private Cloud Connect. The public internet is a best effort network today and it works quite well as long as the appropriate bandwidth is available. However, when CoS is needed, the content owner (Enterprise/Cloud Provider) can best assess what applications should be prioritized over others. Once traffic is classified into the appropriate service classes, then the network can provide the proper treatment.

When using a CoS-enabled service, both the CE and V-CE routers must shape the traffic towards the UNI or E-NNI to adhere to the contracted service bandwidth, and mark it (802.1p) accordingly. The Service Provider will use ingress policing to enforce contracted service bandwidth, so the goal is to have the CE and V-CE intelligently drop traffic based on priority rather than have the Service Provider do it.

The goal of the Service Provider is to meet or exceed the SLA associated with the Private Cloud Connect service. When enabled, CoS can provide additional visibility and control to enhance the performance of the applications running in the cloud. The Service Provider can offer CoS-enabled EVC based either on Layer 3 DSCP or Layer 2 802.1p.

With the non-CoS aware EVC based model, all traffic within an EVC is treated the same as it traverses the Service Provider network, under the assumption that the traffic was already scheduled and shaped by the CE/V-CE router. The Service Provider may offer individual EVCs to have different aggregated CoS treatment (Low, Medium or High) that will drive different SLAs around packet delivery, delay and jitter. With this approach the Service Provider is not looking and acting on the 802.1p packet header, nor is it changing or reordering the packets as they traverse the network.

The second approach is a CoS-enabled service.  With this approach it is still recommended that the CE and V-CE router traffic shape traffic towards the UNI/E-NNI. However, the Service Provider network will classify traffic based on the 802.1p. With a CoS-enabled service, the Service Provider can differentiate traffic into service classes, police the individual service classes and provide different SLAs for each of the service classes. During times of congestion the Service Provider will intelligently drop traffic based on the service class. This approach allows for greater visibility and control of traffic across the Service Provider network. In this application standardizing on 802.1p marking/classification will reduce the overall complexity.

Another design issue for Private Cloud Connect is the alignment between the Enterprise, Service Provider and Cloud Provider around policing and traffic shaping on Layer 2 Ethernet packets (with or without VLAN headers) versus Layer 3 IP packets. In a CoS-enabled network it is extremely important to ensure that traffic is intelligently dropped. Without this alignment it is very easy to have improperly dropped traffic due to micro-bursting of application data.

The Benefits of Automation and Apps

Once the Private Cloud Connect model has been simplified and standardized, it becomes possible to apply automation to give the end user a self-service model. The next figure shows a Private Cloud Connect service that has been enhanced with a “Cloud App Store”.

Figure 4: Private Cloud Connect and Cloud App Store

The goal of is to automate the creation and modification of the Private Cloud Connect and the cloud services such that the Service Provider and Cloud Provider can deliver a simple, dynamic, flexible cloud ecosystem to the Enterprise.

As shown in Figure 4, the “Cloud App Store” provides a centralized self-service portal that can be used to gather the required service attributes. These attributes are then communicated via the appropriate standard APIs and schema to instantiate or change the end to end service across both the Service Provider and Cloud Provider.

This model also enables the possibility of cloud-based services far beyond what is available today. Options include:

  • Managed router/firewall in the Service Provider
  • Layer 3 VPN to the Cloud
  • High-performance mission critical applications

So, What Do We Do Next?

In order to achieve the goal of more efficient delivery of dynamic private cloud services, the industry must work together to change how cloud services are delivered. Some requirements:

  • Service Providers and Cloud Providers need more peering points in data centers.
  • Equipment providers must provide open APIs to support dynamic interaction between cloud and network services.
  • Everyone must work together to solve the problem of how to manage the connection to ensure quality of experience. This will require the network to have a new level of application awareness, which is a problem that hasn’t yet been solved.

If we can meet these requirements then the benefits are compelling:

  • Operators can implement valuable and dynamic services that are controllable by users.
  • Operational models are simplified, reducing costs and errors.
  • Deployments are accelerated due to automation.
  • Better network performance and SLAs are possible.

There is a lot of work to do.  However, the benefits to the users and suppliers of cloud and network services are huge.

About the Authors

Prayson Pate is the Chief Technologist at Overture Networks (News - Alert).  He has more than 25 years of experience developing communications products.  For more information, please email prayson.pate@overturenetworks.com or visit www.overturenetworks.com.

Francis Ferguson is the Director of IP/MPLS and Carrier Ethernet Architecture at tw telecom (News - Alert).  He has more than 20 years of experience in the date networking.  For more information, please email francis.ferguson@twtelecom.com or visit www.twtelecom.com.




Edited by Stefania Viscusi
blog comments powered by Disqus