MPLS and RSVP-TE

In This Chapter

This chapter provides information required to configure Multiprotocol Label Switching (MPLS) and Resource Reservation Protocol for Traffic Engineering (RSVP-TE) for the 7705 SAR. For information on dynamic LSPs with LDP, refer to the chapter Label Distribution Protocol.

Topics in this chapter include:

  1. Overview
  2. MPLS
  3. RSVP and RSVP-TE
  4. RSVP-TE Signaling
  5. LSP Redundancy
  6. Fast Reroute (FRR)
  7. Shared Risk Link Groups
  8. RSVP-TE Graceful Shutdown
  9. MPLS Service Usage
  10. MPLS and RSVP-TE Configuration Process Overview
  11. Configuration Notes
  12. Configuring MPLS and RSVP-TE with CLI
  13. MPLS and RSVP-TE Command Reference

Overview

The 7705 SAR provides MPLS technology using static LSPs, RSVP-TE for traffic-engineered signaled routing of LSPs, and LDP for non-traffic-engineered signaled routing of LSPs. A network operator may choose to use any combination of static LSPs, RSVP-TE, and LDP to establish paths for services. Furthermore, the 7705 SAR can be used as an ingress and egress Label Edge Router (ILER and ELER), and as a transit router. A transit router is also referred to as a Label Switch Router (LSR). Consider RSVP-TE and LDP as the Layer 2.5 protocols.

OSPF and IS-IS are the interior gateway protocols with traffic engineering extensions (IGP-TE) available to the 7705 SAR. These are the Layer 3 protocols. Typically, one or the other of these gateway protocols will be in use in the network. Whichever protocol is the chosen gateway protocol, it must be working in order for LDP or RSVP-TE to function. These Layer 3 protocols identify the next hop, which is information needed by the Layer 2.5 protocols (LDP or RSVP-TE) in order to assign labels.

In addition, the 7705 SAR provides link and node redundancy protection through LSP redundancy and Fast Reroute (FRR) features.

The LSP redundancy and FRR features have the ability to take shared risk link groups (SRLGs) into consideration when the Constrained Shortest Path First (CSPF) algorithm is used to determine an alternate LSP. The selection of a route is determined by the IGP-TE protocol. The added constraints imposed by SRLGs and CSPF will ensure that the redundant route selected will be unique from the principal route (route being protected); that is, it will use physical equipment that is different from the equipment that carries the principal route. CSPF will constrain the alternate route to be the shortest possible alternative route. Note that there may be more than one alternative route.

MPLS

Multiprotocol Label Switching (MPLS) is a label switching technology that provides the ability to set up connection-oriented paths over a connectionless IP network. MPLS facilitates network traffic flow and provides a mechanism to engineer network traffic patterns independently from routing tables. MPLS sets up a specific path for a sequence of packets. The packets are identified by a label inserted into each packet.

MPLS is independent of any routing protocol but is considered multiprotocol because it works with protocols such as IP, ATM, Ethernet, and circuit emulation.

This section contains the following topics:

  1. Traffic Engineering for MPLS
  2. MPLS Label Stack
  3. Label Edge and Label Switch Routers
  4. LSP Types

Traffic Engineering for MPLS

Without traffic engineering (TE), routers route traffic according to the Shortest Path First (SPF) algorithm, disregarding congestion or packet types.

With traffic engineering, network traffic is routed efficiently to maximize throughput and minimize delay. Traffic engineering facilitates traffic flows to be mapped to the destination through a less-congested path than the one selected by the SPF algorithm.

MPLS directs a flow of IP packets along a label switched path (LSP). LSPs are simplex, meaning that the traffic flows in one direction (unidirectional) from an ingress router to an egress router. Two LSPs are required for duplex (bidirectional) traffic. Each LSP carries traffic in a specific direction, forwarding packets from one router to the next across the MPLS domain.

When an ingress router receives a packet, it adds an MPLS header to the packet and forwards it to the next hop in the LSP. The labeled packet is forwarded along the LSP path (from next hop to next hop) until it reaches the destination point. The MPLS header is removed and the packet is forwarded based on Layer 3 information such as the IP destination address. The physical path of the LSP is not constrained to the shortest path that the IGP would choose using SPF to reach the destination IP address.

TE Metric and IGP Metric

When the TE metric is selected for an LSP, the shortest path computation will select an LSP path based on the TE metric constraints instead of the IGP metric (for OSPF and IS-IS), which is the default metric. The user configures the TE metric under the router>mpls> interface context and the IGP metric under the router>ospf>area>interface context (for OSPF) and the router>isis>if>level context (for IS-IS). Both the TE and IGP metrics are advertised by OSPF and IS-IS for each link in the network.

The TE metric is part of the traffic engineering extensions of the IGP protocols. For more information on the OSPF and IS-IS routing protocols, refer to the 7705 SAR OS Routing Protocols Guide.

Typically, the TE metric is used to allow Constrained Shortest Path First (CSPF) to represent a dual TE topology for the purpose of computing LSP paths, where one TE topology is based on the RSVP-TE database and the other is based on the IGP-TE database.

An LSP dedicated to real-time and delay-sensitive user and control traffic has its path computed by CSPF using the TE metric. The user configures the TE metric to represent the amount of delay, or combined delay and jitter, of the link. In this case, the shortest path satisfying the constraints of the LSP path will effectively represent the shortest-delay path.

An LSP dedicated to non-delay-sensitive user and control traffic has its path computed by CSPF using the IGP metric. The IGP metric could represent the link bandwidth or some other value as required.

When the use of the TE metric is enabled for an LSP, the CSPF process will first eliminate all links in the network topology that do not meet the constraints specified for the LSP path; the constraints include bandwidth, admin-groups, and hop limit. CSPF will then run the SPF algorithm on the remaining links. The shortest path among all the SPF paths will be selected based on the TE metric instead of the IGP metric. Note that the TE metric is only used in CSPF computations for MPLS paths and not in the regular SPF computation for IP reachability.

MPLS Label Stack

Routers that support MPLS are known as Label Edge Routers (LERs) and Label Switch Routers (LSRs). MPLS requires a set of procedures to enhance network layer packets with label stacks, which turns them into labeled packets. In order to initiate, transmit, or terminate a labeled packet on a particular data link, an LER or LSR must support the encoding technique which, when given a label stack and a network layer packet, produces a labeled packet.

In MPLS, packets can carry not just one label, but a set of labels in a stack. An LSR can swap the label at the top of the stack, pop the stack (that is, remove the top label), or swap the label and push one or more labels onto the stack. The processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that other labels may have been above it in the past or that other labels may be below it at present.

As described in RFC 3032, MPLS Label Stack Encoding, the label stack is represented as a sequence of “label stack entries”. Each label stack entry is represented by 4 octets. Figure 1 shows the structure of a label and Table 2 describes the fields. Figure 2 shows the label placement in a packet.

