CCAMP Working Group                         CCAMP GMPLS P&R Design Team
Internet Draft
Expiration Date: September 2004                      J.P. Lang (Editor)
                                                    Y. Rekhter (Editor)
                                              D. Papadimitriou (Editor)



                                                             March 2004




   RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery


         draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt





Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [RFC2026].


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.


   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract


   This document describes protocol specific procedures for GMPLS
   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
   ReserVation Protocol - Traffic Engineering) signaling extensions to
   support end-to-end LSP recovery (protection and restoration). A
   generic functional description of GMPLS recovery can be found in a
   companion document.







J.P.Lang et al. - Internet Draft ¡ Expires September 2004            1
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



1. Contributors


   This document is the result of the CCAMP Working Group Protection
   and Restoration design team joint effort. The following are the
   authors that contributed to the present memo:


   Deborah Brungard (AT&T)
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ 07748, USA
   EMail: dbrungard@att.com


   Sudheer Dharanikota
   EMail: sudheer@ieee.org


   Jonathan Lang (Rincon Networks)
   EMail: jplang@ieee.org


   Guangzhi Li (AT&T)
   180 Park Avenue,
   Florham Park, NJ 07932, USA
   EMail: gli@research.att.com


   Eric Mannie
   EMail: eric_mannie@hotmail.com


   Dimitri Papadimitriou (Alcatel)
   Fr. Wellesplein, 1
   B-2018, Antwerpen, Belgium
   EMail: dimitri.papadimitriou@alcatel.be


   Bala Rajagopalan
   EMail: braj@earthlink.net


   Yakov Rekhter (Juniper)
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089, USA
   EMail: yakov@juniper.net



2. 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], [RFC-3471], [RFC-3473] and
   referenced as well as [TERM] and [FUNCT].







J.P.Lang et al. - Internet Draft ¡ Expires September 2004            2
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



3. Introduction


   Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
   include support for Layer-2 (L2SC), Time-Division Multiplex (TDM),
   Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC)
   interfaces. GMPLS-based recovery uses control plane mechanisms
   (i.e., signaling, routing, link management mechanisms) to support
   data plane fault recovery. Note that the analogous (data plane)
   fault detection mechanisms are required to be present in support of
   the control plane mechanisms. 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 phase (see [TERM]).


   A functional description of GMPLS-based recovery is provided in
   [FUNCT] and should be considered as a companion document to this
   memo which describes the protocol specific procedures for GMPLS
   RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering)
   signaling (see [RFC-3473]) to support end-to-end recovery of an
   entire LSP from the head-end to the tail-end. The present memo
   addresses four types of end-to-end LSP recovery: 1+1 unidirectional/
   1+1 bi-directional protection, LSP protection with extra-traffic
   (including 1:N protection with extra-traffic), pre-planned LSP re-
   routing without extra-traffic (including shared mesh), and full LSP
   re-routing.


   The simplest notion of end-to-end LSP protection is 1+1
   unidirectional protection. Using this type of protection, a
   protecting LSP is signaled over a dedicated resource-disjoint
   alternate path to protect an associated working LSP. Normal traffic
   is simultaneously sent on both LSPs and a selector is used at the
   egress node to receive traffic from one of the LSPs. If a failure
   occurs along one of the LSPs, the egress node selects the traffic
   from the valid LSP. No coordination is required between the end
   nodes when a failure/switchover occurs.


   In 1+1 bi-directional protection, a protecting LSP is signaled over
   a dedicated resource-disjoint alternate path to protect the working
   LSP. Normal traffic is simultaneously sent on both LSPs (in both
   directions) and a selector is used at both ingress/egress nodes to
   receive traffic from the same LSP. This requires co-ordination
   between the end-nodes when switching to the protecting LSP.


   In 1:N (N =< 1) protection with extra-traffic, the protecting LSP is
   a fully provisioned and resource-disjoint LSP from the N working
   LSPs, that allows for carrying extra-traffic. The N working LSPs MAY
   be mutually resource-disjoint. Coordination between end-nodes is
   required when switching from one of the working to the protecting
   LSP. Note that M:N protection is out of scope of this document
   (though mechanisms it defines may be extended to cover it).



J.P.Lang et al. - Internet Draft ¡ Expires September 2004            3
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004




   Pre-planned LSP re-routing (or restoration) relies on the
   establishment between the same pair of end-nodes of a working LSP
   and a protecting LSP that is link/node/SRLG disjoint from the
   working one. Here, the recovery resources for the protecting LSP are
   pre-reserved and explicit action is required to activate (i.e.
   commit resource allocation at the data plane) a specific protecting
   LSP instantiated during the (pre-)provisioning phase. Since the
   protecting LSP is not "active" (i.e. fully instantiated), it can not
   carry any extra-traffic (note that this does not mean that the
   corresponding resources can not used by other LSPs). Therefore, this
   mechanism protects against working LSP(s) failure(s) but requires
   activation of the protecting LSP after working LSP failure
   occurrence. This requires restoration signaling along the protecting
   path. "Shared-mesh" restoration can be seen as a particular case of
   pre-planned LSP re-routing that reduces the recovery resource
   requirements by allowing multiple protecting LSPs to share common
   link and node resources. The recovery resources are pre-reserved and
   explicit action is required to activate (i.e. commit resource
   allocation at the data plane) a specific protecting LSP instantiated
   during the (pre-)provisioning phase. This procedure requires
   restoration signaling along the protecting path. Note that in both
   cases, any lower priority LSP that would use the pre-reserved
   resources for the protecting LSP(s) MUST be preempted during the
   activation of the protecting LSP.


   Full LSP re-routing (or restoration) switches normal traffic to an
   alternate LSP that is fully established only after working LSP
   failure occurs. The new alternate route is selected at the LSP head-
   end node, it may reuse resources of the failed LSP at intermediate
   nodes and may include additional intermediate nodes and/or links.


   Note that crankback signaling (see [CRANK]) and LSP segment recovery
   are further detailed in dedicated companion documents. Also, there
   is no impact to Fast Reroute [FRR] introduced by end-to-end
   GMPLS-based recovery i.e. it is possible to use either method
   defined in FRR with end-to-end GMPLS-based recovery. The objects
   used and/or newly introduced by end-to-end recovery will be ignored
   by [FRR] conformant implementations, and FRR can operate on a per
   LSP basis as defined in [FRR].


4. Overview


4.1 LSP Identification


   This section reviews terms previously defined in [RFC2205],
   [RFC3209], and [RFC3473]. LSP tunnels are identified by a
   combination of the SESSION and SENDER_TEMPLATE objects (see also
   [RFC-3209]). The relevant fields are as follows:


   IPv4 (or IPv6) tunnel end point address




J.P.Lang et al. - Internet Draft ¡ Expires September 2004            4
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



        IPv4 (or IPv6) address of the egress node for the tunnel.


   Tunnel ID


        A 16-bit identifier used in the SESSION that remains constant
        over the life of the tunnel.


   Extended Tunnel ID


        A 32-bit (or 16-byte) identifier used in the SESSION that
        remains constant over the life of the tunnel. Normally set to
        all zeros. Ingress nodes that wish to narrow the scope of a
        SESSION to the ingress-egress pair MAY place their IPv4 (or
        IPv6) address here as a globally unique identifier.


   IPv4 (or IPv6) tunnel sender address


        IPv4 (or IPv6) address for a sender node.


   LSP ID


        A 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC
        that can be changed to allow a sender to share resources with
        itself.


   The first three fields are carried in the SESSION object (Path and
   Resv message) and constitute the basic identification of the LSP
   tunnel.


   The last two fields are carried in the SENDER_TEMPLATE (Path
   message) and FILTER_SPEC objects (Resv message). The LSP ID is used
   to differentiate LSP tunnels that belong to the same session.


4.2 Recovery Attributes


   The recovery attributes includes all the parameters that determine
   the status of a LSP within the recovery scheme to which it is
   associated. These attributes are part of the PROTECTION object
   introduced in Section 14.


