< draft-aruns-ccamp-rsvp-restart-ext-00.txt   draft-aruns-ccamp-rsvp-restart-ext-01.txt >
Network Working Group Arun Satyanarayana (Movaz Networks)
Internet Draft Lou Berger (Movaz Networks)
Expiration Date: August 2004 Dimitri Papadimitriou (Alcatel)
February 2004 Network Working Group A. Satyanarayana (Movaz Networks)
Internet Draft R. Rahman (Cisco Systems)
Expiration Date: January 2005 Editors
July 2004
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-aruns-ccamp-rsvp-restart-ext-00.txt draft-aruns-ccamp-rsvp-restart-ext-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html.
Directory, see http://www.ietf.org/shadow.html.
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 RSVP Graceful Restart
defined in [RFC3473]. The extensions enable the recovery of RSVP mechanisms defined in [RFC3473]. The extensions enable the recovery
signaling state based on the Path message last sent by the node being of RSVP signaling state based on the Path message last sent by the
restarted. Previously defined Graceful Restart mechanisms, also node being restarted. Previously defined Graceful Restart
called nodal faults, permit recovery of signaling state from adjacent mechanisms, also called recovery from nodal faults, permit recovery
nodes when the data plane has retained the associated forwarding of signaling state from adjacent nodes when the data plane has
state across a restart. These mechanisms do not fully support retained the associated forwarding state across a restart. These
recovery of ingress nodes or recovery of all RSVP objects. The mechanisms do not fully support signaling state recovery on ingress
presented extensions use the RSVP Hello Extensions defined in nodes or recovery of all RSVP objects. The presented extensions use
[RFC3209], and extensions for state recovery on nodal faults defined the RSVP Hello extensions defined in [RFC3209], and extensions for
in [RFC3473]. With the presented extensions the restarting node can state recovery on nodal faults defined in [RFC3473]. With the
recover all previously transmitted Path state including the ERO and presented extensions the restarting node can recover all previously
the downstream (outgoing) interface identifiers. The extensions can transmitted Path state including the ERO and the downstream
also be used to recover signaling state after the restart of an (outgoing) interface identifiers. The extensions can also be used to
ingress node. recover signaling state after the restart of an ingress node. The
extensions optionally support the use of Summary Refresh, defined in
[RFC2961], to reduce the number of messages exchanged during the
Recovery Phase when the restarting node has recovered signaling state
locally for one or more LSP's.
Contents Contents
1 Introduction ................................................ 3 1 Introduction .............................................. 4
2 Extensions to Nodal Fault Handling .......................... 4 2 Extensions to Nodal Fault Handling ........................ 6
2.1 RecoveryPath Message Format ................................. 4 2.1 RecoveryPath Message Format ............................... 6
2.2 Related Procedures .......................................... 5 2.2 Related Procedures ........................................ 6
2.3 Procedures For The Downstream Neighbor ...................... 5 2.3 Procedures For The Downstream Neighbor .................... 7
2.4 Procedures for the Restarting Node .......................... 6 2.4 Procedures for the Restarting Node ........................ 8
3 Compatibility notes ......................................... 9 2.4.1 Path and RecoveryPath Message Procedures .................. 8
4 Security Considerations ..................................... 9 2.4.2 Re-Synchronization Procedures ............................. 9
5 IANA Considerations ......................................... 9 2.4.3 Procedures on Expiration of Recovery Period ............... 10
6 References .................................................. 9 2.5 Compatibility ............................................. 10
6.1 Normative References ........................................ 9 3 RecoveryPath Summary Refresh .............................. 11
7 Authors' Addresses .......................................... 10 3.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ........... 12
8 Full Copyright Statement .................................... 10 3.2 Capability Object ......................................... 13
3.2.1 Procedures ................................................ 13
3.2.2 Compatibility ............................................. 14
3.3 RecoveryPath Summary Refresh Procedures ................... 14
3.3.1 Generation of RecoveryPath-related Srefresh Messages ...... 14
3.3.2 RecoveryPath-related Srefresh Receive Processing and NACK Generation 16
3.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing ... 16
4 Acknowledgments ........................................... 17
5 Security Considerations ................................... 17
6 IANA Considerations ....................................... 17
7 References ................................................ 17
7.1 Normative References ...................................... 17
7.2 Informative References .................................... 18
8 Authors' Addresses ........................................ 18
9 Intellectual Property Considerations ...................... 19
10 IPR Disclosure Acknowledgement ............................ 20
11 Full Copyright Statement .................................. 20
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. 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]. [RFC3209] describes a mechanism, using RSVP defined in [RFC3209]. [RFC3209] describes a mechanism, using RSVP
Hello messages, to detect the state of an adjacent RSVP signaling Hello messages, to detect the state of an adjacent RSVP agent.
process. [RFC3473] extends this mechanism to advertise the [RFC3473] extends this mechanism to advertise the capability of
capability of retaining data plane state across the restart of a node retaining data / forwarding plane state across the restart of a node
or a "nodal fault". [RFC3473] also defines the Recovery Label object or 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 restart not previously supported. The presented extensions enable a
the recovery of an ERO previously transmitted by a restarting node, restarting node to recover all objects in previously transmitted Path
from its downstream neighbor. The extensions also enable graceful messages including the ERO, from its downstream neighbors. The
restart of an ingress node that does not preserve full control plane extensions also enable graceful restart of an ingress node that does
state across restarts. not preserve full RSVP state across restarts.
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, the Label object. To determine the downstream (outgoing) interface and
restarting node must consult the data plane. This may not be associated label(s), the restarting node must consult the data plane.
possible for all types of nodes. Furthermore, data plane information This may not be possible for all types of nodes. Furthermore, data
is not sufficient to reconstruct EROs in many cases. The restarting plane information is not sufficient to reconstruct all previously
node may have previously performed some form of path computation on transmitted Path state. In these cases, the only source of RSVP
the received ERO, such as ERO expansion to a loose next hop or a state is the downstream RSVP neighbor.
partial path computation up to the Egress node if an ERO was not
received. If the restarting node is an ingress node, it may have
performed a full path computation as part of the LSP setup process.
The restarting node has to recover the ERO it had sent in its Path
message prior to the restart, so that it can continue to include the
same ERO in its Path messages after the restart. If the restarting
node is an ingress node, the only source of RSVP state is the
downstream RSVP neighbor.
The defined extensions provide a restarting upstream node with For example, when the restarting node is an ingress node, all
previously transmitted Path state may need to be recovered. Such
Path state may include (but is not restricted to) the Protection
object, the Admin Status object, the Session Attribute object, the
Notify Request object, the Sender Tspec object. A restarting transit
node may have modified received Path state in its previously
transmitted Path message, which cannot be reconstructed internally
during recovery.
Another example of state that cannot be completely recovered from the
data plane in some cases is the previously transmitted ERO. Recovery
of the previously transmitted ERO is minimizes subsequent change of
downstream LSP state. On a restarting ingress node, the ERO may have
been based on configuration or the result of a previous path
computation. A restarting transit node may have previously performed
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
restarting node may have modified other received Path state in its
previously transmitted Path state, which cannot be reconstructed
internally during recovery.
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, after This is accomplished by the downstream RSVP neighbor, after
reestablishing RSVP communication with the restarted node, sending a reestablishing RSVP communication with the restarted node, sending a
new message for every Path message it has previously received from new message for every Path message it has previously received from
the restarting node. the restarting node.
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.
If the restarting node is a transit node for an LSP being recovered, If the restarting node is a transit node, it will receive a Path
it will receive a Path message with a Recovery Label object from its message with a Recovery Label object from its upstream RSVP neighbor.
upstream RSVP neighbor. Additionally, the RecoveryPath message In addition, the RecoveryPath message allows such transit nodes to
allows such transit nodes to reconstruct any state that was reconstruct any state that was previously dynamically constructed by
previously dynamically constructed by the node, e.g., ERO sub- the node, e.g., ERO sub-objects. If the restarting node is an
objects. If the restarting node is an ingress node, all significant ingress node, all significant signaling state can be recovered based
signaling state can be recovered based on the RecoveryPath message. on the RecoveryPath message.
Selective transmission of the RecoveryPath message is supported by
enhancing the Summary Refresh mechanisms defined in [RFC2961]. When
Recovery Summary Refresh is supported, the restarting node can select
the LSP's for which it would like to receive RecoveryPath messages.
This is useful when the restarting node is able to locally recover
the signaling state for a subset of the previously active LSP's.
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. Extensions to Nodal Fault Handling 2. 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].
2.1. RecoveryPath Message Format 2.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]: Path message as defined in [RFC3473]:
<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 sent by the sending header of the corresponding Resv message last generated by the
node. Except as specified below all objects in a RecoveryPath sending node. Except as specified below all objects in a
message are identical to the objects in the corresponding Path RecoveryPath message are identical to the objects in the
message last received by the sending node. corresponding Path message last received by the sending node.
2.2. Related Procedures 2.2. 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_Caps object in the RSVP Hello messages as defined in Restart_Caps object in RSVP Hello messages as defined in [RFC3473].
[RFC3473]. The procedures for control channel faults are defined in The procedures for control channel faults are defined in [RFC3473]
[RFC3473] and are not changed by this document. and are not changed by this document.
The presented extensions requires the use of RSVP Hellos as defined The presented extensions require the use of RSVP Hellos as defined in
in [RFC3209] and the use of the Restart_Caps object extension as [RFC3209] and the use of the Restart_Caps object extension as defined
defined in [RFC3473]. The presented extensions addresses only "Nodal in [RFC3473]. The presented extensions address only "Nodal Faults"
Faults" as defined in [RFC3473]. Control channel faults are fully as defined in [RFC3473]. Control channel faults are fully addressed
addressed in [RFC3473]. 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.
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.
2.3. Procedures For The Downstream Neighbor 2.3. 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 and is capable of recovery, as defined in [RFC3473], has restarted and is capable of recovery as defined in [RFC3473], the
the downstream RSVP neighbor MUST send a RecoveryPath message for downstream RSVP neighbor MUST send a RecoveryPath message for each
each LSP associated with the restarting node for which it has sent a LSP associated with the restarting node for which it has sent a Resv
Resv message. message.
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 object is not copied. Any Message ID objects used The MESSAGE_ID object is not copied. Any MESSAGE_ID objects used
in RecoveryPath messages are generated based on procedures defined in RecoveryPath messages are generated based on procedures defined
in [RFC2961]. 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 within approximately 1/2 of
the Recovery Time advertised by the restarted neighbor. If there are
many LSP's to be recovered by the restarted node, the downstream RSVP
neighbor should avoid sending RecoveryPath messages in a short time
interval, to avoid overloading the restarted node's CPU. Instead it
should spread the messages across 1/2 the Recovery Time interval.
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 re-send the RecoveryPath message until
it receives a corresponding response. A corresponding response is a it receives a corresponding response. A corresponding response is a
Message ID acknowledgment or a Path message matching the RecoveryPath Message ID acknowledgment or a Path message matching the RecoveryPath
message. Note, per [RFC3473], Resv messages are suppressed during message. Note, per [RFC3473], Resv messages are suppressed during
this recovery period until a corresponding Path message is received. this recovery period until a corresponding Path message is received.
2.4. Procedures for the Restarting Node 2.4. 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 in [RFC3473]. Any
RecoveryPath message received after the Recovery Period has expired RecoveryPath message received after the Recovery Period has expired
MUST be discarded. A node MAY send a PathTear message downstream MUST be discarded. A node MAY send a PathTear message downstream
matching the discarded message. matching the discarded 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 ingress node SHOULD consider mechanisms defined in this document. The restarting node SHOULD
signaling state as resynchronized for all such LSPs and follow consider signaling state as resynchronized for all such LSPs and
corresponding procedures defined below. Further, recovery procedures follow corresponding procedures defined below. Further, recovery
defined below may be overridden by local policy. procedures defined below may be overridden by local policy.
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.
2.4.1. Path and RecoveryPath Message Processing Related Procedures 2.4.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 a associated with the message. If there is resynchronized state, and
Message ID object is present in the RecoveryPath message, the node when both reliable message delivery [RFC2961] is supported and a
MUST follow Message ID acknowledgement procedures as defined in MESSAGE_ID object is present in the RecoveryPath message, the node
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, the node MAY resynchronized state, and, there is no MESSAGE_ID object or reliable
send a triggered Path message, and, consider the message as message delivery [RFC2961] is not supported, the node SHOULD send a
processed. triggered Path message, and, consider the message as processed.
If non-resynchronized state is found or the node is the ingress, the If non-resynchronized state is found or the node is the ingress, the
node saves the information contained in the RecoveryPath message and node saves the information contained in the RecoveryPath message and
continues with processing as defined in the next section. continues with processing as defined in Section 2.4.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 checks if it has an RSVP state associated with the node first locates any RSVP state associated with the message. If
message. If resynchronized RSVP state is found, then the node resynchronized RSVP state is found, then the node handles this
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 non-resynchronized state is found, the node saves the information
contained in Recovery_Label object and continues with processing as contained in the Path message including the Recovery_Label object and
defined in the next section. continues with processing as defined in Section 2.4.2.
Per [RFC3473], if the RSVP state is not found, and the message does Per [RFC3473], if matching RSVP state is not found, and the message
not carry a Recovery_Label object, the node treats this as a setup does not carry a Recovery_Label object, the node treats this as a
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 the RSVP state is not found, and the message carries a If 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 Recovery_Label object for later use. the Path message including the Recovery_Label object for later use.
2.4.2. Re-Synchronization Procedures 2.4.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:
The upstream data interface is recovered from the received RSVP The upstream data interface is recovered from the RSVP HOP object
HOP object in the Path message. in the received Path message.
The label on the upstream data interface is recovered from the The label on the upstream data interface is recovered from the
Recovery Label object in the received Path message. If the LSP is Recovery Label object in the received Path message. If the LSP is
bidirectional, the label for the reverse direction is recovered bidirectional, the label for the upstream direction is recovered
from the Upstream Label object in the received Path message. from the Upstream Label object in the received Path message.
The downstream data interface is recovered from the RSVP HOP The downstream data interface is recovered from the RSVP HOP
object in the received RecoveryPath message. object in the received RecoveryPath message.
The label on the downstream data interface is recovered from the The label on the downstream data interface is recovered from the
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 reverse 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 triggered Path treat the LSP as resynchronized and MUST send a triggered Path
message downstream. The Explicit Route object in the Path message message downstream. The Explicit Route object in the Path message
SHOULD match the Explicit Route object received RecoveryPath message. SHOULD match the Explicit Route object received in the RecoveryPath
In addition, a node SHOULD recover state from the other objects message. In addition, the restarted node SHOULD recover state from
received in the RecoveryPath message. The optimal result is for the the other objects received in the RecoveryPath message. The optimal
resulting Path message to not cause any redundant or unnecessary re- result is for the resulting Path message to not cause any redundant
processing of state along the remaining downstream nodes. Ideally, or unnecessary re-processing of state along the remaining downstream
except for Message Id processing and recovery processing, the nodes. Ideally, except for MESSAGE_ID processing and recovery
transmitted Path message will be treated as a refresh by the processing, the transmitted Path message will be treated as a refresh
downstream RSVP neighbor (and hence should not trigger any generation by the 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 path message If no forwarding state is located, the node treats the path message
as a setup for a new LSP. The outgoing interface and label(s) as a setup for a new LSP. The outgoing interface and label(s)
indicated in the RecoveryPath message SHOULD be reused, when 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. message MAY also be used.
2.4.3. Procedures on Expiration of Recovery Period 2.4.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 a resulted of a received RecoveryPath message and is not installed as the result of a received RecoveryPath message that is
resynchronized SHOULD be discarded. not resynchronized SHOULD be discarded.
Any received Path messages that were received containing a Any Path messages that were received containing a Recovery_Label that
Recovery_Label have not been resynchronized, SHOULD be treated as have not been resynchronized, SHOULD be treated as being received
being received during the Recovery Period and processed as per during the Recovery Period and processed as per [RFC3473].
[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.
3. Compatibility notes 2.5. Compatibility
This document introduces a new RSVP signaling message to be generated This document introduces a new RSVP signaling message to be generated
by the downstream RSVP neighbor of a restarting node. by the downstream RSVP neighbor of a restarting node.
If the restarting node does not support the RecoveryPath message and If the restarting node does not support the RecoveryPath message and
associated procedures, it will discard all received RecoveryPath associated procedures, it will discard all received RecoveryPath
messages, and revert to recovery processing as defined in [RFC3473]. messages, and revert to recovery processing as defined in [RFC3473].
If the downstream RSVP neighbor does not support the RecoveryPath If the downstream RSVP neighbor does not support the RecoveryPath
message and associated procedures, the restarting node processes message and associated procedures, the restarting node processes
received Path messages as defined above, which essentially reverts received Path messages as defined in Section 2.4.3, which essentially
to the processing defined in [RFC3473]. reverts to the processing defined in [RFC3473].
4. Security Considerations 3. RecoveryPath Summary Refresh
This section describes a mechanism to control which LSP state is
communicated in RecoveryPath messages. This mechanism enhances the
Summary Refresh mechanism defined in [RFC2961], and uses a new object
carried in the Hello message defined in [RFC3209] and [RFC3473]. The
described mechanism is referred to as RecoveryPath Summary Refresh.
Selective transmission of RecoveryPath messages is controlled much
the same way transmission of Path or Resv messages is controlled with
standard Summary Refresh, see [RFC2961]. In standard Summary
Refresh, an Srefresh message is sent by a node to identify to its
neighbor about Path and Resv state that is locally installed and
available. The receiver of the Srefresh message, can then attempt to
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
sending an Srefresh NACK to the sender of the Srefresh message. When
the Srefresh NACK is received, the corresponding Path or Resv message
is sent. MESSAGE_ID information is used to identify Path and Resv
state in this process.
The mechanism described in this section extends the Summary Refresh
process to the Path state that can be represented in RecoveryPath
messages. In this case, the Srefresh messages represent previously
received Path messages, rather than previously transmitted Path
messages. This is the primary difference between standard Summary
Refresh and RecoveryPath Summary Refresh described in this section.
When a node restarts, and is capable of supporting the mechanisms
described in this section, it includes a new object in Hello messages
it sends to its RSVP neighbors. The new object is defined below in
Section 3.2 and is called the Capability object. A bit carried
within the Capability object indicates when a restarting node desires
its downstream neighbor to use the mechanisms described in this
section. This bit is called the RecoveryPath Srefresh Capable bit.
When a neighbor of the restarting node detects a restart, see
[RFC3209], it detects that the restarted node is requesting
RecoveryPath Srefresh messages by the presence of the Capability
object with the RecoveryPath Srefresh Capable bit set. When such an
indication is found, the neighbor generates one or more Srefresh
messages. Each message indicates the Path state that can be
represented in a RecoveryPath message. Within such Srefresh
messages, Path state that can be represented in RecoveryPath messages
is represented using MESSAGE_ID information, and this information is
communicated within MESSAGE_ID LIST objects. To indicate that the
MESSAGE_ID LIST object is for recovery purposes, a new flag is set in
the MESSAGE_ID LIST object. This flag is called the RecoveryPath
Flag and is defined below.
The restarted node can then use the Srefresh message and the
MESSAGE_ID LIST object to try to identify matching transmitted Path
state. The node identifies locate state by matching Epoch and
Message ID tuples against Path messages transmitted downstream prior
to the restart.
If matching state is located, then the restarted node operates as if
a RecoveryPath message has been received, per Section 2.4. If no
matching state can be located, the restarted node generates a
Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is
also marked with the new RecoveryPath Flag to indicate that the NACK
is related to RecoveryPath messages.
Upon receiving a Srefresh NACK, the downstream node generates a
RecoveryPath message for the Path state indicated by each entry in
the MESSAGE_ID LIST. The procedures defined above in Section 2 are
then followed by the restarted node and the downstream RSVP neighbor.
3.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object,
defined in [RFC2961], are updated by this document. A new bit within
the existing Flags field of each object is defined. This bit
indicates that the object carries MESSAGE_ID information related to
Path state that can be recovered using RecoveryPath messages. The
same flag value is used in all the objects for consistency.
MESSAGE_ID_ACK object
MESSAGE_ID_NACK object
See Section 4.3 of [RFC2961] for definition of other fields.
MESSAGE_ID LIST object
See Section 5.1 of [RFC2961] for definition of other fields.
Flags: 8 bits
0x02: RecoveryPath Flag
Indicates that the associated object carries MESSAGE_ID
information related to one or more Path messages that can be
recovered using a RecoveryPath message.
3.2. Capability Object
Capability objects are carried in RSVP Hello messages. The
Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type
of 1.
The message format of a Hello message is modified to be:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ]
The format of a Capability object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Srefresh Capable (R): 1 bit
When set (1), indicates that the sending node is capable of
receiving and processing Srefresh messages with the
RecoveryPath Flag set (1) in the MESSAGE_ID LIST object.
Absence of the Capability object MUST be treated as if the R-
bit is cleared (0).
3.2.1. Procedures
The Capability object is sent within a Hello message to indicate that
a node supports selective transmission of RecoveryPath messages. To
indicate to a neighbor that selective transmission of RecoveryPath
messages is desired, a restarting node MUST include the Capability
object with the R-bit set (1) in all Hello messages it sends during
the Recovery Period to the neighbor. When either the Restart_Cap
Object is not present in a Hello message or when the Recovery Time is
zero (0), the Capability object MUST be omitted or the R-bit MUST be
cleared (0).
On the downstream neighbor, the R-bit is checked upon detecting a
restart of a neighbor that supports state recovery. Detection of
neighbor restarts with state recovery is defined in [RFC3473]. When
a node supports RecoveryPath Summary Refresh, and it detects a
restart of a neighbor that supports state recovery, it MUST check to
see if the received Hello message contains a Capability object with
the R-bit set. If the R-bit is set, then the procedures defined
below in Section 3.3.1 MUST be followed. If the Capability object is
not found or the R-bit not set, then the node MUST revert to normal
recovery procedures as defined above in Section 2.3.
3.2.2. Compatibility
There are no compatibility issues introduced in this section. The
use of the Capability object will not cause any issues on a non-
supporting receiver as it uses a Class-Number of form 10bbbbbb. The
object will simply be ignored, and normal processing will continue.
Normal processing includes procedures defined above in Section 2, in
[RFC3473] and in [RFC3209].
The sender of the Capability object will detect that its neighbor
does not support selective transmission of RecoveryPath messages when
a RecoveryPath message is received prior to the receipt of a Srefresh
message containing a MESSAGE_ID LIST object with the RecoveryPath
Flag set (1). When this occurs, any received RecoveryPath messages
MUST be processed as defined above in Section 2.
3.3. RecoveryPath Summary Refresh Procedures
Related processing occurs in the following logical order:
o Generation of RecoveryPath-related Srefresh messages
o RecoveryPath-related Srefresh message receive processing and NACK
generation
o Message ID NACK receive processing and generation of
RecoveryPath messages
o Receive processing of RecoveryPath messages
Actual processing MAY result in the above occurring in an interlaced
fashion when multiple LSP's are being recovered. Both the restarted
node and the downstream RSVP neighbor MUST be able to process in this
fashion.
3.3.1. Generation of RecoveryPath-related Srefresh Messages
A neighbor of a restarting node generates one or more RecoveryPath-
related Srefresh messages when the R-bit is set in the restarted
node's Hello messages as described above in Section 3.2.1. The
procedures for generating an Srefresh message are defined in
[RFC2961]. Only modifications to these procedures are described in
this section.
To generate RecoveryPath-related Srefresh messages, a node must
identify which Path state can be represented in RecoveryPath messages
and which Srefresh message or messages can be used to carry the
related information. As previously mentioned, the Path state that
can be represented in RecoveryPath messages is indicated in Srefresh
messages using the MESSAGE_ID information from the most recently
received Path message associated with the state.
After processing the R-bit as described in Section 3.2.1, the node
identifies all state associated with Path messages received from the
restarted neighbor. Only Path state that has not been updated since
the restart may be represented in the Srefresh messages. Path state
that has been updated when a Path message is received with a
MESSAGE_ID which contains an Epoch value that matches the Epoch
received in the most recent Hello message. Such Path state MUST NOT
be represented in the Srefresh messages.
Each Srefresh message contains one or more MESSAGE_ID LIST objects.
Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set
(1). Multiple MESSAGE_ID LIST objects MAY be included in order to
accommodate multiple Epoch values. The MESSAGE_ID LIST objects
represent the identified, non-updated, Path state. A
Message_Identifier field created for each identified, non-updated
Path state MUST be included in an appropriate MESSAGE_ID LIST object.
The Message_Identifier field is created based on the MESSAGE_ID
object from the most recently received Path message associated with
identified Path state. If any identified Path state does not have an
associated MESSAGE_ID object, this state MUST be processed as defined
above in Section 2.3.
The source IP address for the Srefresh message SHOULD be the source
IP address in the IP header of the corresponding Resv messages
previously sent to the restarted node. The Srefresh message SHOULD
be destined to the IP address in the HOP object in the corresponding
Path messages. This may result in multiple Srefresh messages being
generated. Per [RFC2961], implementations may choose to limit each
Srefresh message to the MTU size of the outgoing link, and to not
bundle Srefresh messages. RecoveryPath-related Srefresh messages
SHOULD be sent using reliable delivery, as defined in [RFC2961].
During the Recovery Period, unacknowledged RecoveryPath-related
Srefresh messages SHOULD be periodically transmitted. Note that
updated Path state SHOULD be omitted from these periodic Srefresh
messages.
To allow sufficient processing time for the restarted node, the
downstream RSVP neighbor MAY choose to generate multiple
RecoveryPath-related Srefresh messages containing partial but
mutually exclusive sets of Message Identifiers spread across 1/4 of
the Recovery Time advertised by the restarted node.
3.3.2. RecoveryPath-related Srefresh Receive Processing and NACK
Generation
Upon receiving an Srefresh message containing a MESSAGE_ID LIST
object with the RecoveryPath Flag set), the restarted node attempts
to locate matching previously transmitted Path state. The Epoch in
the MESSAGE_ID LIST object along with each Message Identifier in the
object is used to match against the MESSAGE_ID object in Path
messages previously transmitted to the downstream RSVP neighbor. For
each Message Identifier in the MESSAGE_ID LIST:
If matching transmitted Path state is found, the restarting node
treats the corresponding LSP state as having received and
processed a RecoveryPath message, and, perform any further
processing necessary as defined in Section 2.4. Specifically, it
MUST generate a triggered Path message for the LSP as defined in
Section 2.4.2. The restarted node MAY spread the transmission of
such triggered Path messages across 1/2 of the remaining Recovery
Period to allow the downstream RSVP neighbor sufficient processing
time.
If matching transmitted Path state is not found, the restarting
node MUST generate a MESSAGE_ID NACK as defined in [RFC2961].
Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set
(1).
It is recommended that the restarted node combine multiple such
MESSAGE_ID NACK's into a single ACK message, per [RFC2961].
3.3.3. RecoveryPath-related MESSAGE_ID NACK Receive Processing
This section defines the procedures associated with the processing of
received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1).
Procedures for processing of MESSAGE_ID NACK's without the
RecoveryPath Flag present are defined in [RFC2961] and not modified
in this document. Processing of MESSAGE_ID NACK's with the
RecoveryPath Flag set (1) also follows procedures defined in
[RFC2961] unless explicitly modified in this section.
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the
downstream RSVP neighbor must locate the matching received Path
message. If a matching Path message is found, the downstream RSVP
neighbor MUST generate a RecoveryPath message as defined in Section
2.3. If a matching Path message is not found, the MESSAGE_ID NACK is
ignored. An example where this may occur is when the restarted node
has already generated an updated Path message after its restart.
4. Acknowledgments
The authors would like to thank participants of the CCAMP WG for
comments and suggestions. Also thanks to Arthi Ayyangar, Adrian
Farrel and Nick Neate for their helpful comments and feedback.
5. 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.
5. IANA Considerations This document introduces a new RSVP object to be included in RSVP
Hello messages. This document introduces no new security
considerations beyond those already addressed for existing objects in
RSVP Hello messages.
6. IANA Considerations
A new RSVP message type is defined in this document. The RSVP A new RSVP message type is defined in this document. The RSVP
message type is TBA by IANA. message type is TBA by IANA.
6. References A new RSVP object is defined in this document. The Class-Num is TBA
by IANA.
6.1. Normative References 7. References
7.1. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997. RFC 2119, S. Bradner, March 1997.
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", Functional Specification",
RFC 2205, Braden, et al, September 1997. RFC 2205, Braden, et al, September 1997.
[RFC2747] "RSVP Cryptographic Authentication", [RFC2747] "RSVP Cryptographic Authentication",
RFC 2747, F. Baker, et al, January 2000. RFC 2747, F. Baker, et al, January 2000.
skipping to change at page 10, line 17 skipping to change at page 18, line 20
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", Signaling Functional Description",
RFC 3471, L. Berger, et al, January 2003. RFC 3471, L. Berger, et al, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", Engineering (RSVP-TE) Extensions",
RFC 3473, L. Berger, et al, January 2003. RFC 3473, L. Berger, et al, January 2003.
7. Authors' Addresses 7.2. Informative References
[RESTART] "RSVP Graceful Restart Extensions",
draft-rahman-rsvp-restart-extensions-00,
R. Rahman, et al, October 2003
8. Authors' Addresses
Arun Satyanarayana Arun Satyanarayana
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Email: aruns@movaz.com Email: aruns@movaz.com
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
skipping to change at page 10, line 39 skipping to change at page 19, line 4
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
Reshad Rahman
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613)-254-3519
Email: rrahman@cisco.com
8. Full Copyright Statement Anca Zamfir
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613)-254-3484
Email: ancaz@cisco.com
Junaid Israr
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613)-254-3693
Email: jisrar@cisco.com
9. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
11. Full Copyright Statement
Copyright (c) The Internet Society (2004). All Rights Reserved. Copyright (c) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
 End of changes. 43 change blocks. 
134 lines changed or deleted 542 lines changed or added

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