draft-ietf-ccamp-rsvp-restart-ext-09.txt   rfc5063.txt 
Network Working Group A. Satyanarayana, Ed.
Internet-Draft R. Rahman, Ed.
Updates: 2961, 3473 (if approved) Cisco Systems
Expires: January 2008
Extensions to GMPLS RSVP Graceful Restart Network Working Group A. Satyanarayana, Ed.
Request for Comments: 5063 R. Rahman, Ed.
Updates: 2961, 3473 Cisco Systems
Category: Standards Track September 2007
draft-ietf-ccamp-rsvp-restart-ext-09 Extensions to GMPLS Resource Reservation Protocol (RSVP)
Graceful Restart
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This document specifies an Internet standards track protocol for the
applicable patent or other IPR claims of which he or she is aware Internet community, and requests discussion and suggestions for
have been or will be disclosed, and any of which he or she becomes improvements. Please refer to the current edition of the "Internet
aware will be disclosed, in accordance with Section 6 of BCP 79. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to the RSVP Graceful Restart This document describes extensions to the Resource Reservation
mechanisms defined in RFC 3473. The extensions enable the recovery Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The
of RSVP signaling state based on the Path message last sent by the extensions enable the recovery of RSVP signaling state based on the
node being restarted. Path message last sent by the node being restarted.
Previously defined Graceful Restart mechanisms, also called recovery Previously defined Graceful Restart mechanisms, also called recovery
from nodal faults, permit recovery of signaling state from adjacent from nodal faults, permit recovery of signaling state from adjacent
nodes when the data plane has retained the associated forwarding nodes when the data plane has retained the associated forwarding
state across a restart. Those mechanisms do not fully support state across a restart. Those mechanisms do not fully support
signaling state recovery on ingress nodes or recovery of all RSVP signaling state recovery on ingress nodes or recovery of all RSVP
objects. objects.
The extensions defined in this document build on the RSVP Hello The extensions defined in this document build on the RSVP Hello
extensions defined in RFC 3209, and extensions for state recovery on extensions defined in RFC 3209, and extensions for state recovery on
nodal faults defined in RFC 3473. Using these extensions the nodal faults defined in RFC 3473. Using these extensions, the
restarting node can recover all previously transmitted Path state restarting node can recover all previously transmitted Path state,
including the Explicit Route Object and the downstream (outgoing) including the Explicit Route Object and the downstream (outgoing)
interface identifiers. The extensions can also be used to recover interface identifiers. The extensions can also be used to recover
signaling state after the restart of an ingress node. signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state. These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined The extensions optionally support the use of Summary Refresh, defined
in RFC 2961, to reduce the number of messages exchanged during the in RFC 2961, to reduce the number of messages exchanged during the
Recovery Phase when the restarting node has recovered signaling state Recovery Phase when the restarting node has recovered signaling state
locally for one or more LSPs. locally for one or more Label Switched Paths (LSPs).
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document ...............................5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology .....................................................5
4. Extensions to Nodal Fault Handling . . . . . . . . . . . 6 4. Extensions to Nodal Fault Handling ..............................5
4.1. RecoveryPath Message Format . . . . . . . . . . . . . . 6 4.1. RecoveryPath Message Format ................................5
4.2. Capability Object . . . . . . . . . . . . . . . . . . . 6 4.2. Capability Object ..........................................6
4.2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Conformance .........................................7
4.3. Related Procedures . . . . . . . . . . . . . . . . . . . 8 4.3. Related Procedures .........................................7
4.4. Procedures for the Capability Object . . . . . . . . . . 8 4.4. Procedures for the Capability Object .......................8
4.4.1. Procedures for the Downstream Neighbor . . . . . . . . . 8 4.4.1. Procedures for the Downstream Neighbor ..............8
4.4.2. Procedures for the Restarting Node . . . . . . . . . . . 9 4.4.2. Procedures for the Restarting Node ..................8
4.5. Procedures for the RecoveryPath message . . . . . . . . 9 4.5. Procedures for the RecoveryPath Message ....................9
4.5.1. Procedures for the Downstream Neighbor . . . . . . . . . 9 4.5.1. Procedures for the Downstream Neighbor ..............9
4.5.2. Procedures for the Restarting Node . . . . . . . . . . . 11 4.5.2. Procedures for the Restarting Node .................10
4.5.2.1. Path and RecoveryPath Message Procedures . . . . . . . . 11 4.5.2.1. Path and RecoveryPath Message Procedures ..11
4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12 4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12
4.5.2.3. Procedures on Expiration of Recovery Period . . . . . . 13 4.5.2.3. Procedures on Expiration of
4.6. Compatibility . . . . . . . . . . . . . . . . . . . . . 13 Recovery Period ...........................13
5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . 14 4.6. Compatibility .............................................13
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . 15 5. RecoveryPath Summary Refresh ...................................14
5.2. RecoveryPath Srefresh Capable bit . . . . . . . . . . . 16 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
5.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. RecoveryPath Srefresh Capable Bit .........................16
5.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Procedures .........................................16
5.3. RecoveryPath Summary Refresh Procedures . . . . . . . . 17 5.2.2. Compatibility ......................................17
5.3.1. Generation of RecoveryPath-related Srefresh Messages . . 17 5.3. RecoveryPath Summary Refresh Procedures ...................17
5.3.2. RecoveryPath-related Srefresh Receive Processing and 5.3.1. Generation of RecoveryPath-Related Srefresh
NACK Generation . . . . . . . . . . . . . . . . . . . . 19 Messages ...........................................17
5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive 5.3.2. RecoveryPath-Related Srefresh Receive
Processing . . . . . . . . . . . . . . . . . . . . . . . 19 Processing and NACK Generation .....................19
6. Security Considerations . . . . . . . . . . . . . . . . 20 5.3.3. RecoveryPath-Related MESSAGE_ID NACK
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21 Receive Processing .................................19
8. IANA Considerations . . . . . . . . . . . . . . . . . . 21 6. Security Considerations ........................................20
9. Normative References . . . . . . . . . . . . . . . . . . 22 7. Acknowledgments ................................................21
8. IANA Considerations ............................................21
1. Conventions used in this document 9. Normative References ...........................................22
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminology
The reader is assumed to be familiar with the terminology defined in
[RFC3209] and [RFC3473].
Throughout this document, the term "node" when used in the context of
a restarting or restarted node generally refers to the control plane
component which is the signaling controller for a data plane switch.
3. Introduction 1. Introduction
RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms
defined in [RFC3209]. When data/forwarding plane state can be defined in [RFC3209]. When data/forwarding plane state can be
retained across the restart of the RSVP agent that established such retained across the restart of the RSVP agent that established such
state, RSVP Graceful Restart provides the ability for the RSVP agent state, RSVP Graceful Restart provides the ability for the RSVP agent
to resynchronize its state based on updates received from its to resynchronize its state based on updates received from its
neighboring RSVP agents, and, reconcile such state with the retained neighboring RSVP agents, and, reconcile such state with the retained
data/forwarding plane state. [RFC3209] describes a mechanism, using data/forwarding plane state. [RFC3209] describes a mechanism, using
RSVP Hello messages, to detect the state of an adjacent RSVP agent. RSVP Hello messages, to detect the state of an adjacent RSVP agent.
[RFC3473] extends this mechanism to advertise the capability of [RFC3473] extends this mechanism to advertise the capability of
retaining data/forwarding plane state across the restart of a node or retaining data/forwarding plane state across the restart of a node or
a "nodal fault". [RFC3473] also defines the Recovery Label object a "nodal fault". [RFC3473] also defines the Recovery Label object
for use in the Path message of the RSVP neighbor upstream of a for use in the Path message of the RSVP neighbor upstream of a
restarting node, to indicate that the Path message is for existing restarting node, to indicate that the Path message is for existing
data plane state. data plane state.
This document presents extensions to address two aspects of graceful This document presents extensions to address two aspects of graceful
restart not previously supported. The presented extensions enable a restart not previously supported. The presented extensions enable a
restarting node to recover all objects in previously transmitted Path restarting node to recover all objects in previously transmitted Path
messages including the Explicit Route Object (ERO), from its messages, including the Explicit Route Object (ERO), from its
downstream neighbors and so recover control plane state. The downstream neighbors, thus recovering the control plane state. The
extensions do not facilitate the recovery or creation of extensions do not facilitate the recovery or creation of
data/forwarding plane state, and can only be used to re-establish data/forwarding plane state, and can only be used to reestablish
control plane state which matches in-place data/forwarding state. control plane state that matches in-place data/forwarding state. The
The extensions also enable graceful restart of an ingress node that extensions also enable graceful restart of an ingress node that does
does not preserve full RSVP state across restarts. The presented not preserve full RSVP state across restarts. The presented
extensions are equally applicable to LSPs of various switching types extensions are equally applicable to LSPs of various switching types
as defined in [RFC3471]. as defined in [RFC3471].
Per [RFC3473], a restarting node can distinguish Path messages Per [RFC3473], a restarting node can distinguish Path messages
associated with LSPs being recovered by the presence of the Recovery associated with LSPs being recovered by the presence of the Recovery
Label object. To determine the downstream (outgoing) interface and Label object. To determine the downstream (outgoing) interface and
associated label(s), the restarting node must consult the data plane. associated label(s), the restarting node must consult the data plane.
This may not be possible for all types of nodes. Furthermore, data This may not be possible for all types of nodes. Furthermore, data
plane information is not sufficient to reconstruct all previously plane information is not sufficient to reconstruct all previously
transmitted Path state. In these cases, the only source of RSVP transmitted Path state. In these cases, the only source of RSVP
state is the downstream RSVP neighbor. state is the downstream RSVP neighbor.
For example, when the restarting node is an ingress node, all For example, when the restarting node is an ingress node, all
previously transmitted Path state may need to be recovered. Such previously transmitted Path state may need to be recovered. Such
Path state may include (but is not restricted to) the Protection Path state may include (but is not restricted to) the Protection
object, the Admin Status object, the Session Attribute object, the object, the Admin Status object, the Session Attribute object, the
Notify Request object, the Sender Tspec object. A restarting transit Notify Request object, and the Sender Tspec object. A restarting
node may have modified received Path state in its previously transit node may have modified received Path state in its previously
transmitted Path message, which cannot be reconstructed internally transmitted Path message, which cannot be reconstructed internally
during recovery. during recovery.
Another example of state that cannot be completely recovered from the Another example of state that cannot be completely recovered from the
data plane in some cases is the previously transmitted ERO. Recovery data plane in some cases is the previously transmitted ERO. Recovery
of the previously transmitted ERO minimizes subsequent change of of the previously transmitted ERO minimizes subsequent change of
downstream LSP state. On a restarting ingress node, the ERO may have downstream LSP state. On a restarting ingress node, the ERO may have
been based on configuration or the result of a previous path been based on configuration or the result of a previous path
computation. A restarting transit node may have previously performed computation. A restarting transit node may have previously performed
some form of path computation as a result of not receiving an ERO or some form of path computation as a result of not receiving an ERO or
receiving a loose hop in the ERO. In addition to the ERO, the receiving a loose hop in the ERO. In addition to the ERO, the
restarting node may have modified other received Path state in its restarting node may have modified other received Path state in its
previously transmitted Path state, which cannot be reconstructed previously transmitted Path state, which cannot be reconstructed
internally during recovery. internally during recovery.
The defined extensions provide a restarting upstream node with all The defined extensions provide a restarting upstream node with all
information previously transmitted by the node in Path messages. information previously transmitted by the node in Path messages.
This is accomplished by the downstream RSVP neighbor sending a new This is accomplished by the downstream RSVP neighbor sending a new
message for every Path message it has previously received from the message for every Path message it has previously received from the
restarting node, after reestablishing RSVP communication with a restarting node, after reestablishing RSVP communication with a
restarted node which supports the recovery procedures defined in restarted node that supports the recovery procedures defined in
Section 4.5.2 of this document. Section 4.5.2 of this document.
The new message is called the RecoveryPath message. The message The new message is called the RecoveryPath message. The message
conveys the contents of the last received Path message back to the conveys the contents of the last received Path message back to the
restarting node. The restarting node can use the RecoveryPath restarting node. The restarting node can use the RecoveryPath
message along with the state in the received Path message to message, along with the state in the received Path message to
associate control and data plane state and to validate the forwarding associate control and data plane state and to validate the forwarding
state with the state presented by the neighboring RSVP nodes. state with the state presented by the neighboring RSVP nodes.
The restarting node indicates its desire to receive and process the The restarting node indicates its desire to receive and process the
RecoveryPath message by including a new object called the Capability RecoveryPath message by including a new object called the Capability
object with the RecoveryPath Desired bit set, in its Hello messages object with the RecoveryPath Desired bit set, in its Hello messages
sent to the downstream RSVP neighbor. The downstream RSVP neighbor sent to the downstream RSVP neighbor. The downstream RSVP neighbor
can indicate its ability to send RecoveryPath messages by including can indicate its ability to send RecoveryPath messages by including
the Capability object with the RecoveryPath Transmit Enabled set in the Capability object with the RecoveryPath Transmit Enabled set in
its Hello messages to the restarting node. Thus, both the restarting its Hello messages to the restarting node. Thus, both the restarting
skipping to change at page 6, line 23 skipping to change at page 5, line 15
Selective transmission of the RecoveryPath message is supported by Selective transmission of the RecoveryPath message is supported by
enhancing the Summary Refresh mechanisms defined in [RFC2961]. When enhancing the Summary Refresh mechanisms defined in [RFC2961]. When
Recovery Summary Refresh is supported, the restarting node can select Recovery Summary Refresh is supported, the restarting node can select
the LSPs for which it would like to receive RecoveryPath messages. the LSPs for which it would like to receive RecoveryPath messages.
This is useful when the restarting node is able to locally recover This is useful when the restarting node is able to locally recover
the signaling state for a subset of the previously active LSPs. the signaling state for a subset of the previously active LSPs.
Restarting egress nodes, and Resv message processing are not impacted Restarting egress nodes, and Resv message processing are not impacted
by the presented extensions, see [RFC3473] for details. by the presented extensions, see [RFC3473] for details.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
The reader is assumed to be familiar with the terminology defined in
[RFC3209] and [RFC3473].
Throughout this document, the term "node", when used in the context
of a restarting or restarted node, generally refers to the control
plane component, which is the signaling controller for a data plane
switch.
4. Extensions to Nodal Fault Handling 4. Extensions to Nodal Fault Handling
This section presents the protocol modifications to Section 9 of This section presents the protocol modifications to Section 9 of
[RFC3473]. [RFC3473].
4.1. RecoveryPath Message Format 4.1. RecoveryPath Message Format
The format of a RecoveryPath message is the same as the format of a The format of a RecoveryPath message is the same as the format of a
Path message as defined in [RFC3473], but uses a new message number Path message, as defined in [RFC3473], but uses a new message number
so that it can be identified correctly. (30) so that it can be identified correctly.
<RecoveryPath Message> ::= <Path Message> <RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath The destination address used in the IP header of a RecoveryPath
message MUST be the same as the destination address used in the IP message MUST be the same as the destination address used in the IP
header of the corresponding Resv message last generated by the header of the corresponding Resv message last generated by the
sending node. Except as specified below all objects in a sending node. Except as specified below, all objects in a
RecoveryPath message are identical to the objects in the RecoveryPath message are identical to the objects in the
corresponding Path message last received by the sending node. corresponding Path message last received by the sending node.
4.2. Capability Object 4.2. Capability Object
Capability objects are carried in RSVP Hello messages. The Capability objects are carried in RSVP Hello messages. The
Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type
of 1. of 1.
The message format of a Hello message is modified to be: The message format of a Hello message is modified to be:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> <Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ] [ <RESTART_CAP> ] [ <CAPABILITY> ]
The format of a Capability object is: The format of a Capability object is:
0 1 2 3 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 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(TBA)| C-Type (1) | | Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S| | Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Transmit Enabled (T): 1 bit RecoveryPath Transmit Enabled (T): 1 bit
When set (1), indicates that the sending node is enabled to When set (1), indicates that the sending node is enabled to
send RecoveryPath messages. Absence of the Capability object send RecoveryPath messages. Absence of the Capability object
MUST be treated as if the T-bit is cleared (0). MUST be treated as if the T-bit is cleared (0).
RecoveryPath Desired (R): 1 bit RecoveryPath Desired (R): 1 bit
When set (1), indicates that the sending node desires to When set (1), indicates that the sending node desires to
receive RecoveryPath messages. Absence of the Capability receive RecoveryPath messages. Absence of the Capability
object MUST be treated as if the R-bit is cleared (0). object MUST be treated as if the R-bit is cleared (0).
RecoveryPath Srefresh Capable (S): 1 bit RecoveryPath Srefresh Capable (S): 1 bit
When set (1) along with the R-bit, indicates that the sending When set (1), along with the R-bit, indicates that the sending
node is capable of receiving and processing Srefresh messages node is capable of receiving and processing Srefresh messages
with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST
object. Absence of the Capability object MUST be treated as if object. Absence of the Capability object MUST be treated as if
the S-bit is cleared (0). Related procedures are defined in the S-bit is cleared (0). Related procedures are defined in
Section 5.2.1. Section 5.2.1.
Reserved bits Reserved bits
Reserved bits MUST be set to zero on transmission and MUST be Reserved bits MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
4.2.1. Conformance 4.2.1. Conformance
All nodes supporting the extensions defined in this document MUST be All nodes supporting the extensions defined in this document MUST be
able to transmit, and, properly receive and process RecoveryPath able to transmit, and properly receive and process RecoveryPath
messages. All nodes MUST be able to set both the T and R bits. Both messages. All nodes MUST be able to set both the T and R bits. Both
the T and R bits SHOULD be set (1) by default. A node MAY allow the T and R bits SHOULD be set (1) by default. A node MAY allow
RecoveryPath message transmission and reception to be independently RecoveryPath message transmission and reception to be independently
disabled based on local policy. When RecoveryPath message disabled based on local policy. When RecoveryPath message
transmission is disabled, the T-bit MUST be set to zero (0). When transmission is disabled, the T-bit MUST be set to zero (0). When
RecoveryPath message reception is not desired, the R-bit MUST be set RecoveryPath message reception is not desired, the R-bit MUST be set
to zero (0). to zero (0).
Any node that supports the extensions defined in this document and Any node that supports the extensions defined in this document and
sets the Refresh-Reduction-Capable bit [RFC2961], SHOULD support sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support
setting of the S-bit and support the mechanisms defined in Section 5. setting of the S-bit and support the mechanisms defined in Section 5.
4.3. Related Procedures 4.3. Related Procedures
This document does not modify existing procedures for sending and This document does not modify existing procedures for sending and
receiving RSVP Hello messages as defined in [RFC3209] and the receiving RSVP Hello messages, as defined in [RFC3209], and the
Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. Restart_Cap object in RSVP Hello messages as defined in [RFC3473].
The procedures for control channel faults are defined in [RFC3473] The procedures for control channel faults are defined in [RFC3473]
and are not changed by this document. and are not changed by this document.
The presented extensions require the use of RSVP Hellos as defined in The presented extensions require the use of RSVP Hellos, as defined
[RFC3209] and the use of the Restart_Cap object extension as defined in [RFC3209], and the use of the Restart_Cap object extension as
in [RFC3473]. The presented extensions address only "Nodal Faults" defined in [RFC3473]. The presented extensions address only "Nodal
as defined in [RFC3473]. Control channel faults are fully addressed Faults" as defined in [RFC3473]. Control channel faults are fully
in [RFC3473]. addressed in [RFC3473].
Note: There are no changes to the procedures defined in Section 9.5.3 Note: There are no changes to the procedures defined in Section 9.5.3
in [RFC3473] (Procedures for the Neighbor of a Restarting node). in [RFC3473] (Procedures for the Neighbor of a Restarting node).
There are no changes to the procedures defined in Section 9.5.2 in There are no changes to the procedures defined in Section 9.5.2 in
[RFC3473] if the restarting node is an egress node. [RFC3473] if the restarting node is an egress node.
There are no changes to the procedures with respect of the There are no changes to the procedures with respect to the
data/forwarding plane as described in [RFC3473]. In particular, a data/forwarding plane as described in [RFC3473]. In particular, a
restarting node MUST NOT create data/forwarding plane state as the restarting node MUST NOT create data/forwarding plane state as the
result of any of the extensions defined in this document. result of any of the extensions defined in this document.
The following sections assume previously defined procedures are The following sections assume previously defined procedures are
followed, except where explicitly modified. followed, except where explicitly modified.
4.4. Procedures for the Capability Object 4.4. Procedures for the Capability Object
4.4.1. Procedures for the Downstream Neighbor 4.4.1. Procedures for the Downstream Neighbor
If a node is capable of sending RecoveryPath messages, it MUST If a node is capable of sending RecoveryPath messages, it MUST
include the Capability object with the RecoveryPath Transmit Enabled include the Capability object with the RecoveryPath Transmit Enabled
(T) bit set (1) in all its Hello messages. (T) bit set (1) in all its Hello messages.
If the downstream RSVP neighbor receives Hello messages from a If the downstream RSVP neighbor receives Hello messages from a
restarting node, with the Restart_Cap object as defined in [RFC3473], restarting node, with the Restart_Cap object, as defined in
and, with the Capability object with the RecoveryPath Desired (R) bit [RFC3473], and with the Capability object with the RecoveryPath
set (1), it MUST treat the restarting node as capable of receiving Desired (R) bit set (1), it MUST treat the restarting node as capable
and processing RecoveryPath messages as defined in this document. of receiving and processing RecoveryPath messages as defined in this
document.
If the downstream RSVP neighbor receives a Capability object in a If the downstream RSVP neighbor receives a Capability object in a
Hello message with the RecoveryPath Desired (R) bit set (1), but, Hello message with the RecoveryPath Desired (R) bit set (1), but
without the Restart_Cap object, it MUST process the Hello message as without the Restart_Cap object, it MUST process the Hello message as
if the RecoveryPath Receive Desired (R) bit is cleared (0) in the if the RecoveryPath Receive Desired (R) bit is cleared (0) in the
Hello message. Hello message.
If the downstream RSVP neighbor does not receive the Capability If the downstream RSVP neighbor does not receive the Capability
object in Hello messages sent by the restarting node or the object in Hello messages sent by the restarting node or the
RecoveryPath Desired (R) bit is cleared (0) in the Capability object, RecoveryPath Desired (R) bit is cleared (0) in the Capability object,
it MUST treat the restarting node as not capable of supporting the it MUST treat the restarting node as not capable of supporting the
RecoveryPath message procedures defined in this document, and, MUST RecoveryPath message procedures defined in this document, and MUST
revert to recovery procedures as defined in [RFC3473]. revert to recovery procedures as defined in [RFC3473].
4.4.2. Procedures for the Restarting Node 4.4.2. Procedures for the Restarting Node
A node that expects to recover RSVP state by the receipt and A node that expects to recover RSVP state by the receipt and
processing of RecoveryPath messages according to procedures defined processing of RecoveryPath messages according to procedures defined
in this document, MUST include the Capability object with the in this document, MUST include the Capability object with the
RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to
its neighbors. The node MUST also include the Restart_Cap object as its neighbors. The node MUST also include the Restart_Cap object, as
defined in [RFC3473], in all those Hello messages. defined in [RFC3473], in all those Hello messages.
If the Recovery Time is zero (0) or the restarting node does not If the Recovery Time is zero (0) or the restarting node does not
support/desire the use of RecoveryPath messages, the RecoveryPath support/desire the use of RecoveryPath messages, the RecoveryPath
Desired (R) bit MUST be cleared (0) in the Capability object included Desired (R) bit MUST be cleared (0) in the Capability object included
in Hello messages, or the Capability object MAY be omitted from Hello in Hello messages, or the Capability object MAY be omitted from Hello
messages sent by the restarting node. messages sent by the restarting node.
During the Recovery Period, if the restarting node receives Hello During the Recovery Period, if the restarting node receives Hello
messages from a downstream RSVP neighbor with the RecoveryPath messages from a downstream RSVP neighbor with the RecoveryPath
Transmit Enabled (T) bit set (1) in the Capability object and the Transmit Enabled (T) bit set (1) in the Capability object and the
Restart_Cap object as defined in [RFC3473], it MUST treat the Restart_Cap object, as defined in [RFC3473], it MUST treat the
downstream RSVP neighbor as capable of sending RecoveryPath messages downstream RSVP neighbor as capable of sending RecoveryPath messages
according to procedures defined in Section 4.5.1. If the restarting according to procedures defined in Section 4.5.1. If the restarting
node expects to recover RSVP state by the receipt and processing of node expects to recover RSVP state by the receipt and processing of
RecoveryPath messages, it MUST follow procedures defined in RecoveryPath messages, it MUST follow procedures defined in Section
Section 4.5.2, with the downstream RSVP neighbor. 4.5.2, with the downstream RSVP neighbor.
During the Recovery Period, if the restarting node receives Hello During the Recovery Period, if the restarting node receives Hello
messages from a downstream RSVP neighbor with the RecoveryPath messages from a downstream RSVP neighbor with the RecoveryPath
Transmit Enabled (T) bit cleared (0) in the Capability object, or, Transmit Enabled (T) bit cleared (0) in the Capability object, or,
with the Capability object not present, it MUST treat the downstream with the Capability object not present, it MUST treat the downstream
RSVP neighbor as not capable of the RecoveryPath message procedures RSVP neighbor as not capable of the RecoveryPath message procedures
defined in this document, and, it MUST revert to the recovery defined in this document, and, it MUST revert to the recovery
procedures defined in [RFC3473] immediately, with the downstream RSVP procedures defined in [RFC3473] immediately, with the downstream RSVP
neighbor. neighbor.
4.5. Procedures for the RecoveryPath message 4.5. Procedures for the RecoveryPath Message
4.5.1. Procedures for the Downstream Neighbor 4.5.1. Procedures for the Downstream Neighbor
After a downstream RSVP neighbor has detected that its upstream node After a downstream RSVP neighbor has detected that its upstream node
has restarted, is capable of recovery as defined in [RFC3473], and, has restarted, is capable of recovery as defined in [RFC3473], and,
is capable of receiving RecoveryPath messages as defined in is capable of receiving RecoveryPath messages as defined in Section
Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message
message for each LSP associated with the restarting node for which it for each LSP associated with the restarting node for which it has
has sent a Resv message. During the Recovery Period, if the sent a Resv message. During the Recovery Period, if the downstream
downstream RSVP neighbor detects that the restarting node is not RSVP neighbor detects that the restarting node is not capable of
capable of receiving RecoveryPath messages, by the absence of the receiving RecoveryPath messages by the absence of the Capability
Capability object or the RecoveryPath Desired (R) bit cleared (0) in object or the RecoveryPath Desired (R) bit cleared (0) in the
the Capability object in the restarting node's Hello messages, the Capability object in the restarting node's Hello messages, the
downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to
the restarting node. the restarting node.
The RecoveryPath message is constructed by copying all objects from The RecoveryPath message is constructed by copying all objects from
the last received associated Path message, with the following the last received associated Path message, with the following
exceptions: exceptions:
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not
copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK
objects used in RecoveryPath messages are generated based on objects used in RecoveryPath messages are generated based on
procedures defined in [RFC2961]. procedures defined in [RFC2961].
The Integrity object is not copied. Any Integrity objects used in The Integrity object is not copied. Any Integrity objects used in
RecoveryPath messages are generated based on procedures defined in RecoveryPath messages are generated based on procedures defined in
[RFC2747]. [RFC2747].
The RSVP Hop object is copied from the most recent associated Resv The RSVP Hop object is copied from the most recent associated Resv
message sent to the restarted node, for the LSP being recovered. message sent to the restarted node for the LSP being recovered.
In the sender descriptor, the Recovery Label object MUST be In the sender descriptor, the Recovery Label object MUST be
included, with the label value copied from the label value in the included, with the label value copied from the label value in the
Label object in the most recent associated Resv message sent to Label object in the most recent associated Resv message sent to
the restarted node, for the LSP being recovered. the restarted node, for the LSP being recovered.
All other objects from the most recent received Path message MUST be All other objects from the most recent received Path message MUST be
included in the RecoveryPath message. included in the RecoveryPath message.
All RecoveryPath messages SHOULD be sent at least once within All RecoveryPath messages SHOULD be sent at least once within
approximately 1/2 of the Recovery Time advertised by the restarted approximately 1/2 of the Recovery Time advertised by the restarted
neighbor. If there are many LSPs to be recovered by the restarted neighbor. If there are many LSPs to be recovered by the restarted
node, the downstream RSVP neighbor should avoid sending RecoveryPath node, the downstream RSVP neighbor should avoid sending RecoveryPath
messages in a short time interval, to avoid overloading the restarted messages in a short time interval to avoid overloading the restarted
node's CPU. Instead it should spread the messages across 1/2 the node's CPU. Instead, it should spread the messages across 1/2 the
Recovery Time interval. The range of Recovery Time is dependent on Recovery Time interval. The range of Recovery Time is dependent on
many factors including but not limited to the CPU processing power on many factors including, but not limited to, the CPU processing power
the restarting node as well as the upstream and downstream neighbors, on the restarting node as well as the upstream and downstream
amount of CPU available for processing RSVP recovery procedures, neighbors, the amount of CPU available for processing RSVP recovery
implementation specifics that affect the amount of time taken to procedures, and the implementation specifics that affect the amount
verify the received recovery state against existing forwarding plane of time taken to verify the received recovery state against existing
state. Such discussion is out of scope of this document. forwarding plane state. Such discussion is out of scope of this
document.
After sending a RecoveryPath message and during the Recovery Period, After sending a RecoveryPath message and during the Recovery Period,
the node SHOULD periodically re-send the RecoveryPath message until the node SHOULD periodically resend the RecoveryPath message until it
it receives a corresponding response. A corresponding response is a receives a corresponding response. A corresponding response is a
Message ID acknowledgment or a Path message for the LSP the Message ID acknowledgment or a Path message for the LSP the
RecoveryPath message represents. Each such re-send attempt is at the RecoveryPath message represents. Each such resend attempt is at the
end of any Message ID rapid retransmissions, if the Message ID end of any Message ID rapid retransmissions, if the Message ID
mechanism is used. If the Message ID mechanism is not in use, the mechanism is used. If the Message ID mechanism is not in use, the
period between re-send attempts SHOULD be such that at least 3 period between resend attempts SHOULD be such that at least 3
attempts are completed before the expiry of 3/4 the Recovery Time attempts are completed before the expiry of 3/4 the Recovery Time
interval. Each such re-send attempt MUST treat the RecoveryPath interval. Each such resend attempt MUST treat the RecoveryPath
message as a new message, and update the MESSAGE_ID object according message as a new message and update the MESSAGE_ID object according
to procedures defined in [RFC2961]. Note, per [RFC3473], Resv to procedures defined in [RFC2961]. Note, per [RFC3473], Resv
messages are suppressed during this recovery period until a messages are suppressed during this recovery period until a
corresponding Path message is received. corresponding Path message is received.
4.5.2. Procedures for the Restarting Node 4.5.2. Procedures for the Restarting Node
These procedures apply during the "state recovery process" and These procedures apply during the "state recovery process" and
"Recovery Period" as defined in Section 9.5.2 in [RFC3473]. Any "Recovery Period" as defined in Section 9.5.2 of [RFC3473]. Any
RecoveryPath message received after the Recovery Period has expired RecoveryPath message received after the Recovery Period has expired
SHOULD be matched against local LSP state. If matching fully SHOULD be matched against local LSP state. If matching fully
resynchronized state is located, the node SHOULD send a Path message resynchronized state is located, the node SHOULD send a Path message
downstream. If non-resynchronized or no LSP state matching the downstream. If non-resynchronized or no LSP state matching the
RecoveryPath message is located, the restarted node MAY send a RecoveryPath message is located, the restarted node MAY send a
PathTear message constructed from the RecoveryPath message, to PathTear message constructed from the RecoveryPath message to
expedite the cleanup of unrecovered RSVP and associated forwarding expedite the cleanup of unrecovered RSVP and associated forwarding
state downstream of the restarted node. The restarting node MUST state downstream of the restarted node. The restarting node MUST NOT
NOT create data plane or forwarding state to match the received create data plane or forwarding state to match the received
RecoveryPath message. RecoveryPath message.
The remaining procedures are broken down into three sub-sections. The remaining procedures are broken down into three sub-sections.
The term "resynchronized state", originally defined in [RFC3473], is The term "resynchronized state", originally defined in [RFC3473], is
used and modified in these sections. This term refers to LSP state used and modified in these sections. This term refers to LSP state
that is fully recovered. that is fully recovered.
Signaling state may be recovered from sources other than the Signaling state may be recovered from sources other than the
mechanisms defined in this document. The restarting node SHOULD mechanisms defined in this document. The restarting node SHOULD
consider signaling state as resynchronized for all such LSPs and consider signaling state as resynchronized for all such LSPs and
skipping to change at page 11, line 50 skipping to change at page 11, line 30
Again, there are no changes to the procedures defined in Section Again, there are no changes to the procedures defined in Section
9.5.2 in [RFC3473] if the restarting node is an egress node. 9.5.2 in [RFC3473] if the restarting node is an egress node.
4.5.2.1. Path and RecoveryPath Message Procedures 4.5.2.1. Path and RecoveryPath Message Procedures
When a node receives a RecoveryPath message during the Recovery When a node receives a RecoveryPath message during the Recovery
Period, the node first checks if it has resynchronized RSVP state Period, the node first checks if it has resynchronized RSVP state
associated with the message. If there is resynchronized state, and associated with the message. If there is resynchronized state, and
when both reliable message delivery [RFC2961] is supported and a when both reliable message delivery [RFC2961] is supported and a
MESSAGE_ID object is present in the RecoveryPath message, the node MESSAGE_ID object is present in the RecoveryPath message, the node
MUST follow Message ID acknowledgment procedures as defined in MUST follow Message ID acknowledgment procedures, as defined in
[RFC2961], and, consider the message as processed. If there is [RFC2961], and consider the message as processed. If there is
resynchronized state, and, there is no MESSAGE_ID object or reliable resynchronized state and there is no MESSAGE_ID object or reliable
message delivery [RFC2961] is not supported, the node SHOULD send a message delivery [RFC2961] is not supported, the node SHOULD send a
trigger Path message, and, consider the message as processed. trigger Path message, and, consider the message as processed.
If non-resynchronized state is found or the node is the ingress, the If a non-resynchronized state is found or the node is the ingress,
node saves the information contained in the RecoveryPath message and the node saves the information contained in the RecoveryPath message
continues with processing as defined in Section 4.5.2.2. and continues with processing as defined in Section 4.5.2.2.
If no associated RSVP state is found and the node is not the ingress If no associated RSVP state is found and the node is not the ingress
node, the node saves the information contained in the RecoveryPath node, the node saves the information contained in the RecoveryPath
message for later use. message for later use.
Note the following modifies Section 9.5.2 of [RFC3473]: Note the following modifies Section 9.5.2 of [RFC3473]:
When a node receives a Path message during the Recovery Period, the When a node receives a Path message during the Recovery Period, the
node first locates any RSVP state associated with the message. If node first locates any RSVP state associated with the message. If
resynchronized RSVP state is found, then the node handles this resynchronized RSVP state is found, then the node handles this
message according to previously defined procedures. message according to previously defined procedures.
If non-resynchronized state is found, the node saves the information If a non-resynchronized state is found, the node saves the
contained in the Path message including the Recovery_Label object and information contained in the Path message, including the
continues with processing as defined in Section 4.5.2.2. Recovery_Label object, and continues with processing as defined in
Section 4.5.2.2.
Per [RFC3473], if matching RSVP state is not found, and the message Per [RFC3473], if matching RSVP state is not found, and the message
does not carry a Recovery_Label object, the node treats this as a does not carry a Recovery_Label object, the node treats this as a
setup for a new LSP, and handles it according to previously defined setup for a new LSP, and handles it according to previously defined
procedures. procedures.
If matching RSVP state is not found, and the message carries a If a matching RSVP state is not found and the message carries a
Recovery_Label object, the node saves the information contained in Recovery_Label object, the node saves the information contained in
the Path message including the Recovery_Label object for later use. the Path message, including the Recovery_Label object for later use.
4.5.2.2. Re-Synchronization Procedures 4.5.2.2. Re-Synchronization Procedures
After receipt of the RecoveryPath message and, for non-ingress LSPs, After receipt of the RecoveryPath message and, for non-ingress LSPs,
the corresponding Path message with a Recovery Label object, the the corresponding Path message with a Recovery Label object, the
restarting node SHOULD locate and associate corresponding forwarding restarting node SHOULD locate and associate corresponding forwarding
state using the received information. The restarting node associates state using the received information. The restarting node associates
the corresponding active forwarding plane state from the following the corresponding active forwarding plane state from the following
signaled information: signaled information:
skipping to change at page 13, line 16 skipping to change at page 12, line 50
Recovery Label object in the received RecoveryPath message. If Recovery Label object in the received RecoveryPath message. If
the LSP is bidirectional, the label for the upstream direction is the LSP is bidirectional, the label for the upstream direction is
recovered from the Upstream Label object in the RecoveryPath recovered from the Upstream Label object in the RecoveryPath
message. message.
If complete forwarding state is located, the restarted node MUST If complete forwarding state is located, the restarted node MUST
treat the LSP as resynchronized and MUST send a trigger Path message treat the LSP as resynchronized and MUST send a trigger Path message
downstream. The Explicit Route object in the Path message SHOULD downstream. The Explicit Route object in the Path message SHOULD
match the Explicit Route object received in the RecoveryPath message. match the Explicit Route object received in the RecoveryPath message.
In addition, the restarted node SHOULD recover state from the other In addition, the restarted node SHOULD recover state from the other
objects received in the RecoveryPath message. Optimally the objects received in the RecoveryPath message. Optimally, the
resulting Path message should not cause any redundant or unnecessary resulting Path message should not cause any redundant or unnecessary
re-processing of state along the remaining downstream nodes. reprocessing of state along the remaining downstream nodes. Ideally,
Ideally, except for MESSAGE_ID processing and recovery processing, except for MESSAGE_ID processing and recovery processing, the
the transmitted Path message will be treated as a refresh by the transmitted Path message will be treated as a refresh by the
downstream RSVP neighbor (and hence should not trigger any generation downstream RSVP neighbor (and hence, should not trigger any
of Path messages with changed state further downstream). generation of Path messages with changed state further downstream).
If no forwarding state is located, the node treats the received Path If no forwarding state is located, the node treats the received Path
message as a setup request for a new LSP. The outgoing interface and message as a setup request for a new LSP. The outgoing interface and
label(s) indicated in the RecoveryPath message SHOULD be reused, when label(s) indicated in the RecoveryPath message SHOULD be reused when
possible. All other information contained in the RecoveryPath possible. All other information contained in the RecoveryPath
message MAY also be used. That is, forwarding state MUST NOT be message MAY also be used. That is, forwarding state MUST NOT be
created except after receipt of a Path message from upstream or, at created except after receipt of a Path message from upstream or, at
an ingress node, the receipt of a command from the management plane. an ingress node, the receipt of a command from the management plane.
Further, the forwarding state created is subject to local policy and Further, the forwarding state created is subject to local policy and
the information received from downstream in the RecoveryPath message the information received from downstream in the RecoveryPath message
is treated only as advisory. is treated only as advisory.
4.5.2.3. Procedures on Expiration of Recovery Period 4.5.2.3. Procedures on Expiration of Recovery Period
There are several cleanup steps to follow at the end of the Recovery There are several cleanup steps to follow at the end of the Recovery
Period. At the end of the Recovery Period, any state that was Period. At the end of the Recovery Period, any state that was
installed as the result of a received RecoveryPath message that is installed as the result of a received RecoveryPath message that is
not resynchronized SHOULD be discarded. not resynchronized SHOULD be discarded.
Any Path messages that were received containing a Recovery_Label that Any Path messages that were received containing a Recovery_Label that
has not been resynchronized, MUST be treated as being received has not been resynchronized, MUST be treated as being received during
during the Recovery Period and processed as per [RFC3473]. the Recovery Period and processed as per [RFC3473].
Per [RFC3473], any other state that is not resynchronized during the Per [RFC3473], any other state that is not resynchronized during the
Recovery Period SHOULD be removed at the end of the Period. Recovery Period SHOULD be removed at the end of the Period.
4.6. Compatibility 4.6. Compatibility
This document introduces a new RSVP signaling message called the This document introduces a new RSVP signaling message called the
RecoveryPath message to be generated by the downstream RSVP neighbor RecoveryPath message to be generated by the downstream RSVP neighbor
of a restarting node. To advertise the capability of sending and of a restarting node. To advertise the capability of sending and
receiving RecoveryPath messages, this document introduces the receiving RecoveryPath messages, this document introduces the
Capability object, to be included in Hello messages by a restarting Capability object to be included in Hello messages by a restarting
node and its downstream RSVP neighbors. node and its downstream RSVP neighbors.
If a restarting node does not support the Capability object, it will If a restarting node does not support the Capability object, it will
discard the object as the Class-Number is of the form 10bbbbbb and discard the object, as the Class-Number is of the form 10bbbbbb, and
revert to recovery processing as defined in [RFC3473]. The revert to recovery processing as defined in [RFC3473]. The
restarting node will not include the Capability object in its Hello restarting node will not include the Capability object in its Hello
messages. Hence, all downstream RSVP neighbors detect that the messages. Hence, all downstream RSVP neighbors that detect that the
restarting node is not capable of supporting the extensions defined restarting node is not capable of supporting the extensions defined
in this document, will not send the RecoveryPath messages to the in this document will not send the RecoveryPath messages to the
restarting node, and, will revert to recovery processing as defined restarting node and will revert to recovery processing as defined in
in [RFC3473]. [RFC3473].
If a downstream RSVP neighbor does not support the Capability object, If a downstream RSVP neighbor does not support the Capability object,
it will discard the object received in Hello messages and revert to it will discard the object received in Hello messages and revert to
recovery processing as defined in [RFC3473]. The downstream RSVP recovery processing as defined in [RFC3473]. The downstream RSVP
neighbor will not include the Capability object in its Hello neighbor will not include the Capability object in its Hello
messages. Hence, the restarting node will detect that the downstream messages. Hence, the restarting node will detect that the downstream
RSVP neighbor is not capable of supporting the extensions defined in RSVP neighbor is not capable of supporting the extensions defined in
this document, and, will revert to recovery processing as defined in this document and will revert to recovery processing as defined in
[RFC3473]. [RFC3473].
5. RecoveryPath Summary Refresh 5. RecoveryPath Summary Refresh
This section describes a mechanism to control which LSP state is This section describes a mechanism to control which LSP state is
communicated in RecoveryPath messages. This mechanism enhances the communicated in RecoveryPath messages. This mechanism enhances the
Summary Refresh mechanism defined in [RFC2961], and uses the Summary Refresh mechanism defined in [RFC2961], and uses the
RecoveryPath Srefresh Capable (S) bit in the Capability object as RecoveryPath Srefresh Capable (S) bit in the Capability object, as
defined in Section 4.2, carried in the Hello message defined in defined in Section 4.2, carried in the Hello message defined in
[RFC3209] and [RFC3473]. The described mechanism is referred to as [RFC3209] and [RFC3473]. The described mechanism is referred to as
RecoveryPath Summary Refresh. RecoveryPath Summary Refresh.
Selective transmission of RecoveryPath messages is controlled much Selective transmission of RecoveryPath messages is controlled much
the same way transmission of Path or Resv messages is controlled with the same way transmission of Path or Resv messages is controlled with
standard Summary Refresh, see [RFC2961]. In standard Summary standard Summary Refresh, see [RFC2961]. In standard Summary
Refresh, an Srefresh message is sent by a node to identify to its Refresh, an Srefresh message is sent by a node to identify to its
neighbor about Path and Resv state that is locally installed and neighbor about Path and Resv state that is locally installed and
available. The receiver of the Srefresh message, can then attempt to available. The receiver of the Srefresh message can then attempt to
locate matching Path and Resv state. If no matching state is found, locate matching Path and Resv state. If no matching state is found,
the receiver can request that the missing state be sent to it, by the receiver can request that the missing state be sent to it by
sending an Srefresh NACK to the sender of the Srefresh message. When sending an Srefresh NACK to the sender of the Srefresh message. When
the Srefresh NACK is received, the corresponding Path or Resv message the Srefresh NACK is received, the corresponding Path or Resv message
is sent. MESSAGE_ID information is used to identify Path and Resv is sent. MESSAGE_ID information is used to identify Path and Resv
state in this process. state in this process.
The mechanism described in this section extends the Summary Refresh The mechanism described in this section extends the Summary Refresh
process to the Path state that can be represented in RecoveryPath process to the Path state that can be represented in RecoveryPath
messages. In this case, the Srefresh messages represent previously messages. In this case, the Srefresh messages represent previously
received Path messages, rather than previously transmitted Path received Path messages, rather than previously transmitted Path
messages. This is the primary difference between standard Summary messages. This is the primary difference between standard Summary
Refresh and RecoveryPath Summary Refresh described in this section. Refresh and RecoveryPath Summary Refresh described in this section.
When a node restarts, and is capable of supporting the mechanisms When a node restarts, and is capable of supporting the mechanisms
described in this section, it includes the Capability object with the described in this section, it includes the Capability object with the
RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh
Capable (S) bit set in Hello messages it sends to its RSVP neighbors. Capable (S) bit set in Hello messages it sends to its RSVP neighbors.
When a neighbor of the restarting node detects a restart, see When a neighbor of the restarting node detects a restart (see
[RFC3209], it detects that the restarted node is capable of receiving [RFC3209]), it detects that the restarted node is capable of
RecoveryPath messages as defined in Section 4.4, and that the receiving RecoveryPath messages, as defined in Section 4.4, and that
restarted node is requesting RecoveryPath Srefresh messages by the the restarted node is requesting RecoveryPath Srefresh messages by
the RecoveryPath Srefresh Capable (S) bit set in the Capability
RecoveryPath Srefresh Capable (S) bit set in the Capability object. object. When such an indication is found, the neighbor generates one
When such an indication is found, the neighbor generates one or more or more Srefresh messages. Each message indicates the Path state
Srefresh messages. Each message indicates the Path state that can be that can be represented in a RecoveryPath message. Within such
represented in a RecoveryPath message. Within such Srefresh Srefresh messages, the Path state that can be represented in
messages, Path state that can be represented in RecoveryPath messages RecoveryPath messages is represented using MESSAGE_ID information,
is represented using MESSAGE_ID information, and this information is and this information is communicated within MESSAGE_ID LIST objects.
communicated within MESSAGE_ID LIST objects. To indicate that the To indicate that the MESSAGE_ID LIST object is for recovery purposes,
MESSAGE_ID LIST object is for recovery purposes, a new flag is set in a new flag is set in the MESSAGE_ID LIST object. This flag is called
the MESSAGE_ID LIST object. This flag is called the RecoveryPath the RecoveryPath Flag and is defined below.
Flag and is defined below.
The restarted node can then use the Srefresh message and the The restarted node can then use the Srefresh message and the
MESSAGE_ID LIST object to try to identify matching transmitted Path MESSAGE_ID LIST object to try to identify matching transmitted Path
state. The node identifies local state by matching Epoch and Message state. The node identifies local state by matching Epoch and Message
ID tuples against Path messages transmitted downstream prior to the ID tuples against Path messages transmitted downstream prior to the
restart. restart.
If matching state is located, then the restarted node operates as if If matching state is located, then the restarted node operates as if
a RecoveryPath message has been received, per Section 4.5.2. If no a RecoveryPath message has been received, per Section 4.5.2. If no
matching state can be located, the restarted node generates a matching state can be located, the restarted node generates a
Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is
also marked with the new RecoveryPath Flag to indicate that the NACK also marked with the new RecoveryPath Flag to indicate that the NACK
is related to RecoveryPath messages. is related to RecoveryPath messages.
Upon receiving a Srefresh NACK, the downstream node generates a Upon receiving a Srefresh NACK, the downstream node generates a
RecoveryPath message for the Path state indicated by each entry in RecoveryPath message for the Path state indicated by each entry in
the MESSAGE_ID LIST. The procedures defined above in Section 4 are the MESSAGE_ID LIST. The procedures defined in Section 4 above are
then followed by the restarted node and the downstream RSVP neighbor. then followed by the restarted node and the downstream RSVP neighbor.
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object,
defined in [RFC2961], are updated by this document. A new bit within defined in [RFC2961], are updated by this document. A new bit within
the existing Flags field of each object is defined. This bit the existing Flags field of each object is defined. This bit
indicates that the object carries MESSAGE_ID information related to indicates that the object carries MESSAGE_ID information related to
Path state that can be recovered using RecoveryPath messages. The Path state that can be recovered using RecoveryPath messages. The
same flag value is used in all the objects for consistency. same flag value is used in all the objects for consistency.
skipping to change at page 16, line 22 skipping to change at page 16, line 22
See Section 5.1 of [RFC2961] for definition of other fields. See Section 5.1 of [RFC2961] for definition of other fields.
Flags: 8 bits Flags: 8 bits
0x02: RecoveryPath Flag 0x02: RecoveryPath Flag
Indicates that the associated object carries MESSAGE_ID Indicates that the associated object carries MESSAGE_ID
information related to one or more Path messages that can be information related to one or more Path messages that can be
recovered using a RecoveryPath message. recovered using a RecoveryPath message.
5.2. RecoveryPath Srefresh Capable bit 5.2. RecoveryPath Srefresh Capable Bit
The Capability object and the RecoveryPath Srefresh Capable (S) bit The Capability object and the RecoveryPath Srefresh Capable (S) bit
are defined in Section 4.2. are defined in Section 4.2.
5.2.1. Procedures 5.2.1. Procedures
To support the selective receipt of RecoveryPath messages as defined To support the selective receipt of RecoveryPath messages as defined
in this section, a restarting node MUST support the receipt and in this section, a restarting node MUST support the receipt and
processing of RecoveryPath messages as defined in Section 4.5.2 and processing of RecoveryPath messages as defined in Section 4.5.2, and
MUST indicate this capability by including the Capability object with MUST indicate this capability by including the Capability object with
the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in
its Hello messages. its Hello messages.
To indicate to an RSVP neighbor that selective transmission of To indicate to an RSVP neighbor that selective transmission of
RecoveryPath messages is desired, a node MUST set (1) the S-bit in RecoveryPath messages is desired, a node MUST set (1) the S-bit in
the Capability object in all Hello messages it sends. When the the Capability object in all Hello messages it sends. When the
restarting node does not desire the receipt of RecoveryPath messages, restarting node does not desire the receipt of RecoveryPath messages
see Section 4.4.2, or, the selective transmission mechanism defined (see Section 4.4.2) or the selective transmission mechanism defined
in this section, it MUST clear (0) the S-bit in the Capability object in this section, it MUST clear (0) the S-bit in the Capability object
if included in Hello messages. if included in Hello messages.
The downstream RSVP neighbor checks the R-bit and the S-bit upon The downstream RSVP neighbor checks the R-bit and the S-bit upon
detecting a restart of a node that supports state recovery with detecting a restart of a node that supports state recovery with
RecoveryPath messages. Detection of neighbor restarts with state RecoveryPath messages. Detection of neighbor restarts with state
recovery using RecoveryPath messages is defined in Section 4. If recovery using RecoveryPath messages is defined in Section 4. If
both the R-bit and the S-bit are set, then the procedures defined both the R-bit and the S-bit are set, then the procedures defined
below in Section 5.3.1 MUST be followed. If the S-bit is cleared, below in Section 5.3.1 MUST be followed. If the S-bit is cleared,
the downstream RSVP neighbor MUST revert to normal procedures defined the downstream RSVP neighbor MUST revert to normal procedures defined
in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the
downstream RSVP neighbor MUST treat as if the Capability object was downstream RSVP neighbor MUST treat it as if the Capability object
received with the S-bit cleared. See Section 4.4 for handling of was received with the S-bit cleared. See Section 4.4 for handling of
Hello messages without the Capability object. Hello messages without the Capability object.
5.2.2. Compatibility 5.2.2. Compatibility
There are no compatibility issues introduced in the procedures There are no compatibility issues introduced in the procedures
defined in Section 5.2.1. defined in Section 5.2.1.
The restarting node will detect that its neighbor does not support The restarting node will detect that its neighbor does not support
selective transmission of RecoveryPath messages when a RecoveryPath selective transmission of RecoveryPath messages when a RecoveryPath
message is received prior to the receipt of a Srefresh message message is received prior to the receipt of a Srefresh message
skipping to change at page 17, line 36 skipping to change at page 17, line 39
o Message ID NACK receive processing and generation of RecoveryPath o Message ID NACK receive processing and generation of RecoveryPath
messages messages
o Receive processing of RecoveryPath messages o Receive processing of RecoveryPath messages
Actual processing MAY result in the above occurring in an interlaced Actual processing MAY result in the above occurring in an interlaced
fashion when multiple LSPs are being recovered. Both the restarted fashion when multiple LSPs are being recovered. Both the restarted
node and the downstream RSVP neighbor MUST be able to process in this node and the downstream RSVP neighbor MUST be able to process in this
fashion. fashion.
5.3.1. Generation of RecoveryPath-related Srefresh Messages 5.3.1. Generation of RecoveryPath-Related Srefresh Messages
A neighbor of a restarting node generates one or more RecoveryPath- A neighbor of a restarting node generates one or more RecoveryPath-
related Srefresh messages when the S-bit is set in the restarted related Srefresh messages when the S-bit is set in the restarted
node's Hello messages as described in Section 5.2.1. The procedures node's Hello messages as described in Section 5.2.1. The procedures
for generating an Srefresh message are defined in [RFC2961]. Only for generating an Srefresh message are defined in [RFC2961]. Only
modifications to these procedures are described in this section. modifications to these procedures are described in this section.
Also, Srefresh message transmit and receive processing may occur Also, Srefresh message transmit and receive processing may occur
simultaneously during the Recovery Period and are not impacted by the simultaneously during the Recovery Period and are not impacted by the
procedures defined in this section. procedures defined in this section.
To generate RecoveryPath-related Srefresh messages, a node must To generate RecoveryPath-related Srefresh messages, a node must
identify which Path state can be represented in RecoveryPath messages identify which Path state can be represented in RecoveryPath messages
and which Srefresh message or messages can be used to carry the and which Srefresh message or messages can be used to carry the
related information. As previously mentioned, the Path state that related information. As previously mentioned, the Path state that
can be represented in RecoveryPath messages is indicated in Srefresh can be represented in RecoveryPath messages is indicated in Srefresh
messages using the MESSAGE_ID information from the most recently messages using the MESSAGE_ID information from the most recently
received Path message associated with the state. received Path message associated with the state.
After processing the S-bit as described in Section 5.2.1, the node After processing the S-bit as described in Section 5.2.1, the node
identifies all state associated with Path messages received from the identifies all state associated with Path messages received from the
restarted neighbor. Only Path state that has not been updated since restarted neighbor. Only a Path state that has not been updated
the restart may be represented in the Srefresh messages. Received since the restart may be represented in the Srefresh messages.
Path state containing a MESSAGE_ID object whose Epoch value matches Received Path state containing a MESSAGE_ID object whose Epoch value
the Epoch received in the most recent Hello message is considered as matches the Epoch received in the most recent Hello message is
updated after the upstream neighbor has restarted. Such Path state considered as updated after the upstream neighbor has restarted.
MUST NOT be represented in the Srefresh messages. Each Srefresh Such Path state MUST NOT be represented in the Srefresh messages.
message contains one or more MESSAGE_ID LIST objects. Each such Each Srefresh message contains one or more MESSAGE_ID LIST objects.
MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1). Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set
(1).
Multiple MESSAGE_ID LIST objects MAY be included in order to Multiple MESSAGE_ID LIST objects MAY be included in order to
accommodate multiple Epoch values. The MESSAGE_ID LIST objects accommodate multiple Epoch values. The MESSAGE_ID LIST objects
represent the identified, non-updated, Path state. A represent the identified, non-updated, Path state. A
Message_Identifier field created for each identified, non-updated Message_Identifier field created for each identified, non-updated
Path state MUST be included in an appropriate MESSAGE_ID LIST object. Path state MUST be included in an appropriate MESSAGE_ID LIST object.
The Message_Identifier field is created based on the MESSAGE_ID The Message_Identifier field is created based on the MESSAGE_ID
object from the most recently received Path message associated with object from the most recently received Path message associated with
identified Path state. If any identified Path state does not have an identified Path state. If any identified Path state does not have an
associated MESSAGE_ID object, this state MUST be processed as defined associated MESSAGE_ID object, this state MUST be processed as defined
skipping to change at page 18, line 39 skipping to change at page 18, line 45
previously sent to the restarted node. The Srefresh message SHOULD previously sent to the restarted node. The Srefresh message SHOULD
be destined to the IP address in the HOP object in the corresponding be destined to the IP address in the HOP object in the corresponding
Path messages. This may result in multiple Srefresh messages being Path messages. This may result in multiple Srefresh messages being
generated. Per [RFC2961], implementations may choose to limit each generated. Per [RFC2961], implementations may choose to limit each
Srefresh message to the MTU size of the outgoing link, and to not Srefresh message to the MTU size of the outgoing link, and to not
bundle Srefresh messages. RecoveryPath-related Srefresh messages bundle Srefresh messages. RecoveryPath-related Srefresh messages
SHOULD be sent using reliable delivery, as defined in [RFC2961]. SHOULD be sent using reliable delivery, as defined in [RFC2961].
During the Recovery Period, unacknowledged RecoveryPath-related During the Recovery Period, unacknowledged RecoveryPath-related
Srefresh messages SHOULD be periodically transmitted. The Srefresh messages SHOULD be periodically transmitted. The
retransmission algorithm used can be same algorithm used for retransmission algorithm used can be the same algorithm used for
retransmitting RecoveryPath messages during the Recovery Period (see retransmitting RecoveryPath messages during the Recovery Period (see
Section 4.5.1). Note that prior to each such periodic Section 4.5.1). Note that prior to each such periodic
retransmission, the Srefresh message SHOULD be updated to exclude the retransmission, the Srefresh message SHOULD be updated to exclude the
Message ID's of Path state that has been updated by the receipt of a Message ID's of Path state that has been updated by the receipt of a
Path message. Path message.
To allow sufficient processing time for the restarted node, the To allow sufficient processing time for the restarted node, the
downstream RSVP neighbor MAY choose to generate multiple downstream RSVP neighbor MAY choose to generate multiple
RecoveryPath-related Srefresh messages containing partial but RecoveryPath-related Srefresh messages containing partial but
mutually exclusive sets of Message Identifiers spread across 1/4 of mutually exclusive sets of Message Identifiers spread across 1/4 of
the Recovery Time advertised by the restarted node. the Recovery Time advertised by the restarted node.
5.3.2. RecoveryPath-related Srefresh Receive Processing and NACK 5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK
Generation Generation
Upon receiving an Srefresh message containing a MESSAGE_ID LIST Upon receiving an Srefresh message containing a MESSAGE_ID LIST
object with the RecoveryPath Flag set), the restarted node attempts object with the RecoveryPath Flag set), the restarted node attempts
to locate matching previously transmitted Path state. The Epoch in to locate matching previously transmitted Path state. The Epoch in
the MESSAGE_ID LIST object along with each Message Identifier in the the MESSAGE_ID LIST object, along with each Message Identifier in the
object is used to match against the MESSAGE_ID object in Path object, is used to match against the MESSAGE_ID object in Path
messages previously transmitted to the downstream RSVP neighbor. For messages previously transmitted to the downstream RSVP neighbor. For
each Message Identifier in the MESSAGE_ID LIST: each Message Identifier in the MESSAGE_ID LIST:
If matching transmitted Path state is found, the restarting node If matching transmitted Path state is found, the restarting node
treats the corresponding LSP state as having received and treats the corresponding LSP state as having received and
processed a RecoveryPath message, and, perform any further processed a RecoveryPath message and perform any further
processing necessary as defined in Section 4.5.2. Specifically, processing necessary as defined in Section 4.5.2. Specifically,
it MUST generate a trigger Path message for the LSP as defined in it MUST generate a trigger Path message for the LSP as defined in
Section 4.5.2.2. The restarted node MAY spread the transmission Section 4.5.2.2. The restarted node MAY spread the transmission
of such trigger Path messages across 1/2 of the remaining Recovery of such trigger Path messages across 1/2 of the remaining Recovery
Period to allow the downstream RSVP neighbor sufficient processing Period to allow the downstream RSVP neighbor sufficient processing
time. time.
If matching transmitted Path state is not found, the restarting If matching transmitted Path state is not found, the restarting
node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. node MUST generate a MESSAGE_ID NACK as defined in [RFC2961].
Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set
(1). (1).
It is recommended that the restarted node combine multiple such It is recommended that the restarted node combine multiple such
MESSAGE_ID NACK's into a single ACK message, per [RFC2961]. MESSAGE_ID NACKs into a single ACK message, per [RFC2961].
5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive Processing 5.3.3. RecoveryPath-Related MESSAGE_ID NACK Receive Processing
This section defines the procedures associated with the processing of This section defines the procedures associated with the processing of
received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1). received MESSAGE_ID NACKs that have the RecoveryPath Flag set (1).
Procedures for processing of MESSAGE_ID NACK's without the Procedures for processing of MESSAGE_ID NACKs without the
RecoveryPath Flag present are defined in [RFC2961] and not modified RecoveryPath Flag present are defined in [RFC2961] and not modified
in this document. Processing of MESSAGE_ID NACK's with the in this document. Processing of MESSAGE_ID NACKs with the
RecoveryPath Flag set (1) also follows procedures defined in RecoveryPath Flag set (1) also follows procedures defined in
[RFC2961] unless explicitly modified in this section. [RFC2961] unless explicitly modified in this section.
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the
downstream RSVP neighbor must locate the matching received Path downstream RSVP neighbor must locate the matching received Path
message. If a matching Path message is found, the downstream RSVP message. If a matching Path message is found, the downstream RSVP
neighbor MUST generate a RecoveryPath message as defined in neighbor MUST generate a RecoveryPath message as defined in Section
Section 4.5.1. If a matching Path message is not found, the 4.5.1. If a matching Path message is not found, the MESSAGE_ID NACK
MESSAGE_ID NACK is ignored. An example where this may occur is when is ignored. An example where this may occur is when the restarted
the restarted node has already generated an updated Path message node has already generated an updated Path message after its restart.
after its restart.
6. Security Considerations 6. Security Considerations
This document introduces a new RSVP message that is restricted to one This document introduces a new RSVP message that is restricted to one
RSVP hop. This document introduces no new security considerations RSVP hop. This document introduces no new security considerations
beyond those already addressed for existing RSVP hop-by-hop messages. beyond those already addressed for existing RSVP hop-by-hop messages.
This document introduces a new RSVP object to be included in RSVP This document introduces a new RSVP object to be included in RSVP
Hello messages. This document introduces no new security Hello messages. This document introduces no new security
considerations beyond those already addressed for existing objects in considerations beyond those already addressed for existing objects in
skipping to change at page 20, line 26 skipping to change at page 20, line 30
This document introduces new procedures to be performed on RSVP This document introduces new procedures to be performed on RSVP
agents that neighbor a restarting RSVP agent. In situations where agents that neighbor a restarting RSVP agent. In situations where
the control plane in general, and the RSVP agent in particular, of a the control plane in general, and the RSVP agent in particular, of a
node carrying one or more LSPs is restarted due to external attacks, node carrying one or more LSPs is restarted due to external attacks,
the procedures introduced in this document provide the ability for the procedures introduced in this document provide the ability for
the restarting RSVP agent to recover the RSVP state corresponding to the restarting RSVP agent to recover the RSVP state corresponding to
the LSPs with the least possible perturbation to the rest of the the LSPs with the least possible perturbation to the rest of the
network. Ideally, only the neighboring RSVP agents should notice the network. Ideally, only the neighboring RSVP agents should notice the
restart and hence need to perform additional processing. This allows restart and hence need to perform additional processing. This allows
for a network with active LSPs to recover LSP state gracefully from for a network with active LSPs to recover LSP state gracefully from
an external attack, without perturbing the data/forwarding plane an external attack without perturbing the data/forwarding plane
state. state.
[RFC2747] provides mechanisms to protect against external agents [RFC2747] provides mechanisms to protect against external agents
compromising the RSVP signaling state in an RSVP agent. These compromising the RSVP signaling state in an RSVP agent. These
mechanisms, when used with the new message and procedures introduced mechanisms, when used with the new message and procedures introduced
in this document, provide the same degree of protection to the in this document, provide the same degree of protection to the
restarting RSVP agent, against installing compromised signaling state restarting RSVP agent against installing compromised signaling state
from an external agent during its RSVP signaling state recovery. from an external agent during its RSVP signaling state recovery.
Note that the procedures assume a full trust model between RSVP Note that the procedures assume a full trust model between RSVP
neighbors. That is, although the protocol exchanges before and after neighbors. That is, although the protocol exchanges before and after
restart can be secured, and although it is possible to authenticate restart can be secured, and although it is possible to authenticate
the identity of the neighbors, no mechanism is provided to verify the identity of the neighbors, no mechanism is provided to verify
that the restart information is correctly mapped from the protocol that the restart information is correctly mapped from the protocol
information exchanged before the restart. This is considered information exchanged before the restart. This is considered
acceptable because a similar trust model is required for normal acceptable because a similar trust model is required for normal
operation of the protocol. operation of the protocol.
The procedures defined in this document introduce additional The procedures defined in this document introduce additional
processing overhead for the RSVP agents that neighbor a restarting processing overhead for the RSVP agents that neighbor a restarting
RSVP agent. If an RSVP agent restarts due to external attacks, such RSVP agent. If an RSVP agent restarts due to external attacks, such
added processing on the neighboring RSVP agents may impact their added processing on the neighboring RSVP agents may impact their
ability to perform other control plane tasks including any processing ability to perform other control plane tasks, including any
for other LSPs that do not involve the restarting node. Such impact processing for other LSPs that do not involve the restarting node.
can be minimalized by the restarting RSVP agent using a large enough Such impact can be minimalized by the restarting RSVP agent using a
Recovery Time, so that its neighbors are provided sufficient time to large enough Recovery Time, so that its neighbors are provided
handle the additional processing involved while continuing to perform sufficient time to handle the additional processing involved while
their other control plane functions normally during the Recovery continuing to perform their other control plane functions normally
Period. during the Recovery Period.
Note that the procedures defined in this document cannot be used to Note that the procedures defined in this document cannot be used to
create false forwarding state. The restarting node that receives a create false forwarding state. The restarting node that receives a
RecoveryPath message that does not match the existing forwarding RecoveryPath message that does not match the existing forwarding
state MUST NOT create or modify its forwarding state to match. A state MUST NOT create or modify its forwarding state to match. A
restarting node SHOULD log such an event or otherwise notify the restarting node SHOULD log such an event or otherwise notify the
operator since it might represent an attack. operator since it might represent an attack.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank participants of the CCAMP WG for The authors would like to thank participants of the CCAMP WG for
comments and suggestions. Also thanks to Arthi Ayyangar, Adrian comments and suggestions. Also thanks to Arthi Ayyangar, Adrian
Farrel, Nick Neate and Pavan Beeram for their helpful comments and Farrel, Nick Neate, and Pavan Beeram for their helpful comments and
feedback. feedback.
Derek Atkins provided useful discussion during SecDir review. Sam Derek Atkins provided useful discussion during SecDir review. Sam
Hartman gave careful scrutiny of the security considerations and Hartman gave careful scrutiny of the security considerations and the
the potential impact on the RSVP-TE security trust model. potential impact on the RSVP-TE security trust model.
Adrian Farrel edited the final revisions of this document as it Adrian Farrel edited the final revisions of this document as it
progressed through IESG review. progressed through IESG review.
8. IANA Considerations 8. IANA Considerations
[RFC2205] defines the Class-Number name space for RSVP objects. The [RFC2205] defines the Class-Number name space for RSVP objects. The
name space is managed by IANA. name space is managed by IANA.
A new RSVP object using a Class-Number of form 10bbbbbb called the A new RSVP object using a Class-Number of form 10bbbbbb called the
Capability Object is defined in Section 4.2 in this document. The Capability Object is defined in Section 4.2 in this document. The
Class-Number is TBA by IANA. A value of 132 is suggested. Class-Number is 134.
A new RSVP message type called a RecoveryPath message is defined in A new RSVP message type called a RecoveryPath message is defined in
Section 4.1 of this document. The RSVP message type is TBA by IANA. Section 4.1 of this document. The RSVP message type is 30.
A value of 30 is suggested.
This document creates a new name space in the Capability object This document creates a new name space in the Capability object
defined in Section 4.2. The new name space is a 32 bit-wide field. defined in Section 4.2. The new name space is a 32-bit-wide field.
New registrations in this name space are to be allocated by IANA New registrations in this name space are to be allocated by IANA
through an IETF Consensus action, per [RFC2434]. IANA also serves as through an IETF Consensus action, per [RFC2434]. IANA also serves as
the repository for this name space. the repository for this name space.
Section 4.2 defines the following bits in the 32-bit field of the Section 4.2 defines the following bits in the 32-bit field of the
Capability Object, TBA by IANA: Capability Object (134):
RecoveryPath Transmit Enabled (T): 1 bit RecoveryPath Transmit Enabled (T): 1 bit
RecoveryPath Desired (R): 1 bit RecoveryPath Desired (R): 1 bit
RecoveryPath Srefresh Capable (S): 1 bit RecoveryPath Srefresh Capable (S): 1 bit
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 22, line 37 skipping to change at page 23, line 5
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Authors' Addresses Editors' Addresses
Arun Satyanarayana (editor) Arun Satyanarayana (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853-3206 Phone: +1 408 853 3206
EMail: asatyana@cisco.com EMail: asatyana@cisco.com
Reshad Rahman (editor) Reshad Rahman (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3519 Phone: 613 254 3519
EMail: rrahman@cisco.com EMail: rrahman@cisco.com
Authors' Addresses
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Email: dimitri.Papadimitriou@alcatel-lucent.be
Phone: +32 3 240-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel-lucent.be
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1 301 468-9228 Phone: +1 301 468 9228
EMail: lberger@labn.net EMail: lberger@labn.net
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3484 Phone: 613 254 3484
EMail: ancaz@cisco.com EMail: ancaz@cisco.com
Junaid Israr Junaid Israr
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3693 Phone: 613 254 3693
EMail: jisrar@cisco.com EMail: jisrar@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 24, line 28 skipping to change at line 1102
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.32pre3 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
 End of changes. 98 change blocks. 
247 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/