tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4872

 
 
 

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

Part 2 of 2, p. 23 to 47
Prev RFC Part

 


prevText      Top      Up      ToC       Page 23 
10.  LSP Preemption

   When protecting resources are only pre-reserved for the secondary
   LSPs, they MAY be used to set up lower-priority LSPs.  In this case,
   these resources MUST be preempted when the protecting LSP is
   activated.  An additional condition raises from misconnection
   avoidance between the secondary protecting LSP being activated and
   the low-priority LSP(s) being preempted.  Procedure to be applied
   when the secondary protecting LSP (i.e., the preempting LSP) Path
   message reaches a node using the resources for lower-priority LSP(s)
   (i.e., preempted LSP(s)) is as follows:

Top      Up      ToC       Page 24 
   1. De-allocate resources to be used by the preempting LSP and release
      the cross-connection.  Note that if the preempting LSP is
      bidirectional, these resources may come from one or two lower-
      priority LSPs, and if from two LSPs, they may be uni- or bi-
      directional.  The preempting node SHOULD NOT send the Path message
      before the de-allocation of resources has completed since this may
      lead to the downstream path becoming misconnected if the
      downstream node is able to reassign the resources more quickly.

   2. Send PathTear and PathErr messages with the new error code/sub-
      code "Policy Control failure/Hard preempted" and the
      Path_State_Removed flag set for the preempted LSP(s).

   3. Reserve the preempted resources for the protecting LSP.  The
      preempting node MUST NOT cross-connect the upstream resources of a
      bidirectional preempting LSP.

   4. Send the Path message.

   5. Upon reception of a trigger Resv message from the downstream node,
      cross-connect the downstream path resources, and if the preempting
      LSP is bidirectional, perform cross-connection for the upstream
      path resources.

   Note that step 1 may cause alarms to be raised for the preempted LSP.
   If alarm suppression is desired, the preempting node MAY insert the
   following steps before step 1.

   1a. Before de-allocating resources, send a Resv message, including an
       ADMIN_STATUS object, to disable alarms for the preempted LSP.
   1b. Receive a Path message indicating that alarms are disabled.

   At the downstream node (with respect to the preempting LSP), the
   processing is RECOMMENDED to be as follows:

   1.  Receive PathTear (and/or PathErr) message for the preempted
       LSP(s).

   2a. Release the resources associated with the LSP on the interface to
       the preempting LSP, remove any cross-connection, and release all
       other resources associated with the preempted LSP.
   2b. Forward the PathTear (and/or PathErr) message per [RFC3473].

   3.  Receive the Path message for the preempting LSP and process as
       normal, forwarding it to the downstream node.

   4.  Receive the Resv message for the preempting LSP and process as
       normal, forwarding it to the upstream node.

Top      Up      ToC       Page 25 
11.  (Full) LSP Rerouting

   LSP rerouting, 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 failed 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 (see [CRANK]) and route exclusion techniques (see
   [RFC4874]) 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 rerouting) 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 rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  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 reused by the new alternate LSP.

11.1.  Identifiers

   The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and
   Tunnel Sender Address uniquely identify both the old and new LSPs.
   Only the LSP_ID value differentiates the old from the new alternate
   LSP.  The new alternate LSP is set up before the old LSP is torn down
   using Shared-Explicit (SE) reservation style.  This ensures that the
   new (alternate) LSP is established without double-counting resource
   requirements along common segments.

Top      Up      ToC       Page 26 
   The alternate LSP MAY be set up 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).

   In both cases, the Association ID of the ASSOCIATION object MUST be
   set to the LSP ID value of the signaled LSP.

11.2.  Signaling Reroutable LSPs

   A new PROTECTION object is included in the Path message during
   signaling of dynamically reroutable LSPs, with the end-to-end LSP
   Protection Type value set to "Full Rerouting".  These LSPs that can
   be either uni- or bidirectional are signaled by setting in the
   PROTECTION object the S bit to 0, the P bit to 0, and the Association
   ID value to the LSP_ID value of the signaled LSP.  Any specific
   action to be taken during the provisioning phase is up to 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 SHOULD
   NOT be rerouted at the head-end node after failure occurrence.  The
   Association_ID value MUST be set to the LSP_ID value of the signaled
   LSP.  This does not mean that the Unprotected LSP cannot be re-
   established for other reasons such as path re-optimization and
   bandwidth adjustment driven by policy conditions.

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 them even after
   a failure.  It is important to have mechanisms that allow reversion
   to be performed with minimal service disruption and reconfiguration.

   For "1+1 bidirectional Protection", reversion to the recovered LSP
   occurs by using the following sequence:

   1. Clear the A bit of the ADMIN_STATUS object if set for the
      recovered LSP.

   2. Then, apply the method described below to switch normal traffic
      back from the protecting to the recovered LSP.  This is performed
      by using the new error code/sub-code "Notify Error/LSP Recovered"
      (Switchback Request).

