No relevant resource is found in the selected language.
MENU
Support Documentation
NE20E-S V800R012C00SPC300 Feature Description - Segment Routing 04
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
SR-MPLS TE Policy

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 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 2-81 shows the SR-MPLS TE Policy model. One SR-MPLS TE Policy may contain multiple candidate paths with 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. Currently, this attribute cannot be set and is defaulted to 1. A segment list is an explicit label stack that instructs a network device to forward packets, and multiple segment lists can work in load balancing mode.

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

Field

Length

Description

Type

8 bits

TLV type.

Length

8 bits

Packet length.

Flags

8 bits

Flags bit. Currently, this field is not in use.

Preference

32 bits

SR-MPLS TE Policy preference.

Binding SID Sub-TLV

Figure 2-83 shows the format of the Binding SID sub-TLV.
Figure 2-83 Binding SID sub-TLV
Table 2-29 Fields in the Binding SID sub-TLV

Field

Length

Description

Type

8 bits

TLV type.

Length

8 bits
Packet length that 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 bit.
Figure 2-84 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.

Figure 2-85 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 2-86 shows the format of the Segment List sub-TLV.
Figure 2-86 Segment List sub-TLV
Table 2-30 Fields in the Segment List sub-TLV

Field

Length

Description

Type

8 bits

TLV type.

Length

16 bits

Packet length.

sub-TLVs

Variable length

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 2-87 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 2-88 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 2-89 shows the format of the Policy Priority sub-TLV.
Figure 2-89 Policy Priority sub-TLV
Table 2-31 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 2-90 shows the format of the Extended Color Community.
Figure 2-90 Extended Color Community
Table 2-32 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 Policies. Instead, it receives NLRIs containing SR-MPLS TE Policy information from a controller to generate SR Policies. Upon reception of an NLRI, BGP must determine whether the NLRI is acceptable based on the following rules:
  • The NLRI must contain Distinguisher, Policy Color, and Endpoint attributes.
  • The Update message carrying the 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 NLRI must have one Tunnel Encapsulation Attribute.

SR-MPLS TE Policy MTU

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 Policies as needed.

MBB and Delayed Deletion for SR Policies

SR-MPLS TE Policies support make-before-break (MBB), allowing a forwarder to 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 fault or does not obtain the segment list status, the segment list is considered invalid and then immediately deleted without any delay.

SR-MPLS TE Policy Creation

An SR-MPLS TE Policy can be manually configured on a forwarder through CLI or NETCONF. Alternatively, it can be delivered to a forwarder after being dynamically generated by a protocol, such as BGP, on a controller. The dynamic mode facilitates network deployment. If SR Policies generated in both modes exist, the forwarder selects an SR-MPLS TE Policy based on the following rules in descending order:
  • Protocol-Origin: The default value of Protocol-Origin is 20 for a BGP-delivered SR-MPLS TE Policy and is 30 for a manually configured SR-MPLS TE Policy. A larger value indicates a higher preference.
  • <ASN, node-address> tuple: ASN indicates an AS number. For both ASN and node-address, a smaller value indicates a higher preference. The ASN and node-address values of a manually configured SR-MPLS TE Policy are fixed at 0 and 0.0.0.0, respectively.
  • Discriminator: A larger value indicates a higher preference. For a manually configured SR-MPLS TE Policy, the value of Discriminator is the same as the preference value.

Manual SR-MPLS TE Policy Configuration

You can manually configure an SR-MPLS TE Policy through CLI or NETCONF. For a manually configured SR-MPLS TE Policy, information, such as the endpoint and color attributes, the preference values of candidate paths, and segment lists, must be configured. Moreover, the preference values must be unique. The first-hop label of a segment list can be a node, adjacency, BGP EPE, parallel, or anycast SID, but cannot be any binding SID. Ensure that the first-hop label is a local incoming label, so that the forwarding plane can use this label to search the local forwarding table for the corresponding forwarding entry.
Figure 2-91 Manually configured SR-MPLS TE Policy

SR-MPLS TE Policy Delivery by a Controller

Figure 2-92 shows the process in which a controller dynamically generates and delivers an SR-MPLS TE Policy to a forwarder. The process is as follows:
  1. The controller collects information, such as network topology and label information, through BGP-LS.
  2. The controller and headend forwarder establish a BGP peer relationship in the IPv4 SR-MPLS TE Policy address family.
  3. The controller computes an SR-MPLS TE Policy and delivers it to the headend forwarder through the BGP peer relationship. The headend forwarder then generates SR-MPLS TE Policy entries.