Figure 1:  Label Structure 
Table 2:  Packet/Label Field Description  

Field

Description

Label

This 20-bit field carries the actual value (unstructured) of the label.

Exp

This 3-bit field is reserved for experimental use. It is currently used for Class of Service (CoS).

S

This bit is set to 1 for the last entry (bottom) in the label stack and 0 for all other label stack entries.

TTL

This 8-bit field is used to encode a time-to-live value.

A stack can carry several labels, organized in a last in/first out order. The top of the label stack appears first in the packet and the bottom of the stack appears last (Figure 2).

Figure 2:  Label Packet Placement 

The label value at the top of the stack is looked up when a labeled packet is received. A successful lookup reveals:

  1. the next hop where the packet is to be forwarded
  2. the operation to be performed on the label stack before forwarding

In addition, the lookup may reveal outgoing data link encapsulation and other information needed to properly forward the packet.

An empty label stack can be thought of as an unlabeled packet. An empty label stack has zero (0) depth. The label at the bottom of the stack is referred to as the Level 1 label. The label above it (if it exists) is the Level 2 label, and so on. The label at the top of the stack is referred to as the Level m label.

Label Values

The 7705 SAR uses RSVP-TE and LDP protocols for label forwarding, For packet-based services such as VLL, the 7705 SAR uses T-LDP for signaling PW labels between peer nodes.

Packets traveling along an LSP are identified by the packet label, which is the 20-bit, unsigned integer (see Label Edge and Label Switch Routers). The range is 0 through 1 048 575. Label values 0 to 15 are reserved and are defined below:

  1. A value of 0 represents the IPv4 Explicit NULL label. This label value is legal only at the bottom of the label stack if the label stack is immediately followed by an IPv4 header, in which case the packet forwarding is based on the IPv4 header. If the IPv4 Explicit NULL label is not at the bottom of the label stack, then the packet forwarding is based on the subsequent label.
  2. A value of 1 represents the router alert label. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual packet forwarding is determined by the label beneath it in the stack. However, if the packet is further forwarded, the router alert label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the router alert option in IP packets. Since this label cannot be at the bottom of the stack, it is not associated with a particular network layer protocol.
  3. A value of 3 represents the Implicit NULL label. An LER advertises this when it is requesting penultimate hop popping and expecting unlabeled packets. Thus, the label value 3 should never appear in the label stack.
  4. Values 4 through 15 are reserved for future use.

Table 3 lists the label ranges available for use by ingress labels (pop labels).

Table 3:  Ingress Label Values (Pop Labels)  

Label Values

Description

16 through 31

Reserved for future use

32 through 1023

Available for static outer LSP tunnel label assignment

1024 through 2047

Reserved for future use

2048 through 18 431

Statically assigned for services (inner pseudowire label)

32 768 through 131 071

Dynamically assigned for both MPLS and services

131 072 through 1 048 575

Reserved for future use

Table 4 lists the label ranges available for use by egress labels (push labels).

Table 4:  Egress Label Values (Push Labels)  

Label Values

Description

16 through 1 048 575

Can be used for static LSP tunnel and static PW labels

16 through 1 048 575

Can be dynamically assigned for both MPLS tunnel labels and PW labels

Label Edge and Label Switch Routers

A 7705 SAR performs different functions based on its position in an LSP—ingress, egress, or transit—as described in the following list:

  1. ingress Label Edge Router (ILER) — The router at the beginning of an LSP is the ILER. The ingress router encapsulates packets with an MPLS header and forwards the packets to the next router along the path. An LSP can only have one ingress router.
  2. Label Switching Router (LSR) — An LSR can be any intermediate router in the LSP between the ingress and egress routers, swapping the incoming label with the outgoing MPLS label and forwarding the MPLS packets it receives to the next router in the LSP. An LSP can have 0 to 253 transit routers.
  3. egress Label Edge Router (ELER) — The router at the end of an LSP is the ELER. The egress router strips the MPLS encapsulation, which changes it from an MPLS packet to a data packet, and then forwards the packet to its final destination using information in the forwarding table. An LSP can have only one egress router. The ingress and egress routers in an LSP cannot be the same router.

A router in a network can act as an ingress, egress, or transit router for one or more LSPs, depending on the network design.

Constrained-path LSPs are signaled and are confined to one Interior Gateway Protocol (IGP) area. These LSPs cannot cross an autonomous system (AS) boundary.

Static LSPs can cross AS boundaries. The intermediate hops are manually configured so that the LSP has no dependence on the IGP topology or a local forwarding table.

LSP Types

The following LSP types are supported:

  1. static LSPs — a static LSP specifies a static path. All routers that the LSP traverses must be configured manually with labels. No RSVP-TE or LDP signaling is required. Static LSPs are discussed in this chapter.
  2. signaled LSPs — LSPs are set up using the RSVP-TE or LDP signaling protocol. The signaling protocol allows labels to be assigned from an ingress router to the egress router. Signaling is triggered by the ingress routers. Configuration is required only on the ingress router and is not required on intermediate routers. Signaling also facilitates path selection. RSVP-TE is discussed in this chapter, and LDP is discussed in Label Distribution Protocol.
    There are two types of signaled LSP:
    1. explicit-path LSPs — MPLS uses RSVP-TE to set up explicit-path LSPs. The hops within the LSP are configured manually. The intermediate hops must be configured as either strict or loose, meaning that the LSP must take either a direct path from the previous hop router to this router (strict) or can traverse other routers (loose). Thus, you can control how the path is set up. Explicit-path LSPs are similar to static LSPs but require less configuration. See RSVP and RSVP-TE. Note that an explicit path that has not specified any hops will follow the IGP route.
    2. constrained-path LSPs — for constrained-path LSPs, the intermediate hops of the LSP are dynamically assigned. A constrained-path LSP relies on the Constrained Shortest Path First (CSPF) routing algorithm to find a path that satisfies the constraints for the LSP. In turn, CSPF relies on the topology database provided by an extended IGP such as OSPF or IS-IS.
      Once the path is found by CSPF, RSVP-TE uses the path to request the LSP setup. CSPF calculates the shortest path based on the constraints provided, such as bandwidth, class of service, and specified hops.

If Fast Reroute (FRR) is configured, the ingress router signals the downstream routers so that each downstream router can preconfigure a detour route for the LSP that will be used if there is a failure on the original LSP. If a downstream router does not support FRR, the request is ignored and the router continues to support the original LSP. This can cause some of the detour routes to fail, but the original LSP is not impacted. For more information on FRR, see Fast Reroute (FRR).

No bandwidth is reserved for the reroute path. If the user enters a value in the bandwidth parameter in the config>router>mpls>lsp>fast-reroute context, it will have no effect on establishing the backup LSP. The following warning message is displayed:

“The fast reroute bandwidth command is not supported in this release.”

RSVP and RSVP-TE

