Skip to main content

Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
draft-ietf-ccamp-gmpls-recovery-functional-04

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4426.
Authors Dimitri Papadimitriou , Dr. Bala Rajagopalan , Jonathan Lang
Last updated 2013-03-02 (Latest revision 2005-03-30)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4426 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Alex D. Zinin
Send notices to kireeti@juniper.net, adrian@olddog.co.uk
draft-ietf-ccamp-gmpls-recovery-functional-04
Network Working Group                             Jonathan P. Lang, Ed. 
Internet Draft                                    Bala Rajagopalan, Ed. 
Category: Standards Track                    Dimitri Papadimitriou, Ed. 
Expiration Date: October 2005                                           
                                                                        
                                                             April 2005 
 
    
 
      Generalized Multi-Protocol Label Switching (GMPLS) Recovery 
                        Functional Specification 
 
           draft-ietf-ccamp-gmpls-recovery-functional-04.txt 
 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is subject to all provisions 
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each 
   author represents that any applicable patent or other IPR claims of 
   which he or she is aware have been or will be disclosed, and any of 
   which he or she become aware will be disclosed, in accordance with 
   RFC 3668. 
    
   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 (2005). All Rights Reserved. 
 
    
Abstract 
 
   This document presents a functional description of the protocol 
   extensions needed to support Generalized Multi-Protocol Label 
   Switching (GMPLS)-based recovery (i.e. protection and restoration). 
   Protocol specific formats and mechanisms will be described in 
   companion documents. 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                   1 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
Table of Content 
    
   Status of this Memo .............................................. 1 
   Abstract ......................................................... 1 
   Table of Content ................................................. 2 
   Contributors ..................................................... 2 
   1. Conventions ................................................... 3 
   2. Introduction .................................................. 3 
   3. Span Protection ............................................... 4 
   3.1 Unidirectional 1+1 dedicated protection ...................... 5 
   3.2 Bi-directional 1+1 dedicated protection ...................... 6 
   3.3 Dedicated 1:1 protection with Extra Traffic .................. 6 
   3.4 Shared M:N protection ........................................ 8 
   3.5 Messages .................................................... 10 
   3.5.1 Failure Indication Message ................................ 11 
   3.5.2 Switchover Request Message ................................ 11 
   3.5.3 Switchover Response Message ............................... 12 
   3.6 Preventing Unintended Connections ........................... 12 
   4. End-to-End (Path) Protection and Restoration ................. 12 
   4.1 Unidirectional 1+1 Protection ............................... 12  
   4.2 Bi-directional 1+1 Protection ............................... 12 
   4.2.1 Identifiers ............................................... 13 
   4.2.2 Nodal Information ......................................... 13 
   4.2.3 End-to-End Failure Indication Message ..................... 14 
   4.2.4 End-to-End Failure Acknowledgment Message ................. 14 
   4.2.5 End-to-End Switchover Request Message ..................... 15 
   4.2.6 End-to-End Switchover Response Message .................... 15 
   4.3 Shared Mesh Restoration ..................................... 15 
   4.3.1 End-to-End Failure Indication and Acknowledgment .......... 16 
   4.3.2 End-to-End Switchover Request Message ..................... 16 
   4.3.3 End-to-End Switchover Response Message .................... 16 
   5. Reversion and other Administrative Procedures ................ 16 
   6. Discussion ................................................... 17 
   6.1 LSP Priorities During Protection ............................ 17 
   7. Security Considerations ...................................... 18 
   8. IANA Considerations .......................................... 19 
   9. Editor's Addresses ........................................... 19 
   10. References .................................................. 19 
   10.1 Normative References ....................................... 19 
   10.2 Informative References ..................................... 20 
   Intellectual Property Statement ................................. 21 
   Disclaimer of Validity .......................................... 21 
   Copyright Statement ............................................. 21 
    
Contributors 
    
   This document was the product of many individuals working together 
   in the CCAMP WG Protection and Restoration design team. The 
   following are the authors that contributed to this document: 
    
   Deborah Brungard (AT&T) 
   200 S. Laurel Ave. 
   Middletown, NJ 07748, USA 
   EMail: dbrungard@att.com 
  
Lang, J., Rajagopalan, B., et al - Standards Track                   2 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
    
   Sudheer Dharanikota 
   EMail: sudheer@ieee.org 
    
   Jonathan P. Lang (Sonos)  
   506 Chapala Street                    
   Santa Barbara, CA 93101, USA               
   EMail: jplang@ieee.org 
    
   Guangzhi Li (AT&T) 
   180 Park Avenue, 
   Florham Park, NJ 07932, USA 
   E-mail: gli@research.att.com 
    
   Eric Mannie  
   EMail: eric_mannie@hotmail.com 
    
   Dimitri Papadimitriou (Alcatel) 
   Francis Wellesplein, 1  
   B-2018 Antwerpen, Belgium 
   EMail: dimitri.papadimitriou@alcatel.be 
    
   Bala Rajagopalan (Intel Broadband Wireless Division) 
   2111 NE 25th Ave.   
   Hillsboro, OR 97124, USA 
   EMail: bala.rajagopalan@intel.com 
    
   Yakov Rekhter (Juniper) 
   1194 N. Mathilda Avenue                  
   Sunnyvale, CA 94089, USA 
   EMail: yakov@juniper.net 
    
1. Conventions used in this document 
    
   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 [RFC2119].  
    
   In addition, the reader is assumed to be familiar with the 
   terminology used in [GMPLS-ARCH], [RFC3471] and referenced as well 
   as [TERM]. 
    
