draft-ietf-nfsv4-rpcrdma-08.txt   draft-ietf-nfsv4-rpcrdma-09.txt 
NFSv4 Working Group Tom Talpey NFSv4 Working Group Tom Talpey
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track Brent Callaghan Intended status: Standards Track Brent Callaghan
Expires: October 17, 2008 Apple Expires: June 3, 2009 Apple
April 16, 2008 December 3, 2008
Remote Direct Memory Access Transport for Remote Procedure Call Remote Direct Memory Access Transport for Remote Procedure Call
draft-ietf-nfsv4-rpcrdma-08 draft-ietf-nfsv4-rpcrdma-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
Copyright Notice This Internet-Draft will expire on June 3, 2009.
Copyright (C) The IETF Trust (2008).
Abstract Abstract
A protocol is described providing Remote Direct Memory Access A protocol is described providing Remote Direct Memory Access
(RDMA) as a new transport for Remote Procedure Call (RPC). The (RDMA) as a new transport for Remote Procedure Call (RPC). The
RDMA transport binding conveys the benefits of efficient, bulk data RDMA transport binding conveys the benefits of efficient, bulk data
transport over high speed networks, while providing for minimal transport over high speed networks, while providing for minimal
change to RPC applications and with no required revision of the change to RPC applications and with no required revision of the
application RPC protocol, or the RPC protocol itself. application RPC protocol, or the RPC protocol itself.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
5.2. RDMA Write of Long Replies (Reply Chunks) . . . . . . . 24 5.2. RDMA Write of Long Replies (Reply Chunks) . . . . . . . 24
6. Connection Configuration Protocol . . . . . . . . . . . . 25 6. Connection Configuration Protocol . . . . . . . . . . . . 25
6.1. Initial Connection State . . . . . . . . . . . . . . . . 26 6.1. Initial Connection State . . . . . . . . . . . . . . . . 26
6.2. Protocol Description . . . . . . . . . . . . . . . . . . 26 6.2. Protocol Description . . . . . . . . . . . . . . . . . . 26
7. Memory Registration Overhead . . . . . . . . . . . . . . . 28 7. Memory Registration Overhead . . . . . . . . . . . . . . . 28
8. Errors and Error Recovery . . . . . . . . . . . . . . . . 28 8. Errors and Error Recovery . . . . . . . . . . . . . . . . 28
9. Node Addressing . . . . . . . . . . . . . . . . . . . . . 28 9. Node Addressing . . . . . . . . . . . . . . . . . . . . . 28
10. RPC Binding . . . . . . . . . . . . . . . . . . . . . . . 29 10. RPC Binding . . . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 33
14. Normative References . . . . . . . . . . . . . . . . . . 32 14. Normative References . . . . . . . . . . . . . . . . . . 33
15. Informative References . . . . . . . . . . . . . . . . . 33 15. Informative References . . . . . . . . . . . . . . . . . 34
16. Authors' Addresses . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
17. Intellectual Property and Copyright Statements . . . . . 35 Intellectual Property Statement . . . . . . . . . . . . . . . 35
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 36 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 36
Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
Requirements Language Requirements Language
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
Remote Direct Memory Access (RDMA) [RFC5040, RFC5041] [IB] is a Remote Direct Memory Access (RDMA) [RFC5040, RFC5041] [IB] is a
skipping to change at page 19, line 23 skipping to change at page 19, line 23
ignore the XID in the RPC header, if it so chooses. ignore the XID in the RPC header, if it so chooses.
2. Version number. 2. Version number.
This version of the RPC RDMA message protocol is 1. The This version of the RPC RDMA message protocol is 1. The
version number MUST be increased by one whenever the format of version number MUST be increased by one whenever the format of
the RPC RDMA messages is changed. the RPC RDMA messages is changed.
3. Flow control credit value. 3. Flow control credit value.
When sent in an RPC call message, the requested value is When sent in an RPC call message, the requested value is
provided. When sent in an RPC reply message, the granted provided. When sent in an RPC reply message, the granted
value is returned. RPC calls SHOULD not be sent in excess of value is returned. RPC calls SHOULD NOT be sent in excess of
the currently granted limit. the currently granted limit.
4. Message type. 4. Message type.
o RDMA_MSG = 0 indicates that chunk lists and RPC message o RDMA_MSG = 0 indicates that chunk lists and RPC message
follow. follow.
o RDMA_NOMSG = 1 indicates that after the chunk lists there o RDMA_NOMSG = 1 indicates that after the chunk lists there
is no RPC message. In this case, the chunk lists provide is no RPC message. In this case, the chunk lists provide
information to allow the message proper to be transferred information to allow the message proper to be transferred
skipping to change at page 28, line 50 skipping to change at page 28, line 50
/* max active RDMA Reads at server */ /* max active RDMA Reads at server */
}; };
program CONFIG_RDMA_PROG { program CONFIG_RDMA_PROG {
version VERS1 { version VERS1 {
/* /*
* Config call/reply * Config call/reply
*/ */
config_rdma_reply CONF_RDMA(config_rdma_req) = 1; config_rdma_reply CONF_RDMA(config_rdma_req) = 1;
} = 1; } = 1;
} = 100400; } = 100417;
7. Memory Registration Overhead 7. Memory Registration Overhead
RDMA requires that all data be transferred between registered RDMA requires that all data be transferred between registered
memory regions at the source and destination. All protocol headers memory regions at the source and destination. All protocol headers
as well as separately transferred data chunks use registered as well as separately transferred data chunks use registered
memory. Since the cost of registering and de-registering memory memory. Since the cost of registering and de-registering memory
can be a large proportion of the RDMA transaction cost, it is can be a large proportion of the RDMA transaction cost, it is
important to minimize registration activity. This is easily important to minimize registration activity. This is easily
achieved within RPC controlled memory by allocating chunk list data achieved within RPC controlled memory by allocating chunk list data
skipping to change at page 30, line 18 skipping to change at page 30, line 18
service, which associates an RPC program number with a service service, which associates an RPC program number with a service
address. (In the case of UDP or TCP, the service address for NFS address. (In the case of UDP or TCP, the service address for NFS
is normally port 2049.) This policy is no different with RDMA is normally port 2049.) This policy is no different with RDMA
interconnects, although it may require the allocation of port interconnects, although it may require the allocation of port
numbers appropriate to each upper layer binding which uses the RPC numbers appropriate to each upper layer binding which uses the RPC
framing defined here. framing defined here.
When mapped atop the iWARP [RFC5040, RFC5041] transport, which uses When mapped atop the iWARP [RFC5040, RFC5041] transport, which uses
IP port addressing due to its layering on TCP and/or SCTP, port IP port addressing due to its layering on TCP and/or SCTP, port
mapping is trivial and consists merely of issuing the port in the mapping is trivial and consists merely of issuing the port in the
connection process. connection process. The NFS/RDMA protocol service address has been
assigned port 20049 by IANA, for both iWARP/TCP and iWARP/SCTP.
When mapped atop Infiniband [IB], which uses a GID-based service When mapped atop Infiniband [IB], which uses a GID-based service
endpoint naming scheme, a translation MUST be employed. One such endpoint naming scheme, a translation MUST be employed. One such
translation is defined in the Infiniband Port Addressing Annex translation is defined in the Infiniband Port Addressing Annex
[IBPORT], which is appropriate for translating IP port addressing [IBPORT], which is appropriate for translating IP port addressing
to the Infiniband network. Therefore, in this case, IP port to the Infiniband network. Therefore, in this case, IP port
addressing may be readily employed by the upper layer. addressing may be readily employed by the upper layer.
When a mapping standard or convention exists for IP ports on an When a mapping standard or convention exists for IP ports on an
RDMA interconnect, there are several possibilities for each upper RDMA interconnect, there are several possibilities for each upper
skipping to change at page 30, line 49 skipping to change at page 30, line 50
A second possibility is to have the server's portmapper A second possibility is to have the server's portmapper
register itself on the RDMA interconnect at a "well known" register itself on the RDMA interconnect at a "well known"
service address. (On UDP or TCP, this corresponds to port service address. (On UDP or TCP, this corresponds to port
111.) A client could connect to this service address and use 111.) A client could connect to this service address and use
the portmap protocol to obtain a service address in response the portmap protocol to obtain a service address in response
to a program number, e.g., an iWARP port number, or an to a program number, e.g., an iWARP port number, or an
Infiniband GID. Infiniband GID.
Alternatively, the client could simply connect to the mapped Alternatively, the client could simply connect to the mapped
well-known port for the service itself, if it is appropriately well-known port for the service itself, if it is appropriately
defined. defined. By convention, the NFS/RDMA service, when operating
atop such an Infiniband fabric, will use the same 20049
assignment as for iWARP.
Historically, different RPC protocols have taken different Historically, different RPC protocols have taken different
approaches to their port assignment, therefore the specific method approaches to their port assignment, therefore the specific method
is left to each RPC/RDMA-enabled upper layer binding, and not is left to each RPC/RDMA-enabled upper layer binding, and not
addressed here. addressed here.
This specification defines a new "netid", to be used for This specification defines two new "netid" values, to be used for
registration of upper layers atop iWARP [RFC5040, RFC5041] and registration of upper layers atop iWARP [RFC5040, RFC5041] and
(when a suitable port translation service is available) Infiniband (when a suitable port translation service is available) Infiniband
[IB] in section 12, "IANA Considerations." Additional RDMA-capable [IB] in section 12, "IANA Considerations." Additional RDMA-capable
networks MAY define their own netids, or if they provide a port networks MAY define their own netids, or if they provide a port
translation, MAY share the one defined here. translation, MAY share the one defined here.
11. Security Considerations 11. Security Considerations
RPC provides its own security via the RPCSEC_GSS framework RPC provides its own security via the RPCSEC_GSS framework
[RFC2203]. RPCSEC_GSS can provide message authentication, [RFC2203]. RPCSEC_GSS can provide message authentication,
skipping to change at page 32, line 44 skipping to change at page 32, line 45
message in order to provide the next credit. The time-based window message in order to provide the next credit. The time-based window
(or any other appropriate method) SHOULD be used by the server to (or any other appropriate method) SHOULD be used by the server to
recover resources in the event that the client never returns. recover resources in the event that the client never returns.
The "Connection Configuration Protocol", when used, MUST be The "Connection Configuration Protocol", when used, MUST be
protected by an appropriate RPC security flavor, to ensure it is protected by an appropriate RPC security flavor, to ensure it is
not attacked in the process of initiating an RPC/RDMA connection. not attacked in the process of initiating an RPC/RDMA connection.
12. IANA Considerations 12. IANA Considerations
The new RPC transport is to be assigned a new RPC "netid", which is Three new assignments are specified by this document:
an rpcbind [RFC1833] string used to describe the underlying
protocol in order for RPC to select the appropriate transport
framing, as well as the format of the service ports.
The following "nc_proto" registry string is hereby defined for this - A new set of RPC "netids" for resolving RPC/RDMA services
- Optional service port assignments for upper layer bindings
- An RPC program number assignment for the configuration protocol
These assignments have been established, as below.
The new RPC transport has been assigned an RPC "netid", which is an
rpcbind [RFC1833] string used to describe the underlying protocol
in order for RPC to select the appropriate transport framing, as
well as the format of the service addresses and ports.
The following "nc_proto" registry strings are defined for this
purpose: purpose:
NC_RDMA "rdma" NC_RDMA "rdma"
This netid MAY be used for any RDMA network satisfying the NC_RDMA6 "rdma6"
These netids MAY be used for any RDMA network satisfying the
requirements of section 2, and able to identify service endpoints requirements of section 2, and able to identify service endpoints
using IP port addressing, possibly through use of a translation using IP port addressing, possibly through use of a translation
service as described above in section 10, RPC Binding. service as described above in section 10, RPC Binding. The "rdma"
netid is to be used when IPv4 addressing is employed by the
underlying transport, and "rdma6" for IPv6 addressing.
The netid assignment policy and registry are defined in [IANA-
NETID].
As a new RPC transport, this protocol has no effect on RPC program As a new RPC transport, this protocol has no effect on RPC program
numbers or existing registered port numbers. However, new port numbers or existing registered port numbers. However, new port
numbers MAY be registered for use by RPC/RDMA-enabled services, as numbers MAY be registered for use by RPC/RDMA-enabled services, as
appropriate to the new networks over which the services will appropriate to the new networks over which the services will
operate. operate.
For example, the NFS/RDMA service defined in [NFSDDP] has been
assigned the port 20049, in the IANA registry:
nfsrdma 20049/tcp Network File System (NFS) over RDMA
nfsrdma 20049/udp Network File System (NFS) over RDMA
nfsrdma 20049/sctp Network File System (NFS) over RDMA
The OPTIONAL Connection Configuration protocol described herein The OPTIONAL Connection Configuration protocol described herein
requires an RPC program number assignment. The value "100400" is requires an RPC program number assignment. The value "100417" has
hereby assigned: been assigned:
rdmaconfig 100400 rpc.rdmaconfig rdmaconfig 100417 rpc.rdmaconfig
Currently, neither the nc_proto netid's nor the RPC program numbers The RPC program number assignment policy and registry are defined
are are assigned by IANA. The list in [RFC1833] has served as the in [RFC1831bis].
netid registry, and the republication declared in [IANA-RPC] has
served as the program number registry. Ideally, IANA will create
explicit registries for these objects. However, in the absence of
new registries, this document would serve as the repository for the
RPC program number assignment, and the protocol netid.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Rob Thurlow, John Howard, Chet Juszczak, The authors wish to thank Rob Thurlow, John Howard, Chet Juszczak,
Alex Chiu, Peter Staubach, Dave Noveck, Brian Pawlowski, Steve Alex Chiu, Peter Staubach, Dave Noveck, Brian Pawlowski, Steve
Kleiman, Mike Eisler, Mark Wittle, Shantanu Mehendale, David Kleiman, Mike Eisler, Mark Wittle, Shantanu Mehendale, David
Robinson and Mallikarjun Chadalapaka for their contributions to Robinson and Mallikarjun Chadalapaka for their contributions to
this document. this document.
14. Normative References 14. Normative References
[RFC2119] [RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", Best Current Practice, BCP 14, RFC 2119, March 1997. Levels", Best Current Practice, BCP 14, RFC 2119, March 1997.
[RFC1094]
Sun Microsystems, "NFS: Network File System Protocol
Specification", (NFS version 2) Informational RFC,
http://www.ietf.org/rfc/rfc1094.txt
[RFC1831bis] [RFC1831bis]
R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol R. Thurlow, Ed., "RPC: Remote Procedure Call Protocol
Specification Version 2", Standards Track RFC Specification Version 2", Internet Draft Work in Progress,
draft-ietf-nfsv4-rfc1831bis
[RFC4506] [RFC4506]
M. Eisler Ed., "XDR: External Data Representation Standard", M. Eisler Ed., "XDR: External Data Representation Standard",
Standards Track RFC, http://www.ietf.org/rfc/rfc4506.txt Standards Track RFC, http://www.ietf.org/rfc/rfc4506.txt
[RFC1813]
B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3
Protocol Specification", Informational RFC,
http://www.ietf.org/rfc/rfc1813.txt
[RFC1833] [RFC1833]
R. Srinivasan, "Binding Protocols for ONC RPC Version 2", R. Srinivasan, "Binding Protocols for ONC RPC Version 2",
Standards Track RFC, http://www.ietf.org/rfc/rfc1833.txt Standards Track RFC, http://www.ietf.org/rfc/rfc1833.txt
[RFC3530]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame,
M. Eisler, D. Noveck, "NFS version 4 Protocol", Standards
Track RFC, http://www.ietf.org/rfc/rfc3530.txt
[RFC2203] [RFC2203]
M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol
Specification", Standards Track RFC, Specification", Standards Track RFC,
http://www.ietf.org/rfc/rfc2203.txt http://www.ietf.org/rfc/rfc2203.txt
[RPCSECGSSV2] [RPCSECGSSV2]
M. Eisler, "RPCSEC_GSS Version 2", Internet Draft Work in M. Eisler, "RPCSEC_GSS Version 2", Internet Draft Work in
Progress draft-ietf-nfsv4-rpcsec-gss-v2 Progress, draft-ietf-nfsv4-rpcsec-gss-v2
[RFC5056] [RFC5056]
N. Williams, "On the Use of Channel Bindings to Secure N. Williams, "On the Use of Channel Bindings to Secure
Channels", Standards Track RFC Channels", Standards Track RFC
http://www.ietf.org/rfc/rfc5056.txt
[BTNSLATCH] [BTNSLATCH]
N. Williams, "IPsec Channels: Connection Latching", Internet N. Williams, "IPsec Channels: Connection Latching", Internet
Draft Work in Progress draft-ietf-btns-connection-latching Draft Work in Progress, draft-ietf-btns-connection-latching
[RFC5042] [RFC5042]
J. Pinkerton, E. Deleganes, "Direct Data Placement Protocol J. Pinkerton, E. Deleganes, "Direct Data Placement Protocol
(DDP) / Remote Direct Memory Access Protocol (RDMAP) Security" (DDP) / Remote Direct Memory Access Protocol (RDMAP)
Standards Track RFC Security", Standards Track RFC,
http://www.ietf.org/rfc/rfc5042.txt
[IANA-NETID]
M. Eisler, "IANA Considerations for RPC Net Identifiers and
Universal Address Formats", Internet Draft Work in Progress,
draft-ietf-nfsv4-rpc-netid
15. Informative References 15. Informative References
[RFC1094]
Sun Microsystems, "NFS: Network File System Protocol
Specification", (NFS version 2) Informational RFC,
http://www.ietf.org/rfc/rfc1094.txt
[RFC1813]
B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3
Protocol Specification", Informational RFC,
http://www.ietf.org/rfc/rfc1813.txt
[RFC3530]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame,
M. Eisler, D. Noveck, "NFS version 4 Protocol", Standards
Track RFC, http://www.ietf.org/rfc/rfc3530.txt
[NFSDDP] [NFSDDP]
B. Callaghan, T. Talpey, "NFS Direct Data Placement" Internet B. Callaghan, T. Talpey, "NFS Direct Data Placement", Internet
Draft Work in Progress, draft-ietf-nfsv4-nfsdirect Draft Work in Progress, draft-ietf-nfsv4-nfsdirect
[RFC5040] [RFC5040]
R. Recio et al., "A Remote Direct Memory Access Protocol R. Recio et al., "A Remote Direct Memory Access Protocol
Specification", Standards Track RFC Specification", Standards Track RFC,
http://www.ietf.org/rfc/rfc5040.txt
[RFC5041] [RFC5041]
H. Shah et al., "Direct Data Placement over Reliable H. Shah et al., "Direct Data Placement over Reliable
Transports", Standards Track RFC Transports", Standards Track RFC,
http://www.ietf.org/rfc/rfc5041.txt
[NFSRDMAPS] [NFSRDMAPS]
T. Talpey, C. Juszczak, "NFS RDMA Problem Statement", Internet T. Talpey, C. Juszczak, "NFS RDMA Problem Statement", Internet
Draft Work in Progress, draft-ietf-nfsv4-nfs-rdma-problem- Draft Work in Progress, draft-ietf-nfsv4-nfs-rdma-problem-
statement statement
[NFSv4.1] [NFSv4.1]
S. Shepler et al., ed., "NFSv4 Minor Version 1" Internet Draft S. Shepler et al., ed., "NFSv4 Minor Version 1", Internet
Work in Progress, draft-ietf-nfsv4-minorversion1 Draft Work in Progress, draft-ietf-nfsv4-minorversion1
[IB] [IB]
Infiniband Architecture Specification, available from Infiniband Architecture Specification, available from
http://www.infinibandta.org http://www.infinibandta.org
[IBPORT] [IBPORT]
Infiniband Trade Association, "IP Addressing Annex", available Infiniband Trade Association, "IP Addressing Annex", available
from http://www.infinibandta.org from http://www.infinibandta.org
[IANA-RPC] Authors' Addresses
IANA Sun RPC number statement,
http://www.iana.org/assignments/sun-rpc-numbers
16. Authors' Addresses
Tom Talpey Tom Talpey
Network Appliance, Inc. Network Appliance, Inc.
1601 Trapelo Road, #16 1601 Trapelo Road, #16
Waltham, MA 02451 USA Waltham, MA 02451 USA
Phone: +1 781 768 5329 Phone: +1 781 768 5329
EMail: thomas.talpey@netapp.com EMail: thomas.talpey@netapp.com
Brent Callaghan Brent Callaghan
Apple Computer, Inc. Apple Computer, Inc.
MS: 302-4K MS: 302-4K
2 Infinite Loop 2 Infinite Loop
Cupertino, CA 95014 USA Cupertino, CA 95014 USA
EMail: brentc@apple.com EMail: brentc@apple.com
17. Intellectual Property and Copyright Statements Intellectual Property Statement
Full Copyright Statement The IETF Trust 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 any IETF 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.
Copyright (C) The IETF Trust (2008). Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF on-
line IPR repository at http://www.ietf.org/ipr
This document is subject to the rights, licenses and restrictions The IETF invites any interested party to bring to its attention any
contained in BCP 78, and except as set forth therein, the authors copyrights, patents or patent applications, or other proprietary
retain all their rights. rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org
This document and the information contained herein are provided on The definitive version of an IETF Document is that published by, or
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE under the auspices of, the IETF. Versions of IETF Documents that
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE are published by third parties, including those that are translated
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL into other languages, should not be considered to be definitive
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY versions of IETF Documents. The definitive version of these Legal
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE Provisions is that published by, or under the auspices of, the
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS IETF. Versions of these Legal Provisions that are published by
FOR A PARTICULAR PURPOSE. third parties, including those that are translated into other
languages, should not be considered to be definitive versions of
these Legal Provisions.
Intellectual Property For the avoidance of doubt, each Contributor to the IETF Standards
The IETF takes no position regarding the validity or scope of any Process licenses each Contribution that he or she makes as part of
Intellectual Property Rights or other rights that might be claimed the IETF Standards Process to the IETF Trust pursuant to the
to pertain to the implementation or use of the technology described provisions of RFC 5378. No language to the contrary, or terms,
in this document or the extent to which any license under such conditions or rights that differ from or are inconsistent with the
rights might or might not be available; nor does it represent that rights and licenses granted under RFC 5378, shall have any effect
it has made any independent effort to identify any such rights. and shall be null and void, whether published or posted by such
Information on the procedures with respect to rights in RFC Contributor, or included with or in such Contribution.
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Disclaimer of Validity
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any All IETF Documents and the information contained therein are
copyrights, patents or patent applications, or other proprietary provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
rights that may cover technology that may be required to implement HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
this standard. Please address the information to the IETF at ietf- SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
ipr@ietf.org. DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Copyright Statement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
 End of changes. 44 change blocks. 
105 lines changed or deleted 142 lines changed or added

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