RFC4296 日本語訳
4296 The Architecture of Direct Data Placement (DDP) and Remote DirectMemory Access (RDMA) on Internet Protocols. S. Bailey, T. Talpey. December 2005. (Format: TXT=43907 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bailey
Request for Comments: 4296 Sandburst
Category: Informational T. Talpey
NetApp
December 2005
コメントを求めるワーキンググループS.べイリー要求をネットワークでつないでください: 4296年のSandburstカテゴリ: 情報のT.Talpey NetApp2005年12月
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)インターネット協会(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.
Direct Data Placement(DDP)とRemote Direct Memory Access(RDMA)プロトコルがインターネットプロトコルスイート輸送で動くように、このドキュメントは抽象的なアーキテクチャを定義します。 このアーキテクチャは、必ずそのようなプロトコルを実装する適切な方法を反映するというわけではありませんが、むしろプロトコルを定義して、理解するための描写的であるツールです。 DDPはUpper Layerプロトコル(例えば、RDMA)によって指定されたバッファの中にデータの効率的なプレースメントを許容します。 RDMAは、ある意味でアプリケーション要件と一致した同輩の間のRemote Direct Memory Accessを有効にするために意味論を提供します。
Bailey & Talpey Informational [Page 1] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[1ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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
1. 序論…2 1.1. 用語…2 1.2. DDPとRDMAプロトコル…3 2. アーキテクチャ…4 2.1. データプレースメント(DDP)プロトコルアーキテクチャを指示してください…4 2.1.1. 操作を輸送してください…6 2.1.2. DDP操作…7 2.1.3. DDPにおける特性を輸送してください…10 2.2. リモートダイレクトメモリアクセス(RDMA)はアーキテクチャについて議定書の中で述べます。12 2.2.1. RDMA操作…14 2.2.2. RDMAで特性を輸送してください…16 3. セキュリティ問題…17 3.1. セキュリティサービス…18 3.2. 誤り問題…19 4. 承認…19 5. 有益な参照…20
1. Introduction
1. 序論
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.
Direct Data Placement(DDP)とRemote Direct Memory Access(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プロトコルのアーキテクチャについて説明します。
1.1. Terminology
1.1. 用語
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 操作--、プロトコルメッセージ、または提供されるメッセージの系列、建築、データバッファを読むか、または主題にして書くのなどように、意味的です。
Bailey & Talpey Informational [Page 2] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[2ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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 配送--特定のメッセージが使用に利用可能であることをどんなUpper Layerやアプリケーションにも知らせます。 したがって、「コントロール」信号がデータのユニットと交際したので、配送は見られるかもしれません。 配送の注文がそれがプレースメントのためのものであるより厳密に定義されることに注意してください。
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 完成--特定の操作が終わったことをどんなUpper Layerやアプリケーションにも知らせます。 例えば、完成がいくつかのメッセージの配送を必要とするかもしれませんか、またはまた、何らかのローカル処理が終わったのは反射するかもしれません。
o Data Sink - the peer on which any placement occurs.
o データSink--どんなプレースメントも起こる同輩。
o Data Source - the peer from which the placed data originates.
o データSource--置かれたデータが起因する同輩。
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 操縦Tag--「ハンドル」は以前はよくプレースメントの目標であるバッファを特定していました。 「タグ付けをされた」メッセージはそのようなハンドルに参照をつけるものです。
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 Write--ローカルのデータバッファからリモートデータバッファまでデータを置くOperationはSteering Tagで指定しました。
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 Read--ローカルのデータバッファにデータを置くOperationはSteering Tagで別のSteering Tagによって指定されたリモートデータバッファから指定しました。
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 発信してください--ローカルのデータバッファからリモートデータ受信端末の選択のデータバッファまでデータを置くOperation。 したがって、発信する、"非タグ付け"です。
1.2. DDP and RDMA Protocols
1.2. DDPとRDMAプロトコル
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プロトコルの目標はある意味でアプリケーション要件と一致した同輩の間のRemote Direct Memory Accessを有効にするために意味論を提供することです。 RDMAプロトコルはすぐに存在、将来のネットワーク、ストレージ、および他のアプリケーション・プロトコルの役に立つ施設を提供します。 [FCVI、イブ、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
DDPとRDMAプロトコルは、それらのそれぞれの目標を達成するために一緒に働いています。 DDPは、安全にペイロードをData Sinkの特定のバッファに導くために便宜を与えます。 RDMAは、データ転送を制御して、これらのバッファを特定するためにUpper Layersに便宜を与えます。
Bailey & Talpey Informational [Page 3] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[3ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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.
同輩のバッファの間では、サポートするのはバッファと、合図完成の間の双方向の転送を認可しました。 RDMAの特徴を必要としない上側のLayerプロトコルは直接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プロトコルと、Transportとの関係を示しています。
+--------------------------------------------------+
| Upper Layer Protocol |
+---------+------------+---------------------------+
| | | RDMA |
| | +---------------------------+
| | DDP |
| +----------------------------------------+
| Transport |
+--------------------------------------------------+
+--------------------------------------------------+ | 上側の層のプロトコル| +---------+------------+---------------------------+ | | | RDMA| | | +---------------------------+ | | DDP| | +----------------------------------------+ | 輸送| +--------------------------------------------------+
2. Architecture
2. アーキテクチャ
The Architecture section is presented in two parts: Direct Data Placement Protocol architecture and Remote Direct Memory Access Protocol architecture.
Architecture部は2つの部品に提示されます: Data PlacementプロトコルアーキテクチャとRemote Direct Memory Accessプロトコルアーキテクチャを指示してください。
2.1. Direct Data Placement (DDP) Protocol Architecture
2.1. ダイレクトデータプレースメント(DDP)プロトコルアーキテクチャ
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;
{_tが始めであるとconstに扱ってください;constアドレス_tエンド(空集合(アドレス_t a、データ_t v))}というtypedef struct ddp_バッファ_t。
Bailey & Talpey Informational [Page 4] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[4ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
address_t
アドレス_t
a reference to local memory
ローカルの記憶の参照
data_t
データ_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
. . .
DDPクライアントプロトコル(例えば、RDMAか上側の層のプロトコル)| ^はメッセージに非タグ付けをしました。| | メッセージの配送のタグ付けをされたメッセージに非タグ付けをしました。| | タグ付けをされたメッセージ配送v| DDP+--->データプレースメント^| 輸送メッセージ対Transport(例えば、SCTP(DCCP)はTCPを縁どった)^| IPデータグラム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メッセージの中と、そして、それぞれ別々の輸送メッセージで分けられるかもしれません。 しかしながら、輸送が頼り無いか、または順不同のである、輸送メッセージの向こう側に分けられたメッセージは役に立つ振舞いを提供するかもしれません、頼り無いか順不同の輸送メッセージの向こう側に任意のUpper Layerメッセージを分けると役に立つ振舞いが提供されるかもしれないのと同様に。 言い換えれば、同じ問題は異なったタイプの輸送のときにDDPの使用のあるなしにかかわらずビルクライアントプロトコルに適用されます。
Bailey & Talpey Informational [Page 5] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[5ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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|
雄ジカはs、オフセット=o、メッセージ1と等しいです: =y、イド=iに通知してください。|=ddpをタイプしてください。| メッセージ=|雄ジカ=s| |aabbccddee|-------. |=oを相殺してください。| ~ ... ~----. \ |=nに通知してください。| |vvwwxxyyzz|-. \ \ |イド=?| | \ `--->|aabbccddee| | \ ~ ... ~ | +----->|iijjkkllmm| | | + | メッセージ2: \ | |=ddpをタイプしてください。| \ | |雄ジカ=s| \ + |=o+nを相殺してください。| \ \ |=yに通知してください。| \ \ |イド=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情報の成分は、また、輸送特有の分野にあるか、または輸送の特定の制御情報から導かれるかもしれません。
2.1.1. Transport Operations
2.1.1. 輸送業務
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);
空のxpt_は発信します(ソケット_t s、メッセージ_t m)。 メッセージ_t xpt_recv(ソケット_t s)。 msize_t xpt_最大_msize(ソケット_t s)。
socket_t
ソケット_t
a transport address, including IP addresses, ports and other
transport-specific identifiers.
IPアドレス、ポート、および他の輸送特有の識別子を含む輸送アドレス。
message_t
メッセージ_t
a string of octets.
一連の八重奏。
Bailey & Talpey Informational [Page 6] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[6ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
msize_t (scalar)
msize_t(スカラ)です。
a message size.
メッセージサイズ。
xpt_send(socket_t s, message_t m)
xpt_は発信します。(ソケット_t s、メッセージ_t m)
send a transport message.
輸送メッセージを送ってください。
xpt_recv(socket_t s)
xpt_recv(ソケット_t s)
receive a transport message.
輸送メッセージを受け取ってください。
xpt_max_msize(socket_t s)
xpt_最大_msize(ソケット_t s)
get the current maximum transport message size. Corresponds,
roughly, to the current path Maximum Transfer Unit (PMTU),
adjusted by underlying protocol overheads.
現在の最大の輸送メッセージサイズを得てください。 およそ、基本的なプロトコルオーバーヘッドによって調整された現在の経路Maximum Transfer Unit(PMTU)に対応しています。
Real implementations of xpt_send() and xpt_recv() typically return error indications, but that is not relevant to this architecture.
xpt_の本当の実装はrecv()が通常返す()とxpt_に誤り指摘を送りますが、それはこのアーキテクチャに関連していません。
2.1.2. DDP Operations
2.1.2. DDP操作
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_は発信します(ソケット_t s、メッセージ_t m)。 空のddp_は_ddpを送ります(ソケット_t s、メッセージ_t m、ddp_addr_t d、ddp_は_t nに通知します)。 _ddp_ポストrecv(ソケット_t s、bdesc_t b)を欠如させてください。 ddp_ind_t ddp_recv(ソケット_t s)。 bdesc_t ddp_レジスタ(ソケット_t s、ddp_バッファ_t b)。 ddp_「反-レジスタ」(bhand_t bh)を欠如させてください。 msizes_t ddp_最大_msizes(ソケット_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;
typedef struct雄ジカ_t雄ジカ; _tが相殺したアドレス;ddp_addr_t。
stag_t (scalar)
雄ジカ_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
操縦タグ。 雄ジカ_tはタグ付けをされたメッセージのための目的地バッファを特定します。バッファが何らかのクライアントプロトコルによって送付者と登録されて、コミュニケートされているとき、雄ジカ_tは発生しています。
Bailey & Talpey Informational [Page 7] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[7ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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アーキテクチャの値がクライアントプロトコルに完全に不透明であって、実装依存していると思われるDDPメッセージ雄ジカ_tに挿入されています。 しかしながら、マルチキャスト輸送(以下を見る)でのDDPなどの特定の実装は男一人で_tを選択する際に何らかのコントロールをバッファ所有者に供給するかもしれません。
ddp_notify_t
ddp_は_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;
論理演算子_tが通知する; ddp_msg_イド_t i;typedef structはddpされます。__tに通知してください。
ddp_msg_id_t (scalar)
ddp_msg_イド_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.
. msg_イド_tがいくらかのクライアントプロトコルコンベンションによって送付者に伝えられて、DDPメッセージに挿入されたDDPメッセージ受信機(バッファ所有者)によって選ばれているDDPメッセージ識別子。 メッセージレセプション指示がDDPメッセージのために要求されているかどうかが、クライアントプロトコルコンベンションの物質です。 雄ジカ_tと異なって、msg_イド_tの構造はDDPに不明瞭です、そして、したがって、それは完全にクライアントプロトコルの手にあります。
bdesc_t
bdesc_t
a description of a registered buffer:
登録されたバッファの記述:
typedef struct {
bhand_t bh;
ddp_addr_t a;
} bdesc_t;
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.は相殺されました'は登録されたバッファの始めのオフセットです。(それは、そのバッファの'始め'か'終わり'アドレスとの関係を全く持っていないかもしれません)。 しかしながら、マルチキャスト輸送(以下を見る)でのDDPなどの特定の実装は始めのオフセットの何らかのクライアントプロトコルコントロールを許すかもしれません。
bhand_t
bhand_t
an opaque buffer handle used to deregister a buffer.
不透明なバッファハンドルは「反-レジスタ」にバッファを使用しました。
Bailey & Talpey Informational [Page 8] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[8ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
recv_message_t
recv_メッセージ_t
a description of a completed untagged receive buffer:
完成した非タグ付けをされた受信バッファの記述:
typedef struct {
bdesc_t b;
length_t l;
} recv_message_t;
typedef struct bdesc_t b; 長さ_t l;recv_メッセージ_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;
typedef組合、recv_メッセージ_t m; ddp_msg_イド_t i; ddp_が間違える、_t e;、ddp_ind_t。
ddp_err_t
ddp_が間違える、_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;
msize_t最大_が非タグ付けをした; t最大_がタグ付けをしたmsize_;typedef structは_tをmsizesします。
ddp_send(socket_t s, message_t m)
ddp_は発信します。(ソケット_t s、メッセージ_t m)
send an untagged message.
非タグ付けをされたメッセージを送ってください。
ddp_send_ddp(socket_t s, message_t m, ddp_addr_t d, ddp_notify_t n)
ddp_は_ddpを送ります。(ソケット_t s、_t m、ddp_addr_t d、ddp_が_t nに通知するというメッセージ)
send a tagged message to remote buffer address d.
リモートバッファアドレスdにタグ付けをされたメッセージを送ってください。
Bailey & Talpey Informational [Page 9] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[9ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
ddp_post_recv(socket_t s, bdesc_t b)
_ddp_ポストrecv(ソケット_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() untaggedメッセージレセプション指示で各バッファを訪問者に返します、それが掲示されたオーダーで。 同じバッファは複数のソケットで可能にされるかもしれません。 これらのソケットのどれかからのバッファの中への非タグ付けをされたメッセージの領収書はすべてのソケットからのバッファを非掲示します。
ddp_recv(socket_t s)
ddp_recv(ソケット_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_レジスタ(ソケット_t s、ddp_バッファ_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_「反-レジスタ」(bhand_t bh)
remove a registration from a buffer.
バッファから登録を取り除いてください。
ddp_max_msizes(socket_t s)
ddp_最大_msizes(ソケット_t s)
get the current maximum untagged and tagged message sizes that
will fit in a single transport message.
ただ一つの輸送メッセージをうまくはめ込む現在の最大の非タグ付けをされてタグ付けをされたメッセージサイズを得てください。
2.1.3. Transport Characteristics in DDP
2.1.3. DDPにおける輸送の特性
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によって動かされるのではなく、Upper Layerの要件によって動かされて、DDPサービスを使っています。
Specifically, transports are:
明確に、輸送は以下の通りです。
o reliable or unreliable,
o 信頼できるか、または頼り無いです。
o ordered or unordered,
o 命令されるか、または順不同のです。
o single source or multisource,
o ソースか「マルチ-ソース」を選抜してください。
Bailey & Talpey Informational [Page 10] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[10ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
o single destination or multidestination (multicast or anycast).
o 目的地か「マルチ-目的地」(マルチキャストかanycast)を選抜してください。
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.
1終点あたりのアドレスで、例えば複数のIPを許容しながら、輸送に関する終点IPアドレスの向こう側に一貫してバッファアクセスを実装しなければなりません、SCTP。 Steering Tagは、特に、一貫して見なければならなくて、終点に属しながら、すべての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
Multidestinationデータ配送はDDPプロトコルにおける特定の考慮を必要とするかもしれない輸送の特性です。 以上のように、基本的なDDPモデルは、ddp_レジスタ()によって返されたバッファアドレス値がクライアントプロトコル、および缶に不透明であると仮定します。
Bailey & Talpey Informational [Page 11] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[11ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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の「マルチ-目的地」に輸送能力を供給するものに匹敵する見返りを設計することを伴います。
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.
登録されたバッファはDDPの中で雄ジカ_tによって特定されます。(それは、順番にソケットに関連しています)。 したがって、この登録がDDP同輩に能力を与えて、ソケット(その選ばれた輸送と可能なセキュリティの基本的な特性を使用する)は、同輩を特定して、雄ジカ_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_ポストrecv()によって可能にされるかもしれません。 この場合、バッファが掲示されたそれと異なったソケットの上にどんなddp_recv() untaggedメッセージレセプション指示も提供するかもしれません。 そのような指摘は複数の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のレイヤリングは、輸送の基本的な特性を言い表し続けなければなりません。
2.2. Remote Direct Memory Access (RDMA) Protocol Architecture
2.2. リモートダイレクトメモリアクセス(RDMA)プロトコルアーキテクチャ
Remote Direct Memory Access (RDMA) extends the capabilities of DDP with two primary functions.
リモートDirect Memory Access(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 Read)に示されたと言い足します。 これで、リモートクライアントにかかわらないで、クライアントプロトコルは任意の、そして、双方向のデータ運動を実行できます。 RDMAがハードウェアで実装されるとき、全くリモートホストCPUにかかわらないで、任意のデータ運動を実行できます。
Bailey & Talpey Informational [Page 12] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[12ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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アーキテクチャは、デバイスプログラミングのための伝統的なモデルの後に型に基づいて作られて、完成についてクライアントに通知します。そこでは、クライアントがSendのような動作(入出力をプログラムする)を使用することで操作を要求して、サーバは操作のための必要なデータ転送を実行します(DMAは読んで、書きます)。 プログラムされた入出力+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
. . .
クライアントプロトコル| ^は発信します。| | レセプション指摘RDMA Read Requestsを送ってください。| | RDMA Read Completion指摘RDMA Writes| | RDMA Write Completion指摘v| RDMA| ^はメッセージに非タグ付けをしました。| | メッセージの配送のタグ付けをされたメッセージに非タグ付けをしました。| | タグ付けをされたメッセージ配送v| DDP+--->データプレースメント^| メッセージ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 Read RequestsとRDMA Writesの結果、それぞれRDMAに登録されたバッファに実行されます。
An RDMA `buffer' extends a DDP buffer with a get() operation that retrieves the value of the octet at address `a':
RDMA'バッファ'はaでDDPバッファを広げています。() アドレス'a'で八重奏の値を検索する操作を得てください:
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;
_tが始めであるとconstに扱ってください; constに_データ_tが手に入れるt終わり(空集合(アドレス_t a、データ_t v))を扱ってください。typedef struct、(_がt a)であると扱ってください;、rdma_バッファ_t。
Bailey & Talpey Informational [Page 13] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[13ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
2.2.1. RDMA Operations
2.2.1. RDMA操作
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);
空のrdma_は発信します(ソケット_t s、メッセージ_t m)。 空のrdma_は書きます(ソケット_t s、メッセージ_t m、ddp_addr_t d、rdma_は_t nに通知します)。 空のrdma_は読みました(ソケット_t s、ddp_addr_t s、ddp_addr_t d)。 _rdma_ポストrecv(ソケット_t s、bdesc_t b)を欠如させてください。 rdma_ind_t rdma_recv(ソケット_t s)。 rdma_が登録するbdesc_t(ソケット_t s、rdma_バッファ_t b、bmode_tモード)。 rdma_「反-レジスタ」(bhand_t bh)を欠如させてください。 msizes_t rdma_最大_msizes(ソケット_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_とことによると_が()を送るrdma(Sendフロー制御があるとき)は完成する任意の時間を必要とすることができます。 また、完全な並行性とRDMAデータ転送のインターリービング、これらのインタフェースを言い表すのは、リエントラントであるべきです。 例えば、クライアントプロトコルは_が()を送るrdmaを実行するかもしれませんが、() 操作が読まれたrdma_は進行しています。
rdma_notify_t
rdma_は_tに通知します。
RDMA Write notification information, used to signal that the
message represents the final fragment of a multi-segmented RDMA
message:
メッセージがマルチ区分されたRDMAメッセージの最終的な断片を表すと合図するのに使用されるRDMA Write通知情報:
typedef struct {
boolean_t notify;
rdma_write_id_t i;
} rdma_notify_t;
論理演算子_tが通知する; _が_イド_t iを書くrdma;typedef structはrdmaされます。__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_がddp_msg_イド_tに同等でないかもしれないと_が、_それを除いたtに通知する_イド_tに書くddpと同じです。
rdma_write_id_t (scalar)
rdma_は_イド_tに書きます。(スカラ)です。
an RDMA Write identifier.
RDMA Write識別子。
Bailey & Talpey Informational [Page 14] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[14ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
rdma_ind_t
rdma_ind_t
a Send message, or an RDMA error:
Sendメッセージ、またはRDMA誤り:
typedef union {
recv_message_t m;
rdma_err_t e;
} rdma_ind_t;
typedef組合、recv_メッセージ_t m; _をrdmaするのが間違える、_t e;、rdma_ind_t。
rdma_err_t
rdma_が間違える、_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_に、_t、およびバッファ保護違反(例えばバッファが読書のために登録するだけであったRDMA Writing)は間違えています。
bmode_t
bmode_t
buffer registration mode (permissions). Any combination of
permitting RDMA Read (BMODE_READ) and RDMA Write (BMODE_WRITE)
operations.
登録モード(許容)をバッファリングしてください。 RDMA Read(BMODE_READ)とRDMA Write(BMODE_WRITE)に操作を可能にするどんな組み合わせ。
rdma_send(socket_t s, message_t m)
rdma_は発信します。(ソケット_t s、メッセージ_t m)
send a message, delivering it to the next untagged RDMA buffer
at the remote peer.
リモート同輩で次のuntagged RDMAバッファにそれを提供して、メッセージを送ってください。
rdma_write(socket_t s, message_t m, ddp_addr_t d, rdma_notify_t n)
rdma_は書きます。(ソケット_t s、_t m、ddp_addr_t d、rdma_が_t nに通知するというメッセージ)
RDMA Write to remote buffer address d.
リモートバッファへのRDMA Writeはdを扱います。
rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)
rdma_は読みました。(ソケット_t s、ddp_addr_t s、長さの_t l、ddp_addr_t d)
RDMA Read l octets from remote buffer address s to local buffer
address d.
リモートバッファアドレスsからローカルのバッファまでのRDMA Read l八重奏はdを扱います。
rdma_post_recv(socket_t s, bdesc_t b)
_rdma_ポストrecv(ソケット_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.
ただ一つのSendメッセージを受け入れる登録されたバッファを掲示して、いっぱいにして、返してください、rdma_recv()のその後の訪問者。 バッファが複数のソケットでDDPで可能にされるとき、その場合、注文保証はリラックスします。 また、DDPなら、局所界面は配分のメカニズムと複数のソケットに掲示されたバッファの管理を経営しなければなりません。
Bailey & Talpey Informational [Page 15] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[15ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
rdma_recv(socket_t s);
rdma_recv(ソケット_t s)。
get the next received Send message, RDMA Write completion
identifier, or RDMA error.
次の受信されたSendメッセージ、RDMA Write完成識別子、またはRDMA誤りを得てください。
rdma_register(socket_t s, rdma_buffer_t b, bmode_t mode)
rdma_レジスタ(ソケット_t s、rdma_バッファ_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_「反-レジスタ」(bhand_t bh)
remove a registration from a buffer.
バッファから登録を取り除いてください。
rdma_max_msizes(socket_t s)
rdma_最大_msizes(ソケット_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.
ただ一つの輸送メッセージをうまくはめ込む現在の最大のSend(最大_は非タグ付けをされた)とRDMA ReadかWrite(_がタグ付けをした最大)操作を得てください。 rdma_最大_msizes()によって返された値は、密接にddp_最大_msizes()によって返された値に関連しますが、等しくないかもしれません。
2.2.2. Transport Characteristics in RDMA
2.2.2. RDMAの輸送の特性
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 ()sを手に入れてください。
o Send messages, and
o そしてメッセージを送ってください。
o RDMA Read completions
o RDMA Read落成
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.
自分たちとそれらがどうリモート同輩における対応する操作に関連するかの中で命令されます。 これらの関係は基本的な輸送の特性の関数である傾向があります。
Bailey & Talpey Informational [Page 16] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[16ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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によってポイントのポイントの、そして、信頼できる輸送に提供されただけである能力によりそうです。 言い換えれば、多くの潜在的Upper Layers(RDMAサービスを自分たちに利用するかもしれない)が自然に既にこれらの輸送のクラスに向かって偏られます。
3. Security Considerations
3. セキュリティ問題
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プロトコル自体は追加脆弱性を導入するべきではありません。 彼らは、承認などの機能を中間的プロトコルであり、実行するので、必要とするべきではありません。(機能はUpper Layersのドメインです)。 しかしながら、DDPとRDMAプロトコルは、新しい脆弱性が寛大でない厳しいUpper Layersで写像するのを許容するべきです。 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.
Steering Tagがバッファへのアクセスをエクスポートするので、セキュリティの1つのきわどい局面がこのアクセサリーの範囲です。 アクセスで、リモートな状態で読まれて、それが登録された終点(ソケット)、包含のときにリモートなSteering Tagによって提供されたアクセスの属性が特定されるかもしれないアクセス、および他のものに書くのは、個別にコントロール特有に可能であるに違いありません。 DDPとRDMA仕様は、適切なデザイン決定をするのに作成者を助けるためにこの問題に関連している実装要件とガイドラインの両方を提供しなければなりません。
Bailey & Talpey Informational [Page 17] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[17ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
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ヘッダーは保護されないかもしれません。 したがって、要件によって、そのようなレイヤリングは不適当であるかもしれません。
3.1. Security Services
3.1. セキュリティー・サービス
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.
保全はどんな輸送にも重要ですが、DDPとRDMAPプロトコルに、各操作で運ばれたRDMA制御情報が保護されるのは、重要です、適切にペイロードを指示するために。
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
パケットごとのベースで接続を保証するために作動して、RDMAがプレースメントであると機密保護することへのIPsecは自然な発作です。(プレースメントは輸送に関連して作動します)。 RDMAが、実装が、バッファリングするのを避けるのを可能にするので、それはすべて適切な状態で働くために望ましいです。
Bailey & Talpey Informational [Page 18] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[18ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
security protection prior to processing of each segment by the transport and RDMA layers. Such a layering enables the most efficient secure RDMA implementation.
輸送と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長さの制限は複数の記録にかからなければならない長い操作のための追加バッファリングと処理を課します。 したがって、より少ない生まれつきの名手がRDMAプロトコルを保護するために潜在的に合ったので、TLSは見られます。
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プロトコルへの必要なセキュリティー・サービスを提供するために効率的な実装を可能にしている間、十分です。
3.2. Error Considerations
3.2. 誤り問題
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とDDPのどんな証券分析の必要な範囲の中にも必要に応じてRDMAプロトコル、および転送の粒状でサービス不能攻撃と重ね書きと他の並行操作、落成の注文につながるリソース問題があります。
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協会における誤りの結果を指定しなければなりません。
4. Acknowledgements
4. 承認
The authors wish to acknowledge the valuable contributions of Caitlin Bestler, David Black, Jeff Mogul, and Allyn Romanow.
作者はケイトリンBestler、デヴィッドBlack、ジェフ・ムガール人、およびアリンRomanowの有価約因を承諾したがっています。
Bailey & Talpey Informational [Page 19] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[19ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
5. Informative References
5. 有益な参照
[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 Technical Committee T11、「繊維のチャンネルの標準のVIアーキテクチャマッピング」、2001年3月に http://www.t11.org/t11/stat.nsf/fcproj から利用可能なANSI/NCITS357- 2001。
[IB] InfiniBand Trade Association, "InfiniBand Architecture
Specification Volumes 1 and 2", Release 1.1, November 2002,
available from http://www.infinibandta.org/specs.
[IB]インフィニバンドTrade Association、「第1インフィニバンドアーキテクチャ仕様巻と何2インチも、1.1、 http://www.infinibandta.org/specs から空いている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.
1998年8月に http://www.myri.com/open-specs から利用可能な[MYR]VMEbusの国際Trade Association、「VMEプロトコル仕様のMyrinet」ANSI/ヴィータ26-1998。
[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)」、RFC4297(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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(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]インフィニバンドTrade Association、「ソケットDirectプロトコルv1.0"、インフィニバンドArchitecture Specification Volume1、2002年11月に http://www.infinibandta.org/specs から利用可能なRelease1.1のAnnex A。」
[SRVNET] R. Horst, "TNet: A reliable system area network", IEEE
Micro, pp. 37-45, February 1995.
[SRVNET]R.ホルスト、「TNet:」 「信頼できるシステム領域ネットワーク」、IEEE Micro、ページ 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.レニエ、「VIアーキテクチャ」、ISBN0971288704、インテルPress、2002年4月、 http://www.intel.com/intelpress/via/ の詳しい情報。
Bailey & Talpey Informational [Page 20] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[20ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
Authors' Addresses
作者のアドレス
Stephen Bailey Sandburst Corporation 600 Federal Street Andover, MA 01810 USA USA
米国のスティーブンべイリーSandburst社600の連邦政府の通りMA01810アンドーバー(米国)
Phone: +1 978 689 1614 EMail: steph@sandburst.com
以下に電話をしてください。 +1 1614年の978 689メール: steph@sandburst.com
Tom Talpey Network Appliance 1601 Trapelo Road Waltham, MA 02451 USA
トムTalpeyネットアプライアンス1601Trapelo Road MA02451ウォルサム(米国)
Phone: +1 781 768 5329 EMail: thomas.talpey@netapp.com
以下に電話をしてください。 +1 5329年の781 768メール: thomas.talpey@netapp.com
Bailey & Talpey Informational [Page 21] RFC 4296 DDP and RDMA Architecture December 2005
べイリーとTalpeyの情報[21ページ]のRFC4296DDPとRDMAアーキテクチャ2005年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Bailey & Talpey Informational [Page 22]
べイリーとTalpey情報です。[22ページ]
一覧
スポンサーリンク
