draft-ietf-mpls-tp-cc-cv-rdi-00.txt   draft-ietf-mpls-tp-cc-cv-rdi-01.txt 
MPLS Working Group Dave Allan, Ed. MPLS Working Group Dave Allan, Ed.
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Standards Track Intended status: Standards Track
Expires: December 2010 George Swallow Ed. Expires: January 2011 George Swallow Ed.
Cisco Systems, Inc Cisco Systems, Inc
John Drake Ed. John Drake Ed.
Juniper Juniper
June 1, 2010 July 12, 2010
Proactive Connection Verification, Continuity Check and Remote Proactive Connection Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile Defect indication for MPLS Transport Profile
draft-ietf-mpls-tp-cc-cv-rdi-00 draft-ietf-mpls-tp-cc-cv-rdi-01
Abstract Abstract
Continuity Check (CC), Proactive Connectivity Verification (CV) and Continuity Check (CC), Proactive Connectivity Verification (CV) and
Remote Defect Indication (RDI) functionalities required for are MPLS- Remote Defect Indication (RDI) functionalities required for are MPLS-
TP OAM. TP OAM.
Continuity Check monitors the integrity of the continuity of the path Continuity Check monitors the integrity of the continuity of the path
for any loss of continuity defect. Connectivity verification monitors for any loss of continuity defect. Connectivity verification monitors
the integrity of the routing of the path between sink and source for the integrity of the routing of the path between sink and source for
skipping to change at page 2, line 39 skipping to change at page 2, line 39
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Authors......................................................3 1.1. Authors......................................................4
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
2.1. Terminology..................................................4 2.1. Terminology..................................................4
2.2. Issues for discussion........................................4 2.2. Issues for discussion........................................4
3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5
3.1. ACH code points for CC and proactive CV......................5 3.1. ACH code points for CC and proactive CV......................5
3.2. MPLS BFD CC Message format...................................6 3.2. MPLS BFD CC Message format...................................6
3.3. MPLS BFD proactive CV Message format.........................6 3.3. MPLS BFD proactive CV Message format.........................6
3.4. BFD Session in MPLS-TP terminology...........................7 3.4. BFD Session in MPLS-TP terminology...........................7
3.5. BFD Profile for MPLS-TP......................................7 3.5. BFD Profile for MPLS-TP......................................7
3.5.1. Session initiation.........................................8 3.5.1. Session initiation.........................................8
3.5.2. Defect entry criteria......................................8 3.5.2. Defect entry criteria......................................8
3.5.3. Defect entry consequent action.............................9 3.5.3. Defect entry consequent action............................10
3.5.4. Defect exit criteria.......................................9 3.5.4. Defect exit criteria......................................10
3.5.5. Configuration of MPLS-TP BFD sessions.....................10 3.5.5. State machines............................................10
3.5.6. Discriminator values......................................10 3.5.6. Configuration of MPLS-TP BFD sessions.....................13
4. Acknowledgments...............................................10 3.5.7. Discriminator values......................................13
5. IANA Considerations...........................................10 4. Acknowledgments...............................................13
6. Security Considerations.......................................11 5. IANA Considerations...........................................14
7. References....................................................11 6. Security Considerations.......................................14
7.1. Normative References........................................11 7. References....................................................14
7.2. Informative References......................................11 7.1. Normative References........................................14
7.2. Informative References......................................15
1. Introduction 1. Introduction
In traditional transport networks, circuits are provisioned on two or In traditional transport networks, circuits are provisioned on two or
more switches. Service Providers (SP) need OAM tools to detect mis- more switches. Service Providers (SP) need OAM tools to detect mis-
connectivity and loss of continuity of transport circuits. Both PWs connectivity and loss of continuity of transport circuits. Both PWs
and MPLS-TP LSPs [6] emulating traditional transport circuits need to and MPLS-TP LSPs [7] emulating traditional transport circuits need to
provide the same CC and proactive CV capabilities as required in provide the same CC and proactive CV capabilities as required in
draft-ietf-mpls-tp-oam-requirements[3]. This document describes the draft-ietf-mpls-tp-oam-requirements[3]. This document describes the
use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between
two Maintenance Entity Group End Points (MEPs). two Maintenance Entity Group End Points (MEPs).
As described in [8], Continuity Check (CC) and Proactive Connectivity As described in [9], Continuity Check (CC) and Proactive Connectivity
Verification (CV) functions are used to detect loss of continuity Verification (CV) functions are used to detect loss of continuity
(LOC), and unintended connectivity between two MEPs (e.g. mismerging (LOC), and unintended connectivity between two MEPs (e.g. mismerging
or misconnection or unexpected MEP). or misconnection or unexpected MEP).
The Remote Defect Indication (RDI) is an indicator that is The Remote Defect Indication (RDI) is an indicator that is
transmitted by a MEP to communicate to its peer MEP that a signal transmitted by a MEP to communicate to its peer MEP that a signal
fail condition exists. RDI is only used for bidirectional connections fail condition exists. RDI is only used for bidirectional connections
and is associated with proactive CC & CV packet generation. and is associated with proactive CC & CV packet generation.
This document specifies the BFD extension and behavior to satisfy the This document specifies the BFD extension and behavior to satisfy the
skipping to change at page 4, line 46 skipping to change at page 4, line 51
PW: Pseudo Wire PW: Pseudo Wire
RDI: Remote Defect Indication. RDI: Remote Defect Indication.
TTL: Time To Live TTL: Time To Live
TLV: Type Length Value TLV: Type Length Value
2.2. Issues for discussion 2.2. Issues for discussion
1) Requirement for additional BFD diagnostic codes 1) Requirement for additional BFD diagnostic codes?
1. When periodicity of CV cannot be supported 1. When periodicity of CV cannot be supported
2. For mis-connectivity defect
2) Do we continue to separate CC and CV as separate functions, or
collapse them into a single CC+CV behavior given CV is a superset
of CC?
3) Is receipt of an unexpected discriminator really a problem?
3. MPLS CC, proactive CV and RDI Mechanism using BFD 3. MPLS CC, proactive CV and RDI Mechanism using BFD
This document proposes distinct encapsulations and code points for This document proposes distinct encapsulations and code points for
BFD depending on whether the mode of operation is CC or CV: BFD depending on whether the mode of operation is CC or CV:
o CC mode: defines a new code point in the Associated Channel Header o CC mode: defines a new code point in the Associated Channel Header
(ACH) described in [2].In this mode Continuity Check and RDI (ACH) described in [2].In this mode Continuity Check and RDI
functionalities are supported. functionalities are supported.
o CV mode: defines a new code point in the Associated Channel Header o CV mode: defines a new code point in the Associated Channel Header
skipping to change at page 7, line 8 skipping to change at page 7, line 5
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS CV Message Figure 3: MPLS CV Message
As shown in Figure 3, BFD Control packet as defined in [4] is As shown in Figure 3, BFD Control packet as defined in [4] is
transmitted as MPLS labeled packets along with ACH, ACH TLV Header transmitted as MPLS labeled packets along with ACH, ACH TLV Header
defined in Section 3 of RFC 5586 and one ACH TLV object carrying the defined in Section 3 of RFC 5586 and one ACH TLV object carrying the
unique MEP Identifier of the source of the BFD packet defined in [7] unique MEP Identifier of the source of the BFD packet defined in [8].
When GAL label is used, the TTL field of the GAL MUST be set to at When GAL label is used, the TTL field of the GAL MUST be set to at
least 1, and the GAL will be the end of stack label (S=1). least 1, and the GAL will be the end of stack label (S=1).
3.4. BFD Session in MPLS-TP terminology 3.4. BFD Session in MPLS-TP terminology
A BFD session corresponds to a CC or a proactive CV OAM instance in A BFD session corresponds to a CC or a proactive CV OAM instance in
MPLS-TP terminology. MPLS-TP terminology.
A BFD session is enabled when the CC or proactive CV functionality is A BFD session is enabled when the CC or proactive CV functionality is
skipping to change at page 7, line 47 skipping to change at page 7, line 44
circumstance where an operator has a reason to change session circumstance where an operator has a reason to change session
parameters, poll/final discipline is used. parameters, poll/final discipline is used.
The transport profile is designed to operate independent of the The transport profile is designed to operate independent of the
control plane; hence the C bit SHOULD be set. control plane; hence the C bit SHOULD be set.
This document specifies bi-directional BFD for p2p transport paths, This document specifies bi-directional BFD for p2p transport paths,
hence the M bit MUST be clear. hence the M bit MUST be clear.
There are two modes of operation for bi-directional paths. One in There are two modes of operation for bi-directional paths. One in
which both directions of the path fate share and one constructed from which the session state of both directions of the path is coordinated
BFD sessions in such a way that the two directions operate and one constructed from BFD sessions in such a way that the two
independently. A single bi-directional BFD session is used for fate directions operate independently. A single bi-directional BFD session
sharing operation. Two independent BFD sessions are used for is used for coordinated operation. Two independent BFD sessions are
independent operation. used for independent operation.
Fate sharing operation is as described in [4]. Independent operation Coordinated operation is as described in [4]. Independent operation
requires clarification of two aspects of [4]. Independent operation requires clarification of two aspects of [4]. Independent operation
is characterized by the setting of MinRxInterval to zero by the MEP is characterized by the setting of MinRxInterval to zero by the MEP
that is typically the session originator, and there will be a session that is typically the session originator (referred to as the source
originator at either end of the bi-directional path. MEP), and there will be a session originator at either end of the bi-
directional path. Each source MEP will have a corresponding sink MEP
that has been configured to a Tx interval of zero.
The base spec is unclear on aspects of how a session with a BFD The base spec is unclear on aspects of how a MEP with a BFD transmit
source set to zero interval behaves. One interpretation is that no rate set to zero behaves. One interpretation is that no periodic
periodic messages originate with that source, it will only originate messages originate with that MEP, it will only originate messages on
messages on a state change. a state change.
The first clarification is that when a state change occurs a zero The first clarification is that when a state change occurs a MEP set
interval source send BFD control messages with a one second period to a transmit rate of zero sends BFD control messages with a one
until such time that the state change is confirmed by the session second period until such time that the state change is confirmed by
peer. At this point the zero interval source can resume quiescent the session peer. At this point the MEP set to a transmit rate of
behavior. This adds robustness to all state transitions in the zero can resume quiescent behavior. This adds robustness to all state
RxInterval=0 case. transitions in the RxInterval=0 case.
The second is that the originating MEP (the one with a non-zero The second is that the originating MEP (the one with a non-zero
TxInterval) will ignore a DOWN state received from a zero interval TxInterval) will ignore a DOWN state received from a zero interval
peer. This means that the zero interval peer will continue to send peer. This means that the zero interval peer will continue to send
DOWN state messages as the state change is never confirmed. This adds DOWN state messages as the state change is never confirmed. This adds
robustness to the exchange of RDI indication on a uni-directional robustness to the exchange of RDI indication on a uni-directional
failure (for both session types DOWN with a diagnostic of control failure (for both session types DOWN with a diagnostic of control
detection period expired offering RDI functionality). detection period expired offering RDI functionality).
The normal usage is that 1:1 protected paths must use fate sharing, A further extension to the base specification is that there are
and independent operation applies to 1+1 protected paths. additional OAM protocol exchanges that act as inputs to the BFD state
machine; these are the Link Down Indication [6] and the Lock
Instruct/Lock Report transactions.
3.5.1. Session initiation 3.5.1. Session initiation
In all scenarios a BFD session starts with both ends in the DOWN In all scenarios a BFD session starts with both ends in the DOWN
state. DOWN state messages exchanged include the desired Tx and Rx state. DOWN state messages exchanged include the desired Tx and Rx
rates for the session. If a node cannot support the Min Tx rate rates for the session. If a node cannot support the Min Tx rate
desired by a peer MEP it does not transition from down to the INIT desired by a peer MEP it does not transition from down to the INIT
state and sends a diagnostic code (TBD) indicating that the requested state and sends a diagnostic code (TBD) indicating that the requested
Tx rate cannot be supported. Tx rate cannot be supported.
Otherwise once a transition from DOWN to INIT has occurred, the Otherwise once a transition from DOWN to INIT has occurred, the
session progresses as per [4]. session progresses as per [4].
3.5.2. Defect entry criteria 3.5.2. Defect entry criteria
There are further defect criteria beyond that defined in [4] to There are further defect criteria beyond that defined in [4] to
consider given the possibility of mis-connectivity and mis- consider given the possibility of mis-connectivity and mis-
configuration defects. The result is the criteria for a path configuration defects. The result is the criteria for a path
direction to transition from the defect free state to a defect state direction to transition from the defect free state to a defect state
is a superset of that in the BFD base specification [4]. is a superset of that in the BFD base specification [4].
The following conditions cause a MEP to enter the defect state for CC
The following conditions case a MEP to enter the defect state: of CV:
1. BFD session times out (Loss of Continuity defect), 1. BFD session times out (Loss of Continuity defect),
2. BFD control packets are received with an unexpected 2. Receipt of a link down indication.
3. Receipt of an unexpected M bit (Session Mis-configuration
defect),
And the following will cause the MEP to enter the defect state for CV
operation
1. BFD control packets are received with an unexpected
encapsulation (Mis-connectivity defect), these include encapsulation (Mis-connectivity defect), these include
- a PW receiving a packet with a GAL - a PW receiving a packet with a GAL
- an LSP receiving an IP header instead of a GAL - an LSP receiving an IP header instead of a GAL
(note there are other possibilities but these can also alias (note there are other possibilities but these can also alias
3. Receipt of an unexpected globally unique Source MEP identifier 2. Receipt of an unexpected globally unique Source MEP identifier
(Mis-connectivity defect), (Mis-connectivity defect),
4. Receipt of an unexpected session discriminator (Mis-connectivity 3. Receipt of an unexpected session discriminator in the your
defect) discriminator field (Mis-connectivity defect),
5. Receipt of an unexpected M bit (Session Mis-configuration 4. Receipt of an expected session discriminator with an unexpected
defect) label (mis-connectivity defect),
The effective defect hierarchy (order of checking) is The effective defect hierarchy (order of checking) is
1. Receiving nothing 1. Receiving nothing
2. Receiving from an incorrect source (determined by whatever 2. Receiving link down indication
3. Receiving from an incorrect source (determined by whatever
means) means)
3. Receiving from a correct source (as near as can be determined), 4. Receiving from a correct source (as near as can be determined),
but with incorrect session information) but with incorrect session information)
4. Receiving control packets in all discernable ways correct. 5. Receiving control packets in all discernable ways correct.
3.5.3. Defect entry consequent action 3.5.3. Defect entry consequent action
Upon defect entry a sink MEP will assert signal fail into any client Upon defect entry a sink MEP will assert signal fail into any client
(sub-)layers. It will also communicate session DOWN to its session (sub-)layers. It will also communicate session DOWN to its session
peer. peer.
The blocking of traffic as consequent action MUST be driven only by a The blocking of traffic as consequent action MUST be driven only by a
defect's consequent action as specified in draft-ietf-mpls-tp-oam- defect's consequent action as specified in draft-ietf-mpls-tp-oam-
framework [8] section 5.1.1.2. framework [9] section 5.1.1.2.
When the defect is mis-braching, the transport path termination will When the defect is mis-branching, the transport path termination will
silently discard all non-oam traffic received. silently discard all non-oam traffic received.
3.5.4. Defect exit criteria 3.5.4. Defect exit criteria
Exit from a Loss of continuity defect Exit from a Loss of continuity defect
For a fate sharing session exit from a loss of connectivity defect is For a coordinated session, exit from a loss of connectivity defect is
as described in [4]. as described in figure 4 which updates [4].
For an independent session, exit from a loss of connectivity defect For an independent session, exit from a loss of connectivity defect
occurs upon receipt of a well formed control packet from the peer occurs upon receipt of a well formed control packet from the peer MEP
MEP. as described in figures 5 and 6.
Exit from a session mis-configuration defect Exit from a session mis-configuration defect
[editors: for a future version of the document] [editors: for a future version of the document]
Exit from a mis-connectivity defect Exit from a mis-connectivity defect
The exit criteria for a mis-connectivity defect is determined by the The exit criteria for a mis-connectivity defect is determined by the
maximum of the set of min Rx session time times the multiplier that maximum of the set of min Rx session time times the multiplier that
have been received. A session can transition from DOWN to UP have been received. A session can transition from DOWN to UP
(independent mode) or DOWN to INIT (fate sharing mode) when both (independent mode) or DOWN to INIT (coordinated mode) when both
correctly formed control packets are being exchanged, and no mis- correctly formed control packets are being exchanged, and no mis-
connected control packets have been received in the specified connected control packets have been received in the specified
interval. interval.
3.5.5. Configuration of MPLS-TP BFD sessions 3.5.5. State machines
[Editors note, for a future revision of the document] The following state machines update [4]. They have been modified to
include LDI and LKI as inputs to the state machine and to clarify the
behavior for independent mode.
3.5.6. Discriminator values The coordinated session state machine has been augmented to indicate
LDI and LKR as inputs to the state machine. For a session that is in
the UP state, receipt of LDI or LKR will transition the session into
the DOWN state.
MPLS labels at peer MEPs are used to provide context for the received [Dave: I have to think that we do not need to consider LDI/LKR for
BFD packets. transition from DOWN to INIT, I have to receive a BFD control packet
to do that which means the condition is cleared, only funky case is
when I'm getting both UP messages and LDI/LKR]
+--+
| | UP, ADMIN DOWN, TIMER, LDI/LKR
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| |
V |LDI/LKR LDI/LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 4: State machine for coordinated session operation
For independent mode, there are two state machines. One for the
source MEP (who requested MinRxInterval=0) and the sink MEP (who
agreed to MinRxInterval=0).
The source MEP will not transition out of the UP state once
initialized except in the case of a forced ADMIN DOWN. Hence LDI/LKR
do not enter into the state machine transition from the UP state, but
do enter into the INIT and DOWN states.
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN | |
| |ADMIN DOWN, | |
| |TIMER, | |
V |LDI/LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ LDI/LKR
+------+ +------+
Figure 5: State machine for source MEP for independent session
operation
The sink MEP state machine (for which the transmit interval has been
set to zero) is modified to:
1) Permit direct transition from DOWN to UP once the session has been
initialized. With the exception of via the ADMIN DOWN state, the
source MEP will never transition from the UP state, hence in normal
unidirectional fault scenarios will never transition to the INIT
state.
+--+
| | ADMIN DOWN, TIMER, LDI/LKR
| V
DOWN +------+ INIT, UP
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | |
V |LDI/LKR LDI/LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 6: State machine for the sink MEP for independent session
operation
3.5.6. Configuration of MPLS-TP BFD sessions
[Editors note, for a future revision of the document]
3.5.7. Discriminator values
In the BFD control packet the discriminator values have either local In the BFD control packet the discriminator values have either local
or no significance. to the sink MEP or no significance (when not known).
My Discriminator field MUST be set to a nonzero value (it can be a My Discriminator field MUST be set to a nonzero value (it can be a
fixed value), the transmitted your discriminator value MUST reflect fixed value), the transmitted your discriminator value MUST reflect
back the received value of My discriminator field or be set to 0 if back the received value of My discriminator field or be set to 0 if
that value is not known. that value is not known.
Although the BFD base specification permits an implementation to
change the my discriminator field at arbitrary times, this is not
permitted for CV mode in order to avoid race conditions in mis-
connectivity defects.
4. Acknowledgments 4. Acknowledgments
To be added in a later version of this document To be added in a later version of this document
5. IANA Considerations 5. IANA Considerations
To be added in a later version of this document To be added in a later version of this document
6. Security Considerations 6. Security Considerations
skipping to change at page 11, line 35 skipping to change at page 14, line 39
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
5586 , June 2009 5586 , June 2009
[3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for
Operations Administration and Maintenance in MPLS Operations Administration and Maintenance in MPLS
Transport Networks", RFC5860, May 2010 Transport Networks", RFC5860, May 2010
[4] Katz, D. and D. Ward, "Bidirectional Forwarding [4] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-11 (work in progress), Detection", RFC 5880, June 2010
February 2009
[5] Boutros, S. et al., "Definition of ACH TLV Structure", [5] Boutros, S. et al., "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March
2010 2010
[6] Swallow, G. et al., "MPLS Fault Management OAM", draft-
ietf-mpls-tp-fault-02 (work in progress), July 2010
7.2. Informative References 7.2. Informative References
[6] Bocci, M., et al., "A Framework for MPLS in Transport [7] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-12, (work in Networks", RFC5921, July 2010
progress), May 2010
[7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- [8] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
swallow-mpls-tp-identifiers-02 (work in progress), March swallow-mpls-tp-identifiers-02 (work in progress), July
2010 2010
[8] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM [9] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM
Framework", draft-ietf-mpls-tp-oam-framework-06 (work in Framework", draft-ietf-mpls-tp-oam-framework-06 (work in
progress), April 2010 progress), April 2010
Authors' Addresses Authors' Addresses
Dave Allan Dave Allan
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
John Drake John Drake
 End of changes. 38 change blocks. 
79 lines changed or deleted 186 lines changed or added

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