RFC4960

http://tools.ietf.org/html/rfc4960
Page 70まで

Network Working Group R. Stewart, Ed.
Request for Comments: 4960 September 2007
Obsoletes: 2960, 3309
Category: Standards Track

Stream Control Transmission Protocol
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.
このドキュメントはインターネットコミュニティにインターネット標準の規定とプロトコルと改良のための提案と議論の要求をする。
標準化状態とプロトコル状態はSTD1の最新版を参照してください。
このメモの配布には制限がない。

Abstract
概要

This document obsoletes RFC 2960 and RFC 3309. It describes the
Stream Control Transmission Protocol (SCTP). SCTP is designed to
transport Public Switched Telephone Network (PSTN) signaling messages
over IP networks, but is capable of broader applications.
このドキュメントはRFC2960とRFC3309を廃止する。
このドキュメントはStream Control Transmission Protocol(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等のコネクションレスパケット網上で動作する信頼性の高いプロトコルである。
SCTPはユーザーに下記のサービスを提供する。

-- acknowledged error-free non-duplicated transfer of user data,
-- ユーザデータのエラー無し、重複無しの送信

-- data fragmentation to conform to discovered path MTU size,
-- Path MTUサイズに適合するためのデータの分割(フラグメント)

-- sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user
messages,
-- 個々のユーザメッセージの到達順序のオプションを使用した
複数ストリーム内のユーザメッセージの順序送信

-- optional bundling of multiple user messages into a single SCTP
packet, and
-- 単一SCTPパケットに複数のユーザメッセージを任意にバンドルする

-- network-level fault tolerance through supporting of multi-homing
at either or both ends of an association.
-- アソシエーションによるマルチホーミングのサポートによるネットワークレベルの障害耐性。

The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.
SCTPの設計は輻輳制御に適切な振る舞いと、フラッディング、マスカレード攻撃への耐性が含まれる。

Stewart Standards Track [Page 1]

RFC 4960 Stream Control Transmission Protocol September 2007

Table of Contents

1. Introduction ....................................................5
1.導入
1.1. Motivation .................................................5
1.1. モチベーション
1.2. Architectural View of SCTP .................................6
1.2. SCTPのアーキテクチャ観点
1.3. Key Terms ..................................................6
1.3. 用語
1.4. Abbreviations .............................................10
1.4. 略語
1.5. Functional View of SCTP ...................................10
1.5 SCTPの機能的観点
1.5.1. Association Startup and Takedown ...................11
1.5.1. AssociationのStartupとTakedown
1.5.2. Sequenced Delivery within Streams ..................12
1.5.2. ストリーム内の順序送信
1.5.3. User Data Fragmentation ............................12
1.5.3. ユーザデータの分割(フラグメント)
1.5.4. Acknowledgement and Congestion Avoidance ...........12
1.5.4. Acknowledgementと輻輳回避
1.5.5. Chunk Bundling .....................................13
1.5.5. チャンクバンドリング
1.5.6. Packet Validation ..................................13
1.5.6 パケット検証
1.5.7. Path Management ....................................13
1.5.7. パスマネジメント
1.6. Serial Number Arithmetic ..................................14
1.6 シリアルナンバーの計算
1.7. Changes from RFC 2960 .....................................15
1.7. RFC2960からの変更点
2. Conventions ....................................................15
2. ルール
3. SCTP Packet Format .............................................15
3. SCTPパケットフォーマット
3.1. SCTP Common Header Field Descriptions .....................16
3.1. SCTP共通ヘッダーフィールドの説明
3.2. Chunk Field Descriptions ..................................17
3.2. チャンクフィールドの説明
3.2.1. Optional/Variable-Length Parameter Format ..........19
3.2.1. オプション/可変長パラメータのフォーマット
3.2.2. Reporting of Unrecognized Parameters ...............21
3.2.2. 認められていないパラメータの報告
3.3. SCTP Chunk Definitions ....................................21
3.3. SCTPチャンク定義
3.3.1. Payload Data (DATA) (0) ............................22
3.3.1. ペイロードデータ (DATA) (0)
3.3.2. Initiation (INIT) (1) ..............................24
3.3.2 Initialtion (INIT) (1)
3.3.2.1. Optional/Variable-Length Parameters in INIT ........................27
3.3.2.1 INITのオプション/可変長パラメータ
3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30
3.3.3. Initiation Acknowledgement (INIT ACK) (2)
3.3.3.1. Optional or Variable-Length Parameters ....33
3.3.3.1. オプション/可変長パラメータ
3.3.4. Selective Acknowledgement (SACK) (3) ...............34
3.3.4 Selective Acknowledgement (SACK) (3)
3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38
3.3.5. Heartbeat Request (HEARTBEAT) (4)
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)
3.3.7. Abort Association (ABORT) (6) ......................40
3.3.7. Abort Association (ABORT) (6)
3.3.8. Shutdown Association (SHUTDOWN) (7) ................41
3.3.8. Shutdown Association (SHUTDOWN) (7)
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8)
3.3.10. Operation Error (ERROR) (9) .......................42
3.3.10. Operation Error (ERROR) (9)
3.3.10.1. Invalid Stream Identifier (1) ............44
3.3.10.1 Invalid Stream Identifier (1)
3.3.10.2. Missing Mandatory Parameter (2) ..........44
3.3.10.2 Missing Mandatory Parameter (2)
3.3.10.3. Stale Cookie Error (3) ...................45
3.3.10.3. Stale Cokie Error (3)
3.3.10.4. Out of Resource (4) ......................45
3.3.10.4. Out of resource (4)
3.3.10.5. Unresolvable Address (5) .................46
3.3.10.5. Unresolvable Address (5)
3.3.10.6. Unrecognized Chunk Type (6) ..............46
3.3.10.6. Unrecognized Chunk Type (6)
3.3.10.7. Invalid Mandatory Parameter (7) ..........47
3.3.10.7. Invalid Mandatory Parameter (7)
3.3.10.8. Unrecognized Parameters (8) ..............47
3.3.10.8. Unrecognized Parameters (8)
3.3.10.9. No User Data (9) .........................48
3.3.10.9. No User Data (9)
3.3.10.10. Cookie Received While Shutting Down (10) ...............................48
3.3.10.10. Cookie Received While Shutting Down (10)

Stewart Standards Track [Page 2]

RFC 4960 Stream Control Transmission Protocol September 2007

3.3.10.11. Restart of an Association with New Addresses (11) ......................49
3.3.10.11 Restart of an Association with New Addresses (11)
3.3.10.12. User-Initiated Abort (12) ...............49
3.3.10.12 User-Initiated Abort (12)
3.3.10.13. Protocol Violation (13) .................50
3.3.10.13 Protocol Violation (13)
3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50
3.3.11. Cookie Echo (COOKIE ECHO) (11)
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14)
4. SCTP Association State Diagram .................................52
4. SCTP Association状態遷移図
5. Association Initialization .....................................56
5. Association Initialization
5.1. Normal Establishment of an Association ....................56
5.1. Associationの通常の確立
5.1.1. Handle Stream Parameters ...........................58
5.1.1. Streamパラメータの処理
5.1.2. Handle Address Parameters ..........................58
5.1.2. Addressパラメータの処理
5.1.3. Generating State Cookie ............................61
5.1.3. State Cookieの生成
5.1.4. State Cookie Processing ............................62
5.1.4. State Cookieの処理
5.1.5. State Cookie Authentication ........................62
5.1.5. State Cookieの認証
5.1.6. An Example of Normal Association Establishment .....64
5.1.6. 通常のAssociation確立の例
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and ..........................................65
5.2. 重複、予期しないINIT、INIT ACK、COOKIE ECHOの処理
5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) .......................66
5.2.1. COOKIE-WAIT or COOKIE-ECHOED状態でのINIT受信
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, .............................66
5.2.2. CLOSED、COOKIE-ECHOED以外の状態での予期しないINIT
5.2.3. Unexpected INIT ACK ................................67
5.2.3. 予期しないINIT ACK
5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67
5.2.4. TCBが存在する場合のCOOKIE ECHOの処理
5.2.4.1. An Example of a Association Restart .......69
5.2.4.1 Association Restartの例
5.2.5. Handle Duplicate COOKIE-ACK. .......................71
5.2.5. COOKIE-ACK重複の処理
5.2.6. Handle Stale COOKIE Error ..........................71
5.2.6. COOKIE Error状態の処理
5.3. Other Initialization Issues ...............................72
5.3. 他のInitialization問題
5.3.1. Selection of Tag Value .............................72
5.3.1. Tag Valueの選択
5.4. Path Verification .........................................72
5.4. パス検証
6. User Data Transfer .............................................73
6. ユーザデータ送信
6.1. Transmission of DATA Chunks ...............................75
6.1. データチャンクの送信
6.2. Acknowledgement on Reception of DATA Chunks ...............78
6.2. データチャンク受信のAcknowledgement
6.2.1. Processing a Received SACK .........................81
6.2.1. SACK受信の処理
6.3. Management of Retransmission Timer ........................83
6.3. 再送タイマのマネジメント
6.3.1. RTO Calculation ....................................83
6.3.1. RTOの計算
6.3.2. Retransmission Timer Rules .........................85
6.3.2. 再送タイマのルール
6.3.3. Handle T3-rtx Expiration ...........................86
6.3.3. T3-rtx期限切れの処理
6.4. Multi-Homed SCTP Endpoints ................................87
6.4. Multi-Homed SCTPエンドポイント
6.4.1. Failover from an Inactive Destination Address ......88
6.4.1. 非アクティブな宛先アドレスからのFailover(障害迂回)
6.5. Stream Identifier and Stream Sequence Number ..............88
6.5. Stream Identifier and Stream Sequence Number
6.6. Ordered and Unordered Delivery ............................88
6.6. 順序送信と非順序送信
6.7. Report Gaps in Received DATA TSNs .........................89
6.7. 受信したDATA TSNのGaps報告
6.8. CRC32c Checksum Calculation ...............................90
6.8. CRC32チェックサムの計算
6.9. Fragmentation and Reassembly ..............................91
6.9. 分割と組み立て
6.10. Bundling .................................................92
6.10. バンドリング
7. Congestion Control .............................................93
7. 輻輳制御
7.1. SCTP Differences from TCP Congestion Control ..............94
7.1 TCP輻輳制御とSCTPの違い
Stewart Standards Track [Page 3]

