Uncolored SR-MPLS TE-Policy

Uncolored SR-MPLS TE policies define the rules for traffic engineering in an SR-enabled network. They determine how traffic should be routed across the network based on various constraints.

The Uncolored SR-MPLS TE policy is a set of segment lists, where each segment list is a collection of segment IDs (SID). A segment list can be constructed with multiple SIDs to meet the traffic engineering requirment for a given tunnel. SID specifies a path from source to destination, instructing routers to follow the specified path instead of the shortest route calculated by the IGP. After a data packet is imported into an SR-MPLS TE policy, the ingress (headend) adds the SID list to the packet, and other routers on the network execute the instructions embedded in the SID list.

TE policies can be categorized into colored and uncolored types.
  • SR-MPLS colored TE policy (sr-mpls-colored): Segment lists based on labels or simply segment lists constitute candidate paths, where each path is configured using a color and an endpoint. This is similar to SR Policies, where colors and endpoints are used to identify candidate paths.
  • Uncolored SR-MPLS TE policy (sr-mpls-uncolored): A single active LSP is represented as a segment list under the TE policy. Ideally, the primary segment list is used, with the standby as an alternative. As a last resort, the secondary segment list becomes active to provide a TE path to a given destination. Note that in 7x50 SR OS routers, uncolored SR-MPLS TE-Policy segment lists are referred to as SR-TE LSPs.

Basic concepts

The following terms are essential for understanding the structure of an SR-MPLS TE policy and the interrelationship between policies.

Segment list

A segment list is an ordered sequence of SIDs that steers traffic along a specific path when translated to a data path encapsulation. You can configure segment lists directly, derive them from other configurations (for example, an explicit path specifying IP addresses or mpls labels), or compute them.

Binding Segment Identifier (BSID)

A BSID is an identifier that represents an SR-MPLS TE policy. When a packet with a BSID is received, the router selects an SR-MPLS TE policy based on the BSID to route the packet. With BSIDs, complex path policies can be encapsulated into single identifiers thus simplifying their application.

Endpoint

An endpoint defines the destination of the SR-MPLS TE policy. It is the IP address of the final destination node or router for the traffic. This is a mandatory parameter for SR-MPLS TE policy configuration.

Explicit path

The SR-MPLS TE policies can define explicit paths, where the exact sequence of SIDs is specified manually. The explicit path can be configured based on an IP address or MPLS label. The explicit path can be either strict or loose hop.

Dynamic path

A dynamic path provides an optimization objective and a set of constraints. The ingress Label Edge Router (iLER) can compute dynamic paths using local CSPF or via an external Path Computation Engine (PCE).

TE policy tunnel

TE policy tunnels are source-routed traffic engineered end-to-end segment routing paths, where routing constraints such as strict or loose hops can be used to determine a data path through a network. TE-policy tunnels can have one (uncolored) or more (colored) segment-lists that are active at any given time. These segment-lists follow the guidelines set by an uncolored SR-MPLS TE-Policy. Note that in 7x50 SR OS routers, uncolored SR-MPLS TE-Policy segment lists are referred to as SR-TE LSPs.

Uncolored SR-MPLS TE Policy segment lists are similar to traditional traffic-engineered LSPs such as RSVP-TE and offer a natural migration path, except that uncolored SR-MPLS TE Policy segment lists do not have a mid-point state. Each intermediate and tail-end router is unaware of the segment list's presence because no signaling protocol is used to create the path. The path can be computed locally by the ingress PE or by offloading the path computation to an external controller (PCE).

Binding segments

Binding Segment, or BSID, is a SID value that opaquely represents an SR-MPLS TE policy to upstream routers. When a packet with a BSID as the top label is received, the router selects an SR-MPLS TE policy based on the BSID to route the packet. BSIDs provide isolation or decoupling between different source-routed domains and improve overall network scalability.

A BSID can be assigned to a uncolored SR-MPLS TE policy, which can have multiple segment lists (primary and secondary). The BSID remains the same, but the actual path taken can change based on the availability and preference of the segment list.

The SR-MPLS TE policy switches to the secondary segment list if the primary segment list becomes unavailable because of link or node failure. This ensures traffic continues to be routed without interruption.

Suppose a network has four nodes - N1, N2, N3, and N4. The segment list and BSID are configured as follows:
  • primary segment list has four SIDs: 1,2,3,4
  • secondary segment list has two SIDs : 1,4
  • BSID: 16001

When a data packet with BSID 16001 is received, the ingress router applies the SR-MPLS TE policy associated with BSID 16001. This policy includes an explicit path consisting of a sequence of nodes (segments) the packet must traverse. All SIDs listed in a specific segment list are included in the packet header.

When a packet is sent with a primary segment list (1, 2, 3, 4), the packet traverses through nodes in the order of these segment IDs. If the primary segment list is unavailable or needs rerouting, the packet can use the secondary segment list (1, 4) instead. This secondary segment list serves as a backup path for the packet.

Configuring SR-MPLS TE policy

Segment Routing supports traffic engineering by using logical traffic tunnels that adhere to specific constraints.

SR Linux supports default network instance TE policies for configuration of traffic engineered tunnels.