2. Introduction 
    
   A requirement for the development of a common control plane for both  
   optical and electronic switching equipment is that there must be 
   signaling, routing, and link management mechanisms that support data 
   plane fault recovery. In this document, the term "recovery" is 
   generically used to denote both protection and restoration; the 
   specific terms "protection" and "restoration" are only used when 
   differentiation is required. The subtle distinction between 
   protection and restoration is made based on the resource allocation 
   done during the recovery period (see [TERM]). 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                   3 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   A label-switched path (LSP) may be subject to local (span), segment, 
   and/or end-to-end recovery. Local span protection refers to the 
   protection of the link (and hence all the LSPs marked as required 
   for span protection and routed over the link) between two 
   neighboring switches. Segment protection refers to the recovery of 
   an LSP segment (i.e., an SNC in the ITU-T terminology) between two 
   nodes, i.e. the boundary nodes of the segment. End-to-end protection 
   refers to the protection of an entire LSP from the ingress to the 
   egress port. The end-to-end recovery models discussed in this 
   document apply to segment protection where the source and 
   destination refer to the protected segment rather than the entire 
   LSP. Multiple recovery levels may be used concurrently by a single 
   LSP for added resiliency; however, the interaction between levels 
   becomes affecting any one direction of the LSP results in both 
   directions of the LSP being switched to a new span, segment, or end-
   to-end path. 
    
   Unless otherwise stated, all references to "link" in this document 
   indicate a bi-directional link (which may be realized as a pair of 
   unidirectional links). 
    
   Consider the control plane message flow during the establishment of 
   an LSP. This message flow proceeds from an initiating (or source) 
   node to a terminating (or destination) node, via a sequence of 
   intermediate nodes. A node along the LSP is said to be "upstream" 
   from another node if the former occurs first in the sequence. The 
   latter node is said to be "downstream" from the former node. That 
   is, an "upstream" node is closer to the initiating node than a node 
   further "downstream". Unless otherwise stated, all references to 
   "upstream" and "downstream" are in terms of the control plane 
   message flow. 
    
   The flow of the data traffic is defined from ingress (source node) 
   to egress (destination node). Note that for bi-directional LSPs 
   there are two different data plane flows, one for each direction of 
   the LSP. This document presents a protocol functional description to 
   support Generalized Multi-Protocol Label Switching (GMPLS)-based 
   recovery (i.e., protection and restoration). Protocol specific 
   formats, encoding and mechanisms will be described in companion 
   documents. 
    
3. Span Protection 
    
   Consider a (working) link i between two nodes A and B. There are two 
   fundamental models for span protection. The first is referred to as 
   1+1 protection. Under this model, a dedicated link j is pre-assigned 
   to protect link i. LSP traffic is permanently bridged onto both 
   links i and j at the ingress node and the egress node selects the 
   signal (i.e., normal traffic) from i or j, based on a selection 
   function (e.g., signal quality). Under unidirectional 1+1 span 
   protection (Section 3.1), each node A and B acts autonomously to 
   select the signal from the working link (i) or the protection link 
   (j). Under bi-directional 1+1 span protection (Section 3.2) the two 

  
Lang, J., Rajagopalan, B., et al - Standards Track                   4 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   nodes A and B coordinate the selection function such that they 
   select the signal from the same link, i or j. 
    
   Under the second model, a set of N working links are protected by a 
   set of M protection links, usually with M =< N.  A failure in any of 
   the N working links results in traffic being switched to one of the 
   M protection links that is available. This is typically a three-step 
   process: first the data plane failure is detected at the egress node 
   and reported (notification), then a protection link is selected, and 
   finally, the LSPs on the failed link are moved to the protection 
   link. If reversion is supported, a fourth step is included, i.e. 
   return of the traffic to the working link (when the working link has 
   recovered from the failure). In Section 3.3, 1:1 span protection is 
   described. In Section 3.4, M:N span protection is described, where M 
   =< N. 
    
3.1  Unidirectional 1+1 dedicated protection 
    
   Suppose a bi-directional LSP is routed over link i between two nodes 
   A and B. Under unidirectional 1+1 protection, a dedicated link j is 
   pre-assigned to protect the working link i. LSP traffic is 
   permanently bridged on both links at the ingress node and the egress 
   node selects the normal traffic from one of the links, i or j. If a 
   node (A or B) detects a failure of a span, it autonomously invokes a 
   process to receive the traffic from the protection span. Thus, it is 
   possible that node A selects the signal from link i in the B to A 
   direction of the LSP, and node B selects the signal from link j in 
   the A to B direction. 
    
   The following functionality is required for 1+1 unidirectional span 
   protection: 
    
        o  Routing: A single TE link encompassing both working and 
           protection links SHOULD be announced with Link Protection 
           Type "Dedicated 1+1" along with the bandwidth parameters for 
           the working link. As the resources are consumed/released, 
           the bandwidth parameters of the TE link are adjusted 
           accordingly. Encoding of the Link Protection Type and 
           bandwidth parameters in IS-IS is specified in [GMPLS-ISIS]. 
           Encoding of this information in OSPF is specified in [GMPLS-
           OSPF]. 
         
        o  Signaling: The Link Protection object/TLV SHOULD be used to 
           request "Dedicated 1+1" link protection for that LSP. This 
           object/TLV is defined in [RFC3471]. If the Link Protection 
           object/TLV is not used, link selection is a matter of local 
           policy. No additional signaling is required when a fail-over 
           occurs. 
         
        o  Link management: Both nodes MUST have a consistent view of 
           the link protection association for the spans. This can be 
           done using the Link Management Protocol (LMP) [LMP], or if 
           LMP is not used, this MUST be configured manually. 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                   5 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
