Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5978 Aalto University
Category: Informational R. Bless
ISSN: 2070-1721 KIT
J. Loughney
Nokia
E. Davies, Ed.
Folly Consulting
October 2010
Internet Engineering Task Force (IETF) J. Manner
Request for Comments: 5978 Aalto University
Category: Informational R. Bless
ISSN: 2070-1721 KIT
J. Loughney
Nokia
E. Davies, Ed.
Folly Consulting
October 2010
Using and Extending the NSIS Protocol Family
使用和扩展NSIS协议系列
Abstract
摘要
This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.
本文件概述了NSIS工作组在2001-2010年期间创建的信令（NSIS）框架和协议套件的后续步骤。它还包括关于行业如何利用新协议以及社区如何利用框架和现有协议的可扩展性来满足未来信令需求的建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are 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/rfc5978.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5978.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3
3. The General Internet Signaling Transport . . . . . . . . . . . 6
4. Quality-of-Service NSLP . . . . . . . . . . . . . . . . . . . 11
5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12
6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13
6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14
6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15
6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15
7. Security Features . . . . . . . . . . . . . . . . . . . . . . 16
8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16
8.1. Overview of Administrative Actions Needed When
Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17
8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Use of Different Message Routing Methods . . . . . . . 18
8.2.2. Use of Different Transport Protocols or Security
Capabilities . . . . . . . . . . . . . . . . . . . . . 18
8.2.3. Use of Alternative Security Services . . . . . . . . . 19
8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 19
8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20
8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20
8.2.7. Defining New Objects To Be Carried in GIST . . . . . . 21
8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21
8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 22
8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23
8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3
3. The General Internet Signaling Transport . . . . . . . . . . . 6
4. Quality-of-Service NSLP . . . . . . . . . . . . . . . . . . . 11
5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12
6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13
6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14
6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15
6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15
7. Security Features . . . . . . . . . . . . . . . . . . . . . . 16
8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16
8.1. Overview of Administrative Actions Needed When
Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17
8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Use of Different Message Routing Methods . . . . . . . 18
8.2.2. Use of Different Transport Protocols or Security
Capabilities . . . . . . . . . . . . . . . . . . . . . 18
8.2.3. Use of Alternative Security Services . . . . . . . . . 19
8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 19
8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20
8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20
8.2.7. Defining New Objects To Be Carried in GIST . . . . . . 21
8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21
8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 22
8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23
8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
The Next Steps in Signaling (NSIS) Working Group was formed in November 2001 to develop an Internet signaling protocol suite that would attempt to remedy some of the perceived shortcomings of solutions based on the Resource ReSerVation Protocol (RSVP), e.g., with respect to mobility and Quality-of-Service (QoS) interoperability. The initial charter was focused on QoS signaling as the first use case, taking RSVP as the background for the work. In May 2003, middlebox traversal was added as an explicit second use case. The requirements for the new generation of signaling protocols are documented in [RFC3726], and an analysis of existing signaling protocols can be found in [RFC4094].
信令下一步（NSIS）工作组于2001年11月成立，旨在开发一套互联网信令协议套件，试图弥补基于资源预留协议（RSVP）的解决方案的一些已知缺陷，例如在移动性和服务质量（QoS）互操作性方面。最初的章程将QoS信令作为第一个用例，以RSVP作为工作背景。2003年5月，添加了middlebox遍历作为第二个明确的用例。新一代信令协议的要求记录在[RFC3726]中，现有信令协议的分析可在[RFC4094]中找到。
The design of NSIS is based on a two-layer model, where a general signaling transport layer provides services to an upper signaling application layer. The design was influenced by Bob Braden's document entitled "A Two-Level Architecture for Internet Signaling" [TWO-LEVEL].
NSIS的设计基于两层模型，其中通用信令传输层向上层信令应用层提供服务。该设计受到了Bob Braden题为“互联网信令的两级体系结构”【两级】的文件的影响。
This document gives an overview of the NSIS framework and protocol suite at the time of writing (2010), provides an introduction to the use cases for which the current version of NSIS was designed, describes how to deploy NSIS in existing networks, and summarizes how the protocol suite can be enhanced to satisfy new use cases.
本文档概述了撰写本文时（2010年）的NSIS框架和协议套件，介绍了NSIS当前版本的设计用例，描述了如何在现有网络中部署NSIS，并总结了如何增强协议套件以满足新的用例。
The design of the NSIS protocol suite reuses ideas and concepts from RSVP but essentially divides the functionality into two layers. The lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge of transporting the higher-layer protocol messages to the next signaling node on the path. This includes discovery of the next-hop NSIS node, which may not be the next routing hop, and different transport and security services depending on the signaling application requirements. The General Internet Signaling Transport (GIST) [RFC5971] has been developed as the protocol that fulfills the role of the NTLP. The NSIS protocol suite supports both IP protocol versions, IPv4 and IPv6.
NSIS协议套件的设计重用了RSVP的思想和概念，但本质上将功能分为两层。下层NSIS传输层协议（NTLP）负责将高层协议消息传输到路径上的下一个信令节点。这包括发现下一跳NSIS节点，该节点可能不是下一个路由跳，以及根据信令应用要求提供不同的传输和安全服务。通用互联网信令传输（GIST）[RFC5971]已开发为履行NTLP角色的协议。NSIS协议套件同时支持IP协议版本IPv4和IPv6。
The actual signaling application logic is implemented in the higher layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). While GIST is only concerned with transporting NSLP messages hop-by-hop between pairs of signaling nodes, the end-to-end signaling functionality is provided by the NSLP protocols if needed. Not all NSLP protocols need to perform end-to-end signaling. The current protocols have features to confine the signaling to a limited part of the path (such as the interior of a domain). Messages transmitted by
实际的信令应用逻辑在NSIS堆栈的更高层NSIS信令层协议（NSLP）中实现。虽然GIST仅涉及在成对的信令节点之间逐跳传输NSLP消息，但如果需要，端到端信令功能由NSLP协议提供。并非所有NSLP协议都需要执行端到端信令。当前的协议具有将信令限制在路径的有限部分（例如域内部）的特性。由
GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID) associated with the NSLP. Two NSLP protocols are currently specified: one concerning Quality-of-Service signaling [RFC5974] and one to enable NAT/firewall traversal [RFC5973].
代表NSLP的GIST由与NSLP关联的唯一NSLP标识符（NSLPID）标识。目前指定了两个NSLP协议：一个涉及服务质量信令[RFC5974]，另一个用于启用NAT/防火墙穿越[RFC5973]。
NSIS is primarily designed to provide the signaling needed to install state on nodes that lie on the path that will be taken by some end-to-end flow of data packets; the state installed should facilitate or enhance some characteristic of the data flow. This is typically achieved by routing signaling messages along the same path (known as "path-coupled signaling") and intercepting the signaling message at NSIS-capable nodes. However, the NSIS architecture is designed to be flexible, and the routing of signaling messages is controlled by the Message Routing Method (MRM) that is applied to the signaling messages. The initial specifications define two MRMs:
NSIS的主要设计目的是提供在节点上安装状态所需的信令，这些节点位于数据包的一些端到端流将采用的路径上；安装的状态应促进或增强数据流的某些特性。这通常是通过沿相同路径路由信令消息（称为“路径耦合信令”）并在支持NSIS的节点处截获信令消息来实现的。然而，NSIS体系结构设计灵活，信令消息的路由由应用于信令消息的消息路由方法（MRM）控制。初始规范定义了两个MRM：
o the basic Path Coupled MRM designed to drive signaling along the path that will be followed by the data flow, and
o 基本路径耦合MRM，设计用于沿数据流所遵循的路径驱动信令，以及
o an alternative Loose End MRM, which is applicable for preconditioning the state in firewalls and Network Address Translation (NAT) middleboxes when data flow destinations lie behind this sort of middlebox. Without preconditioning, these middleboxes will generally reject signaling messages originating outside the region 'protected' by the middlebox and where the destination is located.
o 另一种松端MRM，适用于当数据流目的地位于防火墙和网络地址转换（NAT）中间盒之后时，对其状态进行预处理。在不进行预处理的情况下，这些中间盒通常会拒绝来自中间盒“保护”区域之外以及目的地所在区域的信令消息。
Parameters carried by each signaling message drive the operation of the relevant transport or signaling application. In particular, the messages will carry Message Routing Information (MRI) that will allow the NSIS nodes to identify the data flow to which the signaling applies. Generally, the intercepted messages will be reinjected into the network after processing by the NSIS entities and will be routed further towards the destination, possibly being intercepted by additional NSIS-capable nodes before arriving at the flow endpoint.
每个信令消息携带的参数驱动相关传输或信令应用程序的操作。特别地，消息将携带消息路由信息（MRI），该信息将允许NSIS节点识别信令应用到的数据流。通常，被截获的消息将在NSIS实体处理后重新注入网络，并将进一步路由到目的地，可能在到达流端点之前被其他支持NSIS的节点截获。
As with RSVP, it is expected that the signaling message will make a complete round trip either along the whole end-to-end path or a part of it if the scope of the signaling is limited. This implements a two-phase strategy in which capabilities are assessed and provisional reservations are made on the outbound leg; these provisional reservations are then confirmed and operational state is installed on the return leg. Unlike RSVP, signaling is normally initiated at the source of the data flow, making it easier to ensure that the signaling follows the expected path of the data flow, but can also be receiver initiated as in RSVP.
与RSVP一样，如果信令的范围受到限制，则信令消息将沿着整个端到端路径或其一部分进行完整的往返。这实施了一个两阶段战略，在该战略中，对能力进行评估，并对出站航段进行临时预订；然后确认这些临时保留，并在返回管段上安装操作状态。与RSVP不同，信令通常在数据流的源处启动，这使得更容易确保信令遵循数据流的预期路径，但也可以像RSVP中那样由接收机启动。
A central concept of NSIS is the Session Identifier (SID). Signaling application states are indexed and referred to through the SID in all the NSLPs. This decouples the state information from IP addresses, allowing dynamic IP address changes for signaling flows, e.g., due to mobility: changes in IP addresses do not force complete teardown and re-initiation of a signaling application state; they force merely an update of the state parameters in the NSLP(s), especially the MRI.
NSIS的一个核心概念是会话标识符（SID）。信令应用程序状态通过所有NSLP中的SID进行索引和引用。这将状态信息与IP地址分离，允许信令流的动态IP地址更改，例如，由于移动性：IP地址的更改不会强制信令应用程序状态的完全拆卸和重新启动；它们仅强制更新NSLP（特别是MRI）中的状态参数。
At the NTLP (GIST) layer, the SID is not meaningful by itself, but is used together with the NSLP identifier (NSLPID) and the Message Routing Information (MRI). This 3-tuple is used by GIST to index and manage the signaling flows. Changes of routing or dynamic IP address changes, e.g., due to mobility, will require GIST to modify already established Messaging Associations (MAs) that are used to channel NSLP messages between adjacent GIST peers in order to satisfy the NSLP MRI for each SID.
在NTLP（GIST）层，SID本身没有意义，但与NSLP标识符（NSLPID）和消息路由信息（MRI）一起使用。GIST使用这个三元组来索引和管理信令流。路由更改或动态IP地址更改（例如，由于移动性）将要求GIST修改已建立的消息关联（MA），这些关联用于在相邻GIST对等方之间传递NSLP消息，以满足每个SID的NSLP MRI。
The following design restrictions were imposed for the first phase of the protocol suite. They may be lifted in the future, and new functionality may be added into the protocols at some later stage.
对协议套件的第一阶段施加了以下设计限制。将来可能会取消这些协议，并在稍后的某个阶段将新功能添加到协议中。
o Initial focus on MRMs for path-coupled signaling: GIST transports messages towards an identified unicast data flow destination based on the signaling application request, and does not directly support path-decoupled signaling, e.g., QoS signaling to a bandwidth broker or other off-path resource manager. The framework also supports a Loose End MRM used to discover GIST nodes with particular properties in the direction of a given address; for example, the NAT/firewall NSLP uses this method to discover a NAT along the upstream data path.
o 最初关注路径耦合信令的MRMs：GIST根据信令应用程序请求将消息传输到已识别的单播数据流目的地，并且不直接支持路径解耦信令，例如，到带宽代理或其他非路径资源管理器的QoS信令。该框架还支持一个松散端MRM，用于在给定地址的方向上发现具有特定属性的GIST节点；例如，NAT/防火墙NSLP使用此方法沿上游数据路径发现NAT。
o No multicast support: Introducing support for multicast was deemed too much overhead, considering the currently limited support for global IP multicast. Thus, the current GIST and the NSLP specifications consider unicast flows only.
o 不支持多播：考虑到目前对全局IP多播的支持有限，引入对多播的支持被认为开销太大。因此，当前的GIST和NSLP规范只考虑单播流。
The key documents specifying the NSIS framework are:
指定NSIS框架的关键文件包括：
o Requirements for Signaling Protocols [RFC3726]
o 信令协议要求[RFC3726]
o Next Steps in Signaling: Framework [RFC4080]
o 信令的下一步：框架[RFC4080]
o Security Threats for NSIS [RFC4081]
o NSIS的安全威胁[RFC4081]
The protocols making up the suite specified by the NSIS Working Group are documented in:
NSIS工作组指定的套件的协议记录在：
o The General Internet Signaling Transport protocol [RFC5971]
o 通用因特网信令传输协议[RFC5971]
o Quality-of-Service NSLP (QoS NSLP) [RFC5974]
o 服务质量NSLP（QoS NSLP）[RFC5974]
o The QoS specification template [RFC5975]
o QoS规范模板[RFC5975]
o NAT/firewall traversal NSLP [RFC5973]
o NAT/防火墙穿越NSLP[RFC5973]
The next three sections provide a brief survey of GIST, the QoS NSLP, and the NAT/firewall NSLP.
接下来的三节简要介绍了GIST、QoS NSLP和NAT/防火墙NSLP。
The General Internet Signaling Transport (GIST) [RFC5971] provides signaling transport and security services to NSIS Signaling Layer Protocols (NSLP) and the associated signaling applications. GIST does not define new IP transport protocols or security mechanisms but rather makes use of existing protocols, such as TCP, UDP, TLS, and IPsec. Applications can indicate the desired transport attributes for the signaling flow, e.g., unreliable or reliable, and GIST then chooses the most appropriate transport protocol(s) to satisfy the requirements of the flow. GIST will normally use UDP if unreliable signaling is adequate, TCP if reliability is required, and TLS over TCP for secure (and reliable) signaling flows, but there exist extensibility provisions within GIST that will allow alternatives to be specified in the future. The NSIS layered protocol stack is shown in Figure 1.
通用互联网信令传输（GIST）[RFC5971]向NSIS信令层协议（NSLP）和相关信令应用程序提供信令传输和安全服务。GIST没有定义新的IP传输协议或安全机制，而是利用现有的协议，如TCP、UDP、TLS和IPsec。应用程序可以指示信令流的期望传输属性，例如，不可靠或可靠，然后GIST选择最合适的传输协议以满足流的要求。如果不可靠的信令足够，GIST通常使用UDP，如果需要可靠性，则使用TCP，对于安全（和可靠）的信令流，则使用TCP上的TLS，但GIST中存在可扩展性规定，允许将来指定替代方案。NSIS分层协议栈如图1所示。
+-----+ +--------+ +-------+
| | | | | |
| QoS | | NAT/FW | | ... | NSLP
| | | | | |
+-----+ +--------+ +-------+
+-----+ +--------+ +-------+
| | | | | |
| QoS | | NAT/FW | | ... | NSLP
| | | | | |
+-----+ +--------+ +-------+
---------------------------------------------------------------------
+--------------------------+
| |
| GIST | NTLP
| |
+--------------------------+
---------------------------------------------------------------------
+--------------------------+
| |
| GIST | NTLP
| |
+--------------------------+
---------------------------------------------------------------------
+------------+-------------+
| TLS | DTLS | Security Support*
+------------+-------------+
| TCP | SCTP | UDP | DCCP | Transport Protocol*
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4 | IPv6 |
+--------------------------+
---------------------------------------------------------------------
+------------+-------------+
| TLS | DTLS | Security Support*
+------------+-------------+
| TCP | SCTP | UDP | DCCP | Transport Protocol*
+--------------------------+
+--------------------------+
| IPsec |
+--------------------------+
+--------------------------+
| IPv4 | IPv6 |
+--------------------------+
* The Security Support and Transport Protocol layers show some possible protocols that could be used to transport NSIS messages. To provide authentication and/or integrity protection support, the transport protocol has to be paired with a suitable security mechanism, e.g., TCP with TLS, or Datagram Congestion Control Protocol (DCCP) with DTLS.
* 安全支持和传输协议层显示了一些可能用于传输NSIS消息的协议。为了提供身份验证和/或完整性保护支持，传输协议必须与适当的安全机制配对，例如，TCP与TLS，或数据报拥塞控制协议（DCCP）与DTL。
Figure 1: The NSIS protocol stack
图1:NSIS协议栈
GIST divides up the data flow's end-to-end path into a number of segments between pairs of NSIS-aware peer nodes located along the path. Not every router or other middlebox on the path needs to be NSIS aware: each segment of the signaling path may incorporate several routing hops. Also not every NSIS-aware node necessarily implements every possible signaling application. If the signaling for a flow requests services from a subset of the applications, then only nodes that implement those services are expected to participate as peers, and even some of these nodes can decline to operate on a particular flow if, for example, the additional load might overload the processing capability of the node. These characteristics mean that incremental deployment of NSIS capabilities is possible both with the initial protocol suite, and for any future NSLP applications
GIST将数据流的端到端路径划分为若干段，这些段位于路径沿线的感知NSIS的对等节点对之间。并非路径上的每个路由器或其他中间盒都需要NSIS感知：信令路径的每个段可能包含多个路由跳。此外，并非每个NSIS感知节点都必须实现每个可能的信令应用。如果流的信令从应用程序的子集请求服务，则预期只有实现这些服务的节点作为对等方参与，并且如果例如，附加负载可能使节点的处理能力过载，则即使这些节点中的一些节点也可以拒绝在特定流上操作。这些特征意味着NSIS能力的增量部署在初始协议套件和任何未来NSLP应用程序中都是可能的
that might be developed. The following paragraphs describe how a signaling segment is set up to offer the transport and security characteristics needed by a single NSLP.
这是可以发展的。以下段落描述如何设置信令段以提供单个NSLP所需的传输和安全特性。
When an NSLP application wants to send a message towards a flow endpoint, GIST starts the process of discovering the next signaling node by sending a Query message towards the destination of the related data flow. This Query carries the NSLP identifier (NSLPID) and Message Routing Information (MRI), among others. The MRI contains enough information to control the routing of the signaling message and to identify the associated data flow. The next GIST node on the path receives the message, and if it is running the same NSLP, it provides the MRI to the NSLP application and requests it to make a decision on whether to peer with the querying node. If the NSLP application chooses to peer, GIST sets up a Message Routing State (MRS) between the two nodes for the future exchange of NSLP data. State setup is performed by a three-way handshake that allows for negotiation of signaling flow parameters and provides counter-measures against several attacks (like denial-of-service) by using cookie mechanisms and a late state installation option.
当NSLP应用程序想要向流端点发送消息时，GIST通过向相关数据流的目的地发送查询消息来启动发现下一个信令节点的过程。此查询包含NSLP标识符（NSLPID）和消息路由信息（MRI）等。MRI包含足够的信息来控制信令消息的路由并识别相关联的数据流。路径上的下一个GIST节点接收消息，如果它正在运行相同的NSLP，它将MRI提供给NSLP应用程序，并请求它决定是否与查询节点进行对等。如果NSLP应用程序选择对等，GIST将在两个节点之间设置消息路由状态（MRS），以便将来交换NSLP数据。状态设置通过三方握手执行，该握手允许协商信令流参数，并通过使用cookie机制和后期状态安装选项提供针对多个攻击（如拒绝服务）的对策。
If a transport connection is required and needs to provide for reliable or secure signaling, like TCP or TLS/TCP, a Messaging Association (MA) is established between the two peers. An MA can be reused for signaling messages concerning several different data flows, i.e., signaling messages between two nodes are multiplexed over the same transport connection. This can be done when the transport requirements (reliability, security) of a new flow can be met with an existing MA, i.e., the security and transport properties of an existing MA are equivalent or better than what is requested for a potential new MA.
如果需要传输连接并且需要提供可靠或安全的信令，如TCP或TLS/TCP，则在两个对等方之间建立消息关联（MA）。MA可被重新用于关于多个不同数据流的信令消息，即，两个节点之间的信令消息通过相同的传输连接被多路复用。当新流量的传输要求（可靠性、安全性）可通过现有MA得到满足时，即现有MA的安全性和传输特性等同于或优于潜在新MA的要求时，可以实现这一点。
For path-coupled signaling, we need to find the nodes on the data path that should take part in the signaling of an NSLP and invoke them to act on the arrival of such NSLP signaling messages. The basic concept is that such nodes along a flow's data path intercept the corresponding signaling packets and are thus discovered automatically. GIST places a Router Alert Option (RAO) in Query message packets to ensure that they are intercepted by relevant NSIS-aware nodes, as in RSVP.
对于路径耦合信令，我们需要在数据路径上找到应参与NSLP信令的节点，并调用它们以在此类NSLP信令消息到达时采取行动。基本概念是，沿着流的数据路径的这些节点截获相应的信令分组，并因此被自动发现。GIST在查询消息包中放置路由器警报选项（RAO），以确保它们被相关NSIS感知节点拦截，如RSVP。
Late in the development of GIST, serious concerns were raised in the IETF about the security risks and performance implications of extensive usage of the RAO [RAO-BAD]. Additionally, evidence was discovered indicating that several existing implementations of RAO were inconsistent with the (intention of the) standards and would not support the NSIS usage. There were also concerns that extending the need for RAO recognition in the fast path of routers that are
在GIST开发的后期，IETF中对广泛使用RAO[RAO-BAD]的安全风险和性能影响提出了严重关注。此外，发现的证据表明，RAO的几个现有实现与（标准意图）不一致，不支持NSIS的使用。也有人担心，在路由器的快速路径中扩展RAO识别的需求
frequently implemented in hardware would delay or deter implementation and deployment of NSIS. Eventually, it was decided that NSIS would continue to specify RAO as its primary means for triggering interception of signaling messages in intermediate nodes on the data path, but the protocol suite would be published with Experimental status rather than on the Standards Track while deployment experience was gathered. More information about the use of RAO in GIST can be found in [GIST-RAO]. Also, the deployment issues that arise from the use of RAO are discussed in Section 6.1.
经常在硬件中实施会延迟或阻止NSI的实施和部署。最终，NSIS决定继续将RAO指定为其主要手段，用于在数据路径上的中间节点中触发信令消息的拦截，但在收集部署经验时，协议套件将以实验状态发布，而不是在标准轨道上发布。有关GIST中RAO用法的更多信息，请参见[GIST-RAO]。此外，第6.1节讨论了使用RAO产生的部署问题。
Alternative mechanisms have been considered to allow nodes to recognize NSIS signaling packets that should be intercepted. For example, NSIS nodes could recognize UDP packets directed to a specific destination port as Query messages that need to be intercepted even though they are not addressed to the intercepting node. GIST provides for the use of such alternatives as a part of its extensibility design. NSIS recognizes that the workload imposed by intercepting signaling packets could be considerable relative to the work needed just to forward such packets. To keep the necessary load to a minimum, NSIS provides mechanisms to limit the number of interceptions needed by constraining the rate of generation and allowing for intentional bypassing of signaling nodes that are not affected by particular signaling requests. This can be accomplished either in GIST or in the NSLP.
已经考虑了替代机制，以允许节点识别应被截获的NSIS信令包。例如，NSIS节点可以将定向到特定目标端口的UDP数据包识别为需要拦截的查询消息，即使这些数据包没有发送到拦截节点。GIST将使用这些替代方案作为其可扩展性设计的一部分。NSIS认识到，截获信令包所施加的工作量相对于转发此类包所需的工作量可能相当大。为了将必要的负载保持在最低限度，NSIS通过限制生成速率和允许有意绕过不受特定信令请求影响的信令节点，提供了限制所需拦截次数的机制。这可以在GIST或NSLP中完成。
Since GIST carries information about the data flow inside its messages (in the MRI), NAT gateways must be aware of GIST in order to let it work correctly. GIST provides a special object for NAT traversal so that the actual translation is disclosed if a GIST-aware NAT gateway provides this object.
由于GIST在其消息（在MRI中）中携带有关数据流的信息，因此NAT网关必须了解GIST，以使其正常工作。GIST为NAT遍历提供了一个特殊的对象，因此，如果GIST感知的NAT网关提供了该对象，则会公开实际的转换。
As with RSVP, all the state installed by NSIS protocols is "soft-state" that will expire and be automatically removed unless it is periodically refreshed. NSIS state is held both at the signaling application layer and in the signaling transport layer, and is maintained separately. NSLPs control the lifetime of the state in the signaling application layer by setting a timeout and sending periodic "keep alive" messages along the signaling path if no other messages are required. The MAs and the routing state are maintained semi-independently by the transport layer, because MAs may be used by multiple NSLP sessions, and can also be recreated "on demand" if the node needs to reclaim resources. The transport layer can send its own "keep alive" messages across a MA if no NSLP messages have been sent, for example, if the transport layer decides to maintain a heavily used MA even though there is no current NSLP session using it. Local state can also be deleted explicitly when no longer needed.
与RSVP一样，NSIS协议安装的所有状态都是“软状态”，除非定期刷新，否则将过期并自动删除。NSIS状态在信令应用层和信令传输层都保持，并且单独维护。NSLP通过设置超时并在不需要其他消息的情况下沿信令路径发送周期性“保持活动”消息来控制信令应用层中状态的生存期。MAs和路由状态由传输层半独立地维护，因为多个NSLP会话可以使用MAs，如果节点需要回收资源，也可以“按需”重新创建MAs。如果没有发送NSLP消息，则传输层可以在MA上发送其自己的“保持活动”消息，例如，如果传输层决定维护使用频繁的MA，即使当前没有使用它的NSLP会话。当不再需要时，也可以显式删除本地状态。
If there is a change in the route used by a flow for which NSIS has created state, NSIS needs to detect the change in order to determine if the new path contains additional NSIS nodes that should have state installed. GIST may use a range of triggers in order to detect a route change. It probes periodically for the next peer by sending a GIST Query, thereby detecting a changed route and GIST peer. GIST monitors routing tables and the GIST peer states, and it notifies NSLPs of any routing changes. It is then up to the NSLPs to act appropriately, if needed, e.g., by issuing a refresh message. The periodic queries also serve to maintain the soft-state in nodes as long as the route is unchanged.
如果NSIS已为其创建状态的流所使用的路由发生更改，NSIS需要检测该更改，以确定新路径是否包含应安装状态的其他NSIS节点。GIST可以使用一系列触发器来检测路线变化。它通过发送GIST查询周期性地探测下一个对等点，从而检测更改的路由和GIST对等点。GIST监视路由表和GIST对等状态，并将任何路由更改通知NSLP。然后，如果需要，由NSLP采取适当行动，例如发出刷新消息。只要路由保持不变，周期性查询还可用于维持节点中的软状态。
In summary, GIST provides several services in one package to the upper-layer signaling protocols:
总之，GIST在一个包中向上层信令协议提供多个服务：
o Signaling peer discovery: GIST is able to find the next-hop node that runs the NSLP being signaled for.
o 信令对等发现：GIST能够找到下一跳节点，该节点运行为其发送信令的NSLP。
o Multiplexing: GIST reuses already established signaling relationships and messaging associations to next-hop peers if the signaling flows require the same transport attributes.
o 多路复用：如果信令流需要相同的传输属性，GIST将已建立的信令关系和消息关联重用给下一跳对等方。
o Transport: GIST provides transport with different attributes -- namely, reliable/unreliable and secure/unsecure.
o 传输：GIST提供具有不同属性的传输，即可靠/不可靠和安全/不安全。
o Security: If security is requested, GIST uses TLS to provide an encrypted and integrity-protected message transport to the next signaling peer.
o 安全性：如果请求安全性，GIST使用TLS向下一个信令对等方提供加密和完整性保护的消息传输。
o Routing changes: GIST detects routing changes, but instead of acting on its own, it merely sends a notification to the local NSLP. It is then up to the NSLP to act.
o 路由更改：GIST检测到路由更改，但它不自行操作，只向本地NSLP发送通知。然后由NSLP采取行动。
o Fragmentation: GIST uses either a known Path MTU for the next hop or limits its message size to 576 bytes when using UDP or Query mode. If fragmentation is required, it automatically establishes an MA and sends the signaling traffic over a reliable protocol, e.g., TCP.
o 分段：GIST为下一跳使用已知路径MTU，或者在使用UDP或查询模式时将其消息大小限制为576字节。如果需要分段，它会自动建立MA并通过可靠的协议（如TCP）发送信令流量。
o State maintenance: GIST establishes and then maintains the soft-state that controls communications through MAs between GIST peers along the signaling path, according to usage parameters supplied by NSLPs and local policies.
o 状态维护：GIST根据NSLP提供的使用参数和本地策略，建立并维护软状态，通过MAs控制信令路径上GIST对等方之间的通信。
The Quality-of-Service (QoS) NSIS Signaling Layer Protocol (NSLP) establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of RFC 3726 [RFC3726]. No support for QoS architectures based on bandwidth brokers or other off-path resource managers is currently included.
服务质量（QoS）NSIS信令层协议（NSLP）在数据流路径上的节点处建立和维护状态，以便为该流提供一些转发资源。其旨在满足RFC 3726[RFC3726]的QoS相关要求。目前不支持基于带宽代理或其他非路径资源管理器的QoS体系结构。
The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path). The QoS NSLP extends the set of reservation mechanisms to meet the requirements of RFC 3726 [RFC3726], in particular, support of sender- or receiver-initiated reservations, as well as, a type of bidirectional reservation and support of reservations between arbitrary nodes, e.g., edge-to-edge, end-to-access, etc. On the other hand, there is currently no support for IP multicast.
QoS NSLP的设计在概念上类似于RSVP、RFC 2205[RFC2205]，并且使用软状态对等刷新消息作为主要状态管理机制（即，状态安装/刷新在成对相邻NSLP节点之间执行，而不是沿着完整信令路径以端到端方式执行）。QoS NSLP扩展了保留机制集，以满足RFC 3726[RFC3726]的要求，特别是，支持发送方或接收方发起的保留，以及一种双向保留和支持任意节点之间的保留，例如，边到边、端到访问等，目前不支持IP多播。
A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). RMF-related information is carried in the QSPEC (QoS Specification) object in QoS NSLP messages. This is similar to the decoupling between RSVP and the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries information on resources available, resources required, traffic descriptions, and other information required by the RMF. A template for QSPEC objects is defined in [RFC5975]. This provides a number of basic parameter objects that can be used as a common language to specify components of concrete QoS models. The objects defined in [RFC5975] provide the building blocks for many existing QoS models such as those associated with RSVP and Differentiated Services. The extensibility of the template allows new QoS model specifications to extend the template language as necessary to support these specifications.
在信令协议的操作和资源管理功能（RMF）的操作所需的信息之间进行了区分。RMF相关信息在QoS NSLP消息中的QSPEC（QoS规范）对象中携带。这类似于RSVP和IntServ体系结构RFC1633[RFC1633]之间的解耦。QSPEC包含可用资源、所需资源、交通描述以及RMF所需的其他信息。[RFC5975]中定义了QSPEC对象的模板。这提供了一些基本的参数对象，这些对象可用作指定具体QoS模型组件的公共语言。[RFC5975]中定义的对象为许多现有的QoS模型（如与RSVP和区分服务相关的模型）提供了构建块。模板的可扩展性允许新的QoS模型规范根据需要扩展模板语言以支持这些规范。
The QoS NSLP supports different QoS models because it does not define the QoS mechanisms and RMF that have to be used in a domain. As long as a domain knows how to perform admission control for a given QSPEC, QoS NSLP actually does not care how the specified constraints are enforced and met, e.g., by putting the related data flow in the topmost of four Diffserv classes or by putting it into the third highest of twelve Diffserv classes. The particular QoS configuration used is up to the network provider of the domain. The QSPEC can be seen as a common language to express QoS requirements between different domains and QoS models.
QoS NSLP支持不同的QoS模型，因为它没有定义必须在域中使用的QoS机制和RMF。只要域知道如何对给定的QSPEC执行准入控制，QoS NSLP实际上并不关心如何强制执行和满足指定的约束，例如，将相关数据流放在四个Diffserv类中的最顶端，或将其放在十二个Diffserv类中的第三高。所使用的特定QoS配置取决于域的网络提供商。QSPEC可以看作是一种通用语言，用于表示不同域和QoS模型之间的QoS需求。
In short, the functionality of the QoS NSLP includes:
简而言之，QoS NSLP的功能包括：
o Conveying resource requests for unicast flows
o 传送单播流的资源请求
o Resource requests (QSPEC) that are decoupled from the signaling protocol (QoS NSLP)
o 与信令协议（QoS NSLP）分离的资源请求（QSPEC）
o Sender- and receiver-initiated reservations, as well as bidirectional
o 发送方和接收方发起的预订以及双向预订
o Soft-state and reduced refresh (keep-alive) signaling
o 软状态和减少刷新（保持活动）信号
o Session binding, i.e., session X can be valid only if session Y is also valid
o 会话绑定，即会话X只有在会话Y也有效时才有效
o Message scoping, end-to-end, edge-to-edge, or end-to-edge (proxy mode)
o 消息范围、端到端、边到边或端到边（代理模式）
o Protection against message re-ordering and duplication
o 防止邮件重新排序和重复
o Group tear, tearing down several sessions with a single message
o 组分解，用一条消息分解多个会话
o Support for rerouting, e.g., due to mobility
o 支持重新路由，例如由于移动性
o Support for request priorities and preemption
o 支持请求优先级和抢占
o Stateful and stateless nodes: stateless operation is particularly relevant in core networks where large amounts of QoS state could easily overwhelm a node
o 有状态和无状态节点：无状态操作在核心网络中尤其重要，因为在核心网络中，大量的QoS状态很容易压倒节点
o Reservation aggregation
o 预订汇总
The protocol also provides for a proxy mode to allow the QoS signaling to be implemented without needing all end-hosts to be capable of handling NSIS signaling.
该协议还提供代理模式，以允许在不需要所有终端主机能够处理NSIS信令的情况下实现QoS信令。
The QSPEC template supports situations where the QoS parameters need to be fine-grained, specifically targeted to an individual flow in one part of the network (typically the edge or access part) but might need to be more coarse-grained, where the flow is part of an aggregate (typically in the core of the network).
QSPEC模板支持以下情况：QoS参数需要细粒度，特别针对网络一部分（通常为边缘或接入部分）中的单个流，但可能需要更粗粒度，其中流是聚合的一部分（通常为网络核心）。
The NAT/firewall traversal NSLP [RFC5973] lets end-hosts interact with NAT and firewall devices in the data path. Basically, it allows for a dynamic configuration of NATs and/or firewalls along the data path in order to enable data flows to traverse these devices without
NAT/防火墙穿越NSLP[RFC5973]允许终端主机与数据路径中的NAT和防火墙设备进行交互。基本上，它允许沿数据路径动态配置NAT和/或防火墙，以便使数据流能够在没有任何干扰的情况下穿越这些设备
being obstructed. For instance, firewall pinholes could be opened on demand by authorized hosts. Furthermore, it is possible to block unwanted incoming traffic on demand, e.g., if an end-host is under attack.
被阻碍。例如，经授权的主机可以根据需要打开防火墙针孔。此外，如果终端主机受到攻击，可以按需阻止不需要的传入流量。
Configurations to be implemented in NAT and firewall devices signaled by the NAT/firewall NSLP take the form of a (pattern, action) pair, where the pattern specifies a template for packet header fields to be matched. The device is then expected to apply the specified action to any passing packet that matches the template. Actions are currently limited to ALLOW (forward the packet) and DENY (drop the packet). The template specification allows for a greater range of packet fields to be matched than those allowed for in the GIST MRI.
由NAT/防火墙NSLP发出信号的NAT和防火墙设备中要实现的配置采用（模式、操作）对的形式，其中模式为要匹配的数据包头字段指定模板。然后，期望设备将指定的操作应用于任何与模板匹配的传递数据包。当前操作仅限于允许（转发数据包）和拒绝（丢弃数据包）。模板规范允许匹配的数据包字段范围比GIST MRI中允许的范围更大。
Basically, NAT/firewall signaling starts at the data sender (NSIS Initiator) before any actual application data packets are sent. Signaling messages may pass several middleboxes that are NAT/firewall NSLP aware (NSIS Forwarder) on their way downstream and usually hit the receiver (being the NSIS Responder). A proxy mode is also available for cases where the NAT/firewall NSLP is not fully supported along the complete data path. NAT/firewall NSLP is based on a soft-state concept, i.e., the sender must periodically repeat its request in order to keep it active.
基本上，NAT/防火墙信令在发送任何实际应用程序数据包之前从数据发送方（NSIS启动器）开始。信令消息可能会在其下行途中通过几个NAT/防火墙NSLP感知（NSIS转发器）的中间盒，并且通常会击中接收器（作为NSIS响应者）。代理模式也可用于NAT/防火墙NSLP在整个数据路径上不完全受支持的情况。NAT/防火墙NSLP基于软状态概念，即发送方必须定期重复其请求以保持其活动状态。
Additionally, the protocol also provides functions for receivers behind NATs. The receiver may request an external address that is reachable from outside. The reserved external address must, however, be communicated to the sender out-of-band by other means, e.g., by application level signaling. After this step the data sender may initiate a normal NAT/firewall signaling in order to create firewall pinholes.
此外，该协议还为NAT后面的接收器提供功能。接收者可以请求一个可以从外部访问的外部地址。然而，保留的外部地址必须通过其他方式（例如，通过应用级信令）在带外传送给发送方。在此步骤之后，数据发送方可启动正常NAT/防火墙信令以创建防火墙针孔。
The protocol also provides for a proxy mode to allow the NAT/firewall signaling to be implemented without needing all end-hosts to be capable of handling NSIS signaling.
该协议还提供代理模式，以允许在不需要所有终端主机都能够处理NSIS信令的情况下实现NAT/防火墙信令。
The initial version of the NSIS protocol suite is being published with the status of Experimental in order to gain deployment experience. Concerns over the security, implementation, and administrative issues surrounding the use of RAO are likely to mean that initial deployments occur in "walled gardens" where the characteristics of hardware in use are well-known, and there is a high level of trust and control over the end nodes that use the protocols. This section addresses issues that need to be considered in a deployment of the NSIS protocol suite.
为了获得部署经验，NSIS协议套件的初始版本以实验状态发布。对RAO使用的安全性、实施和管理问题的担忧可能意味着初始部署发生在“围墙花园”中，在那里使用的硬件的特性是众所周知的，并且对使用协议的终端节点具有高度的信任和控制。本节讨论在部署NSIS协议套件时需要考虑的问题。
First of all, NSIS implementations must be available in at least some of the corresponding network nodes (i.e., routers, firewalls, or NAT gateways) and end-hosts. That means not only GIST support, but also the NSLPs and their respective control functions (such as a resource management function for QoS admission control, etc.) must be implemented. NSIS is capable of incremental deployment and an initial deployment does not need to involve every node in a network domain. This is discussed further in Section 6.3. There are a number of obstacles that may be encountered due to broken implementations of RAO (see Section 6.1) and due to firewalls or NATs that drop NSIS signaling packets (see Section 6.2).
首先，NSIS实现必须至少在一些相应的网络节点（即路由器、防火墙或NAT网关）和终端主机中可用。这意味着不仅必须实现GIST支持，还必须实现NSLP及其各自的控制功能（例如用于QoS许可控制的资源管理功能等）。NSIS能够进行增量部署，初始部署不需要涉及网络域中的每个节点。这将在第6.3节中进一步讨论。由于RAO的中断实现（见第6.1节）和丢弃NSIS信令包的防火墙或NAT（见第6.2节），可能会遇到许多障碍。
Another important issue is that applications may need to be made NSIS-aware, thereby requiring some effort from the applications' programmers. Alternatively, it may be possible to implement separate applications to control, e.g., the network QoS requests or firewall pinholes, without needing to update the actual applications that will take advantage of NSIS capabilities.
另一个重要问题是，应用程序可能需要NSIS感知，因此需要应用程序的程序员做出一些努力。或者，可以实现单独的应用程序来控制，例如，网络QoS请求或防火墙针孔，而不需要更新将利用NSIS能力的实际应用程序。
The standardized version of GIST depends on routers and other middleboxes correctly recognizing and acting on packets containing RAO. There are a number of problems related to RAO that can obstruct a deployment of NSIS:
GIST的标准化版本取决于路由器和其他中间盒是否正确识别和处理包含RAO的数据包。与RAO相关的许多问题可能会阻碍NSI的部署：
o Some implementations do not respond to RAO at all.
o 有些实现根本不响应RAO。
o Some implementations respond but do not distinguish between the RAO parameter values in IPv4 packets or reject anything except 0 (in which case, only the value 0 can be used).
o 有些实现会响应，但不会区分IPv4数据包中的RAO参数值，也不会拒绝除0以外的任何内容（在这种情况下，只能使用值0）。
o The response to RAO in a GIST Query mode packet, which is sent using the UDP transport, is to dispatch the packet to the UDP stack in the intercepting node rather than to a function associated with the RAO parameter. Since the node will not normally have a regular UDP receiver for these packets they are dropped.
o GIST查询模式数据包（使用UDP传输发送）中对RAO的响应是将数据包发送到侦听节点中的UDP堆栈，而不是发送到与RAO参数关联的函数。由于节点通常不会为这些数据包提供常规UDP接收器，因此会丢弃这些数据包。
o The major security concern with RAO in NSIS is that it provides a new vector for hosts to mount a (distributed) denial-of-service (DDoS) attack on the control plane of routers on the data path. Such attacks have occurred, and it is therefore normal for service providers to prohibit "host-to-router" signaling packets such as RSVP or NSIS from entering their networks from customer networks. This will tend to limit the deployment of NSIS to "walled gardens" unless a suitable mitigation of the DDoS threat can be found and deployed.
o NSIS中RAO的主要安全问题是，它为主机在数据路径上的路由器控制平面上发起（分布式）拒绝服务（DDoS）攻击提供了一个新的载体。此类攻击已经发生，因此服务提供商禁止诸如RSVP或NSI之类的“主机到路由器”信令包从客户网络进入其网络是正常的。这将倾向于限制NSI在“围墙花园”的部署，除非能够找到并部署DDoS威胁的适当缓解措施。
In order to deploy NSIS effectively, routers and other hardware need to be selected and correctly configured to respond to RAO and dispatch intercepted packets to the NSIS function.
为了有效地部署NSIS，需要选择并正确配置路由器和其他硬件，以响应RAO并将截获的数据包发送给NSIS功能。
A further obstacle results from the likelihood that IPv4 packets with IP options of any kind will be filtered and dropped by firewalls and NATs. In many cases, this is the default behavior so that explicit configuration is needed to allow packets carrying the RAO to pass through. The general inclination of domain administrators is to deny access to packets carrying IP options because of the security risks and the additional load on the routers in the domain. The situation with IPv6 may be easier, as the RAO option in IPv6 is better defined, but the security concerns remain.
另一个障碍是，具有任何类型IP选项的IPv4数据包可能会被防火墙和NAT过滤和丢弃。在许多情况下，这是默认行为，因此需要显式配置来允许携带RAO的数据包通过。域管理员的一般倾向是拒绝访问带有IP选项的数据包，因为安全风险和域中路由器的额外负载。IPv6的情况可能更容易，因为IPv6中的RAO选项定义得更好，但安全问题仍然存在。
Deployment issues are discussed at more length in Appendix C of the GIST specification [RFC5971].
GIST规范[RFC5971]的附录C详细讨论了部署问题。
NAT gateways and firewalls may also hinder initial deployment of NSIS protocols for several reasons:
NAT网关和防火墙也可能由于以下几个原因阻碍NSIS协议的初始部署：
o They may filter and drop signaling traffic (as described in Section 6.1) to deny access to packets containing IP options.
o 它们可以过滤和丢弃信令流量（如第6.1节所述），以拒绝访问包含IP选项的数据包。
o They may not permit "unsolicited" incoming GIST Query mode packets. This behavior has been anticipated in the design of the protocols but requires additional support to ensure that the middleboxes are primed to accept the incoming queries (see [RFC5974] and [RFC5973]).
o 它们可能不允许“未经请求”传入GIST查询模式数据包。这种行为在协议的设计中是预期的，但需要额外的支持，以确保中间盒已准备好接受传入查询（请参阅[RFC5974]和[RFC5973]）。
o NATs that are not aware of the NSIS protocols will generally perform address translations that are not coordinated with the NSIS protocols. Since NSIS signaling messages may be carrying embedded IP addresses affected by these translations, it may not be possible to operate NSIS through such legacy NATs. The situation and workarounds are discussed in Section 7.2.1 of [RFC5971].
o 不知道NSIS协议的NAT通常会执行与NSIS协议不协调的地址转换。由于NSIS信令消息可能携带受这些转换影响的嵌入式IP地址，因此可能无法通过此类遗留NAT操作NSIS。[RFC5971]第7.2.1节讨论了这种情况和解决办法。
NSIS is specifically designed to be incrementally deployable. It is not required that all nodes on the signaling and data path are NSIS aware. To make any use of NSIS, at least two nodes on the path need to be NSIS aware. However, it is not essential that the initiator and receiver of the data flow are NSIS aware. Both the QoS and NAT/ firewall NSLPs provide "proxy modes" in which nodes adjacent to the initiator and/or receiver can act as proxy signaling initiator or
NSIS专门设计为可增量部署。不要求信令和数据路径上的所有节点都知道NSIS。要使用NSI，路径上至少有两个节点需要知道NSI。然而，数据流的发起方和接收方不必知道NSIS。QoS和NAT/防火墙NSLP都提供“代理模式”，在这种模式下，与启动器和/或接收器相邻的节点可以充当代理信令启动器或接收器
receiver. An initiator proxy can monitor traffic and, hopefully, detect when a data flow of a type needing NSIS support is being initiated. The proxies can act more or less transparently on behalf of the data flow initiator and/or receiver to set up the required NSIS state and maintain it while the data flow continues. This capability reduces the immediate need to modify all the data flow endpoints before NSIS is viable.
接受者启动器代理可以监视通信量，并有望在需要NSIS支持的类型的数据流被启动时进行检测。代理可以或多或少透明地代表数据流发起方和/或接收方来设置所需的NSIS状态，并在数据流继续时对其进行维护。此功能减少了在NSIS可行之前修改所有数据流端点的直接需要。
Basic security functions are provided at the GIST layer, e.g., protection against some blind or denial-of-service attacks, but note that introduction of alternative MRMs may provide attack avenues that are not present with the current emphasis on the path-coupled MRM. Conceptually, it is difficult to protect against an on-path attacker and man-in-the-middle attacks when using path-coupled MRMs, because a basic functionality of GIST is to discover as yet unknown signaling peers. Transport security can be requested by signaling applications and is realized by using TLS between signaling peers, i.e., authenticity and confidentiality of signaling messages can be assured between peers. GIST allows for mutual authentication of the signaling peers (using TLS means such as certificates) and can verify the authenticated identity against a database of nodes authorized to take part in GIST signaling. It is, however, a matter of policy that the identity of peers is verified and accepted upon establishment of the secure TLS connection.
GIST层提供了基本的安全功能，例如，针对某些盲攻击或拒绝服务攻击提供保护，但请注意，引入替代MRM可能会提供当前未强调路径耦合MRM的攻击途径。从概念上讲，当使用路径耦合的MRM时，很难防范路径上的攻击者和中间人攻击，因为GIST的一个基本功能是发现未知的信令对等点。传输安全性可由信令应用程序请求，并通过在信令对等方之间使用TLS实现，即，可在对等方之间确保信令消息的真实性和机密性。GIST允许信令对等方的相互认证（使用TLS手段，例如证书），并且可以根据授权参与GIST信令的节点数据库验证认证的身份。然而，在建立安全TLS连接时验证和接受对等方的身份是一个政策问题。
While GIST is handling authentication of peer nodes, more fine-grained authorization may be required in the NSLP protocols. There is currently an ongoing work to specify common authorization mechanisms to be used in NSLP protocols [NSIS-AUTH], thus allowing, e.g., per-user and per-service authorization.
GIST处理对等节点的身份验证时，NSLP协议中可能需要更细粒度的授权。目前正在进行一项工作，以指定NSLP协议[NSIS-AUTH]中使用的通用授权机制，从而允许（例如）每个用户和每个服务的授权。
This section discusses the ways that are available to extend the NSIS protocol suite. The Next Steps in Signaling (NSIS) Framework [RFC4080] describes a two-layer framework for signaling on the Internet, comprising a generic transport layer with specific signaling-layer protocols to address particular applications running over this transport layer. The model is designed to be highly extensible so that it can be adapted for different signaling needs.
本节讨论扩展NSIS协议套件的可用方法。信令（NSIS）框架[RFC4080]中的下一步描述了用于在因特网上进行信令的两层框架，包括具有特定信令层协议的通用传输层，以解决在该传输层上运行的特定应用。该模型的设计具有高度的可扩展性，因此可以适应不同的信令需求。
It is expected that additional signaling requirements will be identified in the future. The two-layer approach allows for NSLP signaling applications to be developed independently of the transport protocol. Further NSLPs can therefore be developed and deployed to meet these new needs using the same GIST infrastructure, thereby
预计未来将确定额外的信号需求。两层方法允许独立于传输协议开发NSLP信令应用程序。因此，可以使用相同的GIST基础设施进一步开发和部署NSLP，以满足这些新需求，从而
providing a level of macro-extensibility. However, the GIST protocol and the two signaling applications have been designed so that additional capabilities can be incorporated into the design should additional requirements within the general scope of these protocols need to be accommodated.
提供一定级别的宏扩展性。然而，GIST协议和两个信令应用程序的设计使得，如果需要满足这些协议一般范围内的附加要求，则可以将附加功能纳入设计中。
The NSIS framework is also highly supportive of incremental deployment. A new NSLP need not be available on every NSIS-aware node in a network or along a signaling path in order to start using it. Nodes that do not (yet) support the application will forward its signaling messages without complaint until it reaches a node where the new NSLP application is deployed.
NSIS框架也高度支持增量部署。新的NSLP不需要在网络中的每个NSIS感知节点上或沿着信令路径提供，就可以开始使用它。不支持该应用程序的节点将毫无怨言地转发其信令消息，直到它到达部署新NSLP应用程序的节点。
One key functionality of parameter objects carried in NSIS protocols is the so-called "Extensibility flags (A/B)". All the existing protocols (and any future ones conforming to the standards) can carry new experimental objects, where the A/B flags can indicate whether a receiving node must interpret the object, or whether it can just drop them or pass them along in subsequent messages sent out further on the path. This functionality allows defining new objects without forcing all network entities to understand them.
NSIS协议中携带的参数对象的一个关键功能是所谓的“可扩展性标志（A/B）”。所有现有协议（以及符合标准的任何未来协议）都可以携带新的实验对象，其中A/B标志可以指示接收节点是否必须解释该对象，或者是否可以丢弃它们或在路径上进一步发送的后续消息中传递它们。此功能允许定义新对象，而无需强制所有网络实体理解它们。
Generally, NSIS protocols can be extended in multiple ways, many of which require the allocation of unique code point values in registries maintained by IANA on behalf of the IETF. This and the following sections provide an overview of the administrative mechanisms that might apply. The extensibility rules defined below are based upon the procedures by which IANA assigns values: "IESG Approval", "IETF Review", "Expert Review", and "Private Use" (as specified in [RFC5226]). The appropriate procedure for a particular type of code point is defined in one or other of the NSIS protocol documents, mostly [RFC5971].
一般来说，NSIS协议可以以多种方式扩展，其中许多需要在IANA代表IETF维护的注册表中分配唯一的代码点值。本节和以下各节概述了可能适用的管理机制。以下定义的扩展性规则基于IANA分配值的程序：“IESG批准”、“IETF审查”、“专家审查”和“私人使用”（如[RFC5226]中规定）。特定类型代码点的适当程序在一个或另一个NSIS协议文件中定义，主要是[RFC5971]。
In addition to registered code points, all NSIS protocols provide code points that can be used for experimentation, usually within closed networks, as explained in [RFC3692]. There is no guarantee that independent experiments will not be using the same code point!
除了注册的代码点外，所有NSIS协议都提供了可用于实验的代码点，通常在封闭网络内，如[RFC3692]中所述。无法保证独立实验不会使用相同的代码点！
GIST is extensible in several aspects covered in the subsections below. In these subsections, there are references to document sections in the GIST specification [RFC5971] where more information can be found. The bullet points at the end of each subsection specify the formal administrative actions that would need to be carried out when a new extension is standardized.
GIST可在以下小节所述的几个方面进行扩展。在这些小节中，参考了GIST规范[RFC5971]中的文件章节，其中可以找到更多信息。每一小节末尾的要点都详细说明了新扩展标准化时需要执行的正式行政行动。
More generally, as asserted in Section 1 of the GIST specification, the GIST design could be extended to cater for multicast flows and for situations where the signaling is not tied to an end-to-end data flow. However, it is not clear whether this could be done in a totally backwards-compatible way, and this is not considered within the extensibility model of NSIS.
更一般地，如GIST规范第1节所述，GIST设计可以扩展以满足多播流和信令不绑定到端到端数据流的情况。然而，目前还不清楚这是否可以以完全向后兼容的方式完成，NSIS的可扩展性模型中也没有考虑到这一点。
Currently, only two message routing methods are supported (Path Coupled MRM and Loose End MRM), but further MRMs may be defined in the future. See Sections 3.3 and 5.8 of the GIST specification [RFC5971]. One possible additional MRM under development is documented in [EST-MRM]. This MRM would direct signaling towards an explicit target address other than the (current) data flow destination and is intended to assist setting up of state on a new path during "make-before-break" handover sequences in mobile operations. Note that alternative routing methods may require modifications to the firewall traversal techniques used by GIST and NSLPs.
目前，只支持两种消息路由方法（路径耦合MRM和松散端MRM），但将来可能会定义更多的MRM。参见GIST规范[RFC5971]第3.3节和第5.8节。[EST-MRM]中记录了正在开发的一个可能的额外MRM。该MRM将信令指向（当前）数据流目的地以外的显式目标地址，并旨在帮助在移动操作中的“先通后断”切换序列期间在新路径上建立状态。请注意，替代路由方法可能需要修改GIST和NSLP使用的防火墙穿越技术。
o New MRMs require allocation of a new MRM-ID either by IETF review of a specification or expert review [RFC5971].
o 新的MRM要求通过IETF规范评审或专家评审分配新的MRM-ID[RFC5971]。
The initial handshake between GIST peers allows a negotiation of the transport protocols to be used. Currently, proposals exist to add DCCP [GIST-DCCP] and the Stream Control Transmission Protocol (SCTP) [GIST-SCTP] transports to GIST; in each case, using Datagram TLS (DTLS) to provide security. See Sections 3.2 and 5.7 of the GIST specification [RFC5971]. GIST expects alternative capabilities to be treated as selection of an alternative protocol stack. Within the protocol stack, the individual protocols used are specified by MA Protocol IDs that are allocated from an IANA registry if new protocols are to be used. See Sections 5.7 and 9 of the GIST specification [RFC5971].
GIST对等方之间的初始握手允许对要使用的传输协议进行协商。目前，有建议将DCCP[GIST-DCCP]和流控制传输协议（SCTP）[GIST-SCTP]传输添加到GIST；在每种情况下，使用数据报TLS（DTL）提供安全性。参见GIST规范[RFC5971]第3.2节和第5.7节。GIST期望替代功能被视为替代协议栈的选择。在协议栈中，使用的各个协议由MA协议ID指定，如果要使用新协议，则从IANA注册表分配MA协议ID。参见GIST规范[RFC5971]第5.7节和第9节。
o Use of an alternative transport protocol or security capability requires allocation of a new MA-Protocol-ID either by IETF review of a specification or expert review [RFC5971].
o 使用替代传输协议或安全能力需要通过IETF规范审查或专家审查分配新的MA协议ID[RFC5971]。
Currently, only TLS is specified for providing secure channels with MAs. Section 3.9 of the GIST specification [RFC5971] suggests that alternative protocols could be used, but the interactions with GIST functions would need to be carefully specified. See also Section 4.4.2 of the GIST specification [RFC5971].
目前，仅指定TLS为MAs提供安全通道。GIST规范[RFC5971]第3.9节建议可以使用替代协议，但需要仔细指定与GIST功能的交互。另见GIST规范[RFC5971]第4.4.2节。
o Use of an alternative security service requires allocation of a new MA-Protocol-ID either by IETF review of a specification or expert review [RFC5971].
o 使用替代安全服务需要通过IETF规范审查或专家审查[RFC5971]分配新的MA协议ID。
GIST has standardized a scheme using RAO mechanisms [GIST-RAO] with UDP packets. If the difficulties of deploying the RAO scheme prove insuperable in particular circumstances, alternative interception schemes can be specified. One proposal that was explored for GIST used UDP port recognition in routers (rather than RAO mechanisms) to drive the interception of packets. See Section 5.3.2 of the GIST specification [RFC5971]. Each NSLP needs to specify membership of an "interception class" whenever it sends a message through GIST. A packet interception scheme can support one or more interception classes. In principle, a GIST instance can support multiple packet interception schemes, but each interception class needs to be associated with exactly one interception scheme in a GIST instance, and GIST instances that use different packet interception schemes for the same interception class will not be interoperable.
GIST已经标准化了一个使用RAO机制[GIST-RAO]和UDP数据包的方案。如果部署RAO方案的困难在特定情况下无法克服，则可以指定替代拦截方案。GIST研究的一个建议是在路由器中使用UDP端口识别（而不是RAO机制）来驱动数据包截获。参见GIST规范[RFC5971]第5.3.2节。每当通过GIST发送消息时，每个NSLP都需要指定“拦截类”的成员身份。数据包拦截方案可以支持一个或多个拦截类。原则上，一个GIST实例可以支持多个包拦截方案，但每个拦截类需要在一个GIST实例中只关联一个拦截方案，对于同一个拦截类使用不同包拦截方案的GIST实例将不具有互操作性。
Defining an alternative interception class mechanism for incorporation into GIST should be considered as a very radical step, and all alternatives should be considered before taking this path. The main reason for this is that the mechanism will necessarily require additional operations on every packet passing through the affected router interfaces. A number of considerations should be taken into account:
定义用于并入GIST的替代拦截类机制应该被视为一个非常激进的步骤，并且在采取这条路径之前应该考虑所有替代方案。这样做的主要原因是，该机制必然需要对通过受影响路由器接口的每个数据包进行额外的操作。应考虑以下几点：
o Although the interception mechanism need only be deployed on routers that actually need it (probably for a new NSLP), deployment may be constrained if the mechanism requires modification to the hardware of relevant routers and/or needs to await modification of the software by the router vendor.
o 虽然拦截机制只需要部署在实际需要它的路由器上（可能是新的NSLP），但如果该机制需要修改相关路由器的硬件和/或需要等待路由器供应商修改软件，则部署可能会受到限制。
o Typically, any packet fields to be examined should be near the header of the packet so that additional memory accesses are not needed to retrieve the values needed for examination.
o 通常，要检查的任何数据包字段都应该靠近数据包的报头，这样就不需要额外的内存访问来检索检查所需的值。
o The logic required to determine if a packet should be intercepted needs to be kept simple to minimize the extra per-packet processing.
o 确定是否应该拦截数据包所需的逻辑需要保持简单，以最大限度地减少每个数据包的额外处理。
o The mechanism should be applicable to both IPv4 and IPv6 packets.
o 该机制应同时适用于IPv4和IPv6数据包。
o Packet interception mechanisms potentially provide an attack path for denial-of-service attacks on routers, in that packets are diverted into the "slow path" and hence can significantly increase the load on the general processing capability of the router. Any new interception mechanism needs to be carefully designed to minimize the attack surface.
o 数据包拦截机制可能为路由器上的拒绝服务攻击提供攻击路径，因为数据包被转移到“慢路径”中，因此可以显著增加路由器的一般处理能力上的负载。任何新的拦截机制都需要仔细设计，以尽量减少攻击面。
Packet interception mechanisms are identified by an "interception class" which is supplied to GIST through the Application Programming Interface for each message sent.
数据包截取机制由“截取类”标识，该类通过应用程序编程接口提供给GIST，用于发送每条消息。
o New packet interception mechanisms will generally require allocation of one or more new Interception-class-IDs. This does not necessarily need to be placed in an IANA registry as it is primarily used as a parameter in the API between the NSLPs and GIST and may never appear on the wire, depending on the mechanism employed; all that is required is consistent interpretation between the NSLPs and GIST in each applicable node. However, if, as is the case with the current RAO mechanism [GIST-RAO], the scheme distinguishes between multiple packet interception classes by a value carried on the wire (different values of RAO parameter for the RAO mechanism in GIST), an IANA registry may be required to provide a mapping between interception classes and on-the-wire values as discussed in Section 6 of [GIST-RAO].
o 新的数据包拦截机制通常需要分配一个或多个新的拦截类ID。这不一定需要放在IANA注册表中，因为它主要用作NSLP和GIST之间API中的参数，可能永远不会出现在线路上，具体取决于所采用的机制；所需的只是每个适用节点中NSLP和GIST之间的一致解释。然而，如果与当前RAO机制[GIST-RAO]的情况一样，该方案通过在线路上携带的值（GIST中RAO机制的RAO参数的不同值）来区分多个包拦截类，如[GIST-RAO]第6节所述，IANA注册表可能需要提供截取类和在线值之间的映射。
The mechanisms proposed for both legacy NAT traversal (Section 7.2.1 of the GIST specification [RFC5971]) and GIST-aware NAT traversal (Section 7.2.2 of the GIST specification [RFC5971]) can be extended or replaced. As discussed above, extension of NAT traversal may be needed if a new MRM is deployed. Note that there is extensive discussion of NAT traversal in the NAT/firewall NSLP specification [RFC5973].
可以扩展或替换为传统NAT遍历（GIST规范[RFC5971]第7.2.1节）和GIST感知NAT遍历（GIST规范[RFC5971]第7.2.2节）提出的机制。如上所述，如果部署了新的MRM，可能需要扩展NAT遍历。注意，NAT/防火墙NSLP规范[RFC5973]中对NAT遍历进行了广泛讨论。
Making extensions to any of the above items may result in having to create new error modes. See Section 9 and Appendix A.4.1 - A.4.3 of the GIST specification [RFC5971].
对上述任何一项进行扩展都可能导致必须创建新的错误模式。参见GIST规范[RFC5971]第9节和附录A.4.1-A.4.3。
o Additional error identifiers require allocation of new error code(s) and/or subcode(s) and may also require allocation of Additional Information types. These are all allocated on a first-come, first-served basis by IANA [RFC5971].
o 其他错误标识符需要分配新的错误代码和/或子代码，还可能需要分配其他信息类型。这些都是IANA按照先到先得的原则分配的[RFC5971]。
The A/B (extensibility) flags in each signaling object carried in NSIS protocols enable the community to specify new objects applicable to GIST that can be carried inside a signaling session without breaking existing implementations. See Appendix A.2 of the GIST specification [RFC5971]. The A/B flags can also be used to indicate in a controlled fashion that a certain object must be understood by all GIST nodes, which makes it possible to probe for the support of an extension. One such object already designed is the "Peering Information Object (PIO)" [PEERING-DATA] that allows a Query message to carry additional peering data to be used by the recipient in making the peering decision.
NSIS协议中携带的每个信令对象中的A/B（可扩展性）标志使社区能够指定适用于GIST的新对象，这些对象可以在信令会话中携带，而不会破坏现有的实现。参见GIST规范[RFC5971]的附录A.2。A/B标志还可用于以受控方式指示所有GIST节点必须理解某个对象，这使得探测扩展的支持成为可能。已经设计的一个这样的对象是“对等信息对象（PIO）”[Peering-DATA]，它允许查询消息携带额外的对等数据，以便接收方在做出对等决策时使用。
o New objects require allocation of a new Object Type ID either by IETF review of a specification or through another acceptable published specification [RFC5971].
o 新对象需要通过IETF对规范的审查或通过另一个可接受的发布规范[RFC5971]分配新的对象类型ID。
Major modifications could be made by adding additional GIST message types and defining appropriate processing. It might be necessary to define this as a new version of the protocol. A field is provided in the GIST Common Header containing the version number. GIST currently has no provision for version or capability negotiation that might be needed if a new version was defined.
可以通过添加额外的GIST消息类型和定义适当的处理来进行重大修改。可能有必要将其定义为协议的新版本。GIST公共标题中提供了一个包含版本号的字段。GIST目前没有规定在定义新版本时可能需要的版本或能力协商。
o New GIST Message Types require allocation of a new GIST Message Type ID either by IETF review of a specification or expert review [RFC5971].
o 新的GIST消息类型要求通过IETF规范评审或专家评审[RFC5971]分配新的GIST消息类型ID。
The QoS NSLP provides signaling for QoS reservations on the Internet. The QoS NSLP decouples the resource reservation model or architecture (QoS model) from the signaling. The signaling protocol is defined in Quality-of-Service NSLP (QoS NSLP) [RFC5974]. The QoS models are defined in separate specifications, and the QoS NSLP can operate with one or more of these models as required by the environment where it is used. It is anticipated that additional QoS models will be developed to address various Internet scenarios in the future. Extensibility of QoS models is considered in Section 8.4.
QoS NSLP为Internet上的QoS保留提供信令。QoS NSLP将资源预留模型或体系结构（QoS模型）与信令分离。信令协议在服务质量NSLP（QoS NSLP）[RFC5974]中定义。QoS模型在单独的规范中定义，QoS NSLP可以根据使用环境的要求使用一个或多个模型。预计将开发更多的QoS模型，以解决未来各种互联网场景。第8.4节考虑了QoS模型的可扩展性。
The QoS NSLP specifically mentions the possibility of using alternative Message Routing Methods (MRMs), apart from the general ability to extend NSLPs using new objects with the standard A/B extensibility flags to allow them to be used in new and old implementations.
QoS NSLP特别提到了使用替代消息路由方法（MRM）的可能性，除了使用具有标准A/B可扩展性标志的新对象扩展NSLP的一般能力之外，还允许在新的和旧的实现中使用它们。
There is already work to extend the base QoS NSLP and GIST to enable new QoS signaling scenarios. One such proposal is the Inter-Domain Reservation Aggregation aiming to support large-scale deployment of the QoS NSLP [RESV-AGGR]. Another current proposal seeks to extend the whole NSIS framework towards path-decoupled signaling and QoS reservations [HYPATH].
已经有工作扩展基本QoS NSLP和GIST，以支持新的QoS信令场景。其中一个方案是域间预约聚合，旨在支持大规模部署QoS NSLP[RESV-AGGR]。当前的另一个提议试图将整个NSIS框架扩展到路径解耦信令和QoS保留[HYPATH]。
The QoS Specification template (QSPEC) is defined in [RFC5975]. This provides the language in which the requirements of specific QoS models are described. Introduction of a new QoS model involves defining a new QSPEC. In order to have a new QSPEC allocated by IANA, there must be an acceptable published specification that defines the specific elements within the QSPEC used in the new model. See [RFC5975] for details.
[RFC5975]中定义了QoS规范模板（QSPEC）。这提供了描述特定QoS模型需求的语言。引入一个新的QoS模型需要定义一个新的QSPEC。为了让IANA分配一个新的QSPEC，必须有一个可接受的发布规范，该规范定义了新模型中使用的QSPEC中的特定元素。详见[RFC5975]。
The introduction of new QoS models is designed to enable deployment of NSIS-based QoS control in specific scenarios. One such example is the Integrated Services Controlled Load Service for NSIS [CL].
引入新的QoS模型旨在支持在特定场景中部署基于NSIS的QoS控制。其中一个例子是NSIS的集成服务控制负载服务[CL]。
A key feature provided by defining the QSPEC template is support of a common language for describing QoS requirements and capabilities, which can be reused by any QoS models intending to use the QoS NSLP to signal their requirements for traffic flows. The commonality of the QSPEC parameters ensures a certain level of interoperability of QoS models and reduces the demands on hardware that has to implement the QoS control. Optional QSPEC parameters support the extensibility of the QoS NSLP to other QoS models in the future; new QSPEC parameters can be defined in the document that specifies a new QoS model. See Sections 4.4 and 7 of [RFC5975].
通过定义QSPEC模板提供的一个关键特性是支持用于描述QoS需求和功能的公共语言，任何打算使用QoS NSLP来表示其流量需求的QoS模型都可以重用该语言。QSPEC参数的通用性确保了QoS模型的一定程度的互操作性，并减少了对必须实现QoS控制的硬件的需求。可选的QSPEC参数支持QoS NSLP在将来扩展到其他QoS模型；可以在指定新QoS模型的文档中定义新的QSPEC参数。见[RFC5975]第4.4节和第7节。
The QSPEC consists of a QSPEC version number, QSPEC objects, plus specification of processing and procedures that can be used to build many QoS models. The definition of a QSPEC can be revised without necessarily changing the version if the changes are functionally backwards compatible. If changes are made that are not backwards compatible, then a new QSPEC version number has to be assigned. Note that a new QSPEC version number is not needed just because additional QSPEC parameters are specified; new versions will be needed only if the existing functionality is modified. The template includes version negotiation procedures that allow the originator of an NSLP
QSPEC由QSPEC版本号、QSPEC对象以及可用于构建许多QoS模型的处理和过程规范组成。如果更改在功能上向后兼容，则可以修改QSPEC的定义，而不必更改版本。如果所做的更改不向后兼容，则必须分配新的QSPEC版本号。注意，仅仅因为指定了附加的QSPEC参数，就不需要新的QSPEC版本号；只有在修改现有功能时，才需要新版本。该模板包括允许NSLP发起人的版本协商程序
message to retry with a lower QSPEC version if the receiver rejects a message because it does not support the QSPEC version signaled in the message. See Section 3.2 of [RFC5975].
如果接收方拒绝消息，因为它不支持消息中指示的QSPEC版本，则使用较低的QSPEC版本重试消息。见[RFC5975]第3.2节。
o Creation of a new, incompatible version of an existing QSPEC requires allocation of a new QSPEC version number that is documented in a permanent and readily available public specification. See [RFC5975].
o 创建现有QSPEC的新的、不兼容的版本需要分配一个新的QSPEC版本号，该版本号记录在永久的、随时可用的公共规范中。参见[RFC5975]。
o Completely new QSPECs can also be created. Such new QSPECs require allocation of a QSPEC type that is documented in a permanent and readily available public specification. Values are also available for local or experimental use during development. See [RFC5975].
o 还可以创建全新的QSpec。此类新的QSPEC要求分配QSPEC类型，该类型记录在永久且随时可用的公共规范中。在开发过程中，这些值也可供本地或实验使用。参见[RFC5975]。
o Additional QSPEC procedures can be defined requiring allocation of a new QSPEC procedure number that is documented in a permanent and readily available public specification. Values are also available for local or experimental use during development. See [RFC5975].
o 可以定义额外的QSPEC程序，要求分配一个新的QSPEC程序编号，该编号记录在一个永久且随时可用的公共规范中。在开发过程中，这些值也可供本地或实验使用。参见[RFC5975]。
o Additional QSPEC parameters and associated error codes can be defined requiring a permanent and readily available public specification document. Values are also available for local or experimental use during development. See [RFC5975].
o 额外的QSPEC参数和相关的错误代码可以定义，需要一份永久的、随时可用的公共规范文件。在开发过程中，这些值也可供本地或实验使用。参见[RFC5975]。
The NAT/firewall signaling can be extended broadly in the same way as the QoS NSLP by defining new parameters to be carried in NAT/firewall NSLP messages. See Section 7 of [RFC5973]. No proposals currently exist to fulfill new use cases for the protocol.
通过定义NAT/防火墙NSLP消息中要携带的新参数，NAT/防火墙信令可以以与QoS NSLP相同的方式广泛扩展。参见[RFC5973]第7节。目前还没有关于实现该协议的新用例的提案。
Designing a new NSLP is both challenging and easy.
设计一个新的NSLP既有挑战性又容易。
New signaling applications with associated NSLPs can be defined to work in parallel or replace the applications already defined by the NSIS working group. Applications that fit into the NSIS framework will be expected to use GIST to provide transport of signaling messages and appropriate security facilities that relieve the application designer of many "lower-level" problems. GIST provides many important functions through the API that it exposes to the code of the signaling application layer, and allows the signaling application programmer to offload various tasks to GIST, e.g., the channel security, transport characteristics, and signaling node discovery.
可将具有相关NSLP的新信令应用程序定义为并行工作或替换NSIS工作组已定义的应用程序。符合NSIS框架的应用程序预计将使用GIST提供信令消息传输和适当的安全设施，以减轻应用程序设计者的许多“低级”问题。GIST通过API提供了许多重要功能，它向信令应用层的代码公开这些功能，并允许信令应用程序程序员将各种任务卸载到GIST，例如，信道安全、传输特性和信令节点发现。
Yet, on the other hand, the signaling application designer must take into account that the network environment can be dynamic, both in terms of routing and node availability. The new NSLP designer must take into account at least the following issues:
然而，另一方面，信令应用程序设计者必须考虑到网络环境在路由和节点可用性方面都是动态的。新的NSLP设计师必须至少考虑以下问题：
o Routing changes, e.g., due to mobility: GIST sends network notifications when something happens in the network, e.g., peers or routing paths change. All signaling applications must be able to handle these notifications and act appropriately. GIST does not include logic to figure out what the NSLP would want to do due to a certain network event. Therefore, GIST gives the notification to the application, and lets it make the right decision.
o 路由更改，例如，由于移动性：GIST在网络中发生某些情况时（例如，对等点或路由路径更改）发送网络通知。所有信令应用程序必须能够处理这些通知并采取适当的行动。GIST不包括逻辑，以确定NSLP由于某个网络事件想要做什么。因此，GIST向应用程序发出通知，并让它做出正确的决定。
o GIST indications: GIST will also send other notifications, e.g., if a signaling peer does not reply to refresh messages, or a certain NSLP message was not successfully delivered to the recipient. NSLP applications must also be able to handle these events. Appendix B in the GIST specification discusses the GIST-NSLP API and the various functionality required, but implementing this interface can be quite challenging; the multitude of asynchronous notifications that can arrive from GIST increases the implementation complexity of the NSLP.
o GIST指示：GIST还将发送其他通知，例如，如果信令对等方不回复刷新消息，或者某个NSLP消息未成功传递给收件人。NSLP应用程序还必须能够处理这些事件。GIST规范中的附录B讨论了GIST-NSLP API和所需的各种功能，但实现此接口可能非常具有挑战性；来自GIST的大量异步通知增加了NSLP的实现复杂性。
o Lifetime of the signaling flow: NSLPs should inform GIST when a flow is no longer needed using the SetStateLifetime primitive. This reduces bandwidth demands in the network.
o 信令流的生存期：当不再需要流时，NSLP应使用SetStateLifetime原语通知GIST。这降低了网络中的带宽需求。
o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new NSLP needs to use a unique NSLPID to ensure that its messages are delivered to the correct application by GIST. A single NSLP could use multiple NSLPIDs, for example, to distinguish different classes of signaling nodes that might handle different levels of aggregation of requests or alternative processing paths. Note that unlike GIST, the NSLPs do not provide a protocol versioning mechanism. If the new NSLP is an upgraded version of an existing NSLP, then it should be distinguished by a different NSLPID.
o NSLP ID：NSLP消息可以通过MAs多路传输。新的NSLP需要使用唯一的NSLPID，以确保其消息通过GIST传递到正确的应用程序。例如，单个NSLP可以使用多个NSLPID来区分可能处理不同级别的请求聚合或替代处理路径的不同类别的信令节点。请注意，与GIST不同，NSLP不提供协议版本控制机制。如果新NSLP是现有NSLP的升级版本，则应使用不同的NSLPID进行区分。
* A new generally available NSLP requires IESG approval for the allocation of a new NSLP ID [RFC5971]
* 新的通用NSLP需要IESG批准分配新的NSLP ID[RFC5971]
o Incremental deployment: It would generally be unrealistic to expect every node on the signaling path to have a new NSLP implemented immediately. New NSLPs need to allow for this. The QoS and NAT/firewall NSLPs provide examples of techniques such as proxy modes that cater for cases where the data flow originator and/or receiver does not implement the NSLP.
o 增量部署：期望信令路径上的每个节点立即实现新的NSLP通常是不现实的。新的NSLP需要考虑到这一点。QoS和NAT/防火墙NSLP提供了诸如代理模式之类的技术示例，这些技术适用于数据流发起人和/或接收方未实现NSLP的情况。
o Signaling Message Source IP Address: It is sometimes challenging for an NSLP originating a signaling message to determine the source IP address that should be used in the signaling messages, which may be different from the data flow source address used in the MRI. This challenge occurs either when a node has multiple interfaces or is acting as a proxy for the data flow originator (typically expected to occur during the introduction of NSIS when not all nodes are NSIS enabled). A proxy signaling flow originator generally needs to know and use the correct data flow source IP address, at least initially. As discussed in Section 5.8.1.2 of [RFC5971], the signaling flow originator may choose to alter the source IP address after the initial Query message has established the flow path in order that ICMP messages are directed to the most appropriate node. In the proxy case, the data flow originator would be unaware of the signaling flow, and ICMP messages relating to the signaling would be meaningless if passed on to the data flow originator. Hence, it is essential that an NSLP is aware of the position and role of the node on which it is instantiated and has means of determining the appropriate source address to be used and ensuring that it is used on signaling packets.
o 信令消息源IP地址：对于发起信令消息的NSLP来说，有时很难确定信令消息中应使用的源IP地址，这可能不同于MRI中使用的数据流源地址。当一个节点具有多个接口或充当数据流发起人的代理时（通常预期在引入NSIS期间发生，但并非所有节点都启用了NSIS），就会出现此问题。代理信令流发起者通常需要知道并使用正确的数据流源IP地址，至少最初是这样。如[RFC5971]第5.8.1.2节所述，信令流发起者可选择在初始查询消息建立流路径后更改源IP地址，以便将ICMP消息定向到最合适的节点。在代理情况下，数据流发端人将不知道信令流，如果将与信令相关的ICMP消息传递给数据流发端人，则该消息将毫无意义。因此，NSLP必须知道其在其上被实例化的节点的位置和角色，并且具有确定要使用的适当源地址并确保其在信令分组上使用的手段。
o New MRMs: GIST currently defines two Message Routing Methods, and leaves the door open for new ideas. Thus, it is possible that a new NSLP also requires a new MRM; path-decoupled routing being one example.
o 新的MRMs:GIST目前定义了两种消息路由方法，并为新想法打开了大门。因此，新的NSLP也可能需要新的MRM；路径解耦路由就是一个例子。
o Cooperation with other NSLPs: Some applications might need resources from two or more different classes in order to operate successfully. The NSLPs managing these resources could operate cooperatively to ensure that such requests were coordinated to avoid wasting signaling bandwidth and prevent race conditions.
o 与其他NSLP的合作：某些应用程序可能需要来自两个或更多不同类的资源才能成功运行。管理这些资源的NSLP可以协同工作，以确保这些请求得到协调，从而避免浪费信令带宽和防止竞争条件。
It is essential that the security considerations of a new NSLP are carefully analyzed. NSIS NSLPs are deployed in routers as well as host systems; a poorly designed NSLP could therefore provide an attack vector for network resources as well as end systems. The NSLP must also support authorization of users and must allow the use of the GIST authentication and integrity protection mechanisms where users deem them to be necessary.
必须仔细分析新NSLP的安全考虑因素。NSIS NSLP部署在路由器和主机系统中；因此，设计不良的NSLP可以为网络资源和终端系统提供攻击向量。NSLP还必须支持用户授权，并且必须允许在用户认为必要时使用GIST身份验证和完整性保护机制。
The API between GIST and NSLPs (see Appendix B in [RFC5971]) is very important to understand. The abstract design in the GIST specification does not specify the exact messaging between GIST and the NSLPs but gives an understanding of the interactions, especially what kinds of asynchronous notifications from GIST the NSLP must be prepared to handle: the actual interface will be dependent on each implementation of GIST.
GIST和NSLP之间的API（参见[RFC5971]中的附录B）对于理解非常重要。GIST规范中的抽象设计没有规定GIST和NSLP之间的确切消息传递，但提供了对交互的理解，特别是NSLP必须准备好处理GIST发出的何种异步通知：实际接口将取决于GIST的每个实现。
Messages transmitted by GIST on behalf of an NSLP are identified by a unique NSLP identifier (NSLPID). NSLPIDs are 16-bit unsigned numbers taken from a registry managed by IANA and defined in Section 9 of the GIST specification [RFC5971].
GIST代表NSLP传输的消息由唯一NSLP标识符（NSLPID）标识。NSLPID是从IANA管理的注册表中获取的16位无符号数字，在GIST规范[RFC5971]第9节中定义。
A range of values (32704-32767) is available for Private and Experimental use during development. Any new signaling application that expects to be deployed generally on the Internet needs to use the registration procedure "IESG Approval" in order to request allocation of unique NSLPID value(s) from the IANA registry. There is additional discussion of NSLPIDs in Section 3.8 of the GIST specification.
在开发过程中，有一系列值（32704-32767）可供私人和实验使用。任何预计在互联网上部署的新信令应用程序都需要使用注册程序“IESG批准”，以便从IANA注册中心请求分配唯一的NSLPID值。GIST规范第3.8节对NSLPID进行了补充讨论。
This document provides information to the community. It does not itself raise new security concerns.
本文件向社区提供信息。它本身不会引起新的安全问题。
However, any extensions that are made to the NSIS protocol suite will need to be carefully assessed for any security implications. This is particularly important because NSIS messages are intended to be actively processed by NSIS-capable routers that they pass through, rather than simply forwarded as is the case with most IP packets. It is essential that extensions provide means to authorize usage of capabilities that might allocate resources and recommend the use of appropriate authentication and integrity protection measures in order to exclude or adequately mitigate any security issues that are identified.
但是，对NSIS协议套件进行的任何扩展都需要仔细评估是否存在任何安全隐患。这一点尤其重要，因为NSIS消息将由它们通过的支持NSIS的路由器主动处理，而不是像大多数IP数据包那样简单地转发。扩展必须提供授权使用可能分配资源的功能的方法，并建议使用适当的身份验证和完整性保护措施，以排除或充分缓解已识别的任何安全问题。
Authors of new extensions for NSIS should review the analysis of security threats to NSIS documented in [RFC4081] as well as considering whether the new extension opens any new attack paths that need to be mitigated.
NSIS新扩展的作者应审查[RFC4081]中记录的对NSIS安全威胁的分析，并考虑新扩展是否会开启任何需要缓解的新攻击路径。
GIST offers facilities to authenticate NSIS messages and to ensure that they are delivered reliably. Extensions must allow these capabilities to be used in an appropriate manner to minimize the risks of NSIS messages being misused and must recommend their appropriate usage.
GIST提供了对NSIS消息进行身份验证并确保其可靠传递的工具。扩展必须允许以适当的方式使用这些功能，以最大限度地降低NSIS消息被误用的风险，并且必须推荐适当的使用方法。
If additional transport protocols are proposed for use in association with GIST, an appropriate set of compatible security functions must be made available in conjunction with the transport protocol to support the authentication and integrity functions expected to be available through GIST.
如果建议与GIST结合使用其他传输协议，则必须与传输协议一起提供一组适当的兼容安全功能，以支持预期通过GIST可用的身份验证和完整性功能。
This document combines work previously published as two separate documents: "What is Next Steps in Signaling anyway - A User's Guide to the NSIS Protocol Family" written by Roland Bless and Jukka Manner, and "NSIS Extensibility Model" written by John Loughney.
本文档结合了之前作为两个单独文档发布的工作：“无论如何，信令的下一步是什么-NSIS协议系列用户指南”，由罗兰·布莱斯和朱卡·韦恩编写，以及约翰·洛格尼编写的“NSIS可扩展性模型”。
Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of the "User's Guide" and valuable input. Teemu Huovila also provided valuable input on the later versions.
Max Laier、Nuutti Varis和Lauri Liuhto对“用户指南”进行了审查，并提供了宝贵的意见。Teemu Huovila还为以后的版本提供了有价值的信息。
The "Extensibility Model" borrowed some ideas and some text from RFC 3936 [RFC3936], "Procedures for Modifying the Resource ReSerVation Protocol (RSVP)". Robert Hancock provided text for the original GIST section, since much modified, and Claudia Keppler has provided feedback on this document, while Allison Mankin and Bob Braden suggested that this document be worked on.
“可扩展性模型”借鉴了RFC 3936[RFC3936]“修改资源预留协议（RSVP）的过程”中的一些思想和文本。罗伯特·汉考克（Robert Hancock）为原始的要点部分提供了文本，因为经过了大量修改，克劳迪娅·凯普勒（Claudia Keppler）对此文档提供了反馈，而艾莉森·曼金（Allison Mankin）和鲍勃·布拉登（Bob Braden）则建议编写此文档。
[RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]Brunner，M.，“信令协议的要求”，RFC 3726，2004年4月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
[RFC5973]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，RFC 59732010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]Ash，G.，Bader，A.，Kappler，C.，和D.Oran，“服务质量NSIS信令层协议（NSLP）的QSPEC模板”，RFC 59752010年10月。
[CL] Kappler, C., Fu, X., and B. Schloer, "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.
[CL]Kappler，C.，Fu，X.，和B.Schloer，“使用NSIS发送IntServ控制负载服务的QoS模型”，正在进行的工作，2010年4月。
[EST-MRM] Bless, R., "An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol", Work in Progress, June 2010.
[EST-MRM]Bless，R.，“通用互联网信令传输（GIST）协议的显式信令目标消息路由方法（EST-MRM）”，正在进行的工作，2010年6月。
[GIST-DCCP] Manner, J., "Generic Internet Signaling Transport over DCCP and DTLS", Work in Progress, June 2007.
[GIST-DCCP]Way，J.，“DCCP和DTLS上的通用互联网信令传输”，正在进行的工作，2007年6月。
[GIST-RAO] Hancock, R., "Using the Router Alert Option for Packet Interception in GIST", Work in Progress, November 2008.
[GIST-RAO]Hancock，R.，“在GIST中使用路由器警报选项进行数据包拦截”，正在进行的工作，2008年11月。
[GIST-SCTP] Fu, X., Dickmann, C., and J. Crowcroft, "General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)", Work in Progress, May 2010.
[GIST-SCTP]Fu，X.，Dickmann，C.，和J.Crowcroft，“流控制传输协议（SCTP）上的通用互联网信令传输（GIST）和数据报传输层安全（DTLS）”，正在进行的工作，2010年5月。
[HYPATH] Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", Work in Progress, February 2008.
[HYPATH]Cordeiro，L.，Curado，M.，Monteiro，E.，Bernardo，V.，Palma，D.，Racaru，F.，Diaz，M.，和C.Chassot，“混合在路-非路径信号（HYPATH）的GIST扩展”，正在进行的工作，2008年2月。
[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, "Authorization for NSIS Signaling Layer Protocols", Work in Progress, July 2008.
[NSIS-AUTH]Way，J.，Stiemering，M.，Tschofenig，H.，和R.Bless，“NSIS信令层协议的授权”，正在进行的工作，2008年7月。
[PEERING-DATA] Manner, J., Liuhto, L., Varis, N., and T. Huovila, "Peering Data for NSIS Signaling Layer Protocols", Work in Progress, February 2008.
[PEERING-DATA]Way，J.，Liuhto，L.，Varis，N.，和T.Huovila，“NSIS信令层协议的对等数据”，正在进行的工作，2008年2月。
[RAO-BAD] Rahman, R. and D. Ward, "Use of IP Router Alert Considered Dangerous", Work in Progress, October 2008.
[RAO-BAD]Rahman，R.和D.Ward，“使用IP路由器警报被认为是危险的”，正在进行的工作，2008年10月。
[RESV-AGGR] Doll, M. and R. Bless, "Inter-Domain Reservation Aggregation for QoS NSLP", Work in Progress, July 2007.
[RESV-AGGR]Doll，M.和R.Bless，“QoS NSLP的域间保留聚合”，正在进行的工作，2007年7月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.
[RFC3936]Kompella，K.和J.Lang，“修改资源预留协议（RSVP）的程序”，BCP 96，RFC 3936，2004年10月。
[RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.
[RFC4094]Way，J.和X.Fu，“现有服务质量信令协议分析”，RFC 4094，2005年5月。
[TWO-LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", Work in Progress, November 2002.
[两级]Braden，R.和B.Lindell，“互联网信令的两级架构”，正在进行的工作，2002年11月。
Authors' Addresses
作者地址
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
阿尔托大学通信与网络系（Comnet）邮政信箱13000 FIN-00076阿尔托芬兰
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany
德国卡尔斯鲁厄理工学院罗兰·布莱斯远程信息处理研究所（KIT）Zirkel 2号楼20.20信箱6980卡尔斯鲁厄76049
Phone: +49 721 608 6413
EMail: bless@kit.edu
URI: http://tm.kit.edu/~bless
Phone: +49 721 608 6413
EMail: bless@kit.edu
URI: http://tm.kit.edu/~bless
John Loughney Nokia 955 Page Mill Road Palo Alto, CA 94303 USA
美国加利福尼亚州帕洛阿尔托市密尔路955页，邮编94303
Phone: +1 650 283 8068
EMail: john.loughney@nokia.com
Phone: +1 650 283 8068
EMail: john.loughney@nokia.com
Elwyn Davies (editor) Folly Consulting Soham UK
Elwyn Davies（编辑）Folly Consulting Soham UK
EMail: elwynd@folly.org.uk
URI: http://www.folly.org.uk
EMail: elwynd@folly.org.uk
URI: http://www.folly.org.uk