Top      Up      ToC       Page 27 
      The procedure is as follows:

      1) The initiating (source) node sends the normal traffic onto both
         the working and the protecting LSPs.  Once completed, the
         source node sends reliably a Notify message to the destination
         with the new error code/sub-code "Notify Error/LSP Recovered"
         (Switchback Request).  This Notify message includes the
         MESSAGE_ID object.  The ACK_Desired flag MUST be set in this
         object to request the receiver to send an acknowledgment for
         the message (see [RFC2961]).

      2) Upon receipt of this message, the destination selects the
         traffic from the working LSP.  At the same time, it transmits
         the traffic onto both the working and protecting LSP.

         The destination then sends reliably a Notify message to the
         source confirming the completion of the operation.  This
         message includes the MESSAGE_ID_ACK object to acknowledge
         reception of the received Notify message.  This Notify message
         also includes the MESSAGE_ID object.  The ACK_Desired flag MUST
         be set in this object to request the receiver to send an
         acknowledgment for the message (see [RFC2961]).

      3) When the source node receives this Notify message, it switches
         to receive traffic from the working LSP.

         The source node then sends an Ack message to the destination
         node confirming that the LSP has been reverted.

   3. Finally, clear the O bit of the PROTECTION object sent over the
      protecting LSP.

   For "1:N Protection with Extra-traffic", reversion to the recovered
   LSP occurs by using the following sequence:

   1. Clear the A bit of the ADMIN_STATUS object if set for the
      recovered LSP.

   2. Then, apply the method described below to switch normal traffic
      back from the protecting to the recovered LSP.  This is performed
      by using the new error code/sub-code "Notify Error/LSP Recovered"
      (Switchback Request).

      The procedure is as follows:

      1) The initiating (source) node sends the normal traffic onto both
         the working and the protecting LSPs.  Once completed, the
         source node sends reliably a Notify message to the destination

Top      Up      ToC       Page 28 
         with the new error code/sub-code "Notify Error/LSP Recovered"
         (Switchback Request).  This Notify message includes the
         MESSAGE_ID object.  The ACK_Desired flag MUST be set in this
         object to request the receiver to send an acknowledgment for
         the message (see [RFC2961]).

      2) Upon receipt of this message, the destination selects the
         traffic from the working LSP.  At the same time, it transmits
         the traffic onto both the working and protecting LSP.

         The destination then sends reliably a Notify message to the
         source confirming the completion of the operation.  This
         message includes the MESSAGE_ID_ACK object to acknowledge
         reception of the received Notify message.  This Notify message
         also includes the MESSAGE_ID object.  The ACK_Desired flag MUST
         be set in this object to request the receiver to send an
         acknowledgment for the message (see [RFC2961]).

      3) When the source node receives this Notify message, it switches
         to receive traffic from the working LSP, and stops transmitting
         traffic on the protecting LSP.

         The source node then sends an Ack message to the destination
         node confirming that the LSP has been reverted.

      4) Upon receipt of this message, the destination node stops
         transmitting traffic along the protecting LSP.

   3. Finally, clear the O bit of the PROTECTION object sent over the
      protecting LSP.

   For "Rerouting without Extra-traffic" (including the shared recovery
   case), reversion 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 exact same resources are retrieved
   after reversion switching (except if the working LSP required re-
   signaling).  Re-activation is performed using the following sequence:

   1. Clear the A bit of the ADMIN_STATUS object if set for the
      recovered LSP.

   2. Then, apply the method described below to switch normal traffic
      back from the protecting to the recovered LSP.  This is performed
      by using the new error code/sub-code "Notify Error/LSP Recovered"
      (Switchback Request).

