draft-ietf-ccamp-rsvp-restart-ext-05.txt   draft-ietf-ccamp-rsvp-restart-ext-06.txt 
Network Working Group A. Satyanarayana (Editor) Network Working Group A. Satyanarayana, Ed.
Internet-Draft R. Rahman (Editor) Internet-Draft R. Rahman, Ed.
Updates: 2961, 3473 (if approved) Cisco Systems Updates: 2961, 3473 (if approved) Cisco Systems
October 2005 Intended status: Standards Track December 2006
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-05 draft-ietf-ccamp-rsvp-restart-ext-06
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 33
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 June 8, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
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
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
transmitted Path state including the Explicit Route Object and the transmitted Path state including the Explicit Route Object and the
downstream (outgoing) interface identifiers. The extensions can also downstream (outgoing) interface identifiers. The extensions can also
be used to recover signaling state after the restart of an ingress be used to recover signaling state after the restart of an ingress
node. The extensions optionally support the use of Summary Refresh, node. The extensions optionally support the use of Summary Refresh,
defined in RFC 2961, to reduce the number of messages exchanged defined in RFC 2961, to reduce the number of messages exchanged
during the Recovery Phase when the restarting node has recovered during the Recovery Phase when the restarting node has recovered
signaling state locally for one or more LSPs. signaling state locally for one or more LSPs.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
4. Extensions to Nodal Fault Handling . . . . . . . . . . . . 6 4. Extensions to Nodal Fault Handling . . . . . . . . . . . 6
4.1 RecoveryPath Message Format . . . . . . . . . . . . . . . 6 4.1. RecoveryPath Message Format . . . . . . . . . . . . . . 6
4.2 Capability Object . . . . . . . . . . . . . . . . . . . . 6 4.2. Capability Object . . . . . . . . . . . . . . . . . . . 6
4.2.1 Conformance . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Related Procedures . . . . . . . . . . . . . . . . . . . . 8 4.3. Related Procedures . . . . . . . . . . . . . . . . . . . 8
4.4 Procedures for the Capability Object . . . . . . . . . . . 8 4.4. Procedures for the Capability Object . . . . . . . . . . 8
4.4.1 Procedures for the Downstream Neighbor . . . . . . . . . . 8 4.4.1. Procedures for the Downstream Neighbor . . . . . . . . . 8
4.4.2 Procedures for the Restarting Node . . . . . . . . . . . . 9 4.4.2. Procedures for the Restarting Node . . . . . . . . . . . 9
4.5 Procedures for the RecoveryPath message . . . . . . . . . 9 4.5. Procedures for the RecoveryPath message . . . . . . . . 9
4.5.1 Procedures For The Downstream Neighbor . . . . . . . . . . 9 4.5.1. Procedures for the Downstream Neighbor . . . . . . . . . 9
4.5.2 Procedures for the Restarting Node . . . . . . . . . . . . 11 4.5.2. Procedures for the Restarting Node . . . . . . . . . . . 11
4.5.2.1 Path and RecoveryPath Message Procedures . . . . . . . . . 11 4.5.2.1. Path and RecoveryPath Message Procedures . . . . . . . . 11
4.5.2.2 Re-Synchronization Procedures . . . . . . . . . . . . . . 12 4.5.2.2. Re-Synchronization Procedures . . . . . . . . . . . . . 12
4.5.2.3 Procedures on Expiration of Recovery Period . . . . . . . 13 4.5.2.3. Procedures on Expiration of Recovery Period . . . . . . 13
4.6 Compatibility . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Compatibility . . . . . . . . . . . . . . . . . . . . . 13
5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . . 14 5. RecoveryPath Summary Refresh . . . . . . . . . . . . . . 14
5.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . . 15 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects . . . . 15
5.2 RecoveryPath Srefresh Capable bit . . . . . . . . . . . . 16 5.2. RecoveryPath Srefresh Capable bit . . . . . . . . . . . 16
5.2.1 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . . 17
5.3 RecoveryPath Summary Refresh Procedures . . . . . . . . . 17 5.3. RecoveryPath Summary Refresh Procedures . . . . . . . . 17
5.3.1 Generation of RecoveryPath-related Srefresh Messages . . . 17 5.3.1. Generation of RecoveryPath-related Srefresh Messages . . 17
5.3.2 RecoveryPath-related Srefresh Receive Processing and 5.3.2. RecoveryPath-related Srefresh Receive Processing and
NACK Generation . . . . . . . . . . . . . . . . . . . . . 19 NACK Generation . . . . . . . . . . . . . . . . . . . . 19
5.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing . 19 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive
6. Security Considerations . . . . . . . . . . . . . . . . . 20 Processing . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22 9. Normative References . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . 24
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
skipping to change at page 6, line 28 skipping to change at page 6, line 28
the signaling state for a subset of the previously active LSPs. the signaling state for a subset of the previously active LSPs.
Restarting egress nodes, and Resv message processing are not impacted Restarting egress nodes, and Resv message processing are not impacted
by the presented extensions, see [RFC3473] for details. by the presented extensions, see [RFC3473] for details.
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]:
<RecoveryPath Message> ::= <Path Message> <RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath The destination address used in the IP header of a RecoveryPath
message MUST be the same as the destination address used in the IP message MUST be the same as the destination address used in the IP
header of the corresponding Resv message last generated by the header of the corresponding Resv message last generated by the
sending node. Except as specified below all objects in a sending node. Except as specified below all objects in a
RecoveryPath message are identical to the objects in the RecoveryPath message are identical to the objects in the
corresponding Path message last received by the sending node. corresponding Path message last received by the sending node.
4.2 Capability Object 4.2. Capability Object
Capability objects are carried in RSVP Hello messages. The Capability objects are carried in RSVP Hello messages. The
Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type Capability object uses Class-Number TBA (of form 10bbbbbb) and C-Type
of 1. of 1.
The message format of a Hello message is modified to be: The message format of a Hello message is modified to be:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO> <Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ] [ <RESTART_CAP> ] [ <CAPABILITY> ]
The format of a Capability object is: The format of a Capability object is:
skipping to change at page 7, line 40 skipping to change at page 7, line 40
with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST
object. Absence of the Capability object MUST be treated as if object. Absence of the Capability object MUST be treated as if
the S-bit is cleared (0). Related procedures are defined in the S-bit is cleared (0). Related procedures are defined in
Section 5.2.1. Section 5.2.1.
Reserved bits Reserved bits
Reserved bits MUST be set to zero on transmission and MUST be Reserved bits MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
4.2.1 Conformance 4.2.1. Conformance
All nodes supporting the extensions defined in this document MUST be All nodes supporting the extensions defined in this document MUST be
able to transmit, and, properly receive and process RecoveryPath able to transmit, and, properly receive and process RecoveryPath
messages. All nodes MUST be able to set both the T and R bits. Both messages. All nodes MUST be able to set both the T and R bits. Both
the T and R bits SHOULD be set (1) by default. A node MAY allow the T and R bits SHOULD be set (1) by default. A node MAY allow
RecoveryPath message transmission and reception to be independently RecoveryPath message transmission and reception to be independently
disabled based on local policy. When RecoveryPath message disabled based on local policy. When RecoveryPath message
transmission is disabled, the T-bit MUST be set to zero (0). When transmission is disabled, the T-bit MUST be set to zero (0). When
RecoveryPath message reception is not desired, the R-bit MUST be set RecoveryPath message reception is not desired, the R-bit MUST be set
to zero (0). to zero (0).
Any node that supports the extensions defined in this document and Any node that supports the extensions defined in this document and
sets the Refresh-Reduction-Capable bit [RFC2961], SHOULD support sets the Refresh-Reduction-Capable bit [RFC2961], SHOULD support
setting of the S-bit and support the mechanisms defined in Section 5. setting of the S-bit and support the mechanisms defined in Section 5.
4.3 Related Procedures 4.3. Related Procedures
This document does not modify existing procedures for sending and This document does not modify existing procedures for sending and
receiving RSVP Hello messages as defined in [RFC3209] and the receiving RSVP Hello messages as defined in [RFC3209] and the
Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. Restart_Cap object in RSVP Hello messages as defined in [RFC3473].
The procedures for control channel faults are defined in [RFC3473] The procedures for control channel faults are defined in [RFC3473]
and are not changed by this document. and are not changed by this document.
The presented extensions require the use of RSVP Hellos as defined in The presented extensions require the use of RSVP Hellos as defined in
[RFC3209] and the use of the Restart_Cap 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"
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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 a node is capable of sending RecoveryPath messages, it MUST If a node is capable of sending RecoveryPath messages, it MUST
include the Capability object with the RecoveryPath Transmit Enabled include the Capability object with the RecoveryPath Transmit Enabled
(T) bit set (1) in all its Hello messages. (T) bit set (1) in all its Hello messages.
If the downstream RSVP neighbor receives Hello messages from a If the downstream RSVP neighbor receives Hello messages from a
restarting node, with the Restart_Cap object as defined in [RFC3473], restarting node, with the Restart_Cap object as defined in [RFC3473],
and, with the Capability object with the RecoveryPath Desired (R) bit and, with the Capability object with the RecoveryPath Desired (R) bit
set (1), it MUST treat the restarting node as capable of receiving set (1), it MUST treat the restarting node as capable of receiving
and processing RecoveryPath messages as defined in this document. and processing RecoveryPath messages as defined in this document.
skipping to change at page 9, line 9 skipping to change at page 9, line 9
if the RecoveryPath Receive Desired (R) bit is cleared (0) in the if the RecoveryPath Receive Desired (R) bit is cleared (0) in the
Hello message. Hello message.
If the downstream RSVP neighbor does not receive the Capability If the downstream RSVP neighbor does not receive the Capability
object in Hello messages sent by the restarting node or the object in Hello messages sent by the restarting node or the
RecoveryPath Desired (R) bit is cleared (0) in the Capability object, RecoveryPath Desired (R) bit is cleared (0) in the Capability object,
it MUST treat the restarting node as not capable of supporting the it MUST treat the restarting node as not capable of supporting the
RecoveryPath message procedures defined in this document, and, MUST RecoveryPath message procedures defined in this document, and, MUST
revert to recovery procedures as defined in [RFC3473]. revert to recovery procedures as defined in [RFC3473].
4.4.2 Procedures for the Restarting Node 4.4.2. Procedures for the Restarting Node
A node that expects to recover RSVP state by the receipt and A node that expects to recover RSVP state by the receipt and
processing of RecoveryPath messages according to procedures defined processing of RecoveryPath messages according to procedures defined
in this document, MUST include the Capability object with the in this document, MUST include the Capability object with the
RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to
its neighbors. The node MUST also include the Restart_Cap object as its neighbors. The node MUST also include the Restart_Cap object as
defined in [RFC3473], in all those Hello messages. defined in [RFC3473], in all those Hello messages.
If the Recovery Time is zero (0) or the restarting node does not If the Recovery Time is zero (0) or the restarting node does not
support/desire the use of RecoveryPath messages, the RecoveryPath support/desire the use of RecoveryPath messages, the RecoveryPath
skipping to change at page 9, line 43 skipping to change at page 9, line 43
During the Recovery Period, if the restarting node receives Hello During the Recovery Period, if the restarting node receives Hello
messages from a downstream RSVP neighbor with the RecoveryPath messages from a downstream RSVP neighbor with the RecoveryPath
Transmit Enabled (T) bit cleared (0) in the Capability object, or, Transmit Enabled (T) bit cleared (0) in the Capability object, or,
with the Capability object not present, it MUST treat the downstream with the Capability object not present, it MUST treat the downstream
RSVP neighbor as not capable of the RecoveryPath message procedures RSVP neighbor as not capable of the RecoveryPath message procedures
defined in this document, and, it MUST revert to the recovery defined in this document, and, it MUST revert to the recovery
procedures defined in [RFC3473] immediately, with the downstream RSVP procedures defined in [RFC3473] immediately, with the downstream RSVP
neighbor. neighbor.
4.5 Procedures for the RecoveryPath message 4.5. Procedures for the RecoveryPath message
4.5.1 Procedures For The Downstream Neighbor 4.5.1. Procedures for the Downstream Neighbor
After a downstream RSVP neighbor has detected that its upstream node After a downstream RSVP neighbor has detected that its upstream node
has restarted, is capable of recovery as defined in [RFC3473], and, has restarted, is capable of recovery as defined in [RFC3473], and,
is capable of receiving RecoveryPath messages as defined in is capable of receiving RecoveryPath messages as defined in
Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath
message for each LSP associated with the restarting node for which it message for each LSP associated with the restarting node for which it
has sent a Resv message. During the Recovery Period, if the has sent a Resv message. During the Recovery Period, if the
downstream RSVP neighbor detects that the restarting node is not downstream RSVP neighbor detects that the restarting node is not
capable of receiving RecoveryPath messages, by the absence of the capable of receiving RecoveryPath messages, by the absence of the
Capability object or the RecoveryPath Desired (R) bit cleared (0) in Capability object or the RecoveryPath Desired (R) bit cleared (0) in
skipping to change at page 10, line 42 skipping to change at page 10, line 42
All other objects from the most recent received Path message MUST be All other objects from the most recent received Path message MUST be
included in the RecoveryPath message. included in the RecoveryPath message.
All RecoveryPath messages SHOULD be sent at least once within All RecoveryPath messages SHOULD be sent at least once within
approximately 1/2 of the Recovery Time advertised by the restarted approximately 1/2 of the Recovery Time advertised by the restarted
neighbor. If there are many LSPs to be recovered by the restarted neighbor. If there are many LSPs to be recovered by the restarted
node, the downstream RSVP neighbor should avoid sending RecoveryPath node, the downstream RSVP neighbor should avoid sending RecoveryPath
messages in a short time interval, to avoid overloading the restarted messages in a short time interval, to avoid overloading the restarted
node's CPU. Instead it should spread the messages across 1/2 the node's CPU. Instead it should spread the messages across 1/2 the
Recovery Time interval. Recovery Time interval. The range of Recovery Time is dependent on
many factors including but not limited to the CPU processing power on
the restarting node as well as the upstream and downstream neighbors,
amount of CPU available for processing RSVP recovery procedures,
implementation specifics that affect the amount of time taken to
verify the received recovery state against existing forwarding plane
state. Such discussion is out of scope of this document.
After sending a RecoveryPath message and during the Recovery Period, After sending a RecoveryPath message and during the Recovery Period,
the node SHOULD periodically re-send the RecoveryPath message until the node SHOULD periodically 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 mechanim 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
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
SHOULD be matched against local LSP state. If matching fully SHOULD be matched against local LSP state. If matching fully
resynchronized state is located, the node SHOULD send a Path message resynchronized state is located, the node SHOULD send a Path message
downstream. If non-resynchronized or no LSP state matching the downstream. If non-resynchronized or no LSP state matching the
RecoveryPath message is located, the restarted node MAY send a RecoveryPath message is located, the restarted node MAY send a
PathTear message constructed from the RecoveryPath message, to PathTear message constructed from the RecoveryPath message, to
expedite the cleanup of unrecovered RSVP and associated forwarding expedite the cleanup of unrecovered RSVP and associated forwarding
skipping to change at page 11, line 38 skipping to change at page 11, line 44
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
procedures 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.
4.5.2.1 Path and RecoveryPath Message Procedures 4.5.2.1. Path and RecoveryPath Message Procedures
When a node receives a RecoveryPath message during the Recovery When a node receives a RecoveryPath message during the Recovery
Period, the node first checks if it has resynchronized RSVP state Period, the node first checks if it has resynchronized RSVP state
associated with the message. If there is resynchronized state, and associated with the message. If there is resynchronized state, and
when both reliable message delivery [RFC2961] is supported and a when both reliable message delivery [RFC2961] is supported and a
MESSAGE_ID object is present in the RecoveryPath message, the node MESSAGE_ID object is present in the RecoveryPath message, the node
MUST follow Message ID acknowledgment procedures as defined in MUST follow Message ID acknowledgment procedures as defined in
[RFC2961], and, consider the message as processed. If there is [RFC2961], and, consider the message as processed. If there is
resynchronized state, and, there is no MESSAGE_ID object or reliable resynchronized state, and, there is no MESSAGE_ID object or reliable
message delivery [RFC2961] is not supported, the node SHOULD send a message delivery [RFC2961] is not supported, the node SHOULD send a
skipping to change at page 12, line 31 skipping to change at page 12, line 37
Per [RFC3473], if matching RSVP state is not found, and the message Per [RFC3473], if matching RSVP state is not found, and the message
does not carry a Recovery_Label object, the node treats this as a does not carry a Recovery_Label object, the node treats this as a
setup for a new LSP, and handles it according to previously defined setup for a new LSP, and handles it according to previously defined
procedures. procedures.
If matching RSVP state is not found, and the message carries a If matching RSVP state is not found, and the message carries a
Recovery_Label object, the node saves the information contained in Recovery_Label object, the node saves the information contained in
the Path message including the Recovery_Label object for later use. the Path message including the Recovery_Label object for later use.
4.5.2.2 Re-Synchronization Procedures 4.5.2.2. Re-Synchronization Procedures
After receipt of the RecoveryPath message and, for non-ingress LSPs, After receipt of the RecoveryPath message and, for non-ingress LSPs,
the corresponding Path message with a Recovery Label object, the the corresponding Path message with a Recovery Label object, the
restarting node SHOULD locate and associate corresponding forwarding restarting node SHOULD locate and associate corresponding forwarding
state using the received information. The restarting node associates state using the received information. The restarting node associates
the corresponding active forwarding plane state from the following the corresponding active forwarding plane state from the following
signaled information: signaled information:
The upstream data interface is recovered from the RSVP HOP object The upstream data interface is recovered from the RSVP HOP object
in the received Path message. in the received Path message.
skipping to change at page 13, line 30 skipping to change at page 13, line 34
the transmitted Path message will be treated as a refresh by the the transmitted Path message will be treated as a refresh by the
downstream RSVP neighbor (and hence should not trigger any generation downstream RSVP neighbor (and hence should not trigger any generation
of Path messages with changed state further downstream). 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.
4.5.2.3 Procedures on Expiration of Recovery Period 4.5.2.3. Procedures on Expiration of Recovery Period
There are several cleanup steps to follow at the end of the Recovery There are several cleanup steps to follow at the end of the Recovery
Period. At the end of the Recovery Period, any state that was Period. At the end of the Recovery Period, any state that was
installed as the result of a received RecoveryPath message that is installed as the result of a received RecoveryPath message that is
not resynchronized SHOULD be discarded. not resynchronized SHOULD be discarded.
Any Path messages that were received containing a Recovery_Label that Any Path messages that were received containing a Recovery_Label that
have not been resynchronized, MUST be treated as being received have not been resynchronized, MUST be treated as being received
during the Recovery Period and processed as per [RFC3473]. during the Recovery Period and processed as per [RFC3473].
Per [RFC3473], any other state that is not resynchronized during the Per [RFC3473], any other state that is not resynchronized during the
Recovery Period SHOULD be removed at the end of the Period. Recovery Period SHOULD be removed at the end of the Period.
4.6 Compatibility 4.6. Compatibility
This document introduces a new RSVP signaling message called the This document introduces a new RSVP signaling message called the
RecoveryPath message to be generated by the downstream RSVP neighbor RecoveryPath message to be generated by the downstream RSVP neighbor
of a restarting node. To advertise the capability of sending and of a restarting node. To advertise the capability of sending and
receiving RecoveryPath messages, this document introduces the receiving RecoveryPath messages, this document introduces the
Capability object, to be included in Hello messages by a restarting Capability object, to be included in Hello messages by a restarting
node and its downstream RSVP neighbors. node and its downstream RSVP neighbors.
If a restarting node does not support the Capability object, it will If a restarting node does not support the Capability object, it will
discard the object as the Class-Number is of the form 10bbbbbb and discard the object as the Class-Number is of the form 10bbbbbb and
skipping to change at page 15, line 43 skipping to change at page 15, line 48
matching state can be located, the restarted node generates a matching state can be located, the restarted node generates a
Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is
also marked with the new RecoveryPath Flag to indicate that the NACK also marked with the new RecoveryPath Flag to indicate that the NACK
is related to RecoveryPath messages. is related to RecoveryPath messages.
Upon receiving a Srefresh NACK, the downstream node generates a Upon receiving a Srefresh NACK, the downstream node generates a
RecoveryPath message for the Path state indicated by each entry in RecoveryPath message for the Path state indicated by each entry in
the MESSAGE_ID LIST. The procedures defined above in Section 4 are the MESSAGE_ID LIST. The procedures defined above in Section 4 are
then followed by the restarted node and the downstream RSVP neighbor. then followed by the restarted node and the downstream RSVP neighbor.
5.1 MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects 5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object,
defined in [RFC2961], are updated by this document. A new bit within defined in [RFC2961], are updated by this document. A new bit within
the existing Flags field of each object is defined. This bit the existing Flags field of each object is defined. This bit
indicates that the object carries MESSAGE_ID information related to indicates that the object carries MESSAGE_ID information related to
Path state that can be recovered using RecoveryPath messages. The Path state that can be recovered using RecoveryPath messages. The
same flag value is used in all the objects for consistency. same flag value is used in all the objects for consistency.
MESSAGE_ID_ACK object MESSAGE_ID_ACK object
MESSAGE_ID_NACK object MESSAGE_ID_NACK object
skipping to change at page 16, line 20 skipping to change at page 16, line 26
See Section 5.1 of [RFC2961] for definition of other fields. See Section 5.1 of [RFC2961] for definition of other fields.
Flags: 8 bits Flags: 8 bits
0x02: RecoveryPath Flag 0x02: RecoveryPath Flag
Indicates that the associated object carries MESSAGE_ID Indicates that the associated object carries MESSAGE_ID
information related to one or more Path messages that can be information related to one or more Path messages that can be
recovered using a RecoveryPath message. recovered using a RecoveryPath message.
5.2 RecoveryPath Srefresh Capable bit 5.2. RecoveryPath Srefresh Capable bit
The Capability object and the RecoveryPath Srefresh Capable (S) bit The Capability object and the RecoveryPath Srefresh Capable (S) bit
are defined in Section 4.2. are defined in Section 4.2.
5.2.1 Procedures 5.2.1. Procedures
To support the selective receipt of RecoveryPath messages as defined To support the selective receipt of RecoveryPath messages as defined
in this section, a restarting node MUST support the receipt and in this section, a restarting node MUST support the receipt and
processing of RecoveryPath messages as defined in Section 4.5.2 and processing of RecoveryPath messages as defined in Section 4.5.2 and
MUST indicate this capability by including the Capability object with MUST indicate this capability by including the Capability object with
the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in
its Hello messages. its Hello messages.
To indicate to an RSVP neighbor that selective transmission of To indicate to an RSVP neighbor that selective transmission of
RecoveryPath messages is desired, a node MUST set (1) the S-bit in RecoveryPath messages is desired, a node MUST set (1) the S-bit in
skipping to change at page 17, line 7 skipping to change at page 17, line 12
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
received with the S-bit cleared. See Section 4.4 for handling of received with the S-bit cleared. See Section 4.4 for handling of
Hello messages without the Capability object. Hello messages without the Capability object.
5.2.2 Compatibility 5.2.2. Compatibility
There are no compatibility issues introduced in the procedures There are no compatibility issues introduced in the procedures
defined in Section 5.2.1. defined in Section 5.2.1.
The restarting node will detect that its neighbor does not support The restarting node will detect that its neighbor does not support
selective transmission of RecoveryPath messages when a RecoveryPath selective transmission of RecoveryPath messages when a RecoveryPath
message is received prior to the receipt of a Srefresh message message is received prior to the receipt of a Srefresh message
containing a MESSAGE_ID LIST object with the RecoveryPath Flag set containing a MESSAGE_ID LIST object with the RecoveryPath Flag set
(1). When this occurs, any received RecoveryPath messages MUST be (1). When this occurs, any received RecoveryPath messages MUST be
processed as defined in Section 4. processed as defined in Section 4.
5.3 RecoveryPath Summary Refresh Procedures 5.3. RecoveryPath Summary Refresh Procedures
Related processing occurs in the following logical order: Related processing occurs in the following logical order:
o Generation of RecoveryPath-related Srefresh messages o Generation of RecoveryPath-related Srefresh messages
o RecoveryPath-related Srefresh message receive processing and NACK o RecoveryPath-related Srefresh message receive processing and NACK
generation generation
o Message ID NACK receive processing and generation of RecoveryPath o Message ID NACK receive processing and generation of RecoveryPath
messages messages
o Receive processing of RecoveryPath messages o Receive processing of RecoveryPath messages
Actual processing MAY result in the above occurring in an interlaced Actual processing MAY result in the above occurring in an interlaced
fashion when multiple LSPs are being recovered. Both the restarted fashion when multiple LSPs are being recovered. Both the restarted
node and the downstream RSVP neighbor MUST be able to process in this node and the downstream RSVP neighbor MUST be able to process in this
fashion. fashion.
5.3.1 Generation of RecoveryPath-related Srefresh Messages 5.3.1. Generation of RecoveryPath-related Srefresh Messages
A neighbor of a restarting node generates one or more RecoveryPath- A neighbor of a restarting node generates one or more RecoveryPath-
related Srefresh messages when the S-bit is set in the restarted related Srefresh messages when the S-bit is set in the restarted
node's Hello messages as described in Section 5.2.1. The procedures node's Hello messages as described in Section 5.2.1. The procedures
for generating an Srefresh message are defined in [RFC2961]. Only for generating an Srefresh message are defined in [RFC2961]. Only
modifications to these procedures are described in this section. modifications to these procedures are described in this section.
Also, Srefresh message transmit and receive processing may occur Also, Srefresh message transmit and receive processing may occur
simultaneously during the Recovery Period and are not impacted by the simultaneously during the Recovery Period and are not impacted by the
procedures defined in this section. procedures defined in this section.
skipping to change at page 19, line 7 skipping to change at page 19, line 12
retransmission, the Srefresh message SHOULD be updated to exclude the retransmission, the Srefresh message SHOULD be updated to exclude the
Message ID's of Path state that has been updated by the receipt of a Message ID's of Path state that has been updated by the receipt of a
Path message. Path message.
To allow sufficient processing time for the restarted node, the To allow sufficient processing time for the restarted node, the
downstream RSVP neighbor MAY choose to generate multiple downstream RSVP neighbor MAY choose to generate multiple
RecoveryPath-related Srefresh messages containing partial but RecoveryPath-related Srefresh messages containing partial but
mutually exclusive sets of Message Identifiers spread across 1/4 of mutually exclusive sets of Message Identifiers spread across 1/4 of
the Recovery Time advertised by the restarted node. the Recovery Time advertised by the restarted node.
5.3.2 RecoveryPath-related Srefresh Receive Processing and NACK 5.3.2. RecoveryPath-related Srefresh Receive Processing and NACK
Generation Generation
Upon receiving an Srefresh message containing a MESSAGE_ID LIST Upon receiving an Srefresh message containing a MESSAGE_ID LIST
object with the RecoveryPath Flag set), the restarted node attempts object with the RecoveryPath Flag set), the restarted node attempts
to locate matching previously transmitted Path state. The Epoch in to locate matching previously transmitted Path state. The Epoch in
the MESSAGE_ID LIST object along with each Message Identifier in the the MESSAGE_ID LIST object along with each Message Identifier in the
object is used to match against the MESSAGE_ID object in Path object is used to match against the MESSAGE_ID object in Path
messages previously transmitted to the downstream RSVP neighbor. For messages previously transmitted to the downstream RSVP neighbor. For
each Message Identifier in the MESSAGE_ID LIST: each Message Identifier in the MESSAGE_ID LIST:
skipping to change at page 19, line 36 skipping to change at page 19, line 41
time. time.
If matching transmitted Path state is not found, the restarting If matching transmitted Path state is not found, the restarting
node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. node MUST generate a MESSAGE_ID NACK as defined in [RFC2961].
Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set
(1). (1).
It is recommended that the restarted node combine multiple such It is recommended that the restarted node combine multiple such
MESSAGE_ID NACK's into a single ACK message, per [RFC2961]. MESSAGE_ID NACK's into a single ACK message, per [RFC2961].
5.3.3 RecoveryPath-related MESSAGE_ID NACK Receive Processing 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive Processing
This section defines the procedures associated with the processing of This section defines the procedures associated with the processing of
received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1). received MESSAGE_ID NACK's which have the RecoveryPath Flag set (1).
Procedures for processing of MESSAGE_ID NACK's without the Procedures for processing of MESSAGE_ID NACK's without the
RecoveryPath Flag present are defined in [RFC2961] and not modified RecoveryPath Flag present are defined in [RFC2961] and not modified
in this document. Processing of MESSAGE_ID NACK's with the in this document. Processing of MESSAGE_ID NACK's with the
RecoveryPath Flag set (1) also follows procedures defined in RecoveryPath Flag set (1) also follows procedures defined in
[RFC2961] unless explicitly modified in this section. [RFC2961] unless explicitly modified in this section.
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the
skipping to change at page 20, line 31 skipping to change at page 20, line 36
node carrying one or more LSPs is restarted due to external attacks, node carrying one or more LSPs is restarted due to external attacks,
the procedures introduced in this document provide the ability for the procedures introduced in this document provide the ability for
the restarting RSVP agent to recover the RSVP state corresponding to the restarting RSVP agent to recover the RSVP state corresponding to
the LSPs with the least possible perturbation to the rest of the the LSPs with the least possible perturbation to the rest of the
network. Ideally, only the neighboring RSVP agents should notice the network. Ideally, only the neighboring RSVP agents should notice the
restart and hence need to perform additional processing. This allows restart and hence need to perform additional processing. This allows
for a network with active LSPs to recover LSP state gracefully from for a network with active LSPs to recover LSP state gracefully from
an external attack, without perturbing the data/forwarding plane an external attack, without perturbing the data/forwarding plane
state. state.
[RFC2747] provides mechanisms to protect against external agents from
compromising the RSVP signaling state in an RSVP agent. These
mechanisms, when used with the new message and procedures introduced
in this document, provide the same degree of protection to the
restarting RSVP agent, against installing compromised signaling state
from an external agent during its RSVP signaling state recovery.
The procedures defined in this document introduce additional The procedures defined in this document introduce additional
processing overhead for the RSVP agents that neighbor a restarting processing overhead for the RSVP agents that neighbor a restarting
RSVP agent. If an RSVP agent restarts due to external attacks, such RSVP agent. If an RSVP agent restarts due to external attacks, such
added processing on the neighboring RSVP agents may impact their added processing on the neighboring RSVP agents may impact their
ability to perform other control plane tasks including any processing ability to perform other control plane tasks including any processing
for other LSPs that do not involve the restarting node. Such impact for other LSPs that do not involve the restarting node. Such impact
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
skipping to change at page 22, line 21 skipping to change at page 22, line 31
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, (GMPLS) Signaling Functional Description", RFC 3471,
January 2003. January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Contact Information Authors' Addresses
Arun Satyanarayana Arun Satyanarayana (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853-3206 Phone: +1 408 853-3206
Email: asatyana@cisco.com EMail: asatyana@cisco.com
Reshad Rahman Reshad Rahman (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3519 Phone: 613 254-3519
Email: rrahman@cisco.com EMail: rrahman@cisco.com
Contributors
Lou Berger Lou Berger
Movaz Networks, Inc. LabN Consulting, L.L.C.
7926 Jones Branch Drive
Suite 615 Phone: +1 301 468-9228
McLean, VA 22102 EMail: lberger@labn.net
USA
Phone: +1 703 847-1801
Email: lberger@movaz.com
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3484 Phone: 613 254-3484
Email: ancaz@cisco.com EMail: ancaz@cisco.com
Junaid Israr Junaid Israr
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Dr. 2000 Innovation Dr.
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Phone: 613 254-3693 Phone: 613 254-3693
Email: jisrar@cisco.com EMail: jisrar@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 29 skipping to change at page 24, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgements
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.32pre3 (of http://xml.resource.org/) from a source
in RFC-2629 XML format.
 End of changes. 43 change blocks. 
99 lines changed or deleted 110 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/