[要約] RFC 6525は、SCTPにおけるストリームの再構成に関する仕様です。その目的は、SCTPのストリームを動的に再構成するための手法と手順を提供することです。
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 6525 Adara Networks
Category: Standards Track M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
P. Lei
Cisco Systems, Inc.
February 2012
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
ストリーム制御伝送プロトコル（SCTP）ストリーム再構成
Abstract
概要
Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers.
Stream Control送信プロトコル（SCTP）を使用する多くのアプリケーションは、ストリームを「リセット」する機能を必要としています。ストリームをリセットする意図は、リセットが実行されたというアプリケーションレイヤーに対応する通知を使用して、ストリームの番号付けシーケンスを「ゼロ」に戻すことです。この機能が必要なアプリケーションでは、さまざまな目的でストリームを「再利用」できるようにしてください。したがって、この機能がなければ、古いストリームを新しい使用すると、「ストリームをゼロに戻す」プロトコルメカニズムがない限り、メッセージ番号が予想よりも大きくなります。このドキュメントには、送信シーケンス番号をリセットし、ストリームを追加し、すべてのストリームシーケンス番号をリセットする方法も含まれています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6525.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6525で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. New Chunk Type ..................................................4
3.1. RE-CONFIG Chunk ............................................5
4. New Parameter Types .............................................6
4.1. Outgoing SSN Reset Request Parameter .......................7
4.2. Incoming SSN Reset Request Parameter .......................8
4.3. SSN/TSN Reset Request Parameter ............................9
4.4. Re-configuration Response Parameter .......................10
4.5. Add Outgoing Streams Request Parameter ....................12
4.6. Add Incoming Streams Request Parameter ....................13
5. Procedures .....................................................14
5.1. Sender-Side Procedures ....................................14
5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk .....14
5.1.2. Sender-Side Procedures for the Outgoing SSN
Reset Request Parameter ............................15
5.1.3. Sender-Side Procedures for the Incoming SSN
Reset Request Parameter ............................16
5.1.4. Sender-Side Procedures for the SSN/TSN
Reset Request Parameter ............................17
5.1.5. Sender-Side Procedures for the Add Outgoing
Streams Request Parameter ..........................17
5.1.6. Sender-Side Procedures for the Add Incoming
Streams Request Parameter ..........................17
5.1.7. Sender-Side Procedures for the
Re-configuration Response Parameter ................18
5.2. Receiver-Side Procedures ..................................18
5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk ...18
5.2.2. Receiver-Side Procedures for the Outgoing
SSN Reset Request Parameter ........................19
5.2.3. Receiver-Side Procedures for the Incoming
SSN Reset Request Parameter ........................20
5.2.4. Receiver-Side Procedures for the SSN/TSN
Reset Request Parameter ............................21
5.2.5. Receiver-Side Procedures for the Add
Outgoing Streams Request Parameter .................21
5.2.6. Receiver-Side Procedures for the Add
Incoming Streams Request Parameter .................22
5.2.7. Receiver-Side Procedures for the
Re-configuration Response Parameter ................22
6. Sockets API Considerations .....................................23
6.1. Events ....................................................23
6.1.1. Stream Reset Event .................................24
6.1.2. Association Reset Event ............................25
6.1.3. Stream Change Event ................................26
6.2. Event Subscription ........................................27
6.3. Socket Options ............................................27
6.3.1. Enable/Disable Stream Reset
(SCTP_ENABLE_STREAM_RESET) .........................28
6.3.2. Reset Incoming and/or Outgoing Streams
(SCTP_RESET_STREAMS) ...............................29
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) ...................29
6.3.4. Add Incoming and/or Outgoing Streams
(SCTP_ADD_STREAMS) .................................30
7. Security Considerations ........................................30
8. IANA Considerations ............................................31
8.1. A New Chunk Type ..........................................31
8.2. Six New Chunk Parameter Types .............................31
9. Acknowledgments ................................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................32
Appendix A. Examples of the Reconfiguration Procedures ............33
Many applications that use SCTP as defined in [RFC4960] want the ability to "reset" a stream. The intention of resetting a stream is to set the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want to "reuse" streams for different purposes but still utilize the SSN so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result
[RFC4960]で定義されているSCTPを使用する多くのアプリケーションは、ストリームを「リセット」する機能を必要としています。ストリームをリセットする意図は、リセットが実行されたというアプリケーションレイヤーに対応する通知を使用して、ストリームのストリームシーケンス番号（SSNS）を「ゼロ」に戻すことです。この機能を必要とするアプリケーションは、さまざまな目的でストリームを「再利用」する必要がありますが、アプリケーションがメッセージフローを追跡できるようにSSNを利用しています。したがって、この機能がなければ、古いストリームの新しい使用が生じます
in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the Transmission Sequence Numbers (TSNs), adding additional streams, and resetting all SSNs.
「ストリームをゼロに戻す」プロトコルメカニズムがない限り、予想よりも大きいメッセージ番号で。このドキュメントには、送信シーケンス番号（TSNS）をリセットする方法、追加のストリームの追加、すべてのSSNのリセットも含まれています。
The sockets API for SCTP defined in [RFC6458] exposes the sequence numbers used by SCTP for user message transfer. Therefore, resetting them can be used by application writers. Please note that the corresponding sequence number for TCP is not exposed via the sockets API for TCP.
[RFC6458]で定義されたSCTPのSockets APIは、SCTPがユーザーメッセージ転送に使用するシーケンス番号を公開します。したがって、それらをリセットすることは、アプリケーションライターで使用できます。TCPの対応するシーケンス番号は、TCPのSockets APIを介して公開されないことに注意してください。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This section defines the new chunk type that will be used to reconfigure streams. Table 1 illustrates the new chunk type.
このセクションでは、ストリームの再構成に使用される新しいチャンクタイプを定義します。表1は、新しいチャンクタイプを示しています。
+------------+------------------------------------+
| Chunk Type | Chunk Name |
+------------+------------------------------------+
| 130 | Re-configuration Chunk (RE-CONFIG) |
+------------+------------------------------------+
Table 1
表1
It should be noted that the format of the RE-CONFIG chunk requires that the receiver ignore the chunk if it is not understood and continue processing all chunks that follow. This is accomplished by the use of the upper bits of the chunk type as described in Section 3.2 of [RFC4960].
ReConfig Chunkの形式では、レシーバーが理解されていない場合はチャンクを無視し、続くすべてのチャンクを処理し続けることが必要であることに注意する必要があります。これは、[RFC4960]のセクション3.2で説明されているように、チャンクタイプの上部ビットを使用することによって達成されます。
All transported integer numbers are in "network byte order", a.k.a. Big Endian.
輸送されたすべての整数数は、「ネットワークバイトの順序」、別名ビッグエンディアンです。
This document adds one new chunk type to SCTP. The chunk has the following format:
このドキュメントは、1つの新しいチャンクタイプをSCTPに追加します。チャンクには次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 130 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Re-configuration Parameter /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Re-configuration Parameter (optional) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 1 byte (unsigned integer) This field holds the IANA-defined chunk type for the RE-CONFIG chunk. The value of this field is 130.
チャンクタイプ：1バイト（符号なし整数）このフィールドには、ReConfigチャンク用のIANA定義のチャンクタイプが保持されます。このフィールドの値は130です。
Chunk Flags: 1 byte (unsigned integer) This field is set to 0 by the sender and ignored by the receiver.
チャンクフラグ：1バイト（符号なし整数）このフィールドは、送信者によって0に設定され、受信機によって無視されます。
Chunk Length: 2 bytes (unsigned integer) This field holds the length of the chunk in bytes, including the Chunk Type, Chunk Flags, and Chunk Length.
チャンクの長さ：2バイト（符号なし整数）このフィールドは、チャンクタイプ、チャンクフラグ、チャンクの長さを含むバイトのチャンクの長さを保持します。
Re-configuration Parameter This field holds a Re-configuration Request Parameter or a Re-configuration Response Parameter.
再構成パラメーターこのフィールドは、再構成要求パラメーターまたは再構成応答パラメーターを保持します。
Note that each RE-CONFIG chunk holds at least one parameter and at most two parameters. Only the following combinations are allowed:
各reconfigチャンクは、少なくとも1つのパラメーターと最大2つのパラメーターを保持していることに注意してください。次の組み合わせのみが許可されています。
1. Outgoing SSN Reset Request Parameter.
1. 発信SSNリセット要求パラメーター。
2. Incoming SSN Reset Request Parameter.
2. 着信SSNリセット要求パラメーター。
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request Parameter.
3. 発信SSNリセット要求パラメーター、着信SSNリセット要求パラメーター。
4. SSN/TSN Reset Request Parameter.
4. SSN/TSNリセット要求パラメーター。
5. Add Outgoing Streams Request Parameter.
5. 発信ストリーム要求パラメーターを追加します。
6. Add Incoming Streams Request Parameter.
6. 着信ストリーム要求パラメーターを追加します。
7. Add Outgoing Streams Request Parameter, Add Incoming Streams Request Parameter.
7. 発信ストリームリクエストパラメーターを追加し、加速ストリームリクエストパラメーターを追加します。
8. Re-configuration Response Parameter.
8. 再構成応答パラメーター。
9. Re-configuration Response Parameter, Outgoing SSN Reset Request Parameter.
9. 再構成応答パラメーター、発信SSNリセット要求パラメーター。
10. Re-configuration Response Parameter, Re-configuration Response Parameter.
10. 再構成応答パラメーター、再構成応答パラメーター。
If a sender transmits an unsupported combination, the receiver SHOULD send an ERROR chunk with a Protocol Violation cause, as defined in Section 3.3.10.13 of [RFC4960]).
送信者がサポートされていない組み合わせを送信する場合、受信者は[RFC4960]のセクション3.3.10.13で定義されているように、プロトコル違反の原因でエラーチャンクを送信する必要があります。
This section defines the new parameter types that will be used in the RE-CONFIG chunk. Table 2 illustrates the new parameter types.
このセクションでは、ReConfig Chunkで使用される新しいパラメータータイプを定義します。表2に、新しいパラメータータイプを示しています。
+----------------+----------------------------------------+
| Parameter Type | Parameter Name |
+----------------+----------------------------------------+
| 13 | Outgoing SSN Reset Request Parameter |
| 14 | Incoming SSN Reset Request Parameter |
| 15 | SSN/TSN Reset Request Parameter |
| 16 | Re-configuration Response Parameter |
| 17 | Add Outgoing Streams Request Parameter |
| 18 | Add Incoming Streams Request Parameter |
+----------------+----------------------------------------+
Table 2
表2
It should be noted that the parameter format requires that the receiver stop processing the parameter and not process any further parameters within the chunk if the parameter type is not recognized. This is accomplished by the use of the upper bits of the parameter type as described in Section 3.2.1 of [RFC4960].
パラメーター形式では、受信機がパラメーターの処理を停止し、パラメータータイプが認識されない場合はチャンク内のパラメーターを処理しないことが必要であることに注意してください。これは、[RFC4960]のセクション3.2.1で説明されているように、パラメータータイプの上部ビットの使用によって達成されます。
All transported integer numbers are in "network byte order", a.k.a. Big Endian.
輸送されたすべての整数数は、「ネットワークバイトの順序」、別名ビッグエンディアンです。
This parameter is used by the sender to request the reset of some or all outgoing streams.
このパラメーターは、送信者によって使用され、一部またはすべての発信ストリームのリセットを要求します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 13 | Parameter Length = 16 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Last Assigned TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the Outgoing SSN Reset Request Parameter. The value of this field is 13.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、発信SSNリセットリクエストパラメーターのIANA定義パラメータータイプが保持されます。このフィールドの値は13です。
Parameter Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 16 + 2 * N, where N is the number of stream numbers listed.
パラメーターの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。値は16 2 * nでなければなりません。ここで、nはリストされているストリーム数の数です。
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the initial TSN. It is increased by 1 whenever sending a new Re-configuration Request Parameter.
再構成要求シーケンス番号：4バイト（符号なし整数）このフィールドは、リクエストを識別するために使用されます。これは、初期のTSNと同じ値に初期化される単調に増加する数値です。新しい再構成要求パラメーターを送信するたびに、1増加します。
Re-configuration Response Sequence Number: 4 bytes (unsigned integer) When this Outgoing SSN Reset Request Parameter is sent in response to an Incoming SSN Reset Request Parameter, this parameter is also an implicit response to the incoming request. This field then holds the Re-configuration Request Sequence Number of the incoming request. In other cases, it holds the next expected Re-configuration Request Sequence Number minus 1.
再構成応答シーケンス番号：4バイト（符号なし整数）この発信SSNリセット要求パラメーターが、着信SSNリセット要求パラメーターに応じて送信される場合、このパラメーターは着信要求に対する暗黙的な応答でもあります。このフィールドは、着信要求の再構成要求シーケンス番号を保持します。それ以外の場合、次に予想される再構成要求シーケンス番号をマイナス1を保持します。
Sender's Last Assigned TSN: 4 bytes (unsigned integer) This value holds the next TSN minus 1 -- in other words, the last TSN that this sender assigned.
送信者の最後に割り当てられたTSN：4バイト（符号なし整数）この値は、次のTSNマイナス1、つまりこの送信者が割り当てた最後のTSNを保持します。
Stream Number 1..N: 2 bytes (unsigned integer) This optional field, if included, is used to indicate specific streams that are to be reset. If no streams are listed, then all streams are to be reset.
ストリーム番号1..N：2バイト（符号なし整数）このオプションフィールドは、含まれている場合は、リセットされる特定のストリームを示すために使用されます。ストリームがリストされていない場合、すべてのストリームをリセットする必要があります。
This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクで表示できます。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This parameter is used by the sender to request that the peer reset some or all of its outgoing streams.
このパラメーターは、送信者がピアがその発信ストリームの一部またはすべてをリセットするように要求するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 14 | Parameter Length = 8 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the Incoming SSN Reset Request Parameter. The value of this field is 14.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、着信SSNリセットリクエストパラメーターのIANA定義パラメータータイプが保持されます。このフィールドの値は14です。
Parameter Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 8 + 2 * N.
パラメーターの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。値は8 2 * nでなければなりません。
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the initial TSN. It is increased by 1 whenever sending a new Re-configuration Request Parameter.
再構成要求シーケンス番号：4バイト（符号なし整数）このフィールドは、リクエストを識別するために使用されます。これは、初期のTSNと同じ値に初期化される単調に増加する数値です。新しい再構成要求パラメーターを送信するたびに、1増加します。
Stream Number 1..N: 2 bytes (unsigned integer) This optional field, if included, is used to indicate specific streams that are to be reset. If no streams are listed, then all streams are to be reset.
ストリーム番号1..N：2バイト（符号なし整数）このオプションフィールドは、含まれている場合は、リセットされる特定のストリームを示すために使用されます。ストリームがリストされていない場合、すべてのストリームをリセットする必要があります。
This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクで表示できます。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This parameter is used by the sender to request a reset of the TSN and SSN numbering of all incoming and outgoing streams.
このパラメーターは、送信者によって使用され、すべての受信および発信ストリームのTSNおよびSSN番号のリセットを要求します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 15 | Parameter Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the SSN/TSN Reset Request Parameter. The value of this field is 15.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、SSN/TSNリセット要求パラメーターのIANA定義パラメータータイプが保持されます。このフィールドの値は15です。
Parameter Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 8.
パラメーターの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。値は8でなければなりません。
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the initial TSN. It is increased by 1 whenever sending a new Re-configuration Request Parameter.
再構成要求シーケンス番号：4バイト（符号なし整数）このフィールドは、リクエストを識別するために使用されます。これは、初期のTSNと同じ値に初期化される単調に増加する数値です。新しい再構成要求パラメーターを送信するたびに、1増加します。
This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクで表示できます。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This parameter is used by the receiver of a Re-configuration Request Parameter to respond to the request.
このパラメーターは、リクエストに応答するために、再構成要求パラメーターの受信者によって使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 16 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the Re-configuration Response Parameter. The value of this field is 16.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、再構成応答パラメーターのIANA定義のパラメータータイプが保持されます。このフィールドの値は16です。
Parameter Type Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 12 if the optional fields are not present and 20 otherwise.
パラメータータイプの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。オプションのフィールドが存在しない場合は、値は12でなければならず、それ以外の場合は20でなければなりません。
Re-configuration Response Sequence Number: 4 bytes (unsigned integer) This value is copied from the request parameter and is used by the receiver of the Re-configuration Response Parameter to tie the response to the request.
再構成応答シーケンス番号：4バイト（unsigned Integer）この値はリクエストパラメーターからコピーされ、再構成応答パラメーターの受信者によって使用され、応答を要求に結びます。
Result: 4 bytes (unsigned integer) This value describes the result of the processing of the request. It is encoded as indicated in Table 3:
結果：4バイト（符号なし整数）この値は、リクエストの処理の結果を説明しています。表3に示すようにエンコードされています。
+--------+-------------------------------------+
| Result | Description |
+--------+-------------------------------------+
| 0 | Success - Nothing to do |
| 1 | Success - Performed |
| 2 | Denied |
| 3 | Error - Wrong SSN |
| 4 | Error - Request already in progress |
| 5 | Error - Bad Sequence Number |
| 6 | In progress |
+--------+-------------------------------------+
Table 3
表3
Sender's Next TSN: 4 bytes (unsigned integer) This field holds the TSN that the sender of the response will use to send the next DATA chunk. The field is only applicable in responses to SSN/TSN reset requests.
送信者の次のTSN：4バイト（符号なし整数）このフィールドは、応答の送信者が次のデータチャンクを送信するために使用するTSNを保持します。このフィールドは、SSN/TSNリセットリクエストへの応答にのみ適用されます。
Receiver's Next TSN: 4 bytes (unsigned integer) This field holds the TSN that the receiver of the response must use to send the next DATA chunk. The field is only applicable in responses to SSN/TSN reset requests.
受信者の次のTSN：4バイト（符号なし整数）このフィールドは、応答の受信機が次のデータチャンクを送信するために使用する必要があるTSNを保持します。このフィールドは、SSN/TSNリセットリクエストへの応答にのみ適用されます。
Either both optional fields (Sender's Next TSN and Receiver's Next TSN) MUST be present, or no field.
両方のオプションフィールド（送信者の次のTSNとレシーバーの次のTSN）は、フィールドが存在する必要があります。
This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクで表示できます。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This parameter is used by the sender to request that an additional number of outgoing streams (i.e., the receiver's incoming streams) be added to the association.
このパラメーターは、送信者によって使用され、追加の数の発信ストリーム（つまり、受信者の着信ストリーム）をアソシエーションに追加することを要求します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 17 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the Add Outgoing Streams Request Parameter. The value of this field is 17.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、Add Outging StreamsリクエストパラメーターのIANA定義パラメータータイプが保持されます。このフィールドの値は17です。
Parameter Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 12.
パラメーターの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。値は12でなければなりません。
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the initial TSN. It is increased by 1 whenever sending a new Re-configuration Request Parameter.
再構成要求シーケンス番号：4バイト（符号なし整数）このフィールドは、リクエストを識別するために使用されます。これは、初期のTSNと同じ値に初期化される単調に増加する数値です。新しい再構成要求パラメーターを送信するたびに、1増加します。
Number of new streams: 2 bytes (unsigned integer) This value holds the number of additional outgoing streams that the sender requests be added to the association. Streams are added in order and are consecutive; e.g., if an association has 4 outgoing streams (0-3) and a request is made to add 3 streams, then the new streams will be 4, 5, and 6.
新しいストリームの数：2バイト（符号なし整数）この値は、送信者がリクエストする追加の発信ストリームの数を協会に追加します。ストリームは順番に追加され、連続しています。たとえば、協会に4つの発信ストリーム（0-3）があり、3つのストリームを追加するようにリクエストが行われた場合、新しいストリームは4、5、および6になります。
Reserved: 2 bytes (unsigned integer) This field is reserved. It SHOULD be set to 0 by the sender and ignored by the receiver.
予約済み：2バイト（符号なし整数）このフィールドは予約されています。送信者によって0に設定され、受信機によって無視される必要があります。
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクに表示される場合があります。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This parameter is used by the sender to request that the peer add an additional number of outgoing streams (i.e., the sender's incoming streams) to the association.
このパラメーターは、送信者によって使用され、ピアがアソシエーションに追加の数の発信ストリーム（つまり、送信者の着信ストリーム）を追加することを要求します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 18 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) This field holds the IANA-defined parameter type for the Add Incoming Streams Request Parameter. The value of this field is 18.
パラメータータイプ：2バイト（符号なし整数）このフィールドには、ADD受信ストリーム要求パラメーターのIANA定義パラメータータイプが保持されます。このフィールドの値は18です。
Parameter Length: 2 bytes (unsigned integer) This field holds the length in bytes of the parameter; the value MUST be 12.
パラメーターの長さ：2バイト（符号なし整数）このフィールドは、パラメーターのバイトの長さを保持します。値は12でなければなりません。
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the initial TSN. It is increased by 1 whenever sending a new Re-configuration Request Parameter.
再構成要求シーケンス番号：4バイト（符号なし整数）このフィールドは、リクエストを識別するために使用されます。これは、初期のTSNと同じ値に初期化される単調に増加する数値です。新しい再構成要求パラメーターを送信するたびに、1増加します。
Number of new streams: 2 bytes (unsigned integer) This value holds the number of additional incoming streams that the sender requests be added to the association. Streams are added in order and are consecutive; e.g., if an association has 4 outgoing streams (0-3) and a request is made to add 3 streams, then the new streams will be 4, 5, and 6.
新しいストリームの数：2バイト（符号なし整数）この値には、送信者がリクエストする追加の入力ストリームの数が協会に追加されます。ストリームは順番に追加され、連続しています。たとえば、協会に4つの発信ストリーム（0-3）があり、3つのストリームを追加するようにリクエストが行われた場合、新しいストリームは4、5、および6になります。
Reserved: 2 bytes (unsigned integer) This field is reserved. It SHOULD be set to 0 by the sender and ignored by the receiver.
予約済み：2バイト（符号なし整数）このフィールドは予約されています。送信者によって0に設定され、受信機によって無視される必要があります。
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type.
このパラメーターは、reconfigチャンクに表示される場合があります。このパラメーターは、他のチャンクタイプで表示されてはなりません。
This section defines the procedures used by both the sender and receiver of a RE-CONFIG chunk. Various examples of re-configuration scenarios are given in Appendix A.
このセクションでは、ReConfig Chunkの送信者と受信者の両方が使用する手順を定義します。再構成シナリオのさまざまな例は、付録Aに記載されています。
One important thing to remember about SCTP streams is that they are uni-directional and there is no correspondence between outgoing and incoming streams. The procedures outlined in this section are designed so that the incoming side will always reset its SSN first (before the outgoing side), which means the re-configuration request must always originate from the outgoing side. These two issues have important ramifications upon how an SCTP endpoint might request that its incoming streams be reset. In effect, it must ask the peer to start an outgoing reset procedure and once that request is acknowledged let the peer actually control the reset operation.
SCTPストリームについて覚えておくべき重要なことの1つは、それらが一方向であり、発信ストリームと着信ストリームの間に対応がないことです。このセクションで概説されている手順は、着信側が常にSSNを最初にリセットするように設計されています（発信側の前）。つまり、再構成要求は常に発信側から発生する必要があります。これらの2つの問題は、SCTPエンドポイントが着信ストリームをリセットすることを要求する方法について重要な影響を及ぼします。実際には、ピアに発信リセット手順を起動するように依頼する必要があり、そのリクエストが確認されたら、ピアが実際にリセット操作を制御できます。
This section describes the procedures related to the sending of RE-CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type-Length-Value (TLV) parameters.
このセクションでは、ReConfigチャンクの送信に関連する手順について説明します。ReConfigチャンクは、1つまたは2つのタイプ長値（TLV）パラメーターで構成されています。
The SCTP protocol extension described in this document uses the Supported Extensions Parameter defined in [RFC5061] for negotiating the support.
このドキュメントで説明されているSCTPプロトコル拡張は、サポートを交渉するために[RFC5061]で定義されたサポートされている拡張機能パラメーターを使用します。
An SCTP endpoint supporting this extension MUST include the chunk type of the RE-CONFIG chunk in the Supported Extensions Parameter in either the INIT or INIT-ACK. Before sending a RE-CONFIG chunk, the sender MUST ensure that the peer advertised support for the re-configuration extension. If the chunk type of the RE-CONFIG chunk does not appear in the supported extension's list of chunks, then the sender MUST NOT send any re-configuration request to the peer, and any request by the application for such service SHOULD be responded to with an appropriate error indicating that the peer SCTP stack does not support the re-configuration extension.
この拡張機能をサポートするSCTPエンドポイントには、initまたはinit-ackのサポートされている拡張機能パラメーターに、reconfigチャンクのチャンクタイプを含める必要があります。再構成チャンクを送信する前に、送信者はピアが再構成拡張のサポートを宣伝したことを確認する必要があります。ReConfig Chunkのチャンクタイプがサポートされている拡張機能のチャンクリストに表示されない場合、送信者は再構成要求をピアに送信してはなりません。ピアSCTPスタックが再構成拡張をサポートしていないことを示す適切なエラー。
At any given time, there MUST NOT be more than one request in flight. So, if the Re-configuration Timer is running and the RE-CONFIG chunk contains at least one request parameter, the chunk MUST be buffered.
いつでも、飛行中に複数のリクエストが必要であってはなりません。したがって、再構成タイマーが実行されており、再構成チャンクに少なくとも1つの要求パラメーターが含まれている場合、チャンクをバッファリングする必要があります。
After packaging the RE-CONFIG chunk and sending it to the peer, the sender MUST start the Re-configuration Timer if the RE-CONFIG chunk contains at least one request parameter. If it contains no request parameters, the Re-configuration Timer MUST NOT be started. This
ReConfig Chunkをパッケージ化してピアに送信した後、ReConfig Chunkに少なくとも1つの要求パラメーターが含まれている場合、送信者は再構成タイマーを起動する必要があります。要求パラメーターが含まれていない場合、再構成タイマーを開始する必要はありません。これ
timer MUST use the same value as SCTP's data transmission timer (i.e., the retransmission timeout (RTO) timer) and MUST use exponential backoff, doubling the value at every expiration. If the timer expires, besides doubling the value, the sender MUST retransmit the RE-CONFIG chunk, increment the appropriate error counts (for both the association and the destination), and perform threshold management, possibly destroying the association if SCTP retransmission thresholds are exceeded.
タイマーは、SCTPのデータ送信タイマー（つまり、再送信タイムアウト（RTO）タイマー）と同じ値を使用し、指数バックオフを使用して、有効期限ごとに値を2倍にする必要があります。タイマーの有効期限が切れている場合、値を2倍にすることに加えて、送信者は再構成チャンクを再送信し、適切なエラーカウント（関連性と目的地の両方）を増やし、しきい値管理を実行し、SCTPの再送信のしきい値を超えた場合、関連性を破壊する可能性があります。。
5.1.2. Sender-Side Procedures for the Outgoing SSN Reset Request Parameter
5.1.2. 発信SSNリセットリクエストパラメーターの送信者側の手順
When an SCTP sender wants to reset the SSNs of some or all outgoing streams, it can send an Outgoing SSN Reset Request Parameter, provided that the Re-configuration Timer is not running. The following steps must be followed:
SCTP送信者が、一部またはすべての発信ストリームのSSNをリセットする場合、再構成タイマーが実行されていない場合、発信SSNリセットリクエストパラメーターを送信できます。次の手順に従う必要があります。
A1: The sender MUST stop assigning new SSNs to new user data provided by the upper layer for the affected streams and queue it. This is because it is not known whether the receiver of the request will accept or deny it; moreover, a lost request might cause an out-of-sequence error in a stream that the receiver is not yet prepared to handle.
A1：送信者は、影響を受けるストリームの上層層によって提供される新しいユーザーデータへの新しいSSNSの割り当てを停止する必要があります。これは、リクエストの受信者がそれを受け入れるか拒否するかどうかは不明だからです。さらに、リクエストの紛失は、レシーバーがまだ処理する準備ができていないストリームに順序外エラーを引き起こす可能性があります。
A2: The sender MUST assign the next re-configuration request sequence number and MUST put it into the Re-configuration Request Sequence Number field of the Outgoing SSN Reset Request Parameter. The next re-configuration request sequence number MUST then be incremented by 1.
A2：送信者は、次の再構成要求シーケンス番号を割り当て、発信SSNリセットリクエストパラメーターの再構成要求シーケンス番号フィールドに配置する必要があります。次の再構成要求シーケンス番号は、1で増分する必要があります。
A3: The Sender's Last Assigned TSN MUST be set to the next TSN the sender assigns minus 1.
A3：送信者の最後に割り当てられたTSNは、次のTSNに設定する必要があります。送信者はマイナス1を割り当てます。
A4: If this Outgoing SSN Reset Request Parameter is sent in response to an Incoming SSN Reset Request Parameter, the stream numbers MUST be copied from the Incoming SSN Reset Request Parameter to the Outgoing SSN Reset Request Parameter. The Re-configuration Response Sequence Number of the Outgoing SSN Reset Request Parameter MUST be the Re-configuration Request Sequence Number of the Incoming SSN Reset Request Parameter. If this Outgoing SSN Reset Request Parameter is sent at the request of the upper layer and the sender requests that all outgoing streams be reset, stream numbers SHOULD NOT be put into the Outgoing SSN Reset Request Parameter. If the sender requests that only some outgoing streams be reset, these stream numbers MUST be placed in the Outgoing SSN Reset Request Parameter. The Re-configuration Response Sequence Number is the next expected Re-configuration Request Sequence Number of the peer minus 1.
A4：この発信SSNリセット要求パラメーターが、着信SSNリセットリクエストパラメーターに応じて送信された場合、ストリーム番号を発信SSNリセットリクエストパラメーターに着信SSNリセットリクエストパラメーターからコピーする必要があります。発信SSNリセットリクエストパラメーターの再構成応答シーケンス番号は、着信SSNリセット要求パラメーターの再構成要求シーケンス番号である必要があります。この発信SSNリセット要求パラメーターが上層の要求に応じて送信され、送信者がすべての発信ストリームをリセットすることを要求する場合、ストリーム番号を発信SSNリセットリクエストパラメーターに入れてはなりません。送信者が一部の発信ストリームのみをリセットすることを要求する場合、これらのストリーム番号は発信SSNリセットリクエストパラメーターに配置する必要があります。再構成応答シーケンス番号は、ピアマイナス1の次の予想される再構成要求シーケンス番号です。
A5: The Outgoing SSN Reset Request Parameter MUST be put into a RE-CONFIG Chunk. The Outgoing SSN Reset Request Parameter MAY be put together with either an Incoming SSN Reset Request Parameter or a Re-configuration Response Parameter, but not with both. It MUST NOT be put together with any other parameter, as described in Section 3.1.
A5：発信SSNリセットリクエストパラメーターは、ReConfigチャンクに配置する必要があります。発信SSNリセットリクエストパラメーターは、着信SSNリセットリクエストパラメーターまたは再構成応答パラメーターのいずれかとまとめられますが、両方ではまとめられません。セクション3.1で説明されているように、他のパラメーターとまとめてはなりません。
A6: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
A6：セクション5.1.1に記載されているルールに従って、reconfigチャンクを送信する必要があります。
5.1.3. Sender-Side Procedures for the Incoming SSN Reset Request Parameter
5.1.3. 着信SSNリセットリクエストパラメーターの送信者側の手順
When an SCTP sender wants to reset the SSNs of some or all incoming streams, it can send an Incoming SSN Reset Request Parameter, provided that the Re-configuration Timer is not running. The following steps must be followed:
SCTP送信者が、一部またはすべての着信ストリームのSSNをリセットしたい場合、再構成タイマーが実行されていない場合、着信SSNリセットリクエストパラメーターを送信できます。次の手順に従う必要があります。
B1: The sender MUST assign the next re-configuration request sequence number and MUST put it into the Re-configuration Request Sequence Number field of the Incoming SSN Reset Request Parameter. After assigning it, the next re-configuration request sequence number MUST be incremented by 1.
B1：送信者は、次の再構成要求シーケンス番号を割り当て、着信SSNリセットリクエストパラメーターの再構成要求シーケンス番号フィールドに配置する必要があります。それを割り当てた後、次の再構成要求シーケンス番号は1で増加する必要があります。
B2: If the sender wants all incoming streams to be reset, stream numbers SHOULD NOT be put into the Incoming SSN Reset Request Parameter. If the sender wants only some incoming streams to be reset, these stream numbers MUST be filled in the Incoming SSN Reset Request Parameter.
B2：送信者がすべての着信ストリームのリセットを望んでいる場合、ストリーム番号を着信SSNリセット要求パラメーターに入れないでください。送信者がいくつかの着信ストリームのみをリセットする必要がある場合、これらのストリーム番号は、着信SSNリセットリクエストパラメーターで入力する必要があります。
B3: The Incoming SSN Reset Request Parameter MUST be put into a RE-CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset Request Parameter but MUST NOT be put together with any other parameter.
B3：着信SSNリセットリクエストパラメーターは、ReConfigチャンクに配置する必要があります。発信SSNリセットリクエストパラメーターとまとめられる場合がありますが、他のパラメーターとまとめてはなりません。
B4: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
B4：セクション5.1.1に記載されているルールに従って、reconfigチャンクを送信する必要があります。
When sending an Incoming SSN Reset Request, there is a potential that the peer has just reset or is in the process of resetting the same streams via an Outgoing SSN Reset Request. This collision scenario is discussed in Section 5.2.3.
着信SSNリセットリクエストを送信する場合、ピアがリセットしたばかりの可能性があります。この衝突シナリオについては、セクション5.2.3で説明します。
When an SCTP sender wants to reset the SSNs and TSNs, it can send an SSN/TSN Reset Request Parameter, provided that the Re-configuration Timer is not running. The following steps must be followed:
SCTP送信者がSSNSとTSNをリセットする場合、再構成タイマーが実行されていない場合、SSN/TSNリセットリクエストパラメーターを送信できます。次の手順に従う必要があります。
C1: The sender MUST assign the next re-configuration request sequence number and put it into the Re-configuration Request Sequence Number field of the SSN/TSN Reset Request Parameter. After assigning it, the next re-configuration request sequence number MUST be incremented by 1.
C1：送信者は、次の再構成要求シーケンス番号を割り当て、SSN/TSNリセットリクエストパラメーターの再構成要求シーケンス番号フィールドに配置する必要があります。それを割り当てた後、次の再構成要求シーケンス番号は1で増加する必要があります。
C2: The sender has either no outstanding TSNs or considers all outstanding TSNs abandoned. The sender MUST queue any user data, suspending any new transmissions and TSN assignment until the reset procedure is finished by the peer either acknowledging or denying the request.
C2：送信者は、未解決のTSNSを持っていないか、放棄されたすべての未解決のTSNを考慮しています。送信者は、ユーザーデータをキューにし、リセット手順が完了するまで、新しい送信とTSN割り当てを一時停止する必要があります。
C3: The SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG chunk. There MUST NOT be any other parameter in this chunk.
C3：SSN/TSNリセットリクエストパラメーターは、ReConfigチャンクに配置する必要があります。このチャンクには他のパラメーターがあってはなりません。
C4: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
C4：セクション5.1.1に記載されているルールに従って、reconfigチャンクを送信する必要があります。
Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, which is considered a maximum segment lifetime (the IP MSL).
30秒以内にSSN/TSNリセットリクエストを1つだけ送信する必要があります。これは、最大セグメント寿命（IP MSL）と見なされます。
5.1.5. Sender-Side Procedures for the Add Outgoing Streams Request Parameter
5.1.5. Add Outvering Streamsリクエストパラメーターの送信者側の手順
When an SCTP sender wants to increase the number of outbound streams to which it is able to send, it may add an Add Outgoing Streams Request Parameter to the RE-CONFIG chunk. Upon sending the request, the sender MUST await a positive acknowledgment (Success) before using any additional stream added by this request. Note that new streams are added adjacent to the previous streams with no gaps. This means that if a request is made to add 2 streams to an association that already has 5 (0-4), then the new streams, upon successful completion, are streams 5 and 6. A new stream MUST use SSN 0 for its first ordered message.
SCTP送信者が送信できるアウトバウンドストリームの数を増やしたい場合、ReConfigチャンクにAdd Outinging Requestパラメーターを追加する場合があります。リクエストを送信すると、送信者は、このリクエストによって追加された追加のストリームを使用する前に、肯定的な承認（成功）を待たなければなりません。ギャップなしで以前のストリームに隣接する新しいストリームが追加されていることに注意してください。これは、すでに5（0-4）を持つ関連付けに2つのストリームを追加するようにリクエストが作成された場合、新しいストリームは、正常に完了すると、ストリーム5および6であることを意味します。新しいストリームは、最初のSSN 0を使用する必要があります。注文メッセージ。
5.1.6. Sender-Side Procedures for the Add Incoming Streams Request Parameter
5.1.6. ADD受信ストリーム要求パラメーターの送信者側の手順
When an SCTP sender wants to increase the number of inbound streams to which the peer is able to send, it may add an Add Incoming Streams Request Parameter to the RE-CONFIG chunk. Note that new streams are added adjacent to the previous streams with no gaps. This means that
SCTP送信者が、ピアが送信できるインバウンドストリームの数を増やしたい場合、ReConfig ChunkにADD加入ストリーム要求パラメーターを追加する場合があります。ギャップなしで以前のストリームに隣接する新しいストリームが追加されていることに注意してください。この意味は
if a request is made to add 2 streams to an association that already has 5 (0-4), then the new streams, upon successful completion, are streams 5 and 6. A new stream MUST use SSN 0 for its first ordered message.
すでに5（0-4）を持つ関連付けに2つのストリームを追加するようにリクエストが行われた場合、新しいストリームは、正常に完了すると、ストリーム5および6です。新しいストリームは、最初の注文メッセージにSSN 0を使用する必要があります。
5.1.7. Sender-Side Procedures for the Re-configuration Response Parameter
5.1.7. 再構成応答パラメーターの送信者側の手順
When an implementation receives a reset request parameter, it must respond with a Re-configuration Response Parameter in the following manner:
実装がリセットリクエストパラメーターを受信した場合、次の方法で再構成応答パラメーターで応答する必要があります。
D1: The Re-configuration Request Sequence number of the incoming request MUST be copied to the Re-configuration Response Sequence Number field of the Re-configuration Response Parameter.
D1：再構成要求シーケンス着信要求の番号は、再構成応答シーケンス番号フィールドにコピーする必要があります。
D2: The result of the processing of the incoming request according to Table 3 MUST be placed in the Result field of the Re-configuration Response Parameter.
D2：表3に従って着信要求の処理の結果は、再構成応答パラメーターの結果フィールドに配置する必要があります。
D3: If the incoming request is an SSN/TSN reset request, the Sender's Next TSN field MUST be filled with the next TSN the sender of this Re-configuration Response Parameter will assign. For other requests, the Sender's Next TSN field, which is optional, MUST NOT be used.
D3：着信要求がSSN/TSNリセット要求である場合、送信者の次のTSNフィールドは次のTSNで満たされなければなりません。他のリクエストの場合、オプションである送信者の次のTSNフィールドは使用してはなりません。
D4: If the incoming request is an SSN/TSN reset request, the Receiver's Next TSN field MUST be filled with a TSN such that the sender of the Re-configuration Response Parameter can be sure it can discard received DATA chunks with smaller TSNs. The value SHOULD be the smallest TSN not acknowledged by the receiver of the request plus 2^31. For other requests, the Receiver's Next TSN field, which is optional, MUST NOT be used.
D4：着信要求がSSN/TSNリセット要求である場合、Receverの次のTSNフィールドにTSNが満たされているため、再構成応答パラメーターの送信者は、受信したデータチャンクをより小さなTSNで破棄できることを確認できます。値は、リクエストの受信者と2^31の受信者によって認められない最小のTSNでなければなりません。他のリクエストの場合、オプションであるレシーバーの次のTSNフィールドを使用してはなりません。
Upon reception of a RE-CONFIG chunk, each parameter within it SHOULD be processed. If multiple parameters have to be returned, they MUST be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk contains at least one request parameter, a selective acknowledgment (SACK) chunk SHOULD be sent back and MAY be bundled with the RE-CONFIG chunk. If the received RE-CONFIG chunk contains at least one request and based on the analysis of the Re-configuration Request Sequence Numbers this is the last received RE-CONFIG chunk (i.e., a retransmission), the same RE-CONFIG chunk MUST to be sent back in response, as it was earlier.
再構成チャンクを受信すると、その中の各パラメーターを処理する必要があります。複数のパラメーターを返す必要がある場合、それらは1つのre_configチャンクに配置する必要があります。受信したReConfig Chunkに少なくとも1つの要求パラメーターが含まれている場合、選択的な確認（Sack）チャンクを送り返す必要があり、ReConfig Chunkにバンドルされる場合があります。受信したReConfig Chunkに少なくとも1つのリクエストが含まれており、再構成要求シーケンス番号の分析に基づいて、これが最後に受信したReConfigチャンク（つまり、再送信）である場合、同じReConfig Chunkは以前のように、それに応じて送り返されます。
The decision to deny a re-configuration request is an administrative decision and may be user configurable even after the association has formed. If for whatever reason the endpoint does not wish to process a received request parameter, it MUST send a corresponding response parameter as described in Section 5.1.7, with an appropriate Result field.
再構成要求を拒否する決定は管理上の決定であり、協会が設立された後でもユーザー構成可能である可能性があります。何らかの理由でエンドポイントが受信要求パラメーターを処理することを希望しない場合、適切な結果フィールドを使用して、セクション5.1.7で説明されているように対応する応答パラメーターを送信する必要があります。
Implementation Note: It is recommended that a SACK be bundled with any re-configuration response so that any retransmission processing that needs to occur can be expedited. A SACK chunk is not required for this feature to work, but it will in effect help minimize the delay in completing a re-configuration operation in the face of any data loss.
実装注：再構成の応答に袋をバンドルすることをお勧めします。そうすれば、発生する必要がある再送信処理を迅速化できるようにします。この機能が機能するにはサックチャンクは必要ありませんが、実際には、データの損失に直面して再構成操作の完了の遅延を最小限に抑えるのに役立ちます。
5.2.2. Receiver-Side Procedures for the Outgoing SSN Reset Request Parameter
5.2.2. 発信SSNリセットリクエストパラメーターのレシーバー側の手順
In the case that the endpoint is willing to perform a stream reset, the following steps must be followed:
エンドポイントがストリームリセットを喜んで実行する場合、次の手順に従う必要があります。
E1: If the Re-configuration Timer is running for the Re-configuration Request Sequence Number indicated in the Re-configuration Response Sequence Number field, the Re-configuration Request Sequence Number MUST be marked as acknowledged. If all Re-configuration Request Sequence Numbers for which the Re-configuration Timer is running are acknowledged, the Re-configuration Timer MUST be stopped.
E1：再構成タイマーが再構成要求シーケンス番号のために実行されている場合、再構成応答シーケンス番号フィールドに示されている場合、再構成要求シーケンス番号は確認されたとおりにマークする必要があります。再構成タイマーが実行されているすべての再構成要求シーケンス番号が認められている場合、再構成タイマーを停止する必要があります。
E2: If the Sender's Last Assigned TSN is greater than the cumulative acknowledgment point, then the endpoint MUST enter "deferred reset processing". In this mode, any data arriving with a TSN larger than the Sender's Last Assigned TSN for the affected stream(s) MUST be queued locally and held until the cumulative acknowledgment point reaches the Sender's Last Assigned TSN. When the cumulative acknowledgment point reaches the last assigned TSN, then proceed to the next step. If the endpoint enters "deferred reset processing", it MUST put a Re-configuration Response Parameter into a RE-CONFIG chunk indicating "In progress" and MUST send the RE-CONFIG chunk.
E2：送信者の最後に割り当てられたTSNが累積確認ポイントよりも大きい場合、エンドポイントは「繰延リセット処理」を入力する必要があります。このモードでは、影響を受けるストリームに対して送信者の最後に割り当てられたTSNよりも大きいTSNを使用して到着するデータは、ローカルでキューに入れられ、累積確認ポイントが送信者の最後の割り当てられたTSNに到達するまで保持する必要があります。累積確認ポイントが最後に割り当てられたTSNに到達したら、次のステップに進みます。エンドポイントが「繰延リセット処理」に入る場合、「進行中」を示す再構成応答パラメーターを再構成チャンクに入れ、再構成チャンクを送信する必要があります。
E3: If no stream numbers are listed in the parameter, then all incoming streams MUST be reset to 0 as the next expected SSN. If specific stream numbers are listed, then only these specific streams MUST be reset to 0, and all other non-listed SSNs remain unchanged.
E3：パラメーターにストリーム番号がリストされていない場合、次の予想SSNとして、すべての着信ストリームを0にリセットする必要があります。特定のストリーム番号がリストされている場合、これらの特定のストリームのみを0にリセットする必要があり、他のすべての非リストのSSNは変更されません。
E4: Any queued TSNs (queued at step E2) MUST now be released and processed normally.
E4：キューに囲まれたTSNS（ステップE2でキューに留められている）は、正常に解放され、処理する必要があります。
E5: A Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing.
E5：再構成応答パラメーターを再構成チャンクに入れて、成功した処理を示す必要があります。
E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
E6：reconfigチャンクは、着信再構成チャンクが完全に処理された後に送信する必要があります。
5.2.3. Receiver-Side Procedures for the Incoming SSN Reset Request Parameter
5.2.3. 着信SSNリセット要求パラメーターのレシーバー側の手順
In the case that the endpoint is willing to perform a stream reset, the following steps must be followed:
エンドポイントがストリームリセットを喜んで実行する場合、次の手順に従う必要があります。
F1: An Outgoing SSN Reset Request Parameter MUST be put into a RE-CONFIG chunk according to Section 5.1.2.
F1：発信SSNリセット要求パラメーターは、セクション5.1.2に従ってReConfigチャンクに配置する必要があります。
F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
F2：reconfigチャンクは、着信再構成チャンクが完全に処理された後に送信する必要があります。
When a peer endpoint requests an Incoming SSN Reset Request, it is possible that the local endpoint has just sent an Outgoing SSN Reset Request on the same association and has not yet received a response. In such a case, the local endpoint MUST do the following:
ピアエンドポイントが着信SSNリセットリクエストを要求すると、ローカルエンドポイントが同じ協会に発信SSNリセットリクエストを送信したばかりで、まだ応答を受け取っていない可能性があります。そのような場合、ローカルエンドポイントは次のことを行う必要があります。
o If the Outgoing SSN Reset Request Parameter that was just sent completely overlaps the received Incoming SSN Reset Request Parameter, respond to the peer with an acknowledgment indicating that there was "Nothing to do".
o 送信されたばかりの発信SSNリセット要求パラメーターが、受信した受信したSSNリセット要求パラメーターと完全に重複している場合、「何もすることがない」ことを示す確認書でピアに応答します。
o Otherwise, process the Incoming SSN Reset Request Parameter normally, responding to the peer with an acknowledgment. Note that this case includes the situation where some of the streams requested overlap with the Outgoing SSN Reset Request that was just sent. Even in such a situation, the Incoming SSN Reset MUST be processed normally, even though this means that (if the endpoint elects to do the stream reset) streams that are already at SSN 0 will be reset a subsequent time.
o それ以外の場合は、受信SSNリセット要求パラメーターを正常に処理し、承認を得てピアに応答します。このケースには、送信されたばかりのSSNリセットリクエストと重複するストリームの一部が含まれている状況が含まれていることに注意してください。このような状況でも、（エンドポイントがストリームリセットを選択する場合）すでにSSN 0にあるストリームがその後リセットされることを意味する場合でも、着信SSNリセットは正常に処理する必要があります。
It is also possible that the Incoming request will arrive after the Outgoing SSN Reset Request just completed. In such a case, all of the streams being requested will be already set to 0. If so, the local endpoint SHOULD send back a Re-configuration Response with the success code "Nothing to do".
また、発信されたSSNリセットリクエストが完了した後に着信要求が到着する可能性もあります。そのような場合、要求されるすべてのストリームはすでに0に設定されます。もしそうなら、ローカルエンドポイントは「何もすることはない」という成功コードで再構成応答を送り返す必要があります。
Note that in either race condition, the local endpoint could optionally also perform the reset. This would result in streams that are already at sequence 0 being reset again to 0, which would cause no harm to the application but will add an extra message to the network.
いずれかの人種状態では、ローカルエンドポイントはオプションでリセットを実行できることに注意してください。これにより、既にシーケンス0にあるストリームが0に再びリセットされ、アプリケーションに害がなくなりますが、ネットワークに追加のメッセージが追加されます。
In the case that the endpoint is willing to perform an SSN/TSN reset, the following steps must be followed:
エンドポイントがSSN/TSNリセットを喜んで実行する場合、次の手順に従う必要があります。
G1: Compute an appropriate value for the Receiver's Next TSN -- the TSN that the peer should use to send the next DATA chunk. The value SHOULD be the smallest TSN not acknowledged by the receiver of the request plus 2^31.
G1：受信者の次のTSN（ピアが次のデータチャンクを送信するために使用するTSN）に適切な値を計算します。値は、リクエストの受信者と2^31の受信者によって認められない最小のTSNでなければなりません。
G2: Compute an appropriate value for the local endpoint's next TSN, i.e., the next TSN assigned by the receiver of the SSN/TSN reset chunk. The value SHOULD be the highest TSN sent by the receiver of the request plus 1.
G2：ローカルエンドポイントの次のTSN、つまりSSN/TSNリセットチャンクの受信者によって割り当てられた次のTSNに適切な値を計算します。値は、リクエストの受信者から送信される最高のTSNと1でなければなりません。
G3: The same processing as though a SACK chunk with no gap report and a cumulative TSN ACK of the Sender's Next TSN minus 1 were received MUST be performed.
G3：ギャップレポートのないサックチャンクと送信者の次のTSNマイナス1の累積TSN ACKを受信したのと同じ処理を実行する必要があります。
G4: The same processing as though a FWD-TSN chunk (as defined in [RFC3758]) with all streams affected and a new cumulative TSN ACK of the Receiver's Next TSN minus 1 were received MUST be performed.
G4：すべてのストリームが影響を受けるFWD-TSNチャンク（[RFC3758]で定義されている）と同じ処理と、受信者の次のTSNマイナス1の新しい累積TSN ACKを受信する必要があります。
G5: The next expected and outgoing SSNs MUST be reset to 0 for all incoming and outgoing streams.
G5：次の予想されたSSNと発信SSNは、すべての受信および発信ストリームに対して0にリセットする必要があります。
G6: A Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing.
G6：再構成応答パラメーターを再構成チャンクに入れて、処理の成功を示す必要があります。
G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
G7：reconfigチャンクは、着信再構成チャンクが完全に処理された後に送信する必要があります。
5.2.5. Receiver-Side Procedures for the Add Outgoing Streams Request Parameter
5.2.5. Add Outvering Streamsリクエストパラメーターのレシーバー側の手順
When an SCTP endpoint receives a re-configuration request adding additional streams, it MUST send a response parameter either acknowledging or denying the request. If the response is successful, the receiver MUST add the requested number of inbound streams to the association, initializing the next expected SSN to 0. The SCTP endpoint SHOULD deny the request if the number of streams exceeds a limit that should be configurable by the application.
SCTPエンドポイントが再構成要求を受信して追加のストリームを追加する場合、リクエストを確認または拒否する応答パラメーターを送信する必要があります。応答が成功した場合、受信者は、リクエストされたインバウンドストリームの数をアソシエーションに追加する必要があり、次の予想SSNを0に初期化する必要があります。SCTPエンドポイントは、アプリケーションで構成できる制限を超えている場合、SCTPエンドポイントがリクエストを否定する必要があります。。
5.2.6. Receiver-Side Procedures for the Add Incoming Streams Request Parameter
5.2.6. ADD受信ストリーム要求パラメーターのレシーバー側の手順
When an SCTP endpoint receives a re-configuration request adding additional incoming streams, it MUST either send a response parameter denying the request or send a corresponding Add Outgoing Streams Request Parameter, following the rules given in Section 5.1.5. The SCTP endpoint SHOULD deny the request if the number of streams exceeds a limit that should be configurable by the application.
SCTPエンドポイントが再構成要求を受信する場合、追加の入力ストリームを追加する場合、セクション5.1.5に記載されているルールに従って、リクエストを拒否する応答パラメーターを送信するか、対応するADD OutingRiensリクエストパラメーターを送信する必要があります。SCTPエンドポイントは、アプリケーションによって構成可能な制限を超えている場合、要求を拒否する必要があります。
5.2.7. Receiver-Side Procedures for the Re-configuration Response Parameter
5.2.7. 再構成応答パラメーターのレシーバー側の手順
On receipt of a Re-configuration Response Parameter, the following must be performed:
再構成応答パラメーターを受け取ったら、以下を実行する必要があります。
H1: If the Re-configuration Timer is running for the Re-configuration Request Sequence Number indicated in the Re-configuration Response Sequence Number field, the Re-configuration Request Sequence Number MUST be marked as acknowledged. If all Re-configuration Request Sequence Numbers for which the Re-configuration Timer is running are acknowledged, the Re-configuration Timer MUST be stopped. If the timer was not running for the Re-configuration Request Sequence Number, the processing of the Re-configuration Response Parameter is complete.
H1：再構成タイマーが再構成要求シーケンス番号に対して実行されている場合、再構成応答シーケンス番号フィールドに示されている場合、再構成要求シーケンス番号は確認されたとおりにマークする必要があります。再構成タイマーが実行されているすべての再構成要求シーケンス番号が認められている場合、再構成タイマーを停止する必要があります。タイマーが再構成要求シーケンス番号のために実行されていない場合、再構成応答パラメーターの処理が完了します。
H2: If the Result field indicates "In progress", the timer for the Re-configuration Request Sequence Number is started again. If the timer runs out, the RE-CONFIG chunk MUST be retransmitted but the corresponding error counters MUST NOT be incremented.
H2：結果フィールドが「進行中」を示している場合、再構成要求シーケンス番号のタイマーが再び開始されます。タイマーが実行された場合、ReConfigチャンクを再送信する必要がありますが、対応するエラーカウンターをインクリメントする必要はありません。
H3: If the Result field does not indicate successful processing, the processing of this response is complete.
H3：結果フィールドが成功した処理を示していない場合、この応答の処理は完了します。
H4: If the request was an Outgoing SSN Reset Request, the affected streams MUST now be reset and all queued data should now be processed. The assigning of SSNs is allowed again.
H4：リクエストが発信SSNリセットリクエストである場合、影響を受けるストリームをリセットする必要があり、すべてのキュー化されたデータを処理する必要があります。SSNSの割り当ては再度許可されます。
H5: If the request was an SSN/TSN Reset Request, new data MUST be sent from the Receiver's Next TSN, beginning with SSN 0 for all outgoing streams. All incoming streams MUST be reset to 0 as the next expected SSN. The peer will send DATA chunks starting with the Sender's Next TSN.
H5：リクエストがSSN/TSNリセット要求である場合、すべての発信ストリームのSSN 0から始まるレシーバーの次のTSNから新しいデータを送信する必要があります。次の予想SSNとして、すべての着信ストリームを0にリセットする必要があります。ピアは、送信者の次のTSNからデータチャンクを送信します。
H6: If the request was to add outgoing streams, the endpoint MUST add the additional streams to the association. Note that an implementation may allocate the memory at the time of the request, but it MUST NOT use the streams until the peer has responded with a positive acknowledgment.
H6：リクエストが送信ストリームを追加する場合、エンドポイントはアソシエーションに追加のストリームを追加する必要があります。実装では、リクエストの時点でメモリを割り当てる場合がありますが、ピアが肯定的な承認で応答するまで、ストリームを使用しないでください。
This section describes how the sockets API defined in [RFC6458] needs to be extended to make the features of SCTP re-configuration available to the application.
このセクションでは、[RFC6458]で定義されているソケットAPIを拡張して、SCTP再構成の機能をアプリケーションで利用できるようにする方法について説明します。
Please note that this section is informational only.
このセクションは情報のみであることに注意してください。
When the SCTP_ASSOC_CHANGE notification is delivered and both peers support the extension described in this document, SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field.
sctp_assoc_change通知が配信され、両方のピアがこのドキュメントに記載されている拡張機能をサポートする場合、sctp_assoc_supports_re_configをsac_infoフィールドにリストする必要があります。
The union sctp_notification {} is extended to contain three new fields: sn_strreset_event, sn_assocreset_event, and sn_strchange_event:
ユニオンSCTP_NOTIFICATION {}は、3つの新しいフィールドを含むように拡張されます：SN_STRRESET_EVENT、SN_ASSOCRESET_EVENT、およびSN_STRCHANGE_EVENT：
union sctp_notification {
struct sctp_tlv {
uint16_t sn_type; /* Notification type. */
uint16_t sn_flags;
uint32_t sn_length;
} sn_header;
...
struct sctp_stream_reset_event sn_strreset_event;
struct sctp_assoc_reset_event sn_assocreset_event;
struct sctp_stream_change_event sn_strchange_event;
...
}
The corresponding sn_type values are given in Table 4.
対応するSN_TYPE値を表4に示します。
+--------------------------+----------------------------------------+
| sn_type | valid field in union sctp_notification |
+--------------------------+----------------------------------------+
| SCTP_STREAM_RESET_EVENT | sn_strreset_event |
| SCTP_ASSOC_RESET_EVENT | sn_assocreset_event |
| SCTP_STREAM_CHANGE_EVENT | sn_strchange_event |
+--------------------------+----------------------------------------+
Table 4
表4
These events are delivered when an incoming request was processed successfully or the processing of an outgoing request has been finished.
これらのイベントは、着信要求が正常に処理された場合、または発信要求の処理が終了したときに配信されます。
The event delivered has the following structure:
配信されるイベントには、次の構造があります。
struct sctp_stream_reset_event {
uint16_t strreset_type;
uint16_t strreset_flags;
uint32_t strreset_length;
sctp_assoc_t strreset_assoc_id;
uint16_t strreset_stream_list[];
};
strreset_type: This field should be SCTP_STREAM_RESET_EVENT.
strreset_type：このフィールドはsctp_stream_reset_eventである必要があります。
strreset_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
strreset_flags：このフィールドは、現在定義されているフラグの1つ以上から形成されます。
SCTP_STREAM_RESET_INCOMING_SSN: The stream identifiers given in strreset_stream_list[] refer to incoming streams of the endpoint.
sctp_stream_reset_incoming_ssn：strreset_stream_list []に与えられたストリーム識別子は、エンドポイントの入力ストリームを参照しています。
SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in strreset_stream_list[] refer to outgoing streams of the endpoint.
sctp_stream_reset_outvering_ssn：strreset_stream_list []で指定されたストリーム識別子は、エンドポイントの発信ストリームを参照しています。
SCTP_STREAM_RESET_DENIED: The corresponding request was denied by the peer.
sctp_stream_reset_denied：対応するリクエストはピアによって拒否されました。
SCTP_STREAM_RESET_FAILED: The corresponding request failed.
sctp_stream_reset_failed：対応するリクエストは失敗しました。
At least one of SCTP_STREAM_RESET_INCOMING_SSN and SCTP_STREAM_RESET_OUTGOING_SSN is set. SCTP_STREAM_RESET_DENIED and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the request was successful, none of these are set.
sctp_stream_reset_incoming_ssnおよびsctp_stream_reset_outving_ssnの少なくとも1つが設定されています。sctp_stream_reset_deniedおよびsctp_stream_reset_failedは相互に排他的です。リクエストが成功した場合、これらのいずれも設定されていません。
strreset_length: This field is the total length in bytes of the delivered event, including the header.
strreset_length：このフィールドは、ヘッダーを含む配信されたイベントのバイトの合計長さです。
strreset_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
strreset_assoc_id：この関連付けIDフィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。1対1のスタイルのソケットの場合、このフィールドは無視されます。
strreset_stream_list: This is the list of stream identifiers to which this event refers. An empty list identifies all streams as being reset. Depending on strreset_flags, the identifiers refer to incoming or outgoing streams, or both.
strreset_stream_list：これは、このイベントが参照するストリーム識別子のリストです。空のリストは、すべてのストリームがリセットされていることを識別します。strreset_flagsに応じて、識別子は着信または発信ストリーム、またはその両方を指します。
The event delivered has the following structure:
配信されるイベントには、次の構造があります。
struct sctp_assoc_reset_event {
uint16_t assocreset_type;
uint16_t assocreset_flags;
uint32_t assocreset_length;
sctp_assoc_t assocreset_assoc_id;
uint32_t assocreset_local_tsn;
uint32_t assocreset_remote_tsn;
};
assocreset_type: This field should be SCTP_ASSOC_RESET_EVENT.
assocreset_type：このフィールドはsctp_assoc_reset_eventである必要があります。
assocreset_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
assocreset_flags：このフィールドは、現在定義されているフラグの1つ以上から形成されます。
SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was denied by the peer.
sctp_assoc_reset_denied：対応する発信要求は、ピアによって拒否されました。
SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request failed.
sctp_assoc_reset_failed：対応する発信要求は失敗しました。
SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutually exclusive. If the request was successful, none of these are set.
sctp_assoc_reset_deniedおよびsctp_assoc_reset_failedは相互に排他的です。リクエストが成功した場合、これらのいずれも設定されていません。
assocreset_length: This field is the total length in bytes of the delivered event, including the header.
assocreset_length：このフィールドは、ヘッダーを含む配信されたイベントのバイトの合計長さです。
assocreset_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
assocreset_assoc_id：この関連付けIDフィールドは、協会の識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。1対1のスタイルのソケットの場合、このフィールドは無視されます。
assocreset_local_tsn: This field is the next TSN used by the endpoint.
assocreset_local_tsn：このフィールドは、エンドポイントで使用される次のTSNです。
assocreset_remote_tsn: This field is the next TSN used by the peer.
assocreset_remote_tsn：このフィールドは、ピアが使用する次のTSNです。
The event delivered has the following structure:
配信されるイベントには、次の構造があります。
struct sctp_stream_change_event {
uint16_t strchange_type;
uint16_t strchange_flags;
uint32_t strchange_length;
sctp_assoc_t strchange_assoc_id;
uint16_t strchange_instrms;
uint16_t strchange_outstrms;
};
strchange_type: This field should be SCTP_STREAM_CHANGE_EVENT.
strchange_type：このフィールドはsctp_stream_change_eventである必要があります。
strchange_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
strchange_flags：このフィールドは、現在定義されているフラグの1つ以上から形成されます。
SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied by the peer.
sctp_stream_change_denied：対応するリクエストはピアによって拒否されました。
SCTP_STREAM_CHANGE_FAILED: The corresponding request failed.
sctp_stream_change_failed：対応する要求に失敗しました。
SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutually exclusive. If the request was successful, none of these are set.
sctp_stream_change_deniedおよびsctp_stream_change_failedは相互に排他的です。リクエストが成功した場合、これらのいずれも設定されていません。
strchange_length: This field is the total length in bytes of the delivered event, including the header.
strchange_length：このフィールドは、ヘッダーを含む配信されたイベントのバイトの全長です。
strchange_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
strchange_assoc_id：この関連付けIDフィールドは、関連付けの識別子を保持します。特定の関連付けのすべての通知には、同じ関連付け識別子があります。1対1のスタイルのソケットの場合、このフィールドは無視されます。
strchange_instrms: The number of streams that the peer is allowed to use outbound.
strchange_instrms：ピアがアウトバウンドを使用することが許可されているストリームの数。
strchange_outstrms: The number of streams that the endpoint is allowed to use outbound.
strchange_outstrms：エンドポイントがアウトバウンドを使用できるストリームの数。
Subscribing to events as described in [RFC6458] uses a setsockopt() call with the SCTP_EVENT socket option. This option takes the following structure, which specifies the association, the event type (using the same value found in the event type field), and an on/off boolean.
[rfc6458]で説明されているイベントを購読すると、sctp_eventソケットオプションでsetsockopt（）コールが使用されます。このオプションは、アソシエーション、イベントタイプ（イベントタイプフィールドと同じ値を使用）を指定する次の構造、およびオン/オフブール値を指定します。
struct sctp_event {
sctp_assoc_t se_assoc_id;
uint16_t se_type;
uint8_t se_on;
};
The user fills in the se_type field with the same value found in the strreset_type field, i.e., SCTP_STREAM_RESET_EVENT. The user will also fill in the se_assoc_id field with either the association to set this event on (this field is ignored for one-to-one style sockets) or one of the reserved constant values defined in [RFC6458]. Finally, the se_on field is set with a 1 to enable the event or a 0 to disable the event.
ユーザーは、STRRESET_TYPEフィールド、つまりSCTP_STREAM_RESET_EVENTで見つかったのと同じ値でSE_Typeフィールドに記入します。また、ユーザーは、SE_Assoc_IDフィールドに、このイベントを設定するためのAssociation（このフィールドは1対1のスタイルのソケットでは無視されます）または[RFC6458]で定義されている予約済み定数値のいずれかを記入します。最後に、SE_ONフィールドは1で設定され、イベントを有効にするか、イベントを無効にします。
Table 5 describes the new socket options that make the re-configuration features accessible to the user. They all use IPPROTO_SCTP as their level.
表5に、再構成機能をユーザーがアクセスできるようにする新しいソケットオプションについて説明します。それらはすべて、IPPROTO_SCTPをレベルとして使用しています。
If a call to setsockopt() is used to issue a re-configuration request while the Re-configuration timer is running, setsockopt() will return -1, and error is set to EALREADY.
再構成タイマーが実行されている間に再構成要求を発行するためにSetSockopt（）への呼び出しを使用している場合、SetSockopt（）が-1を返し、エラーがEALReadyに設定されます。
+--------------------------+---------------------------+-----+-----+
| option name | data type | get | set |
+--------------------------+---------------------------+-----+-----+
| SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X |
| SCTP_RESET_STREAMS | struct sctp_reset_streams | | X |
| SCTP_RESET_ASSOC | sctp_assoc_t | | X |
| SCTP_ADD_STREAMS | struct sctp_add_streams | | X |
+--------------------------+---------------------------+-----+-----+
Table 5
表5
This option allows a user to control whether the SCTP implementation processes or denies incoming requests in STREAM_RESET chunks.
このオプションにより、ユーザーはSCTP実装がStream_resetチャンクで着信要求を処理するか拒否するかを制御できます。
The default is to deny all incoming requests.
デフォルトは、すべての着信リクエストを拒否することです。
To set or get this option, the user fills in the following structure:
このオプションを設定または取得するには、ユーザーは次の構造に記入します。
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 which association the user is performing an action upon.
ASSOC_ID：このパラメーターは、1対1のスタイルソケットでは無視されます。1対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。
assoc_value: This field is formed from the bitwise OR of one or more of the following currently defined flags:
assoc_value：このフィールドは、ビットワイズまたは現在定義されているフラグの1つ以上から形成されます。
SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing SSN Reset Requests if this flag is set; deny them if not.
SCTP_ENABLE_RESET_STREAM_REQ：このフラグが設定されている場合、受信/発信SSNリセットリクエストを受信しました。そうでない場合は拒否してください。
SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset Requests if this flag is set; deny them if not.
SCTP_ENABLE_RESET_ASSOC_REQ：プロセスこのフラグが設定されている場合、SSN/TSNリセットリクエストを受信しました。そうでない場合は拒否してください。
SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing Streams Requests if this flag is set; deny them if not.
sctp_enable_change_assoc_req：このフラグが設定されている場合、Process add outing streams requestsを受信します。そうでない場合は拒否してください。
The default value is !(SCTP_ENABLE_RESET_STREAM_REQ| SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ).
デフォルト値は！（sctp_enable_reset_stream_req | sctp_enable_reset_assoc_req | sctp_enable_change_assoc_req）です。
Please note that using the option does not have any impact on subscribing to any related events.
このオプションを使用しても、関連するイベントへの購読には影響しないことに注意してください。
This option allows the user to request the reset of incoming and/or outgoing streams.
このオプションにより、ユーザーは着信および/または発信ストリームのリセットを要求できます。
To set or get this option, the user fills in the following structure:
このオプションを設定または取得するには、ユーザーは次の構造に記入します。
struct sctp_reset_streams {
sctp_assoc_t srs_assoc_id;
uint16_t srs_flags;
uint16_t srs_number_streams;
uint16_t srs_stream_list[];
};
srs_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates which association the user is performing an action upon.
SRS_ASSOC_ID：このパラメーターは、1対1のスタイルソケットでは無視されます。1対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。
srs_flags: This parameter describes which class of streams is reset. It is formed from the bitwise OR of one or more of the following currently defined flags:
SRS_FLAGS：このパラメーターは、どのクラスのストリームがリセットされているかを説明します。これは、ビットワイズまたは現在定義されているフラグの1つ以上から形成されます。
* SCTP_STREAM_RESET_INCOMING
* sctp_stream_reset_incoming
* SCTP_STREAM_RESET_OUTGOING
* sctp_stream_reset_outovering
srs_number_streams: This parameter is the number of elements in the srs_stream_list. If it is zero, the operation is performed on all streams.
srs_number_streams：このパラメーターは、srs_stream_listの要素の数です。ゼロの場合、操作はすべてのストリームで実行されます。
srs_stream_list: This parameter contains a list of stream identifiers the operation is performed upon. It contains srs_number_streams elements. If it is empty, the operation is performed on all streams. Depending on srs_flags, the identifiers refer to incoming or outgoing streams, or both.
SRS_STREAM_LIST：このパラメーターには、操作が実行されるストリーム識別子のリストが含まれています。srs_number_streams要素が含まれています。空の場合、操作はすべてのストリームで実行されます。srs_flagsに応じて、識別子は着信または発信ストリーム、またはその両方を指します。
This option allows a user to request the reset of the SSN/TSN.
このオプションにより、ユーザーはSSN/TSNのリセットを要求できます。
To set this option, the user provides an option_value of type sctp_assoc_t.
このオプションを設定するには、ユーザーはsctp_assoc_tのタイプのoption_valueを提供します。
On one-to-one style sockets, the option_value is ignored. For one-to-many style sockets, the option_value is the association identifier of the association the action is to be performed upon.
1対1のスタイルのソケットでは、Option_Valueは無視されます。1対多スタイルのソケットの場合、option_valueは、アクションを実行することになります。
This option allows a user to request the addition of a number of incoming and/or outgoing streams.
このオプションにより、ユーザーは多くの着信および/または発信ストリームの追加を要求できます。
To set this option, the user fills in the following structure:
このオプションを設定するには、ユーザーが次の構造に記入します。
struct sctp_add_streams {
sctp_assoc_t sas_assoc_id;
uint16_t sas_instrms;
uint16_t sas_outstrms;
};
sas_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates which association the user is performing an action upon.
SAS_ASSOC_ID：このパラメーターは、1対1のスタイルソケットでは無視されます。1対多スタイルのソケットの場合、このパラメーターは、ユーザーがアクションを実行している関連付けを示します。
sas_instrms: This parameter is the number of incoming streams to add.
SAS_INSTRMS：このパラメーターは、追加する入力ストリームの数です。
sas_outstrms: This parameter is the number of outgoing streams to add.
sas_outstrms：このパラメーターは、追加する発信ストリームの数です。
An endpoint can limit the number of incoming and outgoing streams by using the sinit_max_instreams field in the struct sctp_initmsg{} when issuing an SCTP_INIT socket option, as defined in [RFC6458]. An incoming request asking for more streams than allowed will be denied.
エンドポイントは、[RFC6458]で定義されているように、SCTP_INITソケットオプションを発行するときに、struct sctp_initmsg {}のstruct sctp_initmsg {}のsinit_max_instreamsフィールドを使用することにより、着信ストリームと発信ストリームの数を制限できます。許可されているよりも多くのストリームを要求する受信リクエストは拒否されます。
The SCTP sockets API as described in [RFC6458] exposes the sequence numbers of received DATA chunks to the application. An application might expect them to be monotonically increasing. When using the re-configuration extension, this might no longer be true. Therefore, the applications must enable this extension explicitly before it is used. In addition, applications must subscribe explicitly to notifications related to the re-configuration extension before receiving them.
[RFC6458]で説明されているSCTPソケットAPIは、受信したデータチャンクのシーケンス番号をアプリケーションに公開します。アプリケーションは、それらが単調に増加することを期待するかもしれません。再構成拡張機能を使用する場合、これはもはや真実ではない可能性があります。したがって、アプリケーションは使用する前にこの拡張機能を明示的に有効にする必要があります。さらに、アプリケーションは、再構成拡張に関連する通知に明示的に購読する必要があります。
SCTP associations are protected against blind attackers by using verification tags. This is still valid when using the re-configuration extension. Therefore, this extension does not add any additional security risk to SCTP in relation to blind attackers.
SCTP関連は、検証タグを使用することにより、ブラインド攻撃者から保護されています。これは、再構成拡張機能を使用する場合でも有効です。したがって、この拡張機能は、ブラインド攻撃者に関連してSCTPに追加のセキュリティリスクを追加しません。
When both the SSN and TSN are reset, the maximum segment lifetime is used to avoid TSN wrap-around.
SSNとTSNの両方がリセットされると、TSNラップアラウンドを回避するために最大セグメント寿命が使用されます。
This document (RFC 6525) is the reference for all registrations described in this section. The changes are described below.
このドキュメント（RFC 6525）は、このセクションで説明されているすべての登録のリファレンスです。変更については、以下に説明します。
A chunk type has been assigned by IANA. The values given in Table 1 have been used. IANA has assigned this value from the pool of chunks with the upper two bits set to '10'.
チャンクタイプはIANAによって割り当てられています。表1に示されている値が使用されています。IANAは、この値をチャンクのプールから割り当て、上部2ビットを「10」に設定しています。
This has added a line in the "Chunk Types" registry for SCTP:
これにより、SCTPの「チャンクタイプ」レジストリに行が追加されました。
Chunk Types
チャンクタイプ
ID Value Chunk Type Reference
----- ---------- ---------
130 Re-configuration Chunk (RE-CONFIG) [RFC6525]
The registration table as defined in [RFC6096] for the chunk flags of this chunk type is empty.
このチャンクタイプのチャンクフラグの[RFC6096]で定義されている登録表は空です。
Six chunk parameter types have been assigned by IANA. It the values given in Table 2 have been used. IANA has assigned these values from the pool of parameters with the upper two bits set to '00'.
IANAによって6つのチャンクパラメータータイプが割り当てられています。表2に示されている値が使用されています。IANAは、これらの値をパラメーターのプールから割り当て、上部2ビットを「00」に設定しています。
Six additional lines in the "Chunk Parameter Types" registry for SCTP have been added:
SCTPの「チャンクパラメータータイプ」レジストリの6つの追加行が追加されました。
Chunk Parameter Types
チャンクパラメータータイプ
ID Value Chunk Parameter Type Reference
-------- ------------------------------------------------ ---------
13 Outgoing SSN Reset Request Parameter [RFC6525]
14 Incoming SSN Reset Request Parameter [RFC6525]
15 SSN/TSN Reset Request Parameter [RFC6525]
16 Re-configuration Response Parameter [RFC6525]
17 Add Outgoing Streams Request Parameter [RFC6525]
18 Add Incoming Streams Request Parameter [RFC6525]
The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and Vlad Yasevich for their invaluable comments.
著者は、Paul Aitken、Gorry Fairhurst、Tom Petch、Kacheong Poon、Irene Ruengeler、Robin Seggelmann、Gavin Shearer、Vlad Yasevichの貴重なコメントに感謝したいと考えています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）動的アドレス再構成」、RFC 5061、2007年9月。
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, January 2011.
[RFC6096] Tuexen、M。およびR. Stewart、「ストリーム制御伝送プロトコル（SCTP）チャンクフラグ登録」、RFC 6096、2011年1月。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Sockets API拡張機能（SCTP）」、RFC 6458、2011年12月。
Please note that this appendix is informational only.
この付録は情報のみであることに注意してください。
The following message flows between Endpoints E-A and E-Z illustrate the described procedures. The time progresses in downward direction.
エンドポイントE-AとE-Zの間の次のメッセージの流れは、説明されている手順を示しています。時間は下向きに進行します。
The following example illustrates E-A resetting streams 1 and 2 for just its outgoing streams.
次の例は、発信ストリームのみのe-Aリセットストリーム1と2を示しています。
E-A E-Z
----------[RE-CONFIG(OUT-REQ:X/1,2)]---------->
<-------------[RE-CONFIG(RESP:X)]--------------
The following example illustrates E-A resetting streams 1 and 2 for just its incoming streams.
次の例は、その着信ストリームのみのe-Aリセットストリーム1と2を示しています。
E-A E-Z
-----------[RE-CONFIG(IN-REQ:X/1,2)]---------->
<--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]----------
-------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates E-A resetting all streams in both directions.
次の例は、すべてのストリームを両方向にリセットするE-Aを示しています。
E-A E-Z
-----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]---->
<------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]-------
-------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates E-A requesting that the streams and TSNs be reset. At completion, E-A has the new sending TSN (selected by the peer) of B, and E-Z has the new sending TSN of A (also selected by the peer).
次の例は、e-aがストリームとTSNをリセットすることを要求することを示しています。完了時に、E-AにはBの新しい送信TSN（ピアによって選択）があり、E-ZにはAの新しい送信TSN（ピアによって選択されます）があります。
E-A E-Z
------------[RE-CONFIG(TSN-REQ:X)]------------>
<-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]-----
The following example illustrates E-A requesting the addition of 3 outgoing streams.
次の例は、3つの発信ストリームの追加を要求するE-Aを示しています。
E-A E-Z
--------[RE-CONFIG(ADD_OUT_STRMS:X/3)]-------->
<-------------[RE-CONFIG(RESP:X)]--------------
The following example illustrates E-A requesting the addition of 3 incoming streams.
次の例は、3つの着信ストリームの追加を要求するE-Aを示しています。
E-A E-Z
---------[RE-CONFIG(ADD_IN_STRMS:X/3)]-------->
<----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------
-------------[RE-CONFIG(RESP:Y)]-------------->
Authors' Addresses
著者のアドレス
Randall R. Stewart Adara Networks Chapin, SC 29036 USA
ランドールR.スチュワートアダラネットワークチャピン、サウスカロライナ州29036 USA
EMail: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr。39 48565 Steinfurt de
EMail: tuexen@fh-muenster.de
Peter Lei Cisco Systems, Inc. 9501 Technology Blvd. West Office Center Rosemont, IL 60018 USA
Peter Lei Cisco Systems、Inc。9501 Technology Blvd.ウェストオフィスセンターローズモント、イリノイ州60018 USA
EMail: peterlei@cisco.com