MPLS and RSVP

Packets traveling along an LSP (see Label switching routers) are identified by its label, the 20-bit, unsigned integer. The range is 0 through 1,048,575. Label values 0 to 15 are reserved and are defined below as follows:

• A value of 0 represents the IPv4 Explicit NULL label. It indicates that the label stack must be popped, and the packet forwarding must be based on the IPv4 header. SR OS implementation does not support advertising an explicit-null label value, but can properly process in a received packet.

• 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. Because this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.

• A value of 2 represents the IPv6 explicit NULL label. It indicates that the label stack must be popped, and the packet forwarding must be based on the IPv6 header. SR OS implementation does not support advertising an explicit-null label value, but can properly process in a received packet.

• A value of 3 represents the Implicit NULL label. This is a label that a Label Switching Router (LSR) can assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is Implicit NULL, the LSR pops the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol (LDP) or RSVP-TE protocol, so a value is reserved.

• A value of 7 represents the Entropy Label Indicator (ELI) which precedes in the label stack the actual Entropy Label (EL) which carries the entropy value of the packet.

• A value of 13 represents the Generic-ACH Label (GAL), an alert mechanism used to carry OAM payload in MPLS-TP LSP.

• Values 5-6, 8-12, and 14-15 are reserved for future use.

The router uses labels for MPLS, RSVP-TE, LDP, BGP Label Unicast, Segment Routing, as well as packet-based services such as VLL and VPLS.

Label values 16 through 1,048,575 are defined as follows:

• label values 16 through 31 are reserved for future use

• label values 32 through 18,431 are available for static LSP, MPLS-TP LSP, and static service label assignments. The upper bound of this range, which is also the lower bound of the dynamic label range, is configurable such that the user can expand or shrink the static or dynamic label range.

• label values 18,432 through 524,287 (1,048,575 in FP4, or later FP generation, profile B) are assigned dynamically by RSVP, LDP, and BGP control planes for both MPLS LSP and service labels.

• label values 524,288 through 1,048,575 are not assigned by SR OS in system profiles other than FP4, or later FP generation, profile B, and therefore no POP or SWAP label operation is possible in that range and for those system profiles. However, a PUSH operation, with a label from the full range 32 through 1,048,575 if signaled by some downstream LSR for LSP or service, is supported.

The user can carve out a range of the dynamic label space dedicated for labels of the following features:

• Segment Routing Global Block (SRGB) and usable by Segment Routing in OSPF and ISIS.

• Reserved Label Block for applications such as SR policy, MPLS forwarding policy, and the assignment of a static label to the SID of a ISIS or OSPF adjacency and adjacency set.

Reserved label blocks are used to reserve a set of labels for allocation for various applications. These reserved label blocks are separate from the existing ranges such as the static-labels-range, and are not tied to the bottom of the labels range. For example, a reserved range may be used as a Segment Routing Local Block (SRLB) for local segment identifiers (SIDs). Ranges are reserved from the dynamic label range and up to four reserved label block ranges may be configured on a system.

A range can be configured up to the maximum supported MPLS label value on the system.

[ex:/configure router "Base" mpls-labels]
A:admin@node-2# info
    reserved-label-block "test" {
        start-label 18432
        end-label 20000
    }

A:node-2>config>router>mpls-labels# info
----------------------------------------------
            reserved-label-block "test"
                start-label 18432 end-label 20000
            exit
----------------------------------------------

The hash label is supported on VLL, VPRN, or VPLS services bound to any MPLS type encapsulated SDPs, as well as to a VPRN service using the auto-bind-tunnel command with the resolution-filter command set to any MPLS tunnel type. When enabled, the ingress datapath is modified such that the result of the hash on the payload packet header is communicated to the egress datapath for use as the value of the label field of the hash label. The egress datapath appends the hash label to the bottom of the stack (BoS) and sets the S-bit to 1. The TTL of the hash label is set to a value of 0. The user enables the signaling of the hash-label capability under a VLL spoke SDP, a VPLS spoke SDP or mesh SDP, or an IES or VPRN spoke SDP interface by adding the signal-capability option. When this capability is enabled, the decision to insert the hash label on the user and control plane packets by the local PE is determined by the outcome of the signaling process and may override the local PE configuration.

The MPLS entropy label provides a similar function to the hash label, but is applicable to a wider range of services. The entropy label is appended directly below the tunnel label. As with the hash label, the value of the entropy label is calculated based on a hash of the packet payload header.

The router supports the entropy label for the following services and protocols:

• VPRN

• EVPN VPLS and Epipe

• RFC 8277 MP-BGP tunnels

• RSVP and LDP LSPs used as shortcuts for static, IGP, and BGP route resolution

• VLLs, including BGP VPWS, IES/VPRN, and VPLS spoke-SDP termination, but not including Cpipe

• LDP VPLS and BGP-AD VPLS

• PW ports bound to a specific physical port supporting PW-SAPs used for Epipe VLL, IES, VPRN, and Enhanced Subscriber Management services

The entropy label is supported with the following tunnel types:

• RSVP-TE: configured and auto-LSPs

• LDP

• Segment Routing (shortest path, PCC and PCE-initiated SR-TE and SR-TE auto-LSPs)

• BGP

The entropy label is not supported on P2MP LSPs.

The entropy label indicated (ELI) label (value=7) is a special-purpose label that indicates that the entropy label follows in the stack. It is always placed immediately below the tunnel label to which hashing applies. Inserting the EL adds two labels in the MPLS label stack: the EL and its accompanying ELI.

The following sections provide more detailed information about these three criteria.

configure router ldp entropy-label-capability
configure router rsvp entropy-label-capability

This section describes entropy label processing. Details specific to particular services or other tunnel types are described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide, 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN, and the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.

A router acting as a stitching point between two LSPs maps the ELC received in signaling for a downstream segment to the upstream segment for the level in the LSP hierarchy being stitched.

If an LSR is stitching an RSVP or LDP segment to a downstream segment of a tunnel type that does not support ELC signaling (for example, BGP) and the override-tunnel-elc command is configured at the LSR for the to command's downstream segment, the system signals ELC on the upstream LSP segment. The override-tunnel-elc command must be configured to reflect whether all possible downstream LERs are entropy-label-capable; otherwise, packets with an EL are discarded by a downstream LER that is not entropy-label-capable.

The mapping of ELC across LDP-BGP stitching points is not supported. If a downstream tunnel endpoint signals ELC, this signal is not automatically propagated upstream. The EL and ELI are not inserted on these LSPs by the ingress LER.

Service OAM packets or OAM packets within the context of a shortcut (for example, ICMP Ping or traceroute packets), also include an EL and ELI if ELC is signaled for the corresponding tunnel and the entropy-label command is enabled for the service. The EL and ELI is inserted at the same level in the label stack as it is in user data packets, which is under the innermost LSP label closest to the service payload that has advertised ELC. The EL and ELI therefore always reside at a different level in the label stack than the special-purpose labels related to the service payload (such as the Router Alert label). OAM packets at the LSP level, such as LSP ping and LSP trace, do not have the EL and ELI inserted.

If EL insertion is configured for a VPLS or VLL service, the MTU of the SDP binding is automatically reduced to account for the overhead of the EL and ELI labels. The MTU is reduced whether the LSP tunnel used by the service is entropy-label-capable.

The EL requires the insertion of two additional labels in the label stack. In some cases, the insertion of EL and ELI may result in an unsupported label stack depth or large changes in the label stack depth during the lifetime of an LSP. For RSVP LSPs, use the following commands to provide local control at the head-end of an LSP over whether the entropy label is inserted on an LSP irrespective of the entropy label capability signaled from the egress LER, and control over how the additional label stack depth is accounted for.

configure router mpls entropy-label
configure router mpls lsp entropy-label

This control allows a user to avoid entropy label insertion where there is a risk of the label stack becoming too deep.

The following are LSP types:

• static LSPs

  A static LSP specifies a static path. All routers that the LSP traverses must be configured manually with labels. No signaling such as RSVP or LDP is required.

• signaled LSPs

  LSPs are set up using a signaling protocol such as RSVP-TE or LDP. 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.

  There are two signaled LSP types:

  • 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 through other routers (loose). You can control how the path is set up. They are similar to static LSPs but require less configuration. See RSVP.

  • 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 which satisfies the constraints for the LSP. In turn, CSPF relies on the topology database provided by the extended IGP such as OSPF or IS-IS.

    After the path is found by CSPF, RSVP uses the path to request the LSP set up. CSPF calculates the shortest path based on the constraints provided such as bandwidth, class of service, and specified hops.

If fast reroute is configured, the ingress router signals the routers downstream. Each downstream router sets up a detour for the LSP. If a downstream router does not support fast reroute, the request is ignored and the router continues to support the LSP. This can cause some of the detours to fail, but otherwise the LSP is not impacted.

The hop limit command option specifies the maximum number of hops that an LSP can traverse, including the ingress and egress routers. An LSP is not set up if the hop limit is exceeded. The hop count is set to 255 by default for the primary and secondary paths. It is set to 16 by default for a bypass or detour LSP path.

A BFD session on an LSP is bootstrapped using LSP ping. LSP ping is used to exchange the local and remote discriminator values to use for the BFD session for a particular MPLS LSP or FEC.

SR OS supports the sending of periodic LSP ping messages on an LSP for which LSP BFD has been enabled, as specified in RFC 5884. The ping messages are sent, along with the bootstrap TLV, at a configurable interval for LSPs on which the following command has been configured:

The default interval is 60 seconds, with a maximum interval of 300 seconds. The LSP ping Echo Request message uses the system IP address as the default source address. An alternative source address consisting of any routable address that is local to the node may be configured, and is used if the local system IP address is not routable from the far-end node.

configure router mpls lsp bfd lsp-ping-interval

LSP BFD sessions are recreated after a High-Availability (HA) switchover between active and standby CPMs. However, some disruption may occur to LSP ping because of LSP BFD.

At the tail end of an LSP, sessions are recreated on the standby CPM following an HA switchover. The following current information is lost from an active display of the following command.

tools dump test-oam lsp-bfd tail

• handle

• seqNum

• rc

• rsc

Any new, incoming bootstrap requests are dropped until LSP BFD becomes active. When LSP BFD becomes active, new bootstrap requests are considered.

A user can enable support for LSP BFD and allow an upper limit to the number of supported sessions at the tail end node for LSPs. This is useful because BFD resources are shared among applications using BFD, so a user may want to set an upper limit to ensure that a specified number of BFD sessions are reserved for other applications. This is important at the tail end of LSPs where no per-LSP configuration context exists.

configure router lsp-bfd bfd-sessions

configure router lsp-bfd tail-end multiplier
configure router lsp-bfd tail-end receive-interval
configure router lsp-bfd tail-end transmit-interval

LSP BFD is applicable to configured RSVP LSPs as well as mesh-p2p and one-hop-p2p auto-LSPs.

LSP BFD is configured on an RSVP-TE LSP, or on the primary or secondary path of an RSVP-TE LSP, under the bfd context at the LSP head end.

A BFD template must always be configured first. BFD is then enabled using the following command.

• MD-CLI

  configure router mpls lsp bfd bfd-liveness true

• classic CLI

  configure router mpls lsp bfd bfd-enable 

When BFD is configured at the LSP level, BFD packets follow the currently active path of the LSP.

The BFD bfd-template command provides the control packet timer values for the BFD session to use at the LSP head end. Because there is no LSP configuration at the tail end of an RSVP LSP, the BFD state machine at the tail end initially uses system-wide default command options (the timer values are: min-tx: 1sec, min-rx: 1sec). The head end then attempts to adjust the control packet timer values when it transitions to the INIT state.

The BFD wait-for-up-timer command allows RSVP LSPs BFD sessions to come up during MBB and switchover events when the current active path is not BFD degraded (that is, BFD is not down). It is only applicable in cases where the BFD failure-action failover-or-down command is also configured (see Using LSP BFD for LSP path protection) and applies to the following:

• a path undergoing MBB when BFD is up on the original path

• the initial administrative enable of an LSP

• signaling retry of non-standby secondary paths

The wait-for-up-timer command is configured under the contexts that follow. The value that the system uses is the one configured under the same context in which BFD has been enabled.

Use the commands in following context to configure BFD on RSVP LSPs or Seamless BFD on SR-TE LSPs.

configure router mpls lsp bfd

Use the commands in the following context to configure BFD at the primary-path level.

configure router mpls lsp primary bfd

Use the commands in the following context to configure BFD on both standby and non-standby secondary paths.

configure router mpls lsp secondary bfd

BFD sessions are not established on these paths unless they are made active, unless failure-action failover-or-down is configured. See Using LSP BFD for LSP path protection. If failure-action failover-or-down is configured then the top three best-preference primary and standby paths (primary and up to two standby paths, or three standby paths if no primary is present) are programmed in the IOM, and BFD sessions are established on all of them.

It is not possible to configure LSP BFD on a secondary path or on P2MP LSPs.

LSP BFD at the LSP level and the path level is mutually exclusive. That is, if LSP BFD is already configured for the LSP then its configuration for the path is blocked. Likewise, it cannot be configured on the LSP if it is already configured at the path level.

[ex:/configure router "Base" mpls]
A:admin@node-2# info
    lsp-template "test1" {
        type p2p-rsvp-mesh
        bfd {
            bfd-liveness true
            bfd-template "test"
        }
    }

A:node-2>config>router>mpls# info
----------------------------------------------
...
            lsp-template "test1" mesh-p2p
                shutdown
                path-computation-method local-cspf
                bfd
                    bfd-template "test"
                    bfd-enable
                exit
            exit
----------------------------------------------

[ex:/configure router "Base" mpls]
A:admin@node-2# info
...
    lsp-template "test2" {
        type p2p-rsvp-one-hop
        bfd {
            bfd-liveness true
            bfd-template "test"
        }
    }

A:node-2>config>router>mpls# info
----------------------------------------------
...
            lsp-template "test2" one-hop-p2p
                shutdown
                path-computation-method local-cspf
                hop-limit 2
                bfd
                    bfd-template "test"
                    bfd-enable
                exit
            exit
----------------------------------------------

SR OS can determine the forwarding state of an LSP from the LSP BFD session, allowing users of the LSP to determine whether their transport is operational. If BFD is down on an LSP path, then the path is considered to be BFD degraded by the system.

Use the commands in the following contexts to configure the action the system takes if BFD fails for an RSVP LSP or LDP prefix list.

configure router mpls lsp bfd failure-action
configure router mpls lsp-template bfd failure-action
configure router ldp lsp-bfd failure-action

There are three possible failure actions:

• failure-action down

  The LSP is marked as unusable in TTM when BFD on the LSP goes down. This is applicable to RSVP and LDP LSPs.

• failure-action failover

  When LSP BFD goes down on the currently active path, then the LSP switches from the primary path to the secondary path, or from the currently active secondary path to the next-best preference secondary path. This is applicable to RSVP LSPs.

• failure-action failover-or-down

  Similar to failure-action failover, when LSP BFD goes down on the currently active path, then the LSP switches from the primary path to the secondary path, or from the currently active secondary path to the next best preference secondary path. However, failure-action failover-or-down also supports the ability to run BFD sessions simultaneously on the primary and up to two other secondary or standby paths. The system does not switch to a standby path for which the BFD session is down. If all BFD sessions for the LSP are down, then the LSP is marked as unusable in TTM. This is applicable to RSVP LSPs and SR-TE LSPs. See the 7750 SR and 7950 XRS Segment Routing and PCE User Guide for further details of its use for SR-TE LSPs.

In all cases, an SNMP trap is raised indicating that BFD has gone down on the LSP.

The MPLS/RSVP on Broadcast Interface feature allows MPLS and RSVP to distinguish neighbors from one another when the outgoing interface is a broadcast interface connecting to multiple neighbors over a broadcast domain. More specifically, in the case where a BFD session toward a specific neighbor on the broadcast domain goes down, the consecutive actions (for example, FRR switchover) only concerns the LSPs of the affected neighbor. Previously, the actions would have been taken on the LSPs of all neighbors over the outgoing interface.

The PLR uses rules to select a bypass LSP among multiple manual and dynamic bypass LSPs at the time of establishment of the primary LSP path or when searching for a bypass for a protected LSP which does not have an association with a bypass tunnel: Bypass tunnel nodes shows an example of bypass tunnel nodes.

The rules are:

1. The MPLS task in the PLR node checks if an existing manual bypass satisfies the constraints. If the path message for the primary LSP path indicated node protection is needed, which is the default LSP FRR setting at the head end node, MPLS task searches for a node-protect bypass LSP. If the path message for the primary LSP path indicated link protection is needed, then it searches for a link-protect bypass LSP.

2. If multiple manual bypass LSPs satisfying the path constraints exist, it prefers a manual-bypass terminating closer to the PLR over a manual bypass terminating further away. If multiple manual bypass LSPs satisfying the path constraints terminate on the same downstream node, it selects one with the lowest IGP path cost or if in a tie, picks the first one available.

3. If none satisfies the constraints and dynamic bypass tunnels have not been disabled on PLR node, then the MPLS task in the PLR checks if any of the already established dynamic bypasses of the requested type satisfy the constraints.

4. If none do, then the MPLS task asks CSPF to check if a new dynamic bypass of the requested type, node-protect or link-protect, can be established.

