[要約] RFC 5667は、NFS Direct Data Placementの仕様を定義しており、データの直接配置を可能にする。目的は、NFSプロトコルのパフォーマンスを向上させ、ネットワーク上でのデータ転送を効率化すること。
Internet Engineering Task Force (IETF) T. Talpey
Request for Comments: 5667 Unaffiliated
Category: Standards Track B. Callaghan
ISSN: 2070-1721 Apple
January 2010
Network File System (NFS) Direct Data Placement
ネットワークファイルシステム（NFS）直接データ配置
Abstract
概要
This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport.
このドキュメントでは、RPC/RDMAトランスポートプロトコルによってサポートされているリモートダイレクトメモリアクセス（RDMA）操作に、さまざまなネットワークファイルシステム（NFS）バージョンのバインディングを定義します。これは、このようなRDMAトランスポートを介したNFSバージョン2、3、4、および4.1の実装のために、サーバー開始のRDMA操作をクライアント支援バッファーに使用することにより、直接データ配置の使用を説明しています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5667.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5667で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. Transfers from NFS Client to NFS Server .........................3
3. Transfers from NFS Server to NFS Client .........................3
4. NFS Versions 2 and 3 Mapping ....................................4
5. NFS Version 4 Mapping ...........................................6
5.1. NFS Version 4 Callbacks ....................................7
6. Port Usage Considerations .......................................8
7. Security Considerations .........................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
The Remote Direct Memory Access (RDMA) Transport for Remote Procedure Call (RPC) [RFC5666] allows an RPC client application to post buffers in a Chunk list for specific arguments and results from an RPC call. The RDMA transport header conveys this list of client buffer addresses to the server where the application can associate them with client data and use RDMA operations to transfer the results directly to and from the posted buffers on the client. The client and server must agree on a consistent mapping of posted buffers to RPC. This document details the mapping for each version of the NFS protocol [RFC1094] [RFC1813] [RFC3530] [RFC5661].
リモートダイレクトメモリアクセス（RDMA）リモートプロシージャコール（RPC）[RFC5666]のためのトランスポートにより、RPCクライアントアプリケーションは、特定の引数とRPCコールの結果のためにチャンクリストにバッファーを投稿できます。RDMAトランスポートヘッダーは、クライアントバッファーアドレスのこのリストをサーバーに伝え、アプリケーションがクライアントデータに関連付け、RDMA操作を使用して結果をクライアントのバッファーと直接転送できます。クライアントとサーバーは、RPCへの投稿されたバッファーの一貫したマッピングに同意する必要があります。このドキュメントは、NFSプロトコル[RFC1094] [RFC1813] [RFC3530] [RFC5661]の各バージョンのマッピングのマッピングについて詳しく説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The RDMA Read list, in the RDMA transport header, allows an RPC client to marshal RPC call data selectively. Large chunks of data, such as the file data of an NFS WRITE request, MAY be referenced by an RDMA Read list and be moved efficiently and directly placed by an RDMA Read operation initiated by the server.
RDMAトランスポートヘッダーのRDMA読み取りリストにより、RPCクライアントはRPCコールデータを選択的に元に戻すことができます。NFS書き込み要求のファイルデータなどの大量のデータは、RDMA読み取りリストで参照され、サーバーによって開始されたRDMA読み取り操作によって効率的かつ直接移動することができます。
The process of identifying these chunks for the RDMA Read list can be implemented entirely within the RPC layer. It is transparent to the upper-level protocol, such as NFS. For instance, the file data portion of an NFS WRITE request can be selected as an RDMA "chunk" within the eXternal Data Representation (XDR) marshaling code of RPC based on a size criterion, independently of the NFS protocol layer. The XDR unmarshaling on the receiving system can identify the correspondence between Read chunks and protocol elements via the XDR position value encoded in the Read chunk entry.
RDMA読み取りリストのこれらのチャンクを識別するプロセスは、RPCレイヤー内で完全に実装できます。NFSなどの上位レベルのプロトコルに対して透明です。たとえば、NFSのデータ表現（XDR）は、NFSプロトコル層とは無関係にサイズ基準に基づいてRPCの外部データ表現（XDR）マーシャリングコード内のRDMA「チャンク」として選択できます。受信システムのXDR Unmarshalingは、読み取りチャンクエントリでエンコードされたXDR位置値を介して、読み取りチャンクとプロトコル要素の間の対応を識別できます。
RPC RDMA Read chunks are employed by this NFS mapping to convey specific NFS data to the server in a manner that may be directly placed. The following sections describe this mapping for versions of the NFS protocol.
RPC RDMA読み取りチャンクは、このNFSマッピングで採用され、特定のNFSデータを直接配置できる方法でサーバーに伝達します。次のセクションでは、NFSプロトコルのバージョンのこのマッピングについて説明します。
The RDMA Write list, in the RDMA transport header, allows the client to post one or more buffers into which the server will RDMA Write designated result chunks directly. If the client sends a null Write list, then results from the RPC call will be returned either as an inline reply, as chunks in an RDMA Read list of server-posted buffers, or in a client-posted reply buffer.
RDMAの書き込みリストは、RDMAトランスポートヘッダーで、クライアントが1つ以上のバッファーを投稿することができます。クライアントがnull writeリストを送信する場合、RPCコールの結果は、RDMAがサーバーポストバッファーのRDMA読み取りリスト、またはクライアントが投稿した返信バッファーのチャンクとして、インライン応答として返されます。
Each posted buffer in a Write list is represented as an array of memory segments. This allows the client some flexibility in submitting discontiguous memory segments into which the server will scatter the result. Each segment is described by a triplet consisting of the segment handle or steering tag (STag), segment length, and memory address or offset.
書き込みリストに投稿された各バッファーは、メモリセグメントの配列として表されます。これにより、クライアントは、サーバーが結果を散乱させる不連続なメモリセグメントを提出する際にある程度の柔軟性を可能にします。各セグメントは、セグメントハンドルまたはステアリングタグ（STAG）、セグメントの長さ、メモリアドレスまたはオフセットで構成されるトリプレットで説明されています。
struct xdr_rdma_segment {
uint32 handle; /* Registered memory handle */
uint32 length; /* Length of the chunk in bytes */
uint64 offset; /* Chunk virtual address or offset */
};
struct xdr_write_chunk {
struct xdr_rdma_segment target<>;
};
struct xdr_write_list {
struct xdr_write_chunk entry;
struct xdr_write_list *next;
};
The sum of the segment lengths yields the total size of the buffer, which MUST be large enough to accept the result. If the buffer is too small, the server MUST return an XDR encode error. The server MUST return the result data for a posted buffer by progressively filling its segments, perhaps leaving some trailing segments unfilled or partially full if the size of the result is less than the total size of the buffer segments.
セグメントの長さの合計は、バッファの合計サイズを生成します。これは、結果を受け入れるのに十分な大きさでなければなりません。バッファが小さすぎる場合、サーバーはXDRエンコードエラーを返す必要があります。サーバーは、結果のサイズがバッファセグメントの合計サイズよりも小さい場合、おそらく徐々にセグメントを徐々に充填して、掲示されたバッファーの結果データを返す必要があります。
The server returns the RDMA Write list to the client with the segment length fields overwritten to indicate the amount of data RDMA written to each segment. Results returned by direct placement MUST NOT be returned by other methods, e.g., by Read chunk list or inline. If no result data at all is returned for the element, the server places no data in the buffer(s), but does return zeros in the segment length fields corresponding to the result.
サーバーは、各セグメントに書き込まれたデータの量を示すために上書きされたセグメント長フィールドでRDMA書き込みリストをクライアントに返します。直接配置によって返された結果は、他の方法、たとえば読み取りチャンクリストまたはインラインで返されてはなりません。要素に対して結果データがまったく返されない場合、サーバーはバッファーにデータを配置しませんが、結果に対応するセグメント長フィールドにゼロを返します。
The RDMA Write list allows the client to provide multiple result buffers -- each buffer maps to a specific result in the reply. The NFS client and server implementations agree by specifying the mapping of results to buffers for each RPC procedure. The following sections describe this mapping for versions of the NFS protocol.
RDMA書き込みリストを使用すると、クライアントは複数の結果バッファーを提供できます。各バッファーは、返信の特定の結果にマップします。NFSクライアントとサーバーの実装は、各RPCプロシージャのバッファーへの結果のマッピングを指定することで一致します。次のセクションでは、NFSプロトコルのバージョンのこのマッピングについて説明します。
Through the use of RDMA Write lists in NFS requests, it is not necessary to employ the RDMA Read lists in the NFS replies, as described in the RPC/RDMA protocol. This enables more efficient operation, by avoiding the need for the server to expose buffers for RDMA, and also avoiding "RDMA_DONE" exchanges. Clients MAY additionally employ RDMA Reply chunks to receive entire messages, as described in [RFC5666].
NFSリクエストでRDMA書き込みリストを使用することにより、RPC/RDMAプロトコルで説明されているように、NFS応答でRDMA読み取りリストを使用する必要はありません。これにより、サーバーがRDMAのバッファーを公開する必要性を回避し、「RDMA_DONE」交換を回避することにより、より効率的な操作が可能になります。[RFC5666]に記載されているように、クライアントはRDMAの返信チャンクを使用してメッセージ全体を受信することができます。
A single RDMA Write list entry MAY be posted by the client to receive either the opaque file data from a READ request or the pathname from a READLINK request. The server MUST ignore a Write list for any other NFS procedure, as well as any Write list entries beyond the first in the list.
単一のRDMA書き込みリストエントリをクライアントが投稿して、読み取り要求から不透明なファイルデータまたはReadLinkリクエストからパス名のいずれかを受信することができます。サーバーは、他のNFSプロシージャの書き込みリストと、リストの最初のリストを超えた書き込みリストエントリを無視する必要があります。
Similarly, a single RDMA Read list entry MAY be posted by the client to supply the opaque file data for a WRITE request or the pathname for a SYMLINK request. The server MUST ignore any Read list for other NFS procedures, as well as additional Read list entries beyond the first in the list.
同様に、単一のRDMA読み取りリストエントリをクライアントが投稿して、書き込みリクエストの不透明ファイルデータまたはSymlinkリクエストのパス名を提供することができます。サーバーは、他のNFS手順の読み取りリストを無視する必要があります。
Because there are no NFS version 2 or 3 requests that transfer bulk data in both directions, it is not necessary to post requests containing both Write and Read lists. Any unneeded Read or Write lists are ignored by the server.
バルクデータを両方向に転送するNFSバージョン2または3のリクエストはないため、書き込みリストと読み取りリストの両方を含むリクエストを投稿する必要はありません。不要な読み取り値または書き込みリストは、サーバーによって無視されます。
In the case where the outgoing request or expected incoming reply is larger than the maximum size supported on the connection, it is possible for the RPC layer to post the entire message or result in a special "RDMA_NOMSG" message type that is transferred entirely by RDMA. This is implemented in RPC, below NFS, and therefore has no effect on the message contents.
発信要求または予想される受信返信が接続でサポートされている最大サイズよりも大きい場合、RPCレイヤーがメッセージ全体を投稿したり、RDMAによって完全に転送される特別な「RDMA_NOMSG」メッセージタイプになっている可能性があります。。これは、NFS以下のRPCで実装されるため、メッセージの内容に影響を与えません。
Non-RDMA (inline) WRITE transfers MAY OPTIONALLY employ the "RDMA_MSGP" padding method described in the RPC/RDMA protocol, if the appropriate value for the server is known to the client. Padding allows the opaque file data to arrive at the server in an aligned fashion, which may improve server performance.
非RDMA（インライン）書き込み転送は、サーバーに適切な値がクライアントに知られている場合、RPC/RDMAプロトコルで説明されている「RDMA_MSGP」パディング方法をオプションで採用する場合があります。パディングにより、不透明ファイルデータがアラインドされた方法でサーバーに到達することができ、サーバーのパフォーマンスが向上する可能性があります。
The NFS version 2 and 3 protocols are frequently limited in practice to requests containing less than or equal to 8 kilobytes and 32 kilobytes of data, respectively. In these cases, it is often practical to support basic operation without employing a configuration exchange as discussed in [RFC5666]. The server MUST post buffers large enough to receive the largest possible incoming message (approximately 12 KB for NFS version 2, or 36 KB for NFS version 3, would be vastly sufficient), and the client can post buffers large enough to receive replies based on the "rsize" it is using to the server, plus a fixed overhead for the RPC and NFS headers. Because the server MUST NOT return data in excess of this size, the client can be assured of the adequacy of its posted buffer sizes.
NFSバージョン2および3のプロトコルは、それぞれ8キロバイト以下のデータと32キロバイトのデータを含むリクエストに対して、実際に制限されていることがよくあります。これらの場合、[RFC5666]で説明されているように、構成交換を使用せずに基本的な操作をサポートすることがしばしば実用的です。サーバーは、可能な最大の受信メッセージを受信するのに十分な大きさのバッファーを投稿する必要があります（NFSバージョン2で約12 KB、NFSバージョン3で36 KBで十分に十分です）。サーバーに使用している「rsize」に加えて、RPCおよびNFSヘッダーの固定オーバーヘッド。サーバーはこのサイズを超えるデータを返してはならないため、クライアントは投稿されたバッファサイズの妥当性を保証できます。
Flow control is handled dynamically by the RPC RDMA protocol, and write padding is OPTIONAL and therefore MAY remain unused.
フロー制御はRPC RDMAプロトコルによって動的に処理され、書き込みパディングはオプションであるため、未使用のままである可能性があります。
Alternatively, if the server is administratively configured to values appropriate for all its clients, the same assurance of interoperability within the domain can be made.
または、サーバーがすべてのクライアントに適した値に管理上構成されている場合、ドメイン内の相互運用性の同じ保証を作成できます。
The use of a configuration protocol with NFS v2 and v3 is therefore OPTIONAL. Employing a configuration exchange may allow some advantage to server resource management through accurately sizing buffers, enabling the server to know exactly how many RDMA Reads may be in progress at once on the client connection, and enabling client write padding, which may be desirable for certain servers when RDMA Read is impractical.
したがって、NFS V2およびV3を使用した構成プロトコルの使用はオプションです。構成交換を使用すると、正確なサイジングバッファーを介してサーバーリソース管理にある程度の利点があり、サーバーがクライアント接続で一度にいくつのRDMA読み取りが進行中であるかを正確に知ることができ、クライアントの書き込みパディングを可能にすることができます。RDMAの読み取りが非現実的であるときのサーバー。
This specification applies to the first minor version of NFS version 4 (NFSv4.0) and any subsequent minor versions that do not override this mapping.
この仕様は、NFSバージョン4（NFSV4.0）の最初のマイナーバージョンと、このマッピングをオーバーライドしない後続のマイナーバージョンに適用されます。
The Write list MUST be considered only for the COMPOUND procedure. This procedure returns results from a sequence of operations. Only the opaque file data from an NFS READ operation and the pathname from a READLINK operation MUST utilize entries from the Write list.
書き込みリストは、複合手順についてのみ考慮する必要があります。この手順は、一連の操作から結果を返します。NFS読み取り操作からの不透明ファイルデータのみと、ReadLink操作からのパス名は、書き込みリストからエントリを利用する必要があります。
If there is no Write list, i.e., the list is null, then any READ or READLINK operations in the COMPOUND MUST return their data inline. The NFSv4.0 client MUST ensure in this case that any result of its READ and READLINK requests will fit within its receive buffers, in order to avoid a resulting RDMA transport error upon transfer. The server is not required to detect this.
書き込みリストがない場合、つまりリストがnullである場合、化合物内の読み取りまたは読み取り操作はデータをインラインで返す必要があります。NFSV4.0クライアントは、この場合、読み取りおよびReadLink要求の結果が、転送時に結果のRDMA輸送エラーを回避するために、受信バッファー内に収まることを確認する必要があります。サーバーはこれを検出する必要はありません。
The first entry in the Write list MUST be used by the first READ or READLINK in the COMPOUND request. The next Write list entry is used by the next READ or READLINK, and so on. If there are more READ or READLINK operations than Write list entries, then any remaining operations MUST return their results inline.
書き込みリストの最初のエントリは、化合物要求の最初の読み取りまたはReadLinkで使用する必要があります。次の書き込みリストエントリは、次の読み取りまたはReadLinkなどで使用されます。書き込みリストエントリよりも読み取りまたはReadLinkの操作が多い場合、残りの操作は結果をインラインで返す必要があります。
If a Write list entry is presented, then the corresponding READ or READLINK MUST return its data via an RDMA Write to the buffer indicated by the Write list entry. If the Write list entry has zero RDMA segments, or if the total size of the segments is zero, then the corresponding READ or READLINK operation MUST return its result inline.
書き込みリストのエントリが表示されている場合、対応する読み取りまたはreadLinkは、書き込みリストエントリで示されるバッファーにRDMA書き込みを介してデータを返す必要があります。書き込みリストエントリのRDMAセグメントがゼロの場合、またはセグメントの合計サイズがゼロの場合、対応する読み取りまたはReadLink操作は結果をインラインに戻す必要があります。
The following example shows an RDMA Write list with three posted buffers A, B, and C. The designated operations in the compound request, READ and READLINK, consume the posted buffers by writing their results back to each buffer.
次の例は、3つの投稿されたバッファーA、B、およびCを備えたRDMA書き込みリストを示しています。複合要求で指定された操作、読み取りと読み取りリンクは、結果を各バッファーに書き戻して投稿されたバッファーを消費します。
RDMA Write list:
RDMA書き込みリスト：
A --> B --> C
Compound request:
複合リクエスト：
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ
| | |
v v v
A B C
If the client does not want to have the READLINK result returned directly, then it provides a zero-length array of segment triplets for buffer B or sets the values in the segment triplet for buffer B to zeros so that the READLINK result MUST be returned inline.
クライアントがReadLinkの結果を直接返したくない場合、バッファーB用のセグメントトリプレットのゼロ長い配列を提供するか、バッファーBのセグメントトリプレットの値をゼロに設定して、ReadLinkの結果をインラインで返す必要があります。。
The situation is similar for RDMA Read lists sent by the client and applies to the NFSv4.0 WRITE and SYMLINK procedures as for v3. Additionally, inline segments too large to fit in posted buffers MAY be transferred in special "RDMA_NOMSG" messages.
状況は、クライアントが送信したRDMA読み取りリストで同様であり、V3に関してNFSV4.0の書き込み手順とSymlink手順に適用されます。さらに、投稿されたバッファーに収まるには大きすぎるインラインセグメントは、特別な「RDMA_NOMSG」メッセージで転送される場合があります。
Non-RDMA (inline) WRITE transfers MAY OPTIONALLY employ the "RDMA_MSGP" padding method described in the RPC/RDMA protocol, if the appropriate value for the server is known to the client. Padding allows the opaque file data to arrive at the server in an aligned fashion, which may improve server performance. In order to ensure accurate alignment for all data, it is likely that the client will restrict its use of OPTIONAL padding to COMPOUND requests containing only a single WRITE operation.
非RDMA（インライン）書き込み転送は、サーバーに適切な値がクライアントに知られている場合、RPC/RDMAプロトコルで説明されている「RDMA_MSGP」パディング方法をオプションで採用する場合があります。パディングにより、不透明ファイルデータがアラインドされた方法でサーバーに到達することができ、サーバーのパフォーマンスが向上する可能性があります。すべてのデータの正確なアラインメントを確保するために、クライアントは、単一の書き込み操作のみを含むリクエストを複合するために、オプションのパディングの使用を制限する可能性があります。
Unlike NFS versions 2 and 3, the maximum size of an NFS version 4 COMPOUND is not bounded, even when RDMA chunks are in use. While it might appear that a configuration protocol exchange (such as the one described in [RFC5666]) would help, in fact the layering issues involved in building COMPOUNDs by NFS make such a mechanism unworkable.
NFSバージョン2および3とは異なり、RDMAチャンクが使用されている場合でも、NFSバージョン4化合物の最大サイズは制限されていません。構成プロトコル交換（[RFC5666]に記載されているようなものなど）は、実際には、NFSによる化合物の構築に伴う階層化の問題により、そのようなメカニズムを実行不可能にします。
However, typical NFS version 4 clients rarely issue such problematic requests. In practice, they behave in much more predictable ways, in fact most still support the traditional rsize/wsize mount parameters. Therefore, most NFS version 4 clients function over RPC/RDMA in the same way as NFS versions 2 and 3, operationally.
ただし、典型的なNFSバージョン4クライアントは、このような問題のあるリクエストを発行することはめったにありません。実際には、それらははるかに予測可能な方法で振る舞います。実際、ほとんどは従来のRsize/Wsizeマウントパラメーターをサポートしています。したがって、ほとんどのNFSバージョン4クライアントは、NFSバージョン2および3の運用と同じ方法でRPC/RDMAで機能します。
There are however advantages to allowing both client and server to operate with prearranged size constraints, for example, use of the sizes to better manage the server's response cache. An extension to NFS version 4 supporting a more comprehensive exchange of upper-layer parameters is part of [RFC5661].
ただし、クライアントとサーバーの両方が事前に配置されたサイズの制約で動作できるようにすることには利点があります。たとえば、サイズを使用してサーバーの応答キャッシュをより適切に管理することです。より包括的な上層パラメーターのより包括的な交換をサポートするNFSバージョン4の拡張は、[RFC5661]の一部です。
The NFS version 4 protocols support server-initiated callbacks to selected clients, in order to notify them of events such as recalled delegations, etc. These callbacks present no particular issue to being framed over RPC/RDMA, since such callbacks do not carry bulk data such as NFS READ or NFS WRITE. They MAY be transmitted inline via RDMA_MSG, or if the callback message or its reply overflow the negotiated buffer sizes for a callback connection, they MAY be transferred via the RDMA_NOMSG method as described above for other exchanges.
NFSバージョン4プロトコルは、リコールされた代表団などのイベントを通知するために、選択したクライアントへのサーバーが開始するコールバックをサポートします。これらのコールバックは、RPC/RDMAに額面化することに特別な問題を提示しません。NFS読み取りやNFSの書き込みなど。それらはRDMA_MSGを介してインラインで送信される可能性があります。または、コールバック接続のためにコールバックメッセージまたはその応答がネゴシエートされたバッファーサイズをオーバーフローする場合、他の交換について上記のようにRDMA_NOMSGメソッドを介して転送される場合があります。
One special case is noteworthy: in NFS version 4.1, the callback channel is optionally negotiated to be on the same connection as one used for client requests. In this case, and because the transaction ID (XID) is present in the RPC/RDMA header, the client MUST ascertain whether the message is in fact an RPC REPLY, and therefore a reply to a prior request and carrying its XID, before processing it as such. By the same token, the server MUST ascertain whether an incoming message on such a callback-eligible connection is an RPC CALL, before optionally processing the XID.
1つの特別なケースは注目に値します。NFSバージョン4.1では、クライアントリクエストに使用されるものと同じ接続と同じ接続に登場すると、コールバックチャネルがオプションで交渉されます。この場合、およびトランザクションID（XID）がRPC/RDMAヘッダーに存在するため、クライアントはメッセージが実際にRPCの返信であるかどうかを確認する必要があります。そのように。同様に、サーバーは、XIDをオプションで処理する前に、そのようなコールバックに適格な接続に関する着信メッセージがRPC呼び出しであるかどうかを確認する必要があります。
In the callback case, the XID present in the RPC/RDMA header will potentially have any value, which may (or may not) collide with an XID used by the client for a previous or future request. The client and server MUST inspect the RPC component of the message to determine its potential disposition as either an RPC CALL or RPC REPLY, prior to processing this XID, and MUST NOT reject or accept it without also determining the proper context.
コールバックの場合、RPC/RDMAヘッダーに存在するXIDには、以前または将来のリクエストのためにクライアントが使用するXIDと衝突する可能性がある（またはそうでない）価値がある可能性があります。クライアントとサーバーは、メッセージのRPCコンポーネントを検査して、このXIDを処理する前に、RPCコールまたはRPC応答のいずれかとして潜在的な処分を決定する必要があり、適切なコンテキストを決定せずに拒否または受け入れてはなりません。
NFS use of direct data placement introduces a need for an additional NFS port number assignment for networks that share traditional UDP and TCP port spaces with RDMA services. The iWARP [RFC5041] [RFC5040] protocol is such an example (InfiniBand is not).
NFS直接データ配置の使用により、従来のUDPおよびTCPポートスペースをRDMAサービスと共有するネットワークの追加のNFSポート番号割り当てが必要になります。IWARP [RFC5041] [RFC5040]プロトコルはそのような例です（infinibandはそうではありません）。
NFS servers for versions 2 and 3 [RFC1094] [RFC1813] traditionally listen for clients on UDP and TCP port 2049, and additionally, they register these with the portmapper and/or rpcbind [RFC1833] service. However, [RFC3530] requires NFS servers for version 4 to listen on TCP port 2049, and they are not required to register.
バージョン2および3 [RFC1094] [RFC1813]のNFSサーバーは、伝統的にUDPおよびTCPポート2049のクライアントを聴き、さらに、これらをポートマッパーおよび/またはRPCBIND [RFC1833]サービスに登録しています。ただし、[RFC3530]は、バージョン4のNFSサーバーがTCPポート2049でリッスンする必要があり、登録する必要はありません。
An NFS version 2 or version 3 server supporting RPC/RDMA 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/RDMA service. The chosen port MAY be registered with the RPC portmapper under the netid assigned by the requirement in [RFC5666].
このようなネットワーク上のRPC/RDMAをサポートし、RPCポートマッパーに登録するNFSバージョン2またはバージョン3サーバーは、任意のポートを選択するか、RPC/RDMAサービスに代替の有名なポート番号を使用する場合があります。選択したポートは、[RFC5666]の要件によって割り当てられたNetIDの下でRPCポートマッパーに登録できます。
An NFS version 4 server supporting RPC/RDMA on such a network MUST use the alternative well-known port number for its RPC/RDMA service. Clients SHOULD connect to this well-known port without consulting the RPC portmapper (as for NFSv4/TCP).
このようなネットワーク上のRPC/RDMAをサポートするNFSバージョン4サーバーは、RPC/RDMAサービスに代替の有名なポート番号を使用する必要があります。クライアントは、RPCポートマッパー（NFSV4/TCPの場合）に相談することなく、この有名なポートに接続する必要があります。
The port number assigned to an NFS service over an RPC/RDMA transport is available from the IANA port registry [RFC3232].
RPC/RDMAトランスポートを介してNFSサービスに割り当てられたポート番号は、IANAポートレジストリ[RFC3232]から入手できます。
The RDMA transport for RPC [RFC5666] supports all RPC [RFC5531] security models, including RPCSEC_GSS [RFC2203] security and link-level security. The choice of RDMA Read and RDMA Write to return RPC argument and results, respectively, does not affect this, since it only changes the method of data transfer. Specifically, the requirements of [RFC5666] ensure that this choice does not introduce new vulnerabilities.
RPC [RFC5666]のRDMA輸送は、RPCSEC_GSS [RFC2203]セキュリティおよびリンクレベルのセキュリティを含むすべてのRPC [RFC5531]セキュリティモデルをサポートしています。RDMA読み取りとRDMAの選択は、それぞれRPC引数と結果を返すために書き込み、データ転送の方法のみを変更するため、これには影響しません。具体的には、[RFC5666]の要件は、この選択が新しい脆弱性を導入しないことを保証します。
Because this document defines only the binding of the NFS protocols atop [RFC5666], all relevant security considerations are therefore to be described at that layer.
このドキュメントは、[RFC5666]の上のNFSプロトコルの結合のみを定義するため、すべての関連するセキュリティに関する考慮事項は、その層で説明されます。
The authors would like to thank Dave Noveck and Chet Juszczak for their contributions to this document.
著者は、この文書への貢献についてDave NoveckとChet Juszczakに感謝したいと思います。
[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094] Sun Microsystems、「NFS：ネットワークファイルシステムプロトコル仕様」、RFC 1094、1989年3月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[RFC1833] Srinivasan、R。、「ONC RPCバージョン2の結合プロトコル」、RFC 1833、1995年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009.
[RFC5531] Thurlow、R。、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 5531、2009年5月。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[RFC5661] Shepler、S.、ed。、eisler、M.、ed。、およびD. Noveck、ed。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン1プロトコル」、RFC 5661、2010年1月。
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RFC5040] Recio、R.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「リモートダイレクトメモリアクセスプロトコル仕様」、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「信頼できる輸送を介した直接データ配置」、RFC 5041、2007年10月。
[RFC5666] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", RFC 5666, January 2010.
[RFC5666] Talpey、T。およびB. Callaghan、「リモートプロシージャコールのリモートダイレクトメモリアクセストランスポート」、RFC 5666、2010年1月。
Authors' Addresses
著者のアドレス
Tom Talpey 170 Whitman St. Stow, MA 01775 USA
Tom Talpey 170ホイットマンセントストウ、マサチューセッツ州01775 USA
EMail: tmtalpey@gmail.com
Brent Callaghan Apple Computer, Inc. MS: 302-4K 2 Infinite Loop Cupertino, CA 95014 USA
Brent Callaghan Apple Computer、Inc。MS：302-4K 2 Infinite Loop Cupertino、CA 95014 USA
EMail: brentc@apple.com