Network Working Group L. Ong
Request for Comments: 3286 Ciena Corporation
Category: Informational J. Yoakum
Nortel Networks
May 2002
Network Working Group L. Ong
Request for Comments: 3286 Ciena Corporation
Category: Informational J. Yoakum
Nortel Networks
May 2002
An Introduction to the Stream Control Transmission Protocol (SCTP)
流控制传输协议（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol.
本文档从较高的层次介绍了流控制传输协议（SCTP）支持的功能。本手册旨在为SCTP作为通用传输协议的潜在用户提供指南。
The Stream Control Transmission Protocol (SCTP) is a new IP transport protocol, existing at an equivalent level with UDP (User Datagram Protocol) and TCP (Transmission Control Protocol), which provide transport layer functions to many Internet applications. SCTP has been approved by the IETF as a Proposed Standard [1]. The error check algorithm has since been modified [2]. Future changes and updates will be reflected in the IETF RFC index.
流控制传输协议（SCTP）是一种新的IP传输协议，与UDP（用户数据报协议）和TCP（传输控制协议）具有同等的地位，为许多Internet应用程序提供传输层功能。SCTP已被IETF批准为拟定标准[1]。此后，对错误检查算法进行了修改[2]。未来的变化和更新将反映在IETF RFC索引中。
Like TCP, SCTP provides a reliable transport service, ensuring that data is transported across the network without error and in sequence. Like TCP, SCTP is a session-oriented mechanism, meaning that a relationship is created between the endpoints of an SCTP association prior to data being transmitted, and this relationship is maintained until all data transmission has been successfully completed.
与TCP一样，SCTP提供了可靠的传输服务，确保数据在网络上传输时无误且按顺序传输。与TCP一样，SCTP是一种面向会话的机制，这意味着在传输数据之前在SCTP关联的端点之间创建一种关系，并且这种关系将一直保持到所有数据传输成功完成为止。
Unlike TCP, SCTP provides a number of functions that are critical for telephony signaling transport, and at the same time can potentially benefit other applications needing transport with additional performance and reliability. The original framework for the SCTP definition is described in [3].
与TCP不同，SCTP提供了许多对电话信令传输至关重要的功能，同时还可以潜在地使需要传输的其他应用程序受益，从而提高性能和可靠性。SCTP定义的原始框架如[3]所述。
SCTP is a unicast protocol, and supports data exchange between exactly 2 endpoints, although these may be represented by multiple IP addresses.
SCTP是一种单播协议，支持正好两个端点之间的数据交换，尽管这些端点可能由多个IP地址表示。
SCTP provides reliable transmission, detecting when data is discarded, reordered, duplicated or corrupted, and retransmitting damaged data as necessary. SCTP transmission is full duplex.
SCTP提供可靠的传输，检测数据何时被丢弃、重新排序、复制或损坏，并根据需要重新传输损坏的数据。SCTP传输是全双工的。
SCTP is message oriented and supports framing of individual message boundaries. In comparison, TCP is byte oriented and does not preserve any implicit structure within a transmitted byte stream without enhancement.
SCTP是面向消息的，支持单个消息边界的框架。相比之下，TCP是面向字节的，在传输的字节流中不保留任何隐式结构而不进行增强。
SCTP is rate adaptive similar to TCP, and will scale back data transfer to the prevailing load conditions in the network. It is designed to behave cooperatively with TCP sessions attempting to use the same bandwidth.
SCTP与TCP类似，是速率自适应的，它将根据网络中的主要负载条件缩减数据传输。它被设计为与试图使用相同带宽的TCP会话协作。
The name Stream Control Transmission Protocol is derived from the multi-streaming function provided by SCTP. This feature allows data to be partitioned into multiple streams that have the property of independently sequenced delivery, so that message loss in any one stream will only initially affect delivery within that stream, and not delivery in other streams.
名称流控制传输协议源自SCTP提供的多流功能。此功能允许将数据划分为具有独立顺序传递特性的多个流，因此任何一个流中的消息丢失最初只会影响该流中的传递，而不会影响其他流中的传递。
In contrast, TCP assumes a single stream of data and ensures that delivery of that stream takes place with byte sequence preservation. While this is desirable for delivery of a file or record, it causes additional delay when message loss or sequence error occurs within the network. When this happens, TCP must delay delivery of data until the correct sequencing is restored, either by receipt of an out-of-sequence message, or by retransmission of a lost message.
相比之下，TCP采用单一数据流，并确保在保留字节序列的情况下交付该数据流。虽然这对于文件或记录的传递是可取的，但当网络中发生消息丢失或序列错误时，它会导致额外的延迟。发生这种情况时，TCP必须延迟数据的传递，直到恢复正确的顺序，或者通过接收无序消息，或者通过重新传输丢失的消息。
For a number of applications, the characteristic of strict sequence preservation is not truly necessary. In telephony signaling, it is only necessary to maintain sequencing of messages that affect the same resource (e.g., the same call, or the same channel). Other messages are only loosely correlated and can be delivered without having to maintain overall sequence integrity.
在许多应用中，严格序列保持的特性并不是真正必要的。在电话信令中，只需要保持影响相同资源（例如，相同呼叫或相同信道）的消息序列。其他消息只是松散关联的，可以在不必维护整体序列完整性的情况下交付。
Another example of possible use of multi-streaming is the delivery of multimedia documents, such as a web page, when done over a single session. Since multimedia documents consist of objects of different sizes and types, multi-streaming allows transport of these components
多流媒体的另一个可能使用示例是在单个会话上完成多媒体文档（如网页）的交付。由于多媒体文档由不同大小和类型的对象组成，因此多流允许传输这些组件
to be partially ordered rather than strictly ordered, and may result in improved user perception of transport.
部分订购而非严格订购，可能会改善用户对运输的感知。
At the same time, transport is done within a single SCTP association, so that all streams are subjected to a common flow and congestion control mechanism, reducing the overhead required at the transport level.
同时，传输是在单个SCTP关联中完成的，因此所有流都受到通用的流和拥塞控制机制的约束，从而减少了传输级别所需的开销。
SCTP accomplishes multi-streaming by creating independence between data transmission and data delivery. In particular, each payload DATA "chunk" in the protocol uses two sets of sequence numbers, a Transmission Sequence Number that governs the transmission of messages and the detection of message loss, and the Stream ID/Stream Sequence Number pair, which is used to determine the sequence of delivery of received data.
SCTP通过在数据传输和数据交付之间建立独立性来实现多流传输。具体地，协议中的每个有效负载数据“块”使用两组序列号，一个控制消息传输和消息丢失检测的传输序列号，以及流ID/流序列号对，其用于确定接收数据的交付顺序。
This independence of mechanisms allows the receiver to determine immediately when a gap in the transmission sequence occurs (e.g., due to message loss), and also whether or not messages received following the gap are within an affected stream. If a message is received within the affected stream, there will be a corresponding gap in the Stream Sequence Number, while messages from other streams will not show a gap. The receiver can therefore continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.
机制的这种独立性允许接收器立即确定传输序列中何时出现间隙（例如，由于消息丢失），以及在间隙之后接收的消息是否在受影响的流中。如果在受影响的流中接收到消息，则流序列号中将存在相应的间隙，而来自其他流的消息将不显示间隙。因此，接收机可以继续向未受影响的流传送消息，同时在受影响的流中缓冲消息，直到发生重传。
Another core feature of SCTP is multi-homing, or the ability for a single SCTP endpoint to support multiple IP addresses. The benefit of multi-homing is potentially greater survivability of the session in the presence of network failures. In a conventional single-homed session, the failure of a local LAN access can isolate the end system, while failures within the core network can cause temporary unavailability of transport until the IP routing protocols can reconverge around the point of failure. Using multi-homed SCTP, redundant LANs can be used to reinforce the local access, while various options are possible in the core network to reduce the dependency of failures for different addresses. Use of addresses with different prefixes can force routing to go through different carriers, for example, route-pinning techniques or even redundant core networks can also be used if there is control over the network architecture and protocols.
SCTP的另一个核心特性是多主，即单个SCTP端点支持多个IP地址的能力。多宿主的好处是，在出现网络故障时，会话的生存能力可能更高。在传统的单宿会话中，本地LAN访问的故障可隔离终端系统，而核心网络内的故障可导致传输暂时不可用，直到IP路由协议可在故障点附近重新聚合。使用多宿SCTP，可以使用冗余LAN来加强本地访问，而在核心网络中可以使用各种选项来减少故障对不同地址的依赖性。使用具有不同前缀的地址可以强制路由通过不同的载体，例如，如果对网络架构和协议有控制权，也可以使用路由固定技术甚至冗余核心网络。
In its current form, SCTP does not do load sharing, that is, multi-homing is used for redundancy purposes only. A single address is chosen as the "primary" address and is used as the destination for all DATA chunks for normal transmission. Retransmitted DATA chunks
在其当前形式中，SCTP不进行负载共享，也就是说，多归属仅用于冗余目的。选择单个地址作为“主”地址，并将其用作所有数据块的目的地，以便正常传输。重传数据块
use the alternate address(es) to improve the probability of reaching the remote endpoint, while continued failure to send to the primary address ultimately results in the decision to transmit all DATA chunks to the alternate until heartbeats can reestablish the reachability of the primary.
使用备用地址来提高到达远程端点的概率，而持续发送到主地址的失败最终导致决定将所有数据块传输到备用地址，直到心跳能够重新建立主地址的可达性。
To support multi-homing, SCTP endpoints exchange lists of addresses during initiation of the association. Each endpoint must be able to receive messages from any of the addresses associated with the remote endpoint; in practice, certain operating systems may utilize available source addresses in round robin fashion, in which case receipt of messages from different source addresses will be the normal case. A single port number is used across the entire address list at an endpoint for a specific session.
为了支持多宿主，SCTP端点在关联启动期间交换地址列表。每个端点必须能够从与远程端点关联的任何地址接收消息；实际上，某些操作系统可能以循环方式利用可用的源地址，在这种情况下，从不同的源地址接收消息将是正常情况。对于特定会话，在端点的整个地址列表中使用单个端口号。
In order to reduce the potential for security issues, it is required that some response messages be sent specifically to the source address in the message that caused the response. For example, when the server receives an INIT chunk from a client to initiate an SCTP association, the server always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT.
为了减少潜在的安全问题，需要将一些响应消息专门发送到引起响应的消息中的源地址。例如，当服务器从客户端接收到INIT块以启动SCTP关联时，服务器总是将响应INIT ACK块发送到INIT的IP头中的源地址。
The SCTP Initiation Procedure relies on a 4-message sequence, where DATA can be included on the 3rd and 4th messages of the sequence, as these messages are sent when the association has already been validated. A "cookie" mechanism has been incorporated into the sequence to guard against some types of denial of service attacks.
SCTP启动程序依赖于4条消息序列，其中数据可包含在序列的第3条和第4条消息中，因为这些消息是在关联已验证时发送的。序列中加入了“cookie”机制，以防止某些类型的拒绝服务攻击。
The "cookie" mechanism guards specifically against a blind attacker generating INIT chunks to try to overload the resources of an SCTP server by causing it to use up memory and resources handling new INIT requests. Rather than allocating memory for a Transmission Control Block (TCB), the server instead creates a Cookie parameter with the TCB information, together with a valid lifetime and a signature for authentication, and sends this back in the INIT ACK. Since the INIT ACK always goes back to the source address of the INIT, the blind attacker will not get the Cookie. A valid SCTP client will get the Cookie and return it in the COOKIE ECHO chunk, where the SCTP server can validate the Cookie and use it to rebuild the TCB. Since the server creates the Cookie, only it needs to know the format and secret key, this is not exchanged with the client.
“cookie”机制专门防止生成INIT块的盲攻击者试图通过使用内存和资源处理新的INIT请求来过载SCTP服务器的资源。服务器不是为传输控制块（TCB）分配内存，而是使用TCB信息、有效生存期和身份验证签名创建一个Cookie参数，并将其发送回INIT ACK。由于INIT ACK始终返回INIT的源地址，因此盲攻击者将无法获取Cookie。有效的SCTP客户端将获取Cookie并将其返回到Cookie回显块中，在该块中，SCTP服务器可以验证Cookie并使用它重建TCB。因为服务器创建Cookie，所以它只需要知道Cookie的格式和密钥，而不需要与客户端交换。
Otherwise, the SCTP Initiation Procedure follows many TCP conventions, so that the endpoints exchange receiver windows, initial sequence numbers, etc. In addition to this, the endpoints may exchange address lists as discussed above, and also mutually confirm the number of streams to be opened on each side.
否则，SCTP启动过程遵循许多TCP约定，以便端点交换接收器窗口、初始序列号等。除此之外，端点可以如上所述交换地址列表，并且还相互确认每侧要打开的流的数量。
Multi-homing adds to the potential that messages will be received out of sequence or with different address pairs. This is a particular concern during initiation of the association, where without procedures for resolving the collision of messages, you may easily end up with multiple parallel associations between the same endpoints. To avoid this, SCTP incorporates a number of procedures to resolve parallel initiation attempts into a single association.
多宿主增加了消息接收顺序错误或使用不同地址对的可能性。在关联启动期间，这是一个特别值得关注的问题，如果没有解决消息冲突的过程，那么很容易在相同端点之间产生多个并行关联。为了避免这种情况，SCTP采用了许多程序将并行启动尝试解析为单个关联。
DATA chunk exchange in SCTP follows TCP's Selective ACK procedure. Receipt of DATA chunks is acknowledged by sending SACK chunks, which indicate not only the cumulative Transmission Sequence Number (TSN) range received, but also any non-cumulative TSNs, implying gaps in the received TSN sequence. Following TCP procedures, SACKs are sent using the "delayed ack" method, normally one SACK per every other received packet, but with an upper limit on the delay between SACKs and an increase to once per received packet when there are gaps detected.
SCTP中的数据块交换遵循TCP的选择性确认过程。通过发送SACK块来确认数据块的接收，SACK块不仅指示接收到的累积传输序列号（TSN）范围，还指示任何非累积TSN，这意味着接收到的TSN序列中存在间隔。在TCP过程之后，使用“延迟确认”方法发送SACK，通常每接收一个数据包发送一个SACK，但SACK之间的延迟有一个上限，当检测到间隙时，每个接收数据包的延迟增加一次。
Flow and Congestion Control follow TCP algorithms. The advertised receive window indicates buffer occupancy at the receiver, while a per-path congestion window is maintained to manage the packets in flight. Slow start, Congestion avoidance, Fast recovery and Fast retransmit are incorporated into the procedures as described in RFC 2581, with the one change being that the endpoints must manage the conversion between bytes sent and received and TSNs sent and received, since TSN is per chunk rather than per byte.
流量和拥塞控制遵循TCP算法。播发的接收窗口指示接收器处的缓冲区占用情况，同时维护每路径拥塞窗口以管理飞行中的数据包。如RFC 2581所述，慢启动、拥塞避免、快速恢复和快速重传被纳入到程序中，其中一个变化是端点必须管理发送和接收的字节与发送和接收的TSN之间的转换，因为TSN是每个块而不是每个字节。
The application can specify a lifetime for data to be transmitted, so that if the lifetime has expired and the data has not yet been transmitted, it can be discarded (e.g., time-sensitive signaling messages). If the data has been transmitted, it must continue to be delivered to avoid creating a hole in the TSN sequence.
应用程序可以指定要传输的数据的生存期，以便如果生存期已过期且数据尚未传输，则可以丢弃它（例如，时间敏感的信令消息）。如果数据已经传输，则必须继续传输，以避免在TSN序列中创建孔。
SCTP Shutdown uses a 3-message procedure to allow graceful shutdown, where each endpoint has confirmation of the DATA chunks received by the remote endpoint prior to completion of the shutdown. An Abort procedure is also provided for error cases when an immediate shutdown must take place.
SCTP Shutdown使用一个3消息过程来允许正常关闭，其中每个端点都在关闭完成之前确认远程端点接收到的数据块。对于必须立即关闭的错误情况，还提供了中止程序。
Note that SCTP does not support the function of a "half-open" connection as can occur in TCP, when one side indicates that it has no more data to send, but the other side can continue to send data indefinitely. SCTP assumes that once the shutdown procedure begins, both sides will stop sending new data across the association, and only need to clear up acknowledgements of previously sent data.
请注意，SCTP不支持TCP中可能出现的“半开放”连接功能，当一方表示没有更多数据要发送时，另一方可以无限期地继续发送数据。SCTP假设一旦关闭过程开始，双方将停止在关联中发送新数据，只需清除先前发送数据的确认。
The SCTP Message includes a common header plus one or more chunks, which can be control or data. The common header has source and destination port numbers to allow multiplexing of different SCTP associations at the same address, a 32-bit verification tag that guards against insertion of an out-of-date or false message into the SCTP association, and a 32-bit checksum (this has been modified to use the CRC-32c polynomial [2]) for error detection.
SCTP消息包括一个公共头加上一个或多个块，这些块可以是控制或数据。公共报头具有源端口号和目标端口号，以允许在同一地址多路复用不同的SCTP关联；32位验证标签，用于防止将过期或错误消息插入SCTP关联；32位校验和（已修改为使用CRC-32c多项式[2]）用于错误检测。
Each chunk includes chunk type, flag field, length and value. Control chunks incorporate different flags and parameters depending on the chunk type. DATA chunks in particular incorporate flags for control of segmentation and reassembly, and parameters for the TSN, Stream ID and Stream Sequence Number, and a Payload Protocol Identifier.
每个区块包括区块类型、标志字段、长度和值。控件块根据块类型包含不同的标志和参数。数据块尤其包含用于控制分段和重新组装的标志，以及用于TSN、流ID和流序列号的参数，以及有效负载协议标识符。
The Payload Protocol ID has been included for future flexibility. It is envisioned that the functions of protocol identification and port number multiplexing will not be as closely linked in the future as they are in current usage. Payload Protocol ID will allow the protocol being carried by SCTP to be identified independent of the port numbers being used.
为了将来的灵活性，已包含有效负载协议ID。可以预见，协议标识和端口号多路复用的功能在未来不会像当前使用的那样紧密相连。有效负载协议ID将允许识别SCTP承载的协议，而与所使用的端口号无关。
The SCTP message format naturally allows support of bundling of multiple DATA and control chunks in a single message, to improve transport efficiency. Use of bundling is controllable by the application, so that bundling of initial transmission can be prohibited. Bundling will naturally occur on retransmission of DATA chunks, to further reduce any chance of congestion.
SCTP消息格式自然允许在单个消息中捆绑多个数据和控制块，以提高传输效率。捆绑的使用由应用程序控制，因此可以禁止初始传输的捆绑。在重新传输数据块时自然会进行捆绑，以进一步减少拥塞的可能性。
Retransmission of DATA chunks occurs from either (a) timeout of the retransmission timer; or (b) receipt of SACKs indicating the DATA chunk has not been received. To reduce the potential for congestion, the rate of retransmission of DATA chunks is limited. The retransmission timeout (RTO) is adjusted based on estimates of the round trip delay and backs off exponentially as message loss increases.
数据块的重新传输从（a）重新传输计时器超时开始；或（b）收到SACK，表明尚未收到数据块。为了减少拥塞的可能性，数据块的重新传输速率是有限的。重传超时（RTO）根据对往返延迟的估计进行调整，并随着消息丢失的增加以指数形式后退。
In an active association with fairly constant DATA transmission, SACKs are more likely to cause retransmission than the timeout. To reduce the chance of an unnecessary retransmission, a 4 SACK rule is used, so that retransmission only occurs on receipt of the 4th SACK that indicates that the chunk is missing. This is intended to avoid retransmits due to normal occurrences such as packets received out of sequence.
在数据传输相当稳定的主动关联中，SACK比超时更有可能导致重新传输。为了减少不必要的重新传输的机会，使用了4 SACK规则，以便仅在接收到第4 SACK时发生重新传输，该SACK指示块丢失。这是为了避免由于正常情况（如数据包接收顺序错误）而导致的重传。
A count is maintained of the number of retransmissions to a particular destination address without successful acknowledgement. When this count exceeds a configured maximum, the address is declared inactive, notification is given to the application, and the SCTP begins to use an alternate address for the sending of DATA chunks.
在未成功确认的情况下，保持对特定目的地地址的重传次数的计数。当此计数超过配置的最大值时，该地址被声明为非活动，通知应用程序，并且SCTP开始使用备用地址发送数据块。
Also, Heartbeat chunks are sent periodically to all idle destinations (i.e., alternate addresses), and a counter is maintained on the number of Heartbeats sent to an inactive destination without receipt of a corresponding Heartbeat Ack. When this counter exceeds a configured maximum, that destination address is also declared inactive.
此外，心跳块会定期发送到所有空闲目的地（即备用地址），并且计数器会保留发送到非活动目的地的心跳数量，而不会收到相应的心跳确认。当此计数器超过配置的最大值时，该目标地址也被声明为非活动。
Heartbeats continue to be sent to inactive destination addresses until an Ack is received, at which point the address can be made active again. The rate of sending Heartbeats is tied to the RTO estimation plus an additional delay parameter that allows Heartbeat traffic to be tailored according to the needs of the user application.
心跳继续发送到非活动的目标地址，直到收到Ack，此时地址可以再次激活。发送心跳的速率与RTO估计加上额外的延迟参数有关，该参数允许根据用户应用程序的需要定制心跳流量。
A count is maintained across all destination addresses on the number of retransmits or Heartbeats sent to the remote endpoint without a successful Ack. When this exceeds a configured maximum, the endpoint is declared unreachable, and the SCTP association is closed.
在没有成功确认的情况下，对发送到远程端点的重传或心跳次数的所有目标地址进行计数。当这超过配置的最大值时，将声明端点不可访问，并关闭SCTP关联。
The specification includes a model of the primitives exchanged between the application and the SCTP layer, intended as informational material rather than a formal API statement. A socket-based API is being defined to simplify migration of TCP or UDP applications to the use of SCTP.
该规范包括应用程序和SCTP层之间交换的原语模型，旨在作为信息材料，而不是正式的API语句。正在定义基于套接字的API，以简化TCP或UDP应用程序向SCTP的迁移。
In addition to the verification tag and cookie mechanisms, SCTP specifies the use of IPSec if strong security and integrity protection is required. The SCTP specification does not itself define any new security protocols or procedures.
除了验证标签和cookie机制外，如果需要强大的安全性和完整性保护，SCTP还指定使用IPSec。SCTP规范本身没有定义任何新的安全协议或过程。
Extensions to IPSec are under discussion to reduce the overhead required to support multi-homing. Also, work is in progress on the use of Transport Layer Security (TLS) over SCTP [4].
正在讨论对IPSec的扩展，以减少支持多宿主所需的开销。此外，在SCTP上使用传输层安全性（TLS）的工作正在进行[4]。
The SCTP format allows new chunk types, flags and parameter fields to be defined as extensions to the protocol. Any extensions must be based on standard agreements within the IETF, as no vendor-specific extensions are supported in the protocol.
SCTP格式允许将新的块类型、标志和参数字段定义为协议的扩展。任何扩展都必须基于IETF内的标准协议，因为协议中不支持特定于供应商的扩展。
Chunk Type values are organized into four ranges to allow extensions to be made with a pre-defined procedure for responding if a new Chunk Type is not recognized at the remote endpoint. Responses include: whole packet discard; packet discard with reporting; ignoring the chunk; ignoring with reporting. Similar pre-defined responses are specified for unrecognized Parameter Type values.
块类型值被组织为四个范围，以允许使用预定义的过程进行扩展，以便在远程端点无法识别新的块类型时进行响应。响应包括：整包丢弃；数据包丢弃与报告；忽略块；忽略报告。为无法识别的参数类型值指定了类似的预定义响应。
Chunk Parameter Type values are in principle independent ranges for each Chunk Type. In practice, the values defined in the SCTP specification have been coordinated so that a particular parameter type will have the same Chunk Parameter Type value across all Chunk Types. Further experience will determine if this alignment needs to be maintained or formalized.
区块参数类型值原则上是每个区块类型的独立范围。在实践中，SCTP规范中定义的值已得到协调，以便特定参数类型在所有区块类型中具有相同的区块参数类型值。进一步的经验将决定是否需要保持或正式确定这种一致性。
[1] 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.
[1] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in Progress.
[2] Stewart，Sharp等人，“SCTP校验和更改”，正在进行的工作。
[3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[3] Ong，L.，Rytina，I.，Garcia，M.，Schwarzbauer，H.，Coene，L.，Lin，H.，Juhasz，I.，Holdrege，M.和C.Sharp，“信号传输的框架架构”，RFC 2719，1999年10月。
[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in Progress.
[4] 荣迈尔、瑞斯科拉和图克森，“超临界流体输送系统的TLS”，工作正在进行中。
Lyndon Ong Ciena Corporation 10480 Ridgeview Drive Cupertino, CA 95014
加利福尼亚州库比蒂诺市里奇维尤大道10480号林登·翁·西纳公司，邮编95014
EMail: lyong@ciena.com
EMail: lyong@ciena.com
John Yoakum Emerging Opportunities Nortel Networks
John Yoakum北电网络的新兴机遇
EMail: yoakum@nortelnetworks.com
EMail: yoakum@nortelnetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。