5. If the path message for the primary LSP path indicated node protection is needed, and no manual bypass was found after Step 1, or no dynamic bypass LSP was found after one attempt of performing Step 3, the MPLS task repeats Steps 1 to 3 looking for a suitable link-protect bypass LSP. If none are found, the primary LSP has 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. Node protection continues to be attempted using a background re-evaluation process.

6. If the path message for the primary LSP path indicated link protection is needed, and no manual bypass was found after Step 1, or no dynamic bypass LSP was found after performing Step 3, the primary LSP has 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 does not search for a node-protect’ bypass LSP in this case.

7. If the PLR node successfully makes an association, it must set the ‟local protection available” flag in the IPv4 address sub-object of the RRO starting in the next RESV refresh message it sends upstream.

8. For all primary LSP that requested FRR protection but are not currently associated with a bypass tunnel, the PLR node on reception of RESV refresh on the primary LSP path repeats Steps 1 to 7.

If the user disables dynamic-bypass tunnels on a node while dynamic bypass tunnels were activated and were passing traffic, traffic loss occurs on the protected LSP. Furthermore, if no manual bypass exist that satisfy the constraints of the protected LSP, the LSP remains without protection.

If the user configures a bypass tunnel on node B and dynamic bypass tunnels have been disabled, LSPs which have been previously signaled and which were not associated with any manual bypass tunnel, for example, none existed, are associated with the manual bypass tunnel if suitable. The node checks for the availability of a suitable bypass tunnel for each of the outstanding LSPs every time a 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 which have been previously signaled over dynamic bypass tunnels are not automatically switched into the manual bypass tunnel even if the manual bypass is a more optimized path. The user must perform a make before break at the head end of these LSPs.

If the manual bypass goes into the down state in node B and dynamic bypass tunnels have been disabled, node B (PLR) clears the ‟protection available” flag in the RRO IPv4 sub-object in the next RESV refresh message for each affected LSP. It then tries to associate each of these LSPs with one of the manual bypass tunnels that are still up. If it finds one, it makes the association and sets again the ‟protection available” flag in the next RESV refresh message for each of these LSPs. If it could not find one, it keeps checking for one every time a RESV message is received for each of the remaining LSPs. When the manual bypass tunnel is back UP, the LSPs which did not find a match are associated back to this tunnel and the protection available flag is set starting in the next RESV refresh message.

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

The MPLS Fast Re-Route (FRR) feature implements a background task to evaluate Path State Block (PSB) associations with bypass LSP. The following is the task evaluation behavior:

• For PSBs that have facility FRR enabled but no bypass association, the task triggers a FRR protection request.

• For PSBs that have requested node-protect bypass LSP but are currently associated with a link-protect bypass LSP, the task triggers a node-protect FRR request.

• For PSBs that have LSP statistics enabled but the statistic index allocation failed, the task re-attempts index allocation.

The MPLS FRR background task enables PLRs to be aware of the missing node protection and allows them to probe regularly for a node-bypass. FRR node-protection example shows an example of FRR node protection.

The following describes an LSP scenario where:

• LSP 1: from PE_1 to PE_2, with CSPF, FRR facility node-protect enabled

• P_1 protects P_2 with bypass-nodes P_1 -P_3 - P_4 - PE_4 -PE_2

• If P_4 fails, P_1 tries to establish the bypass-node three times

• When the bypass-node creation fails, P_1 protects link P_1-P_2

• P_1 protects the link to P_2 through P_1 - P_5 - P_2

• P_4 returns online

LSP 1 has requested node protection, but because there is no available path, it can only obtain link protection. Therefore, every 60 seconds the PSB background task triggers the PLR for LSP 1 to search for a new path that can provide node protection. When P_4 is back online and such a path is available, a new bypass tunnel is signaled and LSP 1 gets associated with this new bypass tunnel.

This section discusses an auto-bandwidth hierarchy configurable in the following context.

configure router mpls lsp

Adding auto-bandwidth at the LSP level starts the measurement of LSP bandwidth described in Measurement of LSP bandwidth and allows auto-bandwidth adjustments to take place based on the triggers described in Periodic automatic bandwidth adjustment.

When an LSP is first established, the bandwidth reserved along its primary path is controlled by the following command, whether the LSP has auto-bandwidth enabled or not.

configure router mpls lsp primary bandwidth

The bandwidth reserved along a secondary path is controlled by the following command.

configure router mpls lsp secondary bandwidth

When auto-bandwidth is enabled and a trigger occurs, the system attempts to change the bandwidth of the LSP to a value between min-bandwidth and max-bandwidth, which are configurable values in the following context.

configure router mpls lsp auto-bandwidth

The min-bandwidth option is the minimum bandwidth that auto-bandwidth can signal for the LSP, and the max-bandwidth option is the maximum bandwidth that can be signaled. The user can set the min-bandwidth to the same value as the primary path bandwidth but the system does not enforce this restriction. The system allows:

• no min-bandwidth to be configured. In this case, the implicit minimum is 0 Mb/s.

• no max-bandwidth to be configured, as long as overflow-triggered auto-bandwidth is not configured. In this case, the implicit maximum is infinite (effectively 100 Gb/s).

• the configured primary path bandwidth to be outside the range of min-bandwidth to max-bandwidth

• the auto-bandwidth configuration can be changed at any time on an operational LSP; in most cases, the changes have no immediate impact, but subsequent sections describe some exceptions.

All of the auto-bandwidth adjustments discussed are performed using MBB procedures.

Auto-bandwidth can be added to an operational LSP at any time (without the need to administratively disable the LSP or path), but no bandwidth change occurs until a future trigger event. Auto-bandwidth may also be removed from an operational LSP at any time and this causes an immediate MBB bandwidth change to be attempted using the configured primary path bandwidth.

A change to the configured bandwidth of an auto-bandwidth LSP has no immediate effect. The change only occurs if the LSP or path goes down (because of a failure or an administrative action) and comes back up, or if auto-bandwidth is removed from the LSP. The user can force an auto-bandwidth LSP to be resized immediately to an arbitrary bandwidth using the appropriate tools commands.

Auto-bandwidth is supported for LSPs that have secondary or secondary standby paths. A secondary path is only initialized at its configured bandwidth when it is established, and the bandwidth is adjusted only when the secondary path becomes active.

Auto-bandwidth on LSPs with standby paths use the following terminology.

Current bandwidth

the last known reserved bandwidth for the LSP; may be the value of a different path from the currently active path

Operational bandwidth

the last known reserved bandwidth for a specified path, as recorded in the MIB

Configured bandwidth

the bandwidth explicitly configured for the LSP path by the user in CLI

Active path

the path (primary or secondary) the LSP currently uses to forward traffic

Signaled bandwidth

the new bandwidth value signaled during an MBB

A secondary or standby secondary path is initially signaled with its configured bandwidth. Setup for the secondary path is triggered only when the active path goes down or becomes degraded (for example, because of FRR or preemption). An auto-bandwidth triggered bandwidth adjustment (auto bandwidth MBB) only takes place on the active path. For example, if an auto-bandwidth adjustment occurs on the primary path, which is currently active, no adjustment is made at that time to the secondary path because that path is not active.

When the active path changes, the current bandwidth is updated to the operational bandwidth of the newly active path. While the auto-bandwidth MBB on the active path is in progress, a statistics sample could be triggered, and this would be collected in the background. Auto-bandwidth computations use the current bandwidth of the newly active path. In case the statistics sample collection results in a bandwidth adjustment, the in-progress auto-bandwidth MBB is restarted. If after five attempts, the auto-bandwidth MBB fails, the current bandwidth and secondary operational bandwidth remain unchanged.

For a secondary or standby secondary path, if the active path for an LSP changes (without the LSP going down), an auto-bandwidth MBB is triggered for the new active path. The bandwidth used to signal the MBB is the operational bandwidth of the previous active path. If the MBB fails, it retries with a maximum of five attempts. The reserved bandwidth of the newly active path is therefore its configured bandwidth until the MBB succeeds.

For a secondary path where the active path goes down, the LSP goes down temporarily until the secondary path is setup. If the LSP goes down, all statistics and counters are cleared, so the previous path operational bandwidth is lost. That is, the operational BW of a path is not persistent across LSP down events. In this case, there is no immediate bandwidth adjustment on the secondary path.

The following algorithm is used to determine the signaled bandwidth on a newly active path:

• For a path that is operationally down, signaled bandwidth = configured bandwidth.

• For the active path, if an auto-bandwidth MBB adjustment is in progress, signaled bandwidth = previous path operational bandwidth for the first five attempts. For the remaining attempts, the signaled bandwidth = operational BW.

• For an MBB on the active path (other than an auto-BW MBB), MBB signaled BW = operational BW.

• For an MBB on the inactive path, MBB signaled bandwidth = configured BW.

If the primary path is not the currently active path and it has not gone down, then any MBB uses the configured bandwidth for the primary path. However, if the configured bandwidth is changed for a path that is currently not active, then a config change MBB is not triggered.

If the standby is SRLG enabled, and the active path is the standby, and the primary comes up, this immediately triggers a delayed retry MBB on the standby. If the delayed retry MBB fails, immediate reversion to the primary occurs regardless of the retry timer.

When the system reverts from a secondary standby or secondary path to the primary path, a Delayed Retry MBB is attempted to bring the bandwidth of the standby path back to its configured bandwidth. Delayed Retry MBB is attempted one time, and if it fails, the standby is torn down. A Delayed Retry MBB has highest priority among all MBBs, so it takes precedence over any other MBB in progress on the standby path (for example, config change or preemption).

The system carries over the last signaled bandwidth of the LSP over multiple failovers. For example, if an LSP is configured with auto-bandwidth for some time, and adjusts its currently reserved bandwidth for the primary, and Monitor mode is then enabled, bandwidth adjustment on the primary ceases, but the bandwidth remains reserved at the last adjusted value. Next, the LSP fails over to a secondary or secondary standby. The secondary inherits the last reserved bandwidth of the primary, but then disables further adjustment as long as monitoring mode is enabled.

The system’s ability to carry-over the last signaled BW across failovers has the following limitations:

• case 1

  If the LSP fails over from path1 to path2 and the auto-bandwidth MBB on path2 is successful, the last signaled bandwidth is carried over when the LSP reverts back to path1 or fails over to a new path3. This may trigger an auto-bandwidth MBB on the new active path to adjust its bandwidth to last signaled BW.

• case 2

  If the LSP fails over from path1 to path2 and the auto-bandwidth MBB on path2 is still in progress and the LSP reverts back to path1 or fails over to a new path3, the last signaled BW is carried over to the new active path (path1 or path3) and this may result in an auto-bandwidth MBB on that path.

• case 3

  If the LSP fails over from path1 to path2 and the auto-bandwidth MBB on path2 fails (after 5 retry attempts), the last signaled bandwidth from when path1 was active is lost. Therefore, when the LSP reverts back to path1 or fails over to a new path3, the original signaled bandwidth from path1 is not carried over. However the signaled bandwidth of path2 is carried over to the new active path (path1 or path3) and may trigger an AutoBW on that path.

A user must configure the LSP for egress statistics collection at the ingress LER to allow for automatic adjustment of RSVP LSP bandwidth based on measured traffic rate into the tunnel. The following example displays the configuration of egress statistics collection at the ingress LER.

[ex:/configure router "Base" mpls lsp "test3"]
A:admin@node-2# info
...
    egress-statistics {
        admin-state enable
        collect-stats true
        accounting-policy 99
    }

A:node-2>config>router>mpls>lsp$ info
----------------------------------------------
                egress-statistics
                    collect-stats
                    accounting-policy 99
                    no shutdown
                exit
                no shutdown
----------------------------------------------

[ex:/configure log]
A:admin@node-2# info
    accounting-policy 99 {
        collection-interval 5
        record combined-mpls-lsp-egress
    }

A:node-2>config>log# info
----------------------------------------------
        accounting-policy 99
            shutdown
            record combined-mpls-lsp-egress
            collection-interval 5
        exit

configure log accounting-policy record

configure router mpls auto-bandwidth-multipliers sample-multiplier

configure router mpls lsp auto-bandwidth multiplier

configure router mpls auto-bandwidth-multipliers adjust-multiplier

configure router mpls lsp auto-bandwidth multipliers

configure router mpls auto-bandwidth-multipliers
configure router mpls lsp auto-bandwidth multipliers

configure router mpls lsp-template auto-bandwidth monitor-bandwidth 

Use the following command to view the maximum average data rate in the current adjust interval and the remaining time in the current adjust interval.

show router mpls lsp detail

Automatic bandwidth allocation is supported on any RSVP LSP that has MBB enabled in the following context.

configure router mpls lsp adaptive

If the following command is enabled, the LSP is not resignaled to adjust its bandwidth to the calculated values.

configure router mpls lsp auto-bandwidth monitor-bandwidth

If an eligible RSVP LSP is configured for auto-bandwidth using the following command, the ingress LER decides for every adjust interval whether to attempt an auto-bandwidth adjustment.

configure router mpls lsp auto-bandwidth

The following options are defined.

Current bandwidth

the currently reserved bandwidth of the LSP; this is the operational bandwidth that is already maintained in the MIB

Measured bandwidth

the maximum average data rate in the current adjust interval

Signaled bandwidth

the bandwidth that is provided to the CSPF algorithm and signaled in the SENDER_TSPEC and FLOWSPEC objects when an auto-bandwidth adjustment is attempted

Minimum bandwidth

the configured minimum bandwidth of the LSP

Maximum bandwidth

the configured maximum bandwidth of the LSP

Bandwidth percentage up

the minimum difference between measured bandwidth and current bandwidth, expressed as a percentage of current bandwidth, for increasing the bandwidth of the LSP

Bandwidth up

the minimum difference between measured bandwidth and current bandwidth, expressed as an absolute bandwidth relative to current bandwidth, for increasing the bandwidth of the LSP. This is optional; if not defined the value is 0.

Bandwidth percentage down

the minimum difference between current bandwidth and measured bandwidth, expressed as a percentage of current bandwidth, for decreasing the bandwidth of the LSP

Bandwidth down

the minimum difference between current bandwidth and measured bandwidth, expressed as an absolute bandwidth relative to current bandwidth, for decreasing the bandwidth of the LSP. This is optional; if not defined the value is 0.

At the end of every adjust interval the system decides if an auto-bandwidth adjustment should be attempted. The heuristics are as follows:

• If the measured bandwidth exceeds the current bandwidth by more than the percentage threshold and also by more than the absolute threshold then the bandwidth is re-signaled to the measured bandwidth (subject to minimum and maximum constraints).

• If the measured bandwidth is less than the current bandwidth by more than the percentage threshold and also by more than the absolute threshold then the bandwidth is re-signaled to the measured bandwidth (subject to minimum and maximum constraints).

• If the current bandwidth is greater than the maximum bandwidth then the LSP bandwidth is re-signaled to the maximum bandwidth, even if the thresholds have not been triggered.

• If the current bandwidth is less than the minimum bandwidth then the LSP bandwidth is re-signaled to minimum bandwidth, even if the thresholds have not been triggered.

Changes to the minimum bandwidth, maximum bandwidth, and any of the threshold values (up, up%, down, down%) are permitted at any time on an operational LSP, but the changes have no effect until the next auto-bandwidth trigger (for example, adjust interval expiry).

If the measured bandwidth exceeds the current bandwidth by more than the percentage threshold and also by more than the absolute threshold then the bandwidth is re-signaled to the measured bandwidth (subject to minimum and maximum constraints).

The adjust interval and maximum average data rate are reset whether the adjustment succeeds or fails. If the bandwidth adjustment fails (for example, CSPF cannot find a path), the existing LSP is maintained with its existing bandwidth reservation. The system does not retry the bandwidth adjustment (for example, per the configuration of the LSP retry timer and retry limit).

For cases where the measured bandwidth of an LSP has increased significantly since the start of the current adjust interval, it may be desirable for the system to preemptively adjust the bandwidth of the LSP and not wait until the end of the adjust interval.

The following options are defined.

Current bandwidth

the currently reserved bandwidth of the LSP

Sampled bandwidth

the average data rate of the sample interval that just ended

Measured bandwidth

the maximum average data rate in the current adjust interval

Signaled bandwidth

the bandwidth that is provided to the CSPF algorithm and signaled in the SENDER_TSPEC and FLOWSPEC objects when an auto-bandwidth adjustment is attempted

Maximum bandwidth

the configured maximum bandwidth of the LSP

Percentage threshold

the minimum difference between the sampled bandwidth and the current bandwidth, expressed as a percentage of the current bandwidth, for counting an overflow event

Minimum threshold

the minimum difference between the sampled bandwidth and the current bandwidth, expressed as an absolute bandwidth relative to current bandwidth, for counting an overflow event. This is optional; if not defined the value is 0.

When a sample interval ends it is counted as an overflow if:

• The sampled bandwidth exceeds the current bandwidth by more than the percentage threshold and by more than the absolute bandwidth threshold (if defined).

• When the number of overflow samples reaches a configured limit, an immediate attempt is made to adjust the bandwidth to the measured bandwidth (subject to the min and max constraints).

If the bandwidth adjustment is successful, then the adjust-interval, maximum average data rate, and overflow count are all reset. If the bandwidth adjustment fails, then the overflow count is reset but the adjust-interval and maximum average data rate continue with current values. It is possible that the overflow count reach the configured limit again before the end of adjust-interval is reached and this triggers again an immediate auto-bandwidth adjustment attempt.