To configure SR-MPLS TE policy, perform the following tasks:
  1. Configure a static label range.
  2. Assign the static MPLS label range to the BSID.
  3. Define explicit path.
  4. Configure the TE features.
  5. Enable advertisement of IS-IS TE TLVs/sub-TLVs.
  6. Configure the SR-MPLS TE policy using the defined explicit path and BSID.

Configuring a static label range.

Use the command, .system.mpls.label-ranges. to configure the static label range. The static label range is used by all participating routers within the SR domain. In the configuration example, a static MPLS range (srl-static-label-range) is set from 16001-104857.
--{ + running }--[  ]--
# info system mpls label-ranges static srl-static-label-range
    system {
        mpls {
            label-ranges {
                static srl-static-label-range {
                    shared false
                    start-label 16001
                    end-label 104857
                }
            }
        }
    }

Assigning a static MPLS range to the BSID

The following example configures the BSID in SR-capable routers to align with the configured label range (srl-static-label-range).

--{ + running }--[  ]--
# info network-instance default traffic-engineering-policies binding-sid
    network-instance default {
        traffic-engineering-policies {
            binding-sid {
                static-label-block srl-static-label-range
            }
        }
    }

Define explicit path

Define the explicit path that the SR-MPLS TE policy follows. This involves configuring the intermediate hops (nodes or segments) that the traffic follows along the explicit path.

The following example configures an explicit path that can be used as a primary path (e_prim_path). 

--{ + candidate shared default }--[ ]--
info network-instance default traffic-engineering-policies explicit-paths path e_prim_path
    network-instance default {
        traffic-engineering-policies {
            explicit-paths {
                path e_prim_path {
                    hop 10 {
                        ip {
                            ip-address 10.0.0.2
                            hop-type strict
                        }
                    }
                    hop 20 {
                        ip {
                            ip-address 10.0.0.3
                            hop-type strict
                        }
                    }
                    hop 30 {
                        ip {
                            ip-address 10.0.0.4
                            hop-type strict
                        }
                    }
                }
            }
        }
    }
The following example configures another explicit path that can be used as a secondary path (e_sec_path). 
--{ + candidate shared default }--[ ]--
info network-instance default traffic-engineering-policies explicit-paths path e_sec_path
    network-instance default {
        traffic-engineering-policies {
            explicit-paths {
                path e_sec_path {
                    hop 40 {
                        ip {
                            ip-address 10.0.0.5
                            hop-type loose
                        }
                    }
                }
            }
        }
    }

Configuring the TE link attributes

For information about configuring the TE attributes in the SR domain, see Traffic Engineering.

Enabling advertisement of IS-IS TE TLVs/sub-TLVs

For information about enabling advertisement of IS-IS TE TLVs/sub-TLVs, see Enabling advertisement of IS-IS TE TLVs/sub-TLVs.

Configuring SR-MPLS TE policy

The following example configures the SR-MPLS TE policy using the defined explicit path and the BSID. 
--{ + candidate shared default }--[ ]--
 info network-instance default traffic-engineering-policies policy srl_mpls_te_policy
    network-instance default {
        traffic-engineering-policies {
            policy srl_mpls_te_policy {
                policy-type sr-mpls-uncolored
                endpoint 10.0.0.4
                binding-sid {
                    mpls-label 16001
                }
                segment-list 10 {
                    explicit-path e_prim_path
                    segment-list-type primary
                }
                segment-list 20 {
                    explicit-path e_sec_path
                    segment-list-type secondary
                }
            }
        }
    }

Configuring BSID to a static MPLS label range

You can configure a BSID to reference a static MPLS label range. The high-level steps are as follows:
  1. Define the static label range.
  2. Assign the static label range to the BSID.

Configure a static MPLS label range

In the configuration example, a static MPLS range (srl-static-label-range) is set from 16001-104857. The start-label or end-label value of the static LSP label range must be within the range 16-1048575.

--{ + running }--[  ]--
# info system mpls label-ranges static srl-static-label-range
    system {
        mpls {
            label-ranges {
                static srl-static-label-range {
                    shared false
                    start-label 16001
                    end-label 104857
                }
            }
        }
    }

Assign the static MPLS label range to the BSID

The following example configures the BSID in SR-capable routers to correspond to the configured label range (srl-static-label-range).

--{ + running }--[  ]--
# info network-instance default traffic-engineering-policies binding-sid
    network-instance default {
        traffic-engineering-policies {
            binding-sid {
                static-label-block srl-static-label-range
            }
        }
    }

Configuring BSID to a MPLS label value

You can configure a BSID to reference a static MPLS label value. The high-level steps are as follows:
  1. Configure a static MPLS label range.
  2. Assign a static MPLS label value to the BSID

Configure a static MPLS label range

The following example defines a static MPLS label range (srl-static-label-range) for use by the SRLB. The start-label or end-label value of the static LSP label range must be within the range 16-1048575.

--{ + running }--[  ]--
# info system mpls label-ranges static srl-static-label-range
    system {
        mpls {
            label-ranges {
                static srl-static-label-range {
                    shared false
                    start-label 16001
                    end-label 104857
                }
            }
        }
    }

Assign a static MPLS label value to the BSID