3.2  Bi-directional 1+1 dedicated protection 
    
   Suppose a bi-directional LSP is routed over link i between two nodes 
   A and B. Under bi-directional 1+1 protection, a dedicated link j is 
   pre-assigned to protect the working link i. LSP traffic is 
   permanently duplicated on both links and under normal conditions, 
   the traffic from link i is received by nodes A and B (in the 
   appropriate directions). A failure affecting link i results in both 
   A and B switching to the traffic on link j in the respective 
   directions. Note that some form of signaling is required to ensure 
   that both A and B start receiving from the protection link. 
    
   The basic steps in 1+1 bi-directional span protection are as 
   follows: 
    
        1. If a node (A or B) detects the failure of the working link 
           (or a degradation of signal quality over the working link), 
           it SHOULD begin receiving on the protection link and send a 
           switchover request message reliably to the other node (B or 
           A, respectively). This message SHOULD indicate the identity 
           of the failed working link and other relevant information. 
         
        2. Upon receipt of the switchover request message, a node MUST 
           begin receiving from the protection link and send a 
           switchover response message to the other node (A or B, 
           respectively). Since both the working/protect spans are 
           exposed to routing and signaling as a single link, the 
           switchover SHOULD be transparent to routing and signaling. 
    
   The following functionality is required for 1+1 bi-directional span 
   protection: 
    
        o  The routing procedures are the same as in 1+1 
           unidirectional. 
         
        o  The signaling procedures are the same as in 1+1 
           unidirectional. 
         
        o  In addition to the procedures described in 1+1 
           (unidirectional), a switchover request message MUST be used 
           to signal the switchover request. This can be done using LMP 
           [LMP]. Note that GMPLS-based mechanisms MAY not be necessary 
           when the underlying span (transport) technology provides 
           such a mechanism. 
 
3.3  Dedicated 1:1 protection with Extra Traffic 
    
   Consider two adjacent nodes A and B. Under 1:1 protection, a 
   dedicated link j between A and B is pre-assigned to protect working 
   link i. Link j may be carrying (preemptable) Extra Traffic. A 
   failure affecting link i results in the corresponding LSP(s) being 
   restored to link j. Extra Traffic being routed over link j may need 
   to be preempted to accommodate the LSPs that have to be restored. 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                   6 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   Once a fault is isolated/localized, the affected LSP(s) must be 
   moved to the protection link. The process of moving an LSP from a 
   failed (working) link to a protection link must be initiated by one 
   of the nodes, A or B. This node is referred to as the "master". The 
   other node is called the "slave". The determination of the master 
   and the slave may be based on configured information or protocol 
   specific requirements.  
    
   The basic steps in dedicated 1:1 span protection (ignoring 
   reversion) are as follows:   
    
        1. If the master detects/localizes a link failure event, it 
           invokes a process to allocate the protection link to the 
           affected LSP(s). 
        2. If the slave detects a link failure event, it informs the 
           master of the failure using a failure indication message. 
           The master then invokes the same procedure as (1) to move 
           the LSPs to the protection link. If the protection link is 
           carrying Extra Traffic, the slave stops using the span for 
           the Extra Traffic. 
        3. Once the span protection procedure is invoked in the master, 
           it requests the slave to switch the affected LSP(s) to the 
           protection link. Prior to this, if the protection link is 
           carrying Extra Traffic, the master stops using the span for 
           this traffic (i.e., the traffic is dropped by the master and 
           not forwarded into or out of the protection link). 
        4. The slave sends an acknowledgement to the master. Prior to 
           this, the slave stops using the link for Extra Traffic (i.e. 
           the traffic is dropped by the slave and not forwarded into 
           or out of the protection link). It then starts sending the 
           normal traffic on the selected protection link. 
        5. When the master receives the acknowledgement, it starts 
           sending and receiving the normal traffic over the new link. 
           The switchover of the LSPs is thus completed. 
    
        Note: though this mechanism implies more traffic dropped than 
        necessary, it is preferred over possible misconnections during 
        the recovery process. 
    
   From the description above, it is clear that 1:1 span protection may 
   require up to three signaling messages for each failed span: a 
   failure indication message, an LSP switchover request message, and 
   an LSP switchover response message. Furthermore, it may be possible 
   to switch multiple LSPs from the working span to the protection span 
   simultaneously. 
    
   The following functionality is required for dedicated 1:1 span 
   protection: 
    
        o  Pre-emption MUST be supported to accommodate Extra Traffic. 
         
        o  Routing: A single TE link encompassing both working and 
           protection links is announced with Link Protection Type 
           "Dedicated 1:1". If Extra Traffic is supported over the 
  
Lang, J., Rajagopalan, B., et al - Standards Track                   7 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
           protection link, then the bandwidth parameters for the 
           protection link MUST also be announced. The differentiation 
           between bandwidth for working and protect links is made 
           using priority mechanisms. In other words, the network MUST 
           be configured such that bandwidth at priority X or lower is 
           considered Extra Traffic. 
            
           If there is a failure on the working link, then the normal 
           traffic is switched to the protection link, preempting Extra 
           Traffic if necessary. The bandwidth for the protection link 
           MUST be adjusted accordingly. 
            
        o  Signaling: To establish an LSP on the working link, the Link 
           Protection object/TLV indicating "Dedicated 1:1" SHOULD be 
           included in the signaling request message for that LSP. To 
           establish an LSP on the protection link, the appropriate 
           priority (indicating Extra Traffic) SHOULD be used for that 
           LSP. These objects/TLVs are defined in [RFC3471]. If the 
           Link Protection object/TLV is not used, link selection is a 
           matter of local policy. 
            
        o  Link management: Both nodes MUST have a consistent view of 
           the link protection association for the spans. This can be 
           done using LMP [LMP] or via manual configuration. 
            
        o  When a link failure is detected at the slave, a failure 
           indication message MUST be sent to the master informing the 
           node of the link failure. 
 
