Internet Engineering Task Force (IETF) X. Fu
Request for Comments: 6084 C. Dickmann
Category: Experimental University of Goettingen
ISSN: 2070-1721 J. Crowcroft
University of Cambridge
January 2011
Internet Engineering Task Force (IETF) X. Fu
Request for Comments: 6084 C. Dickmann
Category: Experimental University of Goettingen
ISSN: 2070-1721 J. Crowcroft
University of Cambridge
January 2011
General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)
基于流控制传输协议（SCTP）和数据报传输层安全（DTLS）的通用互联网信令传输（GIST）
Abstract
摘要
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).
通用Internet信令传输（GIST）协议目前使用TCP或TCP上的传输层安全（TLS）进行连接模式操作。本文档描述了GIST在流控制传输协议（SCTP）和数据报传输层安全性（DTLS）上的使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6084.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6084.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Association Setup . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multihoming Support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming Support in SCTP . . . . . . . . . . . . . . . . 8
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Association Setup . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multihoming Support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming Support in SCTP . . . . . . . . . . . . . . . . 8
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document describes the usage of the General Internet Signaling Transport (GIST) protocol [1] and Datagram Transport Layer Security (DTLS) [2].
本文档描述了通用互联网信令传输（GIST）协议[1]和数据报传输层安全性（DTLS）[2]的使用。
GIST, in its initial specification for Connection mode (C-mode) operation, runs on top of a byte-stream-oriented transport protocol providing a reliable, in-sequence delivery, i.e., using the Transmission Control Protocol (TCP) [9] for signaling message transport. However, some Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] context information has a definite lifetime; therefore, the GIST transport protocol could benefit from flexible retransmission, so stale NSLP messages that are held up by congestion can be dropped. Together with the head-of-line blocking and multihoming issues with TCP, these considerations argue that implementations of GIST should support SCTP as an optional transport protocol for GIST. Like TCP, SCTP supports reliability, congestion control, and fragmentation. Unlike TCP, SCTP provides a number of functions that are desirable for signaling transport, such as multiple streams and multiple IP addresses for path failure recovery. Furthermore, SCTP offers an advantage of message-oriented transport instead of using the byte-stream-oriented TCP where the framing mechanisms must be provided separately. In addition, its Partial Reliability extension (PR-SCTP) [3] supports partial retransmission based on a programmable retransmission timer. Furthermore, DTLS provides a viable solution for securing SCTP [4], which allows SCTP to use almost all of its transport features and its extensions.
GIST在其连接模式（C模式）操作的初始规范中，运行在面向字节流的传输协议之上，提供可靠的顺序传递，即使用传输控制协议（TCP）[9]进行信令消息传输。然而，信令（NSIS）信令层协议（NSLP）[10]中的一些后续步骤上下文信息具有确定的生存期；因此，GIST传输协议可以受益于灵活的重传，因此可以丢弃因拥塞而阻塞的陈旧NSLP消息。再加上TCP的线路阻塞和多宿问题，这些考虑因素认为GIST的实现应该支持SCTP作为GIST的可选传输协议。与TCP一样，SCTP支持可靠性、拥塞控制和分段。与TCP不同，SCTP提供了许多信令传输所需的功能，例如用于路径故障恢复的多个流和多个IP地址。此外，SCTP提供了面向消息的传输的优势，而不是使用面向字节流的TCP，在这种TCP中必须单独提供成帧机制。此外，其部分可靠性扩展（PR-SCTP）[3]支持基于可编程重传定时器的部分重传。此外，DTLS为保护SCTP提供了一个可行的解决方案[4]，它允许SCTP使用几乎所有的传输功能及其扩展。
This document defines the use of SCTP as the underlying transport protocol for GIST and the use of DTLS as a security mechanism for protecting GIST Messaging Associations and discusses the implications on GIST state maintenance and API between GIST and NSLPs. Furthermore, this document describes how GIST is transported over SCTP and used by NSLPs in order to exploit the additional capabilities offered by SCTP to deliver GIST C-mode messages more effectively. More specifically:
本文档定义了使用SCTP作为GIST的底层传输协议，以及使用DTL作为保护GIST消息关联的安全机制，并讨论了GIST和NSLP之间GIST状态维护和API的含义。此外，本文档还描述了如何通过SCTP传输GIST，并由NSLP使用，以便利用SCTP提供的附加功能更有效地传递GIST C模式消息。更具体地说：
o How to use the multiple streams feature of SCTP.
o 如何使用SCTP的多流功能。
o How to use the PR-SCTP extension of SCTP.
o 如何使用SCTP的PR-SCTP扩展。
o How to take advantage of the multihoming support of SCTP.
o 如何利用SCTP的多主支持。
GIST over SCTP as described in this document does not require any changes to the high-level operation and structure of GIST. However, adding new transport options requires additional interface code and configuration support to allow applications to exploit the additional
本文件中所述的SCTP上的GIST不需要对GIST的高级操作和结构进行任何更改。但是，添加新的传输选项需要额外的接口代码和配置支持，以允许应用程序利用额外的传输选项
transport when appropriate. In addition, SCTP implementations to transport GIST MUST support the optional feature of fragmentation of SCTP user messages.
适当时运输。此外，传输GIST的SCTP实现必须支持SCTP用户消息分段的可选功能。
Additionally, this document also specifies how to establish GIST security using DTLS for use in combination with, e.g., SCTP and UDP.
此外，本文档还规定了如何使用DTL建立GIST安全性，以便与SCTP和UDP等结合使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [5]. Other terminologies and abbreviations used in this document are taken from related specifications ([1], [2], [3], [6]):
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[5]中所述进行解释。本文件中使用的其他术语和缩写取自相关规范（[1]、[2]、[3]、[6]）：
o SCTP - Stream Control Transmission Protocol
o 流控制传输协议
o PR-SCTP - SCTP Partial Reliability Extension
o PR-SCTP-SCTP部分可靠性扩展
o MRM - Message Routing Method
o 消息路由方法
o MRI - Message Routing Information
o MRI-消息路由信息
o SCD - Stack-Configuration-Data
o SCD-堆栈配置数据
o Messaging Association (MA) - A single connection between two explicitly identified GIST adjacent peers, i.e., between a given signaling source and destination address. A messaging association may use a transport protocol; if security protection is required, it may use a specific network layer security association, or use a transport layer security association internally. A messaging association is bidirectional: signaling messages can be sent over it in either direction, referring to flows of either direction.
o 消息关联（MA）-两个明确标识的相邻对等方之间的单个连接，即给定信令源和目标地址之间的连接。消息传递关联可以使用传输协议；如果需要安全保护，它可以使用特定的网络层安全关联，或者在内部使用传输层安全关联。消息关联是双向的：信令消息可以通过它向任一方向发送，指向任一方向的流。
o SCTP Association - A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.
o SCTP关联—SCTP端点之间的协议关系，由两个SCTP端点和协议状态信息组成。关联可以由关联中端点使用的传输地址唯一标识。在任何给定时间，两个SCTP端点之间不得有多个SCTP关联。
o Stream - A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.
o 流-从一个关联的SCTP端点到另一个关联的SCTP端点建立的单向逻辑通道，在该通道中，除提交给无序传递服务的用户消息外，所有用户消息均按顺序传递。
This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for using SCTP as the GIST transport protocol. The use of DTLS in GIST is defined in Section 7.
本节定义了一种新的MA协议ID类型“Forwards SCTP”，用于将SCTP用作GIST传输协议。GIST中DTL的使用定义见第7节。
The basic GIST protocol specification defines two possible protocols to be used in Messaging Associations, namely Forwards-TCP and TLS. This information is a main part of the Stack Configuration Data (SCD) [1]. This section adds Forwards-SCTP (value 3) as another possible protocol option. In Forwards-SCTP, analog to Forwards-TCP, connections between peers are opened in the forwards direction, from the querying node, towards the responder.
基本GIST协议规范定义了两种可能用于消息关联的协议，即转发TCP和TLS。此信息是堆栈配置数据（SCD）[1]的主要部分。本节添加转发SCTP（值3）作为另一个可能的协议选项。在Forwards-SCTP（类似于Forwards-TCP）中，对等方之间的连接在从查询节点到响应方的转发方向上打开。
The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP between peers. Support for this protocol is OPTIONAL. If this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object. The MA-protocol-options field formats are:
MA协议ID“转发SCTP”表示对等方之间SCTP的基本使用。对该协议的支持是可选的。如果提供了此协议，则MA协议选项数据也必须携带在SCD对象中。MA协议选项字段格式为：
o in a Query: no information apart from the field header.
o 在查询中：除字段标题外，没有其他信息。
o in a Response: 2-byte port number at which the connection will be accepted, followed by 2 pad bytes.
o 在响应中：接受连接的2字节端口号，后跟2个pad字节。
The connection is opened in the forwards direction, from the querying node towards the responder. The querying node MAY use any source address and source port. The destination for establishing the message association MUST be derived from information in the Response: the address from the interface-address in the Network-Layer-Information object and the port from the SCD object as described above.
从查询节点到响应者的正向连接被打开。查询节点可以使用任何源地址和源端口。建立消息关联的目的地必须来自响应中的信息：如上所述，来自网络层信息对象中接口地址的地址和来自SCD对象的端口。
Associations using Forwards-SCTP can carry messages with the transfer attribute Reliable=True. If an error occurs on the SCTP connection such as a reset, as can be reported by an SCTP socket API notification [11], GIST MUST report this to NSLPs as discussed in Section 4.1.2 of [1]. For the multihoming scenario, when a destination address of a GIST-over-SCTP peer encounters a change, the SCTP API will notify GIST about the availability of different SCTP endpoint addresses and the possible change of the primary path.
使用转发SCTP的关联可以携带传输属性为Reliable=True的消息。如果SCTP连接上发生错误，如重置，如SCTP套接字API通知[11]所述，GIST必须向NSLP报告，如[1]第4.1.2节所述。对于多主场景，当SCTP对等方上GIST的目标地址发生更改时，SCTP API将通知GIST不同SCTP端点地址的可用性以及主路径的可能更改。
As SCTP provides additional functionality over TCP, this section discusses the implications of using GIST over SCTP on GIST state maintenance.
由于SCTP通过TCP提供了额外的功能，本节将讨论在SCTP上使用GIST对GIST状态维护的影响。
While SCTP defines unidirectional streams, for the purpose of this document, the concept of a bidirectional stream is used. Implementations MUST establish both downstream and upstream (unidirectional) SCTP streams and use the same stream identifier in both directions. Thus, the two unidirectional streams (in opposite directions) form a bidirectional stream.
虽然SCTP定义了单向流，但为了本文档的目的，使用了双向流的概念。实现必须同时建立下游和上游（单向）SCTP流，并在两个方向上使用相同的流标识符。因此，两个单向流（方向相反）形成双向流。
Due to the multi-streaming support of SCTP, it is possible to use different SCTP streams for different resources (e.g., different NSLP sessions), rather than maintaining all messages along the same transport connection/association in a correlated fashion as TCP (which imposes strict (re)ordering and reliability per transport level). However, there are limitations to the use of multi-streaming. When an SCTP implementation is used for GIST transport, all GIST messages for a particular session MUST be sent over the same SCTP stream to assure the NSLP assumption of in-order delivery. Multiple sessions MAY share the same SCTP stream based on local policy.
由于SCTP的多流支持，可以为不同的资源（例如，不同的NSLP会话）使用不同的SCTP流，而不是以与TCP相关的方式维护同一传输连接/关联上的所有消息（这对每个传输级别施加了严格的（重新）排序和可靠性）。但是，多流的使用存在限制。当SCTP实现用于GIST传输时，特定会话的所有GIST消息必须通过相同的SCTP流发送，以确保NSLP假定按顺序传递。基于本地策略，多个会话可以共享相同的SCTP流。
The GIST concept of Messaging Association re-use is not affected by this document or the use of SCTP. All rules defined in the GIST specification remain valid in the context of GIST over SCTP.
消息关联重用的要点概念不受本文档或SCTP使用的影响。GIST规范中定义的所有规则在GIST over SCTP的上下文中仍然有效。
A variant of SCTP, PR-SCTP [3] provides a "timed reliability" service, which would be particularly useful for delivering GIST Connection mode messages. It 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. Because of the chunk bundling function of SCTP, reliable and partially reliable messages can be multiplexed over a single PR-SCTP association. Therefore, an SCTP implementation for GIST transport SHOULD attempt to establish a PR-SCTP association using "timed reliability" service instead of a standard SCTP association, if available, to support more flexible transport features for potential needs of different NSLPs.
作为SCTP的一种变体，PR-SCTP[3]提供了“定时可靠性”服务，这对于传递GIST连接模式消息特别有用。它允许用户在每条消息的基础上指定规则，这些规则控制传输服务在尝试将消息发送给接收方时的持久性。由于SCTP的区块绑定功能，可靠和部分可靠的消息可以通过单个PR-SCTP关联进行多路复用。因此，GIST传输的SCTP实现应尝试使用“定时可靠性”服务建立PR-SCTP关联，而不是标准SCTP关联（如果可用），以支持更灵活的传输功能，满足不同NSLP的潜在需求。
When using a normally reliable session (as opposed to a partially reliable session), if a node 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. The "timed reliability" service in PR-SCTP eliminates this issue and is hence RECOMMENDED to be used for GIST over PR-SCTP.
特别不幸的是，重新传输浪费了本来可以用于其他（非生命周期过期）消息的带宽。PR-SCTP中的“定时可靠性”服务消除了这一问题，因此建议将其用于GIST over PR-SCTP。
The GIST specification defines an abstract API between GIST and NSLPs. While this document does not change the API itself, the semantics of some parameters have slightly different interpretations in the context of SCTP. This section only lists those primitives and parameters that need special consideration when used in the context of SCTP. The relevant primitives from [1] are as follows:
GIST规范定义了GIST和NSLP之间的抽象API。虽然本文档没有更改API本身，但在SCTP上下文中，某些参数的语义有稍微不同的解释。本节仅列出在SCTP上下文中使用时需要特别考虑的原语和参数。[1]中的相关原语如下：
o The Timeout parameter in API "SendMessage": According to [1], this parameter represents the "length of time GIST should attempt to send this message before indicating an error". When used with PR-SCTP, this parameter is used as the timeout for the "timed reliability" service of PR-SCTP.
o API“SendMessage”中的超时参数：根据[1]，此参数表示“GIST在指示错误之前尝试发送此消息的时间长度”。当与PR-SCTP一起使用时，此参数用作PR-SCTP“定时可靠性”服务的超时。
o "NetworkNotification": According to [1], this primitive "is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred". Here, if SCTP detects a failure of the primary path, GIST SHOULD also indicate this event to the NSLP by calling this primitive with Network-Notification-Type "Routing Status Change". This notification should be done even if SCTP was able to retain an open connection to the peer due to its multihoming capabilities.
o “网络通知”：根据[1]，此原语“从GIST传递到信令应用程序。它表示发生了信令应用程序可能感兴趣的网络事件”。这里，如果SCTP检测到主路径故障，GIST还应通过调用此具有网络通知类型“路由状态更改”的原语向NSLP指示此事件。即使SCTP由于其多主功能而能够保持与对等机的开放连接，也应发出此通知。
This section provides the bit-level format for the MA-protocol-options field that is used for SCTP protocol in the Stack-Configuration-Data object of GIST.
本节提供用于GIST堆栈配置数据对象中SCTP协议的MA协议选项字段的位级格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCTP port number = Port number at which the responder will accept SCTP connections
SCTP端口号=响应程序将接受SCTP连接的端口号
The SCTP port number is only supplied if sent by the responder.
SCTP端口号仅在响应程序发送时提供。
In general, the multihoming support of SCTP can be used to improve fault-tolerance in case of a path or link failure. Thus, GIST over SCTP would be able to deliver NSLP messages between peers even if the primary path is not working anymore. However, for the Message Routing Methods (MRMs) defined in the basic GIST specification, such a feature is only of limited use. The default MRM is path-coupled, which means that if the primary path is failing for the SCTP association, it most likely is also failing for the IP traffic that is signaled for. Thus, GIST would need to perform a refresh to the NSIS nodes to the alternative path anyway to cope with the route change. When the two endpoints of a multihomed SCTP association (but none of the intermediate nodes between them) support NSIS, GIST over SCTP provides a robust means for GIST to deliver NSLP messages even when the primary path fails but at least one alternative path between these (NSIS-enabled) endpoints of the multihomed path is available. Additionally, the use of the multihoming support of SCTP provides GIST and the NSLP with another source to detect route changes. Furthermore, for the time between detection of the route change and recovering from it, the alternative path offered by SCTP can be used by the NSLP to make the transition more smoothly. Finally, future MRMs might have different properties and therefore benefit from multihoming more broadly.
一般来说，SCTP的多宿支持可用于在路径或链路故障的情况下提高容错能力。因此，GIST over SCTP将能够在对等方之间传递NSLP消息，即使主路径不再工作。然而，对于在基本GIST规范中定义的消息路由方法（MRM），这种特性的用途有限。默认的MRM是路径耦合的，这意味着如果SCTP关联的主路径出现故障，那么它很可能也会导致发送信号的IP流量出现故障。因此，GIST需要对NSIS节点执行刷新，以适应路由变化。当多宿SCTP关联的两个端点（但它们之间没有中间节点）支持NSI时，GIST over SCTP为GIST提供了一种可靠的方法，即使主路径失败，但多宿路径的这些（启用NSI的）端点之间至少有一条备用路径可用时，GIST也可以传递NSLP消息。此外，使用SCTP的多宿支持为GIST和NSLP提供了另一个源来检测路由变化。此外，对于检测到路由变化和从中恢复之间的时间，NSLP可以使用SCTP提供的替代路径，以使转换更加平滑。最后，未来的MRM可能具有不同的属性，因此更广泛地受益于多归宿。
Streaming support in SCTP is advantageous for GIST. It allows better parallel processing, in particular by avoiding the head-of-line blocking issue in TCP. Since a single GIST MA may be reused by multiple sessions, using TCP as the transport for GIST signaling messages belonging to different sessions may be blocked if another message is dropped. In the case of SCTP, this can be avoided, as different sessions having different requirements can belong to different streams; thus, a message loss or reordering in a stream will only affect the delivery of messages within that particular stream, and not any other streams.
SCTP中的流式支持有利于GIST。它允许更好的并行处理，特别是通过避免TCP中的行首阻塞问题。由于单个GIST MA可被多个会话重用，因此如果丢弃另一条消息，则可能会阻止使用TCP作为属于不同会话的GIST信令消息的传输。在SCTP的情况下，这是可以避免的，因为具有不同需求的不同会话可以属于不同的流；因此，流中的消息丢失或重新排序只会影响该特定流中的消息传递，而不会影响任何其他流。
NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and the GIST extensibility capabilities defined in [12]. This specification does not define NAT traversal procedures for GIST over SCTP, although an approach for SCTP NAT traversal is described in [13].
GIST over SCTP的NAT遍历将遵循[1]的第7.2节和[12]中定义的GIST扩展能力。本规范未定义GIST over SCTP的NAT遍历过程，尽管[13]中描述了SCTP NAT遍历的方法。
This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the use of DTLS in GIST, which denotes a basic use of datagram transport layer channel security, initially in conjunction with GIST over SCTP. It provides server (i.e., GIST transport receiver) authentication and integrity (as long as the NULL ciphersuite is not selected during ciphersuite negotiation), as well as optionally replay protection for control packets. The use of DTLS for securing GIST over SCTP allows GIST to take the advantage of features provided by SCTP and its extensions. The usage of DTLS for GIST over SCTP is similar to TLS for GIST as specified in [1], where a stack-proposal containing both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
本节为GIST中DTL的使用指定了一个新的MA协议ID“DTLS”（值4），它表示数据报传输层信道安全性的基本用途，最初与SCTP上的GIST结合使用。它提供服务器（即GIST传输接收器）身份验证和完整性（只要在密码套件协商期间未选择空密码套件），以及可选的控制数据包重放保护。通过使用DTL在SCTP上保护GIST，GIST可以利用SCTP及其扩展提供的功能。对于SCTP上的GIST，DTL的使用类似于[1]中规定的GIST的TLS，其中在GIST握手阶段，包含SCTP和DTL的MA协议ID的堆栈建议。
The usage of DTLS [2] for securing GIST over datagram transport protocols MUST be implemented and SHOULD be used.
必须实现并使用DTLS[2]来保护数据报传输协议上的GIST。
GIST message associations using DTLS may carry messages with transfer attributes requesting confidentiality or integrity protection. The specific DTLS version will be negotiated within the DTLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to DTLS v1.0 and MUST use the highest protocol version supported by both peers. NULL authentication and integrity ciphers MUST NOT be negotiated for GIST nodes supporting DTLS. For confidentiality ciphers, nodes can negotiate the NULL ciphersuites. The same rules for negotiating TLS ciphersuites as specified in Section 5.7.3 of [1] apply.
使用DTL的GIST消息关联可能携带具有请求机密性或完整性保护的传输属性的消息。特定的DTLS版本将在DTLS层本身内协商，但实现不得协商到DTLS v1.0之前的协议版本，并且必须使用两个对等方支持的最高协议版本。不能为支持DTL的GIST节点协商空身份验证和完整性密码。对于机密性密码，节点可以协商空密码套件。[1]第5.7.3节规定的TLS密码套件协商规则同样适用。
DTLS renegotiation [7] may cause problems for applications such that connection security parameters can change without the application knowing it. Hence, it is RECOMMENDED that renegotiation be disabled for GIST over DTLS.
DTLS重新协商[7]可能会导致应用程序出现问题，例如连接安全参数可能会在应用程序不知情的情况下更改。因此，建议禁用GIST对DTL的重新协商。
No MA-protocol-options field is required for DTLS. The configuration information for the transport protocol over which DTLS is running (e.g., SCTP port number) is provided by the MA-protocol-options for that protocol.
DTL不需要MA协议选项字段。运行DTLS的传输协议的配置信息（例如，SCTP端口号）由该协议的MA协议选项提供。
The security considerations of [1], [6], and [2] apply. Additionally, although [4] does not support replay detection in DTLS over SCTP, the SCTP replay protection mechanisms [6] [8] should be able to protect NSIS messages transported using GIST over (DTLS over) SCTP from replay attacks.
[1]、[6]和[2]中的安全注意事项适用。此外，尽管[4]不支持DTLS over SCTP中的重播检测，但SCTP重播保护机制[6][8]应该能够保护使用GIST over（DTLS over）SCTP传输的NSIS消息免受重播攻击。
According to this specification, IANA has registered the following codepoints (MA-Protocol-IDs) in a registry created by [1]:
根据本规范，IANA已在[1]创建的注册表中注册了以下代码点（MA协议ID）：
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
Note that MA-Protocol-ID "DTLS" is never used alone but always coupled with a transport protocol specified in the stack proposal.
请注意，MA协议ID“DTLS”从未单独使用，而是始终与堆栈方案中指定的传输协议结合使用。
The authors would like to thank John Loughney, Jukka Manner, Magnus Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their helpful suggestions.
作者要感谢约翰·拉夫尼、朱卡·韦德勒、马格努斯·韦斯特隆德、肖恩·特纳、拉尔斯·艾格特、杰弗里·哈泽尔曼、罗伯特·汉考克、安德鲁·麦克唐纳、马丁·斯蒂默林、方春国、扬·德姆特、劳里·柳图、迈克尔·图克森和罗兰·布莱斯提出的有益建议。
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[1] Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[2] Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[3] Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[4] Tuexen，M.，Seggelmann，R.，和E.Rescorla，“流控制传输协议（SCTP）的数据报传输层安全性（DTLS）”，RFC 6083，2011年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[6] Stewart，R.，“流控制传输协议”，RFC 4960，2007年9月。
[7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[7] Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[8] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[8] Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9] 《传输控制协议》，标准7，RFC 793，1981年9月。
[10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[10] Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年6月。
[11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, January 2011.
[11] Stewart，R.，Poon，K.，Tuexen，M.，Yasevich，V.，和P.Lei，“流控制传输协议（SCTP）的套接字API扩展”，正在进行的工作，2011年1月。
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[12] Way，J.，Bless，R.，Loughney，J.，和E.Davies，“使用和扩展NSIS协议系列”，RFC 5978，2010年10月。
[13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, December 2010.
[13] Stewart，R.，Tuexen，M.和I.Ruengeler，“流控制传输协议（SCTP）网络地址转换”，正在进行的工作，2010年12月。
Authors' Addresses
作者地址
Xiaoming Fu University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
格林顿大学计算机科学学院。7戈廷根37077德国
EMail: fu@cs.uni-goettingen.de
EMail: fu@cs.uni-goettingen.de
Christian Dickmann University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
哥丁根大学计算机科学研究所。7戈廷根37077德国
EMail: mail@christian-dickmann.de
EMail: mail@christian-dickmann.de
Jon Crowcroft University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD UK
乔恩Currkft剑桥大学计算机实验室威廉盖茨大厦15 JJ汤姆逊大道剑桥CB3 0FD英国
EMail: jon.crowcroft@cl.cam.ac.uk
EMail: jon.crowcroft@cl.cam.ac.uk