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: 4873 6780 9270
Proposed Standard
→ Errata
Updates: 3471
Updated by: 4873 6780 9270
Part 2 of 2 – Pages 23 to 47
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:
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.
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.
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).
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
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).
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
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.
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.
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.
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.
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])
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.
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.
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 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
- 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.
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.
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.
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]
[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.
[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.
[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
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
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.