wdiff draft-atlas-rsvp-local-protect-interop-01.txt draft-atlas-rsvp-local-protect-interop-02.txt

Internet Draft Alia Atlas (Avici Systems)
Expires: January 2002 Curtis Villamizar
- Avici Systems

Caren Litvanyi
- Qwest Communications

July May 20002 Markus Jork (Avici Systems)

November 2001

MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute

draft-atlas-rsvp-local-protect-interop-01.txt

draft-atlas-rsvp-local-protect-interop-02.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

Routers implementing

Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute-
00.txt, leaves several areas with future work required. One of those
areas is the merging rules for detour LSPs. This draft describes
some of the issues with the merging rules presented in draft-ping-
rsvp-fastreroute-02.txt and proposes a solution which also enhances
interoperability.

The implementation of detour LSPs described in draft-ping-rsvp-
fastreroute-00.txt results in intermittent backup availability. A
detour LSP will become temporarily unavailable when other detours
with different EROs are merged into it; local protection enhancements given in
[draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage will become
temporarily unavailable if re-optimization of a backup path is clarified in
[draft-swallow-rsvp-bypass-label-01.txt],
implemented.

This draft describes examples of the above problems and routers implementing
solely [draft-gan-fast-reroute-00.txt] proposes a
solution. The solution also resolves issues with merged backups
which do not interoperate to provide
local protection. Those routers which follow the guidelines given in
this draft should be able adequate protection, due to interoperate with either type the use of
implementation. SRLGs.
The guidelines solution also specify how to support make-
before-break with finds backup LSPs. paths in some topologies where a
detour LSP could not be found, in the merging rules in draft-ping-
rsvp-fastreroute-00.txt were followed.

Recommended behavior for supporting a revertive mode for local
protection is specified.

Contents

1. Introduction .............................................. ............................................... 3
2. Terminology ............................................... Backup Availability ........................................ 3
3. Ingress Support ........................................... Backup Does Not Provide Protection ......................... 4
3.1 Requesting Local Protection .............................. Selected ERO Merges at PLR ................................ 4
3.2 Detecting Protection Information ......................... Selected ERO Uses SRLG .................................... 5
3.3 No Backup Path For Detour LSP ............................. 5
4. PLR Behavior .............................................. Solution to Problems with Merging Rules .................... 6
4.1 Selecting Backup LSP Type ................................ 7
4.2 Bypass Tunnels ........................................... 8
4.3 Make-Before-Break on Backup Tunnels Detour Object Need Not be Understood ...................... 8
4.3.1 Shared-Explicit and Backup LSPs ........................ 9
4.3.2 7
5. Make-Before-Break with Sender Addresses ................ .......................................... 7
6. Revertive Behavior: Recovery from Failure .................. 9
4.4 Catching ResvTears and Appropriate PathErrs ..............
6.1 Local Failure ............................................. 10
4.5 Handling Resource Preemption ............................. 11
5. Merge Node Behavior ....................................... 11
5.1 Label Space .............................................. 11
5.2 Ignore Path Tears Unless From Ingress .................... 11
5.3 Simple and Detour Backup LSPs ............................ 12
5.4 ResvTears ................................................ 12
6.
6.2 Remote Failure ............................................ 10
7. Security Considerations ................................... 13
7. References ................................................ 13 .................................... 10
8. Reference .................................................. 10
9. Authors' Addresses ........................................ 14 ......................................... 11

1. Introduction

Routers may implement the local protection enhancements given in
[RSVP-TE], whose usage

Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute-
00.txt, leaves several areas with future work required. One of those
areas is clarified in [BYPASS], but not implement
[DETOUR]. Routers may also implement [DETOUR] without implementing the local protection enhancements given in [RSVP-TE]. These two sets
of routers will not interoperate to provide local protection. merging rules for detour LSPs. This draft assumes that a router falls into one describes
some of the following
three sets:

A. Implements both issues with the local protection enhancements given merging rules presented in
[RSVP-TE] draft-ping-
rsvp-fastreroute-02.txt and [DETOUR] as described in this draft.

B. Implements only [DETOUR].

C. Implements only the local protection enhancements given in
[RSVP-TE], according to the guidelines in [BYPASS]. proposes a solution which also enhances
interoperability.

The guidelines given implementation of detour LSPs described in this draft should allow routers [FAST-REROUTE] results
in set intermittent backup availability. A to
interoperate with either of the detour LSP will become
temporarily unavailable when other two sets of routers, but not
both. A network detours with routers in set A and set B will be able to
provide different EROs are
merged into it; local protection. A network with routers in set A and set C protection will be able to provide local protection. A network that contains
routers from both set B become temporarily unavailable
if re-optimization of a backup path is implemented.

This draft describes examples of the above problems and set C will proposes a
solution. The solution also resolves issues with merged backups
which do not be able to provide local
protection adequate protection, due to the use of SRLGs.
The solution also finds backup paths in some cases involving paths with topologies where a mix of
detour LSP could not be found, in the two types
of routers, irrespective of merging rules in [FAST-REROUTE]
were followed. Finally, the presence or absence of routers from
set A.

This draft also describes a modification solution allows make-before-break to identifying work
on detour LSPs
specified without causing the protection to become temporarily
unavailable.

Recommended behavior for Shared-Explicit which distinguish between primary and
backup bandwidth reservations. This supporting a revertive mode for local
protection is necessary to support make-
before-break on backup tunnels; how specified.

2. Backup Availability

In order for local protection to support make-before-break on
backup tunnels is described.

More details on handling PathErrs and resource preemption be useful in mission-critical
networks, it is
provided.

2. Terminology important that local protection, once created at a
PLR (Point-of-Local-Repair): Any node along the for a given primary LSP's path is LSP, remains available at all times until a potential PLR. A node becomes an active PLR when it takes action
single fault has occurred. That fault could be physical or due to transfer traffic from
resource preemption and could occur on either the primary LSP to a or the
backup tunnel LSP.

The fault against which the backup protects could occur at any time,
including when a
failure the backup is locally detected. When discussed temporarily unavailable. Similarly, at
any time, traffic could be running across a backup - if it becomes
temporarily unavailable then, traffic loss will result.

The following example demonstrates a case when following the merging
rules given in examples, [FAST-REROUTE] result in the backup becoming
temporarily unavailable. In this example, the
specific potential PLR of interest is the node backup
which originates is temporarily unavailable is not aware that the
specific backup tunnel under discussion.

Backup Tunnel: A is not
functional during that period.

[R1]----[R2]----[R3]----[R4]--R5]
| \ / | /
[R6]-------[R8]----------[R9]

