Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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:  48736780
Part 2 of 2 – Pages 23 to 47
First   Prev   None

Top   ToC   RFC4872 - Page 23   prevText

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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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   ToC   RFC4872 - 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.