RFC 4960 Stream Control Transmission Protocol September 2007

7.2. SCTP Slow-Start and Congestion Avoidance ..................95
7.2. SCTP Slow-Startと輻輳回避
7.2.1. Slow-Start .........................................96
7.2.1 Slow-Start
7.2.2. Congestion Avoidance ...............................97
7.2.2. 輻輳回避
7.2.3. Congestion Control .................................98
7.2.3. 輻輳制御
7.2.4. Fast Retransmit on Gap Reports .....................98
7.2.4. Gap ReportのFast Retransmit
7.3. Path MTU Discovery .......................................100
7.3. Path MTU Discovery
8. Fault Management ..............................................100
8. Fault Management
8.1. Endpoint Failure Detection ...............................100
8.1 エンドポイント障害検知
8.2. Path Failure Detection ...................................101
8.2. パス障害検知
8.3. Path Heartbeat ...........................................102
8.3. Path Heartbeat
8.4. Handle "Out of the Blue" Packets .........................104
8.4. "Out of the Blue"パケットの処理
8.5. Verification Tag .........................................105
8.5. Tagの検証
8.5.1. Exceptions in Verification Tag Rules ..............105
8.5.1. Tagルール検証の例外
9. Termination of Association ....................................106
9. Associationの終了
9.1. Abort of an Association ..................................107
9.1. AssociationのAbort
9.2. Shutdown of an Association ...............................107
9.2. AssociationのShutdown
10. Interface with Upper Layer ...................................110
10. 上位レイヤのInterface
10.1. ULP-to-SCTP .............................................110
10.1 上位レイヤからSCTP
10.2. SCTP-to-ULP .............................................120
10.2. SCTPから上位レイヤ
11. Security Considerations ......................................123
11. セキュリティの考慮
11.1. Security Objectives .....................................123
11.1 セキュリティの目的
11.2. SCTP Responses to Potential Threats .....................124
11.2. 脆弱性へのSCTPの対応
11.2.1. Countering Insider Attacks .......................124
11.2.1 Inside攻撃への対応
11.2.2. Protecting against Data Corruption in the Network ..........................................124
11.2.2 ネットワーク内のデータ破損に対する保護
11.2.3. Protecting Confidentiality .......................124
11.2.3 機密性の保護
11.2.4. Protecting against Blind Denial-of-Service Attacks ........................125
11.2.4. DoS攻撃からの保護
11.2.4.1. Flooding ................................125
11.2.4.1. Flooding
11.2.4.2. Blind Masquerade ........................126
11.2.4.2. Blind Masquerade
11.2.4.3. Improper Monopolization of Services .....127
11.2.4.3. 不適切なサービス独占
11.3. SCTP Interactions with Firewalls ........................127
11.3. ファイヤーウォールとSCTPの作用
11.4. Protection of Non-SCTP-Capable Hosts ....................128
11.4. SCTP非対応ホストの保護
12. Network Management Considerations ............................128
12. ネットワークマネジメントの考慮
13. Recommended Transmission Control Block (TCB) Parameters ......129
13. 推奨されるTCBパラメータ
13.1. Parameters Necessary for the SCTP Instance ..............129
13.1. SCTPインスタンスに必要なパラメータ
13.2. Parameters Necessary per Association (i.e., the TCB) ....129
13.2. Association(すなわちTCB)毎に必要なパラメータ
13.3. Per Transport Address Data ..............................131
13.3. Transport Adddress Data毎に
13.4. General Parameters Needed ...............................132
13.4. 一般的に必要なパラメータ
14. IANA Considerations ..........................................132
14. IANAの考慮
14.1. IETF-defined Chunk Extension ............................132
14.1 IETF定義のチャンク拡張
14.2. IETF-Defined Chunk Parameter Extension ..................133
14.2 IETF定義のチャンクパラメータ拡張
14.3. IETF-Defined Additional Error Causes ....................133
14.3. IETF定義の追加エラーCause
14.4. Payload Protocol Identifiers ............................134
14.4 ペイロードプロトコルの識別子
14.5. Port Numbers Registry ...................................134
14.5. ポート番号登録簿
15. Suggested SCTP Protocol Parameter Values .....................136
15. 提案されるSCTPプロトコルパラメータ値
16. Acknowledgements .............................................137
16. Acknowledgements
Appendix A. Explicit Congestion Notification .....................139
Appendix A. 詳細な輻輳通知
Stewart Standards Track [Page 4]

RFC 4960 Stream Control Transmission Protocol September 2007

Appendix B. CRC32c Checksum Calculation ..........................140
Appendix A. CRC32チェックサムの計算
Appendix C. ICMP Handling ........................................142
Appendix C. ICMPの処理
References .......................................................149
参照
Normative References ..........................................149
Normative References
Informative References ........................................150
Informative References

1. Introduction

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.
このセクションではStream Control Transmission Protocol (SCTP)が提供するサービス、
プロトコルの詳細を理解するために必要な基本的なコンセプトの背景を説明する。

This document obsoletes [RFC2960] and [RFC3309].
このドキュメントはRFC2960、RFC3309を廃止する。

1.1. Motivation
1.1. モチベーション

TCP [RFC0793] has performed immense service as the primary means of
reliable data transfer in IP networks.
However, an increasing number
of recent applications have found TCP too limiting, and have
incorporated their own reliable data transfer protocol on top of UDP
[RFC0768]. The limitations that users have wished to bypass include
the following:
TCP [RFC0793]はIPネットワーク内の高信頼性のデータ転送の方法としてサービスを提供している。
しかし、最近のアプリケーションではTCPの多くの制限から、UDP[RFC0768]上に独自の信頼性のあるデータ転送プロトコルが組み込まれている。
ユーザが回避を望む制限には下記のものがある。

-- TCP provides both reliable data transfer and strict order-of-
transmission delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these
cases, the head-of-line blocking offered by TCP causes unnecessary
delay.
-- TCPは信頼性のデータ転送と厳密なデータの順序伝送を提供する。
データお順序性が必要なアプリケーションもあるが、一部のアプリケーションでは順序制御のない信頼性のデータ転送を必要とする。
これらの両方のケースでは、TCPが提供するhead-of-line blocking(head-of-the-lineブロッキング（キュー送信によるブロッキング)が原因となる。

-- 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の限られた範囲では、multi-homed hostsを使用した高信頼データ転送の提供が複雑になる。

-- TCP is relatively vulnerable to denial-of-service attacks, such as
SYN attacks.
--TCPはSYN攻撃のようなDoS攻撃に比較的脆弱である。

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の開発の動機であり、いくつかのアプリケーションの要件にもマッチする。

Stewart Standards Track [Page 5]

RFC 4960 Stream Control Transmission Protocol September 2007

1.2. Architectural View of SCTP
1.2. SCTPのアーキテクチャ観点

SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and a connectionless packet network service such as
IP. The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of user
messages between peer SCTP users.
It performs this service within the context of an association between two SCTP endpoints.
Section 10 of this document sketches the API that should exist at the boundary
between the SCTP and the SCTP user layers.
SCTPはSCTPユーザアプリケーション(略：SCTP user)とIPのようなコネクションレスのパケットサービスとみなされる。
SCTPはIP上で動作することを前提とする。
SCTPが提供する基本機能はSCTPユーザ間のユーザメッセージの信頼性転送である。
SCTPは2つのSCTPエンドポイント間のassociationのコンテキスト内でこのサービスを実行する。
Section 10ではSCTPとSCTPユーザレイヤ間の境界に存在するAPIを説明する。