Primary: R1-R2-R3-R4-R5
R2 backup: R2-R8-R9-R4
R3 backup: R3-R8-R9-R5

Figure 1: New Detour Causes Existing Detour to Fail

Assume that due to setup timing, R2's backup tunnel is logically created from first. Then
when the PLR detour from R3 tries to a be created, R8 must merge node on the primary LSP's path; which specific merge node is
used can vary between two
detours together. According to the backup LSPs contained merging rules in [FAST-REROUTE],
R8 must select the backup tunnel.
The backup tunnel can contain one or more backup LSPs for a given
primary LSP. The concept of ERO to R3's backup. When R8 does so, there is a
period when the backup tunnel permits make-before-
break for backup LSPs.

Backup LSP: A backup LSP extends from its origin at R2 was "up" but isn't actually available
unless R8 and R9 deal with changing the PLR to ERO in a
specific merge node, where it rejoins make-before-break
fashion.

The same problem will occur when and if the primary LSP. A backup LSP from R3 is part of a torn
down. Tearing down R3's backup will make R2's backup temporarily
unavailable.

3. Backup Tunnel. Does Not Provide Protection

There are three types examples of backup LSPs -
simple, detour and unsignalled.

Simple Backup LSP: A Simple Backup LSP is where the merging rules given in [FAST-
REROUTE] result in either a backup final detour LSP whose PATH
message which does not include the DETOUR object. The provide
protection against failure or in no detour LSP being created.

3.1 Selected ERO contains the
selected backup path to Merges at PLR

In the merge node and then an exact duplicate of following example, the primary LSP's ERO from merging rules in [FAST-REROUTE] require
that merge node to the egress.

Detour Backup shorter ERO be selected.

[R1]--[R2]----[R3]----[R4]---------------[R5]--[R6]--
\ | |
\ [R7] [R8]
\ | \ |
\ | \ |
------[R9]--[R10]--[R11]--[R12]---[R13]

Primary LSP: A R1-R2-R3-R4-R5-R6-....
R1's Backup: R1-R9-R10-R7-R3-R4-R5-R6-....
R3's Backup: R3-R7-R9-R10-R11-R12-R13-R8-R5-R6-...

Figure 2: No Protection for PLR Because Merged Detour Backup LSP is a Ends at PLR

In this example, R9 must merge R1's backup LSP whose PATH
message includes and R3's backup. Because
the DETOUR object. The shorter ERO simply contains the
selected must be chosen, R9 would select R1's backup's ERO;
clearly R3 would not have an effective backup path to the in this case.

This problem could be resolved by adding a merge node.

Bypass Tunnel: A tunnel rule which removes
any ERO from consideration which merges with the PLR of interest to primary LSP at a specific merge
node through which traffic across unsignalled backup LSPs can be
passed. This is used as defined in [BYPASS].

