Network Working Group R. Hancock
Request for Comments: 4080 Siemens/RMR
Category: Informational G. Karagiannis
University of Twente/Ericsson
J. Loughney
Nokia
S. Van den Bosch
Alcatel
June 2005
Network Working Group R. Hancock
Request for Comments: 4080 Siemens/RMR
Category: Informational G. Karagiannis
University of Twente/Ericsson
J. Loughney
Nokia
S. Van den Bosch
Alcatel
June 2005
Next Steps in Signaling (NSIS): Framework
信令（NSIS）的下一步：框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
信令（NSIS）工作组的下一步是考虑在网络中沿其路径发送数据流信息的信令协议。NSIS协议套件旨在支持需要在网络中安装和/或操纵此类状态的各种信令应用程序。基于现有的信令需求工作，本文档提出了这些信令协议的体系结构框架。
This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application.
本文档为参与此类信令的网络实体以及信令与网络操作其余部分之间的关系提供了一个模型。我们将整个信令协议套件分解为一个通用（较低）层，每个特定的信令应用程序都有单独的上层。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Definition of the Signaling Problem ........................3
1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1. Fundamental Signaling Concepts .............................6
3.1.1. Simple Network and Signaling Topology ...............6
1. Introduction ....................................................3
1.1. Definition of the Signaling Problem ........................3
1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1. Fundamental Signaling Concepts .............................6
3.1.1. Simple Network and Signaling Topology ...............6
3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4. Signaling Messages and Network Control State .......10
3.1.5. Data Flows and Sessions ............................10
3.2. Layer Model for the Protocol Suite ........................11
3.2.1. Layer Model Overview ...............................11
3.2.2. Layer Split Concept ................................12
3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5. State Management Functionality .....................16
3.2.6. Path-Decoupled Operation ...........................17
3.3. Signaling Application Properties ..........................18
3.3.1. Sender/Receiver Orientation ........................18
3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3. Heterogeneous Operation ............................19
3.3.4. Aggregation ........................................20
3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6. Acknowledgements and Notifications .................21
3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol ..............................23
4.1. Internal Protocol Components ..............................23
4.2. Addressing ................................................24
4.3. Classical Transport Functions .............................24
4.4. Lower Layer Interfaces ....................................26
4.5. Upper Layer Services ......................................27
4.6. Identity Elements .........................................28
4.6.1. Flow Identification ................................28
4.6.2. Session Identification .............................28
4.6.3. Signaling Application Identification ...............29
4.7. Security Properties .......................................30
5. Interactions with Other Protocols ..............................30
5.1. IP Routing Interactions ...................................30
5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2. Route Changes ......................................31
5.2. Mobility and Multihoming Interactions .....................33
5.3. Interactions with NATs ....................................36
5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications .........................................37
6.1. Signaling for Quality of Service ..........................37
6.1.1. Protocol Message Semantics .........................38
6.1.2. State Management ...................................39
6.1.3. Route Changes and QoS Reservations .................39
6.1.4. Resource Management Interactions ...................41
6.2. Other Signaling Applications ..............................42
7. Security Considerations ........................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4. Signaling Messages and Network Control State .......10
3.1.5. Data Flows and Sessions ............................10
3.2. Layer Model for the Protocol Suite ........................11
3.2.1. Layer Model Overview ...............................11
3.2.2. Layer Split Concept ................................12
3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5. State Management Functionality .....................16
3.2.6. Path-Decoupled Operation ...........................17
3.3. Signaling Application Properties ..........................18
3.3.1. Sender/Receiver Orientation ........................18
3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3. Heterogeneous Operation ............................19
3.3.4. Aggregation ........................................20
3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6. Acknowledgements and Notifications .................21
3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol ..............................23
4.1. Internal Protocol Components ..............................23
4.2. Addressing ................................................24
4.3. Classical Transport Functions .............................24
4.4. Lower Layer Interfaces ....................................26
4.5. Upper Layer Services ......................................27
4.6. Identity Elements .........................................28
4.6.1. Flow Identification ................................28
4.6.2. Session Identification .............................28
4.6.3. Signaling Application Identification ...............29
4.7. Security Properties .......................................30
5. Interactions with Other Protocols ..............................30
5.1. IP Routing Interactions ...................................30
5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2. Route Changes ......................................31
5.2. Mobility and Multihoming Interactions .....................33
5.3. Interactions with NATs ....................................36
5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications .........................................37
6.1. Signaling for Quality of Service ..........................37
6.1.1. Protocol Message Semantics .........................38
6.1.2. State Management ...................................39
6.1.3. Route Changes and QoS Reservations .................39
6.1.4. Resource Management Interactions ...................41
6.2. Other Signaling Applications ..............................42
7. Security Considerations ........................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................44
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network.
信令（NSIS）工作组的下一步是考虑在网络中沿其路径发送数据流信息的信令协议。
It is assumed that the path taken by the data flow is already determined by network configuration and routing protocols, independently of the signaling itself; that is, signaling to set up the routes themselves is not considered. Instead, the signaling simply interacts with nodes along the data flow path. Additional simplifications are that the actual signaling messages pass directly through these nodes themselves (i.e., the 'path-coupled' case; see Section 3.1.2) and that only unicast data flows are considered.
假设数据流采用的路径已经由网络配置和路由协议确定，独立于信令本身；也就是说，不考虑设置路由本身的信令。相反，信令只是沿着数据流路径与节点交互。额外的简化是，实际信令消息直接通过这些节点本身（即“路径耦合”情况；参见第3.1.2节），并且只考虑单播数据流。
The signaling problem in this sense is very similar to that addressed by RSVP. However, there are two generalizations. First, the intention is that components of the NSIS protocol suite will be usable in different parts of the Internet, for different needs, without requiring a complete end-to-end deployment (in particular, the signaling protocol messages may not need to run all the way between the data flow endpoints).
从这个意义上讲，信令问题与RSVP解决的问题非常相似。然而，有两种概括。首先，意图是NSIS协议套件的组件将可用于互联网的不同部分，以满足不同的需求，而不需要完整的端到端部署（特别是，信令协议消息可能不需要在数据流端点之间一直运行）。
Second, the signaling is intended for more purposes than just QoS (resource reservation). The basic mechanism to achieve this flexibility is to divide the signaling protocol stack into two layers: a generic (lower) layer, and an upper layer specific to each signaling application. The scope of NSIS work is to define both the generic protocol and, initially, upper layers suitable for QoS signaling (similar to the corresponding functionality in RSVP) and middlebox signaling. Further applications may be considered later.
第二，信令的目的不仅仅是QoS（资源预留）。实现这种灵活性的基本机制是将信令协议栈分为两层：通用（较低）层和特定于每个信令应用程序的上层。NSIS的工作范围是定义通用协议，以及最初适用于QoS信令（类似于RSVP中的相应功能）和中间箱信令的上层。以后可能会考虑进一步的申请。
The underlying requirements for signaling in the context of NSIS are defined in [1] and a separate security threats document [2]; other related requirements can be found in [3] and [4] for QoS/Mobility and middlebox communication, respectively. This framework does not replace or update these requirements. Discussions about lessons to be learned from existing signaling and resource management protocols are contained in separate analysis documents [5], [6].
NSI背景下的信令基本要求在[1]和单独的安全威胁文件[2]中定义；在[3]和[4]中分别可以找到关于QoS/移动性和中间盒通信的其他相关要求。该框架不会取代或更新这些需求。关于从现有信令和资源管理协议中吸取的经验教训的讨论包含在单独的分析文档[5]、[6]中。
The role of this framework is to explain how NSIS signaling should work within the broader networking context, and to describe the overall structure of the protocol suite itself. Therefore, it
该框架的作用是解释NSIS信令应如何在更广泛的网络环境中工作，并描述协议套件本身的总体结构。因此,
discusses important protocol considerations such as routing, mobility, security, and interactions with network 'resource' management (in the broadest sense).
讨论重要的协议注意事项，如路由、移动性、安全性以及与网络“资源”管理（最广义）的交互。
The basic context for NSIS protocols is given in Section 3. Section 3.1 describes the fundamental elements of NSIS protocol operation in comparison to RSVP [7]; in particular, Section 3.1.3 describes more general signaling scenarios, and Section 3.1.4 defines a broader class of signaling applications for which the NSIS protocols should be useful. The two-layer protocol architecture that supports this generality is described in Section 3.2, and Section 3.3 gives examples of the ways in which particular signaling application properties can be accommodated within signaling layer protocol behavior.
第3节给出了NSIS协议的基本上下文。第3.1节描述了与RSVP[7]相比的NSIS协议操作的基本要素；特别是，第3.1.3节描述了更一般的信令场景，第3.1.4节定义了NSIS协议应适用的更广泛的信令应用类别。第3.2节描述了支持这种通用性的两层协议体系结构，第3.3节给出了在信令层协议行为中容纳特定信令应用程序属性的方法示例。
The overall functionality required from the lower (generic) protocol layer is described in Section 4. This is not intended to define the detailed design of the protocol or even design options, although some are described as examples. It describes the interfaces between this lower-layer protocol and the IP layer (below) and signaling application protocols (above), including the identifier elements that appear on these interfaces (Section 4.6). Following this, Section 5 describes how signaling applications that use the NSIS protocols can interact sensibly with network layer operations; specifically, routing (and re-routing), IP mobility, and network address translation (NAT).
第4节描述了较低（通用）协议层所需的总体功能。这并不是为了定义协议的详细设计，甚至不是为了定义设计选项，尽管其中一些被描述为示例。它描述了该下层协议与IP层（下文）和信令应用协议（上文）之间的接口，包括出现在这些接口上的标识符元素（第4.6节）。接下来，第5节描述了使用NSIS协议的信令应用程序如何与网络层操作进行合理交互；具体来说，路由（和重路由）、IP移动性和网络地址转换（NAT）。
Section 6 describes particular signaling applications. The example of signaling for QoS (comparable to core RSVP QoS signaling functionality) is given in detail in Section 6.1, which describes both the signaling application specific protocol and example modes of interaction with network resource management and other deployment aspects. However, note that these examples are included only as background and for explanation; we do not intend to define an over-arching architecture for carrying out resource management in the Internet. Further possible signaling applications are outlined in Section 6.2.
第6节描述了特定的信令应用。第6.1节详细给出了QoS信令示例（与核心RSVP QoS信令功能相当），其中描述了信令应用特定协议以及与网络资源管理和其他部署方面交互的示例模式。但是，请注意，这些示例仅作为背景和解释而包含；我们不打算为在Internet上执行资源管理定义一个总体架构。第6.2节概述了其他可能的信号应用。
Classifier: an entity that selects packets based on their contents according to defined rules.
分类器：根据定义的规则根据数据包内容选择数据包的实体。
[Data] flow: a stream of packets from sender to receiver that is a distinguishable subset of a packet stream. Each flow is distinguished by some flow identifier (see Section 4.6.1).
[数据]流：从发送方到接收方的数据包流，是数据包流的可区分子集。每个流通过一些流标识符进行区分（见第4.6.1节）。
Edge node: an (NSIS-capable) node on the boundary of some administrative domain.
边缘节点：某个管理域边界上的（支持NSIS的）节点。
Interior nodes: the set of (NSIS-capable) nodes that form an administrative domain, excluding the edge nodes.
内部节点：构成管理域的一组（支持NSIS的）节点，不包括边缘节点。
NSIS Entity (NE): the function within a node that implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path.
NSIS实体（NE）：节点内实现NSIS协议的功能。在路径耦合信令的情况下，网元将始终位于数据路径上。
NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS protocol component that supports a specific signaling application. See also Section 3.2.1.
NSIS信令层协议（NSLP）：支持特定信令应用的NSIS协议组件的通用术语。另见第3.2.1节。
NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS protocol component that will support lower-layer (signaling application-independent) functions. See also Section 3.2.1.
NSIS传输层协议（NTLP）：NSIS协议组件的占位符名称，该组件将支持较低层（独立于信令应用程序）功能。另见第3.2.1节。
Path-coupled signaling: a mode of signaling in which the signaling messages follow a path that is tied to the data messages.
路径耦合信令：一种信令模式，其中信令消息遵循与数据消息绑定的路径。
Path-decoupled signaling: signaling for state manipulation related to data flows, but only loosely coupled to the data path; e.g., at the AS level.
路径解耦信令：用于与数据流相关的状态操作的信令，但仅松散耦合到数据路径；e、 例如，在AS级别。
Peer discovery: the act of locating and/or selecting which NSIS peer to carry out signaling exchanges with for a specific data flow.
对等发现：为特定数据流定位和/或选择与哪个NSIS对等进行信令交换的行为。
Peer relationship: signaling relationship between two adjacent NSIS entities (i.e., NEs with no other NEs between them).
对等关系：两个相邻NSIS实体（即，它们之间没有其他网元的网元）之间的信令关系。
Receiver: the node in the network that is receiving the data packets in a flow.
接收方：网络中接收流中数据包的节点。
Sender: the node in the network that is sending the data packets in a flow.
发送方：网络中以流形式发送数据包的节点。
Session: application layer flow of information for which some network control state information is to be manipulated or monitored (see Section 3.1.5).
会话：应用层信息流，其中一些网络控制状态信息将被操纵或监控（见第3.1.5节）。
Signaling application: the purpose of the NSIS signaling. A signaling application could be QoS management, firewall control, and so on. Totally distinct from any specific user application.
信令应用：NSIS信令的目的。信令应用程序可以是QoS管理、防火墙控制等。完全不同于任何特定的用户应用程序。
The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate state in the network. This state is related to a data flow and is installed and maintained on the NSIS Entities (NEs) along the data flow path through the network; not every node has to contain an NE. The basic protocol concepts do not depend on the signaling application, but the details of operation and the information carried do. This section discusses the basic entities involved with signaling as well as interfaces between them.
NSIS协议套件旨在支持需要在网络中安装和/或操作状态的各种信令应用程序。该状态与数据流相关，并沿通过网络的数据流路径在NSIS实体（NE）上安装和维护；并非每个节点都必须包含一个网元。基本协议概念不依赖于信令应用，但操作细节和所携带的信息依赖于信令应用。本节讨论与信令相关的基本实体以及它们之间的接口。
Two NSIS entities that communicate directly are said to be in a 'peer relationship'. This concept might loosely be described as an 'NSIS hop'; however, there is no implication that it corresponds to a single IP hop. Either or both NEs might store some state information about the other, but there is no assumption that they necessarily establish a long-term signaling connection between themselves.
两个直接通信的NSIS实体被称为处于“对等关系”。这个概念可以粗略地描述为“NSIS跃点”；但是，这并不意味着它对应于单个IP跃点。一个或两个网元可能存储关于另一个网元的一些状态信息，但没有假设它们必须在它们之间建立长期信令连接。
It is common to consider a network as composed of various domains (e.g., for administrative or routing purposes), and the operation of signaling protocols may be influenced by these domain boundaries. However, it seems there is no reason to expect that an 'NSIS domain' should exactly overlap with an IP domain (AS, area), but it is likely that its boundaries would consist of boundaries (segments) of one or several IP domains.
通常认为网络由各种域组成（例如，用于管理或路由目的），并且信令协议的操作可能受这些域边界的影响。然而，似乎没有理由期望“NSIS域”与IP域（AS、area）完全重叠，但其边界可能由一个或多个IP域的边界（段）组成。
Figure 1 shows a diagram of nearly the simplest possible signaling configuration. A single data flow is running from an application in the sender to the receiver via routers R1, R2, and R3. Each host and two of the routers contain NEs that exchange signaling messages -- possibly in both directions -- about the flow. This scenario is essentially the same as that considered by RSVP for QoS signaling; the main difference is that here we make no assumptions about the particular sequence of signaling messages that will be invoked.
图1显示了几乎最简单的信令配置图。单个数据流通过路由器R1、R2和R3从发送方的应用程序运行到接收方。每个主机和两个路由器都包含交换有关流的信令消息（可能是双向的）的网元。该场景基本上与RSVP考虑的QoS信令相同；主要区别在于，这里我们不对将被调用的特定信令消息序列进行假设。
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows
图1：简单的信令和数据流
We can consider two basic paradigms for resource reservation signaling, which we refer to as "path-coupled" and "path-decoupled".
我们可以考虑两种基本的资源保留信令范例，我们称之为“路径耦合”和“路径解耦”。
In the path-coupled case, signaling messages are routed only through NEs that are on the data path. They do not have to reach all the nodes on the data path. (For example, there could be intermediate signaling-unaware nodes, or the presence of proxies such as those shown in Figure 2 could prevent the signaling from reaching the path end points.) Between adjacent NEs, the route taken by signaling and data might diverge. The path-coupled case can be supported by various addressing styles, with messages either explicitly addressed to the neighbor on-path NE, or addressed identically to the data packets, but also with the router alert option (see [8] and [9]), and intercepted. These cases are considered in Section 4.2. In the second case, some network configurations may split the signaling and data paths (see Section 5.1.1); this is considered an error case for path-coupled signaling.
在路径耦合的情况下，信令消息仅通过数据路径上的网元路由。它们不必到达数据路径上的所有节点。（例如，可能存在中间信令不知道节点，或者存在如图2所示的代理可能会阻止信令到达路径端点。）在相邻网元之间，信令和数据所采用的路由可能会发散。路径耦合情况可以由各种寻址方式支持，消息可以显式地寻址到路径NE上的邻居，或者以与数据包相同的方式寻址，但也可以使用路由器警报选项（参见[8]和[9]），并被拦截。第4.2节考虑了这些情况。在第二种情况下，一些网络配置可能会分割信令和数据路径（见第5.1.1节）；这被认为是路径耦合信令的错误情况。
In the path-decoupled case, signaling messages are routed to nodes (NEs) that are not assumed to be on the data path, but that are (presumably) aware of it. Signaling messages will always be directly addressed to the neighbor NE, and the signaling endpoints may have no relation at all with the ultimate data sender or receiver. The implications of path-decoupled operation for the NSIS protocols are considered briefly in Section 3.2.6; however, the initial goal of NSIS and this framework is to concentrate mainly on the path-coupled case.
在路径解耦的情况下，信令消息被路由到假定不在数据路径上但（可能）知道它的节点（ne）。信令消息将始终直接寻址到邻居网元，并且信令端点可能与最终数据发送方或接收方完全没有关系。第3.2.6节简要考虑了NSIS协议的路径解耦操作的影响；然而，NSIS和该框架的最初目标是主要关注路径耦合情况。
There are different possible triggers for the signaling protocols. Among them are user applications (that are using NSIS signaling services), other signaling applications, network management actions, some network events, and so on. The variety of possible triggers requires that the signaling can be initiated and terminated in the different parts of the network: hosts, domain boundary nodes (edge nodes), or interior domain nodes.
信令协议有不同的可能触发器。其中包括用户应用程序（使用NSIS信令服务）、其他信令应用程序、网络管理操作、一些网络事件等。各种可能的触发器要求信令可以在网络的不同部分启动和终止：主机、域边界节点（边缘节点）或内部域节点。
The NSIS protocol suite extends the RSVP model to consider this wider variety of possible signaling exchanges. As well as the basic end-to-end model already described, examples such as end-to-edge and edge-to-edge can be considered. The edge-to-edge case might involve the edge nodes communicating directly, as well as via the interior nodes.
NSIS协议套件扩展了RSVP模型，以考虑这种更广泛的各种可能的信令交换。除了已经描述的基本端到端模型外，还可以考虑端到边和边到边等示例。边到边的情况可能涉及直接通信的边节点以及通过内部节点进行通信的边节点。
Although the end-to-edge (host-to-network) scenario requires only intra-domain signaling, the other cases might need inter-domain NSIS signaling as well if the signaling endpoints (hosts or network edges) are connected to different domains. Depending on the trust relation between concatenated NSIS domains, the edge-to-edge scenario might cover a single domain or multiple concatenated NSIS domains. The latter case assumes the existence of trust relations between domains.
尽管端到端（主机到网络）场景仅需要域内信令，但如果信令端点（主机或网络边缘）连接到不同的域，则其他情况也可能需要域间NSIS信令。根据连接的NSIS域之间的信任关系，边缘到边缘方案可能涵盖单个域或多个连接的NSIS域。后一种情况假设域之间存在信任关系。
In some cases, it is desired to be able to initiate and/or terminate NSIS signaling not from the end host that sends/receives the data flow, but from some other entities in the network that can be called signaling proxies. There could be various reasons for this: signaling on behalf of the end hosts that are not NSIS-aware, consolidation of the customer accounting (authentication, authorization) in respect to consumed application and transport resources, security considerations, limitation of the physical connection between host and network, and so on. This configuration can be considered a kind of "proxy on the data path"; see Figure 2.
在某些情况下，希望能够不是从发送/接收数据流的终端主机而是从网络中可以称为信令代理的一些其他实体发起和/或终止NSIS信令。这可能有多种原因：代表不了解NSIS的终端主机发送信令、整合客户记帐（身份验证、授权）以了解所消耗的应用程序和传输资源、安全考虑、主机和网络之间的物理连接限制，等等。这种配置可以被视为一种“数据路径上的代理”；参见图2。
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Appl = signaling application
Appl = signaling application
Figure 2: "On path" NSIS proxy
图2：“路径上”NSIS代理
This configuration presents two specific challenges for the signaling:
此配置对信令提出了两个特定的挑战：
o A proxy that terminates signaling on behalf of the NSIS-unaware host (or part of the network) should be able to determine that it is the last NSIS-aware node along the path.
o 代表NSIS非感知主机（或网络的一部分）终止信令的代理应该能够确定它是路径上最后一个NSIS感知节点。
o Where a proxy initiates NSIS signaling on behalf of the NSIS-unaware host, interworking with some other "local" technology might be required (for example, to provide QoS reservation from proxy to the end host in the case of a QoS signaling application).
o 在代理代表NSIS不知道的主机发起NSIS信令的情况下，可能需要与一些其他“本地”技术互通（例如，在QoS信令应用的情况下，提供从代理到终端主机的QoS预留）。
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
Appl = signaling PA = Proxy for signaling application application
Appl=信令PA=信令应用程序代理
Figure 3: "Off path" NSIS proxy
图3：“非路径”NSIS代理
Another possible configuration, shown in Figure 3, is where an NE can send and receive signaling information to a remote processor. The NSIS protocols may or may not be suitable for this remote interaction, but in any case it is not currently part of the NSIS problem. This configuration is supported by considering the NE a proxy at the signaling application level. This is a natural implementation approach for some policy control and centralized control architectures; see also Section 6.1.4.
图3所示的另一种可能的配置是，网元可以向远程处理器发送和接收信令信息。NSIS协议可能适合也可能不适合这种远程交互，但在任何情况下，它目前都不是NSIS问题的一部分。通过将网元视为信令应用级别的代理来支持此配置。这是一些策略控制和集中控制体系结构的自然实现方法；另见第6.1.4节。
The distinguishing features of the signaling supported by the NSIS protocols are that it is related to specific flows (rather than to network operation in general), and that it involves nodes in the network (rather than running transparently between the end hosts).
NSIS协议支持的信令的显著特征是，它与特定流（而不是一般的网络操作）相关，并且它涉及网络中的节点（而不是在终端主机之间透明地运行）。
Therefore, each signaling application (upper-layer) protocol must carry per-flow information for the aspects of network-internal operation that are of interest to that signaling application. An example for the case of an RSVP-like QoS signaling application would be state data representing resource reservations. However, more generally, the per-flow information might be related to some other control function in routers and middleboxes along the path. Indeed, the signaling might simply be used to gather per-flow information, without modifying network operation at all.
因此，每个信令应用程序（上层）协议必须携带该信令应用程序感兴趣的网络内部操作方面的每流信息。类似于RSVP的QoS信令应用程序的示例是表示资源预留的状态数据。然而，更一般地说，每流信息可能与路径上路由器和中间盒中的某些其他控制功能有关。实际上，信令可能只是用于收集每个流的信息，而根本不修改网络操作。
We call this information 'network control state' generically. Signaling messages may install, modify, refresh, or simply read this state from network elements for particular data flows. Usually a network element will also manage this information at the per-flow level, although coarser-grained ('per-class') state management is also possible.
我们一般称此信息为“网络控制状态”。信令消息可以为特定数据流安装、修改、刷新或简单地从网络元素读取该状态。通常，网元也将在每流级别管理此信息，尽管粗粒度（“每类”）状态管理也是可能的。
Formally, a data flow is a (unidirectional) sequence of packets between the same endpoints that all follow a unique path through the network (determined by IP routing and other network configuration). A flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). In general we assume that when discussing only the data flow path, we only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent).
在形式上，数据流是相同端点之间的（单向）数据包序列，所有端点都遵循通过网络的唯一路径（由IP路由和其他网络配置确定）。流由包分类器定义（在最简单的情况下，只需要目标地址和拓扑原点）。一般来说，我们假设只讨论数据流路径时，我们只需要考虑“简单”固定分类器（例如，IPv4 5元组或等效）。
A session is an application layer concept for an exchange of packets between two endpoints, for which some network state is to be allocated or monitored. In simple cases, a session may map to a specific flow; however, signaling applications are allowed to create
会话是两个端点之间数据包交换的应用层概念，需要为其分配或监视某些网络状态。在简单的情况下，会话可以映射到特定的流；但是，允许信令应用程序创建
more flexible flow:session relationships. (Note that this concept of 'session' is different from that of RSVP, which defines a session as a flow with a specific destination address and transport protocol. The NSIS usage is closer to the session concepts of higher-layer protocols.)
更灵活的流程：会话关系。（请注意，“会话”的概念不同于RSVP，RSVP将会话定义为具有特定目标地址和传输协议的流。NSIS的使用更接近于高层协议的会话概念。）
The simplest service provided by NSIS signaling protocols is the management of network control state at the level of a specific flow, as described in the previous subsection. In particular, it should be possible to monitor routing updates as they change the path taken by a flow and, for example, update network state appropriately. This is no different from the case for RSVP (local path repair). Where there is a 1:1 flow:session relationship, this is all that is required.
NSIS信令协议提供的最简单的服务是在特定流级别管理网络控制状态，如前一小节所述。特别是，当路由更新更改流所采用的路径时，应该可以监视路由更新，例如，适当地更新网络状态。这与RSVP（本地路径修复）的情况没有什么不同。如果存在1:1流：会话关系，则只需要这些。
However, for some more complex scenarios (especially mobility and multihoming related ones; see [1] and the mobility discussion of [5]), it is desirable to update the flow:session mapping during the session lifetime. For example, a new flow can be added, and the old one deleted (and maybe in that order, for a 'make-before-break' handover), effectively transferring the network control state between data flows to keep it associated with the same session. Such updates are best managed by the end systems (generally, systems that understand the flow:session mapping and are aware of the packet classifier change). To enable this, it must be possible to relate signaling messages to sessions as well as to data flows. A session identifier (Section 4.6.2) is one component of the solution.
然而，对于一些更复杂的场景（特别是与移动性和多归属相关的场景；请参见[1]和[5]的移动性讨论），需要在会话生存期内更新flow:session映射。例如，可以添加一个新的流，删除旧的流（对于“先通后断”的切换，可能按照该顺序），有效地在数据流之间传输网络控制状态，以使其与同一会话保持关联。这样的更新最好由终端系统管理（通常，理解流的系统：会话映射，并且知道包分类器的更改）。为了实现这一点，必须能够将信令消息与会话以及数据流相关联。会话标识符（第4.6.2节）是解决方案的一个组成部分。
In order to achieve a modular solution for the NSIS requirements, the NSIS protocol suite will be structured in two layers:
为了实现NSIS需求的模块化解决方案，NSIS协议套件将分为两层：
o a 'signaling transport' layer, responsible for moving signaling messages around, which should be independent of any particular signaling application; and
o “信令传输”层，负责移动信令消息，该层应独立于任何特定信令应用；和
o a 'signaling application' layer, which contains functionality such as message formats and sequences, specific to a particular signaling application.
o “信令应用”层，包含特定于特定信令应用的消息格式和序列等功能。
For the purpose of this document, we use the term 'NSIS Transport Layer Protocol' (NTLP) to refer to the component that will be used in the transport layer. We also use the term 'NSIS Signaling Layer Protocol' (NSLP) to refer generically to any protocol within the signaling application layer; in the end, there will be several NSLPs, largely independent of each other. These relationships are
在本文档中，我们使用术语“NSIS传输层协议”（NTLP）来指代将在传输层中使用的组件。我们还使用术语“NSIS信令层协议”（NSLP）泛指信令应用层内的任何协议；最终，将有几个基本上相互独立的NSLP。这些关系是
illustrated in Figure 4. Note that the NTLP may or may not have an interesting internal structure (e.g., including existing transport protocols), but that is not relevant at this level of description.
如图4所示。注意，NTLP可能具有也可能不具有有趣的内部结构（例如，包括现有的传输协议），但这与此描述级别无关。
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| +-----------------+ | for ... |
V +-----------------+
=============================================
NSIS ^ +--------------------------------+
Transport | | NSIS Transport Layer Protocol |
Layer V +--------------------------------+
=============================================
+--------------------------------+
. IP and lower layers .
. .
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| +-----------------+ | for ... |
V +-----------------+
=============================================
NSIS ^ +--------------------------------+
Transport | | NSIS Transport Layer Protocol |
Layer V +--------------------------------+
=============================================
+--------------------------------+
. IP and lower layers .
. .
Figure 4: NSIS Protocol Components
图4:NSIS协议组件
Note that not every generic function has to be located in the NTLP. Another option would be to have re-usable components within the signaling application layer. Functionality within the NTLP should be restricted to what interacts strongly with other transport and lower-layer operations.
请注意，并非所有通用函数都必须位于NTLP中。另一个选择是在信令应用层中具有可重用的组件。NTLP内的功能应限于与其他传输和较低层操作的强烈交互。
This section describes the basic concepts underlying the functionality of the NTLP. First, we make a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger-scope issues (including e2e aspects) are left to the upper layers.
本节介绍NTLP功能的基本概念。首先，我们假设NTLP的协议机制仅在相邻网元之间运行（非正式地说，NTLP是“逐跳”协议），而任何更大范围的问题（包括e2e方面）都留给上层。
The way in which the NTLP works can be described as follows: When a signaling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (upstream or downstream), where it is received and the responsibility of the NTLP ends. Note that there is no assumption here about how the messages are actually addressed (this is a protocol design issue, and the
NTLP的工作方式可以描述如下：当信令消息准备好从一个NE发送时，将其连同关于其用于什么流的信息一起提供给NTLP；然后由NTLP将其传送到路径（上游或下游）上的下一个网元，在那里接收并结束NTLP的责任。请注意，这里没有关于消息实际如何寻址的假设（这是一个协议设计问题，而
options are outlined in Section 4.2). The key point is that the NTLP for a given NE does not use any knowledge about addresses, capabilities, or status of any NEs other than its direct peers.
选项见第4.2节）。关键的一点是，给定网元的NTLP不使用任何关于其直接对等方以外的任何网元的地址、能力或状态的知识。
The NTLP in the receiving NE either forwards the message directly or, if there is an appropriate signaling application locally, passes it upwards for further processing; the signaling application can then generate another message to be sent via the NTLP. In this way, larger-scope (including end-to-end) message delivery is achieved.
接收网元中的NTLP或者直接转发消息，或者如果本地存在适当的信令应用，则向上传递消息以进行进一步处理；然后，信令应用程序可以生成另一条要通过NTLP发送的消息。通过这种方式，可以实现更大范围（包括端到端）的消息传递。
This definition relates to NTLP operation. It does not restrict the ability of an NSLP to send messages by other means. For example, an NE in the middle or end of the signaling path could send a message directly to the other end as a notification or acknowledgement of some signaling application event. However, the issues in sending such messages (endpoint discovery, security, NAT traversal, and so on) are so different from the direct peer-peer case that there is no benefit in extending the NTLP to include such non-local functionality. Instead, an NSLP that requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol. For example, UDP or DCCP would be a good match for many of the scenarios that have been proposed. Acknowledgements and notifications of this type are considered further in Section 3.3.6.
此定义与NTLP操作有关。它不限制NSLP通过其他方式发送消息的能力。例如，在信令路径的中间或端部的NE可以将消息直接发送到另一端作为通知或确认某些信令应用事件。然而，发送此类消息（端点发现、安全性、NAT遍历等）时的问题与直接对等情况非常不同，因此扩展NTLP以包括此类非本地功能没有任何好处。相反，需要此类消息并希望避免穿越网元路径的NSLP应该使用其他一些现有传输协议。例如，UDP或DCCP将非常适合已提出的许多方案。第3.3.6节将进一步考虑此类确认和通知。
One motivation for restricting the NTLP to peer-relationship scope is that if there are any options or variants in design approach -- or, worse, in basic functionality -- it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole Internet.
限制NTLP到对等关系范围的一个动机是，如果设计方法中存在任何选项或变体，或者更糟糕的是，在基本功能中存在任何选项或变体，那么如果其只影响直接对等方而不是潜在的整个互联网，则更容易管理由此产生的复杂性。
Because the NSIS problem includes multiple signaling applications, it is very likely that a particular NSLP will only be implemented on a subset of the NSIS-aware nodes on a path, as shown in Figure 5. In addition, a node inside an aggregation region will still wish to ignore signaling messages that are per-flow, even if they are for a signaling application that the node is generally able to process.
由于NSIS问题包括多个信令应用程序，因此很可能只在路径上NSIS感知节点的子集上实现特定NSLP，如图5所示。此外，聚合区域内的节点仍然希望忽略每个流的信令消息，即使这些消息用于该节点通常能够处理的信令应用程序。
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPs
图5：具有异构NSLP的信号
Where signaling messages traverse such NSIS-aware intermediate nodes, it is desirable to process them at the lowest level possible (in particular, on the fastest path). In order to offer a non-trivial message transfer service (in terms of security, reliability and so on) to the peer NSLP nodes, it is important that the NTLP at intermediate nodes is as transparent as possible; that is, it carries out minimal processing. In addition, if intermediate nodes have to do slow-path processing of all NSIS messages, this eliminates many of the scaling benefits of aggregation, unless tunneling is used.
当信令消息穿过此类NSIS感知的中间节点时，希望在尽可能低的级别（特别是在最快的路径上）处理它们。为了向对等NSLP节点提供非平凡的消息传输服务（在安全性、可靠性等方面），中间节点上的NTLP尽可能透明是很重要的；也就是说，它执行最小的处理。此外，如果中间节点必须对所有NSIS消息进行缓慢的路径处理，这将消除聚合的许多扩展优势，除非使用隧道。
Considering first the case of messages sent with the router alert option, there are two complementary methods to achieve this bypassing of intermediate NEs:
首先考虑使用路由器警报选项发送消息的情况，有两种互补的方法来实现中间网元的旁路：
o At the IP layer, a set of protocol numbers or a range of values in the router alert option can be used. In this way, messages can be marked with an implied granularity, and routers can choose to apply further slow-path processing only to configured subsets of messages. This is the method used in [10] to distinguish per-flow and per-aggregate signaling.
o 在IP层，可以使用路由器警报选项中的一组协议编号或一系列值。通过这种方式，可以用隐含的粒度标记消息，路由器可以选择只对已配置的消息子集应用进一步的慢路径处理。这是[10]中用于区分每流和每聚合信令的方法。
o The NTLP could process the message but determine that there was no local signaling application it was relevant to. At this stage, the message can be returned unchanged to the IP layer for normal forwarding; the intermediate NE has effectively chosen to be transparent to the message in question.
o NTLP可以处理该消息，但确定没有与其相关的本地信令应用程序。在此阶段，消息可以原封不动地返回到IP层进行正常转发；中间NE已有效地选择对所讨论的消息透明。
In both cases, the existence of the intermediate NE is totally hidden from the NSLP nodes. If later stages of the signaling use directly addressed messages (e.g., for reverse routing), they will not involve the intermediate NE at all, except perhaps as a normal router.
在这两种情况下，中间NE的存在对NSLP节点完全隐藏。如果信令的稍后阶段使用直接寻址的消息（例如，用于反向路由），则它们将根本不涉及中间NE，除非可能作为正常路由器。
There may be cases where the intermediate NE would like to do some restricted protocol processing, such as the following:
可能存在中间网元希望执行一些受限协议处理的情况，例如：
o Translating addresses in message payloads (compare Section 4.6.1); note that this would have to be done to messages passing in both directions through a node.
o 翻译消息有效载荷中的地址（比较第4.6.1节）；请注意，必须对通过节点在两个方向上传递的消息执行此操作。
o Updating signaling application payloads with local status information (e.g., path property measurement inside a domain).
o 使用本地状态信息（例如，域内的路径属性测量）更新信令应用程序有效负载。
If this can be done without fully terminating the NSIS protocols, it would allow a more lightweight implementation of the intermediate NE, and a more direct 'end-to-end' NTLP association between the peer NSLPs where the signaling application is fully processed. On the other hand, this is only possible with a limited class of possible NTLP designs, and makes it harder for the NTLP to offer a security service (since messages have to be partially protected). The feasibility of this approach will be evaluated during the NTLP design.
如果这可以在不完全终止NSIS协议的情况下完成，那么它将允许中间NE的更轻量级实现，以及在完全处理信令应用的对等nslp之间的更直接的“端到端”NTLP关联。另一方面，这仅在有限种类的可能NTLP设计中才可能实现，这使得NTLP更难提供安全服务（因为必须对消息进行部分保护）。该方法的可行性将在NTLP设计期间进行评估。
This section describes the basic functionality to be supported by the NTLP. Note that the overall signaling solution will always be the result of joint operation of both the NTLP and the signaling layer protocols (NSLPs); for example, we can always assume that an NSLP is operating above the NTLP and taking care of end-to-end issues (e.g., recovery of messages after restarts).
本节介绍NTLP支持的基本功能。注意，整个信令解决方案将始终是NTLP和信令层协议（NSLP）联合运行的结果；例如，我们可以始终假设NSLP在NTLP之上运行，并负责端到端问题（例如，重新启动后恢复消息）。
Therefore, NTLP functionality is essentially just efficient upstream and downstream peer-peer message delivery, in a wide variety of network scenarios. Message delivery includes the act of locating and/or selecting which NTLP peer to carry out signaling exchanges with for a specific data flow. This discovery might be an active process (using specific signaling packets) or a passive process (a side effect of using a particular addressing mode). In addition, it appears that the NTLP can sensibly carry out many of the functions that enable signaling messages to pass through middleboxes, since this is closely related to the problem of routing the signaling messages in the first place. Further details about NTLP functionality are contained in Sections 3.2.5 and 4.3.
因此，在各种网络场景中，NTLP功能本质上只是高效的上游和下游对等消息传递。消息传递包括定位和/或选择要与哪个NTLP对等方进行特定数据流的信令交换的行为。此发现可能是一个主动过程（使用特定的信令包）或被动过程（使用特定寻址模式的副作用）。此外，NTLP似乎可以明智地执行使信令消息能够通过中间盒的许多功能，因为这首先与信令消息的路由问题密切相关。有关NTLP功能的更多详细信息，请参见第3.2.5节和第4.3节。
Internet signaling requires the existence and management of state within the network for several reasons. This section describes how state management functionality is split across the NSIS layers. (Note that how the NTLP internal state is managed is a matter for its design and indeed implementation.)
互联网信令需要存在和管理网络内的状态，原因有几个。本节介绍如何在NSIS层之间拆分状态管理功能。（请注意，如何管理NTLP内部状态是其设计和实现的问题。）
1. Conceptually, the NTLP provides a uniform message delivery service. It is unaware of the difference in state semantics between different types of signaling application messages (e.g., whether a message changes, just refreshes signaling application state, or even has nothing to with signaling application state at all).
1. 从概念上讲，NTLP提供统一的消息传递服务。它不知道不同类型的信令应用程序消息之间的状态语义差异（例如，消息是否更改、只是刷新信令应用程序状态，或者甚至与信令应用程序状态完全无关）。
2. An NTLP instance processes and, if necessary, forwards all signaling application messages "immediately". (It might offer different service classes, but these would be distinguished by, for example, reliability or priority, not by state aspects.) This means that the NTLP does not know explicit timer or message sequence information for the signaling application; and that signaling application messages pass immediately through an NSLP-unaware node. (Their timing cannot be jittered there, nor can messages be stored up to be re-sent on a new path in case of a later re-routing event.)
2. NTLP实例处理并在必要时“立即”转发所有信令应用程序消息。（它可以提供不同的服务类别，但这些服务类别将通过例如可靠性或优先级而不是状态方面来区分。）这意味着NTLP不知道信令应用的显式计时器或消息序列信息；信令应用程序消息会立即通过NSLP节点。（它们的时间不能在那里抖动，也不能存储消息，以便在以后发生重新路由事件时在新路径上重新发送。）
3. Within any node, it is an implementation decision whether to generate/jitter/filter refreshes separately within each signaling application that needs this functionality, or to integrate it with the NTLP implementation as a generic "soft-state management toolbox". The choice doesn't affect the NTLP specification at all. Implementations might piggyback NTLP soft-state refresh information (if the NTLP works this way) on signaling application messages, or they might even combine soft-state management between layers. The state machines of the NTLP and NSLPs remain logically independent, but an implementation is free to allow them to interact to reduce the load on the network to the same level that would be achieved by a monolithic model.
3. 在任何节点内，实现决策是在需要此功能的每个信令应用程序内单独生成/抖动/过滤刷新，还是将其与NTLP实现集成为通用的“软状态管理工具箱”。这个选择根本不会影响NTLP规范。实现可能会将NTLP软状态刷新信息（如果NTLP以这种方式工作）携带到信令应用程序消息上，或者它们甚至可能在层之间结合软状态管理。NTLP和NSLP的状态机在逻辑上保持独立，但实现可以自由地允许它们进行交互，从而将网络上的负载降低到与单片模型相同的水平。
4. It may be helpful for signaling applications to receive state-management related 'triggers' from the NTLP indicating that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signaling application peers. We can consider this another case of route change detection/notification (which the NTLP is also allowed to do anyway). However, apart from generating such
4. 它可能有助于向应用程序发送信号，以从NTLP接收状态管理相关的“触发器”，指示对等方已失败或可用（“向下/向上通知”）。这些触发器与相邻的NTLP对等点有关，而不是向应用程序对等点发送信号。我们可以考虑另一种路由更改检测/通知（NTLP也允许这样做）。但是,除了产生这样的
triggers, the NTLP takes no action itself on such events, other than to ensure that subsequent signaling messages are routed correctly.
触发时，NTLP对此类事件本身不采取任何行动，只是确保后续信令消息正确路由。
5. The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signaling application level. In this sense, up/down notifications are advisories that allow faster reaction to events in the network, but that shouldn't be built into NSLP semantics. (This is essentially the same distinction, with the same rationale, that SNMP makes between notifications and normal message exchanges.)
5. 这些触发器的存在并不能取代NSLP刷新作为在信令应用程序级别保持活跃性的机制。从这个意义上说，向上/向下通知是允许对网络中的事件做出更快反应的建议，但不应将其内置到NSLP语义中。（这本质上与SNMP在通知和正常消息交换之间所做的区别相同，具有相同的原理。）
Path-decoupled signaling is defined as signaling for state installation along the data path, without the restriction of passing only through nodes that are located on the data path. Signaling messages can be routed to nodes that are off the data path, but that are (presumably) aware of it. This allows a looser coupling between signaling and data plane nodes (e.g., at the autonomous system level). Although support for path-decoupled operation is not one of the initial goals of the NSIS work, this section is included for completeness and to capture some initial considerations for future reference.
路径解耦信令被定义为沿数据路径进行状态安装的信令，不受仅通过位于数据路径上的节点的限制。信令消息可以路由到脱离数据路径但（可能）知道它的节点。这使得信令和数据平面节点之间的耦合更加松散（例如，在自治系统级别）。尽管支持路径解耦操作不是NSIS工作的初始目标之一，但为了完整性和获取一些初始注意事项以供将来参考，包含本节。
The main advantages of path-decoupled signaling are ease of deployment and support of additional functionality. The ease of deployment comes from a restriction of the number of impacted nodes in case of deployment and/or upgrade of an NSLP. Path-decoupled signaling would allow, for instance, deploying a solution without upgrading any of the routers in the data plane. Additional functionality that can be supported includes the use of off-path proxies to support authorization or accounting architectures.
路径解耦信令的主要优点是易于部署和支持附加功能。在部署和/或升级NSLP时，受影响节点的数量受到限制，因此易于部署。例如，路径解耦信令将允许在不升级数据平面中的任何路由器的情况下部署解决方案。可以支持的其他功能包括使用非路径代理来支持授权或记帐体系结构。
There are potentially significant differences in the way that the two signaling paradigms should be analyzed. Using a single centralized off-path NE may increase the requirements in terms of message handling; on the other hand, path-decoupled signaling is equally applicable to distributed off-path entities. Failure recovery scenarios need to be analyzed differently because fate-sharing between data and control planes can no longer be assumed. Furthermore, the interpretation of sender/receiver orientation becomes less natural. With the local operation of the NTLP, the impact of path-decoupled signaling on the routing of signaling messages is presumably restricted to the problem of peer determination. The assumption that the off-path NSIS nodes are loosely tied to the data path suggests, however, that peer determination can still be based on L3 routing information. This
在分析这两种信号模式的方式上存在潜在的显著差异。使用单个集中式非路径网元可能会增加消息处理方面的要求；另一方面，路径解耦信令同样适用于分布式非路径实体。故障恢复场景需要进行不同的分析，因为无法再假设数据和控制平面之间的命运共享。此外，发送方/接收方方向的解释变得不那么自然。由于NTLP的本地操作，路径解耦信令对信令消息路由的影响可能仅限于对等确定问题。然而，假设非路径NSIS节点松散地绑定到数据路径，则表明对等确定仍然可以基于L3路由信息。这
means that a path-decoupled signaling solution could be implemented using a lower-layer protocol presenting the same service interface to NSLPs as the path-coupled NTLP. A new message transport protocol (possibly derived from the path-coupled NTLP) would be needed, but NSLP specifications and the inter-layer interaction would be unchanged from the path-coupled case.
这意味着路径解耦信令解决方案可以使用较低层协议来实现，该协议向NSLP提供与路径耦合NTLP相同的服务接口。需要一个新的消息传输协议（可能来自路径耦合的NTLP），但NSLP规范和层间交互将与路径耦合的情况保持不变。
It is clear that many signaling applications will require specific protocol behavior in their NSLP. This section outlines some of the options for NSLP behavior; further work on selecting from these options would depend on detailed analysis of the signaling application in question.
显然，许多信令应用程序在其NSLP中需要特定的协议行为。本节概述了NSLP行为的一些选项；从这些选项中选择的进一步工作将取决于对所讨论的信令应用的详细分析。
In some signaling applications, a node at one end of the data flow takes responsibility for requesting special treatment (such as a resource reservation) from the network. Which end may depend on the signaling application, or on characteristics of the network deployment.
在一些信令应用中，数据流一端的节点负责从网络请求特殊处理（例如资源预留）。哪一端可能取决于信令应用，或取决于网络部署的特征。
In a sender-initiated approach, the sender of the data flow requests and maintains the treatment for that flow. In a receiver-initiated approach, the receiver of the data flow requests and maintains the treatment for that flow. The NTLP itself has no freedom in this area: Next NTLP peers have to be discovered in the sender-to-receiver direction, but after that the default assumption is that signaling is possible both upstream and downstream (unless a signaling application specifically indicates that this is not required). This implies that backward routing state must be maintained by the NTLP or that backward routing information must be available in the signaling message.
在发送方发起的方法中，数据流的发送方请求并维护对该流的处理。在接收方发起的方法中，数据流的接收方请求并维护对该流的处理。NTLP本身在这一方面没有自由：必须在发送方到接收方的方向上发现下一个NTLP对等方，但在此之后，默认假设是信令在上游和下游都是可能的（除非信令应用程序明确指出这是不需要的）。这意味着反向路由状态必须由NTLP维护，或者反向路由信息必须在信令消息中可用。
The sender- and receiver-initiated approaches have several differences in their operational characteristics. The main ones are as follows:
发送方和接收方发起的方法在操作特性上有几个不同之处。主要内容如下：
o In a receiver-initiated approach, the signaling messages traveling from the receiver to the sender must be backward routed such that they follow exactly the same path as was followed by the signaling messages belonging to the same flow traveling from the sender to the receiver. In a sender-initiated approach, provided that acknowledgements and notifications can be delivered securely to the sending node, backward routing is not necessary, and nodes do not have to maintain backward routing state.
o 在接收方发起的方法中，从接收方到发送方的信令消息必须反向路由，以便它们遵循与从发送方到接收方的相同流中的信令消息完全相同的路径。在发送方发起的方法中，如果确认和通知可以安全地传递给发送节点，则不需要反向路由，并且节点不必保持反向路由状态。
o In a sender-initiated approach, a mobile node can initiate a reservation for its outgoing flows as soon as it has moved to another roaming subnetwork. In a receiver-initiated approach, a mobile node has to inform the receiver about its handover, thus allowing the receiver to initiate a reservation for these flows. For incoming flows, the reverse argument applies.
o 在发送方发起的方法中，移动节点一旦移动到另一个漫游子网，就可以为其传出流发起预约。在接收器发起的方法中，移动节点必须通知接收器其切换，从而允许接收器发起对这些流的保留。对于传入流，反向参数适用。
o In general, setup and modification will be fastest if the node responsible for authorizing these actions can initiate them directly within the NSLP. A mismatch between authorizing and initiating NEs will cause additional message exchanges, either in the NSLP or in a protocol executed prior to NSIS invocation. Depending on how the authorization for a particular signaling application is done, this may favor either sender- or receiver-initiated signaling. Note that this may complicate modification of network control state for existing flows.
o 通常，如果负责授权这些操作的节点可以直接在NSLP内启动这些操作，则设置和修改将最快。授权和启动网元之间的不匹配将导致额外的消息交换，无论是在NSLP中还是在NSIS调用之前执行的协议中。根据特定信令应用的授权方式，这可能有利于发送方或接收方发起的信令。请注意，这可能会使现有流的网络控制状态修改复杂化。
For some signaling applications and scenarios, signaling may only be considered for a unidirectional data flow. However, in other cases, there may be interesting relationships in the signaling between the two flows of a bi-directional session; an example is QoS for a voice call. Note that the path in the two directions may differ due to asymmetric routing. In the basic case, bi-directional signaling can simply use a separate instance of the same signaling mechanism in each direction.
对于某些信令应用和场景，信令可能仅考虑单向数据流。然而，在其他情况下，在双向会话的两个流之间的信令中可能存在有趣的关系；一个例子是语音呼叫的QoS。请注意，由于非对称布线，两个方向上的路径可能不同。在基本情况下，双向信令可以简单地在每个方向上使用相同信令机制的单独实例。
In constrained topologies where parts of the route are symmetric, it may be possible to use a more unified approach to bi-directional signaling; e.g., carrying the two signaling directions in common messages. This optimization might be used for example to make mobile QoS signaling more efficient.
在部分路由对称的受限拓扑中，可以使用更统一的双向信令方法；e、 例如，在公共消息中承载两个信令方向。例如，该优化可用于使移动QoS信令更有效。
In either case, the correlation of the signaling for the two flow directions is carried out in the NSLP. The NTLP would simply be enabled to bundle the messages together.
在任一情况下，在NSLP中执行两个流方向的信令的相关。只需启用NTLP即可将消息捆绑在一起。
It is likely that the appropriate way to describe the state for which NSIS is signaling will vary from one part of the network to another (depending on the signaling application). For example, in the QoS case, resource descriptions that are valid for inter-domain links will probably be different from those useful for intra-domain operation (and the latter will differ from one domain to another).
描述NSI正在信令的状态的适当方式很可能会因网络的不同部分而有所不同（取决于信令应用）。例如，在QoS情况下，对域间链路有效的资源描述可能不同于对域内操作有用的资源描述（并且后者在不同的域中会有所不同）。
One way to address this issue is to consider the state description used within the NSLP as carried in globally-understood objects and locally-understood objects. The local objects are only applicable for intra-domain signaling, while the global objects are mainly used in inter-domain signaling. Note that the local objects are still part of the protocol but are inserted, used, and removed by one single domain.
解决这个问题的一种方法是考虑在全局理解的对象和本地理解的对象中携带的NSLP中使用的状态描述。本地对象仅适用于域内信令，而全局对象主要用于域间信令。请注意，本地对象仍然是协议的一部分，但由单个域插入、使用和删除。
The purpose of this division is to provide additional flexibility in defining the objects carried by the NSLP such that only the objects applicable in a particular setting are used. One approach for reflecting the distinction is that local objects could be put into separate local messages that are initiated and terminated within one single domain; an alternative is that they could be "stacked" within the NSLP messages that are used anyway for inter-domain signaling.
本部分的目的是在定义NSLP携带的对象时提供额外的灵活性，以便仅使用适用于特定设置的对象。反映这种区别的一种方法是，可以将本地对象放入单独的本地消息中，这些消息在一个域中启动和终止；另一种选择是，它们可以“堆叠”在NSLP消息中，这些消息无论如何都用于域间信令。
It is a well-known problem that per-flow signaling in large-scale networks presents scaling challenges because of the large number of flows that may traverse individual nodes.
众所周知，大规模网络中的每流信令由于可能穿越单个节点的大量流而面临扩展挑战。
The possibilities for aggregation at the level of the NTLP are quite limited; the primary scaling approach for path-coupled signaling is for a signaling application to group flows together and to perform signaling for the aggregate, rather than for the flows individually. The aggregate may be created in a number of ways; for example, the individual flows may be sent down a tunnel, or given a common Differentiated Services Code Point (DSCP) marking. The aggregation and de-aggregation points perform per flow signaling, but nodes within the aggregation region should only be forced to process signaling messages for the aggregate. This depends on the ability of the interior nodes to ignore the per-flow signaling as discussed in Section 3.2.3.
在NTLP级别进行聚合的可能性非常有限；路径耦合信令的主要缩放方法是，信令应用程序将流分组在一起，并为聚合执行信令，而不是单独为流执行信令。可通过多种方式创建骨料；例如，单个流可以沿着隧道发送，或者给定公共区分服务代码点（DSCP）标记。聚合和反聚合点执行每流信令，但聚合区域内的节点应仅强制处理聚合的信令消息。这取决于内部节点忽略第3.2.3节中讨论的每流信令的能力。
Individual NSLPs will need to specify what aggregation means in their context, and how it should be performed. For example, in the QoS context it is possible to add together the resources specified in a number of separate reservations. In the case of other applications, such as signaling to NATs and firewalls, the feasibility (and even the meaning) of aggregation is less clear.
单个NSLP需要指定聚合在其上下文中的含义，以及应该如何执行。例如，在QoS上下文中，可以将多个单独的保留中指定的资源添加到一起。在其他应用中，如NAT和防火墙的信令，聚合的可行性（甚至意义）不太清楚。
The assumption in this framework is that the NTLP will operate 'locally'; that is, just over the scope of a single peer relationship. End-to-end operation is built up by concatenating these relationships. Non-local operation (if any) will take place in NSLPs.
该框架中的假设是NTLP将“本地”运营；也就是说，仅在单一对等关系的范围内。端到端操作是通过连接这些关系建立起来的。非本地操作（如有）将在NSLP中进行。
The peering relations may also have an impact on the required amount of state at each NSIS entity. When direct interaction with remote peers is not allowed, it may be required to keep track of the path that a message has followed through the network. This could be achieved by keeping per-flow state at the NSIS entities, as is done in RSVP. Another approach would be to maintain a record route object in the messages; this object would be carried within the NSIS protocols, rather than depend on the route-recording functionality provided by the IP layer.
对等关系还可能对每个NSIS实体所需的状态量产生影响。当不允许与远程对等方直接交互时，可能需要跟踪消息在网络中的路径。这可以通过在NSIS实体中保持每个流状态来实现，就像在RSVP中所做的那样。另一种方法是在消息中维护记录路由对象；该对象将在NSIS协议中承载，而不是依赖于IP层提供的路由记录功能。
We are assuming that the NTLP provides a simple message transfer service, and that any acknowledgements or notifications it generates are handled purely internally (and apply within the scope of a single NTLP peer relationship).
我们假设NTLP提供了一个简单的消息传输服务，并且它生成的任何确认或通知都是纯内部处理的（并且在单个NTLP对等关系的范围内应用）。
However, we expect that some signaling applications will require acknowledgements regarding the failure/success of state installation along the data path, and this will be an NSLP function.
然而，我们预计，一些信令应用程序将需要关于沿数据路径安装状态失败/成功的确认，这将是一个NSLP功能。
Acknowledgements can be sent along the sequence of NTLP peer relationships towards the signaling initiator, which relieves the requirements on the security associations that need to be maintained by NEs and that can allow NAT traversal in both directions. (If this direction is towards the sender, it implies maintaining reverse routing state in the NTLP.) In certain circumstances (e.g., trusted domains), an optimization could be to send acknowledgements directly to the signaling initiator outside the NTLP (see Section 3.2.2), although any such approach would have to take into account the necessity of handling denial of service attacks launched from outside the network.
确认可以沿着NTLP对等关系的序列发送到信令发起方，这减轻了对需要由网元维护的安全关联的要求，并且可以允许在两个方向上进行NAT遍历。（如果该方向指向发送方，则意味着在NTLP中保持反向路由状态。）在某些情况下（例如，受信任域），优化可以是直接向NTLP外部的信令启动器发送确认（参见第3.2.2节），尽管任何此类方法都必须考虑处理从网络外部发起的拒绝服务攻击的必要性。
The semantics of the acknowledgement messages are of particular importance. An NE sending a message could assume responsibility for the entire downstream chain of NEs, indicating (for instance) the availability of reserved resources for the entire downstream path. Alternatively, the message could have a more local meaning, indicating (for instance) that a certain failure or degradation occurred at a particular point in the network.
确认消息的语义特别重要。发送消息的网元可以承担整个网元下游链的责任，指示（例如）整个下游路径的保留资源的可用性。或者，该消息可以具有更局部的含义，指示（例如）在网络中的特定点处发生了某种故障或降级。
Notifications differ from acknowledgements because they are not (necessarily) generated in response to other signaling messages. This means that it may not be obvious how to determine where the notification should be sent. Other than that, the same considerations apply as for acknowledgements. One useful distinction to make would be to differentiate between notifications that trigger a signaling action and others that don't. The security requirements for the latter are less stringent, which means they could be sent directly to the NE they are destined for (provided that this NE can be determined).
通知与确认不同，因为它们（不一定）是响应其他信令消息而生成的。这意味着，如何确定通知应该发送到哪里可能并不明显。除此之外，同样的考虑也适用于确认。一个有用的区别是区分触发信令操作的通知和不触发信令操作的通知。后者的安全要求较不严格，这意味着它们可以直接发送到它们的目的地（前提是可以确定该网元）。
In some cases, it will be possible to achieve the necessary level of signaling security by using basic 'channel security' mechanisms [11] at the level of the NTLP, and the possibilities are described in Section 4.7. In other cases, signaling applications may have specific security requirements, in which case they are free to invoke their own authentication and key exchange mechanisms and to apply 'object security' to specific fields within the NSLP messages.
在某些情况下，通过在NTLP级别上使用基本的“信道安全”机制[11]，可以达到必要的信令安全级别，其可能性在第4.7节中描述。在其他情况下，信令应用程序可能有特定的安全要求，在这种情况下，它们可以自由调用自己的身份验证和密钥交换机制，并对NSLP消息中的特定字段应用“对象安全性”。
In addition to authentication, the authorization (to manipulate network control state) has to be considered as functionality above the NTLP level, since it will be entirely application specific. Indeed, authorization decisions may be handed off to a third party in the protocol (e.g., for QoS, the resource management function as described in Section 6.1.4). Many different authorization models are possible, and the variations impact:
除了身份验证之外，授权（操纵网络控制状态）必须被视为NTLP级别以上的功能，因为它完全是特定于应用程序的。事实上，授权决定可以移交给协议中的第三方（例如，为了QoS，第6.1.4节中描述的资源管理功能）。许多不同的授权模型都是可能的，其变化会影响：
o what message flows take place -- for example, whether authorization information is carried along with a control state modification request or is sent in the reverse direction in response to it;
o 发生了什么消息流——例如，授权信息是与控制状态修改请求一起携带，还是响应请求以相反方向发送；
o what administrative relationships are required -- for example, whether authorization takes place only between peer signaling applications, or over longer distances.
o 需要什么样的管理关系——例如，授权是仅在对等信令应用程序之间进行，还是在更长的距离上进行。
Because the NTLP operates only between adjacent peers and places no constraints on the direction or order in which signaling applications can send messages, these authorization aspects are left open to be defined by each NSLP. Further background discussion of this issue is contained in [12].
由于NTLP仅在相邻对等方之间运行，并且对信令应用程序可以发送消息的方向或顺序没有任何限制，因此这些授权方面留待每个NSLP定义。关于这个问题的进一步背景讨论载于[12]。
This section describes the overall functionality required from the NTLP. It mentions possible protocol components within the NTLP layer and the different possible addressing modes that can be utilized, as well as the assumed transport and state management functionality. The interfaces between NTLP and the layers above and below it are identified, with a description of the identity elements that appear on these interfaces.
本节介绍NTLP所需的总体功能。它提到了NTLP层中可能的协议组件和可利用的不同可能寻址模式，以及假定的传输和状态管理功能。NTLP和其上下各层之间的接口已标识，并对这些接口上出现的标识元素进行了描述。
This discussion is not intended to design the NTLP or even to enumerate design options, although some are included as examples. The goal is to provide a general discussion of required functionality and to highlight some of the issues associated with this.
本讨论的目的不是设计NTLP，甚至不是列举设计选项，尽管其中一些选项是作为示例包含的。目标是对所需功能进行一般性讨论，并强调与此相关的一些问题。
The NTLP includes all functionality below the signaling application layer and above the IP layer. The functionality that is required within the NTLP is outlined in Section 3.2.4, with some more details in Sections 3.2.5 and 4.3.
NTLP包括信令应用层之下和IP层之上的所有功能。第3.2.4节概述了NTLP所需的功能，第3.2.5节和第4.3节提供了更多详细信息。
Some NTLP functionality could be provided via components operating as sublayers within the NTLP design. For example, if specific transport capabilities are required (such as congestion avoidance, retransmission, and security), then existing protocols (such as TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This possibility is not required or excluded by this framework.
一些NTLP功能可以通过在NTLP设计中作为子层运行的组件提供。例如，如果需要特定的传输能力（例如拥塞避免、重传和安全性），那么现有协议（例如TCP+TLS或DCCP+IPsec）可以合并到NTLP中。本框架不要求或排除这种可能性。
If peer-peer addressing (Section 4.2) is used for some messages, then active next-peer discovery functionality will be required within the NTLP to support the explicit addressing of these messages. This could use message exchanges for dynamic peer discovery as a sublayer within the NTLP; there could also be an interface to external mechanisms to carry out this function.
如果对某些消息使用对等寻址（第4.2节），则NTLP内需要活动的下一个对等发现功能，以支持这些消息的显式寻址。这可以使用消息交换作为NTLP内的子层进行动态对等发现；也可以有一个与外部机制的接口来执行此功能。
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
Figure 6: Options for NTLP Structure
图6:NTLP结构的选项
There are two ways to address a signaling message being transmitted between NTLP peers:
有两种方法可以寻址NTLP对等点之间传输的信令消息：
o peer-peer, where the message is addressed to a neighboring NSIS entity that is known to be closer to the destination NE.
o 对等，其中消息被寻址到邻近的NSIS实体，该NSIS实体已知更靠近目的地网元。
o end-to-end, where the message is addressed to the flow destination directly and intercepted by an intervening NE.
o 端到端，其中消息直接寻址到流目的地，并被中间网元截获。
With peer-peer addressing, an NE will determine the address of the next NE based on the payload of the message (and potentially on the previous NE). This requires that the address of the destination NE be derivable from the information present in the payload, either by using some local routing table or through participation in active peer discovery message exchanges. Peer-peer addressing inherently supports tunneling of messages between NEs, and is equally applicable to the path-coupled and path-decoupled cases.
通过对等寻址，网元将基于消息的有效负载（可能在前一个网元上）确定下一个网元的地址。这要求通过使用一些本地路由表或通过参与主动对等发现消息交换，目的地NE的地址可以从有效载荷中存在的信息导出。对等寻址本质上支持网元之间的消息隧道，同样适用于路径耦合和路径解耦的情况。
In the case of end-to-end addressing, the message is addressed to the data flow receiver, and (some of) the NEs along the data path intercept the messages. The routing of the messages should follow exactly the same path as the associated data flow (but see Section 5.1.1 on this point). Note that securing messages sent this way raises some interesting security issues (these are discussed in [2]). In addition, it is a matter of the protocol design what should be used as the source address of the message (the flow source or signaling source).
在端到端寻址的情况下，消息被寻址到数据流接收器，并且（一些）沿着数据路径的网元截获消息。消息的路由应遵循与相关数据流完全相同的路径（但见第5.1.1节）。请注意，保护以这种方式发送的消息会引发一些有趣的安全问题（这些问题在[2]中讨论）。此外，应该使用什么作为消息的源地址（流源或信令源）是协议设计的问题。
It is not possible at this stage to mandate one addressing mode or the other. Indeed, each is necessary for some aspects of NTLP operation: In particular, initial discovery of the next downstream peer will usually require end-to-end addressing, whereas reverse routing will always require peer-peer addressing. For other message types, the choice is a matter of protocol design. The mode used is not visible to the NSLP, and the information needed in each case is available from the flow identifier (Section 4.6.1) or locally stored NTLP state.
在这个阶段，不可能强制一种寻址模式或另一种寻址模式。实际上，在NTLP操作的某些方面，每个都是必要的：特别是，下一个下游对等点的初始发现通常需要端到端寻址，而反向路由总是需要对等点寻址。对于其他消息类型，选择取决于协议设计。所使用的模式对NSLP不可见，每种情况下所需的信息可从流量标识符（第4.6.1节）或本地存储的NTLP状态中获得。
The NSIS signaling protocols are responsible for transporting (signaling) data around the network; in general, this requires functionality such as congestion management, reliability, and so on. This section discusses how much of this functionality should be provided within the NTLP. It appears that this doesn't affect the basic way in which the NSLP/NTLP layers relate to each other (e.g.,
NSIS信令协议负责在网络周围传输（信令）数据；通常，这需要诸如拥塞管理、可靠性等功能。本节讨论NTLP中应提供多少功能。这似乎不影响NSLP/NTLP层相互关联的基本方式（例如。，
in terms of the semantics of the inter-layer interaction); it is much more a question of the overall performance/complexity tradeoff implied by placing certain functions within each layer.
就层间交互的语义而言）；这更像是在每一层中放置某些函数所隐含的整体性能/复杂性权衡问题。
Note that, per the discussion at the end of Section 3.2.3, there may be cases where intermediate nodes wish to modify messages in transit even though they do not perform full signaling application processing. In this case, not all the following functionality would be invoked at every intermediate node.
注意，根据第3.2.3节末尾的讨论，可能存在中间节点希望修改传输中的消息的情况，即使它们不执行完整的信令应用程序处理。在这种情况下，并不是每个中间节点都会调用以下所有功能。
The following functionality is assumed to lie within the NTLP:
假设以下功能位于NTLP内：
1. Bundling together of small messages (comparable to [13]) can be provided locally by the NTLP as an option, if desired; it doesn't affect the operation of the network elsewhere. The NTLP should always support unbundling, to avoid the cost of negotiating the feature as an option. (The related function of refresh summarization -- where objects in a refresh message are replaced with a reference to a previous message identifier -- is left to NSLPs, which can then do this in a way tuned to the state management requirements of the signaling application. Additional transparent compression functionality could be added to the NTLP design later as a local option.) Note that end-to-end addressed messages for different flows cannot be bundled safely unless the next node on the outgoing interface is known to be NSIS-aware.
1. 如果需要，NTLP可以在本地提供捆绑小消息（与[13]类似）的选项；它不会影响其他地方网络的运行。NTLP应始终支持分拆，以避免将功能作为选项进行协商的成本。（刷新摘要的相关功能——刷新消息中的对象被替换为对先前消息标识符的引用——留给NSLP，NSLP可以按照信令应用程序的状态管理要求进行调整。可以向NTLP添加额外的透明压缩功能请注意，除非传出接口上的下一个节点已知是NSIS感知的，否则不同流的端到端寻址消息无法安全绑定。
2. When needed, message fragmentation should be provided by the NTLP. The use of IP fragmentation for large messages may lead to reduced reliability and may be incompatible with some addressing schemes. Therefore, this functionality should be provided within the NTLP as a service for NSLPs that generate large messages. How the NTLP determines and accommodates Maximum Transmission Unit (MTU) constraints is left as a matter of protocol design. To avoid imposing the cost of reassembly on intermediate nodes, the fragmentation scheme used should allow for the independent forwarding of individual fragments towards a node hosting an interested NSLP.
2. 需要时，NTLP应提供消息分段。对大型消息使用IP分段可能会导致可靠性降低，并且可能与某些寻址方案不兼容。因此，应在NTLP中提供此功能，作为生成大型消息的NSLP的服务。NTLP如何确定和适应最大传输单元（MTU）约束是协议设计的问题。为了避免在中间节点上增加重新组装的成本，所使用的分段方案应允许将单个片段独立转发到承载感兴趣的NSLP的节点。
3. There can be significant benefits for signaling applications if state-changing messages are delivered reliably (as introduced in [13] for RSVP; see also the more general analysis of [14]). This does not change any assumption about the use of soft-state by NSLPs to manage signaling application state, and it leaves the responsibility for detecting and recovering from application layer error conditions in the NSLP. However, it means that such functionality does not need to be tuned to handle fast recovery from message loss due to congestion or corruption in the lower layers, and it also means that the NTLP can prevent the
3. 如果状态改变消息能够可靠地传递（如RSVP的[13]中所述；另请参见[14]中更一般的分析），那么信令应用程序将获得显著的好处。这不会改变关于NSLP使用软状态来管理信令应用程序状态的任何假设，并且将检测和恢复NSLP中的应用程序层错误条件的责任留给NSLP。然而，这意味着不需要对此类功能进行调整，以处理由于较低层中的拥塞或损坏而导致的消息丢失的快速恢复，并且还意味着NTLP可以防止
amplification of message loss rates caused by fragmentation. Reliable delivery functionality is invoked by the NSLP on a message-by-message basis and is always optional to use.
碎片导致的消息丢失率放大。可靠的传递功能由NSLP逐个消息地调用，并且始终是可选的。
4. The NTLP should not allow signaling messages to cause congestion in the network (i.e., at the IP layer). Congestion could be caused by retransmission of lost signaling packets or by upper layer actions (e.g., a flood of signaling updates to recover from a route change). In some cases, it may be possible to engineer the network to ensure that signaling cannot overload it; in others, the NTLP would have to detect congestion and to adapt the rate at which it allows signaling messages to be transmitted. Principles of congestion control in Internet protocols are given in [15]. The NTLP may or may not be able to detect overload in the control plane itself (e.g., an NSLP-aware node several NTLP-hops away that cannot keep up with the incoming message rate) and indicate this as a flow-control condition to local signaling applications. However, for both the congestion and overload cases, it is up to the signaling applications themselves to adapt their behavior accordingly.
4. NTLP不应允许信令消息导致网络拥塞（即，在IP层）。拥塞可能由丢失的信令分组的重新传输或上层操作（例如，从路由更改中恢复的大量信令更新）引起。在某些情况下，可以对网络进行工程设计，以确保信令不会使其过载；在其他情况下，NTLP必须检测拥塞并调整其允许信令消息传输的速率。互联网协议中的拥塞控制原理见[15]。NTLP可能能够也可能无法检测到控制平面本身中的过载（例如，一个NSLP感知节点在几个NTLP跳之外，无法跟上传入消息速率），并将此作为流控制条件指示给本地信令应用程序。然而，对于拥塞和过载两种情况，信令应用程序本身需要相应地调整其行为。
The NTLP interacts with 'lower layers' of the protocol stack for the purposes of sending and receiving signaling messages. This framework places the lower boundary of the NTLP at the IP layer. The interface to the lower layer is therefore very simple:
NTLP与协议栈的“较低层”进行交互，以发送和接收信令消息。该框架将NTLP的下边界置于IP层。因此，与下层的接口非常简单：
o The NTLP sends raw IP packets
o NTLP发送原始IP数据包
o The NTLP receives raw IP packets. In the case of peer-peer addressing, they have been addressed directly to it. In the case of end-to-end addressing, this will be achieved by intercepting packets that have been marked in some special way (by special protocol number or by some option interpreted within the IP layer, such as the router alert option).
o NTLP接收原始IP数据包。在对等寻址的情况下，它们被直接寻址到it。在端到端寻址的情况下，这将通过截取以某种特殊方式（通过特殊协议编号或通过IP层内解释的某些选项，如路由器警报选项）标记的数据包来实现。
o The NTLP receives indications from the IP layer (including local forwarding tables and routing protocol state) that provide some information about route changes and similar events (see Section 5.1).
o NTLP接收来自IP层的指示（包括本地转发表和路由协议状态），这些指示提供有关路由更改和类似事件的一些信息（见第5.1节）。
For correct message routing, the NTLP needs to have some information about link and IP layer configuration of the local networking stack. In general, it needs to know how to select the outgoing interface for a signaling message and where this must match the interface that will be used by the corresponding flow. This might be as simple as just allowing the IP layer to handle the message using its own routing
对于正确的消息路由，NTLP需要有一些关于本地网络堆栈的链路和IP层配置的信息。通常，它需要知道如何为信令消息选择传出接口，以及该接口必须与相应流使用的接口匹配的位置。这可能与只允许IP层使用自己的路由处理消息一样简单
table. There is no intention to do something different from IP routing (for end-to-end addressed messages); however, some hosts allow applications to bypass routing for their data flows, and the NTLP processing must account for this. Further network layer information would be needed to handle scoped addresses (if such things ever exist).
桌子不打算做与IP路由不同的事情（对于端到端寻址消息）；但是，有些主机允许应用程序绕过其数据流的路由，NTLP处理必须考虑到这一点。需要进一步的网络层信息来处理作用域地址（如果存在这种情况）。
Configuration of lower-layer operation to handle flows in particular ways is handled by the signaling application.
以特定方式处理流的下层操作的配置由信令应用程序处理。
The NTLP offers transport-layer services to higher-layer signaling applications for two purposes: sending and receiving signaling messages, and exchanging control and feedback information.
NTLP为高层信令应用程序提供传输层服务，用于两个目的：发送和接收信令消息，以及交换控制和反馈信息。
For sending and receiving messages, two basic control primitives are required:
发送和接收消息需要两个基本的控制原语：
o Send Message, to allow the signaling application to pass data to the NTLP for transport.
o 发送消息，以允许信令应用程序将数据传递给NTLP进行传输。
o Receive Message, to allow the NTLP to pass received data to the signaling application.
o 接收消息，以允许NTLP将接收到的数据传递给信令应用程序。
The NTLP and signaling application may also want to exchange other control information, such as the following:
NTLP和信令应用程序可能还希望交换其他控制信息，例如：
o Signaling application registration/de-registration, so that particular signaling application instances can register their presence with the transport layer. This may also require some identifier to be agreed upon between the NTLP and signaling application to support the exchange of further control information and to allow the de-multiplexing of incoming data.
o 信令应用注册/取消注册，以便特定信令应用实例可以向传输层注册它们的存在。这还可能需要在NTLP和信令应用程序之间商定一些标识符，以支持进一步控制信息的交换，并允许对传入数据进行解复用。
o NTLP configuration, allowing signaling applications to indicate what optional NTLP features they want to use, and to configure NTLP operation, such as controlling what transport layer state should be maintained.
o NTLP配置，允许信令应用程序指示他们想要使用的可选NTLP功能，并配置NTLP操作，例如控制应该保持的传输层状态。
o Error messages, to allow the NTLP to indicate error conditions to the signaling application, and vice versa.
o 错误消息，以允许NTLP向信令应用程序指示错误条件，反之亦然。
o Feedback information, such as route change indications so that the signaling application can decide what action to take.
o 反馈信息，如路线改变指示，以便信令应用程序可以决定采取什么行动。
The flow identification is a method of identifying a flow in a unique way. All packets associated with the same flow will be identified by the same flow identifier. The key aspect of the flow identifier is to provide enough information such that the signaling flow receives the same treatment along the data path as the actual data itself; i.e., consistent behavior is applied to the signaling and data flows by a NAT or policy-based forwarding engine.
流量识别是一种以独特方式识别流量的方法。与相同流关联的所有数据包将由相同的流标识符标识。流标识符的关键方面是提供足够的信息，使得信令流沿着数据路径接收与实际数据本身相同的处理；i、 例如，一致性行为通过NAT或基于策略的转发引擎应用于信令和数据流。
Information that could be used in flow identification may include:
可用于流量识别的信息包括：
o source IP address;
o 源IP地址；
o destination IP address;
o 目的IP地址；
o protocol identifier and higher layer (port) addressing;
o 协议标识符和更高层（端口）寻址；
o flow label (typical for IPv6);
o 流标签（典型用于IPv6）；
o SPI field for IPsec encapsulated data; and
o 用于IPsec封装数据的SPI字段；和
o DSCP/TOS field.
o DSCP/TOS字段。
It is assumed that at most limited wildcarding on these identifiers is needed.
假设这些标识符最多需要有限的通配符。
We assume here that the flow identification is not hidden within the NSLP, but is explicitly part of the NTLP. The justification for this is that being able to do NSIS processing, even at a node which was unaware of the specific signaling application (see Section 3.2.3) might be valuable. An example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written.
我们在此假设流标识不隐藏在NSLP中，而是显式地属于NTLP的一部分。这样做的理由是，即使在不知道特定信令应用（见第3.2.3节）的节点上，也能够进行NSIS处理可能是有价值的。一个示例场景是通过寻址边界的消息，其中必须重新写入流标识。
There are circumstances in which being able to refer to signaling application state independently of the underlying flow is important. For example, if the address of one of the flow endpoints changes due to a mobility event, it is desirable to be able to change the flow identifier without having to install a completely new reservation. The session identifier provides a method to correlate the signaling about the different flows with the same network control state.
在某些情况下，能够独立于底层流引用信令应用程序状态非常重要。例如，如果流端点之一的地址由于移动事件而改变，则希望能够在不必安装全新的保留的情况下改变流标识符。会话标识符提供了将关于不同流的信令与相同网络控制状态相关联的方法。
The session identifier is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. However, we assume here that it should be visible within the NTLP. This enables it to be used to control NTLP behavior; for example, by controlling how the transport layer should forward packets belonging to this session (as opposed to this signaling application). In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported (see Section 4.6.3 for more information on signaling application identification).
会话标识符本质上是一个信令应用程序概念，因为它仅用于特定于应用程序的非平凡状态管理操作。然而，我们在此假设它应该在NTLP中可见。这使得它能够用于控制NTLP行为；例如，通过控制传输层应如何转发属于该会话的数据包（与该信令应用相反）。此外，如果支持这种操作场景，NTLP可以使用会话标识符在同一信令应用程序的多个实例之间解复用接收到的信令消息（有关信令应用程序标识的更多信息，请参阅第4.6.3节）。
To be useful for mobility support, the session identifier should be globally unique, and it should not be modified end-to-end. It is well known that it is practically impossible to generate identifiers in a way that guarantees this property; however, using a large random number makes it highly likely. In any case, the NTLP ascribes no valuable semantics to the identifier (such as 'session ownership'); this problem is left to the signaling application, which may be able to secure it to be used for this purpose.
为了对移动性支持有用，会话标识符应该是全局唯一的，并且不应该端到端地修改它。众所周知，以保证该属性的方式生成标识符实际上是不可能的；然而，使用一个大的随机数使它很有可能发生。在任何情况下，NTLP都不会将有价值的语义赋予标识符（例如“会话所有权”）；这个问题留给信令应用程序解决，它可能能够确保用于此目的。
Because the NTLP can be used to support several NSLP types, there is a need to identify which type a particular signaling message exchange is being used for. This is to support:
由于NTLP可用于支持多种NSLP类型，因此需要确定特定信令消息交换用于哪种类型。这是为了支持：
o processing of incoming messages -- the NTLP should be able to demultiplex these towards the appropriate signaling applications; and
o 处理传入消息——NTLP应该能够将这些消息解复用到适当的信令应用程序；和
o processing of general messages at an NSIS-aware intermediate node -- if the node does not handle the specific signaling application, it should be able to make a forwarding decision without having to parse upper-layer information.
o 在NSIS感知的中间节点上处理一般消息——如果该节点不处理特定的信令应用程序，它应该能够做出转发决策，而不必解析上层信息。
No position is taken on the form of the signaling application identifier, or even the structure of the signaling application 'space': free-standing applications, potentially overlapping groups of capabilities, etc. These details should not influence the rest of the NTLP design.
未对信令应用程序标识符的形式，甚至信令应用程序“空间”的结构采取任何立场：独立应用程序、可能重叠的功能组等。这些细节不应影响NTLP设计的其余部分。
It is assumed that the only security service required within the NTLP is channel security. Channel security requires a security association to be established between the signaling endpoints, which is carried out via some authentication and key management exchange. This functionality could be provided by reusing a standard protocol.
假定NTLP中唯一需要的安全服务是通道安全。信道安全性要求在信令端点之间建立安全关联，该关联通过某种身份验证和密钥管理交换来执行。可以通过重用标准协议来提供此功能。
In order to protect a particular signaling exchange, the NSIS entity needs to select the security association that it has in place with the next NSIS entity that will be receiving the signaling message. The ease of doing this depends on the addressing model in use by the NTLP (see Section 4.2).
为了保护特定信令交换，NSIS实体需要选择它与将接收信令消息的下一个NSIS实体的安全关联。这取决于NTLP使用的寻址模型（见第4.2节）。
Channel security can provide many different types of protection to signaling exchanges, including integrity and replay protection and encryption. It is not clear which of these is required at the NTLP layer, although most channel security mechanisms support them all. It is also not clear how tightly an NSLP can 'bind' to the channel security service provided by the NTLP.
信道安全性可以为信令交换提供许多不同类型的保护，包括完整性和重播保护以及加密。虽然大多数通道安全机制都支持NTLP层，但尚不清楚需要哪一个。NSLP与NTLP提供的通道安全服务的“绑定”程度也不清楚。
Channel security can also be applied to the signaling messages with differing granularity; i.e., all or parts of the signaling message may be protected. For example, if the flow is traversing a NAT, only the parts of the message that do not need to be processed by the NAT should be protected. (Alternatively, if the NAT takes part in NTLP security procedures, it only needs to be given access to the message fields containing addresses, often just the flow id.) Which parts of the NTLP messages need protecting is an open question, as is what type of protection should be applied to each.
信道安全性还可以应用于具有不同粒度的信令消息；i、 例如，信令消息的全部或部分可以被保护。例如，如果流正在穿越NAT，则只应保护消息中不需要NAT处理的部分。（或者，如果NAT参与NTLP安全过程，则只需授予其对包含地址的消息字段的访问权限，通常仅需流id即可。）NTLP消息的哪些部分需要保护是一个悬而未决的问题，每个部分应该应用何种类型的保护也是一个悬而未决的问题。
The NTLP is responsible for determining the next node to be visited by the signaling protocol. For path-coupled signaling, this next node should be one that will be visited by the data flow. In practice, this peer discovery will be approximate, as any node could use any feature of the peer discovery packet to route it differently from the corresponding data flow packets. Divergence between the data and signaling paths can occur due to load sharing or load balancing (Section 5.1.1). An example specific to the case of QoS is given in Section 6.1.1. Route changes cause a temporary divergence between the data path and the path on which signaling state has been installed. The occurrence, detection, and impact of route changes is described in Section 5.1.2. A description of this issue in the context of QoS is given in Section 6.1.2.
NTLP负责确定信令协议要访问的下一个节点。对于路径耦合信令，下一个节点应该是数据流将访问的节点。在实践中，该对等发现将是近似的，因为任何节点都可以使用对等发现分组的任何特征来不同于相应的数据流分组来路由它。由于负载共享或负载平衡（第5.1.1节），数据和信令路径之间可能会出现分歧。第6.1.1节给出了特定于QoS情况的示例。路由更改会导致数据路径和已安装信令状态的路径之间出现临时分歧。第5.1.2节描述了路线变化的发生、检测和影响。第6.1.2节中给出了QoS背景下该问题的描述。
Load sharing or load balancing is a network optimization technique that exploits the existence of multiple paths to the same destination in order to obtain benefits in terms of protection, resource efficiency, or network stability. It has been proposed for a number of routing protocols, such as OSPF [16] and others. In general, load sharing means that packet forwarding will take into account header fields in addition to the destination address; a general discussion of such techniques and the problems they cause is provided in [17].
负载共享或负载平衡是一种网络优化技术，它利用到同一目的地的多条路径的存在，以获得保护、资源效率或网络稳定性方面的好处。它已被提出用于许多路由协议，如OSPF[16]和其他。一般来说，负载共享意味着除了目的地址之外，分组转发还将考虑报头字段；[17]中对此类技术及其引起的问题进行了一般性讨论。
The significance of load sharing in the context of NSIS is that routing of signaling messages using end-to-end addressing does not guarantee that these messages will follow the data path. Policy-based forwarding for data packets -- where the outgoing link is selected based on policy information about fields additional to the packet destination address -- has the same impact. Signaling and data packets may diverge because of both of these techniques.
NSIS环境中负载共享的意义在于，使用端到端寻址的信令消息路由不能保证这些消息将遵循数据路径。基于策略的数据包转发——其中，根据关于数据包目标地址以外字段的策略信息选择传出链路——具有相同的影响。由于这两种技术，信令和数据包可能会出现分歧。
If signaling packets are given source and destination addresses identical to data packets, signaling and data may still diverge because of layer-4 load balancing (based on protocol or port). Such techniques would also cause ICMP errors to be misdirected to the source of the data because of source address spoofing. If signaling packets are made identical in the complete 5-tuple, divergence may still occur because of the presence of router alert options. The same ICMP misdirection applies, and it becomes difficult for the end systems to distinguish between data and signaling packets. Finally, QoS routing techniques may base the routing decision on any field in the packet header (e.g., DSCP).
如果信令包的源地址和目的地址与数据包相同，则由于第4层负载平衡（基于协议或端口），信令和数据可能仍然会出现分歧。由于源地址欺骗，这种技术还会导致ICMP错误被错误地定向到数据源。如果信令包在完整的5元组中是相同的，则由于路由器警报选项的存在，仍然可能出现分歧。同样的ICMP误导也适用，终端系统很难区分数据包和信令包。最后，QoS路由技术可以基于分组报头中的任何字段（例如，DSCP）来做出路由决策。
In a connectionless network, each packet is independently routed based on its header information. Whenever a better route towards the destination becomes available, this route is installed in the forwarding table and will be used for all subsequent (data and signaling) packets. This can cause a divergence between the path along which state has been installed and the path along which forwarding will actually take place. The problem of route changes is reduced if route pinning is performed. Route pinning refers to the independence of the path taken by certain data packets from reachability changes caused by routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP). Nothing about NSIS signaling prevents route pinning from being used as a network engineering technique, provided that it is done in a way
在无连接网络中，每个数据包根据其报头信息独立路由。每当到达目的地的更好路由可用时，该路由将安装在转发表中，并将用于所有后续（数据和信令）数据包。这可能会导致安装状态的路径与实际发生转发的路径之间出现差异。如果执行路由钉扎，则路由更改问题会减少。路由钉扎是指某些数据包所采用的路径独立于内部网关协议（OSPF、IS-IS）或外部网关协议（BGP）的路由更新引起的可达性变化。NSIS信令的任何内容都不能阻止路由钉扎被用作网络工程技术，只要它是以某种方式完成的
that preserves the common routing of signaling and data. However, even if route pinning is used, it cannot be depended on to prevent all route changes (for example, in the case of link failures).
这保留了信令和数据的公共路由。但是，即使使用了路由固定，也不能依靠它来防止所有路由更改（例如，在链路故障的情况下）。
Handling route changes requires the presence of three processes in the signaling protocol:
处理路由更改需要在信令协议中存在三个过程：
1. route change detection
1. 路径变化检测
2. installation of state on the new path
2. 在新路径上安装状态
3. removal of state on the old path
3. 删除旧路径上的状态
Many route change detection methods can be used, some needing explicit protocol support, and some of which are implementation-internal. They differ in their speed of reaction and in the types of change they can detect. In rough order of increasing applicability, they can be summarized as follows:
可以使用许多路由更改检测方法，有些需要显式协议支持，有些是内部实现。它们的反应速度和检测到的变化类型各不相同。按照增加适用性的大致顺序，可概括如下：
1. monitoring changes in local forwarding table state
1. 监视本地转发表状态的更改
2. monitoring topology changes in a link-state routing protocol
2. 监视链路状态路由协议中的拓扑更改
3. inference from changes in data packet TTL
3. 从数据包TTL的变化推断
4. inference from loss of packet stream in a flow-aware router
4. 流感知路由器中分组流丢失的推断
5. inference from changes in signaling packet TTL
5. 从信令包TTL的变化推断
6. changed route of an end-to-end addressed signaling packet
6. 端到端寻址信令包的更改路由
7. changed route of a specific end-to-end addressed probe packet
7. 更改了特定端到端寻址探测数据包的路由
These methods can be categorized as being based on network monitoring (methods 1-2), on data packet monitoring (methods 3-4) and on monitoring signaling protocol messages (methods 5-7); method 6 is the baseline method of RSVP. The network monitoring methods can only detect local changes; in particular, method 1 can only detect an event that changes the immediate next downstream hop, and method 2 can only detect changes within the scope of the link-state protocol. Methods 5-7, which are contingent on monitoring signaling messages, become less effective as soft-state refresh rates are reduced.
这些方法可分为基于网络监测（方法1-2）、基于数据包监测（方法3-4）和基于监测信令协议消息（方法5-7）的方法；方法6是RSVP的基线方法。网络监控方法只能检测局部变化；具体地说，方法1只能检测改变下一个下游跳的事件，方法2只能检测链路状态协议范围内的变化。方法5-7取决于监控信令消息，随着软状态刷新率的降低，其效率降低。
When a route change has been detected, it is important that state is installed as quickly as possible along the new path. It is not guaranteed that the new path will be able to provide the same characteristics that were available on the old path. To avoid duplicate state installation or, worse, rejection of the signaling
当检测到路由更改时，必须沿新路径尽快安装状态。不能保证新路径能够提供与旧路径相同的特性。避免重复状态安装，或者更糟的是，拒绝信令
message because of previously installed state, it is important to be able to recognize the new signaling message as belonging to an existing session. In this respect, we distinguish between route changes with associated change of the flow identification (e.g., in case of a mobility event when the IP source might change) and route changes without change of the flow identification (e.g., in case of a link failure along the path). The former case requires an identifier independent from the flow identification; i.e., the session identifier (Section 4.6.2). Mobility issues are discussed in more detail in Section 5.2.
消息由于以前安装的状态，因此能够将新的信令消息识别为属于现有会话非常重要。在这方面，我们区分了具有流标识相关变化的路由变化（例如，在IP源可能变化的移动事件的情况下）和不具有流标识变化的路由变化（例如，在路径上的链路故障的情况下）。前一种情况需要独立于流标识的标识符；i、 会话标识符（第4.6.2节）。第5.2节详细讨论了机动性问题。
When state has been installed along the new path, the existing state on the old path needs to be removed. With the soft-state principle, this will happen automatically because of the lack of refresh messages. Depending on the refresh timer, however, it may be required to tear down this state much faster (e.g., because it is tied to an accounting record). In that case, the teardown message needs to be able to distinguish between the new path and the old path.
沿新路径安装状态后，需要删除旧路径上的现有状态。使用软状态原则，由于缺少刷新消息，这将自动发生。但是，根据刷新计时器的不同，可能需要更快地解除此状态（例如，因为它与会计记录关联）。在这种情况下，拆卸消息需要能够区分新路径和旧路径。
In some environments, it is desirable to provide connectivity and per-flow or per-class state management with high-availability characteristics; i.e., with rapid transparent recovery, even in the presence of route changes. This may require interactions with protocols that are used to manage the routing in this case, such as Virtual Router Redundancy Protocol (VRRP) [18].
在某些环境中，希望提供具有高可用性特征的连接性和每流或每类状态管理；i、 例如，具有快速透明恢复，即使在存在路由更改的情况下也是如此。这可能需要与在这种情况下用于管理路由的协议进行交互，例如虚拟路由器冗余协议（VRRP）[18]。
Our basic assumption about such interactions is that the NTLP would be responsible for detecting the route change and ensuring that signaling messages were re-routed consistently (in the same way as the data traffic). However, further state re-synchronization (including failover between 'main' and 'standby' nodes in the high availability case) would be the responsibility of the signaling application and its NSLP, and would possibly be triggered by the NTLP.
我们对此类交互的基本假设是，NTLP将负责检测路由变化，并确保信令消息以一致的方式重新路由（与数据流量相同）。但是，进一步的状态重新同步（包括高可用性情况下“主”节点和“备用”节点之间的故障切换）将由信令应用程序及其NSLP负责，并且可能由NTLP触发。
The issues associated with mobility and multihoming are a generalization of the basic route change case of the previous section. As well as the fact that packets for a given session are no longer traveling over a single topological path, the following extra considerations arise:
与机动性和多归宿相关的问题是上一节基本路线变更案例的概括。除了给定会话的数据包不再在单个拓扑路径上传输这一事实之外，还需要考虑以下额外因素：
1. The use of IP-layer mobility and multihoming means that more than one IP source or destination address will be associated with a single session. The same applies if application-layer solutions (e.g., SIP-based approaches) are used.
1. 使用IP层移动性和多归属意味着一个会话将关联多个IP源或目标地址。如果使用应用层解决方案（例如，基于SIP的方法），则同样适用。
2. Mobile IP and associated protocols use some special encapsulations for some segments of the data path.
2. 移动IP和相关协议对数据路径的某些部分使用一些特殊的封装。
3. The double route may persist for some time in the network (e.g., in the case of a 'make-before-break' handover being done by a multihomed host).
3. 双路由可能在网络中持续一段时间（例如，在多宿主机进行“先通后断”切换的情况下）。
4. Conversely, the re-routing may be rapid and routine (unlike network-internal route changes), increasing the importance of rapid state release on old paths.
4. 相反，重新路由可能是快速和常规的（与网络内部路由更改不同），增加了旧路径上快速状态释放的重要性。
The interactions between mobility and signaling have been extensively analyzed in recent years, primarily in the context of RSVP and Mobile IP interaction (e.g., the mobility discussion of [5]), but also in that of other types of network (e.g., [19]). A general review of the fundamental interactions is given in [20], which provides further details on many of the subjects considered in this section.
近年来，移动和信令之间的交互已被广泛分析，主要是在RSVP和移动IP交互的背景下（例如[5]的移动讨论），但也在其他类型网络的背景下（例如[19]）。[20]中给出了基本交互的一般回顾，提供了本节中考虑的许多主题的进一步细节。
We assume that the signaling will refer to 'outer' IP headers when defining the flows it is controlling. There are two main reasons for this. The first is that the data plane will usually be unable to work in terms of anything else when implementing per-flow treatment (e.g., we cannot expect that a router will analyze inner headers to decide how to schedule packets). The second reason is that we are implicitly relying on the security provided by the network infrastructure to ensure that the correct packets are given the special treatment being signaled for, and this is built on the relationship between packet source and destination addresses and network topology. (This is essentially the same approach that is used as the basis of route optimization security in Mobile IPv6 [21].) The consequence of this assumption is that we see the packet streams to (or from) different addresses as different flows. Where a flow is carried inside a tunnel, it is seen as a different flow again. The encapsulation issues (point (2) above) are therefore to be handled the same way as other tunneling cases (Section 5.4).
我们假设，在定义信令所控制的流时，信令将引用“外部”IP报头。这主要有两个原因。首先，在实现每流处理时，数据平面通常无法在任何其他方面工作（例如，我们不能期望路由器分析内部报头以决定如何调度数据包）。第二个原因是，我们隐式地依赖于网络基础设施提供的安全性，以确保正确的数据包得到信号发送的特殊处理，这是建立在数据包源地址和目标地址以及网络拓扑之间的关系之上的。（这与移动IPv6中用作路由优化安全基础的方法基本相同[21]）该假设的结果是，我们将不同地址的数据包流视为不同的流。当水流在隧道内流动时，它又被视为一种不同的水流。因此，封装问题（上文第（2）点）的处理方式与其他隧道案例（第5.4节）相同。
Therefore, the most critical aspect is that multiple flows are being used, and the signaling for them needs to be correlated. This is the intended role of the session identifier (see Section 4.6.2, which also describes some of the security requirements for such an identifier). Although the session identifier is visible at the NTLP, the signaling application is responsible for performing the correlation (and for doing so securely). The NTLP responsibility is limited to delivering the signaling messages for each flow between the correct signaling application peers. The locations at which the correlation takes place are the end system and the signaling-
因此，最关键的方面是正在使用多个流，并且需要关联它们的信令。这是会话标识符的预期角色（参见第4.6.2节，其中还描述了此类标识符的一些安全要求）。尽管会话标识符在NTLP处可见，但信令应用程序负责执行关联（并安全地执行）。NTLP的责任仅限于为正确的信令应用对等方之间的每个流传递信令消息。发生相关的位置是终端系统和信令-
application-aware node in the network where the flows meet. (This node is generally referred to as the "crossover router"; it can be anywhere in the network.)
网络中流相遇的应用程序感知节点。（该节点通常称为“交叉路由器”；它可以位于网络中的任何位置。）
Although much work has been done in the past on finding the crossover router directly from information held in particular mobility signaling protocols, the initial focus of NSIS work should be a solution that is not tightly bound to any single mobility approach. In other words, it should be possible to determine the crossover router based on NSIS signaling. (This doesn't rule out the possibility that some implementations may be able to do this discovery faster; e.g., by being tightly integrated with local mobility management protocols. This is directly comparable to spotting route changes in fixed networks by being routing aware.)
尽管过去已经做了大量工作，直接从特定移动性信令协议中保存的信息中找到交叉路由器，但NSIS工作的初始重点应该是一个不与任何单一移动性方法紧密结合的解决方案。换句话说，应该可以基于NSIS信令来确定交叉路由器。（这并不排除某些实现可以更快地完成这一发现的可能性；例如，通过与本地移动性管理协议紧密集成。这与通过路由感知发现固定网络中的路由变化有直接的可比性。）
Note that the crossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the mobile or multihomed node), which raises a latency concern. On the other hand, end-to-end signaling will have been necessary in any case, at the application level not only to communicate changed addresses, but also to update packet classifiers along the path. It is a matter for further analysis to decide how these exchanges could be combined or carried out in parallel.
注意，交叉路由器发现可能涉及端到端信令交换（特别是对于流向移动或多址节点的流），这会引起延迟问题。另一方面，端到端信令在任何情况下都是必要的，在应用层上，不仅用于通信更改的地址，而且还用于沿路径更新分组分类器。这是一个有待进一步分析的问题，以决定如何合并或并行进行这些交流。
On the shared part of the path, signaling is needed at least to update the packet classifiers to include the new flow, although if correlation with the existing flow is possible it should be possible to bypass any policy or admission control processing. State installation on the new path (and possibly release on the old one) are also required. Which entity (one of the end hosts or the crossover router) controls all these procedures depends on which entities are authorized to carry out network state manipulations, so this is therefore a matter of signaling application and NSLP design. The approach may depend on the sender/receiver orientation of the original signaling (see Section 3.3.1). In addition, in the mobility case, the old path may no longer be directly accessible to the mobile node; inter-access-router communication may be required to release state in these circumstances.
在路径的共享部分上，至少需要信令来更新分组分类器以包括新的流，尽管如果可能与现有流相关，则应该可以绕过任何策略或接纳控制处理。还需要在新路径上安装状态（可能在旧路径上发布）。哪个实体（终端主机或交叉路由器之一）控制所有这些过程取决于哪个实体有权执行网络状态操作，因此这是信令应用和NSLP设计的问题。该方法可能取决于原始信令的发送方/接收方方向（见第3.3.1节）。此外，在移动性情况下，旧路径可能不再直接可供移动节点访问；在这些情况下，可能需要接入路由器间通信来释放状态。
The frequency of handovers in some network types makes fast handover support protocols desirable, for selecting the optimal access router for handover (for example, [22]), and for transferring state information to avoid having to regenerate it in the new access router after handover (for example, [23]). Both of these procedures could have strong interactions with signaling protocols. The access router selection might depend on the network control state that could be
某些网络类型中的切换频率使得需要快速切换支持协议，用于选择用于切换的最佳接入路由器（例如，[22]），以及用于传输状态信息以避免在切换后必须在新接入路由器中重新生成状态信息（例如，[23]）。这两个过程都可能与信令协议有很强的交互作用。访问路由器的选择可能取决于可能出现的网络控制状态
supported on the path through the new access router. Transfer of signaling application state or NTLP/NSLP protocol state may be a candidate for context transfer.
在通过新访问路由器的路径上受支持。信令应用状态或NTLP/NSLP协议状态的传输可能是上下文传输的候选。
Because at least some messages will almost inevitably contain addresses and possibly higher-layer information as payload, we must consider the interaction with address translation devices (NATs). These considerations apply both to 'traditional' NATs of various types (as defined in [24]) as well as some IPv4/v6 transition mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25].
因为至少一些消息几乎不可避免地包含地址和可能更高的层信息作为有效载荷，所以我们必须考虑与地址转换设备（NAT）的交互。这些注意事项既适用于各种类型的“传统”NAT（定义见[24]），也适用于一些IPv4/v6转换机制，如无状态IP/ICMP转换（SIIT）[25]。
In the simplest case of an NSIS-unaware NAT in the path, payloads will be uncorrected, and signaling will refer to the flow incorrectly. Applications could attempt to use STUN [26] or similar techniques to detect and recover from the presence of the NAT. Even then, NSIS protocols would have to use a well-known encapsulation (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT devices.
在路径中NSIS不知道NAT的最简单情况下，有效负载将不被纠正，信令将错误地引用流。应用程序可以尝试使用STUN[26]或类似技术检测NAT并从NAT中恢复。即使如此，NSIS协议也必须使用众所周知的封装（TCP/UDP/ICMP），以避免被更谨慎的低端NAT设备丢弃。
A simple 'NSIS-aware' NAT would require flow identification information to be in the clear and not to be integrity protected. An alternative conceptual approach is to consider the NAT functionality part of message processing itself, in which case the translating node can take part natively in any NSIS protocol security mechanisms. Depending on NSIS protocol layering, it would be possible for this processing to be done in an NSIS entity that was otherwise ignorant of any particular signaling applications. This is the motivation for including basic flow identification information in the NTLP (Section 4.6.1).
一个简单的“NSIS感知”NAT将要求流标识信息是透明的，而不是完整性保护的。另一种概念性方法是考虑消息处理本身的NAT功能部分，在这种情况下，翻译节点可以在任何NSIS协议安全机制中本地参与。根据NSIS协议分层，此处理可能在不知道任何特定信令应用的NSIS实体中完成。这是在NTLP中包含基本流量标识信息的动机（第4.6.1节）。
Note that all of this discussion is independent of the use of a specific NSLP for general control of NATs (and firewalls). That case is considered in Section 6.2.
请注意，所有这些讨论都与使用特定NSLP对NAT（和防火墙）进行一般控制无关。第6.2节考虑了这种情况。
Tunneling is used in the Internet for a number of reasons, such as flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual private networking, and so on. An NSIS solution must continue to work in the presence of these techniques. The presence of the tunnel should not cause problems for end-to-end signaling, and it should also be possible to use NSIS signaling to control the treatment of the packets carrying the tunneled data.
Internet中使用隧道有很多原因，例如流聚合、IPv4/6转换机制、移动IP、虚拟专用网络等。NSIS解决方案必须在这些技术存在的情况下继续工作。隧道的存在不应导致端到端信令的问题，并且还应该可以使用NSIS信令来控制对承载隧道数据的分组的处理。
It is assumed that the NSIS approach will be similar to that of [27], where the signaling for the end-to-end data flow is tunneled along with that data flow and is invisible to nodes along the path of the tunnel (other than the endpoints). This provides backwards compatibility with networks where the tunnel endpoints do not support the NSIS protocols. We assume that NEs will not unwrap tunnel encapsulations to find and process tunneled signaling messages.
假设NSIS方法类似于[27]，其中端到端数据流的信令与该数据流一起被隧道化，并且对隧道路径上的节点（端点除外）不可见。这提供了与隧道端点不支持NSIS协议的网络的向后兼容性。我们假设网元不会打开隧道封装来查找和处理隧道信令消息。
To signal for the packets carrying the tunneled data, the tunnel is considered a new data flow in its own right, and NSIS signaling is applied to it recursively. This requires signaling support in at least one tunnel endpoint. In some cases (where the signaling initiator is at the opposite end of the data flow from the tunnel initiator; i.e., in the case of receiver initiated signaling), the ability to provide a binding between the original flow identification and that for the tunneled flow is needed. It is left open here whether this should be an NTLP or an NSLP function.
为了给携带隧道数据的数据包发送信号，隧道本身被视为一个新的数据流，NSIS信号被递归地应用于它。这需要在至少一个隧道端点中提供信令支持。在某些情况下（其中信令启动器位于来自隧道启动器的数据流的另一端；即，在接收器发起信令的情况下），需要在原始流标识和隧道流标识之间提供绑定的能力。这是一个NTLP函数还是一个NSLP函数，在这里都是开放的。
This section gives an overview of NSLPs for particular signaling applications. The assumption is that the NSLP uses the generic functionality of the NTLP given earlier; this section describes specific aspects of NSLP operation. It includes simple examples that are intended to clarify how NSLPs fit into the framework. It does not replace or even form part of the formal NSLP protocol specifications; in particular, initial designs are being developed for NSLPs for resource reservation [28] and middlebox communication [29].
本节概述了特定信令应用的NSLP。假设NSLP使用前面给出的NTLP的通用功能；本节介绍NSLP操作的具体方面。其中包括旨在阐明NSLP如何融入框架的简单示例。它不取代或甚至不构成正式NSLP协议规范的一部分；特别是，正在为NSLP开发用于资源保留[28]和中间箱通信[29]的初始设计。
In the case of signaling for QoS, all the basic NSIS concepts of Section 3.1 apply. In addition, there is an assumed directionality of the signaling process, in that one end of the signaling flow takes responsibility for actually requesting the resource. This leads to the following definitions:
对于QoS信令，第3.1节的所有基本NSIS概念均适用。此外，存在信令过程的假定方向性，其中信令流的一端负责实际请求资源。这导致了以下定义：
o QoS NSIS Initiator (QNI): the signaling entity that makes the resource request, usually as a result of user application request.
o QoS NSIS启动器（QNI）：发出资源请求的信令实体，通常是用户应用程序请求的结果。
o QoS NSIS Responder (QNR): the signaling entity that acts as the endpoint for the signaling and that can optionally interact with applications as well.
o QoS NSIS Responder（QNR）：作为信令端点的信令实体，也可以选择与应用程序交互。
o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR that propagates NSIS signaling further through the network.
o QoS NSIS转发器（QNF）：QNI和QNR之间的信令实体，通过网络进一步传播NSIS信令。
Each of these entities will interact with a resource management function (RMF) that actually allocates network resources (router buffers, interface bandwidth, and so on).
这些实体中的每一个都将与实际分配网络资源（路由器缓冲区、接口带宽等）的资源管理功能（RMF）交互。
Note that there is no constraint on which end of the signaling flow should take the QNI role: With respect to the data flow direction, it could be at the sending or receiving end.
请注意，对于信令流的哪一端应该扮演QNI角色没有任何限制：关于数据流方向，它可能在发送端或接收端。
The QoS NSLP will include a set of messages to carry out resource reservations along the signaling path. A possible set of message semantics for the QoS NSLP is shown below. Note that the 'direction' column in the table below only indicates the 'orientation' of the message. Messages can be originated and absorbed at QNF nodes as well as the QNI or QNR; an example might be QNFs at the edge of a domain exchanging messages to set up resources for a flow across a it. Note that it is left open if the responder can release or modify a reservation, during or after setup. This seems mainly a matter of assumptions about authorization, and the possibilities might depend on resource type specifics.
QoS NSLP将包括一组消息，以沿信令路径执行资源预留。QoS NSLP的一组可能的消息语义如下所示。请注意，下表中的“方向”列仅表示消息的“方向”。消息可以在QNF节点以及QNI或QNR上发起和吸收；一个例子可能是位于域边缘的QNFs，它通过交换消息来为it上的流设置资源。请注意，如果响应者可以在设置期间或之后释放或修改保留，则它将保持打开状态。这似乎主要是关于授权的假设问题，其可能性可能取决于资源类型的具体情况。
The table also explicitly includes a refresh operation. This does nothing to a reservation except extend its lifetime, and it is one possible state management mechanism (see next section).
该表还显式包含刷新操作。除了延长保留的生命周期之外，这对保留没有任何影响，而且这是一种可能的状态管理机制（请参阅下一节）。
+-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow |
| | | |
| Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | |
| | | |
| Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation |
| | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request |
| | | |
| Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
| | | |
| Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+
+-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow |
| | | |
| Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | |
| | | |
| Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation |
| | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request |
| | | |
| Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
| | | |
| Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+
The primary purpose of NSIS is to manage state information along the path taken by a data flow. The issues regarding state management within the NTLP (state related to message transport) are described in Section 4. The QoS NSLP will typically have to handle additional state related to the desired resource reservation to be made.
NSIS的主要目的是沿着数据流所采用的路径管理状态信息。第4节描述了NTLP（与消息传输相关的状态）内的状态管理问题。QoS NSLP通常必须处理与所需资源预留相关的附加状态。
There two critical issues to be considered in building a robust NSLP to handle this problem:
在建立一个稳健的NSLP以处理此问题时，需要考虑两个关键问题：
o The protocol must be scalable. It should allow minimization of the resource reservation state-storage demands that it implies for intermediate nodes; in particular, storage of state per 'micro' flow is likely to be impossible except at the very edge of the network. A QoS signaling application might require per-flow or lower granularity state; examples of each for the case of QoS would be IntServ [30] or RMD [31] (per 'class' state), respectively.
o 协议必须是可伸缩的。它应该允许最小化对中间节点的资源保留状态存储需求；特别是，每个“微”流的状态存储可能是不可能的，除非在网络的最边缘。QoS信令应用程序可能需要每个流或较低粒度的状态；在QoS的情况下，每个示例分别是IntServ[30]或RMD[31]（每个“类”状态）。
o The protocol must be robust against failure and other conditions that imply that the stored resource reservation state has to be moved or removed.
o 协议必须能够抵抗故障和其他意味着必须移动或删除存储资源保留状态的情况。
For resource reservations, soft-state management is typically used as a general robustness mechanism. According to the discussion of Section 3.2.5, the soft-state protocol mechanisms are built into the NSLP for the specific signaling application that needs them; the NTLP sees this simply as a sequence of (presumably identical) messages.
对于资源预留，软状态管理通常用作一般健壮性机制。根据第3.2.5节的讨论，NSLP中内置了软状态协议机制，用于需要它们的特定信令应用；NTLP将此简单地视为一系列（可能相同的）消息。
In this section, we will explore the expected interaction between resource signaling and routing updates (the precise source of routing updates does not matter). The normal operation of the NSIS protocol will lead to the situation depicted in Figure 7, where the reserved resources match the data path.
在本节中，我们将探讨资源信令和路由更新之间的预期交互（路由更新的确切来源并不重要）。NSIS协议的正常操作将导致图7所示的情况，其中保留的资源与数据路径匹配。
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
--------------------------------------->
data path
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
--------------------------------------->
data path
Figure 7: Normal NSIS Protocol Operation
图7：正常NSIS协议操作
A route change can occur while such a reservation is in place. The route change will be installed immediately, and any data will be forwarded on the new path. This situation is depicted Figure 8.
当预订到位时，可能会发生路线变更。路由更改将立即安装，任何数据都将在新路径上转发。这种情况如图8所示。
Resource reservation on the new path will only be started once the next control message is routed along the new path. This means that there is a certain time interval during which resources are not reserved on (part of) the data path, and certain delay or drop-sensitive applications will require that this time interval be minimized. Several techniques to achieve this could be considered. As an example, RSVP [7] has the concept of local repair, whereby the router may be triggered by a route change. In that case, the RSVP node can start sending PATH messages directly after the route has been changed. Note that this option may not be available if no per-flow state is kept in the QNF. Another approach would be to pre-install backup state, and it would be the responsibility of the QoS-NSLP to do this. However, mechanisms for identifying backup paths and routing the necessary signaling messages along them are not currently considered in the NSIS requirements and framework.
只有在沿新路径路由下一条控制消息后，才会启动新路径上的资源保留。这意味着有一个特定的时间间隔，在此期间，数据路径（部分）上没有保留资源，并且某些延迟或丢包敏感的应用程序将要求最小化此时间间隔。可以考虑几种实现这一点的技术。例如，RSVP[7]具有本地修复的概念，由此路由器可由路由改变触发。在这种情况下，RSVP节点可以在路由更改后直接开始发送路径消息。请注意，如果QNF中未保留每流状态，则此选项可能不可用。另一种方法是预安装备份状态，QoS NSLP有责任这样做。然而，NSIS需求和框架中目前没有考虑用于识别备份路径和沿其路由必要信令消息的机制。
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Figure 8: Route Change
图8：路线变更
The new path might not be able to provide the same guarantees that were available on the old path. Therefore, it might be desirable for the QNF to wait until resources have been reserved on the new path before allowing the route change to be installed (unless, of course, the old path no longer exists). However, delaying the route change installation while waiting for reservation setup needs careful analysis of the interaction with the routing protocol being used, in order to avoid routing loops.
新路径可能无法提供与旧路径相同的保证。因此，在允许安装路由更改之前，QNF可能需要等待新路径上的资源被保留（当然，除非旧路径不再存在）。但是，在等待预留设置时延迟路由更改安装需要仔细分析与正在使用的路由协议的交互，以避免路由循环。
Another example related to route changes is denoted as severe congestion and is explained in [31]. This solution adapts to a route change when a route change creates congestion on the new routed path.
另一个与路线变化相关的示例表示为严重拥挤，并在[31]中进行了解释。当路由更改在新路由路径上造成拥塞时，此解决方案适应路由更改。
The QoS NSLP itself is not involved in any specific resource allocation or management techniques. The definition of an NSLP for resource reservation with Quality of Service, however, implies the notion of admission control. For a QoS NSLP, the measure of signaling success will be the ability to reserve resources from the total resource pool that is provisioned in the network. We define the function responsible for allocating this resource pool as the Resource Management Function (RMF). The RMF is responsible for all resource provisioning, monitoring, and assurance functions in the network.
QoS NSLP本身不涉及任何特定的资源分配或管理技术。然而，对于具有服务质量的资源预留，NSLP的定义隐含了准入控制的概念。对于QoS NSLP，信令成功的度量将是从网络中提供的总资源池中保留资源的能力。我们将负责分配此资源池的功能定义为资源管理功能（RMF）。RMF负责网络中的所有资源供应、监控和保证功能。
A QoS NSLP will rely on the RMF to do resource management and to provide inputs for admission control. In this model, the RMF acts as a server towards client NSLP(s). Note, however, that the RMF may in turn use another NSLP instance to do the actual resource provisioning in the network. In this case, the RMF acts as the initiator (client) of an NSLP.
QoS NSLP将依赖RMF进行资源管理，并为准入控制提供输入。在此模型中，RMF充当面向客户端NSLP的服务器。然而，请注意，RMF可以反过来使用另一个NSLP实例来执行网络中的实际资源供应。在这种情况下，RMF充当NSLP的发起方（客户端）。
This essentially corresponds to a multi-level signaling paradigm, with an 'upper' level handling internetworking QoS signaling (possibly running end-to-end), and a 'lower' level handling the more specialized intra-domain QoS signaling (running between just the edges of the network). (See [10], [32], and [33] for a discussion of similar architectures.) Given that NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow and limited scope (e.g., edge-to-edge) operation, it is not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP.
这基本上对应于多级信令范式，具有“上层”处理网络间QoS信令（可能运行端到端），以及“下层”处理更专业的域内QoS信令（仅在网络边缘之间运行）。（关于类似架构的讨论，请参见[10]、[32]和[33]）鉴于NSIS信令已经被认为能够支持给定流和有限范围（例如，边到边）操作的多个NSLP实例，目前尚不清楚支持多级模型是否会导致QoS NSLP的任何新协议要求。
The RMF may or may not be co-located with a QNF (note that co-location with a QNI/QNR can be handled logically as a combination between QNF and QNI/QNR). To cater for both cases, we define a (possibly logical) QNF-RMF interface. Over this interface, information may be provided from the RMF about monitoring, resource availability, topology, and configuration. In the other direction, the interface may be used to trigger requests for resource provisioning. One way to formalize the interface between the QNF and the RMF is via a Service Level Agreement (SLA). The SLA may be static or it may be dynamically updated by means of a negotiation protocol. Such a protocol is outside the scope of NSIS.
RMF可能与QNF共存，也可能不与QNF共存（请注意，与QNI/QNR共存可以作为QNF和QNI/QNR的组合进行逻辑处理）。为了满足这两种情况，我们定义了一个（可能是逻辑的）QNF-RMF接口。通过该接口，可以从RMF提供有关监视、资源可用性、拓扑和配置的信息。在另一个方向，该接口可用于触发资源供应请求。形式化QNF和RMF之间接口的一种方法是通过服务级别协议（SLA）。SLA可以是静态的，也可以通过协商协议动态更新。这种协议不在NSIS的范围之内。
There is no assumed restriction on the placement of the RMF. It may be a centralized RMF per domain, several off-path distributed RMFs, or an on-path RMF per router. The advantages and disadvantages of both approaches are well-known. Centralization typically allows decisions to be taken using more global information, with more
对RMF的放置没有假定的限制。它可以是每个域的集中式RMF、多个非路径分布式RMF或每个路由器的路径上RMF。这两种方法的优缺点是众所周知的。集中化通常允许使用更多的全局信息以及更多的
efficient resource utilization as a result. It also facilitates deployment or upgrade of policies. Distribution allows local decision processes and rapid response to data path changes.
因此，高效的资源利用率。它还便于策略的部署或升级。分布允许本地决策过程和对数据路径更改的快速响应。
As well as the use for 'traditional' QoS signaling, it should be possible to develop NSLPs for other signaling applications that operate on different types of network control state. One specific case is setting up flow-related state in middleboxes (firewalls, NATs, and so on). Requirements for such communication are given in [4]. Other examples include network monitoring and testing, and tunnel endpoint discovery.
除了使用“传统”QoS信令外，还可以为在不同类型的网络控制状态下运行的其他信令应用程序开发NSLP。一个具体的例子是在中间盒（防火墙、NAT等）中设置与流相关的状态。[4]中给出了此类通信的要求。其他示例包括网络监视和测试以及隧道端点发现。
This document describes a framework for signaling protocols that assumes a two-layer decomposition, with a common lower layer (NTLP) supporting a family of signaling-application-specific upper-layer protocols (NSLPs). The overall security considerations for the signaling therefore depend on the joint security properties assumed or demanded for each layer.
本文档描述了一个信令协议框架，该框架采用两层分解，其中公共下层（NTLP）支持一系列信令应用程序特定上层协议（NSLP）。因此，信令的总体安全考虑因素取决于为每一层假定或要求的联合安全特性。
Security for the NTLP is discussed in Section 4.7. We have assumed that, apart from being resistant to denial of service attacks against itself, the main role of the NTLP will be to provide message protection over the scope of a single peer relationship, between adjacent signaling application entities. (See Section 3.2.3 for a discussion of the case where these entities are separated by more than one NTLP hop.) These functions can ideally be provided by an existing channel security mechanism, preferably using an external key management mechanism based on mutual authentication. Examples of possible mechanisms are TLS, IPsec and SSH. However, there are interactions between the actual choice of security protocol and the rest of the NTLP design. Primarily, most existing channel security mechanisms require explicit identification of the peers involved at the network and/or transport level. This conflicts with those aspects of path-coupled signaling operation (e.g., discovery) where this information is not even implicitly available because peer identities are unknown; the impact of this 'next-hop problem' on RSVP design is discussed in the security properties document [6] and also influences many parts of the threat analysis [2]. Therefore, this framework does not mandate the use of any specific channel security protocol; instead, this has to be integrated with the design of the NTLP as a whole.
第4.7节讨论了NTLP的安全性。我们假设，除了抵抗针对自身的拒绝服务攻击外，NTLP的主要作用是在相邻信令应用实体之间的单个对等关系范围内提供消息保护。（有关这些实体被多个NTLP跃点分隔的情况的讨论，请参见第3.2.3节。）理想情况下，这些功能可以由现有的信道安全机制提供，最好使用基于相互认证的外部密钥管理机制。可能的机制有TLS、IPsec和SSH。然而，安全协议的实际选择与NTLP设计的其余部分之间存在交互作用。主要地，大多数现有的信道安全机制需要明确标识网络和/或传输级别上涉及的对等方。这与路径耦合信令操作（例如，发现）的那些方面相冲突，其中，由于对等身份未知，该信息甚至不隐式可用；“下一跳问题”对RSVP设计的影响在安全属性文档[6]中进行了讨论，也影响了威胁分析的许多部分[2]。因此，该框架不强制使用任何特定的通道安全协议；相反，这必须与NTLP的整体设计相结合。
Security for the NSLPs is entirely dependent on signaling application requirements. In some cases, no additional protection may be required compared to what is provided by the NTLP. In other cases, more sophisticated object-level protection and the use of public-key-based solutions may be required. In addition, the NSLP needs to consider the authorization requirements of the signaling application. Authorization is a complex topic, for which a very brief overview is provided in Section 3.3.7.
NSLP的安全性完全取决于信令应用要求。在某些情况下，与NTLP提供的保护相比，可能不需要额外的保护。在其他情况下，可能需要更复杂的对象级保护和使用基于公钥的解决方案。此外，NSLP需要考虑信令应用的授权要求。授权是一个复杂的主题，第3.3.7节对此进行了简要概述。
Another factor is that NTLP security mechanisms operate only locally, whereas NSLP mechanisms may also need to operate over larger regions (not just between adjacent peers), especially for authorization aspects. This complicates the analysis of basing signaling application security on NTLP protection.
另一个因素是NTLP安全机制仅在本地运行，而NSLP机制可能还需要在更大的区域（而不仅仅是在相邻对等方之间）上运行，特别是在授权方面。这使得基于NTLP保护的信令应用程序安全性分析变得复杂。
An additional concern for signaling applications is the session identifier security issue (Sections 4.6.2 and 5.2). The purpose of this identifier is to decouple session identification (as a handle for network control state) from session "location" (i.e., the data flow endpoints). The identifier/locator distinction has been extensively discussed in the user plane for end-to-end data flows, and is known to lead to non-trivial security issues in binding the two together again. Our problem is the analogue in the control plane, and is at least similarly complex, because of the need to involve nodes in the interior of the network as well.
信令应用程序的另一个问题是会话标识符安全问题（第4.6.2和5.2节）。该标识符的目的是将会话标识（作为网络控制状态的句柄）与会话“位置”（即数据流端点）解耦。标识符/定位器的区别已经在端到端数据流的用户平面中进行了广泛的讨论，并且已知在将两者再次绑定在一起时会导致非平凡的安全问题。我们的问题是控制平面中的模拟，并且至少类似地复杂，因为还需要涉及网络内部的节点。
Further work on this and other security design will depend on a refinement of the NSIS threats work begun in [2].
关于此和其他安全设计的进一步工作将取决于[2]中开始的NSIS威胁工作的改进。
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[1] Brunner，M.，“信令协议的要求”，RFC 3726，2004年4月。
[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[2] Tschofenig，H.和D.Kroeselberg，“信号下一步的安全威胁（NSIS）”，RFC 40812005年6月。
[3] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003.
[3] Chaskar，H.，“移动IP服务质量（QoS）解决方案的要求”，RFC 3583，2003年9月。
[4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[4] R.斯瓦尔、P.马特、P.斯吉本、S.布里姆和M.肖尔，“中间箱通信（midcom）协议要求”，RFC 33042002年8月。
[5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service Signaling Protocols", Work in Progress, December 2004.
[5] J.和X.Fu，“现有服务质量信令协议分析”，正在进行的工作，2004年12月。
[6] Tschofenig, H., "RSVP Security Properties", Work in Progress, February 2005.
[6] Tschofenig，H.，“RSVP安全属性”，正在进行的工作，2005年2月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[8] Katz，D.，“IP路由器警报选项”，RFC 2113，1997年2月。
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[9] 帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[10] Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[11] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[12] Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
[12] Tschofenig，H.，“NSIS认证、授权和会计问题”，正在进行的工作，2003年3月。
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[13] Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of Hard-State and Soft-State Signaling Protocols", Computer Communication Review, Volume 33, Number 4, October 2003.
[14] Ji，P.，Ge，Z.，Kurose，J.，和D.Townsley，“硬态和软态信令协议的比较”，《计算机通信评论》，第33卷，第4期，2003年10月。
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[15] Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, A., and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999.
[16] Apostolopoulos，G.，Kamat，S.，Williams，D.，Guerin，R.，Orda，A.，和T.Przygienda，“QoS路由机制和OSPF扩展”，RFC 26761999年8月。
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[17] Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 29912000年11月。
[18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[18] Hinden，R.，“虚拟路由器冗余协议（VRRP）”，RFC 3768，2004年4月。
[19] Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg, "DiffServ Resource Management in IP-based Radio Access Networks", Proceedings of 4th International Symposium on Wireless Personal Multimedia Communications WPMC'01, September 9 - 12 2001.
[19] Heijenk，G.，Karagiannis，G.，Rexepi，V.，和L.Westberg，“基于IP的无线接入网络中的区分服务资源管理”，第四届无线个人多媒体通信国际研讨会论文集WPMC'01，2001年9月9日至12日。
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E., and Y. Khouaja, "Evaluation of Mobility and QoS Interaction", Computer Networks Volume 38, Issue 2, p. 137-163, 5 February 2002.
[20] Way，J.，Lopez，A.，Mihailovic，A.，Velayos，H.，Hepworth，E.，和Y.Khouaja，“移动性和QoS交互的评估”，计算机网络卷38，第2期，第页。137-163，2002年2月5日。
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[21] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", Work in Progress, May 2005.
[22] Liebsch，M.，Ed.，Singh，A.，Ed.，Chaskar，H.，Funato，D.，和E.Shim，“候选接入路由器发现（卡）”，正在进行的工作，2005年5月。
[23] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[23] Kempf，J.，“问题描述：在IP接入网络中的节点之间执行上下文传输的原因”，RFC 3374，2002年9月。
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[24] Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[25] Nordmark，E.，“无状态IP/ICMP转换算法（SIIT）”，RFC 27652000年2月。
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[26] Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[27] Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[28] Bosch，S.，Karagiannis，G.，和A.McDonald，“服务质量信号NSLP”，正在进行的工作，2005年2月。
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.
[29] “NAT/防火墙NSIS信令层协议（NSLP）”，正在进行的工作，2005年2月。
[30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[30] Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs, "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", Seventh International Workshop on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April 2002.
[31] Westberg，L.，Csaszar，A.，Karagiannis，G.，Marquetant，A.，Partain，D.，Pop，O.，Rexepi，V.，Szabo，R.，和A.Takacs，“区分服务中的资源管理（RMD）：功能和性能行为概述”，第七届高速网络协议国际研讨会PfHSN 2002，2002年4月22-24日。
[32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-072, November 1992.
[32] Ferrari，D.，Banerjea，A.，和H.Zhang，“多媒体网络支持——特尼特方法的讨论”，伯克利TR-92-0721992年11月。
[33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[33] Nichols，K.，Jacobson，V.，和L.Zhang，“互联网的两位差异化服务架构”，RFC 2638，1999年7月。
Several parts of the introductory sections of this document (in particular, in Sections 3.1 and 3.3) are based on contributions from Ilya Freytsis, then of Cetacean Networks, Inc.
本文件导言部分的几个部分（特别是第3.1节和第3.3节）以当时Cetacean Networks，Inc.的Ilya Freytsis的贡献为基础。
Bob Braden originally proposed "A Two-Level Architecture for Internet Signalling" as an Internet-Draft in November 2001. This document served as an important starting point for the framework discussed herein, and the authors owe a debt of gratitude to Bob for this proposal.
Bob Braden最初在2001年11月提出了“互联网信令的两级架构”作为互联网草案。本文件是本文讨论的框架的一个重要起点，作者对Bob的这一提议表示感谢。
The authors would like to thank Bob Braden, Maarten Buchli, Eleanor Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for significant contributions in particular areas of this document. In addition, the authors would like to acknowledge Cedric Aoun, Attila Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler, Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, and Lixia Zhang for insights and inputs during this and previous framework activities. Dave Oran, Michael Richardson, and Alex Zinin provided valuable comments during the final review stages.
作者要感谢Bob Braden、Maarten Buchli、Eleanor Hepworth、Andrew McDonald、Melinda Shore和Hannes Tschofenig在本文件特定领域的重要贡献。此外，作者还要感谢塞德里克·奥恩、阿提拉·贝德、安德斯·伯格斯滕、罗兰·布莱斯、马库斯·布伦纳、路易斯·伯恩斯、傅晓明、鲁迪格·盖布、丹尼·戈德里斯、金辉、科妮莉亚·卡普勒、宋希丘·李、陈特拉鲁、麦克·麦克蒂芬、保罗·门德斯、汉斯·德内韦、潘平、大卫·帕坦、弗拉·雷切皮、亨宁·舒尔兹林、，Tom Taylor、Michael Thomas、Daniel Warren、Michael Welzl、Lars Westberg和Lixia Zhang在本次和之前的框架活动中提供见解和投入。Dave Oran、Michael Richardson和Alex Zinin在最终审查阶段提供了宝贵的意见。
Authors' Addresses
作者地址
Robert Hancock Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
Robert Hancock西门子/Roke Manor Research Old Salisbury Lane Romsey，英国汉普郡SO51 0ZN
EMail: robert.hancock@roke.co.uk
EMail: robert.hancock@roke.co.uk
Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands
乔治斯·卡拉吉安尼斯屯特大学邮政信箱217 7500 AE恩斯赫德荷兰
EMail: g.karagiannis@ewi.utwente.nl
EMail: g.karagiannis@ewi.utwente.nl
John Loughney Nokia Research Center 11-13 Itamerenkatu Helsinki 00180 Finland
John Loughney诺基亚研究中心11-13芬兰赫尔辛基伊塔梅伦卡图00180
EMail: john.loughney@nokia.com
EMail: john.loughney@nokia.com
Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium
Sven Van den Bosch Alcatel Francis Welleslein 1 B-2018比利时安特卫普
EMail: sven.van_den_bosch@alcatel.be
EMail: sven.van_den_bosch@alcatel.be
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。