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.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:

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

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

3.2.3.1. Overview of Entropy Labels

The 7705 SAR supports MPLS entropy labels on RSVP-TE and SR-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 capability (ELC)). Entropy labels are supported on RSVP-TE and SR-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 or an SR-TE tunnel on IS-IS or OSPF. Capability signaling is not supported for point-to-multipoint LSPs, BGP tunnels, or LDP FECs. An LSR used for RSVP-TE and SR-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:

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 entropy-label command under the service, mesh SDP, or spoke SDP context or under the config>router>isis (or ospf)>segment-routing context for SR-TE LSPs.

The entropy label requires the insertion of two additional labels in the label stack. In some cases, this may result in an unsupported label stack depth or large changes in the label stack depth during the lifetime of an LSP (for example, due to switching from a primary path with entropy label capability enabled to a secondary path for which the far end has not signaled entropy label capability).

The entropy-label command under the config>router>mpls and config>router>mpls>lsp contexts provides local control at the head end of an LSP over whether the entropy label is inserted on an LSP by overriding the entropy label capability signaled from the far-end LER, and control over how the additional label stack depth is accounted for. This allows the user to avoid entropy label insertion where there is a risk of the label stack depth becoming too great.

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 and SR-TE tunnels are the only valid options, 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. Table 5 lists entropy label support on the 7705 SAR.

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.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. Segment Routing Entropy Label and IPSec, ESPI Hashing, and NGE

Segment routing with entropy label can be used with IPSec and NGE services and with ESPI hashing, as listed below:

3.2.3.5. 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 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:

config>service>cpipe>spoke-sdp>entropy-label

config>service>epipe>spoke-sdp>entropy-label

config>service>ipipe>spoke-sdp>entropy-label

config>service>vpls>spoke-sdp>entropy-label

config>service>vpls>mesh-sdp>entropy-label

config>service>vprn>entropy-label

config>service>vprn>interface>spoke-sdp>entropy-label

config>router>isis>segment-routing>entropy-label

config>router>ospf>segment-routing>entropy-label

At the egress LER:

config>router>entropy-label

config>router>rsvp>entropy-label-capability

config>router>mpls>lsp>entropy-label

config>router>isis>entropy-label>override-tunnel-elc

config>router>ospf>entropy-label>override-tunnel-elc

The per-service-hashing command and the l4-load-balancing, teid-load-balancing, and spi-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 and/or the spi-load-balancing command.

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:

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:

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.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.3.2.1. Configuring RSVP LSP Statistics at Ingress LER

At the ingress LER, statistics are configured in the egress data path of an originating LSP with the config>router>mpls>lsp>egress-statistics command in the LSP configuration at the head-end node. Statistics collection in the egress data path is enabled after the user executes the no shutdown command in the egress-statistics context. By default, this function is in a shutdown state.

Statistics cannot be configured if the LSP name contains a colon (:), which is used as a field separator by the ingress LER for encoding the LSP and path names into the RSVP Session Name field in the Session_Attribute object.

The no form of the egress-statistics command disables statistics collection in the egress data path and removes the accounting policy association from the RSVP LSP. Users can choose to disable statistics in the egress data path while keeping the accounting policy association of the RSVP LSP with the config>router>mpls>lsp>egress-statistics shutdown command.

The same set of counters are updated for packets forwarded over any path of the LSP. In the steady state, counters are updated for packets forwarded over the active path of the LSP. The active path can be the primary path, one of the secondary paths, the FRR detour path, or the FRR bypass path when the head-end node is also the PLR.

The LSP counters are maintained over the lifetime of the LSP as long as statistics are enabled. The user can clear the counters with the clear>router>mpls>lsp-egress-stats [lsp-name] command.

