Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4872

RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery

Pages: 47
Proposed Standard
Errata
Updates:  3471
Updated by:  487367809270
Part 1 of 2 – Pages 1 to 23
None   None   Next

Top   ToC   RFC4872 - Page 1
Network Working Group                                     J.P. Lang, Ed.
Request for Comments: 4872                                         Sonos
Updates: 3471                                            Y. Rekhter, Ed.
Category: Standards Track                                        Juniper
                                                   D. Papadimitriou, Ed.
                                                                 Alcatel
                                                                May 2007


              RSVP-TE Extensions in Support of End-to-End
      Generalized Multi-Protocol Label Switching (GMPLS) Recovery

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

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

Table of Contents

1. Introduction .....................................................3 2. Conventions Used in This Document ...............................5 3. Relationship to Fast Reroute (FRR) ..............................5 4. Definitions .....................................................6 4.1. LSP Identification .........................................6 4.2. Recovery Attributes ........................................7 4.2.1. LSP Status ..........................................7 4.2.2. LSP Recovery ........................................8 4.3. LSP Association ............................................9 5. 1+1 Unidirectional Protection ...................................9 5.1. Identifiers ...............................................10
Top   ToC   RFC4872 - Page 2
   6. 1+1 Bidirectional Protection ...................................10
      6.1. Identifiers ...............................................11
      6.2. End-to-End Switchover Request/Response ....................11
   7. 1:1 Protection with Extra-Traffic ..............................13
      7.1. Identifiers ...............................................14
      7.2. End-to-End Switchover Request/Response ....................15
      7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
   8. Rerouting without Extra-Traffic ................................17
      8.1. Identifiers ...............................................19
      8.2. Signaling Primary LSPs ....................................19
      8.3. Signaling Secondary LSPs ..................................19
   9. Shared-Mesh Restoration ........................................20
      9.1. Identifiers ...............................................22
      9.2. Signaling Primary LSPs ....................................22
      9.3. Signaling Secondary LSPs ..................................23
   10. LSP Preemption ................................................23
   11. (Full) LSP Rerouting ..........................................25
      11.1. Identifiers ..............................................25
      11.2. Signaling Reroutable LSPs ................................26
   12. Reversion .....................................................26
   13. Recovery Commands .............................................29
   14. PROTECTION Object .............................................31
      14.1. Format ...................................................31
      14.2. Processing ...............................................33
   15. PRIMARY_PATH_ROUTE Object .....................................33
      15.1. Format ...................................................34
      15.2. Subobjects ...............................................34
      15.3. Applicability ............................................35
      15.4. Processing ...............................................36
   16. ASSOCIATION Object ............................................37
      16.1. Format ...................................................37
      16.2. Processing ...............................................38
   17. Updated RSVP Message Formats ..................................39
   18. Security Considerations .......................................40
   19. IANA Considerations ...........................................41
   20. Acknowledgments ...............................................43
   21. References ....................................................43
      21.1. Normative References .....................................43
      21.2. Informative References ...................................44
   22. Contributors ..................................................45
Top   ToC   RFC4872 - Page 3

