[要約] RFC 8797は、RPC-over-RDMAバージョン1のためのRDMA-CMプライベートデータに関する仕様です。このRFCの目的は、RDMA-CMプライベートデータの構造と使用方法を定義し、RPC-over-RDMAプロトコルの効率と信頼性を向上させることです。
Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8797 Oracle
Updates: 8166 June 2020
Category: Standards Track
ISSN: 2070-1721
Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1
リモートダイレクトメモリアクセス-接続マネージャー（RDMA-CM）RPC-over-RDMAバージョン1のプライベートデータ
Abstract
概要
This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166.
このドキュメントでは、リモートダイレクトメモリアクセス-接続の確立の一部としてRPC-over-RDMAバージョン1ピア間で交換される接続マネージャー（RDMA-CM）プライベートデータの形式を指定します。このドキュメントで指定されているプライベートデータペイロードの追加は、RPC-over-RDMAバージョン1プロトコルを変更しないオプションの拡張機能です。このドキュメントはRFC 8166を更新します。
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 https://www.rfc-editor.org/info/rfc8797.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8797で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Advertised Transport Properties
3.1. Inline Threshold Size
3.2. Remote Invalidation
4. Private Data Message Format
4.1. Using the R Field
4.2. Send and Receive Size Values
5. Interoperability Considerations
5.1. Interoperability with RPC-over-RDMA Version 1
Implementations
5.2. Interoperability amongst RDMA Transports
6. Updating the Message Format
7. Security Considerations
8. IANA Considerations
8.1. Guidance for Designated Experts
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Author's Address
The RPC-over-RDMA version 1 transport protocol [RFC8166] enables payload data transfer using Remote Direct Memory Access (RDMA) for upper-layer protocols based on Remote Procedure Calls (RPCs) [RFC5531]. The terms "Remote Direct Memory Access" (RDMA) and "Direct Data Placement" (DDP) are introduced in [RFC5040].
RPC-over-RDMAバージョン1トランスポートプロトコル[RFC8166]は、リモートプロシージャコール（RPC）[RFC5531]に基づく上位層プロトコルのリモートダイレクトメモリアクセス（RDMA）を使用したペイロードデータ転送を可能にします。 「リモートダイレクトメモリアクセス」（RDMA）と「ダイレクトデータ配置」（DDP）という用語は、[RFC5040]で導入されました。
The two most immediate shortcomings of RPC-over-RDMA version 1 are as follows:
RPC-over-RDMAバージョン1の最も差し迫った2つの欠点は次のとおりです。
1. Setting up an RDMA data transfer (via RDMA Read or Write) can be costly. The small default size of messages transmitted using RDMA Send forces the use of RDMA Read or Write operations even for relatively small messages and data payloads.
1. （RDMA読み取りまたは書き込みを介した）RDMAデータ転送のセットアップは、コストがかかる可能性があります。 RDMA送信を使用して送信されるメッセージのデフォルトサイズは小さいため、比較的小さいメッセージやデータペイロードでも、RDMA読み取りまたは書き込み操作を使用する必要があります。
The original specification of RPC-over-RDMA version 1 provided an out-of-band protocol for passing inline threshold values between connected peers [RFC5666]. However, [RFC8166] eliminated support for this protocol, making it unavailable for this purpose.
RPC-over-RDMAバージョン1の元の仕様では、接続されたピア間でインラインしきい値を渡すための帯域外プロトコルが提供されていました[RFC5666]。ただし、[RFC8166]はこのプロトコルのサポートを排除し、この目的には使用できなくなりました。
2. Unlike most other contemporary RDMA-enabled storage protocols, there is no facility in RPC-over-RDMA version 1 that enables the use of remote invalidation [RFC5042].
2. 他の最新のRDMA対応ストレージプロトコルとは異なり、RPC-over-RDMAバージョン1には、リモート無効化[RFC5042]の使用を可能にする機能はありません。
Each RPC-over-RDMA version 1 Transport Header follows the External Data Representation (XDR) definition [RFC4506] specified in [RFC8166]. However, RPC-over-RDMA version 1 has no means of extending this definition in such a way that interoperability with existing implementations is preserved. As a result, an out-of-band mechanism is needed to help relieve these constraints for existing RPC-over-RDMA version 1 implementations.
各RPC-over-RDMAバージョン1トランスポートヘッダーは、[RFC8166]で指定されている外部データ表現（XDR）定義[RFC4506]に従います。ただし、RPC-over-RDMAバージョン1には、既存の実装との相互運用性が維持されるような方法でこの定義を拡張する手段がありません。その結果、既存のRPC-over-RDMAバージョン1実装のこれらの制約を緩和するために、帯域外メカニズムが必要です。
This document specifies a simple, non-XDR-based message format designed to be passed between RPC-over-RDMA version 1 peers at the time each RDMA transport connection is first established. The mechanism assumes that the underlying RDMA transport has a Private Data field that is passed between peers at connection time, such as is present in the Marker PDU Aligned Framing (MPA) protocol (described in Section 7.1 of [RFC5044] and extended in [RFC6581]) or the InfiniBand Connection Manager [IBA].
このドキュメントは、各RDMAトランスポート接続が最初に確立されるときにRPC-over-RDMAバージョン1ピア間で渡されるように設計された、単純な非XDRベースのメッセージ形式を指定します。このメカニズムでは、基になるRDMAトランスポートに、接続時にピア間で渡されるプライベートデータフィールドがあることを前提としています。たとえば、Marker PDU Aligned Framing（MPA）プロトコル（[RFC5044]のセクション7.1で説明されており、[RFC6581 ]）またはInfiniBand Connection Manager [IBA]。
To enable current RPC-over-RDMA version 1 implementations to interoperate with implementations that support the message format described in this document, implementation of the Private Data exchange is OPTIONAL. When Private Data has been successfully exchanged, peers may choose to perform extended RDMA semantics. However, this exchange does not alter the XDR definition specified in [RFC8166].
現在のRPC-over-RDMAバージョン1実装が、このドキュメントで説明されているメッセージ形式をサポートする実装と相互運用できるようにするには、プライベートデータ交換の実装はオプションです。プライベートデータが正常に交換されると、ピアは拡張RDMAセマンティクスの実行を選択できます。しかしながら、この交換は[RFC8166]で指定されたXDR定義を変更しません。
The message format is intended to be further extensible within the normal scope of such IETF work (see Section 6 for further details). Section 8 of this document defines an IANA registry for this purpose. In addition, interoperation between implementations of RPC-over-RDMA version 1 that present this message format to peers and those that do not recognize this message format is guaranteed.
メッセージ形式は、そのようなIETF作業の通常の範囲内でさらに拡張できるように意図されています（詳細については、セクション6を参照）。このドキュメントのセクション8では、この目的のためのIANAレジストリを定義しています。さらに、このメッセージ形式をピアに提示するRPC-over-RDMAバージョン1の実装と、このメッセージ形式を認識しない実装の間の相互運用が保証されています。
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]で説明されているように解釈されます。
Section 3.3.2 of [RFC8166] defines the term "inline threshold". An inline threshold is the maximum number of bytes that can be transmitted using one RDMA Send and one RDMA Receive. There are a pair of inline thresholds for a connection: a client-to-server threshold and a server-to-client threshold.
[RFC8166]のセクション3.3.2は、「インラインしきい値」という用語を定義しています。インラインしきい値は、1つのRDMA送信と1つのRDMA受信を使用して送信できる最大バイト数です。接続には、クライアントからサーバーへのしきい値とサーバーからクライアントへのしきい値という、1対のインラインしきい値があります。
If an incoming RDMA message exceeds the size of a receiver's inline threshold, the Receive operation fails and the RDMA provider typically terminates the connection. To convey an RPC message larger than the receiver's inline threshold without risking receive failure, a sender must use explicit RDMA data transfer operations, which are more expensive than an RDMA Send. See Sections 3.3 and 3.5 of [RFC8166] for a complete discussion.
着信RDMAメッセージがレシーバーのインラインしきい値のサイズを超える場合、受信操作は失敗し、RDMAプロバイダーは通常接続を終了します。受信失敗の危険を冒さずに受信者のインラインしきい値より大きいRPCメッセージを伝達するには、送信者はRDMA送信よりもコストのかかる明示的なRDMAデータ転送操作を使用する必要があります。完全な議論については[RFC8166]のセクション3.3と3.5を見てください。
The default value of inline thresholds for RPC-over-RDMA version 1 connections is 1024 bytes (as defined in Section 3.3.3 of [RFC8166]). This value is adequate for nearly all NFS version 3 procedures.
RPC-over-RDMAバージョン1接続のインラインしきい値のデフォルト値は1024バイトです（[RFC8166]のセクション3.3.3で定義）。この値は、ほとんどすべてのNFSバージョン3の手順に適しています。
NFS version 4 COMPOUND operations [RFC7530] are larger on average than NFS version 3 procedures [RFC1813], forcing clients to use explicit RDMA operations for frequently issued requests such as LOOKUP and GETATTR. The use of RPCSEC_GSS security also increases the average size of RPC messages, due to the larger size of RPCSEC_GSS credential material included in RPC headers [RFC7861].
NFSバージョン4のCOMPOUND操作[RFC7530]は、NFSバージョン3の手順[RFC1813]よりも平均で大きく、クライアントはLOOKUPやGETATTRなどの頻繁に発行される要求に対して明示的なRDMA操作を使用する必要があります。 RPCSEC_GSSセキュリティを使用すると、RPCヘッダーに含まれるRPCSEC_GSS資格情報のサイズが大きくなるため、RPCメッセージの平均サイズも増加します[RFC7861]。
If a sender and receiver could somehow agree on larger inline thresholds, frequently used RPC transactions avoid the cost of explicit RDMA operations.
送信者と受信者が何らかの形でより大きなインラインしきい値に同意できる場合、頻繁に使用されるRPCトランザクションは明示的なRDMA操作のコストを回避します。
After an RDMA data transfer operation completes, an RDMA consumer can request that its peer's RDMA Network Interface Card (RNIC) invalidate the Steering Tag (STag) associated with the data transfer [RFC5042].
RDMAデータ転送操作が完了した後、RDMAコンシューマーは、ピアのRDMAネットワークインターフェイスカード（RNIC）がデータ転送[RFC5042]に関連付けられたステアリングタグ（STag）を無効にするよう要求できます。
An RDMA consumer requests remote invalidation by posting an RDMA Send with Invalidate operation in place of an RDMA Send operation. Each RDMA Send with Invalidate carries one STag to invalidate. The receiver of an RDMA Send with Invalidate performs the requested invalidation and then reports that invalidation as part of the completion of a waiting Receive operation.
RDMAコンシューマーは、RDMA送信操作の代わりに、無効なRDMA送信操作をポストすることにより、リモート無効化を要求します。無効化された各RDMA送信には、無効化するSTagが1つ含まれます。無効化されたRDMA送信の受信側は、要求された無効化を実行し、待機中の受信操作の完了の一部としてその無効化を報告します。
If both peers support remote invalidation, an RPC-over-RDMA responder might use remote invalidation when replying to an RPC request that provided chunks. Because one of the chunks has already been invalidated, finalizing the results of the RPC is made simpler and faster.
両方のピアがリモート無効化をサポートしている場合、RPC-over-RDMAレスポンダは、チャンクを提供したRPC要求に応答するときにリモート無効化を使用する可能性があります。チャンクの1つがすでに無効化されているため、RPCの結果のファイナライズがよりシンプルで高速になります。
However, there are some important caveats that contraindicate the blanket use of remote invalidation:
ただし、リモート無効化の全面的な使用を禁ずるいくつかの重要な警告があります。
* Remote invalidation is not supported by all RNICs.
* リモート無効化は、すべてのRNICでサポートされているわけではありません。
* Not all RPC-over-RDMA responder implementations can generate RDMA Send with Invalidate operations.
* すべてのRPC-over-RDMAレスポンダの実装が、無効な操作でRDMA送信を生成できるわけではありません。
* Not all RPC-over-RDMA requester implementations can recognize when remote invalidation has occurred.
* すべてのRPC-over-RDMAリクエスター実装が、リモート無効化がいつ発生したかを認識できるわけではありません。
* On one connection in different RPC-over-RDMA transactions, or in a single RPC-over-RDMA transaction, an RPC-over-RDMA requester can expose a mixture of STags that may be invalidated remotely and some that must not be. No indication is provided at the RDMA layer as to which is which.
* 異なるRPC-over-RDMAトランザクションの1つの接続、または単一のRPC-over-RDMAトランザクションで、RPC-over-RDMAリクエスターは、リモートで無効にできるSTagと無効にできないSTagの混合を公開できます。どちらがどれであるかについては、RDMA層で何も示されません。
A responder therefore must not employ remote invalidation unless it is aware of support for it in its own RDMA stack, and on the requester. And, without altering the XDR structure of RPC-over-RDMA version 1 messages, it is not possible to support remote invalidation with requesters that include an STag that must not be invalidated remotely in an RPC with STags that may be invalidated. Likewise, it is not possible to support remote invalidation with requesters that mix RPCs with STags that may be invalidated with RPCs with STags that must not be invalidated on the same connection.
したがって、レスポンダは、独自のRDMAスタックおよびリクエスタでのサポートを認識していない限り、リモート無効化を使用してはなりません。また、RPC-over-RDMAバージョン1メッセージのXDR構造を変更せずに、無効化される可能性のあるSTagを持つRPCでリモートで無効化してはならないSTagを含むリクエスターでリモート無効化をサポートすることはできません。同様に、同じ接続で無効にしてはならないSTagを持つRPCで無効化される可能性のあるSTagを持つRPCを混在させるリクエスターでリモート無効化をサポートすることはできません。
There are some NFS/RDMA client implementations whose STags are always safe to invalidate remotely. For such clients, indicating to the responder that remote invalidation is always safe can enable such invalidation without the need for additional protocol elements to be defined.
一部のNFS / RDMAクライアント実装には、STagが常にリモートで無効にしても安全です。そのようなクライアントの場合、リモートの無効化が常に安全であることをレスポンダに示すことで、追加のプロトコル要素を定義する必要なく、そのような無効化を有効にできます。
With an InfiniBand lower layer, for example, RDMA connection setup uses a Connection Manager (CM) when establishing a Reliable Connection [IBA]. When an RPC-over-RDMA version 1 transport connection is established, the client (which actively establishes connections) and the server (which passively accepts connections) populate the CM Private Data field exchanged as part of CM connection establishment.
たとえば、InfiniBandの下位層では、RDMA接続セットアップは、信頼できる接続[IBA]を確立するときに接続マネージャー（CM）を使用します。 RPC-over-RDMAバージョン1トランスポート接続が確立されると、クライアント（接続をアクティブに確立する）とサーバー（接続をパッシブに受け入れる）が、CM接続確立の一部として交換されるCMプライベートデータフィールドにデータを入力します。
The transport properties exchanged via this mechanism are fixed for the life of the connection. Each new connection presents an opportunity for a fresh exchange. An implementation of the extension described in this document MUST be prepared for the settings to change upon a reconnection.
このメカニズムを介して交換されるトランスポートプロパティは、接続の存続期間中固定されます。新しいつながりがあるたびに、新鮮な交流の機会が生まれます。このドキュメントで説明されている拡張機能の実装は、再接続時に設定が変更されるように準備する必要があります。
For RPC-over-RDMA version 1, the CM Private Data field is formatted as described below. RPC clients and servers use the same format. If the capacity of the Private Data field is too small to contain this message format or the underlying RDMA transport is not managed by a CM, the CM Private Data field cannot be used on behalf of RPC-over-RDMA version 1.
RPC-over-RDMAバージョン1の場合、CMプライベートデータフィールドは以下のようにフォーマットされます。 RPCクライアントとサーバーは同じ形式を使用します。 Private Dataフィールドの容量が小さすぎてこのメッセージフォーマットを含めることができない場合、または基になるRDMAトランスポートがCMで管理されていない場合、CM Private DataフィールドはRPC-over-RDMAバージョン1の代わりに使用できません。
The first eight octets of the CM Private Data field are to be formatted as follows:
CM Private Dataフィールドの最初の8オクテットは、次のようにフォーマットされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved |R| Send Size | Receive Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format Identifier: This field contains a fixed 32-bit value that identifies the content of the Private Data field as an RPC-over-RDMA version 1 CM Private Data message. In RPC-over-RDMA version 1 Private Data, the value of this field is always 0xf6ab0e18, in network byte order. The use of this field is further expanded upon in Section 5.2.
フォーマット識別子：このフィールドには、プライベートデータフィールドの内容をRPC-over-RDMAバージョン1 CMプライベートデータメッセージとして識別する固定32ビット値が含まれています。 RPC-over-RDMAバージョン1プライベートデータでは、このフィールドの値は常にネットワークバイトオーダーで0xf6ab0e18です。このフィールドの使用は、セクション5.2でさらに拡張されます。
Version: This 8-bit field contains a message format version number. The value "1" in this field indicates that exactly eight octets are present, that they appear in the order described in this section, and that each has the meaning defined in this section. Further considerations about the use of this field are discussed in Section 6.
バージョン：この8ビットのフィールドには、メッセージ形式のバージョン番号が含まれます。このフィールドの値「1」は、正確に8オクテットが存在し、これらがこのセクションで説明されている順序で表示され、それぞれがこのセクションで定義されている意味を持つことを示します。このフィールドの使用に関するその他の考慮事項については、セクション6で説明します。
Reserved: This 7-bit field is unused. Senders MUST set these bits to zero, and receivers MUST ignore their value.
予約済み：この7ビットのフィールドは未使用です。送信側はこれらのビットをゼロに設定する必要があり、受信側はそれらの値を無視する必要があります。
R: This 1-bit field indicates that the sender supports remote invalidation. The field is set and interpreted as described in Section 4.1.
R：この1ビットのフィールドは、送信者がリモート無効化をサポートしていることを示します。このフィールドは、セクション4.1の説明に従って設定および解釈されます。
Send Size: This 8-bit field contains an encoded value corresponding to the maximum number of bytes this peer is prepared to transmit in a single RDMA Send on this connection. The value is encoded as described in Section 4.2.
送信サイズ：この8ビットのフィールドには、この接続で単一のRDMA送信で送信するためにこのピアが準備する最大バイト数に対応するエンコードされた値が含まれます。値はセクション4.2で説明されているようにエンコードされます。
Receive Size: This 8-bit field contains an encoded value corresponding to the maximum number of bytes this peer is prepared to receive with a single RDMA Receive on this connection. The value is encoded as described in Section 4.2.
受信サイズ：この8ビットのフィールドには、この接続で単一のRDMA受信を使用してこのピアが受信する準備ができている最大バイト数に対応するエンコードされた値が含まれます。値はセクション4.2で説明されているようにエンコードされます。
The R field indicates limited support for remote invalidation as described in Section 3.2. When both connection peers have set this bit flag in their CM Private Data, the responder MAY use RDMA Send with Invalidate operations when transmitting RPC Replies. Each RDMA Send with Invalidate MUST invalidate an STag associated only with the Transaction ID (XID) in the rdma_xid field of the RPC-over-RDMA Transport Header it carries.
セクション3.2で説明されているように、Rフィールドはリモート無効化のサポートが制限されていることを示します。両方の接続ピアがCMプライベートデータにこのビットフラグを設定した場合、レスポンダは、RPC応答を送信するときに、無効なRDMA送信操作を使用できます（MAY）。無効化された各RDMA送信は、運ぶRPC-over-RDMAトランスポートヘッダーのrdma_xidフィールドのトランザクションID（XID）にのみ関連付けられたSTagを無効化する必要があります（MUST）。
When either peer on a connection clears this flag, the responder MUST use only RDMA Send when transmitting RPC Replies.
接続のいずれかのピアがこのフラグをクリアした場合、レスポンダはRPC応答を送信するときにRDMA送信のみを使用する必要があります。
Inline threshold sizes from 1024 to 262144 octets can be represented in the Send Size and Receive Size fields. The inline threshold values provide a pair of 1024-octet-aligned maximum message lengths that guarantee that Send and Receive operations do not fail due to length errors.
1024〜262144オクテットのインラインしきい値サイズは、送信サイズフィールドと受信サイズフィールドで表すことができます。インラインしきい値は、1024オクテットで整列された最大メッセージ長のペアを提供し、長さエラーが原因で送信および受信操作が失敗しないことを保証します。
The minimum inline threshold for RPC-over-RDMA version 1 is 1024 octets (see Section 3.3.3 of [RFC8166]). The values in the Send Size and Receive Size fields represent the unsigned number of additional kilo-octets of length beyond the first 1024 octets. Thus, a sender computes the encoded value by dividing its actual buffer size, in octets, by 1024 and subtracting one from the result. A receiver decodes an incoming Size value by performing the inverse set of operations: it adds one to the encoded value and then multiplies that result by 1024.
RPC-over-RDMAバージョン1の最小インラインしきい値は1024オクテットです（[RFC8166]のセクション3.3.3を参照）。 [送信サイズ]および[受信サイズ]フィールドの値は、最初の1024オクテットを超える長さの追加のキロオクテットの符号なし数を表します。したがって、送信者は、実際のバッファサイズ（オクテット単位）を1024で割り、結果から1を引くことにより、エンコードされた値を計算します。受信機は、操作の逆のセットを実行することにより、着信するSize値をデコードします。エンコードされた値に1を加え、その結果に1024を乗算します。
The client uses the smaller of its own send size and the server's reported receive size as the client-to-server inline threshold. The server uses the smaller of its own send size and the client's reported receive size as the server-to-client inline threshold.
クライアントは自身の送信サイズとサーバーから報告された受信サイズの小さい方をクライアントからサーバーへのインラインしきい値として使用します。サーバーは自身の送信サイズとクライアントから報告された受信サイズの小さい方をサーバーからクライアントへのインラインしきい値として使用します。
The extension described in this document is designed to allow RPC-over-RDMA version implementations that use CM Private Data to interoperate fully with RPC-over-RDMA version 1 implementations that do not exchange this information. Implementations that use this extension must also interoperate fully with RDMA implementations that use CM Private Data for other purposes. Realizing these goals requires that implementations of this extension follow the practices described in the rest of this section.
このドキュメントで説明する拡張機能は、CMプライベートデータを使用するRPC-over-RDMAバージョンの実装が、この情報を交換しないRPC-over-RDMAバージョン1の実装と完全に相互運用できるように設計されています。この拡張機能を使用する実装は、他の目的でCMプライベートデータを使用するRDMA実装と完全に相互運用する必要もあります。これらの目標を実現するには、この拡張機能の実装が、このセクションの残りの部分で説明されているプラクティスに従う必要があります。
When a peer does not receive a CM Private Data message that conforms to Section 4, it needs to act as if the remote peer supports only the default RPC-over-RDMA version 1 settings, as defined in [RFC8166]. In other words, the peer MUST behave as if a Private Data message was received in which (1) bit 15 of the Flags field is zero and (2) both Size fields contain the value zero.
ピアがセクション4に適合するCMプライベートデータメッセージを受信しない場合、[RFC8166]で定義されているように、リモートピアがデフォルトのRPC-over-RDMAバージョン1設定のみをサポートするかのように動作する必要があります。言い換えると、ピアは、（1）Flagsフィールドのビット15がゼロであり、（2）両方のSizeフィールドに値ゼロが含まれているプライベートデータメッセージが受信されたかのように動作する必要があります。
The Format Identifier field defined in Section 4 is provided to enable implementations to distinguish the Private Data defined in this document from Private Data inserted at other layers, such as the additional Private Data defined by the MPAv2 protocol described in [RFC6581], and others.
セクション4で定義されたフォーマット識別子フィールドは、このドキュメントで定義されたプライベートデータを、[RFC6581]で説明されているMPAv2プロトコルで定義された追加のプライベートデータなど、他のレイヤーで挿入されたプライベートデータと区別できるようにするために提供されています。
As part of connection establishment, the buffer containing the received Private Data is searched for the Format Identifier word. The offset of the Format Identifier is not restricted to any alignment. If the RPC-over-RDMA version 1 CM Private Data Format Identifier is not present, an RPC-over-RDMA version 1 receiver MUST behave as if no RPC-over-RDMA version 1 CM Private Data has been provided.
接続確立の一部として、受信したプライベートデータを含むバッファでフォーマット識別子ワードが検索されます。フォーマットIDのオフセットは、いかなる配置にも制限されません。 RPC-over-RDMAバージョン1 CMプライベートデータフォーマット識別子が存在しない場合、RPC-over-RDMAバージョン1レシーバーは、RPC-over-RDMAバージョン1 CMプライベートデータが提供されていないかのように動作する必要があります。
Once the RPC-over-RDMA version 1 CM Private Data Format Identifier is found, the receiver parses the subsequent octets as RPC-over-RDMA version 1 CM Private Data. As additional assurance that the content is valid RPC-over-RDMA version 1 CM Private Data, the receiver should check that the format version number field contains a valid and recognized version number and the size of the content does not overrun the length of the buffer.
RPC-over-RDMAバージョン1 CMプライベートデータフォーマット識別子が見つかると、受信機は後続のオクテットをRPC-over-RDMAバージョン1 CMプライベートデータとして解析します。コンテンツが有効なRPC-over-RDMAバージョン1 CMプライベートデータであることの追加の保証として、受信者は、フォーマットバージョン番号フィールドに有効で認識されたバージョン番号が含まれ、コンテンツのサイズがバッファーの長さを超えないことを確認する必要があります。
Although the message format described in this document provides the ability for the client and server to exchange particular information about the local RPC-over-RDMA implementation, it is possible that there will be a future need to exchange additional properties. This would make it necessary to extend or otherwise modify the format described in this document.
このドキュメントで説明するメッセージ形式は、クライアントとサーバーがローカルRPC-over-RDMA実装に関する特定の情報を交換する機能を提供しますが、将来、追加のプロパティを交換する必要が生じる可能性があります。このため、このドキュメントで説明されている形式を拡張または変更する必要があります。
Any modification faces the problem of interoperating properly with implementations of RPC-over-RDMA version 1 that are unaware of the existence of the new format. These include implementations that do not recognize the exchange of CM Private Data as well as those that recognize only the format described in this document.
変更を加えると、新しいフォーマットの存在を認識しないRPC-over-RDMAバージョン1の実装と適切に相互運用するという問題に直面します。これらには、CMプライベートデータの交換を認識しない実装と、このドキュメントで説明されている形式のみを認識する実装が含まれます。
Given the message format described in this document, these interoperability constraints could be met by the following sorts of new message formats:
このドキュメントで説明されているメッセージ形式を考えると、これらの相互運用性の制約は、次の種類の新しいメッセージ形式によって満たすことができます。
* A format that uses a different value for the first four bytes of the format, as provided for in the registry described in Section 8.
* セクション8で説明されているレジストリで提供されている、フォーマットの最初の4バイトに異なる値を使用するフォーマット。
* A format that uses the same value for the Format Identifier field and a value other than one (1) in the Version field.
* Format Identifierフィールドに同じ値を使用し、Versionフィールドに1以外の値を使用するフォーマット。
Although it is possible to reorganize the last three of the eight bytes in the existing format, extended formats are unlikely to do so. New formats would take the form of extensions of the format described in this document with added fields starting at byte eight of the format or changes to the definition of bits in the Reserved field.
既存の形式で8バイトの最後の3バイトを再編成することは可能ですが、拡張形式ではそうすることはほとんどありません。新しい形式は、このドキュメントで説明されている形式の拡張の形式を取り、形式のバイト8から始まるフィールドが追加されるか、予約済みフィールドのビットの定義が変更されます。
The reader is directed to the Security Considerations section of [RFC8166] for background and further discussion.
読者は背景とさらなる議論のために[RFC8166]のセキュリティ考慮事項セクションに導かれます。
The RPC-over-RDMA version 1 protocol framework depends on the semantics of the Reliable Connected (RC) queue pair (QP) type, as defined in Section 9.7.7 of [IBA]. The integrity of CM Private Data and the authenticity of its source are ensured by the exclusive use of RC QPs. Any attempt to interfere with or hijack data in transit on an RC connection results in the RDMA provider terminating the connection.
[IBA]のセクション9.7.7で定義されているように、RPC-over-RDMAバージョン1プロトコルフレームワークは、Reliable Connected（RC）キューペア（QP）タイプのセマンティクスに依存します。 CMプライベートデータの整合性とそのソースの信頼性は、RC QPの排他的な使用によって保証されます。 RC接続で転送中のデータを妨害またはハイジャックしようとすると、RDMAプロバイダーが接続を終了します。
The Security Considerations section of [RFC5042] refers the reader to further relevant discussion of generic RDMA transport security. That document recommends IPsec as the default transport-layer security solution. When deployed with the Remote Direct Memory Access Protocol (RDMAP) [RFC5040], DDP [RFC5041], and MPA [RFC5044], IPsec establishes a protected channel before any operations are exchanged; thus, it protects the exchange of Private Data. However, IPsec is not available for InfiniBand or RDMA over Converged Ethernet (RoCE) deployments. Those fabrics rely on physical security and cyclic redundancy checks to protect network traffic.
[RFC5042]のセキュリティに関する考慮事項のセクションでは、一般的なRDMAトランスポートセキュリティのさらに関連する説明を読者に紹介しています。このドキュメントでは、デフォルトのトランスポート層セキュリティソリューションとしてIPsecを推奨しています。リモートダイレクトメモリアクセスプロトコル（RDMAP）[RFC5040]、DDP [RFC5041]、およびMPA [RFC5044]を使用して展開すると、IPsecは操作が交換される前に保護されたチャネルを確立します。したがって、それはプライベートデータの交換を保護します。ただし、IPsecはInfiniBandまたはRDMA over Converged Ethernet（RoCE）の展開では使用できません。これらのファブリックは、物理的なセキュリティと巡回冗長検査に依存してネットワークトラフィックを保護します。
Exchanging the information contained in the message format defined in this document does not expose upper-layer payloads to an attacker. Furthermore, the behavior changes that occur as a result of exchanging the Private Data described in the current document do not introduce any new risk of exposure of upper-layer payload data.
このドキュメントで定義されているメッセージ形式に含まれている情報を交換しても、上位層のペイロードは攻撃者に公開されません。さらに、現在のドキュメントで説明されているプライベートデータの交換の結果として発生する動作の変更は、上位層のペイロードデータが公開されるという新たなリスクをもたらしません。
Improperly setting one of the fields in version 1 Private Data can result in an increased risk of disconnection (i.e., self-imposed Denial of Service). A similar risk can arise if non-RPC-over-RDMA CM Private Data inadvertently contains the Format Identifier that identifies this protocol's data structure. Additional checking of incoming Private Data, as described in Section 5.2, can help reduce this risk.
バージョン1のプライベートデータのフィールドの1つを不適切に設定すると、切断のリスクが高まる可能性があります（つまり、自発的なサービス拒否）。非RPC-over-RDMA CMプライベートデータに、このプロトコルのデータ構造を識別するフォーマット識別子が誤って含まれている場合にも、同様のリスクが発生する可能性があります。セクション5.2で説明されているように、受信プライベートデータをさらにチェックすることで、このリスクを減らすことができます。
In addition to describing the structure of a new format version, any document that extends the Private Data format described in the current document must discuss security considerations of new data items exchanged between connection peers. Such documents should also explore the risks of erroneously identifying non-RPC-over-RDMA CM Private Data as the new format.
新しい形式のバージョンの構造を説明することに加えて、現在のドキュメントで説明されているプライベートデータ形式を拡張するドキュメントでは、接続ピア間で交換される新しいデータアイテムのセキュリティに関する考慮事項について説明する必要があります。このようなドキュメントでは、RPC-over-RDMA以外のCMプライベートデータを新しい形式として誤って識別するリスクについても検討する必要があります。
IANA has created the "RDMA-CM Private Data Identifiers" subregistry within the "Remote Direct Data Placement" protocol category group. This is a subregistry of 32-bit numbers that identify the upper-layer protocol associated with data that appears in the application-specific RDMA-CM Private Data area. The fields in this subregistry include the following: Format Identifier, Length (format length, in octets), Description, and Reference.
IANAは、「Remote Direct Data Placement」プロトコルカテゴリグループ内に「RDMA-CM Private Data Identifiers」サブレジストリを作成しました。これは、アプリケーション固有のRDMA-CMプライベートデータ領域に表示されるデータに関連付けられた上位層プロトコルを識別する32ビット番号のサブレジストリです。このサブレジストリのフィールドには、フォーマット識別子、長さ（オクテット単位のフォーマット長）、説明、および参照が含まれます。
The initial contents of this registry are a single entry:
このレジストリの最初の内容は単一のエントリです。
+===================+========+=======================+===========+
| Format Identifier | Length | Description | Reference |
+===================+========+=======================+===========+
| 0xf6ab0e18 | 8 | RPC-over-RDMA version | RFC 8797 |
| | | 1 CM Private Data | |
+-------------------+--------+-----------------------+-----------+
Table 1: New "RDMA-CM Private Data Identifiers" Registry
表1：新しい「RDMA-CM Private Data Identifiers」レジストリ
IANA is to assign subsequent new entries in this registry using the Specification Required policy as defined in Section 4.6 of [RFC8126].
IANAは、[RFC8126]のセクション4.6で定義されている仕様必須ポリシーを使用して、このレジストリの後続の新しいエントリを割り当てます。
The Designated Expert (DE), appointed by the IESG, should ascertain the existence of suitable documentation that defines the semantics and format of the Private Data, and verify that the document is permanently and publicly available. Documentation produced outside the IETF must not conflict with work that is active or already published within the IETF. The new Reference field should contain a reference to that documentation.
IESGによって任命された指定専門家（DE）は、プライベートデータのセマンティクスと形式を定義する適切なドキュメントの存在を確認し、そのドキュメントが永続的かつ公的に利用可能であることを確認する必要があります。 IETFの外部で作成されたドキュメントは、IETF内でアクティブまたは既に公開されている作業と競合してはなりません。新しい参照フィールドには、そのドキュメントへの参照が含まれているはずです。
The Description field should contain the name of the upper-layer protocol that generates and uses the Private Data.
[説明]フィールドには、プライベートデータを生成して使用する上位層プロトコルの名前を含める必要があります。
The DE should assign a new Format Identifier so that it does not conflict with existing entries in this registry and so that it is not likely to be mistaken as part of the payload of other registered formats.
DEは、このレジストリの既存のエントリと競合しないように、また他の登録済みフォーマットのペイロードの一部と間違えられないように、新しいフォーマット識別子を割り当てる必要があります。
The DE shall post the request to the NFSV4 Working Group mailing list (or a successor to that list, if such a list exists) for comment and review. The DE shall approve or deny the request and publish notice of the decision within 30 days.
DEは、コメントとレビューのために、NFSV4ワーキンググループメーリングリスト（または、そのようなリストが存在する場合は、そのリストの後継者）に要求を投稿します。 DEはリクエストを承認または拒否し、30日以内に決定の通知を公開します。
[IBA] InfiniBand Trade Association, "InfiniBand Architecture Specification Volume 1", Release 1.3, March 2015, <https://www.infinibandta.org/>.
[IBA] InfiniBand Trade Association、「InfiniBand Architecture Specification Volume 1」、リリース1.3、2015年3月、<https://www.infinibandta.org/>。
[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>。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC4506] Eisler、M。、編、「XDR：外部データ表現標準」、STD 67、RFC 4506、DOI 10.17487 / RFC4506、2006年5月、<https://www.rfc-editor.org/info/rfc4506 >。
[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、「A Remote Direct Memory Access Protocol Specification」、RFC 5040、DOI 10.17487 / RFC5040、2007年10月、< https://www.rfc-editor.org/info/rfc5040>。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, DOI 10.17487/RFC5042, October 2007, <https://www.rfc-editor.org/info/rfc5042>.
[RFC5042] Pinkerton、J。およびE. Deleganes、「Direct Data Placement Protocol（DDP）/ Remote Direct Memory Access Protocol（RDMAP）Security」、RFC 5042、DOI 10.17487 / RFC5042、2007年10月、<https：// www。 rfc-editor.org/info/rfc5042>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[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>。
[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>。
[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、「Reliable Transportsを介した直接データ配置」、RFC 5041、DOI 10.17487 / RFC5041、2007年10月、<https：// www。 rfc-editor.org/info/rfc5041>。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, DOI 10.17487/RFC5044, October 2007, <https://www.rfc-editor.org/info/rfc5044>.
[RFC5044] Culley、P.、Elzur、U.、Recio、R.、Bailey、S。、およびJ. Carrier、「Marker PDU Aligned Framing for TCP Specification」、RFC 5044、DOI 10.17487 / RFC5044、2007年10月、< https://www.rfc-editor.org/info/rfc5044>。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <https://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月、<https://www.rfc-editor.org/info/rfc5531>。
[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>。
[RFC6581] Kanevsky, A., Ed., Bestler, C., Ed., Sharp, R., and S. Wise, "Enhanced Remote Direct Memory Access (RDMA) Connection Establishment", RFC 6581, DOI 10.17487/RFC6581, April 2012, <https://www.rfc-editor.org/info/rfc6581>.
[RFC6581] Kanevsky、A.、Ed。、Bestler、C.、Ed。、Sharp、R.、and S. Wise、 "Enhanced Remote Direct Memory Access（RDMA）Connection Establishment"、RFC 6581、DOI 10.17487 / RFC6581、 2012年4月、<https://www.rfc-editor.org/info/rfc6581>。
[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]ヘインズ、T。、エド。およびD. Noveck、編、「ネットワークファイルシステム（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、「Remote Procedure Call（RPC）Security Version 3」、RFC 7861、DOI 10.17487 / RFC7861、2016年11月、<https://www.rfc-editor.org/info/ rfc7861>。
Acknowledgments
謝辞
Thanks to Christoph Hellwig and Devesh Sharma for suggesting this approach, and to Tom Talpey and David Noveck for their expert comments and review. The author also wishes to thank Bill Baker and Greg Marsden for their support of this work. Also, thanks to expert reviewers Sean Hefty and Dave Minturn.
このアプローチを提案してくれたChristoph HellwigとDevesh Sharma、専門家のコメントとレビューをしてくれたTom TalpeyとDavid Noveckに感謝します。著者はまた、この作業を支援してくれたBill BakerとGreg Marsdenに感謝します。また、専門のレビュアーSean HeftyとDave Minturnに感謝します。
Special thanks go to document shepherd Brian Pawlowski, Transport Area Director Magnus Westerlund, NFSV4 Working Group Chairs David Noveck and Spencer Shepler, and NFSV4 Working Group Secretary Thomas Haynes.
ドキュメントシェパードのBrian Pawlowski、トランスポートエリアディレクターのMagnus Westerlund、NFSV4ワーキンググループの議長であるDavid NoveckとSpencer Shepler、およびNFSV4ワーキンググループの書記Thomas Haynesに特に感謝します。
Author's Address
著者のアドレス
Charles Lever Oracle Corporation United States of America
Charles Lever Oracle Corporationアメリカ合衆国
Email: chuck.lever@oracle.com