LSP statistics are not collected on a dynamic or static bypass tunnel. LSP egress statistics are also not collected if the head-end node is also the penultimate-popping hop (PHP) node for a single-hop LSP using an implicit null label. However, if any label is pushed onto the label stack, for example, the Layer 2 or Layer 3 service label, the egress statistics are counted for the LSP even if the transport MPLS label is not present.

When a hierarchy of LSPs is in use, statistics collection on the outermost label corresponding to the tunneling LSP and on the inner labels, corresponding to the tunneled LSPs, are mutually exclusive. The outermost label takes precedence. Consequently, when the user enables statistics collection on an RSVP LSP that is also used for tunneling LDP FECs with the LDP over RSVP shortcut, statistics will be collected on the RSVP LSP only. No statistics are collected for an LDP FEC tunneled over this RSVP LSP even if the user enabled statistics collection on the FEC. When the user disables statistics collection on the RSVP LSP, statistics collection, if enabled, will be performed on the tunneled LDP FEC.

LSP statistics are not collected on static LSPs. Auto-LSP templates do not support LSP statistics collection.

3.3.2.2. Configuring RSVP LSP Statistics at Egress LER

At the egress LER, statistics are configured in the ingress data path of a terminating LSP by entering the LSP name, along with the ingress LER system interface address, with the config>router>mpls>ingress-statistics>lsp lsp-name sender ip-address command. Statistics collection is enabled in the ingress data path after the user executes the no shutdown command in the ingress-statistics context. By default, this function is in a shutdown state.

The LSP name must correspond to the name configured by the user at the ingress LER. Statistics cannot be configured if the LSP name contains a colon (:), which is used as a field separator by the ingress LER for encoding the LSP and path names into the RSVP Session Name field in the Session_Attribute object.

The no form of the ingress-statistics command disables statistics collection in the ingress data path and removes the accounting policy association from the RSVP LSP. Users can choose to disable statistics in the ingress data path while keeping the accounting policy association of the RSVP LSP with the config>router>mpls>ingress-statistics>lsp>shutdown command.

The same set of counters are updated for packets received over any path of the LSP. In the steady state, the counters are updated for packets received over the active path of the LSP. The active path can be the primary path, one of the secondary paths, the FRR detour path, or the FRR bypass path when the tail-end node is also the MP.

The LSP counters are maintained over the lifetime of the LSP as long as statistics are enabled. The user can clear the counters with the clear>router>mpls>lsp-ingress-stats ip-address lsp lsp-name command.

When a hierarchy of LSPs is in use, statistics collection on the outermost label corresponding to the tunneling LSP and on the inner labels, corresponding to the tunneled LSPs, are mutually exclusive. The outermost label takes precedence.

Because ingress data path statistics are not supported for an LDP FEC, there are no statistics collected for an LDP FEC, however if the LDP FEC is tunneled over an RSVP shortcut LSP that has LSP ingress statistics configured, the statistics are collected for the RSVP LSP

The user can enable statistics collection on a manual bypass LSP terminating on the egress LER. However, all LSPs whose primary path is protected by the manual bypass will not collect statistics when they activate forwarding over the manual bypass. If the user disables statistics collection on the manual bypass LSP, statistics collection, if enabled, is continued on the protected LSP when the bypass LSP is activated.

A flag in the output of the show command for the LSP statistics will indicate if there were no path state blocks (PSBs) that matched the specified LSP name at any given point in time. This could be due to the absence of the RSVP session or to the presence of a session type that is not supported; for example, the LSP name matched a point-to-multipoint LSP. The counters will show all zero values, which could otherwise be confused with an LSP with a valid matched PSB that is not receiving packets.

3.3.2.3. Configuring LDP FEC Statistics

At the ingress LER and LSR, statistics collection is configured in the egress data path of an LDP FEC by specifying the FEC prefix with the config>router>ldp>egress-statistics>fec-prefix command. Statistics collection is enabled in the egress data path after the user executes the no shutdown command under the egress-statistics context. By default, this function is in a shutdown state.