3.4  Shared M:N protection 
    
   Shared M:N protection is described with respect to two neighboring 
   nodes A and B. The scenario considered is as follows: 
    
        o  At any point in time, there are two sets of links between A 
           and B, i.e., a working set of N (bi-directional) links 
           carrying traffic subject to protection and a protection set 
           of M (bi-directional) links. A protection link may be 
           carrying Extra Traffic. There is no a priori relationship 
           between the two sets of links, but the value of M and N MAY 
           be pre-configured. The specific links in the protection set 
           MAY be pre-configured to be physically diverse to avoid the 
           possibility that failure events affect a large proportion of 
           protection links (along with working links). 
        
        o  When a link in the working set is affected by a failure, the 
           normal traffic is diverted to a link in the protection set, 
           if such a link is available. Note that such a link might be 
           carrying more than one LSP, e.g., an OC-192 link carrying 
           four STS-48 LSPs. 
        
        o  More than one link in the working set may be affected by the 
           same failure event. In this case, there may not be an 
           adequate number of protection links to accommodate all of 
  
Lang, J., Rajagopalan, B., et al - Standards Track                   8 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
           the affected traffic carried by failed working links. The 
           set of affected working links that are actually restored 
           over available protection links is then subject to policies 
           (e.g., based on relative priority of working traffic). These 
           policies are not specified in this document. 
        
        o  When normal traffic must be diverted from a failed link in 
           the working set to a protection link, the decision as to 
           which protection link is chosen is always made by one of the 
           nodes, A or B. This node is considered the "master" and it 
           is required to both apply any policies and select specific 
           protection links to divert working traffic. The other node 
           is considered the "slave". The determination of the master 
           and the slave MAY be based on configured information, 
           protocol specific requirements, or as a result of running a 
           neighbor discovery procedure. 
        
        o  Failure events themselves are detected by transport layer 
           mechanisms if available (e.g., SONET Alarm Indication Signal 
           (AIS)/ Remote Defect Indication (RDI)). Since the bi-
           directional links are formed by a pair of unidirectional 
           links, a failure in the link from A to B is typically 
           detected by B and a failure in the opposite direction is 
           detected by A. It is possible that a failure simultaneously 
           affects both directions of the bi-directional link. In this 
           case, A and B will concurrently detect failures, in the B-
           to-A direction and in the A-to-B direction, respectively. 
    
   The basic steps in M:N protection (ignoring reversion) are as 
   follows:   
    
        1. If the master detects a failure of a working link, it 
           autonomously invokes a process to allocate a protection link 
           to the affected traffic. 
        
        2. If the slave detects a failure of a working link, it MUST 
           inform the master of the failure using a failure indication 
           message. The master then invokes the same procedure as above 
           to allocate a protection link. (It is possible that the 
           master has itself detected the same failure, for example, a 
           failure simultaneously affecting both directions of a link). 
        
        3. Once the master has determined the identity of the 
           protection link, it indicates this to the slave and requests 
           the switchover of the traffic (using a "switchover request" 
           message). Prior to this, if the protection link is carrying 
           Extra Traffic, the master stops using the link for this 
           traffic (i.e., the traffic is dropped by the master and not 
           forwarded into or out of the protection link). 
        
        4. The slave sends a "switchover response" message back to the 
           master. Prior to this, if the selected protection link is 
           carrying traffic that could be preempted, the slave stops 
           using the link for this traffic (i.e., the traffic is 
  
Lang, J., Rajagopalan, B., et al - Standards Track                   9 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
           dropped by the slave and not forwarded into or out of the 
           protection link). It then starts sending the normal traffic 
           on the selected protection link.   
        
        5. When the master receives the switchover response, it starts 
           sending and receiving the traffic that was previously 
           carried on the now-failed link over the new link. 
    
        Note: though this mechanism implies more traffic dropped than 
        necessary, it is preferred over possible misconnections during 
        the recovery process. 
    
   From the description above, it is clear that M:N span restoration 
   (involving LSP local recovery) MAY require up to three messages for 
   each working link being switched: a failure indication message, a 
   switchover request message and a switchover response message. 
    
   The following functionality is required for M:N span restoration: 
    
        o  Pre-emption MUST be supported to accommodate Extra Traffic. 
        
        o  Routing: A single TE link encompassing both sets of working 
           and protect links should be announced with Link Protection 
           Type "Shared M:N". If Extra Traffic is supported over set of 
           the protection links, then the bandwidth parameters for the 
           set of protection links MUST also be announced. The 
           differentiation between bandwidth for working and protect 
           links is made using priority mechanisms. 
    
           If there is a failure on a working link, then the affected 
           LSP(s) MUST be switched to a protection link, preempting 
           Extra Traffic if necessary. The bandwidth for the protection 
           link MUST be adjusted accordingly. 
    
        o  Signaling: To establish an LSP on the working link, the Link 
           Protection object/TLV indicating "Shared M:N" SHOULD be 
           included in the signaling request message for that LSP. To 
           establish an LSP on the protection link, the appropriate 
           priority (indicating Extra Traffic) SHOULD be used for that. 
           These objects/TLVs are defined in [RFC3471]. If the Link 
           Protection object/TLV is not used, link selection is a 
           matter of local policy. 
        
        o  For link management, both nodes MUST have a consistent view 
           of the link protection association for the links. This can 
           be done using LMP [LMP] or via manual configuration. 
        
