Configuring Local Protection

This chapter describes the functionality and commands associated with the configuration of local protection.

Introduction

Local Protection uses RSVP signaling to bypass a single primary label switched path (LSP) link or node failure. IGP re-convergence times can take several seconds. Local protection provides millisecond recovery times by pre-configuring MPLS label-switched backup paths at all enabled ingress and midpoint nodes along the LSP. When a failure occurs on a primary LSP, if the immediate upstream node is a PLR with a backup path capable of getting around the failure, the PLR activates the backup path immediately. A PathErr message with the RRO bit set for backup in use is sent to all upstream nodes. If the failure takes place at a non-protected node, a PathErr is sent upstream for the primary LSP and for any upstream backup paths that merge with the primary at the non-protected node. If an upstream node is capable of getting around the failure it does so; if it is not capable of getting around the failure it sends a PathErr message upstream.

Upon activation of the backup path, the PLR moves the MPLS traffic on that LSP to the prepared backup path. A backup path activation overview, of a section of the LSP downstream of the ingress, is depicted in Figure 5-1:

1. A failure occurs on the inbound interface of RTB for primary LSP section RTA - RTC.
   
   
2. RTA discovers the failure, and because it is downstream of the ingress, creates a Path-Err message and sends it upstream.
   
   
3. Because the RTA inbound interface for this primary LSP has a backup path capable of getting around the failure, RTA activates the backup path.
   
   
4. The backup path merges back into the primary path at the inbound interface of RTC after traversing RTD - RTF.
   
   

Figure 5-1. Backup Path Activation Overview

If the failed element recovers, IPriori moves the MPLS traffic back to the original LSP. IPriori supports local protection of up to 250 LSPs per Avici router. Local protection is supported on POS and Gigabit Ethernet interfaces, and composite links.

A pre-configured backup path can originate at any local protection enabled ingress or mid-point node along the LSP and merge back into the LSP at any midpoint or egress node. Local protection does not need to be enabled on the merge node. The point of merge is the closest down-stream LSP node on the primary that provides the lowest total cost from the PLR to the egress.

The first node in a backup path is called the Point of Local Repair (PLR). Figure 5-2 "Local Protection Outbound Interface Failure" shows a single node portion of a primary LSP with an operational inbound link and failed outbound link. The backup path bypasses the failed outbound link and continues on to a downstream node where it merges with the primary LSP.

Figure 5-2. Local Protection Outbound Interface Failure

In the case of a node failure, the PLR is the closest upstream node to the point of failure that provides a backup path bypassing the failed node. You can protect against an immediate downstream node failure by configuring the PLR for node disjoint. If node disjoint is not configured, the immediate downstream node may be used by the backup path. If node disjoint is configured, local protection will not use the immediate downstream node when signaling the backup path. By enabling node disjoint, if topology and constraints allow, the immediate downstream node is protected should the node fail.

Figure 5-3 "Local Protection Node Failure With Node Disjoint Enabled" shows how local protection with node disjoint enabled provides a backup path that bypasses a failed node.

Figure 5-3. Local Protection Node Failure With Node Disjoint Enabled

You can think of the PLR as the ingress for the backup path. In this documentation, the term ingress will always refer to the first primary LSP node and the term PLR will always refer to the first backup path node.

A backup path extends from its PLR origins to the merge node, where it rejoins the primary LSP. IPriori automatically switches to the backup path if the PLR is informed of a local or downstream primary LSP outbound link or downstream node failure. Due to required signaling, the closer the PLR is to the point of failure, the sooner the backup path will be active. The backup path is associated with a backup tunnel which may contain one or more backup paths for a primary LSP. Backup tunnels permit make-before-break for backup paths. A backup tunnel is auto-named by IPriori using the format: backup:primary-tunnel-name.

The Avici router supports two types of local protection: the simple backup LSP as defined in draft-swallow-rsvp-bypass-label-01.txt, from here on in referred to as the Bypass draft, and Detour backup LSP as defined in draft-gan-fast-reroute -00.txt, from here on in referred to as the Detour draft.

There are two basic differences between the two drafts from a configuration point of view. The Detour draft includes the fast reroute object which signals a subset of backup path parameter values to midpoint PLRs. The information contained in the fast reroute object allows a subset of backup path values to be used on all Detour draft supported backup paths along the primary LSP. This provides backup path parameter values for base SPF bandwidth, holding and reserving priority, the maximum number of backup path hops, and include and exclude administrative colors on all midpoint nodes that support the Detour draft. The second basic difference is that the Detour draft only requires that the route object ERO include routes from the PLR to the merge. The ability to merge back into the original primary LSP is provided by the detour object which provides the PLR and avoid node IDs. Backup paths using the RSVP signaled detour object are also referred to as detours. Multiple detours sharing the same link to the merge will merge at that shared link.

The Bypass draft does not provide a mechanism to inform midpoints of configured ingress backup path parameter values and therefore requires local configuration of backup path parameter values for each PLR. The Bypass draft includes in its route object ERO the route from the PLR to the merge, as well as, the route from the merge to the egress. In this document, a backup path that does not signal the detour object is referred to as a simple backup path.

These two levels of local protection allow IPriori to support three types of router configuration:

• MPLS tunnels made up exclusively of Avici routers support both drafts, allowing the configuration of a PLR for Bypass draft simple backup paths or Detour draft protection using detours. Because of the desirability of each PLR knowing the fast-reroute signaled parameter values, this documentation assumes an all Avici router tunnel will be configured for Detour draft.
  
  
• MPLS tunnels made up of a combination of Avici routers and Bypass draft routers only support the Bypass draft simple backup path for PLRs that protect Bypass draft nodes. An Avici router ingress on tunnels that contain Bypass draft nodes provides Detour draft support for Avici routers in the tunnel due to RSVP's ability to ignore the fast reroute object, for routers that do not understand it. If the ingress is a Bypass draft only router, Detour draft is not supported on backup path Avici routers. Bypass tunnels defined in the Bypass draft are not supported for this release. The Avici router may be a node in a bypass tunnel configured by a router that supports bypass tunnels as defined in the Bypass draft. The Avici router can be used as the egress in a bypass tunnel by configuring the Avici router for PHP using the no mpls egress-capable command.
  
  
• MPLS tunnels made up of a combination of Avici routers and Detour draft routers support the Detour draft for all Avici router and Detour draft nodes in the tunnel.
  
  

  NOTE Because aspects of the two drafts are mutually exclusive, If all three router types are present, some backup paths may fail. Therefore, IPriori does not support local protection on MPLS tunnels made up of Avici routers, Bypass draft, and Detour draft routers.