SCTP is connection-oriented in nature, but the SCTP association is a
broader concept than the TCP connection.
SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint
(during association startup) with a list of transport addresses
(i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will
originate SCTP packets. The association spans transfers over all of
the possible source/destination combinations that may be generated
from each endpoint's lists.
SCTPはコネクション指向の性質があるが、SCTP associationはTCPコネクションより広範なコンセプトである。
SCTPは各SCTPエンドポイントにSCTPパケット転送するための転送アドレスのリスト(すなわちSCTPポートと組み合わせられた複数のIPアドレス)を他のエンドポイントに提供するための方法を提供する。
Associationは各エンドポイントのリストから生成されるsource/destinationのすべての組み合わせの転送に作成される。

_____________ _____________
| 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.3. Key Terms
1.3. 用語

Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the
key terms and their definitions.
SCTPを説明するために使用される用語は前の章で導入された。
この章では用語と定義を提供する。

o Active destination transport address: A transport address on a
peer endpoint that a transmitting endpoint considers available for
receiving user messages.
o Active destination transport address：
送信側エンドポイントがユーザデータを受信可能と判断しているエンドポイント間のトランスポートアドレス。

Stewart Standards Track [Page 6]

RFC 4960 Stream Control Transmission Protocol September 2007

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 Bundling（バンドリング）
複数のユーザメッセージを同じSCTPパケットで転送することによる多重化処理。
各ユーザメッセージは各データチャンクで送信される。

o Chunk: A unit of information within an SCTP packet, consisting of
a chunk header and chunk-specific content.
o Chunk（チャンク）:
チャンクヘッダとチャンクコンテンツで構成される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 Congestion window (cwnd)（輻輳ウィンドウ）:
データを制限するSCTPのパラメータ（byte数）で、送信側がacknowledgementを受信する前に宛先アドレスに送信できる。

o Cumulative TSN Ack Point: The TSN of the last DATA chunk
acknowledged via the Cumulative TSN Ack field of a SACK.
o Cumulative TSN Ack Point（累積TSN Ack Point）:
最後のデータチャンクのTSNはSACKの累積TSN Ackフィールドで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 Idle destination address:
ユーザメッセージをHEARTBEATかそれ以上の時間に受信できなかったアドレス。

o Inactive destination transport address: An address that is
considered inactive due to errors and unavailable to transport
user messages.
o Inactive destination transport address:
エラーによりinactiveと判断され、ユーザメッセージの転送に使用できないアドレス。

o Message = user message: Data submitted to SCTP by the Upper Layer
Protocol (ULP).
o Message = user message:
上位レイヤ(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 Message Authentication Code (MAC):
秘密鍵を用いたハッシュ関数に基づく、Integrityチェックのメカニズム。
通常、MACは秘密鍵を共有する2者間で送信された情報の検証のために使用される。
SCTPでは、COOKIE ECHOチャンクでピアから返信されたState Cookie情報を検証するためにエンドポイントで使用される。

o Network Byte Order: Most significant byte first, a.k.a., big
endian.
o Network Byte Order（ネットワークバイトオーダー）:
最上位byteが最初。別名ビッグエンディアン。

o Ordered Message: A user message that is delivered in order with
respect to all previous user messages sent within the stream on
which the message was sent.
o Ordered Message（順序制御されたメッセージ）:
メッセージが送信されたストリーム内で順序通りに転送されたユーザメッセージ。

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 Outstanding TSN (at an SCTP endpoint)（SCTPエンドポイントの未処理のTSN）:
エンドポイントにより送信されたが、acknowledgementを受信していないTSNおよび関連するデータチャンク。

Stewart Standards Track [Page 7]

RFC 4960 Stream Control Transmission Protocol September 2007

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 Path:
SCTPエンドポイント間の特定の宛先トランスポートアドレスへのSCTPエンドポイントが送信したSCTPパケットが通るルート。
異なる宛先トランスポートアドレスに送信することは、必ずしもパスを分けることを必要としない。

o Primary Path: The primary path is the destination and source
address that will be put into a packet outbound to the peer
endpoint by default. The definition includes the source address
since an implementation MAY wish to specify both destination and
source address to better control the return path taken by reply
chunks and on which interface the packet is transmitted when the
data sender is multi-homed.
o Primary Path:
Primary pathはエンドポイント間の送信にデフォルトで使用される宛先と送信元のアドレス。
定義は送信元アドレスと宛先アドレスを含んでいる、それは、実装ではマルチホーム送信のときにパケットを送信する送信元・宛先の両方のアドレスを指定するため。。

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 Receiver Window (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 association:
SCTPエンドポイント間のプロトコルの関係。
2つのSCTPエンドポイントとVerification Tag、TSNなどのプロトコル状態情報から構成される。
Associationはassociationのエンドポイントのトランスポートアドレスを使って一意に識別できる。
2つのSCTPエンドポイントある時点でその間に複数のSCTP associationを持ってはいけない。

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 endpoint:
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 packet (or packet):
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 user application (SCTP user)
SCTPを使用する論理的に上位のアプリケーション。Upper-Layer Protocol(ULP)とも呼ばれる。

Stewart Standards Track [Page 8]

RFC 4960 Stream Control Transmission Protocol September 2007

o Slow-Start Threshold (ssthresh): An SCTP variable. This is the
threshold that the endpoint will use to determine whether to
perform slow start or congestion avoidance on a particular
destination transport address. Ssthresh is in number of bytes.
o Slow-Start Threshold (ssthresh):
SCTP変数。エンドポイントが特定の宛先トランスポートアドレスにスロースタートや輻輳回避を実行するかを決定するための閾値。ssthreshはバイト数。

o Stream: A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the
unordered delivery service.
o Stream:
2つのSCTPエンドポイント間で確立される一方向の論理チャネルで、すべてのユーザメッセージが順序送信（非順序送信のServiceは除く）により送信される。

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.
対向のストリームとの関連はアプリケーションが管理する。

o Stream Sequence Number: A 16-bit sequence number used internally
by SCTP to ensure sequenced delivery of the user messages within a
given stream. One Stream Sequence Number is attached to each user
message.
o Stream Sequence Number:
ストリーム内のユーザメッセージの順序送信を保証するため、SCTPが使用する16ビットのシーケンス番号。
Stream Sequence Numberは各ユーザメッセージに付与される。

o Tie-Tags: Two 32-bit random numbers that together make a 64-bit
nonce. These tags are used within a State Cookie and TCB so that
a newly restarting association can be linked to the original
association within the endpoint that did not restart and yet not
reveal the true Verification Tags of an existing association.
o Tie-Tags:
64bitのnonceを作る32bitの乱数。
タグは、associationにリンクできるようにState CookieとTCBで使用される。

o Transmission Control Block (TCB): An internal data structure
created by an SCTP endpoint for each of its existing SCTP
associations to other SCTP endpoints. TCB contains all the status
and operational information for the endpoint to maintain and
manage the corresponding association.
o Transmission Control Block (TCB):
他のSCTPエンドポイントへ各SCTP associationのためにSCTPエンドポイントによって作成された内部データ構造。
TCBはassociationを維持、管理するための状態情報と運用状態のすべてを含んでいる。

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 Transmission Sequence Number (TSN):
SCTPが内部的に使用する32ビットのシーケンス番号。
TSNは受信の確認と重複受信検出を受信側SCTPエンドポイントが可能なようにユーザデータを含むチャンクに付与される。

o Transport address: A transport address is traditionally defined by
a network-layer address, a transport-layer protocol, and a
transport-layer port number. In the case of SCTP running over IP,
a transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the transport protocol).
o Transport address:
ネットワークレイヤアドレス（ネットワーク層）とポート番号（トランスポート層）。

o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the
associated DATA chunk) that has been received by the endpoint but
for which an acknowledgement has not yet been sent. Or in the
opposite case, for a packet that has been sent but no
acknowledgement has been received.
o Unacknowledged TSN (at an SCTP endpoint):
エンドポイントで受信されたが、acknowledgementがまだ送信されていないTSN。
送信側ではパケットは送信されたが、acknowledgementがまだ受信されていない。

Stewart Standards Track [Page 9]

RFC 4960 Stream Control Transmission Protocol September 2007

o Unordered Message: Unordered messages are "unordered" with respect
to any other message; this includes both other unordered messages
as well as other ordered messages. An unordered message might be
delivered prior to or later than ordered messages sent on the same
stream.
o Unordered Message（順序制御されていないメッセージ）:
非順序送信の他のメッセージ（非順序送信メッセージ or 順序送信メッセージ）に関して非順序送信である。
非順序送信メッセージは同じストリームで送信された順序送信メッセージの前後に送信される。

o User message: The unit of data delivery across the interface
between SCTP and its user.
o User message:
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 Verification Tag:
ランダムに生成される32bit非負整数。
Verification Tagは受信者のSCTPパケットが現在のassociationに属し、以前のassociationの古いパケットか確認するキーを提供する。

1.4. Abbreviations

MAC - Message Authentication Code [RFC2104]

RTO - Retransmission Timeout

RTT - Round-Trip Time

RTTVAR - Round-Trip Time Variation

SCTP - Stream Control Transmission Protocol

SRTT - Smoothed RTT

TCB - Transmission Control Block

TLV - Type-Length-Value coding format

TSN - Transmission Sequence Number

ULP - Upper-Layer Protocol

1.5. Functional View of SCTP
1.5 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に示されるとおり、本章で説明される。

Stewart Standards Track [Page 10]

RFC 4960 Stream Control Transmission Protocol September 2007

SCTP User Application
SCTPユーザアプリケーション

-----------------------------------------------------
__________________________________________
| || Sequenced Delivery |
| Association || within Streams |
| ||____________________|
| Startup |Stream内の順序送信
| |______________________________
| and || User Data Fragmentation |
| ||____________________________|
| Takedown |ユーザデータのフラグメント
| |______________________________
| || Acknowledgement |
| || and |
| || Congestion Avoidance |
| ||____________________________|
| |Acknowledgementと輻輳回避
| |_______________________________
| || Chunk Bundling |
| ||_____________________________|
| |
| |___________________________________
| || Packet Validation |
| ||_________________________________|
| |
| |_______________________________
| || Path Management |
|__________________||______________________________|

Figure 2: Functional View of the SCTP Transport Service
Figure 2: SCTP Transport Serviceの機能観点

1.5.1. Association Startup and Takedown
1.5.1. Association Startup and Takedown

An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 10).
アソシエーションはSCTPユーザからの要求で初期化される。
（ASSOCIATE SENDのプリミティブはSection 10参照。）