The Resource Reservation Protocol (RSVP) is a network control protocol used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality of service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain operational state to provide the requested service. In general, RSVP requests result in resources reserved in each node along the data path.

The Resource Reservation Protocol for Traffic Engineering (RSVP-TE) is an extended version of RSVP for MPLS. RSVP-TE uses traffic engineering extensions to support automatic signaling of LSPs. MPLS uses RSVP-TE to set up traffic-engineered LSPs. See RSVP-TE Extensions for MPLS for more information.

RSVP-TE Overview

RSVP-TE requests resources for simplex (unidirectional) flows. Therefore, RSVP-TE treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. Duplex flows require two LSPs, to carry traffic in each direction.

RSVP-TE is a signaling protocol, not a routing protocol. RSVP-TE operates with unicast and multicast routing protocols. Routing protocols determine where packets are forwarded. RSVP-TE consults local routing tables to relay RSVP-TE messages.

RSVP-TE uses two message types to set up LSPs, PATH and RESV. Figure 3 depicts the process to establish an LSP.

  1. The sender (the ingress LER (ILER)) sends PATH messages toward the receiver, (the egress LER (ELER)) to indicate the forwarding equivalence class (FEC) for which label bindings are desired. PATH messages are used to signal and request the label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type.
  2. PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream.
  3. The ELER sends label binding information in the RESV messages in response to PATH messages received.
  4. The LSP is considered operational when the ILER receives the label binding information.
Figure 3:  Establishing LSPs 

Figure 4 displays an example of an LSP path set up using RSVP-TE. The ingress label edge router (ILER 1) transmits an RSVP-TE PATH message (path: 30.30.30.1) downstream to the egress label edge router (ELER 4). The PATH message contains a label request object that requests intermediate LSRs and the ELER to provide a label binding for this path.

Figure 4:  LSP Using RSVP-TE Path Setup 

In addition to the label request object, an RSVP-TE PATH message can also contain a number of optional objects:

  1. explicit route object (ERO) — when the ERO is present, the RSVP-TE PATH message is forced to follow the path specified by the ERO (independent of the IGP shortest path)
  2. record route object (RRO) — allows the ILER to receive a listing of the LSRs that the LSP tunnel actually traverses
  3. session attribute object — controls the path setup priority, holding priority, and local rerouting features

Upon receiving a PATH message containing a label request object, the ELER transmits an RESV message that contains a label object. The label object contains the label binding that the downstream LSR communicates to its upstream neighbor. The RESV message is sent upstream towards the ILER, in a direction opposite to that followed by the PATH message. Each LSR that processes the RESV message carrying a label object uses the received label for outgoing traffic associated with the specific LSP. When the RESV message arrives at the ingress LSR, the LSP is established.

Using RSVP-TE for MPLS

Hosts and routers that support both MPLS and RSVP-TE can associate labels with RSVP-TE flows. When MPLS and RSVP-TE are combined, the definition of a flow can be made more flexible. Once an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a variety of criteria. The set of packets that are assigned the same label value by a specific node are considered to belong to the same Forwarding Equivalence Class (FEC) that defines the RSVP-TE flow.

For use with MPLS, RSVP-TE already has the resource reservation component built in, making it ideal to reserve resources for LSPs.

RSVP-TE Extensions for MPLS

The RSVP-TE extensions enable MPLS to support the creation of explicitly routed LSPs, with or without resource reservation. Several of the features enabled by these extensions were implemented to meet the requirements for traffic engineering over MPLS, which enables the creation of traffic trunks with specific characteristics. None of the TE extensions result in backward compatibility problems with traditional RSVP implementations.

To run properly, the traffic engineering capabilities of RSVP-TE require an underlying TE-enabled IGP routing protocol. The 7705 SAR supports OSPF and IS-IS with TE extensions.

Routing protocols make it possible to advertise the constraints imposed over various links in the network. For example, in order for the nodes in a network to choose the best link for signaling a tunnel, the capacity of a particular link and the amount of reservable capacity must be advertised by the IGP. RSVP-TE makes use of these constraints to request the setup of a path or LSP that traverses only those links that are part of an administrative group (admin groups are described in the following list). Thus, both RSVP-TE and the IGP-TE (that is, OSPF-TE or IS-IS-TE for the 7705 SAR) must be enabled and running simultaneously.

The following TE capabilities are supported:

  1. hop limit — the hop limit is the maximum number of LSR nodes that a given LSP can traverse, including the ingress and the egress LER nodes. Typically, the hop limit is used to control the maximum delay time for mission-critical traffic such as voice traffic.
    The hop limit applies to the primary LSP, any backup LSPs, and LSPs configured to be used in Fast Reroute (FRR) situations.
  2. admin groups — administrative groups provide a way to define which LSR nodes should be included or excluded while signaling an LSP. For example, it might be desirable to avoid some nodes or links that are known to be used heavily from being included in the path of an LSP, or to include a specific LSR node to ensure that a newly signaled RSVP-TE tunnel traverses that LSR node.
    Administrative groups apply to both primary and secondary LSPs. They are defined under the config>router>mpls context, and are applied at the MPLS interface level, as well as at the LSP and the primary and secondary LSP levels through include and exclude commands.
  3. bandwidth — the bandwidth capability (supported by RSVP-TE), is similar to the Connection Admission Control (CAC) function in ATM. During the establishment phase of RSVP-TE, the LSP PATH message contains the bandwidth reservation request. If the requested capacity is available, the RESV message confirms the reservation request. The amount of reserved bandwidth stated in the request is deducted from the amount of reservable bandwidth for each link over which the LSP traverses.
    The bandwidth capability applies to both primary and secondary LSPs, and LSPs configured to be used in Fast Reroute (FRR) situations.

Hello Protocol

The Hello protocol detects the loss of a neighbor node (node failure detection) or the reset of a neighbor’s RSVP-TE state information. In standard RSVP, neighbor monitoring occurs as part of the RSVP soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LERs. If the state is not refreshed within a specified time interval, the LSR discards the state because it assumes that either the neighbor node has been lost or its RSVP-TE state information has been reset.

The Hello protocol extension is composed of a Hello message, a Hello request object and a Hello ACK object. Hello processing between two neighbors supports independent selection of failure detection intervals. Each neighbor can automatically issue Hello request objects. Each Hello request object is answered by a Hello ACK object.

MD5 Authentication of RSVP-TE Interface

When enabled on an RSVP-TE interface, authentication of RSVP messages operates in both directions of the interface. A node maintains a security association with its neighbors for each authentication key. The following items are stored in the context of this security association:

  1. the HMAC-MD5 authentication algorithm
  2. the key used with the authentication algorithm
  3. the lifetime of the key. A key is a user-generated key using third-party software or hardware. The value is entered as a static string into the CLI configuration of the RSVP interface. The key will continue to be valid until it is removed from that RSVP interface.
  4. the source address of the sending system
  5. the latest sending sequence number used with this key identifier

