Network Working Group R. Stewart
Request for Comments: 2960 Q. Xie
Category: Standards Track Motorola
K. Morneault
C. Sharp
Cisco
H. Schwarzbauer
Siemens
T. Taylor
Nortel Networks
I. Rytina
Ericsson
M. Kalla
Telcordia
L. Zhang
UCLA
V. Paxson
ACIRI
October 2000
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications.
この文書では、ストリーム制御伝送プロトコル（SCTP）について説明します。 SCTPは、IPネットワーク上でシグナリングメッセージをPSTNを輸送するために設計されていますが、より広範なアプリケーションすることが可能です。
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 -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
オプションの単一SCTPパケットに複数のユーザメッセージのバンドル、および - - 支持介してネットワークレベルのフォールトトレランス - 個々のユーザメッセージの順序の到着送達するためのオプションを持つ複数のストリーム内のユーザメッセージの配列決定送達会合のいずれかまたは両方の端部でマルチホーミングの。
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.................................................. 6
1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP..................................... 7
1.3.1 Association Startup and Takedown........................ 8
1.3.2 Sequenced Delivery within Streams....................... 9
1.3.3 User Data Fragmentation................................. 9
1.3.4 Acknowledgement and Congestion Avoidance................ 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 Packet Validation....................................... 10
1.3.7 Path Management......................................... 11
1.4 Key Terms................................................... 11
1.5 Abbreviations............................................... 15
1.6 Serial Number Arithmetic.................................... 15
2. Conventions.................................................... 16
3. SCTP packet Format............................................ 16
3.1 SCTP Common Header Field Descriptions....................... 17
3.2 Chunk Field Descriptions.................................... 18
3.2.1 Optional/Variable-length Parameter Format............... 20
3.3 SCTP Chunk Definitions...................................... 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable Length Parameters.............. 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable Length Parameters.............. 33
3.3.4 Selective Acknowledgement (SACK)........................ 33
3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
3.3.7 Abort Association (ABORT)............................... 39
3.3.8 Shutdown Association (SHUTDOWN)......................... 40
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
3.3.10 Operation Error (ERROR)................................ 41
3.3.10.1 Invalid Stream Identifier.......................... 42
3.3.10.2 Missing Mandatory Parameter........................ 43
3.3.10.3 Stale Cookie Error................................. 43
3.3.10.4 Out of Resource.................................... 44
3.3.10.5 Unresolvable Address............................... 44
3.3.10.6 Unrecognized Chunk Type............................ 44
3.3.10.7 Invalid Mandatory Parameter........................ 45
3.3.10.8 Unrecognized Parameters............................ 45
3.3.10.9 No User Data....................................... 46
3.3.10.10 Cookie Received While Shutting Down............... 46
3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
4. SCTP Association State Diagram................................. 48
5. Association Initialization..................................... 52
5.1 Normal Establishment of an Association...................... 52
5.1.1 Handle Stream Parameters................................ 54
5.1.2 Handle Address Parameters............................... 54
5.1.3 Generating State Cookie................................. 56
5.1.4 State Cookie Processing................................. 57
5.1.5 State Cookie Authentication............................. 57
5.1.6 An Example of Normal Association Establishment.......... 58
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK.............................................. 60
5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or COOKIE-ECHOED States................................. 60
5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
5.2.3 Unexpected INIT ACK..................................... 61
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
5.2.4.1 An Example of a Association Restart................. 64
5.2.5 Handle Duplicate COOKIE ACK............................. 66
5.2.6 Handle Stale COOKIE Error............................... 66
5.3 Other Initialization Issues................................. 67
5.3.1 Selection of Tag Value.................................. 67
6. User Data Transfer............................................. 67
6.1 Transmission of DATA Chunks................................. 69
6.2 Acknowledgement on Reception of DATA Chunks................. 70
6.2.1 Tracking Peer's Receive Buffer Space.................... 73
6.3 Management Retransmission Timer............................. 75
6.3.1 RTO Calculation......................................... 75
6.3.2 Retransmission Timer Rules.............................. 76
6.3.3 Handle T3-rtx Expiration................................ 77
6.4 Multi-homed SCTP Endpoints.................................. 78
6.4.1 Failover from Inactive Destination Address.............. 79
6.5 Stream Identifier and Stream Sequence Number................ 80
6.6 Ordered and Unordered Delivery.............................. 80
6.7 Report Gaps in Received DATA TSNs........................... 81
6.8 Adler-32 Checksum Calculation............................... 82
6.9 Fragmentation............................................... 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP Congestion Control................ 85
7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
7.2.1 Slow-Start.............................................. 87
7.2.2 Congestion Avoidance.................................... 89
7.2.3 Congestion Control...................................... 89
7.2.4 Fast Retransmit on Gap Reports.......................... 90
7.3 Path MTU Discovery.......................................... 91
8. Fault Management.............................................. 92
8.1 Endpoint Failure Detection.................................. 92
8.2 Path Failure Detection...................................... 92
8.3 Path Heartbeat.............................................. 93
8.4 Handle "Out of the blue" Packets............................ 95
8.5 Verification Tag............................................ 96
8.5.1 Exceptions in Verification Tag Rules.................... 97
9. Termination of Association..................................... 98
9.1 Abort of an Association..................................... 98
9.2 Shutdown of an Association.................................. 98
10. Interface with Upper Layer....................................101
10.1 ULP-to-SCTP................................................101
10.2 SCTP-to-ULP................................................111
11. Security Considerations.......................................114
11.1 Security Objectives........................................114
11.2 SCTP Responses To Potential Threats........................115
11.2.1 Countering Insider Attacks.............................115
11.2.2 Protecting against Data Corruption in the Network......115
11.2.3 Protecting Confidentiality.............................115
11.2.4 Protecting against Blind Denial of Service Attacks.....116
11.2.4.1 Flooding...........................................116
11.2.4.2 Blind Masquerade...................................118
11.2.4.3 Improper Monopolization of Services................118
11.3 Protection against Fraud and Repudiation...................119
12. Recommended Transmission Control Block (TCB) Parameters.......120
12.1 Parameters necessary for the SCTP instance.................120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport Address Data.................................122
12.4 General Parameters Needed..................................123
13. IANA Considerations...........................................123
13.1 IETF-defined Chunk Extension...............................123
13.2 IETF-defined Chunk Parameter Extension.....................124
13.3 IETF-defined Additional Error Causes.......................124
13.4 Payload Protocol Identifiers...............................125
14. Suggested SCTP Protocol Parameter Values......................125
15. Acknowledgements..............................................126
16. Authors' Addresses............................................126
17. References....................................................128
18. Bibliography..................................................129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
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）、それが提供するサービス、およびプロトコルの詳細な説明を理解するために必要な基本的な概念の発展の背後にある理由を説明しています。
TCP [RFC793] 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 [RFC768]. The limitations which users have wished to bypass include the following:
TCP [RFC793] IPネットワークにおける信頼性の高いデータ転送の主要な手段として巨大サービスを行いました。しかし、最近のアプリケーションの増加数はTCPがあまりにも制限を発見した、とUDP [RFC768]の上に、独自の信頼性の高いデータ転送プロトコルが組み込まれています。ユーザーがバイパスに願っている制限事項は、次のものがあります。
-- 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 which 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.4) to provide the other endpoint
SCTPはコネクション指向の性質であるが、SCTPアソシエーションはTCPコネクションよりも広い概念です。 SCTPは、他のエンドポイントを提供するために、各SCTPエンドポイント（1.4節）ための手段を提供します
(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 which may be generated from each endpoint's lists.
トランスポート・アドレスのリストを（関連の起動時）（すなわち、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協会
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内のプリミティブ）を関連付けるの説明を参照してください（またはSEND）。
A cookie mechanism, similar to one described by Karn and Simpson in [RFC2522], is employed during the initialization to provide protection against security 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]でカーンとシンプソンによって記載したものと同様のクッキー機構は、セキュリティ攻撃に対する保護を提供するために、初期化中に使用されます。クッキーメカニズムは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ユーザからのリクエストに応じてアクティブ・アソシエーションの優雅近い（すなわち、シャットダウン）を提供します。また無様な（すなわち、中断）、いずれかのユーザからの要求に近い（プリミティブABORT）又はSCTP層内で検出されたエラー状態の結果としての可能セクション10 SCTPにおけるプリミティブSHUTDOWNの説明を参照してください。第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 eight bits).
用語「流れ」は、同じストリーム内の他のメッセージに対して順番に上位層プロトコルに配信されるユーザメッセージの配列を指すためにSCTPで用いられます。これは、バイトの配列（本書ではバイトは8ビットであると仮定される）を意味するTCP、その使用とは対照的です。
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項を参照）と交渉しています。ユーザのメッセージは（セクション10、プリミティブを受信し、SEND）ストリーム番号に関連付けられています。内部的には、SCTPはSCTPユーザによって渡された各メッセージにストリーム・シーケンス番号を割り当てます。受信側では、SCTPメッセージが与えられたストリーム内の配列にSCTPユーザに配信されることを保証します。一つのストリームが次にシーケンスユーザメッセージを待ってブロックされるかもしれないが、他のストリームからの送達が進行してもよいです。
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 Sections 6 and 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 messages 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パケットは、一つ以上のチャンクに続く共通ヘッダから成ります。各チャンクは、ユーザデータ又はSCTP制御情報のいずれかを含むことができます。 SCTPユーザは、単一の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をバンドルしていないことを要求した場合でも、バンドルを実行するかもしれません。同梱のユーザーの無効化が唯一の送信前の時間の小さな期間を遅らせる可能性がSCTPの実装に影響を与えます（バンドル奨励しようとします）。ユーザ層がバンドリングを無効にしたときに、この小さな遅延が禁止されているが、それを束ねていないが、輻輳又は再送信の間に行われます。
A mandatory Verification Tag field and a 32 bit checksum field (see Appendix B for a description of the Adler-32 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 Adler-32 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 Adler-32 checksum silently discards the packet.
必須の検証タグフィールドと32ビットのチェックサムフィールドは、（アドラー-32チェックサムの説明については、付録Bを参照）SCTP共通ヘッダに含まれています。検証タグ値は、協会の起動時に協会のそれぞれの端部によって選択されます。予想される検証タグ値なしで受信されたパケットは、ブラインドマスカレード攻撃に対する防御として、前の協会からの古いSCTPパケットに対して、破棄されます。アドラー-32チェックサムは、ネットワーク内のデータ破損に対する追加の保護を提供するために、各SCTPパケットの送信者によって設定されるべきです。無効アドラー-32チェックサムとの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ユーザは、SCTPパス管理機能は、SCTPユーザの指示に基づいて各発信SCTPパケットの宛先トランスポート・アドレスを選択し、セクション10に記載プリミティブを通じてSCTPパケットの宛先として使用されるトランスポート・アドレスのセットを操作することが可能です現在、適格な宛先セットの到達可能性ステータスを感じました。他のパケットトラフィックがこの情報を提供するには不十分であり、任意の遠端トランスポートアドレスの変更の際に到達可能SCTPユーザに通知する際に、パス管理機能は、ハートビートを介して到達可能性を監視します。パス管理機能も協会の起動時に遠端にローカルトランスポートアドレスの適格なセットを報告するための、およびトランスポート・アドレスは、SCTPユーザに遠端から戻って報告する責任があります。
At association start-up, 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.
注：別々に上述したが、実際にはそれらは別々のアイテムとして行うことができないので、パス管理とパケット検証は、同時に行われます。
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 which 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パケットに実施することができることにより、任意の多重化動作。各ユーザーのメッセージは、独自のデータチャンクを占めています。
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をポイント：最後のDATAチャンクのTSNはSACKの累積TSN ACKフィールドを経由して認めました。
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 which 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 the message was sent on.
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（および関連するデータチャンク）。
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パス：ピアSCTPエンドポイントの特定の宛先トランスポートアドレス1つの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を）の現在のアクティブセットを含むプロトコル状態情報との間のプロトコルの関係等関連一意に使用されるトランスポート・アドレスによって同定することができます協会内のエンドポイントによって。二つの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制御チャンク、及びユーザデータを含みます。
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 which 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 uni-directional 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エンドポイント、1つの確立された単方向の論理チャネル。
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 assure 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: Verification Tags from a previous association. These Tags are used within a State Cookie so that the newly restarting association can be linked to the original association within the endpoint that did not restart.
以前の関連付けから検証タグ：タイタグO。新しく再起動する関連付けが再起動していないエンドポイント内の元組合にリンクすることができるように、これらのタグは、国家クッキー内で使用されています。
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ビットのシーケンス番号。一つのTSNは、その受領を確認し、重複配達を検出するために、受信したSCTP終点を可能にするために、ユーザー・データを含む各チャンクに取り付けられています。
o Transport address: A Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and 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トランスポートアドレス：トランスポート・アドレスは伝統的にネットワーク層アドレス、トランスポート層プロトコルおよびトランスポート層のポート番号によって定義されます。 SCTPは、IP上で動作する場合には、トランスポートアドレスはIPアドレス及び（SCTPトランスポートプロトコルである）SCTPポート番号の組み合わせで定義されています。
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) which 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.
（SCTPエンドポイントで）O未確認TSN：エンドポイントではなく、肯定応答がまだ送信されていないために受信されたTSN（および関連するデータチャンク）。あるいは逆の場合は、送られてきたが、確認応答を受信していないパケットのため。
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. 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 Time-out
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-値コーディングフォーマット
TSN - Transmission Sequence Number
TSN - 送信シーケンス番号
ULP - Upper-layer Protocol
ULP - 上位層プロトコル
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).
非常に大きいけれども実際の送信シーケンス番号空間が有限であることを覚えておくことが不可欠です。 1.スペースが有限であるため、伝送シーケンス番号を扱う全ての演算がモジュロ2 ** 32を実行しなければならない - この空間は0から2 ** 32の範囲です。再び1 0 - この符号なしの算術演算は、2 ** 32から彼らサイクルとしてシーケンス番号の関係を維持します。いくつかの微妙なので、細心の注意がこのような値の比較をプログラミングに注意する必要があり、コンピュータのモジュロ演算にあります。 TSNを、記号「= <」に言及するとき（モジュロ2 ** 32）「以下」を意味します。
Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
[RFC1982]ここでSERIAL_BITS = 32で定義されるように、この文書に記載されているのTSNに比較演算は、シリアル番号演算を使用すべきです。
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上記1 - エンドポイントは、2 ** 31以上であるTSNを持つデータチャンクを送信すべきではありません。そうすることの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 TSN = 0 - 1であることを、次のTSNがDATAチャンクがTSN = 2 * 32を送信した後に使用しなければなりません。
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
[RFC1982]ここでSERIAL_BITS = 16で定義されているストリームのシーケンス番号に行わ任意算術シリアル番号演算を使用すべきです。
All other arithmetic and comparisons in this document uses normal arithmetic.
この文書に記載されているその他のすべての算術比較は通常の算術演算を使用しています。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、、推奨MAY、およびオプションではない、推奨すべきでないないものとものとしてはなりませんしなければなりません。
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.
これは、SCTP送信者のポート番号です。このパケットが属する関連付けを識別するために、送信元IPアドレス、SCTP宛先ポート及びおそらくは宛先IPアドレスと組み合わせて、受信機で使用することができます。
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.
これは、このパケットの宛先されているSCTPポート番号です。受信ホストは、正しい受信エンドポイント/アプリケーションにSCTPパケットを逆多重化するために、このポート番号を使用します。
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. - 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. - A packet containing an ABORT chunk may have the verification tag copied from the packet which caused the ABORT to be sent. For details see Section 8.4 and 8.5.
- INITチャンクを含むパケットはゼロ検証タグを持たなければなりません。 - TビットセットでSHUTDOWN-COMPLETEチャンクを含むパケットは、SHUTDOWN-ACKチャンクを持つパケットからコピーされた検証タグを持たなければなりません。 - 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 Adler-
32 algorithm as described in Appendix B for calculating the
checksum
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から255の値は、拡張フィールドとして将来の使用のために予約されている254の値をとります。
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 - reserved by IETF 63 - IETF-defined Chunk Extensions 64 to 126 - reserved by IETF 127 - IETF-defined Chunk Extensions 128 to 190 - reserved by IETF 191 - IETF-defined Chunk Extensions 192 to 254 - reserved by IETF 255 - IETF-defined Chunk Extensions
14 - シャットダウン完了（SHUTDOWN COMPLETE）15 62 - IETF 63によって予約 - IETF定義のチャンク拡張64 126に - IETF 127によって予約 - IETF定義のチャンクExtensionsが190から128 - IETF 191によって予約 - IETF定義のチャンク拡張IETF 255によって予約 - - 254から192 IETF定義のチャンクの拡張機能
Chunk Types are encoded such that the highest-order two 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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01 - このSCTPパケットの処理を停止し、それを破棄し、その内の任意の更なるチャンクを処理し、（ERRORのいずれかまたはINIT ACKで）「認識できないパラメータ型」で認識されていないパラメータを報告しません。
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).
注意：ECNEとCWRチャンクタイプは、明示的輻輳通知（ECN）を将来の使用のために予約されています。
Chunk Flags: 8 bits
チャンクフラグ：8ビット
The usage of these bits depends on the chunk type as given by the Chunk Type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt.
チャンクタイプによって与えられるように、これらのビットの使用は、チャンクタイプに依存します。特に指定しない限り、彼らは、送信時にゼロに設定され、領収書の上で無視されます。
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 padding.
この値は、チャンクタイプ、チャンクフラグ、チャンク長、およびチャンク値フィールドを含むバイト単位のチャンクのサイズを表します。チャンク値フィールドが長さゼロの場合はそのため、長さフィールドは、任意のパディングをカウントされません4.チャンク長フィールドに設定されます。
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 should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
（タイプ、長さおよび値フィールドを含む）のチャンクの合計長さが4バイトの倍数でなければなりません。チャンクの長さが4バイトの倍数でない場合、送信者MUSTパッドは全てゼロバイトのチャンクと、このパディングは、チャンク長フィールドに含まれていません。送信者は、以上の3バイトのパッドありません。受信機は、パディングバイトを無視しなければなりません。
SCTP defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 13.1 of this document.
SCTP定義されたチャンクは、セクション3.3に詳細に記載されています。 IETF定義のチャンクの拡張のためのガイドラインは、このドキュメントのセクション13.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 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ビットの識別子です。これは、65534から0の値をとります。
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk description 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 SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
（タイプ、パラメータ長および値フィールドを含む）パラメータの合計長さが4バイトの倍数でなければなりません。パラメータの長さが4バイトの倍数でない場合、すべてのゼロバイトの送信元パッド端におけるパラメータ（すなわち、パラメータ値フィールドの後）。詰め物の長さはパラメータ長フィールドに含まれていません。送信者は、以上の3バイトのパッドべきではありません。受信機は、パディングバイトを無視しなければなりません。
The Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter 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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01 - このSCTPパケットの処理を停止し、それを破棄し、その内の任意の更なるチャンクを処理し、（ERRORのいずれかまたはINIT ACKで）「認識できないパラメータ型」で認識されていないパラメータを報告しません。
10 - Skip this parameter and continue processing.
10 - このパラメータをスキップして、処理を続行。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11 - このパラメータをスキップして、処理を続行しますが（ERRORのいずれかまたはINIT ACKで）「認識できないパラメータ型」で認識されていないパラメータを報告しています。
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2.
実際のSCTPパラメータは、特定のSCTPチャンクセクションで定義されています。 IETF定義のパラメータの拡張のための規則は、13.2節で定義されています。
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）norderedビット、「1」に設定されている場合、これは非順序DATAチャンクであることを示し、このデータチャンクに割り当てられたストリームのシーケンス番号がありません。そのため、受信機はストリームシーケンス番号フィールドを無視しなければなりません。
After re-assembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to re-order.
再アセンブリ（必要な場合）の後に、無秩序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）eginningフラグメントビットは、設定されている場合、ユーザ・メッセージの最初のフラグメントを示します。
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:
断片化されていないユーザメッセージが「1」にセットBとEビットの両方を持たなければなりません。以下の表にまとめたように「0」にBとEビットの両方を設定すると、マルチ断片ユーザメッセージの中央断片を示します。
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 no user data field will have Length set to 16 (indicating 16 bytes).
このフィールドは、任意のパディングを除いたユーザデータフィールドの最後にタイプフィールドの先頭からのバイトのデータチャンクの長さを示します。ユーザデータフィールドを有するデータチャンクは16に設定された長さ（16のバイトを表す）を有するであろう。
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.
この値は、このデータチャンクのTSNを表します。 TSNの有効範囲は0から4294967295（ - 1 2 ** 32）です。 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.
この値は、0〜65535であるストリームS.有効範囲内の次のユーザデータのストリームシーケンス番号を表します。
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 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).
この値は、アプリケーション（上層）指定されたプロトコル識別子を表します。この値は、上位層によってSCTPに渡され、そのピアに送信されます。この識別子は、SCTPによって使用されていないが、このデータチャンクに運ばれる情報の種類を識別するために、特定のネットワークエンティティ、ならびにピアアプリケーションで使用することができます。このフィールドは、（必ず、それがネットワークの途中でエージェントに利用できるようにするために）も、断片化されたデータのチャンクで送信する必要があります。
The value 0 indicates 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.
これは、ペイロードのユーザデータです。実施MUSTパッドすべてゼロバイトの4バイト境界へのデータの終わり。任意のパディングは長さフィールドに含んではいけません。送信者は、パディングの3つの以上のバイトを追加してはなりません。
This chunk is used to initiate a 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チャンクに含まれなければなりません。
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可能フィールドは、明示的輻輳通知の将来の使用のために予約されています。
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でのホスト名のアドレスを他のアドレスタイプを組み合わせるてはなりません。ホスト名アドレスパラメータは、受信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：このパラメータは、存在する場合、送信エンドポイントがサポートできるすべてのアドレスの種類を指定します。このパラメータが存在しない場合は、送信側エンドポイントが任意のアドレスタイプをサポートできることを示しています。
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（応答側）の受信機は、タグの開始パラメータの値を記録します。この値は、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チャンクで開始タグの値が0であることが見出された場合、受信機は、エラーとして扱い、ABORTを送信することにより関連付けを閉じる必要があります。
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.
注：0に設定OS値とINITの受信機は、関連付けを中止すべきです。
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つのエンドポイントは、（提供要求）分を使用します。詳細については、セクション5.1.1を参照してください。
Note: A receiver of an INIT with the MIS value of 0 SHOULD abort the association.
注：0のMIS値とINITの受信機は、関連付けを中止すべきです。
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です。
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で定義されるように、以下のパラメータは、タイプレングス値の形式に従います。任意のタイプレングス値フィールドは、前のセクションで定義された固定長フィールドの後に来なければなりません。
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 bit (unsigned integer)
IPv6アドレス：128ビット（符号なし整数）
Contains an IPv6 address of the sending endpoint. It is binary encoded.
送信エンドポイントのIPv6アドレスが含まれています。これは、バイナリエンコードされています。
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373] but should instead use an IPv4 Address Parameter for an IPv4 address.
注意：送信者はIPv4射影IPv6アドレス[RFC2373]を使用してはならないが、代わりに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 lifetime 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データグラムの宛先アドレスとして使用することができます初期化。
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の送信者は、マルチホームされたときに複数のIPアドレスパラメータはINITチャンクに含めることができます。また、マルチホームエンドポイントが複数のアドレスの種類が1つのINITチャンクに存在することができ、したがって、ネットワークの異なるタイプへのアクセスを有していてもよく、すなわち、IPv4およびIPv6アドレスは同じINITチャンクで許可されています。
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は、INITを受信エンドポイントによって宛先として使用することができる少なくとも1つのIPアドレスパラメータ、INITチャンクとINIT内に設けられた追加のアドレスを含むIPデータグラムのソース・アドレスが含まれている場合。 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で任意のIPアドレスパラメータを使用し、INIT-ACKは、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の送信者は、国家クッキーの長寿命のために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)
提案クッキーライフスパンインクリメント：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.
このパラメータは、送信者がデフォルトのクッキーの寿命に追加するために受信機を望んでどのくらいの増分ミリ秒単位で受信機に示します。
This optional parameter should be added to the INIT chunk by the sender when it re-attempts 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.
このオプションのパラメータが原因失効クッキー操作エラーに関連付けを確立する以前の試みが失敗したピアとのアソシエーションを確立する試行を再送信者によってINITチャンクに追加されるべきです。受信機は、独自のセキュリティ上の理由のために提案されたクッキー寿命の増加を無視することを選択するかもしれません。
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 RFC1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP.
このフィールドは、RFC1123のセクション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, Hostname = 11).
これは、対応するアドレスTLV（例えば、= 5のIPv4、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:
INIT ACKのパラメータの一部は、INITチャンクと同様にフォーマットされます。州Cookieと認識されないパラメータ：それは2つの余分な変数のパラメータを使用します。
The format of the INIT ACK chunk is shown below:
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の受信機は、開始タグのパラメータの値を記録します。この値は、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 treat it as an error and close the association by transmitting an ABORT.
受信したINIT ACKチャンク内の開始タグの値が0であることが見出された場合、受信機は、エラーとして扱い、ABORTを送信することにより関連付けを閉じる必要があります。
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.
このINIT ACKチャンクの送信者がこの協会で作成したいのアウトバウンドストリームの数を定義します。 0の値を使用してはいけません。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
注：0に設定OS値とINIT ACKの受信機は、そのTCBを破棄会合を破壊するべきです。
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つのエンドポイントは、（提供要求）分を使用します。詳細については、セクション5.1.1を参照してください。
Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB.
注：0に設定MIS値とINIT ACKの受信機は、そのTCBを破棄会合を破壊するべきです。
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です。
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 Parameters 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可能フィールドは、明示的輻輳通知の将来の使用のために予約されています。
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でのホスト名のアドレスを他のアドレスタイプを組み合わせるてはなりません。ホスト名のアドレスパラメータが存在する場合INIT ACKの受信機は、他のアドレスの種類を無視しなければなりません。
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a 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.
実装上の注意：実装が原因の状態クッキーの可変サイズと可変アドレス一覧にかなり大きいのINIT ACK（以上1500バイト）を受け取るように準備しなければなりません。 INITへの応答が1000のIPv4は、それが送信したいアドレスを持っている場合たとえば、それはINIT ACKでこれをエンコードするために、少なくとも8,000バイトが必要になります。
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 lifetime 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内に設けられINIT ACK及び任意の追加のアドレスを含むIPデータグラムのソースアドレスは、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.
セクション3.2.1で定義され、以下に記載されるような状態クッキーと認識されていないパラメータなType-Length-Valueのフォーマットを使用します。他のフィールドは、INITチャンクでの対応と同じように定義されています。
State Cookie
状態クッキー
Parameter Type Value: 7
パラメータタイプ値：7
Parameter Length: variable size, depending on Size of 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.
このパラメータの値は、メッセージ認証コード（MAC）と共に、関連付けを作成するには、このINIT ACKの送信者のために必要なすべての状態とパラメータ情報を含まなければなりません。状態クッキーの定義の詳細については、セクション5.1.3を参照してください。
Unrecognized Parameters:
認識できないパラメータ：
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 which has a value that indicates that 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.
このチャンクは、受信したデータチャンクを確認し、それらのTSNによって示されるように、データチャンクの受信サブシーケンスのギャップのピアエンドポイントに知らせるためにピアエンドポイントに送信されます。
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters.
SACKは累積TSN ACKおよびアドバタイズ受信ウィンドウクレジット（a_rwnd）パラメータを含まなければなりません。
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もゼロ以上のギャップ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 zeros on transmit and ignored on receipt.
送信上のすべてゼロに設定して、領収書の上で無視。
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.
このパラメータは、ギャップの前に順番に受け取った最後のDATAチャンクのTSNが含まれています。
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.
ギャップAckブロックの数がこのSACKに含ま示します。
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はギャップAckブロックリスト以下のリストされている重複します。
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ブロックごとに繰り返されます。以上（累積TSNのAck +ギャップAckブロックスタート）に等しく、以下の各ギャップAckブロックの（累積TSNのAck +ギャップAckブロックエンド）に等しいTSNを有するすべてのデータチャンクが正しく受信されているものとします。
Gap Ack Block Start: 16 bits (unsigned integer)
ギャップAckブロックスタート：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)
ギャップAckブロック終了：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ブロックで受信した最後のデータチャンクのTSNを識別する。
For example, assume the receiver has the following DATA chunks newly arrived at the time when it decides to send a Selective ACK,
例えば、受信機は次のデータチャンクが新しく、それは選択的ACKを送信することを決定した時点で到着したと仮定し、
----------
| 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のパラメータの一部は、（送信者4660に設定されている新しいa_rwndを仮定して）以下のように構築されなければなりません。
+--------------------------------+
| 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 re-initialized to zero after sending each SACK.
最後のSACKが送信されたので、TSNが重複して受信された回数を示します。受信機は（SACKを送信する前に）重複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三回を取得した場合たとえば、それはアウトバウンドSACKで二回19をリストします。それはまだ1以上TSN 19を受け取った場合はSACKを送った後、それはかつて次の発信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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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).
送信者固有のハートビートInfoフィールドは、通常、送信者の現在のこのHEARTBEATチャンクが送信された時点と、このHEARTBEATが送られる先のトランスポートアドレス（セクション8.3を参照）に関する情報を含める必要があります。
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.
エンドポイントは、（8.3節を参照）HEARTBEATチャンクへの応答として、ピアエンドポイントにこのチャンクを送信する必要があります。 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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
Heartbeat Ack Length: 16 bits (unsigned integer)
ハートビートのAck長さ：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 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とバンドルしてはなりません。 （INIT、INIT ACK、シャットダウンCOMPLETEを除く）制御チャンクはABORTとバンドルされるかもしれないが、彼らはSCTPパケットにABORTの前に置かなければなりません、またはそれらは受信機によって無視されます。
If an endpoint receives an ABORT with a format error or for an association that doesn't exist, 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を受信した場合、それは静かにそれを捨てなければなりません。また、どのような状況の下で、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 had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
送信者は、それが破壊されていることTCBを持っていた場合はTビットが0に設定されています。送信者がTCBを持っていなかった場合には、このビットを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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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ブロックの欠如は、データ受信機は、関連するデータチャンクに破っていることを示しています。 SHUTDOWNはギャップAckブロックが含まれていないので、SHUTDOWNの受信機はrenegeとしてギャップAckブロックの欠如を解釈するべきではありません。 （renegingについては、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.
このチャンクは、詳細については、セクション9.2を参照してください、シャットダウンプロセスの完了時にSHUTDOWNチャンクの受信を確認するために使用しなければなりません。
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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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 3.2.1, i.e.:
エラー原因はすなわち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
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.
このフィールドには、エラー状態の詳細を運びます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1 - 3.3.10.10エラーがSCTPの原因を定義します。新しいエラー原因値を定義するために、IETFのためのガイドラインは、13.3節で議論されています。
Cause of error
---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk
sent to a nonexistent stream.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
エラーで受信したデータチャンクのストリーム識別子が含まれています。
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
欠落のparamsの数：32ビット（符号なし整数）
This field contains the number of parameters contained in the Cause-specific Information field.
このフィールドは、原因特定情報フィールドに含まれるパラメータの数が含まれています。
Missing Param Type: 16 bits (unsigned integer)
行方不明のParamタイプ：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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
このフィールドは、現在の時刻と状態クッキーの有効期限が切れた時間の間、マイクロ秒で、違いが含まれています。
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.
このエラーの原因の送信者は、どのくらい過去満了州クッキー報告することを選ぶかもしれ古フィールドの尺度でゼロ以外の値を含めることです。送信者がこの情報を提供したくない場合は、ゼロの値に古フィールドの尺度を設定する必要があります。
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
認識できないチャンクのフィールドは、チャンクタイプ、チャンクフラグとチャンク長との完全な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 a invalid value.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
認識できないパラメータフィールドはTLVとの完全なINIT ACKチャンクからコピーされた認識できないパラメータが含まれています。このエラーの原因は通常、COOKIE ECHOチャンクの送信者が認識できないパラメータを報告したい場合、INIT ACKに応答するときCOOKIE ECHOチャンクにバンドルERRORチャンクに含まれています。
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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値フィールドは、ユーザデータフィールドと、受信したデータチャンクの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 SHUTDOWN-ACK-SENT state. This error is
usually returned in an ERROR chunk bundled with the retransmitted
SHUTDOWN ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
このチャンクのみ関連の初期化中に使用されます。初期化プロセスを完了するために、そのピアに関連のイニシエータによって送信されます。この塊は協会内で送信されるデータチャンクを先行しなければなりませんが、同じパケット内の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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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: variable size
クッキー：可変サイズ
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
このフィールドは、前のINIT ACKから州Cookieパラメタで受信し、正確なクッキーが含まれている必要があります。
An implementation SHOULD make the cookie as small as possible to insure interoperability.
実装は、相互運用性を保証するためにできる限りのクッキーは限り小さくすべきです。
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 in the same SCTP packet.
このチャンクのみ関連の初期化中に使用されます。 COOKIE ECHOチャンクの受信を確認するために使用されます。この塊は協会内に送信データやSACK塊に先行しなければなりませんが、同じ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 zero on transmit and ignored on receipt.
送信時にゼロに設定して、領収書の上で無視。
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.
このチャンクは、詳細については、セクション9.2を参照してください、シャットダウンプロセスの完了時にSHUTDOWN ACKチャンクの受信を確認するために使用しなければなりません。
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 had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
送信者は、それが破壊されていることTCBを持っていた場合はTビットが0に設定されています。送信者がTCBを持っていなかった場合には、このビットを1に設定する必要があります。
Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details.
注意：特別なルールは検証のために、このチャンクに適用されます、詳細については、セクション8.5.1を参照してください。
During the lifetime of an SCTP association, the SCTP endpoint's association progress 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 description of all special cases should be 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 which causes a state transition it is labeled (A), (B) etc.
注意：パラメータ名は最初の文字は州Cookieパラメタ対、例えば、COOKIE ECHOチャンクタイプを資産計上していながら、チャンク名は、すべて大文字で指定されています。複数のイベント/メッセージは、標識されている状態遷移（A）、（B）等を引き起こす場合に発生することができ
----- -------- (frm 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/check
|PENDING | | 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が無効である場合（すなわち、整合性チェックを通過することができなかった）、受信機は静かにパケットを捨てなければなりません。受信状態クッキー（5.1.5項を参照）有効期限が切れている場合は、受信機はERRORチャンクを返送しなければなりません。いずれの場合も、受信機は、CLOSED状態にとどまります。
2) If the T1-init timer expires, the endpoint MUST retransmit INIT and re-start 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 SCTP user.
T1-INITタイマーが満了した場合2）、エンドポイントは、INITを再送しなければならなくて、状態を変更することなく、T1-INITタイマーを再起動します。これは、「Max.Init.Retransmits」回まで繰り返さなければなりません。その後、エンドポイントは、初期化プロセスを中止し、SCTPユーザにエラーを報告しなければなりません。
3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and re-start 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 SCTP user.
T1-クッキータイマーが満了した場合3）、エンドポイントは、COOKIE ECHOを再送しなければならないし、状態を変更することなく、T1-クッキータイマーを再起動します。これは、「Max.Init.Retransmits」回まで繰り返さなければなりません。その後、エンドポイントは、初期化プロセスを中止し、SCTPユーザにエラーを報告しなければなりません。
4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received DATA chunks without delay.
4）SHUTDOWN-SENT状態で、エンドポイントは、遅滞なく、任意の受信したデータチャンクを確認しなければなりません。
5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send request from its SCTP user.
5）SHUTDOWN-RECEIVED状態では、エンドポイントは、そのSCTPユーザからの新しい送信要求を受け入れてはいけません。
6) In 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 SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send request from its SCTP user.
7）SHUTDOWN-ACK-SENT状態では、エンドポイントは、そのSCTPユーザからの新しい送信要求を受け入れてはいけません。
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.
最初のデータ伝送が別のSCTPエンドポイント（「Z」）、1つのSCTPエンドポイント（「A」）から行うことができる前に、2つのエンドポイントは、それらの間のSCTPアソシエーションを設定するために初期化プロセスを完了しなければなりません。
The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint.
エンドポイントSCTPユーザは、別のSCTPエンドポイントにSCTPアソシエーションを初期化するためにプリミティブASSOCIATEを使用すべきです。
IMPLEMENTATION NOTE: From an SCTP-user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see 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 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state.
A） "" 第一 "Z" へINITチャンクを送信します。 INITでは、「」開始タグフィールドでの検証タグ（TAG_A）を提供しなければなりません。 TAG_Aは、（タグ値を選択するための5.3.1を参照）1 4294967295までの範囲の乱数であるべきです。 INITを送った後、「」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, nor keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks.
注意：州CookieパラメタでINIT ACKを送信した後、「Z」は、任意のリソースを割り当ててはならない、また新しいアソシエーションを任意の状態を保ちます。それ以外の場合は、「Z」リソース攻撃に対して脆弱になります。
C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1- init timer and leave 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.
「Z」からINIT ACKを受信すると、C）は、「」T1- INITタイマーを停止し、COOKIE-WAIT状態のままにしなければなりません。 「」その後、国家クッキーがCOOKIE ECHOチャンクでINIT ACKチャンクで受信し送信しなければならない、T1-クッキータイマーを開始し、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チャンクを受信すると、エンドポイント「Z」は、TCBを構築し、確立された状態に移動した後COOKIE ACK塊で応答します。 COOKIE ACK塊は、任意の保留データチャンク（および/またはSACKチャンク）にバンドルされてもよいが、COOKIE ACK塊は、パケット内の最初のチャンクでなければなりません。
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).
COOKIE ACKの受信、エンドポイント時にE）は、「」T1-クッキータイマを停止、ESTABLISHED状態にCOOKIE-ECHOED状態から移動します。また、コミュニケーションアップ通知との関連の成功設立についてそのULPに通知することができる（セクション10を参照）。
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-クッキータイマはセクション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 MUST 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チャンクを含むアウトバウンドSCTPパケットの共通ヘッダに検証タグフィールドは、ピアの開始タグの値に設定しなければなりません。
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.
協会の最初のデータチャンクの受信後にエンドポイントは、すぐにデータチャンクを確認するためにSACKで応じなければなりません。 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マイナス1の値にその内部の累積TSN Ackをポイントを設定しなければなりません。
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 shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
INITとINIT ACKチャンクは、チャンクの送信者は、それが他のエンドポイントから受け入れる関連を持っていることを望むだけでなく、最大のインバウンドストリーム（MIS）アウトバウンドストリーム（OS）の数を示すものとします。
After receiving the stream configuration information from the other side, each endpoint shall 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 either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer.
他の側からのストリーム構成情報を受信した後、各エンドポイントは、次のチェックを実行しなければならないピアの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.
会合後、エンドポイントは分（ローカルOS、リモートMIS）-1 0でなければならないのいずれかの有効なアウトバウンドストリーム識別子の範囲を初期化されます。
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.
受信したINITまたはINIT ACKチャンクに存在しないアドレスのパラメータが存在しない場合A）、エンドポイントは、送信先トランスポートアドレスとして、SCTP送信元ポート番号との組合せで、チャンクが到着元のソースIPアドレスを取得し、それを記録しなければなりませんこのピアのために。
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.
受信INITまたはINIT ACKチャンクに存在するホスト名パラメータがある場合はB）、エンドポイントは、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クエリ）を含み、受信機は、期間の攻撃を資源に自分自身を開く可能性がある場合それは国家クッキーを構築し、ローカルリソースを解放することができます前に、それは名前解決の結果を待っている間の時間。
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の受信機とは、INITが受信された送信元IPアドレスにINIT ACKを送信します。
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の受信機は、そのピアに（ピギーバックまたはスタンドアロン）のユーザデータを送ってはいけません。
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 shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) 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）のみのIPv4 / IPv6が受信INITあるいはINIT ACKチャンクに存在するアドレスがある場合、受信機は、導出し、受信したチャンクとINITまたはINIT ACKを送信した送信元IPアドレスからのすべてのトランスポートアドレスを記録しなければなりません。トランスポートアドレス（複数可）は、（共通ヘッダから）SCTP送信元ポートの組み合わせとINITあるいはINIT ACKチャンクとIPデータグラムの送信元IPアドレスで運ばれるIPアドレスパラメータ（単数または複数）によって導出されます。ピアへの後続のパケットを送信するとき、受信機は、送信先トランスポートアドレスとしてのみ、これらのトランスポート・アドレスを使用する必要があります。
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アドレスを管理していない場合）、エンドポイントはそのINITまたはINIT ACKにどのパケットからピアに可能なすべてのIPアドレスを含める必要があります可能性があり送信すること。
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チャンクから誘導された後、エンドポイントは初期主要パスとして転送アドレスのいずれかを選択しなければなりません。
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 (initiatee) 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（initiatee）の受信機は、INITに応答するときにサポートされているアドレス型パラメータで示されるアドレスの種類のいずれかを使用しなければならないか、それが不本意である場合には、「解決できないアドレス」エラーの原因との関連を中止しますまたはそのピアによって示されるアドレスのタイプのいずれかを使用することができません。
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 re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：INIT ACKの受信機が原因サポートされていないタイプのアドレスパラメータを解決するために失敗した場合は、開始プロセスを中止することができますし、新しい中に「サポートされているアドレス型」パラメータを使用して、再起動を試みますINITは、それが好むアドレスの種類を示します。
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 time stamp 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の送信者は、国家クッキーを作成し、INIT ACKの州Cookieパラメタでそれを送信します。この状態クッキーの中に、送信者はそれを確立するために必要なすべての情報とともに、MAC（例えば、[RFC2104]を参照）、国家クッキーが作成されたときのタイムスタンプ、および国家クッキーの寿命を含める必要があります協会。
The following steps SHOULD be taken to generate the State 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',
2）TCBで、現在の時刻に作成時刻を設定し、プロトコルパラメータ「Valid.Cookie.Life」の寿命、
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を組み合わせることにより、状態クッキーを生成します。
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.
リソース攻撃を防止するために、州CookieパラメタでINIT ACKを送った後、送信者は、TCBと新しいアソシエーションに関連する他のローカルリソースを削除する必要があります。
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 ([RFC1750] 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の使用は、サービス拒否攻撃を防ぐために必須です。秘密鍵はランダムであるべきである（[RFC1750]はランダム性のガイドラインについていくつかの情報を提供します）。それが合理的に頻繁に変更されるべきであり、国家クッキーのタイムスタンプは、MACを検証するために使用されるべきキーを決定するために使用されるかもしれません。
An implementation SHOULD make the cookie as small as possible to insure interoperability.
実装は、相互運用性を保証するためにできる限りのクッキーは限り小さくすべきです。
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.
（クッキーWAIT状態）エンドポイントが状態クッキーパラメータとINIT ACKチャンクを受信すると、それは即座に受信した状態クッキーとのピアにCOOKIE ECHOチャンクを送信しなければなりません。送信者はまた、COOKIE ECHOチャンクの後にパケットに保留中のDATAチャンクを追加するかもしれません。
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' is reached causing the peer endpoint to be marked unreachable (and thus the association enters the CLOSED state).
エンドポイントはまた、COOKIE ECHOチャンクを送信した後、T1-クッキータイマーをスタートします。タイマーが期限切れになった場合、エンドポイントは、COOKIE ECHOチャンクを再送信し、T1-クッキータイマを再スタートするものとします。クッキーACKのいずれかが受信されたか「Max.Init.Retransmits」は、ピアエンドポイントが（したがって関連が閉状態になる）到達不能とマークさせる達するまでこれが繰り返されます。
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). Reference [RFC2104] can be used as a guideline for generating the MAC,
1）州Cookieで運ばTCBデータと秘密鍵を（注意状態クッキーのタイムスタンプが使用する秘密鍵どの決定することができる）を使用してMACを計算します。参考文献[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）それは、以前州Cookieで運ば1に対して計算されたMACとを比較することによって生成されたものと州Cookieを認証。この比較が失敗した場合、COOKIE ECHOとどんなDATAチャンクを含むSCTPパケットは、黙って破棄しなければなりません、
3) 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,
3）現在のローカル時刻に状態クッキー内の作成タイムスタンプを比較してください。経過時間が長い状態クッキーに運ば寿命を超える場合は、COOKIE ECHOと接続されているすべてのDATA塊を含むパケットは、破棄されるべきとエンドポイントは、「古いクッキー」エラー原因とERRORチャンクを伝えなければなりませんピアエンドポイント、
4) 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,
状態クッキーが有効であれば4）、COOKIE ECHOで運ばTCBデータに情報をCOOKIE ECHOチャンクの送信者に関連付けを作成し、および確立された状態を入力し、
5) Send a COOKIE ACK chunk to the peer acknowledging reception 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.
5）COOKIE ECHOの受信を肯定応答するピアにCOOKIE ACKチャンクを送信します。 COOKIE ACKは、アウトバウンドのDATAチャンクまたはSACKチャンクにバンドルすることができ、しかし、COOKIE ACKは、SCTPパケット内の最初のチャンクでなければなりません。
6) 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 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
6）直後（次のデータチャンク応答）はセクション6.2で定義された規則に従うべきであるSACKとCOOKIE ECHOにバンドルされ、任意のデータチャンクを認めます。 SACKがCOOKIE ACKにバンドルされている場合）、ステップ5で述べたように、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):
次の例では、「」会合を開始した後、「Z」へのユーザメッセージを送信し、その後、「Z」は、後に（なしバンドルまたはフラグメンテーション発生を想定していない）「A」への2つのユーザ・メッセージを送信します。
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=1 & 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=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
図4：開始例
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). When retransmitting the INIT, the endpoint MUST follow the rules defined in 6.3 to determine the proper timer value.
T1-INITタイマーが「A」で有効期限が切れるとINITまたはCOOKIE ECHOチャンクが送信された後、同じと同じINITまたはCOOKIE ECHOチャンクはタグを開始します（つまり、TAG_A）または状態クッキーが再送されなければならないとタイマーが再スタート。これは、その上位層に「」考える「Z」到達不能と報告故障前Max.Init.Retransmits回繰り返さなければならない（従って、関連付けは、CLOSED状態に入ります）。 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 lifetime 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.
（可能な状態のいずれかで）関連の存続期間中に、エンドポイントは、ピアエンドポイントからセットアップチャンク（INIT、INIT ACK、COOKIE ECHOおよびCOOKIE ACK）のいずれかを受け取ることができます。受信機は、重複するようなセットアップチャンクを治療し、このセクションで説明するように、それを処理しなければなりません。
Note: An endpoint will not receive the chunk unless the chunk was sent to a SCTP transport address and is from a 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, re-started 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 or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged). These 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-エコー状態でINITを受信すると、エンドポイントは、それが（その開始タグを含む、変化しない）元のINITチャンクで送信され、同じパラメータを使用してINITのACKで応答しなければなりません。これら元のパラメータは、新たに受信したINITチャンクからのものと組み合わされます。エンドポイントはまた、INIT ACKと状態クッキーを生成しなければなりません。エンドポイントは状態クッキーを計算するために、そのINITに送信されたパラメータを使用しています。
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.
エンドポイントがその状態を変更してはならないことをした後、T1-INITタイマーが実行中のままにされなければならないと、対応するTCBは破壊されてはなりません。 TCBが存在するときの状態クッキーを処理するための通常の手順は、単一の協会に複製のINIT解決されます。
For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags with the Tag information of itself and its peer (see section 5.2.2 for a description of the Tie-Tags).
それはそれ自体とそのピアのタグ情報とのタイタグを移入する必要がありCOOKIE-ECHOED状態にあるエンドポイント（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と-SENT SHUTDOWN-ACKよりも米国その他の予期しないINIT
Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation 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の受信時に、エンドポイントは、国家クッキーとINIT ACKを生成するものとします。アウトバウンドINIT ACKではエンドポイントは状態クッキー内の予約済みの場所に、現在の検証タグとピアの検証タグをコピーしなければなりません。我々はPeer's-タイタグとローカル・タイタグとしてこれらの場所を指すものとします。このINIT ACKを含むアウトバウンドSCTPパケットは、予期せぬINITで見つかった開始タグに等しい検証タグ値を運ばなければなりません。そして、INIT ACKは（ランダム5.3.1項を参照してください生成された）新しい開始タグを含まなければなりません。エンドポイントの他のパラメータはINIT ACKとクッキーに関連（アウトバウンドストリームの例えば数）の既存のパラメータからコピーする必要があります。
After sending out the INIT ACK, 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を送信した後、エンドポイント、すなわち、現在の状態、および対応するTCBを含む既存の関連付けは、変更してはならない、それ以上の行動を取るなりません。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT state are the Tie-Tags populated. For a normal association INIT (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.
注：TCBが存在し、アソシエーションがCOOKIE-WAIT状態でない場合にのみタイタグ移入されます。通常関連INIT（すなわち、エンドポイントがCOOKIE-WAIT状態にある）のために、タイタグ（以前のTCBが存在しないことを示す）を0に設定しなければなりません。セクション5.2.1で指定されたINIT ACKと状態クッキーが移入されます。
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.
INIT ACKがCOOKIE-WAIT状態以外の状態でエンドポイントによって受信された場合、エンドポイントは、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チャンク（すなわち、しない閉じた状態で）既存の関連付けのための任意の状態でエンドポイントによって受信される場合、以下の規則が適用されなければなりません。
1) Compute a MAC as described in Step 1 of Section 5.1.5,
セクション5.1.5のステップ1に記載したように1）、MACを計算します
2) Authenticate the State Cookie as described in Step 2 of Section 5.1.5 (this is case C or D above).
セクション5.1.5のステップ2に記載したように2）（これは場合Cまたは上記Dである）州Cookieを認証。
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 ECHOとどんなDATAチャンクを含むパケットは、破棄されなければなりません。エンドポイントは、（これはセクション5.2の場合CまたはDである）ピアエンドポイントに「古いクッキー」エラー原因でERRORチャンクを送信しなければなりません。
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 of section 5.2) even if the lifespan is exceeded.
国家クッキーで検証タグの両方が現在のアソシエーションの検証タグが一致した場合は、寿命を超えた場合でも、（これはセクション5.2の場合Eである）状態クッキーが有効なことを検討してください。
4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB.
国家クッキーが有効であることが判明した場合4）、一時的な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 - クッキーでノーネクタイタグ（不明）。 - すべてのケース、すなわちM、X、または0。
Note: For any case not shown in Table 2, the cookie should be silently discarded.
注：表2に示されていない場合は、クッキーは静かに捨てなければなりません。
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）この場合、ピアは、再起動してもよいです。エンドポイントは、この潜在的な「再起動」を認識すると、それは以下の例外を持つ新しいCOOKIEのECHO続いABORTを受けたかのように、既存のセッションが同じように扱われます。
- 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.
- RESTARTの通知はULPの代わりに「通信LOST」通知に送信されるべきです。
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.
この後エンドポイントはESTABLISHED状態に入るものとします。
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes the peer has restarted (Action A), it MUST NOT setup 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を再送し、「シャットダウン中に受信したクッキー」と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 running and send a COOKIE ACK.
B）この場合、双方がほぼ同時にアソシエーションを開始しようとすることができるが、ピアエンドポイントは、ローカルエンドポイントのINITに応答した後、そのINITを開始しました。したがって、それは、このエンドポイントを送っていた以前のタグを意識することはない、新たな検証タグを選んだことがあります。エンドポイントは、中にとどまるか、ESTABLISHED状態に入るが、それは、国家クッキーからそのピアの検証タグを更新し実行している可能性のある初期化やクッキータイマを停止し、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）この場合、ローカルエンドポイントのクッキーが遅れて到着しました。それが到着する前に、ローカルエンドポイントは、INITを送信し、INIT-ACKを受信し、最終的にピアの同じタグが、その独自の新しいタグでCOOKIE ECHOを送りました。クッキーは静かに捨てられるべきです。エンドポイントは状態を変更すべきではなく、実行しているすべてのタイマーを残す必要があります。
D) When both local and remote tags match the endpoint should always enter the ESTABLISHED state, if it has not already done so. It should stop any init or cookie timers that may be running and send a COOKIE ACK.
D）、ローカルとリモートの両方のタグが、それはまだ行っていない場合、エンドポイントは常に、ESTABLISHED状態に入るべき一致します。それが実行されても任意の初期化やクッキータイマを停止し、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):
次の例では、「」再起動が発生した後の関連付けを開始します。エンドポイント「Z」が交換されるまで再起動の知識を有していなかった（すなわち、ハートビートはまだ「A」の障害を検出しませんでした）。 （非バンドルを想定していないか、フラグメンテーションが発生）。
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 a 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=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
図5：再起動例
At any state other than COOKIE-ECHOED, an endpoint should silently discard a received COOKIE ACK chunk.
COOKIE-エコー以外の状態では、終点は静かに受信されたクッキーACKチャンクを破棄しなければなりません。
Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates one of a number of possible events:
「古いクッキー」エラー原因とERRORチャンクの受信が可能なイベントの数のいずれかを示します。
A) That the association failed to completely setup before the State Cookie issued by the sender was processed.
A）送信者によって発行された状態クッキーが処理される前に会合が完全にセットアップに失敗したこと。
B) An old State Cookie was processed after setup completed.
セットアップが完了した後、B）古い状態クッキーが処理されました。
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チャンクが失われたことを誰かから受信されます。
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 setup, 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.
アソシエーションが設定中である場合、エンドポイントは、最初の検討すべき引き起こす「古いクッキー」エラーで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 re-attempt the setup procedure.
1）新しい状態クッキーを生成して、セットアップ手順を再試行するエンドポイントに新しいINITチャンクを送信します。
2) Discard the TCB and report to the upper layer the inability to setup the association.
2）TCBを破棄し、設定することができないことを上位層への関連付けを報告しています。
3) Send a new INIT chunk to the endpoint, adding a Cookie Preservative parameter requesting an extension to the lifetime 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 lifetimes making the endpoint more subject to a replay attack.
3）国家クッキーの有効期間の延長を要求するクッキー防腐剤パラメータを追加し、エンドポイントに新しいINITチャンクを送信します。時間の延長を計算する場合、実装は、以前のCOOKIE ECHO / ERROR交換に基づいて測定されたRTT情報を使用すべきである、とするエンドポイントは、より対象作る長い州Cookieの寿命のために測定された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 [RFC1750] 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。開始タグの値が「中間者」と「シーケンス番号」攻撃から保護するためにランダム化されることが非常に重要です。 [RFC1750]に記載された方法は、開始タグのランダム化のために使用することができます。タグを開始するの慎重な選択が誤って現在のアソシエーションに属するものとして処理される前の協会から古い重複パケットを防ぐためにも必要です。
Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the lifetime of an association. A new Verification Tag value MUST be used each time the endpoint tears-down and then re-establishes an association to the same peer.
また、与えられた関連のいずれかのエンドポイントによって使用される検証タグ値は、アソシエーションの寿命の間に変化してはいけません。新しい検証タグ値は、各時間エンドポイント涙ダウンを使用し、同じピアへの関連付けを再確立しなければなりません。
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 COOKIE-WAIT state.
データ送信はESTABLISHED、SHUTDOWN-PENDING、およびSHUTDOWN-RECEIVED状態で行われる必要があります。これに対する唯一の例外は、データチャンクがCOOKIE-WAIT状態のときにアウトバウンドCOOKIE ECHOチャンクにバンドルすることが許可されていることです。
DATA chunks MUST only be received according to the rules below in ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received in CLOSED is out of the blue and SHOULD be handled per 8.4. A DATA chunk received in any other state SHOULD be discarded.
DATAチャンクのみESTABLISHED、SHUTDOWN-PENDING、SHUTDOWN-SENTに以下の規則に従って受信されなければなりません。 CLOSEDに受信されたデータチャンクは、青色のうちで、8.4当たり処理されるべきです。他の状態で受信されたデータチャンクは、廃棄されるべきです。
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 8.4. A SACK chunk received in any other state SHOULD be discarded.
SACKは、確立された、SHUTDOWN-PENDING、およびSHUTDOWNに受信で処理されなければなりません。入って来るSACKは、COOKIE-ECHOEDで処理することができます。閉状態におけるSACKは、青色の外であり、8.4の規則に従って処理されるべきです。他の状態で受信されたSACKチャンクは廃棄されるべきです。
A SCTP receiver MUST be able to receive a minimum of 1500 bytes in one SCTP packet. This means that a SCTP endpoint MUST NOT indicate less than 1500 bytes in its Initial a_rwnd sent in the INIT or INIT ACK.
SCTPの受信機は、一の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.
このセクションでは、用語「データ送信者」は、データチャンクと、用語「データ受信」を送信データチャンクを受信するエンドポイントを指すエンドポイントを指します。データ受信装置は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）、エンドポイントは、複数のデータチャンクに現在関連付け経路MTUよりも大きいユーザメッセージを断片化します。データ受信装置は、通常、ユーザ（詳細はセクション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を超えない限り、送信のために単一のSCTPパケットに送信側で束ねてもよいです。受信機は、元のチャンクにパケットをアンバンドルされます。コントロールチャンクはパケット内のデータの塊の前に来なければなりません。
Figure 6: Illustration of User Data Transfer
図6：ユーザデータ転送のイラスト
The fragmentation and bundling mechanisms, as detailed in Sections 6.9 and 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.
この文書は、宛先トランスポートアドレスごとに単一の再送信タイマーがあるかのように指定されていますが、実装は、各データチャンクの再送信タイマーを持っているかもしれません。
The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks:
以下の一般的なルールは、送信及び/又はアウトバウンド・データチャンクの再送信のためにデータ送信者によって適用されなければなりません。
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 having been lost in transit from the data receiver to the data sender.
そのピアのRWNDピア（すなわちRWNDが0である、セクション6.2.1を参照）は、バッファスペースを有していないことを示す場合A）は、任意の所与の時点で、データ送信者は任意の宛先トランスポートアドレスに新しいデータを送信してはいけません。 CWNDによって許可されている場合しかし、関係なく（それが0である場合を含む）RWNDの値の、データの送信側は常に受信機に飛行中の一つのデータチャンクを有することができる（以下ルール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.
それはcwndをまたはそのトランスポートアドレスへの未処理データのより多くのバイトをしている場合B）任意の時点で、送信者は、与えられた輸送アドレスに新しいデータを送信してはなりません。
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks which are marked for retransmission (limited by the current cwnd).
送信者が送信するための時間が来るとC）、新しいデータチャンクを送信する前に、送信者は、まず現在のcwndによって制限された再送（）のためにマークされているすべての未処理データチャンクを伝えなければなりません。
D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow.
D）次に、送信者はルール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 a 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).
伝送のためにコミット複数のデータチャンクは、単一のパケットにバンドルされるかもしれません。また、再送されるデータチャンクは、得られたパケットサイズがパスMTUを超えない限り、新たなデータチャンクにバンドルされるかもしれません。 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.
エンドポイントは、データチャンクを送信する前に、すべての受信したデータチャンクが確認されていない場合は、（例えば、遅延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チャンクが確認されると、送信が再びルール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）の未処理データチャンクが再送信されている場合、送信者はタイマーを再起動する必要があります。それ以外の場合は、データの送信者はタイマーを再起動してはなりません。
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.
注意：データの送信者は2 ** 31以上であるTSN使うべきではありません - 1現在の送信ウィンドウの開始TSNの上を。
The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk.
SCTP終点は常に、各有効なデータ・チャンクの受信を確認しなければなりません。
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で指定された遅延確認応答アルゴリズムのガイドラインに従わされるべきです。具体的には、肯定応答は、少なくとも毎秒パケット（必ずしもすべての第二のデータチャンク）を受信するために生成されるべきであり、任意の未確認DATAチャンクの到着の200ミリ秒以内に生成されるべきです。 SCTP送信機は、この文書に詳述アルゴリズムが許すよりも保守的であるために、いくつかの状況では有益であり得ます。しかし、SCTP送信機は、以下のアルゴリズムが許すよりも、より積極的にすることはできません。
A 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を発生させてはいけません。
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 500ms but MUST NOT raise it above 500ms.
実装は、最大遅延は500以上のミリ秒であるように構成されることを可能にしてはいけません。つまり、実装は500msの下に、この値を下げるかもしれませんが、500ミリ秒を超える、それを発生させてはなりません。
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 SHOULD also be reported in the Gap Ack Block fields.
シャットダウンが終点がSHUTDOWNチャンクに確認応答を送信することができ、その場合にはULPによって要求された場合を除き謝辞はSACKチャンクに送らなければなりません。 SACKチャンクは複数のDATAチャンクの受信を確認することができます。 SACKチャンク形式については、セクション3.3.4を参照してください。特に、SCTP終点は、それが受信した（有効なデータチャンクの）最新のシーケンシャルTSNを示すために、累積TSN ACKフィールドに記入しなければなりません。累積TSN ACKフィールドの値より大きいTSNを有する任意の受信したデータチャンクはまた、ギャップ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チャンクはギャップAckブロックフィールドが含まれていません。そのため、エンドポイントは、順不同で受信したデータチャンクを確認するためにSACKの代わりに、SHUTDOWNチャンクを使用する必要があります。
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.
パケットが重複データチャンク（S）とし、新しいデータのチャンク（S）で到着すると、エンドポイントはすぐに遅延なしでSACKを送らなければなりません。パケットが新しいDATAチャンクにバンドルされ、重複データチャンク（S）で到着した場合、エンドポイントはすぐにSACKを送信することができます。オリジナルのSACKチャンクが失われたとピアのRTOが期限切れになったとき、重複DATAチャンクの通常の受信が発生します。重複TSN番号（複数可）は、重複するようにSACKで報告されるべきです。
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を受信すると、SACK損失が発生しているかどうかを決定するために重複TSN情報を使用することができます。このデータのさらなる利用は、今後の検討課題です。
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:
データ受信機は、その受信バッファを維持する責任があります。データ受信装置は、データを受信する能力の変化をタイムリーにデータを送信者に通知すべきです。実装は、多くの要因に依存してその受信バッファを管理する方法（例えば、オペレーティングシステム、メモリ管理システム、メモリの量、など）。しかしながら、セクション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を増加しないはずです。受信機が再組み立てキューに断片化されたデータチャンクを保持している場合、例えば、それは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).
SACKを送信するときD）、データ受信機はa_rwndフィールドにa_rwndの現在の値を配置する必要があります。データ受信装置は、データ送信者が累積TSN ACK（すなわち、その再送信キューからドロップされます）を介してACKされたデータチャンクを再送しないであろう考慮すべきです。
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に配信）から放出されていないデータチャンクを削除する必要があるかもしれません。これらのデータチャンクはギャップAckブロックにACKされている場合があります。それはバッファスペースを受け取るを使い果たしたときに、そのピアから断片化されたユーザメッセージを再組み立てしながら、例えば、データ受信機は、受信バッファ内のデータを保持することができます。それはギャップAckブロックでそれらを認めているにもかかわらず、これらのデータチャンクを低下することがあります。データ受信がDATAチャンクをドロップした場合、彼らは再送信を経由して再び受信するまで、それ以降の袋にギャップAckブロックにそれらを含めることはできません。そのa_rwndを計算する際に加えて、エンドポイントは考慮にドロップされたデータを取る必要があります。
An endpoint SHOULD NOT revoke a SACK and discard data. Only in extreme circumstance 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を取り消すとデータを破棄すべきではありません。唯一の極端な状況では、エンドポイントは、（例えばバッファ空間のうちのような）この手順を使用しなければなりません。データ受信機は、ギャップAckブロックに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 Acknowledgment 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".
エンドポイントは（すなわち、長さフィールドが16に設定されている）のないデータでデータチャンクを受信した場合には、「ユーザデータ」に設定し、エラーの原因とABORTを送らなければなりません。
An endpoint SHOULD NOT send a DATA chunk with no user data part.
エンドポイントが無いユーザデータ部とのデータチャンクを送るべきではありません。
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を処理するときにデータの送信者が考慮しなければならない問題の一つは、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が新しいかどうかを決定するためのヒューリスティックを使用しなければなりません。
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値、受信されたSACKにおいて累積TSN ACKおよびギャップAckブロックを使用して、RWNDを計算するために次のルールを使用すべきです。
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）アソシエーションの確立時に、エンドポイントは、アドバタイズ受信ウィンドウクレジット（a_rwnd）INITあるいはINIT ACKに指定されたピアに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）ピアへのデータチャンクを送信（または再送信される任意の時間）は、エンドポイントがそのピアのRWNDからチャンクのデータサイズを減算します。
C) Any time a DATA chunk is marked for retransmission (via either 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）のDATAチャンクが再送信のためにマークされているすべての時間は、あるいは高速再送（第7.2.4項）を介して）（いずれかのT3-RTXタイマ満了（セクション6.3.3を経由して）、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チャンクの各データチャンクのタイマーを維持している場合。
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.
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）のセットは、新たに受信したa_rwndマイナス累積TSN ACKおよびギャップAckブロックを処理した後、まだ未処理のバイト数に等しいRWND。
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 mark the corresponding DATA chunk as available for retransmit: Mark it as missing for 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.
ⅲ）SACKが以前ギャップAckブロック（例えば、データ受信機がデータに破っ）を経由して認められたTSNが欠落している場合は、再送信用として利用できる対応するデータチャンクマーク：説明したように、高速再送信のために不足しているとしてマーク、それを何の再送信タイマーは、どのデータチャンクが最初に送信されたために宛先アドレスのために実行されていないセクション7.2.4にしている場合は、T3-RTXは、その宛先アドレスに対して開始されます。
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 follows 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が再送タイマを管理して密接にどのように従います。 SRTT（平滑化往復時間）とRTTVAR（ラウンドトリップ時間変動）：現在のRTOを計算するために、エンドポイントが宛先トランスポートアドレスごとに2つの状態変数を維持します。
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 SRTT <- R, RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR.
最初のRTT計測Rが行われるとC2）、設定SRTT < - R、RTTVAR < - R / 2、及びRTO < - SRTT + 4 * RTTVAR。
C3) When a new RTT measurement R' is made, set
新しいRTT測定R」が行われるC3）、セット
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| 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.
SRTT + 4 *のRTTVAR - 計算した後、RTOを<更新。
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測定は、所定の宛先トランスポートアドレスの往復に一回以下で行われるべきではありません。この勧告には2つの理由があります。第一に、より頻繁に頻繁に測定することは実際には任意の重要な利点[ALLMAN99]が得られないことが表示されます。測定がより頻繁に行われる場合SRTTとRTTVARはまだどのように多くのラウンドトリップの点で（ほぼ同じ割合で変化に合わせるように、第2、次いで上記ルールC3におけるRTO.AlphaとRTO.Betaの値を調整しなければならないこと彼らは往復ごとに1つだけの測定を行うと、ルールC3に与えられたようRTO.AlphaとRTO.Betaを使用してしまうかのように）新しい値を反映するためにそれらを取ります。しかし、これらの調整の正確な性質は、研究課題のまま。
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 packet or a later instance).
C5）カーンのアルゴリズム：RTT測定は、再送されたパケットを使用して作製されてはいけません（したがって、そのためには、返信パケット以降のインスタンス）の最初のインスタンスのためだったかどうか曖昧です。
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].
それはそれはRTO.Min秒に切り上げられRTO.Min秒未満の場合RTOは、計算されるたびにC6）。このルールの理由は、高い最小値を持っていないRTOSは不要タイムアウト[ALLMAN99]の影響を受けやすいということです。
C7) A maximum value may be placed on RTO provided it is at least RTO.max seconds.
C7）の最大値は、RTO上に配置することができる、少なくともRTO.max秒提供されます。
There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables, other than:
Gは、RTT測定値及び以外の異なる状態変数を計算するために使用されるクロックの粒度のための必要はありません。
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G.
RTTVARが計算されるたびG1）、RTTVAR = 0の場合、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.
そのアドレスのT3-RTXタイマーが実行されていない場合R1）（）（再送信を含む）のDATAチャンクが任意のアドレスに送信されるたびに、それがそのアドレスのRTO後に期限切れになるように、それが実行を開始します。 RTOは、ここで使用により以下のルールE2で説明したように対応する宛先アドレスに前T3-RTXタイマーの期限切れに任意の倍加後に得られたということです。
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 T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address).
まだそのアドレスに優れたデータ）がある場合SACKは、それがそのアドレスの最初期卓越したTSNを持つデータチャンクを認めて受信されるたびR3）は、（現在のRTOとそのアドレスに対してT3-RTXタイマーを再起動します。
R4) Whenever a SACK is received missing a TSN that was previously acknowledged via a Gap Ack Block, start T3-rtx for the destination address to which the DATA chunk was originally transmitted if it is not already running.
SACKが以前ギャップAckブロックを経て承認されたTSNが欠け受信するたびR4）が、それはまだ実行されていない場合は、DATAチャンクが最初に送信されたと宛先アドレスのためのT3-RTXを起動します。
The following example shows the use of various timer rules (assuming 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)
\
/ \
(Re-start 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.
RTO * 2（「バックオフタイマー」） - タイマーが期限切れになるために宛先アドレスのE2）は、<RTOを設定します。 （RTO.max）上記ルールC7で議論最大値は、この倍増操作に上限を提供するために使用され得ます。
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））T3-RTXの有効期限が切れているアドレスのための優れたDATAチャンクが先輸送アドレスに対応するパスのMTUの制約を受け、単一のパケットに収まるどのように多くの早い（すなわち、最低のTSNの決定その再送が送信されている（これはタイマーが期限切れになるのアドレスと異なっていてもよい[セクション6.4を参照]）。この値K.バンドルを呼び出して、宛先エンドポイントに単一のパケットでそれらのK DATAチャンクを再送します。
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).
ルールR1は、上記そうすることを示している場合E4）、再送が送信された送信先アドレスに再送タイマT3-RTXを起動します。 RTOは、タイマが満了したため、宛先アドレスと異なる場合があり、受信機は、マルチホームで、再送が送信される宛先アドレスのためのものであるべきであるT3-RTXを開始するために使用される（セクションを参照下記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測定が（[セクション8.3を参照]ルールC5あたり、またはHEARTBEATから作られた測定のために、新たなデータが送信され、承認された場合にのみ発生する可能性がある）が得られると再送後、ルールC3で演算が行われます、それは（E2ルール）倍加を受けた後にバックダウンRTOを「崩壊」をもたらす可能性がRTOの計算を含みます。
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タイマーが満了したためのアドレスに送信されましたが、SACKが到着し、通常時に（再送信のためにマークとすぐにcwndが許すとして送信されるべき、1 MTU（上記のE3を支配）に適合していない任意のデータチャンク）。
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）別のものに現在の宛先トランスポートアドレスからたびに、エンドポイントスイッチは、現在の再送タイマーが動作して残されています。エンドポイントが新しいトランスポートアドレスへのデータチャンク（複数可）を含むパケットを送信するとすぐに、ルール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 Sections 5.1.2 and 10.1 for details).
また、エンドポイントのULPは（セクション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ユーザが明示的に使用するための宛先トランスポートアドレス（およびおそらくソーストランスポートアドレス）を指定しない限り、デフォルトでは、エンドポイントは常に、プライマリパスに送信しなければなりません。
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チャンクをバンドルされている場合は、このルールにも従わなければなりません。
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に異なる送信元アドレスからのパケットで受信した複数のデータチャンクを認める場合しかし、SACKチャンクは、データまたは制御チャンクが受信された肯定応答され、そこから先輸送アドレスの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 being 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.
重複データチャンクの受信機は、マルチホームエンドポイントにSACKを送信するときには、宛先アドレスを変更し、DATAチャンクの送信元アドレスを使用しないことが有益であり得ます。マルチホームのエンドポイントからの複製を受信するためのSACK（DATAチャンクの送信元アドレスで指定されるように）、リターンパスが切断されたことを示すかもしれないことである理由。
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
そのピアがマルチホームである場合さらに、エンドポイントは、データチャンクが送信されたために、最後の宛先アドレスと異なるアクティブ宛先トランスポートアドレスにチャンクを再送するようにしてください。
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.
再送は、発行済データ数には影響を与えません。データチャンクが異なる宛先アドレスに再送された場合は、新しい宛先アドレスとデータチャンクが最後に送られたために、古い宛先アドレスに優れたデータ数の両方が相応に調整されなければなりません。
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 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終点がすべき1が存在する場合は、代替アクティブ先輸送アドレスにデータを送信してみてください。
When retransmitting data, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting 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 is 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.
すべてのデータ・チャンクは有効なストリーム識別子を運ばなければなりません。エンドポイントが無効なストリーム識別子とデータチャンクを受信した場合、それはすぐに「無効なストリーム識別子」に設定し、原因とERRORチャンクを送って、通常の手順以下のDATAチャンクの受信を確認しなければならない（セクション3.3.10を参照）、捨てますDATAチャンク。エンドポイントは、限りERRORがSACKを次のようにSACKと同じパケットにERRORチャンクをバンドルすることがあります。
The stream sequence number in all the streams shall start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number shall 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 re-ordered.
ストリーム内で、エンドポイントは、そのストリーム・シーケンス番号の順序に従って上位階層に0にUフラグを設定して、受信したデータチャンクを供給しなければなりません。 DATAチャンクは、そのストリームのシーケンス番号の順不同で到着した場合、彼らは再順序付けされるまで、エンドポイントは、ULPへの配信から受信したデータチャンクを保持しなければなりません。
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エンドポイントには順序付けられた配信が1へのデータチャンクのUフラグを設定することにより、ストリーム内で送信特定のデータチャンクのために必要とされないことを示すことができます。
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 re-assembly if the user data is fragmented by the data sender).
エンドポイントが1にセットUフラグでデータチャンクを受信すると、順序付けメカニズムを迂回しなければならないし、直ちに（ユーザデータは、データ送信側によって断片化される場合、再組み立て後に）上位層にデータを配信します。
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.
これは、指定されたストリームの「アウトオブバンド」データを送信するのに有効な方法を提供します。また、ストリームは、単に、そのストリームを介して送信されるすべてのデータチャンク1にUフラグを設定することにより、「無秩序」ストリームとして使用することができます。
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.
実装上の注意：順不同のデータチャンクを送信する場合、実装が可能な場合はアウトバウンド送信キューの先頭にあるアウトバウンドパケット内のデータのチャンクを配置することもできます。
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.
1に設定Uフラグ付きデータチャンクに「ストリームシーケンス番号」フィールドには意味を持ちません。送信者は、任意の値でそれを埋めることができますが、受信機は、フィールドを無視しなければなりません。
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.
注：注文し、順不同のデータを送信するときに1にセットUフラグ付きデータチャンクを送信する場合、エンドポイントはそのストリームシーケンス番号をインクリメントしません。
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.
新しいデータチャンクを受信すると、エンドポイントは受け取ったTSNの継続性を検査しなければなりません。エンドポイントが受信したデータチャンクのシーケンスにおけるギャップを検出した場合、それは直ちにギャップAckブロックとSACKを送信すべきです。データ受信装置は、ギャップを埋めるない各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ブロックに基づいて、エンドポイントが欠落したデータチャンクを計算します（詳細は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を送信しようとする必要があります。
Upon the reception of a SACK, the endpoint MUST remove all DATA chunks which 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をによって承認されているすべてのデータのチャンクを削除する必要があります。エンドポイントは「行方不明」としてSACKで報告されたギャップAckブロックに含まれていないのTSNを持つすべてのデータの塊を扱わなければなりません。それぞれの未処理データのチャンクの「行方不明」報告書の数には再送信の意思決定を行うために、データの送信者を記録しなければなりません。詳細については、第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,
/ Strt=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 can not 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.
単一のSACKチャンク内に報告することができるギャップAckブロックの最大数は、現在のパスMTUによって制限されます。単一のSACKが原因MTU制限に報告するために必要なすべてのギャップAckブロックをカバーすることができない場合、エンドポイントはMTUで設定されたサイズ制限内で、最低から最高のTSNにギャップAckブロックを報告し、一つだけSACKを送らなければなりません、および未確認の残りの最高TSN番号を残します。
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the Adler-32 checksum value calculated on the packet, as described below.
SCTPパケットを送信するとき、以下に記載されるように、エンドポイントは、パケットで計算アドラー-32チェックサム値を含むことによって、送信のデータの整合性を強化しなければなりません。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall:
パケットが（SCTP共通ヘッダと1つ以上の制御またはDATAチャンクを含む）を構築した後、送信機はなければなりません。
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 Adler-32 checksum of the whole packet, including the SCTP common header and all the chunks. Refer to appendix B for details of the Adler-32 algorithm. And,
2）SCTP共通ヘッダとすべてのチャンクを含むパケット全体のアドラー-32チェックサムを計算します。アドラー-32アルゴリズムの詳細については、付録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 Adler-32 checksum:
SCTPパケットが受信されると、受信機は最初アドラー-32チェックサムをチェックしなければなりません。
1) Store the received Adler-32 checksum value aside,
1）、別に受信アドラー-32チェックサム値を格納
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate an Adler-32 checksum value of the whole received packet. And,
2）全て「0で受信SCTPパケット内のチェックサムフィールドの32ビットを交換し、全受信パケットのアドラー-32チェックサム値を計算します。そして、
3) Verify that the calculated Adler-32 checksum is the same as the received Adler-32 checksum. If not, the receiver MUST treat the packet as an invalid SCTP packet.
3）が算出アドラー-32チェックサムが受信アドラー-32チェックサムと同じであることを確認します。そうでない場合、受信機は、無効なSCTPパケットとしてパケットを扱わなければなりません。
The default procedure for handling invalid SCTP packets is to silently discard them.
無効なSCTPパケットを処理するためのデフォルトの手順は静かにそれらを捨てることです。
An endpoint MAY support fragmentation when sending DATA chunks, but 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チャンクを送信するときに断片化をサポートするかもしれませんが、データのチャンクを受信したときに再構築をサポートしなければなりません。エンドポイントが断片化をサポートしている場合、ユーザ・メッセージのサイズが現在のMTUを超える発信SCTPパケットサイズを引き起こす送信する場合には、ユーザメッセージを断片化しなければなりません。実装は、発信ユーザメッセージの断片化をサポートしていない場合、エンドポイントは、その上位層にエラーを返すと、ユーザーのメッセージを送信しようとしてはなりません。
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パケットヘッダとデータチャンクヘッダ（単数または複数）を取らなければなりません。また、実装は、アカウントへのデータの塊でSACKチャンクをバンドルする場合は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）データ送信側は、各チャンクプラス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）次に、送信機は、シーケンスで、一連のデータのチャンクのそれぞれに別々のTSNを割り当てる必要があります。送信機は、データのチャンクのそれぞれに同じSSNを割り当てます。ユーザがメッセージは順不同配信を使用して配信されることを示している場合、ユーザ・メッセージの各データチャンクの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）送信機はまた、「10」、「01」に直列に最後のデータチャンクのB / Eビットの系列の最初のデータチャンクのB / Eビットを設定しなければなりません、そしてB / Eビットの「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 re-assembly. Once the user message is reassembled, SCTP shall pass the re-assembled user message to the specific stream for possible re-ordering and final dispatching.
エンドポイントは、受信したデータチャンクの各々にB / Eビットを調べることによって断片化されたデータチャンクを認識、及び再組立のために断片化されたデータチャンクをキューイングしなければいけません。ユーザメッセージが再組み立てされると、SCTPは、可能な並べ替え、最終的な派遣のための具体的な流れに組み立て直さユーザメッセージを合格しなければなりません。
Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the re-assembly 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, including the SCTP packet and IP headers, MUST be less or equal to the current Path MTU.
エンドポイントは、単に1つのアウトバウンドSCTPパケットで複数のチャンクを含むことにより、チャンクをバンドルしています。 SCTPパケットとIPヘッダを含む得られた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 a SCTP packet in increasing order of TSN.
DATAチャンクと制御チャンクをバンドルする場合、エンドポイントは、アウトバウンドSCTPパケットに第一の制御塊を置かなければなりません。送信機は、TSNの昇順にSCTPパケット内のデータチャンクを送信しなければなりません。
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チャンクの前に送信されなければならないので、データチャンクはSHUTDOWNまたはSHUTDOWN ACKチャンクにバンドルすることはできません。
Partial chunks MUST NOT be placed in an SCTP packet.
部分的なチャンクは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.
エンドポイントMUSTプロセスは、パケット内の順序でチャンクを受け取りました。受信機は、すべてのチャンクが4バイト境界で終わっているという事実を考慮して次のチャンクのチャンクと始まりの終わりを決定するためにチャンク長フィールドを使用しています。受信機は、部分的チャンクを検出した場合、それは塊を落とさなければなりません。
An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with any other chunks.
エンドポイントは、INIT、INIT ACKまたは任意の他のチャンクとの完全なシャットダウンをバンドルしてはなりません。
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 assure 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の基本的な機能の一つです。したがって、送信が厳しい混雑状況に遭遇することを、通常の操作中に、そうであるように思われる - いくつかのアプリケーションでは、十分なリソースがタイムクリティカルなデータの迅速な配達を保証するために、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, are 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ブロックで運ばれた情報を考慮する。累積TSN AckをポイントがDATAチャンクのTSN（すなわち通過するまでSCTP、順不同で受信端に到着したデータを含め、SACKによって確認された任意のデータチャンクに、完全に配信考慮されていない、データチャンクはあり）SACKの累積TSN ACKフィールドによって承認され。したがって、CWNDの値が（非SACKのTCPの場合のように）よりむしろ未処理データの量、最も肯定応答シーケンス番号と輻輳ウィンドウ内で送信することができる最新のデータチャンクとの間の上限を制御します。 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つのエンドポイント間で異なるデータパスをもたらし得ます。マルチホームの受信機のため、ここでの輻輳制御の治療には、SCTPで新しく追加され、将来的に改善が必要な場合があります。現在のアルゴリズムは、以下の仮定を行います。
o The sender usually uses the same destination address until being instructed by the upper layer 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が受信されたシーケンス番号のギャップを通知するときのギャップが欠落データのより高いシーケンス番号で受信したデータを配信する前に満たされるまで、それが待機することを意味します。一方、SCTPストリームシーケンス番号が特定のストリーム（すなわち、欠落データチャンクは異なるストリームのためのものである）、または場合のシーケンスである場合、TSNにおけるギャップがあっても、その上位層プロトコルにデータを配信することができます順不同配信が示されています。これは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はまた、CWND調整を容易にするために、輻輳回避フェーズ中に使用されるpartial_bytes_acked一つの追加の制御変数を必要とします。
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全体協会（ピアがマルチホームであるか、単一のアドレスを持っている場合に関係なく）のために維持されます。
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 <= 2*MTU.
O十分長いアイドル期間のデータ伝送の前または後の初期CWNDは、<= 2 * MTUでなければなりません。
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).
SSTHRESHの初期値を任意に高くてもよいO（例えば、実装は、受信機のサイズがウィンドウをアドバタイズ使用してもよいです）。
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address.
CWNDがゼロよりも大きいときはいつでも、O、エンドポイントは、そのトランスポートアドレス上の未処理データのcwndのバイトを持つことが許されます。
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd (assuming the current congestion window is being fully utilized). If an incoming SACK advances the Cumulative TSN Ack Point, 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 protects against the ACK-Splitting attack outlined in [SAVAGE99].
CWNDは、SCTP終点をSSTHRESH以下である場合、O（現在の輻輳ウィンドウが完全に利用されていると仮定して）CWNDを増加させるためにスロースタートアルゴリズムを使用しなければなりません。着信SACKが累積TSNのAckポイントを進める場合、CWNDは、最も低い以前の未処理データのチャンク（S）の合計サイズが認め）1、及び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のを調整してはなりません。
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をポイントを進めていなくても、その累積TSN Ackをポイントに結合されていないため、エンドポイントは、やはりクロックアウト新しいデータをそれらを使用することができます。それは、新たにSACKによって確認データは今のcwnd未満に飛行中のデータの量を減少させる、です。そのためにcwndの現在、変わらない値は、新しいデータを送信することができます。上記で特定した一方で、CWNDの増加が累積TSN Ackをポイント進歩に接続する必要があります。そうしないと、重複サックスは、クロックアウト新しいデータをだけではなくなりますが、また、単に可能混雑の時間の間に、ネットワークを残しているものよりも新しいデータをクロックアウト悪影響を及ぼすだろう。
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, 2*MTU) per RTO.
エンドポイントが与えられたトランスポートアドレスにデータを送信しない場合には、O、トランスポート・アドレスのCWNDは、MAXに調整しなければならない（CWND / 2、2 * MTU）RTOあたり。
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をまたは対応するトランスポート・アドレスのための未処理データの複数のバイトた場合、CWNDは、RTTあたり1つの* MTUだけインクリメントされるべきです。
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が累積TSNのAckポイントを進める各SACKの到着時に、新たな累積TSNのAckによって、およびギャップAckブロックによって認めチャンクを含むことSACKに認めすべての新しいチャンクのバイトの総数によってpartial_bytes_acked、増加SSTHRESHより大きい。
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).
partial_bytes_acked場合、O（すなわち、SACKの到着前に、flightsizeはcwndを以上であった）、MTUによってCWNDが増加に等しいかCWNDより大きく、送信者が未処理データのバイトをcwndを以上たSACKの到着の前にあります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, 2*MTU) per RTO.
O送信者が与えられたトランスポートアドレスにデータを送信しないスロースタート、と同様に、トランスポート・アドレスのCWNDを最大に調整しなければならない（CWND / 2、2 * MTU）当たりRTO。
o When all of the data transmitted by the sender has been acknowledged by the receiver, partial_bytes_acked is initialized to 0.
O場合は、送信者が送信したデータのすべてが0に初期化されpartial_bytes_acked、受信機によって認められています。
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, 2*MTU) cwnd = ssthresh
SSTHRESH = MAX（CWND / 2、2 * MTU）CWND = SSTHRESH
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, 2*MTU) cwnd = 1*MTU
SSTHRESH = MAX（CWND / 2、2 * MTU）CWND = 1 * MTU
and assure 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.
そしてエンドポイントがそのアドレスへのデータの成功配信のための肯定応答を受信するまでは、複数の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の送信を開始すべきです。
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
エンドポイントが不足しているいくつかのTSNを示しSACK（複数可）を受信するたびに、高速再送信に関して行動を起こす前に、同じTSN（S）上の（その後のSACKの経由）3点の、さらにミスの指摘を待つべき。
When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall:
TSN（複数可）4期連続SACKに欠けていると報告されている場合、データの送信者がしなければなりません。
1) Mark the missing DATA chunk(s) for retransmission,
1）マークを再送信のために失われたデータのチャンク（複数可）、
2) 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項に記載の式に従って、欠落データチャンクが最後に送信された先のアドレス（ES）の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.
3）最も初期の何を決定する（すなわち、再送信のためにマークされた最も低いTSN）DATA塊は、パケットが送信された送付先輸送アドレスの経路MTUの制約を受ける単一のパケットに収まります。 K.は、単一のパケットでそれらのK DATAチャンクを再送この値を呼び出します。
4) Restart 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）再起動T3-RTXタイマー最後のSACKが最低優れたTSN番号は、そのアドレスに送信された、またはエンドポイントがそのアドレスに送信された最初の未処理データのチャンクを再送された場合にのみ認めました。
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 Sections 7.2.1 and 7.2.2 must be applied first.
注：受信したSACKはまた、新しいデータチャンクを承認し、累積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 4 and starting the fast retransmit procedure, the counter resets to 0.
上記の簡単な実装はSACKによって報告された各TSN穴用のカウンタを保持します。 TSN穴を報告各連続SACKのカウンタをインクリメント。 4に到達し、高速再送信手順を開始した後、カウンタが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高速回復の効果は、輻輳制御ウィンドウサイズに調整なしで自動的に達成されます。
[RFC1191] specifies "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 which exceed the MTU, other than occasional attempts to probe for a change in the Path MTU (PMTU). RFC 1191 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. [RFC1981] specifies the same mechanisms for IPv6. An SCTP sender using IPv6 MUST use Path MTU Discovery unless all packets are less than the minimum IPv6 MTU [RFC2460].
[RFC1191]は、エンドポイントが探索するために時折試み以外のMTUを超えている経路に沿って送信するパケットから所定のインターネット経路に沿った最大伝送単位（MTU）の推定値と控えるを維持することにより、「パスMTUディスカバリ」を指定しますパスMTU（PMTU）の変化。 RFC 1191は、現在のエンド・ツー・エンドのMTU設定を決定するだけでなく、この値の変化を検出するためのMTU発見メカニズムと戦略のその議論で完全です。 [RFC1981]はIPv6の同じメカニズムを指定します。すべてのパケットが最小のIPv6 MTU [RFC2460]未満でない限り、IPv6を使用してSCTP送信者は、パスMTUディスカバリーを使用しなければなりません。
An endpoint SHOULD apply these techniques, and SHOULD do so on a per-destination-address basis.
エンドポイントは、これらの技術を適用すべきである、とあたりの宛先アドレスに基づき、そうすべきです。
There are 4 ways in which SCTP differs from the description in RFC 1191 of applying MTU discovery to TCP:
SCTPはTCPにMTU探索を適用したRFC 1191に記述と異なっている4つの方法があります：
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) Elsewhere in this document, when the term "MTU" is discussed, it refers to the MTU associated with the destination address corresponding to the context of the discussion.
用語「MTU」が議論されている場合2）他の場所この文書に記載されている、それは議論の文脈に対応する宛先アドレスに関連付けられたMTUを指します。
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment Size". Accordingly, the MTU for each destination address SHOULD be initialized to a value no larger than the link MTU for the local interface to which packets for that remote destination address will be routed.
3）TCPとは異なり、SCTPは、「最大セグメントサイズ」の概念を持っていません。従って、各宛先アドレスのMTUは、そのリモート宛先アドレスに対するパケットがルーティングされる先のローカルインタフェースのリンクMTUよりも大きくない値に初期化されるべきです。
4) Since data transmission in SCTP is naturally structured in terms of TSNs rather than bytes (as is the case for TCP), the discussion in Section 6.5 of RFC 1191 applies: When retransmitting an IP datagram to a remote address for which the IP datagram appears too large for the path MTU to that address, the IP datagram SHOULD be retransmitted without the DF bit set, allowing it to possibly be fragmented. Transmissions of new IP datagrams MUST have DF set.
SCTPにおけるデータ伝送が自然のTSNの観点からではなく、バイト（TCPの場合のように）で構成されているので4）、RFC 1191のセクション6.5で議論が適用されます。ためのIPデータグラムのリモートアドレスにIPデータグラムを再送信する場合そのアドレスへのパスMTUに対して大きすぎる表示され、IPデータグラムは、それはおそらく断片化することができるように、DFビットを設定せずに再送されるべきです。新しいIPデータグラムの送信はDFを設定する必要があります。
5) The sender should track an association PMTU which 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.
5）送信者はピアの宛先アドレスのすべてのために発見された最小のPMTUなりアソシエーションPMTUを追跡する必要があります。複数の部分にメッセージを断片化すると、この関連PMTUは、各断片の大きさを計算するために使用されるべきです。これは、再送信がシームレスにIPフラグメンテーションに遭遇することなく別のアドレスに送信できるようになります。
Other than these differences, the discussion of TCP's use of MTU discovery in RFCs 1191 and 1981 applies to SCTP on a per-destination-address basis.
これらの相違点以外は、RFCの1191年と1981年のMTU発見のTCPの使用についての考察は、配送先ごとのアドレスベースでSCTPに適用されます。
Note: For IPv6 destination addresses the DF bit does not exist, instead the IP datagram must be fragmented as described in [RFC2460].
注意：IPv6の宛先のDFビットが存在しない[RFC2460]に記載されているように、代わりにIPデータグラムが断片化されなければならないアドレス。
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). 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 shall 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.
エンドポイントは、（それがマルチホームされている場合、ピアのすべての宛先トランスポートアドレスへの再送信を含む）ピアへの連続再送信の総数にカウンタを維持しなければなりません。このカウンタの値は、プロトコルパラメータ「Association.Max.Retrans」で示さ限界を超えた場合、エンドポイントは、ピアエンドポイントが到達不能に考慮しなければならないし、それが（したがって、関連が閉状態になる）に、任意のより多くのデータの送信を停止しなければなりません。加えて、エンドポイントは、上位層に失敗を報告し、必要に応じてその送信キューに残っているすべての未処理のユーザデータをバック報告しなければなりません。ピアエンドポイントが到達不能になったときに関連付けは自動的に閉じられます。
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.
カウンタが（SACKの受信によって）そのピアエンドポイントに送信されたデータチャンクが確認されるたびにリセットされなければならない、またはHEARTBEAT-ACKは、ピアエンドポイントから受信されます。
When its peer endpoint is multi-homed, an endpoint should keep a 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 a 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.
アイドルアドレスに送信されたHEARTBEATがRTO内に認めていないときにT3-RTXタイマーが任意のアドレスに期限が切れるたびに、または、その送信先アドレスのエラーカウンタがインクリメントされます。エラーカウンタの値がその宛先アドレスのプロトコルパラメータ「Path.Max.Retrans」を超えたときに、エンドポイントが非アクティブとして宛先トランスポートアドレスをマークする必要があり、通知は、上位層に送信されるべきです。
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で承認された場合、エンドポイントは、どのデータチャンクが送信された最後だったし（または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 the 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.
プライマリパスが（例えば、過度の再送信に）非アクティブとマークされたときに一方が存在し、アクティブである場合、送信者は自動的に代替の宛先アドレスに新しいパケットを送信することができます。プライマリパスが非アクティブにマークされたときに、複数の代替アドレスがアクティブな場合のみONEトランスポートアドレスは、選択されたと新しい宛先トランスポートアドレスとして使用する必要があります。
By default, an SCTP endpoint shall 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).
デフォルトでは、SCTP終点は、宛先トランスポートアドレス（ES）に定期的にHEARTBEATチャンクを送信することによって、そのピアのアイドル先トランスポートアドレス（ES）の到達性を監視しなければなりません。
A destination transport address is considered "idle" if no new chunk which 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を更新するために使用することができる新しいチャンク（通常、HEARTBEAT等INIT、COOKIE ECHOを、第一の送信データを含まない）場合、「アイドル」とみなされ、ハートビートは、現在の心拍の期間内に、それに送信されていませんそのアドレスの。これは、アクティブおよび非アクティブの両方の宛先アドレスに適用されます。
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が送られた先のエラーカウンタをクリアする必要があります。これは、実際には、以前になでエラーをクリアします（およびその他のエラーも同様にカウントします）。
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk.
HEARTBEATの受信機はすぐに受け取った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, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
ハートビートさせ、アイドル宛先アドレスに、ハートビート・チャンクは+/- 50％のジッタ、および指数バックオフで、その宛先アドレスとプロトコルパラメータ「HB.interval」のRTOごとに一度送信することが推奨されています以前HEARTBEATが応答がない場合は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 a implementation decision on how to choose which of the candidate idle destinations to heartbeat to (if more than one destination is idle).
プリミティブはHB.intervalを変更し、与えられた宛先アドレスにハートビートオンまたはオフにするSCTPユーザのために提供されます。 SCTPユーザにより設定されたハートビート間隔は、（任意の指数バックオフを含む）をその宛先のRTOに添加されます。一つだけのハートビートは、（複数の宛先がアイドル状態になっている場合）、ハートビートタイマーの期限が切れるたびに送信する必要があります。これは、（複数の宛先がアイドル状態の場合）に心拍候補アイドルの宛先のかを選択する方法については実装決定です。
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を発見するだけであろう。 HEARTBEATタイマーをチューニングするときに考慮しなければなりません。 HEARTBEATが唯一の関連にデータを送信して無効になっている場合は、ピアから失われたABORTを発見するでしょう。
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
それが正しく形成されている場合SCTPパケットは「青のうち」（OOTB）パケットと呼ばれている、すなわち、受信機のアドラー-32のチェック（6.8節を参照）を通過したが、受信機は、この先の関連性を識別することができませんパケットが属します。
The receiver of an OOTB packet MUST do the following:
OOTBパケットの受信機は、以下を行う必要があります。
1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise,
OOTBパケットが非ユニキャストアドレスへ又はからのものである場合は1）、静かにパケットを廃棄します。そうでなければ、
2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise,
OOTBパケットはABORTチャンクが含まれている場合は2）、受信機は静かOOTBパケットを破棄し、さらなる行動を取るてはなりません。そうでなければ、
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise,
3）5.1節で説明したように、パケットがINIT「0」に設定検証タグとチャンク、プロセス、それが含まれている場合。そうでなければ、
4) If the packet contains a COOKIE ECHO in the first chunk, process it as described in Section 5.1. Otherwise,
4）5.1節で説明したように、パケットは、それが、最初のチャンクの処理をCOOKIE ECHOを含む場合。そうでなければ、
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 no TCB was found. Otherwise,
パケットがSHUTDOWN ACKチャンクが含まれている場合5）、受信機は、SHUTDOWNのCOMPLETEとOOTBパケットの送信者に応答する必要があります。 SHUTDOWNがCOMPLETE送信する場合は、OOTBパケットの受信機は、SHUTDOWNのACKで受信された検証タグとアウトバウンドパケットの検証タグフィールドに入力し、何のTCBが見つからなかったことを示すためにチャンクフラグにTビットを設定する必要があります。そうでなければ、
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver should silently discard the packet and take no further action. Otherwise,
パケットがSHUTDOWN COMPLETEチャンクが含まれている場合は6）、受信機は静かにパケットを破棄し、それ以上の行動を取るべきではありません。そうでなければ、
7) If the packet contains a "Stale cookie" ERROR or a COOKIE ACK the SCTP Packet should be silently discarded. Otherwise,
パケットは「古いクッキー」ERRORまたはCOOKIE ACKが含まれている場合7）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 no TCB was found. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8）受信機は、ABORTとOOTBパケットの送信者に応答すべきです。 ABORTを送信する場合、OOTBパケットの受信機はOOTBパケットの検証タグフィールドで見つかった値とアウトバウンドパケットの検証タグフィールドに入力し、その何のTCBがないことを示すためにチャンクフラグにTビットを設定しなければなりません発見された。このABORTを送信した後、OOTBパケットの受信機はOOTBパケットを破棄し、それ以上の措置を講じてはなりません。
The Verification Tag rules defined in this section apply when sending or receiving SCTP packets which 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、COMPLETE SHUTDOWN、COOKIE ECHOを（5.1節を参照）を含んでいないSCTPパケットを受信したとき、ABORTまたはSHUTDOWN ACKチャンク適用されます。これらのチャンクタイプのいずれかを含む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 ACKがピアから受信したINITまたは開始タグパラメータのタグ値を持つ発信パケットの検証タグフィールドに入力しなければなりません。
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 shall 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 MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 検証タグは独自のタグ、またはそのピアのタグのいずれかと一致した場合、受信機はパケットを受け入れなければなりません。そうでない場合、受信機は静かにパケットを破棄し、それ以上の行動を取らないしなければなりません。
C) Rules for packet carrying SHUTDOWN COMPLETE:
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. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK.
- シャットダウンCOMPLETEを送信するときSHUTDOWN ACKの受信機は、次に、TCBを有する場合、宛先エンドポイントのタグが使用されなければなりません。何TCBは、送信者はSHUTDOWNのACKから検証タグを使用する必要があります存在しない場合のみ。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag OR 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.
- パケットの検証タグフィールドは、独自のタグが一致するか、そのピアのタグに設定されているとTビットはチャンクフラグに設定されている場合、COMPLETE SHUTDOWNの受信機がパケットを受け入れるもの。そうでない場合、受信機は静かにパケットを破棄し、それ以上の行動を取らないしなければなりません。それは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 Initial 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
SHUTDOWN ACKを運ぶパケットのためのE）のルール
- 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の手順は、他の言葉で、それはブルーパケットのうちとして扱われるべきである、続いされるべきです。
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 shall 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.
エンドポイントは、既存の関連付けを中止することを決定したときは、そのピアエンドポイントにABORTチャンクを送信しなければなりません。送信者は、発信パケットにピアの検証タグに記入しなければならないとABORTで任意のデータチャンクをバンドルしてはなりません。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
エンドポイントは、（また、8.4節を参照）ABORTチャンクを含む任意の受信パケットに応じてはいけません。
An endpoint receiving an ABORT shall 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 shall remove the association from its record, and shall report the termination to its upper layer.
検証タグをチェックした後、受信側のエンドポイントは、そのレコードから関連付けを削除するものとし、その上層に終了を報告するものとします。
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節を参照）、関連エンドポイントの上層が正常アソシエーションを閉じることができます。これは、関連付けが終了する前にシャットダウン開始のピアからのすべての未処理データのチャンクが配信されるようになります。
Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters 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 re-send the SHUTDOWN with the updated last sequential TSN received from its peer.
そのすべての未処理データが確認された後、エンドポイントは、それがピアから受信した累積TSN ACKフィールドの最後のシーケンシャルTSNを含むピアにSHUTDOWNチャンクを送信しなければなりません。その後、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.
セクション6.3のルールは、T2-シャットダウンのための適切なタイマ値を決定するために従わなければなりません。 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.
エンドポイントは、プロトコルパラメータ「Association.Max.Retrans」にSHUTDOWNチャンクの再送回数を制限する必要があります。このしきい値を超えた場合、エンドポイントは、TCBを破壊する必要があり、上位層に到達できピアエンドポイントを報告しなければならない（したがって、関連付けは、CLOSED状態に入ります）。ピアからのすべてのパケットを受信していてキューに入れられたDATAチャンクの全てを送信するピア十分な機会を与えて、エンドポイントの再送回数をクリアし、T2-シャットダウンタイマーを再起動する必要があります（つまりピアは、そのキューに入れられたDATAチャンクの全てが送信されます）まだ送信されていません。
Upon the reception of the SHUTDOWN, the peer endpoint shall
SHUTDOWNを受信すると、ピアエンドポイントは、条
- enter the SHUTDOWN-RECEIVED state,
- SHUTDOWN-RECEIVED状態に入り、
- stop accepting new data from its SCTP user
- その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.
- そのすべての未処理データチャンクは、SHUTDOWN送信者が受信したことを、チャンクの累積TSN ACKフィールドをチェックして、確認してください。
Once an endpoint as 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を送ってはいけません、そしてそれに続くSHUTDOWNチャンクを破棄しなければなりません。
If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall 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.
左の未処理データの塊が残っている場合は、SHUTDOWN受信機は、すべての未処理データのチャンクが確認されるまで、6節で定義された通常のデータ送信手順に従うことを継続します。しかし、SHUTDOWN受信機はそのSCTPユーザからの新しいデータを受け入れてはいけません。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall 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 re-send the SHUTDOWN ACK.
SHUTDOWN-SENT状態にある間、SHUTDOWN送信者は、直ちにSACK、SHUTDOWNチャンクで一つ以上のデータチャンク（複数可）を含む各受信パケットに応答、およびT2-シャットダウンタイマーを再起動する必要があります。それは、より優れたDATAチャンクを持っていない場合は、SHUTDOWNの受信機は、SHUTDOWN ACKを送信しなければならないし、SHUTDOWN-ACK-SENT状態に入る、それ自身のT2-シャットダウンタイマーを起動します。タイマーが期限切れになった場合、エンドポイントは、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の送信者は、プロトコルパラメータ「Association.Max.Retrans」にSHUTDOWN ACKチャンクの再送回数を制限する必要があります。このしきい値を超えた場合、エンドポイントは、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 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 assure that all its outstanding DATA chunks have been acknowledged before initiating the shutdown procedure.
エンドポイントは、そのすべての未処理データのチャンクはシャットダウン手順を開始する前に承認されていることを保証すべきです。
An endpoint should reject any new data request from its upper layer if it is in 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 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状態にあり、（SHUTDOWNのCOMPLETEが失われた場合など、）INITチャンクを受信した場合、この協会に所属し、送信元と宛先トランスポートアドレス（IPアドレスまたはINITチャンク内のいずれか）と、それは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アドレスを持つ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
INITまたはCOOKIE ECHOの送信者はSHUTDOWNのACKで受信された同じタグに設定された共通ヘッダの検証タグフィールドを持つSCTPパケット内COMPLETEスタンドアロンSHUTDOWNでSHUTDOWN-ACKの受信に応答しなければなりませんパケット。セクション8.4で定義されたように、これはブルーパケットのうち、と考えられています。 INITの送信者はT1-initが実行を継続することができますし、中に残っています
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.
COOKIE-WAITまたはCOOKIE-ECHOED状態。通常T1-のinitタイマ満了はINITまたはCOOKIEチャンクが再送させ、したがって、新しい関連付けを開始します。
If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the SHUTDOWN chunk SHOULD be silently discarded.
シャットダウンがクッキーWAITまたはCOOKIEエコーで受信された場合SHUTDOWNチャンクは静かに捨てられるべきで述べています。
If an endpoint is in 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 a SHUTDOWN-ACK-SENT state restarting its T2-shutdown timer.
エンドポイントがSHUTDOWN-SENT状態にあり、そのピアからSHUTDOWNチャンクを受信した場合、エンドポイントは、そのピアにSHUTDOWNのACKで即座に対応し、そのT2-シャットダウンタイマーを再起動SHUTDOWN-ACK-SENT状態に移行するものとします。
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 (ULP) shall request for 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インターフェイスを有していてもよいです。しかし、すべてのSCTPsは、すべての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 the 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はULPにローカルSCTPインスタンス名を返します。
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ローカルポート - SCTPポート番号、ULPは、指定したい場合は、
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インスタンス名、宛先輸送ADDR、アウトバウンドストリーム数） - >アソシエーションID [、送信先トランスポートADDRリスト] [、アウトバウンドストリーム数]
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 which defines the endpoint (see Section 1.4). If the local SCTP instance has not been initialized, the ASSOCIATE is considered an error.
ピアエンドポイントがエンドポイントを定義するトランスポート・アドレスのいずれかで指定しなければならない（1.4節を参照）。ローカル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協会のローカルのハンドルである協会イドは、協会の成功の確立に返されます。 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 address 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.
他の関連パラメータは、ピアの完全な宛先トランスポートアドレス、ならびにローカルエンドポイントのアウトバウンドストリーム数を含め、戻されてもよいです。返された宛先アドレスからトランスポートアドレスの一つが、このピアにSCTPパケットを送信するためのデフォルトのプライマリパスとしてローカルエンドポイントによって選択されます。返された「宛先輸送addrのリストは、」デフォルトのプライマリ・パスを変更したり、特定のトランスポートアドレスにパケットを送信する強制的に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は成功確立時に協会イドに加えて、関連パラメータを返すことができます。 ASSOCIATEプリミティブが非ブロッキング・コールとして実装されている場合、唯一の関連IDが返さなければならないと関連パラメータは、通知を通信を使用して渡さなければなりません。
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宛先輸送ADDR - アソシエーションが確立されるべきピア・エンドポイントのトランスポート・アドレスの一つとして指定されました。
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（協会イド） - >結果
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協会イド - SCTP協会へのローカルハンドル
Optional attributes:
オプションの属性：
None.
無し。
D) Abort
D）アボート
Format: ABORT(association id [, cause code]) -> result
フォーマット：ABORT（アソシエーションID [、原因コード]） - >結果
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 abortion 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協会イド - SCTP協会へのローカルハンドル
Optional attributes:
オプションの属性：
o cause code - 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] [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> result
フォーマット：（アソシエーションID、バッファアドレス、バイトカウント[コンテキスト] [、ストリームID] [ライフタイム] [、送信先トランスポートアドレス] [、unorderフラグ] [無バンドルフラグ] [、ペイロードプロトコル-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協会イド - 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コンテキスト - このユーザメッセージの輸送に障害が発生した場合ULPへ送信失敗通知に実施される任意の32ビット整数。
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 lifetime 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 lifetime option attached to the DATA chunk.
実装上の注意：より良いデータの寿命オプションをサポートするために、送信機は最後の瞬間に、アウトバウンドのDATAチャンクのTSN番号の割り当てをバック保持してもよいです。 TSN番号が割り当てられた後の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宛先トランスポートアドレス - このパケットが送られるべきであるため、ピアエンドポイントの宛先トランスポートアドレスの一つとして指定されました。可能な限り、SCTPではなく、現在のプライマリパスの、パケットを送信するために、この先のトランスポートアドレスを使用する必要があります。
o unorder 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フラグunorder - このフラグは、存在する場合、ユーザは、（すなわち、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.
無バンドルフラグ○ - 他のアウトバウンド・データチャンクと、このユーザデータをバンドルしない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ペイロードプロトコル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 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協会イド - SCTP協会へのローカルハンドル
o destination transport address - specified as one of the transport addresses of the peer endpoint, which should be used as primary address for sending packets. This overrides the current primary address information maintained by the local SCTP endpoint.
O宛先トランスポートアドレス - パケットを送信するための一次アドレスとして使用されるべきピア・エンドポイントのトランスポート・アドレスの一つとして指定されました。これは、ローカル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]
フォーマット：受信（アソシエーション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.
利用できるものがある場合には、このプリミティブは、ULPによって指定されたバッファ内にキューSCTPにおける最初のユーザメッセージを読み取るものとします。メッセージの読み取りのサイズは、バイト単位で、返されます。順序付けられたメッセージの場合等、検索に利用可能なより多くのメッセージがあるかどうかは、特定の実装に応じて、また、そのような送信者のアドレス、それが受信されたストリーム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協会イド - 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ペイロードプロトコルID - 受信したデータのペイロードプロトコルの種類を示すピアから受信される32ビットの符号なし整数。この値は、SCTPで不透明なデータとして渡されます。
H) Status
H）ステータス
Format: STATUS(association id) -> status data
フォーマット：STATUS（協会イド） - >ステータスデータ
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チャンクの数、受信を保留データチャンクの数を、プライマリパス上のプライマリパス、最新のSRTT、RTOプライマリパスに、他の宛先アドレスにSRTTとRTOなど
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association
O協会イド - SCTP協会へのローカルハンドル
Optional attributes:
オプションの属性：
None.
無し。
I) Change Heartbeat
I）の変更ハートビート
Format: CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> result
フォーマット：CHANGEHEARTBEAT（アソシエーション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協会イド - SCTP協会へのローカルハンドル
o destination transport address - specified as one of the transport addresses of the peer endpoint.
O宛先トランスポートアドレス - ピア・エンドポイントのトランスポート・アドレスの一つとして指定されました。
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, effects all destinations.
O間隔は - これは、宛先トランスポートアドレスにハートビートを有効にすることである場合に存在する場合、ハートビートの周波数を示します。この値は、先のトランスポートアドレスのRTOに追加されます。この値は、存在する場合、すべての宛先に影響を与えます。
J) Request HeartBeat
J）リクエストハートビート
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協会イド - 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.
ローカルSCTPアソシエーションが所与の指定された宛先のトランスポートアドレスに現在のSRTT測定値を報告するように指示します。返される結果は、ミリ秒単位で最新のSRTTを含む整数を指定できます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association
O協会イド - 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) -> result
フォーマット：SETFAILURETHRESHOLD（アソシエーションID、送信先トランスポートアドレス、障害しきい値） - >結果
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協会イド - 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協会イド - SCTP協会へのローカルハンドル
o protocol parameter list - The specific names and values of the protocol parameters (e.g., Association.Max.Retrans [see Section 14]) that the SCTP user wishes to customize.
Oプロトコルパラメータリスト - プロトコルパラメータの特定の名前と値（例えば、Association.Max.Retrans [セクション14を参照]）SCTPユーザがカスタマイズすることを望みます。
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に渡されます。
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ペイロードプロトコル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に渡されます。
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ペイロードプロトコル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 to be destroyed.
ローカル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 an 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）DATAは、通知に到着します
SCTP shall invoke this notification on the ULP when a user message is successfully received and ready for retrieval.
ユーザ・メッセージが正常に受信され、検索のために準備されたときにSCTPはULPにこの通知を起動しなければなりません。
The following may be optionally be passed with the notification:
以下に、必要に応じて通知して渡されることができます。
o association id - local handle to the SCTP association
O協会イド - SCTP協会へのローカルハンドル
o stream id - to indicate which stream the data is received on.
OストリームID - データに受信したストリーミング示します。
B) SEND FAILURE notification
B）障害通知を送信します
If a message can not be delivered SCTP shall invoke this notification on the ULP.
メッセージが配信できない場合はSCTPがULPにこの通知を呼び出すものとします。
The following may be optionally be passed with the notification:
以下に、必要に応じて通知して渡されることができます。
o association id - local handle to the SCTP association
O協会イド - SCTP協会へのローカルハンドル
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
Oデータ検索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コンテキスト - このメッセージに関連付けられた任意の情報（セクション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協会イド - 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新しいステータス - これは新しい状態を示します。
D) COMMUNICATION UP notification
D）通信UP通知
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 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プリミティブ自体の結果として返されます。その場合、通信UP通知は、アソシエーション開始者側で任意です。
The following shall be passed with the notification:
以下は、通知を渡さなければなりません。
o association id - local handle to the SCTP association
O協会イド - SCTP協会へのローカルハンドル
o status - This indicates what type of event has occurred
Oステータス - これは、発生したイベントの種類を示します
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協会イド - SCTP協会へのローカルハンドル
o status - This indicates what type of event has occurred; The status may indicate 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 - 未送信及び未確認データを取得するために使用される識別。
o last-acked - the TSN last acked by that peer endpoint;
O最後にACKさ - TSN最後そのピアエンドポイントによってACKさ。
o last-sent - the TSN last sent to that peer endpoint;
O最後に送られた - TSNは最後にその同輩終点に送られました。
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は、ピアからのエラーチャンクを受信し、ULPに通知することを決定する場合、それはULPに関するこの通知を呼び出すことができます。
The following can be passed with the notification:
以下は、通知を渡すことができます。
o association id - local handle to the SCTP association
O協会イド - SCTP協会へのローカルハンドル
o error info - this indicates the type of error and optionally some additional information received through the ERROR chunk.
Oエラー情報 - これはエラーの種類およびエラーチャンクを介して受信し、任意にいくつかの追加情報を示しています。
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協会イド - SCTP協会へのローカルハンドル
H) SHUTDOWN COMPLETE notification
H）SHUTDOWN COMPLETE通知
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協会イド - 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 operator(s) of systems running SCTP to analyze their particular situations and decide on the appropriate counter-measures.
SCTPは、潜在的に危険な状況の多種多様に使用することができます。それは彼らの特定の状況を分析し、適切な対策を決定するためにSCTPを実行しているシステムのオペレータ（S）のために重要です。
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を保護するために必要とされます。
In order to promote software code-reuse, to avoid re-inventing the wheel, and to avoid gratuitous complexity to SCTP, the IP Authentication Header [RFC2402] SHOULD be used when the threat environment requires stronger integrity protections, but does not require confidentiality.
脅威の環境は強い整合性保護を必要としますが、機密性を必要としない場合は、ソフトウェアコードの再利用を促進するための再発明し、ホイールを避けるために、そしてSCTPに無償煩雑さを避けるために、IP認証ヘッダ[RFC2402]は使用されるべきです。
A widely implemented BSD Sockets API extension exists for applications to request IP security services, such as AH or ESP from an operating system kernel. Applications can use such an API to request AH whenever AH use is appropriate.
広く実装BSDソケットAPIの拡張機能は、オペレーティングシステムのカーネルからそのようなAHやESPなどのIPセキュリティサービスを、要求するアプリケーションのために存在します。 AHの使用が適切である時はいつでもアプリケーションでは、AHを要求するために、このようなAPIを使用することができます。
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.
ほとんどの場合、機密性の侵害の危険性がないSCTPまたは下位層プロトコルオーバーヘッドに、シグナリングデータ・ペイロードに適用されます。それが本当であれば、SCTPユーザデータの暗号化のみが考慮されるかもしれません。補足チェックサムサービスと同様に、ユーザデータの暗号化には、SCTPユーザアプリケーションによって実行することができます。
Alternately, the user application MAY use an implementation-specific API to request that the IP Encapsulating Security Payload (ESP) [RFC2406] be used to provide confidentiality and integrity.
代わりに、ユーザアプリケーションは、IPカプセル化セキュリティペイロード（ESP）[RFC2406]は、機密性と完全性を提供するために使用されることを要求するために、実装固有のAPIを使用するかもしれません。
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ではなく、アプリケーションレベルの機密性の使用されるべきです。 ESPは、SCTPトラフィックの機密性を保護するために使用されている場合は、ESPは、機密性の脅威がある場合にも、強い整合性の脅威が存在しますので、暗号完全性保護は、使用しなければならない含ん変換暗号化。
Whenever ESP is in use, application-level encryption is not generally required.
ESPが使用されているときはいつでも、アプリケーションレベルの暗号化は、一般的に必要とされていません。
Regardless of where confidentiality is provided, the ISAKMP [RFC2408] and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key management.
かかわらず、機密性が提供される場合の、ISAKMP [RFC2408]とインターネット鍵交換（IKE）[RFC2409]は鍵管理のために使用されるべきです。
Operators should consult [RFC2401] for more information on the security services available at and immediately above the Internet Protocol layer.
オペレータは、利用可能とすぐに、インターネットプロトコル層の上のセキュリティ・サービスの詳細については、[RFC2401]を相談してください。
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.
ネットワーク機器は、アラームを生成することができ、トラフィックで不審な増加が発生した場合、ログインする必要があります。ログは、このような保護措置を講ずるために、ネットワークまたはSCTPシステムオペレータを助けるが使用着信リンクおよびソースアドレス（ES）の識別などの情報を提供しなければなりません。手続きは、虐待の明確なパターンが現れた場合、そのようなアラームに作用するオペレータのための場所にする必要があります。
The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way start-up 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ノードでリソースのコミットメントを延期するクッキーの使用、およびその使用の使用で、フラッディング攻撃に耐性があります検証タグは、確立された協会の流れの中に異質なパケットの挿入を防止します。
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 INIT's 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サーバーをあふれさせるために使用することができます。名前がIPアドレスにINITチャンクで受信されたホストを解決するDNSクエリの大きなバックログは、特定のドメインに複数のホストにINITのを送信することにより達成することができます。また、攻撃者は、ターゲットのホスト名を含むランダムホストへのINITを大量に送信することにより、第三者への間接的な攻撃でホスト名機能を使用することができます。 DNSリソース上の歪みに加えて、これはまた、ターゲットに送信されたINIT ACKの多数につながる可能性があります。このタイプの攻撃から保護するための一つの方法は、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ノードを有するものSCTPアソシエーションの最大を可能にすることができます。マスカレード攻撃者は、それを必要とするとき、後者はそうではないことができるように偽装したノードから来るようにという趣旨の関連付けを確立することを試みることができます。
- by deliberately allowing the impersonation to be detected, thereby provoking counter-measures which 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.
- そのようなシャットダウン要求として無関係なコンテンツを挿入することによって確立されたアソシエーションを妨害することによって。
SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Man-in-the-middle masquerade attacks are discussed in Section 11.3 below. Because the initial exchange is memoryless, 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スプーフィングによってブラインドマスカレード攻撃のリスクを低減します。 man-in-the-middleなりすまし攻撃は、セクション以下11.3で議論されています。初期交換が無記憶なので、何もロックアウト機構は、盲目の仮面舞踏会攻撃によってトリガされません。また、州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 ACKの受信などINIT要求や異常のロギングは敵対的な活動のパターンを検出する方法として考えられるかもしれません。しかし、そのような伐採の潜在的有用性は、フラッド攻撃を受けやすく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ユーザアプリケーションは、ローカルポリシーに基づいて、所定のアソシエーションおよびロギングのいずれかの中に不正または「ノーオペレーション」メッセージを大量に検出又は結果としての関連付けを終了することができなければなりません。
The objective of fraud is to obtain services without authorization and specifically without paying for them. In order to achieve this objective, the attacker must induce the SCTP user application at the target SCTP node to provide the desired service while accepting invalid billing data or failing to collect it. Repudiation is a related problem, since it may occur as a deliberate act of fraud or simply because the repudiating party kept inadequate records of service received.
詐欺の目的は、許可なしに、具体的に彼らのために支払うことなくサービスを得ることです。この目的を達成するために、攻撃者が無効な課金データを受け入れるか、またはそれを収集するために失敗しながら、所望のサービスを提供するターゲットSCTPノードのSCTPユーザアプリケーションを誘導しなければなりません。それは詐欺の故意の行為として発生したり否認当事者が受信したサービスの不十分なレコードを保持いうだけの理由以来否認は、関連する問題です。
Potential fraudulent attacks include interception and misuse of authorizing information such as credit card numbers, blind masquerade and replay, and man-in-the middle attacks which modify the packets passing through a target SCTP association in real time.
潜在的な詐欺的な攻撃は傍受や、クレジットカード番号、盲目の仮面舞踏会やリプレイ、およびマン・イン・リアルタイムでの目標SCTPアソシエーションを通過するパケットを変更する中間者攻撃などの情報を承認の誤用が含まれます。
The interception attack is countered by the confidentiality measures discussed in Section 11.2.3 above.
盗聴攻撃は、上記の11.2.3項で説明した機密保持の措置によって相殺されます。
Section 11.2.4.2 describes how SCTP is resistant to blind masquerade attacks, as a result of the four-way startup handshake and the Verification Tag. The Verification Tag and TSN together are protections against blind replay attacks, where the replay is into an existing association.
セクション11.2.4.2は、SCTPは4ウェイスタートアップハンドシェイクと検証タグの結果として、ブラインドマスカレード攻撃に耐性がある方法を説明します。リプレイは既存の関連付けにここで検証タグとTSNは一緒に、盲目のリプレイ攻撃に対する保護されています。
However, SCTP does not protect against man-in-the-middle attacks where the attacker is able to intercept and alter the packets sent and received in an association. For example, the INIT ACK will have sufficient information sent on the wire for an adversary in the middle to hijack an existing SCTP association. Where a significant possibility of such attacks is seen to exist, or where possible repudiation is an issue, the use of the IPSEC AH service is recommended to ensure both the integrity and the authenticity of the SCTP packets passed.
ただし、SCTPは、攻撃者が関連して送信され、受信したパケットを傍受し、変更することができman-in-the-middle攻撃を防ぐことはできません。例えば、INIT ACKは、既存のSCTPアソシエーションをハイジャックする途中で敵のためにワイヤ上で送信された十分な情報を有することになります。どこでこのような攻撃の重要な可能性が存在すると見られている、または可能な否認が問題であり、IPSEC AHサービスの利用には、整合性と渡されたSCTPパケットの信憑性の両方を確保することをお勧めします。
SCTP also provides no protection against attacks originating at or beyond the SCTP node and taking place within the context of an existing association. Prevention of such attacks should be covered by appropriate security policies at the host site, as discussed in Section 11.2.1.
SCTPはまた、攻撃SCTPノードで、またはを超えて発信され、既存の関連のコンテキスト内で行わに対する保護機能はありません。セクション11.2.1で説明したように、このような攻撃の防止には、ホストサイトで適切なセキュリティポリシーによってカバーされるべきです。
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 [RFC1750] can be helpful in selection of the key.
秘密鍵：MACを計算するために、このエンドポイントで使用する秘密鍵。これは、十分な長さの暗号の品質乱数であるべきです。 [RFC1750]での議論は、キーの選択に役立ちます。
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チャンクの1のピア（複数可）に渡されます。
SCTP Port: The local SCTP port number the endpoint is bound to.
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 :
私：タグは、すべての着信パケットに期待し、検証に送ら：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.
状態：どのような状態の関連性を示す状態変数：すなわち、COOKIE-WAIT、COOKIE-エコーは、確立され、である：SHUTDOWN-PENDING、SHUTDOWN-SENT、SHUTDOWN-受信：SHUTDOWN-ACK-SENT。
Note: No "CLOSED" state is illustrated since if a
association is "CLOSED" its TCB SHOULD be removed.
Peer : A list of SCTP transport addresses that the peer is Transport : bound to. 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.
ピア：ピアが交通であることをSCTP輸送アドレスのリスト：に結合します。この情報は、INITまたはアドレスから派生している：INIT ACKとインバウンドパケットの一覧を関連付けるために使用されます。与えられた協会で。通常、この情報は以下のとおりです。ハッシュ化またはクイック検索と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.
プライマリ：ピアエンドポイントのアドレス：これは、現在の主要な目的地の搬送路です。このエンドポイント上のソーストランスポートアドレス：それも指定することができます。
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.
ピアの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).
次のTSN：新しいDATAチャンクに割り当てられる次のTSN番号。 ：これは、ピアにINITまたはINIT ACKチャンクで送信され：およびDATAチャンクが割り当てられるたびにインクリメント：TSNを（通常は単に送信する前または中：フラグメンテーション）。
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.
最終受信数：これは最後のTSNが順番に受けています。この値TSNは：、ピアの初期TSNを取ることによって最初に設定されている：INITまたはINIT ACKチャンクで受信し、そして：それから1を引い。
Mapping : An array of bits or bytes indicating which out of Array : order TSN's 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.
マッピング：（に対して：最終受信数TSN）順TSN者が受信された：配列のうち示すビット又はバイトのアレイ。全くギャップが順序から外れない、すなわち、存在しない場合：全てゼロ：パケットが受信された、この配列は、に設定されます。循環バッファ又はビットアレイ：この構造は、の形態であってもよいです。
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, SACK's are not delayed (see Section : 6).
Ack状態：SACKで応答する：次の受信パケットがあれば、このフラグは示しています。これは初期化されます：0に、パケットは、それがインクリメントされる受信した場合。 ：データチャンク順不同で受信されない：これは、何をする場合にのみ使用されている：この値は2以上に達した場合、SACKが送信され：値は0に注意することがリセットされます。 DATAチャンクが時：順不同であり、SACKのは（セクションを参照してください。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.
アウトバウンド：アウトバウンドストリームを追跡するための構造体の配列。ストリーム：通常、次のシーケンス番号を含むTO：ストリームで送信すること。
Reasm Queue : A re-assembly queue.
Reasmキュー：再組み立てキュー。
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 needs 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.
エラー：この先、すなわちしきい値の現在のエラーしきい値：この値に達する：エラーカウントがあればダウン先をマークどのような値。
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 6.2.2)
部分：CWNDの増加追跡方法バイトにACKさ：輻輳回避モード（セクション6.2.2を参照）
state : The current state of this destination, i.e. DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, etc.
状態：この先の現在の状態、即ちDOWN、UP、：ALLOW-HB、NO-HEARTBEAT、等
PMTU : The current known path MTU.
PMTU：現在知られているパスMTU。
Per : A timer used by each destination. Destination : Timer :
パー：各宛先が使用するタイマー。目的地：タイマー：
RTO-Pending : A flag used to track if one of the DATA chunks sent to this address is currently being used to compute a RTT. If this flag is 0, the next DATA chunk sent to this destination should be used to compute a RTT and this flag should be set. Every time the RTT calculation completes (i.e. the DATA chunk is SACK'd) clear this flag.
RTO-保留：フラグは、このアドレスに送信されたデータチャンクのいずれかが現在RTTを計算するために使用されている場合を追跡するために使用されます。このフラグが0である場合、この宛先に送信される次のデータチャンクは、RTTを計算するために使用されるべきであり、このフラグが設定されるべきです。 RTTの算出が完了するたびに（すなわち、データチャンクがSACK'dである）、このフラグをクリアします。
last-time : The time this destination was last sent to. This can be used : used to determine if a HEARTBEAT is needed.
前回：この先は、最後に送信された時刻。これは使用することができます。HEARTBEATが必要かどうかを決定するために使用します。
Out Queue : A queue of outbound DATA chunks.
アウトキュー：アウトバウンドDATAチャンクのキュー。
In Queue : A queue of inbound DATA chunks.
キュー内：インバウンドDATAチャンクのキュー。
This protocol will require port reservation like TCP for the use of "well known" servers within the Internet. All current TCP ports shall be automatically reserved in the SCTP port address space. New requests should follow IANA's current mechanisms for TCP.
このプロトコルは、インターネット内の「周知の」サーバの使用のためにTCPのようなポートの予約が必要になります。現在のすべてのTCPポートは自動的にSCTPポートアドレス空間内に確保されなければなりません。新しい要求は、TCPのためのIANAの現在のメカニズムに従ってください。
This protocol may also be extended through IANA in three ways:
このプロトコルはまた、3通りの方法でIANAによって延長することができます。
-- through definition of additional chunk types, -- through definition of additional parameter types, or -- through definition of additional cause codes within ERROR chunks
- 追加のチャンクタイプの定義を通じて、 - ERRORチャンク内の追加原因コードの定義による - 追加のパラメータの型の定義、または貫通
In the case where a particular ULP using SCTP desires to have its own ports, the ULP should be responsible for registering with IANA for getting its ports assigned.
SCTPを使用して、特定のULPは独自のポートを持っていることを望む場合には、ULPは、割り当てられたそのポートを取得するためにIANAに登録する責任を負わなければなりません。
The definition and use of new chunk types is an integral part of SCTP. Thus, new chunk types are assigned by IANA through an IETF Consensus action as defined in [RFC2434].
新しいチャンクタイプの定義と使用は、SCTPの不可欠な部分です。 [RFC2434]で定義されるようにこのように、新しいチャンクタイプはIETF Consensus動作を通してIANAによって割り当てられます。
The documentation for a new chunk code type must include the following information: 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 Consensus動作を介して行われます。チャンクパラメータのドキュメントには、以下の情報を含まなければなりません：
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に記載した一般的なタイプレングス値の形式に準拠しなければなりません。
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）の詳細は、このパラメータ・タイプの使用目的の記述、及びこのパラメータの型の複数のインスタンスが同じチャンク内に見出すことができるかどうか、およびどのような状況下での指示。
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]で定義されるように、追加の原因コードは、仕様必要なアクションを介して65535の範囲11に配置されてもよいです。提供された文書は、次の情報を含める必要があります。
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.
この原因コードとのSCTP終点がERRORを発行する（またはABORTする条件）のb）の詳細な説明。
c) Expected action by the SCTP endpoint which receives an ERROR (or ABORT) chunk containing this cause code.
この原因コードを含むERROR（またはABORT）塊を受けるSCTP終点によるc）期待のアクション。
d) Detailed description of the structure and content of data fields which 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 two bytes contain the cause code value -- last two bytes contain length of the Cause Parameter.
- 最初の2つのバイトは、原因コード値を含む - 最後の2つのバイトは、原因パラメータの長さを含みます。
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.
データチャンクに不特定のペイロードプロトコル識別子を示すために、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との任意の特定のプロトコル識別子を標準化すべきです。任意の特定のペイロードプロトコル識別子の使用は、SCTPの範囲外です。
The following protocol parameters are RECOMMENDED:
以下のプロトコルパラメータを推奨します。
RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds 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
RTO.Initial - 3秒RTO.Min - 1秒RTO.Max - 60秒RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60秒Association.Max.Retrans - 10回のパス。 Max.Retrans - （宛先アドレスごと）5つの試みMax.Init.Retransmits - 8つの試みHB.interval - 30秒
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10).
実装上の注意：SCTPの実装は（セクション10を参照）ULPは、これらのプロトコルパラメータの一部をカスタマイズすることを可能にします。
Note: RTO.Min SHOULD be set as recommended above.
注：上記の推奨通りRTO.Minを設定する必要があります。
The authors wish to thank 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.に感謝したいですアトキンソン、リチャード・バンド、スコット・ブラッドナー、スティーブBellovin氏、ピーター・バトラー、ラムDantu、R. Ezhirpavai、マイク・フィスク、サリー・フロイド、敦福本、マット・ホールドレッジ、ヘンリーHouh、クリスチャンのHuitema、ゲイリーLehecka、ジョナサン・リー、デビッド・レーマン、ジョンLoughney 、ダニエル・ルアン、バリーNagelberg、トーマスNarten氏、エリックNordmarkと、リンドンオング、Shyamalプラサド、ケルビンポーター、ハインツPrantner、ヤルノRajahalme、レイモンドE.リーブス、レニーRevis、イバン・ロドリゲス・アリアス、A. Sankarの、グレッグSidebottom、ブライアンWyld、ラ・モンテYarroll、そして彼らの貴重なコメントのための他の多くの。
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA
ランドールR.スチュワート24燃える柴トレイル。クリスタルレイク、IL 60012 USA
Phone: +1-815-477-2127 EMail: rrs@cisco.com
電話：+ 1-815-477-2127 Eメール：rrs@cisco.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA
私はIEモトローラ社1501 W.シュウ再ドライブをXオリンピックアイスQ、＃2309アーリントンハイツ、IL 60004 USA
Phone: +1-847-632-3028 EMail: qxie1@email.mot.com
電話：+ 1-847-632-3028 Eメール：qxie1@email.mot.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
ケンMorneaultシスコシステムズ13615ダレステクノロジードライブハーンドン。 20171 USA
Phone: +1-703-484-3323 EMail: kmorneau@cisco.com
電話：+ 1-703-484-3323 Eメール：kmorneau@cisco.com
Chip Sharp Cisco Systems Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
チップシャープシスコシステムズ株式会社7025キットクリーク道路リサーチトライアングルパーク、NC 27709 USA
Phone: +1-919-392-3121 EMail: chsharp@cisco.com
電話：+ 1-919-392-3121 Eメール：chsharp@cisco.com
Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich Germany
ハンスユルゲンシュヴァルツェンバウアーSIEMENS AG Hofmannstr。 51 81359ミュンヘンドイツ
Phone: +49-89-722-24236 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
電話：+ 49-89-722-24236 Eメール：HannsJuergen.Schwarzbauer@icn.siemens.de
Tom Taylor Nortel Networks 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8
トムテイラーノーテル1852ロレーヌアベニュー。オタワ、オンタリオカナダK1H 6Z8
Phone: +1-613-736-0961 EMail: taylor@nortelnetworks.com
電話：+ 1-613-736-0961 Eメール：taylor@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000 Australia
イアンRytinaエリクソンオーストラリア360分の37エリザベスストリートメルボルン、ビクトリア3000オーストラリア
Phone: +61-3-9301-6164 EMail: ian.rytina@ericsson.com
電話：+ 61-3-9301-6164 Eメール：ian.rytina@ericsson.com
Malleswar Kalla Telcordia Technologies 3 Corporate Place PYA-2J-341 Piscataway, NJ 08854 USA
MalleswarカラのTelcordia Technologies社3コーポレート・プレイスPYA-2J-341ピスカタウェイ、NJ 08854 USA
Phone: +1-732-699-3728 EMail: mkalla@telcordia.com
電話：+ 1-732-699-3728 Eメール：mkalla@telcordia.com
Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA
LixiaチャンUCLAコンピュータサイエンス学部4531G Boelterホールロサンゼルス、CA 90095から1596 USA
Phone: +1-310-825-2695 EMail: lixia@cs.ucla.edu
電話：+ 1-310-825-2695 Eメール：lixia@cs.ucla.edu
Vern Paxson ACIRI 1947 Center St., Suite 600, Berkeley, CA 94704-1198 USA
バークレー、CA 94704-1198 USAバーン・パクソンACIRI 1947センターセント、スイート600、
Phone: +1-510-666-2882 EMail: vern@aciri.org
電話：+ 1-510-666-2882 Eメール：vern@aciri.org
[RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.（編）、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.（編）、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1123] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.とJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年8月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]モーガン、D.、Schertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[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、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
「エンドツーエンドのネットワークパスのプロパティの推定について」[ALLMAN99]オールマン、M.とパクソン、V.、PROC。 SIGCOMM'99、1999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[FALL96]秋、K.とフロイド、S.、タホ、リノ、およびSACK TCP、コンピュータコミュニケーションレビュー、V. 26 N. 3、1996年7月、頁5-21のシミュレーションベースの比較。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]イーストレーク、D.（編）、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]ドイツP.とJ. Gailly氏、 "ZLIB圧縮データフォーマット仕様バージョン3.3"、RFC 1950、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]フレイザー、B.、 "サイトセキュリティハンドブック"、FYI 8、RFC 2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]カーン、P.とW.シンプソン、 "Photuris：セッション鍵管理プロトコル"、RFC 2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]サベージ、S.、カードウェル、N.、Wetherall、D.、およびアンダーソン、T.、 "ふらちなレシーバーとのTCP輻輳制御"、ACMコンピュータコミュニケーションレビュー、29（5）、1999年10月。
Appendix A: Explicit Congestion Notification
付録A：明示的輻輳通知
ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", RFC 2481, January 1999) 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 RFC 2481 should be followed with the following exceptions.
ECN（ラマクリシュナン、K.、フロイド、S.、「明示的輻輳通知」、RFC 2481、1999年1月）データグラム損失の外輻輳の自覚する方法を詳述IPに提案された拡張を記述しています。これは、実装がSCTPに追加することを選択するかもしれないオプション機能です。この付録では、彼らがこの機能を実装することを選択した場合、実装が注意する必要がありますわずかな違いを詳しく説明します。一般的RFCに2481年には、以下の例外を除いて従ってください。
Negotiation:
ネゴシエーション：
RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets two bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to assure 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:
RFC2481は、TCP接続のSYNとSYN-ACK段階でECNの交渉を詳述します。 SYNの送信者は、TCPフラグに2ビットを設定し、SYN-ACKの送信者は、1ビットのみを設定します。この背後にある理由は、両側が本当にECNことができる保証することです。 SCTPについては、これは必要ありません。エンドポイントがECNであることを示すために、可能なエンドポイントは、TLVがECNのために予約INIT及びまたはINIT ACKチャンクに追加する必要があります。この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-エコー：
RFC 2481 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:
RFC 2481は、受信機がネットワークから到着したビット（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：
RFC 2481 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.
RFC 2481は、その輻輳ウィンドウを減少させたことをピアに示すために、その次のアウトバウンド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は、コントロールチャンクと考えられています。
Appendix B Alder 32 bit checksum calculation
付録Bアルダー32ビットのチェックサム計算
The Adler-32 checksum calculation given in this appendix is copied from [RFC1950].
この付録に示さアドラー-32チェックサムの計算は、[RFC1950]からコピーされます。
Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order.
アドラー-32バイト当たり累積2点の合計で構成されている：S1はすべてのバイトの合計であり、S2は全てS1の値の合計です。両方の合計は、モジュロ65521. S1がゼロにS2では、1に初期化されて行われます。アドラー-32チェックサムは、ネットワークバイト順でのS2 * 65536 + S1として記憶されます。
The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
次のCコードは、データバッファのアドラー-32チェックサムを計算します。それはない速さのために、明確さのために書かれています。サンプルコードは、ANSI Cプログラミング言語です。非Cユーザーは、簡単にこれらのヒントを読むことを見つけることがあります。
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should be
initialized to 1.
Usage example:
使用例：
unsigned long adler = 1L;
unsigned long型アドラー= 1L。
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。