Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8167 Oracle
Category: Standards Track June 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8167 Oracle
Category: Standards Track June 2017
ISSN: 2070-1721
Bidirectional Remote Procedure Call on RPC-over-RDMA Transports
RPC over RDMA传输上的双向远程过程调用
Abstract
摘要
Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection. This document describes how RPC transport endpoints capable of Remote Direct Memory Access (RDMA) convey RPCs in both directions on a single connection.
当远程过程调用（RPC）传输可以在同一连接上向两个方向发送RPC事务时，网络文件系统（NFS）版本4的次版本比次版本0更新，效果最好。本文档描述了能够远程直接内存访问（RDMA）的RPC传输端点如何在单个连接上双向传输RPC。
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 http://www.rfc-editor.org/info/rfc8167.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8167.
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 (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Understanding RPC Direction . . . . . . . . . . . . . . . . . 3
3. Immediate Uses of Bidirectional RPC-over-RDMA . . . . . . . . 5
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Sending and Receiving Operations in the Reverse Direction . . 8
6. In the Absence of Support for Reverse-Direction Operation . . 11
7. Considerations for ULBs . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Understanding RPC Direction . . . . . . . . . . . . . . . . . 3
3. Immediate Uses of Bidirectional RPC-over-RDMA . . . . . . . . 5
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Sending and Receiving Operations in the Reverse Direction . . 8
6. In the Absence of Support for Reverse-Direction Operation . . 11
7. Considerations for ULBs . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
RPC-over-RDMA transports, introduced in [RFC8166], efficiently convey Remote Procedure Call (RPC) transactions on transport layers capable of Remote Direct Memory Access (RDMA). The purpose of this document is to enable concurrent operation in both directions on a single transport connection using RPC-over-RDMA protocol versions that do not have specific facilities for reverse-direction operation.
[RFC8166]中介绍的RPC over RDMA传输在能够远程直接内存访问（RDMA）的传输层上高效地传输远程过程调用（RPC）事务。本文档的目的是使用RPC over RDMA协议版本在单个传输连接上启用双向并发操作，该协议版本没有用于反向操作的特定设施。
Reverse-direction RPC transactions are necessary for the operation of version 4.1 of the Network File System (NFS), and in particular, of Parallel NFS (pNFS) [RFC5661], though any Upper-Layer Protocol (ULP) implementation may make use of them. An Upper-Layer Binding (ULB) for NFS version 4.x callback operation is additionally required (see Section 7) but is not provided in this document.
反向RPC事务对于网络文件系统（NFS）版本4.1的操作是必要的，尤其是并行NFS（pNFS）[RFC5661]，尽管任何上层协议（ULP）实现都可以使用它们。另外还需要NFS版本4.x的上层绑定（ULB）回调操作（请参阅第7节），但本文档中未提供此操作。
For example, using the approach described herein, RPC transactions can be conveyed in both directions on the same RPC-over-RDMA version 1 connection without changes to the RPC-over-RDMA version 1 protocol. This document does not update the protocol specified in [RFC8166].
例如，使用本文描述的方法，可以在相同的RPC over RDMA版本1连接上在两个方向上传送RPC事务，而不改变RPC over RDMA版本1协议。本文档不更新[RFC8166]中指定的协议。
The remainder of this document assumes familiarity with the terminology and concepts contained in [RFC8166], especially Sections 2 and 3.
本文件的其余部分假设熟悉[RFC8166]中包含的术语和概念，尤其是第2节和第3节。
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]所述进行解释。
The Open Network Computing Remote Procedure Call (ONC RPC) protocol as described in [RFC5531] is architected as a message-passing protocol between one server and one or more clients. ONC RPC transactions are made up of two types of messages.
[RFC5531]中所述的开放网络计算远程过程调用（ONC RPC）协议被设计为一台服务器和一个或多个客户端之间的消息传递协议。ONC RPC事务由两种类型的消息组成。
A CALL message, or "Call", requests work. A Call is designated by the value CALL in the message's msg_type field. An arbitrary unique value is placed in the message's Transaction ID (XID) field. A host that originates a Call is referred to in this document as a "Requester".
呼叫信息或“呼叫”请求工作。调用由消息的msg_type字段中的值调用指定。在消息的事务ID（XID）字段中放置一个任意唯一值。发起呼叫的主机在本文档中称为“请求者”。
A REPLY message, or "Reply", reports the results of work requested by a Call. A Reply is designated by the value REPLY in the message's msg_type field. The value contained in the message's XID field is copied from the Call whose results are being returned. A host that emits a Reply is referred to as a "Responder".
回复消息或“回复”报告呼叫请求的工作结果。回复由消息的msg_type字段中的值Reply指定。消息的XID字段中包含的值是从返回结果的调用中复制的。发出应答的主机称为“应答器”。
Typically, a Call results in a corresponding Reply. A Reply is never sent without a corresponding Call.
通常，一个呼叫会产生相应的应答。如果没有相应的呼叫，则不会发送回复。
RPC-over-RDMA is a connection-oriented RPC transport. In all cases, when a connection-oriented transport is used, ONC RPC client endpoints are responsible for initiating transport connections, while ONC RPC service endpoints passively await incoming connection requests.
RDMA上的RPC是一种面向连接的RPC传输。在所有情况下，当使用面向连接的传输时，ONC RPC客户端端点负责启动传输连接，而ONC RPC服务端点被动地等待传入的连接请求。
RPC direction on connectionless RPC transports is not addressed in this document.
本文档中未说明无连接RPC传输上的RPC方向。
Traditionally, an ONC RPC client acts as a Requester, while an ONC RPC service acts as a Responder. This form of message passing is referred to as "forward-direction" operation.
传统上，ONC RPC客户端充当请求者，而ONC RPC服务充当响应者。这种形式的消息传递称为“正向”操作。
The ONC RPC specification [RFC5531] does not forbid passing messages in the other direction. An ONC RPC service endpoint can act as a Requester, in which case, an ONC RPC client endpoint acts as a Responder. This form of message passing is referred to as "reverse-direction" operation.
ONC RPC规范[RFC5531]并不禁止向另一个方向传递消息。ONC RPC服务端点可以充当请求者，在这种情况下，ONC RPC客户端端点可以充当响应者。这种形式的消息传递称为“反向”操作。
During reverse-direction operation, the ONC RPC client is responsible for establishing transport connections, even though RPC Call messages come from the ONC RPC server.
在反向操作期间，ONC RPC客户端负责建立传输连接，即使RPC调用消息来自ONC RPC服务器。
ONC RPC clients and servers are optimized to perform and scale well while handling traffic in the forward direction and might not be prepared to handle operation in the reverse direction. Not until NFS version 4.1 [RFC5661] has there been a strong need to handle reverse-direction operation.
ONC RPC客户端和服务器经过优化，能够在正向处理流量时良好地执行和扩展，并且可能不准备处理反向操作。直到NFS版本4.1[RFC5661]才强烈需要处理反向操作。
A pair of connected RPC endpoints may choose to use only forward-direction or only reverse-direction operations on a particular transport connection. Or, these endpoints may send Calls in both directions concurrently on the same transport connection.
一对连接的RPC端点可以选择在特定传输连接上仅使用正向或反向操作。或者，这些端点可以在同一传输连接上同时向两个方向发送调用。
"Bidirectional operation" occurs when both transport endpoints act as a Requester and a Responder at the same time.
“双向操作”发生在两个传输端点同时充当请求者和响应者时。
Bidirectionality is an extension of RPC transport connection sharing. Two RPC endpoints wish to exchange independent RPC messages over a shared connection, but in opposite directions. These messages may or may not be related to the same workloads or RPC Programs.
双向性是RPC传输连接共享的扩展。两个RPC端点希望通过共享连接交换独立的RPC消息，但方向相反。这些消息可能与相同的工作负载或RPC程序相关，也可能不相关。
Section 9 of [RFC5531] introduces the ONC RPC transaction identifier, or "XID" for short. The value of an XID is interpreted in the context of the message's msg_type field.
[RFC5531]的第9节介绍了ONC RPC事务标识符，简称“XID”。XID的值在消息的msg_type字段的上下文中进行解释。
o The XID of a Call is arbitrary but is unique among outstanding Calls from that Requester.
o 调用的XID是任意的，但在来自该请求者的未完成调用中是唯一的。
o The XID of a Reply always matches that of the initiating Call.
o 应答的XID始终与发起呼叫的XID匹配。
When receiving a Reply, a Requester matches the XID value in the Reply with a Call it previously sent.
当收到回复时，请求者将回复中的XID值与之前发送的呼叫进行匹配。
During bidirectional operation, forward- and reverse-direction XIDs are typically generated on distinct hosts by possibly different algorithms. There is no coordination between forward- and reverse-direction XID generation.
在双向操作期间，正向和反向XID通常通过可能不同的算法在不同的主机上生成。正向和反向XID生成之间没有协调。
Therefore, a forward-direction Requester MAY use the same XID value at the same time as a reverse-direction Requester on the same transport connection. Though such concurrent requests use the same XID value, they represent distinct ONC RPC transactions.
因此，前向请求者可以在同一传输连接上与反向请求者同时使用相同的XID值。尽管此类并发请求使用相同的XID值，但它们表示不同的ONC RPC事务。
An NFS version 4.0 client employs a traditional ONC RPC client to send NFS requests to an NFS version 4.0 server's traditional ONC RPC service [RFC7530]. NFS version 4.0 requests flow in the forward direction on a connection established by the client. This connection is referred to as a "forechannel" connection.
NFS 4.0版客户端使用传统的ONC RPC客户端向NFS 4.0版服务器的传统ONC RPC服务[RFC7530]发送NFS请求。NFS版本4.0请求在客户端建立的连接上向前流动。此连接称为“前频道”连接。
An NFS version 4.x "delegation" is simply a promise made by a server that it will notify a client before another client or program running on the server is allowed access to a file. With this guarantee, that client can operate as sole accessor of the file. In particular, it can manage the file's data and metadata caches aggressively.
NFS版本4.x“委派”只是服务器做出的承诺，即在允许服务器上运行的另一个客户端或程序访问文件之前，它将通知客户端。有了这一保证，客户机可以作为文件的唯一存取者进行操作。特别是，它可以积极地管理文件的数据和元数据缓存。
To administer file delegations, NFS version 4.0 introduces the use of callback operations, or "callbacks", in Section 10.2 of [RFC7530]. An NFS version 4.0 server sets up a forward-direction ONC RPC client, and an NFS version 4.0 client sets up a forward-direction ONC RPC service. Callbacks flow in the forward direction on a connection established between the server's callback client and the client's callback service. This connection is distinct from connections being used as forechannels and is referred to as a "backchannel connection".
为了管理文件委派，NFS 4.0版在[RFC7530]的第10.2节中引入了回调操作或“回调”。NFS 4.0版服务器设置正向ONC RPC客户端，NFS 4.0版客户端设置正向ONC RPC服务。回调在服务器的回调客户端和客户端的回调服务之间建立的连接上向前流动。此连接与用作前通道的连接不同，称为“后通道连接”。
When an RDMA transport is used as a forechannel, an NFS version 4.0 client typically provides a TCP-based callback service. The client's SETCLIENTID operation advertises the callback service endpoint with a "tcp" or "tcp6" netid. The server then connects to this service using a TCP socket.
当RDMA传输用作预测通道时，NFS 4.0版客户端通常提供基于TCP的回调服务。客户端的SETCLIENTID操作使用“tcp”或“tcp6”netid播发回调服务端点。然后，服务器使用TCP套接字连接到此服务。
NFS version 4.0 implementations can function without a backchannel in place. In this case, the NFS server does not grant file delegations. This might result in a negative performance effect, but correctness is not affected.
NFS版本4.0实现可以在没有反向通道的情况下正常工作。在这种情况下，NFS服务器不授予文件委派。这可能会对性能产生负面影响，但不会影响正确性。
NFS version 4.1 supports file delegation in a similar fashion to NFS version 4.0 and extends the callback mechanism to manage pNFS layouts, as discussed in Section 12 of [RFC5661].
NFS版本4.1以与NFS版本4.0类似的方式支持文件委派，并扩展回调机制以管理pNFS布局，如[RFC5661]第12节所述。
NFS version 4.1 transport connections are initiated by NFS version 4.1 clients. Therefore, NFS version 4.1 servers send callbacks to clients in the reverse direction on connections established by NFS version 4.1 clients.
NFS 4.1版传输连接由NFS 4.1版客户端启动。因此，NFS 4.1版服务器在NFS 4.1版客户端建立的连接上以相反的方向向客户端发送回调。
NFS version 4.1 clients and servers indicate to their peers that a backchannel capability is available on a given transport connection in the arguments and results of the NFS CREATE_SESSION or BIND_CONN_TO_SESSION operations.
NFS版本4.1客户端和服务器在NFS创建会话或绑定连接到会话操作的参数和结果中向其对等方指示，在给定的传输连接上可以使用反向通道功能。
NFS version 4.1 clients may establish distinct transport connections for forechannel and backchannel operation, or they may combine forechannel and backchannel operation on one transport connection using bidirectional operation.
NFS版本4.1客户端可以为前向通道和后向通道操作建立不同的传输连接，也可以使用双向操作在一个传输连接上组合前向通道和后向通道操作。
Without a reverse-direction RPC-over-RDMA capability, an NFS version 4.1 client additionally connects using a transport with reverse-direction capability to use as a backchannel. Opening an independent TCP socket is the only choice for an NFS version 4.1 backchannel connection in this case.
如果没有反向RPC over RDMA功能，NFS 4.1版客户端还可以使用具有反向功能的传输进行连接，以用作反向通道。在这种情况下，打开独立TCP套接字是NFS 4.1版反向通道连接的唯一选择。
Implementations often find it more convenient to use a single combined transport (i.e., a transport that is capable of bidirectional operation). This simplifies connection establishment and recovery during network partitions or when one endpoint restarts. This can also enable better scaling by using fewer transport connections to perform the same work.
实现通常会发现使用单个组合传输（即，能够双向操作的传输）更方便。这简化了网络分区期间或一个端点重新启动时的连接建立和恢复。这还可以通过使用较少的传输连接来执行相同的工作，从而实现更好的扩展。
As with NFS version 4.0, if a backchannel is not in use, an NFS version 4.1 server does not grant delegations. Because NFS version 4.1 relies on callbacks to manage pNFS layout state, pNFS operation is not possible without a backchannel.
与NFS 4.0版一样，如果未使用反向通道，则NFS 4.1版服务器不会授予委派。因为NFS版本4.1依赖回调来管理pNFS布局状态，所以如果没有反向通道，pNFS操作是不可能的。
For an RDMA Send operation to work properly, the receiving peer has to have already posted a Receive buffer in which to accept the incoming message. If a receiver hasn't posted enough buffers to accommodate each incoming Send operation, the receiving RDMA provider is allowed to terminate the RDMA connection.
为了使RDMA发送操作正常工作，接收对等方必须已经发布了接收缓冲区，以便接收传入消息。如果接收方没有发布足够的缓冲区来容纳每个传入的发送操作，则允许接收RDMA提供程序终止RDMA连接。
RPC-over-RDMA transport protocols provide built-in send flow control to prevent overrunning the number of pre-posted Receive buffers on a connection's receive endpoint using a "credit grant" mechanism. The use of credits in RPC-over-RDMA version 1 is described in Section 3.3.1 of [RFC8166].
RPC over RDMA传输协议提供内置的发送流控制，以使用“信用授予”机制防止连接的接收端点上预发布的接收缓冲区数量超限。[RFC8166]的第3.3.1节描述了RPC over RDMA版本1中信用的使用。
RPC-over-RDMA credits work the same way in the reverse direction as they do in the forward direction. However, forward-direction credits and reverse-direction credits on the same connection are accounted separately. Direction-independent credit accounting prevents head-of-line blocking in one direction from impacting operation in the other direction.
RPC-over-RDMA信用在反向工作的方式与在正向工作的方式相同。但是，同一连接上的正向信用和反向信用是分开核算的。方向独立的信用核算可防止一个方向的行首阻塞影响另一个方向的运营。
The forward-direction credit value retains the same meaning whether or not there are reverse-direction resources associated with an RPC-over-RDMA transport connection. This is the number of RPC requests the forward-direction Responder (the ONC RPC server) is prepared to receive concurrently.
无论是否存在与RPC over RDMA传输连接关联的反向资源，正向信用值都保留相同的含义。这是前向响应程序（ONC RPC服务器）准备并发接收的RPC请求数。
The reverse-direction credit value is the number of RPC requests the reverse-direction Responder (the ONC RPC client) is prepared to receive concurrently. The reverse-direction credit value MAY be different than the forward-direction credit value.
反向信用值是反向响应程序（ONC RPC客户端）准备同时接收的RPC请求数。反向信用值可能不同于正向信用值。
During bidirectional operation, each receiver has to decide whether an incoming message contains a credit request (the receiver is acting as a Responder) or a credit grant (the receiver is acting as a requester) and apply the credit value accordingly.
在双向操作期间，每个接收者必须决定传入消息是包含信用请求（接收者充当响应者）还是信用授权（接收者充当请求者），并相应地应用信用值。
When message direction is not fully determined by context (e.g., suggested by the definition of the RPC-over-RDMA version that is in use) or by an accompanying RPC message payload with a call direction field, it is not possible for the receiver to tell with certainty whether the header credit value is a request or grant. In such cases, the receiver MUST ignore the header's credit value.
当消息方向未完全由上下文（例如，由正在使用的RPC over RDMA版本的定义所建议）或由带有呼叫方向字段的伴随RPC消息有效负载所确定时，接收器不可能确定地告诉消息头信用值是请求还是授予。在这种情况下，接收方必须忽略标题的信用值。
Forward- and reverse-direction operation on the same connection share the same Receive buffers. Therefore, the inline threshold values for the forward direction and the reverse direction are the same. The call inline threshold for the reverse direction is the same as the reply inline threshold for the forward direction, and vice versa. For more information, see Section 3.3.2 of [RFC8166].
同一连接上的正向和反向操作共享相同的接收缓冲区。因此，正向和反向的内联阈值相同。反向的呼叫内联阈值与正向的应答内联阈值相同，反之亦然。有关更多信息，请参见[RFC8166]第3.3.2节。
An RPC-over-RDMA transport endpoint posts Receive buffers before it can receive and process incoming RPC-over-RDMA messages. If a sender transmits a message for a receiver that has no posted Receive buffer, the RDMA provider is allowed to drop the RDMA connection.
RPC over RDMA传输终结点在接收和处理传入的RPC over RDMA消息之前发送接收缓冲区。如果发送方为没有发送接收缓冲区的接收方发送消息，则允许RDMA提供程序断开RDMA连接。
Typically, an RPC-over-RDMA Requester posts only as many Receive buffers as there are outstanding RPC Calls. Therefore, a client endpoint without reverse-direction support might, at times, have no available Receive buffers.
通常，RPCoverRDMA请求程序只发布与未完成RPC调用数量相同的接收缓冲区。因此，没有反向支持的客户端端点有时可能没有可用的接收缓冲区。
To receive incoming reverse-direction Calls, an RPC-over-RDMA client endpoint posts enough additional Receive buffers to match its advertised reverse-direction credit value. Each outstanding forward-direction RPC requires an additional Receive buffer above this minimum.
为了接收传入的反向调用，RPCoverRDMA客户端端点会发布足够多的额外接收缓冲区，以匹配其公布的反向信用值。每个未完成的前向RPC都需要一个高于此最小值的额外接收缓冲区。
When an RDMA transport connection is lost, all active Receive buffers are flushed and are no longer available to receive incoming messages. When a fresh transport connection is established, a client endpoint posts a Receive buffer to handle the Reply for each retransmitted forward-direction Call, and it posts enough Receive buffers to handle reverse-direction Calls.
当RDMA传输连接丢失时，将刷新所有活动接收缓冲区，并且不再可用于接收传入消息。当建立新的传输连接时，客户端端点发布一个接收缓冲区来处理每个重新传输的前向呼叫的应答，并发布足够的接收缓冲区来处理反向呼叫。
A forward-direction RPC-over-RDMA service endpoint posts as many Receive buffers as it expects incoming forward-direction Calls. That is, it posts no fewer buffers than the number of credits granted in the rdma_credit field of forward-direction RPC replies.
RDMA上的前向RPC服务端点发布的接收缓冲区数量与其预期传入的前向调用数量相同。也就是说，它发布的缓冲区不少于前向RPC应答的rdma_credit字段中授予的信用数。
To receive incoming reverse-direction replies, an RPC-over-RDMA server endpoint posts enough additional Receive buffers to handle replies for each reverse-direction Call it sends.
为了接收传入的反向应答，RPCoverRDMA服务器端点会发布足够的额外接收缓冲区，以处理其发送的每个反向调用的应答。
When the existing transport connection is lost, all active Receive buffers are flushed and are no longer available to receive incoming messages. When a fresh transport connection is established, a server endpoint posts a Receive buffer to handle the Reply for each retransmitted reverse-direction Call, and it posts enough Receive buffers to handle incoming forward-direction Calls.
当现有传输连接丢失时，将刷新所有活动接收缓冲区，并且不再可用于接收传入消息。当建立新的传输连接时，服务器端点发布一个接收缓冲区来处理每个重新传输的反向呼叫的应答，并发布足够的接收缓冲区来处理传入的正向呼叫。
The operation of RPC-over-RDMA transports in the forward direction is defined in [RFC5531] and [RFC8166]. In this section, a mechanism for reverse-direction operation on RPC-over-RDMA is defined. Reverse-direction operation used in combination with forward-direction operation enables bidirectional communication on a common RPC-over-RDMA transport connection.
[RFC5531]和[RFC8166]中定义了RDMA上RPC传输的正向操作。在本节中，定义了RDMA上RPC的反向操作机制。反向操作与正向操作结合使用，可在公共RPC over RDMA传输连接上实现双向通信。
Certain fields in the RPC-over-RDMA header have a fixed position in all versions of RPC-over-RDMA. The normative specification of these fields is contained in Section 4 of [RFC8166].
RPC over RDMA标头中的某些字段在所有版本的RPC over RDMA中都有固定位置。这些领域的规范性规范包含在[RFC8166]的第4节中。
To form a reverse-direction RPC-over-RDMA Call message, an ONC RPC service endpoint constructs an RPC-over-RDMA header containing a fresh RPC XID in the rdma_xid field (see Section 2.4 for full requirements).
为了形成反向RPC over RDMA调用消息，ONC RPC服务端点构造一个RPC over RDMA报头，该报头在RDMA_XID字段中包含一个新的RPC XID（有关完整要求，请参见第2.4节）。
The rdma_vers field MUST contain the same value in reverse- and forward-direction Call messages on the same connection.
在同一连接上的反向和正向调用消息中，rdma__ver字段必须包含相同的值。
The number of requested reverse-direction credits is placed in the rdma_credit field (see Section 4).
请求的反向信用的数量放在rdma_信用字段中（见第4节）。
Whether presented inline or as a separate chunk, the ONC RPC Call header MUST start with the same XID value that is present in the RPC-over-RDMA header, and the RPC header's msg_type field MUST contain the value CALL.
无论是内联显示还是作为单独的块显示，ONC-RPC-Call头必须以RPC-over-RDMA头中存在的相同XID值开头，并且RPC头的msg_-type字段必须包含值调用。
To form a reverse-direction RPC-over-RDMA Reply message, an ONC RPC client endpoint constructs an RPC-over-RDMA header containing a copy of the matching ONC RPC Call's RPC XID in the rdma_xid field (see Section 2.4 for full requirements).
为了形成反向RPC over RDMA回复消息，ONC RPC客户端端点在RDMA_XID字段中构造一个包含匹配ONC RPC调用的RPC XID副本的RPC over RDMA报头（有关完整要求，请参阅第2.4节）。
The rdma_vers field MUST contain the same value in a reverse-direction Reply message as in the matching Call message.
rdma__ver字段在反向回复消息中必须包含与匹配呼叫消息中相同的值。
The number of granted reverse-direction credits is placed in the rdma_credit field (see Section 4).
授予的反向信用的数量放在rdma_信用字段中（见第4节）。
Whether presented inline or as a separate chunk, the ONC RPC Reply header MUST start with the same XID value that is present in the RPC-over-RDMA header, and the RPC header's msg_type field MUST contain the value REPLY.
无论是内联显示还是作为单独的块显示，ONC-RPC-Reply头必须以RPC-over-RDMA头中存在的相同XID值开头，并且RPC头的msg_-type字段必须包含Reply值。
A "chunk" refers to a portion of a message's Payload stream that is DDP-eligible and that is placed directly in the receiver's memory by the transport. Chunk data may be moved by an explicit RDMA operation, for example. Chunks are defined in Section 3.4.4 and DDP-eligibility is covered in Section 6.1 of [RFC8166].
“区块”是指符合DDP条件的消息有效负载流的一部分，该部分由传输直接放在接收方的内存中。例如，块数据可以通过显式RDMA操作移动。区块在第3.4.4节中定义，DDP资格在[RFC8166]的第6.1节中涵盖。
Chunks MAY be used in the reverse direction. They operate the same way as in the forward direction.
块可以反向使用。它们的操作方式与前进方向相同。
An implementation might support only ULPs that have no DDP-eligible data items. Such ULPs may use only small messages, or they may have a native mechanism for restricting the size of reverse-direction RPC messages, obviating the need to handle Long Messages in the reverse direction.
实现可能只支持没有DDP合格数据项的ULP。此类ULP可能仅使用小消息，或者它们可能具有用于限制反向RPC消息大小的本机机制，从而无需在反向处理长消息。
When there is no ULP requirement for chunks in the reverse direction, implementers can choose not to provide support for chunks in the reverse direction. This avoids the complexity of adding support for performing RDMA Reads and Writes in the reverse direction.
当对反向块没有ULP要求时，实现者可以选择不向反向块提供支持。这避免了添加对反向执行RDMA读写的支持的复杂性。
When chunks are not implemented, RPC messages in the reverse direction are always sent using a Short Message; therefore, they can be no larger than what can be sent inline (that is, without chunks). Sending an inline message larger than the inline threshold can result in loss of connection.
当块没有实现时，反向的RPC消息总是使用短消息发送；因此，它们不能大于内联发送的内容（即，没有块）。发送大于内联阈值的内联消息可能会导致连接丢失。
If a reverse-direction requester provides a non-empty chunk list to a Responder that does not support chunks, the Responder MUST reply with an RDMA_ERROR message with rdma_err field set to ERR_CHUNK.
如果反向请求者向不支持区块的响应者提供非空区块列表，响应者必须回复RDMA_错误消息，并将RDMA_err field设置为err_chunk。
In rare cases, an ONC RPC service cannot complete an RPC transaction and then send a reply. This can be because the transport connection was lost, because the Call or Reply message was dropped, or because the ULP delayed or dropped the ONC RPC request. Typically, the Requester sends the RPC transaction again, reusing the same RPC XID. This is known as an "RPC retransmission".
在极少数情况下，ONC RPC服务无法完成RPC事务，然后发送回复。这可能是因为传输连接丢失、呼叫或应答消息被丢弃，或者ULP延迟或丢弃了ONC RPC请求。通常，请求者再次发送RPC事务，重用相同的RPC XID。这称为“RPC重传”。
In the forward direction, the Requester is the ONC RPC client. The client is always responsible for establishing a transport connection before sending again.
在前进方向上，请求者是ONC-RPC客户机。客户端始终负责在再次发送之前建立传输连接。
With reverse-direction operation, the Requester is the ONC RPC server. Because an ONC RPC server does not establish transport connections with clients, it cannot retransmit if there is no transport connection. It is forced to wait for the ONC RPC client to re-establish a transport connection before it can retransmit ONC RPC transactions in the reverse direction.
使用反向操作时，请求者是ONC RPC服务器。由于ONC RPC服务器不与客户端建立传输连接，因此如果没有传输连接，则无法重新传输。它必须等待ONC RPC客户端重新建立传输连接，然后才能反向重新传输ONC RPC事务。
If the ONC RPC client peer has no work to do, it can be some time before it re-establishes a transport connection. A waiting reverse-direction ONC RPC Call may time out to avoid waiting indefinitely for a connection to be established.
如果ONC-RPC客户机对等方没有工作要做，则可能需要一段时间才能重新建立传输连接。等待反向ONC-RPC调用可能会超时，以避免无限期地等待建立连接。
Therefore, forward-direction Requesters SHOULD maintain a transport connection as long as there is the possibility that the connection peer can send reverse-direction requests. For example, while an NFS version 4.1 client has open delegated files or active pNFS layouts, it maintains one or more transport connections to enable the NFS server to perform callback operations.
因此，只要连接对等方有可能发送反向请求，前向请求方就应该保持传输连接。例如，尽管NFS 4.1版客户端具有打开的委托文件或活动的pNFS布局，但它维护一个或多个传输连接以使NFS服务器能够执行回调操作。
An RPC-over-RDMA transport endpoint might not support reverse-direction operation (and thus it does not support bidirectional operation). There might be no mechanism in the transport implementation to do so. Or in an implementation that can support operation in the reverse direction, the ULP might not yet have configured or enabled the transport to handle reverse-direction traffic.
RPC over RDMA传输终结点可能不支持反向操作（因此不支持双向操作）。传输实现中可能没有这样做的机制。或者，在支持反向操作的实现中，ULP可能尚未配置或启用传输以处理反向流量。
If an endpoint is not prepared to receive an incoming reverse-direction message, loss of the RDMA connection might result. Thus, denial of service could result if a sender continues to send reverse-direction messages after every transport reconnect to an endpoint that is not prepared to receive them.
若端点不准备接收传入的反向消息，则可能会导致RDMA连接丢失。因此，如果发送方在每次传输重新连接到不准备接收反向消息的端点后继续发送反向消息，则可能会导致拒绝服务。
When dealing with the possibility that the remote peer has no transport-level support for reverse-direction operation, the ULP becomes responsible for informing peers when reverse-direction operation is supported. Otherwise, even a simple reverse-direction RPC NULL procedure from a peer could result in a lost connection.
当处理远程对等方不支持反向操作的传输级别的可能性时，ULP负责在支持反向操作时通知对等方。否则，即使来自对等方的简单反向RPC NULL过程也可能导致连接丢失。
Therefore, a ULP MUST NOT perform reverse-direction ONC RPC operations until the peer has indicated it is prepared to handle them. A description of ULP mechanisms used for this indication is outside the scope of this document.
因此，ULP必须在对等方表示准备处理这些操作之前，才能执行反向ONC RPC操作。用于该指示的ULP机制的描述不在本文件范围内。
For example, an NFS version 4.1 server does not send backchannel messages to an NFS version 4.1 client before the NFS version 4.1 client has sent a CREATE_SESSION or a BIND_CONN_TO_SESSION operation. As long as an NFS version 4.1 client has prepared appropriate resources to receive reverse-direction operations before sending one of these NFS operations, denial of service is avoided.
例如，在NFS 4.1版客户端发送创建会话或绑定连接到会话操作之前，NFS 4.1版服务器不会向NFS 4.1版客户端发送反向通道消息。只要NFS 4.1版客户端在发送其中一个NFS操作之前准备了适当的资源来接收反向操作，就可以避免拒绝服务。
A ULP that operates on RPC-over-RDMA transports may have procedures that include DDP-eligible data items. DDP-eligibility is specified in an Upper-Layer Binding (ULB). Direction of operation does not obviate the need for DDP-eligibility statements.
在RPC over RDMA传输上运行的ULP可能具有包括DDP合格数据项的过程。DDP合格性在上层绑定（ULB）中指定。操作指导并不排除DDP资格声明的必要性。
Reverse-direction-only operation requires the client endpoint to establish a fresh connection. The ULB can specify appropriate RPC binding parameters for such connections.
仅反向操作要求客户端端点建立新连接。ULB可以为此类连接指定适当的RPC绑定参数。
Bidirectional operation occurs on an already-established connection. Specification of RPC binding parameters is usually not necessary in this case.
双向操作发生在已建立的连接上。在这种情况下，通常不需要指定RPC绑定参数。
For bidirectional operation, other considerations may apply when distinct RPC Programs share an RPC-over-RDMA transport connection concurrently. Consult Section 6 of [RFC8166] for details about what else may be contained in a ULB.
对于双向操作，当不同的RPC程序同时共享一个RPC over RDMA传输连接时，可能需要考虑其他因素。有关ULB中可能包含的其他内容的详细信息，请参阅[RFC8166]第6节。
RPC security is handled in the RPC layer, which is above the transport layer where RPC-over-RDMA operates.
RPC安全性在RPC层中处理，RPC层位于传输层之上，RPC over RDMA在传输层上运行。
Reverse-direction operations make use of an authentication mechanism and credentials that are independent of forward-direction operation but otherwise operate in the same fashion as outlined in Section 8.2 of [RFC8166].
反向操作使用独立于正向操作的身份验证机制和凭证，但其操作方式与[RFC8166]第8.2节所述相同。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531]Thurlow，R.，“RPC：远程过程调用协议规范版本2”，RFC 5531，DOI 10.17487/RFC5531，2009年5月<http://www.rfc-editor.org/info/rfc5531>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[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, <http://www.rfc-editor.org/info/rfc8166>.
[RFC8166]Lever，C.，Ed.，Simpson，W.，和T.Talpey，“远程过程调用版本1的远程直接内存访问传输”，RFC 8166，DOI 10.17487/RFC8166，2017年6月<http://www.rfc-editor.org/info/rfc8166>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
致谢
Tom Talpey was an indispensable resource, in addition to creating the foundation upon which this work is based. The author's warmest regards go to him for his help and support.
Tom Talpey是一个不可缺少的资源，除了创造的基础上，这项工作的基础。作者向他的帮助和支持致以最热烈的问候。
Dave Noveck provided excellent review, constructive suggestions, and navigational guidance throughout the process of drafting this document.
在起草本文件的整个过程中，Dave Noveck提供了出色的审查、建设性建议和导航指导。
Dai Ngo was a solid partner and collaborator. Together we constructed and tested independent prototypes of the changes described in this document.
Dai Ngo是一个可靠的合作伙伴和合作者。我们共同构建并测试了本文档中描述的变更的独立原型。
The author wishes to thank Bill Baker and Greg Marsden for their unwavering support of this work. In addition, the author gratefully acknowledges the expert contributions of Karen Deitke, Chunli Zhang, Mahesh Siddheshwar, Steve Wise, and Tom Tucker.
作者希望感谢比尔·贝克和格雷格·马斯登对这项工作的坚定支持。此外，作者感谢Karen Deitke、张春丽、Mahesh Siddheshwar、Steve Wise和Tom Tucker的专家贡献。
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chair and Document Shepherd Spencer Shepler, and NFSV4 Working Group Secretary Tom Haynes for their support.
特别感谢运输区总监斯宾塞·道金斯、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