Internet Draft Network Working Group Robert Goguen Internet Draft Cisco Systems, Inc. Expiration Date: May 2001 George Swallow Cisco Systems, Inc. November 2000 RSVP Label Allocation for Backup Tunnels draft-swallow-rsvp-bypass-label-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document describes the use of RSVP, to establish backup tunnels for local repair of LSP tunnels. Goguen & Swallow [Page 1] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 Contents 1 Introduction .......................................... 3 2 Labels for backup tunnels .............................. 4 3 Signaling for backup tunnels ........................... 5 3.1 Identification and association of backup LSP tunnels ... 5 3.2 ERO contents ........................................... 7 4 Efficient signaling for the global label case .......... 7 5 Notification of local repair ........................... 7 6 Security Considerations ................................ 8 7 Intellectual Property Considerations ................... 8 8 References ............................................. 8 9 Authors' Addresses ..................................... 8 Goguen & Swallow [Page 2] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 1. Introduction This document describes the use of RSVP[RFC2205], to establish backup tunnels for local repair of LSP tunnels. The RSVP extensions for setting up LSP tunnels are described in [2]. In order to meet the needs of realtime applications such as Voice over IP, it is highly desirable to be able to repair LSP tunnels in 10s of milliseconds. We use the term local repair to when referring to techniques which accomplish this. There are two basic strategies for effecting local repair. These are one to one backup and one to many backup. In the one to one case, a label switched path is established which intersects the original tunnel somewhere downstream of the point of local repair. For each LSP which is backed up, another backup LSP is established. [R1]---[R2]-----[R3]----[R4]---[R5] \ / [R6]---[R7] For example, suppose that in the simple topology above, R1 creates a tunnel to R5 via the path [R1->R2->R3->R4->R5]. R2 can provide local repair by creating a partial backup tunnel [R2->R6->R7->R4] which merges with the original tunnel [R1->R2->R3->R4->R5] at R4. A second means of backing up LSPs is to take advantage of the label stack. Instead of creating a separate LSP for every backed-up LSP tunnel, a single LSP is created which serves to backup up a set of tunnels. We call such a tunnel a bypass tunnel. The bypass tunnel itself is established just like any other LSP tunnel. Again the bypass tunnel must intersect the original tunnel(s) somewhere downstream of the point of local repair. This of course implies that the set of tunnels being backed up all pass through some common downstream node. All tunnels which pass through the point of local repair and through this common node which do not use the facilities being bypassed are candidates for this set of tunnels. To effect the repair of the backed up tunnels, packets belonging to a repaired tunnel are redirected onto the bypass tunnel. An additional label representing the bypass tunnel is stacked onto the redirected packets. At the penultimate hop of the bypass tunnel, the label for the bypass tunnel is popped off the stack, revealing the label which represents the tunnel being backed up. Returning to the above example, R2 in this case would build a bypass Goguen & Swallow [Page 3] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 tunnel [R2->R6->R7->R4]. The doubled lines represent this tunnel. The backup path for [R1->R2->R3->R4->R5] again rejoins the original path at R4, but its path is now [R1->R2->R4->R5] with the bypass tunnel as the connection between R2 and R4. [R8] \ [R1]---[R2]----[R3]----[R4]---[R5] \ // \ [R6]===[R7] [R9] The scalability improvement comes in that this bypass tunnel can also be a backup for tunnels from any of R1, or R2, R8 to any of R4, R5, or R9 which traverse the link R2->R3. 2. Labels for backup tunnels In this section we consider the issues of binding labels to these various backup entities. In this discussion we refer to the point of local repair as PLR or the PLR node depending on context. Similarly, we refer to the point at which the backup tunnel merges back into the original tunnel as the merge point or merge node. Note that it is possible that the merge node is also the tunnel tail. In MPLS, a node may have a single label space which is global to the node, or it may have multiple label spaces, some of which are specific to particular interfaces. Whether one to one backup or many to one backup is used, a means for obtaining labels which properly represent the backed up tunnels is required. The simplest case is when the merge node is the next hop of both the original tunnel and of the backup tunnel and the merge node has a global label space. In the one to one case this situation would arise as follows. There exist multiple links between the local- repair node and the merge node. An LSP tunnel crosses one of these links. A parallel link will be used as the backup should the primary link fail. Since the merge node is using a global label space, it would properly recognize packets which were sent on the parallel link. In the many to one case, the above situation arises in a more general way. Consider any two neighbor nodes, L and M. If L wishes to backup the tunnels crossing the link to M it could establish a backup tunnel to M via any available route which avoids the backed up link. Again, since M is using a global label space, to effect the bypass, L Goguen & Swallow [Page 4] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 would simply do the normal label swap, and then push on the label for the backup tunnel. The penultimate hop of the backup tunnel would pop the label for the backup tunnel, revealing the label which M expects. When a failure occurs and the backup comes into use, a means of maintaining the RSVP state is required. In this simple case the Path messages can simply be sent via the backup link or tunnel as the case may be. Except for these specific cases, additional labels must be assigned and a means of signaling is required. Returning to the bypass tunnel example above, if R4 does not use a global label space then a label must be assigned out of the label space used by R4 on the interface terminating the link from R7. if, however, R4 has a global label space then the label which R2 uses during the backup could be the same label value which is used by R3. In the next section we describe a general means of obtaining backup labels. In the following section we describe an efficient means communicating labels where global label spaces are used. 3. Signaling for backup tunnels A number of objectives must be met to obtain a satisfactory signaling solution. These are summarized as follows: 1. Unambiguously and uniquely identify backup tunnels 2. Unambiguously associate primary tunnels with their backup tunnels 3. Work with both global and non-global label spaces 4. Allow for merging of backup tunnels 5. Maintain RSVP state during and after fail-over. 3.1. Identification and association of backup LSP tunnels LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects. The relevant fields are: IPv4 tunnel end point address IPv4 address of the egress node for the tunnel. Goguen & Swallow [Page 5] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. IPv4 tunnel sender address IPv4 address for a sender node LSP ID A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The first three of these are in the SESSION object and are the basic identification of the tunnel. The last two are in the SENDER_TEMPLATE. The LSP_ID is used to differentiate multiple LSPs during a tunnel reroute procedure. During this procedure, multiple LSPs each with their own LSP_ID may be active simultaneously. It is quite possible that a node which is downstream of the point of local repair on the LSP being backed up is also upstream of the point of local repair for some other LSP associated with the tunnel. It is thus necessary to properly associate the LSP_ID of a backup tunnel with the LSP_ID of the tunnel being backed up. We therefore propose that backup tunnels be identified as follows. The SESSION object and the LSP_ID are copied from the LSP tunnel being backed up. The IPv4 tunnel sender address is set to an address of the PLR node. If the head-end of a tunnel is also acting as the PLR, it must choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel. Goguen & Swallow [Page 6] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 3.2. ERO contents The PLR creates an ERO for the backup LSP tunnel. It does this by operating on the original ERO or on the contents of a received RRO. Abstract nodes which precede the merge point are removed. In the case of signaling over a bypass tunnel, the procedure is now complete. In the one-to-one backup case the, an explicit route from the PLR node to the merge node is prepended to the ERO. 4. Efficient signaling for the global label case When global labels are in use and bypass tunnels are used as the means of local repair, a more efficient means of backup label distribution can be employed. When using a bypass tunnel, the backed up tunnels are only one LSP hop from rejoining their primary LSPs. If the merge node is using a global label space, then the label necessary for the back up tunnel is the label already assigned by the merge node. By using the label record option of the ROUTE_RECORD procedure, downstream labels can be known by upstream nodes without further protocol interactions. In this case no Path message is sent down the bypass tunnel prior to a failure. When a failure occurs, the PLR updates the ERO as above and begins refreshing the LSP down the bypass tunnel. This ensures that the LSP state is refreshed in the merge node and nodes further downstream. 5. Notification of local repair In many situations, the route used during a local repair will be less than optimal. The point of the local repair is to keep high priority and loss sensitive traffic flowing while a more optimal rerouting of the tunnel can be effected by the head-end of the tunnel. Thus the head-end needs to know of the failure. To provide this notification, the point of local repair SHOULD send a PathErr message with error code of "Notify" and an error value of "Notification of local repair". Goguen & Swallow [Page 7] Internet Draft draft-swallow-rsvp-bypass-label-01.txt November 2000 6. Security Considerations These procedures do not change the trust model of RSVP [RFC2205] and draft-ietf-mpls-rsvp-tunnel-07.txt[RSVP-TE]. As such no additional security risks are posed. 7. Intellectual Property Considerations Cisco Systems may have intellectual property rights claimed in regard to some or all of the specification contained in this document. 8. References [RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August, 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 9. Authors' Addresses Robert Goguen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8095 Email: rgoguen@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 Email: swallow@cisco.com Goguen & Swallow [Page 8]