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-01.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. The guidelines also specify how to support make- before-break with backup LSPs. 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. 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 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], according to the guidelines in [BYPASS]. 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 must 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]. 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 the IPv4 and IPv6 address subobjects 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 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 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. 4.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 Atlas et al. [Page 6] Internet Draft July 2001 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 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. 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 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 Atlas et al. [Page 7] Internet Draft July 2001 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. 4.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 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 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 Atlas et al. [Page 8] Internet Draft July 2001 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. Consider if the backup LSP at B is B-I-J-F. If the link B-C failed and A tried to create a new primary LSP, the new LSP would have 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 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 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 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 Atlas et al. [Page 9] Internet Draft July 2001 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. 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 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]. 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. 4.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 Atlas et al. [Page 10] Internet Draft July 2001 "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". 4.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, 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. 5. Merge Node Behavior 5.1 Label Space To support all types of backup LSPs, a merge node must 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 should 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 Atlas et al. [Page 11] Internet Draft July 2001 /--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. 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 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. 5.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 Atlas et al. [Page 12] Internet Draft July 2001 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. 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. 6. 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. 7. 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. Atlas et al. [Page 13] Internet Draft July 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 8. 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 Email: litvanyi@synack.net Atlas et al. [Page 14]