draft-ietf-rddp-applicability-05.txt   draft-ietf-rddp-applicability-06.txt 
Remote Direct Data Placement C. Bestler Remote Direct Data Placement C. Bestler
Working group Broadcom Working group Broadcom Corporation
Internet-Draft L. Coene Internet-Draft L. Coene
Expires: June 8, 2006 Siemens Expires: October 26, 2006 Siemens
December 5, 2005 April 24, 2006
Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct
Data Placement (DDP) Data Placement (DDP)
draft-ietf-rddp-applicability-05.txt draft-ietf-rddp-applicability-06.txt
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 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 8, 2006. This Internet-Draft will expire on October 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the applicability of Remote Direct Memory This document describes the applicability of Remote Direct Memory
Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).
It comparese and contrasts the different transport options over IP It compares and contrasts the different transport options over IP
that DDP can use, provides guidance to ULP developers on choosing that DDP can use, provides guidance to ULP developers on choosing
between available transports and/or how to be indifferent to the between available transports and/or how to be indifferent to the
specific transport layer used, compares use of DDP with direct use of specific transport layer used, compares use of DDP with direct use of
the supporting transports, and compares DDP over IP transports with the supporting transports, and compares DDP over IP transports with
non-IP transports that support RDMA functionality. non-IP transports that support RDMA functionality.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 33 skipping to change at page 2, line 33
6.2. Out of Order Reception Implications . . . . . . . . . . . 15 6.2. Out of Order Reception Implications . . . . . . . . . . . 15
6.3. Header and Marker Overhead . . . . . . . . . . . . . . . . 15 6.3. Header and Marker Overhead . . . . . . . . . . . . . . . . 15
6.4. Middlebox Support . . . . . . . . . . . . . . . . . . . . 15 6.4. Middlebox Support . . . . . . . . . . . . . . . . . . . . 15
6.5. Processing Overhead . . . . . . . . . . . . . . . . . . . 16 6.5. Processing Overhead . . . . . . . . . . . . . . . . . . . 16
6.6. Data Integrity Implications . . . . . . . . . . . . . . . 16 6.6. Data Integrity Implications . . . . . . . . . . . . . . . 16
6.6.1. MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 16 6.6.1. MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 16
6.6.2. SCTP Specifics . . . . . . . . . . . . . . . . . . . . 17 6.6.2. SCTP Specifics . . . . . . . . . . . . . . . . . . . . 17
6.7. Non-IP Transports . . . . . . . . . . . . . . . . . . . . 17 6.7. Non-IP Transports . . . . . . . . . . . . . . . . . . . . 17
6.7.1. No RDMA Layer Ack . . . . . . . . . . . . . . . . . . 17 6.7.1. No RDMA Layer Ack . . . . . . . . . . . . . . . . . . 17
6.8. Other IP Transports . . . . . . . . . . . . . . . . . . . 18 6.8. Other IP Transports . . . . . . . . . . . . . . . . . . . 18
6.9. LLP Independent Session Establishment . . . . . . . . . . 18 6.9. LLP Independent Session Establishment . . . . . . . . . . 19
6.9.1. RDMA-only Session Establishment . . . . . . . . . . . 19 6.9.1. RDMA-only Session Establishment . . . . . . . . . . . 19
6.9.2. RDMA-Conditional Session Establishment . . . . . . . . 19 6.9.2. RDMA-Conditional Session Establishment . . . . . . . . 19
7. Local Interface Implications . . . . . . . . . . . . . . . . . 21 7. Local Interface Implications . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security considerations . . . . . . . . . . . . . . . . . . . 23 9. Security considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Connection/Association Setup . . . . . . . . . . . . . . . 23 9.1. Connection/Association Setup . . . . . . . . . . . . . . . 23
9.2. Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 23 9.2. Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 23
9.3. Impact of Encrypted Transports . . . . . . . . . . . . . . 23 9.3. Impact of Encrypted Transports . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative references . . . . . . . . . . . . . . . . . . . 24 10.1. Normative references . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Remote Direct Memory Access Protocol (RDMAP) and Direct Data Remote Direct Memory Access Protocol [6] and Direct Data Placement
Placement (DDP) work together to provide application independent [7] work together to provide application independent efficient
efficient placement of application payload directly into buffers placement of application payload directly into buffers specified by
specified by the Upper Layer Protocol (ULP). the Upper Layer Protocol (ULP).
The DDP protocol is responsible for direct placement of received The DDP protocol is responsible for direct placement of received
payload into ULP specified buffers. The RDMAP protocol provides payload into ULP specified buffers. The RDMAP protocol provides
completion notifications to the ULP and support for Data Sink completion notifications to the ULP and support for Data Sink
initiated fetch of advertised buffers (RDMA Reads). initiated fetch of advertised buffers (RDMA Reads).
DDP and RDMAP are both application independent protocols which allow DDP and RDMAP are both application independent protocols which allow
the ULP to perform remote direct data placement. DDP can use the ULP to perform remote direct data placement. DDP can use
multiple standard IP transports including SCTP and TCP. multiple standard IP transports including SCTP and TCP.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
cleanly as a layer over existing IP transports, DDP has simpler cleanly as a layer over existing IP transports, DDP has simpler
ordering rules than some prior RDMA protocols. This may have some ordering rules than some prior RDMA protocols. This may have some
implications for application designers. implications for application designers.
The full capabilities of DDP and RDMAP can only be fully realized by The full capabilities of DDP and RDMAP can only be fully realized by
applications that are designed to exploit them. The co-existence of applications that are designed to exploit them. The co-existence of
RDMAP/DDP aware local interfaces with traditional socket interfaces RDMAP/DDP aware local interfaces with traditional socket interfaces
will also be explored. will also be explored.
Finally, DDP support is defined for at least two IP transports: SCTP Finally, DDP support is defined for at least two IP transports: SCTP
and TCP. The rationale for supporting both transports is reviewed, [8] and MPA over TCP [10]. The rationale for supporting both
as well as when each would be the appropriate selection. transports is reviewed, as well as when each would be the appropriate
selection.
2. Definitions 2. Definitions
Advertisement - the act of informing a Remote Peer that a local RDMA Advertisement - the act of informing a Remote Peer that a local RDMA
Buffer is available to it. A Node makes available an RDMA Buffer Buffer is available to it. A Node makes available an RDMA Buffer
for incoming RDMA Read or RDMA Write access by informing its RDMA/ for incoming RDMA Read or RDMA Write access by informing its RDMA/
DDP peer of the Tagged Buffer identifiers (STag, base address, and DDP peer of the Tagged Buffer identifiers (STag, base address, and
buffer length). This advertisement of Tagged Buffer information buffer length). This advertisement of Tagged Buffer information
is not defined by RDMA/DDP and is left to the ULP. A typical is not defined by RDMA/DDP and is left to the ULP. A typical
method would be for the Local Peer to embed the Tagged Buffer's method would be for the Local Peer to embed the Tagged Buffer's
skipping to change at page 5, line 45 skipping to change at page 5, line 45
message sender. The message receiver is given no independent message sender. The message receiver is given no independent
indication that a tagged message has been received. indication that a tagged message has been received.
Untagged Message A DDP message that is directed to a ULP specified Untagged Message A DDP message that is directed to a ULP specified
buffer based upon a Message Sequence Number being matched with a buffer based upon a Message Sequence Number being matched with a
receiver supplied buffer. The destination buffer is specified by receiver supplied buffer. The destination buffer is specified by
the message receiver. The message receiver is notified by some the message receiver. The message receiver is notified by some
mechanism that an untagged message has been received. mechanism that an untagged message has been received.
Upper Layer Protocol (ULP) The direct user of RDMAP/DDP services. In Upper Layer Protocol (ULP) The direct user of RDMAP/DDP services. In
addition to protocols such as iSER [10] and NFSv4 over RDMA [11], addition to protocols such as iSER [11] and NFSv4 over RDMA [12],
the ULP may be embedded in an application, or a middleware layer the ULP may be embedded in an application, or a middleware layer
as is often the case for the Sockets Direct Protocol (SDP) and as is often the case for the Sockets Direct Protocol (SDP) and
Remote Procedure Call (RPC) protocols. Remote Procedure Call (RPC) protocols.
3. Direct Placement 3. Direct Placement
Direct Data Placement optimizes the placement of ULP payload into the Direct Data Placement optimizes the placement of ULP payload into the
correct destination buffers, typically eliminating intermediate correct destination buffers, typically eliminating intermediate
copying. Placement is enabled without regard to order of arrival, copying. Placement is enabled without regard to order of arrival,
order of transmission or requiring per-placement interaction with the order of transmission or requiring per-placement interaction with the
skipping to change at page 8, line 33 skipping to change at page 8, line 33
Some examples of data that typically belongs in the untagged message Some examples of data that typically belongs in the untagged message
would include short fixed size control data that is inherently part would include short fixed size control data that is inherently part
of the control message almost always should be included in the of the control message almost always should be included in the
untagged message, relatively short payload that is almost always untagged message, relatively short payload that is almost always
needed (especially when it would eliminate a round-trip to fetch the needed (especially when it would eliminate a round-trip to fetch the
data. For example, the initial data on a write request, and of data. For example, the initial data on a write request, and of
course advertising tagged buffers that specify the location of data course advertising tagged buffers that specify the location of data
not in the untagged message. not in the untagged message.
Tagged messages standardizes direct placemtn of data without per- Tagged messages standardizes direct placement of data without per-
packet interaction with the upper layers. Even if there is an upper packet interaction with the upper layers. Even if there is an upper
layer protocol encoding of what is being transferred, as is common layer protocol encoding of what is being transferred, as is common
with middleware solutions, this information is not understood at the with middleware solutions, this information is not understood at the
application independent layers. The directions on where to place the application independent layers. The directions on where to place the
incoming data cannot be accessed without switching to the ULP first. incoming data cannot be accessed without switching to the ULP first.
DDP provides a standardized\ 'packing list' which can be interpreted DDP provides a standardized 'packing list' which can be interpreted
without requiring ULP interaction. Indeed, it is designed to be without requiring ULP interaction. Indeed, it is designed to be
implementable in hardware. implementable in hardware.
4.1. Order Independent Reception 4.1. Order Independent Reception
Tagged messages are directed to a buffer based on an included Tagged messages are directed to a buffer based on an included
Steering Tag. Additionally, no notice is provided to the ULP for each Steering Tag. Additionally, no notice is provided to the ULP for each
individual Tagged Message's arrival. Together these allow tagged individual Tagged Message's arrival. Together these allow tagged
messages received out-of-order to be processed without intermediate messages received out-of-order to be processed without intermediate
buffering or additional notifications to the ULP. buffering or additional notifications to the ULP.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
A DDP stream delivered via MPA/TCP will require more processing A DDP stream delivered via MPA/TCP will require more processing
effort that one delivered over SCTP. However this extra work may be effort that one delivered over SCTP. However this extra work may be
justified for many deployments where full SCTP support is unavailable justified for many deployments where full SCTP support is unavailable
in the endpoints of the network, or where middleboxes impair the in the endpoints of the network, or where middleboxes impair the
usability of SCTP. usability of SCTP.
6.6. Data Integrity Implications 6.6. Data Integrity Implications
Both the SCTP and MPA/TCP adaptation provide end-to-end CRC32c Both the SCTP and MPA/TCP adaptation provide end-to-end CRC32c
protection against data corruption, or its equivalent. protection against data accidental corruption, or its equivalent.
A ULP that requires a greater degree of protection may add it own. A ULP that requires a greater degree of protection may add it own.
However, DDP and RDMAP headers will only be guaranteed to have the However, DDP and RDMAP headers will only be guaranteed to have the
equivalent of end-to-end CRC32c protection. A ULP that requires data equivalent of end-to-end CRC32c protection. A ULP that requires data
integrity checking more thorough than an end-to-end CRC32c should integrity checking more thorough than an end-to-end CRC32c should
first invalidate all STags that reference a buffer before applying first invalidate all STags that reference a buffer before applying
their own integrity check. their own integrity check.
CRC32c only provides protection against random corruption. To
protect against unauthorized alteration or forging of data packets,
security methods must be applied. IPsec is supported for both SCTP
and MPA/TCP.
6.6.1. MPA/TCP Specifics 6.6.1. MPA/TCP Specifics
It is mandatory for MPA/TCP implementations to implement CRC32c, but It is mandatory for MPA/TCP implementations to implement CRC32c, but
it is NOT mandatory to use the CRC32c during an RDMA connection. The it is NOT mandatory to use the CRC32c during an RDMA connection. The
activating or deactivating of the CRC in MPA/TCP is an administrative activating or deactivating of the CRC in MPA/TCP is an administrative
configuration operation at the local and remote end. The configuration operation at the local and remote end. The
administration of the CRC(ON/OFF) is invisible to the ULP. administration of the CRC(ON/OFF) is invisible to the ULP.
Applications SHOULD trust that this administrative option will only Applications SHOULD trust that this administrative option will only
be used when the end-to-end protection is at least as effective as a be used when the end-to-end protection is at least as effective as a
skipping to change at page 20, line 12 skipping to change at page 20, line 19
With TCP. a normal TCP connection is established. It is then used by With TCP. a normal TCP connection is established. It is then used by
the ULP to determine whether or not to convert to MPA mode and use the ULP to determine whether or not to convert to MPA mode and use
RDMA. This will typically be integral with other session RDMA. This will typically be integral with other session
establishment negotiations. establishment negotiations.
With SCTP, the establishment of an association tests whether RDMA is With SCTP, the establishment of an association tests whether RDMA is
supported. If not supported, the application simply requests the supported. If not supported, the application simply requests the
association without the RDMA adaptation indication. association without the RDMA adaptation indication.
In key difference is that with SCTP the determination as to whether One key difference is that with SCTP the determination as to whether
the peer can support RDMA is made before the transport layer the peer can support RDMA is made before the transport layer
association/connection is established while with TCP the established association/connection is established while with TCP the established
connection itself is used to determine whether RDMA is supported. connection itself is used to determine whether RDMA is supported.
7. Local Interface Implications 7. Local Interface Implications
Full utilization of DDP and RDMAP capabilities requires a local Full utilization of DDP and RDMAP capabilities requires a local
interface that explicitly requests these services. Protocols such as interface that explicitly requests these services. Protocols such as
Sockets Direct Protocol (SDP) can allow applications to keep their Sockets Direct Protocol (SDP) can allow applications to keep their
traditional byte-stream or message-stream interface and still enjoy traditional byte-stream or message-stream interface and still enjoy
skipping to change at page 23, line 15 skipping to change at page 23, line 15
9. Security considerations 9. Security considerations
9.1. Connection/Association Setup 9.1. Connection/Association Setup
Both the SCTP and TCP adaptations allow for existing procedures to be Both the SCTP and TCP adaptations allow for existing procedures to be
followed for the establishment of the SCTP association or TCP followed for the establishment of the SCTP association or TCP
connection. Use of DDP does not impair the use of any security connection. Use of DDP does not impair the use of any security
measures to filter, validate and/or log the remote end of an measures to filter, validate and/or log the remote end of an
association/connection. association/connection.
Authentication of peers and approval of connections is outside of the
scope of DDP. Connection authentication is the responsibility of the
ULP, which may be based upon information from the LLP. IPSEC is
usable for both TCP and SCTP.
9.2. Tagged Buffer Exposure 9.2. Tagged Buffer Exposure
DDP only exposes ULP memory to the extent explicitly allowed by ULP DDP only exposes ULP memory to the extent explicitly allowed by ULP
actions. These include posting of receive operations and enabling of actions. These include posting of receive operations and enabling of
Steering Tags. Steering Tags.
DDP validates that STags are only used by the remote peer to the
extent authorized by the ULP. The STag selects from a pool of
buffers previously authorized by the ULP; an STag by itself does not
authorize access.
Use of randomization in generating STag values may be useful in
preventing 'off by one' and other programmatic errors, but is of
limited value in countering generation and misuse of STag values by
an active attacker. IPsec provides countermeasures that can prevent
such an unauthorized attacker from gaining access to buffers used by
DDP and RDMAP.
Neither RDMAP or DDP place requirements on how ULP's advertise Neither RDMAP or DDP place requirements on how ULP's advertise
buffers. A ULP may use a single Steering Tag for multiple buffer buffers. A ULP may use a single Steering Tag for multiple buffer
advertisements. However, the ULP should be aware that enforcement on advertisements. However, the ULP should be aware that enforcement on
STag usage is likely limited to the overall range that is enabled. STag usage is likely limited to the overall range that is enabled.
If the remote peer writes into the 'wrong' advertised buffer, neither If the remote peer writes into the 'wrong' advertised buffer, neither
the DDP or RDMAP layer will be aware of this. Nor is there any the DDP or RDMAP layer will be aware of this. Nor is there any
report to the ULP on how the remote peer specifically used tagged report to the ULP on how the remote peer specifically used tagged
buffers. buffers.
Unless the ULP peers have an adequate basis for mutual trust, the Unless the ULP peers have an adequate basis for mutual trust, the
skipping to change at page 24, line 19 skipping to change at page 25, line 19
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
"Stream Control Transmission Protocol", RFC 2960, October 2000. Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[5] Coene, L., "Stream Control Transmission Protocol Applicability [5] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", RFC 3257, April 2002. Statement", RFC 3257, April 2002.
[6] Recio, R., "An RDMA Protocol Specification", [6] Recio, R., "An RDMA Protocol Specification",
draft-ietf-rddp-rdmap-05 (work in progress), July 2005. draft-ietf-rddp-rdmap-05 (work in progress), July 2005.
[7] Shah, H., "Direct Data Placement over Reliable Transports", [7] Shah, H., "Direct Data Placement over Reliable Transports",
draft-ietf-rddp-ddp-05 (work in progress), July 2005. draft-ietf-rddp-ddp-05 (work in progress), July 2005.
[8] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote [8] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Direct Memory Access (RDMA) Direct Data Placement (DDP) Remote Direct Memory Access (RDMA) Direct Data Placement (DDP)
Adaptationn", draft-ietf-rddp-sctp-02 (work in progress), Adaptation", draft-ietf-rddp-sctp-02 (work in progress),
August 2005. August 2005.
[9] Culley, P., "Marker PDU Aligned Framing for TCP Specification", [9] Pinkerton, J., "DDP/RDMAP Security",
draft-ietf-rddp-security-08 (work in progress), March 2006.
[10] Culley, P., "Marker PDU Aligned Framing for TCP Specification",
draft-ietf-rddp-mpa-02 (work in progress), February 2005. draft-ietf-rddp-mpa-02 (work in progress), February 2005.
10.2. Informative References 10.2. Informative References
[10] Ko, M., "iSCSI Extensions for RDMA Specification", [11] Ko, M., "iSCSI Extensions for RDMA Specification",
October 2005. October 2005.
[11] Callaghan, B. and T. Talpey, "NFS Direct Data Placemetn", [12] Callaghan, B. and T. Talpey, "NFS Direct Data Placement",
draft-ietf-nfsv4-nfsdirect-02 (work in progress), October 2005. draft-ietf-nfsv4-nfsdirect-02 (work in progress), October 2005.
Authors' Addresses Authors' Addresses
Caitlin Bestler Caitlin Bestler
Broadcom Broadcom Corporation
49 Discovery 16215 Alton Parkway
Irvine, CA 92618 P.O. Box 57013
Irvine, CA 92619-7013
USA USA
Phone: 949-926-6383 Phone: 949-926-6383
Email: caitlinb@broadcom.com Email: caitlinb@broadcom.com
Lode Coene Lode Coene
Siemens Siemens
Atealaan 26 Atealaan 26
Herentals, 2200 Herentals, 2200
Belgium Belgium
skipping to change at page 26, line 41 skipping to change at page 27, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 25 change blocks. 
37 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/