[要約] RFC 5045は、RDMAとDDPのプロトコルの適用可能性について説明しており、高速データ転送を目的としています。
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)
リモートダイレクトメモリアクセスプロトコル（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.
このドキュメントでは、リモートダイレクトメモリアクセスプロトコル（RDMAP）と直接データ配置プロトコル（DDP）の適用性について説明します。DDPが使用できるIP上のさまざまなトランスポートオプションを比較および対照し、利用可能なトランスポートを選択するためのULP開発者にガイダンスを提供します。、およびRDMA機能をサポートする非IPトランスポートとIPトランスポートを介したDDPを比較します。
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 Reads）。
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は、SCTPやTCPを含む複数の標準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.
これらのプロトコルの機能が適用できる状況を明確にすることにより、このドキュメントは、使用するプロトコルを選択する際に、実装者とアプリケーションおよびプロトコル設計者をガイドできます。
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は、データソースがデータを送信した順序（またはどのメッセージ）に無関心にすることができます。通常、タグ付きデータはペイロード転送に使用できますが、Untaggedはコントロールメッセージに最適です。ただし、各上層層プロトコルは、タグ付きメッセージとタグなしメッセージの最適な使用を決定できます。このドキュメントでは、データソースの柔軟性がアプリケーションにとって有益である場合に説明します。
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.
Infinibandなどの一部の非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の完全な機能は、それらを悪用するように設計されたアプリケーションによってのみ完全に実現できます。従来のソケットインターフェイスとの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.
最後に、DDPサポートは、少なくとも2つのIPトランスポートで定義されます：SCTP [RFC5043]とTCP [RFC5044]。両方のトランスポートをサポートするための理論的根拠がレビューされ、それぞれが適切な選択になる時期です。
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ピアにタグ付きバッファー識別子（STAG、ベースアドレス、およびバッファーの長さ）を通知することにより、着信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.
ステアリングタグ（STAG） - プロトコル仕様内で定義されているように有効なノード上のタグ付きバッファーの識別子。
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.
Untaggedメッセージ - レシーバーサプライされたバッファーと一致するメッセージシーケンス番号に基づいて、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などのプロトコルに加えて、ULPはアプリケーションまたはミドルウェア層に埋め込まれている場合があります。）プロトコル。
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がなければ、事前ポストバッファーには、必要なバッファとそのサイズを正確に予測するために受信側が必要です。これは、すべてのULPSにとって実行不可能です。対照的に、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またはTCP（RDMAなし）に適切に設計されたローカルインターフェイスを使用してそうすることができるかもしれません。これは、アプリケーションがメッセージのシーケンスと各メッセージの最大サイズを正確なサイズではなく予測するだけではないため、ネイティブ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の場合、これにより、必要な相互作用の数がさらに根本的に減少します。
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は、交換全体が配置されているという通知を受信するまで、交換の一部の処理を開始できません。ここでの「Exchange」は、ゼロ以上のタグ付きメッセージのセットと、1つの終了していないメッセージです。受信したペイロードの作業を開始することを好むアプリケーションは、到着した順序に関係なく、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.
したがって、タグ付きメッセージの観点から完全に定義することはできません。最終的に、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ストライピングやミラーリングなどのテクニックは、この同じ問題を表していますが、さらに1つのステップを表しています。データシンクの単一のリソースと思われるものは、実際にはデータソースによって別々の場所に保存されます。非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).
データシンクが要求されたデータの真の順序や場所を知らない理由はたくさんあります。クライアントごとに異なる場合があり、選択された異なるレコード、および/または異なるソートオーダー、およびレイドストライピング、ファイルフラグメンテーション、ボリュームフラグメンテーション、ボリュームミラーリング、コンテンツのサーバー側の動的コンポジット（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ピアは、送信者が特定のターゲットバッファーに送信できる最大サイズを認識していることを確認する必要があります。そうする方法の1つは、特定の接続内のすべての未編成バッファーに標準サイズを使用することです。たとえば、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 KBバッファーを宣伝し、3つの連続したトランザクションで50 kb、20 kb、および30 kbを記述したというピアから通知を受け取ることができます。
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.
輸送と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バッファーの数が十分に大きく、届く到着の速度が十分に低い場合、メモリ内のすべてのターゲット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バッファーの部分を正確に取得できます。これは、データソース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読み取りにより、ストレージサーバーは「Just In Time」ベースでペイロードを取得できます。この方法で、比較的少数のブロックサイズのバッファーを使用して、大きなファイルを書くことを指定する単一のトランザクションを実行できます。サーバー。
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は、同じサービスを提供します。ただし、選択のパフォーマンスへの影響がある場合があります。ULPの責任は、どのIP輸送がそのニーズに最適かを決定することです。
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ソースシーケンス番号（DDP-SSN）によってストリームごとに制御されます。したがって、複数のDDPストリームを単一のSCTPアソシエーションに組み合わせることで、他のストリームの完了を遅らせる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 FPDUのアラインメントが失われると、秩序外の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を介して配信されたものよりも多くの処理努力が必要です。ただし、この追加作業は、ネットワークのエンドポイントで完全な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は、最初に独自の整合性チェックを適用する前に、バッファーを参照するすべてのSTAGを無効にする必要があります。
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]に記載されているように、RDDPのIPSEC要件は、RFC 3723 [RFC3723]によってプロファイルされるように、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（オン/オフ）の投与は、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は、SCTPやTCPなどのユビキタスなIP輸送を操作するように定義されています。これにより、新しい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.
RDMA機能を提供する非IPトランスポートファブリックがあります。これらの機能はトランスポートプロトコルと統合されているため、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レベルのアッキングは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.
ローカルインターフェイスが「フェンス」のアウトバウンドメッセージに表示される能力はありません。これは、タグ付きメッセージを送信する前に、以前のタグ付けされたメッセージが配置されていることを保証します。反対側から利用可能な唯一の保証は、RDMA読み取り応答（RDMAP層から来る）または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.
このドキュメントの他の場所でカバーされているように、Untaggedメッセージのフロー制御は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が必要です。信頼性の低いIPトランスポートにDDPを展開する場合、代替完了ハンドリングプロトコルが必要になります。
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は、1つの未編成メッセージで終了するすべてのメッセージが完了した場合にのみ通知されます。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で説明したDDPストリームセッションの確立の手順とMPA/TCPマッピングのセクション13.3では、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で許可されているように、ポートの同じソース/宛先ペアを再利用することができます。
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にはこの要件がありません。輸送中立になりたいULPSは、最初のメッセージを送信するために開始の終わりを必要とするはずです。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接続が確立されます。次に、ULPによって使用されて、MPAモードに変換してRDMAを使用するかどうかを判断します。これは通常、他のセッション確立交渉と不可欠です。
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を使用すると、Associationの確立は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.
重要な違いの1つは、SCTPでは、ピアが輸送層の関連/接続が確立される前にRDMAをサポートできるかどうかの決定を決定し、TCPでは、確立された接続自体が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機能を完全に利用するには、これらのサービスを明示的に要求するローカルインターフェイスが必要です。Sockets Direct Protocol（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も、ULPSがバッファーを宣伝する方法に要件を掲載していません。ULPは、複数のバッファ広告に単一のステアリングタグを使用する場合があります。ただし、ULPは、STAGの使用に関する施行が有効な全体の範囲に限定される可能性が高いことを認識する必要があります。リモートピアが「間違った」宣伝されたバッファーに書き込む場合、DDPもRDMAP層もこれを認識しません。また、リモートピアがタグ付きバッファーをどのように使用したかについて、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を受信することは、各インタラクションに明確な雄鹿を使用し、使用後にそれを無効にすること、またはそのピアにRDMAPオプションを使用してSTAGを無効にすることを要求することをお勧めします。その応答のないメッセージが付いています。
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]。LLPが順番に解読する必要がある場合、配置目的でDDPレイヤーに順序外のDDPセグメントを提供することはできません。IPSEC [RFC2401]トンネルモードは、IPデータグラム全体を暗号化します。IPSECトランスポートモードは、TCPまたはSCTP上のUDPを介したデータグラムTLS（DTLS）[RFC4347]の使用と同様に、TCPセグメントまたはSCTPパケットを暗号化します。IPSECもDTLの使用も、配置のために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に対して「または同等の」保護があると判断される可能性がある1つの例です。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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.、Metzler、B.、Culley、P.、Hilland、J。、およびD. Garcia、「リモートダイレクトメモリアクセスプロトコル仕様」、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] Shah、H.、Pinkerton、J.、Recio、R。、およびP. Culley、「信頼できる輸送を介した直接データ配置」、RFC 5041、2007年10月。
[RFC5042] Pinkerton, J. and E. Deleganes, "DDP/RDMAP Security", RFC 5042, October 2007.
[RFC5042] Pinkerton、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. Stewart、「ストリーム制御伝送プロトコル（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.、Bailey、S。、およびJ. Carrier、「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.、Callaghan、B。、およびI. Property、「NFS Direct Data Placement」、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.、Tseng、J.、Walker、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] Kent、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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] Ko、M.、Chadalapaka、M.、Elzur、U.、Shah、H。、およびP. Thaler、「インターネットスモールコンピューターシステムインターフェイス（ISCSI）リモートダイレクトメモリアクセス（RDMA）の拡張機能」、RFC 5046、2007年10月。
Authors' Addresses
著者のアドレス
Caitlin Bestler (editor) Neterion 20230 Stevens Creek Blvd. Suite C Cupertino, CA 95014 USA
Caitlin Bestler（編集者）Neterion 20230 Stevens Creek Blvd.Suite C Cupertino、CA 95014 USA
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
Lode Coene Nokia Siemens Networks Atealaan 26 Herentals 2200ベルギー
Phone: +32-14-252081
EMail: lode.coene@nsn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。