The overflow configuration command fails if the max-bandwidth of the LSP has not been defined.

The threshold limit can be changed on an operational auto-bandwidth LSP at any time and the change should take effect at the end of the current sample interval (for example, if the user decreases the overflow limit to a value lower than the current overflow count, then auto-bandwidth adjustment takes place as soon as the sample interval ends). The threshold values can also be changed at any time (for example, percentage threshold and minimum threshold), but the new values do not take effect until the end of the current sample interval.

Use the following command to trigger auto-bandwidth adjustment to attempt an immediate auto-bandwidth adjustment for either one specific LSP or all active LSPs.

tools perform router mpls adjust-autobandwidth [lsp lsp-name [force [bandwidth mbps]]]

If the LSP is not specified, the system assumes the command applies to all LSPs. If an LSP name is provided, the command applies to that specific LSP only and the force command option (with or without a bandwidth) can be used.

If force is not specified (or the command is not LSP-specific), the measured bandwidth is compared to the current bandwidth and bandwidth adjustment may or may not occur.

If force is specified and a bandwidth is not provided, the threshold checking is bypassed but the minimum and maximum bandwidth constraints are still enforced.

If force is specified with a bandwidth (in Mb/s), the signaled bandwidth is set to this bandwidth. There is no requirement that the bandwidth entered as part of the command fall within the range of the min‑bandwidth rate to max-bandwidth rate.

The adjust interval, maximum average data rate, and overflow count are not reset by the manual auto‑bandwidth command, whether the bandwidth adjustment succeeds or fails. The overflow count is reset only if the manual automatic bandwidth adjustment is successful.

SR OS supports carrying over of the operational bandwidth (for example, the last successfully signaled bandwidth) of an LSP path to the next active path following a switchover. The new active path can be a secondary or a primary path. The bandwidth is not lost even when the previously active path fails. The last successfully signaled bandwidth is known as the last adjusted bandwidth.

Use the following command to configure operational bandwidth carryover.

configure router mpls lsp auto-bandwidth use-last-adj-bw

When enabled, secondary paths are initially signaled with the last adjusted bandwidth of the primary, and not the configured bandwidth. If signaling a secondary at this bandwidth fails after a number of retries, then the path fails instead of falling back to using the configured bandwidth. Use the following command to configure the number of retries for secondary paths at the last adjusted bandwidth.

configure router mpls lsp auto-bandwidth use-last-adj-bw secondary-retry-limit

Disabling the primary or any configuration that changes events causing a switch to a secondary uses the last adjusted bandwidth. The user can toggle the use-last-adj-bw command at any time; this does not require administratively disabling auto-bandwidth, however, the new value is not used until the next path switchover.

If the revert timer is enabled, the primary is resignaled before the revert timer expires with its configured bandwidth. An auto-bandwidth MBB using the last adjusted bandwidth of the secondary occurs immediately on switching back when the revert timer expires. If the system switches to a new path while an auto-bandwidth MBB is in progress on the previously active path, then the bandwidth used to signal the new path is the new value that was being attempted on the old path (instead of the last adjusted bandwidth). This means that the new path establishes with the most up to date bandwidth for the LSP (provided sufficient network resources are available) instead of a potentially out of date bandwidth.

By default, the system continuously collects statistics (packet and octet counts) of MPLS traffic on ingress and egress of MPLS interfaces. Use the following command to view these statistics.

show router mpls interface statistics

The implicit null on ingress is not regarded as labeled traffic and octet counts include Layer 2 headers and trailers.

configure router mpls aux-stats

The sr command option refers to any type of MPLS-SR traffic (such as SR-OSPF, SR-ISIS, SR-TE). After being enabled and configured, auxiliary statistics can be viewed, monitored, and cleared. The two types of statistics (global or default MPLS statistics and auxiliary statistics) are independent; clearing one counter does not affect the values of the other counter.

For both types of statistics, implicit null on ingress is not regarded as labeled traffic and octet counts include Layer 2 headers and trailers.

Segment routing traffic statistics have a dependency with the ability to account for dark bandwidth in IGP‑TE advertisements.

The nature of MPLS allows for LSPs, owned by a specific protocol, to be tunneled into an LSP that is owned by another protocol. Typical examples of this capability are LDP over RSVP-TE, SR over RSVP-TE, and LDP over SR-TE. Also, in a variety of constructs (SR-TE LSPs, SR policies) SR OS uses hierarchical NHLFEs where a single (top) NHLFE that models the forwarding actions toward the next hop, can be referenced by one or more (inner) NHLFEs that model the forwarding actions for the rest of the end-to-end path.

SR OS enables collecting the traffic statistics from the majority of all supported types of tunnels. In cases where statistics collection is enabled on multiple labels of the stack, SR OS provides the capability to collect traffic statistics on two labels of the MPLS stack. Any label needs to be processed (as part of ILM or NHLFE processing) for statistics to be collected. For example, a node acting as an LSR for an RSVP-TE LSP (that transports an LDP LSP) can collect statistics for the RSVP-TE LSP but does not collect stats for the LDP LSP. A node acting as an LER for that same RSVP-TE LSP is, however, able to collect statistics for the LDP LSP.

configure system ip mpls label-stack-statistics-count

This command does not enable statistics collection. It only performs controls on a specific number of labels, and out of those that have statistics collection enabled, statistics collection is effectively performed.

If the MPLS label stack represents more than two stacked tunnels, the system collects statistics on the outermost (top) label for which statistics collection is enabled (if above value is 1 or 2), and collects statistics on the innermost (bottom) label for which statistics collection is enabled (if above value is 2).

For RSVP-TE and LDP, statistics are provided per forwarding class and as in-profile or out-of-profile. For all other labeled constructs, statistics are provided regardless of the forwarding class and the QoS profile. Altogether, labeled constructs share 128k statistic indexes (on ingress and on egress independently). Statistics with FC and QoS profile consume 16 indexes.

See RSVP-TE LSP statistics and P2MP RSVP-TE LSP statistics for information about RSVP-TE and MPLS-TP traffic statistics.

RSVP has been extended for MPLS to support automatic signaling of LSPs. To enhance the scalability, latency, and reliability of RSVP signaling, several extensions have been defined. Refresh messages are still transmitted but the volume of traffic, the amount of CPU utilization, and response latency are reduced while reliability is supported. None of these extensions result in backward compatibility problems with traditional RSVP implementations.

The Hello protocol detects the loss of a neighbor node or the reset of a neighbor’s RSVP state information. In standard RSVP, neighbor monitoring occurs as part of RSVP’s soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LSRs. 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 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.

When the following command is enabled on an RSVP interface, authentication of RSVP messages operates in both directions of the interface.

configure router rsvp interface authentication-key

A router maintains a security association using one authentication key for each interface to an RSVP neighbor.

An RSVP neighbor transmits an authenticating digest of the RSVP message that is computed using the shared authentication key and a keyed-hash algorithm. The message digest is included in an INTEGRITY object, which also contains a flags field, a key identifier field, and a sequence number field. An RSVP neighbor uses the key together with the authentication algorithm to process received RSVP messages. The RSVP MD5 authentication complies to the procedures for RSVP message generation in RFC 2747, RSVP Cryptographic Authentication.

When a Point of Local Repair (PLR) activates a bypass LSP toward a Merge Point (MP), by default, the INTEGRITY object corresponding to the bypass LSP interface is not added to a transmitted RSVP message except for packets of routed RSVP messages (Resv, Srefresh. and ACK) and only when the packet is intended for a bypass LSP endpoint (PLR or MP) that is a directly connected neighbor.

When the following command is enabled, the INTEGRITY object of the interface corresponding to the bypass LSP is added to a transmitted RSVP message whether the bypass LSP endpoint (PLR or MP) is a directly connected RSVP neighbor.

configure router rsvp authentication-over-bypass

The INTEGRITY object is included with the following RSVP messages: Path, PathTear, PathErr, Resv, ResvTear, ResvErr, Srefresh, and ACK.

In all cases, an RSVP message received from a PLR or an MP (sender address in the SenderTemplate or FilterSpec is different from an Extended Tunnel ID in a Session Object), and which includes the INTEGRITY object, is authenticated against the bypass LSP interface. An RSVP message received from a PLR or MP without the INTEGRITY object is also accepted.

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

The use of authentication mechanism is recommended to protect against malicious attack on the communications between routing protocol neighbors. These attacks could aim to either disrupt communications or to inject incorrect routing information into the systems routing table. The use of authentication keys can help to protect the routing protocols from these types of attacks.

Within RSVP, authentication must be explicitly configured through the use of the authentication keychain mechanism. This mechanism allows for the configuration of authentication keys and allows the keys to be changed without affecting the state of the protocol adjacencies.

To configure the use of an authentication keychain within RSVP, use the following steps:

1. Configure an authentication keychain under the following context. The configured keychain must include at least on valid key entry, using a valid authentication algorithm for the RSVP protocol.

   • MD-CLI

     configure system security keychains

   • classic CLI

     configure system security keychain

2. Use the following command to associate the configured authentication keychain with RSVP at the interface level of the CLI.

   • MD-CLI

     configure router rsvp interface authentication-keychain

   • classic CLI

     configure router rsvp interface auth-keychain

   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 in the key entry must be supported by the RSVP protocol.

   The RSVP protocol supports the following algorithms:

   • cleartext password

   • HMAC-MD5

   • HMC-SHA-1

   Error handling:

   • If a keychain exists but there are no active key entries with an authentication type that is valid for the associated protocol then inbound protocol packets are not authenticated and discarded, and no outbound protocol packets should be sent.

   • If keychain exists but the last key entry has expired, a log entry is raised indicating that all keychain entries have expired. The RSVP protocol requires that the protocol not revert to an unauthenticated state and requires that the old key is not to be used, therefore, when the last key has expired, all traffic is discarded.

When a flood of signaling messages arrive because of topology changes in the network, signaling messages can be dropped which results in longer set up times for LSPs. RSVP message pacing controls the transmission rate for RSVP messages, allowing the messages to be sent in timed intervals. Pacing reduces the number of dropped messages that can occur from bursts of signaling messages in large networks.

SR OS also provides traffic rate statistics. For RSVP-TE LSPs, including template-based LSPs and MPLS-TP LSPs, the user performs one of the following options to enable that capability:

• configures an accounting policy that uses the following command with the combined-mpls-lsp-egress record name

  configure log accounting-policy record

• assigns that accounting policy to a specific LSP (or template)
• enables stats collection

The frequency at which the rate is determined is defined using the collection-interval command in the accounting policy. The minimum interval is 5 minutes.

Rate statistics are provided in packets per second and Mb/s. Rate statistics are provided as an aggregate across all paths of the LSP, which have a statistical index assigned, and for all forwarding classes in or out‑of‑profile.

Rate statistics are only available on the egress of the ingress LER. At least two samples are needed to determine a rate.

At ingress LER, the configuration of the egress statistics is under the MPLS P2MP LSP context when carrying multicast packets over a RSVP P2MP LSP in the base routing instance. This is the same configuration as the one already supported with P2P RSVP LSP.

[ex:/configure router "Base" mpls]
A:admin@node-2# info
...
    lsp "test7" {
        type p2mp-rsvp
        egress-statistics {
            admin-state enable
            collect-stats true
            accounting-policy 99
        }
    }

A:node-2>config>router>mpls# info
----------------------------------------------
...           
            lsp "test7" p2mp-lsp
                shutdown
                egress-statistics
                    collect-stats
                    accounting-policy 99
                    no shutdown
                exit
            exit

[ex:/configure router "Base" mpls]
A:admin@node-2# info
...
    lsp-template "test8" {
        type p2mp-rsvp
        egress-statistics {
            collect-stats true
            accounting-policy 99
        }
    }

A:node-2>config>router>mpls# info
----------------------------------------------
...
            lsp-template "test8" p2mp
                shutdown
                egress-statistics
                    collect-stats
                    accounting-policy 99
                exit
            exit

When the ingress LER signals the path of the S2L sub-LSP, it includes the name of the LSP and that of the path 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.

1. P2MP LSP via user configuration for Layer 3 multicast in global routing instance: ‟LspNameFromConfig”

2. P2MP LSP as I-PMSI or S-PMSI in Layer 3 mVPN: templateName-SvcId-mTTmIndex

3. P2MP LSP as I-PMSI in VPLS/B-VPLS: templateName-SvcId-mTTmIndex

The ingress statistics configuration allows the user to match either on the exact name of the P2MP LSP as configured at the ingress LER or on a context which matches on the template name and the service ID as configured at the ingress LER.

[ex:/configure router "Base" mpls ingress-statistics]
A:admin@node-2# info
    lsp sender 192.0.0.2 lsp-name "test9" {
        admin-state enable
        collect-stats true
        accounting-policy 88
    }
    p2mp-template-lsp sender 192.0.0.2 rsvp-session-name "test9" {
        admin-state enable
        collect-stats true
        accounting-policy 88
        max-stats 1000
    }

A:node-2>config>router>mpls>ingr-stats# info
----------------------------------------------
                lsp "test9" sender 192.0.0.2
                    collect-stats
                    accounting-policy 88
                    no shutdown
                exit
                p2mp-template-lsp rsvp-session-name "test9" sender 192.0.0.2
                    collect-stats
                    accounting-policy 88
                    max-stats 1000
                    no shutdown
                exit
----------------------------------------------

When the Point-of-Local Repair (PLR) node activates the bypass LSP by sending a PATH message to refresh the path state of protected LSP at the Merge-Point (MP) node, it must use an IPv4 tunnel sender address in the sender template object that is different than the one used by the ingress LER in the PATH message. These are the procedures specified in RFC 4090 that are followed in the SR OS implementation.

The router uses the address of the outgoing interface of the bypass LSP as the IPv4 tunnel sender address in the sender template object. This address is different from the system interface address used in the sender template of the protected LSP by the ingress LER and so, there are no conflicts when the ingress LER acts as a PLR.

When the PLR is the ingress LER node and the outgoing interface of the bypass LSP is unnumbered, it is required that the user assigns to the interface a borrowed IP address that is different from the system interface. If not, the bypass LSP does not come up.

In addition, the PLR node includes the IPv4 RSVP_HOP object (C-Type=1) or the IF_ID RSVP_HOP object (C-Type=3) in the PATH message if the outgoing interface of the bypass LSP is numbered or unnumbered respectively.

When the MP node receives the PATH message over the bypass LSP, it creates the merge-point context for the protected LSP and associate it with the existing state if any of the following is satisfied:

• Change in C-Type of the RSVP_HOP object

• C-Type is IF_ID RSVP_HOP and did not change but IF_ID TLV is different

• Change in IPv4 Next or Previous Hop Address in RSVP_HOP object regardless of the C-Type value.

These procedures at the PLR and MP nodes are followed in both the link-protect and the node-protect FRR. If the MP node is running a pre-Release 11.0 implementation, it rejects the new IF_ID C-Type and drops the PATH over bypass. This results in the protected LSP state expiring at the MP node, which tears down the path. This is the case in general when node-protect FRR is enabled and the MP node does not support unnumbered RSVP interface.

The system may use MPLS-TP LSPs, and PWs, to transport point to point virtual leased line services. The router may play the role of a terminating PE or switching PE for VLLs. Epipe and Cpipe VLL services of type Epipe and Cpipe. The router may play the role of a switching PE.

MPLS-TP provider edge and gateway, VLL services illustrates the use of the system as a T-PE for services in an MPLS-TP domain, and as a S-PE for services between an MPLS-TP domain and an IP/MPLS domain. Static PWs with MPLS-TP identifiers, originating in the MPLS-TP network, are transported over static MPLS-TP LSPs. These either terminate on a local SAP on the system, or are switched to another PW segment across the IP/MPLS network. The PW segment in the IP/MPLS network may have static labels or be signaled using T-LDP.

MPLS-TP provider edge and gateway, spoke SDP termination on VPLS and MPLS-TP provider edge and gateway, spoke SDP termination on IES/VPRN illustrate the model for spoke SDP termination on VPLS, IES, and VPRN services, respectively. Similar to the VLL case, the static MPLS-TP PW may terminate on an interface belonging to the service on the router at the border between the MPLS‑TP and IP/MPLS networks, or be switched to another PW segment to be terminated on a remote PE.

SR OS supports the configuration of MPLS-TP tunnels, which comprise a working and, optionally, a protect LSP. In SR OS, a tunnel is referred to as an LSP, while an MPLS-TP LSP is referred to as a path. It is then possible to bind an MPLS-TP tunnel to an SDP.

MPLS-TP LSPs (that is, paths) with static labels are supported. MPLS-TP is not supported for signaled LSPs.

Both bidirectional associated (where the forward and reverse directions of a bidirectional LSP are associated at a specific LER, but may take different routes through the intervening network) and bidirectional co-routed (where the forward and reverse directions of the LSP are associated at each LSR, and take the same route through the network) are possible in MPLS-TP. However, only bidirectional co-routed LSPs are supported.

It is possible to configure MPLS-TP identifiers associated with the LSP, and MPLS-TP OAM command options on each LSP of a tunnel. MPLS-TP protection is configured for a tunnel at the level of the protect path level. Both protection and OAM configuration is managed via templates, to simplify provisioning for large numbers of tunnels.

The router may play the role of either an LER or an LSR.