The no form of the egress-statistics command disables statistics collection in the egress data path and removes the accounting policy association from the LDP FEC. Users can choose to disable statistics in the egress data path while keeping the accounting policy association of the LDP FEC with the config>router>ldp>egress-statistics>fec-prefix>shutdown command.

Statistics collection applies to prefix FECs imported from both LDP neighbors and T-LDP neighbors.

The egress data path counters are updated for both originating and transit packets. Originating packets may be service packets or IP user and control packets forwarded either as BGP LU over LDP FEC or as VPRN traffic (MP-BGP) over LDP FEC or simply over LDP FEC IGP shortcut. Transit packets of the FEC are label-switched on this node.

When ECMP is enabled and multiple paths exist for a FEC, the same set of counters is updated for each packet forwarded over any of the ECMP links for as long as this FEC is active.

The LDP FEC counters are maintained over the lifetime of the FEC as long as statistics are enabled. The user can clear the counters with the clear>router>ldp>fec-egress-statistics command.

For more information about LDP FEC statistics commands, see LDP Command Reference.

3.4.1.1. Bidirectional Forwarding Detection

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:

3.4.1.3. LSP Resignal Limit

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

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:

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:

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:

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. 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. Implicit Null Label

The implicit null label option enables an eLER to receive MPLS packets from the previous-hop LSR without the outer LSP label.

The implicit null label is included in RESV messages sent by the eLER to the previous-hop LSR. When the implicit null label is signaled to the LSR, it pops the outer label before sending the MPLS packet to the eLER; this is known as penultimate hop popping.

The implicit null label option can be enabled for all RSVP-TE interfaces and for all RSVP-TE LSPs for which the router is the eLER by using the implicit-null-label command in the config>router>rsvp context.

RSVP-TE must be shut down before this command can be used.

The implicit null label option can also be enabled or disabled on a specific RSVP-TE interface, overriding the RSVP-TE level configuration, by using the implicit-null-label {enable | disable} command in the config>router>rsvp>interface context.

The implicit null label is enabled for all LSPs for which the router is the eLER and for which the PATH message is received from the previous-hop LSR over the RSVP-TE interface.

With facility backup, if the eLER is also the merge point (MP) node, the incoming interface for the PATH refresh message over the bypass tunnel dictates whether the packet will use the implicit null label. Similarly, with one-to-one backup, if the eLER is also the detour merge point (DMP) node, the incoming interface for the PATH refresh message over the detour LSP dictates whether the packet will use the implicit null label.

The RSVP-TE interface must be shut down before this command can be used.

3.4.1.8. RSVP-TE Entropy Labels

The 7705 SAR supports entropy labels as described in MPLS Entropy Labels.

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.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:

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.

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.7.4.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.

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.7.4.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.

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.12.2.1. PCC-initiated and PCC-controlled LSPs

For PCC-initiated and PCC-controlled LSPs, the user configures the LSP name, primary path name, and optional secondary path name with the path information in the referenced path name, entering a full or partial explicit path with all or some hops to the destination of the LSP. Each hop is specified as an address of a node or an address of the next hop of a TE link.

To configure the primary path or secondary path to always use a specific link whenever it is up, the strict hop must be entered as an address corresponding to the next hop of an adjacency SID. If the strict hop corresponds to a loopback address, it is translated to an adjacency SID as explained below and therefore there is no guarantee that the same TE link is picked.

To use an SR-TE path that consists of unprotected adjacency SIDs, each hop of the path must be configured as a strict hop with the address matching the next hop of the adjacency SID and protection on each of these adjacencies must be disabled as explained in SR-TE LSP Path Computation.

MPLS assigns a tunnel ID to the SR-TE LSP and a path ID to each new instantiation of the primary path, as for an RSVP-TE LSP. These IDs represent the MBB path of the same SR-TE LSP, which must coexist during the update of the primary path.

