TE-Policy
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 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 requirement 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.
- 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. Note that in 7x50 SR OS routers, colored TE-Policy are referred to as SR policies. - 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.
Uncolored SR-MPLS TE-Policy
Uncolored SR-MPLS TE-policy refers to a type of TE-policy used in an SR-enabled network that does not use color to identify the policy. A single active LSP is represented as a segment list under the TE policy. An uncolored SR-MPLS TE LSP supports a primary path, with Fast Reroute (FRR) backup, and one or more secondary paths. A secondary path can be configured as standby.
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
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.
- 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
SR Linux supports default network instance TE policies for configuration of traffic engineered tunnels.
- Configure a static label range.
- Assign the static MPLS label range to the BSID.
- Define explicit path.
- Configure the TE features.
- Enable advertisement of IS-IS TE TLVs/sub-TLVs.
- Configure the SR-MPLS TE policy using the defined explicit path and BSID.
Configuring a static label range.
.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
}
}
}
}
}
}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
--{ + 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
- Define the static label range.
- 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
- Configure a static MPLS label range.
- 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.
- 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.
Paths containing explicit SID values can only be used by SR-MPLS TE policy tunnels.
Configuring explicit-path segment lists
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.
| 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.
keepalivedead-timerunknown-message-rateredelegation-timerstate-timerreport-path-constraintspeer
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.
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.
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.
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.
If the PCEP session to the PCE goes down, all delegated PCC-initiated LSPs have their state maintained in the PCC and are not timed out. The PCC continues to attempt to re-establish the PCEP session. When the PCEP session is re-established, the LSP database is synchronized with the PCE, and any LSP that went down since the last time the PCEP session was up has its path updated by the PCE.
The range of the parameterredelegation-timer 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
--{ 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.
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.
The peer parameter cannot be modified while the PCEP session is
operational.
--{ 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
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.
| 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.
- 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
-
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
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 parameterpce-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
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
}
}
}
}PCEP Associations
The PCEP Association Groups are used to reference TE-policy uncolored segment list constraints. PCEP Association Groups allow segment lists (LSPs) to share common information, such as common policies or common configuration parameters/constraints. SR Linux routers in the PCC role can reference a set of path constraints while making a path computation request to PCE, instead of passing individual constraints one by one.
The PCEP ASSOCIATION object defines an Association ID and an Association Type to signal any type of association between LSPs (as defined in RFC 8697). Association groups are identified by a tuple consisting of an Association ID, Association Type, and Association Source. Association groups offer a disaggregated approach to specifying association, where the Association ID is equivalent to the path group ID, and the tuple (Association ID, Association Type, Association Source) is equivalent to the path profile ID. The tuple is the key to the association group. Both IPv4 and IPv6 PCEP control planes support signaling of the Association IDs. The PCE uses the Association ID to reference a path profile.
The following are the SR Linux supported PCEP association types:
- Generic association object with Association ID and Association type, defined in RFC 8697
- Disjoint Association Type, as defined in RFC 8800, is used to signal path diversity constraints
- Policy Association Type, as defined in RFC 9005, is used to signal PCE policies for associating policies
PCE association of segment lists
local-cspf or the
pce computed segment lists (LSPs), enabling the following
behavior:- Primary, standby, and secondary paths can have different PCE association policies.
- PCE-computed segment lists use PCE association policies as constraints in computation requests and reports.
- In the local-CSPF computed segment list with
pce-control/pce-reportconfigured, the association information is shared with the PCE server in reports. - In the local-CSPF computed segment list without
pce-controlconfigured, the PCE-association policies are ignored. - In IP-to-label and explicit labels, the PCE association policies cannot be configured.
PCEP extensions for LSP association
The PCEP extensions for LSP sets provide a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping enables the definition of associations between sets of LSPs or between a set of LSPs and a set of attributes.
The PCC can signal one or more ASSOCIATION objects for each Association Type based on the configuration of the PCC-initiated LSP. MPLS passes this information to the PCC module. The PCC can include the ASSOCIATION object and its TLVs in any of the following PCEP messages: PCReq, PCRpt. The PCE may reflect the same ASSOCIATION objects and TLVs in any of the following PCEP messages: PCRep, PCUpd.
The following table displays the base ASSOCIATION object.
| Object | Message |
|---|---|
|
ASSOCIATION object |
PCRpt, PCReq, PCRep, PCInitiate, PCUpd |
The following are the PCEP extensions for IPv4 LSPs:
| Value | Name | Object-type | Reference | |
|---|---|---|---|---|
| 40 | ASSOCIATION | 0: Reserved | 1: IPv4 | RFC 8697 |
| Value | Meaning | Reference |
|---|---|---|
| 29 | Operator-configured Association Range | RFC 8697 |
| 30 | Global Association Source | |
| 31 | Extended Association ID |
The following are the PCEP extensions for IPv6 LSPs:
| Value | Name | Object-type | Reference | |
|---|---|---|---|---|
| 40 | ASSOCIATION | 2: Reserved | 2: IPv6 | RFC 8697 |
| Type | Name | Reference |
|---|---|---|
| 1 | Path Protection Association | RFC 8745 |
| 38 | Path Protection Association Group TLV |
| Bit | Name | Reference |
|---|---|---|
| 31 | P - PROTECTION-LSP | RFC 8745 |
| 30 | S - SECONDARY-LSP | |
| 6-29 | Unassigned | |
| 0-5 | Protection Type Flags |
Diversity Association Group
The disjoint association signals path diversity constraints using the Disjoint Association Type defined in RFC 8800. The Association ID for the diversity type supports the user-configured mode of operation. The ID value is interpreted as a global value independent of the IP address of the PCC or PCE node that is used to associate segment lists (LSPs).
The DISJOINTNESS-CONFIGURATION TLV is used to describe the diversity parameters requested for the set of segment lists. The PCE uses the DISJOINTNESS-STATUS TLV to convey the status of the diversity parameters after the path computation. The same flags indicate whether any of the parameters were met by the returned path.
| Type | Name | Reference |
|---|---|---|
| 46 | DISJOINTNESS-CONFIGURATION | RFC 8745 |
| 47 | DISJOINTNESS-STATUS |
| Code point | Name | Reference |
|---|---|---|
| 15 | Minimize the number of Shared Links (MSL) | RFC 8800 |
| 16 | Minimize the number of Shared SRLGs (MSS) | |
| 17 | Minimize the number of Shared Nodes (MSN) |
| Code point | Name | Reference |
|---|---|---|
| 11 | Disjoint path not found | RFC 8800 |
| 10 | Requested disjoint computation not supported |
Configuring diversity association parameters
You can configure the diversity association parameters in network-instance* [name] protocols pcep!+ pcc pce-associations diversity* context.
- association-id- a value identifying the association group.
- association-source - the source of the association, which can be specified as either an IPv4 or IPv6 address.
- disjointness-reference – indicates whether this LSP path is the reference path for the disjoint set of paths. When set, the PCE must first compute the path of this LSP and then apply the requested disjointness type to calculate the path of all other paths in the same diversity association ID.
- disjointness-type – specifies the disjointness type, either strict or loose.
- diversity-type – defines the type of diversity, which can be link, node, srlg-link, or srlg-node. Configuration of this parameter is mandatory. If this parameter is not configured, the system does not validate the association configuration.
--{ +* candidate shared default }--[ ]--
# info network-instance default protocols pcep pcc pce-associations diversity srl_diversity_association
network-instance default {
protocols {
pcep {
pcc {
pce-associations {
diversity srl_diversity_association {
association-id 10
association-source 10.0.0.3
disjointness-reference true
disjointness-type strict
diversity-type node
}
}
}
}
}
}
Policy Association Group
The policy association signals policy constraints using the Policy Association Type defined in RFC 9005.
The Association ID is a globally unique identifier within a specific domain, configured by the operator, and is independent of the source address. Multiple PCC nodes can use the same Association ID in the domain to refer to the same policy or path profile. When a PCC node sends a request to the PCE, the PCE uses the Association ID to look up the corresponding path profile, regardless of the source address of the PCC node. As a result, multiple PCC nodes in the same domain can use the same Association ID to signal different LSPs, and the PCE applies the same path profile to all of them.
| Value | Name | Reference |
|---|---|---|
| 3 | Policy Association | RFC 9005 |
| Value | Meaning | Reference |
|---|---|---|
| 48 | POLICY-PARAMETERS-TLV | RFC 9005 |
Configuring PCE association policy
You can configure the PCE association policy type using the command,
network-instance* [name] protocols pcep! pcc pce-associations
policy*. The association ID (association-id) is the
identifier for the association group and the association source
(association-source) specifies the source of the association
and can be specified as either an IPv4 or IPv6 address.
--{ +* candidate shared default }--[ ]--
# info network-instance default protocols pcep pcc pce-associations policy srl_test_association
network-instance default {
protocols {
pcep {
pcc {
pce-associations {
policy srl_test_association {
association-id 10
association-source 10.0.0.3
}
}
}
}
}
}PCEP ASSOCIATION object error handling
If the ASSOCIATION objects in the PCE do not match the ones sent by PCC in the PCReq or PCRpt messages, the PCC returns an error.
The router handles consistency between the association group configuration for a set of LSPs on a specific PCC. That is, an association group can only have one set of parameters within an association (for example, Diversity Type and Disjointness Type), which ensures that LSPs added to the same association group do not have inconsistent parameters. However, LSPs originating on different PCCs can be added to the same association group, but those association groups have different parameters configured on the different PCCs. In that case, only the NSP can detect parameter inconsistencies.
For LSPs that are delegated and have inconsistent association parameters, the NSP sends a PCUpd down message followed by a PCErr message with the appropriate error message. This causes the affected LSPs to go operationally down. For non-delegated LSPs, the NSP sends a PCErr message.
If an LSP is added to an association group that has inconsistent parameters when compared with the same association group to which operationally up LSPs are already assigned, the NSP only registers an error on the new LSP and leaves the existing LSPs undisturbed.
| Error type | Meaning | Error value | Reference |
|---|---|---|---|
| 26 | Association Error | 0: Unassigned | RFC 8697 |
| 1: Association Type is not supported | |||
| 2: Too many LSPs in the association group | |||
| 3: Too many association groups | |||
| 4: Association unknown | |||
| 5: Operator-configured association information mismatch | |||
| 6: Association information mismatch | |||
| 7: Cannot join the association group | |||
| 8: Association ID not in range |
| Error type | Meaning | Error value | Reference |
|---|---|---|---|
| 26 | Association error | ||
| - | - | 9: Tunnel ID or endpoints mismatch for Path Protection Association | |
| 10: Attempt to add another working/protection LSP for Path Protection Association | |||
| 11: Protection type is not supported |
| Error type | Meaning | Error value | Reference |
|---|---|---|---|
| 6 | Mandatory Object missing | - | RFC 5440 |
| - | - | 15: DISJOINTNESS-CONFIGURATION TLV missing | RFC 8800 |
| 10 | Reception of an invalid object | - | RFC 5440 |
| - | - | 32: Incompatible OF code | RFC 8800 |
| Error type | Meaning | Error value | Reference |
|---|---|---|---|
| 26 | Association Error | - | RFC 8697 |
| - | - | 12: Not expecting policy parameters | RFC 9005 |
| - | Reception of an invalid object | 13: Unacceptable policy parameters | RFC 9005 |
Local CSPF (Constrained Shortest Path First) based path computation
TE policy path computation using local CSPF is applicable in single-level IS-IS instances 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-protectionwithin thenetwork-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraintsis set tomandatedvalue. -
only includes unprotected adjacencies - Here, the parameter
local-sr-protectionwithin thenetwork-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraintsis set tononevalue. -
can include both protected and unprotected adjacencies - Here, the parameter
local-sr-protectionwithin thenetwork-instance traffic-engineering-policies policy segment-list dynamic path-algorithm local-cspf te-constraintsis set topreferredvalue. This is a default option.
Configuring CSPF for path computation
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
}
}
}
}Local CSPF path computation using delay metric
A TE-policy segment list used by real-time and delay-sensitive user and control traffic
can have its path computed
by
local CSPF
based
on the delay metric. To use the delay metric, set the metric type
(metric-type) to delay under the
network-instance*
[name] traffic-engineering-policies!+ policy* [policy-name] segment-list*
[segment-list-index] dynamic! te-constraints
context.
When the delay metric is configured, the node selects the path with the
lowest end-to-end delay from the ingress router performing local-cspf
computation to the egress label edge router (eLER).
The delay metric values reported by all subinterfaces along the path are
accumulated and compared against the configured delay metric limit. The default setting
for delay-metric-limit parameter is no-limit and is
configured under the network-instance* [name] traffic-engineering-policies!+
policy* [policy-name] segment-list* [segment-list-index] dynamic! te-constraints
delay-metric-limit context. The total delay of the calculated path must
stay within this limit.
The TE-policy segment list is only resignaled after a failure, timer expiration, or similar events and is not based on changes to the delay metric.
During path recalculation, the latest delay values from the subinterfaces are used. The delay measurements are relayed to the traffic engineering database (TEDB) based on the following sequence of events: TWAMP, STAMP, or similar tools measure delay and publish to the internal IP module, which relays it via IGP (ISIS in this case). A new delay value learnt by a PE is published to the TE database in a manner comparable to other attributes. SR-TE subsequently queries the TEDB to compute an optimal path.
Configuring local CSPF path computation using delay metric
To configure local-cspfpath computation
using
delay metric, you must, set the parameter
metric-type value within the network-instance* [name]
traffic-engineering-policies! policy* [policy-name] segment-list*
[segment-list-index] dynamic! te-constraints context to
delay.
--{ +* candidate shared default }--[ ]--
info network-instance default traffic-engineering-policies policy srl_test_policy
network-instance default {
traffic-engineering-policies {
policy srl_test_policy {
policy-type sr-mpls-uncolored
endpoint 10.0.0.2
segment-list 3 {
segment-list-type primary
dynamic {
path-algorithm local-cspf
te-constraints {
metric-type delay
delay-metric-limit 30
}
}
}
}
}
}Path computation fallback
The SR Linux router supports using a local path computation as a fallback for PCC-initiated SR-MPLS TE path computations. The fallback mechanism is triggered when the PCC notifies the MPLS of PCEP session failure or when the redelegation timer expires, and all configured TE-policy segment lists signal overload, preventing redelegation. However, the fallback mechanism is not triggered when the PCC is administratively down or has not yet been configured.
PCE-independent protection mechanisms such as LFA (Loop-Free Alternate) and ti-LFA (Topology-Independent LFA) continue to be supported. These protection mechanisms are managed by the node and do not rely on the PCE. Additionally, primary to standby TE-policy segment list path switching and vice versa remains supported. This means the node can switch between primary and standby paths even when the PCE is unavailable.
You can configure the fallback path algorithm by setting the parameter,
fallback-path-algorithm in the network-instance
traffic-engineering-policies policy segment-list dynamic context.
When the PCEP session recovers and at least one configured PCE does not have the overload bit set, the PCC notifies MPLS that the PCE is enabled, indicating that the PCC is ready to reuse the PCE for path computations.
| Primary path algorithm (path-algorithm) | Secondary path algorithm (path-algorithm) | Fallback path algorithm methodfallback-path-algorithm | PCE state | Behaviour |
|---|---|---|---|---|
| pce | local-cspf | Not configured | PCE is operational | Upon primary path falure, the secondary path is attempted based on the local CSPF computed path. |
| pce | local-cspf | local-cspf | PCE is in a down state | The primary path directly attempts a fallback computed path. Only if this fails is the secondary path attempted. |
| pce | local-cspf | local-cspf | PCE state is unknown (start-up phase) | The primary path first attempts the PCE-based path computation. If PCE fails (for example, timeout), the secondary path is attempted, skipping the fallback path computation. |
network-instance default
traffic-engineering-policies.policy.segment-list.pce-control is not
configured, the PCC waits for specific events to initiate a return to PCE-based path
computation. These events include:- expiry of the re-optimization timer
- a manual resignal
- expiry of the retry timer, for instance, after a previous path computation failure
- any configuration changes to the segment list ( the sequence of segments that constitute the LSP)
In an active stateful LSP, where the pce-control value
is
within the network-instance default
traffic-engineering-policies.policy.segment-list
,
PCC notifies MPLS that the PCE is enabled indicating that the PCC is ready to reuse the
PCE for path computations.
Configuring fallback path algorithm
You can configure the fallback path algorithm by setting the parameter,
fallback-path-algorithm in the
network-instance.traffic-engineering-policies.policy.segment-list.dynamic
context.
The fallback path algorithm parameter fallback-path-algorithm can be configured to local-cspf or none.
network-instance.traffic-engineering-policies.policy.segment-list.dynamic.path-algorithm)
is set to pce.The following example configures the fallback-path-algorithm with the local-cspf value:
--{ +* candidate shared default }--[ ]--
# info network-instance default traffic-engineering-policies policy srl_te_policy
network-instance default {
traffic-engineering-policies {
policy srl_te_policy {
segment-list 5 {
dynamic {
path-algorithm pce
fallback-path-algorithm local-cspf
}
}
}
}
}Uncolored SR-MPLS TE-policy tags
Tags (tag-set command) 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 tags. The
tag constraint for a 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. Services and IP shortcuts use tags to resolve the best transport tunnel. Tunnel resolution configuration can dictate a specific tag or tags; Resolution may be based on the preference of a tag or tags without mandating a tag match. Using tags ensures services and shortcuts resolve to tunnels that match certain criteria, such as hop count, delay, or something similar. Unless a mandatory keyword is used in resolution, 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,the service or route would remain inactive.
Tag-sets enable the system to resolve to specific transport tunnels (or groups of eligible transport tunnels) for BGP routes for applications such as BGP labeled unicast, VPRN, or EVPN. Additionally, tag-sets specify a finer level of granularity on the next-hop or the far-end prefix associated with a BGP labeled unicast route or unlabeled BGP route shortcut tunnels.
Associating an SR-MPLS TE policy with a tag-set
An uncolored SR-MPLS TE policy can be configured with tag-sets. 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
}
}
}Associating a tag-set with BGP next-hop resolution
By associating a tag-set, you can constrain the tunnels used by the system for resolution of BGP next-hops or prefixes and BGP labeled unicast routes.
--{ * candidate shared default }--[ ]--
# info routing-policy policy srl-test-policy default-action bgp
routing-policy {
policy srl-test-policy {
default-action {
bgp {
next-hop-resolution {
set-tag-set srl-tag-set
}
}
}
}
}Configuring a tag as mandatory for BGP route resolution
Uncolored SR-MPLS TE-policy tag match criteria are user configurable and can be set to mandatory, in which case an exact match is required for the resolution of a network instance or a route to a TE Policy. Routing policy configures tag-set and match is via uncolored SR-MPLS TE-policy tag. Configuring SR-MPLS TE-policy tags allows for a more detailed level of granularity when determining the next hop associated with a BGP-labelled unicast route, ensuring that only routes meeting specific policy criteria are selected.
The following configuration shows how to make the uncolored SR-MPLS TE-policy tag mandatory for BGP route resolution. The next-hop resolution uses IPv4 next-hops, and the allowed tunnel type is an SR-MPLS uncolored TE-policy.
--{ * candidate shared default }--[ ]--
# info network-instance default protocols bgp
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 78
afi-safi l3vpn-ipv4-unicast {
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
te-policy-sr-mpls-uncolored
]
selection-attributes {
tag {
mandatory true
}
}
}
}
}
}
}
}
}
}Uncolored SR-MPLS TE path failure codes
The table below lists the uncolored SR-MPLS TE path failure codes and their meanings.
| Failure codes | Description |
|---|---|
| path-computation-request-timeout | Path computation request timed out |
| path-computation-no-route | No valid route is returned for path computation request |
| no-resources-available | Required resources are depleted, not enough resources to establish the requested segment-list |
| path-computation-bad-node | Path computation failure due to a resolution issue of one or more of the hops |
| path-computation-routing-loop | Path computation failure due to routing loop |
| unknown | Segment-list is down because of unknown reason |
| path-computation-no-route-owner | Path computation failure as none of the IGP instances had a valid route to one of the hops |
| path-computation-hop-limit-exceeded | Path computation failure due to hop limit. No path within the hop limit constraint configured |
| srlg-not-disjoint | SRLG is shared with primary segment-list and there is no other viable path with dispersed SRLG |
| srlg-not-computed-path | SRLG is not applicable, as primary segment-list has no applicable SRLG for path computation |
| srlg-primary-segment-list-down | SRLG is not applicable, as primary segment-list is down |
| unresolved-first-segment | The router is unable to resolve the first SID (MPLS label value) into one or more outgoing interfaces and next-hops |
| fib-add-pending | Segment-list is kept down, when adding next-hop into the FIB |
| fib-add-failed | FIB has failed to add the next-hop group. Next-hop group represents a group of next-hops for valid segment-lists under a TE-policy |
| maximum-label-stack-depth-exceeded | The resolution of the named path requires more labels than supported by the datapath |
| pce-update-with-empty-ero | PCE update has empty Explicit Route Object (EROs) |
| segment-list-admin-down | Segment-list is administratively down |
| ipv4-hops-in-ipv6-path | IPv4 and IPv6 hops are mixed in explicit path |
| ipv6-hops-in-ipv4-path | IPv6 and IPv4 hops are mixed in explicit path |
| sid-hops-in-ip-path | SID (label-based) and IP hops are mixed in explicit path |
| sid-hops-with-invalid-path-computation | SID hops (labeled hops) with path computation local-cspf/pcep is not allowed |
| policy-down | Traffic engineering policy is down |
| pce-association-conflict | PCE-association conflict |
| retry-on-config-change | Segment-list retry attempted due to config change |
| clear-command | Segment-list retry attempted due to manual clear command |
| secondary-segment-list | Secondary type segment-list, primary is always preferred when available |
| bfd-down | BFD is reported down |
| te-rtr-id-not-configured | TE router ID config is missing |
| pce-down | PCE is unavailable |
| pce-error | PCE response has error or timed-out |
| pcc-error | PCC responded with error |
| delay-metric-limit-exceeded | Segment-list delay metric limit exceeded |
Colored TE policy
RFC 9256 describes the concept of a colored TE policy. This policy describes a source-routed path from a head-end router to an endpoint, and it determines which traffic flows should be steered through that path. A colored TE-Policy for a specific head-end router can be statically configured on that router or advertised to it as a BGP route.
A colored TE policy is identified by the tuple of <head-end, color, endpoint>. Each colored TE policy is associated with a set of one or more candidate paths, one of which is selected to implement the colored TE policy and is installed in the data plane. The colored TE policies have additional attributes, such as preferences, binding SIDs, and segment lists, which are used in the policy selection and implementation.
SR Linux colored TE policy supports 32 programmed segment lists per candidate path. Each segment list can be assigned a weight to influence its share of traffic compared to other segment lists of the same policy.
Weighted ECMP across segment lists of a given candidate path is not qualified despite any valid weight value programmed. Similarly, datapath ECMP resources are allocated in line with the weights.
Basic concepts
Head-end
The head-end is an IP address that identifies the router at the source of the source-routed path.
Endpoint
The endpoint is an IP address that identifies the router that is the destination of the source-routed path.
Color
Color is a label assigned to a set of traffic flows or routes. Color is a property that determines the sets of traffic flows that the policy should steer. It is a mandatory parameter for a colored TE policy.
Discriminator
A discriminator is a unique value assigned to each policy to differentiate between multiple policies with the same color. It is a mandatory parameter for both local and non-local policies.
Candidate paths
A colored TE policy can define one or multiple candidate paths. Each candidate path comprises a set of one or more segment lists that load-balance the traffic toward the endpoint. The traffic distribution is based on each segment list's relative weights. Each candidate path has a preference value. For a specific (head-end, endpoint, and color) tuple, the candidate path with the highest preference is selected as the active path and installed into the datapath. A colored TE policy can contain multiple candidate paths, but only one is chosen as the best and active path. The control plane retains the lower preference candidate paths so the next best one can take over if the active path becomes unavailable.
Binding SID (BSID)
Each candidate path can have a binding SID (BSID), as per RFC 9256. The SR Linux implementation requires every signaled and configured candidate path to have a BSID. The BSID opaquely represents the entire candidate path to upstream routers.
The binding SID must be an available label (MPLS) in the reserved label block associated with colored TE policies; otherwise, the policy cannot be activated.
Typically, all candidate paths within a colored SR TE-Policy should be assigned the same BSID as described in RFC 9256, but this is not enforced or guaranteed.
Best path selection process
-
Candidate paths under a TE policy are validated and ranked based on the
following criteria, in strict order of priority:
- Candidate path preference: Higher values are preferred.
- Protocol origin: Higher values are preferred.
- Originator (ASN, Node-address): Lower values are preferred.
- Discriminator: Higher values are preferred.
- After sorting the candidate paths based on the defined priority criteria, each path is evaluated sequentially. The first path with a successful BSID allocation is selected as the best path.
- The selected path from step 2 is added to the tunnel table.
Statically-configured colored TE policies
Colored TE policies can be statically configured locally on a head-end node or dynamically learned by a head-end node through the BGP colored TE policy route.
When the head-end parameter in network-instance* [name]
traffic-engineering-policies!+ policy* [policy-name] color? is set to
local, a static policy is local, and when it is set to an IP
address, it is non-local.
Configuring a static local colored TE policy
network-instance* [name] traffic-engineering-policies!+ policy*
[policy-name] color? context.- Configure a static label range.
- Assign the static MPLS label range to the BSID.
- Configure the local colored TE policy using the defined BSID.
Configuring a static label range.
system.mpls.label-ranges to configure the static
label range. All participating routers within the SR domain use the static label
range. 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
}
}
}Configuring a static local colored TE policy
The following example configures a static local colored TE policy
(srl_local_colored_policy) using the defined BSID. The
MPLS label value 16001 falls within the defined MPLS label range
(srl-static-label-range) and serves as the BSID for the static
local colored TE policy.
--{ + candidate shared default }--[ ]--
# info network-instance default traffic-engineering-policies policy srl_local_colored_policy
network-instance default {
traffic-engineering-policies {
policy srl_local_colored_policy {
policy-type sr-mpls-colored
color 600
endpoint 192.0.2.5
discriminator 78
head-end local
binding-sid {
mpls-label 16001
}
}
}
}Configuring a static non-local colored TE policy
network-instance* [name] traffic-engineering-policies!+ policy*
[policy-name] color? context.--{ + candidate shared default }--[ ]--
# info network-instance default traffic-engineering-policies policy srl_non_local_colored_policy
network-instance default {
traffic-engineering-policies {
policy srl_non_local_colored_policy {
policy-type sr-mpls-colored
color 600
endpoint 192.0.2.5
discriminator 78
head-end 10.10.10.1
binding-sid {
mpls-label 16001
}
}
}
}BGP signaled colored TE policy
MP-BGP (Multi-Protocol BGP) is used to advertise colored TE policies between routers. A controller or another BGP speaker can instruct a BGP edge router to steer traffic according to a specific colored TE policy; it can advertise the colored TE policy candidate path through MP-BGP.
The Network Layer Reachability Information (NLRI) within the UPDATE messages of the AFI/SAFIs identifies a colored TE policy candidate path. The NLRI format of this MP-BGP route is described in draft-ietf-idr-sr-policy-safi-13.
The colored TE policy information is carried using the AFI/SAFI combination of AFI=1, SAFI=73 for IPv4 destinations and AFI=2, SAFI=73 for IPv6 destinations.
SR Linux AFI-SAFI name for
IPv4 is srte-policy-ipv4, and the AFI-SAFI name for IPv6 is
srte-policy-ipv6.
To exchange routes that belong to the (AFI=1, SAFI=73) or (AFI=2, SAFI=73) address family
with a specific BGP neighbor, the family configuration for that neighbor must include
the srte-policy-ipv4 or srte-policy-ipv6 AFI-SAFI
names.
When BGP router receives a srte-policy-ipv4 route (AFI=1, SAFI=73) or a
srte-policy-ipv6 (AFI=2, SAFI=73) from a peer, it runs its standard
BGP best path selection algorithm to choose the best path for each NLRI combination of
discriminator, endpoint, and color. If the best path is targeted to this router as the
head-end, BGP extracts the colored TE policy details into the local database.
Multiple candidate paths can exist for a colored TE policy, although only one path can be selected as the best path of the colored TE policy and become the active path. If several candidate paths of the same colored TE policy (endpoint, color) are advertised via BGP colored TE policy to the same head-end, unique discriminators for each NLRI are recommended. For information about BGP colored TE policy traffic steering, see Colored TE policy traffic steering.
A BGP colored TE policy route is considered malformed if it does not have at least one segment list TLV, which triggers error-handling procedures such as session reset or treat-as-withdraw.
Importing a static non-local colored TE policy
SR Linux supports the origination of non-local colored TE policy routes configured as static candidate paths. Static non-local policies are signaled as BGP NLRIs.
import-static to true using the
network-instance.protocols.bgp.afi-safi.srte-policy-ipv4
command. Similarly, to add non-local IPv6-endpoint static candidate paths that are
maintained by the SR policy manager to the BGP RIB-IN for AFI=2/SAFI=73 routes, set
the parameter, import-static to true using the
network-instance.protocols.bgp.afi-safi.srte-policy-ipv6
command.- If the head-end address is IPv4, it is encoded inside an IPv4-address-specific route-target extended community (type/subtype 0x4102).
- If the head-end address is IPv6, it is encoded inside an IPv6-address-specific route-target extended community (path attribute 25, extended community type/subtype 0x0002).
Importing non-local colored TE policy (IPv4)
--{ + candidate shared default }--[ ]--
# info network-instance default protocols bgp afi-safi ipv4-unicast srte-policy-ipv4 import-static
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
srte-policy-ipv4 {
import-static true
}
}
}
}
}Importing non-local colored TE policy (IPv6)
--{ + candidate shared default }--[ ]--
# info network-instance default protocols bgp afi-safi ipv6-unicast srte-policy-ipv6 import-static
network-instance default {
protocols {
bgp {
afi-safi ipv6-unicast {
srte-policy-ipv6 {
import-static true
}
}
}
}
}Colored TE policy encoding using TLV
When a BGP router advertises a colored TE policy candidate path, the specific details are encoded within the Tunnel Encapsulation Attributes as defined in RFC 9012, using a Tunnel-Type called SR Policy Type with codepoint 15.
The following sub-TLVs are defined for use with TLV 15:
- Preference subTLV (type 12) - optional, encodes 4-byte value
- Binding SID subTLV type (type 13) - optional, encodes MPLS label value
- Segment-List subTLV (type 128) - optional, can be repeated multiple times, encodes a
segment list as collection of subsubTLVs:
- Weight subsubTLV (type 9) - optional, encodes 4-byte value; zero is invalid
- Segment subsubTLV (type dependent on Segment Type) - optional, encodes a single segment in a segment-list
- Explicit Null Label Policy subTLV (type 14) - currently not supported in SR Linux
- Policy Priority subTLV (type 15) - currently not supported in SR Linux
- Policy Candidate Path Name subTLV (type 129)
- Policy Name subTLV (type 130) - currently not supported in SR Linux
Colored TE policy traffic steering
When a BGP router that supports the new AFI-SAFI receives a BGP message encoding a colored TE policy candidate path, it follows these steps to steer traffic:
- The router applies the BGP import policy to process the received candidate path.
- The router runs the BGP best path selection algorithm to choose one best BGP path for each NLRI combination of <discriminator, color, endpoint>. See Validating colored TE policy routes.
- If the selected best path for a particular <discriminator, color, endpoint> tuple is targeted to this router as head-end, BGP extracts the candidate path details and forwards them to an SR policy manager. The SR policy manager maintains a lists all candidate paths from various sources, including static configuration, and BGP.
- The SR policy manager evaluates the validity of each candidate path and updates its status as conditions change. For information on validation process, see Validating colored TE policy routes.
- For each <color, endpoint>, the SR policy manager selects the highest-preference valid candidate path for installation into the data path. If multiple valid candidate paths have the same best preference, tie-breaking rules determine the selection.
-
The SR policy manager programs the selected candidate path from the previous
step into the datapath, resulting in the creation of the following entries:
- An Incoming Label Map (ILM) entry that matches the BSID and binds it to a Next Hop Group (NHG) containing one Next-Hop Label Forwarding Entry (NHLFE) for each of the valid segment lists.
- A colored tunnel entry that binds to an NHG containing one NHLFE for each of the valid segment-lists. The color of the tunnel matches the <color> of the active candidate path from which it is derived.
Validating colored TE policy routes
BGP selects the best path for every TE policy NLRI, keyed by the combination of <discriminator, color, endpoint>. The best path selection algorithm uses the normal BGP rules. BGP excludes statically configured TE policies when selecting the best path.
None of the Tunnel Encapsulation attribute values are used for best path selection.
If the best path is targeted to this router as the head-end, BGP extracts the colored TE policy details into the SR policy manager. A BGP colored TE- Policy route is deemed to be targeted to this router as the head-end if either:
-
it has no route-target extended community and a NO-ADVERTISE standard community
-
it has an IPv4 address-specific route-target extended community with an IPv4 address matching the system IPv4 address of this router
Validation process
After the candidate path is passed to the SR policy manager, it validates the candidate path. The SR policy manager determines whether the candidate path is valid or invalid and continuously updates as conditions change.
- It is not empty (0 segments).
- BSID is present and is within the expected range of MPLS labels.
- If weight is specified, it is non-zero (zero-weight paths are not valid).
- It consists only of type A segments, and the number of segments does not exceed datapath capabilities.
- The SR policy manager performs path resolution for the first SID in one or more outgoing interfaces and next-hops.
- When selecting the candidate path for each <color, endpoint>, the
following criteria are applied in order of priority:
- Highest preference: If no preference sub-TLV is present in the BGP route, a default preference value of 100 is used.
-
Highest protocol origin: The order of preference is:
- Static (30)
- BGP (20)
-
Lowest originator value: This is a 160-bit value created by combining the origin AS and the 128-bit node address. The origin AS is the first AS in the AS_PATH of the route (or the peer AS if the AS_PATH is empty), and the node address is the IPv4 or IPv6 address of the originator, extracted from BGP Originator ID (RFC4456) or Router ID of the peer (from its OPEN message).
- Highest discriminator value
Colored TE policy data forwarding
- An MPLS packet is received with a top label that matches an ILM entry programmed in step 6a. In this case, the binding SID label is popped, and the next forwarding step operates on an MPLS packet with N new labels pushed on top of the stack; the N labels correspond to the NHLFE/segment list selected by the ECMP load-balancing hash algorithm. The packet is forwarded out of the box according to the ILM entry for the top label of the new label stack. Depending on the SID instruction, this ILM entry can pop or swap the top label.
- An IP packet is received and matches a BGP route with one or more of its next-hops resolved by a colored tunnel entry as programmed in step 6b. Assuming that the ECMP load-balancing hash algorithm selects one of these next hops, the forwarding pipeline is given an MPLS packet with N labels corresponding to the selected NHLFE/segment list. The packet is forwarded out of the box according to the ILM entry for the top label of the new label stack. Depending on the SID instruction, this ILM entry can pop or swap the top label.
- An IP packet or Ethernet frame is received in the context of an IP-VRF or
MAC-VRF and matches a VPN route that has one or more of its next-hops resolved
by a colored tunnel entry as programmed in step 6b. Assuming that the ECMP load-balancing hash algorithm
selects one of these next-hops, the forwarding pipeline is given an MPLS packet
with N labels corresponding to the selected NHLFE/segment list. The packet is
forwarded out of the box according to the ILM entry for the top label of the new
label stack. Depending on the SID instruction, this ILM entry can pop or swap
the top label.Note:
Weighted ECMP across segment list within a candidate path is not supported, even if valid weight values are programmed. The datapath ECMP resources are allocated according to the specified weights.
Next-hop address encoding for colored TE policy
- When
next-hop-selfis enabled for a BGP session with peer-X, the BGP next-hop address in the RIB-IN is overwritten with the local IP address associated with the session. The resulting BGP next-hop address can be either an IPv4 or IPv6 address, depending on the type of transport peer used for the session. - When
next-hop-selfis not enabled for a session with an IBGP peer (peer-X), the next-hop address is not modified and remains the same as the original next-hop address. - When
next-hop-selfis not enabled for a session with an EBGP peer (peer-X), the next-hop address is not modified. It remains the same as the original next-hop address, which has been overwritten with the local IP address associated with the session. The resulting BGP next-hop address can be either an IPv4 or IPv6 address, depending on the type of transport peer used for the session.