All Avici routers using local protection must be locally enabled for local protection. Fast reroute is only configured on the ingress of a tunnel containing Detour draft supported routers; the ingress must support the Detour draft.

In the case of a Bypass draft simple backup path, unless the PLR happens to be the ingress, the PLR is unaware of the fast-reroute signaled backup path values. Both Simple backup path and detour PLR values can be locally configured using a series of protect commands; these commands provide for the configuration of the following parameters:

• SPF Bandwidth
  
  
• Holding priority
  
  
• Reserving priority
  
  
• Include administrative colors
  
  
• Exclude administrative colors
  
  
• The maximum number of hops used by a backup path
  
  
• Resilience
  
  
• Adaptivity
  
  

Because the first six bullets above are signaled using the fast reroute object, for PLRs that support fast reroute, only resilience and adaptivity related parameter values need to be locally configured for midpoints that support fast reroute. But keep in mind that SPF bandwidth defaults to 0% unless modified by local configuration.

IPriori provides a form of local protection adaptivity for a replacement primary that is unable to fully protect itself. This local protection based adaptivity is called protect tolerance. Standard traffic engineering adaptivity performs an SPF and comes up with a better primary LSP. A primary LSP that is fully protected will not move traffic to a replacement primary LSP, signaled by adaptivity, until the replacement primary LSP is also fully protected. It is possible that this replacement primary will not be fully protected. A protect tolerance timer is set upon the signaling of the replacement primary LSP. Should the protect tolerance timer lapse prior to the replacement primary being fully protected, a new SPF is run in an attempt to find a replacement primary that is capable of fully protecting itself.

After a reasonable period of time, the moving of traffic to the new primary becomes more important than whether that new primary is fully protected. If the LSP signaled by the protect tolerance SPF is not fully protected before the expiration of the timer specified by the complete-reroute-unprotected command, any traffic not on the new LSP is moved to the new LSP.

A new midpoint default command mode, available from the traffic engineering configuration mode, provides for configuring backup path default values used by the PLR when the Avici router is a primary LSP ingress or midpoint. This mode is available for all commands configurable at both the ingress and midpoint PLRs. Values configured in midpoint default mode will be used by any backup paths unless replaced by fast reroute.

Primary LSPs that are locally protected are not moved due to adaptivity or manual configuration changes until the new LSP is as protected as the original LSP. The complete-reroute-unprotected command provides for the specification of the time to wait before moving traffic to the new LSP should the new LSP be unable to protect itself

Backup path adaptivity can cause a better backup path to become available. IPriori supports backup tunnel make-before-break for all backup paths. Make-before-break requires the configuration of unique IDs for both the original backup path and the new backup path. These IDs must differ from the PLR router ID. Select one of the PLR's available IP addresses to be used as the primary backup path address, and select a second address to be used as the replacement backup path address. A new command allows for the configuration of local protect primary and replacement backup IDs that are distinct from the router ID. The primary backup ID is used for signaling the original backup path. The replacement backup ID is used to signal a backup path caused by adaptivity or a manual change that affects the backup path. These additional path IDs provide for the full signaling of a new backup path before replacing the current backup path.

Figure 5-4. Make-Before-Break Using Backup Path Adaptivity

If a Non-Avici router that supports the Detour draft and not the Bypass draft is a member of the backup path, that router may not be able to signal the local-protect-available and local-protect-inuse objects supported by the Avici router. Make-before-break uses these flags to determine when every PLR is protected on a replacement primary LSP. By informing the ingress of routers that do not support these flags, the ingress will not consider these routers for determining if every PLR is protected on the replacement primary LSP, even though backup paths will be attempted at these routers. A new command is available to inform the Avici router of the Detour draft only routers that are present.

For this release, when a failure takes place affecting an ingress PLR, IP and LDP traffic will not be rerouted to backup paths at speeds normally associated with local protection.

There is a RSVP interoperability issue with the label-record sub-object and SE bit. Detour only routers do not support these items. Use the rsvp local-protect-interop command to specify the types of routers in your network so that IPriori can handle this RSVP interoperability issue.

Shared Risk Link Group (SRLG) is a functionality that groups links that share a common failure risk e.g., links or nodes that share the same conduit, power supply, or module. The grouping of links and nodes that share common failure risks into SRLGs allows for the specifying of additional costs or biases to be associated with these links and nodes. When a backup path is signaled, if the link being protected belongs to the same SRLG as the link or node being considered for the backup path, the link or node being considered will be avoided, if a lesser cost link or node is available. In the case of a biased SRLG member, if a lesser cost link is not available, the link or node will be used in the backup path, but the primary LSP will not be considered fully protected. If at some point, adaptivity determines that a fully protected primary is available, traffic will be moved to that protected primary. An SRLG can be configured for a cost that is added to the TE metric of the SRLG link to form the final cost. Instead of an additional cost, a bias value can be associated with the link that assures the final cost will be greater than any non-biased link cost. Same cost/bias SRLG groups should be specified in ranges; cost/bias configured values can be applied to a range of SRLG groups with a single command line.

Configuring Primary LSP Protection Tolerance

Protection tolerance provides a protection based adaptivity for new primaries, signaled by adaptivity, that are unable to fully protect themselves. When the adaptivity timer expires, an SPF is run on the primary LSP. If the original primary LSP was fully protected, and the adaptivity SPF signals a better primary, traffic will not be moved to the new primary LSP until it is fully protected. Should the new primary LSP be unable to fully protect itself, it is undesirable to wait a full adaptivity cycle before running a new SPF. Protect tolerance provides a timer that will determine when a SPF should be run if the new primary LSP is unable to fully protect itself.

