Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

How to Configure Path Computation Element Protocol for SR-TE LSPs

 
Summary

You can enable the traffic-engineering (TE) capabilities of segment routing or Source Packet Routing in Networking (SPRING) with the Path Computation Element Protocol (PCEP) for traffic steering. With this support, the advantages of segment routing are extended to the label-switched paths (LSPs) that are externally controlled by a Path Computation Element (PCE).

Segment Routing for the Path Computation Element Protocol Overview

Benefits of Segment Routing for PCEP

  • Setting up of LSPs through an external controller provides a global view of per-LSP, per-device bandwidth demand on the network, enabling online and real-time constraint-based path computation.

    The advantages of segment routing are extended to the LSPs initiated by a Path Computation Element (PCE), augmenting the benefits of external path computing in an MPLS network.

  • A Path Computation Client (PCC) with delegation capability can take back control of the delegated segment routing LSPs from the PCE when the PCEP session goes down, which would otherwise be deleted from the PCC. You can thereby benefit from LSP protection by eliminating a traffic black-hole condition.

Segment Routing for Traffic Engineering

Segment routing can operate over an IPv4 or IPv6 data plane, and supports equal-cost multipath (ECMP). With the IGP extensions built into it, segment routing integrates with the rich multiservice capabilities of MPLS, including Layer 3 VPN, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN (EVPN).

Some of the high-level components of the SR-TE solution include:

  • Use of an IGP for advertising link characteristics. This is similar to RSVP-TE.

  • Use of CSPF on the ingress device or the PCE.

  • Use of an IGP for advertising labels for links.

    In SR-TE:

    1. The ingress device constructs an LSP by stacking the labels of the links that it wants to traverse.
    2. The per-link IGP advertisement is combined with label stacking to create source routed LSPs on the ingress device, so the transit devices are not aware of the end-to-end LSPs.
    3. There is no per-LSP signaling in SR-TE. This enables creation of LSPs between edge nodes without placing any per-LSP memory requirements on the transit devices.
    4. SR-TE has the capability to stack per-neighbor labels, resulting in the management of a large number of labels, leading to control plane scaling.

Junos OS Implementation of Segment Routing for PCEP

There are two types of Junos OS implementations of segment routing with PCEP:

PCE-Initiated Segment Routing LSPs

The PCE-initiated segment routing LSPs are those LSPs that are created by the PCE using the adjacency and node segments.

The PCE:

  1. Computes the path of the segment routing LSP.
  2. Provisions the LSP on the Path Computation Client (PCC) using PCEP segment routing extensions.
  3. Parses the PCEP segment routing extensions.
  4. Creates a tunnel route on the PCC, that has its own preference value and is made available in the inet.3 routing table to resolve IP traffic and services like any other tunnel route.

The PCC:

  1. Selects the outgoing interface based on the first network access identifier (NAI) in the source Explicit Route Object (S-ERO).

    Junos OS supports S-EROs that contain the first hop as a strict hop; there is no support on the PCC to select the outgoing interface based on a loose hop node segment ID. However, the remaining hops can be loose. No specific processing is done for the S-EROs that are beyond the first hop, other than to simply use the label for next-hop creation.

  2. Rejects the S-ERO if:
    • It does not have labels in it.

    • It carries more than six hops.

  3. Creates an equal-cost multipath (ECMP) route when there are multiple LSPs to the same destination with the same metric.
  4. Waits for the PCE to process any event that leads to a change in the segment routing LSP after it is provisioned, such as withdrawal or change in label, or one of the interfaces traversed by the LSP going down.

When the PCEP session goes down, the PCE-initiated segment routing LSP:

  1. Remains up for 300 seconds.
  2. Purges out after 300 seconds.

For more details, see Internet drafts draft-ietf-pce-lsp-setup-type-03.txt (expires December 25, 2015) Conveying path setup type in PCEP messages, and draft-ietf-pce-segment-routing-06.txt (expires February 10, 2016) PCEP Extensions for Segment Routing.

PCE-Delegated Segment Routing LSPs

The PCE-delegated segment routing LSPs are the IPv4 uncolored segment routing LSPs that are locally configured on the PCC and then delegated to a PCE controller.

The PCE controls the delegated LSPs and can modify the LSP attributes for path computation. The LSP control is reverted back to the PCC when the PCEP session between the PCC and the PCE goes down. This is an advantage that PCE-delegated LSPs have over PCE-initiated LSPs, as LSPs initiated by a PCE get deleted from the PCC when the PCEP session goes down.

The following types of segment routing LSPs support the PCE-delegation capability:

  • Statically configured source-routing-paths that are computed.

  • Statically configured source-routing-paths that are auto-translated.

  • Statically configured source-routing paths that have the entire label stack statically configured.

  • Dynamically created tunnels triggered through the Dynamic Tunnel Module that have last hop ERO resolution.

