No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Feature Description - Segment Routing 01

This is NE40E V800R010C10SPC500 Feature Description - Segment Routing
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 LSP

SR LSP

SR LSPs are established using the segment routing technique, uses prefix or node segments to guide data packet forwarding. Segment Routing Best Effort (SR-BE) uses an IGP to run the shortest path algorithm to compute an optimal SR LSP.

The establishment and data forwarding of SR LSPs are similar with those of LDP LSPs. SR LSPs have no tunnel interfaces.

Creating an SR LSP

Creating an SR LSP involves the following operations:

  • Devices report topology information to a controller (if the controller is used to create a tunnel) and are assigned labels.

  • The devices compute paths.

SR LSPs are created primarily using prefix labels. A destination node runs an IGP to advertise prefix SIDs, and forwarders parse them and compute label values based on local SRGBs. Each node then runs an IGP to collect topology information, runs the SPF algorithm to calculate a label forwarding path, and delivers the computed next hop and outgoing label (OuterLabel) to the forwarding table to guide data packet forwarding.
Figure 2-6 Prefix label-based LSP establishment

Table 2-2 describes the process of using prefix labels to create an LSP shown in Figure 2-6.

Table 2-2 LSP creation process

Step

Device

Operation

1

D

An SRGB and a prefix SID are configured on a loopback interface of D. D generates forwarding entries, encapsulates the SRGB and prefix SID into an LSP (for example, IS-IS Router Capability TLV-242 containing SR-Capabilities Sub-TLV), and floods the LSP across the whole network through an IGP.

After the other devices receive the LSP, they parse the LSP, obtain the prefix SID advertised by device D, and use the prefix to compute labels based on local SRGBs. They run an IGP to compute a label switched path and find next-hop devices and outgoing labels.

2

C

C parses the prefix SID released by device D and computes a label value based on the local SRGB (36000 to 65535). The value is calculated using the following formula:

Label = SRGB start value + Prefix SID value = 36000 + 100 = 36100

IS-IS calculates an outgoing label based on the following formula:

OuterLabel = SRGB start value advertised by the next hop devices + Prefix SID value = 16000 + 100 = 16100

Here, the next-hop device is device D, and device D releases the SRGB (16000 to 65535).

3

B

The calculation process is similar to C:

Label = 26000 + 100 = 26100

OuterLabel = 36000 + 100 = 36100

4

A

The calculation process is similar to C:

Label = 6000 + 100 = 6100

OuterLabel = 26000 + 100 = 26100

Data Forwarding

Similar to MPLS, SR-TE operates labels by pushing, swapping, or popping them.

  • Push: After a packet enters an SR LSP, the ingress adds a label between the Layer 2 and IP header. Alternatively, the ingress adds a label stack above the existing label stack.

  • Swap: When packets are forwarded in an SR domain, a node searches the label forwarding table for a label assigned by a next hop and swaps the label on the top of the label stack with the matching label in each SR packet.

  • Pop: After the packets leave out of an SR-TE tunnel, a node finds an outbound interface mapped to the label on the top of the label stack and removes the top label.

Figure 2-7 Prefix label-based data forwarding

Table 2-3 describes the data forwarding process on the network shown in Figure 2-7.

Table 2-3 Packet forwarding process

Step

Device

Operation

1

A

Receives a data packet, adds label 26100 to the packet, and forwards the packet.

2

B

Receives the labeled packet, swaps label 26100 for label 36100, and forwards the packet.

3

C

Receives the labeled packet, swaps label 36100 for label 16100, and forwards the packet.

4

D

Removes label 16100 and forwards the packet along a matching route.

PHP, MPLS QoS, and TTL

Penultimate hop popping (PHP) is enabled on the egress on which a label becomes useless. The egress assigns a label to a penultimate node on an LSP so that the label is removed to relieve the burden on the egress. The egress then forwards the packet over an IP route or based on the next label.

PHP is configured on the egress. In Figure 2-7, PHP is not enabled, and NE-C is a penultimate hop of an SR tunnel. NE-C uses a valid label to reach NE-D. If PHP is enabled, NE-C sends a packet without an SR label to NE-D.

Enabling PHP affects both the MPLS QoS and TTL functions on the egress. For details, see Table 2-4.

Table 2-4 PHP, MPLS QoS, and TTL
Label Type Description MPLS EXP (QoS) on the Egress MPLS TTL on the Egress Scenario

explicit-null

