draft-ietf-nfsv4-rfc5667bis-12.txt   draft-ietf-nfsv4-rfc5667bis-13.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 5667 (if approved) August 7, 2017 Obsoletes: 5667 (if approved) August 9, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: February 8, 2018 Expires: February 10, 2018
Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version 1 Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version 1
draft-ietf-nfsv4-rfc5667bis-12 draft-ietf-nfsv4-rfc5667bis-13
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 1, enabling the use (NFS) protocol versions to RPC-over-RDMA version 1, enabling the use
of Direct Data Placement. This document obsoletes RFC 5667. of Direct Data Placement. This document obsoletes RFC 5667.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 February 8, 2018. This Internet-Draft will expire on February 10, 2018.
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 46 skipping to change at page 2, line 46
6.6. Session-Related Considerations . . . . . . . . . . . . . 12 6.6. Session-Related Considerations . . . . . . . . . . . . . 12
6.7. Transport Considerations . . . . . . . . . . . . . . . . 13 6.7. Transport Considerations . . . . . . . . . . . . . . . . 13
7. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 14 7. Extending NFS Upper Layer Bindings . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 17 Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The RPC-over-RDMA version 1 transport may employ direct data The RPC-over-RDMA version 1 transport may employ direct data
placement to convey data payloads associated with RPC transactions placement to convey data payloads associated with RPC transactions
[RFC8166]. To enable successful interoperation, RPC client and [RFC8166]. To enable successful interoperation, RPC client and
server implementations using RPC-over-RDMA version 1 must agree which server implementations using RPC-over-RDMA version 1 must agree which
XDR data items and RPC procedures are eligible to use direct data XDR data items and RPC procedures are eligible to use direct data
placement (DDP). placement (DDP).
An Upper Layer Binding specifies this agreement for one RPC Program. An Upper Layer Binding specifies this agreement for one version or
Other operational details, such as RPC binding assignments, pairing more versions of one RPC program. Other operational details, such as
Write chunks with result data items, and reply size estimation, are RPC binding assignments, pairing Write chunks with result data items,
also specified by this Binding. and reply size estimation, are also specified by this Binding.
This document contains material required of Upper Layer Bindings, as This document contains material required of Upper Layer Bindings, as
specified in [RFC8166]. for the following NFS protocol versions: specified in [RFC8166], for the following NFS protocol versions:
o NFS version 2 [RFC1094] o NFS version 2 [RFC1094]
o NFS version 3 [RFC1813] o NFS version 3 [RFC1813]
o NFS version 4.0 [RFC7530] o NFS version 4.0 [RFC7530]
o NFS version 4.1 [RFC5661] o NFS version 4.1 [RFC5661]
o NFS version 4.2 [RFC7862] o NFS version 4.2 [RFC7862]
skipping to change at page 5, line 15 skipping to change at page 5, line 15
considered a correctable implementation bug. considered a correctable implementation bug.
NFS server implementations can avoid connection loss by first NFS server implementations can avoid connection loss by first
confirming that target RDMA segments are large enough to receive confirming that target RDMA segments are large enough to receive
results before initiating explicit RDMA operations. results before initiating explicit RDMA operations.
4. Upper Layer Binding for NFS Versions 2 and 3 4. Upper Layer Binding for NFS Versions 2 and 3
The Upper Layer Binding specification in this section applies to NFS The Upper Layer Binding specification in this section applies to NFS
version 2 [RFC1094] and NFS version 3 [RFC1813]. For brevity, in version 2 [RFC1094] and NFS version 3 [RFC1813]. For brevity, in
this document a "Legacy NFS client" refers to an NFS client using the this document a "Legacy NFS client" refers to an NFS client using
NFS version 2 or NFS version 3 RPC Programs (100003) to communicate version 2 or version 3 of the NFS RPC program (100003) to communicate
with an NFS server. Likewise, a "Legacy NFS server" is an NFS server with an NFS server. Likewise, a "Legacy NFS server" is an NFS server
communicating with clients using NFS version 2 or NFS version 3. communicating with clients using NFS version 2 or NFS version 3.
The following XDR data items in NFS versions 2 and 3 are DDP- The following XDR data items in NFS versions 2 and 3 are DDP-
eligible: eligible:
o The opaque file data argument in the NFS WRITE procedure o The opaque file data argument in the NFS WRITE procedure
o The pathname argument in the NFS SYMLINK procedure o The pathname argument in the NFS SYMLINK procedure
skipping to change at page 6, line 16 skipping to change at page 6, line 16
network and registering itself with the RPC portmapper MAY choose an network and registering itself with the RPC portmapper MAY choose an
arbitrary port, or MAY use the alternative well-known port number for arbitrary port, or MAY use the alternative well-known port number for
its RPC-over-RDMA service (see Section 9). The chosen port MAY be its RPC-over-RDMA service (see Section 9). The chosen port MAY be
registered with the RPC portmapper under the netids assigned in registered with the RPC portmapper under the netids assigned in
[RFC8166]. [RFC8166].
5. Upper Layer Bindings for NFS Version 2 and 3 Auxiliary Protocols 5. Upper Layer Bindings for NFS Version 2 and 3 Auxiliary Protocols
NFS versions 2 and 3 are typically deployed with several other NFS versions 2 and 3 are typically deployed with several other
protocols, sometimes referred to as "NFS auxiliary protocols." These protocols, sometimes referred to as "NFS auxiliary protocols." These
are distinct RPC Programs that define procedures which are not part are distinct RPC programs that define procedures which are not part
of the NFS version 2 or version 3 RPC Programs. The Upper Layer of the NFS RPC program (100003). The Upper Layer Bindings in this
Bindings in this section apply to: section apply to:
o Versions 2 and 3 of the MOUNT protocol [RFC1813] o Versions 2 and 3 of the MOUNT RPC program (100005) [RFC1813]
o Versions 1, 3, and 4 of the NLM protocol [RFC1813] o Versions 1, 3, and 4 of the NLM RPC program (100021) [RFC1813]
o Version 1 of the NSM protocol, described in Chapter 11 of [XNFS] o Version 1 of the NSM RPC program (100024), described in Chapter 11
of [XNFS]
o Version 1 of the NFSACL protocol, which does not have a public o Version 1 of the NFSACL RPC program (100227), which does not have
definition. NFSACL is treated in this document as a de facto a public definition. NFSACL is treated in this document as a de
standard, as there are several interoperating implementations. facto standard, as there are several interoperating
implementations.
5.1. MOUNT, NLM, and NSM Protocols 5.1. MOUNT, NLM, and NSM Protocols
Historically, NFS/RDMA implementations have chosen to convey the Historically, NFS/RDMA implementations have chosen to convey the
MOUNT, NLM, and NSM protocols via TCP. To enable interoperation of MOUNT, NLM, and NSM protocols via TCP. To enable interoperation of
these protocols when NFS/RDMA is in use, a legacy NFS server MUST these protocols when NFS/RDMA is in use, a legacy NFS server MUST
provide support for these protocols via TCP. provide support for these protocols via TCP.
5.2. NFSACL Protocol 5.2. NFSACL Protocol
Legacy clients and servers that support the NFSACL RPC Program Legacy clients and servers that support the NFSACL RPC program
typically convey NFSACL procedures on the same connection as the NFS typically convey NFSACL procedures on the same connection as the NFS
RPC program (100003). This obviates the need for separate rpcbind RPC program (100003). This obviates the need for separate rpcbind
queries to discover server support for this RPC Program. queries to discover server support for this RPC program.
ACLs are typically small, but even large ACLs must be encoded and ACLs are typically small, but even large ACLs must be encoded and
decoded to some degree. Thus no data item in this Upper Layer decoded to some degree. Thus no data item in this Upper Layer
Protocol is DDP-eligible. Protocol is DDP-eligible.
For procedures whose replies do not include an ACL object, the size For procedures whose replies do not include an ACL object, the size
of a reply is determined directly from the NFSACL RPC Program's XDR of a reply is determined directly from the NFSACL RPC program's XDR
definition. definition.
There is no protocol-specified size limit for NFS version 3 ACLs, and There is no protocol-specified size limit for NFS version 3 ACLs, and
there is no mechanism in either the NFSACL or NFS RPC Programs for a there is no mechanism in either the NFSACL or NFS RPC programs for a
Legacy client to ascertain the largest ACL a Legacy server can Legacy client to ascertain the largest ACL a Legacy server can
return. Legacy client implementations should choose a maximum size return. Legacy client implementations should choose a maximum size
for ACLs based on their own internal limits. for ACLs based on their own internal limits.
Because an NFSACL client cannot know in advance how large a returned Because an NFSACL client cannot know in advance how large a returned
ACL will be, it can use short Reply chunk retry when an NFSACL GETACL ACL will be, it can use short Reply chunk retry when an NFSACL GETACL
operation encounters a transport error. operation encounters a transport error.
6. Upper Layer Binding For NFS Version 4 6. Upper Layer Binding For NFS Version 4
The Upper Layer Binding specification in this section applies to RPC The Upper Layer Binding specification in this section applies to
Programs defined in NFS version 4.0 [RFC7530], NFS version 4.1 versions of the NFS RPC program defined in NFS version 4.0 [RFC7530],
[RFC5661], and NFS version 4.2 [RFC7862]. NFS version 4.1 [RFC5661], and NFS version 4.2 [RFC7862].
6.1. DDP-Eligibility 6.1. DDP-Eligibility
Only the following XDR data items in the COMPOUND procedure of all Only the following XDR data items in the COMPOUND procedure of all
NFS version 4 minor versions are DDP-eligible: NFS version 4 minor versions are DDP-eligible:
o The opaque data field in the WRITE4args structure o The opaque data field in the WRITE4args structure
o The linkdata field of the NF4LNK arm in the createtype4 union o The linkdata field of the NF4LNK arm in the createtype4 union
skipping to change at page 11, line 39 skipping to change at page 11, line 39
The NFS version 4 family of protocols support server-initiated The NFS version 4 family of protocols support server-initiated
callbacks to notify NFS version 4 clients of events such as recalled callbacks to notify NFS version 4 clients of events such as recalled
delegations. delegations.
6.5.1. NFS Version 4.0 Callback 6.5.1. NFS Version 4.0 Callback
NFS version 4.0 implementations typically employ a separate TCP NFS version 4.0 implementations typically employ a separate TCP
connection to handle callback operations, even when the forward connection to handle callback operations, even when the forward
channel uses an RPC-over-RDMA version 1 transport. channel uses an RPC-over-RDMA version 1 transport.
No operation in the NFS version 4.0 callback RPC Program conveys a No operation in the NFS version 4.0 callback RPC program conveys a
significant data payload. Therefore, no XDR data items in this RPC significant data payload. Therefore, no XDR data items in this RPC
Program is DDP-eligible. program is DDP-eligible.
A CB_RECALL reply is small and fixed in size. The CB_GETATTR reply A CB_RECALL reply is small and fixed in size. The CB_GETATTR reply
contains a variable-length fattr4 data item. See Section 6.2.1 for a contains a variable-length fattr4 data item. See Section 6.2.1 for a
discussion of reply size prediction for this data item. discussion of reply size prediction for this data item.
An NFS version 4.0 client advertises netids and ad hoc port addresses An NFS version 4.0 client advertises netids and ad hoc port addresses
for contacting its NFS version 4.0 callback service using the for contacting its NFS version 4.0 callback service using the
SETCLIENTID operation. SETCLIENTID operation.
6.5.2. NFS Version 4.1 Callback 6.5.2. NFS Version 4.1 Callback
skipping to change at page 14, line 36 skipping to change at page 14, line 36
respond to that error as prescribed by the specification of the respond to that error as prescribed by the specification of the
RPC transport. Then the NFS version 4 rules for handling RPC transport. Then the NFS version 4 rules for handling
retransmission apply. retransmission apply.
o If there is a transport disconnect and the responder has provided o If there is a transport disconnect and the responder has provided
no other response for a request, then only the NFS version 4 rules no other response for a request, then only the NFS version 4 rules
for handling retransmission apply. for handling retransmission apply.
7. Extending NFS Upper Layer Bindings 7. Extending NFS Upper Layer Bindings
RPC Programs such as NFS are required to have an Upper Layer Binding RPC programs such as NFS are required to have an Upper Layer Binding
specification to interoperate on RPC-over-RDMA version 1 transports specification to interoperate on RPC-over-RDMA version 1 transports
[RFC8166]. Via standards action, the Upper Layer Binding specified [RFC8166]. Via standards action, the Upper Layer Binding specified
in this document can be extended to cover versions of the NFS version in this document can be extended to cover versions of the NFS version
4 protocol specified after NFS version 4 minor version 2, or 4 protocol specified after NFS version 4 minor version 2, or
separately published extensions to an existing NFS version 4 minor separately published extensions to an existing NFS version 4 minor
version, as described in [RFC8178]. version, as described in [RFC8178].
8. Security Considerations 8. Security Considerations
RPC-over-RDMA version 1 supports all RPC security models, including RPC-over-RDMA version 1 supports all RPC security models, including
RPCSEC_GSS security and transport-level security [RFC7861]. 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 [RFC8166] ensure data transfer. Because this document defines only the binding of the
that this choice does not introduce new vulnerabilities. NFS protocols atop [RFC8166], all relevant security considerations
are therefore to be described at that layer.
Because this document defines only the binding of the NFS protocols
atop [RFC8166], all relevant security considerations are therefore to
be described at that layer.
9. IANA Considerations 9. IANA Considerations
The use of direct data placement in NFS introduces a need for an The use of direct data placement in NFS introduces a need for an
additional port number assignment for networks that share traditional additional port number assignment for networks that share traditional
UDP and TCP port spaces with RDMA services. The iWARP protocol is UDP and TCP port spaces with RDMA services. The iWARP protocol is
such an example [RFC5041] [RFC5040]. such an example [RFC5041] [RFC5040].
For this purpose, a set of transport protocol port number assignments For this purpose, a set of transport protocol port number assignments
is specified by this document. IANA has assigned the following ports is specified by this document. IANA has assigned the following ports
 End of changes. 22 change blocks. 
37 lines changed or deleted 36 lines changed or added

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