Protection tolerance is configured using the protect-tolerance command and has the same options as the traffic engineering resilience command set. These options include: disabled, pacing, sorted-pacing, and linear. If protection tolerance is not explicitly configured for a primary LSP, protection tolerance defaults to the resilience settings for the affected LSP.

Because the protect-tolerance command only affects the primary LSP, it is not available in the midpoint default command mode.

Example 1: In the following example, the protect-tolerance linear command configures the tunnel to delay the establishment of new primary LSPs once local protection is in use. The linear method starts with the largest reservation amounts and their associated timers and ends with the smallest reservation amounts and their associated timers:

router(config)#mpls te ospf router(config-te)#tunnel oc192toBos router(config-te-tunnel)#protect-tolerance linear 8g 50s 5g 90s 2g 120s jitter 10% router(config-te-tunnel)#end router#show mpls te tunnel tunnel oc192toBos . . . protect-tolerance linear 8g 50000ms 5g 90000ms 2g 120000ms jitter 10% . . .

Example 2: In the following example, the protect-tolerance pacing command configures the ingress router to delay the establishment of new primary LSPs once local protection is in use. This pacing method configuration establishes new primary LSPs one at a time, using a 10 second delay between reservation attempts and with a jitter of plus or minus 2 seconds:

router(config)#mpls te ospf router(config-te)#tunnel oc192toBos router(config-te-tunnel)#protect-tolerance pacing 60s jitter 6s router(config-te-tunnel)#end router#show mpls te tunnel tunnel oc192toBos . . . protect-tolerance pacing 60000ms jitter 6000ms . . .

Understanding Local Protection Parameter Precedence

There are two ways in which local protection parameter precedence is different from non-local protection traffic engineering:

• The midpoint default command mode provides a new command mode for the configuration of parameter values associated with a backup path.
  
  
• Whether a command mode is available, and the order of available command modes in the precedence hierarchy, depends upon whether the PLR node being configured is an ingress or midpoint of the primary LSP.
  
  

The default for all command modes except factory default is non-specified. The default for factory default is disabled.

Local Protection Parameter Ingress Precedence

Local protection parameters can be explicitly set in the tunnel command mode, set in a named parameter set, set as a tunnel default, set as a midpoint default or default to the factory default. All of these command modes are available for local protection parameters configured for the ingress as ingress or ingress as PLR.

Figure 5-5 shows a graphic presentation of the ingress local protection portion of the Avici router command line interface. The command modes affected by ingress local protection are mpls te, leading to tunnel-name, tunnel default, tunnel parameter-set, and midpoint default.

Figure 5-5. Navigating Through the Ingress Local Protection Command Line Interface

For local protection parameters configured for the primary LSP ingress PLR:

1. If you explicitly configure a local protection parameter in tunnel command mode, that parameter value overrides everything else.
   
   
2. If you do not explicitly configure a local protection parameter in tunnel command mode, but you do explicitly configure a local protection parameter in a parameter-set, for a set that is referenced by the tunnel, that parameter value overrides everything else.
   
   
3. If you do not explicitly configure a local protection parameter in either the tunnel command mode or the parameter-set specified in the tunnel, but you do configure the parameter in the tunnel default parameter-set, then the tunnel defaults parameter value is used.
   
   
4. If you do not explicitly configure a local protection parameter in the tunnel command mode, a parameter-set specified in the tunnel, or the tunnel default parameter-set, and you do specify a midpoint default parameter value, then the midpoint default parameter value is used.
   
   
5. If none of the above applies for a given parameter, the factory default option value is used.
   
   

When a tunnel parameter-set, tunnel default, or midpoint default parameter is changed, traffic engineering updates all affected tunnels. This can force tunnels to be rerouted.

Local Protection Parameter Midpoint Precedence

If the PLR is a primary LSP midpoint, The midpoint default, tunnel default and factory default command modes are available for configuring local protection parameters.

Figure 5-6 shows a graphic presentation of the midpoint local protection portion of the Avici router command line interface. The command modes affected by midpoint local protection are mpls te, leading to midpoint default and tunnel default.

Figure 5-6. Navigating Through the Midpoint Local Protection Command Line Interface

For local protection parameters configured for any primary LSP midpoint PLR:

1. If you explicitly configure a local protection parameter in midpoint default command mode, that parameter value overrides everything else.
   
   
2. If you do not explicitly configure a local protection parameter in midpoint default command mode, but you do explicitly configure a local protection parameter in tunnel default command mode, that parameter value overrides everything else.
   
   
3. If neither of the above applies for a given parameter, the factory default option value is used.
   
   

If a tunnel default or midpoint default parameter is changed, local protection updates all affected backup paths. This can force backup tunnels to be rerouted. Midpoint PLR parameters signaled by fast-reroute override any configured values with the exception of bandwidth which is modified by the local SPF bandwidth.

Understanding Enabled, Disabled, Non-Specified Command Options

Typically, IPriori allows you to enable or disable/delete a parameter. Because local protection precedence provides for the capability to use the same command mode in different precedence orders, a third option is introduced for some commands: to not specify a parameter within a command mode. This option is available for the following commands:

• local-protect - used to determine whether local protection is enabled on this node
  
  
• send-fast-reroute - used to determine whether the fast reroute object is sent for this ingress node
  
  
• node-disjoint - used to determine whether the following node can be used by the backup path originating at this PLR
  
  

Whether one of these functions is enabled, disabled, or non-specified depends upon the option entered with the command as follows:

• enabled: enables the command for the command mode in which you enter the command
  
  
• disabled: disables the command for the command mode in which you enter the command. This option could possibly cause a reroute of the tunnel.
  
  
• no: configures the command to be non-specified for this command mode. When the command is non-specified, IPriori follows the rules for parameter precedence to determine active parameter values for this PLR.
  
  

These options allow you to configure different local protect enable values for such different situations as ingress using fast reroute, midpoint using simple backup, and tunnels configured using parameter sets.

Configuring Local Protection Parameters

Understanding Backup Path Make-Before-Break