1. Introduction

Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to include support for Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) interfaces. GMPLS recovery uses control plane mechanisms (i.e., signaling, routing, and 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 [RFC4427]). A functional description of GMPLS recovery is provided in [RFC4426] and should be considered as a companion document. The present document describes the protocol-specific procedures for GMPLS RSVP- TE (Resource ReSerVation Protocol - Traffic Engineering) signaling (see [RFC3473]) to support end-to-end recovery. End-to-end recovery refers to the recovery of an entire LSP from its head-end (ingress node endpoint) to its tail-end (egress node endpoint). With end-to- end recovery, working LSPs are assumed to be resource-disjoint (where a resource is a link, node, or Shared Risk Link Group (SRLG)) in the network so that they do not share any failure probability, but this is not mandatory. With respect to a given set of network resources, a pair of working/protecting LSPs SHOULD be resource disjoint in case of dedicated recovery type (see below). On the other hand, in case of shared recovery (see below), a group of working LSPs SHOULD be mutually resource-disjoint in order to allow for a (single and commonly) shared protecting LSP, itself resource-disjoint from each of the working LSPs. Note that resource disjointness is a necessary (but not sufficient) condition to ensure LSP recoverability. The present document addresses four types of end-to-end LSP recovery: 1) 1+1 (unidirectional/bidirectional) protection, 2) 1:N (N >= 1) LSP protection with extra-traffic, 3) pre-planned LSP rerouting without extra-traffic (including shared mesh), and 4) full LSP rerouting. 1) 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
Top   ToC   RFC4872 - Page 4
      traffic from the valid LSP.  No coordination is required between
      the end nodes when a failure/switchover occurs.

      In 1+1 bidirectional 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 coordination between the end-nodes when switching to the
      protecting LSP.

   2) 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 LSPs to the protecting LSP.  As the protecting LSP is
      fully provisioned, default operations during protection switching
      are specified for a protecting LSP carrying extra-traffic, but
      this is not mandatory.  Note that M:N protection is out of scope
      of this document (though mechanisms it defines may be extended to
      cover it).

   3) Pre-planned LSP rerouting (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 but 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 cannot carry any extra-traffic.  This does not
      mean that the corresponding resources cannot be 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 rerouting that
      reduces the recovery resource requirements by allowing multiple
      protecting LSPs to share common link and node resources.  The
      recovery resources are pre-reserved but 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.
Top   ToC   RFC4872 - Page 5
      Note that in both cases, bandwidth pre-reserved for a protecting
      (but not activated) LSP can be made available for carrying extra
      traffic.  LSPs for extra-traffic (with lower holding priority than
      the protecting LSP) can then be established using the bandwidth
      pre-reserved for the protecting LSP.  Also, any lower priority LSP
      that use the pre-reserved resources for the protecting LSP(s) must
      be preempted during the activation of the protecting LSP.

   4) Full LSP rerouting (or restoration) switches normal traffic to an
      alternate LSP that is not even partially established until after
      the 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.

   Crankback signaling (see [CRANK]) and LSP segment recovery (see
   [RFC4873]) are further detailed in dedicated companion documents.

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 [RFC3945], [RFC3471], [RFC3473] and referenced as well as in [RFC4427] and [RFC4426].

3. Relationship to Fast Reroute (FRR)

There is no impact to RSVP-TE Fast Reroute (FRR) [RFC4090] introduced by end-to-end GMPLS recovery i.e., it is possible to use either method defined in FRR with end-to-end GMPLS recovery. The objects used and/or newly introduced by end-to-end recovery will be ignored by [RFC4090] conformant implementations, and FRR can operate on a per LSP basis as defined in [RFC4090].
Top   ToC   RFC4872 - Page 6

4. Definitions

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 [RFC3209]). The relevant fields are as follows: IPv4 (or IPv6) tunnel endpoint address 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 LSPs that belong to the same LSP Tunnel (as identified by its Tunnel ID).
Top   ToC   RFC4872 - Page 7

4.2. Recovery Attributes