Unsignalled Backup LSP: An Unsignalled Backup LSP can only exist if
there is an appropriate bypass tunnel. This bypass tunnel is used so
that the Unsignalled Backup PLR for any detour LSP is logically one hop away from the
merge node. No RSVP signalling is done to create or indicate being merged.

3.2 Selected ERO Uses SRLG

In the
existence of following example, the Unsignalled Backup LSP. The Unsignalled Backup LSP selected ERO uses the label provided by the merge node, via the Label sub-object,
to forward traffic a link which belongs
to an SRLG which one of the merge node, as described in [BYPASS].

Fully Protected: A primary merged detour LSPs was avoiding.

[R1]-----[R2]-----[R3]-------[R4]
\ | / |
-----[R5]------[R6]----[R7] |
| |
[R8]---[R9]--|

Primary LSP: R1-R2-R3-R4
R1's Backup: R1-R5-R6-R7-R4
R2's Backup: R2-R5-R6-R8-R9-R4
SRLG contains: R2-R3 and R6-R7

Figure 3: Merged Detour LSP is considered to be fully protected
when each potential PLR in its path has Uses a current backup tunnel
available.

3. Ingress Support

3.1 Requesting Local Protection

The [DETOUR] and [BYPASS] propose different methods for the ingress Link Avoided Due to signal that an LSP desires local protection. These methods are
not mutually incompatible. The ingress must both include the
FAST_REROUTE object in SRLG

In the PATH message and set above figure, the two flags, "Label
Recording desired" and "Local Protection desired", merging rules in [FAST-REROUTE] mean that R5
will select the
SESSION_ATTRIBUTE object[RSVP-TE].

By including the FAST_REROUTE object, any nodes on ERO associated with R1's backup. Unfortunately, that
means that the primary merged detour LSP
which implement [DETOUR] will know that not protect against the primary LSP requires
protection. By setting failure
of R2-R3 because the "Local Protection desired" flag link R6-R7 is used in the
SESSION_ATTRIBUTE object, any nodes which implement [BYPASS] will
know that the primary final merged detour
LSP requires protection. The FAST_REROUTE
object provides constraints on the backup tunnel; those constraints
can be configured solely at the primary tunnel's ingress and can
differ easily differ between primary LSPs.

If the ingress sets the "Label Recording desired" flag in the
SESSION_ATTRIBUTE, the resulting Label subobjects R6-R7 and R2-R3 are in the RRO permit
those PLRs which implement [BYPASS] to create Unsignalled a common SRLG.

3.3 No Backup
LSPs. If there are nodes Path For Detour LSP

The CSPF rules given in [FAST-REROUTE] require that the primary LSP's backup path which do not
understand Label subobjects and do not ignore the unrecognized
subobjects, as they SHOULD according to [RSVP-TE], then the ingress
should not set the "Label Recording desired" flag in the SESSION
ATTRIBUTE. If this flag is
selected does not set, the interoperability affected
will be with routers which only support Unsignalled Backup LSPs.
This must be cross a configured option at the ingress. It is assumed that
the network operator knows whether routers in the network support
LRO, don't support but correctly ignore request for LRO, or handle
the LRO link in violation of the specification.

3.2 Detecting Protection Information

The primary tunnel's ingress is responsible for determining when
rerouting of same direction as the primary path is desirable. For instance, if local
protection
LSP does. This is in use on the current primary LSP, it would be
desirable to compute a new primary LSP.

The ingress must also determine avoid merging problems when to move from a current detour LSP to a
new LSP, via make-before-break. For instance, it will take time
before a newly created
intersects its primary LSP will and yet should not be fully protected. If merged. However,
this can result in the
new primary LSP were to be created lack of protection, due to a configuration change or
adaptation to network changes, then the ingress might wait to move
traffic to the new primary LSP until that is fully protected.
Alternatively, if the new primary LSP were to be created because
local protection is lack of paths, as
described in use on the current primary LSP, the ingress
may move traffic immediately following example.

[R1]--[R2]--[R3]--[R4]
| / | |
| / | |
[R5]--[R6]--[R7]---------|
Primary: R5-R6-R7-R2-R3-R4
R2 Backup: R2-R6-R7-R4
[R2]-[R7] has insufficient bandwidth to the new primary LSP or it may wait
until the new primary support R2's backup

Figure 4: Detour LSP is as locally protected along its path uses same link as
the current primary LSP is.

For both of the reasons above, upstream from PLR

In the ingress must know what nodes along
an LSP's path above example, there are currently providing local protection and which two possible ways for R2 to have
that local protection in use. The "Local protection available" and
"Local protection in use" in the IPv4 address and IPv6 address
subobjects of the RRO [RSVP-TE] provide a
backup. Either, it can use R2-R6-R7 or it can use R2-R7. In this
scenario, the necessary information link R2-R7 does not have sufficient free bandwidth to
admit the ingress. backup LSP.