4.2.1 LSP Status


   The following bits are used in determining resource allocation and
   status of the LSP within the group of LSPs forming the protected
   entity:


   - S (Secondary) bit: enables distinction between primary and
     secondary LSPs. A primary LSP is a fully established LSP for
     which the resource allocation has been committed at the data plane
     (i.e. full cross-connection has been performed). Both working and
     protecting LSPs can be primary LSPs. A secondary LSP is an LSP
     that has been provisioned in the control plane only and for which



J.P.Lang et al. - Internet Draft ¡ Expires September 2004            5
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



     resource selection MAY have been done but for which the resource
     allocation has not been committed at the data plane (for instance,
     no cross-connection has been performed). Therefore, a secondary
     LSP is not immediately available to carry any traffic (requiring
     thus additional signaling to be available). A secondary LSP can
     only be a protecting LSP. The (data plane) resources allocated for
     a secondary LSP MAY be used by other LSPs until the primary LSP
     fails over to the secondary LSP.


   - P (Protecting) bit: enables distinction between working and
     protecting LSPs. A working LSP must be a primary LSP whilst a
     protecting LSP can be either a primary or a secondary LSP. When
     protecting LSP(s) are associated with working LSP(s), one also
     refers to the latter as protected LSPs.


   Note: The combination "secondary working" is not valid (only
   protecting LSPs can be secondary LSPs). Working LSPs are always
   primary LSPs (i.e. fully established) whilst primary LSPs can be
   either working or protecting LSPs.


   - O (Operational) bit: this bit is set when a protecting LSP is
     carrying the normal traffic after protection switching (i.e.
     applies only in case of dedicated LSP protection or LSP protection
     with extra-traffic, see Section 4.2.2).


   In this document, the PROTECTION object uses as a basis the
   PROTECTION object defined in [RFC-3471] and [RFC-3473] and defines
   additional fields within it. The fields defined in [RFC-3471] and
   [RFC-3473] are unchanged by this memo.


4.2.2 LSP Recovery


   The following classification is used to distinguish the LSP
   Protection Type with which LSPs can be associated at end-nodes (a
   distinct value is associated with each Protection Type in the
   PROTECTION object, see Section 14):


   - Full LSP Re-routing: set if a primary working LSP is dynamically
     recoverable using (non pre-planned) head-end re-routing.


   - Pre-planned LSP Re-routing without Extra-traffic: set if a
     protecting LSP is a secondary LSP that allows sharing of the
     pre-reserved recovery resources between one or more than one
     <sender;receiver> pair. When the secondary LSPs resources are not
     pre-reserved for a single <sender;receiver> pair, this type is
     referred to as "shared mesh" recovery.


   - LSP Protection with Extra-traffic: set if a protecting LSP is a
     dedicated primary LSP that allows for extra-traffic transport
     and thus precludes any sharing of the recovery resources between
     more than one <sender;receiver> pair. This type includes 1:N LSP
     protection with extra-traffic.



J.P.Lang et al. - Internet Draft ¡ Expires September 2004            6
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   - Dedicated LSP Protection: set if a protecting LSP does not allow
     sharing of the recovery resources nor the transport of extra-
     traffic (implying in the present context, duplication of the
     signal over both working and protecting LSPs as in 1+1 dedicated
     protection). Note also that this document makes a distinction
     between 1+1 unidirectional and bi-directional dedicated LSP
     protection.


   For LSP protection, in particular when the data plane provides
   automated protection switching capability (see for instance ITU-T
   G.841 Recommendation), a Notification (N) bit is defined in the
   PROTECTION object. It allows for distinction between protection
   switching signaling via the control plane or via the data plane.


   Note: this document assumes that Protection Type values have end-to-
   end significance and that the same value is sent over the protected
   and the protecting path. In this context, shared-mesh for instance,
   appears from the end-nodes perspective as being simply an LSP re-
   routing without extra-traffic services. The net result of this is
   that a single bit (the S bit alone) does not allow determining
   whether resource allocation should be performed and this *with
   respect to* the status of the LSP within the protected entity. The
   introduction of the P bit solves this problem unambiguously. These
   bits MUST be processed on a hop-by-hop basis (independently of the
   LSP Protection Type context). This allows for an easier
   implementation of reversion signaling (see Section 12) but also
   facilitates the transparent delivery of protected services since any
   intermediate node is not required to know the semantic associated
   with the incoming LSP Protection Type value.


4.3 LSP Association


   The ASSOCIATION object, introduced in Section 16, is used to
   associate the working and protecting LSPs.


   When used for the working LSP signaling, the Association ID of the
   ASSOCIATION object (see Section 16) identifies the protecting LSP.
   When used for the protecting LSP signaling, this field identifies
   the LSP protected by the protecting LSP.


5. 1+1 Unidirectional Protection


   One of the simplest notions of end-to-end LSP protection is 1+1
   unidirectional protection.


   Consider the following network topology:



                                  A---B---C---D
                                   \         /
                                    E---F---G




J.P.Lang et al. - Internet Draft ¡ Expires September 2004            7
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004




   The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint,
   ignoring the ingress/egress nodes A and D. A 1+1 protected path is
   established from A to D over [A,B,C,D] and [A,E,F,G,D] and traffic
   is transmitted simultaneously over both component paths (i.e. LSPs).


   When a failure occurs (say at node B) and is detected at end-node D,
   the receiver at D selects the normal traffic from the other LSP.
   From this perspective, 1+1 unidirectional protection can be seen as
   an uncoordinated protection switching mechanism acting independently
   at both end-points. Note also that both LSPs are fully instantiated
   (and thus activated) so that no resource sharing can be done along
   the protecting LSP (nor can any extra-traffic be transported). It is
   also RECOMMENDED to set the N bit since no protection switching
   signaling is assumed in this case. Also, for the protected LSP under
   failure condition, the Path_State_Removed Flag of the ERROR_SPEC
   object (see [RFC-3473]) SHOULD NOT be set upon PathErr message
   generation.


   Note: one should assume that both paths are SRLG disjoint otherwise,
   a failure would impact both working and protecting LSPs.


5.1. Identifiers


   Since both LSPs belong to the same session, the SESSION object MUST
   be the same for both LSPs. The LSP ID, however, MUST be different to
   distinguish between the two LSPs.


   A new PROTECTION object is included in the Path message. This object
   carries the desired end-to-end LSP Protection Type (in this case,
   "1+1 Unidirectional") as well as the LSP ID of the associated LSP
   referred to as the Association ID. This LSP Protection Type value is
   applicable to both uni- and bi-directional LSPs.


   It is also desirable to allow distinguishing the working LSP (from
   which the signal is taken) from the protecting LSP. This is achieved
   for the working LSP by setting in the PROTECTION object the S bit to
   0, the P bit to 0, and the Association ID to the protecting LSP_ID.
   The protecting LSP is signaled by setting in this object the S bit
   to 0, the P bit to 1, and the Association ID to the associated
   protected LSP_ID.


   After protection switching completes (step 2), and after reception
   of the PathErr message, to keep track of the LSP from which the
   signal is taken, the protecting LSP SHOULD be signaled with the O-
   bit set. The formerly working LSP MAY be signaled with the A bit set
   in the ADMIN_STATUS object (see [RFC-3473]). This process assumes
   the tail-end node has notified the head-end node that traffic
   selection switchover has occurred.






J.P.Lang et al. - Internet Draft ¡ Expires September 2004            8
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



6. 1+1 Bi-directional Protection


   1+1 bi-directional protection is another scheme that provides end-
   to-end LSP protection.


   Consider the following network topology:


                                  A---B---C---D
                                   \         /
                                    E---F---G



   The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint,
   ignoring the ingress/egress nodes A and D. A bi-directional LSP is
   established from A to D over each path and traffic is transmitted
   simultaneously over both LSPs. In this scheme, both end-points must
   receive traffic over the same LSP. When a failure is detected by one
   or both end-points of the LSP, both end-points must select traffic
   from the other LSP. This action must be coordinated between node A
   and D. From this perspective, 1+1 bi-directional protection can be
   seen as a coordinated protection switching mechanism between both
   end-points. Note also that both LSPs are fully instantiated (and
   thus activated) so that no resource sharing can be done along the
   protection path (nor can any extra-traffic be transported).


   Note: one should assume that both paths are SRLG disjoint otherwise
   a failure would impact both working and protecting LSPs.