Top      Up      ToC       Page 29 
      The procedure is as follows:

      1) The initiating (source) node sends the normal traffic onto both
         the working and the protecting LSPs.  Once completed, the
         source node sends reliably a Notify message to the destination
         with the new error code/sub-code "Notify Error/LSP Recovered"
         (Switchback Request).  This Notify message includes the
         MESSAGE_ID object.  The ACK_Desired flag MUST be set in this
         object to request the receiver to send an acknowledgment for
         the message (see [RFC2961]).

      2) Upon receipt of this message, the destination selects the
         traffic from the working LSP.  At the same time, it transmits
         the traffic onto both the working and protecting LSP.

         The destination then sends reliably a Notify message to the
         source confirming the completion of the operation.  This
         message includes the MESSAGE_ID_ACK object to acknowledge
         reception of the received Notify message.  This Notify message
         also includes the MESSAGE_ID object.  The ACK_Desired flag MUST
         be set in this object to request the receiver to send an
         acknowledgment for the message (see [RFC2961]).

      3) When the source node receives this Notify message, it switches
         to receive traffic from the working LSP, and stops transmitting
         traffic on the protecting LSP.

         The source node then sends an Ack message to the destination
         node confirming that the LSP has been reverted.

      4) Upon receipt of this message, the destination node stops
         transmitting traffic along the protecting LSP.

   3. Finally, de-activate the protecting LSP by setting the S bit to 1
      in the PROTECTION object sent over the protecting LSP.

13.  Recovery Commands

   This section specifies the control plane behavior when using several
   commands (see [RFC4427]) that can be used to influence the recovery
   operations.

   A. Lockout of recovery LSP:

   The Lockout (L) bit of the ADMIN_STATUS object is used following the
   rules defined in Section 8 of [RFC3471] and Section 7 of [RFC3473].
   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

Top      Up      ToC       Page 30 
   Resv message with the L bit set, this forces the recovery LSP to be
   temporarily unavailable to transport traffic (either normal or
   extra-traffic).  Unlock is performed by clearing the L bit, following
   the rules defined in Section 7 of [RFC3473].  This procedure is only
   applicable when the LSP Protection Type Flag is set to either 0x04
   (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional
   Protection), or 0x10 (1+1 Bidirectional Protection).

   The updated format of the ADMIN_STATUS object to include the L bit 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(196)|   C-Type (1)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                        Reserved                 |L|I|C|T|A|D|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Lockout (L): 1 bit

        When set, forces the recovery LSP to be temporarily unavailable
        to transport traffic (either normal or extra traffic).

   The R (Reflect), T (Testing), A (Administratively down), and D
   (Deletion in progress) bits are defined in [RFC3471].  The C (Call
   control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm
   communication) bit in [RFC4783].

   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 NOT occur unless the working LSP is carrying the
   normal traffic.  Unlock is performed by clearing the O bit over the
   protecting LSP.  This procedure is only applicable when the LSP
   Protection Type Flag is set to either 0x04 (1:N Protection with
   Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1
   Bidirectional Protection).

   C. Forced switch for normal traffic:

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

Top      Up      ToC       Page 31 
   D. Requested switch for normal traffic:

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

   E. Requested switch for recovery LSP:

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

14.  PROTECTION Object

   This section describes the extensions to the PROTECTION object to
   broaden its applicability to end-to-end LSP recovery.

14.1.  Format

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

      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.

Top      Up      ToC       Page 32 
      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 Protection Type Flag is set to either 0x04 (1:N
         Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional
         Protection), or 0x10 (1+1 Bidirectional Protection).  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
         Protection Type Flag is set to either 0x04 (1:N Protection with
         Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10
         (1+1 Bidirectional Protection).  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) Rerouting
                0x02    Rerouting without Extra-Traffic
                0x04    1:N Protection with Extra-Traffic
                0x08    1+1 Unidirectional Protection
                0x10    1+1 Bidirectional Protection

      Reserved: 10 bits

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

Top      Up      ToC       Page 33 
      Link Flags: 6 bits

         Indicates the desired link protection type (see [RFC3471]).

      Reserved field: 32 bits

         Encoding of this field is detailed in [RFC4873].

14.2.  Processing

   Intermediate and egress nodes processing a Path message containing a
   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 new error code/sub-code
   "Routing problem/Unsupported LSP Protection".

   Intermediate nodes processing a Path message containing a PROTECTION
   object with the LSP Protection Type 0x02 (Rerouting without Extra-
   Traffic) value set and a PRIMARY_PATH_ROUTE object (see Section 15)
   MUST verify that the requested LSP Protection Type can be supported
   by the outgoing interface.  If it cannot, the node MUST generate a
   PathErr message with the new error code/sub-code "Routing
   problem/Unsupported LSP Protection".

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).  If the LSP Protection
   Type value is set to 0x02 (Rerouting without Extra-Traffic), this
   object SHOULD be present in the Path message for the pre-provisioning
   of the secondary protecting LSP to enable recovery resource sharing
   between one or more secondary protecting LSPs (see Section 9).  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 node that initiates the request.
   Therefore, the information included in these objects can 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.

