Related Concepts

Table 1-917 Related concepts

Concept	Description
MPLS TE tunnel	MPLS TE often associates multiple LSPs with a virtual tunnel interface, and such a group of LSPs is called an MPLS TE tunnel. An MPLS TE tunnel is uniquely identified by the following parameters: Tunnel interface: a P2P virtual interface that encapsulates packets. Similar to a loopback interface, a tunnel interface is a logical interface. A tunnel interface name is identified by an interface type and number. The interface type is tunnel. The interface number is expressed in the format of slot ID/card ID/interface ID. Tunnel ID: a decimal number that uniquely identifies an MPLS TE tunnel, facilitating tunnel planning and management. A tunnel ID must be specified when an MPLS TE tunnel interface is configured. Figure 1-2178 MPLS TE tunnel and LSP A primary LSP with an LSP ID 2 is established along the path LSRA → LSRB → LSRC → LSRD → LSRE on the network shown in Figure 1-2178. A backup LSP with an LSP ID 1024 is established along the path LSRA → LSRF → LSRG → LSRH → LSRE. The two LSPs are in MPLS TE tunnel named Tunnel1 with a tunnel ID 100.
CR-LSP	LSPs in an MPLS TE tunnel are generally called constraint-based routed label switched paths (CR-LSPs). Unlike Label Distribution Protocol (LDP) LSPs that are established based on routing information, CR-LSPs are established based on bandwidth and path constraints in addition to routing information.

MPLS TE Tunnel Establishment and Application

An MPLS TE tunnel is established using a series of protocol components, as shown in Table 1-918. They work in sequence during tunnel establishment.

An MPLS TE network administrator only needs to configure link attributes based on link resource status and tunnel attributes based on service needs and network planning. MPLS TE can then automatically establish tunnels based on the configurations. After tunnels are set up and traffic import is configured, traffic can then be forwarded along tunnels.

Related Concepts

Contents to Be Advertised

Advertisement Methods

When to Advertise Information

OSPF TE or IS-IS TE floods link information so that each node can save area-wide link information to a traffic engineering database (TEDB). Information flooding is triggered by the establishment of an MPLS TE tunnel, or one of the following conditions:

• A specific IGP TE flooding interval elapses.

• A link is activated or deactivated.

• A CR-LSP fails to be established for an MPLS TE tunnel because no adequate bandwidth can be reserved.

• Link attributes, such as the administrative group attribute or affinity attribute, change.

• The link bandwidth changes.

  When the available bandwidth of an MPLS interface changes, the system automatically updates information in the TEDB and floods it. When a lot of tunnels are to be established on a node, the node reserves bandwidth and frequently updates information in the TEDB and floods it. For example, the bandwidth of a link is 100 Mbit/s. If 100 TE tunnels, each with bandwidth of 1 Mbit/s, are established, the system floods link information 100 times.

  To help suppress the frequency at which TEDB information is updated and flooded, the flooding is triggered based on either of the following conditions:

  • The proportion of the bandwidth reserved for an MPLS TE tunnel to the available bandwidth in the TEDB is greater than or equal to a specific threshold.

  • The proportion of the bandwidth released by an MPLS TE tunnel to the available bandwidth in the TEDB is greater than or equal to a specific threshold.

  If either of the preceding conditions is met, an IGP floods link bandwidth information, and CSPF updates the TEDB.

  Assume that the available bandwidth of a link is 100 Mbit/s and 100 TE tunnels, each with bandwidth of 1 Mbit/s, are established over the link. The flooding threshold is 10%. Figure 1-2179 shows the proportion of the bandwidth reserved for each MPLS TE tunnel to the available bandwidth in the TEDB.

  Bandwidth flooding is not performed when tunnels 1 to 9 are created. After tunnel 10 is created, the bandwidth information (10 Mbit/s in total) on tunnels 1 to 10 is flooded. The available bandwidth is 90 Mbit/s. Similarly, no bandwidth information is flooded after tunnels 11 to 18 are created. After tunnel 19 is created, bandwidth information of tunnels 11 to 19 is flooded. The process repeats until tunnel 100 is established.

  Figure 1-2179 Proportion of the bandwidth reserved for each MPLS TE tunnel to the available bandwidth in the TEDB
  

Results Obtained After Information Advertisement

Every node creates a TEDB in an MPLS TE area after OSPF TE or IS-IS TE floods bandwidth information.

TE parameters are advertised during the deployment of an MPLS TE network. Every node collects TE link information in the MPLS TE area and saves it in a TEDB. The TEDB

contains network link and topology attributes, including information about the constraints and bandwidth usage of each link. A node calculates the optimal path to another node in the MPLS TE area based on information in the TEDB. MPLS TE then establishes a CR-LSP over this optimal path.

Related Concepts

CSPF Fundamentals

CSPF works based on the following parameters:

• Tunnel attributes configured on an ingress to establish a CR-LSP

• TEDB

A TEDB can be generated only after IGP TE is configured. On an IGP TE-incapable network, CR-LSPs are established based on IGP routes, but not CSPF calculation results.

CSPF Calculation Process

The CSPF calculation process is as follows:

1. Links that do not meet tunnel attribute requirements in the TEDB are excluded.

2. SPF calculates the shortest path to a tunnel destination based on TEDB information.

CSPF attempts to use the OSPF TEDB to establish a path for a CR-LSP by default. If a path is successfully calculated using OSPF TEDB information, CSPF completes calculation and does not use the IS-IS TEDB to calculate a path. If path calculation fails, CSPF attempts to use IS-IS TEDB information to calculate a path.

CSPF can be configured to use the IS-IS TEDB to calculate a CR-LSP path. If path calculation fails, CSPF uses the OSPF TEDB to calculate a path.

CSPF calculates the shortest path to a destination. If there are several shortest paths with the same metric, CSPF uses a tie-breaking policy to select one of them. The following tie-breaking policies for selecting a path are available:

• Most-fill: selects a link with the highest proportion of used bandwidth to the maximum reservable bandwidth, efficiently using bandwidth resources.

• Least-fill: selects a link with the lowest proportion of used bandwidth to the maximum reservable bandwidth, evenly using bandwidth resources among links.

• Random: selects links randomly, allowing LSPs to be established evenly over links, regardless of bandwidth distribution.

The Most-fill and Least-fill modes are only effective when the difference in bandwidth usage between the two links exceeds 10%, such as 50% of link A bandwidth utilization and 45% of link B bandwidth utilization. The value is 5%. At this time, the Most-fill and Least-fill modes do not take effect, and the Random mode is still used.

On the network shown in Figure 1-2183, except the blue links and the links marked a specific bandwidth value, all the links are of black and have the bandwidth of 100 Mbit/s. In this topology, an MPLS TE tunnel needs to be established. The constraints on this tunnel are: The destination is LSRE, the bandwidth is 80 Mbit/s, the affinity is black, and a transit node is LSRH. The lower part of Figure 1-2183 shows the topology in which links that do not meet the constraints are removed.

Figure 1-2183 Process of link removal

CSPF calculates a path shown in Figure 1-2184 in the same way SPF would calculate it.

Figure 1-2184 CSPF calculation result

Differences Between CSPF and SPF

CSPF is dedicated to calculating MPLS TE paths. It has similarities with SPF but they have the following differences:

• CSPF calculates the shortest path between the ingress and egress, and SPF calculates the shortest path between a node and each of other nodes on a network.

• CSPF uses metrics such as the bandwidth, link attributes, and affinity attributes, in addition to link costs, which are the only metric used by SPF.

• CSPF does not support load balancing and uses three tie-breaking policies to determine a path if multiple paths have the same attributes.

RSVP-TE Messages

RSVP-TE messages are as follows:

• Path message: used to request downstream nodes to distribute labels. A Path message records path information on each node through which the message passes. The path information is used to establish a path state block (PSB) on a node.