A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522], is employed during the initialization to provide
protection against synchronization attacks. The cookie mechanism
uses a four-way handshake, the last two legs of which are allowed to
carry user data for fast setup. The startup sequence is described in
Section 5 of this document.
RFC2522でKarn and Simpsonが述べたのと同じcookieメカニズムがsyn attackに対する保護を提供するため初期化中に使用される。
4-way handshakeのcookieメカニズムは、fast setupでユーザデータを送信する最後の2 legを使う。
startupシーケンスはSection 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

Stewart Standards Track [Page 11]

RFC 4960 Stream Control Transmission Protocol September 2007

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ユーザからの要求によるアクティブなassociationのgraceful 切断(shutdown)を提供する。
SHUTDOWNプリミティブはSection 10参照。SCTPはユーザからの要求やSCTPレイヤで検出されたエラーによるungraceful 切断(abort)も許可する。
Section 9ではgraceful切断、ungraceful切断を説明する。

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のようなhalf-open state（片方が切断されている間にもう片方がデータを送信する）をサポートしない。
エンドポイントの片方がshutdownすると、各peerのassociationは新しいデータの受け入れを停止し、graceful切断時にキューのデータのみを送信する。

1.5.2. Sequenced Delivery within Streams

The term "stream" is used in SCTP to refer to a sequence of user
messages that are to be delivered to the upper-layer protocol in
order with respect to other messages within the same stream. This is
in contrast to its usage in TCP, where it refers to a sequence of
bytes (in this document, a byte is assumed to be 8 bits).
streamは同じストリーム内の他のメッセージとの間で順番に上位レイヤに送信されるユーザメッセージのsequenceを表すためにSCTPで使われる。これはbyteのsequenceを表す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ユーザはassociation startup時にサポートされるassociation数を指定できる。
その数はremote end（Section 5.1.1）でネゴシエーションされる。
ユーザメッセージはstream number(SEND、RECEIVEプリミティブ。Section 10)に関連付けられる。
内部的には、SCTPはSCTPユーザから渡された各メッセージにStream Sequence Numberを付与する。
受信側ではSCTPはメッセージが指定されたstream内のsequenceのSCTPユーザに送信されることを保証する。
streamが次のsequence内のユーザメッセージ待ちのためブロック中、別のstreamの送信を進めてよい。

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はsequence deliveryのバイパスのためのメカニズムを提供する。
このメカニズムを使用して送信されたユーザメッセージは、受信したSCTPユーザにすぐに届けられる。

1.5.3. User Data Fragmentation

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のを保証するためユーザメッセージをfragmentする。
受信ではfragmentはSCTPユーザに渡される前に元のメッセージにreassembleされる。

1.5.4. Acknowledgement and Congestion Avoidance

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はTransmission Sequence Number(TSN)を各ユーザデータメッセージに付与する。
TSNはstream levelで割り当てられたStream Sequence Numberとは無関係である。
受信側はsequenceにgapがあってもすべてのTSNをacknowledgeする。
これにより、信頼性送信と順序送信の機能分割が保たれる。

Stewart Standards Track [Page 12]

RFC 4960 Stream Control Transmission Protocol September 2007

The acknowledgement and congestion avoidance function is responsible
for packet retransmission when timely acknowledgement has not been
received. Packet retransmission is conditioned by congestion
avoidance procedures similar to those used for TCP. See Section 6
and Section 7 for a detailed description of the protocol procedures
associated with this function.
acknowledgementと輻輳回避はacknowledgementが受信できない時のパケット再送を担う。
パケット再送はTCPで使用されるものと同様の輻輳回避プロシージャで調整される。
この機能に関連するプロシージャの詳細はSection6、7を参照。

1.5.5. Chunk Bundling

As described in Section 3, the SCTP packet as delivered to the lower
layer consists of a common header followed by one or more chunks.
Each chunk may contain either user data or SCTP control information.
The SCTP user has the option to request bundling of more than one
user message into a single SCTP packet. The chunk bundling function
of SCTP is responsible for assembly of the complete SCTP packet and
its disassembly at the receiving end.
Section 3で説明したように、SCTP下位レイヤに送信されるSCTPパケットは1つ以上のチャンクと共通ヘッダで構成される。
各チャンクはSCTP control informationまたはユーザデータを含んでよい。
SCTPユーザは一つのSCTPパケットに複数のユーザデータのbundlingを要求するオプションをもつ。
チャンクbundling機能は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 bundleされないことを要求した場合でもbundlingを実行してもよい。
bundlingのユーザによる無効化は送信前のわずかな遅延に関するSCTPの実装に影響を与える（bundlingを試みるため）。
ユーザ層がbudlingを無効化したらわずかな遅延を抑えられるが、輻輳時や再送時にbundlingが実行されない。

1.5.6. Packet Validation

A mandatory Verification Tag field and a 32-bit checksum field (see
Appendix B for a description of the CRC32c checksum) are included in
the SCTP common header. The Verification Tag value is chosen by each
end of the association during association startup. Packets received
without the expected Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale SCTP
packets from a previous association. The CRC32c checksum should be
set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid CRC32c checksum silently discards the
packet.
必須のVerificaton Tagフィールドと32bitチェックサムフィールド(CRC32チェックサムの詳細はAppenix B参照)はSCTP common headerに含まれる。
Verification Tagの値はassociation startup時に各association間で選択される。
正しいVerification Tagなしで受信したパケットはblind masquerade attackと古いassociationパケットとして削除される。
CRC32チェックサムはネットワークによるデータ破損に対する保護を提供するため各SCTPパケットの送信者によって送信されること。
不正なCRCチェックサムのSCTPパケットの受信者はパケットを破棄する。

1.5.7. Path Management

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

Stewart Standards Track [Page 13]

RFC 4960 Stream Control Transmission Protocol September 2007

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送信者はSection10で説明されるプリミティブによりSCTPパケットの宛先として使用されるtransport addressのsetを操作できる。
SCTP path managementはSCTPユーザの指定や宛先の到達性の状態に基づき、各送信SCTPパケットの宛先transport addressを選択する。
path managementはパケットトラヒックの情報が不足している場合、heartbeatで到達性を監視し、SCTPユーザに他のtransport addressの到達性の変化を通知する。
path managementはassociation startup時に相手へのlocal transport addressを通知と、相手のSCTPユーザから返されたtransport addressを報告を担い。

At association startup, a primary path is defined for each SCTP
endpoint, and is used for normal sending of SCTP packets.
association startup時、primary pathは各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.
受信側ではpath managementは受信したSCTPパケットをその後の処理に渡す前に正しいSCTP associationであるかの確認を担う。

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.
Path ManagementとPacket Validationは同時には実行されるため、実際は上記に分けた説明が別々に実行されることはない。