In the following example, the MPLS label value 16008 falls within the defined MPLS label range (srl-static-label-range) and serves as the BSID for the configured SR-MPLS TE policy (srl_mpls_te_policy). 
--{ + running }--[  ]--
# info network-instance default traffic-engineering-policies policy srl_mpls_te_policy
    network-instance default {
        traffic-engineering-policies {
            policy srl_mpls_te_policy {
                binding-sid {
                    mpls-label 16008
                }
            }
        }
    }
    }

SR-MPLS TE policy path computation

When an SR-MPLS TE policy is configured on the router, the router can compute its path or an external TE controller.

SR Linux supports the following path computation methods configurable individually for each TE policy segment list:
  • explicit path: allows the user to manually configure each TE Policy segment list path using an explicit list of SID values.
  • Local Constrained Shortest Path First (CSPF) segment list: allows routers within a network to calculate TE Policy segment list paths based on CSPF algorithms autonomously. Unlike explicit paths defined manually, local CSPF computation dynamically selects paths based on constraints and real-time network conditions.
  • Path Computation Element Protocol (PCEP) : allows the SR Linux router, acting as a PCE client (PCC), to forward requests for SR-MPLS TE path computations to the PCE.

Explicit path

The SR-MPLS TE policy path can be manually configured using an explicit list of SID values or nexthop IP addresses. Explicit path configuration is supported for primary, secondary, and standby paths.

When configuring an explicit path, you can specify either an MPLS label (mpls-label) or the IP address (ip-address) of the intermediary hops that the LSP needs to pass to the egress router. However, using an IP address requires IP-to-label translation to map the address to the corresponding SID in the SR network.

When using explicitly configured SIDs for a path that includes SIDs or IP address hops, you must provide all the necessary SIDs to reach the destination. The router verifies if the first SID provided is present in the router tunnel table.

When explicit SIDs are used in a path, the router prioritizes these SIDs over any configured path computation methods such as PCEP or CSPF at the TE policy segment list level. The router can establish the path based on the specified SIDs alone, disregarding the configured path computation for TE policy segment list.

When a TE-Policy (sr-mpls-uncolored) includes both SID-labeled paths and paths calculated using local-CSPF, the router cannot guarantee SRLG diversity between the CSPF and SID-labeled paths. This is because CSPF does not know about the SID-labeled paths, which are not included in the TE database.

Note:

Paths containing explicit SID values can only be used by SR-MPLS TE policy tunnels.

Configuring explicit-path segment lists

When configuring an explicit path, specify either an MPLS label (mpls-label) or the IP address (ip-address) for each hop in the path.
Configuring an explicit path MPLS label

The following example configures an explicit path using the MPLS label (mpls-label) for the intermediary hops that the TE policy segment list needs to pass to reach the egress router. The value of the mpls-label must be within the range 16-1048575.

--{ + candidate shared default }--[ ]--
info network-instance default traffic-engineering-policies explicit-paths path srl-explicit_path
    network-instance default {
        traffic-engineering-policies {
            explicit-paths {
                path srl-explicit_path {
                    hop 50 {
                        mpls-label 16002
                    }
                    hop 60 {
                        mpls-label 16003
                    }
                }
            }
        }
    }
Configuring an explicit path using an IPv4-address

The following example configures an explicit path consisting of IPv4 addresses of the intermediary hops that the TE policy segment list needs to pass to reach the egress router.

--{ + candidate shared default }--[ ]--
info network-instance default traffic-engineering-policies explicit-paths path srl-explicit_path
    network-instance default {
        traffic-engineering-policies {
            explicit-paths {
                path srl-explicit_path {
                    hop 10 {
                        ip {
                            ip-address 10.0.0.2
                            hop-type strict
                        }
                    }
                    hop 20 {
                        ip {
                            ip-address 10.0.0.3
                            hop-type strict
                        }
                    }
                    hop 30 {
                        ip {
                            ip-address 10.0.0.4
                            hop-type strict
                        }
                    }
                }
            }
        }
    }

Path Computation Element Protocol (PCEP)

The PCEP is one of several protocols used to communicate between a Wide Area Network (WAN) Software Define Networking (SDN) controller and network elements. The Nokia WAN SDN Controller is known as the Network Services Platform (NSP).

The SR Linux node operates as the Path Computation Client (PCC), while the Nokia NSP (or another third-party PCE) serves as Path Computation Element (PCE). PCEs are used for path computation of TE policy segment list in SR-MPLS domain.

PCEP provides mechanisms for PCEs to perform path computations in response to PCC requests.

Each router (SR Linux node) acting as a PCC initiates a PCEP session with the PCE in its domain. The PCC uses PCEP to send a path computation request for one or more TE policy segment lists to the PCE. The PCE then replies with a set of computed paths if it finds one or more paths that satisfy the set of constraints.

SR Linux supports the following PCE and PCC capabilities:

  • base PCEP implementation, in accordance with RFC 5440

  • active and passive stateful PCE LSP update, in accordance with RFC 8231, Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

  • delegation of LSP control to PCE

  • synchronization of the LSP database (LSP-DB) with network elements for PCE-controlled LSPs and network element-controlled LSPs

  • support for PCC-initiated LSPs, in accordance with RFC 8231, Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