• Resv message: used to reserve resources at each hop of a path. A Resv message carries information about resources to be reserved. Each node that receives the Resv message reserves resources based on reservation information carried in the message. The reservation information is used to establish a reservation state block (RSB) and to record information about distributed labels.

• PathErr message: sent upstream by an RSVP node if an error occurs during the processing of a Path message. A PathErr message is forwarded by every transit node and arrives at the ingress.

• ResvErr message: sent downstream by an RSVP node if an error occurs during the processing of a Resv message. A ResvErr message is forwarded by every transit node and arrives at the egress.

• PathTear message: sent downstream by the ingress to delete information about the local state created on every node of the path.

• ResvTear message: sent upstream by the egress to delete the local reserved resources assigned to a path. After receiving the ResvTear message, the ingress sends a PathTear message to the egress.

Process of Establishing an LSP

Figure 1-2185 Schematic diagram for the establishment of a CR-LSP

Figure 1-2185 shows the process of establishing a CR-LSP. The process is as follows:

1. The ingress configured with RSVP-TE creates a PSB and sends a Path message to transit nodes.

2. After receiving the Path message, the transit node processes and forwards this message, and creates a PSB.

3. After receiving the Path message, the egress creates a PSB, uses bandwidth reservation information in the Path message to generate a Resv message, and sends the Resv message to the ingress.

4. After receiving the Resv message, the transit node processes and forwards the Resv message and creates an RSB.

5. After receiving the Resv message, the ingress creates an RSB and confirms that the resources are reserved successfully.

6. The ingress successfully establishes a CR-LSP to the egress.

Soft State Mechanism

The soft state mechanism enables RSVP nodes to periodically send Path and Resv messages to synchronize states (including states in the PSB and RSB) between RSVP neighboring nodes or to resend RSVP messages that have been dropped. If an RSVP node does not receive an RSVP matching a specific state within a specified period of time, the RSVP node deletes the state from a state block.

A node can refresh a state in a state block and notifies other nodes of the refreshed state. In the tunnel re-optimization scenario, if a route changes, the ingress is about to establish a new LSP. RSVP nodes along the new path send Path messages downstream to initialize PSBs and receive Resv messages responding to create new RSBs. After the new path is established, the ingress sends a Tear message downstream to delete soft states maintained on nodes of the previous path.

Reservation Styles

A reservation style defines how a node reserves resources after receiving a request sent by an upstream node. The NetEngine 8000 F supports the following reservation styles:

• Fixed filter (FF): defines a distinct bandwidth reservation for data packets from a particular transmit end.

• Shared explicit (SE): defines a single reservation for a set of selected transmit ends. These senders share one reservation but assign different labels to a receive end.

Background

RSVP Refresh messages are used to synchronize path state block (PSB) and reservation state block (RSB) information between nodes. They can also be used to monitor the reachability between RSVP neighbors and maintain RSVP neighbor relationships. As the sizes of Path and Resv messages are larger, sending many messages to establish many CR-LSPs causes increased consumption of network resources. RSVP Srefresh can be used to address this problem.

Implementation

Background

RSVP Refresh messages are used to synchronize path state block (PSB) and reservation state block (RSB) information between nodes. They can also be used to monitor the reachability between RSVP neighbors and maintain RSVP neighbor relationships.

Using Path and Resv messages to monitor neighbor reachability delays a traffic switchover if a link fault occurs and therefore is slow. The RSVP Hello extension can address this problem.

Related Concepts

Implementation

The principles of the RSVP Hello extension are as follows:

1. Hello handshake mechanism

   Figure 1-2186 Hello handshake mechanism
   

   LSRA and LSRB are directly connected on the network shown in Figure 1-2186.

   • If RSVP Hello is enabled on LSRA, LSRA sends a Hello Request message to LSRB.

   • After LSRB receives the Hello Request message and is also enabled with RSVP Hello, LSRB sends a Hello ACK message to LSRA.

   • After receiving the Hello ACK message, LSRA considers LSRB reachable.

2. Detecting neighbor loss

   After a successful Hello handshake is implemented, LSRA and LSRB exchange Hello messages. If LSRB does not respond to three consecutive Hello Request messages sent by LSRA, LSRA considers router B lost and re-initializes the RSVP Hello process.

3. Detecting neighbor restart

   If LSRA and LSRB are enabled with RSVP GR, and the Hello extension detects that LSRB is lost, LSRA waits for LSRB to send a Hello Request message carrying a GR extension. After receiving the message, LSRA starts the GR process on LSRB and sends a Hello ACK message to LSRB. After receiving the Hello ACK message, LSRB performs the GR process and restores the RSVP soft state. LSRA and LSRB exchange Hello messages to maintain the restored RSVP soft state.

There are two scenarios if a CR-LSP is set up between LSRs:

• If GR is disabled and FRR is enabled, FRR switches traffic to a bypass CR-LSP after the Hello extension detects that the RSVP neighbor relationship is lost to ensure proper traffic transmission.

• If GR is enabled, the GR process is performed.

Deployment Scenarios

The RSVP Hello extension applies to networks enabled with both RSVP GR and TE FRR.

Static Route

Static route is the simplest method for directing traffic to a CR-LSP in an MPLS TE tunnel. A TE static route works in the same way as a common static route and has a TE tunnel interface as an outbound interface.

Auto Route

An Interior Gateway Protocol (IGP) uses an auto route related to a CR-LSP in a TE tunnel that functions as a logical link to calculate a path. The tunnel interface is used as an outbound interface in the auto route. The TE tunnel is considered a P2P link with a specified metric value. The following auto routes are supported:

• IGP shortcut: A route related to a CR-LSP is not advertised to neighbor nodes, preventing other nodes from using the CR-LSP.

• Forwarding adjacency: A route related to a CR-LSP is advertised to neighbor nodes, allowing these nodes to use the CR-LSP.

  Forwarding adjacency allows tunnel information to be advertised based on IGP neighbor relationships.

  If the forwarding adjacency is used, nodes on both ends of a CR-LSP must be in the same area.

The following example demonstrates the IGP shortcut and forwarding adjacency.

Figure 1-2187 Schematic diagram for IGP shortcut and forwarding adjacency

Policy-based Routing

The policy-based routing (PBR) allows the system to select routes based on user-defined policies, improving security and load balancing traffic. If PBR is enabled on an MPLS network, IP packets are forwarded over specific CR-LSPs based on PBR rules.

MPLS TE PBR, the same as IP unicast PBR, is implemented based on a set of matching rules and behaviors. The rules and behaviors are defined using an apply clause, in which the outbound interface is a specific tunnel interface. If packets do not match PBR rules, they are properly forwarded using IP; if they match PBR rules, they are forwarded over specific CR-LSPs.

Tunnel Policy

Background

A tunnel affinity and a link administrative group attribute are 8-bit hexadecimal numbers. An IGP (IS-IS or OSPF) advertises the administrative group attribute to devices in the same IGP area. RSVP-TE advertises the tunnel affinity to downstream devices. CSPF on the ingress checks whether administrative group bits match affinity bits to determine whether a link can be used to establish an LSP.

Hexadecimal calculations are complex, and maintaining and querying tunnels established using hexadecimal calculations are difficult. To address this issue, the NetEngine 8000 F allows you to assign different names (such as colors) for the 128 bits in the affinity attribute. Naming affinity bits help verify that tunnel affinity bits match link administrative group bits, facilitating network planning and deployment.

Implementation

An affinity name template can be configured to manage the mapping between affinity bits and names. On an MPLS network, you are advised to configure the same template for all nodes, because inconsistent configuration may cause a service deployment failure. As shown in Figure 1-2189, the affinity bits are named using colors. For example, bit 1 is named "red", bit 4 is "blue", and bit 6 is "brown." You can name each of the 128 affinity bits differently.

Figure 1-2189 Affinity naming example

Bits in a link administrative group must also be configured with the same names as the affinity bits.

Usage Scenarios

