Internet Engineering Task Force (IETF) C. Shen
Request for Comments: 5979 H. Schulzrinne
Category: Experimental Columbia U.
ISSN: 2070-1721 S. Lee
Samsung
J. Bang
Samsung AIT
March 2011
Internet Engineering Task Force (IETF) C. Shen
Request for Comments: 5979 H. Schulzrinne
Category: Experimental Columbia U.
ISSN: 2070-1721 S. Lee
Samsung
J. Bang
Samsung AIT
March 2011
NSIS Operation over IP Tunnels
NSIS在IP隧道上的运行
Abstract
摘要
NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.
NSIS服务质量（QoS）信令使应用程序能够沿数据流路径执行QoS保留。当数据流路径包含IP隧道段时，NSIS QoS信令在这些隧道段内不起作用。因此，产生的隧道段可能成为最薄弱的QoS链路，并使端到端路径其余部分的QoS工作无效。隧道内的NSIS信令问题是由屏蔽数据包原始IP报头字段的隧道封装引起的。拦截NSIS信令消息和分类QoS数据包需要这些原始IP报头字段。本文档通过将端到端QoS会话请求映射到隧道中相应的QoS会话来定义此问题的解决方案，从而将端到端QoS信令扩展到IP隧道段。
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/rfc5979.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5979.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Preconfigured QoS Sessions . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Preconfigured QoS Sessions . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
IP tunneling [RFC1853] [RFC2003] is a technique that allows a packet to be encapsulated and carried as payload within an IP packet. The resulting encapsulated packet is called an IP tunnel packet, and the packet being tunneled is called the original packet. In typical scenarios, IP tunneling is used to exert explicit forwarding path control (e.g., in Mobile IP [RFC5944]), implement secure IP data delivery (e.g., in IPsec [RFC4301]), and help packet routing in IP networks of different characteristics (e.g., between IPv6 and IPv4 networks [RFC4213]). Section 3.1 summarizes a list of common IP tunneling protocols.
IP隧道[RFC1853][RFC2003]是一种允许在IP数据包中封装和携带数据包作为有效负载的技术。得到的封装包称为IP隧道包，被隧道传输的包称为原始包。在典型场景中，IP隧道用于实施显式转发路径控制（例如，在移动IP[RFC5944]中），实现安全的IP数据传输（例如，在IPsec[RFC4301]中），并帮助在具有不同特征的IP网络（例如，在IPv6和IPv4网络[RFC4213]之间）中进行分组路由。第3.1节总结了常见的IP隧道协议列表。
This document considers the situation when the packet being tunneled contains a Next Step In Signaling (NSIS) [RFC4080] packet. NSIS is an IP signaling architecture consisting of a Generic Internet Signaling Transport (GIST) [RFC5971] sub-layer for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) sub-layer customizable for different applications. We focus on the Quality of Service (QoS) NSLP [RFC5974] which provides functionalities that extend those of the earlier RSVP [RFC2205] signaling. In this document, the terms "NSIS" and "NSIS QoS" are used interchangeably.
本文件考虑了正在隧道传输的数据包包含信令（NSIS）[RFC4080]数据包中的下一步时的情况。NSIS是一种IP信令体系结构，由用于信令传输的通用Internet信令传输（GIST）[RFC5971]子层和可针对不同应用定制的NSIS信令层协议（NSLP）子层组成。我们关注服务质量（QoS）NSLP[RFC5974]，它提供了扩展早期RSVP[RFC2205]信令的功能。在本文件中，术语“NSIS”和“NSIS QoS”可互换使用。
Without additional efforts, NSIS signaling does not work within IP tunnel segments of a signaling path. The reason is that tunnel encapsulation masks the original packet including its header and payload. However, information from the original packet is required both for NSIS peer node discovery and for QoS data flow packet classification. Without access to information from the original packet, an IP tunnel acts as an NSIS-unaware virtual link in the end-to-end NSIS signaling path.
如果没有额外的努力，NSIS信令就不能在信令路径的IP隧道段内工作。原因是隧道封装屏蔽了原始数据包，包括其头部和有效负载。然而，NSIS对等节点发现和QoS数据流分组分类都需要来自原始分组的信息。在不访问原始数据包信息的情况下，IP隧道充当端到端NSIS信令路径中的NSIS非感知虚拟链路。
This document defines a mechanism to extend end-to-end NSIS signaling for QoS reservation into IP tunnels. The NSIS-aware IP tunnel endpoints that support this mechanism are called NSIS-tunnel-aware endpoints. There are two main operation modes. On one hand, if the tunnel already has preconfigured QoS sessions, the NSIS-tunnel-aware endpoints map end-to-end QoS signaling requests directly to existing tunnel sessions as long as there are enough tunnel session resources; on the other hand, if no preconfigured tunnel QoS sessions are available, the NSIS-tunnel-aware endpoints dynamically initiate and maintain tunnel QoS sessions that are then associated with the corresponding end-to-end QoS sessions. Note that whether or not the tunnel preconfigures QoS sessions, and which preconfigured tunnel QoS sessions a particular end-to-end QoS signaling request should be mapped to are policy issues that are out of scope of this document.
本文档定义了一种机制，用于将用于QoS保留的端到端NSIS信令扩展到IP隧道中。支持此机制的NSIS感知IP隧道端点称为NSIS感知隧道端点。主要有两种操作模式。一方面，如果隧道已经具有预配置的QoS会话，则NSIS隧道感知端点将端到端QoS信令请求直接映射到现有隧道会话，只要有足够的隧道会话资源；另一方面，如果没有预配置的隧道QoS会话可用，NSIS隧道感知端点将动态地发起和维护隧道QoS会话，然后这些会话与相应的端到端QoS会话相关联。请注意，隧道是否预配置QoS会话，以及特定端到端QoS信令请求应映射到哪些预配置的隧道QoS会话，这些都是超出本文档范围的策略问题。
The rest of this document is organized as follows. Section 2 defines terminology. Section 3 presents the problem statement including common IP tunneling protocols and existing behavior of NSIS QoS signaling over IP tunnels. Section 4 introduces the design requirements and overall approach of our mechanism. More details about how NSIS QoS signaling operates with tunnels that use preconfigured QoS and dynamic QoS signaling are provided in Sections 5 and 6. Section 7 describes a method to automatically discover whether a tunnel endpoint node supports the NSIS-tunnel interoperation mechanism defined in this document. Section 8 discusses IANA considerations, and Section 9 considers security.
本文件其余部分的组织如下。第2节定义了术语。第3节介绍了问题陈述，包括常见的IP隧道协议和NSIS QoS信令在IP隧道上的现有行为。第4节介绍了我们的机制的设计要求和总体方法。有关NSIS QoS信令如何与使用预配置QoS和动态QoS信令的隧道一起运行的更多详细信息，请参见第5节和第6节。第7节描述了一种自动发现隧道端点节点是否支持本文档中定义的NSIS隧道互操作机制的方法。第8节讨论IANA考虑事项，第9节讨论安全性。
This document uses terminology defined in [RFC2473], [RFC5971], and [RFC5974]. In addition, the following terms are used:
本文件使用[RFC2473]、[RFC5971]和[RFC5974]中定义的术语。此外，还使用了以下术语：
IP Tunnel: A tunnel that is configured as a virtual link between two IP nodes and on which the encapsulating protocol is IP.
IP隧道：配置为两个IP节点之间的虚拟链路且封装协议为IP的隧道。
Tunnel IP Header: The IP header prepended to the original packet during encapsulation. It specifies the tunnel endpoints as source and destination.
隧道IP头：在封装过程中预先添加到原始数据包的IP头。它将隧道端点指定为源和目标。
Tunnel-Specific Header: The header fields inserted by the encapsulation mechanism after the tunnel IP header and before the original packet. These headers may or may not exist depending on the specific tunnel mechanism used. An example of such header fields is the Encapsulation Security Payload (ESP) header for IPsec [RFC4301] tunneling mode.
隧道特定标头：封装机制在隧道IP标头之后、原始数据包之前插入的标头字段。这些标头可能存在，也可能不存在，具体取决于所使用的特定隧道机制。此类头字段的一个示例是IPsec[RFC4301]隧道模式的封装安全有效负载（ESP）头。
Tunnel Intermediate Node (Tmid): A node that resides in the middle of the forwarding path between the tunnel entry-point node and the tunnel exit-point node.
隧道中间节点（TMID）：位于隧道入口点节点和隧道出口点节点之间的转发路径中间的节点。
Flow Identifier (Flow ID): The set of header fields that is used to identify a data flow. For example, it may include flow sender and receiver addresses, and protocol and port numbers.
流标识符（流ID）：用于标识数据流的标题字段集。例如，它可能包括流发送方和接收方地址，以及协议和端口号。
End-to-End QoS Signaling: The signaling process that manipulates the QoS control information in the end-to-end path from the flow sender to the flow receiver. When the end-to-end flow path contains tunnel segments, this document uses end-to-end QoS signaling to refer to the QoS signaling outside the tunnel segments. This document uses "end-to-end QoS signaling" and "end-to-end signaling" interchangeably.
端到端QoS信令：在从流发送方到流接收方的端到端路径中操纵QoS控制信息的信令过程。当端到端流程包含隧道段时，本文档使用端到端QoS信令来指代隧道段外的QoS信令。本文档交替使用“端到端QoS信令”和“端到端信令”。
Tunnel QoS Signaling: The signaling process that manipulates the QoS control information in the path inside a tunnel, between the tunnel entry-point and the tunnel exit-point nodes. This document uses "tunnel QoS signaling" and "tunnel signaling" interchangeably.
隧道QoS信令：在隧道入口点和隧道出口点节点之间，操纵隧道内路径中QoS控制信息的信令过程。本文档交替使用“隧道QoS信令”和“隧道信令”。
NSIS-Aware Node: A node that supports NSIS signaling.
NSIS感知节点：支持NSIS信令的节点。
NSIS-Aware Tunnel Endpoint Node: A tunnel endpoint node that is also an NSIS node.
NSIS感知隧道端点节点：也是NSIS节点的隧道端点节点。
NSIS-Tunnel-Aware Endpoint Node: An NSIS-aware tunnel endpoint node that also supports the mechanism for NSIS operating over IP tunnels defined in this document.
NSIS隧道感知端点节点：NSIS感知隧道端点节点，还支持NSIS在本文档中定义的IP隧道上运行的机制。
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Figure 1: IP Tunnel
图1:IP隧道
The following description about IP tunneling is derived from [RFC2473] and adapted for both IPv4 and IPv6.
以下关于IP隧道的描述源自[RFC2473]，适用于IPv4和IPv6。
IP tunneling (Figure 1) is a technique for establishing a "virtual link" between two IP nodes for transmitting data packets as payloads of IP packets. From the point of view of the two nodes, this "virtual link", called an IP tunnel, appears as a point-to-point link on which IP acts like a link-layer protocol. The two IP nodes play specific roles. One node encapsulates original packets received from other nodes or from itself and forwards the resulting tunnel packets through the tunnel. The other node decapsulates the received tunnel packets and forwards the resulting original packets towards their destinations, possibly itself. The encapsulating node is called the tunnel entry-point node (Tentry), and it is the source of the tunnel packets. The decapsulating node is called the tunnel exit-point node (Texit), and it is the destination of the tunnel packets.
IP隧道（图1）是一种在两个IP节点之间建立“虚拟链路”的技术，用于将数据包作为IP包的有效负载进行传输。从这两个节点的角度来看，这个称为IP隧道的“虚拟链路”似乎是一个点对点链路，IP在该链路上起着链路层协议的作用。这两个IP节点扮演特定的角色。一个节点封装从其他节点或自身接收的原始数据包，并通过隧道转发产生的隧道数据包。另一个节点对接收到的隧道数据包进行去封装，并将得到的原始数据包转发到它们的目的地（可能是自身）。封装节点称为隧道入口点节点（Tentry），它是隧道数据包的源。解封装节点称为隧道出口点节点（Texit），它是隧道数据包的目的地。
An IP tunnel is a unidirectional mechanism - the tunnel packet flow takes place in one direction between the IP tunnel entry-point and exit-point nodes. Bidirectional tunneling is achieved by combining two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other -- the entry-point node of one tunnel is the exit-point node of the other tunnel.
IP隧道是一种单向机制-隧道数据包流在IP隧道入口点和出口点节点之间的一个方向上发生。双向隧道是通过组合两个单向机制实现的，即配置两个隧道，每个隧道的方向与另一个相反——一个隧道的入口点节点是另一个隧道的出口点节点。
Figure 2 illustrates the original packet and the resulting tunnel packet. In a tunnel packet, the original packet is encapsulated within the tunnel header. The tunnel header contains two components, the tunnel IP header and other tunnel-specific headers. The tunnel IP header specifies the tunnel entry-point node as the IP source
图2说明了原始数据包和生成的隧道数据包。在隧道数据包中，原始数据包被封装在隧道报头中。隧道标头包含两个组件，隧道IP标头和其他特定于隧道的标头。隧道IP标头将隧道入口点节点指定为IP源
address and the tunnel exit-point node as the IP destination address, causing the tunnel packet to be forwarded in the tunnel. The tunnel-specific header between the tunnel IP header and the original packet is optional, depending on the tunneling protocol in use.
地址和隧道出口点节点作为IP目标地址，导致隧道数据包在隧道中转发。隧道IP头和原始数据包之间的隧道特定头是可选的，具体取决于使用的隧道协议。
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
< Tunnel Headers > < Original Packet >
+---------+-----------+-------------------------//--------------+
| Tunnel | Tunnel- | |
| IP | Specific | Original Packet |
| Header | Header | |
+---------+-----------+-------------------------//--------------+
< Tunnel IP Packet >
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
< Tunnel Headers > < Original Packet >
+---------+-----------+-------------------------//--------------+
| Tunnel | Tunnel- | |
| IP | Specific | Original Packet |
| Header | Header | |
+---------+-----------+-------------------------//--------------+
< Tunnel IP Packet >
Figure 2: IP Tunnel Encapsulation
图2:IP隧道封装
Commonly used IP tunneling protocols include Generic Routing Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] and IPsec tunneling mode [RFC4301] [RFC4303]. Among these tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4, and IPv6GEN contain only a tunnel IP header, and no tunnel-specific header. All the other tunneling protocols have a tunnel header consisting of both a tunnel IP header and a tunnel-specific header. The tunnel-specific header is the GRE header for GRE and GREIPv4, the minimum encapsulation header for MINENC, and the ESP header for IPsec tunneling mode. As will be discussed in Section 4.3, some of the tunnel-specific headers may be used to identify a flow in the tunnel and facilitate NSIS operating over IP tunnels.
常用的IP隧道协议包括通用路由封装（GRE）[RFC1701][RFC2784]、IPv4网络上的通用路由封装（GREPV4）[RFC1702]和IP内的IP封装（IPv4INIPv4）[RFC1853][RFC2003]、IP内的最小封装（MINENC）[RFC2004]、IPv4上的IPv6隧道（IPv6INIPv4）[RFC4213]，IPv6规范（IPv6GEN）[RFC2473]和IPsec隧道模式[RFC4301][RFC4303]中的通用数据包隧道。在这些隧道协议中，IPv4INIPv4、IPv6INIPv4和IPv6GEN中的隧道头仅包含隧道IP头，而不包含隧道特定头。所有其他隧道协议都有一个隧道头，由隧道IP头和隧道特定头组成。特定于隧道的头是GRE和GREPV4的GRE头、MINENC的最小封装头和IPsec隧道模式的ESP头。如第4.3节所述，一些特定于隧道的标头可用于识别隧道中的流量，并促进NSI在IP隧道上运行。
Typically, applications use NSIS QoS signaling to reserve resources for a flow along the flow path. NSIS QoS signaling can be initiated by either the flow sender or flow receiver. Figure 3 shows an example scenario with five NSIS nodes, including flow sender node A, flow receiver node E, and intermediate NSIS nodes B, C, and D. Nodes that are not NSIS QoS capable are not shown.
通常，应用程序使用NSIS QoS信令为沿流路径的流保留资源。NSIS QoS信令可以由流发送方或流接收方发起。图3显示了具有五个NSIS节点的示例场景，包括流发送方节点A、流接收方节点E和中间NSIS节点B、C和D。未显示不支持NSIS QoS的节点。
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 3: Example Scenario of NSIS QoS Signaling
图3:NSIS QoS信令的示例场景
Figure 4 illustrates a sender-initiated signaling sequence in the scenario of Figure 3. Sender node A sends a RESERVE message towards receiver node E. The RESERVE message gets forwarded by intermediate NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver node E then sends back a RESPONSE message confirming the QoS reservation, again through the previous intermediate NSIS nodes in the flow path.
图4展示了图3场景中发送方发起的信令序列。发送方节点A向接收方节点E发送保留消息。保留消息由中间NSIS节点B、C和D转发，最后到达接收方节点E。接收方节点E然后再次通过流路径中的先前中间NSIS节点发回确认QoS保留的响应消息。
There are two important aspects in the above signaling process that are worth mentioning. First, the flow sender does not initially know exactly which intermediate nodes are NSIS-aware and should be involved in the signaling process for a flow from node A to node E. Discovery of those nodes (namely, nodes B, C, and D) is accomplished by a separate NSIS peer discovery process (not shown above; see [RFC5971]). The NSIS peer discovery messages contain special IP header and payload formats or include a Router Alert Option (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery messages allow nodes B, C, and D to intercept the messages and subsequently insert themselves into the signaling path for the flow in question. After formation of the signaling path, all signaling messages corresponding to this flow will be passed to these nodes for processing. Other nodes that are not NSIS-aware simply forward all signaling messages, as they would any other IP packets that do not require additional handling.
上述信令过程中有两个重要方面值得一提。首先，流发送方最初并不确切知道哪些中间节点是NSIS感知的，并且应该参与从节点a到节点E的流的信令过程。这些节点（即节点B、C和D）的发现是通过单独的NSIS对等发现过程完成的（上面未显示；请参阅[RFC5971]）。NSIS对等发现消息包含特殊的IP报头和有效负载格式，或包含路由器警报选项（RAO）[RFC2113][RFC2711]。NSIS发现消息的特殊格式允许节点B、C和D截获消息，并随后将其自身插入到相关流的信令路径中。在形成信令路径之后，与该流相对应的所有信令消息将被传递到这些节点进行处理。其他不知道NSIS的节点只是转发所有信令消息，就像它们转发不需要额外处理的任何其他IP数据包一样。
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | | |
| +------------->| | |
| | | RESERVE | |
| | +------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | | RESPONSE | |
| | |<-------------+ |
| | RESPONSE | | |
| |<-------------+ | |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | | |
| +------------->| | |
| | | RESERVE | |
| | +------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | | RESPONSE | |
| | |<-------------+ |
| | RESPONSE | | |
| |<-------------+ | |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 4: Sender-Initiated NSIS QoS Signaling
图4：发送方发起的NSIS QoS信令
Second, the goal of QoS signaling is to install control information to give QoS treatment for the flow being signaled. Basic QoS control information includes the data Flow ID for packet classification and the type of QoS treatment those packets are entitled to. The Flow ID contains a set of header fields such as flow sender and receiver addresses, and protocol and port numbers.
第二，QoS信令的目标是安装控制信息，为被信令的流提供QoS处理。基本QoS控制信息包括用于分组分类的数据流ID以及这些分组有权获得的QoS处理的类型。流ID包含一组头字段，如流发送方和接收方地址、协议和端口号。
Now consider Figure 5 where nodes B, C, and D are endpoints and intermediate nodes of an IP tunnel. During the signaling path discovery process, node B can still intercept and process NSIS peer discovery messages if it recognizes them before performing tunnel encapsulation; node D can identify NSIS peer discovery messages after performing tunnel decapsulation. A tunnel intermediate node such as node C, however, only sees the tunnel header of the packets and will not be able to identify the original NSIS peer discovery message or insert itself in the flow signaling path. Furthermore, the Flow ID of the original flow is based on IP header fields of the original packet. Those fields are also hidden in the payload of the tunnel packet. So, there is no way node C can classify packets belonging to that flow in the tunnel.
现在考虑图5，其中节点B、C和D是IP隧道的端点和中间节点。在信令路径发现过程中，如果节点B在执行隧道封装之前识别出NSIS对等发现消息，则节点B仍然可以拦截和处理NSIS对等发现消息；节点D可以在执行隧道解封装后识别NSIS对等发现消息。然而，诸如节点C之类的隧道中间节点仅看到分组的隧道报头，并且将不能识别原始NSIS对等发现消息或将其自身插入流信令路径中。此外，原始流的流ID基于原始分组的IP报头字段。这些字段也隐藏在隧道数据包的有效负载中。因此，节点C无法在隧道中对属于该流的数据包进行分类。
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel
图5：具有IP隧道的NSIS QoS信令示例场景
In summary, an IP tunnel segment normally appears like a QoS-unaware virtual link. Since the best QoS of an end-to-end path is judged based on its weakest segment, we need a mechanism to extend NSIS into the IP tunnel segments, which should allow the tunnel intermediate nodes to intercept original NSIS signaling messages and classify original data flow packets in the presence of tunnel encapsulation.
总之，IP隧道段通常看起来像一个不考虑QoS的虚拟链路。由于端到端路径的最佳QoS是根据其最薄弱的部分来判断的，因此我们需要一种将NSIS扩展到IP隧道段的机制，该机制应允许隧道中间节点拦截原始NSIS信令消息，并在存在隧道封装的情况下对原始数据流分组进行分类。
We identify the following design requirements for NSIS operating over IP tunnels.
我们确定了IP隧道上运行的NSI的以下设计要求。
o The mechanism should work with all common IP tunneling protocols listed in Section 3.1.
o 该机制应适用于第3.1节中列出的所有通用IP隧道协议。
o Some IP tunnels maintain preconfigured QoS sessions inside the tunnel. The mechanism should work for IP tunnels both with and without preconfigured tunnel QoS sessions.
o 一些IP隧道在隧道内维护预配置的QoS会话。该机制应适用于具有和不具有预配置的隧道QoS会话的IP隧道。
o The mechanism should minimize the required upgrade to existing infrastructure in order to facilitate its deployment. Specifically, we should limit the necessary upgrade to the tunnel endpoints.
o 该机制应尽量减少对现有基础设施的升级，以便利其部署。具体来说，我们应该限制对隧道端点的必要升级。
o The mechanism should provide a method for one NSIS-tunnel-aware endpoint to discover whether the other endpoint is also NSIS-tunnel-aware, when necessary.
o 该机制应为一个NSIS隧道感知端点提供一种方法，以便在必要时发现另一个端点是否也是NSIS隧道感知的。
o The mechanism should learn from the design experience of previous related work on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also addressing the following major differences of NSIS from
o 该机制应借鉴先前在RSVP-over-IP隧道（RSVP-TUNNEL）[RFC2746]上的相关工作的设计经验，同时还应解决NSI与其他NSI的以下主要差异
RSVP. First, NSIS is designed as a generic framework to accommodate various signaling application needs, and therefore is split into a signaling transport layer and a signaling application layer; RSVP does not have a layer split and is designed only for QoS signaling. Second, NSIS QoS NSLP allows both sender-initiated and receiver-initiated reservations; RSVP only supports receiver-initiated reservations. Third, NSIS deals only with unicast; RSVP also supports multicast. Fourth, NSIS integrates a new SESSION-ID feature which is different from the session identification concept in RSVP.
RSVP。首先，NSIS被设计为一个通用框架，以适应各种信令应用需求，因此被分为信令传输层和信令应用层；RSVP没有层拆分，仅设计用于QoS信令。第二，NSIS QoS NSLP允许发送方发起和接收方发起的预约；RSVP仅支持接收方发起的预订。第三，NSIS只处理单播；RSVP还支持多播。第四，NSIS集成了一个新的会话ID功能，这与RSVP中的会话标识概念不同。
The overall design of this NSIS signaling and IP tunnel interworking mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is tailored and extended for NSIS operation.
该NSIS信令和IP隧道互通机制的总体设计借鉴了RSVP-tunnel[RFC2746]的类似概念，但针对NSIS操作进行了定制和扩展。
Since we only consider unidirectional flows, to accommodate flows in both directions of a tunnel, we require both tunnel entry-point and tunnel exit-point to be NSIS-tunnel-aware. An NSIS-tunnel-aware endpoint knows whether the other tunnel endpoint is NSIS-tunnel-aware either through preconfiguration or through an NSIS-tunnel capability discovery mechanism defined in Section 7.
由于我们只考虑单向流，以适应在隧道的两个方向上的流动，我们要求隧道入口点和隧道出口点都是NSIS隧道感知。NSIS隧道感知端点通过预配置或第7节中定义的NSIS隧道能力发现机制知道另一个隧道端点是否为NSIS隧道感知端点。
Tunnel endpoints need to always intercept NSIS peer discovery messages and insert themselves into the NSIS signaling path so they can receive all NSIS signaling messages and coordinate their interaction with tunnel QoS.
隧道端点需要始终截获NSIS对等发现消息并将其自身插入NSIS信令路径，以便它们能够接收所有NSIS信令消息并协调它们与隧道QoS的交互。
To facilitate QoS handling in the tunnel, an end-to-end QoS session is mapped to a tunnel QoS session, either preconfigured or dynamically created. The tunnel session uses a tunnel Flow ID based on information available in the tunnel headers, thus allowing tunnel intermediate nodes to classify flow packets correctly.
为了促进隧道中的QoS处理，端到端QoS会话被映射到隧道QoS会话（预配置或动态创建）。隧道会话使用基于隧道头中可用信息的隧道流ID，从而允许隧道中间节点正确分类流包。
For tunnels that maintain preconfigured QoS sessions, upon receiving a request to reserve resources for an end-to-end session, the tunnel endpoint maps the end-to-end QoS session to an existing tunnel session. To simplify the design, the mapping decision is always made by the tunnel entry-point, regardless of whether the end-to-end session uses sender-initiated or receiver-initiated NSIS signaling mode. The details about which end-to-end session can be mapped to which preconfigured tunnel session depend on policy mechanisms outside the scope of this document.
对于维护预配置QoS会话的隧道，在接收到为端到端会话保留资源的请求时，隧道端点将端到端QoS会话映射到现有的隧道会话。为了简化设计，无论端到端会话使用发送方发起还是接收方发起的NSIS信令模式，映射决策始终由隧道入口点做出。有关哪些端到端会话可以映射到哪个预配置的隧道会话的详细信息取决于本文档范围之外的策略机制。
For tunnels that do not maintain preconfigured QoS sessions, the NSIS-tunnel-aware endpoints dynamically create and manage a corresponding tunnel QoS session for the end-to-end session. Since
对于不维护预配置的QoS会话的隧道，NSIS隧道感知端点会为端到端会话动态创建和管理相应的隧道QoS会话。自从
the initiation mode of both QoS sessions can be sender-initiated or receiver-initiated, to simplify the design, we require that the initiation mode of the tunnel QoS session follows that of the end-to-end QoS session. In other words, the end-to-end QoS session and its corresponding tunnel QoS session are either both sender-initiated or both receiver-initiated. To keep the handling mechanism consistent with the case for tunnels with preconfigured QoS sessions, the tunnel entry-point always initiates the mapping between the tunnel session and the end-to-end session.
两种QoS会话的发起模式可以是发送方发起或接收方发起，为了简化设计，我们要求隧道QoS会话的发起模式遵循端到端QoS会话的发起模式。换句话说，端到端QoS会话及其对应的隧道QoS会话要么都是发送方发起的，要么都是接收方发起的。为了使处理机制与具有预配置QoS会话的隧道保持一致，隧道入口点始终启动隧道会话和端到端会话之间的映射。
As the mapping initiator, the tunnel entry-point records the association between the end-to-end session and its corresponding tunnel session, both in tunnels with and without preconfigured QoS sessions. This association serves two purposes, one for the signaling plane and the other for the data plane. For the signaling plane, the association enables the tunnel entry-point to coordinate necessary interactions between the end-to-end and the tunnel QoS sessions, such as QoS adjustment in sender-initiated reservations. For the data plane, the association allows the tunnel entry-point to correctly encapsulate data flow packets according to the chosen tunnel Flow ID. Since the tunnel Flow ID uses header fields that are visible inside the tunnel, the tunnel intermediate nodes can classify the data flow packets and apply appropriate QoS treatment.
作为映射启动器，隧道入口点记录端到端会话与其对应的隧道会话之间的关联，包括在具有和不具有预配置QoS会话的隧道中。此关联用于两个目的，一个用于信令平面，另一个用于数据平面。对于信令平面，关联使得隧道入口点能够协调端到端和隧道QoS会话之间的必要交互，例如发送方发起的预留中的QoS调整。对于数据平面，关联允许隧道入口点根据选择的隧道流ID正确封装数据流包。由于隧道流ID使用隧道内可见的报头字段，隧道中间节点可以对数据流包进行分类并应用适当的QoS处理。
In addition to the tunnel entry-point recording the association between the end-to-end session and its corresponding tunnel session, the tunnel exit-point also needs to maintain the same association for similar reasons. For the signaling plane, this association at the tunnel exit-point enables the interaction of the end-to-end and the tunnel QoS session such as QoS adjustment in receiver-initiated reservations. For the data plane, this association tells the tunnel exit-point that the relevant data flow packets need to be decapsulated according to the corresponding tunnel Flow ID.
除了隧道入口点记录端到端会话与其对应隧道会话之间的关联外，隧道出口点还需要出于类似原因保持相同的关联。对于信令平面，隧道出口点处的这种关联能够实现端到端和隧道QoS会话的交互，例如接收机发起的预留中的QoS调整。对于数据平面，该关联告诉隧道出口点，需要根据相应的隧道流ID对相关数据流分组进行解封。
In tunnels with preconfigured QoS sessions, the tunnel exit-point may also learn about the mapping information between the corresponding tunnel and end-to-end QoS sessions through preconfiguration as well. In tunnels without preconfigured QoS sessions, the tunnel exit-point knows the mapping between the corresponding tunnel and end-to-end QoS sessions through the NSIS signaling process that creates the tunnel QoS sessions inside the tunnel, with the help of appropriate QoS NSLP session-binding and message-binding mechanisms.
在具有预配置的QoS会话的隧道中，隧道出口点还可以通过预配置来了解相应的隧道和端到端QoS会话之间的映射信息。在没有预配置QoS会话的隧道中，隧道出口点通过NSIS信令过程知道相应隧道和端到端QoS会话之间的映射，NSIS信令过程在适当的QoS NSLP会话绑定和消息绑定机制的帮助下在隧道内创建隧道QoS会话。
One problem for NSIS operating over IP tunnels that dynamically create QoS sessions is that it involves two signaling sequences. The outcome of the tunnel signaling session directly affects the outcome of the end-to-end signaling session. Since the two signaling sessions overlap in time, there are circumstances when a tunnel
在动态创建QoS会话的IP隧道上运行的NSI的一个问题是，它涉及两个信令序列。隧道信令会话的结果直接影响端到端信令会话的结果。由于两个信令会话在时间上重叠，因此存在以下情况：
endpoint has to decide whether it should proceed with the end-to-end signaling session while it is still waiting for results of the tunnel session. This problem can be addressed in two ways, namely sequential mode and parallel mode. In sequential mode, end-to-end signaling pauses while it is waiting for results of tunnel signaling, and resumes upon receipt of the tunnel signaling outcome. In parallel mode, end-to-end signaling continues outside the tunnel while tunnel signaling is still in process and its outcome is unknown. The parallel mode may lead to reduced signaling delays if the QoS resources in the tunnel path are sufficient compared to the rest of the end-to-end path. If the QoS resources in the tunnel path are more constraint than the rest of the end-to-end path, however, the parallel mode may lead to wasted end-to-end signaling or may necessitate renegotiation after the tunnel signaling outcome becomes available. In those cases, the signaling flow of the parallel mode also tends to be complicated. This document adopts a sequential mode approach for the two signaling sequences.
端点在等待隧道会话的结果时，必须决定是否应继续进行端到端信令会话。这个问题可以用两种方式解决，即顺序模式和并行模式。在顺序模式中，端到端信令在等待隧道信令结果时暂停，并在接收到隧道信令结果时恢复。在并行模式下，端到端信令在隧道外继续，而隧道信令仍在进行中，其结果未知。如果与端到端路径的其余部分相比，隧道路径中的QoS资源足够，则并行模式可导致减少信令延迟。然而，如果隧道路径中的QoS资源比端到端路径的其余部分更受约束，则并行模式可能导致浪费端到端信令，或者可能需要在隧道信令结果变得可用后重新协商。在这些情况下，并行模式的信令流也趋于复杂。本文件对两个信令序列采用顺序模式方法。
A tunnel Flow ID identifies the end-to-end flow for packet classification within the tunnel. The tunnel Flow ID is based on a set of tunnel header fields. Different tunnel Flow IDs can be chosen for different tunneling mechanisms in order to minimize the classification overhead. This document specifies the following Flow ID formats for the respective tunneling protocols.
隧道流ID标识隧道内分组分类的端到端流。隧道流ID基于一组隧道标题字段。可以为不同的隧道机制选择不同的隧道流ID，以最小化分类开销。本文件规定了各隧道协议的以下流ID格式。
o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID consists of the tunnel entry-point IPv6 address and the tunnel exit-point IPv6 address plus a unique IPv6 flow label [RFC3697].
o 对于IPv6隧道协议（IPv6GEN），隧道流ID由隧道入口点IPv6地址和隧道出口点IPv6地址以及唯一的IPv6流标签组成[RFC3697]。
o For IPsec tunnel mode (IPsec), the tunnel Flow ID contains the tunnel entry-point IP address and the tunnel exit-point IP address plus the Security Parameter Index (SPI).
o 对于IPsec隧道模式（IPsec），隧道流ID包含隧道入口点IP地址和隧道出口点IP地址以及安全参数索引（SPI）。
o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional UDP header between the tunnel header and the original packet. The Flow ID consists of the tunnel entry-point and tunnel exit-point IP addresses and the source port number in the additional UDP header. The source port number is dynamically chosen by the tunnel entry-point and conveyed to the tunnel exit-point. In these cases, it is especially important that the tunnel exit-point understands the additional UDP encapsulation, and therefore can correctly decapsulate both the normal tunnel header and the additional UDP header. In other words, both tunnel endpoints need to be NSIS-tunnel-aware.
o 对于所有其他隧道协议（GRE、GREPV4、IPv4INIPv4、MINENC、IPv6INIPv4），隧道入口点在隧道头和原始数据包之间插入额外的UDP头。流ID由隧道入口点和隧道出口点IP地址以及附加UDP标头中的源端口号组成。源端口号由隧道入口点动态选择，并传送到隧道出口点。在这些情况下，隧道出口点了解附加UDP封装，因此能够正确地解除普通隧道标头和附加UDP标头的封装，这一点尤为重要。换句话说，两个隧道端点都需要NSIS隧道感知。
The above recommendations about choosing the tunnel Flow ID apply to dynamically created QoS tunnel sessions. For preconfigured QoS tunnel sessions, the corresponding Flow ID is determined by the configuration mechanism itself. For example, if the tunnel QoS is Diffserv based, the Diffserv Code Point (DSCP) field value may be used to identify the corresponding tunnel session.
上述关于选择隧道流ID的建议适用于动态创建的QoS隧道会话。对于预配置的QoS隧道会话，相应的流ID由配置机制本身确定。例如，如果隧道QoS基于Diffserv，则Diffserv码点（DSCP）字段值可用于标识相应的隧道会话。
When tunnel QoS is managed by preconfigured QoS sessions, both the tunnel entry-point and tunnel exit-point need to be configured with information about the Flow ID of the tunnel QoS session. This allows the tunnel endpoints to correctly perform matching encapsulating and decapsulating operations. The procedures of NSIS operating over tunnels with preconfigured QoS sessions depend on whether the end-to-end NSIS signaling is sender-initiated or receiver-initiated. But in both cases, it is the tunnel entry-point that first creates the mapping between a tunnel session and an end-to-end session.
当隧道QoS由预配置的QoS会话管理时，隧道入口点和隧道出口点都需要配置有关隧道QoS会话的流ID的信息。这允许隧道端点正确执行匹配的封装和解封装操作。NSIS在具有预配置QoS会话的隧道上运行的过程取决于端到端NSIS信令是发送方发起的还是接收方发起的。但在这两种情况下，首先创建隧道会话和端到端会话之间映射的是隧道入口点。
Figure 6 illustrates the signaling sequence when end-to-end signaling outside the tunnel is sender-initiated. Upon receiving a RESERVE message from the sender, Tentry checks the tunnel QoS configuration, determines whether and how this end-to-end session can be mapped to a preconfigured tunnel session. The mapping criteria are part of the preconfiguration and outside the scope of this document. Tentry then tunnels the RESERVE message to Texit. Texit forwards the RESERVE message to the receiver. The receiver replies with a RESPONSE message that arrives at Texit, Tentry, and finally the sender. If the RESPONSE message that Tentry receives confirms that the overall signaling is successful, Tentry starts to encapsulate all incoming packets of the data flow using the tunnel Flow ID corresponding to the mapped tunnel session. Texit knows how to decapsulate the tunnel packets because it recognizes the mapped tunnel Flow ID based on information supplied during tunnel session preconfiguration.
图6说明了当发送方启动隧道外部的端到端信令时的信令序列。在收到来自发送方的保留消息后，Tentry检查隧道QoS配置，确定此端到端会话是否以及如何映射到预配置的隧道会话。映射标准是预配置的一部分，不在本文件范围内。然后Tentry将保留消息隧道传输到Texit。Texit将保留消息转发给接收方。接收者回复一条响应消息，该消息到达Texit、Tentry，最后到达发送者。如果Tentry接收的响应消息确认整个信令成功，Tentry开始使用对应于映射的隧道会话的隧道流ID封装数据流的所有传入分组。Texit知道如何解除隧道数据包的封装，因为它根据隧道会话预配置期间提供的信息识别映射的隧道流ID。
Sender Tentry Tmid Texit Receiver
发送器Tentry Tmid Texit接收器
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 6: Sender-Initiated End-to-End Session with Preconfigured Tunnel QoS Sessions
图6：发送方发起的具有预配置隧道QoS会话的端到端会话
Figure 7 shows the signaling sequence when end-to-end signaling outside the tunnel is receiver-initiated. Upon receiving the first end-to-end Query message, Tentry examines the tunnel QoS configuration, then updates and tunnels the Query message to Texit. Texit decapsulates the QUERY message, processes it, and forwards it toward the receiver. The receiver sends back a RESERVE message passing through Texit and arriving at Tentry. Tentry decides on whether and how the QoS request for this end-to-end session can be mapped to a preconfigured tunnel session based on criteria outside the scope of this document. Then, Tentry forwards the RESERVE message towards the sender. The signaling continues until a RESPONSE message arrives at Tentry, Texit, and finally the receiver. If the RESPONSE message that Tentry receives confirms that the overall signaling is successful, Tentry starts to encapsulate all incoming packets of the data flow using the tunnel Flow ID corresponding to the mapped tunnel session. Similarly, Texit knows how to decapsulate the tunnel packets because it recognizes the mapped tunnel Flow ID based on information supplied during tunnel session preconfiguration.
图7显示了当隧道外的端到端信令被接收器启动时的信令序列。在收到第一个端到端查询消息后，Tentry检查隧道QoS配置，然后更新查询消息并将其隧道到Texit。Texit解除对查询消息的封装，对其进行处理，并将其转发给接收方。接收方通过Texit发回保留消息，并到达Tentry。Tentry根据本文档范围之外的标准决定是否以及如何将此端到端会话的QoS请求映射到预配置的隧道会话。然后，Tentry将保留消息转发给发送方。信令将继续，直到响应消息到达Tentry、Texit，最后到达接收器。如果Tentry接收的响应消息确认整个信令成功，Tentry开始使用对应于映射的隧道会话的隧道流ID封装数据流的所有传入分组。类似地，Texit知道如何解除隧道数据包的封装，因为它根据隧道会话预配置期间提供的信息识别映射的隧道流ID。
Since separate tunnel QoS signaling is not involved in preconfigured QoS tunnels, Figures 6 and 7 make the tunnel look like a single virtual link. The signaling path simply skips all tunnel intermediate nodes. However, both Tentry and Texit need to deploy the NSIS-tunnel-related functionalities described above, including acting on the end-to-end NSIS signaling messages based on tunnel QoS
由于预先配置的QoS隧道中不涉及单独的隧道QoS信令，图6和图7使隧道看起来像一个单独的虚拟链路。信令路径只是跳过所有隧道中间节点。然而，Tentry和Texit都需要部署上述NSIS隧道相关功能，包括基于隧道QoS作用于端到端NSIS信令消息
status, mapping end-to-end and tunnel QoS sessions, and correctly encapsulating and decapsulating tunnel packets according to the tunnel protocol and the configured tunnel Flow ID.
状态，映射端到端和隧道QoS会话，并根据隧道协议和配置的隧道流ID正确封装和解除封装隧道数据包。
Sender Tentry Tmid Texit Receiver
发送器Tentry Tmid Texit接收器
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
Figure 7: Receiver-Initiated End-to-End Session with Preconfigured Tunnel QoS Sessions
图7：具有预配置隧道QoS会话的接收器启动的端到端会话
When there are no preconfigured tunnel QoS sessions, a tunnel can apply the same NSIS QoS signaling mechanism used for the end-to-end path to manage the QoS inside the tunnel. The tunnel NSIS signaling involves only those NSIS nodes in the tunnel forwarding path. The Flow IDs for the tunnel signaling are based on tunnel header fields. NSIS peer discovery messages inside the tunnel distinguish themselves using the tunnel header fields, which solves the problem for tunnel intermediate NSIS nodes to intercept signaling messages.
当没有预配置的隧道QoS会话时，隧道可以应用用于端到端路径的相同NSIS QoS信令机制来管理隧道内的QoS。隧道NSIS信令仅涉及隧道转发路径中的那些NSIS节点。隧道信令的流ID基于隧道头字段。隧道内的NSIS对等发现消息使用隧道头字段进行区分，这解决了隧道中间NSIS节点拦截信令消息的问题。
When tunnel endpoints dynamically create tunnel QoS sessions, the initiation mode of the tunnel session always follows the initiation mode of the end-to-end session. Specifically, when the end-to-end session is sender-initiated, the tunnel session should also be sender-initiated; when the end-to-end session is receiver-initiated, the tunnel session should also be receiver-initiated.
当隧道端点动态创建隧道QoS会话时，隧道会话的启动模式始终遵循端到端会话的启动模式。具体而言，当端到端会话由发送方发起时，隧道会话也应由发送方发起；当端到端会话由接收器启动时，隧道会话也应由接收器启动。
The tunnel entry-point conveys the corresponding tunnel Flow ID associated with an end-to-end session to the tunnel exit-point during the tunnel signaling process. The tunnel entry-point also informs the exit-point of the binding between the corresponding tunnel session and end-to-end session through the BOUND_SESSION_ID QoS NSLP message object. The reservation message dependencies between the tunnel session and end-to-end session are resolved using the MSG-ID and BOUND-MSG-ID objects of the QoS NSLP message binding mechanism.
在隧道信令过程中，隧道入口点将与端到端会话相关联的对应隧道流ID传送到隧道出口点。隧道入口点还通过绑定的会话ID QoS NSLP消息对象通知出口点相应的隧道会话和端到端会话之间的绑定。隧道会话和端到端会话之间的保留消息依赖关系是使用QoS NSLP消息绑定机制的MSG-ID和bind-MSG-ID对象解决的。
Figure 8 shows the typical messaging sequence of how NSIS operates over IP tunnels when both the end-to-end session and tunnel session are sender-initiated. Tunnel signaling messages are distinguished from end-to-end messages by a prime symbol after the message name. The sender first sends an end-to-end RESERVE message (1) that arrives at Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel session, and associates the end-to-end session with the tunnel session. Tentry then sends a tunnel RESERVE' message (2) matching the request of the end-to-end session towards Texit to reserve tunnel resources. This RESERVE' message (2) includes a MSG-ID object that contains a randomly generated 128-bit MSG-ID. Meanwhile, Tentry inserts a BOUND-MSG-ID object containing the same MSG-ID as well as a BOUND-SESSION-ID object containing the SESSION-ID of the tunnel session into the original RESERVE message, and sends this RESERVE message (3) towards Texit using normal tunnel encapsulation. The Message_Binding_Type flags of both the MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages (2, 3) are SET, indicating a bidirectional binding. The tunnel RESERVE' message (2) is processed hop-by-hop inside the tunnel for the flow identified by the chosen tunnel Flow ID, while the end-to-end RESERVE message (3) passes through the tunnel intermediate nodes (Tmid) just like other tunneled packets. These two messages could arrive at Texit in different orders, and the reaction of Texit in these different situations should combine the tunnel QoS message processing rules with the QoS NSLP processing principles for message binding [RFC5974], as illustrated below.
图8显示了当端到端会话和隧道会话都由发送方发起时，NSIS如何通过IP隧道运行的典型消息传递序列。隧道信令消息与端到端消息的区别在于消息名称后面有一个基本符号。发送方首先发送到达Tentry的端到端保留消息（1）。Tentry选择隧道流ID，创建隧道会话，并将端到端会话与隧道会话关联。然后Tentry向Texit发送与端到端会话的请求相匹配的“隧道保留”消息（2），以保留隧道资源。此保留消息（2）包括一个包含随机生成的128位MSG-ID的MSG-ID对象。同时，Tentry将包含相同MSG-ID的绑定MSG-ID对象以及包含隧道会话会话ID的绑定会话ID对象插入原始保留消息，并发送此保留消息（3）使用普通隧道封装。设置了RESERVE'和RESERVE消息（2，3）中MSG-ID和bind-MSG-ID对象的Message_Binding_Type标志，表示双向绑定。隧道保留消息（2）在隧道内逐跳处理由所选隧道流ID标识的流，而端到端保留消息（3）与其他隧道包一样通过隧道中间节点（Tmid）。这两条消息可能以不同的顺序到达Texit，Texit在这些不同情况下的反应应该将隧道QoS消息处理规则与用于消息绑定的QoS NSLP处理原则结合起来[RFC5974]，如下所示。
The first possibility is shown in the example messaging flow of Figure 8, where the tunnel RESERVE' message (2), also known as the triggering message in QoS NSLP message binding terms, arrives first. Since the message binding is bidirectional, Texit records the MSG-ID of the RESERVE' message (2), enqueues it and starts a MsgIDWait timer waiting for the end-to-end RESERVE message (3), also known as the bound signaling message in QoS NSLP message binding terms. The timer
第一种可能性如图8的示例消息流所示，其中隧道保留消息（2），在QoS NSLP消息绑定术语中也称为触发消息，首先到达。由于消息绑定是双向的，Texit会记录保留消息（2）的MSG-ID，将其排队并启动MsgIDWait计时器，等待端到端保留消息（3），在QoS NSLP消息绑定术语中也称为绑定信令消息。计时器
Sender Tentry Tmid Texit Receiver
发送器Tentry Tmid Texit接收器
| | | | |
| RESERVE(1) | | | |
+------------->| | | |
| | RESERVE'(2) | | |
| +=============>| | |
| | | RESERVE'(2) | |
| | +=============>| |
| | RESERVE(3) | |
| +---------------------------->| |
| | | RESPONSE'(4) | |
| | |<=============+ |
| | RESPONSE'(4) | | |
| |<=============+ | |
| | | | RESERVE(5) |
| | | +------------->|
| | | | RESPONSE(6) |
| | | |<-------------+
| | RESPONSE(6) | |
| |<----------------------------+ |
| RESPONSE(6) | | | |
|<-------------+ | | |
| | | | |
| | | | |
| | | | |
| RESERVE(1) | | | |
+------------->| | | |
| | RESERVE'(2) | | |
| +=============>| | |
| | | RESERVE'(2) | |
| | +=============>| |
| | RESERVE(3) | |
| +---------------------------->| |
| | | RESPONSE'(4) | |
| | |<=============+ |
| | RESPONSE'(4) | | |
| |<=============+ | |
| | | | RESERVE(5) |
| | | +------------->|
| | | | RESPONSE(6) |
| | | |<-------------+
| | RESPONSE(6) | |
| |<----------------------------+ |
| RESPONSE(6) | | | |
|<-------------+ | | |
| | | | |
| | | | |
(1,5): RESERVE w/o BOUND-MSG-ID and BOUND-SESSION-ID
(2): RESERVE' w/ MSG-ID
(3): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
(1,5): RESERVE w/o BOUND-MSG-ID and BOUND-SESSION-ID
(2): RESERVE' w/ MSG-ID
(3): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
Figure 8: Sender-Initiated Reservation for Both End-to-End and Tunnel Signaling
图8：发送方发起的端到端和隧道信令预留
value is set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3) arrives, Texit notices that there is an existing stored MSG-ID which matches the MSG-ID in the BOUND-MSG-ID object of the incoming RESERVE message (3). Therefore, the message binding condition has been satisfied. Texit resumes processing of the tunnel RESERVE' message (2), creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' message (4) to Tentry. At the same time, Texit checks the BOUND-SESSION-ID object of the end-to-end RESERVE message (3) and records the binding of the corresponding tunnel session with the end-to-end session. Texit also updates the end-to-end RESERVE message based on the result of the tunnel session reservation, removes its tunnel BOUND-SESSION-ID and BOUND-MSG-ID object and forwards the end-to-end RESERVE message (5) along the path towards
值设置为默认的重新传输超时时间QOSNSLP\u请求\u重试。当端到端保留消息（3）到达时，Texit注意到存在与传入保留消息（3）的绑定-MSG-ID对象中的MSG-ID匹配的现有存储的MSG-ID。因此，消息绑定条件已经满足。Texit恢复处理隧道保留“消息（2），为隧道会话创建保留状态，并向Tentry发送隧道响应”消息（4）。同时，Texit检查端到端保留消息（3）的绑定会话ID对象，并记录相应隧道会话与端到端会话的绑定。Texit还根据隧道会话保留的结果更新端到端保留消息，删除其隧道绑定会话ID和绑定消息ID对象，并沿路径转发端到端保留消息（5）
the receiver. When the receiver receives the end-to-end RESERVE message (5), it sends an end-to-end RESPONSE message (6) back to the sender.
接受者。当接收器接收到端到端保留消息（5）时，它将端到端响应消息（6）发送回发送者。
The second possibility is that the end-to-end RESERVE message arrives before the tunnel RESERVE' message at Texit. In that case, Texit notices a BOUND-SESSION-ID object and a BOUND-MSG-ID object in the end-to-end RESERVE message, but realizes that the tunnel session does not exist yet. So, Texit enqueues the RESERVE message and starts a MsgIDWait timer. The timer value is set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the corresponding tunnel RESERVE' message arrives with a MSG-ID matching that of the outstanding BOUND-MSG-ID object, the message binding condition is satisfied. Texit sends a tunnel RESPONSE' message back to Tentry and updates the end-to-end RESERVE message by incorporating the result of the tunnel session reservation, as well as removing the tunnel BOUND-SESSION-ID and BOUND-MSG-ID objects. Texit then forwards the end-to-end RESERVE message along the path towards the receiver. When the receiver receives the end-to-end RESERVE message, it sends an end-to-end RESPONSE message back to the sender.
第二种可能性是，端到端保留消息在隧道保留消息到达Texit之前到达。在这种情况下，Texit在端到端保留消息中注意到一个绑定会话ID对象和一个绑定消息ID对象，但意识到隧道会话还不存在。因此，Texit将保留消息排入队列，并启动MsgIDWait计时器。计时器值设置为默认的重新传输超时时间QOSNSLP_请求_重试。当相应的tunnel RESERVE消息到达时，其MSG-ID与未完成的绑定MSG-ID对象的MSG-ID匹配，则满足消息绑定条件。Texit将隧道响应消息发送回Tentry，并通过合并隧道会话保留的结果以及删除隧道绑定会话ID和绑定消息ID对象来更新端到端保留消息。然后，Texit沿着通向接收器的路径转发端到端保留消息。当接收方接收到端到端保留消息时，它会将端到端响应消息发送回发送方。
Yet another possibility is that the tunnel RESERVE' message arrives at Texit first, but the end-to-end RESERVE message never arrives. In that case, the MsgIDWait timer for the queued tunnel RESERVE' message will expire. Texit should then send a tunnel RESPONSE' message back to Tentry indicating a reservation error has occurred, and discard the tunnel RESERVE' message. The last possibility is that the end-to-end RESERVE message arrives at Texit first, but the tunnel RESERVE' message never arrives. In that case, the MsgIDWait timer for the queued end-to-end RESERVE message will expire. Texit should then treat this situation as a local reservation failure, and according to [RFC5974], Texit as a stateful QoS NSLP should generate an end-to-end RESPONSE message indicating RESERVE error to the sender.
另一种可能性是隧道保留消息首先到达Texit，但端到端保留消息从未到达。在这种情况下，“排队隧道保留”消息的MsgIDWait计时器将过期。Texit然后应向Tentry发送一条隧道响应“消息，指示发生了保留错误，并放弃隧道保留”消息。最后一种可能性是端到端保留消息首先到达Texit，但隧道保留消息从未到达。在这种情况下，排队的端到端保留消息的MsgIDWait计时器将过期。然后，Texit应将这种情况视为本地保留失败，根据[RFC5974]，Texit作为有状态QoS NSLP应生成一条向发送方指示保留错误的端到端响应消息。
Once the end-to-end and the tunnel QoS session have both been successfully created and associated, the tunnel endpoints Tentry and Texit coordinate the signaling between the two sessions and make sure that adjustment or teardown of either session may trigger similar actions for the other session as necessary, by invoking appropriate signaling messages.
一旦成功创建并关联了端到端和隧道QoS会话，隧道端点Tentry和Texit将协调两个会话之间的信令，并确保根据需要调整或拆除任一会话可触发另一会话的类似操作，通过调用适当的信令消息。
Figure 9 shows the typical messaging sequence of how NSIS signaling operates over IP tunnels when both end-to-end and tunnel sessions are receiver-initiated. Upon receiving an end-to-end QUERY message (1) from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel
图9显示了当端到端会话和隧道会话都由接收器发起时，NSIS信令如何通过IP隧道运行的典型消息传递序列。从发送方接收到端到端查询消息（1）后，Tentry选择隧道流ID并发送隧道
Sender Tentry Tmid Texit Receiver
发送器Tentry Tmid Texit接收器
| | | | |
| QUERY(1) | | | |
+------------->| | | |
| | QUERY'(2) | | |
| +=============>| | |
| | | QUERY'(2) | |
| | +=============>| |
| | | RESPONSE'(3) | |
| | |<=============+ |
| | RESPONSE'(3) | | |
| |<=============+ | |
| | QUERY(4) | |
| +---------------------------->| |
| | | | QUERY(5) |
| | | +------------->|
| | | | RESERVE(6) |
| | | |<-------------+
| | | RESERVE'(7) | |
| | |<=============+ |
| | RESERVE'(7) | | |
| |<=============+ | |
| | RESERVE(8) | |
| |<----------------------------+ |
| | RESPONSE'(9) | | |
| +=============>| | |
| | | RESPONSE'(9) | |
| | +=============>| |
| RESERVE(10) | | | |
|<-------------+ | | |
| RESPONSE(11) | | | |
+------------->| | | |
| | RESPONSE(11) | |
| +---------------------------->| |
| | | | RESPONSE(11) |
| | | +------------->|
| | | | |
| | | | |
(1), (5): QUERY w/ RESERVE-INIT
(2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND-SESSION-ID
(6), (10): RESERVE w/o BOUND-SESSION-ID
(7): RESERVE' w/ MSG-ID
(8): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
| | | | |
| QUERY(1) | | | |
+------------->| | | |
| | QUERY'(2) | | |
| +=============>| | |
| | | QUERY'(2) | |
| | +=============>| |
| | | RESPONSE'(3) | |
| | |<=============+ |
| | RESPONSE'(3) | | |
| |<=============+ | |
| | QUERY(4) | |
| +---------------------------->| |
| | | | QUERY(5) |
| | | +------------->|
| | | | RESERVE(6) |
| | | |<-------------+
| | | RESERVE'(7) | |
| | |<=============+ |
| | RESERVE'(7) | | |
| |<=============+ | |
| | RESERVE(8) | |
| |<----------------------------+ |
| | RESPONSE'(9) | | |
| +=============>| | |
| | | RESPONSE'(9) | |
| | +=============>| |
| RESERVE(10) | | | |
|<-------------+ | | |
| RESPONSE(11) | | | |
+------------->| | | |
| | RESPONSE(11) | |
| +---------------------------->| |
| | | | RESPONSE(11) |
| | | +------------->|
| | | | |
| | | | |
(1), (5): QUERY w/ RESERVE-INIT
(2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND-SESSION-ID
(6), (10): RESERVE w/o BOUND-SESSION-ID
(7): RESERVE' w/ MSG-ID
(8): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
Figure 9: Receiver-Initiated Reservation for Both End-to-end and Tunnel Signaling
图9：端到端和隧道信令的接收器启动预留
QUERY' message (2) matching the request of the end-to-end session towards Texit. This tunnel QUERY' message (2) is meant to discover QoS characteristics of the tunnel path, rather than initiate an actual reservation. Therefore, it includes a Request Identification Information (RII) object but does not set the RESERVE-INIT flag. The tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel for the flow identified by the tunnel Flow ID. When Texit receives this tunnel QUERY' message (2), it replies with a corresponding tunnel RESPONSE' message (3) containing the tunnel path characteristics. After receiving the tunnel RESPONSE' message (3), Tentry creates the tunnel session, generates an outgoing end-to-end QUERY message (4) considering the tunnel path characteristics, appends a tunnel BOUND-SESSION-ID object containing the tunnel SESSION-ID, and sends it toward Texit using normal tunnel encapsulation. The end-to-end QUERY message (4) passes along tunnel intermediate nodes like other tunneled packets. Upon receiving this end-to-end QUERY message (4), Texit notices the tunnel session binding, creates the tunnel session state, removes the tunnel BOUND-SESSION-ID object, and forwards the end-to-end QUERY message (5) further along the path.
“查询”消息（2）与针对Texit的端到端会话的请求相匹配。此隧道查询消息（2）旨在发现隧道路径的QoS特征，而不是启动实际的保留。因此，它包括一个请求标识信息（RII）对象，但不设置REFERE-INIT标志。隧道查询“消息（2）在隧道内逐跳处理由隧道流ID标识的流。当收到此隧道查询”消息（2）时，它将使用包含隧道路径特征的相应隧道响应“消息（3）进行响应。在接收到隧道响应消息（3）后，Tentry创建隧道会话，生成考虑隧道路径特征的传出端到端查询消息（4），附加包含隧道会话ID的隧道绑定会话ID对象，并使用正常隧道封装将其发送到Texit。端到端查询消息（4）像其他隧道包一样沿着隧道中间节点传递。收到此端到端查询消息（4）后，Texit会注意到隧道会话绑定，创建隧道会话状态，删除隧道绑定的会话ID对象，并沿路径进一步转发端到端查询消息（5）。
The end-to-end QUERY message (5) arrives at the receiver and triggers a RESERVE message (6). When Texit receives the RESERVE message (6), it notices that the session is bound to a receiver-initiated tunnel session. Therefore, Texit triggers a RESERVE' message (7) toward Tentry for the tunnel session reservation. This tunnel RESERVE' message (7) includes a randomly generated 128-bit MSG-ID. Meanwhile, Texit inserts a BOUND-MSG-ID object containing the same MSG-ID and a BOUND-SESSION-ID object containing the tunnel SESSION-ID into the end-to-end RESERVE message (8), and sends it towards Tentry using normal tunnel encapsulation. The Message_Binding_Type flags of the MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages (7,8) are SET, indicating a bidirectional binding.
端到端查询消息（5）到达接收方并触发保留消息（6）。当Texit接收到RESERVE消息（6）时，它注意到会话被绑定到接收方发起的隧道会话。因此，对于隧道会话预留，Texit会向Tentry触发RESERVE消息（7）。此隧道保留消息（7）包括随机生成的128位MSG-ID。同时，Texit将包含相同MSG-ID的绑定MSG-ID对象和包含隧道会话ID的绑定会话ID对象插入端到端保留消息（8），并使用正常隧道封装将其发送到Tentry。设置了RESERVE'和RESERVE消息（7,8）中MSG-ID和bind-MSG-ID对象的Message_Binding_Type标志，表示双向绑定。
At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE message (8) could arrive in either order. In a typical case shown in Figure 9, the tunnel RESERVE' message (7) arrives first. Tentry then records the MSG-ID of the tunnel RESERVE' message (7) and starts a MsgIDWait timer. When the end-to-end RESERVE message (8) with the BOUND-MSG-ID object containing the same MSG-ID arrives, the message binding condition is satisfied. Tentry resumes processing of the tunnel RESERVE' message (7), creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' message (9) to Texit. At the same time, Tentry creates the outgoing end-to-end RESERVE message (10) by incorporating results of the tunnel session reservation and removing the BOUND-SESSION-ID and BOUND-MSG-ID
第十，隧道预留信息（7）和端到端预留信息（8）可以按任意顺序到达。在图9所示的典型情况下，tunnel RESERVE消息（7）首先到达。然后，Tentry记录隧道保留信息（7）的MSG-ID，并启动MsgIDWait计时器。当包含相同MSG-ID的绑定MSG-ID对象的端到端保留消息（8）到达时，消息绑定条件满足。Tentry继续处理隧道保留“消息（7），为隧道会话创建保留状态，并向Texit发送隧道响应”消息（9）。同时，Tentry通过合并隧道会话保留的结果并移除绑定会话ID和绑定消息ID来创建传出端到端保留消息（10）
objects, and forwards it along the path towards the sender. When the sender receives the end-to-end RESERVE message (10), it sends an end-to-end RESPONSE message (11) back to the receiver.
对象，并沿路径将其转发给发件人。当发送方接收到端到端保留消息（10）时，它将端到端响应消息（11）发送回接收方。
If the end-to-end RESERVE message arrives before the tunnel RESERVE' message at Tentry, or either of the two messages fails to arrive at Tentry, the processing rules at Tentry are similar to those of Texit in the situation discussed in Section 6.1.
如果端到端保留消息在Tentry隧道保留消息之前到达，或者两条消息中的任何一条未能到达Tentry，则Tentry的处理规则与第6.1节讨论的情况下Texit的处理规则类似。
Once the end-to-end and the tunnel QoS session have both been successfully created and associated, the tunnel endpoints Tentry and Texit coordinate the signaling between the two sessions and make sure that adjustment or teardown of either session can trigger similar actions for the other session as necessary, by invoking appropriate signaling messages.
一旦成功创建并关联了端到端和隧道QoS会话，隧道端点Tentry和Texit将协调两个会话之间的信令，并确保调整或断开任一会话都可以根据需要触发另一个会话的类似操作，通过调用适当的信令消息。
The mechanism of NSIS operating over IP tunnels requires the coordination of both tunnel endpoints in tasks such as special encapsulation and decapsulation of data flow packets according to the chosen tunnel Flow ID, as well as the possible creation and adjustment of the end-to-end and tunnel QoS sessions. Therefore, one NSIS-tunnel-aware endpoint needs to know that the other tunnel endpoint is also NSIS-tunnel-aware before initiating this mechanism of NSIS operating over IP tunnels. In some cases, especially for IP tunnels with preconfigured QoS sessions, an NSIS-tunnel-aware endpoint can learn about whether the other tunnel endpoint is also NSIS-tunnel-aware through preconfiguration. In other cases where such preconfiguration is not available, the initiating NSIS-tunnel-aware endpoint may dynamically discover the other tunnel endpoint's capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined in this section.
NSIS在IP隧道上运行的机制需要在任务中协调两个隧道端点，例如根据选择的隧道流ID对数据流分组进行特殊封装和去封装，以及可能创建和调整端到端和隧道QoS会话。因此，一个NSIS隧道感知端点需要知道另一个隧道端点也是NSIS隧道感知的，然后才能启动通过IP隧道运行的NSIS机制。在某些情况下，特别是对于具有预配置QoS会话的IP隧道，NSIS隧道感知端点可以通过预配置了解其他隧道端点是否也具有NSIS隧道感知。在此类预配置不可用的其他情况下，发起NSIS隧道感知端点可通过本节中定义的QoS NSLP节点能力隧道对象动态发现其他隧道端点的能力。
The NODE_CAPABILITY_TUNNEL object is a zero-length object with a standard NSLP object header as shown in Figure 10.
NODE_CAPABILITY_TUNNEL对象是一个零长度对象，具有标准NSLP对象头，如图10所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY_TUNNEL Object Format
图10：节点\u能力\u隧道对象格式
Type: NODE_CAPABILITY_TUNNEL (0x015) from the shared NSLP object type space
类型：共享NSLP对象类型空间中的节点\u能力\u隧道（0x015）
Length: 0
长度：0
The bits marked 'A' and 'B' define the desired behavior for objects whose Type field is not recognized. If a node does not recognize the NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward". That is, the object must be retained unchanged and forwarded as a result of message processing. This is satisfied by setting 'AB' to '10'.
标记为“A”和“B”的位定义了类型字段无法识别的对象的所需行为。如果一个节点不识别node_CAPABILITY_TUNNEL对象，则所需的行为为“Forward”。也就是说，对象必须保持不变，并作为消息处理的结果进行转发。通过将“AB”设置为“10”即可满足此要求。
The 'r' bit stands for 'reserved'.
“r”位表示“保留”。
The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or RESERVE' message by a tunnel endpoint that needs to learn about the other endpoint's capability for NSIS tunnel handling. If the receiving tunnel endpoint is indeed NSIS-tunnel-aware, it recognizes this object and knows that the sending endpoint is NSIS-tunnel-aware. The receiving tunnel endpoint places the same object in a tunnel RESPONSE' message to inform the sending endpoint that it is also NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in the cases of sender-initiated reservation and receiver-initiated reservation are as follows.
需要了解另一个端点NSIS隧道处理能力的隧道端点将节点能力隧道对象包含在隧道查询“或保留”消息中。如果接收隧道端点确实是NSIS隧道感知的，则它会识别此对象并知道发送端点是NSIS隧道感知的。接收隧道端点将同一对象放置在隧道响应消息中，以通知发送端点它也是NSIS隧道感知的。在发送方发起的保留和接收方发起的保留的情况下，NODE_CAPABILITY_TUNNEL对象的使用如下所示。
First, assume that the end-to-end session is sender-initiated as in Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the NSIS tunnel capability of Texit. After receiving the first end-to-end RESERVE message (1), Tentry inserts an RII object and a NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2) and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-aware and includes the same object into the tunnel RESPONSE' message (4) sent back to Tentry.
首先，假设端到端会话由发送方发起，如图8所示，NSIS隧道感知终端希望发现Texit的NSIS隧道能力。在接收到第一个端到端保留消息（1）后，Tentry将RII对象和NODE_CAPABILITY_TUNNEL对象插入隧道保留消息（2）并将其发送给Texit。如果Texit是NSIS隧道感知的，则它从NODE_CAPABILITY_tunnel对象得知Tentry也是NSIS隧道感知的，并将相同的对象包含在发送回Tentry的隧道响应消息（4）中。
Second, assume that the end-to-end session is receiver-initiated as in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the NSIS tunnel capability of Texit. Upon receiving the first end-to-end QUERY message (1), Tentry inserts an RII object and a NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-aware and includes the same object tunnel RESPONSE' message (3) sent to Tentry.
其次，假设端到端会话如图9所示由接收器启动，NSIS隧道感知终端希望发现Texit的NSIS隧道能力。在接收到第一个端到端查询消息（1）后，Tentry在隧道查询消息（2）中插入一个RII对象和一个NODE_CAPABILITY_TUNNEL对象，并将其发送给Texit。如果Texit是NSIS隧道感知的，则它从NODE_CAPABILITY_tunnel对象得知Tentry也是NSIS隧道感知的，并包括发送给Tentry的相同对象隧道响应消息（3）。
This document defines a new object type called NODE_CAPABILITY_TUNNEL for QoS NSLP. Its Type value (0x015) has been assigned by IANA. The object format and the setting of the extensibility bits are defined in Section 7.
本文档为QoS NSLP定义了一种称为NODE_CAPABILITY_TUNNEL的新对象类型。其类型值（0x015）已由IANA分配。对象格式和可扩展性位的设置在第7节中定义。
This NSIS and IP tunnel interoperation mechanism has two IPsec-related security implications. First, NSIS messages may require per-hop processing within the IPsec tunnel, and that is potentially incompatible with IPsec. A similar problem exists for RSVP interacting with IPsec, when the Router Alert option is used (Appendix A.1 of RFC 4302 [RFC4302]). If this mechanism is indeed used for NSIS and IPsec tunnels, a so-called covert channel could exist where someone can create spurious NSIS signaling flows within the protected network in order to create signaling in the outside network, which then someone else is monitoring. For highly secure networks, this would be seen as a way to smuggle information out of the network, and therefore this channel will need to be rate-limited. A similar covert channel rate-limit problem exists for using Differentiated Services (DS) or Explicit Congestion Notification (ECN) fields with IPsec (Section 5.1.2 of RFC 4301 [RFC4301]).
此NSIS和IP隧道互操作机制具有两个与IPsec相关的安全含义。首先，NSIS消息可能需要在IPsec隧道内进行每跳处理，这可能与IPsec不兼容。当使用路由器警报选项（RFC 4302[RFC4302]的附录A.1）时，与IPsec交互的RSVP也存在类似的问题。如果此机制确实用于NSIS和IPsec隧道，则可能存在所谓的隐蔽通道，其中有人可以在受保护网络内创建虚假NSIS信令流，以便在外部网络中创建信令，然后由其他人进行监控。对于高度安全的网络，这将被视为将信息从网络中走私出去的一种方式，因此该通道需要限制速率。在IPsec中使用区分服务（DS）或显式拥塞通知（ECN）字段也存在类似的隐蔽信道速率限制问题（RFC 4301[RFC4301]第5.1.2节）。
Second, since the NSIS-tunnel-aware endpoint is responsible for adapting changes between the NSIS signaling both inside and outside the tunnel, there could be additional risks for an IPsec endpoint that is also an NSIS-tunnel-aware endpoint. For example, security vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec tunnel endpoint may be exposed to the unprotected outside network. Nevertheless, it should also be noted that if any node along the signaling path is compromised, the whole end-to-end QoS signaling could be affected, whether or not the end-to-end path includes an IPsec tunnel.
其次，由于NSIS隧道感知端点负责适应隧道内外NSIS信令之间的变化，因此作为NSIS隧道感知端点的IPsec端点可能存在额外的风险。例如，该IPsec隧道端点的NSIS堆栈上的安全漏洞（例如，缓冲区溢出）可能会暴露给未受保护的外部网络。然而，还应注意，如果沿信令路径的任何节点被破坏，则无论端到端路径是否包括IPsec隧道，整个端到端QoS信令都可能受到影响。
Several other documents discuss security issues for NSIS. General threats for NSIS can be found in [RFC4081]. Security considerations for NSIS NTLP and QoS NSLP are discussed in [RFC5971] and [RFC5974], respectively.
其他几个文件讨论了NSIS的安全问题。NSI的一般威胁可在[RFC4081]中找到。NSIS NTLP和QoS NSLP的安全注意事项分别在[RFC5971]和[RFC5974]中讨论。
The authors would like to thank Roland Bless, Francis Dupont, Lars Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig, and other members of the NSIS working group for comments. Thanks to Yaron Sheffer for pointing out the IPsec-related security considerations.
作者要感谢罗兰·布莱斯、弗朗西斯·杜邦、拉尔斯·艾格特、阿德里安·法雷尔、罗斯·霍斯利、乔治·卡拉吉安尼斯、朱卡·韦德、马丁·罗里奇特、彼得·圣安德烈、马丁·斯蒂梅林、汉内斯·茨霍芬尼以及NSIS工作组的其他成员的评论。感谢Yaron Sheffer指出与IPsec相关的安全注意事项。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697]Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年3月。
[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月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年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月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“IPv4网络上的通用路由封装”，RFC 1702，1994年10月。
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC1853]辛普森，W.，“IP隧道中的IP”，RFC1853，1995年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[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月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，Ed.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
Authors' Addresses
作者地址
Charles Shen Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
Phone: +1 212 854 3109
EMail: charles@cs.columbia.edu
Phone: +1 212 854 3109
EMail: charles@cs.columbia.edu
Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号亨宁·舒尔兹林内哥伦比亚大学计算机科学系，邮编：10027
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
Sung-Hyuck Lee Convergence Technologies & Standardization Lab Samsung Information System America, INC. 95 West Plumeria Drive San Jose, CA 95134 USA
Sung Hyuck Lee Convergence Technologies&Standardization Lab Samsung Information System America，INC.位于美国加利福尼亚州圣何塞市西普洛玛丽亚大道95号，邮编95134
Phone: 1-408-544-5809 EMail: sung1.lee@samsung.com
电话：1-408-544-5809电子邮件：sung1。lee@samsung.com
Jong Ho Bang SAMSUNG Advanced Institute of Technology San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 South Korea
韩国京畿道Giheung eup Yongin si农色里郑和邦三星高级技术学院San 14-1 449-712
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com