Base implementation of PCE

The base implementation of PCE uses the PCEP extensions defined in RFC 5440.

The main functions of the PCEP are:

  • establishing, maintaining, and closing PCEP sessions

  • generating path computation requests using the PCReq message

  • generating path computation replies using the PCRep message

  • generating notification messages (PCNtf) by which the PCEP speaker can inform its peer about events, such as path request cancellation by the PCC or path computation cancellation by the PCE

  • generating error messages (PCErr) by which the PCEP speaker can inform its peer about errors related to processing requests, message objects, or TLVs

The following table lists the base PCEP messages and objects.

Table 1. Base PCEP message objects and TLVs
TLV, object, or message Contained in object Contained in message

OPEN object

—

OPEN, PCErr

Request Parameter (RP) object

—

PCReq, PCRep, PCErr, PCNtf

NO-PATH object

—

PCRep

END-POINTS object

—

PCReq

METRIC object

—

PCReq, PCRep, PCRpt, PCInitiate

Explicit Route Object (ERO)

—

PCRep

Reported Route Object (RRO)

—

PCReq

LSPA object

—

PCReq, PCRep, PCRpt, PCInitiate

NOTIFICATION object

—

PCNtf

PCEP-ERROR object

—

PCErr

CLOSE object

—

CLOSE

The base (stateless) PCE computes paths without considering the existing state of network LSPs.

The behavior and limitations of the implementation of the objects in the preceding table are as follows:

  • The PCE treats all supported objects received in a PCReq message as mandatory, regardless of whether the P-flag in the common header of the object is set (mandatory object) or not (optional object).

  • The PCC implementation always sets the B-flag (B=1) in the METRIC object containing the hop metric value, which means that a bound value must be included in the PCReq message. The PCE returns the computed value in the PCRep message with flags set identically to the PCReq message.

  • The PCC implementation always sets flags B=0 and C=1 in the METRIC object for the IGP or TE metric values in the PCReq message. This means that the request is to optimize (minimize) the metric without providing a bound. The PCE returns the computed value in PCRep message with flags set identically to the PCReq message.

  • The IRO and LOAD-BALANCING objects are not supported in the NSP PCE feature. If the PCE receives a PCReq message with one or more of these objects, it ignores them regardless of the setting of the P-flag and processes the path computations normally.

  • LSP path setup and hold priorities are configurable during SR-TE LSP configuration on the router, and the PCC passes the configurations on in an LSPA object. However, the PCE does not implement LSP preemption.

  • The LSPA and METRIC objects are also included in the PCRpt message.

The following features are not supported in SR Linux:

  • PCE discovery using IS-IS (as defined in RFC 5089) and OSPF (as defined in RFC 5088) along with corresponding extensions for discovering stateful PCE (as defined in draft-sivabalan-pce-disco-stateful)

  • PCEP synchronization optimization (as defined in RFC 8232)

  • jitter, latency, or packet loss link metric signaling in the PCE METRIC object (as defined in RFC 8233)

PCEP session establishment and maintenance

The PCEP protocol operates over TCP using the destination TCP port 4189. The PCE client (PCC) always initiates the connection. After the user configures the PCEP local IPv4 or IPv6 address and the peer IPv4 or IPv6 address on the PCC, the PCC initiates a TCP connection to the PCE. If both a local IPv4 and a local IPv6 address are configured, the connection uses the local address of the same family as the peer address. When the connection is established, the PCC and PCE exchange OPEN messages, and this process initializes the PCEP session and exchanges the session parameters to be negotiated.

By default, the PCC attempts to reach the remote PCE address through the default network instance. PCE connectivity can be via default or management network instance. SR Linux node in the PCC role attempts an in-band connection to PCE via default network.instance which can be changed to management network.instance for out-of-band connectivity. The local IPv4 or IPv6 address configured by the user is always used to set up the PCEP session.

A keepalive mechanism is used as an acknowledgment of the acceptance of the session within the negotiated parameters. It is also used as a maintenance function to detect whether the PCEP peer is still alive.

The negotiated parameters include the keepalive timer and the dead timer and one or more PCEP capabilities, such as support for stateful PCE and the SR-MPLS TE LSP path type.

The following figure shows PCEP session initialization steps.

Suppose the session to the PCE times out, the router acting as a PCC keeps the last successfully programmed path provided by the PCE until the session is re-established. Any subsequent TE policy segment list state change is synchronized when the session is re-established.

When a PCEP session with a peer time out or closes, the rate at which the PCEP speaker attempts to establish the session is subject to an exponential back-off mechanism.

PCEP parameters

SR Linux supports configuring of PCEP parameters at the .network-instance .protocols. level. On the PCE, the configured parameter values are used on sessions to all PCCs.

Configuring keepalive timer

A PCEP speaker (PCC or PCE) must send a keepalive message if no other PCEP message is sent to the peer at the expiry of this timer. This timer is restarted every time a PCEP message is sent or the keepalive message is sent.

The keepalive mechanism is asymmetric, meaning that each peer can use a different keepalive timer value.