1.6. Serial Number Arithmetic

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).
Transmission Sequence Number空間は非常に大きいが有限（0～2^32-1）である。
有限であるため、Transmission Sequence Numberを扱う演算はmod 2^32をする必要がある。
この演算は0～2^32-1のサイクルとしてシーケンス番号を保持する。
moduloの計算には微妙な点があるため、値の比較には注意が必要である。
TSNを参照する際は"=<"は以下(mod 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のSerial Number Arithmeticを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.
endpointは送信ウィンドウでTSN 2^31-1を超えるデータチャンクを送信しないこと。
そうすると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.
TSNは2^32-1に達すると重複する。
つまり次のTSN=0はTSN=2^32-1を送信した後に使用すること。

Any arithmetic done on Stream Sequence Numbers SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16.
All other arithmetic and comparisons in this document use normal
arithmetic.
RFC1982で定義されるSERIAL_BITS = 16のSerial Number ArithmeticをStream Sequence Numberを計算に使用すること。
このドキュメントのその他の計算、比較は通常の算術演算を使用する。

Stewart Standards Track [Page 14]

RFC 4960 Stream Control Transmission Protocol September 2007

1.7. Changes from RFC 2960

SCTP was originally defined in [RFC2960], which this document
obsoletes. Readers interested in the details of the various changes
that this document incorporates are asked to consult [RFC4460].
SCTPはこのドキュメントが廃止したRFC2960で定義された。
このドキュメントに組み込まれた変更の詳細はRFC4460を参照。

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"はRFC2119で説明されるように解釈されること。

3. SCTP Packet Format

An SCTP packet is composed of a common header and chunks. A chunk
contains either control information or user data.
SCTPパケットはcommon headerとチャンクで構成される。チャンクはcontrol informationまたはユーザデータを含む。

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パケットにチャンクをbundleできる。
これらのチャンクはパケット内の他のチャンクをbundleしないこと。
chunk bundlingの詳細はSection 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パケットに収まらない場合、Section 6.9のプロシージャを用いて複数のチャンクにfragmentできる。

All integer fields in an SCTP packet MUST be transmitted in network
byte order, unless otherwise stated.
SCTPパケット内のすべての整数フィールドはネットワークバイトオーダーで送信されること。

Stewart Standards Track [Page 15]

RFC 4960 Stream Control Transmission Protocol September 2007

3.1. SCTP Common Header Field Descriptions

SCTP Common Header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port Number: 16 bits (unsigned integer)

This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port, and possibly the destination IP address to
identify the association to which this packet belongs. The port
number 0 MUST NOT be used.
SCTP送信者のポート番号。
パケットのassociatinを識別するため送信元、宛先のIPアドレス、SCTP宛先ポートとともに受信者に使用される。
ポート番号0は使わないこと。

Destination Port Number: 16 bits (unsigned integer)

This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex the
SCTP packet to the correct receiving endpoint/application. The
port number 0 MUST NOT be used.
パケットの宛先ポート番号。
受信側が受信エンドポイント/アプリケーションにSCTPパケットをde-multiplexするために使用する。
ポート番号0は使わないこと。

Verification Tag: 32 bits (unsigned integer)

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パケットの検証のためにVerification Tagを使用する。
送信時、Verification Tagはassociation initialization中にピアエンドポイントから受信したInitiate Tagの値を設定すること。
下記の例外は除く。

- A packet containing an INIT chunk MUST have a zero Verification
Tag.
INITチャンクを含むパケットは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.
T bitのSHUTDOWN COMPLETEチャンクを含むパケットは、SHUTDOWN ACKチャンクパケットからコピーされたVerification Tagであること。

- A packet containing an ABORT chunk may have the verification
tag copied from the packet that caused the ABORT to be sent.
For details see Section 8.4 and Section 8.5.
ABORTチャンクを含むパケットは、ABORTが送信される原因となったパケットからコピーされたVerification Tagをコピーすること。
詳細はSection 8.4、8.5を参照。

Stewart Standards Track [Page 16]

RFC 4960 Stream Control Transmission Protocol September 2007

An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
INITチャンクはこれを送信するSCTPの唯一のチャンクであること。

Checksum: 32 bits (unsigned integer)

This field contains the checksum of this SCTP packet. Its
calculation is discussed in Section 6.8. SCTP uses the CRC32c
algorithm as described in Appendix B for calculating the checksum.
SCTPパケットのチェックサム。
計算方法はSection 6.8で述べる。
SCTPはCRC32アルゴリズム（Appendix B）を用いる。

3.2. Chunk Field Descriptions

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パケットで送信されるチャンクフィールドフォーマットを示す。
各チャンクはChunk Type、Chunk-specific Flag、Chunk Length、Chunk Valueから構成される。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Type: 8 bits (unsigned integer)

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.
Chunk Value filedの情報の種類を識別する。
0～254をとる。255は今後の拡張のための予約。

The values of Chunk Types are defined as follows:
Chunk Typesは下記のように定義される。

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)

Stewart Standards Track [Page 17]

RFC 4960 Stream Control Transmission Protocol September 2007

12 - Reserved for Explicit Congestion Notification Echo
(ECNE)
13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE)
15 to 62 - available
63 - reserved for IETF-defined Chunk Extensions
64 to 126 - available
127 - reserved for IETF-defined Chunk Extensions
128 to 190 - available
191 - reserved for IETF-defined Chunk Extensions
192 to 254 - available
255 - reserved for IETF-defined Chunk Extensions

Chunk Types are encoded such that the highest-order 2 bits specify
the action that must be taken if the processing endpoint does not
recognize the Chunk Type.
Chunk Typeは上位2bitがエンドポイントがChunk Typeを認識しない場合のアクションを指定するためにエンコードされる。

00 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it.
SCTPパケット処理を停止し、破棄する。Chunkを処理しない。

01 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it, and report the
unrecognized chunk in an 'Unrecognized Chunk Type'.
SCTPパケット処理を停止し、破棄する。Chunkを処理せず、Unrecognized Chunk TypeとしてChunkを報告する。

10 - Skip this chunk and continue processing.
Chunkをスキップし、処理を継続する。

11 - Skip this chunk and continue processing, but report in an
ERROR chunk using the 'Unrecognized Chunk Type' cause of
error.
Chunkをスキップし、処理を継続する。Unrecognized Chunk Typeを使用したERROR Chunkで報告する。

Note: The ECNE and CWR chunk types are reserved for future use of
Explicit Congestion Notification (ECN); see Appendix A.
ECNEとCWR chunkタイプはECN(明示的輻輳通知)で使用するためreserveされている。Appendix A参照。

Chunk Flags: 8 bits

The usage of these bits depends on the Chunk type as given by the
Chunk Type field. Unless otherwise specified, they are set to 0
on transmit and are ignored on receipt.
Chunk Type fieldで指定されたChunk typeに応じて使用される。
特に規定がない場合、送信側で0が設定され、受信側で無視される。

Chunk Length: 16 bits (unsigned integer)

This value represents the size of the chunk in bytes, including
the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
chunk padding.
Chunk Value、Chunk Length、Chunk Flags、Chunk Typesのバイト単位のchunkサイズを表す。
Chunk Value fieldが0の場合、Lengthは4に設定される。
Chunk Lengthはchunk paddingをカウントしない。

Stewart Standards Track [Page 18]

RFC 4960 Stream Control Transmission Protocol September 2007

Chunks (including Type, Length, and Value fields) are padded out
by the sender with all zero bytes to be a multiple of 4 bytes
long. This padding MUST NOT be more than 3 bytes in total. The
Chunk Length value does not include terminating padding of the
chunk. However, it does include padding of any variable-length
parameter except the last parameter in the chunk. The receiver
MUST ignore the padding.
Chunkは4バイトの倍数であるために、0バイトで送信者によってpaddingされる。
paddingは3バイトを超えてはいけない。
Chunk Lengthはchunkの終端のpaddingを含んでいない。
受信者はpaddingを無視すること。

Note: A robust implementation should accept the chunk whether or
not the final padding has been included in the Chunk Length.
robustな実装ではpaddingがChunk Lengthに含まれているか確認する必要がある。

Chunk Value: variable length

The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
Chunk Value fieldはChunkで送信される情報が含まれている。
使用方法とフォーマットはChunk Typeに依存する。

The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, and this padding is not included in the Chunk Length
field. The sender MUST NOT pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
chunkの合計のサイズは4バイトの倍数であること。
4バイトの倍数でない場合、送信者は0バイトでpaddingし、paddingはChunk Lengthに含めないこと。
送信者は3バイトより多くをpaddingしてはいけない。
受信者はpaddingバイトを無視すること。

SCTP-defined chunks are described in detail in Section 3.3. The
guidelines for IETF-defined chunk extensions can be found in Section
14.1 of this document.
SCTP定義のchunkはSection 3.3で詳しく述べる。
IETF定義のchunk拡張はSection 14.1で述べる。