4. Solution to Problems with Merging Rules

The ingress may problems with the merging rules can be notified that local protection is in
use via solved by using a PathErr message with an error code
different SENDER_TEMPLATE for each backup LSP, instead of "Notify"(25) using the
primary's SENDER_TEMPLATE, and an
error value of "Tunnel locally repaired"(3) by nodes implementing
[BYPASS].

Routers implementing only [DETOUR] without the local protection
enhancements given in [RSVP-TE] may not set the "Local protection
available" and "Local protection in use" flags in merging Path messages with
different EROs.

First, consider the IPv4 and IPv6
address subobjects solution of the RRO.

To permit the ingress behavior described early in this section, the
ingress should be configured with information about which nodes
implement only [DETOUR] and, therefore, do not support a means merging Path messages with
different EROs. This alone appears to
indicate that local protection is available at that node. Such nodes
can be ignored at resolve all three of the ingress
issues described in any decision regarding whether the
protection is fully available (it must be assumed that protection is
available for any such node Section 3. However, simply not merging Path
messages with different EROs introduces other problems when any RSVP RESV arives).

4. PLR Behavior

Once an ingress or midpoint node has determined that a given all
detour LSPs for the same primary LSP is
requesting local protection, that node, acting in have the role of a PLR,
must determine same SENDER_TEMPLATE.

Consider the link(s) and/or node(s) that third issue described where the backup tunnel path must
avoid. Then, cross
and use the PLR must determine same link as the backup path primary LSP. Not merging the detour LSP
and merge node.
Finally, the PLR must determine what type of backup primary LSP leads to use and
create it.

A link or node could fail for a variety of reasons. Links for which
failure may be correlated are determined through the use of Shared
Risk Link Groups (SRLGs). SRLGs may be signaled via [GMPLS IS-IS]
and [GMPLS OSPF]. The PLR can inability to determine what SRLGs are present
through this signaling or through configuration at each node of all
SRLGs in the entire network.

Some routers may support only signaled SRLGs and therefore SRLG
signaling must be originated. Some routers may only support
configured SRLGs and therefore cannot originate signaled SRLGs and
therefore the ability whether a
PathErr belongs to configure SRLGs for external links must be
supported.

4.1 Selecting Backup the Primary LSP Type

The PLR may decide or to create a backup Backup LSP either when it has received through the primary LSP's PATH message or after it has received LSR
with the primary
LSP's RESV message. The latter case is required if unsignalled
backup paths are desirable. The former case is reasonable same next hop. Figure 4 demonstrates the problem with this
partial solution.

In Figure 4, if most
LSPs are expected the link from R7-R4 breaks, R7 will send a PathErr to be created successfully
R6. If the SENDER_TEMPLATE for the Primary LSP and if for R2's Backup
LSP were the ERO is
primarily strict hops, so that a reasonable merge node can same, then R6 would be
determined.

To unable to determine which type of backup whether the
PathErr was for the Primary LSP to create, or for R2's Backup LSP. This is the PLR must infer
what type of routers
problem with not merging Path messages with different EROs when
detour LSPs share the local domain. same SENDER_TEMPLATE.

To further elaborate, consider Figure 5 below, when one tries to NOT
merge Path messages for detour LSPs with different EROs but with the
same next link/hop.

[R1]--[R2]--[R3]--[R4]
\ | | /
\ | | /
[R5]---[R6]

Primary : R1-R5-R6-R4
R1's Backup: R1-R2-R3-R6
R5's Backup: R5-R2-R3-R4

Figure 5: OverMerging Backup LSPs

If the other routers
implement [BYPASS], then either a simple SENDER_TEMPLATES for R1's backup LSP or an unsignalled and R5's backup LSP should be created. If are the other routers implement
[DETOUR], same,
then a detour backup LSP should be created.

If the PLR is to create RESV received for one would have a FILTER_SPEC which would
match both R1's backup LSP when it has received and R5's backup. Because the primary
LSP's PATH message, then SENDER_TEMPLATEs
are the PLR must determine same and the type of Detour object is not included in the RESV, there
is no way at R2 to distinguish a RESV for R1's backup
LSP based upon from a RESV for
R5's backup.

From the inferred type preceeding, there are two alternatives if merging of Path
messages with different EROs is not desired (as demonstrated via
Figure 1). Either, the ingress. If the primary's
PATH Detour object must be included in every Path,
Resv, PathErr, ResvErr, PathTear, ResvTear, and ResvConf message contains a FAST_REROUTE object, it
which is assumed that other
routers will support for the [DETOUR]. The PLR will attempt to create a detour backup LSP. If no FAST_REROUTE object is found LSP or if the SENDER_TEMPLATEs for detour creation LSPs
must be different. The former alternative is rejected, as indicated by a PathErr with essentially expanding
the error
code "Unknown object class", then SENDER_TEMPLATE to include the Detour object.

