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
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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].
リモートプロシージャコール（RPC）[RFC5666]のためのリモートダイレクトメモリアクセス（RDMA）輸送は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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書き込み要求のファイルのデータ部分は、独立して、NFSプロトコル層の、サイズ基準に基づいて、RPCの外部データ表現（XDR）マーシャリングコード内RDMA「チャンク」として選択することができます。受信システムにアンマーシャリングXDRは、Readチャンクエントリでエンコード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トランスポート・ヘッダーに、クライアントはサーバがRDMA直接指定された結果のチャンクを書くでしょうその中に1つ以上のバッファを投稿することができます。クライアントがヌル書き込みリストを送信する場合は、RPC呼び出しの結果は、インライン応答として、サーバ掲示バッファの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.
書き込みリスト内の各通知バッファは、メモリ・セグメントのアレイとして表されます。これは、クライアントにサーバーが結果を散乱するその中に不連続メモリセグメントを提出である程度の柔軟性を可能にします。各セグメントは、セグメントハンドルまたはステアリングタグ（婚前）、セグメント長、およびメモリアドレスまたはオフセットからなるトリプレットによって記述されます。
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の量を示すために、上書きされたセグメントの長さのフィールドを持つクライアントに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書き込みリストを使用することにより、NFSでRDMA読み取りリストを使用する必要はないRPC / 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書き込みリストエントリは、READ要求または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読むリストエントリは、WRITE要求または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」メッセージタイプをもたらすようにするための発信要求または期待される着信応答が接続上でサポートされる最大サイズよりも大きい場合には、それが可能です。これは、RPCで、NFS下に実施するため、メッセージの内容には影響を与えていません。
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」パディング法を採用してもよいWRITE。パディングは、サーバのパフォーマンスを向上させることができる、不透明なファイルデータが整列方式でサーバに到達することを可能にします。
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キロバイト、非常に十分であろう）を受信するのに十分な大きさのバッファをポストしなければならない、そしてクライアントが基づいて応答を受信するのに十分な大きさのバッファを投稿することができそれは、サーバーに使用している「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.
書き込みリストはCOMPOUND手順のために考えなければなりません。この手順は、一連の操作の結果を返します。 READLINK操作からNFS READ操作およびパス名から不透明なファイルデータのみが書き込みリストからエントリを利用しなければなりません。
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の場合、化合物中の任意のREADまたはREADLINK操作は、そのデータをインラインで返さなければなりません。 NFSv4.0のクライアントは、そのREADと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.
書き込みリストの最初のエントリは、COMPOUND要求に最初のREADまたはREADLINKで使用しなければなりません。次の書き込みリストエントリは、その次のREADまたはREADLINKで使用され、されています。リストのエントリを書くよりも多くのREADまたは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.
書き込みリスト項目が提示されている場合、対応するREADまたはREADLINK書き込みリストエントリによって示されるバッファにRDMA書き込みを介してそのデータを返さなければなりません。書き込みリストエントリがゼロRDMAセグメントを有する、またはセグメントの合計サイズがゼロである場合、対応するREADまたは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書き込みリストを示し、READ及びREADLINKは、バック各バッファにその結果を書き込むことによって投稿バッファを消費します。
RDMA Write list:
RDMA書き込みリスト：
A --> B --> C
- > B - > C
Compound request:
複合要求：
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ | | | v v v A B C
PUTFH LOOKUP READ PUTFH LOOKUP READLINK PUTFH LOOKUP READ | | | V V V 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のセグメントトリプレットの長さゼロの配列を提供するか、READLINK結果はインライン返さなければならないようにゼロにバッファBのセグメントトリプレットの値を設定します。
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のWRITEと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」パディング法を採用してもよいWRITE。パディングは、サーバのパフォーマンスを向上させることができる、不透明なファイルデータが整列方式でサーバに到達することを可能にします。すべてのデータの正確な位置合わせを確保するためには、クライアントは、単一のWRITE操作を含む化合物を要求するには、オプションのパディングの使用を制限する可能性があります。
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とは異なり、NFSバージョン4の化合物の最大サイズは、RDMAチャンクが使用されている場合であっても、囲まれていません。それは（例えば、[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 READまたはNFS WRITEなど。彼らは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.
一つの特別なケースは、注目に値する：NFSバージョン4.1で、コールバックチャネルは、必要に応じてクライアントの要求のために使用されるものと同じ接続であることを交渉しています。この場合、処理前に、トランザクションID（XID）がRPC / RDMAヘッダに存在する、クライアントは、メッセージが実際にRPC応答であるか否かを確認し、従って前の要求に応答し、そのXIDを搬送しなければならないためそのような。同じトークンによって、サーバは、コールバック適格接続の着信メッセージは、任意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コールまたはRPC応答のいずれかとその潜在的な配置を決定するために、メッセージのRPCコンポーネントを検査前にこのXIDを処理するとともに、適切なコンテキストを決定することなく、それを拒否または受け入れてはいけませんしなければなりません。
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の使用は、RDMAサービスと伝統的なUDPおよびTCPポートのスペースを共有するネットワークのための追加的なNFSポート番号の割り当ての必要性を紹介します。 iWARPの[RFC5041]、[RFC5040]プロトコル（インフィニバンドではない）、このような例です。
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]はTCPポート2049をリッスンするように、バージョン4のNFSサーバを必要とし、彼らは登録する必要はありません。
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].
NFSバージョン2またはバージョン3サーバー、ネットワーク上のRPC / RDMAをサポートし、任意のポートを選択してもよいし、そのRPC / RDMAサービスの代替周知のポート番号を使用するかもしれRPCポートマッパに自身を登録します。選択されたポートは、[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サービスの代替周知のポート番号を使用しなければなりません。クライアントは、（のNFSv4 / TCP用として）RPCポートマッパーに相談することなく、この既知のポートに接続する必要があります。
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 Readと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.
作者はこのドキュメントへの貢献のためにデーブNoveckとチェットJuszczakに感謝したいと思います。
[RFC1094] Sun Microsystems, "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094]サン・マイクロシステムズ、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月を。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813]キャラハン、B.、ポロウスキー、B.、およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[RFC1833]スリニバサン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]アイスラー、M.、チウ、A.、およびL.リン、 "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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、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.編、アイスラー、M.、編、及びD. Noveck編、 "ネットワークファイルシステム（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]レイノルズ、J.、エド、。：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。
[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.、メッツラー、B.、Culley、P.、Hilland、J.、およびD.ガルシア、 "リモートダイレクトメモリアクセスプロトコル仕様"、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]シャー、H.、ピンカートン、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.キャラハン、RFC 5666、2010年1月。
Authors' Addresses
著者のアドレス
Tom Talpey 170 Whitman St. Stow, MA 01775 USA
トムTalpey 170ホイットマンセントストウ、MA 01775 USA
EMail: tmtalpey@gmail.com
メールアドレス：tmtalpey@gmail.com
Brent Callaghan Apple Computer, Inc. MS: 302-4K 2 Infinite Loop Cupertino, CA 95014 USA
ブレントキャラハンされたApple Computer、Inc. MS：302-4K 2無限ループクパチーノ、CA 95014 USA
EMail: brentc@apple.com
メールアドレス：brentc@apple.com