Depending on the source of the segment routing LSP, you can configure the delegation capability on the PCC. To enable delegation of segment routing LSPs, include the lsp-external-controller pccd statement at the appropriate level under [edit protocols source-packet-routing].

Table 1 shows a mapping of the LSP source to the corresponding configuration hierarchy on which the delegation capability is enabled.

You must include the lsp-external-controller pccd at the [edit protocols source-packet-routing] and [edit protocols mpls] hierarchy levels before configuring the PCC with the delegation capability.

Table 1: Segment Routing LSP Source and Configuration Hierarchy Mapping

Source of Segment Routing LSP

Configuration Hierarchy

Statically configured source-routing-paths that are computed and auto-translated.

Segment list at [edit protocols source-packet-routing source-routing-path source-routing-path-name to ip-address]

Statically configured source-routing paths that have the entire label stack statically configured.

Primary segment list of the source-routing-path at [edit protocols source-packet-routing source-routing-path source-routing-path-name to ip-address primary primary-segment-list-name]

Dynamically created tunnels triggered through the Dynamic Tunnel Module that have last hop ERO resolution.

Primary segment list of the source-routing-path-template at [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

You can view the control status of the SR-TE LSPs from the show spring-traffic-engineering command output.

Table 2 displays the PCEP interaction when the lsp-external-controller statement is configured for a source-routing-path.

Table 2: PCEP Interaction LSP Delegation

lsp-external-controller Configuration Hierarchy

source-routing-path Configuration State

PCEP Interaction

Primary segment list of source-routing-path

Initial configuration

  1. PCReport is sent to the PCE requesting delegation. PCReport contains only constraints and path details (like ERO).
  2. PCE calculates the path for LSP and reports path to be in the down state.
  3. No route is programmed by the local LSP until the controller computes the ERO and notifies the result through PCUpdate.

The same behavior is seen when the routing protocol process restarts or a Routing Engine switch-over happens.

Primary segment list of of source-routing-path

Update to existing path

  1. PCReport is sent to the PCE requesting delegation. PCReport contains only constraints and path details (like ERO).
  2. Corresponding primary or secondary segment is delegated to the PCE.
  3. PCE calculates the path for LSP.
  4. The primary or secondary segment continue to contribute to the route as determined by the local configuration or computation until a PCUpdate is received from the PCE.
    • If seamless BFD (S-BFD) is not configured for the primary, then there is no further updates to the route and the LSP state is also not monitored and reported to the PCE. The LSP state at this point is reported as UP or DOWN depending on whether path computation had succeeded at that point.

    • If S-BFD is configured for the primary, then the state of the primary is duly tracked and reported to the PCE. If BFD detects the primary to be down, the corresponding primary path is removed from the route. The same route that was previously calculated is re-programmed if that the path is Up now.

  5. If a PCUpdate is received from the PCE, SR-TE uses the received parameter to setup the path for which PCReport has been sent. The programmed path then includes only the segment-list(s) received from the PCE and all the other segment-list(s) that were previously programmed are removed. This re-programming of the route happens in a make-before-break fashion.

Primary segment of source-routing-path

Not configured

The segment-list from the PCE (if available) is no longer used and the computation result from the local computation is used. Once the local result for the segment list is available, the corresponding segment list is used to program route in a make-before-break fashion.

Segment list of source-routing-path

Configured

Delegation functionality is triggered for the primary segment list under the source-routing path.

Segment list of source-routing-path

Not configured

Delegation functionality is removed from the primary segment list under the source-routing path.

Primary segment list of source-routing-path-template

Configured

  • Under the source-routing-path-template - Delegation functionality is triggered for the entire source-routing path.

    Template configurations can be applied only to Dynamic Tunnel Module.

  • Under the primary path in the source-routing-path-template - Delegation functionality is triggered for that particular primary path as per configuration.

Primary segment list of source-routing-path-template

Not configured

Delegation functionality is removed from all the source-routing paths and primary paths that match the template configuration.

Segment Routing for PCEP Limitations and Unsupported Features

The support of segment routing for PCEP does not add any additional performance burden on the system; however, it has the following limitations:

  • A SR-TE LSP is not locally protected on the PCC. When the LSP is over six hops, no other service is provided on the LSP other than to carry plain IP.

  • Graceful Routing Engine switchover (GRES) and unified ISSU in-service software upgrade are not supported.

  • Nonstop active routing (NSR) is not supported.

  • IPv6 is not supported.

  • PCE-delegated LSPs does not support the following:

    • Colored SR-TE LSPs

    • IPv6 LSPs

    • Secondary segment list of source-routing-path. Only one path of the segment list can be delegated.

    • Multi-segment standard. Only one segment list must be present in the candidate path.

WHAT'S NEXT

For information on configuring segment routing for PCEP, see Example: Configuring Segment Routing for the Path Computation Element Protocol.