The RSVP sender transmits an authenticating digest of the RSVP message, computed using the shared authentication key and a keyed hash algorithm. The message digest is included in an Integrity object that also contains a Flags field, a Key Identifier field, and a Sequence Number field. The RSVP sender complies with the procedures for RSVP message generation in RFC 2747, RSVP Cryptographic Authentication.

An RSVP receiver uses the key together with the authentication algorithm to process received RSVP messages.

If a point of local repair (PLR) node switches the path of the LSP to a bypass LSP, it does not send the integrity object in the RSVP messages over the bypass tunnel. If an integrity object is received from the merge point (MP) node, then the message is discarded since there is no security association with the next-next-hop MP node.

The 7705 SAR MD5 implementation does not support the authentication challenge procedures in RFC 2747.

RSVP-TE Signaling

RSVP-TE-based signaling provides a means to establish tunnels dynamically.

RSVP-TE uses the Downstream on Demand (DOD) label distribution mode, sending PATH messages from the ingress LER node to the egress LER, and RESV messages in the reverse direction. DOD label distribution is a router’s response to an explicit request from another router for label binding information. The DOD mode is in contrast to LDP on the 7705 SAR, which uses the Downstream Unsolicited (DU) label distribution mode for both PWs and LSPs. A router in DU mode will distribute label bindings to another router that has not explicitly requested the label bindings.

RSVP-TE signaling is supported when the 7705 SAR is deployed as an LER and as an LSR. When used as an LER, the 7705 SAR uses RSVP-TE signaling to set up constrained paths because only the LER knows all the constraints imposed on the LSP. When used as an LSR, the 7705 SAR uses RSVP-TE to interpret the RSVP-TE messages (including all the constraints).

With RSVP-TE, users can choose which services and PWs may use a particular LSP. One-to-one or many-to-one scenarios for binding PWs to RSVP-TE LSPs is supported, which is similar to binding PWs to static LSPs. Furthermore, each RSVP-TE LSP can be configured with its own set of attributes and constraints.

General Attributes of RSVP-TE

The following general attributes of RSVP-TE on the 7705 SAR are supported:

  1. Authentication
  2. OAM: BFD
  3. Timers
  4. LSP Resignal Limit
  5. RSVP-TE Message Pacing
  6. RSVP-TE Overhead Refresh Reduction
  7. RSVP-TE Reservation Styles

Authentication

In order to ensure the integrity of a peer router, authentication for RSVP-TE is supported. It can be enabled on a per-link basis and is bidirectional. Hence both of the nodes must either enable authentication or disable it on a per-peer or per-link basis. The MD5-based authentication algorithm is implemented and sequence numbers are used to keep track of messages.

OAM: BFD

Bidirectional Forwarding Detection (BFD) is supported on the 7705 SAR. In the case of BFD for RSVP-TE, an RSVP-TE enabled link is registered with the BFD state machine, and if a failure occurs the RSVP-TE interface is taken out of service. The BFD implementation on the 7705 SAR works on a hop-by-hop basis, and if BFD detects a link failure, only the two directly connected MPLS nodes are aware of that failure. If the node that detects the link failure is an LSR node, it generates PATH-ERR messages to the originators (the LER nodes) of the failing LSPs. If FRR is configured, the detecting node takes corrective action itself. See LSP Redundancy and Fast Reroute (FRR) for more information on these topics.

Timers

The following timers are implemented to ensure the successful operation of RSVP-TE:

  1. hold-timer — the hold timer defines the amount of time before an LSP is brought up and is in service, which provides protection against unreliable nodes and links
  2. resignal-timer — the resignal timer is used in conjunction with the route optimization process, especially after a reroute has occurred. If the newly computed path for an LSP has a better metric than the currently recorded hop list, then an attempt is made to resignal that LSP, and if the attempt is successful, then a make-before-break switchover occurs. If the attempt to resignal an LSP fails, the LSP continues to use the existing path and another resignal attempt is made the next time the timer expires.
    When the resignal timer expires, a trap and syslog message are generated.
  3. retry-timer — the retry timer defines a period of time before a resignal attempt is made after an LSP failure. This delay time protects network resources against excessive signaling overhead.

LSP Resignal Limit

When an LSP fails, an LER node tries to resignal it. The following limit can be configured:

  1. retry-limit — the retry limit defines the number of resignaling attempts in order to conserve the resources of the nodes in the network. There could be a serious loss of capacity due to a link failure where an infinite number of retries generate unnecessary message overhead.

RSVP-TE Message Pacing

RSVP-TE message pacing provides a means to limit the overwhelming number of RSVP-TE signaling messages that can occur in large MPLS networks during node failures. RSVP-TE message pacing allows the messages to be sent in timed intervals.

To protect nodes from receiving too many messages, the following message pacing parameters can be configured:

  1. msg-pacing — message pacing can be enabled or disabled
  2. max-burst — maximum burst defines the number of RSVP-TE messages that can be sent in the specified period of time
  3. period — period defines the interval of time used in conjunction with the max-burst parameter to send message pacing RSVP-TE messages

Message pacing needs to be enabled on all the nodes in a network to ensure the efficient operation of tier-1 nodes. Message pacing affects the number of RSVP-TE messages that a particular node can generate, not the number of messages it can receive. Thus, each node must be paced at a rate that allows the most loaded MPLS nodes to keep up with the number of messages they receive.

Note:

Typically, a tier-1 node is an aggregator of tier-2 node transmissions, which is an aggregator of tier-3 node transmissions. Tier-1 nodes are often installed at an MTSO, while tier-3 nodes are often installed at cell sites.

RSVP-TE Overhead Refresh Reduction

RFC 2961, RSVP Refresh Overhead Reduction Extensions, defines enhancements to the RSVP-TE signaling protocol that reduce refresh overhead, which are in addition to the message pacing function.

These extensions are:

  1. RSVP-TE message bundling — RSVP-TE message bundling reduces the total number of RSVP-TE messages by aggregating the status information of multiple LSPs into a single RSVP-TE PDU. The 7705 SAR supports the receipt and processing of bundled RSVP-TE messages but not the transmission of bundled messages as specified in RFC 2961, section 3.3.
  2. reliable message delivery — reliable message delivery extends RSVP-TE to support MESSAGE_ACK. Each RSVP-TE PDU has a unique message-id for sequence tracking purposes. When an RSVP-TE message arrives, the recipient acknowledges the reception of the specific message-id (this is similar to TCP ACK messages). Lost PDUs can be detected and re-sent with this method, which helps reduce the refresh rate because there are two endpoints tracking the received/lost messages.
  3. summary refresh — the summary refresh capability uses a single message-id list to replace many individual refresh messages and sends negative ACKs (NACKs) for any message-id that cannot be matched (verified). The summary refresh capability reduces the number of message exchanges and message processing between peers. It does not reduce the amount of soft state stored in the node. The term soft state refers to the control state in hosts and routers that will expire if not refreshed within a specified amount of time (see RFC 2205 for information on soft state).

