Network Working Group C. Bestler, Ed.
Request for Comments: 5045 Neterion
Category: Informational L. Coene
Nokia Siemens Networks
October 2007
Applicability of Remote Direct Memory Access Protocol (RDMA)
and Direct Data Placement Protocol (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.
この文書では、リモートダイレクトメモリアクセスプロトコル（RDMAP）と直接データの配置プロトコル（DDP）の適用性を説明しています。これは、比較してDDPを使用することができますIP上の異なるトランスポートオプションを対比し、利用可能なトランスポートとの間の選択にULP開発者にガイダンスを提供/または使用される特定のトランスポート層に無関心になる方法を、支えるトランスポートを直接使用してDDPの使用を比較、およびIP上でDDPを比較して非IPはそのサポートRDMA機能を輸送して運搬します。
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
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).
リモートダイレクトメモリアクセスプロトコル（RDMAP）[RFC5040]と直接データ配置（DDP）[RFC5041]直接上位層プロトコル（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プロトコルはULPおよびデータシンクが開始し（RDMA読み込み）アドバタイズバッファのフェッチのために支持体に完了通知を提供します。
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がリモート直接データ配置を実行できるように、両方のアプリケーションに依存しないプロトコルです。 DDPは、複数の標準IPは、SCTPとTCPなどのトランスポートを使用することができます。
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.
これらのプロトコルの機能が適用される状況を明確にすることによって、この文書では、使用するプロトコルを選択して実装し、アプリケーションとプロトコルの設計者を導くことができます。
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は、タグなしおよびタグ付きバッファの両方をサポートしています。バッファは、データシンクULPは、どのような順序（または何のメッセージ内）に無関心ことを可能にするタグ付けされたデータソースは、データを送信し、またはどのような順序でパケットが受信されています。最高の制御メッセージのために使用されるタグなしながら、典型的には、タグ付けされたデータは、ペイロード転送のために使用することができます。しかしながら、各上位層プロトコルは、それ自体のためにタグ付きおよびタグなしメッセージの最適な使用を決定することができます。データソースの柔軟性がアプリケーションに有益である場合に、この文書では説明します。
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読み込み定義します。この文書では、代替ソリューションとは対照的に読み取り、RDMAを使用することの利点を検討します。
A more comprehensive introduction to the RDMAP and DDP protocols and discussion of their security considerations can be found in [RFC5042].
RDMAPとDDPプロトコルとそのセキュリティ上の考慮事項の議論により包括的な導入は、[RFC5042]で見つけることができます。
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は、InfiniBandなど、輸送、直接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のすべての機能は完全にそれらを利用するように設計されたアプリケーションで実現することができます。伝統的なソケットインタフェースとRDMAP / DDP対応ローカルインタフェースの共存もまた探求します。
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.
SCTP [RFC5043]とTCP [RFC5044]：最後に、DDPサポートは、少なくとも2つのIPトランスポートのために定義されています。両方のトランスポートをサポートするための理論的根拠は、それぞれが適切な選択であろう場合と同様に、見直されます。
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バッファがそれに利用可能なリモートピアに通知する行為。ノードは、RDMA /タグ付きバッファ識別子のDDPピア（婚前、ベースアドレス、およびバッファ長）を通知することにより、着信RDMA読み取り又はRDMA書き込みアクセスのために利用可能なRDMAバッファを行います。タグ付きバッファ情報のこの広告は、RDMA / DDPによって定義されていないとULPに任されています。典型的な方法は、リモートピア宛てのメッセージ送信にタグ付けバッファのステアリングタグ、ベース・アドレス、および長さを埋め込むローカルピアのためになります。
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.
データシンク - データペイロードを受信するピア。データシンクがデータペイロードを転送するRDMA / DDPメッセージを送受信するために、両方の必要とされることができることに留意されたいです。
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.
データソース - データペイロードを送信ピア。データソースは、データペイロードを転送するRDMA / DDPメッセージを送受信するには、両方必要になることができることに注意してください。
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.
下位レイヤプロトコル（LLP） - DDPにサービスを提供するトランスポートプロトコル。これは、必要なアダプテーション層とIPトランスポートです。アダプテーション層は、SCTPとTCPのために定義されています。
Steering Tag (STag) - An identifier of a Tagged Buffer on a Node, valid as defined within a protocol specification.
ステアリングタグ（婚前） - プロトコル仕様内で定義されるように有効なノードにタグ付けバッファの識別子。
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.
タグ付けされたメッセージ - 埋め込まれたアドレス情報に基づいて、ULP-指定されたバッファに向けられるDDPメッセージ。即時の意味では、宛先バッファは、メッセージ送信者によって指定されています。メッセージ受信機は、タグ付きメッセージが受信された独立した指標を与えられていません。
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.
タグなしメッセージ - 受信機が提供バッファに一致されるメッセージシーケンス番号に基づいて、ULP-指定されたバッファに向けられるDDPメッセージ。宛先バッファは、メッセージ受信者によって指定されています。メッセージ受信機はタグなしメッセージが受信されたいくつかの機構によって通知されます。
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.
上位層プロトコル（ULP） - RDMAP / DDPサービスの直接のユーザ。そのようなRDMA [NFSDIRECT]上のiSER [RFC5046]とのNFSv4しばしばソケット直接プロトコル（SDP）とリモートプロシージャコールの場合のように、ULPは、アプリケーションやミドルウェア層に埋め込まれてもよい（RPCなどのプロトコルに加えて）プロトコル。
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.
直接データ配置は、典型的には、中間コピーを排除し、正しい宛先バッファにULPペイロードの配置を最適化します。配置は到着、送信順序、またはULPとあたり-配置の相互作用の要件の順序に関係なく有効になります。
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の相互作用のための複数のトランスポート層パケットを必要とするアプリケーションのための最も貴重なものです。
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がなければ、事前に投稿バッファを正確に必要なバッファとそのサイズを予測するために、受信側が必要です。これは、すべてのULPのために現実的ではありません。これとは対照的に、DDPは、着信タグなしメッセージの順序とサイズを予測するULPが必要です。
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 application would only have to predict the sequence of messages and the maximum size of each message, not the exact size.
着信メッセージを予測し、バッファに直接配置する以上のものを必要とすることができなかったアプリケーションがネイティブSCTPまたは（RDMAなし）TCPに適切に設計されたローカル・インターフェースで、そうすることができるかもしれません。これは、アプリケーションがメッセージのみのシーケンスと各メッセージの最大サイズではなく、正確なサイズを予測しなければならないので、ネイティブのSCTPを使用して簡単です。
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の主な利点は、事前に掲載の受信バッファということでしょう義務付けローカルインタフェースの機能であり、予測が常に（ないバイトごと）ごとのメッセージに基づいて行うことができます。
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特有の知識が受信したパケットの「パースと場所」の取り扱いを可能にするために、プロトコルスタックに組み込まれている場合は下位層プロトコル、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とプロトコルスタックとの間の緊密な結合を必要とせず、着信ペイロードを配置することの利点を達成します。しかし、「解析と場所」の能力は確かの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、および電子メールなどのコンテンツアクセスの他のアプリケーション固有の形態を含みます。
This section covers the major benefits from the use of 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のより重要な利点は、タグ付きバッファを使用するには、データソースの能力です。メッセージをタグ付けすることは、データソースは、そのペイロード配達の順序とパケットを選択することができます。単に前投稿に基づいて直接データ配置を受信すると、ペイロードのパケット化と配信は、事前にULPピアによって合意されなければなりません。
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 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:
通常、タグなしのメッセージに属するデータのいくつかの例には、含まれます：
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.
そのインクルージョンがデータをフェッチするためのラウンドトリップを排除するであろう、特にほとんど常に必要とされている比較的短いペイロード、。例としては、書き込み要求とタグ付きバッファの広告の初期データが含まれます。
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.
タグ付けされたメッセージは、上位層とパケット単位の相互作用なしにデータの直接配置を標準化します。ミドルウェアソリューションで一般的であるように、転送されているものの上位層プロトコルのエンコーディングがある場合でも、この情報は、アプリケーションに依存しない層に理解されていません。着信データを配置する場所の指示は、最初のULPに切り替えることなくアクセスすることができません。 DDPはULP相互作用を必要とせずに解釈することができる標準化された「パッキングリスト」を、提供します。確かに、ハードウェアで実現可能になるように設計されています。
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.
タグ付けされたメッセージが含まれてステアリングタグに基づいて、バッファに向けられています。また、何の通知は、個々のタグ付きメッセージの到着をULPに提供されていません。一緒に、これらは順不同で受信したタグ付きメッセージは、中間バッファリングまたは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は、タグ付きおよびタグなしの両方のメッセージを提供しています。いいえ、受信側のULP相互作用は、タグ付きメッセージのために必要ありません。最適タグ付きおよびタグなしメッセージとの間のトラフィックを分割することにより、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相互作用を減少させます。ほとんどのULPのために、これは根本的にさらにULP必要な相互作用の数を減らします。
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。 「交換」ここで、ゼロまたはそれ以上のタグ付きメッセージおよび単一終端タグなしメッセージのセットです。できるだけ早く受信したペイロードに作業を開始することを好むアプリケーションは、関係なく、それはで着いたどのような順序、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相互作用が何であるかを達成するために、複数のトランスポート層パケットを使用するアプリケーションのために非常に有益であり得ます。
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.
タグ付きメッセージの通知ルールのULPは、ULP相互作用に単一のステップを表すゼロ個以上のタグ付きメッセージからなるマルチメッセージ「交換」を作成することを可能にします。受信ULPは、タグなしのメッセージが到着し、暗黙的に関連するタグ付きメッセージの通知を受けたことが通知されます。
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が効果的にタグ付きのメッセージを使用できない場合は、SCTPを直接使用と比較してRDMAP / DDPの使用からほとんど利益を引き出すでしょう。タグ付きバッファはRDMAP / DDPのために正当化している間しかし、タグなしバッファがまだ必要です。タグなしバッファなし、バッファ広告を交換する唯一の方法は、アウトオブバンド通信を必要とするであろう。ほとんどのRDMA対応ののULPは、要求と応答のためのタグなしバッファを使用しています。バッファ広告は通常、これらのタグなしメッセージ内で行われています。
More importantly, there would be no reliable method for the upper-layer peers to synchronize. The absence of any guarantees about ordering within or between Tagged Messages is fundamental to allowing the DDP layer to optimize transfer of tagged payload.
より重要なことに、上層ピアが同期するための信頼できる方法はないだろう。タグ付きメッセージ内または間注文に関する保証の欠如は、DDP層がタグ付けされたペイロードの転送を最適化することを可能に基本的です。
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.
そのため、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:
タグ付けされた転送を使用して、すべてのバルク・データを移動することによって、リクエストとレスポンスにタグなしバッファの使用を制限することは、非常にデータシンクは、事前に掲示して実行しなければならないという予測の量を簡素化することができます受信バッファ。例えば、典型的なRDMA対応の相互作用は、以下で構成されます：
1. Client sends transaction request to server as an Untagged Message.
1.クライアントがタグなしのメッセージとしてサーバーにトランザクション要求を送信します。
2. This message includes buffer Advertisements for the buffers where the results are to be placed.
2.このメッセージは、結果が配置されるバッファのバッファ広告を含みます。
3. The server sends multiple Tagged Messages to the Advertised buffers.
3.サーバはアドバタイズバッファに複数のタグ付きのメッセージを送信します。
4. The server sends transaction reply as an Untagged Message to the client.
4.サーバーは、クライアントへのタグなしのメッセージとしてトランザクション応答を送信します。
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.
為替のこのタイプでは、ペーシングおよびタグなしバッファの必要なサイズは非常に予測可能です。応答の大きさのばらつきは、タグ付けされた転送によって吸収されます。
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).
データシンクは、実際のサイズ、構造、またはそれが要求（または更新）されたコンテンツの場所を知らない場合にタグ付きメッセージの使用は、特に適用されます。
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.
例えば、データシンクULPは、4つの別々のバッファにデータの4つの関連作品をフェッチする必要があるとします。 SCTPを使用すると、データシンクULPは、各の最大サイズを予測すること、4つの別々のバッファに4つのメッセージを受け取ることができます。しかし、それはデータソースが別々の部品を供給する順番を決定しなければなりません。データソースは異なる順序でそれらを取得することが有利であることが判明した場合、それは次の再中間バッファリングを使用しなければならないアプリケーションは唯一、すべての4が配信されることを必要と真の順序を持っていなかったにもかかわらず、予想されるために作品要求。
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ストライピングとミラーリングのような技術は、この同じ問題を表すが、さらに一歩。何が実際にデータソースによって別々の場所に格納されたデータシンクに単一のリソースであるように思われます。非RDMAプロトコルは、いずれかの所望の順序で材料をフェッチまたは宛先バッファの画像を組み立てるために、自身の保持バッファを使用するデータソースを強制的にデータソースを必要とするであろう。
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).
データシンクが要求されたデータの真の順序や場所を知っているだろう、なぜ、多くの理由があります。これは、異なるレコードが選択され、および/または異なるソート順、クライアントごとに異なる可能性、ならびにサーバ側としてコンテンツのRAIDストライピング、ファイルの断片化、ボリュームの断片化、ボリュームミラーリング、およびサーバ側動的合成は、（HTTPのために含まれ）。
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.
これらすべての場合には、データソースは、コンポーネントのデータがそれに利用可能になるどんな順序でデータシンクのバッファに必要なデータを集めるために自由です。それは順序に拘束されません。これは、データシンクのバッファにそれを作成する前に、自身のメモリに画像を組み立てることはありません。
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は、バルク転送のために、タグ付きメッセージの使用を可能にしながら、タグなしメッセージはまだバルク転送のために使用されるいくつかのアプリケーションシナリオがあることに注意してください。例えば、ファイルサーバは、クライアントに独自のメモリを公開しない場合があります。 RDMAを発行するサーバーが読み込み、その上にバッファを宣伝する書き込みを希望するクライアント。小さな書き込みを行う場合しかし、タグなしメッセージ内のデータではなく、RDMA読み取り、その応答と追加のラウンドトリップを招くを含むことが好ましいであろう。
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.
一般的に、タグなしのメッセージの最適な使用を同期させるために、自然の同期と同じメッセージに関連付けされたデータを提供することです。初期データ転送の場合、これは不定の期間のために特定のタグ付きバッファを宣伝する必要性を回避する付加的な利点を持っています。代わりに、匿名のバッファは初期データ受信のために使用することができます。匿名のバッファが事前に特定のメッセージに縛られる必要はありませんので、これは大きなメリットです。
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と大きく異なります。
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機構が存在することを前提。推定されるメカニズムは、データシンクULPは、データソースは、タグなしのメッセージの特定の番号を送信することができ、データソースへのクレジットを発行したことです。
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ピアは、送信者が特定のターゲット・バッファに送ることができる最大サイズを認識していることを確認する必要があります。そうすることの一つの方法は、特定の接続内のすべてのタグなしバッファのための標準的なサイズを使用することです。例えば、ULPは、セッション確立後すぐに使用される最初のタグなしバッファサイズを指定し、必要に応じて交渉の変更のための機構を指定することができます。
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から直接アドバタイズULPリソースです。 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.
いずれかのタグ付きまたはタグなしバッファは、システムバッファリソースのバイパスを可能にします。タグ付きバッファの使用は、さらにデータソースは、クレジットを行使するためにどのような順序で選択することができます。
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によって許可された範囲で、タグ付きバッファも割り切れる資源です。データシンクは、単一の100キロバイトのバッファを広告し、それは三つの連続トランザクションにおけるそのバッファ、50キロバイト、20キロバイト、30キロバイト書き込まれたピアからの通知を受信することができます。
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.
タグ付きバッファ資源のULP管理は、輸送およびDDP層クレジットの独立した、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.
ターゲットULPバッファの数が十分に大きく、かつ任意の書き込みが到着する速度は、メモリ内のすべてのターゲットULPバッファを固定することは望ましくないであろうことは、十分に低い場合に一例があろう。最大転送速度、ひいては必要なシステムバッファの最大量は、総ULPバッファー露光よりも安定かつ予測可能であってもよいです。
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.
データシンクが予測可能な速度でデータのストリームを受信したいが、各データパケットのサイズがどうなるか事前に把握していないときもう一つの例は以下のようになります。これは、可変ビットレートでエンコードされたストリーミングメディアをより一般的です。 DDPでは、データシンクは、最大パケットのために十分な大きさのタグなしバッファを使用し、または円形のバッファを宣伝しなければならないのいずれか。セキュリティやその他の理由のために、データシンクは、基礎となるSCTPトランスポートを使用して、そのバッファのサイズが公に知られるようにしたくなかった、場合は、直接、そのバイト指向クレジットのが好ましいかもしれません。
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はRDMAPが提供する更なるサービスです読み込みます。 RDMAは、データシンクが正確にULP Bufferを「ジャストインタイム」ベースで必要なピアの一部を取得することを可能に読み込みます。これは、データソースULPから毎のフェッチのサポートを必要とせずに行うことができます。
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.
いずれの場合も、はるかにそれは永続的なストレージメディアに書き込まれるときの、事前にデータソースからデータを転送するにはほとんど利点があります。 RDMAは、ストレージサーバーは、「ジャストインタイム」ベースでペイロードをフェッチすることを可能に読み込みます。このように、ブロック・サイズのバッファの数が比較的少ないが、多くのクライアントとの大きなファイル、またはストレージサーバーを書い指定単一のトランザクションを実行するために使用することができますに最も便利であるために、個々のクライアントからのバッファを取得することができますサーバー。
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.
アドバタイズバッファの所望の部分が事前に知られていない場合、この同じ機能を使用することができます。たとえば、アドバタイズバッファは、パフォーマンス統計情報を含めることができます。データシンクは、データソース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 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.
これは（すなわち、許可されたユーザは、データのセット全体への読み取りアクセス権を持っている）をチェックするトランザクションの妥当性を必要としない半揮発性データを公開し、多くのアプリケーションに適用可能です。データに行われなければならないULPの整合性チェックがあるときにはあまり適用されます。このようなアプリケーションは、より良いクライアントが要求を送信した、とRDMAが要求されたデータを公開するために書き込みますサーバーの使用を持っていることによって提供されるだろう。どちらRDMAPもDDPは、アトミック動作に複数の互いに素な更新をバンドルするためのメカニズムを提供します。したがって、データ・リソースとして広告緩衝液の使用は、独自の一貫性を強制しないよう、フラットファイルなど、任意のランダムに更新されたデータリソースと同一の注意事項、にさらされます。
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セグメントは、単一のSCTPパケット内に配信されます。同等のサービスは、MPA（マーカPDUアライメント）アダプテーション層の使用を介してTCPでのみ利用可能です。
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.
補完は、ストリーム単位でDDPソースシーケンス番号（SSN-DDP）によって制御されています。したがって、単一のSCTPアソシエーションに複数のDDPストリームを結合することは、1つのストリームが他に完了を遅延させるためのデータを搬送するドロップされたパケットを生じさせることができません。
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と順序付けされていないデータチャンクを使用すると、IPデータグラムは、順不同で受信されたときDDP層プレースメントを実行することができることを保証します。
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セグメントの配置は保証されますが、確かに許可されていません。 TCPセグメントとMPAのFPDUsのアライメントが失われたときにアウトオブオーダーDDPセグメント処理するMPA受信機の能力が損なわれる可能性があります。 SCTPを使用して、各DDPセグメントは、単一のデータチャンクにエンコードされ、複数のIPデータグラムに広がることはありません。
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ペイロードの差が重要な要因である可能性が高いではありません。
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接続など、すべてのネットワーク・ミドルボックスに表示されます。多くの環境で、既存のネットワーク要素を満たすために、および/または接続の監視および制御を容易にするためにのみ、TCP接続を使用する必要があるかもしれません。 SCTPは、TCPのように、確かに同じように監視可能で制御可能である一方、ネットワーク管理インフラストラクチャの両方のために必要なサポートを持っているという保証はありません。
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を介して配信さ1以上の処理の労力が必要になります。しかし、この余分な作業は、完全なSCTPサポートがミドルボックスは、SCTPの利便性を損なうネットワークのエンドポイント、またはで使用できない多くの配備のために正当化することができます。
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は、まず、自身の整合性チェックを適用する前にバッファを参照するすべてのスタッグスを無効にする必要があります。
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]は、両方のアダプテーション層のためのRFC 2406 [RFC2406]の使用を指定します。 [RFC5042]に記載されているように、RFC 3723 [RFC3723]でプロファイルとしてRDDPのIPsec要件は、IPsecの新しいバージョンが存在するにもかかわらず、RFC 2401 [RFC2401]および関連するRFCで指定されたIPSecのバージョンに基づいていることに注意してくださいRFC 4301で指定された[RFC4301]および関連するRFC。
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が一方向/終了のために使用/アクティブである場合、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よりも良好な）接続が提供されるに未検出誤りから同等の保護限り許可されます。
SCTP provides CRC32c protection automatically. The adaptation to SCTP provides for no option to suppress SCTP CRC32c protection.
SCTPは、自動的にCRC32C保護を提供します。 SCTPへの適応は、SCTP CRC32C保護を抑制するためのオプションを提供します。
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は、ユビキタスIP上で動作するように定義されるようにSCTPとTCPと搬送されます。これは、新しいDDP対応のノードがIPネットワークにどこにでも追加することができます。ミドルボックスからの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オペレーションのフェンシングは、トランスポートレベルのACKに基づくことができます。 DDPは、きれいにIPトランスポートを介して積層されているため、明示的なRDMA層ACKは、トランスポート層のACKから分離されなければなりません。
There may be deployments where the benefits of RDMA/transport integration outweigh the benefits of being on an IP network.
RDMA /輸送統合のメリットは、IPネットワーク上にあるの利益を上回る展開があるかもしれません。
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リードレスポンスです。 DDPとRDMAPはほぼ完全フロー制御およびペーシングのための他の層に依存しています。 LLPは、配信を保証し、ネットワークの混雑を避けるために依存して、ULPレベルの肯定応答（ACK）は、ULPペーシングのために頼っているとULPバッファオーバーランを避けるために。
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.
InfiniBandなど前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.
その前にタグ付きのメッセージは、タグ付きメッセージを送信する前に配置されている保証するための「フェンス」送信メッセージにローカルインタフェースのための機能はありません。他の側から利用可能な唯一の保証は、（RDMAP層から来る）RDMA読み取り応答やULP層からの応答をだろう。データシンクULPは、タグなしのメッセージが通知されますとき、通常の発注ルールのみを保証することを忘れないでください。データが受信バッファに置かれたとき、それは制御しません。
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.
再使用タグ付きバッファの細心の注意を払って行う必要があります。タグなしのメッセージはすべて事前タグ付きのメッセージは、遅くともタグ付きませんメッセージが持っていることを保証するものではありません配置されていることを示しているという事実。最善の戦略は、タグなしメッセージと任意のアドバタイズバッファの状態のみを変更することです。
As covered elsewhere in this document, flow control of Untagged Messages is the responsibility of the ULP.
このドキュメントの他の場所でカバーされたよう、タグなしのメッセージのフロー制御は、ULPの責任です。
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セグメントがこれまで実際に到着したかどうかに依存しません。
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トランスポートを介して展開されるようにした場合、代替補完処理プロトコルが必要とされるであろう。
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クレジットとしてタグ付けバッファに前のセクションで述べたように、RDMAPもDDPいずれもタグ付きメッセージの任意のフロー制御を提供します。いかなる輸送層流制御が提供されない場合、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の無知であることを、アプリケーションを奨励しています。単一タグなしメッセージで終わるすべてのメッセージが完了したとき、ULPにのみ通知されます。 ULPは、根底にあるメッセージの細かさや秩序を認識しません。このアプローチはULPは、メッセージの完全なセットにのみ興味あり、それらのサブセットのための使用を持っていないことを前提としています。
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アプリケーション用、SCTPストリームの対によってTCPコネクションが提供するトランスポート・サービスの両方に同じサービス（2つの接続されたRDMAP / DDPのエンドポイント間のDDPセグメントの信頼できる配信）を提供します。
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.
具体的には、SCTPマッピング部3、及びMPA / TCPマッピングのセクション13.3で説明したDDPストリームセッション確立のための手順は、DDPの交換を可能にする前に、ULP特有のデータ（「プライベートデータ」）の交換を可能両方セグメント。この遅延は、交換されたデータに基づいて、エンドポイントの適切な選択及び/又は構成を可能にすることができます。例えば、単一のクライアントセッションに関連付けられた各DDPストリームセッションは、同じDDP保護ドメインに割り当てることがあります。
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エンドポイントを設定する方法を決定するために、セッション確立メッセージの一部としてプライベートデータを交換する必要があります。片側はイニシエータ、および他、レスポンダでなければなりません。
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ストリームの対は、SCTPアソシエーションが開いたまま連続セッションのために使用することができます。 MPA / TCPを使用すると、各接続は、ほとんど、1つのセッションで、使用することができます。しかしながら、ポートの同じソース/宛先ペアは、TCPによって許可されるように、後続のTCP接続のために再使用することができます。
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セグメントを送信するためにMPAモードへの変換を開始したTCPコネクションの終了を要求します。 SCTPはこの要件はありません。輸送ニュートラルにしたいのULPは、最初のメッセージを送信するために開始終了を要求すべきです。 ULPロジック自体が自然にこの制限をサポートしない場合、長さゼロの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.
SCTPでは、関連試験の確立RDMAがサポートされているかどうか。サポートされていない場合、アプリケーションは単に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.
TCPで確立された接続自体は、RDMAがサポートされているかどうかを決定するために使用される一つの重要な違いは、SCTPとRDMAをサポートすることができるピアがトランスポート層アソシエーション/接続する前に形成されているか否かの決意が確立されることです。
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機能をフル活用は、明示的にこれらのサービスを要求したローカルインタフェースが必要です。そのようなソケット直接プロトコル（SDP）などのプロトコルは、アプリケーションが彼らの伝統的なバイトストリームまたはメッセージストリームインタフェースを維持し、まだ最適化されたワイヤレベルのプロトコルの多くの利点を享受できるようにすることができます。
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セキュリティの考慮事項は、RDMAセキュリティ文書[RFC5042]で議論されています。この文書では、唯一のより多くの利用状況志向の側面に対処し、どこ基礎となるトランスポートの選択に影響があります。
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の使用は、フィルタ検証する任意のセキュリティ対策の使用を損ない、および/または会合/接続のリモート側のログを記録しません。
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メモリを公開します。これらは、受信操作の投稿を含めるとステアリングタグの有効化。
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はのULPは、バッファを宣伝する方法についての要件を課します。 ULPは、複数のバッファ広告のための単一のステアリングタグを使用することができます。しかし、ULPはクワガタの使用上の執行は可能性が有効になっている全体的な範囲に限定されていることを認識する必要があります。リモートピアが「間違っている」アドバタイズバッファに書き込む場合は、DDPもRDMAP層のいずれもがこのことを認識されます。 NORリモートピアは、特にタグ付きバッファの使用方法についてのULPへの報告があります。
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を使用して、各使用後にそれを無効にする、またはのSTagを無効にするRDMAPオプションを使用するピアを必要とするように助言されるかもしれませんその応答タグなしメッセージと。
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.
DDPはきれいLLP上に積層されている間LLPストリームは、このようなトランスポート層セキュリティ（TLS）[RFC4346]として、ストリーミングCYPHERで固定されたとき、その最大の利益を制限してもよいです。 LLPが順番に復号化する必要がある場合、それは、配置の目的のためにDDP層へのアウト・オブ・オーダーDDPセグメントを提供することはできません。 IPsecの[RFC2401]トンネルモードは、全IPデータグラムを暗号化します。 IPsecトランスポートモードは、TCPまたはSCTPの下にUDPデータグラムを超えるTLS（DTLS）[RFC4347]の使用がそうであるように、TCPセグメントまたはSCTPパケットを暗号化します。 IPsecのもDTLSのこの使用はいずれも、配置のためのDDP層にアウトオブオーダーDDPセグメントを提供することを妨げます。
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生成の抑制が可能となり、特定の状況下でチェックすることがあります。これは、LLPが持っていると判断「または同等の」エンドツーエンドCRC32Cに保護することができる一例です。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、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.ガルシア、 "リモートダイレクトメモリアクセスプロトコル仕様"、RFC 5040、2007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[RFC5042] Pinkerton, J. and E. Deleganes, "DDP/RDMAP Security", RFC 5042, October 2007.
[RFC5042]ピンカートン、J.およびE. Deleganes、 "DDP / RDMAPセキュリティ"、RFC 5042、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）適応"、RFC 5043、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.キャリア、 "TCP仕様のためのマーカーPDUアラインフレーミング"、RFC 5044、2007年10月。
[NFSDIRECT] Talpey, T., Callaghan, B., and I. Property, "NFS Direct Data Placement", Work in Progress, June 2007.
[NFSDIRECT] Talpey、T.、キャラハン、B.、およびI.プロパティ、 "NFS直接データ配置"、進歩、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上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、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.ターラー、RFC 5046 "リモートダイレクトメモリアクセス（RDMA）のためのインターネット小型コンピュータシステムインタフェース（iSCSIの）拡張機能" 2007年10月。
Authors' Addresses
著者のアドレス
Caitlin Bestler (editor) Neterion 20230 Stevens Creek Blvd. Suite C Cupertino, CA 95014 USA
ケイトリンベストの（エディタ）Neterio 20230スティーブンスクリークブルバードスイートCクパチーノ、CA 95014 USA
Phone: 408-366-4639 EMail: caitlin.bestler@neterion.com
電話：408-366-4639 Eメール：caitlin.bestler@neterion.com
Lode Coene Nokia Siemens Networks Atealaan 26 Herentals 2200 Belgium
鉱脈CoeneノキアシーメンスネットワークスAtealaan 26 2200 Herentalsのベルギー
Phone: +32-14-252081 EMail: lode.coene@nsn.com
電話：+ 32-14-252081 Eメール：lode.coene@nsn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。