Y. Suemura Internet Draft I. Nishioka Document: draft-suemura-gmpls-restoration-signaling-00.txt A. Kolarov Expires: August 2002 NEC February 2002 Extensions to RSVP-TE for Supporting Multiple Protection and Restoration Types 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes extensions to RSVP-TE for supporting multiple protection/restoration types (LSP Protection Types) in end-to-end protection/restoration. We propose the LSP Protection Type field to be defined in the Protection Object. Another aim of this document is prevention of an unintended connection for extra traffic when traffic from a failed working LSP is switched over to a backup LSP. We address this issue and propose a 3-way switchover signaling procedure. Suemura et al. Expires Aug. 2002 [Page 1] Extensions to RSVP-TE for Supporting... Feb. 2002 NAME OF I-D: http://www.ietf.org/internet-drafts/draft-suemura-gmpls-restoration- signaling-00.txt SUMMARY This document proposes extensions to RSVP-TE for supporting multiple protection/restoration types (LSP Protection Types) in end-to-end protection/restoration. We propose the LSP Protection Type field to be defined in the Protection Object. Another aim of this document is prevention of an unintended connection for extra traffic when traffic from a failed working LSP is switched over to a backup LSP. We address this issue and propose a 3-way switchover signaling procedure. RELATED DOCUMENTS draft-bala-protection-restoration-signaling-00.txt draft-li-shared-mesh-restoration-01.txt draft-ietf-mpls-generalized-rsvp-te-06.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK CCAMP WG WHY IS IT TARGETED AT THIS WG This document addresses the following work item in the CCAMP charter: - Abstract link and path properties needed for link and path protection. Define signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling and measurement protocols, either separately or in combination. JUSTIFICATION This document defines signaling mechanisms for supporting multiple protection/restoration types in path protection/restoration. Defining signaling mechanisms for path protection/restoration is included in the CCAMP WG tasks stated in the CCAMP charter. Support of multiple protection/restoration types is essential for applying GMPLS protection/restoration to service provider's networks. So, I believe this document is justified for the CCAMP WG. Suemura et al. Expires Aug. 2002 [Page 2] Extensions to RSVP-TE for Supporting... Feb. 2002 1. Introduction There are two failure recovery techniques for optical networks: 1) local span protection and 2) end-to-end protection/restoration [1]. Local span protection refers to the protection of the link between two neighboring nodes. End-to-end protection/restoration refers to the protection/restoration of an entire connection from the initiator node to the terminator node. This document describes two unaddressed issues in end-to-end protection/restoration. One is support for multiple protection/restoration modes. Although [2] describes extensions to RSVP-TE [3] for supporting shared mesh restoration, it does not mention support for other protection/restoration modes such as 1+1 and 1:1. The other issue is prevention of an unintended connection for extra traffic when traffic from a failed working LSP is switched over to a backup LSP. This document addresses these issues and proposes extensions to RSVP-TE. 2. Overview of End-to-end Protection and Restoration In end-to-end protection and restoration, a working LSP and a backup LSP are set up for the connection. If the working LSP fails, connection traffic is switched over to the backup LSP. There are three modes in end-to-end protection and restoration. 1+1 protection: A working LSP and a dedicated, resource-disjoint backup LSP are established for the connection. Connection traffic is simultaneously sent on both LSPs and received from one of the LSPs by the receiving end node. 1:1 restoration: A working LSP is established for the connection. A dedicated resource-disjoint backup LSP is pre-routed but not established. The backup LSP is established after the working LSP detects a failure. Shared restoration: A working LSP is established for the connection. A resource-disjoint backup LSP is pre-routed but not established. The resources along the backup LSP may be shared among multiple connections being protected. The backup LSP is established after one of the working LSPs detects a failure. 1+1 protection achieves the shortest recovery time since it does not require switchover signaling for setting up intermediate nodes. Shared restoration cannot recover concurrently failed multiple connections that share common backup resources. Therefore, in terms of service class, 1+1 protection is the best, and shared restoration is the worst. However, in terms of resource utilization efficiency, 1+1 protection is the worst because backup resources cannot be used for extra traffic. Shared restoration achieves the most efficient resource utilization as a result of resource sharing. As shown above, there is a trade-off between service classes and Suemura et al. Expires Aug. 2002 [Page 3] Extensions to RSVP-TE for Supporting... Feb. 2002 resource utilization efficiency. An optical network should support more than one protection/restoration mode so that an appropriate mode can be chosen to provide a required service class. 3. LSP Protection Types Each of protection/restoration modes shown in the previous section requires different operations at nodes along the backup LSP. Therefore, signaling messages for setting up the backup LSP must identify protection/restoration modes (LSP Protection Type) applied to the backup LSP. We propose the following LSP Protection Types to be defined: Dedicated 1+1 Dedicated 1:1 Shared Unprotected Extra Traffic "Dedicated 1+1", "Dedicated 1:1" and "Shared" correspond to 1+1 protection, 1:1 restoration and shared restoration respectively. "Unprotected" LSPs do not require end-to-end restoration, but local span protection may protect each link on the unprotected LSP. "Extra Traffic" LSPs use bandwidth reserved for backup LSPs for the connections with 1:1 and shared restoration. The extra traffic LSPs may be released when the working LSP fails, and connection traffic is sent on the backup LSP. 4. Labeled vs. Unlabeled Backup LSP There are two approaches for pre-assigning a backup LSP in case of 1:1 or shared restoration: labeled and unlabeled. In the labeled approach, labels are allocated in advance at nodes along the backup LSP. After detecting a failure, switchover signaling only sets cross-connections at the nodes along the backup LSP. In the unlabeled approach, since labels are not allocated at nodes along the backup LSP before a failure, switchover signaling first allocates labels and then sets cross-connections. The unlabeled approach is potentially slower in recovery and more complex in implementation than the labeled approach. However, it still has two advantages shown below: (1) Higher availability of Extra Traffic LSPs: Consider the case when working and backup LSPs are setup for a connection with 1:1 restoration and bandwidth for the backup LSP is used for an extra traffic LSP. In the labeled approach, the extra traffic LSP is always released when the working LSP fails because it uses labels allocated for the backup LSP. In the unlabeled approach, on the other hand, the extra traffic LSP is released only when the working LSP fails and the nodes on the backup path are not able to allocate a new Suemura et al. Expires Aug. 2002 [Page 4] Extensions to RSVP-TE for Supporting... Feb. 2002 label for the backup LSP. This results in higher availability of extra traffic LSPs. (2) Better resource utilization: Consider the case with three working LSPs, W1, W2 and W3, traversing SRLGs as shown below, and, their corresponding backup LSPs, B1, B2 and B3, going through the same link. W1: SRLG list = {S1, S2} W2: SRLG list = {S2, S3} W3: SRLG list = {S1, S3} In the labeled approach, B1, B2 and B3 require three labels at this link because they are not SRLG-disjoint with each other. In the unlabeled approach, since no more than two LSPs are affected simultaneously by a single SRLG failure, bandwidth for only two backup LSPs is reserved. In this case, the unlabeled approach uses resources (labels) 1.5 times more efficient than the labeled approach. 5. Preventing Unintended Connections In 1:1 and shared restoration, switchover from a working LSP to a backup LSP may cause an unintended connection to be established and traffic from the failed working path to be delivered to an extra traffic LSP instead of the backup LSP. In Figure 1, for example, it is possible to have a working LSP, A-B-C-D, and a backup LSP, A-E-F-D. Having an extra traffic LSP, G-E-F-H is also possible. This extra traffic LSP uses label X on link E-F. If the backup LSP is established from node A to node F and label X is allocated to this LSP, the backup LSP is unintentionally connected to the extra traffic LSP for a short time until node F sets up a cross-connect for the backup LSP. This can be prevented if the extra traffic LSP is released before the switchover occurs. B----C / \ A D \ / E----F / \ G H Figure 1 6. Extensions to RSVP-TE We propose a switchover signaling procedure based on RSVP-TE [3] for preventing unintended connections in 1:1 and shared restoration. In [2], definition of a new flag (R-bit) in the Protection Object defined in [3] is proposed. The R-bit is used for supporting labeled and unlabeled shared restoration. Our switchover signaling procedure requires an additional flag (P-bit) to be defined in the Protection Suemura et al. Expires Aug. 2002 [Page 5] Extensions to RSVP-TE for Supporting... Feb. 2002 Object. We also propose a new field indicating an LSP Protection Type to be defined in the Protection Object. This is used to distinguish LSP Protection Types when setting up working and backup LSPs. 6.1 Switchover Procedure for a Uni-directional Connection If a working LSP for a uni-directional connection fails, the terminator node detects the LSP failure by some means not defined in this document. For example in all optical networks, the terminator node can detect the LSP failure by monitoring the optical signal power. In SONET networks, the terminator can detect the LSP failure by receiving path AIS sent from an intermediate node. If the LSP Protection Type for the connection is "Dedicated 1:1" or "Shared", the terminator node initiates signaling along the backup LSP for switching over the connection traffic. To prevent an unintended connection (see Section 5), we propose the 3-way switchover signaling procedure shown below. 1. Extra Traffic Release Message: A Resv message with R-bit not set, P-bit set, and RESV_CONFIRM object not set, is sent from the terminator node to the initiator node along the backup LSP. 2. Switchover Request Message: A Path message with R-bit not set, P- bit set, is sent from the initiator node to the terminator node along the backup LSP. 3. Switchover Response Message: A Resv message with R-bit not set, P- bit set, and RESV_CONFIRM object indicating Node ID of the terminator node, is sent from the terminator node to the initiator node along the backup LSP. Actions taken by the node that has received these messages depends on a type of the backup LSP (labeled or unlabeled) (see Section 4). These actions are described in the following sections. 6.1.1 Switchover Procedure for a Labeled Backup LSP 1. Extra Traffic Release Message The node that has received this message checks whether the labels that are allocated for the backup LSP are used for extra traffic LSPs or not. If used, the node releases the extra traffic LSP. The procedure for releasing the extra traffic LSP is for further study. 2. Switchover Request Message The node that has received this message sets a cross-connection for the backup LSP. 3. Switchover Response Message Suemura et al. Expires Aug. 2002 [Page 6] Extensions to RSVP-TE for Supporting... Feb. 2002 The node that has received this message confirms completion of the cross-connection. 6.1.2 Switchover Procedure for an Unlabeled Backup LSP 1. Extra Traffic Release Message The node that has received this message checks whether there is an unallocated label for the link on the route of the backup LSP. If there is not an unallocated label and there is an extra traffic LSP on the link, the node releases the extra traffic LSP and reserves the released label for the backup LSP. If there is an unallocated label, the node reserves it for the backup LSP. 2. Switchover Request Message The node that has received this message allocates the reserved label and sets a cross-connection for the backup LSP. 3. Switchover Response Message The node that has received this message confirms completion of the label allocation and the cross-connection. 6.2 Switchover Procedure for a Bi-directional Connection If a working LSP for a bi-directional connection fails, the initiator node or the terminator node detects the LSP failure (uni-directional failure), or, both of the initiator and terminator nodes detect the LSP failure (bi-directional failure). If the terminator node detects the LSP failure, it initiates switchover signaling. The signaling procedure is the same as that for a uni-directional connection except that labels are reserved and allocated for both directions. If the initiator node detects the LSP failure, it sends a ResvErr message to the terminator node. If the terminator node has already detected the same LSP failure, the ResvErr massage is discarded. Otherwise, the terminator node initiates switchover signaling. 6.3 Extensions to the Protection Object The format of the newly proposed Protection Object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|R|P| Reserved | LSP | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S (1 bit) 0 Working (Primary) Suemura et al. Expires Aug. 2002 [Page 7] Extensions to RSVP-TE for Supporting... Feb. 2002 1 Backup (Secondary) R (1 bit) 0 Allocation 1 Reservation P (1 bit) (New) 0 Normal 1 Switchover LSP Protection Type(3 bit) (New) 0x7 Reserved 0x6 Reserved 0x5 Reserved 0x4 Dedicated 1+1 0x3 Dedicated 1:1 0x2 Shared 0x1 Unprotected 0x0 Extra Traffic Link Flags(6 bit) 0x20 Enhanced 0x10 Dedicated 1+1 0x08 Dedicated 1:1 0x04 Shared 0x02 Unprotected 0x01 Extra Traffic P-bit is needed to indicate difference between the switchover signaling messages and normal Path and Resv messages. LSP Protection Type indicates a protection/restoration mode which should be provided by the working LSP and the backup LSP being established. Note that it is different from what indicated by the Link Flags. Link Flags indicate protection types which should be provided by a link being traversed by the LSP[4]. 7. Security Considerations No security issues are considered in this document. Suemura et al. Expires Aug. 2002 [Page 8] Extensions to RSVP-TE for Supporting... Feb. 2002 8. References [1] B. Rajagopalan et al., " Signaling for Protection and Restoration in Optical Mesh Networks," draft-bala-protection- restoration-signaling-00.txt, work in progress. [2] G. Li et al., "RSVP-TE Extensions For Shared-Mesh Restoration in Transport Networks," draft-li-shared-mesh-restoration-01.txt, work in progress. [3] P. Ashwood-Smith et al., "Generalized MPLS Signaling - RSVP-TE Extensions," draft-ietf-mpls-generalized-rsvp-te-06.txt, work in progress. [4] P. Ashwood-Smith et al., "Generalized MPLS - Signaling Functional Description," draft-ietf-mpls-generalized-signaling- 07.txt, work in progress. 9. Author's Addresses Yoshihiko Suemura NEC Corporation 4-1-1, Miyazaki, Miyamae-ku, Kawasaki, 216-8555, Japan Phone: +81-44-856-8109 Email: y-suemura@bp.jp.nec.com Itaru Nishioka NEC Corporation 4-1-1, Miyazaki, Miyamae-ku, Kawasaki, 216-8555, Japan Phone: +81-44-856-8109 Email: i-nishioka@cb.jp.nec.com Aleksandar Kolarov NEC USA, Inc. 4 Independence Way, Princeton, NJ 08540, USA Phone: +1-609-951-2985 Email: kolarov@nec-lab.com