6.1. Identifiers


   Since both LSPs belong to the same session, the SESSION object MUST
   be the same in both LSPs. The LSP ID, however, MUST be different to
   distinguish between the two LSPs.


   A new PROTECTION object (see Section 14) is included in the Path
   message. This object carries the desired end-to-end LSP Protection
   Type (in this case, "1+1 Bi-directional") as well as the LSP ID of
   the associated LSP referred to as Association ID. This LSP
   Protection Type value is only applicable to bi-directional LSPs.


   It is also desirable to allow distinguishing the working (LSP from
   which the signal is taken) from the protecting LSP. This is achieved
   for the working LSP by setting in the PROTECTION object the S bit to
   0, the P bit to 0, and the Association ID to the protecting LSP_ID.
   The protecting LSP is signaled by setting in this object the S bit
   to 0, the P bit to 1 and the Association ID to the associated
   protected LSP_ID.


6.2. End-to-End Switchover Request/Response


   To co-ordinate the switchover between end-points, an end-to-end
   switchover request is needed since a failure affecting one the LSPs



J.P.Lang et al. - Internet Draft ¡ Expires September 2004            9
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   results in both end-points switching to the other LSP (resulting in
   receiving traffic from the other LSP) in their respective
   directions. This is done using the Notify message with a new Error
   Code indicating "Working LSP Failure (Switchover Request)". The
   Notify Ack message MUST be sent to confirm the reception of the
   Notify message (see [RFC-3473], Section 4.3).


   The procedure is as follows:


        1. If an end-node (A or D) detects the failure of the working
           LSP (or a degradation of signal quality over the working
           LSP) or receives a Notify message including its SESSION
           object within the <upstream/downstream session list> (see
           [RFC-3473]), it MUST begin receiving on the protecting LSP
           and send a Notify message reliably to the other end-node (D
           or A, respectively). This message MAY indicate the identity
           of the failed working link and other relevant information
           using the IF_ID ERROR_SPEC (see [RFC-3473]).


           Note: in this case, the IF_ID ERROR_SPEC replaces the
           ERROR_SPEC in the Notify message, otherwise the
           corresponding (data plane) information SHOULD be received
           in the PathErr/ResvErr message.


        2. Upon receipt of the switchover message, the end-node
           (D or A, respectively) MUST begin receiving from the
           protection LSP and send a (Notify) Ack message to the other
           end-node (A or D, respectively) using reliable message
           delivery (see [RFC-2961]).


   Since the intermediate nodes (B,C,E,F and G) are assumed to be GMPLS
   signaling capable, each node adjacent to the failure MAY generate a
   Notify message directed either to the LSP head-end (upstream
   direction) or the LSP tail-end (downstream direction) or even both.
   Therefore, it is expected that these LSP terminating nodes (that MAY
   also detect the failure of the LSP from the data plane) provide
   either the right correlation mechanism to avoid repetition of the
   above procedure or just discard subsequent Notify messages
   corresponding to the same Session. In addition, for the working LSP
   under failure, the Path_State_Remove Flag of the ERROR_SPEC object
   (see [RFC-3473]) SHOULD NOT be set upon PathErr message generation.


   After protection switching completes (step 2), and after reception
   of the PathErr message, to keep track of the LSP from which the
   signal is taken, the protecting LSP SHOULD be signaled with the O-
   bit set. The formerly working LSP MAY be signaled with the A bit set
   in the ADMIN_STATUS object (see [RFC-3473]).


   Note: when the N bit is set, the end-to-end switchover request/
   response exchange described above only provides control plane
   coordination (no actions are triggered at the data plane level).




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           10
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



7. 1:1 Protection with Extra-Traffic


   The most common case of end-to-end 1:N protection is to establish,
   between the same end-points, an end-to-end working LSP (thus, N = 1)
   and a dedicated end-to-end protecting LSP that are mutually link/
   node/SRLG disjoint. This protects against working LSP failure(s).


   The protecting LSP is used for fast switchover when the working LSP
   fails. GMPLS signaling allows for the pre-provisioning of protecting
   LSPs by indicating in the Path message (in the PROTECTION object,
   see Section 14) that the LSPs are of type protecting. Here, working
   and protecting LSPs are signaled as primary LSPs; both are fully
   instantiated during the provisioning phase.


   Although the resources for the protecting LSP are pre-allocated,
   preemptable traffic may be carried end-to-end using this LSP (i.e.
   the protecting LSP is capable of carrying extra-traffic) with the
   caveat that this traffic will be preempted if the working LSP fails.
   Also, if extra-traffic is carried over the protecting LSP, the
   corresponding end-nodes may need to be notified of the failure in
   order to complete the switchover.


   The setup of the working LSP SHOULD indicate that the LSP head-end
   and tail-end node wish to receive Notify messages using the NOTIFY
   REQUEST object. The node upstream to the failure (upstream in terms
   of the direction an RSVP Path message traverses) SHOULD send an RSVP
   Notify message to the LSP head-end node, and the node downstream to
   the failure SHOULD send an RSVP Notify message to the LSP tail-end
   node. Upon receipt of the Notify messages, both the end-nodes MUST
   switch the (normal) traffic from the working LSP to the pre-
   configured protecting LSP (see Section 7.2). Moreover some
   coordination is required if extra-traffic is carried over the end-
   to-end protecting LSP. Note that if the working and the protecting
   LSP are established between the same end-nodes no further
   notification is required to indicate that the working LSPs are no
   longer protected.


   Consider the following topology:


                                  A---B---C---D
                                   \         /
                                    E---F---G



   The working LSP [A,B,C,D] could be protected by the protecting LSP
   [A,E,F,G,D]. Both LSPs are fully instantiated (resources are
   allocated for both working and protecting LSPs) and no resource
   sharing can be done along the protection path since the primary
   protecting LSP can carry extra-traffic.


   Note: one should assume that both paths are SRLG disjoint otherwise
   a failure would impact both working and protecting LSPs.



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           11
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



7.1 Identifiers


   Since both LSPs belong to the same session, the SESSION object MUST
   be the same in both LSPs. The LSP ID, however, MUST be different to
   distinguish between the protected LSP carrying working traffic and
   the protecting LSP that can carry extra-traffic.


   A new PROTECTION object (see Section 14) is included in the Path
   message used to setup the two LSPs. This object carries the desired
   end-to-end LSP Protection Type (in this case, "1:N Protection with
   Extra-Traffic"). This LSP Protection Type value is applicable to
   both uni- and bi-directional LSPs.


   The working LSP is signaled by setting in this object the S bit to
   0, the P bit to 0 and the Association ID to the protecting LSP_ID.
   The protecting LSP is signaled by setting in this object the S bit
   to 0, the P bit to 1, and the Association ID to the associated
   protected LSP_ID.


7.2 End-to-End Switchover Request/Response


   To co-ordinate the switchover between end-points, an end-to-end
   switchover request is needed such that the affected LSP(s) are moved
   to the protecting LSP. Protection switching from the working to the
   protecting LSP (implying preemption of extra-traffic carried over
   the protecting LSP) must be initiated by one of the end-nodes (A or
   D).


   This operation may be done using a Notify message exchange with a
   new Error Code indicating "(Working) LSP Failure (Switchover
   Request)". The Notify Ack message MUST be sent to confirm the
   reception of the Notify message.


   The procedure is as follows:


        1. If an end-node (A or D) detects the failure of the working
           LSP (or a degradation of signal quality over the working
           LSP) or receives a Notify message including its SESSION
           object within the <upstream/downstream session list> (see
           [RFC-3473]), it disconnects the extra-traffic from the
           protecting LSP and send a Notify message reliably to the
           other end-node (D or A, respectively). This message MAY
           indicate the identity of the failed working link and other
           relevant information using the IF_ID ERROR_SPEC (see [RFC-
           3473]).


        Note: in this case, the IF_ID ERROR_SPEC replaces the
        ERROR_SPEC in the Notify message, otherwise the corresponding
        information SHOULD be received in the PathErr/ResvErr message


        2. Upon receipt of the switchover (i.e. end-to-end Notify)
           message, the end-node (D or A, respectively) MUST disconnect



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           12
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



           the extra-traffic from the protecting LSP and begin
           sending/receiving normal traffic out/from the protecting LSP
           and send a (Notify) Ack message to the other end-node (A or
           D, respectively) using reliable message delivery (see [RFC
           2961]). Also, the Notify message generated by the end-node
           is distinguishable from the one generated by an intermediate
           node, there is no possibility of connecting the extra
           traffic to the working LSP due to the receipt of Notify
           message from an intermediate node.


        3. Upon receipt of the switchover (Notify) Ack message, the
           end-node (A or D, respectively) MUST begin receiving normal
           traffic from the protecting LSP.


   Note 1: a 2-phase protection switching signaling is used in the
   present context, a 3-phase signaling (see [FUNCT]) that would imply
   a notification message and a switchover request/response messages,
   is not considered here. Also, when the protecting LSPs do not carry
   extra-traffic, a 1-Phase protection switching signaling as defined
   in Section 6.2 MAY be used instead of the 2-Phase described here
   above.


   Note 2: when the N bit is set, the above end-to-end switchover
   request/response exchange does only provide control plane
   coordination (no actions are triggered at the data plane level).


   After protection switching completes (step 3), and after reception
   of the PathErr message, to keep track of the LSP from which the
   normal traffic is taken, the protecting LSP SHOULD be signaled with
   the O-bit set. In addition, the formerly working LSP MAY be signaled
   with the A bit set in the ADMIN_STATUS object (see [RFC-3473]).