These capabilities can be enabled on a per-RSVP-TE interface basis and are referred to collectively as “refresh overhead reduction extensions”. When refresh-reduction is enabled on a 7705 SAR RSVP-TE interface, the node indicates this to its peer by setting a refresh-reduction-capable bit in the flags field of the common RSVP-TE header. If both peers of an RSVP-TE interface set this bit, all three of the capabilities listed above can be used. The node monitors the setting of this bit in received RSVP-TE messages from the peer on the interface. If the bit is cleared, the node stops sending summary refresh messages. If a peer did not set the refresh-reduction-capable bit, a 7705 SAR node does not attempt to send summary refresh messages.

Also, reliable delivery of RSVP-TE messages over the RSVP-TE interface can be enabled using the reliable-delivery option.

RSVP-TE Reservation Styles

LSPs can be signaled with explicit reservation styles for the reservation of resources, such as bandwidth. A reservation style describes a set of attributes for a reservation, including the sharing attributes and sender selection attributes. The style information is part of the LSP configuration. The 7705 SAR OS supports two reservation styles:

  1. fixed filter (FF) — the fixed filter (FF) reservation style specifies an explicit list of senders and a distinct reservation for each of them. Each sender has a dedicated reservation that is not shared with other senders. Each sender is identified by an IP address and a local identification number, the LSP ID. Because each sender has its own reservation, a unique label and a separate LSP can be constructed for each sender-receiver pair. For traditional RSVP applications, the FF reservation style is ideal for a video distribution application in which each channel (or source) requires a separate pipe for each of the individual video streams.
  2. shared explicit (SE) — the shared explicit (SE) reservation style creates a single reservation over a link that is shared by an explicit list of senders. Because each sender is explicitly listed in the RESV message, different labels can be assigned to different sender-receiver pairs, thereby creating separate LSPs.

If the FRR option is enabled for the LSP and the facility FRR method is selected at the head-end node, only the SE reservation style is allowed. Furthermore, if a 7705 SAR PLR node receives a PATH message with fast reroute requested with facility method and the FF reservation style, it will reject the reservation. The one-to-one backup method supports both FF and SE styles.

LSP Redundancy

Each primary LSP can be protected by up to two secondary LSPs. When the LER detects a primary LSP failure, it signals its secondary LSPs, if any have been configured, and automatically switches to the first one that is available. LSP redundancy supports shared risk link groups (SRLG). See Shared Risk Link Groups for more information on SRLG.

LSP redundancy differs from the Fast Reroute (FRR) feature in that LSP redundancy is controlled by the LER that initiated the LSP, whereas FRR uses the node that detects the failure to take recovery action. This means that LSP redundancy takes longer to reroute traffic than FRR because failure messages need to traverse multiple hops to reach the LER and activate LSP redundancy, whereas an FRR-configured node responds immediately to bypass the failed node or link. See Fast Reroute (FRR) for more information on FRR.

The following parameters can be configured for primary and secondary LSPs:

  1. bandwidth — the amount of bandwidth needed for the secondary LSP can be reserved and can be any value; it does not need to be identical to the value reserved by the primary LSP. Bandwidth reservation can be set to 0, which is equivalent to reserving no bandwidth.
  2. inclusion and exclusion of nodes — by including or excluding certain nodes, you can ensure that the primary and secondary LSPs do not traverse the same nodes and therefore ensure successful recovery. Each secondary LSP can have its own list of included and excluded nodes.
  3. hop limit — the hop limit is the maximum number of LSR nodes that a secondary LSP can traverse, including the ingress and egress LER nodes.
  4. standby (secondary LSPs only) — when a secondary LSP is configured for standby mode, it is signaled immediately and is ready to take over traffic the moment the LER learns of a primary LSP failure. This mode is also called hot-standby mode.
    When a secondary LSP is not in standby mode, then it is only signaled when the primary LSP fails. If there is more than one secondary LSP, they are all signaled at the same time (upon detection of a primary LSP failure) and the first one to come up is used.

Fast Reroute (FRR)

FRR is a mechanism to protect against RSVP-TE signaled LSP failures by reacting to these failures as soon as possible. FRR is set up from the ILER, which signals the transit routers to precompute their backup LSPs. FRR creates a precomputed backup LSP from each node in the LSP path. If a link or LSP between two routers fails, traffic is rerouted immediately onto the precomputed backup LSP.

Note:

In order for FRR to work, CSPF must be enabled.

The 7705 SAR supports FRR facility backup and one-to-one backup.

Facility backup mode allows FRR to be enabled on an aggregate basis and protects a whole node or a whole link, regardless of the number of LSPs using that link. In other words, facility backup mode creates a common bypass tunnel to protect all LSP-paths traversing a common facility path. It provides flexibility, faster provisioning, and faster convergence times compared with one-to-one backup or LSP redundancy. One-to-one backup allows FRR to be enabled on a per-LSP basis.

With both methods, MPLS switches build many possible detour routes on the nodes between the ingress and egress nodes of an LSP. The facility backup method creates a detour route between two nodes, called a bypass tunnel, which is a single tunnel that follows the primary LSP path except where the link or node has failed. Traffic then switches to the bypass tunnel. The bypass tunnel merges with the original LSP path at the merge point (MP) as soon as possible. The one-to-one backup method creates a detour route, called a detour LSP, for each LSP that needs to be rerouted. Unlike the bypass tunnel, the detour LSP takes the best path to the termination point, and does not merge with the original LSP as soon as possible. The detour LSPs of a one-to-one backup LSP can merge at a detour merge point (DMP), which can either be at the termination point or at a point along the primary LSP.

One of the major differences between facility and one-to-one backup is the scalability offered by the protection method. In facility backup mode, all LSPs of the same type are rerouted over the bypass tunnel. Hence they are all protected against the failure of a node or link in the network. In facility backup mode, each LSR along the path verifies that it has a bypass tunnel available to meet its requirements; otherwise, if it can, it signals a new bypass tunnel based on the requirements. If a new LSP is configured for FRR facility backup, the existing backup tunnels are scanned and if any one of them can be used for recovery, it is preferred. If there are no common links, then a new bypass tunnel will be signaled, assuming that the LSP requirements can be met. One-to-one backup mode uses similar reroute and protection methods except a detour route is applied on a per-LSP basis.

The 7705 SAR uses CSPF to calculate the explicit route and dynamically signal the FRR LSP.

With facility backup mode, routers check the contents of the Record Route Object (RRO) in the received RESV message to determine the bypass tunnel endpoint in the FRR facility. For link protection, the router uses the RRO to check the IP address of the next-hop router attached to the far end of the link along with the label allocation information and to build the bypass tunnel. This label is preserved until the LSP is merged at the MP. For node protection, the router uses the RRO to determine the next-next-hop router and the label it is expecting. The collection of RRO information is enabled through the record and record-label options.

