< draft-ietf-nfsv4-rfc5667bis-10.txt   draft-ietf-nfsv4-rfc5667bis-11.txt >
Network File System Version 4 C. Lever, Ed. Network File System Version 4 C. Lever, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 5667 (if approved) May 5, 2017 Obsoletes: 5667 (if approved) May 8, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: November 6, 2017 Expires: November 9, 2017
Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version
One One
draft-ietf-nfsv4-rfc5667bis-10 draft-ietf-nfsv4-rfc5667bis-11
Abstract Abstract
This document specifies Upper Layer Bindings of Network File System This document specifies Upper Layer Bindings of Network File System
(NFS) protocol versions to RPC-over-RDMA Version One, enabling the (NFS) protocol versions to RPC-over-RDMA Version One, enabling the
use of Direct Data Placement. This document obsoletes RFC 5667. use of Direct Data Placement. This document obsoletes RFC 5667.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 6, 2017. This Internet-Draft will expire on November 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 9, line 40 skipping to change at page 9, line 40
matching non-empty Write chunk, an NFS version 4 server MUST matching non-empty Write chunk, an NFS version 4 server MUST
return an empty Write chunk in that Write list position. return an empty Write chunk in that Write list position.
o If there are more READ operations than Write chunks, then o If there are more READ operations than Write chunks, then
remaining NFS Read operations in an NFS version 4 COMPOUND that remaining NFS Read operations in an NFS version 4 COMPOUND that
have no matching Write chunk MUST return their results inline. have no matching Write chunk MUST return their results inline.
5.4.2. Chunk List Complexity 5.4.2. Chunk List Complexity
The RPC-over-RDMA Version One protocol does not place any limit on The RPC-over-RDMA Version One protocol does not place any limit on
the number of chunks or segments that may appear in the Read or Write the number of chunks or segments that may appear in Read or Write
lists. However, for various reasons NFS version 4 server lists. However, for various reasons NFS version 4 server
implementations often have practical limits on the number of chunks implementations often have practical limits on the number of chunks
or segments they are prepared to process in one message. or segments they are prepared to process in a single RPC transaction
conveyed via RPC-over-RDMA Version One.
These implementation limits are especially important when Kerberos These implementation limits are especially important when Kerberos
integrity or privacy is in use [RFC7861]. GSS services increase the integrity or privacy is in use [RFC7861]. GSS services increase the
size of credential material in RPC headers, potentially requiring size of credential material in RPC headers, potentially requiring
more frequent use of Long messages. This can increase the complexity more frequent use of Long messages. This can increase the complexity
of chunk lists independent of the NFS version 4 COMPOUND being of chunk lists independent of the NFS version 4 COMPOUND being
conveyed. conveyed.
To avoid encountering server chunk list complexity limits, NFS In the absence of explicit knowledge of the server's limits, NFS
version 4 clients SHOULD follow the prescriptions listed below when Version 4 clients SHOULD follow the prescriptions listed below when
constructing transport headers: constructing RPC-over-RDMA Version One messages. NFS Version 4
servers MUST accept and process such requests.
o The Read list can contain either a Position-Zero Read chunk, one o The Read list can contain either a Position-Zero Read chunk, one
Read chunk with a non-zero Position, or both. Read chunk with a non-zero Position, or both.
o The Write list can contain no more than one Write chunk. o The Write list can contain no more than one Write chunk.
o Any chunk can contain up to sixteen RDMA segments. o Any chunk can contain up to sixteen RDMA segments.
NFS version 4 clients wishing to send more complex chunk lists can NFS version 4 clients wishing to send more complex chunk lists can
provide configuration interfaces to bound the complexity of NFS provide configuration interfaces to bound the complexity of NFS
version 4 COMPOUNDs, limit the number of elements in scatter-gather version 4 COMPOUNDs, limit the number of elements in scatter-gather
operations, and avoid other sources of RPC-over-RDMA chunk overruns operations, and avoid other sources of chunk overruns at the
at the receiving peer. receiving peer.
An NFS Version 4 server has some flexibility in how it indicates that An NFS Version 4 server SHOULD return one of the following responses
an RPC-over-RDMA Version One message received from an NFS Version 4 to a client that has sent an RPC transaction via RPC-over-RDMA
client is valid but cannot be processed. Examples include: Version One which cannot be processed due to chunk list complexity
limits on the server:
o A problem is detected by the transport layer while parsing the o A problem is detected by the transport layer while parsing the
transport header in an RPC Call message. The server responds with transport header in an RPC Call message. The server responds with
an RDMA_ERROR message with the err field set to ERR_CHUNK. an RDMA_ERROR message with the err field set to ERR_CHUNK.
o A problem is detected during XDR decoding of the RPC Call message o A problem is detected during XDR decoding of the RPC Call message
while the RPC layer reassembles the call's XDR stream. The server while the RPC layer reassembles the call's XDR stream. The server
responds with an RPC reply with its "reply_stat" field set to responds with an RPC reply with its "reply_stat" field set to
MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS. MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS.
skipping to change at page 18, line 28 skipping to change at page 18, line 28
o An IANA Considerations Section has been added, which specifies the o An IANA Considerations Section has been added, which specifies the
port assignments for NFS/RDMA. This replaces the example port assignments for NFS/RDMA. This replaces the example
assignment that appeared in [RFC5666]. assignment that appeared in [RFC5666].
o Code excerpts have been removed, and figures have been modernized. o Code excerpts have been removed, and figures have been modernized.
Appendix B. Acknowledgments Appendix B. Acknowledgments
The author gratefully acknowledges the work of Brent Callaghan and The author gratefully acknowledges the work of Brent Callaghan and
Tom Talpey on the original NFS Direct Data Placement specification Tom Talpey on the original NFS Direct Data Placement specification
[RFC5667]. The author also wishes to thank Bill Baker and Greg [RFC5667]. Tom contributed the text of Section 5.4.2.
Marsden for their support of this work.
Dave Noveck provided excellent review, constructive suggestions, and Dave Noveck provided excellent review, constructive suggestions, and
consistent navigational guidance throughout the process of drafting consistent navigational guidance throughout the process of drafting
this document. Dave also contributed the text of Section 5.6 and this document. Dave contributed the text of Section 5.6 and
Section 6, and insisted on precise discussion of reply size Section 6, and insisted on precise discussion of reply size
estimation. estimation.
Thanks to Karen Deitke for her sharp observations about idempotency, Thanks to Karen Deitke for her sharp observations about idempotency,
NFS COMPOUNDs, and NFS sessions. NFS COMPOUNDs, and NFS sessions.
Special thanks go to Transport Area Director Spencer Dawkins, nfsv4 Special thanks go to Transport Area Director Spencer Dawkins, nfsv4
Working Group Chair Spencer Shepler, and nfsv4 Working Group Working Group Chair Spencer Shepler, and nfsv4 Working Group
Secretary Thomas Haynes for their support. Secretary Thomas Haynes for their support. The author also wishes to
thank Bill Baker and Greg Marsden for their support of this work.
Author's Address Author's Address
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
USA USA
Phone: +1 248 816 6463 Phone: +1 248 816 6463
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 12 change blocks. 
18 lines changed or deleted 21 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/