3.5  Messages 
    
   The following messages are used in local span protection procedures.  
    
   These messages SHOULD be delivered reliably. Therefore, the protocol  
   mechanisms used to deliver these messages SHOULD provide sequencing, 

  
Lang, J., Rajagopalan, B., et al - Standards Track                  10 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   acknowledgment and retransmission. The protocol SHOULD also handle 
   situations where the message(s) can not be delivered. 
    
   The messages described in the following subsections are abstract, 
   their format and encoding will be described in separate documents. 
    
3.5.1    Failure Indication Message 
    
   This message is sent from the slave to the master to indicate the 
   identities of one or more failed working links. This message MAY not 
   be necessary when the transport plane technology itself provides for 
   such a notification. 
    
   The number of links included in the message would depend on the 
   number of failures detected within a window of time by the sending 
   node. A node MAY choose to send separate failure indication messages 
   in the interest of completing the recovery for a given link within 
   an implementation-dependent time constraint. 
    
3.5.2    Switchover Request Message 
    
   Under bi-directional 1+1 span protection, this message is used to 
   coordinate the selecting function at both nodes. This message is 
   originated at the node that detected the failure. 
    
   Under dedicated 1:1 and shared M:N span protection, this message is 
   used as an LSP switchover request. This message is sent from the 
   master node to the slave node (reliably) to indicate that the LSP(s) 
   on the (failed) working link can be switched to an available 
   protection link. If so, the ID of the protection link as well as the 
   LSP labels (if necessary) MUST be indicated. These identifiers used 
   MUST be consistent with those used in GMPLS signaling. 
    
   A working link may carry multiple LSPs. Since the normal traffic 
   carried over the working link is switched to the protection link, it 
   MAY be possible for the LSPs on the working link to be mapped to the 
   protection link without re-signaling each individual LSP. For 
   example, if link bundling [BUNDLE] is used where the working and 
   protect links are mapped to component links, and the labels are the 
   same on the working and protection links, it MAY be possible to 
   change the component links without needing to re-signal each 
   individual LSP. Optionally, the labels MAY need to be explicitly 
   coordinated between the two nodes. In this case, the switchover 
   request message SHOULD carry the new label mappings. 
    
   The master may not be able to find protection links to accommodate 
   all failed working links. Thus, if this message is generated in 
   response to a Failure Indication message from the slave then the set 
   of failed links in the message MAY be a sub-set of the links 
   received in the Failure Indication message. Depending on time 
   constraints, the master may switch the normal traffic from the set 
   of failed links in smaller batches. Thus, a single failure 
   indication message MAY result in the master sending more than one 
   Switchover Request message to the same slave node. 
  
Lang, J., Rajagopalan, B., et al - Standards Track                  11 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
    
3.5.3   Switchover Response Message 
    
   This message is sent from the slave to the master (reliably) to 
   indicate the completion (or failure) of switchover at the slave.  In 
   this message, the slave MAY indicate that it cannot switch over to 
   the corresponding free link for some reason. The master and slave in 
   this case notify the user (operator) of the failed switchover. A 
   notification of the failure MAY also be used as a trigger in an end-
   to-end recovery. 
    
3.6  Preventing Unintended Connections 
    
   An unintended connection occurs when traffic from the wrong source 
   is delivered to a receiver. This MUST be prevented during protection 
   switching. This is primarily a concern when the protection link is 
   being used to carry Extra Traffic. In this case, it MUST be ensured 
   that the LSP traffic being switched from the (failed) working link 
   to the protection link is not delivered to the receiver of the 
   preempted traffic. Thus, in the message flow described above, the 
   master node MUST disconnect (any) preempted traffic on the selected 
   protection link before sending the Switchover Request. The slave 
   node MUST also disconnect preempted traffic before sending the 
   Switchover Response. In addition, the master node SHOULD start 
   receiving traffic for the protected LSP from the protection link. 
   Finally, the master node SHOULD start sending protected traffic on 
   the protection link upon receipt of the Switchover Response. 
    
4. End-to-End (Path) Protection and Restoration 
    
   End-to-end path protection and restoration refer to the recovery of 
   an entire LSP from the initiator to the terminator. Suppose the 
   primary path of an LSP is routed from the initiator (Node A) to the 
   terminator (Node B) through a set of intermediate nodes.  
    
   The following subsections describe three previously proposed end-to-
   end protection schemes and the functional steps needed to implement 
   them. 
 
4.1  Unidirectional 1+1 Protection 
    
   A dedicated, resource-disjoint alternate path is pre-established to 
   protect the LSP. Traffic is simultaneously sent on both paths and 
   received from one of the functional paths by the end nodes A and B. 
    
   There is no explicit signaling involved with this mode of 
   protection. 
    
4.2  Bi-directional 1+1 Protection 
    
   A dedicated, resource-disjoint alternate path is pre-established to 
   protect the LSP. Traffic is simultaneously sent on both paths; under 
   normal conditions, the traffic from the working path is received by 
   nodes A and B (in the appropriate directions). A failure affecting 
  