If, after this process, another LSP requests FRR using the facility backup method, then the router checks and compares its session object to the existing session object(s) and if there is a match, the router binds that LSP to the same bypass tunnel. If there is no match, another bypass is created.

FRR Terminology

Table 5 provides definitions of terms used for FRR.

Table 5:  FRR Terminology  

Term

Definition

Backup path

The LSP that is responsible for backing up a protected LSP. A backup path can be a backup tunnel (facility backup) or a detour LSP (one-to-one backup).

Backup tunnel

The LSP that is used to back up one of the many LSPs in FRR facility (many-to-one) backup

Bypass tunnel

An LSP that is used to protect a set of LSPs passing over a common facility in FRR facility backup. A bypass tunnel can be configured manually or dynamically (see Dynamic and Manual Bypass LSPs).

CSPF

Constraint-based shortest path first

Detour route

Any alternate route that protects the primary path, such as a secondary path, FRR bypass tunnel, or FRR detour LSP. Note that the term “detour route” should not be confused with the term “detour LSP”. Detour route is a general term that refers to any alternate route, while detour LSP is a specific term that applies to one-to-one backup.

Detour LSP

The LSP that is used to reroute traffic around a failure in FRR one-to-one backup. Note that the term “detour LSP” should not be confused with the term “detour route”. Detour route is a general term that refers to any alternate route, while detour LSP is a specific term that applies to one-to-one backup.

DMP

Detour merge point

In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR.

Disjoint

See SRLG disjoint

Facility backup

A local repair method in which a single bypass tunnel is used to protect one or more LSPs that traverse the PLR, the resource being protected, and the Merge Point (in that order). Facility backup is distinct from a one-to-one backup tunnel, which has one backup path per protected path.

MP

Merge point

The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously.

NHOP bypass tunnel

Next-hop bypass tunnel

A backup tunnel that bypasses a single link of the protected LSP

NNHOP bypass tunnel

Next-next-hop bypass tunnel

A backup tunnel that bypasses a single node of the protected LSP

One-to-one backup

A local repair method in which a backup LSP is separately created for each protected LSP at a PLR

PLR

Point of local repair

The head-end router of a backup tunnel or a detour LSP, where the term local repair refers to techniques used to repair an LSP tunnel quickly when a node or link along an LSP path fails

Primary path

An LSP that uses the routers specified by the path defined by the primary path-name command

Protected LSP

An LSP is protected at a given hop if it has one or more associated backup tunnels originating at that hop

Reroutable LSP

Any LSP for which the head-end router requests local protection

Secondary path

An LSP that protects a primary path that uses LSP redundancy protection rather than FRR protection

SRLG disjoint

A path is considered to be SRLG disjoint from a given link or node if the path does not use any links or nodes that belong to the same SRLG as the given link or node

FRR Behavior

The FRR MPLS facility backup method and one-to-one backup method are configured on the ingress LER (ILER) by using the fast-reroute command.

The behavior of an LSP at an ILER with both FRR and a standby LSP path configured is as follows.

  1. When a downstream detour route (alternative path) becomes active at a Point of Local Repair (PLR):
    The ILER switches to the standby LSP path as soon as it is notified of the reroute. If the primary LSP path is subsequently repaired at the PLR, the LSP switches back to the primary path. If the standby path goes down, the LSP is switched back to the primary path, even though the primary path is still on the detour route at the PLR.
  2. If the primary path goes down at the ILER while the LSP is on the standby path, the detour route at the ILER is torn down and, for one-to-one backup detour routes, a “path tear” is sent for the detour route. In other words, the detour route at the ILER does not protect the standby LSP. If and when the primary LSP is again successfully resignaled, the ILER detour route will be restarted.
  3. When the primary LSP fails at the ILER:
    The LSP switches to the detour route. If the primary path undergoes a global revertive recovery, the LSP switches back to the primary path. If the LSP is on the detour route and the detour route fails, the LSP is switched to the standby path.
  4. Administrative groups are not taken into account when creating the detour routes for LSPs.

Dynamic and Manual Bypass LSPs

Users can disable dynamic bypass creation on a per-node basis using the config>router>mpls>dynamic-bypass command. Disabling dynamic bypass means that manual bypass is enabled. Dynamic bypass is enabled by default.

Dynamic bypass tunnels are implemented as per RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels. When an LSP is signaled and the Local Protection flag in the Session_attribute object is set, or the FRR object in the PATH message indicates that facility backup is desired, the PLR establishes a bypass tunnel to provide node and link protection. If there exists a bypass LSP that merges with the protected LSP at a downstream node, and if this LSP satisfies the constraints in the FRR object, then this bypass tunnel is selected and used. The frr-object command specifies whether facility backup is signaled in the FRR object.

The manual bypass feature allows an LSP to be preconfigured from a Point of Local Repair (PLR) that will be used exclusively for bypass protection. When a PATH message for a new LSP requests bypass protection, the node first checks for a manual bypass tunnel that satisfies the path constraints. If one is found, it is selected and used. If no manual bypass tunnel is found, the 7705 SAR dynamically signals a bypass LSP in the default behavior. To configure a manual bypass LSP, use the bypass-only option in the config>router> mpls>lsp lsp-name [bypass-only] command.

Refer to Configuring Manual Bypass Tunnels for configuration information.

Bypass LSP Selection Rules for the PLR

Figure 5 shows a sample network used to illustrate the LSP selection rules for a PLR bypass scenario.

Figure 5:  Bypass Tunnel Node Example 

