In the WAN, it’s better to be single than attached

In a traditional WAN infrastructure, the control plane and data plane are tightly coupled, typically congruent, and cannot be separated due to how they are integrated with each network device. This architecture served the networking needs of enterprises well until now, since most data flows were structured around data centers with centralized exits.

However, the emergence of cloud computing and new dynamic business requirements that involve communicating with multiple partners and suppliers have forced enterprises to embrace new connectivity models. Today, enterprises need secure access to both partners and cloud provider infrastructures. This new model requires a different policy structure that is very difficult to instantiate and maintain within a legacy MPLS WAN.

The changing nature of enterprise networks demands the ability to add network capacity on-demand, create new service offerings, and concurrently attain real-time visibility into network and application performance. These requirements are best addressed with a new model suited to these challenges, rather than retrofitting existing technology intended for other purposes.

Software defined networking’s basic premise is the separation of  control plane and data plane. In cases where data plane policy needs to be changed between two elements the configuration is only done at the central controller. In the traditional model, that uses a  congruent data and control plane, every element needs to be reconfigured if data plane polices are to be changed. This separation enables a unique set of transformative capabilities that can address both existing and new services and requirements.

Real world benefits

During my days at Cisco, I worked with a large manufacturing company that wanted to acquire WAN services from an MPLS provider. Their requirements were seemingly straightforward. Their business partners needed access to shared services in their data centers and the ability to upload files once tasks were completed. Also, VPNs were required between partners on a temporary basis. This connectivity needed to be established with the permission of the host company. Trying to address these challenges using a carrier-provided MPLS-based service did not work well for these reasons:

1. Every business partner would have to be provisioned with their own VPN, since all the business partners needed to access centralized services on a permanent basis.

2. Temporary and project-driven peer-to-peer connectivity would require the MPLS service provider to create inter-partner connectivity on their PE routers to accommodate changes. Meanwhile, all four parties would need to be involved in making changes.

Using MPLS technology, this manufacturing company decided to build its own VPN network to achieve the policy control it needed. The following complications ensued.

All remote partner VRFs needed to be imported into PE5 and PE6 routers at the central site that would provide connectivity for the shared services (Figure 1). These routers needed to be provisioned to import all partner VRFs through specific configurations. When new partners were added, specific provisions were required at these central services routers.

To block traffic between partners, access policies had to be configured within each of these central routers. These policies then required manual maintenance to accommodate adjustments in partner networks, revisions of connectivity matrixes, and other third-partner-related adds, moves, and changes.

Using SDN, which separates the data and control planes, eliminates many of these issues. In the same manufacturing example, SDN allows traditional PE-functions to be relocated to a central controller while the IP forwarding functions can be located at the hollow PE which is just an IP forwarding device. Meanwhile, the VPN related information can be distributed at the CE and central controller. Removing VPN state from the intermediate device like a PE, enables IP as a transport. This allows additional circuits to be added on demand utilizing third party MPLS, commodity Internet or LTE.

Furthermore, since the control plane is no longer attached to the data plane, the manufacturing company could use any kind of transport from any carrier. The specific carrier, location, and type of circuit no longer restricts partner connectivity. To quickly connect a new partner location, a local broadband or LTE circuit would be sufficient to get the project going. All that would be required to add new partners is provisioning a new site device and central controller. Other data plane elements would not require any configuration changes and information about other VPNs would only be presented to relevant devices.

This new transport agnostic approach can be based on a secure, ubiquitous overlay that is totally independent from the composition of the data plane. It delivers a secure control plane and data plane at scale, provides endpoint and data authentication, data confidentiality, data integrity and non-repudiation. To overcome scalability challenges the control plane used to establish data plane security relies on the central SDN controller. This eliminates the need for pairwise associations between encryption peers.

Figure 2 illustrates how SDN concepts applied to the WAN can be used by the manufacturing company to exchange large volumes of data directly with specific partners.

Instead of implementing separate MPLS VPNs (and associated policies) at each partner site, SDN uses a centrally administered policy that not only restricts connectivity but also distributes application and data traffic to where it belongs from a data plane perspective.

This allows for bulk data transfers between partners to be assigned to an Internet carrier, while other applications can be carried on top of a transport capable of supporting pre-set SLA requirements.

In the example above, the manufacturing company wanted two things: simplicity and availability. With the advent of cloud computing, a third very important element has emerged -- agility. Rapidly evolving business needs have made speed to adoption a key metric. Specifically around the ability to consume new cloud services that require little investment and can be changed as needed. This agility requires the ability to quickly modify network policies, which is most easily achieved through centralization provided by SDN.