< draft-atlas-rsvp-local-protect-interop-01.txt   draft-atlas-rsvp-local-protect-interop-02.txt >
Internet Draft Alia Atlas Internet Draft Alia Atlas (Avici Systems)
Expires: January 2002 Curtis Villamizar Expires: May 20002 Markus Jork (Avici Systems)
- Avici Systems
Caren Litvanyi
- Qwest Communications
July 2001 November 2001
MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute 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 Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 37 skipping to change at page 1, line 33
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
Routers implementing the local protection enhancements given in Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute-
[draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage is clarified in 00.txt, leaves several areas with future work required. One of those
[draft-swallow-rsvp-bypass-label-01.txt], and routers implementing areas is the merging rules for detour LSPs. This draft describes
solely [draft-gan-fast-reroute-00.txt] do not interoperate to provide some of the issues with the merging rules presented in draft-ping-
local protection. Those routers which follow the guidelines given in rsvp-fastreroute-02.txt and proposes a solution which also enhances
this draft should be able to interoperate with either type of interoperability.
implementation. The guidelines also specify how to support make-
before-break with backup LSPs.
Contents
1. Introduction .............................................. 3
2. Terminology ............................................... 3
3. Ingress Support ........................................... 4
3.1 Requesting Local Protection .............................. 4
3.2 Detecting Protection Information ......................... 5
4. PLR Behavior .............................................. 6
4.1 Selecting Backup LSP Type ................................ 7
4.2 Bypass Tunnels ........................................... 8
4.3 Make-Before-Break on Backup Tunnels ...................... 8
4.3.1 Shared-Explicit and Backup LSPs ........................ 9
4.3.2 Make-Before-Break with Sender Addresses ................ 9
4.4 Catching ResvTears and Appropriate PathErrs .............. 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. Security Considerations ................................... 13
7. References ................................................ 13
8. Authors' Addresses ........................................ 14
1. Introduction 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 will become
temporarily unavailable if re-optimization of a backup path is
implemented.
Routers may implement the local protection enhancements given in This draft describes examples of the above problems and proposes a
[RSVP-TE], whose usage is clarified in [BYPASS], but not implement solution. The solution also resolves issues with merged backups
[DETOUR]. Routers may also implement [DETOUR] without implementing which do not provide adequate protection, due to the use of SRLGs.
the local protection enhancements given in [RSVP-TE]. These two sets The solution also finds backup paths in some topologies where a
of routers will not interoperate to provide local protection. detour LSP could not be found, in the merging rules in draft-ping-
rsvp-fastreroute-00.txt were followed.
This draft assumes that a router falls into one of the following Recommended behavior for supporting a revertive mode for local
three sets: protection is specified.
A. Implements both the local protection enhancements given in Contents
[RSVP-TE] and [DETOUR] as described in this draft.
B. Implements only [DETOUR]. 1. Introduction ............................................... 3
2. Backup Availability ........................................ 3
3. Backup Does Not Provide Protection ......................... 4
3.1 Selected ERO Merges at PLR ................................ 4
3.2 Selected ERO Uses SRLG .................................... 5
3.3 No Backup Path For Detour LSP ............................. 5
4. Solution to Problems with Merging Rules .................... 6
4.1 Detour Object Need Not be Understood ...................... 7
5. Make-Before-Break .......................................... 7
6. Revertive Behavior: Recovery from Failure .................. 9
6.1 Local Failure ............................................. 10
6.2 Remote Failure ............................................ 10
7. Security Considerations .................................... 10
8. Reference .................................................. 10
9. Authors' Addresses ......................................... 11
C. Implements only the local protection enhancements given in 1. Introduction
[RSVP-TE], according to the guidelines in [BYPASS].
The guidelines given in this draft should allow routers in set A to Our combined draft on fast-reroute, draft-ping-rsvp-fastreroute-
interoperate with either of the other two sets of routers, but not 00.txt, leaves several areas with future work required. One of those
both. A network with routers in set A and set B will be able to areas is the merging rules for detour LSPs. This draft describes
provide local protection. A network with routers in set A and set C some of the issues with the merging rules presented in draft-ping-
will be able to provide local protection. A network that contains rsvp-fastreroute-02.txt and proposes a solution which also enhances
routers from both set B and set C will not be able to provide local interoperability.
protection in some cases involving paths with a mix of the two types
of routers, irrespective of the presence or absence of routers from
set A.
This draft also describes a modification to identifying LSPs The implementation of detour LSPs described in [FAST-REROUTE] results
specified for Shared-Explicit which distinguish between primary and in intermittent backup availability. A detour LSP will become
backup bandwidth reservations. This is necessary to support make- temporarily unavailable when other detours with different EROs are
before-break on backup tunnels; how to support make-before-break on merged into it; local protection will become temporarily unavailable
backup tunnels is described. if re-optimization of a backup path is implemented.
More details on handling PathErrs and resource preemption is This draft describes examples of the above problems and proposes a
provided. solution. The solution also resolves issues with merged backups
which do not provide adequate protection, due to the use of SRLGs.
The solution also finds backup paths in some topologies where a
detour LSP could not be found, in the merging rules in [FAST-REROUTE]
were followed. Finally, the solution allows make-before-break to work
on detour LSPs without causing the protection to become temporarily
unavailable.
2. Terminology Recommended behavior for supporting a revertive mode for local
protection is specified.
PLR (Point-of-Local-Repair): Any node along the primary LSP's path is 2. Backup Availability
a potential PLR. A node becomes an active PLR when it takes action
to transfer traffic from the primary LSP to a backup tunnel when a
failure is locally detected. When discussed in examples, the
specific potential PLR of interest is the node which originates the
specific backup tunnel under discussion.
Backup Tunnel: A backup tunnel is logically created from the PLR to a In order for local protection to be useful in mission-critical
merge node on the primary LSP's path; which specific merge node is networks, it is important that local protection, once created at a
used can vary between the backup LSPs contained in the backup tunnel. PLR for a given primary LSP, remains available at all times until a
The backup tunnel can contain one or more backup LSPs for a given single fault has occurred. That fault could be physical or due to
primary LSP. The concept of a backup tunnel permits make-before- resource preemption and could occur on either the primary LSP or the
break for backup LSPs. backup LSP.
Backup LSP: A backup LSP extends from its origin at the PLR to a The fault against which the backup protects could occur at any time,
specific merge node, where it rejoins the primary LSP. A backup LSP including when the backup is temporarily unavailable. Similarly, at
is part of a Backup Tunnel. There are three types of backup LSPs - any time, traffic could be running across a backup - if it becomes
simple, detour and unsignalled. temporarily unavailable then, traffic loss will result.
Simple Backup LSP: A Simple Backup LSP is a backup LSP whose PATH The following example demonstrates a case when following the merging
message does not include the DETOUR object. The ERO contains the rules given in [FAST-REROUTE] result in the backup becoming
selected backup path to the merge node and then an exact duplicate of temporarily unavailable. In this example, the PLR of the backup
the primary LSP's ERO from that merge node to the egress. which is temporarily unavailable is not aware that the backup is not
functional during that period.
Detour Backup LSP: A Detour Backup LSP is a backup LSP whose PATH [R1]----[R2]----[R3]----[R4]--R5]
message includes the DETOUR object. The ERO simply contains the | \ / | /
selected backup path to the merge node. [R6]-------[R8]----------[R9]
Bypass Tunnel: A tunnel from the PLR of interest to a specific merge Primary: R1-R2-R3-R4-R5
node through which traffic across unsignalled backup LSPs can be R2 backup: R2-R8-R9-R4
passed. This is used as defined in [BYPASS]. R3 backup: R3-R8-R9-R5
Unsignalled Backup LSP: An Unsignalled Backup LSP can only exist if Figure 1: New Detour Causes Existing Detour to Fail
there is an appropriate bypass tunnel. This bypass tunnel is used so
that the Unsignalled Backup LSP is logically one hop away from the
merge node. No RSVP signalling is done to create or indicate the
existence of the Unsignalled Backup LSP. The Unsignalled Backup LSP
uses the label provided by the merge node, via the Label sub-object,
to forward traffic to the merge node, as described in [BYPASS].
Fully Protected: A primary LSP is considered to be fully protected Assume that due to setup timing, R2's backup is created first. Then
when each potential PLR in its path has a current backup tunnel when the detour from R3 tries to be created, R8 must merge the two
available. detours together. According to the merging rules in [FAST-REROUTE],
R8 must select the ERO to R3's backup. When R8 does so, there is a
period when the backup from R2 was "up" but isn't actually available
unless R8 and R9 deal with changing the ERO in a make-before-break
fashion.
3. Ingress Support The same problem will occur when and if the backup from R3 is torn
down. Tearing down R3's backup will make R2's backup temporarily
unavailable.
3.1 Requesting Local Protection 3. Backup Does Not Provide Protection
The [DETOUR] and [BYPASS] propose different methods for the ingress There are three examples of where the merging rules given in [FAST-
to signal that an LSP desires local protection. These methods are REROUTE] result in either a final detour LSP which does not provide
not mutually incompatible. The ingress must both include the protection against failure or in no detour LSP being created.
FAST_REROUTE object in the PATH message and set the two flags, "Label
Recording desired" and "Local Protection desired", in the
SESSION_ATTRIBUTE object[RSVP-TE].
By including the FAST_REROUTE object, any nodes on the primary LSP 3.1 Selected ERO Merges at PLR
which implement [DETOUR] will know that the primary LSP requires
protection. By setting the "Local Protection desired" flag in the
SESSION_ATTRIBUTE object, any nodes which implement [BYPASS] will
know that the primary 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 In the following example, the merging rules in [FAST-REROUTE] require
SESSION_ATTRIBUTE, the resulting Label subobjects in the RRO permit that the shorter ERO be selected.
those PLRs which implement [BYPASS] to create Unsignalled Backup
LSPs. If there are nodes in the primary LSP's 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 not set, the interoperability affected
will be with routers which only support Unsignalled Backup LSPs.
This must be 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 in violation of the specification.
3.2 Detecting Protection Information [R1]--[R2]----[R3]----[R4]---------------[R5]--[R6]--
\ | |
\ [R7] [R8]
\ | \ |
\ | \ |
------[R9]--[R10]--[R11]--[R12]---[R13]
The primary tunnel's ingress is responsible for determining when Primary LSP: R1-R2-R3-R4-R5-R6-....
rerouting of the primary path is desirable. For instance, if local R1's Backup: R1-R9-R10-R7-R3-R4-R5-R6-....
protection is in use on the current primary LSP, it would be R3's Backup: R3-R7-R9-R10-R11-R12-R13-R8-R5-R6-...
desirable to compute a new primary LSP.
The ingress must also determine when to move from a current LSP to a Figure 2: No Protection for PLR Because Merged Detour Ends at PLR
new LSP, via make-before-break. For instance, it will take time
before a newly created primary LSP will be fully protected. If the
new primary LSP were to be created 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 in use on the current primary LSP, the ingress
may move traffic immediately to the new primary LSP or it may wait
until the new primary LSP is as locally protected along its path as
the current primary LSP is.
For both of the reasons above, the ingress must know what nodes along In this example, R9 must merge R1's backup and R3's backup. Because
an LSP's path are currently providing local protection and which have the shorter ERO must be chosen, R9 would select R1's backup's ERO;
that local protection in use. The "Local protection available" and clearly R3 would not have an effective backup in this case.
"Local protection in use" in the IPv4 address and IPv6 address
subobjects of the RRO [RSVP-TE] provide the necessary information to
the ingress. The ingress may be notified that local protection is in
use via a PathErr message with an error code of "Notify"(25) and an
error value of "Tunnel locally repaired"(3) by nodes implementing
[BYPASS].
Routers implementing only [DETOUR] without the local protection This problem could be resolved by adding a merge rule which removes
enhancements given in [RSVP-TE] may not set the "Local protection any ERO from consideration which merges with the primary LSP at a
available" and "Local protection in use" flags in the IPv4 and IPv6 node which is the PLR for any detour LSP being merged.
address subobjects of the RRO.
To permit the ingress behavior described early in this section, the 3.2 Selected ERO Uses SRLG
ingress should be configured with information about which nodes
implement only [DETOUR] and, therefore, do not support a means to
indicate that local protection is available at that node. Such nodes
can be ignored at the ingress in any decision regarding whether the
protection is fully available (it must be assumed that protection is
available for any such node when any RSVP RESV arives).
4. PLR Behavior In the following example, the selected ERO uses a link which belongs
to an SRLG which one of the merged detour LSPs was avoiding.
Once an ingress or midpoint node has determined that a given LSP is [R1]-----[R2]-----[R3]-------[R4]
requesting local protection, that node, acting in the role of a PLR, \ | / |
must determine the link(s) and/or node(s) that the backup tunnel must -----[R5]------[R6]----[R7] |
avoid. Then, the PLR must determine the backup path and merge node. | |
Finally, the PLR must determine what type of backup LSP to use and [R8]---[R9]--|
create it.
A link or node could fail for a variety of reasons. Links for which Primary LSP: R1-R2-R3-R4
failure may be correlated are determined through the use of Shared R1's Backup: R1-R5-R6-R7-R4
Risk Link Groups (SRLGs). SRLGs may be signaled via [GMPLS IS-IS] R2's Backup: R2-R5-R6-R8-R9-R4
and [GMPLS OSPF]. The PLR can determine what SRLGs are present SRLG contains: R2-R3 and R6-R7
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 Figure 3: Merged Detour LSP Uses a Link Avoided Due to SRLG
signaling must be originated. Some routers may only support
configured SRLGs and therefore cannot originate signaled SRLGs and
therefore the ability to configure SRLGs for external links must be
supported.
4.1 Selecting Backup LSP Type In the above figure, the merging rules in [FAST-REROUTE] mean that R5
will select the ERO associated with R1's backup. Unfortunately, that
means that the merged detour LSP will not protect against the failure
of R2-R3 because the link R6-R7 is used in the final merged detour
LSP and R6-R7 and R2-R3 are in a common SRLG.
The PLR may decide to create a backup LSP either when it has received 3.3 No Backup Path For Detour LSP
the primary LSP's PATH message or after it has received the primary
LSP's RESV message. The latter case is required if unsignalled
backup paths are desirable. The former case is reasonable if most
LSPs are expected to be created successfully and if the ERO is
primarily strict hops, so that a reasonable merge node can be
determined.
To determine which type of backup LSP to create, the PLR must infer The CSPF rules given in [FAST-REROUTE] require that the backup path
what type of routers share the local domain. If the other routers selected does not cross a link in the same direction as the primary
implement [BYPASS], then either a simple backup LSP or an unsignalled LSP does. This is to avoid merging problems when a detour LSP
backup LSP should be created. If the other routers implement intersects its primary LSP and yet should not be merged. However,
[DETOUR], then a detour backup LSP should be created. this can result in the lack of protection, due to a lack of paths, as
described in the following example.
If the PLR is to create a backup LSP when it has received the primary [R1]--[R2]--[R3]--[R4]
LSP's PATH message, then the PLR must determine the type of backup | / | |
LSP based upon the inferred type of the ingress. If the primary's | / | |
PATH message contains a FAST_REROUTE object, it is assumed that other [R5]--[R6]--[R7]---------|
routers will support the [DETOUR]. The PLR will attempt to create a Primary: R5-R6-R7-R2-R3-R4
detour backup LSP. If no FAST_REROUTE object is found or if the R2 Backup: R2-R6-R7-R4
detour creation is rejected, as indicated by a PathErr with the error [R2]-[R7] has insufficient bandwidth to support R2's backup
code "Unknown object class", then a simple backup LSP can be
attempted. The latter case can only occur in a mixed network where
the ingress supports [DETOUR] but a node along the selected backup
path does not. In this case, the backup LSP must be resignaled
without a DETOUR object.
When the PLR creates a backup LSP after it has received the primary Figure 4: Detour LSP uses same link as primary LSP upstream from PLR
LSP's RESV message, the decision as to backup LSP type is based upon
inferring the behavior of the merge node. If the merge node has
recorded a label, via a subobject in the RRO, then the PLR can assume
that the merge node implements [BYPASS] with the RSVP enhancements
given in [RSVP-TE]. Otherwise the merge node is assumed to implement
[DETOUR] and a detour backup LSP is signalled. If the selected merge
node does not support, or is assumed to not support, the DETOUR
object, then a simple backup path can be used. Using this method, the
PLR can provide the most efficient backup LSP feasible given the
capabilites of the downstream LSRs.
4.2 Bypass Tunnels In the above example, there are two possible ways for R2 to have a
backup. Either, it can use R2-R6-R7 or it can use R2-R7. In this
scenario, the link R2-R7 does not have sufficient free bandwidth to
admit the backup LSP.
The use of the tunnel heirarchy described in [BYPASS] provides 4. Solution to Problems with Merging Rules
enhanced scalability for local protection. The midpoint nodes along
the active LSP of the bypass tunnel are aware of 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 backup The problems with the merging rules can be solved by using a
LSPs discussed in [BYPASS]. It is also possible to have simple different SENDER_TEMPLATE for each backup LSP, instead of using the
backup LSPs or detour backup LSPs be tunneled through a bypass primary's SENDER_TEMPLATE, and by not merging Path messages with
tunnel. To do this, the simple or detour backup LSP's PATH message different EROs.
must be sent through the bypass tunnel; it 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 a DETOUR First, consider the solution of not merging Path messages with
object through a node which does not support [DETOUR] to reach a different EROs. This alone appears to resolve all three of the
merge node that does support [DETOUR] and does not support LRO. issues described in Section 3. However, simply not merging Path
messages with different EROs introduces other problems when all
detour LSPs for the same primary LSP have the same SENDER_TEMPLATE.
4.3 Make-Before-Break on Backup Tunnels Consider the third issue described where the backup path must cross
and use the same link as the primary LSP. Not merging the detour LSP
and the primary LSP leads to the inability to determine whether a
PathErr belongs to the Primary LSP or to a Backup LSP through the LSR
with the same next hop. Figure 4 demonstrates the problem with this
partial solution.
In supporting make-before-break on backup tunnels, the option of In Figure 4, if the link from R7-R4 breaks, R7 will send a PathErr to
using a different LSP-ID is not available. As described in [RSVP-TE], R6. If the SENDER_TEMPLATE for the Primary LSP and for R2's Backup
when doing a make-before-break on a regular tunnel, the ingress will LSP were the same, then R6 would be unable to determine whether the
allocate a new LSP ID to be used when creating a new LSP. Because PathErr was for the Primary LSP or for R2's Backup LSP. This is the
the SESSION object of the current LSP and that of the new LSP are the problem with not merging Path messages with different EROs when
same and Shared-Explicit (SE) is specified, resources will be shared. detour LSPs share the same SENDER_TEMPLATE.
When signalling a backup LSP, the LSP ID used (sent in the To further elaborate, consider Figure 5 below, when one tries to NOT
SENDER_TEMPLATE and the FILTER_SPEC objects) is that of the primary merge Path messages for detour LSPs with different EROs but with the
LSP which the backup LSP is protecting. The SESSION object used when same next link/hop.
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 [R1]--[R2]--[R3]--[R4]
\ | | /
\ | | /
[R5]---[R6]
To properly support make-before-break on a backup tunnel, shared- Primary : R1-R5-R6-R4
explicit must be used on that backup tunnel. However, if this were R1's Backup: R1-R2-R3-R6
done simply based upon the SESSION object, as is specified in [RSVP- R5's Backup: R5-R2-R3-R4
TE], then the backup LSPs and the primary LSPs would share resources.
This is undesirable, as demonstrated by the following topology.
I---------J Figure 5: OverMerging Backup LSPs
/| |
/ | |
A----B E----F----G
| /| | /
| / | | /
| / | | /
|/ | |/
C----D----H
Consider a primary LSP which goes A-B-C-D-E-F-G. The backup LSP for If the SENDER_TEMPLATES for R1's backup and R5's backup are the same,
E might go E-C-D-H-G. In this case, both the primary LSP and the then a RESV received for one would have a FILTER_SPEC which would
backup LSP traverse the link C-D in the same direction. If the match both R1's backup and R5's backup. Because the SENDER_TEMPLATEs
Shared-Explicit means that the primary LSP and backup LSP share are the same and the Detour object is not included in the RESV, there
resources, then only the maximum of the primary LSP's bandwidth and is no way at R2 to distinguish a RESV for R1's backup from a RESV for
the backup LSP's bandwidth would be reserved on C-D. This would mean R5's backup.
that insufficient resources are reserved in the event of a failure of
link E-F.
Consider if the backup LSP at B is B-I-J-F. If the link B-C failed From the preceeding, there are two alternatives if merging of Path
and A tried to create a new primary LSP, the new LSP would have to messages with different EROs is not desired (as demonstrated via
travel across the I-J link. It is possible that the link I-J has Figure 1). Either, the Detour object must be included in every Path,
only enough bandwidth for either the backup LSP or the new primary Resv, PathErr, ResvErr, PathTear, ResvTear, and ResvConf message
LSP. which is for the detour LSP or the SENDER_TEMPLATEs for detour LSPs
must be different. The former alternative is essentially expanding
the SENDER_TEMPLATE to include the Detour object.
From these two cases, it is clear that, backup LSPs cannot share The recommendation is to simply use a different SENDER_TEMPLATE. The
bandwidth with the primary LSP that they are protecting and that "IPv4 tunnel sender address" in the SENDER_TEMPLATE MUST contain an
backup LSPs must share bandwidth with primary LSPs that they are not IP address of the PLR.
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 A backup LSP MUST be identified as follows. The SESSION object and
SENDER_TEMPLATE) be considered when determining whether LSPs should the LSP_ID are copied from the primary LSP being protected. The IPv4
share resources once Shared-Explicit is specified. If the LSP IDs in tunnel sender address MUST be set to an address of the PLR node. If
two different RESV (or PATH) messages are different, then they can the head-end of a tunnel is also acting as the PLR, it MUST choose an
share resources. If the LSP IDs are the same, then they cannot share IP address different from the one used in the SENDER_TEMPLATE of the
resources. This does not result in transitive sharing. original LSP tunnel.
i) Backup LSPs for LSP n 4.1 Detour Object Need Not be Understood
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 An additional benefit of having different SENDER_TEMPLATEs for detour
(iv). (ii) can share with (iii) and (iv). (iii) can share with (i) LSPs is that the Detour object need not be rejected by LSRs which do
and (ii). (iv) can share with (i) and (ii). not understand it. Instead, the Detour object can be silently passed
along; its use is for managability.
A router following these guidelines should implement this enhancement This simplifies the interoperability scenarios between an LSR which
of the rules for shared-explicit. If all backup LSPs always have zero implements only the facility backup method given in [FAST-REROUTE]
bandwidth reserved, then this enhancement is not needed. and not the one-to-one detour LSP backup method given in [FAST-
Constraining all backup LSPs to use zero bandwidth is a severe REROUTE].
restriction and unacceptable in some situations.
4.3.2 Make-Before-Break with Sender Addresses 5. Make-Before-Break
The prior subsection clarifies how Shared-Explicit can be specified Supporting make-before-break for detour LSPs is important if
for backup LSPs. The Shared-Explicit is required for make-before- re-optimization of the backup paths is desired. It guarantees that
break, as explained in [RSVP-TE]. The other piece necessary for the local protection, once created, will remain continuously
make-before-break is a way of distinguishing the current backup LSP available until a failure occurs. At a PLR, consider a single
from the new backup LSP. For a regular TE tunnel, this is done by detour LSP for a given primary LSP. When network adaptivity,
changing the LSP ID. However, the LSP ID is used to associate the configuration, etc. dictate that a different path is preferred for
backup tunnel with a specific primary LSP. Therefore, the LSP ID the detour, a new detour LSP must be created. Once that new detour
cannot be changed to do a make-before-break on the backup tunnel. LSP is created, the fast-reroute protection should be moved to the
new detour LSP; then the old detour LSP can finally be torn down.
The other content of the SENDER_TEMPLATE (and FILTER_SPEC) is the The requirement is for local-protection to ALWAYS be available at a
"IPv4 (IPv6) tunnel sender address". As suggested in [BYPASS], the given PLR for a given primary LSP until a single failure occurs.
PLR will fill out this address with one of the PLR's addresses for That failure may occur on the backup or on the primary.
simple backup LSPs. A router implementing [DETOUR] may not modify
this address in the SENDER_TEMPLATE; when a PLR, this router will put
the PLR's address in the "Source ID" field in the DETOUR object.
Any router which can distinguish a backup LSP from a primary LSP must When signalling either detour LSP, the LSP ID used (sent in the
do so based upon either the "IPv4 (IPv6) tunnel sender address" in SENDER_TEMPLATE and the FILTER_SPEC objects) is that of the primary
the SENDER_TEMPLATE (and FILTER_SPEC) or upon the "Source ID" in the LSP which the backup LSP is protecting. The SESSION object used
DETOUR object. Therefore, to signal two different backup LSPs from when signalling the backup LSP is the same as the SESSION object of
the same PLR for the same primary LSP, the PLR must use different IP the primary LSP.
addresses, which are put into the SENDER_TEMPLATE and/or the DETOUR
object.
To effect a reroute or a bandwidth change on a backup tunnel, the PLR Therefore, the option of using a different LSP-ID, as described in
picks one of its IP addresses which is different from that used for [RSVP-TE] for a regular tunnel, is not available for
the current backup LSP in that backup tunnel and which is different make-before-break on a backup. As described in [RSVP-TE], when
from that used for primary LSP. Then the PLR signals the new backup doing a make-before-break on a regular tunnel, the ingress will
LSP and proceeds with a make-before-break as described in [RSVP-TE]. allocate a new LSP ID to be used when creating a new LSP.
To support make-before-break on backup tunnels in this manner, the To support make-before-break on a backup, it is necessary to have a
PLR must have ownership of two distinct IP addresses. If the PLR is way of distinguishing the current backup LSP from the new backup
also ingress, then it requires a third distinct IP address, which it LSP. The content in the SENDER_TEMPLATE (and FILTER_SPEC) are the
uses when signalling primary LSPs. Only the router ID needs to be LSP ID and the "IPv4 (IPv6) tunnel sender address". The former
routable. All three addresses MUST be unique within the MPLS domain, cannot be modified; therefore it is necessary to change the
and MUST be globally unique if chosen from public address space. address.
4.4 Catching ResvTears and Appropriate PathErrs For detour LSPs, the "IPv4 (IPv6) tunnel sender address" will be
filled with one of the PLR's address, which is different from that
used when the LSR acts as an ingress, rather than a PLR.
Additionally, for Detour Backup LSPs, the PLR will put that same
address in the DETOUR Object's "Source ID".
The PLR behavior described in this section should only start after An LSR distinguishes a backup LSP from a primary LSP based upon the
the primary LSP is known to be successfully created. If the backup "IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE (and
tunnel is created after a RESV is received for the primary LSP, then FILTER_SPEC). Therefore, to signal two different backup LSPs from
it suffices to check whether the backup tunnel is up. If the backup the same PLR for the same primary LSP, the PLR must use different
tunnel is created when a PATH message is received for the primary IP addresses, which are put into the SENDER_TEMPLATE.
LSP, then it is necessary that the backup tunnel be up and that a
RESV has been received for the primary LSP.
Under those circumstances, the PLR must not forward ResvTear To effect a reroute or a bandwidth change on a backup, the PLR
[DETOUR]. Instead, when a ResvTear is received, the PLR should move picks one of its IP addresses which is different from that used for
traffic to the backup tunnel, if it is up, and then not propagate the the current backup LSP and which is different from that used for
ResvTear upstream towards the ingress. primary LSP. Then the PLR signals the new backup LSP and proceeds
with a make-before-break as described in [RSVP-TE].
The PLR must also handle certain PathErrs similarly to how it handles To support make-before-break on backups in this manner, the PLR
ResvTears. If the PLR receives a PathErr with an error code of must have ownership of two distinct IP addresses. If the PLR is
"Policy Control failure", as happens when the primary LSP is also ingress, then it requires a third distinct IP address, which
preempted, or a PathErr with an error code of "Routing Problem" and a it uses when signalling primary LSPs. Only the router ID needs to
sub-code of "No route available toward destination", as may happen be routable. All three addresses MUST be unique within the MPLS
when a link or node fails, then the PLR should similarly move traffic domain.
to the backup tunnel, if it is up, and then not propagate the PathErr
upstream towards the ingress.
According to [RSVP-TE], the PathErr with the code "Policy Control Support of make-before-break on backups MAY be supported.
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 detected at the ingress based upon IGP (IS-IS or
OSPF) information. Therefore the ingress must be explicitly notified
if the PLR receives this type of PathErr 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 6. Revertive Behavior: Recovery from Failure
It is possible for a primary LSP to have its resources preempted, due [MPLS-RECOVERY] describes some motivations for supporting revertive
to the arrival and admission of another LSP. If the PLR is making behavior. It is necessary to have a method for recovering back to
this determination and has a backup tunnel, which is currently up, the primary LSP after a failure has recovered. Ideally, as soon as
for that primary LSP, then the PLR should move traffic from the the Ingress learned about the failure, a new primary LSP would have
primary LSP to the backup tunnel and then send a PathErr with an been created and the traffic moved onto it. Practically, it is not
error code of "Notify" and an error value of "Tunnel locally required to occur. A recomputation of the primary tunnel's path
repaired". When this type of PathErr is received at the ingress, the for a new primary LSP can guarantee the use of a newly available
ingress should reroute the tunnel onto a new primary LSP using make- resource.
before-break.
5. Merge Node Behavior Revertive behavior MAY be supported. The determination of when a
failure is over is as follows:
5.1 Label Space 1) The locally detected failure, if any, has cleared
(e.g. interface has come back up),
To support all types of backup LSPs, a merge node must use a 2) and a RESV message for the primary LSP has been received
platform-wide (aka global) label for an LSP which has requested local since the failure occured.
protection.
If an implemention does not normally provide platform-wide labels for Practically, when a RESV for the primary LSP is received at a PLR
unprotected RSVP-TE LSPs, additional behavior should be defined to and that PLR has local protection in use for that primary LSP, if
handle an LSP which changes from requesting local protection to not no local failure is detectable, the PLR may revert to using the
and vice versa. It is not recommended to change this attribute of a primary LSP.
TE tunnel without doing a reroute.
5.2 Ignore Path Tears Unless From Ingress When the RESV for the primary LSP is received, it is highly likely
/--F----G----H--\ that a different label will be specified in the LABEL Object. This
/ | | | \ occurs if the downstream neighbor of the PLR has lost all knowledge
A----B----C----D----E of the primary LSP. When the PLR receives a different label, it
MUST change the primary LSP to using that label without propogating
a different label upstream.
Primary LSP: A-B-C-D-E Essentially, to revert to the primary LSP, the PLR should:
Bypass Tunnel's LSP: B-F-G-H-D
In the above example, consider what occurs when the link B-C fails. 1) Update the primary LSP's out-segment to use the new label
B will start using its unsignalled backup path, which goes through specified,
the bypass tunnel, and C will send a PathTear to D. If D acts upon
the PathTear received from C, then D would tear down the remainder of
the primary (D-E) which is required to deliver traffic sent over the
unsignalled backup path to the egress. Because B is using an
unsignalled backup path, D cannot determine that it is a merge node.
This example indicates that PathTears must be ignored for primary
LSPs which request local protection.
However, ignoring all PathTears means that the ingress cannot destroy 2) Move the traffic from the backup LSP's out-segment to the
the primary LSP. This unfortunate loss of capability can be remedied primary LSP's out-segment,
by examination of the PathTear message. If the PathTear's IP
packet's source IP address matches the "IPv4 (IPv6) tunnel sender
address" in the SENDER_TEMPLATE object, then the PathTear came from
the LSP's ingress and should not be ignored.
5.3 Simple and Detour Backup LSPs 3) And clear the "local protection in use" flag from its IPv4
(IPv6) address subobject in the primary LSP's RRO. This
change should be propogated back to the ingress as soon as
feasible.
A router can determine that it is the merge node of either a simple 6.1 Local Failure
backup LSP or a detour backup LSP. In the latter case, the DETOUR
object contains one of the merge node's IP addresses. In the former
case, if the matching primary LSP is known at the router and the ERO
in the simple backup LSP's PATH message matches the ERO in the
primary LSP's PATH message, then the node is the merge node. If the
router is the merge node for a simple backup LSP, then the simple
backup LSP's 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 the RRO, and sending that.
As long as a router knows that it is the merge node for an existing If the failure being recovered from is local, no PATH messages can
backup LSP, the router will not tear down the primary LSP to the be sent for the primary LSP until the affected link, etc, has
egress. recovered.
5.4 ResvTears If the failure was resource preemption, revertive behavior may not
be reasonable. If desired, then if a PATH message for the primary
LSP succeeds in getting resources on the primary LSP's out-going
interface, then and only then can the PLR forward a PATH message
for the primary LSP downstream.
When a router receives a ResvTear for an LSP and it is not a PLR for 6.2 Remote Failure
that LSP, then the router should propagate the ResvTear towards the
LSP's ingress. For each backup LSP where the router is the merge
node, the ResvTear should also be propagated along the backup LSP
towards the backup LSP's ingress, a PLR.
This propagation clearly works for simple and detour backup LSPs. If the failure being recovered from is remote, then the PLR may
For unsignalled backup LSPs, the router does not know it is a merge send PATH messages for the primary LSP immediately. However, in
node. response to such a PATH message while the failure is occuring, the
PATH message will be met with a PathErr. All such PathErrs must be
ignored and not propogated upstream. The PLR is already aware that
a failure exists and is repairing around that failure. The PLR
should send a PATH message for the primary LSP no more frequently
than the normal refresh interval.
A----B----C----D 7. Security Considerations
| | | |
E----F----G----H
Primary LSP: A-B-C-D These procedures do not change the trust model of RSVP [RFC2205]
Bypass Tunnel 1: A-E-F-G-C and [RSVP-TE]. As such no additional security risks are posed.
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 8. References
will determine 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 and will switch to
using an unsignalled backup path through bypass tunnel 1. Bypass
tunnel 1 is still up.
A will send a PATH message for the primary LSP through bypass tunnel [FAST-REROUTE] Pan, P. et al., "Fast Reroute Techniques in
1 to C. C will determine the the next hop in the PATH's ERO is RSVP-TE", Internet Draft, draft-ping-rsvp-fastreroute-00.txt,
unreachable and send a PathErr with error code "Routing Problem" and November 2001
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. Security Considerations [MPLS-RECOVERY] Sharma, V. et al., "Framework for MPLS-based
Recovery", Internet Draft, draft-ietf-mpls-recovery-frmwrk-03.txt,
July 2001
This draft provides guidlelines for the use of existing protocol [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
mechanisms defined in [RSVP-TE], [BYPASS], and [DETOUR] which are Requirement Levels", RFC 2119, March 1997.
designed to maximize interoperability. No new protocol is defined.
The usage or existing protocol described here does not introduce any
additional security risks.
7. References [RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP)
-- Version 1, Functional Specification", RFC 2205, September
1997.
[RSVP-TE] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt,
February 2001. February 2001.
[BYPASS] Swallow, G. and Goguen, R., "RSVP Label Allocation for 9. Authors' Addresses
Backup Tunnels", Internet Draft, draft-swallow-rsvp-bypass-label-
01.txt, November 2000
[DETOUR] Gan, D. et al., "A Method for MPLS LSP Fast-Reroute Using
RSVP Detours", Internet Draft, draft-gan-fast-reroute-00.txt, April
2001
[GMPLS IS-IS] Kompella, K. 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. et al., "OSPF Extensions in Support of
Generalized MPLS", Internet Draft, draft-kompella-ospf-gmpls-
extensions-01.txt, February 2001
8. Authors' Addresses
Alia Atlas Alia Atlas
Avici Systems Avici Systems
101 Billerica Avenue 101 Billerica Avenue
N. Billerica, MA 01862 N. Billerica, MA 01862
Voice: +1 (978) 964-2070 Voice: +1 (978) 964-2070
Email: aatlas@avici.com Email: aatlas@avici.com
Curtis Villamizar Markus Jork
Email: curtis@avici.com Avici Systems
101 Billerica Avenue
Caren Litvanyi N. Billerica, MA 01862
PO Box 2535 Voice: +1 (978) 964-2142
Cupertino, CA 95015 Email: mjork@avici.com
Email: litvanyi@synack.net
 End of changes. 95 change blocks. 
476 lines changed or deleted 338 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/