The range of this parameter is 1 to 255 seconds, and the default value is 30 seconds. If the keepalive value is not explicitly configured, the system defaults to the predefined default value.

Note:

The keepalive parameter cannot be modified while the PCEP session is operational.

--{ candidate shared default }--[  ]--
info network-instance default protocols pcep pcc keepalive
    network-instance default {
        protocols {
            pcep {
                pcc {
                    keepalive 254
                }
            }
        }
    }
Configuring dead-timer

This timer tracks the amount of time a PCEP speaker (PCC or PCE) waits after the receipt of the last PCEP message before declaring its peer down.

The dead timer mechanism is asymmetric, meaning that each PCEP speaker can propose a different dead timer value to its peer to use to detect session timeouts.

The range of this parameter is 1 to 255 seconds, and the default value is 120 seconds. If the dead-timer value is not explicitly configured, the system defaults to the predefined default value.

Note:

The dead-timer parameter cannot be modified while the PCEP session is operational.

--{ candidate shared default }--[  ]--
info network-instance default protocols pcep pcc dead-timer
    network-instance default {
        protocols {
            pcep {
                pcc {
                    dead-timer 50
                }
            }
        }
    }
Configuring unknown message rate

You can configure the maximum rate of unknown messages which can be received on a PCEP session. When the rate of received unrecognized or unknown messages reaches this limit, the PCEP speaker closes the session to the peer.

Note:

The unknown-message-rate parameter can be modified while the PCEP session is operational.

--{ candidate shared default }--[  ]--
 info network-instance default protocols pcep pcc unknown-message-rate
    network-instance default {
        protocols {
            pcep {
                pcc {
                    unknown-message-rate 65
                }
            }
        }
    }
Configuring session redelegation timer

Redelegation timers (known as the Redelegation Timeout Interval in RFC 8231) are started when the PCEP session goes down or the PCE signals overload.

The range of this parameter is 1 to 3600 seconds, and the default value is 90 seconds. If the redelegation-timer value is not explicitly configured, the system defaults to the predefined default value.

--{ candidate shared default }--[  ]--
info network-instance default protocols pcep pcc redelegation-timer
    network-instance default {
        protocols {
            pcep {
                pcc {
                    redelegation-timer 2500
                }
            }
        }
    }
    }
Configuring state timers
State timers (known as the State Timeout Interval in RFC 8231) are started when the PCEP session goes down or the PCE signals overload.
Note: The state timer applies only to PCE-initiated TE policy segment lists.
--{ candidate shared default }--[  ]--
info network-instance default protocols pcep
    network-instance default {
        protocols {
            pcep {
                pcc {
                    state-timer {
                        timer 30
                        timer-action none
                    }
                }
            }
        }
    }
Configuring report path constraints

Use the parameter report-path-constraints to enable or disable the path constraints in PCC report. When set to false, the TE policy segment list path constraints are not included in the report message that the PCC sends to the PCE.

Note:

The report-path-constraints parameter can be modified while the PCEP session is operational.

--{ candidate shared default }--[  ]--
info network-instance default protocols pcep pcc report-path-constraints
    network-instance default {
        protocols {
            pcep {
                pcc {
                    report-path-constraints true
                }
            }
        }
    }
Configuring peer PCEP IP address

You can configure the IP address of a peer PCEP speaker. The address is used as the destination address in the PCEP session messages to a PCEP peer.

The preference parameter allows the PCC to select the preferred PCE when both have their PCEP sessions successfully established. A maximum of two PCEP peers is supported.

The PCE peer that is not in overload is always selected by the PCC as the active PCE. However, if neither of the PCEs are signaling the overload state, the PCE with the higher numerical preference value is selected, and in case of a tie, the PCE with the lower IP address is selected. To change the value of the preference parameter, the peer must be deleted and recreated.

Note:

The peer parameter cannot be modified while the PCEP session is operational.

In the following example two PCEP peers are configured.
--{ candidate shared default }--[  ]--
info network-instance default protocols pcep pcc
    network-instance default {
        protocols {
            pcep {
                pcc {
                    unknown-message-rate 65
                    report-path-constraints true
                    dead-timer 89
                    redelegation-timer 2500
                    state-timer {
                        timer 30
                        timer-action none
                    }
                    peer 192.168.0.5 {
                        preference 5
                    }
                    peer 192.168.0.10 {
                        preference 1
                    }
                }
            }
        }
    }

PCE connection

By default, the PCC attempts to reach the remote PCE address through the default network instance. PCE connectivity can be via default or management network instance. SR Linux node in the PCC role attempts an in-band connection to PCE via default network.instance which can be changed to management network.instance for out-of-band connectivity. The local IPv4 or IPv6 address configured by the user is always used to set up the PCEP session.
Configuring an in-band reachability

In the following example, PCC is configured to connect to the PCE server with an in-band reachability.

--{ * candidate shared default }--[  ]--
info network-instance default protocols pcep pcc peer 193.0.0.1
    network-instance default {
        protocols {
            pcep {
                pcc {
                    peer 193.0.0.1 {
                        admin-state enable
                        local-address 192.0.0.5
                        preference 1
                        network-instance default
                    }
                }
            }
        }
    }
    }