MPLS-TP is supported on PWs with static labels. The provisioning model supports RFC 6370-style PW path identifiers for MPLS-TP PWs.

MPLS-TP PWs reuse the static PW provisioning model of previous SR OS releases. Including the use of the PW-switching key work to distinguish an S-PE. Therefore, the primary distinguishing feature for an MPLS-TP PW is the ability to configure MPLS-TP PW path identifiers, and to support MPLS-TP OAM and static PW status signaling.

The system can perform the role of a T-PE or an S-PE for a PW with MPLS-TP.

A spoke SDP with static PW labels and MPLS-TP identifiers and OAM capabilities can use an SDP that uses either an MPLS-TP tunnel, or that uses regular RSVP-TE LSPs. The control word is supported for all MPLS-TP PWs.

MPLS-TP requires that all OAM traffic be carried in-band on both directions of an LSP or PW. This is to ensure that OAM traffic always shares fate with user data traffic. This is achieved by using an associated control channel on an LSP or PW, similar to that used today on PWs. This creates a channel, which is used for OAM, protection switching protocols (for example, LSP linear protection switching coordination), and other maintenance traffic, and is known as the Generic Associated Channel (G-ACh).

RFC 5586 specifies mechanisms for implementing the G-ACh, relying on the combination of a reserved MPLS label, the Generic-ACH Label (GAL), as an alert mechanism (value equals 13) and Generic Associated Channel Header (G-ACH) for MPLS LSPs, and using the Generic Associated Channel Header, only, for MPLS PWs (although the GAL is allowed on PWs). The purpose of the GAL is to indicate that a G-ACH resides at the bottom of the label stack, and is only visible when the bottom non-reserved label is popped. The G-ACH channel type is used to indicate the packet type carried on the G-ACh. Packets on a G-ACh are targeted to a node containing a MEP by ensuring that the GAL is pushed immediately below the label that is popped at the MEP (for example, LSP endpoint or PW endpoint), so that it can be inspected as soon as the label is popped. A G-ACh packet is targeted to a node containing a MIP by setting the TTL of the LSP or PW label, as applicable, so that it expires at that node, in a similar manner to the SR OS implementation of VCCV for MS-PWs.

The system supports the G-ACh on static PWs and static LSPs.

This section details the MPLS-TP OAM mechanisms that are supported.

MPLS-TP introduces the ability to support a full range of OAM and protection and redundancy on PWs for which no dynamic T-LDP control plane exists. Static PW status signaling is used to advertise the status of a PW with statically configured labels by encapsulating the PW status TLV in a G-ACh on the PW. This mechanism enables OAM message mapping and PW redundancy for such PWs, as defined in RFC 6478. This mechanism is known as control channel status signaling in SR OS.

PW control channel status notifications use a similar model to T-LDP status signaling. That is, in general, status is always sent to the nearest neighbor T-PE or S-PE and relayed to the next segment by the S-PE. To achieve this, the PW label TTL is set to 1 for the G-ACh packet containing the status message.

Control channel status notifications are disabled by default on a spoke SDP. If they are enabled, then the default refresh interval is set to zero (although this value should be configurable in CLI). That is, when a status bit changes, three control channel status packets are sent consecutively at one-second intervals, and then the transmitter falls silent. If the refresh timer interval is non-zero, then status messages continue to be sent at that interval. The system supports the configuration of a refresh timer of 0, or from 10 to 65535 seconds. The recommended value is 600 seconds.

The system supports the optional acknowledgment of a PW control channel status message.

To constrain the CPU resources consumed processing control channel status messages, the system implements a credit-based mechanism. If a user enables control channel status on a PW[n], then a specific number of credits c_n are consumed from a CPM-wide pool of max_credit credits. The number of credits consumed is inversely proportional to the configured refresh timer (the first three messages at 1 second interval do not count against the credit). If the current_credit ≤ 0, then control channel status signaling cannot be configured on a PW (but the PW can still be configured and enabled).

If a PE with a non-zero refresh timer configured does not receive control channel status refresh messages for 3.5 time the specified timer value, then by default it times out and assume a PW status of zero.

A trap is generated if the refresh timer times out.

If PW redundancy is configured, the system always considers the literal value of the PW status; a time-out of the refresh timer does not impact the choice of the active transit object for the VLL service. The result of this is that if the refresh timer times-out, and a specified PW is currently the active PW, then the system does not fail-over to an alternative PW if the status is zero and some lower-layer OAM mechanism; for example, BFD has not brought down the LSP because of a connectivity defect. It is recommended that the PW refresh timer be configured with a much longer interval than any proactive OAM on the LSP tunnel, so that the tunnel can be brought down before the refresh timer expires if there is a CC defect.

A unidirectional continuity fault on a RSVP TE LSP may not result in the LSP being brought down before the received PW status refresh timer expires. Nokia recommends that either bidirectional static MPLS-TP LSPs with BFD CC, or additional protection mechanisms; for example, FRR be used on RSVP-TE LSPs carrying MPLS-TP PWs. This is particularly important in active and standby PW dual homing configurations, where the active and standby forwarding state or operational state of every PW in the redundancy set must be accurately reflected at the redundant PE side of the configuration.

A PW with a refresh timer value of zero is always treated as having not expired.

The system implements a hold-down timer for control-channel-status PW status bits to suppress bouncing of the status of a PW. For a specific spoke SDP, if the system receives 10 PW status change events in 10 seconds, the system holds down the spoke SDP on the local node with the last received non-zero PW-status bits for 20 seconds. It updates the local spoke with the most recently received PW status. This hold down timer is not persistent across disabled and enabled events.

The system implements an optional PW control channel status request mechanism. This enhances the existing control channel status mechanism so that a peer that has a "stale" PW status for the far end of a PW can request that the peer PE send a static PW status update. Accurate and current information about the far end status of a PW is important for correct operation of PW redundancy. This mechanism ensures a consistent view of the control plane is maintained, as far as possible, between peer nodes. It is not intended to act as a continuity check between peer nodes.

PW redundancy is supported for static MPLS-TP pseudowires. However, instead of using T-LDP status signaling to signal the forwarding state of a PW, control channel status signaling is used.

The following PW redundancy scenarios must be supported:

• MC-LAG and MC-APS with single and multisegment PWs interconnecting the PEs

• MS-PW (S-PE) redundancy between VLL PEs with single-homed CEs

• dual-homing of a VLL service into redundant IES or VPRN PEs, with active or standby PWs

• dual-homing of a VLL service into a VPLS with active/standby PWs

Active or standby dual-homing into routed VPLS is not supported in for MPLS-TP PWs. This is because it relies on PW label withdrawal of the standby PW to take down the VPLS instance, and therefore the associated IP interface. Instead, it is possible to enable BGP multihoming on a routed VPLS that has MPLS-TP PWs as spoke SDPs, and for the PW status of each spoke SDP to be driven (using control channel status) from the active or standby forwarding state assigned to each PW by BGP.

It is possible to configure inter-chassis backup (ICB) PWs as static MPLS-TP PWs with MPLS-TP identifiers. Only MPLS-TP PWs are supported in the same endpoint. That is, PWs in an endpoint must either be all MPLS-TP, or none of them must be MPLS-TP. This implies that an ICB used in an endpoint for which other PWs are MPLS TP must also be configured as an MPLS-TP PW.

A failover to a standby pseudowire is initiated based on the existing supported methods (for example, failure of the SDP).

On the 7750 SR and 7450 ESS, the MPLS-TP supports lock instruct and loopback for PWs, including the ability to:

• administratively lock a spoke SDP with MPLS-TP identifiers

• divert traffic to and from an external device connected to a SAP

• create a datapath loopback on the corresponding PW at a downstream S-PE or T-PE that was not originally bound to the spoke SDP being tested

• forward test traffic from an external test generator into an administratively locked PW, while simultaneously blocking the forwarding of user service traffic

MPLS-TP provides the ability to conduct test service throughput for PWs, through the configuration of a loopback on an administratively locked pseudowire. To conduct a service throughput test, an administrative lock is applied at each end of the PW. A test service that contains the SAP connected to the external device is used to inject test traffic into the PW. Lock request messaging is not supported.

A lock can be applied using the CLI or NMS. The forwarding state of the PW can be either active or standby.

After the PW is locked it can be put into loopback mode (for two way tests) so the ingress datapath in the forward direction is cross connected to the egress datapath in the reverse direction of the PW. The loopback can be configured through the CLI or NMS.

The PW loopback is created at the PW level, so everything under the PW label is looped back. This distinguishes a PW loopback from a service loopback, where only the native service packets are looped back.

The following MPLS-TP loopback configuration is supported:

• An MPLS-TP loopback can be created for an Epipe or Cpipe VLL.

• Test traffic can be inserted at an Epipe or Cpipe VLL endpoint or at an Epipe spoke-sdp termination on a VPLS interface.

For more information about configuring lock instruct and loopback for MPLS-TP Pseudowires see, the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide and the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide.

Linear 1-for-1 protection of MPLS-TP LSPs is supported, as defined in the RFC. This applies only to LSPs (not PWs).

This is supported edge-to-edge on an LSP, between two LERs, where normal traffic is transported either on the working LSP or on the protection LSP using a logical selector bridge at the source of the protected LSP.

At the sink LER of the protected LSP, the LSP that carries the normal traffic is selected, and that LSP becomes the working LSP. A protection switching coordination (PSC) protocol coordinates between the source and sink bridge, which LSP is used, as working path and protection path. The PSC protocol is always carried on a G-ACh on the protection LSP.

The system supports single-phased coordination between the LSP endpoints, in which the initiating LER performs the protection switchover to the alternate path and informs the far-end LER of the switch.

Bidirectional protection switching is achieved by the PSC protocol coordinating between the two end points to determine which of the two possible paths (that is the working or protect path), transmits user traffic at any specific time.

It is possible to configure non-revertive or revertive behavior. For non-revertive, the LSP does not switch back to the working path when the PSC switchover requests end, while for revertive configurations, the LSP always returns back to the working path when the switchover requests end.

The following figures illustrate the behavior of linear protection in more detail.

In normal condition, user data packets are sent on the working path on both directions, from A to Z and Z to A.

A defect in the direction of transmission from node Z to node A impacts the working connection Z-to-A, and initiates the detection of a defect at the node A.

The unidirectional PSC protocol initiates protection switching: the selector bridge at node A is switched to protection connection A-to-Z and the selector at node A switches to protection connection Z to-A. The PSC packet, sent from node A to node Z, requests a protection switch to node Z.

After node Z validates the priority of the protection switch request, the selector at node Z is switched to protection connection A-to-Z and the selector bridge at the node Z is switched to protection connection Z-to-A. The PSC packet, sent from node Z to node A, is used as acknowledge, informing node A about the switching.

If BFD CC or CC/CV OAM packets are used to detect defects on the working and protection paths, they are inserted on both working and protection paths. Packets are sent whether the path is selected as the currently active path. Linear protection switching is also triggered on receipt of an AIS with the LDI bit set.

The following commands are supported:

• Forced Switch

• Manual Switch

• Clear

The following actions must be performed to configure MPLS-TP LSPs or PWs.

configure router mpls mpls-tp transit-path

If a user disables MPLS, normally the entire MPLS configuration is deleted. However, in the case of MPLS‑TP a check that there is no other MPLS-TP configuration; for example, services or tunnels using MPLS-TP on the node, is performed.

In the classic CLI, use the following command to configure MPLS-TP.

configure router mpls mpls-tp

Administratively disabling MPLS-TP, therefore, brings down all MPLS-TP LSPs on the system.

The MPLS-TP context cannot be deleted if MPLS-TP LSPs or SDPs exist on the system.

In the classic CLI, the following example displays the configuration of the MPLS-TP identifiers.

A:node-2>config>router>mpls# info
----------------------------------------------
...
            mpls-tp
                global-id 500
                node-id 0.0.0.4
                no shutdown

configure router mpls mpls-tp

The SR OS reserves a range of labels for use by static LSPs and static pseudowires (VCs). That is, LSPs and pseudowires with no dynamic signaling of the label mapping. Use the following command to configure static labels for LSPs and pseudowires.

configure router mpls-labels static-label-range 

The static-label-range value indicates the maximum number of labels for the label type.

The minimum label value starts at 32 and expands all the way to the maximum number specified. The dynamic label range exists above the static label range. This prevents fragmentation of the label range.

In the classic CLI, the MPLS-TP tunnel ID range is configured as follows.

configure router mpls mpls-tp tp-tunnel-id-range

The tunnel ID range referred to here is a contiguous range of RSVP-TE tunnel IDs is reserved for use by MPLS TP, and these IDs map to the MPLS-TP tunnel numbers. There are some cases where the dynamic LSPs may have caused fragmentation to the number space such that contiguous range {max-min} is not available. In these cases, the command fails.

There is no default value for the tunnel ID range, and it must be configured to enable MPLS-TP.

If a configuration of the tunnel ID range fails, then the system gives a reason. This could be that the initially requested range, or the change to the allocated range, is not available that is tunnel IDs in that range have already been allocated by RSVP-TE. Allocated tunnel IDs are visible using a show command.

Changing the LSP or static VC label ranges does not require a reboot.

The static label ranges for LSPs, above, apply only to static LSPs configured using the CLI commands for MPLS-TP specified in this section. Different scalability constraints apply to static LSPs configured using the following CLI introduced in earlier SR OS releases.

configure router mpls static-lsp
configure router mpls interface label-map

The scalability applying to labels configured using this CLI is enforced as follows:

• A maximum of 1000 static LSP names may be configured with a PUSH operation.

• A maximum of 1000 LSPs with a POP or SWAP operation may be configured.

These two limits are independent of one another, giving a combined limit of 1000 PUSH and 1000 POP and SAP operations configured on a node.

The static LSP and VC label spaces are contiguous. Therefore, the dimensioning of these label spaces requires careful planning by a user as increasing the static LSP label space impacts the start of the static VC label space, which may already-deployed.

It is possible for MPLS-TP paths to use both numbered IP numbered interfaces that use ARP and static ARP, or IP unnumbered interfaces. MPLS-TP requires no changes to these interfaces. It is also possible to use a new type of interface that does not require any IP addressing or next-hop resolution.

RFC 7213 provides guidelines for the usage of various Layer 2 next-hop resolution mechanisms with MPLS-TP. If protocols such as ARP are supported, then they should be used. However, in the case where no dynamic next hop resolution protocol is used, it should be possible to configure a unicast, multicast or broadcast next-hop MAC address. The rationale is to minimize the amount of configuration required for upstream nodes when downstream interfaces are changes. A default multicast MAC address for use by MPLS-TP point-to-point LSPs has been assigned by IANA (Value: 01-00-5e-90-00-00). This value is configurable on the router to support interoperability with third-party implementations that do not default to this value, and this no default value is implemented on the router.

To support these requirements, an interface type, known as an unnumbered MPLS-TP interface allows a broadcast or multicast destination MAC address to be configured.

[ex:/configure router "Base" interface "test"]
A:admin@node-2# info
    admin-state enable
    flavor unnumbered-mpls-tp
    port 2/1/1:10
    mac 04:0a:01:01:00:01
    ipv4 {
        neighbor-discovery {
            static-neighbor-unnumbered {
                mac-address 01:00:5e:90:10:00
            }
        }
    }

A:node-2>config>router>if# info
----------------------------------------------
            port 2/1/1:10
            mac 04:0a:01:01:00:01
            static-arp unnumbered 01:00:5e:90:10:00
            no shutdown
----------------------------------------------

A:node-2>config>router>mpls>if$ info detail
----------------------------------------------
                mpls-tp-mep
                    if-num 100
                    if-num-validation enable
                    ais-enable
                exit
...
----------------------------------------------

Use the following commands in the following contexts to configure forward and reverse directions of the MPLS-TP LSP path at a transit LSR.

configure router mpls mpls-tp transit-path forward-path
configure router mpls mpls-tp transit-path path-id 
configure router mpls mpls-tp transit-path reverse-path

In the transit-path path-id context, the src-tunnel-num and dest-tunnel-num command options are consistent with the source and destination of a label mapping message for a signaled LSP.

If the dest-tunnel-num command option is not configured, the dest-tunnel-num value is assumed to be the same as the src-tunnel-num value.

If any of the global ID values are not entered, the value is assumed to be 0.

If the src-global-id value is entered, but the dest-global-id value is not configured, the dest-global-id value is the same as the src-global-id value.

The transit-path path-id lsp-num must match the value configured in the LER for a specified path. If no explicit lsp-num is configured, then working-path or protect-path must be specified (equating to 1 or 2 in the system).

The forward path must be configured before the reverse path. The configuration of the reverse path is optional.

The LSP ID (the path-id) options apply to the downstream direction of the forward LSP path, and are used to populate the MIP ID for the path at this LSR.

The reverse path configuration must be deleted before the forward path.

The forward-path (and reverse-path if applicable) command options can be configured with or without the path ID, but they must be configured if MPLS-TP OAM is to be able to identify the LSR MIP.

The transit-path can be enabled (as long as the forward-path or reverse-path options have been configured properly) with or without identifiers.

The path-id path-name must be unique on the node. There is a one to one mapping between a specified path name and path ID.

Traffic cannot pass through the transit path if the transit path is disabled.

The user enables the signaling of the primary LSP path admin-group constraints in the FRR object at the ingress LER with the following CLI command:

