CCAMP Working Group Jun Kyun Choi(ICU) Document : Hee Jung Goh(ICU) draft-choi-ccamp-e2e-restoration-srlg-00.txt Expiration Date: December 2003 Hyun Cheol Kim(SKKU) Tae Gon Noh(Samsung AIT) June Koo Rhee(Samsung AIT) Hyeong Ho Lee(ETRI) Jea Hoon Yu(ETIR) June 2003 Signaling Extension for the End-to-End Restoration with SRLG Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026. 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 obsolete 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 draft describes the requirements and scenario for end-to-end restoration with SRLG for disjointness of resources. Furthermore, we also describe the signaling extension for restoration scheme suggested in pre-OTN network. For the disjointness of end-to-end restoration path from failed working path, we extend the RSVP-TE signaling message including SRLG. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Choi et al Expires -December 2003 [Page 1] End-to-End restoration with SRLG June 2003 Table of Contents 1. Introduction.....................................................2 2. Terminology......................................................3 3. Requirements for End-to-End restoration with SRLG................4 3.1 Overview of Restoration Requirements............................4 3.2 Requirements for End-to-End restoration with SRLG...............5 4. Scenario for End-to-End restoration with SRLG....................7 5. Signaling extension..............................................9 5.1 PROTECTION Object...............................................9 5.2 BACKUP ROUTE Object............................................ 11 6. Consideration for SRLG confirmation..............................13 3 7. Conclusion.......................................................14 4 References..........................................................14 Acknowledgement.....................................................15 Author's Addresses..................................................15 5 Full Copyright Statement............................................16 6 1. Introduction Current End-to-End recovery in optical network has three types of recovery schemes : 1+1 uni-directional protection, 1+1 Bi-directional and shared mesh restoration. In 1+1 unidirectional, a dedicated, resource-disjoint alternate path is pre-established to protect the failed LSP. Traffic is simultaneously sent on both paths and received from one of the functional paths by the end nodes. The 1+1 Bi- directional recovery has also a dedicated, resource-disjoint alternate path pre-established. Under normal conditions, the traffic from the working path is received by nodes A and B. A failure affecting the working path results in both A and B switches to the traffic on the protection path in the respective directions. Shared mesh restoration refers to schemes under which protection paths for multiple LSPs share common link and node resources[2],[3]. These recovery schemes may be difficult to support efficient resource restoration due to lack of disjointness between working path and backup path. Therefore we suggest that the end-to-end restoration with SRLG to reduce the amount of information for route computation and to provide complete disjointness of physical or logical resources. This draft describes the scenario and signaling extension to support efficient end-to-end restoration with SRLG of an entire LSP from the source to the destination in pre-OTN network. Pre-OTN networks in which a failure may be masked by intermediated O/E/O based optical line system are transport networks that have a GMPSL-based control plane and various transport plane technologies (such as Optical cross Choi et al Expires - December 2003 [Page 2] End-to-End restoration with SRLG June 2003 connects and Optical Add/Drop Multiplexers, etc.) which separate control plane and transport plane in optical network. The restoration scheme should be timely recovery from failures and also be resource efficient and flexible to meet requirements. This draft describes the protocol specific procedures for GMLS(Generalized Multi-Protocol Label Switching) RSVP-TE (Resource Reservation Protocol-Traffic Engineering) signaling to support end-to-end restoration with SRLG for disjointness of working path and backup path which support entire LSP from the source to the destination. Shared Risk Link Groups (SRLGs) allow the definition of resources or groups of resources that share the same risk of failure. The knowledge of SRLGs may be used to compute diverse paths that can be used for protection. The concept of SRLG(Shared Risk Link Group)has been used for computing a path that is disjoint from a set of links sharing the same risk. For the purpose, links sharing the same risk are grouped to have the same SRLG value. When tow or more links share the same risk, it means that when a link failed, the other can fail at the same time. Network can be planned to recover from failures due to a risk(represented by an SRLG) using different mechanism. The SRLG concept generates another dimension to the existing constraint- based path computation methods traditionally used in hierarchical networks. The SRLG constraints come in addition to the common traffic engineering constrains such as bandwidth availability, link metrics and TE attributes. Shared mesh restoration reduce the resource requirements by allowing multiple LSPs to share common link and node resources. In this scheme, the restoration path is pre-computed and resource capability is on- demand with signaling message. This requires restoration signaling along the working path. We propose the requirements and scenario for end-to-end restoration with SRLG for definitive disjointness of resources. Furthermore, we also describe the signaling extension for restoration scheme suggested. For the disjointness of end-to-end restoration path from failed working path, we extend the RSVP-TE signaling message including SRLG. 2. Terminology This draft uses the GMPSL nodes to support the ability handling SRLG. Therefore we summarize the function of each node. o Recovery GMPLS Nodes - Ingress GMPLS node of end-to-end LSP with SRLG : The ingress GMPLS node of an End-to-End LSP is where the working traffic may be switchover the backup end-to-end LSP. The ingress node with SRLG can compute the disjoint path between working path and backup path in advance for the reducing the computational complexity of Choi et al Expires - December 2003 [Page 3] End-to-End restoration with SRLG June 2003 the resource planning after failure and is used to search the relationships between failed working path and backup path. - Egress GMPLS node of end-to-end LSP with SRLG : The egress GMPSL node of an End-to-End LSP is where the working traffic may be selected from either the working or the backup end-to-end LSP. The egress node with SRLG also can select the backup path disjointed from working path considering SRLGs. - Intermediate GMPLS node of an end-to-end LSP with SRLG : Intermediate node is a node along either the working or backup end-to-end LSP route between the corresponding ingress and egress nodes. It only propagates the SRLG values to the egress or ingress without processing them. 3. Requirements for End-to-End restoration with SRLG 3.1 Overview of Restoration Requirements This section summarizes the end-to-end recovery for pre-OTN networks. We refer [1] to describe the history of restoration in this section. The recovery mechanisms have protection and restoration. The end-to- end path protection and restoration refer to the recovery of an entire LPS from the initiator (Ingress LSR) to the terminator (Egress LSR). The LSP consists of initiator, terminator and a set of intermediate nodes whether it is primary path or not backup path. (The protection mechanism is not the scope of this document.) We have two classification of restoration as following. Restoration -Pre-computation of path and on-demand selection of resource -On-demand computation of path and pre-selection of resource In general, restoration schemes are required to operate in a stable manner to maximize the network reliability and optimization. The five restoration phases are commonly accepted when the failure occurred in pre-OTN networks. Phase 1 : Failure Detection --Transport plane Failure detection should be handled at the layer closet to the failure. One measure of failure detection at the transport plane is detecting loss of light (LOL) which we show this draft. Upon failure condition, the transport plane must trigger the control plane for subsequent actions through the use of GMPSL signaling capabilities. Phase 2: Failure isolation/localization--Transport/Control plane Choi et al Expires - December 2003 [Page 4] End-to-End restoration with SRLG June 2003 Failure Localization requires communication between nodes to determine where the failure has occurred and information to perform the subsequent recovery action at the LSP end points. Phase 3: Failure notification --Control plane Failure Notification is used to inform intermediate nodes that a LSP failure has occurred and has been detected to inform the recovery deciding entities that the corresponding service is not available. Notification message exchanges through a GMPSL control plane may not follow the same path as LSP for which these messages carry the status. Phase 4: Recovery --Control plane In this draft, we consider the recovery as the restoration, and when applicable, recovery resource are provisioned using GMPSL signaling capabilities. Phase 5: Reversion (normalization) --Control plane The process that the original working path has been repaired and begins to carry the traffic again. Now, we described the overview of end-to-end restoration in this section. We want to represent the requirements for end-to-end restoration with SRLG for support efficient and simultaneous recovery from failure. The requirements with SRLG should not only include the contents in 3.1 but also add some functions or features in the following section. 3.2 Requirements for End-to-End restoration with SRLG In this draft, we describe the end-to-end recovery not the link recovery. In the link recovery with SRLG, all the connections that traverse the failed link should be replaced to the new link. Although the link recovery has the shorter recovery latency than end-to-end recovery, it has been reported that end-to-end restoration schemes are more economical and optimal than link recovery in the sense that they require much lower redundant network resource and pre- computation of resource. Moreover end-to-end recovery is more feasible than link recovery with available technologies. Considering this reasons, we want to support the end-to-end restoration and describe the requirements for end-to-end restoration. They are the lists of requirements for restoration. (1) Requirements on efficiency of working and recovery resource - A restoration scheme with SRLG should allow disjoint path (node, link, and logical structure) between the working path and the backup path. Choi et al Expires- December 2003 [Page 5] End-to-End restoration with SRLG June 2003 - It should allow sharing of recovery bandwidth among multiple recovery path, when possible, to enable efficient use of recovery bandwidth because the SRLG concept has the multiple link common risk sharing resources. (2) Requirements on SRLG properties - It should support multiple failure based on group recovery which recover the entire path. - It should restrict the TE element such as SRLG. - It should allow abstraction of path information between initiator and terminator. - It should reduce or hide the network topology information when the working path or backup path would be computed. - A restoration scheme with SRLG should allow aggregated restoration actions, ensuring scalability. (3) Requirements on Recovery actions - It should ensure reliable fault recovery action, providing the control plane is connected. - It should support recovery within bounded time constraints and may be compliant with generally used recovery times because of reduction of information dealt in path computation and selection. - It should test and verify the availability of the restoration path with SRLG before its actual use. In other words, the restoration path binding SRLG should test the SRLG confirmation. This test may occur when the restoration path is provisioned or after it is provisioned but before actual restoration action occurs and the path starts being used. - It should guarantee that restoration actions correctly deliver traffic from primary path to the respective back up path, such that the restoration actions do not result in any unintended connections or unintended diversion of traffic. - It should support CRANKBACK operation of its restoration actions. The dynamic restoration signaling using SRLG may utilize CRANKGACK to successively try different paths until a path with available resources is found. (4) Requirements on recovery priority - It should allow support priority-based recovery of failed LSPs. Choi et al Expires - December 2003 [Page 6] End-to-End restoration with SRLG June 2003 - It should allow support of service classes with different recovery time guarantee. (5) Requirements on failure notification - A restoration scheme with SRLG should be equipped with a failure notification mechanism considering SRLG that guarantees prompt and reliable delivery of notification of faults in the data plane to a deciding entity that is in charge of recovering the fault. 4. Scenario for End-to-End restoration with SRLG In this section, a failure recovery scenario is described based on shared mesh restoration with separation of control plane and transport plane. Every node (OXC) has and OXC switch in transport plane and controller in control plane which is supported to GSMP master-slave. The detailed algorithms or schemes may accepted in this scenario Shared mesh restoration LSP with SRLG is pre-computation but no allocated in resource in advance. In other words, upon the failure, the allocation of resource on path establishment occurs, therefore shred-mesh restoration LSP can manage the efficient resource and can optimize the network resource due to pre-computation. When a failure occurs, the following procedure is carried out: A downstream node close to the failure detects it. If the path is bi-directional, both a downstream node and an upstream node detect failure. Upon failure, the transport node detect it through Loss of Light(LOL)/Loss of Signal(LOS) of physical resource in transport layer. The detecting node should report the detection of failure The node which detects failure and report the detection transmits Notify message with failed LSP(Working Path) ID and SRLG Lists in PROTECTION Object which can be included in Notify message to act a SWITCHOVER Request for end-to-end restoration. This process occurs in Control plane in pre-OTN network which consists of control plane and transport plane which shows in fig 1. Each OXC has the controller and switch that is connected by GSMP master-slave[6]. Pre-OTN network uses this relationship of GSMP master-slave, which is report to controller in detection of failure in transport plane, therefore each intermediate controller of OXC propagates the Notify message with failed LSP ID and SRLG and report failure in Working path to the Ingress or Egress OXC. One key requirement for this process is that the intermediate OXC should be able to notify the failed LSP or node responsible for restoring the connections when failures occur, without processing the message or modifying the state of the affected connections for fast restoration. Choi et al Expires - December 2003 [Page 7] End-to-End restoration with SRLG June 2003 The Ingress or Egress OXC sends the Notify response message for confirmation to detection node of failure through the control plane. The Ingress or Egress OXC sends RSVP-TE signaling message for restoration path based on database which contains the Working LSP ID, SRLG lists for working LSP, the Backup LSP ID and SRLG lists for Backup LSP corresponding the Working path. We can use the Path message for restoration path including BACKUP ROUTE Object with SRLG which represents the relationship for failed LSP and backup LSP. The Path message which have the BACKUP ROUTE Object may be given the highest priority among other messages. The OXC received in Path message accepts the Path establishment, if the OXC has available resources, and sends the RESV message. If the backup path is established through the procedures, the data of failed Working path should be switched over to the Backup path established. The establishment process is achieved through the control plane each OXC using GSMP master-slave, and the GSMP master-slave can be switchover the data through the orders from master. +----------+ +----------+ |Controller|< -----------> |Controller| +----------+ RSVP-TE +----------+ | signaling with SRLG | Control plane | | -------------------------------------------------------------- Transport plane | | +----------+ +----------+ |Switch |< -----------> |Swtich | +----------+ Optical data +----------+ Figure1. OXC structure for control and switch Figure 2 shows an example of Shared mesh based-restoration with SRLG. One working path, LSP 1 runs from Node 1 to Node 4 through connection with SRLG [s1-s2-s3], and another working path, LSP 2 runs from Node 7 to Node 10 through connection with SRLG [s9-s10-s11]. Node 1 can provides data traffic protection by creating a backup LSP that merges with the working LPS at Node 4. We refer to a B-LSP 1 with SRLG [s4- s6-s5] as the restoration LSP of LSP1. In the same manner, we refer to B-LSP2 with SLRG [s7-s6-s10]as restoration of LSP2. In this situation, if it can be assumed that multiple failure do not occur at a same time, the resource for recovering the working LSPs can be shared. In other words, the resource with SRLG 6 can be shared between the B-LSP1 and B-LSP2. By setting up these backup path, the spare/work capacity ration in the network can be reduced. When a failure occurs at a SRLG10 on the working LSP2, the endpoint nodes (both Node 8 and Node9) of the link will detect the failure (if the link is bi-directional). Then the detecting nodes start sending Choi et al Expires -December 2003 [Page 8] End-to-End restoration with SRLG June 2003 Notify message in the control plane through the GSMP master-slave. When a Notify message is received, these nodes send back a Notify response message to the sending node. In the same manner, they propagate the message to their intermediate nodes. 5. Signaling extension In this section, we describe RSVP-TE signaling extension to extend its applicability to end-to-end LSP restoration in pre-OTN network. Also we can show the message format and its definition. [Node1]--srlg1--[Node2]--srlg2--[Node3]--srlg3--[Node4] \ / srlg4 \ / srlg5 [Node5]-----------srlg6-----------[Node6] / \ srlg7 / \ srlg8 [Node7]--srlg9--[Node8]--srlg10--[Node9]--srlg11-[Node10] Working LSP 1: [s1-s2-s3] Working LSP2: [s9-s10-s11] Backup LSP 1:[s4-s6-s5] Backup LSP 2:[s7-s6-s8] Figure 2. Shared mesh Restoration with SRLG 5.1 PROTECTION Object We describe extension to the PROTECTION object to extend its applicability to end-to-end LSP restoration. In addition to modifications to the format of the PROTECTION object, we extend its usage not only so that the object can be included in the Notify message to act a SWTICHOVER Request action but also so that the object can be included in the PATH, RESV message to protect entire path. The PROTECTION object includes the failed LSP, and failed SRLG ID. The format of the PORTJECT object (Class-Num=37, C-Type=TBA by IANA)is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Ckass-Num(37) | C-Type(TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | LSP Flags |Resev |P-Type(TBD)|LINk Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed LSP ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Type | SRLG Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Choi et al Expires - December 2003 [Page 9] End-to-End restoration with SRLG June 2003 Secondary (S): 1 bit When set to 1, this bit indicates that the requested LSP is a secondary (backup) LSP, it indicates that the requested LSP is a primary (working) LSP. Reserved (R ) : 9bit This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. LSP Flags: 6 bits Indicates desired end-to-end LSP recovery type. A value of 0 implies that LSP recovery type is left unspecified. Only one bit can be set at a time. The following values are defined. All other values are reserved and must be sent as Zero and ignored on receipt. 0x00 Unspecified 0x01 Extra-Traffic 0x02 Unprotected 0x04 Shared Mesh 0x08 Dedicated 1:1 (with Extra Traffic) 0x10 Dedicated 1+1 Unidirectional 0x20 Dedicated 1+1 Bidirectional Reserved : 4 bits This field is reserved. It MUST be set to 0 on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. Protection (P) Type : 6 bits Indicates desired resource protection type. A value of 0 implies that LSP recovery type is left unspecified. Only one bit can be set at a time. The following values are defined. All other values are reserved and must be sent as Zero and ignored on receipt. 0x00 Unspecified 0x01 End-to-End protection available 0x02 End-to-End protection in use 0x04 Bandwidth protection Choi et al Expires - December 2003 [Page 10] End-to-End restoration with SRLG June 2003 0x08 Node protection TBD SRLG protection Link Flag : 6 bits Indicates the desired Link Protection Type (see [RFC 3471] Failed LSP ID : 16 bits Identifies the LSP affected by the failure. If unknown, this values by default set to 0. Reserved : 16 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. SRLG (S) Type : 8 bits Define the resource types (also generically referred to as the link type) to which the identifier (32 bits) integer value refers. SRLG (S) Weight : 24 bits Assign on a per-SRLG basis along with the identifier and the value represent the risk assessment defined as the quantification process of the potential risk associated to the inclusion of a given resource. SRLG (S) Identifier : 32 bits Identifiers the SRLG affected by the failure. In other words, the SRLG Identifier in PROTECTION object represents the failed SRLG ID. 5.2 BACKUP ROUTE Object The BACKUP ROUTE Object (BRO)is defined to inform the relationship between Working path and backup path which includes resources are being sued by the associated working LSP. This object may also be used to inform SRLGs along the path of a working protecting LSP about which resources are being used by the associated working path. BR object is a new object that the contents are B-LSP ID and a series of associated SRLG. The BRO can be present in Path messages. The BRO handles the backup LSP corresponding the failed working LSP and its SRLGs for physical/logical disjointess between working LSP and backup LSP. If a Path message contains multiple BRO, all the BROs are meaningful. The BRO has the following format. Choi et al Expires - December 2003 [Page 11] End-to-End restoration with SRLG June 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Ckass-Num(TBA) | C-Type(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|B| Reserved |P-Type(TBD)| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed LSP ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup LSP ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Type | SRLG Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Secondary (S): 1 bit When set to 1, this bit indicates that the requested LSP is a secondary LSP, it indicates that the requested LSP is a primary LSP. Backup (B) : 1 bit When set to 1, this bit indicates that the requested LSP is a backup LSP and represent the Backup LSP ID. When set to 0, it indicates that the request LSP is a working LSP and the Backup LSP ID sets to zero. If the B sets to 0, the message with BR object has the highest priority handling message. Reserved (R ) : 14bit This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. Protection (P) Type : 6 bits Indicates desired resource protection type. A value of 0 implies that LSP recovery type is left unspecified. Only one bit can be set at a time. The following values are defined. All other values are reserved and must be sent as Zero and ignored on receipt. 0x00 Unspecified 0x01 End-to-End protection available 0x02 End-to-End protection in use 0x04 Bandwidth protection 0x08 Node protection Choi et al Expires - December 2003 [Page 12] End-to-End restoration with SRLG June 2003 TBD SRLG protection Reserved : 10 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. Failed LSP ID : 16 bits Identifies the LSP affected by the failure. If unknown, this values by default set to 0. Reserved : 16 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. Backup LSP ID : 16 bits Identifies the backup LSP for restoration. If unknown, this values by default set to 0 Reserved : 16 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes. SRLG (S) Type : 8 bits Define the resource types (also generically referred to as the link type) to which the identifier (32 bits) integer value refers. SRLG (S) Weight : 24 bits Assign on a per-SRLG basis along with the identifier and the value represent the risk assessment defined as the quantification process of the potential risk associated to the inclusion of a given resource. SRLG (S) Identifier : 32 bits Identifiers the SRLG affected by the failure. In other words, the SRLG Identifier in PROTECTION object represents the failed SRLG ID. 6. Consideration for SRLG confirmation Choi et al Expires - December 2003 [Page 13] End-to-End restoration with SRLG June 2003 In this section, we consider the verification of end-to-end restoration path. The test of backup path for failed LSP occurs before its actual use and after its provision. We consider the test as SRLG confirmation for backup path. The backup path test may be use new messages for probe with SRLG ID Lists in backup path. This process and message are further study in this draft. 7. Conclusion This draft describes requirements, scenario, and signaling extensions for end-to-end restoration for control plane-based recovery from data plane failures in pre-OTN network. While there are several scheme for end-to-end restoration, the list of requirements and restoration scheme with SRLG has not been specifically detailed. We identify that the requirements and restoration scheme support disjointness and signaling extension to suggest the restoration scheme is also described. In 6, we consider further study to support test and verification of backup LSP using SRLG. References [1] Papadimitriou, D. and E.Mannie, "Analysis of Generalized MPLS- based Recovery Mechanisms (Including Protection and Restoration)", Internet Draft, work in progress, draft-ietf-ccamp-gmpls-recovery- analysis-01.txt, November 2003. [2] Eric Mannie. , "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", Internet Draft, work in progress, draft-ietf-ccamp-gmpls-recovery-terminology- 02.txt, November 2003. 3] Jonathan P. Lang., "Generalized MPLS Recovery Functional Specification", Internet Draft, work in progress, draft-ietf-ccamp- gmpls-recovery-functional-00.txt, July 2003. [4] Berger, L. "Generalized MPLS Signlaing-RSVP-TE Extension", RFC3473,January 2003 [5] Mannie, E., et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture," draft-ietf-ccamp-gmpls-architecture-07.txt, November 2003. [6] Doria, A. and K. Sundell, "General Switch Management Protocol Applicability", RFC 3294, June 2002. [7] Papadimitriou, D. et al., "Shared Risk Link Groups Encoding and Processing", Internet Draft, draft-papadimitriou-ccamp-srlg- processing-01.txt, May 2003 Choi et al Expires - December 2003 [Page 14 End-to-End restoration with SRLG June 2003 [8] Daniel Awduche, WYakov Rekhter, "Multiprotocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects", IEEE Comm. Mag., March 2001 [9] P. Czezowski., "Optical Network Failure Recovery Requirements", Internet Draft, draft-czezowski-optical-recovery-reqs-00.txt, April 2003. [10] J.P. Lang, et.al., "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", Internet Draft, work in Progress, draft-lang- ccamp-gmpls-recovery-e2e-signlaing-00.txt, August 2003. Acknowledgement This work was supported in part by the Korean Science and Engineering Foundation (KOSEF) through OIRC project Author's Addresses Jun Kyun Choi Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Daejon Korea 305-732 Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Hee Jung Goh Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Daejon Korea 305-732 Phone: +82-42-866-6182 Email: kaumi@icu.ac.kr Hyun Cheol Kim SungKyunKwan university, 440-746 Suwon, Krea Email: hckim@songgang.skku.ac.kr Tae Gon Noh Samsung Advanced Institute of Technology (Samsung AIT) P.O. Box 111, Suwon, Kyoungki Korea 440-600 Phone: +82-31-280-9621 Email: tgnoh@samsung.com June-Koo Rhee Samsung Advanced Institute of Technology (Samsung AIT) P.O. Box 111, Suwon, Kyoungki Korea 440-600 Phone: +82-31-280-8193 Email: jk.rhee@samsung.com Choi et al Expires - December 2003 [Page 15] End-to-End restoration with SRLG June 2003 Hyeong Ho Lee ETRI (Electronics and Telecommunications Research Institute) 161 KaJong-Dong, Yusong-Gu, Daejeon Korea 305-309 Phone: +82-42-860-6130 Email: holee@etri.re.kr Jea Hoon Yu ETRI (Electronics and Telecommunications Research Institute) 161 KaJong-Dong, Yusong-Gu, Daejeon Korea 305-309 Phone: +82-42-860-1602 Email: jh-yoo@etri.re.kr Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Choi et al Expires - December 2003 [Page 16]