The affinity naming function is used when CSPF calculates paths over which RSVP-TE establishes CR-LSPs.

Benefits

The affinity naming function allows you to easily and rapidly use affinity bits to control paths over which CR-LSPs are established.

Background

A main function of MPLS TE tunnels is to optimize traffic distribution over a network. Generally, the initial bandwidth of an MPLS TE tunnel is configured based on the initial bandwidth requirement of services, and its path is calculated and set up based on the initial network status. However, a network topology changes in some cases, which may cause bandwidth wastes or require traffic distribution optimization. As such, MPLS TE tunnel re-optimization is required.

Implementation

Tunnel re-optimization allows the ingress to re-optimize a CR-LSP based on certain events so that the CR-LSP can be established over the optimal path with the smallest metric value.

• If the fixed filter (FF) resource reservation style is used, tunnel re-optimization cannot be configured.

• Tunnel re-optimization is performed based on tunnel path constraints. During path calculation for re-optimization, path constraints, such as explicit path constraints and bandwidth constraints, are also considered.

The make-before-break mechanism is used to ensure uninterrupted service transmission during the re-optimization process. This means that a new CR-LSP must be established first. Traffic is switched to the new CR-LSP before the original CR-LSP is torn down.

Background

MPLS TE tunnels are used to optimize traffic distribution over a network. Traffic that frequently changes wastes MPLS TE tunnel bandwidth; therefore, automatic bandwidth adjustment is used to prevent this waste. A bandwidth is initially set to meet the requirement for the maximum volume of services to be transmitted over an MPLS TE tunnel, to ensure uninterrupted transmission.

Related Concepts

Automatic bandwidth adjustment allows the ingress to dynamically detect bandwidth changes and periodically attempt to reestablish a tunnel with the needed bandwidth.

Implementation

The preceding procedure repeats each time automatic bandwidth adjustment is triggered. Bandwidth adjustment is not needed if traffic fluctuates below a specific threshold. The ingress calculates an average bandwidth after the sampling interval time elapses. The ingress performs automatic bandwidth adjustment if the ratio of the difference between the average and existing bandwidths to the existing bandwidth exceeds a specific threshold. The following inequality applies:

[ |(D - C)| / C ] x 100% > Threshold

Other Usage

Background

MPLS TE provides a set of tunnel update mechanisms, which prevents traffic loss during tunnel updates. In real-world situations, an administrator can modify the bandwidth or explicit path attributes of an established MPLS TE tunnel based on service requirements. An updated topology allows for a path better than the existing one, over which an MPLS TE tunnel can be established. Any change in bandwidth or path attributes causes a CR-LSP in an MPLS TE tunnel to be reestablished using new attributes and causes traffic to switch from the previous CR-LSP to the newly established CR-LSP. During the traffic switchover, the make-before-break mechanism prevents traffic loss that occurs if the traffic switchover is implemented more quickly than the path switchover.

Principles

Make-before-break is a mechanism that allows a CR-LSP to be established using changed bandwidth and path attributes over a new path before the original CR-LSP is torn down. It helps minimize data loss and additional bandwidth consumption. The new CR-LSP is called a modified CR-LSP. Make-before-break is implemented using the shared explicit (SE) resource reservation style.

The new CR-LSP competes with the original CR-LSP on some shared links for bandwidth. The new CR-LSP cannot be established if it fails the competition. The make-before-break mechanism allows the system to reserve bandwidth used by the original CR-LSP for the new CR-LSP, without calculating the bandwidth to be reserved. Additional bandwidth is used if links on the new path do not overlap the links on the original path.

Figure 1-2190 Schematic diagram for make-before-break

In this example, the maximum reservable bandwidth on each link is 60 Mbit/s on the network shown in Figure 1-2190. A CR-LSP along the path LSRA → LSRB → LSRC → LSRD is established, with the bandwidth of 40 Mbit/s.

The path is expected to change to LSRA → LSRE → LSRC → LSRD to forward data because LSRE has a light load. The reservable bandwidth of the link between LSRC and LSRD is just 20 Mbit/s. The total available bandwidth for the new path is less than 40 Mbit/s. The make-before-break mechanism can be used in this situation.

The make-before-break mechanism allows the newly established CR-LSP over the path LSRA → LSRE → LSRC → LSRD to use the bandwidth of the original CR-LSP's link between LSRC and LSRD. After the new CR-LSP is established over the path, traffic switches to the new CR-LSP, and the original CR-LSP is torn down.

In addition to the preceding method, another method of increasing the tunnel bandwidth can be used. If the reservable bandwidth of a shared link increases to a certain extent, a new CR-LSP can be established.

In the example shown in Figure 1-2190, the maximum reservable bandwidth on each link is 60 Mbit/s. A CR-LSP along the path LSRA → LSRB → LSRC → LSRD is established, with the bandwidth of 30 Mbit/s.

The path is expected to change to LSRA → LSRE → LSRC → LSRD to forward data because LSRE has a light load, and the bandwidth is expected to increase to 40 Mbit/s. The reservable bandwidth of the link between LSRC and LSRD is just 30 Mbit/s. The total available bandwidth for the new path is less than 40 Mbit/s. The make-before-break mechanism can be used in this situation.

The make-before-break mechanism allows the newly established CR-LSP over the path LSRA → LSRE → LSRC → LSRD to use the bandwidth of the original CR-LSP's link between LSRC and LSRD. The bandwidth of the new CR-LSP is 40 Mbit/s, out of which 30 Mbit/s is released by the link between LSRC and LSRD. After the new CR-LSP is established, traffic switches to the new CR-LSP and the original CR-LSP is torn down.

Delayed Switchover and Deletion

If an upstream node on an MPLS network is busy but its downstream node is idle or an upstream node is idle but its downstream node is busy, a CR-LSP may be torn down before the new CR-LSP is established, causing a temporary traffic interruption.

To prevent this temporary traffic interruption, the switching and deletion delays are used together with the make-before-break mechanism. In this case, traffic switches to a new CR-LSP a specified delay time later after a new CR-LSP is established. The original CR-LSP is torn down a specified delay later after a new CR-LSP is established. The switching delay and deletion delay can be manually configured.

Background

Generally, a link or node failure in an MPLS TE tunnel triggers a primary/backup CR-LSP switchover. During the switchover, IGP routes converge to a backup CR-LSP, and CSPF recalculates a path over which the primary CR-LSP can be reestablished. Traffic is dropped during this process.

TE FRR can be used to minimize traffic loss. It pre-establishes backup paths that bypass faulty links and nodes. If a link or node on an MPLS TE tunnel fails, traffic can be rapidly switched to a backup path to prevent traffic loss, without depending on IGP route convergence. In addition, when traffic is transmitted along the backup path, the ingress will initiate the reestablishment of the primary path.

Benefits

TE FRR provides carrier-class local protection capabilities for MPLS TE, improving the reliability of an entire network.

Related Concepts

Facility backup mode

In facility backup mode, TE FRR establishes a bypass tunnel for each link or node that may fail on a primary tunnel, as shown in Figure 1-2191. A bypass tunnel can protect traffic on multiple primary tunnels. In terms of the protection granularity, facility backup enables tunnels to protect tunnels. This mode is extensible, resource efficient, and easy to implement. However, bypass tunnels can only be manually planned and configured. This is time-consuming and laborious on a complex network. The maintenance workload is also heavy.

Figure 1-2191 TE FRR in facility backup mode

One-to-one backup mode

In one-to-one backup mode, TE FRR automatically creates a backup CR-LSP on each possible node along a primary CR-LSP to protect downstream links or nodes, as shown in Figure 1-2192. In terms of the protection granularity, one-to-one backup enables CR-LSPs to protect CR-LSPs. This mode is easy to configure, eliminates manual network planning, and provides flexibility on a complex network. However, this mode has low extensibility, requires each node to maintain backup CR-LSP status, and consumes more bandwidth.

