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.
- 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
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.
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
}
}
}
}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 CSFP 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
}
}
}
}
}
}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 |