There are two considerations when configuring local protection make-before-break :

• It is strongly recommended that Shared explicit be used on the backup tunnel such that the backup LSP and the primary LSP do not share resources
  
  
• Explicit IDs must be configured to distinguish the primary backup LSP from the replacement backup LSP.
  
  

  NOTE No backups are possible until Explicit IDs are configured for both the backup path and its replacement.

The shared explicit requirement is transparent to user configuration and is mentioned in the context of how IPriori handles make-before-break. The explicit configuration of primary and replacement backup LSP IDs must take place in order for any backup paths to be created for an Avici router.

Configuring Backup Path Primary and Backup Router IDs

The second piece necessary for backup tunnel make-before-break is a way of distinguishing the primary backup path from the replacement backup path. When make-before-break is performed on a regular traffic engineered tunnel, Traffic engineering changes the LSP ID for the replacement tunnel. This solution is not available to the backup tunnel because the backup tunnel already uses the primary LSP ID.

IPriori uses the FILTER-SPEC tunnel sender address to distinguish between the primary and replacement backup LSP IDs. To support make-before-break on backup tunnels, the PLR must have ownership of two distinct IP addresses that are unique within the MPLS domain, and must be globally unique if chosen from the public address space. If the PLR is also the primary LSP ingress, a third distinct IP address is required for signalling the primary LSP; this third IP address must also meet the same criteria as backup IP addresses.

To affect a reroute or bandwidth change on a backup tunnel, configure one of the PLR's available IP addresses to be used as the primary backup LSP ID; configure a second available IP address to be used as the replacement backup LSP ID.

The local-protect-router-ids command in traffic engineering command mode provides for the configuration of the primary and replacement backup LSP IDs for this PLR.

Example: In the following example the local-protect-router-ids command sets the primary backup path ID to 12.1.1.2 and the replacement backup path ID to 12.1.1.50 for this Avici router:

router(config)#mpls te ospf router(config-te)#local-protect-router-ids 12.1.1.2 12.1.1.50 router(config-te)end router#show local-protect-router-ids Primary router id = 12.1.1.2 Secondary router id = 12.1.1.50

Figure 5-7 "Make-Before-Break Backup Address Assignments" depicts the backup LSP ID assignments both before and after make-before-break.

Figure 5-7. Make-Before-Break Backup Address Assignments

Identifying Local Protect Signal Incapable Routers

The primary LSP needs to be able to determine when it is desirable to reroute the primary path. In order to do this it needs to know when local protection is inuse and which primary nodes are acting as PLRs. The local-protect-available and local-protect-inuse flags in the IPv4 and IPv6 address sub-objects of the Record Route Object (RRO) provide this information to the ingress. To permit proper ingress behavior it is important that the ingress be made aware of any primary LSP nodes that do not support the local-protect-available and local-protect-inuse flags. Detour draft only routers do not currently support these two flags. Use the local-protect-signal-incapable command in traffic engineering mode at the ingress to identify primary LSP routers that do not support these flags.

Example: In the following example the local-protect-signal-incapable command informs the PLR that router 50.1.0.1 is not capable of signaling the local-protect-available or local-protect-inuse flags:

router(config)#mpls te ospf router(config-te)#local-protect-signal-incapable 50.1.0.1 router(config-te)end router#show local-protect-signal-incapable 50.1.0.1 Router id 50.1.0.1 is not capable of signalling local protect

Enabling Local Protection

You must enable local protection for all potential Avici router PLRs. Use the local-protect command to enable local protection on a node. Local protection can be enabled from appropriate command modes specified in "Understanding Local Protection Parameter Precedence" on page 130. The appropriateness of a command mode depends upon whether the PLR is an ingress or midpoint router. Any node not enabled for local protection will not function as a PLR. Any non-ingress primary LSP node may function as a merge node regardless of whether local protection is enabled. Local protection can be enabled, disabled or not specified depending upon the option used.

Figure 5-8 "Interface and Node Protection w/ Local Protection Enabled/Disabled" displays a tunnel of four Avici routers (Ra - Rd):

• Ra and Rb are both local protection enabled.
  
  
• Rc is not enabled.
  
  
• Because Rd is the egress, it doesn't matter whether local protection is enabled.
  
  
• Ra is configured for Node Disjoint.
  
  

Figure 5-8. Interface and Node Protection w/ Local Protection Enabled/Disabled

This configuration provides the following possible local protection scheme:

• The backup path at Ra bypasses Rb, due to the configuration of node disjoint at Ra, and merges at Rc. The merge at Rc is possible because local protection enabled is not required for the merge node. This configuration protects against both an outbound link failure at Ra and a Node failure at Rb.
  
  
• The backup path at Rb merges at Rc.This configuration protects against an outbound link failure at Rb; it does not provide any protection against a node failure at Rc, because node disjoint is not configured at Rb.
  
  
• Local protection is not available at Rc, therefore, no backup path originates at Rc.
  
  

This configuration protects Ra from an outbound link failure and a node failure at Rb. Rb is protected from an outbound link failure. Rc is not protected at all.

Example 1: In the following example the local-protect enable command enables local protection for midpoint default mode and tunnel default:

router(config)#mpls te ospf router(config-te)midpoint default router(config-te-midpoint-default)#local-protect enable router(config-te-midpoint-default)exit router(config-te)tunnel default router(config-te-tunnel-default)local-protect enable router(config-te-tunnel-default)end router#show mpls te midpoint default . .      local-protect enabled . . router#show mpls te tunnel default . .      local-protect enabled . . router#

Example 2: In the following example the local-protect disable command disables local protection for midpoint default mode:

router(config)#mpls te ospf router(config-te)midpoint default router(config-te-midpoint-default)#local-protect disable router(config-te-midpoint-default)end router#

Example 3: In the following example the no local-protect command sets local protection as non-specified in tunnel default mode:

router(config)#mpls te ospf router(config-te)tunnel default router(config-te-tunnel-default)#no local-protect router(config-te-tunnel-default)end router#

Enabling Fast Reroute

