Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8267 Oracle
Obsoletes: 5667 October 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8267 Oracle
Obsoletes: 5667 October 2017
Category: Standards Track
ISSN: 2070-1721
Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1
通过RDMA版本1将网络文件系统（NFS）上层绑定到RPC
Abstract
摘要
This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.
本文档指定了网络文件系统（NFS）协议版本到RPC over RDMA版本1的上层绑定，从而支持使用直接数据放置。本文件淘汰RFC 5667。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8267.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8267.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Reply Size Estimation . . . . . . . . . . . . . . . . . . . . 5
3.1. Short Reply Chunk Retry . . . . . . . . . . . . . . . . . 5
4. Upper-Layer Binding for NFS Versions 2 and 3 . . . . . . . . 6
4.1. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7
4.2. RPC Binding Considerations . . . . . . . . . . . . . . . 7
5. Upper-Layer Bindings for NFS Versions 2 and 3 Auxiliary
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. MOUNT, NLM, and NSM Protocols . . . . . . . . . . . . . . 8
5.2. NFSACL Protocol . . . . . . . . . . . . . . . . . . . . . 8
6. Upper-Layer Binding for NFS Version 4 . . . . . . . . . . . . 8
6.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 8
6.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 9
6.3. RPC Binding Considerations . . . . . . . . . . . . . . . 10
6.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 10
6.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 13
6.6. Session-Related Considerations . . . . . . . . . . . . . 14
6.7. Transport Considerations . . . . . . . . . . . . . . . . 15
7. Extending NFS Upper-Layer Bindings . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Reply Size Estimation . . . . . . . . . . . . . . . . . . . . 5
3.1. Short Reply Chunk Retry . . . . . . . . . . . . . . . . . 5
4. Upper-Layer Binding for NFS Versions 2 and 3 . . . . . . . . 6
4.1. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7
4.2. RPC Binding Considerations . . . . . . . . . . . . . . . 7
5. Upper-Layer Bindings for NFS Versions 2 and 3 Auxiliary
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. MOUNT, NLM, and NSM Protocols . . . . . . . . . . . . . . 8
5.2. NFSACL Protocol . . . . . . . . . . . . . . . . . . . . . 8
6. Upper-Layer Binding for NFS Version 4 . . . . . . . . . . . . 8
6.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 8
6.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 9
6.3. RPC Binding Considerations . . . . . . . . . . . . . . . 10
6.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 10
6.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 13
6.6. Session-Related Considerations . . . . . . . . . . . . . 14
6.7. Transport Considerations . . . . . . . . . . . . . . . . 15
7. Extending NFS Upper-Layer Bindings . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
The RPC-over-RDMA version 1 transport may employ Direct Data Placement (DDP) to convey data payloads associated with RPC transactions [RFC8166]. To enable successful interoperation, RPC client and server implementations using RPC-over-RDMA version 1 must agree which External Data Representation (XDR) data items and RPC procedures are eligible to use DDP.
RPC over RDMA版本1传输可采用直接数据放置（DDP）来传输与RPC事务相关的数据有效载荷[RFC8166]。为了实现成功的互操作，使用RPC over RDMA版本1的RPC客户端和服务器实现必须同意哪些外部数据表示（XDR）数据项和RPC过程有资格使用DDP。
An Upper-Layer Binding specifies this agreement for one or more versions of one RPC program. Other operational details, such as RPC binding assignments, pairing Write chunks with result data items, and reply size estimation, are also specified by this Binding.
上层绑定为一个RPC程序的一个或多个版本指定此协议。此绑定还指定了其他操作细节，例如RPC绑定分配、将写块与结果数据项配对以及回复大小估计。
This document contains material required of Upper-Layer Bindings, as specified in [RFC8166], for the following NFS protocol versions:
本文档包含[RFC8166]中规定的以下NFS协议版本的上层绑定所需的资料：
o NFS version 2 [RFC1094]
o NFS版本2[RFC1094]
o NFS version 3 [RFC1813]
o NFS版本3[RFC1813]
o NFS version 4.0 [RFC7530]
o NFS版本4.0[RFC7530]
o NFS version 4.1 [RFC5661]
o NFS版本4.1[RFC5661]
o NFS version 4.2 [RFC7862]
o NFS版本4.2[RFC7862]
Upper-Layer Bindings are also provided for auxiliary protocols used with NFS versions 2 and 3 (see Section 5).
还为NFS版本2和3使用的辅助协议提供了上层绑定（请参见第5节）。
This document assumes the reader is already familiar with concepts and terminology defined in [RFC8166] and the documents it references.
本文档假设读者已经熟悉[RFC8166]中定义的概念和术语及其引用的文档。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
During the construction of each RPC Call message, a requester is responsible for allocating appropriate resources for receiving the corresponding Reply message. If the requester expects the RPC Reply message will be larger than its inline threshold, it provides Write and/or Reply chunks wherein the responder can place results and the Reply's Payload stream.
在构造每个RPC调用消息期间，请求者负责分配适当的资源以接收相应的应答消息。如果请求者期望RPC回复消息将大于其内联阈值，则它将提供写入和/或回复块，响应者可以在其中放置结果和回复的有效负载流。
A reply resource overrun occurs if the RPC Reply Payload stream does not fit into the provided Reply chunk or if no Reply chunk was provided and the Payload stream does not fit inline. This prevents the responder from returning the Upper-Layer reply to the requester. Therefore, reliable reply size estimation is necessary to ensure successful interoperation.
如果RPC回复有效负载流不适合提供的回复区块，或者如果未提供回复区块且有效负载流不适合内联，则会发生回复资源溢出。这会阻止响应者将上层应答返回给请求者。因此，可靠的回复大小估计对于确保成功的互操作是必要的。
In most cases, the NFS protocol's XDR definition provides enough information to enable an NFS client to predict the maximum size of the expected Reply message. If there are variable-size data items in the result, the maximum size of the RPC Reply message can be estimated as follows:
在大多数情况下，NFS协议的XDR定义提供了足够的信息，使NFS客户端能够预测预期回复消息的最大大小。如果结果中存在大小可变的数据项，则RPC回复消息的最大大小可估计如下：
o The client requests only a specific portion of an object (e.g., using the "count" and "offset" fields in an NFS READ).
o 客户端仅请求对象的特定部分（例如，使用NFS读取中的“计数”和“偏移量”字段）。
o The client limits the number of results (e.g., using the "count" field of an NFS READDIR request).
o 客户端限制结果的数量（例如，使用NFS READDIR请求的“计数”字段）。
o The client has already cached the size of the whole object it is about to request (e.g., via a previous NFS GETATTR request).
o 客户端已经缓存了它将要请求的整个对象的大小（例如，通过以前的NFS GETATTR请求）。
o The client and server have negotiated a maximum size for all calls and responses (e.g., using a CREATE_SESSION operation).
o 客户端和服务器已协商所有呼叫和响应的最大大小（例如，使用CREATE_会话操作）。
In a few cases, either the size of one or more returned data items or the number of returned data items cannot be known in advance of forming an RPC Call.
在少数情况下，在形成RPC调用之前，无法知道一个或多个返回数据项的大小或返回数据项的数量。
If an NFS server finds that the NFS client provided inadequate receive resources to return the whole Reply, it returns an RPC-level error or a transport error, such as ERR_CHUNK.
如果NFS服务器发现NFS客户端提供的接收资源不足，无法返回整个应答，则会返回RPC级别错误或传输错误，如ERR_CHUNK。
In response to these errors, an NFS client can choose to:
为了响应这些错误，NFS客户端可以选择：
o terminate the RPC transaction immediately with an error, or
o 出现错误时立即终止RPC事务，或
o allocate a larger Reply chunk and send the same request as a new RPC transaction (a new Transaction ID (XID) should be assigned to the retransmitted request to avoid matching a cached RPC Reply that caches the original error). The NFS client should avoid retrying the request indefinitely because a responder may return ERR_CHUNK for a variety of reasons.
o 分配一个较大的应答块，并发送与新RPC事务相同的请求（应为重新传输的请求分配一个新事务ID（XID），以避免与缓存原始错误的缓存RPC应答匹配）。NFS客户端应该避免无限期地重试请求，因为响应程序可能出于各种原因返回ERR_块。
Subsequent sections of this document discuss exactly which operations might have ultimate difficulty with reply size estimation. These operations are eligible for "short Reply chunk retry". Unless explicitly mentioned as applicable, short Reply chunk retry should not be used since accurate reply size estimation is problematic in only a few cases. In all other cases, reply size underestimation is considered a correctable implementation bug.
本文档的后续部分将详细讨论哪些操作可能在回复大小估计方面存在最终困难。这些操作符合“短回复区块重试”的条件。除非明确指出适用，否则不应使用短回复区块重试，因为只有在少数情况下，精确的回复大小估计是有问题的。在所有其他情况下，应答大小低估被认为是一个可纠正的实现错误。
NFS server implementations can avoid connection loss by first confirming that target RDMA segments are large enough to receive results before initiating explicit RDMA operations.
NFS服务器实现可以通过在启动显式RDMA操作之前首先确认目标RDMA段足够大以接收结果来避免连接丢失。
The Upper-Layer Binding specification in this section applies to NFS versions 2 [RFC1094] and 3 [RFC1813]. For brevity, in this document a "Legacy NFS client" refers to an NFS client using versions 2 or 3 of the NFS RPC program (100003) to communicate with an NFS server. Likewise, a "Legacy NFS server" is an NFS server communicating with clients using NFS versions 2 or 3.
本节中的上层绑定规范适用于NFS版本2[RFC1094]和3[RFC1813]。为简洁起见，在本文档中，“遗留NFS客户端”是指使用NFS RPC程序（100003）版本2或3与NFS服务器通信的NFS客户端。同样，“遗留NFS服务器”是使用NFS版本2或3与客户端通信的NFS服务器。
The following XDR data items in NFS versions 2 and 3 are DDP-eligible:
NFS版本2和3中的以下XDR数据项符合DDP条件：
o the opaque file data argument in the NFS WRITE procedure
o NFS写入过程中的不透明文件数据参数
o the pathname argument in the NFS SYMLINK procedure
o NFS符号链接过程中的路径名参数
o the opaque file data result in the NFS READ procedure
o 不透明文件数据导致NFS读取过程
o the pathname result in the NFS READLINK procedure
o 路径名将导致NFS READLINK过程
All other argument or result data items in NFS versions 2 and 3 are not DDP-eligible.
NFS版本2和3中的所有其他参数或结果数据项都不符合DDP条件。
A transport error does not give an indication of whether the server has processed the arguments of the RPC Call or whether the server has accessed or modified client memory associated with that RPC.
传输错误不会指示服务器是否已处理RPC调用的参数，或者服务器是否已访问或修改与该RPC关联的客户端内存。
A Legacy NFS client determines the maximum reply size for each operation using the criteria outlined in Section 3. There are no operations in NFS versions 2 or 3 that benefit from short Reply chunk retry.
传统NFS客户端使用第3节中概述的标准确定每个操作的最大回复大小。NFS版本2或3中没有任何操作可以从短回复区块重试中获益。
Legacy NFS servers traditionally listen for clients on UDP and TCP port 2049. Additionally, they register these ports with a local portmapper [RFC1833] service.
传统NFS服务器在UDP和TCP端口2049上侦听客户端。此外，它们向本地端口映射程序[RFC1833]服务注册这些端口。
A Legacy NFS server supporting RPC-over-RDMA version 1 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-over-RDMA service (see Section 9). The chosen port MAY be registered with the RPC portmapper under the netids assigned in [RFC8166].
在这样的网络上支持RPC over RDMA version 1并向RPC portmapper注册的旧版NFS服务器可以选择任意端口，或者可以为其RPC over RDMA服务使用其他已知端口号（请参阅第9节）。所选端口可以在[RFC8166]中指定的NetID下向RPC端口映射器注册。
NFS versions 2 and 3 are typically deployed with several other protocols, sometimes referred to as "NFS auxiliary protocols". These are distinct RPC programs that define procedures that are not part of the NFS RPC program (100003). The Upper-Layer Bindings in this section apply to:
NFS版本2和3通常与其他几个协议一起部署，有时称为“NFS辅助协议”。这些是不同的RPC程序，用于定义不属于NFS RPC程序（100003）的过程。本节中的上层绑定适用于：
o versions 2 and 3 of the MOUNT RPC program (100005) [RFC1813];
o MOUNT RPC程序（100005）[RFC1813]的版本2和版本3；
o versions 1, 3, and 4 of the NLM (Network Lock Manager) RPC program (100021) [RFC1813];
o NLM（网络锁管理器）RPC程序（100021）[RFC1813]的版本1、3和4；
o version 1 of the NSM (Network Status Monitor) RPC program (100024), which is described in Chapter 11 of [XNFS]; and
o NSM（网络状态监视器）RPC程序（100024）的第1版，如[XNFS]第11章所述；和
o version 1 of the NFSACL RPC program (100227), which does not have a public definition. NFSACL is treated in this document as a de facto standard, as there are several interoperating implementations.
o NFSACL RPC程序（100227）的第1版，没有公共定义。NFSACL在本文档中被视为事实上的标准，因为有几个互操作实现。
Historically, NFS/RDMA implementations have chosen to convey the MOUNT, NLM, and NSM protocols via TCP. To enable interoperation of these protocols when NFS/RDMA is in use, a Legacy NFS server MUST provide support for these protocols via TCP.
过去，NFS/RDMA实现选择通过TCP传输装载、NLM和NSM协议。要在使用NFS/RDMA时启用这些协议的互操作，旧版NFS服务器必须通过TCP提供对这些协议的支持。
Legacy clients and servers that support the NFSACL RPC program typically convey NFSACL procedures on the same connection as the NFS RPC program (100003). This obviates the need for separate rpcbind queries to discover server support for this RPC program.
支持NFSACL RPC程序的传统客户端和服务器通常在与NFS RPC程序相同的连接上传输NFSACL过程（100003）。这样就不需要单独的rpcbind查询来发现此RPC程序的服务器支持。
Access Control Lists (ACLs) are typically small, but even large ACLs must be encoded and decoded to some degree. Thus, no data item in this upper-layer protocol is DDP-eligible.
访问控制列表（ACL）通常很小，但即使是较大的ACL也必须在一定程度上进行编码和解码。因此，此上层协议中没有符合DDP条件的数据项。
For NFSACL procedures whose Replies do not include an ACL object, the size of a Reply is determined directly from the NFSACL RPC program's XDR definition.
对于其应答不包括ACL对象的NFSACL过程，应答的大小直接由NFSACL RPC程序的XDR定义确定。
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 Legacy client to ascertain the largest ACL a Legacy server can return. Legacy client implementations should choose a maximum size for ACLs based on their own internal limits.
NFS版本3 ACL没有协议指定的大小限制，在NFSACL或NFS RPC程序中，旧客户端都没有确定旧服务器可以返回的最大ACL的机制。旧客户端实现应根据自身的内部限制选择ACL的最大大小。
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 operation encounters a transport error.
由于NFSACL客户端无法预先知道返回的ACL有多大，因此当NFSACL GETACL操作遇到传输错误时，它可以使用短回复块重试。
The Upper-Layer Binding specification in this section applies to versions of the NFS RPC program defined in NFS versions 4.0 [RFC7530], 4.1 [RFC5661], and 4.2 [RFC7862].
本节中的上层绑定规范适用于NFS版本4.0[RFC7530]、4.1[RFC5661]和4.2[RFC7862]中定义的NFS RPC程序版本。
Only the following XDR data items in the COMPOUND procedure of all NFS version 4 minor versions are DDP-eligible:
在所有NFS版本4次要版本的复合过程中，只有以下XDR数据项符合DDP条件：
o The opaque data field in the WRITE4args structure
o WRITE4args结构中的不透明数据字段
o The linkdata field of the NF4LNK arm in the createtype4 union
o createtype4联合中NF4LNK arm的linkdata字段
o The opaque data field in the READ4resok structure
o READ4resok结构中的不透明数据字段
o The linkdata field in the READLINK4resok structure
o READLINK4resok结构中的linkdata字段
Within NFS version 4, there are certain variable-length result data items whose maximum size cannot be estimated by clients reliably because there is no protocol-specified size limit on these arrays. These include:
在NFS版本4中，某些可变长度结果数据项的最大大小无法由客户端可靠地估计，因为这些阵列上没有协议指定的大小限制。这些措施包括：
o the attrlist4 field;
o 属性列表4字段；
o fields containing ACLs such as fattr4_acl, fattr4_dacl, and fattr4_sacl;
o 包含acl的字段，如fattr4_acl、fattr4_dacl和fattr4_sacl；
o fields in the fs_locations4 and fs_locations_info4 data structures; and
o fs_locations4和fs_locations_info4数据结构中的字段；和
o fields opaque to the NFS version 4 protocol that pertain to pNFS (parallel NFS) layout metadata, such as loc_body, loh_body, da_addr_body, lou_body, lrf_body, fattr_layout_types, and fs_layout_types.
o 与pNFS（并行NFS）布局元数据相关的NFS版本4协议不透明的字段，例如loc_body、loh_body、da_addr_body、lou_body、lrf_body、fattr_布局_类型和fs_布局_类型。
The NFS version 4.0 protocol itself does not impose any bound on the size of NFS calls or responses.
NFS版本4.0协议本身不会对NFS调用或响应的大小施加任何限制。
Some of the data items enumerated in Section 6.2 (in particular, the items related to ACLs and fs_locations) make it difficult to predict the maximum size of NFS version 4.0 Replies that interrogate variable-length fattr4 attributes. Client implementations might rely on their own internal architectural limits to constrain the reply size, but such limits are not always guaranteed to be reliable.
第6.2节中列举的一些数据项（特别是与ACL和fs_位置相关的项）使得很难预测查询可变长度fattr4属性的NFS版本4.0回复的最大大小。客户端实现可能依赖于它们自己的内部体系结构限制来限制回复大小，但这些限制并不总是可靠的。
When an especially large fattr4 result is expected, a Reply chunk might be required. An NFS version 4.0 client can use short Reply chunk retry when an NFS COMPOUND containing a GETATTR operation encounters a transport error.
当期望得到特别大的fattr4结果时，可能需要一个应答块。当包含GETATTR操作的NFS化合物遇到传输错误时，NFS版本4.0客户端可以使用短回复区块重试。
The use of NFS COMPOUND operations raises the possibility of requests that combine a non-idempotent operation (e.g., RENAME) with a GETATTR operation that requests one or more variable-length results. This combination should be avoided by ensuring that any GETATTR operation that requests a result of unpredictable length is sent in an NFS COMPOUND by itself.
NFS复合操作的使用增加了将非幂等操作（例如重命名）与请求一个或多个可变长度结果的GETATTR操作相结合的请求的可能性。通过确保请求长度不可预测的结果的任何GETATTR操作都是在NFS组合中自行发送的，可以避免这种组合。
6.2.2. Reply Size Estimation for Minor Version 1 and Newer Minor Versions
6.2.2. 次要版本1和更新次要版本的回复大小估计
In NFS version 4.1 and newer minor versions, the csa_fore_chan_attrs argument of the CREATE_SESSION operation contains a ca_maxresponsesize field. The value in this field can be taken as the absolute maximum size of replies generated by an NFS version 4.1 server.
在NFS版本4.1和更新的次要版本中，CREATE_SESSION操作的csa_fore_chan_attrs参数包含一个ca_maxresponsesize字段。此字段中的值可以作为NFS 4.1版服务器生成的回复的绝对最大大小。
This value can be used in cases where it is not possible to precisely estimate a reply size upper bound. In practice, objects such as ACLs, named attributes, layout bodies, and security labels are much smaller than this maximum.
此值可用于无法精确估计回复大小上限的情况。实际上，对象（如ACL、命名属性、布局体和安全标签）远小于此最大值。
NFS version 4 servers are required to listen on TCP port 2049, and they are not required to register with an rpcbind service [RFC7530].
NFS版本4服务器需要侦听TCP端口2049，并且不需要向rpcbind服务注册[RFC7530]。
Therefore, an NFS version 4 server supporting RPC-over-RDMA version 1 MUST use the alternative well-known port number for its RPC-over-RDMA service (see Section 9). Clients SHOULD connect to this well-known port without consulting the RPC portmapper (as for NFS version 4 on TCP transports).
因此，支持RPC over RDMA version 1的NFS version 4服务器必须为其RPC over RDMA服务使用备用的已知端口号（请参阅第9节）。客户端应连接到此众所周知的端口，而无需咨询RPC端口映射器（对于TCP传输上的NFS版本4）。
An NFS version 4 COMPOUND procedure can contain more than one operation that carries a DDP-eligible data item. An NFS version 4 client provides XDR Position values in each Read chunk to disambiguate which chunk is associated with which argument data item. However, NFS version 4 server and client implementations must agree in advance on how to pair Write chunks with returned result data items.
NFS版本4复合过程可以包含多个携带DDP合格数据项的操作。NFS版本4客户端在每个读取块中提供XDR位置值，以消除哪个块与哪个参数数据项关联的歧义。但是，NFS版本4服务器和客户端实现必须事先就如何将写块与返回的结果数据项配对达成一致。
In the following list, a "READ operation" refers to any NFS version 4 operation that has a DDP-eligible result data item. The mechanism specified in Section 4.3.2 of [RFC8166] is applied to this class of operations:
在下面的列表中，“读取操作”是指任何具有DDP合格结果数据项的NFS版本4操作。[RFC8166]第4.3.2节中规定的机制适用于此类操作：
o If an NFS version 4 client wishes all DDP-eligible items in an NFS Reply to be conveyed inline, it leaves the Write list empty.
o 如果NFS version 4客户端希望以内联方式传递NFS回复中所有符合DDP条件的项，则会将写入列表保留为空。
o The first chunk in the Write list MUST be used by the first READ operation in an NFS version 4 COMPOUND procedure. The next Write chunk is used by the next READ operation, and so on.
o NFS版本4复合过程中的第一个读取操作必须使用写入列表中的第一个块。下一个写块由下一个读操作使用，依此类推。
o If an NFS version 4 client has provided a matching non-empty Write chunk, then the corresponding READ operation MUST return its DDP-eligible data item using that chunk.
o 如果NFS版本4客户端提供了匹配的非空写入区块，则相应的读取操作必须使用该区块返回其符合DDP条件的数据项。
o If an NFS version 4 client has provided an empty matching Write chunk, then the corresponding READ operation MUST return all of its result data items inline.
o 如果NFS版本4客户端提供了一个空的匹配写块，则相应的读操作必须内联返回其所有结果数据项。
o If a READ operation returns a union arm that does not contain a DDP-eligible result, and the NFS version 4 client has provided a matching non-empty Write chunk, an NFS version 4 server MUST return an empty Write chunk in that Write list position.
o 如果读取操作返回的联合arm不包含符合DDP条件的结果，并且NFS版本4客户端提供了匹配的非空写入区块，则NFS版本4服务器必须在该写入列表位置返回空写入区块。
o If there are more READ operations than Write chunks, then remaining NFS READ operations in an NFS version 4 COMPOUND that have no matching Write chunk MUST return their results inline.
o 如果读操作多于写块，那么NFS版本4复合中没有匹配写块的剩余NFS读操作必须内联返回结果。
The RPC-over-RDMA version 1 protocol does not place any limit on the number of chunks or segments that may appear in Read or Write lists. However, for various reasons, NFS version 4 server implementations often have practical limits on the number of chunks or segments they are prepared to process in a single RPC transaction conveyed via RPC-over-RDMA version 1.
RPC over RDMA version 1协议对读或写列表中可能出现的块或段的数量没有任何限制。然而，由于各种原因，NFS版本4服务器实现通常对它们准备在通过RPC over RDMA版本1传输的单个RPC事务中处理的块或段的数量有实际限制。
These implementation limits are especially important when Kerberos integrity or privacy is in use [RFC7861]. Generic Security Service (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.
当使用Kerberos完整性或隐私时，这些实现限制尤其重要[RFC7861]。通用安全服务（GSS）服务增加了RPC头中凭证材料的大小，可能需要更频繁地使用长消息。这可能会增加区块列表的复杂性，而不受所传输的NFS版本4化合物的影响。
In the absence of explicit knowledge of the server's limits, NFS version 4 clients SHOULD follow the prescriptions listed below when constructing RPC-over-RDMA version 1 messages. NFS version 4 servers MUST accept and process such requests.
在没有明确了解服务器限制的情况下，NFS版本4客户端在构建RDMA版本1上的RPC消息时应遵循以下规定。NFS版本4服务器必须接受并处理此类请求。
o The Read list can contain either a Position Zero Read chunk, one Read chunk with a non-zero Position, or both.
o 读取列表可以包含一个位置为零的读取块，一个位置为非零的读取块，或者两者都包含。
o The Write list can contain no more than one Write chunk.
o 写入列表只能包含一个写入区块。
o Any chunk can contain up to sixteen RDMA segments.
o 任何区块最多可包含16个RDMA段。
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 chunk overruns at the receiving peer.
希望发送更复杂区块列表的NFS version 4客户端可以提供配置接口，以限制NFS version 4化合物的复杂性，限制分散-聚集操作中的元素数量，并避免接收对等方的其他区块溢出源。
An NFS version 4 server SHOULD return one of the following responses to a client that has sent an RPC transaction via RPC-over-RDMA version 1, which cannot be processed due to chunk list complexity limits on the server:
NFS版本4服务器应向通过RPC over RDMA版本1发送RPC事务的客户端返回以下响应之一，由于服务器上的区块列表复杂性限制，无法处理该响应：
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 传输层在解析RPC调用消息中的传输头时检测到问题。服务器响应RDMA_错误消息，并将err字段设置为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.
o RPC层重新组装调用的XDR流时，在RPC调用消息的XDR解码期间检测到问题。服务器响应RPC应答，其“Reply_stat”字段设置为MSG_ACCEPTED，其“accept_stat”字段设置为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 RPC Reply.
在收到其中一个错误后，NFS版本4客户端不应重新传输失败的请求，因为结果将是相同的错误。它应该立即终止与RPC应答中的XID关联的RPC事务。
The following example shows a Write list with three Write chunks: A, B, and C. The NFS version 4 server consumes the provided Write chunks by writing the results of the designated operations in the COMPOUND request (READ and READLINK) back to each chunk.
下面的示例显示了一个包含三个写块的写列表：a、B和C。NFS版本4服务器通过将复合请求（读取和读取链接）中指定操作的结果写回每个块来使用提供的写块。
Write list:
写作列表：
A --> B --> C
A --> B --> C
NFS version 4 COMPOUND request:
NFS版本4复合请求：
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ
| | |
v v v
A B C
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ
| | |
v v v
A B C
If the NFS version 4 client does not want to have the READLINK result returned via RDMA, it provides an empty Write chunk for buffer B to indicate that the READLINK result must be returned inline.
如果NFS版本4客户端不希望通过RDMA返回READLINK结果，它将为缓冲区B提供一个空写块，以指示必须内联返回READLINK结果。
The NFS version 4 family of protocols support server-initiated callbacks to notify NFS version 4 clients of events such as recalled delegations.
NFS version 4协议系列支持服务器发起的回调，以通知NFS version 4客户端事件，如撤回的委派。
NFS version 4.0 implementations typically employ a separate TCP connection to handle callback operations, even when the forward channel uses an RPC-over-RDMA version 1 transport.
NFS版本4.0实现通常使用单独的TCP连接来处理回调操作，即使转发通道使用RPC over RDMA版本1传输也是如此。
No operation in the NFS version 4.0 callback RPC program conveys a significant data payload. Therefore, no XDR data items in this RPC program are DDP-eligible.
NFS版本4.0回调RPC程序中的任何操作都不会传递重要的数据负载。因此，此RPC程序中没有符合DDP条件的XDR数据项。
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 discussion of reply size prediction for this data item.
CB_召回回复较小且大小固定。CB_GETATTR回复包含一个可变长度的fattr4数据项。有关此数据项的回复大小预测的讨论，请参见第6.2.1节。
An NFS version 4.0 client advertises netids and ad hoc port addresses for contacting its NFS version 4.0 callback service using the SETCLIENTID operation.
NFS 4.0版客户端使用SETCLIENTID操作播发NetID和特殊端口地址，以联系其NFS 4.0版回调服务。
In NFS version 4.1 and newer minor versions, callback operations may appear on the same connection as is used for NFS version 4 forward channel client requests. NFS version 4 clients and servers MUST use the approach described in [RFC8167] when backchannel operations are conveyed on RPC-over-RDMA version 1 transports.
在NFS版本4.1和更新的次要版本中，回调操作可能出现在与NFS版本4转发通道客户端请求相同的连接上。当反向通道操作通过RPC over RDMA version 1传输传输时，NFS version 4客户端和服务器必须使用[RFC8167]中描述的方法。
The csa_back_chan_attrs argument of the CREATE_SESSION operation contains a ca_maxresponsesize field. The value in this field can be taken as the absolute maximum size of backchannel replies generated by a replying NFS version 4 client.
CREATE_SESSION操作的csa_back_chan_attrs参数包含一个ca_maxresponsesize字段。此字段中的值可以作为回复NFS版本4客户端生成的反向通道回复的绝对最大大小。
There are no DDP-eligible data items in callback procedures defined in NFS versions 4.1 or 4.2. However, some callback operations (such as messages that convey device ID information) can be large, in which case, a Long Call or Reply might be required.
NFS版本4.1或4.2中定义的回调过程中没有符合DDP条件的数据项。但是，某些回调操作（如传递设备ID信息的消息）可能很大，在这种情况下，可能需要长时间的调用或应答。
When an NFS version 4.1 client can support Long Calls in its backchannel, it reports a backchannel ca_maxrequestsize that is larger than the connection's inline thresholds. Otherwise, an NFS version 4 server MUST use only Short messages to convey backchannel operations.
当NFS 4.1版客户端可以在其后通道中支持长调用时，它会报告一个大于连接内联阈值的后通道ca_maxrequestsize。否则，NFS版本4服务器必须仅使用短消息来传递反向通道操作。
The presence of an NFS session (defined in [RFC5661]) has no effect on the operation of RPC-over-RDMA version 1. None of the operations introduced to support NFS sessions (e.g., the SEQUENCE operation) contain DDP-eligible data items. There is no need to match the number of session slots with the number of available RPC-over-RDMA credits.
NFS会话（在[RFC5661]中定义）的存在对RPC over RDMA版本1的操作没有影响。为支持NFS会话而引入的任何操作（例如，序列操作）都不包含符合DDP条件的数据项。不需要将会话插槽的数量与RDMA上可用的RPC点数相匹配。
However, there are a few new cases where an RPC transaction can fail. For example, in response to an RPC request, a requester might receive an RDMA_ERROR message with an rdma_err value of ERR_CHUNK. These situations are not different from existing RPC errors, which an NFS session implementation is already prepared to handle for other transports. And as with other transports during such a failure, there might be no SEQUENCE result available to the requester to distinguish whether failure occurred before or after the requested operations were executed on the responder.
然而，有一些新的情况下，RPC事务可能会失败。例如，为了响应RPC请求，请求者可能会收到RDMA_错误消息，其RDMA_err值为err_CHUNK。这些情况与现有RPC错误没有什么不同，NFS会话实现已经准备好为其他传输处理这些错误。与此故障期间的其他传输一样，请求程序可能没有可用的序列结果来区分故障是在响应程序上执行请求的操作之前还是之后发生的。
When a transport error occurs (e.g., RDMA_ERROR), the requester proceeds as usual to match the incoming XID value to a waiting RPC Call. The RPC transaction is terminated, and the result status is reported to the upper-layer protocol. The requester's session implementation then determines the session ID and slot for the failed request and performs slot recovery to make that slot usable again. If this were not done, that slot could be rendered permanently unavailable.
当发生传输错误（例如，RDMA_错误）时，请求者将一如既往地将传入的XID值与等待的RPC调用相匹配。RPC事务终止，结果状态报告给上层协议。然后，请求者的会话实现确定失败请求的会话ID和插槽，并执行插槽恢复以使该插槽再次可用。如果不这样做，该插槽可能会永久不可用。
When an NFS session is not present (for example, when NFS version 4.0 is in use), a transport error does not provide an indication of whether the server has processed the arguments of the RPC Call or whether the server has accessed or modified client memory associated with that RPC.
当NFS会话不存在时（例如，当使用NFS版本4.0时），传输错误不会指示服务器是否已处理RPC调用的参数，或者服务器是否已访问或修改与该RPC关联的客户端内存。
Section 3.1 of [RFC7530] states:
[RFC7530]第3.1节规定：
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP).
如果NFSv4实现支持通过IP网络协议进行操作，则NFS和IP之间受支持的传输层必须是IETF标准化传输协议，该协议指定用于避免网络拥塞；此类传输包括TCP和流控制传输协议（SCTP）。
Section 2.9.1 of [RFC5661] also states:
[RFC5661]第2.9.1节还规定：
Even if NFSv4.1 is used over a non-IP network protocol, it is RECOMMENDED that the transport support congestion control.
即使NFSv4.1通过非IP网络协议使用，建议传输支持拥塞控制。
It is permissible for a connectionless transport to be used under NFSv4.1; however, reliable and in-order delivery of data combined with congestion control by the connectionless transport is REQUIRED. As a consequence, UDP by itself MUST NOT be used as an NFSv4.1 transport.
允许根据NFSv4.1使用无连接运输工具；但是，需要通过无连接传输结合拥塞控制可靠有序地传输数据。因此，UDP本身不能用作NFSv4.1传输。
RPC-over-RDMA version 1 is constructed on a platform of RDMA Reliable Connections [RFC8166] [RFC5041]. RDMA Reliable Connections are reliable, connection-oriented transports that guarantee in-order delivery, thus meeting all above requirements for NFS version 4 transports.
RDMA版本1上的RPC构建在RDMA可靠连接平台[RFC8166][RFC5041]上。RDMA可靠连接是可靠的、面向连接的传输，可以保证按顺序交付，因此满足NFS版本4传输的所有上述要求。
NFS version 4 client implementations often rely on a transport-layer keep-alive mechanism to detect when an NFS version 4 server has become unresponsive. When an NFS server is no longer responsive, client-side keep-alive terminates the connection, which in turn triggers reconnection and RPC retransmission.
NFS版本4客户端实现通常依赖于传输层保持活动机制来检测NFS版本4服务器何时变得无响应。当NFS服务器不再响应时，客户端保持活动将终止连接，从而触发重新连接和RPC重新传输。
Some RDMA transports (such as Reliable Connections on InfiniBand) have no keep-alive mechanism. Without a disconnect or new RPC traffic, such connections can remain alive long after an NFS server has become unresponsive. Once an NFS client has consumed all available RPC-over-RDMA credits on that transport connection, it will forever await a Reply before sending another RPC request.
一些RDMA传输（如InfiniBand上的可靠连接）没有保持活动机制。如果没有断开连接或新的RPC通信，这种连接可以在NFS服务器失去响应后很长时间保持活动状态。一旦NFS客户机在该传输连接上使用了所有可用的RPC over RDMA积分，它将永远等待回复，然后再发送另一个RPC请求。
NFS version 4 clients SHOULD reserve one RPC-over-RDMA credit to use for a periodic server or connection health assessment. This credit can be used to drive an RPC request on an otherwise idle connection, triggering either a quick affirmative server response or immediate connection termination.
NFS版本4客户端应保留一个RPC over RDMA信用，以用于定期服务器或连接健康评估。此积分可用于在其他空闲连接上驱动RPC请求，从而触发快速肯定服务器响应或立即终止连接。
In addition to network partition and request loss scenarios, RPC-over-RDMA transport connections can be terminated when a Transport header is malformed, Reply messages are larger than receive resources, or when too many RPC-over-RDMA messages are sent at once. In such cases:
除了网络分区和请求丢失场景外，当传输头格式错误、回复消息大于接收资源或一次发送的RPC over RDMA消息过多时，也可以终止RPC over RDMA传输连接。在这种情况下：
o If there is a transport error indicated (i.e., RDMA_ERROR) before the disconnect or instead of a disconnect, the requester MUST respond to that error as prescribed by the specification of the RPC transport. Then, the NFS version 4 rules for handling retransmission apply.
o 如果在断开连接之前指示了传输错误（即RDMA_错误），或者不是断开连接，则请求者必须按照RPC传输规范的规定响应该错误。然后，应用NFS版本4处理重传的规则。
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 for handling retransmission apply.
o 如果存在传输断开连接，并且响应者没有为请求提供其他响应，则只有NFS版本4处理重传的规则适用。
RPC programs such as NFS are required to have an Upper-Layer Binding specification to interoperate on RPC-over-RDMA version 1 transports [RFC8166]. Via IETF standards action, the Upper-Layer Binding specified in this document can be extended to cover (a) versions of the NFS version 4 protocol specified after NFS version 4 minor version 2 or (b) separately published extensions to an existing NFS version 4 minor version, as described in [RFC8178].
诸如NFS之类的RPC程序需要有上层绑定规范，才能在RPC over RDMA版本1传输上进行互操作[RFC8166]。通过IETF标准行动，本文档中指定的上层绑定可以扩展到（a）NFS版本4次要版本2之后指定的NFS版本4协议的版本，或（b）现有NFS版本4次要版本的单独发布扩展，如[RFC8178]所述。
RPC-over-RDMA version 1 supports all RPC security models, including RPCSEC_GSS security and transport-level security [RFC7861]. The choice of what Direct Data Placement mechanism to convey RPC argument and results does not affect this, since it changes only the method of data transfer. 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.
RPC over RDMA版本1支持所有RPC安全模型，包括RPCSEC_GSS安全和传输级安全[RFC7861]。选择何种直接数据放置机制来传递RPC参数和结果并不影响这一点，因为它只会更改数据传输的方法。由于本文档仅定义了[RFC8166]上NFS协议的绑定，因此所有相关的安全注意事项都将在该层描述。
The use of Direct Data Placement in NFS introduces a need for an additional port number assignment for networks that share traditional UDP and TCP port spaces with RDMA services. The iWARP protocol is such an example [RFC5041] [RFC5040].
在NFS中使用直接数据放置，需要为与RDMA服务共享传统UDP和TCP端口空间的网络分配额外的端口号。iWARP协议就是这样一个例子[RFC5041][RFC5040]。
For this purpose, a set of transport protocol port number assignments is specified by this document. IANA has assigned the following ports for NFS/RDMA in the IANA port registry, according to the guidelines described in [RFC6335].
为此，本文件规定了一组传输协议端口号分配。IANA已根据[RFC6335]中描述的指导原则，在IANA端口注册表中为NFS/RDMA分配了以下端口。
nfsrdma 20049 tcp Network File System (NFS) over RDMA nfsrdma 20049 udp Network File System (NFS) over RDMA nfsrdma 20049 sctp Network File System (NFS) over RDMA
通过RDMA的nfsrdma 20049 tcp网络文件系统（NFS）通过RDMA的nfsrdma 20049 udp网络文件系统（NFS）通过RDMA的nfsrdma 20049 sctp网络文件系统（NFS）
This document is listed as the reference for the nfsrdma port assignments.
本文档作为nfsrdma端口分配的参考文件列出。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, DOI 10.17487/RFC1833, August 1995, <https://www.rfc-editor.org/info/rfc1833>.
[RFC1833]Srinivasan，R.，“ONC RPC版本2的绑定协议”，RFC 1833，DOI 10.17487/RFC1833，1995年8月<https://www.rfc-editor.org/info/rfc1833>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <https://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<https://www.rfc-editor.org/info/rfc5661>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<https://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, <https://www.rfc-editor.org/info/rfc7861>.
[RFC7861]Adamson，A.和N.Williams，“远程过程调用（RPC）安全版本3”，RFC 7861，DOI 10.17487/RFC7861，2016年11月<https://www.rfc-editor.org/info/rfc7861>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<https://www.rfc-editor.org/info/rfc7862>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166]Lever，C.，Ed.，Simpson，W.，和T.Talpey，“远程过程调用版本1的远程直接内存访问传输”，RFC 8166，DOI 10.17487/RFC8166，2017年6月<https://www.rfc-editor.org/info/rfc8166>.
[RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC-over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167, June 2017, <https://www.rfc-editor.org/info/rfc8167>.
[RFC8167]Lever，C.，“RDMA传输上RPC的双向远程过程调用”，RFC 8167，DOI 10.17487/RFC8167，2017年6月<https://www.rfc-editor.org/info/rfc8167>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, DOI 10.17487/RFC1094, March 1989, <https://www.rfc-editor.org/info/rfc1094>.
[RFC1094]Nowicki，B.，“NFS:网络文件系统协议规范”，RFC 1094，DOI 10.17487/RFC1094，1989年3月<https://www.rfc-editor.org/info/rfc1094>.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <https://www.rfc-editor.org/info/rfc1813>.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，DOI 10.17487/RFC1813，1995年6月<https://www.rfc-editor.org/info/rfc1813>.
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, DOI 10.17487/RFC5040, October 2007, <https://www.rfc-editor.org/info/rfc5040>.
[RFC5040]Recio，R.，Metzler，B.，Culley，P.，Hilland，J.，和D.Garcia，“远程直接内存访问协议规范”，RFC 5040，DOI 10.17487/RFC5040，2007年10月<https://www.rfc-editor.org/info/rfc5040>.
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, DOI 10.17487/RFC5041, October 2007, <https://www.rfc-editor.org/info/rfc5041>.
[RFC5041]Shah，H.，Pinkerton，J.，Recio，R.，和P.Culley，“可靠传输上的直接数据放置”，RFC 5041，DOI 10.17487/RFC5041，2007年10月<https://www.rfc-editor.org/info/rfc5041>.
[RFC5666] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", RFC 5666, DOI 10.17487/RFC5666, January 2010, <https://www.rfc-editor.org/info/rfc5666>.
[RFC5666]Talpey，T.和B.Callaghan，“远程过程调用的远程直接内存访问传输”，RFC 5666，DOI 10.17487/RFC5666，2010年1月<https://www.rfc-editor.org/info/rfc5666>.
[RFC5667] Talpey, T. and B. Callaghan, "Network File System (NFS) Direct Data Placement", RFC 5667, DOI 10.17487/RFC5667, January 2010, <https://www.rfc-editor.org/info/rfc5667>.
[RFC5667]Talpey，T.和B.Callaghan，“网络文件系统（NFS）直接数据放置”，RFC 5667，DOI 10.17487/RFC5667，2010年1月<https://www.rfc-editor.org/info/rfc5667>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, <https://www.rfc-editor.org/info/rfc8178>.
[RFC8178]Noveck，D.，“NFSv4扩展和次要版本的规则”，RFC 8178，DOI 10.17487/RFC8178，2017年7月<https://www.rfc-editor.org/info/rfc8178>.
[XNFS] The Open Group, "Protocols for Interworking: XNFS, Version 3W", Document Number C702, ISBN 1-85912-184-5, February 1998.
[XNFS]开放组，“互通协议：XNFS，版本3W”，文件编号C702，ISBN 1-85912-184-51998年2月。
Corrections and updates made necessary by new language in [RFC8166] have been introduced. For example, references to deprecated features of RPC-over-RDMA version 1 (such as RDMA_MSGP) and the use of the Read list for handling RPC Replies have been removed. The term "mapping" has been replaced with the term "binding" or "Upper-Layer Binding" throughout the document. Material that duplicates what is in [RFC8166] has been deleted.
[RFC8166]中的新语言进行了必要的更正和更新。例如，已删除对RDMA版本1上的RPC的不推荐功能（如RDMA_MSGP）的引用以及使用读取列表处理RPC回复。在整个文档中，术语“映射”已替换为术语“绑定”或“上层绑定”。与[RFC8166]中内容重复的材料已被删除。
Material required by [RFC8166] for Upper-Layer Bindings that was not present in [RFC5667] has been added. A complete discussion of reply size estimation has been introduced for all protocols covered by the Upper-Layer Bindings in this document.
已添加[RFC8166]所需的上层绑定材料，但[RFC5667]中不存在该材料。本文对上层绑定所涵盖的所有协议的回复大小估计进行了全面讨论。
Technical corrections have been made. For example, the mention of 12KB and 36KB inline thresholds has been removed. The reference to a nonexistent NFS version 4 SYMLINK operation has been replaced.
已经进行了技术更正。例如，删除了12KB和36KB内联阈值。已替换对不存在的NFS版本4符号链接操作的引用。
The discussion of NFS version 4 COMPOUND handling has been completed. Some changes were made to the algorithm for matching DDP-eligible results to Write chunks.
关于NFS版本4复合处理的讨论已经完成。对匹配DDP合格结果以写入区块的算法进行了一些更改。
Requirements to ignore extra Read or Write chunks have been removed from the NFS versions 2 and 3 Upper-Layer Binding, as they conflict with [RFC8166].
NFS版本2和3上层绑定中已删除忽略额外读或写块的要求，因为它们与[RFC8166]冲突。
A section discussing NFS version 4 retransmission and connection loss has been added.
增加了讨论NFS版本4重新传输和连接丢失的部分。
The following additional improvements have been made, relative to [RFC5667]:
与[RFC5667]相比，进行了以下额外改进：
o An explicit discussion of NFS versions 4.0 and 4.1 backchannel operation have replaced the previous treatment of callback operations.
o 对NFS版本4.0和4.1 backchannel操作的明确讨论取代了以前对回调操作的处理。
o A section describing considerations when an NFS session is in use has been added.
o 添加了一节，介绍使用NFS会话时的注意事项。
o An Upper-Layer Binding for NFS version 4.2 has been added.
o 添加了NFS版本4.2的上层绑定。
o A section suggesting a mechanism for periodically assessing connection health has been introduced.
o 介绍了一个建议定期评估连接健康状况的机制的部分。
o Ambiguous or erroneous uses of key words from RFC 2119 have been corrected.
o 已纠正RFC 2119中关键词的歧义或错误用法。
o References to obsolete RFCs have been updated.
o 已更新对过时RFC的引用。
o An IANA Considerations section has been added, which specifies the port assignments for NFS/RDMA. This replaces the example assignment that appeared in [RFC5666].
o 添加了一个IANA注意事项部分，指定NFS/RDMA的端口分配。这将替换[RFC5666]中出现的示例赋值。
o Code excerpts have been removed, and figures have been modernized.
o 代码摘录已删除，数字已现代化。
Acknowledgments
致谢
The author gratefully acknowledges the work of Brent Callaghan and Tom Talpey on the original NFS Direct Data Placement specification [RFC5667]. Tom contributed the text of Section 6.4.2.
作者非常感谢Brent Callaghan和Tom Talpey在原始NFS直接数据放置规范[RFC5667]上所做的工作。Tom提供了第6.4.2节的文本。
Dave Noveck provided an excellent review, constructive suggestions, and consistent navigational guidance throughout the process of drafting this document. Dave contributed the text of Sections 6.6 and 7 and insisted on precise discussion of reply size estimation.
在起草本文件的整个过程中，Dave Noveck提供了出色的审查、建设性建议和一致的导航指导。Dave提供了第6.6节和第7节的文本，并坚持对回复大小估计进行精确讨论。
Thanks to Karen Deitke for her sharp observations about idempotency, NFS COMPOUNDs, and NFS sessions.
感谢Karen Deitke对幂等性、NFS化合物和NFS会话的敏锐观察。
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chair and Document Shepherd Spencer Shepler, and NFSV4 Working Group Secretary Thomas Haynes for their support. The author also wishes to thank Bill Baker and Greg Marsden for their support of this work.
特别感谢运输区总监斯宾塞·道金斯、NFSV4工作组主席兼文件保管员斯宾塞·谢普勒和NFSV4工作组秘书托马斯·海恩斯的支持。作者还要感谢比尔·贝克和格雷格·马斯登对这项工作的支持。
Author's Address
作者地址
Charles Lever Oracle Corporation 1015 Granger Avenue Ann Arbor, MI 48104 United States of America
美国密歇根州安阿伯格兰杰大道1015号查尔斯·利弗甲骨文公司，邮编：48104
Phone: +1 248 816 6463
Email: chuck.lever@oracle.com
Phone: +1 248 816 6463
Email: chuck.lever@oracle.com