Network Working Group R. Stewart
Request for Comments: 4460 Cisco Systems, Inc.
Category: Informational I. Arias-Rodriguez
Nokia Research Center
K. Poon
Sun Microsystems, Inc.
A. Caro
BBN Technologies
M. Tuexen
Muenster Univ. of Applied Sciences
April 2006
Network Working Group R. Stewart
Request for Comments: 4460 Cisco Systems, Inc.
Category: Informational I. Arias-Rodriguez
Nokia Research Center
K. Poon
Sun Microsystems, Inc.
A. Caro
BBN Technologies
M. Tuexen
Muenster Univ. of Applied Sciences
April 2006
Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
流控制传输协议（SCTP）规范勘误表和问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order 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 delta, a description of the problem and the details of the solution are also provided.
本文档汇集了六次互操作性事件期间发现的问题，以及5年来实施、测试和使用流控制传输协议（SCTP）的经验以及建议的修复。本文件提供RFC 2960的增量，并以基于时间的方式组织。这些问题按提出的顺序列出。由于某些文本经过多次更改，因此应应用文本中的最后一个增量。除了增量之外，还提供了问题的描述和解决方案的详细信息。
Table of Contents
目录
1. Introduction ....................................................6
1.1. Conventions ................................................7
2. Corrections to RFC 2960 .........................................7
2.1. Incorrect Error Type During Chunk Processing. ..............7
2.1.1. Description of the Problem ..........................7
2.1.2. Text changes to the document ........................7
2.1.3. Solution Description ................................7
1. Introduction ....................................................6
1.1. Conventions ................................................7
2. Corrections to RFC 2960 .........................................7
2.1. Incorrect Error Type During Chunk Processing. ..............7
2.1.1. Description of the Problem ..........................7
2.1.2. Text changes to the document ........................7
2.1.3. Solution Description ................................7
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
2.49.3. Solution Description .............................102
2.50. Payload Protocol Identifier .............................102
2.50.1. Description of the Problem .......................102
2.50.2. Text Changes to the Document .....................103
2.50.3. Solution Description .............................103
2.51. Karn's Algorithm ........................................104
2.51.1. Description of the Problem .......................104
2.51.2. Text Changes to the Document .....................104
2.51.3. Solution Description .............................104
2.52. Fast Retransmit Algorithm ...............................104
2.52.1. Description of the Problem .......................104
2.52.2. Text Changes to the Document .....................105
2.52.3. Solution Description .............................105
3. Security Considerations .......................................105
4. Acknowledgements ..............................................106
5. IANA Considerations ...........................................106
6. Normative References ..........................................106
2.49.3. Solution Description .............................102
2.50. Payload Protocol Identifier .............................102
2.50.1. Description of the Problem .......................102
2.50.2. Text Changes to the Document .....................103
2.50.3. Solution Description .............................103
2.51. Karn's Algorithm ........................................104
2.51.1. Description of the Problem .......................104
2.51.2. Text Changes to the Document .....................104
2.51.3. Solution Description .............................104
2.52. Fast Retransmit Algorithm ...............................104
2.52.1. Description of the Problem .......................104
2.52.2. Text Changes to the Document .....................105
2.52.3. Solution Description .............................105
3. Security Considerations .......................................105
4. Acknowledgements ..............................................106
5. IANA Considerations ...........................................106
6. Normative References ..........................................106
This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP), RFC 2960 [5]. 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 SCTP to clarify errors in the original SCTP document.
本文件包含了在本文件发布之前针对流控制传输协议（SCTP）RFC 2960[5]发现的所有缺陷的汇编。这些缺陷可能是编辑性或技术性的。本文件可被视为SCTP实施过程中的配套文件，以澄清原始SCTP文件中的错误。
This document provides a history of the changes that will be compiled into RFC 2960's [5] BIS document. Each error will be detailed within this document in the form of
本文件提供了将编入RFC 2960[5]BIS文件的变更历史记录。每个错误将在本文件中以
o the problem description,
o 问题描述，
o the text quoted from RFC 2960 [5],
o 引用自RFC 2960[5]的文本，
o the replacement text that should be placed into the BIS document, and
o 应放入BIS文件中的替换文本，以及
o a description of the solution.
o 对解决方案的描述。
This document is a historical record of sequential changes what have been found necessary at various interop events and through discussion on this list.
本文档是在各种互操作事件中以及通过在此列表上的讨论发现的必要顺序更改的历史记录。
Note that because some text is changed several times, the last delta for a text in the document is the erratum for that text in RFC 2960.
请注意，由于某些文本经过多次更改，文档中文本的最后一个增量是RFC 2960中该文本的勘误表。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [2].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照RFC 2119[2]中所述进行解释。
2.1. Incorrect Error Type During Chunk Processing.
2.1. 块处理期间错误类型不正确。
A typo was discovered in RFC 2960 [5] that incorrectly specifies an action to be taken when processing chunks of unknown identity.
在RFC 2960[5]中发现了一个输入错误，错误地指定了处理未知标识块时要采取的操作。
---------
Old text: (Section 3.2)
---------
---------
Old text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
---------
New text: (Section 3.2)
---------
---------
New text: (Section 3.2)
---------
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”中报告未识别的数据块。
The receiver of an unrecognized chunk should not send a 'parameter' error but instead should send the appropriate chunk error as described above.
无法识别的区块的接收者不应发送“参数”错误，而应如上所述发送适当的区块错误。
A typographical error was introduced through an improper cut and paste in the use of the upper two bits to describe proper handling of unknown parameters.
在使用上两位描述未知参数的正确处理时，由于剪切和粘贴不当，导致了印刷错误。
---------
Old text: (Section 3.2.1)
---------
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it; do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它；不要在其中处理任何进一步的块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
---------
New text: (Section 3.2.1)
---------
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk.
00-停止处理此SCTP块并放弃它，不要处理此块中的任何其他参数。
01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP区块并放弃它，不处理此区块内的任何其他参数，并在“未识别的参数类型”中报告未识别的参数（在错误或初始确认中）。
It was always the intent to stop processing at the level one was at in an unknown chunk or parameter with the upper bit set to 0. Thus, if you are processing a chunk, you should drop the packet. If you are processing a parameter, you should drop the chunk.
在高位设置为0的未知块或参数中，始终希望在一级停止处理。因此，如果您正在处理一个数据块，您应该丢弃该数据包。如果您正在处理一个参数，那么应该删除该块。
A problem was found when a Chunk terminated in a TLV parameter. If this last TLV was not on a 32-bit boundary (as required), there was confusion as to whether the last padding was included in the chunk length.
在TLV参数中终止区块时发现问题。如果最后一个TLV不在32位边界上（根据需要），那么最后一个填充是否包含在块长度中就存在混淆。
---------
Old text: (Section 3.2)
---------
---------
Old text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
块长度：16位（无符号整数）
This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding.
此值表示块的大小（以字节为单位），包括块类型、块标志、块长度和块值字段。因此，如果区块值字段的长度为零，则长度字段将设置为4。区块长度字段不计算任何填充。
Chunk Value: variable length
区块值：可变长度
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
区块值字段包含要在区块中传输的实际信息。此字段的用法和格式取决于区块类型。
The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
块的总长度（包括类型、长度和值字段）必须是4字节的倍数。如果区块的长度不是4字节的倍数，则发送方必须用所有零字节填充区块，并且该填充不包括在区块长度字段中。发送方的填充长度不应超过3个字节。接收器必须忽略填充字节。
---------
New text: (Section 3.2)
---------
---------
New text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
块长度：16位（无符号整数）
This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding.
此值表示块的大小（以字节为单位），包括块类型、块标志、块长度和块值字段。因此，如果区块值字段的长度为零，则长度字段将设置为4。“块长度”字段不计算任何块填充。
Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding.
数据块（包括类型、长度和值字段）由发送方填充，所有零字节都是4字节长的倍数。此填充总共不得超过3个字节。区块长度值不包括区块的终止填充。但是，它确实包括任何可变长度参数的填充，块中最后一个参数除外。接收器必须忽略填充。
Note: A robust implementation should accept the Chunk whether or not the final padding has been included in the Chunk Length.
注意：一个健壮的实现应该接受区块，无论区块长度中是否包含最终填充。
Chunk Value: variable length
区块值：可变长度
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
区块值字段包含要在区块中传输的实际信息。此字段的用法和格式取决于区块类型。
The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
块的总长度（包括类型、长度和值字段）必须是4字节的倍数。如果区块的长度不是4字节的倍数，则发送方必须用所有零字节填充区块，并且该填充不包括在区块长度字段中。发送方的填充长度不应超过3个字节。接收器必须忽略填充字节。
The above text makes clear that the padding of the last parameter is not included in the Chunk Length field. It also clarifies that the padding of parameters that are not the last one must be counted in the Chunk Length field.
上面的文本清楚地表明，最后一个参数的填充不包括在Chunk Length字段中。它还澄清了非最后一个参数的填充必须在Chunk Length字段中计数。
A problem was noted when multiple errors are needed to be sent regarding unknown or unrecognized parameters. Since often the error type does not hold the chunk type field, it may become difficult to tell which error was associated with which chunk.
当需要发送有关未知或无法识别的参数的多个错误时，出现了一个问题。由于错误类型通常不包含chunk type字段，因此可能很难判断哪个错误与哪个chunk关联。
---------
Old text: (Section 3.2.1)
---------
---------
Old text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2.
实际的SCTP参数在特定的SCTP区块部分中定义。IETF定义的参数扩展规则见第13.2节。
---------
New text: (Section 3.2.1)
---------
---------
New text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are
实际的SCTP参数在特定的SCTP区块部分中定义。IETF定义的参数扩展规则如下
defined in Section 13.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk.
定义见第13.2节。请注意，参数类型在所有块中都必须是唯一的。例如，参数类型“5”用于表示IPv4地址（请参阅第3.3.2节）。然后，值“5”在所有区块中保留以表示IPv4地址，并且不得在任何其他区块中以不同的含义重复使用。
---------
Old text: (Section 13.2)
---------
---------
Old text: (Section 13.2)
---------
13.2 IETF-defined Chunk Parameter Extension
13.2 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) Name of the parameter type.
a) 参数类型的名称。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1.
b) 参数字段结构的详细说明。该结构必须符合第3.2.1节所述的通用类型长度值格式。
c) Detailed definition of each component of the parameter type.
c) 参数类型的每个组件的详细定义。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一块中找到此参数类型的多个实例的指示。
---------
New text: (Section 13.2)
---------
---------
New text: (Section 13.2)
---------
13.2. IETF-defined Chunk Parameter Extension
13.2. 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) Name of the parameter type.
a) 参数类型的名称。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1.
b) 参数字段结构的详细说明。该结构必须符合第3.2.1节所述的通用类型长度值格式。
c) Detailed definition of each component of the parameter type.
c) 参数类型的每个组件的详细定义。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) 此参数类型的预期用途的详细说明，以及是否以及在何种情况下可在同一块中找到此参数类型的多个实例的指示。
e) Each parameter type MUST be unique across all chunks.
e) 每个参数类型在所有块中都必须是唯一的。
By having all parameters unique across all chunk assignments (the current assignment policy), no ambiguity exists as to what a parameter means in different contexts. The trade-off for this is a smaller parameter space, i.e., 65,536 parameters versus 65,536 * Number-of- chunks.
通过使所有区块分配中的所有参数都是唯一的（当前分配策略），就不存在参数在不同上下文中的含义的歧义。这样做的代价是参数空间更小，即65536个参数与65536*个块的数量相比。
A problem was found where the specification is unclear on the legality of an endpoint asking for more stream resources than were allowed in the MIS value of the INIT. In particular, the value in the INIT ACK requested in its OS value was larger than the MIS value received in the INIT chunk. This behavior is illegal, yet it was unspecified in RFC 2960 [5]
发现了一个问题，即规范不清楚端点请求的流资源是否比INIT的MIS值中允许的更多。特别是，在其OS值中请求的INIT ACK中的值大于在INIT块中接收的MIS值。这种行为是非法的，但在RFC 2960[5]中未明确说明
---------
Old text: (Section 3.3.3)
---------
---------
Old text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
出站流（OS）数：16位（无符号整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used.
定义此INIT ACK块的发送方希望在此关联中创建的出站流数。不得使用0的值。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
注意：OS值设置为0的INIT ACK接收器应销毁关联，丢弃其TCB。
---------
New text: (Section 3.3.3)
---------
---------
New text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
出站流（OS）数：16位（无符号整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk.
定义此INIT ACK块的发送方希望在此关联中创建的出站流数。不得使用0的值，且该值不得大于INIT块中发送的MIS值。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association, discarding its TCB.
注意：OS值设置为0的INIT ACK接收器应销毁关联，丢弃其TCB。
The change in wording, above, changes it so that a responder to an INIT chunk does not specify more streams in its OS value than were represented to it in the MIS value, i.e., its maximum.
上述措辞的改变改变了它，使得INIT块的响应者在其OS值中指定的流不会比在MIS值（即其最大值）中表示的流多。
A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur, and the intruder would have hijacked an association.
重新启动时发现安全问题。入侵者可能向现有关联的端点发送INIT。在INIT中，入侵者将列出一个或多个关联及其自身的当前地址。然后，正常的重启过程就会发生，入侵者就会劫持一个关联。
---------
Old text: (Section 3.3.10)
---------
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
“原因”字段，包括“原因代码”的“原因长度”参数设置
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
第3.3.10.1-3.3.10.10节定义了SCTP的错误原因。
Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Section 3.3.10)
---------
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields.
设置为参数的大小（字节），包括原因代码、原因长度和原因特定信息字段。
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.11节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Note no old text, new error cause added in section 3.3.10)
---------
---------
New text: (Note no old text, new error cause added in section 3.3.10)
---------
3.3.10.11. Restart of an Association with New Addresses (11)
3.3.10.11. 重新启动与新地址的关联（11）
Cause of error
--------------
Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
new addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see Section 5.2).
Cause of error
--------------
Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
new addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see Section 5.2).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter length.
注意：每个新地址TLV都是在新的INIT块中找到的TLV的精确副本，包括参数类型和参数长度。
---------
Old text: (Section 5.2.1)
---------
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged). These original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
在接收到处于COOKIE-WAIT或COOKIE-echood状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其Initiation标记，未更改）响应INIT ACK。这些原始参数与新接收的INIT块中的参数组合在一起。端点还应使用INIT ACK生成状态Cookie。端点使用在其INIT中发送的参数来计算状态Cookie。
---------
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 Initiation 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 to.
在接收到处于COOKIE-WAIT状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其初始标记，未更改）响应INIT ACK。响应时，端点必须将INIT ACK发送回原始INIT（由该端点发送）发送到的相同地址。
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
在接收到处于COOKIE-echood状态的INIT时，端点必须使用其在原始INIT块中发送的相同参数（包括其初始标记，未更改）响应INIT ACK，前提是未向形成关联添加新地址。如果INIT消息指示已将新地址添加到关联中，则必须放弃整个INIT，并且不应对现有关联进行任何更改。应发送中止响应，该响应可能包括错误“重新启动与新地址的关联”。错误应列出添加到重新启动关联的地址。
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK, the original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
当以INIT ACK的任一状态（COOKIE-WAIT或COOKIE-echood）响应时，原始参数与新接收到的INIT块中的参数组合在一起。端点还应使用INIT ACK生成状态Cookie。端点使用在其INIT中发送的参数来计算状态Cookie。
---------
Old text: (Section 5.2.2)
---------
---------
Old text: (Section 5.2.2)
---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT
5.2.2 非关闭、COOKIE-Echosed、COOKIE-WAIT和SHUTDOWN-ACK-SENT状态下的意外初始化
Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
除非另有说明，否则在接收到此关联的意外INIT时，端点应使用状态Cookie生成INIT ACK。在outbound INIT ACK中，端点必须将其当前验证标记和对等方的验证标记复制到状态cookie中的保留位置。我们将这些位置称为对等的Tie-Tag和本地Tie-Tag。包含此初始化确认的出站SCTP数据包必须携带与意外初始化中找到的初始化标记相等的验证标记值。初始确认必须包含新的初始标签（随机生成，见第5.3.1节）。端点的其他参数应从关联的现有参数（例如，出站流的数量）复制到INIT ACK和cookie中。
After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
在发送INIT ACK之后，端点不应采取进一步的操作，即现有关联，包括其当前状态，并且不得更改相应的TCB。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT state are the Tie-Tags populated. For a normal association INIT (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.
注意：只有当TCB存在且关联未处于COOKIE-WAIT状态时，才会填充Tie标记。对于正常关联INIT（即端点处于COOKIE-WAIT状态），Tie标记必须设置为0（表示之前不存在TCB）。按照第5.2.1节的规定填充初始确认和状态Cookie。
---------
New text: (Section 5.2.2)
---------
---------
New text: (Section 5.2.2)
---------
5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.2. 处于关闭、COOKIE-Echosed、COOKIE-WAIT和SHUTDOWN-ACK-SENT以外状态的意外初始化
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding, the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond
除非另有说明，否则在收到此关联的意外INIT时，端点应使用状态Cookie生成INIT ACK。在响应之前，端点必须检查意外的INIT是否向关联添加了新地址。如果将新地址添加到关联中，端点必须响应
with an ABORT, copying the 'Initiation Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In the ABORT response, the cause of error MAY be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
使用中止，将意外初始化的“启动标签”复制到携带中止的出站数据包的“验证标签”中。在中止响应中，错误原因可能设置为“重新启动与新地址的关联”。错误应列出添加到重新启动关联的地址。
If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
如果未添加新地址，则在响应出站初始化确认中的初始化时，端点必须将其当前验证标记和对等方的验证标记复制到状态cookie中的保留位置。我们将这些位置称为对等的Tie-Tag和本地Tie-Tag。包含此初始化确认的出站SCTP数据包必须携带与意外初始化中找到的初始化标记相等的验证标记值。初始确认必须包含一个新的初始标签（随机生成；见第5.3.1节）。端点的其他参数应从关联的现有参数（例如，出站流的数量）复制到INIT ACK和cookie中。
After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
在发送INIT ACK或ABORT后，端点不应采取进一步的操作；i、 例如，不能更改现有关联（包括其当前状态）和相应的TCB。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e., the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed).
注意：只有当TCB存在且关联未处于COOKIE-WAIT或SHUTDOWN-ACK-SENT状态时，Tie标记才会填充0以外的值。对于正常关联初始化（即端点处于关闭状态），Tie标记必须设置为0（表示之前不存在TCB）。
A new error code is being added, along with specific instructions to send back an ABORT to a new association in a restart case or collision case, where new addresses have been added. The error code can be used by a legitimate restart to inform the endpoint that it has made a software error in adding a new address. The endpoint then can choose to wait until the OOTB ABORT tears down the old association, or to restart without the new address.
正在添加新的错误代码，以及在重新启动或冲突情况下向新关联发回中止的特定指令，其中已添加了新地址。合法重新启动可以使用错误代码通知端点在添加新地址时发生软件错误。然后，端点可以选择等待直到OOTB中止删除旧关联，或者在没有新地址的情况下重新启动。
Also, the note at the end of Section 5.2.2 explaining the use of the Tie-Tags was modified to properly explain the states in which the Tie-Tags should be set to a value different than 0.
此外，对第5.2.2节末尾解释系紧标签使用的注释进行了修改，以正确解释系紧标签应设置为不同于0的值的状态。
Some implementations were having difficulty growing their cwnd. This was due to an improper enforcement of the congestion control rules. The rules, as written, provided for a slop over of the cwnd value. Without this slop over, the sender would appear NOT to be using its full cwnd value and thus would never increase it.
一些实现难以扩展其cwnd。这是由于交通拥堵控制规则执行不当造成的。如前所述，规则规定了cwnd值的斜率。如果没有这种倾斜，发送方似乎不会使用其完整的cwnd值，因此永远不会增加它。
---------
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 or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded.
B） 在任何给定的时间，如果发送方有cwnd或更多字节的数据未发送到给定的传输地址，则发送方不得将新数据发送到该传输地址。如果当前未超过cwnd，则发送方在新传输上最多可超过cwnd（PMTU-1）字节。
The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes.
文本更改明确了在cwnd值上移动不超过（PMTU-1）字节的能力。
Several problems were found in the current specification of fast retransmit. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. The specification left unclear how to handle the fast retransmit cycle, having the implementation wait on the cwnd to retransmit a TSN that was marked for fast retransmit. No limit was placed on how many times a TSN could be fast retransmitted. Fast Recovery was not specified, causing the congestion window to be reduced drastically when there are multiple losses in a single RTT.
在当前的快速重传规范中发现了几个问题。当前的措辞不要求发送GAP ACK块，即使它们对SCTP拥塞控制的工作至关重要。该规范不清楚如何处理快速重传周期，让实现在cwnd上等待重传标记为快速重传的TSN。TSN可以快速重新传输的次数没有限制。未指定快速恢复，导致在单个RTT中存在多个丢失时，拥塞窗口将大幅减少。
---------
Old text: (Section 6.2)
---------
---------
Old text: (Section 6.2)
---------
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields.
确认必须以SACK块的形式发送，除非ULP请求关闭，在这种情况下，端点可以在关闭块中发送确认。SACK块可以确认多个数据块的接收。SACK区块格式见第3.3.4节。特别是，SCTP端点必须填写累积TSN Ack字段，以指示其接收到的（有效数据块的）最新顺序TSN。任何接收到的TSN大于累积TSN Ack字段中的值的数据块也应在Gap Ack块字段中报告。
---------
New text: (Section 6.2)
---------
---------
New text: (Section 6.2)
---------
Acknowledegments MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU.
Acknowledegments必须以SACK块的形式发送，除非ULP请求关闭，在这种情况下，端点可以在关闭块中发送确认。SACK块可以确认多个数据块的接收。SACK区块格式见第3.3.4节。特别是，SCTP端点必须填写累积TSN Ack字段，以指示其接收到的（有效数据块的）最新顺序TSN。任何接收到的TSN大于累积TSN Ack字段中的值的数据块都会在Gap Ack块字段中报告。SCTP端点必须报告受当前路径MTU限制的单个SACK块中所能容纳的尽可能多的Gap Ack块。
---------
Old text: (Section 6.2.1)
---------
---------
Old text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
D） 每当SACK到达时，端点都会执行以下操作：
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 如果累计TSN Ack小于累计TSN Ack点，则丢弃SACK。由于累积TSN Ack是单调递增的，因此累积TSN Ack小于累积TSN Ack点的SACK表示顺序错误的SACK。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）将rwnd设置为新接收的a_rwnd减去处理累积TSN Ack和Gap Ack块后仍然未完成的字节数。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then mark the corresponding DATA chunk as available for retransmit: Mark it as missing for fast retransmit as described in Section 7.2.4 and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）如果SACK缺少先前通过Gap Ack块确认的TSN（例如，数据接收器拒绝接收数据），然后将相应的数据块标记为可用于重新传输：如第7.2.4节所述，将其标记为缺少可用于快速重新传输的数据块，如果没有为数据块最初传输到的目标地址运行重新传输计时器，则为该目标地址启动T3 rtx。
---------
New text: (Section 6.2.1)
---------
---------
New text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
D） 每当SACK到达时，端点都会执行以下操作：
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 如果累计TSN Ack小于累计TSN Ack点，则丢弃SACK。由于累积TSN Ack是单调递增的，因此累积TSN Ack小于累积TSN Ack点的SACK表示顺序错误的SACK。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）将rwnd设置为新接收的a_rwnd减去处理累积TSN Ack和Gap Ack块后仍然未完成的字节数。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then consider the corresponding DATA that might be possibly missing: Count one miss indication towards fast retransmit as described in Section 7.2.4, and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）如果SAG丢失了先前通过间隙ACK块确认的TSN（例如，数据接收器放弃了数据），那么考虑可能丢失的相应数据：如7.2.4节所述，对快速重传计数一个未命中指示；如果没有为数据块最初传输到的目标地址运行重新传输计时器，则为该目标地址启动t3rtx。
iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
iv）如果累计TSN Ack匹配或超过快速恢复退出点（第7.2.4节），则快速恢复退出。
---------
Old text: (Section 7.2.4)
---------
---------
Old text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
每当端点接收到指示某些TSN丢失的SACK时，它应该等待相同TSN上的3个进一步的未命中指示（通过后续SACK），然后再采取有关快速重新传输的操作。
When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall:
当连续第四个SACK中报告TSN缺失时，数据发送方应：
1) Mark the missing DATA chunk(s) for retransmission,
1) 标记丢失的数据块以便重新传输，
2) Adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2) 根据第7.2.3节中描述的公式，调整上次向其发送缺失数据块的目标地址的ssthresh和cwnd。
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet.
3) 根据分组被发送到的目的地传输地址的路径MTU的约束，确定标记为重传的最早（即，最低TSN）数据块中有多少将适合于单个分组。调用该值K。在单个数据包中重新传输这些K个数据块。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4) 仅当最后一个SACK确认发送到该地址的最低未完成TSN号，或者端点正在重新传输发送到该地址的第一个未完成数据块时，才重新启动T3 rtx计时器。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
注：在进行上述调整之前，如果收到的SACK也确认新的数据块并提前累计TSN确认点，则必须首先应用第7.2.1节和第7.2.2节中定义的cwnd调整规则。
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit procedure, the counter resets to 0. 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孔的每个连续袋，计数器递增。达到4并开始快速重传程序后，计数器重置为0。由于SCTP中的cwnd间接限制了未完成TSN的数量，因此TCP快速恢复的效果是自动实现的，而无需调整拥塞控制窗口的大小。
---------
New text: (Section 7.2.4)
---------
---------
New text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 3 further miss indications (via subsequent SACKs) on the same TSN(s) before taking action with regard to Fast Retransmit.
每当端点接收到指示某些TSN丢失的SACK时，它应等待同一TSN上的3个进一步的未命中指示（通过后续SACK），然后再采取有关快速重传的措施。
Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK.
未命中指示应遵循HTNA（最高TSN新确认）算法。对于每个传入SACK，仅在SACK中新确认的最高TSN之前，缺失TSN的未命中指示才会增加。新确认的数据块是SACK中以前未确认的数据块。如果端点处于快速恢复状态，且SACK到达并超过累积TSN确认点，则SACK中报告缺失的所有TSN的未命中指示将增加。
When the fourth consecutive miss indication is received for a TSN(s), the data sender shall do the following:
当接收到TSN的第四个连续未命中指示时，数据发送方应执行以下操作：
1) Mark the DATA chunk(s) with four miss indications for retransmission.
1) 用四个未命中指示标记数据块，以便重新传输。
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2) 如果不是在快速恢复中，根据第7.2.3节中描述的公式，调整上次向其发送丢失数据块的目标地址的ssthresh和cwnd。
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3) 根据分组被发送到的目的地传输地址的路径MTU的约束，确定标记为重传的最早（即，最低TSN）数据块中有多少将适合于单个分组。调用该值K。在单个数据包中重新传输这些K个数据块。当执行快速重传时，发送方应忽略cwnd的值，并且不应延迟此单个数据包的重传。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4) 仅当最后一个SACK确认发送到该地址的最低未完成TSN号，或者端点正在重新传输发送到该地址的第一个未完成数据块时，才重新启动T3 rtx计时器。
5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent fast retransmit. Those TSNs marked for retransmission due to the Fast Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent fast retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows.
5) 将数据块标记为正在快速重新传输，因此没有资格进行后续快速重新传输。由于快速重传算法而被标记为重传的那些TSN不适合于携带K个其他TSN的发送数据报，也被标记为不适合后续快速重传。但是，由于它们被标记为要重新传输，因此在cwnd允许的情况下，稍后将尽快重新传输它们。
6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any destinations due to a subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further due to a subsequent fast retransmit).
6) 如果不在快速恢复中，请输入快速恢复，并将最高的未完成TSN标记为快速恢复退出点。当SACK确认到并包括此退出点的所有TSN时，将退出快速恢复。在快速恢复中，ssthresh和cwnd不应因后续快速恢复事件而改变任何目的地（即，不应因后续快速重传而进一步减少cwnd）。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
注：在进行上述调整之前，如果收到的SACK也确认新的数据块并提前累计TSN确认点，则必须首先应用第7.2.1节和第7.2.2节中定义的cwnd调整规则。
The effect of the above wording changes are as follows:
上述措辞变更的影响如下：
o It requires with a MUST the sending of GAP Ack blocks instead of the current RFC 2960 [5] SHOULD.
o 它要求必须发送GAP Ack块，而不是当前的RFC 2960[5]。
o It allows a TSN being Fast Retransmitted (FR) to be sent only once via FR.
o 它允许被快速重传（FR）的TSN仅通过FR发送一次。
o It ends the delay in waiting for the flight size to drop when a TSN is identified as being ready to FR.
o 当TSN被识别为准备好FR时，它结束等待航班大小下降的延迟。
o It changes the way chunks are marked during fast retransmit, so that only new reports are counted.
o 它改变了在快速重传期间标记块的方式，因此只统计新报告。
o It introduces a Fast Recovery period to avoid multiple congestion window reductions when there are multiple losses in a single RTT (as shown by Caro et al. [3]).
o 它引入了一个快速恢复期，以避免在单个RTT中存在多个损失时出现多个拥塞窗口减少（如Caro等人[3]所示）。
These changes will effectively allow SCTP to follow a similar model as TCP+SACK in the handling of Fast Retransmit.
这些更改将有效地允许SCTP在处理快速重传时遵循与TCP+SACK类似的模型。
SCTP uses four control variables to regulate its transmission rate: rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of packet losses from SACK, or when the T3-rtx timer expires on an address, cwnd and ssthresh should be updated as stated in Section 7.2.3. However, that section should also clarify that partial_bytes_acked must be updated as well; it has to be reset to 0.
SCTP使用四个控制变量来调节其传输速率：rwnd、cwnd、ssthresh和partial_bytes_acked。在检测到SACK的数据包丢失时，或者当T3 rtx定时器在某个地址上过期时，应按照第7.2.3节的规定更新cwnd和ssthresh。但是，该部分还应澄清，部分确认的字节也必须更新；必须将其重置为0。
---------
Old text: (Section 7.2.3)
---------
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
7.2.3 拥塞控制
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
在检测到来自SACK的数据包丢失时（参见第7.2.4节），端点应执行以下操作：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
---------
New text: (Section 7.2.3)
---------
7.2.3. Congestion Control
7.2.3. 拥塞控制
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following if not in Fast Recovery:
在检测到SACK的数据包丢失后（参见第7.2.4节），如果不是在快速恢复中，端点应执行以下操作：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by
当T3 rtx计时器在某个地址上过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
The missing text added solves the doubts about what to do with partial_bytes_acked in the situations stated in Section 7.2.3, making clear that, along with ssthresh and cwnd, partial_bytes_acked should also be updated by being reset to 0.
添加的缺失文本解决了在第7.2.3节所述情况下如何处理部分字节的疑问，明确了与ssthresh和cwnd一起，部分字节也应通过重置为0进行更新。
Five basic problems have been discovered with the current heartbeat procedures:
目前的心跳程序发现了五个基本问题：
o The current specification does not specify that you should count a failed heartbeat as an error against the overall association.
o 当前规范没有指定您应该将失败的心跳计数为针对整个关联的错误。
o The current specification is not specific as to when you start sending heartbeats and when you should stop.
o 当前规范没有具体说明何时开始发送心跳以及何时停止。
o The current specification is not specific as to when you should respond to heartbeats.
o 当前的规范没有具体说明您应该何时响应心跳。
o When responding to a Heartbeat, it is unclear what to do if more than a single TLV is present.
o 当响应心跳时，如果存在多个TLV，则不清楚该怎么办。
o The jitter applied to a heartbeat was meant to be a small variance of the RTO and is currently a wide variance, due to the default delay time and incorrect wording within the RFC.
o 应用于心跳的抖动意味着RTO的微小差异，而由于RFC中的默认延迟时间和不正确的措辞，目前是一个很大的差异。
---------
Old text: (Section 8.1)
---------
---------
Old text: (Section 8.1)
---------
8.1 Endpoint Failure Detection
8.1 端点故障检测
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
端点应保留一个计数器，记录到其对等方的连续重传总数（包括到对等方的所有目的地传输地址的重传，如果它是多宿的）。如果该计数器的值超过协议参数关联.Max .ReTrin所表示的极限，则端点应考虑对等端点不可到达，并且停止向其发送更多的数据（从而关联进入关闭状态）。此外，端点应向上层报告故障，并选择性地报告其出站队列中剩余的所有未完成用户数据。当对等端点变得不可访问时，关联将自动关闭。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint.
每次确认发送到该对等端点的数据块（通过接收SACK）或从该对等端点接收到心跳确认时，都应重置计数器。
---------
New text: (Section 8.1)
---------
---------
New text: (Section 8.1)
---------
8.1. Endpoint Failure Detection
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. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint MAY report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
端点应保留一个计数器，记录到其对等方的连续重传总数（这包括到对等方的所有目标传输地址的重传，如果它是多宿的），包括未确认的心跳块。如果该计数器的值超过协议参数关联.Max .ReTrin所表示的极限，则端点应考虑对等端点不可到达，并且停止向其发送更多的数据（从而关联进入关闭状态）。此外，端点可以向上层报告故障，并选择性地报告其出站队列中剩余的所有未完成用户数据。当对等端点变得不可访问时，关联将自动关闭。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint.
每次确认发送到该对等端点的数据块（通过接收SACK）或从该对等端点接收到心跳确认时，都应重置计数器。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
8.3 Path Heartbeat
8.3 路径心跳
By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es).
默认情况下，SCTP端点应通过定期向目标传输地址发送心跳数据块来监控其对等方的空闲目标传输地址的可达性。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
8.3 Path Heartbeat
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
默认情况下，SCTP端点应该通过周期性地向目标传输地址发送心跳数据块来监视其对等方的空闲目标传输地址的可达性。心跳信号发送可在达到既定状态时开始，并在发送SHUTDOWN或SHUTDOWN-ACK后中断。心跳的接收器必须在进入COOKIE-echood状态后使用HEARTBEAT-ACK响应心跳
(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).
（初始发送方）或已建立状态（初始接收方），直至达到SHUTDOWN-SENT状态（SHUTDOWN发送方）或SHUTDOWN-ACK-SENT状态（SHUTDOWN接收方）。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk.
心跳的接收器应立即响应心跳确认，该确认包含从接收到的心跳块复制的心跳信息字段。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk.
心跳的接收器应立即响应心跳确认，其中包含心跳信息TLV以及任何其他接收到的TLV，这些TLV未经更改地从接收到的心跳块复制而来。
---------
Old text: (Section 8.3)
---------
---------
Old text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
在允许心跳的空闲目标地址上，建议每个目标地址的RTO加上协议参数“HB.interval”发送一次心跳块，抖动为+/-50%，如果前一个心跳未响应，则RTO将以指数形式后退。
---------
New text: (Section 8.3)
---------
---------
New text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, it is recommended that a HEARTBEAT chunk is sent once per RTO of that destination address plus the protocol parameter 'HB.interval', with jittering of +/- 50% of the RTO value, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
在允许心跳的空闲目标地址上，建议每个目标地址的RTO加上协议参数“HB.interval”发送一次心跳块，抖动为RTO值的+/-50%，如果前一个心跳未响应，则按指数方式退出RTO。
The above text provides guidance as to how to respond to the five issues mentioned in Section 2.10.1. In particular, the wording changes provide guidance as to when to start and stop heartbeating,
上述文本就如何应对第2.10.1节中提到的五个问题提供了指导。特别是，措辞的变化为何时开始和停止心跳提供了指导，
how to respond to a heartbeat with extra parameters, and it clarifies the error counting procedures for the association.
如何使用额外的参数响应心跳，并阐明关联的错误计数过程。
When dealing with firewalls, it is advantageous for the firewall to be able to properly determine the initial startup sequence of a reliable transport protocol. With this in mind, the following text is to be added to SCTP's security section.
在处理防火墙时，防火墙能够正确地确定可靠传输协议的初始启动顺序是有利的。考虑到这一点，以下文本将添加到SCTP的安全部分。
---------
New text: (no old text, new section added)
---------
---------
New text: (no old text, new section added)
---------
11.4 SCTP Interactions with Firewalls
11.4 SCTP与防火墙的交互
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to RFC1858). Accordingly, we stress the requirements, stated in 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.
如果某些防火墙可以只检查片段化SCTP数据包的第一个片段，并明确确定它是否对应于INIT块（有关更多信息，请参阅RFC1858），则这对它们很有帮助。因此，我们强调3.1中所述的要求，（1）INIT块不得与数据包中的任何其他块捆绑在一起，（2）包含INIT块的数据包必须具有零验证标记。此外，我们要求INIT块的接收者必须强制执行这些规则，方法是悄悄地丢弃带有与其他块捆绑在一起的INIT块的到达数据包。
---------
Old text: (Section 18)
---------
---------
Old text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]Allman，M.和Paxson，V.，“关于估算端到端网络路径属性”，Proc。SIGCOMM'991999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[Fall 96]Fall，K.和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]伊斯特莱克，D.（编辑），“安全的随机性建议”，RFC17501994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，Anderson，T.，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，29（5），1999年10月。
---------
New text: (Section 18)
---------
---------
New text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]Allman，M.和Paxson，V.，“关于估算端到端网络路径属性”，Proc。SIGCOMM'991999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[Fall 96]Fall，K.和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]伊斯特莱克，D.（编辑），“安全的随机性建议”，RFC17501994年12月。
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.和Traina P.，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，Anderson，T.，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，29（5），1999年10月。
The above text, which adds a new subsection to the Security Considerations section of RFC 2960 [5] makes clear that, to make easier the interaction with firewalls, an INIT chunk must not be bundled in any case with any other chunk that will silently discard the packets that do not follow this rule (this rule is enforced by the packet receiver).
上面的文本在RFC 2960[5]的安全注意事项部分添加了一个新的小节，明确指出，为了更容易与防火墙交互，在任何情况下，都不能将INIT块与任何其他块捆绑在一起，这些块将自动丢弃不遵循此规则的数据包（此规则由数据包接收器强制执行）。
Currently, there is an ambiguity between the statements in Sections 6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in place of a SACK when the sender is in the process of shutting down, while section 9.2 requires that both a SHUTDOWN chunk and a SACK chunk be sent.
目前，第6.2节和第9.2节中的陈述存在歧义。第6.2节允许发送方在关机过程中发送关机区块代替SACK，而第9.2节要求同时发送关机区块和SACK区块。
Along with this ambiguity there is a problem wherein an errant SHUTDOWN receiver may fail to stop accepting user data.
除了这种模糊性，还有一个问题，错误的关机接收器可能无法停止接受用户数据。
---------
Old text: (Section 9.2)
---------
---------
Old text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
如果仍然存在未完成的数据块，停堆接收器应继续遵循第6节中规定的正常数据传输程序，直到所有未完成的数据块都得到确认；但是，关机接收器不得接受来自其SCTP用户的新数据。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
处于SHUTDOWN-SENT状态时，SHUTDOWN发送方必须立即使用SACK、SHUTDOWN chunk响应包含一个或多个数据块的每个接收数据包，并重新启动T2 SHUTDOWN定时器。如果没有更多未处理的数据块，停机接收器应发送停机确认，并启动自己的T2停机计时器，进入停机确认发送状态。如果计时器过期，端点必须重新发送关机确认。
---------
New text: (Section 9.2)
---------
---------
New text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
如果仍然存在未完成的数据块，停堆接收器必须继续遵循第6节中定义的正常数据传输程序，直到所有未完成的数据块都得到确认；但是，关机接收器不得接受来自其SCTP用户的新数据。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent.
在SHUTDOWN-SENT状态下，SHUTDOWN发送方必须立即使用SHUTDOWN chunk响应包含一个或多个数据块的每个接收数据包，并重新启动T2 SHUTDOWN定时器。如果关机区块本身无法确认所有接收到的数据区块（即，可以确认的TSN大于累计TSN，因此TSN序列中存在间隙），或者如果已接收到重复的TSN，则还必须发送SACK区块。
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
停机发送器也可启动总保护定时器“T5停机保护”，以限制停机顺序的总时间。在此计时器过期时，发送方应通过发送中止块中止关联。如果使用“T5停机保护”计时器，则应将其设置为建议值“RTO.Max”的5倍。
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
如果停机接收器没有更多未完成的数据块，停机接收器必须发送停机确认并启动自己的T2停机计时器，进入停机确认发送状态。如果计时器过期，端点必须重新发送关机确认。
The above text clarifies the use of a SACK in conjunction with a SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown sequence to protect against errant receivers of SHUTDOWN chunks.
上面的文本阐明了SACK与SHUTDOWN块的结合使用。它还向SCTP关机序列添加了一个保护计时器，以防止关机块的错误接收器。
It was noted that the wording in Section 8.5.1 did not give proper directions in the use of the 'T bit' with the Verification Tags.
需要注意的是，第8.5.1节中的措辞没有给出使用带有验证标签的“T位”的正确说明。
---------
Old text: (Section 8.5.1)
---------
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B） 数据包承载中止规则：
- The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known.
- 端点应始终在出站数据包的验证标签字段中填入目标端点的标签值（如果已知）。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果验证标签与其自己的标签或其对等方的标签匹配，则接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
---------
New text: (Section 8.5.1)
---------
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B） 数据包承载中止规则：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- 端点必须始终使用目标端点的标记值（如果已知）填写出站数据包的验证标记字段。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver of a ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果数据包的验证标记字段与其自己的标记匹配，或者如果数据包设置为其对等方的标记，并且在区块标志中设置了T位，则中止的接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
The above text change clarifies that the T bit must be set before an implementation looks for the peer's tag.
上面的文本更改澄清了在实现查找对等标记之前必须设置T位。
A problem was found with the current specification of the growth and decay of cwnd. The cwnd should only be increased if it is being fully utilized, and after periods of underutilization, the cwnd should be decreased. In some sections, the current wording is weak and is not clearly defined. Also, the current specification unnecessarily introduces the need for special case code to ensure cwnd degradation. Plus, the cwnd should not be increased during Fast Recovery, since a full cwnd during Fast Recovery does not qualify the cwnd as being fully utilized. Additionally, multiple loss scenarios in a single window may cause the cwnd to grow more rapidly as the number of losses in a window increases [3].
发现cwnd生长和衰变的现行规范存在问题。只有在充分利用cwnd的情况下，才应增加cwnd，并且在利用不足一段时间后，应减少cwnd。在一些章节中，目前的措词很薄弱，没有明确界定。此外，当前规范不必要地引入了特殊情况代码的需求，以确保cwnd降级。此外，在快速恢复期间不应增加cwnd，因为快速恢复期间的完整cwnd不符合cwnd被充分利用的条件。此外，单个窗口中的多个损失场景可能会导致cwnd随着窗口中损失数量的增加而增长更快[3]。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow.
D） 然后，发送方可以根据上述规则A和规则B发送尽可能多的新数据块。
---------
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 as follows:
D） 当发送方传输新数据块时，应使用协议参数Max.Burst来限制发送的数据包数量。可通过如下调整cwnd来应用该限值：
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.
或者，它可以通过严格限制输出例程发出的数据包的数量来应用。
E) Then, the sender can send out as many new DATA chunks as Rule A and Rule B allow.
E） 然后，发送方可以发送规则A和规则B允许的尽可能多的新数据块。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd (assuming the current congestion window is being fully utilized). If an incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99].
o 当cwnd小于或等于ssthresh时，SCTP端点必须使用慢启动算法来增加cwnd（假设当前拥塞窗口被充分利用）。如果传入SACK提前了累积TSN Ack点，则cwnd必须最多增加1）已确认的先前未完成数据块的总大小，以及2）目标的路径MTU中的较小者。这可以防止[99]中概述的ACK分裂攻击。
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST use the slow start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased; otherwise, the cwnd MUST not be increased. If these conditions are met, then cwnd MUST be increased by, at most, the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99].
o 当cwnd小于或等于ssthresh时，SCTP端点必须使用慢启动算法来增加cwnd，前提是当前拥塞窗口正被充分利用，传入SACK提前累积TSN Ack点，并且数据发送方未处于快速恢复状态。只有满足这三个条件，才能增加cwnd；否则，不得增加cwnd。如果满足这些条件，则cwnd最多必须增加1）已确认的先前未完成数据块的总大小和2）目标的路径MTU中的较小者。此上限可防止[99]中概述的ACK分裂攻击。
---------
Old text: (Section 14)
---------
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. 建议的SCTP协议参数值
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. 建议的SCTP协议参数值
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
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
The above changes strengthen the rules and make it much more apparent as to the need to block cwnd growth when the full cwnd is not being utilized. The changes also apply cwnd degradation without introducing the need for complex special case code.
上述变化强化了规则，并使其更加明显，即在未使用全部cwnd时，需要阻止cwnd增长。这些变化也适用于cwnd降级，而不需要引入复杂的特殊情况代码。
When a receiver clamps its rwnd to 0 to flow control the peer, the specification implies that one must continue to accept data from the remote peer. This is incorrect and needs clarification.
当接收器将其rwnd钳制为0以流控制对等方时，该规范意味着必须继续接受来自远程对等方的数据。这是不正确的，需要澄清。
---------
Old text: (Section 6.2)
---------
---------
Old text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the receipt of each valid DATA chunk.
SCTP端点必须始终确认收到每个有效数据块。
---------
New text: (Section 6.2)
---------
---------
New text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window.
当接收到的数据块在其接收窗口内时，SCTP端点必须始终确认每个有效数据块的接收。
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122.
当接收器的播发窗口为0时，接收器必须丢弃TSN大于迄今为止接收到的最大TSN的任何新传入数据块。如果新的传入数据块持有的TSN值小于迄今为止接收到的最大TSN，则接收方应丢弃为重新排序而持有的最大TSN，并接受新的传入数据块。在任何一种情况下，如果这样的数据块被丢弃，接收方必须立即发送回SACK，当前接收窗口仅显示到目前为止接收和接受的数据块。丢弃的数据块不能包含在SACK中，因为它们不被接受。如RFC 813中所述，接收器还必须具有用于广告其接收窗口的算法，以避免接收器傻窗口综合症（SWS）。该算法可以类似于RFC 1122第4.2.3.3节中描述的算法。
---------
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 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变化。
---------
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 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A） 在任何给定时间，如果对等方的rwnd指示该对等方没有缓冲区空间（即rwnd为0；请参阅第6.2.1节），则数据发送方不得向任何目标传输地址传输新数据。但是，无论rwnd的值是多少（包括如果它是0），如果cwnd允许，数据发送方可以始终将一个数据块传送到接收方（请参见下面的规则B）。此规则允许发送方探测由于SACK在从数据接收方到数据发送方的传输过程中丢失而导致发送方错过的rwnd变化。
When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
当接收器的播发窗口为零时，此探测称为零窗口探测。请注意，只有当所有未完成的数据块都已累计确认且没有数据块在飞行时，才应发送零窗口探测。必须支持零窗口探测。
If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address.This is because the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window. The sender SHOULD send the first zero window probe after 1 RTO when it detects that the receiver has closed its window and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero window probing does not affect the calculation of cwnd.
如果发送方在执行零窗口探测时继续从接收方接收新数据包，则未确认的窗口探测不应增加关联或任何目标传输地址的错误计数器。这是因为接收方可能会无限期地关闭其窗口。请参阅第6.2节，了解接收器在播发零窗口时的行为。当发送方检测到接收方已关闭其窗口时，发送方应在1 RTO后发送第一个零窗口探测，并应在其后以指数方式增加探测间隔。还应注意，cwnd应根据第7.2.1节进行调整。零窗探测不影响cwnd的计算。
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.4 of RFC 1122.
发送方还必须具有发送新数据块的算法，以避免RFC 813中所述的愚蠢窗口综合症（SWS）。该算法可以类似于RFC 1122第4.2.3.4节中描述的算法。
The above allows a receiver to drop new data that arrives and yet still requires the receiver to send a SACK showing the conditions unchanged (with the possible exception of a new a_rwnd) and the dropped chunk as missing. This will allow the association to continue until the rwnd condition clears.
上述情况允许接收方丢弃到达的新数据，但仍要求接收方发送SACK，显示条件不变（新的a_rwnd可能除外），且丢弃的数据块丢失。这将允许关联继续，直到rwnd条件清除为止。
The current wording of the Fragmentation and Reassembly forces an implementation that supports fragmentation to always fragment. This prohibits an implementation from offering its users an option to disable sends that exceed the SCTP fragmentation point.
碎片和重组的当前措辞迫使支持碎片的实现总是碎片化。这禁止实现向用户提供禁用超过SCTP分段点的发送的选项。
The restriction in RFC 2960 [5], Section 6.9, was never meant to restrict an implementations API from this behavior.
RFC 2960[5]第6.9节中的限制从来都不是为了限制实现API的这种行为。
---------
Old text: (Section 6.1)
---------
---------
Old text: (Section 6.1)
---------
6.9 Fragmentation and Reassembly
6.9 分裂与重组
An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message.
端点在发送数据块时可能支持分段，但在接收数据块时必须支持重新组装。如果端点支持分段，则如果要发送的用户消息的大小导致出站SCTP数据包大小超过当前MTU，则必须对用户消息进行分段。如果实现不支持出站用户消息的分段，则端点必须向其上层返回错误，并且不尝试发送用户消息。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
实现说明：在这种错误情况下，第10.1节中讨论的Send原语需要向上层返回一个错误。
---------
New text: (Section 6.1)
---------
---------
New text: (Section 6.1)
---------
6.9. Fragmentation and Reassembly
6.9. 分裂与重组
An endpoint MAY support fragmentation when sending DATA chunks, but it MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint MUST return an error to its upper layer and not attempt to send the user message.
端点在发送数据块时可能支持分段，但在接收数据块时必须支持重新组装。如果端点支持分段，则如果要发送的用户消息的大小导致出站SCTP数据包大小超过当前MTU，则必须对用户消息进行分段。如果实现不支持出站用户消息的分段，则端点必须向其上层返回错误，并且不尝试发送用户消息。
Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current P-MTU.
注意：如果支持分段的实现为其上层提供了一种关闭分段的机制，则可以这样做。但是，在这样做时，它必须像不支持分段的实现一样做出反应，即它必须拒绝超过当前P-MTU的发送。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
实现说明：在这种错误情况下，第10.1节中讨论的Send原语需要向上层返回一个错误。
The above wording will allow an implementation to offer the option of rejecting sends that exceed the P-MTU size even when the implementation supports fragmentation.
上述措辞将允许实现提供拒绝超过P-MTU大小的发送的选项，即使实现支持分段。
The current description of the SACK chunk within the RFC does not clearly state the value that would be put within a SACK when no DATA chunk has been received.
RFC中SACK块的当前描述没有明确说明在未收到数据块时将放入SACK中的值。
---------
Old text: (Section 3.3.4)
---------
---------
Old text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累积TSN确认：32位（无符号整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap.
此参数包含间隔之前按顺序接收的最后一个数据块的TSN。
---------
New text: (Section 3.3.4)
---------
---------
New text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累积TSN确认：32位（无符号整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one.
此参数包含间隔之前按顺序接收的最后一个数据块的TSN。在没有接收到数据块的情况下，该值设置为对等方的初始TSN减去1。
This change clearly states what the initial value will be for a SACK sender.
此更改清楚地说明了SACK发送者的初始值。
The current description on handling address parameters contained within the INIT and INIT-ACK does not fully describe a requirement for their handling.
当前对INIT和INIT-ACK中包含的处理地址参数的描述没有完全描述对其处理的要求。
---------
Old text: (Section 5.1.2)
---------
---------
Old text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C） 如果在接收到的INIT或INIT ACK区块中仅存在IPv4/IPv6地址，则接收方应从接收区块和发送INIT或INIT ACK的源IP地址派生并记录所有传输地址。传输地址由SCTP源端口（来自公共报头）和初始或初始确认块中携带的IP地址参数以及IP数据报的源IP地址组合而成。当向其对等方发送后续数据包时，接收方应仅使用这些传输地址作为目标传输地址。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver MUST derive and record all the transport addresses from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport addresses are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C） 如果接收的INIT或INIT ACK区块中仅存在IPv4/IPv6地址，则接收方必须从接收的区块和发送INIT或INIT ACK的源IP地址派生并记录所有传输地址。传输地址由SCTP源端口（来自公共报头）和INIT或INIT ACK块中携带的IP地址参数以及IP数据报的源IP地址组合而成。当向其对等方发送后续数据包时，接收方应仅使用这些传输地址作为目标传输地址。
D) An INIT or INIT ACK chunk MUST be treated as belonging to an already established association (or one in the process of being established) if the use of any of the valid address parameters contained within the chunk would identify an existing TCB.
D） 如果使用块中包含的任何有效地址参数将标识现有TCB，则必须将INIT或INIT ACK块视为属于已建立的关联（或正在建立的关联）。
This new text clearly specifies to an implementor the need to look within the INIT or INIT ACK. Any implementation that does not do this may (for example) not be able to recognize an INIT chunk coming from an already established association that adds new addresses (see Section 2.6) or an incoming INIT ACK chunk sent from a source address different from the destination address used to send the INIT chunk.
这个新的文本向实现者明确指定了查看INIT或INIT ACK的需要。任何不这样做的实现可能（例如）无法识别来自添加新地址（参见第2.6节）的已建立关联的INIT块或从不同于用于发送INIT块的目标地址的源地址发送的传入INIT ACK块。
The current wording in the RFC places the choice of sending an ABORT upon the SCTP stack when a stream shortage occurs. This decision should really be made by the upper layer, not the SCTP stack.
RFC中的当前措辞将在出现流短缺时选择在SCTP堆栈上发送中止。这个决定实际上应该由上层做出，而不是由SCTP堆栈做出。
---------
Old text:
---------
---------
Old text:
---------
5.1.1 Handle Stream Parameters
5.1.1 处理流参数
In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
在INIT和INIT ACK块中，块的发送方应指示其希望在关联中拥有的出站流（OS）的数量，以及它将从另一个端点接受的最大入站流（MIS）。
After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer.
在从另一方接收到流配置信息后，每个端点应执行以下检查：如果对等方的MIS小于端点的OS，这意味着对等方无法支持端点想要配置的所有出站流，则端点必须使用MIS出站流，或者中止关联，并向其上层报告对等方的资源短缺。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
5.1.1. Handle Stream Parameters
5.1.1. 处理流参数
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
在INIT和INIT ACK块中，块的发送方必须指明它希望在关联中拥有的出站流（OS）的数量，以及它将从另一个端点接受的最大入站流（MIS）。
After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
在接收到来自另一方的流配置信息后，每个端点必须执行以下检查：如果对等方的MIS小于端点的OS，这意味着对等方无法支持端点想要配置的所有出站流，端点必须使用MIS出站流，并且可以向上层报告任何不足。如果资源短缺是不可接受的，上层可以选择中止关联。
The above changes take the decision to ABORT out of the realm of the SCTP stack and place it into the user's hands.
上述更改决定中止SCTP堆栈，并将其交给用户。
The current RFC does not provide any guidance on the assignment of TSN sequence numbers to outbound messages nor reception of these messages. This could lead to a possible indefinite postponement.
当前的RFC未提供任何关于向出站消息分配TSN序列号或接收这些消息的指导。这可能导致无限期推迟。
---------
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。
6.2 Acknowledgement on Reception of DATA Chunks
6.2 接收数据块时的确认
---------
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.
注意：数据发送方不应使用比当前发送窗口的起始TSN高出2**31-1的TSN。
The algorithm by which an implementation assigns sequential TSNs to messages on a particular association MUST ensure that no user message that has been accepted by SCTP is indefinitely postponed from being assigned a TSN. Acceptable algorithms for assigning TSNs include
实现为特定关联上的消息分配顺序TSN的算法必须确保SCTP已接受的用户消息不会无限期推迟分配TSN。可接受的TSN分配算法包括
(a) assigning TSNs in round-robin order over all streams with pending data; and
(a) 在具有挂起数据的所有流上以循环顺序分配TSN；和
(b) preserving the linear order in which the user messages were submitted to the SCTP association.
(b) 保留用户消息提交给SCTP关联的线性顺序。
When an upper layer requests to read data on an SCTP association, the SCTP receiver SHOULD choose the message with the lowest TSN from among all deliverable messages. In SCTP implementations that allow a user to request data on a specific stream, this operation SHOULD NOT block if data is not available, since this can lead to a deadlock under certain conditions.
当上层请求读取SCTP关联上的数据时，SCTP接收器应从所有可交付消息中选择TSN最低的消息。在允许用户请求特定流上的数据的SCTP实现中，如果数据不可用，此操作不应阻止，因为在某些情况下，这可能导致死锁。
6.2. Acknowledgement on Receipt of DATA Chunks
6.2. 收到数据块时的确认
The above wording clarifies how TSNs SHOULD be assigned by the sender.
上述措辞澄清了发送方应如何分配TSN。
It is not possible for an upper layer to abort the association and provide the peer with an indication of why the association is aborted.
上层不可能中止关联并向对等方提供关联中止原因的指示。
Some of the changes given here already include changes suggested in Section 2.6 of this document.
此处给出的一些变更已经包括本文件第2.6节中建议的变更。
---------
Old text: (Section 3.3.10)
---------
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
“原因”字段，包括“原因代码”的“原因长度”参数设置
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.10节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Section 3.3.10)
---------
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User-Initiated Abort
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User-Initiated Abort
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
“原因”字段，包括“原因代码”的“原因长度”参数设置
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.12节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Note: no old text, new error added in Section 3.3.10)
---------
---------
New text: (Note: no old text, new error added in Section 3.3.10)
---------
3.3.10.12. User-Initiated Abort (12)
3.3.10.12. 用户启动的中止（12）
Cause of error
--------------
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because of an upper layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper layer protocol at the peer.
此错误原因可能包含在由于上层请求而发送的中止块中。上层可以指定上层中止原因，该原因由SCTP透明地传输，并且可以在对等端传递给上层协议。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 9.1)
---------
---------
Old text: (Section 9.1)
---------
9.1 Abort of an Association
9.1 中止联合
When an endpoint decides to abort an existing association, it shall send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT.
当端点决定中止现有关联时，它应向其对等端点发送中止块。发送方必须在出站数据包中填写对等方的验证标签，并且不得将任何数据块与中止捆绑在一起。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
端点不得响应包含中止块的任何接收数据包（另请参见第8.4节）。
An endpoint receiving an ABORT shall apply the special Verification Tag check rules described in Section 8.5.1.
接收中止的端点应采用第8.5.1节所述的特殊验证标签检查规则。
After checking the Verification Tag, the receiving endpoint shall remove the association from its record and shall report the termination to its upper layer.
检查验证标签后，接收端点应从其记录中删除关联，并向其上层报告终止情况。
---------
New text: (Section 9.1)
---------
---------
New text: (Section 9.1)
---------
9.1. Abort of an Association
9.1. 中止联合
When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
当端点决定中止现有关联时，它必须向其对等端点发送中止块。发送方必须在出站数据包中填写对等方的验证标签，并且不得将任何数据块与中止捆绑在一起。如果在上层请求时中止关联，则中止区块中应存在用户发起的中止错误原因（见3.3.10.12）。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
端点不得响应包含中止块的任何接收数据包（另请参见第8.4节）。
An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1.
接收中止的端点必须应用第8.5.1节中描述的特殊验证标签检查规则。
After checking the Verification Tag, the receiving endpoint MUST
检查验证标记后，接收端点必须
remove the association from its record and SHOULD report the termination to its upper layer. If a User-Initiated Abort error cause is present in the ABORT chunk, the Upper Layer Abort Reason SHOULD be made available to the upper layer.
从其记录中删除关联，并应向其上层报告终止。如果中止区块中存在用户发起的中止错误原因，则上层中止原因应可供上层使用。
---------
Old text: (Section 10.1)
---------
---------
Old text: (Section 10.1)
---------
D) Abort
D） 流产
Format: ABORT(association id [, cause code]) -> result
格式：中止（关联id[，原因代码]）->结果
Ungracefully closes an association. Any locally queued user data will be discarded and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned.
笨拙地关闭一个协会。任何本地排队的用户数据都将被丢弃，并向对等方发送一个中止块。成功终止关联时将返回成功代码。如果试图中止关联导致失败，则应返回错误代码。
Mandatory attributes:
强制性属性：
o association id - local handle to the SCTP association
o 关联id-SCTP关联的本地句柄
Optional attributes:
可选属性：
o cause code - reason of the abort to be passed to the peer.
o 原因代码-将中止传递给对等方的原因。
---------
New text: (Section 10.1)
---------
---------
New text: (Section 10.1)
---------
D) Abort
D） 流产
Format: ABORT(association id [, Upper Layer Abort Reason]) -> result
格式：中止（关联id[，上层中止原因]->结果
Ungracefully closes an association. Any locally queued user data will be discarded, and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned.
笨拙地关闭一个协会。任何本地排队的用户数据都将被丢弃，并向对等方发送一个中止块。成功终止关联时将返回成功代码。如果试图中止关联导致失败，则应返回错误代码。
Mandatory attributes:
强制性属性：
o association id - Local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
Optional attributes:
可选属性：
o Upper Layer Abort Reason - Reason of the abort to be passed to the peer.
o 上层中止原因-要传递给对等方的中止原因。
None.
没有一个
---------
Old text: (Section 10.2)
---------
---------
Old text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
E） 通信丢失通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
当SCTP完全失去与端点的通信（例如，通过心跳）或检测到端点已执行中止操作时，它应在ULP上调用此通知。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - local handle to the SCTP association
o 关联id-SCTP关联的本地句柄
o status - This indicates what type of event has occurred; The status may indicate a failure OR a normal termination event occurred in response to a shutdown or abort request.
o 状态-指示发生了什么类型的事件；该状态可能表示在响应关机或中止请求时发生了故障或正常终止事件。
The following may be passed with the notification:
以下内容可随通知一起传递：
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o 数据检索id—用于检索未发送和未确认数据的标识。
o last-acked - the TSN last acked by that peer endpoint;
o last acked—该对等端点上次确认的TSN；
o last-sent - the TSN last sent to that peer endpoint;
o last sent—上次发送到该对等端点的TSN；
---------
New text: (Section 10.2)
---------
---------
New text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
E） 通信丢失通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
当SCTP完全失去与端点的通信（例如，通过心跳）或检测到端点已执行中止操作时，它应在ULP上调用此通知。
The following shall be passed with the notification:
以下内容应随通知一起通过：
o association id - Local handle to the SCTP association.
o association id—SCTP关联的本地句柄。
o status - This indicates what type of event has occurred; The status may indicate that a failure OR a normal termination event occurred in response to a shutdown or abort request.
o 状态-指示发生了什么类型的事件；该状态可能表示在响应关机或中止请求时发生了故障或正常终止事件。
The following may be passed with the notification:
以下内容可随通知一起传递：
o data retrieval id - An identification used to retrieve unsent and unacknowledged data.
o 数据检索id—用于检索未发送和未确认数据的标识。
o last-acked - The TSN last acked by that peer endpoint.
o last acked—该对等端点上次确认的TSN。
o last-sent - The TSN last sent to that peer endpoint.
o 发送到最后一个端点的TSN。
o Upper Layer Abort Reason - The abort reason specified in case of a user-initiated abort.
o 上层中止原因-用户发起中止时指定的中止原因。
The above allows an upper layer to provide its peer with an indication of why the association was aborted. Therefore, an addition error cause was introduced.
以上允许上层向其对等方提供关联中止原因的指示。因此，引入了一个加法错误原因。
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate Tag set to zero handles this as an error and sends back an ABORT. But the sender of the INIT-ACK normally has no TCB, and thus the ABORT is useless.
RFC 2960要求Initiate标记设置为零的INIT-ACK接收器将此作为错误处理，并发送回中止。但是INIT-ACK的发送方通常没有TCB，因此中止是无用的。
---------
Old text: (Section 3.3.3)
---------
---------
Old text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
初始化标记：32位（无符号整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACK的接收器记录Initiate标记参数的值。必须将该值放入INIT ACK接收器在此关联内发送的每个SCTP数据包的验证标签字段中。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
Initiate标记不能采用值0。有关初始标签值选择的更多信息，请参见第5.3.1节。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT.
如果在接收的INIT ACK块中发现Initiate标记的值为0，则接收方必须将其视为错误，并通过发送中止来关闭关联。
---------
New text: (Section 3.3.3)
---------
---------
New text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
初始化标记：32位（无符号整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACK的接收器记录Initiate标记参数的值。必须将该值放入INIT ACK接收器在此关联内发送的每个SCTP数据包的验证标签字段中。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
Initiate标记不能采用值0。有关初始标签值选择的更多信息，请参见第5.3.1节。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose.
如果在接收到的INIT ACK块中发现Initiate标记的值为0，则接收方必须销毁关联，丢弃其TCB。接收机可能会出于调试目的发送中止。
The new text does not require that the receiver of the invalid INIT-ACK send the ABORT. This behavior is in tune with the error case of invalid stream numbers in the INIT-ACK. However, sending an ABORT for debugging purposes is allowed.
新文本不要求无效INIT-ACK的接收方发送中止。此行为与INIT-ACK中无效流号的错误情况一致。但是，允许出于调试目的发送中止。
Whenever the receiver of an INIT chunk has to send an ABORT chunk in response, for whatever reason, it is not stated clearly which Verification Tag and value of the T-bit should be used.
无论出于何种原因，每当INIT块的接收方必须发送一个ABORT块作为响应时，都没有明确说明应该使用哪个验证标记和T位的值。
---------
Old text: (Section 8.4)
---------
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise,
3) 如果数据包包含验证标记设置为“0”的INIT块，请按照第5.1节中的说明进行处理。否则
---------
New text: (Section 8.4)
---------
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate tag of the received INIT chunk, and the T-Bit of the ABORT chunk has to be set to 0, indicating that a TCB was destroyed. Otherwise,
3) 如果数据包包含验证标记设置为“0”的INIT块，请按照第5.1节中的说明进行处理。如果出于任何原因，无法正常处理INIT，并且必须发送中止响应，则包含中止块的数据包的验证标记必须是接收到的INIT块的inite标记，并且中止块的T位必须设置为0，表示TCB已被破坏。否则
The new text stated clearly which value of the Verification Tag and T-bit have to be used.
新文本明确说明了必须使用验证标签和T位的哪个值。
RFC 2960 does not describe the fact that the SSN has to be initialized to 0, as required by RFC 2119.
RFC 2960没有描述必须按照RFC 2119的要求将SSN初始化为0的事实。
---------
Old text: (Section 6.5)
---------
---------
Old text: (Section 6.5)
---------
The stream sequence number in all the streams shall start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number shall be set to 0.
当建立关联时，所有流中的流序列号应从0开始。此外，当流序列号达到值65535时，下一个流序列号应设置为0。
---------
New text: (Section 6.5)
---------
---------
New text: (Section 6.5)
---------
The stream sequence number in all the streams MUST start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number MUST be set to 0.
建立关联时，所有流中的流序列号必须从0开始。此外，当流序列号达到值65535时，下一个流序列号必须设置为0。
The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior.
文本中的“应”替换为“必须”，以明确说明所需的行为。
It is not clear in RFC 2960 whether a SACK must contain the fields Number of Gap Ack Blocks and Number of Duplicate TSNs.
RFC 2960中不清楚SACK是否必须包含Gap Ack块数和重复TSN数字段。
---------
Old text: (Section 3.3.4)
---------
---------
Old text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters.
SACK必须包含累积TSN Ack和播发的接收方窗口信用（a_rwnd）参数。
---------
New text: (Section 3.3.4)
---------
---------
New text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields.
SACK必须包含累积TSN Ack、公布的接收器窗口信用（a_rwnd）、间隙Ack块的数量和重复TSN字段的数量。
The text has been modified. It is now clear that a SACK always contains the fields Number of Gap Ack Blocks and Number of Duplicate TSNs.
文本已被修改。现在很清楚，SACK始终包含Gap Ack块数和重复TSN数字段。
There are many situations where an SCTP endpoint may detect that its peer violates the protocol. The result of such detection often results in the association being destroyed by the sending of an ABORT. Currently, there are only some error causes that could be used to indicate the reason for the abort, but these do not cover all cases.
在许多情况下，SCTP端点可能会检测到其对等方违反协议。这种检测的结果通常会导致通过发送中止来破坏关联。目前，只有一些错误原因可用于指示中止的原因，但这些原因并不涵盖所有情况。
Some of the changes given here already include changes suggested in Section 2.6 and 2.21 of this document.
此处给出的一些变更已经包括本文件第2.6节和第2.21节中建议的变更。
---------
Old text: (Section 3.3.10)
---------
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
“原因”字段，包括“原因代码”的“原因长度”参数设置
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.10节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Section 3.3.10)
---------
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
原因长度：16位（无符号整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
“原因”字段，包括“原因代码”的“原因长度”参数设置
Cause-specific Information: variable length
原因特定信息：可变长度
This field carries the details of the error condition.
此字段包含错误条件的详细信息。
Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
第3.3.10.1-3.3.10.13节定义了SCTP的错误原因。IETF定义新错误原因值的指南见第13.3节。
---------
New text: (Note: no old text; new error added in section 3.3.10)
---------
---------
New text: (Note: no old text; new error added in section 3.3.10)
---------
3.3.10.13. Protocol Violation (13)
3.3.10.13. 违反协议（13）
Cause of error
--------------
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in 3.3.10.1 to 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected.
此错误原因可能包含在发送的中止块中，因为SCTP端点检测到对等方的协议违反，而这不在3.3.10.1至3.3.10.12中所述的错误原因中。实现可以提供额外的信息，指定检测到哪种协议违反。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An additional error cause has been defined that can be used by an endpoint to indicate a protocol violation of the peer.
已经定义了一个额外的错误原因，端点可以使用它来指示对等方的协议冲突。
It is not stated clearly in RFC 2960 [5] how unrecognized parameters should be reported. Unrecognized parameters in an INIT chunk could be reported in the INIT-ACK chunk or in a separate ERROR chunk, which can get lost. Unrecognized parameters in an INIT-ACK chunk have to be reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR chunk or sent separately. If it is sent separately and received before the COOKIE-ECHO, it will be handled as an OOTB packet, resulting in sending out an ABORT chunk. Therefore, the association would not be established.
RFC 2960[5]中没有明确说明如何报告未识别的参数。INIT块中无法识别的参数可能会在INIT-ACK块或单独的错误块中报告，这可能会丢失。必须在错误块中报告INIT-ACK块中无法识别的参数。这可以与COOKIE-ERROR块捆绑在一起，也可以单独发送。如果在COOKIE-ECHO之前单独发送和接收，它将作为OOTB数据包处理，从而发送一个中止块。因此，该协会不会成立。
Some of the changes given here already include changes suggested in Section 2.2 of this document.
此处给出的一些变更已经包括本文件第2.2节中建议的变更。
---------
Old text: (Section 3.2.1)
---------
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-跳过此参数并继续处理，但在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
---------
New text: (Section 3.2.1)
---------
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it; do not process any further parameters within this chunk.
00-停止处理此SCTP块并丢弃它；不要在此块中处理任何其他参数。
01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
01-停止处理此SCTP区块并放弃它，不处理此区块内的任何其他参数，并以“未识别的参数类型”报告未识别的参数，如3.2.2所述。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
11-跳过此参数并继续处理，但以“未识别的参数类型”报告未识别的参数，如3.2.2所述。
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 报告无法识别的参数
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), then no report would be sent back.
如果INIT块的接收方检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，则必须将“无法识别的参数”参数放入响应INIT块而发送的INIT-ACK块中。请注意，如果INIT块的接收者不打算建立关联（例如，由于缺乏资源），则不会返回任何报告。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
如果INIT-ACK数据块的接收者检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，那么它应该将包含“无法识别的参数”错误原因的错误数据块与响应INIT-ACK数据块而发送的COOKIE-ECHO数据块捆绑在一起。如果INIT-ACK的接收器无法将COOKIE-ECHO块与错误块捆绑在一起，则可以单独发送错误块，但不能在收到COOKIE-ACK之前发送。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注意：任何时候在数据包中发送COOKIE-ECHO时，它必须是第一个数据块。
The procedure of reporting unrecognized parameters has been described clearly.
报告未识别参数的程序已明确说明。
It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that supports either IPv4 addresses or IPv6 addresses should respond if IPv4 and IPv6 addresses are presented by the peer in the INIT or INIT-ACK chunk.
RFC 2960[5]中没有明确说明，如果对等方在INIT或INIT-ACK块中提供IPv4和IPv6地址，则支持IPv4地址或IPv6地址的SCTP端点应如何响应。
---------
Old text: (Section 5.1.2)
---------
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新启动，以指示其首选的地址类型。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新启动，以指示其首选的地址类型。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
实施说明：如果仅支持IPv4或IPv6的SCTP终结点从其对等方接收到INIT或INIT-ACK块中的IPv4和IPv6地址，则它必须使用属于支持的地址系列的所有地址。其他地址可能会被忽略。端点不应响应任何类型的错误指示。
The procedure of handling IP address parameters has been described clearly.
已经清楚地描述了处理IP地址参数的过程。
The description of the behavior in RFC 2960 [5] when a COOKIE ECHO chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is received, a TCB exists and the local tag and peer's tag match, it is stated that the endpoint should enter the ESTABLISHED state if it has not already done so and send a COOKIE ACK. It was not clear that, in the case the endpoint has already left the ESTABLISHED state again, then it should not go back to established. In case D, the endpoint can only enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing about the peer's tag, which is requested to match in this case.
RFC 2960[5]中对COOKIE回显块和TCB存在时的行为的描述可能会被误解。当接收到COOKIE回音时，TCB存在，并且本地标记和对等方的标记匹配，说明端点应进入已建立状态（如果尚未进入该状态），并发送COOKIE ACK。不清楚的是，如果端点已再次离开已建立状态，则不应返回已建立状态。在案例D中，端点只能进入从COOKIE-Echored建立的状态，因为在状态CLOSED中，它没有TCB，而在状态COOKIE-WAIT中，它有TCB，但对对等方的标记一无所知，在本例中，该标记被请求匹配。
---------
Old text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should
always enter the ESTABLISHED state, if it has not already
done so. It should stop any init or cookie timers that may
be running and send a COOKIE ACK.
---------
Old text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should
always enter the ESTABLISHED state, if it has not already
done so. It should stop any init or cookie timers that may
be running and send a COOKIE ACK.
---------
New text: (Section 5.2.4)
---------
D) When both local and remote tags match, the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
state. It should stop any cookie timer that may
be running and send a COOKIE ACK.
---------
New text: (Section 5.2.4)
---------
D) When both local and remote tags match, the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
state. It should stop any cookie timer that may
be running and send a COOKIE ACK.
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly.
当TCB存在时，COOKIE-ECHO块的处理过程已经清楚地描述。
RFC 2960 was published with the intention of having the same congestion control properties as TCP. Since the publication of RFC 2960, TCP's initial congestion window size has been increased via RFC 3390. This same update will be needed for SCTP to keep SCTP's congestion control properties equivalent to that of TCP.
发布RFC 2960的目的是使其具有与TCP相同的拥塞控制特性。自RFC 2960发布以来，TCP的初始拥塞窗口大小已通过RFC 3390增加。SCTP也需要同样的更新，以保持SCTP的拥塞控制属性等同于TCP的拥塞控制属性。
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a
sufficiently long idle period MUST be <= 2*MTU.
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a
sufficiently long idle period MUST be <= 2*MTU.
---------
New 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)).
---------
New 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)).
---------
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, 2*MTU) per RTO.
---------
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, 2*MTU) per RTO.
---------
New 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.
---------
New 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.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.3)
---------
---------
Old text: (Section 7.2.3)
---------
7.2.3. Congestion Control
7.2.3. 拥塞控制
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following:
在检测到来自SACK的数据包丢失时（参见第7.2.4节），端点应执行以下操作：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by
当T3 rtx计时器在某个地址上过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
---------
New text: (Section 7.2.3)
---------
7.2.3 Congestion Control
7.2.3 拥塞控制
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
在检测到来自SACK的数据包丢失时（参见第7.2.4节），端点应执行以下操作：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本上，数据包丢失会导致cwnd减半。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
当T3 rtx计时器在某个地址过期时，SCTP应通过以下方式执行慢速启动：
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
The change to SCTP's initial congestion window will allow it to continue to maintain the same congestion control properties as TCP.
更改SCTP的初始拥塞窗口将允许它继续保持与TCP相同的拥塞控制属性。
In Section 2.24 of this document, it is clarified that the SSN are initialized with 0. Two figures in RFC 2960 [5] illustrate that they start with 1.
在本文件第2.24节中，明确SSN初始化为0。RFC 2960[5]中的两个数字说明它们以1开头。
---------
Old text: (Section 7.2.1)
---------
---------
Old text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <-----/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, / ---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <-----/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, / ---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
图4：初始化示例
---------
New text: (Section 7.2.1)
---------
---------
New text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
图4：初始化示例
---------
Old text: (Section 5.2.4.1)
---------
---------
Old text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<------------ Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Endpoint A Endpoint Z
<------------ Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
图5：重启示例
---------
New text: (Section 5.2.4.1)
---------
---------
New text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
图5：重启示例
Figure 4 and 5 were changed so that the SSN starts with 0 instead of 1.
图4和图5已更改，因此SSN从0开始，而不是从1开始。
The RFC does not state clearly in Section 3.3.3.1 whether one or multiple unrecognized parameters are included in the 'Unrecognized Parameter' parameter.
RFC未在第3.3.3.1节中明确说明“Unrecogned Parameter”（未识别参数）参数中是否包含一个或多个未识别参数。
---------
Old text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
Old text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
New text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
New text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
Parameter Type Value: 8
参数类型值：8
Parameter Length: Variable Size.
参数长度：可变大小。
Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length and Value fields.
参数值：当INIT包含一个无法识别的参数时，该参数将返回给INIT块的发起人，该参数的值指示应将其报告给发送者。此参数值字段将包含从INIT块复制的无法识别的参数，包括参数类型、长度和值字段。
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
Parameter Type Value: 8
参数类型值：8
Parameter Length: Variable Size.
参数长度：可变大小。
Parameter Value:
参数值：
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates that it should be reported to the sender. This parameter value field will contain the unrecognized parameter copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
当INIT包含一个无法识别的参数，该参数的值指示应该向发送方报告时，该参数将返回给INIT块的发起方。此参数值字段将包含从INIT块复制的无法识别的参数，包括参数类型、长度和值字段。
The new text states clearly that only one unrecognized parameter is reported per parameter.
新文本明确指出，每个参数只报告一个无法识别的参数。
It is not stated clearly in RFC 2960 [5] how unrecognized parameters should be handled. The problem comes up when an INIT contains an unrecognized parameter with highest bits 00. It was not clear whether an INIT-ACK should be sent.
RFC 2960[5]中没有明确说明如何处理未识别的参数。当INIT包含最高位为00的无法识别的参数时，就会出现问题。不清楚是否应发送INIT-ACK。
Some of the changes given here already include changes suggested in Section 2.27 of this document.
此处给出的一些变更已经包括本文件第2.27节中建议的变更。
---------
Old text: (Section 3.2.1)
---------
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-跳过此参数并继续处理，但在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
---------
New text: (Section 3.2.1)
---------
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00-停止处理该参数；不要在此块中处理任何其他参数。
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
01-停止处理此参数，不处理此区块内的任何其他参数，并以“未识别的参数类型”报告未识别的参数，如3.2.2所述。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
11-跳过此参数并继续处理，但以“未识别的参数类型”报告未识别的参数，如3.2.2所述。
---------
New text: (Note: no old text; clarification added in section 3.2)
---------
---------
New text: (Note: no old text; clarification added in section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 报告无法识别的参数
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of
如果INIT块的接收方检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，则必须将“无法识别的参数”参数放入响应INIT块而发送的INIT-ACK块中。注意，如果INIT块的接收者不打算建立关联（例如，由于缺少
resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
“无法识别的参数”将不会包含在发送给INIT发送方的任何中止中。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
如果INIT-ACK数据块的接收者检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，那么它应该将包含“无法识别的参数”错误原因的错误数据块与响应INIT-ACK数据块而发送的COOKIE-ECHO数据块捆绑在一起。如果INIT-ACK的接收器无法将COOKIE-ECHO块与错误块捆绑在一起，则可以单独发送错误块，但不能在收到COOKIE-ACK之前发送。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注意：任何时候在数据包中发送COOKIE-ECHO时，它必须是第一个数据块。
The procedure of handling unrecognized parameters has been described clearly.
处理未识别参数的过程已清楚描述。
RFC 2960 requires that Tie-Tags be included in the COOKIE. The cookie may not be encrypted. An attacker could discover the value of the Verification Tags by analyzing cookies received after sending an INIT.
RFC 2960要求在COOKIE中包含领带标签。cookie可能未加密。攻击者可以通过分析发送INIT后收到的cookie来发现验证标记的值。
---------
Old text: (Section 1.4)
---------
o Tie-Tags: Verification Tags from a previous association. These
Tags are used within a State Cookie so that the newly
restarting association can be linked to the original
association within the endpoint that did not restart.
---------
Old text: (Section 1.4)
---------
o Tie-Tags: Verification Tags from a previous association. These
Tags are used within a State Cookie so that the newly
restarting association can be linked to the original
association within the endpoint that did not restart.
---------
New text: (Section 1.4)
---------
---------
New text: (Section 1.4)
---------
o Tie-Tags: Two 32-bit random numbers that together make a 64- bit nonce. These Tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association.
o Tie Tags：两个32位随机数组合成一个64位nonce。这些标记在状态Cookie和TCB中使用，以便新重新启动的关联可以链接到端点中未重新启动但未显示现有关联的真实验证标记的原始关联。
---------
Old text: (Section 5.2.1)
---------
---------
Old text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags with the Tag information of itself and its peer (see Section 5.2.2 for a description of the Tie-Tags).
对于处于COOKIE-echood状态的端点，它必须使用自身及其对等方的标记信息填充其Tie标记（有关Tie标记的说明，请参见第5.2.2节）。
---------
New text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags within both the association TCB and
inside the State Cookie (see section 5.2.2 for a description
of the Tie-Tags).
---------
New text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags within both the association TCB and
inside the State Cookie (see section 5.2.2 for a description
of the Tie-Tags).
---------
Old text: (Section 5.2.2)
---------
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a
reserved place within the state cookie. We shall refer to these
locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The
outbound SCTP packet containing this INIT ACK MUST carry a
Verification Tag value equal to the Initiation Tag found in the
unexpected INIT. And the INIT ACK MUST contain a new Initiation
Tag (randomly generated see Section 5.3.1). Other parameters
for the endpoint SHOULD be copied from the existing parameters
of the association (e.g., number of outbound streams) into the
INIT ACK and cookie.
---------
Old text: (Section 5.2.2)
---------
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a
reserved place within the state cookie. We shall refer to these
locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The
outbound SCTP packet containing this INIT ACK MUST carry a
Verification Tag value equal to the Initiation Tag found in the
unexpected INIT. And the INIT ACK MUST contain a new Initiation
Tag (randomly generated see Section 5.3.1). Other parameters
for the endpoint SHOULD be copied from the existing parameters
of the association (e.g., number of outbound streams) into the
INIT ACK and cookie.
---------
New text: (Section 5.2.2)
---------
---------
New text: (Section 5.2.2)
---------
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint MUST generate an INIT ACK with a State Cookie. In the outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a reserved place within the State Cookie and the association's TCB. We shall refer to these locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy within an association's TCB as the Local Tag and Peer's Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a
除非另有说明，否则在收到此关联的意外INIT时，端点必须使用状态Cookie生成INIT ACK。在outbound INIT ACK中，端点必须将其当前的Tie标记复制到状态Cookie和关联的TCB中的保留位置。我们将把cookie中的这些位置称为Peer's-Tie-Tag和Local-Tie-Tag。我们将引用关联TCB中的副本作为本地标记和对等标记。包含此初始化确认的出站SCTP数据包必须携带与意外初始化中找到的初始化标记相等的验证标记值。并且INIT ACK必须包含
new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
新启动标签（随机生成；见第5.3.1节）。端点的其他参数应从关联的现有参数（例如，出站流的数量）复制到INIT ACK和cookie中。
The solution to this problem is not to use the real Verification Tags within the State Cookie as tie-tags. Instead, two 32-bit random numbers are created to form one 64-bit nonce and stored both in the State Cookie and the existing association TCB. This prevents exposing the Verification Tags inadvertently.
这个问题的解决方案是不使用状态Cookie中的实际验证标记作为tie标记。相反，创建两个32位随机数以形成一个64位nonce，并存储在状态Cookie和现有关联TCB中。这样可以防止无意中暴露验证标签。
The State Cookie sent by a listening SCTP endpoint may not contain the original port numbers or the local Verification Tag. It is then possible that the endpoint, on receipt of the COOKIE-ECHO, will not be able to verify that these values match the original values found in the INIT and INIT-ACK that began the association setup.
侦听SCTP端点发送的状态Cookie可能不包含原始端口号或本地验证标记。然后，端点在收到COOKIE-ECHO后可能无法验证这些值是否与启动关联设置的INIT和INIT-ACK中的原始值匹配。
---------
Old text: (Section 5.1.5)
---------
3) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded and the endpoint MUST transmit an ERROR
chunk with a "Stale Cookie" error cause to the peer endpoint,
---------
Old text: (Section 5.1.5)
---------
3) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded and the endpoint MUST transmit an ERROR
chunk with a "Stale Cookie" error cause to the peer endpoint,
4) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO, and enter the ESTABLISHED state,
4) 如果状态Cookie有效，则使用Cookie ECHO中携带的TCB数据中的信息创建与Cookie ECHO块发送方的关联，并输入已建立的状态，
5) Send a COOKIE ACK chunk to the peer acknowledging reception of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
5) 向对等方发送COOKIE ACK区块，确认接收到COOKIE回音。COOKIE ACK可以与出站数据块或SACK块捆绑；但是，COOKIE ACK必须是SCTP数据包中的第一个块。
6) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step
6) 立即用SACK确认与COOKIE ECHO捆绑的任何数据块（后续数据块确认应遵循第6.2节中定义的规则）。如步骤中所述
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
5） ，如果SACK与COOKIE ACK捆绑在一起，则COOKIE ACK必须首先出现在SCTP数据包中。
---------
New text: (Section 5.1.5)
---------
---------
New text: (Section 5.1.5)
---------
3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded.
3) 将COOKIE ECHO区块中包含的端口号和验证标记与接收数据包的SCTP公共头中的实际端口号和验证标记进行比较。如果这些值不匹配，则必须以静默方式丢弃数据包。
4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.
4) 将状态Cookie中的创建时间戳与当前本地时间进行比较。如果经过的时间长于状态Cookie中携带的寿命，则应丢弃该数据包，包括Cookie回显和任何附加的数据块，并且端点必须向对等端点传输带有“陈旧Cookie”错误原因的错误块。
5) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO and enter the ESTABLISHED state.
5) 如果状态Cookie有效，则使用Cookie ECHO中携带的TCB数据中的信息创建与Cookie ECHO块发送方的关联，并进入已建立状态。
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
6) 向对等方发送COOKIE ACK区块，确认收到COOKIE回音。COOKIE ACK可以与出站数据块或SACK块捆绑；但是，COOKIE ACK必须是SCTP数据包中的第一个块。
7) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step 5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
7) 立即用SACK确认与COOKIE ECHO捆绑的任何数据块（后续数据块确认应遵循第6.2节中定义的规则）。如步骤5所述，如果SACK与COOKIE ACK绑定，则COOKIE ACK必须首先出现在SCTP数据包中。
By including both port numbers and the local Verification Tag within the State Cookie and verifying these during COOKIE-ECHO processing, this issue is resolved.
通过在状态Cookie中包含端口号和本地验证标记，并在Cookie-ECHO处理期间验证这些标记，此问题得以解决。
When an association enters the ESTABLISHED state, the endpoint has no verification that all of the addresses presented by the peer do in fact belong to the peer. This could cause various forms of denial of service attacks.
当关联进入已建立状态时，端点无法验证对等方提供的所有地址是否确实属于该对等方。这可能导致各种形式的拒绝服务攻击。
---------
Old text: None
---------
---------
Old text: None
---------
---------
New text: (Section 5.4)
---------
5.4. Path Verification
---------
New text: (Section 5.4)
---------
5.4. Path Verification
During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association:
在建立关联期间，两个对等方交换地址列表。在大多数情况下，这些列表准确地表示每个对等方拥有的地址。然而，行为不端的对等方可能会提供它不拥有的地址。为防止出现这种情况，以下规则将应用于新关联的所有地址：
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1) 上层传递给INIT发送方的任何地址都会自动被视为已确认。
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is the one that the INIT-ACK was sent to.
2) 对于COOKIE-ECHO的接收方，唯一确认的地址是发送INIT-ACK的地址。
3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification.
3) 规则1和规则2未涵盖的所有其他地址均被视为未确认地址，需要进行调查以进行验证。
To probe an address for verification, an endpoint will send HEARTBEATs including a 64-bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter.
要探测用于验证的地址，端点将在HEARTBEAT参数内发送心跳，包括64位随机nonce和路径指示符（用于标识心跳发送到的地址）。
Upon receipt of the HEARTBEAT-ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
在收到HEARTBEAT-ACK后，将验证HEARTBEAT参数中包含的nonce是否是发送到HEARTBEAT参数中指示的地址的nonce。当发生此匹配时，原始心跳发送到的地址现在被视为已确认并可用于正常数据传输。
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed.
这些探测过程在关联移动到已建立状态时开始，在确认所有路径时结束。
Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented.
每个RTO a探测器可以在活动的未确认路径上发送，以尝试将其移动到已确认状态。如果在此探测过程中路径变为非活动状态，则此速率将降低到正常心跳速率。RTO计时器到期时，任何已探测但未确认的路径的错误计数器增加1，并进行路径故障检测，如第8.2节所定义。但是，在探测未确认的地址时，关联的总体错误计数不会增加。
The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peer's addresses for path verification.
每个RTO发送的心跳数应受到HB.Max.Burst参数的限制。如何将心跳分配到对等地址以进行路径验证是一个实现决策。
Whenever a path is confirmed, an indication MAY be given to the upper layer.
每当确认路径时，可向上层给出指示。
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions:
端点不得向未经确认的地址发送任何数据块，以下情况除外：
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address.
- 包括nonce的心跳信号可以发送到未确认的地址。
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- HEARTBEAT-ACK可以发送到未确认的地址。
- A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE-ACK to an UNCONFIRMED address.
- COOKIE-ACK可以发送到未确认的地址，但必须与包含nonce的心跳绑定。不支持捆绑的实现不得向未确认的地址发送COOKIE-ACK。
- A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implementation MUST NOT send a COOKIE-ECHO to an UNCONFIRMED address.
- COOKE-ECHO可以发送到未经确认的地址，但必须与包含nonce的心跳绑定，并且数据包不得超过路径MTU。如果实现不支持捆绑，或者捆绑的COOKIE-ECHO plus HEARTBEAT（包括nonce）将超过路径MTU，则实现不得向未确认的地址发送COOKIE-ECHO。
---------
Old text: (Section 14)
---------
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. 建议的SCTP协议参数值
The following protocol parameters are RECOMMENDED:
建议使用以下协议参数：
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. 建议的SCTP协议参数值
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
By properly setting up initial path state and accelerated probing via HEARTBEAT's, a new association can verify that all addresses presented by a peer belong to that peer.
通过正确设置初始路径状态并通过心跳加速探测，新关联可以验证对等方提供的所有地址是否属于该对等方。
RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint.
RFC 2960没有描述SCTP端点应如何处理ICMP消息。
--------
Old text: None
--------
--------
Old text: None
--------
---------
New text
---------
---------
New text
---------
11.5. Protection of Non-SCTP Capable Hosts.
11.5. 保护不支持SCTP的主机。
To provide a non-SCTP capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C.
为了为不支持SCTP的主机提供与支持SCTP的主机相同级别的攻击防护，所有SCTP堆栈必须实现附录C中所述的ICMP处理。
When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA.
当SCTP堆栈接收到包含多个控制或数据块的数据包，并且该数据包的处理需要发送多个数据块作为响应时，响应数据块的发送方不得发送多个数据包。如果支持捆绑，可以将适合单个数据包的多个响应块捆绑到一个响应数据包中。如果不支持绑定，则发送方不得发送多个响应块，并且必须放弃所有其他响应。请注意，此规则不适用于SACK块，因为SACK块本身就是对数据的响应，SACK不需要更多数据的响应。
An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent.
如果SCTP实现接收到确认尚未发送TSN的SACK，则应中止关联。
An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks.
由于包含多个错误参数，接收需要大数据包响应的INIT的SCTP实现可以（自行决定）选择省略部分或全部错误参数以减小INIT-ACK的大小。由于COOKIE参数的大小和INIT接收器可能向对等方指示的地址数的组合，INIT-ACK始终可能大于原始INIT。SCTP实现应尝试使INIT-ACK尽可能小，以减少字节放大攻击的可能性。
---------
Old text: None
---------
---------
Old text: None
---------
---------
New text: (Appendix C)
---------
---------
New text: (Appendix C)
---------
Appendix C ICMP Handling
附录C ICMP处理
Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3.
每当SCTP端点接收到ICMP消息时，必须遵循以下程序，以确保正确利用第3层提供的信息。
ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable".
ICMP1）如果类型字段未设置为“目标不可访问”，则实现可能会忽略所有ICMPv4消息。
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable, "Parameter Problem" or "Packet Too Big".
ICMP2）如果类型字段不是“无法到达目的地”、“参数问题”或“数据包太大”，则实现可能会忽略所有ICMPv6消息。
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）如果代码未指示“协议不可访问”或“需要分段”，则实现可以忽略任何ICMPv4消息。
ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized next header type encountered".
ICMP4）如果代码不是“遇到无法识别的下一个标头类型”，则实现可能会忽略所有类型为“参数问题”的ICMPv6消息。
ICMP5) An implementation MUST use the payload of the ICMP message (V4 or V6) to locate the association that sent the message that ICMP is responding to. If the association cannot be found, an implementation SHOULD ignore the ICMP message.
ICMP5）实现必须使用ICMP消息（V4或V6）的有效负载来定位发送ICMP正在响应的消息的关联。如果找不到关联，则实现应忽略ICMP消息。
ICMP6) An implementation MUST validate that the Verification Tag contained in the ICMP message matches the verification tag of the peer. If the Verification Tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the initiate tag matches the tag of the peer, continue with ICMP7. If the ICMP message is too short or the chunk type or the initiate tag does not match, silently discard the packet.
ICMP6）实现必须验证ICMP消息中包含的验证标记是否与对等方的验证标记匹配。如果验证标记不是0且不匹配，则丢弃ICMP消息。如果为0且ICMP消息包含足够的字节来验证区块类型是否为INIT区块以及initiate标记是否与对等方的标记匹配，请继续执行ICMP7。如果ICMP消息太短或区块类型或initiate标记不匹配，则以静默方式丢弃该数据包。
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery.
ICMP7）如果ICMP消息是V6“数据包太大”或V4“需要碎片”，则实现可以按照为路径MTU发现定义的方式处理此信息。
ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT
ICMP8）如果ICMP代码是“遇到的无法识别的下一个标头类型”或“协议不可访问”，则实现必须将此消息视为带T位的中止（如果它不包含INIT块）。如果它确实包含INIT
chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT.
块，并且关联处于COOKIE-WAIT状态，请像中止一样处理ICMP消息。
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）如果ICMPv6代码为“目的地不可访问”，则实现可能会将目的地标记为不可访问状态，或者增加路径错误计数器。
Note that these procedures differ from RFC 1122 [1] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP.
请注意，这些过程不同于RFC 1122[1]，不同于其处理端口不可访问消息的要求，也不同于实现必须中止关联以响应“协议不可访问”消息的要求。不处理端口不可访问消息，因为实现将发送中止，而不是端口不可访问。对“协议不可访问”消息进行更严格的处理是因为不支持SCTP的主机存在安全问题。
The new appendix now describes proper handling of ICMP messages in conjunction with SCTP.
新的附录现在描述了如何结合SCTP正确处理ICMP消息。
RFC 3309 [6] changes the SCTP checksum due to weaknesses in the original Adler 32 checksum for small messages. This document, being used as a guide for a cut and paste replacement to update RFC 2960, thus also needs to incorporate the checksum changes. The idea is that one could apply all changes found in this guide to a copy of RFC 2960 and have a "new" document that has ALL changes (including RFC 3309).
RFC 3309[6]由于小消息的原始Adler 32校验和存在缺陷，因此更改了SCTP校验和。本文件用作剪切粘贴替换的指南，以更新RFC 2960，因此也需要合并校验和更改。其想法是，可以将本指南中的所有更改应用于RFC 2960的副本，并创建一个包含所有更改（包括RFC 3309）的“新”文档。
---------
Old text:
---------
---------
Old text:
---------
6.8 Adler-32 Checksum Calculation
6.8 Adler-32校验和计算
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the Adler-32 checksum value calculated on the packet, as described below.
当发送SCTP数据包时，端点必须通过包括在数据包上计算的Adler-32校验和值来加强传输的数据完整性，如下所述。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall:
在构建数据包（包含SCTP公共报头和一个或多个控制或数据块）后，发送器应：
1) Fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to 0's.
1) 在SCTP公共标头中填写正确的验证标记，并将校验和字段初始化为0。
2) Calculate the Adler-32 checksum of the whole packet, including the SCTP common header and all the chunks. Refer to appendix B for details of the Adler-32 algorithm. And,
2) 计算整个数据包的Adler-32校验和，包括SCTP公共头和所有数据块。有关Adler-32算法的详细信息，请参阅附录B。和
3) Put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3) 将结果值放入公共标头的校验和字段中，并保持其余位不变。
When an SCTP packet is received, the receiver MUST first check the Adler-32 checksum:
当接收到SCTP数据包时，接收器必须首先检查Adler-32校验和：
1) Store the received Adler-32 checksum value aside,
1) 将收到的Adler-32校验和值存储在一边，
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate an Adler-32 checksum value of the whole received packet. And,
2) 用所有“0”替换接收到的SCTP数据包中校验和字段的32位，并计算整个接收数据包的Adler-32校验和值。和
3) Verify that the calculated Adler-32 checksum is the same as the received Adler-32 checksum. If not, the receiver MUST treat the packet as an invalid SCTP packet.
3) 验证计算出的Adler-32校验和与接收到的Adler-32校验和相同。否则，接收方必须将该数据包视为无效的SCTP数据包。
The default procedure for handling invalid SCTP packets is to silently discard them.
处理无效SCTP数据包的默认过程是以静默方式丢弃它们。
---------
New text:
---------
---------
New text:
---------
6.8 CRC-32c Checksum Calculation
6.8 CRC-32c校验和计算
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the CRC32c checksum value calculated on the packet, as described below.
当发送SCTP数据包时，端点必须通过包括在数据包上计算的CRC32c校验和值来加强传输的数据完整性，如下所述。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter MUST
在构造数据包（包含SCTP公共头和一个或多个控制或数据块）后，发送器必须
1) fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to '0's,
1) 在SCTP公共标头中填写正确的验证标记，并将校验和字段初始化为“0”，
2) calculate the CRC32c checksum of the whole packet, including the SCTP common header and all the chunks (refer to appendix B for details of the CRC32c algorithm); and
2) 计算整个数据包的CRC32c校验和，包括SCTP公共头和所有数据块（有关CRC32c算法的详细信息，请参阅附录B）；和
3) put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3) 将结果值放入公共标头的校验和字段中，并保持其余位不变。
When an SCTP packet is received, the receiver MUST first check the CRC32c checksum as follows:
当接收到SCTP数据包时，接收器必须首先检查CRC32c校验和，如下所示：
1) Store the received CRC32c checksum value aside.
1) 将接收到的CRC32c校验和值存储在一旁。
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate a CRC32c checksum value of the whole received packet.
2) 用所有“0”替换接收到的SCTP数据包中校验和字段的32位，并计算整个接收数据包的CRC32c校验和值。
3) Verify that the calculated CRC32c checksum is the same as the received CRC32c checksum. If it is not, the receiver MUST treat the packet as an invalid SCTP packet.
3) 验证计算出的CRC32c校验和与接收到的CRC32c校验和相同。如果不是，则接收方必须将该数据包视为无效的SCTP数据包。
The default procedure for handling invalid SCTP packets is to silently discard them.
处理无效SCTP数据包的默认过程是以静默方式丢弃它们。
Any hardware implementation SHOULD be done in a way that is verifiable by the software.
任何硬件实现都应以软件可验证的方式进行。
---------
Old text:
---------
---------
Old text:
---------
Appendix B Alder 32 bit checksum calculation
附录B Alder 32位校验和计算
The Adler-32 checksum calculation given in this appendix is copied from [RFC1950].
本附录中给出的Adler-32校验和计算从[RFC1950]复制而来。
Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order.
Adler-32由每个字节累积的两个和组成：s1是所有字节的和，s2是所有s1值的和。这两个和都是以65521模计算的。s1初始化为1，s2初始化为0。Adler-32校验和按网络字节顺序存储为s2*65536+s1。
The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
下面的C代码计算数据缓冲区的Adler-32校验和。它是为了清晰而写的，不是为了速度。示例代码采用ANSI C编程语言。非C用户可能会发现使用以下提示更容易阅读：
& Bitwise AND operator. >> Bitwise right shift operator. When applied to an unsigned quantity, as here, right shift inserts zero bit(s) at the left. << Bitwise left shift operator. Left shift inserts zero bit(s) at the right. ++ "n++" increments the variable n. % modulo operator: a % b is the remainder of a divided by b.
&按位AND运算符。>>按位右移运算符。当应用于无符号量时，如此处所示，右移位在左侧插入零位。<<按位左移位运算符。左移位在右侧插入零位“n++”增加变量n.%模运算符：a%b是a除以b的余数。
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should
be initialized to 1.
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should
be initialized to 1.
Usage example:
用法示例：
unsigned long adler = 1L;
无符号长adler=1L；
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
---------
New text:
---------
---------
New text:
---------
Appendix B CRC32c Checksum Calculation
附录B CRC32c校验和计算
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32-bit CRC is calculated as described for CRC-32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport level usage.
我们将“反射值”定义为与机器的正常位顺序相反的值。按照CRC-32c的说明计算32位CRC，并使用多项式代码0x11EDC6F41（Castagnoli93）或x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0。CRC的计算过程与以太网CRC[ITU32]类似，经过修改以反映传输级别的使用情况。
CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic [PETERSON 72].
CRC计算使用多项式除法。将消息比特串M转换为多项式M（X），并使用多项式算法从M（X）计算CRC[PETERSON 72]。
When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high-order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders.
当在链路层使用CRC时，多项式是从在线位顺序推导出来的：第一位“在线”是高阶系数。由于SCTP是一种传输级协议，它无法知道实际的串行媒体位顺序。此外，SCTP端点之间的路径中的不同链路可以使用不同的链路级比特顺序。
A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit-ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first; but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most significant polynomial coefficient within that byte, and the most-significant SCTP bit is the least significant polynomial coefficient in that byte. (This bit ordering is sometimes called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed back into SCTP transport-level byte values, using a consistent mapping.
因此，必须建立一种约定，将SCTP传输消息映射到多项式，以便进行CRC计算。将SCTP消息映射到多项式的位顺序是首先取最重要的字节；但在每个字节中，位首先被取为最低有效位。消息的第一个字节提供八个最高系数。在每个字节内，最低有效SCTP位给出该字节内最高有效多项式系数，最高有效SCTP位是该字节内最低有效多项式系数。（这种位顺序有时称为“镜像”或“反射”[WILLIAMS93]）CRC多项式将使用一致映射转换回SCTP传输级字节值。
The SCTP transport-level CRC value should be calculated as follows:
SCTP传输级CRC值的计算如下：
- CRC input data are assigned to a byte stream, numbered from 0 to N-1.
- CRC输入数据分配给字节流，编号从0到N-1。
- The transport-level byte-stream is mapped to a polynomial value. An N-byte PDU with j bytes numbered 0 to N-1 is considered as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being coefficient x^(8(N-j)-1).
- 传输级字节流映射到多项式值。具有编号为0到N-1的j字节的N字节PDU被视为8N-1阶多项式M（x）的系数，其中字节j的位0为系数x^（8（N-j）-8，字节j的位7为系数x^（8（N-j）-1）。
- The CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial.
- CRC余数寄存器用所有1初始化，CRC用同时乘以x^32和除以CRC多项式的算法计算。
- The polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, producing a remainder R(x) of degree less than or equal to 31.
- 该多项式乘以x^32，再除以生成多项式G（x），得到一个小于或等于31次的余数R（x）。
- The coefficients of R(x) are considered a 32-bit sequence.
- R（x）的系数被认为是一个32位序列。
- The bit sequence is complemented. The result is the CRC polynomial.
- 位序列被补充。结果是CRC多项式。
- The CRC polynomial is mapped back into SCTP transport-level bytes. The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, and the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3, and the coefficient of x^0 gives bit 0 of byte 3. The resulting four-byte transport-level sequence is the 32-bit SCTP checksum value.
- CRC多项式被映射回SCTP传输级字节。x^31的系数给出了SCTP字节0的第7位的值，x^24的系数给出了字节0的第0位的值。x^7的系数给出字节3的第7位，x^0的系数给出字节3的第0位。产生的四字节传输级序列是32位SCTP校验和值。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified such that the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
实施说明：关于CRC的标准文件、教科书和供应商文献通常遵循另一种表述，其中用于保存长除法算法剩余部分的寄存器初始化为零，而不是全部1，并补充消息的前32位。我们公式中使用的长除法算法是这样规定的，即2^32的初始乘法和长除法组合成一个同时运算。对于此类算法，以及长度超过64位的消息，这两种规范完全等效。该等效性是本文件的目的。
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long-division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits.
SCTP的实现者被警告，这两个规范都可以在文献中找到，有时对长除法算法没有限制。本文件中的公式选择允许非SCTP使用，其中相同的CRC算法可用于保护短于64位的消息。
There may be a computational advantage in validating the Association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These special case exchanges must represent small packets and will minimize the effect of the checksum calculation.
在执行校验和之前，根据验证标记验证关联可能具有计算优势，因为在大多数情况下，无效标记将导致与错误校验和相同的操作。这种技术的例外情况是INIT和一些关机完成的交换，以及陈旧的COOKIE-ECHO。这些特殊情况交换必须表示小数据包，并将校验和计算的影响降至最低。
---------
Old text: (Section 18)
---------
---------
Old text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]Allman，M.和Paxson，V.，“关于估算端到端网络路径属性”，Proc。SIGCOMM'991999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[Fall 96]Fall，K.和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]伊斯特莱克，D.（编辑），“安全的随机性建议”，RFC17501994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，Anderson，T.，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，29（5），1999年10月。
---------
New text: (Section 18, including changes from 2.11)
---------
---------
New text: (Section 18, including changes from 2.11)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]Allman，M.和Paxson，V.，“关于估算端到端网络路径属性”，Proc。SIGCOMM'991999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[Fall 96]Fall，K.和Floyd，S.，《塔霍河、雷诺和萨克TCP基于模拟的比较》，《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[ITU32] ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", Section 8.1.1.6.2, October 1996.
[ITU32]ITU-T建议V.42，“使用异步到同步转换的DCE纠错程序”，第8.1.1.6.2节，1996年10月。
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting Codes, 2nd Edition, MIT Press, Cambridge, Massachusetts.
[PETERSON 1972]W.W.PETERSON和E.J Weldon，纠错码，第二版，麻省理工学院出版社，马萨诸塞州剑桥。
[RFC1750] Eastlake, D., Ed., "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]伊斯特莱克，D.，编辑，“安全的随机性建议”，RFC17501994年12月。
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.和Traina P.，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99]Savage，S.，Cardwell，N.，Wetheral，D.，Anderson，T.，“使用行为不当接收器的TCP拥塞控制”，ACM计算机通信评论，29（5），1999年10月。
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" - Internet publication, August 1993, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm.
[WILLIAMS93]Williams，R.，“CRC错误检测算法的无痛指南”-互联网出版物，1993年8月，http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm。
This change adds to the implementor's guide the complete set of changes that, when combined with RFC 2960 [5], encompasses the changes from RFC 3309 [6].
该变更为实施者指南增加了一整套变更，当与RFC 2960[5]结合时，这些变更包含了RFC 3309[6]的变更。
The current retransmission policy (send all retransmissions an alternate destination) in the specification has performance issues under certain loss conditions with multihomed endpoints. Instead, fast retransmissions should be sent to the same destination, and only timeout retransmissions should be sent to an alternate destination [4].
规范中的当前重传策略（将所有重传发送到备用目的地）在多宿端点的某些丢失情况下存在性能问题。相反，应将快速重传发送到同一目的地，并且仅将超时重传发送到备用目的地[4]。
---------
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 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.
此外，当其对等方是多宿时，端点应尝试将超时的数据块重新传输到活动目标传输地址，该地址与数据块发送到的最后一个目标地址不同。
---------
Old text: (Section 6.4.1)
---------
---------
Old text: (Section 6.4.1)
---------
When retransmitting data, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
当重传数据时，如果端点是多家乡的，它应该考虑在其重传选择策略中的每个源目的地地址对。当重新传输时，端点应尝试从数据包传输到的原始源-目的地对中选取最分散的源-目的地对。
---------
New text: (Section 6.4.1)
---------
---------
New text: (Section 6.4.1)
---------
When retransmitting data that timed out, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
当重传超时的数据时，如果端点是多宿主的，则它应该考虑其重传选择策略中的每个源目的地地址对。当重新传输超时数据时，端点应尝试从数据包传输到的原始源-目的地对中选取差异最大的源-目的地对。
The above wording changes clarify that only timeout retransmissions should be sent to an alternate active destination.
上面的措辞更改阐明，只有超时重传才应发送到备用活动目的地。
The port number 0 has a special semantic in various APIs. For example, in the socket API, if the user specifies 0, the SCTP implementation chooses an appropriate port number for the user. Therefore, the port number 0 should not be used on the wire.
端口号0在各种API中具有特殊的语义。例如，在socket API中，如果用户指定0，SCTP实现将为用户选择适当的端口号。因此，不应在导线上使用端口号0。
---------
Old text: (Section 3.1)
---------
---------
Old text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
源端口号：16位（无符号整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs.
这是SCTP发送方的端口号。它可由接收器与源IP地址、SCTP目的地端口以及可能的目的地IP地址结合使用，以识别该分组所属的关联。
Destination Port Number: 16 bits (unsigned integer)
目标端口号：16位（无符号整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application.
这是该数据包的目的地SCTP端口号。接收主机将使用此端口号将SCTP数据包解复用到正确的接收端点/应用程序。
---------
New text: (Section 3.1)
---------
---------
New text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
源端口号：16位（无符号整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used.
这是SCTP发送方的端口号。它可由接收器与源IP地址、SCTP目的地端口和可能的目的地IP地址结合使用，以识别该分组所属的关联。不得使用端口号0。
Destination Port Number: 16 bits (unsigned integer)
目标端口号：16位（无符号整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
这是该数据包的目的地SCTP端口号。接收主机将使用此端口号将SCTP数据包解复用到正确的接收端点/应用程序。不得使用端口号0。
It is clearly stated that the port number 0 is an invalid value on the wire.
很明显，端口号0是导线上的无效值。
The description of the T bit as the bit describing whether a TCB has been destroyed is misleading. In addition, the procedure described in Section 2.13 is not as precise as needed.
将T位描述为描述TCB是否已被破坏的位具有误导性。此外，第2.13节中描述的程序不够精确。
---------
Old text: (Section 3.3.7)
---------
---------
Old text: (Section 3.3.7)
---------
T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
T位：1位如果发送方有已销毁的TCB，则T位设置为0。如果发送方没有TCB，则应将该位设置为1。
---------
New text: (Section 3.3.7)
---------
---------
New text: (Section 3.3.7)
---------
T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
T位：1位如果发送方填写了对等方期望的验证标记，则T位设置为0。如果验证标签被反射，则T位必须设置为1。反射意味着发送的验证标签与接收的验证标签相同。
---------
Old text: (Section 3.3.13)
---------
---------
Old text: (Section 3.3.13)
---------
T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
T位：1位如果发送方有已销毁的TCB，则T位设置为0。如果发送方没有TCB，则应将该位设置为1。
---------
New text: (Section 3.3.13)
---------
---------
New text: (Section 3.3.13)
---------
T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
T位：1位如果发送方填写了对等方期望的验证标记，则T位设置为0。如果验证标签被反射，则T位必须设置为1。反射意味着发送的验证标签与接收的验证标签相同。
---------
Old text: (Section 8.4)
---------
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise,
3) 如果数据包包含验证标记设置为“0”的INIT块，请按照第5.1节中的说明进行处理。否则
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag of
the packet containing the ABORT chunk MUST be the Initiate
tag of the received INIT chunk, and the T-Bit of the ABORT
chunk has to be set to 0, indicating that the Verification
Tag is NOT reflected.
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag of
the packet containing the ABORT chunk MUST be the Initiate
tag of the received INIT chunk, and the T-Bit of the ABORT
chunk has to be set to 0, indicating that the Verification
Tag is NOT reflected.
---------
Old text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver
should respond to the sender of the OOTB packet with a
SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
receiver of the OOTB packet must fill in the Verification
Tag field of the outbound packet with the Verification Tag
received in the SHUTDOWN ACK and set the T-bit in the Chunk
Flags to indicate that no TCB was found. Otherwise,
---------
Old text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver
should respond to the sender of the OOTB packet with a
SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
receiver of the OOTB packet must fill in the Verification
Tag field of the outbound packet with the Verification Tag
received in the SHUTDOWN ACK and set the T-bit in the Chunk
Flags to indicate that no TCB was found. Otherwise,
---------
New text: (Section 8.4)
---------
---------
New text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. Otherwise,
5) 如果数据包包含SHUTDOWN ACK块，则接收方应以SHUTDOWN COMPLETE响应OOTB数据包的发送方。发送关机完成时，OOTB数据包的接收方必须使用关机确认中接收到的验证标签填写出站数据包的验证标签字段，并在区块标志中设置T位，以指示验证标签已被反映。否则
---------
Old text: (Section 8.4)
---------
---------
Old text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that no TCB was found. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8) 接收方应以中止响应OOTB数据包的发送方。发送中止时，OOTB数据包的接收方必须使用在OOTB数据包的验证标签字段中找到的值填写出站数据包的验证标签字段，并在区块标志中设置T位以指示未找到TCB。发送此中止后，OOTB数据包的接收方应丢弃OOTB数据包，不再采取进一步的行动。
---------
New text: (Section 8.4)
---------
---------
New text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8) 接收方应以中止响应OOTB数据包的发送方。发送中止时，OOTB数据包的接收方必须使用在OOTB数据包的验证标签字段中找到的值填写出站数据包的验证标签字段，并在区块标志中设置T位，以指示验证标签被反射。发送此中止后，OOTB数据包的接收方应丢弃OOTB数据包，不再采取进一步的行动。
---------
Old text: (Section 8.5.1)
---------
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B） 数据包承载中止规则：
- The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known.
- 端点应始终在出站数据包的验证标签字段中填入目标端点的标签值（如果已知）。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果验证标签与其自己的标签或其对等方的标签匹配，则接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
---------
New text: (Section 8.5.1)
---------
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B） 数据包承载中止规则：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- 端点必须始终使用目标端点的标记值（如果已知）填写出站数据包的验证标记字段。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- 如果中止是响应OOTB数据包发送的，则端点必须遵循第8.4节中描述的过程。
- The receiver of an ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 如果数据包的验证标记字段与其自己的标记匹配且未设置T位，或者如果数据包设置为其对等标记且T位在区块标志中设置，则中止的接收方必须接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。
---------
Old text: (Section 8.5.1)
---------
---------
Old text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C） 数据包传送关闭规则完成：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST be used. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK.
- 发送关机完成时，如果关机确认的接收器具有TCB，则必须使用目标端点的标记。只有在不存在TCB的情况下，发送方才应使用关机确认中的验证标签。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag OR it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- 如果数据包的验证标签字段与其自己的标签匹配，或者设置为对等标签，并且在区块标志中设置了T位，则关闭完成的接收器应接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。如果端点未处于SHUTDOWN-ACK-SENT状态，则它必须忽略SHUTDOWN COMPLETE。
---------
New text: (Section 8.5.1)
---------
---------
New text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C） 数据包传送关闭规则完成：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB, then the destination endpoint's tag MUST be used, and the T-bit MUST NOT be set. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK, and MUST set the T-bit.
- 发送关机完成时，如果关机确认的接收器具有TCB，则必须使用目标端点的标记，并且不得设置T位。只有在不存在TCB的情况下，发送方才应使用关机确认中的验证标签，并且必须设置T位。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- 如果数据包的验证标签字段与其自己的标签匹配且未设置T位，或者数据包设置为其对等标签且T位设置在区块标志中，则关闭完成的接收器应接受数据包。否则，接收方必须悄悄地丢弃数据包，并且不采取进一步的操作。如果端点未处于SHUTDOWN-ACK-SENT状态，则它必须忽略SHUTDOWN COMPLETE。
The description of the T bit now clearly describes the semantic of the bit. The procedures for receiving the T bit have been clarified.
T比特的描述现在清楚地描述了比特的语义。已澄清接收T位的程序。
The description given in Section 2.33 does not state clearly whether an INIT-ACK or COOKIE-ECHO is sent.
第2.33节中给出的描述未明确说明是否发送了INIT-ACK或COOKIE-ECHO。
The changes given here already include changes suggested in Section 2.2, 2.27, and 2.33 of this document.
此处给出的变更已经包括本文件第2.2、2.27和2.33节中建议的变更。
---------
Old text: (Section 3.2.1)
---------
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it do not process any further chunks within it.
00-停止处理此SCTP数据包并丢弃它-不处理其中的任何其他数据块。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-停止处理此SCTP数据包并丢弃它，不要处理其中的任何其他数据块，并在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-跳过此参数并继续处理，但在“Unrecogned parameter Type”（错误或初始确认）中报告未识别的参数。
---------
New text: (Section 3.2.1)
---------
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00-停止处理该参数；不要在此块中处理任何其他参数。
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2.
01-停止处理此参数，不处理此区块内的任何其他参数，并在“Unrecogned parameter”（未识别参数）中报告未识别的参数，如3.2.2所述。
10 - Skip this parameter and continue processing.
10-跳过此参数并继续处理。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2.
11-跳过此参数并继续处理，但在“未识别参数”中报告未识别的参数，如3.2.2所述。
Please note that in all four cases an INIT-ACK or COOKIE-ECHO chunk is sent. In the 00 or 01 case the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
请注意，在所有四种情况下，都会发送INIT-ACK或COOKIE-ECHO块。在00或01情况下，取消未知参数后的参数处理，但不回滚已完成的处理。
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 报告无法识别的参数
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
如果INIT块的接收方检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，则必须将“无法识别的参数”参数放入响应INIT块而发送的INIT-ACK块中。请注意，如果INIT块的接收方不打算建立关联（例如，由于缺乏资源），则发送给INIT发送方的任何中止都不会包含“无法识别的参数”。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
如果INIT-ACK数据块的接收者检测到无法识别的参数，并且必须根据第3.2.1节报告这些参数，那么它应该将包含“无法识别的参数”错误原因的错误数据块与响应INIT-ACK数据块而发送的COOKIE-ECHO数据块捆绑在一起。如果INIT-ACK的接收器无法将COOKIE-ECHO块与错误块捆绑在一起，则可以单独发送错误块，但不能在收到COOKIE-ACK之前发送。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注意：任何时候在数据包中发送COOKIE-ECHO时，它必须是第一个数据块。
The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be sent.
新文本明确指出必须发送INIT-ACK或COOKIE-ECHO。
The description given in Section 3.3.11 of RFC 2960 [5] is unclear as to how the COOKIE-ECHO is composed.
RFC 2960[5]第3.3.11节中给出的描述不清楚COOKIE-ECHO是如何构成的。
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
此字段必须包含在State cookie参数中从上一个INIT ACK接收到的确切cookie。
An implementation SHOULD make the cookie as small as possible to insure interoperability.
实现应该使cookie尽可能小，以确保互操作性。
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
此字段必须包含在State cookie参数中从上一个INIT ACK接收到的确切cookie。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
实现应该使cookie尽可能小，以确保互操作性。
Note: A Cookie Echo does NOT contain a State Cookie Parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first two bytes of the State Cookie parameter to become a Cookie Echo Chunk.
注意：Cookie回显不包含状态Cookie参数；相反，状态Cookie的参数值中的数据将成为Cookie Echo的块值中的数据。这允许实现仅将State Cookie参数的前两个字节更改为Cookie Echo块。
The new text adds a note that helps clarify that a Cookie Echo chunk is nothing more than the State Cookie parameter with only two bytes modified.
新文本添加了一个注释，有助于澄清Cookie回显块只不过是修改了两个字节的状态Cookie参数。
Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks' without defining it.
RFC 2960[5]第6.10节使用了“部分块”的概念，但没有对其进行定义。
---------
Old text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet.
---------
Old text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet.
---------
New text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk that is not completely contained in the SCTP
packet; i.e., the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length.
---------
New text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk that is not completely contained in the SCTP
packet; i.e., the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length.
The new text adds a definition of 'partial chunks'.
新文本增加了“部分块”的定义。
Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all non-unicast addresses. This leaves future use of anycast addresses in question. With the addition of the add-ip feature, SCTP should be able to easily handle anycast INIT s that can be followed, after association setup, with a delete of the anycast address from the association.
RFC 2960[5]第8.4节强制OOTB处理丢弃所有非单播地址。这就给选播地址的未来使用留下了疑问。通过添加add ip功能，SCTP应该能够轻松地处理anycast INIT，在关联设置之后，可以从关联中删除anycast地址。
---------
Old text: (Section 8.4)
---------
8.4 Handle "Out of the blue" Packets
---------
Old text: (Section 8.4)
---------
8.4 Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
如果SCTP数据包的格式正确，即通过了接收方的Adler-32检查（见第6.8节），则称其为“出其不意”（OOTB）数据包，但接收方无法识别该数据包所属的关联。
The receiver of an OOTB packet MUST do the following:
OOTB数据包的接收方必须执行以下操作：
1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise,
1) 如果OOTB数据包发送到非单播地址或来自非单播地址，则自动丢弃该数据包。否则
---------
New text: (Section 8.4)
---------
---------
New text: (Section 8.4)
---------
8.4. Handle "Out of the Blue" Packets
8.4. 处理“突发事件”数据包
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
如果SCTP数据包的格式正确（即通过了接收方的CRC32c检查；参见第6.8节），则称其为“出其不意”（OOTB）数据包，但接收方无法识别该数据包所属的关联。
The receiver of an OOTB packet MUST do the following:
OOTB数据包的接收方必须执行以下操作：
1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
1) 如果OOTB数据包发送到非单播地址或来自非单播地址，则接收方应悄悄丢弃该数据包。否则
The loosening of the wording to a SHOULD will now allow future use of anycast addresses. Note that no changes are made to Section 11.2.4.1, since responding to broadcast addresses could lead to flooding attacks and implementors should pay careful attention to these words.
将措辞放宽为“应该”现在将允许将来使用选播地址。请注意，第11.2.4.1节未作任何更改，因为响应广播地址可能导致洪水攻击，实施者应仔细注意这些词语。
Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently discard ABORT chunks received for associations that do not exist. It is not clear what this means in the COOKIE-WAIT state, for example. Therefore, it was not clear whether an ABORT sent in response to an INIT should be processed or silently discarded.
RFC 2960[5]的第3.3.7节要求SCTP端点以静默方式放弃为不存在的关联接收的中止块。例如，不清楚在COOKIE-WAIT状态下这意味着什么。因此，不清楚是应该处理响应INIT发送的中止，还是应该以静默方式放弃中止。
---------
Old text: (Section 3.3.7)
---------
---------
Old text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it.
如果端点接收到带格式错误的中止或不存在关联的中止，则必须以静默方式放弃该中止。
---------
New text: (Section 3.3.7)
---------
---------
New text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it.
如果端点接收到带格式错误的中止或未找到TCB，则必须以静默方式放弃它。
It is now clearly stated that an ABORT chunk should be processed whenever a TCB is found.
现在已经明确指出，只要找到TCB，就应该处理中止块。
Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in response to an INIT chunk when there is no listening end point. To make port scanning harder, someone might not want these ABORTs to be received by the sender of the INIT chunks. Currently, the only way to enforce this is by using a firewall that discards the packets containing the INIT chunks or the packets containing the ABORT chunks. It is desirable that the same can be done without a middle box.
RFC 2960[5]的第5.1节要求在没有侦听端点时发送一个中止块以响应INIT块。为了使端口扫描更加困难，可能有人不希望INIT块的发送方接收这些中止。目前，强制执行此操作的唯一方法是使用防火墙，该防火墙丢弃包含INIT块的数据包或包含ABORT块的数据包。希望在没有中间盒的情况下也能做到这一点。
---------
Old text: (Section 5.1)
---------
---------
Old text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk.
如果端点接收到INIT、INIT ACK或COOKIE ECHO块，但由于接收到的INIT或INIT ACK中缺少必需参数、参数值无效或缺少本地资源而决定不建立新关联，则它必须使用中止块进行响应。
---------
New text: (Section 5.1)
---------
---------
New text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk.
如果端点接收到INIT、INIT ACK或COOKIE ECHO块，但由于接收到的INIT或INIT ACK中缺少必需参数、参数值无效或缺少本地资源而决定不建立新关联，则它应使用中止块进行响应。
The requirement of sending ABORT chunks is relaxed such that an implementation can decide not to send ABORT chunks.
发送中止块的要求被放宽，这样实现就可以决定不发送中止块。
The sender of the INIT chunk can include a 'Supported Address Types' parameter to indicate which address families are supported. It is unclear how an INIT chunk should be processed where the source address of the packet containing the INIT chunk or listed addresses
INIT块的发送方可以包含“支持的地址类型”参数，以指示支持哪些地址族。不清楚在包含INIT块的数据包的源地址或列出的地址所在的位置，应该如何处理INIT块
within the INIT chunk indicate that more address types are supported than those listed in the 'Supported Address Types' parameter.
在INIT块中，表示支持的地址类型比“支持的地址类型”参数中列出的地址类型多。
The changes given here already include changes suggested in Section 2.28 of this document.
此处给出的变更已经包括本文件第2.28节中建议的变更。
---------
Old text: (Section 5.1.2)
---------
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新启动，以指示其首选的地址类型。
---------
New text: (Section 5.1.2)
---------
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
实施说明：如果INIT ACK的接收方由于不支持的类型而无法解析address参数，它可以中止启动过程，然后通过在新INIT中使用“Supported address Types”参数来尝试重新启动，以指示其首选的地址类型。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
实施说明：如果仅支持IPv4或IPv6的SCTP终结点从其对等方接收到INIT或INIT-ACK块中的IPv4和IPv6地址，则它必须使用属于支持的地址系列的所有地址。其他地址可能会被忽略。端点不应响应任何类型的错误指示。
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.
实施说明：如果SCTP端点在“受支持的地址类型”参数中列出IPv4或IPv6，但使用另一个系列发送包含INIT区块的数据包，或者如果它还列出INIT区块中另一个系列的地址，然后，“Supported address Types”（受支持的地址类型）参数中未列出的地址族也应被视为受INIT块的接收方支持。INIT块的接收方不应响应任何类型的错误指示。
It is now clearly described how these Supported Address Types parameters with incorrect data should be handled.
现在已经清楚地描述了如何处理这些支持的地址类型参数和不正确的数据。
RFC 2960 [5] clearly describes how unknown parameters in the INIT and INIT-ACK chunk should be processed. But it is not described how unexpected parameters should be processed. A parameter is unexpected if it is known and is an optional parameter in either the INIT or INIT-ACK chunk but is received in the chunk for which it is not an optional parameter. For example, the 'Supported Address Types' parameter would be an unexpected parameter if contained in an INIT-ACK chunk.
RFC 2960[5]清楚地描述了应该如何处理INIT和INIT-ACK块中的未知参数。但没有描述如何处理意外参数。如果参数是已知的，并且是INIT或INIT-ACK块中的可选参数，但在非可选参数的块中接收到，则该参数是意外的。例如，“受支持的地址类型”参数如果包含在INIT-ACK块中，则可能是意外参数。
---------
Old text: (Section 3.3.2)
---------
---------
Old text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
注4：此参数（如果存在）指定发送端点可以支持的所有地址类型。缺少此参数表示发送端点可以支持任何地址类型。
---------
New text: (Section 3.3.2)
---------
---------
New text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
注4：此参数（如果存在）指定发送端点可以支持的所有地址类型。缺少此参数表示发送端点可以支持任何地址类型。
IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk then the receiver SHOULD process the INIT chunk and send back an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE-ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
实现说明：如果接收到的INIT块中包含的已知参数不是INIT块的可选参数，则接收方应处理INIT块并发回INIT-ACK。INIT块的接收者稍后可能会将错误块与COOKIE-ACK块捆绑在一起。但是，限制性实现可能会发回一个ABORT块来响应INIT块。
---------
Old text: (Section 3.3.3)
---------
---------
Old text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
实现说明：由于状态cookie和可变地址列表的大小可变，实现必须准备好接收相当大（超过1500字节）的INIT ACK。例如，如果INIT的响应程序希望发送1000个IPv4地址，则至少需要8000字节才能在INIT ACK中对其进行编码。
---------
New text: (Section 3.3.3)
---------
---------
New text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example, if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
实现说明：由于状态cookie和可变地址列表的大小可变，实现必须准备好接收相当大（超过1500字节）的INIT ACK。例如，如果INIT的响应程序希望发送1000个IPv4地址，则至少需要8000字节才能在INIT ACK中对其进行编码。
IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known parameters that are not optional parameters of the INIT-ACK chunk, then the receiver SHOULD process the INIT-ACK chunk and send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT-ACK chunk.
实施说明：如果接收到的INIT-ACK块的已知参数不是INIT-ACK块的可选参数，则接收方应处理INIT-ACK块并发送回COOKIE-ECHO。INIT-ACK块的接收方可以将错误块与COOKIE-ECHO块捆绑在一起。但是，限制性实现可能会发回中止块以响应INIT-ACK块。
It is now stated how unexpected parameters should be processed.
现在说明了如何处理意外参数。
The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order.
有效负载协议标识符的当前描述没有突出显示字段不一定按网络字节顺序的事实。
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities as well as the peer application to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network).
此值表示应用程序（或上层）指定的协议标识符。该值由其上层传递给SCTP，并发送给其对等方。SCTP不使用此标识符，但某些网络实体以及对等应用程序可以使用此标识符来标识此数据块中承载的信息类型。这个字段必须在零散的数据块中发送（以确保它对于网络中间的代理是可用的）。
The value 0 indicates no application identifier is specified by the upper layer for this payload data.
值0表示上层没有为此有效负载数据指定应用程序标识符。
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation, therefore its byte order is NOT necessarily Big Endian. The upper layer is responsible for any byte order conversions to this field.
此值表示应用程序（或上层）指定的协议标识符。该值由其上层传递给SCTP，并发送给其对等方。SCTP不使用此标识符，但某些网络实体以及对等应用程序可以使用此标识符来标识此数据块中承载的信息类型。这个字段必须在零散的数据块中发送（以确保它对于网络中间的代理是可用的）。请注意，SCTP实现不涉及此字段，因此其字节顺序不一定是Big-Endian。上层负责到该字段的任何字节顺序转换。
The value 0 indicates that no application identifier is specified by the upper layer for this payload data.
值0表示上层没有为此有效负载数据指定应用程序标识符。
It is now explicitly stated that the upper layer is responsible for the byte order of this field.
现在明确指出，上层负责该字段的字节顺序。
The current wording of the use of Karn's algorithm is not descriptive enough to ensure that an implementation in a multi-homed association does not incorrectly mismeasure the RTT.
目前使用Karn算法的措辞不足以确保多宿主关联中的实现不会错误地误判RTT。
---------
Old text: (Section 6.3.1)
---------
---------
Old text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using
packets that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of the
packet or a later instance)
---------
New text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using
packets that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of the
packet or a later instance)
---------
New text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance)
C5）Karn算法：RTT测量不得使用重新传输的数据块（因此，对于这些数据块，回复是针对该数据块的第一个实例还是后续实例是不明确的）
IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.
实施说明：如果自r首次发送后，没有TSN小于或等于r的区块被重新传输，则只能使用TSN为r的区块进行RTT测量。
The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm.
上述澄清增加了一份实施说明，将为Karn算法的应用提供额外的指导。
The original SCTP specification is overly conservative in requiring 4 missing reports before fast retransmitting a segment. TCP uses 3 missing reports or 4 acknowledgements indicating that the same segment was received.
最初的SCTP规范过于保守，要求在快速重新传输段之前丢失4个报告。TCP使用3个缺失报告或4个确认，表明收到了相同的数据段。
---------
Old text:
---------
---------
Old text:
---------
7.2.4 Fast Retransmit on Gap Reports
7.2.4 间隙报告的快速重传
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
在没有数据丢失的情况下，端点执行延迟确认。但是，每当端点注意到到达的TSN序列中有一个漏洞时，它应该在每次数据包到达时发送一个SACK，直到该漏洞被填满为止。
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
每当端点接收到指示某些TSN丢失的SACK时，它应该等待相同TSN上的3个进一步的未命中指示（通过后续SACK），然后再采取有关快速重新传输的操作。
---------
New text:
---------
---------
New text:
---------
7.2.4. Fast Retransmit on Gap Reports
7.2.4. 间隙报告的快速重传
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
在没有数据丢失的情况下，端点执行延迟确认。但是，每当端点注意到到达的TSN序列中有一个漏洞时，它应该在每次数据包到达时发送一个SACK，直到该漏洞被填满为止。
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 2 further miss indications (via subsequent SACKs for a total of 3 missing reports) on the same TSNs before taking action with regard to Fast Retransmit.
每当端点接收到表明某些TSN丢失的SACK时，它应该等待相同TSN上的2个进一步的未命中指示（通过后续SACK总共3个缺失报告），然后再采取有关快速重新传输的措施。
The above changes will make SCTP and TCP behave similarly in terms of how fast they engage the Fast Retransmission algorithm upon receiving missing reports.
上述更改将使SCTP和TCP在接收丢失报告时采用快速重传算法的速度方面表现类似。
This document should add no additional security risks to SCTP and in fact SHOULD correct some original security flaws within the original document once it is incorporated into a RFC 2960 [5] BIS document.
本文件不应给SCTP增加额外的安全风险，事实上，一旦纳入RFC 2960[5]BIS文件，应纠正原始文件中的一些原始安全缺陷。
The authors would like to thank the following people who have provided comments and input for this document:
作者要感谢为本文件提供评论和意见的以下人员：
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
巴里·扎克曼、拉蒙特·雅罗、谢乔宾、王晓鹏、乔纳森·伍德、杰夫·瓦斯科、迈克·特纳、约翰·汤森、萨比娜·托雷特、克里夫·托马斯、铃木优吉、马诺伊·索兰基、斯维雷·斯洛特、基尔·沙阿、扬·罗文斯、本·罗宾逊、雷内·雷维斯、伊恩·佩里安、RC·莫内、桑杰·饶、苏吉特·拉德哈克里希南、海因茨·普兰特纳、比伦·帕特尔、纳塔利·莫利奇、，米奇·迈尔斯、伯恩沃德·梅克内克特、斯坦·麦克莱伦、奥利弗市长、托马斯·奥尔蒂·马丁、桑德普·马哈扬、大卫·莱曼、乔纳森·李、菲利普·朗格洛伊斯、卡尔·克努森、乔·凯勒、加雷思·凯利、安德烈亚斯·荣迈尔、贾纳德·艾扬格、穆苏亚·艾里、约翰·赫伯特、考萨·哈桑、弗雷德·哈塞尔、丹·哈里森、乔恩·格里姆、劳伦特·格劳德、史蒂文·弗尼斯、，福本安寿、藤田肯、史蒂夫·迪米格、托马斯·科伦、塞尔坎·齐尔、梅丽莎·坎贝尔、彼得·巴特勒、罗布·布伦南、哈什·邦德、布莱恩·比杜洛克、凯特琳·贝斯特勒、乔恩·伯杰、罗比·贝内迪克、斯蒂芬·鲍克、桑德普·巴拉尼和罗尼·塞拉。
A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.
特别感谢马克·奥尔曼，他本应该是《max burst》的合著者，但由于技术上的原因，他成功地摆脱了困境。此外，我们还要感谢林登·翁和菲尔·康拉德的宝贵意见和许多贡献。
This document recommends changes for the RFC 2960 [5] BIS document. As such, even though it lists new error cause code, this document in itself does NOT define those new codes. Instead, the BIS document will make the needed changes to RFC 2960 [5] and thus its IANA section will require changes to be made.
本文件建议对RFC 2960[5]BIS文件进行修改。因此，即使它列出了新的错误原因代码，但本文档本身并没有定义这些新代码。相反，BIS文件将对RFC 2960[5]进行必要的修改，因此其IANA部分将要求进行修改。
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[1] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP and TCP Variants: Congestion Control Under Multiple Losses", Technical Report TR2003-04, Computer and Information Sciences Department, University of Delaware, February 2003, <http://www.armandocaro.net/papers>.
[3] CARO、A.、Sah、K.、Iyangar、J.、阿梅尔、P.和R. Stewart，“SCTP和TCP变体：多重损失下的拥塞控制”，德拉瓦大学计算机与信息科学系，技术报告Tr2003 3-04，2003年2月，<http://www.armandocaro.net/papers>.
[4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for End-to-end Failover with Transport Layer Multihoming", GLOBECOM, November 2004., <http://www.armandocaro.net/papers>.
[4] Caro，A.，Amer，P.，和R.Stewart，“具有传输层多主的端到端故障切换的重传方案”，GLOBECOM，2004年11月<http://www.armandocaro.net/papers>.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[6] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[6] Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC3309，2002年9月。
Authors' Addresses
作者地址
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA
Randall R.Stewart Cisco Systems，Inc.4875 Forest Drive Suite 200哥伦比亚，SC 29206美国
EMail: rrs@cisco.com
EMail: rrs@cisco.com
Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
Ivan Arias Rodriguez诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: ivan.arias-rodriguez@nokia.com
EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon Sun Microsystems, Inc. 3571 N. First St. San Jose, CA 95134 USA
Kacheong Poon Sun Microsystems，Inc.3571 N.First St.San Jose，CA 95134美国
EMail: kacheong.poon@sun.com
EMail: kacheong.poon@sun.com
Armando L. Caro Jr. BBN Technologies 10 Moulton St. Cambridge, MA 02138
马萨诸塞州剑桥莫尔顿街10号Armando L.Caro Jr.BBN Technologies，邮编：02138
EMail: acaro@bbn.com
URI: http://www.armandocaro.net
EMail: acaro@bbn.com
URI: http://www.armandocaro.net
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen Muenster应用科学大学Stegerwaldstr。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。