7.3 1:N (N > 1) Protection with Extra-Traffic


   1:N (N > 1) protection with extra-traffic assumes that the fully
   provisioned protecting LSP is resource-disjoint LSP from the N
   working LSPs. This protecting LSP allows thus for carrying extra-
   traffic. In addition, the N working LSPs (considered as identical in
   terms of traffic parameters) MAY be mutually resource-disjoint.
   Coordination between end-nodes is required when switching from one
   of the working to the protecting LSP.


   Each working LSP is signaled with both S bit and P bit set to 0. The
   LSP Flag is set to 0x04 (during LSP setup). Each Association ID
   points to the protecting LSP ID. The protecting LSP (carrying extra-
   traffic) is signaled with S bit set to 0 and P bits set to 1. The
   LSP Flag is set to 0x04 (during LSP setup). The Association ID is
   not significant (multiple protected LSPs) and MUST be set by default
   to the LSP ID of the protected LSP corresponding to N = 1.


   Any signaling procedure applicable to 1:1 protection with extra-
   traffic equally applies to 1:N protection with extra-traffic.



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           13
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



8. Re-routing without Extra-Traffic


   End-to-end (pre-planned) re-routing without extra-traffic relies on
   the establishment between the same pair of end-nodes of a working
   LSP and a protecting LSP that is link/node/SRLG disjoint from the
   working one. However, in this case the protecting LSP is not fully
   instantiated, thus, it can not carry any extra-traffic (note that
   this does not mean that the corresponding resources can not used by
   other LSPs). Therefore, this mechanism protects against working LSP
   failure(s) but requires activation of the protecting LSP after
   failure occurrence.


   Signalling is performed by indicating in the Path message (in the
   PROTECTION object, see Section 14) that the LSPs are of type working
   and protecting, respectively. Protecting LSPs are used for fast
   switchover when working LSPs fail. In this case, working and
   protecting LSPs are signaled as primary LSP and secondary LSP,
   respectively. Thus, only the working LSP is fully instantiated
   during the provisioning phase and for the protecting LSPs, no
   resources are committed at the data plane level (they are pre-
   reserved at the control plane level only). The setup of the working
   LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in
   Section 4 of [RFC-3473]) that the LSP head-end node (and possibly
   the tail-end node) wish to receive a Notify message upon LSP failure
   occurrence. Upon receipt of the Notify message, the head-end node
   MUST switch the (normal) traffic from the working LSP to the
   protecting LSP after its activation. Note that since the working and
   the protecting LSP are established between the same end-nodes no
   further notification is required to indicate that the working LSPs
   are no longer protected.


   To make bandwidth pre-reserved for a protecting but not activated
   LSP, available for extra traffic this bandwidth could be included in
   the advertised Unreserved Bandwidth at priority lower (means
   numerically higher) than the Setup Priority of the protecting LSP.
   In addition, the Max LSP Bandwidth field in the Interface Switching
   Capability Descriptor sub-TLV should reflect the fact that the
   bandwidth pre-reserved for the protecting LSP is available for extra
   traffic. LSPs for extra traffic then can be established using the
   bandwidth pre-reserved for the protecting LSP by setting (in the
   Path message) the Setup Priority field of the SESSION_ATTRIBUTE
   object to X (where X is the Setup Priority of the protecting LSP)
   and the Holding Priority field at least to X+1. Also, if the
   resources pre-reserved for the protecting LSP are used by lower
   priority LSPs, these LSPs MUST be preempted when the protecting LSP
   is activated.


   Consider the following topology:


                                  A---B---C---D
                                   \         /
                                    E---F---G



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           14
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   The working LSP [A,B,C,D] could be protected by the protecting LSP
   [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources
   are only allocated for the working LSP) therefore, the protecting
   LSP can not carry any extra-traffic. When a failure is detected on
   the working LSP (say at B), the error is propagated and/or notified
   to the ingress node (A), which activates the secondary protecting
   LSP instantiated during the (pre-)provisioning phase. This requires:
   (1)  the ability to identify a "secondary protecting LSP" (hereby
        called the "secondary LSP") used to recover another primary
        working LSP (hereby called the "protected LSP")
   (2)  the ability to associate the secondary LSP with the protected
        LSP
   (3)  the capability to activate a secondary LSP after failure
        occurrence.


   In the following subsections, these features are described in more
   detail.


8.1 Identifiers


   Since both LSPs (i.e. the primary working and the secondary
   protecting LSPs) belong to the same session, the SESSION object MUST
   be the same in both LSPs. The LSP ID, however, MUST be different to
   distinguish between the protected LSP carrying working traffic and
   the secondary protecting LSP that can not carry extra-traffic.


   A new PROTECTION object (see Section 14) is used to setup the two
   LSPs. This object carries the desired end-to-end LSP Protection Type
   in this case, "Re-routing without Extra-Traffic") as well as the LSP
   ID of the association LSP. This LSP Protection Type value is
   applicable to both uni- and bi-directional LSPs.


8.2 Signaling Primary LSPs


   The new PROTECTION object is included in the Path message during
   signaling of the primary working LSP, with the end-to-end LSP
   Protection Type value set to "Re-routing without Extra-Traffic".


   Primary working LSPs are signaled by setting in this object the S
   bit to 0, the P bit to 0 and the Association ID to the protecting
   LSP_ID.