Figure 1-2192 TE FRR in one-to-one backup mode

Table 1-922 describes some concepts in TE FRR.

In facility backup mode, an established bypass CR-LSP supports a combination of the above protection types. For example, a bypass CR-LSP can implement manual, node, and bandwidth protection.

Implementation

Facility backup mode

In this mode, TE FRR is implemented as follows:

1. Primary CR-LSP establishment

   A primary CR-LSP is established in a way similar to that of an ordinary CR-LSP. The difference is that the ingress appends the following flags into the Session_Attribute object in a Path message: Local protection desired, Label recording desired, and SE style desired. If bandwidth protection is required, the "Bandwidth protection desired" flag is also added.

   Figure 1-2193 TE FRR local protection
   

2. Bypass CR-LSP binding

   The process of searching for a proper bypass CR-LSP for a primary CR-LSP is called binding. Only the primary CR-LSP with the "Local protection desired" flag can trigger a binding process. The binding must be complete before a primary/bypass CR-LSP switchover is performed. During the binding, the node must obtain information about the outbound interface of the bypass CR-LSP, next hop label forwarding entry (NHLFE), LSR ID of the MP, label allocated by the MP, and protection type.

   The PLR of the primary CR-LSP already knows the next hop (NHOP) and next-next hop (NNHOP). Link protection can be provided if the egress LSR ID of the bypass CR-LSP is the same as the NHOP LSR ID. Node protection can be provided if the egress LSR ID of the bypass CR-LSP is the same as the NNHOP LSR ID. For example, in Figure 1-2194, Bypass CR-LSP 1 protects a link, and Bypass CR-LSP 2 protects a node.

   Figure 1-2194 Bypass CR-LSP binding in TE FRR
   

   If multiple bypass CR-LSPs are available on a node, the node selects a bypass CR-LSP based on the following factors in sequence: bandwidth/non-bandwidth protection, implementation mode, and protected object. Bandwidth protection takes precedence over non-bandwidth protection, node protection takes precedence over link protection, and manual protection takes precedence over automatic protection. If both Bypass CR-LSP 1 and Bypass CR-LSP 2 shown in Figure 1-2194 are manually configured and provide bandwidth protection, the primary CR-LSP selects Bypass CR-LSP 2 for binding. If Bypass CR-LSP 1 provides bandwidth protection but Bypass CR-LSP 2 provides only path protection, the primary CR-LSP selects Bypass CR-LSP 1 for binding.

   After a bypass CR-LSP is successfully bound to the primary CR-LSP, the NHLFE of the primary CR-LSP is recorded. The NHLFE contains the NHLFE index of the bypass CR-LSP and the inner label assigned by the MP for the previous node. The inner label is used to guide traffic forwarding during FRR switching.

3. Fault detection

   • In link protection, a data link layer protocol is used to detect and advertise faults. The fault detection speed at the data link layer depends on link types.
   • In node protection, a data link layer protocol is used to detect link faults. If no link fault occurs, RSVP Hello detection or BFD for RSVP is used to detect faults in protected nodes.
   If a link or node fault is detected, FRR switching is triggered immediately.

   In node protection, only the link between the protected node and PLR is protected. The PLR cannot detect faults in the link between the protected node and MP.

4. Switchover

   A switchover is a process that switches both service traffic and RSVP messages to a bypass CR-LSP and notifies the upstream node of the switchover when a primary CR-LSP fails. During the switchover, the MPLS label nesting mechanism is used. The PLR pushes the label that the MP assigns for the primary CR-LSP as the inner label, and then the label for the bypass CR-LSP as the outer label. The penultimate hop along the bypass CR-LSP removes the outer label from the packet and forwards the packet only with the inner label to the MP. As the inner label is assigned by the MP, it can forward the packet to the next hop on the primary CR-LSP.

   Figure 1-2195 Packet forwarding before TE FRR switchover
   

   Figure 1-2196 Packet forwarding after TE FRR switchover
   

   Assume that a primary CR-LSP and a bypass CR-LSP are set up. Figure 1-2195 describes the labels assigned by each node on the primary CR-LSP and forwarding actions. The bypass CR-LSP provides node protection. If LSRC or the link between LSRB and LSRC fails, traffic is switched to the bypass CR-LSP. During the switchover, the PLR LSRB swaps 1024 for 1022 and then pushes label 34 as an outer label. This ensures that the packet can be forwarded to the next hop after reaching LSRD. Figure 1-2196 shows the forwarding process.

5. Switchback

   After the switchover, the ingress of the primary CR-LSP attempts to reestablish the primary CR-LSP. After the primary CR-LSP is successfully reestablished, service traffic and RSVP messages are switched back from the bypass CR-LSP to the primary CR-LSP. The reestablished CR-LSP is called a modified CR-LSP. In this process, TE FRR (including Auto FRR) adopts the make-before-break mechanism. With this mechanism, the original primary CR-LSP is torn down only after the modified CR-LSP is set up successfully.

One-to-one backup mode

In this mode, TE FRR is implemented as follows:

1. Primary CR-LSP establishment

   The process of establishing a primary CR-LSP in one-to-one backup mode is similar to that in facility backup mode. The ingress appends the "Local protection desired", "Label recording desired", and "SE style desired" flags to the Session_Attribute object carried in a Path message.

2. Detour LSP establishment

   When a primary CR-LSP is set up, each node, except the egress, on the primary CR-LSP assumes that it is a PLR and attempts to set up detour CR-LSPs to protect its downstream link or node. A qualified node establishes a detour CR-LSP based on CSPF calculation results and becomes the real PLR.

   Each PLR has a known next hop (NHOP). A PLR establishes a detour CR-LSP to provide a specific type of protection:

   • Link protection is provided if the detour CR-LSP's egress LSR ID is the same as the NHOP LSR ID. (For example, Detour CR-LSP2 in Figure 1-2197 provides link protection.)

   • Node protection is provided if the detour CR-LSP's egress LSR ID is not the same as the NHOP LSR ID (that is, other nodes exist between the PLR and MP). (For example, Detour CR-LSP1 in Figure 1-2197 provides node protection.)

   If a PLR supports detour CR-LSPs that provide both link and node protection, the PLR can establish only detour CR-LSPs that provide node protection.

   Figure 1-2197 Detour CR-LSP establishment and label swapping
   

3. Fault detection

   • In link protection, a data link layer protocol is used to detect and advertise faults. The fault detection speed at the data link layer depends on link types.

   • In node protection, a data link layer protocol is used to detect link faults. If no link fault occurs, RSVP Hello detection or BFD for RSVP is used to detect faults in protected nodes.

   If a link or node fault is detected, FRR switching is triggered immediately.

   In node protection, only the link between the protected node and PLR is protected. The PLR cannot detect faults in the link between the protected node and MP.

4. Switchover

   A switchover is a process that switches both service traffic and RSVP messages to a detour CR-LSP and notifies the upstream node of the switchover when a primary CR-LSP fails. During a switchover in this mode, the MPLS label nesting mechanism is not used, and the label stack depth remains unchanged. This is different from that in facility backup mode.

   In Figure 1-2197, a primary CR-LSP and two detour CR-LSPs are established. If no faults occur, traffic is forwarded along the primary CR-LSP based on labels. If the link between LSRB and LSRC fails, LSRB detects the link fault and switches traffic to Detour CR-LSP2 by swapping label 1024 for label 36 in a packet and sending the packet to LSRE. LSRE is the DMP of these two detour CR-LSPs. On LSRE, detour LSPs 1 and 2 merge into one detour CR-LSP (for example, Detour CR-LSP1). LSRE swaps the existing label for label 37 and sends the packet to LSRC. On LSRC, Detour CR-LSP1 overlaps with the primary CR-LSP. Therefore, LSRC uses the label of the primary CR-LSP and sends the packet to the egress.