PHP is not supported. The egress assigns an explicit-null label. The IPv4 explicit-null label value is 0.

The MPLS EXP field is reserved. QoS is supported.

The MPLS TTL processing is normal.

Label resources on the egress are saved. If E2E services carry QoS attributes to be contained in the EXP field in a label, an explicit-null can be used.

implicit-null

PHP is supported. The egress assigns an implicit-null label. The implicit-null label value is 3.

If an implicit-null label is distributed to an NE, the NE directly removes the label without having to swap an existing label at the top of the stack for it. The egress then forwards the packet over an IP route or based on the next label.

There is no MPLS EXP field on the egress, and QoS is not supported.

There is no MPLS TTL field on the egress, so it cannot be copied to the IP TTL field.

The forwarding burden on the egress is reduced, and forwarding efficiency is improved.

non-null

PHP is not supported. The egress assigns a common label to a penultimate hop.

The MPLS EXP field is reserved. QoS is supported.

The MPLS TTL processing is normal.

Using a non-null label consumes a great number of resources on the egress and is not recommended. The non-null label helps the egress identify various types of services.

SR and LDP Communication

Users are gravitating to segment routing (SR), a new tunneling technique that is a substitute for MPLS. SR is introduced to simplify network deployment and management and reduce capital expenditure (CAPEX).

MPLS LDP is a mainstream tunneling technique that is widely used on bearer networks. When SR is edging out LDP, LSP and SR coexist for a long term, which poses a challenge to the interworking between LDP and SR networks.

The SR and LDP interworking technique allows both segment routing and LDP to work within the same network. This technique connects an SR network to an LDP network to implement MPLS forwarding.

To implement the interworking between the LDP and SR networks, the SR network must have devices that replace SR-incapable LDP devices to advertise SIDs. Such devices are mapping servers.
  • Mapping server: supports mapping between prefixes and SIDs and advertises the mapping to a mapping client.
  • Mapping client: receives mapping between prefixes and SIDs sent by the mapping server and creates mapping entries.

Since LSPs are unidirectional, SR and LDP interworking involves two directions: SR to LDP and LDP to SR.

SR to LDP
Figure 2-8 describes the process of creating an E2E SR-to-LDP LSP.
Figure 2-8 Process of creating an E2E SR-to-LDP LSP
The process of creating an E2E SR-to-LDP LSP is as follows:
  1. On PE2, an IP address prefix is configured. LDP assigns a label to the prefix. PE2 sends a Label Mapping message upstream to P3.
  2. Upon receipt of the message, P3 assigns a label to the prefix and sends a Label Mapping message upstream to P2.
  3. Upon receipt of the message, P2 creates an LDP LSP to PE2.
  4. On P2, the mapping server function is enabled so that P2 maps an LDP label carried in the IP address prefix to a SID.
  5. P2 advertises a Mapping TLV upstream to P1.
  6. P1 advertises a Mapping TLV upstream to PE1.
  7. PE1 parses the Mapping TLV and creates an SR LSP to P2.
  8. P2 creates mapping between the SR and LDP LSPs.

During data forwarding, P2 has no SR label destined for PE2 and encapsulates an SR label to an LDP label based on the mapping between the prefix and SID.

LDP to SR
Figure 2-9 describes the process of creating an E2E LDP-to-SR LSP.
Figure 2-9 Process of creating an E2E LDP-to-SR LSP
The process of creating an E2E LDP-to-SR LSP is as follows:
  1. An IP address prefix is assigned to PE1 and a SID is set for the prefix. PE1 advertises the prefix and SID to P1 using an IGP.
  2. Upon receipt of the information, P1 advertises the prefix and SID to P2 using an IGP.
  3. Upon receipt of the prefix and SID, P2 creates an SR LSP to PE1.
  4. On P2, proxy LDP egress is configured P2 maps a SID carried in the IP address prefix to an LDP label. Once proxy LDP egress is configured and the route to the peer is reachable, a local node sends a Label Mapping message upstream.
  5. P2 sends a Label Mapping message upstream to P3, and P3 sends a Label Mapping message upstream to PE2.
  6. PE2 parses the received Label Mapping message and creates an LDP LSP to P2.
  7. P2 creates mapping between the SR and LDP LSPs.

During data forwarding, P2 has no LDP label destined for PE1 and encapsulates an LDP label to an SR label based on the mapping between the prefix and SID.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055048

Views: 6051

Downloads: 69

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next