[要約] RFC 8167は、RPC-over-RDMAトランスポート上での双方向リモートプロシージャコール（RPC）に関する仕様です。このRFCの目的は、RPC-over-RDMAトランスポートを使用して双方向通信を実現するための手法を提供することです。
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.
マイナーバージョン0より新しいネットワークファイルシステム（NFS）バージョン4のマイナーバージョンは、リモートプロシージャコール（RPC）トランスポートが同じ接続で双方向にRPCトランザクションを送信できる場合に最適に機能します。このドキュメントでは、リモートダイレクトメモリアクセス（RDMA）が可能なRPCトランスポートエンドポイントがRPCを単一の接続で双方向に伝達する方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
ネットワークファイルシステム（NFS）のバージョン4.1、特に並列NFS（pNFS）[RFC5661]の操作には、逆方向RPCトランザクションが必要ですが、上位層プロトコル（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-over-RDMAバージョン1接続でRPCトランザクションを両方向に伝達できます。このドキュメントは、[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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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]で説明されているOpen Network Computing Remote Procedure Call（ONC RPC）プロトコルは、1つのサーバーと1つ以上のクライアント間のメッセージ受け渡しプロトコルとして設計されています。 ONC RPCトランザクションは、2つのタイプのメッセージで構成されます。
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".
CALLメッセージ、つまり「Call」は作業を要求します。呼び出しは、メッセージのmsg_typeフィールドの値CALLによって指定されます。メッセージのトランザクション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".
REPLYメッセージまたは「Reply」は、コールによって要求された作業の結果を報告します。返信は、メッセージのmsg_typeフィールドの値REPLYによって指定されます。メッセージのXIDフィールドに含まれる値は、結果が返されるCallからコピーされます。返信を送信するホストは「レスポンダ」と呼ばれます。
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.
RPC-over-RDMAは、接続指向の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.
逆方向の操作中、RPC CallメッセージがONC 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トランスポート接続共有の拡張です。 2つの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値を使用できます（MAY）。このような同時要求は同じ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リクエストをNFSバージョン4.0サーバーの伝統的なONC RPCサービス[RFC7530]に送信します。 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].
[RFC5661]のセクション12で説明されているように、NFSバージョン4.1はNFSバージョン4.0と同様の方法でファイル委任をサポートし、コールバックメカニズムを拡張してpNFSレイアウトを管理します。
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 CREATE_SESSIONまたはBIND_CONN_TO_SESSION操作の引数と結果で、特定のトランスポート接続でバックチャネル機能が利用可能であることをピアに示します。
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クライアントは、フォアチャネルとバックチャネルの操作で異なるトランスポート接続を確立するか、双方向操作を使用して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クライアントは、逆方向機能を持つトランスポートを使用して接続し、バックチャネルとして使用します。この場合、NFSバージョン4.1のバックチャネル接続では、独立したTCPソケットを開くことが唯一の選択肢です。
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.
多くの場合、実装では、単一の複合トランスポート（つまり、双方向操作が可能なトランスポート）を使用する方が便利です。これにより、ネットワークパーティション中または1つのエンドポイントが再起動したときの接続の確立と回復が簡素化されます。これにより、トランスポート接続の数を減らして同じ作業を実行することで、スケーリングを向上させることもできます。
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トランスポートプロトコルは、組み込みの送信フロー制御を提供し、「クレジット付与」メカニズムを使用して、接続の受信エンドポイントで事前送信された受信バッファの数がオーバーランするのを防ぎます。 RPC-over-RDMAバージョン1でのクレジットの使用については、[RFC8166]のセクション3.3.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メッセージペイロードによって完全に決定されていない場合、受信者は次のことを行うことができません。ヘッダーのクレジット値がリクエストであるか付与であるかを確実に伝えます。そのような場合、受信者はヘッダーのクレジット値を無視しなければなりません（MUST）。
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.
通常、RPC-over-RDMAリクエスターは、未解決の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.
RPC-over-RDMAクライアントエンドポイントは、着信する逆方向の呼び出しを受信するために、アドバタイズされた逆方向のクレジット値と一致するのに十分な追加の受信バッファーをポストします。未処理の順方向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.
順方向RPC-over-RDMAサービスエンドポイントは、着信順方向コールに必要な数の受信バッファーをポストします。つまり、フォワード方向の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.
RPC-over-RDMAサーバーエンドポイントは、着信する逆方向の応答を受信するために、送信する各逆方向の呼び出しに対する応答を処理するのに十分な追加の受信バッファーをポストします。
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.
順方向のRPC-over-RDMAトランスポートの動作は、[RFC5531]および[RFC8166]で定義されています。このセクションでは、RPC-over-RDMAでの逆方向操作のメカニズムを定義します。順方向操作と組み合わせて使用される逆方向操作は、一般的な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サービスエンドポイントは、rdma_xidフィールドに新しいRPC XIDを含むRPC-over-RDMAヘッダーを作成します（完全な要件については、セクション2.4を参照）。
The rdma_vers field MUST contain the same value in reverse- and forward-direction Call messages on the same connection.
rdma_versフィールドには、同じ接続の逆方向および順方向のCallメッセージで同じ値を含める必要があります。
The number of requested reverse-direction credits is placed in the rdma_credit field (see Section 4).
要求された逆方向クレジットの数は、rdma_creditフィールドに配置されます（セクション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フィールドには値CALLが含まれている必要があります。
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_versフィールドは、一致するCallメッセージと同じ値を逆方向返信メッセージに含める必要があります。
The number of granted reverse-direction credits is placed in the rdma_credit field (see Section 4).
付与された逆方向クレジットの数は、rdma_creditフィールドに配置されます（セクション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_errフィールドがERR_CHUNKに設定されたRDMA_ERRORメッセージで応答する必要があります。
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 XIDを再利用して、RPCトランザクションを再度送信します。これは「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トランザクションを再送信する前に、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サーバーがコールバック操作を実行できるように1つ以上のトランスポート接続を維持しています。
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操作を実行してはなりません（MUST NOT）。この表示に使用される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クライアントがCREATE_SESSIONまたはBIND_CONN_TO_SESSION操作を送信する前に、NFSバージョン4.1クライアントにバックチャネルメッセージを送信しません。 NFSバージョン4.1クライアントが、これらのNFS操作の1つを送信する前に、逆方向操作を受信するための適切なリソースを準備している限り、サービス拒否は回避されます。
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適格性は、Upper-Layer Binding（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-over-RDMAが動作するトランスポート層の上にあるRPC層で処理されます。
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：Remote Procedure Call Protocol Specification Version 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。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、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]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、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.
トムタルペイは、この作品の基礎となる基盤を構築することに加えて、不可欠なリソースでした。著者の最も温かい敬意は彼の助けとサポートのために彼に行きます。
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.
著者は、この作業に対する揺るぎないサポートを提供してくれたBill BakerとGreg Marsdenに感謝します。さらに、著者は、Karen Deitke、Chunli Zhang、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.
Transport Area Director Spencer Dawkins、NFSV4 Working Group Chair and Document Shepherd Spencer Shepler、およびNFSV4 Working Group Secretary Tom Haynesのサポートに特に感謝します。
Author's Address
著者のアドレス
Charles Lever Oracle Corporation 1015 Granger Avenue Ann Arbor, MI 48104 United States of America
Charles Lever Oracle Corporation 1015 Granger Avenueアナーバー、ミシガン州48104アメリカ合衆国
Phone: +1 248 816 6463
Email: chuck.lever@oracle.com