Network Working Group R. Stewart
Request for Comments: 3758 M. Ramalho
Category: Standards Track Cisco Systems, Inc.
Q. Xie
Motorola, Inc.
M. Tuexen
Univ. of Applied Sciences Muenster
P. Conrad
University of Delaware
May 2004
Network Working Group R. Stewart
Request for Comments: 3758 M. Ramalho
Category: Standards Track Cisco Systems, Inc.
Q. Xie
Motorola, Inc.
M. Tuexen
Univ. of Applied Sciences Muenster
P. Conrad
University of Delaware
May 2004
Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
流控制传输协议（SCTP）部分可靠性扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism.
此备忘录描述了对流控制传输协议（SCTP）的扩展，该协议允许SCTP端点向其对等方发出信号，表明其应向前移动累积ack点。当SCTP关联的双方都支持此扩展时，SCTP实现可以使用它向上层协议提供部分可靠的数据传输服务。本备忘录描述了协议扩展，包括INIT和INIT ACK的新参数以及新的前向TSN块类型，并提供了一个可通过该机制向上层提供的部分可靠服务的示例。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of Protocol Extensions. . . . . . . . . . . . . 2
1.2. Overview of New Services Provided to the Upper Layer . . 3
1.3. Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . 4
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . . 5
3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK. . 5
3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN). . 5
3.3. Negotiation of Forward-TSN-Supported parameter . . . . . 7
3.3.1. Sending Forward-TSN-Supported param in INIT . . . 7
3.3.2. Receipt of Forward-TSN-Supported parameter in
INIT or INIT-ACK. . . . . . . . . . . . . . . . . 7
3.3.3. Receipt of Op. Error for Forward-TSN-Supported
Param . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition of "abandoned" in the context of PR-SCTP. . . 8
3.5. Sender Side Implementation of PR-SCTP. . . . . . . . . . 9
3.6. Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
4. Services provided by PR-SCTP to the upper layer. . . . . . . . 14
4.1. PR-SCTP Service Definition for "timed reliability" . . . 15
4.2. PR-SCTP Association Establishment. . . . . . . . . . . . 16
4.3. Guidelines for defining other PR-SCTP Services . . . . . 17
4.4. Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
5. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of Protocol Extensions. . . . . . . . . . . . . 2
1.2. Overview of New Services Provided to the Upper Layer . . 3
1.3. Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . 4
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . . 5
3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK. . 5
3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN). . 5
3.3. Negotiation of Forward-TSN-Supported parameter . . . . . 7
3.3.1. Sending Forward-TSN-Supported param in INIT . . . 7
3.3.2. Receipt of Forward-TSN-Supported parameter in
INIT or INIT-ACK. . . . . . . . . . . . . . . . . 7
3.3.3. Receipt of Op. Error for Forward-TSN-Supported
Param . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition of "abandoned" in the context of PR-SCTP. . . 8
3.5. Sender Side Implementation of PR-SCTP. . . . . . . . . . 9
3.6. Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
4. Services provided by PR-SCTP to the upper layer. . . . . . . . 14
4.1. PR-SCTP Service Definition for "timed reliability" . . . 15
4.2. PR-SCTP Association Establishment. . . . . . . . . . . . 16
4.3. Guidelines for defining other PR-SCTP Services . . . . . 17
4.4. Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
5. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC 2960 [2] that allows an SCTP sender to signal to its peer that it should no longer expect to receive one or more DATA chunks.
本备忘录描述了对流控制传输协议（SCTP）RFC 2960[2]的扩展，该扩展允许SCTP发送方向其对等方发出信号，表明其不再期望接收一个或多个数据块。
The protocol extension described in this document consists of two new elements:
本文件中描述的协议扩展由两个新元素组成：
1. a single new parameter in the INIT/INIT-ACK exchange that indicates whether the endpoint supports the extension
1. INIT/INIT-ACK交换中的单个新参数，指示端点是否支持扩展
2. a single new chunk type, FORWARD TSN, that indicates that the receiver should move its cumulative ack point forward (possibly skipping past one or more DATA chunks that may not yet have been received and/or acknowledged.)
2. 一种新的数据块类型FORWARD TSN，指示接收器应向前移动其累积ack点（可能跳过一个或多个可能尚未接收和/或确认的数据块）
When this extension is supported by both sides of an SCTP association, it can be used to provide partially reliable transport service over an SCTP association. We define partially reliable transport service as a service that allows the user to specify, on a per message basis, the rules governing how persistent the transport service should be in attempting to send the message to the receiver.
当SCTP关联的双方都支持此扩展时，可以使用它通过SCTP关联提供部分可靠的传输服务。我们将部分可靠传输服务定义为一种服务，它允许用户在每条消息的基础上指定控制传输服务在尝试将消息发送给接收方时的持久性的规则。
One example of partially reliable service is specified in this document, namely a "timed reliability" service. This service allows the service user to indicate a limit on the duration of time that the sender should try to transmit/retransmit the message (this is a natural extension of the "lifetime" parameter already in the base protocol).
本文件规定了部分可靠服务的一个示例，即“定时可靠性”服务。此服务允许服务用户指示发送方尝试传输/重新传输消息的持续时间限制（这是基本协议中已有的“生存期”参数的自然扩展）。
In addition to this example, we will also show that defining the semantics of a particular partially reliable service involves two elements, namely:
除此示例外，我们还将说明定义特定部分可靠服务的语义涉及两个元素，即：
1. how the service user indicates the level of reliability required for a particular message, and
1. 服务用户如何指示特定消息所需的可靠性水平，以及
2. how the sender side implementation uses that reliability level to determine when to give up on further retransmissions of that message.
2. 发送方实现如何使用该可靠性级别来确定何时放弃该消息的进一步重传。
Note that other than the fact that the FORWARD-TSN chunk is required, neither of these two elements impacts the "on-the-wire" protocol; only the API and the sender side implementation are affected by the way in which the service is defined to the upper layer. Therefore, in principle, it is feasible to implement many varieties of partially reliable services in a particular SCTP implementation without changing the on-the-wire protocol. Also, the SCTP receiver does not necessarily need to know which semantics of partially reliable service are being used by the sender, since the receiver's only role is to correctly interpret FORWARD TSN chunks, thereby skipping past messages that the sender has decided to no longer transmit (or retransmit).
注意，除了需要FORWARD-TSN块这一事实之外，这两个元素都不会影响“在线”协议；只有API和发送方实现受上层服务定义方式的影响。因此，原则上，在不改变在线协议的情况下，在特定SCTP实现中实现多种部分可靠的服务是可行的。此外，SCTP接收器不一定需要知道发送方正在使用部分可靠服务的哪种语义，因为接收器的唯一作用是正确解释前向TSN块，从而跳过发送方已决定不再传输（或重新传输）的过去消息。
Nevertheless, it is recommended that a limited number of standard definitions of partially reliable services be standardized by the IETF so that the designers of IETF application layer protocols can
然而，建议IETF对有限数量的部分可靠服务的标准定义进行标准化，以便IETF应用层协议的设计者能够
match the requirements of their upper layer protocols to standard service definitions provided by a particular SCTP implementation. One such definition, "timed reliability", is included in this document. Given the extensions proposed in this document, other definitions may be standardized as the need arises without further changes to the on-the-wire protocol.
将其上层协议的要求与特定SCTP实现提供的标准服务定义相匹配。本文件中包含一个此类定义“定时可靠性”。鉴于本文件中提出的扩展，其他定义可根据需要进行标准化，而无需对在线协议进行进一步更改。
Hereafter, we use the notation "Partial Reliable Stream Control Transmission Protocol (PR-SCTP)" to refer to the SCTP protocol, extended as defined in this document.
此后，我们使用符号“部分可靠流控制传输协议（PR-SCTP）”来表示SCTP协议，该协议按照本文件中的定义进行扩展。
The following are some of the advantages for integrating partially reliable data service into SCTP, i.e., benefits of PR-SCTP:
以下是将部分可靠的数据服务集成到SCTP中的一些优势，即PR-SCTP的优势：
1. Some application layer protocols may benefit from being able to use a single SCTP association to carry both reliable content, -- such as text pages, billing and accounting information, setup signaling -- and unreliable content, e.g., state that is highly sensitive to timeliness, where generating a new packet is more advantageous than transmitting an old one [3].
1. 一些应用层协议可能受益于能够使用单个SCTP关联来承载可靠内容（如文本页、账单和会计信息、设置信令）和不可靠内容（如对及时性高度敏感的状态），其中，生成新分组比发送旧分组更有利[3]。
2. Partially reliable data traffic carried by PR-SCTP will enjoy the same communication failure detection and protection capabilities as the normal reliable SCTP data traffic does. This includes the ability to quickly detect a failed destination address, fail-over to an alternate destination address, and be notified if the data receiver becomes unreachable.
2. PR-SCTP承载的部分可靠数据流量将享有与正常可靠SCTP数据流量相同的通信故障检测和保护能力。这包括快速检测故障目标地址、故障切换到备用目标地址以及在数据接收器无法访问时收到通知的能力。
3. In addition to providing unordered, unreliable data transfer as UDP does, PR-SCTP can provide ordered, unreliable data transfer service.
3. 除了像UDP一样提供无序、不可靠的数据传输外，PR-SCTP还可以提供有序、不可靠的数据传输服务。
4. PR-SCTP employs the same congestion control and congestion avoidance for all data traffic, whether reliable or partially reliable - this is very desirable since SCTP enforces TCP-friendliness (unlike UDP.)
4. PR-SCTP对所有数据流量（无论是可靠的还是部分可靠的）采用相同的拥塞控制和拥塞避免-这是非常可取的，因为SCTP加强了TCP友好性（与UDP不同）
5. Because of the chunk bundling function of SCTP, reliable and unreliable messages can be multiplexed over a single PR-SCTP association. Therefore, the number of IP datagrams (and hence the network overhead) can be reduced instead of having to send these different types of data using separate protocols. Additionally, this multiplexing allows for port savings versus using different ports for reliable and unreliable connections.
5. 由于SCTP的区块绑定功能，可靠和不可靠的消息可以通过单个PR-SCTP关联进行多路复用。因此，可以减少IP数据报的数量（从而减少网络开销），而不必使用单独的协议发送这些不同类型的数据。此外，与使用不同的端口进行可靠和不可靠的连接相比，这种多路复用允许节省端口。
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 BCP 14, RFC 2119 [1].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、不推荐、可和可选时，应按照BCP 14、RFC 2119[1]中的说明进行解释。
Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are governed by the rules in Section 1.6 of RFC 2960 [2].
传输序列号（TSN）的比较和算法受RFC 2960[2]第1.6节中的规则管辖。
The following new OPTIONAL parameter is added to the INIT and INIT ACK chunks.
以下新的可选参数添加到INIT和INIT ACK块中。
Parameter Name Status Type Value
-------------------------------------------------------------
Forward-TSN-Supported OPTIONAL 49152 (0xC000)
Parameter Name Status Type Value
-------------------------------------------------------------
Forward-TSN-Supported OPTIONAL 49152 (0xC000)
At the initialization of the association, the sender of the INIT or INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer that it is able to support the Forward TSN chunk (see Section 3.3 for further details). The format of this parameter is defined as follows:
在关联初始化时，INIT或INIT ACK块的发送方可以包括此可选参数，以通知其对等方它能够支持前向TSN块（有关更多详细信息，请参阅第3.3节）。此参数的格式定义如下：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 49152 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 49152 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int
类型：16位u_int
49152, indicating Forward-TSN-Supported parameter
49152，表示前向TSN支持的参数
Length: 16 bit u_int
长度：16位u_int
Indicates the size of the parameter, i.e., 4.
指示参数的大小，即4。
The following new chunk type is defined:
定义了以下新块类型：
Chunk Type Chunk Name
------------------------------------------------------
192 (0xC0) Forward Cumulative TSN (FORWARD TSN)
Chunk Type Chunk Name
------------------------------------------------------
192 (0xC0) Forward Cumulative TSN (FORWARD TSN)
This chunk shall be used by the data sender to inform the data receiver to adjust its cumulative received TSN point forward because some missing TSNs are associated with data chunks that SHOULD NOT be transmitted or retransmitted by the sender.
数据发送方应使用该数据块通知数据接收方向前调整其累计接收的TSN点，因为某些缺失的TSN与发送方不应传输或重新传输的数据块相关联。
Forward Cumulative TSN chunk has the following format:
前向累积TSN区块具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 192 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-1 | Stream Sequence-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-N | Stream Sequence-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 192 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-1 | Stream Sequence-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-N | Stream Sequence-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags:
区块标志：
Set to all zeros on transmit and ignored on receipt.
传输时设置为全零，接收时忽略。
New Cumulative TSN: 32 bit u_int
新累积TSN:32位u_int
This indicates the new cumulative TSN to the data receiver. Upon the reception of this value, the data receiver MUST consider any missing TSNs earlier than or equal to this value as received, and stop reporting them as gaps in any subsequent SACKs.
这表示数据接收器的新累积TSN。在接收到该值时，数据接收器必须考虑任何小于或等于接收到此值的丢失的TSN，并且停止将它们报告为任何后续包中的间隙。
Stream-N: 16 bit u_int
流N:16位u_int
This field holds a stream number that was skipped by this FWD-TSN.
此字段保存此FWD-TSN跳过的流编号。
Stream Sequence-N: 16 bit u_int
流序列-N:16位u_int
This field holds the sequence number associated with the stream that was skipped. The stream sequence field holds the largest stream sequence number in this stream being skipped. The receiver of the FWD-TSN's can use the Stream-N and Stream Sequence-N fields to enable delivery of any stranded TSN's that remain on the stream re-ordering queues. This field MUST NOT report TSN's corresponding to DATA chunks that are marked as unordered. For ordered DATA chunks this field MUST be filled in.
此字段保存与被跳过的流关联的序列号。stream sequence字段保存被跳过流中的最大流序列号。FWD-TSN的接收器可以使用Stream-N和Stream Sequence-N字段来启用保留在流重新排序队列上的任何搁浅TSN的递送。此字段不得报告与标记为无序的数据块相对应的TSN。对于有序数据块，必须填写此字段。
If an SCTP endpoint supports the FORWARD TSN chunk, then any time it sends an INIT during association establishment, it MAY include the Forward-TSN-supported parameter in the INIT chunk to indicate this fact to its peer.
如果SCTP端点支持前向TSN块，则在关联建立期间，每当它发送INIT时，它可能会在INIT块中包含前向TSN支持的参数，以向其对等方指示此事实。
Note that if the endpoint chooses NOT to include the parameter, then at no time during the life of the association can it send or process a FORWARD TSN. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN.
请注意，如果端点选择不包含该参数，则在关联生命周期内任何时候都不能发送或处理前向TSN。相反，它必须表现为不支持转发TSN块，在收到任何转发TSN时向对等方返回错误。
When a receiver of an INIT detects a Forward-TSN-Supported parameter and does not support the Forward-TSN chunk type, the receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960 [2].
当INIT的接收器检测到Forward TSN Supported参数且不支持Forward TSN区块类型时，接收器必须遵循RFC 2960[2]第3.3.3节中定义的规则。
When a receiver of an INIT-ACK detects a Forward-TSN-Supported parameter and it does not support the Forward-TSN chunk type, the receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960 [2].
当INIT-ACK的接收器检测到前向TSN支持的参数且不支持前向TSN块类型时，接收器必须遵循RFC 2960[2]第3.3.3节中定义的规则。
When a receiver of an INIT detects a Forward-TSN-Supported parameter and it does support the Forward-TSN chunk type, the receiver MAY respond with a Forward-TSN-supported parameter in the INIT-ACK chunk.
当INIT的接收器检测到前向TSN支持的参数并且它确实支持前向TSN块类型时，接收器可以在INIT-ACK块中使用前向TSN支持的参数进行响应。
Note that if the endpoint chooses NOT to include the parameter, then at no time during the life of the association can it send or process a FORWARD TSN. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN.
请注意，如果端点选择不包含该参数，则在关联生命周期内任何时候都不能发送或处理前向TSN。相反，它必须表现为不支持转发TSN块，在收到任何转发TSN时向对等方返回错误。
When an endpoint that supports the FORWARD TSN chunk receives an INIT that does not contain the Forward-TSN-Supported Parameter, that endpoint:
当支持FORWARD TSN区块的端点接收到不包含FORWARD TSN Supported参数的INIT时，该端点：
o MAY include the Forward-TSN-Supported parameter in the INIT-ACK, o SHOULD record the fact that the peer does not support the FORWARD TSN chunk, o MUST NOT send a FORWARD TSN chunk at any time during the associations life, o SHOULD inform the upper layer if the upper layer has requested such notification.
o 可以在INIT-ACK中包括Forward TSN Supported参数，o应记录对等方不支持Forward TSN区块的事实，o不得在关联生命周期内的任何时间发送Forward TSN区块，o应通知上层是否上层已请求此类通知。
When an SCTP endpoint that desires to use the FORWARD TSN chunk feature for partially reliable data transfer receives an operational error from the remote endpoint (either bundled with the COOKIE or as an unrecognized parameter in the INIT-ACK), indicating that the remote endpoint does not recognize the Forward-TSN-Supported parameter, the local endpoint SHOULD inform its upper layer of the remote endpoint's inability to support partially reliable data transfer.
当希望使用前向TSN区块功能进行部分可靠数据传输的SCTP端点从远程端点（与COOKIE捆绑在一起或作为INIT-ACK中无法识别的参数）接收到操作错误时，表示远程端点无法识别前向TSN支持的参数，本地端点应告知其上层远程端点无法支持部分可靠的数据传输。
The local endpoint may then choose to either:
然后，本地端点可以选择：
1) end the initiation process (in cases where the initiation process has already ended, the endpoint may need to send an ABORT) in consideration of the peer's inability to supply the requested features for the new association, or
1) 考虑到对等方无法为新关联提供请求的功能，结束启动过程（在启动过程已经结束的情况下，端点可能需要发送中止），或者
2) continue the initiation process (in cases where the initiation process has already completed, the endpoint MUST just mark the association as not supporting partial reliability), but with the understanding that partially reliable data transmission is not supported. In this case, the endpoint receiving the operational error SHOULD note that the FORWARD TSN chunk is not supported, and MUST NOT transmit a FORWARD TSN chunk at any time during the life of the association.
2) 继续启动过程（在启动过程已经完成的情况下，端点必须仅将关联标记为不支持部分可靠性），但要理解不支持部分可靠的数据传输。在这种情况下，接收操作错误的端点应注意，不支持前向TSN块，并且在关联生命周期内的任何时候都不得传输前向TSN块。
At some point, a sending PR-SCTP implementation MAY determine that a particular data chunk SHOULD NOT be transmitted or retransmitted further, in accordance with the rules governing some particular PR-SCTP service definition (such as the definition of "timed reliability" in Section 4.1.) For purposes of this document, we define the term "abandoned" to refer to any data chunk about which the SCTP sender has made this determination.
在某些情况下，发送PR-SCTP实现可能会根据某些特定PR-SCTP服务定义（如第4.1节中“定时可靠性”的定义）的规则确定不应进一步传输或重新传输特定数据块。在本文件中，我们定义术语“放弃”引用SCTP发送方已做出此决定的任何数据块。
Each PR-SCTP service defines the rules for determining when a TSN is "abandoned", and accordingly, the rules that govern how, whether, and when to "abandon" a TSN may vary from one service definition to another. However, the rules governing the actions taken when a TSN is "abandoned" do NOT vary between service definitions; these rules are included in Section 3.5.
每个PR-SCTP服务定义用于确定何时“放弃”TSN的规则，相应地，控制如何、是否以及何时“放弃”TSN的规则可能因服务定义的不同而不同。但是，当TSN被“放弃”时，管理所采取的操作的规则在服务定义之间没有变化；这些规则包含在第3.5节中。
The sender side implementation of PR-SCTP is identical to that of the base SCTP protocol, except for:
PR-SCTP的发送方实现与基本SCTP协议相同，除了：
o actions a sending side PR-SCTP implementation must take when a TSN is "abandoned" (as per the rules of whatever PR-SCTP service definition is in effect) o special actions that a PR-SCTP implementation must take upon receipt of SACK o rules governing the generation of FORWARD TSN chunks.
o 当TSN被“放弃”时，发送端PR-SCTP实现必须采取的行动（根据有效的PR-SCTP服务定义的规则）o PR-SCTP实现在收到SACK时必须采取的特殊行动o管理前向TSN块生成的规则。
In detail, these exceptions are as follows:
具体而言，这些例外情况如下：
A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer to track a theoretical cumulative TSN point of the peer (Note, this is a _new_ protocol variable and its value is NOT necessarily the same as the SCTP "Cumulative TSN Ack Point" as defined in Section 1.4 of RFC 2960 [2], and as discussed throughout that document.)
A1）发送方为每个对等方维护一个“Advanced.Peer.Ack.Point”，以跟踪对等方的理论累积TSN点（注意，这是一个新的协议变量，其值不一定与RFC 2960[2]第1.4节中定义的SCTP“累积TSN Ack Point”相同，并在该文件中进行了讨论。）
A2) From time to time, as governed by the rules of a particular PR-SCTP service definition (see Section 4), the SCTP data sender may make a determination that a particular data chunk that has already been assigned a TSN SHOULD be "abandoned".
A2）根据特定PR-SCTP服务定义的规则（见第4节），SCTP数据发送方可不时确定已分配TSN的特定数据块应“放弃”。
When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding.
当数据块被“放弃”时，发送方必须将该数据块视为已最终确认且不再未完成。
The sender MUST NOT credit an "abandoned" data chunk to the partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2], and MUST NOT advance the cwnd based on this "abandoned" data chunk.
发送方不得将“放弃的”数据块记入RFC 2960[2]第7.2.2节中定义的已确认的部分字节，也不得基于该“放弃的”数据块推进cwnd。
A3) When a TSN is "abandoned", if it is part of a fragmented message, all other TSN's within that fragmented message MUST be abandoned at the same time.
A3）当TSN被“放弃”时，如果它是碎片消息的一部分，则必须同时放弃该碎片消息中的所有其他TSN。
A4) Whenever the data sender receives a SACK from the data receiver, it MUST first process the SACK using the normal procedures as defined in Section 6.2.1 of RFC 2960 [2].
A4）每当数据发送方从数据接收方接收SACK时，必须首先使用RFC 2960[2]第6.2.1节中定义的正常程序处理SACK。
The data sender MUST then perform the following additional steps:
然后，数据发送方必须执行以下附加步骤：
C1) Let SackCumAck be the Cumulative TSN ACK carried in the received SACK.
C1）让SackCumAck为接收到的SACK中携带的累积TSN ACK。
If (Advanced.Peer.Ack.Point < SackCumAck), then update Advanced.Peer.Ack.Point to be equal to SackCumAck.
如果（Advanced.Peer.Ack.Point<SackCumAck），则更新Advanced.Peer.Ack.Point使其等于SackCumAck。
C2) Try to further advance the "Advanced.Peer.Ack.Point" locally, that is, to move "Advanced.Peer.Ack.Point" up as long as the chunk next in the out-queue space is marked as "abandoned", as shown in the following example:
C2）尝试在本地进一步提升“Advanced.Peer.Ack.Point”，即只要队列外空间中的下一个区块标记为“放弃”，就向上移动“Advanced.Peer.Ack.Point”，如下例所示：
Assuming that a SACK arrived with the Cumulative TSN ACK = 102 and the Advanced.Peer.Ack.Point is updated to this value:
假设SACK到达时累计TSN ACK=102，且Advanced.Peer.ACK.Point更新为该值：
out-queue at the end of ==> out-queue after Adv.Ack.Point normal SACK processing local advancement
结束时的out queue==>Adv.Ack.Point normal SACK processing local ADVANCE后的out queue
... ... Adv.Ack.Pt-> 102 acked 102 acked 103 abandoned 103 abandoned 104 abandoned Adv.Ack.P-> 104 abandoned 105 105 106 acked 106 acked ... ...
... ... Adv.Ack.Pt->102确认102确认103放弃103放弃104放弃Adv.Ack.P->104放弃105 106确认106确认。。。
In this example, the data sender successfully advanced the "Advanced.Peer.Ack.Point" from 102 to 104 locally.
在本例中，数据发送方在本地成功地将“advanced.Peer.Ack.Point”从102提升到104。
C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is greater than the Cumulative TSN ACK carried in the received SACK, the data sender MUST send the data receiver a FORWARD TSN chunk containing the latest value of the "Advanced.Peer.Ack.Point". Note that the sender MAY delay the sending of a FORWARD TSN as defined in rule F2 below. IMPLEMENTATION NOTE: It is an implementation decision as to which destination address it is to be sent to, the only restriction being that the address MUST be one that is CONFIRMED.
C3）如果在步骤C1和C2之后，“Advanced.Peer.Ack.Point”大于接收到的SACK中携带的累积TSN Ack，则数据发送方必须向数据接收方发送包含“Advanced.Peer.Ack.Point”最新值的前向TSN块。注意，发送方可以延迟发送如下面的规则F2中定义的转发TSN。实施说明：这是关于发送到哪个目的地地址的实施决定，唯一的限制是该地址必须是已确认的地址。
C4) For each "abandoned" TSN, the sender of the FORWARD TSN MUST determine if the chunk has a valid stream and sequence number (i.e., it was ordered). If the chunk has a valid stream and sequence number, the sender MUST include the stream and sequence number in the FORWARD TSN. This information will enable the receiver to easily find any stranded TSN's waiting
C4）对于每个“放弃的”TSN，前向TSN的发送方必须确定区块是否具有有效的流和序列号（即，它已被订购）。如果区块具有有效的流和序列号，则发送方必须在转发TSN中包含流和序列号。此信息将使接收器能够轻松找到任何滞留的TSN
on stream reorder queues. Each stream SHOULD only be reported once; this means that if multiple abandoned messages occur in the same stream, then only the highest abandoned stream sequence number is reported. If the total size of the FORWARD TSN does NOT fit in a single MTU, then the sender of the FORWARD TSN SHOULD lower the Advanced.Peer.Ack.Point to the last TSN that will fit in a single MTU.
流上重新排序队列。每个流只能报告一次；这意味着，如果在同一个流中出现多个废弃消息，则只报告最高的废弃流序列号。如果转发TSN的总大小不适合单个MTU，则转发TSN的发送方应将Advanced.Peer.Ack.Point降低到将适合单个MTU的最后一个TSN。
C5) If a FORWARD TSN is sent, the sender MUST assure that at least one T3-rtx timer is running. IMPLEMENTATION NOTE: Any destination's timer may be used for the purposes of rule C5.
C5）如果发送了转发TSN，发送方必须确保至少有一个T3 rtx定时器正在运行。实施说明：任何目的地的计时器均可用于规则C5。
A5) Any time the T3-rtx timer expires, on any destination, the sender SHOULD try to advance the "Advanced.Peer.Ack.Point" by following the procedures outlined in C2 - C5.
A5）每当T3 rtx计时器在任何目的地过期时，发送方应尝试按照C2-C5中概述的程序推进“Advanced.Peer.Ack.Point”。
The following additional rules govern the generation of FORWARD TSN chunks:
以下附加规则控制前向TSN块的生成：
F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other than circumstances described in this document.
F1）端点不得将转发TSN用于本文件所述情况以外的任何目的。
F2) The data sender SHOULD always attempt to bundle an outgoing FORWARD TSN with outbound DATA chunks for efficiency.
F2）为了提高效率，数据发送方应始终尝试将传出转发TSN与出站数据块捆绑在一起。
A sender MAY even choose to delay the sending of the FORWARD TSN in the hope of bundling it with an outbound DATA chunk.
发送方甚至可以选择延迟转发TSN的发送，希望将其与出站数据块捆绑在一起。
IMPLEMENTATION NOTE: An implementation may wish to limit the number of duplicate FORWARD TSN chunks it sends by either only sending a duplicate FORWARD TSN every other SACK or waiting a full RTT before sending a duplicate FORWARD TSN.
实施说明：实施可能希望通过每隔一个SACK只发送一个重复的前向TSN或在发送重复的前向TSN之前等待一个完整的RTT来限制其发送的重复的前向TSN块的数量。
IMPLEMENTATION NOTE: An implementation may allow the maximum delay for generating a FORWARD TSN to be configured either statically or dynamically in order to meet the specific timing requirements of the protocol being carried, but see the next rule:
实施说明：实施可允许静态或动态配置生成转发TSN的最大延迟，以满足所承载协议的特定定时要求，但请参见下一条规则：
F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT exceed 200ms and MUST NOT exceed 500ms. In other words, an implementation MAY lower this value below 500ms but MUST NOT raise it above 500ms.
F3）应用于发送前向TSN块的任何延迟不得超过200ms，且不得超过500ms。换句话说，实现可以将该值降低到500ms以下，但不能将其提高到500ms以上。
NOTE: Delaying the sending of FORWARD TSN chunks may cause delays in the receiver's ability to deliver other data being held at the receiver for re-ordering. The values of 200ms and 500ms match
注意：延迟前向TSN块的发送可能会导致接收器延迟交付接收器保存的其他数据以进行重新排序。200ms和500ms的值匹配
the required values for the delayed acknowledgement in RFC 2960 [2] since delaying a FORWARD TSN has the same consequences but in the reverse direction.
RFC 2960[2]中延迟确认所需的值，因为延迟前向TSN具有相同的结果，但方向相反。
F4) The detection criterion for out-of-order SACKs MUST remain the same as stated in RFC 2960, that is, a SACK is only considered out-of-order if the Cumulative TSN ACK carried in the SACK is earlier than that of the previous received SACK (i.e., the comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
F4）故障行李的检测标准必须与RFC 2960中规定的相同，即，如果行李中携带的累积TSN ACK早于之前接收到的行李（即，不得与“Advanced.Peer.ACK.Point”进行比较），则仅认为行李故障。
F5) If the decision to "abandon" a chunk is made, no matter how such a decision is made, the appropriate congestion adjustment MUST be made as specified in RFC 2960 if the chunk would have been marked for retransmission later (e.g., either by T3-Timeout or by Fast Retransmit).
F5）如果做出了“放弃”数据块的决定，无论该决定是如何作出的，如果该数据块将被标记为稍后重新传输（例如，通过T3超时或快速重新传输），则必须按照RFC 2960中的规定进行适当的拥塞调整。
The receiver side implementation of PR-SCTP at an SCTP endpoint A is capable of supporting any PR-SCTP service definition used by the sender at endpoint B, even if that service definition is not supported by the sending side functionality of host A. All that is necessary is that the receiving side correctly handle the Forward-TSN-Supported parameter as specified in Section 3.3, and correctly handle the receipt of FORWARD TSN chunks as specified below.
SCTP端点A处的PR-SCTP的接收方实现能够支持端点B处的发送方使用的任何PR-SCTP服务定义，即使主机A的发送端功能不支持该服务定义，所需的只是接收方按照第3.3节的规定正确处理Forward TSN supported参数，并按照以下规定正确处理Forward TSN chunk的接收。
DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA
chunk arrival at a base protocol SCTP receiver---that is, the
receiver MUST perform the same TSN handling, including duplicate
detection, gap detection, SACK generation, cumulative TSN
advancement, etc. as defined in RFC 2960 [2]---with the following
exceptions and additions.
DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA
chunk arrival at a base protocol SCTP receiver---that is, the
receiver MUST perform the same TSN handling, including duplicate
detection, gap detection, SACK generation, cumulative TSN
advancement, etc. as defined in RFC 2960 [2]---with the following
exceptions and additions.
When a FORWARD TSN chunk arrives, the data receiver MUST first update its cumulative TSN point to the value carried in the FORWARD TSN chunk, and then MUST further advance its cumulative TSN point locally if possible, as shown by the following example:
当前向TSN块到达时，数据接收方必须首先将其累积TSN点更新为前向TSN块中携带的值，然后必须在可能的情况下进一步在本地提前其累积TSN点，如下例所示：
Assuming that the new cumulative TSN carried in the arrived FORWARD TSN is 103:
假设到账TSN中携带的新累计TSN为103：
in-queue before processing in-queue after processing the FORWARD TSN ==> the FORWARD TSN and further advancement
处理前在队列中处理后在队列中向前TSN==>向前TSN和进一步推进
cum.TSN.Pt-> 102 received 102 -- 103 missing 103 -- 104 received 104 -- 105 received cum.TSN.Pt-> 105 received 106 missing 106 missing 107 received 107 received ... ...
累计TSN.Pt->102收到102--103缺失103--104收到104--105收到累计TSN.Pt->105收到106缺失106缺失107收到107收到。。。
In this example, the receiver's cumulative TSN point is first updated to 103 and then further advanced to 105.
在该示例中，接收机的累积TSN点首先更新到103，然后进一步前进到105。
After the above processing, the data receiver MUST stop reporting any missing TSNs earlier than or equal to the new cumulative TSN point.
在上述处理之后，数据接收器必须停止报告任何小于或等于新累积TSN点的缺失TSN。
Note, if the "New Cumulative TSN" value carried in the arrived FORWARD TSN chunk is found to be behind or at the current cumulative TSN point, the data receiver MUST treat this FORWARD TSN as out-of-date and MUST NOT update its Cumulative TSN. The receiver SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since such a duplicate may indicate the previous SACK was lost in the network.
注意，如果发现到达的前向TSN区块中携带的“新累积TSN”值落后于或位于当前累积TSN点，则数据接收方必须将此前向TSN视为过期，并且不得更新其累积TSN。接收方应向其对等方（转发TSN的发送方）发送一个SACK，因为这样的副本可能表明前一个SACK在网络中丢失。
Any time a FORWARD TSN chunk arrives, for the purposes of sending a SACK, the receiver MUST follow the same rules as if a DATA chunk had been received (i.e., follow the delayed sack rules specified in RFC 2960 [2] section 6.2).
任何时候，为了发送SACK，前向TSN区块到达时，接收方必须遵循与接收到数据区块相同的规则（即，遵循RFC 2960[2]第6.2节中规定的延迟SACK规则）。
Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating ordered delivery) and is out of order, the receiver must hold the chunk for reordering. Since it is possible with PR-SCTP that a DATA chunk being waited upon will not be retransmitted, special actions will need to be taken upon the arrival of a FORWARD TSN.
每当数据块到达时，其“U”位设置为“0”（表示有序交付），并且出现顺序错误时，接收方必须持有该数据块以进行重新排序。由于PR-SCTP可能不会重新传输正在等待的数据块，因此需要在前向TSN到达时采取特殊措施。
In particular, during processing of a FORWARD TSN, the receiver MUST use the stream sequence information to examine all of the listed stream reordering queues, and immediately make available for delivery stream sequence numbers earlier than or equal to the stream sequence number listed inside the FORWARD TSN. Any such stranded data SHOULD be made immediately available to the upper layer application.
具体地，在前向TSN的处理期间，接收器必须使用流序列信息来检查所有列出的流重新排序队列，并且立即使交付流序列号早于或等于前向TSN内列出的流序列号。任何此类滞留数据应立即提供给上层应用程序。
An application using PR-SCTP receiving data should be aware of possible missing messages. The stream sequence number can be used, in such a case, to determine that an intervening message has been skipped. When intervening messages are missing, it is an application decision to process the messages or to take some other corrective action.
使用PR-SCTP接收数据的应用程序应注意可能丢失的消息。在这种情况下，可以使用流序列号来确定已跳过介入消息。当中间消息丢失时，应用程序决定处理消息或采取其他纠正措施。
After receiving and processing a FORWARD TSN, the data receiver MUST take cautions in updating its re-assembly queue. The receiver MUST remove any partially reassembled message, which is still missing one or more TSNs earlier than or equal to the new cumulative TSN point. In the event that the receiver has invoked the partial delivery API, a notification SHOULD also be generated to inform the upper layer API that the message being partially delivered will NOT be completed.
在接收和处理前向TSN后，数据接收器必须注意更新其重新组装队列。接收方必须删除任何部分重新组装的消息，该消息仍然缺少早于或等于新累积TSN点的一个或多个TSN。如果接收方调用了部分传递API，则还应生成通知，通知上层API部分传递的消息将不会完成。
Note that after receiving a FORWARD TSN and updating the cumulative acknowledgement point, if a TSN that was skipped does arrive (i.e., due to network reordering), then the receiver will follow the normal rules defined in RFC 2960 [2] for handling duplicate data. This implies that the receiver will drop the chunk and report it as a duplicate in the next outbound SACK chunk.
注意，在接收到转发TSN并更新累积确认点之后，如果被跳过的TSN确实到达（即，由于网络重新排序），则接收器将遵循RFC 2960[2]中定义的处理重复数据的正常规则。这意味着接收方将删除该块，并在下一个出站SACK块中将其作为副本报告。
As described in Section 1.2, it is feasible to implement a variety of partially reliable transport services using the new protocol mechanisms introduced in Section 3; introducing these new services requires making changes only at the sending side API, and the sending side protocol implementation. Thus, there may be a temptation to standardize only the protocol, and leave the service definition as "implementation specific" or leave it to be defined in "informational" documents.
如第1.2节所述，使用第3节介绍的新协议机制实现各种部分可靠的传输服务是可行的；引入这些新服务只需要在发送端API和发送端协议实现上进行更改。因此，可能存在仅标准化协议的诱惑，将服务定义保留为“特定于实现”或保留在“信息性”文档中定义。
However, for those who may wish to write IETF standards for upper layer protocols implemented over PR-SCTP, it is important to be able to refer to a standard definition of services provided. Therefore, this section provides example definitions of one such service, while also providing guidelines for the definition of additional services as required. Each such service may be proposed as a separate new RFC.
然而，对于那些希望为通过PR-SCTP实现的上层协议编写IETF标准的人来说，能够参考所提供服务的标准定义是很重要的。因此，本节提供了此类服务的示例定义，同时还提供了根据需要定义附加服务的指南。每项此类服务可作为单独的新RFC提出。
Section 4 is organized as follows:
第4节的组织如下：
o Section 4.1 provides the definition of one specific PR-SCTP service: timed reliability.
o 第4.1节提供了一种特定PR-SCTP服务的定义：定时可靠性。
o Section 4.2 describes how a particular PR-SCTP service definition is requested by the upper layer during association establishment, and how the upper layer is notified if that request cannot be satisfied.
o 第4.2节描述了上层在关联建立期间如何请求特定的PR-SCTP服务定义，以及如果无法满足该请求，如何通知上层。
o Section 4.3 then provides guidelines for the specification of PR-SCTP services other then the one defined in this memo.
o 第4.3节提供了PR-SCTP服务规范指南，本备忘录中定义的服务除外。
o Finally, Section 4.4 describes some additional usage notes that upper layer protocol designers and implementors may find helpful.
o 最后，第4.4节描述了上层协议设计人员和实现人员可能会发现有帮助的一些附加用法说明。
The "timed reliability" service is a natural extension of the "lifetime" concept already present in the base SCTP protocol.
“定时可靠性”服务是基本SCTP协议中已经存在的“寿命”概念的自然延伸。
When this service is requested for an SCTP association, it changes the meaning of the lifetime parameter specified in the SEND primitive (see Section 10.1, part (E) of RFC 2960 [2]; note that the parameter is spelled "life time" in that document.)
当为SCTP关联请求此服务时，它会更改发送原语中指定的生存期参数的含义（请参阅RFC 2960[2]第10.1节第（E）部分；请注意，该文件中的参数拼写为“生存期”。）
In the base SCTP protocol, the lifetime parameter is used to avoid sending stale data. When a lifetime value is indicated for a particular message and that lifetime expires, SCTP cancels the sending of this message, and notifies the ULP if the first transmission of the data does not take place (because of rwnd or cwnd limitations, or for any other reason). However, in the base protocol, if SCTP has sent the first transmission before the lifetime expires, then the message MUST be sent as a normal reliable message. During episodes of congestion this is particularly unfortunate, as retransmission wastes bandwidth that could have been used for other (non-lifetime expired) messages.
在基本SCTP协议中，使用生存期参数来避免发送过时数据。当指示特定消息的生存期值且该生存期到期时，SCTP取消该消息的发送，并在数据的第一次传输未发生时通知ULP（由于rwnd或cwnd限制，或任何其他原因）。但是，在基本协议中，如果SCTP在生存期到期之前发送了第一次传输，则该消息必须作为正常可靠消息发送。在拥塞期间，这尤其令人遗憾，因为重新传输会浪费本来可以用于其他（非生命周期过期）消息的带宽。
When the "timed reliability" service is invoked, this latter restriction is removed. Specifically, when the "timed reliability" service is in effect, the following rules govern all messages that are sent with a lifetime parameter:
调用“定时可靠性”服务时，后一个限制将被删除。具体而言，当“定时可靠性”服务生效时，以下规则适用于使用生存期参数发送的所有消息：
TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE (or unspecified see Section 5), that message is treated as a normal reliable SCTP message, just as in the base SCTP protocol.
TR1）如果消息的生存期参数为SCTP_lifety_RELIABLE（或未指定，请参见第5节），则该消息将被视为正常可靠的SCTP消息，就像在基本SCTP协议中一样。
TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see Section 5), then the SCTP sender MUST treat the message just as if it were a normal reliable SCTP message, as long as the lifetime has not yet expired.
TR2）如果生存期参数不是SCTP_lifety_RELIABLE（参见第5节），则SCTP发送方必须将消息视为正常可靠的SCTP消息，只要生存期尚未过期。
TR3) Before assigning a TSN to any message, the SCTP sender MUST evaluate the lifetime of that message. If it is expired, the SCTP sender MUST NOT assign a TSN to that message, but instead, SHOULD issue a notification to the upper layer and abandon the message.
TR3）在将TSN分配给任何消息之前，SCTP发送方必须评估该消息的生存期。如果过期，SCTP发送方不得将TSN分配给该消息，而是应向上层发出通知并放弃该消息。
TR4) Before transmitting or retransmitting a message for which a TSN is already assigned, the SCTP sender MUST evaluate the lifetime of the message. If the lifetime of the message is expired, the
TR4）在传输或重新传输已分配TSN的消息之前，SCTP发送方必须评估消息的生存期。如果消息的生存期已过期，则
SCTP sender MUST "abandon" the message, as per the rules specified in Section 3.5 marking that TSN as eligible for forward TSN. Note that this meets the requirement G1 defined in Section 4.3. IMPLEMENTATION NOTE: An implementation SHOULD delay TSN assignment as mentioned in RFC 2960 [2] Section 10.1. In such a case, the lifetime parameter should be checked BEFORE assigning a TSN, thus allowing a message to be abandoned without the need to send a FORWARD TSN.
SCTP发送方必须根据第3.5节规定的规则“放弃”该消息，标记该TSN符合转发TSN的条件。注意，这符合第4.3节中定义的G1要求。实施说明：如RFC 2960[2]第10.1节所述，实施应延迟TSN分配。在这种情况下，应在分配TSN之前检查生存期参数，从而允许在不需要发送前向TSN的情况下放弃消息。
TR5) The sending SCTP MAY evaluate the lifetime of messages at anytime. Expired messages that have not been assigned a TSN MAY be handled as per rule TR3. Expired messages that HAVE been assigned a TSN MAY be handled as per rule TR4.
TR5）发送SCTP可以随时评估消息的生存期。未分配TSN的过期邮件可根据规则TR3进行处理。已分配TSN的过期邮件可根据规则TR4进行处理。
TR6) The sending application MUST NOT change the lifetime parameter once the message is passed to the sending SCTP.
TR6）一旦消息传递给发送SCTP，发送应用程序不得更改生存期参数。
Implementation Note: Rules TR1 through TR4 are designed in such a way as to avoid requiring the implementer to maintain a separate timer for each message; instead, the lifetime need only be evaluated at points in the life of the message where actions are already being taken, such as TSN assignment, transmission, or expiration of a retransmission timeout. Rule TR5 is intended to give the SCTP implementor flexibility to evaluate lifetime at any other convenient opportunity, WITHOUT requiring that lifetime be evaluated immediately at the point in time where it expires.
实施说明：规则TR1到TR4的设计避免了要求实施者为每条消息维护一个单独的计时器；相反，只需在消息生命周期中已采取操作（例如TSN分配、传输或重传超时过期）的时间点评估生命周期。规则TR5旨在为SCTP实施者提供在任何其他方便的时机评估生存期的灵活性，而不要求在生存期到期时立即评估生存期。
An upper layer protocol (ULP) that uses PR-SCTP may need to know whether PR-SCTP can be supported on a given association. Therefore, the ULP needs to have some indication of whether the FORWARD-TSN chunk is supported by its peer.
使用PR-SCTP的上层协议（ULP）可能需要知道给定关联是否支持PR-SCTP。因此，ULP需要对其对等方是否支持FORWARD-TSN块有一些指示。
Section 10.1 of RFC 2960 [2] describes abstract primitives for the ULP-to-SCTP interface, while noting that "individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls."
RFC 2960[2]的第10.1节描述了ULP到SCTP接口的抽象原语，同时指出“各个实现必须定义自己的精确格式，并且可以在单个调用中提供基本函数的组合或子集。”
In this section, we describe one additional return value that may be added to the ASSOCIATE primitive to allow an SCTP service user to indicate whether the FORWARD-TSN chunk is supported by its peer.
在本节中，我们将描述一个附加的返回值，该值可以添加到ASSOCIATE原语中，以允许SCTP服务用户指示FORWARD-TSN区块是否受其对等方的支持。
RFC 2960 indicates that the ASSOCIATE primitive "allows the upper layer to initiate an association to a specific peer endpoint". It is structured as follows:
RFC 2960表示关联原语“允许上层发起到特定对等端点的关联”。其结构如下：
Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]
格式：关联（本地SCTP实例名称、目标传输地址、出站流计数）->关联id[，目标传输地址列表][，出站流计数]
This extension adds one new OPTIONAL return value, such that the new primitive reads as follows:
此扩展添加一个新的可选返回值，这样新原语的内容如下：
Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count ) -> association id [,destination transport addr list] [,outbound stream count] [,forward tsn supported]
格式：关联（本地SCTP实例名称、目标传输地址、出站流计数）->关联id[，目标传输地址列表][，出站流计数][，支持转发tsn]
NOTE: As per RFC 2960, if the ASSOCIATE primitive is implemented as a non-blocking call, the new OPTIONAL return value shall be passed with the association parameters using the COMMUNICATION UP notification.
注：根据RFC 2960，如果ASSOCIATE原语作为非阻塞调用实现，则新的可选返回值应使用COMMUNICATION UP通知与关联参数一起传递。
The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
新的可选参数“forward tsn supported”是一个布尔标志：
(0) false [default] indicates that FORWARD TSN is not enabled by both endpoints.
(0) false[默认值]表示两个端点都未启用前向TSN。
(1) true indicates that FORWARD TSN is enabled on both endpoints.
(1) true表示在两个端点上都启用了前向TSN。
We also add a new primitive to allow the user application to enable/ disable the PR-SCTP service on its endpoint before an association is established.
我们还添加了一个新的原语，允许用户应用程序在建立关联之前在其端点上启用/禁用PR-SCTP服务。
Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable)
格式：ENABLE_PRSCTP（本地SCTP实例名称，布尔启用）
The boolean parameter enable, if set to true, will enable PR-SCTP upon future endpoint associations. If the boolean parameter is set to false, then the local endpoint will not advertise support of PR-SCTP and thus disable the feature on future associations. It is recommended that this option be disabled by default, i.e., in order to enable PR-SCTP, the user will need to call this API option with the enable flag set to "true".
布尔参数enable如果设置为true，将在将来端点关联时启用PR-SCTP。如果布尔参数设置为false，则本地端点将不会公布对PR-SCTP的支持，从而在将来的关联中禁用该功能。建议在默认情况下禁用此选项，即为了启用PR-SCTP，用户需要在启用标志设置为“true”的情况下调用此API选项。
Other PR-SCTP services may be defined and implemented as dictated by the needs of upper layer protocols. If such upper layer protocols are to be standardized and require some particular PR-SCTP service other than the one defined in this document (i.e., "timed reliability"), then those additional PR-SCTP services should also be specified and standardized in a new RFC.
其他PR-SCTP服务可以根据上层协议的需要来定义和实现。如果此类上层协议需要标准化，并且需要一些特定的PR-SCTP服务，而不是本文件中定义的服务（即“定时可靠性”），则这些额外的PR-SCTP服务也应在新的RFC中指定和标准化。
It is suggested that any such additional service definitions be modeled after the contents of Section 4.1. In particular, the service definition should provide:
建议按照第4.1节的内容对任何此类附加服务定义进行建模。特别是，服务定义应提供：
1. A description of how the service user specifies any parameters that need to be associated with a particular message (and/or any other communication that takes place between the application and the SCTP transport sender) that provides the SCTP transport sender with the information needed to determine when to give up on transmission of a particular message.
1. 服务用户如何指定需要与特定消息（和/或应用程序与SCTP传输发送方之间发生的任何其他通信）关联的任何参数的说明这为SCTP传输发送方提供了确定何时放弃特定消息传输所需的信息。
Preferably, this description should reference the primitives in the abstract API provided in Section 10 of RFC 2960 [2], indicating any:
优选地，该描述应参考RFC 2960[2]第10节中提供的抽象API中的原语，指出任何：
* changes to the interpretation of the existing parameters of existing primitives,
* 对现有原语的现有参数解释的更改，
* additional parameters to be added to existing primitives (these should be OPTIONAL, and default values should be indicated),
* 要添加到现有基本体的其他参数（这些参数应为可选参数，并应指示默认值），
* additional primitives that may be needed.
* 可能需要的其他原语。
2. A description of the rules used by the sender side implementation to determine when to give up on messages that have not yet been assigned a TSN. This description should also indicate what protocol events trigger the evaluation, and what actions to take (e.g., notifications.)
2. 发送方端实现用于确定何时放弃尚未分配TSN的邮件的规则说明。该说明还应说明触发评估的协议事件以及要采取的措施（例如通知）
3. A description of the rules used by the sender side implementation to determine when to give up on the transmission or retransmission of messages that have already been assigned a TSN, and may have been transmitted and possibly retransmitted zero or more times.
3. 对发送方实现使用的规则的描述，用于确定何时放弃已分配TSN的消息的传输或重新传输，并且可能已经传输并且可能重新传输了零次或多次。
Items (2) and (3) in the list above should also indicate what protocol events trigger the evaluation, and what actions to take if the determination is made that the sender should give up on transmitting the message (e.g., notifications to the ULP.)
上述列表中的第（2）项和第（3）项还应说明触发评估的协议事件，以及如果确定发送方应放弃发送消息（例如，向ULP发送通知），应采取的措施
Note that in any PR-SCTP service, the following rule MUST be specified to avoid a protocol deadlock:
请注意，在任何PR-SCTP服务中，必须指定以下规则以避免协议死锁：
(G1) When the sender side implementation gives up on transmitting a message that has been assigned a TSN (i.e., when that message is "abandoned", as defined in Section 3.4), the sender side MUST mark that TSN as eligible for forward TSN, and the rules in Section 3.4 regarding the sending of FORWARD TSN chunks MUST be followed.
（G1）当发送方实现放弃发送已分配TSN的消息时（即，如第3.4节所定义，当该消息被“放弃”时），发送方必须将该TSN标记为符合转发TSN的条件，并且必须遵守第3.4节中关于发送转发TSN块的规则。
Finally, a PR-SCTP service definition should specify a "canonical service name" to uniquely identify the service, and distinguish it from other PR-SCTP services. This name can then be used in upper layer protocol standards to indicate which PR-SCTP service definition is required by that upper layer protocol. It can also be used in the documentation of APIs of PR-SCTP implementations to indicate how an upper layer indicates which definition of PR-SCTP service should apply. The canonical service name for the PR-SCTP service defined in Section 4.1 is "timed reliability".
最后，PR-SCTP服务定义应指定一个“规范服务名称”，以唯一标识该服务，并将其与其他PR-SCTP服务区分开来。然后，可以在上层协议标准中使用该名称，以指示该上层协议需要哪个PR-SCTP服务定义。它还可以用于PR-SCTP实现的API文档中，以指示上层如何指示应该应用PR-SCTP服务的定义。第4.1节中定义的PR-SCTP服务的规范服务名称为“定时可靠性”。
Detecting missing data in a PR-SCTP stream is useful for some applications (e.g., Fibre channel or SCSI over IP). With PR-SCTP, this becomes possible - the upper layer simply needs to examine the stream sequence number of the arrived user messages of that stream to detect any missing data. Note, this detection only works when all the messages on that stream are sent in order, i.e., the "U" bit is not set.
检测PR-SCTP流中丢失的数据对于某些应用程序（例如，光纤通道或IP上的SCSI）非常有用。使用PR-SCTP，这成为可能-上层只需检查该流的到达用户消息的流序列号，以检测任何丢失的数据。注意，此检测仅在该流上的所有消息按顺序发送时有效，即未设置“U”位。
This section defines variables used throughout this document:
本节定义了本文件中使用的变量：
SCTP_LIFETIME_RELIABLE - A user interface indication defined by an implementation and used to indicate when a message is to be considered fully reliable.
SCTP_LIFETIME_RELIABLE—由实现定义的用户界面指示，用于指示消息何时被视为完全可靠。
The authors would like to thank Brian Bidulock, Scott Bradner, Jon Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias Rodriguez, Ian Rytina, Chip Sharp, and others for their comments.
作者要感谢Brian Bidulock、Scott Bradner、Jon Berger、Armando L.Caro Jr、John Loughney、Jon Peterson、Ivan Arias Rodriguez、Ian Rytina、Chip Sharp和其他人的评论。
This document does not introduce any new security concerns to SCTP other than the ones already documented in RFC 2960 [2]. In particular, this document shares the same security issues as unordered data within RFC 2960 [2] identified by RFC 3436 [4]. An application using the PR-SCTP extension should not use transport layer security; further details can be found in RFC 3436 [4].
除RFC 2960[2]中已经记录的安全问题外，本文件未向SCTP引入任何新的安全问题。特别是，本文档与RFC 3436[4]确定的RFC 2960[2]中的无序数据具有相同的安全问题。使用PR-SCTP扩展的应用程序不应使用传输层安全性；有关更多详细信息，请参见RFC 3436[4]。
Note that the ability to cause a message to be skipped (i.e, the FORWARD TSN chunk) does not provide any new attack for a Man-In-the-Middle (MIM), since the MIM already is capable of changing and/or withholding data, thus effectively skipping messages. However, the FORWARD TSN chunk does provide a mechanism to make it easier for a
请注意，导致跳过消息（即，前向TSN块）的能力不会为中间人（MIM）提供任何新的攻击，因为MIM已经能够更改和/或保留数据，从而有效地跳过消息。然而，FORWARD TSN区块确实提供了一种机制，使
MIM to skip selective messages when the application has this feature enabled since the MIM would have less state to maintain.
当应用程序启用此功能时，MIM将跳过选择性消息，因为MIM需要维护的状态较少。
IANA has assigned 192 as a new chunk type to SCTP.
IANA已将192指定为SCTP的新块类型。
IANA has assigned 49152 as a new parameter type code to SCTP.
IANA已将49152指定为SCTP的新参数类型代码。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] 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.
[2] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[3] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, September 1990.
[3] Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”，SIGCOMM 1990，第200-208页，1990年9月。
[4] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[4] Jungmaier，A.，Rescorla，E.和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA
Randall R.Stewart Cisco Systems，Inc.美国伊利诺伊州芝加哥市西希金斯路8725号300室，邮编60631
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Michael A. Ramalho Cisco Systems, Inc. 1802 Rue de la Porte Wall Township, NJ 07719-3784 USA
Michael A.Ramalho Cisco Systems，Inc.美国新泽西州沃尔镇拉门街1802号，邮编：07719-3784
Phone: +1.732.449.5762
EMail: mramalho@cisco.com
Phone: +1.732.449.5762
EMail: mramalho@cisco.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA
谢乔平摩托罗拉公司，美国伊利诺伊州阿灵顿高地2309号舒尔大道西1501号，邮编60004
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen应用科学大学Muenster Stegerwaldstr。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Phillip T. Conrad University of Delaware Department of Computer and Information Sciences Newark, DE 19716 USA
菲利浦·T·康拉德德拉瓦大学计算机与信息科学系纽瓦克，美国19716
Phone: +1 302 831 8622
EMail: conrad@acm.org
URI: http://www.cis.udel.edu/~pconrad
Phone: +1 302 831 8622
EMail: conrad@acm.org
URI: http://www.cis.udel.edu/~pconrad
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。