Configuring an out-of-band reachability

In the following example, PCC is configured to connect to the PCE server with an out-of-band reachability.

--{ * candidate shared default }--[  ]--
info network-instance default protocols pcep pcc peer 193.0.0.1
    network-instance default {
        protocols {
            pcep {
                pcc {
                    peer 193.0.0.1 {
                        admin-state enable
                        local-address 192.0.0.5
                        preference 1
                        network-instance mgmt
                    }
                }
            }
        }
    }

Stateful PCE

A stateful PCE implementation maintains an up-to-date Traffic Engineering Database (TED) and LSP State Database (LSP-DB).

The TED includes the network topology and resource state. The LSP-DB stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth usage, switching types, and TE-policy constraints. This state information computes constrained paths while considering individual segments and their interdependency.

The primary function of stateful PCE, as opposed to the base PCE implementation, is the ability to synchronize the TE-Policy (sr-mpls-uncolored) segment list information between the PCC and the PCE. This function allows the PCE to have all the required segment list information to optimize and update the segment list paths.

The following table describes the messages and objects supported by stateful PCE in SR Linux.

Table 2. PCEP stateful PCE extension objects and TLVs
TLV, object, or message Contained in object Contained in message

Path Computation State Report (PCRpt) message

—

New message

Path Computation Update Request (PCUpd) message

—

New message

Stateful PCE Capability TLV

OPEN

OPEN

Stateful Request Parameter (SRP) object

—

PCRpt, PCErr, PCInitiate

LSP object

ERO

PCRpt, PCReq, PCRep, PCInitiate

LSP Identifiers TLV

LSP

PCRpt

Symbolic Path Name TLV

LSP, SRP

PCRpt, PCInitiate

LSP Error Code TLV

LSP

PCRpt

The following behavior and limitations apply to the implementation of the objects listed in the preceding table:

  • PCC and PCE support all PCEP capability TLVs defined in this document and always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, neither the PCE nor the PCC use them during the specific PCEP session.

  • The PCC always includes the LSP object in the PCReq message to ensure that the PCE can correlate the PLSP ID for this LSP when a subsequent PCRpt message arrives with the delegation bit set. The PCE, however, still honors a PCReq message without the LSP object.

  • PCE path computation only considers the bandwidth used by LSPs in its LSP-DB. As a result, in the following situations, the PCE path computation does not accurately account for the bandwidth used in the network:

    • when there are LSPs that are signaled by the routers but are not synchronized with the PCE. The user can enable the reporting of the LSP to the PCE LSP database for each LSP.

    • when the stateful PCE is peering with a third-party stateless PCC, implementing only the original RFC 5440. While the PCE is able to bring the PCEP session up, the LSP database is not updated, because stateless PCC does not support the PCRpt message. As such, PCE path computation does not accurately account for the bandwidth used by these LSPs in the network.

  • The PCE ignores the reoptimize flag (R-flag) in the PCReq message when acting in stateful-passive mode for a specific LSP and always returns the new computed path, regardless of whether it is link-by-link identical or has the same metric as the current path. The PCC decides whether to initiate the new path in the network.

  • The SVEC object is not supported in SR Linux . If the PCE receives a PCReq message with the SVEC object, it ignores the SVEC object and treats each path computation request in the PCReq message as independent, regardless of the setting of the P-flag in the SVEC object common header.

  • When an LSP is delegated to the PCE, there can be no prior state in the NRC-P LSP database for the LSP. This could be because the PCE did not receive a PCReq message for the same PLSP-ID. For the PCE to become aware of the original constraints of the LSP, the following additional procedures are performed:

    • The PCC appends a duplicate of each of the LSPA and METRIC objects in the PCRpt message. The only difference between the two objects of the same type is that the P-flag is set in the common header of the duplicate object to indicate a mandatory object for processing by the PCE.

    • The value of the metric in the duplicate object contains the original constraint value, while the first object contains the operational value. This is applicable to hop metrics in the METRIC object only. The SR Linux PCC does not support putting a bound on the IGP or TE metric in the path computation.

    • The path computation on the PCE uses the first set of objects when updating a path, if the PCRpt message contains a single set. If the PCRpt message contains a duplicate set, the PCE path computation must use the constraints in the duplicate set.

    • For interoperability, implementations compliant to PCEP standards accept the first metric object and ignore the second object without additional error handling. Because there are LSPA objects, the report-path-constraints command is provided in the PCC on a per-PCEP session basis to disable the inclusion of the duplicate objects. Duplicate objects are included by default.

Active stateful PCE

An active stateful PCE updates TE-Policy (sr-mpls-uncolored) segment list information for those TE-Policies whose PCCs have delegated control to the PCE. When you enable PCE control for one or more TE-Policy (sr-mpls-uncolored), the PCE takes over the path, updating and periodically re-optimizing the TE-policy.

Passive stateful PCE

A passive stateful PCE uses TE-Policy (sr-mpls-uncolored) segment list information to optimize path computation but does not actively modify the segment list state. In this role, the PCE considers other segment lists on the router, taking into account their resource usage while computing paths for the segment lists it controls, but it does not directly update the segment list state itself.

PCEP establishment and maintenance of TE policy segment list