The recovery attributes include all the parameters that determine the status of an 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 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 (thus requiring 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 [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this document.
Top   ToC   RFC4872 - Page 8

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 Rerouting: set if a primary working LSP is dynamically recoverable using (non pre-planned) head-end rerouting. - Pre-planned LSP Rerouting 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. - 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 bidirectional 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 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 rerouting 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 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
Top   ToC   RFC4872 - Page 9
   signaling (see Section 12) but also facilitates the transparent
   delivery of protected services since any intermediate node is not
   required to know the semantics 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 signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, 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 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). During the provisioning phase, 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. 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 endpoints. Also, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation. Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.
Top   ToC   RFC4872 - Page 10

5.1. Identifiers

To simplify association operations, both LSPs belong to the same session. Thus, 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 (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 Unidirectional". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs. To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID. After protection switching completes, 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 [RFC3473]). This process assumes the tail- end node has notified the head-end node that traffic selection switchover has occurred.

6. 1+1 Bidirectional Protection

1+1 bidirectional protection is a scheme that provides end-to-end protection for bidirectional LSPs. 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 bidirectional LSP is established from A to D over each path, and traffic is transmitted simultaneously over both LSPs. In this scheme, both endpoints must receive traffic over the same LSP. 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).
Top   ToC   RFC4872 - Page 11
   When a failure is detected by one or both endpoints of the LSP, both
   endpoints must select traffic from the other LSP.  This action must
   be coordinated between node A and D.  From this perspective, 1+1
   bidirectional protection can be seen as a coordinated protection-
   switching mechanism between both endpoints.

   Note: it is necessary that both paths are SRLG disjoint to ensure
   recoverability; otherwise, a single failure may impact both working
   and protecting LSPs.

6.1. Identifiers

To simplify association operations, both LSPs belong to the same session. Thus, 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 (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 Bidirectional". This LSP Protection Type value is only applicable to bidirectional 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 in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object the Association ID to the associated protected LSP_ID.

6.2. End-to-End Switchover Request/Response

To coordinate the switchover between endpoints, an end-to-end switchover request/response exchange is needed since a failure affecting one of the LSPs results in both endpoints switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions. 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 [RFC3473]), and the new error code/sub-code "Notify Error/ LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it MUST begin receiving on the protecting LSP. Note that the <sender descriptor> or <flow
Top   ToC   RFC4872 - Page 12
         descriptor> is also present in the Notify message that resolves
         any ambiguity and race condition since identifying (together
         with the SESSION object) the LSP under failure condition.

            Note: (IF_ID)_ERROR_SPEC indicates that either the
            ERROR_SPEC (C-Type 1/2) or the ERROR_SPEC (C-Type 3/4,
            defined in [RFC3473]) can be used.

         This node MUST reliably send a Notify message, including the
         MESSAGE_ID object, to the other end-node (D or A, respectively)
         with the new error code/sub-code "Notify Error/LSP Failure"
         (Switchover Request) indicating the failure of the working LSP.
         This Notify message MUST be sent with the ACK_Desired flag set
         in the MESSAGE_ID object to request the receiver to send an
         acknowledgment for the message (see [RFC2961]).

         This (switchover request) Notify message MAY indicate the
         identity of the failed link or any other relevant information
         using the IF_ID ERROR_SPEC object (see [RFC3473]).  In this
         case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC
         object in the Notify message; otherwise, the corresponding
         (data plane) information SHOULD be received in the
         PathErr/ResvErr message.

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

         This node MUST reliably send a Notify message, including the
         MESSAGE_ID object, to the other end-node (A or D,
         respectively).  This (switchover response) Notify message MUST
         also include a MESSAGE_ID_ACK object to acknowledge reception
         of the (switchover request) Notify message.

         This (switchover response) Notify message MAY indicate the
         identity of the failed link or any other relevant information
         using the IF_ID ERROR_SPEC object (see [RFC3473]).

         Note: upon receipt of the (switchover response) Notify message,
         the end-node (A or D, respectively) MUST send an Ack message to
         the other end-node to acknowledge its reception.

   Since the intermediate nodes (B, C, E, F, and G) are assumed to be
   GMPLS RSVP-TE 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
Top   ToC   RFC4872 - Page 13
   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 LSP
   under failure condition, it is RECOMMENDED to not set the Path_State_
   Removed Flag of the ERROR_SPEC object (see [RFC3473]) 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 [RFC3473]).

   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).

7. 1:1 Protection with Extra-Traffic

The most common case of end-to-end 1:N protection is to establish, between the same endpoints, 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 switchover when the working LSP fails. GMPLS RSVP-TE 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. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails. 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 Path message traverses) SHOULD send a Notify message to the LSP head-end node, and the node downstream to the failure SHOULD send an 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
Top   ToC   RFC4872 - Page 14
   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: it is necessary that both paths are SRLG disjoint to ensure
   recoverability; otherwise, a single failure may impact both working
   and protecting LSPs.

7.1. Identifiers

To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for 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 set up 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 bidirectional LSPs. The working LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.
Top   ToC   RFC4872 - Page 15

7.2. End-to-End Switchover Request/Response

To coordinate the switchover between endpoints, an end-to-end switchover request/response is needed such that the affected LSP is 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). 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 [RFC3473]), and the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it disconnects the extra-traffic from the protecting LSP. Note that the <sender descriptor> or <flow descriptor> is also present in the Notify message that resolves any ambiguity and race condition since identifying (together with the SESSION object) the LSP under failure condition. This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) indicating the failure of the working LSP. This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object to request the receiver to send an acknowledgment for the message (see [RFC2961]). This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]). In this case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message; otherwise, the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message. 2. Upon receipt of the (switchover request) Notify message, the end-node (D or A, respectively) MUST disconnect the extra- traffic from the protecting LSP and begin sending/receiving normal traffic out/from the protecting LSP. This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST
Top   ToC   RFC4872 - Page 16
         also include a MESSAGE_ID_ACK object to acknowledge reception
         of the (switchover request) Notify message.

         This (switchover response) Notify message MAY indicate the
         identity of the failed link or any other relevant information
         using the IF_ID ERROR_SPEC object (see [RFC3473]).

         Note: since the Notify message generated by the other end-node
         (A or D, respectively) 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 a Notify message from an intermediate node.

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

         This node MUST also send an Ack message to the other end-node
         (D or A, respectively) to acknowledge the reception of the
         (switchover response) Notify message.

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

   Note 2: when the N bit is set, the above end-to-end switchover
   request/response exchange only provides 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 [RFC3473]).

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 from the N working LSPs. This protecting LSP thereby allows for carrying extra-traffic. Note that the N working LSPs and the protecting LSP are all between the same pair of endpoints. In addition, the N working LSPs (considered as identical in terms of traffic parameters) MAY be
Top   ToC   RFC4872 - Page 17
   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 Protection Type is set to 0x04 (1:N Protection with Extra-
   Traffic) during LSP setup.  Each Association ID points to the
   protecting LSP ID.

   The protecting LSP (carrying extra-traffic) is signaled with the S
   bit set to 0 and the P bit set to 1.  The LSP Protection Type is set
   to 0x04 (1:N Protection with Extra-Traffic) during LSP setup.  The
   Association ID 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.

