draft-ietf-rddp-applicability-01.txt   draft-ietf-rddp-applicability-02.txt 
Remote Direct Data Placement C. Bestler Remote Direct Data Placement C. Bestler
Working group L. Coene Working group L. Coene
Expires: April 12, 2004 Expires: March 11, 2005
Applicability of Remote Direct Memory Access Protocol (RDMA) and Applicability of Remote Direct Memory Access Protocol (RDMA) and
Direct Data Placement (DDP) Direct Data Placement (DDP)
draft-ietf-rddp-applicability-01.txt draft-ietf-rddp-applicability-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
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
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
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 April 12, 2004. This Internet-Draft will expire on March 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 Access Protocol (RDMAP) and the Direct Data Placement Protocol
(DDP). It contrasts the different transport options over IP that DDP (DDP). It contrasts the different transport options over IP that DDP
can use, compares use of DDP with direct use of the supporting can use, compares use of DDP with direct use of the supporting
transports, and compares DDP over IP transports with non-IP transports, and compares DDP over IP transports with non-IP
transports that support RDMA functionality. transports that support RDMA functionality.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Direct Placement . . . . . . . . . . . . . . . . . . . . . . 6 3. Direct Placement . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Fewer Required ULP Interactions . . . . . . . . . . . . . . 6 3.1 Fewer Required ULP Interactions . . . . . . . . . . . . . 6
3.2 Direct Placement using only the LLP . . . . . . . . . . . . 6 3.2 Direct Placement using only the LLP . . . . . . . . . . . 6
4. Tagged Messages . . . . . . . . . . . . . . . . . . . . . . 8 4. Tagged Messages . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Order Independent Reception . . . . . . . . . . . . . . . . 8 4.1 Order Independent Reception . . . . . . . . . . . . . . . 8
4.2 Reduced ULP Notifications . . . . . . . . . . . . . . . . . 8 4.2 Reduced ULP Notifications . . . . . . . . . . . . . . . . 8
4.3 Simplified ULP Exchanges . . . . . . . . . . . . . . . . . . 9 4.3 Simplified ULP Exchanges . . . . . . . . . . . . . . . . . 9
4.4 Order Independent Sending . . . . . . . . . . . . . . . . . 10 4.4 Order Independent Sending . . . . . . . . . . . . . . . . 10
4.5 Tagged Buffers as ULP Credits . . . . . . . . . . . . . . . 11 4.5 Tagged Buffers as ULP Credits . . . . . . . . . . . . . . 11
5. RDMA Read . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. RDMA Read . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. LLP Comparisons . . . . . . . . . . . . . . . . . . . . . . 14 6. LLP Comparisons . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Multistreaming Implications . . . . . . . . . . . . . . . . 14 6.1 Multistreaming Implications . . . . . . . . . . . . . . . 14
6.2 Out of Order Reception Implications . . . . . . . . . . . . 14 6.2 Out of Order Reception Implications . . . . . . . . . . . 14
6.3 Header and Marker Overhead . . . . . . . . . . . . . . . . . 14 6.3 Header and Marker Overhead . . . . . . . . . . . . . . . . 14
6.4 Middlebox Support . . . . . . . . . . . . . . . . . . . . . 14 6.4 Middlebox Support . . . . . . . . . . . . . . . . . . . . 14
6.5 Processing Overhead . . . . . . . . . . . . . . . . . . . . 15 6.5 Processing Overhead . . . . . . . . . . . . . . . . . . . 15
6.6 Data Integrity Implications . . . . . . . . . . . . . . . . 15 6.6 Data Integrity Implications . . . . . . . . . . . . . . . 15
6.6.1 MPA/TCP Specifics . . . . . . . . . . . . . . . . . . . . . 15 6.6.1 MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 15
6.6.2 SCTP Specifics . . . . . . . . . . . . . . . . . . . . . . . 16 6.6.2 SCTP Specifics . . . . . . . . . . . . . . . . . . . . 16
6.7 Non-IP Transports . . . . . . . . . . . . . . . . . . . . . 16 6.7 Non-IP Transports . . . . . . . . . . . . . . . . . . . . 16
6.7.1 No RDMA Layer Ack . . . . . . . . . . . . . . . . . . . . . 16 6.7.1 No RDMA Layer Ack . . . . . . . . . . . . . . . . . . 16
6.8 Other IP Transports . . . . . . . . . . . . . . . . . . . . 17 6.8 Other IP Transports . . . . . . . . . . . . . . . . . . . 17
6.9 LLP Independent Session Establishment . . . . . . . . . . . 17 6.9 LLP Independent Session Establishment . . . . . . . . . . 17
6.9.1 RDMA-only Session Establishment . . . . . . . . . . . . . . 18 6.9.1 RDMA-only Session Establishment . . . . . . . . . . . 17
6.9.2 RDMA-Conditional Session Establishment . . . . . . . . . . . 18 6.9.2 RDMA-Conditional Session Establishment . . . . . . . . 18
7. Local Interface Implications . . . . . . . . . . . . . . . . 20 7. Local Interface Implications . . . . . . . . . . . . . . . . . 20
8. Security considerations . . . . . . . . . . . . . . . . . . 21 8. Security considerations . . . . . . . . . . . . . . . . . . . 21
8.1 Connection/Association Setup . . . . . . . . . . . . . . . . 21 8.1 Connection/Association Setup . . . . . . . . . . . . . . . 21
8.2 Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . . 21 8.2 Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 21
8.3 Impact of Encrypted Transports . . . . . . . . . . . . . . . 21 8.3 Impact of Encrypted Transports . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
Remote Direct Memory Access Protocol (RDMAP) and Direct Data Remote Direct Memory Access Protocol (RDMAP) and Direct Data
Placement (DDP) work together to provide application independent Placement (DDP) work together to provide application independent
efficient placemenet of application payload directly into buffers efficient placemenet of application payload directly into buffers
specified by the Upper Layer Protocol (ULP). specified by 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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
accurately predict the required buffers and their sizes. This is not accurately predict the required buffers and their sizes. This is not
feasible for all ULPs. By contrast, DDP only requires the ULP to feasible for all ULPs. By contrast, DDP only requires the ULP to
predict the sequence and size of incoming untagged messages. predict the sequence and size of incoming untagged messages.
An application that could predict incoming messages and required An application that could predict incoming messages and required
nothing more than direct placement into buffers might be able to do nothing more than direct placement into buffers might be able to do
so with a properly designed local interface to SCTP or TCP. Doing so so with a properly designed local interface to SCTP or TCP. Doing so
for TCP requires making predictions at a byte level rather than a for TCP requires making predictions at a byte level rather than a
message level. message level.
The main benefit of DDP for such an application would be that pre- The main benefit of DDP for such an application would be that
posting of receive buffers is a mandated local interface capability, pre-posting of receive buffers is a mandated local interface
and that predictions can be made on a per-message basis (not per capability, and that predictions can be made on a per-message basis
byte). (not per byte).
The LLP can also be used directly if ULP specific knowledge is built The LLP can also be used directly if ULP specific knowledge is built
into the protocol stack to allow "parse and place" handling of into the protocol stack to allow "parse and place" handling of
received packets. Such a solution either requires interaction with received packets. Such a solution either requires interaction with
the ULP, or that the protocol stack have knowledge of ULP specific the ULP, or that the protocol stack have knowledge of ULP specific
syntax rules. syntax rules.
DDP achieves the benefits of directly placing incoming payload DDP achieves the benefits of directly placing incoming payload
without requiring tight coupling between the ULP and the protocol without requiring tight coupling between the ULP and the protocol
stack. However, "parse and place" capabilities can certainly provide stack. However, "parse and place" capabilities can certainly provide
skipping to change at page 10, line 27 skipping to change at page 10, line 24
Use of tagged messages is especially applicable when the Data Sink Use of tagged messages is especially applicable when the Data Sink
does not know the actual size, structure or location of the content does not know the actual size, structure or location of the content
it is requesting (or updating). it is requesting (or updating).
For example, suppose the Data Sink ULP needs to fetch four related For example, suppose the Data Sink ULP needs to fetch four related
pieces of data into a four separate buffers. With SCTP the Data Sink pieces of data into a four separate buffers. With SCTP the Data Sink
ULP could receive four messages into four separate buffers, only ULP could receive four messages into four separate buffers, only
having to predict the maximum size of each. However it would have to having to predict the maximum size of each. However it would have to
dictate the order in which the Data Source supplied the separate dictate the order in which the Data Source supplied the separate
pieces. If the Data Source found it advantageous to fetch them in a pieces. If the Data Source found it advantageous to fetch them in a
different order it would have to use intermediate buffering to re- different order it would have to use intermediate buffering to
order the pieces into the expected order even though the application re-order the pieces into the expected order even though the
only required that all four be delivered and did not truly have an application only required that all four be delivered and did not
ordering requirement. truly have an ordering requirement.
Techniques such as RAID striping and mirroring represent this same Techniques such as RAID striping and mirroring represent this same
problem, but one step further. What appears to be a single resource problem, but one step further. What appears to be a single resource
to the Data Sink is actually stored in separate locations by the Data to the Data Sink is actually stored in separate locations by the Data
Source. Non RDMA protocols would either require the Data Source to Source. Non RDMA protocols would either require the Data Source to
fetch the material in the desired order or force the Data Source to fetch the material in the desired order or force the Data Source to
use its own holding buffers to assemble an image of the destination use its own holding buffers to assemble an image of the destination
buffer. buffer.
While sometimes referred to as a "buffer-to-buffer" solution, RDMA While sometimes referred to as a "buffer-to-buffer" solution, RDMA
skipping to change at page 14, line 25 skipping to change at page 14, line 25
equivalent services are only available with TCP through the use of equivalent services are only available with TCP through the use of
the MPA adaptation layer. the MPA adaptation layer.
6.1 Multistreaming Implications 6.1 Multistreaming Implications
SCTP also provides multi-streaming. When the same pair of hosts have SCTP also provides multi-streaming. When the same pair of hosts have
need for multiple DDP streams this can be a major advantage. A need for multiple DDP streams this can be a major advantage. A
single SCTP association carries multiple DDP streams, consolidating single SCTP association carries multiple DDP streams, consolidating
connection setup, congestion control and acknowledgements. connection setup, congestion control and acknowledgements.
Completions are controlled by the DDP Source Sequence Number (DDP- Completions are controlled by the DDP Source Sequence Number
SSN) on a per stream basis. Therefore combining multiple DDP Streams (DDP-SSN) on a per stream basis. Therefore combining multiple DDP
into a single SCTP association cannot result in a dropped packet Streams into a single SCTP association cannot result in a dropped
carrying data for one stream delaying completions on others. packet carrying data for one stream delaying completions on others.
6.2 Out of Order Reception Implications 6.2 Out of Order Reception Implications
The use of unordered Data Chunks with SCTP guarantees that the DDP The use of unordered Data Chunks with SCTP guarantees that the DDP
layer will be able to perform placements when IP datagrams are layer will be able to perform placements when IP datagrams are
received out of order. received out of order.
Placement of out-of-order DDP Segments carried over MPA/TCP is not Placement of out-of-order DDP Segments carried over MPA/TCP is not
guaranteed, but certainly allowed. The ability of the MPA receiver guaranteed, but certainly allowed. The ability of the MPA receiver
to process out-of-order DDP Segments may be impaired when TCP to process out-of-order DDP Segments may be impaired when TCP
skipping to change at page 15, line 45 skipping to change at page 15, line 45
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
transport layer CRC32c. Applications SHOULD NOT apply additional transport layer CRC32c. Applications SHOULD NOT apply additional
protection as a guard against this administrative option being turned protection as a guard against this administrative option being turned
on inadvertently. on inadvertently.
Administrators MUST NOT enable CRC32c suppression unless the end-to- Administrators MUST NOT enable CRC32c suppression unless the
end protection is truly equivalent. end-to-end protection is truly equivalent.
If the CRC is active/used for one direction/end , then the use of the If the CRC is active/used for one direction/end , then the use of the
CRC is mandatory in both directions/ends. CRC is mandatory in both directions/ends.
If both ends have been configured NOT to use the CRC, then this is If both ends have been configured NOT to use the CRC, then this is
allowed as long as an equivalent protection(comparable or better allowed as long as an equivalent protection(comparable or better
than/to CRC) from undetected errors on the connection is provided. than/to CRC) from undetected errors on the connection is provided.
6.6.2 SCTP Specifics 6.6.2 SCTP Specifics
skipping to change at page 18, line 31 skipping to change at page 18, line 26
To be transport neutral, the applications should exchange Private To be transport neutral, the applications should exchange Private
Data as part of session establishment messages to determine how the Data as part of session establishment messages to determine how the
RDMA endpoints are to be configured. One side must be the Initiator, RDMA endpoints are to be configured. One side must be the Initiator,
and the other the Responder. and the other the Responder.
With SCTP, a pair of SCTP streams can be used for sequential With SCTP, a pair of SCTP streams can be used for sequential
sessions. With MPA/TCP each connection can be used for at most one sessions. With MPA/TCP each connection can be used for at most one
session. However, the same source/destination pair of ports can be session. However, the same source/destination pair of ports can be
re-used sequentially subject to normal TCP rules. re-used sequentially subject to normal TCP rules.
SCTP limits the Stream Session Initiate control message to a single
SCTP Data Chunk, or 516 bytes whichever is greater. MPA only limits
the private data in a MPA Request or Response frame to 65,535 bytes.
An IP transport neutral application SHOULD limit itself to 512 bytes
or less of Private Data in the connection establishment phase. An
application that wanted to be InfiniBand compatible as well would
need to limit the size even further.
MPA/TCP requires the end of the TCP connection that initiated the
conversion to MPA mode to send the first DDP Segment. SCTP does not
have this requirement. ULPs which wish to be transport neutral
should require the initiating end to send the first message. A
zero-length RDMA Write can be used for this purpose if the ULP logic
itself does naturally support this restriction.
6.9.2 RDMA-Conditional Session Establishment 6.9.2 RDMA-Conditional Session Establishment
It is sometimes desirable for the active side of a session to connect It is sometimes desirable for the active side of a session to connect
with the passive side before knowing whether the passive side with the passive side before knowing whether the passive side
supports RDMA. supports RDMA.
This style of session establishment can be supported with either TCP This style of session establishment can be supported with either TCP
or SCTP, but not as transparently as for RDMA-only sessions. Pre- or SCTP, but not as transparently as for RDMA-only sessions.
existing non-RDMA servers are also far more likely to be using TCP Pre-existing non-RDMA servers are also far more likely to be using
than SCTP. TCP than SCTP.
With TCP. a normal TCP connection is established. It is then used 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 by 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.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
placement purposes. IPsec tunnel mode encrypts entire IP Datagrams. placement purposes. IPsec tunnel mode encrypts entire IP Datagrams.
IPsec transport mode encrypts TCP Segments or SCTP packets. In IPsec transport mode encrypts TCP Segments or SCTP packets. In
neither case should IPsec preclude providing out-of-order DDP neither case should IPsec preclude providing out-of-order DDP
Segments to the DDP layer for placement. Segments to the DDP layer for placement.
Note that end-to-end use of IPsec cryptographic integrity protection Note that end-to-end use of IPsec cryptographic integrity protection
may allow suppression of MPA CRC generation and checking under may allow suppression of MPA CRC generation and checking under
certain circumstances. This is one example where the LLP may be certain circumstances. This is one example where the LLP may be
judged to have "or equivalent" protection to an end-to-end CRC32c. judged to have "or equivalent" protection to an end-to-end CRC32c.
References 9 References
[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., Allen, C., Treese, W., Karlton, P., Freier, A. and [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2246, January 1999.
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. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "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", draft-ietf-rddp- [6] Recio, R., "An RDMA Protocol Specification",
rdmap-00 (work in progress), February 2003. draft-ietf-rddp-rdmap-02 (work in progress), September 2004.
[7] Shah, H., "Direct Data Placement over Reliable Transports", [7] Shah, H., "Direct Data Placement over Reliable Transports",
draft-ietf-rddp-ddp-00 (work in progress), February 2003. draft-ietf-rddp-ddp-03 (work in progress), August 2004.
[8] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote [8] Stewart, R., "Stream Control Transmission Protocol (SCTP) Remote
Direct Memory Access (RDMA) Direct Data Placement (DDP) Direct Memory Access (RDMA) Direct Data Placement (DDP)
Adaptationn", draft-ietf-rddp-sctp-00 (work in progress), Adaptationn", draft-ietf-rddp-sctp-02 (work in progress), August
September 2003. 2004.
[9] Culley, P., "Marker PDU Aligned Framing for TCP Specification", [9] Culley, P., "Marker PDU Aligned Framing for TCP Specification",
draft-ietf-rddp-mpa-00 (work in progress), October 2003. draft-ietf-rddp-mpa-01 (work in progress), July 2004.
Authors' Addresses Authors' Addresses
Caitlin Bestler Caitlin Bestler
1241 W. North Shore 1241 W. North Shore
# 2G # 2G
Chicago, IL 60626 Chicago, IL 60626
USA USA
Phone: +1-773-743-1594 Phone: +1-773-743-1594
EMail: cait@asomi.com EMail: cait@asomi.com
Lode Coene Lode Coene
Atealaan 26 Atealaan 26
Herentals, 2200 Herentals, 2200
Belgium Belgium
Phone: +32-14-252081 Phone: +32-14-252081
EMail: lode.coene@siemens.com EMail: lode.coene@siemens.com
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository at
included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
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 The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
This document and the information contained herein is provided on an Disclaimer of Validity
"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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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. 

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