< draft-ietf-nfsv4-nfsdirect-02.txt   draft-ietf-nfsv4-nfsdirect-03.txt >
Internet-Draft Brent Callaghan Internet-Draft Tom Talpey
Expires: April 2006 Tom Talpey Expires: December 2006 Brent Callaghan
Document: draft-ietf-nfsv4-nfsdirect-02 October, 2005 Document: draft-ietf-nfsv4-nfsdirect-03 June, 2006
NFS Direct Data Placement NFS Direct Data Placement
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
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 docu- months and may be updated, replaced, or obsoleted by other
ments at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts
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 The list of Inter- http://www.ietf.org/ietf/1id-abstracts.txt
net-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.
Abstract Abstract
The RDMA transport for ONC RPC provides direct data placement for NFS The RDMA transport for ONC RPC provides direct data placement for NFS
data. Direct data placement not only reduces the amount of data that data. Direct data placement not only reduces the amount of data that
needs to be copied in an NFS call, but allows much of the data needs to be copied in an NFS call, but allows much of the data
movement over the network to be implemented in RDMA hardware. This movement over the network to be implemented in RDMA hardware. This
draft describes the use of direct data placement by means of server- draft describes the use of direct data placement by means of server-
initiated RDMA operations into client-supplied buffers in a Chunk initiated RDMA operations into client-supplied buffers in a Chunk
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Transfers from NFS Client to NFS Server . . . . . . . . . . 2 2. Transfers from NFS Client to NFS Server . . . . . . . . . . 2
3. Transfers from NFS Server to NFS Client . . . . . . . . . . 2 3. Transfers from NFS Server to NFS Client . . . . . . . . . . 2
4. NFS Versions 2 and 3 Mapping . . . . . . . . . . . . . . . . 4 4. NFS Versions 2 and 3 Mapping . . . . . . . . . . . . . . . . 4
5. NFS Version 4 Mapping . . . . . . . . . . . . . . . . . . . 5 5. NFS Version 4 Mapping . . . . . . . . . . . . . . . . . . . 5
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . 8
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 8 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
12. Intellectual Property and Copyright Statements . . . . . . 8 12. Intellectual Property and Copyright Statements . . . . . . 9
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The RDMA Transport for ONC RPC [RPCRDMA] allows an RPC client The RDMA Transport for ONC RPC [RPCRDMA] allows an RPC client
application to post buffers in a Chunk list for specific arguments application to post buffers in a Chunk list for specific arguments
and results from an RPC call. The RDMA transport header conveys this and results from an RPC call. The RDMA transport header conveys this
list of client buffer addresses to the server where the application list of client buffer addresses to the server where the application
can associate them with client data and use RDMA operations to can associate them with client data and use RDMA operations to
transfer the results directly to and from the posted buffers on the transfer the results directly to and from the posted buffers on the
client. The client and server must agree on a consistent mapping of client. The client and server must agree on a consistent mapping of
posted buffers to RPC. This document details the mapping for each posted buffers to RPC. This document details the mapping for each
version of the NFS protocol. version of the NFS protocol [RFC1831] [RFC1832] [RFC1094] [RFC1813]
[RFC3530] [NFSv4.1].
2. Transfers from NFS Client to NFS Server 2. Transfers from NFS Client to NFS Server
The RDMA Read list, in the RDMA transport header, allows an RPC The RDMA Read list, in the RDMA transport header, allows an RPC
client to marshal RPC call data selectively. Large chunks of data, client to marshal RPC call data selectively. Large chunks of data,
such as the file data of an NFS WRITE request, may be referenced by such as the file data of an NFS WRITE request, may be referenced by
an RDMA Read list and be moved efficiently and directly-placed by an an RDMA Read list and be moved efficiently and directly-placed by an
RDMA READ operation initiated by the server. RDMA READ operation initiated by the server.
The process of identifying these chunks for the RDMA Read list can be The process of identifying these chunks for the RDMA Read list can be
skipping to change at page 7, line 14 skipping to change at page 7, line 14
restrict its use of optional padding to COMPOUND requests containing restrict its use of optional padding to COMPOUND requests containing
only a single WRITE operation. only a single WRITE operation.
Unlike NFS versions 2 and 3, the maximum size of an NFS version 4 Unlike NFS versions 2 and 3, the maximum size of an NFS version 4
COMPOUND is unbounded, even when RDMA chunks are in use. While it COMPOUND is unbounded, even when RDMA chunks are in use. While it
might appear that a configuration protocol exchange (such as the one might appear that a configuration protocol exchange (such as the one
described in [RPCRDMA]) would help, in fact the layering issues described in [RPCRDMA]) would help, in fact the layering issues
involved in building COMPOUNDs by NFS make such a mechanism involved in building COMPOUNDs by NFS make such a mechanism
unworkable. Instead, an extension to NFS version 4 supporting a more unworkable. Instead, an extension to NFS version 4 supporting a more
comprehensive exchange of upper layer (NFSv4) parameters is proposed comprehensive exchange of upper layer (NFSv4) parameters is proposed
in [NFSSESS]. This proposal also addresses other use of the sizes, in [NFSv4.1]. This proposal also addresses other use of the sizes,
such as in the server's response cache. such as in the server's response cache.
6. Security 6. Security
The RDMA transport for ONC RPC supports RPCSEC_GSS security as well The RDMA transport for ONC RPC supports RPCSEC_GSS security as well
as link-level security. The use of RDMA Write to return RPC results as link-level security. The use of RDMA Write to return RPC results
does not affect ONC RPC security. does not affect ONC RPC security.
7. IANA Considerations 7. IANA Considerations
NFS use of direct data placement introduces no new IANA NFS use of direct data placement may introduce a need for an
considerations. additional NFS port number assignment for networks which share
traditional UDP and TCP port spaces with RDMA services. The iWARP
[DDP] [RDMAP] protocol is such an example (Infiniband is not).
NFS servers for versions 2 and 3 [RFC1094] [RFC1813] traditionally
listen for clients on UDP and TCP port 2049, and additionally, they
register these with the portmapper. NFS servers for version 4
[RFC3050] are required to listen on TCP port 2049, and are not
required to register.
An NFS version 2 or version 3 server supporting RPC/RDMA on such a
network and registering itself with the RPC portmapper may choose an
arbitrary port, or may be assigned an alternative well-known port
number for its RPC/RDMA service by IANA. The chosen port must be
registered with the RPC portmapper under the netid assigned by the
requirement in [RPCRDMA].
An NFS version 4 server supporting RPC/RDMA on such a network must be
assigned an alternative well-known port number for its RPC/RDMA
service by IANA. Clients will connect to this well-known port
without consulting the RPC portmapper (as for NFSv4/TCP).
Any subsequent NFS version 4 minor version's [NFSv4.1] server may
reuse port 2049, by requiring the client to perform the RDMA session
negotiation supported by this protocol. If it does not require the
client to negotiate an RDMA-enabled session, it must use the
alternative port for RPC/RDMA, as for version 4.
This is not an issue on non-IP transports such as native Infiniband,
where a non-colliding port translation scheme is used [IBPORT]. On
such interfaces, the server can simply listen on the port mapped from
the IANA-assigned NFS 2049, or any other port as assigned by the
native transport. Such assignments are out of the scope of IANA, and
of this document.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Dave Noveck and Chet Juszczak for The authors would like to thank Dave Noveck and Chet Juszczak for
their contributions to this document. their contributions to this document.
9. Normative References 9. Normative References
[RFC1831] [RFC1831]
R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
skipping to change at page 8, line 18 skipping to change at page 8, line 51
[RFC3530] [RFC3530]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, "NFS version 4 Protocol", Eisler, D. Noveck, "NFS version 4 Protocol",
Standards Track RFC, Standards Track RFC,
http://www.ietf.org/rfc/rfc3530.txt http://www.ietf.org/rfc/rfc3530.txt
10. Informative References 10. Informative References
[RPCRDMA] [RPCRDMA]
B. Callaghan, T. Talpey, "RDMA Transport for ONC RPC" T. Talpey, B. Callaghan, "RDMA Transport for ONC RPC"
Internet Draft Work in Progress, Internet Draft Work in Progress,
draft-ietf-nfsv4-rpcrdma draft-ietf-nfsv4-rpcrdma
[NFSSESS] [NFSv4.1]
T. Talpey, S. Shepler, J. Bauman, "NFSv4 Session Extensions" S. Shepler, ed., "NFSv4 Minor Version 1"
Internet Draft Work in Progress, Internet Draft Work in Progress,
draft-ietf-nfsv4-sess draft-ietf-nfsv4-minorversion1
11. Authors' Addresses [DDP]
H. Shah et al, "Direct Data Placement over Reliable Transports",
Internet Draft Work in Progress,
draft-ietf-rddp-ddp
Brent Callaghan [RDMAP]
1614 Montalto Dr. R. Recio et al, "An RDMA Protocol Specification",
Mountain View, California 94040 USA Internet Draft Work in Progress,
draft-ietf-rddp-rdmap
Phone: +1 650 968 2333 [IBPORT]
EMail: brent.callaghan@gmail.com Infiniband Trade Association, "IP Addressing Annex",
available from www.infinibandta.org
11. Authors' Addresses
Tom Talpey Tom Talpey
Network Appliance, Inc. Network Appliance, Inc.
375 Totten Pond Road 375 Totten Pond Road
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
Apple Computer, Inc.
MS: 302-4K
2 Infinite Loop
Cupertino, CA 95014 USA
EMail: brentc@apple.com
12. Intellectual Property and Copyright Statements 12. Intellectual Property and Copyright Statements
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC docu- Information on the procedures with respect to rights in RFC
ments can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this speci- of such proprietary rights by implementers or users of this
fication can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is sub- Copyright (C) The Internet Society (2006).
ject to the rights, licenses and restrictions contained in BCP 78,
and except as set forth therein, the authors retain all their This document is subject to the rights, licenses and restrictions
rights. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgement Acknowledgement
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. 21 change blocks. 
42 lines changed or deleted 95 lines changed or added

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