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.
ストリーム制御伝送プロトコル（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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 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.
[RFC4960]で定義されているSCTPを使用する多くのアプリケーションは、ストリームを「リセット」する機能が欲しいです。ストリームをリセットする意図はリセットが実行されたアプリケーション層に対応する通知バック「ゼロ」にストリームのストリーム・シーケンス番号（SSNの）を設定することです。この機能を必要とするアプリケーションは、異なる目的のためにストリームを「再利用」が、それでもアプリケーションがメッセージ・フローを追跡できるように、SSNを利用したいと思います。したがって、この機能なしで、古いストリームの新しい使用は、「ゼロに戻すストリームをリセット」するためのプロトコルメカニズムがなければ、予想よりも大きなメッセージ数をもたらすであろう。この文書はまた、追加のストリームを追加すること、およびすべてのSSNをリセットし、送信シーケンス番号（TSNを）をリセットするための方法を含みます。
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のためのソケットAPIは、ユーザのメッセージ転送のためにSCTPによって使用されるシーケンス番号を露出させます。そのため、それらをリセットするアプリケーション作成者によって使用することができます。 TCPに対応するシーケンス番号は、TCP用のソケット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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
RE-CONFIGチャンクの形式は、受信機は、それが理解されていない場合にチャンクを無視して、続くすべてのチャンクの処理を続行することを必要とすることに留意すべきです。 [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:
この文書では、SCTPに1つの新しいチャンクタイプを追加します。チャンク形式は次のとおりです。
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バイト（符号なし整数）このフィールドには、RE-CONFIGチャンクのための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:
各RE-CONFIGチャンクは、少なくとも一つのパラメータと、せいぜい2つのパラメータを保持していることに注意してください。のみ、次の組み合わせが許可されています。
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request Parameter.
3.発信SSNは、リクエストパラメータをリセットし、着信SSNはリクエストパラメータをリセットします。
7. Add Outgoing Streams Request Parameter, Add Incoming Streams Request Parameter.
7.、発信ストリームリクエストパラメータを追加します。着信ストリームリクエストパラメータを追加します。
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で定義されるように、受信機は、プロトコル違反の原因とERRORチャンクを送信する必要があります）。
This section defines the new parameter types that will be used in the RE-CONFIG chunk. Table 2 illustrates the new parameter types.
このセクションでは、RE-CONFIGチャンクで使用される新しいパラメータの型を定義します。表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バイト（符号なし整数）このフィールドは、パラメータのバイト単位の長さを保持します。値Nが記載されているストリーム数の数であり、16 + 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増加します。
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.
このパラメータは、RE-CONFIGチャンクに表示されます。このパラメータは、他のチャンクタイプに現れてはいけません。
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.
このパラメータは、RE-CONFIGチャンクに表示されます。このパラメータは、他のチャンクタイプに現れてはいけません。
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.
このパラメータは、RE-CONFIGチャンクに表示されます。このパラメータは、他のチャンクタイプに現れてはいけません。
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バイト（符号なし整数）このフィールドは、パラメータのバイト単位の長さを保持します。オプションフィールドが存在しないと、20そうでない場合、この値は12でなければなりません。
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バイト（符号なし整数）この値は、要求パラメータからコピーされ、要求に対する応答を結びつけるために再構成応答パラメータの受信機によって使用されます。
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.
このパラメータは、RE-CONFIGチャンクに表示されます。このパラメータは、他のチャンクタイプに現れてはいけません。
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バイト（符号なし整数）このフィールドは、追加発信ストリーム・リクエスト・パラメータのための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.
このパラメータは、RE-CONFIGチャンクに表示されることがあります。このパラメータは、他のチャンクタイプに現れてはいけません。
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バイト（符号なし整数）このフィールドには、追加の着信ストリームリクエストパラメータのための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.
このパラメータは、RE-CONFIGチャンクに表示されることがあります。このパラメータは、他のチャンクタイプに現れてはいけません。
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.
このセクションでは、RE-CONFIGチャンクの送信者と受信者の両方によって使用される手順を定義しています。再構成シナリオの様々な例が付録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.
このセクションでは、RE-CONFIGチャンクの送信に関連する手順を説明します。 RE-CONFIGチャンクは、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のいずれかでサポートされている拡張機能のパラメータでRE-CONFIGチャンクのチャンクタイプを含まなければなりません。 RE-CONFIGチャンクを送信する前に、送信者は、ピアは、再設定の拡張機能のサポートをアドバタイズしていることを確認しなければなりません。 RE-CONFIGチャンクのチャンクタイプは、チャンクのサポート拡張機能のリストに表示されない場合は、送信者はピアに任意の再設定要求を送ってはいけませんし、そのようなサービスのためのアプリケーションによって、すべての要求がで応答すべきである（SHOULD）ピア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.
どの時点でも、飛行中の複数の要求があってはなりません。再構成のタイマーが動作しているとRE-CONFIGチャンクは、少なくとも一つのリクエストパラメータが含まれているのであれば、チャンクがバッファリングされなければなりません。
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 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.
RE-CONFIGチャンクは、少なくとも一つのリクエストパラメータが含まれている場合はRE-CONFIGチャンクをパッケージ化し、ピアに送信した後、送信者は、再設定のタイマーを起動する必要があります。それはリクエストパラメータが含まれていない場合は、再設定のタイマーが開始されてはなりません。このタイマは、SCTPのデータ送信タイマ（すなわち、再送タイムアウト（RTO）タイマー）と同じ値を使用しなければならなくて、すべての有効期限の値を倍に、指数バックオフを使用しなければなりません。タイマーが満了した場合は、値を二倍以外に、送信者は、SCTPの再送しきい値を超えた場合には（協会と宛先の両方のための）適切なエラーカウントをインクリメントし、閾値管理を行う、おそらく関連性を破壊し、RE-CONFIGチャンクを再送しなければなりません。
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：送信者は、影響を受けたストリームに対して、上位層によって提供される新しいユーザデータに新規のSSNを割り当てることを停止し、それをキューイングしなければいけません。リクエストの受信機がそれを受け入れるか拒否するかどうかは知られていないためです。また、失われた要求は、受信機がまだ対処する準備ができていないことであるストリームでシーケンス外のエラーが発生する可能性があります。
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は、送信者が、1マイナス割り当て次のTSNに設定しなければなりません。
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リセットリクエストパラメータは、RE-CONFIGチャンクに入れなければなりません。発信SSNリセットリクエストパラメータは、両方ではないと、着信SSNリセットリクエストパラメータまたは再構成のレスポンスパラメータのいずれかと一緒に置かれるかもしれません。 3.1節で述べたように、それは、他のパラメータと一緒に入れてはなりません。
A6: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
A6：RE-CONFIGチャンクは、5.1.1項で与えられた規則に従って送らなければなりません。
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リセットリクエストパラメータはRE-CONFIGチャンクに入れなければなりません。これは、発信SSNリセットリクエストパラメータと一緒に置かれるかもしれませんが、他のパラメータと一緒に入れてはなりません。
B4: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
B4：RE-CONFIGチャンクは、5.1.1項で与えられた規則に従って送らなければなりません。
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が要求をリセット送信するとき、ピアは単にリセットまたはリセット要求送信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送信者がのSSNとの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：送信者がどちらかの未解決のTSNを持っていないか、すべての未の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はリクエストパラメータをリセットRE-CONFIGチャンクに入れなければなりません。このチャンク内の他のパラメータがあってはなりません。
C4: The RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1.
C4：RE-CONFIGチャンクは、5.1.1項で与えられた規則に従って送らなければなりません。
Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, which is considered a maximum segment lifetime (the IP MSL).
/ TSNをリセット要求つのみSSNは、最大セグメント寿命（IP MSL）が考えられている30秒以内に送信されるべきです。
5.1.5. Sender-Side Procedures for the Add Outgoing Streams Request Parameter
5.1.5. 追加発信ストリーム・リクエスト・パラメータの送信側の手順
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送信者は、送信することができたアウトバウンドストリーム数を増やしたい場合は、RE-CONFIGチャンクに発信ストリームのリクエストパラメータを追加します追加することができます。リクエストを送信すると、送信側はこの要求によって追加された追加のストリームを使用する前に、肯定応答（成功）を待たなければなりません。新しいストリームが隙間なく前ストリームに隣接して追加されることに留意されたいです。これは、要求が正常に完了すると、既に5（0-4）を有するアソシエーション、新しいストリームに2つのストリームを追加するためになされた場合、ストリーム5,6新しいストリームは、その最初のためSSN 0を使用しなければなりませんであることを意味します注文したメッセージ。
5.1.6. Sender-Side Procedures for the Add Incoming Streams Request Parameter
5.1.6. 追加の着信ストリームリクエストパラメータの送信側の手順
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 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送信者は、ピアが送信することができたインバウンドストリーム数を増やしたい場合は、RE-CONFIGチャンクに追加の着信ストリームリクエストパラメータを追加することができます。新しいストリームが隙間なく前ストリームに隣接して追加されることに留意されたいです。これは、要求が正常に完了すると、既に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が要求をリセットする場合には、受信者の次の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.
RE-CONFIGチャンクを受信すると、その中の各パラメータは、処理されるべきです。複数のパラメータが返されている場合、彼らは1つのRE_CONFIGチャンクに入れなければなりません。受信したRE-CONFIGチャンクは少なくとも一つの要求パラメータが含まれている場合、選択的確認応答（SACK）チャンクが返送されるべきであり、RE-CONFIGチャンクにバンドルされるかもしれません。受信したRE-CONFIGチャンクは少なくとも一つの要求を含み、再構成要求シーケンス番号の分析に基づいた場合、これは最後に受信したRE-CONFIGチャンクは同じRE-CONFIGチャンクがあることがなければならない（すなわち、再送）でありますそれは以前にあったように、応答に送り返さ。
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.
実装上の注意：これは、SACKが発生する必要がある任意の再送処理を迅速ことができるように、任意の再構成応答にバンドルすることをお勧めします。 SACKチャンクは、この機能を動作させるために必要とされていないが、それは実質的に任意のデータ損失に直面して再構成操作を完了するの遅延を最小限に抑えることができます。
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は累積確認応答ポイントよりも大きい場合、エンドポイントは「繰延リセット処理」を入力する必要があります。このモードでは、任意のデータが影響を受けるストリーム（S）ローカルキューに入れられ、累積確認応答ポイントが送信者の最後に割り当てられたTSNに達するまで保持されなければならないため送信者の最後に割り当てられたTSNより大きいTSNと到着します。累積確認応答ポイントが最後に割り当てられたTSNに到達すると、次のステップに進みます。エンドポイントは、「繰延リセット処理」を入力した場合、それは「進行中」を示すRE-CONFIGチャンクへの再構成のレスポンスパラメータを置く必要がありますし、RE-CONFIGチャンクを送らなければなりません。
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：NOストリーム番号をパラメータにリストされていない場合、次のSSNを予想通り、その後、すべての着信ストリームを0にリセットする必要があります。特定のストリーム番号が表示されている場合は、のみ、これらの具体的な流れは、0にリセットされなければならない、と他のすべての非上場のSSNは変更されません。
E4: Any queued TSNs (queued at step E2) MUST now be released and processed normally.
E4：すべては（ステップE2でキューに入れられた）のTSNをキューに入れ、今正常に解放して処理しなければなりません。
E5: A Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing.
E5は：再構成のレスポンスパラメータは、成功した処理を示すRE-CONFIGチャンクに入れなければなりません。
E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
E6：着信RE-CONFIGチャンクが完全に処理された後、RE-CONFIGチャンクが送信されなければなりません。
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項に従ってRE-CONFIGチャンクに入れなければなりません。
F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
F2：着信RE-CONFIGチャンクが完全に処理された後、RE-CONFIGチャンクが送信されなければなりません。
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リセットが、これはSSN 0ですでにストリームは、その後の時間にリセットされます（エンドポイントがストリームのリセットを行うことを選択した場合）ことを意味していても、正常に処理しなければなりません。
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チャンクをリセットします。値は、要求プラス1の受信機によって送信された最高TSNであるべきです。
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とSACKチャンクが実行されなければならないかのように同じ処理を行います。
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：影響を受けるすべてのストリームとレシーバの次のTSNの新しい累積TSN ACKとFWD-TSNチャンクしかし同様の処理（[RFC3758]で定義されるように）マイナス1が受信されたが行われなければなりません。
G5: The next expected and outgoing SSNs MUST be reset to 0 for all incoming and outgoing streams.
G5：次の予想されると発信のSSNは、すべての着信および発信ストリームに0にリセットされなければなりません。
G6: A Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing.
G6：再構成のレスポンスパラメータが成功した処理を示すRE-CONFIGチャンクに入れなければなりません。
G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely.
G7：着信RE-CONFIGチャンクが完全に処理された後、RE-CONFIGチャンクが送信されなければなりません。
5.2.5. Receiver-Side Procedures for the Add Outgoing Streams Request Parameter
5.2.5. 送信ストリームの追加リクエストパラメータの受信側の手順
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エンドポイントが追加のストリームを追加、再設定要求を受信すると、要求を承認または拒否のいずれかの応答パラメータを送らなければなりません。応答が成功した場合、受信機は、ストリームの数は、アプリケーションによって設定可能でなければならない限界を超えた場合に0にSCTPエンドポイントを次の期待SSNを初期化する要求を拒否する必要があり、関連するインバウンドストリームの要求された数を追加しなければなりません。
5.2.6. Receiver-Side Procedures for the Add Incoming Streams Request Parameter
5.2.6. 追加の着信ストリームリクエストパラメータの受信側の手順
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で与えられた規則に従って、対応する送信ストリームを追加するリクエストパラメータを送ります。ストリームの数は、アプリケーションによって設定可能でなければならない限界を超えた場合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：[結果]フィールドには「進行中」の場合は、再設定要求シーケンス番号のためのタイマーが再び開始されます。タイマーが切れる場合は、RE-CONFIGチャンクを再送する必要がありますが、対応するエラーカウンタをインクリメントしてはなりません。
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が要求をリセットした場合、影響を受けたストリームは今リセットする必要があり、すべてのデータは現在処理されなければならないキューに入れられました。 SSNのの割り当てが再び許可されます。
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から始まる、Receiverの次のTSNから送らなければなりません。次はSSNを期待通りにすべての受信ストリームは0にリセットされなければなりません。ピアは、送信者の次のTSNで始まるDATAチャンクを送信します。
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:
sn_strreset_event、sn_assocreset_event、及びsn_strchange_event：組合sctp_notificationは{}つの新しいフィールドを含むように拡張されます。
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：このフィールドは、ビット単位のOR以下、現在定義されたフラグの一つ以上で形成されています。
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_OUTGOING_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_OUTGOING_SSNの少なくとも一方が設定されています。 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フィールドには、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーション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：このフィールドは、ビット単位のOR以下、現在定義されたフラグの一つ以上で形成されています。
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フィールドには、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーション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：このフィールドは、ビット単位のOR以下、現在定義されたフラグの一つ以上で形成されています。
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フィールドには、協会の識別子を保持しています。与えられたアソシエーションのすべての通知は、同じアソシエーション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フィールドを埋めます。また、ユーザは、このイベントを設定するために関連（このフィールドは一対一の様式ソケットでは無視される）または[RFC6458]で定義された予約済みの定数値のいずれかのいずれかでse_assoc_idフィールドに入力します。最後に、se_onフィールドは、イベントを無効にするイベントまたは0を有効にするために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：このフィールドは、ビット単位のOR以下、現在定義されたフラグの一つ以上で形成されています。
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：プロセスは、このフラグが設定されている場合、発信ストリームの要求を追加受け取りました。ない場合は、それらを否定します。
The default value is !(SCTP_ENABLE_RESET_STREAM_REQ| SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ).
（| SCTP_ENABLE_RESET_ASSOC_REQ | SCTP_ENABLE_CHANGE_ASSOC_REQ SCTP_ENABLE_RESET_STREAM_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：このパラメータはリセットされるストリームのクラスについて説明します。これは、ビット単位のOR以下、現在定義されたフラグの一つ以上で形成されています。
* SCTP_STREAM_RESET_INCOMING
* SCTP_STREAM_RESET_INCOMING
* SCTP_STREAM_RESET_OUTGOING
* SCTP_STREAM_RESET_OUTGOING
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ソケットオプションを発行するときに構造体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は「10」に設定上位2ビットとチャンクのプールからこの値を割り当てました。
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によって割り当てられています。表2に与えられたこの値が使用されています。 IANAは「00」に設定上位2ビットを用いてパラメータのプールからこれらの値を割り当てました。
Six additional lines in the "Chunk Parameter Types" registry for SCTP have been added:
SCTPのための「チャンクパラメータ型」レジストリ内の6つの追加行が追加されました。
Chunk Parameter Types
CHUNKパラメータの種類
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.
作者は彼らの貴重なコメントをポール・エイトケン、Gorry Fairhurst、トム・ペッチ、Kacheongプーン、アイリーンRuengeler、ロビンSeggelmann、ギャビン・シアラー、およびヴラドYasevichに感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、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]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル（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.スチュワート、 "ストリーム制御伝送プロトコル（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]スチュワート、R.、Tuexen、M.、プーン、K.、レイ、P.、およびV. Yasevich、RFC 6458、2011年12月 "ストリーム制御伝送プロトコル（SCTP）のためのソケットAPI拡張"。
Appendix A. Examples of the Reconfiguration Procedures
再構成手順の付録A.例
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-リセットがちょうどその発信ストリームの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-リセットがちょうどその着信ストリームの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はストリームとTSNをリセットすることを要求示します。完了時に、E-Aは、Bの（ピアによって選択された）新しい送信TSNを有し、そしてE-Zは、（また、ピアによって選択された）の新たな送信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.スチュワートアダラネットワークチャピン、SC 29036 USA
EMail: randall@lakerest.net
メールアドレス：randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
応用科学StegerwaldstrのマイケルTuexenミュンスター大学。 39 48565シュタインフルトDE
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Peter Lei Cisco Systems, Inc. 9501 Technology Blvd. West Office Center Rosemont, IL 60018 USA
ピーター・レイシスコシステムズ株式会社9501テクノロジー・ブルバードウェスト・オフィスセンターローズモント、IL 60018 USA
EMail: peterlei@cisco.com
メールアドレス：peterlei@cisco.com