The recommendation is to simply use a simple backup LSP can be
attempted. different SENDER_TEMPLATE. The latter case can only occur
"IPv4 tunnel sender address" in a mixed network where the ingress supports [DETOUR] but a node along the selected backup
path does not. In this case, SENDER_TEMPLATE MUST contain an
IP address of the PLR.

A backup LSP must MUST be resignaled
without a DETOUR object.

When identified as follows. The SESSION object and
the PLR creates a backup LSP after it has received LSP_ID are copied from the primary
LSP's RESV message, the decision as to backup LSP type is based upon
inferring the behavior being protected. The IPv4
tunnel sender address MUST be set to an address of the merge PLR node. If
the merge node has
recorded a label, via head-end of a subobject in the RRO, then the PLR can assume
that tunnel is also acting as the merge node implements [BYPASS] with PLR, it MUST choose an
IP address different from the RSVP enhancements
given one used in [RSVP-TE]. Otherwise the merge node is assumed to implement
[DETOUR] and a detour backup SENDER_TEMPLATE of the
original LSP tunnel.

4.1 Detour Object Need Not be Understood

An additional benefit of having different SENDER_TEMPLATEs for detour
LSPs is signalled. If that the selected merge
node does Detour object need not support, or is assumed to be rejected by LSRs which do
not support, understand it. Instead, the DETOUR
object, then a simple backup path Detour object can be used. Using this method, silently passed
along; its use is for managability.

This simplifies the
PLR can provide interoperability scenarios between an LSR which
implements only the most efficient facility backup LSP feasible method given the
capabilites of the downstream LSRs.

4.2 Bypass Tunnels

The use of the tunnel heirarchy described in [BYPASS] provides
enhanced scalability for local protection. The midpoint nodes along
the active LSP of the bypass tunnel are aware of [FAST-REROUTE]
and reserve for only
one LSP, but multiple backup LSPs can use the same bypass tunnel.

This use of a label stack is not limited to the unsignalled one-to-one detour LSP backup
LSPs discussed method given in [BYPASS]. It is also possible to have simple
backup LSPs or [FAST-
REROUTE].

5. Make-Before-Break

Supporting make-before-break for detour backup LSPs be tunneled through a bypass
tunnel. To do this, is important if
re-optimization of the simple or detour backup LSP's PATH message
must be sent through paths is desired. It guarantees that
the bypass tunnel; it local protection, once created, will emerge at the merge
node. The backup path part of the ERO would simply be the merge
node. To support this, the merge node and the PLR must trust each
other to provide legitimate RSVP messages.

A bypass LSP may also be used by the PLR to avoid sending remain continuously
available until a DETOUR
object through failure occurs. At a node which does not support [DETOUR] to reach PLR, consider a
merge node single
detour LSP for a given primary LSP. When network adaptivity,
configuration, etc. dictate that does support [DETOUR] and does not support LRO.

4.3 Make-Before-Break on Backup Tunnels

In supporting make-before-break on backup tunnels, the option of
using a different LSP-ID path is not available. As described in [RSVP-TE],
when doing a make-before-break on a regular tunnel, preferred for
the ingress will
allocate detour, a new detour LSP ID to must be used when creating a created. Once that new LSP. Because
the SESSION object of the current detour
LSP and that of is created, the fast-reroute protection should be moved to the
new LSP are detour LSP; then the
same and Shared-Explicit (SE) old detour LSP can finally be torn down.

The requirement is specified, resources will for local-protection to ALWAYS be shared.

When signalling available at a
given PLR for a given primary LSP until a single failure occurs.
That failure may occur on the backup or on the primary.

When signalling either detour LSP, the LSP ID used (sent in the
SENDER_TEMPLATE and the FILTER_SPEC objects) is that of the primary
LSP which the backup LSP is protecting. The SESSION object used
when signalling the backup LSP is the same as the SESSION object of
the primary LSP. This behavior is common in [BYPASS] and [DETOUR].

4.3.1 Shared-Explicit and Backup LSPs

To properly support make-before-break on a backup tunnel, shared-
explicit must be used on that backup tunnel. However, if this were
done simply based upon

Therefore, the SESSION object, option of using a different LSP-ID, as is specified described in [RSVP-
TE], then the backup LSPs and the primary LSPs would share resources.
This is undesirable, as demonstrated by the following topology.

I---------J
/| |
/ | |
A----B E----F----G
| /| | /
| / | | /
| / | | /
|/ | |/
C----D----H

