draft-ietf-issll-dclass-01.txt   rfc2996.txt 
Internet Draft Y. Bernet, Microsoft
draft-ietf-issll-dclass-01.txt October, 1999
Format of the RSVP DCLASS Object
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Network Working Group Y. Bernet
Force (IETF), its areas, and its working groups. Note that other groups Request for Comments: 2996 Microsoft
may also distribute working documents as Internet-Drafts. Category: Standards Track November 2000
Internet-Drafts are draft documents valid for a maximum of six months Format of the RSVP DCLASS Object
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Abstract Abstract
RSVP signaling may be used to request QoS services and enhance the Resource Reservation Protocol (RSVP) signaling may be used to request
manageability of application traffic's QoS in a differentiated service Quality of Service (QoS) services and enhance the manageability of
(diff-serv or DS) network. When using RSVP with DS networks it is application traffic's QoS in a differentiated service (diff-serv or
useful to be able to carry carry Differentiated Services Code Points DS) network. When using RSVP with DS networks it is useful to be
(DSCPs) in RSVP message objects. One example of this is the use of RSVP able to carry carry Differentiated Services Code Points (DSCPs) in
to arrange for the marking of packets with a particular DSCP upstream RSVP message objects. One example of this is the use of RSVP to
arrange for the marking of packets with a particular DSCP upstream
from the DS network's ingress point, at the sender or at a previous from the DS network's ingress point, at the sender or at a previous
network's egress router. network's egress router.
The DCLASS object is used to represent and carry DSCPs within RSVP The DCLASS object is used to represent and carry DSCPs within RSVP
messages. This draft specifies the format of the DCLASS object and messages. This document specifies the format of the DCLASS object
briefly discusses its use. and briefly discusses its use.
2. Introduction
This section describes the mechanics of using RSVP [RSVP] signaling and 1. Introduction
the DCLASS object for effecting admission control and applying QoS
policy within a Differentiated Service network [DS]. It assumes
standard RSVP senders and receivers, and a diff-serv network somewhere
in the path between sender and receiver. At least one RSVP aware
network element resides in the diff-serv network. This network element
may be a policy enforcement point (PEP) [RAP] or may simply act as an
Bernet Expires May, 2000 1 This section describes the mechanics of using RSVP [RSVP] signaling
admission control agent for the network, admitting or denying resource and the DCLASS object for effecting admission control and applying
requests based on the availability of resources. In either case, this QoS policy within a Differentiated Service network [DS]. It assumes
network element interacts with RSVP messages arriving from outside the standard RSVP senders and receivers, and a diff-serv network
DS network, accepting resource requests from RSVP-aware senders and somewhere in the path between sender and receiver. At least one RSVP
receivers, and conveying the DS network's admission control and resource aware network element resides in the diff-serv network. This network
allocation decisions to the higher-level RSVP. The network element is element may be a policy enforcement point (PEP) [RAP] or may simply
typically a router and will be considered to be so for the purpose of act as an admission control agent for the network, admitting or
this draft. This model is described fully in [INTDIFF]. denying resource requests based on the availability of resources. In
either case, this network element interacts with RSVP messages
arriving from outside the DS network, accepting resource requests
from RSVP-aware senders and receivers, and conveying the DS network's
admission control and resource allocation decisions to the higher-
level RSVP. The network element is typically a router and will be
considered to be so for the purpose of this document. This model is
described fully in [INTDIFF].
2.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information 1.1 Use of the DCLASS Object to Carry Upstream Packet Marking
Information
A principal usage of the DCLASS object is to carry DSCP information A principal usage of the DCLASS object is to carry DSCP information
between a DS network and upstream nodes that may wish to mark packets between a DS network and upstream nodes that may wish to mark packets
with DSCP values. Briefly, the sender composes a standard RSVP PATH with DSCP values. Briefly, the sender composes a standard RSVP PATH
message and sends it towards the receiver. At some point the PATH message and sends it towards the receiver. At some point the PATH
message reaches the DS network. The PATH message traverses one or more message reaches the DS network. The PATH message traverses one or
network elements that are PEPs and/or admission control agents for the more network elements that are PEPs and/or admission control agents
diff-serv network. These elements install appropriate state and forward for the diff-serv network. These elements install appropriate state
the PATH message towards the receiver. If admission control is and forward the PATH message towards the receiver. If admission
successful downstream of the diff-serv network, then a RESV message will control is successful downstream of the diff-serv network, then a
arrive from the direction of the receiver. As this message arrives at RESV message will arrive from the direction of the receiver. As this
the PEPs and/or admission control agents that are RSVP enabled, each of message arrives at the PEPs and/or admission control agents that are
these network elements must make a decision regarding the admissibility RSVP enabled, each of these network elements must make a decision
of the signaled flow to the diff-serv network. regarding the admissibility of the signaled flow to the diff-serv
network.
If the network element determines that the request represented by the If the network element determines that the request represented by the
PATH and RESV messages is admissible to the diff-serv network, the PATH and RESV messages is admissible to the diff-serv network, the
appropriate diff-serv service level (or behaviour aggregate) for the appropriate diff-serv service level (or behavior aggregate) for the
traffic represented in the RSVP request is determined. Next, a decision traffic represented in the RSVP request is determined. Next, a
is made to mark arriving data packets for this traffic locally using MF decision is made to mark arriving data packets for this traffic
classification, or to request upstream marking of the packets with the locally using MF classification, or to request upstream marking of
appropriate DSCP(s). This upstream marking could occur anywhere before the packets with the appropriate DSCP(s). This upstream marking
the DS network's ingress point. Two likely candidates are the could occur anywhere before the DS network's ingress point. Two
originating sender and the egress boundary router of some upstream (DS likely candidates are the originating sender and the egress boundary
or non-DS) network. The decision about where the RSVP request's packets router of some upstream (DS or non-DS) network. The decision about
should be marked can be made by agreement or through a negotiation where the RSVP request's packets should be marked can be made by
protocol; the details are outside the scope of this document. agreement or through a negotiation protocol; the details are outside
the scope of this document.
If the packets for this RSVP request are to be marked upstream, If the packets for this RSVP request are to be marked upstream,
information about the DSCP(s) to use must be conveyed from the RSVP- information about the DSCP(s) to use must be conveyed from the RSVP-
aware network element to the upstream marking point. This information aware network element to the upstream marking point. This
is conveyed with the DCLASS object. To do this, the network element information is conveyed with the DCLASS object. To do this, the
adds a DCLASS object containing one or more DSCPs corresponding to the network element adds a DCLASS object containing one or more DSCPs
behaviour aggregate, to the RESV message. The RESV message is then sent corresponding to the behavior aggregate, to the RESV message. The
upstream towards the RSVP sender. RESV message is then sent upstream towards the RSVP sender.
If the network element determines that the RSVP request is not If the network element determines that the RSVP request is not
admissible to the diff-serv network, it sends a RESV error message admissible to the diff-serv network, it sends a RESV error message
towards the receiver. No DCLASS is required. towards the receiver. No DCLASS is required.
Bernet Expires May, 2000 2 1.1 Additional Uses of the DCLASS Object
2.1 Additional Uses of the DCLASS Object
The DCLASS object is intended to be a general tool for conveying DSCP The DCLASS object is intended to be a general tool for conveying DSCP
information in RSVP messages. This may be useful in a number of information in RSVP messages. This may be useful in a number of
situations. We give one further example here as motivation. situations. We give one further example here as motivation.
In this example, we assume that the decision about the appropriate In this example, we assume that the decision about the appropriate
behavior aggregate for a RSVP-mediated traffic flow is made at the DS behavior aggregate for a RSVP-mediated traffic flow is made at the DS
network egress router (or a related Policy Decision Point) by observing network egress router (or a related Policy Decision Point) by
RSVP PATH and RESV messages and other necessary information. However, observing RSVP PATH and RESV messages and other necessary
the actual packet marking must be done at the ingress of the network. information. However, the actual packet marking must be done at the
The DCLASS object can be used to carry the needed marking information ingress of the network. The DCLASS object can be used to carry the
between egress and ingress routers. needed marking information between egress and ingress routers.
3. Format of the DCLASS Object 2. Format of the DCLASS Object
The DCLASS object has the following format: The DCLASS object has the following format:
0 | 1 | 2 | 3 0 | 1 | 2 | 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>= 8) | C-Num (225) | 1 | | Length (>= 8) | C-Num (225) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 1st DSCP | | | Unused | 1st DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 2nd DSCP | | | Unused | 2nd DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | . . . . | | | Unused | . . . . | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first word contains the standard RSVP object header (the Class Num The first word contains the standard RSVP object header (the Class
for the DCLASS object is 225). The length field indicates the total Num for the DCLASS object is 225). The length field indicates the
object length in bytes. The object header is followed by one or more total object length in bytes. The object header is followed by one
32-bit words, each containing a DSCP in the six high-order bits of the or more 32-bit words, each containing a DSCP in the six high-order
least significant byte. The length field in the object header indicates bits of the least significant byte. The length field in the object
the number of DSCPs included in the object. Specifically, the number of header indicates the number of DSCPs included in the object.
DCLASS objects present is equal to (Length - 4) / 4. Specifically, the number of DCLASS objects present is equal to
(Length - 4) / 4.
The network may return multiple DSCPs in the DCLASS object in order to The network may return multiple DSCPs in the DCLASS object in order
enable the host to discriminate sub-flows within a behaviour aggregate. to enable the host to discriminate sub-flows within a behavior
For example, in the case of the AF PHB group [AF], the network may aggregate. For example, in the case of the AF PHB group [AF], the
return the DSCPs 001010, 001100, and 001110 corresponding to increasing network may return the DSCPs 001010, 001100, and 001110 corresponding
levels of drop precedence within Class 1 of the AF PHB group. Note that to increasing levels of drop precedence within Class 1 of the AF PHB
this draft makes no statements regarding the significance of the order group. Note that this document makes no statements regarding the
of the returned DSCPs. Further interpretation of DSCP sets is dependent significance of the order of the returned DSCPs. Further
on the specific service requested by the host and is beyond the scope of interpretation of DSCP sets is dependent on the specific service
this draft. requested by the host and is beyond the scope of this document.
Note that the Class-Num for the DCLASS object is chosen from the space Note that the Class-Num for the DCLASS object is chosen from the
of unknown class objects that should be ignored and forwarded by nodes space of unknown class objects that should be ignored and forwarded
that do not recognize it. This is to assure maximal backward by nodes that do not recognize it. This is to assure maximal
compatibility. backward compatibility.
Bernet Expires May, 2000 3 3. Admission Control Functionality
4. Admission Control Functionality
From a black-box perspective, admission control and policy functionality From a black-box perspective, admission control and policy
amounts to the decision whether to accept or reject a request and the functionality amounts to the decision whether to accept or reject a
determination of the DSCPs that should be used for the corresponding request and the determination of the DSCPs that should be used for
traffic. The specific details of admission control are beyond the scope the corresponding traffic. The specific details of admission control
of this document. In general the admission control decision is based are beyond the scope of this document. In general the admission
both on resource availability and on policies regarding the use of control decision is based both on resource availability and on
resources in the diff-serv network. The admission control decision made policies regarding the use of resources in the diff-serv network.
by RSVP aware network elements represents both considerations. The admission control decision made by RSVP aware network elements
represents both considerations.
In order to decide whether the RSVP request is admissible in terms of In order to decide whether the RSVP request is admissible in terms of
resource availability, one or more network elements within or at the resource availability, one or more network elements within or at the
boundary of the diff-serv network must understand the impact that boundary of the diff-serv network must understand the impact that
admission would have on specific diff-serv resources, as well as the admission would have on specific diff-serv resources, as well as the
availability of these resources along the relevant data path in the availability of these resources along the relevant data path in the
diff-serv network. diff-serv network.
In order to decide whether the RSVP request is admissible in terms of In order to decide whether the RSVP request is admissible in terms of
policy, the network element may use identity objects describing users policy, the network element may use identity objects describing users
and/or applications that may be included in the request. The router may and/or applications that may be included in the request. The router
act as a PEP/PDP and use data from a policy database or directory to aid may act as a PEP/PDP and use data from a policy database or directory
in this decision. to aid in this decision.
See Appendix A for a simple mechanism for configurable resource based See Appendix A for a simple mechanism for configurable resource based
admission control. admission control.
5. Security Considerations 4. Security Considerations
The DCLASS object conveys information that can be used to request The DCLASS object conveys information that can be used to request
enhanced QoS from a DS network, so inappropriate modification of the enhanced QoS from a DS network, so inappropriate modification of the
object could allow traffic flows to obtain a higher or lower level of object could allow traffic flows to obtain a higher or lower level of
QoS than appropriate. Particularly, modification of a DCLASS object by QoS than appropriate. Particularly, modification of a DCLASS object
a third party inserted between the DS network ingress node and the by a third party inserted between the DS network ingress node and the
upstream marker constitutes a possible denial of service attack. This upstream marker constitutes a possible denial of service attack.
attack is subtle because it is possible to reduce the received QoS to an This attack is subtle because it is possible to reduce the received
unacceptably low level without completely cutting off data flow, making QoS to an unacceptably low level without completely cutting off data
the attack harder to detect. flow, making the attack harder to detect.
The possibility of raising the received level of QoS by inappropriate The possibility of raising the received level of QoS by inappropriate
modification of the DCLASS object is less significant because it a modification of the DCLASS object is less significant because it a
subclass of a larger class of attacks that must already be detected by subclass of a larger class of attacks that must already be detected
the system. Protection must already be in place to prevent a host by the system. Protection must already be in place to prevent a host
raising its received level of QoS by simply guessing "good" DSCP's and raising its received level of QoS by simply guessing "good" DSCP's
marking packets accordingly. If this protection is at the boundary of and marking packets accordingly. If this protection is at the
the DS network, it will detect inappropriate marking of arriving packets boundary of the DS network, it will detect inappropriate marking of
caused by modified DCLASS objects as well. If, however, the protection arriving packets caused by modified DCLASS objects as well. If,
function as well as the marking function has been pushed upstream however, the protection function as well as the marking function has
(perhaps to a trusted third party or intermediate node), correct been pushed upstream (perhaps to a trusted third party or
transmission of the DCLASS object must be ensured to prevent a possible intermediate node), correct transmission of the DCLASS object must be
theft of service attack. ensured to prevent a possible theft of service attack.
Bernet Expires May, 2000 4 Simple observation of the DCLASS object in a RSVP message raises
Simple observation of the DCLASS object in a RSVP message raises several several issues which may be seen as security concerns. Correlation
issues which may be seen as security concerns. Correlation of observed of observed DCLASS object values with RSVP requests or MF
DCLASS object values with RSVP requests or MF classification parameters classification parameters allows the observer to determine that
allows the observer to determine that different flows are receiving different flows are receiving different levels of QoS, which may be
different levels of QoS, which may be knowledge that should be protected knowledge that should be protected in some environments. Similarly,
in some environments. Similarly, observation of the DCLASS object can observation of the DCLASS object can allow the observer to determine
allow the observer to determine that a single flow's QoS has been that a single flow's QoS has been promoted or demoted, which may
promoted or demoted, which may signal significant events in the life of signal significant events in the life of that flow's application or
that flow's application or user. Finally, observation of the DCLASS user. Finally, observation of the DCLASS object may reveal
object may reveal information about the internal operations of a DS information about the internal operations of a DS network that could
network that could be useful to observers interested in be useful to observers interested in theft-of-services attacks.
theft-of-services attacks.
6. References 5. References
[INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [INTDIFF] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A
Operation over Diffserv Networks", Internet Draft, June 1999 Framework for Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[DS] An Architecture for Differentiated Services. S. Blake, D. Black, [DS] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss,
M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 1998. "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Functional Specification.", IETF RFC 2205, Sep. 1997. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
Control", IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999. for Policy Based Admission Control", RFC 2753, January
2000.
[AF], Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured [AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
Forwarding PHB Group", RFC 2597, June 1999 "Assured Forwarding PHB Group", RFC 2597, June 1999.
7. Acknowledgments 6. Acknowledgments
Thanks to Fred Baker and Carol Iturralde for reviewing this draft. Thanks to Fred Baker and Carol Iturralde for reviewing this document.
Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for input. Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for
input.
8. Author's Address 7. Author's Address
Bernet, Yoram Yoram Bernet
Microsoft Microsoft
One Microsoft Way, One Microsoft Way,
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 936-9568 Phone: (425) 936-9568
Email: yoramb@microsoft.com EMail: yoramb@microsoft.com
Appendix A - Simple Configurable Resource Based Admission Control Appendix A - Simple Configurable Resource Based Admission Control
Routers may use quite sophisticated mechanisms in making the admission Routers may use quite sophisticated mechanisms in making the
control decision, including policy considerations, various intra- domain admission control decision, including policy considerations, various
signaling protocols, results of traffic monitoring and so on. It is intra-domain signaling protocols, results of traffic monitoring and
recommended that the following basic functionality be provided to enable so on. It is recommended that the following basic functionality be
provided to enable simple resource based admission control in the
Bernet Expires May, 2000 5 absence of more sophisticated mechanisms. This functionality can be
simple resource based admission control in the absence of more used with configurable, standalone routers. It applies to standard
sophisticated mechanisms. This functionality can be used with RSVP/Intserv requests. This minimal functionality assumes only a
configurable, standalone routers. It applies to standard RSVP/Intserv single DSCP is included in the DCLASS object, but may readily be
requests. This minimal functionality assumes only a single DSCP is extended to support multiple DSCPs.
included in the DCLASS object, but may readily be extended to support
multiple DSCPs.
It must be possible to configure two tables in the router. These are It must be possible to configure two tables in the router. These are
described below. described below.
A.1 Service Type to DSCP Mapping A.1 Service Type to DSCP Mapping
One table provides a mapping from the intserv service-type specified in One table provides a mapping from the intserv service-type specified
the RSVP request to a DSCP that can be used to obtain a corresponding in the RSVP request to a DSCP that can be used to obtain a
service in the diff-serv network. This table contains a row for each corresponding service in the diff-serv network. This table contains
intserv service type for which a mapping is available. Each row has the a row for each intserv service type for which a mapping is available.
following format: Each row has the following format:
Intserv service type : DSCP Intserv service type : DSCP
The table would typically contain at least three rows; one for The table would typically contain at least three rows; one for
Guaranteed service, one for Controlled Load service and one for Best- Guaranteed service, one for Controlled Load service and one for Best-
Effort service. (The best-effort service will typically map to DSCP Effort service. (The best-effort service will typically map to DSCP
000000, but may be overridden). It should be possible to add rows for 000000, but may be overridden). It should be possible to add rows
as-yet-undefined service types. for as-yet-undefined service types.
This table allows the network administrator to statically configure a This table allows the network administrator to statically configure a
DSCP that the router will return in the DCLASS object for an admitted DSCP that the router will return in the DCLASS object for an admitted
RSVP request. In general, more sophisticated and likely more dynamic RSVP request. In general, more sophisticated and likely more dynamic
mechanisms may be used to determine the DSCP to be returned in the mechanisms may be used to determine the DSCP to be returned in the
DCLASS object. Also, it is likely that a real mapping for some services DCLASS object. Also, it is likely that a real mapping for some
would use more than one DSCP, with the DSCP depending on the invocation services would use more than one DSCP, with the DSCP depending on the
parameters of a specific service request. In this case, these invocation parameters of a specific service request. In this case,
mechanisms may override or replace the static table based mapping these mechanisms may override or replace the static table based
described here. mapping described here.
A.2 Quantitative Resource Availability A.2 Quantitative Resource Availability
Standard intserv requests are quantitative in nature. They include Standard intserv requests are quantitative in nature. They include
token bucket parameters describing the resources required by the traffic token bucket parameters describing the resources required by the
for which admission is requested. The second table enables the network traffic for which admission is requested. The second table enables
administrator to statically configure quantitative parameters to be used the network administrator to statically configure quantitative
by the router when making an admission control decision for quantitative parameters to be used by the router when making an admission control
service requests. Each row in this table has the following form: decision for quantitative service requests. Each row in this table
has the following form:
DSCP : Token bucket profile DSCP : Token bucket profile
The first column specifies those DSCPs for which quantitative admission The first column specifies those DSCPs for which quantitative
control is applied. The second column specifies the token bucket admission control is applied. The second column specifies the token
parameters which represent the total resources available in the bucket parameters which represent the total resources available in
diff-serv network to accommodate traffic in the service class specified the diff-serv network to accommodate traffic in the service class
by the DSCP. specified by the DSCP.
Bernet Expires May, 2000 6 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 48 change blocks. 
206 lines changed or deleted 203 lines changed or added

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