RFC5045 日本語訳
5045 Applicability of Remote Direct Memory Access Protocol (RDMA) andDirect Data Placement (DDP). C. Bestler, Ed., L. Coene. October 2007. (Format: TXT=51749 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bestler, Ed.
Request for Comments: 5045 Neterion
Category: Informational L. Coene
Nokia Siemens Networks
October 2007
ワーキンググループC.Bestler、エドをネットワークでつないでください。コメントのために以下を要求してください。 5045年のNeterionカテゴリ: 情報のL.Coeneノキアシーメンスは2007年10月をネットワークでつなぎます。
Applicability of Remote Direct Memory Access Protocol (RDMA)
and Direct Data Placement Protocol (DDP)
リモートダイレクトメモリアクセスプロトコル(RDMA)とダイレクトデータプレースメントプロトコルの適用性(DDP)
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality.
このドキュメントはRemote Direct Memory Accessプロトコル(RDMAP)とDirect Data Placementプロトコル(DDP)の適用性について説明します。 それは、DDPが使用できるIPの上に対して異なった輸送オプションを比較して、対照して、利用可能な輸送、そして/または、どう使用される特定のトランスポート層に無関心であるかを選ぶときULP開発者に指導を提供して、サポート輸送のダイレクト使用とDDPの使用を比べて、RDMAの機能性を支持する非IP輸送とIP輸送の上のDDPを比べます。
Bestler & Coene Informational [Page 1] RFC 5045 RDMA/DDP Applicability October 2007
[1ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Direct Placement . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Direct Placement Using Only the LLP . . . . . . . . . . . 5
3.2. Fewer Required ULP Interactions . . . . . . . . . . . . . 6
4. Tagged Messages . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Order-Independent Reception . . . . . . . . . . . . . . . 7
4.2. Reduced ULP Notifications . . . . . . . . . . . . . . . . 7
4.3. Simplified ULP Exchanges . . . . . . . . . . . . . . . . . 8
4.4. Order-Independent Sending . . . . . . . . . . . . . . . . 9
4.5. Untagged Messages and Tagged Buffers as ULP Credits . . . 10
5. RDMA Read . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. LLP Comparisons . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Multistreaming Implications . . . . . . . . . . . . . . . 13
6.2. Out-of-Order Reception Implications . . . . . . . . . . . 13
6.3. Header and Marker Overhead . . . . . . . . . . . . . . . . 13
6.4. Middlebox Support . . . . . . . . . . . . . . . . . . . . 14
6.5. Processing Overhead . . . . . . . . . . . . . . . . . . . 14
6.6. Data Integrity Implications . . . . . . . . . . . . . . . 14
6.6.1. MPA/TCP Specifics . . . . . . . . . . . . . . . . . . 15
6.6.2. SCTP Specifics . . . . . . . . . . . . . . . . . . . . 15
6.7. Non-IP Transports . . . . . . . . . . . . . . . . . . . . 15
6.7.1. No RDMA-Layer Ack . . . . . . . . . . . . . . . . . . 16
6.8. Other IP Transports . . . . . . . . . . . . . . . . . . . 16
6.9. LLP-Independent Session Establishment . . . . . . . . . . 17
6.9.1. RDMA-Only Session Establishment . . . . . . . . . . . 17
6.9.2. RDMA-Conditional Session Establishment . . . . . . . . 18
7. Local Interface Implications . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Connection/Association Setup . . . . . . . . . . . . . . . 19
8.2. Tagged Buffer Exposure . . . . . . . . . . . . . . . . . . 19
8.3. Impact of Encrypted Transports . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 プレースメント. . . . . . . . . . . . . . . . . . . . . . . 5 3.1を指示してください。 LLP. . . . . . . . . . . 5 3.2だけを使用して、プレースメントを指示してください。 ULP相互作用. . . . . . . . . . . . . 6 4を必要としませんでした。 タグ付けをされたメッセージ. . . . . . . . . . . . . . . . . . . . . . . 6 4.1。 オーダーから独立しているレセプション. . . . . . . . . . . . . . . 7 4.2。 ULP通知. . . . . . . . . . . . . . . . 7 4.3を減らしました。 簡易型のULPは.84.4を交換します。 オーダーから独立している発信. . . . . . . . . . . . . . . . 9 4.5。 ULPクレジット. . . 10 5としてメッセージをUntaggedして、バッファにタグ付けをしました。 RDMAは.126を読みます。 LLP比較. . . . . . . . . . . . . . . . . . . . . . . 13 6.1。 含意. . . . . . . . . . . . . . . 13 6.2をMultistreamingします。 不適切なレセプション含意. . . . . . . . . . . 13 6.3。 ヘッダーとマーカーオーバーヘッド. . . . . . . . . . . . . . . . 13 6.4。 Middleboxは.146.5を支持します。 オーバーヘッド. . . . . . . . . . . . . . . . . . . 14 6.6を処理します。 データの保全含意. . . . . . . . . . . . . . . 14 6.6.1。 MPA/TCP詳細. . . . . . . . . . . . . . . . . . 15 6.6.2。 SCTP詳細. . . . . . . . . . . . . . . . . . . . 15 6.7。 非IPは.1に.156.7を輸送します。 Ack. . . . . . . . . . . . . . . . . . 16 6.8RDMA-層がありません。 他のIPは.166.9を輸送します。 LLPから独立しているセッション設立. . . . . . . . . . 17 6.9.1。 RDMAだけセッション設立. . . . . . . . . . . 17 6.9.2。 RDMA条件付きのセッション設立. . . . . . . . 18 7。 局所界面含意. . . . . . . . . . . . . . . . . 18 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 8.1。 接続/協会セットアップ. . . . . . . . . . . . . . . 19 8.2。 タグ付けをされたバッファ露出. . . . . . . . . . . . . . . . . . 19 8.3。 コード化された輸送. . . . . . . . . . . . . . 19 9の影響。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 19 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 19
Bestler & Coene Informational [Page 2] RFC 5045 RDMA/DDP Applicability October 2007
[2ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
1. Introduction
1. 序論
Remote Direct Memory Access Protocol (RDMAP) [RFC5040] and Direct Data Placement (DDP) [RFC5041] work together to provide application- independent efficient placement of application payload directly into buffers specified by the Upper Layer Protocol (ULP).
リモートDirect Memory Accessプロトコル(RDMAP)[RFC5040]とDirect Data Placement(DDP)[RFC5041]は、Upper Layerプロトコル(ULP)によって指定されたバッファの直接中にアプリケーションペイロードのアプリケーションの独立している効率的なプレースメントを提供するために一緒に働いています。
The DDP protocol is responsible for direct placement of received payload into ULP-specified buffers. The RDMAP protocol provides completion notifications to the ULP and support for Data-Sink- initiated fetch of Advertised Buffers (RDMA Reads).
DDPプロトコルはULPによって指定されたバッファの中への容認されたペイロードの直接募集に原因となります。 RDMAPプロトコルはAdvertised Buffers(RDMA Reads)のData-流し台で開始しているフェッチのULPとサポートに完成通知を供給します。
DDP and RDMAP are both application-independent protocols that allow the ULP to perform remote direct data placement. DDP can use multiple standard IP transports including SCTP and TCP.
DDPとRDMAPはULPがリモートダイレクトデータプレースメントを実行できる両方のアプリケーションから独立しているプロトコルです。 SCTPとTCPを含んでいて、DDPはIPが輸送する平均物価標準を使用できます。
By clarifying the situations where the functionality of these protocols is applicable, this document can guide implementers and application and protocol designers in selecting which protocols to use.
これらのプロトコルの機能性が適切である状況をはっきりさせることによって、どのプロトコルを使用したらよいかを選択する際にこのドキュメントはimplementers、アプリケーション、およびプロトコルデザイナーを誘導できます。
The applicability of RDMAP/DDP is driven by their unique capabilities:
RDMAP/DDPの適用性は彼らのユニークな能力によって動かされます:
o This document will discuss when common data placement procedures
are of more benefit to applications than application-specific
solutions built on top of direct use of the underlying transport.
o このドキュメントは、一般的なデータプレースメント手順がいつアプリケーションにおいて基本的な輸送のダイレクト使用の上で築き上げられたアプリケーション特有の解決策より利益となるかと議論するでしょう。
o DDP supports both Untagged and Tagged Buffers. Tagged Buffers
allow the Data Sink ULP to be indifferent to what order (or in
what messages) the Data Source sent the data, or in what order
packets are received. Typically, tagged data can be used for
payload transfer, while untagged is best used for control
messages. However each upper-layer protocol can determine the
optimal use of Tagged and Untagged Messages for itself. This
document will discuss when Data Source flexibility is of benefit
to applications.
o DDPはUntaggedとTagged Buffersの両方を支持します。 タグ付けをされたBuffersは、Data Sink ULPが何が、データをData Sourceに送るよう命令するか、そして、(またはどんなメッセージで)またはパケットがどんなオーダーで受け取られているかにありきたりであることを許容します。 タグ付けをされたデータは通常、非タグ付けをされる間のペイロード転送に使用されているのが、コントロールメッセージに、中古の最善であるということであるかもしれません。 しかしながら、それぞれの上側の層のプロトコルはTaggedとUntagged Messagesのそれ自体の最適の使用を決定できます。 このドキュメントは、Data Sourceの柔軟性がいつアプリケーションに有益であるかと議論するでしょう。
o RDMAP consolidates ULP notifications, thereby minimizing the
number of required ULP interactions.
o RDMAPはULP通知を統合して、その結果、必要なULP相互作用の数を最小にします。
o RDMAP defines RDMA Reads, which allow remote access to Advertised
Buffers. This document will review the advantages of using RDMA
Reads as contrasted to alternate solutions.
o RDMAPはRDMA Readsを定義します。(RDMA ReadsはAdvertised Buffersに遠隔アクセスを許容します)。 このドキュメントは解決策を交替するために対照されるようにRDMA Readsを使用する利点を見直すでしょう。
A more comprehensive introduction to the RDMAP and DDP protocols
and discussion of their security considerations can be found in
[RFC5042].
[RFC5042]でRDMAPとDDPプロトコルへの、より包括的な紹介とそれらのセキュリティ問題の議論を見つけることができます。
Bestler & Coene Informational [Page 3] RFC 5045 RDMA/DDP Applicability October 2007
[3ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Some non-IP transports, such as InfiniBand, directly integrate RDMA features. This document will review the applicability of providing RDMA services over ubiquitous IP transports instead of over customized transport protocols. Due to the fact that DDP is defined cleanly as a layer over existing IP transports, DDP has simpler ordering rules than some prior RDMA protocols. This may have some implications for application designers.
インフィニバンドなどのいくつかの非IP輸送が直接RDMAの特徴を統合します。 このドキュメントはカスタム設計されたトランスポート・プロトコルの代わりに遍在しているIP輸送の上でサービスをRDMAに供給する適用性を見直すでしょう。 DDPがIPが輸送する存在の上で清潔に層と定義されるという事実のため、DDPには、いくつかの先のRDMAプロトコルより簡単な注文規則があります。 これには、アプリケーション設計者のためのいくつかの意味があるかもしれません。
The full capabilities of DDP and RDMAP can only be fully realized by applications that are designed to exploit them. The coexistence of RDMAP/DDP-aware local interfaces with traditional socket interfaces will also be explored.
それらを利用するように設計されているアプリケーションでDDPとRDMAPの完全な能力を完全に実現できるだけです。 また、伝統的なソケットインタフェースとのDDP RDMAP/意識している局所界面の共存は調査されるでしょう。
Finally, DDP support is defined for at least two IP transports: SCTP [RFC5043] and TCP [RFC5044]. The rationale for supporting both transports is reviewed, as well as when each would be the appropriate selection.
最終的に、DDPサポートは少なくともIPが輸送する2のために定義されます: SCTP[RFC5043]とTCP[RFC5044]。 両方の輸送を支持するための原理はそれぞれが適切な選択である時と同様に見直されます。
2. Definitions
2. 定義
Advertisement - the act of informing a Remote Peer that a local RDMA
Buffer is available to it. A Node makes available an RDMA Buffer
for incoming RDMA Read or RDMA Write access by informing its RDMA/
DDP peer of the Tagged Buffer identifiers (STag, base address, and
buffer length). This Advertisement of Tagged Buffer information
is not defined by RDMA/DDP and is left to the ULP. A typical
method would be for the Local Peer to embed the Tagged Buffer's
Steering Tag, base address, and length in a Send Message destined
for the Remote Peer.
広告--地方のRDMA Bufferがそれに利用可能であることをRemote Peerに知らせる行為。 Nodeは、Tagged Buffer識別子(STag、ベースアドレス、およびバッファ長)についてRDMA/DDP同輩に知らせることによって、入って来るRDMA ReadかRDMA WriteアクセスのためのRDMA Bufferを利用可能にします。 Tagged Buffer情報のこのAdvertisementはRDMA/DDPによって定義されないで、ULPに残されます。 典型的な方法はLocal PeerがTagged BufferのSteering Tag、ベースアドレス、および長さをRemote Peerのために運命づけられたSend Messageに埋め込むだろうことです。
Data Sink - The peer receiving a data payload. Note that the Data
Sink can be required to both send and receive RDMA/DDP Messages to
transfer a data payload.
データSink--データペイロードを受け取る同輩。 Data Sinkがデータペイロードを移すためにともにRDMA/DDP Messagesを送って、受け取ることができなければならないことに注意してください。
Data Source - The peer sending a data payload. Note that the Data
Source can be required to both send and receive RDMA/DDP Messages
to transfer a data payload.
データSource--データペイロードを送る同輩。 Data Sourceがデータペイロードを移すためにともにRDMA/DDP Messagesを送って、受け取ることができなければならないことに注意してください。
Lower Layer Protocol (LLP) - The transport protocol that provides
services to DDP. This is an IP transport with any required
adaptation layer. Adaptation layers are defined for SCTP and TCP.
Layerプロトコル(LLP)を下ろしてください--DDPに対するサービスを提供するトランスポート・プロトコル。 どんな必要な適合層でこれはIP輸送です。 適合層はSCTPとTCPのために定義されます。
Steering Tag (STag) - An identifier of a Tagged Buffer on a Node,
valid as defined within a protocol specification.
操縦Tag(STag)--定義されるとしてプロトコル仕様の中で有効なNodeの上のTagged Bufferに関する識別子。
Bestler & Coene Informational [Page 4] RFC 5045 RDMA/DDP Applicability October 2007
[4ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Tagged Message - A DDP message that is directed to a ULP-specified
buffer based upon imbedded addressing information. In the
immediate sense, the destination buffer is specified by the
message sender. The message receiver is given no independent
indication that a Tagged Message has been received.
タグ付けをされたMessage--ULPによって指定されたバッファに向けられるDDPメッセージは情報を埋め込まれたアドレシングに基礎づけました。 即座の意味で、目的地バッファはメッセージ送付者によって指定されます。 Tagged Messageを受け取ったというどんな独立している指示もメッセージ受信機に与えません。
Untagged Message - A DDP message that is directed to a ULP-specified
buffer based upon a Message Sequence Number being matched with a
receiver-supplied buffer. The destination buffer is specified by
the message receiver. The message receiver is notified by some
mechanism that an Untagged Message has been received.
Untagged Message--受信機に供給されたバッファに合わせられているMessage Sequence Numberに基づくULPによって指定されたバッファに向けられるDDPメッセージ。 目的地バッファはメッセージ受信機によって指定されます。メッセージ受信機は何らかのメカニズムによってUntagged Messageが受け取られたことに通知されます。
Upper Layer Protocol (ULP) - The direct user of RDMAP/DDP services.
In addition to protocols such as iSER [RFC5046] and NFSv4 over
RDMA [NFSDIRECT], the ULP may be embedded in an application or a
middleware layer, as is often the case for the Sockets Direct
Protocol (SDP) and Remote Procedure Call (RPC) protocols.
上側のLayerプロトコル(ULP)--ダイレクトRDMAP/DDPサービスのユーザ。 よくあるように、RDMA[NFSDIRECT]の上のiSER[RFC5046]やNFSv4などのプロトコルに加えて、ULPはSockets Directプロトコル(SDP)とRemote Procedure Call(RPC)プロトコルのためにアプリケーションかミドルウェア層に埋め込まれるかもしれません。
3. Direct Placement
3. 直接募集
Direct Data Placement optimizes the placement of ULP Payload into the correct destination buffers, typically eliminating intermediate copying. Placement is enabled without regard to order of arrival, order of transmission, or requirement of per-placement interaction with the ULP.
中間的コピーを通常排除して、ダイレクトに、Data Placementは正しい目的地バッファの中にULP有効搭載量のプレースメントを最適化します。 プレースメントは関係なしで到着の注文、トランスミッションの注文、またはULPとの1プレースメントあたりの相互作用の要件に可能にされます。
RDMAP minimizes the required ULP interactions. This capability is most valuable for applications that require multiple transport layer packets for each required ULP interaction.
RDMAPは必要なULP相互作用を最小にします。 それぞれの必要なULP相互作用のために複数のトランスポート層パケットを必要とするアプリケーションに、この能力は最も貴重です。
3.1. Direct Placement Using Only the LLP
3.1. LLPだけを使用する直接募集
Direct data placement can be achieved without RDMA. Pre-posting of receive buffers could allow a non-RDMA network stack to place data directly to user buffers.
RDMAなしでダイレクトデータプレースメントを達成できます。 受信バッファのプレ任命で、非RDMAネットワークスタックは直接ユーザバッファにデータを置くことができるかもしれません。
The degree to which DDP optimizes depends on which transport it is being compared with, and on the nature of the local interface. Without RDMAP/DDP, pre-posting buffers require the receiving side to accurately predict the required buffers and their sizes. This is not feasible for all ULPs. By contrast, DDP only requires the ULP to predict the sequence and size of incoming Untagged Messages.
DDPが最適化される程度は、自然と局所界面の自然の上にどの輸送にそれがあるかによります。 RDMAP/DDPがなければ、プレ任命バッファは、正確に必要なバッファとそれらのサイズを予測するために受信側を必要とします。 すべてのULPsには、これは可能ではありません。 対照的に、DDPは、ULPが入って来るUntagged Messagesの系列とサイズを予測するのを必要とするだけです。
An application that could predict incoming messages and required nothing more than direct placement into buffers might be able to do so with a properly designed local interface to native SCTP or TCP (without RDMA). This is easier using native SCTP because the
したがって、入力メッセージを予測できて、バッファの中にただ直接募集を必要としたアプリケーションはネイティブのSCTPかTCP(RDMAのない)に適切に設計された局所界面を処理できるかもしれません。 ネイティブのSCTPを使用することではこれは、より簡単です。
Bestler & Coene Informational [Page 5] RFC 5045 RDMA/DDP Applicability October 2007
[5ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
application would only have to predict the sequence of messages and the maximum size of each message, not the exact size.
アプリケーションはメッセージの系列と実寸ではなく、それぞれのメッセージの最大サイズを予測するだけでよいでしょう。
The main benefit of DDP for such an application would be that pre- posting of receive buffers is a mandated local interface capability, and that predictions can always be made on a per-message basis (not per byte).
そのようなアプリケーションのためのDDPの主な利益は受信バッファのプレ任命が強制された局所界面能力であり、1メッセージあたり1個のベース(1バイトでないのあたりの)でいつも予測をすることができるということでしょう。
The Lower Layer Protocol, LLP, can also be used directly if ULP- specific knowledge is built into the protocol stack to allow "parse and place" handling of received packets. Such a solution either requires interaction with the ULP or the protocol stack's knowledge of ULP-specific syntax rules.
また、プロトコル・スタックが「分析してください、そして、入賞してください」に容認されたパケットの取り扱いを許すためにULPの特定の知識に組み込まれるなら、直接、Lower Layerプロトコル(LLP)を使用できます。 そのような解決策はULP特有のシンタックス・ルールに関するULPかプロトコル・スタックの知識との相互作用を必要とします。
DDP achieves the benefits of directly placing incoming payload without requiring tight coupling between the ULP and the protocol stack. However, "parse and place" capabilities can certainly provide equivalent services to a limited number of ULPs.
DDPは直接ULPとプロトコル・スタックの間で密結合を必要としないで入って来るペイロードを置く利益を実現します。 しかしながら、確かに、能力は、「分析してください、そして、入賞してください。」とULPsの限られた数に対する同等なサービスを前提とすることができます。
3.2. Fewer Required ULP Interactions
3.2. より少ない必要なULP相互作用
While reducing the number of required ULP interactions is in itself desirable, it is critical for high-speed connections. The burst packet rate for a high-speed interface could easily exceed the host system's ability to switch ULP contexts.
必要なULP相互作用について数を減らすのは本来望ましいのですが、高速接続に、それは重要です。 高速インタフェースの炸裂パケット率は容易にULP文脈を切り換えるホストシステムの性能を超えるかもしれません。
Content access applications are important examples of applications that require high bandwidth and can transfer a significant amount of content between required ULP interactions. These applications include file access protocols (NAS), storage access (SAN), database access, and other application-specific forms of content access such as HTTP, XML, and email.
満足しているアクセスアプリケーションは、高帯域を必要とするアプリケーションの重要な例であり、必要なULP相互作用の間にかなりの量の内容を移すことができます。 これらのアプリケーションはファイルアクセス・プロトコル(NAS)、格納アクセス(SAN)、データベースアクセス、および他のアプリケーション特有の形式のHTTPや、XMLや、メールなどの満足しているアクセスを含んでいます。
4. Tagged Messages
4. タグ付けをされたメッセージ
This section covers the major benefits from the use of Tagged Messages.
このセクションはTagged Messagesの使用から主要な利益をカバーします。
A more critical advantage of DDP is the ability of the Data Source to use Tagged Buffers. Tagging messages allows the Data Source to choose the ordering and packetization of its payload deliveries. With direct data placement based solely upon pre-posted receives, the packetization and delivery of payload must be agreed by the ULP peers in advance.
DDPの、より重要な利点はData SourceがTagged Buffersを使用する能力です。 メッセージにタグ付けをするのに、Data Sourceはペイロード配送の注文とpacketizationを選ぶことができます。 ULP同輩はあらかじめ、ペイロードの唯一あらかじめ掲示されるのに基づいているプレースメントが受け取るダイレクトデータ、packetization、および配送に同意しなければなりません。
The Upper Layer Protocol can allocate content between Untagged and/or Tagged Messages to maximize the potential optimizations. Placing content within an Untagged Message can deliver the content in the
Upper Layerプロトコルは、潜在的最適化を最大にするためにUntagged、そして/または、Tagged Messagesの間に内容を割り当てることができます。 Untagged Messageの中に内容を置くと、内容を送ることができます。
Bestler & Coene Informational [Page 6] RFC 5045 RDMA/DDP Applicability October 2007
[6ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
same packet that signals completion to the receiver. This can improve latency. It can even eliminate round trips. But it requires making larger anonymous buffers to be available.
それは受信機に完成に合図します。同じパケット、これは潜在を改良できます。 それは周遊旅行を排除さえできます。 しかし、利用可能であるのが、より大きい匿名のバッファを作るのを必要とします。
Some examples of data that typically belongs in the Untagged Message would include:
Untagged Messageには通常あるデータに関するいくつかの例が以下を含んでいるでしょう。
short fixed-size control data that is inherently part of the
control message. This is especially true when the data is a
required part of the control message.
本来コントロールメッセージの一部である短い固定サイズコントロールデータ。 データがコントロールメッセージの必要な部分であるときに、これは特に本当です。
relatively short payload that is almost always needed, especially
when its inclusion would eliminate a round-trip to fetch the data.
Examples would include the initial data on a write request and
Advertisements of Tagged Buffers.
包含が特にデータをとって来るためには往復のaを排除するとほとんどいつも必要である比較的短いペイロード。 例はaに関するデータがTagged Buffersの要求とAdvertisementsに書くイニシャルを含んでいるでしょう。
Tagged Messages standardize direct placement of data without per- packet interaction with the upper layers. Even if there is an upper- layer protocol encoding of what is being transferred, as is common with middleware solutions, this information is not understood at the application-independent layers. The directions on where to place the incoming data cannot be accessed without switching to the ULP first. DDP provides a standardized 'packing list', which can be interpreted without requiring ULP interaction. Indeed, it is designed to be implementable in hardware.
タグ付けをされたMessagesがデータの直接募集を標準化する、-、上側の層とのパケット相互作用。 そのままでミドルウェア解決について一般的に移されているものをコード化する上側の層のプロトコルがあっても、この情報はアプリケーションから独立している層で理解されていません。 最初にULPに切り替わらないで、受信データをどこに置くかに関する指示にアクセスできません。 DDPは標準化された'荷造明細書'を提供します。(ULP相互作用を必要としないで、それを解釈できます)。 本当に、それは、ハードウェアで実行可能になるように設計されています。
4.1. Order-Independent Reception
4.1. オーダーから独立しているレセプション
Tagged Messages are directed to a buffer based on an included Steering Tag. Additionally, no notice is provided to the ULP for each individual Tagged Message's arrival. Together these allow Tagged Messages received out of order to be processed without intermediate buffering or additional notifications to the ULP.
タグ付けをされたMessagesは含まれているSteering Tagに基づくバッファに向けられます。 さらに、それぞれの個々のTagged Messageの到着のために通知を全くULPに提供しません。 これらは、故障していた状態で受け取られたTagged Messagesが中間的バッファリングしているか追加している通知なしでULPに処理されるのを一緒に、許容します。
4.2. Reduced ULP Notifications
4.2. 減少しているULP通知
RDMAP offers both Tagged and Untagged Messages. No receiving-side ULP interactions are required for Tagged Messages. By optimally dividing traffic between Tagged and Untagged Messages, the ULP can limit the number of events that must be dealt with at the ULP layer. This typically reduces the number of context switches required and improves performance.
RDMAPはTaggedとUntagged Messagesの両方を提供します。 受信サイドULP相互作用は全くTagged Messagesに必要ではありません。 TaggedとUntagged Messagesの間の交通を最適に分割することによって、ULPはULP層で対処しなければならない出来事の数を制限できます。 これは、スイッチが必要とした文脈の数を通常減少させて、性能を向上させます。
RDMAP further reduces required ULP interactions, consolidating completion notifications of Tagged Messages with the completion notification of a trailing Untagged Message. For most ULPs, this radically reduces the number of ULP required interactions even further.
RDMAPは必要なULP相互作用をさらに減少させます、引きずっているUntagged Messageの完成通知によるTagged Messagesの完成通知を統合して。 ほとんどのULPsに関しては、これはULPの必要な相互作用の数を根本的にさらにさえ減少させます。
Bestler & Coene Informational [Page 7] RFC 5045 RDMA/DDP Applicability October 2007
[7ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
While RDMAP consolidation of notices is beneficial to most applications, it may be detrimental to some applications that benefit from streamed delivery to enable ULP processing of received data as promptly as possible. A ULP that uses RDMAP cannot begin processing any portion of an exchange until it receives notification that the entire exchange has been placed. An "exchange" here is a set of zero or more Tagged Messages and a single terminating Untagged Message. An application that would prefer to begin work on the received payload as soon as possible, no matter what order it arrived in, might prefer to work directly with the LLP. RDMAP is optimized for applications that are more concerned when the entire exchange is complete.
通知のRDMAP強化がほとんどのアプリケーションに有益である間、できるだけ即座に受信データのULP処理を可能にするのは流された配送の利益を得るいくつかのアプリケーションに有害であるかもしれません。 RDMAPを使用するULPは、全体の交換が置かれたという通知を受け取るまで交換のどんな部分も処理し始めることができません。 ここの「交換」は1セットのゼロであるか、より多くのTagged MessagesとシングルはUntagged Messageを終えることです。 どんなオーダーに到達してもできるだけ早く容認されたペイロードへの作業を始めるのを好むアプリケーションは、直接LLPと共に働くのを好むかもしれません。 RDMAPは全体の交換が完全であるときに、より関したアプリケーションのために最適化されます。
An application that benefits from being able to begin processing of each received packet as quickly as possible may find RDMAP interferes with that goal.
処理し始めることができる存在からそれぞれの容認されたパケットのできるだけはやくためになるアプリケーションは、RDMAPがその目標を妨げるのがわかるかもしれません。
Such an application might be able to retain most of the benefits of RDMAP by using the DDP layer directly. However, in addition to taking on the responsibilities of the RDMAP layer, the application would likely have more difficulty finding support for a DDP-only API. Many hardware implementations may choose to tightly couple RDMAP and DDP, and might not provide an API directly to DDP services.
そのようなアプリケーションは、直接DDP層を使用することによって、RDMAPの利益の大部分を保有できるかもしれません。 しかしながら、RDMAP層について責任を負うことに加えて、アプリケーションはおそらくDDPだけAPIのサポートを見つけることにおける、より多くの苦労をするでしょう。 多くのハードウェア実装は、しっかりRDMAPとDDPを結合するのを選んで、直接DDPサービスするのにAPIを前提としないかもしれません。
These features minimize the required interactions with the ULP. This can be extremely beneficial for applications that use multiple transport layer packets to accomplish what is a single ULP interaction.
これらの特徴はULPとの必要な相互作用を最小にします。 単一のULP相互作用であることを達成するのに複数のトランスポート層パケットを使用するアプリケーションに、これは非常に有益である場合があります。
4.3. Simplified ULP Exchanges
4.3. 簡易型のULP交換
The notification rules for Tagged Messages allows ULPs to create multi-message "exchanges" consisting of zero or more Tagged Messages that represent a single step in the ULP interaction. The receiving ULP is notified that the Untagged Message has arrived, and implicitly notified of any associated Tagged Messages.
Tagged Messagesのための通知規則で、ULPsはULP相互作用でシングルステップを表すマルチメッセージゼロか以上から成る「交換」Tagged Messagesを作成できます。 受信ULPはUntagged Messageが到着したことに通知されて、どんな関連Tagged Messagesについてもそれとなく通知されます。
If a ULP cannot effectively use Tagged Messages, it would derive little benefit from use of RDMAP/DDP by comparison to direct use of SCTP. But, while Tagged Buffers are the justification for RDMAP/DDP, Untagged Buffers are still necessary. Without Untagged Buffers, the only method to exchange buffer Advertisements would require out-of- band communications. Most RDMA-aware ULPs use Untagged Buffers for requests and responses. Buffer Advertisements are typically done within these Untagged Messages.
ULPが事実上Tagged Messagesを使用できないなら、それが、SCTPの使用を指示するために利益にRDMAP/DDPの比較による使用にほとんど由来していないでしょう。 しかし、Tagged BuffersはRDMAP/DDPのための正当化ですが、Untagged Buffersがまだ必要です。 Untagged Buffersがなければ、バッファAdvertisementsを交換する唯一の方法がアウトを必要とするだろう、-、バンドコミュニケーションについて。 ほとんどのRDMA意識しているULPsが要求と応答にUntagged Buffersを使用します。 通常これらのUntagged Messagesの中でバッファAdvertisementsをします。
More importantly, there would be no reliable method for the upper- layer peers to synchronize. The absence of any guarantees about
より重要に、上側の層の同輩が連動する確かな方法が全くないでしょう。 どんな保証のおよそ欠如
Bestler & Coene Informational [Page 8] RFC 5045 RDMA/DDP Applicability October 2007
[8ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
ordering within or between Tagged Messages is fundamental to allowing the DDP layer to optimize transfer of tagged payload.
DDP層がタグ付けをされたペイロードの転送を最適化するのを許容するのにTagged Messages以内かTagged Messagesの間で注文するのは基本的です。
Therefore, no ULP can be defined entirely in terms of Tagged Messages. Eventually, a notification that confirms delivery must be generated from the RDMAP/DDP layer.
したがって、完全なTagged Messagesに関してULPを全く定義できません。 結局、配送を確認する通知はRDMAP/DDP層から発生しなければなりません。
Limiting use of Untagged Buffers to requests and responses by moving all bulk data using tagged transfers can greatly simplify the amount of prediction that the Data Sink must perform in pre-posting receive buffers. For example, a typical RDMA-enabled interaction would consist of the following:
タグ付けをされた転送を使用することですべての大量のデータを動かすことによってUntagged Buffersの使用を要求と応答に制限すると、Data Sinkがプレ任命受信バッファで働かなければならないという予測の量を大いに簡素化できます。 例えば、典型的なRDMAによって可能にされた相互作用は以下から成るでしょう:
1. Client sends transaction request to server as an Untagged
Message.
1. クライアントはUntagged Messageとしてトランザクション要求をサーバに送ります。
2. This message includes buffer Advertisements for the buffers where
the results are to be placed.
2. このメッセージは置かれる結果がことであるバッファのためのバッファAdvertisementsを含んでいます。
3. The server sends multiple Tagged Messages to the Advertised
buffers.
3. サーバは複数のTagged MessagesをAdvertisedバッファに送ります。
4. The server sends transaction reply as an Untagged Message to the
client.
4. サーバはUntagged Messageとして取引回答をクライアントに送ります。
5. Client receives single notification, indicating completion of the
interaction.
5. 相互作用の完成を示して、クライアントはただ一つの通知を受け取ります。
With this type of exchange, the pacing and required size of Untagged Buffers are highly predictable. The variability of response sizes is absorbed by tagged transfers.
このタイプの交換で、Untagged Buffersのペースと必要なサイズは非常に予測できます。 タグ付けをされた転送で応答サイズの可変性を吸収します。
4.4. Order-Independent Sending
4.4. オーダーから独立している発信
Use of Tagged Messages is especially applicable when the Data Sink does not know the actual size, structure, or location of the content it is requesting (or updating).
Data Sinkがそれが要求している内容(または、アップデート)の実サイズ、構造、または位置を知らないとき、Tagged Messagesの使用は特に適切です。
For example, suppose the Data Sink ULP needs to fetch four related pieces of data into four separate buffers. With SCTP, the Data Sink ULP could receive four messages into four separate buffers, only having to predict the maximum size of each. However, it would have to dictate the order in which the Data Source supplied the separate pieces. If the Data Source found it advantageous to fetch them in a different order, it would have to use intermediate buffering to re- order the pieces into the expected order even though the application only required that all four be delivered and did not truly have an ordering requirement.
例えば、4をとって来るData Sink ULPの必要性が4つの別々のバッファの中にデータの断片を関係づけたと仮定してください。 SCTPと共に、Data Sink ULPは、それぞれの最大サイズを予測するために4つの別々のバッファ、有だけに4つのメッセージを受け取ることができました。 しかしながら、それはData Sourceが別々の断片を供給したオーダーを書き取らなければならないでしょう。 Data Sourceが、異なったオーダーでそれらをとって来るのが有利であることがわかるなら、それは、アプリケーションが、すべての4が送られて、本当に、注文要件を持っていなかったのを必要としただけですが、予想されたオーダーに断片を再命令するのに中間的バッファリングを使用しなければならないでしょうに。
Bestler & Coene Informational [Page 9] RFC 5045 RDMA/DDP Applicability October 2007
[9ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Techniques, such as RAID striping and mirroring, represent this same problem, but one step further. What appears to be a single resource to the Data Sink is actually stored in separate locations by the Data Source. Non RDMA protocols would either require the Data Source to fetch the material in the desired order or force the Data Source to use its own holding buffers to assemble an image of the destination buffer.
RAIDストライピングやミラーリングなどのテクニックはさらにこの同じ問題、しかし、ワンステップを表します。 何がData Sinkへのただ一つのリソースであるように見えるか実際に別々の位置にData Sourceによって格納されます。 非RDMAプロトコルは、Data Sourceによって目的地バッファのイメージを組み立てるのに必要なオーダーで材料をとって来るか、またはData Sourceが、それ自身がバッファを保持するのをやむを得ず使用するのを必要とするでしょう。
While sometimes referred to as a "buffer-to-buffer" solution, RDMA more fundamentally enables remote buffer access. The ULP is free to work with larger remote buffers than it has locally. This reduces buffering requirements and the number of times the data must be copied in an end-to-end transfer.
時々「バッファからバッファ」解決策と呼ばれている間、RDMAは、より基本的にリモートバッファアクセサリーを可能にします。 ULPは局所的に持っているより大きいリモートバッファで自由に働くことができます。 これは、終わりから終わりへの転送でデータをコピーしなければならないという回の要件と数をバッファリングしながら、減少します。
There are numerous reasons why the Data Sink would not know the true order or location of the requested data. It could be different for each client, different records selected and/or different sort orders, as well as RAID striping, file fragmentation, volume fragmentation, volume mirroring, and server-side dynamic compositing of content (such as server-side includes for HTTP).
Data Sinkが要求されたデータの本当のオーダーか位置を知らない多数の理由があります。 各クライアント、選択された異なった記録、そして/または、異なった種類の命令において、それは異なるかもしれません、内容(HTTPのためのサーバサイドインクルードなどの)のRAIDストライピング、ファイル断片化、ボリューム断片化、ボリュームミラーリング、およびサーバサイドのダイナミックな合成と同様に。
In all of these cases, the Data Source is free to assemble the desired data in the Data Sink's buffer in whatever order the component data becomes available to it. It is not constrained on ordering. It does not have to assemble an image in its own memory before creating it in the Data Sink's buffers.
これらの場合では、全部で、Data Sourceは自由にコンポーネントデータがオーダーに何でもなるかのData Sinkの利用可能なバッファの必要なデータをそれに組み立てることができます。 それは注文のときに抑制されません。 Data Sinkのバッファでそれを作成する前に、それはそれ自身のメモリのイメージを組み立てる必要はありません。
Note that while DDP enables use of Tagged Messages for bulk transfer, there are some application scenarios where Untagged Messages would still be used for bulk transfer. For example, a file server may not expose its own memory to its clients. A client wishing to write may Advertise a buffer upon which the server will issue RDMA Reads. However, when performing a small write, it may be preferable to include the data in the Untagged Message rather than incurring an additional round trip with the RDMA Read and its response.
DDPがTagged Messagesのバルク転送の使用を可能にしますが、いくつかのアプリケーションシナリオがUntagged Messagesがバルク転送にまだ使用されているところにあることに注意してください。 例えば、ファイルサーバーはそれ自身のメモリをクライアントに露出しないかもしれません。 書きたいクライアントは広告、サーバがRDMA Readsを発行するものに関する、よりもみ皮製のaがそうするかもしれません。 しかしながら、小さくaを実行するときには、書いてください、そして、RDMA Readとその応答で追加周遊旅行を被るよりむしろUntagged Messageのデータを含んでいるのは望ましくてもよいです。
Generally, the best use of an Untagged Message is to synchronize and to deliver data that is naturally tied to the same message as the synchronization. For initial data transfers, this has the additional benefit of avoiding the need to Advertise specific Tagged Buffers for indefinite time periods. Instead, anonymous buffers can be used for initial data reception. Because anonymous buffers do not need to be tied to specific messages in advance, this can be a major benefit.
一般に、Untagged Messageの最善の利用は、連動して、自然に同期と同じメッセージに結ばれるデータを送ることです。 初期のデータ転送のために、これには、無期期間に広告、特定のTagged Buffersとして必要性を避ける追加利益があります。 代わりに、初期のデータ受信に匿名のバッファを使用できます。 あらかじめ匿名のバッファによって特定のメッセージに結ばれる必要はないので、これは主要な利益であるかもしれません。
4.5. Untagged Messages and Tagged Buffers as ULP Credits
4.5. ULPクレジットとしてメッセージとタグ付けをされたバッファをUntaggedしました。
The handling of end-to-end buffer credits differs considerably with DDP than when the ULP directly uses either TCP or SCTP.
終わりから終わりへのバッファクレジットの取り扱いはULPが直接TCPかSCTPのどちらかを使用する時よりDDPでかなり異なります。
Bestler & Coene Informational [Page 10] RFC 5045 RDMA/DDP Applicability October 2007
[10ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
With both TCP and SCTP, buffer credits are based upon the receiver granting transmit permission based on the total number of bytes. These credits reflect system buffering resources and/or simple flow control. They do not represent ULP resources.
TCPとSCTP、バッファクレジットが基づいている両方で、受信機の与えるのはバイトの総数に基づく許可を伝えます。 これらのクレジットはリソース、そして/または、簡単なフロー制御をバッファリングするシステムを反映します。 彼らはULPリソースを表しません。
DDP defines no standard flow control, but presumes the existence of a ULP mechanism. The presumed mechanism is that the Data Sink ULP has issued credits to the Data Source, allowing the Data Source to send a specific number of Untagged Messages.
DDPは、どんな標準のフロー制御も定義しませんが、ULPメカニズムの存在を推定します。 推定されたメカニズムはData Sink ULPがData Sourceにクレジットを発行したということです、Data SourceがUntagged Messagesの特定の数を送るのを許容して。
The ULP peers must ensure that the sender is aware of the maximum size that can be sent to any specific target buffer. One method of doing so is to use a standard size for all Untagged Buffers within a given connection. For example, a ULP may specify an initial Untagged Buffer size to be used immediately after session establishment, and then optionally specify mechanisms for negotiating changes.
ULP同輩は、送付者がどんな特定の目標バッファにも送ることができる最大サイズを意識しているのを保証しなければなりません。 そうする1つのメソッドは与えられた接続の中のすべてのUntagged Buffersに標準のサイズを使用することです。 例えば、ULPはセッション設立直後使用されるために初期のUntagged Bufferサイズを指定して、次に、任意に変化を交渉するのにメカニズムを指定するかもしれません。
Tagged Buffers are ULP resources Advertised directly from ULP to ULP. A DDP put to a known Tagged Buffer is constrained only by transport level flow control, not by available system buffering.
直接ULPからULPまでタグ付けをされたBuffersはULPリソースAdvertisedです。 知られているTagged BufferにつけられたDDPはフロー制御であって、利用可能なシステムでバッファリングしていない輸送レベルだけによって抑制されます。
Either Tagged or Untagged Buffers allows bypassing of system buffer resources. Use of Tagged Buffers additionally allows the Data Source to choose in what order to exercise the credits.
TaggedかUntagged Buffersのどちらかがシステムバッファ資源を迂回させます。 Tagged Buffersの使用で、Data Sourceはクレジットを運動させるどんな命令でさらに、選ぶことができるか。
To the extent allowed by the ULP, Tagged Buffers are also divisible resources. The Data Sink can Advertise a single 100 KB buffer, and then receive notifications from its peer that it had written 50 KB, 20 KB, and 30 KB to that buffer in three successive transactions.
ULPによって許容された範囲に、また、Tagged Buffersは分割可能なリソースです。 広告、a。Data Sinkがそうすることができる、100KBがバッファリングして、その時がそのバッファへの同輩からの50KBを書いたという通知、20KB、および30KBに3つの連続したトランザクションで受け取るシングル。
ULP management of Tagged Buffer resources, independent of transport and DDP layer credits, is an additional benefit of RDMA protocols. Large bulk transfers cannot be blocked by limited general-purpose buffering capacity. Applications can flow control based upon higher level abstractions, such as number of outstanding requests, independent of the amount of data that must be transferred.
輸送の如何にかかわらずTagged BufferリソースとDDP層のクレジットのULP管理はRDMAプロトコルの追加利益です。 容量をバッファリングする限られた汎用で大きいバルク転送を妨げることができません。 アプリケーションは移さなければならないデータ量の如何にかかわらず傑出している要求の数などの、より高い平らな抽象化に基づくフロー制御をそうすることができます。
However, use of system buffering, as offered by direct use of the underlying transports, can be preferable under certain circumstances.
しかしながら、システムバッファリングの基本的な輸送のダイレクト使用で提供する使用はある状況で望ましい場合があります。
One example would be when the number of target ULP Buffers is sufficiently large, and the rate at which any writes arrive is sufficiently low, that pinning all the target ULP Buffers in memory would be undesirable. The maximum transfer rate, and hence the maximum amount of system buffering required, may be more stable and predictable than the total ULP Buffer exposure.
1つの例はいつ目標ULP Buffersの数が十分大きくて、レートであるかということでしょう。いずれも到着すると書くものは十分低く、メモリにすべての目標ULP Buffersをピンで止めるのは望ましくないでしょう。 最大の転送レート、およびしたがって、バッファリングが必要としたシステムの最大の量は、総ULP Buffer暴露より安定していて予測できるかもしれません。
Bestler & Coene Informational [Page 11] RFC 5045 RDMA/DDP Applicability October 2007
[11ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Another example would be when the Data Sink wishes to receive a stream of data at a predictable rate, but does not know in advance what the size of each data packet will be. This is common from streaming media that has been encoded with a variable bit rate. With DDP, the Data Sink would either have to use Untagged Buffers large enough for the largest packet, or Advertise a circular buffer. If, for security or other reasons, the Data Sink did not want the size of its buffer to be publicly known, using the underlying SCTP transport directly may be preferable because of its byte-oriented credits.
別の例はData Sinkが予測できるレートでデータのストリームを受けることを願っていますが、あらかじめそれぞれのデータ・パケットのサイズがなるか何を知らない時でしょう。 それがメディアであったのを流すので可変ビット伝送速度でコード化されて、これは一般的です。 DDPと共に、Data Sinkが最も大きいパケットには、十分大きいUntagged Buffersを使用しなければならないだろう、さもなければ、広告。回覧バッファ。 Data Sinkがセキュリティか他の理由であって、公的にバッファのサイズを知っていて欲しくなかったなら、基本的なSCTP輸送を使用するのはバイト指向のクレジットのために直接望ましいかもしれません。
5. RDMA Read
5. RDMAは読みます。
RDMA Reads are a further service provided by RDMAP. RDMA Reads allow the Data Sink to fetch exactly the portion of the peer ULP Buffer required on a "just in time" basis. This can be done without requiring per-fetch support from the Data Source ULP.
RDMA ReadsはRDMAPによって提供されたさらなるサービスです。 RDMA ReadsはData Sinkにまさに「まさしく時間」ベースで必要である同輩ULP Bufferの一部をとって来させます。 Data Source ULPから1フェッチあたりの必要なサポートなしでこれができます。
Storage servers may wish to limit the maximum write buffer allocated to any single session. The storage server may be a very minimal layer between the client and the disk storage media, or the server may merely wish to limit the total resources that would be required if all clients could push the entire payload they wished written at their own convenience.
サーバが最大を制限したがっているかもしれないストレージはどんなただ一つのセッションまでも割り当てられたバッファを書きます。 ストレージサーバはクライアントとディスク記憶媒体の間の非常に最小量の層であるかもしれませんかサーバは単にすべてのクライアントが彼らがそれら自身の便利に書かれることを願っていた全体のペイロードを押すことができるなら必要である総リソースを制限したがっているかもしれません。
In either case, there is little benefit in transferring data from the Data Source far in advance of when it will be written to the persistent storage media. RDMA Reads allow the Storage Server to fetch the payload on a "just in time" basis. In this fashion, a relatively small number of block-sized buffers can be used to execute a single transaction that specified writing a large file, or a Storage Server with numerous clients can fetch buffers from the individual clients in the order that is most convenient to the server.
どちらの場合には、それが書かれる時のずっと前のData Sourceから永続的な記憶媒体までデータを移すのにおいて利益がほとんどありません。 RDMA ReadsはStorage Serverに「まさしく時間」ベースでペイロードをとって来させます。 こんなやり方で、大きいファイルを書きながら指定した単一取引を実行するのに比較的少ない数のブロックサイズのバッファを使用できますか、または多数のクライアントがいるStorage Serverは最も便利なオーダーにおける個々のクライアントからサーバまでバッファをとって来ることができます。
This same capability can be used when the desired portion of the Advertised Buffer is not known in advance. For example, the Advertised Buffer could contain performance statistics. The Data Sink could request the portions of the data it required, without requiring an interaction with the Data Source ULP.
Advertised Bufferの必要な部分があらかじめ知られていないとき、この同じ能力を使用できます。 例えば、Advertised Bufferは性能統計を含むことができました。 Data Sinkはそれが必要としたデータの部分を要求できました、Data Source ULPとの相互作用を必要としないで。
This is applicable for many applications that publish semi-volatile data that does not require transactional validity checking (i.e., authorized users have read access to the entire set of data). It is less applicable when there are ULP consistency checks that must be performed upon the data. Such applications would be better served by having the client send a request, and having the server use RDMA Writes to publish the requested data. Neither RDMAP nor DDP provide mechanisms for bundling multiple disjoint updates into an atomic
取引の正当性の照合を必要としない半揮発性データを発表する多くのアプリケーションに、これは適切です(すなわち、認定ユーザは全体のデータへのアクセスを読みました)。 データに実行しなければならないULP一貫性チェックがあるとき、それはそれほど適切ではありません。 そのようなアプリケーションで、クライアントに要求を送らせることによって役立たれるほうがよくて、サーバは、要求されたデータを発表するのにRDMA Writesを使用しているでしょう。 RDMAPもDDPも倍数がアップデートをばらばらにならせるバンドリングにメカニズムを提供しない、原子
Bestler & Coene Informational [Page 12] RFC 5045 RDMA/DDP Applicability October 2007
[12ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
operation. Therefore, use of an Advertised Buffer as a data resource is subject to the same caveats as any randomly updated data resource, such as flat files, that do not enforce their own consistency.
操作。 したがって、データリソースとしてのAdvertised Bufferの使用は平坦なファイルなどのどんな手当たりしだいにアップデートされたデータリソースとも同じそれら自身の一貫性を実施しないのに警告を受けることがあります。
6. LLP Comparisons
6. LLP比較
Normally, the choice of underlying IP transport is irrelevant to the ULP. RDMAP and DDP provides the same services over either. There may be performance impacts of the choice, however. It is the responsibility of the ULP to determine which IP transport is best suited to its needs.
通常、IP輸送の基礎となることの選択はULPと無関係です。 RDMAPとDDPは同じサービスをどちらかの上に提供します。 しかしながら、選択の性能影響があるかもしれません。どのIP輸送がそのの必要に最もよくぴったりとするかを決定するのは、ULPの責任です。
SCTP provides for preservation of message boundaries. Each DDP Segment will be delivered within a single SCTP packet. The equivalent services are only available with TCP through the use of the MPA (Marker PDU Alignment) adaptation layer.
SCTPはメッセージ限界の保存に備えます。 それぞれのDDP Segmentは単一のSCTPパケットの中で提供されるでしょう。 同等なサービスはTCPと共に単にMPA(マーカーPDU Alignment)適合層の使用で利用可能です。
6.1. Multistreaming Implications
6.1. 含意をMultistreamingします。
SCTP also provides multi-streaming. When the same pair of hosts have need for multiple DDP streams, this can be a major advantage. A single SCTP association carries multiple DDP streams, consolidating connection setup, congestion control, and acknowledgements.
また、SCTPはマルチストリーミングを提供します。 ホストの同じ組に複数のDDPストリームの必要があるとき、これは主要な利点であるかもしれません。 接続設定、輻輳制御、および承認を統合して、単一のSCTP協会は複数のDDPストリームを運びます。
Completions are controlled by the DDP Source Sequence Number (DDP- SSN) on a per-stream basis. Therefore, combining multiple DDP Streams into a single SCTP association cannot result in a dropped packet carrying data for one stream delaying completions on others.
落成は1ストリームあたり1個のベースでDDP Source Sequence Number(DDP SSN)によって制御されます。 したがって、複数のDDP Streamsを単一のSCTP協会に結合すると、携帯データが個人的には流す下げられたパケットは、落成を他のものに遅らせながら、もたらされることができません。
6.2. Out-of-Order Reception Implications
6.2. 不適切なレセプション含意
The use of unordered Data Chunks with SCTP guarantees that the DDP layer will be able to perform placements when IP datagrams are received out of order.
SCTPとの順不同のData Chunksの使用は、DDP層が故障していた状態でIPデータグラムが受け取られているときのプレースメントを実行できるのを保証します。
Placement of out-of-order DDP Segments carried over MPA/TCP is not guaranteed, but certainly allowed. The ability of the MPA receiver to process out-of-order DDP Segments may be impaired when alignment of TCP segments and MPA FPDUs is lost. Using SCTP, each DDP Segment is encoded in a single Data Chunk and never spread over multiple IP datagrams.
MPA/TCPの上まで運ばれた故障しているDDP Segmentsのプレースメントは、保証されませんが、確かに、許容されています。 TCPセグメントとMPA FPDUsの整列が無くなるとき、MPA受信機が故障しているDDP Segmentsを処理する能力は損なわれるかもしれません。 SCTPを使用して、それぞれのDDP Segmentは複数のIPデータグラムの上に独身のData Chunkと普及で決してコード化されません。
6.3. Header and Marker Overhead
6.3. ヘッダーとマーカーオーバーヘッド
MPA and TCP headers together are smaller than the headers used by SCTP and its adaptation layer. However, this advantage can be reduced by the insertion of MPA markers. The difference in ULP Payload per IP Datagram is not likely to be a significant factor.
一緒にMPAとTCPヘッダーはSCTPによって使用されたヘッダーとその適合層より小さいです。 しかしながら、この利点はMPAマーカーの挿入で減少できます。 IPデータグラムあたりのULP有効搭載量の違いは特筆すべき要因である傾向がありません。
Bestler & Coene Informational [Page 13] RFC 5045 RDMA/DDP Applicability October 2007
[13ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
6.4. Middlebox Support
6.4. Middleboxサポート
Even with the MPA adaptation layer, DDP traffic carried over MPA/TCP will appear to all network middleboxes as a normal TCP connection. In many environments, there may be a requirement to use only TCP connections to satisfy existing network elements and/or to facilitate monitoring and control of connections. While SCTP is certainly just as monitorable and controllable as TCP, there is no guarantee that the network management infrastructure has the required support for both.
MPA適合層があっても、MPA/TCPの上まで運ばれたDDPトラフィックは普通のTCP接続としてすべてのネットワークmiddleboxesにおいて現れるでしょう。 多くの環境には、既存のネットワーク要素を満たして、接続のモニターとコントロールを容易にするのにTCP接続だけを使用するという要件があるかもしれません。 SCTPはTCPとしてちょうど確かに同じくらいモニター可能であって、制御可能ですが、ネットワークマネージメントインフラストラクチャには両方の必要なサポートがあるという保証が全くありません。
6.5. Processing Overhead
6.5. 処理オーバヘッド
A DDP stream delivered via MPA/TCP will require more processing effort than one delivered over SCTP. However, this extra work may be justified for many deployments where full SCTP support is unavailable in the endpoints of the network, or where middleboxes impair the usability of SCTP.
MPA/TCPを通して提供されたDDP小川はSCTPの上に提供されたものより多くの処理取り組みを必要とするでしょう。 しかしながら、完全なSCTPサポートがネットワークの終点、またはmiddleboxesがSCTPのユーザビリティを損なうところで入手できないところでこの時間外労働は多くの展開のために正当化されるかもしれません。
6.6. Data Integrity Implications
6.6. データの保全含意
Both the SCTP [RFC4960] and MPA/TCP [RFC5044] adaptation provide end- to-end CRC32c protection against data accidental corruption, or its equivalent.
SCTP[RFC4960]とMPA/TCP[RFC5044]適合の両方がデータの偶然の不正、またはその同等物に対する終わりまでの終わりのCRC32c保護を提供します。
A ULP that requires a greater degree of protection may add its own. However, DDP and RDMAP headers will only be guaranteed to have the equivalent of end-to-end CRC32c protection. A ULP that requires data integrity checking more thorough than an end-to-end CRC32c should first invalidate all STags that reference a buffer before applying its own integrity check.
より大きい度合いの保護を必要とするULPはそれ自身のものを加えるかもしれません。 しかしながら、DDPとRDMAPヘッダーは、終わりから終わりへのCRC32c保護の同等物を持つために保証されるだけでしょう。 終わりから終わりへのCRC32cより徹底的にチェックするデータ保全を必要とするULPは最初に、それ自身の保全チェックを適用する前にバッファに参照をつけるすべてのSTagsを無効にするはずです。
CRC32c only provides protection against random corruption. To protect against unauthorized alteration or forging of data packets, security methods must be applied. The RDMA security document [RFC5042] specifies usage of RFC 2406 [RFC2406] for both adaptation layers. As stated in [RFC5042], note that the IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC 3723 [RFC3723], despite the existence of a newer version of IPsec specified in RFC 4301 [RFC4301] and related RFCs.
CRC32cは無作為の不正に対する保護を提供するだけです。 権限のない変更かデータ・パケットの鍛造物、セキュリティメソッドから守るのは適用していなければなりません。 RDMAセキュリティドキュメント[RFC5042]はRFC2406[RFC2406]の使用法を両方の適合層に指定します。 [RFC5042]に述べられているように、RDDPがIPsecのバージョンに基づいているので、IPsec要件がRFC2401[RFC2401]で指定して、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるようにRFCsを関係づけて、RFCsを関係づけたことに注意してください。
Bestler & Coene Informational [Page 14] RFC 5045 RDMA/DDP Applicability October 2007
[14ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
6.6.1. MPA/TCP Specifics
6.6.1. MPA/TCP詳細
It is mandatory for MPA/TCP implementations to implement CRC32c, but it is not mandatory to use the CRC32c during an RDMA connection. The activating or deactivating of the CRC in MPA/TCP is an administrative configuration operation at the local and remote end. The administration of the CRC (ON/OFF) is invisible to the ULP.
MPA/TCP実装がCRC32cを実装するのが、義務的ですが、RDMA接続の間、CRC32cを使用するのは義務的ではありません。 MPA/TCPでのCRCの動かすか非活性化が地方の、そして、リモートな終わりの管理構成操作です。 CRC(ON/OFF)の管理はULPに目に見えません。
Applications should assume that disabling CRC32c will only be used when the end-to-end protection is at least as effective as a transport layer CRC32c. Applications should not use additional integrity checks based solely on the possibility that CRC32c could be disabled without equivalent integrity checks at a lower level.
アプリケーションは、終わりから終わりへの保護がCRC32cトランスポート層と少なくとも同じくらい有効であるときにだけ、CRC32cを無効にするのが使用されると仮定するべきです。 アプリケーションは同等な保全チェックなしで下のレベルでCRC32cを無効にすることができた唯一可能性に基づく追加保全チェックを使用するべきではありません。
CRC32c must not be disabled unless equivalent or better end-to-end integrity protection is provided.
終わりから終わりへの保全同等であるか、より良い保護が提供されない場合、CRC32cを無効にしてはいけません。
If the CRC is active/used for one direction/end, then the use of the CRC is mandatory in both directions/ends.
CRCが1つの方向/終わりの間、アクティブであるか、または使用されているなら、CRCの使用は両方の方向/終わりで義務的です。
If both ends have been configured not to use the CRC, then this is allowed as long as an equivalent protection (comparable to or better than CRC) from undetected errors on the connection is provided.
両端がCRCを使用しないように構成されたなら、接続の非検出された誤りによる(CRCより匹敵するか良い)の同等な保護を提供する限り、これは許容されています。
6.6.2. SCTP Specifics
6.6.2. SCTP詳細
SCTP provides CRC32c protection automatically. The adaptation to SCTP provides for no option to suppress SCTP CRC32c protection.
SCTPは自動的に保護をCRC32cに供給します。 SCTPへの適合は、SCTP CRC32c保護を抑圧するためにオプションに全く備えません。
6.7. Non-IP Transports
6.7. 非IP輸送
DDP is defined to operate over ubiquitous IP transports such as SCTP and TCP. This enables a new DDP-enabled node to be added anywhere to an IP network. No DDP-specific support from middleboxes is required.
DDPは、SCTPやTCPなどの遍在しているIP輸送の上で作動するために定義されます。 これは、新しいDDPで可能にされたノードがIPネットワークにどこでも加えられるのを可能にします。 middleboxesからのどんなDDP特有のサポートも必要ではありません。
There are non-IP transport fabric offering RDMA capabilities. Because these capabilities are integrated with the transport protocol they have some technical advantages when compared to RDMA over IP. For example, fencing of RDMA Operations can be based upon transport level acks. Because DDP is cleanly layered over an IP transport, any explicit RDMA layer ack must be separate from the transport layer ack.
非IP輸送骨組みの提供RDMA能力があります。 これらの能力がトランスポート・プロトコルについて統合しているので、それらには、IPの上でRDMAと比べると、いくつかの技術的な利点があります。 例えば、RDMA Operationsのフェンシングは輸送レベルacksに基づくことができます。 DDPがIP輸送の上で清潔に層にされるので、どんなackの明白なRDMA層もackトランスポート層から別々であるに違いありません。
There may be deployments where the benefits of RDMA/transport integration outweigh the benefits of being on an IP network.
展開がRDMA/輸送統合の恩恵がIPネットワークにある利益より重いところにあるかもしれません。
Bestler & Coene Informational [Page 15] RFC 5045 RDMA/DDP Applicability October 2007
[15ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
6.7.1. No RDMA-Layer Ack
6.7.1. Ack RDMA-層がありません。
DDP does not provide for its own acknowledgements. The only form of ack provided at the RDMAP layer is an RDMA Read Response. DDP and RDMAP rely almost entirely upon other layers for flow control and pacing. The LLP is relied upon to guarantee delivery and avoid network congestion, and ULP-level acking is relied upon for ULP pacing and to avoid ULP Buffer overruns.
DDPはそれ自身の承認に備えません。 RDMAP層で提供されたackの唯一のフォームがRDMA Read Responseです。 DDPとRDMAPはフロー制御とペースのために他の層をほぼ完全に当てにします。 荷渡しを保証して、ネットワークの混雑を避けるためにLLPを当てにされます、そして、ULPペース、ULP Buffer超過を避けるためにULP-レベルackingを当てにされます。
Previous RDMA protocols, such as InfiniBand, have been able to use their integration with the transport layer to provide stronger ordering guarantees. It is important that application designers that require such guarantees provide them through ULP interaction.
インフィニバンドなどの前のRDMAプロトコルは、保証を命令しながら、より強い状態で提供するのにトランスポート層による彼らの統合を使用できました。 そのような保証を必要とするアプリケーション設計者がULP相互作用でそれらを提供するのは、重要です。
Specifically:
明確に:
There is no ability for a local interface to "fence" outbound
messages to guarantee that prior Tagged Messages have been placed
prior to sending a Tagged Message. The only guarantees available
from the other side would be an RDMA Read Response (coming from
the RDMAP layer) or a response from the ULP layer. Remember that
the normal ordering rules only guarantee when the Data Sink ULP
will be notified of Untagged Messages; it does not control when
data is placed into receive buffers.
局所界面がTagged Messageを送る前に先のTagged Messagesが置かれたのを保証する外国行きのメッセージを「囲う」能力が全くありません。 反対側から利用可能な唯一の保証が、RDMA Read Response(RDMAP層から、来る)かULP層からの応答でしょう。 Data Sink ULPがUntagged Messagesについて通知されるとき、正常な注文が保証だけを統治するのを覚えていてください。 それは、データがいつ受信バッファの中に置かれるかを制御しません。
Re-use of Tagged Buffers must be done with extreme care. The fact
that an Untagged Message indicates that all prior Tagged Messages
have been placed does not guarantee that no later Tagged Message
has. The best strategy is to change only the state of any given
Advertised Buffers with Untagged Messages.
極端な注意でTagged Buffersの再使用をしなければなりません。 Untagged Messageが、すべての先のTagged Messagesが置かれたのを示すという事実は、後のそのノーTagged Messageが持っているのを保証しません。 最も良い戦略はUntagged MessagesとAdvertised Buffersを考えて、いずれの状態だけを変えることです。
As covered elsewhere in this document, flow control of Untagged
Messages is the responsibility of the ULP.
本書ではほかの場所にカバーされるように、Untagged Messagesのフロー制御はULPの責任です。
6.8. Other IP Transports
6.8. 他のIP輸送
Both TCP and SCTP provide DDP with reliable transport with TCP- friendly rate control. Currently, DDP is defined to work over reliable transports and implicitly relies upon some form of rate control.
TCPとSCTPの両方がTCPの好意的な速度制御で信頼できる輸送をDDPに提供します。 現在、DDPは、信頼できる輸送の上で働くために定義されて、それとなく何らかの形式の速度制御を当てにします。
DDP is fully compatible with a non-reliable protocol. Out-of-order placement is obviously not dependent on whether the other DDP Segments ever actually arrive.
DDPは非信頼できるプロトコルと完全に互換性があります。 不適切なプレースメントは明らかに他のDDP Segmentsが実際に到着するかどうかに依存していません。
However, RDMAP requires the LLP to provide reliable service. An alternate completion handling protocol would be required if DDP were to be deployed over an unreliable IP transport.
しかしながら、RDMAPは、LLPが信頼できるサービスを提供するのを必要とします。 代替の完成取り扱いプロトコルがDDPが頼り無いIP輸送の上で配布されることであるなら必要です。
Bestler & Coene Informational [Page 16] RFC 5045 RDMA/DDP Applicability October 2007
[16ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
As noted in the prior section on Tagged Buffers as ULP credits, neither RDMAP nor DDP provides any flow control for Tagged Messages. If no transport layer flow control is provided, an RDMAP/DDP application would be limited only by the link layer rate, almost inevitably resulting in severe network congestion.
ULPクレジットとしてTagged Buffersの上の先のセクションで注意されるように、RDMAPもDDPもどんなフロー制御もTagged Messagesに供給しません。 トランスポート層フロー制御を全く提供しないなら、リンクレイヤレートだけでRDMAP/DDPアプリケーションを制限するでしょう、ほぼ必然的に厳しいネットワークの混雑をもたらして。
RDMAP encourages applications to be ignorant of the underlying transport path MTU. The ULP is only notified when all messages ending in a single Untagged Message have completed. The ULP is not aware of the granularity or ordering of the underlying message. This approach assumes that the ULP is only interested in the complete set of messages, and has no use for a subset of them.
RDMAPは、アプリケーションに基本的な輸送経路MTUに無知であるよう奨励します。 Untagged Messageが完成したシングルに終わるすべてのメッセージであるときにだけ、ULPは通知されます。 ULPは意識しない、粒状をまた基本的なメッセージを注文しません。 このアプローチは、ULPが完全なセットのメッセージに興味を持っているだけであり、それらの部分集合のために無駄を持っていると仮定します。
6.9. LLP-Independent Session Establishment
6.9. LLPから独立しているセッション設立
For an RDMAP/DDP application, the transport services provided by a pair of SCTP streams and by a TCP connection both provide the same service (reliable delivery of DDP Segments between two connected RDMAP/DDP endpoints).
RDMAP/DDPアプリケーションのために、1組のSCTPの流れとTCP接続によって提供された輸送サービスはともに同じサービスを提供します(2の間のDDP Segmentsの信頼できる配信はRDMAP/DDP終点をつなげました)。
6.9.1. RDMA-Only Session Establishment
6.9.1. RDMAだけセッション設立
It is also possible to allow for transport-neutral establishment of RDMAP/DDP sessions between endpoints. Combined, these two features would allow most applications to be unconcerned as to which LLP was actually in use.
また、終点の間のRDMAP/DDPセッションの輸送中立の設立を考慮するのも可能です。 結合されていて、これらの2つの特徴が、どのLLPが実際に使用中であったかに関して無関心になるようにほとんどのアプリケーションを許容するでしょう。
Specifically, the procedures for DDP Stream Session establishment
discussed in section 3 of the SCTP mapping, and section 13.3 of the
MPA/TCP mapping, both allow for the exchange of ULP-specific data
("Private Data") before enabling the exchange of DDP Segments. This
delay can allow for proper selection and/or configuration of the
endpoints based upon the exchanged data. For example, each DDP
Stream Session associated with a single client session might be
assigned to the same DDP Protection Domain.
明確に、DDP Segmentsの交換を可能にする前に、SCTPマッピングのセクション3、およびMPA/TCPマッピングのセクション13.3で議論したDDP Stream Session設立のための手順はともにULP特有のデータ(「個人的なデータ」)の交換を考慮します。 この遅れは交換されたデータに基づく終点の適切な選択、そして/または、構成を考慮できます。 例えば、ただ一つのクライアントセッションに関連しているそれぞれのDDP Stream Sessionは同じDDP Protection Domainに割り当てられるかもしれません。
To be transport neutral, the applications should exchange Private Data as part of session establishment messages to determine how the RDMA endpoints are to be configured. One side must be the Initiator, and the other, the Responder.
輸送中立に、なるように、アプリケーションはRDMA終点が構成されることになっている方法を決定するセッション設立メッセージの一部として兵士のDataを交換するべきです。 半面は、Initiatorと、他、Responderであるに違いありません。
With SCTP, a pair of SCTP streams can be used for successive sessions while the SCTP association remains open. With MPA/TCP, each connection can be used for, at most, one session. However, the same source/destination pair of ports can be re-used for a subsequent TCP connection, as allowed by TCP.
SCTP協会が開いたままで残っている間、SCTPと共に、連続したセッションに1組のSCTPの流れを使用できます。 MPA/TCPと共に、大部分の1つのセッションに各接続を使用できます。 しかしながら、TCPによって許容されているようにその後のTCP接続にポートの同じソース/目的地組を再使用できます。
Bestler & Coene Informational [Page 17] RFC 5045 RDMA/DDP Applicability October 2007
[17ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Both SCTP and MPA limit the private data size to a maximum of 512 bytes.
ともに、SCTPとMPAは個人的なデータサイズを最大512バイトに制限します。
MPA/TCP requires the end of the TCP connection that initiated the conversion to MPA mode to send the first DDP Segment. SCTP does not have this requirement. ULPs that wish to be transport neutral should require the initiating end to send the first message. A zero-length RDMA Write can be used for this purpose if the ULP logic itself does naturally support this restriction.
MPA/TCPは最初のDDP Segmentを送るためにMPAモードに変換を開始したTCP接続の終わりを必要とします。 SCTPには、この要件がありません。 輸送中立になりたがっているULPsは、最初のメッセージを送るために開始終わりを必要とするはずです。 このためにULP論理自体が自然にこの制限をサポートするなら、無の長さのRDMA Writeを使用できます。
6.9.2. RDMA-Conditional Session Establishment
6.9.2. RDMA条件付きのセッション設立
It is sometimes desirable for the active side of a session to connect with the passive side before knowing whether the passive side supports RDMA.
セッションアクティブ側が受け身側がRDMAを支えるかどうかを知る前の受け身側に接続するのは、時々望ましいです。
This style of session establishment can be supported with either TCP or SCTP, but not as transparently as for RDMA-only sessions. Pre- existing non-RDMA servers are also far more likely to be using TCP than SCTP.
このスタイルのセッション設立はTCPかSCTPのどちらかと共にサポートされますが、RDMAだけセッションで透過的にサポートすることができません。 また、プレ既存の非RDMAサーバもSCTPよりはるかにTCPを使用していそうです。
With TCP, a normal TCP connection is established. It is then used by the ULP to determine whether or not to convert to MPA mode and use RDMA. This will typically be integral with other session- establishment negotiations.
TCPと共に、普通のTCP接続は確立されます。 そして、それは、MPAモードに変えて、RDMAを使用するかどうか決定するのにULPによって使用されます。 これは他のセッション設立交渉で通常不可欠になるでしょう。
With SCTP, the establishment of an association tests whether RDMA is supported. If not supported, the application simply requests the association without the RDMA adaptation indication.
RDMAがサポートされるか否かに関係なく、SCTPと共に、協会の設立はテストされます。 サポートされないなら、アプリケーションはRDMA適合指示なしで協会を単に要求します。
One key difference is that with SCTP the determination as to whether the peer can support RDMA is made before the transport layer association/connection is established, while with TCP the established connection itself is used to determine whether RDMA is supported.
1つの主要な違いはトランスポート層協会/接続を確立する前にSCTPと共に、同輩がRDMAをサポートすることができるかどうかに関する決断をするということです、確立した接続自体がRDMAがサポートされるかどうか決定するのにTCPと共に使用されますが。
7. Local Interface Implications
7. 局所界面含意
Full utilization of DDP and RDMAP capabilities requires a local interface that explicitly requests these services. Protocols such as Sockets Direct Protocol (SDP) can allow applications to keep their traditional byte-stream or message-stream interface and still enjoy many of the benefits of the optimized wire level protocols.
DDPとRDMAP能力の完全利用は明らかにこれらのサービスを要求する局所界面を必要とします。 Sockets Directなどのプロトコル(SDP)で、それらの伝統的なバイト・ストリームかメッセージストリームインタフェースを保って、まだ最適化されたワイヤの利益の多くをアプリケーションを持つことができるプロトコルはプロトコルを平らにします。
Bestler & Coene Informational [Page 18] RFC 5045 RDMA/DDP Applicability October 2007
[18ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
8. Security Considerations
8. セキュリティ問題
RDMA security considerations are discussed in the RDMA security document [RFC5042]. This document will only deal with the more usage-oriented aspects, and where there are implications in the choice of underlying transport.
RDMAセキュリティドキュメント[RFC5042]でRDMAセキュリティ問題について議論します。 このドキュメントは輸送の基礎となることの選択には含意があるところで、より用法指向の局面に対処するだけでしょう。
8.1. Connection/Association Setup
8.1. 接続/協会セットアップ
Both the SCTP and TCP adaptations allow for existing procedures to be followed for the establishment of the SCTP association or TCP connection. Use of DDP does not impair the use of any security measures to filter, validate, and/or log the remote end of an association/connection.
SCTPとTCP適合の両方が、存在するように手順がSCTP協会かTCP接続の設立のために従われるのを許容します。 DDPの使用は、協会/接続のリモートエンドをフィルターにかけて、有効にする、そして/または、登録するためにどんな安全策の使用も損ないません。
8.2. Tagged Buffer Exposure
8.2. タグ付けをされたバッファ暴露
DDP only exposes ULP memory to the extent explicitly allowed by ULP actions. These include posting of receive operations and enabling of Steering Tags.
DDPは、ULPがメモリであることをULP動作で明らかに許容された範囲にさらすだけです。 これらは、Steering Tagsについて掲示するのを操作を受けて、可能にするのを含んでいます。
Neither RDMAP nor DDP places requirements on how ULPs Advertise Buffers. A ULP may use a single Steering Tag for multiple buffer Advertisements. However, the ULP should be aware that enforcement on STag usage is likely limited to the overall range that is enabled. If the Remote Peer writes into the 'wrong' Advertised Buffer, neither the DDP nor the RDMAP layer will be aware of this. Nor is there any report to the ULP on how the Remote Peer specifically used Tagged Buffers.
RDMAPもDDPも要件を置かない、どのようにULPs、広告、Buffers。 ULPは複数のバッファAdvertisementsに独身のSteering Tagを使用するかもしれません。 しかしながら、ULPはSTag用法における実施がおそらく可能にされる総合的な範囲に制限されるのを意識しているべきです。 Remote Peerが'間違った'Advertised Bufferに書くと、DDPもRDMAP層もこれを意識しないでしょう。 また、ULPへのRemote Peerがどう明確にTagged Buffersを使用したかに関するどんなレポートもありません。
Unless the ULP peers have an adequate basis for mutual trust, the receiving ULP might be well advised to use a distinct STag for each interaction, and to invalidate it after each use, or to require its peer to use the RDMAP option to invalidate the STag with its responding Untagged Message.
ULP同輩に信頼関係の適切な基礎がないなら、受信ULPは各相互作用に異なったSTagを使用して、使用後その都度それを無効にするか、または同輩がUntagged Messageを反応させるのにSTagを無効にするのにRDMAPオプションを使用するのが必要であるように上手にアドバイスされるかもしれません。
8.3. Impact of Encrypted Transports
8.3. 暗号化された輸送の影響
While DDP is cleanly layered over the LLP, its maximum benefit may be limited when the LLP Stream is secured with a streaming cypher, such as Transport Layer Security (TLS) [RFC4346]. If the LLP must decrypt in order, it cannot provide out-of-order DDP Segments to the DDP layer for placement purposes. IPsec [RFC2401] tunnel mode encrypts entire IP Datagrams. IPsec transport mode encrypts TCP Segments or SCTP packets, as does use of Datagram TLS (DTLS) [RFC4347] over UDP beneath TCP or SCTP. Neither IPsec nor this use of DTLS precludes providing out-of-order DDP Segments to the DDP layer for placement.
LLP Streamがストリーミングの暗号化で固定されているとき、DDPがLLPの上で清潔に層にされている間、最大限の利益は制限されるかもしれません、Transport Layer Security(TLS)[RFC4346]などのように。 LLPが整然とした状態で解読しなければならないなら、それはプレースメント目的のために故障しているDDP SegmentsをDDP層に供給できません。 IPsec[RFC2401]トンネルモードは全体のIPデータグラムを暗号化します。IPsec交通機関はTCP SegmentsかSCTPパケットを暗号化します、TCPかSCTPの下のUDPの上のデータグラムTLS(DTLS)[RFC4347]の使用のように。 IPsecもDTLSのこの使用も、プレースメントのために故障しているDDP SegmentsをDDP層に供給するのを排除しません。
Bestler & Coene Informational [Page 19] RFC 5045 RDMA/DDP Applicability October 2007
[19ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Note that end-to-end use of cryptographic integrity protection may allow suppression of MPA CRC generation and checking under certain circumstances. This is one example where the LLP may be judged to have "or equivalent" protection to an end-to-end CRC32c.
暗号の保全保護の終わりから最終用途が、ある状況でMPA CRC世代と照合の抑圧を許すかもしれないことに注意してください。 終わりから終わりへのCRC32cへのLLPがそうである1つの例が持つために判断され「同等である」というこの保護。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、「ストリーム制御伝動プロトコル」、RFC4960、2007年9月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, October 2007.
[RFC5040]RecioとR.とメツラーとB.とCulleyとP.とHilland、J.とD.ガルシア、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(2007年10月)。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley,
"Direct Data Placement over Reliable Transports",
RFC 5041, October 2007.
2007年10月の[RFC5041]シャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
[RFC5042] Pinkerton, J. and E. Deleganes, "DDP/RDMAP Security",
RFC 5042, October 2007.
[RFC5042] ピンカートンとJ.とE.Deleganes、「DDP/RDMAPセキュリティ」、RFC5042、2007年10月。
[RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Direct Data Placement (DDP) Adaptation",
RFC 5043, October 2007.
[RFC5043]BestlerとC.とR.スチュワート、「ストリーム制御伝動プロトコル(SCTP)ダイレクトデータプレースメント(DDP)適合」、RFC5043、2007年10月。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, October 2007.
[RFC5044] Culley、P.、Elzur、U.、Recio、R.、べイリー、S.、およびJ.キャリヤー、「マーカーPDUはTCPのために仕様を縁どりながら、並びました」、RFC5044、2007年10月。
9.2. Informative References
9.2. 有益な参照
[NFSDIRECT] Talpey, T., Callaghan, B., and I. Property, "NFS Direct
Data Placement", Work in Progress, June 2007.
T.とキャラハン、B.とI.の特性、「NFSのダイレクトデータプレースメント」という[NFSDIRECT]Talpeyは進歩、2007年6月に働いています。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「IPの上でブロックストレージがプロトコルであると機密保護します」、RFC3723(2004年4月)。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Bestler & Coene Informational [Page 20] RFC 5045 RDMA/DDP Applicability October 2007
[20ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4347] レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、RFC4347、2006年4月。
[RFC5046] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., and P.
Thaler, "Internet Small Computer System Interface
(iSCSI) Extensions for Remote Direct Memory Access
(RDMA)", RFC 5046, October 2007.
[RFC5046] コー、M.、Chadalapaka、M.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」、RFC5046(2007年10月)。
Authors' Addresses
作者のアドレス
Caitlin Bestler (editor) Neterion 20230 Stevens Creek Blvd. Suite C Cupertino, CA 95014 USA
ケイトリンBestler(エディタ)Neterion20230スティーブンスクリークBlvd. Suite Cカルパチーノ(カリフォルニア)95014米国
Phone: 408-366-4639 EMail: caitlin.bestler@neterion.com
以下に電話をしてください。 408-366-4639 メールしてください: caitlin.bestler@neterion.com
Lode Coene Nokia Siemens Networks Atealaan 26 Herentals 2200 Belgium
鉱脈CoeneノキアジーメンスはAtealaan26ヘーレンタルス2200ベルギーをネットワークでつなぎます。
Phone: +32-14-252081 EMail: lode.coene@nsn.com
以下に電話をしてください。 +32-14-252081はメールされます: lode.coene@nsn.com
Bestler & Coene Informational [Page 21] RFC 5045 RDMA/DDP Applicability October 2007
[21ページ]RFC5045RDMA/DDP適用性2007年10月の情報のBestler&Coene
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Bestler & Coene Informational [Page 22]
Bestler&Coene情報です。[22ページ]
一覧
スポンサーリンク
