[要約] RFC 8260は、Stream Control Transmission Protocol（SCTP）のストリームスケジューラとユーザーメッセージの交互配置に関する規格です。このRFCの目的は、SCTPのパフォーマンスを向上させ、ユーザーメッセージの効率的な処理を可能にすることです。
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8260 Netflix, Inc.
Category: Standards Track M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
S. Loreto
Ericsson
R. Seggelmann
Metafinanz Informationssysteme GmbH
November 2017
Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
Stream Control Transmission Protocolのストリームスケジューラとユーザーメッセージインターリーブ
Abstract
概要
The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.
ストリーム制御伝送プロトコル（SCTP）は、任意のサイズのユーザーメッセージをサポートするメッセージ指向のトランスポートプロトコルです。このドキュメントでは、ペイロードデータを伝送するための新しいチャンクをSCTPに追加します。これにより、送信者は異なるユーザーメッセージをインターリーブできます。そうしないと、送信者で行頭ブロッキングが発生します。 WebRTCデータチャネルには、ユーザーメッセージのインターリーブが必要です。
Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.
SCTP送信者がユーザーデータの送信を許可されている場合は常に、複数の発信SCTPストリームから選択できます。この選択では、ストリームスケジューラと呼ばれる複数の方法がこのドキュメントで定義されています。ストリームスケジューラは、ユーザーメッセージインターリーブを実装するか、実装しないかを選択できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8260.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8260で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. User Message Interleaving . . . . . . . . . . . . . . . . . . 6
2.1. The I-DATA Chunk Supporting User Message Interleaving . . 7
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Sender-Side Considerations . . . . . . . . . . . . . 10
2.2.3. Receiver-Side Considerations . . . . . . . . . . . . 11
2.3. Interaction with Other SCTP Extensions . . . . . . . . . 11
2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 11
2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 13
3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 14
3.1. First-Come, First-Served Scheduler (SCTP_SS_FCFS) . . . . 14
3.2. Round-Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 14
3.3. Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 14
3.4. Priority-Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 14
3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 15
3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 15
4. Socket API Considerations . . . . . . . . . . . . . . . . . . 15
4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 15
4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 16
4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Enable or Disable the Support of User Message
Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 16
4.3.2. Get or Set the Stream Scheduler
(SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 17
4.3.3. Get or Set the Stream Scheduler Parameter
(SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 18
4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 19
5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
When SCTP [RFC4960] was initially designed, it was mainly envisioned for the transport of small signaling messages. Late in the design stage, it was decided to add support for fragmentation and reassembly of larger messages with the thought that someday signaling messages in the style of Session Initiation Protocol (SIP) [RFC3261] may also need to use SCTP, and a message that is a single Maximum Transmission Unit (MTU) would be too small. Unfortunately this design decision, though valid at the time, did not account for other applications that might send large messages over SCTP. The sending of such large messages over SCTP, as specified in [RFC4960], can result in a form of sender-side head-of-line blocking (e.g., when the transmission of a message is blocked from transmission because the sender has started the transmission of another, possibly large, message). This head-of-line blocking is caused by the use of the Transmission Sequence Number (TSN) for three different purposes:
SCTP [RFC4960]が最初に設計されたとき、それは主に小さなシグナリングメッセージの転送を想定していた。設計段階の後半に、いつかセッション開始プロトコル（SIP）[RFC3261]のスタイルのシグナリングメッセージもSCTPを使用する必要があるかもしれないという考えで、より大きなメッセージの断片化と再構成のサポートを追加することが決定され、メッセージ単一の最大転送単位（MTU）が小さすぎます。残念ながら、この設計上の決定は当時は有効でしたが、SCTPを介して大きなメッセージを送信する可能性のある他のアプリケーションを考慮していませんでした。 [RFC4960]で指定されているように、SCTPを介してそのような大きなメッセージを送信すると、送信者側の行頭ブロッキングの形式になることがあります（たとえば、送信者が送信を開始したためにメッセージの送信が送信からブロックされた場合）別の、おそらく大きなメッセージの送信）。この行頭ブロッキングは、次の3つの異なる目的で伝送シーケンス番号（TSN）を使用したことが原因です。
1. As an identifier for DATA chunks to provide a reliable transfer.
1. 信頼性の高い転送を提供するDATAチャンクの識別子として。
2. As an identifier for the sequence of fragments to allow reassembly.
2. 再構成を可能にするフラグメントのシーケンスの識別子として。
3. As a sequence number allowing up to 2**16 - 1 Stream Sequence Numbers (SSNs) outstanding.
3. 最大2 ** 16-1の未処理のストリームシーケンス番号（SSN）を許可するシーケンス番号として。
The protocol requires all fragments of a user message to have consecutive TSNs. This document allows an SCTP sender to interleave different user messages.
このプロトコルでは、ユーザーメッセージのすべてのフラグメントにTSNが連続している必要があります。このドキュメントにより、SCTP送信者は異なるユーザーメッセージをインターリーブできます。
This document also defines several stream schedulers for general SCTP associations allowing different relative stream treatments. The stream schedulers may behave differently depending on whether or not user message interleaving has been negotiated for the association.
このドキュメントでは、さまざまな相対ストリーム処理を可能にする一般的なSCTPアソシエーション用のいくつかのストリームスケジューラも定義しています。ストリームスケジューラの動作は、ユーザーメッセージのインターリービングが関連付けに対してネゴシエートされているかどうかによって異なります。
Figure 1 illustrates the behavior of a round-robin stream scheduler using DATA chunks when three streams with the Stream Identifiers (SIDs) 0, 1, and 2 are used. Each queue for SID 0 and SID 2 contains a single user message requiring three chunks. The queue for SID 1 contains three user messages each requiring a single chunk. It is shown how these user messages are encapsulated in chunks using TSN 0 to TSN 8. Please note that the use of such a scheduler implies late TSN assignment, but it can be used with an implementation that is compliant with [RFC4960] and that does not support user message interleaving. Late TSN assignment means that the sender generates chunks from user messages and assigns the TSN as late as possible in the process of sending the user messages.
図1は、ストリーム識別子（SID）が0、1、および2の3つのストリームが使用されている場合に、DATAチャンクを使用するラウンドロビンストリームスケジューラの動作を示しています。 SID 0およびSID 2の各キューには、3つのチャンクを必要とする単一のユーザーメッセージが含まれています。 SID 1のキューには、それぞれ単一のチャンクを必要とする3つのユーザーメッセージが含まれています。これらのユーザーメッセージがTSN 0〜TSN 8を使用してチャンクにカプセル化される方法を示します。このようなスケジューラの使用は遅延TSN割り当てを意味しますが、[RFC4960]に準拠する実装で使用でき、ユーザーメッセージのインターリーブはサポートされていません。レイトTSN割り当てとは、送信者がユーザーメッセージからチャンクを生成し、ユーザーメッセージの送信プロセスで可能な限り遅くTSNを割り当てることを意味します。
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|
|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-------+
+-------+ |SID/SSN|
|SID/SSN| |-------|
+-------+ | TSN |
+-------+
Figure 1: Round-Robin Scheduler without User Message Interleaving
図1：ユーザーメッセージインターリーブなしのラウンドロビンスケジューラ
This document describes a new chunk carrying payload data called I-DATA. This chunk incorporates the properties of the current SCTP DATA chunk, all the flags and fields except the Stream Sequence Number (SSN), and also adds two new fields in its chunk header -- the Fragment Sequence Number (FSN) and the Message Identifier (MID). The FSN is only used for reassembling all fragments that have the same MID and the same ordering property. The TSN is only used for the reliable transfer in combination with Selective Acknowledgment (SACK) chunks.
このドキュメントでは、I-DATAと呼ばれるペイロードデータを運ぶ新しいチャンクについて説明します。このチャンクは、現在のSCTP DATAチャンクのプロパティ、ストリームシーケンス番号（SSN）を除くすべてのフラグとフィールドを組み込んでおり、チャンクヘッダーにフラグメントシーケンス番号（FSN）とメッセージID（ MID）。 FSNは、同じMIDと同じ順序付けプロパティを持つすべてのフラグメントを再構成する場合にのみ使用されます。 TSNは、選択的確認応答（SACK）チャンクと組み合わせた信頼性の高い転送にのみ使用されます。
In addition, the MID is also used for ensuring ordered delivery instead of using the stream sequence number (the I-DATA chunk omits an SSN).
さらに、MIDは、ストリームシーケンス番号を使用する代わりに、順序付けられた配信を保証するためにも使用されます（I-DATAチャンクはSSNを省略します）。
Figure 2 illustrates the behavior of an interleaving round-robin stream scheduler using I-DATA chunks.
図2は、I-DATAチャンクを使用したインターリービングラウンドロビンストリームスケジューラの動作を示しています。
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|
|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-----------+
+-------+ |SID/MID/FSN|
|SID/MID| |-----------|
+-------+ | TSN |
+-----------+
Figure 2: Round-Robin Scheduler with User Message Interleaving
図2：ユーザーメッセージインターリーブを使用したラウンドロビンスケジューラ
The support of the I-DATA chunk is negotiated during the association setup using the Supported Extensions Parameter, as defined in [RFC5061]. If I-DATA support has been negotiated for an association, I-DATA chunks are used for all user messages. DATA chunks are not permitted when I-DATA support has been negotiated. It should be noted that an SCTP implementation supporting I-DATA chunks needs to allow the coexistence of associations using DATA chunks and associations using I-DATA chunks.
I-DATAチャンクのサポートは、[RFC5061]で定義されているサポートされている拡張パラメータを使用して、関連付けのセットアップ中にネゴシエートされます。関連付けについてI-DATAサポートがネゴシエートされている場合、すべてのユーザーメッセージにI-DATAチャンクが使用されます。 I-DATAサポートがネゴシエートされている場合、DATAチャンクは許可されません。 I-DATAチャンクをサポートするSCTP実装では、DATAチャンクを使用した関連付けとI-DATAチャンクを使用した関連付けの共存を許可する必要があることに注意してください。
In Section 2, this document specifies the user message interleaving by defining the I-DATA chunk, the procedures to use it, and its interactions with other SCTP extensions. Section 3 defines multiple stream schedulers, and Section 4 describes an extension to the socket API for using the mechanism specified in this document.
セクション2で、このドキュメントは、I-DATAチャンク、それを使用する手順、および他のSCTP拡張との相互作用を定義することにより、ユーザーメッセージインターリーブを指定します。セクション3では複数のストリームスケジューラを定義し、セクション4では、このドキュメントで指定されているメカニズムを使用するためのソケットAPIの拡張について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The protocol mechanisms described in this document allow the interleaving of user messages sent on different streams. They do not support the interleaving of multiple messages (ordered or unordered) sent on the same stream.
このドキュメントで説明するプロトコルメカニズムにより、さまざまなストリームで送信されるユーザーメッセージのインターリーブが可能になります。同じストリームで送信される複数のメッセージ（順序付きまたは順序なし）のインターリーブはサポートされていません。
The interleaving of user messages is required for WebRTC data channels, as specified in [DATA-CHAN].
[DATA-CHAN]で指定されているように、WebRTCデータチャネルにはユーザーメッセージのインターリーブが必要です。
An SCTP implementation supporting user message interleaving is REQUIRED to support the coexistence of associations using DATA chunks and associations using I-DATA chunks. If an SCTP implementation supports user message interleaving and the Partial Reliability extension described in [RFC3758] or the Stream Reconfiguration Extension described in [RFC6525], it is REQUIRED to implement the corresponding changes specified in Section 2.3.
DATAメッセージチャンクを使用した関連付けとI-DATAチャンクを使用した関連付けの共存をサポートするには、ユーザーメッセージインターリービングをサポートするSCTP実装が必要です。 SCTP実装がユーザーメッセージインターリービングと[RFC3758]で説明されている部分信頼性拡張または[RFC6525]で説明されているストリーム再構成拡張をサポートしている場合、セクション2.3で指定されている対応する変更を実装する必要があります。
The following Figure 3 shows the new I-DATA chunk allowing user message interleaving.
次の図3は、ユーザーメッセージのインターリーブを可能にする新しいI-DATAチャンクを示しています。
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 = 64 | Res |I|U|B|E| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier / Fragment Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: I-DATA Chunk Format
図3：I-DATAチャンク形式
The only differences between the I-DATA chunk in Figure 3 and the DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the new Message Identifier (MID) and the new Fragment Sequence Number (FSN) and the removal of the Stream Sequence Number (SSN). The Payload Protocol Identifier (PPID), which is already defined for DATA chunks in [RFC4960], and the new FSN are stored at the same location of the packet using the B bit to determine which value is stored at the location. The length of the I-DATA chunk header is 20 bytes, which is 4 bytes more than the length of the DATA chunk header defined in [RFC4960] and [RFC7053].
図3のI-DATAチャンクと、[RFC4960]および[RFC7053]で定義されたDATAチャンクとの唯一の違いは、新しいメッセージ識別子（MID）と新しいフラグメントシーケンス番号（FSN）の追加、およびストリームシーケンス番号（SSN）。 [RFC4960]でDATAチャンクに対して既に定義されているペイロードプロトコル識別子（PPID）と新しいFSNは、Bビットを使用してパケットの同じ場所に格納され、その場所に格納される値を決定します。 I-DATAチャンクヘッダーの長さは20バイトです。これは、[RFC4960]と[RFC7053]で定義されているDATAチャンクヘッダーの長さより4バイト長いです。
The old fields are:
古いフィールドは次のとおりです。
Res: 4 bits These bits are reserved. They MUST be set to 0 by the sender and MUST be ignored by the receiver.
Res：4ビットこれらのビットは予約済みです。それらは送信者によって0に設定されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
I bit: 1 bit The (I)mmediate Bit, if set, indicates that the receiver SHOULD NOT delay the sending of the corresponding SACK chunk. Same as the I bit for DATA chunks, as specified in [RFC7053].
Iビット：1ビット（I）中間ビットは、設定されている場合、受信者が対応するSACKチャンクの送信を遅らせてはならない（SHOULD NOT）ことを示します。 [RFC7053]で指定されているように、DATAチャンクのIビットと同じです。
U bit: 1 bit The (U)nordered bit, if set, indicates the user message is unordered. Same as the U bit for DATA chunks, as specified in [RFC4960].
Uビット：1ビット（U）順序付きビットは、設定されている場合、ユーザーメッセージが順序付けされていないことを示します。 [RFC4960]で指定されているように、DATAチャンクのUビットと同じです。
B bit: 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. Same as the B bit for DATA chunks, as specified in [RFC4960].
Bビット：1ビット（B）開始フラグメントビットは、設定されている場合、ユーザーメッセージの最初のフラグメントを示します。 [RFC4960]で指定されているように、DATAチャンクのBビットと同じです。
E bit: 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. Same as the E bit for DATA chunks, as specified in [RFC4960].
Eビット：1ビット（E）フラグメントビットは、設定されている場合、ユーザーメッセージの最後のフラグメントを示します。 [RFC4960]で指定されているように、DATAチャンクのEビットと同じです。
Length: 16 bits (unsigned integer) This field indicates the length in bytes of the DATA chunk from the beginning of the Type field to the end of the User Data field, excluding any padding. Similar to the Length for DATA chunks, as specified in [RFC4960].
長さ：16ビット（符号なし整数）このフィールドは、タイプフィールドの先頭からユーザーデータフィールドの末尾までのDATAチャンクのバイト単位の長さを示します（パディングを除く）。 [RFC4960]で指定されているDATAチャンクの長さに似ています。
TSN: 32 bits (unsigned integer) This value represents the TSN for this I-DATA chunk. Same as the TSN for DATA chunks, as specified in [RFC4960].
TSN：32ビット（符号なし整数）この値は、このI-DATAチャンクのTSNを表します。 [RFC4960]で指定されているように、DATAチャンクのTSNと同じです。
Stream Identifier: 16 bits (unsigned integer) Identifies the stream to which the user data belongs. Same as the Stream Identifier for DATA chunks, as specified in [RFC4960].
ストリーム識別子：16ビット（符号なし整数）ユーザーデータが属するストリームを識別します。 [RFC4960]で指定されているように、DATAチャンクのストリーム識別子と同じです。
The new fields are:
新しいフィールドは次のとおりです。
Reserved: 16 bits (unsigned integer) This field is reserved. It MUST be set to 0 by the sender and MUST be ignored by the receiver.
予約：16ビット（符号なし整数）このフィールドは予約されています。送信者は0に設定する必要があり、受信者は無視する必要があります。
Message Identifier (MID): 32 bits (unsigned integer) The MID is the same for all fragments of a user message; it is used to determine which fragments (enumerated by the FSN) belong to the same user message. For ordered user messages, the MID is also used by the SCTP receiver to deliver the user messages in the correct order to the upper layer (similar to the SSN of the DATA chunk defined in [RFC4960]). The sender uses two counters for each outgoing stream: one for ordered messages and one for unordered messages. All of these counters are independent and initially 0. They are incremented by 1 for each user message. Please note that the serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 32 applies. Therefore, the sender MUST NOT have more than 2**31 - 1 ordered messages for each outgoing stream in flight and MUST NOT have more than 2**31 - 1 unordered messages for each outgoing stream in flight. A message is considered in flight if at least one of its I-DATA chunks is not acknowledged in a way that cannot be reneged (i.e., not acknowledged by the cumulative TSN Ack). Please note that the MID is in "network byte order", a.k.a. Big Endian.
メッセージID（MID）：32ビット（符号なし整数）MIDは、ユーザーメッセージのすべてのフラグメントで同じです。これは、（FSNによって列挙された）どのフラグメントが同じユーザーメッセージに属するかを決定するために使用されます。順序付けられたユーザーメッセージの場合、MIDはSCTPレシーバーによってユーザーメッセージを正しい順序で上位層に配信するためにも使用されます（[RFC4960]で定義されているDATAチャンクのSSNと同様）。送信者は、送信ストリームごとに2つのカウンターを使用します。1つは順序付けられたメッセージ用で、もう1つは順序付けされていないメッセージ用です。これらのカウンターはすべて独立しており、最初は0です。ユーザーメッセージごとに1ずつ増加します。 [RFC1982]でSERIAL_BITS = 32を使用して定義されたシリアル番号演算が適用されることに注意してください。したがって、送信者は、フライト中の各発信ストリームに対して2 ** 31-1を超える順序付けされたメッセージがあってはならず、また、フライト中の各出力ストリームに対して2 ** 31-1を超える順序付けられていないメッセージがあってはなりません。 I-DATAチャンクの少なくとも1つが無視できない方法で確認されない（つまり、累積TSN Ackで確認されない）場合、メッセージは処理中と見なされます。 MIDは「ネットワークバイトオーダー」、つまりビッグエンディアンであることに注意してください。
Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 32 bits (unsigned integer) If the B bit is set, this field contains the PPID of the user message. Note that in this case, this field is not touched by an SCTP implementation; therefore, its byte order is not necessarily in network byte order. The upper layer is responsible for any byte order conversions to this field, similar to the PPID of DATA chunks. In this case, the FSN is implicitly considered to be 0. If the B bit is not set, this field contains the FSN. The FSN is used to enumerate all fragments of a single user message, starting from 0 and incremented by 1. The last fragment of a message MUST have the E bit set. Note that the FSN MAY wrap completely multiple times, thus allowing arbitrarily large user messages. For the FSN, the serial number arithmetic defined in [RFC1982] applies with SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 2**31 - 1 fragments of a single user message in flight. A fragment is considered in flight if it is not acknowledged in a way that cannot be reneged. Please note that the FSN is in "network byte order", a.k.a. Big Endian.
ペイロードプロトコル識別子（PPID）/フラグメントシーケンス番号（FSN）：32ビット（符号なし整数）Bビットが設定されている場合、このフィールドにはユーザーメッセージのPPIDが含まれます。この場合、このフィールドはSCTP実装によって影響を受けないことに注意してください。したがって、そのバイト順は必ずしもネットワークバイト順ではありません。上位層は、DATAチャンクのPPIDと同様に、このフィールドへのバイトオーダー変換を担当します。この場合、FSNは暗黙的に0と見なされます。Bビットが設定されていない場合、このフィールドにはFSNが含まれます。 FSNは、単一のユーザーメッセージのすべてのフラグメントを列挙するために使用され、0から始まり、1ずつ増加します。メッセージの最後のフラグメントには、Eビットが設定されている必要があります。 FSNは完全に複数回ラップする可能性があることに注意してください。これにより、任意のサイズのユーザーメッセージを許可できます。 FSNの場合、[RFC1982]で定義されているシリアル番号の計算はSERIAL_BITS = 32で適用されます。したがって、送信者は、進行中の単一ユーザーメッセージの2 ** 31-1フラグメントを超えてはなりません。破棄できない方法で確認されない場合、フラグメントは処理中と見なされます。 FSNは「ネットワークバイトオーダー」、つまりビッグエンディアンであることに注意してください。
This subsection describes how the support of the I-DATA chunk is negotiated and how the I-DATA chunk is used by the sender and receiver.
このサブセクションでは、I-DATAチャンクのサポートがネゴシエートされる方法と、I-DATAチャンクが送信者と受信者によってどのように使用されるかについて説明します。
The handling of the I bit for the I-DATA chunk corresponds to the handling of the I bit for the DATA chunk described in [RFC7053].
I-DATAチャンクのIビットの処理は、[RFC7053]で説明されているDATAチャンクのIビットの処理に対応しています。
An SCTP endpoint indicates user message interleaving support by listing the I-DATA chunk within the Supported Extensions Parameter, as defined in [RFC5061]. User message interleaving has been negotiated for an association if both endpoints have indicated I-DATA support.
[RFC5061]で定義されているように、SCTPエンドポイントは、サポートされている拡張パラメーター内にI-DATAチャンクをリストすることにより、ユーザーメッセージインターリーブサポートを示します。両方のエンドポイントがI-DATAサポートを示している場合、ユーザーメッセージインターリービングは関連付けのためにネゴシエートされました。
If user message interleaving support has been negotiated for an association, I-DATA chunks MUST be used for all user messages and DATA chunks MUST NOT be used. If user message interleaving support has not been negotiated for an association, DATA chunks MUST be used for all user messages and I-DATA chunks MUST NOT be used.
ユーザーメッセージインターリーブサポートが関連付けに対してネゴシエートされている場合、すべてのユーザーメッセージにI-DATAチャンクを使用する必要があり、DATAチャンクを使用してはなりません（MUST NOT）。ユーザーメッセージインターリーブサポートが関連付けに対してネゴシエートされていない場合、すべてのユーザーメッセージにDATAチャンクを使用する必要があり、I-DATAチャンクを使用してはなりません（MUST NOT）。
An endpoint implementing the socket API specified in [RFC6458] MUST NOT indicate user message interleaving support unless the user has requested its use (e.g., via the socket API; see Section 4.3). This constraint is made since the usage of this chunk requires that the application is capable of handling interleaved messages upon reception within an association. This is not the default choice within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option in Section 8.1.20 of [RFC6458]); thus, the user MUST indicate to the SCTP implementation its support for receiving completely interleaved messages.
[RFC6458]で指定されたソケットAPIを実装するエンドポイントは、ユーザーがその使用を要求しない限り（例えば、ソケットAPIを介して、セクション4.3を参照）、ユーザーメッセージインターリーブのサポートを示してはなりません。このチャンクを使用するには、アプリケーションがアソシエーション内で受信すると、インターリーブされたメッセージを処理できる必要があるため、この制約が発生します。これは、ソケットAPI内のデフォルトの選択ではありません（[RFC6458]のセクション8.1.20のSCTP_FRAGMENT_INTERLEAVEソケットオプションを参照してください）。したがって、ユーザーは完全にインターリーブされたメッセージを受信するためのサポートをSCTP実装に示す必要があります。
Note that stacks that do not implement [RFC6458] may use other methods to indicate interleaved message support and thus indicate the support of user message interleaving. The crucial point is that the SCTP stack MUST know that the application can handle interleaved messages before indicating the I-DATA support.
[RFC6458]を実装していないスタックは、他の方法を使用してインターリーブされたメッセージのサポートを示し、ユーザーメッセージのインターリーブのサポートを示す場合があることに注意してください。重要な点は、SCTPスタックは、I-DATAサポートを示す前に、アプリケーションがインターリーブメッセージを処理できることを認識している必要があることです。
The sender-side usage of the I-DATA chunk is quite simple. Instead of using the TSN for fragmentation purposes, the sender uses the new FSN field to indicate which fragment number is being sent. The first fragment MUST have the B bit set. The last fragment MUST have the E bit set. All other fragments MUST NOT have the B or E bit set. All other properties of the existing SCTP DATA chunk also apply to the I-DATA chunk, i.e., congestion control as well as receiver window conditions MUST be observed, as defined in [RFC4960].
I-DATAチャンクの送信側の使用法は非常に簡単です。フラグメント化の目的でTSNを使用する代わりに、送信者は新しいFSNフィールドを使用して、送信されているフラグメント番号を示します。最初のフラグメントにはBビットが設定されている必要があります。最後のフラグメントにはEビットが設定されている必要があります。他のすべてのフラグメントには、BまたはEビットを設定してはなりません（MUST NOT）。既存のSCTP DATAチャンクの他のすべてのプロパティもI-DATAチャンクに適用されます。つまり、[RFC4960]で定義されているように、輻輳制御とレシーバーウィンドウの条件を遵守する必要があります。
Note that the usage of this chunk implies the late assignment of the actual TSN to any chunk being sent. Each I-DATA chunk uses a single TSN. This way messages from other streams may be interleaved with the fragmented message. Please note that this is the only form of interleaving support. For example, it is not possible to interleave multiple ordered or unordered user messages from the same stream.
このチャンクの使用は、送信されるチャンクへの実際のTSNの割り当てが遅いことを意味することに注意してください。各I-DATAチャンクは単一のTSNを使用します。このようにして、他のストリームからのメッセージが断片化されたメッセージとインターリーブされる場合があります。これがインターリーブサポートの唯一の形式であることに注意してください。たとえば、同じストリームから複数の順序付きまたは順序なしのユーザーメッセージをインターリーブすることはできません。
The sender MUST NOT process (move user data into I-DATA chunks and assign a TSN to it) more than one user message in any given stream at any time. At any time, a sender MAY process multiple user messages, each of them on different streams.
送信者は、任意のストリームの複数のユーザーメッセージをいつでも処理（ユーザーデータをI-DATAチャンクに移動してTSNを割り当てる）してはなりません（MUST NOT）。いつでも、送信者は複数のユーザーメッセージを処理できます（MAY）。各メッセージは異なるストリーム上にあります。
The sender MUST assign TSNs to I-DATA chunks in a way that the receiver can make progress. One way to achieve this is to assign a higher TSN to the later fragments of a user message and send out the I-DATA chunks such that the TSNs are in sequence.
送信者は、受信者が進行できるようにTSNをI-DATAチャンクに割り当てなければなりません（MUST）。これを実現する1つの方法は、ユーザーメッセージの後半のフラグメントに高いTSNを割り当て、TSNが連続するようにI-DATAチャンクを送信することです。
Upon reception of an SCTP packet containing an I-DATA chunk whose user message needs to be reassembled, the receiver MUST first use the SID to identify the stream, consider the U bit to determine if it is part of an ordered or unordered message, find the user message identified by the MID, and use the FSN for reassembly of the message and not the TSN. The receiver MUST NOT make any assumption about the TSN assignments of the sender. Note that a non-fragmented message is indicated by the fact that both the E and B bits are set. A message (either ordered or unordered) whose E and B bits are not both set may be identified as being fragmented.
ユーザーメッセージを再構成する必要があるI-DATAチャンクを含むSCTPパケットを受信すると、受信者は最初にSIDを使用してストリームを識別し、Uビットを考慮して、それが順序付けられたメッセージまたは順序付けされていないメッセージの一部であるかどうかを判断し、 MIDによって識別されるユーザーメッセージ。メッセージの再組み立てにはFSNを使用し、TSNは使用しません。受信者は送信者のTSN割り当てについていかなる仮定もしてはならない（MUST NOT）。フラグメント化されていないメッセージは、EビットとBビットの両方が設定されているという事実によって示されることに注意してください。 EビットとBビットの両方が設定されていないメッセージ（順序付きまたは順序なし）は、フラグメント化されていると識別される場合があります。
If I-DATA support has been negotiated for an association, the reception of a DATA chunk is a violation of the above rules and therefore the receiver of the DATA chunk MUST abort the association by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol Violation' error cause. The same applies if I-DATA support has not been negotiated for an association and an I-DATA chunk is received.
関連付けについてI-DATAサポートがネゴシエートされている場合、DATAチャンクの受信は上記の規則に違反しているため、DATAチャンクの受信者はABORTチャンクを送信して関連付けを中止する必要があります。 ABORTチャンクには、「プロトコル違反」エラーの原因が含まれる場合があります。関連付けについてI-DATAサポートがネゴシエートされておらず、I-DATAチャンクが受信された場合も同じことが当てはまります。
The usage of the I-DATA chunk might interfere with other SCTP extensions. Future SCTP extensions MUST describe if and how they interfere with the usage of I-DATA chunks. For the SCTP extensions already defined when this document was published, the details are given in the following subsections.
I-DATAチャンクの使用は、他のSCTP拡張に干渉する可能性があります。将来のSCTP拡張は、I-DATAチャンクの使用を妨害するかどうか、および妨害する方法を記述しなければなりません（MUST）。このドキュメントの公開時に既に定義されているSCTP拡張機能の詳細については、次のサブセクションで説明します。
When the SCTP extension defined in [RFC3758] is used in combination with the user message interleaving extension, the new I-FORWARD-TSN chunk MUST be used instead of the FORWARD-TSN chunk. The difference between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit Message Identifier (MID), and the largest skipped MID can also be provided for unordered messages. Therefore, the principle applied to ordered messages when using FORWARD-TSN chunks is applied to ordered and unordered messages when using I-FORWARD-TSN chunks.
[RFC3758]で定義されているSCTP拡張をユーザーメッセージインターリービング拡張と組み合わせて使用する場合、FORWARD-TSNチャンクの代わりに新しいI-FORWARD-TSNチャンクを使用する必要があります。 FORWARD-TSNチャンクとI-FORWARD-TSNチャンクの違いは、16ビットのストリームシーケンス番号（SSN）が32ビットのメッセージID（MID）に置き換えられ、スキップされた最大のMIDも提供できることです。順序付けられていないメッセージの場合。したがって、FORWARD-TSNチャンクを使用するときに順序付けされたメッセージに適用される原則は、I-FORWARD-TSNチャンクを使用するときに順序付けられたメッセージと順序付けされていないメッセージに適用されます。
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 = 194 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: I-FORWARD-TSN Chunk Format
図4：I-FORWARD-TSNチャンク形式
The old fields are:
古いフィールドは次のとおりです。
Flags: 8 bits (unsigned integer) These bits are reserved. They MUST be set to 0 by the sender and MUST be ignored by the receiver. Same as the Flags for FORWARD TSN chunks, as specified in [RFC3758].
フラグ：8ビット（符号なし整数）これらのビットは予約されています。それらは送信者によって0に設定されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。 [RFC3758]で指定されている、FORWARD TSNチャンクのフラグと同じです。
Length: 16 bits (unsigned integer) This field holds the length of the chunk. Similar to the Length for FORWARD TSN chunks, as specified in [RFC3758].
長さ：16ビット（符号なし整数）このフィールドには、チャンクの長さが保持されます。 [RFC3758]で指定されているFORWARD TSNチャンクの長さに似ています。
New Cumulative TSN: 32 bits (unsigned integer) This indicates the New Cumulative TSN to the data receiver. Same as the New Cumulative TSN for FORWARD TSN chunks, as specified in [RFC3758].
新しい累積TSN：32ビット（符号なし整数）これは、データレシーバーに対する新しい累積TSNを示します。 [RFC3758]で指定されているように、FORWARD TSNチャンクの新しい累積TSNと同じ。
The new fields are:
新しいフィールドは次のとおりです。
Stream Identifier (SID): 16 bits (unsigned integer) This field holds the stream number this entry refers to.
ストリーム識別子（SID）：16ビット（符号なし整数）このフィールドは、このエントリが参照するストリーム番号を保持します。
Reserved: 15 bits This field is reserved. It MUST be set to 0 by the sender and MUST be ignored by the receiver.
予約：15ビットこのフィールドは予約されています。送信者は0に設定する必要があり、受信者は無視する必要があります。
U bit: 1 bit The U bit specifies if the Message Identifier of this entry refers to unordered messages (U bit is set) or ordered messages (U bit is not set).
Uビット：1ビットUビットは、このエントリのメッセージ識別子が順序付けられていないメッセージ（Uビットが設定されている）を参照するか、順序付けされたメッセージ（Uビットが設定されていない）を参照するかを指定します。
Message Identifier (MID): 32 bits (unsigned integer) This field holds the largest Message Identifier for ordered or unordered messages indicated by the U bit that was skipped for the stream specified by the Stream Identifier. For ordered messages, this is similar to the FORWARD-TSN chunk, just replacing the 16-bit SSN by the 32-bit MID.
メッセージID（MID）：32ビット（符号なし整数）このフィールドには、ストリームIDで指定されたストリームに対してスキップされたUビットで示される、順序付けられたメッセージまたは順序付けされていないメッセージの最大のメッセージIDが保持されます。順序付けられたメッセージの場合、これはFORWARD-TSNチャンクに似ており、16ビットのSSNを32ビットのMIDに置き換えるだけです。
Support for the I-FORWARD-TSN chunk is negotiated during the SCTP association setup via the Supported Extensions Parameter, as defined in [RFC5061]. The partial reliability extension is negotiated and can be used in combination with user message interleaving only if both endpoints indicated their support of user message interleaving and the I-FORWARD-TSN chunk.
I-FORWARD-TSNチャンクのサポートは、[RFC5061]で定義されているように、サポートされている拡張パラメータを介してSCTPアソシエーションのセットアップ中にネゴシエートされます。部分的な信頼性拡張はネゴシエートされ、両方のエンドポイントがユーザーメッセージインターリーブとI-FORWARD-TSNチャンクのサポートを示した場合にのみ、ユーザーメッセージインターリーブと組み合わせて使用できます。
The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and MUST NOT be used in combination with the I-DATA chunk. The I-FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and MUST NOT be used in combination with the DATA chunk.
FORWARD-TSNチャンクはDATAチャンクと組み合わせて使用する必要があり、I-DATAチャンクと組み合わせて使用してはなりません。 I-FORWARD-TSNチャンクは、I-DATAチャンクと組み合わせて使用する必要があり、DATAチャンクと組み合わせて使用してはなりません。
If I-FORWARD-TSN support has been negotiated for an association, the reception of a FORWARD-TSN chunk is a violation of the above rules and therefore the receiver of the FORWARD-TSN chunk MUST abort the association by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol Violation' error cause. The same applies if I-FORWARD-TSN support has not been negotiated for an association and a FORWARD-TSN chunk is received.
I-FORWARD-TSNサポートがアソシエーションに対してネゴシエートされている場合、FORWARD-TSNチャンクの受信は上記の規則に違反しているため、FORWARD-TSNチャンクの受信者はABORTチャンクを送信してアソシエーションを中止する必要があります。 ABORTチャンクには、「プロトコル違反」エラーの原因が含まれる場合があります。 I-FORWARD-TSNサポートがアソシエーションに対してネゴシエートされておらず、FORWARD-TSNチャンクが受信された場合も同様です。
When an association resets the SSN using the SCTP extension defined in [RFC6525], the two counters (one for the ordered messages, one for the unordered messages) used for the MIDs MUST be reset to 0.
アソシエーションが[RFC6525]で定義されているSCTP拡張を使用してSSNをリセットする場合、MIDに使用される2つのカウンター（1つは順序付けられたメッセージ用、1つは順序付けられていないメッセージ用）を0にリセットする必要があります。
Since most schedulers, especially all schedulers supporting user message interleaving, require late TSN assignment, it should be noted that the implementation of [RFC6525] needs to handle this.
ほとんどのスケジューラー、特にユーザー・メッセージ・インターリービングをサポートするすべてのスケジューラーは、遅延TSN割り当てを必要とするため、[RFC6525]の実装がこれを処理する必要があることに注意してください。
This section defines several stream schedulers. The stream schedulers may behave differently depending on whether or not user message interleaving has been negotiated for the association. An implementation MAY implement any subset of them. If the implementation is used for WebRTC data channels, as specified in [DATA-CHAN], it MUST implement the Weighted Fair Queueing Scheduler defined in Section 3.6.
このセクションでは、いくつかのストリームスケジューラを定義します。ストリームスケジューラの動作は、ユーザーメッセージのインターリービングが関連付けに対してネゴシエートされているかどうかによって異なります。実装はそれらのサブセットを実装してもよい（MAY）。 [DATA-CHAN]で指定されているように、実装がWebRTCデータチャネルに使用されている場合、セクション3.6で定義されている重み付けされた均等化キュースケジューラを実装する必要があります。
The selection of the stream scheduler is done at the sender side. There is no mechanism provided for signaling the stream scheduler being used to the receiver side or even for letting the receiver side influence the selection of the stream scheduler used at the sender side.
ストリームスケジューラの選択は送信側で行われます。使用されているストリームスケジューラを受信側に通知するためのメカニズムや、受信側に送信側で使用されるストリームスケジューラの選択に影響を与えるためのメカニズムはありません。
The simple first-come, first-served scheduler of user messages is used. It just passes through the messages in the order in which they have been delivered by the application. No modification of the order is done at all. The usage of user message interleaving does not affect the sending of the chunks, except that I-DATA chunks are used instead of DATA chunks.
ユーザーメッセージの単純な先着順のスケジューラが使用されます。メッセージは、アプリケーションによって配信された順序で通過します。注文の変更は一切行われません。ユーザーメッセージインターリーブの使用は、チャンクの送信に影響を与えません。ただし、DATAチャンクの代わりにI-DATAチャンクが使用されます。
When not interleaving user messages, this scheduler provides a fair scheduling based on the number of user messages by cycling around non-empty stream queues. When interleaving user messages, this scheduler provides a fair scheduling based on the number of I-DATA chunks by cycling around non-empty stream queues.
ユーザーメッセージをインターリーブしない場合、このスケジューラは、空でないストリームキューを循環することにより、ユーザーメッセージの数に基づいて公平なスケジューリングを提供します。ユーザーメッセージをインターリーブする場合、このスケジューラは、空でないストリームキューを循環することにより、I-DATAチャンクの数に基づいて公平なスケジューリングを提供します。
This is a round-robin scheduler, which only switches streams when starting to fill a new packet. It bundles only DATA or I-DATA chunks referring to the same stream in a packet. This scheduler minimizes head-of-line blocking when a packet is lost because only a single stream is affected.
これはラウンドロビンスケジューラであり、新しいパケットの書き込みを開始したときにのみストリームを切り替えます。パケット内の同じストリームを参照するDATAまたはI-DATAチャンクのみをバンドルします。このスケジューラーは、単一のストリームのみが影響を受けるため、パケットが失われたときの行頭ブロッキングを最小化します。
Scheduling of user messages with strict priorities is used. The priority is configurable per outgoing SCTP stream. Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the scheduling between them is implementation dependent. When the scheduler interleaves user messages, the sending of large, lower-priority user messages will not delay the sending of higher-priority user messages.
厳密な優先度を持つユーザーメッセージのスケジューリングが使用されます。優先順位は、発信SCTPストリームごとに構成可能です。より高い優先度を持つストリームが最初にスケジュールされ、複数のストリームが同じ優先度を持つ場合、それらの間のスケジュールは実装に依存します。スケジューラがユーザーメッセージをインターリーブする場合、優先度の低い大きなユーザーメッセージの送信によって、優先度の高いユーザーメッセージの送信が遅延することはありません。
A fair capacity distribution between the streams is used. This scheduler considers the lengths of the messages of each stream and schedules them in a specific way to maintain an equal capacity for all streams. The details are implementation dependent. interleaving user messages allows for a better realization of the fair capacity usage.
ストリーム間の公平な容量配分が使用されます。このスケジューラーは、各ストリームのメッセージの長さを考慮し、すべてのストリームに対して等しい容量を維持するために特定の方法でそれらをスケジュールします。詳細は実装に依存します。ユーザーメッセージをインターリーブすることで、適切な容量の使用をより適切に実現できます。
A Weighted Fair Queueing scheduler between the streams is used. The weight is configurable per outgoing SCTP stream. This scheduler considers the lengths of the messages of each stream and schedules them in a specific way to use the capacity according to the given weights. If the weight of stream S1 is n times the weight of stream S2, the scheduler should assign to stream S1 n times the capacity it assigns to stream S2. The details are implementation dependent. Interleaving user messages allows for a better realization of the capacity usage according to the given weights.
ストリーム間の重み付けされた均等化キュースケジューラが使用されます。重みは発信SCTPストリームごとに設定可能です。このスケジューラーは、各ストリームのメッセージの長さを考慮し、指定された重みに従って容量を使用する特定の方法でそれらをスケジュールします。ストリームS1の重みがストリームS2の重みのn倍である場合、スケジューラーは、ストリームS1に、ストリームS2に割り当てる容量のn倍を割り当てる必要があります。詳細は実装に依存します。ユーザーメッセージをインターリーブすると、指定された重みに応じて、容量の使用率をより適切に実現できます。
This scheduler, in combination with user message interleaving, is used for WebRTC data channels, as specified in [DATA-CHAN].
このスケジューラは、ユーザーメッセージインターリーブと組み合わせて、[DATA-CHAN]で指定されているように、WebRTCデータチャネルに使用されます。
This section describes how the socket API defined in [RFC6458] is extended to allow applications to use the extension described in this document.
このセクションでは、[RFC6458]で定義されたソケットAPIを拡張して、アプリケーションがこのドキュメントで説明されている拡張機能を使用できるようにする方法について説明します。
Please note that this section is informational only.
このセクションは情報提供のみを目的としています。
The socket API defined in [RFC6458] defines several structures in which the SSN of a received user message is exposed to the application. The list of these structures includes:
[RFC6458]で定義されているソケットAPIは、受信したユーザーメッセージのSSNがアプリケーションに公開されるいくつかの構造を定義します。これらの構造のリストは次のとおりです。
struct sctp_sndrcvinfo Specified in Section 5.3.2 of [RFC6458] and marked as deprecated.
struct sctp_sndrcvinfo [RFC6458]のセクション5.3.2で指定され、非推奨としてマークされています。
struct sctp_extrcvinfo Specified in Section 5.3.3 of [RFC6458] and marked as deprecated.
struct sctp_extrcvinfo [RFC6458]のセクション5.3.3で指定され、非推奨としてマークされています。
struct sctp_rcvinfo Specified in Section 5.3.5 of [RFC6458].
struct sctp_rcvinfo [RFC6458]のセクション5.3.5で指定。
If user message interleaving is used, the lower-order 16 bits of the MID are used as the SSN when filling out these structures.
ユーザーメッセージインターリービングが使用される場合、これらの構造を入力するときに、MIDの下位16ビットがSSNとして使用されます。
When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association where both peers support the I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in the sac_info field.
SCTP_ASSOC_CHANGE通知（[RFC6458]のセクション6.1.1で指定）が配信され、両方のピアがI-DATAチャンクをサポートするSCTPアソシエーションのSCTP_COMM_UPまたはSCTP_RESTARTのsac_stateを示す場合、SCTP_ASSOC_SUPPORTS_INTERLEAVINGがsac_infoフィールドにリストされます。
+-----------------------------+-------------------------+-----+-----+
| Option Name | Data Type | Get | Set |
+-----------------------------+-------------------------+-----+-----+
| SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER_VALUE | struct | X | X |
| | sctp_stream_value | | |
+-----------------------------+-------------------------+-----+-----+
4.3.1. Enable or Disable the Support of User Message Interleaving (SCTP_INTERLEAVING_SUPPORTED)
4.3.1. ユーザーメッセージインターリービングのサポートを有効または無効にする（SCTP_INTERLEAVING_SUPPORTED）
This socket option allows the enabling or disabling of the negotiation of user message interleaving support for future associations. For existing associations, it allows for querying whether or not user message interleaving support was negotiated on a particular association.
このソケットオプションを使用すると、将来のアソシエーションに対するユーザーメッセージインターリーブサポートのネゴシエーションを有効または無効にできます。既存のアソシエーションの場合、特定のアソシエーションでユーザーメッセージインターリービングサポートがネゴシエートされたかどうかを照会できます。
This socket option uses IPPROTO_SCTP as its level and SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with getsockopt() and setsockopt(). The socket option value uses the following structure defined in [RFC6458]:
このソケットオプションは、レベルとしてIPPROTO_SCTPを使用し、名前としてSCTP_INTERLEAVING_SUPPORTEDを使用します。 getsockopt()およびsetsockopt()で使用できます。ソケットオプション値は、[RFC6458]で定義されている次の構造を使用します。
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special sctp_assoc_t SCTP_FUTURE_ASSOC can also be used; it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_id：このパラメーターは、1対1スタイルのソケットでは無視されます。 1対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。特別なsctp_assoc_t SCTP_FUTURE_ASSOCも使用できます。 assoc_idでSCTP_ {CURRENT | ALL} _ASSOCを使用するとエラーになります。
assoc_value: A non-zero value encodes the enabling of user message interleaving, whereas a value of zero encodes the disabling of user message interleaving.
assoc_value：ゼロ以外の値はユーザーメッセージインターリーブの有効化をエンコードしますが、値0はユーザーメッセージインターリーブの無効化をエンコードします。
sctp_opt_info() needs to be extended to support SCTP_INTERLEAVING_SUPPORTED.
sctp_opt_info()は、SCTP_INTERLEAVING_SUPPORTEDをサポートするように拡張する必要があります。
An application using user message interleaving should also set the fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE socket option specified in Section 8.1.20 of [RFC6458]. This allows the interleaving of user messages from different streams. Please note that it does not allow the interleaving of user messages (ordered or unordered) on the same stream. Failure to set this option can possibly lead to application deadlock. Some implementations might therefore put some restrictions on setting combinations of these values. Setting the interleaving level to at least 2 before enabling the negotiation of user message interleaving should work on all platforms. Since the default fragment interleave level is not 2, user message interleaving is disabled per default.
ユーザーメッセージインターリーブを使用するアプリケーションでは、[RFC6458]のセクション8.1.20で指定されているSCTP_FRAGMENT_INTERLEAVEソケットオプションを使用して、フラグメントインターリーブレベルを2に設定する必要もあります。これにより、異なるストリームからのユーザーメッセージのインターリーブが可能になります。同じストリームでユーザーメッセージ（順序付けまたは順序付けなし）をインターリーブできないことに注意してください。このオプションを設定しないと、アプリケーションのデッドロックが発生する可能性があります。したがって、実装によっては、これらの値の組み合わせの設定にいくつかの制限を課す場合があります。ユーザーメッセージインターリーブのネゴシエーションを有効にする前に、インターリーブレベルを少なくとも2に設定すると、すべてのプラットフォームで機能するはずです。デフォルトのフラグメントインターリーブレベルは2ではないため、ユーザーメッセージインターリービングはデフォルトで無効になっています。
A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER option for setsockopt(). The struct sctp_assoc_value is used to specify the association for which the scheduler should be changed and the value of the desired algorithm.
ストリームスケジューラは、setsockopt()のSCTP_STREAM_SCHEDULERオプションで選択できます。 struct sctp_assoc_valueを使用して、スケジューラを変更する必要がある関連付けと、目的のアルゴリズムの値を指定します。
The definition of struct sctp_assoc_value is the same as in [RFC6458]:
struct sctp_assoc_valueの定義は[RFC6458]と同じです：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: Holds the identifier of the association for which the scheduler should be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter is ignored for one-to-one style sockets.
assoc_id：スケジューラを変更する必要がある関連付けの識別子を保持します。特別なSCTP_ {FUTURE | CURRENT | ALL} _ASSOCも使用できます。このパラメーターは、1対1スタイルのソケットでは無視されます。
assoc_value: This specifies which scheduler is used. The following constants can be used:
assoc_value：使用するスケジューラーを指定します。次の定数を使用できます。
SCTP_SS_DEFAULT: The default scheduler used by the SCTP implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR.
SCTP_SS_DEFAULT：SCTP実装で使用されるデフォルトのスケジューラ。一般的な値はSCTP_SS_FCFSまたはSCTP_SS_RRです。
SCTP_SS_FCFS: Use the scheduler specified in Section 3.1.
SCTP_SS_FCFS：セクション3.1で指定されたスケジューラを使用します。
SCTP_SS_RR: Use the scheduler specified in Section 3.2.
SCTP_SS_RR：セクション3.2で指定されたスケジューラを使用します。
SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3.
SCTP_SS_RR_PKT：セクション3.3で指定されたスケジューラを使用します。
SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The priority can be assigned with the sctp_stream_value struct. The higher the assigned value, the lower the priority. That is, the default value 0 is the highest priority, and therefore the default scheduling will be used if no priorities have been assigned.
SCTP_SS_PRIO：セクション3.4で指定されたスケジューラを使用します。優先順位はsctp_stream_value構造体で割り当てることができます。割り当てられた値が高いほど、優先度は低くなります。つまり、デフォルト値0が最高の優先順位であるため、優先順位が割り当てられていない場合はデフォルトのスケジューリングが使用されます。
SCTP_SS_FB: Use the scheduler specified in Section 3.5.
SCTP_SS_FB：セクション3.5で指定されたスケジューラを使用します。
SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The weight can be assigned with the sctp_stream_value struct.
SCTP_SS_WFQ：セクション3.6で指定されたスケジューラを使用します。重みはsctp_stream_value構造体で割り当てることができます。
sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER.
sctp_opt_info()は、SCTP_STREAM_SCHEDULERをサポートするように拡張する必要があります。
4.3.3. Get or Set the Stream Scheduler Parameter (SCTP_STREAM_SCHEDULER_VALUE)
4.3.3. ストリームスケジューラパラメータの取得または設定（SCTP_STREAM_SCHEDULER_VALUE）
Some schedulers require additional information to be set for individual streams as shown in the following table:
一部のスケジューラでは、次の表に示すように、個々のストリームに追加情報を設定する必要があります。
+-----------------+-----------------+
| Name | Per-Stream Info |
+-----------------+-----------------+
| SCTP_SS_DEFAULT | n/a |
| SCTP_SS_FCFS | no |
| SCTP_SS_RR | no |
| SCTP_SS_RR_PKT | no |
| SCTP_SS_PRIO | yes |
| SCTP_SS_FB | no |
| SCTP_SS_WFQ | yes |
+-----------------+-----------------+
This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the corresponding struct sctp_stream_value. The definition of struct sctp_stream_value is as follows:
これは、SCTP_STREAM_SCHEDULER_VALUEオプションと対応するstruct sctp_stream_valueで実現されます。 struct sctp_stream_valueの定義は次のとおりです。
struct sctp_stream_value {
sctp_assoc_t assoc_id;
uint16_t stream_id;
uint16_t stream_value;
};
assoc_id: Holds the identifier of the association for which the scheduler should be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter is ignored for one-to-one style sockets.
assoc_id：スケジューラを変更する必要がある関連付けの識別子を保持します。特別なSCTP_ {FUTURE | CURRENT | ALL} _ASSOCも使用できます。このパラメーターは、1対1スタイルのソケットでは無視されます。
stream_id: Holds the identifier of the stream for which additional information has to be provided.
stream_id：追加情報を提供する必要があるストリームの識別子を保持します。
stream_value: The meaning of this field depends on the scheduler specified. It is ignored when the scheduler does not need additional information.
stream_value：このフィールドの意味は、指定されたスケジューラーによって異なります。スケジューラーが追加情報を必要としない場合は無視されます。
sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER_VALUE.
sctp_opt_info()は、SCTP_STREAM_SCHEDULER_VALUEをサポートするように拡張する必要があります。
Using explicit End of Record (EOR) marking for an SCTP association supporting user message interleaving allows the user to interleave the sending of user messages on different streams.
ユーザーメッセージのインターリーブをサポートするSCTPアソシエーションに明示的なEOR（End of Record）マーキングを使用すると、ユーザーは異なるストリームでユーザーメッセージの送信をインターリーブできます。
Two new chunk types have been assigned by IANA.
IANAによって2つの新しいチャンクタイプが割り当てられました。
IANA has assigned the chunk type for this chunk from the pool of chunks with the upper two bits set to '01'. This appears in the "Chunk Types" registry for SCTP as follows:
IANAは、上位2ビットが「01」に設定されたチャンクのプールから、このチャンクのチャンクタイプを割り当てました。これは、SCTPの「チャンクタイプ」レジストリに次のように表示されます。
+----------+--------------------------------------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+--------------------------------------------+-----------+
| 64 | Payload Data supporting Interleaving | RFC 8260 |
| | (I-DATA) | |
+----------+--------------------------------------------+-----------+
The registration table (as defined in [RFC6096]) for the chunk flags
of this chunk type is initially as follows:
+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+
| 0x01 | E bit | RFC 8260 |
| 0x02 | B bit | RFC 8260 |
| 0x04 | U bit | RFC 8260 |
| 0x08 | I bit | RFC 8260 |
| 0x10 | Unassigned | |
| 0x20 | Unassigned | |
| 0x40 | Unassigned | |
| 0x80 | Unassigned | |
+------------------+-----------------+-----------+
IANA has assigned the chunk type for this chunk from the pool of chunks with the upper two bits set to '11'. This appears in the "Chunk Types" registry for SCTP as follows:
IANAは、上位2ビットが「11」に設定されたチャンクのプールから、このチャンクのチャンクタイプを割り当てました。これは、SCTPの「チャンクタイプ」レジストリに次のように表示されます。
+----------+---------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+---------------+-----------+
| 194 | I-FORWARD-TSN | RFC 8260 |
+----------+---------------+-----------+
The registration table (as defined in [RFC6096]) for the chunk flags of this chunk type is initially empty.
このチャンクタイプのチャンクフラグの登録テーブル（[RFC6096]で定義）は、最初は空です。
This document does not add any additional security considerations in addition to the ones given in [RFC4960] and [RFC6458].
このドキュメントは、[RFC4960]と[RFC6458]で与えられたものに加えて、追加のセキュリティの考慮事項を追加しません。
It should be noted that the application has to consent that it is willing to do the more complex reassembly support required for user message interleaving. When doing so, an application has to provide a reassembly buffer for each incoming stream. It has to protect itself against these buffers taking too many resources. If user message interleaving is not used, only a single reassembly buffer needs to be provided for each association. But the application has to protect itself for excessive resource usages there too.
アプリケーションは、ユーザーメッセージのインターリーブに必要な、より複雑な再アセンブリサポートを実行することに同意する必要があることに注意してください。その場合、アプリケーションは各着信ストリームに対して再構成バッファーを提供する必要があります。多くのリソースを消費するこれらのバッファから自分自身を保護する必要があります。ユーザーメッセージインターリービングを使用しない場合、関連付けごとに1つの再構成バッファーを用意するだけで済みます。しかし、アプリケーションは、そこでの過剰なリソース使用に対しても自分自身を保護する必要があります。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982] Elz、R. and R. Bush、 "Serial Number Arithmetic"、RFC 1982、DOI 10.17487 / RFC1982、August 1996、<https://www.rfc-editor.org/info/rfc1982>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）Partial Reliability Extension」、RFC 3758、DOI 10.17487 / RFC3758、May 2004、<https://www.rfc-editor.org/info/rfc3758>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487 / RFC5061、9月2007、<https://www.rfc-editor.org/info/rfc5061>。
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, DOI 10.17487/RFC6096, January 2011, <https://www.rfc-editor.org/info/rfc6096>.
[RFC6096] Tuexen、M。、およびR. Stewart、「Stream Control Transmission Protocol（SCTP）Chunk Flags Registration」、RFC 6096、DOI 10.17487 / RFC6096、2011年1月、<https://www.rfc-editor.org/info / rfc6096>。
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、DOI 10.17487 / RFC6525、2012年2月、<https：//www.rfc- editor.org/info/rfc6525>。
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053] Tuexen、M.、Ruengeler、I。、およびR. Stewart、「SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol」、RFC 7053、DOI 10.17487 / RFC7053、2013年11月、<https：//www.rfc -editor.org/info/rfc7053>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.
[DATA-CHAN] Jesup、R.、Loreto、S。、およびM. Tuexen、「WebRTCデータチャネル」、Work in Progress、draft-ietf-rtcweb-data-channel-13、2015年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487 / RFC6458 、2011年12月、<https://www.rfc-editor.org/info/rfc6458>。
Acknowledgments
謝辞
The authors wish to thank Benoit Claise, Julian Cordes, Spencer Dawkins, Gorry Fairhurst, Lennart Grahl, Christer Holmberg, Mirja Kuehlewind, Marcelo Ricardo Leitner, Karen E. Egede Nielsen, Maksim Proshin, Eric Rescorla, Irene Ruengeler, Felix Weinrank, Michael Welzl, Magnus Westerlund, and Lixia Zhang for their invaluable comments.
著者は、ブノワ・クレイズ、ジュリアン・コーデス、スペンサー・ドーキンス、ゴーリー・フェアハースト、レナート・グラール、クリスター・ホルムバーグ、ミヤ・キュールウィンド、マルセロ・リカルド・レイトナー、カレン・E・エジエ・ニールセン、マクシム・プロシン、エリック・レスコーラ、アイリーン・ルエンゲラー、フェリックス・ウェインランクに感謝します、Magnus Westerlund、Lixia Zhangの貴重なコメント。
This work has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No. 644334 (NEAT). The views expressed are solely those of the authors.
この作品は、EUのHorizon 2020研究およびイノベーションプログラムから、助成金契約番号644334（NEAT）のもとで資金提供を受けています。表明された見解は、著者の見解のみです。
Authors' Addresses
著者のアドレス
Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America
Randall R. Stewart Netflix、Inc. Chapin、SC 29036アメリカ合衆国
Email: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
Michael Tuexen Muenster応用科学大学Stegerwaldstrasse 39 48565シュタインフルトドイツ
Email: tuexen@fh-muenster.de
Salvatore Loreto Ericsson Torshamnsgatan 21 164 80 Stockholm Sweden
Salvatore Loreto Ericsson Torshamnsgatan 21 164 80ストックホルムスウェーデン
Email: Salvatore.Loreto@ericsson.com
Robin Seggelmann Metafinanz Informationssysteme GmbH Leopoldstrasse 146 80804 Muenchen Germany
Robin Seggelmann Metafinanz Informationssysteme GmbH Leopoldstrasse 146 80804ミュンヘンドイツ
Email: rfc@robin-seggelmann.com