Figure 2-92 Controller-delivered SR-MPLS TE Policy

Traffic Steering into an SR-MPLS TE Policy

Route Coloring

Route coloring is to add the Color Extended Community to a route through a route-policy, enabling the route to recurse to an SR-MPLS TE Policy based on the color value and next-hop address in the route.

The route coloring process is as follows:

  1. Configure a route-policy and set a specific color value for the desired route.

  2. Apply the route-policy to a BGP peer or a VPN instance as an import or export policy.

Color-based Traffic Steering

Color-based traffic steering is to steer traffic into an SR-MPLS TE Policy by recursing the traffic route to the SR-MPLS TE Policy based on the color value and next-hop address in the route. Figure 2-93 shows the traffic steering process.
Figure 2-93 Color-based traffic steering
The color-based traffic steering process is as follows:
  1. The controller delivers an SR-MPLS TE Policy to headend device A. The SR-MPLS TE Policy's color value is 123 and its endpoint value is the address 10.1.1.3 of device B.
  2. A BGP or VPN export policy is configured on device B, or a BGP or VPN import policy is configured on device A, with the color value being set to 123 for route prefix 10.1.1.0/24 and the next-hop address in the route being set to address 10.1.1.3 of device B. Then, the route is delivered to device A through the BGP peer relationship.
  3. A tunnel policy is configured on device A. After receiving BGP route 10.1.1.0/24, device A recurses the route to the SR-MPLS TE Policy based on color value 123 and next-hop address 10.1.1.3. During forwarding, the label stack <C,E,G,B> is added to the packets destined for 10.1.1.0/24.

DSCP-based Traffic Steering

DSCP-based traffic steering does not support color-based route recursion. Instead, it recurses a route into an SR-MPLS TE Policy based on the next-hop address in the route. Specifically, it searches for the SR-MPLS TE Policy group matching specific endpoint information and then finds the corresponding SR-MPLS TE Policy based on the DSCP value of packets. Figure 2-94 shows the DSCP-based traffic steering process.

Figure 2-94 DSCP-based traffic steering
The DSCP-based traffic steering process is as follows:
  1. The controller sends two SR Policies to headend device A. SR-MPLS TE Policy 1's color value is 123 and its endpoint value is address 10.1.1.3 of device B. SR-MPLS TE Policy 2's color value is 124 and its endpoint value is also address 10.1.1.3 of device B.
  2. Device B delivers BGP route 10.1.1.0/24 to headend device A through the BGP peer relationship.
  3. Tunnel policy configuration is performed on the head device A. Specifically, an SR-MPLS TE Policy group is configured, with its endpoint being address 10.1.1.3 of device B. Color value 123 is mapped to DSCP value 10, and color value 124 is mapped to DSCP value 20. Then, a tunnel policy is configured on device A to bind the SR-MPLS TE Policy group and the next-hop address in the route.
  4. Device A implements tunnel recursion based on the destination address of packets and finds the SR-MPLS TE Policy group bound to the destination address. After the color value matching the DSCP value of the packets and the specific SR-MPLS TE Policy matching the color value are found, the packets can be steered into the SR-MPLS TE Policy.

SR-MPLS TE Policy-based Data Forwarding

Intra-AS Data Forwarding

Intra-AS data forwarding depends on the establishment of intra-AS SR-MPLS TE Policy forwarding entries. Figure 2-95 shows the process of establishing intra-AS SR-MPLS TE Policy forwarding entries.
Figure 2-95 Establishment of intra-AS SR-MPLS TE Policy forwarding entries
The process of establishing intra-AS SR-MPLS TE Policy forwarding entries is as follows:
  1. The controller delivers an SR-MPLS TE Policy to headend device A.
  2. Endpoint device B advertises BGP route 10.1.1.0/24 to device A, and the next-hop address in the BGP route is address 10.1.1.3/32 of device B.
  3. A tunnel policy is configured on device A. After receiving the BGP route, device A recurses the route to the SR-MPLS TE Policy based on the color value and next-hop address in the route. The label stack of the SR-MPLS TE Policy is <20003,20005,20007,20002>.