Note: The concept of MBB is not exactly accurate in the context of an SR-TE LSP because there is no signaling involved and therefore the new path information immediately overrides the older one.

The router retains full control of the path of the LSP. CSPF is not supported; therefore, the full or partially explicit path is instantiated as is and no other constraint (such as SRLG, admin-group, hop-count, or bandwidth) is checked. Only the LSP path label stack size is checked by MPLS against the maximum value configured for the LSP after the TE database (TE-DB) hop-to-label translation returns the label stack. See SR-TE LSP Path Computation for more information about this check.

The ingress LER performs the following steps to resolve the user-entered path before programming it in the data path:

3.12.2.1.1. Guidelines for Using PCC-initiated and PCC-controlled LSPs

The 7705 SAR does not support CSPF path computation for an SR-TE LSP and uses hop-to-label translation to compute the path. The ingress LER does not monitor network events that affect the reachability of the adjacency SID or node SID used in the label stack of the LSP; therefore, the label stack is not updated to reflect changes in the path except when seamless BFD is used to detect path failures. As a result, it is recommended that this type of SR-TE LSP be used in the following configurations only:

1. empty path
2. path with a single node SID loose hop
3. path of an LSP to a directly connected router (single-hop LSP) with an adjacency SID or a node SID loose or strict hop
4. strict path with hops of adjacencies explicitly configured in the path and seamless BFD used to monitor the LSP

In addition, the user can configure an SR-TE LSP with a single loose hop, using the anycast SID concept to provide LSR node protection within a particular plane of the network TE topology. This is illustrated in Figure 12. The user configures all LSRs in a plane with the same loopback interface address, which must be different from that of the system interface and the router ID of the router, and assigns them the same node SID index value. All routers must use the same SRGB.

Figure 12:  Multi-plane TE with Node Protection 

The user then configures an SR-TE LSP on an LER to a destination and adds to its path a loose hop matching the anycast loopback address. The SR-TE LSP to any destination will hop over the closest of the LSRs owning the anycast SID because the resolution of the node SID for that anycast loopback address uses the closest router. If that router fails, the resolution is updated to the next closest router owning the anycast SID without changing the label stack of the SR-TE LSP.

3.12.2.2. PCC-initiated and PCE-computed/controlled LSP

In the PCC-initiated and PCE-computed/controlled LSP mode of operation, the ingress LER uses PCEP to communicate with a PCE-based external TE controller (also referred to as the PCE). The router instantiates a PCEP session to the PCE. The router is referred to as the PCE client (PCC).

When the user enables the pce-computation option for one or more SR-TE LSPs, the PCE performs path computations at the request of the PCC, which is referred to as passive stateful mode. If the user enables the pce-control option for an LSP, the PCE can also perform both path computation and periodic reoptimization of the LSP path without an explicit request from the PCC. This is referred to as active stateful mode.

For the PCC to communicate with a PCE about the management of the path of an SR-TE LSP, the router implements the extensions to PCEP in support of segment routing (see PCEP for more information).This feature works with the Nokia stateful PCE, which is part of the network services platform (NSP).

The following steps describe configuring a PCC-initiated SR-TE LSP when passive or active control is given to the PCE.

Note: The above procedures are followed when the user performs a no shutdown on a PCE-controlled or PCE-computed LSP. The starting point is an administratively down LSP with no active paths.

The following steps are for an LSP with an active path.

The PCE supports the computation of disjoint paths for two different LSPs originating or terminating on the same or different PE routers. To indicate this constraint to the PCE, the user must configure the PCE path profile ID and path group ID that the LSP belongs to. These parameters are passed transparently by the PCC to the PCE and are therefore opaque data to the router. The user can configure the path profile and path group using the path-profile profile-id [path-group group-id] command.

