RFC5043 日本語訳
5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement(DDP) Adaptation. C. Bestler, Ed., R. Stewart, Ed.. October 2007. (Format: TXT=38740 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Bestler, Ed.
Request for Comments: 5043 Neterion
Category: Standards Track R. Stewart, Ed.
Cisco Systems, Inc.
October 2007
ワーキンググループC.Bestler、エドをネットワークでつないでください。コメントのために以下を要求してください。 5043年のNeterionカテゴリ: エド標準化過程R.スチュワート、シスコシステムズInc.2007年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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プロトコル(SCTP)を使用することでLower Layerプロトコル(LLP)サービスをDirect Data Placement(DDP)に供給するために適合層を指定します。
Bestler & Stewart Standards Track [Page 1] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . 3 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 動機. . . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5。 データは.55.1をフォーマットします。 適合層のインディケータ. . . . . . . . . . . . . . . . 5 5.2。 有効搭載量データ塊. . . . . . . . . . . . . . . . . . . 6 5.2.1。 DDPソース一連番号(DDP-SSN).65.2.2。 DDPセグメント塊. . . . . . . . . . . . . . . . . . 7 5.2.3。 DDP流れのセッション制御. . . . . . . . . . . . . . 7 6。 DDP流れのセッション. . . . . . . . . . . . . . . . . . . . . 8 6.1。 配列. . . . . . . . . . . . . . . . . . . . . . . . 9 6.2。 法的な系列: アクティブであるか受け身のセッションは.96.3を受け入れました。 法的な系列: アクティブであるか受け身のセッションは.96.4を拒絶しました。 法的な系列: アクティブであるか受け身のセッション非ULPは.106.5を拒絶しました。 ULP特有の配列. . . . . . . . . . . . . . . . . 10 6.6。 他の配列は.107を統治します。 SCTP終点. . . . . . . . . . . . . . . . . . . . . . . . 11 7.1。 適合層の指示制限. . . . . . . . . 11 7.2。 マルチホーミング含意. . . . . . . . . . . . . . . . . 11 8。 流れ. . . . . . . . . . . . . . . . . . . . . . 12 9の数。 断片化. . . . . . . . . . . . . . . . . . . . . . . . 12 10。 順不同の操作. . . . . . . . . . . . . . . . 13 11を配列しました。 手順. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1。 協会初期設定. . . . . . . . . . . . . . . . 13 11.2。 塊バンドリング. . . . . . . . . . . . . . . . . . . . . . 14 11.3。 協会終了. . . . . . . . . . . . . . . . . 14 12。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 14。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 16 15。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 16。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 16 16.1。 引用規格. . . . . . . . . . . . . . . . . . . 16 16.2。 有益な参照. . . . . . . . . . . . . . . . . . 16
Bestler & Stewart Standards Track [Page 2] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[2ページ]。
1. Introduction
1. 序論
This document describes a method to adapt Direct Data Placement [RFC5041] to Stream Control Transmission Protocol (SCTP) [RFC4960].
このドキュメントはStream Control Transmissionプロトコル(SCTP)[RFC4960]にDirect Data Placement[RFC5041]を適合させる方法を説明します。
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]
1.1. Conventions
1.1. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Definitions
2. 定義
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 Endpoint--DDP Segmentsの論理的な送付者/受信機。 SCTP流れの組がDDP Endpointを持っていると思われません。 局所界面でいったんSCTP流れの組にDDP Endpointを配属すると、DDP Segmentsを送るだけであるかもしれません。
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 Source Stream Sequence Number(DDP-SSN)--各SCTP Data Chunkのために適合層によって割り当てられた流れの特有の一連番号は発信しました。 これによる塊がそうであったオーダーを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 Segment--DDPのためのデータ転送の最小単位は議定書を作ります。 それはDDP HeaderとULP有効搭載量を含んでいます(存在しているなら)。 DDP Segmentは、Lower LayerプロトコルMULPDU(マーカーPDU Aligned(MPA)の上側のLayer PDU)の中で合うように大きさで分けられるべきです。
DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the
DDP-SSN and a DDP Segment.
DDP Segment Chunk--DDP-SSNとDDP Segmentを要約するSCTP有効搭載量Data Chunk。
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 Stream--注文がLLPによって定義されるDDP Segmentsの系列。 SCTPに関しては、DDPの流れは同じStream IDとの流れを直接SCTPの双方向の組に写像します。 DDPがDDPの流れの間に注文していない保証を持っていることに注意してください。
Bestler & Stewart Standards Track [Page 3] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[3ページ]。
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 Stream Session--InitiationメッセージからTerminationメッセージまで続くDDPの流れでのDDP Endpointsのただ一つの組み合わせ。
DDP Stream Session Control Message - A message that is used to
control the association of the DDP Endpoint with the DDP stream.
DDP Stream Session Control Message--DDPの流れからDDP Endpointの協会を制御するのに使用されるメッセージ。
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.
Data Placementプロトコル(DDP)を指示してください--顕在記憶バッファプレースメント情報をLLPペイロード単位に関連づけることによってDirect Data Placementを支持するワイヤプロトコル。
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.
DDP(信頼できる輸送サービスを提供するRDMAの下のプロトコル層)の文脈のLayerプロトコル(LLP)を下ろしてください。 SCTP DDP適応はDDPのための初めは定義されたLLPsの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.
保護Domain--どのSteering Tags(STags)がどのDDP Endpointsによって有効であるかを制御する一般的な局所界面コンベンション。 このコンベンションの下では、Steering TagとDDP Endpointの両方がProtection Domainの文脈の中で作成されます、そして、Steering Tagは同じProtection Domainの下で作成されたDDP Endpointsのために有効にされるだけであるかもしれません。
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協会--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 Data Chunk--SCTP Chunkは以前はよく有効搭載量Dataを運んでいました。 それぞれのSCTPパケットの中に複数のChunksがあることができます。 他のChunksは、SCTP Associationを制御するのに使用されます。
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パケットを送ることができる1セットの適任の送付先輸送アドレスとして同輩に表されます。
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 Stream--1〜別のものまで確立された単方向の論理チャネルはSCTP終点を関連づけました。 それぞれのSCTP協会の中に複数のSCTPの流れがあることができます。 SCTPの流れは、DDPの流れの一方向を形成するのに使用されます。
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.
トランスミッションSequence Number(TSN)--32ビットの一連番号はSCTPで内用しました。 1TSNが領収書を受け取ったことを知らせて、写し配送を検出することを受信SCTP終点を許可する利用者データを含む各塊に取り付けられます。
Bestler & Stewart Standards Track [Page 4] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[4ページ]。
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.
上側のLayerプロトコル(ULP)--RDMAプロトコル仕様の文脈では、これはRDMAサービスを利用する層です。 これは、通常、アプリケーションかミドルウェアです。 RDMAプロトコルの第一の目標はペイロードの直接移転をULP Buffersからの/に可能にすることです。
3. Motivation
3. 動機
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能力の特定の部分集合を使用することでLower Layerプロトコル(LLP)の要件を実現させる適合層をDDPに指定します。
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スタックの上で実行可能であることを意図します。
4. Overview
4. 概観
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.
適合層は、2DDP Endpointsの間に信頼できるDDPの流れを供給するのにSCTP Associationの中で1組の同様に番号付のSCTPの流れを使用します。 明確に注意されるのを除いて、DDP層によって提出されたそれぞれのDDP Segmentは独身の順不同のSCTP Data Chunkとしてコード化されます。 また、DDP Segmentに加えて、Data Chunkは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 Stream SessionはDDP Stream Sessionの州を経営するDDP Stream Session Control Chunksによって定義されます。 これらのChunksはダイナミックにDDP Stream SessionにDDP Endpointsを縛ります、そして、DDP Segment Chunksは、セッションと共にDDP Segmentsを確かに届けるのに使用されます。
5. Data Formats
5. データ形式
5.1. Adaptation Layer Indicator
5.1. 適合層のインディケータ
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 Adaptation Indicationを交渉させたSCTP Associationは本書では定義されるようにSCTP Data Chunksだけを運ぶでしょう。
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が協会を可能にしたので受信データ塊の取り扱いが単一の協会での通常のSCTP協会より十分異なった混合DDPに支持を要するのにおいて望ましくなくて非DDPの流れであると推定されます。 アプリケーションが、DDPと同じリモートホストとの非DDP交通の両方を利用することを望むなら、単一の協会以上が必要です。
Bestler & Stewart Standards Track [Page 5] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[5ページ]。
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で見えなければならないAdaptation Indicationを定義します。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC006をタイプしてください。| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 適合指示| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adaptation Indication:
適合指示:
The following value has been assigned for DDP.
DDPのために以下の値を割り当ててあります。
DDP - 0x00000001
DDP--0×00000001
5.2. Payload Data Chunks
5.2. 有効搭載量データ塊
The DDP SCTP adaptation uses two types of SCTP Payload Data Chunks, differentiated by the Payload Protocol Identifier:
DDP SCTP適合は有効搭載量プロトコルIdentifierによって微分されたSCTP有効搭載量Data Chunksの2つのタイプを使用します:
DDP Segment Chunks are used to reliably deliver DDP Segments sent
between DDP Endpoints.
DDP Segment Chunksは、DDP Endpointsの間に送られたDDP Segmentsを確かに届けるのに使用されます。
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 Stream Session Control MessagesはDDP Streamセッションズを設立して、取りこわすのに使用されます、特にSCTPの流れによるDDP Endpointsの結合を制御することによって。
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セグメント塊--16DDP流れのセッション制御--17
5.2.1. DDP Source Sequence Number (DDP-SSN)
5.2.1. DDPソース一連番号(DDP-SSN)
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有効搭載量Data ChunksがDDP Source Sequence Number(DDP-SSN)を含んでいます。 DDP-SSNはメッセージがSCTPの流れのためにSCTP層に使用中に提出された系列を追跡します。 DDP-SSN MUSTには、順不同のというよりむしろ命令されたSCTP有効搭載量Data Chunksが使用されていたならSCTP Stream Sequence Number(SSN)が割り当てられたのと同じ値があります。
Bestler & Stewart Standards Track [Page 6] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[6ページ]。
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層から迅速な配送を確実にするのに順不同の有効搭載量Data Chunksを使用するので、SCTP Stream Sequence Number(SSN)は適当ではありません。
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 Transmission Sequence Number(TSN)は流れの中でData Chunksに関する最初の注文を決定するのに適当ではありません。 送付SCTP層はChunk Bundlingを奨励するために順不同のData Chunksのトランスミッション系列を最適化するのが許容されているか、または他の目的のためのものです。
5.2.2. DDP Segment Chunk
5.2.2. 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 | DDP Segment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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セグメント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Segmentsが[RFC5041]で定義されるようにあります。 DDP Segment Chunkは付記された配列情報で信頼できるプロトコルの上までDDP Segmentsを運ぶという点にMPA[RFC5044]の上側のLayer PDU(MULPDU)と同じ目的に役立ちます。
5.2.3. DDP Stream Session Control
5.2.3. 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) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 機能コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 個人的なデータ(機能コードに依存する)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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流れのセッション開始--DDP流れのセッションが受け入れる0×001--0×002DDP流れのセッション廃棄物--DDP流れのセッションが終える0×003--0×004
Bestler & Stewart Standards Track [Page 7] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[7ページ]。
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 Stream Session Initiate、DDP Stream Session Accept、およびDDP Stream Session RejectメッセージのためにULPによって供給された兵士のDataを含まなければなりません。 しかしながら、兵士のDATA MAYに供給されたULPはゼロ・レングスのそうです。
Private Data length MUST NOT exceed 512 bytes in any message.
個人的なDataの長さはどんなメッセージの512バイトも超えてはいけません。
Private Data MUST NOT be included in the DDP Stream Session Terminate message.
DDP Stream Session Terminateメッセージに個人的なDataを含んではいけません。
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 Stream Session ControlはSHOULDを通信させます。ULPに報告されます。 報告されるなら、ULPが調べるように、どんな供給された兵士のDataも利用可能でなければなりません。
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に提出したというSession Initiate要求の数を制限するかもしれません。 そのような限界のためDDP Stream Session InitiateをULPに送ることができないとき、適合層はDDP Stream Session Terminateメッセージで応じなければなりません。
6. DDP Stream Sessions
6. 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 EndpointはDDP Segmentsの論理的な送付者/受信機です。 DDPの流れは、同じSCTP Stream Identifiersを持っているSCTPの流れの互角のペアを使用することで2DDP Endpointsを接続します。
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 Stream Sessionは2DDP Endpointsの間で以下のセクションで定義されるように異なった首尾を持っているDDPの流れで交換されたData Chunksの系列を定義します。 1DDP Stream SessionからのデータChunksは次のセッションまで決して持ち越されません。 各Data Chunkは明白にまさに1つのセッションに属します。 セッションのためにData Chunksに割り当てられた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 Sessionの初期の交換に基づいているDDPの流れにDDP Endpointを関連づけて、セッションの終わりにダイナミックにその協会を終えるかもしれません。 交互に、専門化している局所界面は単に静的にDDP Endpointsを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.
慣習上、ULPが、RDMA接続要求を受け入れると決めた後までRDMAのための局所界面はDDP Endpointの選択を延期しました。 しかし、それはワイヤプロトコル要件ではなく、局所界面選択です。
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 Stream Sessionの間、高々1Protection Domainしか関連していません。 受け身側では、協会が通常DDP Stream Session Acceptメッセージまで延期されます。
Bestler & Stewart Standards Track [Page 8] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[8ページ]。
6.1. Sequencing
6.1. 配列
The DDP-SSN is reset to zero at the beginning of each DDP Stream Session.
DDP-SSNはそれぞれのDDP Stream Sessionの始めにゼロにリセットされます。
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.
与えられたセッション以内に有効搭載量Data Chunksを考えるための標準の系列は各Data 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.
適合層が列挙された法的なパターンのいずれにも従わない有効搭載量Data Chunkを受けるなら、DDP Stream Sessionを終えなければなりません。
6.2. Legal Sequence: Active/Passive Session Accepted
6.2. 法的な系列: アクティブであるか受け身のセッションは受け入れました。
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 Stream Session系列では、1DDP Endpointが反対側が受け入れるDDP Stream Sessionを要求することにおける積極的役割を引き受けます。
Active side sends a DDP Stream Session Initiate message.
アクティブ側はDDP Stream Session Initiateメッセージを送ります。
Passive side sends a DDP Stream Session Accept message.
受け身側はDDP Stream Session Acceptメッセージを送ります。
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 Segmentsを送るかもしれないそれぞれが他のプロトコル層のそばででしゃばりました。
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.
それぞれの側への最終的なUser Data ChunkはDDP Stream Terminateであるかもしれません。 少なくとも半面はDDP Stream Terminateを送らなければなりません。 これがどんなRDMAP Terminateメッセージにも従うことに注意してください。(メッセージは単に適合層への別のDDP Segmentです)。
6.3. Legal Sequence: Active/Passive Session Rejected
6.3. 法的な系列: 拒絶されたアクティブであるか受け身のセッション
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.
Streamセッションズがただ一つの非ペイロードメッセージをもう一方の端の前に各当事者を送らせる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.
これらの決定は特定のProtection Domainを割り当てるか、いくつのRDMA Read Creditsが必要であるかを決定するか、またはいくつがULPが可能にするはずである操作を受けるかを決定する必要性によって影響を及ぼされるかもしれません。
Bestler & Stewart Standards Track [Page 9] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[9ページ]。
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 Stream Session Requestを拒絶するのを選ぶかもしれません。 これは以下の法的な系列をもたらします:
Active side sends a DDP Stream Session Initiate message.
アクティブ側はDDP Stream Session Initiateメッセージを送ります。
Passive side sends a DDP Stream Session Reject message.
受け身側はDDP Stream Session Rejectメッセージを送ります。
A DDP Stream Session Reject message MUST NOT be sent unless the rejection is at the direction of the ULP.
ULPの指示に拒絶がない場合、DDP Stream Session Rejectメッセージを送ってはいけません。
6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected
6.4. 法的な系列: 非ULPが拒絶したアクティブであるか受け身のセッション
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 Stream Session InitiateメッセージSHOULDの承認か拒絶がULPのコントロールの下でそうです。 これは、出来事をULPに通過するのを必要とするかもしれません。 有限限界がULP決定まであるそのような要求の数にあるに違いありません。 より多くのセッション要求が受信されているとき、受け身側はDDP Stream Terminate Messageと共にInitiateメッセージに応じなければなりません。
6.5. ULP-Specific Sequencing
6.5. ULP特有の配列
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.
AはULP MUSTを定義しました。定義された義務的なセッション系列だけを使用することで作動できてください。 任意の最適化にだけどんな追加系列も使用しなければなりません。
6.6. Other Sequencing Rules
6.6. 他の配列規則
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 Stream Session Controlメッセージの前に同じDDP Stream Sessionの中にそれを受け取るかもしれないなら、DDP Stream Session Controlメッセージを送ってはいけません。
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 Stream Sessionのアクティブな側面はDDP Stream Session Initiateメッセージの前に受け取られるかもしれないDDP Segmentを送ってはいけません。
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 Stream Session Initiateメッセージを伝えるのに使用されるData ChunkのSCTP acking、または敏感なDDP Stream Session Controlメッセージの領収書で決定するかもしれません。
A DDP Stream Identifier MUST NOT be reused for another DDP Stream Session while any Data Chunk from a prior session might be outstanding.
先のセッションからのどんなData Chunkも傑出しているかもしれない間、別のDDP Stream SessionのためにDDP Stream Identifierを再利用してはいけません。
Bestler & Stewart Standards Track [Page 10] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[10ページ]。
7. SCTP Endpoints
7. SCTP終点
7.1. Adaptation Layer Indication Restriction
7.1. 適合層の指示制限
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は、特定のAdaptation Indicationを使用するために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.
かつて、終点は許容できるAdaptation Indication(s)を決めて、それはSHOULDです。どんな異なった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実現は、終点への1つの協会が設立されるまでしか与えられたSCTP終点を求める協会要求を受け入れないのを選ぶかもしれません。 その時、それは、同じ終点が同じAdaptation Indicationを使用するすべてのより詳細な関連を制限するのを選ぶかもしれません。
7.2. Multihoming Implications
7.2. マルチホーミング含意
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")にすべて割り当てられる1セットの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.
または、ただ一つのIPアドレスより多くのDDPで可能にされたSCTP終点SHOULD NOTカバーのデフォルト結合がどちらももたらして、そうすることがなくない、追加バス通行、複製、メモリ登録リソースについて。 これは頻繁に可能にされた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によるAdvertisedがDDPで可能にされたものではなく、汎用のSCTP終点を扱うかもしれないすべてのIPアドレスから成ります。
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.
マルチホーミングが支持さえされるとき、ULPsが警告される、それ、彼ら、SHOULD NOTは複数の経路の向こう側に負荷で流れのバランスをとる試みにおける、ソースアドレスのULPコントロールを使用します。 マルチホーミングが前提でなるデザインにもかかわらず、経路の間の負荷バランスに使用されるのではなく、ネットワーク耐障害性に使用されて、SHOULDが最適化するマルチホーミングを支持するのを選ぶ受信DDP/SCTP実現。 これはお勧めのSCTP習慣と一致しています。
Bestler & Stewart Standards Track [Page 11] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[11ページ]。
8. Number of Streams
8. 流れの数
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 Stream Identifierと共に流す組み合わせでいつも構成されます。
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の流れの最大数を要求するはずです。 まだDDP EndpointsにSCTPの流れを縛らなければなりません、そして、DDPで可能にされたSCTP協会は命令されたData Chunksを支持しません。 したがって、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.
このマッピングは1つ以上のDDPの流れを運ぶSCTP協会を使用します。それぞれのDDPの流れは同じSCTP流れの番号で1組のSCTPの流れに写像されるでしょう。 適合は同じ数の本国行きの、そして、外国行きの流れとのSCTP協会のすべてを初期化しなければなりません。
9. Fragmentation
9. 断片化
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 Receiverは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のためのLower Layerプロトコル(LLP)として、SCTP適合層は支持される最大のDDP Segmentサイズの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.
最低516バイトが、512バイトの兵士のDataとDDP Stream Session Control Messageを許容するのに必要です。
SCTP data chunk fragmentation MUST NOT be used unless the alternative is IP fragmentation.
代替手段がIP断片化でないならSCTPデータ塊断片化を使用してはいけません。
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適合層のSHOULDは、同じSCTPパケットにControl Chunksを荷物をまとめさせるのを許容するために理論上の最大より下で最大のDDP Segmentサイズを設定します。
The SCTP adaptation layer MUST reject DDP Segments that are larger than the maximum size specified.
SCTP適合層は最大サイズが指定したより大きいDDP Segmentsを拒絶しなければなりません。
Bestler & Stewart Standards Track [Page 12] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[12ページ]。
10. Sequenced Unordered Operation
10. 配列された順不同の操作
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.
適合層はすべてのData ChunksでUnorderedオプションを使用しなければなりません(U Flagは1つにセットしました)。 SCTP層が即刻順不同のData Chunksを届けると予想されます。
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配送を使うので、受信機はDDP Segmentsの注文を含意するためにSCTP Transmission Sequence Number(TSN)を当てにされてはいけません。 DDP SegmentのためのSCTP Data Chunkが累積しているackポイントの前にあるという事実は、すべての先のDDPセグメントが置かれたのを保証しません。 SCTP送付者が提示されたオーダーで順不同のData Chunksを伝えるのが義務付けられません。
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.
機内のメッセージの最大数が32768未満であるときに、服従系列を決定するのに特別な論理なしでDDP-SSNを使用できます。 また、発信しているSCTPがただ一つの流れのためにTSNsを割り当てないで32767Data Chunksを受け入れるなら、これは適用されます。
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以上のData塊を受け入れるなら、送付DDPは、ただ一つの流れのために承認なしで32767Data Chunksを送るのを単に控えなければなりません。 それがこのために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.
受信機は、どんなギャップもunreceived Data Chunksによって説明されるかもしれないのを保証するために容認されたDDP-SSNsにバリディティチェックを実行するかもしれません。 最初にそのようなバリディティチェックを実行しないで、実現SHOULD NOTはDDP-SSNsが有効であるという前提でリソースを割り当てます。 DDPの流れの終了における無効のDDP-SSN MAY結果。
11. Procedures
11. 手順
11.1. Association Initialization
11.1. 協会初期設定
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)の交換の後に、終点は、Adaptation Indicationを確かめて、点検して、適切な動きを決定するために以下のテーブルとそれを比較しなければなりません。
Bestler & Stewart Standards Track [Page 13] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[13ページ]。
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
指示| 動作タイプ| ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | これがそれを示す、同輩DOES NOT NONE| その結果、あらゆるDDPかRDMA適合を支持してください。| RDMAとDDP手順はそうであるはずがありません。| この協会に実行されます。 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | これは、同輩DOESがDDPを支持するのを示します。| ここで定義されたDDP/SCTP適合層。 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | これがそれを示す、同輩DOES NOT ANY-OTHER| DDP適合を支持して、その結果、Indicationを支持してください。| DDP手順を実行してはいけません。| この協会で。 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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は局所界面で、指定されたモードに協会を設立するという要求しか受け入れることができないかもしれません。
11.2. Chunk Bundling
11.2. 塊バンドリング
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は、複数のData Chunksが単一のSCTPパケットに束ねられるのを許容します。 非タグ付けをされたメッセージSHOULD NOTが荷物をまとめるのを容易にするために遅れているDDP Segmentsを含むデータ塊。 一般に、タグ付けをされたメッセージがあるDDP Segmentsを含むデータ塊が完全に大きさで分けられて、したがって、バンドリングを受けることがなくなるでしょう。 しかしながら、短い非タグ付けをされたメッセージが頻繁にそれらのあとに続くとき、部分的なサイズのタグ付けをされたメッセージは遅れるかもしれません。
11.3. Association Termination
11.3. 協会終了
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 Associationの終了はSCTP層で扱われるべきです。 RDMAPによって定義されたRDMAP Terminate Message SHOULD、SCTP協会を終えるのを決断をしたときにはそれぞれのDDPの流れに送らないでください。 それぞれのSCTPの流れにそのメッセージを送ると、協会の終了は厳しく遅れるかもしれません。
The local interface SHOULD notify all consumers of DDP streams when the underlying SCTP stream has been terminated.
基本的なSCTPの流れが終えられたとき、局所界面SHOULDは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.
他のRDMAPによって定義されたTerminate Messagesは指定されるとしてDDPの流れが終えられると発生しなければなりません。 SCTPマッピングで、DDP Streamの終了がAssociationの終了を強制しないことに注意してください。
Bestler & Stewart Standards Track [Page 14] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[14ページ]。
12. IANA Considerations
12. IANA問題
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(0×00000001)のために新しいSCTP Adaptation Layer Indication codepointを定義します。 [RFC5061]はこのcodepointが割り当てられた登録を作成します。
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有効搭載量プロトコルIdentifiers(PPIDs)を定義します。 RFC4960[RFC4960]はこれらの識別子を割り当ててある登録を作成します。 以下の値を割り当ててあります:
DDP Segment Chunk - 16
DDP Stream Session Control - 17
DDPセグメント塊--16DDP流れのセッション制御--17
13. Security Considerations
13. セキュリティ問題
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]、またはSecurity[RFC5042]ドキュメントに記述されます。 このドキュメントはRFC4960[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.
Remote Direct Data Placement(RDDP)がIPsecのバージョンに基づいているので、IPsec要件は、RFC2401[RFC2401]で指定して、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるようにRFCsを関係づけて、RFCsを関係づけました。 RDDPプロトコルの重要な早めの応用の1つはiSCSI iSER[RFC5046]との彼らの使用です。 RDDPのIPsec要件は、IPsecの一般的なプロフィールがiSCSIとRDDPプロトコルと共に使用されるのを許容することによってその用法を容易にするためにIPsecのものに続きます。 将来、IPsecの、より新しいバージョンにRFC3723をアップデートするかもしれません。 どんなそのようなものの要件もアップデートする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の使用のためRDDPのためにトランスポート・プロトコルとしてSCTPの上でセキュリティに適用されます。 SCTPの上のRDDPのためのIPsecの実現:
1) MUST support IPsec functionality for SCTP equivalent to the IPsec
functionality for TCP that is required by RFC 3723,
1) RFC3723によって必要とされる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のサポートが全くない場合SHOULDが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のための少なくともプロトコルとポートセレクタの機能性のレベルを支持しなければなりません。
Bestler & Stewart Standards Track [Page 15] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[15ページ]。
14. Contributors
14. 貢献者
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ガングリー、独立しているコンサルタント、IBMのVivek Kashyap、マイクロソフトのジム・ピンカートン、およびBroadcomのHemalシャー。 すべてのきつい仕事をありがとうございます。
15. Acknowledgments
15. 承認
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.
作者はコメントと入力を提供した以下の人々に感謝したがっています: スティーブン・べイリー、デヴィッドBlack、ダグラスオーティス、アリンRomanow、およびジム・ウィリアムズ。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「ブロック格納プロトコルをIPの上に保証します」、RFC3723(2004年4月)。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、「流れの制御伝動プロトコル」、RFC4960、2007年9月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol
Specification", RFC 5040, October 2007.
[RFC5040]RecioとR.とメツラーとB.とCulleyとP.とHilland、J.とD.ガルシア、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(2007年10月)。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
Data Placement over Reliable Transports", RFC 5041,
October 2007.
2007年10月の[RFC5041]シャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement
Protocol (DDP) / Remote Direct Memory Access Protocol
(RDMAP) Security", RFC 5042, October 2007.
[RFC5042] ピンカートン、J.、およびE.Deleganesは「データプレースメントプロトコル(DDP)/リモートなダイレクトメモリアクセスプロトコル(RDMAP)セキュリティを指示します」、RFC5042、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]スチュワート、R.、シェ、Q.、Tuexen(M.、丸山、S.、およびM.小塚)は「制御伝動のプロトコルの(SCTP)ダイナミックなアドレス再構成を流します」、RFC5061、2007年9月。
16.2. Informative References
16.2. 有益な参照
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Bestler & Stewart Standards Track [Page 16] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[16ページ]。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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.、べイリー、S.、およびJ.キャリヤー、「マーカーPDUはTCPのために仕様を縁どりながら、並びました」、RFC5044、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] コー、M.、Chadalapaka、M.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」、RFC5046(2007年10月)。
Authors' Addresses
作者のアドレス
Caitlin Bestler (editor) Neterion 20230 Stevens Creek Blvd. Suite C Cupertino, CA 95014 USA
ケイトリンBestler(エディタ)Neterion20230スティーブンスクリークBlvd. Suite Cカルパチーノ(カリフォルニア)95014米国
Phone: 408-366-4639 EMail: caitlin.bestler@neterion.com
以下に電話をしてください。 408-366-4639 メールしてください: caitlin.bestler@neterion.com
Randall R. Stewart (editor) Cisco Systems, Inc. Forest Drive Columbia, SC 29036 USA
ランドルR.スチュワート(エディタ)シスコシステムズInc.森林Drive SC29036コロンビア(米国)
Phone: +1-815-342-5222 EMail: rrs@cisco.com
以下に電話をしてください。 +1-815-342-5222 メールしてください: rrs@cisco.com
Bestler & Stewart Standards Track [Page 17] RFC 5043 SCTP DDP Adaptation October 2007
BestlerとスチュワートStandardsはSCTP DDP適合2007年10月にRFC5043を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Bestler & Stewart Standards Track [Page 18]
Bestlerとスチュワート標準化過程[18ページ]
一覧
スポンサーリンク