Figure 2-96 shows the intra-AS data forwarding process. Headend device A finds the SR-MPLS TE Policy and pushes label stack <20003,20005,20007,20002> on the packet destined for 10.1.1.0/24. After receiving an SR-MPLS TE packet, devices C, E, and G all remove the outer label in the SR-MPLS TE packet. Finally, device G forwards the received packet to device B. After receiving the packet, device B further processes it based on the packet destination address.
Figure 2-96 Intra-AS data forwarding

Inter-AS Data Forwarding

Inter-AS data forwarding depends on the establishment of inter-AS SR-MPLS TE Policy forwarding entries. Figure 2-97 shows the process of establishing inter-AS SR-MPLS TE Policy forwarding entries.

Figure 2-97 Establishment of inter-AS SR-MPLS TE Policy forwarding entries
The process of establishing inter-AS SR-MPLS TE Policy forwarding entries is as follows:
  1. The controller delivers an intra-AS SR-MPLS TE Policy to headend device ASBR3 in AS 200. The SR-MPLS TE Policy's color value is 123, endpoint is IP address 10.1.1.3 of PE1, and binding SID is 30028.
  2. The controller delivers an inter-AS E2E SR-MPLS TE Policy to headend device CSG1 in AS 100. The SR-MPLS TE Policy's color value is 123, and endpoint is address 10.1.1.3 of PE1. The segment list combines the intra-AS label of AS 100, the inter-AS BGP Peer-Adj label, and the binding SID of AS 200, forming <102,203,3040,30028>.
  3. A BGP or VPN export policy is configured on PE1, with the color value being set to 123 for route prefix 10.1.1.0/24 and the next-hop address in the route being set to address 10.1.1.3 of PE1. Then, the route is advertised to CSG1 through the BGP peer relationship.
  4. A tunnel policy is configured on headend device CSG1. After receiving BGP route 10.1.1.0/24, CSG1 recurses the route to the E2E SR-MPLS TE Policy based on the color value and next-hop address in the route. The label stack of the SR-MPLS TE Policy is <102,203,3040,30028>.

Figure 2-98 shows the inter-AS data forwarding process.

Figure 2-98 Inter-AS SR-MPLS TE Policy data forwarding

The inter-AS SR-MPLS TE Policy data forwarding process is as follows:

  1. Headend device CSG1 adds label stack <102,203,3040,30028> to the data packet. Then, the device searches for the outbound interface according to label 102 of the CSG1->AGG1 adjacency and removes the label. The packet carrying label stack <203,3040,30028> is forwarded to downstream device AGG1 through the CSG1->AGG1 adjacency.

  2. After receiving the packet, AGG1 searches for the adjacency matching top label 203 in the label stack, finds that the corresponding outbound interface is the AGG1->ASBR1 adjacency, and removes the label. The packet carrying label stack <3040,30028> is forwarded to downstream device ASBR1 through the AGG1->ASBR1 adjacency.

  3. After receiving the packet, ASBR1 searches for the adjacency matching top label 3040 in the label stack, finds that the corresponding outbound interface is the ASBR1->ASBR3 adjacency, and removes the label. The packet carrying label stack <30028> is forwarded to downstream device ASBR3 through the ASBR1->ASBR3 adjacency.

  4. After receiving the packet, ASBR3 searches the forwarding table based on top label 30028 in the label stack. 30028 is a binding SID that corresponds to label stack <405,506>. Then, the device searches for the outbound interface based on label 405 of the ASBR3->P1 adjacency and removes the label. The packet carrying label stack <506> is forwarded to downstream device P1 through the ASBR3->P1 adjacency.

  5. After receiving the packet, P1 searches for the adjacency matching top label 506 in the label stack, finds that the corresponding outbound interface is the P1->PE1 adjacency, and removes the label. In this case, the packet does not carry any label and is forwarded to destination device PE1 through the P1->PE1 adjacency. After receiving the packet, PE1 further processes it based on the packet destination address.

SBFD for SR-MPLS TE Policy

Unlike RSVP-TE, which exchanges Hello messages between forwarders to maintain tunnel status, an SR-MPLS TE Policy cannot maintain its status in the same way. An SR-MPLS TE Policy is established immediately after the headend delivers a label stack. The SR-MPLS TE Policy remains up only unless the label stack is revoked. Therefore, seamless bidirectional forwarding detection (SBFD) for SR-MPLS TE Policy is introduced for SR-MPLS TE Policy fault detection. SBFD for SR-MPLS TE Policy is an end-to-end fast detection mechanism that quickly detects faults on the link through which an SR-MPLS TE Policy passes.