5. Switchback

   After the switchover, the ingress of the primary CR-LSP attempts to reestablish the primary CR-LSP, and service traffic and RSVP messages are switched back from the detour CR-LSP to the primary CR-LSP after it is established successfully. The reestablished CR-LSP is called a modified CR-LSP. In this process, TE FRR adopts the make-before-break mechanism. With this mechanism, the original primary CR-LSP is torn down only after the modified CR-LSP is set up successfully.

Other Functions

When TE FRR is in the FRR in-use state, the RSVP messages sent by the transmit interface do not carry the interface authentication TLV, and the receive interface does not perform interface authentication on the RSVP messages that do not carry the authentication TLV and are in the FRR in-use state. In this case, you can configure neighbor authentication.

Board removal protection: When the interface board where a primary CR-LSP's outbound interface resides is removed from a PLR, MPLS TE traffic is rapidly switched to a backup path. When the interface board is re-installed, MPLS TE traffic can be switched back to the primary path if the outbound interface of the primary path is still available. Board removal protection protects traffic on the primary CR-LSP's outbound interface of the PLR.

Without board removal protection, after an interface board on which a tunnel interface resides is removed, tunnel information is lost. To prevent tunnel information loss, ensure that the interface board to be removed does not have the following interfaces: primary CR-LSP's tunnel interface on the PLR, bypass CR-LSP's tunnel interface, bypass CR-LSP's outbound interface, or detour CR-LSP's outbound interface. Configuring a TE tunnel interface on a PLR's IPU is recommended.

After a TE tunnel interface is configured on the IPU, if the interface board on which the physical outbound interface of the primary CR-LSP resides is removed or fails, the outbound interface enters the stale state and the FRR-enabled primary CR-LSP that passes through the outbound interface is not deleted. When the interface board is re-inserted, the interface becomes available, and the primary CR-LSP reestablishment starts.

Hot-standby CR-LSP Switchover and Revertive Switchover Policy

Path Overlapping

The path overlapping function can be configured for hot-standby CR-LSPs. This function allows a hot-standby CR-LSP to use links of a primary CR-LSP. The hot-standby CR-LSP protects traffic on the primary CR-LSP.

Comparison Between CR-LSP Backup and Other Features

• The difference between CR-LSP backup and TE FRR is as follows:

  • CR-LSP backup is end-to-end path protection for an entire CR-LSP.

  • Fast reroute (FRR) is a partial protection mechanism used to protect a link or node on a CR-LSP. In addition, FRR rapidly responds to a fault and takes effect temporarily, which minimizes the switchover time.

• CR-LSP hot standby and TE FRR are used together.

  If a protected link or node fails, a point of local repair (PLR) switches traffic to a bypass tunnel. If the PLR is the ingress of the primary CR-LSP, the PLR immediately switches traffic to a hot-standby CR-LSP. If the PLR is a transit node of the primary CR-LSP, it uses a signaling to advertise fault information to the ingress of the primary CR-LSP, and the ingress switches traffic to the hot-standby CR-LSP. If the hot-standby CR-LSP is Down, the ingress keeps attempting to reestablish a hot-standby CR-LSP.

• CR-LSP ordinary backup and TE FRR are used together.

  • The association is disabled.

    If a protected link or node fails, a PLR switches traffic to a bypass tunnel. Only after both the primary and bypass CR-LSPs fail, the ingress of the primary CR-LSP attempts to establish an ordinary backup CR-LSP.

  • The association is enabled (FRR in Use).

    If a protected link or node fails, a PLR switches traffic to a bypass tunnel. If the PLR is the ingress of the primary CR-LSP, the PLR attempts to establish an ordinary backup CR-LSP. If the ordinary backup CR-LSP is successfully established, the PLR switches traffic to the new CR-LSP. If the PLR is a transit node on the primary CR-LSP, the PLR advertises the fault to the ingress of the primary CR-LSP, the ingress attempts to establish an ordinary backup CR-LSP. If the ordinary backup CR-LSP is successfully established, the ingress switches traffic to the new CR-LSP.

    If the ordinary backup CR-LSP fails to be established, traffic keeps traveling through the bypass CR-LSP.

Background

Most live IP radio access networks (RANs) use ring topologies and have the access ring separated from the aggregation ring. Figure 1-2199 illustrates an E2E VPN bearer solution. On this network, an inter-layer MPLS TE tunnel is established between a cell site gateway (CSG) on the access ring and a radio service gateway (RSG) on the aggregation ring. The MPLS TE tunnel implements E2E VPN service transmission. To meet high reliability requirements for IP RAN bearer, hot standby is deployed for the TE tunnel, and the primary and hot-standby CR-LSPs needs to be separated.

However, the existing CSPF algorithm used by TE selects a CR-LSP with the smallest link metric and cannot automatically calculate separated primary and hot-standby CR-LSPs. Assume that the TE metric of each link is as shown in Figure 1-2199. CSPF calculates the primary CR-LSP as CSG-ASG1-ASG2-RSG, but cannot calculate a hot-standby CR-LSP that is completely separated from the primary CR-LSP. However, two completely separated CR-LSPs exist on the network: CSG-ASG1-RSG and CSG-ASG2-RSG.

Those two completely separated CR-LSPs can be obtained by specifying strict explicit paths. In real-world situations, nodes are frequently added or deleted on an IP RAN. The method of specifying strict explicit paths requires you to frequently modify path information, causing heavy O&M workload.

An ideal solution to the problem is to optimize CSPF path calculation so that CSPF can automatically calculate separated primary and hot-standby CR-LSPs. To achieve this purpose, isolated CR-LSP computation is introduced.

Figure 1-2199 E2E VPN bearer solution

Implementation

Isolated CR-LSP computation uses the disjoint algorithm to optimize CSPF path calculation. On the network shown in Figure 1-2200, before the disjoint algorithm is used, CSPF selects CR-LSPs based on link metrics. It calculates LSRA-LSRB-LSRC-LSRD as the primary CR-LSP, and then LSRA-LSRC-LSRD as the hot-standby CR-LSP if the hot-standby overlap-path function is configured. These CR-LSPs, however, are not completely separated.

After the disjoint algorithm is used, CSPF calculates the primary and backup CR-LSPs at the same time and excludes the paths that may cause overlapping. Two completely separated CR-LSPs can then be calculated, with the primary CR-LSP being LSRA-LSRB-LSRD, and the hot-standby CR-LSP being LSRA-LSRC-LSRD.

Figure 1-2200 Schematic diagram of the disjoint algorithm

• CSPF calculates separate primary and hot-standby CR-LSPs only when the network topology permits. If there are no two completely separate CR-LSPs, CSPF calculates the primary and hot-standby CR-LSPs based on the original CSPF algorithm.

• The disjoint algorithm is mutually exclusive with the explicit path and hop limit. Ensure that these features are not deployed before enabling the disjoint algorithm. If this algorithm has been enabled, these features cannot be deployed.

• After you enable the disjoint algorithm, the shared risk link group (SRLG), if configured, becomes ineffective.

• If an affinity constraint is configured, the disjoint algorithm takes effect only when the primary and backup CR-LSPs have the same affinity property or no affinity property is configured for the primary and backup CR-LSPs.

Application Scenarios

This feature applies to scenarios where RSVP-TE tunnels and hot standby are deployed.

Benefits

Isolated CR-LSP computation enables CSPF to isolate the primary and hot-standby CR-LSPs if possible. This feature brings the following benefits:

• Improves the reliability of hot backup protection.

• Reduces the maintenance workload as explicit path information does not need to be maintained.

Background

If a device is unable to store new link state protocol data units (LSPs) or use LSPs to update its link state database (LSDB) information, the device will calculate incorrect routes, causing forwarding failures. The IS-IS overload function enables the device to set the device to the IS-IS overload state to prevent such forwarding failures. By configuring the ingress to establish a CR-LSP that excludes the overloaded IS-IS device, the association between CR-LSP establishment and the IS-IS overload function helps the CR-LSP reliably transmit MPLS TE traffic.

