< draft-eastlake-sfc-nsh-ecn-support-02.txt   draft-eastlake-sfc-nsh-ecn-support-03.txt >
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Huawei Intended status: Proposed Standard Huawei
Bob Briscoe Bob Briscoe
Independent Independent
Andrew Malis Andrew Malis
Huawei Huawei
Expires: April 20, 2019 October 21, 2018 Expires: August 4, 2019 February 5, 2019
Explicit Congestion Notification (ECN) and Congestion Feedback Explicit Congestion Notification (ECN) and Congestion Feedback
Using the Network Service Header (NSH) Using the Network Service Header (NSH)
<draft-eastlake-sfc-nsh-ecn-support-02.txt> <draft-eastlake-sfc-nsh-ecn-support-03.txt>
Abstract Abstract
Explicit congestion notification (ECN) allows a forwarding element to Explicit congestion notification (ECN) allows a forwarding element to
notify downstream devices of the onset of congestion without having notify downstream devices of the onset of congestion without having
to drop packets. Coupled with a means to feed back information about to drop packets. Coupled with a means to feed back information about
congestion to upstream nodes, this can improve network efficiency congestion to upstream nodes, this can improve network efficiency
through better congestion control, frequently without packet drops. through better congestion control, frequently without packet drops.
This document specifies ECN and congestion feedback support through This document specifies ECN and congestion feedback support within a
use of the Network Service Header (NSH, RFC 8300) and IP Flow Service Function Chaining (SFC) domain through use of the Network
Information Export (IPFIX, draft-ietf-tsvwg-tunnel-congestion- Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX,
feedback). draft-ietf-tsvwg-tunnel-congestion-feedback).
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the SFC Working Group mailing list <sfc@ietf.org> or to the to the SFC Working Group mailing list <sfc@ietf.org> or to the
authors. authors.
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 2, line 13 skipping to change at page 2, line 13
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction............................................3
1.1 NSH Background.........................................3 1.1 NSH Background.........................................3
1.2 ECN Background.........................................5 1.2 ECN Background.........................................5
1.3 Tunnel Congestion Feedback Background..................5 1.3 Tunnel Congestion Feedback Background..................5
1.4 Conventions Used in This Document......................6 1.4 Conventions Used in This Document......................7
2. The NSH ECN Field.......................................8 2. The NSH ECN Field.......................................8
3. ECN Support in the NSH.................................10 3. ECN Support in the NSH.................................10
3.1 At The Ingress........................................11 3.1 At The Ingress........................................11
3.2 At Transit Nodes......................................11 3.2 At Transit Nodes......................................12
3.2.1 At NSH Transit Nodes................................12 3.2.1 At NSH Transit Nodes................................12
3.2.2 At an SF/Proxy......................................12 3.2.2 At an SF/Proxy......................................13
3.2.3 At Other Forwarding Nodes...........................13 3.2.3 At Other Forwarding Nodes...........................13
3.3 At Exit/Egress........................................13 3.3 At Exit/Egress........................................13
3.4 Conservation of Packets...............................14 3.4 Conservation of Packets...............................14
4. Tunnel Congestion Feedback Support.....................15 4. Tunnel Congestion Feedback Support.....................15
5. IANA Considerations....................................16 5. IANA Considerations....................................16
6. Security Considerations................................17 6. Security Considerations................................17
7. Acknowledgements.......................................17 7. Acknowledgements.......................................17
skipping to change at page 3, line 15 skipping to change at page 3, line 15
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
1. Introduction 1. Introduction
Explicit congestion notification (ECN [RFC3168]) allows a forwarding Explicit congestion notification (ECN [RFC3168]) allows a forwarding
element to notify downstream devices of the onset of congestion element to notify downstream devices of the onset of congestion
without having to drop packets. Coupled with a means to feed back without having to drop packets. Coupled with a means to feed back
information about congestion to upstream nodes, this can improve information about congestion to upstream nodes, this can improve
network efficiency through better congestion control, frequently network efficiency through better congestion control, frequently
without packet drops. This document specifies ECN and congestion without packet drops. This document specifies ECN and congestion
feedback support through use of the Network Service Header (NSH feedback support within a Service Function Chaining (SFC [RFC7665])
[RFC8300]) and IP Flow Information Export (IPFIX domain through use of the Network Service Header (NSH [RFC8300]) and
[TunnelCongFeedback]). IP Flow Information Export (IPFIX [TunnelCongFeedback]).
This section provides background information on NSH, ECN, congestion It requires that all ingress and egress nodes of the SFC domain
feedback, and terminology used in this document. implement ECN. While congestion management will be the most effective
if all interior nodes of the SFC domain implement ECN, some benefit
is obtained even if some interior nodes do not implement ECN. In
particular, congestion at any bottleneck where ECN marking is not
implemented will be unmanaged.
The subsections below in this is section provide background
information on NSH, ECN, congestion feedback, and terminology used in
this document.
1.1 NSH Background 1.1 NSH Background
The Service Function Chaining (SFC [RFC7665]) architecture calls for The Service Function Chaining (SFC [RFC7665]) architecture calls for
the encapsulation of traffic within a service function chaining the encapsulation of traffic within a service function chaining
domain with a Network Service Header (NSH [RFC8300]) added by the domain with a Network Service Header (NSH [RFC8300]) added by the
"Classifier" (ingress node) on entry to the domain and the NSH being "Classifier" (ingress node) on entry to the domain and the NSH being
removed on exit from the domain at the egress node. The NSH is used removed on exit from the domain at the egress node. The NSH is used
to control the path of a packet in an SFC domain. The NSH is a to control the path of a packet in an SFC domain. The NSH is a
natural way, in a domain where traffic is NSH encapsulated, to note natural place, in a domain where traffic is NSH encapsulated, to note
congestion, avoiding possible confusion due, for example, to changes congestion, avoiding possible confusion due, for example, to changes
in the outer transport header in different parts of the domain. in the outer transport header in different parts of the domain.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
| |
v v
+----------+ +----------+
. .|Classifier|. . . . . . . . . . . . . . . .|Classifier|. . . . . . . . . . . . . .
. +----------+ . . +----------+ .
skipping to change at page 5, line 26 skipping to change at page 5, line 26
congestion without having to drop packets. This can be used as an congestion without having to drop packets. This can be used as an
element in active queue management (AQM) [RFC7567] to improve network element in active queue management (AQM) [RFC7567] to improve network
efficiency through better traffic control without packet drops. The efficiency through better traffic control without packet drops. The
forwarding element can explicitly mark some packets in an ECN field forwarding element can explicitly mark some packets in an ECN field
instead of dropping the packet. For example, a two-bit field is instead of dropping the packet. For example, a two-bit field is
available for ECN marking in IP headers [RFC3168]. available for ECN marking in IP headers [RFC3168].
1.3 Tunnel Congestion Feedback Background 1.3 Tunnel Congestion Feedback Background
Tunnel Congestion Feedback [TunnelCongFeedback] is a building block Tunnel Congestion Feedback [TunnelCongFeedback] is a building block
for various congestion mitigation methods that supports feedback of for various congestion mitigation methods. It supports feedback of
congestion information from an egress node to an ingress node. congestion information from an egress node to an ingress node.
Examples of actions that can be taken by an ingress node when it has Examples of actions that can be taken by an ingress node when it has
knowledge of downstream congestion include those listed below. knowledge of downstream congestion include those listed below.
Details of implementing these traffic control methods, beyond those Details of implementing these traffic control methods, beyond those
given here, are outside the scope of this document. given here, are outside the scope of this document.
Any action by the ingress to reduce congestion needs to allow
sufficient time for the end-to-end congestion control loop to respond
first, for instance by the ingress taking a smoothed average of the
level of congestion signalled by feedback from the tunnel egress.
(1) Traffic throttling (policing), where the downstream traffic (1) Traffic throttling (policing), where the downstream traffic
flowing out of the ingress node is limited to reduce or eliminate flowing out of the ingress node is limited to reduce or eliminate
congestion. congestion.
(2) Upstream congestion feedback, where the ingress node sends (2) Upstream congestion feedback, where the ingress node sends
messages upstream to or towards the ultimate traffic source, a messages upstream to or towards the ultimate traffic source, a
function that can throttle traffic generation/transmission. function that can throttle traffic generation/transmission.
(3) Traffic re-direction, where the ingress node configures the NSH (3) Traffic re-direction, where the ingress node configures the NSH
of some future traffic so that it avoids congested paths. of some future traffic so that it avoids congested paths. Great
care must be taken to avoid (a) significant re-ordering of
NOTE: With this method 3 great care must be taken to avoid (a) traffic in flows that it is desirable to keep in order and (b)
significant re-ordering of traffic in flows that it is desirable oscillation/instability in traffic paths due to alternate
to keep in order and (b) oscillation/instability in traffic paths congestion of previously idle paths and the idling of previously
due to alternate congestion of previously idle paths and the congested paths. For example, it is preferable to classify
idling of previously congested paths. For example, it is
preferable to classify traffic into flows or a sufficiently
coarse granularity that the flows are long lived and use a stable
path per flow sending only newly appearing flows on apparently
uncongested paths.
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
traffic into flows of a sufficiently coarse granularity that the
flows are long lived and use a stable path per flow sending only
newly appearing flows on apparently uncongested paths.
Figure 2 shows an example path from an origin sender to a final Figure 2 shows an example path from an origin sender to a final
receiver passing through an example chain of service functions receiver passing through an example chain of service functions
between the ingress and egress of an SFC domain. The path is also between the ingress and egress of an SFC domain. The path is also
likely to pass through other network nodes outside the SFC domain likely to pass through other network nodes outside the SFC domain
(not shown). The figure shows typical congestion feedback that would (not shown). The figure shows typical congestion feedback that would
be expected from the final receiver to the origin sender, which be expected from the final receiver to the origin sender, which
controls the load the origin sender applies to all elements on the controls the load the origin sender applies to all elements on the
path. The figure also shows the congestion feedback from the egress path. The figure also shows the congestion feedback from the egress
to the ingress of the SFC domain that is described in this document, to the ingress of the SFC domain that is described in this document,
to control or balance load within the SFC domain. to control or balance load within the SFC domain.
skipping to change at page 6, line 49 skipping to change at page 7, line 5
|SF | |SF | |SF | |SF |
+---+ +---+ +---+ +---+
Figure 2: Congestion Feedback across an SFC Domain Figure 2: Congestion Feedback across an SFC Domain
SFC Domain congestion feedback in Figure 2 is shown within the SFC Domain congestion feedback in Figure 2 is shown within the
context of an end-to-end congestion feedback loop. Also shown is the context of an end-to-end congestion feedback loop. Also shown is the
encapsulated layering of NSH headers within a series of outer encapsulated layering of NSH headers within a series of outer
transport headers (OT1, OT2, ... OTn). transport headers (OT1, OT2, ... OTn).
INTERNET-DRAFT NSH ECN & Congestion Feedback
1.4 Conventions Used in This Document 1.4 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
INTERNET-DRAFT NSH ECN & Congestion Feedback
document are to be interpreted as described in [RFC2119] [RFC8174] document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
Acronyms: Acronyms:
AQM - Active Queue Management [RFC7567] AQM - Active Queue Management [RFC7567]
CE - Congestion Experienced [RFC3168] CE - Congestion Experienced [RFC3168]
downstream - The direction from ingress to egress downstream - The direction from ingress to egress
skipping to change at page 10, line 24 skipping to change at page 10, line 24
While this section covers all combinations of ECN-aware and not ECN- While this section covers all combinations of ECN-aware and not ECN-
aware, it is expected that in most cases the NSH domain will be aware, it is expected that in most cases the NSH domain will be
uniform so that, if this document is applicable, all SFFs will uniform so that, if this document is applicable, all SFFs will
support ECN; however, some legacy SFs might not support ECN. support ECN; however, some legacy SFs might not support ECN.
ECN Propagation: ECN Propagation:
The specification of ECN tunneling [RFC6040] explains that an The specification of ECN tunneling [RFC6040] explains that an
ingress must not propagate ECN support into an encapsulating ingress must not propagate ECN support into an encapsulating
header unless the egress supports correct onward propagation of header unless the egress supports correct onward propagation of
the ECN field during decapsulation. We define Compliant ECN the ECN field during decapsulation. We define Compliant ECN
Decapsulation here as decapsulation compliant with either Decapsulation here as decapsulation compliant with either
[RFC6040] or an earlier compatible equivalent ([RFC4301], or full [RFC6040] or an earlier compatible equivalent ([RFC4301], or full
functionality mode of [RFC3168]). functionality mode of [RFC3168]).
The procedures in Section 3.2.1 ensure that each ingress of the The procedures in Section 3.2.1 ensure that each ingress of the
large number of possible transport links within the SFC domain large number of possible transport links within the SFC domain
does not propagate ECN support into the encapsulating outer does not propagate ECN support into the encapsulating outer
transport header unless the corresponding egress of that link transport header unless the corresponding egress of that link
supports Compliant ECN Decapsulation. supports Compliant ECN Decapsulation.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
3.1 At The Ingress 3.1 At The Ingress
When the ingress/Classifier encapsulates an incoming IP packet with When the ingress/Classifier encapsulates an incoming IP packet with
an NSH, it MUST set the NSH ECN field using the "Normal mode" an NSH, it MUST set the NSH ECN field using the "Normal mode"
specified in [RFC6040] (i.e., copied from the incoming IP header). specified in [RFC6040] (i.e., copied from the incoming IP header).
Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
set it to ECT(0), in order to indicate that the NSH encapsulation is set it to ECT(0). This indicates that, even though the end-to-end
an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH transport is not ECN-capable, the egress and ingress of the SFC
domain supports the experimental L4S capability [RFC8311], [ecnL4S]. domain are acting as an ECN-capable transport. This approach will
inherently support all known variatns of ECN, including the
experimental L4S capability [RFC8311], [ecnL4S].
Packets arriving at the ingress might not use IP. If the protocol of Packets arriving at the ingress might not use IP. If the protocol of
arriving packets supports an ECN field similar to IP, the procedures arriving packets supports an ECN field similar to IP, the procedures
for IP packets can be used. If arriving packets do not support an ECN for IP packets can be used. If arriving packets do not support an ECN
field similar to IP, they MUST be treated as if they are Not-ECT IP field similar to IP, they MUST be treated as if they are Not-ECT IP
packets. packets.
Then, as the NSH encapsulated packet is further encapsulated with a Then, as the NSH encapsulated packet is further encapsulated with a
transport header, if ECN marking is available for that transport (as transport header, if ECN marking is available for that transport (as
it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the
transport header MUST be set using the "Normal mode" specified in transport header MUST be set using the "Normal mode" specified in
[RFC6040] (i.e., copied from the NSH ECN field). [RFC6040] (i.e., copied from the NSH ECN field).
A summary of these normative steps is given in Table 2. A summary of these normative steps is given in Table 2.
+-----------------+-------------------------------+ +-----------------+---------------+
| Incoming Header |Departing NSH and Outer Headers| | Incoming Header | Departing NSH |
| (also equal to +---------------+---------------+ | (also equal to | and Outer |
| departing Inner | Classic ECN | L4S ECN | | departing Inner | Headers |
| Header) | Mode | Mode | | Header) | |
+-----------------+---------------+---------------+ +-----------------+---------------+
| Not-ECT | ECT(0) | ECT(1) | | Not-ECT | ECT(0) |
| ECT(0) | ECT(0) | ECT(0) | | ECT(0) | ECT(0) |
| ECT(1) | ECT(1) | ECT(1) | | ECT(1) | ECT(1) |
| CE | CE | CE | | CE | CE |
+-----------------+---------------+---------------+ +-----------------+---------------+
Table 2. Setting of ECN fields by an ingress/Classifier Table 2. Setting of ECN fields by an ingress/Classifier
The requirements in this section apply to all ingress nodes for the The requirements in this section apply to all ingress nodes for the
domain in which NSH is being used to route traffic. domain in which NSH is being used to route traffic.
INTERNET-DRAFT NSH ECN & Congestion Feedback
3.2 At Transit Nodes 3.2 At Transit Nodes
This section described behavior at nodes that forward based on the This section described behavior at nodes that forward based on the
NSH such as SFF and other forwarding nodes such as IP routers. Figure NSH such as SFF and other forwarding nodes such as IP routers. Figure
5 shows a packet on the wire between forwarding nodes. 5 shows a packet on the wire between forwarding nodes.
INTERNET-DRAFT NSH ECN & Congestion Feedback
+-----------------+ +-----------------+
| Outer Header | | Outer Header |
+-----------------+ +-----------------+
| NSH | | NSH |
+-----------------+ +-----------------+
| Inner Header | | Inner Header |
+-----------------+ +-----------------+
| Payload | | Payload |
+-----------------+ +-----------------+
skipping to change at page 12, line 44 skipping to change at page 13, line 5
When the NSH encapsulated packet is further encapsulated for When the NSH encapsulated packet is further encapsulated for
transmission to the next SFF or SF, ECN marking behavior depends on transmission to the next SFF or SF, ECN marking behavior depends on
whether or not the node that will decapsulate the outer header whether or not the node that will decapsulate the outer header
supports Compliant ECN Decapsulation (see Section 3). If it does, supports Compliant ECN Decapsulation (see Section 3). If it does,
then the ingress node propagates the NSH ECN field to this outer then the ingress node propagates the NSH ECN field to this outer
encapsulation using the "Normal Mode" of ECN encapsulation [RFC6040] encapsulation using the "Normal Mode" of ECN encapsulation [RFC6040]
(it copies the ECN field). If it does not, then the ingress MUST (it copies the ECN field). If it does not, then the ingress MUST
clear ECN in the outer encapsulation to non-ECT (the "Compatibility clear ECN in the outer encapsulation to non-ECT (the "Compatibility
Mode" of [RFC6040]). Mode" of [RFC6040]).
INTERNET-DRAFT NSH ECN & Congestion Feedback
3.2.2 At an SF/Proxy 3.2.2 At an SF/Proxy
If the SF is NSH and ECN-aware, the processing is essentially the If the SF is NSH and ECN-aware, the processing is essentially the
same at the SF as at an SFF as discussed in Section 3.2.1. same at the SF as at an SFF as discussed in Section 3.2.1.
If the SF is NSH-aware but not ECN-aware, then the SFF transmitting If the SF is NSH-aware but not ECN-aware, then the SFF transmitting
the packet to the SF will use Compatibility Mode. Congestion the packet to the SF will use Compatibility Mode. Congestion
encountered in the SFF to SF and SF to SFF paths will be unmanaged. encountered in the SFF to SF and SF to SFF paths will be unmanaged.
INTERNET-DRAFT NSH ECN & Congestion Feedback
If the SF is not NSH-aware, then an NSH proxy will be between the SFF If the SF is not NSH-aware, then an NSH proxy will be between the SFF
and the SF to avoid exposure of the NSH at the SF that does not and the SF to avoid exposure of the NSH at the SF that does not
understand NSHs. This is described in Section 4.6 of [RFC7665]. The understand NSHs. This is described in Section 4.6 of [RFC7665]. The
SF and proxy together look to the SFF like an NSH-aware SF. The SF and proxy together look to the SFF like an NSH-aware SF. The
behavior at the proxy and SF in this case is as below: behavior at the proxy and SF in this case is as below:
If such a proxy is not ECN-aware then congestion in the entire If such a proxy is not ECN-aware then congestion in the entire
path from SFF to proxy to SF back to proxy to SFF will be path from SFF to proxy to SF back to proxy to SFF will be
unmanaged. unmanaged.
skipping to change at page 17, line 20 skipping to change at page 17, line 20
For security considerations concerning tampering with ECN signaling, For security considerations concerning tampering with ECN signaling,
see [RFC3168]. For security considerations concerning ECN see [RFC3168]. For security considerations concerning ECN
encapsulation, see [RFC6040]. encapsulation, see [RFC6040].
For general IPFIX security considerations, see [RFC7011]. If deployed For general IPFIX security considerations, see [RFC7011]. If deployed
in an untrusted environment, the signaling traffic between ingress in an untrusted environment, the signaling traffic between ingress
and egress can be protected utilizing the security mechanisms and egress can be protected utilizing the security mechanisms
provided by IPFIX (see section 11 in RFC7011). provided by IPFIX (see section 11 in RFC7011).
The solution does not introduce any greater potential to invade The solution in this document does not introduce any greater
privacy than would have been possible without the solution. potential to invade privacy than would have been possible without the
solution.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank the following for their comments and The authors wish to thank the following for their comments and
suggestion: suggestion:
Joel Halpern, Xinpeng Wei Joel Halpern, Tal Mizrahi, Xinpeng Wei
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Normative References 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, DOI 10.17487/RFC2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
March 1997, <http://www.rfc-editor.org/info/rfc2119>. March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
skipping to change at page 21, line 9 skipping to change at page 21, line 9
Andrew G. Malis Andrew G. Malis
Huawei Technologies Huawei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
INTERNET-DRAFT NSH ECN & Congestion Feedback INTERNET-DRAFT NSH ECN & Congestion Feedback
Copyright and IPR Provisions Copyright and IPR Provisions
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 26 change blocks. 
54 lines changed or deleted 68 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/