Using PCE/SDN to Overcome MPLS WAN Shortfalls
Wide Area Network (WAN) has helped organizations to connect their remote centers and provided local area network (LAN)-like connectivity to their distributed workforce. Layer-3 multi-protocol label switching (MPLS)-based virtual private networks (VPNs) have been used predominantly to build up private WAN services for enterprises. Over time, organizations have realized that these solutions have exacted a toll in the form of limited options and scalability, complex configurations, and higher cost.
Recent innovations like path computation element (PCE) have come to rescue in situations like this. PCE has all the fundamentals of software-defined networking (SDN), which can be put together to design a WAN solution. PCE is a centralized controller with an overall view of the WAN can make much more intelligent decisions to optimize the network and the cost. The programmable PCE controller makes the configuration adaptive to any change in the network and less prone to human error. It opens the door for operators to provide innovative WAN services in a much more cost-effective way. To upgrade an existing network to PCE, the operators do not need to do a forklift upgrade. Through a software upgrade, the existing legacy network can be upgraded to PCE. This provides protection for existing investment.
MPLS-WAN: Where It Falls Short
Let us consider one of the optimization challenges in MPLS-based WAN.
Figure 1: Classical Fish Problem
MPLS works by setting dedicated tunnel (called label switch path - LSP) between ingress and egress. The order of setting the tunnel matters and it can cause severe degradation of bandwidth utilization. Referring to Figure 1, all the links have an IGP cost of 1 except the red link, which has an IGP cost of 2. At time T1, router R1 wants to send data at 5 Gbps. To do this, a 5 Gig MPLS tunnel TUN-1 (LSP-1) is set up through R1-R3-R5-R6—the green LSP in the figure. At time T2, R2 wants to send traffic to R6 at 10 Gbps. The MPLS network cannot create this tunnel (TUN-2 or LSP-2) between R2 and R6. The reason behind this is that the R5-R6 link has only 5 Gig of capacity left (the other 5 Gig is taken by LSP-1, the green tunnel) and on the alternate path R4-R6 link is a 5 Gig link only. Even though between R4-R6 link and R5-R6 link the available bandwidth in aggregate is 10 Gig, still we will not be able to establish the 10 Gig path. The order of tunnel setup is causing the problem. This is called the classical fish problem of routing.
PCE/SDN: Centralized Control is the Key
This problem can be avoided if a central controller, such as PCE, is available that has the global bandwidth utilization view of the whole network. The controller can determine that we can move the TUN-1 to R1-R3-R4-R6 path then TUN-2 can be established successfully through R2-R3-R5-R6. The second significant problem PCE can solve is establishing an optimal path for cross-domain communication.
Depending on the purpose and activities, there are various flavors of PCE. The two broad categories of PCE are “stateful” and “stateless”. Stateful PCE is further classified to “active” and “passive”. So, a network engineer has the following choices:
Stateless PCE—Upon bootup, Stateless PCE (where PCE is the central controller) doesn’t have knowledge of previously established LSPs. This severely limits PCEs capability to optimize the network resources at a global level. It only provides a mechanism to perform path computations (from ingress to egress) in response to requests from the path computational client (PCC). It is the client component that sits in the individual routers in the network.
Stateful PCE—This option has the capability to store all the existing LSPs into a database, enabling it to respond to changes to network state. Stateful PCE keeps this database synchronized with the actual network state. Having a well-synchronised central database gives stateful PCE the intelligence to compute a more optimal path when requested.
Passive Stateful PCE—On receiving a path computation request from the router (PCC), a passive stateful PCE computes an optimized path and sends the computed path information back to the requesting router (PCC). The router PCC becomes responsible for initiating path setup (for RSVP-TE LSP) and retains the control of the path. The PCE does not proactively inform the PCC about any LSP optimization that may be required resulting from a change in network topology in the future.
Active Stateful PCE—In this case, an LSP is not only computed by the PCE, it also takes the responsibility to maintain it and optimize it. For better utilization, if needed the PCE can change the path to make the traffic traverse through more optimized links. This is how it can solve the classical fish problem referred to earlier. Such a PCE can also proactively initiate an LSP setup at an ingress PCC router or it can leave it to a PCC to request an LSP initiation when required.
PCE Initiated: In this case, an Active stateful PCE initiates an LSP and maintains the responsibility of updating the LSP.
PCC Initiated: In this case, a PCC requests the PCE for setting up an LSP and after getting a path from the PCE, it may delegate the control later to the active stateful PCE.
IxNetwork: Validate SDN/PCE at Scale
We can clearly see that stateful PCE brings a lot of value for operators to run more optimized networks. Through programmability at the centralized controller level, operators can differentiate from competitors in terms of new and attractive features and services. Before deploying, a PCE controller or a PCC router needs to be validated for scalability, responsiveness to network change, and for the ability to do optimal path provisioning. To validate PCEP (the protocol used by PCE) and its operation at scale, Ixia’s IxNetwork provides a comprehensive test solution. In IxNetwork, it is extremely easy to build up a PCE topology (simple or complex) and do the testing at low, medium, and high scale. IxNetwork can help network engineers test for basic PCE operation from the ability to manage the life cycle of an LSP, to advanced PCE use cases like testing for bandwidth on demand and service optimization.
Figure 4: Complex PCE test configuration made simple in IxNetwork
IxNetwork offers PCE as well as PCC solutions for both RSVP-TE and SR (Segment Routing) types of LSPs.
As a stateful active PCE it can initiate LSPs and update LSP attributes like bandwidth, ERO, and metric on demand at a later point. It also allows users to create groups of working and protect LSPs using PPAG (path protection association group) support.
IxNetwork also allows users to run VPN services over PCE/PCC-initiated LSPs end-to-end, between an ingress and egress router, thereby validating a PCE’s path computation accuracy with real-time traffic flowing through the computed LSPs.