The PLR uses the following rules to select a bypass LSP from among multiple bypass LSPs (manually and dynamically created) when establishing the primary LSP path or when searching for a bypass for a protected LSP that does not have an association with a bypass tunnel.

  1. The MPLS/RSVP-TE task in the PLR node checks for an existing manual bypass tunnel that satisfies the constraints. If the PATH message for the primary LSP path indicated that node protection is desired, which is the default LSP FRR setting at the head-end node, then the MPLS/RSVP-TE task searches for a node-protect bypass LSP. If the PATH message for the primary LSP path indicated that link protection is desired, then it searches for a link-protect bypass LSP.
  2. If multiple manual bypass LSPs satisfying the path constraints exist, the PLR will prefer a manual bypass LSP terminating closer to the PLR over a manual bypass LSP terminating further away. If multiple manual bypass LSPs satisfying the path constraints terminate on the same downstream node, the PLR selects the one with the lowest IGP path cost, or if there is a tie, it picks the first one available.
  3. If none of the manual bypass LSPs satisfy the constraints and dynamic bypass tunnels have not been disabled on the PLR node, then the MPLS/RSVP-TE task in the PLR node checks to determine if any of the already established dynamic bypass LSPs of the requested type satisfy the constraints.
  4. If none of the dynamic bypass LSPs satisfy the constraints, then the MPLS/RSVP-TE task will ask CSPF to check if a new dynamic bypass of the requested type, node-protect or link-protect, can be established.
  5. If the PATH message for the primary LSP path indicated node protection is desired, and no manual bypass was found after Step 1, and/or no dynamic bypass LSP was found after three attempts to perform Step 3, the MPLS/RSVP-TE task will repeat Steps 1 to 3 looking for a suitable link-protect bypass LSP. If none are found, the primary LSP will have no protection and the PLR node must clear the Local Protection Available flag in the IPv4 address sub-object of the RRO, starting in the next RESV refresh message it sends upstream.
  6. If the PATH message for the primary LSP path indicated link protection is desired, and no manual bypass was found after Step 1, and/or no dynamic bypass LSP was found after performing Step 3, the primary LSP will have no protection and the PLR node must clear the Local Protection Available flag in the IPv4 address sub-object of the RRO, starting in the next RESV refresh message it sends upstream. The PLR will not search for a node-protect bypass LSP in this case.
  7. If the PLR node successfully makes an association, it must set the Local Protection Available flag in the IPv4 address sub-object of the RRO, starting in the next RESV refresh message it sends upstream.
  8. For all primary LSPs that requested FRR protection but are not currently associated with a bypass tunnel, the PLR node—upon reception of an RESV refresh message on the primary LSP path—repeats Steps 1 to 7.

If the user disables dynamic bypass tunnels on a node while dynamic bypass tunnels are activated and passing traffic, traffic loss will occur on the protected LSP. Furthermore, if no manual bypass tunnel exists that satisfies the constraints of the protected LSP, the LSP will remain without protection.

If the user configures a bypass tunnel on Node B (Figure 5) and dynamic bypass tunnels have been disabled, LSPs that had been previously signaled and that were not associated with any manual bypass tunnel (for example, none existed) will be associated with the manual bypass tunnel, if it is suitable. The node checks for the availability of a suitable bypass tunnel for each of the outstanding LSPs every time an RESV message is received for these LSPs.

If the user configures a bypass tunnel on Node B and dynamic bypass tunnels have not been disabled, LSPs that had been previously signaled over dynamic bypass tunnels will not automatically be switched to the manual bypass tunnel, even if the manual bypass tunnel is a more optimized path. The user must perform a make-before-break switchover at the head end of these LSPs. The make-before-break process is enabled using the adaptive option.

If the manual bypass tunnel goes into the down state on Node B and dynamic bypass tunnels have been disabled, Node B (PLR) will clear the “protection available” flag in the RRO IPv4 sub-object in the next RESV refresh message for each affected LSP. It will then try to associate each of these LSPs with one of the manual bypass tunnels that are still up. If it finds one, it will make the association and set the “protection available” flag in the next RESV refresh message for each of these LSPs. If it cannot find one, it will keep checking for one every time an RESV message is received for each of the remaining LSPs. When the manual bypass tunnel is back up, the LSPs that did not find a match are associated back with this tunnel and the protection available flag is set starting in the next RESV refresh message.

If the manual bypass tunnel goes into the down state on Node B and dynamic bypass tunnels have not been disabled, Node B will automatically signal a dynamic bypass tunnel to protect the LSPs if a suitable one does not exist. Similarly, if an LSP is signaled while the manual bypass tunnel is in the down state, the node will only signal a dynamic bypass tunnel if the user has not disabled dynamic tunnels. When the manual bypass tunnel is back up, the node will not switch the protected LSPs from the dynamic bypass tunnel to the manual bypass tunnel.

FRR Node Protection (Facility Backup)

The MPLS Fast Reroute (FRR) functionality enables PLRs to be aware of the lack of node protection and lets them regularly probe for a node bypass via the node-protect command.

When enabled, the node-protect command provides node protection for the specified LSP. If node protection cannot be provided, link protection is attempted. If link protection cannot be provided, no protection is provided. When disabled via the no form of the command, link protection is attempted, and if link protection cannot be provided, no protection is provided.

For example, assume the following for the LSP scenario in Figure 6.

  1. LSP_1 is between PE_1 and PE_2 (via P1 and P2), and has CSPF, FRR facility backup, and FRR node protection enabled.
  2. P1 protects P2 with bypass nodes P1 - P3 - P4 - PE_4 - PE_3.
  3. If P4 fails, P1 tries to establish the bypass node three times.
  4. When the bypass node creation fails (there is no bypass route), P1 will protect link P1-P2.
  5. P1 protects the link to P2 through P1 - P5 - P2.
  6. P4 returns online.
Figure 6:  FRR Node-Protection Example 

LSP_1 had requested node protection, but due to lack of an available path it could only obtain link protection. Therefore, every 60 s, the PLR for LSP_1 will search for a new path that might be able to provide node protection. Once P4 is back online and such a path is available, a new bypass tunnel will be signaled and LSP_1 will be associated with this new bypass tunnel.

Shared Risk Link Groups

A shared risk link group (SRLG) represents a set of interfaces (or links) that share the same risk of failing because they may be subjected to the same resource failures or defects. Two examples where the same risk of failure exists are fiber links that share the same conduit, and multiple wavelengths that share the same fiber.

SRLGs are supported by both LSP redundancy protection and FRR protection. SRLGs allow the user to prepare a detour route that is disjoint from the primary LSP path. See Disjoint and Non-disjoint Paths.

The SRLG feature ensures that a primary and secondary LSP path, or a bypass tunnel or detour LSP path, do not share SRLGs. That is, they do not share the same sets of links that are considered to have a similar (or identical) chance of failure.

To use SRLGs, the user first creates an SRLG by assigning one or more routers to the SRLG. Then, the user links the SRLG to an MPLS interface and enables the SRLG feature on the LSP path. Note that SRLGs cannot be assigned to the system interface.

SRLGs for Secondary LSP Paths

SRLGs for secondary LSP paths apply when LSP redundancy protection is used.

When setting up the secondary path, enable the srlg option on the secondary path to ensure that CSPF includes the SRLG constraint in its route calculation. To make an accurate computation, CSPF requires that the primary LSP be established and in the up state (because the head-end LER needs the most current explicit route object (ERO) for the primary path, and the most current ERO is built during primary path CSPF computation). The ERO includes the list of SRLGs.

At the establishment of a secondary path with the SRLG constraint, the MPLS/RSVP-TE task queries CSPF again, which provides the list of SRLGs to be avoided. CSPF prunes all links having interfaces that belong to the same SRLGs as the interfaces included in the ERO of the primary path. If CSPF finds an eligible path, the secondary path is set up. If CSPF does not find an eligible path, MPLS/RSVP-TE keeps retrying the requests to CSPF.

SRLGs for FRR LSP Paths

