Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8540 Netflix, Inc.
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
M. Proshin
Ericsson
February 2019
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8540 Netflix, Inc.
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
M. Proshin
Ericsson
February 2019
Stream Control Transmission Protocol: Errata and Issues in RFC 4960
流控制传输协议：RFC4960中的勘误表和问题
Abstract
摘要
This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided.
本文档是自2007年9月RFC 4960发布以来发现的问题的汇编，基于实施、测试和使用流控制传输协议（SCTP）以及建议的修复的经验。本文件提供RFC 4960的增量，并按时间顺序组织。这些问题按提出的顺序列出。由于某些文本经过多次更改，因此应应用文本中的最后一个增量。除了增量之外，还提供了每个问题的描述以及每个问题的解决方案的详细信息。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8540.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8540.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper-Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-Bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20
3.13. HEARTBEAT ACK and the Association Error Counter . . . . . 21
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24
3.17. Automatically CONFIRMED Addresses . . . . . . . . . . . . 25
3.18. Only One Packet after Retransmission Timeout . . . . . . 26
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27
3.20. Zero Window Probing and Unreachable Primary Path . . . . 28
3.21. Normative Language in Section 10 of RFC 4960 . . . . . . 29
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32
3.23. Inconsistent Handling of Notifications . . . . . . . . . 33
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39
3.26. Increasing the cwnd in the Congestion Avoidance Phase . . 41
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43
3.28. Window Updates after Receiver Window Opens Up . . . . . . 45
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper-Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-Bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20
3.13. HEARTBEAT ACK and the Association Error Counter . . . . . 21
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24
3.17. Automatically CONFIRMED Addresses . . . . . . . . . . . . 25
3.18. Only One Packet after Retransmission Timeout . . . . . . 26
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27
3.20. Zero Window Probing and Unreachable Primary Path . . . . 28
3.21. Normative Language in Section 10 of RFC 4960 . . . . . . 29
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32
3.23. Inconsistent Handling of Notifications . . . . . . . . . 33
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39
3.26. Increasing the cwnd in the Congestion Avoidance Phase . . 41
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43
3.28. Window Updates after Receiver Window Opens Up . . . . . . 45
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 46
3.30. "Outstanding Data", "Flightsize", and "Data in Flight"
Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 47
3.31. Degradation of cwnd due to Max.Burst . . . . . . . . . . 49
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 50
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 52
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 53
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 55
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 56
3.38. Honoring cwnd . . . . . . . . . . . . . . . . . . . . . . 57
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 58
3.40. Updating References regarding ECN . . . . . . . . . . . . 60
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 62
3.42. Conflicting Text regarding the 'Supported Address Types'
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 66
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 67
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 70
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 72
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 76
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 87
3.48. Handling of SSN Wraparounds . . . . . . . . . . . . . . . 89
3.49. Update to RFC 2119 Boilerplate Text . . . . . . . . . . . 90
3.50. Removal of Text (Previously Missed in RFC 4960) . . . . . 91
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
5. Security Considerations . . . . . . . . . . . . . . . . . . . 92
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1. Normative References . . . . . . . . . . . . . . . . . . 92
6.2. Informative References . . . . . . . . . . . . . . . . . 92
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 46
3.30. "Outstanding Data", "Flightsize", and "Data in Flight"
Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 47
3.31. Degradation of cwnd due to Max.Burst . . . . . . . . . . 49
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 50
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 52
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 53
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 55
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 56
3.38. Honoring cwnd . . . . . . . . . . . . . . . . . . . . . . 57
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 58
3.40. Updating References regarding ECN . . . . . . . . . . . . 60
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 62
3.42. Conflicting Text regarding the 'Supported Address Types'
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 66
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 67
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 70
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 72
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 76
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 87
3.48. Handling of SSN Wraparounds . . . . . . . . . . . . . . . 89
3.49. Update to RFC 2119 Boilerplate Text . . . . . . . . . . . 90
3.50. Removal of Text (Previously Missed in RFC 4960) . . . . . 91
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
5. Security Considerations . . . . . . . . . . . . . . . . . . . 92
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1. Normative References . . . . . . . . . . . . . . . . . . 92
6.2. Informative References . . . . . . . . . . . . . . . . . 92
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
This document contains a compilation of all defects for [RFC4960] ("Stream Control Transmission Protocol") that were found up until the publication of this document. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of the Stream Control Transmission Protocol (SCTP) to clarify errors in the original SCTP document.
本文件包含[RFC4960]（“流控制传输协议”）在本文件出版之前发现的所有缺陷的汇编。这些缺陷可能是编辑性或技术性的。本文件可被视为在流控制传输协议（SCTP）的实施中使用的配套文件，以澄清原始SCTP文件中的错误。
This document provides a history of the changes that will be compiled into a bis document for [RFC4960]. It is structured similarly to [RFC4460].
本文件提供了将被编译为[RFC4960]bis文件的变更历史记录。其结构类似于[RFC4460]。
Each error will be detailed within this document in the form of:
本文件将以以下形式详细说明每个错误：
o The problem description,
o 问题描述，
o The text quoted from [RFC4960],
o 引用自[RFC4960]的文本，
o The replacement text that should be placed into an upcoming bis document, and
o 应放在即将发布的bis文件中的替换文本，以及
o A description of the solution.
o 对解决方案的描述。
Note that when reading this document one must use care to ensure that a field or item is not updated later on within the document. Since this document is a historical record of the sequential changes that have been found necessary at various interop events and through discussion on the Transport Area Working Group mailing list, the last delta in the text is the one that should be applied.
请注意，阅读本文档时，必须小心确保文档中的字段或项目以后不会更新。由于本文件是在各种互操作事件中以及通过对运输区工作组邮件列表的讨论发现必要的顺序更改的历史记录，因此文本中的最后一个增量应适用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The handling of the 'Path.Max.Retrans' parameter is described in Sections 8.2 and 8.3 of [RFC4960] in an inconsistent way. Whereas Section 8.2 of [RFC4960] says that a path is marked inactive when the path error counter exceeds the threshold, Section 8.3 of [RFC4960] says that the path is marked inactive when the path error counter reaches the threshold.
[RFC4960]第8.2节和第8.3节以不一致的方式描述了“Path.Max.Retrans”参数的处理。[RFC4960]的第8.2节指出，当路径错误计数器超过阈值时，路径被标记为不活动，而[RFC4960]的第8.3节指出，当路径错误计数器达到阈值时，路径被标记为不活动。
This issue was reported as an errata for [RFC4960] with Errata ID 1440.
该问题作为[RFC4960]的勘误表报告，勘误表ID为1440。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
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”时，端点应将相应的目标地址标记为非活动（如果未如此标记），并且还可以选择向上层报告此目标地址的可达性更改。在此之后，端点应继续此目标地址上的心跳，但应停止增加计数器。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
When the value of this counter exceeds 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 in 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”时，端点应将相应的目标地址标记为非活动（如果未如此标记），并且还可以选择向上层报告此目标地址的可达性变化。在此之后，端点应继续此目标地址上的心跳，但应停止增加计数器。
This text has been modified by multiple errata. It is further updated in Section 3.23.
此文本已被多个勘误表修改。第3.23节对其进行了进一步更新。
The intended state change should happen when the threshold is exceeded.
当超过阈值时，应发生预期状态更改。
Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN chunks in the SHUTDOWN-RECEIVED state instead of the handling of shutdown requests from its upper layer in this state.
[RFC4960]的第9.2节描述了在SHUTDOWN-received状态下对接收到的SHUTDOWN chunk的处理，而不是在此状态下对来自上层的SHUTDOWN请求的处理。
This issue was reported as an errata for [RFC4960] with Errata ID 1574.
该问题作为[RFC4960]的勘误表报告，勘误表ID为1574。
---------
Old text: (Section 9.2)
---------
---------
Old text: (Section 9.2)
---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
一旦端点达到SHUTDOWN-RECEIVED状态，它就不能发送SHUTDOWN来响应ULP请求，并且应该放弃后续的SHUTDOWN块。
---------
New text: (Section 9.2)
---------
---------
New text: (Section 9.2)
---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST ignore ULP shutdown requests but MUST continue responding to SHUTDOWN chunks from its peer.
一旦端点达到SHUTDOWN-RECEIVED状态，它必须忽略ULP SHUTDOWN请求，但必须继续响应来自其对等方的SHUTDOWN块。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The text never intended that the SCTP endpoint ignore SHUTDOWN chunks from its peer. If it did, the endpoints could never gracefully terminate associations in some cases.
文本从未打算让SCTP端点忽略来自其对等端的关闭块。如果这样做了，端点在某些情况下永远无法正常终止关联。
Section 14.1 of [RFC4960] should deal with new chunk types; however, the text only refers to parameter types.
[RFC4960]第14.1节应处理新的块类型；但是，文本仅指参数类型。
This issue was reported as an errata for [RFC4960] with Errata ID 2592.
该问题作为[RFC4960]的勘误表报告，勘误表ID为2592。
---------
Old text: (Section 14.1)
---------
---------
Old text: (Section 14.1)
---------
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一致行动分配新的区块参数类型代码。区块参数的文档必须包含以下信息：
---------
New text: (Section 14.1)
---------
---------
New text: (Section 14.1)
---------
The assignment of new chunk type codes is done through an IETF Consensus action, as defined in [RFC8126]. Documentation for the chunk type MUST contain the following information:
按照[RFC8126]中的定义，通过IETF一致行动分配新的区块类型代码。区块类型的文档必须包含以下信息：
This text has been modified by multiple errata. It is further updated in Section 3.43.
此文本已被多个勘误表修改。第3.43节对其进行了进一步更新。
The new text refers to chunk types as intended and changes the reference to [RFC8126].
新文本按预期引用块类型，并将引用更改为[RFC8126]。
In Section 3.3.2 of [RFC4960], newlines in wrong places break the layout of the table of variable parameters for the INIT chunk.
在[RFC4960]的第3.3.2节中，错误位置的换行符破坏了INIT块变量参数表的布局。
This issue was reported as an errata for [RFC4960] with Errata ID 3291 and Errata ID 3804.
该问题作为[RFC4960]的勘误表报告，勘误表ID 3291和勘误表ID 3804。
---------
Old text: (Section 3.3.2)
---------
---------
Old text: (Section 3.3.2)
---------
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
---------
New text: (Section 3.3.2)
---------
---------
New text: (Section 3.3.2)
---------
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
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The formatting of the table is corrected.
表的格式已更正。
The sample code for CRC32c computation, as provided in [RFC4960], assumes that a variable of type unsigned long uses 32 bits. This is not true on some 64-bit platforms (for example, platforms that use LP64).
[RFC4960]中提供的CRC32c计算示例代码假定无符号长类型的变量使用32位。某些64位平台（例如，使用LP64的平台）上并非如此。
This issue was reported as an errata for [RFC4960] with Errata ID 3423.
该问题作为[RFC4960]的勘误表报告，勘误表ID为3423。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = 0xffffffffL;
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = 0xffffffffL;
This text has been modified by multiple errata. It is further updated in Section 3.10 and again in Section 3.46.
此文本已被多个勘误表修改。第3.10节和第3.46节对其进行了进一步更新。
The new text uses 0xffffffffL instead of ~0L; this gives the same value on platforms using 32 bits or 64 bits for variables of type unsigned long.
新文本使用0xFFFFFFFFFFFFL而不是~0L；这在使用32位或64位的平台上为unsigned long类型的变量提供相同的值。
The handling of the association error counter defined in Section 8.1 of [RFC4960] can result in an association failure even if the path used for data transmission is available (but idle).
[RFC4960]第8.1节中定义的关联错误计数器的处理可能导致关联失败，即使用于数据传输的路径可用（但空闲）。
This issue was reported as an errata for [RFC4960] with Errata ID 3788.
该问题作为[RFC4960]的勘误表报告，勘误表ID为3788。
---------
Old text: (Section 8.1)
---------
---------
Old text: (Section 8.1)
---------
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks.
端点应保留一个计数器，记录到其对等方的连续重传总数（这包括到对等方的所有目标传输地址的重传，如果它是多宿的），包括未确认的心跳块。
---------
New text: (Section 8.1)
---------
---------
New text: (Section 8.1)
---------
An endpoint SHOULD keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is
端点应保留一个计数器，记录到其对等方的连续重新传输的总数（这包括到对等方的所有目标传输地址的数据重新传输，如果需要的话）
multi-homed), including the number of unacknowledged HEARTBEAT chunks observed on the path that is currently used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer SHOULD NOT increment the association error counter, as this could lead to association closure even if the path that is currently used for data transfer is available (but idle).
multi-homed），包括在当前用于数据传输的路径上观察到的未确认的心跳数据块的数量。在与当前用于数据传输的路径不同的路径上观察到的未确认心跳数据块不应增加关联错误计数器，因为这可能导致关联关闭，即使当前用于数据传输的路径可用（但空闲）。
This text has been modified by multiple errata. It is further updated in Section 3.23.
此文本已被多个勘误表修改。第3.23节对其进行了进一步更新。
A more refined handling of the association error counter is defined.
定义了更精确的关联错误计数器处理。
When integrating the changes to Section 6.1 A) of [RFC2960] as described in Section 2.15.2 of [RFC4460], some text was duplicated and became the final paragraph of Section 6.1 A) of [RFC4960].
如[RFC4460]第2.15.2节所述，当整合[RFC2960]第6.1 A）节的变更时，一些文本被复制并成为[RFC4960]第6.1 A）节的最后一段。
This issue was reported as an errata for [RFC4960] with Errata ID 4071.
该问题作为[RFC4960]的勘误表报告，勘误表ID为4071。
---------
Old text: (Section 6.1 A))
---------
---------
Old text: (Section 6.1 A))
---------
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.4 of [RFC1122].
发送方还必须具有发送新数据块的算法，以避免[RFC0813]中所述的愚蠢窗口综合症（SWS）。该算法可以类似于[RFC1122]第4.2.3.4节中描述的算法。
However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender.
但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
---------
New text: (Section 6.1 A))
---------
---------
New text: (Section 6.1 A))
---------
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC1122]. The algorithm can be similar to the algorithm described in Section 4.2.3.4 of [RFC1122].
发送方还必须具有发送新数据块的算法，以避免[RFC1122]中所述的愚蠢窗口综合症（SWS）。该算法可以类似于[RFC1122]第4.2.3.4节中描述的算法。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The last paragraph of Section 6.1 A) is removed, as had been intended in Section 2.15.2 of [RFC4460].
删除第6.1 A）节的最后一段，如[RFC4460]第2.15.2节所述。
Figure 4 of [RFC4960] illustrates the SCTP association setup. However, it incorrectly shows that the T1-init timer is used in the COOKIE-ECHOED state, whereas the T1-cookie timer should have been used instead.
[RFC4960]的图4说明了SCTP关联设置。但是，它错误地显示T1初始化计时器是在COOKIE-echood状态下使用的，而T1 COOKIE计时器应该被使用。
This issue was reported as an errata for [RFC4960] with Errata ID 4400.
该问题作为[RFC4960]的勘误表报告，勘误表ID为4400。
---------
Old text: (Section 5.1.6, Figure 4)
---------
---------
Old text: (Section 5.1.6, Figure 4)
---------
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)
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)
---------
New text: (Section 5.1.6, Figure 4)
---------
---------
New text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
This text has been modified by multiple errata. It is further updated in Section 3.9.
此文本已被多个勘误表修改。第3.9节对其进行了进一步更新。
The figure is changed such that the T1-cookie timer is used instead of the T1-init timer.
该图更改为使用T1 cookie计时器而不是T1 init计时器。
While processing [RFC4960], some typos were not caught.
在处理[RFC4960]时，未发现某些打字错误。
One typo was reported as an errata for [RFC4960] with Errata ID 5003.
一个打字错误被报告为[RFC4960]的勘误表，勘误表ID为5003。
---------
Old text: (Section 1.6)
---------
---------
Old text: (Section 1.6)
---------
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。
---------
New text: (Section 1.6)
---------
---------
New text: (Section 1.6)
---------
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。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 3.3.10.9)
---------
---------
Old text: (Section 3.3.10.9)
---------
No User Data: This error cause is returned to the originator of a
无用户数据：此错误原因返回给
DATA chunk if a received DATA chunk has no user data.
如果接收到的数据块没有用户数据，则为数据块。
---------
New text: (Section 3.3.10.9)
---------
---------
New text: (Section 3.3.10.9)
---------
No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data.
无用户数据：如果接收到的数据块没有用户数据，则会将此错误原因返回给数据块的发起人。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 6.7, Figure 9)
---------
---------
Old text: (Section 6.7, Figure 9)
---------
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
---------
New text: (Section 6.7, Figure 9)
---------
---------
New text: (Section 6.7, Figure 9)
---------
Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer)
Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/
(remove 6 from out-queue,
and mark 7 as "1" missing report)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/
(remove 6 from out-queue,
and mark 7 as "1" missing report)
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 6.10)
---------
---------
Old text: (Section 6.10)
---------
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram,
端点通过简单地在一个出站SCTP数据包中包含多个块来绑定块。生成的IP数据报的总大小，
including the SCTP packet and IP headers, MUST be less that or equal to the current Path MTU.
包括SCTP数据包和IP报头，必须小于或等于当前路径MTU。
---------
New text: (Section 6.10)
---------
---------
New text: (Section 6.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 than or equal to the current Path MTU (PMTU).
端点通过简单地在一个出站SCTP数据包中包含多个块来绑定块。生成的IP数据报（包括SCTP数据包和IP报头）的总大小必须小于或等于当前路径MTU（PMTU）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 O))
---------
---------
Old text: (Section 10.1 O))
---------
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]）
---------
New text: (Section 10.1 O))
---------
---------
New text: (Section 10.1 O))
---------
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]）
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 M))
---------
---------
Old text: (Section 10.1 M))
---------
M) Set Protocol Parameters
M） 设置协议参数
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list)
格式：SETPROTOCOLPARAMETERS（关联id，[，目标传输地址，]协议参数列表）
---------
New text: (Section 10.1 M))
---------
---------
New text: (Section 10.1 M))
---------
M) Set Protocol Parameters
M） 设置协议参数
Format: SETPROTOCOLPARAMETERS(association id, [destination transport address,] protocol parameter list)
格式：SETPROTOCOLPARAMETERS（关联id，[目标传输地址，]协议参数列表）
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big".
ICMP2）如果类型字段不是“无法到达目的地”、“参数问题”或“数据包太大”，则实现可以忽略所有ICMPv6消息。
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem", or "Packet Too Big".
ICMP2）如果类型字段不是“无法到达目的地”、“参数问题”或“数据包太大”，则实现可以忽略所有ICMPv6消息。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery.
ICMP7）如果ICMP消息是v6“数据包太大”或v4“需要碎片”，则实现可以按照为路径MTU发现定义的方式处理此信息。
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PMTU discovery.
ICMP7）如果ICMP消息是v6“数据包太大”或v4“需要碎片”，则实现可以按照为PMTU发现定义的方式处理此信息。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 5.4)
---------
---------
Old text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent.
2) 对于COOKIE ECHO的接收方，唯一确认的地址是发送INIT-ACK的地址。
---------
New text: (Section 5.4)
---------
---------
New text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the address to which the INIT ACK was sent.
2) 对于COOKIE回显的接收方，唯一确认的地址是发送INIT ACK的地址。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 5.1.6, Figure 4)
---------
---------
Old text: (Section 5.1.6, Figure 4)
---------
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)
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)
---------
New text: (Section 5.1.6, Figure 4)
---------
---------
New text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
This text has been modified by multiple errata. It includes modifications from Section 3.8. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.8节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Section 5.2.5)
---------
---------
Old text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE-ACK.
5.2.5. 处理重复的COOKIE-ACK。
---------
New text: (Section 5.2.5)
---------
---------
New text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE ACK.
5.2.5. 处理重复的COOKIE确认。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
默认情况下，SCTP端点应该通过周期性地向目标传输地址发送心跳数据块来监视其对等方的空闲目标传输地址的可达性。心跳信号发送可在达到既定状态时开始，并在发送SHUTDOWN或SHUTDOWN-ACK后中断。心跳的接收器必须在进入COOKIE-echood状态（初始发送器）或已建立状态（初始接收器）后，使用心跳确认响应心跳，直到达到SHUTDOWN-SENT状态（SHUTDOWN发送器）或SHUTDOWN-ACK-SENT状态（SHUTDOWN接收器）。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
默认情况下，SCTP端点应该通过周期性地向目标传输地址发送心跳数据块来监视其对等方的空闲目标传输地址的可达性。心跳信号发送可在达到既定状态时开始，并在发送关机或关机确认后停止。心跳的接收器必须在进入COOKIE-echood状态（初始发送器）或已建立状态（初始接收器）后，使用心跳确认响应心跳，直到达到SHUTDOWN-SENT状态（SHUTDOWN发送器）或SHUTDOWN-ACK-SENT状态（SHUTDOWN接收器）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Several typos have been fixed.
已经修复了几个拼写错误。
The CRC32c computation is described in Appendix B of [RFC4960]. However, the corresponding sample code and its explanation appear at the end of Appendix C of [RFC4960], which deals with ICMP handling.
[RFC4960]附录B中描述了CRC32c计算。然而，相应的示例代码及其解释出现在[RFC4960]附录C的末尾，该附录涉及ICMP处理。
The text in Appendix C of [RFC4960], starting with the following sentence, needs to be moved to the end of Appendix B.
[RFC4960]附录C中的文本，从以下句子开始，需要移动到附录B的末尾。
The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide.
以下非规范性示例代码取自开源CRC生成器[WILLIAMS93]，使用“镜像”技术，生成一个包含256个条目的SCTP CRC32c查找表，每个条目宽32位。
This text has been modified by multiple errata. It includes modifications from Section 3.5. It is further updated in Section 3.46.
此文本已被多个勘误表修改。它包括第3.5节的修改。第3.46节对其进行了进一步更新。
The text is moved to the appropriate location.
文本将移动到适当的位置。
Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked should be reset to 0 after packet loss detection from selective acknowledgment (SACK), but this information is not accounted for in the case of T3-rtx timer expiration.
[RFC4960]第7.2.3节明确规定，在从选择性确认（SACK）检测到数据包丢失后，应将已确认的部分字节重置为0，但在T3 rtx计时器过期的情况下，不考虑此信息。
---------
Old text: (Section 7.2.3)
---------
---------
Old text: (Section 7.2.3)
---------
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
---------
New text: (Section 7.2.3)
---------
When the T3-rtx timer expires on an address, SCTP SHOULD perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text specifies that partial_bytes_acked should be reset to 0 after T3-rtx timer expiration.
新文本指定在T3 rtx计时器过期后，应将已确认的部分字节重置为0。
Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance phase.
[RFC4960]第7.2.2节可能暗示在拥塞避免阶段对部分字节和cwnd应用错误的调整顺序。
---------
Old text: (Section 7.2.2)
---------
---------
Old text: (Section 7.2.2)
---------
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）。
---------
New text: (Section 7.2.2)
---------
---------
New text: (Section 7.2.2)
---------
o (1) when partial_bytes_acked is equal to or greater than cwnd and (2) before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before the arrival of the SACK,
o （1） 当部分_字节_acked等于或大于cwnd和（2）在SACK到达之前，发送方有cwnd或更多字节的数据未完成（即，在SACK到达之前，
flightsize was greater than or equal to cwnd), partial_bytes_acked is reset to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
flightsize大于或等于cwnd），部分字节已确认重置为（部分字节已确认-cwnd）。接下来，cwnd增加1*MTU。
This text has been modified by multiple errata. It is further updated in Section 3.26.
此文本已被多个勘误表修改。第3.26节对其进行了进一步更新。
The new text defines the exact order of adjustments of partial_bytes_acked and cwnd in the congestion avoidance phase.
新文本定义了拥塞避免阶段部分字节确认和cwnd的精确调整顺序。
Sections 8.1 and 8.3 of [RFC4960] prescribe that the receiver of a HEARTBEAT ACK must reset the association overall error count. In some circumstances, e.g., when a router discards DATA chunks but not HEARTBEAT chunks due to the larger size of the DATA chunk, it might be better to not clear the association error counter on reception of the HEARTBEAT ACK and reset it only on reception of the SACK to avoid stalling the association.
[RFC4960]第8.1节和第8.3节规定，心跳ACK的接收器必须重置关联整体错误计数。在某些情况下，例如，当路由器由于数据块较大而丢弃数据块而不是心跳块时，最好不要在接收到心跳ACK时清除关联错误计数器，并仅在接收到SACK时重置它，以避免关联暂停。
---------
Old text: (Section 8.1)
---------
---------
Old text: (Section 8.1)
---------
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT ACK is received from the peer endpoint.
每次确认发送到该对等端点的数据块（通过接收SACK）或从该对等端点接收到心跳ACK时，都应重置计数器。
---------
New text: (Section 8.1)
---------
---------
New text: (Section 8.1)
---------
The counter MUST be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK). When a HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD also be reset. The receiver of the HEARTBEAT ACK MAY choose not to clear the counter if there is outstanding data on the association. This allows for handling the possible difference in reachability based on DATA chunks and HEARTBEAT chunks.
每次（通过接收SACK）确认发送到对等端点的数据块时，必须重置计数器。当从对等端点接收到心跳ACK时，计数器也应重置。如果关联上存在未完成的数据，心跳ACK的接收器可以选择不清除计数器。这允许处理基于数据块和心跳块的可达性的可能差异。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
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节所定义）。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT MUST 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 SHOULD also clear the association overall error count (as defined in Section 8.1).
在接收到心跳信号确认后，心跳信号的发送方必须清除心跳信号发送到的目标传输地址的错误计数器，并将目标传输地址标记为活动（如果未如此标记）。当由于接收到最新的心跳信号ACK而将非活动目的地地址标记为活动时，端点可以选择性地向上层报告。心跳ACK的接收器还应清除关联总体错误计数（如第8.1节所定义）。
This text has been modified by multiple errata. It is further updated in Section 3.23.
此文本已被多个勘误表修改。第3.23节对其进行了进一步更新。
The new text provides the possibility of not resetting the association overall error count when a HEARTBEAT ACK is received if there are valid reasons for not doing so.
新文本提供了在接收到心跳确认时不重置关联总体错误计数的可能性，前提是存在不重置的有效原因。
[RFC4960] clearly describes where to retransmit data that is timed out when the peer is multi-homed, but the same is not stated for fast retransmissions.
[RFC4960]清楚地描述了当对等方是多宿时，在何处重新传输超时的数据，但对于快速重新传输没有说明。
---------
Old text: (Section 6.4)
---------
---------
Old text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
此外，当其对等方是多宿时，端点应尝试将超时的数据块重新传输到活动目标传输地址，该地址与数据块发送到的最后一个目标地址不同。
---------
New text: (Section 6.4)
---------
---------
New text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
此外，当其对等方是多宿时，端点应尝试将超时的数据块重新传输到活动目标传输地址，该地址与数据块发送到的最后一个目标地址不同。
When its peer is multi-homed, an endpoint SHOULD send fast retransmissions to the same destination transport address to which the original data was sent. If the primary path has been changed and the original data was sent to the old primary path before the Fast Retransmit, the implementation MAY send it to the new primary path.
当其对等方是多宿时，端点应向原始数据发送到的相同目标传输地址发送快速重传。如果主路径已更改，并且在快速重新传输之前原始数据已发送到旧的主路径，则实现可能会将其发送到新的主路径。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text clarifies where to send fast retransmissions.
新文本阐明了在哪里发送快速重传。
The Fast Retransmit on Gap Reports algorithm intends that only the very first packet may be sent regardless of cwnd in the Fast Recovery phase, but rule 3) in Section 7.2.4 of [RFC4960] misses this clarification.
Gap报告上的快速重传算法旨在仅发送第一个数据包，而不考虑快速恢复阶段的cwnd，但[RFC4960]第7.2.4节中的规则3）忽略了这一澄清。
---------
Old text: (Section 7.2.4)
---------
---------
Old text: (Section 7.2.4)
---------
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3) 根据分组被发送到的目的地传输地址的路径MTU的约束，确定标记为重传的最早（即，最低TSN）数据块中有多少将适合于单个分组。调用该值K。在单个数据包中重新传输这些K个数据块。当执行快速重传时，发送方应忽略cwnd的值，并且不应延迟此单个数据包的重传。
---------
New text: (Section 7.2.4)
---------
---------
New text: (Section 7.2.4)
---------
3) If not in Fast Recovery, 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 PMTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3) 如果不是在快速恢复中，则确定标记为重传的最早（即，最低TSN）数据块中有多少块将适合于单个数据包，这取决于数据包被发送到的目的地传输地址的PMTU的约束。调用该值K。在单个数据包中重新传输这些K个数据块。当执行快速重传时，发送方应忽略cwnd的值，并且不应延迟此单个数据包的重传。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text explicitly specifies that only the first packet in the Fast Recovery phase be sent and that the cwnd limitations be disregarded.
新文本明确规定只发送快速恢复阶段的第一个数据包，并且不考虑cwnd限制。
The initial value of ssthresh should be set arbitrarily high. Using the advertised receiver window of the peer is inappropriate if the peer increases its window after the handshake. Furthermore, a higher requirement level needs to be used, since not following the advice may result in performance problems.
ssthresh的初始值应设置为任意高。如果对等方在握手后增加其窗口，则使用对等方的播发接收方窗口是不合适的。此外，需要使用更高的需求级别，因为不遵循建议可能会导致性能问题。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window).
o ssthresh的初始值可以任意高（例如，实现可以使用接收器广告窗口的大小）。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o The initial value of ssthresh SHOULD be arbitrarily high (e.g., the size of the largest possible advertised window).
o ssthresh的初始值应任意高（例如，最大可能广告窗口的大小）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The same value as the value suggested in [RFC5681], Section 3.1, is now used as an appropriate initial value. Also, the same requirement level is used.
与[RFC5681]第3.1节中建议的值相同的值现在用作适当的初始值。此外，使用相同的需求级别。
The Path Verification procedure of [RFC4960] prescribes that any address passed to the sender of the INIT by its upper layer be automatically CONFIRMED. This, however, is unclear if (1) only addresses in the request to initiate association establishment or (2) any addresses provided by the upper layer in any requests (e.g., in 'Set Primary') are considered.
[RFC4960]的路径验证程序规定，由其上层传递给INIT发送方的任何地址都将被自动确认。然而，如果（1）仅考虑发起关联建立的请求中的地址，或者（2）任何请求中上层提供的任何地址（例如，在“设置主”中），则这一点不清楚。
---------
Old text: (Section 5.4)
---------
---------
Old text: (Section 5.4)
---------
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1) 上层传递给INIT发送方的任何地址都会自动被视为已确认。
---------
New text: (Section 5.4)
---------
---------
New text: (Section 5.4)
---------
1) Any addresses passed to the sender of the INIT by its upper layer in the request to initialize an association are automatically considered to be CONFIRMED.
1) 在初始化关联的请求中，上层传递给INIT发送方的任何地址都将自动被视为已确认。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text clarifies that only addresses provided by the upper layer in the request to initialize an association are automatically CONFIRMED.
新文本澄清了只有上层在初始化关联的请求中提供的地址才会被自动确认。
[RFC4960] is not completely clear when it describes data transmission after T3-rtx timer expiration. Section 7.2.1 of [RFC4960] does not specify how many packets are allowed to be sent after T3-rtx timer expiration if more than one packet fits into cwnd. At the same time, Section 7.2.3 of [RFC4960] has text without normative language saying that SCTP should ensure that no more than one packet will be in flight after T3-rtx timer expiration until successful acknowledgement. The text is therefore inconsistent.
[RFC4960]在描述T3 rtx定时器到期后的数据传输时并不完全清楚。[RFC4960]第7.2.1节未规定，如果cwnd中有多个数据包，则T3 rtx定时器到期后允许发送多少数据包。同时，[RFC4960]第7.2.3节的文本中没有规范性语言，即SCTP应确保在T3 rtx定时器到期后，在成功确认之前，不会有超过一个数据包处于飞行状态。因此，案文不一致。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU.
o 重传超时后的初始cwnd不得超过1*MTU。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU, and only one packet is allowed to be in flight until successful acknowledgement.
o 重传超时后的初始cwnd必须不超过1*MTU，并且在成功确认之前，只允许一个数据包处于飞行状态。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text clearly specifies that only one packet is allowed to be sent after T3-rtx timer expiration until successful acknowledgement.
新文本明确规定，在T3 rtx定时器到期后，只有一个数据包被允许发送，直到成功确认为止。
In the case of an INIT received in the COOKIE-WAIT state, [RFC4960] prescribes that an INIT ACK be sent to the same destination address to which the original INIT has been sent. [RFC4960] does not address the possibility of the upper layer providing multiple remote IP addresses while requesting the association establishment. If the upper layer has provided multiple IP addresses and only a subset of these addresses are supported by the peer, then the destination address of the original INIT may be absent in the incoming INIT and sending an INIT ACK to that address is useless.
对于在COOKIE-WAIT状态下接收的INIT，[RFC4960]规定将INIT ACK发送到原始INIT发送到的相同目标地址。[RFC4960]没有解决上层在请求建立关联时提供多个远程IP地址的可能性。如果上层提供了多个IP地址，并且对等方只支持这些地址的一个子集，则原始INIT的目标地址可能在传入INIT中不存在，并且向该地址发送INIT ACK是无用的。
---------
Old text: (Section 5.2.1)
---------
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the endpoint MUST send the INIT ACK back to the same address that the original INIT (sent by this endpoint) was sent.
当接收到处于COOKIE-WAIT状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其Initiate标记，未更改）响应INIT ACK。响应时，端点必须将INIT ACK发送回发送原始INIT（由该端点发送）的相同地址。
---------
New text: (Section 5.2.1)
---------
---------
New text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the following rules MUST be applied:
当接收到处于COOKIE-WAIT状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其Initiate标记，未更改）响应INIT ACK。响应时，必须应用以下规则：
1) The INIT ACK MUST only be sent to an address passed by the upper layer in the request to initialize the association.
1) INIT ACK只能发送到请求中上层传递的地址，以初始化关联。
2) The INIT ACK MUST only be sent to an address reported in the incoming INIT.
2) INIT ACK只能发送到传入INIT中报告的地址。
3) The INIT ACK SHOULD be sent to the source address of the received INIT.
3) INIT ACK应该发送到接收到的INIT的源地址。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text requires sending an INIT ACK to a destination address that is passed by the upper layer and reported in the incoming INIT. If the source address of the INIT meets these conditions, sending the INIT ACK to the source address of the INIT is the preferred behavior.
新文本需要向上层传递并在传入的INIT中报告的目标地址发送INIT ACK。如果INIT的源地址满足这些条件，则将INIT ACK发送到INIT的源地址是首选行为。
Section 6.1 of [RFC4960] states that when sending zero window probes, SCTP should neither increment the association counter nor increment the destination address error counter if it continues to receive new packets from the peer. However, the reception of new packets from the peer does not guarantee the peer's reachability, and if the destination address becomes unreachable during zero window probing, SCTP cannot get an updated rwnd until it switches the destination address for probes.
[RFC4960]第6.1节规定，当发送零窗口探测时，如果SCTP继续从对等方接收新数据包，则SCTP既不应增加关联计数器，也不应增加目标地址错误计数器。然而，从对等方接收新数据包并不保证对等方的可达性，并且如果在零窗口探测期间目标地址变得不可访问，则SCTP无法获得更新的rwnd，直到它为探测切换目标地址。
---------
Old text: (Section 6.1 A))
---------
---------
Old text: (Section 6.1 A))
---------
If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address. This is because the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window.
如果发送方在执行零窗口探测时继续从接收方接收新数据包，则未确认的窗口探测不应增加关联或任何目标传输地址的错误计数器。这是因为接收器可能会无限期地关闭窗口。请参阅第6.2节，了解接收器在播发零窗口时的行为。
---------
New text: (Section 6.1 A))
---------
---------
New text: (Section 6.1 A))
---------
If the sender continues to receive SACKs from the peer while doing zero window probing, the unacknowledged window probes SHOULD NOT increment the error counter for the association or any destination
如果发送方在执行零窗口探测时继续从对等方接收SACK，则未确认的窗口探测不应增加关联或任何目的地的错误计数器
transport address. This is because the receiver could keep its window closed for an indefinite time. Section 6.2 describes the receiver behavior when it advertises a zero window.
传输地址。这是因为接收器可以无限期地关闭窗口。第6.2节描述了接收器在播发零窗口时的行为。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text clarifies that if the receiver continues to send SACKs, the sender of probes should not increment the error counter of the association and the destination address even if the SACKs do not acknowledge the probes.
新文本阐明，如果接收者继续发送SACK，即使SACK未确认探测，探测发送者也不应增加关联的错误计数器和目标地址。
Section 10 of [RFC4960] is informative. Therefore, normative language such as MUST and MAY cannot be used there. However, there are several places in Section 10 of [RFC4960] where MUST and MAY are used.
[RFC4960]的第10节提供了信息。因此，那里不能使用规范性语言，如“必须”和“可能”。然而，在[RFC4960]第10节中有几个地方必须使用和可能使用。
---------
Old text: (Section 10.1 E))
---------
---------
Old text: (Section 10.1 E))
---------
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仍可能捆绑。
---------
New text: (Section 10.1 E))
---------
---------
New text: (Section 10.1 E))
---------
o no-bundle flag - instructs SCTP not to bundle this user data with other outbound DATA chunks. When faced with network congestion, SCTP may still bundle the data, even when this flag is present.
o 无绑定标志-指示SCTP不要将此用户数据与其他出站数据块绑定。当面临网络拥塞时，即使存在此标志，SCTP仍可能捆绑数据。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 G))
---------
---------
Old text: (Section 10.1 G))
---------
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时，表示不会再收到此流序列号的传递。
---------
New text: (Section 10.1 G))
---------
---------
New text: (Section 10.1 G))
---------
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 primitive contains a partial delivery of the whole message. When this flag is set, the stream id and stream sequence number must accompany this primitive. 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时，表示不会再收到此流序列号的传递。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 N))
---------
---------
Old text: (Section 10.1 N))
---------
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时，表示不会再收到此流序列号的传递。
---------
New text: (Section 10.1 N))
---------
---------
New text: (Section 10.1 N))
---------
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 primitive. 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时，表示不会再收到此流序列号的传递。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 O))
---------
---------
Old text: (Section 10.1 O))
---------
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时，表示不会再收到此流序列号的传递。
---------
New text: (Section 10.1 O))
---------
---------
New text: (Section 10.1 O))
---------
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 primitive. 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时，表示不会再收到此流序列号的传递。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The normative language is removed from Section 10. In addition, the consistency of the text has been improved.
规范性语言从第10节中删除。此外，文本的一致性也得到了改善。
Two issues have been discovered in the text in Section 7.2.2 of [RFC4960] regarding partial_bytes_acked handling:
[RFC4960]第7.2.2节中关于部分字节确认处理的文本中发现了两个问题：
o If the Cumulative TSN Ack Point is not advanced but the SACK chunk acknowledges new TSNs in the Gap Ack Blocks, these newly acknowledged TSNs are not considered for partial_bytes_acked even though these TSNs were successfully received by the peer.
o 如果累积TSN Ack点未提前，但SACK区块确认Gap Ack块中的新TSN，则即使对等方成功接收到这些TSN，这些新确认的TSN也不会被视为已确认的部分字节。
o Duplicate TSNs are not considered in partial_bytes_acked even though they confirm that the DATA chunks were successfully received by the peer.
o 即使重复的TSN确认对等方已成功接收到数据块，也不会在部分确认的字节中考虑重复的TSN。
---------
Old text: (Section 7.2.2)
---------
---------
Old text: (Section 7.2.2)
---------
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块确认的块。
---------
New text: (Section 7.2.2)
---------
---------
New text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 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, by Gap Ack Blocks, and by the number of bytes of duplicated chunks reported in Duplicate TSNs.
o 每当cwnd大于ssthresh时，在每次SACK到达时，将partial_bytes_acked增加到该SACK中确认的所有新块的字节总数，包括新累积TSN Ack确认的块、Gap Ack块以及在重复TSN中报告的重复块的字节数。
This text has been modified by multiple errata. It is further updated in Section 3.26.
此文本已被多个勘误表修改。第3.26节对其进行了进一步更新。
In the new text, partial_bytes_acked is increased by TSNs reported as duplicated, as well as TSNs newly acknowledged in Gap Ack Blocks, even if the Cumulative TSN Ack Point is not advanced.
在新文本中，即使累积TSN确认点未提前，部分确认的TSN字节也会增加报告为重复的TSN以及间隙确认块中新确认的TSN。
[RFC4960] uses inconsistent normative and non-normative language when describing rules for sending notifications to the upper layer. For example, Section 8.2 of [RFC4960] says that when a destination address becomes inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP SHOULD send a notification to the upper layer; however, Section 8.3 of [RFC4960] says that when a destination address becomes inactive due to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to the upper layer.
[RFC4960]在描述向上层发送通知的规则时使用了不一致的规范性和非规范性语言。例如，[RFC4960]的第8.2节说，当目标地址由于未确认的数据块或心跳块而变得不活动时，SCTP应向上层发送通知；然而，[RFC4960]的第8.3节指出，当目标地址由于未确认的心跳数据块而变得不活动时，SCTP可以向上层发送通知。
These inconsistent descriptions need to be corrected.
这些不一致的描述需要纠正。
---------
Old text: (Section 8.1)
---------
---------
Old text: (Section 8.1)
---------
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks.
端点应保留一个计数器，记录到其对等方的连续重传总数（这包括到对等方的所有目标传输地址的重传，如果它是多宿的），包括未确认的心跳块。
---------
New text: (Section 8.1)
---------
---------
New text: (Section 8.1)
---------
An endpoint SHOULD keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed), including the number of unacknowledged HEARTBEAT chunks observed on the path that is currently used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer SHOULD NOT increment the association error counter, as this could lead to association closure even if the path that is currently used for data transfer is available (but idle). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint SHOULD consider the peer endpoint unreachable and SHALL stop
端点应保留一个计数器，记录到其对等方的连续重传总数（这包括到对等方的所有目标传输地址的数据重传，如果它是多宿的），包括在当前用于数据传输的路径上观察到的未确认的心跳块数。在与当前用于数据传输的路径不同的路径上观察到的未确认心跳数据块不应增加关联错误计数器，因为这可能导致关联关闭，即使当前用于数据传输的路径可用（但空闲）。如果此计数器的值超过协议参数关联.Max .ReTrin中所指示的限制，则端点应考虑对等端点不可到达，并应停止。
transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint SHOULD 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.
向其传输更多数据（因此关联进入关闭状态）。此外，端点应向上层报告故障，并有选择地报告出站队列中剩余的所有未完成用户数据。当对等端点变得不可访问时，关联将自动关闭。
This text has been modified by multiple errata. It includes modifications from Section 3.6. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.6节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Section 8.2)
---------
---------
Old text: (Section 8.2)
---------
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行为没有任何重大影响。如果不希望出现这种歧义，则如果发送的最后一个数据块是重传，则发送器可以选择不清除错误计数器。
---------
New text: (Section 8.2)
---------
---------
New text: (Section 8.2)
---------
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent) and SHOULD also report to the upper layer when an inactive destination address is marked as active. 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 could be credited to the address of the last chunk sent. However, this ambiguity does not seem to have significant consequences for 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行为产生重大影响。如果不希望出现这种歧义，则如果发送的最后一个数据块是重传，则发送器可以选择不清除错误计数器。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
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”时，端点应将相应的目标地址标记为非活动（如果未如此标记），并且还可以选择向上层报告此目标地址的可达性更改。在此之后，端点应继续此目标地址上的心跳，但应停止增加计数器。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
When the value of this counter exceeds the protocol parameter 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding destination address as inactive if it is not so marked and SHOULD also report to the upper layer the change in 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”时，端点应将相应的目标地址标记为非活动（如果未如此标记），并且还应向上层报告此目标地址的可达性变化。在此之后，端点应继续此目标地址上的心跳，但应停止增加计数器。
This text has been modified by multiple errata. It includes modifications from Section 3.1. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.1节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
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节所定义）。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
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
在收到HEARTBEAT ACK后，HEARTBEAT的发送方应清除HEARTBEAT发送到的目标传输地址的错误计数器，并标记目标传输
address as active if it is not so marked. The endpoint SHOULD 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 SHOULD also clear the association overall error count (as defined in Section 8.1).
如果地址未如此标记，则将其视为活动地址。当由于接收到最新的心跳信号ACK而将非活动目标地址标记为活动时，端点应向上层报告。心跳ACK的接收器还应清除关联总体错误计数（如第8.1节所定义）。
This text has been modified by multiple errata. It includes modifications from Section 3.13. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.13节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Section 9.2)
---------
---------
Old text: (Section 9.2)
---------
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).
端点应将关机区块的重新传输次数限制为协议参数“Association.Max.Retrans”。如果超过此阈值，端点应销毁TCB，并且必须向上层报告无法访问的对等端点（因此关联进入关闭状态）。
---------
New text: (Section 9.2)
---------
---------
New text: (Section 9.2)
---------
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 SHOULD report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
端点应将关机区块的重新传输次数限制为协议参数“Association.Max.Retrans”。如果超过此阈值，端点应销毁TCB，并向上层报告无法访问的对等端点（因此关联进入关闭状态）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 9.2)
---------
---------
Old text: (Section 9.2)
---------
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，并可能向上层报告无法访问的对等端点（因此关联进入关闭状态）。
---------
New text: (Section 9.2)
---------
---------
New text: (Section 9.2)
---------
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 SHOULD report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
关机确认的发送方应将关机确认块的重新传输次数限制为协议参数“Association.Max.Retrans”。如果超过此阈值，端点应销毁TCB，并向上层报告无法访问的对等端点（因此关联进入关闭状态）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The inconsistencies are removed by consistently using SHOULD.
一致使用SHOULD可以消除不一致性。
SCTP as specified in [RFC4960] supports delaying SACKs. The timer value for this is a parameter, and Section 6.2 of [RFC4960] specifies a default and maximum value for it. However, (1) defining a name for this parameter and (2) listing it in the table of protocol parameters in Section 15 of [RFC4960] are missing.
[RFC4960]中规定的SCTP支持延迟SACK。此参数的计时器值是一个参数，[RFC4960]的第6.2节为其指定了默认值和最大值。但是，（1）定义此参数的名称，以及（2）在[RFC4960]第15节的协议参数表中列出此参数的信息缺失。
This issue was reported as an errata for [RFC4960] with Errata ID 4656.
该问题作为[RFC4960]的勘误表报告，勘误表ID为4656。
---------
Old text: (Section 6.2)
---------
---------
Old text: (Section 6.2)
---------
An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms.
实现不得允许将最大延迟配置为超过500 ms。换句话说，实现可将该值降低到500 ms以下，但不得将其提高到500 ms以上。
---------
New text: (Section 6.2)
---------
---------
New text: (Section 6.2)
---------
An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of SACK.Delay below 500 ms but MUST NOT raise it above 500 ms.
实现不得允许将最大延迟（协议参数“SACK.delay”）配置为超过500 ms。换句话说，实现可将SACK.delay的值降低到500 ms以下，但不得将其提高到500 ms以上。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 15)
---------
---------
Old text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
---------
New text: (Section 15)
---------
---------
New text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial: 3 seconds
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
RTO.Initial: 3 seconds
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
This text has been modified by multiple errata. It is further updated in Section 3.32.
此文本已被多个勘误表修改。第3.32节对其进行了进一步更新。
The parameter is given the name 'SACK.Delay' and added to the list of protocol parameters.
该参数的名称为“SACK.Delay”，并添加到协议参数列表中。
There are a few places in [RFC4960] where text specifies that the receiver of a packet must discard it while processing the chunks of the packet. Whether or not the receiver has to roll back state changes already performed while processing the packet is unclear.
在[RFC4960]中有几个地方，文本指定数据包的接收者在处理数据包块时必须丢弃它。接收器是否必须回滚在处理数据包时已经执行的状态更改尚不清楚。
The intention of [RFC4960] is to process an incoming packet chunk by chunk and not to perform any prescreening of chunks in the received packet. Thus, by discarding one chunk, the receiver also causes the discarding of all further chunks.
[RFC4960]的意图是逐块处理传入数据包，而不是对接收数据包中的数据块执行任何预筛选。因此，通过丢弃一个块，接收方还导致丢弃所有其他块。
---------
Old text: (Section 3.2)
---------
---------
Old text: (Section 3.2)
---------
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01-停止处理此SCTP数据包并丢弃它，不处理其中的任何其他数据块，并在“unrecognized chunk Type”中报告未识别的数据块。
---------
New text: (Section 3.2)
---------
---------
New text: (Section 3.2)
---------
00 - Stop processing this SCTP packet; discard the unrecognized chunk and all further chunks.
00-停止处理此SCTP数据包；丢弃无法识别的块和所有其他块。
01 - Stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01-停止处理此SCTP数据包，丢弃未识别的块和所有其他块，并在“未识别的块类型”中报告未识别的块。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 11.3)
---------
---------
Old text: (Section 11.3)
---------
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk.
如果某些防火墙可以只检查片段化SCTP数据包的第一个片段，并明确地确定它是否对应于INIT块（有关更多信息，请参阅[RFC1858]），则这对它们很有帮助。因此，我们强调第3.1节中所述的要求，（1）INIT块不得与数据包中的任何其他块捆绑在一起，（2）包含INIT块的数据包必须具有零验证标记。此外，我们要求INIT块的接收者必须强制执行这些规则，方法是悄悄地丢弃带有与其他块捆绑在一起的INIT块或具有非零验证标记且包含INIT块的到达数据包。
---------
New text: (Section 11.3)
---------
---------
New text: (Section 11.3)
---------
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. The receiver of an INIT chunk MUST silently discard the INIT chunk and all further chunks if the INIT chunk is bundled with other chunks or the packet has a non-zero Verification Tag.
如果某些防火墙可以只检查片段化SCTP数据包的第一个片段，并明确地确定它是否对应于INIT块（有关更多信息，请参阅[RFC1858]），则这对它们很有帮助。因此，我们强调要求，如第3.1节所述，（1）INIT块不得与数据包中的任何其他块捆绑，（2）包含INIT块的数据包必须具有零验证标记。如果INIT块与其他块捆绑在一起，或者数据包具有非零验证标记，则INIT块的接收方必须静默地丢弃INIT块和所有其他块。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text makes it clear that chunks can be processed from the beginning to the end and that no rollback or prescreening is required.
新文本清楚地表明，块可以从头到尾进行处理，不需要回滚或预筛选。
Section 7.2.2 of [RFC4960] prescribes that cwnd be increased by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding to the corresponding address in the congestion avoidance phase. However, this is described without normative language. Moreover, Section 7.2.2 of [RFC4960] includes an algorithm that specifies how an implementation can achieve this, but this algorithm is underspecified and actually allows increasing cwnd by more than 1*MTU per RTT.
[RFC4960]第7.2.2节规定，如果发送方在拥塞避免阶段有cwnd或更多字节的数据未处理到相应地址，则cwnd每RTT增加1*MTU。然而，这是描述没有规范的语言。此外，[RFC4960]第7.2.2节包含了一个算法，该算法指定了实现如何实现这一点，但该算法的规定不充分，实际上允许每RTT将cwnd增加1*MTU以上。
---------
Old text: (Section 7.2.2)
---------
---------
Old text: (Section 7.2.2)
---------
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。
---------
New text: (Section 7.2.2)
---------
---------
New text: (Section 7.2.2)
---------
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. The basic guidelines for incrementing cwnd during congestion avoidance are as follows:
当cwnd大于ssthresh时，如果发送方具有对应传输地址的cwnd或更多字节的未处理数据，则cwnd应每RTT增加1*MTU。在避免拥塞期间增加cwnd的基本准则如下：
o SCTP MAY increment cwnd by 1*MTU.
o SCTP可将cwnd增加1*MTU。
o SCTP SHOULD increment cwnd by 1*MTU once per RTT when the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
o 当发送方有对应传输地址的cwnd或更多字节的未处理数据时，SCTP应在每个RTT中将cwnd增加1*MTU。
o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT.
o SCTP每RTT的cwnd增量不得超过1*MTU。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 7.2.2)
---------
---------
Old text: (Section 7.2.2)
---------
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）。
---------
New text: (Section 7.2.2)
---------
---------
New text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 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, by Gap Ack Blocks, and by the number of bytes of duplicated chunks reported in Duplicate TSNs.
o 每当cwnd大于ssthresh时，在每次SACK到达时，将partial_bytes_acked增加到该SACK中确认的所有新块的字节总数，包括新累积TSN Ack确认的块、Gap Ack块以及在重复TSN中报告的重复块的字节数。
o (1) when partial_bytes_acked is greater than cwnd and (2) before the arrival of the SACK the sender had less than cwnd bytes of data outstanding (i.e., before the arrival of the SACK, flightsize was less than cwnd), reset partial_bytes_acked to cwnd.
o （1） 当确认的部分字节数大于cwnd和（2）在SACK到达之前，发送方未处理的数据少于cwnd字节数（即，在SACK到达之前，flightsize小于cwnd），将确认的部分字节数重置为cwnd。
o (1) when partial_bytes_acked is equal to or greater than cwnd and (2) before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before the arrival of the SACK, flightsize was greater than or equal to cwnd), partial_bytes_acked is reset to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
o （1） 当partial_bytes_acked等于或大于cwnd且（2）在SACK到达之前，发送方有cwnd或更多字节的未处理数据（即，在SACK到达之前，flightsize大于或等于cwnd），partial_bytes_acked将重置为（partial_bytes_acked-cwnd）。接下来，cwnd增加1*MTU。
This text has been modified by multiple errata. It includes modifications from Sections 3.12 and 3.22. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。包括第3.12节和第3.22节的修改。本文件为最终版本，不作进一步更新。
The basic guidelines for incrementing cwnd during the congestion avoidance phase are added into Section 7.2.2. The guidelines include the normative language and are aligned with [RFC5681].
第7.2.2节增加了在拥塞避免阶段增加cwnd的基本指南。指南包括规范性语言，并与[RFC5681]保持一致。
The algorithm from Section 7.2.2 is improved and now does not allow increasing cwnd by more than 1*MTU per RTT.
改进了第7.2.2节中的算法，现在不允许每RTT增加cwnd超过1*MTU。
[RFC4960] prescribes that cwnd per RTO be adjusted if the endpoint does not transmit data on a given transport address. In addition to that, it prescribes that cwnd be set to the initial value after a sufficiently long idle period. The latter is excessive. Moreover, what is considered a sufficiently long idle period is unclear.
[RFC4960]规定，如果端点未在给定传输地址上传输数据，则应调整每个RTO的cwnd。除此之外，它还规定在足够长的空闲时间后，cwnd应设置为初始值。后者是过度的。此外，什么是足够长的闲置期还不清楚。
[RFC4960] doesn't specify the handling of ssthresh in the idle case. If ssthresh is reduced due to packet loss, ssthresh is never recovered. So, traffic can end up in congestion avoidance all the time, resulting in a low sending rate and bad performance. The problem is even more serious for SCTP: in a multi-homed SCTP association, traffic that switches back to the previously failed primary path will also lead to the situation where traffic ends up in congestion avoidance.
[RFC4960]未指定空闲情况下ssthresh的处理。如果ssthresh由于数据包丢失而减少，则ssthresh永远不会恢复。因此，流量可能会一直避免拥塞，导致低发送速率和糟糕的性能。SCTP的问题更为严重：在多宿SCTP关联中，切换回先前失败的主路径的流量也将导致流量最终避免拥塞的情况。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o 数据传输之前或足够长的空闲时间之后的初始cwnd必须设置为最小值（4*MTU，最大值（2*MTU，4380字节））。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o The initial cwnd before data transmission MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o 数据传输前的初始cwnd必须设置为最小值（4*MTU，最大值（2*MTU，4380字节））。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO.
o 当端点不在给定传输地址上传输数据时，传输地址的cwnd应调整为每个RTO的最大值（cwnd/2，4*MTU）。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o While the endpoint does not transmit data on a given transport address, the cwnd of the transport address SHOULD be adjusted to max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, the ssthresh of the transport address SHOULD be set to the cwnd.
o 当端点不在给定的传输地址上传输数据时，传输地址的cwnd应每RTO调整一次至max（cwnd/2，4*MTU）。在第一次cwnd调整之前，传输地址的ssthresh应设置为cwnd。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
A rule about cwnd adjustment after a sufficiently long idle period is removed.
删除了关于在足够长的闲置时间后进行cwnd调整的规则。
The text is updated to describe the handling of ssthresh. When the idle period is detected, the cwnd value is copied to ssthresh.
更新文本以描述ssthresh的处理。当检测到空闲时间段时，cwnd值被复制到ssthresh。
The sending of SACK chunks for window updates is only indirectly referenced in Section 6.2 of [RFC4960], which states that an SCTP receiver must not generate more than one SACK for every incoming packet, other than to update the offered window.
[RFC4960]第6.2节仅间接引用发送SACK块进行窗口更新，该节规定，SCTP接收器不得为每个传入数据包生成多个SACK，除非更新提供的窗口。
However, to avoid performance problems, it is necessary to send the window updates when the receiver window opens up.
但是，为了避免性能问题，有必要在接收器窗口打开时发送窗口更新。
---------
Old text: (Section 6.2)
---------
---------
Old text: (Section 6.2)
---------
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data.
SCTP接收器不得为每个传入数据包生成多个SACK，除非在接收应用程序使用新数据时更新提供的窗口。
---------
New text: (Section 6.2)
---------
---------
New text: (Section 6.2)
---------
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. When the window opens up, an SCTP receiver SHOULD send additional SACK chunks to update the window even if no new data is received. The receiver MUST avoid sending a large number of window updates -- in particular, large bursts of them. One way to achieve this is to send a window update only if the window can be increased by at least a quarter of the receive buffer size of the association.
SCTP接收器不得为每个传入数据包生成多个SACK，除非在接收应用程序使用新数据时更新提供的窗口。当窗口打开时，即使没有收到新数据，SCTP接收器也应该发送额外的SACK块来更新窗口。接收者必须避免发送大量的窗口更新，特别是大量的窗口更新。实现这一点的一种方法是，仅当窗口可以增加关联的接收缓冲区大小的至少四分之一时，才发送窗口更新。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text makes it clear that additional SACK chunks for window updates should be sent as long as excessive bursts are avoided.
新文本明确指出，只要避免过多的突发事件，就应该发送用于窗口更新的额外SACK块。
Section 6.4 of [RFC4960] describes the transmission policy for multi-homed SCTP endpoints. However, this policy has the following issues:
[RFC4960]的第6.4节描述了多宿SCTP端点的传输策略。但是，该政策存在以下问题：
o It states that a SACK should be sent to the source address of an incoming DATA. However, it is known that other SACK policies (e.g., always sending SACKs to the primary path) may be more beneficial in some situations.
o 它声明应该将SACK发送到传入数据的源地址。但是，众所周知，在某些情况下，其他SACK策略（例如，始终将SACK发送到主路径）可能更有利。
o Also, it initially states that an endpoint should always transmit DATA chunks to the primary path but then states that the rule for the transmittal of reply chunks should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. The second statement contradicts the first statement. Some implementations were having problems with it and sent DATA chunks bundled with reply chunks to a different destination address than the primary path, causing many gaps.
o 此外，它最初指出端点应始终将数据块传输到主路径，但随后指出，如果端点将数据块与应答块捆绑在一起，则还应遵循应答块传输规则。第二种说法与第一种说法相矛盾。一些实现遇到了问题，将数据块与应答块捆绑在一起发送到与主路径不同的目标地址，从而造成了许多间隙。
---------
Old text: (Section 6.4)
---------
---------
Old text: (Section 6.4)
---------
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块可以被发送到接收到被确认的数据或控制块的目的地传输地址之一。
---------
New text: (Section 6.4)
---------
---------
New text: (Section 6.4)
---------
An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, HEARTBEAT ACK) in response to control chunks to the same destination transport address from which it received the control chunk to which it is replying.
端点应将应答块（例如，INIT ACK、COOKIE ACK、HEARTBEAT ACK）作为对控制块的响应发送到接收到其应答的控制块的同一目标传输地址。
The selection of the destination transport address for packets containing SACK chunks is implementation dependent. However, an endpoint SHOULD NOT vary the destination transport address of a SACK when it receives DATA chunks coming from the same source address.
为包含SACK块的数据包选择目标传输地址取决于实现。但是，当端点接收来自同一源地址的数据块时，它不应改变SACK的目标传输地址。
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块可被发送到接收到被确认的数据或控制块的目的地传输地址之一。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The SACK transmission policy is left implementation dependent, but the new text now specifies that the policy not vary the destination address of a packet containing a SACK chunk unless there are reasons for not doing so, as varying the destination address may negatively impact RTT measurement.
SACK传输策略依赖于实现，但新文本现在规定，该策略不会改变包含SACK块的数据包的目标地址，除非有理由不这样做，因为改变目标地址可能会对RTT测量产生负面影响。
New text removes a confusing statement that prescribes following the rule for transmittal of reply chunks when the endpoint is bundling DATA chunks together with the reply chunk.
新文本删除了一条令人困惑的语句，该语句规定当端点将数据块与应答块捆绑在一起时，应遵循应答块传输规则。
[RFC4960] uses the key terms "outstanding data", "flightsize", and "data in flight" in formulas and statements, but Section 1.3 ("Key Terms") of [RFC4960] does not provide their definitions. Furthermore, outstanding data does not include DATA chunks that are classified as lost but that have not yet been retransmitted, and there is a paragraph in Section 6.1 of [RFC4960] where this statement is broken.
[RFC4960]在公式和语句中使用了关键术语“未完成数据”、“flightsize”和“飞行中的数据”，但[RFC4960]第1.3节（“关键术语”）未提供其定义。此外，未完成的数据不包括分类为丢失但尚未重新传输的数据块，[RFC4960]第6.1节中有一段对该语句进行了破坏。
---------
Old text: (Section 1.3)
---------
---------
Old text: (Section 1.3)
---------
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 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（以及相关数据块）。
---------
New text: (Section 1.3)
---------
---------
New text: (Section 1.3)
---------
o Congestion window (cwnd): An SCTP variable that limits outstanding data, in number of bytes, that a sender can send to a particular destination transport address before receiving an acknowledgement.
o 拥塞窗口（cwnd）：一个SCTP变量，用于限制发送方在收到确认之前可以发送到特定目标传输地址的未完成数据（字节数）。
...
...
o Flightsize: The amount of bytes of outstanding data to a particular destination transport address at any given time.
o Flightsize：在任何给定时间发送到特定目标传输地址的未完成数据字节数。
...
...
o Outstanding data (or "data outstanding" or "data in flight"): The total amount of the DATA chunks associated with outstanding TSNs. A retransmitted DATA chunk is counted once in outstanding data. A DATA chunk that is classified as lost but that has not yet been retransmitted is not in outstanding data.
o 未完成数据（或“未完成数据”或“飞行中数据”）：与未完成TSN关联的数据块总量。重新传输的数据块在未完成数据中计数一次。分类为丢失但尚未重新传输的数据块不在未完成数据中。
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（以及相关数据块）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd).
C） 当发送方需要传输时，在发送新的数据块之前，发送方必须首先传输标记为要重新传输的任何未完成的数据块（受当前cwnd的限制）。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any DATA chunks that are marked for retransmission (limited by the current cwnd).
C） 当发送方需要传输时，在发送新数据块之前，发送方必须首先传输标记为要重新传输的任何数据块（受当前cwnd限制）。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Section 1.3 is corrected to include explanations of the key terms "outstanding data", "data in flight", and "flightsize". Section 6.1 is corrected to now use "any DATA chunks" instead of "any outstanding DATA chunks".
对第1.3节进行了修改，包括对关键术语“未完成数据”、“飞行中的数据”和“飞行大小”的解释。第6.1节更正为现在使用“任何数据块”而不是“任何未完成的数据块”。
Some implementations were experiencing a degradation of cwnd because of the Max.Burst limit. This was due to misinterpretation of the suggestion in Section 6.1 of [RFC4960] regarding how to use the Max.Burst parameter when calculating the number of packets to transmit.
由于最大突发限制，一些实现正在经历cwnd的降级。这是因为[RFC4960]第6.1节中关于计算要传输的数据包数量时如何使用最大突发参数的建议被误解。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows:
D） 当发送方传输新数据块时，应使用协议参数Max.Burst来限制发送的数据包数量。可通过如下调整cwnd来应用该限值：
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.
或者，它可以通过严格限制输出例程发出的数据包的数量来应用。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd temporarily, as follows:
D） 当发送方传输新数据块时，应使用协议参数Max.Burst来限制发送的数据包数量。可通过临时调整cwnd来应用该限值，如下所示：
if ((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
if ((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
Or, it MAY be applied by strictly limiting the number of packets emitted by the output routine. When calculating the number of packets to transmit, and particularly when using the formula above, cwnd SHOULD NOT be changed permanently.
或者，它可以通过严格限制输出例程发出的包的数量来应用。在计算要传输的数据包数量时，尤其是使用上述公式时，不应永久更改cwnd。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The new text clarifies that cwnd should not be changed when applying the Max.Burst limit. This mitigates packet bursts related to the reception of SACK chunks but not bursts related to an application sending a burst of user messages.
新文本阐明，在应用最大突发限制时，不应更改cwnd。这缓解了与接收SACK块相关的数据包突发，但不会缓解与发送用户消息突发的应用程序相关的数据包突发。
[RFC4960] uses 3 seconds as the default value for RTO.Initial in accordance with Section 4.2.3.1 of [RFC1122]. [RFC6298] updates [RFC1122] and lowers the initial value of the retransmission timer from 3 seconds to 1 second.
[RFC4960]使用3秒作为RTO的默认值。根据[RFC1122]第4.2.3.1节，初始值。[RFC6298]更新[RFC1122]并将重传计时器的初始值从3秒降低到1秒。
---------
Old text: (Section 15)
---------
---------
Old text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
---------
New text: (Section 15)
---------
---------
New text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial: 1 second
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
RTO.Initial: 1 second
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
This text has been modified by multiple errata. It includes modifications from Section 3.24. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。包括第3.24节的修改。本文件为最终版本，不作进一步更新。
The default value for RTO.Initial has been lowered to 1 second to be in tune with [RFC6298].
RTO.Initial的默认值已降低到1秒，以便与[RFC6298]保持一致。
When an SCTP endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge it by sending a SACK chunk and indicate that the stream identifier was invalid by sending an ERROR chunk. These two chunks may be bundled. However, in the case of bundling, [RFC4960] requires that the ERROR chunk follow the SACK chunk. This restriction regarding the ordering of the chunks is not necessary and might limit interoperability.
当SCTP端点接收到具有无效流标识符的数据块时，它应通过发送SACK块来确认该数据块，并通过发送错误块来指示流标识符无效。这两个块可以捆绑在一起。但是，在绑定的情况下，[RFC4960]要求错误块跟随SACK块。这种关于块顺序的限制是不必要的，可能会限制互操作性。
---------
Old text: (Section 6.5)
---------
---------
Old text: (Section 6.5)
---------
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相同的数据包中。
---------
New text: (Section 6.5)
---------
---------
New text: (Section 6.5)
---------
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it SHOULD 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 and the SACK chunk in the same packet.
每个数据块必须携带一个有效的流标识符。如果端点接收到具有无效流标识符的数据块，它应按照正常过程确认数据块的接收，立即发送错误块，并将原因设置为“无效流标识符”（参见第3.3.10节），然后丢弃数据块。端点可以将错误块和SACK块捆绑在同一个数据包中。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The unnecessary restriction regarding the ordering of the SACK and ERROR chunks has been removed.
关于SACK和ERROR块排序的不必要限制已被删除。
[RFC4960] provides a description of an abstract API. In the definition of the RECEIVE primitive, an optional parameter with name "delivery number" is mentioned. However, no definition of this parameter is given in [RFC4960], and the parameter is unnecessary.
[RFC4960]提供了抽象API的描述。在RECEIVE原语的定义中，提到了一个名为“delivery number”的可选参数。但是，[RFC4960]中没有给出该参数的定义，因此不需要该参数。
---------
Old text: (Section 10.1 G))
---------
---------
Old text: (Section 10.1 G))
---------
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]
---------
New text: (Section 10.1 G))
---------
---------
New text: (Section 10.1 G))
---------
G) Receive
G） 接收
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id]
格式：接收（关联id、缓冲区地址、缓冲区大小[，流id]）->字节计数[，传输地址][，流id][，流序列号][，部分标志][，有效负载协议id]
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The undefined parameter has been removed.
未定义的参数已被删除。
The upper layer can change the Differentiated Services Code Point (DSCP) used for packets being sent. Changing the DSCP can result in packets hitting different queues on the path. Therefore, congestion control should be initialized when the DSCP is changed by the upper layer. This is not described in [RFC4960].
上层可以更改用于发送数据包的区分服务代码点（DSCP）。更改DSCP可能导致数据包击中路径上的不同队列。因此，当上层更改DSCP时，应该初始化拥塞控制。[RFC4960]中未对此进行说明。
---------
New text: (Section 7.2.5)
---------
---------
New text: (Section 7.2.5)
---------
7.2.5. Making Changes to Differentiated Services Code Points
7.2.5. 对差异化服务代码点进行更改
SCTP implementations MAY allow an application to configure the Differentiated Services Code Point (DSCP) used for sending packets. If a DSCP change might result in outgoing packets being queued in different queues, the congestion control parameters for all affected destination addresses MUST be reset to their initial values.
SCTP实现可允许应用程序配置用于发送数据包的区分服务代码点（DSCP）。如果DSCP更改可能导致传出数据包在不同队列中排队，则必须将所有受影响目标地址的拥塞控制参数重置为其初始值。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 M))
---------
---------
Old text: (Section 10.1 M))
---------
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans; see Section 15) that the SCTP user wishes to customize.
o 协议参数列表-SCTP用户希望自定义的协议参数的特定名称和值（例如，Association.Max.Retrans；参见第15节）。
---------
New text: (Section 10.1 M))
---------
---------
New text: (Section 10.1 M))
---------
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans (see Section 15), or other parameters like the DSCP) that the SCTP user wishes to customize.
o 协议参数列表-SCTP用户希望自定义的协议参数（如Association.Max.Retrans（见第15节）或其他参数（如DSCP））的特定名称和值。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Text describing the required action for DSCP changes has been added.
已添加描述DSCP更改所需操作的文本。
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 messages. The handling of ICMP messages indicating that the port number is unreachable, as described in the enumerated procedures, is not consistent with the description given in [RFC4960] after the procedures. Furthermore, the text explicitly describes the handling of ICMPv6 packets indicating reachability problems but does not do the same for the corresponding ICMPv4 packets.
[RFC4960]的附录C描述了ICMPv4和ICMPv6消息的处理。如枚举过程中所述，处理表明无法访问端口号的ICMP消息与过程后[RFC4960]中给出的描述不一致。此外，本文明确描述了ICMPv6数据包的处理，指出了可达性问题，但没有对相应的ICMPv4数据包进行相同的处理。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）如果代码未指示“协议不可访问”或“需要分段”，则实现可以忽略任何ICMPv4消息。
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
ICMP3) An implementation SHOULD ignore any ICMP messages where the code indicates "Port Unreachable".
ICMP3）当代码指示“端口不可访问”时，实现应忽略任何ICMP消息。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）如果ICMPv6代码为“目的地不可访问”，则实现可能会将目的地标记为不可访问状态，或者增加路径错误计数器。
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
ICMP9) If the ICMP type is "Destination Unreachable", the implementation MAY move the destination to the unreachable state or, alternatively, increment the path error counter.
ICMP9）如果ICMP类型为“目标不可访问”，则实现可将目标移动到不可访问状态，或者，增加路径错误计数器。
This text has been modified by multiple errata. It is further updated in Section 3.37.
此文本已被多个勘误表修改。第3.37节对其进行了进一步更新。
The text has been changed to describe the intended handling of ICMP messages indicating that the port number is unreachable by replacing the third rule. Also, the limitation to ICMPv6 in the ninth rule has been removed.
文本已更改为描述ICMP消息的预期处理，该消息指示通过替换第三条规则无法访问端口号。此外，第九条规则中对ICMPv6的限制已经取消。
[RFC1122] defines the handling of soft errors and hard errors for TCP. Appendix C of [RFC4960] only deals with hard errors.
[RFC1122]定义TCP软错误和硬错误的处理。[RFC4960]的附录C仅涉及硬错误。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）如果ICMPv6代码为“目的地不可访问”，则实现可能会将目的地标记为不可访问状态，或者增加路径错误计数器。
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
ICMP9) If the ICMP type is "Destination Unreachable", the implementation MAY move the destination to the unreachable state or, alternatively, increment the path error counter. SCTP MAY provide information to the upper layer indicating the reception of ICMP messages when reporting a network status change.
ICMP9）如果ICMP类型为“目标不可访问”，则实现可将目标移动到不可访问状态，或者，增加路径错误计数器。SCTP可向上层提供信息，指示在报告网络状态变化时接收ICMP消息。
This text has been modified by multiple errata. It includes modifications from Section 3.36. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。包括第3.36节的修改。本文件为最终版本，不作进一步更新。
Text has been added allowing SCTP to notify the application in the case of soft errors.
已添加文本，允许SCTP在出现软错误时通知应用程序。
When using the slow start algorithm, SCTP increases the congestion window only when it is being fully utilized. Since SCTP uses DATA chunks and does not use the congestion window to fragment user messages, this requires that some overbooking of the congestion window be allowed.
当使用慢启动算法时，SCTP仅在充分利用时才增加拥塞窗口。由于SCTP使用数据块，而不使用拥塞窗口来分割用户消息，因此需要允许拥塞窗口的一些超额预订。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
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或更多字节的数据未发送到给定的传输地址，则发送方不得将新数据发送到该传输地址。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd + (PMTU - 1) or more bytes of data outstanding to that transport address. If data is available, the sender SHOULD exceed cwnd by up to (PMTU - 1) bytes on a new data transmission if the flightsize does not currently reach cwnd. The breach of cwnd MUST constitute one packet only.
B） 在任何给定的时间，如果发送方有cwnd+（PMTU-1）或更多字节的数据未发送到给定的传输地址，则发送方不得将新数据发送到该传输地址。如果数据可用，如果flightsize当前未达到cwnd，则发送方在新数据传输上应超过cwnd最多（PMTU-1）字节。违反cwnd必须仅构成一个数据包。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
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字节数据。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address. A limited overbooking as described in Section 6.1 B) SHOULD be supported.
o 只要cwnd大于零，就允许端点在该传输地址上有未处理的cwnd字节数据。应支持第6.1 B）节所述的有限超售。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Text was added to clarify how the cwnd limit should be handled.
增加了文本，以澄清应如何处理cwnd限制。
The text in Section 6.1 of [RFC4960] that describes zero window probing does not clearly address the case where the window is not zero but is too small for the next DATA chunk to be transmitted. Even in this case, zero window probing has to be performed to avoid deadlocks.
[RFC4960]第6.1节中描述零窗口探测的文本没有明确说明窗口不是零，但太小，无法传输下一个数据块的情况。即使在这种情况下，也必须执行零窗口探测以避免死锁。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A） 在任何给定时间，如果对等方的rwnd指示该对等方没有缓冲区空间（即rwnd为0；请参阅第6.2.1节），则数据发送方不得向任何目标传输地址传输新数据。但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
当接收器的播发窗口为零时，此探测称为零窗口探测。请注意，只有当所有未完成的数据块都已累计确认且没有数据块在飞行时，才应发送零窗口探测。必须支持零窗口探测。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
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 smaller than the size of the next DATA chunk; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A） 在任何给定时间，如果对等方的rwnd指示该对等方没有缓冲区空间（即rwnd小于下一个数据块的大小；参见第6.2.1节），则数据发送方不得将新数据传输到任何目标传输地址。但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
When the receiver has no buffer space, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
当接收器没有缓冲区空间时，此探测器称为零窗口探测器。请注意，只有当所有未完成的数据块都已累计确认且没有数据块在飞行时，才应发送零窗口探测。必须支持零窗口探测。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The terminology is used in a cleaner way.
该术语的使用更为简洁。
For Explicit Congestion Notification (ECN), [RFC4960] refers only to [RFC3168], which has been updated by [RFC8311]. This needs to be reflected in the text when referring to ECN.
对于显式拥塞通知（ECN），[RFC4960]仅指[RFC3168]，已由[RFC8311]更新。在提及ECN时，这需要反映在文本中。
---------
Old text: (Appendix A)
---------
---------
Old text: (Appendix A)
---------
ECN [RFC3168] describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss.
ECN[RFC3168]描述了一个提议的IP扩展，该扩展详细说明了在数据报丢失之外感知拥塞的方法。
---------
New text: (Appendix A)
---------
---------
New text: (Appendix A)
---------
ECN as specified in [RFC3168] (updated by [RFC8311]) describes an extension to IP that details a method for becoming aware of congestion outside of datagram loss.
[RFC3168]（由[RFC8311]更新）中指定的ECN描述了对IP的扩展，该扩展详细说明了在数据报丢失之外感知拥塞的方法。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix A)
---------
---------
Old text: (Appendix A)
---------
In general, [RFC3168] should be followed with the following exceptions.
一般情况下，应遵循[RFC3168]，但以下例外情况除外。
---------
New text: (Appendix A)
---------
---------
New text: (Appendix A)
---------
In general, [RFC3168] (updated by [RFC8311]) SHOULD be followed, with the following exceptions.
一般情况下，应遵循[RFC3168]（由[RFC8311]更新），但以下例外情况除外。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix A)
---------
---------
Old text: (Appendix A)
---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection.
[RFC3168]详细说明TCP连接的SYN和SYN-ACK阶段期间ECN的协商。
---------
New text: (Appendix A)
---------
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) details the negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection.
[RFC3168]（由[RFC8311]更新）详细说明了TCP连接的SYN和SYN-ACK阶段期间ECN的协商。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix A)
---------
---------
Old text: (Appendix A)
---------
[RFC3168] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network.
[RFC3168]详细说明了接收方在其TCP确认中发送回的特定位，以通知发送方网络中出现的拥塞（CE）位。
---------
New text: (Appendix A)
---------
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit that the CE bit has arrived from the network.
[RFC3168]（由[RFC8311]更新）详细说明了接收方在其TCP确认中发送回的特定位，以通知发送方CE位已从网络到达。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Appendix A)
---------
---------
Old text: (Appendix A)
---------
[RFC3168] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window.
[RFC3168]详细说明发送方在其下一个出站TCP段的报头中发送的特定位，以向其对等方表明其已减少拥塞窗口。
---------
New text: (Appendix A)
---------
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) 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.
[RFC3168]（由[RFC8311]更新）详细说明了发送方要在其下一个出站TCP段的标头中发送的特定位，以向其对等方表明其已减少拥塞窗口。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
References to [RFC8311] have been added. Some wordsmithing was also done while making those updates.
已添加对[RFC8311]的引用。在进行这些更新时，还进行了一些文字编辑。
[RFC4960] defines three types of address parameters to be used with INIT and INIT ACK chunks:
[RFC4960]定义了用于INIT和INIT ACK块的三种类型的地址参数：
1. IPv4 Address parameters.
1. IPv4地址参数。
2. IPv6 Address parameters.
2. IPv6地址参数。
3. Host Name Address parameters.
3. 主机名地址参数。
The first two parameter types are supported by the SCTP kernel implementations of FreeBSD, Linux, and Solaris, but the third is not. In addition, the first two were successfully tested in all nine interoperability tests for SCTP, but the third has never been successfully tested. Therefore, the Host Name Address parameter should be deprecated.
FreeBSD、Linux和Solaris的SCTP内核实现支持前两种参数类型，但第三种不支持。此外，前两个已在SCTP的所有九个互操作性测试中成功测试，但第三个从未成功测试过。因此，不推荐使用主机名地址参数。
---------
Old text: (Section 3.3.2)
---------
---------
Old text: (Section 3.3.2)
---------
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的接收方必须忽略任何其他地址类型。
---------
New text: (Section 3.3.2)
---------
---------
New text: (Section 3.3.2)
---------
Note 3: An INIT chunk MUST NOT contain the Host Name Address parameter. The receiver of an INIT chunk containing a Host Name Address parameter MUST send an ABORT and MAY include an "Unresolvable Address" error cause.
注意3：INIT块不能包含主机名地址参数。包含主机名地址参数的INIT块的接收方必须发送中止，并且可能包含“无法解析的地址”错误原因。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 3.3.2.1)
---------
---------
Old text: (Section 3.3.2.1)
---------
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框工作。
---------
New text: (Section 3.3.2.1)
---------
---------
New text: (Section 3.3.2.1)
---------
The sender of an INIT chunk MUST NOT include this parameter. The usage of the Host Name Address parameter is deprecated.
INIT块的发送方不能包含此参数。不推荐使用主机名地址参数。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 3.3.2.1)
---------
---------
Old text: (Section 3.3.2.1)
---------
Address Type: 16 bits (unsigned integer)
地址类型：16位（无符号整数）
This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
该字段由相应地址TLV的类型值填充（例如，IPv4=5、IPv6=6、主机名=11）。
---------
New text: (Section 3.3.2.1)
---------
---------
New text: (Section 3.3.2.1)
---------
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). The value indicating the Host Name Address parameter (Host name = 11) MUST NOT be used.
该字段由相应地址TLV的类型值填充（例如，IPv4=5，IPv6=6）。不得使用指示主机名地址参数（主机名=11）的值。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 3.3.3)
---------
---------
Old text: (Section 3.3.3)
---------
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的接收方必须忽略任何其他地址类型。
---------
New text: (Section 3.3.3)
---------
---------
New text: (Section 3.3.3)
---------
Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address parameter. The receiver of INIT ACK chunks containing a Host Name Address parameter MUST send an ABORT and MAY include an "Unresolvable Address" error cause.
注意3：INIT ACK块不能包含主机名地址参数。包含主机名地址参数的INIT ACK块的接收器必须发送中止，并且可能包含“无法解决的地址”错误原因。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 5.1.2)
---------
---------
Old text: (Section 5.1.2)
---------
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地址。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
B) If there is a Host Name Address parameter present in the received INIT or INIT ACK chunk, the endpoint MUST immediately send an ABORT and MAY include an "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.
B） 如果在接收到的INIT或INIT ACK块中存在主机名地址参数，则端点必须立即向其对等方发送中止，并可能包括“无法解决的地址”错误原因。中止应发送至接收最后一个对等数据包的源IP地址。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 11.2.4.1)
---------
---------
Old text: (Section 11.2.4.1)
---------
The use of the host name feature in the INIT chunk could be used to flood a target DNS server. A large backlog of DNS queries, resolving the host name received in the INIT chunk to IP addresses, could be accomplished by sending INITs to multiple hosts in a given domain. In addition, an attacker could use the host name feature in an indirect attack on a third party by sending large numbers of INITs to random hosts containing the host name of the target. In addition to the strain on DNS resources, this could also result in large numbers of INIT ACKs being sent to the target. One method to protect against this type of attack is to verify that the IP addresses received from DNS include the source IP address of the original INIT. If the list of IP addresses received from DNS does not include the source IP address of the INIT, the endpoint MAY silently discard the INIT. This last option will not protect against the attack against the DNS.
在INIT区块中使用主机名功能可用于淹没目标DNS服务器。将INIT块中接收的主机名解析为IP地址的大量DNS查询积压可以通过向给定域中的多个主机发送INIT来完成。此外，攻击者可以通过向包含目标主机名的随机主机发送大量init来间接攻击第三方。除了DNS资源紧张外，这还可能导致向目标发送大量初始确认。防止此类攻击的一种方法是验证从DNS接收的IP地址是否包括原始INIT的源IP地址。如果从DNS接收的IP地址列表不包括INIT的源IP地址，则端点可能会自动放弃INIT。最后一个选项将无法防止针对DNS的攻击。
---------
New text: (Section 11.2.4.1)
---------
---------
New text: (Section 11.2.4.1)
---------
Support for the Host Name Address parameter has been removed from the protocol. Endpoints receiving INIT or INIT ACK chunks containing the Host Name Address parameter MUST send an ABORT chunk in response and MAY include an "Unresolvable Address" error cause.
已从协议中删除对主机名地址参数的支持。接收包含主机名地址参数的INIT或INIT ACK块的端点必须发送中止块作为响应，并且可能包含“无法解析的地址”错误原因。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The usage of the Host Name Address parameter has been deprecated.
已不推荐使用主机名地址参数。
3.42. Conflicting Text regarding the 'Supported Address Types' Parameter
3.42. 关于“支持的地址类型”参数的文本冲突
Section 5.1.2 of [RFC4960] contains conflicting text regarding the receipt of an SCTP packet containing an INIT chunk sent from an address for which the corresponding address type is not listed in the 'Supported Address Types' parameter. The text states that the association MUST be aborted, but it also states that the association SHOULD be established and there SHOULD NOT be any error indication.
[RFC4960]第5.1.2节包含关于接收SCTP数据包的冲突文本，该数据包包含从“支持的地址类型”参数中未列出相应地址类型的地址发送的初始化区块。该文本规定必须中止关联，但也规定应建立关联，且不应有任何错误指示。
---------
Old text: (Section 5.1.2)
---------
---------
Old text: (Section 5.1.2)
---------
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiate) MUST either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer.
INIT的发送方可以在INIT中包含“受支持的地址类型”参数，以指示哪些类型的地址是可接受的。当此参数存在时，INIT（initiate）的接收方在响应INIT时必须使用Supported address types参数中指示的地址类型之一，或者如果不愿意或无法使用其对等方指示的任何地址类型，则中止与“Unsolvable address”错误原因的关联。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
The sender of INIT chunks MAY include a 'Supported Address Types' parameter in the INIT to indicate what types of addresses are acceptable.
INIT块的发送方可以在INIT中包含“支持的地址类型”参数，以指示哪些类型的地址是可接受的。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The conflicting text has been removed.
冲突文本已被删除。
[RFC6096] updates [RFC4960] by adding the "Chunk Flags" registry. This should be integrated into the base specification.
[RFC6096]通过添加“区块标志”注册表来更新[RFC4960]。这应纳入基本规范。
---------
Old text: (Section 14.1)
---------
---------
Old text: (Section 14.1)
---------
14.1. IETF-Defined Chunk Extension
14.1. IETF定义的块扩展
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
根据[RFC2434]中的定义，通过IETF一致行动分配新的区块参数类型代码。区块参数的文档必须包含以下信息：
a) A long and short name for the new chunk type.
a) 新块类型的长名称和短名称。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) 区块结构的详细描述，必须符合第3.2节中定义的基本结构。
c) A detailed definition and description of the 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）保留供将来扩展（如有必要）。
---------
New text: (Section 14.1)
---------
---------
New text: (Section 14.1)
---------
14.1. IETF-Defined Chunk Extension
14.1. IETF定义的块扩展
The assignment of new chunk type codes is done through an IETF Review action, as defined in [RFC8126]. Documentation for a new chunk MUST contain the following information:
按照[RFC8126]中的定义，通过IETF审查行动完成新区块类型代码的分配。新区块的文档必须包含以下信息：
a) A long and short name for the new chunk type.
a) 新块类型的长名称和短名称。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) 区块结构的详细描述，必须符合第3.2节中定义的基本结构。
c) A detailed definition and description of the intended use of each field within the chunk, including the chunk flags (if any). Defined chunk flags will be used as initial entries in the chunk flags table for the new chunk type.
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）保留供将来扩展（如有必要）。
For each new chunk type, IANA creates a registration table for the chunk flags of that type. The procedure for registering particular chunk flags is described in Section 14.2.
对于每个新的块类型，IANA都会为该类型的块标志创建一个注册表。第14.2节描述了注册特定区块标志的过程。
This text has been modified by multiple errata. It includes modifications from Section 3.3. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。包括第3.3节的修改。本文件为最终版本，不作进一步更新。
---------
New text: (Section 14.2)
---------
---------
New text: (Section 14.2)
---------
14.2. New IETF Chunk Flags Registration
14.2. 新的IETF区块标志注册
The assignment of new chunk flags is done through an RFC Required action, as defined in [RFC8126]. Documentation for the chunk flags MUST contain the following information:
根据[RFC8126]中的定义，新区块标志的分配通过RFC必需的操作完成。区块标志的文档必须包含以下信息：
a) A name for the new chunk flag.
a) 新块标志的名称。
b) A detailed procedural description of the use of the new chunk flag within the operation of the protocol. It MUST be considered that implementations not supporting the flag will send '0' on transmit and just ignore it on receipt.
b) 协议操作中使用新区块标志的详细过程描述。必须考虑到，不支持该标志的实现将在传输时发送“0”，在接收时忽略它。
IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within the chunk flag values for the specific chunk type.
IANA选择块标志值。这必须是0x01、0x02、0x04、0x08、0x10、0x20、0x40或0x80中的一个，在特定块类型的块标志值内必须是唯一的。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Please note that Sections 14.2, 14.3, 14.4, and 14.5 as shown in [RFC4960] will need to be renumbered when [RFC4960] is updated.
请注意，[RFC4960]中所示的第14.2、14.3、14.4和14.5节需要在更新[RFC4960]时重新编号。
[RFC6096] has been integrated, and the reference has been updated to [RFC8126].
[RFC6096]已集成，参考已更新为[RFC8126]。
[RFC6335] updates [RFC4960] by updating procedures for the "Service Name and Transport Protocol Port Number Registry". This should be integrated into the base specification. Also, the "Guidelines for Writing an IANA Considerations Section in RFCs" reference needs to be changed to [RFC8126].
[RFC6335]通过更新“服务名称和传输协议端口号注册表”的过程来更新[RFC4960]。这应纳入基本规范。此外，“在RFCs中编写IANA注意事项部分的指南”参考需要更改为[RFC8126]。
---------
Old text: (Section 14.5)
---------
---------
Old text: (Section 14.5)
---------
SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC2434].
SCTP服务可以使用联系人端口号向未知呼叫者提供服务，如TCP和UDP。因此，IANA被要求使用以下规则打开SCTP的现有端口号注册表，我们打算将其与现有端口号注册程序很好地结合起来。IESG指定的专家评审员支持IANA根据[RFC2434]中定义的程序评估SCTP端口分配请求。
Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered.
端口号分为三个范围。已知端口是从0到1023的端口，注册端口是从1024到49151的端口，动态和/或专用端口是从49152到65535的端口。已知端口和注册端口旨在供需要系统上的默认联系人的服务器应用程序使用。在大多数系统上，已知端口只能由系统（或根）进程或由特权用户执行的程序使用，而注册端口可以由普通用户进程或由普通用户执行的程序使用。动态和/或专用端口用于临时使用，包括客户端端口、带外协商端口，以及注册专用端口之前的应用程序测试；他们不得注册。
The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use an SCTP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible.
端口号注册表应接受已知端口和已注册端口范围内SCTP端口的注册。未经注册，不得使用知名和注册的端口。尽管在某些情况下（例如将应用程序从TCP移植到SCTP），在注册完成之前使用SCTP端口似乎是很自然的，但我们强调，IANA不会保证特定已知和已注册端口的注册。应尽早申请注册。
Each port registration SHALL include the following information:
每个港口注册应包括以下信息：
o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes).
o 一种短端口名，完全由字母（A-Z和A-Z）、数字（0-9）和“-+./*”（不包括引号）中的标点字符组成。
o The port number that is requested for registration.
o 请求注册的端口号。
o A short English phrase describing the port's purpose.
o 描述港口用途的简短英语短语。
o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended.
o 执行注册的人员或实体的姓名和联系信息，以及对定义端口使用的文档的引用。来自IETF工作组的注册只需命名工作组，但建议指定联系人。
Registrants are encouraged to follow these guidelines when submitting a registration.
鼓励注册人在提交注册时遵循这些指南。
o A port name SHOULD NOT be registered for more than one SCTP port number.
o 不应为多个SCTP端口号注册端口名。
o A port name registered for TCP MAY be registered for SCTP as well. Any such registration SHOULD use the same port number as the existing TCP registration.
o 为TCP注册的端口名也可以为SCTP注册。任何此类注册都应使用与现有TCP注册相同的端口号。
o Concrete intent to use a port SHOULD precede port registration. For example, existing TCP ports SHOULD NOT be registered in advance of any intent to use those ports for SCTP.
o 使用港口的具体意图应先于港口注册。例如，在打算将现有TCP端口用于SCTP之前，不应注册这些端口。
---------
New text: (Section 14.5)
---------
---------
New text: (Section 14.5)
---------
SCTP services can use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing "Service Name and Transport Protocol Port Number Registry" for SCTP using the following rules, which we intend to mesh well with existing port-number registration procedures. An IESG-appointed expert reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC8126]. The details of this process are defined in [RFC6335].
SCTP服务可以使用联系人端口号向未知呼叫者提供服务，如TCP和UDP。因此，IANA被要求使用以下规则为SCTP打开现有的“服务名称和传输协议端口号注册表”，我们打算将这些规则与现有的端口号注册程序很好地结合起来。IESG指定的专家评审员支持IANA根据[RFC8126]中定义的程序评估SCTP端口分配请求。[RFC6335]中定义了该过程的详细信息。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
[RFC6335] has been integrated, and the reference has been updated to [RFC8126].
[RFC6335]已集成，参考已更新为[RFC8126]。
[RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. This should be integrated into the base specification.
[RFC7053]通过向数据块添加I位来更新[RFC4960]。这应纳入基本规范。
---------
Old text: (Section 3.3.1)
---------
---------
Old text: (Section 3.3.1)
---------
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”，并被接收器忽略。
---------
New text: (Section 3.3.1)
---------
---------
New text: (Section 3.3.1)
---------
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 | Res |I|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 | Res |I|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res: 4 bits
Res:4位
SHOULD be set to all '0's and ignored by the receiver.
应设置为所有“0”，并被接收器忽略。
I bit: 1 bit
I位：1位
The (I)mmediate bit MAY be set by the sender whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk being sent back without delay. See Section 4 of [RFC7053] for a discussion of the benefits.
只要数据块的发送方能够从被毫不延迟地发送回的相应SACK块中获益，发送方就可以设置（I）mmediate位。有关好处的讨论，请参见[RFC7053]第4节。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
New text: (Append to Section 6.1)
---------
---------
New text: (Append to Section 6.1)
---------
Whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk being sent back without delay, the sender MAY set the I bit in the DATA chunk header. Please note that why the sender has set the I bit is irrelevant to the receiver.
每当数据块的发送方可以从相应的SACK块被毫不延迟地发送回来中获益时，发送方可以在数据块头中设置I位。请注意，发送方设置I位的原因与接收方无关。
Reasons for setting the I bit include, but are not limited to, the following (see Section 4 of [RFC7053] for a discussion of the benefits):
设置I位的原因包括但不限于以下（有关好处的讨论，请参阅[RFC7053]第4节）：
o The application requests that the I bit of the last DATA chunk of a user message be set when providing the user message to the SCTP implementation (see Section 7).
o 当向SCTP实现提供用户消息时，应用程序请求设置用户消息最后一个数据块的I位（参见第7节）。
o The sender is in the SHUTDOWN-PENDING state.
o 发送方处于关闭挂起状态。
o The sending of a DATA chunk fills the congestion or receiver window.
o 数据块的发送填充拥塞或接收器窗口。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 6.2)
---------
---------
Old text: (Section 6.2)
---------
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块来确认无序接收的数据块。
---------
New text: (Section 6.2)
---------
---------
New text: (Section 6.2)
---------
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块来确认无序接收的数据块。
Upon receipt of an SCTP packet containing a DATA chunk with the I bit set, the receiver SHOULD NOT delay the sending of the corresponding SACK chunk, i.e., the receiver SHOULD immediately respond with the corresponding SACK chunk.
在接收到包含设置了I位的数据块的SCTP数据包时，接收方不应延迟发送相应的SACK数据块，即，接收方应立即响应相应的SACK数据块。
Please note that this change is only about adding a paragraph.
请注意，此更改仅涉及添加段落。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 10.1 E))
---------
---------
Old text: (Section 10.1 E))
---------
E) Send
E） 发送
Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) -> result
格式：发送（关联id、缓冲区地址、字节计数[、上下文][、流id][、生存期][、目标传输地址][、无序标志][、无捆绑标志][、有效负载协议id]）->结果
---------
New text: (Section 10.1 E))
---------
---------
New text: (Section 10.1 E))
---------
E) Send
E） 发送
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id]
[,sack-immediately])
-> result
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id]
[,sack-immediately])
-> result
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
New text: (Append optional parameter in item E) of Section 10.1)
---------
---------
New text: (Append optional parameter in item E) of Section 10.1)
---------
o sack-immediately flag - set the I bit on the last DATA chunk used for the user message to be transmitted.
o sack立即标记-在用于传输用户消息的最后一个数据块上设置I位。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
[RFC7053] has been integrated.
[RFC7053]已集成。
The code given for the CRC32c computations uses types such as "long", which may have different lengths on different operating systems or processors. Therefore, the code needs to be changed, so that it uses specific types such as uint32_t.
为CRC32c计算提供的代码使用诸如“long”之类的类型，这些类型在不同的操作系统或处理器上可能具有不同的长度。因此，需要更改代码，以便使用特定类型，如uint32\t。
Some syntax errors and a comment also need to be fixed.
一些语法错误和注释也需要修复。
We remind the reader that per Section 3.10.2 of this document most of Appendix C of RFC 4960 will be moved to Appendix B in the bis document (thus the "Old text: (Appendix C)" and "New text: (Appendix B)" items in this section).
我们提醒读者，根据本文件第3.10.2节，RFC 4960的大部分附录C将移至bis文件中的附录B（因此，本节中的“旧文本：（附录C）”和“新文本：（附录B）”项）。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
无符号长crc_c[256]=[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 7 7 7 A79A7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1111111111111111111福福1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1，0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 10 10 10 10 10 10 7 7 7 7 7 7 7 7 7 7 7 7 7 7，0 0 0 0 0 0 5 5 5 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 7BBCEF57L、0x89D76C54L、0x5D1D08BFL、0xAF768BCL、0xBC267848L、0x4E4DFB4BL、0x20BD8EDEL、0xD2D60DDDL、0xC186FE29L、0x33ED7D2AL、0xE72719C1L、0x154C9AC2L、0x061C6936L、0xF477EA35L、0xAA64D611L、0x580F5512L、0x4B5FA6L、0xB93425E5L、0x6DFE410EL、0x6DFE49F95C20DL、0x8CC539L、0xC27EA892L、0xB1236L、，
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
10月17日，0月4851927DL，10月15日10月18日18号。10月18日18岁，0月4851927DL，10月15日18月18日18号。10月15日16号18号18号，10月18号10号10号10号10号10号10号10号10号10号10号10号10号10号10号10号19号19号19号19号19号19号19号19号19号19号19号18号18号19，10号18号18号18号18号18号18号18号18号18号18号18号18号19，10，10号18号18号18号18号18号18号18号18号18号18号10，10，10号18号18号18号18号18号18号18号10，10，10号19号19号19号10，10号10，10号10号10号10号10号10，10号10号10号10号10，10号10，10号A29BL，0x1F682198L、0x5125DAD3L、0xA34E59D0L、0xB01EAA24L、0x42752927L、0x96BF4DCCL、0x64D4CECFL、0x77843D3BL、0x85EFBE38L、0xDBFC821CL、0x2997011FL、0x3AC7F2EBL、0xC8AC71E8L、0x1C661503L、0xEE0D9600L、0xFD5D65F4L、0x0F36F7L，
0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0x61C66 936262L，0x9393AD1061L，0x80FDE3951，0x72966096L，0xA656077DL，0x54377 7 EL，0x476767747 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 77DL，0x547 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 EL EL，层EL，0x477 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7EL，0x7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 7A7C35L，0x2F8B6829L，0x82FB41414141BBBBBBBBBBBBBBBBBBBB78L，0x709DB87BL，0x63CD40CD87BL，0x63CD40CDCDBBBB8FL，0x6666CDB666666666666666666F6666B666 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6个BDDL，0x666DB6DB6BDD6BDDL，0xCEB6666BD10 10 10 10-BDL，0xCEB0CEB18个DE10 10 10个DE10 10 10 10个DE10 10个DE10 10个DE10个DE10 10 10个DE10个DE10个DE10 10个DE10个DEL，0x222222222222222222B22222222222222222326B08L，0xA759E80BL、0xB4091BFFL、0x466298FCL、0x1871A4D8L、0xEA1A27DBL、0xF94AD42FL、0x0B21572CL、0xDFEB33C7L、0x2D80B0C4L、0x3ED04330L、0xCCBBC033L、0xA24B5A6L、0x502036A5L、0x4370C551L、0xB11B4652L、0x65D122B9L、0x97BAA11BAAL、0x84EA524EL、0x7681D14DL、0x2892ED69L、0x9ED96E6AL、0xB9AE7D9L、0xB9E37D9L、，2008年10月18 18 18个L，0xA145813DL，0x758个D6666L，0x758个D6个D6L，0x87E4666D5L，0x87E666666D5L，0x94B494949B4949498个L，0x585858585858585858585858585858585858585858588989898989828282L，0xFCFC58585858585858898989898989898989898 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 L，0x668 8 8-8 8 8 8 8 8 8 8 8 8 8 8-5858588 8 8 10 10 10 10啊,，0x7CA56A17L，0x6FF599E3L，0x66FF599E3L，0x9D9D9 10 10 10 10 10 10 10 10 10 10 10 10 10 10 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 ABABBBBB414141甲甲甲甲甲甲甲甲甲甲，19，10 10 10岁，19岁，19 19 ABBBBB64646464648 8 8 8岁，20甲甲甲甲甲甲甲甲甲甲甲甲甲，19 19那个那个那个那个些，19那个么，19 19 19 19岁，19 19 19 19 19甲甲甲甲甲甲，19那个那个那个那个么，19 BD8EDL，0xF0605BEEL、0x24AA3F05L、0xD6C1BC06L、0xC5914FF2L、0x37FACCF1L、0x69E9F0D5L、0x9B8273D6L、0x88D28022L、0x7AB90321L、0xAE7367CAL、0x5C18E4C9L、0x4F48173DL、0xBD23943EL、0xF36E6F75L、0x0105EC76L、0x12551F82L、0xE03E9C81L、，
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, };
0x34F4F86AL、0xC69F7B69L、0xD5CF889DL、0x27A40B9EL、0x79B737BAL、0x8BDCB4B9L、0x988C474DL、0x6AE7C44EL、0xBE2DA0A5L、0x4C4623A6L、0x5F16D052L、0xAD7D5351L、}；
#endif
#恩迪夫
---------
New text: (Appendix B)
---------
---------
New text: (Appendix B)
---------
<CODE BEGINS>
/****************************************************************/
/* Note: The definitions for Ross Williams's table generator */
/* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */
/* For Mr. Williams's direct calculation code, use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */
/****************************************************************/
<CODE BEGINS>
/****************************************************************/
/* Note: The definitions for Ross Williams's table generator */
/* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */
/* For Mr. Williams's direct calculation code, use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */
/****************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_h__
#define __crc32cr_h__
/* Example of the crc table file */
#ifndef __crc32cr_h__
#define __crc32cr_h__
#define CRC32C_POLY 0x1EDC6F41UL
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
#define CRC32C_POLY 0x1EDC6F41UL
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
uint32_t crc_c[256] = { 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL,
uint32\u t crc\u c[256]={0x00000000UL，0xF26B8303UL，0xE13B70F7UL，0x1350F3F4UL，0xC79A971FUL，0x35F1141CUL，0x26A1E7E8UL，0xD4CA64EBUL，0x8AD958CFUL，0x78B2DBCCUL，0x6BE2838UL，0x9989AB3BUL，0x4D43CFD0UL，0xBF284CD3UL，0xAC78BF27UL，0x5E133C24UL，0x105EC76FUL，0xE235446CUL，0x16B798UL，0x65B798UL，0x303049BUL，0xC450CFU，0x877CFU，0xA39CFU，0xA3808CFU五十、 0x68EC1CA3UL、0x7BBCEF57UL、0x89D76C54UL、0x5D1D08FULL、0xAF768BBCUL、0xBC267848UL、0x4E4DFB4BUL、0x20BD8EDEUL、0xD2D60DDDUL、0xC186FE29UL、0x33ED7D2AUL、0xE72719C1UL、0x154C9AC2UL、0x061C6936UL、0xF477EA35UL、0xAA64D611UL、0x580F5512UL、0x4B5FA6DFE6UL、0x93425E5EUL、0xE415E5EUL、0xE410EUL、0xE7272719C22FUL、0xE498EB2FUL、0xB19CF2FULUL，0xD1D83946UL，0x23B3BA45UL，0xF779DEAEUL，0x05125DADUL，0x1642AE59UL，0xE42922D5AUL，0xBA3A17EUL，0x4851927DUL，0x5B06189UL，0xA96AE28AUL，0x7DA08661UL，0x8FCB0562UL，0x9C9BF696UL，0x6EF07595UL，0x417B11BCUL，0xB3109EBFUL，0xBA406D4BUL，0x522BEE48UL，0x86E18AA8AA3AUL，0x748A09AUL，0xB1798UL，0x569AB798UL，0x679AB798UL，0x679AB798UL，0x638CF7CF8UL，0x679UL，0x568CF798CF358UL，0x678CF8CF8CF8CF8CF8CF8CF8CF84UL、0xD8F2B687UL、0x0C38D26CUL、0xFE53516FUL、0xED03A29BUL、0x1F682198UL、0x5125DAD3UL、0xA34E59D0UL、0xB01EAA24UL、0x42752927UL、0x96BF4CCUL、0x64D4CECUL、0x77843DBUL、0x85EFBE38UL、0xDBFC821CUL、0x2997011FUL、0x3AC7F2EBUL、0xC8AC71E8UL、0x1C161503UL、0xEE0D60UL、0xF455D65CF6UL、0x967F466UL、0x966F467CF6UL96UL，0xA65C047DUL，0x5437877EUL，0x4767748AUL，0xB50CF789UL，
0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, };
0xEB1FCADUL、0x197448AEUL、0x0A24BB5AUL、0xF84F3859UL、0x2C855CB2UL、0xDEEDFB1UL、0xCDBE2C45UL、0x3FD5AF46UL、0x7198540DUL、0x83F3D70EUL、0x90A324FAUL、0x62C8A7F9UL、0xB602C312UL、0x44694011UL、0x5739B3E5E5UL、0xFB410CC2UL、0x092A28FC1UL、0x1A7C35UL、0xE816F38BUL、0x382BUL、0x2BUL、0x2BU2BUL、0x568B8B8B8B8B9UL、0x568B8B8B8BUL、，比如说，0xB7072F64UL，0xA457-64F64ul，0xB707072F64ul，0xA457-D60606-6 6-6-6-7DC90UL，0x563C5F933-335F93UL，0x082F607B777B7B77B7B7B7B7B7B7B7B7B8，0xCD6-6-7-7-6-6-6-6-6-6-6-6-6-6-6-6-6-6-8，0xA7DC907DC907DC907DC90ul，0xA457DC907DC908-8-8-8-8-8-8-6-6-6-8-8-6-8-6-6-6-6-8-8-6-6-8-8-6-8-6-6-6-8-8-8-8-8-8-8-8-8，0xF94AD42FUL、0x0B21572CUL、0xDFEB33C7UL、0x2D80B0C4UL、0x3ED04330UL、0xCCBBC033UL、0xA24B5A6UL、0x502036A5UL、0x4370C551UL、0xB11B4652UL、0x65D122B9UL、0x97BAA1BAA1BAUL、0x84EA524EUL、0x7681D14DUL、0x2892ED69UL、0xDAF96E6AUL、0xC9A99D9EUL、0x3BC29DUL、0xEF087A7UL、0x63F975B5U5EUL、0x08882EUL、0xFC0888882EUL、0x0282EUL、，0xA145813DUL、0x758FE5D6UL、0x87E466D5UL、0x94B4952UL、0x66DF1622UL、0x38CC2A06UL、0xCAA7A905UL、0xD9F75AF1UL、0x2B9CD9F2UL、0xFF56BD19UL、0x0D3D3E1AUL、0x1E6DCDEEUL、0xEC064EEDUL、0xC38D26C4UL、0x31E6A5C7UL、0x22B65633UL、0xD0D0D530UL、0x0417B12CUL、0xF678C38UL、0xE547CF8UL、0xC47CF8D08CF8CF8F、0x048CF8F、0x048CF8CF8F、0x8CF8F、0x8F、0x8F、0x8F、0xD8F、0xD8F、0xD8F、0xD8F、0xD8F、0xD8F、0xD，8月8日，8月8日，8月8日，8月8日，8月8日，8月8日，8月8日。8月8日，8月8日，8月8日8 8 8 8 8 8日，8月8日8 8 8 8 8日，8月8日8 8 8 8 8 8日，8月8日8日接受8 8 8 8 8日，8月8日8日接受8 8 8 8日，8月8月8日，8月8日8日8日8 8 8 8日，8月8日8日8日8日8 8 8 8 8 8 8 8 8日8 8 8 8 8点，8收8点，8点，8点8点，8点8点8点8点8点8点，8点8点8点8点，8点8点8点8点，8点8点8点8点，8点8点8点8点8点8点8点8点8点8点8点12点，8点8点8点8点，0x6家B82736家实验室，0x88D28022家UL，0x7家AB8080808022家UL，0x7家AB9032家UL，0x7个AB9032家UL，0xAA7367考考考尔，0x5家学院，0x6家学院，0x5家学院，0x5家学院，0x5家学院，0x6个6个C16个C16个C16个C16个C16个学生，0x6个D6个C16个学生，0x8个808个808个808个808个806个808个学生，0x6个C16个C16个C16个C16个C16个C16个C16个C16个C16个C16个C16个C16个学生，0x6个C16个C16个C16个学生，0x6个学生，0x6个学生，0x6个C16个C16个C16个C16个学生，0x6个808个808个学生，0x6个808个80808 A6ul，0x5F16D052UL，0xAD7D5351UL，}；
#endif
#恩迪夫
This text has been modified by multiple errata. It includes modifications from Section 3.10. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.10节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
/* Example of table build routine */
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
rb=反映32（指数）；
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
主要（）
{
int i;
{
int i;
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
---------
New text: (Appendix B)
---------
---------
New text: (Appendix B)
---------
/* Example of table build routine */
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h" #define CRC32C_POLY 0x1EDC6F41UL
#定义输出文件“crc32cr.h”#定义CRC32C_POLY 0x1EDC6F41UL
static FILE *tf;
静态文件*tf；
static uint32_t
reflect_32(uint32_t b)
{
int i;
uint32_t rw = 0UL;
static uint32_t
reflect_32(uint32_t b)
{
int i;
uint32_t rw = 0UL;
for (i = 0; i < 32; i++) {
for (i = 0; i < 32; i++) {
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
static uint32_t
build_crc_table (int index)
{
int i;
uint32_t rb;
static uint32_t
build_crc_table (int index)
{
int i;
uint32_t rb;
rb = reflect_32(index);
rb = reflect_32(index);
for (i = 0; i < 8; i++) {
if (rb & 0x80000000UL)
rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32(rb));
}
for (i = 0; i < 8; i++) {
if (rb & 0x80000000UL)
rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32(rb));
}
int
main (void)
{
int i;
int
main (void)
{
int i;
printf("\nGenerating CRC32c table file <%s>.\n",
OUTPUT_FILE);
if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) {
printf("Unable to open %s.\n", OUTPUT_FILE);
exit (1);
}
fprintf(tf, "#ifndef __crc32cr_h__\n");
fprintf(tf, "#define __crc32cr_h__\n\n");
fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
(uint32_t)CRC32C_POLY);
fprintf(tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
for (i = 0; i < 256; i++) {
fprintf(tf, "0x%08XUL,", build_crc_table (i));
if ((i & 3) == 3)
printf("\nGenerating CRC32c table file <%s>.\n",
OUTPUT_FILE);
if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) {
printf("Unable to open %s.\n", OUTPUT_FILE);
exit (1);
}
fprintf(tf, "#ifndef __crc32cr_h__\n");
fprintf(tf, "#define __crc32cr_h__\n\n");
fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
(uint32_t)CRC32C_POLY);
fprintf(tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
for (i = 0; i < 256; i++) {
fprintf(tf, "0x%08XUL,", build_crc_table (i));
if ((i & 3) == 3)
fprintf(tf, "\n");
else
fprintf(tf, " ");
}
fprintf(tf, "};\n\n#endif\n");
fprintf(tf, "\n");
else
fprintf(tf, " ");
}
fprintf(tf, "};\n\n#endif\n");
if (fclose(tf) != 0)
printf("Unable to close <%s>.\n", OUTPUT_FILE);
else
printf("\nThe CRC32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
if (fclose(tf) != 0)
printf("Unable to close <%s>.\n", OUTPUT_FILE);
else
printf("\nThe CRC32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
This text has been modified by multiple errata. It includes modifications from Section 3.10. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。它包括第3.10节的修改。本文件为最终版本，不作进一步更新。
---------
Old text: (Appendix C)
---------
---------
Old text: (Appendix C)
---------
/* Example of crc insertion */
/* Example of crc insertion */
#include "crc32cr.h"
#包括“crc32cr.h”
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit * byteswap. On a little-endian machine, this byteswap and * the final ntohl cancel out and could be elided. */
* 但字节已被字节交换。所以我们现在做一个显式的*byteswap。在一台小小的endian机器上，这个byteswap和*最后的ntohl相互抵消，可以省略*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
---------
New text: (Appendix B)
---------
---------
New text: (Appendix B)
---------
/* Example of crc insertion */
/* Example of crc insertion */
#include "crc32cr.h"
#包括“crc32cr.h”
uint32_t
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
uint32_t crc32 = 0xffffffffUL;
uint32_t result;
uint8_t byte0, byte1, byte2, byte3;
uint32_t
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
uint32_t crc32 = 0xffffffffUL;
uint32_t result;
uint8_t byte0, byte1, byte2, byte3;
for (i = 0; i < length; i++) {
CRC32C(crc32, buffer[i]);
}
for (i = 0; i < length; i++) {
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
result = ~crc32;
/* result now holds the negated polynomial remainder,
* since the table and algorithm are "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, and then did an
* end-for-end bit-reversal.
* Note that a 32-bit bit-reversal is identical to four in-place
* 8-bit bit-reversals followed by an end-for-end byteswap.
* In other words, the bits of each byte are in the right order,
* but the bytes have been byteswapped. So, we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
/* result now holds the negated polynomial remainder,
* since the table and algorithm are "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, and then did an
* end-for-end bit-reversal.
* Note that a 32-bit bit-reversal is identical to four in-place
* 8-bit bit-reversals followed by an end-for-end byteswap.
* In other words, the bits of each byte are in the right order,
* but the bytes have been byteswapped. So, we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return (crc32);
}
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return (crc32);
}
int
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
uint32_t crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0UL;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
uint32_t crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0UL;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
uint32_t original_crc32;
uint32_t crc32;
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
uint32_t original_crc32;
uint32_t crc32;
/* save and zero checksum */
message = (SCTP_message *)buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer, length);
return ((original_crc32 == crc32)? 1 : -1);
}
<CODE ENDS>
/* save and zero checksum */
message = (SCTP_message *)buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer, length);
return ((original_crc32 == crc32)? 1 : -1);
}
<CODE ENDS>
This text has been modified by multiple errata. It includes modifications from Sections 3.5 and 3.10. It is in final form and is not further updated in this document.
此文本已被多个勘误表修改。包括第3.5节和第3.10节的修改。本文件为最终版本，不作进一步更新。
The code was changed to use platform-independent types.
代码已更改为使用与平台无关的类型。
The Gap Ack Blocks in the SACK chunk are intended to be isolated. However, this is not mentioned with normative text.
SACK块中的Gap Ack块旨在隔离。然而，规范性文本并未提及这一点。
This issue was reported as part of an errata for [RFC4960] with Errata ID 5202.
该问题作为[RFC4960]勘误表的一部分报告，勘误表ID为5202。
---------
Old text: (Section 3.3.4)
---------
---------
Old text: (Section 3.3.4)
---------
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的值。
---------
New text: (Section 3.3.4)
---------
---------
New text: (Section 3.3.4)
---------
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. The Gap Ack Blocks SHOULD be isolated. This means that the TSN just before each Gap Ack Block and the TSN just after each Gap Ack Block have not been received. 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的子序列。应隔离间隙确认块。这意味着没有接收到每个间隙Ack块之前的TSN和每个间隙Ack块之后的TSN。根据定义，Gap Ack块确认的所有TSN都大于累积TSN Ack的值。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
---------
Old text: (Section 3.3.4)
---------
---------
Old text: (Section 3.3.4)
---------
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块结束）的所有数据块已正确接收。
---------
New text: (Section 3.3.4)
---------
---------
New text: (Section 3.3.4)
---------
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. Gap Ack Blocks SHOULD be isolated. This means that the DATA chunks with TSNs equal to (Cumulative TSN Ack + Gap Ack Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) have not been received.
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. Gap Ack Blocks SHOULD be isolated. This means that the DATA chunks with TSNs equal to (Cumulative TSN Ack + Gap Ack Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) have not been received.translate error, please retry
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
Normative text describing the intended usage of Gap Ack Blocks has been added.
增加了描述间隙确认块预期用途的规范性文本。
The Stream Sequence Number (SSN) is used for preserving the ordering of user messages within each SCTP stream. The SSN is limited to 16 bits. Therefore, multiple wraparounds of the SSN might happen within the current send window. To allow the receiver to deliver ordered user messages in the correct sequence, the sender should limit the number of user messages per stream.
流序列号（SSN）用于保存每个SCTP流中用户消息的顺序。SSN限制为16位。因此，SSN的多个包装可能会在当前发送窗口内发生。为了允许接收者以正确的顺序传递有序的用户消息，发送者应该限制每个流的用户消息数量。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
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。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
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. Note: For each stream, the data sender SHOULD NOT have more than 2**16 - 1 ordered user messages in the current send window.
注意：数据发送方不应使用比当前发送窗口的起始TSN高出2**31-1的TSN。注意：对于每个流，数据发送方在当前发送窗口中的有序用户消息不应超过2**16-1。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The data sender is required to limit the number of ordered user messages within the current send window.
要求数据发送方限制当前发送窗口内已订购用户邮件的数量。
The text to be used to refer to the terms ("key words") defined in [RFC2119] has been updated by [RFC8174]. This needs to be integrated into the base specification.
[RFC2119]中定义的用于引用术语（“关键词”）的文本已由[RFC8174]更新。这需要集成到基本规范中。
---------
Old text: (Section 2)
---------
---------
Old text: (Section 2)
---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
---------
New text: (Section 2)
---------
---------
New text: (Section 2)
---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The text has been updated to the text specified in [RFC8174].
文本已更新为[RFC8174]中指定的文本。
When integrating the changes to Section 7.2.4 of [RFC2960] as described in Section 2.8.2 of [RFC4460], some text was not removed and is therefore still in [RFC4960].
如[RFC4460]第2.8.2节所述，整合[RFC2960]第7.2.4节的变更时，一些文本未删除，因此仍在[RFC4960]中。
---------
Old text: (Section 7.2.4)
---------
---------
Old text: (Section 7.2.4)
---------
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 3 and starting the Fast-Retransmit procedure, the counter resets to 0. 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.
上述的简单实现为SACK报告的每个TSN孔保留一个计数器。对于报告TSN孔的每个连续袋，计数器递增。达到3并开始快速重传过程后，计数器重置为0。由于SCTP中的cwnd间接限制了未完成TSN的数量，因此TCP快速恢复的效果是自动实现的，而无需调整拥塞控制窗口的大小。
---------
New text: (Section 7.2.4)
---------
---------
New text: (Section 7.2.4)
---------
This text is in final form and is not further updated in this document.
本文本为最终形式，本文件不作进一步更新。
The text has finally been removed.
文本终于被删除了。
Section 3.44 of this document suggests new text that would update the "Service Name and Transport Protocol Port Number Registry" for SCTP to be consistent with [RFC6335].
本文件第3.44节建议更新SCTP的“服务名称和传输协议端口号注册表”，使其与[RFC6335]一致。
IANA has confirmed that it is OK to make the proposed text change in an upcoming Standards Track document that will update [RFC4960]. IANA is not asked to perform any other action, and this document does not request that IANA make a change to any registry.
IANA已经确认，可以在即将发布的标准跟踪文档中对提议的文本进行更改，该文档将更新[RFC4960]。IANA没有被要求执行任何其他操作，本文档也没有要求IANA对任何注册表进行更改。
This document does not add any security considerations to those given in [RFC4960].
本文件未在[RFC4960]中给出的安全注意事项基础上添加任何安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, <https://www.rfc-editor.org/info/rfc1858>.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，DOI 10.17487/RFC1858，1995年10月<https://www.rfc-editor.org/info/rfc1858>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, <https://www.rfc-editor.org/info/rfc2960>.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 2960，DOI 10.17487/RFC2960，2000年10月<https://www.rfc-editor.org/info/rfc2960>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, DOI 10.17487/RFC4460, April 2006, <https://www.rfc-editor.org/info/rfc4460>.
[RFC4460]Stewart，R.，Arias Rodriguez，I.，Poon，K.，Caro，A.，和M.Tuexen，“流控制传输协议（SCTP）规范勘误表和问题”，RFC 4460，DOI 10.17487/RFC4460，2006年4月<https://www.rfc-editor.org/info/rfc4460>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<https://www.rfc-editor.org/info/rfc5681>.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, DOI 10.17487/RFC6096, January 2011, <https://www.rfc-editor.org/info/rfc6096>.
[RFC6096]Tuexen，M.和R.Stewart，“流控制传输协议（SCTP）块标志注册”，RFC 6096，DOI 10.17487/RFC6096，2011年1月<https://www.rfc-editor.org/info/rfc6096>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<https://www.rfc-editor.org/info/rfc6298>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053]Tuexen，M.，Ruengeler，I.，和R.Stewart，“流控制传输协议的SACK-立即扩展”，RFC 7053，DOI 10.17487/RFC7053，2013年11月<https://www.rfc-editor.org/info/rfc7053>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.
[RFC8311]Black，D.，“放松对显式拥塞通知（ECN）实验的限制”，RFC 8311，DOI 10.17487/RFC8311，2018年1月<https://www.rfc-editor.org/info/rfc8311>.
Acknowledgements
致谢
The authors wish to thank Pontus Andersson, Eric W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their invaluable comments.
作者要感谢庞图斯·安德森、埃里克·比德曼、塞德里克·邦特、斯宾塞·道金斯、戈里·费尔赫斯特、本杰明·卡杜克、米尔贾·库勒温德、彼得·雷、古拉·马洛西、莱昂内尔·莫兰德、杰夫·莫里斯、卡伦·E·尼尔森、汤姆·佩奇、卡昌潘、朱利安·波尔特、艾琳·吕恩格勒、迈克尔·韦尔茨和谢乔平，感谢他们的宝贵评论。
Authors' Addresses
作者地址
Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America
Randall R.Stewart Netflix，Inc.Chapin，SC 29036美利坚合众国
Email: randall@lakerest.net
Email: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
米迦勒TuxEN明斯特应用科学大学StugWaldStasSE 39 48565斯坦福特德国
Email: tuexen@fh-muenster.de
Email: tuexen@fh-muenster.de
Maksim Proshin Ericsson Kistavaegen 25 Stockholm 164 80 Sweden
Maksim Proshin Ericsson Kistavaegen 25斯德哥尔摩164 80瑞典
Email: mproshin@tieto.mera.ru
Email: mproshin@tieto.mera.ru