--- 1/draft-ietf-nfsv4-nfsdirect-05.txt 2007-06-30 21:12:06.000000000 +0200 +++ 2/draft-ietf-nfsv4-nfsdirect-06.txt 2007-06-30 21:12:06.000000000 +0200 @@ -1,19 +1,19 @@ NFSv4 Working Group Tom Talpey Internet-Draft Network Appliance, Inc. Intended status: Standards Track Brent Callaghan -Expires: November 8, 2007 Apple Computer, Inc. - May 7, 2007 +Expires: January 1, 2008 Apple Computer, Inc. + July 1, 2007 NFS Direct Data Placement - draft-ietf-nfsv4-nfsdirect-05 + draft-ietf-nfsv4-nfsdirect-06 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -47,43 +47,42 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Transfers from NFS Client to NFS Server . . . . . . . . . . 2 3. Transfers from NFS Server to NFS Client . . . . . . . . . . 3 4. NFS Versions 2 and 3 Mapping . . . . . . . . . . . . . . . . 4 5. NFS Version 4 Mapping . . . . . . . . . . . . . . . . . . . 5 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 - 10. Informative References . . . . . . . . . . . . . . . . . . 9 + 10. Informative References . . . . . . . . . . . . . . . . . . 8 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9 - 12. Intellectual Property and Copyright Statements . . . . . 10 + 12. Intellectual Property and Copyright Statements . . . . . . 9 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction The RDMA Transport for ONC RPC [RPCRDMA] allows an RPC client application to post buffers in a Chunk list for specific arguments and results from an RPC call. The RDMA transport header conveys this list of client buffer addresses to the server where the application can associate them with client data and use RDMA operations to transfer the results directly to and from the posted buffers on the client. The client and server must agree on a consistent mapping of posted buffers to RPC. This document details the mapping for each - version of the NFS protocol [RFC1831] [RFC4506] [RFC1094] [RFC1813] - [RFC3530] [NFSv4.1]. + version of the NFS protocol [RFC1094] [RFC1813] [RFC3530] [NFSv4.1]. 2. Transfers from NFS Client to NFS Server The RDMA Read list, in the RDMA transport header, allows an RPC 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 an RDMA Read list and be moved efficiently and directly-placed by an RDMA READ operation initiated by the server. The process of identifying these chunks for the RDMA Read list can be @@ -136,21 +135,21 @@ which MUST be large enough to accept the result. If the buffer is too small, the server MUST return an XDR encode error. The server MUST return the result data for a posted buffer by progressively filling its segments, perhaps leaving some trailing segments unfilled or partially full if the size of the result is less than the total size of the buffer segments. The server returns the RDMA Write list to the client with the segment length fields overwritten to indicate the amount of data RDMA Written to each segment. Results returned by direct placement MUST not be - returned by other methods, e.g. by read chunk list or inline. If no + returned by other methods, e.g., by read chunk list or inline. If no result data at all is returned for the element, the server places no data in the buffer(s), but does return zeroes in the segment length fields corresponding to the result. The RDMA Write list allows the client to provide multiple result buffers - each buffer maps to a specific result in the reply. The NFS client and server implementations agree by specifying the mapping of results to buffers for each RPC procedure. The following sections describe this mapping for versions of the NFS protocol. @@ -227,21 +226,21 @@ This specification applies to the first minor version of NFS version 4 (NFSv4.0) and any subsequent minor versions that do not override this mapping. The Write list MUST be considered only for the COMPOUND procedure. This procedure returns results from a sequence of operations. Only the opaque file data from an NFS READ operation, and the pathname from a READLINK operation MUST utilize entries from the Write list. - If there is no Write list, i.e. the list is null, then any READ or + If there is no Write list, i.e., the list is null, then any READ or READLINK operations in the COMPOUND MUST return their data inline. The NFSv4.0 client MUST ensure that any result of its READ and READLINK requests fits within its receive buffers, lest an RDMA transport error result upon transfer. The first entry in the Write list MUST be used by the first READ or READLINK in the COMPOUND request. The next Write list entry by the by the next READ or READLINK, and so on. If there are more READ or READLINK operations than Write list entries, then any remaining operations MUST return their results inline. @@ -296,21 +294,21 @@ involved in building COMPOUNDs by NFS make such a mechanism unworkable. However, typical NFS version 4 clients rarely issue such problematic requests. In practice, they behave in much more predictable ways, in fact most still support the traditional rsize/wsize mount parameters. Therefore, most NFS version 4 clients function over RPC/RDMA in the same way as NFS versions 2 and 3, operationally. There are however advantages to allowing both client and server to - operate with prearranged sie constraints, for example use of the + operate with prearranged size constraints, for example use of the sizes to better manage the server's response cache. An extension to NFS version 4 supporting a more comprehensive exchange of upper layer parameters is part of [NFSv4.1]. 6. Security 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 does not affect ONC RPC security. @@ -328,57 +326,45 @@ specification 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 use the alternative well-known port number for its RPC/RDMA service by IANA. The chosen port MAY 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 - MUST use the alternative well-known port number for its RPC/RDMA - service by IANA. Clients SHOULD connect to this well-known port - without consulting the RPC portmapper (as for NFSv4/TCP). The - following port is assigned to an NFS service over an RPC/RDMA - transport: - - nfs-rdma 2050 + An NFS version 4 server supporting RPC/RDMA on such a network MUST + use the alternative well-known port number for its RPC/RDMA service + by IANA. Clients SHOULD connect to this well-known port without + consulting the RPC portmapper (as for NFSv4/TCP). The port number + assigned to an NFS service over an RPC/RDMA transport is available + from the IANA port registry [RFC3232]. 8. Acknowledgements The authors would like to thank Dave Noveck and Chet Juszczak for their contributions to this document. 9. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Best Current Practice, BCP 14, RFC 2119, March 1997. - [RFC1831] - R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification - Version 2", - Standards Track RFC, - http://www.ietf.org/rfc/rfc1831.txt - - [RFC4506] - M. Eisler, Ed., "XDR: External Data Representation Standard", - Standards Track RFC, - http://www.ietf.org/rfc/rfc4506.txt - [RFC1094] "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 [RFC1833] R. Srinivasan, "Binding Protocols for ONC RPC Version 2", Standards Track RFC, http://www.ietf.org/rfc/rfc1833.txt @@ -384,37 +370,43 @@ 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 10. Informative References + [RFC3232] + Internet Assigned Numbers Authority (IANA), + Port Registry database, + http://www.ietf.org/rfc/rfc3232.txt + http://www.iana.org/assignments/port-numbers + [RPCRDMA] T. Talpey, B. Callaghan, "RDMA Transport for ONC RPC" Internet Draft Work in Progress, draft-ietf-nfsv4-rpcrdma [NFSv4.1] - S. Shepler et. al., ed., "NFSv4 Minor Version 1" + S. Shepler et al., ed., "NFSv4 Minor Version 1" Internet Draft Work in Progress, draft-ietf-nfsv4-minorversion1 [DDP] - H. Shah et al, "Direct Data Placement over Reliable Transports", + H. Shah et al., "Direct Data Placement over Reliable Transports", Standards Track RFC, draft-ietf-rddp-ddp [RDMAP] - R. Recio et al, "An RDMA Protocol Specification", + R. Recio et al., "An RDMA Protocol Specification", Standards Track RFC, draft-ietf-rddp-rdmap 11. Authors' Addresses Tom Talpey Network Appliance, Inc. 375 Totten Pond Road Waltham, MA 02451 USA