Backup paths, also known as detours when signaled using the detour object, are distributively computed and established using the fast reroute and detour RSVP extensions. Fast reroute should be enabled on any Avici router ingress for which local protection is desired. Enabling fast reroute instructs the ingress to send out the fast reroute object within an RSVP path message. Any Detour draft LSP node that receives the fast reroute object, and is enabled for local protection, will attempt to set up a backup path. Upon receiving the fast reroute path message, the PLR performs a SPF computation using primary LSP information available to it. This SPF computation determines the closest backup path merge node, based upon the lowest total cost from the PLR to the primary LSP egress.

LSP nodes that do not support the fast reroute object, i.e. Bypass draft nodes, forward the fast reroute object downstream unchanged assuring that the setup of fast reroute signaled backup paths will be attempted at all LSP nodes that support the Detour Draft. A node that recognizes the fast reroute but for some reason is unable to establish a backup path will periodically re-attempt the backup path establishment. Fast reroute is only signaled on the primary LSP. The actual detour is signaled from the PLR using the detour object in a separate RSVP path message.

When a local protect enabled LSP node receives a path message containing the fast reroute object, IPriori attempts the backup path setup. The backup path is signaled by an RSVP path message containing the detour object and can traverse up to the maximum number of hops configured at the ingress before merging back into the primary LSP. The detour path message is transmitted out an outbound link other than the outbound link of the primary LSP, providing a bypass for an outbound link failure.

The PLR for this backup path uses the parameter information contained in the fast reroute object to set the values for bandwidth (base bandwidth for SPF bandwidth calculation), holding priority, reserving priority, maximum number of backup path hops, and administrative colors. The detour message contains the address of the sending node and merge node for the detour. Routers that do not support the detour object return a path error message back to the PLR, which causes the detour setup to fail. The sending router will then attempt to establish a simple backup path if setup failure occurs.

Figure 5-9. Fast-reroute Overview

Use the send-fast-reroute command at the ingress of the tunnel to be protected. Fast reroute can be enabled from appropriate command modes specified in "Understanding Local Protection Parameter Precedence" on page 130. The command can be set for enable, disable, or non-specified. Refer to "Understanding Enabled, Disabled, Non-Specified Command Options" on page 134 for further information. Because the send-fast-reroute command is only enabled at the ingress, configuration of the enable setting in tunnel or tunnel default command mode and the disable setting in midpoint default command mode at all LSP nodes will assure the correct setting is configured.

Example: In the following example the send-fast-reroute command is enabled in tunnel default mode and disabled in midpoint default mode for this ingress Avici router:

router(config)#mpls te ospf router(config-te)midpoint default router(config-te-midpoint-default)#send-fast-reroute disabled router(config-te-midpoint-default)exit router(config-te)tunnel default router(config-te-tunnel-default)send-fast-reroute enabled router(config-te-tunnel-default)end router#show mpls te midpoint default . . send-fast-reroute disabled . . router#show mpls te tunnel default . . send-fast-reroute enabled . .

Enabling Node Disjoint

Node disjoint provides backup path protection at the PLR for an immediate downstream node failure. Enabling node disjoint on all locally protected LSP nodes provides for backup path protection for both the PLR outbound link and an immediate downstream node failure. If the immediate downstream node from the PLR is the egress, IPriori ignores the node disjoint configuration.

Node disjoint is treated as though it were an SRLG with a bias of 1 for all links to the immediate LSP downstream node.

If node disjoint is not enabled, and the SPF calculation determines that the next primary LSP node provides the least total cost from the PLR to the primary LSP egress, the backup path will merge with the primary LSP at that next downstream node. In this case, the PLR will not be protected against an immediate down stream node failure unless a node upstream of the PLR provides a backup path bypassing the failed node. There are two reasons why you should attempt to avoid this situation:

1. You can not count on an upstream node providing a backup path that bypasses the node failure.
   
   
2. Because the PLR providing the backup path is some distance away, it takes a longer time for signaling to inform the appropriate PLR to activate the backup path. This time delay may be unacceptable.
   
   

Figure 5-10 "Node-disjoint Overview" displays a tunnel of four Avici routers (RTA - RTD) that depicts the following configuration:

• RTA, RTB, and RTC are local protection enabled.
  
  
• Because RTD is the egress, it doesn't matter whether local protection is enabled.
  
  
• RTA and RTC are configured for node disjoint. RTB is not configured for node disjoint
  
  

This configuration provides the following local protection scheme:

• The backup path at RTA bypasses RTB, due to the configuration of node disjoint at RTA, and merges at RTC. This configuration protects against both an outbound link failure at RTA and a Node failure at RTB.
  
  
• The backup path at RTB merges at RTC. This configuration protects against an outbound link failure at RTB; it does not provide any protection against a node failure at RTC, because node disjoint is not configured at RTB.
  
  
• The backup path at RTC merges at RTD, because RTD is the primary LSP egress and therefore node disjoint enabled at RTC is ignored.
  
  

Figure 5-10. Node-disjoint Overview

This configuration protects RTA from an outbound link failure and a node failure at RTB. RTB and RTC are protected from an outbound link failure. This configuration provides no protection for a RTC node failure.

Use the node-disjoint command in the appropriate command modes specified in "Understanding Local Protection Parameter Precedence" on page 130. The command can be set for enable, disable or non-specified. Refer to "Understanding Enabled, Disabled, Non-Specified Command Options" on page 134 for further information.

Example: In the following example the node-disjoint command is enabled in tunnel default mode and midpoint default mode for this PLR:

router(config)#mpls te ospf router(config-te)midpoint default router(config-te-midpoint-default)#node-disjoint enabled router(config-te-midpoint-default)exit router(config-te)tunnel default router(config-te-tunnel-default)node-disjoint enabled router(config-te-tunnel-default)end router#show mpls te midpoint default . . node-disjoint enabled . . router#show mpls te tunnel default . . node-disjoint disabled . .

Understanding Local Protection Bandwidth Allocation

There are three types of configurable local protection bandwidth:

spf bandwidth	The bandwidth used for the computation of the backup path
reserve bandwidth	The bandwidth that is taken out of use once a backup path is signaled. This bandwidth is immediately available should a backup path become active.
on-failure bandwidth	The bandwidth that is resignaled on failure.