Consider
[RSVP-TE] for a primary LSP which goes A-B-C-D-E-F-G. The backup LSP regular tunnel, is not available for
E might go E-C-D-H-G. In this case, both the primary LSP and the
backup LSP traverse the link C-D in the same direction. If the
Shared-Explicit means that the primary LSP and backup LSP share
resources, then only the maximum of the primary LSP's bandwidth and
the backup LSP's bandwidth would be reserved
make-before-break on C-D. This would mean
that insufficient resources are reserved a backup. As described in the event of [RSVP-TE], when
doing a failure of
link E-F.

Consider if the backup LSP at B is B-I-J-F. If the link B-C failed
and A tried to create make-before-break on a new primary LSP, regular tunnel, the ingress will
allocate a new LSP would have ID to
travel across the I-J link. It is possible that the link I-J has
only enough bandwidth for either the backup LSP or the be used when creating a new primary LSP.

From these two cases, it is clear that, backup LSPs cannot share
bandwidth with the primary LSP that they are protecting and that
backup LSPs must share bandwidth with primary LSPs that they are not
protecting. All primary LSPs must share bandwidth with each other,
as described in [RSVP-TE], to permit make-before-break.

To resolve this requires that the "LSP ID" of the FILTER_SPEC (or
SENDER_TEMPLATE) be considered when determining whether LSPs should
share resources once Shared-Explicit is specified. If the LSP IDs in
two different RESV (or PATH) messages are different, then they can
share resources. If the LSP IDs are the same, then they cannot share
resources. This does not result in transitive sharing.

i) Backup LSPs for LSP n
ii) Primary LSP n
iii) Primary LSP k
iv) Backup LSPs for LSP k

Consider the above four groups of LSPs. (i) can share with (iii) and
(iv). (ii) can share with (iii) and (iv). (iii) can share with (i)
and (ii). (iv) can share with (i) and (ii).

A router following these guidelines should implement this enhancement
of the rules for shared-explicit. If all backup LSPs always have zero
bandwidth reserved, then this enhancement is not needed.
Constraining all backup LSPs to use zero bandwidth is support make-before-break on a severe
restriction and unacceptable in some situations.

4.3.2 Make-Before-Break with Sender Addresses

The prior subsection clarifies how Shared-Explicit can be specified
for backup LSPs. The Shared-Explicit backup, it is required for make-before-
break, as explained in [RSVP-TE]. The other piece necessary for
make-before-break is to have a
way of distinguishing the current backup LSP from the new backup
LSP. For a regular TE tunnel, this is done by
changing The content in the LSP ID. However, SENDER_TEMPLATE (and FILTER_SPEC) are the
LSP ID is used to associate and the
backup "IPv4 (IPv6) tunnel with a specific primary LSP. Therefore, the LSP ID sender address". The former
cannot be changed modified; therefore it is necessary to do a make-before-break on the backup tunnel.

The other content of change the SENDER_TEMPLATE (and FILTER_SPEC) is
address.

For detour LSPs, the "IPv4 (IPv6) tunnel sender address". As suggested in [BYPASS], the
PLR address" will fill out this address be
filled with one of the PLR's addresses for
simple backup LSPs. A router implementing [DETOUR] may not modify
this address in the SENDER_TEMPLATE; address, which is different from that
used when the LSR acts as an ingress, rather than a PLR, this router PLR.
Additionally, for Detour Backup LSPs, the PLR will put
the PLR's that same
address in the "Source ID" field in the DETOUR object.

Any router which can distinguish Object's "Source ID".

An LSR distinguishes a backup LSP from a primary LSP must
do so based upon either the
"IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE (and FILTER_SPEC) or upon the "Source ID" in the
DETOUR object.
FILTER_SPEC). Therefore, to signal two different backup LSPs from
the same PLR for the same primary LSP, the PLR must use different
IP addresses, which are put into the SENDER_TEMPLATE and/or the DETOUR
object. SENDER_TEMPLATE.

To effect a reroute or a bandwidth change on a backup tunnel, backup, the PLR
picks one of its IP addresses which is different from that used for
the current backup LSP in that backup tunnel and which is different from that used for
primary LSP. Then the PLR signals the new backup LSP and proceeds
with a make-before-break as described in [RSVP-TE].

To support make-before-break on backup tunnels backups in this manner, the PLR
must have ownership of two distinct IP addresses. If the PLR is
also ingress, then it requires a third distinct IP address, which
it uses when signalling primary LSPs. Only the router ID needs to
be routable. All three addresses MUST be unique within the MPLS domain,
and MUST
domain.

Support of make-before-break on backups MAY be globally unique if chosen supported.

6. Revertive Behavior: Recovery from public address space.

4.4 Catching ResvTears and Appropriate PathErrs

The PLR behavior described in this section should only start after
the primary LSP Failure