8.3 Signaling Secondary LSPs


   The new PROTECTION object carried in the Path message includes the
   desired end-to-end LSP Protection Type (in this case, "Re-routing
   without Extra-Traffic") as well as the LSP ID of the associated
   primary working LSP, which MUST be known before signaling of the
   secondary LSP. This LSP Protection Type value is applicable to both
   uni- and bi-directional LSPs.





J.P.Lang et al. - Internet Draft ¡ Expires September 2004           15
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   Secondary (protecting) LSPs are signaled by setting in this object
   the S bit and the P bit to 1. With this setting, the resources for
   the protecting LSP SHOULD be pre-reserved, but not committed at the
   data plane level meaning that the internals of the switch need not
   be established until explicit action is taken to activate this
   secondary LSP. Activation of a secondary LSP is done using a
   modified Path message with the S bit set to 0 in the PROTECTION
   object. At this point, the link and node resources must be allocated
   for this LSP that becomes a primary LSP (ready to carry normal
   traffic).


   Two cases have to be covered here (see also [GMPLS-ARCH]) since
   secondary protecting LSPs are setup with resource pre-reservation
   but with or without label pre-selection (both allowing sharing of
   the recovery resources). In the former case (defined as the
   default), secondary LSP signaling does not necessitate any specific
   procedure compared to the one defined in [RFC-3473]. However, in the
   latter case, label (and thus resource) re-allocation MAY occur
   during the secondary LSP activation. This means that during the
   activation phase, labels MAY be re-assigned (with higher precedence
   over existing label assignment, see also [RFC-3471]).


   Note: in certain circumstances, it MAY be desirable to perform the
   activation of the secondary LSP in the upstream direction (Resv
   trigger message) instead of using the default downstream method. In
   this case, and in order to avoid any mis-ordering and any mis-
   interpretation between a refresh Resv and a trigger Resv message at
   intermediate nodes along the secondary LSP, upon reception of the
   Path message, the egress node MAY include the PROTECTION object in
   the Resv message. The latter is then processed on a hop by hop basis
   to activate the secondary LSP until reaching the ingress node. The
   PROTECTION object included in the Path message MUST be set as
   specified in this Section. The upstream activation behavior SHOULD
   be configurable on a local basis.


9. Shared-Mesh Restoration


   An approach to reduce recovery resource requirements is to have
   protection LSPs sharing network resources when the working LSPs that
   they protect are physically (i.e., link, node, SRLG, etc.) disjoint.
   This mechanism is referred to as shared mesh restoration and is
   described in [FUNCT]. Shared-mesh restoration can be seen as a
   particular case of pre-planned LSP re-routing (see Section 8) that
   reduces the recovery resource requirements by allowing multiple
   protecting LSPs to share common link and node resources. Here also,
   the recovery resources for the protecting LSPs are pre-reserved
   during the provisioning phase, thus an explicit signaling action is
   required to activate (i.e. commit resource allocation at the data
   plane) a specific protecting LSP instantiated during the (pre-
   )provisioning phase. This requires restoration signaling along the
   protecting LSP.




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           16
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   To make bandwidth pre-reserved for a protecting but not activated
   LSP, available for extra traffic this bandwidth could be included in
   the advertised Unreserved Bandwidth at priority lower (means
   numerically higher) than the Setup Priority of the protecting LSP.
   In addition, the Max LSP Bandwidth field in the Interface Switching
   Capability Descriptor sub-TLV should reflect the fact that the
   bandwidth pre-reserved for the protecting LSP is available for extra
   traffic. LSPs for extra traffic then can be established using the
   bandwidth pre-reserved for the protecting LSP by setting (in the
   Path message) the Setup Priority field of the SESSION_ATTRIBUTE
   object to X (where X is the Setup Priority of the protecting LSP)
   and the Holding Priority field at least to X+1. Also, if the
   resources pre-reserved for the protecting LSP are used by lower
   priority LSPs, these LSPs MUST be preempted when the protecting LSP
   is activated. Further, if the recovery resources are shared between
   multiple protecting LSPs, the corresponding working LSPs head-end
   nodes must be informed that they are no longer protected when the
   protecting LSP is activated to recover the normal traffic for the
   working LSP under failure.


   Consider the following topology:


                                  A---B---C---D
                                   \         /
                                    E---F---G
                                   /         \
                                  H---I---J---K



   The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by
   [A,E,F,G,D] and [H,E,F,G,K], respectively. In order to achieve
   resource merging during the signaling of these protecting LSPs (i.e.
   resource sharing), the LSPs must have the same Session Ids, but the
   Session Id includes the target (egress) IP address. These addresses
   are not the same in this example. Resource sharing along E, F, G can
   only be achieved if the nodes E, F and G recognize that the LSP Type
   setting of the secondary LSPs is for protection (see PROTECTION
   object, Section 14) and acts accordingly. In this case, the
   protecting LSPs are not merged (which is useful since the paths
   diverge at G), but the resources can be shared.


   When a failure is detected on one of the working LSPs (say at B),
   the error is propagated and/or notified to the ingress node (A),
   which activates the protecting LSP (see Section 8). At this point,
   it is important that a failure on the other LSP (say at J) does not
   cause the other ingress (H) to send the data down the protecting LSP
   since the resources are already in use. This can be achieved by node
   E using the following procedure. When the capacity is first reserved
   for the protecting LSP, E should verify that the LSPs being
   protected ([A,B,C,D] and [H,I,J,K], respectively) do not share any
   common resources. Then, when a failure occurs (say at B) and the
   protecting LSP [A,E,F,G,D] is activated, E should notify H that the



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           17
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   resources for the protecting LSP [H,E,F,G,K] are no longer
   available.


   The following sub-sections details how shared mesh restoration can
   be implemented in an interoperable fashion using GMPLS RSVP-TE
   extensions (see [RFC-3473]). This includes:
   (1)  the ability to identify a "secondary protecting LSP" (hereby
        called the "secondary LSP") used to recover another primary
        working LSP (hereby called the "protected LSP")
   (2)  the ability to associate the secondary LSP with the protected
        LSP
   (3)  the capability to include information about the resources used
        by the protected LSP while instantiating the secondary LSP.
   (4)  the capability to instantiate during the provisioning phase
        several secondary LSPs in an efficient manner.
   (5)  the capability to activate a secondary LSP after failure
        occurrence.


   In the following subsections, these features are described in
   detail.


9.1. Identifiers


   Since both LSPs (i.e. the primary working and the secondary
   protecting LSPs) belong to the same session, the SESSION object MUST
   be the same in both LSPs. The LSP ID, however, MUST be different to
   distinguish between the protected LSP carrying working traffic and
   the secondary protecting LSP that can not carry extra-traffic.


   A new PROTECTION object (see Section 14) is used to setup the two
   LSPs. This object carries the desired end-to-end LSP Protection Type
   in this case, "Re-routing without Extra-Traffic") as well as the LSP
   ID of the associated LSP. This LSP Protection Type value is
   applicable to both uni- and bi-directional LSPs.


9.2 Signaling Primary LSPs


   The new PROTECTION object is included in the Path message during
   signaling of the primary working LSP, with the end-to-end LSP
   Protection Type value set to "Re-routing without Extra-Traffic".


   Primary working LSPs are signaled by setting in this object the S
   bit to 0, the P bit to 0 and the Association ID to the protecting
   LSP_ID.


