Network Working Group R. Stewart, Ed.
Request for Comments: 4960 September 2007
Obsoletes: 2960, 3309
Category: Standards Track
Network Working Group R. Stewart, Ed.
Request for Comments: 4960 September 2007
Obsoletes: 2960, 3309
Category: Standards Track
Stream Control Transmission Protocol
流控制传输协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
本文件淘汰了RFC 2960和RFC 3309。它描述了流控制传输协议（SCTP）。SCTP旨在通过IP网络传输公共交换电话网（PSTN）信令消息，但具有更广泛的应用能力。
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
SCTP是一种可靠的传输协议，在IP等无连接分组网络上运行。它向用户提供以下服务：
-- acknowledged error-free non-duplicated transfer of user data,
--已确认的无错误非重复用户数据传输，
-- data fragmentation to conform to discovered path MTU size,
--数据碎片符合发现的路径MTU大小，
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
--在多个流中按顺序传递用户消息，带有单个用户消息的到达顺序传递选项，
-- optional bundling of multiple user messages into a single SCTP packet, and
--可选地将多个用户消息捆绑到单个SCTP数据包中，以及
-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.
--通过在关联的一端或两端支持多归属，实现网络级容错。
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.
SCTP的设计包括适当的拥塞避免行为以及对洪水和伪装攻击的抵抗。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Motivation .................................................5
1.2. Architectural View of SCTP .................................6
1.3. Key Terms ..................................................6
1.4. Abbreviations .............................................10
1.5. Functional View of SCTP ...................................10
1.5.1. Association Startup and Takedown ...................11
1.5.2. Sequenced Delivery within Streams ..................12
1.5.3. User Data Fragmentation ............................12
1.5.4. Acknowledgement and Congestion Avoidance ...........12
1.5.5. Chunk Bundling .....................................13
1.5.6. Packet Validation ..................................13
1.5.7. Path Management ....................................13
1.6. Serial Number Arithmetic ..................................14
1.7. Changes from RFC 2960 .....................................15
2. Conventions ....................................................15
3. SCTP Packet Format .............................................15
3.1. SCTP Common Header Field Descriptions .....................16
3.2. Chunk Field Descriptions ..................................17
3.2.1. Optional/Variable-Length Parameter Format ..........19
3.2.2. Reporting of Unrecognized Parameters ...............21
3.3. SCTP Chunk Definitions ....................................21
3.3.1. Payload Data (DATA) (0) ............................22
3.3.2. Initiation (INIT) (1) ..............................24
3.3.2.1. Optional/Variable-Length
Parameters in INIT ........................27
3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30
3.3.3.1. Optional or Variable-Length Parameters ....33
3.3.4. Selective Acknowledgement (SACK) (3) ...............34
3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39
3.3.7. Abort Association (ABORT) (6) ......................40
3.3.8. Shutdown Association (SHUTDOWN) (7) ................41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41
3.3.10. Operation Error (ERROR) (9) .......................42
3.3.10.1. Invalid Stream Identifier (1) ............44
3.3.10.2. Missing Mandatory Parameter (2) ..........44
3.3.10.3. Stale Cookie Error (3) ...................45
3.3.10.4. Out of Resource (4) ......................45
3.3.10.5. Unresolvable Address (5) .................46
3.3.10.6. Unrecognized Chunk Type (6) ..............46
3.3.10.7. Invalid Mandatory Parameter (7) ..........47
3.3.10.8. Unrecognized Parameters (8) ..............47
3.3.10.9. No User Data (9) .........................48
3.3.10.10. Cookie Received While Shutting
Down (10) ...............................48
1. Introduction ....................................................5
1.1. Motivation .................................................5
1.2. Architectural View of SCTP .................................6
1.3. Key Terms ..................................................6
1.4. Abbreviations .............................................10
1.5. Functional View of SCTP ...................................10
1.5.1. Association Startup and Takedown ...................11
1.5.2. Sequenced Delivery within Streams ..................12
1.5.3. User Data Fragmentation ............................12
1.5.4. Acknowledgement and Congestion Avoidance ...........12
1.5.5. Chunk Bundling .....................................13
1.5.6. Packet Validation ..................................13
1.5.7. Path Management ....................................13
1.6. Serial Number Arithmetic ..................................14
1.7. Changes from RFC 2960 .....................................15
2. Conventions ....................................................15
3. SCTP Packet Format .............................................15
3.1. SCTP Common Header Field Descriptions .....................16
3.2. Chunk Field Descriptions ..................................17
3.2.1. Optional/Variable-Length Parameter Format ..........19
3.2.2. Reporting of Unrecognized Parameters ...............21
3.3. SCTP Chunk Definitions ....................................21
3.3.1. Payload Data (DATA) (0) ............................22
3.3.2. Initiation (INIT) (1) ..............................24
3.3.2.1. Optional/Variable-Length
Parameters in INIT ........................27
3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30
3.3.3.1. Optional or Variable-Length Parameters ....33
3.3.4. Selective Acknowledgement (SACK) (3) ...............34
3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39
3.3.7. Abort Association (ABORT) (6) ......................40
3.3.8. Shutdown Association (SHUTDOWN) (7) ................41
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41
3.3.10. Operation Error (ERROR) (9) .......................42
3.3.10.1. Invalid Stream Identifier (1) ............44
3.3.10.2. Missing Mandatory Parameter (2) ..........44
3.3.10.3. Stale Cookie Error (3) ...................45
3.3.10.4. Out of Resource (4) ......................45
3.3.10.5. Unresolvable Address (5) .................46
3.3.10.6. Unrecognized Chunk Type (6) ..............46
3.3.10.7. Invalid Mandatory Parameter (7) ..........47
3.3.10.8. Unrecognized Parameters (8) ..............47
3.3.10.9. No User Data (9) .........................48
3.3.10.10. Cookie Received While Shutting
Down (10) ...............................48
3.3.10.11. Restart of an Association with
New Addresses (11) ......................49
3.3.10.12. User-Initiated Abort (12) ...............49
3.3.10.13. Protocol Violation (13) .................50
3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51
4. SCTP Association State Diagram .................................52
5. Association Initialization .....................................56
5.1. Normal Establishment of an Association ....................56
5.1.1. Handle Stream Parameters ...........................58
5.1.2. Handle Address Parameters ..........................58
5.1.3. Generating State Cookie ............................61
5.1.4. State Cookie Processing ............................62
5.1.5. State Cookie Authentication ........................62
5.1.6. An Example of Normal Association Establishment .....64
5.2. Handle Duplicate or Unexpected INIT, INIT ACK,
COOKIE ECHO, and ..........................................65
5.2.1. INIT Received in COOKIE-WAIT or
COOKIE-ECHOED State (Item B) .......................66
5.2.2. Unexpected INIT in States Other than
CLOSED, COOKIE-ECHOED, .............................66
5.2.3. Unexpected INIT ACK ................................67
5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67
5.2.4.1. An Example of a Association Restart .......69
5.2.5. Handle Duplicate COOKIE-ACK. .......................71
5.2.6. Handle Stale COOKIE Error ..........................71
5.3. Other Initialization Issues ...............................72
5.3.1. Selection of Tag Value .............................72
5.4. Path Verification .........................................72
6. User Data Transfer .............................................73
6.1. Transmission of DATA Chunks ...............................75
6.2. Acknowledgement on Reception of DATA Chunks ...............78
6.2.1. Processing a Received SACK .........................81
6.3. Management of Retransmission Timer ........................83
6.3.1. RTO Calculation ....................................83
6.3.2. Retransmission Timer Rules .........................85
6.3.3. Handle T3-rtx Expiration ...........................86
6.4. Multi-Homed SCTP Endpoints ................................87
6.4.1. Failover from an Inactive Destination Address ......88
6.5. Stream Identifier and Stream Sequence Number ..............88
6.6. Ordered and Unordered Delivery ............................88
6.7. Report Gaps in Received DATA TSNs .........................89
6.8. CRC32c Checksum Calculation ...............................90
6.9. Fragmentation and Reassembly ..............................91
6.10. Bundling .................................................92
7. Congestion Control .............................................93
7.1. SCTP Differences from TCP Congestion Control ..............94
3.3.10.11. Restart of an Association with
New Addresses (11) ......................49
3.3.10.12. User-Initiated Abort (12) ...............49
3.3.10.13. Protocol Violation (13) .................50
3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51
4. SCTP Association State Diagram .................................52
5. Association Initialization .....................................56
5.1. Normal Establishment of an Association ....................56
5.1.1. Handle Stream Parameters ...........................58
5.1.2. Handle Address Parameters ..........................58
5.1.3. Generating State Cookie ............................61
5.1.4. State Cookie Processing ............................62
5.1.5. State Cookie Authentication ........................62
5.1.6. An Example of Normal Association Establishment .....64
5.2. Handle Duplicate or Unexpected INIT, INIT ACK,
COOKIE ECHO, and ..........................................65
5.2.1. INIT Received in COOKIE-WAIT or
COOKIE-ECHOED State (Item B) .......................66
5.2.2. Unexpected INIT in States Other than
CLOSED, COOKIE-ECHOED, .............................66
5.2.3. Unexpected INIT ACK ................................67
5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67
5.2.4.1. An Example of a Association Restart .......69
5.2.5. Handle Duplicate COOKIE-ACK. .......................71
5.2.6. Handle Stale COOKIE Error ..........................71
5.3. Other Initialization Issues ...............................72
5.3.1. Selection of Tag Value .............................72
5.4. Path Verification .........................................72
6. User Data Transfer .............................................73
6.1. Transmission of DATA Chunks ...............................75
6.2. Acknowledgement on Reception of DATA Chunks ...............78
6.2.1. Processing a Received SACK .........................81
6.3. Management of Retransmission Timer ........................83
6.3.1. RTO Calculation ....................................83
6.3.2. Retransmission Timer Rules .........................85
6.3.3. Handle T3-rtx Expiration ...........................86
6.4. Multi-Homed SCTP Endpoints ................................87
6.4.1. Failover from an Inactive Destination Address ......88
6.5. Stream Identifier and Stream Sequence Number ..............88
6.6. Ordered and Unordered Delivery ............................88
6.7. Report Gaps in Received DATA TSNs .........................89
6.8. CRC32c Checksum Calculation ...............................90
6.9. Fragmentation and Reassembly ..............................91
6.10. Bundling .................................................92
7. Congestion Control .............................................93
7.1. SCTP Differences from TCP Congestion Control ..............94
7.2. SCTP Slow-Start and Congestion Avoidance ..................95
7.2.1. Slow-Start .........................................96
7.2.2. Congestion Avoidance ...............................97
7.2.3. Congestion Control .................................98
7.2.4. Fast Retransmit on Gap Reports .....................98
7.3. Path MTU Discovery .......................................100
8. Fault Management ..............................................100
8.1. Endpoint Failure Detection ...............................100
8.2. Path Failure Detection ...................................101
8.3. Path Heartbeat ...........................................102
8.4. Handle "Out of the Blue" Packets .........................104
8.5. Verification Tag .........................................105
8.5.1. Exceptions in Verification Tag Rules ..............105
9. Termination of Association ....................................106
9.1. Abort of an Association ..................................107
9.2. Shutdown of an Association ...............................107
10. Interface with Upper Layer ...................................110
10.1. ULP-to-SCTP .............................................110
10.2. SCTP-to-ULP .............................................120
11. Security Considerations ......................................123
11.1. Security Objectives .....................................123
11.2. SCTP Responses to Potential Threats .....................124
11.2.1. Countering Insider Attacks .......................124
11.2.2. Protecting against Data Corruption in the
Network ..........................................124
11.2.3. Protecting Confidentiality .......................124
11.2.4. Protecting against Blind
Denial-of-Service Attacks ........................125
11.2.4.1. Flooding ................................125
11.2.4.2. Blind Masquerade ........................126
11.2.4.3. Improper Monopolization of Services .....127
11.3. SCTP Interactions with Firewalls ........................127
11.4. Protection of Non-SCTP-Capable Hosts ....................128
12. Network Management Considerations ............................128
13. Recommended Transmission Control Block (TCB) Parameters ......129
13.1. Parameters Necessary for the SCTP Instance ..............129
13.2. Parameters Necessary per Association (i.e., the TCB) ....129
13.3. Per Transport Address Data ..............................131
13.4. General Parameters Needed ...............................132
14. IANA Considerations ..........................................132
14.1. IETF-defined Chunk Extension ............................132
14.2. IETF-Defined Chunk Parameter Extension ..................133
14.3. IETF-Defined Additional Error Causes ....................133
14.4. Payload Protocol Identifiers ............................134
14.5. Port Numbers Registry ...................................134
15. Suggested SCTP Protocol Parameter Values .....................136
16. Acknowledgements .............................................137
Appendix A. Explicit Congestion Notification .....................139
7.2. SCTP Slow-Start and Congestion Avoidance ..................95
7.2.1. Slow-Start .........................................96
7.2.2. Congestion Avoidance ...............................97
7.2.3. Congestion Control .................................98
7.2.4. Fast Retransmit on Gap Reports .....................98
7.3. Path MTU Discovery .......................................100
8. Fault Management ..............................................100
8.1. Endpoint Failure Detection ...............................100
8.2. Path Failure Detection ...................................101
8.3. Path Heartbeat ...........................................102
8.4. Handle "Out of the Blue" Packets .........................104
8.5. Verification Tag .........................................105
8.5.1. Exceptions in Verification Tag Rules ..............105
9. Termination of Association ....................................106
9.1. Abort of an Association ..................................107
9.2. Shutdown of an Association ...............................107
10. Interface with Upper Layer ...................................110
10.1. ULP-to-SCTP .............................................110
10.2. SCTP-to-ULP .............................................120
11. Security Considerations ......................................123
11.1. Security Objectives .....................................123
11.2. SCTP Responses to Potential Threats .....................124
11.2.1. Countering Insider Attacks .......................124
11.2.2. Protecting against Data Corruption in the
Network ..........................................124
11.2.3. Protecting Confidentiality .......................124
11.2.4. Protecting against Blind
Denial-of-Service Attacks ........................125
11.2.4.1. Flooding ................................125
11.2.4.2. Blind Masquerade ........................126
11.2.4.3. Improper Monopolization of Services .....127
11.3. SCTP Interactions with Firewalls ........................127
11.4. Protection of Non-SCTP-Capable Hosts ....................128
12. Network Management Considerations ............................128
13. Recommended Transmission Control Block (TCB) Parameters ......129
13.1. Parameters Necessary for the SCTP Instance ..............129
13.2. Parameters Necessary per Association (i.e., the TCB) ....129
13.3. Per Transport Address Data ..............................131
13.4. General Parameters Needed ...............................132
14. IANA Considerations ..........................................132
14.1. IETF-defined Chunk Extension ............................132
14.2. IETF-Defined Chunk Parameter Extension ..................133
14.3. IETF-Defined Additional Error Causes ....................133
14.4. Payload Protocol Identifiers ............................134
14.5. Port Numbers Registry ...................................134
15. Suggested SCTP Protocol Parameter Values .....................136
16. Acknowledgements .............................................137
Appendix A. Explicit Congestion Notification .....................139
Appendix B. CRC32c Checksum Calculation ..........................140
Appendix C. ICMP Handling ........................................142
References .......................................................149
Normative References ..........................................149
Informative References ........................................150
Appendix B. CRC32c Checksum Calculation ..........................140
Appendix C. ICMP Handling ........................................142
References .......................................................149
Normative References ..........................................149
Informative References ........................................150
This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol.
本节解释了流控制传输协议（SCTP）开发背后的原因、它提供的服务以及理解协议详细描述所需的基本概念。
This document obsoletes [RFC2960] and [RFC3309].
本文件废除了[RFC2960]和[RFC3309]。
TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following:
TCP[RFC0793]作为IP网络中可靠数据传输的主要手段，提供了巨大的服务。然而，最近越来越多的应用程序发现TCP限制太大，并且在UDP[RFC0768]之上加入了自己的可靠数据传输协议。用户希望绕过的限制包括：
-- TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay.
--TCP提供可靠的数据传输和严格的数据传输顺序。一些应用程序需要可靠的传输而无需维护序列，而另一些应用程序则需要满足数据的偏序。在这两种情况下，TCP提供的行首阻塞都会导致不必要的延迟。
-- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
--TCP面向流的特性常常带来不便。应用程序必须添加自己的记录标记来描述其消息，并且必须明确使用推送功能以确保在合理的时间内传输完整的消息。
-- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts.
--TCP套接字的有限范围使使用多宿主主机提供高可用数据传输能力的任务变得复杂。
-- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks.
--TCP相对容易受到拒绝服务攻击，如SYN攻击。
Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements.
通过IP网络传输PSTN信令是一个应用程序，TCP的所有这些限制都与此相关。虽然此应用程序直接推动了SCTP的开发，但其他应用程序可能会发现SCTP非常符合其需求。
SCTP is viewed as a layer between the SCTP user application ("SCTP user" for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers.
SCTP被视为SCTP用户应用程序（简称“SCTP用户”）和无连接分组网络服务（如IP）之间的一层。本文档的其余部分假设SCTP在IP上运行。SCTP提供的基本服务是对等SCTP用户之间用户消息的可靠传输。它在两个SCTP端点之间的关联上下文中执行此服务。本文档第10节概述了应存在于SCTP和SCTP用户层之间边界处的API。
SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint's lists.
SCTP本质上是面向连接的，但SCTP关联是比TCP连接更广泛的概念。SCTP为每个SCTP端点（第1.3节）提供了向另一个端点（在关联启动期间）提供传输地址列表的方法（即，多个IP地址与一个SCTP端口相结合），通过这些地址可以到达该端点并从中发起SCTP包。该关联跨越所有可能的源/目标组合的传输，这些组合可以从每个端点的列表生成。
_____________ _____________
| SCTP User | | SCTP User |
| Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|
_____________ _____________
| SCTP 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
SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association
图1:SCTP关联
Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions.
在前面的章节中介绍了一些用于描述SCTP的语言。本节提供了关键术语及其定义的综合列表。
o Active destination transport address: A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages.
o 活动目标传输地址：对等端点上的传输地址，传输端点认为该地址可用于接收用户消息。
o Bundling: An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk.
o 捆绑：一种可选的多路复用操作，在同一SCTP数据包中可以携带多条用户消息。每个用户消息都占用自己的数据块。
o Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.
o 区块：SCTP数据包中的信息单元，由区块头和区块特定内容组成。
o Congestion window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement.
o 拥塞窗口（cwnd）：一个SCTP变量，用于限制发送方在收到确认之前可以发送到特定目标传输地址的数据（字节数）。
o Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK.
o 累积TSN确认点：通过SACK的累积TSN确认字段确认的最后一个数据块的TSN。
o Idle destination address: An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater.
o 空闲目标地址：在一段时间内（通常为心跳间隔或更长时间）没有向其发送用户消息的地址。
o Inactive destination transport address: An address that is considered inactive due to errors and unavailable to transport user messages.
o 非活动目标传输地址：由于错误而被视为非活动且无法传输用户消息的地址。
o Message = user message: Data submitted to SCTP by the Upper Layer Protocol (ULP).
o 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 消息身份验证码（MAC）：一种基于使用密钥的加密哈希函数的完整性检查机制。通常，消息认证码在共享密钥的双方之间使用，以验证这些方之间传输的信息。在SCTP中，端点使用它来验证Cookie回显块中从对等方返回的状态Cookie信息。“MAC”一词在不同的上下文中有不同的含义。SCTP使用该术语的含义与[RFC2104]中的相同。
o Network Byte Order: Most significant byte first, a.k.a., big endian.
o 网络字节顺序：最高有效字节优先，也称为大端字节。
o Ordered Message: A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent.
o 有序消息：相对于在消息发送流中发送的所有先前用户消息，按顺序发送的用户消息。
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.
o 未完成的TSN（在SCTP端点处）：由端点发送但尚未收到确认的TSN（以及相关数据块）。
o Path: The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths.
o 路径：由一个SCTP端点发送到其对等SCTP端点的特定目标传输地址的SCTP数据包所采用的路由。发送到不同的目标传输地址并不一定保证获得单独的路径。
o Primary Path: The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed.
o 主路径：主路径是目标和源地址，默认情况下，该地址将放入到出站到对等端点的数据包中。该定义包括源地址，因为实现可能希望同时指定目的地和源地址，以便更好地控制应答块所采用的返回路径，以及当数据发送方是多宿时在哪个接口上传输分组。
o Receiver Window (rwnd): An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer.
o 接收方窗口（rwnd）：数据发送方用于存储其对等方最近计算的接收方窗口的SCTP变量，以字节为单位。这为发送方提供了接收方入站缓冲区中可用空间的指示。
o SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.
o SCTP关联：SCTP端点之间的协议关系，由两个SCTP端点和协议状态信息组成，包括验证标签和当前活动的传输序列号集（TSN）等。关联可以由关联中端点使用的传输地址唯一标识。在任何给定时间，两个SCTP端点之间不得有多个SCTP关联。
o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.
o SCTP端点：SCTP数据包的逻辑发送方/接收方。在多宿主主机上，SCTP端点向其对等方表示为一组合格的目标传输地址（SCTP数据包可发送到该地址）和一组合格的源传输地址（SCTP数据包可从中接收）的组合。SCTP端点使用的所有传输地址必须使用相同的端口号，但可以使用多个IP地址。SCTP端点使用的传输地址不能由另一个SCTP端点使用。换句话说，传输地址对于SCTP端点是唯一的。
o SCTP packet (or packet): The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks.
o SCTP数据包（或数据包）：通过SCTP和无连接数据包网络（如IP）之间的接口进行数据传输的单元。SCTP包包括公共SCTP头、可能的SCTP控制块和封装在SCTP数据块中的用户数据。
o SCTP user application (SCTP user): The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP).
o SCTP用户应用程序（SCTP用户）：使用SCTP服务的逻辑高层应用程序实体，也称为上层协议（ULP）。
o Slow-Start Threshold (ssthresh): An SCTP variable. This is the threshold that the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes.
o 慢启动阈值（ssthresh）：一个SCTP变量。这是端点将用于确定是否对特定目标传输地址执行慢启动或拥塞避免的阈值。Ssthresh以字节数表示。
o Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.
o 流：从一个关联的SCTP端点到另一个关联的SCTP端点建立的单向逻辑通道，在该通道中，除提交给无序传递服务的用户消息外，所有用户消息都按顺序传递。
Note: The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired.
注意：相反方向的流编号之间的关系严格取决于应用程序如何使用它们。如果需要，SCTP用户有责任创建和管理这些相关性。
o Stream Sequence Number: A 16-bit sequence number used internally by SCTP to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message.
o 流序列号：SCTP内部使用的16位序列号，用于确保在给定流中按顺序传递用户消息。每个用户消息附加一个流序列号。
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 绑定标记：两个32位随机数，一起构成64位nonce。这些标记在状态Cookie和TCB中使用，以便新重新启动的关联可以链接到端点中未重新启动但未显示现有关联的真实验证标记的原始关联。
o Transmission Control Block (TCB): An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association.
o 传输控制块（TCB）：由SCTP端点为其与其他SCTP端点的每个现有SCTP关联创建的内部数据结构。TCB包含端点的所有状态和操作信息，以维护和管理相应的关联。
o Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.
o 传输序列号（TSN）：SCTP内部使用的32位序列号。将一个TSN附加到包含用户数据的每个区块，以允许接收SCTP端点确认其接收并检测重复交付。
o Transport address: A transport address is traditionally defined by a network-layer address, a transport-layer protocol, and a transport-layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the transport protocol).
o 传输地址：传统上，传输地址由网络层地址、传输层协议和传输层端口号定义。在通过IP运行SCTP的情况下，传输地址由IP地址和SCTP端口号的组合定义（其中SCTP是传输协议）。
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received.
o 未确认的TSN（在SCTP端点处）：端点已接收但尚未发送确认的TSN（以及相关数据块）。或者在相反的情况下，对于已发送但未接收到确认的数据包。
o Unordered Message: Unordered messages are "unordered" with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream.
o 无序消息：无序消息相对于任何其他消息是“无序”的；这包括其他无序消息和其他有序消息。无序消息可能在同一流上发送的有序消息之前或之后发送。
o User message: The unit of data delivery across the interface between SCTP and its user.
o 用户消息：通过SCTP与其用户之间的接口传递数据的单位。
o Verification Tag: A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association.
o 验证标记：随机生成的32位无符号整数。验证标签提供了一个密钥，允许接收方验证SCTP数据包是否属于当前关联，并且不是来自前一关联的旧数据包或过时数据包。
MAC - Message Authentication Code [RFC2104]
MAC-消息认证码[RFC2104]
RTO - Retransmission Timeout
RTO-重传超时
RTT - Round-Trip Time
RTT-往返时间
RTTVAR - Round-Trip Time Variation
RTTVAR-往返时间变化
SCTP - Stream Control Transmission Protocol
流控制传输协议
SRTT - Smoothed RTT
SRTT-平滑RTT
TCB - Transmission Control Block
TCB-变速箱控制块
TLV - Type-Length-Value coding format
TLV-类型长度值编码格式
TSN - Transmission Sequence Number
TSN-传输序列号
ULP - Upper-Layer Protocol
上层协议
The SCTP transport service can be decomposed into a number of functions. These are depicted in Figure 2 and explained in the remainder of this section.
SCTP传输服务可以分解为许多功能。这些在图2中进行了描述，并在本节的其余部分进行了解释。
SCTP User Application
SCTP用户应用程序
-----------------------------------------------------
_____________ ____________________
| | | Sequenced Delivery |
| Association | | within Streams |
| | |____________________|
| Startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| Takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
-----------------------------------------------------
_____________ ____________________
| | | Sequenced Delivery |
| Association | | within Streams |
| | |____________________|
| Startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| Takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service
图2:SCTP传输服务的功能视图
An association is initiated by a request from the SCTP user (see the description of the ASSOCIATE (or SEND) primitive in Section 10).
关联由SCTP用户的请求发起（参见第10节中对关联（或发送）原语的描述）。
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.
在初始化过程中使用了一种cookie机制，类似于[RFC2522]中Karn和Simpson所述的机制，以防止同步攻击。cookie机制使用四次握手，最后两次握手允许携带用户数据以进行快速设置。本文件第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
SCTP可根据SCTP用户的请求优雅地关闭（即关闭）活动关联。请参阅第10节中有关关机原语的说明。SCTP还允许根据用户请求（中止）进行非正常关闭（即中止）
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层内检测到错误条件。第9节描述了优雅和不优雅的关闭程序。
SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close (see Section 9).
SCTP不支持半开放状态（如TCP），其中一方可以在另一端关闭时继续发送数据。当任一端点执行关闭时，每个对等点上的关联将停止接受来自其用户的新数据，并且仅在正常关闭时交付队列中的数据（参见第9节）。
The term "stream" is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document, a byte is assumed to be 8 bits).
术语“流”在SCTP中被用来指代将被传递到上层协议的用户消息序列，以相对于同一流中的其他消息的顺序。这与它在TCP中的用法相反，在TCP中它指的是一个字节序列（在本文档中，一个字节假定为8位）。
The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a Stream Sequence Number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed.
SCTP用户可以在关联启动时指定关联支持的流的数量。该号码与远端协商（见第5.1.1节）。用户消息与流编号关联（发送、接收原语，第10节）。在内部，SCTP为SCTP用户传递给它的每条消息分配一个流序列号。在接收端，SCTP确保消息在给定流中按顺序传递给SCTP用户。然而，当一个流可能被阻塞以等待下一个顺序用户消息时，来自其他流的传递可能继续。
SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received.
SCTP提供了一种绕过顺序传递服务的机制。使用此机制发送的用户消息在收到后立即传递给SCTP用户。
When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user.
当需要时，SCTP对用户消息进行分段，以确保传递到较低层的SCTP数据包符合路径MTU。在接收时，片段被重新组装成完整的消息，然后再传递给SCTP用户。
SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any Stream Sequence Number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery.
SCTP为每个用户数据片段或未分段消息分配一个传输序列号（TSN）。TSN独立于在流级别分配的任何流序列号。接收端确认接收到的所有TSN，即使序列中存在间隙。这样，可靠的交付在功能上与顺序流交付保持分离。
The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function.
确认和拥塞避免功能负责在未收到及时确认时重新传输数据包。数据包重传受拥塞避免过程的制约，类似于TCP使用的过程。有关与此功能相关的协议程序的详细说明，请参见第6节和第7节。
As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.
如第3节所述，发送到较低层的SCTP数据包由一个公共报头和一个或多个数据块组成。每个区块可能包含用户数据或SCTP控制信息。SCTP用户可以选择请求将多个用户消息捆绑到单个SCTP数据包中。SCTP的区块捆绑功能负责组装完整的SCTP数据包，并在接收端进行拆卸。
During times of congestion, an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission.
在拥塞期间，即使用户已请求SCTP不绑定，SCTP实现仍可能执行绑定。用户禁用绑定只会影响SCTP实现，SCTP实现可能会在传输前延迟一小段时间（以尝试鼓励绑定）。当用户层禁用绑定时，禁止此小延迟，但不禁止在拥塞或重传期间执行绑定。
A mandatory Verification Tag field and a 32-bit checksum field (see Appendix B for a description of the CRC32c checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The CRC32c checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet.
SCTP公共标头中包含一个强制验证标签字段和一个32位校验和字段（有关CRC32c校验和的说明，请参见附录B）。关联启动期间，关联的每一端都会选择验证标记值。接收到的没有预期验证标记值的数据包将被丢弃，以防止盲伪装攻击和来自先前关联的过时SCTP数据包。CRC32c校验和应由每个SCTP数据包的发送方设置，以提供额外的保护，防止网络中的数据损坏。具有无效CRC32c校验和的SCTP数据包的接收器会自动丢弃该数据包。
The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats
发送SCTP的用户能够通过第10节中描述的原语操作用作SCTP分组目的地的传输地址集。SCTP路径管理功能根据SCTP用户指令和合格目的地集的当前感知可达性状态为每个传出SCTP数据包选择目的地传输地址。路径管理功能通过心跳监控可达性
when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user.
当其他数据包流量不足以提供此信息时，并在任何远端传输地址的可达性发生变化时通知SCTP用户。路径管理功能还负责在关联启动期间向远端报告符合条件的本地传输地址集，并将从远端返回的传输地址报告给SCTP用户。
At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets.
在关联启动时，为每个SCTP端点定义一个主路径，并用于SCTP数据包的正常发送。
On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
在接收端，路径管理负责验证入站SCTP数据包所属的有效SCTP关联的存在，然后将其传递给进一步处理。
Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items.
注意：路径管理和数据包验证是同时完成的，因此尽管上面单独描述，但实际上它们不能作为单独的项目执行。
It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with Transmission Sequence Numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to TSNs, the symbol "=<" means "less than or equal"(modulo 2**32).
必须记住，实际的传输序列号空间是有限的，尽管非常大。此空格的范围为0到2**32-1。由于空间是有限的，所有处理传输序列号的算法都必须以模2**32执行。当序列号再次从2**32-1循环到0时，此无符号算术保留序列号之间的关系。计算机模运算有一些微妙之处，因此在编写比较这些值的程序时应特别小心。当提及TSN时，符号“=<”表示“小于或等于”（模2**32）。
Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
本文件中TSN上的比较和算法应使用[RFC1982]中定义的序列号算法，其中序列位=32。
An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs.
端点不应传输TSN高于其当前发送窗口起始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.
当达到2**32-1时，传输序列号会环绕。也就是说，数据块在传输TSN=2*32-1后必须使用的下一个TSN为TSN=0。
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic.
对流序列号进行的任何运算都应使用[RFC1982]中定义的序列号运算，其中序列位=16。本文档中的所有其他算法和比较均使用普通算法。
SCTP was originally defined in [RFC2960], which this document obsoletes. Readers interested in the details of the various changes that this document incorporates are asked to consult [RFC4460].
SCTP最初是在[RFC2960]中定义的，本文件将其废弃。对本文件包含的各种变更的详细信息感兴趣的读者请参考[RFC4460]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data.
SCTP数据包由公共头和数据块组成。块包含控件信息或用户数据。
The SCTP packet format is shown below:
SCTP数据包格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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大小的SCTP数据包中。这些块不能与数据包中的任何其他块捆绑在一起。有关区块绑定的更多详细信息，请参见第6.10节。
If a user data message doesn't fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.9.
如果用户数据消息不适合一个SCTP数据包，则可以使用第6.9节中定义的程序将其分割成多个数据块。
All integer fields in an SCTP packet MUST be transmitted in network byte order, unless otherwise stated.
除非另有说明，否则SCTP数据包中的所有整数字段必须以网络字节顺序传输。
SCTP Common Header Format
通用头格式
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port Number: 16 bits (unsigned integer)
源端口号：16位（无符号整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used.
这是SCTP发送方的端口号。它可由接收器与源IP地址、SCTP目的地端口以及可能的目的地IP地址结合使用，以识别该分组所属的关联。不得使用端口号0。
Destination Port Number: 16 bits (unsigned integer)
目标端口号：16位（无符号整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
这是该数据包的目的地SCTP端口号。接收主机将使用此端口号将SCTP数据包解复用到正确的接收端点/应用程序。不得使用端口号0。
Verification Tag: 32 bits (unsigned integer)
验证标记：32位（无符号整数）
The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions:
此数据包的接收方使用验证标签验证此SCTP数据包的发送方。在传输时，此验证标记的值必须设置为关联初始化期间从对等端点接收的Initiate标记的值，但以下情况除外：
- A packet containing an INIT chunk MUST have a zero Verification Tag.
- 包含INIT块的数据包必须具有零验证标记。
- A packet containing a SHUTDOWN COMPLETE chunk with the T bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN ACK chunk.
- 包含设置了T位的SHUTDOWN COMPLETE区块的数据包必须具有从具有SHUTDOWN ACK区块的数据包复制的验证标记。
- A packet containing an ABORT chunk may have the verification tag copied from the packet that caused the ABORT to be sent. For details see Section 8.4 and Section 8.5.
- 包含中止块的数据包可能具有从导致发送中止的数据包复制的验证标记。有关详细信息，请参见第8.4节和第8.5节。
An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
INIT块必须是SCTP数据包中承载它的唯一块。
Checksum: 32 bits (unsigned integer)
校验和：32位（无符号整数）
This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum.
此字段包含此SCTP数据包的校验和。第6.8节讨论了其计算。SCTP使用附录B中所述的CRC32c算法计算校验和。
The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field.
下图说明了要在SCTP数据包中传输的数据块的字段格式。每个区块都使用区块类型字段、区块特定标志字段、区块长度字段和值字段进行格式化。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer)
块类型：8位（无符号整数）
This field identifies the type of information contained in the Chunk Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field.
此字段标识区块值字段中包含的信息类型。它的值从0到254。值255保留为将来用作扩展字段。
The values of Chunk Types are defined as follows:
区块类型的值定义如下：
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK)
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK)
12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - available 63 - reserved for IETF-defined Chunk Extensions 64 to 126 - available 127 - reserved for IETF-defined Chunk Extensions 128 to 190 - available 191 - reserved for IETF-defined Chunk Extensions 192 to 254 - available 255 - reserved for IETF-defined Chunk Extensions
12-保留用于显式拥塞通知回显（ECNE）13-保留用于减少拥塞窗口（CWR）14-关闭完成（关闭完成）15至62-可用63-保留给IETF定义的区块扩展64至126-可用127-保留给IETF定义的区块扩展128至190-可用191-保留给IETF定义的区块扩展192至254-可用255-保留给IETF定义的区块扩展
Chunk Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type.
对块类型进行编码，以便最高顺序的2位指定处理端点无法识别块类型时必须采取的操作。
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01-停止处理此SCTP数据包并丢弃它，不处理其中的任何其他数据块，并在“unrecognized chunk Type”中报告未识别的数据块。
10 - Skip this chunk and continue processing.
10-跳过此块并继续处理。
11 - Skip this chunk and continue processing, but report in an ERROR chunk using the 'Unrecognized Chunk Type' cause of error.
11-跳过此区块并继续处理，但使用“无法识别的区块类型”错误原因报告错误区块。
Note: The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN); see Appendix A.
注意：ECNE和CWR区块类型保留供将来使用显式拥塞通知（ECN）；见附录A。
Chunk Flags: 8 bits
块标志：8位
The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt.
这些位的使用取决于Chunk type字段给出的Chunk类型。除非另有规定，否则它们在传输时被设置为0，在接收时被忽略。
Chunk Length: 16 bits (unsigned integer)
块长度：16位（无符号整数）
This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding.
此值表示块的大小（以字节为单位），包括块类型、块标志、块长度和块值字段。因此，如果区块值字段的长度为零，则长度字段将设置为4。“块长度”字段不计算任何块填充。
Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding.
数据块（包括类型、长度和值字段）由发送方填充，所有零字节都是4字节长的倍数。此填充总共不得超过3个字节。区块长度值不包括区块的终止填充。但是，它确实包括任何可变长度参数的填充，块中最后一个参数除外。接收器必须忽略填充。
Note: A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length.
注意：一个健壮的实现应该接受区块，无论区块长度中是否包含最终填充。
Chunk Value: variable length
区块值：可变长度
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
区块值字段包含要在区块中传输的实际信息。此字段的用法和格式取决于区块类型。
The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
块的总长度（包括类型、长度和值字段）必须是4字节的倍数。如果区块的长度不是4字节的倍数，则发送方必须用所有零字节填充区块，并且该填充不包括在区块长度字段中。发送方的填充不能超过3个字节。接收器必须忽略填充字节。
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.
第3.3节详细描述了SCTP定义的块。IETF定义的区块扩展指南见本文件第14.1节。
Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below.
SCTP控制块的块值由一个特定于块类型的必填字段头组成，后跟零个或多个参数。区块中包含的可选和可变长度参数以类型长度值格式定义，如下所示。
0 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Parameter Type: 16 bits (unsigned integer)
区块参数类型：16位（无符号整数）
The Type field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534.
类型字段是参数类型的16位标识符。它的值为0到65534。
The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk descriptions are reserved for use by IETF.
65535的值保留给IETF定义的扩展。除特定SCTP区块描述中定义的值外，其他值保留供IETF使用。
Chunk Parameter Length: 16 bits (unsigned integer)
区块参数长度：16位（无符号整数）
The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes.
参数长度字段包含以字节为单位的参数大小，包括参数类型、参数长度和参数值字段。因此，具有零长度参数值字段的参数的长度字段为4。参数长度不包括任何填充字节。
Chunk Parameter Value: variable length
区块参数值：可变长度
The Parameter Value field contains the actual information to be transferred in the parameter.
参数值字段包含要在参数中传输的实际信息。
The total length of a parameter (including Type, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the Parameter Length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
参数的总长度（包括类型、参数长度和值字段）必须是4字节的倍数。如果参数的长度不是4字节的倍数，则发送方在参数末尾（即参数值字段之后）填充所有零字节。填充的长度不包括在参数长度字段中。发送方的填充长度不得超过3个字节。接收器必须忽略填充字节。
The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type.
对参数类型进行编码，以便最高阶2位指定处理端点无法识别参数类型时必须采取的操作。
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00-停止处理该参数；不要在此块中处理任何其他参数。
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2.
01-停止处理此参数，不处理此区块内的任何其他参数，并在“未识别参数”中报告未识别参数，如第3.2.2节所述。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2.
11-跳过此参数并继续处理，但在“未识别的参数”中报告未识别的参数，如第3.2.2节所述。
Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk is sent. In the 00 or 01 case, the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
请注意，在所有四种情况下，都会发送INIT ACK或COOKIE ECHO块。在00或01的情况下，取消未知参数后的参数处理，但不回滚已完成的处理。
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 14.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2.1). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk.
实际的SCTP参数在特定的SCTP区块部分中定义。IETF定义的参数扩展规则见第14.2节。请注意，参数类型在所有块中都必须是唯一的。例如，参数类型“5”用于表示IPv4地址（请参阅第3.3.2.1节）。然后，值“5”在所有区块中保留以表示IPv4地址，并且不得在任何其他区块中以不同的含义重复使用。
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in response to the INIT chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
如果INIT块的接收方检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，则必须将“无法识别的参数”参数放入响应INIT块而发送的INIT ACK块中。请注意，如果INIT块的接收方不打算建立关联（例如，由于缺乏资源），则发送给INIT发送方的任何中止都不会包含“无法识别的参数”。
If the receiver of an INIT ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE ACK has been received.
如果INIT ACK块的接收者检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，那么它应该将包含“无法识别的参数”错误原因的错误块与响应INIT ACK块而发送的COOKIE ECHO块捆绑在一起。如果INIT ACK的接收器无法将COOKIE ECHO块与错误块捆绑在一起，则可以单独发送错误块，但不能在收到COOKIE ACK之前发送。
Note: Any time a COOKIE ECHO is sent in a packet, it MUST be the first chunk.
注意：任何时候在数据包中发送COOKIE回显时，它必须是第一个数据块。
This section defines the format of the different SCTP chunk types.
本节定义了不同SCTP块类型的格式。
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) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits
保留：5位
Should be set to all '0's and ignored by the receiver.
应设置为所有“0”，并被接收器忽略。
U bit: 1 bit
U位：1位
The (U)nordered bit, if set to '1', indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field.
如果设置为“1”，则（U）nordered位表示这是一个无序数据块，并且没有为该数据块分配流序列号。因此，接收器必须忽略流序列号字段。
After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder.
重新组装（如有必要）后，接收器必须将无序数据块发送到上层，而无需重新排序。
If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to '1'.
如果无序的用户消息是分段的，则消息的每个分段都必须将其U位设置为“1”。
B bit: 1 bit
B位：1位
The (B)eginning fragment bit, if set, indicates the first fragment of a user message.
（B）eginning fragment位（如果设置）表示用户消息的第一个片段。
E bit: 1 bit
E位：1位
The (E)nding fragment bit, if set, indicates the last fragment of a user message.
（E）nding fragment位（如果设置）表示用户消息的最后一个片段。
An unfragmented user message shall have both the B and E bits set to '1'. Setting both B and E bits to '0' indicates a middle fragment of a multi-fragment user message, as summarized in the following table:
未分段的用户消息应将B和E位设置为“1”。将B和E位都设置为“0”表示多片段用户消息的中间片段，如下表所示：
B E Description
============================================================
| 1 0 | First piece of a fragmented user message |
+----------------------------------------------------------+
| 0 0 | Middle piece of a fragmented user message |
+----------------------------------------------------------+
| 0 1 | Last piece of a fragmented user message |
+----------------------------------------------------------+
| 1 1 | Unfragmented message |
============================================================
| Table 1: Fragment Description Flags |
============================================================
B E Description
============================================================
| 1 0 | First piece of a fragmented user message |
+----------------------------------------------------------+
| 0 0 | Middle piece of a fragmented user message |
+----------------------------------------------------------+
| 0 1 | Last piece of a fragmented user message |
+----------------------------------------------------------+
| 1 1 | Unfragmented message |
============================================================
| Table 1: Fragment Description Flags |
============================================================
When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential.
当用户消息被分割成多个块时，接收方使用TSN重新组装消息。这意味着分段用户消息的每个片段的TSN必须严格按顺序排列。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes).
此字段表示从类型字段开始到用户数据字段结束的数据块长度（字节），不包括任何填充。具有一个字节用户数据的数据块的长度将设置为17（表示17个字节）。
A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0.
具有长度为L的用户数据字段的数据块的长度字段将设置为（16+L）（表示16+L字节），其中L必须大于0。
TSN: 32 bits (unsigned integer)
TSN:32位（无符号整数）
This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295.
此值表示此数据块的TSN。TSN的有效范围为0到4294967295（2**32-1）。TSN在达到4294967295后返回到0。
Stream Identifier S: 16 bits (unsigned integer)
流标识符S:16位（无符号整数）
Identifies the stream to which the following user data belongs.
标识以下用户数据所属的流。
Stream Sequence Number n: 16 bits (unsigned integer)
流序列号n:16位（无符号整数）
This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535.
此值表示流S中以下用户数据的流序列号。有效范围为0到65535。
When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message.
当用户消息被SCTP分段传输时，必须在消息的每个片段中携带相同的流序列号。
Payload Protocol Identifier: 32 bits (unsigned integer)
有效负载协议标识符：32位（无符号整数）
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field.
此值表示应用程序（或上层）指定的协议标识符。该值由其上层传递给SCTP，并发送给其对等方。SCTP不使用此标识符，但某些网络实体以及对等应用程序可以使用此标识符来标识此数据块中承载的信息类型。这个字段必须在零散的数据块中发送（以确保它对于网络中间的代理是可用的）。请注意，SCTP实现不涉及此字段；因此，它的字节顺序不一定是大端。上层负责到该字段的任何字节顺序转换。
The value 0 indicates that no application identifier is specified by the upper layer for this payload data.
值0表示上层没有为此有效负载数据指定应用程序标识符。
User Data: variable length
用户数据：可变长度
This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding.
这是有效负载用户数据。实现必须用所有零字节将数据结尾填充到4字节边界。长度字段中不得包含任何填充。发件人添加的填充内容不得超过3字节。
This chunk is used to initiate an SCTP association between two endpoints. The format of the INIT chunk is shown below:
此区块用于启动两个端点之间的SCTP关联。INIT块的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk.
INIT块包含以下参数。除非另有说明，否则每个参数在INIT块中只能包含一次。
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
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
Variable Parameters Status Type Value
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5 IPv6 Address
(Note 1) Optional 6 Cookie Preservative
Optional 9 Reserved for ECN Capable (Note 2) Optional
32768 (0x8000) Host Name Address (Note 3) Optional
11 Supported Address Types (Note 4) Optional 12
Note 1: The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination.
注意1：INIT块可以包含多个地址，这些地址可以是IPv4和/或IPv6的任意组合。
Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification.
注2：支持ECN的字段保留供将来使用显式拥塞通知。
Note 3: An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk.
注意3：INIT块不能包含多个主机名地址参数。此外，INIT的发送方不得将任何其他地址类型与INIT中的主机名地址组合。如果主机名地址参数存在于接收的INIT块中，则INIT的接收方必须忽略任何其他地址类型。
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
注4：此参数（如果存在）指定发送端点可以支持的所有地址类型。缺少此参数表示发送端点可以支持任何地址类型。
IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk, then the receiver SHOULD process the INIT chunk and send back an INIT ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
实现说明：如果接收到的INIT块中包含的已知参数不是INIT块的可选参数，那么接收方应该处理INIT块并发回INIT ACK。INIT块的接收者稍后可能会将错误块与COOKIE ACK块捆绑在一起。但是，限制性实现可能会发回一个ABORT块来响应INIT块。
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 Flags字段是保留的，发送方应将其中的所有位设置为0，接收方应忽略。INIT中的参数序列可以按任何顺序处理。
Initiate Tag: 32 bits (unsigned integer)
初始化标记：32位（无符号整数）
The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association.
INIT（响应端）的接收器记录Initiate标记参数的值。必须将该值放入INIT接收器在此关联内发送的每个SCTP数据包的验证标签字段中。
The Initiate Tag is allowed to have any value except 0. See Section 5.3.1 for more on the selection of the tag value.
Initiate标记允许有除0以外的任何值。有关标签值选择的更多信息，请参见第5.3.1节。
If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT.
如果在接收的INIT块中发现Initiate标记的值为0，则接收方必须将其视为错误，并通过发送中止来关闭关联。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
播发接收器窗口信用（a\U rwnd）：32位（无符号整数）
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks.
此值表示INIT发送方与此窗口关联保留的专用缓冲区空间（字节数）。在关联的生命周期内，该缓冲区空间不应减少（即，从该关联中移除专用缓冲区）；但是，端点可能会更改它在SACK块中发送的\u rwnd的值。
Number of Outbound Streams (OS): 16 bits (unsigned integer)
出站流（OS）数：16位（无符号整数）
Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 MUST NOT be used.
定义此初始化块的发送方希望在此关联中创建的出站流数。不得使用0的值。
Note: A receiver of an INIT with the OS value set to 0 SHOULD abort the association.
注意：OS值设置为0的INIT接收器应中止关联。
Number of Inbound Streams (MIS): 16 bits (unsigned integer)
入站流数（MIS）：16位（无符号整数）
Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value 0 MUST NOT be used.
定义此初始化块的发送方允许对等端在此关联中创建的最大流数。不得使用值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.
注意：没有协商流的实际数量，但两个端点将使用最小值（请求、提供）。详见第5.1.1节。
Note: A receiver of an INIT with the MIS value of 0 SHOULD abort the association.
注意：MIS值为0的INIT接收器应中止关联。
Initial TSN (I-TSN): 32 bits (unsigned integer)
初始TSN（I-TSN）：32位（无符号整数）
Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field.
定义发送方将使用的初始TSN。有效范围为0到4294967295。该字段可以设置为Initiate Tag字段的值。
The following parameters follow the Type-Length-Value format as defined in Section 3.2.1. Any Type-Length-Value fields MUST come after the fixed-length fields defined in the previous section.
以下参数遵循第3.2.1节中定义的类型长度值格式。任何类型长度值字段必须位于上一节中定义的固定长度字段之后。
IPv4 Address Parameter (5)
IPv4地址参数（5）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer)
IPv4地址：32位（无符号整数）
Contains an IPv4 address of the sending endpoint. It is binary encoded.
包含发送终结点的IPv4地址。它是二进制编码的。
IPv6 Address Parameter (6)
IPv6地址参数（6）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bits (unsigned integer)
IPv6地址：128位（无符号整数）
Contains an IPv6 [RFC2460] address of the sending endpoint. It is binary encoded.
包含发送端点的IPv6[RFC2460]地址。它是二进制编码的。
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but should instead use an IPv4 Address parameter for an IPv4 address.
注意：发送方不得使用IPv4映射的IPv6地址[RFC4291]，而应为IPv4地址使用IPv4地址参数。
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the life time of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT.
结合SCTP公共标头中的源端口号，在IPv4或IPv6地址参数中传递的值表示INIT的发送方将支持正在启动的关联的传输地址。也就是说，在该关联的生存期内，该IP地址可以出现在从INIT的发送方发送的IP数据报的源地址字段中，并且可以用作从INIT的接收方发送的IP数据报的目的地地址。
More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-homed. Moreover, a multi-homed endpoint may have access to different types of network; thus, more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk.
当INIT发送方是多宿主时，INIT块中可以包含多个IP地址参数。此外，多宿端点可以访问不同类型的网络；因此，一个INIT块中可以存在多个地址类型，即在同一INIT块中允许IPv4和IPv6地址。
If the INIT contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT chunk and any additional address(es) provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT MUST use the source address associated with the received IP datagram as its sole destination address for the association.
如果INIT包含至少一个IP地址参数，则包含INIT块的IP数据报的源地址和INIT中提供的任何附加地址都可以被接收INIT的端点用作目的地。如果INIT不包含任何IP地址参数，则接收INIT的端点必须使用与接收到的IP数据报关联的源地址作为关联的唯一目标地址。
Note that not using any IP Address parameters in the INIT and INIT ACK is an alternative to make an association more likely to work across a NAT box.
请注意，在INIT和INIT ACK中不使用任何IP地址参数是使关联更有可能跨NAT盒工作的替代方法。
Cookie Preservative (9)
饼干防腐剂（9）
The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie.
INIT的发送方应使用此参数向INIT的接收方建议更长的状态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.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-Span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-Span Increment: 32 bits (unsigned integer)
建议的Cookie寿命增量：32位（无符号整数）
This parameter indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span.
此参数向接收方指示发送方希望接收方在其默认cookie寿命中增加多少增量（以毫秒为单位）。
This optional parameter should be added to the INIT chunk by the sender when it reattempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons.
当发送方重新尝试与对等方建立关联时，应将此可选参数添加到INIT块中。由于陈旧的cookie操作错误，先前尝试建立关联的对等方失败。出于自身的安全原因，接收方可以选择忽略建议的cookie寿命增加。
Host Name Address (11)
主机名地址（11）
The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box.
INIT的发送方使用此参数将其主机名（代替其IP地址）传递给对等方。对等方负责解析名称。使用此参数可能会使关联更有可能跨NAT框工作。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Host Name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name: variable length
主机名：可变长度
This field contains a host name in "host name syntax" per RFC 1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP.
根据RFC 1123第2.1节[RFC1123]，此字段包含“主机名语法”中的主机名。解析主机名的方法超出了SCTP的范围。
Note: At least one null terminator is included in the Host Name string and must be included in the length.
注意：主机名字符串中至少包含一个空终止符，并且必须包含在长度中。
Supported Address Types (12)
支持的地址类型（12）
The sender of INIT uses this parameter to list all the address types it can support.
INIT的发送方使用此参数列出它可以支持的所有地址类型。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type #1 | Address Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Address Type: 16 bits (unsigned integer)
地址类型：16位（无符号整数）
This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
该字段由相应地址TLV的类型值填充（例如，IPv4=5、IPv6=6、主机名=11）。
The INIT ACK chunk is used to acknowledge the initiation of an SCTP association.
INIT ACK块用于确认SCTP关联的启动。
The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The State Cookie and the Unrecognized Parameter:
INIT ACK的参数部分的格式类似于INIT块。它使用两个额外的变量参数：状态Cookie和无法识别的参数：
The format of the INIT ACK chunk is shown below:
INIT ACK块的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag: 32 bits (unsigned integer)
初始化标记：32位（无符号整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACK的接收器记录Initiate标记参数的值。必须将该值放入INIT ACK接收器在此关联内发送的每个SCTP数据包的验证标签字段中。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
Initiate标记不能采用值0。有关初始标签值选择的更多信息，请参见第5.3.1节。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose.
如果在接收到的INIT ACK块中发现Initiate标记的值为0，则接收方必须销毁关联，丢弃其TCB。接收机可能会出于调试目的发送中止。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
播发接收器窗口信用（a\U rwnd）：32位（无符号整数）
This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association).
此值表示INIT ACK的发送方与此窗口关联保留的专用缓冲区空间（字节数）。在关联的生命周期内，不应减少该缓冲区空间（即，从该关联中移除专用缓冲区）。
Number of Outbound Streams (OS): 16 bits (unsigned integer)
出站流（OS）数：16位（无符号整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST
定义此INIT ACK块的发送方希望在此关联中创建的出站流数。必须指定0的值
NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk.
不能使用，并且该值不得大于INIT块中发送的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接收器应销毁关联，丢弃其TCB。
Number of Inbound Streams (MIS): 16 bits (unsigned integer)
入站流数（MIS）：16位（无符号整数）
Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used.
定义此初始确认块的发送方允许对等端在此关联中创建的最大流数。不得使用值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.
注意：没有协商流的实际数量，但两个端点将使用最小值（请求、提供）。详见第5.1.1节。
Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB.
注意：MIS值设置为0的INIT ACK接收器应销毁关联，丢弃其TCB。
Initial TSN (I-TSN): 32 bits (unsigned integer)
初始TSN（I-TSN）：32位（无符号整数）
Defines the initial TSN that the INIT ACK sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field.
定义初始确认发送方将使用的初始TSN。有效范围为0到4294967295。该字段可以设置为Initiate Tag字段的值。
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Fixed Parameters Status
----------------------------------------------
Initiate Tag Mandatory
Advertised Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Note 1: The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination.
注意1：INIT ACK块可以包含任意数量的IP地址参数，这些参数可以是IPv4和/或IPv6的任意组合。
Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification.
注2：支持ECN的字段保留供将来使用显式拥塞通知。
Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present.
注意3：INIT ACK块不能包含多个主机名地址参数。此外，INIT ACK的发送方不得将任何其他地址类型与INIT ACK中的主机名地址组合。如果主机名地址参数存在，则INIT ACK的接收方必须忽略任何其他地址类型。
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive an INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the State Cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
实现说明：由于状态Cookie和可变地址列表的大小可变，实现必须准备好接收相当大（超过1500字节）的INIT ACK。例如，如果INIT的响应程序希望发送1000个IPv4地址，则至少需要8000字节才能在INIT ACK中对其进行编码。
IMPLEMENTATION NOTE: If an INIT ACK chunk is received with known parameters that are not optional parameters of the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the COOKIE ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT ACK chunk.
实现说明：如果接收到的INIT ACK块的已知参数不是INIT ACK块的可选参数，那么接收方应该处理INIT ACK块并发送回COOKIE回显。INIT ACK块的接收方可以将错误块与COOKIE ECHO块捆绑在一起。但是，限制性实现可能会发回一个ABORT块以响应INIT ACK块。
In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the life time of the association being initiated.
结合SCTP公共报头中携带的源端口，INIT ACK中的每个IP地址参数向INIT ACK的接收方指示INIT ACK的发送方在所启动关联的生命周期内支持的有效传输地址。
If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association.
如果INIT ACK包含至少一个IP地址参数，则包含INIT ACK的IP数据报的源地址和INIT ACK内提供的任何附加地址可被INIT ACK的接收器用作目的地。如果INIT ACK不包含任何IP地址参数，则INIT ACK的接收器必须使用与接收到的IP数据报关联的源地址作为其关联的唯一目标地址。
The State Cookie and Unrecognized Parameters use the Type-Length-Value format as defined in Section 3.2.1 and are described below. The other fields are defined the same as their counterparts in the INIT chunk.
状态Cookie和无法识别的参数使用第3.2.1节中定义的类型长度值格式，如下所述。其他字段的定义与INIT块中的对应字段相同。
State Cookie
状态Cookie
Parameter Type Value: 7
参数类型值：7
Parameter Length: Variable size, depending on size of Cookie.
参数长度：可变大小，取决于Cookie的大小。
Parameter Value:
参数值：
This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition.
此参数值必须包含此初始确认的发送方创建关联所需的所有必要状态和参数信息，以及消息身份验证码（MAC）。有关状态Cookie定义的详细信息，请参见第5.1.3节。
Unrecognized Parameter:
无法识别的参数：
Parameter Type Value: 8
参数类型值：8
Parameter Length: Variable size.
参数长度：可变大小。
Parameter Value:
参数值：
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
当INIT包含一个无法识别的参数，该参数的值指示应该向发送方报告时，该参数将返回给INIT块的发起方。此参数值字段将包含从INIT块复制的无法识别的参数，包括参数类型、长度和值字段。
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs.
该数据块被发送到对等端点，以确认接收到的数据块，并通知对等端点由其TSN表示的数据块的接收子序列中的间隙。
The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields.
SACK必须包含累积TSN Ack、公布的接收器窗口信用（a_rwnd）、间隙Ack块的数量和重复TSN字段的数量。
By definition, the value of the Cumulative TSN Ack parameter is the last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value.
根据定义，累积TSN Ack参数的值是在接收到的TSN序列中发生中断之前接收到的最后一个TSN；发送SACK的端点尚未接收到此值之后的下一个TSN值。因此，此参数确认收到小于或等于其值的所有TSN。
The handling of a_rwnd by the receiver of the SACK is discussed in detail in Section 6.2.1.
第6.2.1节详细讨论了SACK接收器对rwnd的处理。
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
SACK还包含零个或多个Gap Ack块。每个间隙Ack块确认在接收到的tsn序列中的中断之后接收到的tsn的子序列。根据定义，Gap Ack块确认的所有TSN都大于累积TSN Ack的值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #1 Start | Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap Ack Block #N Start | Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to all '0's on transmit and ignored on receipt.
传输时设置为所有“0”，接收时忽略。
Cumulative TSN Ack: 32 bits (unsigned integer)
累积TSN确认：32位（无符号整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one.
此参数包含间隔之前按顺序接收的最后一个数据块的TSN。在没有接收到数据块的情况下，该值设置为对等方的初始TSN减去1。
Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer)
播发接收器窗口信用（a\U rwnd）：32位（无符号整数）
This field indicates the updated receive buffer space in bytes of the sender of this SACK; see Section 6.2.1 for details.
此字段表示此SACK发送方的更新接收缓冲区空间（字节）；详见第6.2.1节。
Number of Gap Ack Blocks: 16 bits (unsigned integer)
间隙确认块数：16位（无符号整数）
Indicates the number of Gap Ack Blocks included in this SACK.
指示此SACK中包含的Gap Ack块数。
Number of Duplicate TSNs: 16 bit
重复TSN的数量：16位
This field contains the number of duplicate TSNs the endpoint has received. Each duplicate TSN is listed following the Gap Ack Block list.
此字段包含端点已接收的重复TSN数。每个重复的TSN都列在Gap Ack块列表之后。
Gap Ack Blocks:
间隙确认块：
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly.
这些字段包含间隙确认块。对于每个间隙Ack块重复这些操作，直到间隙Ack块数字段中定义的间隙Ack块数为止。假定每个间隙Ack块的TSN大于或等于（累积TSN Ack+间隙Ack块开始）且小于或等于（累积TSN Ack+间隙Ack块结束）的所有数据块已正确接收。
Gap Ack Block Start: 16 bits (unsigned integer)
间隙确认块开始：16位（无符号整数）
Indicates the Start offset TSN for this Gap Ack Block. To calculate the actual TSN number the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the first TSN in this Gap Ack Block that has been received.
指示此间隙确认块的起始偏移TSN。要计算实际TSN编号，将累积TSN Ack添加到此偏移编号。此计算出的TSN标识此Gap Ack块中已接收的第一个TSN。
Gap Ack Block End: 16 bits (unsigned integer)
间隙确认块结束：16位（无符号整数）
Indicates the End offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block.
指示此间隙确认块的结束偏移TSN。要计算实际TSN编号，将累积TSN Ack添加到此偏移编号。此计算出的TSN标识此Gap Ack块中接收的最后一个数据块的TSN。
For example, assume that the receiver has the following DATA chunks newly arrived at the time when it decides to send a Selective ACK,
例如，假设接收器在决定发送选择性ACK时新到达以下数据块，
----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------
----------
| TSN=17 |
----------
| | <- still missing
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- still missing
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------
then the parameter part of the SACK MUST be constructed as follows (assuming the new a_rwnd is set to 4660 by the sender):
然后，SACK的参数部分必须按如下方式构造（假设发送方将新的a_rwnd设置为4660）：
+--------------------------------+
| Cumulative TSN Ack = 12 |
+--------------------------------+
| a_rwnd = 4660 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+
+--------------------------------+
| Cumulative TSN Ack = 12 |
+--------------------------------+
| a_rwnd = 4660 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+
Duplicate TSN: 32 bits (unsigned integer)
重复TSN:32位（无符号整数）
Indicates the number of times a TSN was received in duplicate since the last SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK), it adds it to the list of duplicates. The duplicate count is reinitialized to zero after sending each SACK.
表示自上次发送SACK以来，重复接收TSN的次数。每次接收方获得一个重复的TSN（在发送SACK之前），它都会将其添加到重复列表中。发送每个SACK后，重复计数重新初始化为零。
For example, if a receiver were to get the TSN 19 three times it would list 19 twice in the outbound SACK. After sending the SACK, if it received yet one more TSN 19 it would list 19 as a duplicate once in the next outgoing SACK.
例如，如果一个接收者三次获得TSN 19，它将在出站SACK中列出19两次。发送SACK后，如果它再收到一个TSN 19，它将在下一个传出SACK中将19列为一个副本。
An endpoint should send this chunk to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association.
端点应将此区块发送到其对等端点，以探测当前关联中定义的特定目标传输地址的可达性。
The parameter field contains the Heartbeat Information, which is a variable-length opaque data structure understood only by the sender.
参数字段包含心跳信息，这是一种只有发送方才能理解的可变长度不透明数据结构。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
Heartbeat Length: 16 bits (unsigned integer)
心跳长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field.
设置为块的大小（以字节为单位），包括块头和心跳信息字段。
Heartbeat Information: variable length
心跳信息：可变长度
Defined as a variable-length parameter using the format described in Section 3.2.1, i.e.:
定义为使用第3.2.1节所述格式的可变长度参数，即：
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-Specific Heartbeat Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sender-Specific Heartbeat Info field should normally include information about the sender's current time when this HEARTBEAT
特定于发送方的心跳信息字段通常应包含有关发送方发出此心跳的当前时间的信息
chunk is sent and the destination transport address to which this HEARTBEAT is sent (see Section 8.3). This information is simply reflected back by the receiver in the HEARTBEAT ACK message (see Section 3.3.6). Note also that the HEARTBEAT message is both for reachability checking and for path verification (see Section 5.4). When a HEARTBEAT chunk is being used for path verification purposes, it MUST hold a 64-bit random nonce.
发送数据块和发送此心跳信号的目标传输地址（参见第8.3节）。该信息仅由接收器在心跳确认消息中反射回来（见第3.3.6节）。还要注意，心跳消息用于可达性检查和路径验证（参见第5.4节）。当心跳块用于路径验证时，它必须包含64位随机nonce。
An endpoint should send this chunk to its peer endpoint as a response to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the HEARTBEAT chunk to which this ack is responding.
端点应将此区块作为对心跳区块的响应发送到其对等端点（请参阅第8.3节）。心跳ACK始终发送到包含此ACK响应的心跳区块的IP数据报的源IP地址。
The parameter field contains a variable-length opaque data structure.
参数字段包含可变长度的不透明数据结构。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
Heartbeat Ack Length: 16 bits (unsigned integer)
心跳信号确认长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field.
设置为块的大小（以字节为单位），包括块头和心跳信息字段。
Heartbeat Information: variable length
心跳信息：可变长度
This field MUST contain the Heartbeat Information parameter of the Heartbeat Request to which this Heartbeat Acknowledgement is responding.
此字段必须包含此心跳确认响应的心跳请求的心跳信息参数。
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver about the reason of the abort. DATA chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be placed before the ABORT in the SCTP packet or they will be ignored by the receiver.
中止区块被发送到关联的对等方以关闭关联。中止区块可能包含原因参数，用于通知接收方中止的原因。数据块不能与中止绑定在一起。控制块（INIT、INIT ACK和SHUTDOWN COMPLETE除外）可以与中止捆绑在一起，但它们必须放在SCTP数据包中中止之前，否则接收器将忽略它们。
If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own.
如果端点接收到带格式错误的中止或未找到TCB，则必须以静默方式放弃它。此外，在任何情况下，接收中止的端点都不能通过发送自己的中止来响应该中止。
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 |Reserved |T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Reserved: 7 bits
保留：7位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
T bit: 1 bit
T位：1位
The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
如果发送方填写了对等方期望的验证标记，则T位设置为0。如果验证标签被反射，则T位必须设置为1。反射意味着发送的验证标签与接收的验证标签相同。
Note: Special rules apply to this chunk for verification; please see Section 8.5.1 for details.
注：特殊规则适用于此区块进行验证；详情请参见第8.5.1节。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
设置块的大小（以字节为单位），包括块头和所有存在的错误原因字段。
See Section 3.3.10 for Error Cause definitions.
错误原因定义见第3.3.10节。
An endpoint in an association MUST use this chunk to initiate a graceful close of the association with its peer. This chunk has the following format.
关联中的端点必须使用此区块来启动与其对等方的关联的优雅关闭。此块具有以下格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Chunk Flags | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Chunk Flags | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Indicates the length of the parameter. Set to 8.
指示参数的长度。设置为8。
Cumulative TSN Ack: 32 bits (unsigned integer)
累积TSN确认：32位（无符号整数）
This parameter contains the TSN of the last chunk received in sequence before any gaps.
此参数包含在任何间隙之前按顺序接收的最后一个区块的TSN。
Note: Since the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be used to acknowledge TSNs received out of order. In a SACK, lack of Gap Ack Blocks that were previously included indicates that the data receiver reneged on the associated DATA chunks. Since SHUTDOWN does not contain Gap Ack Blocks, the receiver of the SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege. (See Section 6.2 for information on reneging.)
注意：由于关机消息不包含Gap Ack块，因此不能用于确认接收到的TSN出现故障。在SACK中，缺少先前包含的Gap Ack块表示数据接收器在相关数据块上进行了叛逆。由于关机不包含Gap Ack块，关机接收器不应将缺少Gap Ack块解释为违约。（有关违约的信息，请参见第6.2节。）
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process; see Section 9.2 for details.
此区块必须用于在关闭过程完成时确认收到关闭区块；详见第9.2节。
The SHUTDOWN ACK chunk has no parameters.
SHUTDOWN ACK区块没有参数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions. It contains one or more error causes. An Operation Error is not considered fatal in and of itself, but may be used with an ABORT chunk to report a fatal condition. It has the following parameters:
端点将此区块发送到其对等端点，以通知其某些错误情况。它包含一个或多个错误原因。操作错误本身不被认为是致命的，但可以与中止块一起使用以报告致命情况。它具有以下参数：
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ one or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
设置块的大小（以字节为单位），包括块头和所有存在的错误原因字段。
Error causes are defined as variable-length parameters using the format described in Section 3.2.1, that is:
错误原因定义为使用第3.2.1节所述格式的可变长度参数，即：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-Specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-Specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code: 16 bits (unsigned integer)
原因代码：16位（无符号整数）
Defines the type of error conditions being reported.
定义要报告的错误条件的类型。
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields.
设置为参数的大小（字节），包括原因代码、原因长度和原因特定信息字段。
Cause-Specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 14.3.
第3.3.10.1节-第3.3.10.13节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第14.3节。
Cause of error
---------------
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream Identifier: 16 bits (unsigned integer)
流标识符：16位（无符号整数）
Contains the Stream Identifier of the DATA chunk received in error.
包含错误接收的数据块的流标识符。
Reserved: 16 bits
保留：16位
This field is reserved. It is set to all 0's on transmit and ignored on receipt.
此字段是保留的。它在传输时被设置为所有0，在接收时被忽略。
Cause of error
---------------
Cause of error
---------------
Missing Mandatory Parameter: Indicates that one or more mandatory TLV parameters are missing in a received INIT or 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Missing params: 32 bits (unsigned integer)
缺少的参数数：32位（无符号整数）
This field contains the number of parameters contained in the Cause-Specific Information field.
此字段包含原因特定信息字段中包含的参数数。
Missing Param Type: 16 bits (unsigned integer)
缺少参数类型：16位（无符号整数）
Each field will contain the missing mandatory parameter number.
每个字段将包含缺少的强制参数编号。
Cause of error
--------------
Cause of error
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie that has expired.
陈旧Cookie错误：表示收到已过期的有效状态Cookie。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness: 32 bits (unsigned integer)
过时度量：32位（无符号整数）
This field contains the difference, in microseconds, between the current time and the time the State Cookie expired.
此字段包含当前时间与状态Cookie过期时间之间的差异（以微秒为单位）。
The sender of this error cause MAY choose to report how long past expiration the State Cookie is by including a non-zero value in the Measure of Staleness field. If the sender does not wish to provide this information, it should set the Measure of Staleness field to the value of zero.
此错误原因的发送方可以通过在“过期度量”字段中包含非零值来报告状态Cookie过期的时间。如果发送方不希望提供此信息，则应将“过时度量”字段的值设置为零。
Cause of error
---------------
Cause of error
---------------
Out of Resource: Indicates that the sender is out of resource. This is usually sent in combination with or within an ABORT.
资源不足：表示发件人资源不足。这通常与中止一起发送或在中止内发送。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unresolvable Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unresolvable Address: variable length
不可解析地址：可变长度
The Unresolvable Address field contains the complete Type, Length, and Value of the address parameter (or Host Name parameter) that contains the unresolvable address or host name.
不可解析地址字段包含包含不可解析地址或主机名的地址参数（或主机名参数）的完整类型、长度和值。
Cause of error
---------------
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.
无法识别的区块类型：如果接收者不理解区块，并且“区块类型”的高位设置为01或11，则此错误原因将返回给区块的发起人。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk: variable length
无法识别的区块：可变长度
The Unrecognized Chunk field contains the unrecognized chunk from the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk Length.
Unrecognized Chunk字段包含来自SCTP数据包的未识别区块，该数据包包含区块类型、区块标志和区块长度。
Cause of error
---------------
Cause of error
---------------
Invalid Mandatory Parameter: This error cause is returned to the originator of an INIT or INIT ACK chunk when one of the mandatory parameters is set to an invalid value.
无效的强制参数：当其中一个强制参数设置为无效值时，此错误原因将返回给INIT或INIT ACK块的发起人。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the originator of the INIT ACK chunk if the receiver does not recognize one or more Optional TLV parameters in the INIT ACK chunk.
无法识别的参数：如果接收方无法识别INIT ACK块中的一个或多个可选TLV参数，则会将此错误原因返回给INIT ACK块的发起方。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Parameters: variable length
无法识别的参数：可变长度
The Unrecognized Parameters field contains the unrecognized parameters copied from the INIT ACK chunk complete with TLV. This error cause is normally contained in an ERROR chunk bundled with the COOKIE ECHO chunk when responding to the INIT ACK, when the sender of the COOKIE ECHO chunk wishes to report unrecognized parameters.
Unrecognized Parameters（未识别参数）字段包含从包含TLV的初始确认块复制的未识别参数。此错误原因通常包含在响应INIT ACK时与COOKIE ECHO块绑定的错误块中，此时COOKIE ECHO块的发送方希望报告无法识别的参数。
Cause of error
---------------
Cause of error
---------------
No User Data: This error cause is returned to the originator of a
无用户数据：此错误原因返回给
DATA chunk if a received DATA chunk has no user data.
如果接收到的数据块没有用户数据，则为数据块。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSN value: 32 bits (unsigned integer)
TSN值：32位（无符号整数）
The TSN value field contains the TSN of the DATA chunk received with no user data field.
TSN值字段包含在没有用户数据字段的情况下接收的数据块的TSN。
This cause code is normally returned in an ABORT chunk (see Section 6.2).
该原因代码通常以中止块的形式返回（参见第6.2节）。
Cause of error
---------------
Cause of error
---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received while the endpoint was in the SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK.
关闭时收到Cookie：端点处于SHUTDOWN-ACK-SENT状态时收到Cookie回音。此错误通常在与重新传输的关机确认捆绑在一起的错误块中返回。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
--------------
Cause of error
--------------
Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The new addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see Section 5.2).
重新启动具有新地址的关联：在现有关联上接收到初始化。但是INIT向该关联添加了以前不属于该关联的地址。新地址列在错误代码中。此错误通常作为拒绝初始化的中止的一部分发送（参见第5.2节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter Length.
注意：每个新地址TLV都是在新的INIT块中找到的TLV的精确副本，包括参数类型和参数长度。
Cause of error
--------------
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper-layer protocol at the peer.
此错误原因可能包含在由于上层请求而发送的中止块中。上层可以指定上层中止原因，该原因由SCTP透明地传输，并且可以在对等端传递给上层协议。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
--------------
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in Section 3.3.10.1 to Section 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected.
此错误原因可能包含在发送的中止块中，因为SCTP端点检测到对等方的协议违反，而第3.3.10.1节至第3.3.10.12节中描述的错误原因未涵盖该协议违反。实现可以提供额外的信息，指定检测到哪种协议违反。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks in the same packet.
此区块仅在关联初始化期间使用。它由关联的发起方发送到其对等方以完成初始化过程。此数据块必须位于关联中发送的任何数据块之前，但可以与同一数据包中的一个或多个数据块捆绑在一起。
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |Chunk Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cookie /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bit
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the size of the cookie.
设置块的大小（以字节为单位），包括块头的4个字节和cookie的大小。
Cookie: variable size
Cookie：可变大小
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
此字段必须包含在State cookie参数中从上一个INIT ACK接收到的确切cookie。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
实现应该使cookie尽可能小，以确保互操作性。
Note: A Cookie Echo does NOT contain a State Cookie parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first 2 bytes of the State Cookie parameter to become a COOKIE ECHO chunk.
注意：Cookie回显不包含状态Cookie参数；相反，状态Cookie的参数值中的数据将成为Cookie Echo的块值中的数据。这允许实现仅将状态Cookie参数的前2个字节更改为Cookie回显块。
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks or SACK chunk's in the same SCTP packet.
此区块仅在关联初始化期间使用。它用于确认收到COOKIE回显块。此区块必须位于关联内发送的任何数据或SACK区块之前，但可以与同一SCTP数据包中的一个或多个数据区块或SACK区块捆绑在一起。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process; see Section 9.2 for details.
此区块必须用于在关机过程完成时确认收到关机确认区块；详见第9.2节。
The SHUTDOWN COMPLETE chunk has no parameters.
SHUTDOWN COMPLETE区块没有参数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
块标志：8位
Reserved: 7 bits
保留：7位
Set to 0 on transmit and ignored on receipt.
发送时设置为0，接收时忽略。
T bit: 1 bit
T位：1位
The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
如果发送方填写了对等方期望的验证标记，则T位设置为0。如果验证标签被反射，则T位必须设置为1。反射意味着发送的验证标签与接收的验证标签相同。
Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details.
注：特殊规则适用于此区块进行验证，详情请参见第8.5.1节。
During the life time of an SCTP association, the SCTP endpoint's association progresses from one state to another in response to various events. The events that may potentially advance an association's state include:
在SCTP关联的生命周期内，SCTP端点的关联根据各种事件从一种状态发展到另一种状态。可能提升关联状态的事件包括：
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o SCTP用户原语调用，例如，[ASSOCIATE]、[SHUTDOWN]、[ABORT]，
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control chunks, or
o 接收初始化、COOKIE回显、中止、关闭等、控制块，或
o Some timeout events.
o 一些超时事件。
The state diagram in the figures below illustrates state changes, together with the causing events and resulting actions. Note that some of the error conditions are not shown in the state diagram. Full descriptions of all special cases are found in the text.
下图中的状态图说明了状态更改，以及导致事件和结果操作的原因。请注意，状态图中未显示某些错误条件。所有特殊情况的完整描述见正文。
Note: Chunk names are given in all capital letters, while parameter names have the first letter capitalized, e.g., COOKIE ECHO chunk type vs. State Cookie parameter. If more than one event/message can occur that causes a state transition, it is labeled (A), (B), etc.
注意：区块名称以所有大写字母给出，而参数名称的首字母大写，例如COOKIE ECHO区块类型与状态COOKIE参数。如果可能发生多个事件/消息导致状态转换，则将其标记为（a）、（B）等。
----- -------- (from any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
----- -------- (from any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN
|PENDING | |------------------
+---------+ | check outstanding
| | DATA chunks
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
| | (D)rcv SHUTDOWN ACK
| |--------------
| | stop shutdown timer
| | send SHUTDOWN COMPLETE
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+
| | (D)rcv SHUTDOWN ACK
| |--------------
| | stop shutdown timer
| | send SHUTDOWN COMPLETE
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+
Figure 3: State Transition Diagram of SCTP
图3:SCTP的状态转换图
Notes:
笔记：
1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state.
1) 如果接收到的Cookie回显中的状态Cookie无效（即未能通过完整性检查），则接收方必须悄悄地丢弃该数据包。或者，如果接收到的状态Cookie已过期（请参阅第5.1.5节），则接收方必须发回错误区块。在任何一种情况下，接收器都保持在关闭状态。
2) If the T1-init timer expires, the endpoint MUST retransmit INIT and restart the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user.
2) 如果T1 init计时器过期，端点必须重新传输init并在不更改状态的情况下重新启动T1 init计时器。这必须重复到“Max.Init.retransmit”次。在此之后，端点必须中止初始化过程并向SCTP用户报告错误。
3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and restart the T1-cookie timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user.
3) 如果T1 cookie计时器过期，端点必须重新传输cookie ECHO，并在不更改状态的情况下重新启动T1 cookie计时器。这必须重复到“Max.Init.retransmit”次。在此之后，端点必须中止初始化过程并向SCTP用户报告错误。
4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any received DATA chunks without delay.
4) 在SHUTDOWN-SENT状态下，端点必须毫不延迟地确认任何接收到的数据块。
5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send requests from its SCTP user.
5) 在SHUTDOWN-RECEIVED状态下，端点不得接受来自其SCTP用户的任何新发送请求。
6) In the SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit data and leave this state when all data in queue is transmitted.
6) 在SHUTDOWN-RECEIVED状态下，端点必须传输或重新传输数据，并在传输队列中的所有数据时离开此状态。
7) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send requests from its SCTP user.
7) 在SHUTDOWN-ACK-SENT状态下，端点不得接受来自其SCTP用户的任何新发送请求。
The CLOSED state is used to indicate that an association is not created (i.e., doesn't exist).
关闭状态用于指示未创建关联（即不存在）。
Before the first data transmission can take place from one SCTP endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must complete an initialization process in order to set up an SCTP association between them.
在从一个SCTP端点（“A”）到另一个SCTP端点（“Z”）进行第一次数据传输之前，两个端点必须完成初始化过程，以便在它们之间建立SCTP关联。
The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint.
端点处的SCTP用户应使用ASSOCIATE原语初始化与另一个SCTP端点的SCTP关联。
IMPLEMENTATION NOTE: From an SCTP user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see Section 10.1 B) being invoked, by the initiating endpoint's sending of the first user data to the destination endpoint. The initiating SCTP will assume default values for all mandatory and optional parameters for the INIT/INIT ACK.
实施说明：从SCTP用户的角度来看，通过发起端点向目标端点发送第一个用户数据，可以隐式打开关联，而不调用关联原语（参见第10.1 B节）。初始化SCTP将假定INIT/INIT ACK的所有强制和可选参数的默认值。
Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1).
一旦建立了关联，单向流将在两端开放以进行数据传输（见第5.1.1节）。
The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association):
初始化过程包括以下步骤（假设SCTP端点“A”尝试设置与SCTP端点“Z”的关联，并且“Z”接受新关联）：
A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see Section 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state.
A） “A”首先向“Z”发送一个INIT块。在INIT中，“A”必须在Initiate Tag字段中提供其验证标记（Tag_A）。标签A应为1至4294967295范围内的随机数（标签值选择见第5.3.1节）。发送INIT后，“A”启动T1 INIT计时器并进入COOKIE-WAIT状态。
B) "Z" shall respond immediately with an INIT ACK chunk. The destination IP address of the INIT ACK MUST be set to the source IP address of the INIT to which this INIT ACK is responding. In the response, besides filling in other parameters, "Z" must set the Verification Tag field to Tag_A, and also provide its own Verification Tag (Tag_Z) in the Initiate Tag field.
B） “Z”应立即响应初始确认块。INIT ACK的目标IP地址必须设置为该INIT ACK响应的INIT的源IP地址。在响应中，除了填写其他参数外，“Z”必须将验证标签字段设置为Tag_A，并在Initiate Tag字段中提供自己的验证标签（Tag_Z）。
Moreover, "Z" MUST generate and send along with the INIT ACK a State Cookie. See Section 5.1.3 for State Cookie generation.
此外，“Z”必须生成并与INIT ACK一起发送状态Cookie。有关状态Cookie的生成，请参见第5.1.3节。
Note: After sending out INIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources or keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks.
注意：在发送带有State Cookie参数的INIT ACK之后，“Z”不能为新关联分配任何资源或保留任何状态。否则，“Z”将容易受到资源攻击。
C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1- init timer and leave the COOKIE-WAIT state. "A" shall then send the State Cookie received in the INIT ACK chunk in a COOKIE ECHO chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED state.
C） 在接收到来自“Z”的初始确认后，“A”应停止T1-INIT定时器并离开COOKIE-WAIT状态。然后，“A”应在Cookie回显块中发送INIT ACK块中接收到的状态Cookie，启动T1 Cookie计时器，并进入Cookie回显状态。
Note: The COOKIE ECHO chunk can be bundled with any pending outbound DATA chunks, but it MUST be the first chunk in the packet and until the COOKIE ACK is returned the sender MUST NOT send any other packets to the peer.
注意：COOKIE ECHO块可以与任何挂起的出站数据块捆绑在一起，但它必须是数据包中的第一个块，并且在返回COOKIE ACK之前，发送方不得向对等方发送任何其他数据包。
D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply with a COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED state. A COOKIE ACK chunk may be bundled with any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk MUST be the first chunk in the packet.
D） 在接收到COOKIE ECHO区块后，端点“Z”将在构建TCB并移动到已建立状态后使用COOKIE ACK区块进行回复。COOKIE ACK区块可以与任何挂起的数据区块（和/或SACK区块）捆绑，但COOKIE ACK区块必须是数据包中的第一个区块。
IMPLEMENTATION NOTE: An implementation may choose to send the Communication Up notification to the SCTP user upon reception of a valid COOKIE ECHO chunk.
实现说明：实现可以选择在接收到有效的COOKIE回显块时向SCTP用户发送通信启动通知。
E) Upon reception of the COOKIE ACK, endpoint "A" will move from the COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1- cookie timer. It may also notify its ULP about the successful establishment of the association with a Communication Up notification (see Section 10).
E） 接收到COOKIE ACK后，端点“A”将从COOKIE-echood状态移动到已建立状态，停止T1-COOKIE计时器。它还可以通过通信通知通知其ULP成功建立关联（见第10节）。
An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. They MUST be the only chunks present in the SCTP packets that carry them.
INIT或INIT ACK块不能与任何其他块绑定。它们必须是SCTP数据包中唯一携带它们的块。
An endpoint MUST send the INIT ACK to the IP address from which it received the INIT.
端点必须将INIT ACK发送到接收INIT的IP地址。
Note: T1-init timer and T1-cookie timer shall follow the same rules given in Section 6.3.
注：T1初始计时器和T1 cookie计时器应遵循第6.3节中给出的相同规则。
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer.
如果端点接收到INIT、INIT ACK或COOKIE ECHO块，但由于接收到的INIT或INIT ACK中缺少必需参数、参数值无效或缺少本地资源而决定不建立新关联，则它应使用中止块进行响应。它还应该通过将错误原因参数包含在中止块中来指定中止的原因，例如缺少的强制参数的类型等。包含中止块的出站SCTP数据包的公共头中的验证标记字段必须设置为对等方的Initiate标记值。
Note that a COOKIE ECHO chunk that does NOT pass the integrity check is NOT considered an 'invalid parameter' and requires special handling; see Section 5.1.5.
请注意，未通过完整性检查的COOKIE回显块不被视为“无效参数”，需要特殊处理；见第5.1.5节。
After the reception of the first DATA chunk in an association the endpoint MUST immediately respond with a SACK to acknowledge the DATA chunk. Subsequent acknowledgements should be done as described in Section 6.2.
在接收到关联中的第一个数据块后，端点必须立即响应SACK以确认该数据块。后续确认应按照第6.2节所述进行。
When the TCB is created, each endpoint MUST set its internal Cumulative TSN Ack Point to the value of its transmitted Initial TSN minus one.
创建TCB时，每个端点必须将其内部累积TSN Ack Point设置为其传输的初始TSN减去1的值。
IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally used as the key to find the TCB within an SCTP instance.
实现说明：IP地址和SCTP端口通常用作在SCTP实例中查找TCB的密钥。
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OSs) it wishes to have in the association, as well as the maximum inbound streams (MISs) it will accept from the other endpoint.
在INIT和INIT ACK块中，块的发送方必须指明它希望在关联中拥有的出站流（OSs）的数量，以及它将从另一个端点接受的最大入站流（MISs）。
After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
在接收到来自另一方的流配置信息后，每个端点必须执行以下检查：如果对等方的MIS小于端点的OS，这意味着对等方无法支持端点想要配置的所有出站流，端点必须使用MIS出站流，并且可以向上层报告任何不足。如果资源短缺是不可接受的，上层可以选择中止关联。
After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1.
初始化关联后，任一端点的有效出站流标识符范围应为0到min（本地操作系统、远程MIS）-1。
During the association initialization, an endpoint shall use the following rules to discover and collect the destination transport address(es) of its peer.
在关联初始化期间，端点应使用以下规则来发现和收集其对等方的目标传输地址。
A) If there are no address parameters present in the received INIT or INIT ACK chunk, the endpoint shall take the source IP address from which the chunk arrives and record it, in combination with the SCTP source port number, as the only destination transport address for this peer.
A） 如果接收到的INIT或INIT ACK区块中没有地址参数，则端点应将区块到达的源IP地址与SCTP源端口号一起记录为该对等方的唯一目标传输地址。
B) If there is a Host Name parameter present in the received INIT or INIT ACK chunk, the endpoint shall resolve that host name to a list of IP address(es) and derive the transport address(es) of this peer by combining the resolved IP address(es) with the SCTP source port.
B） 如果接收到的INIT或INIT ACK块中存在主机名参数，则端点应将该主机名解析为IP地址列表，并通过将解析的IP地址与SCTP源端口相结合来派生该对等方的传输地址。
The endpoint MUST ignore any other IP Address parameters if they are also present in the received INIT or INIT ACK chunk.
如果接收到的INIT或INIT ACK块中也存在任何其他IP地址参数，则端点必须忽略这些参数。
The time at which the receiver of an INIT resolves the host name has potential security implications to SCTP. If the receiver of an INIT resolves the host name upon the reception of the chunk, and the mechanism the receiver uses to resolve the host name involves potential long delay (e.g., DNS query), the receiver may open itself up to resource attacks for the period of time while it is waiting for the name resolution results before it can build the State Cookie and release local resources.
INIT的接收方解析主机名的时间对SCTP有潜在的安全影响。如果INIT的接收方在接收区块时解析主机名，并且接收方用于解析主机名的机制涉及潜在的长延迟（例如，DNS查询），接收方可能会在等待名称解析结果的一段时间内暴露于资源攻击，然后才能构建状态Cookie并释放本地资源。
Therefore, in cases where the name translation involves potential long delay, the receiver of the INIT MUST postpone the name resolution till the reception of the COOKIE ECHO chunk from the peer. In such a case, the receiver of the INIT SHOULD build the State Cookie using the received Host Name (instead of destination transport addresses) and send the INIT ACK to the source IP address from which the INIT was received.
因此，在名称转换涉及潜在长延迟的情况下，INIT的接收方必须将名称解析延迟到从对等方接收COOKIE ECHO块。在这种情况下，INIT的接收方应该使用接收到的主机名（而不是目标传输地址）构建状态Cookie，并将INIT ACK发送到接收INIT的源IP地址。
The receiver of an INIT ACK shall always immediately attempt to resolve the name upon the reception of the chunk.
INIT ACK的接收者应始终在收到数据块后立即尝试解析名称。
The receiver of the INIT or INIT ACK MUST NOT send user data (piggy-backed or stand-alone) to its peer until the host name is successfully resolved.
在成功解析主机名之前，INIT或INIT ACK的接收方不得向其对等方发送用户数据（背载或独立）。
If the name resolution is not successful, the endpoint MUST immediately send an ABORT with "Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from which the last peer packet was received.
如果名称解析不成功，端点必须立即向其对等方发送带有“无法解析的地址”错误原因的中止。中止应发送至接收最后一个对等数据包的源IP地址。
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver MUST derive and record all the transport addresses from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport addresses are derived by the combination of SCTP source port (from the common header) and the IP Address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C） 如果接收的INIT或INIT ACK区块中仅存在IPv4/IPv6地址，则接收方必须从接收的区块和发送INIT或INIT ACK的源IP地址派生并记录所有传输地址。传输地址由SCTP源端口（来自公共报头）和INIT或INIT ACK块中携带的IP地址参数以及IP数据报的源IP地址组合而成。当向其对等方发送后续数据包时，接收方应仅使用这些传输地址作为目标传输地址。
D) An INIT or INIT ACK chunk MUST be treated as belonging to an already established association (or one in the process of being established) if the use of any of the valid address parameters contained within the chunk would identify an existing TCB.
D） 如果使用块中包含的任何有效地址参数将标识现有TCB，则必须将INIT或INIT ACK块视为属于已建立的关联（或正在建立的关联）。
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation doesn't control the source IP address that is used for transmitting), an endpoint might need to include in its INIT or INIT ACK all possible IP addresses from which packets to the peer could be transmitted.
实现说明：在某些情况下（例如，当实现不控制用于传输的源IP地址时），端点可能需要在其INIT或INIT ACK中包含所有可能的IP地址，从这些地址可以将数据包传输到对等方。
After all transport addresses are derived from the INIT or INIT ACK chunk using the above rules, the endpoint shall select one of the transport addresses as the initial primary path.
使用上述规则从INIT或INIT ACK块派生出所有传输地址后，端点应选择其中一个传输地址作为初始主路径。
Note: The INIT ACK MUST be sent to the source address of the INIT.
注意：INIT ACK必须发送到INIT的源地址。
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiate) MUST either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer.
INIT的发送方可以在INIT中包含“受支持的地址类型”参数，以指示哪些类型的地址是可接受的。当此参数存在时，INIT（initiate）的接收方在响应INIT时必须使用Supported address types参数中指示的地址类型之一，或者如果不愿意或无法使用其对等方指示的任何地址类型，则中止与“Unsolvable address”错误原因的关联。
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a reinitiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新初始化，以指示其首选的地址类型。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
实施说明：如果仅支持IPv4或IPv6的SCTP端点从其对等方接收到INIT或INIT ACK块中的IPv4和IPv6地址，则它必须使用属于支持的地址系列的所有地址。其他地址可能会被忽略。端点不应响应任何类型的错误指示。
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.
实施说明：如果SCTP端点在“受支持的地址类型”参数中列出IPv4或IPv6，但使用另一个系列发送包含INIT区块的数据包，或者如果它还列出INIT区块中另一个系列的地址，然后，“Supported address Types”（受支持的地址类型）参数中未列出的地址族也应被视为受INIT块的接收方支持。INIT块的接收方不应响应任何类型的错误指示。
When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a timestamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association.
当发送INIT ACK作为对INIT块的响应时，INIT ACK的发送方创建一个状态Cookie，并在INIT ACK的State Cookie参数中发送它。在该状态Cookie中，发送方应包括一个MAC（例如，请参见[RFC2104]）、创建状态Cookie的时间戳、状态Cookie的寿命，以及建立关联所需的所有信息。
The following steps SHOULD be taken to generate the State Cookie:
应采取以下步骤来生成状态Cookie：
1) Create an association TCB using information from both the received INIT and the outgoing INIT ACK chunk,
1) 使用来自接收的INIT和传出的INIT ACK块的信息创建关联TCB，
2) In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life' (see Section 15),
2) 在TCB中，将创建时间设置为当前时间，将寿命设置为协议参数'Valid.Cookie.Life'（参见第15节），
3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC), and
3) 从TCB识别并收集重新创建TCB所需的最小信息子集，并使用该信息子集和密钥生成MAC（参见[RFC2104]以获取生成MAC的示例），以及
4) Generate the State Cookie by combining this subset of information and the resultant MAC.
4) 通过组合此信息子集和生成的MAC生成状态Cookie。
After sending the INIT ACK with the State Cookie parameter, the sender SHOULD delete the TCB and any other local resource related to the new association, so as to prevent resource attacks.
发送带有State Cookie参数的INIT ACK后，发送方应删除TCB和与新关联相关的任何其他本地资源，以防止资源攻击。
The hashing method used to generate the MAC is strictly a private matter for the receiver of the INIT chunk. The use of a MAC is mandatory to prevent denial-of-service attacks. The secret key SHOULD be random ([RFC4086] provides some information on randomness guidelines); it SHOULD be changed reasonably frequently, and the timestamp in the State Cookie MAY be used to determine which key should be used to verify the MAC.
用于生成MAC的哈希方法对于INIT块的接收者来说严格来说是私有的。为防止拒绝服务攻击，必须使用MAC。密钥应该是随机的（[RFC4086]提供了一些关于随机性准则的信息）；应该合理频繁地更改它，并且可以使用状态Cookie中的时间戳来确定应该使用哪个密钥来验证MAC。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
实现应该使cookie尽可能小，以确保互操作性。
When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK chunk with a State Cookie parameter, it MUST immediately send a COOKIE ECHO chunk to its peer with the received State Cookie. The sender MAY also add any pending DATA chunks to the packet after the COOKIE ECHO chunk.
当端点（处于COOKIE-WAIT状态）接收到带有状态COOKIE参数的INIT ACK块时，它必须立即将COOKIE ECHO块发送到具有接收到的状态COOKIE的对等方。发送方还可以将任何挂起的数据块添加到COOKIE ECHO块之后的数据包中。
The endpoint shall also start the T1-cookie timer after sending out the COOKIE ECHO chunk. If the timer expires, the endpoint shall retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated until either a COOKIE ACK is received or 'Max.Init.Retransmits' (see Section 15) is reached causing the peer endpoint to be marked unreachable (and thus the association enters the CLOSED state).
端点还应在发送cookie回显块后启动T1 cookie计时器。如果计时器过期，端点应重新传输COOKIE回显块并重新启动T1 COOKIE计时器。重复此操作，直到收到COOKIE ACK或到达“Max.Init.Retransmits”（参见第15节），导致对等端点被标记为不可访问（因此关联进入关闭状态）。
When an endpoint receives a COOKIE ECHO chunk from another endpoint with which it has no association, it shall take the following actions:
当一个端点从与它没有关联的另一个端点接收COOKIE回显块时，它应采取以下操作：
1) Compute a MAC using the TCB data carried in the State Cookie and the secret key (note the timestamp in the State Cookie MAY be used to determine which secret key to use). [RFC2104] can be used as a guideline for generating the MAC,
1) 使用状态Cookie中携带的TCB数据和密钥计算MAC（注意，状态Cookie中的时间戳可用于确定使用哪个密钥）。[RFC2104]可用作生成MAC的指南，
2) Authenticate the State Cookie as one that it previously generated by comparing the computed MAC against the one carried in the State Cookie. If this comparison fails, the SCTP packet, including the COOKIE ECHO and any DATA chunks, should be silently discarded,
2) 通过将计算出的MAC与状态Cookie中携带的MAC进行比较，将状态Cookie验证为它先前生成的状态Cookie。如果此比较失败，则SCTP数据包（包括COOKIE回显和任何数据块）应被静默丢弃，
3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded.
3) 将COOKIE ECHO区块中包含的端口号和验证标记与接收数据包的SCTP公共头中的实际端口号和验证标记进行比较。如果这些值不匹配，则必须以静默方式丢弃数据包。
4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.
4) 将状态Cookie中的创建时间戳与当前本地时间进行比较。如果经过的时间长于状态Cookie中携带的寿命，则应丢弃该数据包，包括Cookie回显和任何附加的数据块，并且端点必须向对等端点传输带有“陈旧Cookie”错误原因的错误块。
5) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO and enter the ESTABLISHED state.
5) 如果状态Cookie有效，则使用Cookie ECHO中携带的TCB数据中的信息创建与Cookie ECHO块发送方的关联，并进入已建立状态。
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
6) 向对等方发送COOKIE ACK区块，确认收到COOKIE回音。COOKIE ACK可以与出站数据块或SACK块捆绑；但是，COOKIE ACK必须是SCTP数据包中的第一个块。
7) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step 6, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
7) 立即用SACK确认与COOKIE ECHO捆绑的任何数据块（后续数据块确认应遵循第6.2节中定义的规则）。如步骤6所述，如果SACK与COOKIE ACK捆绑在一起，则COOKIE ACK必须首先出现在SCTP数据包中。
If a COOKIE ECHO is received from an endpoint with which the receiver of the COOKIE ECHO has an existing association, the procedures in Section 5.2 should be followed.
如果从COOKIE回显接收器与之存在关联的端点接收到COOKIE回显，则应遵循第5.2节中的步骤。
In the following example, "A" initiates the association and then sends a user message to "Z", then "Z" sends two user messages to "A" later (assuming no bundling or fragmentation occurs):
在以下示例中，“A”启动关联，然后向“Z”发送一条用户消息，然后“Z”稍后向“A”发送两条用户消息（假设未发生捆绑或碎片）：
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITIATION Example
图4：初始化示例
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and the timer restarted. This shall be repeated Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure to its upper layer (and thus the association enters the CLOSED state).
如果在发送init或COOKIE ECHO块后，T1 init计时器在“A”过期，则应重新传输具有相同启动标记（即标记_A）或状态COOKIE的相同init或COOKIE ECHO块，并重新启动计时器。在“A”认为“Z”不可到达并向其上层报告故障之前（因此关联进入关闭状态），这应重复Max.Init.remits次。
When retransmitting the INIT, the endpoint MUST follow the rules defined in Section 6.3 to determine the proper timer value.
当重新传输INIT时，端点必须遵循第6.3节中定义的规则，以确定正确的计时器值。
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK
5.2. 处理重复或意外的INIT、INIT ACK、COOKIE ECHO和COOKIE ACK
During the life time of an association (in one of the possible states), an endpoint may receive from its peer endpoint one of the setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it as described in this section.
在关联的生命周期内（在一种可能的状态下），端点可以从其对等端点接收一个设置块（INIT、INIT ACK、COOKIE ECHO和COOKIE ACK）。接收器应将此类设置块视为副本，并按照本节所述进行处理。
Note: An endpoint will not receive the chunk unless the chunk was sent to an SCTP transport address and is from an SCTP transport address associated with this endpoint. Therefore, the endpoint processes such a chunk as part of its current association.
注意：除非区块被发送到SCTP传输地址并且来自与此端点关联的SCTP传输地址，否则端点将不会接收区块。因此，端点将此类块作为其当前关联的一部分进行处理。
The following scenarios can cause duplicated or unexpected chunks:
以下情况可能会导致重复或意外的数据块：
A) The peer has crashed without being detected, restarted itself, and sent out a new INIT chunk trying to restore the association,
A） 对等机在未被检测到的情况下崩溃，自身重新启动，并发送了一个新的INIT chunk试图恢复关联，
B) Both sides are trying to initialize the association at about the same time,
B） 双方几乎同时尝试初始化关联，
C) The chunk is from a stale packet that was used to establish the present association or a past association that is no longer in existence,
C） 该区块来自用于建立当前关联或不再存在的过去关联的过时数据包，
D) The chunk is a false packet generated by an attacker, or
D） 该区块是由攻击者生成的假数据包，或
E) The peer never received the COOKIE ACK and is retransmitting its COOKIE ECHO.
E） 对等方从未收到COOKIE ACK，正在重新传输其COOKIE回显。
The rules in the following sections shall be applied in order to identify and correctly handle these cases.
为了识别和正确处理这些情况，应采用以下章节中的规则。
This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint.
这通常表示初始化冲突，即每个端点几乎同时试图与另一个端点建立关联。
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the endpoint MUST send the INIT ACK back to the same address that the original INIT (sent by this endpoint) was sent.
当接收到处于COOKIE-WAIT状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其Initiate标记，未更改）响应INIT ACK。响应时，端点必须将INIT ACK发送回发送原始INIT（由该端点发送）的相同地址。
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
在接收到处于COOKIE-echood状态的INIT时，端点必须使用在其原始INIT块中发送的相同参数（包括其Initiate标记，未更改）响应INIT ACK，前提是未将新地址添加到正在形成的关联中。如果INIT消息指示已将新地址添加到关联中，则必须放弃整个INIT，并且不应对现有关联进行任何更改。应发送中止响应，该响应可能包括错误“重新启动与新地址的关联”。错误应列出添加到重新启动关联的地址。
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK, the original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
当以INIT ACK的任一状态（COOKIE-WAIT或COOKIE-echood）响应时，原始参数与新接收到的INIT块中的参数组合在一起。端点还应使用INIT ACK生成状态Cookie。端点使用在其INIT中发送的参数来计算状态Cookie。
After that, the endpoint MUST NOT change its state, the T1-init timer shall be left running, and the corresponding TCB MUST NOT be destroyed. The normal procedures for handling State Cookies when a TCB exists will resolve the duplicate INITs to a single association.
在此之后，端点不得改变其状态，T1初始计时器应保持运行，且不得破坏相应的TCB。TCB存在时处理状态cookie的正常过程将把重复的初始化解析为单个关联。
For an endpoint that is in the COOKIE-ECHOED state, it MUST populate its Tie-Tags within both the association TCB and inside the State Cookie (see Section 5.2.2 for a description of the Tie-Tags).
对于处于COOKIE-echood状态的端点，它必须在关联TCB和状态COOKIE内部填充其关联标记（有关关联标记的说明，请参见第5.2.2节）。
5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.2. 处于关闭、COOKIE-Echosed、COOKIE-WAIT和SHUTDOWN-ACK-SENT以外状态的意外初始化
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding, the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond with an ABORT, copying the 'Initiate Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In
除非另有说明，否则在收到此关联的意外INIT时，端点应使用状态Cookie生成INIT ACK。在响应之前，端点必须检查意外的INIT是否向关联添加了新地址。如果将新地址添加到关联中，端点必须以中止响应，将意外初始化的“启动标记”复制到携带中止的出站数据包的“验证标记”中。在里面
the ABORT response, the cause of error MAY be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a reserved place within the State Cookie and the association's TCB. We shall refer to these locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy within an association's TCB as the Local Tag and Peer's Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiate Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiate Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
在中止响应中，可能会将错误原因设置为“重新启动与新地址的关联”。错误应列出添加到重新启动关联的地址。如果未添加新地址，则在响应出站INIT ACK中的INIT时，端点必须将其当前Tie标记复制到状态Cookie和关联的TCB中的保留位置。我们将把cookie中的这些位置称为Peer's-Tie-Tag和Local-Tie-Tag。我们将引用关联TCB中的副本作为本地标记和对等标记。包含此初始化确认的出站SCTP数据包必须携带一个验证标记值，该值等于在意外初始化中找到的Initiate标记。初始确认必须包含一个新的初始标记（随机生成；见第5.3.1节）。端点的其他参数应从关联的现有参数（例如，出站流的数量）复制到INIT ACK和cookie中。
After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
在发送INIT ACK或ABORT后，端点不应采取进一步的操作；i、 例如，不能更改现有关联（包括其当前状态）和相应的TCB。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e., the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed).
注意：只有当TCB存在且关联未处于COOKIE-WAIT或SHUTDOWN-ACK-SENT状态时，Tie标记才会填充0以外的值。对于正常关联初始化（即端点处于关闭状态），Tie标记必须设置为0（表示之前不存在TCB）。
If an INIT ACK is received by an endpoint in any state other than the COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk. An unexpected INIT ACK usually indicates the processing of an old or duplicated INIT chunk.
如果端点在COOKIE-WAIT状态以外的任何状态下接收到INIT ACK，则该端点应丢弃INIT ACK块。意外的INIT ACK通常表示处理旧的或重复的INIT块。
When a COOKIE ECHO chunk is received by an endpoint in any state for an existing association (i.e., not in the CLOSED state) the following rules shall be applied:
当端点在现有关联的任何状态（即未处于关闭状态）下接收到COOKIE回显块时，应应用以下规则：
1) Compute a MAC as described in step 1 of Section 5.1.5,
1) 按照第5.1.5节步骤1所述计算MAC，
2) Authenticate the State Cookie as described in step 2 of Section 5.1.5 (this is case C or D above).
2) 按照第5.1.5节第2步中的描述对状态Cookie进行身份验证（这是上述情况C或D）。
3) Compare the timestamp in the State Cookie to the current time. If the State Cookie is older than the lifespan carried in the State Cookie and the Verification Tags contained in the State Cookie do not match the current association's Verification Tags,
3) 将状态Cookie中的时间戳与当前时间进行比较。如果状态Cookie比状态Cookie中包含的寿命长，并且状态Cookie中包含的验证标记与当前关联的验证标记不匹配，
the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint (this is case C or D in Section 5.2).
数据包，包括COOKIE回显和任何数据块，应该被丢弃。端点还必须将带有“过时Cookie”错误原因的错误块传输到对等端点（这是第5.2节中的情况C或D）。
If both Verification Tags in the State Cookie match the Verification Tags of the current association, consider the State Cookie valid (this is case E in Section 5.2) even if the lifespan is exceeded.
如果状态Cookie中的两个验证标签与当前关联的验证标签相匹配，则考虑状态Cookie有效（这是第5.2节中的E E），即使超过了寿命。
4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB.
4) 如果状态Cookie被证明是有效的，则将TCB解包到临时TCB中。
5) Refer to Table 2 to determine the correct action to be taken.
5) 请参阅表2以确定要采取的正确措施。
+------------+------------+---------------+--------------+-------------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ |
| | | | | Description |
+------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+
| M | X | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| M | 0 | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+
| M | M | A | A | (D) |
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB Exists |
+======================================================================+
+------------+------------+---------------+--------------+-------------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ |
| | | | | Description |
+------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+
| M | X | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| M | 0 | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+
| M | M | A | A | (D) |
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB Exists |
+======================================================================+
Legend:
图例：
X - Tag does not match the existing TCB. M - Tag matches the existing TCB. 0 - No Tie-Tag in cookie (unknown). A - All cases, i.e., M, X, or 0.
X标记与现有TCB不匹配。标记匹配现有的TCB。0-cookie中没有领带标签（未知）。A-所有情况，即M、X或0。
Note: For any case not shown in Table 2, the cookie should be silently discarded.
注意：对于表2中没有显示的任何情况，cookie都应该被悄悄地丢弃。
Action
行动
A) In this case, the peer may have restarted. When the endpoint recognizes this potential 'restart', the existing session is treated the same as if it received an ABORT followed by a new COOKIE ECHO with the following exceptions:
A） 在这种情况下，对等方可能已重新启动。当端点识别到此潜在的“重新启动”时，现有会话将被视为在接收到一个新的COOKIE回显后中止，但有以下例外：
- Any SCTP DATA chunks MAY be retained (this is an implementation-specific option).
- 可以保留任何SCTP数据块（这是一个特定于实现的选项）。
- A notification of RESTART SHOULD be sent to the ULP instead of a "COMMUNICATION LOST" notification.
- 应向ULP发送重启通知，而不是“通信丢失”通知。
All the congestion control parameters (e.g., cwnd, ssthresh) related to this peer MUST be reset to their initial values (see Section 6.2.1).
必须将与该对等方相关的所有拥塞控制参数（如cwnd、ssthresh）重置为其初始值（见第6.2.1节）。
After this, the endpoint shall enter the ESTABLISHED state.
在此之后，端点应进入已建立状态。
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes that the peer has restarted (Action A), it MUST NOT set up a new association but instead resend the SHUTDOWN ACK and send an ERROR chunk with a "Cookie Received While Shutting Down" error cause to its peer.
如果端点处于SHUTDOWN-ACK-SENT状态并识别出对等方已重新启动（操作A），则它不能设置新的关联，而是应重新发送SHUTDOWN ACK，并向其对等方发送一个错误块，其中包含“关闭时收到的Cookie”错误原因。
B) In this case, both sides may be attempting to start an association at about the same time, but the peer endpoint started its INIT after responding to the local endpoint's INIT. Thus, it may have picked a new Verification Tag, not being aware of the previous tag it had sent this endpoint. The endpoint should stay in or enter the ESTABLISHED state, but it MUST update its peer's Verification Tag from the State Cookie, stop any init or cookie timers that may be running, and send a COOKIE ACK.
B） 在这种情况下，双方可能同时尝试启动关联，但对等端点在响应本地端点的INIT后启动了其INIT。因此，它可能已经选择了一个新的验证标记，而没有意识到它已经发送给这个端点的前一个标记。端点应保持或进入已建立状态，但它必须从状态Cookie更新其对等方的验证标记，停止任何可能正在运行的init或Cookie计时器，并发送Cookie确认。
C) In this case, the local endpoint's cookie has arrived late. Before it arrived, the local endpoint sent an INIT and received an INIT ACK and finally sent a COOKIE ECHO with the peer's same tag but a new tag of its own. The cookie should be silently discarded. The endpoint SHOULD NOT change states and should leave any timers running.
C） 在本例中，本地终结点的cookie延迟到达。在到达之前，本地端点发送了一个INIT并收到了一个INIT ACK，最后发送了一个COOKIE回显，其中包含了对等方的相同标记，但有一个自己的新标记。应该悄悄地丢弃cookie。端点不应更改状态，并应保持任何计时器运行。
D) When both local and remote tags match, the endpoint should enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It should stop any cookie timer that may be running and send a COOKIE ACK.
D） 当本地标记和远程标记匹配时，如果端点处于COOKIE-echood状态，则端点应进入已建立状态。它应该停止任何可能正在运行的cookie计时器并发送cookie确认。
Note: The "peer's Verification Tag" is the tag received in the Initiate Tag field of the INIT or INIT ACK chunk.
注意：“对等验证标记”是在INIT或INIT ACK块的Initiate Tag字段中接收的标记。
In the following example, "A" initiates the association after a restart has occurred. Endpoint "Z" had no knowledge of the restart until the exchange (i.e., Heartbeats had not yet detected the failure of "A") (assuming no bundling or fragmentation occurs):
在下面的示例中，“A”在重新启动后启动关联。端点“Z”在交换之前不知道重新启动（即心跳尚未检测到“A”的故障）（假设未发生捆绑或碎片）：
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find an existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match, i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find an existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match, i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
图5：重启示例
5.2.5. Handle Duplicate COOKIE-ACK.
5.2.5. 处理重复的COOKIE-ACK。
At any state other than COOKIE-ECHOED, an endpoint should silently discard a received COOKIE ACK chunk.
在COOKIE-echood以外的任何状态下，端点都应该静默地丢弃接收到的COOKIE ACK块。
Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates one of a number of possible events:
接收到带有“过时Cookie”错误原因的错误块表示可能发生的事件之一：
A) The association failed to completely setup before the State Cookie issued by the sender was processed.
A） 在处理发件人发出的状态Cookie之前，无法完全设置关联。
B) An old State Cookie was processed after setup completed.
B） 安装完成后处理了旧状态Cookie。
C) An old State Cookie is received from someone that the receiver is not interested in having an association with and the ABORT chunk was lost.
C） 从接收者不感兴趣的人处接收旧状态Cookie，并且中止区块丢失。
When processing an ERROR chunk with a "Stale Cookie" error cause an endpoint should first examine if an association is in the process of being set up, i.e., the association is in the COOKIE-ECHOED state. In all cases, if the association is not in the COOKIE-ECHOED state, the ERROR chunk should be silently discarded.
当处理带有“Stale Cookie”错误原因的错误块时，端点应首先检查关联是否正在设置过程中，即关联是否处于Cookie-echood状态。在所有情况下，如果关联未处于COOKIE-echood状态，则错误块应被静默丢弃。
If the association is in the COOKIE-ECHOED state, the endpoint may elect one of the following three alternatives.
如果关联处于COOKIE-echood状态，端点可以选择以下三种备选方案之一。
1) Send a new INIT chunk to the endpoint to generate a new State Cookie and reattempt the setup procedure.
1) 将新的INIT块发送到端点以生成新的状态Cookie，然后重新尝试安装过程。
2) Discard the TCB and report to the upper layer the inability to set up the association.
2) 丢弃TCB并向上层报告无法建立关联。
3) Send a new INIT chunk to the endpoint, adding a Cookie Preservative parameter requesting an extension to the life time of the State Cookie. When calculating the time extension, an implementation SHOULD use the RTT information measured based on the previous COOKIE ECHO / ERROR exchange, and should add no more than 1 second beyond the measured RTT, due to long State Cookie life times making the endpoint more subject to a replay attack.
3) 向端点发送一个新的INIT块，添加一个Cookie参数，请求延长状态Cookie的生存时间。在计算时间延长时，实现应使用基于先前COOKIE回音/错误交换测量的RTT信息，并且应在测量的RTT之外添加不超过1秒的时间，因为状态COOKIE生命周期较长，使端点更容易受到重播攻击。
Initiate Tag values should be selected from the range of 1 to 2**32 - 1. It is very important that the Initiate Tag value be randomized to help protect against "man in the middle" and "sequence number" attacks. The methods described in [RFC4086] can be used for the Initiate Tag randomization. Careful selection of Initiate Tags is also necessary to prevent old duplicate packets from previous associations being mistakenly processed as belonging to the current association.
启动标签值应在1到2**32-1范围内选择。将Initiate标记值随机化以帮助防止“中间人”和“序列号”攻击非常重要。[RFC4086]中描述的方法可用于初始标签随机化。仔细选择Initiate标记也很有必要，以防止来自以前关联的旧重复数据包被错误地处理为属于当前关联。
Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the life time of an association. A new Verification Tag value MUST be used each time the endpoint tears down and then reestablishes an association to the same peer.
此外，给定关联中任一端点使用的验证标记值在关联的生命周期内不得更改。每次端点断开，然后重新建立与同一对等方的关联时，必须使用新的验证标记值。
During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association:
在建立关联期间，两个对等方交换地址列表。在大多数情况下，这些列表准确地表示每个对等方拥有的地址。然而，行为不端的对等方可能会提供它不拥有的地址。为防止出现这种情况，以下规则将应用于新关联的所有地址：
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1) 上层传递给INIT发送方的任何地址都会自动被视为已确认。
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent.
2) 对于COOKIE ECHO的接收方，唯一确认的地址是发送INIT-ACK的地址。
3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification.
3) 规则1和规则2未涵盖的所有其他地址均被视为未确认地址，需要进行调查以进行验证。
To probe an address for verification, an endpoint will send HEARTBEATs including a 64-bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter.
要探测用于验证的地址，端点将在HEARTBEAT参数内发送心跳，包括64位随机nonce和路径指示符（用于标识心跳发送到的地址）。
Upon receipt of the HEARTBEAT ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
在接收到HEARTBEAT ACK后，将验证HEARTBEAT参数中包含的nonce是否是发送到HEARTBEAT参数中指示的地址的nonce。当发生此匹配时，原始心跳发送到的地址现在被视为已确认并可用于正常数据传输。
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed.
这些探测过程在关联移动到已建立状态时开始，在确认所有路径时结束。
In each RTO, a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in Section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented.
在每个RTO中，可以在活动的未确认路径上发送探测，以尝试将其移动到已确认状态。如果在此探测过程中路径变为非活动状态，则此速率将降低到正常心跳速率。RTO计时器到期时，任何已探测但未确认的路径的错误计数器增加1，并进行路径故障检测，如第8.2节所定义。但是，在探测未确认的地址时，关联的总体错误计数不会增加。
The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peer's addresses for path verification.
每个RTO发送的心跳数应受到HB.Max.Burst参数的限制。如何将心跳分配到对等地址以进行路径验证是一个实现决策。
Whenever a path is confirmed, an indication MAY be given to the upper layer.
每当确认路径时，可向上层给出指示。
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions:
端点不得向未经确认的地址发送任何数据块，以下情况除外：
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address.
- 包括nonce的心跳信号可以发送到未确认的地址。
- A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address.
- 心跳确认可以发送到未确认的地址。
- A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE ACK to an UNCONFIRMED address.
- COOKIE ACK可以发送到未确认的地址，但必须与包含nonce的心跳绑定。不支持捆绑的实现不得向未确认的地址发送COOKIE确认。
- A COOKIE ECHO MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or if the bundled COOKIE ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implementation MUST NOT send a COOKIE ECHO to an UNCONFIRMED address.
- COOKIE回显可以发送到未确认的地址，但必须与包含nonce的心跳绑定，并且数据包不得超过路径MTU。如果实现不支持捆绑，或者捆绑的COOKIE ECHO plus HEARTBEAT（包括nonce）将超过路径MTU，则实现不得向未确认的地址发送COOKIE ECHO。
Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunks are allowed to be bundled with an outbound COOKIE ECHO chunk when in the COOKIE-WAIT state.
数据传输只能在已建立、关机挂起和关机接收状态下进行。唯一的例外是，当处于COOKIE-WAIT状态时，允许数据块与出站COOKIE回显块绑定。
DATA chunks MUST only be received according to the rules below in ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT. A DATA chunk received in CLOSED is out of the blue and SHOULD be handled per Section 8.4. A DATA chunk received in any other state SHOULD be discarded.
数据块只能根据以下规则在“已建立”、“关机-挂起”和“关机-发送”中接收。在CLOSED中接收到的数据块是出乎意料的，应根据第8.4节进行处理。应丢弃在任何其他状态下接收的数据块。
A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED. An incoming SACK MAY be processed in COOKIE-ECHOED. A SACK in the CLOSED state is out of the blue and SHOULD be processed according to the rules in Section 8.4. A SACK chunk received in any other state SHOULD be discarded.
SACK必须在已建立、关机挂起和关机接收中处理。传入的SACK可以在COOKIE-echood中处理。处于关闭状态的袋子是出乎意料的，应根据第8.4节中的规则进行处理。应丢弃在任何其他状态下接收的SACK块。
An SCTP receiver MUST be able to receive a minimum of 1500 bytes in one SCTP packet. This means that an SCTP endpoint MUST NOT indicate less than 1500 bytes in its initial a_rwnd sent in the INIT or INIT ACK.
SCTP接收器必须能够在一个SCTP数据包中接收至少1500字节。这意味着SCTP端点在INIT或INIT ACK中发送的初始rwnd中不得指示少于1500字节。
For transmission efficiency, SCTP defines mechanisms for bundling of small user messages and fragmentation of large user messages. The following diagram depicts the flow of user messages through SCTP.
为了提高传输效率，SCTP定义了用于捆绑小用户消息和分割大用户消息的机制。下图描述了通过SCTP的用户消息流。
In this section, the term "data sender" refers to the endpoint that transmits a DATA chunk and the term "data receiver" refers to the endpoint that receives a DATA chunk. A data receiver will transmit SACK chunks.
在本节中，术语“数据发送方”指传输数据块的端点，“数据接收方”指接收数据块的端点。数据接收器将发送SACK块。
+--------------------------+
| User Messages |
+--------------------------+
SCTP user ^ |
==================|==|=======================================
| v (1)
+------------------+ +--------------------+
| SCTP DATA Chunks | |SCTP Control Chunks |
+------------------+ +--------------------+
^ | ^ |
| v (2) | v (2)
+--------------------------+
| SCTP packets |
+--------------------------+
SCTP ^ |
===========================|==|===========================
| v
Connectionless Packet Transfer Service (e.g., IP)
+--------------------------+
| User Messages |
+--------------------------+
SCTP user ^ |
==================|==|=======================================
| v (1)
+------------------+ +--------------------+
| SCTP DATA Chunks | |SCTP Control Chunks |
+------------------+ +--------------------+
^ | ^ |
| v (2) | v (2)
+--------------------------+
| SCTP packets |
+--------------------------+
SCTP ^ |
===========================|==|===========================
| v
Connectionless Packet Transfer Service (e.g., IP)
Notes:
笔记：
1) When converting user messages into DATA chunks, an endpoint will fragment user messages larger than the current association path MTU into multiple DATA chunks. The data receiver will normally reassemble the fragmented message from DATA chunks before delivery to the user (see Section 6.9 for details).
1) 将用户消息转换为数据块时，端点会将大于当前关联路径MTU的用户消息分割为多个数据块。在交付给用户之前，数据接收方通常会从数据块中重新组装分段消息（详情见第6.9节）。
2) Multiple DATA and control chunks may be bundled by the sender into a single SCTP packet for transmission, as long as the final size of the packet does not exceed the current path MTU. The receiver will unbundle the packet back into the original chunks. Control chunks MUST come before DATA chunks in the packet.
2) 发送方可以将多个数据和控制块捆绑到单个SCTP分组中进行传输，只要分组的最终大小不超过当前路径MTU。接收者将把数据包分解回原始数据块。数据包中的控制块必须位于数据块之前。
Figure 6: Illustration of User Data Transfer
图6：用户数据传输示意图
The fragmentation and bundling mechanisms, as detailed in Section 6.9 and Section 6.10, are OPTIONAL to implement by the data sender, but they MUST be implemented by the data receiver, i.e., an endpoint MUST properly receive and process bundled or fragmented data.
如第6.9节和第6.10节所述，碎片和捆绑机制是可选的，可由数据发送方实施，但必须由数据接收方实施，即端点必须正确接收和处理捆绑或碎片数据。
This document is specified as if there is a single retransmission timer per destination transport address, but implementations MAY have a retransmission timer for each DATA chunk.
该文档被指定为每个目标传输地址都有一个重传计时器，但实现可能会为每个数据块都有一个重传计时器。
The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks:
对于出站数据块的传输和/或重新传输，数据发送方必须应用以下一般规则：
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A） 在任何给定时间，如果对等方的rwnd指示该对等方没有缓冲区空间（即rwnd为0；请参阅第6.2.1节），则数据发送方不得向任何目标传输地址传输新数据。但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
当接收器的播发窗口为零时，此探测称为零窗口探测。请注意，只有当所有未完成的数据块都已累计确认且没有数据块在飞行时，才应发送零窗口探测。必须支持零窗口探测。
If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address. This is because the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window. The sender SHOULD send the first zero window probe after 1 RTO when it detects that the receiver has closed its window and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero window probing does not affect the calculation of cwnd.
如果发送方在执行零窗口探测时继续从接收方接收新数据包，则未确认的窗口探测不应增加关联或任何目标传输地址的错误计数器。这是因为接收器可能会无限期地关闭窗口。请参阅第6.2节，了解接收器在播发零窗口时的行为。当发送方检测到接收方已关闭其窗口时，发送方应在1 RTO后发送第一个零窗口探测，并应在其后以指数方式增加探测间隔。还应注意，cwnd应根据第7.2.1节进行调整。零窗探测不影响cwnd的计算。
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.4 of [RFC1122].
发送方还必须具有发送新数据块的算法，以避免[RFC0813]中所述的愚蠢窗口综合症（SWS）。该算法可以类似于[RFC1122]第4.2.3.4节中描述的算法。
However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender.
但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address.
B） 在任何给定的时间，如果发送方有cwnd或更多字节的数据未发送到给定的传输地址，则发送方不得将新数据发送到该传输地址。
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd).
C） 当发送方需要传输时，在发送新的数据块之前，发送方必须首先传输标记为要重新传输的任何未完成的数据块（受当前cwnd的限制）。
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows:
D） 当发送方传输新数据块时，应使用协议参数Max.Burst来限制发送的数据包数量。可通过如下调整cwnd来应用该限值：
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.
或者，它可以通过严格限制输出例程发出的数据包的数量来应用。
E) Then, the sender can send out as many new DATA chunks as rule A and rule B allow.
E） 然后，发送方可以发送规则A和规则B允许的尽可能多的新数据块。
Multiple DATA chunks committed for transmission MAY be bundled in a single packet. Furthermore, DATA chunks being retransmitted MAY be bundled with new DATA chunks, as long as the resulting packet size does not exceed the path MTU. A ULP may request that no bundling is performed, but this should only turn off any delays that an SCTP implementation may be using to increase bundling efficiency. It does not in itself stop all bundling from occurring (i.e., in case of congestion or retransmission).
提交用于传输的多个数据块可以捆绑在单个分组中。此外，只要得到的分组大小不超过路径MTU，被重传的数据块可以与新数据块捆绑在一起。ULP可能会请求不执行捆绑，但这只会关闭SCTP实现可能用于提高捆绑效率的任何延迟。它本身并不阻止所有捆绑的发生（即，在拥塞或重传的情况下）。
Before an endpoint transmits a DATA chunk, if any received DATA chunks have not been acknowledged (e.g., due to delayed ack), the sender should create a SACK and bundle it with the outbound DATA chunk, as long as the size of the final SCTP packet does not exceed the current MTU. See Section 6.2.
在端点传输数据块之前，如果任何接收到的数据块未被确认（例如，由于延迟的ack），则发送方应创建SACK并将其与出站数据块捆绑，只要最终SCTP数据包的大小不超过当前MTU。见第6.2节。
IMPLEMENTATION NOTE: When the window is full (i.e., transmission is disallowed by rule A and/or rule B), the sender MAY still accept send requests from its upper layer, but MUST transmit no more DATA chunks until some or all of the outstanding DATA chunks are acknowledged and transmission is allowed by rule A and rule B again.
实施说明：当窗口已满（即，规则A和/或规则B不允许传输）时，发送方仍可接受其上层的发送请求，但在部分或全部未完成数据块得到确认且规则A和规则B再次允许传输之前，不得再传输数据块。
Whenever a transmission or retransmission is made to any address, if the T3-rtx timer of that address is not currently running, the sender MUST start that timer. If the timer for that address is already running, the sender MUST restart the timer if the earliest (i.e., lowest TSN) outstanding DATA chunk sent to that address is being retransmitted. Otherwise, the data sender MUST NOT restart the timer.
每当对任何地址进行传输或重新传输时，如果该地址的T3 rtx计时器当前未运行，则发送方必须启动该计时器。如果该地址的计时器已在运行，则如果发送到该地址的最早（即最低TSN）未完成数据块正在重新传输，则发送方必须重新启动计时器。否则，数据发送器不得重新启动计时器。
When starting or restarting the T3-rtx timer, the timer value must be adjusted according to the timer rules defined in Sections 6.3.2 and 6.3.3.
启动或重新启动T3 rtx定时器时，必须根据第6.3.2节和第6.3.3节中定义的定时器规则调整定时器值。
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window.
注意：数据发送方不应使用比当前发送窗口的起始TSN高出2**31-1的TSN。
The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window.
当接收到的数据块在其接收窗口内时，SCTP端点必须始终确认每个有效数据块的接收。
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.3 of [RFC1122].
当接收器的播发窗口为0时，接收器必须丢弃TSN大于迄今为止接收到的最大TSN的任何新传入数据块。如果新的传入数据块持有的TSN值小于迄今为止接收到的最大TSN，则接收方应丢弃为重新排序而持有的最大TSN，并接受新的传入数据块。在任何一种情况下，如果这样的数据块被丢弃，接收方必须立即发送回SACK，当前接收窗口仅显示到目前为止接收和接受的数据块。丢弃的数据块不能包含在SACK中，因为它们不被接受。如[RFC0813]中所述，接收器还必须有一个算法来公布其接收窗口，以避免接收器傻窗口综合症（SWS）。该算法可以类似于[RFC1122]第4.2.3.3节中描述的算法。
The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations, it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow.
应遵循[RFC2581]第4.2节中规定的延迟确认算法指南。具体地说，应至少为接收到的每一秒分组（不是每一秒数据块）生成确认，并且应在任何未确认的数据块到达后200 ms内生成确认。在某些情况下，SCTP发射机比本文件中详述的算法更加保守可能是有益的。但是，SCTP发射机的攻击性不得超过以下算法允许的范围。
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data.
SCTP接收器不得为每个传入数据包生成多个SACK，除非在接收应用程序使用新数据时更新提供的窗口。
IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried.
实施说明：SCTP管理员可以静态或动态配置生成确认的最大延迟，以满足所承载协议的特定定时要求。
An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms.
实现不得允许将最大延迟配置为超过500 ms。换句话说，实现可将该值降低到500 ms以下，但不得将其提高到500 ms以上。
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU.
除非ULP请求关闭，否则确认必须以SACK块的形式发送，在这种情况下，端点可以在关闭块中发送确认。SACK块可以确认多个数据块的接收。SACK区块格式见第3.3.4节。特别是，SCTP端点必须填写累积TSN Ack字段，以指示其接收到的（有效数据块的）最新顺序TSN。任何接收到的TSN大于累积TSN Ack字段中的值的数据块都会在Gap Ack块字段中报告。SCTP端点必须报告受当前路径MTU限制的单个SACK块中所能容纳的尽可能多的Gap Ack块。
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, the endpoint should use a SACK instead of the SHUTDOWN chunk to acknowledge DATA chunks received out of order.
注意：关机块不包含间隙确认块字段。因此，端点应该使用SACK而不是SHUTDOWN块来确认无序接收的数据块。
When a packet arrives with duplicate DATA chunk(s) and with no new DATA chunk(s), the endpoint MUST immediately send a SACK with no delay. If a packet arrives with duplicate DATA chunk(s) bundled with new DATA chunks, the endpoint MAY immediately send a SACK. Normally, receipt of duplicate DATA chunks will occur when the original SACK chunk was lost and the peer's RTO has expired. The duplicate TSN number(s) SHOULD be reported in the SACK as duplicate.
当数据包到达时有重复的数据块，但没有新的数据块，端点必须立即发送SACK，没有延迟。如果数据包到达时包含与新数据块捆绑在一起的重复数据块，则端点可以立即发送SACK。通常，当原始SACK块丢失且对等方的RTO过期时，会收到重复的数据块。重复的TSN编号应在SACK中报告为重复。
When an endpoint receives a SACK, it MAY use the duplicate TSN information to determine if SACK loss is occurring. Further use of this data is for future study.
当端点接收到SACK时，它可以使用重复的TSN信息来确定是否发生SACK丢失。进一步使用这些数据是为了将来的研究。
The data receiver is responsible for maintaining its receive buffers. The data receiver SHOULD notify the data sender in a timely manner of changes in its ability to receive data. How an implementation manages its receive buffers is dependent on many factors (e.g., operating system, memory management system, amount of memory, etc.). However, the data sender strategy defined in Section 6.2.1 is based on the assumption of receiver operation similar to the following:
数据接收器负责维护其接收缓冲区。数据接收方应及时通知数据发送方其接收数据能力的变化。实现如何管理其接收缓冲区取决于许多因素（例如，操作系统、内存管理系统、内存量等）。但是，第6.2.1节中定义的数据发送方策略基于与以下类似的接收方操作假设：
A) At initialization of the association, the endpoint tells the peer how much receive buffer space it has allocated to the association in the INIT or INIT ACK. The endpoint sets a_rwnd to this value.
A） 在关联初始化时，端点告诉对等方它在INIT或INIT ACK中为关联分配了多少接收缓冲区空间。端点将\u rwnd设置为此值。
B) As DATA chunks are received and buffered, decrement a_rwnd by the number of bytes received and buffered. This is, in effect, closing rwnd at the data sender and restricting the amount of data it can transmit.
B） 在接收和缓冲数据块时，按接收和缓冲的字节数递减rwnd。实际上，这是在数据发送方关闭rwnd并限制其可以传输的数据量。
C) As DATA chunks are delivered to the ULP and released from the receive buffers, increment a_rwnd by the number of bytes delivered to the upper layer. This is, in effect, opening up rwnd on the data sender and allowing it to send more data. The data receiver SHOULD NOT increment a_rwnd unless it has released bytes from its receive buffer. For example, if the receiver is holding fragmented DATA chunks in a reassembly queue, it should not increment a_rwnd.
C） 当数据块被传送到ULP并从接收缓冲区释放时，将a_rwnd增加传送到上层的字节数。实际上，这是在数据发送方上打开rwnd并允许其发送更多数据。除非数据接收器已从其接收缓冲区释放字节，否则它不应增加rwnd。例如，如果接收方在重组队列中持有碎片数据块，则不应增加一个rwnd。
D) When sending a SACK, the data receiver SHOULD place the current value of a_rwnd into the a_rwnd field. The data receiver SHOULD take into account that the data sender will not retransmit DATA chunks that are acked via the Cumulative TSN Ack (i.e., will drop from its retransmit queue).
D） 发送SACK时，数据接收方应将a_rwnd的当前值放入a_rwnd字段。数据接收方应考虑数据发送方不会重新传输通过累积TSN Ack确认的数据块（即，将从其重新传输队列中删除）。
Under certain circumstances, the data receiver may need to drop DATA chunks that it has received but hasn't released from its receive buffers (i.e., delivered to the ULP). These DATA chunks may have been acked in Gap Ack Blocks. For example, the data receiver may be holding data in its receive buffers while reassembling a fragmented user message from its peer when it runs out of receive buffer space. It may drop these DATA chunks even though it has acknowledged them in Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT include them in Gap Ack Blocks in subsequent SACKs until they are received again via retransmission. In addition, the endpoint should take into account the dropped data when calculating its a_rwnd.
在某些情况下，数据接收器可能需要丢弃其已接收但尚未从其接收缓冲区释放的数据块（即，传送到ULP）。这些数据块可能已在间隙确认块中确认。例如，数据接收器可能将数据保存在其接收缓冲区中，同时在接收缓冲区空间用完时重新组装来自其对等方的分段用户消息。它可能会丢弃这些数据块，即使它已在Gap Ack块中确认它们。如果数据接收器丢弃数据块，则在通过重传再次接收数据块之前，不得将其包括在后续SACK的Gap Ack块中。此外，端点在计算其a_rwnd时应考虑丢弃的数据。
An endpoint SHOULD NOT revoke a SACK and discard data. Only in extreme circumstances should an endpoint use this procedure (such as out of buffer space). The data receiver should take into account that dropping data that has been acked in Gap Ack Blocks can result in suboptimal retransmission strategies in the data sender and thus in suboptimal performance.
端点不应撤销SACK并丢弃数据。只有在极端情况下，端点才应使用此过程（例如缓冲区空间不足）。数据接收器应考虑到丢弃已在间隙Ack块中确认的数据可能导致数据发送器中的次优重传策略，从而导致次优性能。
The following example illustrates the use of delayed acknowledgements:
以下示例说明了延迟确认的使用：
Endpoint A Endpoint Z
端点A端点Z
{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 3 messages; strm 0}
DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
/------- SACK [TSN Ack=8,block=0]
(cancel T3-rtx timer) <-----/
DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
/------- SACK [TSN Ack=8,block=0]
(cancel T3-rtx timer) <-----/
DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rtx timer)
...
{App sends 1 message; strm 1}
(bundle SACK with DATA)
/----- SACK [TSN Ack=9,block=0] \
/ DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rtx timer) <------/ (Start T3-rtx timer)
DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
(Start T3-rtx timer)
...
{App sends 1 message; strm 1}
(bundle SACK with DATA)
/----- SACK [TSN Ack=9,block=0] \
/ DATA [TSN=6,Strm=1,Seq=2]
(cancel T3-rtx timer) <------/ (Start T3-rtx timer)
(ack delayed)
(send ack)
SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)
(ack delayed)
(send ack)
SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)
Figure 7: Delayed Acknowledgement Example
图7：延迟确认示例
If an endpoint receives a DATA chunk with no user data (i.e., the Length field is set to 16), it MUST send an ABORT with error cause set to "No User Data".
如果端点接收到没有用户数据的数据块（即，长度字段设置为16），它必须发送一个中止，错误原因设置为“无用户数据”。
An endpoint SHOULD NOT send a DATA chunk with no user data part.
端点不应发送没有用户数据部分的数据块。
Each SACK an endpoint receives contains an a_rwnd value. This value represents the amount of buffer space the data receiver, at the time of transmitting the SACK, has left of its total receive buffer space (as specified in the INIT/INIT ACK). Using a_rwnd, Cumulative TSN Ack, and Gap Ack Blocks, the data sender can develop a representation of the peer's receive buffer space.
端点接收的每个SACK都包含一个a_rwnd值。该值表示数据接收器在发送SACK时，在其总接收缓冲区空间中剩余的缓冲区空间量（如INIT/INIT ACK中所指定）。使用rwnd、累积TSN Ack和Gap Ack块，数据发送方可以开发对等方接收缓冲区空间的表示。
One of the problems the data sender must take into account when processing a SACK is that a SACK can be received out of order. That is, a SACK sent by the data receiver can pass an earlier SACK and be received first by the data sender. If a SACK is received out of
数据发送方在处理SACK时必须考虑的问题之一是，SACK可能会被无序接收。也就是说，数据接收方发送的SACK可以通过较早的SACK，并首先由数据发送方接收。如果一个麻袋是从
order, the data sender can develop an incorrect view of the peer's receive buffer space.
因此，数据发送方可能对对等方的接收缓冲区空间产生错误的看法。
Since there is no explicit identifier that can be used to detect out-of-order SACKs, the data sender must use heuristics to determine if a SACK is new.
由于没有显式标识符可用于检测无序的SACK，因此数据发送者必须使用试探法来确定SACK是否是新的。
An endpoint SHOULD use the following rules to calculate the rwnd, using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in a received SACK.
端点应使用以下规则计算rwnd，使用接收到的SACK中的a_rwnd值、累积TSN Ack和Gap Ack块。
A) At the establishment of the association, the endpoint initializes the rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer specified in the INIT or INIT ACK.
A） 在建立关联时，端点将rwnd初始化为在INIT或INIT ACK中指定的对等方的播发接收方窗口信用（A_rwnd）。
B) Any time a DATA chunk is transmitted (or retransmitted) to a peer, the endpoint subtracts the data size of the chunk from the rwnd of that peer.
B） 每当数据块被传输（或重新传输）到对等方时，端点都会从该对等方的rwnd中减去数据块的数据大小。
C) Any time a DATA chunk is marked for retransmission, either via T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit (Section 7.2.4), add the data size of those chunks to the rwnd.
C） 任何时候，通过T3 rtx定时器到期（第6.3.3节）或通过快速重传（第7.2.4节），将数据块标记为重传时，将这些数据块的数据大小添加到rwnd。
Note: If the implementation is maintaining a timer on each DATA chunk, then only DATA chunks whose timer expired would be marked for retransmission.
注意：如果实现在每个数据块上维护一个计时器，那么只有计时器过期的数据块才会被标记为重新传输。
D) Any time a SACK arrives, the endpoint performs the following:
D） 每当SACK到达时，端点都会执行以下操作：
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 如果累计TSN Ack小于累计TSN Ack点，则丢弃SACK。由于累积TSN Ack是单调递增的，因此累积TSN Ack小于累积TSN Ack点的SACK表示顺序错误的SACK。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）将rwnd设置为新接收的a_rwnd减去处理累积TSN Ack和Gap Ack块后仍然未完成的字节数。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then consider the corresponding DATA that might be possibly missing: Count one miss indication towards Fast Retransmit as described in Section 7.2.4, and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）如果SAG丢失了先前通过间隙ACK块确认的TSN（例如，数据接收器放弃了数据），那么考虑可能丢失的相应数据：如7.2.4节所述，对快速重传计数一个未命中指示；如果没有为数据块最初传输到的目标地址运行重新传输计时器，则为该目标地址启动t3rtx。
iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
iv）如果累计TSN Ack匹配或超过快速恢复退出点（第7.2.4节），则快速恢复退出。
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout).
SCTP端点使用重传计时器T3 rtx来确保在没有来自其对等方的任何反馈的情况下进行数据传送。此计时器的持续时间称为RTO（重传超时）。
When an endpoint's peer is multi-homed, the endpoint will calculate a separate RTO for each different destination transport address of its peer endpoint.
当端点的对等点是多宿的时，端点将为其对等端点的每个不同目的地传输地址计算单独的RTO。
The computation and management of RTO in SCTP follow closely how TCP manages its retransmission timer. To compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation).
SCTP中RTO的计算和管理与TCP如何管理其重传计时器密切相关。为了计算当前RTO，端点为每个目的地传输地址维护两个状态变量：SRTT（平滑往返时间）和RTTVAR（往返时间变化）。
The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:
SRTT、RTTVAR和RTO的计算规则如下：
C1) Until an RTT measurement has been made for a packet sent to the given destination transport address, set RTO to the protocol parameter 'RTO.Initial'.
C1）在对发送到给定目的地传输地址的数据包进行RTT测量之前，将RTO设置为协议参数“RTO.Initial”。
C2) When the first RTT measurement R is made, set
C2）进行第一次RTT测量R时，设置
SRTT <- R,
SRTT<-R，
RTTVAR <- R/2, and
RTTVAR<-R/2，以及
RTO <- SRTT + 4 * RTTVAR.
RTO<-SRTT+4*RTTVAR。
C3) When a new RTT measurement R' is made, set
C3）当进行新的RTT测量R'时，设置
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|
and
和
SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment.
注：RTTVAR更新中使用的SRTT值是使用第二个赋值更新SRTT之前的值。
After the computation, update RTO <- SRTT + 4 * RTTVAR.
计算完成后，更新RTO<-SRTT+4*RTTVAR。
C4) When data is in flight and when allowed by rule C5 below, a new RTT measurement MUST be made each round trip. Furthermore, new RTT measurements SHOULD be made no more than once per round trip for a given destination transport address. There are two reasons for this recommendation: First, it appears that measuring more frequently often does not in practice yield any significant benefit [ALLMAN99]; second, if measurements are made more often, then the values of RTO.Alpha and RTO.Beta in rule C3 above should be adjusted so that SRTT and RTTVAR still adjust to changes at roughly the same rate (in terms of how many round trips it takes them to reflect new values) as they would if making only one measurement per round-trip and using RTO.Alpha and RTO.Beta as given in rule C3. However, the exact nature of these adjustments remains a research issue.
C4）当数据处于飞行状态且以下规则C5允许时，每次往返必须进行新的RTT测量。此外，对于给定的目的地传输地址，每次往返不应进行一次新的RTT测量。这一建议有两个原因：第一，更频繁地测量似乎在实践中不会产生任何显著的好处[ALLMAN99]；其次，如果更频繁地进行测量，则应调整上述规则C3中RTO.Alpha和RTO.Beta的值，以便SRTT和RTTVAR仍以大致相同的速率调整以适应变化（就反映新值所需的往返次数而言）如果每次往返只进行一次测量，并使用规则C3中给出的RTO.Alpha和RTO.Beta，他们会这样做。然而，这些调整的确切性质仍然是一个研究问题。
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance)
C5）Karn算法：不得使用重新传输的数据包进行RTT测量（因此，对于这些数据包，回复是针对块的第一个实例还是针对以后的实例是不明确的）
IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.
实施说明：如果自r首次发送后，没有TSN小于或等于r的区块被重新传输，则只能使用TSN为r的区块进行RTT测量。
C6) Whenever RTO is computed, if it is less than RTO.Min seconds then it is rounded up to RTO.Min seconds. The reason for this rule is that RTOs that do not have a high minimum value are susceptible to unnecessary timeouts [ALLMAN99].
C6）每当计算RTO时，如果小于RTO.Min秒，则将其四舍五入到RTO.Min秒。此规则的原因是，最小值不高的RTO容易出现不必要的超时[ALLMAN99]。
C7) A maximum value may be placed on RTO provided it is at least RTO.max seconds.
C7）可在RTO上设置最大值，前提是该值至少为RTO.max秒。
There is no requirement for the clock granularity G used for computing RTT measurements and the different state variables, other than:
不要求用于计算RTT测量和不同状态变量的时钟粒度G，除了：
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <- G.
G1）每当计算RTTVAR时，如果RTTVAR=0，则调整RTTVAR<-G。
Experience [ALLMAN99] has shown that finer clock granularities (<= 100 msec) perform somewhat better than more coarse granularities.
经验[ALLMAN99]表明，较细的时钟粒度（<=100毫秒）比较粗的时钟粒度性能要好一些。
The rules for managing the retransmission timer are as follows:
管理重传计时器的规则如下：
R1) Every time a DATA chunk is sent to any address (including a retransmission), if the T3-rtx timer of that address is not running, start it running so that it will expire after the RTO of that address. The RTO used here is that obtained after any doubling due to previous T3-rtx timer expirations on the corresponding destination address as discussed in rule E2 below.
R1）每次将数据块发送到任何地址（包括重传）时，如果该地址的T3 rtx计时器未运行，则启动该计时器，使其在该地址的RTO后过期。此处使用的RTO是由于之前的T3 rtx计时器在相应的目标地址上过期而在任何倍增后获得的，如下面的规则E2所述。
R2) Whenever all outstanding data sent to an address have been acknowledged, turn off the T3-rtx timer of that address.
R2）只要发送到某个地址的所有未完成数据均已确认，则关闭该地址的T3 rtx定时器。
R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address).
R3）每当收到SACK确认该地址具有最早未完成TSN的数据块时，使用其当前RTO（如果该地址上仍有未完成数据）重新启动该地址的T3 rtx计时器。
R4) Whenever a SACK is received missing a TSN that was previously acknowledged via a Gap Ack Block, start the T3-rtx for the destination address to which the DATA chunk was originally transmitted if it is not already running.
R4）每当接收到缺少先前通过Gap Ack块确认的TSN的SACK时，如果尚未运行，则启动数据块最初传输到的目标地址的T3 rtx。
The following example shows the use of various timer rules (assuming that the receiver uses delayed acks).
下面的示例显示了各种计时器规则的使用（假设接收器使用延迟的ack）。
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Restart T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Restart T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Figure 8: Timer Rule Examples
图8：计时器规则示例
Whenever the retransmission timer T3-rtx expires for a destination address, do the following:
每当目标地址的重传计时器T3 rtx过期时，执行以下操作：
E1) For the destination address for which the timer expires, adjust its ssthresh with rules defined in Section 7.2.3 and set the cwnd <- MTU.
E1）对于计时器到期的目标地址，使用第7.2.3节中定义的规则调整其ssthresh，并设置cwnd<-MTU。
E2) For the destination address for which the timer expires, set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in rule C7 above (RTO.max) may be used to provide an upper bound to this doubling operation.
E2）对于计时器过期的目标地址，设置RTO<-RTO*2（“退出计时器”）。上述规则C7中讨论的最大值（RTO.max）可用于提供此倍增操作的上限。
E3) Determine how many of the earliest (i.e., lowest TSN) outstanding DATA chunks for the address for which the T3-rtx has expired will fit into a single packet, subject to the MTU constraint for the path corresponding to the destination transport address to which the retransmission is being sent (this may be different from the address for which the timer expires; see Section 6.4). Call this value K. Bundle and retransmit those K DATA chunks in a single packet to the destination endpoint.
E3）确定T3 rtx已过期的地址的最早（即，最低TSN）未完成数据块中有多少将适合于单个分组，取决于与正在向其发送重传的目的地传输地址对应的路径的MTU约束（这可能不同于计时器过期的地址；请参阅第6.4节）。调用此值K.Bundle并将单个数据包中的K个数据块重新传输到目标端点。
E4) Start the retransmission timer T3-rtx on the destination address to which the retransmission is sent, if rule R1 above indicates to do so. The RTO to be used for starting T3-rtx should be the one for the destination address to which the retransmission is sent, which, when the receiver is multi-homed, may be different from the destination address for which the timer expired (see Section 6.4 below).
E4）如果上面的规则R1指示这样做，则在发送重传的目的地地址上启动重传计时器T3 rtx。用于启动T3 rtx的RTO应为发送重传的目标地址的RTO，当接收器为多址时，该RTO可能不同于计时器过期的目标地址（见下文第6.4节）。
After retransmitting, once a new RTT measurement is obtained (which can happen only when new data has been sent and acknowledged, per rule C5, or for a measurement made from a HEARTBEAT; see Section 8.3), the computation in rule C3 is performed, including the computation of RTO, which may result in "collapsing" RTO back down after it has been subject to doubling (rule E2).
在重新传输后，一旦获得新的RTT测量值（仅当根据规则C5发送和确认新数据时，或者对于通过心跳进行的测量，才可能发生这种情况；参见第8.3节），将执行规则C3中的计算，包括RTO的计算，这可能会导致“崩溃”RTO在受到加倍影响后后退（规则E2）。
Note: Any DATA chunks that were sent to the address for which the T3-rtx timer expired but did not fit in one MTU (rule E3 above) should be marked for retransmission and sent as soon as cwnd allows (normally, when a SACK arrives).
注意：发送到T3 rtx计时器过期但不适合一个MTU（上面的规则E3）的地址的任何数据块应标记为重新传输，并在cwnd允许的情况下尽快发送（通常，当SACK到达时）。
The final rule for managing the retransmission timer concerns failover (see Section 6.4.1):
管理重传计时器的最终规则涉及故障转移（见第6.4.1节）：
F1) Whenever an endpoint switches from the current destination transport address to a different one, the current retransmission timers are left running. As soon as the endpoint transmits a packet containing DATA chunk(s) to the new transport address, start the timer on that transport address, using the RTO value of the destination address to which the data is being sent, if rule R1 indicates to do so.
F1）每当端点从当前目标传输地址切换到不同的传输地址时，当前重传计时器将保持运行。一旦端点将包含数据块的数据包传输到新的传输地址，如果规则R1指示这样做，则使用数据发送到的目标地址的RTO值在该传输地址上启动计时器。
An SCTP endpoint is considered multi-homed if there are more than one transport address that can be used as a destination address to reach that endpoint.
如果有多个传输地址可用作到达该端点的目标地址，则将SCTP端点视为多宿主。
Moreover, the ULP of an endpoint shall select one of the multiple destination addresses of a multi-homed peer endpoint as the primary path (see Section 5.1.2 and Section 10.1 for details).
此外，端点的ULP应选择多宿对等端点的多个目的地地址中的一个作为主路径（详见第5.1.2节和第10.1节）。
By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use.
默认情况下，端点应始终传输到主路径，除非SCTP用户明确指定要使用的目标传输地址（可能还有源传输地址）。
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.
端点应将应答块（例如，SACK、心跳ACK等）传输到从中接收数据的同一目标传输地址或其应答的控制块。如果端点将数据块与应答块捆绑在一起，也应遵循此规则。
However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received.
然而，当在单个SACK中确认分组中从不同源地址接收的多个数据块时，SACK块可以被发送到接收到被确认的数据或控制块的目的地传输地址之一。
When a receiver of a duplicate DATA chunk sends a SACK to a multi-homed endpoint, it MAY be beneficial to vary the destination address and not use the source address of the DATA chunk. The reason is that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken.
当重复数据块的接收器向多宿端点发送SACK时，改变目标地址而不使用数据块的源地址可能是有益的。原因是，从多宿主端点接收副本可能表明SACK的返回路径（在数据块的源地址中指定）已中断。
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
此外，当其对等方是多宿时，端点应尝试将超时的数据块重新传输到活动目标传输地址，该地址与数据块发送到的最后一个目标地址不同。
Retransmissions do not affect the total outstanding data count. However, if the DATA chunk is retransmitted onto a different destination address, both the outstanding data counts on the new
重新传输不会影响未完成的数据总数。但是，如果数据块被重新传输到另一个目标地址，则两个未完成的数据都将计入新的目标地址
destination address and the old destination address to which the data chunk was last sent shall be adjusted accordingly.
应相应地调整数据块最后发送到的目标地址和旧目标地址。
Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from the SCTP user.
由于出现某些错误情况（参见第8.2节）或SCTP用户的调整，多宿SCTP端点的某些传输地址可能会变为非活动状态。
When there is outbound data to send and the primary path becomes inactive (e.g., due to failures), or where the SCTP user explicitly requests to send data to an inactive destination transport address, before reporting an error to its ULP, the SCTP endpoint should try to send the data to an alternate active destination transport address if one exists.
当存在要发送的出站数据且主路径变为非活动（例如，由于故障）时，或者SCTP用户在向其ULP报告错误之前明确请求将数据发送到非活动目标传输地址时，SCTP端点应尝试将数据发送到备用活动目标传输地址（如果存在）。
When retransmitting data that timed out, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed-out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
当重传超时的数据时，如果端点是多宿主的，则它应该考虑其重传选择策略中的每个源目的地地址对。当重新传输超时数据时，端点应尝试从数据包传输到的原始源-目的地对中选取差异最大的源-目的地对。
Note: Rules for picking the most divergent source-destination pair are an implementation decision and are not specified within this document.
注意：选择差异最大的源-目的地对的规则是一项实施决策，本文档中未指定。
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK.
每个数据块必须携带一个有效的流标识符。如果端点接收到具有无效流标识符的数据块，它应按照正常程序确认数据块的接收，立即发送错误块，并将原因设置为“无效流标识符”（参见第3.3.10节），然后丢弃数据块。只要错误跟随SACK，端点就可以将错误块捆绑在与SACK相同的数据包中。
The Stream Sequence Number in all the streams MUST start from 0 when the association is established. Also, when the Stream Sequence Number reaches the value 65535 the next Stream Sequence Number MUST be set to 0.
建立关联时，所有流中的流序列号必须从0开始。此外，当流序列号达到值65535时，下一个流序列号必须设置为0。
Within a stream, an endpoint MUST deliver DATA chunks received with the U flag set to 0 to the upper layer according to the order of their Stream Sequence Number. If DATA chunks arrive out of order of
在流中，端点必须根据流序列号的顺序将U标志设置为0的接收数据块传递给上层。如果数据块的到达顺序与
their Stream Sequence Number, the endpoint MUST hold the received DATA chunks from delivery to the ULP until they are reordered.
端点必须保留从交付到ULP的接收数据块的流序列号，直到它们被重新排序。
However, an SCTP endpoint can indicate that no ordered delivery is required for a particular DATA chunk transmitted within the stream by setting the U flag of the DATA chunk to 1.
然而，通过将数据块的U标志设置为1，SCTP端点可以指示流内传输的特定数据块不需要有序传递。
When an endpoint receives a DATA chunk with the U flag set to 1, it must bypass the ordering mechanism and immediately deliver the data to the upper layer (after reassembly if the user data is fragmented by the data sender).
当端点接收到U标志设置为1的数据块时，它必须绕过排序机制并立即将数据传递到上层（如果数据发送方将用户数据分段，则在重新组装后）。
This provides an effective way of transmitting "out-of-band" data in a given stream. Also, a stream can be used as an "unordered" stream by simply setting the U flag to 1 in all DATA chunks sent through that stream.
这提供了在给定流中传输“带外”数据的有效方法。此外，在通过流发送的所有数据块中，只要将U标志设置为1，就可以将流用作“无序”流。
IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an implementation may choose to place the DATA chunk in an outbound packet that is at the head of the outbound transmission queue if possible.
实现说明：在发送无序数据块时，实现可能会选择将数据块放在出站传输队列头部的出站数据包中。
The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1 has no significance. The sender can fill it with arbitrary value, but the receiver MUST ignore the field.
U标志设置为1的数据块中的“流序列号”字段没有意义。发送方可以用任意值填充，但接收方必须忽略该字段。
Note: When transmitting ordered and unordered data, an endpoint does not increment its Stream Sequence Number when transmitting a DATA chunk with U flag set to 1.
注意：当传输有序和无序数据时，当传输U标志设置为1的数据块时，端点不会增加其流序列号。
Upon the reception of a new DATA chunk, an endpoint shall examine the continuity of the TSNs received. If the endpoint detects a gap in the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack Blocks immediately. The data receiver continues sending a SACK after receipt of each SCTP packet that doesn't fill the gap.
接收到新数据块后，端点应检查接收到的TSN的连续性。如果端点在接收到的数据块序列中检测到间隙，它应该立即发送带有间隙确认块的SACK。数据接收器在接收到未填补空白的每个SCTP数据包后继续发送SACK。
Based on the Gap Ack Block from the received SACK, the endpoint can calculate the missing DATA chunks and make decisions on whether to retransmit them (see Section 6.2.1 for details).
根据接收到的SACK的Gap Ack块，端点可以计算丢失的数据块，并决定是否重新传输它们（有关详细信息，请参阅第6.2.1节）。
Multiple gaps can be reported in one single SACK (see Section 3.3.4).
可在一个袋子中报告多个间隙（见第3.3.4节）。
When its peer is multi-homed, the SCTP endpoint SHOULD always try to send the SACK to the same destination address from which the last DATA chunk was received.
当其对等方是多宿时，SCTP端点应始终尝试将SACK发送到接收最后一个数据块的相同目标地址。
Upon the reception of a SACK, the endpoint MUST remove all DATA chunks that have been acknowledged by the SACK's Cumulative TSN Ack from its transmit queue. The endpoint MUST also treat all the DATA chunks with TSNs not included in the Gap Ack Blocks reported by the SACK as "missing". The number of "missing" reports for each outstanding DATA chunk MUST be recorded by the data sender in order to make retransmission decisions. See Section 7.2.4 for details.
接收到SACK后，端点必须从其传输队列中移除SACK的累积TSN Ack确认的所有数据块。端点还必须将SACK报告的Gap Ack块中未包含TSN的所有数据块视为“缺失”。数据发送方必须记录每个未完成数据块的“缺失”报告数，以便做出重传决策。详见第7.2.4节。
The following example shows the use of SACK to report a gap.
下面的示例显示如何使用SACK报告间隙。
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
Figure 9: Reporting a Gap using SACK
图9：使用SACK报告间隙
The maximum number of Gap Ack Blocks that can be reported within a single SACK chunk is limited by the current path MTU. When a single SACK cannot cover all the Gap Ack Blocks needed to be reported due to the MTU limitation, the endpoint MUST send only one SACK, reporting the Gap Ack Blocks from the lowest to highest TSNs, within the size limit set by the MTU, and leave the remaining highest TSN numbers unacknowledged.
单个SACK块中可报告的最大间隙Ack块数受当前路径MTU的限制。当由于MTU限制，单个SACK无法覆盖需要报告的所有Gap Ack块时，端点必须仅发送一个SACK，在MTU设置的大小限制内报告从最低到最高TSN的Gap Ack块，并保留未确认的剩余最高TSN编号。
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the CRC32c checksum value calculated on the packet, as described below.
当发送SCTP数据包时，端点必须通过包括在数据包上计算的CRC32c校验和值来加强传输的数据完整性，如下所述。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter MUST
在构造数据包（包含SCTP公共头和一个或多个控制或数据块）后，发送器必须
1) fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to '0's,
1) 在SCTP公共标头中填写正确的验证标记，并将校验和字段初始化为“0”，
2) calculate the CRC32c checksum of the whole packet, including the SCTP common header and all the chunks (refer to Appendix B for details of the CRC32c algorithm); and
2) 计算整个数据包的CRC32c校验和，包括SCTP公共头和所有数据块（有关CRC32c算法的详细信息，请参阅附录B）；和
3) put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3) 将结果值放入公共标头的校验和字段中，并保持其余位不变。
When an SCTP packet is received, the receiver MUST first check the CRC32c checksum as follows:
当接收到SCTP数据包时，接收器必须首先检查CRC32c校验和，如下所示：
1) Store the received CRC32c checksum value aside.
1) 将接收到的CRC32c校验和值存储在一旁。
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate a CRC32c checksum value of the whole received packet.
2) 用所有“0”替换接收到的SCTP数据包中校验和字段的32位，并计算整个接收数据包的CRC32c校验和值。
3) Verify that the calculated CRC32c checksum is the same as the received CRC32c checksum. If it is not, the receiver MUST treat the packet as an invalid SCTP packet.
3) 验证计算出的CRC32c校验和与接收到的CRC32c校验和相同。如果不是，则接收方必须将该数据包视为无效的SCTP数据包。
The default procedure for handling invalid SCTP packets is to silently discard them.
处理无效SCTP数据包的默认过程是以静默方式丢弃它们。
Any hardware implementation SHOULD be done in a way that is verifiable by the software.
任何硬件实现都应以软件可验证的方式进行。
An endpoint MAY support fragmentation when sending DATA chunks, but it MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint MUST return an error to its upper layer and not attempt to send the user message.
端点在发送数据块时可能支持分段，但在接收数据块时必须支持重新组装。如果端点支持分段，则如果要发送的用户消息的大小导致出站SCTP数据包大小超过当前MTU，则必须对用户消息进行分段。如果实现不支持出站用户消息的分段，则端点必须向其上层返回错误，并且不尝试发送用户消息。
Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation, it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current Path MTU (P-MTU).
注意：如果支持分段的实现为其上层提供了一种关闭分段的机制，那么它可能会这样做。但是，在这样做时，它必须像不支持分段的实现一样做出反应，即它必须拒绝超过当前路径MTU（P-MTU）的发送。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
实现说明：在这种错误情况下，第10.1节中讨论的Send原语需要向上层返回一个错误。
If its peer is multi-homed, the endpoint shall choose a size no larger than the association Path MTU. The association Path MTU is the smallest Path MTU of all destination addresses.
如果其对等点是多宿的，则端点应选择不大于关联路径MTU的大小。关联路径MTU是所有目标地址中最小的路径MTU。
Note: Once a message is fragmented, it cannot be re-fragmented. Instead, if the PMTU has been reduced, then IP fragmentation must be used. Please see Section 7.3 for details of PMTU discovery.
注意：消息一旦分段，就不能重新分段。相反，如果PMTU已减少，则必须使用IP分段。有关PMTU发现的详细信息，请参见第7.3节。
When determining when to fragment, the SCTP implementation MUST take into account the SCTP packet header as well as the DATA chunk header(s). The implementation MUST also take into account the space required for a SACK chunk if bundling a SACK chunk with the DATA chunk.
在确定何时分段时，SCTP实现必须考虑SCTP数据包头和数据块头。如果将SACK块与数据块绑定，则实现还必须考虑SACK块所需的空间。
Fragmentation takes the following steps:
分段执行以下步骤：
1) The data sender MUST break the user message into a series of DATA chunks such that each chunk plus SCTP overhead fits into an IP datagram smaller than or equal to the association Path MTU.
1) 数据发送方必须将用户消息分成一系列数据块，这样每个数据块加上SCTP开销就可以放入小于或等于关联路径MTU的IP数据报中。
2) The transmitter MUST then assign, in sequence, a separate TSN to each of the DATA chunks in the series. The transmitter assigns the same SSN to each of the DATA chunks. If the user indicates that the user message is to be delivered using unordered delivery, then the U flag of each DATA chunk of the user message MUST be set to 1.
2) 然后，发送器必须依次为序列中的每个数据块分配单独的TSN。发射机将相同的SSN分配给每个数据块。如果用户指示要使用无序传递来传递用户消息，则必须将用户消息的每个数据块的U标志设置为1。
3) The transmitter MUST also set the B/E bits of the first DATA chunk in the series to '10', the B/E bits of the last DATA chunk in the series to '01', and the B/E bits of all other DATA chunks in the series to '00'.
3) 发射机还必须将序列中第一个数据块的B/E位设置为“10”，将序列中最后一个数据块的B/E位设置为“01”，将序列中所有其他数据块的B/E位设置为“00”。
An endpoint MUST recognize fragmented DATA chunks by examining the B/E bits in each of the received DATA chunks, and queue the fragmented DATA chunks for reassembly. Once the user message is reassembled, SCTP shall pass the reassembled user message to the specific stream for possible reordering and final dispatching.
端点必须通过检查每个接收到的数据块中的B/E位来识别碎片数据块，并将碎片数据块排队以便重新组装。一旦重新组装用户消息，SCTP应将重新组装的用户消息传递给特定流，以进行可能的重新排序和最终调度。
Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the reassembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received.
注意：如果数据接收器在等待更多片段完成消息重组时耗尽了缓冲区空间，则它应通过部分传递API（参见第10节）发送部分入站消息，释放部分接收缓冲区空间，以便接收其余消息。
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram,
端点通过简单地在一个出站SCTP数据包中包含多个块来绑定块。生成的IP数据报的总大小，
including the SCTP packet and IP headers, MUST be less that or equal to the current Path MTU.
包括SCTP数据包和IP报头，必须小于或等于当前路径MTU。
If its peer endpoint is multi-homed, the sending endpoint shall choose a size no larger than the latest MTU of the current primary path.
如果其对等端点是多宿的，则发送端点应选择不大于当前主路径的最新MTU的大小。
When bundling control chunks with DATA chunks, an endpoint MUST place control chunks first in the outbound SCTP packet. The transmitter MUST transmit DATA chunks within an SCTP packet in increasing order of TSN.
将控制块与数据块绑定时，端点必须将控制块放在出站SCTP数据包的第一位。发射机必须以TSN的递增顺序在SCTP数据包内传输数据块。
Note: Since control chunks must be placed first in a packet and since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks.
注意：由于控制块必须放在数据包的第一位，并且数据块必须在关机或关机确认块之前传输，因此数据块不能与关机或关机确认块捆绑在一起。
Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk is a chunk that is not completely contained in the SCTP packet; i.e., the SCTP packet is too short to contain all the bytes of the chunk as indicated by the chunk length.
部分块不能放在SCTP数据包中。部分区块是未完全包含在SCTP分组中的区块；i、 例如，SCTP数据包太短，无法包含块长度指示的块的所有字节。
An endpoint MUST process received chunks in their order in the packet. The receiver uses the Chunk Length field to determine the end of a chunk and beginning of the next chunk taking account of the fact that all chunks end on a 4-byte boundary. If the receiver detects a partial chunk, it MUST drop the chunk.
端点必须按照数据包中的顺序处理接收到的数据块。接收方使用Chunk Length字段来确定一个块的结尾和下一个块的开头，同时考虑到所有块都在4字节边界上结束的事实。如果接收器检测到部分区块，则必须删除该区块。
An endpoint MUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE with any other chunks.
端点不得将INIT、INIT ACK或SHUTDOWN与任何其他块捆绑在一起。
Congestion control is one of the basic functions in SCTP. For some applications, it may be likely that adequate resources will be allocated to SCTP traffic to ensure prompt delivery of time-critical data -- thus, it would appear to be unlikely, during normal operations, that transmissions encounter severe congestion conditions. However, SCTP must operate under adverse operational conditions, which can develop upon partial network failures or unexpected traffic surges. In such situations, SCTP must follow correct congestion control steps to recover from congestion quickly in order to get data delivered as soon as possible. In the absence of network congestion, these preventive congestion control algorithms should show no impact on the protocol performance.
拥塞控制是SCTP的基本功能之一。对于某些应用程序，可能会为SCTP流量分配足够的资源，以确保及时交付时间关键型数据——因此，在正常运行期间，传输不太可能遇到严重的拥塞情况。然而，SCTP必须在不利的运行条件下运行，这可能会在部分网络故障或意外流量激增时发生。在这种情况下，SCTP必须遵循正确的拥塞控制步骤，以快速从拥塞中恢复，以便尽快交付数据。在没有网络拥塞的情况下，这些预防性拥塞控制算法应该不会对协议性能产生影响。
IMPLEMENTATION NOTE: As far as its specific performance requirements are met, an implementation is always allowed to adopt a more conservative congestion control algorithm than the one defined below.
实施说明：只要满足其特定性能要求，实施始终允许采用比下面定义的更保守的拥塞控制算法。
The congestion control algorithms used by SCTP are based on [RFC2581]. This section describes how the algorithms defined in [RFC2581] are adapted for use in SCTP. We first list differences in protocol designs between TCP and SCTP, and then describe SCTP's congestion control scheme. The description will use the same terminology as in TCP congestion control whenever appropriate.
SCTP使用的拥塞控制算法基于[RFC2581]。本节描述了[RFC2581]中定义的算法如何适用于SCTP。我们首先列出TCP和SCTP在协议设计上的差异，然后描述SCTP的拥塞控制方案。在适当的情况下，描述将使用与TCP拥塞控制中相同的术语。
SCTP congestion control is always applied to the entire association, and not to individual streams.
SCTP拥塞控制始终应用于整个关联，而不是单个流。
Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. SCTP considers the information carried in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has been acknowledged by SACK, including DATA that arrived at the receiving end out of order, is not considered fully delivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack field in the SACK). Consequently, the value of cwnd controls the amount of outstanding data, rather than (as in the case of non-SACK TCP) the upper bound between the highest acknowledged sequence number and the latest DATA chunk that can be sent within the congestion window. SCTP SACK leads to different implementations of Fast Retransmit and Fast Recovery than non-SACK TCP. As an example, see [FALL96].
SCTP SACK中的Gap Ack块具有与TCP SACK相同的语义。TCP仅将SACK中携带的信息视为建议信息。SCTP将SACK块中的Gap Ack块中携带的信息视为建议。在SCTP中，SACK确认的任何数据块，包括无序到达接收端的数据，在累积TSN Ack点通过数据块的TSN（即，SACK中的累积TSN Ack字段已确认该数据块）之前，都不会被视为完全交付。因此，cwnd的值控制未完成的数据量，而不是（如非SACK TCP的情况）最高确认序列号和可在拥塞窗口内发送的最新数据块之间的上限。SCTP SACK导致与非SACK TCP不同的快速重传和快速恢复实现。例如，请参见[FALL96]。
The biggest difference between SCTP and TCP, however, is multi-homing. SCTP is designed to establish robust communication associations between two endpoints each of which may be reachable by more than one transport address. Potentially different addresses may lead to different data paths between the two endpoints; thus, ideally one may need a separate set of congestion control parameters for each of the paths. The treatment here of congestion control for multi-homed receivers is new with SCTP and may require refinement in the future. The current algorithms make the following assumptions:
然而，SCTP和TCP之间最大的区别是多宿主。SCTP设计用于在两个端点之间建立健壮的通信关联，每个端点都可以由多个传输地址访问。潜在不同的地址可能导致两个端点之间的不同数据路径；因此，理想情况下，每个路径可能需要一组单独的拥塞控制参数。这里对多宿接收机拥塞控制的处理是SCTP的新技术，将来可能需要改进。当前算法做出以下假设：
o The sender usually uses the same destination address until being instructed by the upper layer to do otherwise; however, SCTP may change to an alternate destination in the event an address is marked inactive (see Section 8.2). Also, SCTP may retransmit to a different transport address than the original transmission.
o 发送方通常使用相同的目的地地址，直到上层指示使用其他地址；但是，如果地址被标记为非活动地址，SCTP可能会更改为备用目的地（见第8.2节）。此外，SCTP可以重传到与原始传输不同的传输地址。
o The sender keeps a separate congestion control parameter set for each of the destination addresses it can send to (not each source-destination pair but for each destination). The parameters
o 发送方为其可以发送到的每个目的地地址（不是每个源-目的地对，而是每个目的地）保留一个单独的拥塞控制参数集。参数
should decay if the address is not used for a long enough time period.
如果地址在足够长的时间内未被使用，则会衰减。
o For each of the destination addresses, an endpoint does slow start upon the first transmission to that address.
o 对于每个目标地址，端点在第一次传输到该地址时会减慢启动速度。
Note: TCP guarantees in-sequence delivery of data to its upper-layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper-layer protocol even if there is a gap in TSN if the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery is indicated. Although this does not affect cwnd, it might affect rwnd calculation.
注意：TCP保证在单个TCP会话中按顺序将数据传递到其上层协议。这意味着，当TCP注意到接收到的序列号中存在间隙时，它会等待间隙被填满，然后再发送接收到的序列号高于缺失数据的序列号的数据。另一方面，如果流序列号是针对特定流的序列号（即，缺失的数据块是针对不同流的），或者如果指示无序交付，则即使TSN中存在间隙，SCTP也可以将数据交付到其上层协议。虽然这不会影响cwnd，但可能会影响rwnd计算。
The slow-start and congestion avoidance algorithms MUST be used by an endpoint to control the amount of data being injected into the network. The congestion control in SCTP is employed in regard to the association, not to an individual stream. In some situations, it may be beneficial for an SCTP sender to be more conservative than the algorithms allow; however, an SCTP sender MUST NOT be more aggressive than the following algorithms allow.
端点必须使用慢启动和拥塞避免算法来控制注入网络的数据量。SCTP中的拥塞控制针对的是关联，而不是单个流。在某些情况下，SCTP发送方比算法允许的更保守可能是有益的；但是，SCTP发送方的攻击性不得超过以下算法允许的范围。
Like TCP, an SCTP endpoint uses the following three control variables to regulate its transmission rate.
与TCP一样，SCTP端点使用以下三个控制变量来调节其传输速率。
o Receiver advertised window size (rwnd, in bytes), which is set by the receiver based on its available buffer space for incoming packets.
o 接收方公布的窗口大小（rwnd，以字节为单位），由接收方根据其传入数据包的可用缓冲区空间设置。
Note: This variable is kept on the entire association.
注意：此变量保留在整个关联上。
o Congestion control window (cwnd, in bytes), which is adjusted by the sender based on observed network conditions.
o 拥塞控制窗口（cwnd，以字节为单位），由发送方根据观察到的网络状况进行调整。
Note: This variable is maintained on a per-destination-address basis.
注意：此变量以每个目标地址为基础进行维护。
o Slow-start threshold (ssthresh, in bytes), which is used by the sender to distinguish slow-start and congestion avoidance phases.
o 慢速启动阈值（ssthresh，以字节为单位），发送方使用该阈值来区分慢速启动和拥塞避免阶段。
Note: This variable is maintained on a per-destination-address basis.
注意：此变量以每个目标地址为基础进行维护。
SCTP also requires one additional control variable, partial_bytes_acked, which is used during congestion avoidance phase to facilitate cwnd adjustment.
SCTP还需要一个额外的控制变量partial_bytes_acked，用于拥塞避免阶段，以便于cwnd调整。
Unlike TCP, an SCTP sender MUST keep a set of these control variables cwnd, ssthresh, and partial_bytes_acked for EACH destination address of its peer (when its peer is multi-homed). Only one rwnd is kept for the whole association (no matter if the peer is multi-homed or has a single address).
与TCP不同，SCTP发送方必须为其对等方的每个目标地址（当其对等方为多宿主时）保留一组控制变量cwnd、ssthresh和partial_bytes_。整个关联只保留一个rwnd（无论对等方是多宿还是只有一个地址）。
Beginning data transmission into a network with unknown conditions or after a sufficiently long idle period requires SCTP to probe the network to determine the available capacity. The slow-start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer.
在未知条件下或在足够长的空闲时间后开始向网络传输数据需要SCTP探测网络以确定可用容量。为此，在传输开始时或在修复重传计时器检测到的丢失后，使用慢启动算法。
o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o 数据传输之前或足够长的空闲时间之后的初始cwnd必须设置为最小值（4*MTU，最大值（2*MTU，4380字节））。
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU.
o 重传超时后的初始cwnd不得超过1*MTU。
o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window).
o ssthresh的初始值可以任意高（例如，实现可以使用接收器广告窗口的大小）。
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address.
o 只要cwnd大于零，就允许端点在该传输地址上有未处理的cwnd字节数据。
o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST use the slow-start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased; otherwise, the cwnd MUST not be increased. If these conditions are met, then cwnd MUST be increased by, at most, the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99].
o 当cwnd小于或等于ssthresh时，SCTP端点必须使用慢启动算法来增加cwnd，前提是当前拥塞窗口正被充分利用，传入SACK提前累积TSN Ack点，并且数据发送方未处于快速恢复状态。只有满足这三个条件，才能增加cwnd；否则，不得增加cwnd。如果满足这些条件，则cwnd最多必须增加1）已确认的先前未完成数据块的总大小和2）目标的路径MTU中的较小者。此上限可防止[99]中概述的ACK分裂攻击。
In instances where its peer endpoint is multi-homed, if an endpoint receives a SACK that advances its Cumulative TSN Ack Point, then it should update its cwnd (or cwnds) apportioned to the destination addresses to which it transmitted the acknowledged data. However, if
在对等端点为多址的情况下，如果端点接收到一个SACK，该SACK提前了其累积TSN Ack点，则该端点应更新其分配给其传输确认数据的目标地址的cwnd（或cwnd）。然而，如果
the received SACK does not advance the Cumulative TSN Ack Point, the endpoint MUST NOT adjust the cwnd of any of the destination addresses.
接收到的SACK不会提前累计TSN Ack点，端点不得调整任何目标地址的cwnd。
Because an endpoint's cwnd is not tied to its Cumulative TSN Ack Point, as duplicate SACKs come in, even though they may not advance the Cumulative TSN Ack Point an endpoint can still use them to clock out new data. That is, the data newly acknowledged by the SACK diminishes the amount of data now in flight to less than cwnd, and so the current, unchanged value of cwnd now allows new data to be sent. On the other hand, the increase of cwnd must be tied to the Cumulative TSN Ack Point advancement as specified above. Otherwise, the duplicate SACKs will not only clock out new data, but also will adversely clock out more new data than what has just left the network, during a time of possible congestion.
由于端点的cwnd不与其累积TSN确认点相关联，因此当重复的SACK进入时，即使它们可能不会提前累积TSN确认点，端点仍可以使用它们来记录新数据。也就是说，SACK新确认的数据将当前正在传输的数据量减少到小于cwnd，因此cwnd的当前不变值现在允许发送新数据。另一方面，cwnd的增加必须与如上所述的累积TSN确认点前进相关联。否则，在可能出现拥塞的情况下，重复的SACK不仅会记录新数据，而且还会记录比刚刚离开网络的数据更多的新数据。
o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO.
o 当端点不在给定传输地址上传输数据时，传输地址的cwnd应调整为每个RTO的最大值（cwnd/2，4*MTU）。
When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
当cwnd大于ssthresh时，如果发送方具有对应传输地址的cwnd或更多字节的未处理数据，则cwnd应每RTT增加1*MTU。
In practice, an implementation can achieve this goal in the following way:
实际上，实现可以通过以下方式实现此目标：
o partial_bytes_acked is initialized to 0.
o 已确认的部分字节已初始化为0。
o Whenever cwnd is greater than ssthresh, upon each SACK arrival that advances the Cumulative TSN Ack Point, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK including chunks acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks.
o 每当cwnd大于ssthresh时，在每个SACK到达并提前累积TSN Ack点时，将partial_bytes_acked增加该SACK中确认的所有新块的字节总数，包括新累积TSN Ack和Gap Ack块确认的块。
o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd).
o 当partial_bytes_acked等于或大于cwnd且在SACK到达之前，发送方有cwnd或更多字节的未处理数据（即，在SACK到达之前，flightsize大于或等于cwnd），将cwnd增加MTU，并将partial_bytes_acked重置为（partial_bytes_acked-cwnd）。
o Same as in the slow start, when the sender does not transmit DATA on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
o 与慢速启动相同，当发送方不在给定传输地址上传输数据时，传输地址的cwnd应调整为每个RTO的最大值（cwnd/2，4*MTU）。
o When all of the data transmitted by the sender has been acknowledged by the receiver, partial_bytes_acked is initialized to 0.
o 当发送方发送的所有数据都已被接收方确认时，部分确认字节将被初始化为0。
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following:
在检测到来自SACK的数据包丢失时（参见第7.2.4节），端点应执行以下操作：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
and ensure that no more than one SCTP packet will be in flight for that address until the endpoint receives acknowledgement for successful delivery of data to that address.
并确保在端点接收到向该地址成功传递数据的确认之前，该地址的SCTP数据包不会超过一个。
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
在没有数据丢失的情况下，端点执行延迟确认。但是，每当端点注意到到达的TSN序列中有一个漏洞时，它应该在每次数据包到达时发送一个SACK，直到该漏洞被填满为止。
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for two further miss indications (via subsequent SACKs for a total of three missing reports) on the same TSNs before taking action with regard to Fast Retransmit.
每当端点收到指示某些TSN丢失的SACK时，它应该等待同一TSN上的另外两个未命中指示（通过后续SACK，总共三个丢失报告），然后再采取有关快速重新传输的措施。
Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK.
未命中指示应遵循HTNA（最高TSN新确认）算法。对于每个传入SACK，仅在SACK中新确认的最高TSN之前，缺失TSN的未命中指示才会增加。新确认的数据块是SACK中以前未确认的数据块。如果端点处于快速恢复状态，且SACK到达并超过累积TSN确认点，则SACK中报告缺失的所有TSN的未命中指示将增加。
When the third consecutive miss indication is received for a TSN(s), the data sender shall do the following:
当接收到TSN的第三个连续未命中指示时，数据发送方应执行以下操作：
1) Mark the DATA chunk(s) with three miss indications for retransmission.
1) 用三个未命中指示标记数据块，以便重新传输。
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2) 如果不是在快速恢复中，根据第7.2.3节中描述的公式，调整上次向其发送丢失数据块的目标地址的ssthresh和cwnd。
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3) 根据分组被发送到的目的地传输地址的路径MTU的约束，确定标记为重传的最早（即，最低TSN）数据块中有多少将适合于单个分组。调用该值K。在单个数据包中重新传输这些K个数据块。当执行快速重传时，发送方应忽略cwnd的值，并且不应延迟此单个数据包的重传。
4) Restart the T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4) 仅当最后一个SACK确认发送到该地址的最低未完成TSN号，或者端点正在重新传输发送到该地址的第一个未完成数据块时，才重新启动T3 rtx计时器。
5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent Fast Retransmit. Those TSNs marked for retransmission due to the Fast-Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent Fast Retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows.
5) 将数据块标记为正在快速重新传输，因此没有资格进行后续快速重新传输。由于快速重传算法而被标记为重传的那些TSN不适合于携带K个其他TSN的发送数据报，也被标记为不适合后续快速重传。但是，由于它们被标记为要重新传输，因此在cwnd允许的情况下，稍后将尽快重新传输它们。
6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any destinations due to a subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further due to a subsequent Fast Retransmit).
6) 如果不在快速恢复中，请输入快速恢复，并将最高的未完成TSN标记为快速恢复退出点。当SACK确认到并包括此退出点的所有TSN时，将退出快速恢复。在快速恢复中，ssthresh和cwnd不应因后续快速恢复事件而改变任何目的地（即，不应因后续快速重传而进一步减少cwnd）。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Section 7.2.1 and Section 7.2.2 must be applied first.
注：在进行上述调整之前，如果收到的SACK也确认新的数据块并提前累计TSN确认点，则必须首先应用第7.2.1节和第7.2.2节中定义的cwnd调整规则。
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 3 and starting the Fast-Retransmit procedure, the counter resets to 0.
上述的简单实现为SACK报告的每个TSN孔保留一个计数器。对于报告TSN孔的每个连续袋，计数器递增。达到3并开始快速重传过程后，计数器重置为0。
Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP Fast Recovery is achieved automatically with no adjustment to the congestion control window size.
由于SCTP中的cwnd间接限制了未完成TSN的数量，因此TCP快速恢复的效果是自动实现的，而无需调整拥塞控制窗口的大小。
[RFC4821], [RFC1981], and [RFC1191] specify "Packetization Layer Path MTU Discovery", whereby an endpoint maintains an estimate of the maximum transmission unit (MTU) along a given Internet path and refrains from sending packets along that path that exceed the MTU, other than occasional attempts to probe for a change in the Path MTU (PMTU). [RFC4821] is thorough in its discussion of the MTU discovery mechanism and strategies for determining the current end-to-end MTU setting as well as detecting changes in this value.
[RFC4821]、[RFC1981]和[RFC1191]指定“分组化层路径MTU发现”，由此端点保持沿给定因特网路径的最大传输单元（MTU）的估计，并避免沿该路径发送超过MTU的分组，而不是偶尔尝试探测路径MTU（PMTU）中的变化。[RFC4821]详细讨论了确定当前端到端MTU设置以及检测该值变化的MTU发现机制和策略。
An endpoint SHOULD apply these techniques, and SHOULD do so on a per-destination-address basis.
端点应该应用这些技术，并且应该在每个目标地址的基础上应用这些技术。
There are two important SCTP-specific points regarding Path MTU discovery:
关于路径MTU发现，有两个重要的SCTP特定点：
1) SCTP associations can span multiple addresses. An endpoint MUST maintain separate MTU estimates for each destination address of its peer.
1) SCTP关联可以跨越多个地址。端点必须为其对等方的每个目标地址维护单独的MTU估计值。
2) The sender should track an association PMTU that will be the smallest PMTU discovered for all of the peer's destination addresses. When fragmenting messages into multiple parts this association PMTU should be used to calculate the size of each fragment. This will allow retransmissions to be seamlessly sent to an alternate address without encountering IP fragmentation.
2) 发送方应跟踪关联PMTU，该关联PMTU将是为所有对等方的目标地址发现的最小PMTU。当将消息分成多个部分时，应使用此关联PMTU来计算每个片段的大小。这将允许将重传无缝地发送到备用地址，而不会遇到IP碎片。
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint MAY report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
端点应保留一个计数器，记录到其对等方的连续重传总数（这包括到对等方的所有目标传输地址的重传，如果它是多宿的），包括未确认的心跳块。如果该计数器的值超过协议参数关联.Max .ReTrin所表示的极限，则端点应考虑对等端点不可到达，并且停止向其发送更多的数据（从而关联进入关闭状态）。此外，端点可以向上层报告故障，并选择性地报告其出站队列中剩余的所有未完成用户数据。当对等端点变得不可访问时，关联将自动关闭。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT ACK is received from the peer endpoint.
每次确认发送到该对等端点的数据块（通过接收SACK）或从该对等端点接收到心跳ACK时，都应重置计数器。
When its peer endpoint is multi-homed, an endpoint should keep an error counter for each of the destination transport addresses of the peer endpoint.
当其对等端点为多宿时，端点应为对等端点的每个目标传输地址保留一个错误计数器。
Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not acknowledged within an RTO, the error counter of that destination address will be incremented. When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that destination address, the endpoint should mark the destination transport address as inactive, and a notification SHOULD be sent to the upper layer.
每当T3 rtx计时器在任何地址过期时，或者当发送到空闲地址的心跳在RTO内未得到确认时，该目标地址的错误计数器将递增。当错误计数器中的值超过该目标地址的协议参数“Path.Max.Retrans”时，端点应将目标传输地址标记为非活动，并向上层发送通知。
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged with a HEARTBEAT ACK, the endpoint shall clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent). When the peer endpoint is multi-homed and the last chunk sent to it was a retransmission to an alternate address, there exists an ambiguity as to whether or not the acknowledgement should be credited to the address of the last chunk sent. However, this ambiguity does not seem to bear any significant consequence to SCTP behavior. If this ambiguity is undesirable, the transmitter may choose not to clear the error counter if the last chunk sent was a retransmission.
当未完成的TSN被确认或发送到该地址的心跳被心跳ACK确认时，端点应清除上次向其发送数据块（或发送心跳）的目标传输地址的错误计数器。当对等端点是多址的，并且发送给它的最后一个数据块是对备用地址的重新传输时，是否应将确认记入发送的最后一个数据块的地址存在歧义。然而，这种模糊性似乎对SCTP行为没有任何重大影响。如果不希望出现这种歧义，则如果发送的最后一个数据块是重传，则发送器可以选择不清除错误计数器。
Note: When configuring the SCTP endpoint, the user should avoid having the value of 'Association.Max.Retrans' larger than the summation of the 'Path.Max.Retrans' of all the destination addresses for the remote endpoint. Otherwise, all the destination addresses may become inactive while the endpoint still considers the peer endpoint reachable. When this condition occurs, how SCTP chooses to function is implementation specific.
注意：配置SCTP端点时，用户应避免“Association.Max.Retrans”的值大于远程端点所有目标地址的“Path.Max.Retrans”之和。否则，当端点仍然认为对等端点可到达时，所有目标地址都可能变为非活动。当出现这种情况时，SCTP选择如何运行取决于具体的实现。
When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender MAY automatically transmit new packets to an alternate destination address if one exists and is active. If more than one alternate address is active when the primary path is marked inactive, only ONE transport address SHOULD be chosen and used as the new destination transport address.
当主路径被标记为非活动时（例如，由于过度重传），发送方可以自动将新分组发送到备用目的地地址（如果存在并且是活动的）。如果主路径标记为非活动时有多个备用地址处于活动状态，则只应选择一个传输地址并将其用作新的目标传输地址。
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
默认情况下，SCTP端点应该通过周期性地向目标传输地址发送心跳数据块来监视其对等方的空闲目标传输地址的可达性。心跳信号发送可在达到既定状态时开始，并在发送SHUTDOWN或SHUTDOWN-ACK后中断。心跳的接收器必须在进入COOKIE-echood状态（初始发送器）或已建立状态（初始接收器）后，使用心跳确认响应心跳，直到达到SHUTDOWN-SENT状态（SHUTDOWN发送器）或SHUTDOWN-ACK-SENT状态（SHUTDOWN接收器）。
A destination transport address is considered "idle" if no new chunk that can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT, etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to both active and inactive destination addresses.
如果没有可用于更新路径RTT的新块（通常包括第一次传输数据、初始化、COOKIE回送、心跳等），并且在该地址的当前心跳周期内没有心跳发送到目标传输地址，则该地址被视为“空闲”。这适用于活动和非活动目标地址。
The upper layer can optionally initiate the following functions:
上层可以选择启动以下功能：
A) Disable heartbeat on a specific destination transport address of a given association,
A） 在给定关联的特定目标传输地址上禁用检测信号，
B) Change the HB.interval,
B） 改变HB间隔，
C) Re-enable heartbeat on a specific destination transport address of a given association, and
C） 在给定关联的特定目标传输地址上重新启用检测信号，以及
D) Request an on-demand HEARTBEAT on a specific destination transport address of a given association.
D） 在给定关联的特定目标传输地址上请求按需心跳。
The endpoint should increment the respective error counter of the destination transport address each time a HEARTBEAT is sent to that address and not acknowledged within one RTO.
每当心跳信号被发送到目标传输地址且在一个RTO内未被确认时，端点应增加该地址的相应错误计数器。
When the value of this counter reaches the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
当此计数器的值达到协议参数“Path.Max.Retrans”时，端点应将相应的目标地址标记为非活动（如果未如此标记），并且还可以选择向上层报告此目标地址的可达性更改。在此之后，端点应继续此目标地址上的心跳，但应停止增加计数器。
The sender of the HEARTBEAT chunk should include in the Heartbeat Information field of the chunk the current time when the packet is sent out and the destination address to which the packet is sent.
HEARTBEAT区块的发送方应在区块的HEARTBEAT信息字段中包含数据包发送的当前时间和数据包发送到的目标地址。
IMPLEMENTATION NOTE: An alternative implementation of the heartbeat mechanism that can be used is to increment the error counter variable every time a HEARTBEAT is sent to a destination. Whenever a HEARTBEAT ACK arrives, the sender SHOULD clear the error counter of the destination that the HEARTBEAT was sent to. This in effect would clear the previously stroked error (and any other error counts as well).
实现说明：heartbeat机制的另一种实现是，每次将heartbeat发送到目标时，都会增加错误计数器变量。每当检测信号ACK到达时，发送方应清除检测信号发送到的目标的错误计数器。这实际上将清除先前的冲程错误（以及任何其他错误计数）。
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk.
心跳的接收器应立即响应心跳确认，其中包含心跳信息TLV以及任何其他接收到的TLV，这些TLV未经更改地从接收到的心跳块复制而来。
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the association overall error count as well (as defined in Section 8.1).
在收到心跳信号确认后，心跳信号的发送方应清除心跳信号发送到的目标传输地址的错误计数器，并将目标传输地址标记为活动（如果未如此标记）。当由于接收到最新的心跳信号ACK而将非活动目的地地址标记为活动时，端点可以选择性地向上层报告。心跳ACK的接收器还必须清除关联整体错误计数（如第8.1节所定义）。
The receiver of the HEARTBEAT ACK should also perform an RTT measurement for that destination transport address using the time value carried in the HEARTBEAT ACK chunk.
HEARTBEAT ACK的接收器还应该使用HEARTBEAT ACK块中携带的时间值对该目标传输地址执行RTT测量。
On an idle destination address that is allowed to heartbeat, it is recommended that a HEARTBEAT chunk is sent once per RTO of that destination address plus the protocol parameter 'HB.interval', with jittering of +/- 50% of the RTO value, and exponential backoff of the RTO if the previous HEARTBEAT is unanswered.
在允许心跳的空闲目标地址上，建议每个目标地址的RTO加上协议参数“HB.interval”发送一次心跳块，抖动为RTO值的+/-50%，如果前一个心跳未响应，则RTO的指数退避。
A primitive is provided for the SCTP user to change the HB.interval and turn on or off the heartbeat on a given destination address. The heartbeat interval set by the SCTP user is added to the RTO of that destination (including any exponential backoff). Only one heartbeat should be sent each time the heartbeat timer expires (if multiple destinations are idle). It is an implementation decision on how to choose which of the candidate idle destinations to heartbeat to (if more than one destination is idle).
为SCTP用户提供了一个原语，用于更改HB.interval并打开或关闭给定目标地址上的心跳。SCTP用户设置的心跳间隔被添加到该目的地的RTO中（包括任何指数退避）。每次心跳计时器过期时（如果多个目标空闲），只应发送一个心跳。这是一个关于如何选择心跳到哪个候选空闲目的地（如果多个目的地空闲）的实现决策。
Note: When tuning the heartbeat interval, there is a side effect that SHOULD be taken into account. When this value is increased, i.e., the HEARTBEAT takes longer, the detection of lost ABORT messages takes longer as well. If a peer endpoint ABORTs the association for any reason and the ABORT chunk is lost, the local endpoint will only discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT). This must be
注意：在调整心跳间隔时，应该考虑到一个副作用。当该值增加时，即心跳需要更长的时间，检测丢失的中止消息也需要更长的时间。如果对等端点出于任何原因中止关联，并且中止区块丢失，则本地端点将仅通过发送数据区块或心跳区块（从而导致对等方发送另一个中止）来发现丢失的中止。这一定是
considered when tuning the HEARTBEAT timer. If the HEARTBEAT is disabled, only sending DATA to the association will discover a lost ABORT from the peer.
在调整心跳计时器时考虑。如果心跳被禁用，则只有向关联发送数据时才会发现来自对等方的丢失中止。
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
如果SCTP数据包的格式正确（即通过了接收方的CRC32c检查；参见第6.8节），则称其为“出其不意”（OOTB）数据包，但接收方无法识别该数据包所属的关联。
The receiver of an OOTB packet MUST do the following:
OOTB数据包的接收方必须执行以下操作：
1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
1) 如果OOTB数据包发送到非单播地址或来自非单播地址，则接收方应悄悄丢弃该数据包。否则
2) If the OOTB packet contains an ABORT chunk, the receiver MUST silently discard the OOTB packet and take no further action. Otherwise,
2) 如果OOTB数据包包含中止块，则接收方必须默默地丢弃OOTB数据包，并且不采取进一步的操作。否则
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate Tag of the received INIT chunk, and the T bit of the ABORT chunk has to be set to 0, indicating that the Verification Tag is NOT reflected.
3) 如果数据包包含验证标记设置为“0”的INIT块，请按照第5.1节中的说明进行处理。如果出于任何原因，无法正常处理INIT，并且必须发送一个ABORT作为响应，则包含ABORT块的数据包的验证标签必须是接收到的INIT块的inite标签，并且ABORT块的T位必须设置为0，表示未反映验证标签。
4) If the packet contains a COOKIE ECHO in the first chunk, process it as described in Section 5.1. Otherwise,
4) 如果数据包在第一个数据块中包含COOKIE回显，请按照第5.1节所述进行处理。否则
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. Otherwise,
5) 如果数据包包含SHUTDOWN ACK块，则接收方应以SHUTDOWN COMPLETE响应OOTB数据包的发送方。发送关机完成时，OOTB数据包的接收方必须使用关机确认中接收到的验证标签填写出站数据包的验证标签字段，并在区块标志中设置T位，以指示验证标签已被反映。否则
6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver should silently discard the packet and take no further action. Otherwise,
6) 如果数据包包含一个SHUTDOWN COMPLETE块，那么接收方应该悄悄地丢弃该数据包，并且不采取进一步的操作。否则
7) If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK, the SCTP packet should be silently discarded. Otherwise,
7) 如果数据包包含“过时Cookie”错误或Cookie ACK，则应悄悄丢弃SCTP数据包。否则
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T bit in the Chunk Flags to indicate that the Verification Tag is reflected. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8) 接收方应以中止响应OOTB数据包的发送方。发送中止时，OOTB数据包的接收方必须使用OOTB数据包的验证标签字段中的值填写出站数据包的验证标签字段，并在区块标志中设置T位，以指示验证标签已被反映。发送此中止后，OOTB数据包的接收方应丢弃OOTB数据包，不再采取进一步的行动。
The Verification Tag rules defined in this section apply when sending or receiving SCTP packets that do not contain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO (see Section 5.1), ABORT, or SHUTDOWN ACK chunk. The rules for sending and receiving SCTP packets containing one of these chunk types are discussed separately in Section 8.5.1.
当发送或接收不包含INIT、SHUTDOWN COMPLETE、COOKIE ECHO（参见第5.1节）、ABORT或SHUTDOWN ACK块的SCTP数据包时，本节中定义的验证标记规则适用。第8.5.1节分别讨论了发送和接收包含这些块类型之一的SCTP数据包的规则。
When sending an SCTP packet, the endpoint MUST fill in the Verification Tag field of the outbound packet with the tag value in the Initiate Tag parameter of the INIT or INIT ACK received from its peer.
发送SCTP数据包时，端点必须在出站数据包的Verification Tag字段中填入从对等方接收的INIT或INIT ACK的Initiate Tag参数中的标记值。
When receiving an SCTP packet, the endpoint MUST ensure that the value in the Verification Tag field of the received SCTP packet matches its own tag. If the received Verification Tag value does not match the receiver's own tag value, the receiver shall silently discard the packet and shall not process it any further except for those cases listed in Section 8.5.1 below.
当接收SCTP数据包时，端点必须确保接收到的SCTP数据包的验证标签字段中的值与其自己的标签匹配。如果接收到的验证标签值与接收方自己的标签值不匹配，则接收方应悄悄丢弃该数据包，并且不得进一步处理该数据包，但下文第8.5.1节列出的情况除外。
A) Rules for packet carrying INIT:
A） 数据包承载初始化规则：
- The sender MUST set the Verification Tag of the packet to 0.
- 发送方必须将数据包的验证标记设置为0。
- When an endpoint receives an SCTP packet with the Verification Tag set to 0, it should verify that the packet contains only an INIT chunk. Otherwise, the receiver MUST silently discard the packet.
- 当端点接收到验证标记设置为0的SCTP数据包时，它应该验证该数据包是否只包含INIT块。否则，接收方必须悄悄地丢弃数据包。
B) Rules for packet carrying ABORT:
B） 数据包承载中止规则：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- 端点必须始终使用目标端点的标记值（如果已知）填写出站数据包的验证标记字段。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver of an ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果数据包的验证标记字段与其自己的标记匹配且未设置T位，或者如果数据包设置为其对等标记且T位在区块标志中设置，则中止的接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
C) Rules for packet carrying SHUTDOWN COMPLETE:
C） 数据包传送关闭规则完成：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB, then the destination endpoint's tag MUST be used, and the T bit MUST NOT be set. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK, and MUST set the T bit.
- 发送关机完成时，如果关机确认的接收器具有TCB，则必须使用目标端点的标记，并且不得设置T位。只有在不存在TCB的情况下，发送方才应使用关机确认中的验证标签，并且必须设置T位。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- 如果数据包的验证标签字段与其自己的标签匹配且未设置T位，或者数据包设置为其对等标签且T位设置在区块标志中，则关闭完成的接收器应接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。如果端点未处于SHUTDOWN-ACK-SENT状态，则它必须忽略SHUTDOWN COMPLETE。
D) Rules for packet carrying a COOKIE ECHO
D） 携带COOKIE回音的数据包规则
- When sending a COOKIE ECHO, the endpoint MUST use the value of the Initiate Tag received in the INIT ACK.
- 发送COOKIE回显时，端点必须使用INIT ACK中接收的Initiate标记的值。
- The receiver of a COOKIE ECHO follows the procedures in Section 5.
- COOKIE回音的接收器遵循第5节中的程序。
E) Rules for packet carrying a SHUTDOWN ACK
E） 携带关机确认的数据包规则
- If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the procedures in Section 8.4 SHOULD be followed; in other words, it should be treated as an Out Of The Blue packet.
- 如果接收器处于COOKIE-echood或COOKIE-WAIT状态，则应遵循第8.4节中的程序；换句话说，它应该被视为一个出人意料的包。
An endpoint should terminate its association when it exits from service. An association can be terminated by either abort or shutdown. An abort of an association is abortive by definition in that any data pending on either end of the association is discarded and not delivered to the peer. A shutdown of an association is considered a graceful close where all data in queue by either endpoint is delivered to the respective peers. However, in the case of a shutdown, SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on
端点应该在退出服务时终止其关联。关联可以通过中止或关闭来终止。根据定义，关联的中止是中止的，因为任何挂起在关联两端的数据都将被丢弃，而不会传递给对等方。关联的关闭被认为是一个优雅的关闭，其中任一端点的队列中的所有数据都被传递给相应的对等方。然而，在关机的情况下，SCTP不支持半开放状态（如TCP），其中一方可以继续发送数据，而另一端关闭。当任一端点执行关闭时，关联将打开
each peer will stop accepting new data from its user and only deliver data in queue at the time of sending or receiving the SHUTDOWN chunk.
每个对等方将停止接受来自其用户的新数据，并且仅在发送或接收关闭块时在队列中传递数据。
When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see Section 3.3.10.12) SHOULD be present in the ABORT chunk.
当端点决定中止现有关联时，它必须向其对等端点发送中止块。发送方必须在出站数据包中填写对等方的验证标签，并且不得将任何数据块与中止捆绑在一起。如果在上层请求时中止关联，则中止区块中应存在用户发起的中止错误原因（见第3.3.10.12节）。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
端点不得响应包含中止块的任何接收数据包（另请参见第8.4节）。
An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1.
接收中止的端点必须应用第8.5.1节中描述的特殊验证标签检查规则。
After checking the Verification Tag, the receiving endpoint MUST remove the association from its record and SHOULD report the termination to its upper layer. If a User-Initiated Abort error cause is present in the ABORT chunk, the Upper Layer Abort Reason SHOULD be made available to the upper layer.
检查验证标记后，接收端点必须从其记录中删除关联，并应向其上层报告终止。如果中止区块中存在用户发起的中止错误原因，则上层中止原因应可供上层使用。
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an endpoint in an association can gracefully close the association. This will allow all outstanding DATA chunks from the peer of the shutdown initiator to be delivered before the association terminates.
使用SHUTDOWN原语（参见第10.1节），关联中端点的上层可以优雅地关闭关联。这将允许在关联终止之前传递来自关机启动器对等方的所有未完成数据块。
Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters the SHUTDOWN-PENDING state and remains there until all outstanding data has been acknowledged by its peer. The endpoint accepts no new data from its upper layer, but retransmits data to the far end if necessary to fill gaps.
在从其上层接收到SHUTDOWN原语后，端点进入SHUTDOWN-PENDING状态并保持该状态，直到其对等方确认所有未完成的数据。端点不接受来自其上层的新数据，但在必要时将数据重新传输到远端以填补空白。
Once all its outstanding data has been acknowledged, the endpoint shall send a SHUTDOWN chunk to its peer including in the Cumulative TSN Ack field the last sequential TSN it has received from the peer. It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN with the updated last sequential TSN received from its peer.
一旦确认了所有未完成的数据，端点应向其对等方发送一个关机区块，包括在累积TSN Ack字段中从对等方接收的最后一个连续TSN。然后，应启动T2停机计时器并进入停机-发送状态。如果计时器过期，端点必须使用从其对等方接收的更新的最后顺序TSN重新发送关机。
The rules in Section 6.3 MUST be followed to determine the proper timer value for T2-shutdown. To indicate any gaps in TSN, the endpoint may also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet.
必须遵循第6.3节中的规则，以确定T2停机的正确计时器值。为了指示TSN中的任何间隙，端点还可以将SACK与同一SCTP数据包中的SHUTDOWN块捆绑在一起。
An endpoint should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and MUST report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state). The reception of any packet from its peer (i.e., as the peer sends all of its queued DATA chunks) should clear the endpoint's retransmission count and restart the T2-shutdown timer, giving its peer ample opportunity to transmit all of its queued DATA chunks that have not yet been sent.
端点应将关机区块的重新传输次数限制为协议参数“Association.Max.Retrans”。如果超过此阈值，端点应销毁TCB，并且必须向上层报告无法访问的对等端点（因此关联进入关闭状态）。从对等方接收任何数据包（即，当对等方发送其所有排队数据块时）应清除端点的重传计数，并重新启动T2关机计时器，使其对等方有足够的机会发送其所有尚未发送的排队数据块。
Upon reception of the SHUTDOWN, the peer endpoint shall
接收到停机后，对等端点应
- enter the SHUTDOWN-RECEIVED state,
- 进入关机接收状态，
- stop accepting new data from its SCTP user, and
- 停止接受来自其SCTP用户的新数据，以及
- verify, by checking the Cumulative TSN Ack field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN sender.
- 通过检查区块的累积TSN Ack字段，验证关机发送方是否已接收到其所有未完成的数据区块。
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
一旦端点达到SHUTDOWN-RECEIVED状态，它就不能发送SHUTDOWN来响应ULP请求，并且应该放弃后续的SHUTDOWN块。
If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
如果仍然存在未完成的数据块，停堆接收器必须继续遵循第6节中定义的正常数据传输程序，直到所有未完成的数据块都得到确认；但是，关机接收器不得接受来自其SCTP用户的新数据。
While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent.
处于SHUTDOWN-SENT状态时，SHUTDOWN发送方必须立即使用SHUTDOWN chunk响应包含一个或多个数据块的每个接收数据包，并重新启动T2 SHUTDOWN定时器。如果关机区块本身无法确认所有接收到的数据区块（即，可以确认的TSN大于累计TSN，因此TSN序列中存在间隙），或者如果已接收到重复的TSN，则还必须发送SACK区块。
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for the shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
停机发送器也可启动总保护定时器“T5停机保护”，以限制停机顺序的总时间。在此计时器过期时，发送方应通过发送中止块中止关联。如果使用“T5停机保护”计时器，则应将其设置为建议值“RTO.Max”的5倍。
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-
如果关机接收器没有更多未处理的数据块，关机接收器必须发送关机确认并启动T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN ACK.
关闭计时器自身，进入shutdown-ACK-SENT状态。如果计时器过期，端点必须重新发送关机确认。
The sender of the SHUTDOWN ACK should limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and may report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
关机确认的发送方应将关机确认块的重新传输次数限制为协议参数“Association.Max.Retrans”。如果超过此阈值，端点应销毁TCB，并可能向上层报告无法访问的对等端点（因此关联进入关闭状态）。
Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, and remove all record of the association.
收到停机确认后，停机发送方应停止T2停机计时器，向其对等方发送停机完整块，并删除所有关联记录。
Upon reception of the SHUTDOWN COMPLETE chunk, the endpoint will verify that it is in the SHUTDOWN-ACK-SENT state; if it is not, the chunk should be discarded. If the endpoint is in the SHUTDOWN-ACK-SENT state, the endpoint should stop the T2-shutdown timer and remove all knowledge of the association (and thus the association enters the CLOSED state).
接收到SHUTDOWN COMPLETE区块后，端点将验证其是否处于SHUTDOWN-ACK-SENT状态；如果不是，则应丢弃该块。如果端点处于SHUTDOWN-ACK-SENT状态，则端点应停止T2 SHUTDOWN计时器并删除关联的所有知识（因此关联进入关闭状态）。
An endpoint SHOULD ensure that all its outstanding DATA chunks have been acknowledged before initiating the shutdown procedure.
端点应确保在启动关闭过程之前已确认其所有未完成的数据块。
An endpoint should reject any new data request from its upper layer if it is in the SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENT state.
如果端点处于SHUTDOWN-PENDING、SHUTDOWN-SENT、SHUTDOWN-RECEIVE或SHUTDOWN-ACK-SENT状态，则应拒绝来自其上层的任何新数据请求。
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination transport addresses (either in the IP addresses or in the INIT chunk) that belong to this association, it should discard the INIT chunk and retransmit the SHUTDOWN ACK chunk.
如果端点处于SHUTDOWN-ACK-SENT状态，并接收到具有属于此关联的源和目标传输地址（在IP地址或INIT块中）的INIT块（例如，如果SHUTDOWN COMPLETE丢失），则应丢弃INIT块并重新传输SHUTDOWN ACK块。
Note: Receipt of an INIT with the same source and destination IP addresses as used in transport addresses assigned to an endpoint but with a different port number indicates the initialization of a separate association.
注意：接收到与分配给端点的传输地址中使用的源和目标IP地址相同但端口号不同的INIT表示单独关联的初始化。
The sender of the INIT or COOKIE ECHO should respond to the receipt of a SHUTDOWN ACK with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the Verification Tag field of its common header set to the same tag that was received in the SHUTDOWN ACK packet. This is considered an Out of the Blue packet as defined in Section 8.4. The sender of the INIT lets T1-init continue running and remains in the COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration will cause the INIT or COOKIE chunk to be retransmitted and thus start a new association.
INIT或COOKIE ECHO的发送方应在SCTP数据包中独立关机完成后，响应关机确认的接收，其公共头的验证标签字段设置为关机确认数据包中接收到的相同标签。这被视为第8.4节中定义的意外数据包。INIT的发送方允许T1 INIT继续运行，并保持COOKIE-WAIT或COOKIE-echood状态。正常的T1初始化计时器过期将导致重新传输初始化或COOKIE块，从而启动新关联。
If a SHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state, the SHUTDOWN chunk SHOULD be silently discarded.
如果在COOKIE-WAIT或COOKIE-Echosed状态下接收到关机，则关机区块应被静默丢弃。
If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN chunk from its peer, the endpoint shall respond immediately with a SHUTDOWN ACK to its peer, and move into the SHUTDOWN-ACK-SENT state restarting its T2-shutdown timer.
如果端点处于SHUTDOWN-SENT状态并从其对等方接收到SHUTDOWN区块，则该端点应立即向其对等方发出SHUTDOWN ACK响应，并进入SHUTDOWN-ACK-SENT状态，重新启动其T2 SHUTDOWN计时器。
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, and remove all record of the association.
如果端点处于SHUTDOWN-ACK-SENT状态并收到SHUTDOWN ACK，它应停止T2 SHUTDOWN计时器，向其对等方发送SHUTDOWN COMPLETE chunk，并删除关联的所有记录。
The Upper Layer Protocols (ULPs) shall request services by passing primitives to SCTP and shall receive notifications from SCTP for various events.
上层协议（ULP）应通过向SCTP传递原语请求服务，并应接收来自SCTP的各种事件通知。
The primitives and notifications described in this section should be used as a guideline for implementing SCTP. The following functional description of ULP interface primitives is shown for illustrative purposes. Different SCTP implementations may have different ULP interfaces. However, all SCTPs must provide a certain minimum set of services to guarantee that all SCTP implementations can support the same protocol hierarchy.
本节中描述的原语和通知应作为实现SCTP的指南。以下ULP接口原语的功能描述用于说明目的。不同的SCTP实现可能具有不同的ULP接口。但是，所有SCTP必须提供一定的最小服务集，以保证所有SCTP实现都可以支持相同的协议层次结构。
The following sections functionally characterize a ULP/SCTP interface. The notation used is similar to most procedure or function calls in high-level languages.
以下各节从功能上描述了ULP/SCTP接口。使用的符号类似于高级语言中的大多数过程或函数调用。
The ULP primitives described below specify the basic functions that SCTP must perform to support inter-process communication. Individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls.
下面描述的ULP原语指定了SCTP必须执行的基本功能，以支持进程间通信。单个实现必须定义自己的精确格式，并且可以在单个调用中提供基本函数的组合或子集。
A) Initialize
A） 初始化
Format: INITIALIZE ([local port],[local eligible address list])-> local SCTP instance name
格式：初始化（[本地端口]，[本地合格地址列表]）->本地SCTP实例名称
This primitive allows SCTP to initialize its internal data structures and allocate necessary resources for setting up its operation environment. Once SCTP is initialized, ULP can communicate directly with other endpoints without re-invoking this primitive.
此原语允许SCTP初始化其内部数据结构，并为设置其操作环境分配必要的资源。SCTP初始化后，ULP可以直接与其他端点通信，而无需重新调用此原语。
SCTP will return a local SCTP instance name to the ULP.
SCTP将向ULP返回本地SCTP实例名称。
Mandatory attributes:
强制性属性：
None.
没有一个
Optional attributes:
可选属性：
The following types of attributes may be passed along with the primitive:
以下类型的属性可以随原语一起传递：
o local port - SCTP port number, if ULP wants it to be specified.
o 本地端口-SCTP端口号，如果ULP希望指定。
o local eligible address list - an address list that the local SCTP endpoint should bind. By default, if an address list is not included, all IP addresses assigned to the host should be used by the local endpoint.
o 本地合格地址列表-本地SCTP端点应绑定的地址列表。默认情况下，如果不包括地址列表，则本地端点应使用分配给主机的所有IP地址。
IMPLEMENTATION NOTE: If this optional attribute is supported by an implementation, it will be the responsibility of the implementation to enforce that the IP source address field of any SCTP packets sent out by this endpoint contains one of the IP addresses indicated in the local eligible address list.
实现说明：如果实现支持此可选属性，则实现将负责强制此端点发送的任何SCTP数据包的IP源地址字段包含本地合格地址列表中指示的IP地址之一。
B) Associate
B） 联系
Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]
格式：关联（本地SCTP实例名称、目标传输地址、出站流计数）->关联id[，目标传输地址列表][，出站流计数]
This primitive allows the upper layer to initiate an association to a specific peer endpoint.
此原语允许上层启动与特定对等端点的关联。
The peer endpoint shall be specified by one of the transport addresses that defines the endpoint (see Section 1.3). If the local SCTP instance has not been initialized, the ASSOCIATE is considered an error.
对等端点应由定义端点的传输地址之一指定（见第1.3节）。如果本地SCTP实例尚未初始化，则关联将被视为错误。
An association id, which is a local handle to the SCTP association, will be returned on successful establishment of the association. If SCTP is not able to open an SCTP association with the peer endpoint, an error is returned.
关联id是SCTP关联的本地句柄，将在成功建立关联时返回。如果SCTP无法打开与对等端点的SCTP关联，则返回错误。
Other association parameters may be returned, including the complete destination transport addresses of the peer as well as the outbound stream count of the local endpoint. One of the transport addresses from the returned destination addresses will be selected by the local endpoint as default primary path for sending SCTP packets to this peer. The returned "destination transport addr list" can be used by
可以返回其他关联参数，包括对等方的完整目的地传输地址以及本地端点的出站流计数。本地端点将从返回的目标地址中选择一个传输地址作为向该对等方发送SCTP数据包的默认主路径。返回的“目的地传输地址列表”可由
the ULP to change the default primary path or to force sending a packet to a specific transport address.
ULP用于更改默认主路径或强制向特定传输地址发送数据包。
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a blocking function call, the ASSOCIATE primitive can return association parameters in addition to the association id upon successful establishment. If ASSOCIATE primitive is implemented as a non-blocking call, only the association id shall be returned and association parameters shall be passed using the COMMUNICATION UP notification.
实现说明：如果ASSOCIATE原语实现为阻塞函数调用，则ASSOCIATE原语在成功建立时除了返回关联id外，还可以返回关联参数。如果将ASSOCIATE原语实现为非阻塞调用，则只应返回关联id，并使用COMMUNICATION UP通知传递关联参数。
Mandatory attributes:
强制性属性：
o local SCTP instance name - obtained from the INITIALIZE operation.
o 本地SCTP实例名称-从初始化操作中获取。
o destination transport addr - specified as one of the transport addresses of the peer endpoint with which the association is to be established.
o destination transport addr—指定为要与之建立关联的对等端点的传输地址之一。
o outbound stream count - the number of outbound streams the ULP would like to open towards this peer endpoint.
o outbound stream count—ULP希望向该对等端点打开的出站流数。
Optional attributes:
可选属性：
None.
没有一个
C) Shutdown
C） 关闭
Format: SHUTDOWN(association id) -> result
格式：关机（关联id）->结果
Gracefully closes an association. Any locally queued user data will be delivered to the peer. The association will be terminated only after the peer acknowledges all the SCTP packets sent. A success code will be returned on successful termination of the association. If attempting to terminate the association results in a failure, an error code shall be returned.
优雅地结束一个协会。任何本地排队的用户数据都将传递给对等方。只有在对等方确认发送的所有SCTP数据包后，关联才会终止。成功终止关联时将返回成功代码。如果试图终止关联导致失败，则应返回错误代码。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
Optional attributes:
可选属性：
None.
没有一个
D) Abort
D） 流产
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Ungracefully closes an association. Any locally queued user data will be discarded, and an ABORT chunk is sent to the peer. A success code will be returned on successful abort of the association. If attempting to abort the association results in a failure, an error code shall be returned.
笨拙地关闭一个协会。任何本地排队的用户数据都将被丢弃，并向对等方发送一个中止块。成功中止关联时将返回成功代码。如果试图中止关联导致失败，则应返回错误代码。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
Optional attributes:
可选属性：
o Upper Layer Abort Reason - reason of the abort to be passed to the peer.
o 上层中止原因-要传递给对等方的中止原因。
None.
没有一个
E) Send
E） 发送
Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) -> result
格式：发送（关联id、缓冲区地址、字节计数[、上下文][、流id][、生存期][、目标传输地址][、无序标志][、无捆绑标志][、有效负载协议id]）->结果
This is the main method to send user data via SCTP.
这是通过SCTP发送用户数据的主要方法。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o buffer address - the location where the user message to be transmitted is stored.
o 缓冲区地址-存储要传输的用户消息的位置。
o byte count - the size of the user data in number of bytes.
o byte count—用户数据的大小（以字节为单位）。
Optional attributes:
可选属性：
o context - an optional 32-bit integer that will be carried in the sending failure notification to the ULP if the transportation of this user message fails.
o 上下文-如果此用户消息的传输失败，将在向ULP发送失败通知时携带的可选32位整数。
o stream id - to indicate which stream to send the data on. If not specified, stream 0 will be used.
o stream id—指示要在哪个流上发送数据。如果未指定，将使用流0。
o life time - specifies the life time of the user data. The user data will not be sent by SCTP after the life time expires. This parameter can be used to avoid efforts to transmit stale user messages. SCTP notifies the ULP if the data cannot be initiated to transport (i.e., sent to the destination via SCTP's send primitive) within the life time variable. However, the user data will be transmitted if SCTP has attempted to transmit a chunk before the life time expired.
o 生命周期-指定用户数据的生命周期。在生命周期到期后，SCTP不会发送用户数据。此参数可用于避免传输过时的用户消息。如果无法在生命周期变量内启动数据传输（即，通过SCTP的发送原语发送到目的地），SCTP将通知ULP。但是，如果SCTP在生命周期到期之前尝试传输数据块，则将传输用户数据。
IMPLEMENTATION NOTE: In order to better support the data life time option, the transmitter may hold back the assigning of the TSN number to an outbound DATA chunk to the last moment. And, for implementation simplicity, once a TSN number has been assigned the sender should consider the send of this DATA chunk as committed, overriding any life time option attached to the DATA chunk.
实施说明：为了更好地支持数据生命周期选项，发送器可能会将TSN编号分配给出站数据块的操作推迟到最后一刻。而且，为了实现简单性，一旦分配了TSN号码，发送方就应该考虑将该数据块发送为已提交，重写附加到数据块的任何生命期选项。
o destination transport address - specified as one of the destination transport addresses of the peer endpoint to which this packet should be sent. Whenever possible, SCTP should use this destination transport address for sending the packets, instead of the current primary path.
o 目标传输地址-指定为该数据包应发送到的对等端点的目标传输地址之一。只要有可能，SCTP应该使用这个目的地传输地址来发送数据包，而不是使用当前的主路径。
o unordered flag - this flag, if present, indicates that the user would like the data delivered in an unordered fashion to the peer (i.e., the U flag is set to 1 on all DATA chunks carrying this message).
o 无序标志-此标志（如果存在）表示用户希望以无序方式将数据交付给对等方（即，在承载此消息的所有数据块上，U标志设置为1）。
o no-bundle flag - instructs SCTP not to bundle this user data with other outbound DATA chunks. SCTP MAY still bundle even when this flag is present, when faced with network congestion.
o 无绑定标志-指示SCTP不要将此用户数据与其他出站数据块绑定。当面临网络拥塞时，即使存在此标志，SCTP仍可能捆绑。
o payload protocol-id - a 32-bit unsigned integer that is to be passed to the peer indicating the type of payload protocol data being transmitted. This value is passed as opaque data by SCTP.
o 有效负载协议id—要传递给对等方的32位无符号整数，指示正在传输的有效负载协议数据的类型。此值由SCTP作为不透明数据传递。
F) Set Primary
F） 设置主
Format: SETPRIMARY(association id, destination transport address, [source transport address] ) -> result
格式：SETPRIMARY（关联id，目标传输地址，[源传输地址]）->结果
Instructs the local SCTP to use the specified destination transport address as the primary path for sending packets.
指示本地SCTP使用指定的目标传输地址作为发送数据包的主路径。
The result of attempting this operation shall be returned. If the specified destination transport address is not present in the "destination transport address list" returned earlier in an associate command or communication up notification, an error shall be returned.
应返回尝试此操作的结果。如果指定的目的地传输地址不在先前在关联命令或通信启动通知中返回的“目的地传输地址列表”中，则应返回错误。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - specified as one of the transport addresses of the peer endpoint, which should be used as the primary address for sending packets. This overrides the current primary address information maintained by the local SCTP endpoint.
o 目标传输地址-指定为对等端点的传输地址之一，该地址应用作发送数据包的主地址。这将覆盖由本地SCTP端点维护的当前主地址信息。
Optional attributes:
可选属性：
o source transport address - optionally, some implementations may allow you to set the default source address placed in all outgoing IP datagrams.
o 源传输地址—可选地，某些实现可能允许您设置所有传出IP数据报中的默认源地址。
G) Receive
G） 接收
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]
格式：接收（关联id、缓冲区地址、缓冲区大小[，流id]）->字节计数[，传输地址][，流id][，流序列号][，部分标志][，传递号][，有效负载协议id]
This primitive shall read the first user message in the SCTP in-queue into the buffer specified by ULP, if there is one available. The size of the message read, in bytes, will be returned. It may, depending on the specific implementation, also return other information such as the sender's address, the stream id on which it is received, whether there are more messages available for retrieval, etc. For ordered messages, their Stream Sequence Number may also be returned.
该原语应将SCTP in队列中的第一条用户消息读入ULP指定的缓冲区（如果有）。将返回读取的消息大小（以字节为单位）。根据具体实现，它还可以返回其他信息，例如发送者的地址、接收它的流id、是否有更多消息可供检索等。对于已排序的消息，还可以返回它们的流序列号。
Depending upon the implementation, if this primitive is invoked when no message is available the implementation should return an indication of this condition or should block the invoking process until data does become available.
根据实现的不同，如果在没有消息可用时调用此原语，则实现应返回此条件的指示，或者应阻止调用过程，直到数据可用为止。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联id-SCTP关联的本地句柄
o buffer address - the memory location indicated by the ULP to store the received message.
o 缓冲区地址—ULP指示用于存储接收到的消息的内存位置。
o buffer size - the maximum size of data to be received, in bytes.
o 缓冲区大小—要接收的数据的最大大小，以字节为单位。
Optional attributes:
可选属性：
o stream id - to indicate which stream to receive the data on.
o 流id—指示要在哪个流上接收数据。
o Stream Sequence Number - the Stream Sequence Number assigned by the sending SCTP peer.
o 流序列号-发送SCTP对等方分配的流序列号。
o partial flag - if this returned flag is set to 1, then this Receive contains a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分标志-如果此返回标志设置为1，则此接收包含整个消息的部分传递。设置此标志时，流id和流序列号必须伴随此接收。当此标志设置为0时，表示不会再收到此流序列号的传递。
o payload protocol-id - a 32-bit unsigned integer that is received from the peer indicating the type of payload protocol of the received data. This value is passed as opaque data by SCTP.
o 有效负载协议id—从对等方接收的32位无符号整数，指示接收数据的有效负载协议类型。此值由SCTP作为不透明数据传递。
H) Status
H） 地位
Format: STATUS(association id) -> status data
格式：状态（关联id）->状态数据
This primitive should return a data block containing the following information:
此原语应返回包含以下信息的数据块：
association connection state, destination transport address list, destination transport address reachability states, current receiver window size, current congestion window sizes, number of unacknowledged DATA chunks, number of DATA chunks pending receipt, primary path, most recent SRTT on primary path, RTO on primary path, SRTT and RTO on other destination addresses, etc.
关联连接状态、目标传输地址列表、目标传输地址可达性状态、当前接收器窗口大小、当前拥塞窗口大小、未确认数据块数量、待接收数据块数量、主路径、主路径上最近的SRTT、主路径上的RTO、，其他目标地址上的SRTT和RTO等。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
Optional attributes:
可选属性：
None.
没有一个
I) Change Heartbeat
一） 改变心跳
Format: CHANGE HEARTBEAT(association id, destination transport address, new state [,interval]) -> result
格式：更改检测信号（关联id、目标传输地址、新状态[，间隔]）->结果
Instructs the local endpoint to enable or disable heartbeat on the specified destination transport address.
指示本地端点在指定的目标传输地址上启用或禁用检测信号。
The result of attempting this operation shall be returned.
应返回尝试此操作的结果。
Note: Even when enabled, heartbeat will not take place if the destination transport address is not idle.
注意：即使启用，如果目标传输地址不是空闲的，心跳也不会发生。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - specified as one of the transport addresses of the peer endpoint.
o 目标传输地址-指定为对等端点的传输地址之一。
o new state - the new state of heartbeat for this destination transport address (either enabled or disabled).
o 新状态-此目标传输地址的心跳的新状态（已启用或已禁用）。
Optional attributes:
可选属性：
o interval - if present, indicates the frequency of the heartbeat if this is to enable heartbeat on a destination transport address. This value is added to the RTO of the destination transport address. This value, if present, affects all destinations.
o 间隔-如果存在，则指示心跳频率（如果这是为了在目标传输地址上启用心跳）。此值将添加到目标传输地址的RTO中。此值（如果存在）会影响所有目的地。
J) Request HeartBeat
J） 请求心跳
Format: REQUESTHEARTBEAT(association id, destination transport address) -> result
格式：REQUESTHEARTBEAT（关联id，目标传输地址）->结果
Instructs the local endpoint to perform a HeartBeat on the specified destination transport address of the given association. The returned result should indicate whether the transmission of the HEARTBEAT chunk to the destination address is successful.
指示本地端点在给定关联的指定目标传输地址上执行检测信号。返回的结果应该指示心跳块到目标地址的传输是否成功。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - the transport address of the association on which a heartbeat should be issued.
o destination transport address—应在其上发出心跳信号的关联的传输地址。
K) Get SRTT Report
K） 获取SRTT报告
Format: GETSRTTREPORT(association id, destination transport address) -> srtt result
格式：GETSRTTREPORT（关联id，目标传输地址）->srtt结果
Instructs the local SCTP to report the current SRTT measurement on the specified destination transport address of the given association. The returned result can be an integer containing the most recent SRTT in milliseconds.
指示本地SCTP报告给定关联的指定目标传输地址上的当前SRTT测量值。返回的结果可以是一个整数，其中包含以毫秒为单位的最新SRTT。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - the transport address of the association on which the SRTT measurement is to be reported.
o 目的地传输地址—要报告SRTT测量的关联的传输地址。
L) Set Failure Threshold
五十） 设置故障阈值
Format: SETFAILURETHRESHOLD(association id, destination transport address, failure threshold)
格式：SETFAILURETHRESHOLD（关联id、目标传输地址、故障阈值）
-> result
->结果
This primitive allows the local SCTP to customize the reachability failure detection threshold 'Path.Max.Retrans' for the specified destination address.
此原语允许本地SCTP自定义指定目标地址的可达性故障检测阈值“Path.Max.Retrans”。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - the transport address of the association on which the failure detection threshold is to be set.
o 目标传输地址—要设置故障检测阈值的关联的传输地址。
o failure threshold - the new value of 'Path.Max.Retrans' for the destination address.
o 失败阈值-目标地址的“Path.Max.Retrans”的新值。
M) Set Protocol Parameters
M） 设置协议参数
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> result
格式：SETPROTOCOLPARAMETERS（关联id，[，目标传输地址，]协议参数列表）->结果
This primitive allows the local SCTP to customize the protocol parameters.
此原语允许本地SCTP自定义协议参数。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans; see Section 15) that the SCTP user wishes to customize.
o 协议参数列表-SCTP用户希望自定义的协议参数的特定名称和值（例如，Association.Max.Retrans；参见第15节）。
Optional attributes:
可选属性：
o destination transport address - some of the protocol parameters may be set on a per destination transport address basis.
o 目的地传输地址-某些协议参数可根据每个目的地传输地址进行设置。
N) Receive Unsent Message
N） 接收未发送的消息
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])
格式：接收\未发送（数据检索id、缓冲区地址、缓冲区大小[、流id][、流序列号][、部分标志][、有效负载协议id]）
o data retrieval id - the identification passed to the ULP in the failure notification.
o 数据检索id—故障通知中传递给ULP的标识。
o buffer address - the memory location indicated by the ULP to store the received message.
o 缓冲区地址—ULP指示用于存储接收到的消息的内存位置。
o buffer size - the maximum size of data to be received, in bytes.
o 缓冲区大小—要接收的数据的最大大小，以字节为单位。
Optional attributes:
可选属性：
o stream id - this is a return value that is set to indicate which stream the data was sent to.
o stream id-这是一个返回值，设置该值以指示数据发送到哪个流。
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o 流序列号-返回此值，指示与消息关联的流序列号。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分标志-如果此返回标志设置为1，则此消息是整个消息的部分传递。设置此标志时，流id和流序列号必须伴随此接收。当此标志设置为0时，表示不会再收到此流序列号的传递。
o payload protocol-id - The 32 bit unsigned integer that was sent to be sent to the peer indicating the type of payload protocol of the received data.
o payload protocol id—发送给对等方的32位无符号整数，指示接收数据的有效负载协议类型。
o Receive Unacknowledged Message
o 接收未确认的消息
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])
格式：未确认接收（数据检索id、缓冲区地址、缓冲区大小，[，流id][，流序列号][，部分标志][，有效负载协议id]）
o data retrieval id - the identification passed to the ULP in the failure notification.
o 数据检索id—故障通知中传递给ULP的标识。
o buffer address - the memory location indicated by the ULP to store the received message.
o 缓冲区地址—ULP指示用于存储接收到的消息的内存位置。
o buffer size - the maximum size of data to be received, in bytes.
o 缓冲区大小—要接收的数据的最大大小，以字节为单位。
Optional attributes:
可选属性：
o stream id - this is a return value that is set to indicate which stream the data was sent to.
o stream id-这是一个返回值，设置该值以指示数据发送到哪个流。
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o 流序列号-返回此值，指示与消息关联的流序列号。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分标志-如果此返回标志设置为1，则此消息是整个消息的部分传递。设置此标志时，流id和流序列号必须伴随此接收。当此标志设置为0时，表示不会再收到此流序列号的传递。
o payload protocol-id - the 32-bit unsigned integer that was sent to the peer indicating the type of payload protocol of the received data.
o payload protocol id—发送到对等方的32位无符号整数，指示接收数据的有效负载协议类型。
P) Destroy SCTP Instance
P） 销毁SCTP实例
Format: DESTROY(local SCTP instance name)
格式：销毁（本地SCTP实例名称）
o local SCTP instance name - this is the value that was passed to the application in the initialize primitive and it indicates which SCTP instance is to be destroyed.
o local SCTP instance name—这是在initialize原语中传递给应用程序的值，它指示要销毁哪个SCTP实例。
It is assumed that the operating system or application environment provides a means for the SCTP to asynchronously signal the ULP process. When SCTP does signal a ULP process, certain information is passed to the ULP.
假定操作系统或应用程序环境为SCTP提供了一种异步向ULP进程发送信号的方法。当SCTP发出ULP进程信号时，某些信息会传递给ULP。
IMPLEMENTATION NOTE: In some cases, this may be done through a separate socket or error channel.
实现说明：在某些情况下，这可以通过单独的套接字或错误通道完成。
A) DATA ARRIVE notification
A） 数据到达通知
SCTP shall invoke this notification on the ULP when a user message is successfully received and ready for retrieval.
当成功接收并准备检索用户消息时，SCTP应在ULP上调用此通知。
The following may optionally be passed with the notification:
可以选择随通知一起传递以下内容：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o stream id - to indicate which stream the data is received on.
o 流id—指示在哪个流上接收数据。
B) SEND FAILURE notification
B） 发送失败通知
If a message cannot be delivered, SCTP shall invoke this notification on the ULP.
如果无法传递消息，SCTP应在ULP上调用此通知。
The following may optionally be passed with the notification:
可以选择随通知一起传递以下内容：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o 数据检索id—用于检索未发送和未确认数据的标识。
o cause code - indicating the reason of the failure, e.g., size too large, message life time expiration, etc.
o 原因代码-指示故障原因，例如大小过大、消息生命周期过期等。
o context - optional information associated with this message (see D in Section 10.1).
o 上下文-与此消息相关的可选信息（见第10.1节中的D）。
C) NETWORK STATUS CHANGE notification
C） 网络状态更改通知
When a destination transport address is marked inactive (e.g., when SCTP detects a failure) or marked active (e.g., when SCTP detects a recovery), SCTP shall invoke this notification on the ULP.
当目标传输地址标记为非活动（例如，当SCTP检测到故障时）或标记为活动（例如，当SCTP检测到恢复时），SCTP应在ULP上调用此通知。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o destination transport address - this indicates the destination transport address of the peer endpoint affected by the change.
o 目标传输地址-这表示受更改影响的对等端点的目标传输地址。
o new-status - this indicates the new status.
o 新状态-表示新状态。
D) COMMUNICATION UP notification
D） 通信中断通知
This notification is used when SCTP becomes ready to send or receive user messages, or when a lost communication to an endpoint is restored.
当SCTP准备好发送或接收用户消息时，或当恢复与端点的丢失通信时，使用此通知。
IMPLEMENTATION NOTE: If the ASSOCIATE primitive is implemented as a blocking function call, the association parameters are returned as a result of the ASSOCIATE primitive itself. In that case, COMMUNICATION UP notification is optional at the association initiator's side.
实现说明：如果ASSOCIATE原语作为阻塞函数调用实现，则关联参数将作为ASSOCIATE原语本身的结果返回。在这种情况下，在关联发起方一侧，通信启动通知是可选的。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o status - This indicates what type of event has occurred.
o 状态-指示发生了什么类型的事件。
o destination transport address list - the complete set of transport addresses of the peer.
o 目的地传输地址列表-对等方的完整传输地址集。
o outbound stream count - the maximum number of streams allowed to be used in this association by the ULP.
o outbound stream count—ULP允许在此关联中使用的最大流数。
o inbound stream count - the number of streams the peer endpoint has requested with this association (this may not be the same number as 'outbound stream count').
o inbound stream count（入站流计数）—对等端点已请求与此关联的流的数量（这可能与“出站流计数”不同）。
E) COMMUNICATION LOST notification
E） 通信丢失通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
当SCTP完全失去与端点的通信（例如，通过心跳）或检测到端点已执行中止操作时，它应在ULP上调用此通知。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o status - this indicates what type of event has occurred; the status may indicate that a failure OR a normal termination event occurred in response to a shutdown or abort request.
o 状态-指示发生了什么类型的事件；该状态可能表示在响应关机或中止请求时发生了故障或正常终止事件。
The following may be passed with the notification:
以下内容可随通知一起传递：
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o 数据检索id—用于检索未发送和未确认数据的标识。
o last-acked - the TSN last acked by that peer endpoint.
o last acked—该对等端点上次确认的TSN。
o last-sent - the TSN last sent to that peer endpoint.
o last sent—上次发送到该对等端点的TSN。
o Upper Layer Abort Reason - the abort reason specified in case of a user-initiated abort.
o 上层中止原因-用户发起中止时指定的中止原因。
F) COMMUNICATION ERROR notification
F） 通信错误通知
When SCTP receives an ERROR chunk from its peer and decides to notify its ULP, it can invoke this notification on the ULP.
当SCTP从其对等方接收到错误块并决定通知其ULP时，它可以在ULP上调用此通知。
The following can be passed with the notification:
以下内容可随通知一起传递：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o error info - this indicates the type of error and optionally some additional information received through the ERROR chunk.
o 错误信息-这表示错误的类型以及通过错误块接收的一些附加信息（可选）。
G) RESTART notification
G） 重新启动通知
When SCTP detects that the peer has restarted, it may send this notification to its ULP.
当SCTP检测到对等方已重新启动时，它可能会向其ULP发送此通知。
The following can be passed with the notification:
以下内容可随通知一起传递：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
H) SHUTDOWN COMPLETE notification
H） 关闭完成通知
When SCTP completes the shutdown procedures (Section 9.2), this notification is passed to the upper layer.
当SCTP完成关闭程序（第9.2节）时，该通知将传递给上层。
The following can be passed with the notification:
以下内容可随通知一起传递：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
As a common transport protocol designed to reliably carry time-sensitive user messages, such as billing or signaling messages for telephony services, between two networked endpoints, SCTP has the following security objectives.
作为一种通用传输协议，SCTP设计用于在两个联网端点之间可靠地传输时间敏感的用户消息，例如电话服务的计费或信令消息，它具有以下安全目标。
- availability of reliable and timely data transport services
- 提供可靠和及时的数据传输服务
- integrity of the user-to-user information carried by SCTP
- SCTP携带的用户对用户信息的完整性
SCTP may potentially be used in a wide variety of risk situations. It is important for operators of systems running SCTP to analyze their particular situations and decide on the appropriate counter-measures.
SCTP可能用于多种风险情况。运行SCTP的系统操作员分析其特殊情况并决定适当的应对措施非常重要。
Operators of systems running SCTP should consult [RFC2196] for guidance in securing their site.
运行SCTP的系统的操作员应咨询[RFC2196]以获得保护其现场的指导。
The principles of [RFC2196] should be applied to minimize the risk of theft of information or sabotage by insiders. Such procedures include publication of security policies, control of access at the physical, software, and network levels, and separation of services.
[RFC2196]的原则应适用于将信息被盗或内幕人士破坏的风险降至最低。这些程序包括安全策略的发布、物理、软件和网络级别的访问控制以及服务分离。
Where the risk of undetected errors in datagrams delivered by the lower-layer transport services is considered to be too great, additional integrity protection is required. If this additional protection were provided in the application layer, the SCTP header would remain vulnerable to deliberate integrity attacks. While the existing SCTP mechanisms for detection of packet replays are considered sufficient for normal operation, stronger protections are needed to protect SCTP when the operating environment contains significant risk of deliberate attacks from a sophisticated adversary.
如果认为较低层传输服务交付的数据报中未检测到错误的风险太大，则需要额外的完整性保护。如果在应用层中提供了这种额外的保护，则SCTP头仍然容易受到蓄意的完整性攻击。虽然用于检测数据包重放的现有SCTP机制被认为足以正常运行，但当运行环境包含来自复杂对手的蓄意攻击的重大风险时，需要更强的保护来保护SCTP。
The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used when the threat environment requires stronger integrity protections, but does not require confidentiality.
SCTP身份验证扩展SCTP-AUTH[RFC4895]可在威胁环境需要更强的完整性保护，但不需要保密性时使用。
In most cases, the risk of breach of confidentiality applies to the signaling data payload, not to the SCTP or lower-layer protocol overheads. If that is true, encryption of the SCTP user data only might be considered. As with the supplementary checksum service, user data encryption MAY be performed by the SCTP user application. Alternately, the user application MAY use an implementation-specific API to request that the IP Encapsulating Security Payload (ESP) [RFC4303] be used to provide confidentiality and integrity.
在大多数情况下，违反保密性的风险适用于信令数据有效载荷，而不是SCTP或较低层协议开销。如果这是真的，则可能只考虑对SCTP用户数据进行加密。与补充校验和服务一样，用户数据加密可由SCTP用户应用程序执行。或者，用户应用程序可以使用特定于实现的API来请求使用IP封装安全有效载荷（ESP）[RFC4303]来提供机密性和完整性。
Particularly for mobile users, the requirement for confidentiality might include the masking of IP addresses and ports. In this case, ESP SHOULD be used instead of application-level confidentiality. If ESP is used to protect confidentiality of SCTP traffic, an ESP cryptographic transform that includes cryptographic integrity protection MUST be used, because if there is a confidentiality threat there will also be a strong integrity threat.
特别是对于移动用户，保密要求可能包括屏蔽IP地址和端口。在这种情况下，应使用ESP而不是应用程序级机密性。如果ESP用于保护SCTP流量的机密性，则必须使用包含加密完整性保护的ESP加密转换，因为如果存在机密性威胁，也将存在强大的完整性威胁。
Whenever ESP is in use, application-level encryption is not generally required.
每当使用ESP时，通常不需要应用程序级加密。
Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used for key management.
无论在何处提供机密性，都应使用Internet密钥交换协议版本2（IKEv2）[RFC4306]进行密钥管理。
Operators should consult [RFC4301] for more information on the security services available at and immediately above the Internet Protocol layer.
运营商应咨询[RFC4301]以了解更多有关互联网协议层上可用安全服务的信息。
A blind attack is one where the attacker is unable to intercept or otherwise see the content of data flows passing to and from the target SCTP node. Blind denial-of-service attacks may take the form of flooding, masquerade, or improper monopolization of services.
盲攻击是指攻击者无法截获或以其他方式看到进出目标SCTP节点的数据流内容的攻击。盲目拒绝服务攻击可能采取泛滥、伪装或不当垄断服务的形式。
The objective of flooding is to cause loss of service and incorrect behavior at target systems through resource exhaustion, interference with legitimate transactions, and exploitation of buffer-related software bugs. Flooding may be directed either at the SCTP node or at resources in the intervening IP Access Links or the Internet. Where the latter entities are the target, flooding will manifest itself as loss of network services, including potentially the breach of any firewalls in place.
洪水泛滥的目的是通过资源耗尽、干扰合法事务以及利用与缓冲区相关的软件漏洞，在目标系统上造成服务损失和错误行为。洪泛可以被定向到SCTP节点或中间IP接入链路或因特网中的资源。如果后一种实体是目标，洪水将表现为网络服务的损失，包括可能破坏任何现有防火墙。
In general, protection against flooding begins at the equipment design level, where it includes measures such as:
一般而言，防淹保护从设备设计层面开始，包括以下措施：
- avoiding commitment of limited resources before determining that the request for service is legitimate.
- 在确定服务请求是否合法之前避免承诺有限的资源。
- giving priority to completion of processing in progress over the acceptance of new work.
- 优先完成正在进行的加工，而不是接受新工作。
- identification and removal of duplicate or stale queued requests for service.
- 识别和删除重复或过时的排队服务请求。
- not responding to unexpected packets sent to non-unicast addresses.
- 不响应发送到非单播地址的意外数据包。
Network equipment should be capable of generating an alarm and log if a suspicious increase in traffic occurs. The log should provide information such as the identity of the incoming link and source address(es) used, which will help the network or SCTP system operator to take protective measures. Procedures should be in place for the operator to act on such alarms if a clear pattern of abuse emerges.
如果流量出现可疑增加，网络设备应能够生成警报和日志。日志应提供诸如传入链路的标识和使用的源地址等信息，这将有助于网络或SCTP系统运营商采取保护措施。如果出现明显的滥用模式，应制定程序，以便操作员对此类警报采取行动。
The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way startup handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association.
SCTP的设计能够抵抗洪水攻击，特别是在使用四路启动握手、使用cookie延迟响应SCTP节点的资源承诺直到握手完成以及使用验证标签防止将无关数据包插入已建立关联的流中时。
The IP Authentication Header and Encapsulating Security Payload might be useful in reducing the risk of certain kinds of denial-of-service attacks.
IP身份验证标头和封装的安全负载可能有助于降低某些拒绝服务攻击的风险。
The use of the host name feature in the INIT chunk could be used to flood a target DNS server. A large backlog of DNS queries, resolving the host name received in the INIT chunk to IP addresses, could be accomplished by sending INITs to multiple hosts in a given domain. In addition, an attacker could use the host name feature in an indirect attack on a third party by sending large numbers of INITs to random hosts containing the host name of the target. In addition to the strain on DNS resources, this could also result in large numbers of INIT ACKs being sent to the target. One method to protect against this type of attack is to verify that the IP addresses received from DNS include the source IP address of the original INIT. If the list of IP addresses received from DNS does not include the source IP address of the INIT, the endpoint MAY silently discard the INIT. This last option will not protect against the attack against the DNS.
在INIT区块中使用主机名功能可用于淹没目标DNS服务器。将INIT块中接收的主机名解析为IP地址的大量DNS查询积压可以通过向给定域中的多个主机发送INIT来完成。此外，攻击者可以通过向包含目标主机名的随机主机发送大量init来间接攻击第三方。除了DNS资源紧张外，这还可能导致向目标发送大量初始确认。防止此类攻击的一种方法是验证从DNS接收的IP地址是否包括原始INIT的源IP地址。如果从DNS接收的IP地址列表不包括INIT的源IP地址，则端点可能会自动放弃INIT。最后一个选项将无法防止针对DNS的攻击。
Masquerade can be used to deny service in several ways:
伪装可以通过几种方式拒绝服务：
- by tying up resources at the target SCTP node to which the impersonated node has limited access. For example, the target node may by policy permit a maximum of one SCTP association with the impersonated SCTP node. The masquerading attacker may attempt to establish an association purporting to come from the impersonated node so that the latter cannot do so when it requires it.
- 通过在模拟节点具有有限访问权限的目标SCTP节点上绑定资源。例如，目标节点可通过策略允许最多一个SCTP与模拟SCTP节点的关联。伪装攻击者可能试图建立一个声称来自模拟节点的关联，以便后者在需要时无法这样做。
- by deliberately allowing the impersonation to be detected, thereby provoking counter-measures that cause the impersonated node to be locked out of the target SCTP node.
- 通过故意允许检测模拟，从而引发导致模拟节点被锁定在目标SCTP节点之外的对策。
- by interfering with an established association by inserting extraneous content such as a SHUTDOWN request.
- 通过插入无关内容（如关机请求）来干扰已建立的关联。
SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Because the initial exchange is memory-less, no lockout mechanism is triggered by blind masquerade attacks. In addition, the INIT ACK containing the State Cookie is transmitted back to the IP address from which it received the INIT. Thus, the attacker would not receive the INIT ACK containing the State Cookie. SCTP protects against insertion of extraneous packets into the flow of an established association by use of the Verification Tag.
SCTP通过使用四路启动握手通过IP欺骗降低盲伪装攻击的风险。由于初始交换内存较少，因此盲伪装攻击不会触发锁定机制。此外，包含状态Cookie的INIT ACK被传输回它从中接收INIT的IP地址。因此，攻击者不会收到包含状态Cookie的INIT ACK。SCTP通过使用验证标签防止将无关数据包插入到已建立关联的流中。
Logging of received INIT requests and abnormalities such as unexpected INIT ACKs might be considered as a way to detect patterns of hostile activity. However, the potential usefulness of such logging must be weighed against the increased SCTP startup processing it implies, rendering the SCTP node more vulnerable to flooding attacks. Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis.
记录收到的初始化请求和异常（如意外的初始化确认）可能被视为检测恶意活动模式的一种方法。然而，这种日志记录的潜在用途必须与它所暗示的增加的SCTP启动处理进行权衡，从而使SCTP节点更容易受到洪水攻击。如果没有建立日常检查和分析日志的操作程序，日志记录是毫无意义的。
Attacks under this heading are performed openly and legitimately by the attacker. They are directed against fellow users of the target SCTP node or of the shared resources between the attacker and the target node. Possible attacks include the opening of a large number of associations between the attacker's node and the target, or transfer of large volumes of information within a legitimately established association.
此标题下的攻击由攻击者公开合法地执行。它们针对的是目标SCTP节点或攻击者与目标节点之间共享资源的其他用户。可能的攻击包括在攻击者的节点和目标之间打开大量关联，或在合法建立的关联中传输大量信息。
Policy limits should be placed on the number of associations per adjoining SCTP node. SCTP user applications should be capable of detecting large volumes of illegitimate or "no-op" messages within a given association and either logging or terminating the association as a result, based on local policy.
应该对每个相邻SCTP节点的关联数设置策略限制。SCTP用户应用程序应能够检测给定关联内的大量非法或“无操作”消息，并根据本地策略记录或终止关联。
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
如果某些防火墙可以只检查片段化SCTP数据包的第一个片段，并明确地确定它是否对应于INIT块（有关更多信息，请参阅[RFC1858]），则这对它们很有帮助。因此，我们强调第3.1节中所述的要求，（1）不得捆绑INIT块
with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk.
（2）包含INIT块的数据包必须具有零验证标记。此外，我们要求INIT块的接收者必须强制执行这些规则，方法是悄悄地丢弃带有与其他块捆绑在一起的INIT块或具有非零验证标记且包含INIT块的到达数据包。
To provide a non-SCTP-capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C.
为了为不支持SCTP的主机提供与支持SCTP的主机相同级别的攻击防护，所有SCTP堆栈必须实现附录C中所述的ICMP处理。
When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA.
当SCTP堆栈接收到包含多个控制或数据块的数据包，并且该数据包的处理需要发送多个数据块作为响应时，响应数据块的发送方不得发送多个数据包。如果支持捆绑，可以将适合单个数据包的多个响应块捆绑到一个响应数据包中。如果不支持绑定，则发送方不得发送多个响应块，并且必须放弃所有其他响应。请注意，此规则不适用于SACK块，因为SACK块本身就是对数据的响应，SACK不需要更多数据的响应。
An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent.
如果SCTP实现接收到确认尚未发送TSN的SACK，则应中止关联。
An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT ACK as small as possible to reduce the possibility of byte amplification attacks.
由于包含多个错误参数，接收需要大数据包响应的INIT的SCTP实现可以（自行决定）选择省略部分或全部错误参数以减小INIT ACK的大小。由于COOKIE参数的大小和INIT接收器可能向对等方指示的地址数的组合，INIT ACK总是可能大于原始INIT。SCTP实现应尝试使INIT ACK尽可能小，以减少字节放大攻击的可能性。
The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.
[RFC3873]中定义的SCTP MIB模块适用于本文件中规定的协议版本。
This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization.
本节详细介绍了一组建议的参数，这些参数应包含在TCB中，用于实现。本节仅供说明，不应视为实施要求或SCTP TCB内所有参数的详尽列表。每个实现可能需要自己的额外参数进行优化。
Associations: A list of current associations and mappings to the data consumers for each association. This may be in the form of a hash table or other implementation-dependent structure. The data consumers may be process identification information such as file descriptors, named pipe pointer, or table pointers dependent on how SCTP is implemented.
关联：每个关联的当前关联和到数据使用者的映射的列表。这可以是哈希表或其他依赖于实现的结构的形式。根据SCTP的实现方式，数据使用者可以是进程标识信息，例如文件描述符、命名管道指针或表指针。
Secret Key: A secret key used by this endpoint to compute the MAC. This SHOULD be a cryptographic quality random number with a sufficient length. Discussion in RFC 4086 can be helpful in selection of the key.
密钥：此端点用于计算MAC的密钥。这应该是具有足够长度的加密质量随机数。RFC 4086中的讨论有助于选择密钥。
Address List: The list of IP addresses that this instance has bound. This information is passed to one's peer(s) in INIT and INIT ACK chunks.
地址列表：此实例已绑定的IP地址列表。此信息在INIT和INIT ACK块中传递给对等方。
SCTP Port: The local SCTP port number to which the endpoint is bound.
SCTP端口：端点绑定到的本地SCTP端口号。
Peer : Tag value to be sent in every packet and is received Verification: in the INIT or INIT ACK chunk. Tag :
对等：在每个数据包中发送的标记值，并在INIT或INIT ACK块中通过验证接收。标签：
My : Tag expected in every inbound packet and sent in the Verification: INIT or INIT ACK chunk. Tag :
每个入站数据包中都需要My:Tag，并在verify:INIT或INIT ACK块中发送。标签：
State : A state variable indicating what state the association
: is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
: SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
: SHUTDOWN-ACK-SENT.
State : A state variable indicating what state the association
: is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
: SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
: SHUTDOWN-ACK-SENT.
Note: No "CLOSED" state is illustrated since if a association is "CLOSED" its TCB SHOULD be removed.
注：未说明“关闭”状态，因为如果关联“关闭”，则应删除其TCB。
Peer : A list of SCTP transport addresses to which the peer Transport : is bound. This information is derived from the INIT or Address : INIT ACK and is used to associate an inbound packet List : with a given association. Normally, this information : is hashed or keyed for quick lookup and access of the : TCB.
对等：对等传输绑定到的SCTP传输地址列表。此信息来自INIT或Address:INIT ACK，用于将入站数据包列表与给定关联关联起来。通常，此信息是散列的或键入的，以便快速查找和访问：TCB。
Primary : This is the current primary destination transport Path : address of the peer endpoint. It may also specify a : source transport address on this endpoint.
主：这是对等端点的当前主目标传输路径：地址。它还可以在此端点上指定：源传输地址。
Overall : The overall association error count. Error Count :
总体：总体关联错误计数。错误计数：
Overall : The threshold for this association that if the Overall Error : Error Count reaches will cause this association to be Threshold : torn down.
总体：如果总体错误：错误计数达到将导致此关联被阈值：拆除的此关联的阈值。
Peer Rwnd : Current calculated value of the peer's rwnd.
对等机Rwnd：对等机Rwnd的当前计算值。
Next TSN : The next TSN number to be assigned to a new DATA chunk.
: This is sent in the INIT or INIT ACK chunk to the peer
: and incremented each time a DATA chunk is assigned a
: TSN (normally just prior to transmit or during
: fragmentation).
Next TSN : The next TSN number to be assigned to a new DATA chunk.
: This is sent in the INIT or INIT ACK chunk to the peer
: and incremented each time a DATA chunk is assigned a
: TSN (normally just prior to transmit or during
: fragmentation).
Last Rcvd : This is the last TSN received in sequence. This value TSN : is set initially by taking the peer's initial TSN, : received in the INIT or INIT ACK chunk, and : subtracting one from it.
Last Rcvd：这是按顺序接收的最后一个TSN。这个值TSN：最初是通过取对等方的初始TSN，：在INIT或INIT ACK块中接收，并：从中减去一来设置的。
Mapping : An array of bits or bytes indicating which out-of-
Array : order TSNs have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e., no out-of-
: order packets have been received, this array will
: be set to all zero. This structure may be in the
: form of a circular buffer or bit array.
Mapping : An array of bits or bytes indicating which out-of-
Array : order TSNs have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e., no out-of-
: order packets have been received, this array will
: be set to all zero. This structure may be in the
: form of a circular buffer or bit array.
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA
: chunks are out of order, SACKs are not delayed (see
: Section 6).
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA
: chunks are out of order, SACKs are not delayed (see
: Section 6).
Inbound : An array of structures to track the inbound streams, Streams : normally including the next sequence number expected : and possibly the stream number.
Inbound：用于跟踪入站流的结构数组，streams：通常包括预期的下一个序列号，也可能包括流号。
Outbound : An array of structures to track the outbound streams, Streams : normally including the next sequence number to : be sent on the stream.
Outbound：跟踪出站流的结构数组，streams：通常包括流上要发送的下一个序列号。
Reasm Queue : A reassembly queue.
Reasm队列：重组队列。
Local : The list of local IP addresses bound in to this Transport : association. Address : List :
本地：绑定到此传输：关联的本地IP地址列表。地址：名单：
Association : The smallest PMTU discovered for all of the PMTU : peer's transport addresses.
关联：为所有PMTU:peer的传输地址发现的最小PMTU。
For each destination transport address in the peer's address list derived from the INIT or INIT ACK chunk, a number of data elements need to be maintained including:
对于从INIT或INIT ACK块派生的对等方地址列表中的每个目标传输地址，需要维护许多数据元素，包括：
Error Count : The current error count for this destination.
错误计数：此目标的当前错误计数。
Error : Current error threshold for this destination, i.e., Threshold : what value marks the destination down if error count : reaches this value.
错误：此目标的当前错误阈值，即阈值：如果错误计数：达到此值，则什么值会标记目标。
cwnd : The current congestion window.
cwnd：当前拥塞窗口。
ssthresh : The current ssthresh value.
ssthresh：当前ssthresh值。
RTO : The current retransmission timeout value.
RTO：当前重传超时值。
SRTT : The current smoothed round-trip time.
SRTT：当前平滑往返时间。
RTTVAR : The current RTT variation.
RTTVAR：当前RTT变化。
partial : The tracking method for increase of cwnd when in bytes acked : congestion avoidance mode (see Section 7.2.2).
部分：在字节确认时cwnd增加的跟踪方法：拥塞避免模式（见第7.2.2节）。
state : The current state of this destination, i.e., DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, etc.
state：该目的地的当前状态，即DOWN、UP、：ALLOW-HB、NO-HEARTBEAT等。
PMTU : The current known path MTU.
PMTU：当前已知路径MTU。
Per : A timer used by each destination. Destination : Timer :
Per：每个目的地使用的计时器。目的地：计时器：
RTO-Pending : A flag used to track if one of the DATA chunks sent to
: this address is currently being used to compute an
: RTT. If this flag is 0, the next DATA chunk sent to
: this destination should be used to compute an RTT and
: this flag should be set. Every time the RTT
: calculation completes (i.e., the DATA chunk is SACK'd),
: clear this flag.
RTO-Pending : A flag used to track if one of the DATA chunks sent to
: this address is currently being used to compute an
: RTT. If this flag is 0, the next DATA chunk sent to
: this destination should be used to compute an RTT and
: this flag should be set. Every time the RTT
: calculation completes (i.e., the DATA chunk is SACK'd),
: clear this flag.
last-time : The time to which this destination was last sent. : This can be to determine if a HEARTBEAT is needed.
上次时间：上次发送此目标的时间：这可以用来确定是否需要心跳。
Out Queue : A queue of outbound DATA chunks.
Out Queue：出站数据块的队列。
In Queue : A queue of inbound DATA chunks.
In-Queue：入站数据块的队列。
SCTP defines three registries that IANA maintains:
SCTP定义了IANA维护的三个注册表：
- through definition of additional chunk types, - through definition of additional parameter types, or - through definition of additional cause codes within ERROR chunks.
- 通过定义其他块类型，-通过定义其他参数类型，或-通过定义错误块中的其他原因代码。
SCTP requires that the IANA Port Numbers registry be opened for SCTP port registrations, Section 14.5 describes how. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests.
SCTP要求为SCTP端口注册打开IANA端口号注册表，第14.5节描述了如何进行注册。IESG指定的专家评审员支持IANA评估SCTP端口分配请求。
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
根据[RFC2434]中的定义，通过IETF一致行动分配新的区块参数类型代码。区块参数的文档必须包含以下信息：
a) A long and short name for the new chunk type.
a) 新块类型的长名称和短名称。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) 区块结构的详细描述，必须符合第3.2节中定义的基本结构。
c) A detailed definition and description of intended use of each field within the chunk, including the chunk flags if any.
c) 区块内每个字段预期用途的详细定义和说明，包括区块标志（如果有）。
d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.
d) 协议操作中使用新块类型的详细过程描述。
The last chunk type (255) is reserved for future extension if necessary.
最后一个块类型（255）保留供将来扩展（如有必要）。
The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新区块参数类型代码的分配通过[RFC2434]中定义的IETF一致行动完成。区块参数的文档必须包含以下信息：
a) Name of the parameter type.
a) 参数类型的名称。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general Type-Length-Value format described in Section 3.2.1.
b) 参数字段结构的详细说明。该结构必须符合第3.2.1节所述的通用类型长度值格式。
c) Detailed definition of each component of the parameter value.
c) 参数值的每个组件的详细定义。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一块中找到此参数类型的多个实例的指示。
e) Each parameter type MUST be unique across all chunks.
e) 每个参数类型在所有块中都必须是唯一的。
Additional cause codes may be allocated in the range 11 to 65535 through a Specification Required action as defined in [RFC2434]. Provided documentation must include the following information:
可通过[RFC2434]中定义的规范要求的措施，在11至65535范围内分配额外的原因代码。提供的文件必须包括以下信息：
a) Name of the error condition.
a) 错误条件的名称。
b) Detailed description of the conditions under which an SCTP endpoint should issue an ERROR (or ABORT) with this cause code.
b) 详细描述SCTP端点在何种情况下应发出带有此原因代码的错误（或中止）。
c) Expected action by the SCTP endpoint that receives an ERROR (or ABORT) chunk containing this cause code.
c) 接收包含此原因代码的错误（或中止）区块的SCTP终结点的预期操作。
d) Detailed description of the structure and content of data fields that accompany this cause code.
d) 此原因代码附带的数据字段的结构和内容的详细说明。
The initial word (32 bits) of a cause code parameter MUST conform to the format shown in Section 3.3.10, i.e.:
原因码参数的初始字（32位）必须符合第3.3.10节所示的格式，即：
- first 2 bytes contain the cause code value - last 2 bytes contain the length of the cause parameter.
- 前2个字节包含原因代码值，后2个字节包含原因参数的长度。
Except for value 0, which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data.
除SCTP保留的值0表示数据块中未指定的有效负载协议标识符外，SCTP不负责标准化或验证任何有效负载协议标识符；SCTP只是从上层接收标识符，并将其与相应的有效负载数据一起携带。
The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP.
如果需要，上层即SCTP用户应使用IANA标准化任何特定协议标识符。任何特定有效负载协议标识符的使用都超出了SCTP的范围。
SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC2434].
SCTP服务可以使用联系人端口号向未知呼叫者提供服务，如TCP和UDP。因此，IANA被要求使用以下规则打开SCTP的现有端口号注册表，我们打算将其与现有端口号注册程序很好地结合起来。IESG指定的专家评审员支持IANA根据[RFC2434]中定义的程序评估SCTP端口分配请求。
Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered.
端口号分为三个范围。已知端口是从0到1023的端口，注册端口是从1024到49151的端口，动态和/或专用端口是从49152到65535的端口。已知端口和注册端口旨在供需要系统上的默认联系人的服务器应用程序使用。在大多数系统上，已知端口只能由系统（或根）进程或由特权用户执行的程序使用，而注册端口可以由普通用户进程或由普通用户执行的程序使用。动态和/或专用端口用于临时使用，包括客户端端口、带外协商端口，以及注册专用端口之前的应用程序测试；他们不得注册。
The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use an SCTP port before registration completes, we emphasize that IANA will not guarantee registration of
端口号注册表应接受已知端口和已注册端口范围内SCTP端口的注册。未经注册，不得使用知名和注册的端口。尽管在某些情况下（例如将应用程序从TCP移植到SCTP），在注册完成之前使用SCTP端口似乎是很自然的，但我们强调IANA不会保证
particular Well Known and Registered Ports. Registrations should be requested as early as possible.
特定的知名和注册港口。应尽早申请注册。
Each port registration SHALL include the following information:
每个港口注册应包括以下信息：
o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes).
o 一种短端口名，完全由字母（A-Z和A-Z）、数字（0-9）和“-+./*”（不包括引号）中的标点字符组成。
o The port number that is requested for registration.
o 请求注册的端口号。
o A short English phrase describing the port's purpose.
o 描述港口用途的简短英语短语。
o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended.
o 执行注册的人员或实体的姓名和联系信息，以及对定义端口使用的文档的引用。来自IETF工作组的注册只需命名工作组，但建议指定联系人。
Registrants are encouraged to follow these guidelines when submitting a registration.
鼓励注册人在提交注册时遵循这些指南。
o A port name SHOULD NOT be registered for more than one SCTP port number.
o 不应为多个SCTP端口号注册端口名。
o A port name registered for TCP MAY be registered for SCTP as well. Any such registration SHOULD use the same port number as the existing TCP registration.
o 为TCP注册的端口名也可以为SCTP注册。任何此类注册都应使用与现有TCP注册相同的端口号。
o Concrete intent to use a port SHOULD precede port registration. For example, existing TCP ports SHOULD NOT be registered in advance of any intent to use those ports for SCTP.
o 使用港口的具体意图应先于港口注册。例如，在打算将现有TCP端口用于SCTP之前，不应注册这些端口。
This document registers the following ports. (These registrations should be considered models to follow for future allocation requests.)
本文档注册了以下端口。（这些注册应被视为未来分配请求所遵循的模式。）
discard 9/sctp Discard # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
discard 9/sctp Discard # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The discard service, which accepts SCTP connections on port 9, discards all incoming application data and sends no data in response. Thus, SCTP's discard port is analogous to TCP's discard port, and might be used to check the health of an SCTP stack.
discard服务接受端口9上的SCTP连接，丢弃所有传入的应用程序数据，不发送任何数据作为响应。因此，SCTP的丢弃端口类似于TCP的丢弃端口，可用于检查SCTP堆栈的运行状况。
ftp-data 20/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ftp-data 20/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ftp 21/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ftp 21/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
File Transfer Protocol (FTP) data (20) and control ports (21).
文件传输协议（FTP）数据（20）和控制端口（21）。
ssh 22/sctp SSH # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ssh 22/sctp SSH # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The Secure Shell (SSH) remote login service, which allows secure shell logins to a host.
Secure Shell（SSH）远程登录服务，允许安全Shell登录到主机。
http 80/sctp HTTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
http 80/sctp HTTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over SCTP.
基于SCTP的万维网HTTP。
bgp 179/sctp BGP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
bgp 179/sctp BGP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
Border Gateway Protocol over SCTP.
SCTP上的边界网关协议。
https 443/sctp HTTPS # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
https 443/sctp HTTPS # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over TLS/SSL over SCTP.
基于TLS的万维网HTTP/基于SCTP的SSL。
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds HB.Max.Burst - 1
Path.Max.Retrans-5次尝试（每个目标地址）Max.Init.retransmit-8次尝试HB.interval-30秒HB.Max.Burst-1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to customize some of these protocol parameters (see Section 10).
实施说明：SCTP实施可能允许ULP自定义其中一些协议参数（参见第10节）。
Note: RTO.Min SHOULD be set as recommended above.
注：RTO.Min应按照上述建议进行设置。
An undertaking represented by this updated document is not a small feat and represents the summation of the initial authors of RFC 2960: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.
本更新文件所代表的承诺是一项不小的壮举，代表了RFC 2960最初作者的总结：谢Q.谢、K.莫诺、C.夏普、H.施瓦茨鲍尔、T.泰勒、I.雷蒂娜、M.卡拉、张L.和V.帕克森。
Add to that, the comments from everyone who contributed to the original RFC:
除此之外，对原始RFC做出贡献的每个人的评论：
Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their invaluable comments.
马克·奥尔曼、R.J.阿特金森、理查德·班德、斯科特·布拉德纳、史蒂夫·贝洛文、彼得·巴特勒、拉姆·丹图、R.Ezhipavai、迈克·菲斯克、萨利·弗洛伊德、福本阿特寿、马特·霍德雷格、亨利·侯赫、克里斯蒂安·惠特马、加里·莱赫卡、乔纳森·李、大卫·莱曼、约翰·洛尼、丹尼尔·卢安、巴里·纳格伯格、托马斯·纳腾、埃里克·诺德马克、林登·翁、沙马尔·普拉萨德、，开尔文·波特、海因茨·普兰特纳、雅诺·拉贾哈尔梅、雷蒙德·E·里维斯、雷尼·雷维斯、伊万·阿里亚斯·罗德里格斯、A·桑卡尔、格雷格·西德巴顿、布赖恩·怀尔德、拉蒙特·亚罗以及其他许多人的宝贵评论。
Then, add the authors of the SCTP implementor's guide, I. Arias-Rodriguez, K. Poon, A. Caro, and M. Tuexen.
然后，添加SCTP实施者指南的作者I.Arias Rodriguez、K.Poon、A.Caro和M.Tuexen。
Then add to these the efforts of all the subsequent seven SCTP interoperability tests and those who commented on RFC 4460 as shown in its acknowledgements:
然后再加上所有后续七个SCTP互操作性测试的努力，以及那些对RFC 4460发表评论的人，如其致谢中所示：
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
巴里·扎克曼、拉蒙特·雅罗、谢乔宾、王晓鹏、乔纳森·伍德、杰夫·瓦斯科、迈克·特纳、约翰·汤森、萨比娜·托雷特、克里夫·托马斯、铃木优吉、马诺伊·索兰基、斯维雷·斯洛特、基尔·沙阿、扬·罗文斯、本·罗宾逊、雷内·雷维斯、伊恩·佩里安、RC·莫内、桑杰·饶、苏吉特·拉德哈克里希南、海因茨·普兰特纳、比伦·帕特尔、纳塔利·莫利奇、，米奇·迈尔斯、伯恩沃德·梅克内克特、斯坦·麦克莱伦、奥利弗市长、托马斯·奥尔蒂·马丁、桑德普·马哈扬、大卫·莱曼、乔纳森·李、菲利普·朗格洛伊斯、卡尔·克努森、乔·凯勒、加雷思·凯利、安德烈亚斯·荣迈尔、贾纳德·艾扬格、穆苏亚·艾里、约翰·赫伯特、考萨·哈桑、弗雷德·哈塞尔、丹·哈里森、乔恩·格里姆、劳伦特·格劳德、史蒂文·弗尼斯、，福本Atsushi Fukumoto Ken Fujita Steve Dimig，
Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
托马斯·科伦、塞尔坎·西尔、梅丽莎·坎贝尔、彼得·巴特勒、罗布·布伦南、哈什·邦德、布莱恩·比杜洛克、凯特琳·贝斯勒、乔恩·伯杰、罗比·贝内迪克、斯蒂芬·鲍克、桑德普·巴拉尼和罗尼·塞拉。
A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.
特别感谢马克·奥尔曼，他本应该是《max burst》的合著者，但由于技术上的原因，他成功地摆脱了困境。此外，我们还要感谢林登·翁和菲尔·康拉德的宝贵意见和许多贡献。
And finally, you have this document, and those who have commented upon that including Alfred Hoenes and Ronnie Sellars.
最后，你有这份文件，还有那些对此发表评论的人，包括阿尔弗雷德·霍恩斯和罗尼·塞拉斯。
My thanks cannot be adequately expressed to all of you who have participated in the coding, testing, and updating process of this document. All I can say is, Thank You!
我无法向所有参与本文档编码、测试和更新过程的人员表示充分的感谢。我只能说，谢谢你！
Randall Stewart - Editor
兰德尔·斯图尔特-编辑
ECN [RFC3168] describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general, [RFC3168] should be followed with the following exceptions.
ECN[RFC3168]描述了一个提议的IP扩展，该扩展详细说明了在数据报丢失之外感知拥塞的方法。这是实现可以选择添加到SCTP的可选功能。本附录详细说明了实施者在选择实施此功能时需要注意的细微差异。一般情况下，应遵循[RFC3168]，但以下例外情况除外。
Negotiation:
谈判：
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets 2 bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to ensure that both sides are truly ECN capable. For SCTP, this is not necessary. To indicate that an endpoint is ECN capable, an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus has the following format:
[RFC3168]详细说明TCP连接的SYN和SYN-ACK阶段期间ECN的协商。SYN的发送方在TCP标志中设置2位，而SYN-ACK的发送方仅设置1位。这背后的理由是为了确保双方都真正具备ECN能力。对于SCTP，这是不必要的。要指示端点支持ECN，端点应将为ECN保留的TLV添加到INIT和/或INIT ACK块中。此TLV不包含任何参数，因此具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo:
ECN回波：
[RFC3168] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP, this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e., the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows:
[RFC3168]详细说明了接收方在其TCP确认中发送回的特定位，以通知发送方网络中出现的拥塞（CE）位。对于SCTP，通过包括ECNE块来进行相同的指示。该区块包含一个数据元素，即与标有CE位的IP数据报关联的最低TSN，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk.
注意：ECNE被视为控制块。
CWR:
无缝线路：
[RFC3168] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window. This is termed the CWR bit. For SCTP, the same indication is made by including the CWR chunk. This chunk contains one data element, i.e., the TSN number that was sent in the ECNE chunk. This element represents the lowest TSN number in the datagram that was originally marked with the CE bit.
[RFC3168]详细说明发送方在其下一个出站TCP段的报头中发送的特定位，以向其对等方表明其已减少拥塞窗口。这被称为CWR位。对于SCTP，通过包括CWR块来进行相同的指示。此区块包含一个数据元素，即ECNE区块中发送的TSN编号。此元素表示数据报中最初用CE位标记的最低TSN号。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=13 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=13 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The CWR is considered a Control chunk.
注意：CWR被视为一个控制块。
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy Check) is calculated as described for CRC32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+ x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport-level usage.
我们将“反射值”定义为与机器的正常位顺序相反的值。32位CRC（循环冗余校验）按照CRC32c的说明计算，并使用多项式代码0x11EDC6F41（Castagnoli93）或x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0。CRC的计算过程与以太网CRC[ITU32]类似，经过修改以反映传输级别的使用情况。
CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic.
CRC计算使用多项式除法。将消息位字符串M转换为多项式M（X），并使用多项式算法从M（X）计算CRC。
When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high-order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders.
当在链路层使用CRC时，多项式是从在线位顺序推导出来的：第一位“在线”是高阶系数。由于SCTP是一种传输级协议，它无法知道实际的串行媒体位顺序。此外，SCTP端点之间的路径中的不同链路可以使用不同的链路级比特顺序。
A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit-ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first, but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most-significant polynomial coefficient within
因此，必须建立一种约定，将SCTP传输消息映射到多项式，以便进行CRC计算。将SCTP消息映射到多项式的位顺序是，字节先取最高有效位，但在每个字节内，位先取最低有效位。消息的第一个字节提供八个最高系数。在每个字节内，最低有效SCTP位给出了该字节内最高有效多项式系数
that byte, and the most-significant SCTP bit is the least-significant polynomial coefficient in that byte. (This bit ordering is sometimes called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed back into SCTP transport-level byte values, using a consistent mapping.
该字节，最高有效SCTP位是该字节中最低有效多项式系数。（这种位顺序有时称为“镜像”或“反射”[WILLIAMS93]）CRC多项式将使用一致映射转换回SCTP传输级字节值。
The SCTP transport-level CRC value should be calculated as follows:
SCTP传输级CRC值的计算如下：
- CRC input data are assigned to a byte stream, numbered from 0 to N-1.
- CRC输入数据分配给字节流，编号从0到N-1。
- The transport-level byte stream is mapped to a polynomial value. An N-byte PDU with j bytes numbered 0 to N-1 is considered as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being coefficient x^(8(N-j)-1).
- 传输级字节流映射到多项式值。具有编号为0到N-1的j字节的N字节PDU被视为8N-1阶多项式M（x）的系数，其中字节j的位0为系数x^（8（N-j）-8，字节j的位7为系数x^（8（N-j）-1）。
- The CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial.
- CRC余数寄存器用所有1初始化，CRC用同时乘以x^32和除以CRC多项式的算法计算。
- The polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, producing a remainder R(x) of degree less than or equal to 31.
- 该多项式乘以x^32，再除以生成多项式G（x），得到一个小于或等于31次的余数R（x）。
- The coefficients of R(x) are considered a 32-bit sequence.
- R（x）的系数被认为是一个32位序列。
- The bit sequence is complemented. The result is the CRC polynomial.
- 位序列被补充。结果是CRC多项式。
- The CRC polynomial is mapped back into SCTP transport-level bytes. The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, and the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3, and the coefficient of x^0 gives bit 0 of byte 3. The resulting 4-byte transport-level sequence is the 32-bit SCTP checksum value.
- CRC多项式被映射回SCTP传输级字节。x^31的系数给出了SCTP字节0的第7位的值，x^24的系数给出了字节0的第0位的值。x^7的系数给出字节3的第7位，x^0的系数给出字节3的第0位。产生的4字节传输级序列是32位SCTP校验和值。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified such that the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
实施说明：关于CRC的标准文件、教科书和供应商文献通常遵循另一种表述，其中用于保存长除法算法剩余部分的寄存器初始化为零，而不是全部1，并补充消息的前32位。我们公式中使用的长除法算法是这样规定的，即2^32的初始乘法和长除法组合成一个同时运算。对于此类算法，以及长度超过64位的消息，这两种规范完全等效。该等效性是本文件的目的。
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long-division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits.
SCTP的实现者被警告，这两个规范都可以在文献中找到，有时对长除法算法没有限制。本文件中的公式选择允许非SCTP使用，其中相同的CRC算法可用于保护短于64位的消息。
There may be a computational advantage in validating the association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE ECHO. These special-case exchanges must represent small packets and will minimize the effect of the checksum calculation.
在执行校验和之前，根据验证标记验证关联可能具有计算优势，因为在大多数情况下，无效标记将导致与错误校验和相同的操作。这种技术的例外情况是INIT和一些关机完成的交换，以及陈旧的COOKIE回显。这些特殊情况交换必须表示小数据包，并将校验和计算的影响降至最低。
Whenever an ICMP message is received by an SCTP endpoint, the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3.
每当SCTP端点接收到ICMP消息时，必须遵循以下过程，以确保正确利用第3层提供的信息。
ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable".
ICMP1）如果类型字段未设置为“目标不可访问”，则实现可能会忽略所有ICMPv4消息。
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big".
ICMP2）如果类型字段不是“无法到达目的地”、“参数问题”或“数据包太大”，则实现可以忽略所有ICMPv6消息。
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）如果代码未指示“协议不可访问”或“需要分段”，则实现可以忽略任何ICMPv4消息。
ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized Next Header Type Encountered".
ICMP4）如果代码不是“遇到无法识别的下一个标头类型”，则实现可能会忽略所有类型为“参数问题”的ICMPv6消息。
ICMP5) An implementation MUST use the payload of the ICMP message (v4 or v6) to locate the association that sent the message to which ICMP is responding. If the association cannot be found, an implementation SHOULD ignore the ICMP message.
ICMP5）实现必须使用ICMP消息（v4或v6）的有效负载来定位发送ICMP响应的消息的关联。如果找不到关联，则实现应忽略ICMP消息。
ICMP6) An implementation MUST validate that the Verification Tag contained in the ICMP message matches the Verification Tag of the peer. If the Verification Tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the Initiate Tag matches the tag of the
ICMP6）实现必须验证ICMP消息中包含的验证标记是否与对等方的验证标记匹配。如果验证标记不是0且不匹配，则丢弃ICMP消息。如果为0且ICMP消息包含足够的字节，则验证块类型是否为INIT块，以及Initiate标记是否与
peer, continue with ICMP7. If the ICMP message is too short or the chunk type or the Initiate Tag does not match, silently discard the packet.
同级，继续执行ICMP7。如果ICMP消息太短或区块类型或Initiate标记不匹配，则以静默方式丢弃该数据包。
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery.
ICMP7）如果ICMP消息是v6“数据包太大”或v4“需要碎片”，则实现可以按照为路径MTU发现定义的方式处理此信息。
ICMP8) If the ICMP code is an "Unrecognized Next Header Type Encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in the COOKIE-WAIT state, handle the ICMP message like an ABORT.
ICMP8) If the ICMP code is an "Unrecognized Next Header Type Encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in the COOKIE-WAIT state, handle the ICMP message like an ABORT.translate error, please retry
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）如果ICMPv6代码为“目的地不可访问”，则实现可能会将目的地标记为不可访问状态，或者增加路径错误计数器。
Note that these procedures differ from [RFC1122] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port-unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP.
请注意，这些过程不同于[RFC1122]，不同于其处理端口不可访问消息的要求，也不同于实现必须中止关联以响应“协议不可访问”消息的要求。不处理端口不可访问消息，因为实现将发送中止，而不是端口不可访问。对“协议不可访问”消息进行更严格的处理是因为不支持SCTP的主机存在安全问题。
The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide. While neither especially slow nor especially fast, as software table-lookup CRCs go, it has the advantage of working on both big-endian and little-endian CPUs, using the same (host-order) lookup tables, and using only the predefined ntohl() and htonl() operations. The code is somewhat modified from [WILLIAMS93], to ensure portability between big-endian and little-endian architectures. (Note that if the byte endian-ness of the target architecture is known to be little-endian, the final bit-reversal and byte-reversal steps can be folded into a single operation.)
以下非规范性示例代码取自开源CRC生成器[WILLIAMS93]，使用“镜像”技术，生成一个包含256个条目的SCTP CRC32c查找表，每个条目宽32位。虽然软件查表CRC既不特别慢，也不特别快，但它的优点是使用相同的（主机顺序）查表，并且只使用预定义的ntohl（）和htonl（）操作，同时在大端和小端CPU上工作。该代码在某种程度上是从[WILLIAMS93]修改而来的，以确保big-endian和little-endian架构之间的可移植性。（请注意，如果已知目标体系结构的字节结束符是小结束符，则最后的位反转和字节反转步骤可以折叠为一个操作。）
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
无符号长crc_c[256]=[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 7 7 7 A79A7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1111111111111111111福福1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1，0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 10 10 10 10 10 10 7 7 7 7 7 7 7 7 7 7 7 7 7 7，0 0 0 0 0 0 5 5 5 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 7BBCEF57L、0x89D76C54L、0x5D1D08BFL、0xAF768BCL、0xBC267848L、0x4E4DFB4BL、0x20BD8EDEL、0xD2D60DDDL、0xC186FE29L、0x33ED7D2AL、0xE72719C1L、0x154C9AC2L、0x061C6936L、0xF477EA35L、0xAA64D611L、0x580F5512L、0x4B5FA6L、0xB93425E5L、0x6DFE410EL、0x6DFE49F95C20DL、0x8CC539L、0xC27EA892L、0xB1236L、，
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
10月17日，0月4851927DL，10月15日10月18日18号。10月18日18岁，0月4851927DL，10月15日18月18日18号。10月15日16号18号18号，10月18号10号10号10号10号10号10号10号10号10号10号10号10号10号10号10号19号19号19号19号19号19号19号19号19号19号19号18号18号19，10号18号18号18号18号18号18号18号18号18号18号18号18号19，10，10号18号18号18号18号18号18号18号18号18号18号10，10，10号18号18号18号18号18号18号18号10，10，10号19号19号19号10，10号10，10号10号10号10号10号10，10号10号10号10号10，10号10，10号A29BL，0x1F682198L、0x5125DAD3L、0xA34E59D0L、0xB01EAA24L、0x42752927L、0x96BF4DCL、0x64D4CECFL、0x77843D3BL、0x85EFBE38L、0xDBFC821CL、0x2997011FL、0x3AC7F2EBL、0xC8AC71E8L、0x1C661503L、0xEE0D9600L、0xFD5D65D6F7L、0x61C69362L、0x931L、0x931L、0xFDE395L、0x72605CAD7L、0x377B5L、0x677B757L、0x677B7L、，0x197448AEL、0x0A24BB5AL、0xF84F3859L、0x2C855CB2L、0xDEEEDB1L、0xCDBE2C45L、0x3FD5AF46L、0x7198540DL、0x83F3D70EL、0x90A324FAL、0x62C8A7F9L、0xB602C312L、0x44694011L、0x5739B3E5L、0xA55230E6L、0xFB410CC2L、0x092A8FC1L、0x1A7A7C35L、0xE811F36L、0x3CDB9DL、0xCE8BL、0xB682BL、0xB688BL、0xB638BL，0x91A6C88CL、0x456CAC67L、0xB7072F64L、0xA457DC90L、0x563C5F93L、0x082F63B7L、0xFA44E0B4L、0xE9141340L、0x1B7F9043L、0xCFB5F4A8L、0x3DDE77FFL、0x2E8E845FL、0xDCE5075CL、0x92A8FC17L、0x60C37F14L、0x73938CE0L、0x81F80FE3L、0x55326BL、0xA759E80BL、0xFC6298L、，
0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0x18711A448L，0xEA187111A7DBL，0xF94AD42FL，0x0B215722CL，0xDFEB33C7L，0x2D8080B0C4C4L，0x1871871114141414141414141414141414141414141414141414141414177777777777L，0xDfEBEBB7777C777C7C7L，0xDEBEBEBE77C777C7L，0x2DEBEBEBEBB777777C77C7L，0x2D0DB77777C777L，0x2D000000D8080808080000000DBBBBBBB777C7C777777C7777L，0x2D00000000000000532E023EL，10.66DF1622L，0.38CC222L，0.38CC2 2 0 0 0 B6565622L，0.38CC2 2 2 0 0 2 2建建交2 06L，0.CAA7A905L，0.CAA7 AAAA905L，0 0 0 0-CAAAAAAA4545454510 10 10 10 10-18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18层，10 10 10 16 16 16层，10 10 10 10 10 10 161616161616161616161616161616161616161616161616161616161616161616161616LLLL6 6-66666666666666666LLL4L，0x66FF5999E3L，0xD3D33-ABL，0x21 B8622A8L，0x32E8915CL，0x32E8915CL，0xC08383125FL，0x1449766B4L，0x267666666666666-7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6升，0x6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 FF2L，0x37FACCF1L、0x69E9F0D5L、0x9B8273D6L、0x88D28022L、0x7AB90321L、0xAE7367CAL、0x5C18E4C9L、0x4F48173DL、0xBD23943EL、0xF36E6F75L、0x0105EC76L、0x12551F82L、0xE03E9C81L、，
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, };
0x34F4F86AL、0xC69F7B69L、0xD5CF889DL、0x27A40B9EL、0x79B737BAL、0x8BDCB4B9L、0x988C474DL、0x6AE7C44EL、0xBE2DA0A5L、0x4C4623A6L、0x5F16D052L、0xAD7D5351L、}；
#endif
#恩迪夫
/* Example of table build routine */
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
rb=反映32（指数）；
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
{
int i;
main ()
{
int i;
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
/* Example of crc insertion */
/* Example of crc insertion */
#include "crc32cr.h"
#包括“crc32cr.h”
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
References
工具书类
Normative References
规范性引用文件
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion".", ITU-T section 8.1.1.6.2.
[ITU32]“ITU-T建议V.42，“使用异步到同步转换的DCE纠错程序”，ITU-T第8.1.1.6.2节。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004.
[RFC3873]Pastor，J.和M.Belinchon，“流控制传输协议（SCTP）管理信息库（MIB）”，RFC3873，2004年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
Informative References
资料性引用
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5- 21, July 1996.
[FALL96]Fall，K.和S.Floyd，“塔霍河、雷诺和萨克TCP基于模拟的比较”，SIGCOMM'99 V.26 N.3第5-21页，1996年7月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，和T.Anderson，“行为不正常接收器的TCP拥塞控制”，ACM计算机通信评论29（5），1999年10月。
[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM'99 , 1999.
[ALLMAN99]Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，SIGCOMM'991999。
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS", Internet publication, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm, August 1993.
[WILLIAMS93]Williams，R.，“CRC错误检测算法的无痛指南”，互联网出版物，http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm，1993年8月。
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
[RFC0813]Clark，D.，“TCP中的窗口和确认策略”，RFC 813，1982年7月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, April 2006.
[RFC4460]Stewart，R.，Arias Rodriguez，I.，Poon，K.，Caro，A.，和M.Tuexen，“流控制传输协议（SCTP）规范勘误表和问题”，RFC 44602006年4月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
Editor's Address
编辑地址
Randall R. Stewart 4875 Forest Drive Suite 200 Columbia, SC 29206 US
Randall R.Stewart 4875森林大道套房200号哥伦比亚，SC 29206美国
EMail: rrs@cisco.com
EMail: rrs@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.