Internet Draft Alia Atlas Expires: January 2002 Curtis Villamizar - Avici Systems Caren Litvanyi - Qwest Communications July 2001 MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute draft-atlas-rsvp-local-protect-interop-00.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 the local protection enhancements given in [draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage is clarified in [draft-swallow-rsvp-bypass-label-01.txt], and routers implementing solely [draft-gan-fast-reroute-00.txt] do not interoperate to provide local protection. Those routers which follow the guidelines given in this draft should be able to interoperate with either type of implementation. Atlas et al. [Page 1] Internet Draft July 2001 Contents 1. Introduction .............................................. 3 2. Terminology ............................................... 3 3. Ingress Support ........................................... 4 3.1 Requesting Local Protection .............................. 4 3.2 Detecting Protection Information ......................... 5 4. Distinguishing Backups from Different PLRs Based on RESV .. 6 5. PLR Behavior .............................................. 6 5.1 Selecting Backup LSP Type ................................ 7 5.2 Bypass Tunnels ........................................... 8 5.3 Make-Before-Break on Backup Tunnels ...................... 8 5.3.1 Shared-Explicit and Backup LSPs ........................ 9 5.3.2 Make-Before-Break with Sender Addresses ................ 10 5.4 Catching ResvTears and Appropriate PathErrs .............. 11 5.5 Handling Resource Preemption ............................. 11 6. Merge Node Behavior ....................................... 12 6.1 Ignore Path Tears Unless From Ingress .................... 12 6.2 Label Space .............................................. 12 6.3 Simple and Detour Backup LSPs ............................ 12 6.4 ResvTears ................................................ 13 7. Security Considerations ................................... 14 8. References ................................................ 14 9. Authors' Addresses ........................................ 14 Atlas et al. [Page 2] Internet Draft July 2001 1. Introduction Routers may implement the local protection enhancements given in [RSVP-TE], whose usage 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. This draft assumes that a router falls into one of the following three sets: A. Implements both the local protection enhancements given in [RSVP-TE] and [DETOUR] as described in this draft. B. Implements only [DETOUR]. C. Implements only the local protection enhancements given in [RSVP-TE]. The guidelines given in this draft should allow routers in set A to interoperate with either of the other two sets of routers, but not both. A network with routers in set A and set B will be able to provide local protection. A network with routers in set A and set C will be able to provide local protection. A network that contains routers from both set B and set C will not be able to provide local 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 specified for Shared-Explicit which distinguish between primary and backup bandwidth reservations. This is necessary to support make- before-break on backup tunnels; how to support make-before-break on backup tunnels is described. More details on handling PathErrs and resource preemption is provided. 2. Terminology PLR (Point-of-Local-Repair): Any node along the primary LSP's path is 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. Atlas et al. [Page 3] Internet Draft July 2001 Backup Tunnel: A backup tunnel is logically created from the PLR to a merge node on the primary LSP's path; which specific merge node is used can vary between the backup LSPs contained in the backup tunnel. The backup tunnel can contain one or more backup LSPs for a given primary LSP. The concept of a backup tunnel permits make-before- break for backup LSPs. Backup LSP: A backup LSP extends from its origin at the PLR to a specific merge node, where it rejoins the primary LSP. A backup LSP is part of a Backup Tunnel. There are three types of backup LSPs - simple, detour and unsignalled. Simple Backup LSP: A Simple Backup LSP is a backup LSP whose PATH message does not include the DETOUR object. The ERO contains the selected backup path to the merge node and then an exact duplicate of the primary LSP's ERO from that merge node to the egress. Detour Backup LSP: A Detour Backup LSP is a backup LSP whose PATH message includes the DETOUR object. The ERO simply contains the selected backup path to the merge node. Bypass Tunnel: A tunnel from the PLR of interest to 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 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 when each potential PLR in its path has a current backup tunnel available. 3. Ingress Support 3.1 Requesting Local Protection The [DETOUR] and [BYPASS] propose different methods for the ingress to signal that an LSP desires local protection. These methods are not mutually incompatible. The ingress can both include the 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]. Atlas et al. [Page 4] Internet Draft July 2001 By including the FAST_REROUTE object, any nodes on the primary LSP 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 SESSION_ATTRIBUTE, the resulting Label subobjects in the RRO permit 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 The primary tunnel's ingress is responsible for determining when rerouting of the primary path is desirable. For instance, if local protection is in use on the current primary LSP, it would be desirable to compute a new primary LSP. The ingress must also determine when to move from a current LSP to a 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 an LSP's path are currently providing local protection and which 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 the necessary information to Atlas et al. [Page 5] Internet Draft July 2001 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], however [BYPASS] alone does not provide the means to determine when local protection is fully available. To permit proper ingress behavior, it is desirable that the ingress be configured with information about which nodes, if any, 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. Distinguishing Backups from Different PLRs Based on RESV In its Section 4.3, [DETOUR] states "A merging node may receive multiple Path messages from different interfaces, but with identical SESSION and SENDER_TEMPLATES", implying that the same SENDER_TEMPLATE (and, therefore, the FILTER_SPEC) for the detour backup LSPs should be used as for the primary LSP. Because the DETOUR object is only available on the PATH message, this can create a problem at a midpoint node in identifying which detour backup LSP a given RESV was received for. Consider the following example: /--F----G----H--\ / | | | \ A----B----C----D----E Assume that the primary LSP is A-B-C-D-E. Let the detour backup LSP from B be B-F-G-H-D. Let the detour backup LSP from C be C-G-H-E. When G receives a RESV message, it cannot determine whether that RESV is for the detour backup LSP starting at B or at C. To solve this problem, when signalling a detour backup LSP, the PLR can change the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE object to be an IPv4 (IPv6) address associated with the PLR. The contents of the SENDER_TEMPLATE are copied into the FILTER_SPEC and sent as part of the RESV message. This will enable G, in the above example, to determine whether the RESV message is for the detour backup LSP from B or from C. This change of the "IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE is suggested for simple backup LSPs in [BYPASS]. 5. PLR Behavior Atlas et al. [Page 6] Internet Draft July 2001 Once an ingress or midpoint node has determined that a given LSP is 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 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 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 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 to configure SRLGs for external links must be supported. 5.1 Selecting Backup LSP Type The PLR may decide to create a backup LSP either when it has received 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 what type of routers share the local domain. If the other routers implement [BYPASS], then either a simple backup LSP or an unsignalled backup LSP should be created. If the other routers implement [DETOUR], then a detour backup LSP should be created. If the PLR is to create a backup LSP when it has received the primary 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 routers will support the [DETOUR]. The PLR will attempt to create a detour backup LSP. If no FAST_REROUTE object is found or if the detour creation is rejected, as indicated by a PathErr with the error 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 Atlas et al. [Page 7] Internet Draft July 2001 without a DETOUR object. When the PLR creates a backup LSP after it has received the primary 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. 5.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 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 LSPs discussed in [BYPASS]. It is also possible to have simple backup LSPs or detour backup LSPs be tunneled through a bypass tunnel. To do this, the simple or detour backup LSP's PATH message 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 object through a node which does not support [DETOUR] to reach a merge node that does support [DETOUR] and does not support LRO. 5.3 Make-Before-Break on Backup Tunnels In supporting make-before-break on backup tunnels, the option of using a different LSP-ID is not available. As described in [RSVP-TE], when doing a make-before-break on a regular tunnel, the ingress will allocate a new LSP ID to be used when creating a new LSP. Because the SESSION object of the current LSP and that of the new LSP are the same and Shared-Explicit (SE) is specified, resources will be shared. When signalling a backup 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 Atlas et al. [Page 8] Internet Draft July 2001 signalling the backup LSP is the same as the SESSION object of the primary LSP. This behavior is common in [BYPASS] and [DETOUR]. 5.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 the SESSION object, as is specified 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 a primary LSP which goes A-B-C-D-E-F-G. The backup LSP 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 on C-D. This would mean that insufficient resources are reserved in the event of a failure of link E-F. To resolve this requires that the "IPv4 (IPv6) tunnel sender address" of the FILTER_SPEC be considered when determining whether LSPs should share resources once Shared-Explicit is specified. Instead of maintaining one category per SESSION object, two categories would be maintained. The first would be for primary LSPs; the second would be for backup LSPs. The LSPs would be categorized based upon the FILTER_SPEC's "IPv4 (IPv6) tunnel sender address" according to the following logic: a) If a DETOUR object is included in the PATH message, then the LSP belongs to the backup category. This provides interoperability with a strict implementation of [DETOUR]. b) Else if the SESSIONS's "Extended Tunnel ID" is all zeros, then the LSP belongs to the primary category. c) Else if the "IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE or FILTER_SPEC matches the SESSION's Atlas et al. [Page 9] Internet Draft July 2001 "Extended Tunnel Id", an LSP belongs to the primary category. d) Else an LSP belongs to the backup category. The "IPv4 (IPv6) tunnel sender address" in the SENDER_TEMPLATE or FILTER_SPEC does not match the SESSION's "Extended Tunnel Id"; the PLR's address is in the "IPv4 (IPv6) tunnel sender address", indicating that the LSP is a backup. This modification of the rules determining what constitutes a category to share resources provides seperate accounting for primary LSPs in a TE tunnel and for the backup LSPs associated with that TE tunnel. If all backup LSPs always have zero bandwidth reserved, then this enhancement is not needed. Constraining all backup LSPs to use zero bandwidth is a severe restriction and unacceptable in some situations. 5.3.2 Make-Before-Break with Sender Addresses The prior subsection clarifies how Shared-Explicit can be specified for backup LSPs. The Shared-Explicit is required for make-before- break, as explained in [RSVP-TE]. The other piece necessary for make-before-break is a way of distinguishing the current backup LSP from the new backup LSP. For a regular TE tunnel, this is done by changing the LSP ID. However, the LSP ID is used to associate the backup tunnel with a specific primary LSP. Therefore, the LSP ID cannot be changed to do a make-before-break on the backup tunnel. The other content of the SENDER_TEMPLATE (and FILTER_SPEC) is the "IPv4 (IPv6) tunnel sender address". As suggested in [BYPASS], the PLR will fill out this address with one of the PLR's addresses for simple backup LSPs. Section 4 suggests doing the same for detour backup LSPs. Any router which can distinguish 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. 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. To effect a reroute or a bandwidth change on a backup tunnel, 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]. Atlas et al. [Page 10] Internet Draft July 2001 To support make-before-break on backup tunnels 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 be globally unique if chosen from public address space. 5.4 Catching ResvTears and Appropriate PathErrs The PLR behavior described in this section should only start after the primary LSP is known to be successfully created. If the backup tunnel is created after a RESV is received for the primary LSP, then it suffices 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 a RESV has been received for the primary LSP. Under those circumstances, the PLR must not forward ResvTear [DETOUR]. Instead, when a ResvTear is received, the PLR should move traffic to the backup tunnel, if it is up, and then not propagate the ResvTear upstream towards the ingress. The PLR must also handle certain PathErrs similarly to how it handles ResvTears. If the PLR receives a PathErr with an error code of "Policy Control failure", as happens when the primary LSP is preempted, or a PathErr with an error code of "Routing Problem" and a sub-code of "No route available toward destination", as may happen when a link or node fails, then the PLR should similarly move traffic 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 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". 5.5 Handling Resource Preemption It is possible for a primary LSP to have its resources preempted, due to the arrival and admission of another LSP. If the PLR is making this determination and has a backup tunnel, which is currently up, Atlas et al. [Page 11] Internet Draft July 2001 for that primary LSP, then the PLR should move traffic from the primary LSP to the backup tunnel and then send a PathErr with an error code of "Notify" and an error value of "Tunnel locally repaired". When this type of PathErr is received at the ingress, the ingress should reroute the tunnel onto a new primary LSP using make- before-break. 6. Merge Node Behavior 6.1 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 the above example, consider what 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 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 the primary LSP. This unfortunate loss of capability can be remedied 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. 6.2 Label Space To most easily support all types of backup LSPs, a merge node should use a platform-wide (aka global) 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 must 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. Atlas et al. [Page 12] Internet Draft July 2001 6.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 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 backup LSP, the router will not tear down the primary LSP to the egress. 6.4 ResvTears When a router receives a ResvTear for an LSP and it is not a PLR for 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. For unsignalled backup LSPs, the router does not know it 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 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. Atlas et al. [Page 13] Internet Draft July 2001 A will 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. 7. Security Considerations This draft provides guidlelines for the use of existing protocol mechanisms defined in [RSVP-TE], [BYPASS], and [DETOUR] which are designed to maximize interoperability. No new protocol is defined. The usage or existing protocol described here does not introduce any additional security risks. 8. References [RSVP-TE] Awduche, D. 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", 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 9. Authors' Addresses Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 Voice: +1 (978) 964-2070 Email: aatlas@avici.com Atlas et al. [Page 14] Internet Draft July 2001 Curtis Villamizar Email: curtis@avici.com Caren Litvanyi PO Box 2535 Cupertino, CA 95015 Email: litvanyi@synack.net Atlas et al. [Page 15]