9.3 Signaling Secondary LSPs


   The new PROTECTION object carried in the Path message includes the
   desired end-to-end LSP Protection Type (in this case, "Re-routing
   without Extra-Traffic") as well as the LSP ID of the associated
   primary working LSP, which MUST be known before signaling of the




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           18
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   secondary LSP. This LSP Protection Type value is applicable to both
   uni- and bi-directional LSPs.


   Secondary (protecting) LSPs are signaled by setting in this object
   the S bit and the P bit to 1. Moreover, the Path message used to
   instantiate this LSP MUST include at least one PRIMARY PATH ROUTE
   object (see Section 15) that further allows for recovery resource
   sharing at each intermediate node along the secondary path. With
   this setting, the resources for the protecting LSP SHOULD be pre-
   reserved, but not committed at the data plane level meaning that the
   internals of the switch need not be established until explicit
   action is taken to activate this LSP. Activation of a secondary LSP
   is done using a modified Path message with the S bit set to 0 in the
   PROTECTION object. At this point, the link and node resources must
   be allocated for this LSP that becomes a primary LSP (ready to carry
   normal traffic).


   Two cases have to be covered here (see also [GMPLS-ARCH]) since the
   secondary LSP are setup with resource pre-reservation but with or
   without label pre-selection (both allowing sharing of the recovery
   resources). In the former case (defined as the default), secondary
   LSP signaling does not necessitate any specific procedure compared
   to the one defined in [RFC-3473]. However, in the latter case, label
   (and thus resource) re-allocation MAY occur during the secondary LSP
   activation. This means that during the LSP activation phase, labels
   MAY be re-assigned (with higher precedence over existing label
   assignment, see also [RFC-3471]).


11. (Full) LSP Re-routing


   LSP re-routing, on the other hand, switches normal traffic to an
   alternate LSP that is fully established only after failure
   occurrence. The new (alternate) route is selected at the LSP head-
   end and may reuse intermediate nodes included in the original route;
   it may also include additional intermediate nodes. For strict-hop
   routing, TE requirements can be directly applied to the route
   computation, and the filed node or link can be avoided. However, if
   the failure occurred within a loose-routed hop, the head-end node
   may not have enough information to reroute the LSP around the
   failure. Crankback signaling and route exclusion techniques (see
   [XRO]) MAY be used in this case.


   The alternate route may be either computed on demand (that is, when
   the failure occurs; this is referred to as full LSP re-routing) or
   pre-computed and stored for use when the failure is reported. The
   latter offers faster restoration time. There is, however, a risk
   that the alternate route will become out of date through other
   changes in the network - this can be mitigated to some extent by
   periodic recalculation of idle alternate routes.


   (Full) LSP re-routing will be initiated by the head-end node that
   has either detected the failure or received a Notify message and/or



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           19
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   a PathErr message indicating that a failure has occurred. The new
   LSP resources can be established using the make-before-break
   mechanism, where the new LSP is setup before the old LSP is torn
   down. This is done by using the mechanisms of the SESSION object and
   the Shared-Explicit (SE) reservation style (see [RFC-3209]). Both
   the new and old LSPs can share resources at common nodes.


   Note that the make-before-break mechanism is not used to avoid
   disruption to the normal traffic flow (the latter has already been
   broken by the failure that is being repaired). However, it is
   valuable to retain the resources allocated on the original LSP that
   will be re-used by the new alternate LSP.


11.1 Identifiers


   The Tunnel End Point Address, Tunnel Id, Extended Tunnel Id, Tunnel
   Sender Address and LSP Id are all used to uniquely identify both the
   old and new LSPs. The new (alternate) LSP is setup before the old
   LSP is torn down using Shared-Explicit (SE) reservation style. This
   ensures that the new LSP is established without double counting
   resource requirements along common segments.


   Note: if the alternate LSP is setup before any failure occurrence
   with SE style resource reservation, the latter shares the same
   Tunnel End Point Address, Tunnel Id, Extended Tunnel Id, and Tunnel
   Sender Address with the original LSP (i.e. only the LSP Id value
   MUST be different).


11.2 Signaling Re-routable LSPs


   A new PROTECTION object is included in the Path message during
   signaling of dynamically re-routable LSPs, with the end-to-end LSP
   Protection Type value set to "Full Re-routing". These LSPs that can
   be either uni- or bi-directional are signaled by setting in this
   object the S bit to 0, the P bit to 0 and the Association ID to 0.
   Any specific action to be taken during the provisioning phase is up
   the end-node local policy.


   Note: when the end-to-end LSP Protection Type is set to
   "Unprotected", both S and P bit MUST be set to 0 and the LSP MUST
   NOT be re-routed at the head-end node after failure occurrence. The
   Association_ID value MUST be set to 0.


12. Reversion


   Reversion refers to a recovery switching operation, where the normal
   traffic returns to (or remains on) the working LSP when it has
   recovered from the failure. Reversion implies that resources remain
   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 and reconfiguration.




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           20
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   For "1+1 bi-directional" and "1:N Protection with Extra-traffic"
   protection, reversion to the recovered LSP occurs by using the
   following sequence:
   - first, clear the A bit of the ADMIN_STATUS object if set for the
     recovered LSP
   - then, apply the reverse 1-phase APS switchover request/response
     (or 2-phase APS) described in Section 6.2 (or Section 7.2,
     respectively) to switch normal traffic back from the
     protecting to the recovered LSP. This is performed by using the
     Notify message with a new Error Code indicating "(Working) LSP
     Recovered (Switchover Request)". The Notify Ack message MUST be
     sent to confirm the reception of the Notify message (see [RFC-
     3473], Section 4.3).
   - finally, clear the O bit of the PROTECTION object sent over the
     protecting LSP.


   For "Re-routing without Extra-traffic" reversion (including the
   shared recovery case) implies that the formerly working LSP has not
   been torn down by the head-end node upon PathErr message reception
   (i.e. the head-end node kept refreshing the working LSP under
   failure condition). This ensures that the same resources are
   retrieved after reversion switching. Re-activation is performed
   using the following sequence:
   - first, clear the A bit of the ADMIN_STATUS object if set for the
     recovered LSP
   - then, apply the reverse 1-phase APS switchover request/response
     described in Section 6.2, to switch normal traffic back from the
     protecting to the recovered LSP. This is performed by using the
     Notify message with a new Error Code indicating "(Working) LSP
     Recovered (Switchover Request)". The Notify Ack message MUST be
     sent to confirm the reception of the Notify message (see [RFC-
     3473], Section 4.3).
   - finally, de-activate the protecting LSP by setting the S bit to 1
     in the PROTECTION object sent over the protecting LSP.


13. External Commands


   This section specifies the control plane behavior when using several
   external commands (see [TERM]), typically issued by an operator
   through the Network Management System (NMS)/Element Management
   System (EMS), which can be used to influence or command the recovery
   operations. Other specific commands may complete the below list.


   A. Lockout of recovery LSP:


   The Lockout bit (L bit) of the ADMIN_STATUS object is used following
   the rules defined in Section 8 of [RFC-3471] and Section 7 of [RFC-
   3473]. The L bit must be set together with the Reflect (R) bit in
   the ADMIN_STATUS object sent in the Path message. Upon reception of
   the Resv message with the L bit set, this forces the recovery LSP to
   be temporarily unavailable to transport traffic (either normal or




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           21
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   extra traffic). Unlock is performed by clearing the L bit, following
   the rules defined in Section 7 of [RFC-3473].


   B. Lockout of normal traffic:


   The O bit of the PROTECTION object is set to 1 to force the recovery
   LSP to be temporarily unavailable to transport normal traffic. This
   operation MUST never occur unless the working LSP is carrying the
   normal traffic. Unlock is performed by clearing the O bit over the
   protecting LSP.


   C. Forced switch for normal traffic:


   Recovery signaling is initiated externally that switches normal
   traffic to the recovery LSP following the procedures defined in
   Section 6, 7, 8 and 9.


   D. Manual switch for normal traffic:


   Recovery signaling operation is initiated externally that switches
   normal traffic to the recovery LSP following the procedures defined
   in Section 6, 7, 8 and 9. This, unless a fault condition exists on
   other LSPs/spans (including the recovery LSP) or an equal or higher
   priority switch command is in effect.


   E. Manual switch for recovery LSP:


   Recovery signaling operation is initiated externally that switches
   normal traffic to the working LSP following the procedure defined in
   Section 12. This, unless a fault condition exists on the working LSP
   or an equal or higher priority switch command is in effect.


14. PROTECTION Object


   In this section, we describe the extensions to the PROTECTION object
   to broaden its applicability to end-to-end LSP recovery. In addition
   to modifications to the format of the PROTECTION object, we extend
   its use so that the object can be included in the Notify message to
   act a switchover request for 1+1 bi-directional and 1:1 protection.


   The format of the PROTECTION 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             | Class-Num(37) | C-Type (TBA)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|P|N|O| Reserved  | LSP Flags |     Reserved      | Link Flags|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           22
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004




      Secondary (S): 1 bit


         When set to 1, this bit indicates that the requested LSP is a
         secondary LSP. When set to 0 (default), it indicates that the
         requested LSP is a primary LSP.


      Protecting (P): 1 bit


         When set to 1, this bit indicates that the requested LSP is a
         protecting LSP. When set to 0 (default), it indicates that the
         requested LSP is a working LSP. The combination, S set to 1
         with P set to 0 is not valid.


      Notification (N): 1 bit


         When set to 1, this bit indicates that the control plane
         message exchange is only used for notification during
         protection switching. When set to 0 (default), it indicates
         that the control plane message exchanges are used for
         protection switching purposes. The N bit is only applicable
         when the LSP Flag is set to either 0x04, or 0x08 or 0x10. The
         N bit MUST be set to 0 in any other case.


      Operational (O): 1 bit


         When set to 1, this bit indicates that the protecting LSP is
         carrying the normal traffic after protection switching. The O
         bit is only applicable when the P bit is set to 1 and the LSP
         Flag is set to either 0x04, or 0x08 or 0x10. The O bit MUST be
         set to 0 in any other case. The O bit MUST be set to 0 in any
         other case.


      Reserved: 5 bits


         This field is reserved. It MUST be set to zero on transmission
         and MUST be ignored on receipt. These bits SHOULD be passed
         through unmodified by transit nodes.


      LSP (Protection Type) Flags: 6 bits


         Indicates the desired end-to-end LSP recovery type. A value of
         0 implies that the LSP is "Unprotected". Only one value SHOULD
         be set at a time. The following values are defined. All other
         values are reserved.


                0x00    Unprotected
                0x01    (Full) Re-routing
                0x02    Re-routing without Extra-Traffic
                0x04    1:N Protection with Extra-Traffic
                0x08    1+1 Unidirectional Protection
                0x10    1+1 Bi-directional Protection



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           23
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004




      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 passed
         through unmodified by transit nodes.


      Link Flags: 6 bits


         Indicates the desired link protection type (see [RFC-3471]).


   Intermediate nodes processing a Path message containing a PROTECTION
   object with the LSP Protection Type "0x02" value set and a PRIMARY
   PATH ROUTE object (see Section 15) and MUST verify that the
   requested LSP Protection Type can be supported by the outgoing
   interface. If it can not, the node MUST generate a PathErr message,
   with a "Routing problem/Unsupported LSP Protection" indication.
   Intermediate and Egress nodes processing a Path message containing
   the PROTECTION object MUST verify that the requested LSP Protection
   Type can be satisfied by the incoming interface. If it cannot, the
   node MUST generate a PathErr message, with the "Routing problem/
   Unsupported LSP Protection" error code.


15. PRIMARY PATH ROUTE Object


   The PRIMARY PATH ROUTE object (PPRO) is defined to inform nodes
   along the path of a secondary protecting LSP about which resources
   (link/nodes) are being used by the associated primary protected LSP
   (as specified by the Association ID field). This object MUST be
   present in the Path message (for the pre-provisioning of the
   secondary protecting LSP) if and only if the LSP Protection Type
   value is set to "0x02". This document does not assume or preclude
   any other usage for this object.


   PRIMARY PATH ROUTE objects carry information extracted from the
   EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary
   working LSPs they protect. Selection of the PPRO content is up to
   local policy of the head-end LSR that initiates the request.
   Therefore, the information included in these objects MAY be used as
   policy-based admission control to ensure that recovery resources are
   only shared between secondary protecting LSPs whose associated
   primary LSPs have link/node/SRLG disjoint paths.


15.1. Definition


   The primary path route is specified via the PRIMARY_PATH_ROUTE
   object (PPRO). The Primary Path Route Class Number is TBA by IANA.


   Currently one C-Type (Class-Type) is defined, Type 1 Primary Path
   Route. The PRIMARY_PATH_ROUTE object has the following format:


   Class-Num = TBA by IANA (of form 0bbbbbbb), C-Type = 1 (suggested)



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           24
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004




      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The contents of a PRIMARY_PATH_ROUTE object are a series of
   variable-length data items called subobjects. The subobjects are
   identical to those that can constitute an EXPLICIT/RECORD ROUTE
   object as defined in [RFC-3209], [RFC-3473] and [RFC-3477].


   To signal a secondary protecting LSP, the Path message MUST include
   at least one or MAY include multiple PRIMARY_PATH_ROUTE objects,
   where each object is meaningful. The latter is useful when a given
   secondary protecting LSP must be link/node/SRLG disjoint from more
   than one primary LSP (i.e. is protecting more than one primary LSP).


15.2 Applicability


   The PRIMARY_PATH_ROUTE object MUST only be used when all GMPLS nodes
   along the path support the PRIMARY_PATH_ROUTE object and a secondary
   protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is
   assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes
   along the path that do not support this object MUST return a PathErr
   message with the "Unknown Object Class" error code.


   Also, the following restrictions MUST be applied with respect to the
   PPRO usage:


   - PPROs MUST only be sent over secondary protecting LSPs (S bit = 1
     and P bit = 1) and when the LSP Protection Type value is set to
     "0x02" in the PROTECTION object (see Section 14.)


   - Crossed exchanges of PPROs over primary LSPs are forbidden (i.e.
     their usage is restricted to a single set of protected LSPs). If a
     PPRO is received with the S bit set to 0 in the PROTECTION object,
     the receiving node MUST return a PathErr with the "Routing
     Problem/PRIMARY PATH_ROUTE object not applicable" error code.


   - The PPRO's content MUST NOT include subobjects coming from other
     PPROs. In particular, received PPROs MUST NOT be re-used to
     establish other working or protecting LSPs.


15.3 Subobjects


   The PRIMAY_PATH_ROUTE object is defined as a list of variable-length
   data items called subobjects. PPR subobjects are derived from the
   subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           25
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   primary working LSP(s). Each PPR subobject has its own length field.
   The length contains the total length of the subobject in bytes,
   including the Type and Length fields. The length MUST always be a
   multiple of 4, and at least 4.


   The following subobjects are currently defined for the PRIMARY PATH
   ROUTE object:


   - Sub-Type 1: IPv4 Address (see [RFC 3209])
   - Sub-Type 2: IPv6 Address (see [RFC 3209])
   - Sub-Type 3: Label (see [RFC-3473])
   - Sub-Type 4: Unnumbered Interface (see [RFC-3477])


   An empty PPRO with no subobjects is considered as illegal. If there
   is no first subobject, the corresponding Path message is also in
   error and the receiving node SHOULD return a PathErr with the
   "Routing Problem/Bad PRIMARY PATH_ROUTE object" error code.


   Note: an intermediate node processing a PPRO can derive SRLG
   identifiers from the local IGP-TE database using its Type 1, 2 or 4
   subobject values as pointers to the corresponding TE Links (assuming
   each of them has an associated SRLG TE attribute).


15.4 Processing


   The PPRO enables of sharing recovery resources between a given
   secondary protecting LSP and one or more secondary protecting LSPs
   if their corresponding primary working LSPs have mutually
   (link/node/SRLG) disjoint paths. Consider a node N through which n
   secondary protecting LSPs (say P[1],...,P[n]) have already been
   established and protecting n primary working LSPs (say
   P'[1],...,P'[n]). Suppose also that these n secondary working LSPs
   share a given outgoing link resource (say r).


   Now, suppose that node N receives a Path message for an additional
   secondary protecting LSP (say Q, protecting Q'). The PPRO carried by
   this Path messages is processed as follows:


   - N checks whether the primary working LSPs P'[1],...,P'[n]
     associated with the LSPs P[1],...,P[n] respectively have any link,
     node and SLRG in common with the primary working Q' (associated
     with Q) by comparing the stored PPRO subobjects associated with
     P'[1],...,P'[n] with the PPRO subobjects associated with Q'
     received in the Path message.


   - If this is the case, N SHOULD NOT attempt to share the outgoing
     link resource r between P[1],...,P[n] and Q. However, upon local
     policy decision, N MAY allocate another available (shared) link
     other than r for use by Q. If this is not the case (upon the local
     policy decision that no other link is allowed to be allocated for
     Q) or if no other link is available for Q, N SHOULD return a
     PathErr message with the "Admission Control Failure/LSP Admission



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           26
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



     Failure" error code.


   - Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link
     r selected by N for the LSP Q MAY be exactly the same as the one
     selected for the LSPs P[1],...,P[n]. This, after verifying (also
     from its local policy) that the selected link r can be shared
     between these LSPs. If this is not the case (for instance, the
     sharing ratio has reached its maximum for that link) and upon
     local policy decision no other link is allowed to be allocated for
     Q, N SHOULD return a PathErr with the "Admission Control Failure/
     Requested Bandwidth Unavailable" error code. Otherwise (if no
     other link is available), N SHOULD return a PathErr with the
     "Admission Control Failure/LSP Admission Failure" error code.


   Note that the process, through which m out of the n (m =< n)
   secondary protecting LSPs PPROs may be selected on a local basis to
   perform the above comparison and subsequent link selection, is out
   of scope of this document.