Figure 2-99 shows the SBFD for SR-MPLS TE Policy detection process.
Figure 2-99 SBFD for SR-MPLS TE Policy
The SBFD for SR-MPLS TE Policy detection process is as follows:
  1. After SBFD for SR-MPLS TE Policy is enabled on the headend, the endpoint uses the endpoint address (IPv4 address only) as the remote discriminator of the SBFD session corresponding to the segment list in the SR-MPLS TE Policy by default. If multiple segment lists exist in the SR-MPLS TE Policy, the remote discriminators of the corresponding SBFD sessions are the same.
  2. The headend sends an SBFD packet encapsulated with a label stack corresponding to the SR-MPLS TE Policy.
  3. After the endpoint device receives the SBFD packet, it returns a reply through the shortest IP link.
  4. If the headend receives the reply, it considers that the corresponding segment list in the SR-MPLS TE Policy is normal. Otherwise, it considers that the segment list is faulty. If all the segment lists referenced by a candidate path are faulty, SBFD triggers a candidate path switchover.

SBFD return packets are forwarded over IP. If the primary paths of multiple SR-MPLS TE Policies between two nodes differ due to different path constraints but SBFD return packets are transmitted over the same path, a fault in the return path may cause all involved SBFD sessions to go down. As a result, all the SR-MPLS TE Policies between the two nodes go down. The SBFD sessions of multiple segment lists in the same SR-MPLS TE Policy also have this problem.

By default, if HSB protection is not enabled for an SR-MPLS TE Policy, SBFD detects all the segment lists only in the candidate path with the highest preference in the SR-MPLS TE Policy. With HSB protection enabled, SBFD can detect all the segment lists of candidate paths with the highest and second highest priorities in the SR-MPLS TE Policy. If all the segment lists of the candidate path with the highest preference are faulty, a switchover to the HSB path is triggered.

SR-MPLS TE Policy Failover

SBFD for SR-MPLS TE Policy checks the connectivity of segment lists. If a segment list is faulty, an SR-MPLS TE Policy failover is triggered.

On the networks shown in Figure 2-100 and Figure 2-101, the headend and endpoint of SR-MPLS TE Policy 1 are PE1 and PE2, respectively. In addition, the headend and endpoint of SR-MPLS TE Policy 2 are PE1 and PE3, respectively. VPN FRR can be deployed for SR-MPLS TE Policy 1 and SR-MPLS TE Policy 2. Primary and HSB paths are established for SR-MPLS TE Policy 1. Segment list 1 contains node labels to P1, P2, and PE2. It can directly use all protection technologies of SR-MPLS, for example, TI-LFA.
Figure 2-100 SR-MPLS TE Policy failover
Figure 2-101 SR-MPLS TE Policy label stack
In Figure 2-100:
  • If point 1, 3, or 5 is faulty, TI-LFA local protection takes effect only on PE1, P1, or P2. If the SBFD session corresponding to segment list 1 on PE1 detects a fault before traffic is restored through local protection, SBFD automatically sets segment list 1 to down and instructs SR-MPLS TE Policy 1 to switch to segment list 2.
  • If point 2 or 4 is faulty, no local protection is available. SBFD detects node faults, sets segment list 1 to down, and instructs SR-MPLS TE Policy 1 to switch to segment list 2.
  • If PE2 is faulty and all the candidate paths of SR-MPLS TE Policy 1 are unavailable, SBFD can detect the fault, set SR-MPLS TE Policy 1 to down, and trigger a VPN FRR switchover to switch traffic to SR-MPLS TE Policy 2.

SR-MPLS TE Policy OAM

SR-MPLS TE Policy operation, administration and maintenance (OAM) is used to monitor SR-MPLS TE Policy connectivity and quickly detect SR-MPLS TE Policy faults. Currently, SR-MPLS TE Policy OAM is implemented through ping and tracert tests.