This section describes the PCEP establishment and maintenance of the TE policy segment lists .

TE policy segment list path initiation

A TE policy segment list that is configured on the router is called a PCC-initiated TE policy segment list.

SR Linux supports the following modes of operation configurable per TE policy segment list.
  • PCC-initiated and PCC-controlled TE policy segment list: TE policy segment list path is computed and updated by the router acting as a PCC.
  • PCC-initiated and PCE-computed TE policy segment list: TE policy segment list path is computed by the PCE at the request of the PCC.

The configured net-instance.traffic-engineering.te-router-id is the source IP address in PCEP requests or reports. The network operator must ensure that the configured IP address is advertised via IGP.

In scenarios where net-instance.traffic-engineering.te-router-id is not configured, the PCE computed or PCE controlled segment list becomes inactive.

PCC-initiated and PCC-controlled TE policy segment list
When the TE policy segment list path is computed and updated by the router acting as a PCE Client (PCC), the TE policy segment list is called a PCC-initiated and PCC-controlled TE policy segment list. A PCC-initiated and PCC-controlled TE policy segment list has the following characteristics:

  • can contain strict or loose hops, or a combination of both

  • supports both a basic hop-to-label translation and a full CSPF as a path computation method

  • capability exists to report and synchronize the TE policy segment list information with the LSP database of a stateful PCE server using the command network-instance* [name] traffic-engineering-policies!+ policy* [policy-name] segment-list* [segment-list-index] pce-report? . The PCE cannot update the TE policy segment list path; the PCC maintains control of the TE policy segment list.

Configuring PCC-initiated and PCC-controlled TE policy segment list

To authorize the PCC to compute the paths for the TE policy segment list, set the parameter pce-control value within the network-instance default traffic-engineering-policies.policy.segment-list to false.
Configuring TE policy segment list path computation by PCC
--{ +* candidate shared default }--[  ]--
info network-instance default traffic-engineering-policies policy srl_test_policy
    network-instance default {
        traffic-engineering-policies {
            policy srl_test_policy {
                endpoint 192.168.2.1
                segment-list 3 {
                    pce-control false
                    pce-report true
                }
                segment-list 13 {
                    pce-control false
                    pce-report true
                }
            }
        }
    }
PCC-initiated and PCE-computed TE policy segment list

In this mode of operation, the TE policy segment list path is computed by the PCE at the request of the PCC. The PCE calculates the route of the TE policy segment list as requested by the PCC using the command, network-instance* [name] traffic-engineering-policies!+ policy* [policy-name] segment-list* [segment-list-index] dynamic! path-algorithm?.

A PCC-initiated and PCE-computed TE policy segment list supports the passive stateful mode. This allows the PCE to perform path computation only at the request of the PCC; the PCC retains control. The capability exists to report and synchronize the TE policy segment list information with the LSP database of a stateful PCE server using the command network-instance* [name] traffic-engineering-policies!+ policy* [policy-name] segment-list* [segment-list-index] pce-report?.

Configuring PCC-initiated and PCE-computed TE policy segment list

To delegate path computation for the TE policy segment list to the PCE, set the parameter path-algorithm value within the network-instance* [name] traffic-engineering-policies!+ policy* [policy-name] segment-list* [segment-list-index] dynamic! to pce.

Configuring TE policy segment list path computation by PCE
--{ +* candidate shared default }--[  ]--
info network-instance default traffic-engineering-policies policy srl_test_policy
    network-instance default {
        traffic-engineering-policies {
            policy srl_test_policy {
                endpoint 192.168.2.1
                segment-list 10 {
                    segment-list-type primary
                    pce-report true
                    dynamic {
                        path-algorithm pce
                    }
                }
            }
        }
    }
Configuring a TE policy segment list to synchronize the LSP database with a stateful PCE
To report a TE policy segment list and synchronize the LSP database of a stateful PCE server, set the parameter pce-report value within the network-instance* [name] traffic-engineering-policies!+ policy* [policy-name] segment-list* [segment-list-index] to true.
--{ +* candidate shared default }--[  ]--
info network-instance default traffic-engineering-policies policy srl-mpls-te-policy
    network-instance default {
        traffic-engineering-policies {
            policy srl-mpls-te-policy {
                policy-type sr-mpls-uncolored
                segment-list 4 {
                    pce-report true
                    dynamic {
                        path-algorithm pce
                    }
                }
            }
        }
    }
Configuring PCC-initiated, PCE-computed and Controlled TE policy segment lists
To authorize the PCE to control the path and delegate the path it computes, set the parameter pce-control value within the network-instance default traffic-engineering-policies.policy.segment-list to true.
Configuring TE policy segment list path computation and control by PCE
--{ +* candidate shared default }--[  ]--
info network-instance default traffic-engineering-policies policy sr-mpls-te-policy
    network-instance default {
        traffic-engineering-policies {
            policy sr-mpls-te-policy {
                policy-type sr-mpls-uncolored
                segment-list 4 {
                    pce-control true
                }
            }
        }
    }

Local CSPF (Constrained Shortest Path First) based path computation