The association of the optional path group ID is to allow the PCE to determine which profile ID this path group ID must be used with. One path group ID is allowed per profile ID. The user can, however, enter the same path group ID with multiple profile IDs by executing this command multiple times. A maximum of five entries of path-profile [path-group] can be associated with the same LSP. More details of the operation of the PCE path profile are provided in the PCEP chapter.

3.12.3.1. Service and Shortcut Application SR-TE Label Stack Check

Each service and shortcut application on the router performs a check of the resulting net label stack after pushing all the labels required for forwarding the packet in that context. The MPLS module populates each SR-TE LSP in the TTM with the maximum transport label stack size, which consists of the sum of the values in max-sr-labels label-stack-size and additional-frr-labels labels.

Each service or shortcut application then adds the additional, context-specific labels, such as service label and NGE label, required to forward the packet in that context, and checks that the resulting net label stack size does not exceed the maximum label stack supported by the router.

If the check succeeds, the service is bound or the prefix is resolved to the SR-TE LSP. If the check fails, the service will not bind to this SR-TE LSP. Instead, the service will either find another SR-TE LSP or another tunnel of a different type to bind to, if the user configured the use of other tunnel types. Otherwise, the service will go down.

When the service uses an SDP with one or more SR-TE LSPs (up to eight), the spoke SDP bound to this SDP will remain operationally down as long as at least one SR-TE LSP fails the check. In this case, the spoke SDP flag “labelStackLimitExceeded” will be displayed in the show output of the service. As well, the prefix will not get resolved to the SR-TE LSP and will either be resolved to another SR-TE LSP or another tunnel type or become unresolved.

The value of additional-frr-labels labels is checked against the maximum value across all IGP instances of the parameter frr-overhead. The frr-overhead parameter value is computed within an IGP instance as shown in Table 7. For more information on FRR overhead, refer to the “Segment Routing in Shortest Path Forwarding” section in the 7705 SAR Routing Protocols Guide.

When the user configures or changes the configuration of additional-frr-labels, MPLS ensures that the new value accommodates the frr-overhead parameter value across all IGP instances.

For example:

If the check is successful, MPLS adds max-sr-labels and additional-frr-labels and checks that the sum is lower than or equal to the maximum label stack supported by the router. MPLS then populates the value of {max-sr-labels + additional-frr-labels}, along with tunnel information in the TTM, and also passes max-sr-labels to the PCEP module.

Conversely, if the user tries a configuration change that results in a change to the computed frr-overhead, the IGP will check that all SR-TE LSPs can properly account for the overhead; otherwise, the change is rejected. On the IGP, enabling remote-lfa may cause the frr-overhead value to change.

For example:

When the user configures the ti-lfa command, the max-sr-frr-labels value parameter is used to limit the search for the LFA backup next hop, as follows:

When the user attempts to change the max-sr-frr-labels parameter to a value that results in a change to the computed FRR overhead, the IGP checks that all SR-TE LSPs can properly account for the overhead based on the configuration of the LSP max-sr-labels and additional-frr-labels values; otherwise, the change is rejected.

The FRR overhead is computed by the IGP and its value is shown in Table 7.

The above LFA commands allow the user to enable the base LFA feature with the loopfree-alternate command, and to optionally add remote LFA with the remote-lfa option and TI-LFA with the ti-lfa option. For more information, refer to the “Segment Routing in Shortest Path Forwarding” section in the 7705 SAR Routing Protocols Guide.

3.12.5.1. Configuration of S-BFD on SR-TE LSPs

For PCC-initiated or PCC-controlled LSPs, the head end of an S-BFD session is configured under the SR-TE LSP context, the SR-TE primary path context, or the SR-TE secondary path context by using the following commands:

The remote discriminator value is determined by passing the to address of the LSP to BFD, which then matches it to a mapping table of peer IP addresses to reflector remote discriminators. If there is no match for the to address of the LSP, a BFD session is not established on the LSP or path.

Note: A remote peer IP address-to-discriminator mapping must exist prior to bringing an LSP administratively up.