16. ASSOCIATION Object


   The ASSOCIATION object is used to associate LSPs with each other. In
   the context of end-to-end LSP recovery, the association MUST only
   identify LSPs that support the same Tunnel ID. The Association Type,
   Association Source and Association ID fields of the object together
   uniquely identify an association. The object uses an object class
   number of the form 11bbbbbb to ensure compatibility with non-
   supporting nodes.


   The ASSOCIATION object is used to associate LSPs with each other.


16.1. Format


   The IPv4 Association object has the format:


     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             | Class-Num(TBD)|  C-Type (1)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  IPv4 Association Source                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The IPv6 Association object has the format:


     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             | Class-Num(TBD)|  C-Type (2)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           27
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                  IPv6 Association Source                      |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Association Type: 16 bits


        Indicates the type of association being identified. Note that
        this value is considered when determining association. The
        following are values defined in this document.


            Value       Type
            -----       ----
              0         Reserved
              1         Recovery (R)


      Association ID: 16 bits


        A value that when combined with Association Type and
        Association Source uniquely identifies an association.


      Association Source: 4 or 16 bytes


        The IP address of the node that originated the association.


16.2. Processing


   The ASSOCIATION object is used to associate different LSPs with each
   other. In the protection and restoration context, the object is used
   to associate a recovery LSP with the LSP it is protecting. The
   object is carried in Path messages. More than one object may be
   carried in a single Path message.


   Transit nodes MUST transmit, without modification, any received
   ASSOCIATION object in the corresponding outgoing Path message.


   An ASSOCIATION object with an Association Type set to the value
   Recovery is used to identify a LSP Recovery related association. Any
   node associating a recovery LSP MUST insert an ASSOCIATION object
   with a Recovery Association Type set in the Path message of the
   recovery LSP.  The Association Source MUST be set to the tunnel
   sender address of the LSP being protected. The Association ID MUST
   be set to the LSP ID of the LSP being protected by this LSP or the
   LSP protecting this LSP. If unknown, this value is set to 0
   (default). Also, the value of the Association ID MAY change during
   the lifetime of the LSP.


   Nodes merging recovery LSPs use received ASSOCIATION objects with
   the Recovery type to associate a recovery LSP with it's matching



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           28
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   working LSP. This information is used to bind the appropriate
   working and recovery LSPs together.