Related Concepts

IS-IS overload state

When a device cannot store new LSPs or use LSPs to update its LSDB information using LSPs, the device will incorrectly calculate IS-IS routes. In this situation, the device will enter the overload state. For example, an IS-IS device becomes overloaded if its memory resources decrease to a specified threshold or if an exception occurs on the device. A device can be manually configured to enter the IS-IS overload state.

Implementation

In Figure 1-2201, RT1 supports the association between CR-LSP establishment and the IS-IS overload function. RT3 and RT4 support the IS-IS overload function.

Figure 1-2201 CR-LSP establishment and IS-IS overload association

Background

Carriers use CR-LSP hot standby or TE FRR to improve MPLS TE tunnel reliability. However, in real-world situations protection failures can occur, requiring the SRLG technique to be configured as a preventative measure, as the following example demonstrates.

Figure 1-2202 Networking diagram for an SRLG

The primary tunnel is established over the path PE1 → P1 → P2 → PE2 on the network shown in Figure 1-2202. The link between P1 and P2 is protected by a TE FRR bypass tunnel established over the path P1 → P3 → P2.

In the lower part of Figure 1-2202, core nodes P1, P2, and P3 are connected using a transport network device. They share some transport network links marked in yellow. If a fault occurs on a shared link, both the primary and FRR bypass tunnels are affected, causing an FRR protection failure. An SRLG can be configured to prevent the FRR bypass tunnel from sharing a link with the primary tunnel, ensuring that FRR properly protects the primary tunnel.

Related Concepts

An SRLG is a set of links at the same risk of faults. If a link in an SRLG fails, other links also fail. If a link in this group is used by a hot-standby CR-LSP or FRR bypass tunnel, the hot-standby CR-LSP or FRR bypass tunnel cannot provide protection.

Implementation

An SRLG link attribute is a number and links with the same SRLG number are in a single SRLG.

Interior Gateway Protocol (IGP) TE advertises SRLG information to all nodes in a single MPLS TE domain. The constrained shortest path first (CSPF) algorithm uses the SRLG attribute together with other constraints, such as bandwidth, to calculate a path.

The MPLS TE SRLG works in either of the following modes:

• Strict mode: The SRLG attribute is a necessary constraint used by CSPF to calculate a path for a hot-standby CR-LSP or an FRR bypass tunnel.

• Preferred mode: The SRLG attribute is an optional constraint used by CSPF to calculate a path for a hot-standby CR-LSP or FRR bypass tunnel. For example, if CSPF fails to calculate a path for a hot-standby CR-LSP based on the SRLG attribute, CSPF recalculates the path, regardless of the SRLG attribute.

Usage Scenario

The SRLG attribute is used in either the TE FRR or CR-LSP hot-standby scenario.

Benefits

The SRLG attribute limits the selection of a path for a hot-standby CR-LSP or an FRR bypass tunnel, which prevents the primary and bypass tunnels from sharing links with the same risk level.

Related Concepts

As shown in Figure 1-2203, concepts related to a tunnel protection group are as follows:

• Working tunnel: a tunnel to be protected.

• Protection tunnel: a tunnel that protects a working tunnel.

• Protection switchover: quickly switches traffic from a faulty working tunnel to a protection tunnel in a tunnel protection group, which improves network reliability.

Figure 1-2203 Tunnel protection group

A primary tunnel (tunnel-1) and a protection tunnel (tunnel-2) are established on LSRA on the network shown in Figure 1-2203.

On LSRA (ingress), tunnel-2 is configured as a protection tunnel for tunnel-1 (primary tunnel). If the ingress detects a fault in tunnel-1, traffic switches to tunnel-2, and LSRA attempts to reestablish tunnel-1. If tunnel-1 is successfully established, LSRA determines whether to switch traffic back to the primary tunnel based on the configured policy.

Implementation

An MPLS TE tunnel protection group uses a pre-configured protection tunnel to protect traffic on the working tunnel to improve tunnel reliability. Therefore, networking planning needs to be performed before you deploy MPLS TE tunnel protection groups. To ensure the improved performance of the protection tunnel, the protection tunnel must exclude links and nodes through which the working tunnel passes.

Table 1-925 describes the implementation of a tunnel protection group.

Differences Between CR-LSP Backup and a Tunnel Protection Group

BFD for TE Deployment

The networking shown in Figure 1-2206 applies to both BFD for TE CR-LSP and BFD for hot-standby CR-LSP.

Figure 1-2206 BFD for TE deployment

On the network shown in Figure 1-2206, a primary CR-LSP is established along the path LSRA -> LSRB, and a hot-standby CR-LSP is configured. A BFD session is set up between LSRA and LSRB to detect faults on the link of the primary CR-LSP. If a fault occurs on the link of the primary CR-LSP, the BFD session rapidly notifies LSRA of the fault. After receiving the fault information, LSRA rapidly switches traffic to the hot-standby CR-LSP to ensure traffic continuity.

Benefits

No tunnel protection is provided in the NG-MVPN over P2MP TE function or VPLS over P2MP TE function. If a tunnel fails, traffic can only be switched using route change-induced hard convergence, which renders low performance. This function provides dual-root 1+1 protection for the NG-MVPN over P2MP TE function and VPLS over P2MP TE function. If a P2MP TE tunnel fails, BFD for P2MP TE rapidly detects the fault and switches traffic, which improves fault convergence performance and reduces traffic loss.

Principles

Figure 1-2207 BFD for P2MP TE principles

In Figure 1-2207, BFD is enabled on the root PE1 and the backup root PE2. Leaf nodes UPE1 to UEP4 are enabled to passively create BFD sessions. Both PE1 and PE2 sends BFD packets to all leaf nodes along P2MP TE tunnels. The leaf nodes receive the BFD packets transmitted only on the primary tunnel. If a leaf node receives detection packets within a specified interval, the link between the root node and leaf node is working properly. If a leaf node fails to receive BFD packets within a specified interval, the link between the root node and leaf node fails. The leaf node then rapidly switches traffic to a protection tunnel, which reduces traffic loss.

Background

When a Layer 2 device is deployed on a link between two RSVP nodes, an RSVP node can only use the Hello mechanism to detect a link fault. For example, on the network shown in Figure 1-2208, a switch exists between P1 and P2. If a fault occurs on the link between the switch and P2, P1 keeps sending Hello packets and detects the fault after it fails to receive replies to the Hello packets. The fault detection latency causes seconds of traffic loss. To minimize packet loss, BFD for RSVP can be configured. BFD rapidly detects a fault and triggers TE FRR switching, which improves network reliability.

Figure 1-2208 BFD for RSVP

Implementation

BFD for RSVP monitors RSVP neighbor relationships.

Unlike BFD for CR-LSP and BFD for TE that support multi-hop BFD sessions, BFD for RSVP establishes only single-hop BFD sessions between RSVP nodes to monitor the network layer.

BFD for RSVP, BFD for OSPF, BFD for IS-IS, and BFD for BGP can share a BFD session. When protocol-specific BFD parameters are set for a BFD session shared by RSVP and other protocols, the smallest values take effect. The parameters include the minimum intervals at which BFD packets are sent, minimum intervals at which BFD packets are received, and local detection multipliers.

Usage Scenario

BFD for RSVP applies to a network on which a Layer 2 device exists between the TE FRR point of local repair (PLR) on a bypass CR-LSP and an RSVP node on the primary CR-LSP.

Benefits

BFD for RSVP improves reliability on MPLS TE networks with Layer 2 devices.

Background

After an RSVP-TE LSP is established, the system sets the LSP status to up, without waiting for forwarding relationships to be completely established between nodes on the forwarding path. If service traffic is imported to the LSP before all forwarding relationships are established, some early traffic may be lost.

Self-ping can address this issue by checking whether an LSP can properly forward traffic.

Implementation

