3. MPLS and RSVP-TE
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:
3.1. 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. There may be more than one alternative route.
3.2. 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:
3.2.1. 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.
3.2.1.1. 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 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. The TE metric is only used in CSPF computations for MPLS paths and not in the regular SPF computation for IP reachability.
Operational metrics of LSPs that use the TE metric in CSPF path calculations can be overridden with the user-configured administrative LSP metric.
3.2.2. 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:
- the next hop where the packet is to be forwarded
- 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.
3.2.2.1. 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:
- 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.
- 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.
- 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.
- A value of 7 represents the entropy label indicator (ELI). The ELI is a special-purpose MPLS label that indicates that the entropy label (the EL) follows it in the stack.
- Values 4 through 6 and 8 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 |
3.2.3. MPLS Entropy Labels
This section contains information on the following topics:
3.2.3.1. Overview of Entropy Labels
The 7705 SAR supports MPLS entropy labels on RSVP-TE LSPs, as per RFC 6790. The entropy label provides greater granularity for load balancing on an LSR where load balancing is typically based on the MPLS label stack.
The ability of a node to receive and process an entropy label for an LSP is signaled using capability signaling (referred to as entropy label-capable). Entropy labels are supported on RSVP-TE tunnels.
Inserting an entropy label adds two labels in the MPLS label stack: the entropy label itself and the entropy label indicator (ELI).
The entropy label is inserted directly below the tunnel label and closest to the service payload that has advertised entropy label capability (which may be above the bottom of the stack). The value of the entropy label is calculated at the iLER and is based on a hash of the packet payload header content and other system parameters at ingress. For more information on hashing inputs, see the “Per-Flow Hashing” section in the 7705 SAR Interface Configuration Guide.
The ELI is inserted by the iLER. The ELI is a special-purpose MPLS label (value = 7) that indicates that the entropy label is the next label in the stack.
Entropy label capability is advertised at the tunnel level by the far-end node (eLER). This capability can be advertised for an RSVP-TE FEC. Capability signaling is not supported for point-to-multipoint LSPs, BGP tunnels, or LDP FECs.An LSR used for RSVP-TE tunnels will pass the entropy label capability signal from the downstream LSP segment to upstream peers. However, earlier releases that do not support entropy label functionality will pass the capability flag transparently, without altering the value.
The insertion of an entropy label by the upstream LER on a tunnel enabled for entropy label capability is enabled on a per-service basis. The entropy label is only inserted if the downstream peer has signaled entropy label support. The upstream LER only inserts a single entropy label, even if multiple LSP labels exist in a label stack.
The 7705 SAR supports the entropy label feature for the following services:
- Epipe access to spoke SDP
- Epipe spoke SDP to spoke SDP (vc-switching)
- VPLS SAP to VPLS spoke SDP or mesh SDP
- VPLS spoke SDP to VPLS spoke SDP
Entropy label capability on RSVP-TE LSPs is enabled on the eLER using the config>router>rsvp>entropy-label-capability command.
At the iLER, the insertion of the entropy label into the label stack is enabled using the config>service>epipe>spoke-sdp>entropy-label command and the config>service>vpls>spoke-sdp>entropy-label and mesh-sdp>entropy-label commands.
In Release 8.0, the following items apply.
- There is no entropy label support for Layer 3 traffic riding over an IGP-shortcut LSP.
- For entropy labels that are supported on LDP tunnels with remote-LFA protection (that is, for rsvp-shortcut), only loop-free alternate protect (lfa-protect) and LFA (lfa-only) are allowed.
- Support of entropy labels over RSVP-TE tunnels is the only valid option, except when the 7705 SAR is the LER node with BGP labeled unicast (BGP-LU) tunnels. A 7705 SAR in an LER role can push and pop an entropy label for Epipe and VPLS services with a BGP-LU tunnel riding over an RSVP-TE LSP. Conversely, a 7705 SAR does not support being in an ABR or ASBR role with BGP-LU.
3.2.3.2. Inserting and Processing the Entropy Label
This section contains inserting and processing information on the following node types:
3.2.3.2.1. Ingress LER
The procedures at the iLER are as specified in section 4.2 of RFC 6790. In general, the router inserts an entropy label into the label stack if the downstream node for the LSP tunnel has signaled support for entropy label and the entropy label is enabled for the particular service.
RFC 6790 specifies that the iLER can insert several entropy labels in the label stack where the LSP hierarchy exists, one for each LSP in the hierarchy. However, this could result in unreasonably large label stacks. Therefore, when there are multiple LSPs in a hierarchy (for example, LDP over RSVP-TE), the router only inserts a single EL/ELI pair within the innermost LSP label closest to the service payload that has advertised entropy label capability.
The entropy label functionality is not available on first generation (Gen-1) adapter cards.
The router inserts an entropy label on a tunnel that is entropy label-capable when the service has entropy label enabled, even if an implicit or explicit NULL label has been signaled by the downstream LSR or LER. This ensures consistent behavior and ensures that the entropy label value as determined by the iLER is maintained where a tunnel with an implicit NULL label is stitched at a downstream LSR.
3.2.3.2.2. LSR
If an LSR is configured for load balancing and an entropy label is found in the label stack, the LSR will take the entropy label into account in the hashing algorithm as follows:
- label-only: the entropy label is used as input to the hash routine and the rest of the label stack is ignored.
- label-ip: the entropy label and the IP packet are used as input to the hash routine and the rest of the label stack is ignored.
The entropy label functionality is not available on first generation (Gen-1) adapter cards.
If PHP has been requested by a next-hop LER, the LSR will retain any entropy label found immediately below the tunnel label that is to be popped. The system will retain and use the entropy label information as input to the local hash routine if an applicable LSR load-balancing mode has been configured.
For more information on LSR load balancing, see the “LSR Hashing” section in the 7705 SAR Interface Configuration Guide.
3.2.3.2.3. Egress LER
At an eLER, if an ELI and entropy label are detected in the label stack, both the ELI and entropy label are popped and the packet processed as normal. This occurs whether or not the system has signaled entropy label capability.
If an ELI is popped that has the bottom of stack (BoS) bit set, the system will discard the packet.
3.2.3.3. Entropy Label on OAM Packets
Service OAM packets also include an entropy label and ELI if entropy label capability is signaled for the corresponding tunnel and entropy label is enabled for the service. The EL/ELI pair is inserted at the same level in the label stack as it is in user data packets; that is, within the innermost LSP label context closest to the service payload that has advertised entropy label capability. The EL/ELI pair will therefore always reside at a different level in the label stack from special-purpose labels related to the service payload (for example, the router alert label).
OAM packets at the LSP level, such as LSP ping and LSP trace, do not have the EL/ELI pair inserted.
3.2.3.4. Entropy Label Configuration
Figure 3 illustrates the use of entropy labels at the service level.
The iLER has entropy label enabled under an applicable service context and the eLER has entropy label capability enabled. The iLER inserts the ELI and the entropy label (EL) into the label stack. The entropy label value is based on the service ID for point-to-point Layer 2 services.
At the LSR, if hashing is enabled, the LSR recognizes the ELI and uses the entropy label value as the hash result. If the entropy-label command had been disabled at the iLER, the LSR would not find the ELI and would default to hashing based on the label stack, if applicable.
Figure 3: Entropy Label and Load Balancing
At the ingress LER:
At the egress LER:
The per-service-hashing command and the l4-load-balancing and teid-load-balancing commands are mutually exclusive.
For IP traffic, use the l4-load-balancing command. For IP traffic with mobile payload, use the teid-load-balancing command. For other types of flows, use the per-service-hashing command.
3.2.4. 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:
- 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.
- 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.
- 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.
3.2.5. LSP Types
The following LSP types are supported:
- 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.
- 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:
- 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. An explicit path that has not specified any hops will follow the IGP route.
- 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 RSVP-TE 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.”
3.3. 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 paths 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.
3.3.1. 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 4 depicts the process to establish an LSP.
- 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.
- PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream.
- The eLER sends label binding information in the RESV messages in response to PATH messages received.
- The LSP is considered operational when the iLER receives the label binding information.
Figure 4: Establishing LSPs
Figure 5 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 5: 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:
- 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)
- record route object (RRO) — allows the iLER to receive a listing of the LSRs that the LSP tunnel actually traverses
- 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.
3.3.1.1. 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.
3.3.1.2. 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:
- hop limit — the hop limit is the maximum number of LSRs that a given LSP can traverse, including the ingress and the egress LERs. 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.
- 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>if-attribute 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.
- 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.
3.3.1.3. 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.
3.3.1.4. Authentication
Protocol authentication protects against malicious attacks on the communications between routing protocol neighbors. These attacks could either disrupt communications or inject incorrect routing information into the systems routing table. The use of authentication keys can help to protect routing protocols from these types of attacks.
All RSVP-TE protocol exchanges can be authenticated. This guarantees that only trusted routers can participate in autonomous system routing.
Authentication must be explicitly configured and can be done using two separate mechanisms:
- configuration of an explicit authentication key and algorithm using the authentication-key command
- configuration of an authentication keychain using the auth-keychain command
Either the authentication-key command or the auth-keychain command can be used by RSVP-TE, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.
By default, authentication is not enabled on an interface.
3.3.1.4.1. Authentication Key
When enabled on an RSVP-TE interface with the authentication-key command, 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:
- the HMAC-MD5 authentication algorithm
- the key used with the authentication algorithm
- 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.
- the source address of the sending system
- 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.
3.3.1.4.2. Authentication Keychains
The keychain mechanism allows for the creation of keys used to authenticate RSVP-TE communications. Each keychain entry defines the authentication attributes to be used in authenticating RSVP-TE messages from remote peers or neighbors; the entry must include at least one key entry to be valid. The keychain mechanism also allows authentication keys to be changed without affecting the state of the RSVP-TE adjacencies and supports stronger authentication algorithms than plain text and MD5.
Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.
The keychain is then associated with an RSVP-TE interface with the auth-keychain command.
For a key entry to be valid, it must include a valid key, the current system clock value must be within the begin and end time of the key entry, and the algorithm specified must be supported by RSVP-TE.
RSVP-TE supports the following authentication algorithms:
- HMAC-MD5
- HMAC-SHA-1-96
- HMAC-SHA-1
- HMAC-SHA-256
Keychain errors are handled as follows.
- If a keychain exists but there are no active key entries with an authentication type that matches the type supported by RSVP-TE, inbound RSVP-TE packets will not be authenticated and will be discarded and no outbound RSVP-TE packets will be sent.
- If a keychain exists but the last key entry has expired, a log entry will be raised indicating that all keychain entries have expired.RSVP-TE requires that the protocol continue to authenticate inbound and outbound traffic using the last valid authentication key.
3.3.1.5. Non-Router ID Addresses as Destinations and Hops
The address of a configured loopback interface, other than the router ID, can be used as the destination of an RSVP LSP. For a constrained-path LSP, CSPF searches for the best path that matches the constraints across all areas or levels of the IGP where this address is reachable. If the address is the router ID of the destination node, then CSPF selects the best path across all areas or levels of the IGP for that router ID, regardless of which area or level the router ID is reachable for as an interface.
The address of a loopback interface other than the router ID can also be configured as a hop in the LSP path hop definition. If the hop is “strict” and corresponds to the router ID of the node, the CSPF path may use any TE-enabled link to the downstream node based on best cost. If the hop is “strict” and does not correspond to the router ID of the node, CSPF will fail.
3.4. 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.
3.4.1. General Attributes of RSVP-TE
The following general attributes of RSVP-TE on the 7705 SAR are supported:
3.4.1.1. 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 RSVP-TE Fast Reroute (FRR) for more information on these topics.
3.4.1.2. Timers
The following timers are implemented to ensure the successful operation of RSVP-TE:
- 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
- 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.
- 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.
3.4.1.3. LSP Resignal Limit
When an LSP fails, an LER node tries to resignal it. The following limit can be configured:
- 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.
3.4.1.4. 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:
- msg-pacing — message pacing can be enabled or disabled
- max-burst — maximum burst defines the number of RSVP-TE messages that can be sent in the specified period of time
- 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. |
3.4.1.5. 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:
- 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.
- 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.
- 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.
3.4.1.6. 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 supports two reservation styles:
- 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.
- 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.
3.4.1.7. RSVP-TE Entropy Labels
The 7705 SAR supports entropy labels as described in MPLS Entropy Labels.
3.5. 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 RSVP-TE Fast Reroute (FRR) for more information on FRR.
The following parameters can be configured for primary and secondary LSPs:
- 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.
- 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.
- hop limit — the hop limit is the maximum number of LSRs that a secondary LSP can traverse, including the ingress and egress LERs.
- 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.
3.5.1. Make-Before-Break (MBB) Procedures for LSP and Path Parameter Configuration Changes
The Make-Before-Break (MBB) procedure allows an LSP to switch from an existing working path to a new path without interrupting service. The MBB procedure does this by first signaling the new path when it is operationally up, having the ingress LER move the traffic to the new path, and then allowing the ingress LER to tear down the original path.
The MBB procedure is invoked during the following operations:
- timer-based and manual resignal of an LSP path
- Fast Reroute (FRR) global revertive procedures
- Traffic Engineering (TE) graceful shutdown procedures
- update of the secondary path due to an update to the primary path SRLG
- LSP primary or secondary path name change
- LSP or path configuration parameter change
MBB procedure coverage has been extended to most of the other LSP-level and path-level parameters as follows:
- including or excluding admin groups at the LSP and path levels
- enabling or disabling the LSP-level CSPF option
- enabling or disabling LSP-level use-te-metric parameters when the CSPF option is enabled
- enabling or disabling the LSP-level hop-limit option in the fast-reroute context
- enabling the LSP-level least-fill option
- enabling or disabling the LSP-level adspec option
- changing between node-protect and no node-protect (link-protect) values in the LSP-level fast-reroute option
- changing the LSP-level and path-level hop-limit parameter values
- enabling or disabling primary or secondary path record or record-label options
The MBB procedure is not supported on a manual bypass LSP.
3.5.2. Automatic Creation of RSVP-TE LSPs
Automatic creation of RSVP-TE LSPs enables the automated creation of point-to-point RSVP-TE LSPs within a single IGP IS-IS level or OSPF area that can subsequently be used by services and/or IGP shortcuts. The feature is divided into two modes: creation of an RSVP-TE LSP mesh, and creation of single-hop RSVP-TE LSPs.
When creating an RSVP-TE LSP mesh, the mesh can be full or partial, the extent of which is governed by a prefix list containing the system addresses of all nodes that should form part of the mesh. When using single-hop RSVP-TE LSPs, point-to-point LSPs are established to all directly connected neighbors.
The use of automatically created RSVP-TE LSPs avoids manual configuration of RSVP-TE LSP meshes. Even when provisioning tools are used to automatically provision these LSPs, automatic creation of a mesh still provides a benefit by avoiding increased configuration file sizes.
3.5.3. Automatic Creation of RSVP-TE LSP Mesh (Auto-LSP)
This feature enables the automatic creation of an RSVP-TE point-to-point LSP to a destination node whose router ID matches a prefix in the specified peer prefix policy. This LSP type is referred to as an auto-created LSP mesh. To start the process of automatically creating an RSVP-TE LSP mesh, the user must create a route policy referencing a prefix list. This prefix list contains the system addresses of all nodes that are required to be in the mesh, and can be entered as a series of /32 addresses, or simply as a range.
After the route policy is created, the user must create an LSP template containing the common parameters that are used to establish all point-to-point LSPs within the mesh. The template must be created with the keyword mesh-p2p:
config>router>mpls>lsp-template template-name mesh-p2p
Upon creation of the template, CSPF is automatically enabled and cannot be disabled. The template must also reference a default path before it can be placed in a no shutdown state.
Next, the user must associate the LSP template with the previously defined route policy, and this is accomplished using the auto-lsp lsp-template command:
config>router>mpls>auto-lsp lsp-template template-name policy peer-prefix-policy
Once the auto-lsp lsp-template command is entered, the system starts the process of establishing the point-to-point LSPs. The prefixes defined in the prefix list are checked, and if a prefix corresponds to a router ID that is present in the Traffic Engineering (TE) database, the system instantiates a CSPF-computed primary path to that prefix using the parameters specified in the LSP template.
Multiple templates can be associated with the same or different peer prefix policies. Each application of an LSP template with a given prefix in the prefix list results in the instantiation of a single CSPF-computed LSP primary path using the LSP template parameters, as long as the prefix corresponds to a router ID for a node in the TE database. Auto LSP does not support the automatic signaling of a secondary path for an LSP. If the signaling of multiple LSPs to the same destination node is required, a separate LSP template must be associated with a prefix list that contains the same destination node address. Each instantiated LSP will have a unique LSP ID and a unique tunnel ID.
The auto-created LSP is installed in the Tunnel Table Manager (TTM) and is available to applications such as resolution of BGP label routes, and resolution of BGP, IGP, and static routes. The auto-created LSP can also be used for auto-binding by a VPRN service. The auto-created LSP cannot be used as a provisioned SDP for explicit binding by services.
The auto-created LSP mesh can be signaled over both numbered and unnumbered RSVP-TE interfaces.
Up to five peer prefix policies can be associated with an LSP template. Every time the user executes the auto-lsp command with the same or different prefix policy associations or changes the prefix policy associated with an LSP template, the system re-evaluates the prefix policy. The outcome of the re-evaluation indicates to MPLS whether an existing LSP must be torn down or a new LSP must be signaled to a destination address that is already in the TE database.
If a /32 prefix is added to or removed from a prefix list associated with an LSP template, or if a prefix range is expanded or narrowed, the prefix policy re-evaluation is performed. Whether the prefix list contains one or more specific /32 addresses or a range of addresses, MPLS requires an external trigger to instantiate an LSP to a node whose address matches an entry in the prefix list. The external trigger is when the router with a router ID matching an address in the prefix list appears in the TE database. The TE database provides the trigger to MPLS.
The user must perform a no shutdown of the template before it takes effect. When a template is in use, the user must shut down the template before changing any parameters except for those LSP parameters for which the change can be handled with the Make-Before-Break (MBB) procedures (see Make-Before-Break (MBB) Procedures for LSP and Path Parameter Configuration Changes). When the template is shut down and parameters are added, removed, or modified, the existing instances of the LSP using this template are torn down and resignaled.
MBB procedures for manual and timer-based resignaling of the LSP, and for TE graceful shutdown, are supported.
The tools>perform>router>mpls>update-path command is not supported for mesh LSPs.
The one-to-one option under the fast-reroute command is also not supported.
If the TE database loses the router ID while the LSP is up, it will perform an update to the MPLS that states that the router ID is no longer in the TE database. This occurs whether the bypass backup path is activated or not. This will cause MPLS to tear down all mesh LSPs to this router ID. However, if the destination router is not a neighbor of the ingress LER and the user shuts down the IGP instance on the destination router, the router ID corresponding to the IGP instance will only be deleted from the TE database on the ingress LER after the LSA/LSP times out. If the user brings the IGP instance back up before the LSA/LSP times out, the ingress LER will delete and reinstall the same router ID at the receipt of the updated LSA/LSP. The RSVP-TE LSPs destined for this router ID will be deleted and re-established. All other failure conditions will cause the LSP to activate the bypass backup LSP or to go down without being deleted.
3.5.3.1. Multi-Area and Multi-Instance Support
A router that does not have TE links within a given IGP area or level will not have its router ID discovered in the TE database by other routers in this area or level. In other words, an auto-created LSP mesh cannot be signaled to a router that does not participate in the area or level of the ingress LER.
A mesh LSP can be signaled using TE links that belong to the same IGP area even if the router ID of the ingress and egress routers are interfaces reachable in a different area. In this case, the LSP is considered to be an intra-area LSP.
If multiple instances of IS-IS are configured on a router, each with its own router ID, the TE database on other routers will be able to discover TE links advertised by each instance. In this case, an instance of an LSP can be signaled to each router ID with a CSPF path computed using TE links within each instance.
If multiple instances of IS-IS are configured on a destination router, each with the same router ID, a single instance of LSP will be signaled from other routers. If the user shuts down one IGP instance, this will have no impact as long as the other IGP instances remain up. The LSP will remain up and will forward traffic using the same TE links. The same behavior exists with a provisioned LSP.
3.5.3.2. Mesh LSP Name Encoding
When the ingress LER signals the path of an auto-created mesh LSP, it includes the name of the LSP and the path name in the Session Name field of the Session Attribute object in the Path message. The encoding is as follows:
Session Name: <lsp-name::path-name>, where the lsp-name component is encoded as follows:
TemplateName-DestIpv4Address-TunnelId
where DestIpv4Address is the address of the destination of the auto-created LSP.
3.5.4. Automatic Creation of an RSVP-TE Single-Hop LSP
If the one-hop option is specified instead of a prefix policy, the auto-lsp command enables the automatic signaling of single-hop, point-to-point LSPs using the specified template to all directly connected neighbors. This LSP type is referred to as auto-created single-hop LSPs of type one-hop. Unlike the automatically created RSVP-TE LSP mesh, the automatically created single-hop RSVP-TE LSPs have no requirement for a prefix list to be referenced.
The first requirement is to create an LSP template containing the common parameters used to establish each single-hop LSP. The template must be created with the keyword one-hop-p2p:
config>router>mpls>lsp-template template-name one-hop-p2p
Upon creation of the template, CSPF is automatically enabled (and cannot be disabled), and the hop-limit is set to a value of two. The hop-limit defines the number of nodes the LSP may traverse, and since these are single-hop LSPs to adjacent neighbors, a limit of two is sufficient. The template must also reference a default path before it can be placed in the no shutdown state.
The next requirement is to trigger the creation of single-hop LSPs using the auto-lsp lsp-template command:
config>router>mpls>auto-lsp lsp-template template-name one-hop
The LSP and path parameters and options supported in an LSP template of type one-hop-p2p are the same as those in the LSP template of type mesh-p2p. The show command for auto-lsp will display the actual outgoing interface address in the “from” field.
The auto-created single-hop LSP can be signaled over both numbered and unnumbered RSVP-TE interfaces.
When the one-hop command is executed, the TE database keeps track of each TE link to a directly connected IGP neighbor whose router ID is discovered. MPLS then signals an LSP with a destination address matching the router ID of the neighbor and with a strict hop consisting of the address of the interface used by the TE link. The auto-lsp command with the one-hop option results in one or more LSPs signaled to the IGP neighbor.
Only the router ID of the first IGP instance of the neighbor that advertises a TE link causes the LSP to be signaled. If another IGP instance with a different router ID advertises the same TE link, no action is taken and the existing LSP is kept up. If the router ID originally used disappears from the TE database, the LSP is kept up and is now associated with the other router ID.
The state of a single-hop LSP that is signaled displays the following behavior.
- If the interface used by the TE link goes down or BFD times out and the RSVP-TE interface is registered with BFD, the LSP path moves to the bypass backup LSP if the primary path is associated with one.
- If the association of the TE link with a router ID is removed from the TE database while the single-hop LSP is up, the single-hop LSP is torn down whether the bypass backup path is activated or not. This occurs if the interface used by the TE link is deleted or if the interface is shut down in the context of RSVP-TE.
- If the TE database loses the router ID while the LSP is up, it will perform two separate updates to MPLS, whether the bypass backup path is activated or not. The first one updates the loss of the TE link association, which will cause the single-hop LSP to be torn down. The other update states that the router ID is no longer in the TE database, which will cause MPLS to tear down all mesh LSPs to this router ID. A shutdown at the neighbor of the IGP instance that advertised the router ID will cause the router ID to be removed from the ingress LER node immediately after the last IGP adjacency is lost and not be subject to time-out as it is for a non-directly connected destination router.
All other feature behavior and limitations are the same as for an auto-created LSP mesh.
3.5.5. Automatic ABR Selection for Inter-area LSPs
Inter-area RSVP point-to-point LSPs support automatic area border router (ABR) selection at the ingress LER. The ABR does not need to be included as a loose hop in the LSP path definition.
CSPF can now compute all segments of a multi-segment, inter-area LSP path in one operation. Previously, MPLS made separate requests to CSPF for each segment.
For LSP path establishment, the explicit route object (ERO) in the path message is expanded on ABRs where the next hop is a loose hop in the LSP path definition. For ERO expansion to operate, the cspf-on-loose-hop command must be enabled under the mpls context on the ABR to allow the ABR to perform a CSPF calculation. If CSPF calculations are not performed, CSPF for the LSP path fails at the head-end node as TE information for links in another area are not available.
Figure 6 illustrates the role of each node in the signaling of an inter-area LSP with automatic ABR selection.
Figure 6: Automatic ABR Selection for Inter-Area LSP
CSPF for an inter-area LSP operates as follows:
- CSPF in the ingress LER node determines that an LSP is inter-area by performing a route lookup with the destination address of a point-to-point LSP, such as the address in the “to” field of the LSP configuration. If there is no intra-area route to the destination address, the LSP is considered to be inter-area.
- When the path of the LSP is empty, CPSF computes a single-segment, intra-area path to an ABR that advertised a prefix matching the destination address of the LSP.
- If the path of the LSP contains one or more hops, CSPF computes a multi-segment, intra-area path including the hops that are in the area of the ingress LER node.
- If all hops are in the area of the ingress LER, the calculated path ends on an ABR that advertised a prefix matching the destination address of the LSP.
- When there are one or more hops that are not in the area of the ingress LER, the calculated path ends on an ABR that advertised a prefix matching the first-hop address that is not in the area of the ingress LER.
- Note the following special case of a multi-segment, inter-area LSP. If CSPF hits a hop that can be reached via an intra-area path but that resides on an ABR, CSPF only calculates a path up to that ABR. This is because there is a better chance to reach the destination of the LSP by first signaling the LSP up to that ABR and continuing the path calculation from there on by having the ABR expand the remaining hops in the ERO.
- If there is more than one ABR that advertised a prefix, CSPF calculates a path for all ABRs. Only the shortest path is withheld. If more than one path is the shortest path, CSPF picks a path randomly or based on the least-fill criterion if least-fill is enabled. If more than one ABR satisfies the least-fill criterion, CSPF also picks one path randomly.
- The path for an intra-area LSP cannot exit and re-enter the local area of the ingress LER. This behavior was possible in prior implementations when the user specified a loose hop outside the local area or when the only available path was via TE links outside the local area.
3.5.5.1. Rerouting of Inter-area LSPs
In prior implementations, an inter-area LSP path would have been rerouted if a failure or a topology change occurred in the local area or in a remote area while the ABR loose hop in the path definition was still up. If the transit/inter-area (exit) ABR failed or was put into node TE graceful shutdown, or if IS-IS went into overload mode, the LSP path would remain down at the ingress LER.
With automatic ABR selection, the ingress LER can reroute an inter-area LSP primary path via a different ABR in the following situations:
- When the local exit ABR fails, there are two cases to consider:
- If the primary path is not protected at the ABR, and is therefore torn down by the previous hop in the path, then the ingress LER retries the LSP primary path via the ABR that currently has the best path for the destination prefix of the LSP.
- If the primary path is protected at the ABR with a manual or dynamic bypass LSP, the ingress LER will receive a PathErr message with a notification of protection becoming active downstream and a RESV with a Local-Protection-In-Use flag set. At the receipt of the first of these two messages, the ingress LER performs a Global Revertive MBB procedure to optimize the LSP primary path via the ABR that currently has the best path for the destination prefix of the LSP.
- When the local exit ABR node goes into IS-IS overload or is put into node TE graceful shutdown, the ingress LER performs an MBB procedure to optimize the LSP primary path via the ABR that currently has the best path for the destination prefix of the LSP. The MBB is performed at the receipt of the PathErr message for the node TE shutdown, or at the next timer or manual optimization of the LSP path if the IS-IS overload bit is received.
3.5.5.2. Behavior of MPLS Options in Inter-area LSPs
The automatic ABR selection for an inter-area LSP does not change the prior implementation of inter-area LSP behavior for many of the LSP-level and path-level options. However, there are a number of enhancements introduced by the automatic ABR selection feature.
- Features such as path bandwidth reservation and admin-groups continue to operate within the scope of all areas since they rely on propagating the parameter information in the Path message across the area boundary.
- The TE graceful shutdown feature continues to support MBB of the LSP path to avoid the link or node that originated the PathErr message as long as the link or node is in the local area of the ingress LER. If the PathErr originated in a remote area, the ingress LER is not able to avoid the link or node when it performs the MBB since it computes the path to the local exit ABR only. However, there is an exception to this. An enhancement has been added to cause the upstream ABRs in the current path of the LSP to record the link or node to avoid and use the record in subsequent ERO expansions. This means that if the ingress LER computes a new MBB path that goes through the same exit ABR as the current path, and all ABRs upstream of the node or link that originated the PathErr message are also selected in the new MBB path when the ERO is expanded, then the new path will also avoid this link or node.
- MBB support has been expanded to avoid the ABR when the node is put into TE graceful shutdown.
- The use-te-metric option in CSPF cannot be propagated across the area boundary and thus operates within the scope of the local area of the ingress LER. This is a new behavior.
- The srlg option on the bypass LSP continues to operate locally at each PLR within each area. The PLR protecting the ABR checks the SRLG constraint for the path of the bypass within the local area.
- The srlg option on the secondary path is allowed to operate within the scope of the local area of the ingress LER with the automatic ABR selection feature.
- The least-fill option support with an inter-area LSP is introduced with the automatic ABR selection feature. When this option is enabled, CSPF applies the least-fill criterion to select the path segment to the exit ABR in the local area.
- The PLR must indicate to CSPF that a request to a one-to-one detour LSP path must remain within the local area. If the destination for the detour, which is the same as that of the LSP, is outside of the area, CSPF must return no path.
- With the automatic ABR selection feature, timer-based resignaling of the inter-area LSP path is supported and the path is resignaled if the cost of the path segment to the local exit ABR changes. The cost shown for the inter-area LSP at the ingress LER is the cost of the path segments to the ABR.
3.5.5.3. Inter-area LSP Support of OSPF Virtual Links
The OSPF virtual link extends area 0 for a router that is not connected to area 0 (OSPF backbone area). All prefixes in area 0 appear to be reachable via an intra-area path. However, the prefixes are not reachable since the path crosses the transit area through which the virtual link is set up to reach the area 0 remote nodes.
The TE database in a router learns all of the remote TE links in area 0 from the ABR connected to the transit area, but an intra-area LSP path using these TE links cannot be signaled within area 0 since none of these links are directly connected to this node.
The inter-area LSP feature can identify when the destination of an LSP is reachable via a virtual link. In that case, CSPF automatically computes and signals an inter-area LSP via the ABRs that are connected to the transit area.
However, when the ingress LER for the LSP is the ABR connected to the transit area, and the destination of the LSP is the address corresponding to another ABR router-id in that same transit area, CSPF computes and signals an intra-area LSP using the transit area TE links, even when the destination router-id is only part of area 0.
3.5.6. ABR FRR Protection for Inter-area LSP
For protection of the ABR, the upstream node of the ABR acts as a PLR, and the next-hop node to the protected domain border router is the merge point (MP). Both manual and dynamic bypass are available to protect the ABR.
Manual bypass protection only works when a proper completely strict path is provisioned that avoids the ABR.
Dynamic bypass protection provides for the automatic computation, signaling, and association with the primary path of an inter-area point-to-point LSP to provide ABR protection. Figure 7 illustrates the role of each node in ABR protection using a dynamic bypass LSP.
Figure 7: ABR Protection Using Dynamic Bypass LSP
In order for a PLR within the local area of the ingress LER to provide ABR protection, it must dynamically signal a bypass LSP and associate it with the primary path of the inter-area LSP using the following procedures.
- The PLR must inspect the RRO node-id of the LSP primary path to determine the address of the node immediately downstream of the ABR in the other area.
- The PLR signals an inter-area bypass LSP with a destination address set to the address downstream of the ABR and with the exclude route object (XRO) set to exclude the node-id of the protected ABR.
- The request to CSPF is for a path to the merge point (that is, the next-next-hop in the RRO received in the RESV for the primary path) along with the constraint to exclude the protected ABR and the include/exclude admin groups of the primary path. If CSPF returns a path that can only go to an intermediate hop, then the PLR signals the dynamic bypass and automatically includes the XRO with the address of the protected ABR and propagates the admin-group constraints of the primary path into the Session Attribute object of the bypass LSP. Otherwise, the PLR signals the dynamic bypass directly to the merge point node with no XRO in the Path message.
- If a node-protect dynamic bypass cannot be found or signaled, the PLR attempts a link-protect dynamic bypass LSP. As with the existing implementation of dynamic bypass within the same area, the PLR attempts in the background to signal a node-protect bypass at the receipt of every third Resv refresh message for the primary path.
- Refresh reduction over dynamic bypass only works if the RRO node-id also contains the interface address. Otherwise, the neighbor is not created once the bypass is activated by the PLR. The Path state then times out after three refreshes following the activation of the bypass backup LSP.
A one-to-one detour backup LSP cannot be used at the PLR for the protection of the ABR. As a result, a 7705 SAR, acting as a PLR, will not signal a one-to-one detour LSP for ABR protection. In addition, an ABR will reject a Path message, received from a third party implementation, with a detour object and with the ERO having the next hop loose. This is performed whether the cspf-on-loose option is enabled or not on the 7705 SAR. In other words, the 7705 SAR, working as a transit ABR for the detour path, rejects the signaling of an inter-area detour backup LSP.
3.6. RSVP-TE 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, the router checks and compares its session object to the existing session objects 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.
3.6.1. 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. 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. 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 |
3.6.2. 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.
- 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.
- 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.
- 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.
- Administrative groups are not taken into account when creating the detour routes for LSPs.
3.6.3. 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.
When a PLR activates a bypass backup LSP and subsequently receives a RESV refresh message for the original primary LSP path reservation over the restored interface, the PLR does not generate a ResvErr packet downstream. In addition, the MP node, once it becomes active, does not propagate a downstream ResvErr message received packet for the original primary LSP path reservation.
Refer to Configuring Manual Bypass Tunnels for configuration information.
3.6.3.1. Bypass LSP Selection Rules for the PLR
Figure 8 shows an example of a network used to illustrate the LSP selection rules for a PLR bypass scenario.
Figure 8: 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 8) 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.
3.6.3.2. 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 9.
- LSP_1 is between PE_1 and PE_2 (via P1 and P2), and has CSPF, FRR facility backup, and FRR node protection enabled.
- P1 protects P2 with bypass nodes P1 - P3 - P4 - PE_4 - PE_3.
- If P4 fails, P1 tries to establish the bypass node three times.
- When the bypass node creation fails (there is no bypass route), P1 will protect link P1-P2.
- P1 protects the link to P2 through P1 - P5 - P2.
- P4 returns online.
Figure 9: 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. When 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.
3.6.4. Admin Group Support on Facility Bypass Backup LSPs
Admin group support on facility bypass backup LSPs provides for the inclusion of the LSP primary path admin-group constraints in the computation of an FRR facility bypass backup LSP to protect the primary LSP path. Admin group constraints are honored by all nodes in the LSP path both for primary and FRR backup LSPs.
This feature is supported on primary paths of an RSVP point-to-point LSP in both intra-area and inter-area TE where applicable.
This feature is not supported on one-to-one detour backup LSPs.
3.6.5. FRR Over Unnumbered Interfaces
When the PLR is the ingress LER node and the outgoing interface of the bypass LSP is unnumbered, the user must assign a borrowed IP address to the interface that is different from the system interface; otherwise, the bypass LSP will not come up.
In addition, the PLR node includes the IF_ID RSVP_HOP object (C-Type = 3) in the PATH message if the outgoing interface of the bypass LSP is unnumbered. If the outgoing interface of the bypass LSP is numbered, the PLR node includes the IPv4 RSVP_HOP object (C-Type = 1).
When the MP node receives the PATH message over the bypass LSP, it creates the merge-point context for the protected LSP and associates it with the existing state if any of the following is satisfied:
- the C-Type value of the RSVP_HOP object has changed
- the C-Type is the value for the IF_ID RSVP_HOP object (C-Type = 3) and it has not changed, but the IF_ID TLV is different
- the IPv4 Next/Previous Hop Address field in the RSVP_HOP object has changed, regardless of the C-Type value
This behavior at the PLR and MP nodes is the same for both link protection and node protection FRR.
| Note: If node protection FRR is enabled but the MP does not support an unnumbered interface, the PATH message is rejected at the MP and the path is torn down. |
See RSVP-TE Support for Unnumbered Interfaces for information on unnumbered interfaces.
3.7. 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. SRLGs cannot be assigned to the system interface.
3.7.1. 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.
3.7.2. 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).
3.7.3. 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:
- Manual bypass disjoint
- Manual bypass non-disjoint (eligible only if srlg-frr is non-strict)
- Dynamic bypass disjoint
- 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.
3.7.4. 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 10 and Figure 11).
Figure 10 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 11 illustrates SRLG when FRR bypass is used, where SRLG_1 is the same as in Figure 10. Since FRR bypass is used, the following possible reroutes may occur, depending on where the failure occurs:
- if node B fails, the bypass is from node A to nodes E, F, G, H, and C
- if node C fails, the bypass is from node B to nodes F, G, H, J, and D
- 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
- Create an SRLG-group (similar to creating an admin group).
- Link the SRLG-group to MPLS interfaces.
- Configure primary and secondary LSP paths, and enable SRLG on the secondary LSP path. The SRLG secondary LSP paths 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
- Create an SRLG-group (similar to creating an admin group).
- Link the SRLG-group to MPLS interfaces.
- 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 memberships into account.
- Configure primary FRR (facility backup or one-to-one backup) LSP paths. Each PLR will create a bypass or detour LSP that will only avoid the SRLG memberships 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 10: Disjoint Primary and Secondary LSPs
Figure 11: Disjoint FRR Bypass LSPs
3.8. 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.
3.9. RSVP-TE Support for Unnumbered Interfaces
Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface. For more information on support for unnumbered interfaces, refer to the 7705 SAR Router Configuration Guide, “Unnumbered Interfaces”.
Unnumbered IP interfaces can be used via RSVP-TE for signaling traffic engineering (TE) LSPs.
Supporting RSVP-TE over unnumbered interfaces requires the ability to:
- carry TE information over unnumbered links in IS-IS-TE or OSPF-TE extensions
- specify unnumbered interfaces in RSVP-TE signaling
An unnumbered IP interface is identified uniquely on a router in the network by the tuple (router ID, ifindex). An LSR at each end of the link assigns a system-wide unique interface index to the unnumbered interface. IS-IS, OSPF, MPLS (RSVP-TE, LDP), and OAM use this tuple to advertise the link information, signal LSPs over the interface, or send and respond to an MPLS echo request message over an unnumbered interface.
The borrowed IP address for an unnumbered interface is configured using the following CLI command, with the default value set to the system interface address: config>router>interface>unnumbered {ip-int-name | ip-address}.
| Note: The borrowed IP address is used exclusively as the source address for IP packets that originate from the interface. For FRR, this address must be configured to an address different from the system interface in order for the FRR bypass LSP to come up at the ingress LER. See RSVP-TE Fast Reroute (FRR) for information on FRR. |
To support unnumbered TE links in IS-IS, a new sub-TLV of the extended IS reachability TLV is added, which encodes the link local identifiers and link remote identifiers as defined in RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).
To support unnumbered TE links in OSPF, a new sub-TLV of the Link TLV is added, which encodes the link local identifiers and link remote identifiers as defined in RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).
To support unnumbered TE links in RSVP-TE, a new sub-object of the Explicit Route Object (ERO) is added to specify unnumbered links and a new sub-object of the Route Record Object (RRO) is added to record that the LSP traversed an unnumbered link, as per RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). As well, a new IF_ID RSVP_HOP object with a C-Type of 3 is added as per section 8.1.1 of RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. The IPv4 Next/Previous Hop Address field in the object is set to the borrowed IP interface address.
The unnumbered IP interface address is advertised by IS-IS-TE or OSPF-TE, and CSPF can include it in the computation of a path for a point-to-point LSP. However, this feature does not support defining an unnumbered interface as a hop in the path definition of an LSP.
A router creates an RSVP neighbor over an unnumbered interface using the tuple (router ID, ifindex). The router ID of the router that advertised an unnumbered interface index is obtained from the TE database. Therefore, if traffic engineering is disabled in IS-IS or OSPF, a non-CSPF LSP that has its next hop over an unnumbered interface will not come up at the ingress LER because the router ID of the neighbor that has the next hop of the PATH message cannot be looked up. The LSP path will remain operationally down with the error “noRouteToDestination”. If a PATH message is received at the LSR for which traffic engineering was disabled and the next hop for the LSP is over an unnumbered interface, a PathErr message is sent back to the ingress LER with the error code of 24 “Routing Problem” and an error value of 5 “No route available toward destination”.
All MPLS (RSVP-TE and LDP) features supported for numbered IP interfaces are supported for unnumbered interfaces, with the following exceptions:
- configuration of a router ID with a value other than system interface
- signaling of an LSP with an ERO based on a loose or strict hop using an unnumbered TE link in the path hop definition
- signaling of a one-to-one detour LSP over an unnumbered interface
- RSVP Hello messages and all Hello-related capabilities, such as Graceful-Restart Helper
- RSVP refresh reduction on an unnumbered interface
The unnumbered interface feature also extends the support of LSP ping and LSP traceroute to point-to-point LSPs that have unnumbered TE links in their path.
3.10. PCEP Support for RSVP-TE LSPs
The Path Computation Element Communication Protocol (PCEP) is one of several protocols used for communication between a wide area network (WAN) software-defined network (SDN) controller and network elements.
The 7705 SAR operates as a PCE Client (PCC) only, supporting PCC capabilities for RSVP-TE LSPs.
The following MPLS-level and LSP-level CLI commands are used to configure RSVP-TE LSPs in a router acting as a PCC. See MPLS and RSVP-TE Command Reference for command descriptions. See the PCEP Support for RSVP-TE LSPs section in the PCEP chapter for information on using these commands.
- config>router>mpls>pce-report rsvp-te {enable | disable}
- config>router>mpls>lsp>path-profile profile-id [path-group group-id]pce-computationpce-controlpce-report {enable | disable | inherit}
- config>router>mpls>lsp-template>pce-report {enable | disable | inherit}
3.11. MPLS Service Usage
The 7705 SAR 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.
3.11.1. 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 Services Guide. Service transport tunnels can support up to eight forwarding classes and can be used by multiple services.
3.12. MPLS and RSVP-TE Configuration Process Overview
Figure 12 displays the process to configure MPLS and RSVP-TE parameters.
Figure 12: MPLS and RSVP-TE Configuration and Implementation Flow
3.13. 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 Router Configuration Guide for interface configuration information.
This section describes MPLS and RSVP-TE guidelines and caveats.
- Interfaces must already be configured in the config>router>interface context before they can be specified in MPLS and RSVP.
- 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.
- A system interface must be configured and specified in the config>router>mpls context.
- Paths must be created before they can be applied to an LSP.
- CSPF must be enabled in order for administrative groups and SRLGs to be relevant.
3.13.1. Reference Sources
For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.