Lang, J., Rajagopalan, B., et al - Standards Track                  12 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   the working path results in both A and B switching to the traffic on 
   the protection path in the respective directions. 
    
   Note that this requires coordination between the end nodes to switch 
   to the protection path. 
    
   The basic steps in bi-directional 1+1 path protection are as 
   follows: 
    
        o  Failure detection: There are two possibilities for this. 
    
             1. A node in the working path detects a failure event. 
                Such a node MUST send a failure indication message 
                towards the upstream or/and downstream end node of the 
                LSP (node A or B). This message MAY be forwarded along 
                the working path, or routed over a different path if 
                the network has general routing intelligence.  
              
                Mechanisms provided by the data transport plane MAY 
                also be used for this, if available. 
              
             2. The end nodes (A or B) detect the failure themselves 
                (e.g., loss of signal). 
             
        o  Switchover: The action when an end node detects a failure in 
           the working path is as follows: Start receiving from the 
           protection path; at the same time, send a switchover request 
           message to the other end node to enable switching at the 
           other end. 
    
           The action when an end node receives a switchover request 
           message is as follows: 
    
             -  Start receiving from the protection path; at the same 
                time, send a switchover response message to the other 
                end node. 
    
   GMPLS signaling mechanisms MAY be used to (reliably) signal the 
   failure indication message, as well as the switchover request and 
   response message. These messages MAY be forwarded along the 
   protection path if no other routing intelligence is available in the 
   network. 
    
4.2.1   Identifiers 
    
   LSP Identifier: A unique identifier for each LSP. The LSP Identifier 
   is within the scope of the Source ID and Destination ID. 
    
   Source ID: ID of the source (e.g., IP address). 
    
   Destination ID: ID of the destination (e.g., IP address). 
    
4.2.2   Nodal Information 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                  13 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   Each node that is on the working or protection path of an LSP MUST 
   have knowledge of the LSP identifier. If the network does not 
   provide routing intelligence, nodal information MAY also include 
   previous and next nodes in the LSP so that restoration-related 
   messages can be forwarded properly. When, the network provides 
   general routing intelligence, messages MAY be forwarded along paths 
   different than that of the LSP. 
    
   At the end-point nodes, the working and protection paths MUST be 
   associated. The association of these paths MAY be either provisioned 
   using signaling, or MAY be configured when LSP provisioning does not 
   involve signaling (e.g., provisioning through a management system). 
   The related association information MUST remain until the LSP is 
   explicitly de-provisioned.  
 
4.2.3   End-to-End Failure Indication Message 
    
   This message is sent (reliably) by an intermediate node towards the 
   source of an LSP. For instance, such a node might have attempted 
   local span protection and failed. This message MAY not be necessary 
   if the data transport layer provides mechanisms for the notification 
   of LSP failure by the endpoints (i.e. if LSP endpoints are co-
   located with a corresponding data (transport) maintenance/recovery 
   domain). 
    
   Consider a node that detects a link failure. The node MUST determine 
   the identities of all LSPs that are affected by the failure of the 
   link, and send an end-to-end failure indication message to the 
   source of each LSP. For scalability reasons, failure indication 
   messages MAY contain the identity and the status of multiple LSPs 
   rather than a single one. Each intermediate node receiving such a 
   message MUST forward the message to the appropriate next node such 
   that the message would ultimately reach the LSP source. However, 
   there is no requirement that this message flows towards the source 
   along the same path as the failed LSP. Furthermore, if an 
   intermediate node is itself generating a failure indication message, 
   there SHOULD be a mechanism to suppress all but one source of 
   failure indication messages. Finally, the failure indication message 
   MUST be sent reliably from the node detecting the failure to the LSP 
   source. Reliability MAY be achieved, for example, by re-transmitting 
   the message until an acknowledgement is received. However, 
   retransmission of failure indication messages SHOULD not cause 
   further message drops. This MAY be achieved through the appropriate 
   configuration and use of congestion and flow control mechanisms. 
    
4.2.4   End-to-End Failure Acknowledgment Message 
    
   This message is sent by the source node to acknowledge the receipt 
   of an End-to-End failure indication message. This message is sent to 
   the originator of the failure indication message. The acknowledge 
   message SHOULD be sent for each failure indication message received. 
   Each intermediate node receiving the failure acknowledgment message 
   MUST forward it towards the destination of the message. However, 

  
Lang, J., Rajagopalan, B., et al - Standards Track                  14 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   there is no requirement that this message flows towards the 
   destination along the same path as the failed LSP. 
    
   This message MAY not be required if other means of ensuring reliable 
   message delivery are used. 
    
4.2.5   End-to-End Switchover Request Message 
    
   This message is generated by the source node receiving an indication 
   of failure in an LSP. It is sent to the LSP destination, and it 
   carries the identifier of LSP being restored. The End-to-End 
   Switchover Request message MUST be sent reliably from the source to 
   the destination of the LSP. 
    
4.2.6   End-to-End Switchover Response Message 
    
   This message is sent by the destination node receiving an End-to-End 
   Switchover Request message towards the source of the LSP. This 
   message SHOULD identify the LSP being switched over. This message 
   MUST be transmitted in response to each End-to-End Switchover 
   Request message received and MAY indicate either a positive or 
   negative outcome. 
    
4.3  Shared Mesh Restoration 
    
   Shared mesh restoration refers to schemes under which protection 
   paths for multiple LSPs share common link and node resources. Under 
   these schemes, the protection capacity is pre-reserved, i.e., link 
   capacity is allocated to protect one or more LSPs but explicit 
   action is required to instantiate a specific protection LSP. This 
   requires restoration signaling along the protection path. Typically, 
   the protection capacity is shared only amongst LSPs whose working 
   paths are physically diverse. This criterion can be enforced when 
   provisioning the protection path. Specifically, provisioning-related 
   signaling messages may carry information about the working path to 
   nodes along the protection path. This can be used as call admission 
   control to accept/reject connections along the protection path based 
   on the identification of the resources used for the primary path.   
    
   Thus, shared mesh restoration is designed to protect an LSP after a 
   single failure event, i.e., a failure that affects the working path 
   of at most one LSP sharing the protection capacity. It is possible 
   that a protection path may not be successfully activated when 
   multiple, concurrent failure events occur. In this case, shared mesh 
   restoration capacity may be claimed for more than one failed LSP and 
   the protection path can be activated only for one of them (at most).  
    
   For implementing shared mesh restoration, the identifier and nodal 
   information related to signaling along the control path are as 
   defined for 1+1 protection in Sections 4.2.1 and 4.2.2. In addition, 
   each node MUST also keep (local) information needed to establish the 
   data plane of the protection path. This information MUST indicate 
   the local resources to be allocated, the fabric cross-connect to be 
   established to activate the path, etc. The precise nature of this 
  