When setting up the FRR bypass or detour LSP, enable the srlg-frr option on FRR to ensure that CSPF includes the SRLG constraint in its route calculation. CSPF prunes all links that are in the SRLG being used by the primary LSP during the calculation of the FRR path. If one or more paths are found, CSPF sets up the FRR bypass or detour LSP based on the best cost and signals the FRR LSP.

If there is no path found based on the above calculation and the srlg-frr command has the strict option set, then the FRR LSP is not set up and the MPLS/RSVP-TE task keeps trying to set up a path. If the strict option is not set, then the FRR LSP is set up based on the other TE constraints (that is, excluding the SRLG constraint).

Disjoint and Non-disjoint Paths

A path is considered to be SRLG disjoint from a given link (or node) if the path does not use any links (or nodes) that belong to the same SRLG as the given link (or node). Eligible disjoint paths are found by CSPF when the SRLG constraint is included in the CSPF route calculation (referred to as the strict SRLG condition).

When LSP redundancy is used, the secondary LSP is always signaled with a strict SRLG condition.

When FRR is used, the FRR bypass or detour LSP may have a strict or non-strict SRLG condition. If the strict option is used with the srlg-frr command, then the bypass LSP must be on the list of eligible paths found by the CSPF calculation that included the SRLG constraint. If the strict option is not used, then it is possible for the bypass or detour LSP to be non-disjoint. The non-disjoint case is supported only if the SRLG is not strict.

At the PLR, if an FRR tunnel is needed to protect a primary LSP, the priority order for selecting that FRR tunnel is as follows:

  1. Manual bypass disjoint
  2. Manual bypass non-disjoint (eligible only if srlg-frr is non-strict)
  3. Dynamic bypass disjoint
  4. Dynamic bypass non-disjoint (eligible only if srlg-frr is non-strict)

A bypass or a detour LSP path is not guaranteed to be SRLG disjoint from the primary path. This is because only the SRLG constraint of the outgoing interface at the PLR that the primary path is using is considered in the CSPF calculation.

Enabling Disjoint Backup Paths

A typical application of the SRLG feature is to provide automatic setup of secondary LSPs or FRR bypass or detour LSPs, in order to minimize the probability that they share the same failure risks with the primary LSP path (see Figure 7 and Figure 8).

Figure 7 illustrates SRLG when LSP redundancy is used, where SRLG_1 contains the interfaces that define links A-B, B-C, and C-D. The primary path uses these links to connect node A to node D. In the event of a failure along the primary path, the secondary path cannot use any of the links in SRLG_1 and takes the path from node A to nodes E, F, G, H, J, and D.

Figure 8 illustrates SRLG when FRR bypass is used, where SRLG_1 is the same as in Figure 7. Since FRR bypass is used, the following possible reroutes may occur, depending on where the failure occurs:

  1. if node B fails, the bypass is from node A to nodes E, F, G, H, and C
  2. if node C fails, the bypass is from node B to nodes F, G, H, J, and D
  3. if link C-D fails, the bypass is from node C to nodes H, J, and D

The SRLG feature is supported on OSPF and IS-IS interfaces for which RSVP-TE is enabled.

The following steps describe how to enable SRLG disjoint backup paths for LSP redundancy and FRR.

LSP Redundancy for Primary/Secondary (standby) SRLG Disjoint Configuration
  1. Create an SRLG-group (similar to creating an admin group).
  2. Link the SRLG-group to MPLS interfaces.
  3. Configure primary and secondary LSP paths, and enable SRLG on the secondary LSP path. Note that the SRLG secondary LSP path(s) will always perform a strict CSPF query.
    The setting of the srlg-frr command is irrelevant in this case (see the srlg-frr command).
FRR Bypass Tunnel or Detour LSP SRLG Disjoint Configuration
  1. Create an SRLG-group (similar to creating an admin group).
  2. Link the SRLG-group to MPLS interfaces.
  3. Enable the strict option on the srlg-frr command, which is a system-wide command that forces the CSPF calculation for every LSP path to take any configured SRLG membership(s) into account.
  4. Configure primary FRR (facility backup or one-to-one backup) LSP path(s). Note that each PLR will create a bypass or detour LSP that will only avoid the SRLG membership(s) configured on the primary LSP path egress interface. For one-to-one backup, detour-detour merging is out of the control of the PLR. The PLR will not ensure that the FRR detour will be prohibited from merging with a colliding detour LSP. For facility backup, given that there are several bypass types to bind to, the priority rules shown in Disjoint and Non-disjoint Paths are used.

Manually configured bypasses that do not use CSPF are not considered as possible backup paths.

Figure 7:  Disjoint Primary and Secondary LSPs 
Figure 8:  Disjoint FRR Bypass LSPs 

RSVP-TE Graceful Shutdown

RSVP-TE graceful shutdown provides a method to reroute transit LSPs in a bulk fashion away from a node prior to maintenance of that node. A PathErr message with the error code “Local Maintenance on TE Link required Flag” (if the affected network element is a link) or the error code “Local node maintenance required” (if the affected network element is the node) is sent before the links or node are taken out of service.

When an LER receives the message, it performs a make-before-break on the LSP path to move the LSPs away from the links/nodes whose IP addresses are indicated in the PathErr message and reroute them. Affected link/node resources are flagged in the TE database so that other routers will signal LSPs using the affected resources only as a last resort.

Graceful shutdown can be enabled on a per-interface basis or on all interfaces on the node if the whole node must be taken out of service.

MPLS Service Usage

Alcatel-Lucent routers enable service providers to deliver virtual private networks (VPNs) and Internet access using Generic Routing Encapsulation (GRE), IP, and/or MPLS tunnels, with Ethernet and/or SONET/SDH interfaces.

Service Destination Points

A service destination point (SDP) acts as a logical way of directing traffic from one 7705 SAR router to another through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end 7705 SAR router, which directs packets to the correct service egress service access point (SAP) on that device. All services mapped to an SDP use the GRE, IP, or MPLS transport encapsulation type.

For information about service transport tunnels, refer to the 7705 SAR OS Services Guide. Service transport tunnels can support up to eight forwarding classes and can be used by multiple services.

MPLS and RSVP-TE Configuration Process Overview

Figure 9 displays the process to configure MPLS and RSVP-TE parameters.

Figure 9:  MPLS and RSVP-TE Configuration and Implementation Flow 

Configuration Notes

Network and system interfaces must be configured in the config>router>interface context before they can be specified in MPLS. Refer to the 7705 SAR OS Router Configuration Guide for interface configuration information.

This section describes MPLS and RSVP-TE caveats.

  1. Interfaces must already be configured in the config>router>interface context before they can be specified in MPLS and RSVP.
  2. A router interface must be specified in the config>router>mpls context in order to apply it or modify parameters in the config>router>rsvp context.
  3. A system interface must be configured and specified in the config>router>mpls context.
  4. Paths must be created before they can be applied to an LSP.
  5. CSPF must be enabled in order for administrative groups and SRLGs to be relevant.

Reference Sources

For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.