[MPLS-RECOVERY] describes some motivations for supporting revertive
behavior. It is known necessary to be successfully created. If the backup
tunnel is created after have a RESV is received method for the primary LSP, then
it suffices recovering back to check whether the backup tunnel is up. If the backup
tunnel is created when a PATH message is received for
the primary
LSP, then it is necessary that the backup tunnel be up and that LSP after a
RESV failure has been received for recovered. Ideally, as soon as
the primary LSP.

Under those circumstances, Ingress learned about the PLR must not forward ResvTear
[DETOUR]. Instead, when failure, a ResvTear is received, new primary LSP would have
been created and the PLR should move traffic to the backup tunnel, if moved onto it. Practically, it is up, and then not propagate the
ResvTear upstream towards the ingress.

The PLR must also handle certain PathErrs similarly
required to how it handles
ResvTears. If the PLR receives a PathErr with an error code occur. A recomputation of
"Policy Control failure", as happens when the primary LSP is
preempted, or tunnel's path
for a PathErr with an error code new primary LSP can guarantee the use of "Routing Problem" and a
sub-code of "No route newly available toward destination", as may happen
resource.

Revertive behavior MAY be supported. The determination of when a link or node fails, then the PLR should similarly move traffic
to the backup tunnel, if it
failure is over is up, and then not propagate the PathErr
upstream towards the ingress.

According to [RSVP-TE], the PathErr with the code "Policy Control
failure" occurs when the primary LSP to be preempted as the result of
another LSP being setup. This LSP failure caused by resource
preemption cannot be follows:

1) The locally detected at the ingress based upon IGP (IS-IS or
OSPF) information. Therefore the ingress must be explicitly notified failure, if the PLR receives this type of PathErr any, has cleared
(e.g. interface has come back up),

2) and does not propagate it
further upstream toward the ingress; if so, the PLR should send a
PathErr with an error code of "Notify" and an error value of "Tunnel
locally repaired".

4.5 Handling Resource Preemption

It is possible RESV message for a the primary LSP to have its resources preempted, due
to has been received
since the arrival and admission of another LSP. If failure occured.

Practically, when a RESV for the PLR primary LSP is making
this determination received at a PLR
and that PLR has a backup tunnel, which is currently up, local protection in use for that primary LSP, then if
no local failure is detectable, the PLR should move traffic from the
primary LSP may revert to using the backup tunnel and then send a PathErr with an
error code of "Notify" and an error value of "Tunnel locally
repaired".
primary LSP.

When this type of PathErr is received at the ingress, the
ingress should reroute RESV for the tunnel onto a new primary LSP using make-
before-break.

5. Merge Node Behavior

5.1 Label Space

To support all types of backup LSPs, a merge node must use is received, it is highly likely
that a
platform-wide (aka global) different label for an LSP which has requested local
protection.

If an implemention does not normally provide platform-wide labels for
unprotected RSVP-TE LSPs, additional behavior should will be defined to
handle an LSP which changes from requesting local protection to not
and vice versa. It is not recommended to change this attribute of a
TE tunnel without doing a reroute.

5.2 Ignore Path Tears Unless From Ingress
/--F----G----H--\
/ | | | \
A----B----C----D----E

Primary LSP: A-B-C-D-E
Bypass Tunnel's LSP: B-F-G-H-D

In specified in the above example, consider what LABEL Object. This
occurs when the link B-C fails.
B will start using its unsignalled backup path, which goes through
the bypass tunnel, and C will send a PathTear to D. If D acts upon if the PathTear received from C, then D would tear down downstream neighbor of the remainder PLR has lost all knowledge
of the primary (D-E) which is required to deliver traffic sent over LSP. When the
unsignalled backup path to PLR receives a different label, it
MUST change the egress. Because B is primary LSP to using an
unsignalled backup path, D cannot determine that it is label without propogating
a merge node.
This example indicates that PathTears must be ignored for different label upstream.

Essentially, to revert to the primary
LSPs which request local protection.

However, ignoring all PathTears means that LSP, the ingress cannot destroy PLR should:

1) Update the primary LSP. This unfortunate loss of capability can be remedied
by examination of LSP's out-segment to use the PathTear message. If new label
specified,

2) Move the PathTear's IP
packet's source IP address matches traffic from the "IPv4 (IPv6) tunnel sender
address" in backup LSP's out-segment to the SENDER_TEMPLATE object, then
primary LSP's out-segment,

3) And clear the PathTear came "local protection in use" flag from its IPv4
(IPv6) address subobject in the primary LSP's ingress and RRO. This
change should not be ignored.

5.3 Simple and Detour Backup LSPs

A router can determine that it is the merge node of either a simple
backup LSP or a detour backup LSP. In the latter case, the DETOUR
object contains one of propogated back to the merge node's IP addresses. In ingress as soon as
feasible.

6.1 Local Failure

If the former
case, if failure being recovered from is local, no PATH messages can
be sent for the matching primary LSP is known at the router and until the ERO
in affected link, etc, has
recovered.