SR Policies implement policy control on paths, whereas paths are real paths with SID stacks. There are two levels of SR-MPLS TE Policy detection.
  1. SR-MPLS TE Policy-level detection: You can configure multiple candidate paths for an SR-MPLS TE Policy. The valid path with the highest preference is the primary path, and the valid path with the second highest preference is the backup path. Multiple segment lists of a candidate path work in load balancing mode. The same candidate path can be configured for different SR Policies. SR-MPLS TE Policy-level detection is to detect the primary and backup paths in an SR-MPLS TE Policy.
  2. Candidate path-level detection: This detection is basic and does not involve upper-layer policy services. It only detects whether a candidate path is normal.

Policy-level detection is equivalent to candidate path-level detection if the preferred primary and backup paths are found. If the primary and backup paths have multiple segment lists, the ping and tracert tests check all the segment lists through the same process and generate test results.

SR-MPLS TE Policy Ping

On the network shown in Figure 2-102, SR is enabled on the PE and P devices on the public network. An SR-MPLS TE Policy is established from PE1 to PE2. The SR-MPLS TE Policy has only one primary path, and its segment list is PE1->P1->P2->PE2.

Figure 2-102 SR-MPLS TE Policy ping/tracert

The process of initiating a ping test on the SR-MPLS TE Policy from PE1 is as follows:

  1. PE1 constructs an MPLS Echo Request packet. In the IP header of the packet, the destination IP address is 127.0.0.0/8, and the source IP address is the MPLS LSR ID of PE1. MPLS labels are encapsulated as a SID label stack in segment list form.

    Note that, if an adjacency SID is configured, headend device PE1 only detects the FEC of P1. As a result, after the ping packet reaches PE2, the FEC of PE2 fails to be verified. Therefore, to ensure that the FEC verification on the endpoint device succeeds in this scenario, the MPLS Echo Request packet must be encapsulated with nil_FEC.

  2. PE1 forwards the packet to P1 and P2 hop by hop based on the segment list label stack of the SR-MPLS TE Policy.

  3. P2 removes the outer label from the received packet and forwards the packet to PE2. In this case, all labels of the packet are removed.

  4. PE2 sends the packet to the host transceiver for processing, constructs an MPLS Echo Reply packet, and sends the packet to PE1. The destination address of the packet is the MPLS LSR ID of PE1. Because no SR-MPLS TE Policy is bound to the destination address of the reply packet, IP forwarding is implemented for the packet.

  5. After receiving the reply packet, PE1 generates ping test results.

If there are primary and backup paths with multiple segment lists, the ping test checks all the segment lists.

SR-MPLS TE Policy Tracert

On the network in Figure 2-102, the process of initiating a tracert test on the SR-MPLS TE Policy from PE1 is as follows:

  1. PE1 constructs an MPLS Echo Request packet. In the IP header of the packet, the destination IP address is 127.0.0.0/8, and the source IP address is an MPLS LSR ID. MPLS labels are encapsulated as a SID label stack in segment list form.

  2. PE1 forwards the packet to P1. After receiving the packet, P1 determines whether the outer TTL minus one is zero.

    • If the outer TTL minus one is zero, an MPLS TTL timeout occurs and P1 sends the packet to the host transceiver for processing.

    • If the outer TTL minus one is greater than zero, P1 removes the outer MPLS label, buffers the value (outer TTL minus one), copies and pastes the value to the new outer MPLS label, searches the forwarding table for the outbound interface, and forwards the packet to P2.

  3. Similar to P1, P2 also determines whether the outer TTL minus one is zero.

    • If the outer TTL minus one is zero, an MPLS TTL timeout occurs and P2 sends the packet to the host transceiver for processing.

    • If the outer TTL minus one is greater than zero, P2 removes the outer MPLS label, buffers the value (outer TTL minus one), copies and pastes the value to the new outer MPLS label, searches the forwarding table for the outbound interface, and forwards the packet to PE2.

  4. After receiving the packet, PE2 removes the outer MPLS label and sends the packet to the host transceiver for processing. In addition, PE2 returns an MPLS Echo Reply packet to PE1, with the destination address of the packet being the MPLS LSR ID of PE1. Because no SR-MPLS TE Policy is bound to the destination address of the reply packet, IP forwarding is implemented for the packet.

  5. After receiving the reply packet, PE1 generates tracert test results.

If there are primary and backup paths with multiple segment lists, the tracert test checks all the segment lists.

Translation
简体中文
Download
Updated: 2020-07-02

Document ID: EDOC1100147031

Views: 625

Downloads: 5

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next
Enterprise APP

Copyright © 2021 Huawei Technologies Co., Ltd. All rights reserved.

You are going to visit :