Network Working Group R. Stewart
Request for Comments: 2960 Q. Xie
Category: Standards Track Motorola
K. Morneault
C. Sharp
Cisco
H. Schwarzbauer
Siemens
T. Taylor
Nortel Networks
I. Rytina
Ericsson
M. Kalla
Telcordia
L. Zhang
UCLA
V. Paxson
ACIRI
October 2000
Network Working Group R. Stewart
Request for Comments: 2960 Q. Xie
Category: Standards Track Motorola
K. Morneault
C. Sharp
Cisco
H. Schwarzbauer
Siemens
T. Taylor
Nortel Networks
I. Rytina
Ericsson
M. Kalla
Telcordia
L. Zhang
UCLA
V. Paxson
ACIRI
October 2000
Stream Control Transmission Protocol
流控制传输协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications.
本文档描述了流控制传输协议（SCTP）。SCTP设计用于通过IP网络传输PSTN信令消息，但具有更广泛的应用能力。
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
SCTP是一种可靠的传输协议，在IP等无连接分组网络上运行。它向用户提供以下服务：
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.
-- sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual user
messages,
-- optional bundling of multiple user messages into a single SCTP
packet, and
-- network-level fault tolerance through supporting of multi-
homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.
SCTP的设计包括适当的拥塞避免行为以及对洪水和伪装攻击的抵抗。
Table of Contents
目录
1. Introduction.................................................. 5
1.1 Motivation.................................................. 6
1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP..................................... 7
1.3.1 Association Startup and Takedown........................ 8
1.3.2 Sequenced Delivery within Streams....................... 9
1.3.3 User Data Fragmentation................................. 9
1.3.4 Acknowledgement and Congestion Avoidance................ 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 Packet Validation....................................... 10
1.3.7 Path Management......................................... 11
1.4 Key Terms................................................... 11
1.5 Abbreviations............................................... 15
1.6 Serial Number Arithmetic.................................... 15
2. Conventions.................................................... 16
3. SCTP packet Format............................................ 16
3.1 SCTP Common Header Field Descriptions....................... 17
3.2 Chunk Field Descriptions.................................... 18
3.2.1 Optional/Variable-length Parameter Format............... 20
3.3 SCTP Chunk Definitions...................................... 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable Length Parameters.............. 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable Length Parameters.............. 33
3.3.4 Selective Acknowledgement (SACK)........................ 33
3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
3.3.7 Abort Association (ABORT)............................... 39
3.3.8 Shutdown Association (SHUTDOWN)......................... 40
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
3.3.10 Operation Error (ERROR)................................ 41
3.3.10.1 Invalid Stream Identifier.......................... 42
3.3.10.2 Missing Mandatory Parameter........................ 43
3.3.10.3 Stale Cookie Error................................. 43
3.3.10.4 Out of Resource.................................... 44
3.3.10.5 Unresolvable Address............................... 44
3.3.10.6 Unrecognized Chunk Type............................ 44
3.3.10.7 Invalid Mandatory Parameter........................ 45
3.3.10.8 Unrecognized Parameters............................ 45
3.3.10.9 No User Data....................................... 46
3.3.10.10 Cookie Received While Shutting Down............... 46
3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
4. SCTP Association State Diagram................................. 48
1. Introduction.................................................. 5
1.1 Motivation.................................................. 6
1.2 Architectural View of SCTP.................................. 6
1.3 Functional View of SCTP..................................... 7
1.3.1 Association Startup and Takedown........................ 8
1.3.2 Sequenced Delivery within Streams....................... 9
1.3.3 User Data Fragmentation................................. 9
1.3.4 Acknowledgement and Congestion Avoidance................ 9
1.3.5 Chunk Bundling ......................................... 10
1.3.6 Packet Validation....................................... 10
1.3.7 Path Management......................................... 11
1.4 Key Terms................................................... 11
1.5 Abbreviations............................................... 15
1.6 Serial Number Arithmetic.................................... 15
2. Conventions.................................................... 16
3. SCTP packet Format............................................ 16
3.1 SCTP Common Header Field Descriptions....................... 17
3.2 Chunk Field Descriptions.................................... 18
3.2.1 Optional/Variable-length Parameter Format............... 20
3.3 SCTP Chunk Definitions...................................... 21
3.3.1 Payload Data (DATA)..................................... 22
3.3.2 Initiation (INIT)....................................... 24
3.3.2.1 Optional or Variable Length Parameters.............. 26
3.3.3 Initiation Acknowledgement (INIT ACK)................... 30
3.3.3.1 Optional or Variable Length Parameters.............. 33
3.3.4 Selective Acknowledgement (SACK)........................ 33
3.3.5 Heartbeat Request (HEARTBEAT)........................... 37
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38
3.3.7 Abort Association (ABORT)............................... 39
3.3.8 Shutdown Association (SHUTDOWN)......................... 40
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40
3.3.10 Operation Error (ERROR)................................ 41
3.3.10.1 Invalid Stream Identifier.......................... 42
3.3.10.2 Missing Mandatory Parameter........................ 43
3.3.10.3 Stale Cookie Error................................. 43
3.3.10.4 Out of Resource.................................... 44
3.3.10.5 Unresolvable Address............................... 44
3.3.10.6 Unrecognized Chunk Type............................ 44
3.3.10.7 Invalid Mandatory Parameter........................ 45
3.3.10.8 Unrecognized Parameters............................ 45
3.3.10.9 No User Data....................................... 46
3.3.10.10 Cookie Received While Shutting Down............... 46
3.3.11 Cookie Echo (COOKIE ECHO).............................. 46
3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48
4. SCTP Association State Diagram................................. 48
5. Association Initialization..................................... 52
5.1 Normal Establishment of an Association...................... 52
5.1.1 Handle Stream Parameters................................ 54
5.1.2 Handle Address Parameters............................... 54
5.1.3 Generating State Cookie................................. 56
5.1.4 State Cookie Processing................................. 57
5.1.5 State Cookie Authentication............................. 57
5.1.6 An Example of Normal Association Establishment.......... 58
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK.............................................. 60
5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or COOKIE-ECHOED States................................. 60
5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
5.2.3 Unexpected INIT ACK..................................... 61
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
5.2.4.1 An Example of a Association Restart................. 64
5.2.5 Handle Duplicate COOKIE ACK............................. 66
5.2.6 Handle Stale COOKIE Error............................... 66
5.3 Other Initialization Issues................................. 67
5.3.1 Selection of Tag Value.................................. 67
6. User Data Transfer............................................. 67
6.1 Transmission of DATA Chunks................................. 69
6.2 Acknowledgement on Reception of DATA Chunks................. 70
6.2.1 Tracking Peer's Receive Buffer Space.................... 73
6.3 Management Retransmission Timer............................. 75
6.3.1 RTO Calculation......................................... 75
6.3.2 Retransmission Timer Rules.............................. 76
6.3.3 Handle T3-rtx Expiration................................ 77
6.4 Multi-homed SCTP Endpoints.................................. 78
6.4.1 Failover from Inactive Destination Address.............. 79
6.5 Stream Identifier and Stream Sequence Number................ 80
6.6 Ordered and Unordered Delivery.............................. 80
6.7 Report Gaps in Received DATA TSNs........................... 81
6.8 Adler-32 Checksum Calculation............................... 82
6.9 Fragmentation............................................... 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP Congestion Control................ 85
7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
7.2.1 Slow-Start.............................................. 87
7.2.2 Congestion Avoidance.................................... 89
7.2.3 Congestion Control...................................... 89
7.2.4 Fast Retransmit on Gap Reports.......................... 90
7.3 Path MTU Discovery.......................................... 91
8. Fault Management.............................................. 92
8.1 Endpoint Failure Detection.................................. 92
8.2 Path Failure Detection...................................... 92
5. Association Initialization..................................... 52
5.1 Normal Establishment of an Association...................... 52
5.1.1 Handle Stream Parameters................................ 54
5.1.2 Handle Address Parameters............................... 54
5.1.3 Generating State Cookie................................. 56
5.1.4 State Cookie Processing................................. 57
5.1.5 State Cookie Authentication............................. 57
5.1.6 An Example of Normal Association Establishment.......... 58
5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK.............................................. 60
5.2.1 Handle Duplicate INIT in COOKIE-WAIT
or COOKIE-ECHOED States................................. 60
5.2.2 Unexpected INIT in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61
5.2.3 Unexpected INIT ACK..................................... 61
5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62
5.2.4.1 An Example of a Association Restart................. 64
5.2.5 Handle Duplicate COOKIE ACK............................. 66
5.2.6 Handle Stale COOKIE Error............................... 66
5.3 Other Initialization Issues................................. 67
5.3.1 Selection of Tag Value.................................. 67
6. User Data Transfer............................................. 67
6.1 Transmission of DATA Chunks................................. 69
6.2 Acknowledgement on Reception of DATA Chunks................. 70
6.2.1 Tracking Peer's Receive Buffer Space.................... 73
6.3 Management Retransmission Timer............................. 75
6.3.1 RTO Calculation......................................... 75
6.3.2 Retransmission Timer Rules.............................. 76
6.3.3 Handle T3-rtx Expiration................................ 77
6.4 Multi-homed SCTP Endpoints.................................. 78
6.4.1 Failover from Inactive Destination Address.............. 79
6.5 Stream Identifier and Stream Sequence Number................ 80
6.6 Ordered and Unordered Delivery.............................. 80
6.7 Report Gaps in Received DATA TSNs........................... 81
6.8 Adler-32 Checksum Calculation............................... 82
6.9 Fragmentation............................................... 83
6.10 Bundling .................................................. 84
7. Congestion Control .......................................... 85
7.1 SCTP Differences from TCP Congestion Control................ 85
7.2 SCTP Slow-Start and Congestion Avoidance.................... 87
7.2.1 Slow-Start.............................................. 87
7.2.2 Congestion Avoidance.................................... 89
7.2.3 Congestion Control...................................... 89
7.2.4 Fast Retransmit on Gap Reports.......................... 90
7.3 Path MTU Discovery.......................................... 91
8. Fault Management.............................................. 92
8.1 Endpoint Failure Detection.................................. 92
8.2 Path Failure Detection...................................... 92
8.3 Path Heartbeat.............................................. 93
8.4 Handle "Out of the blue" Packets............................ 95
8.5 Verification Tag............................................ 96
8.5.1 Exceptions in Verification Tag Rules.................... 97
9. Termination of Association..................................... 98
9.1 Abort of an Association..................................... 98
9.2 Shutdown of an Association.................................. 98
10. Interface with Upper Layer....................................101
10.1 ULP-to-SCTP................................................101
10.2 SCTP-to-ULP................................................111
11. Security Considerations.......................................114
11.1 Security Objectives........................................114
11.2 SCTP Responses To Potential Threats........................115
11.2.1 Countering Insider Attacks.............................115
11.2.2 Protecting against Data Corruption in the Network......115
11.2.3 Protecting Confidentiality.............................115
11.2.4 Protecting against Blind Denial of Service Attacks.....116
11.2.4.1 Flooding...........................................116
11.2.4.2 Blind Masquerade...................................118
11.2.4.3 Improper Monopolization of Services................118
11.3 Protection against Fraud and Repudiation...................119
12. Recommended Transmission Control Block (TCB) Parameters.......120
12.1 Parameters necessary for the SCTP instance.................120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport Address Data.................................122
12.4 General Parameters Needed..................................123
13. IANA Considerations...........................................123
13.1 IETF-defined Chunk Extension...............................123
13.2 IETF-defined Chunk Parameter Extension.....................124
13.3 IETF-defined Additional Error Causes.......................124
13.4 Payload Protocol Identifiers...............................125
14. Suggested SCTP Protocol Parameter Values......................125
15. Acknowledgements..............................................126
16. Authors' Addresses............................................126
17. References....................................................128
18. Bibliography..................................................129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
8.3 Path Heartbeat.............................................. 93
8.4 Handle "Out of the blue" Packets............................ 95
8.5 Verification Tag............................................ 96
8.5.1 Exceptions in Verification Tag Rules.................... 97
9. Termination of Association..................................... 98
9.1 Abort of an Association..................................... 98
9.2 Shutdown of an Association.................................. 98
10. Interface with Upper Layer....................................101
10.1 ULP-to-SCTP................................................101
10.2 SCTP-to-ULP................................................111
11. Security Considerations.......................................114
11.1 Security Objectives........................................114
11.2 SCTP Responses To Potential Threats........................115
11.2.1 Countering Insider Attacks.............................115
11.2.2 Protecting against Data Corruption in the Network......115
11.2.3 Protecting Confidentiality.............................115
11.2.4 Protecting against Blind Denial of Service Attacks.....116
11.2.4.1 Flooding...........................................116
11.2.4.2 Blind Masquerade...................................118
11.2.4.3 Improper Monopolization of Services................118
11.3 Protection against Fraud and Repudiation...................119
12. Recommended Transmission Control Block (TCB) Parameters.......120
12.1 Parameters necessary for the SCTP instance.................120
12.2 Parameters necessary per association (i.e. the TCB)........120
12.3 Per Transport Address Data.................................122
12.4 General Parameters Needed..................................123
13. IANA Considerations...........................................123
13.1 IETF-defined Chunk Extension...............................123
13.2 IETF-defined Chunk Parameter Extension.....................124
13.3 IETF-defined Additional Error Causes.......................124
13.4 Payload Protocol Identifiers...............................125
14. Suggested SCTP Protocol Parameter Values......................125
15. Acknowledgements..............................................126
16. Authors' Addresses............................................126
17. References....................................................128
18. Bibliography..................................................129
Appendix A .......................................................131
Appendix B .......................................................132
Full Copyright Statement .........................................134
This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol.
本节解释了流控制传输协议（SCTP）开发背后的原因、它提供的服务以及理解协议详细描述所需的基本概念。
TCP [RFC793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC768]. The limitations which users have wished to bypass include the following:
TCP[RFC793]作为IP网络中可靠数据传输的主要手段，提供了巨大的服务。然而，最近越来越多的应用程序发现TCP限制太大，并且在UDP[RFC768]之上加入了自己的可靠数据传输协议。用户希望绕过的限制包括：
-- TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases the head-of-line blocking offered by TCP causes unnecessary delay.
--TCP提供可靠的数据传输和严格的数据传输顺序。一些应用程序需要可靠的传输而无需维护序列，而另一些应用程序则需要满足数据的偏序。在这两种情况下，TCP提供的行首阻塞都会导致不必要的延迟。
-- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
--TCP面向流的特性常常带来不便。应用程序必须添加自己的记录标记来描述其消息，并且必须明确使用推送功能以确保在合理的时间内传输完整的消息。
-- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts.
--TCP套接字的有限范围使使用多宿主主机提供高可用数据传输能力的任务变得复杂。
-- TCP is relatively vulnerable to denial of service attacks, such as SYN attacks.
--TCP相对容易受到拒绝服务攻击，如SYN攻击。
Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements.
通过IP网络传输PSTN信令是一个应用程序，TCP的所有这些限制都与此相关。虽然此应用程序直接推动了SCTP的开发，但其他应用程序可能会发现SCTP非常符合其需求。
SCTP is viewed as a layer between the SCTP user application ("SCTP user" for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API which should exist at the boundary between the SCTP and the SCTP user layers.
SCTP被视为SCTP用户应用程序（简称“SCTP用户”）和无连接分组网络服务（如IP）之间的一层。本文档的其余部分假设SCTP在IP上运行。SCTP提供的基本服务是对等SCTP用户之间用户消息的可靠传输。它在两个SCTP端点之间的关联上下文中执行此服务。本文件第10节概述了应存在于SCTP和SCTP用户层之间边界处的API。
SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.4) to provide the other endpoint
SCTP本质上是面向连接的，但SCTP关联是比TCP连接更广泛的概念。SCTP为每个SCTP端点（第1.4节）提供了提供其他端点的方法
(during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations which may be generated from each endpoint's lists.
（在关联启动期间）具有传输地址列表（即，多个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关联
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 security attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup. The startup sequence is described in Section 5 of this document.
初始化过程中使用了一种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 eight bits).
术语“流”在SCTP中被用来指代将被传递到上层协议的用户消息序列，以相对于同一流中的其他消息的顺序。这与它在TCP中的用法相反，在TCP中它指的是一个字节序列（在本文档中，一个字节假定为八位）。
The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a stream sequence number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed.
SCTP用户可以在关联启动时指定关联支持的流的数量。该号码与远端协商（见第5.1.1节）。用户消息与流编号关联（发送、接收原语，第10节）。在内部，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
SCTP为每个用户数据片段或未分段消息分配一个传输序列号（TSN）。TSN独立于在流级别分配的任何流序列号。接受者
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.
end确认接收到的所有TSN，即使序列中存在间隙。这样，可靠的交付在功能上与顺序流交付保持分离。
The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Sections 6 and 7 for a detailed description of the protocol procedures associated with this function.
确认和拥塞避免功能负责在未收到及时确认时重新传输数据包。数据包重传受拥塞避免过程的制约，类似于TCP使用的过程。有关与此功能相关的协议程序的详细说明，请参见第6节和第7节。
As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user messages into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end.
如第3节所述，发送到较低层的SCTP数据包由一个公共报头和一个或多个数据块组成。每个区块可能包含用户数据或SCTP控制信息。SCTP用户可以选择请求将多个用户消息捆绑到单个SCTP数据包中。SCTP的区块捆绑功能负责组装完整的SCTP数据包，并在接收端进行拆卸。
During times of congestion an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission.
在拥塞期间，即使用户请求SCTP不绑定，SCTP实现仍然可以执行绑定。用户禁用绑定只会影响SCTP实现，SCTP实现可能会在传输前延迟一小段时间（以尝试鼓励绑定）。当用户层禁用绑定时，禁止此小延迟，但不禁止在拥塞或重传期间执行绑定。
A mandatory Verification Tag field and a 32 bit checksum field (see Appendix B for a description of the Adler-32 checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The Adler-32 checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid Adler-32 checksum silently discards the packet.
SCTP公共报头中包括一个强制验证标签字段和一个32位校验和字段（Adler-32校验和的说明见附录B）。关联启动期间，关联的每一端都会选择验证标记值。接收到的没有预期验证标记值的数据包将被丢弃，以防止盲伪装攻击和来自先前关联的过时SCTP数据包。Adler-32校验和应由每个SCTP数据包的发送方设置，以提供额外的保护，防止网络中的数据损坏。具有无效Adler-32校验和的SCTP数据包的接收器会自动丢弃该数据包。
The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user.
发送SCTP的用户能够通过第10节中描述的原语操作用作SCTP分组目的地的传输地址集。SCTP路径管理功能根据SCTP用户指令和合格目的地集的当前感知可达性状态为每个传出SCTP数据包选择目的地传输地址。当其他数据包流量不足以提供此信息时，路径管理功能通过心跳监控可达性，并在任何远端传输地址的可达性发生变化时通知SCTP用户。路径管理功能还负责在关联启动期间向远端报告符合条件的本地传输地址集，并将从远端返回的传输地址报告给SCTP用户。
At association start-up, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets.
在关联启动时，为每个SCTP端点定义主路径，并用于SCTP数据包的正常发送。
On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing.
在接收端，路径管理负责验证入站SCTP数据包所属的有效SCTP关联的存在，然后将其传递给进一步处理。
Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items.
注意：路径管理和数据包验证是同时完成的，因此尽管上面单独描述，但实际上它们不能作为单独的项目执行。
Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions.
在前面的章节中介绍了一些用于描述SCTP的语言。本节提供了关键术语及其定义的综合列表。
o Active destination transport address: A transport address on a peer endpoint which a transmitting endpoint considers available for receiving user messages.
o 活动目标传输地址：对等端点上的传输地址，传输端点认为该地址可用于接收用户消息。
o Bundling: An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk.
o 捆绑：一种可选的多路复用操作，在同一SCTP数据包中可以携带多条用户消息。每个用户消息都占用自己的数据块。
o Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.
o 区块：SCTP数据包中的信息单元，由区块头和区块特定内容组成。
o Congestion Window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement.
o 拥塞窗口（cwnd）：一个SCTP变量，用于限制发送方在收到确认之前可以发送到特定目标传输地址的数据（字节数）。
o Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK.
o 累积TSN确认点：通过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 which is considered inactive due to errors and unavailable to transport user messages.
o 非活动目标传输地址：由于错误而被视为非活动且无法传输用户消息的地址。
o Message = user message: Data submitted to SCTP by the Upper Layer Protocol (ULP).
o 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 the message was sent on.
o Ordered Message（已排序消息）：按顺序传递的用户消息，该消息与在消息流中发送的所有先前用户消息有关。
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.
o 未完成的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 which the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes.
o 慢启动阈值（ssthresh）：一个SCTP变量。这是端点将用于确定是否对特定目标传输地址执行慢启动或拥塞避免的阈值。Ssthresh以字节数表示。
o Stream: A uni-directional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.
o 流：从一个关联的SCTP端点到另一个关联的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 assure 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: Verification Tags from a previous association. These Tags are used within a State Cookie so that the newly restarting association can be linked to the original association within the endpoint that did not restart.
o 绑定标记：来自以前关联的验证标记。这些标记在状态Cookie中使用，以便新重新启动的关联可以链接到端点中未重新启动的原始关联。
o Transmission Control Block (TCB): An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association.
o 传输控制块（TCB）：由SCTP端点为其与其他SCTP端点的每个现有SCTP关联创建的内部数据结构。TCB包含端点的所有状态和操作信息，以维护和管理相应的关联。
o Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries.
o 传输序列号（TSN）：SCTP内部使用的32位序列号。将一个TSN附加到包含用户数据的每个区块，以允许接收SCTP端点确认其接收并检测重复交付。
o Transport address: A Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol).
o 传输地址：传统上，传输地址由网络层地址、传输层协议和传输层端口号定义。在通过IP运行SCTP的情况下，传输地址由IP地址和SCTP端口号的组合定义（其中SCTP是传输协议）。
o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) which has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received.
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. Unordered message might be delivered prior to or later than ordered messages sent on the same stream.
o 无序消息：无序消息相对于任何其他消息都是“无序”的，这包括其他无序消息以及其他有序消息。无序消息可能在同一流上发送的有序消息之前或之后发送。
o User message: The unit of data delivery across the interface between SCTP and its user.
o 用户消息：通过SCTP与其用户之间的接口传递数据的单位。
o Verification Tag: A 32 bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association.
o 验证标记：随机生成的32位无符号整数。验证标签提供了一个密钥，允许接收方验证SCTP数据包是否属于当前关联，并且不是来自前一关联的旧数据包或过时数据包。
MAC - Message Authentication Code [RFC2104]
MAC-消息认证码[RFC2104]
RTO - Retransmission Time-out
RTO-重传超时
RTT - Round-trip Time
RTT-往返时间
RTTVAR - Round-trip Time Variation
RTTVAR-往返时间变化
SCTP - Stream Control Transmission Protocol
流控制传输协议
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
上层协议
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.
对流序列号进行的任何运算都应使用[RFC1982]中定义的序列号运算，其中序列位=16。
All other arithmetic and comparisons in this document uses normal arithmetic.
本文档中的所有其他算法和比较均使用普通算法。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照[RFC2119]中的说明进行解释。
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.
这是SCTP发送方的端口号。它可由接收器与源IP地址、SCTP目的地端口和可能的目的地IP地址结合使用，以识别该分组所属的关联。
Destination Port Number: 16 bits (unsigned integer)
目标端口号：16位（无符号整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application.
这是该数据包的目的地SCTP端口号。接收主机将使用此端口号将SCTP数据包解复用到正确的接收端点/应用程序。
Verification Tag: 32 bits (unsigned integer)
验证标记：32位（无符号整数）
The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions:
此数据包的接收方使用验证标签验证此SCTP数据包的发送方。在传输时，此验证标记的值必须设置为关联初始化期间从对等端点接收的Initiate标记的值，但以下情况除外：
- A packet containing an INIT chunk MUST have a zero Verification Tag. - A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN-ACK chunk. - A packet containing an ABORT chunk may have the verification tag copied from the packet which caused the ABORT to be sent. For details see Section 8.4 and 8.5.
- 包含INIT块的数据包必须具有零验证标记。-包含具有T位集的SHUTDOWN-COMPLETE块的数据包必须具有从具有SHUTDOWN-ACK块的数据包复制的验证标记。-包含中止块的数据包可能具有从导致发送中止的数据包复制的验证标记。有关详细信息，请参见第8.4节和第8.5节。
An INIT chunk MUST be the only chunk in the SCTP packet carrying it.
INIT块必须是SCTP数据包中承载它的唯一块。
Checksum: 32 bits (unsigned integer)
校验和：32位（无符号整数）
This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the Adler-32 algorithm as described in Appendix B for calculating the checksum
此字段包含此SCTP数据包的校验和。第6.8节讨论了其计算。SCTP使用附录B中所述的Adler-32算法计算校验和
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)
12 - Reserved for Explicit Congestion Notification Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR)
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - Initiation Acknowledgement (INIT ACK)
3 - Selective Acknowledgement (SACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 - Abort (ABORT)
7 - Shutdown (SHUTDOWN)
8 - Shutdown Acknowledgement (SHUTDOWN ACK)
9 - Operation Error (ERROR)
10 - State Cookie (COOKIE ECHO)
11 - Cookie Acknowledgement (COOKIE ACK)
12 - Reserved for Explicit Congestion Notification Echo (ECNE)
13 - Reserved for Congestion Window Reduced (CWR)
14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - reserved by IETF 63 - IETF-defined Chunk Extensions 64 to 126 - reserved by IETF 127 - IETF-defined Chunk Extensions 128 to 190 - reserved by IETF 191 - IETF-defined Chunk Extensions 192 to 254 - reserved by IETF 255 - IETF-defined Chunk Extensions
14-关闭完成（关闭完成）15至62-由IETF 63保留-由IETF定义的区块扩展64至126-由IETF 127保留-由IETF定义的区块扩展128至190-由IETF 191保留-由IETF定义的区块扩展192至254-由IETF 255保留-由IETF定义的区块扩展
Chunk Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type.
对块类型进行编码，以便最高顺序的两位指定在处理端点无法识别块类型时必须采取的操作。
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter 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).
注意：ECNE和CWR区块类型保留供将来使用显式拥塞通知（ECN）。
Chunk Flags: 8 bits
块标志：8位
The usage of these bits depends on the chunk type as given by the Chunk Type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt.
这些位的使用取决于块类型给定的块类型。除非另有规定，否则它们在传输时被设置为零，在接收时被忽略。
Chunk Length: 16 bits (unsigned integer)
块长度：16位（无符号整数）
This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding.
此值表示块的大小（以字节为单位），包括块类型、块标志、块长度和块值字段。因此，如果区块值字段的长度为零，则长度字段将设置为4。区块长度字段不计算任何填充。
Chunk Value: variable length
区块值：可变长度
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
区块值字段包含要在区块中传输的实际信息。此字段的用法和格式取决于区块类型。
The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
块的总长度（包括类型、长度和值字段）必须是4字节的倍数。如果区块的长度不是4字节的倍数，则发送方必须用所有零字节填充区块，并且该填充不包括在区块长度字段中。发送方的填充长度不应超过3个字节。接收器必须忽略填充字节。
SCTP defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 13.1 of this document.
第3.3节详细描述了SCTP定义的块。IETF定义的区块扩展指南见本文件第13.1节。
Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below.
SCTP控制块的块值由一个特定于块类型的必填字段头组成，后跟零个或多个参数。区块中包含的可选和可变长度参数以类型长度值格式定义，如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 description are reserved for use by IETF.
65535的值保留给IETF定义的扩展。除特定SCTP区块描述中定义的值外，其他值保留供IETF使用。
Chunk Parameter Length: 16 bits (unsigned integer)
区块参数长度：16位（无符号整数）
The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes.
参数长度字段包含以字节为单位的参数大小，包括参数类型、参数长度和参数值字段。因此，具有零长度参数值字段的参数的长度字段为4。参数长度不包括任何填充字节。
Chunk Parameter Value: variable-length.
区块参数值：可变长度。
The Parameter Value field contains the actual information to be transferred in the parameter.
参数值字段包含要在参数中传输的实际信息。
The total length of a parameter (including Type, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
参数的总长度（包括类型、参数长度和值字段）必须是4字节的倍数。如果参数的长度不是4字节的倍数，则发送方在参数末尾（即参数值字段之后）填充所有零字节。填充的长度不包括在参数长度字段中。发送方的填充不应超过3个字节。接收器必须忽略填充字节。
The Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type.
对参数类型进行编码，以便最高阶的两位指定处理端点无法识别参数类型时必须采取的操作。
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-跳过此参数并继续处理，但在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2.
实际的SCTP参数在特定的SCTP区块部分中定义。IETF定义的参数扩展规则见第13.2节。
This section defines the format of the different SCTP chunk types.
本节定义了不同SCTP块类型的格式。
The following format MUST be used for the DATA chunk:
数据块必须使用以下格式：
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 re-assembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to re-order.
在重新组装（如有必要）后，接收器必须将无序数据块发送到上层，而不尝试重新排序。
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 no user data field will have Length set to 16 (indicating 16 bytes).
此字段表示从类型字段开始到用户数据字段结束的数据块长度（字节），不包括任何填充。没有用户数据字段的数据块的长度将设置为16（表示16字节）。
TSN : 32 bits (unsigned integer)
TSN:32位（无符号整数）
This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295.
此值表示此数据块的TSN。TSN的有效范围为0到4294967295（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 the peer application to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network).
此值表示应用程序（或上层）指定的协议标识符。该值由其上层传递给SCTP，并发送给其对等方。SCTP不使用此标识符，但某些网络实体以及对等应用程序可以使用此标识符来标识此数据块中承载的信息类型。这个字段必须在零散的数据块中发送（以确保它对于网络中间的代理是可用的）。
The value 0 indicates no application identifier is specified by the upper layer for this payload data.
值0表示上层没有为此有效负载数据指定应用程序标识符。
User Data: variable length
用户数据：可变长度
This is the payload user data. The implementation MUST pad the end of the data to a 4 byte boundary with all-zero bytes. Any padding MUST NOT be included in the length field. A sender MUST never add more than 3 bytes of padding.
这是有效负载用户数据。实现必须用所有零字节将数据的结尾填充到4字节边界。长度字段中不得包含任何填充。发件人添加的填充内容不得超过3字节。
This chunk is used to initiate a 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：此参数（如果存在）指定发送端点可以支持的所有地址类型。缺少此参数表示发送端点可以支持任何地址类型。
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 bit (unsigned integer)
IPv6地址：128位（无符号整数）
Contains an IPv6 address of the sending endpoint. It is binary encoded.
包含发送终结点的IPv6地址。它是二进制编码的。
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373] but should instead use an IPv4 Address Parameter for an IPv4 address.
注意：发送方不得使用IPv4映射的IPv6地址[RFC2373]，而应为IPv4地址使用IPv4地址参数。
Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the lifetime of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT.
结合SCTP公共标头中的源端口号，在IPv4或IPv6地址参数中传递的值表示INIT的发送方将支持正在启动的关联的传输地址。也就是说，在该关联的生存期内，该IP地址可以出现在从INIT的发送方发送的IP数据报的源地址字段中，并且可以用作从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 re-attempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons.
当发送方重新尝试与对等方建立关联时，应将此可选参数添加到INIT块中。由于陈旧的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 RFC1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP.
根据RFC1123第2.1节[RFC1123]，此字段包含“主机名语法”中的主机名。解析主机名的方法超出了SCTP的范围。
Note: At least one null terminator is included in the Host Name string and must be included in the length.
注意：主机名字符串中至少包含一个空终止符，并且必须包含在长度中。
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, Hostname = 11).
该字段由相应地址TLV的类型值填充（例如，IPv4=5、IPv6=6、主机名=11）。
3.3.3 Initiation Acknowledgement (INIT ACK) (2):
3.3.3 初始化确认（初始化确认）（2）：
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 treat it as an error and close the association by transmitting an ABORT.
如果在接收的INIT ACK块中发现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 ACK has reserved in association with this window. During the life of the association this buffer space SHOULD not be lessened (i.e. dedicated buffers taken away from this association).
此值表示INIT ACK的发送方与此窗口关联保留的专用缓冲区空间（字节数）。在关联的生命周期内，该缓冲区空间不应减少（即，从该关联中移除专用缓冲区）。
Number of Outbound Streams (OS): 16 bits (unsigned integer)
出站流（OS）数：16位（无符号整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used.
定义此INIT ACK块的发送方希望在此关联中创建的出站流数。不得使用0的值。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
注意：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 Parameters 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 Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Note 1: The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination.
注意1：INIT ACK块可以包含任意数量的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 a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
实现说明：由于状态cookie和可变地址列表的大小可变，实现必须准备好接收相当大（超过1500字节）的INIT ACK。例如，如果INIT的响应程序希望发送1000个IPv4地址，则至少需要8000字节才能在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 lifetime of the association being initiated.
结合SCTP公共报头中携带的源端口，INIT ACK中的每个IP地址参数向INIT ACK的接收方指示INIT ACK的发送方在所启动关联的生存期内支持的有效传输地址。
If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT-ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT-ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association.
如果INIT ACK包含至少一个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 Parameters:
无法识别的参数：
Parameter Type Value: 8
参数类型值：8
Parameter Length: Variable Size.
参数长度：可变大小。
Parameter Value:
参数值：
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length and Value fields.
当INIT包含一个无法识别的参数，该参数的值指示应该向发送方报告时，该参数将返回给INIT块的发起方。此参数值字段将包含从INIT块复制的无法识别的参数，包括参数类型、长度和值字段。
3.3.4 Selective Acknowledgement (SACK) (3):
3.3.4 选择性确认（SACK）（3）：
This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs.
该数据块被发送到对等端点，以确认接收到的数据块，并通知对等端点由其TSN表示的数据块的接收子序列中的间隙。
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters.
SACK必须包含累积TSN Ack和播发的接收方窗口信用（a_rwnd）参数。
By definition, the value of the Cumulative TSN Ack parameter is the last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value.
根据定义，累积TSN Ack参数的值是在接收到的TSN序列中发生中断之前接收到的最后一个TSN；发送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 zeros on transmit and ignored on receipt.
传输时设置为全零，接收时忽略。
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.
此参数包含间隔之前按顺序接收的最后一个数据块的TSN。
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 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 re-initialized 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列为一个副本。
3.3.5 Heartbeat Request (HEARTBEAT) (4):
3.3.5 心跳请求（心跳）（4）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
Heartbeat Length: 16 bits (unsigned integer)
心跳长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field.
设置为块的大小（以字节为单位），包括块头和心跳信息字段。
Heartbeat Information: variable length
心跳信息：可变长度
Defined as a variable-length parameter using the format described in Section 3.2.1, i.e.:
定义为使用第3.2.1节所述格式的可变长度参数，即：
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
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).
特定于发送方的心跳信息字段通常应包括有关发送方发送此心跳块的当前时间以及此心跳发送到的目标传输地址的信息（请参阅第8.3节）。
3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5):
3.3.6 心跳确认（心跳确认）（5）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
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
3.3.7 Abort Association (ABORT) (6):
3.3.7 中止关联（中止）（6）：
The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver the reason of the abort. DATA chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK and SHUTDOWN COMPLETE) MAY be bundled with an ABORT but they MUST be placed before the ABORT in the SCTP packet, or they will be ignored by the receiver.
中止区块被发送到关联的对等方以关闭关联。中止区块可能包含原因参数，用于通知接收方中止的原因。数据块不能与中止绑定在一起。控制块（INIT、INIT ACK和SHUTDOWN COMPLETE除外）可以与中止捆绑在一起，但它们必须放在SCTP数据包中中止之前，否则接收器将忽略它们。
If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own.
如果端点接收到带格式错误的中止或不存在关联的中止，则必须以静默方式放弃该中止。此外，在任何情况下，接收中止的端点都不能通过发送自己的中止来响应该中止。
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 had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
如果发送方有一个已销毁的TCB，则T位设置为0。如果发送方没有TCB，则应将该位设置为1。
Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details.
注：特殊规则适用于此区块进行验证，详情请参见第8.5.1节。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
设置块的大小（以字节为单位），包括块头和所有存在的错误原因字段。
See Section 3.3.10 for Error Cause definitions.
错误原因定义见第3.3.10节。
3.3.8 Shutdown Association (SHUTDOWN) (7):
3.3.8 停机关联（停机）（7）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Indicates the length of the parameter. Set to 8.
指示参数的长度。设置为8。
Cumulative TSN Ack: 32 bits (unsigned integer)
累积TSN确认：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节）
3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (8):
3.3.9 停机确认（停机确认）（8）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
3.3.10 Operation Error (ERROR) (9):
3.3.10 操作错误（错误）（9）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present.
设置块的大小（以字节为单位），包括块头和所有存在的错误原因字段。
Error causes are defined as variable-length parameters using the format described in 3.2.1, i.e.:
错误原因定义为使用3.2.1中所述格式的可变长度参数，即：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Cause-specific Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code: 16 bits (unsigned integer)
原因代码：16位（无符号整数）
Defines the type of error conditions being reported.
定义要报告的错误条件的类型。
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
设置为参数的大小（字节），包括原因代码、原因长度和原因特定信息字段
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.10节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
Cause of error
---------------
Invalid Stream Identifier: Indicates endpoint received a DATA chunk
sent to a nonexistent stream.
Cause 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
---------------
Missing Mandatory Parameter: Indicates that one or more mandatory
TLV parameters are missing in a received INIT or INIT ACK.
Cause of error
---------------
Missing Mandatory Parameter: Indicates that one or more mandatory
TLV parameters are missing in a received INIT or INIT ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired.
Cause of error
--------------
Stale Cookie Error: Indicates the receipt of a valid State Cookie
that has expired.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (usec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
---------------
Out of Resource: Indicates that the sender is out of resource. This
is usually sent in combination with or within an ABORT.
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
---------------
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 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
---------------
Unrecognized Chunk Type: This error cause is returned to the
originator of the chunk if the receiver does not understand the chunk
and the upper bits of the 'Chunk Type' are set to 01 or 11.
Cause of error
---------------
Unrecognized Chunk Type: This error cause is returned to the
originator of the chunk if the receiver does not understand the chunk
and the upper bits of the 'Chunk Type' are set to 01 or 11.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=6 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Chunk /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk: variable length
无法识别的区块：可变长度
The Unrecognized Chunk field contains the unrecognized Chunk from the SCTP packet complete with Chunk Type, Chunk Flags and Chunk Length.
Unrecognized Chunk字段包含来自SCTP数据包的未识别区块，该数据包包含区块类型、区块标志和区块长度。
Cause of error
---------------
Invalid Mandatory Parameter: This error cause is returned to the
originator of an INIT or INIT ACK chunk when one of the mandatory
parameters is set to a invalid value.
Cause of error
---------------
Invalid Mandatory Parameter: This error cause is returned to the
originator of an INIT or INIT ACK chunk when one of the mandatory
parameters is set to a invalid value.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the
originator of the INIT ACK chunk if the receiver does not recognize
one or more Optional TLV parameters in the INIT ACK chunk.
Cause of error
---------------
Unrecognized Parameters: This error cause is returned to the
originator of the INIT ACK chunk if the receiver does not recognize
one or more Optional TLV parameters in the INIT ACK chunk.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
---------------
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 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
---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received
While the endpoint was in SHUTDOWN-ACK-SENT state. This error is
usually returned in an ERROR chunk bundled with the retransmitted
SHUTDOWN ACK.
Cause of error
---------------
Cookie Received While Shutting Down: A COOKIE ECHO was received
While the endpoint was in SHUTDOWN-ACK-SENT state. This error is
usually returned in an ERROR chunk bundled with the retransmitted
SHUTDOWN ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.11 Cookie Echo (COOKIE ECHO) (10):
3.3.11 Cookie Echo（Cookie Echo）（10）：
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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
Length: 16 bits (unsigned integer)
长度：16位（无符号整数）
Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the size of the Cookie.
设置块的大小（以字节为单位），包括块头的4个字节和Cookie的大小。
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 insure interoperability.
实现应该使cookie尽可能小，以确保互操作性。
3.3.12 Cookie Acknowledgement (COOKIE ACK) (11):
3.3.12 Cookie确认（Cookie确认）（11）：
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks or SACK chunk in the same SCTP packet.
此区块仅在关联初始化期间使用。它用于确认收到COOKIE回显块。此区块必须位于关联内发送的任何数据或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 zero on transmit and ignored on receipt.
传输时设置为零，接收时忽略。
3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (14):
3.3.13 关闭完成（关闭完成）（14）：
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 had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
如果发送方有一个已销毁的TCB，则T位设置为0。如果发送方没有TCB，则应将该位设置为1。
Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details.
注：特殊规则适用于此区块进行验证，详情请参见第8.5.1节。
During the lifetime of an SCTP association, the SCTP endpoint's association progress from one state to another in response to various events. The events that may potentially advance an association's state include:
在SCTP关联的生存期内，SCTP端点的关联会响应各种事件从一种状态进展到另一种状态。可能提升关联状态的事件包括：
o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT],
o SCTP用户原语调用，例如，[ASSOCIATE]、[SHUTDOWN]、[ABORT]，
o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control chunks, or
o 接收初始化、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 description of all special cases should be found in the text.
下图中的状态图说明了状态更改，以及导致事件和结果操作的原因。请注意，状态图中未显示某些错误条件。所有特殊情况的完整描述应在文本中找到。
Note: Chunk names are given in all capital letters, while parameter names have the first letter capitalized, e.g., COOKIE ECHO chunk type vs. State Cookie parameter. If more than one event/message can occur which causes a state transition it is labeled (A), (B) etc.
注意：区块名称以所有大写字母给出，而参数名称的首字母大写，例如COOKIE ECHO区块类型与状态COOKIE参数。如果可能发生多个事件/消息，导致状态转换，则标记为（a）、（B）等。
----- -------- (frm any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
----- -------- (frm any state)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | create TCB
| | snd INIT
| | strt init timer
rcv valid | |
COOKIE ECHO | v
(1) ---------------- | +------------+
create TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | stop init timer
| | strt cookie timer
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | stop cookie timer
v v
+---------------+
| ESTABLISHED |
+---------------+
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN/check
|PENDING | | outstanding DATA
+---------+ | chunks
| |------------------
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
(from the ESTABLISHED state only)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
check outstanding | |
DATA chunks | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN/check
|PENDING | | outstanding DATA
+---------+ | chunks
| |------------------
No more outstanding | |
---------------------| |
snd SHUTDOWN | |
strt shutdown timer | |
v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
stop shutdown timer | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
delete TCB | \ |
| \ | No more outstanding
| \ |-----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | strt shutdown timer
----------------------| \ |
send SHUTDOWN ACK | \ |
start shutdown timer | \ |
move to SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | stop shutdown timer
| | delete TCB
| |
| | (D)rcv SHUTDOWN ACK
| |--------------
| | stop shutdown timer
| | send SHUTDOWN COMPLETE
| | delete TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+
| | (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 re-start the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to SCTP user.
2) 如果T1 init计时器过期，端点必须重新传输init并重新启动T1 init计时器，而不更改状态。这必须重复到“Max.Init.retransmit”次。在此之后，端点必须中止初始化过程并向SCTP用户报告错误。
3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and re-start the T1-cookie timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to SCTP user.
3) 如果T1 cookie计时器过期，端点必须重新传输cookie ECHO，并在不更改状态的情况下重新启动T1 cookie计时器。这必须重复到“Max.Init.retransmit”次。在此之后，端点必须中止初始化过程并向SCTP用户报告错误。
4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received DATA chunks without delay.
4) 在SHUTDOWN-SENT状态下，端点必须毫不延迟地确认任何接收到的数据块。
5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send request from its SCTP user.
5) 在SHUTDOWN-RECEIVED状态下，端点不得接受来自其SCTP用户的任何新发送请求。
6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit data and leave this state when all data in queue is transmitted.
6) 在SHUTDOWN-RECEIVED状态下，端点必须传输或重新传输数据，并在传输队列中的所有数据时离开此状态。
7) In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send request from its SCTP user.
7) 在SHUTDOWN-ACK-SENT状态下，端点不得接受来自其SCTP用户的任何新发送请求。
The CLOSED state is used to indicate that an association is not created (i.e., doesn't exist).
关闭状态用于指示未创建关联（即不存在）。
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 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.1b）。初始化SCTP将假定INIT/INIT ACK的所有强制和可选参数的默认值。
Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1).
一旦建立了关联，单向流将在两端开放以进行数据传输（见第5.1.1节）。
The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association):
初始化过程包括以下步骤（假设SCTP端点“A”尝试设置与SCTP端点“Z”的关联，并且“Z”接受新关联）：
A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state.
A） “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, nor 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 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-初始计时器并离开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 MUST respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer.
如果端点接收到INIT、INIT ACK或COOKIE ECHO块，但由于接收到的INIT或INIT ACK中缺少必需参数、参数值无效或缺少本地资源而决定不建立新关联，则它必须使用中止块进行响应。它还应该通过将错误原因参数包含在中止块中来指定中止的原因，例如缺少的强制参数的类型等。包含中止块的出站SCTP数据包的公共头中的验证标记字段必须设置为对等方的Initiate标记值。
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 shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
在INIT和INIT ACK块中，块的发送方应指示其希望在关联中拥有的出站流（OS）的数量，以及它将从另一个端点接受的最大入站流（MIS）。
After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer.
在从另一方接收到流配置信息后，每个端点应执行以下检查：如果对等方的MIS小于端点的OS，这意味着对等方无法支持端点想要配置的所有出站流，则端点必须使用MIS出站流，或者中止关联，并向其上层报告对等方的资源短缺。
After the association is initialized, the valid outbound stream identifier range for either endpoint shall be 0 to min(local OS, remote MIS)-1.
初始化关联后，任一端点的有效出站流标识符范围应为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 shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C） 如果在接收到的INIT或INIT ACK区块中仅存在IPv4/IPv6地址，则接收方应从接收区块和发送INIT或INIT ACK的源IP地址派生并记录所有传输地址。传输地址由SCTP源端口（来自公共报头）和初始或初始确认块中携带的IP地址参数以及IP数据报的源IP地址组合而成。当向其对等方发送后续数据包时，接收方应仅使用这些传输地址作为目标传输地址。
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation doesn't control the source IP address that is used for transmitting), an endpoint might need to include in its INIT or INIT ACK all possible IP addresses from which packets to the peer could be transmitted.
实现说明：在某些情况下（例如，当实现不控制用于传输的源IP地址时），端点可能需要在其INIT或INIT ACK中包含所有可能的IP地址，从这些地址可以将数据包传输到对等方。
After all transport addresses are derived from the INIT or INIT ACK chunk using the above rules, the endpoint shall select one of the transport addresses as the initial primary path.
使用上述规则从INIT或INIT ACK块派生出所有传输地址后，端点应选择其中一个传输地址作为初始主路径。
Note: The INIT-ACK MUST be sent to the source address of the INIT.
注意：INIT-ACK必须发送到INIT的源地址。
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiatee) MUST either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer.
INIT的发送方可以在INIT中包含“受支持的地址类型”参数，以指示哪些类型的地址是可接受的。当此参数存在时，INIT的接收方（发起方）在响应INIT时必须使用Supported address types（支持的地址类型）参数中指示的一种地址类型，或者如果不愿意或无法使用对等方指示的任何地址类型，则中止与“无法解决的地址”错误原因的关联。
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新启动，以指示其首选的地址类型。
When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie parameter of the INIT ACK. Inside this State Cookie, the sender should include a MAC (see [RFC2104] for an example), a time stamp on when the State Cookie is created, and the lifespan of the State Cookie, along with all the information necessary for it to establish the association.
当发送INIT 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',
2) 在TCB中，将创建时间设置为当前时间，将寿命设置为协议参数“Valid.Cookie.Life”，
3) From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC), and
3) 从TCB识别并收集重新创建TCB所需的最小信息子集，并使用该信息子集和密钥生成MAC（参见[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 ([RFC1750] provides some information on randomness guidelines); it SHOULD be changed reasonably frequently, and the timestamp in the State Cookie MAY be used to determine which key should be used to verify the MAC.
用于生成MAC的哈希方法对于INIT块的接收者来说严格来说是私有的。为防止拒绝服务攻击，必须使用MAC。密钥应该是随机的（[RFC1750]提供了一些关于随机性准则的信息）；应该合理频繁地更改它，并且可以使用状态Cookie中的时间戳来确定应该使用哪个密钥来验证MAC。
An implementation SHOULD make the cookie as small as possible to insure 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等待状态）接收到带有状态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' 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”，导致对等端点被标记为不可访问（因此关联进入关闭状态）。
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). Reference [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 creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint,
3) 将状态Cookie中的创建时间戳与当前本地时间进行比较。如果经过的时间长于状态Cookie中携带的生命周期，则应丢弃该数据包，包括Cookie回显和任何附加的数据块，并且端点必须向对等端点传输带有“陈旧Cookie”错误原因的错误块，
4) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO, and enter the ESTABLISHED state,
4) 如果状态Cookie有效，则使用Cookie ECHO中携带的TCB数据中的信息创建与Cookie ECHO块发送方的关联，并输入已建立的状态，
5) Send a COOKIE ACK chunk to the peer acknowledging reception of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
5) 向对等方发送COOKIE ACK区块，确认接收到COOKIE回音。COOKIE ACK可以与出站数据块或SACK块捆绑；但是，COOKIE ACK必须是SCTP数据包中的第一个块。
6) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
6) 立即用SACK确认与COOKIE ECHO捆绑的任何数据块（后续数据块确认应遵循第6.2节中定义的规则）。如步骤5）所述，如果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)
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)
/--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
图4：初始化示例
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunks are sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
如果在发送init或COOKIE ECHO块后，T1 init计时器在“A”过期，则应重新传输具有相同启动标记（即标记_A）或状态COOKIE的相同init或COOKIE ECHO块，并
the timer restarted. This shall be repeated Max.Init.Retransmits times before "A" considers "Z" unreachable and reports the failure to its upper layer (and thus the association enters the CLOSED state). When retransmitting the INIT, the endpoint MUST follow the rules defined in 6.3 to determine the proper timer value.
计时器重新启动。在“A”认为“Z”不可到达并向其上层报告故障之前（因此关联进入关闭状态），这应重复Max.Init.remits次。当重新传输INIT时，端点必须遵循6.3中定义的规则，以确定正确的计时器值。
5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK
5.2 处理重复或意外的INIT、INIT ACK、COOKIE ECHO和COOKIE ACK
During the lifetime of an association (in one of the possible states), an endpoint may receive from its peer endpoint one of the setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The receiver shall treat such a setup chunk as a duplicate and process it as described in this section.
在关联的生存期内（在一种可能的状态下），端点可以从其对等端点接收一个设置块（INIT、INIT ACK、COOKIE ECHO和COOKIE ACK）。接收器应将此类设置块视为副本，并按照本节所述进行处理。
Note: An endpoint will not receive the chunk unless the chunk was sent to a SCTP transport address and is from a SCTP transport address associated with this endpoint. Therefore, the endpoint processes such a chunk as part of its current association.
注意：除非区块被发送到SCTP传输地址并且来自与此端点关联的SCTP传输地址，否则端点将不会接收区块。因此，端点将此类块作为其当前关联的一部分进行处理。
The following scenarios can cause duplicated or unexpected chunks:
以下情况可能会导致重复或意外的数据块：
A) The peer has crashed without being detected, re-started itself and sent out a new INIT chunk trying to restore the association,
A） 对等方在未被检测到的情况下崩溃，重新启动自身并发送了一个新的INIT块，试图恢复关联，
B) Both sides are trying to initialize the association at about the same time,
B） 双方几乎同时尝试初始化关联，
C) The chunk is from a stale packet that was used to establish the present association or a past association that is no longer in existence,
C） 该区块来自用于建立当前关联或不再存在的过去关联的过时数据包，
D) The chunk is a false packet generated by an attacker, or
D） 该区块是由攻击者生成的假数据包，或
E) The peer never received the COOKIE ACK and is retransmitting its COOKIE ECHO.
E） 对等方从未收到COOKIE ACK，正在重新传输其COOKIE回显。
The rules in the following sections shall be applied in order to identify and correctly handle these cases.
为了识别和正确处理这些情况，应采用以下章节中的规则。
This usually indicates an initialization collision, i.e., each endpoint is attempting, at about the same time, to establish an association with the other endpoint.
这通常表示初始化冲突，即每个端点几乎同时试图与另一个端点建立关联。
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it
在接收到处于COOKIE-WAIT或COOKIE-echood状态的INIT时，端点必须使用与它相同的参数响应INIT ACK
sent in its original INIT chunk (including its Initiation Tag, unchanged). These original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
在其原始INIT块中发送（包括其初始标记，未更改）。这些原始参数与新接收的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 with the Tag information of itself and its peer (see section 5.2.2 for a description of the Tie-Tags).
对于处于COOKIE-echood状态的端点，它必须使用自身及其对等方的标记信息填充其Tie标记（有关Tie标记的说明，请参见第5.2.2节）。
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT
5.2.2 非关闭、COOKIE-Echosed、COOKIE-WAIT和SHUTDOWN-ACK-SENT状态下的意外初始化
Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g. number of outbound streams) into the INIT ACK and cookie.
除非另有说明，否则在接收到此关联的意外INIT时，端点应使用状态Cookie生成INIT ACK。在outbound INIT ACK中，端点必须将其当前验证标记和对等方的验证标记复制到状态cookie中的保留位置。我们将这些位置称为对等的Tie-Tag和本地Tie-Tag。包含此初始化确认的出站SCTP数据包必须携带与意外初始化中找到的初始化标记相等的验证标记值。初始确认必须包含新的初始标签（随机生成，见第5.3.1节）。端点的其他参数应从关联的现有参数（例如出站流的数量）复制到INIT ACK和cookie中。
After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
在发送INIT ACK之后，端点不应采取进一步的操作，即现有关联，包括其当前状态，并且不得更改相应的TCB。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT state are the Tie-Tags populated. For a normal association INIT (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.
注意：只有当TCB存在且关联未处于COOKIE-WAIT状态时，才会填充Tie标记。对于正常关联INIT（即端点处于COOKIE-WAIT状态），Tie标记必须设置为0（表示以前不存在TCB）。按照第5.2.1节的规定填充初始确认和状态Cookie。
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, the packet, including the COOKIE ECHO and any DATA chunks, should be discarded. The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint (this is case C or D in section 5.2).
3) 将状态Cookie中的时间戳与当前时间进行比较。如果状态Cookie比状态Cookie中包含的寿命长，并且状态Cookie中包含的验证标记与当前关联的验证标记不匹配，则应丢弃该数据包，包括Cookie回显和任何数据块。端点还必须将带有“过时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 of section 5.2) even if the lifespan is exceeded.
如果状态Cookie中的两个验证标签与当前关联的验证标签相匹配，则考虑状态Cookie有效（这是第5.2节的情况E），即使超过了寿命。
4) If the State Cookie proves to be valid, unpack the TCB into a temporary TCB.
4) 如果状态Cookie被证明是有效的，则将TCB解包到临时TCB中。
5) Refer to Table 2 to determine the correct action to be taken.
5) 请参阅表2以确定要采取的正确措施。
+------------+------------+---------------+--------------+-------------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ |
| | | | | Description |
+------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+
| M | X | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| M | 0 | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+
| M | M | A | A | (D) |
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB exists |
+======================================================================+
+------------+------------+---------------+--------------+-------------+
| Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ |
| | | | | Description |
+------------+------------+---------------+--------------+-------------+
| X | X | M | M | (A) |
+------------+------------+---------------+--------------+-------------+
| M | X | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| M | 0 | A | A | (B) |
+------------+------------+---------------+--------------+-------------+
| X | M | 0 | 0 | (C) |
+------------+------------+---------------+--------------+-------------+
| M | M | A | A | (D) |
+======================================================================+
| Table 2: Handling of a COOKIE ECHO when a TCB exists |
+======================================================================+
Legend:
图例：
X - Tag does not match the existing TCB M - Tag matches the existing TCB. 0 - No Tie-Tag in Cookie (unknown). A - All cases, i.e. M, X or 0.
X标记与现有TCB不匹配M标记与现有TCB匹配。0-Cookie中没有领带标签（未知）。A-所有情况，即M、X或0。
Note: For any case not shown in Table 2, the cookie should be silently discarded.
注意：对于表2中没有显示的任何情况，cookie都应该被悄悄地丢弃。
Action
行动
A) In this case, the peer may have restarted. When the endpoint recognizes this potential 'restart', the existing session is treated the same as if it received an ABORT followed by a new COOKIE ECHO with the following exceptions:
A） 在这种情况下，对等方可能已重新启动。当端点识别到此潜在的“重新启动”时，现有会话将被视为在接收到一个新的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 the peer has restarted (Action A), it MUST NOT setup a new association but instead resend the SHUTDOWN ACK and send an ERROR chunk with a "Cookie Received while Shutting Down" error cause to its peer.
如果端点处于SHUTDOWN-ACK-SENT状态，并且识别出对等方已重新启动（操作A），则它不能设置新关联，而是必须重新发送SHUTDOWN ACK，并向其对等方发送一个错误块，其中包含“关闭时收到的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 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 always enter the ESTABLISHED state, if it has not already done so. It should stop any init or cookie timers that may be running and send a COOKIE ACK.
D） 当本地和远程标记都匹配时，端点应始终进入已建立状态（如果尚未这样做）。它应该停止任何可能正在运行的init或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 a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
图5：重启示例
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) That 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 setup, i.e. the association is in the COOKIE-ECHOED state. In all cases if the association is not in the COOKIE-ECHOED state, the ERROR chunk should be silently discarded.
当处理带有“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 re-attempt the setup procedure.
1) 将新的INIT块发送到端点以生成新的状态Cookie，然后重新尝试安装过程。
2) Discard the TCB and report to the upper layer the inability to setup the association.
2) 丢弃TCB并向上层报告无法设置关联。
3) Send a new INIT chunk to the endpoint, adding a Cookie Preservative parameter requesting an extension to the lifetime of the State Cookie. When calculating the time extension, an implementation SHOULD use the RTT information measured based on the previous COOKIE ECHO / ERROR exchange, and should add no more than 1 second beyond the measured RTT, due to long State Cookie lifetimes making the endpoint more subject to a replay attack.
3) 向端点发送新的INIT块，添加Cookie参数，请求延长状态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 [RFC1750] can be used for the Initiate Tag randomization. Careful selection of Initiate Tags is also necessary to prevent old duplicate packets from previous associations being mistakenly processed as belonging to the current association.
启动标签值应在1到2**32-1范围内选择。将Initiate标记值随机化以帮助防止“中间人”和“序列号”攻击非常重要。[RFC1750]中描述的方法可用于初始标签随机化。仔细选择Initiate标记也很有必要，以防止来自以前关联的旧重复数据包被错误地处理为属于当前关联。
Moreover, the Verification Tag value used by either endpoint in a given association MUST NOT change during the lifetime of an association. A new Verification Tag value MUST be used each time the endpoint tears-down and then re-establishes an association to the same peer.
此外，给定关联中任一端点使用的验证标记值在关联的生存期内不得更改。每次端点断开时，必须使用新的验证标记值，然后重新建立与同一对等方的关联。
Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is that DATA chunks are allowed to be bundled with an outbound COOKIE ECHO chunk when in COOKIE-WAIT state.
数据传输只能在已建立、关机挂起和关机接收状态下进行。唯一的例外是，当处于COOKIE-WAIT状态时，允许数据块与出站COOKIE ECHO块绑定。
DATA chunks MUST only be received according to the rules below in ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received in CLOSED is out of the blue and SHOULD be handled per 8.4. A DATA chunk received in any other state SHOULD be discarded.
数据块只能根据以下规则在已建立、关闭-挂起、关闭-发送中接收。在CLOSED中接收到的数据块是出乎意料的，应该按照8.4进行处理。应丢弃在任何其他状态下接收的数据块。
A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED. An incoming SACK MAY be processed in COOKIE-ECHOED. A SACK in the CLOSED state is out of the blue and SHOULD be processed according to the rules in 8.4. A SACK chunk received in any other state SHOULD be discarded.
SACK必须在已建立、关机挂起和关机接收中处理。传入的SACK可以在COOKIE-echood中处理。处于关闭状态的袋子是出乎意料的，应根据8.4中的规则进行处理。应丢弃在任何其他状态下接收的SACK块。
A SCTP receiver MUST be able to receive a minimum of 1500 bytes in one SCTP packet. This means that a SCTP endpoint MUST NOT indicate less than 1500 bytes in its Initial a_rwnd sent in the INIT or INIT ACK.
SCTP接收器必须能够在一个SCTP数据包中接收至少1500字节。这意味着SCTP端点在INIT或INIT ACK中发送的初始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 Sections 6.9 and 6.10, are OPTIONAL to implement by the data sender, but they MUST be implemented by the data receiver, i.e., an endpoint MUST properly receive and process bundled or fragmented data.
如第6.9节和第6.10节所述，碎片和捆绑机制是可选的，可由数据发送方实施，但必须由数据接收方实施，即端点必须正确接收和处理捆绑或碎片数据。
This document is specified as if there is a single retransmission timer per destination transport address, but implementations MAY have a retransmission timer for each DATA chunk.
该文档被指定为每个目标传输地址都有一个重传计时器，但实现可能会为每个数据块都有一个重传计时器。
The following general rules MUST be applied by the data sender for transmission and/or retransmission of outbound DATA chunks:
对于出站数据块的传输和/或重新传输，数据发送方必须应用以下一般规则：
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender.
A） 在任何给定时间，如果对等方的rwnd指示该对等方没有缓冲区空间（即rwnd为0，请参见第6.2.1节），则数据发送方不得向任何目标传输地址传输新数据。但是，无论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 which are marked for retransmission (limited by the current cwnd).
C） 当发送方需要传输时，在发送新的数据块之前，发送方必须首先传输标记为要重新传输的任何未完成的数据块（受当前cwnd的限制）。
D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow.
D） 然后，发送方可以根据上述规则A和规则B发送尽可能多的新数据块。
Multiple DATA chunks committed for transmission MAY be bundled in a single packet. Furthermore, DATA chunks being retransmitted MAY be bundled with new DATA chunks, as long as the resulting packet size does not exceed the path MTU. A ULP may request that no bundling is performed but this should only turn off any delays that a SCTP implementation may be using to increase bundling efficiency. It does not in itself stop all bundling from occurring (i.e. in case of congestion or retransmission).
提交用于传输的多个数据块可以捆绑在单个分组中。此外，只要得到的分组大小不超过路径MTU，被重传的数据块可以与新数据块捆绑在一起。ULP可能会请求不执行捆绑，但这只会关闭SCTP实现可能用于提高捆绑效率的任何延迟。它本身并不阻止所有捆绑的发生（即在拥塞或重传的情况下）。
Before an endpoint transmits a DATA chunk, if any received DATA chunks have not been acknowledged (e.g., due to delayed ack), the sender should create a SACK and bundle it with the outbound DATA chunk, as long as the size of the final SCTP packet does not exceed the current MTU. See Section 6.2.
在端点传输数据块之前，如果任何接收到的数据块未被确认（例如，由于延迟的ack），则发送方应创建SACK并将其与出站数据块捆绑，只要最终SCTP数据包的大小不超过当前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.
SCTP端点必须始终确认每个有效数据块的接收。
The guidelines on delayed acknowledgement algorithm specified in Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an acknowledgement SHOULD be generated for at least every second packet (not every second DATA chunk) received, and SHOULD be generated within 200 ms of the arrival of any unacknowledged DATA chunk. In some situations it may be beneficial for an SCTP transmitter to be more conservative than the algorithms detailed in this document allow. However, an SCTP transmitter MUST NOT be more aggressive than the following algorithms allow.
应遵循[RFC2581]第4.2节中规定的延迟确认算法指南。具体地说，应至少为接收到的每一秒分组（不是每一秒数据块）生成确认，并且应在任何未确认的数据块到达后200 ms内生成确认。在某些情况下，SCTP发射机比本文件中详述的算法更加保守可能是有益的。但是，SCTP发射机的攻击性不得超过以下算法允许的范围。
A SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data.
SCTP接收器不得为每个传入数据包生成多个SACK，除非在接收应用程序使用新数据时更新提供的窗口。
IMPLEMENTATION NOTE: The maximum delay for generating an acknowledgement may be configured by the SCTP administrator, either statically or dynamically, in order to meet the specific timing requirement of the protocol being carried.
实施说明：SCTP管理员可以静态或动态配置生成确认的最大延迟，以满足所承载协议的特定定时要求。
An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words an implementation MAY lower this value below 500ms but MUST NOT raise it above 500ms.
实现不得允许将最大延迟配置为超过500毫秒。换句话说，实现可将该值降低到500毫秒以下，但不得将其提高到500毫秒以上。
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields.
确认必须以SACK块的形式发送，除非ULP请求关闭，在这种情况下，端点可以在关闭块中发送确认。SACK块可以确认多个数据块的接收。SACK区块格式见第3.3.4节。特别是，SCTP端点必须填写累积TSN Ack字段，以指示其接收到的（有效数据块的）最新顺序TSN。任何接收到的TSN大于累积TSN Ack字段中的值的数据块也应在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
C） 当数据块被传送到ULP并从接收缓冲区释放时，将a_rwnd增加传送到上层的字节数。实际上，这是在数据发送方上打开rwnd并允许其发送更多数据。这个
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.
除非数据接收器已从其接收缓冲区释放字节，否则它不应增加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 circumstance should an endpoint use this procedure (such as out of buffer space). The data receiver should take into account that dropping data that has been acked in Gap Ack Blocks can result in suboptimal retransmission strategies in the data sender and thus in suboptimal performance.
端点不应撤销SACK并丢弃数据。只有在极端情况下，端点才应该使用此过程（例如缓冲区空间不足）。数据接收器应考虑到丢弃已在间隙Ack块中确认的数据可能导致数据发送器中的次优重传策略，从而导致次优性能。
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 Acknowledgment Example
图7：延迟确认示例
If an endpoint receives a DATA chunk with no user data (i.e., the Length field is set to 16) it MUST send an ABORT with error cause set to "No User Data".
如果端点接收到没有用户数据的数据块（即，长度字段设置为16），它必须发送一个中止，错误原因设置为“无用户数据”。
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中所指定）。使用累积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 order, the data sender can develop an incorrect view of the peer's receive buffer space.
数据发送方在处理SACK时必须考虑的问题之一是，SACK可能会被无序接收。也就是说，数据接收方发送的SACK可以通过较早的SACK，并首先由数据发送方接收。如果SACK接收不正常，数据发送方可能会对对等方的接收缓冲区空间产生错误的看法。
Since there is no explicit identifier that can be used to detect out-of-order SACKs, the data sender must use heuristics to determine if a SACK is new.
由于没有显式标识符可用于检测无序的SACK，因此数据发送者必须使用试探法来确定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，使用a_rwnd值、接收SACK中的累积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 (via either T3-rtx timer expiration (Section 6.3.3)or via fast retransmit (Section 7.2.4)), add the data size of those chunks to the rwnd.
C） 任何时候标记数据块进行重传（通过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 mark the corresponding DATA chunk as available for retransmit: Mark it as missing for fast retransmit as described in Section 7.2.4 and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）如果SACK缺少先前通过Gap Ack块确认的TSN（例如，数据接收器拒绝接收数据），然后将相应的数据块标记为可用于重新传输：如第7.2.4节所述，将其标记为缺少可用于快速重新传输的数据块，如果没有为数据块最初传输到的目标地址运行重新传输计时器，则为该目标地址启动T3 rtx。
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data delivery in the absence of any feedback from its peer. The duration of this timer is referred to as RTO (retransmission timeout).
SCTP端点使用重传计时器T3 rtx来确保在没有来自其对等方的任何反馈的情况下进行数据传送。此计时器的持续时间称为RTO（重传超时）。
When an endpoint's peer is multi-homed, the endpoint will calculate a separate RTO for each different destination transport address of its peer endpoint.
当端点的对等点是多宿的时，端点将为其对等端点的每个不同目的地传输地址计算单独的RTO。
The computation and management of RTO in SCTP follows closely how TCP manages its retransmission timer. To compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation).
SCTP中RTO的计算和管理与TCP如何管理其重传计时器密切相关。为了计算当前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 SRTT <- R, RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR.
C2）进行第一次RTT测量R时，设置SRTT<-R、RTTVAR<-R/2和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'| SRTT
<- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT
<- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment.
注：RTTVAR更新中使用的SRTT值是使用第二个赋值更新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
C4）当数据处于飞行状态且以下规则C5允许时，每次往返必须进行新的RTT测量。此外，对于给定的目的地传输地址，每次往返不应进行一次新的RTT测量。这一建议有两个原因：第一，更频繁地测量似乎在实践中不会产生任何显著的好处[ALLMAN99]；其次，如果更频繁地进行测量，则应调整上述规则C3中RTO.Alpha和RTO.Beta的值，以便SRTT和RTTVAR仍能以大致相同的速率调整变化（就往返次数而言）
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.
如果每次往返仅进行一次测量，并使用规则C3中给出的RTO.Alpha和RTO.Beta，则它们将反映新值。然而，这些调整的确切性质仍然是一个研究问题。
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance).
C5）Karn算法：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 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 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 the receiver uses delayed acks).
下面的示例显示了各种计时器规则的使用（假设接收器使用延迟的ack）。
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Re-start T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Re-start T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Figure 8 - Timer Rule Examples
图8-计时器规则示例
Whenever the retransmission timer T3-rtx expires for a destination address, do the following:
每当目标地址的重传计时器T3 rtx过期时，执行以下操作：
E1) For the destination address for which the timer expires, adjust its ssthresh with rules defined in Section 7.2.3 and set the cwnd <- MTU.
E1）对于计时器到期的目标地址，使用第7.2.3节中定义的规则调整其ssthresh，并设置cwnd<-MTU。
E2) For the destination address for which the timer expires, set RTO <- RTO * 2 ("back off the timer"). The maximum value discussed in rule C7 above (RTO.max) may be used to provide an upper bound to this doubling operation.
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
E3）确定T3 rtx已过期的地址的最早（即，最低TSN）未完成数据块中有多少将适合于单个分组，取决于与正在向其发送重传的目的地传输地址相对应的路径的MTU约束（这可能不同于
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.
计时器到期的地址[见第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 Sections 5.1.2 and 10.1 for details).
此外，端点的ULP应选择多宿对等端点的多个目的地地址中的一个作为主路径（详见第5.1.2和10.1节）。
By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use.
默认情况下，端点应始终传输到主路径，除非SCTP用户明确指定要使用的目标传输地址（可能还有源传输地址）。
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.
端点应将应答块（例如，SACK、心跳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 being that receiving a duplicate from a multi-homed endpoint might indicate that the return path (as specified in the source address of the DATA chunk) for the SACK is broken.
当重复数据块的接收器向多宿主端点发送SACK时，改变目标地址而不使用数据块的源地址可能是有益的。原因是，从多宿主端点接收副本可能表示SACK的返回路径（在数据块的源地址中指定）已中断。
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
此外，当其对等方是多宿时，端点应尝试将数据块重新传输到活动目标传输地址，该地址与数据块发送到的最后一个目标地址不同。
Retransmissions do not affect the total outstanding data count. However, if the DATA chunk is retransmitted onto a different destination address, both the outstanding data counts on the new destination address and the old destination address to which the data chunk was last sent shall be adjusted accordingly.
重新传输不会影响未完成的数据总数。然而，如果数据块被重新传输到不同的目的地地址，则新目的地地址上的未完成数据计数和数据块最后发送到的旧目的地地址上的未完成数据计数都应相应地调整。
Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from SCTP user.
由于出现某些错误情况（参见第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, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
当重传数据时，如果端点是多家乡的，它应该考虑在其重传选择策略中的每个源目的地地址对。当重新传输时，端点应尝试从数据包传输到的原始源-目的地对中选取最分散的源-目的地对。
Note: Rules for picking the most divergent source-destination pair are an implementation decision and is not specified within this document.
注意：选择差异最大的源-目的地对的规则是一项实施决策，本文档中未指定。
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK.
每个数据块必须携带一个有效的流标识符。如果端点接收到具有无效流标识符的数据块，它应按照正常程序确认数据块的接收，立即发送错误块，原因设置为“无效流标识符”（见第3.3.10节），并丢弃数据块。只要错误跟随SACK，端点就可以将错误块捆绑在与SACK相同的数据包中。
The stream sequence number in all the streams shall start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number shall be set to 0.
当建立关联时，所有流中的流序列号应从0开始。此外，当流序列号达到值65535时，下一个流序列号应设置为0。
Within a stream, an endpoint MUST deliver DATA chunks received with the U flag set to 0 to the upper layer according to the order of their stream sequence number. If DATA chunks arrive out of order of their stream sequence number, the endpoint MUST hold the received DATA chunks from delivery to the ULP until they are re-ordered.
在流中，端点必须根据流序列号的顺序将U标志设置为0的接收数据块传递给上层。如果数据块的到达顺序与其流序列号不符，则端点必须保持接收到的数据块从交付到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 re-assembly 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 which have been acknowledged by the SACK's Cumulative TSN Ack from its transmit queue. The endpoint MUST also treat all the DATA chunks with TSNs not included in the Gap Ack Blocks reported by the SACK as "missing". The number of "missing" reports for each outstanding DATA chunk MUST be recorded by the data sender in order to make retransmission decisions. See Section 7.2.4 for details.
接收到SACK后，端点必须从其传输队列中移除SACK的累积TSN Ack确认的所有数据块。端点还必须将SACK报告的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,
/ Strt=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,
/ Strt=2,End=2]
<-----/
(remove 6 from out-queue,
and mark 7 as "1" missing report)
Figure 9 - Reporting a Gap using SACK
图9-使用SACK报告差距
The maximum number of Gap Ack Blocks that can be reported within a single SACK chunk is limited by the current path MTU. When a single SACK can not cover all the Gap Ack Blocks needed to be reported due to the MTU limitation, the endpoint MUST send only one SACK, reporting the Gap Ack Blocks from the lowest to highest TSNs, within the size limit set by the MTU, and leave the remaining highest TSN numbers unacknowledged.
单个SACK块中可报告的最大间隙Ack块数受当前路径MTU的限制。当由于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 Adler-32 checksum value calculated on the packet, as described below.
当发送SCTP数据包时，端点必须通过包括在数据包上计算的Adler-32校验和值来加强传输的数据完整性，如下所述。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall:
在构建数据包（包含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 Adler-32 checksum of the whole packet, including the SCTP common header and all the chunks. Refer to appendix B for details of the Adler-32 algorithm. And,
2) 计算整个数据包的Adler-32校验和，包括SCTP公共头和所有数据块。有关Adler-32算法的详细信息，请参阅附录B。和
3) Put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3) 将结果值放入公共标头的校验和字段中，并保持其余位不变。
When an SCTP packet is received, the receiver MUST first check the Adler-32 checksum:
当接收到SCTP数据包时，接收器必须首先检查Adler-32校验和：
1) Store the received Adler-32 checksum value aside,
1) 将收到的Adler-32校验和值存储在一边，
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate an Adler-32 checksum value of the whole received packet. And,
2) 用所有“0”替换接收到的SCTP数据包中校验和字段的32位，并计算整个接收数据包的Adler-32校验和值。和
3) Verify that the calculated Adler-32 checksum is the same as the received Adler-32 checksum. If not, the receiver MUST treat the packet as an invalid SCTP packet.
3) 验证计算出的Adler-32校验和与接收到的Adler-32校验和相同。否则，接收方必须将该数据包视为无效的SCTP数据包。
The default procedure for handling invalid SCTP packets is to silently discard them.
处理无效SCTP数据包的默认过程是以静默方式丢弃它们。
An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message.
端点在发送数据块时可能支持分段，但在接收数据块时必须支持重新组装。如果端点支持分段，则如果要发送的用户消息的大小导致出站SCTP数据包大小超过当前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
2) 然后，发送器必须依次为序列中的每个数据块分配单独的TSN。发射机将相同的SSN分配给每个数据块。如果用户指示
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.
如果要使用无序传递来传递用户消息，则必须将用户消息的每个数据块的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 re-assembly. Once the user message is reassembled, SCTP shall pass the re-assembled user message to the specific stream for possible re-ordering and final dispatching.
端点必须通过检查每个接收数据块中的B/E位来识别碎片数据块，并将碎片数据块排队以进行重新组装。一旦重新组装用户消息，SCTP应将重新组装的用户消息传递给特定流，以进行可能的重新订购和最终调度。
Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the re-assembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received.
注意：如果数据接收器在等待更多片段完成消息的重新组装时耗尽了缓冲区空间，则应通过部分传递API（参见第10节）发送部分入站消息，释放部分接收缓冲区空间，以便接收其余消息。
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram, including the SCTP packet and IP headers, MUST be less or equal to the current Path MTU.
端点通过简单地在一个出站SCTP数据包中包含多个块来绑定块。生成的IP数据报（包括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 a 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.
部分块不能放在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 assure prompt delivery of time-critical data - thus it would appear to be unlikely, during normal operations, that transmissions encounter severe congestion conditions. However SCTP must operate under adverse operational conditions, which can develop upon partial network failures or unexpected traffic surges. In such situations SCTP must follow correct congestion control steps to recover from congestion quickly in order to get data delivered as soon as possible. In the absence of network congestion, these preventive congestion control algorithms should show no impact on the protocol performance.
拥塞控制是SCTP的基本功能之一。对于某些应用程序，可能会为SCTP流量分配足够的资源，以确保及时交付时间关键型数据-因此，在正常运行期间，传输不太可能遇到严重的拥塞情况。然而，SCTP必须在不利的运行条件下运行，这可能会在部分网络故障或意外流量激增时发生。在这种情况下，SCTP必须遵循正确的拥塞控制步骤，以快速从拥塞中恢复，以便尽快交付数据。在没有网络拥塞的情况下，这些预防性拥塞控制算法应该不会对协议性能产生影响。
IMPLEMENTATION NOTE: As far as its specific performance requirements are met, an implementation is always allowed to adopt a more conservative congestion control algorithm than the one defined below.
实施说明：只要满足其特定性能要求，实施始终允许采用比下面定义的更保守的拥塞控制算法。
The congestion control algorithms used by SCTP are based on [RFC2581]. This section describes how the algorithms defined in RFC2581 are adapted for use in SCTP. We first list differences in protocol designs between TCP and SCTP, and then describe SCTP's congestion control scheme. The description will use the same terminology as in TCP congestion control whenever appropriate.
SCTP使用的拥塞控制算法基于[RFC2581]。本节描述了RFC2581中定义的算法如何适用于SCTP。我们首先列出TCP和SCTP在协议设计上的差异，然后描述SCTP的拥塞控制方案。在适当的情况下，描述将使用与TCP拥塞控制中相同的术语。
SCTP congestion control is always applied to the entire association, and not to individual streams.
SCTP拥塞控制始终应用于整个关联，而不是单个流。
Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. SCTP considers the information carried in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has been acknowledged by SACK, including DATA that arrived at the receiving end out of order, are not considered fully delivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack
SCTP SACK中的Gap Ack块具有与TCP SACK相同的语义。TCP仅将SACK中携带的信息视为建议信息。SCTP将SACK块中的Gap Ack块中携带的信息视为建议。在SCTP中，SACK确认的任何数据块，包括无序到达接收端的数据，在累积TSN Ack点通过数据块的TSN（即，该数据块已由累积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].
麻袋中的字段）。因此，cwnd的值控制未完成的数据量，而不是（如非SACK TCP的情况）最高确认序列号和可在拥塞窗口内发送的最新数据块之间的上限。SCTP SACK导致与非SACK TCP不同的快速重传和快速恢复实现。例如，参见[96]。
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 otherwise; however, SCTP may change to an alternate destination in the event an address is marked inactive (see Section 8.2). Also, SCTP may retransmit to a different transport address than the original transmission.
o 发送方通常使用相同的目的地地址，除非上层另有指示；但是，如果地址被标记为非活动地址，SCTP可能会更改为备用目的地（见第8.2节）。此外，SCTP可以重传到与原始传输不同的传输地址。
o The sender keeps a separate congestion control parameter set for each of the destination addresses it can send to (not each source-destination pair but for each destination). The parameters should decay if the address is not used for a long enough time period.
o 发送方为其可以发送到的每个目的地地址（不是每个源-目的地对，而是每个目的地）保留一个单独的拥塞控制参数集。如果地址在足够长的时间内未使用，则参数应衰减。
o For each of the destination addresses, an endpoint does slow-start upon the first transmission to that address.
o 对于每个目标地址，端点在第一次传输到该地址时会减慢启动速度。
Note: TCP guarantees in-sequence delivery of data to its upper-layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper-layer protocol even if there is a gap in TSN if the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery is indicated. Although this does not affect cwnd, it might affect rwnd calculation.
注意：TCP保证在单个TCP会话中按顺序将数据传递到其上层协议。这意味着，当TCP注意到接收到的序列号中存在间隙时，它会等待间隙被填满，然后再发送接收到的序列号高于缺失数据的序列号的数据。另一方面，如果流序列号是针对特定流的序列号（即，缺失的数据块是针对不同流的），或者如果指示无序交付，则即使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 <= 2*MTU.
o 数据传输前或足够长的空闲时间后的初始cwnd必须小于等于2*MTU。
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU.
o 重传超时后的初始cwnd不得超过1*MTU。
o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window).
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 (assuming the current congestion window is being fully utilized). If an incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99].
o 当cwnd小于或等于ssthresh时，SCTP端点必须使用慢启动算法来增加cwnd（假设当前拥塞窗口被充分利用）。如果传入SACK提前了累积TSN Ack点，则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 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，该SACK提前了其累积TSN Ack点，则该端点应更新其分配给其传输确认数据的目标地址的cwnd（或cwnd）。但是，如果接收到的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, 2*MTU) per RTO.
o 当端点不在给定传输地址上传输数据时，传输地址的cwnd应调整为每个RTO的最大值（cwnd/2，2*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, 2*MTU) per RTO.
o 与慢速启动相同，当发送方不在给定传输地址上传输数据时，传输地址的cwnd应调整为每个RTO的最大值（cwnd/2，2*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, 2*MTU)
cwnd = ssthresh
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
and assure that no more than one SCTP packet will be in flight for that address until the endpoint receives acknowledgement for successful delivery of data to that address.
并确保在端点接收到数据成功传递到该地址的确认之前，该地址的SCTP数据包不会超过一个。
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
在没有数据丢失的情况下，端点执行延迟确认。但是，每当端点注意到到达的TSN序列中有一个漏洞时，它应该在每次数据包到达时发送一个SACK，直到该漏洞被填满为止。
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
每当端点接收到指示某些TSN丢失的SACK时，它应该等待相同TSN上的3个进一步的未命中指示（通过后续SACK），然后再采取有关快速重新传输的操作。
When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall:
当连续第四个SACK中报告TSN缺失时，数据发送方应：
1) Mark the missing DATA chunk(s) for retransmission,
1) 标记丢失的数据块以便重新传输，
2) Adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2) 根据第7.2.3节中描述的公式，调整上次向其发送缺失数据块的目标地址的ssthresh和cwnd。
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet.
3) 根据分组被发送到的目的地传输地址的路径MTU的约束，确定标记为重传的最早（即，最低TSN）数据块中有多少将适合于单个分组。调用该值K。在单个数据包中重新传输这些K个数据块。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4) 仅当最后一个SACK确认发送到该地址的最低未完成TSN号，或者端点正在重新传输发送到该地址的第一个未完成数据块时，才重新启动T3 rtx计时器。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
注：在进行上述调整之前，如果收到的SACK也确认新的数据块并提前累计TSN确认点，则必须首先应用第7.2.1节和第7.2.2节中定义的cwnd调整规则。
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit procedure, the counter resets to 0.
上述的简单实现为SACK报告的每个TSN孔保留一个计数器。对于报告TSN孔的每个连续袋，计数器递增。达到4并开始快速重传程序后，计数器重置为0。
Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP fast-recovery is achieved automatically with no adjustment to the congestion control window size.
由于SCTP中的cwnd间接限制了未完成TSN的数量，因此TCP快速恢复的效果是自动实现的，而无需调整拥塞控制窗口的大小。
[RFC1191] specifies "Path MTU Discovery", whereby an endpoint maintains an estimate of the maximum transmission unit (MTU) along a given Internet path and refrains from sending packets along that path which exceed the MTU, other than occasional attempts to probe for a change in the Path MTU (PMTU). RFC 1191 is thorough in its discussion of the MTU discovery mechanism and strategies for determining the current end-to-end MTU setting as well as detecting changes in this value. [RFC1981] specifies the same mechanisms for IPv6. An SCTP sender using IPv6 MUST use Path MTU Discovery unless all packets are less than the minimum IPv6 MTU [RFC2460].
[RFC1191]指定了“路径MTU发现”，其中端点保持沿给定因特网路径的最大传输单元（MTU）的估计值，并避免沿该路径发送超过MTU的数据包，而不是偶尔尝试探测路径MTU（PMTU）中的变化。RFC 1191详细讨论了确定当前端到端MTU设置以及检测该值变化的MTU发现机制和策略。[RFC1981]为IPv6指定相同的机制。使用IPv6的SCTP发送方必须使用路径MTU发现，除非所有数据包都小于最小IPv6 MTU[RFC2460]。
An endpoint SHOULD apply these techniques, and SHOULD do so on a per-destination-address basis.
端点应该应用这些技术，并且应该在每个目标地址的基础上应用这些技术。
There are 4 ways in which SCTP differs from the description in RFC 1191 of applying MTU discovery to TCP:
SCTP与RFC 1191中关于将MTU发现应用于TCP的描述有4种不同的方式：
1) SCTP associations can span multiple addresses. An endpoint MUST maintain separate MTU estimates for each destination address of its peer.
1) SCTP关联可以跨越多个地址。端点必须为其对等方的每个目标地址维护单独的MTU估计值。
2) Elsewhere in this document, when the term "MTU" is discussed, it refers to the MTU associated with the destination address corresponding to the context of the discussion.
2) 在本文件的其他地方，当讨论术语“MTU”时，它是指与讨论上下文对应的目的地地址相关联的MTU。
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment Size". Accordingly, the MTU for each destination address SHOULD be initialized to a value no larger than the link MTU for the local interface to which packets for that remote destination address will be routed.
3) 与TCP不同，SCTP没有“最大段大小”的概念。相应地，每个目的地地址的MTU应初始化为不大于将该远程目的地地址的分组路由到的本地接口的链路MTU的值。
4) Since data transmission in SCTP is naturally structured in terms of TSNs rather than bytes (as is the case for TCP), the discussion in Section 6.5 of RFC 1191 applies: When retransmitting an IP datagram to a remote address for which the IP datagram appears too large for the path MTU to that address, the IP datagram SHOULD be retransmitted without the DF bit set, allowing it to possibly be fragmented. Transmissions of new IP datagrams MUST have DF set.
4) 由于SCTP中的数据传输自然是以TSN而不是字节（如TCP的情况）进行结构，RFC 1191第6.5节中的讨论适用：当将IP数据报重新传输到远程地址时，IP数据报对于该地址的路径MTU来说太大，IP数据报应在不设置DF位的情况下重新传输，使其可能被分段。新IP数据报的传输必须设置DF。
5) The sender should track an association PMTU which will be the smallest PMTU discovered for all of the peer's destination addresses. When fragmenting messages into multiple parts this association PMTU should be used to calculate the size of each fragment. This will allow retransmissions to be seamlessly sent to an alternate address without encountering IP fragmentation.
5) 发送方应跟踪关联PMTU，该关联PMTU将是为所有对等方的目标地址发现的最小PMTU。当将消息分成多个部分时，应使用此关联PMTU来计算每个片段的大小。这将允许将重传无缝地发送到备用地址，而不会遇到IP碎片。
Other than these differences, the discussion of TCP's use of MTU discovery in RFCs 1191 and 1981 applies to SCTP on a per-destination-address basis.
除了这些差异，RFCs 1191和1981中关于TCP使用MTU发现的讨论适用于每个目的地地址的SCTP。
Note: For IPv6 destination addresses the DF bit does not exist, instead the IP datagram must be fragmented as described in [RFC2460].
注意：对于IPv6目标地址，DF位不存在，相反，IP数据报必须按照[RFC2460]中所述进行分段。
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
端点应保留一个计数器，记录到其对等方的连续重传总数（包括到对等方的所有目的地传输地址的重传，如果它是多宿的）。如果该计数器的值超过协议参数关联.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）或从该对等端点接收到心跳确认时，都应重置计数器。
When its peer endpoint is multi-homed, an endpoint should keep a error counter for each of the destination transport addresses of the peer endpoint.
当其对等端点为多宿时，端点应为对等端点的每个目标传输地址保留一个错误计数器。
Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not acknowledged within a RTO, the error counter of that destination address will be incremented. When the value in the error counter exceeds the protocol parameter 'Path.Max.Retrans' of that destination address, the endpoint should mark the destination transport address as inactive, and a notification SHOULD be sent to the upper layer.
每当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 the SCTP chooses to function is implementation specific.
注意：配置SCTP端点时，用户应避免“Association.Max.Retrans”的值大于远程端点所有目标地址的“Path.Max.Retrans”之和。否则，当端点仍然认为对等端点可到达时，所有目标地址都可能变为非活动。当出现这种情况时，SCTP选择如何运行取决于具体的实现。
When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender MAY automatically transmit new packets to an alternate destination address if one exists and is active. If more than one alternate address is active when the primary path is marked inactive only ONE transport address SHOULD be chosen and used as the new destination transport address.
当主路径被标记为非活动时（例如，由于过度重传），发送方可以自动将新分组发送到备用目的地地址（如果存在并且是活动的）。如果主路径标记为非活动时有多个备用地址处于活动状态，则只应选择一个传输地址并将其用作新的目标传输地址。
By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es).
默认情况下，SCTP端点应通过定期向目标传输地址发送心跳数据块来监控其对等方的空闲目标传输地址的可达性。
A destination transport address is considered "idle" if no new chunk which can be used for updating path RTT (usually including first transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no HEARTBEAT has been sent to it within the current heartbeat period of that address. This applies to both active and inactive destination addresses.
如果没有可用于更新路径RTT的新块（通常包括第一次传输数据、初始化、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 field copied from the received HEARTBEAT chunk.
心跳的接收器应立即响应心跳确认，该确认包含从接收到的心跳块复制的心跳信息字段。
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, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
在允许心跳的空闲目标地址上，建议每个目标地址的RTO加上协议参数“HB.interval”发送一次心跳块，抖动为+/-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 a 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 Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
如果SCTP数据包的格式正确，即通过了接收方的Adler-32检查（见第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, 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. Otherwise,
3) 如果数据包包含验证标记设置为“0”的INIT块，请按照第5.1节中的说明进行处理。否则
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 no TCB was found. Otherwise,
5) 如果数据包包含SHUTDOWN ACK块，则接收方应以SHUTDOWN COMPLETE响应OOTB数据包的发送方。发送关机完成时，OOTB数据包的接收方必须使用关机确认中接收到的验证标签填写出站数据包的验证标签字段，并在区块标志中设置T位，以指示未找到TCB。否则
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 no TCB was found. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8) 接收方应以中止响应OOTB数据包的发送方。发送中止时，OOTB数据包的接收方必须使用在OOTB数据包的验证标签字段中找到的值填写出站数据包的验证标签字段，并在区块标志中设置T位以指示未找到TCB。发送此中止后，OOTB数据包的接收方应丢弃OOTB数据包，不再采取进一步的行动。
The Verification Tag rules defined in this section apply when sending or receiving SCTP packets which do not contain an INIT, SHUTDOWN COMPLETE, COOKIE ECHO (see Section 5.1), ABORT or SHUTDOWN ACK chunk. The rules for sending and receiving SCTP packets containing one of these chunk types are discussed separately in Section 8.5.1.
当发送或接收不包含INIT、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 shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known.
- 端点应始终在出站数据包的验证标签字段中填入目标端点的标签值（如果已知）。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果验证标签与其自己的标签或其对等方的标签匹配，则接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
C) Rules for packet carrying SHUTDOWN COMPLETE:
C） 数据包传送关闭规则完成：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST be used. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK.
- 发送关机完成时，如果关机确认的接收器具有TCB，则必须使用目标端点的标记。只有在不存在TCB的情况下，发送方才应使用关机确认中的验证标签。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag OR it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- 如果数据包的验证标签字段与其自己的标签匹配，或者设置为对等标签，并且在区块标志中设置了T位，则关闭完成的接收器应接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。如果端点未处于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 Initial Tag received in the INIT ACK.
- 发送COOKIE回显时，端点必须使用INIT ACK中接收的初始标记的值。
- 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 each peer will stop accepting new data from its user and only deliver data in queue at the time of sending or receiving the SHUTDOWN chunk.
端点应该在退出服务时终止其关联。关联可以通过中止或关闭来终止。根据定义，关联的中止是中止的，因为任何挂起在关联两端的数据都将被丢弃，而不会传递给对等方。关联的关闭被认为是一个优雅的关闭，其中任一端点的队列中的所有数据都被传递给相应的对等方。然而，在关机的情况下，SCTP不支持半开放状态（如TCP），其中一方可以继续发送数据，而另一端关闭。当任一端点执行关闭时，每个对等点上的关联将停止接受来自其用户的新数据，并且仅在发送或接收关闭区块时在队列中传递数据。
When an endpoint decides to abort an existing association, it shall send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT.
当端点决定中止现有关联时，它应向其对等端点发送中止块。发送方必须在出站数据包中填写对等方的验证标签，并且不得将任何数据块与中止捆绑在一起。
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 shall apply the special Verification Tag check rules described in Section 8.5.1.
接收中止的端点应采用第8.5.1节所述的特殊验证标签检查规则。
After checking the Verification Tag, the receiving endpoint shall remove the association from its record, and shall report the termination to its upper layer.
检查验证标签后，接收端点应从其记录中删除关联，并向其上层报告终止。
Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an endpoint in an association can gracefully close the association. This will allow all outstanding DATA chunks from the peer of the shutdown initiator to be delivered before the association terminates.
使用SHUTDOWN原语（参见第10.1节），关联中端点的上层可以优雅地关闭关联。这将允许在关联终止之前传递来自关机启动器对等方的所有未完成数据块。
Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters SHUTDOWN-PENDING state and remains there until all outstanding data has been acknowledged by its peer. The endpoint
在从其上层接收到SHUTDOWN原语后，端点进入SHUTDOWN-PENDING状态，并保持该状态，直到其对等方确认所有未完成的数据。终点
accepts no new data from its upper layer, but retransmits data to the far end if necessary to fill gaps.
不接受来自上层的新数据，但在必要时将数据重新传输到远端以填补空白。
Once all its outstanding data has been acknowledged, the endpoint shall send a SHUTDOWN chunk to its peer including in the Cumulative TSN Ack field the last sequential TSN it has received from the peer. It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN with the updated last sequential TSN received from its peer.
一旦确认了所有未完成的数据，端点应向其对等方发送一个关机区块，包括在累积TSN Ack字段中从对等方接收的最后一个连续TSN。然后，应启动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 the reception of the SHUTDOWN, the peer endpoint shall
接收到停机后，对等端点应
- enter the SHUTDOWN-RECEIVED state,
- 进入关机接收状态，
- stop accepting new data from its SCTP user
- 停止接受来自其SCTP用户的新数据
- verify, by checking the Cumulative TSN Ack field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN sender.
- 通过检查区块的累积TSN Ack字段，验证关机发送方是否已接收到其所有未完成的数据区块。
Once an endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
一旦端点达到SHUTDOWN-RECEIVED状态，它就不能发送SHUTDOWN来响应ULP请求，并且应该放弃后续的SHUTDOWN块。
If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
如果仍然存在未完成的数据块，停堆接收器应继续遵循第6节中规定的正常数据传输程序，直到所有未完成的数据块都得到确认；但是，关机接收器不得接受来自其SCTP用户的新数据。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
处于SHUTDOWN-SENT状态时，SHUTDOWN发送方必须立即使用SACK、SHUTDOWN chunk响应包含一个或多个数据块的每个接收数据包，并重新启动T2 SHUTDOWN定时器。如果
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
如果没有更多未处理的数据块，停机接收器应发送停机确认，并启动自己的T2停机计时器，进入停机确认发送状态。如果计时器过期，端点必须重新发送关机确认。
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 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 assure that all its outstanding DATA chunks have been acknowledged before initiating the shutdown procedure.
端点应确保在启动关闭过程之前已确认其所有未完成的数据块。
An endpoint should reject any new data request from its upper layer if it is in SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENT state.
如果端点处于SHUTDOWN-PENDING、SHUTDOWN-SENT、SHUTDOWN-RECEIVE或SHUTDOWN-ACK-SENT状态，那么它应该拒绝来自其上层的任何新数据请求。
If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination transport addresses (either in the IP addresses or in the INIT chunk) that belong to this association, it should discard the INIT chunk and retransmit the SHUTDOWN ACK chunk.
如果端点处于SHUTDOWN-ACK-SENT状态，并接收到具有属于此关联的源和目标传输地址（在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
INIT或COOKIE ECHO的发送方应在SCTP数据包中独立关闭完成后，响应SHUTDOWN-ACK的接收，其公共报头的验证标记字段设置为SHUTDOWN-ACK数据包中接收到的相同标记。这被视为第8.4节中定义的意外数据包。INIT的发送方允许T1 INIT继续运行并保持在
COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration will cause the INIT or COOKIE chunk to be retransmitted and thus start a new association.
COOKIE-WAIT或COOKIE-Echosed状态。正常的T1初始化计时器过期将导致重新传输初始化或COOKIE块，从而启动新关联。
If a SHUTDOWN is received in COOKIE WAIT or COOKIE ECHOED states the SHUTDOWN chunk SHOULD be silently discarded.
如果在COOKIE等待或COOKIE回显状态中接收到关机，则关机区块应被静默丢弃。
If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN chunk from its peer, the endpoint shall respond immediately with a SHUTDOWN ACK to its peer, and move into a SHUTDOWN-ACK-SENT state restarting its T2-shutdown timer.
如果端点处于SHUTDOWN-SENT状态并从其对等方接收到SHUTDOWN区块，则该端点应立即向其对等方发出SHUTDOWN ACK响应，并进入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 (ULP) shall request for services by passing primitives to SCTP and shall receive notifications from SCTP for various events.
上层协议（ULP）应通过向SCTP传递原语请求服务，并应接收来自SCTP的各种事件通知。
The primitives and notifications described in this section should be used as a guideline for implementing SCTP. The following functional description of ULP interface primitives is shown for illustrative purposes. Different SCTP implementations may have different ULP interfaces. However, all SCTPs must provide a certain minimum set of services to guarantee that all SCTP implementations can support the same protocol hierarchy.
本节中描述的原语和通知应作为实现SCTP的指南。以下ULP接口原语的功能描述用于说明目的。不同的SCTP实现可能具有不同的ULP接口。但是，所有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 the SCTP must perform to support inter-process communication. Individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls.
下面描述的ULP原语指定了SCTP必须执行的基本功能，以支持进程间通信。单个实现必须定义自己的精确格式，并且可以在单个调用中提供基本函数的组合或子集。
A) Initialize
A） 初始化
Format: INITIALIZE ([local port], [local eligible address list]) -> local SCTP instance name
格式：初始化（[本地端口]，[本地合格地址列表]）->本地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 which defines the endpoint (see Section 1.4). If the local SCTP instance has not been initialized, the ASSOCIATE is considered an error.
对等端点应由定义端点的传输地址之一指定（见第1.4节）。如果本地SCTP实例尚未初始化，则关联将被视为错误。
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 address from the returned destination addresses will be selected by the local endpoint as default primary path for sending SCTP packets to this peer. The returned "destination transport addr list" can be used by the ULP to change the default primary path or to force sending a packet to a specific transport address.
可以返回其他关联参数，包括对等方的完整目的地传输地址以及本地端点的出站流计数。本地端点将从返回的目标地址中选择一个传输地址作为向该对等方发送SCTP数据包的默认主路径。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 关联id-SCTP关联的本地句柄
Optional attributes:
可选属性：
None.
没有一个
D) Abort
D） 流产
Format: ABORT(association id [, cause code]) -> result
格式：中止（关联id[，原因代码]）->结果
Ungracefully closes an association. Any locally queued user data will be discarded and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned.
笨拙地关闭一个协会。任何本地排队的用户数据都将被丢弃，并向对等方发送一个中止块。成功终止关联时将返回成功代码。如果试图中止关联导致失败，则应返回错误代码。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联id-SCTP关联的本地句柄
Optional attributes:
可选属性：
o cause code - reason of the abort to be passed to the peer.
o 原因代码-将中止传递给对等方的原因。
None.
没有一个
E) Send
E） 发送
Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> result
格式：发送（关联id、缓冲区地址、字节计数[、上下文][、流id][、生存期][、目标传输地址][、无序标志][、无捆绑标志][、有效负载协议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 关联id-SCTP关联的本地句柄
o buffer address - the location where the user message to be transmitted is stored;
o 缓冲区地址—存储要传输的用户消息的位置；
o byte count - The size of the user data in number of bytes;
o 字节计数-用户数据的大小（以字节为单位）；
Optional attributes:
可选属性：
o context - an optional 32 bit integer that will be carried in the sending failure notification to the ULP if the transportation of this User Message fails.
o 上下文-如果此用户消息的传输失败，将在向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 lifetime option, the transmitter may hold back the assigning of the TSN number to an outbound DATA chunk to the last moment. And, for implementation simplicity, once a TSN number has been assigned the sender should consider the send of this DATA chunk as committed, overriding any lifetime option attached to the DATA chunk.
实施说明：为了更好地支持数据生存期选项，发送器可能会将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 unorder flag - this flag, if present, indicates that the user would like the data delivered in an unordered fashion to the peer (i.e., the U flag is set to 1 on all DATA chunks carrying this message).
o 无序标志-此标志（如果存在）表示用户希望以无序方式将数据交付给对等方（即，在承载此消息的所有数据块上，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 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 关联id-SCTP关联的本地句柄
o destination transport address - specified as one of the transport addresses of the peer endpoint, which should be used as primary address for sending packets. This overrides the current primary address information maintained by the local SCTP endpoint.
o 目标传输地址-指定为对等端点的传输地址之一，该地址应用作发送数据包的主地址。这将覆盖由本地SCTP端点维护的当前主地址信息。
Optional attributes:
可选属性：
o source transport address - optionally, some implementations may allow you to set the default source address placed in all outgoing IP datagrams.
o 源传输地址—可选地，某些实现可能允许您设置所有传出IP数据报中的默认源地址。
G) Receive
G） 接收
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]
格式：接收（关联id、缓冲区地址、缓冲区大小[，流id]）->字节计数[，传输地址][，流id][，流序列号][，部分标志][，传递号][，有效负载协议id]
This primitive shall read the first user message in the SCTP in-queue into the buffer specified by ULP, if there is one available. The size of the message read, in bytes, will be returned. It may, depending on the specific implementation, also return other information such as the sender's address, the stream id on which it is received, whether there are more messages available for retrieval, etc. For ordered messages, their stream sequence number may also be returned.
该原语应将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 关联id-SCTP关联的本地句柄
Optional attributes:
可选属性：
None.
没有一个
I) Change Heartbeat
一） 改变心跳
Format: CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> result
格式：CHANGEHEARTBEAT（关联id、目标传输地址、新状态[，间隔]）->结果
Instructs the local endpoint to enable or disable heartbeat on the specified destination transport address.
指示本地端点在指定的目标传输地址上启用或禁用检测信号。
The result of attempting this operation shall be returned.
应返回尝试此操作的结果。
Note: Even when enabled, heartbeat will not take place if the destination transport address is not idle.
注意：即使启用，如果目标传输地址不是空闲的，心跳也不会发生。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联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, effects all destinations.
o 间隔-如果存在，则指示心跳频率（如果这是为了在目标传输地址上启用心跳）。此值将添加到目标传输地址的RTO中。此值（如果存在）影响所有目的地。
J) Request HeartBeat
J） 请求心跳
Format: REQUESTHEARTBEAT(association id, destination transport address) -> result
格式：REQUESTHEARTBEAT（关联id，目标传输地址）->结果
Instructs the local endpoint to perform a HeartBeat on the specified destination transport address of the given association. The returned result should indicate whether the transmission of the HEARTBEAT chunk to the destination address is successful.
指示本地端点在给定关联的指定目标传输地址上执行检测信号。返回的结果应该指示心跳块到目标地址的传输是否成功。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联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 关联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) -> result
格式：setFailureReshold（关联id、目标传输地址、故障阈值）->结果
This primitive allows the local SCTP to customize the reachability failure detection threshold 'Path.Max.Retrans' for the specified destination address.
此原语允许本地SCTP自定义指定目标地址的可达性故障检测阈值“Path.Max.Retrans”。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联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 关联id-SCTP关联的本地句柄
o protocol parameter list - The specific names and values of the protocol parameters (e.g., Association.Max.Retrans [see Section 14]) that the SCTP user wishes to customize.
o 协议参数列表-SCTP用户希望自定义的协议参数的特定名称和值（例如，Association.Max.Retrans[参见第14节]）。
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 be 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 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 an ULP process, certain information is passed to the ULP.
假定操作系统或应用程序环境为SCTP提供了一种异步向ULP进程发送信号的方法。当SCTP发出ULP进程信号时，某些信息会传递给ULP。
IMPLEMENTATION NOTE: In some cases this may be done through a separate socket or error channel.
实现说明：在某些情况下，这可以通过单独的套接字或错误通道完成。
A) DATA ARRIVE notification
A） 数据到达通知
SCTP shall invoke this notification on the ULP when a user message is successfully received and ready for retrieval.
当成功接收并准备检索用户消息时，SCTP应在ULP上调用此通知。
The following may be optionally be passed with the notification:
可以选择随通知一起传递以下内容：
o association id - local handle to the SCTP association
o 关联id-SCTP关联的本地句柄
o stream id - to indicate which stream the data is received on.
o 流id—指示在哪个流上接收数据。
B) SEND FAILURE notification
B） 发送失败通知
If a message can not be delivered SCTP shall invoke this notification on the ULP.
如果无法发送消息，SCTP应在ULP上调用此通知。
The following may be optionally be passed with the notification:
可以选择随通知一起传递以下内容：
o association id - local handle to the SCTP association
o 关联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 关联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 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.
实现说明：如果关联原语作为阻塞函数调用实现，则关联参数将作为关联原语本身的结果返回。在这种情况下，在关联发起方一侧，通信启动通知是可选的。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - local handle to the SCTP association
o 关联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 关联id-SCTP关联的本地句柄
o status - This indicates what type of event has occurred; The status may indicate a failure OR a normal termination event occurred in response to a shutdown or abort request.
o 状态-指示发生了什么类型的事件；该状态可能表示在响应关机或中止请求时发生了故障或正常终止事件。
The following may be passed with the notification:
以下内容可随通知一起传递：
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o 数据检索id—用于检索未发送和未确认数据的标识。
o last-acked - the TSN last acked by that peer endpoint;
o last acked—该对等端点上次确认的TSN；
o last-sent - the TSN last sent to that peer endpoint;
o last sent—上次发送到该对等端点的TSN；
F) COMMUNICATION ERROR notification
F） 通信错误通知
When SCTP receives an ERROR chunk from its peer and decides to notify its ULP, it can invoke this notification on the ULP.
当SCTP从其对等方接收到错误块并决定通知其ULP时，它可以在ULP上调用此通知。
The following can be passed with the notification:
以下内容可随通知一起传递：
o association id - local handle to the SCTP association
o 关联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 关联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 关联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 operator(s) 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。
In order to promote software code-reuse, to avoid re-inventing the wheel, and to avoid gratuitous complexity to SCTP, the IP Authentication Header [RFC2402] SHOULD be used when the threat environment requires stronger integrity protections, but does not require confidentiality.
为了促进软件代码重用，避免重新发明轮子，并避免SCTP的无端复杂性，当威胁环境需要更强的完整性保护，但不需要保密性时，应使用IP认证头[RFC2402]。
A widely implemented BSD Sockets API extension exists for applications to request IP security services, such as AH or ESP from an operating system kernel. Applications can use such an API to request AH whenever AH use is appropriate.
广泛实现的BSD套接字API扩展适用于从操作系统内核请求IP安全服务（如AH或ESP）的应用程序。只要AH使用合适，应用程序就可以使用这样的API来请求AH。
In most cases, the risk of breach of confidentiality applies to the signaling data payload, not to the SCTP or lower-layer protocol overheads. If that is true, encryption of the SCTP user data only might be considered. As with the supplementary checksum service, user data encryption MAY be performed by the SCTP user application.
在大多数情况下，违反保密性的风险适用于信令数据有效载荷，而不是SCTP或较低层协议开销。如果这是真的，则可能只考虑对SCTP用户数据进行加密。与补充校验和服务一样，用户数据加密可由SCTP用户应用程序执行。
Alternately, the user application MAY use an implementation-specific API to request that the IP Encapsulating Security Payload (ESP) [RFC2406] be used to provide confidentiality and integrity.
或者，用户应用程序可以使用特定于实现的API来请求使用IP封装安全有效载荷（ESP）[RFC2406]来提供机密性和完整性。
Particularly for mobile users, the requirement for confidentiality might include the masking of IP addresses and ports. In this case ESP SHOULD be used instead of application-level confidentiality. If ESP is used to protect confidentiality of SCTP traffic, an ESP cryptographic transform that includes cryptographic integrity protection MUST be used, because if there is a confidentiality threat there will also be a strong integrity threat.
特别是对于移动用户，保密要求可能包括屏蔽IP地址和端口。在这种情况下，应使用ESP，而不是应用程序级机密性。如果ESP用于保护SCTP流量的机密性，则必须使用包含加密完整性保护的ESP加密转换，因为如果存在机密性威胁，也将存在强大的完整性威胁。
Whenever ESP is in use, application-level encryption is not generally required.
每当使用ESP时，通常不需要应用程序级加密。
Regardless of where confidentiality is provided, the ISAKMP [RFC2408] and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key management.
无论在何处提供机密性，ISAKMP[RFC2408]和Internet密钥交换（IKE）[RFC2409]都应用于密钥管理。
Operators should consult [RFC2401] for more information on the security services available at and immediately above the Internet Protocol layer.
运营商应咨询[RFC2401]以了解更多关于互联网协议层上可用安全服务的信息。
A blind attack is one where the attacker is unable to intercept or otherwise see the content of data flows passing to and from the target SCTP node. Blind denial of service attacks may take the form of flooding, masquerade, or improper monopolization of services.
盲攻击是指攻击者无法截获或以其他方式看到进出目标SCTP节点的数据流内容的攻击。盲目拒绝服务攻击可能采取泛滥、伪装或不当垄断服务的形式。
The objective of flooding is to cause loss of service and incorrect behavior at target systems through resource exhaustion, interference with legitimate transactions, and exploitation of buffer-related software bugs. Flooding may be directed either at the SCTP node or at resources in the intervening IP Access Links or the Internet. Where the latter entities are the target, flooding will manifest itself as loss of network services, including potentially the breach of any firewalls in place.
洪水泛滥的目的是通过资源耗尽、干扰合法事务以及利用与缓冲区相关的软件漏洞，在目标系统上造成服务损失和错误行为。洪泛可以被定向到SCTP节点或中间IP接入链路或因特网中的资源。如果后一种实体是目标，洪水将表现为网络服务的损失，包括可能破坏任何现有防火墙。
In general, protection against flooding begins at the equipment design level, where it includes measures such as:
一般而言，防淹保护从设备设计层面开始，包括以下措施：
- avoiding commitment of limited resources before determining that the request for service is legitimate
- 在确定服务请求是否合法之前避免承诺有限的资源
- giving priority to completion of processing in progress over the acceptance of new work
- 优先完成正在进行的加工，而不是接受新工作
- identification and removal of duplicate or stale queued requests for service.
- 识别和删除重复或过时的排队服务请求。
- not responding to unexpected packets sent to non-unicast addresses.
- 不响应发送到非单播地址的意外数据包。
Network equipment should be capable of generating an alarm and log if a suspicious increase in traffic occurs. The log should provide information such as the identity of the incoming link and source address(es) used which will help the network or SCTP system operator to take protective measures. Procedures should be in place for the operator to act on such alarms if a clear pattern of abuse emerges.
如果流量出现可疑增加，网络设备应能够生成警报和日志。日志应提供诸如传入链路的标识和使用的源地址等信息，以帮助网络或SCTP系统运营商采取保护措施。如果出现明显的滥用模式，应制定程序，以便操作员对此类警报采取行动。
The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way start-up handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association.
SCTP的设计能够抵抗洪水攻击，特别是在使用四路启动握手、使用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 INIT's to multiple hosts in a given domain. In addition, an attacker could use the Host Name feature in an indirect attack on a third party by sending large numbers of INITs to random hosts containing the host name of the target. In addition to the strain on DNS resources, this could also result in large numbers of INIT ACKs being sent to the target. One method to protect against this type of attack is to verify that the IP addresses received from DNS include the source IP address of the original INIT. If the list of IP addresses received from DNS does not include the source IP address of the INIT, the endpoint MAY silently discard the INIT. This last option will not protect against the attack against the DNS.
在INIT区块中使用主机名功能可用于淹没目标DNS服务器。通过向给定域中的多个主机发送INIT，可以完成大量积压的DNS查询，将INIT块中接收的主机名解析为IP地址。此外，攻击者可以通过向包含目标主机名的随机主机发送大量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 which cause the impersonated node to be locked out of the target SCTP node.
- 通过故意允许检测模拟，从而引发导致模拟节点被锁定在目标SCTP节点之外的对策。
- by interfering with an established association by inserting extraneous content such as a SHUTDOWN request.
- 通过插入无关内容（如关机请求）来干扰已建立的关联。
SCTP reduces the risk of blind masquerade attacks through IP spoofing by use of the four-way startup handshake. Man-in-the-middle masquerade attacks are discussed in Section 11.3 below. Because the initial exchange is memoryless, no lockout mechanism is triggered by blind masquerade attacks. In addition, the INIT ACK containing the State Cookie is transmitted back to the IP address from which it received the INIT. Thus the attacker would not receive the INIT ACK containing the State Cookie. SCTP protects against insertion of extraneous packets into the flow of an established association by use of the Verification Tag.
SCTP通过使用四路启动握手通过IP欺骗降低盲伪装攻击的风险。下文第11.3节讨论了中间人伪装攻击。因为初始交换是无记忆的，所以盲伪装攻击不会触发锁定机制。此外，包含状态Cookie的INIT ACK被传输回它从中接收INIT的IP地址。因此，攻击者不会收到包含状态Cookie的INIT ACK。SCTP通过使用验证标签防止将无关数据包插入到已建立关联的流中。
Logging of received INIT requests and abnormalities such as unexpected INIT ACKs might be considered as a way to detect patterns of hostile activity. However, the potential usefulness of such logging must be weighed against the increased SCTP startup processing it implies, rendering the SCTP node more vulnerable to flooding attacks. Logging is pointless without the establishment of operating procedures to review and analyze the logs on a routine basis.
记录收到的初始化请求和异常（如意外的初始化确认）可能被视为检测恶意活动模式的一种方法。然而，这种日志记录的潜在用途必须与它所暗示的增加的SCTP启动处理进行权衡，从而使SCTP节点更容易受到洪水攻击。如果没有建立日常检查和分析日志的操作程序，日志记录是毫无意义的。
Attacks under this heading are performed openly and legitimately by the attacker. They are directed against fellow users of the target SCTP node or of the shared resources between the attacker and the target node. Possible attacks include the opening of a large number of associations between the attacker's node and the target, or transfer of large volumes of information within a legitimately-established association.
此标题下的攻击由攻击者公开合法地执行。它们针对的是目标SCTP节点或攻击者与目标节点之间共享资源的其他用户。可能的攻击包括在攻击者的节点和目标之间打开大量关联，或在合法建立的关联中传输大量信息。
Policy limits should be placed on the number of associations per adjoining SCTP node. SCTP user applications should be capable of detecting large volumes of illegitimate or "no-op" messages within a given association and either logging or terminating the association as a result, based on local policy.
应该对每个相邻SCTP节点的关联数设置策略限制。SCTP用户应用程序应能够检测给定关联内的大量非法或“无操作”消息，并根据本地策略记录或终止关联。
The objective of fraud is to obtain services without authorization and specifically without paying for them. In order to achieve this objective, the attacker must induce the SCTP user application at the target SCTP node to provide the desired service while accepting invalid billing data or failing to collect it. Repudiation is a related problem, since it may occur as a deliberate act of fraud or simply because the repudiating party kept inadequate records of service received.
欺诈的目的是在未经授权的情况下获得服务，特别是在不付费的情况下。为了实现这一目标，攻击者必须诱导目标SCTP节点上的SCTP用户应用程序提供所需服务，同时接受无效的计费数据或无法收集数据。拒付是一个相关的问题，因为它可能是故意欺诈行为，或者仅仅是因为拒付方对收到的服务记录不足。
Potential fraudulent attacks include interception and misuse of authorizing information such as credit card numbers, blind masquerade and replay, and man-in-the middle attacks which modify the packets passing through a target SCTP association in real time.
潜在的欺诈攻击包括拦截和滥用授权信息，如信用卡号、盲伪装和重播，以及中间人攻击，这些攻击实时修改通过目标SCTP关联的数据包。
The interception attack is countered by the confidentiality measures discussed in Section 11.2.3 above.
拦截攻击通过上文第11.2.3节讨论的保密措施进行反击。
Section 11.2.4.2 describes how SCTP is resistant to blind masquerade attacks, as a result of the four-way startup handshake and the Verification Tag. The Verification Tag and TSN together are protections against blind replay attacks, where the replay is into an existing association.
第11.2.4.2节描述了SCTP如何抵抗由于四向启动握手和验证标签而产生的盲伪装攻击。验证标签和TSN一起是针对盲重播攻击的保护措施，其中重播进入现有关联。
However, SCTP does not protect against man-in-the-middle attacks where the attacker is able to intercept and alter the packets sent and received in an association. For example, the INIT ACK will have sufficient information sent on the wire for an adversary in the middle to hijack an existing SCTP association. Where a significant possibility of such attacks is seen to exist, or where possible repudiation is an issue, the use of the IPSEC AH service is recommended to ensure both the integrity and the authenticity of the SCTP packets passed.
但是，SCTP不能防止中间人攻击，因为攻击者能够拦截和更改关联中发送和接收的数据包。例如，init ACK将有足够的信息在网上发送给中间的对手来劫持现有的SCTP关联。如果发现存在此类攻击的重大可能性，或者存在可能的拒绝问题，建议使用IPSEC AH服务以确保传递的SCTP数据包的完整性和真实性。
SCTP also provides no protection against attacks originating at or beyond the SCTP node and taking place within the context of an existing association. Prevention of such attacks should be covered by appropriate security policies at the host site, as discussed in Section 11.2.1.
SCTP也不提供针对源自SCTP节点或SCTP节点之外以及在现有关联上下文中发生的攻击的保护。如第11.2.1节所述，主机站点的适当安全政策应涵盖此类攻击的预防。
This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization.
本节详细介绍了一组建议的参数，这些参数应包含在TCB中，用于实现。本节仅供说明，不应视为实施要求或SCTP TCB内所有参数的详尽列表。每个实现可能需要自己的额外参数进行优化。
Associations: A list of current associations and mappings to the data consumers for each association. This may be in the form of a hash table or other implementation dependent structure. The data consumers may be process identification information such as file descriptors, named pipe pointer, or table pointers dependent on how SCTP is implemented.
关联：每个关联的当前关联和到数据使用者的映射的列表。这可以是哈希表或其他依赖于实现的结构的形式。根据SCTP的实现方式，数据使用者可以是进程标识信息，例如文件描述符、命名管道指针或表指针。
Secret Key: A secret key used by this endpoint to compute the MAC. This SHOULD be a cryptographic quality random number with a sufficient length. Discussion in [RFC1750] can be helpful in selection of the key.
密钥：此端点用于计算MAC的密钥。这应该是具有足够长度的加密质量随机数。[RFC1750]中的讨论有助于选择键。
Address List: The list of IP addresses that this instance has bound. This information is passed to one's peer(s) in INIT and INIT ACK chunks.
地址列表：此实例已绑定的IP地址列表。此信息在INIT和INIT ACK块中传递给对等方。
SCTP Port: The local SCTP port number the endpoint is bound to.
SCTP端口：端点绑定到的本地SCTP端口号。
Peer : Tag value to be sent in every packet and is received Verification: in the INIT or INIT ACK chunk. Tag :
对等：在每个数据包中发送的标记值，并在INIT或INIT ACK块中通过验证接收。标签：
My : Tag expected in every inbound packet and sent in the Verification: INIT or INIT ACK chunk. Tag :
每个入站数据包中都需要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 that the peer is Transport : bound to. This information is derived from the INIT or Address : INIT ACK and is used to associate an inbound packet List : with a given association. Normally this information is : hashed or keyed for quick lookup and access of the TCB.
对等方：对等方传输：绑定到的SCTP传输地址列表。此信息来自INIT或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 TSN's have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e. no out of order
: packets have been received, this array will be set to
: all zero. This structure may be in the form of a
: circular buffer or bit array.
Mapping : An array of bits or bytes indicating which out of
Array : order TSN's have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e. no out of order
: packets have been received, this array will be set to
: all zero. This structure may be in the form of a
: circular buffer or bit array.
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA chunks
: are out of order, SACK's are not delayed (see Section
: 6).
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA chunks
: are out of order, SACK's are not delayed (see Section
: 6).
Inbound : An array of structures to track the inbound streams. Streams : Normally including the next sequence number expected : and possibly the stream number.
Inbound：用于跟踪入站流的结构数组。流：通常包括预期的下一个序列号：可能还包括流号。
Outbound : An array of structures to track the outbound streams. Streams : Normally including the next sequence number to : be sent on the stream.
Outbound：跟踪出站流的结构数组。流：通常包括流上要发送的下一个序列号。
Reasm Queue : A re-assembly queue.
Reasm队列：重新组装队列。
Local : The list of local IP addresses bound in to this Transport : association. Address : List :
本地：绑定到此传输：关联的本地IP地址列表。地址：名单：
Association : The smallest PMTU discovered for all of the PMTU : peer's transport addresses.
关联：为所有PMTU: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 needs to be maintained including:
对于从INIT或INIT ACK块派生的对等方地址列表中的每个目标传输地址，需要维护许多数据元素，包括：
Error count : The current error count for this destination.
错误计数：此目标的当前错误计数。
Error : Current error threshold for this destination i.e. Threshold : what value marks the destination down if Error count : reaches this value.
错误：此目标的当前错误阈值，即阈值：如果错误计数：达到此值，则什么值标记目标。
cwnd : The current congestion window.
cwnd：当前拥塞窗口。
ssthresh : The current ssthresh value.
ssthresh：当前ssthresh值。
RTO : The current retransmission timeout value.
RTO：当前重传超时值。
SRTT : The current smoothed round trip time.
SRTT：当前平滑往返时间。
RTTVAR : The current RTT variation.
RTTVAR：当前RTT变化。
partial : The tracking method for increase of cwnd when in bytes acked : congestion avoidance mode (see Section 6.2.2)
部分：在字节确认时cwnd增加的跟踪方法：拥塞避免模式（见第6.2.2节）
state : The current state of this destination, i.e. DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, etc.
状态：此目的地的当前状态，即向下、向上、：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 a RTT. If this flag is 0, the next DATA chunk sent to this destination should be used to compute a RTT and this flag should be set. Every time the RTT calculation completes (i.e. the DATA chunk is SACK'd) clear this flag.
RTO挂起：用于跟踪发送到此地址的数据块之一当前是否用于计算RTT的标志。如果此标志为0，则发送到此目的地的下一个数据块应用于计算RTT，并且应设置此标志。每次RTT计算完成时（即，数据块被丢弃），清除此标志。
last-time : The time this destination was last sent to. This can be used : used 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：入站数据块的队列。
This protocol will require port reservation like TCP for the use of "well known" servers within the Internet. All current TCP ports shall be automatically reserved in the SCTP port address space. New requests should follow IANA's current mechanisms for TCP.
此协议将需要像TCP一样的端口预留，以便在Internet中使用“知名”服务器。所有当前TCP端口应自动保留在SCTP端口地址空间中。新请求应遵循IANA当前的TCP机制。
This protocol may also be extended through IANA in three ways:
本协议也可通过IANA以三种方式扩展：
-- through definition of additional chunk types,
-- through definition of additional parameter types, or
-- through definition of additional cause codes within
ERROR chunks
-- through definition of additional chunk types,
-- through definition of additional parameter types, or
-- through definition of additional cause codes within
ERROR chunks
In the case where a particular ULP using SCTP desires to have its own ports, the ULP should be responsible for registering with IANA for getting its ports assigned.
如果使用SCTP的特定ULP希望拥有自己的端口，ULP应负责向IANA注册以获得其端口分配。
The definition and use of new chunk types is an integral part of SCTP. Thus, new chunk types are assigned by IANA through an IETF Consensus action as defined in [RFC2434].
新块类型的定义和使用是SCTP不可或缺的一部分。因此，IANA通过[RFC2434]中定义的IETF一致行动分配新的区块类型。
The documentation for a new chunk code type must include the following information:
新区块代码类型的文档必须包括以下信息：
a) A long and short name for the new chunk type;
a) 新块类型的长名称和短名称；
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2;
b) 区块结构的详细说明，必须符合第3.2节中定义的基本结构；
c) A detailed definition and description of intended use of each field within the chunk, including the chunk flags if any;
c) 区块内每个字段预期用途的详细定义和说明，包括区块标志（如有）；
d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.
d) 协议操作中使用新块类型的详细过程描述。
The last chunk type (255) is reserved for future extension if necessary.
最后一个块类型（255）保留供将来扩展（如有必要）。
The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新区块参数类型代码的分配通过[RFC2434]中定义的IETF一致行动完成。区块参数的文档必须包含以下信息：
a) Name of the parameter type.
a) 参数类型的名称。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1.
b) 参数字段结构的详细说明。该结构必须符合第3.2.1节所述的通用类型长度值格式。
c) Detailed definition of each component of the parameter value.
c) 参数值的每个组件的详细定义。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一块中找到此参数类型的多个实例的指示。
Additional cause codes may be allocated in the range 11 to 65535 through a Specification Required action as defined in [RFC2434]. Provided documentation must include the following information:
可通过[RFC2434]中定义的规范要求的措施，在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 which receives an ERROR (or ABORT) chunk containing this cause code.
c) 接收包含此原因代码的错误（或中止）区块的SCTP终结点的预期操作。
d) Detailed description of the structure and content of data fields which accompany this cause code.
d) 此原因代码附带的数据字段的结构和内容的详细说明。
The initial word (32 bits) of a cause code parameter MUST conform to the format shown in Section 3.3.10, i.e.:
原因码参数的初始字（32位）必须符合第3.3.10节所示的格式，即：
-- first two bytes contain the cause code value
-- last two bytes contain length of the Cause Parameter.
-- first two bytes contain the cause code value
-- last two bytes contain length of the Cause Parameter.
Except for value 0 which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data.
除SCTP保留的值0表示数据块中未指定的有效负载协议标识符外，SCTP不负责标准化或验证任何有效负载协议标识符；SCTP只是从上层接收标识符，并将其与相应的有效负载数据一起携带。
The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP.
如果需要，上层即SCTP用户应使用IANA标准化任何特定协议标识符。任何特定有效负载协议标识符的使用都超出了SCTP的范围。
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
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应按照上述建议进行设置。
The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their invaluable comments.
作者希望感谢马克·奥尔曼、R.J.阿特金森、理查德·班德、斯科特·布拉德纳、史蒂夫·贝洛文、彼得·巴特勒、拉姆·丹图、R.Ezhipavai、迈克·菲斯克、萨莉·弗洛伊德、福本阿特寿、马特·霍德雷格、亨利·侯赫、克里斯蒂安·惠特马、加里·莱切卡、乔纳森·李、大卫·莱曼、约翰·洛尼、丹尼尔·卢安、巴里·纳格尔伯格、托马斯·纳腾、埃里克·诺德马克、，林登·翁、谢亚马尔·普拉萨德、开尔文·波特、海因茨·普兰特纳、雅诺·拉贾哈尔梅、雷蒙德·里夫斯、雷尼·雷维斯、伊万·阿里亚斯·罗德里格斯、A·桑卡尔、格雷格·西德巴顿、布莱恩·怀尔德、拉蒙特·亚罗以及其他许多人的宝贵评论。
Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA
Randall R.Stewart 24号燃烧丛林小道。美国伊利诺伊州水晶湖60012
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA
谢乔平摩托罗拉公司，美国伊利诺伊州阿灵顿高地2309号舒尔大道西1501号，邮编60004
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA
Ken Morneault Cisco Systems Inc.美国弗吉尼亚州赫恩登市杜勒斯技术大道13615号，邮编：20171
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Chip Sharp Cisco Systems Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
奇普思科系统有限公司，地址：美国北卡罗来纳州基特克里克路研究三角公园7025号，邮编：27709
Phone: +1-919-392-3121
EMail: chsharp@cisco.com
Phone: +1-919-392-3121
EMail: chsharp@cisco.com
Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich Germany
Hanns Juergen Schwarzbauer西门子公司Hofmannstr。5181359德国慕尼黑
Phone: +49-89-722-24236
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Phone: +49-89-722-24236
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Tom Taylor Nortel Networks 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8
Tom Taylor Nortel Networks加拿大安大略省渥太华洛林大道1852号K1H 6Z8
Phone: +1-613-736-0961
EMail: taylor@nortelnetworks.com
Phone: +1-613-736-0961
EMail: taylor@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000 Australia
澳大利亚维多利亚州墨尔本伊丽莎白街37/360号Ian Rytina Ericsson Australia 3000
Phone: +61-3-9301-6164
EMail: ian.rytina@ericsson.com
Phone: +61-3-9301-6164
EMail: ian.rytina@ericsson.com
Malleswar Kalla Telcordia Technologies 3 Corporate Place PYA-2J-341 Piscataway, NJ 08854 USA
Malleswar Kalla Telcordia Technologies美国新泽西州皮斯卡塔韦PYA-2J-341企业广场3号，邮编08854
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA
加州大学洛杉矶分校计算机科学系4531G Boelter Hall洛杉矶，加利福尼亚90095-1596
Phone: +1-310-825-2695
EMail: lixia@cs.ucla.edu
Phone: +1-310-825-2695
EMail: lixia@cs.ucla.edu
Vern Paxson ACIRI 1947 Center St., Suite 600, Berkeley, CA 94704-1198 USA
Vern Paxson ACIRI 1947中心街600室，加利福尼亚州伯克利，邮编94704-1198
Phone: +1-510-666-2882
EMail: vern@aciri.org
Phone: +1-510-666-2882
EMail: vern@aciri.org
[RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.（编辑），“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.（编辑），“传输控制协议”，标准7，RFC793，1981年9月。
[RFC1123] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，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月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]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月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]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月。
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]Allman，M.和Paxson，V.，“关于估算端到端网络路径属性”，Proc。SIGCOMM'991999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[Fall 96]Fall，K.和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]伊斯特莱克，D.（编辑），“安全的随机性建议”，RFC17501994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年3月。
[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月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，Anderson，T.，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，29（5），1999年10月。
Appendix A: Explicit Congestion Notification
附录A：明确拥塞通知
ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", RFC 2481, January 1999) describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general RFC 2481 should be followed with the following exceptions.
ECN（Ramakrishnan，K.，Floyd，S.，“显式拥塞通知”，RFC 2481，1999年1月）描述了一个提议的IP扩展，详细说明了在数据报丢失之外感知拥塞的方法。这是实现可以选择添加到SCTP的可选功能。本附录详细说明了实施者在选择实施此功能时需要注意的细微差异。一般情况下，应遵循RFC 2481，但以下例外情况除外。
Negotiation:
谈判：
RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets two bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to assure both sides are truly ECN capable. For SCTP this is not necessary. To indicate that an endpoint is ECN capable an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus has the following format:
RFC2481详细说明了TCP连接的SYN和SYN-ACK阶段期间的ECN协商。SYN的发送方在TCP标志中设置两位，而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回波：
RFC 2481 details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e. the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows:
RFC 2481详细说明了接收方在其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:
无缝线路：
RFC 2481 details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window. This is termed the CWR bit. For SCTP the same indication is made by including the CWR chunk. This chunk contains one data element, i.e. the TSN number that was sent in the ECNE chunk. This element represents the lowest TSN number in the datagram that was originally marked with the CE bit.
RFC 2481详细说明了发送方在其下一个出站TCP段的报头中要发送的特定位，以向其对等方表明其已减少了拥塞窗口。这被称为CWR位。对于SCTP，通过包括CWR块来进行相同的指示。此区块包含一个数据元素，即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被视为一个控制块。
Appendix B Alder 32 bit checksum calculation
附录B Alder 32位校验和计算
The Adler-32 checksum calculation given in this appendix is copied from [RFC1950].
本附录中给出的Adler-32校验和计算从[RFC1950]复制而来。
Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order.
Adler-32由每个字节累积的两个和组成：s1是所有字节的和，s2是所有s1值的和。这两个和都是以65521模计算的。s1初始化为1，s2初始化为0。Adler-32校验和按网络字节顺序存储为s2*65536+s1。
The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
下面的C代码计算数据缓冲区的Adler-32校验和。它是为了清晰而写的，不是为了速度。示例代码采用ANSI C编程语言。非C用户可能会发现使用以下提示更容易阅读：
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should be
initialized to 1.
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should be
initialized to 1.
Usage example:
用法示例：
unsigned long adler = 1L;
无符号长adler=1L；
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。