Skip to main content

Benefits of segment routing and path computation


Segment routing (SR) in combination with a Path Computation Element (PCE) is emerging as a new approach to provide scalable and granular control to IP/multiprotocol label switching (MPLS) networks. SR coupled with PCE can provide multiple benefits to network operators such as:

  • On-line traffic engineering capabilities across multi-area/multi-level networks
  • Delivery of performance-engineered paths at the service level, including characteristics such as disjointness and bi-directionality
  • New services such as bandwidth calendaring and bandwidth on demand

The challenge of scalability

Operators of IP/ MPLS networks need to optimize their existing network infrastructure, increase options available to existing services, and potentially create new service offerings. In this context, traffic engineering is vital to success. However, in striving for more granular control over traffic routes, network operators have always been stymied by scalability issues that inevitably arose from increased control plane signaling and state information that would be required in the network.

Current traffic engineering solutions based on the Resource Reservation Protocol (RSVP) only enable coarse levels of control. Attempts to apply RSVP to engineer more granular service flows have always stranded on scalability concerns. Segment routing[1] is a new tunneling protocol that can be applied in conjunction with software-defined networking (SDN) applications to solve the conundrum of achieving granular control with good scalability.

Segment routing: A recipe for scalable control

Unlike RSVP and Label Distribution Protocol (LDP), SR requires no MPLS control plane signaling and imposes no changes to the MPLS data plane. SR requires only ingress label edge routers to keep per-service state. State management requirements from the midpoint (label switch routers) and tail end (egress label edge routers) are removed. This allows SR to scale significantly better than RSVP-TE while providing most of the same functions:

  • Interior Gateway Protocol (IGP)-based MPLS tunnels for services such as VPRN or VPLS without any other transport signaling protocol
  • Fast-reroute capability using a pre-computed backup path that can provide full coverage and does not have any topology dependencies[2]
  • Ability to source route using a combination of loose and/or strict hops. Allows for centralized or distributed traffic engineering models with most of the capabilities of RSVP-TE (including admin-groups and shared risk link groups), without the associated midpoint state management requirement that causes scaling issues in larger networks.

In the SR domain, nodes and links are assigned segment identifiers (SIDs), which are advertised into the domain by each SR router using extensions to intermediate system-intermediate system/open shortest path first. These SIDs allow an ingress node to select a path through the network using either a single SID to represent the destination node or using a series of SIDs, called a segment list, which specifies a particular path through the network that an SR tunnel should traverse. As a result, is it possible to route paths that are completely independent of the IGP shortest path.

Figure 1. An SR domain represented as segments

Segment identifiers or segment lists can be encoded as one or more MPLS labels or as one or more IPv6 addresses. An SR tunnel can contain a single segment that represents the destination node or it can contain a segment list that represents the set of segments that a given tunnel must traverse.

The SR tunnel can be established over an IPv4/IPv6 MPLS infrastructure or over an IPv6 infrastructure and is encoded as:

  • A single MPLS label or an ordered list of hops represented as a stack of labels
  • A single IPv6 address or an ordered list of hops represented by a number of IPv6 addresses contained in an IPv6 extension header

When MPLS is used to instantiate SR tunnels, the MPLS forwarding plane does not change. Segment routing uses extensions to the link-state IGP to flood SIDs that include an absolute MPLS label value, or an index from which the MPLS label can be derived.

No LDP and/or RSVP control plane is required, although it is possible to run these in conjunction with SR because the LDP and RSVP label spaces do not overlap with the MPLS label space maintained by SR (this is known as the SR global block).

Role of a Path Computation Element

While SR does support distributed traffic engineering, options to optimize and assure established label-switched paths (LSPs) are very limited due to the lack of state information on implemented routes. A PCE[3] addresses this issue by maintaining network wide SR topology and per-LSP state in a centralized traffic engineering database (TED).

