Network Working Group S. Bailey
Request for Comments: 4296 Sandburst
Category: Informational T. Talpey
NetApp
December 2005
The Architecture of Direct Data Placement (DDP)
and Remote Direct Memory Access (RDMA) on Internet Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.
この文書は、インターネットプロトコルスイートのトランスポート上で実行するために直接データ配置（DDP）とリモートダイレクトメモリアクセス（RDMA）プロトコルの抽象アーキテクチャを定義しています。このアーキテクチャは、必ずしもそのようなプロトコルを実装するための適切な方法を反映して、しかし、むしろ、プロトコルを定義し、理解するための説明的なツールであることはありません。 DDPは、上位層プロトコル（例えば、RDMA）により指定されたバッファへのデータの効率的な配置を可能にします。 RDMAは、アプリケーションの要件と一致した方法でピア間のリモートダイレクトメモリアクセスを可能にするためのセマンティクスを提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. DDP and RDMA Protocols .....................................3
2. Architecture ....................................................4
2.1. Direct Data Placement (DDP) Protocol Architecture ..........4
2.1.1. Transport Operations ................................6
2.1.2. DDP Operations ......................................7
2.1.3. Transport Characteristics in DDP ...................10
2.2. Remote Direct Memory Access (RDMA) Protocol Architecture ..12
2.2.1. RDMA Operations ....................................14
2.2.2. Transport Characteristics in RDMA ..................16
3. Security Considerations ........................................17
3.1. Security Services .........................................18
3.2. Error Considerations ......................................19
4. Acknowledgements ...............................................19
5. Informative References .........................................20
This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. This document uses C language notation as a shorthand to describe the architectural elements of DDP and RDMA protocols. The choice of C notation is not intended to describe concrete protocols or programming interfaces.
この文書は、インターネットプロトコルスイートのトランスポート上で実行するために直接データ配置（DDP）とリモートダイレクトメモリアクセス（RDMA）プロトコルの抽象アーキテクチャを定義しています。このアーキテクチャは、必ずしもそのようなプロトコルを実装するための適切な方法を反映して、しかし、むしろ、プロトコルを定義し、理解するための説明的なツールであることはありません。この文書では、DDPとRDMAプロトコルのアーキテクチャの要素を説明するための略記としてC言語の表記法を使用します。 C表記の選択は、具体的なプロトコルまたはプログラミング・インターフェースを記述することを意図していません。
The first part of the document describes the architecture of DDP protocols, including what assumptions are made about the transports on which DDP is built. The second part describes the architecture of RDMA protocols layered on top of DDP.
文書の最初の部分はDDPが構築されているトランスポートについて行われているもの仮定を含む、DDPプロトコルのアーキテクチャについて説明します。第二の部分は、DDPの上部に積層RDMAプロトコルのアーキテクチャを記述する。
Before introducing the protocols, certain definitions will be useful to guide discussion:
プロトコルを導入する前に、特定の定義は議論を導くために有用であろう。
o Placement - writing to a data buffer.
O配置 - データバッファに書き込みます。
o Operation - a protocol message, or sequence of messages, which provide an architectural semantic, such as reading or writing of a data buffer.
O動作 - プロトコルメッセージ、またはそのようなデータバッファの読み出しまたは書き込みとして、建築セマンティックを提供するメッセージのシーケンス。
o Delivery - informing any Upper Layer or application that a particular message is available for use. Therefore, delivery may be viewed as the "control" signal associated with a unit of data. Note that the order of delivery is defined more strictly than it is for placement.
O配信 - 特定のメッセージが使用可能である任意の上位層またはアプリケーションを知らせます。したがって、送達は、データのユニットに関連付けられた「制御」信号とみなすことができます。配信の順序は、より厳密には、配置のためであるよりも、定義されていることに注意してください。
o Completion - informing any Upper Layer or application that a particular operation has finished. A completion, for instance, may require the delivery of several messages, or it may also reflect that some local processing has finished.
O完了 - 特定の操作が終了した任意の上位層またはアプリケーションを知らせます。完了は、例えば、いくつかのメッセージの配信を必要とするかもしれない、またはそれはまた、いくつかのローカル処理が終了したことを反映してもよいです。
o Data Sink - the peer on which any placement occurs.
Oデータシンク - 任意の配置が発生したピア。
o Data Source - the peer from which the placed data originates.
Oデータソース - 置かれたデータは、元となるピア。
o Steering Tag - a "handle" used to identify the buffer that is the target of placement. A "tagged" message is one that references such a handle.
Oステアリングタグ - 配置のターゲットであるバッファを識別するために使用される「ハンドル」。 「タグ付け」のメッセージは、このようなハンドルを参照するものです。
o RDMA Write - an Operation that places data from a local data buffer to a remote data buffer specified by a Steering Tag.
O RDMAライト - ステアリングタグで指定されたリモートデータバッファにローカル・データ・バッファからデータを置く操作。
o RDMA Read - an Operation that places data to a local data buffer specified by a Steering Tag from a remote data buffer specified by another Steering Tag.
O RDMA読む - 別のステアリングタグで指定されたリモートデータバッファからステアリングタグで指定されたローカルデータバッファにデータを置く操作。
o Send - an Operation that places data from a local data buffer to a remote data buffer of the data sink's choice. Therefore, sends are "untagged".
O送信 - データシンクの選択肢の遠隔データ・バッファにローカル・データ・バッファからデータを置く動作。そのため、「タグなし」です送信します。
The goal of the DDP protocol is to allow the efficient placement of data into buffers designated by protocols layered above DDP (e.g., RDMA). This is described in detail in [ROM]. Efficiency may be characterized by the minimization of the number of transfers of the data over the receiver's system buses.
DDPプロトコルの目標は、DDP（例えば、RDMA）上に積層プロトコルによって指定されたバッファへのデータの効率的な配置を可能にすることです。これは[ROM]に詳細に記載されています。効率は、受信側のシステムバスを介したデータの転送回数の最小化によって特徴づけることができます。
The goal of the RDMA protocol is to provide the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. The RDMA protocol provides facilities immediately useful to existing and future networking, storage, and other application protocols. [FCVI, IB, MYR, SDP, SRVNET, VI]
RDMAプロトコルの目標は、アプリケーションの要件と一貫性のある方法でピア間のリモートダイレクトメモリアクセスを可能にするためのセマンティクスを提供することです。 RDMAプロトコルは、既存および将来のネットワーク、ストレージ、および他のアプリケーションプロトコルにすぐに便利な機能を提供します。 [FCVI、IB、MYR、SDP、SRVNET、VI]
The DDP and RDMA protocols work together to achieve their respective goals. DDP provides facilities to safely steer payloads to specific buffers at the Data Sink. RDMA provides facilities to Upper Layers for identifying these buffers, controlling the transfer of data between peers' buffers, supporting authorized bidirectional transfer between buffers, and signalling completion. Upper Layer Protocols that do not require the features of RDMA may be layered directly on top of DDP.
DDPとRDMAプロトコルは、それぞれの目標を達成するために一緒に働きます。 DDPは、安全にデータシンクで、特定のバッファにペイロードを操縦する機能を提供します。 RDMAは、これらのバッファを識別するピアのバッファ間のデータ転送を制御し、バッファ間許可双方向転送をサポートし、完了をシグナリングするための上位層に機能を提供します。 RDMAの機能を必要としない上位層プロトコルはDDPの上に直接積層してもよいです。
The DDP and RDMA protocols are transport independent. The following figure shows the relationship between RDMA, DDP, Upper Layer Protocols, and Transport.
DDPとRDMAプロトコルは、トランスポート独立しています。次の図は、RDMA、DDP、上位層プロトコル、および交通との関係を示したものです。
+--------------------------------------------------+
| Upper Layer Protocol |
+---------+------------+---------------------------+
| | | RDMA |
| | +---------------------------+
| | DDP |
| +----------------------------------------+
| Transport |
+--------------------------------------------------+
The Architecture section is presented in two parts: Direct Data Placement Protocol architecture and Remote Direct Memory Access Protocol architecture.
直接データ配置プロトコルアーキテクチャおよびリモートダイレクトメモリアクセスプロトコルアーキテクチャ：アーキテクチャのセクションでは、2つの部分に示されています。
The central idea of general-purpose DDP is that a data sender will supplement the data it sends with placement information that allows the receiver's network interface to place the data directly at its final destination without any copying. DDP can be used to steer received data to its final destination, without requiring layer-specific behavior for each different layer. Data sent with such DDP information is said to be `tagged'.
汎用DDPの中心的な考えは、データ送信側は、それが受信側のネットワークインタフェースは、任意のコピーせずに、最終的な目的地に直接データを配置することを可能にする配置情報を送信したデータを補完するということです。 DDPは、それぞれ異なる層のための層固有の動作を必要とせず、その最終的な宛先に受信したデータを操縦するために使用することができます。このようDDP情報とともに送信されたデータは、 `」タグ付けされると言われています。
The central components of the DDP architecture are the `buffer', which is an object with beginning and ending addresses, and a method (set()), which sets the value of an octet at an address. In many cases, a buffer corresponds directly to a portion of host user memory. However, DDP does not depend on this; a buffer could be a disk file, or anything else that can be viewed as an addressable collection of octets. Abstractly, a buffer provides the interface:
DDPアーキテクチャの中心的構成要素は `開始および終了アドレスを持つオブジェクト、およびアドレスにオクテットの値を設定する方法は、（セット（））であり、これは、「バッファです。多くの場合、バッファは、ホスト・ユーザメモリの部分に直接対応します。しかし、DDPはこれに依存しません。バッファは、ディスク・ファイル、またはオクテットのアドレス可能な集合体として見ることができる何か他のものである可能性があります。抽象的に、バッファは、インタフェースを提供します。
typedef struct {
const address_t start;
const address_t end;
void set(address_t a, data_t v);
} ddp_buffer_t;
address_t
ADDRESS_T
a reference to local memory
ローカルメモリへの参照
data_t
data_t
an octet data value.
オクテットデータ値。
The protocol layering and in-line data flow of DDP is:
DDPのプロトコルレイヤリングとインラインのデータフローです。
DDP Client Protocol
(e.g., RDMA or Upper Layer Protocol)
| ^
untagged messages | | untagged message delivery
tagged messages | | tagged message delivery
v |
DDP+---> data placement
^
| transport messages
v
Transport
(e.g., SCTP, DCCP, framed TCP)
^
| IP datagrams
v
. . .
In addition to in-line data flow, the client protocol registers buffers with DDP, and DDP performs buffer update (set()) operations as a result of receiving tagged messages.
インラインデータフローに加えて、クライアントプロトコルは、DDPとバッファを登録し、DDPは、タグ付けされたメッセージを受信した結果として、バッファの更新（セット（））動作を行います。
DDP messages may be split into multiple, smaller DDP messages, each in a separate transport message. However, if the transport is unreliable or unordered, messages split across transport messages may or may not provide useful behavior, in the same way as splitting arbitrary Upper Layer messages across unreliable or unordered transport messages may or may not provide useful behavior. In other words, the same considerations apply to building client protocols on different types of transports with or without the use of DDP.
DDPメッセージは、複数の、より小さいDDPメッセージ、別のトランスポートメッセージ内のそれぞれに分割することができます。トランスポートが信頼できないか、順不同である場合は、メッセージがまたはまたは有用な動作を提供しない場合があり信頼できない、または順不同の輸送メッセージ間で分割任意の上位層のメッセージと同じように、便利な動作を提供しない場合があり、トランスポートメッセージにまたがって分割します。言い換えれば、同じ考慮事項がDDPの使用の有無にかかわらずトランスポートのさまざまな種類のクライアントプロトコルの構築に適用されます。
A DDP message split across transport messages looks like:
転送メッセージにまたがって分割DDPメッセージは次のようになります。
DDP message: Transport messages:
DDPメッセージ：トランスポート・メッセージ：
stag=s, offset=o, message 1:
notify=y, id=i |type=ddp |
message= |stag=s |
|aabbccddee|-------. |offset=o |
~ ... ~----. \ |notify=n |
|vvwwxxyyzz|-. \ \ |id=? |
| \ `--->|aabbccddee|
| \ ~ ... ~
| +----->|iijjkkllmm|
| |
+ | message 2:
\ | |type=ddp |
\ | |stag=s |
\ + |offset=o+n|
\ \ |notify=y |
\ \ |id=i |
\ `-->|nnooppqqrr|
\ ~ ... ~
`---->|vvwwxxyyzz|
Although this picture suggests that DDP information is carried in-line with the message payload, components of the DDP information may also be in transport-specific fields, or derived from transport-specific control information if the transport permits.
この写真はDDP情報がメッセージペイロードとインライン搬送されることを示唆するが、DDP情報の構成要素はまた、トランスポート固有のフィールドであってもよく、又は輸送許せば、トランスポート固有の制御情報から誘導します。
For the purposes of this architecture, the transport provides:
このアーキテクチャの目的のために、輸送が用意されています。
void xpt_send(socket_t s, message_t m);
message_t xpt_recv(socket_t s);
msize_t xpt_max_msize(socket_t s);
socket_t
socket_t
a transport address, including IP addresses, ports and other
transport-specific identifiers.
message_t
message_t
a string of octets.
オクテットの列。
msize_t (scalar)
msize_t（スカラ）
a message size.
メッセージサイズ。
xpt_send(socket_t s, message_t m)
xpt_send（socket_t S、Mをmessage_t）
send a transport message.
トランスポート・メッセージを送信します。
xpt_recv(socket_t s)
xpt_recv（socket_t秒）
receive a transport message.
トランスポート・メッセージが表示されます。
xpt_max_msize(socket_t s)
xpt_max_msize（socket_t秒）
get the current maximum transport message size. Corresponds,
roughly, to the current path Maximum Transfer Unit (PMTU),
adjusted by underlying protocol overheads.
Real implementations of xpt_send() and xpt_recv() typically return error indications, but that is not relevant to this architecture.
xpt_send（）とxpt_recv（）の本当の実装は通常、エラー表示を返すが、それはこのアーキテクチャには関係ありません。
The DDP layer provides:
DDP層が用意されています。
void ddp_send(socket_t s, message_t m);
void ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d,
ddp_notify_t n);
void ddp_post_recv(socket_t s, bdesc_t b);
ddp_ind_t ddp_recv(socket_t s);
bdesc_t ddp_register(socket_t s, ddp_buffer_t b);
void ddp_deregister(bhand_t bh);
msizes_t ddp_max_msizes(socket_t s);
ddp_addr_t
ddp_addr_t
the buffer address portion of a tagged message:
タグ付けされたメッセージのバッファアドレス部分：
typedef struct {
stag_t stag;
address_t offset;
} ddp_addr_t;
stag_t (scalar)
stag_t（スカラ）
a Steering Tag. A stag_t identifies the destination buffer for
tagged messages. stag_ts are generated when the buffer is
registered, communicated to the sender by some client protocol convention and inserted in DDP messages. stag_t values in this
DDP architecture are assumed to be completely opaque to the
client protocol, and implementation-dependent. However,
particular implementations, such as DDP on a multicast transport
(see below), may provide the buffer holder some control in
selecting stag_ts.
ddp_notify_t
ddp_notify_t
the notification portion of a DDP message, used to signal
that the message represents the final fragment of a
multi-segmented DDP message:
typedef struct {
boolean_t notify;
ddp_msg_id_t i;
} ddp_notify_t;
ddp_msg_id_t (scalar)
ddp_msg_id_t（スカラ）
a DDP message identifier. msg_id_ts are chosen by the DDP
message receiver (buffer holder), communicated to the sender by
some client protocol convention and inserted in DDP messages.
Whether a message reception indication is requested for a DDP
message is a matter of client protocol convention. Unlike
stag_ts, the structure of msg_id_ts is opaque to DDP, and
therefore, it is completely in the hands of the client protocol.
bdesc_t
bdesc_t
a description of a registered buffer:
登録した緩衝液の説明：
typedef struct {
bhand_t bh;
ddp_addr_t a;
} bdesc_t;
`a.offset' is the starting offset of the registered buffer, which may have no relationship to the `start' or `end' addresses of that buffer. However, particular implementations, such as DDP on a multicast transport (see below), may allow some client protocol control over the starting offset.
`a.offsetは、またはそのバッファの`「末端アドレス `開始に関係がないかもしれ登録バッファの開始オフセットです '。しかしながら、このようなマルチキャストトランスポート上のDDPのような特定の実装では、（下記参照）、開始オフセットを超えるいくつかのクライアントプロトコル制御を可能にすることができます。
bhand_t
bhand_t
an opaque buffer handle used to deregister a buffer.
不透明なバッファのハンドルは、バッファの登録を解除するために使用します。
recv_message_t
recv_message_t
a description of a completed untagged receive buffer:
完成したタグなし受信バッファの説明：
typedef struct {
bdesc_t b;
length_t l;
} recv_message_t;
ddp_ind_t
ddp_ind_t
an untagged message, a tagged message reception indication, or a
tagged message reception error:
typedef union {
recv_message_t m;
ddp_msg_id_t i;
ddp_err_t e;
} ddp_ind_t;
ddp_err_t
ddp_err_t
indicates an error while receiving a tagged message, typically
`offset' out of bounds, or `stag' is not registered to the
socket.
msizes_t
msizes_t
The maximum untagged and tagged messages that fit in a single
transport message:
typedef struct {
msize_t max_untagged;
msize_t max_tagged;
} msizes_t;
ddp_send(socket_t s, message_t m)
ddp_send（socket_t S、Mをmessage_t）
send an untagged message.
タグの付いていないメッセージを送信します。
ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d, ddp_notify_t n)
ddp_send_ddp（socket_t秒、message_t mを、ddp_addr_tのD、ddp_notify_t n）が
send a tagged message to remote buffer address d.
リモートバッファアドレスdにタグ付けされたメッセージを送信します。
ddp_post_recv(socket_t s, bdesc_t b)
ddp_post_recv（socket_t S、bdesc_t B）
post a registered buffer to accept a single received untagged
message. Each buffer is returned to the caller in a ddp_recv()
untagged message reception indication, in the order in which it
was posted. The same buffer may be enabled on multiple sockets;
receipt of an untagged message into the buffer from any of these
sockets unposts the buffer from all sockets.
ddp_recv(socket_t s)
ddp_recv（socket_t秒）
get the next received untagged message, tagged message reception
indication, or tagged message error.
ddp_register(socket_t s, ddp_buffer_t b)
ddp_register（socket_t秒、ddp_buffer_t b）は
register a buffer for DDP on a socket. The same buffer may be
registered multiple times on the same or different sockets. The
same buffer registered on different sockets may result in a
common registration. Different buffers may also refer to
portions of the same underlying addressable object (buffer
aliasing).
ddp_deregister(bhand_t bh)
ddp_deregister（bhand_tのBH）
remove a registration from a buffer.
バッファから登録を削除します。
ddp_max_msizes(socket_t s)
ddp_max_msizes（socket_t秒）
get the current maximum untagged and tagged message sizes that
will fit in a single transport message.
Certain characteristics of the transport on which DDP is mapped determine the nature of the service provided to client protocols. Fundamentally, the characteristics of the transport will not be changed by the presence of DDP. The choice of transport is therefore driven not by DDP, but by the requirements of the Upper Layer, and employing the DDP service.
DDPがマッピングされている輸送の特定の特性は、クライアントプロトコルに提供されるサービスの性質を決定します。基本的に、輸送の特性は、DDPの存在によって変更されません。輸送の選択は、そのためではないDDPことではなく、上位層の要件によって駆動され、DDPサービスを利用しています。
Specifically, transports are:
具体的には、トランスポートは、次のとおりです。
o reliable or unreliable,
O信頼性や信頼できません、
o ordered or unordered,
O命じまたは順不同、
o single source or multisource, o single destination or multidestination (multicast or anycast).
単一の宛先または複数の宛先（マルチキャスト又はエニーキャスト）に、単一ソースまたは多重ソースO。
Some transports support several combinations of these characteristics. For example, SCTP [SCTP] is reliable, single source, single destination (point-to-point) and supports both ordered and unordered modes.
いくつかのトランスポートは、これらの特性のいくつかの組み合わせをサポートしています。たとえば、SCTP [SCTP]は信頼性が高く、単一のソース、単一の宛先（ポイント・ツー・ポイント）であり、両方の規則的順序なしモードをサポートします。
DDP messages carried by transport are framed for processing by the receiver, and may be further protected for integrity or privacy in accordance with the transport capabilities. DDP does not provide such functions.
輸送によって運ばDDPメッセージは、受信機による処理のためにフレーム化され、さらに輸送能力に応じて、完全性またはプライバシーのために保護されていてもよいです。 DDPは、このような機能を提供していません。
In general, transport characteristics equally affect transport and DDP message delivery. However, there are several issues specific to DDP messages.
一般に、輸送特性が等しく輸送およびDDPメッセージの配信に影響を与えます。しかし、DDPメッセージに固有のいくつかの問題があります。
A key component of DDP is how the following operations on the receiving side are ordered among themselves, and how they relate to corresponding operations on the sending side:
DDPの主要なコンポーネントは、受信側で次の操作が自分たちの中で順序付けされる方法であり、そしてそれらは、送信側の操作を対応する関連方法。
o set()s,
Oセット（）S、
o untagged message reception indications, and
Oタグなしメッセージ受信指示、及び
o tagged message reception indications.
Oメッセージの受信指示をタグ付け。
These relationships depend upon the characteristics of the underlying transport in a way that is defined by the DDP protocol. For example, if the transport is unreliable and unordered, the DDP protocol might specify that the client protocol is subject to the consequences of transport messages being lost or duplicated, rather than requiring that different characteristics be presented to the client protocol.
これらの関係は、DDPプロトコルによって定義されるように、基礎となるトランスポートの特性に依存します。トランスポートは信頼できないと順不同であれば、例えば、DDPプロトコルは、クライアントプロトコルではなく、異なる特性は、クライアントプロトコルに提示することを要求するよりも、失われたり、複製されるトランスポート・メッセージの影響を受けやすいことを指定できます。
Buffer access must be implemented consistently across endpoint IP addresses on transports allowing multiple IP addresses per endpoint, for example, SCTP. In particular, the Steering Tag must be consistently scoped and must address the same buffer across all IP address associations belonging to the endpoint. Additionally, operation ordering relationships across IP addresses within an association (set(), get(), etc.) depend on the underlying transport. If the above consistency relationships cannot be maintained by a transport endpoint, then the endpoint is unsuitable for a DDP connection.
バッファへのアクセスは、例えば、エンドポイントごとに複数のIPアドレスを許可するトランスポートエンドポイントのIPアドレス一貫SCTPを実装しなければなりません。具体的には、ステアリングタグは一貫スコープする必要がありますし、エンドポイントに属しているすべてのIPアドレス団体間で同じバッファに対処しなければなりません。また、協会内のIPアドレス間の関係を注文する操作（セット（）、（取得）、など）基本的な輸送に依存しています。上記一貫関係がトランスポートエンドポイントによって維持することができない場合、エンドポイントは、DDPの接続には不向きです。
Multidestination data delivery is a transport characteristic that may require specific consideration in a DDP protocol. As mentioned above, the basic DDP model assumes that buffer address values returned by ddp_register() are opaque to the client protocol, and can be implementation dependent. The most natural way to map DDP to a multidestination transport is to require that all receivers produce the same buffer address when registering a multidestination destination buffer. Restriction of the DDP model to accommodate multiple destinations involves engineering tradeoffs comparable to those of providing non-DDP multidestination transport capability.
Multidestinationデータ配信は、DDPプロトコルで特定の考慮を必要とするかもしれない輸送特性です。上述したように、基本的なDDPモデルはddp_registerによって返されたバッファ・アドレス値は（）クライアントプロトコルに不透明であり、実装依存とすることができることを前提としています。 multidestination輸送にDDPをマッピングするための最も自然な方法は、multidestination先バッファの登録時に、すべての受信機が同じバッファのアドレスを生成することを要求することです。複数の宛先に対応するためDDPモデルの制限は、非DDP multidestination輸送能力を提供するのに匹敵エンジニアリングのトレードオフを必要とします。
A registered buffer is identified within DDP by its stag_t, which in turn is associated with a socket. Therefore, this registration grants a capability to the DDP peer, and the socket (using the underlying properties of its chosen transport and possible security) identifies the peer and authenticates the stag_t.
登録されたバッファは、順番に、ソケットに関連付けられ、そのstag_tによってDDP内で識別されます。したがって、この登録は、DDPピアに能力を付与し、そして（その選択されたトランスポートおよび可能なセキュリティの基本的性質を使用して）ソケットピアを識別しstag_tを認証します。
The same buffer may be enabled by ddp_post_recv() on multiple sockets. In this case any ddp_recv() untagged message reception indication may be provided on a different socket from that on which the buffer was posted. Such indications are not ordered among multiple DDP sockets.
同じバッファは、複数のソケットにddp_post_recv（）で有効にされてもよいです。この場合、任意ddp_recv（）タグなしメッセージ受信指示は、バッファが投稿されたものとは異なるソケットに設けられていてもよいです。このような表示は、複数のDDPソケットの間で順序付けされていません。
When multiple sockets reference an untagged message reception buffer, local interfaces are responsible for managing the mechanisms of allocating posted buffers to received untagged messages, the handling of received untagged messages when no buffer is available, and of resource management among multiple sockets. Where underprovisioning of buffers on multiple sockets is allowed, mechanisms should be provided to manage buffer consumption on a per-socket or group of related sockets basis.
複数のソケットがタグなしメッセージ受信バッファを参照する場合、ローカルインタフェースが受信したタグなしメッセージに転記バッファを割り当てるメカニズムを管理する責任があり、受信したタグなしメッセージの取り扱いないバッファが利用可能でない、および複数のソケットの間でのリソース管理の場合。複数のソケット上のバッファのunderprovisioningが許可されている場合、機構は、関連するソケットベースのソケット単位またはグループにバッファ消費を管理するために提供されるべきです。
Architecturally, therefore, DDP is a flexible and general paradigm that may be applied to any variety of transports. Implementations of DDP may, however, adapt themselves to these differences in ways appropriate to each transport. In all cases, the layering of DDP must continue to express the transport's underlying characteristics.
アーキテクチャは、従って、DDPは、トランスポートの任意の多様に適用することができる柔軟かつ一般的なパラダイムです。 DDPの実装は、しかし、各交通機関への適切な方法でこれらの違いに自分自身を適合させることができます。すべての場合において、DDPのレイヤーは、トランスポートの基本的な特性を発現し続ける必要があります。
Remote Direct Memory Access (RDMA) extends the capabilities of DDP with two primary functions.
リモートダイレクトメモリアクセス（RDMA）は、2つの主要な機能とDDPの機能を拡張します。
First, it adds the ability to read from buffers registered to a socket (RDMA Read). This allows a client protocol to perform arbitrary, bidirectional data movement without involving the remote client. When RDMA is implemented in hardware, arbitrary data movement can be performed without involving the remote host CPU at all.
まず、それはソケット（RDMA読み取り）に登録されたバッファから読み取る能力が追加されます。これは、クライアントプロトコルは、リモートクライアントを介さずに、任意の、双方向のデータ移動を行うことができます。 RDMAをハードウェアで実現する場合、任意のデータ移動は、すべてのリモートホストCPUを介さずに行うことができます。
In addition, RDMA specifies a transport-independent untagged message service (Send) with characteristics that are both very efficient to implement in hardware, and convenient for client protocols.
また、RDMAは、両方の非常にハードウェアで実装する効率的、およびクライアントプロトコルのための便利な特性を持つトランスポートに依存しないタグなしメッセージサービス（送信）を指定します。
The RDMA architecture is patterned after the traditional model for device programming, where the client requests an operation using Send-like actions (programmed I/O), the server performs the necessary data transfers for the operation (DMA reads and writes), and notifies the client of completion. The programmed I/O+DMA model efficiently supports a high degree of concurrency and flexibility for both the client and server, even when operations have a wide range of intrinsic latencies.
RDMAアーキテクチャはクライアントが送信状アクション（プログラムされたI / O）を使用して操作を要求するデバイスのプログラミングのための従来のモデル、後にパターニングされ、サーバは、必要なデータ操作のための転送（DMAは読み出しおよび書き込み）、及び通知を行います完了のクライアント。プログラムされたI / O + DMAモデルは、効率的に操作が固有の待ち時間の広い範囲を持っている場合でも、クライアントとサーバの両方のための並行性と高度な柔軟性をサポートしています。
RDMA is layered as a client protocol on top of DDP:
RDMAは、DDPの上のクライアントプロトコルとして積層されています。
Client Protocol
| ^
Sends | | Send reception indications
RDMA Read Requests | | RDMA Read Completion indications
RDMA Writes | | RDMA Write Completion indications
v |
RDMA
| ^
untagged messages | | untagged message delivery
tagged messages | | tagged message delivery
v |
DDP+---> data placement
^
| transport messages
v
. . .
In addition to in-line data flow, read (get()) and update (set()) operations are performed on buffers registered with RDMA as a result of RDMA Read Requests and RDMA Writes, respectively.
インラインデータフローに加えて、読み取り（取得（））および更新（セット（））操作は、RDMA読み取り要求の結果として、RDMAに登録バッファ上で実行され、RDMAは、それぞれ、書き込み。
An RDMA `buffer' extends a DDP buffer with a get() operation that retrieves the value of the octet at address `a':
RDMA `バッファは、「アドレス 'Aでオクテットの値を取得GET（）操作でDDPバッファを拡張します」：
typedef struct {
const address_t start;
const address_t end;
void set(address_t a, data_t v);
data_t get(address_t a);
} rdma_buffer_t;
The RDMA layer provides:
RDMA層が用意されています。
void rdma_send(socket_t s, message_t m);
void rdma_write(socket_t s, message_t m, ddp_addr_t d,
rdma_notify_t n);
void rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d);
void rdma_post_recv(socket_t s, bdesc_t b);
rdma_ind_t rdma_recv(socket_t s);
bdesc_t rdma_register(socket_t s, rdma_buffer_t b,
bmode_t mode);
void rdma_deregister(bhand_t bh);
msizes_t rdma_max_msizes(socket_t s);
Although, for clarity, these data transfer interfaces are synchronous, rdma_read() and possibly rdma_send() (in the presence of Send flow control) can require an arbitrary amount of time to complete. To express the full concurrency and interleaving of RDMA data transfer, these interfaces should also be reentrant. For example, a client protocol may perform an rdma_send(), while an rdma_read() operation is in progress.
明確にするために、これらのデータ転送インタフェースが同期している、が、（送信フロー制御の存在下で）rdma_read（）およびおそらくrdma_send（）が完了するまでの時間の任意の量を必要とすることができます。 RDMAデータ転送の完全な同時実行とインタリーブを表現するために、これらのインタフェースはまた、再入可能でなければなりません。 rdma_read（）操作の進行中に、例えば、クライアントプロトコルは、rdma_send（）を実行してもよいです。
rdma_notify_t
rdma_notify_t
RDMA Write notification information, used to signal that the
message represents the final fragment of a multi-segmented RDMA
message:
typedef struct {
boolean_t notify;
rdma_write_id_t i;
} rdma_notify_t;
identical in function to ddp_notify_t, except that the type rdma_write_id_t may not be equivalent to ddp_msg_id_t.
型rdma_write_id_tがddp_msg_id_tと等価ではないかもしれないことを除いて、ddp_notify_tする機能で同一です。
rdma_write_id_t (scalar)
rdma_write_id_t（スカラ）
an RDMA Write identifier.
RDMA書き込み識別子。
rdma_ind_t
rdma_ind_t
a Send message, or an RDMA error:
送信メッセージ、またはRDMAエラー：
typedef union {
recv_message_t m;
rdma_err_t e;
} rdma_ind_t;
rdma_err_t
rdma_err_t
an RDMA protocol error indication. RDMA errors include buffer
addressing errors corresponding to ddp_err_ts, and buffer
protection violations (e.g., RDMA Writing a buffer only
registered for reading).
bmode_t
bmode_t
buffer registration mode (permissions). Any combination of
permitting RDMA Read (BMODE_READ) and RDMA Write (BMODE_WRITE)
operations.
rdma_send(socket_t s, message_t m)
rdma_send（socket_t S、Mをmessage_t）
send a message, delivering it to the next untagged RDMA buffer
at the remote peer.
rdma_write(socket_t s, message_t m, ddp_addr_t d, rdma_notify_t n)
rdma_write（socket_t秒、message_t mを、ddp_addr_tのD、rdma_notify_t n）が
RDMA Write to remote buffer address d.
RDMAは、リモートバッファアドレスdに書きます。
rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)
rdma_read（socket_tだ、ddp_addr_t S、length_tリットル、ddp_addr_t d）は
RDMA Read l octets from remote buffer address s to local buffer
address d.
rdma_post_recv(socket_t s, bdesc_t b)
rdma_post_recv（socket_t S、bdesc_t B）
post a registered buffer to accept a single Send message, to be
filled and returned in-order to a subsequent caller of
rdma_recv(). As with DDP, buffers may be enabled on multiple
sockets, in which case ordering guarantees are relaxed. Also as
with DDP, local interfaces must manage the mechanisms of
allocation and management of buffers posted to multiple sockets.
rdma_recv(socket_t s);
rdma_recv（socket_t秒）。
get the next received Send message, RDMA Write completion
identifier, or RDMA error.
rdma_register(socket_t s, rdma_buffer_t b, bmode_t mode)
rdma_register（socket_t秒、rdma_buffer_tのBモードbmode_t）
register a buffer for RDMA on a socket (for read access, write
access or both). As with DDP, the same buffer may be registered
multiple times on the same or different sockets, and different
buffers may refer to portions of the same underlying addressable
object.
rdma_deregister(bhand_t bh)
rdma_deregister（bhand_tのBH）
remove a registration from a buffer.
バッファから登録を削除します。
rdma_max_msizes(socket_t s)
rdma_max_msizes（socket_t秒）
get the current maximum Send (max_untagged) and RDMA Read or
Write (max_tagged) operations that will fit in a single
transport message. The values returned by rdma_max_msizes() are
closely related to the values returned by ddp_max_msizes(), but
may not be equal.
As with DDP, RDMA can be used on transports with a variety of different characteristics that manifest themselves directly in the service provided by RDMA. Also, as with DDP, the fundamental characteristics of the transport will not be changed by the presence of RDMA.
DDPのように、RDMAは、RDMAによって提供されるサービスに直接現れる特性の異なる様々なトランスポート上で使用することができます。また、DDPと同様に、輸送の基本的な特性は、RDMAの存在によって変更されません。
Like DDP, an RDMA protocol must specify how:
DDPと同じように、RDMAプロトコルは、どのように指定する必要があります。
o set()s,
Oセット（）S、
o get()s,
Oを取得（）の、
o Send messages, and
Oメッセージを送信し、
o RDMA Read completions
RDMA読む補完O
are ordered among themselves and how they relate to corresponding operations on the remote peer(s). These relationships are likely to be a function of the underlying transport characteristics.
それらの間で注文し、それらがどのようにリモートピア（複数可）に対応する動作に関連しています。これらの関係は、基礎となる輸送特性の関数である可能性が高いです。
There are some additional characteristics of RDMA that may translate poorly to unreliable or multipoint transports due to attendant complexities in managing endpoint state:
信頼できない、またはマルチポイントに不十分翻訳することができるRDMAのいくつかの追加の特徴があり、エンドポイントの状態を管理する上で付随する複雑さのために輸送しています。
o Send flow control
Oフロー制御を送信
o RDMA Read
O RDMA読みます
These difficulties can be overcome by placing restrictions on the service provided by RDMA. However, many RDMA clients, especially those that separate data transfer and application logic concerns, are likely to depend upon capabilities only provided by RDMA on a point-to-point, reliable transport. In other words, many potential Upper Layers, which might avail themselves of RDMA services, are naturally already biased toward these transport classes.
これらの困難は、RDMAが提供するサービスに制限を置くことによって克服することができます。しかし、多くのRDMAクライアントのデータ転送とアプリケーションロジックの問題を分離している、特には、唯一のポイント・ツー・ポイント、信頼性の高い輸送上のRDMAが提供する機能に依存する可能性があります。言い換えれば、RDMAサービスの自分自身を役に立つかもしれない多くの潜在的な上位層は、自然にすでにこれらのトランスポート・クラスに偏っています。
Fundamentally, the DDP and RDMA protocols themselves should not introduce additional vulnerabilities. They are intermediate protocols and so should not perform or require functions such as authorization, which are the domain of Upper Layers. However, the DDP and RDMA protocols should allow mapping by strict Upper Layers that are not permissive of new vulnerabilities; DDP and RDMAP implementations should be prohibited from `cutting corners' that create new vulnerabilities. Implementations must ensure that only `supplied' resources (i.e., buffers) can be manipulated by DDP or RDMAP messages.
基本的に、DDPとRDMAプロトコル自体は、追加の脆弱性を導入してはなりません。彼らは、上位層のドメインです中間プロトコルとそうな承認などの機能を実行したり、要求すべきではない、です。しかし、DDPとRDMAプロトコルは、新しい脆弱性の許容されない厳格な上位層でのマッピングを可能にしなければなりません。 DDPとRDMAP実装は、新しい脆弱性を作成 `切削コーナーから禁止されるべきです。実装は、 `供給」リソース（すなわち、バッファ）がDDPまたはRDMAPメッセージによって操作することができることを確認しなければなりません。
System integrity must be maintained in any RDMA solution. Mechanisms must be specified to prevent RDMA or DDP operations from impairing system integrity. For example, threats can include potential buffer reuse or buffer overflow, and are not merely a security issue. Even trusted peers must not be allowed to damage local integrity. Any DDP and RDMA protocol must address the issue of giving end-systems and applications the capabilities to offer protection from such compromises.
システムの整合性は、任意のRDMA溶液中で維持しなければなりません。メカニズムは、システムの完全性を損なうからRDMAかDDP操作を防ぐために指定する必要があります。たとえば、脅威が潜在的なバッファの再利用やバッファオーバーフローを含め、単にセキュリティ上の問題ではありませんすることができます。でも、信頼されたピアは、地元の整合性を損傷することは許されない必要があります。どれDDPとRDMAプロトコルは、このような妥協からの保護を提供するために、エンド・システムとアプリケーションに機能を与えることの問題に対処しなければなりません。
Because a Steering Tag exports access to a buffer, one critical aspect of security is the scope of this access. It must be possible to individually control specific attributes of the access provided by a Steering Tag on the endpoint (socket) on which it was registered, including remote read access, remote write access, and others that might be identified. DDP and RDMA specifications must provide both implementation requirements relevant to this issue, and guidelines to assist implementors in making the appropriate design decisions.
ステアリングタグ輸出はバッファにアクセスするので、セキュリティの一つの重要な側面は、このアクセスの範囲です。個別に識別される可能性があります、それがリモート読み取りアクセス、リモート書き込みアクセス、およびその他を含む、登録されたエンドポイント（ソケット）にステアリングタグによって提供されるアクセスの特定の属性を制御することが可能でなければなりません。 DDPとRDMA仕様は、実装、この問題に関連する要求事項、および適切な設計上の決定を行う際に実装を支援するためのガイドラインの両方を提供する必要があります。
For example, it must not be possible for DDP to enable evasion of buffer consistency checks at the recipient. The DDP and RDMA specifications must allow the recipient to rely on its consistent buffer contents by explicitly controlling peer access to buffer regions at appropriate times.
DDPは、受信者のバッファの一貫性チェックの回避を可能にするために、例えば、それが可能であってはなりません。 DDPとRDMA仕様は、受信者が明示的に適切なタイミングでバッファ領域へのピアのアクセスを制御することによって、その一貫性のあるバッファの内容に依存できるようにする必要があります。
The use of DDP and RDMA on a transport connection may interact with any security mechanism, and vice-versa. For example, if the security mechanism is implemented above the transport layer, the DDP and RDMA headers may not be protected. Therefore, such a layering may be inappropriate, depending on requirements.
トランスポート接続上のDDPとRDMAの使用は、任意のセキュリティメカニズム、およびその逆と相互作用することができます。セキュリティメカニズムは、トランスポート層の上に実装されている場合、例えば、DDPとRDMAヘッダは保護されなくてもよいです。したがって、このような積層は、要件に応じて、不適切であってもよいです。
The following end-to-end security services protect DDP and RDMAP operation streams:
以下のエンドツーエンドのセキュリティサービスは、DDPとRDMAP操作ストリームを保護します：
o Authentication of the data source, to protect against peer impersonation, stream hijacking, and man-in-the-middle attacks exploiting capabilities offered by the RDMA implementation.
データ・ソースのO認証は、ピア偽装、ストリームハイジャック、及びRDMA実装によって提供される機能を利用するman-in-the-middle攻撃から保護します。
Peer connections that do not pass authentication and
authorization checks must not be permitted to begin processing
in RDMA mode with an inappropriate endpoint. Once associated,
peer accesses to buffer regions must be authenticated and made
subject to authorization checks in the context of the
association and endpoint (socket) on which they are to be
performed, prior to any transfer operation or data being
accessed. The RDMA protocols must ensure that these region
protections be under strict application control.
o Integrity, to protect against modification of the control content and buffer content.
O整合性は、制御内容の変更から保護し、コンテンツをバッファリングします。
While integrity is of concern to any transport, it is
important for the DDP and RDMAP protocols that the RDMA
control information carried in each operation be protected, in
order to direct the payloads appropriately.
o Sequencing, to protect against replay attacks (a special case of the above modifications).
Oシーケンシング、リプレイ攻撃（上記変形例の特別な場合）から保護します。
o Confidentiality, to protect the stream from eavesdropping.
守秘義務O、盗聴からのストリームを保護します。
IPsec, operating to secure the connection on a packet-by-packet basis, is a natural fit to securing RDMA placement, which operates in conjunction with transport. Because RDMA enables an implementation to avoid buffering, it is preferable to perform all applicable security protection prior to processing of each segment by the transport and RDMA layers. Such a layering enables the most efficient secure RDMA implementation.
IPsecは、パケットごとの接続を確保するために動作し、輸送と連動して動作RDMAの配置を、安全に自然にフィットです。 RDMAバッファリングを避けるために、実装を可能にするので、輸送とRDMA層によって、各セグメントの処理に先立って適用されるすべてのセキュリティ保護を行うことが好ましいです。このような積層化は、最も効率的な安全なRDMAの実装を可能にします。
The TLS record protocol, on the other hand, is layered on top of reliable transports and cannot provide such security assurance until an entire record is available, which may require the buffering and/or assembly of several distinct messages prior to TLS processing. This defers RDMA processing and introduces overheads that RDMA is designed to avoid. In addition, TLS length restrictions on records themselves impose additional buffering and processing for long operations that must span multiple records. TLS therefore is viewed as potentially a less natural fit for protecting the RDMA protocols.
TLSレコード・プロトコルは、一方で、信頼性の高いトランスポートの上に積層され、レコード全体が前TLS処理にいくつかの別個のメッセージのバッファリングおよび/または組み立てを必要とすることができる、利用可能になるまで、セキュリティの保証を提供することができません。これは、RDMA処理を延期し、RDMAを回避するように設計されたオーバーヘッドを紹介しています。また、記録上のTLSの長さの制限は、それ自体が複数のレコードにまたがる必要があり、長い操作のために、追加のバッファリングと処理を課します。 TLSは、したがって、RDMAプロトコルを保護するための潜在的に少ない自然なフィット感と見られています。
Any DDP and RDMAP specification must provide the means to satisfy the above security service requirements.
どれDDPとRDMAP仕様は、上記のセキュリティサービスの要件を満たすための手段を提供しなければなりません。
IPsec is sufficient to provide the required security services to the DDP and RDMAP protocols, while enabling efficient implementations.
IPsecは、効率的な実装を可能にしながら、DDPとRDMAPプロトコルに必要なセキュリティサービスを提供するのに十分です。
Resource issues leading to denial-of-service attacks, overwrites and other concurrent operations, the ordering of completions as required by the RDMA protocol, and the granularity of transfer are all within the required scope of any security analysis of RDMA and DDP.
リソース、サービス拒否攻撃につながる問題、上書きされ、他の並行操作、RDMAプロトコルによって要求されるように補完の順序、および転送の粒度は、RDMAおよびDDPのいずれかのセキュリティ分析の必要な範囲内ですべてです。
The RDMA operations require checking of what is essentially user information, explicitly including addressing information and operation type (read or write), and implicitly including protection and attributes. The semantics associated with each class of error resulting from possible failure of such checks must be clearly defined, and the expected action to be taken by the protocols in each case must be specified.
RDMA操作は明示的な情報と操作タイプを（読み取りまたは書き込み）のアドレス指定、および暗黙的に保護や属性などを含め、基本的にユーザー情報が何であるかの確認が必要です。このようなチェックの可能性のある故障に起因する誤差の各クラスに関連付けられたセマンティクスは明確に定義されなければならない、と予想されるアクションを指定する必要があり、各場合におけるプロトコルによって取られます。
In some cases, this will result in a catastrophic error on the RDMA association; however, in others, a local or remote error may be signalled. Certain of these errors may require consideration of abstract local semantics. The result of the error on the RDMA association must be carefully specified so as to provide useful behavior, while not constraining the implementation.
いくつかのケースでは、これは、RDMA協会に壊滅的なエラーになります。しかし、他に、ローカルまたはリモートのエラーを通知してもよいです。これらのエラーの一部は抽象地元のセマンティクスの検討を必要とするかもしれません。実装を制約するものではないが、有益な動作を提供するようにRDMA協会のエラーの結果は、慎重に指定する必要があります。
The authors wish to acknowledge the valuable contributions of Caitlin Bestler, David Black, Jeff Mogul, and Allyn Romanow.
著者はケイトリンBestler、デビッド・ブラック、ジェフムガール人、およびアリンRomanowの貴重な貢献を認めることを望みます。
[FCVI] ANSI Technical Committee T11, "Fibre Channel Standard Virtual Interface Architecture Mapping", ANSI/NCITS 357- 2001, March 2001, available from http://www.t11.org/t11/stat.nsf/fcproj.
http://www.t11.org/t11/stat.nsf/fcprojから入手[FCVI] ANSI T11技術委員会、 "ファイバチャネル標準仮想インタフェース・アーキテクチャのマッピング"、ANSI / NCITS 357- 2001年、2001年3月、。
[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification Volumes 1 and 2", Release 1.1, November 2002, available from http://www.infinibandta.org/specs.
[IB]インフィニバンド展覧会、 "インフィニバンドアーキテクチャ仕様ボリューム1及び2"、http://www.infinibandta.org/specsから入手1.1、2002年11月にリリース。
[MYR] VMEbus International Trade Association, "Myrinet on VME Protocol Specification", ANSI/VITA 26-1998, August 1998, available from http://www.myri.com/open-specs.
[MYR] VMEbusの貿易協会、http://www.myri.com/open-specsから入手可能、ANSI / VITA 26から1998まで、1998年8月、 "VMEプロトコル仕様上のMyrinet"。
[ROM] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote Direct Memory Access (RDMA) over IP Problem Statement", RFC 4297, December 2005.
[ROM] Romanow、A.、モーグル、J.、Talpey、T.、およびS.ベイリー、 "リモートダイレクトメモリアクセスIP問題文上（RDMA）"、RFC 4297、2005年12月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[SDP] InfiniBand Trade Association, "Sockets Direct Protocol v1.0", Annex A of InfiniBand Architecture Specification Volume 1, Release 1.1, November 2002, available from http://www.infinibandta.org/specs.
[SDP]インフィニバンド展覧会、「ソケット直接プロトコルv1.0を」、インフィニバンドアーキテクチャ仕様の第1巻の附属書A、1.1をリリース、2002年11月、http://www.infinibandta.org/specsから入手できます。
[SRVNET] R. Horst, "TNet: A reliable system area network", IEEE Micro, pp. 37-45, February 1995.
[SRVNET] R.ホルスト、 "Tネット：信頼性の高いシステム・エリア・ネットワーク"、IEEEマイクロ、頁37-45、1995年2月。
[VI] D. Cameron and G. Regnier, "The Virtual Interface Architecture", ISBN 0971288704, Intel Press, April 2002, more info at http://www.intel.com/intelpress/via/.
[VI] D.キャメロンとG.レニエ、 "仮想インターフェイスアーキテクチャ"、ISBN 0971288704、インテルプレス、2002年4月、http://www.intel.com/intelpress/via/の詳細情報。
Authors' Addresses
著者のアドレス
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA USA
スティーブン・ベイリーSandburst社600連邦ストリートアンドーバー、MA 01810 USA USA
Phone: +1 978 689 1614 EMail: steph@sandburst.com
電話：+1 978 689 1614 Eメール：steph@sandburst.com
Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA
トムTalpeyネットワーク・アプライアンス1601 Trapelo道路ウォルサム、MA 02451 USA
Phone: +1 781 768 5329 EMail: thomas.talpey@netapp.com
電話：+1 781 768 5329 Eメール：thomas.talpey@netapp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。