Top      Up      ToC       Page 34 
15.1.  Format

   The primary path route is specified via the PRIMARY_PATH_ROUTE object
   (PPRO).  The Primary Path Route Class Number (Class-Num) of form
   0bbbbbbb 38.

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

   Class-Num = 38 (of the form 0bbbbbbb), C-Type = 1

      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 (see Section 15.3).

   To signal a secondary protecting LSP, the Path message MAY include
   one or 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.  Subobjects

   The PRIMARY_PATH_ROUTE object is defined as a list of variable-length
   data items called subobjects.  These subobjects are derived from the
   subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the
   primary working LSP(s).

   Each 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 [RFC3209])
   - Sub-Type 2: IPv6 Address (see [RFC3209])
   - Sub-Type 3: Label (see [RFC3473])
   - Sub-Type 4: Unnumbered Interface (see [RFC3477])

Top      Up      ToC       Page 35 
   An empty PPRO with no subobjects is considered illegal.  If there is
   no first subobject, the corresponding Path message is also in error,
   and the receiving node SHOULD return a PathErr message with the new
   error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

   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.3.  Applicability

   The PRIMARY_PATH_ROUTE object MAY 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 (see [RFC2205]).

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

   - PPROs MAY only be included in Path messages when signaling
     secondary protecting LSPs (S bit = 1 and P bit = 1) and when the
     LSP Protection Type value is set to 0x02 (without Rerouting Extra-
     Traffic) in the PROTECTION object (see Section 14).

   - PRROs SHOULD be present in the Path message for the pre-
     provisioning of the secondary protecting LSP to enable recovery
     resource sharing between one or more secondary protecting LSPs (see
     Section 15.4).

   - PPROs MUST NOT be used in any other conditions.  In particular, if
     a PPRO is received when the S bit is set to 0 in the PROTECTION
     object, the receiving node MUST return a PathErr message with the
     new error code/sub-code "Routing Problem/PRIMARY_PATH_ROUTE object
     not applicable".

   - Crossed exchanges of PPROs over primary LSPs are forbidden (i.e.,
     their usage is restricted to a single set of protected LSPs).

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

Top      Up      ToC       Page 36 
15.4.  Processing

   The PPRO enables 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
   that protect 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 message 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 new error code/sub-code "Admission Control
     Failure/LSP Admission Failure".

   - 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 happens after verifying
     (from the node's 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 if
     upon local policy decision, no other link is allowed to be
     allocated for Q, N SHOULD return a PathErr message with the error
     code/sub-code "Admission Control Failure/Requested Bandwidth
     Unavailable" (see [RFC2205]).  Otherwise (if no other link is
     available), N SHOULD return a PathErr message with the new error
     code/sub-code "Admission Control Failure/LSP Admission Failure".

   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.

Top      Up      ToC       Page 37 
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 as well as the same
   tunnel sender address and tunnel endpoint address.  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 (Class-Num of the form 11bbbbbb with
   value = 199, C-Type = 1) 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(199)|  C-Type (1)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  IPv4 Association Source                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with
   value = 199, C-Type = 2) 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(199)|  C-Type (2)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                  IPv6 Association Source                      |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 38 
      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 assigned by the LSP head-end.  When combined with the
         Association Type and Association Source, this value uniquely
         identifies an association.

      Association Source: 4 or 16 bytes

         An IPv4 or IPv6 address, respectively, that is associated to
         the node that originated the association.

16.2.  Processing

   In the end-to-end LSP recovery context, the ASSOCIATION object is
   used to associate a recovery LSP with the LSP(s) it is protecting or
   a protected LSP(s) with its recovery LSP.  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 an LSP-Recovery-related association.
   Any node associating a recovery LSP MUST insert an ASSOCIATION object
   with the following setting:

   - The Association Type MUST be set to the value "Recovery" in the
     Path message of the recovery LSP.

   - The (IPv4/IPv6) Association Source MUST be set to the tunnel sender
     address of the LSP being protected.