If the simple backup LSP's failure was resource preemption, revertive behavior may not
be reasonable. If desired, then if a PATH message matches for the ERO primary
LSP succeeds in getting resources on the primary LSP's PATH message, out-going
interface, then the node is the merge node. If the
router is the merge node for a simple backup LSP, and only then can the simple
backup LSP's PLR forward a PATH message is not sent all the way to the egress, but
is instead merged to the primary LSP and handled at the merge node.
The merge node is responsible
for constructing a RESV based upon the primary LSP's RESV, including LSP downstream.

6.2 Remote Failure

If the RRO, and sending that.

As long as a router knows that it failure being recovered from is remote, then the merge node PLR may
send PATH messages for an existing
backup LSP, the router will not tear down the primary LSP immediately. However, in
response to the
egress.

5.4 ResvTears

When a router receives a ResvTear for an LSP and it is not such a PLR for
that LSP, then the router should propagate the ResvTear towards the
LSP's ingress. For each backup LSP where PATH message while the router failure is occuring, the merge
node, the ResvTear should also
PATH message will be propagated along the backup LSP
towards the backup LSP's ingress, met with a PLR.

This propagation clearly works for simple PathErr. All such PathErrs must be
ignored and detour backup LSPs.
For unsignalled backup LSPs, the router does not know it propogated upstream. The PLR is a merge
node.

A----B----C----D
| | | |
E----F----G----H

Primary LSP: A-B-C-D
Bypass Tunnel 1: A-E-F-G-C
Bypass Tunnel 2: B-F-G-H-D
Bypass Tunnel 3: C-G-H-D

In the above example, consider the behavior when router D fails. C
will determine already aware that both the primary LSP and bypass tunnel 3 are
down. Therefore, C will send
a ResvTear to B. B will determine that
bypass tunnel 2 is down and that the primary LSP has been torn down,
due to receiving the ResvTear. Therefore, B will send a ResvTear to
A. A will determine that the primary LSP is down failure exists and will switch to
using an unsignalled backup path through bypass tunnel 1. Bypass
tunnel 1 is still up.

A will repairing around that failure. The PLR
should send a PATH message for the primary LSP through bypass tunnel
1 to C. C will determine the the next hop in the PATH's ERO is
unreachable and send a PathErr with error code "Routing Problem" and
a sub-code of "No route available toward destination". When A
receives this PathErr, A will determine that the unsignalled backup
LSP is no longer available and will propagate that error upstream.

6. more frequently
than the normal refresh interval.

7. Security Considerations

This draft provides guidlelines for

These procedures do not change the use trust model of existing protocol
mechanisms defined in [RSVP-TE], [BYPASS], RSVP [RFC2205]
and [DETOUR] which are
designed to maximize interoperability. No new protocol is defined.
The usage or existing protocol described here does not introduce any [RSVP-TE]. As such no additional security risks.

7. risks are posed.

8. References

[RSVP-TE] Awduche, D.

[FAST-REROUTE] Pan, P. et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt,
February 2001.

[BYPASS] Swallow, G. and Goguen, R., "RSVP Label Allocation for
Backup Tunnels", "Fast Reroute Techniques in
RSVP-TE", Internet Draft, draft-swallow-rsvp-bypass-label-
01.txt, draft-ping-rsvp-fastreroute-00.txt,
November 2000

[DETOUR] Gan, D. 2001

[MPLS-RECOVERY] Sharma, V. et al., "A Method "Framework for MPLS LSP Fast-Reroute Using
RSVP Detours", MPLS-based
Recovery", Internet Draft, draft-gan-fast-reroute-00.txt, April draft-ietf-mpls-recovery-frmwrk-03.txt,
July 2001

[GMPLS IS-IS] Kompella, K.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC2205] Braden, R. et al., "IS-IS Extensions in Support of
Generalized MPLS", Internet Draft, draft-ietf-isis-gmpls-extensions-
02.txt, February 2001

[GMPLS OSPF] Kompella, K. "Resource ReSerVation Protocol (RSVP)
-- Version 1, Functional Specification", RFC 2205, September
1997.

[RSVP-TE] Awduche, D. et al., "OSPF "RSVP-TE: Extensions in Support of
Generalized MPLS", to RSVP for LSP
Tunnels", Internet Draft, draft-kompella-ospf-gmpls-
extensions-01.txt, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt,
February 2001

8. 2001.

9. Authors' Addresses

Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
Voice: +1 (978) 964-2070
Email: aatlas@avici.com

Curtis Villamizar
Email: curtis@avici.com

Caren Litvanyi
PO Box 2535
Cupertino, CA 95015

Markus Jork
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
Voice: +1 (978) 964-2142
Email: litvanyi@synack.net mjork@avici.com