With self-ping enabled, an ingress constructs a UDP packet carrying an 8-byte session ID and adds an IP header to the packet to form a self-ping IP packet. Figure 1-2210 shows the format of a self-ping IP packet. In a self-ping IP packet, the destination IP address is the LSR ID of the ingress, the source IP address is the LSR ID of the egress, the destination port number is 8503, and the source port number is a variable ranging from 49152 to 65535.

Figure 1-2210 Format of a self-ping IP packet

Figure 1-2211 shows the self-ping process. In the example network, a P2P RSVP-TE tunnel is established from PE1 to PE2. Each of the numbers 100, 200, and 300 is an MPLS label assigned by a downstream node to its upstream node through RSVP Resv messages.

Self-ping is enabled on PE1 (ingress). After PE1 receives a Resv message, it constructs a self-ping IP packet and forwards the packet along the P2P RSVP-TE LSP. The outgoing label of the packet is 100, same as the label carried in the Resv message. After the self-ping IP packet is forwarded to PE2 (egress) hop by hop, the label is popped out, and the self-ping IP packet is restored.

The destination IP address of the packet is the LSR ID of PE1. PE2 searches the IP routing table for a route matching the destination IP address of the self-ping IP packet, and then sends the packet to PE1 along the matched route. After PE1 receives the self-ping IP packet, PE1 finds a P2P RSVP-TE LSP that matches the session ID carried in the packet. If a matching LSP is found, PE1 considers the LSP normal, sets the LSP status to up, and uses the LSP to transport traffic. The LSP self-ping test is then complete.

Figure 1-2211 Self-ping process

If PE1 does not receive the self-ping IP packet, it sends a new self-ping packet. If PE1 does not receive the self-ping IP packet before the detection period expires, it considers the P2P RSVP-TE LSP faulty and does not use the LSP to transport traffic.

Benefits

Self-ping detects the actual status of RSVP-TE LSPs, improving service reliability.

Principles

RSVP messages are sent over Raw IP with no security mechanism and expose themselves to being modified and expose devices to attacks. These packets are easy to modify, and a device receiving these packets is exposed to attacks.

RSVP authentication parameters are as follows:

Key: The same key must be configured on two RSVP nodes before they perform RSVP authentication. A node uses this key to compute a digest for a packet to be sent based on the HMAC-MD5 (Keyed-Hashing for Message Authentication-Message Digest 5) algorithm. The packet carrying the digest as an integrity object is sent to a remote node. After receiving the packet, the remote node uses the same key and algorithm to compute a digest for the packet, and compares the computed digest with the one carried in the packet. If they are the same, the packet is accepted; if they are different, the packet is discarded.

HMAC-MD5 authentication has low security. In order to ensure better security, it is recommended to use Keychain authentication and use a more secure algorithm, such as HMAC-SHA-256.

Sequence number: In addition, each packet is assigned a 64-bit monotonically increasing sequence number before being sent, which prevents replay attacks. After receiving the packet, the remote node checks whether the sequence number is in an allowable window. If the sequence number in the packet is smaller than the lower limit defined in the window, the receiver considers the packet as a replay packet and discards it.

RSVP authentication also introduces handshake messages. If a receiver receives the first packet from a transmit end or packet mis-sequence occurs, handshake messages are used to synchronize the sequence number windows between the RSVP neighboring nodes.

Authentication lifetime: Network flapping causes an RSVP neighbor relationship to be deleted and created alternatively. Each time the RSVP neighbor relationship is created, the handshake process is performed, which delays the establishment of a CR-LSP. The RSVP authentication lifetime is introduced to resolve the problem. If a network flaps, a CR-LSP is deleted and created. During the deletion, the RSVP neighbor relationship associated with the CR-LSP is retained until the RSVP authentication lifetime expires.

Authentication Key Management

An HMAC-MD5 key is entered in either ciphertext or simple text on an RSVP interface or node. An HMAC-MD5 key has the following characteristics:

• A unique key must be assigned to each protocol.
• A single key is assigned to each interface and node. The key can be reconfigured but cannot be changed.

Key Authentication Configuration Scope

RSVP authentication keys can be configured on RSVP interfaces and nodes.

• Local interface-based key

  A local interface-based key is configured on an interface. The key takes effect on packets sent and received on this interface.

• Neighbor node-based key

  A neighbor node-based key is associated with the label switch router (LSR) ID of an RSVP node. The key takes effect on packets sent and received by the local node.

• Neighbor address-based key

  A neighbor address-based key is associated with the IP address of an RSVP interface. The key takes effect on the following packets:

  • Received packets with the source or next-hop address the same as the configured one
  • Sent packets with the destination or next-hop address the same as the configured one

On an RSVP node, if the local interface-, neighbor node-, and neighbor address-based keys are configured, the neighbor address-based key takes effect; the neighbor node-based key takes effect if the neighbor address-based key fails; if the neighbor node-based key fails, the local interface-based key takes effect.

A specific RSVP authentication key is configured in a specific situation:

• Neighbor node-key usage scenario:

  • If multiple links or hops exist between two RSVP nodes, only a neighbor node-based key needs to be configured, which simplifies the configuration. Two RSVP nodes authenticate all packets exchanged between them based on the key.

  • On a TE FRR network, packets are exchanged on an indirect link between a Point of Local Repair (PLR) node and a Merge Point (MP) node.

• Local interface-based key usage scenario

  Two RSVP nodes are directly connected and authenticate packets that are sent and received by their indirectly connected interfaces.

• Neighbor address-key usage scenarios

  • Two RSVP nodes cannot obtain the LSR ID of each other (for example, on an inter-domain network).
  • The PLR and MP authenticate packets with specified interface addresses.

The keychain key is recommended.

MPLS DS-TE Background

• Advantages and disadvantages of MPLS TE

  MPLS TE establishes an LSP by using available resources along links, which provides guaranteed bandwidth for specific traffic to prevent congestion occurring whenever the network is stable or failed. MPLS TE can also precisely control traffic paths so that existing bandwidth can be efficiently used.

  MPLS TE, however, cannot provide differentiated QoS guarantees for traffic of different types. For example, there are two types of traffic: voice traffic and video traffic. Video frames may be retransmitted over a long period of time, so it may be required that video traffic be of a higher drop priority than voice traffic. MPLS TE does not classify traffic but integrates voice traffic and video traffic into the same drop priority.

  Figure 1-2212 MPLS TE
  

• Advantages and disadvantages of the MPLS DiffServ model

  The MPLS DiffServ model classifies user services and performs differentiated traffic forwarding behaviors based on the service class, meeting various QoS requirements. The DiffServ model provides good scalability. It is because data streams of multiple services are mapped to only several CoSs and the amount of information to be maintained is in direct proportion to the number of data flow types, not the number of data flows.

  The DiffServ model, however, can reserve resources only on a single node. QoS cannot be guaranteed for the entire path.

• Disadvantages of using both MPLS DiffServ and MPLS TE

  In some usage scenarios, using MPLS DiffServ or MPLS TE alone cannot meet requirements.

  For example, a link carries both voice and data services. To ensure the quality of voice services, you must lower voice traffic delays. The sum delay is calculated based on this formula:

  Sum delay = Delay in processing packets + Delay in transmitting packets

  The delay in processing packets is calculated based on this formula:

  Delay in processing packets = Forwarding delay + Queuing delay

  When the path is specified, the delay in transmitting packets remains unchanged. To shorten the sum delay for voice traffic, reduce the delay in processing voice packets on each hop. When traffic congestion occurs, the more packets, the longer the queue, and the higher the delay in processing packets. Therefore, you must restrict the voice traffic on each link.

  Figure 1-2213 Using MPLS TE
  

  In Figure 1-2213, the bandwidth of each link is 100 Mbit/s, and all links share the same metric. Voice traffic is transmitted from R1 to R4 and from R2 to R4 at the rate of 60 Mbit/s and 40 Mbit/s, respectively. Traffic from R1 to R4 is transmitted along the LSP over the path R1 → R3 → R4, with the ratio of voice traffic being 60% between R3 and R4. Traffic from R2 to R4 is transmitted along the LSP over the path R2 → R3 → R7 → R4, with the ratio of voice traffic being 40% between R7 and R4.

  If the link between R3 and R4 fails, as shown in Figure 1-2214, the LSP between R1 and R4 changes to the path R1 → R3 → R7 → R4 because this path is the shortest path with sufficient bandwidth. At this time, the ratio of voice traffic from R7 to R4 reaches 100%, causing the sum delay of voice traffic to prolong.

  Figure 1-2214 Link fails
  

  MPLS DiffServ-Aware Traffic Engineering (DS-TE) can resolve this problem.