Top      Up      ToC       Page 39 
   - 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 its own signaled LSP_ID value (default).
     Also, the value of the Association ID MAY change during the
     lifetime of the LSP.

   Terminating nodes use received ASSOCIATION object(s) with the
   Association Type set to the value "Recovery" to associate a recovery
   LSP with its matching working LSP.  This information is used to bind
   the appropriate working and recovery LSPs together.  Such nodes MUST
   ensure that the received Path messages, including ASSOCIATION
   object(s), are processed with the appropriate PROTECTION object
   settings, if present (see Section 14 for PROTECTION object
   processing).  Otherwise, this node MUST return a PathErr message with
   the new error code/sub-code "LSP Admission Failure/Bad Association
   Type".  Similarly, terminating nodes receiving a Path message with a

   PROTECTION object requiring association between working and recovery
   LSPs MUST include an ASSOCIATION object.  Otherwise, such nodes MUST
   return a PathErr message with the new error code/sub-code "Routing
   Problem/PROTECTION object not Applicable".

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.

Top      Up      ToC       Page 40 
   The format of a Resv message is as follows:

   <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                      [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                      [ <MESSAGE_ID> ]
                      <SESSION> <RSVP_HOP>
                      <TIME_VALUES>
                      [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                      [ <PROTECTION> ]
                      [ <NOTIFY_REQUEST> ]
                      [ <ADMIN_STATUS> ]
                      [ <POLICY_DATA> ... ]
                      <STYLE> <flow descriptor list>

      <flow descriptor list> is not modified by this document.

18.  Security Considerations

   The security threats identified in [RFC4426] may be experienced due
   to the exchange of RSVP messages and information as detailed in this
   document.  The following security mechanisms apply.

   RSVP signaling MUST be able to provide authentication and integrity.
   Authentication is required to ensure that the signaling messages are
   originating from the right place and have not been modified in
   transit.

   For this purpose, [RFC2747] provides the required RSVP message
   authentication and integrity for hop-by-hop RSVP message exchanges.
   For non hop-by-hop RSVP message exchanges the standard IPsec-based
   integrity and authentication can be used as explained in [RFC3473].

   Moreover, this document makes use of the Notify message exchange.
   This precludes RSVP's hop-by-hop integrity and authentication model.
   In the case, when the same level of security provided by [RFC2747] is
   desired, the standard IPsec based integrity and authentication can be
   used as explained in [RFC3473].

   To prevent the consequences of poorly applied protection and the
   increased risk of misconnection, in particular, when extra-traffic is
   involved, that would deliver the wrong traffic to the wrong
   destination, specific mechanisms have been put in place as described
   in Section 7.2, 8.3, and 10.

Top      Up      ToC       Page 41 
19.  IANA Considerations

   IANA assigns values to RSVP protocol parameters.  Within the current
   document, a PROTECTION object (new C-Type), a PRIMARY_PATH_ROUTE
   object, and an ASSOCIATION object are defined.  In addition, new
   Error code/sub-code values are defined in this document.  Finally,
   registration of the ADMIN_STATUS object bits is requested.

   Two RSVP Class Numbers (Class-Num) and three Class Types (C-Types)
   values have to be defined by IANA in registry:

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

   1) PROTECTION object (defined in Section 14.1)

   o PROTECTION object: Class-Num = 37

   - Type 2: C-Type = 2

   2) PRIMARY_PATH_ROUTE object (defined in Section 15.1)

   o PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),

   - Primary Path Route: C-Type = 1

   3) ASSOCIATION object (defined in Section 16.1)

   o ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)

   - IPv4 Association: C-Type = 1
   - IPv6 Association: C-Type = 2

   o Association Type

   The following values defined for the Association Type (16 bits) field
   of the ASSOCIATION object.

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

   Assignment of values (from 2 to 65535) by IANA are subject to IETF
   expert review process, i.e., IETF Standards Track RFC Action.

