Segment Routing Policy (SR-MPLS TE Policy) is a tunneling technology developed based on SR. An SR-MPLS TE Policy is a set of candidate paths consisting of one or more segment lists, that is, segment ID (SID) lists. Each SID list identifies an end-to-end path from the source to the destination, instructing a device to forward traffic through the path rather than the shortest path computed using an IGP. The header of a packet steered into an SR-MPLS TE Policy is augmented with an ordered list of segments associated with that SR-MPLS TE Policy, so that other devices on the network can execute the instructions encapsulated into the list.
Headend: node where an SR-MPLS TE Policy is generated.
Color: extended community attribute of an SR-MPLS TE Policy. A BGP route can recurse to an SR-MPLS TE Policy if the route has the same color attribute as the policy.
Endpoint: destination address of an SR-MPLS TE Policy.
Color and endpoint information is added to an SR-MPLS TE Policy through configuration. In path computation, a forwarding path is computed based on the color attribute that meets SLA requirements. The headend steers traffic into an SR-MPLS TE Policy whose color and endpoint attributes match the color value and next-hop address in the associated route, respectively. The color attribute defines an application-level network SLA policy. This allows network paths to be planned based on specific SLA requirements for services, realizing service value in a refined manner and helping build new business models.
Figure 1 shows the SR-MPLS TE Policy model. One SR-MPLS TE Policy can contain multiple candidate paths with the preference attribute. The valid candidate path with the highest preference functions as the primary path of the SR-MPLS TE Policy, and the valid candidate path with the second highest preference functions as the hot-standby path.
A candidate path can contain multiple segment lists, each of which carries a Weight attribute. Each segment list is an explicit label stack that instructs a network device to forward packets. Multiple segment lists can work in load balancing mode.
+------------------+ | NLRI Length | 1 octet +------------------+ | Distinguisher | 4 octets +------------------+ | Policy Color | 4 octets +------------------+ | Endpoint | 4 or 16 octets +------------------+The meaning of each field is as follows:
The NLRI containing SR-MPLS TE Policy information is carried in a BGP Update message. The Update message must carry mandatory BGP attributes and can also carry any optional BGP attributes.
SR-MPLS TE Policy SAFI NLRI: <Distinguisher, Policy Color, Endpoint> Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR-MPLS TE Policy Binding SID Preference Priority Policy Name ... Segment List Weight Segment Segment ... ...The meaning of each field is as follows:
The Tunnel-Type TLV consists of the following sub-TLVs.
Preference Sub-TLV
Field |
Length |
Description |
---|---|---|
Type |
8 bits |
TLV type. |
Length |
8 bits |
Packet length. |
Flags |
8 bits |
Flags field. Currently, this field is not in use. |
Preference |
32 bits |
SR-MPLS TE Policy preference. |
Binding SID Sub-TLV
Field |
Length |
Description |
---|---|---|
Type |
8 bits |
TLV type. |
Length |
8 bits |
Packet length. It does not contain Type and Length fields. Available values are as follows:
|
Flags |
8 bits |
Flags field. The encoding format is as follows:
Figure 4 Flags field
![]()
|
Binding SID |
32 bits |
Binding SID of the SR-MPLS TE Policy. The following figure shows the format.
Figure 5 Binding SID
The Label field indicates a label that occupies 20 bits. The other field occupies 12 bits and is not in use currently.![]() |
Segment List Sub-TLV
Field |
Length |
Description |
---|---|---|
Type |
8 bits |
TLV type. |
Length |
16 bits |
Packet length. |
sub-TLVs |
Variable |
Sub-TLVs that contain an optional Weight sub-TLV and zero or more Segment sub-TLVs. The format of the Weight sub-TLV is as follows.
Figure 7 Weight sub-TLV
![]() The meaning of each field is as follows:
The format of the Segment sub-TLV is as follows.
Figure 8 Segment sub-TLV in the form of MPLS label
![]() The meaning of each field is as follows:
|
Policy Priority Sub-TLV
Field |
Length |
Description |
---|---|---|
Type |
8 bits |
TLV type. |
Length |
8 bits |
Packet length. It does not contain Type and Length fields. |
Priority |
8 bits |
SR-MPLS TE Policy priority. |
Extended Color Community
Field |
Length |
Description |
---|---|---|
CO |
8 bits |
Color-Only bits indicating that the Extended Color Community is used to steer traffic into an SR-MPLS TE Policy. The current value is 00, indicating that traffic can be steered into an SR-MPLS TE Policy only when the color value and next-hop address in the route match the color and endpoint attributes of the SR-MPLS TE Policy, respectively. |
Color Value |
32 bits |
Extended Color Community attribute value. |
If the actual forwarding path of an SR-MPLS TE Policy involves different physical link types, the links may support different MTUs. If this is the case, the headend must implement MTU control properly to prevent packets from being fragmented or discarded during transmission. Currently, no IGP/BGP-oriented MTU transmission or negotiation mechanism is available. You can configure MTUs for SR-MPLS TE Policies as needed.
SR-MPLS TE Policies support make-before-break (MBB). With the MBB function, a forwarder can establish a new segment list before removing the original one during a segment list update. In the establishment process, traffic is still forwarded through the original segment list, preventing packet loss upon a segment list switchover.
SR-MPLS TE Policies also support delayed deletion. With a segment list deletion delay being configured for an SR-MPLS TE Policy, if the SR-MPLS TE Policy has a segment list with a higher preference, a segment list switchover may be performed. In this case, the original segment list that is up can still be used and is deleted only when the delay expires. This prevents traffic interruptions during the segment list switchover.
Delayed deletion takes effect only for up segment lists (including backup segment lists) in an SR-MPLS TE Policy. If seamless bidirectional forwarding detection (SBFD) detects a segment list failure or does not obtain the segment list status, the segment list is considered invalid and then immediately deleted without any delay.