config>router>mpls>lsp>fast-reroute>propagate-admin-group

When this command is enabled at the ingress LER, the admin-group constraints configured in the context of the P2P LSP primary path, or the ones configured in the context of the LSP and inherited by the primary path, are copied into the FAST_REROUTE object. The admin-group constraints are copied into the include-any or exclude-any fields.

The ingress LER propagates these constraints to the downstream nodes during the signaling of the LSP to allow them to include the admin-group constraints in the selection of the FRR backup LSP for protecting the LSP primary path.

The ingress LER inserts the FAST_REROUTE object by default in a primary LSP path message. If the user disables the object using the following command, the admin-group constraints are not propagated: config>router>mpls>no frr-object.

The same admin-group constraints can be copied into the Session Attribute object. They are intended for the use of an LSR, typically an ABR, to expand the ERO of an inter-area LSP path. They are also used by any LSR node in the path of a CSPF or non-CSPF LSP to check the admin-group constraints against the ERO regardless if the hop is strict or loose. These are governed strictly by the command:

config>router>mpls>lsp>propagate-admin-group

In other words, the user may decide to copy the primary path admin-group constraints into the FAST_REROUTE object only, or into the Session Attribute object only, or into both.

The PLR rules for processing the admin-group constraints can make use of either of the two object admin-group constraints.

The user enables the use of the admin-group constraints in the association of a manual or dynamic bypass LSP with the primary LSP path at a Point-of-Local Repair (PLR) node using the following global command:

config>router>mpls>admin-group-frr

When this command is enabled, each PLR node reads the admin-group constraints in the FAST_REROUTE object in the Path message of the LSP primary path. If the FAST_REROUTE object is not included in the Path message, then the PLR reads the admin-group constraints from the Session Attribute object in the Path message.

If the PLR is also the ingress LER for the LSP primary path, then it just uses the admin-group constraint from the LSP or path level configurations.

Whether the PLR node is also the ingress LER or just an LSR for the protected LSP primary path, the outcome of the ingress LER configuration dictates the behavior of the PLR node and is summarized in Bypass LSP admin-group constraint behavior.

The PLR node then uses the admin-group constraints along with other constraints, such as hop-limit and SRLG, to select a manual or dynamic bypass among those that are already in use.

If none of the manual or dynamic bypass LSP satisfies the admin-group constraints or the other constraints, the PLR node requests CSPF for a path that merges the closest to the protected link or node and that includes or excludes the specified admin-group IDs.

If the user changes the configuration of the above command, there is no effect on existing bypass associations. The change only applies to new attempts to find a valid bypass.

This feature enhances procedures of the timer and manual resignal (both delay and lsp options) of the RSVP-TE bypass LSP path by updating the SRLG information of the links of the current path and checking for SRLG disjointness constraint. The following sequence describes the timer and manual resignal enhancements:

1. CSPF updates the SRLG membership of the current bypass LSP path and checks if the path violates the SRLG constraint of the first primary path that was associated with a PLR of this bypass LSP. This is referred to as the initial Path State Block (initial PSB).

2. CSPF attempts a new path computation for the bypass LSP using the initial PSB constraints.

3. MPLS uses the information returned by CSPF and determines if the new bypass path is more optimal.

   1. If SRLG FRR strict disjointness is configured (configure>router>mpls>srlg-frr strict) and CSPF indicates the updated SRLG information of current path violated the SRLG constraint of the PLR of the initial PSB, the new path is more optimal.

   2. Otherwise, MPLS performs additional checks using the PLR of the initial PSB to determine if the new path is more optimal. Determination of bypass LSP path optimality summarizes the possible cases of bypass path optimality determination.

   Table 9. Determination of bypass LSP path optimality

   PLR SRLG constraint check1		SRLG FRR configuration (strict/loose)	Path cumulative cost comparison1	Path cumulative SRLG weight comparison1	More optimal path
   Current path	New path
   Disjoint	Disjoint	—	New Cost < Current Cost	—	New
   Disjoint	Disjoint	—	New Cost ≥ Current Cost	—	Current
   Disjoint	Not Disjoint	—	—	—	Current
   Not Disjoint	Not Disjoint	—	—	—	New
   Not Disjoint	Not Disjoint	Strict	—	—	Current
   Not Disjoint	Not Disjoint	Loose	New Cost < Current Cost	—	New
   Not Disjoint	Not Disjoint	Loose	New Cost > Current Cost	—	Current
   Not Disjoint	Not Disjoint	Loose	New Cost = Current Cost	New SRLG Weight < Current SRLG Weight	New
   Not Disjoint	Not Disjoint	Loose	New Cost = Current Cost	New SRLG Weight ≥ Current SRLG Weight	Current

   ¹ This check of the current path makes use of the updated SRLG and cost information provided by CSPF.

4. If the path returned by CSPF is found to be a more optimal bypass path with respect to the PLR of the initial PSB, the following sequence of actions is taken:

   1. MPLS signals and programs the new path.

   2. MPLS moves to the new bypass path the PSB associations of all PLRs which evaluation against Determination of bypass LSP path optimality results in the new bypass path being more optimal.

   3. Among the remaining PLRs, MPLS does one of the following:

      • If the updated SRLG information of the current bypass path changed and SRLG FRR loose disjointness is configured (configure>router>mpls>srlg-frr), MPLS keeps this PLR PSB association with the current bypass path.

      • If the updated SRLG information of the current bypass path changed and SRLG strict disjointness is configured (configure>router>mpls>srlg-frr strict), MPLS evaluates the SRLG constraint of each PLR and performs the following actions:

        • MPLS keeps with the current bypass path the PSB associations of all PLRs where the SRLG constraint is not violated by the updated SRLG information of the current bypass path.

          These PSBs are re-evaluated at the next timer or manual resignal MBB following the same procedure, as described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.

        • MPLS detaches from current bypass path the PSB associations of all PLRs where the SRLG constraint is violated by the updated SRLG information of the current bypass path.

          These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis and following the same procedure, as described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.

5. If the path returned by CSPF is found to be less optimal then the current bypass path or if CSPF did not return a new path, the following actions are performed:

   • If the updated SRLG information of the current bypass path did not change, MPLS keeps the current bypass path and the PSB associations of all PLRs.

   • If the updated SRLG information of the current bypass path changed and SRLG FRR loose disjointness is configured (configure>router>mpls>srlg-frr), MPLS keeps the current bypass path and the PSB associations of all PLRs.

   • If the updated SRLG information of the current bypass path changed and SRLG strict disjointness is configured (configure>router>mpls>srlg-frr strict), MPLS evaluates the SRLG constraint of each PLR and performs the following actions:

     • MPLS keeps with the current bypass path the PSB associations of all PLRs where the SRLG constraint is not violated by the updated SRLG information of the current bypass path.

       These PSBs are re-evaluated at the next timer or manual resignal MBB following the same procedure, as described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.

     • MPLS detaches from current bypass path the PSB associations of all PLRs where the SRLG constraint is violated by the updated SRLG information of the current bypass path.

       These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis and following the same procedure, as described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.

This feature enhances procedures of the timer and manual resignal (both delay and lsp options) of a RSVP-TE bypass LSP path by updating the administrative group information of the current path links and checking for administrative group constraints. The following sequence describes the timer and manual resignal enhancements:

1. CSPF updates the administrative group membership of the current bypass LSP path and checks if the path violates the administrative group constraints of the first primary path which was associated with this bypass LSP. This is referred to as the initial PSB.

2. CSPF attempts a new path computation for the bypass LSP using the PLR constraints of the initial PSB.

3. MPLS uses the information returned by CSPF and determines if the new bypass path is more optimal.

   1. If CSPF indicated the updated administrative group information of current path violated the administrative group constraint of the initial PSB, then the new path is more optimal.

   2. Otherwise, the new path is more optimal only if its metric is lower than the updated metric of the current bypass path.

4. If the path returned by CSPF is found to be a more optimal bypass path, MPLS signals and programs the new path. Because the administrative group constraint is not part of the PLR definition, MPLS evaluates the PSBs of all PLRs associated with the current bypass, and takes the following actions:

   1. MPLS moves to the new bypass path the PSB associations in which the administrative group constraints are not violated by the new bypass path.

   2. Among the remaining PSBs, MPLS does the following:

      • MPLS keeps with the current bypass path the PSB associations in which the administrative group constraints are not violated by the updated administrative group information of the current bypass path.

        These PSBs are re-evaluated at the next timer or manual resignal MBB following the same procedure, as described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.

      • MPLS detaches from current bypass path the PSB associations in which the administrative group constraints are violated by the updated administrative group information of the current bypass path.

        These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis and following the same procedure, as described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.

5. If the path returned by CSPF is found to be less optimal than the current bypass path or if CSPF did not return a new path, the following actions are performed:

   • If the updated administrative group information of the current bypass path did not change, MPLS keeps the current bypass path and all PSB associations.

   • If the updated administrative group information of the current bypass path has changed, MPLS evaluates the PSBs of all PLRs associated with the current bypass, and performs the following actions:

     • MPLS keeps with the current bypass path the PSB associations in which the administrative group constraints are not violated by the updated administrative group information of the current bypass path.

     • MPLS detaches from current bypass path the PSB associations in which the administrative group constraints are violated by the updated administrative group information of the current bypass path.

       These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis and following the same procedure, as described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.

An LER allows the operator to map traffic to a DiffServ LSP using one of the following methods:

• explicit RSVP SDP configuration of a VLL, VPLS, or VPRN service

• class-based forwarding in an RSVP SDP. The operator can enable the checking by RSVP that a Forwarding Class (FC) mapping to an LSP under the SDP configuration is compatible with the DiffServ Class Type (CT) configuration for this LSP.

• the auto-bind-tunnel RSVP-TE option in a VPRN service

• static routes with indirect next-hop being an RSVP LSP name

There are a couple of admission control decisions made when an LSP with a specified bandwidth is to be signaled. The first is in the head-end node. CSPF only considers network links that have sufficient bandwidth. Link bandwidth information is provided by IGP TE advertisement by all nodes in that network.

Another decision made is local CAC and is performed when the RESV message for the LSP path is received in the reverse direction by a SR OS in that path. The bandwidth value selected by the egress LER is checked against link bandwidth, otherwise the reservation is rejected. If accepted, the new value for the remaining link bandwidth is advertised by IGP at the next advertisement event.

Both of these admission decisions are enhanced to be performed at the TE class level when DiffServ TE is enabled. In other words, CSPF in the head-end node must check the LSP bandwidth against the ‛unreserved bandwidth’ advertised for all links in the path of the LSP for that TE class which consists of a combination of a CT and a priority. Same for the admission control at SR OS receiving the Resv message.

RSVP uses the Class Type object to carry LSP class-type information during path setup. Eight values are supported for class-types 0 through 7 as per RFC 4124. Class type 0 is the default class that is supported today on the router.

One or more forwarding classes map to a DiffServ class type trough a system level configuration.

IGP extensions are defined in RFC 4124. DiffServ TE advertises link available bandwidth, referred to as unreserved bandwidth, by OSPF TE or IS-IS TE on a per TE class basis. A TE class is a combination of a class type and an LSP priority. To reduce the amount of per TE class flooding required in the network, the number of TE classes is set to eight. This means that eight class types can be supported with a single priority or four class types with two priorities, and so on. In that case, the operator configures the wanted class type on the LSP such that RSVP-TE can signal it in the class-type object in the path message.

IGP continues to advertise the existing Maximum Reservable Link Bandwidth TE parameter to mean the maximum bandwidth that can be booked on a specified interface by all classes. The value advertised is adjusted with the link subscription factor.

This feature behaves according to the following rules:

• When an LSP primary path retries because of a failure, for example, it fails after being in the up state, or undergoes any type of MBB, MPLS retries a new path for the LSP using the main CT. If the first attempt failed, the head-end node performs subsequent retries using the backup CT. This procedure must be followed regardless if the currently used CT by this path is the main or backup CT. This applies to both CSPF and non-CSPF LSPs.

• The triggers for using the backup CT after the first retry attempt are:

  • A local interface failure or a control plane failure (hello timeout, and so on).

  • Receipt of a PathErr message with a notification of a FRR protection becoming active downstream or receipt, or both, of a Resv message with a ‛Local-Protection-In-Use’ flag set. This invokes the FRR Global Revertive MBB.

  • Receipt of a PathErr message with error code=25 (Notify) and sub-code=7 (Local link maintenance required) or a sub-code=8 (Local node maintenance required). This invokes the TE Graceful Shutdown MBB. Note that in this case, only a single attempt is performed by MBB as in current implementation; only the main CT is retried.

  • Receipt of a Resv refresh message with the ‛Preemption pending’ flag set or a PathErr message with error code=34 (Reroute) and a value=1 (Reroute request soft preemption). This invokes the soft preemption MBB.

  • Receipt of a ResvTear message.

  • A configuration change MBB.

• When an unmapped LSP primary path goes into retry, it uses the main CT until the number of retries reaches the value of the new main-ct-retry-limit parameter. If the path did not come up, it must start using the backup CT at that point in time. By default, this parameter is set to infinite value. The new main-ct-retry-limit parameter has no effect on an LSP primary path, which retries because of a failure event. This parameter is configured using the main-ct-retry-limit command in the config>router>mpls>lsp context. If the user entered a value of the main-ct-retry-limit parameter that is greater than the LSP retry-limit, the number of retries still stops when the LSP primary path reaches the value of the LSP retry-limit. In other words, the meaning of the LSP retry-limit parameter is not changed and always represents the upper bound on the number of retries. The unmapped LSP primary path behavior applies to both CSPF and non-CSPF LSPs.

• An unmapped LSP primary path is a path that never received a Resv in response to the first path message sent. This can occur when performing a ‟shut/no-shut” on the LSP or LSP primary path or when the node reboots. An unmapped LSP primary path goes into retry if the retry timer expired or the head-end node received a PathErr message before the retry timer expired.

• When the clear>router>mpls>lsp command is executed, the retry behavior for this LSP is the same as in the case of an unmapped LSP.

• If the value of the parameter main-ct-retry-limit is changed, the new value is only used at the next time the LSP path is put into a ‟no-shut” state.

• The following is the behavior when the user changes the main or backup CT:

  • If the user changes the LSP level CT, all paths of the LSP are torn down and resignaled in a break-before-make fashion. Specifically, the LSP primary path is torn down and resignaled even if it is currently using the backup CT.

  • If the user changes the main CT of the LSP primary path, the path is torn down and resignaled even if it is currently using the backup CT.

  • If the user changes the backup CT of an LSP primary path when the backup CT is in use, the path is torn down and is resignaled.

  • If the user changes the backup CT of an LSP primary path when the backup CT is not in use, no action is taken. If however, the path was in global Revertive, gshut, or soft preemption MBB, the MBB is restarted. This actually means the first attempt is with the main CT and subsequent ones, if any, with the new value of the backup CT.

  • Consider the following priority of the various MBB types from highest to lowest: Delayed Retry, Preemption, Global Revertive, Configuration Change, and TE Graceful Shutdown. If an MBB request occurs while a higher priority MBB is in progress, the latter MBB is restarted. This actually means the first attempt is with the main CT and subsequent ones, if any, with the new value of the backup CT.

• If the least-fill option is enabled at the LSP level, then CSPF must use least-fill equal cost path selection when the main or backup CT is used on the primary path.

• When the resignal timer expires, CSPF tries to find a path with the main CT. The head-end node must resignal the LSP even if the new path found by CSPF is identical to the existing one because the idea is to restore the main CT for the primary path. If a path with main CT is not found, the LSP remains on its current primary path using the backup CT. This means that the LSP primary path with the backup CT may no longer be the most optimal one. Furthermore, if the least-fill option was enabled at the LSP level, CSPF does not check if there is a more optimal path, with the backup CT, according to the least-fill criterion and, so, does not raise a trap to indicate the LSP path is eligible for least-fill re-optimization.

• When the user performs a manual resignal of the primary path, CSPF tries to find a path with the main CT. The head-end node must resignal the LSP as in current implementation.

• If a CPM switchover occurs while an the LSP primary path was in retry using the main or backup CT, for example, was still in operationally down state, the path retry is restarted with the main CT until it comes up. This is because the LSP path retry count is not synchronized between the active and standby CPMs until the path becomes up.

• When the user configured secondary standby and non-standby paths on the same LSP, the switchover behavior between primary and secondary is the same as in existing implementation.

This feature is not supported on a P2MP LSP.

To allow different levels of booking of network links under normal operating conditions and under failure conditions, it is necessary to allow sharing of bandwidth across class types.

This feature introduces the Russian-Doll Model (RDM) DiffServ TE admission control policy described in RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. This mode is enabled using the following command: config>router>rsvp>diffserv-te rdm.

The Russian Doll Model (RDM) LSP admission control policy allows bandwidth sharing across Class Types (CTs). It provides a hierarchical model by which the reserved bandwidth of a CT is the sum of the reserved bandwidths of the numerically equal and higher CTs. RDM admission control policy example shows an example.

CT2 has a bandwidth constraint BC2 which represents a percentage of the maximum reservable link bandwidth. Both CT2 and CT1 can share BC1 which is the sum of the percentage of the maximum reservable bandwidth values configured for CT2 and CT1 respectively. Finally, CT2, CT1, and CT0 together can share BC0 which is the sum of the percentage of the maximum reservable bandwidth values configured for CT2, CT1, and CT0 respectively. The maximum value for BC0 is of course the maximum reservable link bandwidth.