Top      Up      ToC       Page 42 
   4) Error Code/Sub-code values

   The following Error code/sub-code values are defined in this
   document:

   Error Code = 01: "Admission Control Failure" (see [RFC2205])

   o "Admission Control Failure/LSP Admission Failure" (4)
   o "Admission Control Failure/Bad Association Type" (5)

   Error Code = 02: "Policy Control Failure" (see [RFC2205])

   o "Policy Control failure/Hard Pre-empted" (20)

   Error Code = 24: "Routing Problem" (see [RFC3209])

   o "Routing Problem/Unsupported LSP Protection" (17)
   o "Routing Problem/PROTECTION object not applicable" (18)
   o "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19)
   o "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)

   Error Code = 25: "Notify Error" (see [RFC3209])

   o "Notify Error/LSP Failure"               (9)
   o "Notify Error/LSP Recovered"             (10)
   o "Notify Error/LSP Locally Failed"        (11)

   5) Registration of the ADMIN_STATUS object bits

   The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in
   [RFC3473].

   IANA is also requested to track the ADMIN_STATUS bits extended by
   this document.  For this purpose, the following new registry entries
   have been created:

   http://www.iana.org/assignments/gmpls-sig-parameters

   - ADMIN_STATUS bits:

        Name: ADMIN_STATUS bits
        Format: 32-bit vector of bits
        Position:
           [0]          Reflect (R) bit defined in [RFC3471]
           [1..25]      To be assigned by IANA via IETF Standards
                        Track RFC Action.
           [26]         Lockout (L) bit is defined in Section 13
           [27]         Inhibit alarm communication (I) in [RFC4783]

Top      Up      ToC       Page 43 
           [28]         Call control (C) bit is defined in
                        [GMPLS-CALL]
           [29]         Testing (T) bit is defined in [RFC3471]
           [30]         Administratively down (A) bit is defined in
                        [RFC3471]
           [31]         Deletion in progress (D) bit is defined in
                        [RFC3471]

20.  Acknowledgments

   The authors would like to thank John Drake for his active
   collaboration, Adrian Farrel for his contribution to this document
   (in particular, to the Section 10 and 11) and his thorough review of
   the document, Bart Rousseau (for editorial review), Dominique
   Verchere, and Stefaan De Cnodder.  Thanks also to Ichiro Inoue for
   his valuable comments.

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

21.  References

21.1.  Normative References

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

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.

   [RFC2747]    Baker, F., Lindell, B., and M. Talwar, "RSVP
                Cryptographic Authentication", RFC 2747, January 2000.

   [RFC2961]    Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
                and S. Molendini, "RSVP Refresh Overhead Reduction
                Extensions", RFC 2961, April 2001.

   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

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

Top      Up      ToC       Page 44 
   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

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

   [RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
                (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4426]    Lang, J., Rajagopalan, B., and D. Papadimitriou,
                "Generalized Multi-Protocol Label Switching (GMPLS)
                Recovery Functional Specification", RFC 4426, March
                2006.

   [RFC4873]    Berger, L., Bryskin, I., Papdimitriou, D., and A.
                Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.

21.2.  Informative References

   [RFC4783]    Berger, L., "GMPLS - Communication of Alarm
                Information", RFC 4783, December 2006.

   [CRANK]      Farrel, A., Ed., "Crankback Signaling Extensions for
                MPLS and GMPLS RSVP-TE",  Work in Progress, January
                2007.

   [GMPLS-CALL] Papadimitriou, D., Ed., and A. Farrel, Ed., "Generalized
                MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
                Calls",  Work in Progress, January 2007.

   [RFC4090]    Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
                Reroute Extensions to RSVP-TE for LSP Tunnels", RFC
                4090, May 2005.

   [RFC4427]    Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
                (Protection and Restoration) Terminology for Generalized
                Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
                2006.

   [RFC4874]    Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes
                - Extension to Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE)", RFC 4874, April 2007.

Top      Up      ToC       Page 45 
   [G.841]      ITU-T, "Types and Characteristics of SDH Network
                Protection Architectures," Recommendation G.841, October
                1998, available from http://www.itu.int.

22.  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 document:

   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

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

   Eric Mannie (Perceval)
   Rue Tenbosch, 9
   1000 Brussels, Belgium
   Phone: +32-2-6409194
   EMail: eric.mannie@perceval.net

   Bala Rajagopalan (Intel Broadband Wireless Division)
   2111 NE 25th Ave.
   Hillsboro, OR 97124, USA
   EMail: bala.rajagopalan@intel.com

Top      Up      ToC       Page 46 
Editors' Addresses

   Jonathan P. Lang
   Sonos
   506 Chapala Street
   Santa Barbara, CA 93101, USA

   EMail: jplang@ieee.org


   Yakov Rekhter
   Juniper
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089, USA

   EMail: yakov@juniper.net


   Dimitri Papadimitriou
   Alcatel
   Copernicuslaan 50
   B-2018, Antwerpen, Belgium

   EMail: dimitri.papadimitriou@alcatel-lucent.be

Top      Up      ToC       Page 47 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.