More and more network operators and service providers are adopting Traffic Engineering and WAN SDN to optimize their IP/MPLS networks and provide better services to their customers. Following up on our introduction to Path Computation Element (PCE), here’s how SDN PCE facilitates traffic engineering and SDN in multi-domain, multi-layer carrier networks.
In MPLS Traffic Engineering (MPLS-TE) tunnels, path computation is done by the provider’s head-end (ingress) router that receives the path request from the customer. But computing constraints-based paths for different flows can also overwhelm the router’s CPU, thereby affecting overall routing performance too. Path computation becomes even more complex when it involves inter-domain and inter-AS routing and multi-layer networks. This brings in the need for a dedicated path computation server that can compute paths within large complex, meshed networks as well as across domains, irrespective of the underlying network layer.
The separation of path computation from the router can be brought about by using a PCE. PCE architecture allows for the path computation to be done on the router or on a separate server, including a network management system. The architecture also allows a PCE in one domain to communicate with PCEs in other domains to enable it to compute end-to-end paths spanning multiple domains.
By extending the concept of PCE to SDN, an SDN controller, which originally does not have the knowledge about the paths across domains, now gets the ability to compute end-to-end paths across multi-domain, multi-layer networks. Here’s how.
SDN architecture allows a software controller to manage the flow of packets from source to destination without the router having to make intelligent forwarding decisions. To determine how traffic will flow across multiple network nodes and domains, the SDN controller must have the ability to compute multiple end-to-end paths for different traffic flows, some spanning different domains, while also considering constraints such as bandwidth, QoS, and latency requirements.
Network operators, especially service providers, face a few challenges when implementing SDN in their IP/MPLS networks for traffic engineering purposes. To start with, for an SDN protocol such as OpenFlow to relay end-to-end path information to routers, the OpenFlow controller must understand the concept of MPLS forwarding and have all the logic of an MPLS router implemented in it. Another major challenge is that SDN requires all the network nodes along the path to support the SDN protocol in use. This might require replacing or upgrading all network nodes, potentially increasing expenses, downtime, and change management risks.
With a dedicated PCE server, the path is computed and sent to the head-end router to enable source routing-based forwarding of packets. Running PCE from a dedicated server also avoids over-loading the processors in head-end routers. Further, PCE provides all existing MPLS-TE functionalities without the need for deploying protocols such as RSVP-TE and the associated overhead from running additional protocols in the network. Finally, with PCE, only the head-end router needs to be upgraded to understand the path computation messages, thereby saving time and significant expenses for the provider.
Adoption of PCE with SDN also paves the way for PCEP (Path Computation Communication Protocol) to become an SDN protocol. As an SDN protocol, PCEP can be used by SDN controllers for path computation or for an SDN orchestrator to interact with other SDN controllers and provision different types of paths: end-to-end LSPs (Label Switched Paths), a segment of an LSP, or even to provide forwarding instructions to a single node.
In fact, extending the PCE components to function as an SDN central controller allows an existing network to easily evolve into an SDN enabled network with minimal changes to the current infrastructure. This concept, known as PCECC is discussed in more detail here: https://www.ietf.org/proceedings/88/slides/slides-88-pce-5.pdf
The increasing adoption of PCE in service provider networks has led to SDN controllers such as ONOS implementing PCE and PCECC in their releases to provide IP/MPLS SDN capabilities. So, if you are ready for PCE and SDN, get a quick guide on how to enable PCE tunnels in ONOS by reading this how-to blog post: PCE Tunnels with ONOS Goldeneye. Packet Design Explorer SDN Platform includes SDN Path Provisioning application that can compute paths based on customer constraints and work with SDN controllers such as OpenDayLight to provision new paths automatically. Check out our blog on Explorer SDN Path Provisioning to know more about our SDN application: http://www.packetdesign.com/blog/provisioning-new-service-paths-in-minutes-with-sdn/
And finally, if you are planning to Transform Your Network, please share with us your progress in implementing SDN and PCE in your network.