3.2.1. Optional/Variable-Length Parameter Format

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 control chunkのChunk valueは0以上のパラメータの必須フィールドのchunk-type-specificヘッダで構成される。

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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stewart Standards Track [Page 19]

RFC 4960 Stream Control Transmission Protocol September 2007

Chunk Parameter Type: 16 bits (unsigned integer)

The Type field is a 16-bit identifier of the type of parameter.
It takes a value of 0 to 65534.
パラメータのタイプの16bit識別子。0～65534。

The value of 65535 is reserved for IETF-defined extensions.
Values other than those defined in specific SCTP chunk
descriptions are reserved for use by IETF.
65535はIETF定義の拡張のためのreserve。
特定のSCTP chunkで定義された値以外はIETFで使用するためreserveされている。

Chunk Parameter Length: 16 bits (unsigned integer)

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.
Parameter Type、Parameter Length、Parameter Valueのバイト数。
Parameter Valueが0ならばLengthは4。
Parameter Lengthはpadding byteを含まない。

Chunk Parameter Value: variable length

The Parameter Value field contains the actual information to be
transferred in the parameter.
Parameter Valueはパラメータで転送される情報を含む。

The total length of a parameter (including Type, Parameter Length,
and Value fields) MUST be a multiple of 4 bytes. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the
parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is not included in the
Parameter Length field. A sender MUST NOT pad with more than 3
bytes. The receiver MUST ignore the padding bytes.
パラメータ長の合計は4バイトの倍数であること。
4バイトの倍数でない場合、送信者は最後(Parameter Valueの後)に0でpaddingする。
padding長はParameter Lengthに含めない。
送信者は3バイトより多くのpaddingをしてはいけない。
受信者はpaddingを無視すること。

The Parameter Types are encoded such that the highest-order 2 bits
specify the action that must be taken if the processing endpoint
does not recognize the Parameter Type.
Parameter Typeが認識できない場合にParameter Typeの上位2ビットでやるべきアクションが定義されている。

00 - Stop processing this parameter; do not process any further
parameters within this chunk.
パラメータの処理を停止し、パラメータを処理しない。

01 - Stop processing this parameter, do not process any further
parameters within this chunk, and report the unrecognized
parameter in an 'Unrecognized Parameter', as described in
Section 3.2.2.
パラメータパケット処理を停止し、パラメータを処理しない。Unrecognized Parameterとしてパラメータを報告する。Section 3.2.2参照。

10 - Skip this parameter and continue processing.
パラメータをスキップし、処理を継続する。

11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter', as
described in Section 3.2.2.
パラメータをスキップし、処理を継続する。Unrecognized parameterで報告する。Section 3.2.2参照。

Stewart Standards Track [Page 20]

RFC 4960 Stream Control Transmission Protocol September 2007

Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk
is sent. In the 00 or 01 case, the processing of the parameters
after the unknown parameter is canceled, but no processing already
done is rolled back.
4つのケースでINIT ACK、COOKIE ECHOが送信されるのに注意してください。
00 or 01のケースでは、キャンセルされ、未実施の処理はロールバックされない。

The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 14.2. Note that a parameter type MUST be unique
across all chunks. For example, the parameter type '5' is used to
represent an IPv4 address (see Section 3.3.2.1). The value '5' then
is reserved across all chunks to represent an IPv4 address and MUST
NOT be reused with a different meaning in any other chunk.
SCTPのパラメータはSCTP chunk sectionで定義される。
IETF定義のパラメータ拡張はSection 14.2で定義される。
すべてのchunkでParameter Typeは一意であること。
例えば、Parameter Type 5はIPv4アドレスを表すために使用される。(Section 3.3.1.1参照)
5はIPv4 アドレスを表すためにreserveされており、他のchunkで異なる意味の仕様をしてはいけない。

3.2.2. Reporting of Unrecognized Parameters

If the receiver of an INIT chunk detects unrecognized parameters and
has to report them according to Section 3.2.1, it MUST put the
'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in
response to the INIT chunk. Note that if the receiver of the INIT
chunk is NOT going to establish an association (e.g., due to lack of
resources), an 'Unrecognized Parameter' would NOT be included with
any ABORT being sent to the sender of the INIT.
INIT chunkの受信者がunrecognized parameterを検出し、Section 3.2.1に従って報告する場合、INIT chunkの応答としてINIT ACK chunkに"Unrecognized Parameter" parametersを付与すること。
INIT chunkの受信者がassociationの確立していない場合(リソース不足などにより)、送信者へのABORTには"Unrecognized Parameter"が含まれていないことに注意せよ。

If the receiver of an INIT ACK chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it SHOULD bundle
the ERROR chunk containing the 'Unrecognized Parameters' error cause
with the COOKIE ECHO chunk sent in response to the INIT ACK chunk.
If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately but not
before the COOKIE ACK has been received.
INIT ACK chunkの受信者が認識できないパラメータを検出し、Section 3.2.1に従って報告する場合、INIT ACK chunの応答のCOOKIE ECHO chunkで"Unrecognized Parameters"を含むERROR chunkをbundleすること。
INIT ACKの受信者がERROR chunkをCOOKIE ECHO chunkにbundleできない場合、ERROR chunkはCOOKIE ACKの受信前に分けて送られてもよい。

Note: Any time a COOKIE ECHO is sent in a packet, it MUST be the
first chunk.
COOKIE ECHOをパケットで送信するときはそれは最初のchunkであること。

3.3. SCTP Chunk Definitions

This section defines the format of the different SCTP chunk types.
SCTP chunk typeのフォーマットを定義する。

Stewart Standards Track [Page 21]

RFC 4960 Stream Control Transmission Protocol September 2007

3.3.1. Payload Data (DATA) (0)

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

Should be set to all '0's and ignored by the receiver.
0を設定し、受信者は無視すること

U bit: 1 bit

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.
順不同のbit。1が設定された場合、DATA chunkは順不同であることを示し、SSNはDATA chunkはない。
そのため、受信者はSSN fieldを無視すること。

After reassembly (if necessary), unordered DATA chunks MUST be
dispatched to the upper layer by the receiver without any attempt
to reorder.
必要ならばreassemblyの後、順不同のDATA chunkは順序制御なしに受信者によって上位レイヤに転送されること。

If an unordered user message is fragmented, each fragment of the
message MUST have its U bit set to '1'.
順不同のユーザデータがフラグメントされた場合、各フラグメントはU bitに1がセットされる。

B bit: 1 bit

The (B)eginning fragment bit, if set, indicates the first fragment
of a user message.
fragmentの開始bit。セットされた場合、ユーザメッセージの最初のフラグメントを示す。

E bit: 1 bit

The (E)nding fragment bit, if set, indicates the last fragment of
a user message.
fragmentの最終bit。セットされた場合、ユーザメッセージの最後のフラグメントを示す。

Stewart Standards Track [Page 22]

RFC 4960 Stream Control Transmission Protocol September 2007

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:
fragmentされていないユーザメッセージはB、E bitに1を設定すること。
BとEに0が設定されることは、フラグメントの中間であることを示す。
要約を下記のテーブルに示す。

B E Description
============================================================
| 1 0 | First piece of a fragmented user message |
+----------------------------------------------------------+
| 0 0 | Middle piece of a fragmented user message |
+----------------------------------------------------------+
| 0 1 | Last piece of a fragmented user message |
+----------------------------------------------------------+
| 1 1 | Unfragmented message |
============================================================
| Table 1: Fragment Description Flags |
============================================================

When a user message is fragmented into multiple chunks, the TSNs are
used by the receiver to reassemble the message. This means that the
TSNs for each fragment of a fragmented user message MUST be strictly
sequential.
ユーザメッセージが複数のチャンクにfragmentされる場合、TSNがメッセージをreassembleするために受信者に使用される。
これはfragmentされたユーザメッセージの各fragmentのTSNは正確に連続していることを意味している。

Length: 16 bits (unsigned integer)

This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the User Data field
excluding any padding. A DATA chunk with one byte of user data
will have Length set to 17 (indicating 17 bytes).
このfieldにはpaddingを除いたType filedの開始からUser Data fieldの最後までのバイト数で、DATA chunkの長さを表す。
1バイトのユーザデータをもつDATA chunkはLengthに17が設定される。(17byteを表す)

A DATA chunk with a User Data field of length L will have the
Length field set to (16 + L) (indicating 16+L bytes) where L MUST
be greater than 0.
Lが0より大きいとき、長さLのUser Data fieldをもつDATA chunkはLength filedに16 + Lが設定される。(16 + Lbyteを示す。)

TSN: 32 bits (unsigned integer)