What this means in practice is that CT0 LSPs can use up to BC0 in the absence of LSPs in CT1 and CT2. When this occurs and a CT2 LSP with a reservation less than or equal to BC2 requests admission, it is only admitted by preempting one or more CT0 LSPs of lower holding priority than this LSP setup priority. Otherwise, the reservation request for the CT2 LSP is rejected.

It is required that multiple paths of the same LSP share common link bandwidth because they are signaled using the Shared Explicit (SE) style. Specifically, two instances of a primary path, one with the main CT and the other with the backup CT, must temporarily share bandwidth while MBB is in progress. Also, a primary path and one or many secondary paths of the same LSP must share bandwidth whether they are configured with the same or different CTs.

Consider a link configured with two class types CT0 and CT1 and making use of the RDM admission control model as shown in Sharing bandwidth when an LSP primary path is downgraded to backup CT.

Consider an LSP path Z occupying bandwidth B at CT1. BC0 being the sum of all CTs below it, the bandwidth occupied in CT1 is guaranteed to be available in CT0. When new path X of the same LSP for CT0 is setup, it uses the same bandwidth B as used by path Z as shown in Sharing bandwidth when an LSP primary path is downgraded to backup CT (a). When path Z is torn down the same bandwidth now occupies CT0 as shown in Sharing bandwidth when an LSP primary path is downgraded to backup CT (b). Even if there were no new BW available in CT0 as can be seen in Sharing bandwidth when an LSP primary path is downgraded to backup CT (c), path X can always share the bandwidth with path Z.

CSPF at the head-end node and CAC at the transit LSR node shares bandwidth of an existing path when its CT is downgraded in the new path of the same LSP.

When upgrading the CT the following issue can be apparent. Assume an LSP path X exists with CT0. An attempt is made to upgrade this path to a new path Z with CT1 using an MBB.

In Sharing bandwidth when an LSP primary path is upgraded to main CT (a), if the path X occupies the bandwidth as shown it cannot share the bandwidth with the new path Z being setup. If a condition exists, as shown in Sharing bandwidth when an LSP primary path is upgraded to main CT, (b) the path Z can never be setup on this particular link.

Consider Sharing bandwidth when an LSP primary path is upgraded to main CT (c). The CT0 has a region that overlaps with CT1 as CT0 has incursion into CT1. This overlap can be shared. However, to find whether such an incursion has occurred and how large the region is, it is required to know the reserved bandwidths in each class. Currently, IGP-TE advertises only the unreserved bandwidths. Hence, it is not possible to compute these overlap regions at the head end during CSPF. Moreover, the head end needs to then try and mimic each of the traversed links exactly which increases the complexity.

CSPF at the head-end node only attempts to signal the LSP path with an upgraded CT if the advertised bandwidth for that CT can accommodate the bandwidth. In other words, it assumes that in the worst case this path does not share bandwidth with another path of the same LSP using a lower CT.

The following CLI objects enable the resolution over IGP IPv4 shortcuts of IPv4 and IPv6 prefixes within an ISIS instance, of IPv6 prefixes within an OSPFv3 instance, and of IPv4 prefixes within an OSPFv2 instance.

A:Reno 194# configure router isis
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv4, ipv6}
                             resolution {any|disabled|filter|match-family-ip}
                             resolution-filter
                                   [no] rsvp
                                   exit
                              exit
                      exit
                 exit

A:Reno 194# configure router ospf
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv4}
                             resolution {any|disabled|filter|match-family-ip}
                             resolution-filter
                                   [no] rsvp
                                   exit
                              exit
                      exit
                 exit

A:Reno 194# configure router ospf3# 
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv6}
                             resolution {any|disabled|filter}
                             resolution-filter
                                   [no] rsvp
                                   exit
                              exit
                      exit
                 exit

The new resolution node igp-shortcut is introduced to provide flexibility in the selection of the IP next hops or the tunnel types for each of the IPv4 and IPv6 prefix families.

When the IPv4 family option is enabled, the IS-IS or OSPF SPF includes the IPv4 IGP shortcuts in the IP reach calculation of IPv4 nodes and prefixes. RSVP-TE LSPs terminating on a node identified by its router ID can be used to reach IPv4 prefixes owned by this node or for which this node is the IPv4 next hop.

When the IPv6 family option is enabled, the IS-IS or OSPFv3 SPF includes the IPv4 IGP shortcuts in the IP reach calculation of IPv6 nodes and prefixes. RSVP-TE LSPs terminating on a node identified by its router ID can be used to reach IPv6 prefixes owned by this node or for which this node is the IPv6 next hop. The IPv6 option is supported in both ISIS MT=0 and MT=2.

The IS-IS or OSPFv3 IPv6 routes resolved to IPv4 IGP shortcuts are used to forward packets of IS-IS or OSPFv3 prefixes matching these routes but are also used to resolve the BGP next hop of BGP IPv6 prefixes, resolve the indirect next hop of static IPv6 routes, and forward CPM-originated IPv6 packets.

In the datapath, a packet for an IPv6 prefix contains a label stack that consists of the IPv6 Explicit-Null label value of 2 at the bottom of the label stack followed by the label of the IPv4 RSVP-TE LSP.

The following commands control the use of an RSVP-TE LSP in IGP shortcuts:

• config>router>mpls>lsp# [no] igp-shortcut lfa-protect | lfa-only]

• config>router>mpls>lsp# igp-shortcut relative-metric offset

An LSP can be excluded from being used as an IGP shortcut for forwarding IPv4 and IPv6 prefixes, or the LSP in the LFA SPF can be used to protect the primary IP next hop of an IPv4 or IPv6 prefix. For tunneling LDP FECs over IGP shortcuts, the user must enable the tunneling option on the T-LDP sessions to the destinations of the RSVP-TE LSPs used as IGP shortcuts.

The configuration value of sr-te is added to the resolution-filter context of the igp-shortcut construct. When enabled, this value allows IGP to resolve IPv4 prefixes, IPv6 prefixes, and LDP IPv4 prefix FECs over SR-TE LSPs used as IGP shortcuts.

In addition, the value of any in the resolution-filter context allows the user to resolve IP prefixes and LDP FECs to either RSVP-TE or SR-TE LSPs used as IGP shortcuts.

A:Reno 194# configure router isis
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv4, ipv6}
                             resolution {any|disabled|filter|match-family-ip}
                             resolution-filter
                                   [no] rsvp
                                   [no] sr-te
                                   exit
                             exit
                      exit
                 exit

A:Reno 194# configure router ospf
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv4}
                             resolution {any|disabled|filter|match-family-ip}
                             resolution-filter
                                   [no] rsvp
                                   [no] sr-te
                                   exit
                             exit
                      exit
                 exit

A:Reno 194# configure router ospf3
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {ipv6}
                             resolution {any|disabled|filter}
                             resolution-filter
                                   [no] rsvp
                                   [no] sr-te
                                   exit
                             exit
                      exit
                 exit

For tunneling LDP FECs over IGP shortcuts, the user must enable the tunneling option on the T-LDP sessions to the destinations of the SR-TE LSPs used as IGP shortcuts. See Family prefix resolution and tunnel selection rules for an explanation of the rules for the resolution of IPv4 prefixes, IPv6 prefixes, and LDP FECs, and for the selection of the tunnel types on a per family basis.

Two prefix family values of srv4 and srv6 are added to the igp-shortcut construct.

When enabled, the srv4 value allows IGP to resolve SR-ISIS IPv4 tunnels in MT=0 or SR-OSPF IPv4 tunnels over RSVP-TE LSPs used as IGP shortcuts.

When enabled, the srv6 value allows IGP to resolve SR-ISIS IPv6 tunnels in MT=0 over RSVP-TE LSPs used as IGP shortcuts.

A:Reno 194# configure router isis
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {srv4, srv6}
                             resolution {disabled | match-family-ip}
                             exit
                      exit
                 exit

A:Reno 194# configure router ospf
           igp-shortcut
                 [no] shutdown
                 tunnel-next-hop
                      family {srv4}
                             resolution {disabled | match-family-ip}
                             exit
                      exit
                 exit

See Family prefix resolution and tunnel selection rules for applicable rules for the resolution of SR-ISIS IPv4 tunnels, SR-ISIS IPv6 tunnels, and SR-OSPF IPV4 tunnels, and the selection of tunnel types on a per-family basis.

By default, the absolute metric of the LSP is used to compute the contribution of an IGP shortcut to the total cost of a prefix or a node after the SPF is complete. The absolute metric is the operational metric of the LSP populated by MPLS in the TTM. This corresponds to the cumulative IGP-metric of the LSP path returned by CSPF or the static administrative metric value of the LSP if the user configured one using the config>router>mpls>lsp>metric command. Note that MPLS populates the TTM with the maximum metric value of 16777215 in the case of a CSPF LSP using the TE-metric and a non-CSPF LSP with a loose or strict hop in the path. A non-CSPF LSP with an empty hop in the path definition returns the IGP cost for the destination of the LSP.

The user enables the use of the relative metric for an IGP shortcut with the following CLI command:

config>router>mpls>lsp>igp-shortcut relative-metric [offset]

IGP applies the shortest IGP cost between the endpoints of the LSP plus the value of the offset, instead of the LSP operational metric, when computing the cost of a prefix that is resolved to the LSP.

The offset value is optional and it defaults to zero. An offset value of zero is used when the relative-metric option is enabled without specifying the offset parameter value.

The minimum net cost for a prefix is capped to the value of one (1) after applying the offset:

Note that the TTM continues to show the LSP operational metric as provided by MPLS, which allows applications such as LDP-over-RSVP (when IGP shortcut is disabled) and BGP and static route shortcuts to continue to use the LSP operational metric.

The relative-metric option, lfa-protect, and the lfa-only options are mutually exclusive. That is, an LSP with the relative-metric option enabled cannot be included in the LFA SPF and the other way around when the igp-shortcut option is enabled in the IGP.

Finally, it should be noted that the relative-metric option is ignored when forwarding adjacency is enabled in IS-IS or OSPF by configuring the advertise-tunnel-link option. In this case, IGP advertises the LSP as a point-to-point unnumbered link along with the LSP operational metric capped to the maximum link metric allowed in that IGP.

When ECMP is enabled on the system and multiple equal-cost paths exist for a prefix, the following selection criteria are used to select the set of next hops to program in the datapath:

• for a destination = tunnel-endpoint (including external prefixes with tunnel-endpoint as the next hop), select tunnel with lowest tunnel-index (ip next hop is never used in this case).

• for a destination != tunnel-endpoint:

  • exclude LSPs with metric higher than underlying IGP cost between the endpoint of the LSP

  • prefer tunnel next hop over ip next hop

  • within tunnel next hops:

    • select lowest endpoint to destination cost

    • if same endpoint to destination cost, select lowest endpoint node router-id

    • if same router-id, select lowest tunnel-index

  • within ip next hops:

    • select lowest downstream router-id

    • if same downstream router-id, select lowest interface-index

• Although no ECMP is performed across both the IP and tunnel next hops, the tunnel endpoint lies in one of the shortest IGP paths for that prefix. As a result, the tunnel next hop is always selected as long as the prefix cost using the tunnel is equal or lower than the IGP cost.

The ingress IOM sprays the packets for a prefix over the set of tunnel next hops and IP next hops based on the hashing routine currently supported for IPv4 packets.

All control plane packets that require an RTM lookup and whose destination is reachable over the RSVP shortcut are forwarded over the shortcut. This is because RTM keeps a single route entry for each prefix unless there is ECMP over different outgoing interfaces.

Interface bound control packets are not impacted by the RSVP shortcut because RSVP LSPs with a destination address different than the router-id are not included by IGP in its SPF calculation.

The forwarding adjacency feature can be enabled independently from the IGP shortcut feature in CLI. Use the following commands to enable forwarding adjacency in IS-IS or OSPF:

• config>router>isis>advertise-tunnel-link

• config>router>ospf>advertise-tunnel-link

If both igp-shortcut and advertise-tunnel-link options are enabled for a specific IGP instance, the advertise-tunnel-link wins. With this feature, ISIS or OSPF advertises an RSVP LSP as a link so that other routers in the network can include it in their SPF computations. An SR-TE LSP is not supported with forwarding adjacency. The RSVP LSP is advertised as an unnumbered point-to-point link and the link LSP/LSA has no TE opaque sub-TLVs, as described in RFC 3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels.

When the forwarding adjacency feature is enabled, each node advertises a P2P unnumbered link for each best metric tunnel to the router ID of any endpoint node. The node does not include the tunnels as IGP shortcuts in SPF computation directly. Instead, when the LSA or LSP advertising the corresponding P2P unnumbered link is installed in the local routing database, the node performs an SPF and uses it like any other link LSA or LSP. The link bidirectional check requires that a link, regular or tunnel link, exists in the reverse direction for the tunnel to be used in SPF.

The forwarding adjacency feature supports forwarding of both IPv4 and IPv6 prefixes. Specifically, it supports family IPv4 in OSPFv2, family IPv6 in OSPFv3, families IPv4 and IPv6 in ISIS MT=0, and family IPv6 in ISIS MT=2. Note that the igp-shortcut option under the LSP name governs the use of the LSP with both the igp-shortcut and the advertise-tunnel-link options in IGP. Impact of LSP level configuration on IGP shortcut and forwarding adjacency features describes the interactions of the forwarding adjacency feature.

This feature is enabled by configuring both the segment routing and forwarding adjacency features within an IS-IS instance in a multitopology MT=0.

Both IPv4 and IPv6 SR-ISIS tunnels can be resolved and further tunneled over one or more RSVP-TE LSPs used as forwarding adjacencies.

This feature uses the following procedures:

• The forwarding adjacency feature only advertises into IS-IS RSVP-TE LSPs. SR-TE LSPs are not supported.

• An SR-ISIS tunnel (node SID) can have up to 32 next hops, some of which can resolve to a forwarding adjacency and some to a direct IP link. When the router ecmp value is configured lower than the number of next hops for the SR-ISIS tunnel, the subset of next hops selected prefers a forwarding adjacency over an IP link.

• In SR OS, ECMP and LFA are mutually exclusive on a per-prefix basis. This is not specific to SR-ISIS but also applies to IP FRR, LDP FRR, and SR-ISIS FRR. If an SR-ISIS tunnel has one or more next hops that resolve to forwarding adjacencies, each next hop is protected by the FRR mechanism of the RSVP-TE LSP through which it is tunneled. In this case, LFA backup is not programmed by IS-IS.

• If an SR-ISIS tunnel has a single primary next hop that resolves to a direct link (not to a forwarding adjacency), base LFA may protect it if a loop-free alternate path exists. The LFA path may or may not use a forwarding adjacency.

• IS-IS does not compute a remote LFA or a TI-LFA backup for an SR-ISIS tunnel when forwarding adjacency is enabled in the IS-IS instance, even if these two types of LFAs are enabled in the configuration of that same IS-IS instance.

The configuration in IGP shortcut feature configuration enables IGP shortcuts for resolving IGP routes, indirect next hop of static routes, and BGP next hop of BGP routes. The user can enable LDP FECs over IGP shortcuts by further configuring T-LDP sessions, with the tunneling option, to the destination of the RSVP LSP. In this case, LDP FEC is tunneled over the RSVP LSP, effectively implementing LDP-over-RSVP without having to enable the ldp-over-rsvp option in OSPF or IS-IS. The ldp-over-rsvp and igp-shortcut options are mutually exclusive under OSPF or IS-IS.

Similarly, LDP FECs can be tunneled over SR-TE LSPs as detailed in IPv4 IGP shortcuts using SR-TE LSP feature configuration.

Similar to LDP forwarding over IGP shortcut tunnels, the user can enable the resolution of LDP FECs over static route shortcuts by configuring T-LDP sessions and a static route that provides tunneled next hops corresponding to RSVP LSPs. In this case, indirect tunneled next hops in a static route are preferred over IP indirect next hops. For more information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

This feature supports multicast Reverse-Path Check (RPF) in the presence of IGP shortcuts. When the multicast source for a packet is reachable via an IGP shortcut, the RPF check fails because PIM requires a bidirectional path to the source but IGP shortcuts are unidirectional.

The IGP shortcut feature provides IGP with the capability to populate the multicast RTM with the prefix IP next hop when both the igp-shortcut option and the multicast-import option are enabled in IGP.

This change is made possible with the enhancement introduced by which SPF keeps track of both the direct first hop and the tunneled first hop of a node that is added to the Dijkstra tree.

Note that IGP does not pass LFA next-hop information to the mcast RTM in this case. Only ECMP next-hops are passed. As a consequence, features such as PIM Multicast-Only FRR (MoFRR) only work with ECMP next-hops when IGP shortcuts are enabled.

Finally, note that the concurrent enabling of the advertise-tunnel-link option and the multicast-import option results a multicast RTM that is a copy of the unicast RTM and is populated with mix of IP and tunnel NHs. RPF succeeds for a prefix resolved to a IP NH, but fails for a prefix resolved to a tunnel NH. Impact of IGP shortcut and forwarding adjacency on unicast and multicast RTM summarizes the interaction of the igp-shortcut and advertise-tunnel-link options with unicast and multicast RTMs.