Lang, J., Rajagopalan, B., et al - Standards Track                  15 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   information would depend on the type of node and LSP (the GMPLS 
   signaling document describes different type of switches [RFC3471]). 
   It would also depend on whether the information is fine or coarse-
   grained. For example, fine-grained information would indicate pre-
   selection of all details pertaining to protection path activation, 
   such as outgoing link, labels, etc. Coarse-grained information, on 
   the other hand, would allow some details to be determined during 
   protection path activation. For example, protection resources may be 
   pre-selected at the level of a TE link, while the selection of the 
   specific component link and label occurs during protection path 
   activation. 
    
   While the coarser specification allows some flexibility in selection 
   of the precise resource to activate, it also brings in more 
   complexity in decision making and signaling during the time-critical 
   restoration phase. Furthermore, the procedures for the assignment of 
   bandwidth to protection paths MUST take into account the total 
   resources in a TE link so that single-failure survivability 
   requirements are satisfied.  
 
4.3.1   End-to-End Failure Indication and Acknowledgment Message 
    
   The End-to-End failure indication and acknowledgement procedures and 
   messages are as defined in Sections 4.2.3 and 4.2.4. 
    
4.3.2   End-to-End Switchover Request Message  
    
   This message is generated by the source node receiving an indication 
   of failure in an LSP. It is sent to the LSP destination along the 
   protection path, and it identifies the LSP being restored. If any 
   intermediate node is unable to establish cross-connects for the 
   protection path, then it is desirable that no other node in the path 
   establishes cross-connects for the path. This would allow shared 
   mesh restoration paths to be efficiently utilized. 
    
   The End-to-End Switchover message MUST be sent reliably from the 
   source to the destination of the LSP along the protection path. 
    
4.3.3   End-to-End Switchover Response Message 
    
   This message is sent by the destination node receiving an End-to-End 
   Switchover Request message towards the source of the LSP, along the 
   protection path. This message SHOULD identify the LSP that is being 
   switched over. Prior to activating the secondary bandwidth at each 
   hop along the path, Extra Traffic (if used) MUST be dropped and not 
   forwarded 
    
   This message MUST be transmitted in response to each End-to-End 
   Switchover Request message received. 
    
5. Reversion and other Administrative Procedures 
    
   Reversion refers to the process of moving an LSP back to the 
   original working path after a failure is cleared and the path is 
  
