[要約] RFC 5043は、Stream Control Transmission Protocol（SCTP）のDirect Data Placement（DDP）Adaptationに関する規格です。このRFCの目的は、SCTPを使用してデータを直接配置するための方法を提供することです。
Network Working Group C. Bestler, Ed.
Request for Comments: 5043 Neterion
Category: Standards Track R. Stewart, Ed.
Cisco Systems, Inc.
October 2007
Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
ストリーム制御伝送プロトコル（SCTP）直接データ配置（DDP）適応
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP).
このドキュメントは、Stream Control Transmission Protocol（SCTP）を使用して、直接データ配置（DDP）の下層層プロトコル（LLP）サービスを提供する適応レイヤーを指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Adaptation Layer Indicator . . . . . . . . . . . . . . . . 5
5.2. Payload Data Chunks . . . . . . . . . . . . . . . . . . . 6
5.2.1. DDP Source Sequence Number (DDP-SSN) . . . . . . . . . 6
5.2.2. DDP Segment Chunk . . . . . . . . . . . . . . . . . . 7
5.2.3. DDP Stream Session Control . . . . . . . . . . . . . . 7
6. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . . 8
6.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Legal Sequence: Active/Passive Session Accepted . . . . . 9
6.3. Legal Sequence: Active/Passive Session Rejected . . . . . 9
6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected . 10
6.5. ULP-Specific Sequencing . . . . . . . . . . . . . . . . . 10
6.6. Other Sequencing Rules . . . . . . . . . . . . . . . . . . 10
7. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Adaptation Layer Indication Restriction . . . . . . . . . 11
7.2. Multihoming Implications . . . . . . . . . . . . . . . . . 11
8. Number of Streams . . . . . . . . . . . . . . . . . . . . . . 12
9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 13
11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Association Initialization . . . . . . . . . . . . . . . . 13
11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 14
11.3. Association Termination . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . . 16
This document describes a method to adapt Direct Data Placement [RFC5041] to Stream Control Transmission Protocol (SCTP) [RFC4960].
このドキュメントは、直接データ配置[RFC5041]をストリーミング制御伝送プロトコル（SCTP）[RFC4960]に適応させる方法について説明しています。
Some implementations may include this adaptation layer within their SCTP implementations to obtain maximum performance, but the behavior of SCTP will be unaffected. An SCTP layer used solely by this adaptation layer is able to take certain optimizations based on the limited subset of SCTP capabilities used. In order to allow optimization for these implementations, we specify the use of the new adaptation layer indication as defined in [RFC5061]
いくつかの実装には、最大パフォーマンスを得るためにSCTP実装内にこの適応層が含まれる場合がありますが、SCTPの動作は影響を受けません。この適応層のみが使用するSCTP層は、使用されるSCTP機能の限られたサブセットに基づいて特定の最適化を行うことができます。これらの実装の最適化を可能にするために、[RFC5061]で定義されている新しい適応層の表示の使用を指定します
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
DDP - See Direct Data Placement Protocol.
DDP-直接データ配置プロトコルを参照してください。
DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP stream pair is not assumed to have a DDP Endpoint. DDP Segments may only be sent once a DDP Endpoint has been assigned to an SCTP stream pair by a local interface.
DDPエンドポイント - DDPセグメントの論理送信者/受信機。SCTPストリームペアには、DDPエンドポイントがあるとは想定されていません。DDPセグメントは、DDPエンドポイントがローカルインターフェイスによってSCTPストリームペアに割り当てられたらのみ送信できます。
DDP Source Stream Sequence Number (DDP-SSN) - A stream-specific sequence number assigned by the adaptation layer for each SCTP Data Chunk sent. This is the order that chunks were submitted to SCTP, no matter in what order they are actually sent or received.
DDPソースストリームシーケンス番号（DDP-SSN） - 送信される各SCTPデータの適応層によって割り当てられたストリーム固有のシーケンス番号。これは、実際に送信または受け取った順序で、チャンクがSCTPに提出された順序です。
DDP Segment - The smallest unit of data transfer for the DDP protocol. It includes a DDP Header and ULP Payload (if present). A DDP Segment should be sized to fit within the Lower Layer Protocol MULPDU (Marker PDU Aligned (MPA) Upper Layer PDU).
DDPセグメント - DDPプロトコルのデータ転送の最小単位。DDPヘッダーとULPペイロード（存在する場合）が含まれます。DDPセグメントは、下層プロトコルMULPDU（マーカーPDUアライメント（MPA）上層PDU）に収まるようにサイズにする必要があります。
DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the DDP-SSN and a DDP Segment.
DDPセグメントチャンク - DDP -SSNとDDPセグメントをカプセル化するSCTPペイロードデータチャンク。
DDP Stream - A sequence of DDP Segments whose ordering is defined by the LLP. For SCTP, a DDP stream maps directly to a bidirectional pair of SCTP streams with the same Stream IDs. Note that DDP has no ordering guarantees between DDP streams.
DDPストリーム-LLPによって順序付けが定義されているDDPセグメントのシーケンス。SCTPの場合、DDPストリームは、同じストリームIDを持つSCTPストリームの双方向ペアに直接マップします。DDPには、DDPストリーム間に順序付け保証がないことに注意してください。
DDP Stream Session - A single pairing of DDP Endpoints over a DDP stream that lasts from an Initiation message through the Termination message(s).
DDPストリームセッション - 開始メッセージから終了メッセージまで続くDDPストリーム上のDDPエンドポイントの単一のペアリング。
DDP Stream Session Control Message - A message that is used to control the association of the DDP Endpoint with the DDP stream.
DDPストリームセッション制御メッセージ - DDPエンドポイントの関連性をDDPストリームと制御するために使用されるメッセージ。
Direct Data Placement Protocol (DDP) - A wire protocol that supports Direct Data Placement by associating explicit memory buffer placement information with the LLP payload units.
直接データ配置プロトコル（DDP） - 明示的なメモリバッファーの配置情報をLLPペイロードユニットに関連付けることにより、直接データ配置をサポートするワイヤプロトコル。
Lower Layer Protocol (LLP) - In the context of DDP, the protocol layer beneath RDMA that provides a reliable transport service. The SCTP DDP adaption is one of the initially defined LLPs for DDP.
下層プロトコル（LLP） - DDPのコンテキストでは、信頼できる輸送サービスを提供するRDMAの下のプロトコル層。SCTP DDP適応は、DDPの最初に定義されたLLPの1つです。
Protection Domain - A common local interface convention to control which Steering Tags (STags) are valid with which DDP Endpoints. Under this convention, both the Steering Tag and DDP Endpoint are created within the context of a Protection Domain, and the Steering Tag may only be enabled for DDP Endpoints created under the same Protection Domain.
保護ドメイン - どのDDPエンドポイントでどのステアリングタグ（STAG）が有効であるかを制御するための一般的なローカルインターフェイス条約。この規則では、ステアリングタグとDDPエンドポイントの両方が保護ドメインのコンテキスト内で作成され、ステアリングタグは同じ保護ドメインで作成されたDDPエンドポイントでのみ有効にできます。
RDMA - Remote Direct Memory Access.
RDMA-リモートダイレクトメモリアクセス。
RNIC - RDMA Network Interface Card.
RNIC -RDMAネットワークインターフェイスカード。
SCTP association - A protocol relationship between two SCTP endpoints. An SCTP association supports multiple SCTP streams.
SCTP Association- 2つのSCTPエンドポイント間のプロトコル関係。SCTPアソシエーションは、複数のSCTPストリームをサポートします。
SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There can be multiple Chunks within each SCTP packet. Other Chunks are used to control the SCTP Association.
SCTPデータチャンク - ペイロードデータの伝達に使用されるSCTPチャンク。各SCTPパケット内に複数のチャンクがあります。他のチャンクは、SCTP協会の制御に使用されます。
SCTP endpoint - The logical sender/receiver of SCTP packets. On a multihomed host, an SCTP endpoint is represented to its peers as a combination of an SCTP port number and a set of eligible destination transport addresses to which SCTP packets can be sent.
SCTPエンドポイント-SCTPパケットの論理送信者/受信機。マルチホームホストでは、SCTPポート番号とSCTPパケットを送信できる適格な宛先輸送住所の組み合わせとして、SCTPエンドポイントが同業他社に表されます。
SCTP Stream - A unidirectional logical channel established from one to another associated SCTP endpoint. There can be multiple SCTP streams within each SCTP association. An SCTP stream is used to form one direction of a DDP stream.
SCTPストリーム-1つから別の関連するSCTPエンドポイントに確立された一方向の論理チャネル。各SCTPアソシエーション内に複数のSCTPストリームがあります。SCTPストリームは、DDPストリームの1つの方向を形成するために使用されます。
Transmission Sequence Number (TSN) - A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.
送信シーケンス番号（TSN） - SCTPが内部で使用する32ビットシーケンス番号。1つのTSNが各チャンクを含むユーザーデータに接続されており、受信SCTPエンドポイントが領収書を認め、重複配信を検出できるようにします。
Upper Layer Protocol (ULP) - In the context of RDMA protocol specifications, this is the layer using RDMA services. Typically, this is an application or middleware. A primary goal of RDMA protocols is to enable direct transfer of payload to/from ULP Buffers.
上層層プロトコル（ULP） - RDMAプロトコル仕様のコンテキストでは、これはRDMAサービスを使用したレイヤーです。通常、これはアプリケーションまたはミドルウェアです。RDMAプロトコルの主な目標は、ULPバッファーとの間のペイロードの直接転送を有効にすることです。
This document specifies an adaptation layer which fulfills the requirements of a Lower Layer Protocol (LLP) for DDP using a specific subset of SCTP capabilities.
このドキュメントは、SCTP機能の特定のサブセットを使用して、DDPの下層プロトコル（LLP）の要件を満たす適応層を指定します。
The defined protocol is intended to be implementable over existing SCTP stacks, while clearly defining what portions of SCTP are required to enable an implementation to be optimized specifically to support DDP.
定義されたプロトコルは、既存のSCTPスタックで実装可能であることを目的としていますが、DDPをサポートするために実装を最適化できるようにするために必要なSCTPの部分を明確に定義します。
The adaptation layer uses a pair of like-numbered SCTP streams within an SCTP Association to provide a reliable DDP stream between two DDP Endpoints. Except as specifically noted, each DDP Segment submitted by the DDP layer is encoded as a single unordered SCTP Data Chunk. In addition to the DDP Segment, the Data Chunk also contains a sequence number (DDP-SSN) that reflects the order in which DDP submitted the segments for that stream.
適応層は、SCTPアソシエーション内の同様の数のSCTPストリームのペアを使用して、2つのDDPエンドポイント間の信頼性の高いDDPストリームを提供します。特に指摘されている場合を除き、DDPレイヤーによって提出された各DDPセグメントは、単一の順序付けられていないSCTPデータチャンクとしてエンコードされます。DDPセグメントに加えて、データチャンクには、DDPがそのストリームのセグメントを提出した順序を反映するシーケンス番号（DDP-SSN）も含まれています。
A DDP Stream Session is defined by DDP Stream Session Control Chunks that manage the state of the DDP Stream Session. These Chunks dynamically bind DDP Endpoints to the DDP Stream Session, and DDP Segment Chunks are used to reliably deliver DDP Segments with the session.
DDPストリームセッションは、DDPストリームセッションの状態を管理するDDPストリームセッションコントロールチャンクによって定義されます。これらのチャンクは、DDPエンドポイントをDDPストリームセッションに動的に結合し、DDPセグメントチャンクを使用して、セッションでDDPセグメントを確実に提供します。
The DDP/SCTP adaptation layer uses all streams within an SCTP association. An SCTP Association that has had the DDP Adaptation Indication negotiated will carry only SCTP Data Chunks as defined in this document.
DDP/SCTP適応層は、SCTPアソシエーション内のすべてのストリームを使用します。このドキュメントで定義されているように、DDP適応指示がネゴシエートされたSCTP協会は、SCTPデータチャンクのみを運びます。
It is presumed that the handling of incoming data chunks for DDP-enabled associations is sufficiently different than for routine SCTP associations that it is undesirable to require support for mixing DDP and non-DDP streams in a single association. More than a single association is required if an application desires to utilize both DDP and non-DDP traffic with the same remote host.
DDP対応の関連付けのための着信データチャンクの取り扱いは、単一の関連付けでDDPと非DDPストリームの混合をサポートすることを必要とすることが望ましくないことが望ましくない、日常的なSCTP関連とは十分に異なると推定されます。アプリケーションが同じリモートホストでDDPトラフィックと非DDPトラフィックの両方を利用したい場合、単一の関連付けが必要です。
We define an Adaptation Indication that MUST appear in the INIT or INIT-ACK with the following format as defined in [RFC5061].
[RFC5061]で定義されているように、次の形式でinitまたはinit-ackに表示されなければならない適応指標を定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC006 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Indication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adaptation Indication:
適応兆候：
The following value has been assigned for DDP.
次の値はDDPに割り当てられています。
DDP - 0x00000001
DDP -0x00000001
The DDP SCTP adaptation uses two types of SCTP Payload Data Chunks, differentiated by the Payload Protocol Identifier:
DDP SCTP適応は、ペイロードプロトコル識別子によって区別される2種類のSCTPペイロードデータチャンクを使用します。
DDP Segment Chunks are used to reliably deliver DDP Segments sent between DDP Endpoints.
DDPセグメントチャンクは、DDPエンドポイント間で送信されるDDPセグメントを確実に提供するために使用されます。
DDP Stream Session Control Messages are used to establish and tear down DDP Stream Sessions, specifically by controlling the binding of DDP Endpoints with SCTP streams.
DDPストリームセッション制御メッセージは、特にSCTPストリームを使用したDDPエンドポイントのバインディングを制御することにより、DDPストリームセッションを確立および取り壊すために使用されます。
Payload Protocol Identifier:
ペイロードプロトコル識別子：
The following value are defined for DDP in this document and have been assigned by IANA:
次の値は、このドキュメントのDDPに対して定義されており、IANAによって割り当てられています。
DDP Segment Chunk - 16 DDP Stream Session Control - 17
DDPセグメントチャンク-16 DDPストリームセッションコントロール-17
All SCTP Payload Data Chunks used by this adaptation layer include a DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the sequence in which the messages were submitted to the SCTP layer for the SCTP stream in use. The DDP-SSN MUST have the same value that the SCTP Stream Sequence Number (SSN) would have been assigned had ordered SCTP Payload Data Chunks been used rather than unordered.
この適応層で使用されるすべてのSCTPペイロードデータチャンクには、DDPソースシーケンス番号（DDP-SSN）が含まれます。DDP-SSNは、使用中のSCTPストリームのSCTPレイヤーにメッセージが送信されるシーケンスを追跡します。DDP-SSNは、SCTPストリームシーケンス番号（SSN）が割り当てられていたのと同じ値を、SCTPペイロードデータチャンクが順序付けられていないのではなく使用されていることを注文する必要があります。
The rationale for specifying the DDP-SSN is as follows:
DDP-SSNを指定する理由は次のとおりです。
o The SCTP Stream Sequence Number (SSN) is not suitable for this purpose because all messages defined by this document use unordered Payload Data Chunks to ensure prompt delivery from the receiving SCTP layer.
o SCTPストリームシーケンス番号（SSN）は、このドキュメントで定義されているすべてのメッセージが順序付けられていないペイロードデータチャンクを使用して、受信SCTPレイヤーからの迅速な配信を確保するため、この目的には適していません。
o The SCTP Transmission Sequence Number (TSN) is not suitable for determining the original order of Data Chunks within a stream. The sending SCTP layer is allowed to optimize the transmission sequence of unordered Data Chunks to encourage Chunk Bundling, or for other purposes.
o SCTP伝送シーケンス番号（TSN）は、ストリーム内のデータチャンクの元の順序を決定するのに適していません。送信SCTP層は、秩序化されていないデータチャンクの伝送シーケンスを最適化して、チャンクバンドルを促進します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP-SSN | DDP Segment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DDP Segments are as defined in [RFC5041]. The DDP Segment Chunk serves the same purpose as the MPA [RFC5044] Upper Layer PDU (MULPDU) in that it carries DDP Segments over a reliable protocol with added sequencing information.
DDPセグメントは[RFC5041]で定義されています。DDPセグメントチャンクは、MPA [RFC5044]上層PDU（MULPDU）と同じ目的を果たします。これは、追加のシーケンス情報を備えた信頼性の高いプロトコル上でDDPセグメントを運ぶからです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DDP-SSN | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Data (Dependent on Function Code) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following function code values are defined for DDP in this document:
次の関数コード値は、このドキュメントのDDPに対して定義されています。
DDP Stream Session Initiate - 0x001 DDP Stream Session Accept - 0x002 DDP Stream Session Reject - 0x003 DDP Stream Session Terminate - 0x004
DDPストリームセッション開始-0x001DDPストリームセッションAccept -0x002 DDPストリームセッション拒否-0x003DDPストリームセッション終了-0x004
ULP-supplied Private Data MUST be included for DDP Stream Session Initiate, DDP Stream Session Accept, and DDP Stream Session Reject messages. However, the ULP supplied Private DATA MAY be of zero length.
DDPストリームセッションの開始、DDPストリームセッションAccept、およびDDPストリームセッションの拒否メッセージには、ULPがサプリしたプライベートデータを含める必要があります。ただし、ULPが提供するプライベートデータの長さはゼロである可能性があります。
Private Data length MUST NOT exceed 512 bytes in any message.
プライベートデータの長さは、メッセージの512バイトを超えてはなりません。
Private Data MUST NOT be included in the DDP Stream Session Terminate message.
プライベートデータをDDPストリームセッションの終了メッセージに含めてはなりません。
Received DDP Stream Session Control messages SHOULD be reported to the ULP. If reported, any supplied Private Data MUST be available for the ULP to examine.
受信したDDPストリームセッション制御メッセージは、ULPに報告する必要があります。報告された場合、ULPが検査するには、提供されたプライベートデータが利用可能でなければなりません。
The DDP/SCTP adaptation layer MAY limit the number of Session Initiate requests that it has submitted to the ULP. When a DDP Stream Session Initiate cannot be forwarded to the ULP due to such a limit, the adaptation layer MUST respond with a DDP Stream Session Terminate message.
DDP/SCTP適応層は、ULPに提出したセッションの開始要求の数を制限する場合があります。DDPストリームセッションの開始をこのような制限のためにULPに転送できない場合、DDPストリームセッションの終了メッセージで適応層は応答する必要があります。
A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP stream connects two DDP Endpoints using a matched pair of SCTP streams having the same SCTP Stream Identifiers.
DDPエンドポイントは、DDPセグメントの論理送信者/受信機です。DDPストリームは、同じSCTPストリーム識別子を持つSCTPストリームのマッチングペアを使用して、2つのDDPエンドポイントを接続します。
A DDP Stream Session defines the sequence of Data Chunks exchanged between two DDP Endpoints over a DDP stream that has a distinct beginning and end as defined in the following section. Data Chunks from one DDP Stream Session are never carried over to the next session. Each Data Chunk unambiguously belongs to exactly one session. The DDP-SSNs assigned to the Data Chunks for a session MUST NOT have any gaps.
DDPストリームセッションでは、次のセクションで定義されているように明確な開始と終了があるDDPストリーム上で2つのDDPエンドポイント間で交換されるデータチャンクのシーケンスを定義します。1つのDDPストリームセッションからのデータチャンクは、次のセッションに引き継がれることはありません。各データチャンクは、明確に1つのセッションに属します。セッションのためにデータチャンクに割り当てられたDDP-SSNSには、ギャップがない必要があります。
The local interface MAY dynamically associate a DDP Endpoint with the DDP stream based upon the initial exchanges of a DDP Session, and dynamically terminate that association at the session's end. Alternately, a specialized local interface could simply statically map DDP Endpoints to DDP streams.
ローカルインターフェイスは、DDPセッションの初期交換に基づいてDDPエンドポイントをDDPストリームに動的に関連付け、セッションの終わりにその関連を動的に終了させます。あるいは、特殊なローカルインターフェイスは、DDPエンドポイントをDDPストリームに静的にマッピングすることができます。
Conventionally, local interfaces for RDMA have deferred the selection of the DDP Endpoint until after the ULP decides to accept an RDMA connection request. But that is a local interface choice and not a wire protocol requirement.
従来、RDMAのローカルインターフェイスは、ULPがRDMA接続要求を受け入れることを決定するまで、DDPエンドポイントの選択を延期しました。しかし、それはローカルインターフェイスの選択であり、ワイヤープロトコル要件ではありません。
A DDP stream is associated with at most one Protection Domain during a single DDP Stream Session. On the passive side, the association is typically deferred until the DDP Stream Session Accept message.
DDPストリームは、単一のDDPストリームセッション中に最大1つの保護ドメインに関連付けられています。パッシブ側では、DDPストリームセッションがメッセージを受け入れるまで、協会は通常、延期されます。
The DDP-SSN is reset to zero at the beginning of each DDP Stream Session.
DDP-SSNは、各DDPストリームセッションの開始時にゼロにリセットされます。
The normative sequence for considering Payload Data Chunks within a given session is based upon each Data Chunk's DDP-SSN. When considered in this normative sequence, all sessions MUST conform to one of the patterns defined in this section.
特定のセッション内のペイロードデータチャンクを検討するための規範的なシーケンスは、各データChunkのDDP-SSNに基づいています。この規範的なシーケンスで考慮される場合、すべてのセッションは、このセクションで定義されているパターンの1つに準拠する必要があります。
If the adaptation layer receives a Payload Data Chunk that conforms to none of the enumerated legal patterns, the DDP Stream Session MUST be terminated.
適応層が列挙された法的パターンのいずれにも適合しないペイロードデータチャンクを受信した場合、DDPストリームセッションを終了する必要があります。
In this DDP Stream Session sequence, one DDP Endpoint assumes the active role in requesting a DDP Stream Session, which the other side accepts.
このDDPストリームセッションシーケンスでは、1つのDDPエンドポイントが、反対側が受け入れるDDPストリームセッションを要求する際のアクティブな役割を想定しています。
Active side sends a DDP Stream Session Initiate message.
Active Sideは、DDPストリームセッションの開始メッセージを送信します。
Passive side sends a DDP Stream Session Accept message.
パッシブサイドは、DDPストリームセッションを受け入れるメッセージを送信します。
Each side may then send zero or more DDP Segments with increasing DDP-SSNs, subject to any flow control imposed by other protocol layers.
その後、他のプロトコル層によって課されるフロー制御を条件として、各側がDDP-SSNSの増加に伴うゼロ以上のDDPセグメントを送信する場合があります。
The final User Data Chunk for each side MAY be a DDP Stream Terminate. At least one side MUST send a DDP Stream Terminate. Note that this would follow any RDMAP Terminate message, which to the adaptation layer is simply another DDP Segment.
各側の最終的なユーザーデータチャンクは、DDPストリームが終了する場合があります。少なくとも片側はDDPストリームを終了する必要があります。これは、任意のRDMAP終了メッセージに従うことに注意してください。
DDP Stream Sessions allow each party to send a single non-payload message before the other end commits specific resources to the session. This allows each end to determine which resources are to be used, and how they are to be configured, or even if the session should be granted.
DDPストリームセッションにより、各当事者は、反対側がセッションに特定のリソースをコミットする前に、単一の非支払いメッセージを送信することができます。これにより、各端は、使用するリソースを使用するリソースと、それらがどのように構成されるか、またはセッションを許可する必要がある場合でも、決定することができます。
These decisions MAY be influenced by the need to assign a specific Protection Domain, to determine how many RDMA Read Credits are required, or to determine how many receive operations the ULP should enable.
これらの決定は、特定の保護ドメインを割り当てる必要性、必要なRDMAの読み取りクレジットの数を判断する必要があること、またはULPが有効にするべき操作を受信する操作の数を決定する必要がある場合があります。
Because of these or other factors, the passive side MAY choose to reject a DDP Stream Session Request. This results in the following legal sequence:
これらまたは他の要因のため、パッシブ側はDDPストリームセッションリクエストを拒否することを選択できます。これにより、次の法的シーケンスが得られます。
Active side sends a DDP Stream Session Initiate message.
Active Sideは、DDPストリームセッションの開始メッセージを送信します。
Passive side sends a DDP Stream Session Reject message.
パッシブサイドは、DDPストリームセッションの拒否メッセージを送信します。
A DDP Stream Session Reject message MUST NOT be sent unless the rejection is at the direction of the ULP.
拒否がULPの方向にある場合を除き、DDPストリームセッションの拒否メッセージは送信されないでください。
Acceptance or rejection of DDP Stream Session Initiate messages SHOULD be under the control of the ULP. This MAY require passing an event to the ULP. There MUST be a finite limit on the number of such requests that are pending a ULP decision. When more session requests are received, the passive side MUST respond to the Initiate message with a DDP Stream Terminate Message.
DDPストリームセッションの受け入れまたは拒否は、ULPの管理下にある必要があります。これには、イベントをULPに渡す必要がある場合があります。ULPの決定が保留されているようなリクエストの数には、有限の制限がなければなりません。より多くのセッション要求が受信された場合、パッシブ側はDDPストリームがメッセージを終了することで開始メッセージに応答する必要があります。
An implementation MAY choose to support additional ULP-specific sequences, but MUST NOT do so unless requested to do so by the ULP.
実装は、追加のULP固有のシーケンスをサポートすることを選択する場合がありますが、ULPからそうするように要求されない限り、そうしないでください。
A defined ULP MUST be able to operate using only the defined mandatory session sequences. Any additional sequences must be used only for optional optimizations.
定義されたULPは、定義された必須セッションシーケンスのみを使用して動作できる必要があります。追加のシーケンスは、オプションの最適化にのみ使用する必要があります。
A DDP Stream Session Control message MUST NOT be sent if it may be received before a prior DDP Stream Session Control message within the same DDP Stream Session.
DDPストリームセッションコントロールメッセージは、同じDDPストリームセッション内の以前のDDPストリームセッションコントロールメッセージの前に受信される可能性がある場合は、送信しないでください。
An active side of a DDP Stream Session MUST NOT send a DDP Segment that might be received before the DDP Stream Session Initiate message.
DDPストリームセッションのアクティブな側面は、DDPストリームセッションがメッセージを開始する前に受信される可能性のあるDDPセグメントを送信してはなりません。
This MAY be determined by SCTP acking of the Data Chunk used to carry the DDP Stream Session Initiate message, or by receipt of a responsive DDP Stream Session Control message.
これは、DDPストリームセッションの開始メッセージを伝達するために使用されるデータチャンクのSCTPアッキング、またはレスポンシブDDPストリームセッション制御メッセージの受信によって決定される場合があります。
A DDP Stream Identifier MUST NOT be reused for another DDP Stream Session while any Data Chunk from a prior session might be outstanding.
DDPストリーム識別子は、別のDDPストリームセッションのために再利用してはなりませんが、前のセッションからのデータチャンクは未解決の可能性があります。
The local interface MUST allow the ULP to specify an SCTP endpoint to use a specific Adaptation Indication. It MAY require the ULP to do so.
ローカルインターフェイスは、ULPが特定の適応表示を使用するためにSCTPエンドポイントを指定できるようにする必要があります。それを行うにはULPが必要になる場合があります。
Once an endpoint decides on its acceptable Adaptation Indication(s), it SHOULD terminate all requests to establish an association with any different Adaptation Indication.
エンドポイントが許容可能な適応指示を決定すると、異なる適応指示との関連を確立するためにすべての要求を終了する必要があります。
An SCTP implementation MAY choose to accept association requests for a given SCTP endpoint only until one association for the endpoint has been established. At that point, it MAY choose to restrict all further associations for the same endpoint to use the same Adaptation Indication.
SCTP実装は、特定のSCTPエンドポイントの関連付け要求を受け入れることを選択できます。その時点で、同じ適応指示を使用するために、同じエンドポイントのすべてのさらなる関連付けを制限することを選択できます。
SCTP allows an SCTP endpoint to be associated with multiple IP addresses, potentially representing different interface devices. Distribution of the logic for a single DDP stream across multiple input devices can be very undesirable, resulting in complex cache coherency challenges. Therefore, the local interface MAY restrict DDP-enabled SCTP endpoints to a single IP address, or to a set of IP addresses that are all assigned to the same input device ("RNIC").
SCTPを使用すると、SCTPエンドポイントを複数のIPアドレスに関連付けることができ、異なるインターフェイスデバイスを表す可能性があります。複数の入力デバイスにわたる単一のDDPストリームのロジックの分布は非常に望ましくなく、複雑なキャッシュコヒーレンシーの課題になります。したがって、ローカルインターフェイスは、DDP対応のSCTPエンドポイントを単一のIPアドレス、またはすべて同じ入力デバイス（「RNIC」）に割り当てられた一連のIPアドレスに制限する場合があります。
The default binding of a DDP-enabled SCTP endpoint SHOULD NOT cover more than a single IP address unless doing so results in neither additional bus traffic nor duplication of memory registration resources. This will frequently result in a different default than for SCTP endpoints that are not DDP enabled.
DDP対応のSCTPエンドポイントのデフォルトのバインディングは、追加のバストラフィックもメモリ登録リソースの複製もない場合を除き、単一のIPアドレス以上をカバーする必要はありません。これにより、DDPが有効になっていないSCTPエンドポイントとは異なるデフォルトになります。
Applications MAY choose to avoid using out-of-band methods for communicating the set of IP addresses used by an SCTP endpoint when there is potential confusion as to the intended scope of the SCTP endpoint. For example, assuming the SCTP endpoint consists of all IP addresses Advertised by DNS may work for a general purpose SCTP endpoint but not a DDP-enabled one.
アプリケーションは、SCTPエンドポイントの意図された範囲に関して潜在的な混乱がある場合、SCTPエンドポイントで使用されるIPアドレスのセットを通信するために帯域外の方法を使用しないように選択する場合があります。たとえば、SCTPエンドポイントがDNSによって宣伝されているすべてのIPアドレスで構成されていると仮定すると、汎用SCTPエンドポイントで機能する可能性がありますが、DDP対応のエンドポイントではありません。
Even when multihoming is supported, ULPs are cautioned that they SHOULD NOT use ULP control of the source address in an attempt to load-balance a stream across multiple paths. A receiving DDP/SCTP implementation that chooses to support multihoming SHOULD optimize its design on the assumption that multihoming will be used for network fault tolerance, and not to load-balance between paths. This is consistent with recommended SCTP practices.
Multihomingがサポートされている場合でも、ULPは、複数のパスにわたってストリームを負荷バランスするために、ソースアドレスのULP制御を使用すべきではないことに注意しています。マルチホミングをサポートすることを選択する受信DDP/SCTP実装は、マルチホミングがパス間の負荷分散ではなく、ネットワークフォールトトレランスに使用されるという仮定で設計を最適化する必要があります。これは、推奨されるSCTPプラクティスと一致しています。
DDP streams are bidirectional. They are always composed by pairing the inbound and outbound SCTP streams with the same SCTP Stream Identifier.
DDPストリームは双方向です。それらは、インバウンドとアウトバウンドのSCTPストリームを同じSCTPストリーム識別子とペアリングすることによって常に構成されます。
The adaptation layer should request the maximum number of SCTP streams it will wish to use over the lifetime of the association. SCTP streams must still be bound to DDP Endpoints, and a DDP-enabled SCTP association does not support ordered Data Chunks. Therefore, the mere existence of an SCTP stream is unlikely to require significant supporting resources.
適応層は、協会の寿命にわたって使用したいSCTPストリームの最大数を要求する必要があります。SCTPストリームは引き続きDDPエンドポイントにバインドする必要があり、DDP対応のSCTP Associationは順序付けられたデータチャンクをサポートしていません。したがって、SCTPストリームの単なる存在は、重要なサポートリソースを必要とする可能性は低いです。
This mapping uses an SCTP association to carry one or more DDP streams. Each DDP stream will be mapped to a pair of SCTP streams with the same SCTP stream number. The adaptation MUST initialize all of its SCTP associations with the same number of inbound and outbound streams.
このマッピングでは、SCTPアソシエーションを使用して、1つ以上のDDPストリームを運びます。各DDPストリームは、同じSCTPストリーム番号を持つSCTPストリームのペアにマッピングされます。適応は、同じ数のインバウンドおよびアウトバウンドストリームとのすべてのSCTP関連を初期化する必要があります。
A DDP/SCTP Receiver already deals with fragmentation at both the IP and DDP layers. Therefore, use of SCTP layer segmenting will be avoided for most cases.
DDP/SCTPレシーバーは、すでにIPレイヤーとDDPレイヤーの両方で断片化を扱っています。したがって、ほとんどの場合、SCTPレイヤーセグメント化の使用は回避されます。
As a Lower Layer Protocol (LLP) for DDP, the SCTP adaptation layer MUST inform the DDP layer of the maximum DDP Segment size that will be supported. This should be the largest value that can be supported without use of IP or SCTP fragmentation, or 516 bytes, whichever is larger.
DDPの下層プロトコル（LLP）として、SCTP適応層は、サポートされる最大DDPセグメントサイズのDDP層に通知する必要があります。これは、IPまたはSCTPの断片化、または516バイトを使用せずにサポートできる最大の値である必要があります。
A minimum of 516 bytes is required to allow a DDP Stream Session Control Message with 512 bytes of Private Data.
512バイトのプライベートデータを持つDDPストリームセッション制御メッセージを許可するには、最低516バイトが必要です。
SCTP data chunk fragmentation MUST NOT be used unless the alternative is IP fragmentation.
SCTPデータチャンクフラグメンテーションは、代替案がIPフラグメンテーションでない限り使用してはなりません。
The SCTP adaptation layer SHOULD set the maximum DDP Segment size below the theoretical maximum in order to allow bundling of Control Chunks in the same SCTP packet.
SCTP適応層は、同じSCTPパケットにコントロールチャンクをバンドルすることを可能にするために、理論的最大値より下に最大DDPセグメントサイズを設定する必要があります。
The SCTP adaptation layer MUST reject DDP Segments that are larger than the maximum size specified.
SCTP適応層は、指定された最大サイズよりも大きいDDPセグメントを拒否する必要があります。
The adaptation layer MUST use the Unordered option on all Data Chunks (U Flag set to one). The SCTP layer is expected to deliver unordered Data Chunks without delay.
適応層は、すべてのデータチャンク（Uフラグを1に設定）で順序付けられていないオプションを使用する必要があります。SCTPレイヤーは、順序付けられていないデータチャンクを遅滞なく提供することが期待されています。
Because DDP employs unordered SCTP delivery, the receiver MUST NOT rely upon the SCTP Transmission Sequence Number (TSN) to imply ordering of DDP Segments. The fact that the SCTP Data Chunk for a DDP Segment is prior to the cumulative ack point does not guarantee that all prior DDP segments have been placed. The SCTP sender is not obligated to transmit unordered Data Chunks in the order presented.
DDPは順序付けられていないSCTP配信を採用しているため、受信機はSCTP伝送シーケンス番号（TSN）に依存してDDPセグメントの順序を暗示してはなりません。DDPセグメントのSCTPデータチャンクが累積ACKポイントの前であるという事実は、以前のすべてのDDPセグメントが配置されていることを保証するものではありません。SCTP送信者は、提示された順序で順序付けられていないデータチャンクを送信する義務はありません。
The DDP-SSN can be used without special logic to determine the submission sequence when the maximum number of in-flight messages is less than 32768. This also applies if the sending SCTP accepts no more than 32767 Data Chunks for a single stream without assigning TSNs.
DDP-SSNは、飛行中のメッセージの最大数が32768未満である場合に特別なロジックなしで使用できます。。
If SCTP does accept more than 32768 Data chunks for a single stream without assigning TSNs, the sending DDP must simply refrain from sending more than 32767 Data Chunks for a single stream without acknowledgment. Note that it MUST NOT rely upon ULP flow control for this purpose. Typical ULP flow control will deal exclusively with untagged messages, not with DDP segments.
SCTPがTSNSを割り当てずに単一のストリームの32768を超えるデータチャンクを受け入れる場合、送信DDPは、確認なしで単一のストリームに32767以上のデータチャンクを送信することを控える必要があります。この目的のためにULPフロー制御に依存してはならないことに注意してください。典型的なULPフロー制御は、DDPセグメントではなく、未積層のメッセージのみを扱います。
The receiver MAY perform a validity check on received DDP-SSNs to ensure that any gap could be accounted for by unreceived Data Chunks. Implementations SHOULD NOT allocate resources on the assumption that DDP-SSNs are valid without first performing such a validity check. An invalid DDP-SSN MAY result in termination of the DDP stream.
受信者は、受信したDDP-SSNSの有効性チェックを実行して、推定されていないデータチャンクによってギャップが考慮されるようにすることができます。実装は、DDP-SSNSが最初にそのような妥当性チェックを実行せずに有効であるという仮定でリソースを割り当てるべきではありません。無効なDDP-SSNは、DDPストリームの終了をもたらす可能性があります。
At the startup of an association, a DDP/SCTP adaptation layer MUST include an adaptation layer indication in its INIT or INIT-ACK (as defined in Section 5.1). After the exchange of the initial first two SCTP chunks (INIT and INIT-ACK), an endpoint MUST verify and inspect the Adaptation Indication and compare it to the following table to determine proper action.
協会のスタートアップでは、DDP/SCTP適応層には、そのinitまたはinit-ackに適応層の表示を含める必要があります（セクション5.1で定義されています）。最初の最初の2つのSCTPチャンク（initとinit-ack）を交換した後、エンドポイントは適応表示を検証および検査し、それを次の表に比較して適切なアクションを決定する必要があります。
Indication | Action
type |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| This indicates that the peer DOES NOT
NONE | support ANY DDP or RDMA adaptation, and thus
| RDMA and DDP procedures MUST NOT be
| performed upon this association.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| This indicates that the peer DOES support
DDP | the DDP/SCTP adaptation layer defined here.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| This indicates that the peer DOES NOT
ANY-OTHER | support the DDP adaptation, and thus
Indication | DDP procedures MUST NOT be performed
| upon this association.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
An implementation MAY require that all associations for a given SCTP endpoint be placed in the same mode.
実装では、特定のSCTPエンドポイントのすべての関連付けを同じモードに配置する必要があります。
The local interface MAY allow the ULP to accept only requests to establish an association in a specified mode.
ローカルインターフェイスにより、ULPは指定されたモードで関連性を確立するためのリクエストのみを受け入れることができます。
SCTP allows multiple Data Chunks to be bundled in a single SCTP packet. Data chunks containing DDP Segments with untagged messages SHOULD NOT be delayed to facilitate bundling. Data chunks containing DDP Segments with tagged messages will generally be full sized, and hence not subject to bundling. However, partial-size tagged messages MAY be delayed, as they are frequently followed by a short untagged message.
SCTPを使用すると、複数のデータチャンクを単一のSCTPパケットにバンドルできます。バンドリングを容易にするために、編集されていないメッセージを含むDDPセグメントを含むデータチャンクは遅らせないでください。タグ付けされたメッセージを含むDDPセグメントを含むデータチャンクは、一般的にフルサイズであるため、バンドルの影響を受けません。ただし、部分サイズのタグ付けされたメッセージは、頻繁に短い攻撃されていないメッセージが続くため、遅延する場合があります。
Termination of an SCTP Association due to errors should be handled at the SCTP layer. The RDMAP-defined RDMAP Terminate Message SHOULD NOT be sent on each DDP stream when a determination has been made to terminate an SCTP association. Sending that message on each SCTP stream could severely delay the termination of the association.
エラーによるSCTP関連の終了は、SCTP層で処理する必要があります。RDMAP定義のRDMAP終了メッセージは、SCTPアソシエーションを終了する決定が行われた場合、各DDPストリームに送信されないでください。各SCTPストリームでそのメッセージを送信すると、協会の終了を大幅に遅らせる可能性があります。
The local interface SHOULD notify all consumers of DDP streams when the underlying SCTP stream has been terminated.
ローカルインターフェイスは、基礎となるSCTPストリームが終了したときに、すべての消費者にDDPストリームを通知する必要があります。
Other RDMAP-defined Terminate Messages MUST be generated as specified when a DDP stream is terminated. Note that with the SCTP mapping, termination of a DDP Stream does not mandate termination of the Association.
DDPストリームが終了するときに指定されているように、他のRDMAP定義の終端メッセージは生成する必要があります。SCTPマッピングでは、DDPストリームの終了は協会の終了を義務付けていないことに注意してください。
This document defines a new SCTP Adaptation Layer Indication codepoint for DDP (0x00000001). [RFC5061] creates the registry from which this codepoint has been assigned.
このドキュメントでは、DDP（0x00000001）の新しいSCTP適応レイヤー表示コードポイントを定義します。[RFC5061]このコードポイントが割り当てられたレジストリを作成します。
This document also defines two new SCTP Payload Protocol Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from which these identifiers have been assigned. The following values have been assigned:
このドキュメントは、2つの新しいSCTPペイロードプロトコル識別子（PPID）も定義します。RFC 4960 [RFC4960]これらの識別子が割り当てられたレジストリを作成します。次の値が割り当てられています。
DDP Segment Chunk - 16 DDP Stream Session Control - 17
DDPセグメントチャンク-16 DDPストリームセッションコントロール-17
Any direct placement of memory could pose a significant security risk if adequate local controls are not provided. These threats are addressed in the appropriate DDP [RFC5041], RDMA [RFC5040], or Security [RFC5042] documents. This document does not add any additional security risks over those found in RFC 4960 [RFC4960].
適切なローカルコントロールが提供されない場合、メモリを直接配置すると、重大なセキュリティリスクが発生する可能性があります。これらの脅威は、適切なDDP [RFC5041]、RDMA [RFC5040]、またはセキュリティ[RFC5042]ドキュメントで対処されています。このドキュメントでは、RFC 4960 [RFC4960]に見られるものよりもセキュリティリスクが追加されません。
The IPsec requirements for Remote Direct Data Placement (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. One of the important early applications of the RDDP protocols is their use with iSCSI iSER [RFC5046]; RDDP's IPsec requirements follow those of IPsec in order to facilitate that usage by allowing a common profile of IPsec to be used with iSCSI and the RDDP protocols. In the future, RFC 3723 may be updated to the newer version of IPsec; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
リモート直接データ配置（RDDP）のIPSEC要件は、RFC 3723 [RFC3723]によってプロファイルされるように、RFC 2401 [RFC2401]および関連RFCで指定されたIPSECのバージョンに基づいています。4301 [RFC4301]および関連RFC。RDDPプロトコルの重要な初期アプリケーションの1つは、ISCSI ISER [RFC5046]での使用です。RDDPのIPSEC要件は、IPSECの共通プロファイルをISCSIおよびRDDPプロトコルで使用できるようにすることにより、その使用を容易にするためにIPSECの要件に従います。将来、RFC 3723はIPSECの新しいバージョンに更新される場合があります。このような更新のIPSECセキュリティ要件は、ISCSIおよびRDDPプロトコルに均一に適用する必要があります。
Additional requirements apply to security for RDDP over SCTP, due to the use of SCTP as the transport protocol. An implementation of IPsec for RDDP over SCTP:
輸送プロトコルとしてのSCTPを使用しているため、SCTPを介したRDDPのセキュリティに追加要件が適用されます。SCTP経由のRDDPのIPSECの実装：
1) MUST support IPsec functionality for SCTP equivalent to the IPsec functionality for TCP that is required by RFC 3723,
1) RFC 3723で必要なTCPのIPSEC機能に相当するSCTPのIPSEC機能をサポートする必要があります。
2) SHOULD support the same level of IPsec functionality for SCTP and TCP unless there is no support for TCP, and
2) TCPのサポートがない場合を除き、SCTPおよびTCPの同じレベルのIPSEC機能をサポートする必要があります。
3) MUST support at least the level of protocol and port selector functionality for SCTP that is supported for TCP.
3) TCPでサポートされているSCTPのプロトコルおよびポートセレクターの機能のレベルを少なくともサポートする必要があります。
Many thanks to our contributors who have spent many hours reading and reviewing keeping us straight: Sukanta Ganguly an independent consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and Hemal Shah of Broadcom. Thanks for all your hard work.
Sukanta Gangulyが独立したコンサルタントであるIBMのVivek Kashyap、MicrosoftのJim Pinkerton、BroadcomのHemal ShahであるSukanta Gangulyが私たちをまっすぐに維持することに何時間も費やしてきた貢献者に感謝します。すべての努力をありがとう。
The authors would like to thank the following people that have provided comments and input: Stephen Bailey, David Black, Douglas Otis, Allyn Romanow, and Jim Williams.
著者は、スティーブン・ベイリー、デビッド・ブラック、ダグラス・オーティス、アリン・ロマノウ、ジム・ウィリアムズのコメントとインプットを提供した次の人々に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RFC5042] Pinkerton、J。およびE. Deleganes、「ダイレクトデータ配置プロトコル（DDP） /リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ」、RFC 5042、2007年10月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「ストリーム制御伝送プロトコル（SCTP）動的アドレス再構成」、RFC 5061、2007年9月。
[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月。
[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月。
[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月。
[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
Randall R. Stewart (editor) Cisco Systems, Inc. Forest Drive Columbia, SC 29036 USA
Randall R. Stewart（編集者）Cisco Systems、Inc。Forest Drive Columbia、Sc 29036 USA
Phone: +1-815-342-5222
EMail: rrs@cisco.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への情報をお問い合わせください。