< draft-ietf-nfsv4-rfc5667bis-09.txt   draft-ietf-nfsv4-rfc5667bis-10.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) April 10, 2017 Obsoletes: 5667 (if approved) May 5, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: October 12, 2017 Expires: November 6, 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-09 draft-ietf-nfsv4-rfc5667bis-10
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 October 12, 2017. This Internet-Draft will expire on November 6, 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 2, line 40 skipping to change at page 2, line 40
3.2. RPC Binding Considerations . . . . . . . . . . . . . . . 5 3.2. RPC Binding Considerations . . . . . . . . . . . . . . . 5
4. Upper Layer Bindings for NFS Version 2 and 3 Auxiliary 4. Upper Layer Bindings for NFS Version 2 and 3 Auxiliary
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. MOUNT, NLM, and NSM Protocols . . . . . . . . . . . . . . 6 4.1. MOUNT, NLM, and NSM Protocols . . . . . . . . . . . . . . 6
4.2. NFSACL Protocol . . . . . . . . . . . . . . . . . . . . . 6 4.2. NFSACL Protocol . . . . . . . . . . . . . . . . . . . . . 6
5. Upper Layer Binding For NFS Version 4 . . . . . . . . . . . . 7 5. Upper Layer Binding For NFS Version 4 . . . . . . . . . . . . 7
5.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 7 5.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 7
5.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7 5.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7
5.3. RPC Binding Considerations . . . . . . . . . . . . . . . 8 5.3. RPC Binding Considerations . . . . . . . . . . . . . . . 8
5.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 8 5.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 8
5.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 10 5.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 11
5.6. Session-Related Considerations . . . . . . . . . . . . . 11 5.6. Session-Related Considerations . . . . . . . . . . . . . 12
5.7. Transport Considerations . . . . . . . . . . . . . . . . 12 5.7. Transport Considerations . . . . . . . . . . . . . . . . 13
6. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 13 6. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 16 Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The RPC-over-RDMA Version One transport may employ direct data The RPC-over-RDMA Version One transport may employ direct data
placement to convey data payloads associated with RPC transactions placement to convey data payloads associated with RPC transactions
[I-D.ietf-nfsv4-rfc5666bis]. To enable successful interoperation, [I-D.ietf-nfsv4-rfc5666bis]. To enable successful interoperation,
RPC client and server implementations using RPC-over-RDMA Version One RPC client and server implementations using RPC-over-RDMA Version One
must agree which XDR data items and RPC procedures are eligible to must agree which XDR data items and RPC procedures are eligible to
use direct data placement (DDP). use direct data placement (DDP).
skipping to change at page 9, line 37 skipping to change at page 9, line 37
o If a READ operation returns a union arm which does not contain a o If a READ operation returns a union arm which does not contain a
DDP-eligible result, and the NFS version 4 client has provided a DDP-eligible result, and the NFS version 4 client has provided a
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.
If an NFS version 4 client sends an RPC Call with a Write list that 5.4.2. Chunk List Complexity
contains more chunks than an NFS version 4 server is prepared to
process, the server MUST reject the RPC by responding with an
RDMA_ERROR message with the rdma_err value set to ERR_CHUNK.
If an NFS version 4 client sends an RPC Call with a Read list that The RPC-over-RDMA Version One protocol does not place any limit on
contains more chunks than an NFS version 4 server is prepared to the number of chunks or segments that may appear in the Read or Write
process, the server MUST reject the RPC by responding with an lists. However, for various reasons NFS version 4 server
RDMA_MSG message containing an RPC Reply with an accept status of implementations often have practical limits on the number of chunks
GARBAGE_ARGS, or with an RDMA_ERROR message with the rdma_err value or segments they are prepared to process in one message.
set to ERR_CHUNK.
5.4.2. NFS Version 4 COMPOUND Example These implementation limits are especially important when Kerberos
integrity or privacy is in use [RFC7861]. GSS services increase the
size of credential material in RPC headers, potentially requiring
more frequent use of Long messages. This can increase the complexity
of chunk lists independent of the NFS version 4 COMPOUND being
conveyed.
To avoid encountering server chunk list complexity limits, NFS
version 4 clients SHOULD follow the prescriptions listed below when
constructing transport headers:
o The Read list can contain either a Position-Zero Read chunk, one
Read chunk with a non-zero Position, or both.
o The Write list can contain no more than one Write chunk.
o Any chunk can contain up to sixteen RDMA segments.
NFS version 4 clients wishing to send more complex chunk lists can
provide configuration interfaces to bound the complexity of NFS
version 4 COMPOUNDs, limit the number of elements in scatter-gather
operations, and avoid other sources of RPC-over-RDMA chunk overruns
at the receiving peer.
An NFS Version 4 server has some flexibility in how it indicates that
an RPC-over-RDMA Version One message received from an NFS Version 4
client is valid but cannot be processed. Examples include:
o A problem is detected by the transport layer while parsing the
transport header in an RPC Call message. The server responds with
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
while the RPC layer reassembles the call's XDR stream. The server
responds with an RPC reply with its "reply_stat" field set to
MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS.
After receiving one of these errors, an NFS version 4 client SHOULD
NOT retransmit the failing request, as the result would be the same
error. It SHOULD immediately terminate the RPC transaction
associated with the XID in the reply.
5.4.3. NFS Version 4 COMPOUND Example
The following example shows a Write list with three Write chunks, A, The following example shows a Write list with three Write chunks, A,
B, and C. The NFS version 4 server consumes the provided Write B, and C. The NFS version 4 server consumes the provided Write
chunks by writing the results of the designated operations in the chunks by writing the results of the designated operations in the
compound request (READ and READLINK) back to each chunk. compound request (READ and READLINK) back to each chunk.
Write list: Write list:
A --> B --> C A --> B --> C
skipping to change at page 11, line 42 skipping to change at page 12, line 33
The presence of an NFS session (defined in [RFC5661]) has no effect The presence of an NFS session (defined in [RFC5661]) has no effect
on the operation of RPC-over-RDMA Version One. None of the on the operation of RPC-over-RDMA Version One. None of the
operations introduced to support NFS sessions (e.g. the SEQUENCE operations introduced to support NFS sessions (e.g. the SEQUENCE
operation) contain DDP-eligible data items. There is no need to operation) contain DDP-eligible data items. There is no need to
match the number of session slots with the number of available RPC- match the number of session slots with the number of available RPC-
over-RDMA credits. over-RDMA credits.
However, there are a few new cases where an RPC transaction can fail. However, there are a few new cases where an RPC transaction can fail.
For example, a requester might receive, in response to an RPC For example, a requester might receive, in response to an RPC
request, an RDMA_ERROR message with an rdma_err value of ERR_CHUNK. request, an RDMA_ERROR message with an rdma_err value of ERR_CHUNK.
These situations are no different from existing RPC errors which an These situations are not different from existing RPC errors which an
NFS session implementation is already prepared to handle for other NFS session implementation is already prepared to handle for other
transports. And as with other transports during such a failure, transports. And as with other transports during such a failure,
there might be no SEQUENCE result available to the requester to there might be no SEQUENCE result available to the requester to
distinguish whether failure occurred before or after the requested distinguish whether failure occurred before or after the requested
operations were executed on the responder. operations were executed on the responder.
When a transport error occurs (e.g. RDMA_ERROR), the requester When a transport error occurs (e.g. RDMA_ERROR), the requester
proceeds as usual to match the incoming XID value to a waiting RPC proceeds as usual to match the incoming XID value to a waiting RPC
Call. The RPC transaction is terminated, and the result status is Call. The RPC transaction is terminated, and the result status is
reported to the Upper Layer Protocol. The requester's session reported to the Upper Layer Protocol. The requester's session
implementation then determines the session ID and slot for the failed implementation then determines the session ID and slot for the failed
request, and performs slot recovery to make that slot usable again. request, and performs slot recovery to make that slot usable again.
If this is not done, that slot could be rendered permanently If this were not done, that slot could be rendered permanently
unavailable. unavailable.
5.7. Transport Considerations 5.7. Transport Considerations
5.7.1. Congestion Avoidance 5.7.1. Congestion Avoidance
Section 3.1 of [RFC7530] states: Section 3.1 of [RFC7530] states:
Where an NFSv4 implementation supports operation over the IP Where an NFS version 4 implementation supports operation over the
network protocol, the supported transport layer between NFS and IP IP network protocol, the supported transport layer between NFS and
MUST be an IETF standardized transport protocol that is specified IP MUST be an IETF standardized transport protocol that is
to avoid network congestion; such transports include TCP and the specified to avoid network congestion; such transports include TCP
Stream Control Transmission Protocol (SCTP). and the Stream Control Transmission Protocol (SCTP).
Section 2.9.1 of [RFC5661] also states: Section 2.9.1 of [RFC5661] also states:
Even if NFSv4.1 is used over a non-IP network protocol, it is Even if NFS version 4.1 is used over a non-IP network protocol, it
RECOMMENDED that the transport support congestion control. is RECOMMENDED that the transport support congestion control.
It is permissible for a connectionless transport to be used under It is permissible for a connectionless transport to be used under
NFSv4.1; however, reliable and in-order delivery of data combined NFS version 4.1; however, reliable and in-order delivery of data
with congestion control by the connectionless transport is combined with congestion control by the connectionless transport
REQUIRED. As a consequence, UDP by itself MUST NOT be used as an is REQUIRED. As a consequence, UDP by itself MUST NOT be used as
NFSv4.1 transport. an NFS version 4.1 transport.
RPC-over-RDMA Version One is constructed on a platform of RDMA RPC-over-RDMA Version One is constructed on a platform of RDMA
Reliable Connections [I-D.ietf-nfsv4-rfc5666bis] [RFC5041]. RDMA Reliable Connections [I-D.ietf-nfsv4-rfc5666bis] [RFC5041]. RDMA
Reliable Connections are reliable, connection-oriented transports Reliable Connections are reliable, connection-oriented transports
that guarantee in-order delivery, meeting all above requirements for that guarantee in-order delivery, meeting all above requirements for
NFS version 4 transports. NFS version 4 transports.
5.7.2. Retransmission and Keep-alive 5.7.2. Retransmission and Keep-alive
NFS version 4 client implementations often rely on a transport-layer NFS version 4 client implementations often rely on a transport-layer
skipping to change at page 13, line 40 skipping to change at page 14, line 36
specification to interoperate on RPC-over-RDMA Version One transports specification to interoperate on RPC-over-RDMA Version One transports
[I-D.ietf-nfsv4-rfc5666bis]. Via standards action, the Upper Layer [I-D.ietf-nfsv4-rfc5666bis]. Via standards action, the Upper Layer
Binding specified in this document can be extended to cover versions Binding specified in this document can be extended to cover versions
of the NFS version 4 protocol specified after NFS version 4 minor of the NFS version 4 protocol specified after NFS version 4 minor
version 2, or separately published extensions to an existing NFS version 2, or separately published extensions to an existing NFS
version 4 minor version, as described in [I-D.ietf-nfsv4-versioning]. version 4 minor version, as described in [I-D.ietf-nfsv4-versioning].
7. Security Considerations 7. Security Considerations
RPC-over-RDMA Version One supports all RPC security models, including RPC-over-RDMA Version One supports all RPC security models, including
RPCSEC_GSS security and transport-level security [RFC2203]. The RPCSEC_GSS security and transport-level security [RFC7861]. The
choice of what Direct Data Placement mechanism to convey RPC argument choice of what Direct Data Placement mechanism to convey RPC argument
and results does not affect this, since it changes only the method of and results does not affect this, since it changes only the method of
data transfer. Specifically, the requirements of data transfer. Specifically, the requirements of
[I-D.ietf-nfsv4-rfc5666bis] ensure that this choice does not [I-D.ietf-nfsv4-rfc5666bis] ensure that this choice does not
introduce new vulnerabilities. introduce new vulnerabilities.
Because this document defines only the binding of the NFS protocols Because this document defines only the binding of the NFS protocols
atop [I-D.ietf-nfsv4-rfc5666bis], all relevant security atop [I-D.ietf-nfsv4-rfc5666bis], all relevant security
considerations are therefore to be described at that layer. considerations are therefore to be described at that layer.
skipping to change at page 14, line 48 skipping to change at page 15, line 43
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, DOI 10.17487/RFC1833, August 1995, RFC 1833, DOI 10.17487/RFC1833, August 1995,
<http://www.rfc-editor.org/info/rfc1833>. <http://www.rfc-editor.org/info/rfc1833>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>. <http://www.rfc-editor.org/info/rfc5661>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>. March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <http://www.rfc-editor.org/info/rfc7861>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
November 2016, <http://www.rfc-editor.org/info/rfc7862>. November 2016, <http://www.rfc-editor.org/info/rfc7862>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-nfsv4-versioning] [I-D.ietf-nfsv4-versioning]
Noveck, D., "Rules for NFSv4 Extensions and Minor Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", draft-ietf-nfsv4-versioning-09 (work in Versions", draft-ietf-nfsv4-versioning-09 (work in
progress), December 2016. progress), December 2016.
 End of changes. 17 change blocks. 
44 lines changed or deleted 82 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/