draft-ietf-ccamp-rsvp-restart-ext-07.txt   draft-ietf-ccamp-rsvp-restart-ext-08.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
Intended status: Standards Track January 2007 Intended status: Standards Track January 2007
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-07 draft-ietf-ccamp-rsvp-restart-ext-08
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 6, line 27 skipping to change at page 6, line 27
by the presented extensions, see [RFC3473] for details. by the presented extensions, see [RFC3473] for details.
4. Extensions to Nodal Fault Handling 4. Extensions to Nodal Fault Handling
This section presents the protocol modifications to Section 9 of This section presents the protocol modifications to Section 9 of
[RFC3473]. [RFC3473].
4.1. RecoveryPath Message Format 4.1. RecoveryPath Message Format
The format of a RecoveryPath message is the same as the format of a The format of a RecoveryPath message is the same as the format of a
Path message as defined in [RFC3473]: Path message as defined in [RFC3473], but uses a new message number
so that it can be identified correctly.
<RecoveryPath Message> ::= <Path Message> <RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath The destination address used in the IP header of a RecoveryPath
message MUST be the same as the destination address used in the IP message MUST be the same as the destination address used in the IP
header of the corresponding Resv message last generated by the header of the corresponding Resv message last generated by the
sending node. Except as specified below all objects in a sending node. Except as specified below all objects in a
RecoveryPath message are identical to the objects in the RecoveryPath message are identical to the objects in the
corresponding Path message last received by the sending node. corresponding Path message last received by the sending node.
skipping to change at page 10, line 51 skipping to change at page 10, line 51
implementation specifics that affect the amount of time taken to implementation specifics that affect the amount of time taken to
verify the received recovery state against existing forwarding plane verify the received recovery state against existing forwarding plane
state. Such discussion is out of scope of this document. state. Such discussion is out of scope of this document.
After sending a RecoveryPath message and during the Recovery Period, After sending a RecoveryPath message and during the Recovery Period,
the node SHOULD periodically re-send the RecoveryPath message until the node SHOULD periodically 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 for the LSP the Message ID acknowledgment or a Path message for the LSP the
RecoveryPath message represents. Each such re-send attempt is at the RecoveryPath message represents. Each such re-send attempt is at the
end of any Message ID rapid retransmissions, if the Message ID end of any Message ID rapid retransmissions, if the Message ID
mechanism is used. If the Message ID mechanim is not in use, the mechanism is used. If the Message ID mechanism is not in use, the
period between re-send attempts SHOULD be such that at least 3 period between re-send attempts SHOULD be such that at least 3
attempts are completed before the expiry of 3/4 the Recovery Time attempts are completed before the expiry of 3/4 the Recovery Time
interval. Each such re-send attempt MUST treat the RecoveryPath interval. Each such re-send attempt MUST treat the RecoveryPath
message as a new message, and update the MESSAGE_ID object according message as a new message, and update the MESSAGE_ID object according
to procedures defined in [RFC2961]. Note, per [RFC3473], Resv to procedures defined in [RFC2961]. Note, per [RFC3473], Resv
messages are suppressed during this recovery period until a messages are suppressed during this recovery period until a
corresponding Path message is received. corresponding Path message is received.
4.5.2. Procedures for the Restarting Node 4.5.2. Procedures for the Restarting Node
skipping to change at page 21, line 5 skipping to change at page 20, line 49
7. Acknowledgments 7. Acknowledgments
The authors would like to thank participants of the CCAMP WG for The authors would like to thank participants of the CCAMP WG for
comments and suggestions. Also thanks to Arthi Ayyangar, Adrian comments and suggestions. Also thanks to Arthi Ayyangar, Adrian
Farrel, Nick Neate and Pavan Beeram for their helpful comments and Farrel, Nick Neate and Pavan Beeram for their helpful comments and
feedback. feedback.
Derek Atkins provided useful discussion during SecDir review. Derek Atkins provided useful discussion during SecDir review.
Adrian Farrel edited the final revisions of this document as it
progressed through IESG review.
8. IANA Considerations 8. IANA Considerations
[RFC2205] defines the Class-Number name space for RSVP objects. The [RFC2205] defines the Class-Number name space for RSVP objects. The
name space is managed by IANA. name space is managed by IANA.
A new RSVP object using a Class-Number of form 10bbbbbb called the A new RSVP object using a Class-Number of form 10bbbbbb called the
Capability Object is defined in Section 4.2 in this document. The Capability Object is defined in Section 4.2 in this document. The
Class-Number is TBA by IANA. A value of 132 is suggested. Class-Number is 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
 End of changes. 4 change blocks. 
3 lines changed or deleted 7 lines changed or added

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