Lang, J., Rajagopalan, B., et al - Standards Track                  16 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   repaired. Reversion applies both to local span and end-to-end path 
   protected LSPs. Reversion is desired for the following reasons. 
   First, the protection path may not be optimal as compared to the 
   working path from a routing and resource consumption point of view. 
   Second, moving an LSP to its working path allows the protection 
   resources to be used to protect other LSPs. Reversion has the 
   disadvantage of causing a second service disruption. Use of 
   reversion is at the option of the operator. Reversion implies that a 
   working path remains allocated to the LSP that was originally routed 
   over it even after a failure. It is important to have mechanisms 
   that allow reversion to be performed with minimal service disruption 
   to the customer. This can be achieved using a "bridge-and-switch" 
   approach (often referred to as make-before-break). 
    
   The basic steps involved in bridge-and-switch are: 
    
        1. The source node commences the process by "bridging" the 
           normal traffic onto both the working and the protection 
           paths (or links in the case of span protection). 
        2. Once the bridging process is complete, the source node sends 
           a Bridge and Switch Request message to the destination, 
           identifying the LSP and other information necessary to 
           perform reversion. Upon receipt of this message, the 
           destination selects the traffic from the working path. At 
           the same time, it bridges the transmitted traffic onto both 
           the working and protection paths. 
        3. The destination then sends a Bridge and Switch Response 
           message to the source confirming the completion of the 
           operation. 
        4. When the source receives this message, it switches to 
           receive from the working path, and stops transmitting 
           traffic on the protection path. The source then sends a 
           Bridge and Switch Completed message to the destination 
           confirming that the LSP has been reverted. 
        5. Upon receipt of this message, the destination stops 
           transmitting along the protection path and de-activates the 
           LSP along this path. The de-activation procedure should 
           remove the crossed connections along the protection path 
           (and frees the resources to be used for restoring other 
           failures. 
    
   Administrative procedures other than reversion include the ability 
   to force a switchover (from working to protection or vice versa), 
   and locking out switchover, i.e., preventing an LSP from moving from 
   working to protection administratively. These administrative 
   conditions have to be supported by signaling. 
 
6. Discussion 
    
6.1  LSP Priorities During Protection   
    
   Under span protection, a failure event could affect more than one 
   working link and there could be fewer protection links than the 
   number of failed working links. Furthermore, a working link may 
  
Lang, J., Rajagopalan, B., et al - Standards Track                  17 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   contain multiple LSPs of varying priority. Under this scenario, a 
   decision must be made as to which working links (and therefore LSPs) 
   should be protected. This decision MAY be based on LSP priorities.  
    
   In general, a node might detect failures sequentially, i.e., all 
   failed working links may not be detected simultaneously, but only 
   sequentially. In this case, as per the proposed signaling 
   procedures, LSPs on a working link MAY be switched over to a given 
   protection link, but another failure (of a working link carrying 
   higher priority LSPs) may be detected soon afterwards. In this case, 
   the new LSPs may bump the ones previously switched over the 
   protection link. 
    
   In the case of end-to-end shared mesh restoration, priorities MAY be 
   implemented for allocating shared link resources under multiple 
   failure scenarios. As described in Section 4.3, more than one LSP 
   can claim shared resources under multiple failure scenarios. If such 
   resources are first allocated to a lower priority LSP, they MAY have 
   to be reclaimed and allocated to a higher priority LSP. 
    
7. Security Considerations 
    
   There are number of security threats that MAY be experienced due to 
   the exchange of messages and information as detailed in this 
   document. Some examples include interception, spoofing, modification 
   and replay of control messages. Therefore, following security 
   requirements are applicable to the mechanisms of this document. 
        o Signaling MUST be able to provide authentication, integrity,  
          and protect against replay attacks. 
        o Privacy and confidentiality is not required. Only 
          authentication is required to ensure that the signaling  
          messages are originating from the right place and have not  
          been modified in transit. 
        o Protection of the identity of the data plane end-points (in  
          failure indication messages) is not required 
    
   The consequences of poorly secured protection may increase the risk 
   of triggering recovery actions under false failure indication 
   messages including LSP identifiers that are not under failure. Such 
   information could subsequently trigger initiation of "false" 
   recovery actions while there are no reasons to do so. Additionally, 
   if the identification of the LSP is tampered from a failure 
   indication message recovery actions will involve nodes for which the 
   LSPs do not indicate any failure condition or for which no failure 
   indication message has been received. The consequences of such 
   actions is unpredictable and MAY lead to de-synchronisation between 
   the control and the data plane but also increase the risk of 
   misconnections. Moreover, the consequences of poorly applied 
   protection may increase the risk of misconnection. In particular, 
   when Extra Traffic is involved, it is easily possible to deliver the 
   wrong traffic to wrong destination. Similarly, an intrusion that 
   sets up what appears to be a valid protection LSP and then causes a 
   fault may be able to divert traffic. 
    
  
Lang, J., Rajagopalan, B., et al - Standards Track                  18 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
   Moreover, tampering with routing information exchange may also have 
   an effect on traffic engineering. Therefore, any mechanisms used for 
   securing and authenticating the transmission of routing information 
   SHOULD be applied in the present context. 
    
8. IANA Considerations 
    
   This document defines no new code points and requires no action by 
   IANA. 
    
9. Editors' Addresses 
    
   Jonathan P. Lang                   
   Sonos, Inc.                        
   506 Chapala Street                    
   Santa Barbara, CA 93101               
   EMail: jplang@ieee.org                
    
   Bala Rajagopalan 
   Intel Broadband Wireless Div. 
   2111 NE 25th Ave.   
   Hillsboro, OR 97124 
   Phone: +1 503 712-9291 
   EMail: bala.rajagopalan@intel.com 
    
   Dimitri Papadimitriou  
   Alcatel 
   Francis Wellesplein, 1  
   B-2018 Antwerpen, Belgium 
   Phone: +32 3 240-8491  
   EMail: dimitri.papadimitriou@alcatel.be  
       
10. References 
 
10.1 Normative References 
    
   [BUNDLE]     Kompella, K., Rekhter, Y. and Berger, L., "Link 
                Bundling in MPLS Traffic Engineering", draft-ietf-mpls-
                bundle-06.txt (work in progress). 
    
   [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 
                Extensions in Support of Generalized MPLS", draft-ietf-
                isis-gmpls-extensions-16.txt (work in progress). 
    
   [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 
                Extensions in Support of Generalized MPLS", draft-ietf-
                ccamp-ospf-gmpls-extensions-09.txt (work in progress). 
    
   [LMP]        Lang, J., Ed., "Link Management Protocol (LMP) v1.0", 
                Internet Draft, draft-ietf-ccamp-lmp-10.txt (work in 
                progress). 
    
   [RFC2026]    Bradner, S., "The Internet Standards Process --          
                Revision 3", BCP 9, RFC 2026, October 1996.            
  
Lang, J., Rajagopalan, B., et al - Standards Track                  19 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
    
   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate      
                Requirement Levels", BCP 14, RFC 2119, March 1997.  
    
   [RFC3471]    Berger, L., Ed., "Generalized Multi-Protocol Label 
                Switching (GMPLS) - Signaling Functional Description," 
                RFC 3471, January 2003. 
    
   [RFC3667]    Bradner, S., "IETF Rights in Contributions", BCP 78, 
                RFC 3667, February 2004. 
                 
   [RFC3668]    Bradner, S., Ed., "Intellectual Property Rights in IETF 
                Technology", BCP 79, RFC 3668, February 2004.    
 
10.2 Informative References 
    
   [TERM]       Mannie, E., Papadimitriou, D., Ed., "Recovery  
                (Protection Internet Draft, draft-ietf-gmpls-recovery-
                terminology-06.txt, (work in progress). 
    

  
Lang, J., Rajagopalan, B., et al - Standards Track                  20 


draft-ietf-ccamp-gmpls-recovery-functional-04.txt           April 2005 
 
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at 
   ietf-ipr@ietf.org. 
    
Disclaimer of Validity 
    
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2005). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
 
Acknowledgment 
 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
 

  
Lang, J., Rajagopalan, B., et al - Standards Track                  21