8. Rerouting without Extra-Traffic

End-to-end (pre-planned) rerouting 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 LSP. However, in this case the protecting LSP is not fully instantiated; thus, it cannot carry any extra-traffic (note that this does not mean that the corresponding resources cannot be used by other LSPs). Therefore, this mechanism protects against working LSP failure(s) but requires activation of the protecting LSP after failure occurrence. Signaling 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 [RFC3473]) 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 LSPs are established between the same end-nodes, no further notification is required to indicate that the working LSPs are without protection.
Top   ToC   RFC4872 - Page 18
   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 Holding 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 to at least 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
   (see Section 10).

   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].  Only the protected LSP is fully instantiated (resources
   are only allocated for the working LSP).  Therefore, the protecting
   LSP cannot carry any extra-traffic.  When a failure is detected on
   the working LSP (say, at B), the error is propagated and/or notified
   (using a Notify message with the new error code/sub-code "Notify
   Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the
   ingress node (A).  Upon reception, the latter 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.
Top   ToC   RFC4872 - Page 19

8.1. Identifiers

To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra- traffic. A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type (in this case, "Rerouting without Extra-Traffic"). This LSP Protection Type value is applicable to both uni- and bidirectional 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 "Rerouting without Extra-Traffic". Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.

8.3. Signaling Secondary LSPs

The new PROTECTION object is included in the Path message during signaling of secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic". Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. With this setting, the resources for the secondary 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).
Top   ToC   RFC4872 - Page 20
   From [RFC3945], the secondary LSP is set up 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), label allocation during secondary LSP signaling does
   not require any specific procedure compared to [RFC3473].  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 reassigned (with higher precedence
   over existing label assignment; see also [RFC3471]).

   Note: under certain circumstances (e.g., when pre-reserved protecting
   resources are used by lower-priority LSPs), 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
   activation.  In this case, any mis-ordering and any mis-
   interpretation between a refresh Resv (along the lower-priority LSP)
   and a trigger Resv message (along the secondary LSP) MUST be avoided
   at any intermediate node.  For this purpose, 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.  In this case, the PROTECTION object with
   the S bit MUST be set to 0 and included in the Resv message sent in
   the upstream direction.  The upstream activation behavior SHOULD be
   configurable on a local basis.  Details concerning lower-priority LSP
   preemption upon secondary LSP activation are provided in Section 10.

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 [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-planned LSP rerouting (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. 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
Top   ToC   RFC4872 - Page 21
   numerically higher) than the Holding 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 to at least 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
   (see Section 10).  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.  Per [RFC3209], in order
   to achieve resource sharing during the signaling of these protecting
   LSPs, they must have the same Tunnel Endpoint Address (as part of
   their SESSION object).  However, these addresses are not the same in
   this example.  Resource sharing along E, F, and G can only be
   achieved if the nodes E, F, and G recognize that the LSP Protection
   Type of the secondary LSP is set to "Rerouting without Extra-Traffic"
   (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 along E, F, G can be shared.

   When a failure is detected on one of the working LSPs (say, at B),
   the error is propagated and/or notified (using a Notify message with
   the new error code/sub-code "Notify Error/LSP Locally Failed" in the
   (IF_ID)_ERROR_SPEC object) to the ingress node (A).  Upon reception,
   the latter activates the secondary 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
Top   ToC   RFC4872 - Page 22
   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 resources for the protecting LSP [H,E,F,G,K] are no longer
   available.

   The following subsections detail how shared mesh restoration can be
   implemented in an interoperable fashion using GMPLS RSVP-TE
   extensions (see [RFC3473]).  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

To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra- traffic. A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "Rerouting without Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.

9.2. Signaling Primary LSPs

The new PROTECTION object is included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic". Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.
Top   ToC   RFC4872 - Page 23

9.3. Signaling Secondary LSPs

The new PROTECTION object is included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic". Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP SHOULD 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 secondary 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). From [RFC3945], the secondary LSP is set up 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), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. 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 reassigned (with higher precedence over existing label assignment; see also [RFC3471]).


(page 23 continued on part 2)

Next Section