[要約] 要約： RFC 8267は、NFSとRPC-over-RDMAバージョン1の上位レイヤーバインディングに関する仕様です。 目的は、NFSとRPC-over-RDMAの統合を容易にし、高速で効率的なファイルシステムアクセスを提供することです。
Internet Engineering Task Force (IETF) C. Lever
Request for Comments: 8267 Oracle
Obsoletes: 5667 October 2017
Category: Standards Track
ISSN: 2070-1721
Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1
RPC-over-RDMAバージョン1へのネットワークファイルシステム（NFS）上位層バインディング
Abstract
概要
This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.
このドキュメントでは、ネットワークファイルシステム（NFS）プロトコルバージョンの上位層バインディングをRPC-over-RDMAバージョン1に指定し、直接データ配置を使用できるようにします。このドキュメントはRFC 5667を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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/rfc8267.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8267で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Reply Size Estimation . . . . . . . . . . . . . . . . . . . . 5
3.1. Short Reply Chunk Retry . . . . . . . . . . . . . . . . . 5
4. Upper-Layer Binding for NFS Versions 2 and 3 . . . . . . . . 6
4.1. Reply Size Estimation . . . . . . . . . . . . . . . . . . 7
4.2. RPC Binding Considerations . . . . . . . . . . . . . . . 7
5. Upper-Layer Bindings for NFS Versions 2 and 3 Auxiliary
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. MOUNT, NLM, and NSM Protocols . . . . . . . . . . . . . . 8
5.2. NFSACL Protocol . . . . . . . . . . . . . . . . . . . . . 8
6. Upper-Layer Binding for NFS Version 4 . . . . . . . . . . . . 8
6.1. DDP-Eligibility . . . . . . . . . . . . . . . . . . . . . 8
6.2. Reply Size Estimation . . . . . . . . . . . . . . . . . . 9
6.3. RPC Binding Considerations . . . . . . . . . . . . . . . 10
6.4. NFS COMPOUND Requests . . . . . . . . . . . . . . . . . . 10
6.5. NFS Callback Requests . . . . . . . . . . . . . . . . . . 13
6.6. Session-Related Considerations . . . . . . . . . . . . . 14
6.7. Transport Considerations . . . . . . . . . . . . . . . . 15
7. Extending NFS Upper-Layer Bindings . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Changes Since RFC 5667 . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
The RPC-over-RDMA version 1 transport may employ Direct Data Placement (DDP) to convey data payloads associated with RPC transactions [RFC8166]. To enable successful interoperation, RPC client and server implementations using RPC-over-RDMA version 1 must agree which External Data Representation (XDR) data items and RPC procedures are eligible to use DDP.
RPC-over-RDMAバージョン1トランスポートは、直接データ配置（DDP）を使用して、RPCトランザクションに関連するデータペイロードを伝達します[RFC8166]。相互運用を成功させるには、RPC-over-RDMAバージョン1を使用するRPCクライアントとサーバーの実装で、どの外部データ表現（XDR）データ項目とRPCプロシージャがDDPを使用する資格があるかについて合意する必要があります。
An Upper-Layer Binding specifies this agreement for one or more versions of one RPC program. Other operational details, such as RPC binding assignments, pairing Write chunks with result data items, and reply size estimation, are also specified by this Binding.
上位層バインディングは、1つのRPCプログラムの1つ以上のバージョンに対するこの合意を指定します。 RPCバインディングの割り当て、書き込みチャンクと結果データアイテムのペア、応答サイズの見積もりなど、その他の操作の詳細も、このバインディングによって指定されます。
This document contains material required of Upper-Layer Bindings, as specified in [RFC8166], for the following NFS protocol versions:
このドキュメントには、[RFC8166]で指定されているように、次のNFSプロトコルバージョンの上位層バインディングに必要な資料が含まれています。
o NFS version 2 [RFC1094]
o 馬ブレスA [RFS 1094]
o NFS version 3 [RFC1813]
o 疑似馬pa [RFS 1813]
o NFS version 4.0 [RFC7530]
o 私のウマの息4.0 [Rafsahakha 0]
o NFS version 4.1 [RFC5661]
o NFSバージョン4.1 [RFC5661]
o NFS version 4.2 [RFC7862]
o NFSバージョン4.2 [RFC7862]
Upper-Layer Bindings are also provided for auxiliary protocols used with NFS versions 2 and 3 (see Section 5).
上位層バインディングは、NFSバージョン2および3で使用される補助プロトコルにも提供されます（セクション5を参照）。
This document assumes the reader is already familiar with concepts and terminology defined in [RFC8166] and the documents it references.
このドキュメントは、読者が[RFC8166]で定義されている概念と用語、およびそれが参照するドキュメントにすでに精通していることを前提としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
During the construction of each RPC Call message, a requester is responsible for allocating appropriate resources for receiving the corresponding Reply message. If the requester expects the RPC Reply message will be larger than its inline threshold, it provides Write and/or Reply chunks wherein the responder can place results and the Reply's Payload stream.
各RPC Callメッセージの作成中に、リクエスターは、対応するReplyメッセージを受信するための適切なリソースを割り当てる責任があります。リクエスターは、RPC応答メッセージがそのインラインしきい値よりも大きくなることを期待する場合、書き込みチャンクまたは応答チャンク、あるいはその両方を提供し、レスポンダーは結果と応答のペイロードストリームを配置できます。
A reply resource overrun occurs if the RPC Reply Payload stream does not fit into the provided Reply chunk or if no Reply chunk was provided and the Payload stream does not fit inline. This prevents the responder from returning the Upper-Layer reply to the requester. Therefore, reliable reply size estimation is necessary to ensure successful interoperation.
RPC Reply Payloadストリームが提供されたReplyチャンクに適合しない場合、またはReplyチャンクが提供されておらず、ペイロードストリームがインラインに適合しない場合、返信リソースのオーバーランが発生します。これにより、レスポンダが上位層の応答をリクエスタに返すのを防ぎます。したがって、相互運用を確実に成功させるには、信頼できる応答サイズの見積もりが必要です。
In most cases, the NFS protocol's XDR definition provides enough information to enable an NFS client to predict the maximum size of the expected Reply message. If there are variable-size data items in the result, the maximum size of the RPC Reply message can be estimated as follows:
ほとんどの場合、NFSプロトコルのXDR定義は、NFSクライアントが予期される応答メッセージの最大サイズを予測できるようにするのに十分な情報を提供します。結果に可変サイズのデータ項目がある場合、RPC応答メッセージの最大サイズは次のように見積もることができます。
o The client requests only a specific portion of an object (e.g., using the "count" and "offset" fields in an NFS READ).
o クライアントは、オブジェクトの特定の部分のみを要求します（たとえば、NFS READの「count」および「offset」フィールドを使用します）。
o The client limits the number of results (e.g., using the "count" field of an NFS READDIR request).
o クライアントは結果の数を制限します（たとえば、NFS READDIR要求の「カウント」フィールドを使用）。
o The client has already cached the size of the whole object it is about to request (e.g., via a previous NFS GETATTR request).
o クライアントは、要求しようとしているオブジェクト全体のサイズをすでにキャッシュしています（たとえば、以前のNFS GETATTR要求を介して）。
o The client and server have negotiated a maximum size for all calls and responses (e.g., using a CREATE_SESSION operation).
o クライアントとサーバーは、すべての呼び出しと応答の最大サイズをネゴシエートしました（例：CREATE_SESSION操作を使用）。
In a few cases, either the size of one or more returned data items or the number of returned data items cannot be known in advance of forming an RPC Call.
いくつかのケースでは、RPCコールを形成する前に、1つ以上の返されたデータアイテムのサイズまたは返されたデータアイテムの数を知ることができません。
If an NFS server finds that the NFS client provided inadequate receive resources to return the whole Reply, it returns an RPC-level error or a transport error, such as ERR_CHUNK.
NFSサーバーは、NFSクライアントが不十分な受信リソースを提供してReply全体を返すことを検出すると、RPCレベルのエラーまたはERR_CHUNKなどのトランスポートエラーを返します。
In response to these errors, an NFS client can choose to:
これらのエラーに応じて、NFSクライアントは次のいずれかを選択できます。
o terminate the RPC transaction immediately with an error, or
o RPCトランザクションをエラーで直ちに終了する、または
o allocate a larger Reply chunk and send the same request as a new RPC transaction (a new Transaction ID (XID) should be assigned to the retransmitted request to avoid matching a cached RPC Reply that caches the original error). The NFS client should avoid retrying the request indefinitely because a responder may return ERR_CHUNK for a variety of reasons.
o より大きな返信チャンクを割り当て、同じリクエストを新しいRPCトランザクションとして送信します（元のエラーをキャッシュするキャッシュされたRPC返信と一致しないように、新しいトランザクションID（XID）を再送信されたリクエストに割り当てる必要があります）。レスポンダはさまざまな理由でERR_CHUNKを返す可能性があるため、NFSクライアントは要求を無期限に再試行しないようにする必要があります。
Subsequent sections of this document discuss exactly which operations might have ultimate difficulty with reply size estimation. These operations are eligible for "short Reply chunk retry". Unless explicitly mentioned as applicable, short Reply chunk retry should not be used since accurate reply size estimation is problematic in only a few cases. In all other cases, reply size underestimation is considered a correctable implementation bug.
このドキュメントの後続のセクションでは、応答サイズの見積もりが最終的に困難になる可能性がある操作について正確に説明します。これらの操作は、「短い応答チャンク再試行」の対象です。該当することが明記されていない限り、正確な応答サイズの見積もりが問題になるのはごく少数のケースだけなので、短い応答チャンクの再試行は使用しないでください。他のすべての場合では、応答サイズの過小評価は修正可能な実装バグと見なされます。
NFS server implementations can avoid connection loss by first confirming that target RDMA segments are large enough to receive results before initiating explicit RDMA operations.
NFSサーバーの実装では、ターゲットRDMAセグメントが、明示的なRDMA操作を開始する前に結果を受信するのに十分な大きさであることを最初に確認することにより、接続の損失を回避できます。
The Upper-Layer Binding specification in this section applies to NFS versions 2 [RFC1094] and 3 [RFC1813]. For brevity, in this document a "Legacy NFS client" refers to an NFS client using versions 2 or 3 of the NFS RPC program (100003) to communicate with an NFS server. Likewise, a "Legacy NFS server" is an NFS server communicating with clients using NFS versions 2 or 3.
このセクションの上位層バインディング仕様は、NFSバージョン2 [RFC1094]および3 [RFC1813]に適用されます。簡潔にするために、このドキュメントでは、「レガシーNFSクライアント」は、NFS RPCプログラムのバージョン2または3（100003）を使用してNFSサーバーと通信するNFSクライアントを指します。同様に、「レガシーNFSサーバー」は、NFSバージョン2または3を使用してクライアントと通信するNFSサーバーです。
The following XDR data items in NFS versions 2 and 3 are DDP-eligible:
NFSバージョン2および3の次のXDRデータ項目は、DDPに対応しています。
o the opaque file data argument in the NFS WRITE procedure
o NFS WRITEプロシージャの不透明なファイルデータ引数
o the pathname argument in the NFS SYMLINK procedure
o NFS SYMLINKプロシージャのパス名引数
o the opaque file data result in the NFS READ procedure
o 不透明なファイルデータはNFS READプロシージャになります
o the pathname result in the NFS READLINK procedure
o パス名の結果、NFS READLINKプロシージャ
All other argument or result data items in NFS versions 2 and 3 are not DDP-eligible.
NFSバージョン2および3の他のすべての引数または結果データ項目は、DDP対応ではありません。
A transport error does not give an indication of whether the server has processed the arguments of the RPC Call or whether the server has accessed or modified client memory associated with that RPC.
トランスポートエラーは、サーバーがRPC呼び出しの引数を処理したかどうか、またはサーバーがそのRPCに関連付けられたクライアントメモリにアクセスまたは変更したかどうかを示しません。
A Legacy NFS client determines the maximum reply size for each operation using the criteria outlined in Section 3. There are no operations in NFS versions 2 or 3 that benefit from short Reply chunk retry.
レガシーNFSクライアントは、セクション3で概説されている基準を使用して、各操作の最大応答サイズを決定します。NFSバージョン2または3には、短い応答チャンク再試行からメリットを得る操作はありません。
Legacy NFS servers traditionally listen for clients on UDP and TCP port 2049. Additionally, they register these ports with a local portmapper [RFC1833] service.
従来のNFSサーバーは、伝統的にUDPおよびTCPポート2049でクライアントをリッスンします。さらに、これらのポートをローカルポートマッパー[RFC1833]サービスに登録します。
A Legacy NFS server supporting RPC-over-RDMA version 1 on such a network and registering itself with the RPC portmapper MAY choose an arbitrary port or MAY use the alternative well-known port number for its RPC-over-RDMA service (see Section 9). The chosen port MAY be registered with the RPC portmapper under the netids assigned in [RFC8166].
そのようなネットワークでRPC-over-RDMAバージョン1をサポートし、RPCポートマッパーに登録するレガシーNFSサーバーは、任意のポートを選択するか、RPC-over-RDMAサービスに代替の既知のポート番号を使用できます（セクション9を参照）。 ）。選択されたポートは、[RFC8166]で割り当てられたnetidsの下でRPCポートマッパーに登録される場合があります。
NFS versions 2 and 3 are typically deployed with several other protocols, sometimes referred to as "NFS auxiliary protocols". These are distinct RPC programs that define procedures that are not part of the NFS RPC program (100003). The Upper-Layer Bindings in this section apply to:
NFSバージョン2と3は通常、「NFS補助プロトコル」と呼ばれることもある他のいくつかのプロトコルと共に展開されます。これらは、NFS RPCプログラム（100003）の一部ではない手順を定義する別個のRPCプログラムです。このセクションの上位層バインディングは、以下に適用されます。
o versions 2 and 3 of the MOUNT RPC program (100005) [RFC1813];
o MOUNT RPCプログラムのバージョン2および3（100005）[RFC1813];
o versions 1, 3, and 4 of the NLM (Network Lock Manager) RPC program (100021) [RFC1813];
o NLM（Network Lock Manager）RPCプログラムのバージョン1、3、4（100021）[RFC1813];
o version 1 of the NSM (Network Status Monitor) RPC program (100024), which is described in Chapter 11 of [XNFS]; and
o NSM（Network Status Monitor）RPCプログラムのバージョン1（100024）。[XNFS]の第11章で説明されています。そして
o version 1 of the NFSACL RPC program (100227), which does not have a public definition. NFSACL is treated in this document as a de facto standard, as there are several interoperating implementations.
o NFSACL RPCプログラムのバージョン1（100227）。パブリック定義はありません。このドキュメントでは、相互運用する実装がいくつかあるため、NFSACLは事実上の標準として扱われます。
Historically, NFS/RDMA implementations have chosen to convey the MOUNT, NLM, and NSM protocols via TCP. To enable interoperation of these protocols when NFS/RDMA is in use, a Legacy NFS server MUST provide support for these protocols via TCP.
歴史的に、NFS / RDMA実装は、TCPを介してMOUNT、NLM、およびNSMプロトコルを伝達することを選択しました。 NFS / RDMAが使用されているときにこれらのプロトコルの相互運用を有効にするには、レガシーNFSサーバーは、TCPを介してこれらのプロトコルのサポートを提供する必要があります。
Legacy clients and servers that support the NFSACL RPC program typically convey NFSACL procedures on the same connection as the NFS RPC program (100003). This obviates the need for separate rpcbind queries to discover server support for this RPC program.
NFSACL RPCプログラムをサポートするレガシークライアントおよびサーバーは、通常、NFS RPCプログラム（100003）と同じ接続でNFSACL手順を伝達します。これにより、このRPCプログラムのサーバーサポートを検出するための個別のrpcbindクエリが不要になります。
Access Control Lists (ACLs) are typically small, but even large ACLs must be encoded and decoded to some degree. Thus, no data item in this upper-layer protocol is DDP-eligible.
通常、アクセス制御リスト（ACL）は小さいですが、大きなACLでもある程度エンコードおよびデコードする必要があります。したがって、この上位層プロトコルのデータ項目はDDP対応ではありません。
For NFSACL procedures whose Replies do not include an ACL object, the size of a Reply is determined directly from the NFSACL RPC program's XDR definition.
返信にACLオブジェクトが含まれていないNFSACLプロシージャの場合、返信のサイズはNFSACL RPCプログラムのXDR定義から直接決定されます。
There is no protocol-specified size limit for NFS version 3 ACLs, and there is no mechanism in either the NFSACL or NFS RPC programs for a Legacy client to ascertain the largest ACL a Legacy server can return. Legacy client implementations should choose a maximum size for ACLs based on their own internal limits.
NFSバージョン3 ACLにはプロトコル指定のサイズ制限はありません。また、レガシークライアントがレガシーサーバーが返すことができる最大のACLを確認するためのメカニズムは、NFSACLまたはNFS RPCプログラムのいずれにもありません。レガシークライアントの実装では、独自の内部制限に基づいてACLの最大サイズを選択する必要があります。
Because an NFSACL client cannot know in advance how large a returned ACL will be, it can use short Reply chunk retry when an NFSACL GETACL operation encounters a transport error.
NFSACLクライアントは、返されるACLの大きさを事前に知ることができないため、NFSACL GETACL操作でトランスポートエラーが発生した場合、短い応答チャンクの再試行を使用できます。
The Upper-Layer Binding specification in this section applies to versions of the NFS RPC program defined in NFS versions 4.0 [RFC7530], 4.1 [RFC5661], and 4.2 [RFC7862].
このセクションの上位層バインディング仕様は、NFSバージョン4.0 [RFC7530]、4.1 [RFC5661]、および4.2 [RFC7862]で定義されたバージョンのNFS RPCプログラムに適用されます。
Only the following XDR data items in the COMPOUND procedure of all NFS version 4 minor versions are DDP-eligible:
すべてのNFSバージョン4マイナーバージョンのCOMPOUNDプロシージャ内の次のXDRデータ項目のみがDDPに対応しています。
o The opaque data field in the WRITE4args structure
o WRITE4args構造体の不透明なデータフィールド
o The linkdata field of the NF4LNK arm in the createtype4 union o The opaque data field in the READ4resok structure
o createtype4共用体のNF4LNKアームのlinkdataフィールドo READ4resok構造体の不透明なデータフィールド
o The linkdata field in the READLINK4resok structure
o READLINK4resok構造体のlinkdataフィールド
Within NFS version 4, there are certain variable-length result data items whose maximum size cannot be estimated by clients reliably because there is no protocol-specified size limit on these arrays. These include:
NFSバージョン4では、特定の可変長の結果データ項目があり、これらの配列にはプロトコル指定のサイズ制限がないため、クライアントが最大サイズを確実に見積もることができません。これらには以下が含まれます：
o the attrlist4 field;
o attrlist4フィールド。
o fields containing ACLs such as fattr4_acl, fattr4_dacl, and fattr4_sacl;
o fattr4_acl、fattr4_dacl、fattr4_saclなどのACLを含むフィールド。
o fields in the fs_locations4 and fs_locations_info4 data structures; and
o fs_locations4およびfs_locations_info4データ構造のフィールド。そして
o fields opaque to the NFS version 4 protocol that pertain to pNFS (parallel NFS) layout metadata, such as loc_body, loh_body, da_addr_body, lou_body, lrf_body, fattr_layout_types, and fs_layout_types.
o loc_body、loh_body、da_addr_body、lou_body、lrf_body、fattr_layout_types、fs_layout_typesなど、pNFS（パラレルNFS）レイアウトメタデータに関連するNFSバージョン4プロトコルに対して不透明なフィールド。
The NFS version 4.0 protocol itself does not impose any bound on the size of NFS calls or responses.
NFSバージョン4.0プロトコル自体は、NFS呼び出しまたは応答のサイズに制限を課しません。
Some of the data items enumerated in Section 6.2 (in particular, the items related to ACLs and fs_locations) make it difficult to predict the maximum size of NFS version 4.0 Replies that interrogate variable-length fattr4 attributes. Client implementations might rely on their own internal architectural limits to constrain the reply size, but such limits are not always guaranteed to be reliable.
セクション6.2に列挙されている一部のデータ項目（特に、ACLとfs_locationsに関連する項目）は、可変長のfattr4属性を問い合わせるNFSバージョン4.0応答の最大サイズを予測することを困難にします。クライアントの実装は、独自の内部アーキテクチャの制限に依存して応答サイズを制約する場合がありますが、そのような制限が常に信頼できるとは限りません。
When an especially large fattr4 result is expected, a Reply chunk might be required. An NFS version 4.0 client can use short Reply chunk retry when an NFS COMPOUND containing a GETATTR operation encounters a transport error.
特に大きなfattr4の結果が予想される場合は、応答チャンクが必要になることがあります。 NFSバージョン4.0クライアントは、GETATTR操作を含むNFS COMPOUNDでトランスポートエラーが発生した場合、短い応答チャンク再試行を使用できます。
The use of NFS COMPOUND operations raises the possibility of requests that combine a non-idempotent operation (e.g., RENAME) with a GETATTR operation that requests one or more variable-length results. This combination should be avoided by ensuring that any GETATTR operation that requests a result of unpredictable length is sent in an NFS COMPOUND by itself.
NFS COMPOUND操作を使用すると、非べき等操作（RENAMEなど）と1つ以上の可変長の結果を要求するGETATTR操作を組み合わせる要求が発生する可能性があります。この組み合わせは、予測できない長さの結果を要求するGETATTR操作がそれ自体でNFS COMPOUNDで送信されるようにすることで回避する必要があります。
6.2.2. Reply Size Estimation for Minor Version 1 and Newer Minor Versions
6.2.2. マイナーバージョン1以降のマイナーバージョンの応答サイズの見積もり
In NFS version 4.1 and newer minor versions, the csa_fore_chan_attrs argument of the CREATE_SESSION operation contains a ca_maxresponsesize field. The value in this field can be taken as the absolute maximum size of replies generated by an NFS version 4.1 server.
NFSバージョン4.1以降のマイナーバージョンでは、CREATE_SESSION操作のcsa_fore_chan_attrs引数にca_maxresponsesizeフィールドが含まれています。このフィールドの値は、NFSバージョン4.1サーバーによって生成される応答の絶対最大サイズと見なすことができます。
This value can be used in cases where it is not possible to precisely estimate a reply size upper bound. In practice, objects such as ACLs, named attributes, layout bodies, and security labels are much smaller than this maximum.
この値は、応答サイズの上限を正確に見積もることができない場合に使用できます。実際には、ACL、名前付き属性、レイアウト本文、セキュリティラベルなどのオブジェクトは、この最大値よりもはるかに小さくなります。
NFS version 4 servers are required to listen on TCP port 2049, and they are not required to register with an rpcbind service [RFC7530].
NFSバージョン4サーバーは、TCPポート2049でリッスンする必要があり、rpcbindサービス[RFC7530]に登録する必要はありません。
Therefore, an NFS version 4 server supporting RPC-over-RDMA version 1 MUST use the alternative well-known port number for its RPC-over-RDMA service (see Section 9). Clients SHOULD connect to this well-known port without consulting the RPC portmapper (as for NFS version 4 on TCP transports).
したがって、RPC-over-RDMAバージョン1をサポートするNFSバージョン4サーバーは、RPC-over-RDMAサービスに代替の既知のポート番号を使用する必要があります（セクション9を参照）。クライアントは、RPCポートマッパーを参照せずにこの既知のポートに接続する必要があります（TCPトランスポート上のNFSバージョン4の場合）。
An NFS version 4 COMPOUND procedure can contain more than one operation that carries a DDP-eligible data item. An NFS version 4 client provides XDR Position values in each Read chunk to disambiguate which chunk is associated with which argument data item. However, NFS version 4 server and client implementations must agree in advance on how to pair Write chunks with returned result data items.
NFSバージョン4のCOMPOUNDプロシージャには、DDP対応のデータアイテムを運ぶ複数の操作を含めることができます。 NFSバージョン4クライアントは、各チャンクがどの引数データ項目に関連付けられているかを明確にするために、各読み取りチャンクにXDR位置値を提供します。ただし、NFSバージョン4のサーバーとクライアントの実装では、書き込みチャンクと返された結果データアイテムをペアにする方法について事前に合意する必要があります。
In the following list, a "READ operation" refers to any NFS version 4 operation that has a DDP-eligible result data item. The mechanism specified in Section 4.3.2 of [RFC8166] is applied to this class of operations:
以下のリストでは、「READ操作」は、DDP適格な結果データ項目を持つすべてのNFSバージョン4操作を指します。 [RFC8166]のセクション4.3.2で指定されたメカニズムは、このクラスの操作に適用されます。
o If an NFS version 4 client wishes all DDP-eligible items in an NFS Reply to be conveyed inline, it leaves the Write list empty.
o NFSバージョン4クライアントが、NFS応答内のすべてのDDP対応アイテムをインラインで伝達したい場合、書き込みリストは空のままにします。
o The first chunk in the Write list MUST be used by the first READ operation in an NFS version 4 COMPOUND procedure. The next Write chunk is used by the next READ operation, and so on.
o 書き込みリストの最初のチャンクは、NFSバージョン4 COMPOUNDプロシージャの最初のREAD操作で使用する必要があります。次の書き込みチャンクは、次のREAD操作で使用されます。
o If an NFS version 4 client has provided a matching non-empty Write chunk, then the corresponding READ operation MUST return its DDP-eligible data item using that chunk.
o NFSバージョン4クライアントが一致する空でない書き込みチャンクを提供している場合、対応するREAD操作は、そのチャンクを使用してDDP対応のデータ項目を返さなければなりません（MUST）。
o If an NFS version 4 client has provided an empty matching Write chunk, then the corresponding READ operation MUST return all of its result data items inline.
o NFSバージョン4クライアントが一致する空の書き込みチャンクを提供している場合、対応するREAD操作はその結果データ項目のすべてをインラインで返す必要があります。
o If a READ operation returns a union arm that does not contain a DDP-eligible result, and the NFS version 4 client has provided a matching non-empty Write chunk, an NFS version 4 server MUST return an empty Write chunk in that Write list position.
o READ操作がDDP対応の結果を含まないユニオンアームを返し、NFSバージョン4クライアントが対応する空でない書き込みチャンクを提供した場合、NFSバージョン4サーバーはその書き込みリストの位置に空の書き込みチャンクを返す必要があります。
o If there are more READ operations than Write chunks, then remaining NFS READ operations in an NFS version 4 COMPOUND that have no matching Write chunk MUST return their results inline.
o 書き込みチャンクよりも多くのREAD操作がある場合、NFSバージョン4 COMPOUNDで残りのNFS READ操作は、一致する書き込みチャンクがないため、結果をインラインで返す必要があります。
The RPC-over-RDMA version 1 protocol does not place any limit on the number of chunks or segments that may appear in Read or Write lists. However, for various reasons, NFS version 4 server implementations often have practical limits on the number of chunks or segments they are prepared to process in a single RPC transaction conveyed via RPC-over-RDMA version 1.
RPC-over-RDMAバージョン1プロトコルでは、読み取りリストまたは書き込みリストに表示される可能性があるチャンクまたはセグメントの数に制限はありません。ただし、さまざまな理由により、NFSバージョン4サーバーの実装では、RPC-over-RDMAバージョン1を介して伝達される単一のRPCトランザクションで処理するように準備されているチャンクまたはセグメントの数に実際的な制限があることがよくあります。
These implementation limits are especially important when Kerberos integrity or privacy is in use [RFC7861]. Generic Security Service (GSS) services increase the size of credential material in RPC headers, potentially requiring more frequent use of Long messages. This can increase the complexity of chunk lists independent of the NFS version 4 COMPOUND being conveyed.
これらの実装制限は、Kerberosの整合性またはプライバシーが使用されている場合に特に重要です[RFC7861]。 Generic Security Service（GSS）サービスは、RPCヘッダー内の資格情報のサイズを大きくするため、長いメッセージをより頻繁に使用する必要がある可能性があります。これにより、伝達されるNFSバージョン4 COMPOUNDに関係なく、チャンクリストの複雑さが増す可能性があります。
In the absence of explicit knowledge of the server's limits, NFS version 4 clients SHOULD follow the prescriptions listed below when constructing RPC-over-RDMA version 1 messages. NFS version 4 servers MUST accept and process such requests.
サーバーの制限についての明確な知識がない場合、NFSバージョン4クライアントは、RPC-over-RDMAバージョン1メッセージを構築するときに、以下に示す規定に従う必要があります（SHOULD）。 NFSバージョン4サーバーは、そのような要求を受け入れて処理する必要があります。
o The Read list can contain either a Position Zero Read chunk, one Read chunk with a non-zero Position, or both.
o 読み取りリストには、位置ゼロ読み取りチャンク、ゼロ以外の位置を持つ1つの読み取りチャンク、またはその両方を含めることができます。
o The Write list can contain no more than one Write chunk.
o 書き込みリストには、書き込みチャンクを1つだけ含めることができます。
o Any chunk can contain up to sixteen RDMA segments.
o どのチャンクにも最大16個のRDMAセグメントを含めることができます。
NFS version 4 clients wishing to send more complex chunk lists can provide configuration interfaces to bound the complexity of NFS version 4 COMPOUNDs, limit the number of elements in scatter-gather operations, and avoid other sources of chunk overruns at the receiving peer.
より複雑なチャンクリストを送信するNFSバージョン4クライアントは、NFSバージョン4 COMPOUNDの複雑さを制限する構成インターフェイスを提供し、スキャッターギャザー操作の要素数を制限し、受信ピアでのチャンクオーバーランの他のソースを回避できます。
An NFS version 4 server SHOULD return one of the following responses to a client that has sent an RPC transaction via RPC-over-RDMA version 1, which cannot be processed due to chunk list complexity limits on the server:
NFSバージョン4サーバーは、RPC-over-RDMAバージョン1を介してRPCトランザクションを送信したクライアントに次の応答のいずれかを返す必要があります（SHOULD）。サーバーのチャンクリストの複雑さの制限により処理できません。
o A problem is detected by the transport layer while parsing the transport header in an RPC Call message. The server responds with an RDMA_ERROR message with the err field set to ERR_CHUNK.
o RPC Callメッセージのトランスポートヘッダーの解析中に、トランスポート層によって問題が検出されました。サーバーは、errフィールドをERR_CHUNKに設定したRDMA_ERRORメッセージで応答します。
o A problem is detected during XDR decoding of the RPC Call message while the RPC layer reassembles the call's XDR stream. The server responds with an RPC Reply with its "reply_stat" field set to MSG_ACCEPTED and its "accept_stat" field set to GARBAGE_ARGS.
o RPCレイヤーが通話のXDRストリームを再構成しているときに、RPC通話メッセージのXDRデコード中に問題が検出されました。サーバーは、「reply_stat」フィールドがMSG_ACCEPTEDに設定され、「accept_stat」フィールドがGARBAGE_ARGSに設定されたRPC応答で応答します。
After receiving one of these errors, an NFS version 4 client SHOULD NOT retransmit the failing request, as the result would be the same error. It SHOULD immediately terminate the RPC transaction associated with the XID in the RPC Reply.
これらのエラーの1つを受け取った後、NFSバージョン4クライアントは、同じエラーになるため、失敗した要求を再送信してはなりません（SHOULD NOT）。 RPC応答のXIDに関連付けられたRPCトランザクションを直ちに終了する必要があります（SHOULD）。
The following example shows a Write list with three Write chunks: A, B, and C. The NFS version 4 server consumes the provided Write chunks by writing the results of the designated operations in the COMPOUND request (READ and READLINK) back to each chunk.
次の例は、A、B、Cの3つの書き込みチャンクを持つ書き込みリストを示しています。NFSバージョン4サーバーは、指定された操作の結果をCOMPOUNDリクエスト（READおよびREADLINK）で各チャンクに書き戻すことにより、提供された書き込みチャンクを消費します。 。
Write list:
リストを書く：
A --> B --> C
NFS version 4 COMPOUND request:
NFSバージョン4 COMPOUND要求：
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ
| | |
v v v
A B C
If the NFS version 4 client does not want to have the READLINK result returned via RDMA, it provides an empty Write chunk for buffer B to indicate that the READLINK result must be returned inline.
NFSバージョン4クライアントがRDMAを介してREADLINK結果を返さないようにしたい場合、バッファーBに空の書き込みチャンクを提供して、READLINK結果をインラインで返さなければならないことを示します。
The NFS version 4 family of protocols support server-initiated callbacks to notify NFS version 4 clients of events such as recalled delegations.
NFSバージョン4のプロトコルファミリは、サーバーが開始するコールバックをサポートし、リコールされた委任などのイベントをNFSバージョン4クライアントに通知します。
NFS version 4.0 implementations typically employ a separate TCP connection to handle callback operations, even when the forward channel uses an RPC-over-RDMA version 1 transport.
NFSバージョン4.0の実装では、通常、フォワードチャネルがRPC-over-RDMAバージョン1トランスポートを使用する場合でも、コールバック操作を処理するために個別のTCP接続を使用します。
No operation in the NFS version 4.0 callback RPC program conveys a significant data payload. Therefore, no XDR data items in this RPC program are DDP-eligible.
NFSバージョン4.0コールバックRPCプログラムでの操作は、重要なデータペイロードを伝えません。したがって、このRPCプログラムのXDRデータ項目はDDPに対応していません。
A CB_RECALL Reply is small and fixed in size. The CB_GETATTR Reply contains a variable-length fattr4 data item. See Section 6.2.1 for a discussion of reply size prediction for this data item.
CB_RECALL応答は小さく、サイズが固定されています。 CB_GETATTR応答には、可変長のfattr4データ項目が含まれています。このデータ項目の応答サイズ予測については、セクション6.2.1を参照してください。
An NFS version 4.0 client advertises netids and ad hoc port addresses for contacting its NFS version 4.0 callback service using the SETCLIENTID operation.
NFSバージョン4.0クライアントは、SETCLIENTID操作を使用してNFSバージョン4.0コールバックサービスに接続するために、netidおよびアドホックポートアドレスをアドバタイズします。
In NFS version 4.1 and newer minor versions, callback operations may appear on the same connection as is used for NFS version 4 forward channel client requests. NFS version 4 clients and servers MUST use the approach described in [RFC8167] when backchannel operations are conveyed on RPC-over-RDMA version 1 transports.
NFSバージョン4.1以降のマイナーバージョンでは、NFSバージョン4のフォワードチャネルクライアント要求に使用されるのと同じ接続でコールバック操作が表示される場合があります。 NFSバージョン4のクライアントとサーバーは、RPC-over-RDMAバージョン1トランスポートでバックチャネル操作が伝達される場合、[RFC8167]で説明されているアプローチを使用する必要があります。
The csa_back_chan_attrs argument of the CREATE_SESSION operation contains a ca_maxresponsesize field. The value in this field can be taken as the absolute maximum size of backchannel replies generated by a replying NFS version 4 client.
CREATE_SESSION操作のcsa_back_chan_attrs引数には、ca_maxresponsesizeフィールドが含まれています。このフィールドの値は、応答するNFSバージョン4クライアントによって生成されるバックチャネル応答の絶対最大サイズと見なすことができます。
There are no DDP-eligible data items in callback procedures defined in NFS versions 4.1 or 4.2. However, some callback operations (such as messages that convey device ID information) can be large, in which case, a Long Call or Reply might be required.
NFSバージョン4.1または4.2で定義されているコールバックプロシージャには、DDP対応のデータ項目はありません。ただし、一部のコールバック操作（デバイスID情報を伝えるメッセージなど）は大きくなる可能性があり、その場合は、ロングコールまたは応答が必要になることがあります。
When an NFS version 4.1 client can support Long Calls in its backchannel, it reports a backchannel ca_maxrequestsize that is larger than the connection's inline thresholds. Otherwise, an NFS version 4 server MUST use only Short messages to convey backchannel operations.
NFSバージョン4.1クライアントがバックチャネルでロングコールをサポートできる場合、接続のインラインしきい値よりも大きいバックチャネルca_maxrequestsizeを報告します。それ以外の場合、NFSバージョン4サーバーは、バックチャネル操作を伝えるためにShortメッセージのみを使用する必要があります。
The presence of an NFS session (defined in [RFC5661]) has no effect on the operation of RPC-over-RDMA version 1. None of the operations introduced to support NFS sessions (e.g., the SEQUENCE operation) contain DDP-eligible data items. There is no need to match the number of session slots with the number of available RPC-over-RDMA credits.
NFSセッションの存在（[RFC5661]で定義）は、RPC-over-RDMAバージョン1の操作に影響を与えません。NFSセッションをサポートするために導入された操作（たとえば、SEQUENCE操作）には、DDP対応のデータ項目は含まれていません。 。セッションスロットの数を、使用可能なRPC-over-RDMAクレジットの数と一致させる必要はありません。
However, there are a few new cases where an RPC transaction can fail. For example, in response to an RPC request, a requester might receive an RDMA_ERROR message with an rdma_err value of ERR_CHUNK. These situations are not different from existing RPC errors, which an NFS session implementation is already prepared to handle for other transports. And as with other transports during such a failure, there might be no SEQUENCE result available to the requester to distinguish whether failure occurred before or after the requested operations were executed on the responder.
ただし、RPCトランザクションが失敗する可能性のある新しいケースがいくつかあります。たとえば、RPC要求への応答として、リクエスタはrdma_err値がERR_CHUNKのRDMA_ERRORメッセージを受信する場合があります。これらの状況は、NFSセッション実装が他のトランスポートを処理するためにすでに準備されている既存のRPCエラーと同じです。また、このような障害時の他のトランスポートと同様に、要求側が要求された操作が応答側で実行される前または後に障害が発生したかどうかを区別するために要求側が利用できるSEQUENCE結果がない場合があります。
When a transport error occurs (e.g., RDMA_ERROR), the requester proceeds as usual to match the incoming XID value to a waiting RPC Call. The RPC transaction is terminated, and the result status is reported to the upper-layer protocol. The requester's session implementation then determines the session ID and slot for the failed request and performs slot recovery to make that slot usable again. If this were not done, that slot could be rendered permanently unavailable.
トランスポートエラーが発生すると（RDMA_ERRORなど）、リクエスターは通常どおり、着信XID値を待機中のRPCコールと照合します。 RPCトランザクションが終了し、結果のステータスが上位層プロトコルに報告されます。次に、リクエスターのセッション実装は、失敗した要求のセッションIDとスロットを判別し、スロットのリカバリーを実行して、そのスロットを再び使用可能にします。これが行われなかった場合、そのスロットは永続的に使用不可になる可能性があります。
When an NFS session is not present (for example, when NFS version 4.0 is in use), a transport error does not provide an indication of whether the server has processed the arguments of the RPC Call or whether the server has accessed or modified client memory associated with that RPC.
NFSセッションが存在しない場合（NFSバージョン4.0が使用されている場合など）、トランスポートエラーは、サーバーがRPC呼び出しの引数を処理したかどうか、またはサーバーがクライアントメモリにアクセスまたは変更したかどうかを示しませんそのRPCに関連付けられています。
Section 3.1 of [RFC7530] states:
[RFC7530]のセクション3.1は次のように述べています。
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP).
NFSv4実装がIPネットワークプロトコルでの動作をサポートする場合、NFSとIPの間でサポートされるトランスポート層は、ネットワークの輻輳を回避するために指定されたIETF標準トランスポートプロトコルでなければなりません。このようなトランスポートには、TCPおよびStream Control Transmission Protocol（SCTP）が含まれます。
Section 2.9.1 of [RFC5661] also states:
[RFC5661]のセクション2.9.1にも次のように記載されています。
Even if NFSv4.1 is used over a non-IP network protocol, it is RECOMMENDED that the transport support congestion control.
NFSv4.1が非IPネットワークプロトコルで使用されている場合でも、トランスポートが輻輳制御をサポートすることが推奨されます。
It is permissible for a connectionless transport to be used under NFSv4.1; however, reliable and in-order delivery of data combined with congestion control by the connectionless transport is REQUIRED. As a consequence, UDP by itself MUST NOT be used as an NFSv4.1 transport.
コネクションレス型トランスポートをNFSv4.1で使用することは許可されています。ただし、コネクションレス型トランスポートによる輻輳制御と組み合わせた信頼性の高い順序どおりのデータ配信が必要です。その結果、UDP自体をNFSv4.1トランスポートとして使用してはなりません（MUST NOT）。
RPC-over-RDMA version 1 is constructed on a platform of RDMA Reliable Connections [RFC8166] [RFC5041]. RDMA Reliable Connections are reliable, connection-oriented transports that guarantee in-order delivery, thus meeting all above requirements for NFS version 4 transports.
RPC-over-RDMAバージョン1は、RDMA Reliable Connections [RFC8166] [RFC5041]のプラットフォームで構築されています。 RDMA Reliable Connectionsは、順序どおりの配信を保証する信頼性の高い接続指向のトランスポートであり、NFSバージョン4トランスポートの上記の要件をすべて満たしています。
NFS version 4 client implementations often rely on a transport-layer keep-alive mechanism to detect when an NFS version 4 server has become unresponsive. When an NFS server is no longer responsive, client-side keep-alive terminates the connection, which in turn triggers reconnection and RPC retransmission.
NFSバージョン4クライアントの実装では、NFSバージョン4サーバーが応答しなくなったことをトランスポート層のキープアライブメカニズムに依存して検出することがよくあります。 NFSサーバーが応答しなくなると、クライアント側のキープアライブが接続を終了し、その結果、再接続とRPC再送信がトリガーされます。
Some RDMA transports (such as Reliable Connections on InfiniBand) have no keep-alive mechanism. Without a disconnect or new RPC traffic, such connections can remain alive long after an NFS server has become unresponsive. Once an NFS client has consumed all available RPC-over-RDMA credits on that transport connection, it will forever await a Reply before sending another RPC request.
一部のRDMAトランスポート（InfiniBandのReliable Connectionsなど）には、キープアライブメカニズムがありません。切断または新しいRPCトラフィックがなければ、そのような接続はNFSサーバーが応答しなくなった後も長く存続できます。 NFSクライアントがそのトランスポート接続で使用可能なすべてのRPC-over-RDMAクレジットを消費すると、別のRPC要求を送信する前に永久に応答を待ちます。
NFS version 4 clients SHOULD reserve one RPC-over-RDMA credit to use for a periodic server or connection health assessment. This credit can be used to drive an RPC request on an otherwise idle connection, triggering either a quick affirmative server response or immediate connection termination.
NFSバージョン4クライアントは、定期的なサーバーまたは接続の正常性評価に使用するRPC-over-RDMAクレジットを1つ予約する必要があります（SHOULD）。このクレジットを使用して、それ以外の場合はアイドル状態の接続でRPC要求を実行し、迅速な肯定サーバー応答または即時接続終了のいずれかをトリガーできます。
In addition to network partition and request loss scenarios, RPC-over-RDMA transport connections can be terminated when a Transport header is malformed, Reply messages are larger than receive resources, or when too many RPC-over-RDMA messages are sent at once. In such cases:
ネットワークパーティションと要求損失のシナリオに加えて、トランスポートヘッダーの形式が正しくない場合、応答メッセージが受信リソースよりも大きい場合、または一度に送信されるRPC-over-RDMAメッセージが多すぎる場合、RPC-over-RDMAトランスポート接続を終了できます。そのような場合：
o If there is a transport error indicated (i.e., RDMA_ERROR) before the disconnect or instead of a disconnect, the requester MUST respond to that error as prescribed by the specification of the RPC transport. Then, the NFS version 4 rules for handling retransmission apply.
o 切断前または切断の代わりにトランスポートエラー（RDMA_ERRORなど）が示されている場合、リクエスタはRPCトランスポートの仕様で規定されているようにそのエラーに応答する必要があります。次に、再送信を処理するためのNFSバージョン4のルールが適用されます。
o If there is a transport disconnect and the responder has provided no other response for a request, then only the NFS version 4 rules for handling retransmission apply.
o トランスポート切断があり、レスポンダが要求に対して他の応答を提供しなかった場合、再送信を処理するためのNFSバージョン4ルールのみが適用されます。
RPC programs such as NFS are required to have an Upper-Layer Binding specification to interoperate on RPC-over-RDMA version 1 transports [RFC8166]. Via IETF standards action, the Upper-Layer Binding specified in this document can be extended to cover (a) versions of the NFS version 4 protocol specified after NFS version 4 minor version 2 or (b) separately published extensions to an existing NFS version 4 minor version, as described in [RFC8178].
NFSなどのRPCプログラムには、RPC-over-RDMAバージョン1トランスポート[RFC8166]で相互運用するための上位層バインディング仕様が必要です。 IETF標準アクションを介して、このドキュメントで指定されている上位層バインディングを拡張して、（a）NFSバージョン4マイナーバージョン2の後に指定されたNFSバージョン4プロトコルのバージョン、または（b）既存のNFSバージョン4に対して別途公開された拡張機能をカバーできます。 [RFC8178]で説明されているマイナーバージョン。
RPC-over-RDMA version 1 supports all RPC security models, including RPCSEC_GSS security and transport-level security [RFC7861]. The choice of what Direct Data Placement mechanism to convey RPC argument and results does not affect this, since it changes only the method of data transfer. Because this document defines only the binding of the NFS protocols atop [RFC8166], all relevant security considerations are, therefore, to be described at that layer.
RPC-over-RDMAバージョン1は、RPCSEC_GSSセキュリティおよびトランスポートレベルセキュリティ[RFC7861]を含むすべてのRPCセキュリティモデルをサポートします。 RPCの引数と結果を伝えるための直接データ配置メカニズムの選択は、データ転送の方法のみを変更するため、これには影響しません。このドキュメントでは、[RFC8166]の上にあるNFSプロトコルのバインディングのみを定義しているため、関連するセキュリティに関するすべての考慮事項は、その層で説明する必要があります。
The use of Direct Data Placement in NFS introduces a need for an additional port number assignment for networks that share traditional UDP and TCP port spaces with RDMA services. The iWARP protocol is such an example [RFC5041] [RFC5040].
NFSで直接データ配置を使用すると、従来のUDPおよびTCPポートスペースをRDMAサービスと共有するネットワークに追加のポート番号を割り当てる必要が生じます。 iWARPプロトコルはそのような例です[RFC5041] [RFC5040]。
For this purpose, a set of transport protocol port number assignments is specified by this document. IANA has assigned the following ports for NFS/RDMA in the IANA port registry, according to the guidelines described in [RFC6335].
この目的のために、トランスポートプロトコルのポート番号割り当てのセットがこのドキュメントで指定されています。 [RFC6335]で説明されているガイドラインに従って、IANAはIANAポートレジストリでNFS / RDMAに次のポートを割り当てました。
nfsrdma 20049 tcp Network File System (NFS) over RDMA nfsrdma 20049 udp Network File System (NFS) over RDMA nfsrdma 20049 sctp Network File System (NFS) over RDMA
nfsrdma 20049 tcpネットワークファイルシステム（NFS）over RDMA nfsrdma 20049 udpネットワークファイルシステム（NFS）over RDMA nfsrdma 20049 sctpネットワークファイルシステム（NFS）over RDMA
This document is listed as the reference for the nfsrdma port assignments.
このドキュメントは、nfsrdmaポート割り当てのリファレンスとして記載されています。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, DOI 10.17487/RFC1833, August 1995, <https://www.rfc-editor.org/info/rfc1833>.
[RFC1833] Srinivasan、R。、「Binding Protocols for ONC RPC Version 2」、RFC 1833、DOI 10.17487 / RFC1833、1995年8月、<https://www.rfc-editor.org/info/rfc1833>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <https://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、DOI 10.17487 / RFC5661、 2010年1月、<https://www.rfc-editor.org/info/rfc5661>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、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>。
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]ヘインズ、T。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン2プロトコル」、RFC 7862、DOI 10.17487 / RFC7862、2016年11月、<https://www.rfc-editor.org/info/rfc7862 >。
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, <https://www.rfc-editor.org/info/rfc8166>.
[RFC8166] Lever、C.、Ed。、Simpson、W。、およびT. Talpey、「リモートプロシージャコールバージョン1のリモートダイレクトメモリアクセストランスポート」、RFC 8166、DOI 10.17487 / RFC8166、2017年6月、<https：/ /www.rfc-editor.org/info/rfc8166>。
[RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC-over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167, June 2017, <https://www.rfc-editor.org/info/rfc8167>.
[RFC8167]レバー、C。、「RPC-over-RDMAトランスポートの双方向リモートプロシージャコール」、RFC 8167、DOI 10.17487 / RFC8167、2017年6月、<https://www.rfc-editor.org/info/rfc8167> 。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, DOI 10.17487/RFC1094, March 1989, <https://www.rfc-editor.org/info/rfc1094>.
[RFC1094] Nowicki、B。、「NFS：Network File System Protocol specification」、RFC 1094、DOI 10.17487 / RFC1094、1989年3月、<https://www.rfc-editor.org/info/rfc1094>。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <https://www.rfc-editor.org/info/rfc1813>.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、DOI 10.17487 / RFC1813、1995年6月、<https://www.rfc-editor.org/ info / rfc1813>。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, DOI 10.17487/RFC5040, October 2007, <https://www.rfc-editor.org/info/rfc5040>.
[RFC5040] Recio、R.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「A Remote Direct Memory Access Protocol Specification」、RFC 5040、DOI 10.17487 / RFC5040、2007年10月、< https://www.rfc-editor.org/info/rfc5040>。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, DOI 10.17487/RFC5041, October 2007, <https://www.rfc-editor.org/info/rfc5041>.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「Reliable Transportsを介した直接データ配置」、RFC 5041、DOI 10.17487 / RFC5041、2007年10月、<https：// www。 rfc-editor.org/info/rfc5041>。
[RFC5666] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", RFC 5666, DOI 10.17487/RFC5666, January 2010, <https://www.rfc-editor.org/info/rfc5666>.
[RFC5666] Talpey、T。およびB. Callaghan、「リモートプロシージャコール用のリモートダイレクトメモリアクセストランスポート」、RFC 5666、DOI 10.17487 / RFC5666、2010年1月、<https://www.rfc-editor.org/info/ rfc5666>。
[RFC5667] Talpey, T. and B. Callaghan, "Network File System (NFS) Direct Data Placement", RFC 5667, DOI 10.17487/RFC5667, January 2010, <https://www.rfc-editor.org/info/rfc5667>.
[RFC5667] Talpey、T。およびB. Callaghan、「Network File System（NFS）Direct Data Placement」、RFC 5667、DOI 10.17487 / RFC5667、2010年1月、<https://www.rfc-editor.org/info/ rfc5667>。
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, <https://www.rfc-editor.org/info/rfc8178>.
[RFC8178] Noveck、D。、「Rules for NFSv4 Extensions and Minor Versions」、RFC 8178、DOI 10.17487 / RFC8178、2017年7月、<https://www.rfc-editor.org/info/rfc8178>。
[XNFS] The Open Group, "Protocols for Interworking: XNFS, Version 3W", Document Number C702, ISBN 1-85912-184-5, February 1998.
[XNFS] The Open Group、「Protocols for Interworking：XNFS、Version 3W」、ドキュメント番号C702、ISBN 1-85912-184-5、1998年2月。
Corrections and updates made necessary by new language in [RFC8166] have been introduced. For example, references to deprecated features of RPC-over-RDMA version 1 (such as RDMA_MSGP) and the use of the Read list for handling RPC Replies have been removed. The term "mapping" has been replaced with the term "binding" or "Upper-Layer Binding" throughout the document. Material that duplicates what is in [RFC8166] has been deleted.
[RFC8166]の新しい言語で必要になった修正と更新が導入されました。たとえば、RPC-over-RDMAバージョン1の非推奨機能（RDMA_MSGPなど）への参照と、RPC応答を処理するための読み取りリストの使用は削除されました。 「マッピング」という用語は、ドキュメント全体で「バインディング」または「上位層バインディング」という用語に置き換えられました。 [RFC8166]と重複する資料は削除されました。
Material required by [RFC8166] for Upper-Layer Bindings that was not present in [RFC5667] has been added. A complete discussion of reply size estimation has been introduced for all protocols covered by the Upper-Layer Bindings in this document.
[RFC5667]にはなかった、[RFC8166]が必要とする上位層バインディング用の資料が追加されました。このドキュメントでは、上位層バインディングによってカバーされるすべてのプロトコルについて、応答サイズの推定に関する完全な説明が導入されています。
Technical corrections have been made. For example, the mention of 12KB and 36KB inline thresholds has been removed. The reference to a nonexistent NFS version 4 SYMLINK operation has been replaced.
技術的な修正が行われました。たとえば、12KBと36KBのインラインしきい値についての言及は削除されました。存在しないNFSバージョン4 SYMLINK操作への参照が置き換えられました。
The discussion of NFS version 4 COMPOUND handling has been completed. Some changes were made to the algorithm for matching DDP-eligible results to Write chunks.
NFSバージョン4のCOMPOUND処理の説明は完了しました。 DDP対応の結果を書き込みチャンクに一致させるためのアルゴリズムにいくつかの変更が加えられました。
Requirements to ignore extra Read or Write chunks have been removed from the NFS versions 2 and 3 Upper-Layer Binding, as they conflict with [RFC8166].
余分な読み取りまたは書き込みチャンクを無視する要件は、[RFC8166]と競合するため、NFSバージョン2および3上位層バインディングから削除されました。
A section discussing NFS version 4 retransmission and connection loss has been added.
NFSバージョン4の再送信と接続の切断について説明するセクションが追加されました。
The following additional improvements have been made, relative to [RFC5667]:
[RFC5667]に関連して、次の追加の改善が行われました。
o An explicit discussion of NFS versions 4.0 and 4.1 backchannel operation have replaced the previous treatment of callback operations.
o NFSバージョン4.0および4.1のバックチャネル操作についての明確な議論は、以前のコールバック操作の扱いを置き換えました。
o A section describing considerations when an NFS session is in use has been added.
o NFSセッションが使用されている場合の考慮事項を説明するセクションが追加されました。
o An Upper-Layer Binding for NFS version 4.2 has been added.
o NFSバージョン4.2の上位層バインディングが追加されました。
o A section suggesting a mechanism for periodically assessing connection health has been introduced.
o 接続状態を定期的に評価するメカニズムを提案するセクションが導入されました。
o Ambiguous or erroneous uses of key words from RFC 2119 have been corrected.
o RFC 2119のキーワードのあいまいなまたは誤った使用が修正されました。
o References to obsolete RFCs have been updated.
o 廃止されたRFCへの参照が更新されました。
o An IANA Considerations section has been added, which specifies the port assignments for NFS/RDMA. This replaces the example assignment that appeared in [RFC5666].
o NFS / RDMAのポート割り当てを指定するIANAの考慮事項セクションが追加されました。これは、[RFC5666]に現れた割り当て例を置き換えます。
o Code excerpts have been removed, and figures have been modernized.
o コードの抜粋が削除され、数字が近代化されました。
Acknowledgments
謝辞
The author gratefully acknowledges the work of Brent Callaghan and Tom Talpey on the original NFS Direct Data Placement specification [RFC5667]. Tom contributed the text of Section 6.4.2.
著者は、元のNFS Direct Data Placement仕様[RFC5667]に関するBrent CallaghanとTom Talpeyの作業に感謝します。トムはセクション6.4.2のテキストを寄稿しました。
Dave Noveck provided an excellent review, constructive suggestions, and consistent navigational guidance throughout the process of drafting this document. Dave contributed the text of Sections 6.6 and 7 and insisted on precise discussion of reply size estimation.
Dave Noveckは、このドキュメントの草案作成プロセス全体を通じて、優れたレビュー、建設的な提案、および一貫したナビゲーションガイダンスを提供しました。 Daveはセクション6.6と7のテキストを寄稿し、返信サイズの推定に関する正確な議論を主張しました。
Thanks to Karen Deitke for her sharp observations about idempotency, NFS COMPOUNDs, and NFS sessions.
べき等性、NFS COMPOUND、NFSセッションに関する鋭い観察をしてくれたKaren Deitkeに感謝します。
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Working Group Chair and Document Shepherd Spencer Shepler, and NFSV4 Working Group Secretary Thomas Haynes for their support. The author also wishes to thank Bill Baker and Greg Marsden for their support of this work.
Transport Area Director Spencer Dawkins、NFSV4 Working Group Chair and Document Shepherd Spencer Shepler、およびNFSV4 Working Group Secretary Thomas Haynesのサポートに特に感謝します。著者はまた、この作業を支援してくれたBill BakerとGreg Marsdenに感謝します。
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