SR coupled with a PCE can provide multiple benefits to network operators:

  • Optimize LSP placement across multi-area/multi-level networks. Without PCE, the head-end router calculating the path cannot see the end-to-end topology.
  • Effectively utilize expensive network capacity by monitoring network utilization and optimizing LSPs where appropriate.
  • Enable delivery of performance-engineered paths at the service level, including constraints such as disjointness and bi-directionality.
  • Enable a more agile WAN-based SDN architecture in which intelligence in an SDN controller such as the Alcatel-Lucent Network Services Platform determines where and when to establish paths. This agility and flexibility enables new services such as bandwidth calendaring and bandwidth on demand.

A PCE server can be stateful or stateless. A stateful PCE server has strict synchronization between the PCE and the network state using the TED and maintains state on the set of active paths and their reserved resources in the network.

A stateless PCE server computes paths based on the TED but processes each path independently and does not need to remember any previously computed paths. Because it has no view of current active LSP state, it is impossible for a stateless PCE server to re-optimize active paths. Use of a stateful PCE server increases the likelihood of an optimal path computation but requires a reliable synchronization mechanism between itself and the network.

Figure 2: Functional blocks of a stateful Path Computation Element server

A stateful PCE server performs the following functions (Figure 2):

  • Discovers the network topology and resources by listening to IGP/TE-resource updates through a route-listener[4] or through some other means such as BGP Link-State (BGP-LS).
  • Collects link statistics using, for example, IPFIX, SNMP or XML-based accounting.
  • Accepts requests from network elements or management systems for computing paths using the Path Computation Element Protocol (PCEP).
  • May communicate with PCEs in other domains/areas and/or layers for path computation. Multiple PCE servers can manage a single multi-domain/multi-area network or there can be PCE servers at both the optical and IP layers that communicate with each other to ensure that an optimal path is selected that meets the requirements of both layers.
  • Monitors network state, measuring such things as real-time (or near real-time) traffic demand and LSP statistics, and re-optimizes path placement based on that knowledge.
  • Supports both RSVP and SR LSP types.

A router or network element that must communicate with a PCE server to request a path computation is called a path computation client (PCC). The PCEP [5] is used to establish this interface. After a PCEP session has been established, establishing and/or updating an LSP can be PCC-initiated or PCE-initiated dependent on mutual consent and exchange of the relevant parameters and capabilities between the peers.

PCC-initiated provisioning is well-suited when LSP placement is reasonably static. The PCE-initiated process fosters an agile WAN-based SDN architecture in which intelligence in the SDN controller can determine when and where to establish paths. A new path can be established with certain constraints between 2 endpoints and subsequent teardown when it is no longer required. Or an existing path can be dynamically adjusted, such as for bandwidth calendaring services.

Using only the stateful extensions to PCE[6], the process of path setup and teardown is always controlled by the PCC. However, the process of path maintenance and control of a given LSP differs depending on whether the PCE server is acting as an active stateful PCE or a passive stateful PCE for this LSP. The active/passive PCE server role can be configured on a per-LSP basis by delegating or revoking the permission to update LSP state to or from the PCE server.

Table 1 gives a summary of PCE server modes of operation.

Table 1. PCE server modes of operation

Use case examples

Let’s look at some application examples of segment routing in combination with a stateful PCE server.

In the example shown in Figure 3, the ingress router, PE1, functions as the PCC. The OSS layer provides the ingress router with the service characteristics, which triggers PE1 to query the PCE server for a path calculation. Note that also the OSS layer may function as a PCC and query the PCE server directly.

Figure 3: Simple use case of SR-TE in combination with a stateful PCE server

  1. Service provisioning: The operations support system (OSS) layer provides the service provisioning data to the ingress router (PE1). This data includes service characteristics, the tunnel type and any applicable constraints to deliver the service requirements.
  2. Path computation request: If a tunnel that meets the required service criteria does not exist, the ingress router functions as a PCC and sends a PCReq to the PCE server. In this example, the only path constraint is a request for a bandwidth of 10 Mbps.
  3. Path computation reply: The PCE computes the path and returns a PCRep with a positive response that includes a segment list of the calculated hops through the network.
  4. LSP state report: The ingress router activates the LSP by composing a segment list and notifies the PCE server by sending a PCRpt message indicating that the LSP is up. The PCC also delegates control of the LSP to the PCE server (i.e., active stateful operation mode).
  5. The PCC continues to monitor network state, including this LSP and all other LSPs. The PCE server updates and optimizes the LSP path placement as required.