The referenced BFD template must specify parameters that are consistent with an S-BFD session; for example, the endpoint type must be np.

S-BFD can be configured at the LSP level, as follows:

When S-BFD is configured at the LSP level, separate S-BFD sessions with the same configuration are enabled on all primary, secondary, and standby paths of the LSP.

Alternatively, S-BFD can be configured on the primary path or secondary path of the LSP, as follows:

The wait-for-up-timer command is only available if the configured failure action is failover-or-down. For more information, see Support for BFD Failure Action with SR-TE LSPs.

3.12.5.2. Support for BFD Failure Action with SR-TE LSPs

S-BFD provides a mechanism to check the data path forwarding for an SR-TE LSP. If an S-BFD session fails, the LSP can be brought operationally down when the failure-action command is configured with the failover-or-down option. When the failure-action command is configured with the none option, an S-BDF failure will only raise a trap. The failure-action command is available in the following context:

The failure-action command is configured at the LSP level. It can be configured whether S-BFD is applied at the LSP level or the individual path level. The failure-action command can be configured even if the BFD template is not yet configured.

For LSPs configured with a primary path and a secondary or a standby path and a failure action of failover-or-down, the following points apply.

For LSPs configured with only one path and a failure action of failover-or-down, the following points apply.

For LSPs configured with one or more paths and a failure action of none, a BFD trap is raised when the LSP goes down. The path state does not change.

3.12.5.3. S-BFD Operational Considerations

A minimum control packet timer transmit interval of 10 ms can be configured. To maximize the reliability of S-BFD connectivity checking in scaled scenarios with short timers, situations where BFD may go down due to normal changes of the next hop of an LSP path at the head end must be avoided. It is therefore recommended that LFA not be configured at the head-end LER when using S-BFD with sub-second timers. When LFA is not configured, protection of the SR-TE LSP is still provided end-to-end by the combination of S-BFD connectivity checking and primary or secondary path protection.

Similar to LDP and RSVP functionality, S-BFD uses a single path for a loose hop; multiple S-BFD sessions for each of the ECMP paths or spraying of S-BFD packets across the paths is not supported. S-BFD is not down until all the ECMP paths of the loose hop go down.

Note: With very short control packet timer values in scaled scenarios, S-BFD may bounce if the next hop that the path is currently using goes down. This is because it takes time for BFD to be updated to use another next hop in the ECMP set.

3.12.9.1. SR-TE LSP Metric and MTU Settings

The MPLS module assigns an SR-TE LSP the maximum LSP metric value of 16 777 215 when the local router provides the hop-to-label translation for its path. For an SR-TE LSP that uses PCE for path computation (pce-computation option enabled) by the PCE and/or has its control delegated to the PCE (pce-control enabled), the latter will return the computed LSP IGP or TE metric in the PCReq and PCUpd messages. In both cases, the user can override the returned value by configuring an admin metric using the command config>router>mpls>lsp>metric.

The MTU setting of an SR-TE LSP is derived from the MTU of the outgoing SR shortest path tunnel it is using, adjusted with the size of the super NHLFE label stack size.

The following are the details of this calculation:

SR_Tunnel_MTU = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU – (1+ frr-overhead)×4}

where:

This calculation is performed by the IGP and passed to the SR module each time it changes due to an updated resolution of the node SID.

The 7705 SAR also provides the MTU for the adjacency SID tunnel because it is needed in an SR-TE LSP if the first hop in the ERO is an adjacency SID. In that case, the calculation for SR_Tunnel_MTU, initially introduced for a node SID tunnel, is applied to get the MTU of the adjacency SID tunnel.

The MTU of the SR-TE LSP is derived as follows:

SRTE_LSP_MTU = SR_Tunnel_MTU – numLabels×4

where:

This calculation is performed by the SR module and is updated each time the SR-TE LSP path changes or the SR tunnel it is using is updated.