This value represents the TSN for this DATA chunk. The valid
range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back
to 0 after reaching 4294967295.
DATA chunkのTSNを表す。
TSNの範囲は0～4294967295である。
TSNは4294967295に達すると0に戻る。

Stream Identifier S: 16 bits (unsigned integer)

Identifies the stream to which the following user data belongs.
user dataが属するstreamを識別する。

Stream Sequence Number n: 16 bits (unsigned integer)

This value represents the Stream Sequence Number of the following
user data within the stream S. Valid range is 0 to 65535.
Stream Sのuser dataのSSNを表す。範囲は0～65535。

Stewart Standards Track [Page 23]

RFC 4960 Stream Control Transmission Protocol September 2007

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にfragmentされた場合、同じSSNがメッセージの各fragmentに設定されること。

Payload Protocol Identifier: 32 bits (unsigned integer)

This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by SCTP
but can be used by certain network entities, as well as by the
peer application, to identify the type of information being
carried in this DATA chunk. This field must be sent even in
fragmented DATA chunks (to make sure it is available for agents in
the middle of the network). Note that this field is NOT touched
by an SCTP implementation; therefore, its byte order is NOT
necessarily big endian. The upper layer is responsible for any
byte order conversions to this field.
この値はapplicationか上位レイヤにより指定されたprotocol identifierを表す。
この値は上位レイヤから渡され、peerに送られる。
この識別子はSCTPでは使われないが、DATA chunkで送信される情報のタイプを識別するためnetwork entity、peer applicationで使われる。
このfiledはfragmentのDATA chunkにでも送信されること。
このfieldはSCTPに関与されないことに注意せよ。バイトオーダーはビッグエンディアンである必要はない。
上位レイヤはこのfieldのバイトオーダー変換を担う。

The value 0 indicates that no application identifier is specified
by the upper layer for this payload data.
0はこのpayload dataに上位レイヤによってapplication identifierが指定されていないことを示す。

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.
payload user data。4-byte boundaryのためall 0でpaddingすること。
paddingはLength fieldに含めないこと。
送信者は3byteを超えるpaddingを加えないこと。

3.3.2. Initiation (INIT) (1)

This chunk is used to initiate an SCTP association between two
endpoints. The format of the INIT chunk is shown below:
このchunkは2つのエンドポイント間のSCTP associationの初期化に使用する。
INIT chunkのformatを下記に示す。

Stewart Standards Track [Page 24]

RFC 4960 Stream Control Transmission Protocol September 2007

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 chunkには下記のパラメータが含まれている。
各パラメータは一つだけINIT chunkに含まれること。

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.
Note 1: INIT chunkはIPv4 and/or IPv6の任意の組み合わせで複数のアドレスを含むことができる。

Note 2: The ECN Capable field is reserved for future use of Explicit
Congestion Notification.
ECN Capable filedはExplicit Congestion Notificationの今後の仕様のためのreserve領域。

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.
INIT chunkは複数のHost Name Addressパラメータを含んではいけない。
INITの送信者はINITのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。
Host Name Addressパラメータが受信したINIT chunkに存在する場合、INITの受信者は他のアドレスタイプを無視すること。

Stewart Standards Track [Page 25]

RFC 4960 Stream Control Transmission Protocol September 2007

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.
このパラメータが存在する場合、送信エンドポイントがサポートできるすべてのアドレスタイプを指定する。
このパラメータが存在しない場合、送信エンドポイントが任意のアドレスタイプをサポートできることを示す。

IMPLEMENTATION NOTE: If an INIT chunk is received with known
parameters that are not optional parameters of the INIT chunk, then
the receiver SHOULD process the INIT chunk and send back an INIT ACK.
The receiver of the INIT chunk MAY bundle an ERROR chunk with the
COOKIE ACK chunk later. However, restrictive implementations MAY
send back an ABORT chunk in response to the INIT chunk.
INIT chunkがINIT chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT chunkを処理し、INIT ACKを送信すること。
INIT chunkの受信者はCOOKIE ACK chunでERROR chunkをbundleしてもよい。
実装の制限では、INIT chunkに対してABORT chunkを返す。

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のChunk Flag fieldはreserveであり、送信者によって0が設定され、受信者は無視する。
INITのパラメータは順序は任意の順序で処理できる。

Initiate Tag: 32 bits (unsigned integer)

The receiver of the INIT (the responding end) records the value of
the Initiate Tag parameter. This value MUST be placed into the
Verification Tag field of every SCTP packet that the receiver of
the INIT transmits within this association.
INITの受信者はInitiate Tag パラメータの値を記録する。
この値はINITの受信者がassociation中に送信するすべてのSCTPパケットのVerification Tag fieldに設定すること。

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.
Initiate Tagは0以外の値をもつこと。
tag valueの選択についてはSection 5.2.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 chunkのInitiate Tagの値に0を見つけた場合、受信者はエラーとして扱い、ABORTを送信してassociationを終了する。

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer)

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の送信者がassociationのwindow用に確保しているバッファ領域のバイト数。
Assosiationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。ただし、エンドポイントはSACK chunkで送るa_rwndの値を変更してもよい。

Number of Outbound Streams (OS): 16 bits (unsigned integer)

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 chunkの送信者がassociationで作成するoutbound stream数を定義する。
0は使用してはいけない。

Note: A receiver of an INIT with the OS value set to 0 SHOULD
abort the association.
OSが0に設定されたINITの受信者はassociationをabortすること。

Stewart Standards Track [Page 26]

RFC 4960 Stream Control Transmission Protocol September 2007

Number of Inbound Streams (MIS): 16 bits (unsigned integer)

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 chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。
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.
Stream数のネゴシエーションはしないが、代わりに2エンドポイントはmin(requested, offered)を使用する。詳細はSection 5.1.1参照。

Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
the association.
MISが0のINITの受信者はassociationをabortすること。

Initial TSN (I-TSN): 32 bits (unsigned integer)

Defines the initial TSN that the sender will use. The valid range
is from 0 to 4294967295. This field MAY be set to the value of
the Initiate Tag field.
送信側が使用するTSNの初期値を定義する。
範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。

3.3.2.1. Optional/Variable-Length Parameters in INIT

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.
下記のパラメータはSection 3.2.1で定義されたType-Length-Valueフォーマットに従うこと。
Type-Length-Value fieldは前のSectionで定義された固定長フィールドの後にあること。

IPv4 Address Parameter (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)

Contains an IPv4 address of the sending endpoint. It is binary
encoded.
送信側のIPv4アドレスが含まれる。binary encodeである。

Stewart Standards Track [Page 27]

RFC 4960 Stream Control Transmission Protocol September 2007

IPv6 Address Parameter (6)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Address: 128 bits (unsigned integer)

Contains an IPv6 [RFC2460] address of the sending endpoint. It is
binary encoded.
送信側のIPv4アドレスが含まれる。binary encodeである。

Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291],
but should instead use an IPv4 Address parameter for an IPv4
address.
送信者はIPv4マップ IPv6アドレスを使用してはいけない。
IPv4でIPv4 address parameterを使用すること。

Combined with the Source Port Number in the SCTP common header,
the value passed in an IPv4 or IPv6 Address parameter indicates a
transport address the sender of the INIT will support for the
association being initiated. That is, during the life time of
this association, this IP address can appear in the source address
field of an IP datagram sent from the sender of the INIT, and can
be used as a destination address of an IP datagram sent from the
receiver of the INIT.
SCTP common headerのSource Port Numberと組み合わされ、Transport addressのIPv4 or IPv6 アドレスパラメータの値はassociationを示す。
すなわち、associationの生存時間中、このIPアドレスはINIT送信者の送信したIP datagramの送信アドレスとなり、INIT受信側から送信されたIP datagramの宛先アドレスとして使用される。

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送信側がmulti-homeの場合、複数のIPアドレスパラメータがINIT chunkに含まれる。
さらに、multi-home エンドポイントはネットワークの異なるタイプのアクセスがあってもよい。
従って、一つのINIT chunkに複数のアドレスタイプが存在してよい。すなわちIPv4、IPv6アドレスが同一のINIT chunkであることが許容される。

If the INIT contains at least one IP Address parameter, then the
source address of the IP datagram containing the INIT chunk and
any additional address(es) provided within the INIT can be used as
destinations by the endpoint receiving the INIT. If the INIT does
not contain any IP Address parameters, the endpoint receiving the
INIT MUST use the source address associated with the received IP
datagram as its sole destination address for the association.
INITが1つ以上のIPアドレスを含む場合、INIT内のaddress、INITを含むIP datagramのsource addressがINITを受信したエンドポイントに宛先として使用される。
INITがIP アドレスパラメータを含んでいない場合、INITを受信したエンドポイントはassociationに受信したIP datagramの送信元IPアドレスを宛先アドレスとして使用すること。