The following example shows how to apply SR-TE and a stateful PCE to set up disjoint paths with the use of a PCE path profile[7]. A path profile essentially allows for bundling of commonly used path characteristics into a profile/template that is referenced using a profile identifier. The method through which path-profile attributes are made known to the PCC/PCE peers is out-of-band and not within the scope of the path-profile extensions. It is recommended the PCC delegates control to the stateful PCE for both path requests so it can calculate disjointness for both requests in concert and optimize routes if needed.

Figure 4: Setting up a disjoint path with SR-TE, PCE and path profiles

Figure 4 shows an example of the end-to-end process of path placement using a path profile to guarantee disjointness: Path-Profile ID 10: {disjoint_to(GroupID); default_igp_cost(min cost)}. The process is as follows.

  1. Service provisioning: The OSS layer provides the service provisioning characteristics to the ingress PE. These now include an indication of the group-ID to which this service belongs.
  2. Path computation request: The ingress router functioning as a PCC sends a PCReq to the PCE server that includes a path-profile of {Path-Profile ID=10, Extended ID=1000}.
  3. Path computation reply: The PCE computes the path and returns a PCRep with a positive response. If Service M from PE1-PE3 and Service N from PE2-PE4 both signal a path-profile of {Path-Profile ID=10, Extended ID=1000}, the PCE ensures that their respective paths are disjoint from each other.
  4. LSP state report: The ingress router instantiates the LSP by imposing a segment list and notifies the PCE server by sending a PCRpt message indicating that the LSP is up. The PCC also delegates control of the LSP to the PCE server (i.e., making the PCE active stateful).
  5. The PCC monitors the network state, and the PCE server optimizes the LSPs as required.


Fast Reroute with Segment Routing white paper Segment Routing and Path Computation Element white paper Network Services Platform product feature page IP/optical integration solution page


  1. [1] IETF Internet Draft. Segment Routing Architecture (draft-filsfils-spring-segment-routing)
  2. [2] Topology Independent Loop Free Alternates (draft-francois-spring-segment-routing-ti-lfa)
  3. [3] IETF, RFC 4655. A Path Computation Element (PCE)-Based Architecture
  4. [4] An example of a route-listener is the Alcatel-Lucent 7701 Control Plane Assurance Appliance (CPAA), or virtualized CPAA (vCPAA)
  5. [5] IETF, RFC 5440, Path Computation Element (PCE) Communications Protocol (PCEP)
  6. [6] IETF, Internet Draft PCEP Extensions for Stateful PCE (draft-ietf-pce-stateful-pce)
  7. [7] IETF. Internet Draft PCE Path Profiles (draft-alvarez-pce-path-profiles)

To contact the author or request additional information, please send an email to

Anand Raj

About Anand Raj

Anand Raj is a product manager on the Carrier SDN controller at Alcatel-lucent with more than 17 years in the data networking industry. He started out his career designing call control software on ATM switches and spent many years supporting and designing Wide Area Networks consisting of both IP and ATM for a variety of large scale customers. He was one of the key founders of the Alcatel-Lucent Service Router Certification program where he wrote and taught IP courseware in the areas of MPLS, QoS, Services and Triple Play. Anand holds a BEng degree in Computer Engineering from University of Waterloo.

Arnold Jansen

About Arnold Jansen

Arnold is a senior solution marketing manager in Nokia’s Network Infrastructure business division and responsible for promoting IP routing products and solutions. Arnold has held a number of roles in research and innovation, sales, product management, and marketing during his 25 years in the telecommunications industry. He holds a Bachelor degree in Computer Science from the Rotterdam University of Applied Sciences.

Follow Arnold on Twitter


Colin Bookham

About Colin Bookham

Colin Bookham is a consulting engineer at Alcatel-Lucent with more than 20 years of experience in the telecommunications industry. He has designed or helped to design, and supported, many large IP networks across a broad range of market segments in EMEA. Prior to working at Alcatel-Lucent, Colin spent a number of years working in IP design and architecture for a UK operator. Before that, he spent the early years of his career studying communications in the Royal Navy.

Article tags