CCAMP Working Group Internet Draft Document: draft-shimano-imajuku-gmpls-restoration-00.txt Katsuhiro Shimano Wataru Imajuku (NTT) Expires:August 2003 February 2003 RSVP extensions for gmpls restoration signaling Status of this Memo This document is an Internet-Draft and is in full compliance 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract There are some efforts to categorize restoration schemes [Restoration-analysis]. We consider that pre-planned restoration has some advantages, for instance, enhancing the quickness to reduce downtime, extensions to recovery classes, risk management, and totally integrated distributed control. This document describes some requirements and extended properties for message objects on RSVP-TE [RSVP-GMPLS], LSR procedures, and pre-planned GMPLS restoration. We append a procedure to the recovery steps for working and restoration setup. Some objects are additionally required with respect to establishing working LSPs and reservation of restoration LSPs. This document shows that restoration activation is also needed and clarifies the required properties. Shimano [Page 1] Internet Draft draft-shimano-imajuku-gmpls-restoration-00.txt Feburary 2003 1. Conventions used in this document APS: Automatic Protection Switching GMPLS : Generalized Multi-Protocol Label Switching LSR: Label Switched Router LSP: Label Switched Path OTN: Optical Transport Network OSPF: Open Shortest Path First RSVP: Reservation Protocol 2. Introduction We believe that there are three main requirements for GMPLS network recovery. First, speed is the most important requirement in order to maintain a high level of availability and communication quality. Once a fault occurs in a transport network, the transport and client networks each initiate fault recovery. After that, when the fault is resolved and the associated retrieval process is performed, the client networks reconfigure themselves again. In order to avoid such behavior, the recovery must be completed before activation of the fault recovery on the client networks. These networks typically initiate the recovery scheme within a certain duration after fault detection. Therefore, the transport networks must complete their own recovery before recovery is initiated in the clients. The second requirement is harmonization between the restoration scheme and distributed network control. Most conventional restoration schemes assume a centralized network control. On the other hand, IP networks have a distributed structure. Therefore, in order to realize an integrated control plane, IP control and the restoration scheme must be coordinated. The third requirement is that multi-grade recovery class management must be supported. In the next generation systems, telecom carriers must provide to their users multi-recovery classes of paths. Therefore, the restoration scheme must support fine control of path recovery based on priorities. In the conventional synchronous digital hierarchy (SDH) system, automatic protection switching (APS) is mainly used as a fault recovery mechanism. APS provides very fast switching within 50 ms, but it cannot provide multi-recovery classes and does not effectively use network resources because protection requires resources for working and protection resulting in resource usage equaling 50%. On the other hand, restoration is not widely used in the SDH system. Restoration is suitable, however, for fine control of the recovery classes and is expected to achieve a high level of resource usage of networks, although it is difficult to achieve fast restoration. Thus, enhancing the switching speed is the key to developing a restoration scheme. The proposed restoration scheme satisfies these requirements: (1) pre-reserved restoration paths and (2) a signaling based scheme. The former contributes to the speed by avoiding calculation of detours and contributes to the fine control of the multi-recovery classes based on priority control Shimano [Page 2] Internet Draft draft-shimano-imajuku-gmpls-restoration-00.txt Feburary 2003 by utilizing pre-reserved restoration paths. The latter is suitable for distributed network control. This document describes some extensions with respect to RSVP-TE to establish working LSPs, reservation of restoration LSPs, and activation in pre-planned restoration. An additional step should be amended before the recovery procedures that are described in the [Restoration-Analysis]. In this document, the restoration procedure comprises these six steps. (Step 1) establish working path and reservation for restoration path (Step 2) fault detection (Step 3) fault identification and isolation (Step 4) fault notification (Step 5) recovery (Step 6) normalization This document mainly contributions to Steps 1, 5, and 6. Establish working LSPs and reservation of restoration LSP belong to Step 1 and activation of the restoration is for Step 5. We also comment on the normalization issue in Step 6. 3. Need for RSVP Extensions 3.1 Requirements for RSVP extensions on reservation for working path 3.1.1 Objects When a working path is established by a pre-planned restoration scheme, these additional properties are required. (1) Indication for protected path This property indicates the protected working path. (2) Recovery class indication This property identifies the class of service level agreement or recovery mechanism. For example, gold, silver, bronze, and best effort are used for the class of service level agreement, and protection and restoration are used to identify the recovery mechanism. 3.1.2 Procedure In a pre-planned restoration scheme, when a working path is established, a corresponding restoration path is also reserved. An RSVP path message is sent with two properties, protected path and recovery class indicators. All LSRs along the LSP can know that the working LSP is protected and the protecting scheme. In the reservation procedure for restoring LSPs, a list of SRLG or LSR-ID will be required. LSRs can collect the information through record-route object procedures when establishing the working LSP. Shimano [Page 3] Internet Draft draft-shimano-imajuku-gmpls-restoration-00.txt Feburary 2003 3.2 Requirements for RSVP extensions on resource reservations for restoration path 3.2.1 Objects Properties of objects carried by request messages of the reservation restoration path are given below. (1) Indication of resource reservation for restoration path This indicates the resource reservation. (2) Recovery class indication This identifies the class of service level agreement or recovery mechanism. For example, gold, silver, bronze, and best effort are used for the class of the service level agreement, and protection and restoration are used to identify the recovery mechanism. (3) Working LSP-ID or Tunnel-ID This correlates the working path to the restoration path. The LSR can switch the working path over to the restoration path when the activation message is received. If the LSR can manage the recovery mechanism by employing LSP-IDs, the LSR can recognize the relationship between the working LSP and the restoration LSP. Otherwise, the LSR can manage LSPs based on the concept of separating calls and connections, and the tunnel identifier can be used to correlate the working LSPs and restoration LSPs. (4) Indication of label request In the “with resource selection” method, identification of label requests is mandatory. On the other hand, in the “w/o resource selection” method, a label request simply represents a resource request or that the availability of a label must be checked for restoration. (5) Suggested label from upstream node This is required only in the “with resource selection” method and in the case of bi-directional LSPs. (6) List of SRLG/Node ID for corresponding route of working path This indicator bears the information of the route of the working LSP. When the route of the restoration LSP is determined by hop-by-hop routing, LSRs can use the list as information to avoid the faulty node. In other cases, distributed control of restoration resources and robustness would be available due to the exchange of risk information. 3.2.2 Procedure An ingress LSR can reserve a restoration LSP when the working LSP is Shimano [Page 4] Internet Draft draft-shimano-imajuku-gmpls-restoration-00.txt Feburary 2003 set. The ingress node can use a standard RSVP path message with the proposed extensions to reserve the restoration LSP. The LSRs along the route of the restoration LSP can recognize the message for reserving the restoration LSP due to the indicator for reserving the restoration LSP and recovery class. We can also use the recovery class as an indicator of the recovery scheme. The upstream LSR issuing reserve messages can suggest labels to the downstream LSR when bi-directional paths are used in the domain. All LSR associated reserved resources with working LSPs are used to identify the working LSP-ID or tunnel-ID. When the “w/ label selection” scheme is used, the label selection should be performed simultaneously to reserve the restoration LSP. The label request is suitable for such a purpose. In this case, RRO must be supported to identify the route of the restoration LSP to the exact routing of the activation message for the restoration scheme. 3.3 Requirements for RSVP extensions on activation of restoration paths 3.3.1 Objects (1) Indication of restoration initiation This indicator notifies all LSRs on the route that activation of the restoration paths has been initiated. (2) Working LSP-ID/ Restoration LSP-ID This indicator lets the LSRs know which working path has been recovered and the corresponding restoration path ID. 3.3.2 Procedure Both the ingress and egress LSR can activate the restoration scheme through a RSVP message with the indication of initiation of restoration, working LSP-ID, and restoration LSP-ID extensions. An explicit route object is also required to trace the route of the restoration LSP. The activation message passes through the LSRs along the route, all cross connections are set, and the restoration LSP begins to work. 3.4 Normalization issue In the final stage of the recovery process, normalization is sometimes required. In such a case, there are a few options. (1) Retaining ex-working path After a restoration, LSRs maintain the ex-working path while restoration is taking place and Shimano [Page 5] Internet Draft draft-shimano-imajuku-gmpls-restoration-00.txt Feburary 2003 LSRs can revert to the working path immediately after fixing the faults. Some special status control of paths should be utilized during waiting to restore/fixing. LSRs keep hello messages exchanging between the endpoints of the LSRs, even if the d-plane is nonfunctional or if the c-plane is unavailable in some sections. In this case, the c-plane should have some recovery function from faults in order to continue to run after the fault. (2) Tear down and re-setup ex-working path In this case, after a fault occurs along a working path, ex-working paths are torn down intentionally or are expired according to a soft-state scheme using RSVP. When the faults are rectified, LSRs will establish protected working paths to restoration paths. 4. Security Considerations Security issues are not discussed in this draft. 5. Reference [restoration-analysis] D. Papadimitriou and E. Mannie, “Analysis of Generalized MPLS- based Recovery Mechanisms (including Protection and Restoration)”, draft-ietf-ccamp-gmpls-recovery-analysis-00.txt. [GMPLS-RSVP] L. Berge, “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC3473. 6. Author information Katsuhiro Shimano NTT Network Innovation Laboratories Hikari-no-oka 1-1 Yokosuka, Kanagawa 239-0847, Japan Email: shimano@exa.onlab.ntt.co.jp Wataru Imajuku NTT Network Innovation Laboratories Hikari-no-oka 1-1 Yokosuka, Kanagawa 239-0847, Japan Email: imajyuku@exa.onlab.ntt.co.jp Shimano [Page 6]--=====================_14118406==_--