< draft-ietf-ccamp-rsvp-restart-ext-08.txt   draft-ietf-ccamp-rsvp-restart-ext-09.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 July 2007
Expires: July 2007 Expires: January 2008
Extensions to GMPLS RSVP Graceful Restart Extensions to GMPLS RSVP Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-08
draft-ietf-ccamp-rsvp-restart-ext-09
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 2, line 8 skipping to change at page 2, line 8
objects. objects.
The extensions defined in this document build on the RSVP Hello The extensions defined in this document build on the RSVP Hello
extensions defined in RFC 3209, and extensions for state recovery on extensions defined in RFC 3209, and extensions for state recovery on
nodal faults defined in RFC 3473. Using these extensions the nodal faults defined in RFC 3473. Using these extensions the
restarting node can recover all previously transmitted Path state restarting node can recover all previously transmitted Path state
including the Explicit Route Object and the downstream (outgoing) including the Explicit Route Object and the downstream (outgoing)
interface identifiers. The extensions can also be used to recover interface identifiers. The extensions can also be used to recover
signaling state after the restart of an ingress node. signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined The extensions optionally support the use of Summary Refresh, defined
in RFC 2961, to reduce the number of messages exchanged during the in 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 LSPs. 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 18 NACK Generation . . . . . . . . . . . . . . . . . . . . 19
5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive 5.3.3. RecoveryPath-related MESSAGE_ID NACK Receive
Processing . . . . . . . . . . . . . . . . . . . . . . . 19 Processing . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . 22
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 4, line 41 skipping to change at page 4, line 41
retaining data/forwarding plane state across the restart of a node or retaining data/forwarding plane state across the restart of a node or
a "nodal fault". [RFC3473] also defines the Recovery Label object a "nodal fault". [RFC3473] also defines the Recovery Label object
for use in the Path message of the RSVP neighbor upstream of a for use in the Path message of the RSVP neighbor upstream of a
restarting node, to indicate that the Path message is for existing restarting node, to indicate that the Path message is for existing
data plane state. data plane state.
This document presents extensions to address two aspects of graceful This document presents extensions to address two aspects of graceful
restart not previously supported. The presented extensions enable a restart not previously supported. The presented extensions enable a
restarting node to recover all objects in previously transmitted Path restarting node to recover all objects in previously transmitted Path
messages including the Explicit Route Object (ERO), from its messages including the Explicit Route Object (ERO), from its
downstream neighbors. The extensions also enable graceful restart of downstream neighbors and so recover control plane state. The
an ingress node that does not preserve full RSVP state across extensions do not facilitate the recovery or creation of
restarts. The presented extensions are equally applicable to LSPs of data/forwarding plane state, and can only be used to re-establish
various switching types as defined in [RFC3471]. control plane state which matches in-place data/forwarding state.
The extensions also enable graceful restart of an ingress node that
does not preserve full RSVP state across restarts. The presented
extensions are equally applicable to LSPs of various switching types
as defined in [RFC3471].
Per [RFC3473], a restarting node can distinguish Path messages Per [RFC3473], a restarting node can distinguish Path messages
associated with LSPs being recovered by the presence of the Recovery associated with LSPs being recovered by the presence of the Recovery
Label object. To determine the downstream (outgoing) interface and Label object. To determine the downstream (outgoing) interface and
associated label(s), the restarting node must consult the data plane. associated label(s), the restarting node must consult the data plane.
This may not be possible for all types of nodes. Furthermore, data This may not be possible for all types of nodes. Furthermore, data
plane information is not sufficient to reconstruct all previously plane information is not sufficient to reconstruct all previously
transmitted Path state. In these cases, the only source of RSVP transmitted Path state. In these cases, the only source of RSVP
state is the downstream RSVP neighbor. state is the downstream RSVP neighbor.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
[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"
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.
There are no changes to the procedures with respect of the
data/forwarding plane as described in [RFC3473]. In particular, a
restarting node MUST NOT create data/forwarding plane state as the
result of any of the extensions defined in this document.
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.
skipping to change at page 11, line 21 skipping to change at page 11, line 25
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
state downstream of the restarted node. state downstream of the restarted node. The restarting node MUST
NOT create data plane or forwarding state to match the received
RecoveryPath message.
The remaining procedures are broken down into three sub-sections. The remaining procedures are broken down into three sub-sections.
The term "resynchronized state", originally defined in [RFC3473], is The term "resynchronized state", originally defined in [RFC3473], is
used and modified in these sections. This term refers to LSP state used and modified in these sections. This term refers to LSP state
that is fully recovered. that is fully recovered.
Signaling state may be recovered from sources other than the Signaling state may be recovered from sources other than the
mechanisms defined in this document. The 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 13, line 18 skipping to change at page 13, line 24
match the Explicit Route object received in the RecoveryPath message. match the Explicit Route object received in the RecoveryPath message.
In addition, the restarted node SHOULD recover state from the other In addition, the restarted node SHOULD recover state from the other
objects received in the RecoveryPath message. Optimally the objects received in the RecoveryPath message. Optimally the
resulting Path message should not cause any redundant or unnecessary resulting Path message should not cause any redundant or unnecessary
re-processing of state along the remaining downstream nodes. re-processing of state along the remaining downstream nodes.
Ideally, except for MESSAGE_ID processing and recovery processing, Ideally, except for MESSAGE_ID processing and recovery processing,
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 received Path
as a setup for a new LSP. The outgoing interface and label(s) message as a setup request for a new LSP. The outgoing interface and
indicated in the RecoveryPath message SHOULD be reused, when label(s) 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. That is, forwarding state MUST NOT be
created except after receipt of a Path message from upstream or, at
an ingress node, the receipt of a command from the management plane.
Further, the forwarding state created is subject to local policy and
the information received from downstream in the RecoveryPath message
is treated only as advisory.
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 has 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
skipping to change at page 19, line 51 skipping to change at page 20, line 18
RSVP hop. This document introduces no new security considerations RSVP hop. This document introduces no new security considerations
beyond those already addressed for existing RSVP hop-by-hop messages. beyond those already addressed for existing RSVP hop-by-hop messages.
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.
This document introduces new procedures to be performed on RSVP This document introduces new procedures to be performed on RSVP
agents that neighbor a restarting RSVP agent. In situations where agents that neighbor a restarting RSVP agent. In situations where
the control plane in general and the RSVP agent in particular of a the control plane in general, and the RSVP agent in particular, of a
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.
skipping to change at page 20, line 40 skipping to change at page 21, line 6
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
Period. Period.
Note that the procedures defined in this document cannot be used to
create false forwarding state. The restarting node that receives a
RecoveryPath message that does not match the existing forwarding
state MUST NOT create or modify its forwarding state to match. A
restarting node SHOULD log such an event or otherwise notify the
operator since it might represent an attack.
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. Sam
Hartman gave careful scrutiny of the security considerations and
the potential impact on the RSVP-TE security trust model.
Adrian Farrel edited the final revisions of this document as it Adrian Farrel edited the final revisions of this document as it
progressed through IESG review. 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
skipping to change at page 21, line 27 skipping to change at page 21, line 49
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 22, line 28 skipping to change at page 22, line 44
(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.
Authors' Addresses Authors' Addresses
Arun Satyanarayana (editor) 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 (editor) 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
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Email: dimitri.Papadimitriou@alcatel-lucent.be
Phone: +32 3 240-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1 301 468-9228 Phone: +1 301 468-9228
EMail: lberger@labn.net EMail: lberger@labn.net
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 26 change blocks. 
32 lines changed or deleted 49 lines changed or added

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