TE policy path computation using local CSPF is applicable in single-level IS-IS instances. When there are more complex TE policy path computations, or when the network is expanded into multiple IGP areas or instances, an external PCE is required.

TE policy segment list does not require each router to be TE enabled, and the links do not have to be TE links. As long as the routers at each end of the link are SR enabled, local CSPF can calculate an end-to-end path.

Full CSPF path computation on the head-end router (PCC) results in a full explicit path to the destination. The PCC calculates an end-to-end path and the following applies:

  • The computed path is a full explicit TE path.

  • Each link is represented by an adjacency SID.

  • CSPF returns a label stack list of adjacency SIDs.

A TE policy segment list can be re-signaled when a timer expires, when an operator issues a command, or in case of IGP events.

Paths computed by local CSPF contain an adjacency SID for each link in the path and the stack may contain numerous labels. When a network-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraints.segment-depth value exceeds the calculated LSP label stack size or the maximum segment depth of a downstream router is lower than the calculated LSP label stack size, the label stack can be reduced. The label stack reduction capability can replace a series of adjacency SIDs with a node SID. For loose-hop path computation, node SIDs or a combination of node and adjacency SIDs can be used.

Local CSPF is supported on both primary and secondary standby paths of a TE policy segment list.

Local CSPF path computation and SR protected interfaces

When SR is enabled and IGP adjacency is established over a link, the router advertises an adjacency SID in the adjacency SID sub-TLV. When Loop-Free Alternate (LFA), Remote LFA (RLFA), or Topology-Independent LFA (TI-LFA) is enabled, protected adjacencies have the backup flag (B-flag) set in the adjacency SID sub-TLV. Each adjacency is available for SID protection when LFA, RLFA, or TI-LFA is enabled. It is possible to remove SID protection on a specific link by setting the parameter local-sr-protection within the network-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraints to none.

Local CSPF path calculation can set up a path that:

  • only includes protected adjacencies - Here, the parameter local-sr-protection within the network-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraints is set to mandated value.

  • only includes unprotected adjacencies - Here, the parameter local-sr-protection within the network-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraints is set to none value.

  • can include both protected and unprotected adjacencies - Here, the parameter local-sr-protection within the network-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraints is set to preferred value. This is a default option.

Configuring CSPF for path computation

To configure a TE policy segment list path computation request to be forwarded to a local router CSPF, set the parameter path-algorithm value within the network-instance default traffic-engineering-policies.policy.segment-list dynamic. to local-cspf. 
--{ +* candidate shared default }--[  ]--
info network-instance default traffic-engineering-policies policy srl_test_policy
    network-instance default {
        traffic-engineering-policies {
            policy sr-mpls-te-policy {
                policy-type sr-mpls-uncolored
                endpoint 10.0.0.2
                tag-set srl-tag-set
                segment-list 3 {
                    dynamic {
                        path-algorithm local-cspf
                    }
                }
                segment-list 4 {
                    pce-control true
                }
            }
        }
    }

Uncolored SR-MPLS TE-policy tag-sets

Tag-sets (tag-set) can be configured for an uncolored SR-MPLS TE policy path. A TE policy is a traffic engineered tunnel that follows a path determined by a sequence of segment routing SIDs. You can customize the binding of traffic to the tunnel based on tag-sets. The tag-set functionality for a given SR-MPLS uncolored TE policy (sr-mpls-uncolored) is analogous to the admin-tag for SR-TE LSPs in 7x50 SR OS routers.

When a tag-set is assigned to a TE policy, it can contain up to two tags. Preference is given to a more complete match. During resolution, a tag-set with two matching tag-values is preferred over a tag-set with one matching tag-value. Tag match criteria are user configurable and can be set to mandatory, in which case an exact match is required for resolution of network instance or a route to a given TE Policy. For example, if a BGP route has a tag-set X, it can only bind to a tunnel with a tag-set X. Otherwise, it remains unresolved.

If no eligible TE policy exists, the system defaults to regular auto-bind behavior, using LDP, SR-ISIS, or any other lower priority configured tunnel type. Otherwise, the resolution fails.

If other transport tunnel options, like LDP or SR-ISIS, are available, they are used instead. If no alternative transport method is available, and the service or route would otherwise remain inactive, a default resolution procedure is applied.

Associating an SR-MPLS TE policy with a tag-set

An uncolored SR-MPLS TE policy can be configured with tag-sets (tag-set). The tag-set must have at least one tag value and can have a maximum of two values configured.

Configure a tag-set

In the following example, the tag-set (srl-tag-set) is configured with tag values of 2 and 4.
--{ * candidate shared default }--[ ]--
# info routing-policy tag-set srl-tag-set
    routing-policy {
        tag-set srl-tag-set {
            tag-value [
                2
                4
            ]
        }
    }

Associate an SR-MPLS TE policy with a tag-set

In the following example, the uncolored SR-MPLS TE policy (sr-mpls-te-policy) is associated with a tag-set (srl-tag-set). 
--{ * candidate shared default }--[ ]--
# info network-instance default traffic-engineering-policies policy sr-mpls-te-policy
    network-instance default {
        traffic-engineering-policies {
            policy sr-mpls-te-policy {
                tag-set srl-tag-set
            }
        }
    }