Each local protected bandwidth is configured as a percentage of an already established bandwidth value. A local protection bandwidth calculation uses a different criteria depending upon:

• Which type of bandwidth is being configured
  
  
• Whether the bandwidth is configured at an ingress or midpoint PLR
  
  
• Whether fast reroute is enabled
  
  

The following sections detail each bandwidth one at a time.

Configuring Backup Path SPF Bandwidth

Local protection uses the SPF bandwidth when performing the SPF backup path computation. Use the protect-bandwidth spf command to configure SPF bandwidth in the appropriate command modes specified in "Understanding Local Protection Parameter Precedence" on page 130. The actual SPF bandwidth value is determined as follows:

• If SPF bandwidth is calculated at the ingress, the SPF bandwidth value is determined by multiplying tunnel bandwidth by the percentage set in the command.
  
  
• If fast reroute is enabled at the ingress, the calculated ingress SPF bandwidth is signaled to midpoints in the fast reroute object. The SPF bandwidth configured at the ingress becomes the base backup path SPF bandwidth for all midpoint PLRs. This base value is modified at each midpoint PLR by multiplying the base backup path SPF bandwidth by the percentage set in the protect-bandwidth spf command at the midpoint PLR. for example: to set the midpoint backup path SPF bandwidth to be the same as the ingress SFP bandwidth, configure the protect-bandwidth spf command for 100% at the midpoint; to set the midpoint backup path SPF bandwidth to 80% of the base backup path SPF bandwidth, configure the protect-bandwidth spf command for 80% at the midpoint.
  
  
• If fast reroute is not enabled, each PLR whether midpoint or ingress determines the backup path SPF bandwidth by multiplying the tunnel bandwidth by the percentage configured in the protect-bandwidth spf command.
  
  

Example: In the following example SPF bandwidth is configured at a primary LSP midpoint:

• The midpoint default command changes the command mode to traffic engineering midpoint default.
  
  
• The protect-bandwidth spf command sets the bandwidth used to calculate the backup tunnel at 100 percent of the configured ingress SPF bandwidth for this fast reroute enabled tunnel.
  
  
• The show mpls te midpoint default command displays the new setting:
  
  

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)# protect-bandwidth spf 100 router(config-te-midpoint-default)#end router#show mpls te midpoint default . . protect-bandwidth spf 100 . .

Configuring Backup Path Reserve Bandwidth

Local Protection uses the reserve bandwidth to determine how much bandwidth is taken out of current use and set aside for use by the backup path should it become active. Reserve bandwidth allows for the setup of a backup path with all or part of the bandwidth required by the active backup path. When local protection is activated at a PLR with reserve bandwidth configured above zero percent, the backup path is immediately available with the amount of reserved bandwidth. If reserve bandwidth is configured for less than 100 percent of the configured on-failure bandwidth, IPriori signals a make-before-break backup path with the configured on-failure bandwidth upon a failure (when backup becomes in-use). Once fully signaled, data is transferred from the backup path based upon the original reserve bandwidth to the on-failure bandwidth backup path.

Use the protect-bandwidth spf reserve command to configure reserve bandwidth in the appropriate command modes specified in "Understanding Local Protection Parameter Precedence" on page 130. The reserve bandwidth value is determined by multiplying the configured SPF bandwidth for this PLR by the percentage set in the protect-bandwidth spf reserve command.

You can set reserve bandwidth to zero in order to maximize the use of available bandwidth in the network. The drawback to setting the reserve bandwidth to zero is that the backup tunnel will not have any bandwidth associated with it until it is signaled with the on-failure bandwidth setting at activation.

Example: In the following example reserve bandwidth is configured at a primary LSP midpoint:

• The midpoint default command changes the command mode to traffic engineering midpoint default.
  
  
• The protect-bandwidth spf reserve command sets the bandwidth set aside for when the backup path becomes active at 25 percent of the SPF bandwidth configured for this PLR.
  
  
• The show mpls te midpoint default command displays the new setting:
  
  

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)# protect-bandwidth spf 100 reserve 25 router(config-te-midpoint-default)#end router#show mpls te midpoint default . . protect-bandwidth spf 100 reserve 25 . .

Configuring Backup Path On-Failure Bandwidth

Local Protection uses the on-failure bandwidth to determine the actual bandwidth used by an active backup path. On-failure bandwidth does not come into play until a backup path is activated. If the reserve bandwidth is configured for the same value as the on-failure bandwidth, the desired backup path is immediately available upon activation of local protection for this PLR. If the reserve bandwidth value is less than the value configured for on-failure bandwidth, local protection signals a new make-before-break backup path using the on-failure bandwidth value. When completely signaled backup traffic is transferred to the new backup path from the old active backup path.

Use the protect-bandwidth spf reserve on-failure command to configure on-failure bandwidth in the appropriate command modes as specified in "Understanding Local Protection Parameter Precedence" on page 130. The on-failure bandwidth value is determined by multiplying the configured SPF bandwidth for this PLR by the percentage set in the protect-bandwidth spf command.

Example: In the following example reserve bandwidth is configured at a primary LSP midpoint:

• The midpoint default command changes the command mode to traffic engineering midpoint default.
  
  
• The protect-bandwidth spf on-failure command sets the bandwidth actually used by an active backup path as 100 percent of SPF bandwidth. There will be 1 second between multiple backup path setups with a jitter of 20 percent.
  
  
• The show mpls te midpoint default command displays the new setting:
  
  

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)# protect-bandwidth spf 100 reserve 25 on-failure 100 1 jitter 20 router(config-te-midpoint-default)#end router#show mpls te midpoint default . . protect-bandwidth spf 100 on-failure 1 jitter 20 . .

Configuring Maximum Number of Hops

The protect-max-hops command allows for the configuration of the maximum number of hops allowed for a backup path. If fast reroute is enabled, this value is signaled in the fast reroute object for all Detour draft nodes. If fast reroute is not enabled or the node is a Bypass draft node, the backup path maximum hop value is the locally configured value and is only used by the local backup path. The maximum number of backup path hops are configured in the appropriate command modes as specified in "Understanding Local Protection Parameter Precedence" on page 130.