Note that not using any IP Address parameters in the INIT and INIT
ACK is an alternative to make an association more likely to work
across a NAT box.
INIT、INIT ACKのIPアドレスパラメータを使用していないが、associationがNAT boxを経由するためである。

Stewart Standards Track [Page 28]

RFC 4960 Stream Control Transmission Protocol September 2007

Cookie Preservative (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の送信側はState Cookieのlife-spanを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)

This parameter indicates to the receiver how much increment in
milliseconds the sender wishes the receiver to add to its default
cookie life-span.
default cookie life-spanに受信側が追加するms単位の増分を受信側に示す。

This optional parameter should be added to the INIT chunk by the
sender when it reattempts establishing an association with a peer
to which its previous attempt of establishing the association
failed due to a stale cookie operation error. The receiver MAY
choose to ignore the suggested cookie life-span increase for its
own security reasons.
このオプションパラメータは送信者がピアとのcookieが古くなったエラーによりassociationを確立するとき、INIT chunkに追加すること。
受信側はセキュリティのため、提示されたcookie life-span増加を無視してもよい。

Host Name Address (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の送信者はピアにHost Name(IP addressの代わり)を渡すために使われる。
ピアは名前解決をする必要がある。このパラメータの使用によりNAT boxを経由してassociationを作成できる。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Host Name: variable length

This field contains a host name in "host name syntax" per RFC 1123
Section 2.1 [RFC1123]. The method for resolving the host name is
out of scope of SCTP.
このフィールドはRFC 1123 Section 2.1の"host name syntax"のhost nameが含まれる。
ホスト名の解決方法はSCTPのスコープ外である。

Stewart Standards Track [Page 29]

RFC 4960 Stream Control Transmission Protocol September 2007

Note: At least one null terminator is included in the Host Name
string and must be included in the length.
1以上のnull終端がHost Name stringに含まれ、lengthに含まれること。

Supported Address Types (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)

This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
対応するアドレス TLVのタイプの値が設定される。

3.3.3. Initiation Acknowledgement (INIT ACK) (2)

The INIT ACK chunk is used to acknowledge the initiation of an SCTP
association.
INIT ACK chunkはSCTP associationの開始をacknowledgeするために使用される。

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 chunkと同様に定義される。
2つの可変パラメータを使用する。State Cookie、Unrecognized Parameter。

Stewart Standards Track [Page 30]

RFC 4960 Stream Control Transmission Protocol September 2007

The format of the INIT ACK chunk is shown below:

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)

The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits
within this association.
INIT ACKの受信者はInitiate Tagの値を記録する。
この値はassociationでINIT ACK受信者が送信するすべてのSCTPパケットのVerification Tagに設定されること。

The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value.
Initiate Tagは0を設定してはいけない。Initiate Tagの値についてはSection 5.3.1参照。

If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST destroy the association
discarding its TCB. The receiver MAY send an ABORT for debugging
purpose.
受信したINIT ACK chunkのInitiate Tagの値が0の場合、受信者はassociationを破棄すること。受信者はデバッグのためABORTを送ってもよい。

Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer)

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の送信者がassociationのwindow用に確保しているバッファ領域のバイト数。
Associationの存続中、このバッファスペースは減らされないこと(バッファはassosiationから取り除かれないこと)。

Stewart Standards Track [Page 31]

RFC 4960 Stream Control Transmission Protocol September 2007

Number of Outbound Streams (OS): 16 bits (unsigned integer)

Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used, and the value MUST NOT be greater than the MIS value
sent in the INIT chunk.
INIT ACK chunkの送信者がassociationで作成するoutbound stream数を定義する。
0は使用してはいけない。INIT chunkで送信されたMIS値より大きくしてはいけない。

Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.
OSに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。

Number of Inbound Streams (MIS): 16 bits (unsigned integer)

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 chunkの送信者がpeer側で作成されるassociationで許可する最大のstream数を定義する。
0を使用しないこと。

Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD
destroy the association discarding its TCB.
MISに0が設定されたINIT ACKの受信者はassociationを削除し、TCBを破棄すること。

Initial TSN (I-TSN): 32 bits (unsigned integer)

Defines the initial TSN that the INIT ACK sender will use. The
valid range is from 0 to 4294967295. This field MAY be set to the
value of the Initiate Tag field.
INIT ACKの送信側が使用するTSNの初期値を定義する。
範囲は0～4294967295。このフィールドはInitiate Tag fieldの値を設定してもよい。

Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11

Note 1: The INIT ACK chunks can contain any number of IP address
parameters that can be IPv4 and/or IPv6 in any combination.
INIT ACK chunkは任意の組み合わせでIPv4/IPv6アドレスを複数含むことができる。

Note 2: The ECN Capable field is reserved for future use of Explicit
Congestion Notification.
ECN fieldはExplicit Congestion Notification(明示的輻輳通知)のためにreserveされている。

Stewart Standards Track [Page 32]

RFC 4960 Stream Control Transmission Protocol September 2007

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.
INIT ACK chunkは複数のHost Name Addressパラメータを含んではいけない。INIT ACKの送信者はINIT ACKのHost Name Addressを他のアドレスタイプと組み合わせてはいけない。
Host Name Addressパラメータが受信したINIT ACK chunkに存在する場合、INIT ACKの受信者は他のアドレスタイプを無視すること。

IMPLEMENTATION NOTE: An implementation MUST be prepared to receive an
INIT ACK that is quite large (more than 1500 bytes) due to the
variable size of the State Cookie AND the variable address list. For
example if a responder to the INIT has 1000 IPv4 addresses it wishes
to send, it would need at least 8,000 bytes to encode this in the
INIT ACK.
実装では、State Cookieと可変長アドレスリストのため1500byte以上のINIT ACKを受信する準備をすること。
例えば、INITの送信者が送りたいIPv4アドレスを1000個持っている場合、INIT ACKでencodeすると8000byte以上は必要になる。

IMPLEMENTATION NOTE: If an INIT ACK chunk is received with known
parameters that are not optional parameters of the INIT ACK chunk,
then the receiver SHOULD process the INIT ACK chunk and send back a
COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR
chunk with the COOKIE ECHO chunk. However, restrictive
implementations MAY send back an ABORT chunk in response to the INIT
ACK chunk.
INIT ACK chunkがINIT ACK chunkのオプションでない既知のパラメータとともに受信された場合、受信側はINIT ACK chunkを処理し、COOKIE ECHOを送信すること。
INIT ACK chunkの受信者はCOOKIE ECHO chunkでERROR chunkをbundleしてもよい。
実装の制限では、INIT ACK chunkに対してABORT chunkを返してもよい。

In combination with the Source Port carried in the SCTP common
header, each IP Address parameter in the INIT ACK indicates to the
receiver of the INIT ACK a valid transport address supported by the
sender of the INIT ACK for the life time of the association being
initiated.
SCTP common header内のSource Portと組み合わせ、INIT ACK内の各IP AddressパラメータはINIT ACKの受信側にINIT ACKの送信者がサポートしてるassociationで有効なtransport addressを示す。

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が一つ以上IP Address paramterを含んでいる場合、INIT ACKに含まれるIPアドレスとIP datagramの送信元アドレスはINIT ACKの受信側に宛先として使用されてよい。
INIT ACKがIP address paramterを含まない場合、INIT ACKの受信側は受信したIP datagramの送信元IPアドレスをassociationの宛先アドレスとして使用すること。

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.
State CookieとUnrecognized Parmterは Section 3.2.1と下記に定義されたType-Length-Value formatを使用する。
他のfiledはINIT chunkの対応するfieldと同様に定義される。

3.3.3.1. Optional or Variable-Length Parameters

State Cookie

Parameter Type Value: 7

Parameter Length: Variable size, depending on size of Cookie.

Stewart Standards Track [Page 33]

RFC 4960 Stream Control Transmission Protocol September 2007

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.
このparamterはINIT ACKの送信者がassociation作成に必要なparameterとstateをMessage Authentication Code(MAC)とともに含むこと。
State Cookieの定義の詳細は5.1.3

Unrecognized Parameter:

Parameter Type Value: 8

Parameter Length: Variable size.

Parameter Value:

This parameter is returned to the originator of the INIT chunk
when the INIT contains an unrecognized parameter that has a value
that indicates it should be reported to the sender. This
parameter value field will contain unrecognized parameters copied
from the INIT chunk complete with Parameter Type, Length, and
Value fields.
INITが送信側に報告するべき未認識のパラメータを含んでいる場合、このパラメータはINIT chunkの送信側に返される。
このparamter value field はParamter Type、Length、ValueをINIT chunkからコピーした未認識のパラメータを含む。

「RFC4960」をウィキ内検索

最終更新：2014年05月11日 20:17

今日	- 人
昨日	- 人
合計	- 人

Codeまとめby長谷川

メニュー

リンク

他のサービス

カウンター

更新履歴

RFC4960