2024年1月2日发(作者：)
流控制传输协议SCTP
摘要
SCTP被设计用来在IP网上传输PSTN信令消息,但能有更广泛的用途。
SCTP是一个可靠的传输层协议，运行在无连接的包网络上（如IP网）。它为用
户提供下列服务:
-- 确保（acknowledged）用户数据无差错，无重复的传送；
-- 根据通路MTU的限制，进行用户数据的分段；
-- 流内用户消息的顺序递交；（可选的）每个用户消息按到达顺序
（order-of-arrival）进行递交；
-- （可选的）多个用户消息捆绑到单个SCTP包中进行传输；
-- 通过在偶联的一端或两端提供的多归属（multi-homing）机制，提供网
络级容错；
SCTP的设计包含了避免拥塞机制和防泛播（flooding）及匿名攻击
（masquerade attacks）的能力。
目录
1. 5
1. 6
1.2 Architectural View 6
1.3 Functional View . 7
1.3.1 Association Startup 8
1.3.2 Sequenced Delivery . 9
1.3.3 User 9
1.3.4 Acknowledgement and . 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 10
1.3.7 11
1.4 . 11
1. 15
1.6 Serial 15
2. 16
3. SCTP . 16
3.1 SCTP Common Header . 17
3.2 Chunk 18
3.2.1 Optional/Variable-length 20
3.3 SCTP 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable 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 42
3.3.10.2 Missing 43
3.3.10.3 Stale 43
3.3.10.4 Out 44
3.3.10.5 44
3.3.10.6 Unrecognized 44
3.3.10.7 Invalid 45
3.3.10.8 45
3.3.10.9 No 46
3.3.10.10 Cookie Received While 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 48
5. . 52
5.1 Normal Establishment of 52
5.1.1 Handle 54
5.1.2 Handle 54
5.1.3 Generating 56
5.1.4 State 57
5.1.5 State 57
5.1.6 An Example of Normal 58
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
and 60
5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or 60
5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT 61
5.2.3 Unexpected . 61
5.2.4 Handle a COOKIE ECHO when a 62
5.2.4.1 An Example of a 64
5.2.5 Handle Duplicate 66
5.2.6 Handle Stale 66
5.3 Other 67
5.3.1 Selection of 67
6. User 67
6.1 Transmission of 69
6.2 Acknowledgement on Reception of 70
6.2.1 Tracking Peer's Receive 73
6.3 Management 75
6.3.1 75
6.3.2 Retransmission . 76
6.3.3 Handle 77
6.4 Multi-homed 78
6.4.1 Failover from Inactive 79
6.5 Stream Identifier and Stream . 80
6.6 Ordered and . 80
6.7 Report Gaps in Received 81
6.8 Adler-32 82
6. 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP . 85
7.2 SCTP Slow-Start and 87
7.2. 87
7.2.2 89
7.2.3 89
7.2.4 Fast Retransmit on 90
7.3 Path 91
8. 92
8.1 Endpoint 92
8.2 Path 92
8.3 93
8.4 Handle "Out of the blue" 95
8.5 . 96
8.5.1 Exceptions in Verification 97
9. Termination . 98
9.1 Abort of . 98
9.2 Shutdown of 98
10. Interface with 101
10.101
10.111
11. 114
11.1 114
11.2 SCTP Responses To 115
11.2.1 Countering 115
11.2.2 Protecting against Data Corruption in 115
11.2.3 115
11.2.4 Protecting against Blind Denial of 116
11.2.4.116
11.2.4.2 118
11.2.4.3 Improper Monopolization .118
11.3 Protection against Fraud 119
12. Recommended Transmission Control Block (TCB) 120
12.1 Parameters necessary for the 120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport 122
12.4 General 123
13. 123
13.1 IETF-defined 123
13.2 IETF-defined Chunk 124
13.3 IETF-defined Additional .124
13.4 Payload 125
14. Suggested SCTP Protocol 125
15. 126
16. Authors' .126
17. 128
18. 129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
1. 引言
本节解释了发展SCTP的缘由, SCTP提供的服务及理解协议细节所需的基本概念。
1.1 动机
作为IP网上可靠数据传输的主要手段，TCP [RFC793] 已经提供了非常好的服务
（产生了大量应用）。然而，近来越来越多的应用发现TCP具有许多局限性，进
而已经改用它们自己运行在UDP[RFC768]上的可靠数据传输协议。用户希望TCP
解决的局限性主要有：
-- TCP保证用户数据的可靠传输及严格按传输顺序向用户递交数据。然而一
些应用仅需数据的可靠传输（无需维持用户数据的顺序），而另一些也仅需
部分数据按序递交。在这两种情况下，TCP可能引发的队头阻塞
（head-of-line blocking）问题会造成不必要的延迟。
-- TCP面向流的本质经常是麻烦的来源。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 sockets的局限性使得利用多归属机制提供高度可得到的数据传输变
的更为复杂。
-- TCP 相对易于遭受拒绝服务攻击，如SYN攻击。
在IP网上传输PSTN信令就是一个需要解决TCP所有局限性的应用。尽管这个应用
直接推动了SCTP的开发，但是SCTP可能也满足其它一些应用的需要。
1.2 SCTP结构视图
SCTP被视为SCTP用户应用（简称SCTP用户）和无连接包网络服务（如IP）之间的
一层。本文档假定SCTP运行在IP之上。SCTP提供的基本服务就是在对等的SCTP用
户之间提供可靠的用户消息传输。SCTP通过两个SCTP端点（endpoints）间建立
的偶联提供此服务。第10节给出了SCTP和SCTP用户之间的API。
SCTP是面向连接的协议, 但SCTP的偶联（association）是一个比TCP的连接更广
泛的概念。在偶联建立的过程中，SCTP能让一个SCTP端点向另一SCTP端点提供一
个传输地址列表（如多个IP地址结合一个SCTP端口），通过传输地址列表SCTP端
点可达并从它发起SCTP包（传输地址列表是SCTP端点的标识）。The association
spans transfers over all of the possible source/destination combinations
which may be generated from each endpoint's lists.
_____________ _____________
| SCTP 用户 | | SCTP 用户 |
| 应用 | | 应用 |
|-------------| |-------------|
| SCTP | | SCTP |
| 传输服务 | | 传输服务 |
| | | |
|-------------| |-------------|
| |一个或多个 ---- 一个或多个 | |
| IP 网络服务 |IP 地址 IP 地址 | IP 网络服务 |
| |appearances / appearances| |
|_____________| ---- |_____________|
SCTP 端点 A |<-------- 网络传输 ------->| SCTP 端点 B
图 1: SCTP偶联的概念
1.3 SCTP功能视图
SCTP提供的传输服务能被分解为几个部分，如图2所示。
SCTP 用户应用
-----------------------------------------------------
_____________ ____________________
| | | 流内消息的 |
| | | 按序递交 |
| | |____________________|
| |
| | ____________________________
| | | 用户数据分段 |
| | |____________________________|
| |
| | ____________________________
| 偶联的 | | |
| 建立和 | | 证实的避免拥塞 |
| 释放 | | |
| | |____________________________|
| |
| | ____________________________
| | | 数据块捆绑 |
| | |____________________________|
| |
| | ________________________________
| | | 包的有效性验证 |
| | |________________________________|
| |
| | ________________________________
| | | 通路管理 |
|_____________| |________________________________|
图 2: SCTP传输服务的功能视图
1.3.1 偶联的建立和释放
偶联被来自SCTP用户的请求发起(见第10节的ASSOCIATE (or SEND)原语描述）。
在偶联初始化过程中，一个cookie机制————类似于Karn和Simpson在[RFC2522]
中所描述的————被运用，以提供安全保护。cookie机制经历四次握手，后两次
允许携带用户数据以便偶联的快速建立。偶联建立的消息序列在第五节中描述。
接到SCTP用户请求时，SCTP对激活偶联进行正常关闭(见第10节的SHUTDOWN原语
描述）。SCTP也允许异常关闭偶联，在接到SCTP用户请求(ABORT原语)或检测到
SCTP层的内部错误时。第9节描述了正常和异常关闭偶联的过程。
SCTP不支持半开（half-open）状态（TCP支持）————一端可以继续发送数据，尽
管另一端已经关闭。当任一端点执行正常关闭（shutdown）时，两端上的偶联都
将停止接收来自用户的新数据，而仅仅递交正常关闭时已在队列中的数据（见第9节）。
1.3.2 流内消息地按序递交
SCTP中术语"流" 表示把用户消息依次递交给ULP（upper-layer protocol）的顺
序，而在TCP中术语"流"指字节的顺序。
SCTP用户在偶联建立时能指定偶联支持流的数目，此数目要和远端（对端）进行
协商(见5.1.1)。用户消息关联于流号（流的标识）（见第10节SEND, RECEIVE原
语），SCTP内部给SCTP用户传给流的每一消息都分配一个流内的序列号。在接受
端，SCTP确保流内的消息按序递交给SCTP用户。这样，尽管一个流可能被阻塞，
但其它流的消息递交仍可继续。
SCTP提供了一种绕开按需递交的机制，按此机制发送的用户消息在到达对端时即
被递交给SCTP用户。
1.3.3 用户数据分段
在需要的时候，SCTP对用户消息进行分段以确保传递给底层的SCTP包符合通路
MTU的要求。接受时分段被重新组装，进而递交给SCTP用户。
1.3.4 消息证实和避免拥塞
SCTP为每一个用户消息（分段的或未分段的）分配一个传输的序列号TSN，它于
流级别上的序列号无关。接收端证实所有接收到的TSNs，即便存在消息遗漏（gaps）。
通过这种方式，可靠的消息传输在功能上独立于流内的按序递交。
当适时的证实消息没有被收到时，消息证实和避免拥塞功能负责SCTP包的重传。
包的重传受避免拥塞过程（类似于TCP中采用的）的制约。此功能的详细描述见
第6节和第7节。
1.3.5 数据块捆绑
SCTP包由一个公共头和一个或多个数据块组成（见第3节）。每个数据块可以
包含用户数据，也可以包含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.
1.3.6 包的有效性验证
SCTP包的公共头包含两个必备的字段：验证标签字段和32位的校验字段（Adler
-32校验的描述见附录B）。验证标签字段的值在偶联建立时由各个端点分别选定。
带有无效验证值的包被丢弃，以防止匿名攻击和来自原来偶联的过期SCTP包。
Adler-32校验值应该被SCTP包的发送者提供以防止数据在网络中被破坏，接收者
丢弃带有无效Adler-32校验值的SCTP包。
1.3.7 通路管理
通过第10节描述的原语，SCTP用户（sending）能管理（manipulate）用作SCTP
包目的地的传输地址集合。SCTP通路管理功能可以根据SCTP用户的指令和符合条
件的目的地址集合的当前可达性状态，为每个需要发送的SCTP包选择一个目的传
输地址。通路管理功能通过心跳（heartbeats）监视目的地址的可达性，仅当其
它包的交互不足以提供此信息时；并在任何远端传输地址的可达性改变时，警告
SCTP用户。通路管理功能也负责在偶联建立过程中向远端报告符合条件的本地传
输地址集合及向SCTP用户报告从远端返回的传输地址集合。
在偶联建立时, 每一个SCTP端点的主通路（primary path）被定义，被用于SCTP
包的正常发送。
在接受端，通路管理负责在对输入（inbound）SCTP包作进一步处理之前，验证
其所属的偶联是否存在。
注意: 通路管理和包验证同时进行, 尽管上面分别进行了描述, 但事实上它们不
可能被分开执行。
1.4 主要术语
o Active destination transport address: A transport address on a
peer endpoint which a transmitting endpoint considers available
for receiving user messages.
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 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 Cumulative TSN Ack Point: The TSN of the last DATA chunk
acknowledged via the Cumulative TSN Ack field of a SACK.
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 Inactive destination transport address: An address which is
considered inactive due to errors and unavailable to transport
user messages.
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 网络字节顺序 : 最重要的字节优先, a.k.a., Big Endian.
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 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 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 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 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 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 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 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 user application (SCTP user): The logical higher-layer
application entity which uses the services of SCTP, also called
the Upper-layer Protocol (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 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.
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 assure sequenced delivery of the user messages within a
given stream. One stream sequence number is attached to each user
message.
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 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 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 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 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.
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 User message: The unit of data delivery across the interface
between SCTP and its user.
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.
1.5. 缩略语
MAC - Message Authentication Code [RFC2104]
RTO - Retransmission Time-out
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.6 序列号算法
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).
Comparisons and arithmetic on TSNs in this document SHOULD use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more
than 2**31 - 1 above the beginning TSN of its current send window.
Doing so will cause problems in comparing TSNs.
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.
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 uses normal
arithmetic.
2. Conventions
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].
3. SCTP包格式
SCTP包由一个公共头和一个或多个数据块组成。每个数据块可以包含用户数据，
也可以包含SCTP控制信息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
多个块能被捆绑到一个SCTP包中（受限于通路MTU的大小），但INIT,INIT ACK和
SHUTDOWN COMPLETE块除外。这些块不能和其它块捆绑在一个SCTP包内。数据块捆
绑的更多细节见6.10。
如果一个用户消息不能放进一个SCTP包中，用6.9定义的过程对消息进行分段放入
多个块内。
SCTP包的所有整数字段必须用网络字节顺序进行传递，除非另有说明。
3.1 SCTP公共头字段描述
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 源端口号 | 目的端口号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 验证标签Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 校验值Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
源端口号: 16 bits (unsigned integer)
SCTP发送者的端口号，能被接收者用来确定此SCTP包所属的偶联————结合源
IP地址，SCTP目的端口号及可能的目的IP地址。
目的端口号: 16 bits (unsigned integer)
SCTP包被发往的SCTP端口号。接收主机用此端口号分发SCTP包到正确的接收
端点（应用）。
验证标签: 32 bits (unsigned integer)
接收者用验证标签验证发送者的有效性。传输时，验证标签必须被填为偶联
初始化时从对端接收到Initiate标签的值，下列情况例外：
- 包含INIT块的SCTP包必须将验证标签字段置零。
- 包含T-比特被设置的SHUTDOWN-COMPLETE块的SCTP包的验证标签必须
从包含SHUTDOWN-ACK块的SCTP包中拷贝。
- 包含ABORT块的SCTP包的验证标签可以从造成ABORT块被发送的SCTP包中
拷贝。细节见8.4和8.5。
INIT块必须是携带它的SCTP包内的唯一的块。
校验值: 32 bits (unsigned integer)
此字段包含SCTP包的校验值。它的计算在6.8中描述。SCTP用附录B中描述
的Adler-32算法计算校验值。
3.2 SCTP数据块字段描述
下图是在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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
块类型: 8 bits (unsigned integer)
指定了包含在块值（Chunk Value）字段的信息的类型。取值范围为0到254。
255被预留以备将来扩充时用。
块类性的值被定义如下:
ID 值 块类型
----- ----------
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
块类型的最高两个比特指定了正在处理的端点不识别块类型时必须（要）采取
的行为。
00 - 停止处理并丢弃此SCTP包，也不处理包内的其他块。
01 - 停止处理并丢弃此SCTP包，也不处理包内的其他块，并用块ERROR或块INIT
ACK（'Unrecognized Parameter Type'）向对端报告。
10 - 跳过此块，继续处理。
11 - 跳过此块，继续处理，并用ERROR块（'Unrecognized Chunk Type'）向对
端报告。
注意: 块ECNE和块CWR类型被预留以备将来明确拥塞通知ECN（Explicit
Congestion Notification）时使用。
块标记: 8 bits
这些比特的用法取决于块类型。除非特别指明，否则传输时它们被置零，接
收时被忽略。
块长度: 16 bits (unsigned integer)
表示块的长度（字节的个数），包含块类型，块标记，块长度和块值字段。
因此，如果块值字段为零长度（块值字段不存在），则长度字段的值为4。
块长度字段不包括任何填充的字节。
块值: 可变长度
块值字段包含了在块中将要传递的实际信息，其用法和格式取决于块类型。
块的总长度(包含Type, Length和Value 字段)必须是4的倍数，否则发送者必
须用零字节进行填充，并且填充的字节不计入块长度字段。发送者从不会填充
多于3个字节，接收者忽略被填充的字节。
SCTP定义的块在3.3中详细描述。The guidelines for IETF-defined chunk
extensions can be found in Section 13.1 of this document.
3.2.1 可选/可变长度的参数格式
SCTP控制块的块值字段由与块类型相关的（依赖于块类型）头部（必备的）及
零或多个参数组成。包含在一个块内的可选/可变长度参数的格式被定义如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameter Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
块参数类型: 16 bits (unsigned integer)
参数类型的标识符，取值范围为0到65534。值65535被预留以备IETF定义扩展
时使用，其它值（未出现在SCTP块描述中）被IETF预留。
块参数长度: 16 bits (unsigned integer)
参数的字节个数，包括参数类型，参数长度和参数值字段。具有零长度参数值
字段（参数值字段不存在）的参数的长度字段将有值4，参数长度包含任何填
充的字节。
块参数值: 可变长度.
参数值字段包含了在参数中将要传递的实际信息。
参数的总长度(包含Type, Length和Value 字段)必须是4的倍数，否则发送者必
须在结尾（参数值字段之后）用零字节进行填充，并且填充的字节不计入参数长
度字段。发送者从不会填充多于3个字节，接收者忽略被填充的字节。
参数类型的最高两个比特指定了正在处理的端点不识别参数类型时必须（要）采
取的行为。
00 - 停止处理并丢弃此SCTP包，也不处理包内的其他块。
01 - 停止处理并丢弃此SCTP包，也不处理包内的其他块，并用块ERROR或块INIT
ACK（'Unrecognized Parameter Type'）向对端报告。
10 - 跳过此参数，继续处理。
11 - 跳过此参数，继续处理，并用块ERROR或块INIT ACK（'Unrecognized Parameter
Type'）向对端报告。
具体的SCTP参数被定义在相关SCTP块的描述部分。IETF定义的参数扩展规则见13.2。
3.3 SCTP 数据块定义
这一部分定义了各种SCTP块类型的格式。
3.3.1 Payload Data (DATA) (0)
The following format MUST be used for the DATA chunk:
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
应该被置零，接收者忽略。
U bit: 1 bit
无序(U)nordered消息指示符。被置'1'表示这是一个无序的DATA块，没有SSN
（流序列号）被分配给此DATA块，接收者忽略SSN字段。
重新组装后（如果必要的话），无序DATA块无须再进行重新排序，被接收者
直接分发给上层ULP。
如果无序（用户）消息被分段， 则每一片段(fragment)的U比特都得置'1'。
B bit: 1 bit
开始(B)eginning片段指示符，置'1'表示用户消息的第一个片段。
E bit: 1 bit
结尾(E)nding片段指示符，置'1'表示用户消息的最后一个片段。
不分段用户消息应把B比特和E比特都置为'1'。B比特和E比特都置为'0'表示
多个片段用户消息中的一个中间片段, 总结如下表:
B E 描述
============================================================
| 1 0 | 分段用户消息的第一个片段 |
+----------------------------------------------------------+
| 0 0 | 分段用户消息的中间片段 |
+----------------------------------------------------------+
| 0 1 | 分段用户消息的最后一个片段 |
+----------------------------------------------------------+
| 1 1 | 不分段用户消息 |
============================================================
| 表 1: 分段描述标记 |
============================================================
当一个（用户）消息被分为多个片段（块）进行传送时, 接收者用TSNs（传输
序列号）来重新组装消息。因此为分段用户消息的每一个片断所用的TSNs必须
严格有序（strictly sequential）。
长度: 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 no user data field will
have Length set to 16 (indicating 16 bytes).
TSN : 32 bits (unsigned integer)
块DATA的传输序列号，有效范围为0到4294967295 (2**32 - 1)。TSN wraps
back to 0 after reaching 4294967295.
流标识符 S: 16 bits (unsigned integer)
标识用户数据所属的流。
流序列号 n: 16 bits (unsigned integer)
用户数据在流S内的序列号，有效范围为0到65535。
当一个用户消息被SCTP分段传输时，每一个片断具有相同的流序列号SSN。
净荷协议标识符: 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 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).
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
用户数据: 可变长度
字段应为4的倍数，否则实现必须在结尾用零字节填充，但填充的字节不计
入常独字段。发送者从不会填充多于3个字节。
3.3.2 Initiation (INIT) (1)
用来在两个端点间发起一个SCTP偶联，格式如下:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
注意 1: 块INIT能包含多个地址，可以是IPv4 和/或IPv6的任意组合。
注意 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.
注意 3: 块INIT千万不要包含多于一个的主机名地址参数。而且INIT的发送者
也不要把INIT中的任何其它地址类型和主机名地址关联起来。INIT的接收者必
须忽略任何其它地址类型，如果主机名地址参数在被接收的块INIT内出现的话。
注意 4: 此参数, 如果出现, 指定了发送端点能支持的所有地址类型。不提供
此参数表明发送端点能支持任何地址类型。
块INIT内的块标记字段被预留，发送者将所有比特置零，接收者忽略所有比特。
The sequence of parameters within an INIT can be processed in any order.
Initiate标签: 32 bits (unsigned integer)
块INIT的接收者(the responding end)必须记录Initiate标签参数的值。在偶
联内（如果偶联建立成功），此接收者必须把此值填入到它所发送的所有SCTP
包的验证标签字段。
Initiate标签允许有除零外的任何值，选择此标签值的更多细节见5.3.1。
如果被接收到的INIT块的Initiate标签的值为零，接收者必须视为一个错误，
关闭偶联并发送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 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); 然而，端点可以在SACK块中改变它所发送的a_rwnd的值。
输出流(OS)个数 : 16 bits (unsigned integer)
块INIT的发送者希望在此偶联中创建的输出流个数，值0千万不要被用。
注意: OS被置0的块INIT的接收者应该放弃（异常关闭abort）偶联。
输入流(MIS)个数 : 16 bits (unsigned integer)
块INIT的发送者允许对端在此偶联中创建的输入流的最大个数，值0千
万不要被用。
注意: 两个端点不就偶联中支持流（输入和输出）的实际个数进行协商，
而是用min（requested, offered)。细节见5.1.1。
注意: MIS被置0的块INIT的接收者应该放弃（异常关闭abort）偶联。
初始TSN(I-TSN) : 32 bits (unsigned integer)
发送者将要使用的初始TSN，有效范围为0到4294967295，可被填为Initiate
标签字段的值。
3.3.2.1 INIT中的可选/可变长度参数
下列参数遵循3.2.1中定义的Type-Length-Value格式。任何TLV字段必须跟在前
一部分中定义的固定长度字段的后面。
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)
发送端点的IPv4地址，It is binary encoded。
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 bit (unsigned integer)
发送端点的IPv6地址，It is binary encoded。
注意: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]
but should instead use an IPv4 Address Parameter for an IPv4
address.
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.
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.
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.
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.
Cookie Preservative (9)
块INIT的发送者将会用这个参数建议（suggest）块INIT的接收者延长Cookie
状态（the State Cookie）的寿命。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-span Increment: 32 bits (unsigned integer)
指定发送者希望接收者在其缺省cookie寿命基础上新增的额外增量（单位毫秒）。
当重新试图和对端建立偶联时，这个可选参数应该被发送者加入到INIT块中。
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. 出于自省安全的考虑，接收者可
以选择忽略被建议的cookie寿命增量。
Host Name Address (11)
块INIT的发送者用这个参数把它的主机名（Host Name）传给对端(代替IP地
址）。对端负责解析主机名。Using this parameter might make it more
likely for the association to work across a NAT box.
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: 可变长度
This field contains a host name in "host name syntax" per RFC1123
Section 2.1 [RFC1123]. 解析主机名的方法不属于SCTP的范畴。
Note: At least one null terminator is included in the Host Name
string and must be included in the length.
Supported Address Types (12)
块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)
用相应的地址TLV的类型值来填充(如, IPv4 = 5, IPv6 = 6, Hostname = 11)。
3.3.3 Initiation Acknowledgement (INIT ACK) (2):
块INIT ACK用来证实的SCTP偶联的初始化（INIT）.
块INIT ACK参数部分的格式类似于块INIT。它有两个额外的可变参数: The State
Cookie和the Unrecognized Parameter:
块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)
块INIT ACK的接收者记录Initiate标签参数的值。在偶联内（如果偶联建立
成功），此接收者必须把此值填入到它所发送的所有SCTP包的验证标签字段。
Initiate标签允许有除零外的任何值，选择此标签值的更多细节见5.3.1。
如果被接收到的INIT块的Initiate标签的值为零，接收者必须视为一个错误，
关闭偶联并发送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).
输出流(OS)个数 : 16 bits (unsigned integer)
块INIT ACK的发送者希望在此偶联中创建的输出流个数，值0千万不要被用。
注意: OS被置0的块INIT ACK的接收者应该销毁偶联，放弃其TCB。
输入流(MIS)个数 : 16 bits (unsigned integer)
块INIT ACK的发送者允许对端在此偶联中创建的输入流的最大个数，值0千
万不要被用。
注意: 两个端点不就偶联中支持流（输入和输出）的实际个数进行协商，
而是用min（requested, offered)。细节见5.1.1。
注意: MIS被置0的块INIT的接收者应该销毁偶联，放弃其TCB。
Initial TSN (I-TSN) : 32 bits (unsigned integer)
INIT-ACK发送者将要使用的初始TSN，有效范围为0到4294967295，可被填
为Initiate标签字段的值。
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
注意 1: 块INIT ACK能包含多个IP地址参数，可以是IPv4和/或IPv6的任意组合。
注意 2: The ECN capable field is reserved for future use of Explicit
Congestion Notification.
注意 3: 块INIT ACK千万不要包含多于一个的主机名地址参数。而且INIT ACK
的发送者也不要把INIT ACK中的任何其它地址类型和主机名地址关联起来。
INIT ACK的接收者必须忽略任何其它地址类型，如果主机名地址参数在被接收
的块INIT ACK内出现的话。
实现注意: 由于可变大小的cookie状态及可变的地址列表，实现必须准备接受
一个相当长（大于1500字节）的INIT ACK块。例如，如果INIT的一个响应者
（responder）希望发送1000个IPv4地址，在INIT ACK块中将至少需要8000字节
来编码。
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.
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.
参数State Cookie和Unrecognized Parameters使用定义在3.2.1的TLV格式，
它们在下面被描述。其它字段同于INIT块中的相应部分。
3.3.3.1 可选/可变长度参数
State Cookie
Parameter Type Value: 7
Parameter Length: variable size, depending on Size of Cookie
Parameter Value:
对INIT ACK的发送者来说，此参数值必须包含创建偶联所必要的所有
状态及参数信息，连同一个消息验证码(MAC)。State Cookie定义的
细节见5.1.3。
Unrecognized Parameters:
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 which has a
value that indicates that it should be reported to the sender.
参数值字段将包含收到的INIT块中不识别参数的拷贝（包括T,L,V字段）
3.3.4 Selective Acknowledgement (SACK) (3):
用来向对端证实已收到的DATA块及在收到的DATA块序列中的gaps（用TSNs表示）。
SACK必须包含参数Cumulative TSN Ack 及a_rwnd。
根据定义，参数Cumulative TSN Ack的值为：在接收到的TSNs序列出现中断之
前的那个TSN；下一个TSN所标识的SCTP包还没有被发送此SACK块的端点收到。
此参数对所有小于或等于此值的TSN进行了证实。
SACK接收者对a_rwnd处理的细节见6.2.1.
SACK也包含零个或多个Gap Ack Blocks。每一个Gap Ack Block对在所有接收
到TSNs中的一个TSNs序列（following a break）进行了证实。根据定义, 所
有被Gap Ack Blocks证实的TSNs都大于Cumulative 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
传输时所有比特被置零，接收时忽略所有比特。
Cumulative TSN Ack: 32 bits (unsigned integer)
一个TSN，在此TSN之前的所有DATA块都已收到。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
integer)
用于更新SACK发送者的接收缓存空间（单位字节），细节见6.2.1。
Number of Gap Ack Blocks: 16 bits (unsigned integer)
包含在SACK中的Gap Ack Blocks的个数。
Number of Duplicate TSNs: 16 bit
端点收到的重复TSN个数，每一个重复的TSN被列举在Gap Ack Blocks的后面。
Gap Ack Blocks:
包含N个（定义在Number of Gap Ack Blocks字段）Gap Ack Block。每一个
Gap Ack Block中，所有(Cumulative TSN Ack + Gap Ack Block Start)<= *
<=(Cumulative TSN Ack + Gap Ack Block End)的DATA块都已被正确的接收到。
Gap Ack Block Start: 16 bits (unsigned integer)
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.
Gap Ack Block End: 16 bits (unsigned integer)
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.
For example, assume the receiver has the following DATA chunks newly
arrived at the time when it decides to send a Selective 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):
+--------------------------------+
| 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)
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. 发送一个SACK之后，重复计数器被重新初始化为0。
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.
3.3.5 Heartbeat Request (HEARTBEAT) (4):
用来向对端探查某一特定目的传输地址（当前的偶联内）的可达性。
块值域包含心跳信息————可变长度，仅被发送者理解的不透明数据结构。
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
传输时所有比特被置零，接收时忽略所有比特。
Heartbeat Length: 16 bits (unsigned integer)
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.:
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
发送者相关的心跳信息通常包括：块HEARTBEAT发送时发送者当前时间的信
息和块HEARTBEAT被发往的目的传输地址（见8.3）。
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):
作为对HEARTBEAT块的响应，端点应该向对端发送HEARTBEAT ACK（见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.
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
传输时所有比特被置零，接收时忽略所有比特。
Heartbeat Ack Length: 16 bits (unsigned integer)
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
3.3.7 Abort Association (ABORT) (6):
用来异常关闭偶联，可以包含参数Cause通知接收者放弃的原因。块DATA不能和
块ABORT捆绑在一起。控制块(除INIT, INIT ACK和SHUTDOWN COMPLETE)可以和
块ABORT捆绑，但在SCTP包中它们必须被放置在块ABORT的前面，否则将会被接
收者忽略。
如果端点接收到一个格式错误或相应的偶联不存在的块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
Reserved: 7 bits
传输时所有比特被置零，接收时忽略所有比特。
T bit: 1 bit
0表示发送者有一个TCB，但已被破坏；1表示发送者没有TCB。
注意: Special rules apply to this chunk for verification, 细节见8.5.1。
Length: 16 bits (unsigned integer)
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.8 Shutdown Association (SHUTDOWN) (7):
用来正常关闭偶联，格式如下：
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
传输时所有比特被置零，接收时忽略所有比特。
Length: 16 bits (unsigned integer)
Indicates the length of the parameter. Set to 8.
Cumulative TSN Ack: 32 bits (unsigned integer)
This parameter contains the TSN of the last chunk received in
sequence before any gaps.
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)
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (8):
用来在shutdown进程完成时，作为对收到SHUTDOWN的证实，细节见9.2。
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
传输时所有比特被置零，接收时忽略所有比特。
3.3.10 Operation Error (ERROR) (9):
用来向对端报告一定的错误状态（error conditions），包含一个或多个错误
原因。An Operation Error is not considered fatal in and of itself, but
may be used with an ABORT chunk to report a fatal condition。格式如下:
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
传输时所有比特被置零，接收时忽略所有比特。
Length: 16 bits (unsigned integer)
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.:
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)
被报告错误状态的类型。
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)
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 Invalid Stream Identifier (1)
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)
Contains the Stream Identifier of the DATA chunk received in
error.
Reserved: 16 bits
This field is reserved. It is set to all 0's on transmit and
Ignored on receipt.
3.3.10.2 Missing Mandatory Parameter (2)
Cause of error
---------------
缺少必备参数: 在收到的块INIT或INIT ACK中，缺少一个或多个必备的TLV参数。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
缺少必备参数个数: 32 bits (unsigned integer)
This field contains the number of parameters contained in the
Cause-specific Information field.
缺少必备参数类型: 16 bits (unsigned integer)
Each field will contain the missing mandatory parameter number.
3.3.10.3 Stale Cookie Error (3)
Cause of error
--------------
旧Cookie错误: State Cookie已经过期。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness: 32 bits (unsigned integer)
当前时刻与State Cookie过期时刻的差额（单位毫秒）。
错误原因的发送者可以选择报告State Cookie已经过期了多长时间（通过
字段Measure of Staleness取非零值）。如果发送者不想提供这个消息，
它应该把字段Measure of Staleness置零。
3.3.10.4 Out of Resource (4)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.5 Unresolvable Address (5)
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.
3.3.10.6 Unrecognized Chunk Type (6)
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.
3.3.10.7 Invalid Mandatory Parameter (7)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.8 Unrecognized Parameters (8)
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.
3.3.10.9 No User Data (9)
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)
The TSN value field contains the TSN of the DATA chunk received
with no user data field.
This cause code is normally returned in an ABORT chunk (see
Section 6.2)
3.3.10.10 Cookie Received While Shutting Down (10)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.11 Cookie Echo (COOKIE ECHO) (10):
仅仅在偶联初始化时被使用。它被偶联的发起者发往对端，以完成偶联的初始
化。COOKIE ECHO必须领先于偶联内的任何DATA块被发送，但可以和一个或多个
DATA块捆绑于一个SCTP包内。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cookie /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bit
传输时所有比特被置零，接收时忽略所有比特。
Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the 4 bytes of
the chunk header and the size of the Cookie.
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
实现应该使cookie尽可能小以确保互操作性。
3.3.12 Cookie Acknowledgement (COOKIE ACK) (11):
仅仅在偶联初始化时被使用，用来证实COOKIE ECHO。COOKIE ACK必须领先于
偶联内的任何DATA或SACK块被发送，但可以和一个或多个DATA或SACK块捆绑
于一个SCTP包内。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
传输时所有比特被置零，接收时忽略所有比特。
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (14):
用来在shutdown进程完成时，作为对收到SHUTDOWN ACK的证实，细节见9.2。
The SHUTDOWN COMPLETE chunk has no parameters.
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
Reserved: 7 bits
传输时所有比特被置零，接收时忽略所有比特。
T bit: 1 bit
0表示发送者有一个TCB，但已被破坏；1表示发送者没有TCB。
注意: Special rules apply to this chunk for verification, 细节见8.5.1。
4. SCTP 偶联状态图
在SCTP偶联的生命周期期间，受各种（外部）事件的驱动从一个状态转移到
另外一个状态。可能的事件如下：
o SCTP用户原语调用, 如, [ASSOCIATE], [SHUTDOWN], [ABORT],
o 收到INIT, COOKIE ECHO, ABORT, SHUTDOWN, 等控制块, 或
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.
注意: 块名全用大写字母, 参数名仅首字母被大写, 如, COOKIE ECHO块类型
vs. State Cookie 参数。如果有多于一个的event/message能造成状态转移，
用(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
注意:
1) 如果收到的COOKIE ECHO中的State Cookie是无效的(如,无法通过完整性检查)，
接收者必须丢弃此SCTP包；如果收到的State Cookie已过期(见5.1.5), 接收者必
须必须发送ERROR块。在两者情况下，接收者都保持在CLOSED状态。
2) 如果T1-init定时器超期，端点必须重传INIT并重起T1-init定时器而不改变状
态。重传的最大次数为'smits'。此后，端点必须放弃初始化过
程并向SCTP用户报告错误。
3) 如果T1-cookie定时器超期，端点必须重传COOKIE ECHO并重起T1-cookie定时
器而不改变状态。重传的最大次数为'smits'。此后，端点必须
放弃初始化过程并向SCTP用户报告错误。
4) 在SHUTDOWN-SENT状态，端点必须无延迟证实任何收到的DATA块。
5) 在SHUTDOWN-RECEIVED状态, 端点千万不要接收任何新的SCTP用户发送请求。
6) 在SHUTDOWN-RECEIVED状态，端点必须传送或重传已在队列中的数据直到所
有数据都被成功的传送后，偶联离开此状态。
7) 在SHUTDOWN-ACK-SENT状态, 端点千万不要接收任何新的SCTP用户发送请求。
CLOSED状态表明偶联没有被创建(如, 不存在)。
5. 偶联初始化
在从端点A到端点Z能发送第一个数据之前，两个端点必须完成初始化进程以在它
们之间创立一个SCTP偶联。
一个端点的SCTP用户应该用ASSOCIATE原语去初始化和另一个SCTP端点的偶联。
实现注意: 从SCTP用户的观点来看，偶联可以被隐含的创建（无须调用
ASSOCIATE原语）————通过端点第一次向对端发送用户数据。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 偶联的正常建立
初始化进程由下列步骤组成（假设SCTP端点"A"试图建立到SCTP端点"Z"的偶联，
"Z"接受新偶联）：
A) "A" 发送INIT到"Z"。"A" 必须在INIT的Initiate Tag字段中提供它的
Verification Tag (Tag_A)。Tag_A应该是从1到4294967295之间的一个随机数
(标签值选择见5.3.1)。发送INIT后，"A" 启动T1-init定时器并进入COOKIE-
WAIT状态。
B) "Z" 立即响应INIT ACK。INIT ACK的目的IP地址必须被设置为INIT（INIT
ACK正响应的）的源IP地址。在响应中除了填写其它参数外，"Z" 必须设置
Verification Tag字段为Tag_A并在Initiate Tag中提供它自己的Verification
Tag (Tag_Z)。
而且, "Z" 必须产生并发送一个State Cookie（在INIT ACK内）。State
Cookie的产生见5.1.3。
注意: 在发送带有State Cookie参数的INIT ACK之后，"Z" 千万不要分配任
何资源，也不要保持任何新偶联的的状态。否则，"Z" 将易于受到资源攻击。
C) 接收到"Z"的INIT ACK后，"A" 会停止T1-init定时器并离开COOKIE-WAIT状
态。接着"A" 会在COOKIE ECHO中发送在INIT ACK中收到的State Cookie，
启动T1-cookie定时器并进入COOKIE-ECHOED状态。
注意: COOKIE ECHO能和任何未发的（pending）输出DATA捆绑，但必须是包
内的第一个块并且在COOKIE ACK被返回之前，发送者不要向对端发送任何包。
D) 接收到COOKIE ECHO后, "Z" 构建TCB并进入ESTABLISHED状态，然后响应
COOKIE ACK。COOKIE ACK可和任何未发的（pending）DATA（和/或SACK）捆
绑，但COOKIE ACK必须是包内的第一个块。
实现注意: 收到一个有效的COOKIE ECHO时，实现可以选择发发送Communication
Up通知给SCTP用户。
E) 接收到COOKIE ACK后, "A" 将从状态COOKIE-ECHOED进入到状态ESTABLISHED，
停止T1-cookie定时器。它也可用Communication Up（第10节）通知ULP偶联
已成功建立。
INIT或INIT ACK千万不要和任何其他块进行捆绑，它们必须是携带它们的SCTP包
的唯一块。
端点必须发送INIT ACK 到携带它接收到的INIT的IP地址。
注意: T1-init定时器和T1-cookie 定时器遵守相同的规则（见6.3.）。
如果一个端点在收到INIT, INIT ACK, 或COOKIE ECHO后决定不建立新的偶联————
INIT或INIT ACK中缺少必备参数，无效的参数值，或缺乏本地资源等，它必须用
ABORT响应。它也应该通过在ABORT块中包含Error Causes参数指明放弃的原因，
如缺少必备参数的类型等。包含ABORT块的输出SCTP包的公共头的Verification
Tag字段必须被置为对端Initiate Tag的值。
偶联中接收到第一个DATA块之后，端点必须立即用SACK进行证实。随后的证实按
6.2描述的进行。
当TCB被创建后，每一端点必须将它内部的Cumulative TSN Ack指示器设为Initial
TSN - 1。
实现注意: IP地址和SCTP端口号通常被用作在一个SCTP实例内查找TCB的关键字。
5.1.1 Handle Stream Parameters
发送者会在INIT和INIT ACK中指明希望在偶联中拥有的OS与能从其它端接收的MIS。
接收到来自其它端的流配置信息后，端点会执行下列检查：如果对端的MIS小
于本端点的OS（对端无法支持本端想要配置的所有输出流）, 必须用对端的
MIS，或abort偶联并向它的上层报告对端资源shortage。
偶联被初始化后，任何一端有效的输出流标识符范围为0到min(local OS,
remote MIS)-1.
5.1.2 Handle Address Parameters
偶联初始化过程中，端点会用下面的规则去发现并收集对端的目的传输地址(es)。
A) 如果在接受到的INIT或INIT ACK中没有任何地址参数，端点会从携带此块的
IP包中取出源IP地址，与SCTP源端口号一起作为对端的唯一目的传输地址。
B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP
source port.
端点必须忽略任何其他IP地址参数，如果它们也出现在接收到的INIT或
INIT ACK中。
INIT接收者解析主机名的时机存在安全隐患。如果一收到INIT立即解析主
机名，并且接收者所用的解析机制（如DNS查询）（potential）陷入长时
间的等待中，那么可能接收者在能创建State Cookie并释放本地资源之前，
因须等待解析结果而open自己从而受到资源攻击。
因此在此情形下，INIT接收者必须延迟主机名解析直到从对端收到COOKIE
ECHO 。INIT接收者应该用接收到的主机名（而不是目的传输地址）来创建
State Cookie并发送INIT ACK到承载INIT的源IP地址。
接收者接收到INIT ACK后，总会立即试图解析地址（主机名）。
INIT或INIT ACK的接收者在地址（主机名）被成功的解析之前，千万不要发
送任何数据到对端(piggy-backed or stand-alone)。
如果地址（主机名）解析不成功，端点必须立即发送ABORT（"Unresolvable
Address"）到对端。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.
实现注意: 在一些情形下(如, 实现不控制用于传输的源IP地址)，端点可能
需要在它的INIT或INIT ACK中包含所有能被用来向对端发送包的源IP地址。
利用上面的规则从INIT或INIT ACK得到所有的传输地址之后，端点会从中选择
一个作为初始主通路。
注意: INIT-ACK必须被发往INIT的源地址。
发布评论