Example: In the following example the protect-max-hops command sets the maximum number of hops for a backup path at this PLR for 7 in midpoint default mode:

router(config)#mpls te ospf router(config-te)midpoint default router(config-te-midpoint-default)#protect-max-hops 7 router(config-te-midpoint-default)end router#show mpls te midpoint default . . protect-max-hops 7 . .

Configuring Backup Path Holding and Reserving Priority

The protect-holding-priority command specifies the priority used when protecting the backup path from preemption by other backup paths or LSPs. A value of 0 specifies the highest priority and protects this backup path from preemption by all other backup paths or LSPs. A value of 7 specifies the lowest priority and allows all backup LSPs or primary LSPs with a higher priority to pre-empt this backup path. If the holding priority for an existing backup path or LSP is the same as the reserving-priority for a new backup path or LSP, the existing backup path is not pre-empted. The system default for protect holding priority is 7.

The protect-reserving-priority command specifies the priority used when setting up a backup path. A value of 0 specifies the highest priority and enables this backup path to pre-empt all other backup paths or LSPs except those with a holding priority of 0. A value of 7 specifies the lowest priority and does not enable the new backup path to pre-empt any existing backup paths or LSPs. The system default for reserving priority is 7.

For both protect holding and reserving priority, if fast reroute is enabled, the signaled value in the fast reroute object is used for all Detour draft nodes. If the FAST-REROUTE object is not available in the PATH message, or the node is a Bypass node, the value used is the locally configured value and is only used by the local backup path.

Protect holding and reserving priority are configured in the appropriate command modes as specified in "Understanding Local Protection Parameter Precedence" on page 130.

Example 1: In the following example, the protect-reserving-priority command sets the reserving priority for backup paths to 1, and the show mpls te midpoint default command displays the setting:

router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)#protect-reserving-priority 1 router(config-te-midpoint-default)#end router#show mpls te midpoint default . . . protect-reserving-priority 1 . . .

Example 2: In the following example, the protect-holding-priority command sets the holding priority for backup tunnels to 1, and the show mpls te midpoint defaults command displays the setting:

router(config)#mpls te ospf router(config-te)#midpoint defaults router(config-te-midpoint-default)#holding-priority 1 router(config-te-midpoint-default)#end router#show mpls te midpoint default . . . protect-holding-priority 1 . . .

Configuring Backup Path Administrative Colors

The local protection administrative color commands function the same as primary LSP administrative colors, with the exception that configured colors only apply to backup paths. Any configured administrative color can be included in or excluded from the backup path.

Administrative colors identify specific interfaces. The protect-include-administrative-color command specifies administrative colors or administrative color-lists. The backup path can only use interfaces associated with specified administrative colors. The system default for include administrative color is to include all administrative colors. Use the protect-include-
administrative-color disable command to disable the inheritance of the primary LSP include-administrative-color configuration for backup paths.

The protect-exclude-administrative-color command specifies administrative colors or administrative color-lists. Interfaces associated with specified administrative colors are excluded from this backup path. The system default for exclude administrative color is not to exclude any administrative colors. Use the protect-
exclude-administrative-color disable command to disable the inheritance of the primary LSP exclude-administrative-color configuration for backup paths.

Administrative colors are signaled in the FAST-REROUTE object or configured in the appropriate command modes as specified in "Understanding Local Protection Parameter Precedence" on page 130.

Configuring Local Protection Resilience and Adaptivity

The same options and capabilities available for primary LSP resilience and adaptivity are available for local protection resilience and adaptivity. For resilience, options include: disabled, pacing, sorted-pacing, and linear. For adaptivity, options include: disabled, pinned, periodic, linear spf, reroute. Two different commands are available so that IPriori can distinguish whether the configuration is for the primary or backup LSP. Configure local protection resilience at each PLR using the protect-resilience command. Configure local protection adaptivity at each PLR using the protect-adaptivity command.

Local protection resilience and adaptivity can be configured in the appropriate command modes as specified in "Understanding Local Protection Parameter Precedence" on page 130.

Example 1: In the following example, the protect-adaptivity linear spf command configures the backup tunnel to:

• Recompute backup paths that have a reservation of 50 Mb/sec., using a 3 second timer, then
  
  
• Recompute backup paths that have a reservation of 45 Mb/sec., using a 10 second timer, then
  
  
• Recompute backup paths that have a reservation of 40 Mb/sec., using a 20 second timer, then
  
  
• Recompute backup paths that have a reservation of 30 Mb/sec., using a 180 second timer, then
  
  
• Recompute backup paths that have a 0% reservation, using a 600 second timer.
  
  
• Reroute those backup paths that have discovered a better path starting with those backup paths that have a 100% reservation and using a 0 second (no delay) timer,
  
  
• Reroute those backup paths that have discovered a better path ending with those backup paths that have a 0% reservation and using a 60 second timer.
  
  
• Add or subtract a jitter of 25% of the specified timers to prevent backup paths of the same size from attempting to recompute at the same time.
  
  

router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)#protect-adaptivity linear spf 50 3s 45 10s 40 20s 30 180s 0 600s reroute 100% 0s 0% 60s jitter 25% router(config-te-midpoint-default)#end router#show mpls te midpoint default . . .         protect-adaptivity linear spf 50 3000ms 45 10000ms 40 20000ms 30 180000ms 0 600000ms reroute 100% 0s 0% 60000ms jitter 25% . . .

Example 2: In the following example, the protect-resilience linear command configures the tunnel to re-establish LSPs starting with the largest reservation amounts and their associated timers and ending with the smallest reservation amounts and their associated timers:

router(config)#mpls te ospf router(config-te)#midpoint default router(config-te-midpoint-default)#protect-resilience linear 590m 5s 311m 20s 62m 40s jitter 10% router(config-te-midpoint-default)#end router#show mpls te midpoint default . . . protect-resilience linear 590m 5000ms 311m 20000ms 62m 40000ms jitter 10% . . .

