[要約] RFC 4960は、Stream Control Transmission Protocol（SCTP）の仕様を定義しています。SCTPは、信頼性の高いデータ転送とフロー制御を提供するために設計されています。このRFCの目的は、SCTPの機能と動作を明確に定義し、インターネット上での信頼性の高い通信を実現することです。
Network Working Group R. Stewart, Ed.
Request for Comments: 4960 September 2007
Obsoletes: 2960, 3309
Category: Standards Track
Stream Control Transmission Protocol
ストリーム制御伝送プロトコル
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
このドキュメントはRFC 2960とRFC 3309を廃止します。ストリーム制御伝送プロトコル（SCTP）について説明します。 SCTPは、公衆交換電話網（PSTN）シグナリングメッセージをIPネットワーク経由で転送するように設計されていますが、より幅広いアプリケーションに対応できます。
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
SCTPは、IPなどのコネクションレス型パケットネットワーク上で動作する信頼性の高いトランスポートプロトコルです。ユーザーに次のサービスを提供します。
-- acknowledged error-free non-duplicated transfer of user data,
-ユーザーデータのエラーのない重複のない転送を認め、
-- data fragmentation to conform to discovered path MTU size,
-検出されたパスMTUサイズに準拠するためのデータの断片化、
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
-複数のストリーム内でのユーザーメッセージの順次配信、および個々のユーザーメッセージの到着順配信オプション
-- optional bundling of multiple user messages into a single SCTP packet, and
-単一のSCTPパケットへの複数のユーザーメッセージのオプションのバンドル、および
-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
-アソシエーションの一端または両端でのマルチホーミングのサポートによるネットワークレベルのフォールトトレランス。
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.
SCTPの設計には、適切な輻輳回避動作と、フラッディングおよびマスカレード攻撃に対する耐性が含まれています。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Motivation .................................................5
1.2. Architectural View of SCTP .................................6
1.3. Key Terms ..................................................6
1.4. Abbreviations .............................................10
1.5. Functional View of SCTP ...................................10
1.5.1. Association Startup and Takedown ...................11
1.5.2. Sequenced Delivery within Streams ..................12
1.5.3. User Data Fragmentation ............................12
1.5.4. Acknowledgement and Congestion Avoidance ...........12
1.5.5. Chunk Bundling .....................................13
1.5.6. Packet Validation ..................................13
1.5.7. Path Management ....................................13
1.6. Serial Number Arithmetic ..................................14
1.7. Changes from RFC 2960 .....................................15
2. Conventions ....................................................15
3. SCTP Packet Format .............................................15
3.1. SCTP Common Header Field Descriptions .....................16
3.2. Chunk Field Descriptions ..................................17
3.2.1. Optional/Variable-Length Parameter Format ..........19
3.2.2. Reporting of Unrecognized Parameters ...............21
3.3. SCTP Chunk Definitions ....................................21
3.3.1. Payload Data (DATA) (0) ............................22
3.3.2. Initiation (INIT) (1) ..............................24
3.3.2.1. Optional/Variable-Length
Parameters in INIT ........................27
3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30
3.3.3.1. Optional or Variable-Length Parameters ....33
3.3.4. Selective Acknowledgement (SACK) (3) ...............34
3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39
3.3.7. Abort Association (ABORT) (6) ......................40
3.3.8. Shutdown Association (SHUTDOWN) (7) ................41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41
3.3.10. Operation Error (ERROR) (9) .......................42
3.3.10.1. Invalid Stream Identifier (1) ............44
3.3.10.2. Missing Mandatory Parameter (2) ..........44
3.3.10.3. Stale Cookie Error (3) ...................45
3.3.10.4. Out of Resource (4) ......................45
3.3.10.5. Unresolvable Address (5) .................46
3.3.10.6. Unrecognized Chunk Type (6) ..............46
3.3.10.7. Invalid Mandatory Parameter (7) ..........47
3.3.10.8. Unrecognized Parameters (8) ..............47
3.3.10.9. No User Data (9) .........................48
3.3.10.10. Cookie Received While Shutting
Down (10) ...............................48
3.3.10.11. Restart of an Association with
New Addresses (11) ......................49
3.3.10.12. User-Initiated Abort (12) ...............49
3.3.10.13. Protocol Violation (13) .................50
3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51
4. SCTP Association State Diagram .................................52
5. Association Initialization .....................................56
5.1. Normal Establishment of an Association ....................56
5.1.1. Handle Stream Parameters ...........................58
5.1.2. Handle Address Parameters ..........................58
5.1.3. Generating State Cookie ............................61
5.1.4. State Cookie Processing ............................62
5.1.5. State Cookie Authentication ........................62
5.1.6. An Example of Normal Association Establishment .....64
5.2. Handle Duplicate or Unexpected INIT, INIT ACK,
COOKIE ECHO, and ..........................................65
5.2.1. INIT Received in COOKIE-WAIT or
COOKIE-ECHOED State (Item B) .......................66
5.2.2. Unexpected INIT in States Other than
CLOSED, COOKIE-ECHOED, .............................66
5.2.3. Unexpected INIT ACK ................................67
5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67
5.2.4.1. An Example of a Association Restart .......69
5.2.5. Handle Duplicate COOKIE-ACK. .......................71
5.2.6. Handle Stale COOKIE Error ..........................71
5.3. Other Initialization Issues ...............................72
5.3.1. Selection of Tag Value .............................72
5.4. Path Verification .........................................72
6. User Data Transfer .............................................73
6.1. Transmission of DATA Chunks ...............................75
6.2. Acknowledgement on Reception of DATA Chunks ...............78
6.2.1. Processing a Received SACK .........................81
6.3. Management of Retransmission Timer ........................83
6.3.1. RTO Calculation ....................................83
6.3.2. Retransmission Timer Rules .........................85
6.3.3. Handle T3-rtx Expiration ...........................86
6.4. Multi-Homed SCTP Endpoints ................................87
6.4.1. Failover from an Inactive Destination Address ......88
6.5. Stream Identifier and Stream Sequence Number ..............88
6.6. Ordered and Unordered Delivery ............................88
6.7. Report Gaps in Received DATA TSNs .........................89
6.8. CRC32c Checksum Calculation ...............................90
6.9. Fragmentation and Reassembly ..............................91
6.10. Bundling .................................................92
7. Congestion Control .............................................93
7.1. SCTP Differences from TCP Congestion Control ..............94
7.2. SCTP Slow-Start and Congestion Avoidance ..................95
7.2.1. Slow-Start .........................................96
7.2.2. Congestion Avoidance ...............................97
7.2.3. Congestion Control .................................98
7.2.4. Fast Retransmit on Gap Reports .....................98
7.3. Path MTU Discovery .......................................100
8. Fault Management ..............................................100
8.1. Endpoint Failure Detection ...............................100
8.2. Path Failure Detection ...................................101
8.3. Path Heartbeat ...........................................102
8.4. Handle "Out of the Blue" Packets .........................104
8.5. Verification Tag .........................................105
8.5.1. Exceptions in Verification Tag Rules ..............105
9. Termination of Association ....................................106
9.1. Abort of an Association ..................................107
9.2. Shutdown of an Association ...............................107
10. Interface with Upper Layer ...................................110
10.1. ULP-to-SCTP .............................................110
10.2. SCTP-to-ULP .............................................120
11. Security Considerations ......................................123
11.1. Security Objectives .....................................123
11.2. SCTP Responses to Potential Threats .....................124
11.2.1. Countering Insider Attacks .......................124
11.2.2. Protecting against Data Corruption in the
Network ..........................................124
11.2.3. Protecting Confidentiality .......................124
11.2.4. Protecting against Blind
Denial-of-Service Attacks ........................125
11.2.4.1. Flooding ................................125
11.2.4.2. Blind Masquerade ........................126
11.2.4.3. Improper Monopolization of Services .....127
11.3. SCTP Interactions with Firewalls ........................127
11.4. Protection of Non-SCTP-Capable Hosts ....................128
12. Network Management Considerations ............................128
13. Recommended Transmission Control Block (TCB) Parameters ......129
13.1. Parameters Necessary for the SCTP Instance ..............129
13.2. Parameters Necessary per Association (i.e., the TCB) ....129
13.3. Per Transport Address Data ..............................131
13.4. General Parameters Needed ...............................132
14. IANA Considerations ..........................................132
14.1. IETF-defined Chunk Extension ............................132
14.2. IETF-Defined Chunk Parameter Extension ..................133
14.3. IETF-Defined Additional Error Causes ....................133
14.4. Payload Protocol Identifiers ............................134
14.5. Port Numbers Registry ...................................134
15. Suggested SCTP Protocol Parameter Values .....................136
16. Acknowledgements .............................................137
Appendix A. Explicit Congestion Notification .....................139
Appendix B. CRC32c Checksum Calculation ..........................140
Appendix C. ICMP Handling ........................................142
References .......................................................149
Normative References ..........................................149
Informative References ........................................150
This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol.
このセクションでは、ストリーム制御伝送プロトコル（SCTP）の開発の背後にある理由、それが提供するサービス、およびプロトコルの詳細な説明を理解するために必要な基本概念について説明します。
This document obsoletes [RFC2960] and [RFC3309].
このドキュメントは[RFC2960]と[RFC3309]を廃止しました。
TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following:
TCP [RFC0793]は、IPネットワークにおける信頼性の高いデータ転送の主要な手段として、計り知れないサービスを実行しました。しかし、最近のアプリケーションの増加により、TCPは制限が厳しすぎることがわかり、UDP [RFC0768]に独自の信頼性の高いデータ転送プロトコルを組み込んでいます。ユーザーが回避したいと考えていた制限には、次のものがあります。
-- TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay.
-TCPは、信頼できるデータ転送と厳密な送信順序のデータ配信の両方を提供します。一部のアプリケーションはシーケンスのメンテナンスなしで信頼できる転送を必要としますが、他のアプリケーションはデータの部分的な順序付けで満足します。これらのどちらの場合でも、TCPによって提供される行頭ブロッキングは、不要な遅延を引き起こします。
-- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
-TCPのストリーム指向の性質は、しばしば不便です。アプリケーションは、独自のレコードマーキングを追加してメッセージの輪郭を描き、プッシュ機能を明示的に使用して、完全なメッセージが妥当な時間内に確実に転送されるようにする必要があります。
-- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts.
-TCPソケットの範囲が限定されているため、マルチホームホストを使用して高可用性データ転送機能を提供するタスクが複雑になります。
-- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks.
-TCPは、SYN攻撃などのサービス拒否攻撃に対して比較的脆弱です。
Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements.
IPネットワークを介したPSTNシグナリングの転送は、TCPのこれらすべての制限が関連するアプリケーションです。このアプリケーションはSCTPの開発を直接動機づけましたが、他のアプリケーションはSCTPが彼らの要件によく一致することを見つけるかもしれません。
SCTP is viewed as a layer between the SCTP user application ("SCTP user" for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers.
SCTPは、SCTPユーザーアプリケーション（略して「SCTPユーザー」）とIPなどのコネクションレス型パケットネットワークサービスの間のレイヤーと見なされます。このドキュメントの残りの部分では、SCTPがIPの上で実行されることを前提としています。 SCTPが提供する基本的なサービスは、ピアSCTPユーザー間でのユーザーメッセージの信頼できる転送です。 2つのSCTPエンドポイント間の関連付けのコンテキスト内でこのサービスを実行します。このドキュメントのセクション10は、SCTPとSCTPユーザー層の間の境界に存在する必要があるAPIをスケッチしています。
SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint's lists.
SCTPは本質的にコネクション型ですが、SCTPアソシエーションはTCP接続よりも広い概念です。 SCTPは、各SCTPエンドポイント（セクション1.3）が他のエンドポイントに（アソシエーションの起動時に）トランスポートアドレス（つまり、SCTPポートと組み合わせた複数のIPアドレス）のリストを提供する手段を提供します。 SCTPパケットを発信します。関連付けは、各エンドポイントのリストから生成される可能性のあるすべての送信元/宛先の組み合わせにわたる転送にまたがります。
_____________ _____________
| SCTP User | | SCTP User |
| Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association
図1：SCTPアソシエーション
Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions.
SCTPの説明に使用される言語の一部は、前のセクションで紹介されています。このセクションでは、主要な用語とその定義の統合リストを提供します。
o Active destination transport address: A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages.
o アクティブな宛先トランスポートアドレス：送信側エンドポイントがユーザーメッセージの受信に使用できると見なすピアエンドポイント上のトランスポートアドレス。
o Bundling: An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk.
o バンドリング：オプションの多重化操作。これにより、複数のユーザーメッセージを同じSCTPパケットで伝送できます。各ユーザーメッセージは、独自のDATAチャンクを占有します。
o Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.
o チャンク：チャンクヘッダーとチャンク固有のコンテンツで構成される、SCTPパケット内の情報の単位。
o Congestion window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement.
o 輻輳ウィンドウ（cwnd）：送信者が確認を受信する前に特定の宛先トランスポートアドレスに送信できるデータのバイト数を制限するSCTP変数。
o Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK.
o 累積TSN Ackポイント：SACKの累積TSN Ackフィールドを介して確認応答された最後のDATAチャンクのTSN。
o Idle destination address: An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater.
o アイドル宛先アドレス：一定時間（通常はハートビート間隔以上）の間にユーザーメッセージが送信されなかったアドレス。
o Inactive destination transport address: An address that is considered inactive due to errors and unavailable to transport user messages.
o 非アクティブな宛先トランスポートアドレス：エラーのために非アクティブと見なされ、ユーザーメッセージをトランスポートできないアドレス。
o Message = user message: Data submitted to SCTP by the Upper Layer Protocol (ULP).
o メッセージ=ユーザーメッセージ：上位層プロトコル（ULP）によってSCTPに送信されたデータ。
o Message Authentication Code (MAC): An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP, it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term "MAC" has different meanings in different contexts. SCTP uses this term with the same meaning as in [RFC2104].
o メッセージ認証コード（MAC）：秘密鍵を使用した暗号化ハッシュ関数に基づく整合性チェックメカニズム。通常、メッセージ認証コードは、これらの当事者間で送信される情報を検証するために、秘密鍵を共有する2つの当事者間で使用されます。 SCTPでは、COOKIE ECHOチャンクのピアから返された状態Cookie情報を検証するためにエンドポイントによって使用されます。 「MAC」という用語は、文脈によって意味が異なります。 SCTPはこの用語を[RFC2104]と同じ意味で使用します。
o Network Byte Order: Most significant byte first, a.k.a., big endian.
o ネットワークバイトオーダー：最上位バイトが最初、別名ビッグエンディアン。
o Ordered Message: A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent.
o 順序付けされたメッセージ：メッセージが送信されたストリーム内で送信された以前のすべてのユーザーメッセージに関して順番に配信されるユーザーメッセージ。
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.
o 未処理のTSN（SCTPエンドポイントで）：エンドポイントによって送信されたが、まだ確認応答を受け取っていないTSN（および関連するDATAチャンク）。
o Path: The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.
o パス：1つのSCTPエンドポイントがピアSCTPエンドポイントの特定の宛先トランスポートアドレスに送信したSCTPパケットがたどるルート。異なる宛先トランスポートアドレスに送信しても、個別のパスを取得できるとは限りません。
o Primary Path: The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed.
o プライマリパス：プライマリパスは、デフォルトでピアエンドポイントに送信されるパケットに入れられる宛先および送信元アドレスです。実装は宛先チャンクと送信元アドレスの両方を指定して、応答チャンクがたどる戻りパスと、データ送信者がマルチホームの場合にパケットが送信されるインターフェイスをより適切に制御する必要があるため、定義には送信元アドレスが含まれます。
o Receiver Window (rwnd): An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer.
o レシーバーウィンドウ（rwnd）：データ送信者がピアの最後に計算されたレシーバーウィンドウを格納するために使用するSCTP変数（バイト数）。これにより、送信側は受信側のインバウンドバッファーで使用可能なスペースを示します。
o SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.
o SCTPアソシエーション：2つのSCTPエンドポイントで構成されるSCTPエンドポイント間のプロトコル関係と、検証タグや現在アクティブな一連の伝送シーケンス番号（TSN）などを含むプロトコル状態情報。アソシエーションは、によって使用されるトランスポートアドレスによって一意に識別できます。関連付けのエンドポイント。 2つのSCTPエンドポイントは、常にそれらの間に複数のSCTPアソシエーションを持つことはできません。
o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.
o SCTPエンドポイント：SCTPパケットの論理的な送信者/受信者。マルチホームホストでは、SCTPエンドポイントは、SCTPパケットを送信できる適格な宛先トランスポートアドレスのセットと、SCTPパケットを受信できる適格な送信元トランスポートアドレスのセットの組み合わせとして、ピアに対して表されます。 SCTPエンドポイントが使用するすべてのトランスポートアドレスは、同じポート番号を使用する必要がありますが、複数のIPアドレスを使用できます。 SCTPエンドポイントが使用するトランスポートアドレスは、別のSCTPエンドポイントが使用することはできません。つまり、トランスポートアドレスはSCTPエンドポイントに固有です。
o SCTP packet (or packet): The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks.
o SCTPパケット（またはパケット）：SCTPとコネクションレス型パケットネットワーク（IPなど）間のインターフェースを介したデータ配信の単位。 SCTPパケットには、共通のSCTPヘッダー、可能なSCTP制御チャンク、およびSCTP DATAチャンク内にカプセル化されたユーザーデータが含まれます。
o SCTP user application (SCTP user): The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP).
o SCTPユーザーアプリケーション（SCTPユーザー）：SCTPのサービスを使用する論理的な上位層アプリケーションエンティティ。上位層プロトコル（ULP）とも呼ばれます。
o Slow-Start Threshold (ssthresh): An SCTP variable. This is the threshold that the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes.
o スロースタートしきい値（ssthresh）：SCTP変数。これは、特定の宛先トランスポートアドレスでスロースタートまたは輻輳回避を実行するかどうかを決定するためにエンドポイントが使用するしきい値です。 Ssthreshはバイト数です。
o Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.
o ストリーム：関連付けられたSCTPエンドポイント間で確立された単一方向の論理チャネル内で、順序付けされていない配信サービスに送信されたものを除くすべてのユーザーメッセージが順番に配信されます。
Note: The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired.
注：反対方向のストリーム番号間の関係は、アプリケーションがストリーム番号をどのように使用するかに厳密に依存します。必要に応じてこれらの相関を作成および管理するのは、SCTPユーザーの責任です。
o Stream Sequence Number: A 16-bit sequence number used internally by SCTP to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message.
o ストリームシーケンス番号：SCTPが内部で使用する16ビットのシーケンス番号。指定されたストリーム内でユーザーメッセージのシーケンス配信を保証します。 1つのストリームシーケンス番号が各ユーザーメッセージに添付されます。
o Tie-Tags: Two 32-bit random numbers that together make a 64-bit nonce. These tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association.
o タイタグ：一緒に64ビットのナンスを構成する2つの32ビット乱数。これらのタグは状態CookieおよびTCB内で使用されるため、新しく再起動する関連付けは、再起動されず、既存の関連付けの真の検証タグを明らかにしないエンドポイント内の元の関連付けにリンクできます。
o Transmission Control Block (TCB): An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association.
o 伝送制御ブロック（TCB）：他のSCTPエンドポイントへの既存のSCTPアソシエーションごとに、SCTPエンドポイントによって作成される内部データ構造。 TCBには、エンドポイントが対応する関連付けを維持および管理するためのすべてのステータスおよび操作情報が含まれています。
o Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.
o 送信シーケンス番号（TSN）：SCTPが内部で使用する32ビットのシーケンス番号。ユーザーデータを含む各チャンクに1つのTSNがアタッチされ、受信側のSCTPエンドポイントが受信を確認して重複した配信を検出できるようにします。
o Transport address: A transport address is traditionally defined by a network-layer address, a transport-layer protocol, and a transport-layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the transport protocol).
o トランスポートアドレス：トランスポートアドレスは、通常、ネットワーク層アドレス、トランスポート層プロトコル、およびトランスポート層ポート番号によって定義されます。 IPを介して実行されるSCTPの場合、トランスポートアドレスは、IPアドレスとSCTPポート番号の組み合わせによって定義されます（SCTPはトランスポートプロトコルです）。
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received.
o 未確認のTSN（SCTPエンドポイントで）：エンドポイントによって受信されたが、確認応答がまだ送信されていないTSN（および関連するDATAチャンク）。または、反対の場合、送信されたが確認応答が受信されていないパケットの場合。
o Unordered Message: Unordered messages are "unordered" with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream.
o 順序付けられていないメッセージ：順序付けられていないメッセージは、他のメッセージに対して「順序付けられていない」。これには、他の順序付けされていないメッセージと他の順序付けされたメッセージの両方が含まれます。順序付けられていないメッセージは、同じストリームで送信される順序付けられたメッセージの前または後に配信される場合があります。
o User message: The unit of data delivery across the interface between SCTP and its user.
o ユーザーメッセージ：SCTPとそのユーザー間のインターフェイスを介したデータ配信の単位。
o Verification Tag: A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association.
o 検証タグ：ランダムに生成される32ビットの符号なし整数。検証タグは、SCTPパケットが現在のアソシエーションに属し、以前のアソシエーションからの古いパケットや古いパケットではないことを受信者が確認できるようにするキーを提供します。
MAC - Message Authentication Code [RFC2104]
MAC-メッセージ認証コード[RFC2104]
RTO - Retransmission Timeout
RTO-再送信タイムアウト
RTT - Round-Trip Time
RTT-往復時間
RTTVAR - Round-Trip Time Variation
RTTVAR-往復時間の変動
SCTP - Stream Control Transmission Protocol
SCTP-ストリーム制御伝送プロトコル
SRTT - Smoothed RTT
SRTT-平滑化されたRTT
TCB - Transmission Control Block
TCB-伝送制御ブロック
TLV - Type-Length-Value coding format
TLV-Type-Length-Valueコーディング形式
TSN - Transmission Sequence Number
TSN-送信シーケンス番号
ULP - Upper-Layer Protocol
ULP-上位層プロトコル
The SCTP transport service can be decomposed into a number of functions. These are depicted in Figure 2 and explained in the remainder of this section.
SCTPトランスポートサービスは、いくつかの機能に分解できます。これらを図2に示し、このセクションの残りの部分で説明します。
SCTP User Application
SCTPユーザーアプリケーション
-----------------------------------------------------
_____________ ____________________
| | | Sequenced Delivery |
| Association | | within Streams |
| | |____________________|
| Startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| Takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service
図2：SCTPトランスポートサービスの機能ビュー
An association is initiated by a request from the SCTP user (see the description of the ASSOCIATE (or SEND) primitive in Section 10).
関連付けは、SCTPユーザーからの要求によって開始されます（セクション10のASSOCIATE（またはSEND）プリミティブの説明を参照してください）。
A cookie mechanism, similar to one described by Karn and Simpson in [RFC2522], is employed during the initialization to provide protection against synchronization attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup. The startup sequence is described in Section 5 of this document.
[RFC2522]でKarnとSimpsonによって説明されたものと同様のCookieメカニズムが初期化中に使用され、同期攻撃に対する保護を提供します。 Cookieメカニズムは4ウェイハンドシェイクを使用し、その最後の2つのレッグは、高速セットアップのためにユーザーデータを運ぶことができます。起動シーケンスについては、このドキュメントのセクション5で説明しています。
SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP user. See the description of the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT primitive) or as a result of an error condition detected within the SCTP layer. Section 9 describes both the graceful and the ungraceful close procedures.
SCTPは、SCTPユーザーからの要求に応じて、アクティブな関連付けの正常なクローズ（つまり、シャットダウン）を提供します。セクション10のSHUTDOWNプリミティブの説明を参照してください。SCTPは、ユーザーからの要求に応じて（ABORTプリミティブ）、またはSCTPレイヤー内で検出されたエラー条件の結果として、異常なクローズ（つまり、中止）も許可します。セクション9では、正常なクローズ手順と異常なクローズ手順の両方について説明します。
SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close (see Section 9).
SCTPは、ハーフオープン状態（TCPなど）をサポートしていません。一方の側では、もう一方の端が閉じている間もデータの送信を続行できます。いずれかのエンドポイントがシャットダウンを実行すると、各ピアの関連付けは、ユーザーからの新しいデータの受け入れを停止し、正常なクローズ時にのみキューにデータを配信します（セクション9を参照）。
The term "stream" is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document, a byte is assumed to be 8 bits).
SCTPでは、「ストリーム」という用語は、同じストリーム内の他のメッセージに関して、上位層プロトコルに配信される一連のユーザーメッセージを指します。これは、バイトのシーケンスを参照するTCPでの使用とは対照的です（このドキュメントでは、1バイトは8ビットと想定されています）。
The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a Stream Sequence Number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed.
SCTPユーザーは、関連付けの起動時に、関連付けによってサポートされるストリームの数を指定できます。この番号はリモートエンドとネゴシエートされます（セクション5.1.1を参照）。ユーザーメッセージはストリーム番号に関連付けられています（SEND、RECEIVEプリミティブ、セクション10）。内部的には、SCTPは、SCTPユーザーから渡された各メッセージにストリームシーケンス番号を割り当てます。受信側では、SCTPはメッセージが指定されたストリーム内で順番にSCTPユーザーに配信されるようにします。ただし、1つのストリームが次のシーケンス内のユーザーメッセージを待機してブロックされている間、他のストリームからの配信は続行されます。
SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received.
SCTPは、シーケンス配信サービスをバイパスするメカニズムを提供します。このメカニズムを使用して送信されたユーザーメッセージは、受信されるとすぐにSCTPユーザーに配信されます。
When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user.
必要に応じて、SCTPはユーザーメッセージをフラグメント化して、下位層に渡されるSCTPパケットがパスMTUに準拠するようにします。受信すると、フラグメントはSCTPユーザーに渡される前に完全なメッセージに再構成されます。
SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any Stream Sequence Number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery.
SCTPは、各ユーザーデータフラグメントまたはフラグメント化されていないメッセージに送信シーケンス番号（TSN）を割り当てます。 TSNは、ストリームレベルで割り当てられたストリームシーケンス番号から独立しています。シーケンスにギャップがある場合でも、受信側は受信したすべてのTSNを確認します。このようにして、信頼性の高い配信は、シーケンス化されたストリーム配信から機能的に分離されます。
The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function.
確認応答と輻輳回避機能は、タイムリーな確認応答が受信されなかった場合のパケットの再送信を担当します。パケットの再送信は、TCPに使用されるものと同様の輻輳回避手順によって調整されます。この機能に関連するプロトコル手順の詳細については、セクション6およびセクション7を参照してください。
As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.
セクション3で説明したように、下位層に配信されるSCTPパケットは、共通ヘッダーとそれに続く1つ以上のチャンクで構成されます。各チャンクには、ユーザーデータまたはSCTP制御情報を含めることができます。 SCTPユーザーは、複数のユーザーメッセージを1つのSCTPパケットにまとめることを要求するオプションがあります。 SCTPのチャンクバンドリング機能は、完全なSCTPパケットの組み立てと受信側での分解を担当します。
During times of congestion, an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission.
輻輳が発生している間、ユーザーがSCTPをバンドルしないように要求した場合でも、SCTP実装はバンドリングを実行できます（MAY）。ユーザーによるバンドリングの無効化は、（バンドリングを促進するために）送信前に少しの間遅延する可能性があるSCTP実装にのみ影響します。ユーザー層がバンドリングを無効にすると、この小さな遅延は禁止されますが、輻輳または再送信中に実行されるバンドリングは禁止されません。
A mandatory Verification Tag field and a 32-bit checksum field (see Appendix B for a description of the CRC32c checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The CRC32c checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet.
必須の検証タグフィールドと32ビットチェックサムフィールド（CRC32cチェックサムの説明については、付録Bを参照）がSCTP共通ヘッダーに含まれています。検証タグの値は、関連付けの開始時に関連付けの両端で選択されます。予期される検証タグ値なしで受信されたパケットは、ブラインドマスカレード攻撃に対する保護として、および以前のアソシエーションからの古いSCTPパケットに対する保護として破棄されます。 CRC32cチェックサムは、ネットワーク内のデータ破損に対する追加の保護を提供するために、各SCTPパケットの送信者が設定する必要があります。無効なCRC32cチェックサムを持つSCTPパケットの受信者は、静かにパケットを破棄します。
The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user.
送信側のSCTPユーザーは、セクション10で説明するプリミティブを介して、SCTPパケットの宛先として使用されるトランスポートアドレスのセットを操作できます。SCTPパス管理機能は、SCTPユーザーの指示に基づいて、各発信SCTPパケットの宛先トランスポートアドレスを選択します。適格な宛先セットの現在認識されている到達可能性ステータス。パス管理機能は、他のパケットトラフィックがこの情報を提供するのに不十分である場合にハートビートを介して到達可能性を監視し、遠端のトランスポートアドレスの到達可能性が変化したときにSCTPユーザーに通知します。パス管理機能は、アソシエーションの起動時に、適格なローカルトランスポートアドレスのセットを遠端に報告し、遠端からSCTPユーザーに返されたトランスポートアドレスを報告する役割も果たします。
At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets.
アソシエーションの起動時に、プライマリパスが各SCTPエンドポイントに対して定義され、SCTPパケットの通常の送信に使用されます。
On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
受信側では、パス管理は、インバウンドSCTPパケットが属する有効なSCTPアソシエーションが存在することを確認してから、それをさらに処理するために渡します。
Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items.
注：パス管理とパケット検証は同時に行われるため、上記で個別に説明しましたが、実際には個別のアイテムとして実行することはできません。
It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with Transmission Sequence Numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to TSNs, the symbol "=<" means "less than or equal"(modulo 2**32).
実際の送信シーケンス番号スペースは非常に大きいですが、有限であることを覚えておくことが不可欠です。このスペースの範囲は0〜2 ** 32-1です。スペースは有限であるため、送信シーケンス番号を扱うすべての演算は2 ** 32を法として実行する必要があります。この符号なし演算では、シーケンス番号が2 ** 32-1から0に再び循環するときにシーケンス番号の関係が保持されます。コンピュータのモジュロ演算にはいくつかの微妙な点があるため、そのような値の比較をプログラミングする際には細心の注意が必要です。 TSNを参照するとき、記号「= <」は「以下」（2 ** 32を法とする）を意味します。
Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
このドキュメントのTSNの比較と算術は、[RFC1982]で定義されているシリアル番号算術を使用する必要があります（SHOULD、SERIAL_BITS = 32）。
An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs.
エンドポイントは、現在の送信ウィンドウの開始TSNの2 ** 31-1以上のTSNを持つDATAチャンクを送信してはなりません（SHOULD NOT）。これを行うと、TSNの比較で問題が発生します。
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0.
送信シーケンス番号は、2 ** 32-1に達したときにラップアラウンドします。つまり、送信後、DATAチャンクが使用する次のTSN = 2 * 32-1はTSN = 0です。
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic.
ストリームシーケンス番号で行われるすべての算術は、[RFC1982]で定義されているシリアル番号算術を使用する必要があります（SHOULD）。SERIAL_BITS= 16。
SCTP was originally defined in [RFC2960], which this document obsoletes. Readers interested in the details of the various changes that this document incorporates are asked to consult [RFC4460].
SCTPはもともと[RFC2960]で定義されていましたが、このドキュメントでは廃止されました。このドキュメントに組み込まれているさまざまな変更の詳細に興味がある読者は、[RFC4460]に相談してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data.
SCTPパケットは、共通のヘッダーとチャンクで構成されています。チャンクには、制御情報またはユーザーデータが含まれます。
The SCTP packet format is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. These chunks MUST NOT be bundled with any other chunk in a packet. See Section 6.10 for more details on chunk bundling.
INIT、INIT ACK、およびSHUTDOWN COMPLETEチャンクを除き、複数のチャンクをMTUサイズまでの1つのSCTPパケットにバンドルできます。これらのチャンクは、パケット内の他のチャンクとバンドルしてはいけません。チャンクバンドリングの詳細については、セクション6.10を参照してください。
If a user data message doesn't fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.9.
ユーザーデータメッセージが1つのSCTPパケットに収まらない場合は、セクション6.9で定義されている手順を使用して、複数のチャンクにフラグメント化できます。
All integer fields in an SCTP packet MUST be transmitted in network byte order, unless otherwise stated.
特に明記されていない限り、SCTPパケットのすべての整数フィールドは、ネットワークバイトオーダーで送信する必要があります。
SCTP Common Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer)
送信元ポート番号：16ビット（符号なし整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used.
これはSCTP送信者のポート番号です。これは、送信元IPアドレス、SCTP宛先ポート、および場合によっては宛先IPアドレスと組み合わせて、このパケットが属するアソシエーションを識別するために受信者が使用できます。ポート番号0は使用してはなりません。
Destination Port Number: 16 bits (unsigned integer)
宛先ポート番号：16ビット（符号なし整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
これは、このパケットの宛先であるSCTPポート番号です。受信ホストはこのポート番号を使用して、SCTPパケットを正しい受信エンドポイント/アプリケーションに逆多重化します。ポート番号0は使用してはなりません。
Verification Tag: 32 bits (unsigned integer)
検証タグ：32ビット（符号なし整数）
The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions:
このパケットの受信者は検証タグを使用して、このSCTPパケットの送信者を検証します。送信時、この検証タグの値は、関連付けの初期化中にピアエンドポイントから受信した開始タグの値に設定する必要があります。ただし、次の例外があります。
- A packet containing an INIT chunk MUST have a zero Verification Tag.
- INITチャンクを含むパケットには、ゼロ検証タグが必要です。
- A packet containing a SHUTDOWN COMPLETE chunk with the T bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN ACK chunk.
- Tビットが設定されたSHUTDOWN COMPLETEチャンクを含むパケットは、SHUTDOWN ACKチャンクを含むパケットから検証タグをコピーする必要があります。
- A packet containing an ABORT chunk may have the verification tag copied from the packet that caused the ABORT to be sent. For details see Section 8.4 and Section 8.5.
- ABORTチャンクを含むパケットには、ABORTが送信される原因となったパケットからコピーされた検証タグが含まれる場合があります。詳細については、セクション8.4およびセクション8.5を参照してください。
An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
INITチャンクは、それを運ぶSCTPパケット内の唯一のチャンクである必要があります。
Checksum: 32 bits (unsigned integer)
チェックサム：32ビット（符号なし整数）
This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum.
このフィールドには、このSCTPパケットのチェックサムが含まれています。その計算については、セクション6.8で説明します。 SCTPは、付録Bで説明されているように、CRC32cアルゴリズムを使用してチェックサムを計算します。
The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field.
次の図は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer)
チャンクタイプ：8ビット（符号なし整数）
This field identifies the type of information contained in the Chunk Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field.
このフィールドは、チャンク値フィールドに含まれる情報のタイプを識別します。値は0〜254です。255の値は、拡張フィールドとして将来使用するために予約されています。
The values of Chunk Types are defined as follows:
チャンクタイプの値は次のように定義されます。
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK) 12 - Reserved for Explicit Congestion Notification Echo
(ECNE)
13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE)
15 to 62 - available
63 - reserved for IETF-defined Chunk Extensions
64 to 126 - available
127 - reserved for IETF-defined Chunk Extensions
128 to 190 - available
191 - reserved for IETF-defined Chunk Extensions
192 to 254 - available
255 - reserved for IETF-defined Chunk Extensions
Chunk Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type.
チャンクタイプは、最上位の2ビットが処理エンドポイントがチャンクタイプを認識しない場合に実行する必要があるアクションを指定するようにエンコードされます。
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理しないでください。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せず、認識されていないチャンクを「Unrecognized Chunk Type」で報告します。
10 - Skip this chunk and continue processing.
10-このチャンクをスキップして、処理を続行します。
11 - Skip this chunk and continue processing, but report in an ERROR chunk using the 'Unrecognized Chunk Type' cause of error.
11-このチャンクをスキップして処理を続行しますが、エラーの「認識されないチャンクタイプ」の原因を使用してERRORチャンクで報告します。
Note: The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN); see Appendix A.
注：ECNEおよびCWRチャンクタイプは、明示的輻輳通知（ECN）の将来の使用のために予約されています。付録Aを参照してください。
Chunk Flags: 8 bits
チャンクフラグ：8ビット
The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt.
これらのビットの使用法は、チャンクタイプフィールドで指定されたチャンクタイプによって異なります。特に指定のない限り、送信時には0に設定され、受信時には無視されます。
Chunk Length: 16 bits (unsigned integer)
チャンク長：16ビット（符号なし整数）
This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding.
この値は、チャンクタイプ、チャンクフラグ、チャンク長、およびチャンク値フィールドを含む、チャンクのサイズをバイト単位で表します。したがって、「チャンク値」フィールドの長さがゼロの場合、「長さ」フィールドは4に設定されます。「チャンクの長さ」フィールドは、チャンクのパディングをカウントしません。
Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding.
チャンク（タイプ、長さ、および値フィールドを含む）は、すべてゼロバイトで長さが4バイトの倍数になるように送信者によって埋め込まれます。このパディングは、合計で3バイトを超えてはなりません。 Chunk Length値には、チャンクの終了パディングは含まれません。ただし、チャンク内の最後のパラメーターを除くすべての可変長パラメーターのパディングが含まれます。レシーバーはパディングを無視しなければなりません。
Note: A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length.
注：堅牢な実装では、最後のパディングがチャンク長に含まれているかどうかに関係なく、チャンクを受け入れる必要があります。
Chunk Value: variable length
チャンク値：可変長
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
チャンク値フィールドには、チャンクで転送される実際の情報が含まれています。このフィールドの使用法と形式は、チャンクタイプによって異なります。
The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
チャンクの全長（Type、Length、Valueフィールドを含む）は、4バイトの倍数でなければなりません。チャンクの長さが4バイトの倍数でない場合、送信者はチャンクをすべてゼロバイトでパディングする必要があり、このパディングはChunk Lengthフィールドに含まれません。送信者は、3バイトを超えてパディングしてはなりません（MUST NOT）。レシーバーはパディングバイトを無視する必要があります。
SCTP-defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 14.1 of this document.
SCTPで定義されたチャンクについては、3.3節で詳しく説明します。 IETFで定義されたチャンク拡張のガイドラインは、このドキュメントのセクション14.1に記載されています。
Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below.
SCTPコントロールチャンクのチャンク値は、必須フィールドのチャンクタイプ固有のヘッダーで構成され、その後に0個以上のパラメーターが続きます。チャンクに含まれるオプションパラメータと可変長パラメータは、以下に示すようにType-Length-Value形式で定義されます。
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 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Parameter Type: 16 bits (unsigned integer)
チャンクパラメータタイプ：16ビット（符号なし整数）
The Type field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534.
Typeフィールドは、パラメータのタイプの16ビットの識別子です。値は0〜65534です。
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk descriptions are reserved for use by IETF.
65535の値は、IETF定義の拡張用に予約されています。特定のSCTPチャンクの説明で定義されている値以外の値は、IETFが使用するために予約されています。
Chunk Parameter Length: 16 bits (unsigned integer)
チャンクパラメータの長さ：16ビット（符号なし整数）
The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes.
パラメータ長フィールドには、パラメータタイプ、パラメータ長、パラメータ値フィールドを含む、バイト単位のパラメータのサイズが含まれています。したがって、長さがゼロのパラメーター値フィールドを持つパラメーターは、長さフィールドが4になります。パラメーターの長さには、パディングバイトは含まれません。
Chunk Parameter Value: variable length
チャンクパラメータ値：可変長
The Parameter Value field contains the actual information to be transferred in the parameter.
パラメータ値フィールドには、パラメータで転送される実際の情報が含まれています。
The total length of a parameter (including Type, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the Parameter Length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
パラメーター（タイプ、パラメーター長、および値フィールドを含む）の全長は、4バイトの倍数でなければなりません。パラメータの長さが4バイトの倍数でない場合、送信者はパラメータを最後（つまり、[パラメータ値]フィールドの後）にすべて0バイトで埋めます。パディングの長さは、[パラメーターの長さ]フィールドには含まれません。送信者は、3バイトを超えてパディングしてはいけません（MUST NOT）。レシーバーはパディングバイトを無視する必要があります。
The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type.
パラメータタイプは、最上位の2ビットが処理エンドポイントがパラメータタイプを認識しない場合に実行する必要があるアクションを指定するようにエンコードされます。
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00-このパラメーターの処理を停止します。このチャンク内でこれ以上パラメーターを処理しないでください。
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2.
01-このパラメーターの処理を停止し、このチャンク内のパラメーターをそれ以上処理せず、セクション3.2.2で説明されているように、「認識されないパラメーター」で認識されないパラメーターを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2.
11-このパラメーターをスキップして処理を続行しますが、セクション3.2.2で説明されているように、「認識されないパラメーター」で認識されないパラメーターを報告します。
Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk is sent. In the 00 or 01 case, the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
4つのケースすべてで、INIT ACKまたはCOOKIE ECHOチャンクが送信されることに注意してください。 00または01の場合、不明なパラメーターの後のパラメーターの処理は取り消されますが、既に行われた処理はロールバックされません。
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 14.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2.1). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk.
実際のSCTPパラメータは、特定のSCTPチャンクセクションで定義されます。 IETF定義のパラメータ拡張のルールは、セクション14.2で定義されています。パラメータタイプはすべてのチャンクで一意である必要があることに注意してください。たとえば、パラメータタイプ「5」は、IPv4アドレスを表すために使用されます（3.3.2.1項を参照）。次に、値「5」はIPv4アドレスを表すためにすべてのチャンクにわたって予約され、他のチャンクでは異なる意味で再利用してはいけません。
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in response to the INIT chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
INITチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、INITチャンクに応答して送信されるINIT ACKチャンクに「Unrecognized Parameter」パラメーターを配置する必要があります。 INITチャンクの受信側が関連付けを確立しない場合（リソースの不足など）、「Unrecognized Parameter」は、INITの送信側に送信されるABORTに含まれないことに注意してください。
If the receiver of an INIT ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE ACK has been received.
INIT ACKチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、「認識できないパラメーター」エラーの原因を含むERRORチャンクを、INIT ACKチャンクに応答して送信されるCOOKIE ECHOチャンクにバンドルする必要があります（SHOULD）。 。 INIT ACKの受信者がCOOKIE ECHOチャンクをERRORチャンクとバンドルできない場合、ERRORチャンクは個別に送信できますが、COOKIE ACKを受信する前に送信することはできません。
Note: Any time a COOKIE ECHO is sent in a packet, it MUST be the first chunk.
注：COOKIE ECHOがパケットで送信されるときは常に、それが最初のチャンクでなければなりません。
This section defines the format of the different SCTP chunk types.
このセクションでは、さまざまなSCTPチャンクタイプの形式を定義します。
The following format MUST be used for the DATA chunk:
DATAチャンクには次の形式を使用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits
予約済み：5ビット
Should be set to all '0's and ignored by the receiver.
すべて「0」に設定し、レシーバーで無視する必要があります。
U bit: 1 bit
Uビット：1ビット
The (U)nordered bit, if set to '1', indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field.
（U）順のビットは、「1」に設定されている場合、これが順不同のDATAチャンクであり、このDATAチャンクに割り当てられたストリームシーケンス番号がないことを示します。したがって、受信者はストリームシーケンス番号フィールドを無視する必要があります。
After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder.
再構成後（必要な場合）、順序付けされていないDATAチャンクは、順序付けを再試行することなく、レシーバーによって上位層にディスパッチされる必要があります。
If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to '1'.
順序付けられていないユーザーメッセージが断片化されている場合は、メッセージの各断片のUビットを「1」に設定する必要があります。
B bit: 1 bit
Bビット：1ビット
The (B)eginning fragment bit, if set, indicates the first fragment of a user message.
（B）開始フラグメントビットは、設定されている場合、ユーザーメッセージの最初のフラグメントを示します。
E bit: 1 bit
Eビット：1ビット
The (E)nding fragment bit, if set, indicates the last fragment of a user message.
（E）ndingフラグメントビットは、設定されている場合、ユーザーメッセージの最後のフラグメントを示します。
An unfragmented user message shall have both the B and E bits set to '1'. Setting both B and E bits to '0' indicates a middle fragment of a multi-fragment user message, as summarized in the following table:
フラグメント化されていないユーザーメッセージでは、BビットとEビットの両方が「1」に設定されている必要があります。 BビットとEビットの両方を「0」に設定すると、次の表に要約されているように、マルチフラグメントユーザーメッセージの中間フラグメントを示します。
B E Description
============================================================
| 1 0 | First piece of a fragmented user message |
+----------------------------------------------------------+
| 0 0 | Middle piece of a fragmented user message |
+----------------------------------------------------------+
| 0 1 | Last piece of a fragmented user message |
+----------------------------------------------------------+
| 1 1 | Unfragmented message |
============================================================
| Table 1: Fragment Description Flags |
============================================================
When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential.
ユーザーメッセージが複数のチャンクにフラグメント化されると、TSNは受信者がメッセージを再構成するために使用します。これは、断片化されたユーザーメッセージの各フラグメントのTSNが厳密に連続している必要があることを意味します。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes).
このフィールドは、タイプフィールドの先頭からユーザーデータフィールドの末尾までのDATAチャンクの長さをバイトで示します。ユーザーデータが1バイトのDATAチャンクでは、長さが17に設定されます（17バイトを示します）。
A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0.
長さLのユーザーデータフィールドを持つDATAチャンクは、長さフィールドが（16 + L）（16 + Lバイトを示す）に設定され、Lは0より大きい必要があります。
TSN: 32 bits (unsigned integer)
TSN：32ビット（符号なし整数）
This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295.
この値は、このDATAチャンクのTSNを表します。 TSNの有効範囲は0〜4294967295（2 ** 32-1）です。 TSNは、4294967295に達した後、0に戻ります。
Stream Identifier S: 16 bits (unsigned integer)
ストリーム識別子S：16ビット（符号なし整数）
Identifies the stream to which the following user data belongs.
次のユーザーデータが属するストリームを識別します。
Stream Sequence Number n: 16 bits (unsigned integer)
ストリームシーケンス番号n：16ビット（符号なし整数）
This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535.
この値は、ストリームS内の次のユーザーデータのストリームシーケンス番号を表します。有効な範囲は0〜65535です。
When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message.
ユーザーメッセージがトランスポートのためにSCTPによってフラグメント化されるとき、同じストリームシーケンス番号がメッセージの各フラグメントで運ばれる必要があります。
Payload Protocol Identifier: 32 bits (unsigned integer)
ペイロードプロトコル識別子：32ビット（符号なし整数）
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field.
この値は、アプリケーション（または上位層）が指定したプロトコル識別子を表します。この値は、上位層によってSCTPに渡され、ピアに送信されます。この識別子はSCTPでは使用されませんが、このDATAチャンクで伝送される情報のタイプを識別するために、特定のネットワークエンティティやピアアプリケーションで使用できます。このフィールドは、断片化されたDATAチャンクでも送信する必要があります（ネットワークの途中のエージェントが使用できるようにするため）。このフィールドはSCTP実装によって影響を受けないことに注意してください。したがって、そのバイト順は必ずしもビッグエンディアンではありません。上位層は、このフィールドへのバイト順変換を担当します。
The value 0 indicates that no application identifier is specified by the upper layer for this payload data.
値0は、このペイロードデータの上位層でアプリケーション識別子が指定されていないことを示します。
User Data: variable length
ユーザーデータ：可変長
This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding.
これはペイロードのユーザーデータです。実装は、データの終わりをすべてゼロのバイトで4バイト境界に埋め込む必要があります。長さフィールドにパディングを含めることはできません。送信者は、3バイトを超えるパディングを追加してはなりません（MUST）。
This chunk is used to initiate an SCTP association between two endpoints. The format of the INIT chunk is shown below:
このチャンクは、2つのエンドポイント間のSCTPアソシエーションを開始するために使用されます。 INITチャンクのフォーマットを以下に示します。
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 = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk.
INITチャンクには、次のパラメーターが含まれています。特に明記しない限り、各パラメーターはINITチャンクに1回だけ含める必要があります。
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Variable Parameters Status Type Value
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5 IPv6 Address
(Note 1) Optional 6 Cookie Preservative
Optional 9 Reserved for ECN Capable (Note 2) Optional
32768 (0x8000) Host Name Address (Note 3) Optional
11 Supported Address Types (Note 4) Optional 12
Note 1: The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination.
注1：INITチャンクには、IPv4またはIPv6、あるいはその両方を任意の組み合わせで使用できる複数のアドレスを含めることができます。
Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification.
注2：ECN Capableフィールドは、明示的な輻輳通知の将来の使用のために予約されています。
Note 3: An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk.
注3：INITチャンクに複数のホスト名アドレスパラメータを含めることはできません。さらに、INITの送信者は、他のアドレスタイプをINITのホスト名アドレスと組み合わせてはなりません（MUST NOT）。受信したINITチャンクにホスト名アドレスパラメータが存在する場合、INITの受信者は他のアドレスタイプを無視する必要があります。
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
注4：このパラメーターが存在する場合、送信エンドポイントがサポートできるすべてのアドレスタイプを指定します。このパラメーターがないことは、送信エンドポイントが任意のアドレスタイプをサポートできることを示しています。
IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk, then the receiver SHOULD process the INIT chunk and send back an INIT ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
実装上の注意：INITチャンクのオプションのパラメーターではない既知のパラメーターを使用してINITチャンクを受信した場合、受信者はINITチャンクを処理してINIT ACKを返信する必要があります（SHOULD）。 INITチャンクの受信者は、ERRORチャンクとCOOKIE ACKチャンクを後でバンドルする場合があります。ただし、制限のある実装は、INITチャンクへの応答としてABORTチャンクを送り返す場合があります。
The Chunk Flags field in INIT is reserved, and all bits in it should be set to 0 by the sender and ignored by the receiver. The sequence of parameters within an INIT can be processed in any order.
INITのチャンクフラグフィールドは予約されており、その中のすべてのビットは送信者によって0に設定され、受信者によって無視される必要があります。 INIT内の一連のパラメーターは、任意の順序で処理できます。
Initiate Tag: 32 bits (unsigned integer)
タグの開始：32ビット（符号なし整数）
The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association.
INITの受信側（応答側）は、Initiate Tagパラメータの値を記録します。この値は、INITの受信者がこの関連付け内で送信するすべてのSCTPパケットの検証タグフィールドに配置する必要があります。
The Initiate Tag is allowed to have any value except 0. See Section 5.3.1 for more on the selection of the tag value.
開始タグは、0以外の任意の値を持つことができます。タグ値の選択の詳細については、セクション5.3.1を参照してください。
If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT.
受信したINITチャンクのInitiate Tagの値が0であることがわかった場合、受信者はそれをエラーとして扱い、ABORTを送信して関連付けを閉じなければなりません（MUST）。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
アドバタイズされたレシーバーウィンドウクレジット（a_rwnd）：32ビット（符号なし整数）
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks.
この値は、INITの送信側がこのウィンドウに関連して予約した専用のバッファスペースをバイト数で表します。アソシエーションの存続期間中は、このバッファースペースを減らすべきではありません（つまり、このアソシエーションから削除された専用バッファー）。ただし、エンドポイントは、SACKチャンクで送信するa_rwndの値を変更する場合があります。
Number of Outbound Streams (OS): 16 bits (unsigned integer)
アウトバウンドストリーム数（OS）：16ビット（符号なし整数）
Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 MUST NOT be used.
このINITチャンクの送信者がこの関連付けで作成するアウトバウンドストリームの数を定義します。値0は使用してはなりません。
Note: A receiver of an INIT with the OS value set to 0 SHOULD abort the association.
注：OS値が0に設定されたINITの受信側は、関連付けを中止する必要があります（SHOULD）。
Number of Inbound Streams (MIS): 16 bits (unsigned integer)
インバウンドストリーム数（MIS）：16ビット（符号なし整数）
Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value 0 MUST NOT be used.
このINITチャンクの送信者がピア側がこの関連付けで作成できるストリームの最大数を定義します。値0は使用してはなりません。
Note: There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details.
注：実際のストリーム数のネゴシエーションはありませんが、代わりに2つのエンドポイントがmin（requested、offer）を使用します。詳細については、セクション5.1.1を参照してください。
Note: A receiver of an INIT with the MIS value of 0 SHOULD abort the association.
注：MIS値が0のINITの受信側は、関連付けを中止する必要があります（SHOULD）。
Initial TSN (I-TSN): 32 bits (unsigned integer)
初期TSN（I-TSN）：32ビット（符号なし整数）
Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field.
送信者が使用する初期TSNを定義します。有効な範囲は0〜4294967295です。このフィールドは、Initiate Tagフィールドの値に設定される場合があります。
The following parameters follow the Type-Length-Value format as defined in Section 3.2.1. Any Type-Length-Value fields MUST come after the fixed-length fields defined in the previous section.
次のパラメータは、セクション3.2.1で定義されているType-Length-Value形式に従います。 Type-Length-Valueフィールドは、前のセクションで定義された固定長フィールドの後に来る必要があります。
IPv4 Address Parameter (5)
IPv4アドレスパラメータ（5）
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 = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer)
IPv4アドレス：32ビット（符号なし整数）
Contains an IPv4 address of the sending endpoint. It is binary encoded.
送信エンドポイントのIPv4アドレスが含まれます。バイナリエンコードされています。
IPv6 Address Parameter (6)
IPv6アドレスパラメータ（6）
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 = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bits (unsigned integer)
IPv6アドレス：128ビット（符号なし整数）
Contains an IPv6 [RFC2460] address of the sending endpoint. It is binary encoded.
送信エンドポイントのIPv6 [RFC2460]アドレスが含まれています。バイナリエンコードされています。
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but should instead use an IPv4 Address parameter for an IPv4 address.
注：送信者はIPv4にマップされたIPv6アドレス[RFC4291]を使用してはなりません（MUST）。代わりに、IPv4アドレスのIPv4アドレスパラメータを使用する必要があります。
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the life time of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT.
SCTP共通ヘッダーの送信元ポート番号と組み合わせて、IPv4またはIPv6アドレスパラメータで渡される値は、INITの送信者が開始される関連付けに対してサポートするトランスポートアドレスを示します。つまり、この関連付けの存続期間中、このIPアドレスは、INITの送信側から送信されたIPデータグラムの送信元アドレスフィールドに表示され、受信側から送信されたIPデータグラムの宛先アドレスとして使用できます。 INIT。
More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-homed. Moreover, a multi-homed endpoint may have access to different types of network; thus, more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk.
INIT送信側がマルチホームの場合、INITチャンクに複数のIPアドレスパラメータを含めることができます。さらに、マルチホームのエンドポイントは、さまざまなタイプのネットワークにアクセスできます。したがって、1つのINITチャンクに複数のアドレスタイプを含めることができます。つまり、同じINITチャンクでIPv4アドレスとIPv6アドレスを使用できます。
If the INIT contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT chunk and any additional address(es) provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT MUST use the source address associated with the received IP datagram as its sole destination address for the association.
INITに少なくとも1つのIPアドレスパラメータが含まれている場合、INITチャンクを含むIPデータグラムのソースアドレスと、INIT内で提供される追加のアドレスを、INITを受信するエンドポイントが宛先として使用できます。 INITにIPアドレスパラメータが含まれていない場合、INITを受信するエンドポイントは、受信したIPデータグラムに関連付けられているソースアドレスを、関連付けの唯一の宛先アドレスとして使用する必要があります。
Note that not using any IP Address parameters in the INIT and INIT ACK is an alternative to make an association more likely to work across a NAT box.
INITおよびINIT ACKでIPアドレスパラメータを使用しないことは、NATボックス全体でアソシエーションが機能する可能性を高める代替手段であることに注意してください。
Cookie Preservative (9)
クッキー防腐剤（9）
The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie.
INITの送信側は、このパラメーターを使用して、状態Cookieの寿命を延長するようINITの受信側に提案します。
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 = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-Span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)
推奨されるCookieの有効期間の増分：32ビット（符号なし整数）
This parameter indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span.
このパラメーターは、送信者が受信者にデフォルトのCookieの有効期間に追加することを希望するミリ秒単位の増分を受信者に示します。
This optional parameter should be added to the INIT chunk by the sender when it reattempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons.
このオプションのパラメーターは、古いcookie操作エラーのために関連付けを確立するための以前の試行が失敗したピアとの関連付けの確立を再試行するときに、送信者がINITチャンクに追加する必要があります。受信者は、独自のセキュリティ上の理由から、推奨されるCookieの寿命の延長を無視することを選択できます（MAY）。
Host Name Address (11)
ホスト名アドレス（11）
The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box.
INITの送信側はこのパラメーターを使用して、（IPアドレスの代わりに）ホスト名をピアに渡します。ピアは名前を解決する責任があります。このパラメーターを使用すると、関連付けがNATボックス全体で機能する可能性が高くなります。
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 = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name: variable length
ホスト名：可変長
This field contains a host name in "host name syntax" per RFC 1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP.
このフィールドには、RFC 1123セクション2.1 [RFC1123]に基づく「ホスト名構文」のホスト名が含まれています。ホスト名を解決する方法はSCTPの範囲外です。
Note: At least one null terminator is included in the Host Name string and must be included in the length.
注：少なくとも1つのヌルターミネーターがホスト名文字列に含まれており、長さに含まれている必要があります。
Supported Address Types (12)
サポートされているアドレスの種類（12）
The sender of INIT uses this parameter to list all the address types it can support.
INITの送信側は、このパラメーターを使用して、サポートできるすべてのアドレスタイプをリストします。
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 = 12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Address Type: 16 bits (unsigned integer)
アドレスタイプ：16ビット（符号なし整数）
This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
これには、対応するアドレスTLVのタイプ値が入力されます（たとえば、IPv4 = 5、IPv6 = 6、ホスト名= 11）。
The INIT ACK chunk is used to acknowledge the initiation of an SCTP association.
INIT ACKチャンクは、SCTPアソシエーションの開始を確認するために使用されます。
The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The State Cookie and the Unrecognized Parameter: The format of the INIT ACK chunk is shown below:
INIT ACKのパラメーター部分は、INITチャンクと同様にフォーマットされます。 2つの追加の変数パラメーターを使用します：状態Cookieと認識されないパラメーター：INIT ACKチャンクの形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag: 32 bits (unsigned integer)
タグの開始：32ビット（符号なし整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACKの受信側は、Initiate Tagパラメータの値を記録します。この値は、このアソシエーション内でINIT ACKレシーバーが送信するすべてのSCTPパケットの検証タグフィールドに配置する必要があります。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
開始タグは値0をとってはなりません。開始タグ値の選択の詳細については、セクション5.3.1を参照してください。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose.
受信したINIT ACKチャンクのInitiate Tagの値が0であることがわかった場合、受信者はそのTCBを破棄する関連付けを破棄する必要があります。受信者はデバッグ目的でABORTを送信してもよい（MAY）。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
アドバタイズされたレシーバーウィンドウクレジット（a_rwnd）：32ビット（符号なし整数）
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association).
この値は、このウィンドウに関連してINIT ACKの送信者が予約した専用バッファースペースをバイト数で表します。アソシエーションの存続期間中は、このバッファースペースを減らすべきではありません（つまり、このアソシエーションから削除された専用バッファー）。
Number of Outbound Streams (OS): 16 bits (unsigned integer)
アウトバウンドストリーム数（OS）：16ビット（符号なし整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk.
このアソシエーションでこのINIT ACKチャンクの送信者が作成したいアウトバウンドストリームの数を定義します。値0は使用してはならず（MUST NOT）、その値はINITチャンクで送信されたMIS値よりも大きくしてはなりません（MUST NOT）。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
注：OS値が0に設定されたINIT ACKの受信者は、そのTCBを破棄して関連付けを破棄する必要があります（SHOULD）。
Number of Inbound Streams (MIS): 16 bits (unsigned integer)
インバウンドストリーム数（MIS）：16ビット（符号なし整数）
Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used.
このINIT ACKチャンクの送信者がこの関連付けでピアエンドが作成できるストリームの最大数を定義します。値0は使用してはなりません。
Note: There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details.
注：実際のストリーム数のネゴシエーションはありませんが、代わりに2つのエンドポイントがmin（requested、offer）を使用します。詳細については、セクション5.1.1を参照してください。
Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB.
注：MIS値が0に設定されたINIT ACKの受信者は、そのTCBを破棄して関連付けを破棄する必要があります（SHOULD）。
Initial TSN (I-TSN): 32 bits (unsigned integer)
初期TSN（I-TSN）：32ビット（符号なし整数）
Defines the initial TSN that the INIT ACK sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field.
INIT ACK送信側が使用する初期TSNを定義します。有効な範囲は0〜4294967295です。このフィールドは、Initiate Tagフィールドの値に設定される場合があります。
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Note 1: The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination.
注1：INIT ACKチャンクには、任意の数のIPv4またはIPv6、あるいはその両方の組み合わせが可能なIPアドレスパラメータをいくつでも含めることができます。
Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification.
注2：ECN Capableフィールドは、明示的な輻輳通知の将来の使用のために予約されています。
Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present.
注3：INIT ACKチャンクには、複数のホスト名アドレスパラメータを含めることはできません。さらに、INIT ACKの送信者は、他のアドレスタイプをINIT ACKのホスト名アドレスと組み合わせてはなりません（MUST NOT）。 INIT ACKの受信者は、Host Name Addressパラメータが存在する場合、他のアドレスタイプを無視する必要があります。
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive an INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the State Cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
実装上の注意：ステートCookieの可変サイズと可変アドレスリストにより、非常に大きい（1500バイトを超える）INIT ACKを受信できるように実装を準備する必要があります。たとえば、INITへのレスポンダに送信したいIPv4アドレスが1000ある場合、これをINIT ACKにエンコードするには少なくとも8,000バイトが必要です。
IMPLEMENTATION NOTE: If an INIT ACK chunk is received with known parameters that are not optional parameters of the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the COOKIE ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT ACK chunk.
実装上の注意：INIT ACKチャンクのオプションパラメータではない既知のパラメータを使用してINIT ACKチャンクを受信した場合、受信者はINIT ACKチャンクを処理してCOOKIE ECHOを送信する必要があります（SHOULD）。 INIT ACKチャンクのレシーバーは、ERRORチャンクをCOOKIE ECHOチャンクにバンドルしてもよい（MAY）。ただし、制限的な実装では、INIT ACKチャンクへの応答としてABORTチャンクを送り返す場合があります。
In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the life time of the association being initiated.
SCTP共通ヘッダーで送信される送信元ポートと組み合わせて、INIT ACKの各IPアドレスパラメータは、INIT ACKの受信者に、開始されるアソシエーションの存続期間中、INIT ACKの送信者によってサポートされる有効なトランスポートアドレスを示します。
If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association.
INIT ACKに少なくとも1つのIPアドレスパラメータが含まれている場合、INIT ACKを含むIPデータグラムの送信元アドレスと、INIT ACK内で提供される追加のアドレスは、INIT ACKの受信者が宛先として使用できます。 INIT ACKにIPアドレスパラメータが含まれていない場合、INIT ACKの受信者は、受信したIPデータグラムに関連付けられているソースアドレスを、関連付けの唯一の宛先アドレスとして使用する必要があります。
The State Cookie and Unrecognized Parameters use the Type-Length-Value format as defined in Section 3.2.1 and are described below. The other fields are defined the same as their counterparts in the INIT chunk.
状態Cookieと認識されないパラメーターは、セクション3.2.1で定義されているType-Length-Value形式を使用します。他のフィールドは、INITチャンクの対応するフィールドと同じように定義されます。
State Cookie
州のクッキー
Parameter Type Value: 7
パラメータタイプ値：7
Parameter Length: Variable size, depending on size of Cookie.
パラメータの長さ：Cookieのサイズに応じて可変サイズ。
Parameter Value:
パラメータ値：
This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition.
このパラメーター値には、このINIT ACKの送信者が関連付けを作成するために必要なすべての必要な状態およびパラメーター情報を、メッセージ認証コード（MAC）とともに含める必要があります。状態Cookieの定義の詳細については、セクション5.1.3を参照してください。
Unrecognized Parameter:
認識されないパラメータ：
Parameter Type Value: 8
パラメータタイプ値：8
Parameter Length: Variable size.
パラメータの長さ：可変サイズ。
Parameter Value:
パラメータ値：
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
送信者に報告する必要があることを示す値を持つ認識されないパラメーターがINITに含まれている場合、このパラメーターはINITチャンクの発信者に返されます。このパラメーター値フィールドには、パラメータータイプ、長さ、および値のフィールドを備えたINITチャンクからコピーされた認識されないパラメーターが含まれます。
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs.
このチャンクはピアエンドポイントに送信され、受信したDATAチャンクを確認し、ピアエンドポイントにTSNで表されるDATAチャンクの受信したサブシーケンスのギャップを通知します。
The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields.
SACKには、累積TSN Ack、アドバタイズされた受信側ウィンドウクレジット（a_rwnd）、ギャップAckブロックの数、および重複TSNフィールドの数が含まれている必要があります。
By definition, the value of the Cumulative TSN Ack parameter is the last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value.
定義により、累積TSN Ackパラメータの値は、受信したTSNのシーケンスの中断が発生する前に受信した最後のTSNです。これに続く次のTSN値は、SACKを送信するエンドポイントでまだ受信されていません。したがって、このパラメーターは、その値以下のすべてのTSNの受信を確認します。
The handling of a_rwnd by the receiver of the SACK is discussed in detail in Section 6.2.1.
SACKの受信側によるa_rwndの処理については、セクション6.2.1で詳しく説明します。
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
SACKには0個以上のギャップACKブロックも含まれます。各ギャップACKブロックは、受信したTSNのシーケンスの中断に続いて、受信したTSNのサブシーケンスを確認します。定義により、ギャップACKブロックによって確認応答されたすべてのTSNは、累積TSN ACKの値よりも大きくなります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to all '0's on transmit and ignored on receipt.
送信時にはすべて「0」に設定され、受信時には無視されます。
Cumulative TSN Ack: 32 bits (unsigned integer)
累積TSN Ack：32ビット（符号なし整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one.
このパラメータには、ギャップの前に順番に受信された最後のDATAチャンクのTSNが含まれています。 DATAチャンクが受信されなかった場合、この値はピアの初期TSN-1に設定されます。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
アドバタイズされたレシーバーウィンドウクレジット（a_rwnd）：32ビット（符号なし整数）
This field indicates the updated receive buffer space in bytes of the sender of this SACK; see Section 6.2.1 for details.
このフィールドは、このSACKの送信側の更新された受信バッファースペースをバイト単位で示します。詳細については、セクション6.2.1を参照してください。
Number of Gap Ack Blocks: 16 bits (unsigned integer)
ギャップACKブロックの数：16ビット（符号なし整数）
Indicates the number of Gap Ack Blocks included in this SACK.
このSACKに含まれるギャップACKブロックの数を示します。
Number of Duplicate TSNs: 16 bit
重複TSNの数：16ビット
This field contains the number of duplicate TSNs the endpoint has received. Each duplicate TSN is listed following the Gap Ack Block list.
このフィールドには、エンドポイントが受信した重複TSNの数が含まれます。重複するTSNはそれぞれ、Gap Ack Blockリストに続いてリストされます。
Gap Ack Blocks:
ギャップACKブロック：
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly.
これらのフィールドには、ギャップACKブロックが含まれます。これらは、各ギャップACKブロックについて、[ギャップACKブロックの数]フィールドで定義されたギャップACKブロックの数まで繰り返されます。各Gap Ackブロックの（累積TSN Ack +ギャップAckブロックの開始）以上で（累積TSN Ack +ギャップAckブロックの終了）以下のTSNを持つすべてのDATAチャンクは、正しく受信されたと見なされます。
Gap Ack Block Start: 16 bits (unsigned integer)
ギャップ確認ブロック開始：16ビット（符号なし整数）
Indicates the Start offset TSN for this Gap Ack Block. To calculate the actual TSN number the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the first TSN in this Gap Ack Block that has been received.
このギャップACKブロックの開始オフセットTSNを示します。実際のTSN番号を計算するために、累積TSN Ackがこのオフセット番号に追加されます。この計算されたTSNは、このギャップACKブロック内で受信された最初のTSNを識別します。
Gap Ack Block End: 16 bits (unsigned integer)
ギャップ確認ブロック終了：16ビット（符号なし整数）
Indicates the End offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block.
このギャップACKブロックの終了オフセットTSNを示します。実際のTSN番号を計算するために、累積TSN Ackがこのオフセット番号に追加されます。この計算されたTSNは、このギャップACKブロックで受信された最後のDATAチャンクのTSNを識別します。
For example, assume that the receiver has the following DATA chunks newly arrived at the time when it decides to send a Selective ACK,
たとえば、選択的ACKを送信することを決定したときに、受信者が次のDATAチャンクを新たに到着したとします。
----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------
then the parameter part of the SACK MUST be constructed as follows (assuming the new a_rwnd is set to 4660 by the sender):
次に、SACKのパラメータ部分を次のように構築する必要があります（新しいa_rwndが送信者によって4660に設定されていると想定）。
+--------------------------------+
| Cumulative TSN Ack = 12 |
+--------------------------------+
| a_rwnd = 4660 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+
Duplicate TSN: 32 bits (unsigned integer)
重複TSN：32ビット（符号なし整数）
Indicates the number of times a TSN was received in duplicate since the last SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK), it adds it to the list of duplicates. The duplicate count is reinitialized to zero after sending each SACK.
最後のSACKが送信されてからTSNが重複して受信された回数を示します。レシーバーは（SACKを送信する前に）重複したTSNを取得するたびに、重複したTSNを重複のリストに追加します。重複カウントは、各SACKを送信した後にゼロに再初期化されます。
For example, if a receiver were to get the TSN 19 three times it would list 19 twice in the outbound SACK. After sending the SACK, if it received yet one more TSN 19 it would list 19 as a duplicate once in the next outgoing SACK.
たとえば、受信者がTSN 19を3回取得した場合、送信SACKに19が2回リストされます。 SACKを送信した後、さらに1つのTSN 19を受信した場合、次の発信SACKで19を重複として一度にリストします。
An endpoint should send this chunk to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association.
エンドポイントはこのチャンクをピアエンドポイントに送信して、現在の関連付けで定義されている特定の宛先トランスポートアドレスの到達可能性を調査する必要があります。
The parameter field contains the Heartbeat Information, which is a variable-length opaque data structure understood only by the sender.
パラメータフィールドには、送信者だけが理解できる可変長の不透明なデータ構造であるハートビート情報が含まれています。
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 = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
Heartbeat Length: 16 bits (unsigned integer)
ハートビートの長さ：16ビット（符号なし整数）
Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field.
チャンクヘッダーとハートビート情報フィールドを含む、チャンクのサイズをバイト単位で設定します。
Heartbeat Information: variable length
ハートビート情報：可変長
Defined as a variable-length parameter using the format described in Section 3.2.1, i.e.:
セクション3.2.1で説明されている形式を使用して、可変長パラメーターとして定義されます。
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-Specific Heartbeat Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-Specific Heartbeat Info field should normally include information about the sender's current time when this HEARTBEAT chunk is sent and the destination transport address to which this HEARTBEAT is sent (see Section 8.3). This information is simply reflected back by the receiver in the HEARTBEAT ACK message (see Section 3.3.6). Note also that the HEARTBEAT message is both for reachability checking and for path verification (see Section 5.4). When a HEARTBEAT chunk is being used for path verification purposes, it MUST hold a 64-bit random nonce.
送信者固有のハートビート情報フィールドには、通常、このHEARTBEATチャンクが送信される送信者の現在時刻と、このHEARTBEATが送信される宛先トランスポートアドレスに関する情報が含まれている必要があります（セクション8.3を参照）。この情報は、受信者によってHEARTBEAT ACKメッセージに単純に反映されます（セクション3.3.6を参照）。また、HEARTBEATメッセージは到達可能性チェックとパス検証の両方に使用されることにも注意してください（セクション5.4を参照）。 HEARTBEATチャンクがパス検証の目的で使用されている場合、64ビットのランダムnonceを保持する必要があります。
An endpoint should send this chunk to its peer endpoint as a response to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the HEARTBEAT chunk to which this ack is responding.
エンドポイントは、HEARTBEATチャンクへの応答としてこのチャンクをピアエンドポイントに送信する必要があります（セクション8.3を参照）。 HEARTBEAT ACKは常に、このackが応答するHEARTBEATチャンクを含むIPデータグラムのソースIPアドレスに送信されます。
The parameter field contains a variable-length opaque data structure.
パラメータフィールドには、可変長の不透明なデータ構造が含まれます。
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 = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
Heartbeat Ack Length: 16 bits (unsigned integer)
ハートビート肯定応答の長さ：16ビット（符号なし整数）
Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field.
チャンクヘッダーとハートビート情報フィールドを含む、チャンクのサイズをバイト単位で設定します。
Heartbeat Information: variable length
ハートビート情報：可変長
This field MUST contain the Heartbeat Information parameter of the Heartbeat Request to which this Heartbeat Acknowledgement is responding.
このフィールドには、このハートビート確認応答が応答するハートビート要求のハートビート情報パラメーターが含まれている必要があります。
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver about the reason of the abort. DATA chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be placed before the ABORT in the SCTP packet or they will be ignored by the receiver.
ABORTチャンクは、アソシエーションのピアに送信され、アソシエーションを閉じます。 ABORTチャンクには、中止の理由をレシーバーに通知する原因パラメーターが含まれている場合があります。 DATAチャンクはABORTにバンドルしてはなりません（MUST NOT）。制御チャンク（INIT、INIT ACK、およびSHUTDOWN COMPLETEを除く）はABORTにバンドルされる場合がありますが、SCTPパケットのABORTの前に配置する必要があります。そうしないと、受信側で無視されます。
If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own.
エンドポイントがフォーマットエラーのあるABORTを受け取った場合、またはTCBが見つからなかった場合、エンドポイントはそれを黙って破棄する必要があります。さらに、どのような状況でも、ABORTを受信するエンドポイントは、独自のABORTを送信してそのABORTに応答してはなりません。
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 = 6 |Reserved |T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Reserved: 7 bits
予約済み：7ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
T bit: 1 bit
Tビット：1ビット
The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
送信者がピアが予期する検証タグを入力した場合、Tビットは0に設定されます。検証タグが反映されている場合、Tビットは1に設定する必要があります。反映とは、送信された検証タグが受信した検証タグと同じであることを意味します。
Note: Special rules apply to this chunk for verification; please see Section 8.5.1 for details.
注：検証のためにこのチャンクには特別なルールが適用されます。詳細については、セクション8.5.1を参照してください。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
チャンクヘッダーと存在するすべてのエラー原因フィールドを含む、バイト単位のチャンクのサイズに設定します。
See Section 3.3.10 for Error Cause definitions.
エラー原因の定義については、セクション3.3.10を参照してください。
An endpoint in an association MUST use this chunk to initiate a graceful close of the association with its peer. This chunk has the following format.
アソシエーションのエンドポイントは、このチャンクを使用して、ピアとのアソシエーションの正常なクローズを開始する必要があります。このチャンクの形式は次のとおりです。
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 = 7 | Chunk Flags | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
Indicates the length of the parameter. Set to 8.
パラメータの長さを示します。 8に設定します。
Cumulative TSN Ack: 32 bits (unsigned integer)
累積TSN Ack：32ビット（符号なし整数）
This parameter contains the TSN of the last chunk received in sequence before any gaps.
このパラメーターには、ギャップの前に順番に受信された最後のチャンクのTSNが含まれます。
Note: Since the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be used to acknowledge TSNs received out of order. In a SACK, lack of Gap Ack Blocks that were previously included indicates that the data receiver reneged on the associated DATA chunks. Since SHUTDOWN does not contain Gap Ack Blocks, the receiver of the SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege. (See Section 6.2 for information on reneging.)
注：SHUTDOWNメッセージにはギャップACKブロックが含まれていないため、順不同で受信したTSNの確認には使用できません。 SACKで、以前に含まれていたギャップACKブロックがないことは、データレシーバーが関連付けられたDATAチャンクを破棄したことを示します。 SHUTDOWNにはギャップACKブロックが含まれていないため、SHUTDOWNの受信者はギャップACKブロックの欠如を根拠として解釈してはなりません。 （破棄の詳細については、セクション6.2を参照してください。）
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process; see Section 9.2 for details.
このチャンクは、シャットダウンプロセスの完了時にSHUTDOWNチャンクの受信を確認するために使用する必要があります。詳細については、セクション9.2を参照してください。
The SHUTDOWN ACK chunk has no parameters.
SHUTDOWN ACKチャンクにはパラメーターがありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions. It contains one or more error causes. An Operation Error is not considered fatal in and of itself, but may be used with an ABORT chunk to report a fatal condition. It has the following parameters:
エンドポイントはこのチャンクをピアエンドポイントに送信して、特定のエラー状態を通知します。 1つ以上のエラー原因が含まれています。操作エラー自体は致命的とは見なされませんが、ABORTチャンクと一緒に使用して致命的な状態を報告できます。次のパラメーターがあります。
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 = 9 | Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ one or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
チャンクヘッダーと存在するすべてのエラー原因フィールドを含む、バイト単位のチャンクのサイズに設定します。
Error causes are defined as variable-length parameters using the format described in Section 3.2.1, that is:
エラーの原因は、セクション3.2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-Specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code: 16 bits (unsigned integer)
原因コード：16ビット（符号なし整数）
Defines the type of error conditions being reported.
報告されるエラー状態のタイプを定義します。
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields.
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します。
Cause-Specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 14.3.
セクション3.3.10.1-セクション3.3.10.13は、SCTPのエラー原因を定義します。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション14.3で説明します。
Cause of error
---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk sent to a nonexistent stream.
無効なストリーム識別子：存在しないストリームに送信されたDATAチャンクをエンドポイントが受信したことを示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream Identifier: 16 bits (unsigned integer)
ストリーム識別子：16ビット（符号なし整数）
Contains the Stream Identifier of the DATA chunk received in error.
エラーで受信されたDATAチャンクのストリーム識別子が含まれます。
Reserved: 16 bits
予約済み：16ビット
This field is reserved. It is set to all 0's on transmit and ignored on receipt.
このフィールドは予約されています。送信時にはすべて0に設定され、受信時には無視されます。
Cause of error
---------------
Missing Mandatory Parameter: Indicates that one or more mandatory TLV parameters are missing in a received INIT or INIT ACK.
欠落している必須パラメーター：受信したINITまたはINIT ACKで1つ以上の必須TLVパラメーターが欠落していることを示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Missing params: 32 bits (unsigned integer)
欠落しているパラメーターの数：32ビット（符号なし整数）
This field contains the number of parameters contained in the Cause-Specific Information field.
このフィールドには、Cause-Specific Informationフィールドに含まれているパラメーターの数が含まれています。
Missing Param Type: 16 bits (unsigned integer)
パラメータタイプがありません：16ビット（符号なし整数）
Each field will contain the missing mandatory parameter number.
各フィールドには、欠落している必須パラメーター番号が含まれます。
Cause of error
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie that has expired.
古いCookieエラー：有効期限が切れた有効な状態Cookieの受信を示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness: 32 bits (unsigned integer)
古さの測定：32ビット（符号なし整数）
This field contains the difference, in microseconds, between the current time and the time the State Cookie expired.
このフィールドには、現在の時刻と状態Cookieの有効期限が切れた時刻の差がマイクロ秒単位で含まれています。
The sender of this error cause MAY choose to report how long past expiration the State Cookie is by including a non-zero value in the Measure of Staleness field. If the sender does not wish to provide this information, it should set the Measure of Staleness field to the value of zero.
このエラーの原因の送信者は、「古さの測定」フィールドにゼロ以外の値を含めることにより、状態Cookieの有効期限が経過した期間を報告することを選択できます（MAY）。送信者がこの情報を提供したくない場合は、[古さの測定]フィールドをゼロの値に設定する必要があります。
Cause of error
---------------
Out of Resource: Indicates that the sender is out of resource. This is usually sent in combination with or within an ABORT.
リソース不足：送信者がリソース不足であることを示します。これは通常、ABORTと組み合わせて、またはABORT内で送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
Unresolvable Address: Indicates that the sender is not able to resolve the specified address parameter (e.g., type of address is not supported by the sender). This is usually sent in combination with or within an ABORT.
解決できないアドレス：送信者が指定されたアドレスパラメータを解決できないことを示します（たとえば、アドレスのタイプは送信者によってサポートされていません）。これは通常、ABORTと組み合わせて、またはABORT内で送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unresolvable Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unresolvable Address: variable length
解決できないアドレス：可変長
The Unresolvable Address field contains the complete Type, Length, and Value of the address parameter (or Host Name parameter) that contains the unresolvable address or host name.
解決できないアドレスフィールドには、解決できないアドレスまたはホスト名を含むアドレスパラメータ（またはホスト名パラメータ）の完全なタイプ、長さ、および値が含まれます。
Cause of error
---------------
Unrecognized Chunk Type: This error cause is returned to the originator of the chunk if the receiver does not understand the chunk and the upper bits of the 'Chunk Type' are set to 01 or 11.
Unrecognized Chunk Type：このエラーの原因は、受信者がチャンクを理解せず、「チャンクタイプ」の上位ビットが01または11に設定されている場合、チャンクの発信者に返されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk: variable length
認識されないチャンク：可変長
The Unrecognized Chunk field contains the unrecognized chunk from the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk Length.
Unrecognized Chunkフィールドには、チャンクタイプ、チャンクフラグ、およびチャンク長を備えたSCTPパケットからの認識されないチャンクが含まれます。
Cause of error
---------------
Invalid Mandatory Parameter: This error cause is returned to the originator of an INIT or INIT ACK chunk when one of the mandatory parameters is set to an invalid value.
無効な必須パラメーター：このエラーの原因は、必須パラメーターの1つが無効な値に設定されている場合、INITまたはINIT ACKチャンクの発信者に返されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the originator of the INIT ACK chunk if the receiver does not recognize one or more Optional TLV parameters in the INIT ACK chunk.
認識されないパラメーター：このエラー原因は、レシーバーがINIT ACKチャンク内の1つ以上のオプションのTLVパラメーターを認識しない場合、INIT ACKチャンクの発信者に返されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Parameters: variable length
認識されないパラメーター：可変長
The Unrecognized Parameters field contains the unrecognized parameters copied from the INIT ACK chunk complete with TLV. This error cause is normally contained in an ERROR chunk bundled with the COOKIE ECHO chunk when responding to the INIT ACK, when the sender of the COOKIE ECHO chunk wishes to report unrecognized parameters.
Unrecognized Parametersフィールドには、TLVを備えたINIT ACKチャンクからコピーされた認識されないパラメーターが含まれています。このエラーの原因は、通常、INIT ACKに応答するときにCOOKIE ECHOチャンクにバンドルされているERRORチャンクに含まれています。このとき、COOKIE ECHOチャンクの送信者は、認識されないパラメーターを報告します。
Cause of error
---------------
No User Data: This error cause is returned to the originator of a
ユーザーデータなし：このエラー原因は、
DATA chunk if a received DATA chunk has no user data.
受信したDATAチャンクにユーザーデータがない場合は、DATAチャンク。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSN value: 32 bits (unsigned integer)
TSN値：32ビット（符号なし整数）
The TSN value field contains the TSN of the DATA chunk received with no user data field.
TSN値フィールドには、ユーザーデータフィールドなしで受信したDATAチャンクのTSNが含まれます。
This cause code is normally returned in an ABORT chunk (see Section 6.2).
この原因コードは通常、ABORTチャンクで返されます（セクション6.2を参照）。
Cause of error
---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received while the endpoint was in the SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK.
シャットダウン中に受信したCookie：エンドポイントがSHUTDOWN-ACK-SENT状態のときにCOOKIE ECHOを受信しました。このエラーは通常、再送信されたSHUTDOWN ACKにバンドルされているERRORチャンクで返されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
--------------
Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The new addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see Section 5.2).
新しいアドレスとの関連付けの再開：既存の関連付けでINITが受信されました。しかし、INITは以前は関連付けの一部ではなかったアドレスを関連付けに追加しました。新しいアドレスはエラーコードにリストされます。このエラーは通常、INITを拒否するABORTの一部として送信されます（セクション5.2を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter Length.
注：各新しいアドレスTLVは、パラメータータイプやパラメーター長を含む、新しいINITチャンクで見つかったTLVの正確なコピーです。
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper-layer protocol at the peer.
このエラーの原因は、上位層の要求が原因で送信されるABORTチャンクに含まれる場合があります。上位層は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in Section 3.3.10.1 to Section 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected.
SCTPエンドポイントが、セクション3.3.10.1からセクション3.3.10.12で説明されているエラー原因でカバーされていないピアのプロトコル違反を検出するため、このエラー原因は送信されるABORTチャンクに含まれる場合があります。実装は、検出されたプロトコル違反の種類を指定する追加情報を提供する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks in the same packet.
このチャンクは、関連付けの初期化中にのみ使用されます。アソシエーションのイニシエーターによってピアに送信され、初期化プロセスを完了します。このチャンクは、アソシエーション内で送信されるDATAチャンクの前になければなりません（MUST）が、同じパケット内の1つ以上のDATAチャンクにバンドルされる場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cookie /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bit
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the size of the cookie.
チャンクヘッダーの4バイトとCookieのサイズを含む、チャンクのサイズをバイト単位で設定します。
Cookie: variable size
Cookie：可変サイズ
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
このフィールドには、以前のINIT ACKからState Cookieパラメータで受け取った正確なCookieが含まれている必要があります。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
実装は相互運用性を保証するためにCookieを可能な限り小さくする必要があります（SHOULD）。
Note: A Cookie Echo does NOT contain a State Cookie parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first 2 bytes of the State Cookie parameter to become a COOKIE ECHO chunk.
注：Cookieエコーには、State Cookieパラメーターは含まれていません。代わりに、状態Cookieのパラメーター値内のデータは、Cookieエコーのチャンク値内のデータになります。これにより、実装でState Cookieパラメータの最初の2バイトのみを変更してCOOKIE ECHOチャンクにすることができます。
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks or SACK chunk's in the same SCTP packet.
このチャンクは、関連付けの初期化中にのみ使用されます。 COOKIE ECHOチャンクの受信を確認するために使用されます。このチャンクは、アソシエーション内で送信されるDATAまたはSACKチャンクの前になければなりません（MUST）が、同じSCTPパケット内の1つ以上のDATAチャンクまたはSACKチャンクとバンドルされる場合があります。
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 = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process; see Section 9.2 for details.
このチャンクは、シャットダウンプロセスの完了時にSHUTDOWN ACKチャンクの受信を確認するために使用する必要があります。詳細については、セクション9.2を参照してください。
The SHUTDOWN COMPLETE chunk has no parameters.
SHUTDOWN COMPLETEチャンクにはパラメーターがありません。
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 = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
チャンクフラグ：8ビット
Reserved: 7 bits
予約済み：7ビット
Set to 0 on transmit and ignored on receipt.
送信時には0に設定され、受信時には無視されます。
T bit: 1 bit
Tビット：1ビット
The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
送信者がピアが予期する検証タグを入力した場合、Tビットは0に設定されます。検証タグが反映されている場合、Tビットは1に設定する必要があります。反映とは、送信された検証タグが受信した検証タグと同じであることを意味します。
Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details.
注：このチャンクには検証のための特別なルールが適用されます。詳細については、セクション8.5.1を参照してください。
During the life time of an SCTP association, the SCTP endpoint's association progresses from one state to another in response to various events. The events that may potentially advance an association's state include:
SCTPアソシエーションの存続期間中、SCTPエンドポイントのアソシエーションは、さまざまなイベントに応じて、ある状態から別の状態に進みます。協会の状態を進める可能性のあるイベントには、次のものがあります。
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o SCTPユーザープリミティブコール、たとえば、[ASSOCIATE]、[SHUTDOWN]、[ABORT]、
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control chunks, or
o INIT、COOKIE ECHO、ABORT、SHUTDOWNなどの受信、チャンクの制御、または
o Some timeout events.
o 一部のタイムアウトイベント。
The state diagram in the figures below illustrates state changes, together with the causing events and resulting actions. Note that some of the error conditions are not shown in the state diagram. Full descriptions of all special cases are found in the text.
以下の図の状態図は、状態の変化を、原因となるイベントと結果のアクションとともに示しています。一部のエラー状態は状態図に表示されないことに注意してください。すべての特殊なケースの完全な説明は、テキストに記載されています。
Note: Chunk names are given in all capital letters, while parameter names have the first letter capitalized, e.g., COOKIE ECHO chunk type vs. State Cookie parameter. If more than one event/message can occur that causes a state transition, it is labeled (A), (B), etc.
注：チャンク名はすべて大文字で表記されていますが、パラメーター名の最初の文字は大文字になっています（例：COOKIE ECHOチャンクタイプとState Cookieパラメーター）。状態遷移を引き起こす複数のイベント/メッセージが発生する可能性がある場合は、（A）、（B）などのラベルが付けられます。
----- -------- (from any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
| | (D)rcv SHUTDOWN ACK
| |--------------
| | stop shutdown timer
| | send SHUTDOWN COMPLETE
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+
Figure 3: State Transition Diagram of SCTP
図3：SCTPの状態遷移図
Notes:
ノート：
1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state.
1）受信したCOOKIE ECHOの状態Cookieが無効である（つまり、整合性チェックに合格しなかった）場合、受信者は静かにパケットを破棄する必要があります。または、受信した状態Cookieが期限切れの場合（セクション5.1.5を参照）、受信者はERRORチャンクを返送しなければなりません（MUST）。どちらの場合も、レシーバーはCLOSED状態のままです。
2) If the T1-init timer expires, the endpoint MUST retransmit INIT and restart the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user.
2）T1-initタイマーの期限が切れた場合、エンドポイントはINITを再送信し、状態を変更せずにT1-initタイマーを再起動する必要があります。これは、 'Max.Init.Retransmits'回まで繰り返す必要があります。その後、エンドポイントは初期化プロセスを中止し、SCTPユーザーにエラーを報告する必要があります。
3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and restart the T1-cookie timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user.
3）T1-cookieタイマーが期限切れになった場合、エンドポイントはCOOKIE ECHOを再送信し、状態を変更せずにT1-cookieタイマーを再起動する必要があります。 これは、「Max.Init.Retransmits」回まで繰り返す必要があります。 その後、エンドポイントは初期化プロセスを中止し、SCTPユーザーにエラーを報告する必要があります。
4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any received DATA chunks without delay.
4）SHUTDOWN-SENT状態では、エンドポイントは受信したDATAチャンクを遅延なく確認する必要があります。
5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send requests from its SCTP user.
5）SHUTDOWN-RECEIVED状態では、エンドポイントはSCTPユーザーからの新しい送信要求を受け入れてはなりません（MUST NOT）。
6) In the SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit data and leave this state when all data in queue is transmitted.
6）SHUTDOWN-RECEIVED状態では、エンドポイントはデータを送信または再送信し、キュー内のすべてのデータが送信されたときにこの状態のままにする必要があります。
7) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send requests from its SCTP user.
7）SHUTDOWN-ACK-SENT状態では、エンドポイントはSCTPユーザーからの新しい送信要求を受け入れてはなりません（MUST NOT）。
The CLOSED state is used to indicate that an association is not created (i.e., doesn't exist).
CLOSED状態は、関連付けが作成されていない（つまり、存在しない）ことを示すために使用されます。
Before the first data transmission can take place from one SCTP endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must complete an initialization process in order to set up an SCTP association between them.
最初のデータ転送が1つのSCTPエンドポイント（ "A"）から別のSCTPエンドポイント（ "Z"）に行われる前に、2つのエンドポイントは、それらの間のSCTPアソシエーションをセットアップするために初期化プロセスを完了する必要があります。
The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint.
エンドポイントのSCTPユーザーは、ASSOCIATEプリミティブを使用して、別のSCTPエンドポイントへのSCTPアソシエーションを初期化する必要があります。
IMPLEMENTATION NOTE: From an SCTP user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see Section 10.1 B) being invoked, by the initiating endpoint's sending of the first user data to the destination endpoint. The initiating SCTP will assume default values for all mandatory and optional parameters for the INIT/INIT ACK.
実装上の注意：SCTPユーザーの観点から見ると、開始エンドポイントが最初のユーザーデータを宛先エンドポイントに送信することにより、ASSOCIATEプリミティブ（セクション10.1 Bを参照）を呼び出さなくても、関連付けを暗黙的に開くことができます。開始SCTPは、INIT / INIT ACKのすべての必須およびオプションのパラメーターのデフォルト値を想定します。
Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1).
アソシエーションが確立されると、片方向のストリームが両端のデータ転送用に開かれます（セクション5.1.1を参照）。
The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association):
初期化プロセスは、次の手順で構成されます（SCTPエンドポイント「A」がSCTPエンドポイント「Z」との関連付けを設定しようとし、「Z」が新しい関連付けを受け入れると想定）。
A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see Section 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state.
A）「A」は最初にINITチャンクを「Z」に送信します。 INITでは、「A」は「タグの開始」フィールドに検証タグ（Tag_A）を指定する必要があります。 Tag_Aは、1〜4294967295の範囲の乱数である必要があります（タグ値の選択については、セクション5.3.1を参照してください）。 INITを送信した後、「A」はT1-initタイマーを開始し、COOKIE-WAIT状態に入ります。
B) "Z" shall respond immediately with an INIT ACK chunk. The destination IP address of the INIT ACK MUST be set to the source IP address of the INIT to which this INIT ACK is responding. In the response, besides filling in other parameters, "Z" must set the Verification Tag field to Tag_A, and also provide its own Verification Tag (Tag_Z) in the Initiate Tag field.
B）「Z」はINIT ACKチャンクで即座に応答します。 INIT ACKの宛先IPアドレスは、このINIT ACKが応答するINITのソースIPアドレスに設定する必要があります。応答では、他のパラメータを入力するほかに、「Z」は検証タグフィールドをTag_Aに設定し、独自の検証タグ（Tag_Z）を開始タグフィールドに提供する必要があります。
Moreover, "Z" MUST generate and send along with the INIT ACK a State Cookie. See Section 5.1.3 for State Cookie generation.
さらに、「Z」はINIT ACKとともに状態Cookieを生成して送信する必要があります。状態Cookieの生成については、セクション5.1.3を参照してください。
Note: After sending out INIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources or keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks.
注：StateCookieパラメーターを指定してINITACKを送信した後、「Z」はリソースを割り当てたり、新しい関連付けの状態を保持したりしてはなりません（MUSTNOT）。 そうしないと、「Z」はリソース攻撃に対して脆弱になります。
C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1- init timer and leave the COOKIE-WAIT state. "A" shall then send the State Cookie received in the INIT ACK chunk in a COOKIE ECHO chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED state.
C）「Z」からINIT ACKを受信すると、「A」はT1初期化タイマーを停止し、COOKIE-WAIT状態を終了します。次に、「A」は、INIT ACKチャンクで受信した状態CookieをCOOKIE ECHOチャンクで送信し、T1-cookieタイマーを開始して、COOKIE-ECHOED状態に入ります。
Note: The COOKIE ECHO chunk can be bundled with any pending outbound DATA chunks, but it MUST be the first chunk in the packet and until the COOKIE ACK is returned the sender MUST NOT send any other packets to the peer.
注：COOKIE ECHOチャンクは、保留中のアウトバウンドDATAチャンクとバンドルできますが、パケットの最初のチャンクである必要があり、COOKIE ACKが返されるまで、送信者は他のパケットをピアに送信してはなりません。
D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply with a COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED state. A COOKIE ACK chunk may be bundled with any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk MUST be the first chunk in the packet.
D）COOKIE ECHOチャンクを受信すると、TCBを構築してESTABLISHED状態に移行した後、エンドポイント "Z"はCOOKIE ACKチャンクで応答します。 COOKIE ACKチャンクは保留中のDATAチャンク（またはSACKチャンク、あるいはその両方）にバンドルできますが、COOKIE ACKチャンクはパケットの最初のチャンクでなければなりません（MUST）。
IMPLEMENTATION NOTE: An implementation may choose to send the Communication Up notification to the SCTP user upon reception of a valid COOKIE ECHO chunk.
実装上の注意：実装は、有効なCOOKIE ECHOチャンクを受信すると、通信アップ通知をSCTPユーザーに送信することを選択できます。
E) Upon reception of the COOKIE ACK, endpoint "A" will move from the COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1- cookie timer. It may also notify its ULP about the successful establishment of the association with a Communication Up notification (see Section 10).
E）COOKIE ACKを受信すると、エンドポイント「A」はCOOKIE-ECHOED状態からESTABLISHED状態に移行し、T1- cookieタイマーを停止します。また、Communication Up通知（セクション10を参照）との関連付けが正常に確立されたことをULPに通知する場合もあります。
An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. They MUST be the only chunks present in the SCTP packets that carry them.
INITまたはINIT ACKチャンクは、他のチャンクとバンドルしてはいけません。それらは、それらを運ぶSCTPパケットに存在する唯一のチャンクでなければなりません。
An endpoint MUST send the INIT ACK to the IP address from which it received the INIT.
エンドポイントは、INITを受信したIPアドレスにINIT ACKを送信する必要があります。
Note: T1-init timer and T1-cookie timer shall follow the same rules given in Section 6.3.
注：T1-initタイマーとT1-cookieタイマーは、セクション6.3で指定されたのと同じルールに従うものとします。
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer.
エンドポイントがINIT、INIT ACK、またはCOOKIE ECHOチャンクを受信したが、受信したINITまたはINIT ACKに必須パラメーターがない、無効なパラメーター値、またはローカルリソースがないために新しい関連付けを確立しないことを決定した場合、エンドポイントは応答する必要があります。 ABORTチャンク。 また、ABORTチャンクにエラー原因パラメーターを含めることにより、欠落している必須パラメーターのタイプなど、中止の原因を指定する必要があります。 ABORTチャンクを含むアウトバウンドSCTPパケットの共通ヘッダーのVerificationTagフィールドは、ピアのInitiateTag値に設定する必要があります。
Note that a COOKIE ECHO chunk that does NOT pass the integrity check is NOT considered an 'invalid parameter' and requires special handling; see Section 5.1.5.
整合性チェックに合格しないCOOKIE ECHOチャンクは「無効なパラメーター」とは見なされず、特別な処理が必要です。セクション5.1.5を参照してください。
After the reception of the first DATA chunk in an association the endpoint MUST immediately respond with a SACK to acknowledge the DATA chunk. Subsequent acknowledgements should be done as described in Section 6.2.
関連付けで最初のDATAチャンクを受信した後、エンドポイントはすぐにSACKで応答してDATAチャンクを確認する必要があります。後続の確認応答は、セクション6.2で説明されているように実行する必要があります。
When the TCB is created, each endpoint MUST set its internal Cumulative TSN Ack Point to the value of its transmitted Initial TSN minus one.
TCBが作成されるとき、各エンドポイントは、内部の累積TSN Ackポイントを、送信された初期TSNから1を引いた値に設定する必要があります。
IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally used as the key to find the TCB within an SCTP instance.
実装上の注意：IPアドレスとSCTPポートは、通常、SCTPインスタンス内でTCBを見つけるためのキーとして使用されます。
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OSs) it wishes to have in the association, as well as the maximum inbound streams (MISs) it will accept from the other endpoint.
INITチャンクとINITACKチャンクでは、チャンクの送信者は、アソシエーションに含めるアウトバウンドストリーム（OS）の数と、他のエンドポイントから受け入れる最大インバウンドストリーム（MIS）を指定する必要があります。
After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
反対側からストリーム構成情報を受信した後、各エンドポイントは次のチェックを実行する必要があります：ピアのMISがエンドポイントのOSより小さい場合、つまり、エンドポイントが構成するすべての送信ストリームをピアがサポートできない場合、エンドポイントMISアウトバウンドストリームを使用する必要があり、不足を上位層に報告する場合があります。上位層は、リソース不足が許容できない場合、関連付けを中止することを選択できます。
After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1.
アソシエーションが初期化された後、いずれかのエンドポイントの有効なアウトバウンドストリーム識別子の範囲は0〜min（ローカルOS、リモートMIS）-1でなければなりません。
During the association initialization, an endpoint shall use the following rules to discover and collect the destination transport address(es) of its peer.
アソシエーションの初期化中に、エンドポイントは次のルールを使用して、ピアの宛先トランスポートアドレスを検出および収集します。
A) If there are no address parameters present in the received INIT or INIT ACK chunk, the endpoint shall take the source IP address from which the chunk arrives and record it, in combination with the SCTP source port number, as the only destination transport address for this peer.
A）受信したINITまたはINIT ACKチャンクにアドレスパラメータがない場合、エンドポイントは、チャンクの到着元のソースIPアドレスを取得し、SCTPソースポート番号と組み合わせて、唯一の宛先トランスポートアドレスとして記録します。このピアのために。
B) If there is a Host Name parameter present in the received INIT or INIT ACK chunk, the endpoint shall resolve that host name to a list of IP address(es) and derive the transport address(es) of this peer by combining the resolved IP address(es) with the SCTP source port.
B）受信したINITまたはINIT ACKチャンクにホスト名パラメーターが存在する場合、エンドポイントはそのホスト名をIPアドレスのリストに解決し、解決されたものを組み合わせることにより、このピアのトランスポートアドレスを導出する必要があります。 SCTP送信元ポートのIPアドレス。
The endpoint MUST ignore any other IP Address parameters if they are also present in the received INIT or INIT ACK chunk.
エンドポイントは、受信したINITまたはINIT ACKチャンクにも存在する場合、他のIPアドレスパラメータを無視する必要があります。
The time at which the receiver of an INIT resolves the host name has potential security implications to SCTP. If the receiver of an INIT resolves the host name upon the reception of the chunk, and the mechanism the receiver uses to resolve the host name involves potential long delay (e.g., DNS query), the receiver may open itself up to resource attacks for the period of time while it is waiting for the name resolution results before it can build the State Cookie and release local resources.
INITの受信者がホスト名を解決する時間は、SCTPに潜在的なセキュリティ上の影響があります。 INITのレシーバーがチャンクの受信時にホスト名を解決し、ホスト名を解決するためにレシーバーが使用するメカニズムに潜在的な長い遅延（DNSクエリなど）が含まれる場合、レシーバーは、状態Cookieを構築してローカルリソースを解放する前に、名前解決の結果を待機している期間。
Therefore, in cases where the name translation involves potential long delay, the receiver of the INIT MUST postpone the name resolution till the reception of the COOKIE ECHO chunk from the peer. In such a case, the receiver of the INIT SHOULD build the State Cookie using the received Host Name (instead of destination transport addresses) and send the INIT ACK to the source IP address from which the INIT was received.
したがって、名前の変換に潜在的な長い遅延が含まれる場合、INITの受信者は、ピアからのCOOKIE ECHOチャンクの受信まで名前解決を延期する必要があります。このような場合、INITの受信者は、（宛先トランスポートアドレスではなく）受信したホスト名を使用して状態Cookieを作成し、INITの送信元IPアドレスにINIT ACKを送信する必要があります（SHOULD）。
The receiver of an INIT ACK shall always immediately attempt to resolve the name upon the reception of the chunk.
INIT ACKの受信者は、チャンクを受信するとすぐに名前を解決しようとします。
The receiver of the INIT or INIT ACK MUST NOT send user data (piggy-backed or stand-alone) to its peer until the host name is successfully resolved.
INITまたはINIT ACKの受信者は、ホスト名が正常に解決されるまで、ユーザーデータ（ピギーバックまたはスタンドアロン）をピアに送信してはなりません（MUST NOT）。
If the name resolution is not successful, the endpoint MUST immediately send an ABORT with "Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from which the last peer packet was received.
名前解決が成功しない場合、エンドポイントは「原因不明のアドレス」エラーの原因を伴うABORTをすぐにピアに送信する必要があります。 ABORTは、最後のピアパケットが受信された送信元IPアドレスに送信されます。
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver MUST derive and record all the transport addresses from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport addresses are derived by the combination of SCTP source port (from the common header) and the IP Address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C）受信したINITまたはINIT ACKチャンクにIPv4 / IPv6アドレスのみが存在する場合、受信者は、受信したチャンクからすべてのトランスポートアドレスと、INITまたはINIT ACKを送信したソースIPアドレスを導出して記録する必要があります。トランスポートアドレスは、（共通ヘッダーからの）SCTP送信元ポートと、INITまたはINIT ACKチャンクで伝送されるIPアドレスパラメータおよびIPデータグラムの送信元IPアドレスの組み合わせによって導出されます。受信者は、後続のパケットをピアに送信するときに、これらのトランスポートアドレスのみを宛先トランスポートアドレスとして使用する必要があります。
D) An INIT or INIT ACK chunk MUST be treated as belonging to an already established association (or one in the process of being established) if the use of any of the valid address parameters contained within the chunk would identify an existing TCB.
D）チャンク内に含まれる有効なアドレスパラメータのいずれかを使用して既存のTCBを識別する場合、INITまたはINIT ACKチャンクは、すでに確立されている関連付け（または確立中の関連付け）に属するものとして扱われなければなりません（MUST）。
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation doesn't control the source IP address that is used for transmitting), an endpoint might need to include in its INIT or INIT ACK all possible IP addresses from which packets to the peer could be transmitted.
実装上の注意：場合によっては（たとえば、実装が送信に使用されるソースIPアドレスを制御しない場合）、エンドポイントは、ピアへのパケットが送信される可能性のあるすべての可能なIPアドレスをINITまたはINIT ACKに含める必要がある場合があります。送信されます。
After all transport addresses are derived from the INIT or INIT ACK chunk using the above rules, the endpoint shall select one of the transport addresses as the initial primary path.
上記のルールを使用してすべてのトランスポートアドレスがINITまたはINIT ACKチャンクから導出された後、エンドポイントはトランスポートアドレスの1つを初期プライマリパスとして選択する必要があります。
Note: The INIT ACK MUST be sent to the source address of the INIT.
注：INIT ACKは、INITの送信元アドレスに送信する必要があります。
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiate) MUST either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer.
INITの送信者は、どのタイプのアドレスが受け入れられるかを示すために、INITに「サポートされているアドレスタイプ」パラメータを含めることができます。このパラメーターが存在する場合、INIT（開始）の受信者は、INITに応答するときに、サポートされているアドレスタイプパラメーターに示されているアドレスタイプの1つを使用するか、または、それが望まない場合、「解決できないアドレス」エラーの原因でアソシエーションを中止する必要があります。または、そのピアが示すアドレスタイプを使用できません。
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a reinitiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：サポートされていないタイプが原因でINIT ACKの受信者がアドレスパラメータを解決できない場合、初期化プロセスを中止し、新しいINITの「サポートされているアドレスタイプ」パラメータを使用して再初期化を試みることができます。優先するアドレスのタイプを示します。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
実装上の注意：IPv4またはIPv6のいずれかのみをサポートするSCTPエンドポイントがピアからINITまたはINIT ACKチャンクでIPv4およびIPv6アドレスを受信する場合、サポートされているアドレスファミリに属するすべてのアドレスを使用する必要があります。他のアドレスは無視されるかもしれません。エンドポイントは、いかなる種類のエラー表示でも応答してはなりません（SHOULD NOT）。
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.
実装上の注意：SCTPエンドポイントがIPv4またはIPv6の「サポートされているアドレスタイプ」パラメーターにリストされているが、INITチャンクを含むパケットの送信に他のファミリーを使用している場合、またはINITチャンクに他のファミリーのアドレスもリストされている場合、次に、「サポートされているアドレスタイプ」パラメータにリストされていないアドレスファミリも、INITチャンクの受信者によってサポートされていると見なされるべきです（SHOULD）。 INITチャンクの受信者は、いかなる種類のエラー表示でも応答してはなりません（SHOULD NOT）。
When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a timestamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association.
INITチャンクへの応答としてINIT ACKを送信する場合、INIT ACKの送信者は状態Cookieを作成し、それをINIT ACKの状態Cookieパラメータで送信します。この状態Cookie内に、送信者はMAC（例として[RFC2104]を参照）、状態Cookieが作成されたときのタイムスタンプ、および状態Cookieの存続期間と、それを確立するために必要なすべての情報を含める必要があります協会。
The following steps SHOULD be taken to generate the State Cookie:
状態Cookieを生成するには、次の手順を実行する必要があります。
1) Create an association TCB using information from both the received INIT and the outgoing INIT ACK chunk,
1）受信したINITと発信INIT ACKチャンクの両方からの情報を使用して、関連付けTCBを作成します。
2) In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life' (see Section 15),
2）TCBで、作成時刻を現在の時刻に設定し、ライフスパンをプロトコルパラメータ 'Valid.Cookie.Life'に設定します（セクション15を参照）。
3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC), and
3）TCBから、TCBを再作成するために必要な最小限の情報のサブセットを識別および収集し、この情報のサブセットと秘密鍵を使用してMACを生成します（MACの生成例については[RFC2104]を参照）。
4) Generate the State Cookie by combining this subset of information and the resultant MAC.
4）この情報のサブセットと結果のMACを組み合わせて、状態Cookieを生成します。
After sending the INIT ACK with the State Cookie parameter, the sender SHOULD delete the TCB and any other local resource related to the new association, so as to prevent resource attacks.
State Cookieパラメーターを使用してINIT ACKを送信した後、送信者は、リソースの攻撃を防ぐために、TCBと新しい関連付けに関連するその他のローカルリソースを削除する必要があります（SHOULD）。
The hashing method used to generate the MAC is strictly a private matter for the receiver of the INIT chunk. The use of a MAC is mandatory to prevent denial-of-service attacks. The secret key SHOULD be random ([RFC4086] provides some information on randomness guidelines); it SHOULD be changed reasonably frequently, and the timestamp in the State Cookie MAY be used to determine which key should be used to verify the MAC.
MACを生成するために使用されるハッシュ方式は、厳密にはINITチャンクの受信者の個人的な問題です。サービス拒否攻撃を防ぐには、MACの使用が必須です。秘密鍵はランダムである必要があります（[RFC4086]はランダム性ガイドラインに関する情報を提供します）。合理的に頻繁に変更する必要があり、MACを検証するために使用するキーを決定するために、ステートCookieのタイムスタンプを使用できます。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
実装は相互運用性を保証するためにCookieを可能な限り小さくする必要があります（SHOULD）。
When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK chunk with a State Cookie parameter, it MUST immediately send a COOKIE ECHO chunk to its peer with the received State Cookie. The sender MAY also add any pending DATA chunks to the packet after the COOKIE ECHO chunk.
エンドポイント（COOKIE-WAIT状態）が状態Cookieパラメーターを含むINIT ACKチャンクを受信すると、受信した状態Cookieを持つピアにCOOKIE ECHOチャンクをすぐに送信する必要があります。送信者は、COOKIE ECHOチャンクの後に、保留中のDATAチャンクをパケットに追加してもよい（MAY）。
The endpoint shall also start the T1-cookie timer after sending out the COOKIE ECHO chunk. If the timer expires, the endpoint shall retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated until either a COOKIE ACK is received or 'Max.Init.Retransmits' (see Section 15) is reached causing the peer endpoint to be marked unreachable (and thus the association enters the CLOSED state).
エンドポイントは、COOKIE ECHOチャンクを送信した後、T1-cookieタイマーも開始します。タイマーの期限が切れた場合、エンドポイントはCOOKIE ECHOチャンクを再送信し、T1-cookieタイマーを再起動します。これは、COOKIE ACKが受信されるか、「Max.Init.Retransmits」（セクション15を参照）に到達するまで繰り返され、ピアエンドポイントが到達不能としてマークされます（したがって、関連付けはCLOSED状態になります）。
When an endpoint receives a COOKIE ECHO chunk from another endpoint with which it has no association, it shall take the following actions:
エンドポイントは、関連付けのない別のエンドポイントからCOOKIE ECHOチャンクを受信すると、次のアクションを実行します。
1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). [RFC2104] can be used as a guideline for generating the MAC,
1）州のCookieと秘密鍵で運ばれるTCBデータを使用してMACを計算します（州のCookieのタイムスタンプを使用して、使用する秘密鍵を決定できます）。 [RFC2104]は、MACを生成するためのガイドラインとして使用できます。
2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded,
2）計算されたMACを状態Cookieで運ばれたものと比較することにより、以前に生成したものとして状態Cookieを認証します。この比較が失敗した場合、COOKIE ECHOとDATAチャンクを含むSCTPパケットは、通知なく破棄されます。
3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded.
3）COOKIE ECHOチャンクに含まれるポート番号と検証タグを、受信したパケットのSCTP共通ヘッダー内の実際のポート番号と検証タグと比較します。 これらの値が一致しない場合、パケットはサイレントに破棄されなければなりません（MUST）。
4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.
4）状態Cookieの作成タイムスタンプを現在の現地時間と比較します。経過時間がState Cookieで運ばれる寿命よりも長い場合、COOKIE ECHOおよび添付されたDATAチャンクを含むパケットは破棄されるべきであり、エンドポイントは、「古くなったCookie」エラーの原因を含むERRORチャンクを送信する必要があります。ピアエンドポイント。
5) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO and enter the ESTABLISHED state.
5）状態Cookieが有効な場合、COOKIE ECHOで伝送されるTCBデータの情報を使用してCOOKIE ECHOチャンクの送信者への関連付けを作成し、ESTABLISHED状態に入ります。
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
6）COOKIEエコーの受信を確認するピアにCOOKIE ACKチャンクを送信します。 COOKIE ACKは、送信DATAチャンクまたはSACKチャンクにバンドルされる場合があります。ただし、COOKIE ACKはSCTPパケットの最初のチャンクである必要があります。
7) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step 6, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
7）COOKIE ECHOにバンドルされているDATAチャンクをSACKですぐに確認します（後続のDATAチャンクの確認は、セクション6.2で定義されたルールに従う必要があります）。ステップ6で述べたように、SACKがCOOKIE ACKにバンドルされている場合、COOKIE ACKはSCTPパケットの最初に現れる必要があります。
If a COOKIE ECHO is received from an endpoint with which the receiver of the COOKIE ECHO has an existing association, the procedures in Section 5.2 should be followed.
COOKIE ECHOの受信者が既存の関連付けを持つエンドポイントからCOOKIE ECHOを受信した場合は、セクション5.2の手順に従う必要があります。
In the following example, "A" initiates the association and then sends a user message to "Z", then "Z" sends two user messages to "A" later (assuming no bundling or fragmentation occurs):
次の例では、「A」が関連付けを開始してから「Z」にユーザーメッセージを送信し、その後「Z」が2つのユーザーメッセージを「A」に送信します（バンドリングまたはフラグメンテーションが発生しないと想定）。
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITIATION Example
図4：INITIATIONの例
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and the timer restarted. This shall be repeated Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure to its upper layer (and thus the association enters the CLOSED state).
INITまたはCOOKIE ECHOチャンクが送信された後、T1-initタイマーが「A」で期限切れになると、同じINITまたはCOOKIE ECHOチャンクと同じ開始タグ（つまり、Tag_A）または状態Cookieが再送信され、タイマーが再開されます。これは、 "A"が "Z"に到達できないと見なし、その上位層に障害を報告する（したがって、関連付けがCLOSED状態になる）前に、Max.Init.Retransmits回繰り返されます。
When retransmitting the INIT, the endpoint MUST follow the rules defined in Section 6.3 to determine the proper timer value.
INITを再送信するとき、エンドポイントは適切なタイマー値を決定するためにセクション6.3で定義されたルールに従う必要があります。
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK
5.2. 重複または予期しないINIT、INIT ACK、COOKIE ECHO、およびCOOKIE ACKの処理
During the life time of an association (in one of the possible states), an endpoint may receive from its peer endpoint one of the setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it as described in this section.
アソシエーションの存続期間中（可能な状態の1つ）、エンドポイントは、ピアエンドポイントからセットアップチャンク（INIT、INIT ACK、COOKIE ECHO、およびCOOKIE ACK）の1つを受信する場合があります。受信者は、このようなセットアップチャンクを複製として扱い、このセクションで説明するように処理します。
Note: An endpoint will not receive the chunk unless the chunk was sent to an SCTP transport address and is from an SCTP transport address associated with this endpoint. Therefore, the endpoint processes such a chunk as part of its current association.
注：チャンクがSCTPトランスポートアドレスに送信され、このエンドポイントに関連付けられたSCTPトランスポートアドレスから送信されない限り、エンドポイントはチャンクを受信しません。したがって、エンドポイントはそのようなチャンクを現在の関連付けの一部として処理します。
The following scenarios can cause duplicated or unexpected chunks:
次のシナリオでは、チャンクの重複または予期しないチャンクが発生する可能性があります。
A) The peer has crashed without being detected, restarted itself, and sent out a new INIT chunk trying to restore the association,
A）ピアは検出されずにクラッシュし、再起動し、関連付けを復元しようとする新しいINITチャンクを送信しました、
B) Both sides are trying to initialize the association at about the same time,
B）両側がほぼ同時に関連付けを初期化しようとしている、
C) The chunk is from a stale packet that was used to establish the present association or a past association that is no longer in existence,
C）チャンクは、現在の関連付けまたは存在しなくなった過去の関連付けを確立するために使用された古いパケットからのものです。
D) The chunk is a false packet generated by an attacker, or
D）チャンクは、攻撃者によって生成された偽のパケット、または
E) The peer never received the COOKIE ACK and is retransmitting its COOKIE ECHO.
E）ピアがCOOKIE ACKを受信したことがなく、COOKIE ECHOを再送信しています。
The rules in the following sections shall be applied in order to identify and correctly handle these cases.
これらのケースを識別して正しく処理するために、次のセクションのルールが適用されます。
This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint.
これは通常、初期化の衝突を示します。つまり、各エンドポイントがほぼ同時に、他のエンドポイントとの関連付けを確立しようとしています。
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the endpoint MUST send the INIT ACK back to the same address that the original INIT (sent by this endpoint) was sent.
COOKIE-WAIT状態でINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていない開始タグを含む）を使用して、INIT ACKで応答する必要があります。応答時に、エンドポイントはINIT ACKを、このエンドポイントによって送信された元のINITが送信されたのと同じアドレスに送信する必要があります。
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
COOKIE-ECHOED状態でINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていない開始タグを含む）を使用してINIT ACKで応答する必要があります（ただし、新しいアドレスが協会を結成。新しいアドレスが関連付けに追加されたことをINITメッセージが示している場合は、INIT全体を破棄する必要があり、既存の関連付けは変更しないでください。 ABORT SHOULDは、「新しいアドレスとのアソシエーションの再開」というエラーを含む可能性があるという応答として送信する必要があります。エラーは、再起動アソシエーションに追加されたアドレスをリストする必要があります（SHOULD）。
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK, the original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
いずれかの状態（COOKIE-WAITまたはCOOKIE-ECHOED）でINIT ACKを使用して応答すると、元のパラメーターは、新しく受信したINITチャンクからのパラメーターと結合されます。エンドポイントは、INIT ACKを使用して状態Cookieも生成します。エンドポイントは、INITで送信されたパラメーターを使用して状態Cookieを計算します。
After that, the endpoint MUST NOT change its state, the T1-init timer shall be left running, and the corresponding TCB MUST NOT be destroyed. The normal procedures for handling State Cookies when a TCB exists will resolve the duplicate INITs to a single association.
その後、エンドポイントはその状態を変更してはならず（MUST NOT）、T1-initタイマーは実行されたままであり、対応するTCBは破棄されてはなりません（MUST NOT）。 TCBが存在する場合に状態Cookieを処理する通常の手順では、重複するINITを単一の関連付けに解決します。
For an endpoint that is in the COOKIE-ECHOED state, it MUST populate its Tie-Tags within both the association TCB and inside the State Cookie (see Section 5.2.2 for a description of the Tie-Tags).
COOKIE-ECHOED状態にあるエンドポイントの場合、アソシエーションTCB内と状態Cookie内の両方にTieタグを設定する必要があります（Tieタグの説明については、セクション5.2.2を参照してください）。
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.2. CLOSED、COOKIE-ECHOED、COOKIE-WAIT、およびSHUTDOWN-ACK-SENT以外の状態での予期しないINIT
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding, the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond with an ABORT, copying the 'Initiate Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In the ABORT response, the cause of error MAY be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a reserved place within the State Cookie and the association's TCB. We shall refer to these locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy within an association's TCB as the Local Tag and Peer's Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiate Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiate Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
特に明記されていない限り、この関連付けの予期しないINITを受信すると、エンドポイントは状態Cookieを使用してINIT ACKを生成します。応答する前に、エンドポイントは、予期しないINITが新しいアドレスを関連付けに追加するかどうかを確認する必要があります。アソシエーションに新しいアドレスが追加された場合、エンドポイントはABORTで応答する必要があり、予期しないINITの「開始タグ」を、ABORTを運ぶ送信パケットの「検証タグ」にコピーする必要があります。 ABORT応答では、エラーの原因は「新しいアドレスとの関連付けの再開」に設定される場合があります。エラーは、再起動アソシエーションに追加されたアドレスをリストする必要があります（SHOULD）。新しいアドレスが追加されない場合、アウトバウンドINIT ACKのINITに応答するとき、エンドポイントは現在のタイタグを状態Cookieと関連付けのTCB内の予約された場所にコピーする必要があります。 Cookie内のこれらの場所を、Peer's-Tie-TagおよびLocal-Tie-Tagと呼びます。協会のTCB内のコピーをローカルタグおよびピアのタグと呼びます。このINIT ACKを含むアウトバウンドSCTPパケットは、予期しないINITで見つかった開始タグに等しい検証タグ値を運ぶ必要があります。また、INIT ACKには新しい開始タグ（ランダムに生成されます。セクション5.3.1を参照）を含める必要があります。エンドポイントの他のパラメーターは、関連付けの既存のパラメーター（アウトバウンドストリームの数など）からINIT ACKおよびCookieにコピーする必要があります（SHOULD）。
After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
INIT ACKまたはABORTを送信した後、エンドポイントはそれ以上のアクションを実行してはなりません。つまり、現在の状態を含む既存の関連付け、および対応するTCBを変更してはなりません（MUST NOT）。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e., the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed).
注：TCBが存在し、関連付けがCOOKIE-WAITまたはSHUTDOWN-ACK-SENT状態でない場合にのみ、タイタグに0以外の値が入力されます。通常の関連付けINITの場合（つまり、エンドポイントはCLOSED状態）、Tie-Tagは0に設定する必要があります（以前のTCBが存在しなかったことを示します）。
If an INIT ACK is received by an endpoint in any state other than the COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk. An unexpected INIT ACK usually indicates the processing of an old or duplicated INIT chunk.
COOKIE-WAIT状態以外の状態のエンドポイントがINIT ACKを受信した場合、エンドポイントはINIT ACKチャンクを破棄する必要があります。通常、予期しないINIT ACKは、古いまたは重複したINITチャンクの処理を示します。
When a COOKIE ECHO chunk is received by an endpoint in any state for an existing association (i.e., not in the CLOSED state) the following rules shall be applied:
COOKIE ECHOチャンクが既存のアソシエーションの任意の状態（つまり、CLOSED状態ではない）でエンドポイントによって受信された場合、次のルールが適用されます。
1) Compute a MAC as described in step 1 of Section 5.1.5,
1）セクション5.1.5のステップ1の説明に従ってMACを計算します。
2) Authenticate the State Cookie as described in step 2 of Section 5.1.5 (this is case C or D above).
2）セクション5.1.5のステップ2で説明されているように状態Cookieを認証します（これは上記のケースCまたはDです）。
3) Compare the timestamp in the State Cookie to the current time. If the State Cookie is older than the lifespan carried in the State Cookie and the Verification Tags contained in the State Cookie do not match the current association's Verification Tags, the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint (this is case C or D in Section 5.2).
3）状態Cookieのタイムスタンプを現在の時刻と比較します。状態Cookieが状態Cookieに含まれる寿命よりも古く、状態Cookieに含まれている検証タグが現在の関連付けの検証タグと一致しない場合、COOKIE ECHOとすべてのDATAチャンクを含むパケットを破棄する必要があります。エンドポイントはまた、「古いCookie」エラーの原因を含むERRORチャンクをピアエンドポイントに送信する必要があります（これはセクション5.2のケースCまたはDです）。
If both Verification Tags in the State Cookie match the Verification Tags of the current association, consider the State Cookie valid (this is case E in Section 5.2) even if the lifespan is exceeded.
状態Cookieの両方の検証タグが現在の関連付けの検証タグと一致する場合、寿命を超えていても、状態Cookieが有効である（セクション5.2のケースE）と見なします。
4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB.
4）州のCookieが有効であることが判明した場合は、TCBを一時的なTCBに解凍します。
5) Refer to Table 2 to determine the correct action to be taken.
5）実行する正しいアクションを判別するには、表2を参照してください。
+------------+------------+---------------+--------------+-------------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ |
| | | | | Description |
+------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+
| M | X | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| M | 0 | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+
| M | M | A | A | (D) |
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB Exists |
+======================================================================+
Legend:
伝説：
X - Tag does not match the existing TCB. M - Tag matches the existing TCB. 0 - No Tie-Tag in cookie (unknown). A - All cases, i.e., M, X, or 0.
X-タグが既存のTCBと一致しません。 M-タグは既存のTCBと一致します。 0-Cookieにタイタグがありません（不明）。 A-すべてのケース、つまりM、X、または0。
Note: For any case not shown in Table 2, the cookie should be silently discarded.
注：表2に示されていないケースでは、Cookieは暗黙的に破棄されます。
Action
アクション
A) In this case, the peer may have restarted. When the endpoint recognizes this potential 'restart', the existing session is treated the same as if it received an ABORT followed by a new COOKIE ECHO with the following exceptions:
A）この場合、ピアは再起動している可能性があります。エンドポイントがこの「再起動」の可能性を認識すると、既存のセッションは、次の例外を除いて、ABORTの後に新しいCOOKIE ECHOが続く場合と同じように扱われます。
- Any SCTP DATA chunks MAY be retained (this is an implementation-specific option).
- SCTP DATAチャンクは保持される場合があります（これは実装固有のオプションです）。
- A notification of RESTART SHOULD be sent to the ULP instead of a "COMMUNICATION LOST" notification.
- 「通信の喪失」通知の代わりに、再起動の通知をULPに送信する必要があります。
All the congestion control parameters (e.g., cwnd, ssthresh) related to this peer MUST be reset to their initial values (see Section 6.2.1).
このピアに関連するすべての輻輳制御パラメータ（cwnd、ssthreshなど）は、初期値にリセットする必要があります（セクション6.2.1を参照）。
After this, the endpoint shall enter the ESTABLISHED state.
After this, the endpoint shall enter the ESTABLISHED state.
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes that the peer has restarted (Action A), it MUST NOT set up a new association but instead resend the SHUTDOWN ACK and send an ERROR chunk with a "Cookie Received While Shutting Down" error cause to its peer.
エンドポイントがSHUTDOWN-ACK-SENT状態にあり、ピアが再起動したことを認識する場合（アクションA）、新しいアソシエーションをセットアップせず、代わりにSHUTDOWN ACKを再送信して、「シャットダウン中に受信したCookieを含むERRORチャンクを送信する必要があります。ピアへの「ダウン」エラーの原因。
B) In this case, both sides may be attempting to start an association at about the same time, but the peer endpoint started its INIT after responding to the local endpoint's INIT. Thus, it may have picked a new Verification Tag, not being aware of the previous tag it had sent this endpoint. The endpoint should stay in or enter the ESTABLISHED state, but it MUST update its peer's Verification Tag from the State Cookie, stop any init or cookie timers that may be running, and send a COOKIE ACK.
B）この場合、両側がほぼ同時にアソシエーションを開始しようとしている可能性がありますが、ピアエンドポイントはローカルエンドポイントのINITに応答した後にINITを開始しました。したがって、このエンドポイントに送信した以前のタグを認識せずに、新しい検証タグを選択した可能性があります。エンドポイントはESTABLISHED状態を維持または開始する必要がありますが、ピアの検証タグを状態Cookieから更新し、実行中の可能性のあるinitまたはcookieタイマーを停止し、COOKIE ACKを送信する必要があります。
C) In this case, the local endpoint's cookie has arrived late. Before it arrived, the local endpoint sent an INIT and received an INIT ACK and finally sent a COOKIE ECHO with the peer's same tag but a new tag of its own. The cookie should be silently discarded. The endpoint SHOULD NOT change states and should leave any timers running.
C）この場合、ローカルエンドポイントのCookieが遅れて到着しています。到着する前に、ローカルエンドポイントはINITを送信してINIT ACKを受信し、最後にピアの同じタグを使用して独自の新しいタグを付けたCOOKIE ECHOを送信しました。クッキーは黙って破棄されるべきです。エンドポイントは状態を変更してはならず（SHOULD NOT）、タイマーを実行したままにしておく必要があります。
D) When both local and remote tags match, the endpoint should enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It should stop any cookie timer that may be running and send a COOKIE ACK.
D）ローカルタグとリモートタグの両方が一致する場合、エンドポイントがCOOKIE-ECHOED状態であれば、エンドポイントはESTABLISHED状態に入る必要があります。実行中の可能性があるCookieタイマーを停止し、COOKIE ACKを送信する必要があります。
Note: The "peer's Verification Tag" is the tag received in the Initiate Tag field of the INIT or INIT ACK chunk.
注：「ピアの検証タグ」は、INITまたはINIT ACKチャンクの開始タグフィールドで受信されたタグです。
In the following example, "A" initiates the association after a
restart has occurred. Endpoint "Z" had no knowledge of the restart
until the exchange (i.e., Heartbeats had not yet detected the failure
of "A") (assuming no bundling or fragmentation occurs): Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find an existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match, i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
図5：再起動の例
5.2.5. Handle Duplicate COOKIE-ACK.
5.2.5. 重複するCOOKIE-ACKを処理します。
At any state other than COOKIE-ECHOED, an endpoint should silently discard a received COOKIE ACK chunk.
COOKIE-ECHOED以外の状態では、エンドポイントは受信したCOOKIE ACKチャンクを通知なく破棄する必要があります。
Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates one of a number of possible events:
「古くなったCookie」エラーの原因を含むERRORチャンクを受け取った場合、考えられるいくつかのイベントの1つを示します。
A) The association failed to completely setup before the State Cookie issued by the sender was processed.
A）送信者が発行した状態Cookieが処理される前に、関連付けを完全にセットアップできませんでした。
B) An old State Cookie was processed after setup completed.
B）セットアップの完了後に、古い状態のCookieが処理されました。
C) An old State Cookie is received from someone that the receiver is not interested in having an association with and the ABORT chunk was lost.
C）受信者がアソシエーションを持つことに興味がなく、ABORTチャンクが失われた誰かから古いState Cookieが受信された。
When processing an ERROR chunk with a "Stale Cookie" error cause an endpoint should first examine if an association is in the process of being set up, i.e., the association is in the COOKIE-ECHOED state. In all cases, if the association is not in the COOKIE-ECHOED state, the ERROR chunk should be silently discarded.
「古くなったCookie」エラーを含むERRORチャンクを処理する場合、エンドポイントは、関連付けが設定中かどうか、つまり関連付けがCOOKIE-ECHOED状態かどうかを最初に調べる必要があります。いずれの場合も、関連付けがCOOKIE-ECHOED状態でない場合、ERRORチャンクは通知なく破棄されます。
If the association is in the COOKIE-ECHOED state, the endpoint may elect one of the following three alternatives.
アソシエーションがCOOKIE-ECHOED状態にある場合、エンドポイントは次の3つの選択肢のいずれかを選択できます。
1) Send a new INIT chunk to the endpoint to generate a new State Cookie and reattempt the setup procedure.
1）新しいINITチャンクをエンドポイントに送信して、新しい状態Cookieを生成し、セットアップ手順を再試行します。
2) Discard the TCB and report to the upper layer the inability to set up the association.
2）TCBを破棄し、関連付けをセットアップできないことを上位層に報告します。
3) Send a new INIT chunk to the endpoint, adding a Cookie Preservative parameter requesting an extension to the life time of the State Cookie. When calculating the time extension, an implementation SHOULD use the RTT information measured based on the previous COOKIE ECHO / ERROR exchange, and should add no more than 1 second beyond the measured RTT, due to long State Cookie life times making the endpoint more subject to a replay attack.
3）ステートCookieの存続期間の延長を要求するCookie Preservativeパラメーターを追加して、新しいINITチャンクをエンドポイントに送信します。時間延長を計算するとき、実装は、以前のCOOKIE ECHO / ERROR交換に基づいて測定されたRTT情報を使用する必要があり、測定されたRTTを1秒以内に追加する必要があります。リプレイ攻撃。
Initiate Tag values should be selected from the range of 1 to 2**32 - 1. It is very important that the Initiate Tag value be randomized to help protect against "man in the middle" and "sequence number" attacks. The methods described in [RFC4086] can be used for the Initiate Tag randomization. Careful selection of Initiate Tags is also necessary to prevent old duplicate packets from previous associations being mistakenly processed as belonging to the current association.
開始タグの値は、1から2 ** 32-1の範囲から選択する必要があります。「中間者」および「シーケンス番号」攻撃から保護するために、開始タグの値をランダム化することが非常に重要です。 [RFC4086]で説明されている方法は、タグのランダム化の開始に使用できます。以前のアソシエーションからの古い重複パケットが現在のアソシエーションに属するものとして誤って処理されるのを防ぐために、開始タグを慎重に選択することも必要です。
Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the life time of an association. A new Verification Tag value MUST be used each time the endpoint tears down and then reestablishes an association to the same peer.
さらに、特定のアソシエーションのいずれかのエンドポイントで使用される検証タグの値は、アソシエーションの存続期間中に変更してはなりません。エンドポイントが破棄され、同じピアへの関連付けを再確立するたびに、新しい検証タグ値を使用する必要があります。
During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association:
アソシエーションの確立中に、2つのピアはアドレスのリストを交換します。主なケースでは、これらのリストは各ピアが所有するアドレスを正確に表します。ただし、正常に動作しないピアが、所有していないアドレスを提供する可能性があります。これを防ぐために、次のルールが新しい関連付けのすべてのアドレスに適用されます。
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1）上位層によってINITの送信側に渡されたアドレスは、自動的にCONFIRMEDと見なされます。
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent.
2）COOKIE ECHOの受信側の場合、CONFIRMEDアドレスは、INIT-ACKが送信されたアドレスのみです。
3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification.
3）ルール1および2でカバーされていない他のすべてのアドレスは未確認と見なされ、検証のための調査の対象となります。
To probe an address for verification, an endpoint will send HEARTBEATs including a 64-bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter.
検証のためにアドレスをプローブするために、エンドポイントは、HEARTBEATパラメーター内で64ビットのランダムnonceおよびパスインジケーター（HEARTBEATの送信先アドレスを識別するため）を含むHEARTBEATを送信します。
Upon receipt of the HEARTBEAT ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
HEARTBEAT ACKを受信すると、HEARTBEATパラメータに含まれているnonceが、HEARTBEATパラメータ内に示されたアドレスに送信されたものであることが確認されます。この一致が発生すると、元のHEARTBEATが送信されたアドレスはCONFIRMEDと見なされ、通常のデータ転送に使用できるようになります。
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed.
これらのプロービング手順は、関連付けがESTABLISHED状態に移行したときに開始され、すべてのパスが確認されたときに終了します。
In each RTO, a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in Section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented.
各RTOでは、プローブをCONFIRMED状態に移動しようとして、アクティブなUNCONFIRMEDパスでプローブが送信される場合があります。このプローブ中にパスが非アクティブになると、このレートは通常のハートビートレートまで低下します。 RTOタイマーの満了時に、セクション8.2で定義されているように、プローブされたがCONFIRMEDでなかったすべてのパスのエラーカウンターが1つインクリメントされ、パス障害検出が行われます。ただし、UNCONFIRMEDアドレスをプローブする場合、アソシエーション全体のエラーカウントは増分されません。
The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peer's addresses for path verification.
各RTOで送信されるハートビートの数は、HB.Max.Burstパラメーターによって制限されるべきです（SHOULD）。パス検証のためにハートビートをピアのアドレスに配布する方法に関する実装の決定です。
Whenever a path is confirmed, an indication MAY be given to the upper layer.
パスが確認されるときはいつでも、上位層に通知が与えられてもよい（MAY）。
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions:
エンドポイントは、以下の例外を除き、チャンクをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address.
- nonceを含むHEARTBEATは、UNCONFIRMEDアドレスに送信される場合があります。
- A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address.
- A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address.
- A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE ACK to an UNCONFIRMED address.
- COOKIE ACKは、確認されていないアドレスに送信される場合がありますが、ノンスを含むハートビートにバンドルされている必要があります。バンドリングをサポートしない実装は、COOKIE ACKをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
- A COOKIE ECHO MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or if the bundled COOKIE ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implementation MUST NOT send a COOKIE ECHO to an UNCONFIRMED address.
- COOKIE ECHOは、確認されていないアドレスに送信される場合がありますが、ナンスを含むハートビートにバンドルされている必要があり、パケットはパスMTUを超えてはなりません。実装がバンドルをサポートしていない場合、またはバンドルされたCOOKIE ECHOとHEARTBEAT（nonceを含む）がパスMTUを超える場合、実装はCOOKIE ECHOをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunks are allowed to be bundled with an outbound COOKIE ECHO chunk when in the COOKIE-WAIT state.
データ送信は、ESTABLISHED、SHUTDOWN-PENDING、およびSHUTDOWN-RECEIVED状態でのみ発生する必要があります。これの唯一の例外は、COOKIE-WAIT状態にあるときに、DATAチャンクをアウトバウンドCOOKIE ECHOチャンクにバンドルできることです。
DATA chunks MUST only be received according to the rules below in ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT. A DATA chunk received in CLOSED is out of the blue and SHOULD be handled per Section 8.4. A DATA chunk received in any other state SHOULD be discarded.
DATAチャンクは、以下のESTABLISHED、SHUTDOWN-PENDING、およびSHUTDOWN-SENTのルールに従ってのみ受信する必要があります。 CLOSEDで受信されたDATAチャンクは不意に使用されており、セクション8.4に従って処理する必要があります（SHOULD）。他の状態で受信されたDATAチャンクは破棄されるべきです（SHOULD）。
A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED. An incoming SACK MAY be processed in COOKIE-ECHOED. A SACK in the CLOSED state is out of the blue and SHOULD be processed according to the rules in Section 8.4. A SACK chunk received in any other state SHOULD be discarded.
SACKは、ESTABLISHED、SHUTDOWN-PENDING、およびSHUTDOWN-RECEIVEDで処理する必要があります。着信SACKはCOOKIE-ECHOEDで処理される場合があります。 CLOSED状態のSACKは予定外であり、セクション8.4のルールに従って処理する必要があります（SHOULD）。その他の状態で受信したSACKチャンクは破棄する必要があります（SHOULD）。
An SCTP receiver MUST be able to receive a minimum of 1500 bytes in one SCTP packet. This means that an SCTP endpoint MUST NOT indicate less than 1500 bytes in its initial a_rwnd sent in the INIT or INIT ACK.
SCTPレシーバーは、1つのSCTPパケットで最小1500バイトを受信できる必要があります。これは、SCTPエンドポイントがINITまたはINIT ACKで送信された最初のa_rwndで1500バイト未満を示してはならないことを意味します。
For transmission efficiency, SCTP defines mechanisms for bundling of small user messages and fragmentation of large user messages. The following diagram depicts the flow of user messages through SCTP.
伝送効率を高めるために、SCTPは小さなユーザーメッセージのバンドリングと大きなユーザーメッセージのフラグメンテーションのメカニズムを定義しています。次の図は、SCTPを介したユーザーメッセージのフローを示しています。
In this section, the term "data sender" refers to the endpoint that transmits a DATA chunk and the term "data receiver" refers to the endpoint that receives a DATA chunk. A data receiver will transmit SACK chunks.
このセクションでは、「データ送信者」という用語はDATAチャンクを送信するエンドポイントを指し、「データ受信者」という用語はDATAチャンクを受信するエンドポイントを指します。データレシーバーはSACKチャンクを送信します。
+--------------------------+
| User Messages |
+--------------------------+
SCTP user ^ |
==================|==|=======================================
| v (1)
+------------------+ +--------------------+
| SCTP DATA Chunks | |SCTP Control Chunks |
+------------------+ +--------------------+
^ | ^ |
| v (2) | v (2)
+--------------------------+
| SCTP packets |
+--------------------------+
SCTP ^ |
===========================|==|===========================
| v
Connectionless Packet Transfer Service (e.g., IP)
Notes:
ノート：
1) When converting user messages into DATA chunks, an endpoint will fragment user messages larger than the current association path MTU into multiple DATA chunks. The data receiver will normally reassemble the fragmented message from DATA chunks before delivery to the user (see Section 6.9 for details).
1）ユーザーメッセージをDATAチャンクに変換する場合、エンドポイントは現在の関連付けパスMTUよりも大きいユーザーメッセージを複数のDATAチャンクにフラグメント化します。データレシーバーは通常、DATAチャンクからの断片化されたメッセージをユーザーに配信する前に再構成します（詳細については、セクション6.9を参照してください）。
2) Multiple DATA and control chunks may be bundled by the sender into a single SCTP packet for transmission, as long as the final size of the packet does not exceed the current path MTU. The receiver will unbundle the packet back into the original chunks. Control chunks MUST come before DATA chunks in the packet.
2）パケットの最終サイズが現在のパスMTUを超えない限り、複数のDATAチャンクと制御チャンクが送信側によって1つのSCTPパケットにバンドルされて送信されます。レシーバーはパケットを元のチャンクにアンバンドルします。制御チャンクは、パケットのDATAチャンクの前に来る必要があります。
Figure 6: Illustration of User Data Transfer
図6：ユーザーデータ転送の図
The fragmentation and bundling mechanisms, as detailed in Section 6.9 and Section 6.10, are OPTIONAL to implement by the data sender, but they MUST be implemented by the data receiver, i.e., an endpoint MUST properly receive and process bundled or fragmented data.
セクション6.9とセクション6.10で説明するように、断片化とバンドリングのメカニズムは、データ送信者が実装するオプションですが、データレシーバーが実装する必要があります。つまり、エンドポイントは、バンドルまたはフラグメント化されたデータを適切に受信して処理する必要があります。
This document is specified as if there is a single retransmission timer per destination transport address, but implementations MAY have a retransmission timer for each DATA chunk.
このドキュメントは、あて先トランスポートアドレスごとに単一の再送信タイマーがあるかのように指定されていますが、実装では、各DATAチャンクに再送信タイマーがある場合があります。
The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks:
次の一般的なルールは、送信DATAチャンクの送信および/または再送信のためにデータ送信者によって適用される必要があります：
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A）ピアのrwndがピアにバッファスペースがないことを示している場合（rwndが0、セクション6.2.1を参照）、データ送信者は常に新しいデータを宛先トランスポートアドレスに送信してはなりません（MUST NOT）。ただし、rwndの値に関係なく（0の場合も含む）、cwndで許可されている場合、データ送信者は常に1つのDATAチャンクを受信者に送信できます（以下のルールBを参照）。このルールにより、送信者は、データ受信者からデータ送信者への転送中にSACKが失われたために送信者が見逃したrwndの変更をプローブできます。
When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
レシーバーのアドバタイズされたウィンドウがゼロの場合、このプローブはゼロウィンドウプローブと呼ばれます。ゼロウィンドウプローブは、未解決のDATAチャンクがすべて累積的に確認され、DATAチャンクが実行されていない場合にのみ送信する必要があることに注意してください。ゼロウィンドウプローブをサポートする必要があります。
If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address. This is because the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window. The sender SHOULD send the first zero window probe after 1 RTO when it detects that the receiver has closed its window and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero window probing does not affect the calculation of cwnd.
ゼロウィンドウプローブを実行している間、送信側が受信側から新しいパケットを受信し続ける場合、未確認ウィンドウプローブは、アソシエーションまたは宛先トランスポートアドレスのエラーカウンターをインクリメントしないでください。これは、レシーバーがウィンドウを無期限に閉じたままにする可能性があるためです。ゼロウィンドウをアドバタイズするときのレシーバーの動作については、セクション6.2を参照してください。送信側は、受信側がウィンドウを閉じたことを検出すると、1 RTOの後に最初のゼロウィンドウプローブを送信する必要があり（SHOULD）、その後、プローブ間隔を指数関数的に増加させる必要があります（SHOULD）。また、cwndはセクション7.2.1に従って調整する必要があることに注意してください。ゼロウィンドウプローブは、cwndの計算に影響を与えません。
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.4 of [RFC1122].
[RFC0813]で説明されているように、送信者は新しいDATAチャンクを送信して愚かなウィンドウシンドローム（SWS）を回避するアルゴリズムも持っている必要があります。このアルゴリズムは、[RFC1122]のセクション4.2.3.4で説明されているものと同様にすることができます。
However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender.
ただし、rwndの値（0の場合も含む）に関係なく、cwndで許可されていれば、データ送信者は常に1つのDATAチャンクを受信者に送信できます（以下のルールBを参照）。このルールにより、送信者は、データ受信者からデータ送信者への転送中にSACKが失われたために送信者が見逃したrwndの変更をプローブできます。
B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address.
B）常に、送信者がそのトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、そのトランスポートアドレスに新しいデータを送信してはなりません。
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd).
C）送信者が送信する時間になると、新しいDATAチャンクを送信する前に、送信者は最初に再送信のマークが付けられている未処理のDATAチャンクを送信する必要があります（現在のcwndによって制限されます）。
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows:
D）送信者が新しいDATAチャンクを送信する時間になると、プロトコルパラメーターMax.Burstを使用して、送信されるパケットの数を制限する必要があります。この制限は、cwndを次のように調整することで適用できます（MAY）。
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.
または、出力ルーチンによって送信されるパケットの数を厳密に制限することで適用できます。
E) Then, the sender can send out as many new DATA chunks as rule A and rule B allow.
E）次に、送信者は、ルールAとルールBが許可するだけの新しいDATAチャンクを送信できます。
Multiple DATA chunks committed for transmission MAY be bundled in a single packet. Furthermore, DATA chunks being retransmitted MAY be bundled with new DATA chunks, as long as the resulting packet size does not exceed the path MTU. A ULP may request that no bundling is performed, but this should only turn off any delays that an SCTP implementation may be using to increase bundling efficiency. It does not in itself stop all bundling from occurring (i.e., in case of congestion or retransmission).
送信用にコミットされた複数のDATAチャンクは、単一のパケットにバンドルされる場合があります。さらに、再送信されるDATAチャンクは、結果のパケットサイズがパスMTUを超えない限り、新しいDATAチャンクにバンドルされる場合があります。 ULPはバンドリングを実行しないことを要求する場合がありますが、これはSCTP実装がバンドリング効率を高めるために使用している可能性がある遅延のみをオフにする必要があります。それ自体は、すべてのバンドリングの発生を停止しません（つまり、輻輳または再送信の場合）。
Before an endpoint transmits a DATA chunk, if any received DATA chunks have not been acknowledged (e.g., due to delayed ack), the sender should create a SACK and bundle it with the outbound DATA chunk, as long as the size of the final SCTP packet does not exceed the current MTU. See Section 6.2.
エンドポイントがDATAチャンクを送信する前に、受信したDATAチャンクが確認応答されていない場合（たとえば、遅延ACKのため）、送信者はSACKを作成し、最終的なSCTPのサイズである限り、送信DATAチャンクとバンドルする必要があります パケットは現在のMTUを超えません。 セクション6.2を参照してください。
IMPLEMENTATION NOTE: When the window is full (i.e., transmission is disallowed by rule A and/or rule B), the sender MAY still accept send requests from its upper layer, but MUST transmit no more DATA chunks until some or all of the outstanding DATA chunks are acknowledged and transmission is allowed by rule A and rule B again.
実装上の注意：ウィンドウがいっぱいの場合（つまり、ルールAやルールBによって送信が許可されていない場合）、送信者は上位層からの送信要求を受け入れることができますが、未解決のデータの一部またはすべてが送信されるまで、DATAチャンクを送信してはなりません（MUST）。 DATAチャンクは確認され、送信はルールAとルールBによって再び許可されます。
Whenever a transmission or retransmission is made to any address, if the T3-rtx timer of that address is not currently running, the sender MUST start that timer. If the timer for that address is already running, the sender MUST restart the timer if the earliest (i.e., lowest TSN) outstanding DATA chunk sent to that address is being retransmitted. Otherwise, the data sender MUST NOT restart the timer.
送信または再送信がいずれかのアドレスに対して行われる場合は常に、そのアドレスのT3-rtxタイマーが現在実行されていない場合、送信者はそのタイマーを開始する必要があります。そのアドレスのタイマーがすでに実行されている場合、そのアドレスに送信された最も早い（つまり、最低のTSN）未処理のDATAチャンクが再送信されている場合、送信者はタイマーを再起動する必要があります。それ以外の場合、データ送信者はタイマーを再起動してはなりません（MUST NOT）。
When starting or restarting the T3-rtx timer, the timer value must be adjusted according to the timer rules defined in Sections 6.3.2 and 6.3.3.
T3-rtxタイマーを開始または再起動する場合、セクション6.3.2および6.3.3で定義されているタイマールールに従ってタイマー値を調整する必要があります。
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window.
注：データ送信者は、現在の送信ウィンドウの開始TSNの2 ** 31-1以上のTSNを使用してはなりません（SHOULD NOT）。
The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window.
受信したDATAチャンクが受信ウィンドウ内にある場合、SCTPエンドポイントは常に有効な各DATAチャンクの受信を確認する必要があります。
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122].
受信者のアドバタイズされたウィンドウが0の場合、受信者は、これまでに受信した最大のTSNよりも大きいTSNを持つ新しい着信DATAチャンクをドロップする必要があります。新しい着信DATAチャンクがこれまでに受信した最大のTSN未満のTSN値を保持している場合、受信者は、並べ替えのために保持されている最大のTSNをドロップし、新しい着信DATAチャンクを受け入れる必要があります。どちらの場合でも、そのようなDATAチャンクがドロップされた場合、受信者は、現在の受信ウィンドウに現在まで受信および受け入れられたDATAチャンクのみを示すSACKをすぐに送信する必要があります。ドロップされたDATAチャンクは受け入れられなかったため、SACKに含めることはできません。 [RFC0813]で説明されているように、受信者は、受信者の愚かなウィンドウシンドローム（SWS）を回避するために、受信ウィンドウをアドバタイズするアルゴリズムも持っている必要があります。アルゴリズムは、[RFC1122]のセクション4.2.3.3で説明されているものと同様にすることができます。
The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow.
[RFC2581]のセクション4.2で指定されている遅延確認応答アルゴリズムのガイドラインに従う必要があります。具体的には、受信された確認は少なくとも受信されたパケットごとに（毎秒のデータチャンクではなく）生成されるべきであり（SHOULD）、未確認のデータチャンクの到着から200 ms以内に生成されるべきです（SHOULD）。状況によっては、SCTPトランスミッタが、このドキュメントで詳細に説明されているアルゴリズムで許可されているよりも保守的であることが有益な場合があります。ただし、SCTPトランスミッタは、次のアルゴリズムで許可されているよりも強力であってはなりません。
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data.
SCTP受信機は、受信アプリケーションが新しいデータを消費するときに提供されたウィンドウを更新する以外に、すべての着信パケットに対して複数のSACKを生成してはなりません（MUST NOT）。
IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried.
実装上の注意：確認応答を生成するための最大遅延は、実行されているプロトコルの特定のタイミング要件を満たすために、静的または動的にSCTP管理者が構成できます。
An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms.
実装では、最大遅延を500ミリ秒以上に構成することを許可してはなりません（MUST NOT）。言い換えると、実装はこの値を500ミリ秒未満にしてもよいが、500ミリ秒を超えてはならない（MUST NOT）。
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU.
ULPによってシャットダウンが要求されない限り、確認応答はSACKチャンクで送信する必要があります。この場合、エンドポイントはSHUTDOWNチャンクで確認応答を送信できます（MAY）。 SACKチャンクは、複数のDATAチャンクの受信を確認できます。 SACKチャンク形式については、セクション3.3.4を参照してください。特に、SCTPエンドポイントは、それが受信した（有効なDATAチャンクの）最新の順次TSNを示すために、累積TSN Ackフィールドに入力する必要があります。 TSNが累積TSN Ackフィールドの値より大きい受信DATAチャンクは、ギャップAckブロックフィールドで報告されます。 SCTPエンドポイントは、現在のパスMTUによって制限される単一のSACKチャンクに収まるだけの数のギャップACKブロックを報告する必要があります。
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, the endpoint should use a SACK instead of the SHUTDOWN chunk to acknowledge DATA chunks received out of order.
注：SHUTDOWNチャンクにはGap Ack Blockフィールドは含まれません。したがって、エンドポイントは、順不同で受信したDATAチャンクを確認するために、SHUTDOWNチャンクの代わりにSACKを使用する必要があります。
When a packet arrives with duplicate DATA chunk(s) and with no new DATA chunk(s), the endpoint MUST immediately send a SACK with no delay. If a packet arrives with duplicate DATA chunk(s) bundled with new DATA chunks, the endpoint MAY immediately send a SACK. Normally, receipt of duplicate DATA chunks will occur when the original SACK chunk was lost and the peer's RTO has expired. The duplicate TSN number(s) SHOULD be reported in the SACK as duplicate.
パケットが重複したDATAチャンクで到着し、新しいDATAチャンクがない場合、エンドポイントは遅延なしですぐにSACKを送信する必要があります。パケットが新しいDATAチャンクにバンドルされた重複したDATAチャンクで到着した場合、エンドポイントはすぐにSACKを送信できます（MAY）。通常、重複するDATAチャンクの受信は、元のSACKチャンクが失われ、ピアのRTOが期限切れになったときに発生します。重複するTSN番号は、SACKで重複として報告する必要があります（SHOULD）。
When an endpoint receives a SACK, it MAY use the duplicate TSN information to determine if SACK loss is occurring. Further use of this data is for future study.
エンドポイントがSACKを受信すると、重複したTSN情報を使用して、SACK損失が発生しているかどうかを判断できます。このデータのさらなる利用は将来の研究のためです。
The data receiver is responsible for maintaining its receive buffers. The data receiver SHOULD notify the data sender in a timely manner of changes in its ability to receive data. How an implementation manages its receive buffers is dependent on many factors (e.g., operating system, memory management system, amount of memory, etc.). However, the data sender strategy defined in Section 6.2.1 is based on the assumption of receiver operation similar to the following:
データレシーバーは、受信バッファーの維持を担当します。データレシーバーは、データを受信する能力の変化をタイムリーにデータセンダーに通知する必要があります（SHOULD）。実装がその受信バッファーをどのように管理するかは、多くの要因（オペレーティングシステム、メモリ管理システム、メモリ量など）に依存します。ただし、セクション6.2.1で定義されているデータ送信側の戦略は、次のような受信側の動作を前提としています。
A) At initialization of the association, the endpoint tells the peer how much receive buffer space it has allocated to the association in the INIT or INIT ACK. The endpoint sets a_rwnd to this value.
A）アソシエーションの初期化時に、エンドポイントはピアに、INITまたはINIT ACKでアソシエーションに割り当てた受信バッファースペースの量を通知します。エンドポイントはa_rwndをこの値に設定します。
B) As DATA chunks are received and buffered, decrement a_rwnd by the number of bytes received and buffered. This is, in effect, closing rwnd at the data sender and restricting the amount of data it can transmit.
B）DATAチャンクが受信されてバッファーに入れられたら、a_rwndを受信してバッファーに入れられたバイト数だけデクリメントします。これは事実上、データ送信側でrwndを閉じ、送信できるデータの量を制限しています。
C) As DATA chunks are delivered to the ULP and released from the receive buffers, increment a_rwnd by the number of bytes delivered to the upper layer. This is, in effect, opening up rwnd on the data sender and allowing it to send more data. The data receiver SHOULD NOT increment a_rwnd unless it has released bytes from its receive buffer. For example, if the receiver is holding fragmented DATA chunks in a reassembly queue, it should not increment a_rwnd.
C）DATAチャンクがULPに配信され、受信バッファーから解放されると、上位層に配信されたバイト数だけa_rwndをインクリメントします。これは、事実上、データ送信側でrwndを開いて、さらにデータを送信できるようにすることです。データレシーバーは、受信バッファーからバイトを解放しない限り、a_rwndをインクリメントしないでください（SHOULD NOT）。たとえば、レシーバーが再構成キューにフラグメント化されたDATAチャンクを保持している場合、a_rwndをインクリメントしないでください。
D) When sending a SACK, the data receiver SHOULD place the current value of a_rwnd into the a_rwnd field. The data receiver SHOULD take into account that the data sender will not retransmit DATA chunks that are acked via the Cumulative TSN Ack (i.e., will drop from its retransmit queue).
D）SACKを送信するとき、データレシーバーはa_rwndの現在の値をa_rwndフィールドに配置する必要があります（SHOULD）。データレシーバーは、データセンダーが累積TSN Ackを介して確認応答されたDATAチャンクを再送信しないことを考慮に入れる必要があります（つまり、再送信キューから削除されます）。
Under certain circumstances, the data receiver may need to drop DATA chunks that it has received but hasn't released from its receive buffers (i.e., delivered to the ULP). These DATA chunks may have been acked in Gap Ack Blocks. For example, the data receiver may be holding data in its receive buffers while reassembling a fragmented user message from its peer when it runs out of receive buffer space. It may drop these DATA chunks even though it has acknowledged them in Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT include them in Gap Ack Blocks in subsequent SACKs until they are received again via retransmission. In addition, the endpoint should take into account the dropped data when calculating its a_rwnd.
特定の状況下では、データレシーバーは、受信したが受信バッファーから解放されていない（つまり、ULPに配信されていない）DATAチャンクを削除する必要がある場合があります。これらのDATAチャンクは、ギャップACKブロックで確認応答された可能性があります。たとえば、データレシーバーは、受信バッファースペースが足りなくなったときに、ピアからの断片化されたユーザーメッセージを再構成しながら、受信バッファーにデータを保持している可能性があります。これらのDATAチャンクは、ギャップACKブロックで確認済みであっても、ドロップする可能性があります。データレシーバーがDATAチャンクをドロップする場合、再送信によって再度受信されるまで、後続のSACKのギャップACKブロックにそれらを含めてはなりません（MUST NOT）。さらに、エンドポイントは、a_rwndを計算するときに、ドロップされたデータを考慮する必要があります。
An endpoint SHOULD NOT revoke a SACK and discard data. Only in extreme circumstances should an endpoint use this procedure (such as out of buffer space). The data receiver should take into account that dropping data that has been acked in Gap Ack Blocks can result in suboptimal retransmission strategies in the data sender and thus in suboptimal performance.
エンドポイントはSACKを取り消してデータを破棄するべきではありません（SHOULD NOT）。極端な状況でのみ、エンドポイントがこの手順を使用する必要があります（バッファー領域不足など）。データレシーバーは、ギャップACKブロックで確認応答されたデータをドロップすると、データセンダーで再送信戦略が最適化されず、パフォーマンスが最適化されない可能性があることを考慮する必要があります。
The following example illustrates the use of delayed acknowledgements:
次の例は、遅延確認の使用を示しています。
Endpoint A Endpoint Z
エンドポイントAエンドポイントZ
{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
/------- SACK [TSN Ack=8,block=0]
(cancel T3-rtx timer) <-----/
DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rtx timer)
...
{App sends 1 message; strm 1}
(bundle SACK with DATA)
/----- SACK [TSN Ack=9,block=0] \
/ DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rtx timer) <------/ (Start T3-rtx timer)
(ack delayed)
(send ack)
SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)
Figure 7: Delayed Acknowledgement Example
図7：確認応答の遅延の例
If an endpoint receives a DATA chunk with no user data (i.e., the Length field is set to 16), it MUST send an ABORT with error cause set to "No User Data".
エンドポイントがユーザーデータのないDATAチャンクを受信した場合（つまり、Lengthフィールドが16に設定されている場合）、エンドポイントはエラー原因を「ユーザーデータなし」に設定してABORTを送信する必要があります。
An endpoint SHOULD NOT send a DATA chunk with no user data part.
エンドポイントは、ユーザーデータ部分のないDATAチャンクを送信してはなりません（SHOULD NOT）。
Each SACK an endpoint receives contains an a_rwnd value. This value represents the amount of buffer space the data receiver, at the time of transmitting the SACK, has left of its total receive buffer space (as specified in the INIT/INIT ACK). Using a_rwnd, Cumulative TSN Ack, and Gap Ack Blocks, the data sender can develop a representation of the peer's receive buffer space.
エンドポイントが受信する各SACKには、a_rwnd値が含まれています。この値は、SACKの送信時に、データレシーバーが（INIT / INIT ACKで指定された）受信バッファースペースの合計から残したバッファースペースの量を表します。データ送信者は、a_rwnd、累積TSN Ack、およびギャップAckブロックを使用して、ピアの受信バッファースペースの表現を作成できます。
One of the problems the data sender must take into account when processing a SACK is that a SACK can be received out of order. That is, a SACK sent by the data receiver can pass an earlier SACK and be received first by the data sender. If a SACK is received out of order, the data sender can develop an incorrect view of the peer's receive buffer space.
SACKの処理時にデータ送信者が考慮しなければならない問題の1つは、SACKが順不同で受信される可能性があることです。つまり、データ受信側から送信されたSACKは、以前のSACKを通過して、データ送信側から最初に受信されます。 SACKが順不同で受信された場合、データ送信側はピアの受信バッファスペースの誤ったビューを作成する可能性があります。
Since there is no explicit identifier that can be used to detect out-of-order SACKs, the data sender must use heuristics to determine if a SACK is new.
順不同のSACKを検出するために使用できる明示的な識別子がないため、データ送信者はヒューリスティックを使用してSACKが新しいかどうかを判断する必要があります。
An endpoint SHOULD use the following rules to calculate the rwnd, using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in a received SACK.
エンドポイントは、a_rwnd値、累積TSN Ack、および受信したSACKのギャップAckブロックを使用して、以下のルールを使用してrwndを計算する必要があります（SHOULD）。
A) At the establishment of the association, the endpoint initializes the rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer specified in the INIT or INIT ACK.
A）アソシエーションの確立時に、エンドポイントはrwndを初期化して、INITまたはINIT ACKで指定されたピアをAdvertised Receiver Window Credit（a_rwnd）に設定します。
B) Any time a DATA chunk is transmitted (or retransmitted) to a peer, the endpoint subtracts the data size of the chunk from the rwnd of that peer.
B）DATAチャンクがピアに送信（または再送信）されるたびに、エンドポイントはそのピアのrwndからチャンクのデータサイズを減算します。
C) Any time a DATA chunk is marked for retransmission, either via T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit (Section 7.2.4), add the data size of those chunks to the rwnd.
C）T3-rtxタイマーの有効期限（セクション6.3.3）または高速再送信（セクション7.2.4）のいずれかによって、DATAチャンクが再送信用にマークされている場合は常に、それらのチャンクのデータサイズをrwndに追加します。
Note: If the implementation is maintaining a timer on each DATA chunk, then only DATA chunks whose timer expired would be marked for retransmission.
注：実装が各DATAチャンクでタイマーを維持している場合、タイマーが期限切れになったDATAチャンクのみが再送信用にマークされます。
D) Any time a SACK arrives, the endpoint performs the following:
D）SACKが到着するたびに、エンドポイントは次のことを実行します。
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 累積TSN Ackが累積TSN Ackポイントよりも小さい場合、SACKをドロップします。累積TSN Ackは単調に増加しているため、累積TSN Ackが累積TSN Ackポイントよりも小さいSACKは、順序が正しくないSACKを示します。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）rwndを、新しく受信したa_rwndから、累積TSN AckおよびギャップACKブロックの処理後にまだ未処理のバイト数を引いた値に設定します。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then consider the corresponding DATA that might be possibly missing: Count one miss indication towards Fast Retransmit as described in Section 7.2.4, and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）SACKに、ギャップACKブロックを介して以前に確認応答されたTSNが欠落している場合（たとえば、データレシーバーがデータを破棄した場合）、欠落している可能性がある対応するDATAを検討します。セクション7.2.4で、DATAチャンクが最初に送信された宛先アドレスに対して再送信タイマーが実行されていない場合、その宛先アドレスに対してT3-rtxが開始されます。
iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
iv）累積TSN Ackが高速復旧出口点（7.2.4項）と一致するか超える場合、高速復旧は終了します。
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout).
SCTPエンドポイントは、再送信タイマーT3-rtxを使用して、ピアからのフィードバックがない場合のデータ配信を保証します。このタイマーの持続時間は、RTO（再送信タイムアウト）と呼ばれます。
When an endpoint's peer is multi-homed, the endpoint will calculate a separate RTO for each different destination transport address of its peer endpoint.
エンドポイントのピアがマルチホームの場合、エンドポイントは、ピアエンドポイントの異なる宛先トランスポートアドレスごとに個別のRTOを計算します。
The computation and management of RTO in SCTP follow closely how TCP manages its retransmission timer. To compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation).
SCTPでのRTOの計算と管理は、TCPが再送信タイマーを管理する方法に厳密に従っています。現在のRTOを計算するために、エンドポイントは宛先トランスポートアドレスごとに2つの状態変数を維持します。SRTT（スムーズラウンドトリップ時間）とRTTVAR（ラウンドトリップ時間変動）です。
The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:
SRTT、RTTVAR、およびRTOの計算を管理する規則は次のとおりです。
C1) Until an RTT measurement has been made for a packet sent to the given destination transport address, set RTO to the protocol parameter 'RTO.Initial'.
C1）指定された宛先トランスポートアドレスに送信されたパケットのRTT測定が行われるまで、RTOをプロトコルパラメータ「RTO.Initial」に設定します。
C2) When the first RTT measurement R is made, set
C2）最初のRTT測定Rが行われると、
SRTT <- R,
SRTT <-R、
RTTVAR <- R/2, and
RTTVAR <-R / 2、および
RTO <- SRTT + 4 * RTTVAR.
ラト<-シャート+ 4 *ラトワー。
C3) When a new RTT measurement R' is made, set
C3）新しいRTT測定R 'が行われると、
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
and
そして
SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment.
注：RTTVARへの更新で使用されるSRTTの値は、2番目の割り当てを使用してSRTT自体を更新する前の値です。
After the computation, update RTO <- SRTT + 4 * RTTVAR.
計算後、RTO <-SRTT + 4 * RTTVARを更新します。
C4) When data is in flight and when allowed by rule C5 below, a new RTT measurement MUST be made each round trip. Furthermore, new RTT measurements SHOULD be made no more than once per round trip for a given destination transport address. There are two reasons for this recommendation: First, it appears that measuring more frequently often does not in practice yield any significant benefit [ALLMAN99]; second, if measurements are made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes them to reflect new values) as they would if making only one measurement per round-trip and using RTO.Alpha and RTO.Beta as given in rule C3. However, the exact nature of these adjustments remains a research issue.
C4）データが処理中の場合、および以下のルールC5で許可されている場合は、新しいRTT測定を毎回行う必要があります。さらに、新しいRTT測定は、指定された宛先トランスポートアドレスのラウンドトリップごとに1回だけ行う必要があります。この推奨には2つの理由があります。1つ目は、より頻繁に測定しても実際には大きなメリットが得られないことです[ALLMAN99]。次に、測定がより頻繁に行われる場合は、SRTTとRTTVARが依然としてほぼ同じ割合で変化に適応するように、上記の規則C3のRTO.AlphaとRTO.Betaの値を調整する必要があります（ラウンドトリップの数に関して）ルールC3で規定されているように、RTO.AlphaとRTO.Betaを使用して、往復ごとに1つの測定のみを行う場合と同様に、新しい値を反映するようにします。ただし、これらの調整の正確な性質は研究課題のままです。
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance)
C5）Karnのアルゴリズム：RTT測定は、再送信されたパケットを使用して行われてはなりません（そのため、応答がチャンクの最初のインスタンスに対するものか、それ以降のインスタンスに対するものか不明です）。
IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.
実装に関する注記：RTTの測定は、rが最初に送信されてからTSNがr以下のチャンクが再送信されない場合にのみ、TSN rのチャンクを使用して行う必要があります。
C6) Whenever RTO is computed, if it is less than RTO.Min seconds then it is rounded up to RTO.Min seconds. The reason for this rule is that RTOs that do not have a high minimum value are susceptible to unnecessary timeouts [ALLMAN99].
C6）RTOが計算されるときは常に、RTO.Min秒未満の場合、RTO.Min秒に切り上げられます。このルールの理由は、高い最小値を持たないRTOが不必要なタイムアウトの影響を受けやすいためです[ALLMAN99]。
C7) A maximum value may be placed on RTO provided it is at least RTO.max seconds.
C7）最大値は、RTO.max秒以上であれば、RTOに設定できます。
There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables, other than:
RTT測定値とさまざまな状態変数の計算に使用されるクロック粒度Gには、以下の要件以外は必要ありません。
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G.
G1）RTTVAR = 0の場合、RTTVARが計算されるときは常に、RTTVAR <-Gを調整します。
Experience [ALLMAN99] has shown that finer clock granularities (<= 100 msec) perform somewhat better than more coarse granularities.
経験[ALLMAN99]は、より細かいクロック粒度（<= 100ミリ秒）は、より粗い粒度よりもいくらか優れていることを示しています。
The rules for managing the retransmission timer are as follows:
再送信タイマーの管理規則は次のとおりです。
R1) Every time a DATA chunk is sent to any address (including a retransmission), if the T3-rtx timer of that address is not running, start it running so that it will expire after the RTO of that address. The RTO used here is that obtained after any doubling due to previous T3-rtx timer expirations on the corresponding destination address as discussed in rule E2 below.
R1）DATAチャンクが任意のアドレス（再送信を含む）に送信されるたびに、そのアドレスのT3-rtxタイマーが実行されていない場合は、そのアドレスのRTO後に期限切れになるように実行を開始します。ここで使用されるRTOは、以下のルールE2で説明するように、対応する宛先アドレスで以前のT3-rtxタイマーが期限切れになったために2倍になった後に取得されたものです。
R2) Whenever all outstanding data sent to an address have been acknowledged, turn off the T3-rtx timer of that address.
R2）アドレスに送信されたすべての未処理のデータが確認された場合は常に、そのアドレスのT3-rtxタイマーをオフにします。
R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address).
R3）そのアドレスの最も早い未処理のTSNでDATAチャンクを確認するSACKを受信するたびに、そのアドレスのT3-rtxタイマーを現在のRTOで再起動します（そのアドレスに未処理のデータがまだある場合）。
R4) Whenever a SACK is received missing a TSN that was previously acknowledged via a Gap Ack Block, start the T3-rtx for the destination address to which the DATA chunk was originally transmitted if it is not already running.
R4）ギャップACKブロックを介して以前に確認応答されたTSNがないSACKが受信されるたびに、DATAチャンクが最初に送信された宛先アドレスに対してT3-rtxを開始します（まだ実行されていない場合）。
The following example shows the use of various timer rules (assuming that the receiver uses delayed acks).
次の例は、さまざまなタイマールールの使用法を示しています（受信者が遅延ACKを使用すると想定しています）。
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Restart T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Figure 8: Timer Rule Examples
図8：タイマールールの例
Whenever the retransmission timer T3-rtx expires for a destination address, do the following:
宛先アドレスの再送信タイマーT3-rtxが期限切れになるたびに、以下を実行します。
E1) For the destination address for which the timer expires, adjust its ssthresh with rules defined in Section 7.2.3 and set the cwnd <- MTU.
E1）タイマーが時間切れになる宛先アドレスについては、セクション7.2.3で定義されたルールを使用してそのssthreshを調整し、cwnd <- MTUを設定します。
E2) For the destination address for which the timer expires, set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in rule C7 above (RTO.max) may be used to provide an upper bound to this doubling operation.
E2）タイマーが期限切れになる宛先アドレスに対して、RTO <-RTO * 2（「タイマーのバックオフ」）を設定します。上記のルールC7で説明した最大値（RTO.max）を使用して、この2倍演算の上限を指定できます。
E3) Determine how many of the earliest (i.e., lowest TSN) outstanding DATA chunks for the address for which the T3-rtx has expired will fit into a single packet, subject to the MTU constraint for the path corresponding to the destination transport address to which the retransmission is being sent (this may be different from the address for which the timer expires; see Section 6.4). Call this value K. Bundle and retransmit those K DATA chunks in a single packet to the destination endpoint.
E3）宛先トランスポートアドレスに対応するパスのMTU制約に従って、T3-rtxの有効期限が切れたアドレスの最も早い（つまりTSNが最も低い）未処理のDATAチャンクのうちの1つが単一のパケットに収まる数を決定します。再送信が送信されています（これは、タイマーが期限切れになるアドレスとは異なる場合があります。セクション6.4を参照してください）。この値をKと呼び、バンドルして、それらのK DATAチャンクを1つのパケットで宛先エンドポイントに再送信します。
E4) Start the retransmission timer T3-rtx on the destination address to which the retransmission is sent, if rule R1 above indicates to do so. The RTO to be used for starting T3-rtx should be the one for the destination address to which the retransmission is sent, which, when the receiver is multi-homed, may be different from the destination address for which the timer expired (see Section 6.4 below).
E4）上記のルールR1が指示する場合は、再送信の送信先の宛先アドレスで再送信タイマーT3-rtxを開始します。 T3-rtxを開始するために使用されるRTOは、再送信が送信される宛先アドレスのRTOである必要があります。これは、レシーバーがマルチホームの場合、タイマーが期限切れになった宛先アドレスとは異なる場合があります（セクションを参照） 6.4以下）。
After retransmitting, once a new RTT measurement is obtained (which can happen only when new data has been sent and acknowledged, per rule C5, or for a measurement made from a HEARTBEAT; see Section 8.3), the computation in rule C3 is performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to doubling (rule E2).
再送信後、新しいRTT測定が取得されると（ルールC5に従って、またはHEARTBEATから行われた測定の場合、新しいデータが送信および確認された場合にのみ発生する可能性があります。セクション8.3を参照）、ルールC3の計算が実行されます。 RTOの計算を含みます。これにより、RTOが2倍になった後、RTOが「折りたたまれる」可能性があります（ルールE2）。
Note: Any DATA chunks that were sent to the address for which the T3-rtx timer expired but did not fit in one MTU (rule E3 above) should be marked for retransmission and sent as soon as cwnd allows (normally, when a SACK arrives).
注：T3-rtxタイマーの期限が切れたが1つのMTU（上記のルールE3）に収まらなかったアドレスに送信されたDATAチャンクは、再送信のマークを付け、cwndが許可するとすぐに送信する必要があります（通常、SACKが到着したとき） ）。
The final rule for managing the retransmission timer concerns failover (see Section 6.4.1):
再送信タイマーを管理するための最後のルールは、フェイルオーバーに関するものです（セクション6.4.1を参照）。
F1) Whenever an endpoint switches from the current destination transport address to a different one, the current retransmission timers are left running. As soon as the endpoint transmits a packet containing DATA chunk(s) to the new transport address, start the timer on that transport address, using the RTO value of the destination address to which the data is being sent, if rule R1 indicates to do so.
F1）エンドポイントが現在の宛先トランスポートアドレスから別のアドレスに切り替えるたびに、現在の再送信タイマーは実行されたままになります。エンドポイントがDATAチャンクを含むパケットを新しいトランスポートアドレスに送信するとすぐに、ルールR1が指示する場合は、データが送信される宛先アドレスのRTO値を使用して、そのトランスポートアドレスでタイマーを開始します。そう。
An SCTP endpoint is considered multi-homed if there are more than one transport address that can be used as a destination address to reach that endpoint.
SCTPエンドポイントは、そのエンドポイントに到達するための宛先アドレスとして使用できるトランスポートアドレスが複数ある場合、マルチホームと見なされます。
Moreover, the ULP of an endpoint shall select one of the multiple destination addresses of a multi-homed peer endpoint as the primary path (see Section 5.1.2 and Section 10.1 for details).
さらに、エンドポイントのULPは、マルチホームピアエンドポイントの複数の宛先アドレスの1つをプライマリパスとして選択する必要があります（詳細については、セクション5.1.2およびセクション10.1を参照）。
By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use.
デフォルトでは、SCTPユーザーが使用する宛先トランスポートアドレス（および場合によってはソーストランスポートアドレス）を明示的に指定しない限り、エンドポイントは常にプライマリパスに送信する必要があります（SHOULD）。
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.
エンドポイントは、応答チャンク（SACK、HEARTBEAT ACKなど）を、DATAの受信元と同じ宛先トランスポートアドレスまたは応答先の制御チャンクに送信する必要があります（SHOULD）。エンドポイントが応答チャンクと一緒にDATAチャンクをバンドルしている場合も、このルールに従う必要があります。
However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received.
ただし、単一のSACKで異なる送信元アドレスからパケットで受信した複数のDATAチャンクを確認する場合、SACKチャンクは、確認中のDATAまたは制御チャンクの受信元の宛先トランスポートアドレスの1つに送信されることがあります。
When a receiver of a duplicate DATA chunk sends a SACK to a multi-homed endpoint, it MAY be beneficial to vary the destination address and not use the source address of the DATA chunk. The reason is that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken.
重複するDATAチャンクの受信者がSACKをマルチホームエンドポイントに送信する場合、宛先アドレスを変更し、DATAチャンクの送信元アドレスを使用しないことが有益な場合があります。その理由は、マルチホームのエンドポイントから重複を受信すると、SACKの戻りパス（DATAチャンクのソースアドレスで指定されている）が壊れていることを示している可能性があるためです。
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
さらに、ピアがマルチホームの場合、エンドポイントは、タイムアウトしたチャンクを、DATAチャンクが送信された最後の宛先アドレスとは異なるアクティブな宛先トランスポートアドレスに再送信する必要があります（SHOULD）。
Retransmissions do not affect the total outstanding data count. However, if the DATA chunk is retransmitted onto a different destination address, both the outstanding data counts on the new destination address and the old destination address to which the data chunk was last sent shall be adjusted accordingly.
再送信は、未処理の合計データ数には影響しません。ただし、DATAチャンクが別の宛先アドレスに再送信される場合、新しい宛先アドレスの未処理のデータ数と、データチャンクが最後に送信された古い宛先アドレスの両方がそれに応じて調整されます。
Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from the SCTP user.
マルチホームSCTPエンドポイントの一部のトランスポートアドレスは、特定のエラー状態（セクション8.2を参照）の発生またはSCTPユーザーからの調整により、非アクティブになる場合があります。
When there is outbound data to send and the primary path becomes inactive (e.g., due to failures), or where the SCTP user explicitly requests to send data to an inactive destination transport address, before reporting an error to its ULP, the SCTP endpoint should try to send the data to an alternate active destination transport address if one exists.
送信するアウトバウンドデータがあり、プライマリパスが非アクティブになった場合（障害など）、またはSCTPユーザーがULPにエラーを報告する前に、非アクティブな宛先トランスポートアドレスにデータを送信するように明示的に要求した場合、SCTPエンドポイントは 代替のアクティブな宛先トランスポートアドレス（存在する場合）にデータを送信してみてください。
When retransmitting data that timed out, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed-out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
タイムアウトになったデータを再送信するとき、エンドポイントがマルチホームの場合、再送信選択ポリシーで送信元と宛先の各アドレスペアを考慮する必要があります。タイムアウトしたデータを再送信する場合、エンドポイントは、パケットが送信された元の送信元と宛先のペアから、最も異なる送信元と宛先のペアを選択する必要があります。
Note: Rules for picking the most divergent source-destination pair are an implementation decision and are not specified within this document.
注：最も分岐している送信元と宛先のペアを選択するためのルールは実装上の決定であり、このドキュメントでは指定されていません。
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK.
すべてのDATAチャンクは、有効なストリーム識別子を運ぶ必要があります。エンドポイントは、無効なストリーム識別子を持つDATAチャンクを受信した場合、通常の手順に従ってDATAチャンクの受信を確認し、原因を「無効なストリーム識別子」に設定したERRORチャンクを直ちに送信します（セクション3.3.10を参照）。 DATAチャンクを破棄します。エンドポイントは、ERRORがSACKに続く限り、ERRORチャンクをSACKと同じパケットにバンドルできます。
The Stream Sequence Number in all the streams MUST start from 0 when the association is established. Also, when the Stream Sequence Number reaches the value 65535 the next Stream Sequence Number MUST be set to 0.
すべてのストリームのストリームシーケンス番号は、関連付けが確立されたときに0から開始する必要があります。また、ストリームシーケンス番号が値65535に達すると、次のストリームシーケンス番号を0に設定する必要があります。
Within a stream, an endpoint MUST deliver DATA chunks received with the U flag set to 0 to the upper layer according to the order of their Stream Sequence Number. If DATA chunks arrive out of order of their Stream Sequence Number, the endpoint MUST hold the received DATA chunks from delivery to the ULP until they are reordered.
ストリーム内では、エンドポイントは、Uフラグを0に設定して受信したDATAチャンクを、ストリームシーケンス番号の順序に従って上位層に配信する必要があります。 DATAチャンクがストリームシーケンス番号の順不同で到着した場合、エンドポイントは、再注文されるまで、受信したDATAチャンクをULPへの配信から保持しなければなりません（MUST）。
However, an SCTP endpoint can indicate that no ordered delivery is required for a particular DATA chunk transmitted within the stream by setting the U flag of the DATA chunk to 1.
ただし、SCTPエンドポイントは、DATAチャンクのUフラグを1に設定することにより、ストリーム内で送信される特定のDATAチャンクに順序付けられた配信が不要であることを示すことができます。
When an endpoint receives a DATA chunk with the U flag set to 1, it must bypass the ordering mechanism and immediately deliver the data to the upper layer (after reassembly if the user data is fragmented by the data sender).
エンドポイントは、Uフラグが1に設定されたDATAチャンクを受信すると、順序付けメカニズムをバイパスし、すぐにデータを上位層に配信する必要があります（ユーザーデータがデータ送信者によって断片化されている場合は、再構築後）。
This provides an effective way of transmitting "out-of-band" data in a given stream. Also, a stream can be used as an "unordered" stream by simply setting the U flag to 1 in all DATA chunks sent through that stream.
これにより、特定のストリームで「帯域外」データを送信する効果的な方法が提供されます。また、ストリームは、そのストリームを通じて送信されるすべてのDATAチャンクでUフラグを1に設定するだけで、「順序付けされていない」ストリームとして使用できます。
IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an implementation may choose to place the DATA chunk in an outbound packet that is at the head of the outbound transmission queue if possible.
実装上の注意：順序付けされていないDATAチャンクを送信する場合、実装は、可能であれば、送信チャンクの先頭にある送信パケットにDATAチャンクを配置することを選択できます。
The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1 has no significance. The sender can fill it with arbitrary value, but the receiver MUST ignore the field.
Uフラグが1に設定されたDATAチャンクの「ストリームシーケンス番号」フィールドには意味がありません。送信者は任意の値を入力できますが、受信者はフィールドを無視する必要があります。
Note: When transmitting ordered and unordered data, an endpoint does not increment its Stream Sequence Number when transmitting a DATA chunk with U flag set to 1.
注：順序付けられたデータと順序付けされていないデータを送信する場合、エンドポイントは、Uフラグが1に設定されたDATAチャンクを送信するときに、ストリームシーケンス番号を増分しません。
Upon the reception of a new DATA chunk, an endpoint shall examine the continuity of the TSNs received. If the endpoint detects a gap in the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack Blocks immediately. The data receiver continues sending a SACK after receipt of each SCTP packet that doesn't fill the gap.
新しいDATAチャンクを受信すると、エンドポイントは受信したTSNの連続性を検査します。エンドポイントが受信したDATAチャンクシーケンスのギャップを検出した場合、エンドポイントはギャップACKブロックを含むSACKをすぐに送信する必要があります（SHOULD）。データレシーバーは、ギャップを埋めない各SCTPパケットを受信した後も、SACKを送信し続けます。
Based on the Gap Ack Block from the received SACK, the endpoint can calculate the missing DATA chunks and make decisions on whether to retransmit them (see Section 6.2.1 for details).
エンドポイントは、受信したSACKからのギャップACKブロックに基づいて、欠落しているDATAチャンクを計算し、それらを再送信するかどうかを決定できます（詳細については、セクション6.2.1を参照）。
Multiple gaps can be reported in one single SACK (see Section 3.3.4).
1つのSACKで複数のギャップを報告できます（セクション3.3.4を参照）。
When its peer is multi-homed, the SCTP endpoint SHOULD always try to send the SACK to the same destination address from which the last DATA chunk was received.
ピアがマルチホームの場合、SCTPエンドポイントは常に、最後のDATAチャンクが受信されたのと同じ宛先アドレスにSACKを送信しようとする必要があります（SHOULD）。
Upon the reception of a SACK, the endpoint MUST remove all DATA chunks that have been acknowledged by the SACK's Cumulative TSN Ack from its transmit queue. The endpoint MUST also treat all the DATA chunks with TSNs not included in the Gap Ack Blocks reported by the SACK as "missing". The number of "missing" reports for each outstanding DATA chunk MUST be recorded by the data sender in order to make retransmission decisions. See Section 7.2.4 for details.
SACKを受信すると、エンドポイントは、SACKの累積TSN Ackによって確認応答されたすべてのDATAチャンクを送信キューから削除する必要があります。エンドポイントは、SACKによって報告されたギャップACKブロックに含まれないTSNを持つすべてのDATAチャンクも「欠落」として扱わなければなりません（MUST）。再送信の決定を行うために、未解決の各DATAチャンクの「欠落」レポートの数をデータ送信者が記録する必要があります。詳細については、7.2.4項を参照してください。
The following example shows the use of SACK to report a gap.
次の例は、SACKを使用してギャップを報告する方法を示しています。
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
Figure 9: Reporting a Gap using SACK
図9：SACKを使用したギャップの報告
The maximum number of Gap Ack Blocks that can be reported within a single SACK chunk is limited by the current path MTU. When a single SACK cannot cover all the Gap Ack Blocks needed to be reported due to the MTU limitation, the endpoint MUST send only one SACK, reporting the Gap Ack Blocks from the lowest to highest TSNs, within the size limit set by the MTU, and leave the remaining highest TSN numbers unacknowledged.
1つのSACKチャンク内でレポートできるギャップACKブロックの最大数は、現在のパスMTUによって制限されます。 MTUの制限により、1つのSACKで報告する必要のあるすべてのギャップACKブロックをカバーできない場合、エンドポイントは1つのSACKのみを送信し、MTUによって設定されたサイズ制限内で最低から最高のTSNまでのギャップACKブロックを報告する必要があります。残りの最大のTSN番号は未確認のままにします。
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the CRC32c checksum value calculated on the packet, as described below.
SCTPパケットを送信する場合、エンドポイントは、以下で説明するように、パケットで計算されたCRC32cチェックサム値を含めることにより、送信のデータ整合性を強化する必要があります。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter MUST
パケットが構築された後（SCTP共通ヘッダーと1つ以上の制御またはデータチャンクを含む）、送信機は
1) fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to '0's,
1）SCTP共通ヘッダーに適切な検証タグを入力し、チェックサムフィールドを「0」に初期化します。
2) calculate the CRC32c checksum of the whole packet, including the SCTP common header and all the chunks (refer to Appendix B for details of the CRC32c algorithm); and
2）SCTP共通ヘッダーとすべてのチャンクを含む、パケット全体のCRC32cチェックサムを計算します（CRC32cアルゴリズムの詳細については、付録Bを参照してください）。そして
3) put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3）結果の値を共通ヘッダーのチェックサムフィールドに入れ、残りのビットは変更しないでください。
When an SCTP packet is received, the receiver MUST first check the CRC32c checksum as follows:
SCTPパケットを受信すると、受信者はまず次のようにCRC32cチェックサムを確認する必要があります。
1) Store the received CRC32c checksum value aside.
1）受信したCRC32cチェックサム値を保存します。
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate a CRC32c checksum value of the whole received packet.
2）受信したSCTPパケットのチェックサムフィールドの32ビットをすべて「0」に置き換え、受信したパケット全体のCRC32cチェックサム値を計算します。
3) Verify that the calculated CRC32c checksum is the same as the received CRC32c checksum. If it is not, the receiver MUST treat the packet as an invalid SCTP packet.
3）計算されたCRC32cチェックサムが受信したCRC32cチェックサムと同じであることを確認します。そうでない場合、受信者はパケットを無効なSCTPパケットとして扱わなければなりません（MUST）。
The default procedure for handling invalid SCTP packets is to silently discard them.
無効なSCTPパケットを処理するためのデフォルトの手順は、それらをサイレントに破棄することです。
Any hardware implementation SHOULD be done in a way that is verifiable by the software.
ハードウェアの実装は、ソフトウェアで検証可能な方法で行う必要があります。
An endpoint MAY support fragmentation when sending DATA chunks, but it MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint MUST return an error to its upper layer and not attempt to send the user message.
エンドポイントは、DATAチャンクを送信するときの断片化をサポートしてもかまいませんが、DATAチャンクを受信するときの再構成をサポートする必要があります。エンドポイントがフラグメント化をサポートしている場合、送信されるユーザーメッセージのサイズによって送信SCTPパケットサイズが現在のMTUを超える場合、エンドポイントはユーザーメッセージをフラグメント化する必要があります。実装がアウトバウンドユーザーメッセージの断片化をサポートしない場合、エンドポイントはその上位層にエラーを返し、ユーザーメッセージの送信を試みてはなりません（MUST）。
Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation, it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current Path MTU (P-MTU).
注：断片化をサポートする実装が、その上位層で断片化をオフにするメカニズムを利用できるようにする場合、そうする可能性があります。ただし、そうすることで、フラグメンテーションをサポートしない実装と同様に反応する必要があります。つまり、現在のパスMTU（P-MTU）を超える送信を拒否する必要があります。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
実装上の注意：このエラーの場合、セクション10.1で説明した送信プリミティブは、上位層にエラーを返す必要があります。
If its peer is multi-homed, the endpoint shall choose a size no larger than the association Path MTU. The association Path MTU is the smallest Path MTU of all destination addresses.
ピアがマルチホームである場合、エンドポイントはアソシエーションパスMTU以下のサイズを選択する必要があります。関連パスMTUは、すべての宛先アドレスの最小パスMTUです。
Note: Once a message is fragmented, it cannot be re-fragmented. Instead, if the PMTU has been reduced, then IP fragmentation must be used. Please see Section 7.3 for details of PMTU discovery.
注：メッセージが断片化されると、再度断片化することはできません。代わりに、PMTUが削減されている場合は、IPフラグメンテーションを使用する必要があります。 PMTU検出の詳細については、セクション7.3を参照してください。
When determining when to fragment, the SCTP implementation MUST take into account the SCTP packet header as well as the DATA chunk header(s). The implementation MUST also take into account the space required for a SACK chunk if bundling a SACK chunk with the DATA chunk.
いつフラグメント化するかを決定するとき、SCTP実装は、SCTPパケットヘッダーとDATAチャンクヘッダーを考慮する必要があります。 SACKチャンクをDATAチャンクとバンドルする場合、実装はSACKチャンクに必要なスペースも考慮する必要があります。
Fragmentation takes the following steps:
断片化は次のステップを踏みます：
1) The data sender MUST break the user message into a series of DATA chunks such that each chunk plus SCTP overhead fits into an IP datagram smaller than or equal to the association Path MTU.
1）データ送信側は、ユーザーメッセージを一連のDATAチャンクに分割して、各チャンクとSCTPオーバーヘッドを関連付けたパスMTU以下のIPデータグラムに適合させる必要があります。
2) The transmitter MUST then assign, in sequence, a separate TSN to each of the DATA chunks in the series. The transmitter assigns the same SSN to each of the DATA chunks. If the user indicates that the user message is to be delivered using unordered delivery, then the U flag of each DATA chunk of the user message MUST be set to 1.
2）次に、送信機は、順番に、一連のDATAチャンクのそれぞれに個別のTSNを割り当てなければなりません（MUST）。送信機は、DATAチャンクのそれぞれに同じSSNを割り当てます。ユーザーメッセージが順序付けられていない配信を使用して配信されることをユーザーが示す場合、ユーザーメッセージの各DATAチャンクのUフラグを1に設定する必要があります。
3) The transmitter MUST also set the B/E bits of the first DATA chunk in the series to '10', the B/E bits of the last DATA chunk in the series to '01', and the B/E bits of all other DATA chunks in the series to '00'.
3）送信機はまた、シリーズの最初のDATAチャンクのB / Eビットを「10」に、シリーズの最後のDATAチャンクのB / Eビットを「01」に、そしてB / Eビットをシリーズ内の他のすべてのDATAチャンクは「00」に。
An endpoint MUST recognize fragmented DATA chunks by examining the B/E bits in each of the received DATA chunks, and queue the fragmented DATA chunks for reassembly. Once the user message is reassembled, SCTP shall pass the reassembled user message to the specific stream for possible reordering and final dispatching.
エンドポイントは、受信した各DATAチャンクのB / Eビットを調べて断片化されたDATAチャンクを認識し、断片化されたDATAチャンクを再構成のためにキューに入れる必要があります。ユーザーメッセージが再構成されると、SCTPは、再構成されたユーザーメッセージを特定のストリームに渡して、並べ替えと最終的なディスパッチを実行できるようにします。
Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the reassembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received.
注：データレシーバーがバッファースペースを使い果たしている間に、メッセージの再構成が完了するまでフラグメントを待機している場合は、部分配信API（セクション10を参照）を介して受信メッセージの一部をディスパッチし、受信バッファーの一部を解放する必要がありますメッセージの残りの部分を受信できるようにスペース。
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram,
エンドポイントは、1つの送信SCTPパケットに複数のチャンクを含めるだけで、チャンクをバンドルします。結果のIPデータグラムの合計サイズ、
including the SCTP packet and IP headers, MUST be less that or equal to the current Path MTU.
SCTPパケットとIPヘッダーを含め、現在のパスMTU以下である必要があります。
If its peer endpoint is multi-homed, the sending endpoint shall choose a size no larger than the latest MTU of the current primary path.
ピアエンドポイントがマルチホームの場合、送信エンドポイントは、現在のプライマリパスの最新のMTU以下のサイズを選択する必要があります。
When bundling control chunks with DATA chunks, an endpoint MUST place control chunks first in the outbound SCTP packet. The transmitter MUST transmit DATA chunks within an SCTP packet in increasing order of TSN.
制御チャンクをDATAチャンクとバンドルする場合、エンドポイントは制御チャンクを最初にアウトバウンドSCTPパケットに配置する必要があります。 送信機は、TSNの昇順でSCTPパケット内のDATAチャンクを送信する必要があります。
Note: Since control chunks must be placed first in a packet and since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks.
注：コントロールチャンクはパケットの最初に配置する必要があり、DATAチャンクはSHUTDOWNまたはSHUTDOWN ACKチャンクの前に送信する必要があるため、DATAチャンクはSHUTDOWNまたはSHUTDOWN ACKチャンクとバンドルできません。
Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk is a chunk that is not completely contained in the SCTP packet; i.e., the SCTP packet is too short to contain all the bytes of the chunk as indicated by the chunk length.
部分的なチャンクはSCTPパケットに配置してはなりません（MUST NOT）。部分チャンクは、SCTPパケットに完全には含まれていないチャンクです。つまり、SCTPパケットが短すぎて、チャンクの長さで示されるように、チャンクのすべてのバイトを含めることができません。
An endpoint MUST process received chunks in their order in the packet. The receiver uses the Chunk Length field to determine the end of a chunk and beginning of the next chunk taking account of the fact that all chunks end on a 4-byte boundary. If the receiver detects a partial chunk, it MUST drop the chunk.
エンドポイントは、パケット内の順序で受信したチャンクを処理する必要があります。受信者は、チャンク長フィールドを使用して、すべてのチャンクが4バイト境界で終了するという事実を考慮して、チャンクの終わりと次のチャンクの始まりを決定します。レシーバーが部分的なチャンクを検出した場合は、チャンクをドロップする必要があります。
An endpoint MUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE with any other chunks.
エンドポイントは、INIT、INIT ACK、またはSHUTDOWN COMPLETEを他のチャンクとバンドルしてはなりません（MUST NOT）。
Congestion control is one of the basic functions in SCTP. For some applications, it may be likely that adequate resources will be allocated to SCTP traffic to ensure prompt delivery of time-critical data -- thus, it would appear to be unlikely, during normal operations, that transmissions encounter severe congestion conditions. However, SCTP must operate under adverse operational conditions, which can develop upon partial network failures or unexpected traffic surges. In such situations, SCTP must follow correct congestion control steps to recover from congestion quickly in order to get data delivered as soon as possible. In the absence of network congestion, these preventive congestion control algorithms should show no impact on the protocol performance.
輻輳制御は、SCTPの基本機能の1つです。一部のアプリケーションでは、適切なリソースがSCTPトラフィックに割り当てられ、タイムクリティカルなデータの迅速な配信が保証される可能性があります。そのため、通常の操作中に、送信で深刻な輻輳状態が発生する可能性は低いと思われます。ただし、SCTPは、ネットワークの部分的な障害や予期しないトラフィックの急増により発生する可能性のある悪条件で動作する必要があります。このような状況では、SCTPは正しい輻輳制御手順に従って、輻輳からすばやく回復し、データをできるだけ早く配信する必要があります。ネットワークの輻輳がない場合、これらの予防的輻輳制御アルゴリズムは、プロトコルのパフォーマンスに影響を与えないはずです。
IMPLEMENTATION NOTE: As far as its specific performance requirements are met, an implementation is always allowed to adopt a more conservative congestion control algorithm than the one defined below.
実装上の注意：特定のパフォーマンス要件が満たされている限り、実装では、以下に定義するものよりも保守的な輻輳制御アルゴリズムを採用することが常に許可されます。
The congestion control algorithms used by SCTP are based on [RFC2581]. This section describes how the algorithms defined in [RFC2581] are adapted for use in SCTP. We first list differences in protocol designs between TCP and SCTP, and then describe SCTP's congestion control scheme. The description will use the same terminology as in TCP congestion control whenever appropriate.
SCTPが使用する輻輳制御アルゴリズムは、[RFC2581]に基づいています。このセクションでは、[RFC2581]で定義されたアルゴリズムがSCTPでの使用にどのように適合されるかについて説明します。まず、TCPとSCTPのプロトコル設計の違いをリストし、次にSCTPの輻輳制御方式について説明します。説明では、必要に応じて、TCP輻輳制御と同じ用語を使用します。
SCTP congestion control is always applied to the entire association, and not to individual streams.
SCTPの輻輳制御は、常に個々のストリームではなく、関連付け全体に適用されます。
Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. SCTP considers the information carried in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has been acknowledged by SACK, including DATA that arrived at the receiving end out of order, is not considered fully delivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack field in the SACK). Consequently, the value of cwnd controls the amount of outstanding data, rather than (as in the case of non-SACK TCP) the upper bound between the highest acknowledged sequence number and the latest DATA chunk that can be sent within the congestion window. SCTP SACK leads to different implementations of Fast Retransmit and Fast Recovery than non-SACK TCP. As an example, see [FALL96].
SCTP SACKのギャップACKブロックは、TCP SACKと同じ意味を持っています。 TCPは、SACKで伝送される情報を参考情報としてのみ見なします。 SCTPは、SACKチャンクのギャップACKブロックで運ばれる情報を助言と見なします。 SCTPでは、順不同で受信側に到着したDATAを含め、SACKによって確認応答されたDATAチャンクは、累積TSN AckポイントがDATAチャンクのTSNを通過するまで完全に配信されたとは見なされません（つまり、DATAチャンクはSACKのCumulative TSN Ackフィールドで確認されました）。したがって、cwndの値は、（非SACK TCPの場合のように）確認応答された最大のシーケンス番号と輻輳ウィンドウ内で送信できる最新のDATAチャンクとの間の上限ではなく、未処理のデータの量を制御します。 SCTP SACKは、非SACK TCPとは異なる高速再送信および高速リカバリの実装につながります。例として、[FALL96]を参照してください。
The biggest difference between SCTP and TCP, however, is multi-homing. SCTP is designed to establish robust communication associations between two endpoints each of which may be reachable by more than one transport address. Potentially different addresses may lead to different data paths between the two endpoints; thus, ideally one may need a separate set of congestion control parameters for each of the paths. The treatment here of congestion control for multi-homed receivers is new with SCTP and may require refinement in the future. The current algorithms make the following assumptions:
ただし、SCTPとTCPの最大の違いはマルチホーミングです。 SCTPは、2つ以上のトランスポートアドレスから到達可能な2つのエンドポイント間に堅牢な通信アソシエーションを確立するように設計されています。潜在的に異なるアドレスは、2つのエンドポイント間の異なるデータパスにつながる可能性があります。したがって、理想的には、パスごとに輻輳制御パラメータの個別のセットが必要になる場合があります。ここでのマルチホームレシーバーの輻輳制御の扱いはSCTPの新機能であり、今後の改良が必要になる可能性があります。現在のアルゴリズムでは、次のことを前提としています。
o The sender usually uses the same destination address until being instructed by the upper layer to do otherwise; however, SCTP may change to an alternate destination in the event an address is marked inactive (see Section 8.2). Also, SCTP may retransmit to a different transport address than the original transmission.
o 送信者は通常、上位層から別の方法で指示されるまで、同じ宛先アドレスを使用します。ただし、アドレスが非アクティブとしてマークされた場合、SCTPは代替の宛先に変更されることがあります（セクション8.2を参照）。また、SCTPは元の送信とは異なるトランスポートアドレスに再送信する場合があります。
o The sender keeps a separate congestion control parameter set for each of the destination addresses it can send to (not each source-destination pair but for each destination). The parameters should decay if the address is not used for a long enough time period.
o 送信者は、送信可能な宛先アドレスごとに個別の輻輳制御パラメーターセットを保持します（各送信元と宛先のペアではなく、宛先ごとに）。アドレスが十分に長い期間使用されない場合、パラメータは減衰するはずです。
o For each of the destination addresses, an endpoint does slow start upon the first transmission to that address.
o 宛先アドレスごとに、エンドポイントはそのアドレスへの最初の送信時にスロースタートします。
Note: TCP guarantees in-sequence delivery of data to its upper-layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper-layer protocol even if there is a gap in TSN if the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery is indicated. Although this does not affect cwnd, it might affect rwnd calculation.
注：TCPは、単一のTCPセッション内の上位層プロトコルへのデータの順次配信を保証します。これは、TCPが受信したシーケンス番号のギャップに気づいた場合、欠落したデータよりも大きいシーケンス番号で受信されたデータを配信する前に、ギャップが埋められるまで待機することを意味します。一方、ストリームシーケンス番号が特定のストリームに対して連続している場合（つまり、欠落しているDATAチャンクが異なるストリームの場合）、またはTSNにギャップがある場合でも、SCTPは上位層プロトコルにデータを配信できます。未注文の配送が表示されます。これはcwndには影響しませんが、rwndの計算に影響する可能性があります。
The slow-start and congestion avoidance algorithms MUST be used by an endpoint to control the amount of data being injected into the network. The congestion control in SCTP is employed in regard to the association, not to an individual stream. In some situations, it may be beneficial for an SCTP sender to be more conservative than the algorithms allow; however, an SCTP sender MUST NOT be more aggressive than the following algorithms allow.
スロースタートおよび輻輳回避アルゴリズムは、ネットワークに注入されるデータの量を制御するためにエンドポイントで使用する必要があります。 SCTPの輻輳制御は、個々のストリームではなく、アソシエーションに関して使用されます。状況によっては、SCTP送信者がアルゴリズムで許可されているよりも保守的であることが有益な場合があります。ただし、SCTP送信者は、次のアルゴリズムで許可されているよりも積極的にはなりません。
Like TCP, an SCTP endpoint uses the following three control variables to regulate its transmission rate.
TCPと同様に、SCTPエンドポイントは次の3つの制御変数を使用して伝送速度を調整します。
o Receiver advertised window size (rwnd, in bytes), which is set by the receiver based on its available buffer space for incoming packets.
o 受信者がアドバタイズするウィンドウサイズ（バイト単位のrwnd）。これは、受信パケットが使用できるバッファースペースに基づいて受信者が設定します。
Note: This variable is kept on the entire association.
注：この変数は、関連付け全体で保持されます。
o Congestion control window (cwnd, in bytes), which is adjusted by the sender based on observed network conditions.
o 輻輳制御ウィンドウ（バイト単位のcwnd）。観測されたネットワーク状態に基づいて送信側によって調整されます。
Note: This variable is maintained on a per-destination-address basis.
注：この変数は、宛先アドレスごとに維持されます。
o Slow-start threshold (ssthresh, in bytes), which is used by the sender to distinguish slow-start and congestion avoidance phases.
o スロースタートしきい値（ssthresh、バイト単位）。これは、スロースタートと輻輳回避フェーズを区別するために送信者が使用します。
Note: This variable is maintained on a per-destination-address basis.
注：この変数は、宛先アドレスごとに維持されます。
SCTP also requires one additional control variable, partial_bytes_acked, which is used during congestion avoidance phase to facilitate cwnd adjustment.
SCTPには、1つの追加の制御変数partial_bytes_ackedも必要です。これは、輻輳回避フェーズ中にcwnd調整を容易にするために使用されます。
Unlike TCP, an SCTP sender MUST keep a set of these control variables cwnd, ssthresh, and partial_bytes_acked for EACH destination address of its peer (when its peer is multi-homed). Only one rwnd is kept for the whole association (no matter if the peer is multi-homed or has a single address).
TCPとは異なり、SCTP送信者は、ピアの各宛先アドレス（ピアがマルチホームの場合）に対して、これらの制御変数のセットcwnd、ssthresh、partial_bytes_ackedを保持する必要があります。アソシエーション全体で保持されるrwndは1つだけです（ピアがマルチホームであるか、単一のアドレスを持つかは関係ありません）。
Beginning data transmission into a network with unknown conditions or after a sufficiently long idle period requires SCTP to probe the network to determine the available capacity. The slow-start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer.
未知の条件でネットワークへのデータ送信を開始する場合、または十分に長いアイドル期間の後で、SCTPがネットワークをプローブして使用可能な容量を判断する必要があります。スロースタートアルゴリズムは、転送の開始時、または再送信タイマーによって検出された損失を修復した後に、この目的で使用されます。
o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o DATA送信前または十分に長いアイドル期間後の最初のcwndは、min（4 * MTU、max（2 * MTU、4380バイト））に設定する必要があります。
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU.
o 再送信タイムアウト後の最初のcwndは、1 * MTU以下でなければなりません。
o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window).
o ssthreshの初期値は、任意に高くすることができます（たとえば、実装では、レシーバーがアドバタイズしたウィンドウのサイズを使用できます）。
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address.
o cwndがゼロより大きい場合は常に、エンドポイントはそのトランスポートアドレスで未処理のデータのcwndバイトを持つことができます。
o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST use the slow-start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased; otherwise, the cwnd MUST not be increased. If these conditions are met, then cwnd MUST be increased by, at most, the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99].
o cwndがssthresh以下の場合、SCTPエンドポイントは、現在の輻輳ウィンドウが完全に利用されており、着信SACKが累積TSN Ackポイントを進め、データ送信者がそうでない場合にのみ、スロースタートアルゴリズムを使用してcwndを増やす必要があります。高速リカバリ。これらの3つの条件が満たされた場合にのみ、cwndを増やすことができます。それ以外の場合は、cwndを増やしてはなりません（MUST）。これらの条件が満たされている場合、cwndは、最大で、1）確認済みの以前の未処理のDATAチャンクの合計サイズ、および2）宛先のパスMTUの小さい方だけ増やす必要があります。この上限は、[SAVAGE99]で概説されているACK分割攻撃から保護します。
In instances where its peer endpoint is multi-homed, if an endpoint receives a SACK that advances its Cumulative TSN Ack Point, then it should update its cwnd (or cwnds) apportioned to the destination addresses to which it transmitted the acknowledged data. However, if the received SACK does not advance the Cumulative TSN Ack Point, the endpoint MUST NOT adjust the cwnd of any of the destination addresses.
ピアエンドポイントがマルチホームである場合、エンドポイントが累積TSN Ackポイントを進めるSACKを受信すると、確認済みデータを送信した宛先アドレスに割り当てられたcwnd（またはcwnds）を更新する必要があります。ただし、受信したSACKが累積TSN Ackポイントを進めない場合、エンドポイントは宛先アドレスのcwndを調整してはなりません（MUST NOT）。
Because an endpoint's cwnd is not tied to its Cumulative TSN Ack Point, as duplicate SACKs come in, even though they may not advance the Cumulative TSN Ack Point an endpoint can still use them to clock out new data. That is, the data newly acknowledged by the SACK diminishes the amount of data now in flight to less than cwnd, and so the current, unchanged value of cwnd now allows new data to be sent. On the other hand, the increase of cwnd must be tied to the Cumulative TSN Ack Point advancement as specified above. Otherwise, the duplicate SACKs will not only clock out new data, but also will adversely clock out more new data than what has just left the network, during a time of possible congestion.
エンドポイントのcwndは累積TSN Ackポイントに関連付けられていないため、SACKが重複すると、累積TSN Ackポイントを進めることができない場合でも、エンドポイントはそれらを使用して新しいデータをクロックアウトできます。つまり、SACKによって新たに確認応答されたデータにより、現在処理中のデータの量がcwnd未満に減少するため、現在の変更されていないcwndの値で新しいデータを送信できるようになります。一方、cwndの増加は、上で指定したように、累積TSN Ackポイントアドバンスに関連付けられている必要があります。そうでない場合、重複するSACKは新しいデータをクロックアウトするだけでなく、輻輳の可能性があるときに、ネットワークを離れたばかりのデータよりも多くの新しいデータを逆にクロックアウトします。
o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO.
o エンドポイントが特定のトランスポートアドレスでデータを送信しない場合、トランスポートアドレスのcwndをRTOごとにmax（cwnd / 2、4 * MTU）に調整する必要があります。
When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
cwndがssthreshより大きい場合、送信者が対応するトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、RTNごとに1 * MTUずつcwndをインクリメントする必要があります。
In practice, an implementation can achieve this goal in the following way:
実際には、実装は次の方法でこの目標を達成できます。
o partial_bytes_acked is initialized to 0.
o partial_bytes_ackedは0に初期化されます。
o Whenever cwnd is greater than ssthresh, upon each SACK arrival that advances the Cumulative TSN Ack Point, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK including chunks acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks.
o cwndがssthreshよりも大きい場合は常に、累積TSN Ackポイントを進める各SACKの到着時に、新しい累積TSN AckおよびギャップACKブロックによって確認されたチャンクを含む、そのSACKで確認されたすべての新しいチャンクの合計バイト数によって、partial_bytes_ackedを増やします。
o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd).
o partial_bytes_ackedがcwnd以上で、SACKの到着前に送信者が未処理のデータのcwnd以上のバイトを持っていた場合（つまり、SACKの到着前に、flightsizeがcwnd以上であった場合）、MTUによってcwndを増やします。そして、partial_bytes_ackedを（partial_bytes_acked-cwnd）にリセットします。
o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
o スロースタートと同様に、送信者が特定のトランスポートアドレスでDATAを送信しない場合、トランスポートアドレスのcwndをRTOごとにmax（cwnd / 2、4 * MTU）に調整する必要があります。
o When all of the data transmitted by the sender has been acknowledged by the receiver, partial_bytes_acked is initialized to 0.
o 送信側によって送信されたすべてのデータが受信側によって確認されると、partial_bytes_ackedは0に初期化されます。
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following:
SACKからのパケット損失を検出すると（セクション7.2.4を参照）、エンドポイントは以下を実行する必要があります。
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失によりcwndが半分にカットされます。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
T3-rtxタイマーがアドレスで期限切れになると、SCTPは次のようにスロースタートを実行する必要があります。
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
and ensure that no more than one SCTP packet will be in flight for that address until the endpoint receives acknowledgement for successful delivery of data to that address.
また、エンドポイントがそのアドレスへのデータの配信が成功したことの確認応答を受信するまで、そのアドレスに対して1つ以上のSCTPパケットが送信されないようにします。
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
データ損失がない場合、エンドポイントは確認応答の遅延を実行します。ただし、エンドポイントは、到着するTSNシーケンスのホールに気づくと、ホールが埋められるまで、データを運ぶパケットが到着するたびにSACKの送信を開始する必要があります（SHOULD）。
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for two further miss indications (via subsequent SACKs for a total of three missing reports) on the same TSNs before taking action with regard to Fast Retransmit.
エンドポイントは、一部のTSNが欠落していることを示すSACKを受信するたびに、高速再送信に関してアクションを実行する前に、同じTSNで（後続のSACKを介して、合計3つの欠落レポートがある）ミス表示を待つ必要があります。
Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK.
ミス表示は、HTNA（Highest TSN Newly Acknowledged）アルゴリズムに従う必要があります（SHOULD）。着信SACKごとに、SACKで新たに確認応答された最高のTSNの前に、欠落したTSNについてのみ、ミス表示が増分されます。新しく確認されたDATAチャンクは、以前にSACKで確認されていないものです。エンドポイントが高速復旧状態にあり、累積TSN Ackポイントを進めるSACKが到着した場合、SACKで欠落していると報告されたすべてのTSNのミス表示がインクリメントされます。
When the third consecutive miss indication is received for a TSN(s), the data sender shall do the following: 1) Mark the DATA chunk(s) with three miss indications for retransmission.
TSNに対して3回目の連続したミス表示が受信された場合、データ送信者は次のことを行う必要があります。1）再送信するために、DATAチャンクに3つのミス表示をマークします。
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2）高速リカバリでない場合は、セクション7.2.3で説明されている式に従って、欠落しているDATAチャンクが最後に送信された宛先アドレスのssthreshおよびcwndを調整します。
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3）パケットの送信先である宛先トランスポートアドレスのパスMTUの制約に従って、再送信のマークが付けられた最も早い（つまり、最も低いTSN）DATAチャンクが1つのパケットに収まる数を決定します。この値をKと呼びます。これらのK個のDATAチャンクを1つのパケットで再送信します。高速再送信が実行されている場合、送信者はcwndの値を無視する必要があり（SHOULD）、この単一パケットの再送信を遅延してはなりません（SHOULD NOT）。
4) Restart the T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4）最後のSACKがそのアドレスに送信された最小の未処理のTSN番号を確認した場合、またはエンドポイントがそのアドレスに送信された最初の未処理のDATAチャンクを再送信している場合にのみ、T3-rtxタイマーを再起動します。
5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent Fast Retransmit. Those TSNs marked for retransmission due to the Fast-Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent Fast Retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows.
5）DATAチャンクを高速再送信としてマークし、後続の高速再送信の対象外にします。高速再送信アルゴリズムが原因で再送信のマークが付けられたTSNは、K個の他のTSNを伝送する送信データグラムに適合しなかったため、後続の高速再送信の対象外としてマークされます。ただし、再送信のマークが付けられているため、cwndが許可するとすぐに再送信されます。
6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any destinations due to a subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further due to a subsequent Fast Retransmit).
6）高速リカバリーでない場合は、高速リカバリーを入力し、最高の未解決TSNを高速リカバリー出口点としてマークします。 SACKがこの出口ポイントまでのすべてのTSNを確認すると、高速リカバリが終了します。高速復旧中は、ssthreshとcwndは、後続の高速復旧イベントのために、どの宛先でも変更すべきではありません（つまり、後続の高速再送信により、cwndをさらに削減すべきではありません）。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Section 7.2.1 and Section 7.2.2 must be applied first.
注：上記の調整の前に、受信したSACKが新しいDATAチャンクも確認し、累積TSN Ackポイントを進める場合、セクション7.2.1およびセクション7.2.2で定義されたcwnd調整ルールを最初に適用する必要があります。
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 3 and starting the Fast-Retransmit procedure, the counter resets to 0.
上記の簡単な実装は、SACKによって報告された各TSNホールのカウンターを保持します。 TSNホールを報告する連続するSACKごとにカウンターが増加します。 3に達し、Fast-Retransmit手順を開始すると、カウンターは0にリセットされます。
Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP Fast Recovery is achieved automatically with no adjustment to the congestion control window size.
SCTPのcwndは、未解決のTSNの数を間接的に制限するため、輻輳制御ウィンドウサイズを調整せずに、TCP高速復旧の効果が自動的に実現されます。
[RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path MTU Discovery", whereby an endpoint maintains an estimate of the maximum transmission unit (MTU) along a given Internet path and refrains from sending packets along that path that exceed the MTU, other than occasional attempts to probe for a change in the Path MTU (PMTU). [RFC4821] is thorough in its discussion of the MTU discovery mechanism and strategies for determining the current end-to-end MTU setting as well as detecting changes in this value.
[RFC4821]、[RFC1981]、および[RFC1191]は、「パケット化レイヤーパスMTUディスカバリー」を指定します。これにより、エンドポイントは、特定のインターネットパスに沿った最大伝送ユニット（MTU）の推定値を維持し、パケットの送信を控えます。 パスMTU（PMTU）の変更をプローブしようとする場合を除いて、MTUを超えるパスに沿って。 [RFC4821]は、現在のエンドツーエンドのMTU設定を決定し、この値の変化を検出するためのMTU検出メカニズムと戦略について徹底的に説明しています。
An endpoint SHOULD apply these techniques, and SHOULD do so on a per-destination-address basis.
エンドポイントはこれらの手法を適用する必要があり（SHOULD）、宛先アドレスごとに適用する必要があります（SHOULD）。
There are two important SCTP-specific points regarding Path MTU discovery:
パスMTUディスカバリーに関して、2つの重要なSCTP固有のポイントがあります。
1) SCTP associations can span multiple addresses. An endpoint MUST maintain separate MTU estimates for each destination address of its peer.
1）SCTPアソシエーションは複数のアドレスにまたがることができます。エンドポイントは、ピアの宛先アドレスごとに個別のMTU見積もりを維持する必要があります。
2) The sender should track an association PMTU that will be the smallest PMTU discovered for all of the peer's destination addresses. When fragmenting messages into multiple parts this association PMTU should be used to calculate the size of each fragment. This will allow retransmissions to be seamlessly sent to an alternate address without encountering IP fragmentation.
2）送信者は、ピアのすべての宛先アドレスに対して検出された最小のPMTUであるアソシエーションPMTUを追跡する必要があります。メッセージを複数の部分にフラグメント化する場合、この関連付けPMTUを使用して、各フラグメントのサイズを計算する必要があります。これにより、IPの断片化に遭遇することなく、再送信をシームレスに代替アドレスに送信できます。
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint MAY report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
エンドポイントは、未確認のHEARTBEATチャンクを含む、ピアへの連続した再送信の総数（マルチホームの場合、ピアのすべての宛先トランスポートアドレスへの再送信を含む）のカウンターを保持する必要があります。 このカウンターの値がプロトコルパラメーター＆＃39; Association.Max.Retrans＆＃39;に示されている制限を超えると、エンドポイントはピアエンドポイントに到達できないと見なし、それ以上のデータの送信を停止します（したがって、関連付けは次のようになります。 CLOSED状態）。 さらに、エンドポイントは障害を上位層に報告し、オプションでアウトバウンドキューに残っているすべての未処理のユーザーデータを報告してもよい[MAY]。 ピアエンドポイントが到達不能になると、アソシエーションは自動的に閉じられます。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT ACK is received from the peer endpoint.
カウンターは、そのピアエンドポイントに送信されたDATAチャンクが（SACKの受信によって）確認されるか、ピアエンドポイントからHEARTBEAT ACKが受信されるたびにリセットされます。
When its peer endpoint is multi-homed, an endpoint should keep an error counter for each of the destination transport addresses of the peer endpoint.
ピアエンドポイントがマルチホームの場合、エンドポイントは、ピアエンドポイントの宛先トランスポートアドレスごとにエラーカウンターを保持する必要があります。
Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not acknowledged within an RTO, the error counter of that destination address will be incremented. When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that destination address, the endpoint should mark the destination transport address as inactive, and a notification SHOULD be sent to the upper layer.
いずれかのアドレスでT3-rtxタイマーが期限切れになるたび、またはアイドルアドレスに送信されたHEARTBEATがRTO内で確認応答されない場合、その宛先アドレスのエラーカウンターがインクリメントされます。 エラーカウンタの値がプロトコルパラメータ＆＃39; Path.Max.Retrans＆＃39;を超えた場合 その宛先アドレスのうち、エンドポイントは宛先トランスポートアドレスを非アクティブとしてマークする必要があり、通知を上位層に送信する必要があります。
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged with a HEARTBEAT ACK, the endpoint shall clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent). When the peer endpoint is multi-homed and the last chunk sent to it was a retransmission to an alternate address, there exists an ambiguity as to whether or not the acknowledgement should be credited to the address of the last chunk sent. However, this ambiguity does not seem to bear any significant consequence to SCTP behavior. If this ambiguity is undesirable, the transmitter may choose not to clear the error counter if the last chunk sent was a retransmission.
未解決のTSNが確認されるか、そのアドレスに送信されたHEARTBEATがHEARTBEAT ACKで確認されると、エンドポイントは、DATAチャンクが最後に送信された（またはHEARTBEATが送信された）宛先トランスポートアドレスのエラーカウンターをクリアします。ピアエンドポイントがマルチホームであり、最後に送信されたチャンクが代替アドレスへの再送信であった場合、最後に送信されたチャンクのアドレスに確認応答を送信する必要があるかどうかについて曖昧さが存在します。ただし、このあいまいさがSCTPの動作に重大な影響を与えることはないようです。このあいまいさが望ましくない場合、送信された最後のチャンクが再送信であった場合、トランスミッタはエラーカウンタをクリアしないことを選択できます。
Note: When configuring the SCTP endpoint, the user should avoid having the value of 'Association.Max.Retrans' larger than the summation of the 'Path.Max.Retrans' of all the destination addresses for the remote endpoint. Otherwise, all the destination addresses may become inactive while the endpoint still considers the peer endpoint reachable. When this condition occurs, how SCTP chooses to function is implementation specific.
注：SCTPエンドポイントを構成するとき、ユーザーは 'Association.Max.Retrans'の値がリモートエンドポイントのすべての宛先アドレスの 'Path.Max.Retrans'の合計よりも大きくなるのを避ける必要があります。そうでない場合、エンドポイントがピアエンドポイントに到達可能であると見なしている間、すべての宛先アドレスが非アクティブになる可能性があります。この状態が発生した場合、SCTPが機能する方法を選択する方法は、実装によって異なります。
When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender MAY automatically transmit new packets to an alternate destination address if one exists and is active. If more than one alternate address is active when the primary path is marked inactive, only ONE transport address SHOULD be chosen and used as the new destination transport address.
プライマリパスが非アクティブとマークされている場合（過度の再送信などにより）、送信者は、新しい宛先パケットが存在し、アクティブである場合、自動的に代替宛先アドレスに送信できます（MAY）。プライマリパスが非アクティブとしてマークされているときに複数の代替アドレスがアクティブである場合、1つのトランスポートアドレスのみを選択して、新しい宛先トランスポートアドレスとして使用する必要があります。
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
デフォルトでは、SCTPエンドポイントは、HEARTBEATチャンクを宛先トランスポートアドレスに定期的に送信することにより、ピアのアイドル宛先トランスポートアドレスの到達可能性を監視する必要があります（SHOULD）。 HEARTBEATの送信は、ESTABLISHED状態に達したときに開始される場合があり、SHUTDOWNまたはSHUTDOWN-ACKのいずれかを送信した後に中止されます。 HEARTBEATの受信者は、COOKIE-ECHOED状態（INIT送信側）またはESTABLISHED状態（INIT受信側）に入った後、SHUTDOWN-SENT状態（SHUTDOWN送信側）またはSHUTDOWNに到達するまで、HEARTBEAT-ACKでHEARTBEATに応答する必要があります。 -ACK-SENT状態（SHUTDOWNレシーバー）。
A destination transport address is considered "idle" if no new chunk that can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to both active and inactive destination addresses.
パスRTTの更新に使用できる新しいチャンク（通常、最初の送信DATA、INIT、COOKIE ECHO、HEARTBEATなどを含む）がなく、現在のハートビート内にHEARTBEATが送信されていない場合、宛先トランスポートアドレスは「アイドル」と見なされます。そのアドレスの期間。これは、アクティブと非アクティブの両方の宛先アドレスに適用されます。
The upper layer can optionally initiate the following functions:
上位層はオプションで次の機能を開始できます。
A) Disable heartbeat on a specific destination transport address of a given association,
A）特定の関連付けの特定の宛先トランスポートアドレスでハートビートを無効にします。
B) Change the HB.interval,
B）HB.intervalを変更し、
C) Re-enable heartbeat on a specific destination transport address of a given association, and
C）特定の関連付けの特定の宛先トランスポートアドレスでハートビートを再度有効にします。
D) Request an on-demand HEARTBEAT on a specific destination transport address of a given association.
D）特定の関連付けの特定の宛先トランスポートアドレスでオンデマンドのHEARTBEATを要求します。
The endpoint should increment the respective error counter of the destination transport address each time a HEARTBEAT is sent to that address and not acknowledged within one RTO.
エンドポイントは、HEARTBEATがそのアドレスに送信され、1つのRTO内で確認応答されないたびに、宛先トランスポートアドレスのそれぞれのエラーカウンターをインクリメントする必要があります。
When the value of this counter reaches the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
このカウンターの値がプロトコルパラメーター 'Path.Max.Retrans'に到達すると、エンドポイントは、対応する宛先アドレスにマークが付けられていない場合、非アクティブとしてマークする必要があります。宛先アドレス。この後、エンドポイントはこの宛先アドレスでHEARTBEATを続行する必要がありますが、カウンターの増加を停止する必要があります。
The sender of the HEARTBEAT chunk should include in the Heartbeat Information field of the chunk the current time when the packet is sent out and the destination address to which the packet is sent.
HEARTBEATチャンクの送信者は、パケットが送信される現在の時刻とパケットの送信先アドレスをチャンクのハートビート情報フィールドに含める必要があります。
IMPLEMENTATION NOTE: An alternative implementation of the heartbeat mechanism that can be used is to increment the error counter variable every time a HEARTBEAT is sent to a destination. Whenever a HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of the destination that the HEARTBEAT was sent to. This in effect would clear the previously stroked error (and any other error counts as well).
実装上の注意：ハートビートメカニズムの代替実装として、HEARTBEATが宛先に送信されるたびにエラーカウンター変数をインクリメントすることができます。 HEARTBEAT ACKが到着するたびに、送信者はHEARTBEATが送信された宛先のエラーカウンターをクリアする必要があります（SHOULD）。これにより、以前にストロークされたエラー（およびその他のエラーカウント）が実質的にクリアされます。
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk.
HEARTBEATの受信者は、ハートビート情報TLVと、受信したHEARTBEATチャンクから変更されずにコピーされた他の受信TLVを含むHEARTBEAT ACKですぐに応答する必要があります。
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the association overall error count as well (as defined in Section 8.1).
HEARTBEAT ACKを受信すると、HEARTBEATの送信者は、HEARTBEATが送信された宛先トランスポートアドレスのエラーカウンターをクリアし、マークされていない場合は宛先トランスポートアドレスをアクティブとしてマークする必要があります。最新のHEARTBEAT ACKを受信したために非アクティブな宛先アドレスがアクティブとしてマークされている場合、エンドポイントはオプションで上位層に報告する場合があります。 HEARTBEAT ACKの受信者は、アソシエーション全体のエラーカウントもクリアする必要があります（セクション8.1で定義）。
The receiver of the HEARTBEAT ACK should also perform an RTT measurement for that destination transport address using the time value carried in the HEARTBEAT ACK chunk.
HEARTBEAT ACKの受信側は、HEARTBEAT ACKチャンクで伝送される時間値を使用して、その宛先トランスポートアドレスのRTT測定も実行する必要があります。
On an idle destination address that is allowed to heartbeat, it is recommended that a HEARTBEAT chunk is sent once per RTO of that destination address plus the protocol parameter 'HB.interval', with jittering of +/- 50% of the RTO value, and exponential backoff of the RTO if the previous HEARTBEAT is unanswered.
ハートビートが許可されているアイドル宛先アドレスでは、その宛先アドレスのRTOごとにHEARTBEATチャンクとプロトコルパラメーター 'HB.interval'を1回送信し、RTO値の+/- 50％のジッターを設定することをお勧めします。以前のハートビートが未回答の場合は、RTOの指数バックオフ。
A primitive is provided for the SCTP user to change the HB.interval and turn on or off the heartbeat on a given destination address. The heartbeat interval set by the SCTP user is added to the RTO of that destination (including any exponential backoff). Only one heartbeat should be sent each time the heartbeat timer expires (if multiple destinations are idle). It is an implementation decision on how to choose which of the candidate idle destinations to heartbeat to (if more than one destination is idle).
SCTPユーザーがプリミティブを使用して、HB.intervalを変更し、特定の宛先アドレスでハートビートをオンまたはオフにすることができます。 SCTPユーザーが設定したハートビート間隔は、その宛先のRTO（指数バックオフを含む）に追加されます。ハートビートタイマーが期限切れになるたびに1つのハートビートのみを送信する必要があります（複数の宛先がアイドル状態の場合）。これは、ハートビートの候補となるアイドル宛先の選択方法に関する実装の決定です（複数の宛先がアイドルの場合）。
Note: When tuning the heartbeat interval, there is a side effect that SHOULD be taken into account. When this value is increased, i.e., the HEARTBEAT takes longer, the detection of lost ABORT messages takes longer as well. If a peer endpoint ABORTs the association for any reason and the ABORT chunk is lost, the local endpoint will only discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT). This must be considered when tuning the HEARTBEAT timer. If the HEARTBEAT is disabled, only sending DATA to the association will discover a lost ABORT from the peer.
注：ハートビート間隔を調整するときは、考慮すべき副作用があります。この値を大きくすると、つまりHEARTBEATの時間が長くなると、失われたABORTメッセージの検出にも時間がかかります。ピアエンドポイントが何らかの理由でアソシエーションをABORTし、ABORTチャンクが失われた場合、ローカルエンドポイントは、DATAチャンクまたはHEARTBEATチャンクを送信することによって失われたABORTのみを検出します（したがって、ピアは別のABORTを送信します）。これは、ハートビートタイマーを調整するときに考慮する必要があります。 HEARTBEATが無効になっている場合、関連付けにDATAを送信するだけで、ピアから失われたABORTが検出されます。
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
SCTPパケットは、正しく形成されている場合（つまり、レシーバーのCRC32cチェックに合格した場合、セクション6.8を参照）、「out of the blue」（OOTB）パケットと呼ばれますが、レシーバーはこのパケットが属するアソシエーションを識別できません。 。
The receiver of an OOTB packet MUST do the following:
OOTBパケットの受信者は、以下を実行する必要があります。
1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
1）OOTBパケットが非ユニキャストアドレスとの間で送受信される場合、受信者はパケットをサイレントに破棄する必要があります（SHOULD）。さもないと、
2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise,
2）OOTBパケットにABORTチャンクが含まれている場合、受信者はOOTBパケットを静かに破棄し、それ以上のアクションを実行してはなりません（MUST）。さもないと、
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate Tag of the received INIT chunk, and the T bit of the ABORT chunk has to be set to 0, indicating that the Verification Tag is NOT reflected.
3）パケットに検証タグが「0」に設定されたINITチャンクが含まれている場合は、セクション5.1の説明に従って処理します。何らかの理由でINITを正常に処理できず、ABORTを応答として送信する必要がある場合、ABORTチャンクを含むパケットの検証タグは、受信したINITチャンクの開始タグと、ABORTのTビットでなければなりません（MUST）。チャンクは0に設定する必要があり、検証タグが反映されないことを示します。
4) If the packet contains a COOKIE ECHO in the first chunk, process it as described in Section 5.1. Otherwise,
4）パケットの最初のチャンクにCOOKIE ECHOが含まれている場合は、セクション5.1の説明に従って処理します。さもないと、
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. Otherwise,
5）パケットにSHUTDOWN ACKチャンクが含まれている場合、受信者はOOTBパケットの送信者にSHUTDOWNCOMPLETEで応答する必要があります。 SHUTDOWN COMPLETEを送信する場合、OOTBパケットの受信者は、SHUTDOWN ACKで受信した検証タグをアウトバウンドパケットの検証タグフィールドに入力し、チャンクフラグのTビットを設定して検証タグが反映されていることを示す必要があります。 さもないと、
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver should silently discard the packet and take no further action. Otherwise,
6）パケットにSHUTDOWN COMPLETEチャンクが含まれている場合、受信側は黙ってパケットを破棄し、それ以上のアクションは行わないでください。さもないと、
7) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the SCTP packet should be silently discarded. Otherwise,
7）パケットに「Stale Cookie」エラーまたはCOOKIE ACKが含まれている場合、SCTPパケットは通知なく破棄されます。さもないと、
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8）受信者は、OOTBパケットの送信者にABORTで応答する必要があります。 ABORTを送信するとき、OOTBパケットの受信者は、送信パケットの検証タグフィールドにOOTBパケットの検証タグフィールドにある値を入力し、チャンクフラグのTビットを設定して、検証タグが反射してる。このABORTを送信した後、OOTBパケットの受信者はOOTBパケットを破棄し、それ以上のアクションは行いません。
The Verification Tag rules defined in this section apply when sending or receiving SCTP packets that do not contain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO (see Section 5.1), ABORT, or SHUTDOWN ACK chunk. The rules for sending and receiving SCTP packets containing one of these chunk types are discussed separately in Section 8.5.1.
このセクションで定義されている検証タグルールは、INIT、SHUTDOWN COMPLETE、COOKIE ECHO（セクション5.1を参照）、ABORT、またはSHUTDOWN ACKチャンクを含まないSCTPパケットを送受信するときに適用されます。これらのチャンクタイプの1つを含むSCTPパケットを送受信するためのルールについては、セクション8.5.1で個別に説明します。
When sending an SCTP packet, the endpoint MUST fill in the Verification Tag field of the outbound packet with the tag value in the Initiate Tag parameter of the INIT or INIT ACK received from its peer.
SCTPパケットを送信するとき、エンドポイントは、発信パケットの検証タグフィールドに、ピアから受信したINITまたはINIT ACKのInitiate Tagパラメータのタグ値を入力する必要があります。
When receiving an SCTP packet, the endpoint MUST ensure that the value in the Verification Tag field of the received SCTP packet matches its own tag. If the received Verification Tag value does not match the receiver's own tag value, the receiver shall silently discard the packet and shall not process it any further except for those cases listed in Section 8.5.1 below.
SCTPパケットを受信するとき、エンドポイントは、受信したSCTPパケットの検証タグフィールドの値が自身のタグと一致することを確認する必要があります。受信した検証タグ値が受信者自身のタグ値と一致しない場合、受信者はパケットを黙って破棄し、以下のセクション8.5.1にリストされている場合を除いてそれ以上処理しないものとします。
A) Rules for packet carrying INIT:
A）INITを運ぶパケットの規則：
- The sender MUST set the Verification Tag of the packet to 0.
- 送信者は、パケットの検証タグを0に設定する必要があります。
- When an endpoint receives an SCTP packet with the Verification Tag set to 0, it should verify that the packet contains only an INIT chunk. Otherwise, the receiver MUST silently discard the packet.
- エンドポイントは、検証タグが0に設定されたSCTPパケットを受信すると、パケットにINITチャンクのみが含まれていることを確認する必要があります。それ以外の場合、受信者はパケットを静かに破棄する必要があります。
B) Rules for packet carrying ABORT:
B）ABORTを運ぶパケットのルール：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- エンドポイントは、既知の場合、常に送信パケットの検証タグフィールドに宛先エンドポイントのタグ値を入力する必要があります。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- ABORTがOOTBパケットに応答して送信される場合、エンドポイントはセクション8.4で説明されている手順に従う必要があります。
- The receiver of an ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- ABORTの受信者は、パケットの検証タグフィールドが自身のタグと一致し、Tビットが設定されていない場合、またはピアのタグに設定されていて、チャンクフラグでTビットが設定されている場合、パケットを受け入れる必要があります。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを行わない必要があります。
C) Rules for packet carrying SHUTDOWN COMPLETE:
C）シャットダウンを完了するパケットのルール：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB, then the destination endpoint's tag MUST be used, and the T bit MUST NOT be set. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK, and MUST set the T bit.
- SHUTDOWN COMPLETEを送信するとき、SHUTDOWN ACKの受信側にTCBがある場合、宛先エンドポイントのタグを使用する必要があり、Tビットを設定してはなりません（MUST NOT）。 TCBが存在しない場合にのみ、送信者はSHUTDOWN ACKからの検証タグを使用し、Tビットを設定する必要があります。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- SHUTDOWN COMPLETEの受信者は、パケットの検証タグフィールドが自身のタグと一致し、Tビットが設定されていない場合、またはピアのタグに設定されており、Tビットがチャンクフラグに設定されている場合、パケットを受け入れます。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを行わない必要があります。エンドポイントがSHUTDOWN-ACK-SENT状態でない場合、エンドポイントはSHUTDOWN COMPLETEを無視する必要があります。
D) Rules for packet carrying a COOKIE ECHO
D）COOKIE ECHOを運ぶパケットのルール
- When sending a COOKIE ECHO, the endpoint MUST use the value of the Initiate Tag received in the INIT ACK.
- COOKIE ECHOを送信する場合、エンドポイントはINIT ACKで受信した開始タグの値を使用する必要があります。
- The receiver of a COOKIE ECHO follows the procedures in Section 5.
- COOKIE ECHOの受信者は、セクション5の手順に従います。
E) Rules for packet carrying a SHUTDOWN ACK
E）SHUTDOWN ACKを運ぶパケットのルール
- If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the procedures in Section 8.4 SHOULD be followed; in other words, it should be treated as an Out Of The Blue packet.
- 受信者がCOOKIE-ECHOEDまたはCOOKIE-WAIT状態の場合は、8.4節の手順に従う必要があります。言い換えれば、それはOut of the Blueパケットとして扱われるべきです。
An endpoint should terminate its association when it exits from service. An association can be terminated by either abort or shutdown. An abort of an association is abortive by definition in that any data pending on either end of the association is discarded and not delivered to the peer. A shutdown of an association is considered a graceful close where all data in queue by either endpoint is delivered to the respective peers. However, in the case of a shutdown, SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of sending or receiving the SHUTDOWN chunk.
エンドポイントは、サービスを終了するときにその関連付けを終了する必要があります。アソシエーションは、中止またはシャットダウンによって終了できます。アソシエーションのアボートは、アソシエーションの両端で保留中のデータが破棄され、ピアに配信されないという意味で、アボートです。アソシエーションのシャットダウンは、いずれかのエンドポイントによってキュー内のすべてのデータがそれぞれのピアに配信される適切なクローズと見なされます。ただし、シャットダウンの場合、SCTPはハーフオープン状態（TCPなど）をサポートしません。一方の側では、もう一方の端が閉じている間もデータを送信し続けることができます。どちらかのエンドポイントがシャットダウンを実行すると、各ピアの関連付けはユーザーからの新しいデータの受け入れを停止し、SHUTDOWNチャンクの送信または受信時にキュー内のデータのみを配信します。
When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see Section 3.3.10.12) SHOULD be present in the ABORT chunk.
エンドポイントが既存のアソシエーションを中止することを決定した場合、そのエンドポイントにABORTチャンクを送信する必要があります。送信者は、発信パケットにピアの検証タグを入力する必要があり、データチャンクをABORTにバンドルしてはなりません。上位層の要求により関連付けが中止された場合、ユーザー開始の中止エラーの原因（セクション3.3.10.12を参照）は、ABORTチャンクに存在する必要があります（SHOULD）。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
エンドポイントは、ABORTチャンクを含む受信パケットに応答してはなりません（MUST 8.4も参照）。
An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1.
ABORTを受信するエンドポイントは、セクション8.5.1で説明されている特別な検証タグチェックルールを適用する必要があります。
After checking the Verification Tag, the receiving endpoint MUST remove the association from its record and SHOULD report the termination to its upper layer. If a User-Initiated Abort error cause is present in the ABORT chunk, the Upper Layer Abort Reason SHOULD be made available to the upper layer.
検証タグをチェックした後、受信側エンドポイントはその関連付けをレコードから削除する必要があり、その上位層に終了を報告する必要があります（SHOULD）。ユーザーが開始した中止エラーの原因がABORTチャンクに存在する場合、上位層の中止理由は、上位層で利用可能にする必要があります（SHOULD）。
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an endpoint in an association can gracefully close the association. This will allow all outstanding DATA chunks from the peer of the shutdown initiator to be delivered before the association terminates.
SHUTDOWNプリミティブ（セクション10.1を参照）を使用して、アソシエーションのエンドポイントの上位層は、アソシエーションを適切に閉じることができます。これにより、関連付けが終了する前に、シャットダウンイニシエーターのピアからのすべての未処理のDATAチャンクを配信できます。
Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters the SHUTDOWN-PENDING state and remains there until all outstanding data has been acknowledged by its peer. The endpoint accepts no new data from its upper layer, but retransmits data to the far end if necessary to fill gaps.
上位層からSHUTDOWNプリミティブを受信すると、エンドポイントはSHUTDOWN-PENDING状態になり、すべての未処理のデータがピアによって確認されるまでそこに留まります。エンドポイントは、上位層から新しいデータを受け入れませんが、ギャップを埋めるために必要な場合は、データを遠端に再送信します。
Once all its outstanding data has been acknowledged, the endpoint shall send a SHUTDOWN chunk to its peer including in the Cumulative TSN Ack field the last sequential TSN it has received from the peer. It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN with the updated last sequential TSN received from its peer.
すべての未処理のデータが確認されると、エンドポイントはピアからSHUTDOWNチャンクを送信し、ピアから受信した最後の順次TSNを累積TSN Ackフィールドに含めます。次に、T2シャットダウンタイマーを開始し、SHUTDOWN-SENT状態に入ります。タイマーの期限が切れた場合、エンドポイントは、ピアから受信した更新された最後の順次TSNを使用してSHUTDOWNを再送信する必要があります。
The rules in Section 6.3 MUST be followed to determine the proper timer value for T2-shutdown. To indicate any gaps in TSN, the endpoint may also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet.
T2シャットダウンの適切なタイマー値を決定するには、セクション6.3のルールに従う必要があります。 TSNのギャップを示すために、エンドポイントは同じSCTPパケット内のSHUTDOWNチャンクとSACKをバンドルすることもできます。
An endpoint should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and MUST report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state). The reception of any packet from its peer (i.e., as the peer sends all of its queued DATA chunks) should clear the endpoint's retransmission count and restart the T2-shutdown timer, giving its peer ample opportunity to transmit all of its queued DATA chunks that have not yet been sent.
エンドポイントは、SHUTDOWNチャンクの再送信の数をプロトコルパラメーター 'Association.Max.Retrans'に制限する必要があります。このしきい値を超える場合、エンドポイントはTCBを破棄し、到達できないピアエンドポイントを上位層に報告する必要があります（したがって、関連付けはCLOSED状態になります）。ピアからのパケットの受信（つまり、ピアがキューに入れられたDATAチャンクのすべてを送信するとき）は、エンドポイントの再送信カウントをクリアし、T2シャットダウンタイマーを再起動して、ピアがキューに入れられたすべてのDATAチャンクを送信する十分な機会を与える必要がありますまだ送信されていません。
Upon reception of the SHUTDOWN, the peer endpoint shall
SHUTDOWNを受信すると、ピアエンドポイントは、
- enter the SHUTDOWN-RECEIVED state,
- SHUTDOWN-RECEIVED状態に入る
- stop accepting new data from its SCTP user, and
- SCTPユーザーからの新しいデータの受け入れを停止し、
- verify, by checking the Cumulative TSN Ack field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN sender.
- チャンクの累積TSN Ackフィールドをチェックして、そのすべての未処理のDATAチャンクがSHUTDOWN送信側によって受信されたことを確認します。
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
エンドポイントがSHUTDOWN-RECEIVED状態に到達すると、ULP要求に応答してSHUTDOWNを送信してはならず（MUST）、後続のSHUTDOWNチャンクを破棄する必要があります。
If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
未処理のDATAチャンクがまだ残っている場合、SHUTDOWNレシーバーは、すべての未処理のDATAチャンクが確認されるまで、セクション6で定義されている通常のデータ送信手順に従い続ける必要があります。 ただし、SHUTDOWNレシーバーは、SCTPユーザーからの新しいデータを受け入れてはなりません（MUSTNOT）。
While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent.
SHUTDOWN-SENT状態にある間、SHUTDOWN送信側は、1つ以上のDATAチャンクを含む各受信パケットにSHUTDOWNチャンクで即座に応答し、T2シャットダウンタイマーを再起動する必要があります。 SHUTDOWNチャンク自体が受信したDATAチャンクのすべてを確認できない場合（つまり、確認できるTSNが累積TSNより大きく、したがってTSNシーケンスにギャップがある場合）、または重複したTSNが受信された場合、次に、SACKチャンクも送信する必要があります。
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for the shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
SHUTDOWNの送信側は、全体的なガードタイマー「T5-shutdown-guard」を開始して、シャットダウンシーケンスの全体的な時間を制限する場合があります。このタイマーの満了時に、送信者はABORTチャンクを送信することで関連付けを中止する必要があります（SHOULD）。 「T5-shutdown-guard」タイマーを使用する場合は、「RTO.Max」の5倍の推奨値に設定する必要があります。
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2- shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN ACK.
SHUTDOWNのレシーバーに未処理のDATAチャンクがなくなった場合、SHUTDOWNレシーバーはSHUTDOWN ACKを送信し、独自のT2シャットダウンタイマーを開始して、SHUTDOWN-ACK-SENT状態に入る必要があります。タイマーの期限が切れた場合、エンドポイントはSHUTDOWN ACKを再送信する必要があります。
The sender of the SHUTDOWN ACK should limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and may report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
SHUTDOWN ACKの送信者は、SHUTDOWN ACKチャンクの再送信数をプロトコルパラメータ「Association.Max.Retrans」に制限する必要があります。このしきい値を超えると、エンドポイントはTCBを破棄し、到達できないピアエンドポイントを上位層に報告する可能性があります（したがって、関連付けはCLOSED状態になります）。
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, and remove all record of the association.
SHUTDOWN ACKを受信すると、SHUTDOWN送信側はT2シャットダウンタイマーを停止し、SHUTDOWN COMPLETEチャンクをピアに送信し、関連付けのすべてのレコードを削除します。
Upon reception of the SHUTDOWN COMPLETE chunk, the endpoint will verify that it is in the SHUTDOWN-ACK-SENT state; if it is not, the chunk should be discarded. If the endpoint is in the SHUTDOWN-ACK-SENT state, the endpoint should stop the T2-shutdown timer and remove all knowledge of the association (and thus the association enters the CLOSED state).
エンドポイントは、SHUTDOWN COMPLETEチャンクを受信すると、それがSHUTDOWN-ACK-SENT状態であることを確認します。そうでない場合は、チャンクを破棄する必要があります。エンドポイントがSHUTDOWN-ACK-SENT状態にある場合、エンドポイントはT2シャットダウンタイマーを停止し、関連付けに関するすべての情報を削除する必要があります（したがって、関連付けはCLOSED状態になります）。
An endpoint SHOULD ensure that all its outstanding DATA chunks have been acknowledged before initiating the shutdown procedure.
エンドポイントは、シャットダウン手順を開始する前に、すべての未処理のDATAチャンクが確認されていることを確認する必要があります（SHOULD）。
An endpoint should reject any new data request from its upper layer if it is in the SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENT state.
エンドポイントは、SHUTDOWN-PENDING、SHUTDOWN-SENT、SHUTDOWN-RECEIVED、またはSHUTDOWN-ACK-SENT状態の場合、上位層からの新しいデータ要求を拒否する必要があります。
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination transport addresses (either in the IP addresses or in the INIT chunk) that belong to this association, it should discard the INIT chunk and retransmit the SHUTDOWN ACK chunk.
エンドポイントがSHUTDOWN-ACK-SENT状態にあり、この関連付けに属するソースおよび宛先トランスポートアドレス（IPアドレスまたはINITチャンクのいずれか）を含むINITチャンクを受信した場合（たとえば、SHUTDOWN COMPLETEが失われた場合） 、INITチャンクを破棄し、SHUTDOWN ACKチャンクを再送信する必要があります。
Note: Receipt of an INIT with the same source and destination IP addresses as used in transport addresses assigned to an endpoint but with a different port number indicates the initialization of a separate association.
注：送信元IPアドレスと宛先IPアドレスがエンドポイントに割り当てられているトランスポートアドレスと同じで、ポート番号が異なるINITを受信すると、別の関連付けが初期化されたことを示します。
The sender of the INIT or COOKIE ECHO should respond to the receipt of a SHUTDOWN ACK with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the Verification Tag field of its common header set to the same tag that was received in the SHUTDOWN ACK packet. This is considered an Out of the Blue packet as defined in Section 8.4. The sender of the INIT lets T1-init continue running and remains in the COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration will cause the INIT or COOKIE chunk to be retransmitted and thus start a new association.
INITまたはCOOKIEECHOの送信者は、共通ヘッダーの検証タグフィールドがSHUTDOWN ACKパケットで受信されたのと同じタグに設定された、SCTPパケット内のスタンドアロンSHUTDOWNCOMPLETEでSHUTDOWNACKの受信に応答する必要があります。 。 これは、セクション8.4で定義されているように、Out of theBlueパケットと見なされます。 INITの送信者は、T1-initの実行を継続し、COOKIE-WAITまたはCOOKIE-ECHOED状態のままにします。 通常のT1-initタイマーの有効期限が切れると、INITまたはCOOKIEチャンクが再送信され、新しい関連付けが開始されます。
If a SHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state, the SHUTDOWN chunk SHOULD be silently discarded.
SHUTDOWNがCOOKIE-WAITまたはCOOKIE ECHOED状態で受信された場合、SHUTDOWNチャンクは通知なく破棄される必要があります（SHOULD）。
If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN chunk from its peer, the endpoint shall respond immediately with a SHUTDOWN ACK to its peer, and move into the SHUTDOWN-ACK-SENT state restarting its T2-shutdown timer.
エンドポイントがSHUTDOWN-SENT状態にあり、ピアからSHUTDOWNチャンクを受信した場合、エンドポイントはピアにSHUTDOWN ACKで即座に応答し、SHUTDOWN-ACK-SENT状態に移行してT2シャットダウンタイマーを再開します。
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, and remove all record of the association.
エンドポイントがSHUTDOWN-ACK-SENT状態にあり、SHUTDOWN ACKを受信した場合、エンドポイントはT2シャットダウンタイマーを停止し、SHUTDOWN COMPLETEチャンクをピアに送信し、関連付けのすべてのレコードを削除します。
The Upper Layer Protocols (ULPs) shall request services by passing primitives to SCTP and shall receive notifications from SCTP for various events.
上位層プロトコル（ULP）は、プリミティブをSCTPに渡すことによってサービスを要求し、さまざまなイベントの通知をSCTPから受信します。
The primitives and notifications described in this section should be used as a guideline for implementing SCTP. The following functional description of ULP interface primitives is shown for illustrative purposes. Different SCTP implementations may have different ULP interfaces. However, all SCTPs must provide a certain minimum set of services to guarantee that all SCTP implementations can support the same protocol hierarchy.
このセクションで説明するプリミティブと通知は、SCTPを実装するためのガイドラインとして使用する必要があります。以下のULPインターフェイスプリミティブの機能説明は、説明のために示しています。 SCTP実装が異なると、ULPインターフェースも異なる場合があります。ただし、すべてのSCTP実装が同じプロトコル階層をサポートできることを保証するために、すべてのSCTPは特定の最小サービスセットを提供する必要があります。
The following sections functionally characterize a ULP/SCTP interface. The notation used is similar to most procedure or function calls in high-level languages.
以下のセクションでは、ULP / SCTPインターフェイスを機能的に特徴付けます。使用される表記法は、高水準言語でのほとんどのプロシージャーまたは関数呼び出しに似ています。
The ULP primitives described below specify the basic functions that SCTP must perform to support inter-process communication. Individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls.
以下で説明するULPプリミティブは、プロセス間通信をサポートするためにSCTPが実行する必要がある基本機能を指定します。個々の実装は、独自の正確なフォーマットを定義する必要があり、単一の呼び出しで基本関数の組み合わせまたはサブセットを提供する場合があります。
A) Initialize
A）初期化
Format: INITIALIZE ([local port],[local eligible address list])-> local SCTP instance name
形式：INITIALIZE（[ローカルポート]、[ローカル適格アドレスリスト]）->ローカルSCTPインスタンス名
This primitive allows SCTP to initialize its internal data structures and allocate necessary resources for setting up its operation environment. Once SCTP is initialized, ULP can communicate directly with other endpoints without re-invoking this primitive.
このプリミティブにより、SCTPは内部データ構造を初期化し、動作環境をセットアップするために必要なリソースを割り当てることができます。 SCTPが初期化されると、ULPはこのプリミティブを再度呼び出すことなく、他のエンドポイントと直接通信できます。
SCTP will return a local SCTP instance name to the ULP.
SCTPはローカルSCTPインスタンス名をULPに返します。
Mandatory attributes:
必須の属性：
None.
なし。
Optional attributes:
オプションの属性：
The following types of attributes may be passed along with the primitive:
次のタイプの属性をプリミティブとともに渡すことができます。
o local port - SCTP port number, if ULP wants it to be specified.
o ローカルポート-ULPで指定する場合は、SCTPポート番号。
o local eligible address list - an address list that the local SCTP endpoint should bind. By default, if an address list is not included, all IP addresses assigned to the host should be used by the local endpoint.
o ローカル適格アドレスリスト-ローカルSCTPエンドポイントがバインドする必要があるアドレスリスト。デフォルトでは、アドレスリストが含まれていない場合、ホストに割り当てられているすべてのIPアドレスをローカルエンドポイントで使用する必要があります。
IMPLEMENTATION NOTE: If this optional attribute is supported by an implementation, it will be the responsibility of the implementation to enforce that the IP source address field of any SCTP packets sent out by this endpoint contains one of the IP addresses indicated in the local eligible address list.
実装に関する注：このオプションの属性が実装でサポートされている場合、このエンドポイントによって送信されるSCTPパケットのIP送信元アドレスフィールドに、ローカルの適格アドレスで示されるIPアドレスの1つが含まれるように強制するのは、実装の責任です。リスト。
B) Associate
B）アソシエイト
Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]
形式：ASSOCIATE（ローカルSCTPインスタンス名、宛先トランスポートアドレス、送信ストリーム数）->アソシエーションID [、宛先トランスポートアドレスリスト] [、送信ストリーム数]
This primitive allows the upper layer to initiate an association to a specific peer endpoint.
このプリミティブにより、上位層は特定のピアエンドポイントへの関連付けを開始できます。
The peer endpoint shall be specified by one of the transport addresses that defines the endpoint (see Section 1.3). If the local SCTP instance has not been initialized, the ASSOCIATE is considered an error.
ピアエンドポイントは、エンドポイントを定義するトランスポートアドレスの1つによって指定される必要があります（セクション1.3を参照）。 ローカルSCTPインスタンスが初期化されていない場合、ASSOCIATEはエラーと見なされます。
An association id, which is a local handle to the SCTP association, will be returned on successful establishment of the association. If SCTP is not able to open an SCTP association with the peer endpoint, an error is returned.
アソシエーションの確立に成功すると、SCTPアソシエーションへのローカルハンドルであるアソシエーションIDが返されます。 SCTPがピアエンドポイントとのSCTPアソシエーションを開くことができない場合、エラーが返されます。
Other association parameters may be returned, including the complete destination transport addresses of the peer as well as the outbound stream count of the local endpoint. One of the transport addresses from the returned destination addresses will be selected by the local endpoint as default primary path for sending SCTP packets to this peer. The returned "destination transport addr list" can be used by the ULP to change the default primary path or to force sending a packet to a specific transport address.
ピアの完全な宛先トランスポートアドレスやローカルエンドポイントのアウトバウンドストリーム数など、他の関連付けパラメーターが返される場合があります。返された宛先アドレスからのトランスポートアドレスの1つは、ローカルエンドポイントによって、このピアにSCTPパケットを送信するためのデフォルトのプライマリパスとして選択されます。返された "destination transport addr list"は、ULPがデフォルトのプライマリパスを変更したり、特定のトランスポートアドレスにパケットを強制的に送信したりするために使用できます。
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a blocking function call, the ASSOCIATE primitive can return association parameters in addition to the association id upon successful establishment. If ASSOCIATE primitive is implemented as a non-blocking call, only the association id shall be returned and association parameters shall be passed using the COMMUNICATION UP notification.
実装上の注意：ASSOCIATEプリミティブがブロッキング関数呼び出しとして実装されている場合、ASSOCIATEプリミティブは、正常に確立されると、関連付けIDに加えて関連付けパラメーターを返すことができます。 ASSOCIATEプリミティブが非ブロッキング呼び出しとして実装されている場合、関連付けIDのみが返され、関連付けパラメータはCOMMUNICATION UP通知を使用して渡されます。
Mandatory attributes:
必須の属性：
o local SCTP instance name - obtained from the INITIALIZE operation.
o ローカルSCTPインスタンス名-INITIALIZE操作から取得されます。
o destination transport addr - specified as one of the transport addresses of the peer endpoint with which the association is to be established.
o 宛先トランスポートアドレス-関連付けが確立されるピアエンドポイントのトランスポートアドレスの1つとして指定されます。
o outbound stream count - the number of outbound streams the ULP would like to open towards this peer endpoint.
o アウトバウンドストリーム数-ULPがこのピアエンドポイントに向けてオープンするアウトバウンドストリームの数。
Optional attributes:
オプションの属性：
None.
なし。
C) Shutdown
C）シャットダウン
Format: SHUTDOWN(association id) -> result
形式：SHUTDOWN（関連付けID）->結果
Gracefully closes an association. Any locally queued user data will be delivered to the peer. The association will be terminated only after the peer acknowledges all the SCTP packets sent. A success code will be returned on successful termination of the association. If attempting to terminate the association results in a failure, an error code shall be returned.
関連付けを正常に閉じます。ローカルでキューに入れられたユーザーデータはすべてピアに配信されます。アソシエーションは、ピアが送信されたすべてのSCTPパケットを確認した後にのみ終了します。関連付けが正常に終了すると、成功コードが返されます。アソシエーションを終了しようとすると失敗した場合は、エラーコードが返されます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
Optional attributes:
オプションの属性：
None.
なし。
D) Abort
D）中絶
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Ungracefully closes an association. Any locally queued user data will be discarded, and an ABORT chunk is sent to the peer. A success code will be returned on successful abort of the association. If attempting to abort the association results in a failure, an error code shall be returned.
関連付けを不適切に閉じます。ローカルでキューに入れられたユーザーデータはすべて破棄され、ABORTチャンクがピアに送信されます。関連付けが正常に中止されると、成功コードが返されます。関連付けを中止しようとすると失敗した場合は、エラーコードが返されます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
Optional attributes:
オプションの属性：
o Upper Layer Abort Reason - reason of the abort to be passed to the peer.
o 上位層の中止理由-中止がピアに渡される理由。
None.
なし。
E) Send
E）送信
Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) -> result
形式：SEND（関連付けID、バッファアドレス、バイトカウント[、コンテキスト] [、ストリームID] [、ライフタイム] [、宛先トランスポートアドレス] [、順序付けられていないフラグ] [、バンドルなしフラグ] [、ペイロードプロトコルID ]）->結果
This is the main method to send user data via SCTP.
これは、SCTPを介してユーザーデータを送信する主な方法です。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o buffer address - the location where the user message to be transmitted is stored.
o バッファアドレス-送信されるユーザーメッセージが格納される場所。
o byte count - the size of the user data in number of bytes.
o バイトカウント-バイト数で表したユーザーデータのサイズ。
Optional attributes:
オプションの属性：
o context - an optional 32-bit integer that will be carried in the sending failure notification to the ULP if the transportation of this user message fails.
o context-オプションの32ビット整数。このユーザーメッセージの転送が失敗した場合、ULPへの送信失敗通知で伝達されます。
o stream id - to indicate which stream to send the data on. If not specified, stream 0 will be used.
o ストリームID-データを送信するストリームを示します。指定しない場合、ストリーム0が使用されます。
o life time - specifies the life time of the user data. The user data will not be sent by SCTP after the life time expires. This parameter can be used to avoid efforts to transmit stale user messages. SCTP notifies the ULP if the data cannot be initiated to transport (i.e., sent to the destination via SCTP's send primitive) within the life time variable. However, the user data will be transmitted if SCTP has attempted to transmit a chunk before the life time expired.
o ライフタイム-ユーザーデータのライフタイムを指定します。有効期限が切れた後、ユーザーデータはSCTPによって送信されません。このパラメーターを使用すると、古いユーザーメッセージを送信する手間を省くことができます。 SCTPは、ライフタイム変数内でデータのトランスポートを開始できない（SCTPの送信プリミティブを介して宛先に送信できない）場合、ULPに通知します。ただし、有効期限が切れる前にSCTPがチャンクを送信しようとした場合、ユーザーデータは送信されます。
IMPLEMENTATION NOTE: In order to better support the data life time option, the transmitter may hold back the assigning of the TSN number to an outbound DATA chunk to the last moment. And, for implementation simplicity, once a TSN number has been assigned the sender should consider the send of this DATA chunk as committed, overriding any life time option attached to the DATA chunk.
実装上の注意：データライフタイムオプションをより適切にサポートするために、トランスミッターは、送信DATAチャンクへのTSN番号の割り当てを最後まで保留する場合があります。また、実装を簡単にするために、TSN番号が割り当てられると、送信者はこのDATAチャンクの送信をコミット済みと見なし、DATAチャンクに添付されているライフタイムオプションをオーバーライドする必要があります。
o destination transport address - specified as one of the destination transport addresses of the peer endpoint to which this packet should be sent. Whenever possible, SCTP should use this destination transport address for sending the packets, instead of the current primary path.
o 宛先トランスポートアドレス-このパケットの送信先となるピアエンドポイントの宛先トランスポートアドレスの1つとして指定されます。 SCTPは、可能な限り、現在のプライマリパスではなく、この宛先トランスポートアドレスを使用してパケットを送信する必要があります。
o unordered flag - this flag, if present, indicates that the user would like the data delivered in an unordered fashion to the peer (i.e., the U flag is set to 1 on all DATA chunks carrying this message).
o unorderedフラグ-このフラグは、存在する場合、ユーザーがデータを順不同でピアに配信することを希望することを示します（つまり、このメッセージを運ぶすべてのDATAチャンクでUフラグが1に設定されます）。
o no-bundle flag - instructs SCTP not to bundle this user data with other outbound DATA chunks. SCTP MAY still bundle even when this flag is present, when faced with network congestion.
o no-bundleフラグ-このユーザーデータを他の送信DATAチャンクにバンドルしないようにSCTPに指示します。 SCTPは、このフラグが存在する場合でも、ネットワークの輻輳に直面したときにバンドルする場合があります。
o payload protocol-id - a 32-bit unsigned integer that is to be passed to the peer indicating the type of payload protocol data being transmitted. This value is passed as opaque data by SCTP.
o payload protocol-id-送信されるペイロードプロトコルデータのタイプを示す、ピアに渡される32ビットの符号なし整数。この値は、SCTPによって不透明なデータとして渡されます。
F) Set Primary
F）プライマリを設定
Format: SETPRIMARY(association id, destination transport address, [source transport address] ) -> result
形式：SETPRIMARY（関連付けID、宛先トランスポートアドレス、[ソーストランスポートアドレス]）->結果
Instructs the local SCTP to use the specified destination transport address as the primary path for sending packets.
パケットを送信するためのプライマリパスとして指定された宛先トランスポートアドレスを使用するようにローカルSCTPに指示します。
The result of attempting this operation shall be returned. If the specified destination transport address is not present in the "destination transport address list" returned earlier in an associate command or communication up notification, an error shall be returned.
この操作を試みた結果が返されます。指定された宛先トランスポートアドレスが、先に関連付けられたコマンドまたは通信アップ通知で返された「宛先トランスポートアドレスリスト」に存在しない場合、エラーが返されます。
Mandatory attributes:
必須属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - specified as one of the transport addresses of the peer endpoint, which should be used as the primary address for sending packets. This overrides the current primary address information maintained by the local SCTP endpoint.
o 宛先トランスポートアドレス-ピアエンドポイントのトランスポートアドレスの1つとして指定されます。これは、パケットを送信するためのプライマリアドレスとして使用する必要があります。これは、ローカルSCTPエンドポイントによって維持されている現在のプライマリアドレス情報を上書きします。
Optional attributes:
オプションの属性：
o source transport address - optionally, some implementations may allow you to set the default source address placed in all outgoing IP datagrams.
o ソーストランスポートアドレス-オプションで、一部の実装では、すべての発信IPデータグラムに配置されるデフォルトのソースアドレスを設定できます。
G) Receive
G）受け取る
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]
形式：RECEIVE（関連付けID、バッファアドレス、バッファサイズ[、ストリームID]）->バイトカウント[、トランスポートアドレス] [、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、配信番号] [、ペイロードプロトコルID]
This primitive shall read the first user message in the SCTP in-queue into the buffer specified by ULP, if there is one available. The size of the message read, in bytes, will be returned. It may, depending on the specific implementation, also return other information such as the sender's address, the stream id on which it is received, whether there are more messages available for retrieval, etc. For ordered messages, their Stream Sequence Number may also be returned.
このプリミティブは、SCTPインキューの最初のユーザーメッセージをULPで指定されたバッファーに読み込みます（利用可能な場合）。読み込まれたメッセージのサイズ（バイト単位）が返されます。特定の実装によっては、送信者のアドレス、受信したストリームID、取得できるメッセージがまだあるかどうかなど、他の情報も返す場合があります。順序付けされたメッセージの場合、ストリームシーケンス番号も戻ってきた。
Depending upon the implementation, if this primitive is invoked when no message is available the implementation should return an indication of this condition or should block the invoking process until data does become available.
実装によっては、メッセージが使用できないときにこのプリミティブが呼び出された場合、実装はこの状態を示すか、データが使用可能になるまで呼び出しプロセスをブロックする必要があります。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association
o アソシエーションID-SCTPアソシエーションへのローカルハンドル
o buffer address - the memory location indicated by the ULP to store the received message.
o バッファアドレス-受信したメッセージを格納するためにULPによって示されるメモリ位置。
o buffer size - the maximum size of data to be received, in bytes.
o バッファサイズ-受信するデータの最大サイズ（バイト単位）。
Optional attributes:
オプションの属性：
o stream id - to indicate which stream to receive the data on.
o ストリームID-データを受信するストリームを示します。
o Stream Sequence Number - the Stream Sequence Number assigned by the sending SCTP peer.
o ストリームシーケンス番号-送信SCTPピアによって割り当てられたストリームシーケンス番号。
o partial flag - if this returned flag is set to 1, then this Receive contains a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分フラグ-この返されたフラグが1に設定されている場合、この受信にはメッセージ全体の部分配信が含まれます。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
o payload protocol-id - a 32-bit unsigned integer that is received from the peer indicating the type of payload protocol of the received data. This value is passed as opaque data by SCTP.
o payload protocol-id-ピアから受信した32ビットの符号なし整数。受信したデータのペイロードプロトコルのタイプを示します。この値は、SCTPによって不透明なデータとして渡されます。
H) Status
H）ステータス
Format: STATUS(association id) -> status data
形式：STATUS（関連付けID）->ステータスデータ
This primitive should return a data block containing the following information:
このプリミティブは、次の情報を含むデータブロックを返す必要があります。
association connection state, destination transport address list, destination transport address reachability states, current receiver window size, current congestion window sizes, number of unacknowledged DATA chunks, number of DATA chunks pending receipt, primary path, most recent SRTT on primary path, RTO on primary path, SRTT and RTO on other destination addresses, etc.
アソシエーション接続状態、宛先トランスポートアドレスリスト、宛先トランスポートアドレス到達可能性状態、現在の受信側ウィンドウサイズ、現在の輻輳ウィンドウサイズ、未確認のDATAチャンクの数、受信保留中のDATAチャンクの数、プライマリパス、プライマリパス上の最新のSRTT、RTOオンプライマリパス、他の宛先アドレスのSRTTおよびRTOなど
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
Optional attributes:
オプションの属性：
None.
なし。
I) Change Heartbeat
I）ハートビートを変更する
Format: CHANGE HEARTBEAT(association id, destination transport address, new state [,interval]) -> result
形式：CHANGE HEARTBEAT（関連付けID、宛先トランスポートアドレス、新しい状態[、間隔]）->結果
Instructs the local endpoint to enable or disable heartbeat on the specified destination transport address.
指定された宛先トランスポートアドレスでハートビートを有効または無効にするようにローカルエンドポイントに指示します。
The result of attempting this operation shall be returned.
この操作を試みた結果が返されます。
Note: Even when enabled, heartbeat will not take place if the destination transport address is not idle.
注：有効にした場合でも、宛先トランスポートアドレスがアイドル状態でない場合はハートビートは実行されません。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - specified as one of the transport addresses of the peer endpoint.
o 宛先トランスポートアドレス-ピアエンドポイントのトランスポートアドレスの1つとして指定されます。
o new state - the new state of heartbeat for this destination transport address (either enabled or disabled).
o 新しい状態-この宛先トランスポートアドレスのハートビートの新しい状態（有効または無効）。
Optional attributes:
オプションの属性：
o interval - if present, indicates the frequency of the heartbeat if this is to enable heartbeat on a destination transport address. This value is added to the RTO of the destination transport address. This value, if present, affects all destinations.
o interval-存在する場合、これが宛先トランスポートアドレスでハートビートを有効にする場合のハートビートの頻度を示します。この値は、宛先トランスポートアドレスのRTOに追加されます。この値が存在する場合、すべての宛先に影響します。
J) Request HeartBeat
J）HeartBeatのリクエスト
Format: REQUESTHEARTBEAT(association id, destination transport address) -> result
形式：REQUESTHEARTBEAT（関連付けID、宛先トランスポートアドレス）->結果
Instructs the local endpoint to perform a HeartBeat on the specified destination transport address of the given association. The returned result should indicate whether the transmission of the HEARTBEAT chunk to the destination address is successful.
特定の関連付けの指定された宛先トランスポートアドレスでハートビートを実行するようにローカルエンドポイントに指示します。返された結果は、HEARTBEATチャンクの宛先アドレスへの送信が成功したかどうかを示す必要があります。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - the transport address of the association on which a heartbeat should be issued.
o 宛先トランスポートアドレス-ハートビートが発行されるアソシエーションのトランスポートアドレス。
K) Get SRTT Report
K）SRTTレポートを取得する
Format: GETSRTTREPORT(association id, destination transport address) -> srtt result
形式：GETSRTTREPORT（関連付けID、宛先トランスポートアドレス）-> srtt結果
Instructs the local SCTP to report the current SRTT measurement on the specified destination transport address of the given association. The returned result can be an integer containing the most recent SRTT in milliseconds.
特定のアソシエーションの特定の宛先トランスポートアドレスに関する現在のSRTT測定を報告するようにローカルSCTPに指示します。返される結果は、最新のSRTTをミリ秒単位で含む整数にすることができます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - the transport address of the association on which the SRTT measurement is to be reported.
o 宛先トランスポートアドレス-SRTT測定が報告されるアソシエーションのトランスポートアドレス。
L) Set Failure Threshold
L）障害しきい値を設定する
Format: SETFAILURETHRESHOLD(association id, destination transport address, failure threshold)
形式：SETFAILURETHRESHOLD（関連付けID、宛先トランスポートアドレス、障害しきい値）
-> result
->結果
This primitive allows the local SCTP to customize the reachability failure detection threshold 'Path.Max.Retrans' for the specified destination address.
このプリミティブにより、ローカルSCTPは、指定された宛先アドレスの到達可能性障害検出しきい値「Path.Max.Retrans」をカスタマイズできます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - the transport address of the association on which the failure detection threshold is to be set.
o 宛先トランスポートアドレス-障害検出しきい値を設定する関連付けのトランスポートアドレス。
o failure threshold - the new value of 'Path.Max.Retrans' for the destination address.
o 失敗のしきい値-宛先アドレスの「Path.Max.Retrans」の新しい値。
M) Set Protocol Parameters
M）プロトコルパラメータの設定
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> result
形式：SETPROTOCOLPARAMETERS（関連付けID、[、宛先トランスポートアドレス、]プロトコルパラメータリスト）->結果
This primitive allows the local SCTP to customize the protocol parameters.
このプリミティブにより、ローカルSCTPはプロトコルパラメータをカスタマイズできます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans; see Section 15) that the SCTP user wishes to customize.
o プロトコルパラメータリスト-SCTPユーザーがカスタマイズするプロトコルパラメータ（Association.Max.Retransなど）の特定の名前と値（セクション15を参照）。
Optional attributes:
オプションの属性：
o destination transport address - some of the protocol parameters may be set on a per destination transport address basis.
o 宛先トランスポートアドレス-一部のプロトコルパラメータは、宛先トランスポートアドレスごとに設定できます。
N) Receive Unsent Message
N）未送信メッセージを受信
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])
形式：RECEIVE_UNSENT（データ取得ID、バッファアドレス、バッファサイズ[、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、ペイロードプロトコルID]）
o data retrieval id - the identification passed to the ULP in the failure notification.
o データ取得ID-障害通知でULPに渡されるID。
o buffer address - the memory location indicated by the ULP to store the received message.
o バッファアドレス-受信したメッセージを格納するためにULPによって示されるメモリ位置。
o buffer size - the maximum size of data to be received, in bytes.
o バッファサイズ-受信するデータの最大サイズ（バイト単位）。
Optional attributes:
オプションの属性：
o stream id - this is a return value that is set to indicate which stream the data was sent to.
o ストリームID-これは、データの送信先のストリームを示すために設定される戻り値です。
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-メッセージに関連付けられたストリームシーケンス番号を示すこの値が返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
o payload protocol-id - The 32 bit unsigned integer that was sent to be sent to the peer indicating the type of payload protocol of the received data.
o payload protocol-id-ピアに送信するために送信された32ビットの符号なし整数。受信したデータのペイロードプロトコルのタイプを示します。
o Receive Unacknowledged Message
o 未確認メッセージを受信
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])
形式：RECEIVE_UNACKED（データ取得ID、バッファアドレス、バッファサイズ、[、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、ペイロードプロトコルID]）
o data retrieval id - the identification passed to the ULP in the failure notification.
o データ取得ID-障害通知でULPに渡されるID。
o buffer address - the memory location indicated by the ULP to store the received message.
o バッファアドレス-受信したメッセージを格納するためにULPによって示されるメモリ位置。
o buffer size - the maximum size of data to be received, in bytes.
o バッファサイズ-受信するデータの最大サイズ（バイト単位）。
Optional attributes:
オプションの属性：
o stream id - this is a return value that is set to indicate which stream the data was sent to.
o ストリームID-これは、データの送信先のストリームを示すために設定される戻り値です。
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-メッセージに関連付けられたストリームシーケンス番号を示すこの値が返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
o payload protocol-id - the 32-bit unsigned integer that was sent to the peer indicating the type of payload protocol of the received data.
o payload protocol-id-受信したデータのペイロードプロトコルのタイプを示す、ピアに送信された32ビットの符号なし整数。
P) Destroy SCTP Instance
P）SCTPインスタンスを破棄する
Format: DESTROY(local SCTP instance name)
形式：DESTROY（ローカルSCTPインスタンス名）
o local SCTP instance name - this is the value that was passed to the application in the initialize primitive and it indicates which SCTP instance is to be destroyed.
o ローカルSCTPインスタンス名-これは、初期化プリミティブでアプリケーションに渡された値であり、破棄するSCTPインスタンスを示します。
It is assumed that the operating system or application environment provides a means for the SCTP to asynchronously signal the ULP process. When SCTP does signal a ULP process, certain information is passed to the ULP.
オペレーティングシステムまたはアプリケーション環境は、SCTPがULPプロセスに非同期に信号を送るための手段を提供すると想定されています。 SCTPがULPプロセスを通知する場合、特定の情報がULPに渡されます。
IMPLEMENTATION NOTE: In some cases, this may be done through a separate socket or error channel.
実装上の注意：場合によっては、これは別のソケットまたはエラーチャネルを介して行われることがあります。
A) DATA ARRIVE notification
A）データ到着通知
SCTP shall invoke this notification on the ULP when a user message is successfully received and ready for retrieval.
SCTPは、ユーザーメッセージが正常に受信され、取得の準備ができたときに、ULPでこの通知を呼び出します。
The following may optionally be passed with the notification:
オプションで、通知とともに以下を渡すことができます。
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o stream id - to indicate which stream the data is received on.
o ストリームID-データが受信されるストリームを示します。
B) SEND FAILURE notification
B）SEND FAILURE通知
If a message cannot be delivered, SCTP shall invoke this notification on the ULP.
メッセージを配信できない場合、SCTPはULPでこの通知を呼び出します。
The following may optionally be passed with the notification:
オプションで、通知とともに以下を渡すことができます。
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o データ取得ID-未送信および未確認のデータを取得するために使用されるID。
o cause code - indicating the reason of the failure, e.g., size too large, message life time expiration, etc.
o 原因コード-失敗の理由を示します（サイズが大きすぎる、メッセージの存続期間の期限切れなど）。
o context - optional information associated with this message (see D in Section 10.1).
o context-このメッセージに関連付けられたオプションの情報（セクション10.1のDを参照）。
C) NETWORK STATUS CHANGE notification
C）ネットワークステータス変更通知
When a destination transport address is marked inactive (e.g., when SCTP detects a failure) or marked active (e.g., when SCTP detects a recovery), SCTP shall invoke this notification on the ULP.
宛先トランスポートアドレスが非アクティブとしてマークされる（SCTPが障害を検出するなど）か、アクティブとしてマークされる（SCTPが回復を検出するなど）と、SCTPはULPでこの通知を呼び出します。
The following shall be passed with the notification:
次のものは通知とともに渡されます。
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o destination transport address - this indicates the destination transport address of the peer endpoint affected by the change.
o 宛先トランスポートアドレス-これは、変更の影響を受けるピアエンドポイントの宛先トランスポートアドレスを示します。
o new-status - this indicates the new status.
o new-status-これは新しいステータスを示します。
D) COMMUNICATION UP notification
D）通信アップ通知
This notification is used when SCTP becomes ready to send or receive user messages, or when a lost communication to an endpoint is restored.
この通知は、SCTPがユーザーメッセージを送受信できるようになったとき、またはエンドポイントとの通信が失われたときに復元されます。
IMPLEMENTATION NOTE: If the ASSOCIATE primitive is implemented as a blocking function call, the association parameters are returned as a result of the ASSOCIATE primitive itself. In that case, COMMUNICATION UP notification is optional at the association initiator's side.
実装上の注意：ASSOCIATEプリミティブがブロッキング関数呼び出しとして実装されている場合、関連付けパラメーターはASSOCIATEプリミティブ自体の結果として返されます。その場合、アソシエーションの開始者側では、COMMUNICATION UP通知はオプションです。
The following shall be passed with the notification:
次のものは通知とともに渡されます。
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o status - This indicates what type of event has occurred.
o status-これは、発生したイベントのタイプを示します。
o destination transport address list - the complete set of transport addresses of the peer.
o 宛先トランスポートアドレスリスト-ピアのトランスポートアドレスの完全なセット。
o outbound stream count - the maximum number of streams allowed to be used in this association by the ULP.
o アウトバウンドストリーム数-ULPがこの関連付けで使用できるストリームの最大数。
o inbound stream count - the number of streams the peer endpoint has requested with this association (this may not be the same number as 'outbound stream count').
o インバウンドストリーム数-ピアエンドポイントがこの関連付けで要求したストリームの数（これは「アウトバウンドストリーム数」と同じ数ではない場合があります）。
E) COMMUNICATION LOST notification
E）COMMUNICATION LOST通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
SCTPがエンドポイントとの通信を完全に（ハートビートなどを介して）失うか、エンドポイントが中止操作を実行したことを検出すると、ULPでこの通知を呼び出します。
The following shall be passed with the notification:
次のものは通知とともに渡されます。
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o status - this indicates what type of event has occurred; the status may indicate that a failure OR a normal termination event occurred in response to a shutdown or abort request.
o ステータス-これは、発生したイベントのタイプを示します。ステータスは、障害または正常終了イベントがシャットダウンまたは中止要求に応答して発生したことを示している場合があります。
The following may be passed with the notification:
通知では以下が渡される場合があります。
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o データ取得ID-未送信および未確認のデータを取得するために使用されるID。
o last-acked - the TSN last acked by that peer endpoint.
o last-acked-そのピアエンドポイントによって最後に確認されたTSN。
o last-sent - the TSN last sent to that peer endpoint.
o last-sent-そのピアエンドポイントに最後に送信されたTSN。
o Upper Layer Abort Reason - the abort reason specified in case of a user-initiated abort.
o 上位層の中止理由-ユーザーが開始した中止の場合に指定された中止理由。
F) COMMUNICATION ERROR notification
F）通信エラー通知
When SCTP receives an ERROR chunk from its peer and decides to notify its ULP, it can invoke this notification on the ULP.
SCTPは、ピアからERRORチャンクを受信し、ULPに通知することを決定すると、ULPでこの通知を呼び出すことができます。
The following can be passed with the notification:
以下は通知で渡すことができます：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o error info - this indicates the type of error and optionally some additional information received through the ERROR chunk.
o エラー情報-これはエラーのタイプを示し、オプションでERRORチャンクを介して受け取ったいくつかの追加情報を示します。
G) RESTART notification
G）RESTART通知
When SCTP detects that the peer has restarted, it may send this notification to its ULP.
SCTPは、ピアが再起動したことを検出すると、この通知をULPに送信します。
The following can be passed with the notification:
以下は通知で渡すことができます：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
H) SHUTDOWN COMPLETE notification
H）シャットダウン完了通知
When SCTP completes the shutdown procedures (Section 9.2), this notification is passed to the upper layer.
SCTPがシャットダウン手順（セクション9.2）を完了すると、この通知は上位層に渡されます。
The following can be passed with the notification:
以下は通知で渡すことができます：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
As a common transport protocol designed to reliably carry time-sensitive user messages, such as billing or signaling messages for telephony services, between two networked endpoints, SCTP has the following security objectives.
ネットワークに接続された2つのエンドポイント間で、テレフォニーサービスの課金メッセージやシグナリングメッセージなどの時間依存のユーザーメッセージを確実に伝送するように設計された一般的なトランスポートプロトコルとして、SCTPには次のセキュリティ目標があります。
- availability of reliable and timely data transport services
- 信頼性が高くタイムリーなデータ転送サービスの可用性
- integrity of the user-to-user information carried by SCTP
- SCTPによって運ばれるユーザー間の情報の整合性
SCTP may potentially be used in a wide variety of risk situations. It is important for operators of systems running SCTP to analyze their particular situations and decide on the appropriate counter-measures.
SCTPは、さまざまなリスク状況で使用される可能性があります。 SCTPを実行しているシステムのオペレーターは、特定の状況を分析し、適切な対策を決定することが重要です。
Operators of systems running SCTP should consult [RFC2196] for guidance in securing their site.
SCTPを実行しているシステムの運用者は、サイトを保護するためのガイダンスについて[RFC2196]を参照する必要があります。
The principles of [RFC2196] should be applied to minimize the risk of theft of information or sabotage by insiders. Such procedures include publication of security policies, control of access at the physical, software, and network levels, and separation of services.
[RFC2196]の原則を適用して、情報の盗難や内部関係者による妨害のリスクを最小限に抑える必要があります。このような手順には、セキュリティポリシーの公開、物理レベル、ソフトウェアレベル、ネットワークレベルでのアクセス制御、サービスの分離が含まれます。
Where the risk of undetected errors in datagrams delivered by the lower-layer transport services is considered to be too great, additional integrity protection is required. If this additional protection were provided in the application layer, the SCTP header would remain vulnerable to deliberate integrity attacks. While the existing SCTP mechanisms for detection of packet replays are considered sufficient for normal operation, stronger protections are needed to protect SCTP when the operating environment contains significant risk of deliberate attacks from a sophisticated adversary.
下位層のトランスポートサービスによって配信されるデータグラムの未検出エラーのリスクが高すぎると考えられる場合は、追加の整合性保護が必要です。この追加の保護がアプリケーション層で提供された場合、SCTPヘッダーは意図的な整合性攻撃に対して脆弱なままになります。パケットリプレイを検出するための既存のSCTPメカニズムは通常の運用には十分であると考えられていますが、運用環境に高度な攻撃者からの意図的な攻撃の重大なリスクがある場合、SCTPを保護するにはより強力な保護が必要です。
The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used when the threat environment requires stronger integrity protections, but does not require confidentiality.
SCTP認証拡張SCTP-AUTH [RFC4895]は、脅威環境がより強力な完全性保護を必要とするが、機密性は必要としない場合に使用できます。
In most cases, the risk of breach of confidentiality applies to the signaling data payload, not to the SCTP or lower-layer protocol overheads. If that is true, encryption of the SCTP user data only might be considered. As with the supplementary checksum service, user data encryption MAY be performed by the SCTP user application. Alternately, the user application MAY use an implementation-specific API to request that the IP Encapsulating Security Payload (ESP) [RFC4303] be used to provide confidentiality and integrity.
ほとんどの場合、機密性の侵害のリスクは、SCTPまたは下位層プロトコルのオーバーヘッドではなく、シグナリングデータペイロードに適用されます。これが当てはまる場合は、SCTPユーザーデータの暗号化のみが考慮される場合があります。補足チェックサムサービスと同様に、ユーザーデータの暗号化はSCTPユーザーアプリケーションによって実行される場合があります。または、ユーザーアプリケーションは、実装固有のAPIを使用して、IPカプセル化セキュリティペイロード（ESP）[RFC4303]を使用して機密性と整合性を提供することを要求できます（MAY）。
Particularly for mobile users, the requirement for confidentiality might include the masking of IP addresses and ports. In this case, ESP SHOULD be used instead of application-level confidentiality. If ESP is used to protect confidentiality of SCTP traffic, an ESP cryptographic transform that includes cryptographic integrity protection MUST be used, because if there is a confidentiality threat there will also be a strong integrity threat.
特にモバイルユーザーの場合、機密性の要件には、IPアドレスとポートのマスキングが含まれる場合があります。この場合、アプリケーションレベルの機密性の代わりにESPを使用する必要があります（SHOULD）。 ESPを使用してSCTPトラフィックの機密性を保護する場合は、暗号化の完全性保護を含むESP暗号化トランスフォームを使用する必要があります。これは、機密性の脅威がある場合、強力な完全性の脅威も存在するためです。
Whenever ESP is in use, application-level encryption is not generally required.
ESPが使用されている場合は常に、アプリケーションレベルの暗号化は通常必要ありません。
Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used for key management.
機密性が提供される場所に関係なく、インターネットキー交換プロトコルバージョン2（IKEv2）[RFC4306]はキー管理に使用する必要があります（SHOULD）。
Operators should consult [RFC4301] for more information on the security services available at and immediately above the Internet Protocol layer.
通信事業者は、インターネットプロトコルレイヤーおよびそのすぐ上で利用可能なセキュリティサービスの詳細について、[RFC4301]を参照する必要があります。
A blind attack is one where the attacker is unable to intercept or otherwise see the content of data flows passing to and from the target SCTP node. Blind denial-of-service attacks may take the form of flooding, masquerade, or improper monopolization of services.
ブラインド攻撃とは、攻撃者が標的のSCTPノードとの間でやり取りされるデータフローの内容を傍受または他の方法で確認できない攻撃です。ブラインドサービス拒否攻撃は、フラッディング、なりすまし、またはサービスの不適切な独占の形をとる場合があります。
The objective of flooding is to cause loss of service and incorrect behavior at target systems through resource exhaustion, interference with legitimate transactions, and exploitation of buffer-related software bugs. Flooding may be directed either at the SCTP node or at resources in the intervening IP Access Links or the Internet. Where the latter entities are the target, flooding will manifest itself as loss of network services, including potentially the breach of any firewalls in place.
フラッディングの目的は、リソースの枯渇、正当なトランザクションへの干渉、およびバッファ関連のソフトウェアバグの悪用を通じて、ターゲットシステムでサービスの損失と不正な動作を引き起こすことです。フラッディングは、SCTPノードか、介在するIPアクセスリンクまたはインターネットのリソースのいずれかに向けられます。後者のエンティティがターゲットの場合、フラッディングは、ファイアウォールの違反など、ネットワークサービスの喪失として現れます。
In general, protection against flooding begins at the equipment design level, where it includes measures such as:
一般に、洪水に対する保護は機器の設計レベルから始まり、次のような対策が含まれます。
- avoiding commitment of limited resources before determining that the request for service is legitimate.
- サービスの要求が正当であると判断する前に、限られたリソースのコミットメントを回避します。
- giving priority to completion of processing in progress over the acceptance of new work.
- 新しい作業の受け入れよりも進行中の処理の完了を優先します。
- identification and removal of duplicate or stale queued requests for service.
- 重複または古いキューに入れられたサービス要求の識別と削除。
- not responding to unexpected packets sent to non-unicast addresses.
- 非ユニキャストアドレスに送信された予期しないパケットに応答しない。
Network equipment should be capable of generating an alarm and log if a suspicious increase in traffic occurs. The log should provide information such as the identity of the incoming link and source address(es) used, which will help the network or SCTP system operator to take protective measures. Procedures should be in place for the operator to act on such alarms if a clear pattern of abuse emerges.
ネットワーク機器は、疑わしいトラフィックの増加が発生した場合、アラームを生成してログに記録できる必要があります。ログには、着信リンクのIDや使用されているソースアドレスなどの情報が含まれている必要があります。これは、ネットワークまたはSCTPシステムオペレーターが保護対策を講じるのに役立ちます。悪用の明確なパターンが発生した場合に、オペレーターがそのようなアラームに対処するための手順を用意する必要があります。
The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way startup handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association.
SCTPの設計は、特に4方向の起動ハンドシェイクの使用、ハンドシェイクが完了するまで応答するSCTPノードでのリソースのコミットメントを延期するためのCookieの使用、および検証タグの使用において、フラッディング攻撃に耐性があります。確立されたアソシエーションのフローへの無関係なパケットの挿入を防ぐため。
The IP Authentication Header and Encapsulating Security Payload might be useful in reducing the risk of certain kinds of denial-of-service attacks.
IP認証ヘッダーとカプセル化セキュリティペイロードは、特定の種類のサービス拒否攻撃のリスクを軽減するのに役立ちます。
The use of the host name feature in the INIT chunk could be used to flood a target DNS server. A large backlog of DNS queries, resolving the host name received in the INIT chunk to IP addresses, could be accomplished by sending INITs to multiple hosts in a given domain. In addition, an attacker could use the host name feature in an indirect attack on a third party by sending large numbers of INITs to random hosts containing the host name of the target. In addition to the strain on DNS resources, this could also result in large numbers of INIT ACKs being sent to the target. One method to protect against this type of attack is to verify that the IP addresses received from DNS include the source IP address of the original INIT. If the list of IP addresses received from DNS does not include the source IP address of the INIT, the endpoint MAY silently discard the INIT. This last option will not protect against the attack against the DNS.
INITチャンクのホスト名機能を使用すると、ターゲットDNSサーバーをフラッディングする可能性があります。 INITチャンクで受け取ったホスト名をIPアドレスに解決するDNSクエリの大量のバックログは、特定のドメインの複数のホストにINITを送信することで実現できます。さらに、攻撃者は、ターゲットのホスト名を含むランダムなホストに大量のINITを送信することにより、第三者への間接攻撃でホスト名機能を使用する可能性があります。 DNSリソースへの負担に加えて、これにより、ターゲットに送信されるINIT ACKが大量になる可能性もあります。このタイプの攻撃から保護する1つの方法は、DNSから受信したIPアドレスに元のINITのソースIPアドレスが含まれていることを確認することです。 DNSから受け取ったIPアドレスのリストにINITのソースIPアドレスが含まれていない場合、エンドポイントはINITを通知せずに破棄する場合があります。この最後のオプションは、DNSに対する攻撃から保護しません。
Masquerade can be used to deny service in several ways:
マスカレードは、いくつかの方法でサービスを拒否するために使用できます。
- by tying up resources at the target SCTP node to which the impersonated node has limited access. For example, the target node may by policy permit a maximum of one SCTP association with the impersonated SCTP node. The masquerading attacker may attempt to establish an association purporting to come from the impersonated node so that the latter cannot do so when it requires it.
- 偽装ノードがアクセスを制限されているターゲットSCTPノードでリソースを拘束する。たとえば、ターゲットノードはポリシーにより、なりすましSCTPノードとの最大1つのSCTPアソシエーションを許可する場合があります。なりすましの攻撃者は、なりすましのノードから来たとするアソシエーションを確立しようと試みる可能性があります。
- by deliberately allowing the impersonation to be detected, thereby provoking counter-measures that cause the impersonated node to be locked out of the target SCTP node.
- 意図的になりすましを検出できるようにすることにより、偽装ノードがターゲットSCTPノードからロックアウトされる原因となる対策を引き起こします。
- by interfering with an established association by inserting extraneous content such as a SHUTDOWN request.
- SHUTDOWNリクエストなどの無関係なコンテンツを挿入して、確立された関連付けを妨害する。
SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Because the initial exchange is memory-less, no lockout mechanism is triggered by blind masquerade attacks. In addition, the INIT ACK containing the State Cookie is transmitted back to the IP address from which it received the INIT. Thus, the attacker would not receive the INIT ACK containing the State Cookie. SCTP protects against insertion of extraneous packets into the flow of an established association by use of the Verification Tag.
SCTPは、4ウェイスタートアップハンドシェイクを使用することにより、IPスプーフィングによるブラインドマスカレード攻撃のリスクを軽減します。最初の交換ではメモリがなくなるため、ブラインドマスカレード攻撃によってロックアウトメカニズムがトリガーされることはありません。さらに、状態Cookieを含むINIT ACKは、INITを受け取ったIPアドレスに送信されます。したがって、攻撃者は状態Cookieを含むINIT ACKを受信しません。 SCTPは、検証タグを使用して、確立されたアソシエーションのフローに無関係なパケットが挿入されるのを防ぎます。
Logging of received INIT requests and abnormalities such as unexpected INIT ACKs might be considered as a way to detect patterns of hostile activity. However, the potential usefulness of such logging must be weighed against the increased SCTP startup processing it implies, rendering the SCTP node more vulnerable to flooding attacks. Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis.
受信したINIT要求と予期しないINIT ACKなどの異常のロギングは、悪意のあるアクティビティのパターンを検出する方法と見なされる場合があります。ただし、そのようなロギングの潜在的な有用性は、それが意味する増加したSCTP起動処理と比較して、SCTPノードをフラッディング攻撃に対してより脆弱にする必要があります。日常的にログを確認および分析するための操作手順を確立しなければ、ロギングは無意味です。
Attacks under this heading are performed openly and legitimately by the attacker. They are directed against fellow users of the target SCTP node or of the shared resources between the attacker and the target node. Possible attacks include the opening of a large number of associations between the attacker's node and the target, or transfer of large volumes of information within a legitimately established association.
この見出しの下の攻撃は、攻撃者によって公然と正当に行われます。それらは、ターゲットSCTPノードまたは攻撃者とターゲットノード間の共有リソースの仲間のユーザーに対して向けられます。可能性のある攻撃には、攻撃者のノードとターゲット間の多数の関連付けのオープン、または正当に確立された関連付け内の大量の情報の転送が含まれます。
Policy limits should be placed on the number of associations per adjoining SCTP node. SCTP user applications should be capable of detecting large volumes of illegitimate or "no-op" messages within a given association and either logging or terminating the association as a result, based on local policy.
ポリシー制限は、隣接するSCTPノードごとのアソシエーションの数に設定する必要があります。 SCTPユーザーアプリケーションは、ローカルポリシーに基づいて、特定のアソシエーション内の大量の不正または「no-op」メッセージを検出し、結果としてアソシエーションをログに記録または終了することができる必要があります。
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
一部のファイアウォールは、断片化されたSCTPパケットの最初のフラグメントのみを検査し、それがINITチャンクに対応するかどうかを明確に判断できる場合に役立ちます（詳細については、[RFC1858]を参照してください）。したがって、セクション3.1に記載されている要件を強調します。（1）INITチャンクはバンドルしてはいけません。
with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk.
パケット内の他のチャンク、および（2）INITチャンクを含むパケットにはゼロ検証タグが必要です。さらに、INITチャンクの受信者は、他のチャンクにバンドルされているか、ゼロ以外の検証タグがあり、INITチャンクを含むINITチャンクを持つ到着パケットをサイレントに破棄することにより、これらのルールを適用する必要があります。
To provide a non-SCTP-capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C.
SCTP非対応ホストに、SCTP対応ホストと同じレベルの攻撃に対する保護を提供するには、すべてのSCTPスタックが、付録Cで説明されているICMP処理を実装する必要があります。
When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA.
SCTPスタックが複数の制御チャンクまたはDATAチャンクを含むパケットを受信し、そのパケットの処理で応答として複数のチャンクを送信する必要がある場合、応答チャンクの送信者は複数のパケットを送信してはなりません（MUST NOT）。バンドリングがサポートされている場合、単一のパケットに収まる複数の応答チャンクが1つの単一の応答パケットにバンドルされる場合があります。バンドリングがサポートされていない場合、送信者は複数の応答チャンクを送信してはならず（MUST NOT）、他のすべての応答を破棄しなければなりません（MUST）。 SACKチャンクはそれ自体がDATAへの応答であり、SACKはそれ以上のDATAの応答を必要としないため、このルールはSACKチャンクには適用されないことに注意してください。
An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent.
SCTP実装は、送信されていないTSNを確認するSACKを受信した場合、関連付けを中止する必要があります（SHOULD）。
An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT ACK as small as possible to reduce the possibility of byte amplification attacks.
応答に大きなパケットを必要とするINITを受信するSCTP実装では、複数のERRORパラメータが含まれているため、（独自の裁量で）ERRORパラメータの一部またはすべてを省略してINIT ACKのサイズを小さくすることができます（MAY）。 COOKIEパラメータのサイズと、INITの受信者がピアに示すアドレスの数の組み合わせにより、INIT ACKが元のINITよりも大きくなる可能性があります。 SCTP実装は、バイト増幅攻撃の可能性を減らすために、INIT ACKをできるだけ小さくしようとする必要があります（SHOULD）。
The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.
[RFC3873]で定義されているSCTPのMIBモジュールは、このドキュメントで指定されているプロトコルのバージョンに適用されます。
This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization.
このセクションでは、実装のためにTCB内に含める必要がある推奨されるパラメーターのセットについて詳しく説明します。このセクションは例示を目的としたものであり、実装の要件として、またはSCTP TCB内のすべてのパラメーターの完全なリストとして見なしてはなりません。各実装には、最適化のために独自の追加パラメーターが必要な場合があります。
Associations: A list of current associations and mappings to the data consumers for each association. This may be in the form of a hash table or other implementation-dependent structure. The data consumers may be process identification information such as file descriptors, named pipe pointer, or table pointers dependent on how SCTP is implemented.
関連付け：現在の関連付けのリストと、各関連付けのデータコンシューマーへのマッピング。これは、ハッシュテーブルまたは他の実装に依存する構造の形式にすることができます。データコンシューマは、SCTPの実装方法に応じて、ファイル記述子、名前付きパイプポインタ、テーブルポインタなどのプロセス識別情報になる場合があります。
Secret Key: A secret key used by this endpoint to compute the MAC. This SHOULD be a cryptographic quality random number with a sufficient length. Discussion in RFC 4086 can be helpful in selection of the key.
秘密鍵：このエンドポイントがMACを計算するために使用する秘密鍵。これは、十分な長さの暗号品質の乱数である必要があります。 RFC 4086での議論は、キーの選択に役立ちます。
Address List: The list of IP addresses that this instance has bound. This information is passed to one's peer(s) in INIT and INIT ACK chunks.
アドレスリスト：このインスタンスがバインドしたIPアドレスのリスト。この情報は、INITチャンクおよびINIT ACKチャンクでピアに渡されます。
SCTP Port: The local SCTP port number to which the endpoint is bound.
SCTPポート：エンドポイントがバインドされているローカルSCTPポート番号。
Peer : Tag value to be sent in every packet and is received Verification: in the INIT or INIT ACK chunk. Tag :
ピア：すべてのパケットで送信され、受信されるタグ値検証：INITまたはINIT ACKチャンク。鬼ごっこ ：
My : Tag expected in every inbound packet and sent in the Verification: INIT or INIT ACK chunk. Tag :
My：すべてのインバウンドパケットで予期され、検証で送信されるタグ：INITまたはINIT ACKチャンク。鬼ごっこ ：
State : A state variable indicating what state the association
: is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
: SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
: SHUTDOWN-ACK-SENT.
Note: No "CLOSED" state is illustrated since if a association is "CLOSED" its TCB SHOULD be removed.
注：アソシエーションが「クローズ」されている場合、そのTCBを削除する必要があるため、「クローズ」状態は示されていません。
Peer : A list of SCTP transport addresses to which the peer Transport : is bound. This information is derived from the INIT or Address : INIT ACK and is used to associate an inbound packet List : with a given association. Normally, this information : is hashed or keyed for quick lookup and access of the : TCB.
ピア：ピアTransport：がバインドされているSCTPトランスポートアドレスのリスト。この情報はINITまたはAddress：INIT ACKから取得され、インバウンドパケットList：を特定の関連付けに関連付けるために使用されます。通常、この情報は：TCBの迅速な検索とアクセスのためにハッシュまたはキー化されます。
Primary : This is the current primary destination transport Path : address of the peer endpoint. It may also specify a : source transport address on this endpoint.
Primary：これは現在のプライマリ宛先トランスポートです。Path：ピアエンドポイントのアドレス。このエンドポイントで：ソーストランスポートアドレスを指定することもできます。
Overall : The overall association error count. Error Count :
全体：全体的な関連付けエラーの数。エラー数：
Overall : The threshold for this association that if the Overall Error : Error Count reaches will cause this association to be Threshold : torn down.
全体：この関連付けのしきい値。全体的なエラー：エラー数に達すると、この関連付けはしきい値：破棄されます。
Peer Rwnd : Current calculated value of the peer's rwnd.
Peer Rwnd：ピアのrwndの現在の計算値。
Next TSN : The next TSN number to be assigned to a new DATA chunk.
: This is sent in the INIT or INIT ACK chunk to the peer
: and incremented each time a DATA chunk is assigned a
: TSN (normally just prior to transmit or during
: fragmentation).
Last Rcvd : This is the last TSN received in sequence. This value TSN : is set initially by taking the peer's initial TSN, : received in the INIT or INIT ACK chunk, and : subtracting one from it.
Last Rcvd：これは順番に受信された最後のTSNです。この値TSN：は、ピアの初期TSNを取得することによって最初に設定され、：INITまたはINIT ACKチャンクで受信され、：そこから1を減算します。
Mapping : An array of bits or bytes indicating which out-of-
Array : order TSNs have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e., no out-of-
: order packets have been received, this array will
: be set to all zero. This structure may be in the
: form of a circular buffer or bit array.
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA
: chunks are out of order, SACKs are not delayed (see
: Section 6).
Inbound : An array of structures to track the inbound streams, Streams : normally including the next sequence number expected : and possibly the stream number.
インバウンド：インバウンドストリームを追跡するための構造の配列、ストリーム：通常、予期される次のシーケンス番号を含みます：おそらくストリーム番号。
Outbound : An array of structures to track the outbound streams, Streams : normally including the next sequence number to : be sent on the stream.
Outbound：アウトバウンドストリームを追跡するための構造の配列、Streams：通常、次のシーケンス番号を含む：ストリームで送信されます。
Reasm Queue : A reassembly queue.
Reasm Queue：再構成キュー。
Local : The list of local IP addresses bound in to this Transport : association. Address : List :
ローカル：このトランスポートに関連付けられているローカルIPアドレスのリスト：関連付け。住所：リスト：
Association : The smallest PMTU discovered for all of the PMTU : peer's transport addresses.
関連付け：すべてのPMTUで検出された最小のPMTU：ピアのトランスポートアドレス。
For each destination transport address in the peer's address list derived from the INIT or INIT ACK chunk, a number of data elements need to be maintained including:
INITまたはINIT ACKチャンクから派生したピアのアドレスリスト内の各宛先トランスポートアドレスについて、以下を含む多くのデータ要素を維持する必要があります。
Error Count : The current error count for this destination.
エラー数：この送り先の現在のエラー数。
Error : Current error threshold for this destination, i.e., Threshold : what value marks the destination down if error count : reaches this value.
Error：この宛先の現在のエラーしきい値。つまり、Threshold：エラーカウント：この値に達した場合に、宛先をマークする値。
cwnd : The current congestion window.
cwnd：現在の輻輳ウィンドウ。
ssthresh : The current ssthresh value.
ssthresh：現在のssthresh値。
RTO : The current retransmission timeout value.
RTO：現在の再送信タイムアウト値。
SRTT : The current smoothed round-trip time.
SRTT：現在の平滑化された往復時間。
RTTVAR : The current RTT variation.
RTTVAR：現在のRTTバリエーション。
partial : The tracking method for increase of cwnd when in bytes acked : congestion avoidance mode (see Section 7.2.2).
部分的：ackedバイトでのcwndの増加の追跡方法：輻輳回避モード（セクション7.2.2を参照）。
state : The current state of this destination, i.e., DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, etc.
state：この宛先の現在の状態。つまり、DOWN、UP、：ALLOW-HB、NO-HEARTBEATなど。
PMTU : The current known path MTU.
PMTU：現在既知のパスMTU。
Per : A timer used by each destination. Destination : Timer :
Per：各宛先で使用されるタイマー。宛先：タイマー：
RTO-Pending : A flag used to track if one of the DATA chunks sent to
: this address is currently being used to compute an
: RTT. If this flag is 0, the next DATA chunk sent to
: this destination should be used to compute an RTT and
: this flag should be set. Every time the RTT
: calculation completes (i.e., the DATA chunk is SACK'd),
: clear this flag.
last-time : The time to which this destination was last sent. : This can be to determine if a HEARTBEAT is needed.
last-time：この宛先が最後に送信された時刻。 ：これは、ハートビートが必要かどうかを判断するために使用できます。
Out Queue : A queue of outbound DATA chunks.
Out Queue：アウトバウンドDATAチャンクのキュー。
In Queue : A queue of inbound DATA chunks.
In Queue：インバウンドDATAチャンクのキュー。
SCTP defines three registries that IANA maintains:
SCTPは、IANAが維持する3つのレジストリを定義しています。
- through definition of additional chunk types, - through definition of additional parameter types, or - through definition of additional cause codes within ERROR chunks.
- 追加のチャンクタイプの定義を通じて-追加のパラメータータイプの定義を通じて-またはERRORチャンク内の追加の原因コードの定義を通じて。
SCTP requires that the IANA Port Numbers registry be opened for SCTP port registrations, Section 14.5 describes how. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests.
SCTPでは、SCTPポート登録のためにIANAポート番号レジストリを開く必要があります。セクション14.5でその方法を説明します。 IESGが任命したExpert Reviewerは、SCTPポート割り当て要求の評価においてIANAをサポートします。
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新しいチャンクパラメータタイプコードの割り当ては、[RFC2434]で定義されているIETFコンセンサスアクションを通じて行われます。チャンクパラメータのドキュメントには、次の情報を含める必要があります。
a) A long and short name for the new chunk type.
a) 新しいチャンクタイプの長い名前と短い名前。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) チャンクの構造の詳細な説明。セクション3.2で定義された基本構造に準拠する必要があります。
c) A detailed definition and description of intended use of each field within the chunk, including the chunk flags if any.
c) チャンク内の各フィールドの使用目的の詳細な定義と説明。チャンクフラグがあればそれも含まれます。
d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.
d) プロトコルの操作内での新しいチャンクタイプの使用に関する詳細な手順の説明。
The last chunk type (255) is reserved for future extension if necessary.
最後のチャンクタイプ（255）は、必要に応じて将来の拡張のために予約されています。
The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新しいチャンクパラメータタイプコードの割り当ては、[RFC2434]で定義されているIETFコンセンサスアクションを通じて行われます。チャンクパラメータのドキュメントには、次の情報を含める必要があります。
a) Name of the parameter type.
a) パラメータタイプの名前。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general Type-Length-Value format described in Section 3.2.1.
b) パラメータフィールドの構造の詳細な説明。この構造は、セクション3.2.1で説明されている一般的なType-Length-Value形式に準拠する必要があります。
c) Detailed definition of each component of the parameter value.
c) パラメータ値の各コンポーネントの詳細な定義。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) このパラメータータイプの使用目的の詳細な説明、およびこのパラメータータイプの複数のインスタンスが同じチャンク内で見つかるかどうか、またどのような状況下にあるかを示します。
e) Each parameter type MUST be unique across all chunks.
e) 各パラメータタイプは、すべてのチャンクで一意である必要があります。
Additional cause codes may be allocated in the range 11 to 65535 through a Specification Required action as defined in [RFC2434]. Provided documentation must include the following information:
追加の原因コードは、[RFC2434]で定義されている仕様が必要なアクションを通じて11〜65535の範囲で割り当てることができます。提供されるドキュメントには、次の情報が含まれている必要があります。
a) Name of the error condition.
a) エラー状態の名前。
b) Detailed description of the conditions under which an SCTP endpoint should issue an ERROR (or ABORT) with this cause code.
b) SCTPエンドポイントがこの原因コードでERROR（またはABORT）を発行する条件の詳細な説明。
c) Expected action by the SCTP endpoint that receives an ERROR (or ABORT) chunk containing this cause code.
c) この原因コードを含むERROR（またはABORT）チャンクを受け取るSCTPエンドポイントによる予期されるアクション。
d) Detailed description of the structure and content of data fields that accompany this cause code.
d) この原因コードに伴うデータフィールドの構造と内容の詳細な説明。
The initial word (32 bits) of a cause code parameter MUST conform to the format shown in Section 3.3.10, i.e.:
原因コードパラメータの最初のワード（32ビット）は、セクション3.3.10に示す形式に準拠する必要があります。
- first 2 bytes contain the cause code value - last 2 bytes contain the length of the cause parameter.
- first 2 bytes contain the cause code value - last 2 bytes contain the length of the cause parameter.
Except for value 0, which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data.
DATAチャンク内の未指定のペイロードプロトコル識別子を示すためにSCTPによって予約されている値0を除いて、SCTPはペイロードプロトコル識別子の標準化または検証を担当しません。 SCTPは単に上位層から識別子を受信し、対応するペイロードデータと一緒にそれを運びます。
The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP.
上位層、つまりSCTPユーザーは、必要に応じて、特定のプロトコル識別子をIANAで標準化する必要があります（SHOULD）。特定のペイロードプロトコル識別子の使用は、SCTPの範囲外です。
SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC2434].
SCTPサービスは、コンタクトポート番号を使用して、TCPやUDPのように、不明な発信者にサービスを提供できます。したがって、IANAは、既存のポート番号の登録手順と十分に一致させる予定の次のルールを使用して、SCTPの既存のポート番号レジストリを開くように要求されます。 IESGが任命したExpert Reviewerは、[RFC2434]で定義されている手順に従って、SCTPポート割り当て要求を評価する際にIANAをサポートします。
Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered.
ポート番号は3つの範囲に分けられます。 Well Knownポートは0〜1023のポートであり、Registeredポートは1024〜49151のポートであり、Dynamicおよび/またはPrivateポートは49152〜65535のポートです。WellKnownポートおよびRegisteredポートは、サーバーアプリケーションでの使用を目的としています。システムのデフォルトの連絡先。ほとんどのシステムでは、既知のポートはシステム（またはルート）プロセスまたは特権ユーザーが実行するプログラムでのみ使用できますが、登録済みポートは通常のユーザープロセスまたは通常のユーザーが実行するプログラムで使用できます。動的ポートおよび/またはプライベートポートは、クライアント側ポート、アウトオブバンドネゴシエーションポート、専用ポートの登録前のアプリケーションテストなど、一時的な使用を目的としています。登録してはなりません。
The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use an SCTP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible.
ポート番号レジストリは、既知のポートと登録済みポートの範囲のSCTPポートの登録を受け入れる必要があります。 よく知られた登録済みのポートは、登録なしで使用しないでください。 TCPからSCTPへのアプリケーションの移植など、場合によっては、登録が完了する前にSCTPポートを使用するのが自然に思えるかもしれませんが、IANAは特定の既知の登録済みポートの登録を保証しないことを強調します。 登録はできるだけ早くリクエストする必要があります。
Each port registration SHALL include the following information:
各ポート登録には、以下の情報が含まれている必要があります。
o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes).
o 完全に文字（A-Zおよびa-z）、数字（0-9）、および「-_ +。/ *」からの句読文字（引用符は含まない）で構成される短いポート名。
o The port number that is requested for registration.
o 登録を要求されたポート番号。
o A short English phrase describing the port's purpose.
o 港の目的を説明する短い英語のフレーズ。
o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended.
o 登録を実行する人またはエンティティの名前と連絡先情報、および場合によってはポートの使用を定義するドキュメントへの参照。 IETFワーキンググループからの登録では、ワーキンググループに名前を付けるだけで済みますが、連絡先を示すことをお勧めします。
Registrants are encouraged to follow these guidelines when submitting a registration.
登録者は、登録を送信する際にこれらのガイドラインに従うことをお勧めします。
o A port name SHOULD NOT be registered for more than one SCTP port number.
o ポート名は複数のSCTPポート番号に登録されるべきではありません（SHOULDNOT）。
o A port name registered for TCP MAY be registered for SCTP as well. Any such registration SHOULD use the same port number as the existing TCP registration.
o TCPに登録されたポート名は、SCTPにも登録される場合があります。このような登録では、既存のTCP登録と同じポート番号を使用する必要があります（SHOULD）。
o Concrete intent to use a port SHOULD precede port registration. For example, existing TCP ports SHOULD NOT be registered in advance of any intent to use those ports for SCTP.
o ポートを使用する具体的な意図は、ポート登録の前にすべきです（SHOULD）。たとえば、既存のTCPポートは、SCTPにそれらのポートを使用する意図の前に登録してはなりません（SHOULD NOT）。
This document registers the following ports. (These registrations should be considered models to follow for future allocation requests.)
このドキュメントでは、次のポートを登録しています。 （これらの登録は、将来の割り当て要求に準拠するためのモデルと見なされます。）
discard 9/sctp Discard # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The discard service, which accepts SCTP connections on port 9, discards all incoming application data and sends no data in response. Thus, SCTP's discard port is analogous to TCP's discard port, and might be used to check the health of an SCTP stack.
ポート9でSCTP接続を受け入れる破棄サービスは、すべての着信アプリケーションデータを破棄し、応答としてデータを送信しません。したがって、SCTPの破棄ポートはTCPの破棄ポートに類似しており、SCTPスタックの状態をチェックするために使用される場合があります。
ftp-data 20/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ftp 21/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
File Transfer Protocol (FTP) data (20) and control ports (21).
ファイル転送プロトコル（FTP）データ（20）および制御ポート（21）。
ssh 22/sctp SSH # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The Secure Shell (SSH) remote login service, which allows secure shell logins to a host.
セキュアシェル（SSH）リモートログインサービス。ホストへのセキュアシェルログインを可能にします。
http 80/sctp HTTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over SCTP.
SCTP上のWorld Wide Web HTTP。
bgp 179/sctp BGP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
Border Gateway Protocol over SCTP.
SCTP上のボーダーゲートウェイプロトコル。
https 443/sctp HTTPS # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over TLS/SSL over SCTP.
SCTP上のTLS / SSL上のWorld Wide Web HTTP。
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10).
実装上の注意：SCTP実装により、ULPはこれらのプロトコルパラメータの一部をカスタマイズできる場合があります（セクション10を参照）。
Note: RTO.Min SHOULD be set as recommended above.
注：RTO.Minは上記の推奨値に設定する必要があります。
An undertaking represented by this updated document is not a small feat and represents the summation of the initial authors of RFC 2960: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.
この更新されたドキュメントで表される取り組みは小さな偉業ではなく、RFC 2960の最初の著者の要約を表しています。カラ、L。チャン、V。パクソン。
Add to that, the comments from everyone who contributed to the original RFC:
それに加えて、元のRFCに貢献したすべての人からのコメント：
Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their invaluable comments.
マークオールマン、R.J。アトキンソン、リチャードバンド、スコットブラドナー、スティーブベロビン、ピーターバトラー、ラムダントゥ、R。エジルパヴァイ、マイクフィスク、サリーフロイド、福本淳、マットホールドレゲ、ヘンリーハウ、クリスチャンウイテマ、ゲイリーレヘッカ、ジョナサンリー、デビッドリーマン、ジョンラフニー、Daniel Luan、Barry Nagelberg、Thomas Narten、Erik Nordmark、Lyndon Ong、Shyamal Prasad、Kelvin Porter、Heinz Prantner、Jarno Rajahalme、Raymond E. Reeves、Renee Revis、Ivan Arias Rodriguez、A.Sankar、Greg Sidebottom、Brian Wyld、ラモンテヤロール、その他多くの貴重なコメント。
Then, add the authors of the SCTP implementor's guide, I. Arias-Rodriguez, K. Poon, A. Caro, and M. Tuexen.
次に、SCTP実装者ガイドの作成者であるI. Arias-Rodriguez、K。Poon、A。Caro、およびM. Tuexenを追加します。
Then add to these the efforts of all the subsequent seven SCTP interoperability tests and those who commented on RFC 4460 as shown in its acknowledgements:
次に、後続の7つのSCTP相互運用性テストすべてと、その承認に示されているようにRFC 4460についてコメントした人たちの取り組みをこれらに追加します。
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
バリー・ズッカーマン、ラ・モンテ・ヤロール、チャオビン・シェ、ワン・シャオペン、ジョナサン・ウッド、ジェフ・ワスコウ、マイク・ターナー、ジョン・タウンゼンド、サビナ・トレンテ、クリフ・トーマス、スズキ・ユージ、マノジ・ソランキ、スヴェル・スロット、キール・シャー、ジャン・ロビンス、ベン・ロビンソン、レニーレヴィス、イアンペリアム、RCモニー、サンジャイラオ、スミスラダクリシュナン、ハインツプラント、バイレンパテル、ナタリームエリク、ミッチマイアーズ、バーンワードメイクネヒト、スタンマクレラン、オリバーマヨール、トマスオルティマーティン、サンディープマハジャン、デビッドリーマン、ジョナサンリー、フィリップ、カール・ナッツソン、ジョー・ケラー、ガレス・キーリー、アンドレアス・ジュングマイヤー、ジャナルダン・アイエンガー、ムツヤ・イリー、ジョン・ヒーバート、カウザー・ハッサン、フレッド・ハスル、ダン・ハリソン、ジョン・グリム、ローレント・グロード、スティーブン・ファーニス、福本淳、藤田健、スティーブ・ディミグ、トーマスカラン、セルカンシル、メリッサキャンベル、ピーターバトラー、ロブブレナン、ハーシュボンドウェ、ブライアンビデュロック、ケイトリンベストラー、ジョンバーガー、ロビーベネディク、スティーブンバウケ、サンディープバラニ、ロニーセラー。
A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.
Mark Allmanに特に感謝します。MarkAllmanは、実際にはmax-burstに関する彼の研究の共著者であるはずですが、専門性のためになんとか揺れ動きました。また、Lyndon OngとPhil Conradの貴重な意見と多くの貢献に謝意を表します。
And finally, you have this document, and those who have commented upon that including Alfred Hoenes and Ronnie Sellars.
そして最後に、あなたはこの文書を持っています、そしてアルフレッド・ホーネスとロニー・セラーズを含むそれにそれをコメントした人々があります。
My thanks cannot be adequately expressed to all of you who have participated in the coding, testing, and updating process of this document. All I can say is, Thank You!
このドキュメントのコーディング、テスト、更新のプロセスに参加していただいたすべての方に、感謝の気持ちを表すことはできません。私が言えることは、ありがとうございます！
Randall Stewart - Editor
Randall Stewart-エディター
ECN [RFC3168] describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general, [RFC3168] should be followed with the following exceptions.
ECN [RFC3168]は、IPへの提案された拡張について説明しており、データグラムの損失以外に輻輳を認識できるようにする方法を詳しく説明しています。これは、実装がSCTPに追加することを選択できるオプション機能です。この付録では、実装者がこの機能を実装することを選択した場合に知っておく必要がある小さな違いについて詳しく説明します。一般に、[RFC3168]は以下の例外を除いて従うべきです。
Negotiation:
Negotiation:
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets 2 bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to ensure that both sides are truly ECN capable. For SCTP, this is not necessary. To indicate that an endpoint is ECN capable, an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus has the following format:
[RFC3168]は、TCP接続のSYNおよびSYN-ACKステージ中のECNのネゴシエーションについて詳しく説明しています。 SYNの送信側はTCPフラグに2ビットを設定し、SYN-ACKの送信側は1ビットのみを設定します。この背後にある理由は、両側が本当にECNに対応できるようにするためです。 SCTPの場合、これは必要ありません。エンドポイントがECN対応であることを示すために、エンドポイントはECN用に予約されたTLVをINITまたはINIT ACKチャンクに追加する必要があります（SHOULD）。このTLVにはパラメーターが含まれていないため、次の形式になります。
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 = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo:
ECN-Echo：
[RFC3168] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP, this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e., the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows:
[RFC3168]は、ネットワークから到着したCongestion Experienced（CE）ビットを送信者に通知するために、TCP確認応答で受信者が送信する特定のビットの詳細を示します。 SCTPの場合、ECNEチャンクを含めることでこれと同じ指示が行われます。このチャンクには1つのデータ要素、つまり、CEビットでマークされたIPデータグラムに関連付けられた最小のTSNが含まれ、次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk.
注：ECNEは制御チャンクと見なされます。
CWR:
CWR：
[RFC3168] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window. This is termed the CWR bit. For SCTP, the same indication is made by including the CWR chunk. This chunk contains one data element, i.e., the TSN number that was sent in the ECNE chunk. This element represents the lowest TSN number in the datagram that was originally marked with the CE bit.
[RFC3168]は、次の発信TCPセグメントのヘッダーで送信者が送信する特定のビットの詳細を示し、輻輳ウィンドウが減少したことをピアに示します。これはCWRビットと呼ばれます。 SCTPの場合、CWRチャンクを含めることによって同じ指示が行われます。このチャンクには、1つのデータ要素、つまりECNEチャンクで送信されたTSN番号が含まれています。この要素は、CEビットで最初にマークされたデータグラムの最小TSN番号を表します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=13 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The CWR is considered a Control chunk.
注：CWRは制御チャンクと見なされます。
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy Check) is calculated as described for CRC32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+ x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport-level usage.
「反映された値」を、マシンの通常のビット順序とは逆の値として定義します。 32ビットCRC（巡回冗長検査）はCRC32cの説明に従って計算され、多項式コード0x11EDC6F41（Castagnoli93）またはx ^ 32 + x ^ 28 + x ^ 27 + x ^ 26 + x ^ 25 + x ^ 23 +を使用しますx ^ 22 + x ^ 20 + x ^ 19 + x ^ 18 + x ^ 14 + x ^ 13 + x ^ 11 + x ^ 10 + x ^ 9 + x ^ 8 + x ^ 6 + x ^ 0。 CRCは、トランスポートレベルの使用を反映するように変更された、ETHERNET CRC [ITU32]と同様の手順を使用して計算されます。
CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic.
CRC計算は多項式除算を使用します。メッセージのビット文字列Mは多項式M（X）に変換され、CRは多項式演算を使用してM（X）から計算されます。
When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high-order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders.
CRCがリンク層で使用される場合、多項式はオンザワイヤーのビット順序から導出されます。「ワイヤー上の」最初のビットは高次係数です。 SCTPはトランスポートレベルのプロトコルであるため、実際のシリアルメディアのビット順序を知ることはできません。さらに、SCTPエンドポイント間のパス内の異なるリンクは、異なるリンクレベルのビットオーダーを使用する場合があります。
A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit-ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first, but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most-significant polynomial coefficient within that byte, and the most-significant SCTP bit is the least-significant polynomial coefficient in that byte. (This bit ordering is sometimes called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed back into SCTP transport-level byte values, using a consistent mapping.
したがって、CRC計算のためにSCTPトランスポートメッセージを多項式にマッピングするための規則を確立する必要があります。 SCTPメッセージを多項式にマッピングするためのビットの順序付けでは、バイトが最初に最上位に取られますが、各バイト内では、ビットは最初に最下位に取られます。メッセージの最初のバイトは、8つの最も高い係数を提供します。各バイト内で、最下位のSCTPビットはそのバイト内の最上位の多項式係数を示し、最上位のSCTPビットはそのバイト内の最下位の多項式係数です。 （このビット順序は、「ミラーリング」または「反射」と呼ばれることもあります。[WILLIAMS93]）CRC多項式は、一貫したマッピングを使用して、SCTPトランスポートレベルのバイト値に変換し直されます。
The SCTP transport-level CRC value should be calculated as follows:
SCTPトランスポートレベルのCRC値は、次のように計算する必要があります。
- CRC input data are assigned to a byte stream, numbered from 0 to N-1.
- CRC入力データは、0からN-1までの番号が付けられたバイトストリームに割り当てられます。
- The transport-level byte stream is mapped to a polynomial value. An N-byte PDU with j bytes numbered 0 to N-1 is considered as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being coefficient x^(8(N-j)-1).
- トランスポートレベルのバイトストリームは、多項式値にマッピングされます。 0からN-1の番号が付けられたjバイトのNバイトPDUは、次数8N-1の多項式M（x）の係数と見なされます。バイトjのビット0は係数x ^（8（Nj）-8）です。バイトjのビット7は係数x ^（8（Nj）-1）です。
- The CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial.
- CRC剰余レジスタはすべて1で初期化され、CRCは同時にx ^ 32を乗算してCRC多項式で除算するアルゴリズムで計算されます。
- The polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, producing a remainder R(x) of degree less than or equal to 31.
- 多項式はx ^ 32で乗算され、生成多項式であるG（x）で除算され、31以下の次数の剰余R（x）を生成します。
- The coefficients of R(x) are considered a 32-bit sequence.
- R（x）の係数は32ビットシーケンスと見なされます。
- The bit sequence is complemented. The result is the CRC polynomial.
- ビットシーケンスは補完されます。結果はCRC多項式です。
- The CRC polynomial is mapped back into SCTP transport-level bytes. The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, and the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3, and the coefficient of x^0 gives bit 0 of byte 3. The resulting 4-byte transport-level sequence is the 32-bit SCTP checksum value.
- CRC多項式は、SCTPトランスポートレベルのバイトにマッピングされます。係数x ^ 31はSCTPバイト0のビット7の値を与え、x ^ 24の係数はバイト0のビット0の値を与えます。x^ 7の係数はバイト3のビット7を与え、係数x ^ 0の値はバイト3のビット0になります。結果の4バイトのトランスポートレベルシーケンスは、32ビットのSCTPチェックサム値です。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified such that the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
実装上の注意：CRCに関する標準文書、教科書、およびベンダーの文献は、多くの場合、筆算アルゴリズムの余りを保持するために使用されるレジスタがすべて1ではなくゼロに初期化され、代わりに最初の32ビットに初期化される代替の定式化に従います。 メッセージの補足されます。 私たちの定式化で使用される筆算アルゴリズムは、2 ^ 32による最初の乗算と筆算が1つの同時演算に結合されるように指定されています。 このようなアルゴリズムの場合、および64ビットより長いメッセージの場合、2つの仕様はまったく同じです。 その同等性がこのドキュメントの目的です。
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long-division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits.
SCTPの実装者は、両方の仕様が文献に記載されており、場合によっては長分割アルゴリズムに制限がないことを警告しています。このドキュメントの定式化の選択は、SCTP以外の使用を許可することです。この場合、同じCRCアルゴリズムを使用して、64ビットより短いメッセージを保護できます。
There may be a computational advantage in validating the association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE ECHO. These special-case exchanges must represent small packets and will minimize the effect of the checksum calculation.
ほとんどの場合、無効なタグは不良チェックサムと同じアクションになるため、チェックサムを実行する前に、検証タグに対して関連付けを検証することには計算上の利点がある場合があります。 この手法の例外は、INITと一部のSHUTDOWN-COMPLETE交換、および古いCOOKIEECHOです。 これらの特殊なケースの交換は小さなパケットを表す必要があり、チェックサム計算の影響を最小限に抑えます。
Whenever an ICMP message is received by an SCTP endpoint, the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3.
ICMPメッセージがSCTPエンドポイントによって受信されるときはいつでも、レイヤー3によって提供されている情報の適切な利用を確実にするために、次の手順に従う必要があります。
ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable".
ICMP1）実装は、typeフィールドが "Destination Unreachable"に設定されていないすべてのICMPv4メッセージを無視してもよい（MAY）。
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big".
ICMP2）実装は、typeフィールドが「Destination Unreachable」、「Parameter Problem」、または「Packet Too Big」ではないすべてのICMPv6メッセージを無視してもよい（MAY）。
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）コードが「プロトコル到達不能」または「フラグメンテーションが必要」を示さない場合、実装はICMPv4メッセージを無視してもよい（MAY）。
ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized Next Header Type Encountered".
ICMP4）コードが「Unrecognized Next Header Type Encountered」でない場合、実装はタイプ「Parameter Problem」のすべてのICMPv6メッセージを無視してもよい（MAY）。
ICMP5) An implementation MUST use the payload of the ICMP message (v4 or v6) to locate the association that sent the message to which ICMP is responding. If the association cannot be found, an implementation SHOULD ignore the ICMP message.
ICMP5）実装は、ICMPメッセージ（v4またはv6）のペイロードを使用して、ICMPが応答しているメッセージを送信した関連付けを特定する必要があります。関連付けが見つからない場合、実装はICMPメッセージを無視する必要があります（SHOULD）。
ICMP6) An implementation MUST validate that the Verification Tag contained in the ICMP message matches the Verification Tag of the peer. If the Verification Tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the Initiate Tag matches the tag of the peer, continue with ICMP7. If the ICMP message is too short or the chunk type or the Initiate Tag does not match, silently discard the packet.
ICMP6）実装は、ICMPメッセージに含まれる検証タグがピアの検証タグと一致することを検証する必要があります。検証タグが0ではなく、一致しない場合は、ICMPメッセージを破棄します。それが0で、ICMPメッセージに十分なバイトが含まれていて、チャンクタイプがINITチャンクであり、開始タグがピアのタグと一致していることを確認する場合は、ICMP7に進みます。 ICMPメッセージが短すぎるか、チャンクのタイプまたは開始タグが一致しない場合は、暗黙的にパケットを破棄します。
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery.
ICMP7）ICMPメッセージがv6 "Packet Too Big"またはv4 "Fragmentation Needed"のいずれかである場合、実装は、PATH MTUディスカバリーに対して定義されているように、この情報を処理できます（MAY）。
ICMP8) If the ICMP code is an "Unrecognized Next Header Type Encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in the COOKIE-WAIT state, handle the ICMP message like an ABORT.
ICMP8）ICMPコードが「Unrecognized Next Header Type Encountered」または「Protocol Unreachable」である場合、INITチャンクが含まれていない場合、実装はこのメッセージをTビットが設定されたアボートとして処理する必要があります。 INITチャンクが含まれていて、関連付けがCOOKIE-WAIT状態にある場合は、ICMPメッセージをABORTのように処理します。
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）ICMPv6コードが「Destination Unreachable」の場合、実装は宛先を到達不能状態にマークするか、パスエラーカウンターをインクリメントできます（MAY）。
Note that these procedures differ from [RFC1122] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port-unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP.
これらの手順は、[RFC1122]およびポート到達不能メッセージの処理に関する要件と、「プロトコル到達不能」メッセージに応じて実装が関連付けを中止しなければならない（MUST）要件とは異なることに注意してください。実装はポート到達不能ではなくABORTを送信するため、ポート到達不能メッセージは処理されません。 「プロトコル到達不能」メッセージのより厳密な処理は、SCTPをサポートしていないホストのセキュリティ上の問題によるものです。
The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide. While neither especially slow nor especially fast, as software table-lookup CRCs go, it has the advantage of working on both big-endian and little-endian CPUs, using the same (host-order) lookup tables, and using only the predefined ntohl() and htonl() operations. The code is somewhat modified from [WILLIAMS93], to ensure portability between big-endian and little-endian architectures. (Note that if the byte endian-ness of the target architecture is known to be little-endian, the final bit-reversal and byte-reversal steps can be folded into a single operation.)
次の非規範的なサンプルコードは、「ミラーリング」を使用して、オープンソースのCRCジェネレーター[WILLIAMS93]から取得したものです。 テクニックと、それぞれ32ビット幅の256エントリを持つSCTPCRC32cのルックアップテーブルを生成します。 ソフトウェアテーブルルックアップCRCが進むにつれて、特に遅くも速くもありませんが、同じ（ホスト順序）ルックアップテーブルを使用し、事前定義されたntohlのみを使用して、ビッグエンディアンとリトルエンディアンの両方のCPUで動作するという利点があります。 （）およびhtonl（）操作。 コードは[WILLIAMS93]から多少変更されており、ビッグエンディアンアーキテクチャとリトルエンディアンアーキテクチャ間の移植性が確保されています。 （ターゲットアーキテクチャのバイトエンディアンがリトルエンディアンであることがわかっている場合は、最後のビット反転とバイト反転のステップを1つの操作に折りたたむことができることに注意してください。）
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
unsigned long型crc_c [256] = {0x00000000L、0xF26B8303L、0xE13B70F7L、0x1350F3F4L、0xC79A971FL、0x35F1141CL、0x26A1E7E8L、0xD4CA64EBL、0x8AD958CFL、0x78B2DBCCL、0x6BE22838L、0x9989AB3BL、0x4D43CFD0L、0xBF284CD3L、0xAC78BF27L、0x5E133C24L、0x105EC76FL、0xE235446CL、0xF165B798L、0x030E349BL、0xD7C45070L、 0x25AFD373L、0x36FF2087L、0xC494A384L、0x9A879FA0L、0x68EC1CA3L、0x7BBCEF57L、0x89D76C54L、0x5D1D08BFL、0xAF768BBCL、0xBC267848L、0x4E4DFB4BL、0x20BD8EDEL、0xD2D60DDDL、0xC186FE29L、0x33ED7D2AL、0xE72719C1L、0x154C9AC2L、0x061C6936L、0xF477EA35L、0xAA64D611L、0x580F5512L、0x4B5FA6E6L、0xB93425E5L、0x6DFE410EL、0x9F95C20DL、 0x8CC531F9L、0x7EAEB2FAL、0x30E349B1L、0xC288CAB2L、0xD1D83946L、0x23B3BA45L、
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0xF779DEAEL、0x05125DADL、0x1642AE59L、0xE4292D5AL、0xBA3A117EL、0x4851927DL、0x5B016189L、0xA96AE28AL、0x7DA08661L、0x8FCB0562L、0x9C9BF696L、0x6EF07595L、0x417B1DBCL、0xB3109EBFL、0xA0406D4BL、0x522BEE48L、0x86E18AA3L、0x748A09A0L、0x67DAFA54L、0x95B17957L、0xCBA24573L、0x39C9C670L、0x2A993584L、0xD8F2B687L、0x0C38D26CL、 0xFE53516FL、0xED03A29BL、0x1F682198L、0x5125DAD3L、0xA34E59D0L、0xB01EAA24L、0x42752927L、0x96BF4DCCL、0x64D4CECFL、0x77843D3BL、0x85EFBE38L、0xDBFC821CL、0x2997011FL、0x3AC7F2EBL、0xC8AC71E8L、0x1C661503L、0xEE0D9600L、0xFD5D65F4L、0x0F36E6F7L、0x61C69362L、0x93AD1061L、0x80FDE395L、0x72966096L、0xA65C047DL、0x5437877EL、 0x4767748AL、0xB50CF789L、0xEB1FCBADL、0x197448AEL、0x0A24BB5AL、0xF84F3859L、0x2C855CB2L、0xDEEEDFB1L、0xCDBE2C45L、0x3FD5AF46L、0x7198540DL、0x83F3D70EL、0x90A324FAL、0x62C8A7F9L、0xB602C312L、0x44694011L、0x5739B3E5L、0xA55230E6L、0xFB410CC2L、0x092A8FC1L、0x1A7A7C35L、0xE811FF36L、0x3CDB9BDDL、0xCEB018DEL、0xDDE0EB2AL、 0x2F8B6829L、0x82F63B78L、 0x709DB87BL、0x63CD4B8FL、0x91A6C88CL、0x456CAC67L、0xB7072F64L、0xA457DC90L、0x563C5F93L、0x082F63B7L、0xFA44E0B4L、0xE9141340L、0x1B7F9043L、0xCFB5F4A8L、0x3DDE77ABL、0x2E8E845FL、0xDCE5075CL、0x92A8FC17L、0x60C37F14L、0x73938CE0L、0x81F80FE3L、0x55326B08L、0xA759E80BL、0xB4091BFFL、0x466298FCL、0x1871A4D8L、0xEA1A27DBL、 0xF94AD42FL、0x0B21572CL、0xDFEB33C7L、0x2D80B0C4L、0x3ED04330L、0xCCBBC033L、0xA24BB5A6L、0x502036A5L、0x4370C551L、0xB11B4652L、0x65D122B9L、0x97BAA1BAL、0x84EA524EL、0x7681D14DL、0x2892ED69L、0xDAF96E6AL、0xC9A99D9EL、0x3BC21E9DL、0xEF087A76L、0x1D63F975L、0x0E330A81L、0xFC588982L、0xB21572C9L、0x407EF1CAL、0x532E023EL、 0xA145813DL、0x758FE5D6L、0x87E466D5L、0x94B49521L、0x66DF1622L、0x38CC2A06L、0xCAA7A905L、0xD9F75AF1L、0x2B9CD9F2L、0xFF56BD19L、0x0D3D3E1AL、0x1E6DCDEEL、0xEC064EEDL、0xC38D26C4L、0x31E6A5C7L、0x22B65633L、0xD0DDD530L、0x0417B1DBL、0xF67C32D8L、0xE52CC12CL、0x1747422FL、0x49547E0BL、0xBB3FFD08L、0xA86F0EFCL、0x5A048DFFL、 0x8ECEE914L、0x7CA56A17L 、0x6FF599E3L、0x9D9E1AE0L、0xD3D3E1ABL、0x21B862A8L、0x32E8915CL、0xC083125FL、0x144976B4L、0xE622F5B7L、0xF5720643L、0x07198540L、0x590AB964L、0xAB613A67L、0xB831C993L、0x4A5A4A90L、0x9E902E7BL、0x6CFBAD78L、0x7FAB5E8CL、0x8DC0DD8FL、0xE330A81AL、0x115B2B19L、0x020BD8EDL、0xF0605BEEL、0x24AA3F05L、0xD6C1BC06L、0xC5914FF2L 、0x37FACCF1L、0x69E9F0D5L、0x9B8273D6L、0x88D28022L、0x7AB90321L、0xAE7367CAL、0x5C18E4C9L、0x4F48173DL、0xBD23943EL、0xF36E6F75L、0x0125E51L76L0E05L76
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, };
0 x 4 x 4ポンド、0 x 1 x 1 xタマネギ、0 x 1 for 0、0 x 4 x 4623、0 x 5 for 0ライター、0 x 4 x 4623; 0 x 5 x 0ライター
#endif
#endif
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
rb = Reflect_32（インデックス）;
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
{
int i;
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
/* Example of crc insertion */
#include "crc32cr.h"
#include "crc32cr.h"
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
} int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
References
参考文献
Normative References
引用文献
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion".", ITU-T section 8.1.1.6.2.
[ITU32]「ITU-T勧告V.42、「非同期から同期への変換を使用したDCEのエラー修正手順」」、ITU-Tセクション8.1.1.6.2。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz、R。およびR. Bush、「Serial Number Arithmetic」、RFC 1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。、およびW. Stevens、「TCP Congestion Control」、RFC 2581、1999年4月。
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004.
[RFC3873]牧師、J。およびM. Belinchon、「ストリーム制御伝送プロトコル（SCTP）管理情報ベース（MIB）」、RFC 3873、2004年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、編、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
Informative References
参考引用
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5- 21, July 1996.
[FALL96]秋、K。およびS.フロイド、「シミュレーションに基づくタホ、リノ、およびSACK TCPの比較」、SIGCOMM'99 V. 26 N. 3 pp 5- 21、1996年7月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review 29(5), October 1999.
[SAVAGE99] Savage、S.、Cardwell、N.、Wetherall、D。、およびT. Anderson、「誤動作するレシーバーによるTCP輻輳制御」、ACM Computer Communications Review 29（5）、1999年10月。
[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM'99 , 1999.
[ALLMAN99] Allman、M。およびV. Paxson、「On-Estimating End-to-End Network Path Properties」、SIGCOMM'99、1999。
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS", Internet publication, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm, August 1993.
[WILLIAMS93]ウィリアムズR。、「CRCエラー検出アルゴリズムの無痛ガイド」、インターネット出版、http：//www.geocities.com/SiliconValley/Pines/ 8659 / crc.htm、1993年8月。
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
[RFC0813]クラークD。、「TCPにおけるウィンドウと確認応答の戦略」、RFC 813、1982年7月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティに関する考慮事項」、RFC 1858、1995年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser、B。、「Site Security Handbook」、FYI 8、RFC 2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R。、シェイ、Q。、モーノー、K。、シャープ、C。、シュワルツバウアー、H。、テイラー、T。、リティナ、I。、カラ、M。、チャン、L.、V 。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309] Stone、J.、Stewart、R。、およびD. Otis、「Stream Control Transmission Protocol（SCTP）Checksum Change」、RFC 3309、2002年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, April 2006.
[RFC4460] Stewart、R.、Arias-Rodriguez、I.、Poon、K.、Caro、A。、およびM. Tuexen、「Stream Control Transmission Protocol（SCTP）Specification Errata and Issues」、RFC 4460、2006年4月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895] Tuexen、M.、Stewart、R.、Lei、P。、およびE. Rescorla、「Authenticated Chunks for Stream Control Transmission Protocol（SCTP）」、RFC 4895、2007年8月。
Editor's Address
編集者の住所
Randall R. Stewart 4875 Forest Drive Suite 200 Columbia, SC 29206 US
ランドールR.スチュワート4875フォレストドライブスイート200コロンビア、SC 29206 US
EMail: rrs@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。