draft-ietf-ccamp-rsvp-restart-ext-03.txt   draft-ietf-ccamp-rsvp-restart-ext-04.txt 
Network Working Group A. Satyanarayana, Ed. Network Working Group A. Satyanarayana, Ed.
Internet-Draft R. Rahman, Ed. Internet-Draft R. Rahman, Ed.
Updates: 2961, 3473 (if approved) Cisco Systems Updates: 2961, 3473 (if approved) Cisco Systems
Expires: December 3, 2005 L. Berger Expires: April 3, 2006 L. Berger
Movaz Networks Movaz Networks
D. Papadimitriou D. Papadimitriou
Alcatel Alcatel
A. Zamfir A. Zamfir
J. Israr J. Israr
Cisco Systems Cisco Systems
June 2005 September 2005
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-03 draft-ietf-ccamp-rsvp-restart-ext-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
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.
This Internet-Draft will expire on December 3, 2005. This Internet-Draft will expire on April 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes extensions to the RSVP Graceful Restart This document describes extensions to the RSVP Graceful Restart
mechanisms defined in RFC 3473. 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
skipping to change at page 4, line 14 skipping to change at page 4, line 14
1. Conventions used in this document 1. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
xref target="RFC3209" /> and [RFC3473]. [RFC3209] and [RFC3473].
Throughout this document, the term "node" when used in the context of Throughout this document, the term "node" when used in the context of
a restarting or restarted node generally refers to the control plane a restarting or restarted node generally refers to the control plane
component which is the signaling controller for a data plane switch. component which is the signaling controller for a data plane switch.
3. Introduction 3. 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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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 |T|R|S| | Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Desired (R): 1 bit
When set (1), indicates that the sending node desires to
receive RecoveryPath messages. Absence of the Capability
object MUST be treated as if the R-bit is cleared (0).
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
When set (1), indicates that the sending node desires to
receive RecoveryPath messages. Absence of the Capability
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
skipping to change at page 8, line 13 skipping to change at page 8, line 13
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_Caps 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 in
[RFC3209] and the use of the Restart_Caps object extension as defined [RFC3209] and the use of the Restart_Cap object extension as defined
in [RFC3473]. The presented extensions address only "Nodal Faults" in [RFC3473]. The presented extensions address only "Nodal Faults"
as defined in [RFC3473]. Control channel faults are fully addressed as defined in [RFC3473]. Control channel faults are fully 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.
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 the downstream RSVP neighbor of a restarting node is capable of If a node is capable of sending RecoveryPath messages, it MUST
sending RecoveryPath messages to the restarting node, it MUST include include the Capability object with the RecoveryPath Transmit Enabled
the Capability object with the RecoveryPath Transmit Enabled (T) bit (T) bit set (1) in all its Hello messages.
set (1) in all its Hello messages sent to the restarting node.
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_Caps object as defined in restarting node, with the Restart_Cap object as defined in [RFC3473],
[RFC3473], and, with the Capability object with the RecoveryPath and, with the Capability object with the RecoveryPath Desired (R) bit
Desired (R) bit set (1), it MUST treat the restarting node as capable set (1), it MUST treat the restarting node as capable of receiving
of receiving and processing RecoveryPath messages as defined in this and processing RecoveryPath messages as defined in this document.
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_Caps 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 restarting node that expects to recover RSVP state by the receipt A node that expects to recover RSVP state by the receipt and
and processing of RecoveryPath messages according to procedures processing of RecoveryPath messages according to procedures defined
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, during the Recovery Period. The node MUST also its neighbors. The node MUST also include the Restart_Cap object as
include the Restart_Caps object as defined in [RFC3473], in all those defined in [RFC3473], in all those Hello messages.
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_Caps 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 4.5.2, with the downstream RSVP neighbor. Section 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
skipping to change at page 11, line 19 skipping to change at page 11, line 16
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 in [RFC3473]. Any
RecoveryPath message received after the Recovery Period has expired RecoveryPath message received after the Recovery Period has expired
MUST be discarded. If no LSP state matching the RecoveryPath message SHOULD be matched against local LSP state. If matching fully
is located, the restarted node MAY send a PathTear message resynchronized state is located, the node SHOULD send a Path message
constructed from the RecoveryPath message, to expedite the cleanup of downstream. If non-resynchronized or no LSP state matching the
unrecovered RSVP and associated forwarding state downstream of the RecoveryPath message is located, the restarted node MAY send a
restarted node. 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 16, line 35 skipping to change at page 16, line 35
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 restarting node MUST set (1) the RecoveryPath messages is desired, a node MUST set (1) the S-bit in
S-bit in the Capability object in all Hello messages it sends during the Capability object in all Hello messages it sends. When the
the Recovery Period to the neighbor. When the restarting node does restarting node does not desire the receipt of RecoveryPath messages,
not desire the receipt of RecoveryPath messages, see Section 4.4.2, see Section 4.4.2, or, the selective transmission mechanism defined
or, the selective transmission mechanism defined in this section, it in this section, it MUST clear (0) the S-bit in the Capability object
MUST clear (0) the S-bit in the Capability object if included in if included in Hello messages.
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 as if the Capability object was
skipping to change at page 20, line 48 skipping to change at page 20, line 47
can be minimalized by the restarting RSVP agent using a large enough can be minimalized by the restarting RSVP agent using a large enough
Recovery Time, so that its neighbors are provided sufficient time to Recovery Time, so that its neighbors are provided sufficient time to
handle the additional processing involved while continuing to perform handle the additional processing involved while continuing to perform
their other control plane functions normally during the Recovery their other control plane functions normally during the Recovery
Period. Period.
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 and Nick Neate for their helpful comments and feedback. Farrel, Nick Neate and Pavan Beeram for their helpful comments and
feedback.
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. Class-Number is TBA by IANA. A value of 132 is suggested.
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 TBA by IANA.
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, TBA by IANA:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |S|P|R| | |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
 End of changes. 21 change blocks. 
45 lines changed or deleted 45 lines changed or added

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