Configuring Primary LSP Resilience Once Backup Path is Inuse

IPriori allows for the configuration of a separate primary LSP resilience to be used by the primary LSP once a backup path is in use. Because the backup path provides a means of getting around the primary LSP failure, moving traffic to a new primary LSP is not as urgent as it is for a non-protected LSP, but it is still necessary to move traffic to a new primary LSP prior to adaptivity. The inuse-resilience command provides the same capabilities and options available for the resilience command once any primary LSP backup path is in-use.

Example: In the following example, the inuse-resilience linear command configures the tunnel to re-establish LSPs starting with the largest reservation amounts and their associated timers and ending with the smallest reservation amounts and their associated timers:

router(config)#mpls te ospf router(config-te)#tunnel oc12toBos router(config-te-tunnel)#inuse-resilience linear 590m 8s 311m 25s 62m 50s jitter 10% router(config-te-tunnel)#end router#show mpls te tunnel tunnel oc12toBos . . . resilience linear 590m 8000ms 311m 25000ms 62m 50000ms jitter 10% . . .

Configuring Shared Risk Link Groups

When configuring backup paths, it is important that a link or node that shares the same failure risk as the link or node being backed up not be part of the backup path, if it can be avoided. Links and nodes that have common failure points can be grouped in Shared Risk Link Groups (SRLG). The purpose of SRLGs is to limit the chances that the same failure which caused the primary LSP failure will also cause the backup path to fail. This is accomplished by adding an additional cost to the TE metric if cost is specified for the SRLG or by assuring that the final cost will be greater than all possible TE metric combinations if bias is specified for the SRLG.

An SRLG may be made up of such groupings as all interfaces that run through the same fiber conduit, use the same power source, or share the same module as a given link or node.

During the signaling of a backup path, SRLG members of the same SRLG as the failure link or node being backed up will be considered for the backup path based upon the additional TE metric cost or bias associated with that group. Lower cost, non-SRLG member links, will be considered ahead of the higher cost SRLG member links. Because it is always possible that the point of failure will be something other than the specific SRLG failure risk, it is desirable to allow SRLG members to be in backup paths. Should an alternative (non-SRLG member, lower cost) link not be available when signaling a backup path, the members that share the SRLG with the point of failure will then be considered for the backup path, but in the case of a biased member, the resulting backup path will not be included in the information that determines whether a primary LSP is fully protected, and therefore, IPriori will view the primary LSP as being not fully protected. Should adaptivity discover a fully protected primary, traffic will move to that new primary LSP.

Keep in mind, it is possible to have a non-SRLG-member link with a higher cost than an SRLG member link. In this case, the SRLG member link will be used.

SRLGs are configured per router, but additional SRLG cost or bias is configurable per tunnel, parameter set, or default type.

An SRLG is always identified by a decimal number, and optionally by an alpha-numeric name. Because of the ability to assign cost or bias to a range of SRLGs, it is recommended that you use a numeric ID. The alpha-numeric name ID and the ability to associate it with the numeric ID is provided for compatibility with other routers.

There are configuration restrictions associated with using both name and number SRLG IDs. You can associate a name with a number before you actually modify an SRLG by adding links or nodes to it. If the SRLG is not yet modified, you can delete a name and number association by using the no srlg-name command, or overwrite a name/number association by reentering the srlg-name command with the new association. Once an SRLG has been modified by adding links or nodes to it, you must first delete the SRLG using the no external-srlg command before either deleting or overwriting an SRLG name/number association.

SRLG members can be specified as the network address of a broadcast interface (i.e. Gigabit ETHERNET), a router ID, or both ends of a point-to-point link. In the case of a network address of a broadcast interface or router ID, all interfaces coming to that address are members of the SRLG. In the case of specifying a point-to-point link, only that link is added to the SRLG. In order for an SRLG member to affect the cost of a backup path configuration, the link or node under consideration must be a member of the same SRLG as the first primary LSP hop from the PLR to the next node. For example, in Figure 5-11, link 50.10.0.1 to 25.10.0.1 is the failed hop between the PLR and the next node. Link 50.10.0.5 to 150.10.0.1 is a member of the same SRLG (SRLG 1). Therefore, the SRLG cost of 10 is added to the TE metric cost when considering the link for the backup path.

NOTE If from A and from A to B is configured, where A is a router ID, the cost is counted twice, once for the link and once for the node. This is only true if the router ID and the link interface have the same address

IPriori provides for the local configuration for all SRLGs in the network.

Configuration of SRLGs is a three step process:

1. Specify the cost or bias associated with a particular SRLG or range of SRLGs using srlg cost or srlg bias commands. These additional costs are added to the TE metric when signaling the backup path.
   
   
2. Enter the external SRLG command mode using the external-srlg command.
   
   
3. Within the appropriate external SRLG command mode, enter the link or node to be added to this SRLG using the from or from ... to ... command.
   
   

When naming an SRLG, an alpha numeric name is associated with a number. It is recommended that SRLGs that share a common cost or bias be assigned within a range to take advantage of assigning SRLG costs by ranges.

Figure 5-11 "SRLG Cost Example", displays a failure at interface 50.10.0.1. Because node disjoint is configured at RTA, all links to RTB are biased for 1. This means that the total cost of these links will be above any possible combination of non-biased link costs. The failure point belongs to SRLG 1 which contains the failure link and one other link shared by the module: 50.10.0.5 - 150.10.0.1. SRLG 1 adds a cost of 10 to these links. This means that the lowest cost set of links able to create a backup path from RTA to the merge at RTC are links 50.10.0.6 - 150.10.0.3 and 150.10.0.2 - 100.10.0.2. for a total cost of 20.

Figure 5-11. SRLG Cost Example

Copyright © 2002 Avici Systems Inc.
Avici® and TSR® are registered trademarks of Avici Systems Inc.
IPriori™ and SSR™ are trademarks of Avici Systems Inc.

   Source File Name: LocalProtectConfiguration.fm
    HTML File Name: LocalProtectConfiguration.html
    Last Updated: 05/30/02 at 14:10:02

Please email suggestions and comments to: doc@avici.com