What Is MPLS DS-TE?

MPLS DS-TE combines MPLS TE and MPLS DiffServ to provide QoS guarantee.

The class type (CT) is used in DS-TE to allocate resources based on the service class. To provide differentiated services, DS-TE divides the LSP bandwidth into one to eight parts, each part corresponding to a CoS. Such a collection of bandwidths of an LSP or a group of LSPs with the same service class are called a CT. DS-TE maps traffic with the same per-hop behavior (PHB) to one CT and allocates resources to each CT.

Defined by the IETF, DS-TE supports up to eight CTs, marked CTi, in which i ranges from 0 to 7.

If an LSP has a single CT, the LSP is also called a single-CT LSP.

DS Field

To implement DiffServ, the ToS field in an IPv4 header is redefined in relevant standards and then called the Differentiated Services (DS) field. In the DS field, higher two bits are reserved and lower six bits are the DS codepoint (DSCP).

PHB

Per-Hop Behavior (PHB) is used to describe the next action on packets with the same DSCP. Commonly, PHB contains traffic traits, such as delay and packet loss rate.

The IETF defines the existing three standard PHBs: Expedited Forwarding (EF), Assured Forwarding (AF), and Best-Effort (BE). BE is the default PHB.

CT

To provide differentiated services, DS-TE divides the LSP bandwidth into one to eight parts, each part corresponding to a CoS. Such a collection of bandwidths of an LSP or a group of LSPs with the same service class are called a CT. A CT can transmit only the traffic of a CoS.

Defined by the IETF, DS-TE supports up to eight CTs, marked CTi, in which i ranges from 0 to 7.

TE-Class

A TE-class refers to a combination of a CT and a priority, in the format of <CT, priority>.

The priority is the priority of a CR-LSP in a TE-class mapping table, not the EXP value in the MPLS header. The priority value is an integer ranging from 0 to 7. The smaller the value, the higher the priority is. When you create a CR-LSP, you can set the setup and holding priorities for it and CT bandwidth values. A CR-LSP can be established only when both <CT, setup-priority> and <CT, holding-priority> exist in a TE-class mapping table. Assume that the TE-class mapping table of a node contains only TE-Class [0] = <CT0, 6> and TE-Class [1] = <CT0, 7>, only the following three types of CR-LSPs can be successfully set up:

• Class-Type = CT0, setup-priority = 6, holding-priority = 6
• Class-Type = CT0, setup-priority = 7, holding-priority = 6
• Class-Type = CT0, setup-priority = 7, holding-priority = 7

The combination of setup-priority = 6 and hold-priority = 7 does not exist because the setup priority cannot be higher than the holding priority on a CR-LSP.

CTs and priorities can be in any combination. Therefore, there are 64 TE-classes theoretically. The NetEngine 8000 F supports a maximum of eight TE-classes, which are specified by users.

DS-TE Modes

DS-TE has two modes:

• IETF mode: The IETF mode is defined by the IETF and supports 64 TE-classes by combining 8 CTs and 8 priorities. The NetEngine 8000 F supports up to 8 TE-classes.

• Non-IETF mode: The non-IETF mode is not defined by the IETF and supports 8 TE-classes by combining CT0 and 8 priorities.

TE-class mapping table

The TE-class mapping table consists of a group of TE-classes. On the NetEngine 8000 F, the TE-class mapping table consists of a maximum of 8 TE-classes. It is recommended that the same TE-class mapping table be configured on all LSRs on an MPLS network.

BCM

The Bandwidth Constraints Model (BCM) is used to define the maximum number of Bandwidth Constraints (BCs), which CTs can use the bandwidth of each BC, and how to use BC bandwidth.

Basic Implementation

A label edge router (LER) of a DiffServ domain sorts traffic into a small number of classes and marks class information in the Differentiated Service Code Point (DSCP) field of packets. When scheduling and forwarding packets, LSRs select Per-Hop Behaviors (PHBs) based on DSCP values.

The EXP field in the MPLS header carries DiffServ information. The key to implementing DS-TE is to map the DSCP value (with a maximum of 64 values) to the EXP field (with a maximum of 8 values). Relevant standards provide the following solutions:

The NetEngine 8000 F supports E-LSPs. The mapping from the DSCP value to the EXP field complies with the definition of relevant standards. The mapping from the EXP field to the PHB is manually configured.

The class type (CT) is used in DS-TE to allocate resources based on the class of traffic. DS-TE maps traffic with the same PHB to one CT and allocates resources to each CT. Therefore, DS-TE LSPs are established based on CTs. Specifically, when DS-TE calculates an LSP, it needs to take CTs and obtainable bandwidth of each CT as constraints; when DS-TE reserves resources, it also needs to consider CTs and their bandwidth requirements.

IGP Extension

To support DS-TE, related standards extend an IGP by introducing an optional sub-TLV (Bandwidth Constraints sub-TLV) and redefining the original sub-TLV (Unreserved Bandwidth sub-TLV). This helps inform and collect information about reservable bandwidths of CTs with different priorities.

RSVP Extension

To implement IETF DS-TE, the IETF extends RSVP by defining a CLASSTYPE object for the Path message in related standards. For details about CLASSTYPE objects, see related standards.

After an LSR along an LSP receives an RSVP Path message carrying CT information, an LSP is established if resources are sufficient. After the LSP is successfully established, the LSR recalculates the reservable bandwidth of CTs with different priorities. The reservation information is sent to the IGP module to advertise to other nodes on the network.

BCM

Currently, the IETF defines the following bandwidth constraint models (BCMs):

Differences Between the IETF Mode and Non-IETF Mode

The NetEngine 8000 F supports both the IETF and non-IETF modes. Table 1-927 describes differences between the two modes.

If bandwidth constraints or CT or CT reserved bandwidth is configured for a tunnel, the IETF and non-IETF modes cannot be switched to each other.

Table 1-927 Differences between the IETF and non-IETF modes

DS-TE Mode	Non-IETF Mode	IETF Mode
Bandwidth model	N/A	Supports the RDM and MAM.
CT type	Supports CT0.	Supports CT0 through CT7.
BC type	Supports BC0.	Supports BC0 through BC7.
TE-class mapping table	The TE-class mapping table can be configured but does not take effect.	The TE-class mapping table can be configured and takes effect.
IGP message	The priority-based reservable bandwidth is carried in the Unreserved Bandwidth sub-TLV.	The CT information is carried in the Unreserved Bandwidth sub-TLV and Bandwidth Constraints sub-TLV. Unreserved Bandwidth sub-TLV: carries unreserved bandwidth of eight TE-classes. The sub-TLV unit is bytes/second. Bandwidth Constraints sub-TLV: carries BCM model information and BC bandwidth in RDM and MAM.
RSVP message	The CT information is carried in the ADSPEC object.	CT information is carried in the CLASSTYPE object.

Service Overview

Networking Description

Point-to-multipoint (P2MP) traffic engineering (TE) is deployed on an IP/MPLS backbone network to resolve multicast traffic congestion and maintain reliability. Figure 1-2231 shows the application of P2MP TE for multicast services on an IP/MPLS backbone network.

Figure 1-2231 P2MP TE application for multicast services

Feature Deployment