draft-ietf-ccamp-rsvp-restart-ext-00.txt   draft-ietf-ccamp-rsvp-restart-ext-01.txt 
Network Working Group A. Satyanarayana (Movaz Networks) Network Working Group A. Satyanarayana (Cisco Systems)
Internet Draft R. Rahman (Cisco Systems) Internet Draft R. Rahman (Cisco Systems)
Expiration Date: April 2005 Editors Expiration Date: August 2005 Editors
October 2004 February 2005
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-00.txt draft-ietf-ccamp-rsvp-restart-ext-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 38 skipping to change at page 1, line 38
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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
mechanisms defined in [RFC3473]. The extensions enable the recovery mechanisms defined in RFC 3473. The extensions enable the recovery
of RSVP signaling state based on the Path message last sent by the of RSVP signaling state based on the Path message last sent by the
node being restarted. Previously defined Graceful Restart node being restarted. Previously defined Graceful Restart
mechanisms, also called recovery from nodal faults, permit recovery mechanisms, also called recovery from nodal faults, permit recovery
of signaling state from adjacent nodes when the data plane has of signaling state from adjacent nodes when the data plane has
retained the associated forwarding state across a restart. These retained the associated forwarding state across a restart. These
mechanisms do not fully support signaling state recovery on ingress mechanisms do not fully support signaling state recovery on ingress
nodes or recovery of all RSVP objects. The presented extensions use nodes or recovery of all RSVP objects. The presented extensions use
the RSVP Hello extensions defined in [RFC3209], and extensions for the RSVP Hello extensions defined in RFC 3209, and extensions for
state recovery on nodal faults defined in [RFC3473]. With the state recovery on nodal faults defined in RFC 3473. With the
presented extensions the restarting node can recover all previously presented extensions the restarting node can recover all previously
transmitted Path state including the ERO and the downstream transmitted Path state including the ERO and the downstream
(outgoing) interface identifiers. The extensions can also be used to (outgoing) interface identifiers. The extensions can also be used to
recover signaling state after the restart of an ingress node. The recover signaling state after the restart of an ingress node. The
extensions optionally support the use of Summary Refresh, defined in extensions optionally support the use of Summary Refresh, defined in
[RFC2961], to reduce the number of messages exchanged during the 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 LSP's. locally for one or more LSP's.
Contents Contents
1 Introduction .............................................. 5 1 Introduction .............................................. 3
2 Extensions to Nodal Fault Handling ........................ 7 2 Extensions to Nodal Fault Handling ........................ 5
2.1 RecoveryPath Message Format ............................... 7 2.1 RecoveryPath Message Format ............................... 5
2.2 Related Procedures ........................................ 7 2.2 Related Procedures ........................................ 5
2.3 Procedures For The Downstream Neighbor .................... 8 2.3 Procedures For The Downstream Neighbor .................... 6
2.4 Procedures for the Restarting Node ........................ 9 2.4 Procedures for the Restarting Node ........................ 7
2.4.1 Path and RecoveryPath Message Procedures .................. 9 2.4.1 Path and RecoveryPath Message Procedures .................. 7
2.4.2 Re-Synchronization Procedures ............................. 10 2.4.2 Re-Synchronization Procedures ............................. 8
2.4.3 Procedures on Expiration of Recovery Period ............... 11 2.4.3 Procedures on Expiration of Recovery Period ............... 9
2.5 Compatibility ............................................. 11 2.5 Compatibility ............................................. 9
3 RecoveryPath Summary Refresh .............................. 12 3 RecoveryPath Summary Refresh .............................. 10
3.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ........... 13 3.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ........... 11
3.2 Capability Object ......................................... 14 3.2 Capability Object ......................................... 12
3.2.1 Procedures ................................................ 14 3.2.1 Procedures ................................................ 13
3.2.2 Compatibility ............................................. 15 3.2.2 Compatibility ............................................. 13
3.3 RecoveryPath Summary Refresh Procedures ................... 15 3.3 RecoveryPath Summary Refresh Procedures ................... 14
3.3.1 Generation of RecoveryPath-related Srefresh Messages ...... 15 3.3.1 Generation of RecoveryPath-related Srefresh Messages ...... 14
3.3.2 RecoveryPath-related Srefresh Receive Processing and NACK Generation 17 3.3.2 RecoveryPath-related Srefresh Receive Processing and NACK Generation 16
3.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing ... 17 3.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing ... 16
4 Acknowledgments ........................................... 18 4 Acknowledgments ........................................... 17
5 Security Considerations ................................... 18 5 Security Considerations ................................... 17
6 IANA Considerations ....................................... 18 6 IANA Considerations ....................................... 17
7 References ................................................ 18 7 References ................................................ 17
7.1 Normative References ...................................... 18 7.1 Normative References ...................................... 17
7.2 Informative References .................................... 19 7.2 Informative References .................................... 18
8 Authors' Addresses ........................................ 19 8 Authors' Addresses ........................................ 18
9 Intellectual Property Considerations ...................... 20 9 Intellectual Property Considerations ...................... 19
10 Disclaimer of Validity .................................... 21 10 Disclaimer of Validity .................................... 20
11 Full Copyright Statement .................................. 21 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
skipping to change at page 5, line 50 skipping to change at page 3, line 50
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, the Sender Tspec object. A restarting transit
node may have modified received Path state in its previously 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 is 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
skipping to change at page 8, line 17 skipping to change at page 6, line 17
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], the has restarted and is capable of recovery as defined in [RFC3473], the
downstream RSVP neighbor MUST send a RecoveryPath message for each downstream RSVP neighbor MUST send a RecoveryPath message for each
LSP associated with the restarting node for which it has sent a Resv LSP associated with the restarting node for which it has sent a 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, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not
in RecoveryPath messages are generated based on procedures defined copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK
in [RFC2961]. objects used in RecoveryPath messages are generated based on
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
skipping to change at page 8, line 46 skipping to change at page 6, line 47
All RecoveryPath messages SHOULD be sent within approximately 1/2 of All RecoveryPath messages SHOULD be sent within approximately 1/2 of
the Recovery Time advertised by the restarted neighbor. If there are the Recovery Time advertised by the restarted neighbor. If there are
many LSP's to be recovered by the restarted node, the downstream RSVP many LSP's to be recovered by the restarted node, the downstream RSVP
neighbor should avoid sending RecoveryPath messages in a short time neighbor should avoid sending RecoveryPath messages in a short time
interval, to avoid overloading the restarted node's CPU. Instead it interval, to avoid overloading the restarted node's CPU. Instead it
should spread the messages across 1/2 the Recovery Time interval. 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 for the LSP the
message. Note, per [RFC3473], Resv messages are suppressed during RecoveryPath message represents. Each such re-send attempt is at the
this recovery period until a corresponding Path message is received. end of any Message ID rapid retransmissions, if the Message ID
mechanism is used. If the Message ID mechanim is not in use, the
period between re-send attempts SHOULD be such that at least 3
attempts are completed before the expiry of 1/2 the Recovery Time
interval. Each such re-send attempt MUST treat the RecoveryPath
message as a new message, and update the MESSAGE_ID object according
to procedures defined in [RFC2961]. Note, per [RFC3473], Resv
messages are suppressed during 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. If no LSP state matching the RecoveryPath message
matching the discarded message. is located, the restarted node MAY send a PathTear message
constructed from the RecoveryPath message, to expedite the cleanup of
unrecovered RSVP and associated forwarding state downstream of the
restarted node.
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
follow corresponding procedures defined below. Further, recovery follow corresponding procedures defined below. Further, recovery
skipping to change at page 11, line 4 skipping to change at page 9, line 14
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 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 in the RecoveryPath SHOULD match the Explicit Route object received in the RecoveryPath
message. In addition, the restarted node SHOULD recover state from message. In addition, the restarted node SHOULD recover state from
the other objects received in the RecoveryPath message. The optimal the other objects received in the RecoveryPath message. Optimally
result is for the resulting Path message to not cause any redundant the resulting Path message should not cause any redundant or
or unnecessary re-processing of state along the remaining downstream unnecessary re-processing of state along the remaining downstream
nodes. Ideally, except for MESSAGE_ID processing and recovery nodes. Ideally, except for MESSAGE_ID processing and recovery
processing, the transmitted Path message will be treated as a refresh processing, the transmitted Path message will be treated as a refresh
by the downstream RSVP neighbor (and hence should not trigger any by the downstream RSVP neighbor (and hence should not trigger any
generation 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.
skipping to change at page 13, line 8 skipping to change at page 11, line 14
represented in a RecoveryPath message. Within such Srefresh represented in a RecoveryPath message. Within such Srefresh
messages, Path state that can be represented in RecoveryPath messages messages, Path state that can be represented in RecoveryPath messages
is represented using MESSAGE_ID information, and this information is is represented using MESSAGE_ID information, and this information is
communicated within MESSAGE_ID LIST objects. To indicate that the communicated within MESSAGE_ID LIST objects. To indicate that the
MESSAGE_ID LIST object is for recovery purposes, a new flag is set in 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 the MESSAGE_ID LIST object. This flag is called 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 locate state by matching Epoch and state. The node identifies local state by matching Epoch and Message
Message ID tuples against Path messages transmitted downstream prior ID tuples against Path messages transmitted downstream prior to the
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 2.4. If no a RecoveryPath message has been received, per Section 2.4. 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
skipping to change at page 14, line 25 skipping to change at page 12, line 42
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(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R| | Reserved |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Srefresh Capable (R): 1 bit RecoveryPath Srefresh Capable (R): 1 bit
When set (1), indicates that the sending node is capable of When set (1), indicates that the sending node is capable of
receiving and processing Srefresh messages with the receiving and processing Srefresh messages with the
RecoveryPath Flag set (1) in the MESSAGE_ID LIST object. RecoveryPath Flag set (1) in the MESSAGE_ID LIST object.
Absence of the Capability object MUST be treated as if the Absence of the Capability object MUST be treated as if the
R-bit is cleared (0). R-bit is cleared (0).
Reserved bits
Reserved bits MUST be set to zero on transmission and MUST be
ignored on receipt.
This document does not define any TLV's to be included in the
Capability object.
3.2.1. Procedures 3.2.1. Procedures
The Capability object is sent within a Hello message to indicate that The Capability object is sent within a Hello message to indicate that
a node supports selective transmission of RecoveryPath messages. To a node supports selective transmission of RecoveryPath messages. To
indicate to a neighbor that selective transmission of RecoveryPath indicate to a neighbor that selective transmission of RecoveryPath
messages is desired, a restarting node MUST include the Capability messages is desired, a restarting node MUST include the Capability
object with the R-bit set (1) in all Hello messages it sends during 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 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 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 zero (0), the Capability object MUST be omitted or the R-bit MUST be
skipping to change at page 16, line 16 skipping to change at page 14, line 49
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 R-bit as described in Section 3.2.1, the node After processing the R-bit as described in Section 3.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 Path state that has not been updated since
the restart may be represented in the Srefresh messages. Path state the restart may be represented in the Srefresh messages. Received
that has been updated when a Path message is received with a Path state containing a MESSAGE_ID object whose Epoch value matches
MESSAGE_ID which contains an Epoch value that matches the Epoch the Epoch received in the most recent Hello message is considered as
received in the most recent Hello message. Such Path state MUST NOT updated after the upstream neighbor has restarted. Such Path state
be represented in the Srefresh messages. MUST NOT be represented in the Srefresh messages.
Each Srefresh message contains one or more MESSAGE_ID LIST objects. Each Srefresh message contains one or more MESSAGE_ID LIST objects.
Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set
(1). Multiple MESSAGE_ID LIST objects MAY be included in order to (1). 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
skipping to change at page 16, line 46 skipping to change at page 15, line 33
IP address in the IP header of the corresponding Resv messages IP address in the IP header of the corresponding Resv messages
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. Note that Srefresh messages SHOULD be periodically transmitted. The
updated Path state SHOULD be omitted from these periodic Srefresh retransmission algorithm used can be same algorithm used for
messages. retransmitting RecoveryPath messages during the Recovery Period (see
section 2.3). Note that prior to each such periodic 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 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.
3.3.2. RecoveryPath-related Srefresh Receive Processing and NACK 3.3.2. RecoveryPath-related Srefresh Receive Processing and NACK
Generation Generation
skipping to change at page 18, line 30 skipping to change at page 17, line 27
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
RSVP Hello messages. RSVP Hello messages.
6. IANA Considerations 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.
A new RSVP object is defined in this document. The Class-Num is TBA A new RSVP object of form 10bbbbbb is defined in this document. The
by IANA. Class-Num is TBA by IANA.
7. References 7. References
7.1. Normative 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",
skipping to change at page 19, line 27 skipping to change at page 18, line 23
7.2. Informative References 7.2. Informative References
[RESTART] "RSVP Graceful Restart Extensions", [RESTART] "RSVP Graceful Restart Extensions",
draft-rahman-rsvp-restart-extensions-00, draft-rahman-rsvp-restart-extensions-00,
R. Rahman, et al, October 2003 R. Rahman, et al, October 2003
8. Authors' Addresses 8. Authors' Addresses
Arun Satyanarayana Arun Satyanarayana
Movaz Networks, Inc. Cisco Systems, Inc.
7926 Jones Branch Drive 170 West Tasman Dr.
Suite 615 San Jose, CA 95134
McLean VA, 22102 Email: asatyana@cisco.com
Email: aruns@movaz.com
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
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)
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/