SR-MPLS TE Policy

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.

An SR-MPLS TE Policy consists of the following parts:
  • 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.

SR-MPLS TE Policy Model

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.

Figure 1 SR-MPLS TE Policy model

BGP SR-MPLS TE Policy Extension

The BGP SR-MPLS TE Policy extension provides the following functions:
  1. Transmits the SR-MPLS TE Policy dynamically generated on a controller to a forwarder. This function is implemented through the newly defined BGP SR-MPLS TE Policy subsequent address family identifier (SAFI). By establishing a BGP SR-MPLS TE Policy address family-specific peer relationship between the controller and forwarder, this function enables the controller to deliver the SR-MPLS TE Policy to the forwarder, enhancing the capability of automatic SR-MPLS TE Policy deployment.
  2. Supports the new extended community attribute (color attribute) and transmits the attribute between BGP peers. This function is implemented through the BGP network layer reachability information (NLRI) extension.
The format of the NLRI used by a BGP SR-MPLS TE Policy address family is as follows:
+------------------+
|    NLRI Length   | 1 octet
+------------------+
|   Distinguisher  | 4 octets
+------------------+
|   Policy Color   | 4 octets
+------------------+
|     Endpoint     | 4 or 16 octets
+------------------+
The meaning of each field is as follows:
  • NLRI Length: length of the NLRI
  • Distinguisher: distinguisher of the NLRI
  • Policy Color: color value of the associated SR-MPLS TE Policy
  • Endpoint: endpoint information about the associated SR-MPLS TE Policy

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.

The content of an SR-MPLS TE Policy is encoded using the new Tunnel-Type TLV in tunnel encapsulation attributes. The encoding format is as follows:
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:
  • Binding SID: binding SID of an SR-MPLS TE Policy.
  • Preference: SR-MPLS TE Policy selection preference based on which SR-MPLS TE Policies are selected.
  • Priority: SR-MPLS TE Policy convergence priority based on which the sequence of SR-MPLS TE Policy re-computation is determined in the case of a topology change.
  • Policy Name: SR-MPLS TE Policy name.
  • Segment List: list of segments, which contains Weight attribute and segment information. One SR-MPLS TE Policy can contain multiple segment lists, and one segment list can contain multiple segments.

The Tunnel-Type TLV consists of the following sub-TLVs.

Preference Sub-TLV

Figure 2 shows the format of the Preference sub-TLV.
Figure 2 Preference Sub-TLV
Table 1 Fields in the 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

Figure 3 shows the format of the Binding SID sub-TLV.
Figure 3 Binding SID Sub-TLV
Table 2 Fields in the 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:
  • 2: No binding SID is contained.
  • 6: An IPv4 binding SID is contained.

Flags

8 bits

Flags field. The encoding format is as follows:
Figure 4 Flags field
  • S: S-Flag encoding the Specified-BSID-only behavior
  • I: I-Flag encoding the Drop Upon Invalid behavior

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

Figure 6 shows the format of the Segment List sub-TLV.
Figure 6 Segment List Sub-TLV
Table 3 Fields in the 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:
  • Type: TLV type of 8 bits
  • Length: TLV length of 8 bits
  • Flags: flags of 8 bits (not in use currently)
  • Weight: weight value of a segment list
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:
  • Type: TLV type of 8 bits
  • Length: TLV length of 8 bits
  • Flags: flags of 8 bits (not in use currently)
  • Label: label value of 24 bits
  • TC: traffic class of 3 bits
  • S: bottom of stack of 1 bit
  • TTL: TTL value of 8 bits

Policy Priority Sub-TLV

Figure 9 shows the format of the Policy Priority sub-TLV.
Figure 9 Policy Priority Sub-TLV
Table 4 Fields in the 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

Figure 10 shows the format of the Extended Color Community.
Figure 10 Extended Color Community
Table 5 Fields in the 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.

BGP itself does not generate SR-MPLS TE Policies. Instead, it receives SR-MPLS TE Policy NLRIs from a controller to generate SR-MPLS TE Policies. Upon reception of an SR-MPLS TE Policy NLRI, BGP must determine whether the NLRI is acceptable based on the following rules:
  • The SR-MPLS TE Policy NLRI must contain Distinguisher, Policy Color, and Endpoint attributes.
  • The Update message carrying the SR-MPLS TE Policy NLRI must have either the NO_ADVERTISE community or at least one route-target extended community in IPv4 address format.
  • The Update message carrying the SR-MPLS TE Policy NLRI must have one Tunnel Encapsulation Attribute.

MTU for SR-MPLS TE Policy

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.

MBB and Delayed Deletion for SR-MPLS TE Policies

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.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >