idnits 2.17.1 draft-callaghan-nfsdirect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'NFSRDMA' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC1831' is defined on line 191, but no explicit reference was found in the text == Unused Reference: 'RFC1832' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC1094' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC1813' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'RFC3530' is defined on line 213, but no explicit reference was found in the text -- No information found for draft-callaghan-rpc-rdma - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RPCRDMA' == Outdated reference: A later version (-01) exists of draft-talpey-nfsv4-rdma-sess-00 -- Possible downref: Normative reference to a draft: ref. 'NFSRDMA' ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** Downref: Normative reference to an Informational RFC: RFC 1094 ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Brent Callaghan 3 Expires: November 2003 Sun Microsystems, Inc. 4 Tom Talpey 5 Network Appliance, Inc. 7 Document: draft-callaghan-nfsdirect-00.txt May, 2003 9 NFS Direct Data Placement 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 The RDMA transport for ONC RPC supports direct data placement for NFS 43 data. Direct data placement not only reduces the amount of data that 44 needs to be copied in an NFS call, but allows much of the data 45 movement over the network to be implemented in RDMA hardware. This 46 draft describes the use of direct data placement by means of server- 47 initiated RDMA Writes into client-supplied buffers in a Write list 48 for implementations of NFS versions 2, 3, and 4 over an RDMA 49 transport. 51 1. Introduction 53 The RDMA Transport for ONC RPC [RPCRDMA] allows an RPC client 54 application to post buffers in a Write list that accept specific 55 results from an RPC call. The RDMA transport header conveys this 56 list of client buffer addresses to the server where the application 57 can associate them with result data and use RDMA Write to transfer 58 the results directly into the posted buffers on the client. The 59 client and server must agree on a consistent mapping of posted reply 60 buffers to RPC results. This document details the mapping for each 61 version of the NFS protocol. 63 2. RDMA Write List 65 The RDMA Write list, in the RDMA transport header, allows the client 66 to post one or more buffers into which the server will RDMA Write 67 designated result chunks directly. If the client sends a null write 68 list, then results from the RPC call will be returned as either an 69 in-line reply, as chunks in an RDMA Read list of server-posted 70 buffers, or in a client-posted reply buffer. 72 Each posted buffer in a Write list is represented as an array of 73 memory segments. This allows the client some flexibility in 74 submitting discontiguous memory segments into which the server will 75 scatter the result. Each segment is described by a triplet 76 consisting of the segment handle or steering tag (STag), segment 77 length, and memory address or offset. 79 struct xdr_rdma_segment { 80 uint32 handle; /* Registered memory handle */ 81 uint32 length; /* Length of the chunk in bytes */ 82 uint64 offset; /* Chunk virtual address or offset */ 83 }; 84 struct xdr_write_chunk { 85 struct xdr_rdma_segment target<>; 86 }; 88 struct xdr_write_list { 89 struct xdr_write_chunk entry; 90 struct xdr_write_list *next; 91 }; 93 The sum of the segment lengths yields the total size of the buffer, 94 which must be large enough to accept the result. If the buffer is 95 too small the server must return an XDR encode error. The server 96 must return the result data for a posted buffer by progressively 97 filling its segments, perhaps leaving some trailing segments unfilled 98 or partially full if the size of the result is less than the total 99 size of the buffer segments. 101 The server returns the RDMA Write list to the client with the segment 102 length fields overwritten to indicate the amount of data RDMA Written 103 to each segment. Results returned by direct placement must not be 104 returned by other methods, e.g. by read chunk list or in-line. 106 The RDMA Write list allows the client to provide multiple result 107 buffers - each buffer must map to a specific result in the reply. The 108 NFS client and server implementations must agree on the mapping of 109 results to buffers for each RPC procedure. The following sections 110 describe this mapping for versions of the NFS protocol. 112 3. NFS Versions 2 and 3 Mapping 114 A single RDMA write list entry may be posted by the client to receive 115 either the opaque file data from a READ request or the pathname from 116 a READLINK request. The server will ignore a Write list for any 117 other NFS procedure, as well as any Write list entries beyond the 118 first in the list. 120 4. NFS Version 4 Mapping 122 This specification applies to the first minor version of NFS version 123 4 (NFSv4.0) and any subsequent minor versions that do not override 124 this mapping. 126 The Write list will be considered only for the COMPOUND procedure. 127 This procedure returns results from a sequence of operations. 128 Designated operations consume entries from the Write chunk list. The 129 first entry in the Write chunk list must be used by the first 130 designated operation in the compound procedure. If the Write chunk 131 list is consumed before all designated operations are evaluated, 132 remaining results will be returned in-line or by Read chunk list as 133 appropriate. If a Write chunk list entry is presented, then a 134 designated operation must use it to return its result data. However, 135 Write list chunk with a zero length buffer indicates that the 136 corresponding designated operation is to return its result in-line or 137 by Read chunk list. 139 The designated operations and their results are the opaque file data 140 from the READ operation, and the pathname from the READLINK 141 operation. 143 The following example shows an RDMA Write list with three posted 144 buffers A, B, and C. The designated operations in the compound 145 request, READ and READLINK, consume the posted buffers by writing 146 their results back to each buffer. 148 RDMA Write list: 150 A --> B --> C 152 Compound request: 154 PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ 155 | | | 156 v v v 157 A B C 159 If the client does not want to have the READLINK result returned 160 directly, then it sets the values in the segment triplet for buffer B 161 to zeros so that the READLINK result will be returned in-line. 163 5. Security 165 The RDMA transport for ONC RPC supports RPCSEC_GSS security as well 166 as link-level security. The use of RDMA Write to return RPC results 167 does not affect ONC RPC security. 169 6. IANA Considerations 171 NFS use of direct data placement introduces no new IANA 172 considerations. 174 7. Acknowledgements 176 The authors would like to thank Dave Noveck and Chet Juszczak for 177 their contributions to this document. 179 8. References 181 [RPCRDMA] 182 B. Callaghan, T. Talpey, "RDMA Transport for ONC RPC" 183 http://www.ietf.org/internet-drafts/ 184 draft-callaghan-rpc-rdma-00.txt 186 [NFSRDMA] 187 T. Talpey, S. Shepler, "NFSv4 RDMA and Session Extensions" 188 http://www.ietf.org/internet-drafts/ 189 draft-talpey-nfsv4-rdma-sess-00.txt 191 [RFC1831] 192 R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification 193 Version 2", 194 Standards Track RFC, 195 http://www.ietf.org/rfc/rfc1831.txt 197 [RFC1832] 198 R. Srinivasan, "XDR: External Data Representation Standard", 199 Standards Track RFC, 200 http://www.ietf.org/rfc/rfc1832.txt 202 [RFC1094] 203 "NFS: Network File System Protocol Specification", 204 (NFS version 2) Informational RFC, 205 http://www.ietf.org/rfc/rfc1094.txt 207 [RFC1813] 208 B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3 Protocol 209 Specification", 210 Informational RFC, 211 http://www.ietf.org/rfc/rfc1813.txt 213 [RFC3530] 214 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 215 Eisler, D. Noveck, "NFS version 4 Protocol", 216 Standards Track RFC, 217 http://www.ietf.org/rfc/rfc3530.txt 219 9. Authors' Addresses 221 Brent Callaghan 222 Sun Microsystems, Inc. 223 17 Network Circle 224 Menlo Park, California 94025 USA 226 Phone: +1 650 786 5067 227 EMail: brent.callaghan@sun.com 229 Tom Talpey 230 Network Appliance, Inc. 231 375 Totten Pond Road 232 Waltham, MA 02451 USA 234 Phone: +1 781 768 5329 235 EMail: thomas.talpey@netapp.com 237 10. Full Copyright Statement 239 Copyright (C) The Internet Society (2003). All Rights Reserved. 241 This document and translations of it may be copied and furnished to 242 others, and derivative works that comment on or otherwise explain it 243 or assist in its implementation may be prepared, copied, published 244 and distributed, in whole or in part, without restriction of any 245 kind, provided that the above copyright notice and this paragraph are 246 included on all such copies and derivative works. However, this 247 document itself may not be modified in any way, such as by removing 248 the copyright notice or references to the Internet Society or other 249 Internet organizations, except as needed for the purpose of 250 developing Internet standards in which case the procedures for 251 copyrights defined in the Internet Standards process must be 252 followed, or as required to translate it into languages other than 253 English. 255 The limited permissions granted above are perpetual and will not be 256 revoked by the Internet Society or its successors or assigns. 258 This document and the information contained herein is provided on an 259 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 260 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 261 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 262 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 263 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.