[要約] RFC 4296は、インターネットプロトコル上でのDirect Data Placement（DDP）とRemote Direct Memory Access（RDMA）のアーキテクチャについての要約です。このRFCの目的は、DDPとRDMAの実装と使用に関するガイドラインを提供することです。
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
インターネットプロトコル上の直接データ配置（DDP）とリモートダイレクトメモリアクセス（RDMA）のアーキテクチャ
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).
Copyright（c）The Internet Society（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）プロトコルの抽象アーキテクチャを定義します。このアーキテクチャは、必ずしもそのようなプロトコルを実装する適切な方法を反映するわけではありませんが、むしろ、プロトコルを定義および理解するための記述ツールです。このドキュメントでは、C言語表記を速記として使用して、DDPおよびRDMAプロトコルのアーキテクチャ要素を説明しています。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が構築されるトランスポートについてどのような仮定が行われているかが含まれます。2番目の部分では、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アーキテクチャの中央コンポーネントは、「バッファ」であり、これはアドレスと終了アドレスを持つオブジェクトと、アドレスにオクテットの値を設定するメソッド（set（））です。多くの場合、バッファーはホストユーザーメモリの一部に直接対応します。ただし、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はタグ付きメッセージを受信した結果としてバッファーアップデート（set（））操作を実行します。
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.
IPアドレス、ポート、その他の輸送固有の識別子を含む輸送アドレス。
message_t
message_t
a string of octets.
オクテットの文字列。
msize_t (scalar)
msize_t（scalar）
a message size.
メッセージサイズ。
xpt_send(socket_t s, message_t m)
xpt_send（socket_t s、message_t m）
send a transport message.
トランスポートメッセージを送信します。
xpt_recv(socket_t s)
xpt_recv（socket_t s）
receive a transport message.
トランスポートメッセージを受信します。
xpt_max_msize(socket_t s)
xpt_max_msize（socket_t s）
get the current maximum transport message size. Corresponds, roughly, to the current path Maximum Transfer Unit (PMTU), adjusted by underlying protocol overheads.
現在の最大輸送メッセージサイズを取得します。大まかに、基礎となるプロトコルオーバーヘッドによって調整された現在のパス最大転送ユニット（PMTU）に対応します。
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（scalar）
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.
ステアリングタグ。STAG_Tは、タグ付きメッセージの宛先バッファを識別します。STAG_TSは、バッファーが登録されたときに生成され、クライアントプロトコルコンベンションによって送信者に通信され、DDPメッセージに挿入されます。このDDPアーキテクチャのSTAG_T値は、クライアントプロトコルに完全に不透明であると想定されており、実装依存です。ただし、マルチキャストトランスポートのDDPなどの特定の実装（以下を参照）は、STAG_Tを選択する際にバッファホルダーに何らかの制御を提供する場合があります。
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:
メッセージがマルチセグメントDDPメッセージの最終的なフラグメントを表すことを示すために使用されるDDPメッセージの通知部分：
typedef struct {
boolean_t notify;
ddp_msg_id_t i;
} ddp_notify_t;
ddp_msg_id_t (scalar)
ddp_msg_id_t（scalar）
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.
DDPメッセージ識別子。MSG_ID_TSは、DDPメッセージレシーバー（バッファーホルダー）によって選択され、一部のクライアントプロトコルコンベンションによって送信者に通信され、DDPメッセージに挿入されます。DDPメッセージのメッセージ受信表示が要求されるかどうかは、クライアントプロトコル条約の問題です。STAG_TSとは異なり、MSG_ID_TSの構造はDDPに不透明であるため、クライアントプロトコルの手に完全になります。
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.
タグ付けされたメッセージの受信中のエラー、通常は「オフセット」が境界外であるか、「Stag」がソケットに登録されていないことを示します。
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、message_t m）
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 s、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（）未編成メッセージ受信表示で、投稿された順序で発信者に返されます。複数のソケットで同じバッファを有効にする場合があります。これらのソケットのいずれかからバッファーへの攻撃されていないメッセージを受け取ると、すべてのソケットからバッファーが公開されません。
ddp_recv(socket_t s)
ddp_recv（socket_t s）
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 s、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のバッファーを登録します。同じバッファーが同じまたは異なるソケットに複数回登録される場合があります。異なるソケットに登録されている同じバッファーが共通の登録になる場合があります。異なるバッファーは、同じ基礎となるアドレス指定可能なオブジェクト（バッファエイリアシング）の一部を指す場合があります。
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 s）
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 set（）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.
バッファーアクセスは、たとえばSCTPなど、エンドポイントごとに複数のIPアドレスを許可するトランスポート上のエンドポイントIPアドレス全体で一貫して実装する必要があります。特に、ステアリングタグは一貫してスコープされている必要があり、エンドポイントに属するすべてのIPアドレス関連で同じバッファーに対処する必要があります。さらに、Association（set（）、get（）など）内の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.
マルチディステーションデータ配信は、DDPプロトコルで特定の考慮を必要とする可能性のある輸送特性です。上記のように、基本的なDDPモデルは、ddp_register（）によって返されたバッファーアドレス値がクライアントプロトコルに不透明であり、実装に依存する可能性があると想定しています。DDPをマルチディステーショントランスポートにマッピングする最も自然な方法は、マルチデスティング宛先バッファーを登録するときにすべての受信機が同じバッファーアドレスを生成することを要求することです。DDPモデルの制限複数の目的地に対応するには、非DDPマルチデスティング輸送能力を提供するエンジニアリングトレードオフに匹敵するエンジニアリングトレードオフが含まれます。
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（）agged gagedメッセージ受信表示は、バッファーが投稿されたソケットとは異なるソケットに提供される場合があります。このような適応症は、複数の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.
複数のソケットが未編成のメッセージ受信バッファーを参照する場合、ローカルインターフェイスは、掲示されたバッファーを受け取っていないメッセージに割り当てるメカニズム、バッファーが利用できないときに受信された未編成メッセージの処理、および複数のソケット間のリソース管理のメカニズムを管理する責任があります。複数のソケットでのバッファーの不足が許可されている場合は、関連するソケットごとのグループまたはグループでバッファ消費を管理するためにメカニズムを提供する必要があります。
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に登録されたバッファーで読み取り（get（））およびupdate（set（））操作が実行されます。
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_SEND（）を実行し、RDMA_READ（）操作が進行中です。
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:
RDMAは、メッセージがマルチセグメント化されたRDMAメッセージの最終的な断片を表すことを示すために使用される通知情報を書き込みます。
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（scalar）
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).
RDMAプロトコルエラーの表示。RDMAエラーには、DDP_ERR_TSに対応するバッファアドレス指定エラー、およびバッファー保護違反（たとえば、RDMAが読み取り用にのみ登録されているバッファーの書き込み）が含まれます。
bmode_t
bmode_t
buffer registration mode (permissions). Any combination of permitting RDMA Read (BMODE_READ) and RDMA Write (BMODE_WRITE) operations.
バッファ登録モード（許可）。許可RDMA読み取り（bmode_read）とrdma write（bmode_write）操作の任意の組み合わせ。
rdma_send(socket_t s, message_t m)
rdma_send（socket_t s、message_t m）
send a message, delivering it to the next untagged RDMA buffer at the remote peer.
メッセージを送信して、リモートピアの次の未編成のRDMAバッファーに配信します。
rdma_write(socket_t s, message_t m, ddp_addr_t d, rdma_notify_t n)
rdma_write（socket_t s、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 s、ddp_addr_t s、length_t l、ddp_addr_t d）
RDMA Read l octets from remote buffer address s to local buffer address d.
RDMAは、リモートバッファーアドレスからローカルバッファーアドレスまでLオクテットを読み取ります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（）の後続の呼び出し者に注文して返します。DDPと同様に、複数のソケットでバッファーを有効にする場合があります。この場合、注文保証は緩和されます。また、DDPと同様に、ローカルインターフェイスは、複数のソケットに投稿されたバッファーの割り当てと管理のメカニズムを管理する必要があります。
rdma_recv(socket_t s);
rdma_recv（socket_t s）;
get the next received Send message, RDMA Write completion identifier, or RDMA error.
次に受信した送信メッセージ、RDMA書き込み完了識別子、またはRDMAエラーを取得します。
rdma_register(socket_t s, rdma_buffer_t b, bmode_t mode)
rdma_register（socket_t s、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のバッファーをソケットに登録します（読み取りアクセス、書き込みアクセス、またはその両方）。DDPと同様に、同じバッファーを同じまたは異なるソケットに複数回登録することができ、異なるバッファーは同じ基礎となるアドレス指定可能なオブジェクトの一部を指す場合があります。
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 s）
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.
単一のトランスポートメッセージに適合する現在の最大送信（MAX_UNTAGGED）およびRDMAの読み取りまたは書き込み（MAX_TAGGED）操作を取得します。rdma_max_msizes（）によって返される値は、ddp_max_msizes（）によって返される値に密接に関連していますが、等しくない場合があります。
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 set（）s、
o get()s,
o 取得、
o Send messages, and
o メッセージを送信します
o RDMA Read completions
o RDMA読み取り完了
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.
ステアリングタグはバッファーへのアクセスをエクスポートするため、セキュリティの重要な側面の1つはこのアクセスの範囲です。リモート読み取りアクセス、リモート書き込みアクセス、その他識別される可能性のある他のものなど、登録されたエンドポイント（ソケット）のステアリングタグ（ソケット）によって提供されるアクセスの特定の属性を個別に制御することができなければなりません。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の実装によって提供される機能を活用する中間攻撃から保護するためのデータソースの認証。
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.
認証と認証チェックに合格しないピア接続は、不適切なエンドポイントでRDMAモードで処理を開始することを許可してはなりません。関連すると、バッファー領域へのピアアクセスは認証され、転送操作またはデータにアクセスされる前に、それらが実行されるエンドポイント（ソケット）のコンテキストで認証チェックを受ける必要があります。RDMAプロトコルは、これらの地域の保護が厳密なアプリケーション管理下にあることを確認する必要があります。
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.
整合性はあらゆる輸送に懸念がありますが、ペイロードを適切に指示するために、各操作で運ばれるRDMA制御情報を保護することがDDPおよびRDMAPプロトコルにとって重要です。
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.
著者は、Caitlin Bestler、David Black、Jeff Mogul、およびAllyn 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.
[FCVI] ANSI技術委員会T11、「ファイバーチャネル標準仮想インターフェイスアーキテクチャマッピング」、ANSI/NCITS 357- 2001、2001年3月、http：//www.t11.org/t11/stat.nsf/fcprojから入手可能。
[IB] InfiniBand Trade Association, "InfiniBand Architecture Specification Volumes 1 and 2", Release 1.1, November 2002, available from http://www.infinibandta.org/specs.
[IB] Infiniband Trade Association、「Infiniband Architecture Specification Bolumes 1 and 2」、リリース1.1、2002年11月、http：//www.infinibandta.org/specsから入手可能。
[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 International Trade Association、「Myrinet on VME Protocol Specification」、ANSI/VITA 26-1998、1998年8月、http：//www.myri.com/open-pecsから入手可能。
[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.、Mogul、J.、Talpey、T。、およびS. Bailey、「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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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] Infiniband Trade Association、「Sockets Direct Protocol V1.0」、Infiniband Architecture Specification Volume 1、Release 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. Horst、「TNET：信頼できるシステムエリアネットワーク」、IEEE Micro、pp。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. Cameron and G. Regnier、「Virtual Interface Architecture」、ISBN 0971288704、Intel Press、2002年4月、http：//www.intel.com/intelpress/via/の詳細情報。
Authors' Addresses
著者のアドレス
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA USA
Stephen Bailey Sandburst Corporation 600 Federal Street Andover、MA 01810 USA USA
Phone: +1 978 689 1614
EMail: steph@sandburst.com
Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA
Tom Talpey Networkアプライアンス1601 Trapelo Road Waltham、MA 02451 USA
Phone: +1 781 768 5329
EMail: thomas.talpey@netapp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。