The router supports the MPLS entropy label (RFC 6790) on RSVP-TE LSPs used for IGP and BGP shortcuts. LSR nodes in a network can load-balance labeled packets in a more granular way than by hashing on the standard label stack. See MPLS entropy label and hash label for more information.

To configure insertion of the entropy label on IGP or BGP shortcuts, use the entropy-label command under the configure>router context.

A typical application of the SRLG feature is to provide for an automatic placement of secondary backup LSPs or FRR bypass/detour LSPs that minimizes the probability of fate sharing with the path of the primary LSP (Shared Risk Link Groups).

The following details the steps necessary to create shared risk link groups:

• For primary/standby SRLG disjoint configuration:

  1. Create an SRLG-group, similar to admin groups.

  2. Link the SRLG-group to MPLS interfaces.

  3. Configure primary and secondary LSP paths and enable SRLG on the secondary LSP path. Note that the SRLG secondary LSP paths always perform a strict CSPF query. The srlg-frr command is irrelevant in this case.

• For FRR detours/bypass SRLG disjoint configuration:

  1. Create an SRLG group, similar to admin groups.

  2. Link the SRLG group to MPLS interfaces.

  3. Enable the srlg-frr (strict/non-strict) option, which is a system-wide parameter, and it force every LSP path CSPF calculation, to take the configured SRLG memberships (and propagated through the IGP opaque-te-database) into account.

  4. Configure primary FRR (one-to-one/facility) LSP paths. Consider that each PLR creates a detour/bypass that only avoids the SRLG memberships configured on the primary LSP path egress interface. In a one-to-one case, detour-detour merging is out of the control of the PLR. As such, the latter does not ensure that its detour is prohibited to merge with a colliding one. For facility bypass, with the presence of several bypass type to bind to, priority is given in the following order:

     1. manual bypass disjoint
     2. manual bypass non-disjoint (eligible only if srlg-frr is non-strict)
     3. dynamic disjoint
     4. dynamic non-disjoint (eligible only if srlg-frr is non-strict)
  Note: Non-CSPF manual bypass is not considered.

  

This feature is supported on OSPF and IS-IS interfaces on which RSVP is enabled.

The likelihood of paths with links sharing SRLG values with a primary path being used by a bypass or detour LSP can be configured if a penalty weight is specified for the link. The higher the penalty weight, the less desirable it is to use the link with a specific SRLG.

SRLG penalty weight operation illustrates the operation of SRLG penalty weights.

The primary LSP path includes a link between A and D with SRLG (1) and (2). The bypass around this link through nodes B and C includes links (a) and (d), which are members of SRLG (1), and links (b) and (c), which are members of SRLG 2. If the link metrics are equal, then this gives four ECMP paths from A to D via B and C:

• (a), (d), (e)

• (a), (c), (e)

• (b), (c), (e)

• (b), (d), (e)

Two of these paths include undesirable (from a reliability perspective) link (c). SRLG penalty weights or costs can be used to provide a tiebreaker between these paths so that the path including (c) is less likely to be chosen. For example, if the penalty associated with SRLG (1) is 5, and the penalty associated with SRLG (2) is 10, and the penalty associated with SRLG (3) is 1, then the cumulative penalty of each of the paths above is calculated by summing the penalty weights for each SRLG that a path has in common with the primary path:

• (a), (d), (e) = 10

• (a), (c), (e) = 15

• (b), (c), (e) = 20

• (b), (d), (e) = 15

Therefore path (a), (d), (e) is chosen because it has the lowest cumulative penalty.

Penalties are applied by summing the values for SRLGs in common with the protected part of the primary path.

A user can define a penalty weight value associate with an SRLG group using the penalty-weight parameter of the srlg-group command under the configure>router-if-attribute context. If an SRLG penalty weight is configured, then CSPF includes the SRLG penalty weight in the computation of an FRR detour or bypass for protecting the primary LSP path at a PLR node. Links with a higher SRLG penalty should be more likely to be pruned than links with a lower SRLG penalty.

Note that the configured penalty weight is not advertised in the IGP.

An SRLG penalty weight is applicable whenever an SRLG group is applied to an interface, including in the static SRLG database. However, penalty weights are used in bypass and detour path computation only when the srlg-frr (loose) flag is enabled.

This feature provides operations with the ability to manually enter the link members of SRLG groups for the entire network at any SR OS which needs to signal LSP paths (for example, a head-end node).

The operator may explicitly enable the use by CSPF of the SRLG database. In that case, CSPF does not query the TE database for IGP advertised interface SRLG information.

Note, however, that the SRLG secondary path computation and FRR bypass/detour path computation remains unchanged.

There are deployments where the SR OS interoperates with routers that do not implement the SRLG membership advertisement via IGP SRLG TLV or sub-TLV.

In these situations, the user is provided with the ability to enter manually the link members of SRLG groups for the entire network at any SR OS which needs to signal LSP paths, for example, a head-end node.

The user enters the SRLG membership information for any link in the network by using the interface ip-int-name srlg-group group-name command in the config>router>mpls> srlg-database>router-id context. An interface can be associated with up to 5 SRLG groups for each execution of this command. The user can associate an interface with up to 64 SRLG groups by executing the command multiple times. The user must also use this command to enter the local interface SRLG membership into the user SRLG database. The user deletes a specific interface entry in this database by executing the no form of this command.

The group-name must have been previously defined in the srlg-group group-name value group-value command in the config>router>if-attribute. The maximum number of distinct SRLG groups the user can configure on the system is 1024.

The parameter value for router-id must correspond to the router ID configured under the base router instance, the base OSPF instance or the base IS-IS instance of a specific node. Note however that a single user SRLG database is maintained per node regardless if the listed interfaces participate in static routing, OSPF, IS-IS, or both routing protocols. The user can temporarily disable the use by CSPF of all interface membership information of a specific router ID by executing the shutdown command in the config>router>mpls> srlg-database> router-id context. In this case, CSPF assumes these interfaces have no SRLG membership association. The operator can delete all interface entries of a specific router ID entry in this database by executing the no router-id router-address command in the config>router>mpls> srlg-database context.

CSPF does not use entered SRLG membership if an interface is not listed as part of a router ID in the TE database. If an interface was not entered into the user SRLG database, it is assumed that it does not have any SRLG membership. CSPF does not query the TE database for IGP advertised interface SRLG information.

The operator enables the use by CSPF of the user SRLG database by entering the user-srlg-db enable command in the config>router>mpls context. When the MPLS module makes a request to CSPF for the computation of an SRLG secondary path, CSPF queries the local SRLG and computes a path after pruning links which are members of the SRLG IDs of the associated primary path. Similarly, when MPLS makes a request to CSPF for a FRR bypass or detour path to associate with the primary path, CSPF queries the user SRLG database and computes a path after pruning links which are members of the SRLG IDs of the PLR outgoing interface.

The operator can disable the use of the user SRLG database by entering the user-srlg-db disable in command in the config>router>mpls context. CSPF then resumes queries into the TE database for SRLG membership information. However, the user SRLG database is maintained

The operator can delete the entire SRLG database by entering the no srlg-database command in the config>router>mpls context. In this case, CSPF assumes all interfaces have no SRLG membership association if the user has not disabled the use of this database.

This feature enhances the prior implementation of an inter-area RSVP P2P LSP by making the ABR selection automatic at the ingress LER. The user does not need to include the ABR as a loose-hop in the LSP path definition.

CSPF adds the capability to compute all segments of a multisegment intra-area or inter-area LSP path in one operation.

Automatic ABR node selection for inter-area LSP illustrates the role of each node in the signaling of an inter-area LSP with automatic ABR node selection.

CSPF for an inter-area LSP operates as follows:

• CSPF in the Ingress LER node determines that an LSP is inter-area by doing a route lookup with the destination address of a P2P LSP (that is 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 as inter-area.

• When the path of the LSP is empty, CSPF computes a single-segment intra-area path to an ABR node that advertised a prefix matching with the destination address of the LSP.

• When the path of the LSP contains one or more hops, CSPF computes a multisegment intra-area path including the hops that are in the area of the Ingress LER node.

• When all hops are in the area of the ingress LER node, the calculated path ends on an ABR node that advertised a prefix matching with the destination address of the LSP.

• When there are one or more hops that are not in the area of the ingress LER node, the calculated path ends on an ABR node that advertised a prefix matching with the first hop-address that is not in the area of the ingress LER node.

• Note the following special case of a multisegment 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.

  This behavior can be illustrated in the CSPF for an inter-area LSP. The TE link between ABR nodes D and E is in area 0. When node C computes the path for LSP from C to B which path specified nodes C and D as loose hops, it would fail the path computation if CSPF attempted a path all the way to the last hop in the local area, node E. Instead, CSPF stops the path at node A which further expands the ERO by including link D-E as part of the path in area 0.

  

• If there is more than 1 ABR that advertised a prefix, CSPF calculates a path for all ABRs. Only the shortest path is withheld. If more than one path has the shortest path, CSPF picks a path randomly or based on the least-fill criterion if enabled. If more than one ABR satisfies the least-fill criterion, CSPF also picks one path randomly.

• The path for an intra-area LSP path is not able to exit and re-enter the local area of the ingress LER. This behavior was possible in prior implementation when the user specified a loose hop outside of the local area or when the only available path was via TE links outside of the local area.

The OSPF virtual link extends area 0 for a router that is not connected to area 0. As a result, it makes all prefixes in area 0 reachable via an intra-area path but in reality, they are not because 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 because none of these links is directly connected to this node.

This 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 ABR nodes that is 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.

For protection of the area border router, the upstream node of the area border router acts as a point-of-local-repair (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 area border node.

Manual bypass protection works only when a correct completely strict path is provisioned that avoids the area border node.

Dynamic bypass protection provides for the automatic computation, signaling, and association with the primary path of an inter-area P2P LSP to provide ABR node protection. ABR node protection using dynamic bypass LSP illustrates the role of each node in the ABR node protection using a dynamic bypass LSP.

In order for a PLR node within the local area of the ingress LER to provide ABR node protection, it must dynamically signal a bypass LSP and associate it with the primary path of the inter-area LSP using the following new procedures:

• The PLR node must inspect the node-id RRO 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 node and with the XRO set to exclude the node-id of the protected ABR node.

• 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 node 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 node signals the dynamic bypass and automatically includes the XRO with the address of the protected ABR node and propagate 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 object in the Path message.

• If a node-protect dynamic bypass cannot be found or signaled, the PLR node attempts a link-protect dynamic bypass LSP. As in 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 node-id RRO also contains the interface address. Otherwise the neighbor is not created when the bypass is activated by the PLR node. The Path state then times out after three refreshes following the activation of the bypass backup LSP.

Note that a one-to-one detour backup LSP cannot be used at the PLR for the protection of the ABR node. As a result, a PLR node does not signal a one-to-one detour LSP for ABR protection. In addition, an ABR node rejects 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 regardless if the cspf-on-loose-hop option is enabled or not on the node. In other words, the router as a transit ABR for the detour path rejects the signaling of an inter-area detour backup LSP.

This section describes how the matrix of include or exclude colors in a route-admin-tag-policy policy-name, which is assigned to a route, are matched against LSP internal colors. This is a generic algorithm. The following sections provide further details of how this applies to specific use cases.

Internal color matching occurs before any resolution filter is applied.

The following selection process assumes the system starts with a set of eligible RSVP and SR-TE LSPs to the appropriate BGP next hop.

1. Prune the following RSVP and SR-TE LSPs from the eligible set:

   • uncolored LSPs

   • LSPs where none of the internal colors match any "include" color for the route

   • LSPs where any of the internal colors match any "exclude" color for the route

2. If none of the LSPs match, then the default behavior is that the route does not resolve. Depending on the context, configure a fall-back method, as described in LSP admin tag use in tunnel selection for VPRN and EVPN auto-bind.

3. If a route does not have an admin-tag policy, it is assumed that the operator does not want to express a preference for the LSP to use. Therefore, routes with no admin-tag policy can still resolve to any tagged or untagged LSP.

This selection process results in a set of one or more ECMP LSPs, which may be further reduced by a resolution filter.

For VPRN, EVPN-VPLS, and EVPN-VPWS, routes may be imported via peer route import policies that contain route admin-tag policies or via VRF import for VPRN and VSI import for EVPN VPLS or Epipe used for auto-bind-tunnel.

VRF import and VSI import policies take precedence over the peer route import policy.

For policies that contain route admin-tag policies, the set of available RSVP and SR-TE LSPs in TTM are first pruned as described in Internal route color to LSP color matching algorithm. This set may then be further reduced by a resolution filter. If weighted-ecmp is configured, then this is applied across the resulting set.

Routes with no admin-tag, or a tag that is not explicitly excluded by the route admin tag policy, can still resolve to any tagged or untagged LSP but matching tagged LSPs are used in preference to any other. It is possible that following the resolution filter no eligible RSVP or SR-TE LSP exists. By default, the system falls back to regular auto-bind behavior using LDP, SR-ISIS, SR-OSPF, or any other lower priority configured tunnel type, otherwise the resolution fails. That is, matching admin-tagged RSVP or SR-TE LSPs are used in preference to other LSP types, whether tagged or untagged. However, it is possible on a per-service basis to enforce that only specific tagged tunnels should be considered, otherwise resolution fails, using the enforce-strict-tunnel-tagging command in the auto-bind-tunnel context.

A specific LSP can be selected as transport to a specified BGP next hop for BGP labeled unicast and unlabeled BGP routes tunneled over RSVP and SR-TE LSPs.

Routes are imported via import route policies. Named routing policies may contain route admin-tag policies. For route import policies that contain route admin-tag policies, the set of available RSVP and SR-TE LSPs in TTM are first pruned as described in Internal route color to LSP color matching algorithm.

This set may then be further reduced by a resolution filter.

If weighted-ecmp is configured, then this is applied across the resulting set.

Routes with no admin-tag can still resolve to any tagged or untagged LSP. It is possible that, following the resolution filter, no eligible RSVP or SR-TE LSP exists. By default, the system falls back to using LDP, SR-ISIS, SR-OSPF, or any other lower-priority tunnel type; otherwise the resolution fails. That is, matching admin-tagged RSVP or SR-TE LSPs are preferred to other LSP types. On a per-address family basis, the enforce-strict-tunnel-tagging command in the next-hop-resolution filter for BGP labeled routes or shortcut tunnels can be used to enforce that only tagged tunnels are considered; otherwise, resolution fails.

When LSP Self-ping is enabled, destination UDP port 8503 is opened and a unique session ID is allocated for each RSVP LSP path. When an RESV message is received following a resignaling event, LSP Self-ping packets are sent at configurable periodic intervals until a reply is received from the far end for that session ID.

LSP Self-ping applies in cases where the active path is changed, while the previous active path remains up, whether it is FRR/MBB or pre-empted. These cases are as follows:

• primary in degraded state -> standby or secondary path

• standby or secondary path -> primary path (reversion)

• standby or secondary path -> another standby or secondary path (tools>perform>router>mpls>switch-path command or path preference change)

• degraded standby/secondary path -> degraded primary path (degraded primary is preferred to degraded standby/secondary path)

• MBB on active path

A path can go to a degraded state either because of FRR active (only on the primary path), soft pre-emption, or LSP BFD down (when the failure action is failover).

The system does not activate a candidate path until the first LSP Self-ping reply is received, subject to the timeout. The LSP Self-ping timer is started when the RESV message is received. The system then periodically sends LSP Self-ping packets until the timer expires or the first LSP Self-ping reply is received, whichever comes first. If the timeout expires before an LSP Self-ping reply has been received and the timeout-action is set to retry, then the system tears down the candidate path (in the case of switching between paths) and go back to CSPF for a new path. The system then starts the LSP Self-ping cycle again after a new path is obtained. In the case of switching between paths, the system retries immediately and increments the retry counter. In the case of MBB, the system retries immediately, but does not increment the retry counter, which has the effect of continuously repeating the retry/LSP Self-ping cycle until a new path is successfully established.

If no timeout is configured, then the default value is used.

The router can send LSP Self-ping packets at a combined rate across all sessions of 125 packets per second. This means that it takes 10 seconds to detect that the data plane is forwarding for 1250 LSPs. If the number of currently in-progress LSP Self-ping sessions reaches 125 PPS with no response, then the system continues with these LSP Self-ping sessions until the timeout is reached and is not able to test additional LSP paths. In scaled scenarios, it is recommended that the lsp-self-ping interval and timeout values be configured so that LSP Self-ping sessions are completed (either successfully or through timing out) so that all required LSP paths are tested within an acceptable time frame. A count of the number of LSP Self-ping and OAM resource exhaustion timeouts is shown in the output of the show>router>mpls>lsp detail and show>router>mpls>lsp-self-ping commands.

At the root of the P2MP LSP (head-end or ingress LER node):

1. First, the P2MP LSP state is established via the control plane. Each leaf of the P2MP LSP has a next-hop label forwarding entry (NHLFE) configured in the forwarding plane for each outgoing interface.

2. The user maps a specific multicast destination group address to the P2MP LSP in the base router instance by configuring a static multicast group under a tunnel interface representing the P2MP LSP.

3. An FTN entry is programmed at the ingress of the head-end node that maps the FEC of a received user IP multicast packet to a list of outgoing interfaces (OIF) and corresponding NHLFEs.

4. The head-end node replicates the received IP multicast packet to each NHLFE. Replication is performed at ingress toward the fabric, or at egress forwarding engine, or both, depending on the location of the OIF.

5. At ingress, the head-end node performs a PUSH operation on each of the replicated packets.

At an LSR node that is not a branch node, the LSR performs a label swapping operation on a leaf of the P2MP LSP. This is a conventional operation of an LSR in a P2P LSP. An ILM entry is programmed at the ingress of the LSR to map an incoming label to a NHLFE.

For control packets received on an ILM in an LSR, packets that arrive with the TTL in the outer label expiring are sent to the CPM for further processing and are not forwarded to the egress NHLFE.

At an LSR node that is a branch node, the LSR performs a replication and a label swapping for each leaf of the P2MP LSP. An ILM entry is programmed at the ingress of the LSR to map an incoming label to a list of OIF and corresponding NHLFEs. There is a limit of 127 OIF/NHLFEs per ILM entry.

The following is an exception handling procedure for control packets received on an ILM in a branch LSR, packets that arrive with the TTL in the outer label expiring are sent to the CPM for further processing and not copied to the LSP branches.

At the leaf node of the P2MP LSP, (egress LER) the egress LER performs a pop operation. An ILM entry is programmed at the ingress of the egress LER to map an incoming label to a list of next-hop/OIF.

For control packets received on an ILM in an egress LER, the packet is sent to the CPM for further processing if there is any of the IP header exception handling conditions set after the label is popped: 127/8 destination address, router alert option set, or any other options set.

At an LSR node which is both a branch node and an egress leaf node, (bud node) the bud LSR performs a pop operation on one or many replications of the received packet and a swap operation of the remaining replications. An ILM entry is programmed at ingress of the LSR to map the incoming label to list of NHLFE/OIF and next-hop/OIF. Note however, the exact same packets are replicated to an LSP leaf and to a local interface.

The following are the exception handling procedures for control packets received on an ILM in a bud LSR, packets which arrive with the TTL in the outer label expiring are sent to the CPM and are not copied to the LSP branches. Packets whose TTL does not expire are copied to all branches of the LSP. The local copy of the packet is sent to the CPM for further processing if there is any of the IP header exception handling conditions set after the label is popped: 127/8 destination address, router alert option set, or any other options set.

On an ingress XCM or IOM/IMM, there are multiple multicast paths available to forward multicast packets, depending on the hardware being used. Each path has a set of multicast queues and associated with it. Two paths are enabled by default, a primary path and a secondary path, and represent the high-priority and low-priority paths respectively. Each VPLS SAP, access interface, and network interface have a set of per forwarding class multicast or broadcast queues, or both, which are defined in the ingress QoS policy associated with them. The expedited queues are attached to the primary path while the non-expedited queues are attached to secondary path.

When IMPM is enabled or when a P2MP LSP ILM exists on the ingress XCM or IOM/IMM or both, the remaining multicast paths are also enabled. 16 multicast paths are supported by default with 28 on 7950 XRS systems and 7750 SR-12e systems, with the latter having the tools perform system set-fabric-speed fabric-speed-b. One path remains as a secondary path and the rest are primary paths.

A separate pair of shared multicast queues is created on each of the primary paths, one for IMPM managed packets and one for P2MP LSP packets not managed by IMPM. The secondary path does not forward IMPM managed packets or P2MP LSP packets. These queues have a default rate (PIR=CIR) and CBS/MBS/low-drop-tail thresholds, but these can be changed under the bandwidth policy.

A VPLS snooped packet, a PIM routed packet, or a P2MP LSP packet is managed by IMPM if it matches a <*,G> or a <S,G> multicast record in the ingress forwarding table and IMPM is enabled on the ingress XMA or the FP where the packet is received. The user enables IMPM on the ingress XMA datapath or the FP datapath using the config>card>fp>ingress>mcast-path-management command.

A packet received on an IP interface and to be forwarded to a P2MP LSP NHLFE or a packet received on a P2MP LSP ILM is not managed by IMPM when IMPM is disabled on the ingress XMA or the FP where the packet is received or when IMPM is enabled but the packet does not match any multicast record. A P2MP LSP packet duplicated at a branch LSR node is an example of a packet not managed by IMPM even when IMPM is enabled on the ingress XMA or the FP where the P2MP LSP ILM exists. A packet forwarded over a P2MP LSP at an ingress LER and which matches a <*,G> or a <S,G> is an example of a packet which is not managed by IMPM if IMPM is disabled on the ingress XMA or the FP where the packet is received.

When a P2MP LSP packet is not managed by IMPM, it is stored in the unmanaged P2MP shared queue of one of the primary multicast paths.

By default, non-managed P2MP LSP traffic is distributed across the IMPM primary paths using hash mechanisms. This can be optimized by enabling IMPM on any forwarding complex, which allows the system to redistribute this traffic on all forwarding complexes across the IMPM paths to achieve a more even capacity distribution. Be aware that enabling IMPM causes routed and VPLS (IGMP and PIM) snooped IP multicast groups to be managed by IMPM.

The above ingress datapath procedures apply to packets of a P2MP LSP at ingress LER, LSR, branch LSR, bud LSR, and egress LER. Note that in the presence of both IMPM managed traffic and unmanaged P2MP LSP traffic on the same ingress forwarding plane, the user must account for the presence of the unmanaged traffic on the same path when setting the rate limit for an IMPM path in the bandwidth policy.

When soft preemption is enabled for P2MP S2L LSPs, the S2L preemption is governed by the timer value configured using the config>router>rsvp preemption-timer classic CLI command or configure router rsvp preemption-timer MD-CLI command.

When the S2L is preempted at an LSR node, the preempting node sends to the head-end node an Resv refresh message with the "preemption pending" flag set or a PathErr message with error code=34 (Reroute) and a value=1 (Reroute request soft preemption). The preemption timer (configured as described above) starts. When the timer expires, the node performs MBB on the affected adaptive CSPF LSP. Both IGP metric and TE metric based CSPF LSPs are included. If an alternative path that excludes the flagged interface is not found, the LSP is placed on a retry list in a similar way to the global revertive procedure at a head-end node.

When the preemption timer expires, the preempting node tears down the S2L and sends a path error to the head-end node, and the head-end node places the S2L on the retry list.

When soft preemption is not enabled for the P2MP LSP, the value of the preemption timer is hard coded as 0 for S2L LSPs. That is, S2Ls are hard preempted by higher priority LSPs. Make-before-break (MBB) is not performed at the root of the preempted S2L. That is, the S2L is immediately torn down to the root PE when it is preempted and must signal again.

When an S2L is preempted, it sends an RESVTEAR message to the root PE (head-end) indicating the lack of resources, and then the S2L is torn down throughout the network. After the P2MP S2L retry or fast retry timer expires, the S2L signals again by sending a new PATH message from the headend, based on the newly calculated Constraint-based Shortest Path First (CSPF) path where the bandwidth resources are available.

S2Ls can preempt other P2P LSPs or other S2Ls based on the hold and setup priority.

To forward multicast packets over a P2MP LSP, perform the following steps:

1. Create a tunnel interface associated with the P2MP LSP: config>router>tunnel-interface rsvp-p2mp lsp-name. (The config>router>pim>tunnel-interface command has been discontinued.)

2. Add static multicast group joins to the PIM interface, either as a specific <S,G> or as a <*,G>: config>router>igmp>tunnel-if>static>group>source ip-address and config>router>igmp>tunnel-if>static>group>starg.

The tunnel interface identifier consists of a string of characters representing the LSP name for the RSVP P2MP LSP. Note that MPLS actually passes to PIM a more structured tunnel interface identifier. The structure follows the one BGP uses to distribute the PMSI tunnel information in BGP multicast VPN as specified in draft-ietf-l3vpn-2547bis-mcast-bgp, Multicast in MPLS/BGP IP VPNs. The format is: <extended tunnel ID, reserved, tunnel ID, P2MP ID> as encoded in the RSVP-TE P2MP LSP session_attribute object in RFC 4875.

The user can create one or more tunnel interfaces in PIM and associate each to a different RSVP P2MP LSP. The user can then assign static multicast group joins to each tunnel interface. Note however that a specific <*,G> or <S,G> can only be associated with a single tunnel interface.

A multicast packet which is received on an interface and which succeeds the RPF check for the source address is replicated and forwarded to all OIFs which correspond to the branches of the P2MP LSP. The packet is sent on each OIF with the label stack indicated in the NHLFE of this OIF. The packets are also replicated and forwarded natively on all OIFs which have received IGMP or PIM joins for this <S,G>.

The multicast packet can be received over a PIM or IGMP interface which can be an IES interface, a spoke-SDP-terminated IES interface, or a network interface.

To duplicate a packet for a multicast group over the OIF of both P2MP LSP branches and the regular PIM or IGMP interfaces, the tap mask for the P2MP LSP and that of the PIM based interfaces needs to be combined into a superset MCID.

To configure MPLS-signaled label switched paths (LSPs), an LSP must run from an ingress router to an egress router. Configure only the ingress router and configure LSPs to allow the software to make the forwarding decisions or statically configure some or all routers in the path. The LSP is set up by Resource Reservation Protocol (RSVP), through RSVP signaling messages. The router automatically manages label values. Labels that are automatically assigned have values ranging from 1,024 through 1,048,575 (see Label values).

A static LSP is a manually set up LSP where the nexthop IP address and the outgoing label are explicitly specified.

To configure signaled LSPs, you must first create one or more named paths on the ingress router. For each path, the transit routers (hops) in the path are specified.

At least one router interface and one system interface must be defined in the config>router>interface context to configure MPLS on an interface.

To configure a static or a RSVP signaled LSP, you must enable MPLS on the router, which automatically enables RSVP and adds the system interface into both contexts. Any other network IP interface, other than loopbacks, added to MPLS is also automatically enabled in RSVP and becomes a TE link. When the interface is enabled in RSVP, the IGP instance advertises the Traffic Engineering (TE) information for the link to other routers in the network to build their TE database and compute CSPF paths. Operators must enable the traffic-engineering option in the ISIS or OSPF instance for this. Operators can also configure under the RSVP context of the interface the RSVP protocol parameters for that interface.

If only static label switched paths are used in your configurations, operators must manually define the paths through the MPLS network. Label mappings and actions configured at each hop must be specified. Operators can disable RSVP on the interface if it is used only for incoming or outgoing static LSP label by shutting down the interface in the RSVP context. The latter causes IGP to withdraw the TE link from its advertisement which removes it from its local and neighbors TE database.

If dynamic LSP signaling is implemented in an operator’s network then they must keep RSVP enabled on the interfaces they want to use for explicitly defined or CSPF calculated LSP path.

Admin groups can signify link colors, such as red, yellow, or green. MPLS interfaces advertise the link colors it supports. CSPF uses the information when paths are computed for constrained-based LSPs. CSPF must be enabled in order for admin groups to be relevant.

To configure MPLS admin-group parameters, enter the following commands:

if-attribute
    — admin-group group-name value group-value
    — mpls
    — frr-object
    — resignal-timer minutes

The following displays an admin group configuration example:

ALA-1>config>router>if-attr# info
----------------------------------------------
admin-group "green" value 15 
admin-group "yellow" value 20 
admin-group "red" value 25 
----------------------------------------------
A:ALA-1>config>router>mpls# info
----------------------------------------------
            resignal-timer 500
...
----------------------------------------------
A:ALA-1>config>router>mpls#

Configure the label-map parameters if the interface is used in a static LSP. To configure an MPLS interface on a router, enter the following commands:

config>router>mpls
    — interface
        — no shutdown
        — admin-group group-name [group-name...(up to 32 max)]
        — label-map
            — pop
            — swap
            — no shutdown
        — srlg-group group-name [group-name...(up to 5 max)]
        — te-metric value

The following displays an interface configuration example:

A:ALA-1>config>router>mpls# info
----------------------------------------------
...
            interface "to-104"
                admin-group "green"
                admin-group "red"
                admin-group "yellow"
                label-map 35
                    swap 36 nexthop 10.10.10.91
                    no shutdown
                exit
            exit
            no shutdown
...
----------------------------------------------
A:ALA-1>config>router>mpls#

Configure an LSP path to use in MPLS. When configuring an LSP, the IP address of the hops that the LSP should traverse on its way to the egress router must be specified. 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 through other routers (loose).

Use the following CLI syntax to configure a path:

config>router> mpls
    — path path-name
        — hop hop-index ip-address {strict | loose}
        — no shutdown

The following displays a path configuration example:

A:ALA-1>config>router>mpls# info
------------------------------------------
            interface "system"
            exit
            path "secondary-path"
                hop 1 10.10.0.121  strict
                hop 2 10.10.0.145  strict
                hop 3 10.10.0.1    strict
                no shutdown
            exit
            path "to-NYC"
                hop 1 10.10.10.103 strict
                hop 2 10.10.0.210  strict
                hop 3 10.10.0.215  loose
            exit
------------------------------------------
A:ALA-1>config>router>mpls#

Configure an LSP path for MPLS. When configuring an LSP, you must specify the IP address of the egress router in the to statement. Specify the primary path to be used. Secondary paths can be explicitly configured or signaled upon the failure of the primary path. All other statements are optional.

The following displays an MPLS LSP configuration:

A:ALA-1>config>router>mplp# info
----------------------------------------------
...
            lsp "lsp-to-eastcoast"
                to 192.168.200.41
                rsvp-resv-style ff
                path-computation-method local-cspf
                include "red"
                exclude "green"
                adspec
                fast-reroute one-to-one
                exit
                primary "to-NYC"
                    hop-limit 10
                exit
                secondary "secondary-path"
                    bandwidth 50000
                exit
                no shutdown
            exit
            no shutdown
----------------------------------------------
A:ALA-1>config>router>mpls#

An LSP can be explicitly (statically) configured. Static LSPs are configured on every node along the path. The label’s forwarding information includes the address of the next hop router.

Use the following CLI syntax to configure a static LSP:

config>router>mpls
    — static-lsp lsp-name
        — to ip-address
        — push out-label nexthop ip-addr 
        — no shutdown

The following displays a static LSP configuration example:

A:ALA-1>config>router>mpls# info
----------------------------------------------
...
            static-lsp "static-LSP"
                to 10.10.10.124
                push 60 nexthop 10.10.42.3
                no shutdown
            exit
...
----------------------------------------------
A:ALA-1>config>router>mpls# 

Consider the following network setup:

A----B----C----D

| |

E----F

The user first configures the option to disable the dynamic bypass tunnels on node B if required. The CLI for this configuration is:

config>router>mpls>dynamic-bypass [disable | enable]

By default, dynamic bypass tunnels are enabled.

Next, the user configures an LSP on node B, such as B-E-F-C to be used only as bypass. The user specifies each hop in the path, for example, the bypass LSP has a strict path.

Note that including the bypass-only keyword disables the following options under the LSP configuration:

• bandwidth

• fast-reroute

• secondary

The following LSP configuration options are allowed:

• adaptive

• adspec

• exclude

• hop-limit

• include

• metric-type

• path-computation-method local-cspf

The following example displays a bypass tunnel configuration:

A:ALA-48>config>router>mpls>path# info
-------------------------------------------
...
            path "BEFC"
                hop 10 10.10.10.11  strict
                hop 20 10.10.10.12  strict
                hop 30 10.10.10.13  strict
                no shutdown
            exit


            lsp "bypass-BC"
                to 10.10.10.15
                primary "BEFC"
                exit
                no shutdown
...
-------------------------------------------
A:ALA-48>config>router>mpls>path#

Next, the user configures an LSP from A to D and indicates fast-reroute bypass protection by selecting facility as the FRR method (config>router>mpls>lsp>fast-reroute facility). If the LSP goes through B, and bypass is requested, and the next hop is C, and there is a manually configured bypass-only tunnel from B to C, excluding link BC, then node B uses that.

RSVP is used to set up LSPs. RSVP must be enabled on the router interfaces that are participating in signaled LSPs. The keep-multiplier and refresh-time default values can be modified in the RSVP context.

Initially, interfaces are configured in the config>router>mpls>interface context. Only these existing (MPLS) interfaces are available to modify in the config>router> rsvp context. Interfaces cannot be directly added in the RSVP context.

The following example displays an RSVP configuration example:

A:ALA-1>config>router>rsvp# info
----------------------------------------------
interface "system"
             no shutdown
          exit
          interface to-104
             hello-interval 4000
             no shutdown
          exit
          no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#

RSVP message pacing maintains a count of the messages that were dropped because the output queue for the egress interface was full.

Use the following CLI syntax to configure RSVP parameters:

config>router>rsvp
    — no shutdown
    — msg-pacing
        — period milli-seconds
        — max-burst number

The following example displays a RSVP message pacing configuration example:

A:ALA-1>config>router>rsvp# info
----------------------------------------------
            keep-multiplier 5
            refresh-time 60
            msg-pacing
                period 400
                max-burst 400
            exit
            interface "system"
                no shutdown
            exit
            interface to-104
                hello-interval 4000
                no shutdown
            exit
            no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#

TE graceful shutdown can be enabled on a specific interface using the config>router>rsvp>if>graceful-shutdown command. This interface is referred to as the maintenance interface.

Graceful shutdown can be disabled by executing the no form of the command at the RSVP interface level or at the RSVP level. In this case, the user configured TE parameters of the maintenance links are restored and the maintenance node floods them.