The central concept of software-defined networking (SDN) – separation of the control plane from the physical network for visibility, programmability and granular control -- is not exactly new. Path Computation Element Protocol-- a 7-year-old IETF standard -- is a visibility and control protocol that works in MPLS networks, and partially removes the control plane from head-end routers to define network paths. While the Path Computation Element (PCE) architecture never quite got the publicity or support of OpenFlow, it is likely to play a role in emerging SDN architectures, especially in service provider networks.
Why the need for Path Computation Element architecture?
Computing end-to-end paths through MPLS-TE or GMPLS-TE networks can be quite complex. Traffic engineered (TE) paths provide bandwidth and QoS guarantees, such as minimal latency and jitter while avoiding high-cost links. So, locating a path that meets requirements as it passes through an active, complex network is a difficult task.
Path creation becomes even more complex when the path crosses routing domains and autonomous systems (ASes) or in a multi-layer network where part of the path may include a technology such as optical switching.
The PCE architecture, defined in RFC 4655, simplifies path computation by separating network topology determination from path creation. Both tasks have traditionally been done by the provider edge router that receives the customer path request. This router, called the "head-end router," must support an Interior Gateway Protocol (IGP) such as OSPF to determine topology within its routing domain, and must also support the Border Gateway Protocol (BGP) if paths cross AS boundaries. Adding complex path computation can overwhelm the router CPU.
OpenFlow can do everything PCE does and much more, but it requires replicating all of the logic of an MPLS-enabled router in the OpenFlow controller. Meanwhile, PCE presents an evolutionary approach.
The PCE IETF Working Group was created in 2005, and RFC 4655 was published in 2006. The initial RFC defined PCE architecture, and subsequent RFCs have filled in details. Now work is under way to add capabilities and address issues in the architecture.
Path Computation Element vs. SDN
Interest in PCE was initially limited to customers with very specific concerns, but interest has recently increased, now that the emergence of SDN has demonstrated the advantages of moving the control plane out of proprietary network components.
OpenFlow can do everything PCE does and much more, but it requires replicating all of the logic of an MPLS-enabled router in the OpenFlow controller.
Meanwhile, PCE presents an evolutionary approach. Implementing SDN requires upgrading or replacing all existing routers and switches with compliant units, while PCE requires upgrading only head-end routers.
Telecom service providers have found PCE especially attractive because upgrading entire MPLS networks would be extremely expensive and disruptive. The ability of PCE to incorporate optical network parameters in path computation is an additional advantage, as is the ability to create paths across routing domains and ASes.
Path Computation Element components and configurations
In a PCE-based network, the head-end router continues to support an IGP and possibly BGP, but path determination is moved to one or more PCEs. A PCE is a software component dedicated to computing paths. It may execute in a dedicated server, in a network management server, in a cloud or in a head-end router with sufficient processing resources.
Each PCE module depends on a Traffic Engineering Database (TED) for the information required to create a new path. The TED receives network topology information from routers via standard routing protocols and may also exchange information with other TEDs. A TED may be located in a server along with the PCE component, in a server separate from the PCE, or possibly in a head-end router. RFC 4655 describes multiple possible configurations:
- There is one PCE in the domain and it computes all paths.
- There are multiple PCEs in the domain, but each path is determined by a single PCE.
- Multiple PCEs combine to compute a path. One PCE receives the path request, and it then requests information from other PCEs before responding to the request.
- Where paths cross multiple domains, one or more PCEs in each domain combine to create the complete path.
- Multiple domains are combined into a single domain, and one PCE determines all paths.
- The path may contain a "loose hop," where two routers along the path are not directly connected. The router at the loose hop must find a path to the next router on the path. It may request a path from the same PCE that determined the overall path or from a different PCE.
- In a multi-AS network, a PCE architecture can be used on one AS with other ASes controlled by traditional architectures.
Path creation aided by PCE architecture
The RFC lists several cases where path creation complexity makes the PCE architecture especially valuable. These cases include:
- The need to create a set of paths that together meet a goal, such as minimizing link utilization.
- When multiple criteria must be met; for example, minimizing link utilization while also minimizing end-to-end delay.
- When there is a requirement to minimize the cost of point to multipoint networks.
Path creation begins when a customer-edge router issues a request to a provider-edge head-end router which then passes the request to a PCE. RFC 5440 specifies the protocol interchange between head-end routers and PCEs. The request contains the source and destination IP addresses and a specification of required bandwidth and QoS parameters. The PCE then computes a path and returns an Explicit Route Object (ERO) specifying each hop along the path.
The head-end router then sends the ERO along the specified path to allocate the path in each included router. The ERO format is identical to the RSVP-TE ERO format currently used by MPLS-TE-enabled routers. As a result, routers other than the head-end router do not need to be updated to support PCE.
Stateless and stateful Path Computation Elements
Stateless PCEs don't retain a record of created paths, while stateful PCEs maintain records of all currently active paths. Records of existing paths enable a stateful PCE to create paths without attempting to reallocate resources previously committed to an existing path.
More on SDN protocols and standards
Border Gateway Protocol for SDN
Guide to OpenFlow basics
Understanding OpenFlow configuration protocols
Keeping OpenDaylight open
Dell, Object Management Group and a new SDN standards body
Stateless PCEs must also avoid reallocating committed resources. The TED receives updates about available resources in each router throughout the network via the IGP. A stateless PCE uses that information when creating a path.
Retaining state offers advantages but increases complexity. A stateful PCE is notified when a path is closed. It may then determine that an existing path could be re-optimized to improve QoS or reduce cost. A stateful PCE can also insure that a backup path created for quick failover does not use any of the primary path's routers or links.
A stateful PCE's path database may grow quite large, and in a large network with rapid path creation and deletion, keeping the database up-to-date and synchronized with the TED can be difficult. Multiple PCEs add complication. PCE databases must be synchronized to maintain records of paths created by the other PCEs.
Applications such as VoIP, video and collaboration depend upon strict QoS compliance. Increasing use of these applications, along with the continuing need to minimize costs, adds incentives that seem sure to lead to widespread PCE adoption. Work is currently under way to address the difficulties presented by stateful PCEs. Given the current level of interest in PCE technology, active development of both stateless and stateful PCEs will undoubtedly continue.
About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.
This was first published in June 2013