17. Updated RSVP Message Formats


   This section presents the RSVP message related formats as modified
   by this document. Unmodified RSVP message formats are not listed.


   The format of a Path message is as follows:


   <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                      [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                      [ <MESSAGE_ID> ]
                      <SESSION> <RSVP_HOP>
                      <TIME_VALUES>
                      [ <EXPLICIT_ROUTE> ]
                      <LABEL_REQUEST>
                      [ <PROTECTION> ]
                      [ <LABEL_SET> ... ]
                      [ <SESSION_ATTRIBUTE> ]
                      [ <NOTIFY_REQUEST> ... ]
                      [ <ADMIN_STATUS> ]
                      [ <ASSOCIATION> ... ]
                      [ <PRIMARY_PATH_ROUTE> ... ]
                      [ <POLICY_DATA> ... ]
                      <sender descriptor>


   The format of the <sender descriptor> for unidirectional and
   bidirectional LSPs is not modified by the present document


18. Security Considerations


   This document does not introduce or imply any specific security
   consideration.


19. IANA Considerations


   IANA assigns values to RSVP protocol parameters. Within the current
   document a PROTECTION object (new C-Type) and a PRIMARY PATH ROUTE
   object are defined.


   One RSVP Class Number (Class-Num) and two Class Types (C-Types)
   values have to be defined by IANA in registry:


   http://www.iana.org/assignments/rsvp-parameters


   - PROTECTION object: Class-Num = 37, C-Type = 2 (suggested)


   - PRIMARY PATH ROUTE object: Class-Num = TBA (of form 0bbbbbbb),
     C-Type = 1 (suggested)


   - ASSOCIATION object: Class-Num = TBA (of form 11bbbbbb),



J.P.Lang et al. - Internet Draft ¡ Expires September 2004           29
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



     C-Type = 1 (suggested)


   - Error values:


   o "Admission Control Failure/LSP Admission Failure"  (value = TBA)


   o "Routing Problem/Unsupported LSP Protection"       (value = TBA)
   o "Routing Problem/Bad PRIMARY PATH_ROUTE object"    (value = TBA)
   o "Routing Problem/PRIMARY PATH_ROUTE object not applicable"
                                                        (value = TBA)


   o "Notify Error/LSP Failure"                         (value = TBA)
   o "Notify Error/LSP Recovered"                       (value = TBA)


20. Acknowledgments


   The authors would like to thank John Drake for its active
   collaboration, Adrian Farrel for his contribution to this document
   (in particular, to the Section 11) and his thorough review of the
   document, Bart Rousseau (for editorial review) and Stefaan
   De_Cnodder.


   The authors would like also to thank Lou Berger for the time and
   effort he spent together with the design team, in contributing to
   the present document.


21. Intellectual Property Consideration


   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.


21.1 IPR Disclosure Acknowledgement




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           30
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been
   disclosed, and any of which I become aware will be disclosed, in
   accordance with RFC 3668.


22. References


22.1 Normative References


   [FRR]        P.Pan (Editor), "Fast Reroute Extensions to RSVP-TE for
                LSP Tunnels," Internet Draft, Work in progress, draft-
                ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003.


   [FUNCT]      J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS
                Recovery Functional Specification," Internet Draft,
                Work in Progress, draft-ietf-ccamp-gmpls-recovery-
                functional-01.txt, September 2003.


   [GMPLS-ARCH] E.Mannie (Editor), "Generalized Multi-Protocol Label
                Switching Architecture," Internet Draft, Work in
                progress, draft-ietf-ccamp-gmpls-architecture-07.txt,
                May 2003.


   [GMPLS-RTG]  K.Kompella (Editor), "Routing Extensions in Support of
                Generalized MPLS," Internet Draft, Work in Progress,
                draft-ietf-ccamp-gmpls-routing-09.txt, October 2003.


   [LMP]        J.Lang (Editor), "Link Management Protocol (LMP) v1.0,"
                Internet Draft, Work in progress, draft-ietf-ccamp-lmp-
                10, October 2003.


   [RFC-2026]   S.Bradner, "The Internet Standards Process -- Revision
                3," BCP 9, RFC 2026, October 1996.


   [RFC-2119]   S.Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels," BCP 14, RFC 2119, March 1997.


   [RFC-2961]   L.Berger et al., "RSVP Refresh Overhead Reduction
                Extensions," RFC 2961, April 2001.


   [RFC-3209]   D.Awduche et al., "RSVP-TE: Extensions to RSVP for
                LSP Tunnels," RFC 3209, December 2001.


   [RFC-3471]   L.Berger (Editor) et al., "Generalized Multi-Protocol
                Label Switching (GMPLS) ¡ Signaling Functional
                Description," RFC 3471, January 2003.


   [RFC-3473]   L.Berger (Editor) et al., "Generalized Multi-Protocol
                Label Switching (GMPLS) Signaling ¡ Resource
                Reservation Protocol - Traffic Engineering (RSVP-TE)
                Extensions," RFC 3473, January 2003.




J.P.Lang et al. - Internet Draft ¡ Expires September 2004           31
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



   [RFC-3477]   K.Kompella, and Y.Rekhter, "Signalling Unnumbered Links
                in Resource Reservation Protocol - Traffic Engineering
                (RSVP-TE)," RFC 3477, January 2003.


   [TERM]       E.Mannie and D.Papadimitriou (Editors), "Recovery
                (Protection and Restoration) Terminology for GMPLS,"
                Internet Draft, Work in progress, draft-ietf-ccamp-
                gmpls-recovery-terminology-03.txt, January 2004.


   [XRO]        C.Y.Lee et al. "Exclude Routes - Extension to RSVP-TE,"
                Internet Draft, Work in progress, draft-ietf-ccamp-
                rsvp-te-exclude-route-01.txt, November 2003.


23. Author's Addresses


   Jonathan Lang (Rincon Networks)
   E-mail: jplang@ieee.org


   Yakov Rekhter (Juniper)
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089, USA
   E-mail: yakov@juniper.net


   Dimitri Papadimitriou (Alcatel)
   Fr. Wellesplein, 1
   B-2018, Antwerpen, Belgium
   E-mail: dimitri.papadimitriou@alcatel.be




























J.P.Lang et al. - Internet Draft ¡ Expires September 2004           32
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00.txt        March 2004



24. Full Copyright Statement


   Copyright (C) The Internet Society (2004). 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.


   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.










































J.P.Lang et al. - Internet Draft ¡ Expires September 2004           33