Network Working Group F. Baker
Request for Comments: 4923 Cisco Systems
Category: Informational P. Bose
Lockheed Martin
August 2007
Network Working Group F. Baker
Request for Comments: 4923 Cisco Systems
Category: Informational P. Bose
Lockheed Martin
August 2007
Quality of Service (QoS) Signaling in a Nested Virtual Private Network
嵌套虚拟专用网络中的服务质量（QoS）信令
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998.
一些网络需要在虚拟专用网（VPN）的内部和外部部分之间进行通信，或通过此类网络的串联实现嵌套VPN，但对跨边界传输的信息具有敏感性，特别是在为不同优先级的通信提供服务质量时。本说明旨在概述基于RFC 2998中所述Diffserv网络上综合业务运营框架的拟议解决方案的问题和性质。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Background Information and Terminology .....................4
1.3. Nested VPNs ................................................5
1.4. Signaled QoS Technology ....................................7
1.5. The Resource Reservation Protocol (RSVP) ...................9
1.6. Logical Structure of a VPN Router .........................10
2. Reservation and Preemption in a Nested VPN .....................13
2.1. Reservation in a Nested VPN ...............................14
2.2. Preemption in a Nested VPN ................................16
2.3. Working through an Example ................................17
2.3.1. Initial Routine Reservations - Generating
Network State ......................................18
2.3.2. Initial Routine Reservations - Request
Reservation ........................................19
2.3.3. Installation of a Reservation Using Precedence .....20
2.3.4. Installation of a Reservation Using Preemption .....21
3. Data Flows within a VPN Router .................................24
3.1. VPN Routers That Carry Data across the
Cryptographic Boundary ....................................24
3.1.1. Plaintext to Ciphertext Data Flows .................24
3.1.2. Ciphertext to Plaintext Data Flows .................27
3.2. VPN Routers That Use the Network Guard for
Signaling across the Cryptographic Boundary ...............28
3.2.1. Signaling Flow .....................................29
3.2.2. Use Case with Network Guard ........................30
4. Security Considerations ........................................33
5. Acknowledgements ...............................................34
6. References .....................................................34
6.1. Normative References ......................................34
6.2. Informative References ....................................35
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Background Information and Terminology .....................4
1.3. Nested VPNs ................................................5
1.4. Signaled QoS Technology ....................................7
1.5. The Resource Reservation Protocol (RSVP) ...................9
1.6. Logical Structure of a VPN Router .........................10
2. Reservation and Preemption in a Nested VPN .....................13
2.1. Reservation in a Nested VPN ...............................14
2.2. Preemption in a Nested VPN ................................16
2.3. Working through an Example ................................17
2.3.1. Initial Routine Reservations - Generating
Network State ......................................18
2.3.2. Initial Routine Reservations - Request
Reservation ........................................19
2.3.3. Installation of a Reservation Using Precedence .....20
2.3.4. Installation of a Reservation Using Preemption .....21
3. Data Flows within a VPN Router .................................24
3.1. VPN Routers That Carry Data across the
Cryptographic Boundary ....................................24
3.1.1. Plaintext to Ciphertext Data Flows .................24
3.1.2. Ciphertext to Plaintext Data Flows .................27
3.2. VPN Routers That Use the Network Guard for
Signaling across the Cryptographic Boundary ...............28
3.2.1. Signaling Flow .....................................29
3.2.2. Use Case with Network Guard ........................30
4. Security Considerations ........................................33
5. Acknowledgements ...............................................34
6. References .....................................................34
6.1. Normative References ......................................34
6.2. Informative References ....................................35
More and more networks wish to guarantee secure transmission of IP traffic across public LANs or WANs and therefore use Virtual Private Networks. Some networks require communication between an interior and exterior portion of a VPN or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions. The outline of the QoS solution for real-time traffic has been described at a high level in [RFC4542]. The key characteristics of this proposal are that
越来越多的网络希望保证IP流量在公共LAN或WAN之间的安全传输，因此使用虚拟专用网络。一些网络需要VPN内部和外部部分之间的通信，或者通过此类网络的串联来实现嵌套VPN，但是对于跨边界传输的信息具有敏感性，特别是在为具有不同优先级的通信提供服务质量时。本说明旨在概述拟议解决办法的问题和性质。[RFC4542]中对实时流量的QoS解决方案进行了详细描述。这项建议的主要特点是：
o it uses standardized protocols,
o 它使用标准化的协议，
o it includes reservation setup and teardown for guaranteed and controlled load services using the standardized protocols,
o 它包括使用标准化协议为保证和控制负载服务设置预留和拆卸，
o it is independent of link delay, and therefore consistent with high delay*bandwidth networks as well as the more common variety,
o 它独立于链路延迟，因此与高延迟*带宽网络以及更常见的种类一致，
o it has no single point of failure, such as a central reservation manager,
o 它没有单点故障，例如中央预订管理器，
o it provides for the preemption of established data flows,
o 它提供了对已建立数据流的抢占，
o in that preemption, it not only permits a policy-admitted data flow in, but selects a specific data flow to exclude based upon control input rather than simply accepting a loss of service dictated at the discretion of the network control function, and
o 在该抢占中，它不仅允许策略允许的数据流进入，而且基于控制输入选择要排除的特定数据流，而不是简单地接受由网络控制功能决定的服务丢失，以及
o it interoperates directly with SIP Proxies, H.323 Gatekeepers, or other call management subsystems to present the other services required in a preemptive or preferential telephone network.
o 它直接与SIP代理、H.323网关守卫或其他呼叫管理子系统进行互操作，以提供抢占或优先电话网络中所需的其他服务。
The thrust of the memo surrounds VPNs that use encryption in some form, such as IPsec and their subsequent nesting across multiple network domains. This specific type of VPNs is further clarified in Section 1.3, which describes the nested VPN as an example of an IPsec or IPsec like VPN under the context of a 'customer provisioned' VPN. As a result, we will discuss the VPN router supporting "plaintext" and "ciphertext" interfaces. However, the concept extends readily to any form of aggregation, including the concept proposed in [RFC3175] of the IP traffic entering and leaving a network at identified
备忘录的重点围绕以某种形式使用加密的VPN，如IPsec及其后续跨多个网络域的嵌套。第1.3节进一步阐明了这种特定类型的VPN，该节将嵌套VPN描述为“客户配置”VPN上下文下的IPsec或类似IPsec的VPN示例。因此，我们将讨论支持“明文”和“密文”接口的VPN路由器。然而，该概念很容易扩展到任何形式的聚合，包括[RFC3175]中提出的在确定的时间点进出网络的IP流量的概念
points, and the use of other kinds of tunnels including Generic Routing Encapsulation (GRE), IP/IP, MPLS, and so on.
以及使用其他类型的隧道，包括通用路由封装（GRE）、IP/IP、MPLS等。
A note on the use of the words "priority" and "precedence" in this document is in order. The term "priority" has been used in this context with a variety of meanings, resulting in a great deal of confusion. The term "priority" is used in this document to identify one of several possible datagram scheduling algorithms. A scheduler is used when deciding which datagram will be sent next on a computer interface; a priority scheduler always chooses a datagram from the highest priority class (queue) that is occupied, shielding one class of traffic from most of the jitter by passing jitter it would otherwise have experienced to another class. [RFC3181] applies the term to a reservation, in a sense that this document will refer to as "precedence". The term "precedence" is used in the sense implied in the phrase "Multi-Level Precedence and Preemption" [ITU.MLPP.1990]; some classes of sessions take precedence over others, which may result in bandwidth being admitted that might not otherwise have been or may result in the prejudicial termination of a lower-precedence session under a stated set of circumstances. For the purposes of the present discussion, "priority" is a set of algorithms applied to datagrams, where "precedence" is a policy attribute of sessions. The techniques of priority comparisons are used in a router or a policy decision point to implement precedence, but they are not the same thing.
关于本文件中“优先权”和“优先权”两个词的用法，请注意顺序。“优先权”一词在这一上下文中有各种含义，造成了大量的混乱。本文件中使用术语“优先级”来确定几种可能的数据报调度算法之一。调度器用于决定下一步在计算机接口上发送哪个数据报；优先级调度器总是从被占用的最高优先级类别（队列）中选择数据报，通过将抖动传递给另一个类别，从而屏蔽一个类别的流量，使其免受大部分抖动的影响。[RFC3181]将该术语应用于保留，在某种意义上，本文件称之为“优先权”。“优先权”一词的含义为“多级优先权和优先权”[ITU.MLPP.1990]；某些类别的会话优先于其他类别的会话，这可能会导致带宽被接纳，否则可能不会被接纳，或者可能会导致在一组规定的情况下，低优先级会话的不利终止。在本讨论中，“优先级”是一组应用于数据报的算法，其中“优先级”是会话的策略属性。优先级比较技术用于路由器或策略决策点来实现优先级，但它们不是一回事。
Along the same lines, it is important for the reader to understand the difference between QoS policies and policies based on the "precedence" or "importance" of data to the person or function using it. Voice, regardless of the precedence level of the call, is impeded by high levels of variation in network-induced delay. As a result, voice is often serviced using a priority queue, transferring jitter from that application's traffic to other applications. This is as true of voice for routine calls as it is for flash traffic. There are classes of application traffic that require bounded delay. That is a different concept than "no jitter"; they can accept jitter within stated bounds. Routing protocols such as OSPF or BGP are critical to the correct functioning of network infrastructure. While they are designed to work well with moderate loss levels, they are not helped by them, and even a short period of high loss can result in dramatic network events. Variation in delay, however, is not at all an issue if it is within reasonable bounds. As a result, it is common for routers to treat routing protocol datagrams in a way that limits the probability of loss, accepting relatively high delay in some cases, even though the traffic is absolutely critical to the network. Telephone call setup exchanges have this characteristic as
同样，读者理解QoS策略和基于数据对使用QoS的人员或功能的“优先级”或“重要性”的策略之间的区别也很重要。无论呼叫的优先级如何，语音都会受到网络诱导延迟的高度变化的阻碍。因此，语音通常使用优先级队列进行服务，将抖动从该应用程序的流量传输到其他应用程序。这对于日常通话的语音来说是真实的，对于闪存通信也是如此。有几类应用程序流量需要有界延迟。这是一个不同于“无抖动”的概念；他们可以接受规定范围内的抖动。OSPF或BGP等路由协议对于网络基础设施的正确运行至关重要。虽然它们被设计为在中等损失水平下运行良好，但它们并没有得到帮助，即使短时间的高损失也可能导致戏剧性的网络事件。然而，如果延迟的变化在合理范围内，则根本不是问题。因此，路由器通常以限制丢失概率的方式处理路由协议数据报，在某些情况下接受相对较高的延迟，即使流量对网络绝对至关重要。电话呼叫设置交换机具有以下特点：
well: faced with a choice between loss and delay, protocols like SIP and H.323 far prefer the latter, as the call setup time is far less than it would be if datagrams had to be retransmitted, and this is true regardless of whether the call is routine or of high precedence. As such, QoS markings tell us how to provide good service to an application independent of how "important" it may be at the current time, while "importance" can be conveyed separately in many cases.
嗯：面对丢失和延迟之间的选择，像SIP和H.323这样的协议更倾向于后者，因为呼叫建立时间远小于必须重新传输数据报时的时间，这是正确的，无论呼叫是常规的还是高优先级的。因此，QoS标记告诉我们如何向应用程序提供良好的服务，而不依赖于当前应用程序的“重要性”，而在许多情况下，“重要性”可以单独传达。
One could describe a nested VPN network in terms of three network diagrams. Figure 1 shows a simple network stretched across a VPN connection. The VPN router (where, following [RFC2460], a "router" is "a node that forwards packets not explicitly addressed to itself"), performs the following steps:
可以用三种网络图来描述嵌套的VPN网络。图1显示了一个横跨VPN连接的简单网络。VPN路由器（其中，在[RFC2460]之后，“路由器”是“转发未显式寻址到自身的数据包的节点”）执行以下步骤：
o receives an IP datagram from a plaintext interface,
o 从明文接口接收IP数据报，
o determines what remote enclave and therefore other VPN router to forward it to,
o 确定要转发到的远程飞地和其他VPN路由器，
o ensures that it has a tunnel mode security association (as generally defined in [RFC4301], Section 4) with that router,
o 确保其与该路由器具有隧道模式安全关联（如[RFC4301]第4节中的一般定义），
o encloses the encrypted datagram within another VPN (e.g., IPsec) and IP header, and
o 将加密数据报封装在另一个VPN（如IPsec）和IP报头中，以及
o forwards the encapsulated datagram toward the remote VPN router.
o 将封装的数据报转发到远程VPN路由器。
The receiving VPN router reverses the steps:
接收VPN路由器反向执行以下步骤：
o determines what security association the datagram was received from,
o 确定从哪个安全关联接收数据报，
o decrypts the interior datagram,
o 解密内部数据报，
o forwards the now-decapsulated datagram on a plaintext interface.
o 在纯文本接口上转发现在已解除封装的数据报。
The use of IPsec in this manner is described as the tunnel mode of [RFC4301] and [RFC4303].
以这种方式使用IPsec被描述为[RFC4301]和[RFC4303]的隧道模式。
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router
||
|| IPsec Tunnel through routed network
||
VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router
||
|| IPsec Tunnel through routed network
||
VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 1: VPN-Connected Enclave
图1:VPN连接的飞地
An important point to understand is that the VPN tunnel, like other features of the routed network, are invisible to the host. The host can infer that "something out there" is affecting the Path MTU, introducing delay, or otherwise affecting its data stream, but if properly implemented, it should be able to adapt to these. The words "if properly implemented" are the bane of every network manager, however; substandard implementations do demonstrably exist.
需要了解的一个重要点是，VPN隧道与路由网络的其他功能一样，对主机不可见。主机可以推断“有什么东西”正在影响路径MTU、引入延迟或以其他方式影响其数据流，但如果正确实现，它应该能够适应这些情况。然而，“如果实施得当”是每个网络管理者的祸根；不符合标准的实现确实存在。
Outside of the enclave, the hosts are essentially invisible. The communicating enclaves look like a simple data exchange between peer hosts across a routed network, as shown in Figure 2.
在飞地之外，宿主基本上是看不见的。通信飞地看起来像是路由网络上对等主机之间的简单数据交换，如图2所示。
Hosts Not Visible
/==================/
Router
|
VPN-Router
/---------------------/
Inner Domain
/---------------------/
VPN-Router
|
Router
/==================/
Hosts Not Visible
Hosts Not Visible
/==================/
Router
|
VPN-Router
/---------------------/
Inner Domain
/---------------------/
VPN-Router
|
Router
/==================/
Hosts Not Visible
Figure 2: VPN-Connected Enclave from Exterior Perspective
图2：从外部角度看VPN连接的Enclave
Such networks can be nested and re-used in a complex manner. As shown in Figure 3, a pair of enclaves might communicate across a ciphertext network that, for various reasons, is itself re-encrypted and transmitted across a larger ciphertext network. The reasons for
这种网络可以嵌套并以复杂的方式重复使用。如图3所示，一对Enclave可能通过密文网络进行通信，由于各种原因，该网络本身被重新加密并通过更大的密文网络传输。原因
doing this vary, but they relate to information-hiding in the wider network, different levels of security required for different enclosed enclaves, and so on.
这方面的做法各不相同，但它们涉及到信息隐藏在更广泛的网络中，不同封闭的飞地需要不同的安全级别，等等。
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router VPN-Router VPN-Router
/---------------------/ /----------/
Router -------------Router
|
VPN-Router VPN-Router
/-----------/ /----------/
Router -------Router
|
|
Router -------Router
/-----------/ /----------/
VPN-Router VPN-Router
|
Router ------------Router
/---------------------/ /----------/
VPN-Router VPN-Router VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Host Host Host Host Host Host
/------------------/ /------------------/
Router -------Router
|
VPN-Router VPN-Router VPN-Router
/---------------------/ /----------/
Router -------------Router
|
VPN-Router VPN-Router
/-----------/ /----------/
Router -------Router
|
|
Router -------Router
/-----------/ /----------/
VPN-Router VPN-Router
|
Router ------------Router
/---------------------/ /----------/
VPN-Router VPN-Router VPN-Router
|
Router -------Router
/------------------/ /------------------/
Host Host Host Host Host Host
Figure 3: Nested VPN
图3：嵌套VPN
The key question this document explores is "how do reservations, and preemption of reservations, work in such an environment?"
本文档探讨的关键问题是“在这样的环境中，保留和保留的优先权是如何工作的？”
The Integrated Services model for networking was originally proposed in [RFC1633]. In short, it divides all applications into two broad classes: those that will adapt themselves to any available bandwidth, and those that will not or cannot. In the words of [RFC1633]:
网络的综合服务模型最初在[RFC1633]中提出。简言之，它将所有应用程序分为两大类：一类是适应任何可用带宽的应用程序，另一类是不适应或不能适应的应用程序。用[RFC1633]的话来说：
One class of applications needs the data in each packet by a certain time and, if the data has not arrived by then, the data is essentially worthless; we call these "real-time" applications. Another class of applications will always wait for data to arrive; we call these "elastic" applications.
一类应用程序需要在某个时间段内每个数据包中的数据，如果该数据尚未到达，则该数据基本上毫无价值；我们称这些为“实时”应用程序。另一类应用程序将始终等待数据到达；我们称之为“弹性”应用程序。
The Integrated Services model defines data flows supporting applications as either "real-time" or "elastic". It should be noted that "real-time" traffic is also referred to as "inelastic" traffic, and that elastic traffic is occasionally referred to as "non-real-time".
集成服务模型将支持应用程序的数据流定义为“实时”或“弹性”。应该注意，“实时”流量也被称为“非弹性”流量，弹性流量偶尔被称为“非实时”。
In this view, the key issue is the so-called "playback point": a real-time application is considered to have a certain point in time at which data describing the next sound, picture, or whatever to be delivered to a display device or forfeit its utility, while an elastic application has no such boundary. Another way to look at the difference is that real-time applications have an irreducible lower bound on their bandwidth requirements. For example, the typical G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/ UDP/RTP headers) at 20 millisecond intervals. This will yield 80 kbps of bandwidth, without silence suppression, and not accounting for the layer 2 overhead. To operate in real-time, a G.711 codec requires the network over which its data will be delivered to support communications at 80 kbps at the IP layer with roughly constant end-to-end delay and nominal or no loss. If this is not possible (if there is significant loss or wide variations in delay), voice quality will suffer. On the other hand, if many megabits of capacity are available, the G.711 codec will not increase its bandwidth requirements either. Although adaptive codecs exist (e.g., G.722.2 or G.726), the adaptive mechanism can either require greater or lesser bandwidth and can adapt only within a certain range of bandwidth requirements beyond which the quality of the data flow required is not met. Elastic applications, however, will generally adapt themselves to any network: if the bottleneck provides 9600 bits per second, a Web transfer or electronic mail exchange will happen at 9600 bits per second, and if hundreds of megabits are available, the TCP (or SCTP) transport will increase their transfer rate in an attempt to reduce the time required to accomplish the transfer.
在这种观点中，关键问题是所谓的“回放点”：实时应用程序被认为具有某个时间点，在该时间点，描述下一个声音、图片或任何东西的数据将被传送到显示设备或丧失其效用，而弹性应用程序没有这样的边界。另一种看待差异的方式是，实时应用程序的带宽需求有一个不可降低的下限。例如，典型的G.711有效负载以20毫秒的间隔以160字节的样本（加上40字节的IP/UDP/RTP报头）交付。这将产生80 kbps的带宽，没有静音抑制，并且不考虑第2层的开销。为了实时运行，G.711编解码器需要传输其数据的网络，以支持IP层80 kbps的通信，且具有大致恒定的端到端延迟和标称或无损耗。如果这是不可能的（如果有重大损失或延迟变化很大），语音质量将受到影响。另一方面，如果有很多兆的容量可用，G.711编解码器也不会增加其带宽要求。尽管存在自适应编解码器（例如，g.722.2或g.726），但自适应机制可以要求更大或更小的带宽，并且只能在带宽要求的特定范围内进行自适应，超过该范围，所需的数据流质量将得不到满足。然而，弹性应用程序通常会适应任何网络：如果瓶颈提供每秒9600位，则Web传输或电子邮件交换将以每秒9600位的速度进行，如果有数百兆位可用，则TCP（或SCTP）将以每秒9600位的速度进行传输将提高传输速率，以减少完成传输所需的时间。
For real-time applications, those that require data to be delivered end to end with at least a certain rate and with delays varying between stated bounds, the Integrated Services architecture proposes the use of a signaling protocol that allows the communicating applications and the network to communicate about the application requirements and the network's capability to deliver them. Several such protocols have been developed or are under development, notably including the Resource Reservation Protocol (RSVP) and Next Steps in Signaling (NSIS). The present discussion is limited to RSVP, although any protocol that delivers a similar set of capabilities could be considered.
对于实时应用程序，要求数据以至少一定的速率端到端传输，并且延迟在规定的范围内变化的应用程序，综合服务体系结构建议使用信令协议，该协议允许通信应用程序和网络就应用程序需求和网络交付需求的能力进行通信。一些这样的协议已经开发或正在开发中，特别是包括资源预留协议（RSVP）和信令中的下一步（NSIS）。目前的讨论仅限于RSVP，尽管可以考虑提供类似功能集的任何协议。
RSVP is initially defined in [RFC2205] with a set of datagram processing rules defined in [RFC2209] and datagram details for Integrated Services [RFC2210]. Conceptually, this protocol specifies a way to identify data flows from a source application to a destination application and request specific resources for them. The source may be a single machine or a set of machines listed explicitly or implied, whereas the destination may be a single machine or a multicast group (and therefore all of the machines in it). Each application is specified by a transport protocol number in the IP protocol field, or may additionally include destination and perhaps source port numbers. The protocol is defined for both IPv4 [RFC0791] and IPv6 [RFC2460]. It was recognized immediately that it was also necessary to provide a means to perform the same function for various kinds of tunnels, which implies a relationship between what is inside and what is outside the tunnel. Definitions were therefore developed for IPsec [RFC2207] and [RFC4860] and for more generic forms of tunnels [RFC2746]. With the later development of the Differentiated Services Architecture [RFC2475], definitions were added to specify the Differentiated Services Code Point (DSCP) [RFC2474] to be used by a standard RSVP data flow in [RFC2996] and to use a pair of IP addresses and a DSCP as the identifying information for a data flow [RFC3175].
RSVP最初在[RFC2205]中定义，并在[RFC2209]中定义了一组数据报处理规则和集成服务的数据报详细信息[RFC2210]。从概念上讲，该协议指定了一种方法来标识从源应用程序到目标应用程序的数据流，并为它们请求特定的资源。源可以是显式或隐含列出的一台机器或一组机器，而目标可以是一台机器或一个多播组（以及其中的所有机器）。每个应用程序由IP协议字段中的传输协议号指定，或者还可以包括目标端口号和源端口号。该协议是为IPv4[RFC0791]和IPv6[RFC2460]定义的。人们立即认识到，还必须提供一种方法，为各种隧道执行相同的功能，这意味着隧道内外的关系。因此，为IPsec[RFC2207]和[RFC4860]以及更通用的隧道形式[RFC2746]制定了定义。随着区分服务体系结构[RFC2475]的后期开发，增加了定义，以指定[RFC2996]中标准RSVP数据流使用的区分服务代码点（DSCP）[RFC2474]，并使用一对IP地址和DSCP作为数据流[RFC3175]的标识信息。
In addition, the initial definition of the protocol included a placeholder for policy information, and for preemption of reservations. This placeholder was later specified in detail in [RFC2750] with a view to associating a policy [RFC2872] with an identity [RFC3182] and thereby enabling the network to provide a contracted service to an authenticated and authorized user. This was integrated with the Session Initiation Protocol [RFC3261] in [RFC3312]. Preemption of a reservation is specified as in [RFC3181] -- a reservation that is installed in the network using an Preemption Priority and retained using a separate Defending Priority may be removed by the network via an RESV Error signal that removes the entire reservation. This has issues, however, in that the matter is often not quite so black and white. If the issue is that an existing reservation for 80 kbps can no longer be sustained but a 60 kbps reservation could, it is possible that a VoIP sender could change from a G.711 codec to a G.729 codec and achieve that. Or, if there are multiple sessions in a tunnel or other aggregate, one of the calls could be eliminated leaving capacity for the others. [RFC4495] seeks to address this issue.
此外，协议的初始定义包括一个占位符，用于策略信息和预订的抢占。该占位符后来在[RFC2750]中详细指定，目的是将策略[RFC2872]与标识[RFC3182]相关联，从而使网络能够向经过身份验证和授权的用户提供约定服务。这与[RFC3312]中的会话启动协议[RFC3261]集成。如[RFC3181]中所述，预留的抢占被指定——网络可以通过删除整个预留的RESV错误信号删除使用抢占优先级安装在网络中并使用单独的防御优先级保留的预留。然而，这也有一些问题，因为事情往往不是那么黑白分明。如果问题是80 kbps的现有保留无法继续，但60 kbps的保留可以继续，则VoIP发送方可能会从G.711编解码器更改为G.729编解码器并实现这一点。或者，如果在一个隧道或其他聚合中有多个会话，则可以消除其中一个呼叫，将容量留给其他呼叫。[RFC4495]试图解决这个问题。
In a similar way, a capability was added to limit the possibility of control signals being spoofed or otherwise attacked [RFC2747] [RFC3097].
以类似的方式，增加了一种能力，以限制控制信号被欺骗或以其他方式攻击的可能性[RFC2747][RFC3097]。
[RFC3175] describes several features that are unusual in RSVP, being specifically set up to handle aggregates in a service provider network. It describes three key components:
[RFC3175]描述了RSVP中不常见的几个功能，这些功能是专门为处理服务提供商网络中的聚合而设置的。它描述了三个关键组件：
o The RFC 3175 session object, which identifies not the IP addresses of the packets that are identified, but the IP addresses of the ingress and egress devices in the network, and the DSCP that the traffic will use.
o RFC 3175会话对象，它标识的不是已标识的分组的IP地址，而是网络中入口和出口设备的IP地址，以及流量将使用的DSCP。
o The function of a reservation "aggregator", which operates in the ingress router and accepts individual reservations from the "customer" network. It aggregates the reservations into the ISP core in a tunnel or an MPLS LSP, or as a traffic stream that is known to leave at the deaggregator.
o 预订“聚合器”的功能，在入口路由器中运行，并接受来自“客户”网络的个人预订。它将保留聚合到隧道或MPLS LSP中的ISP核心中，或作为已知在解聚集器处离开的业务流。
o The function of a reservation "deaggregator", which operates in the egress router and breaks the aggregate reservation and data streams back out into individual data streams that may be passed to other networks.
o 保留“解聚集器”的功能，该功能在出口路由器中运行，并将聚集的保留和数据流分解回可传递给其他网络的单个数据流。
In retrospect, the Session Object specified by RFC 3175 is useful but not intrinsically necessary. If the ISP network uses tunnels, such as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security Associations, the concepts of an aggregator and a deaggregator work in the same manner, although the reservation mechanism would be that of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746].
回想起来，RFC 3175指定的会话对象很有用，但本质上不是必需的。如果ISP网络使用隧道，例如MPLS LSP、IP/IP或GRE隧道或封闭IPsec安全关联，则聚合器和解聚合器的概念以相同的方式工作，尽管保留机制是[RFC3473]和[RFC3474]、[RFC2207]、[RFC4860]或[RFC2746]的机制。
The conceptual structure of a VPN router is similar to that of any other router. In its simplest form, it is physically a two or more port device (similar to that shown in Figure 4), which has one or more interfaces to the protected enclave(s) and one or more interfaces to the outside world. On the latter, it structures some number of tunnels (in the case of an IPsec tunnel, having security associations) that it can treat as point-to-point interfaces from a routing perspective.
VPN路由器的概念结构类似于任何其他路由器。在其最简单的形式中，它实际上是一个两个或多个端口的设备（类似于图4所示），它具有一个或多个到受保护飞地的接口以及一个或多个到外部世界的接口。对于后者，它构造了一些隧道（在IPsec隧道的情况下，具有安全关联），可以从路由角度将其视为点对点接口。
+---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+
| | | |
+----+-----------+------------+-----------------+----+
| IP |
+-----------+--------------------+------------+------+
| | |
| +-----+-----+ +----+------+
| | Encrypt/ | | Encrypt/ |
| |Decrypt for| |Decrypt for|
| | Security | | Security |
| |Association| |Association|
| +-----+-----+ +----+------+
| | |
+-----------+------------+ +-----+------------+------+
| Plaintext | | Ciphertext |
| Interface | | Interface |
+------------------------+ +-------------------------+
+---------+ +-------+ +----+----+ +---------+
| RSVP | |Routing| |Net Guard| |IPsec Mgr|
+----+----+ +---+---+ +----+----+ +----+----+
| | | |
+----+-----------+------------+-----------------+----+
| IP |
+-----------+--------------------+------------+------+
| | |
| +-----+-----+ +----+------+
| | Encrypt/ | | Encrypt/ |
| |Decrypt for| |Decrypt for|
| | Security | | Security |
| |Association| |Association|
| +-----+-----+ +----+------+
| | |
+-----------+------------+ +-----+------------+------+
| Plaintext | | Ciphertext |
| Interface | | Interface |
+------------------------+ +-------------------------+
Figure 4: Logical Structure of a VPN Router
图4:VPN路由器的逻辑结构
The encrypt/decrypt unit may be implemented as a function of the plaintext router, as a function on its interface card, or as a function of an external device with a private interface to the IP routing functionality of the plaintext router. These are conceptually equivalent, although there are practical differences in implementation. The key issue is that when IP routing presents a message to the encrypt/decrypt unit for transmission, it must also be presented with the IP address of the plaintext routing peer, whether host or router, to which the security association must be established. This IP Address is used to select (and perhaps create) the security association, and in turn select the appropriate set of security parameters. This could also be implemented by presenting the local Security Parameter Index (SPI) for the data, if it has been created out of band by the Network Management Process.
加密/解密单元可以实现为明文路由器的功能、其接口卡上的功能或具有明文路由器的IP路由功能的专用接口的外部设备的功能。这些在概念上是等价的，尽管在实现上存在实际差异。关键问题是，当IP路由将消息呈现给加密/解密单元进行传输时，还必须呈现明文路由对等方的IP地址，无论是主机还是路由器，必须与之建立安全关联。此IP地址用于选择（或者创建）安全关联，并依次选择适当的安全参数集。如果数据是由网络管理过程在带外创建的，也可以通过显示数据的本地安全参数索引（SPI）来实现。
In addition, it is necessary for aggregated signaling to be generated for the ciphertext domain. This may be accomplished in several ways:
此外，有必要为密文域生成聚合信令。这可以通过几种方式实现：
o by having the RSVP process on the plaintext router generate the messages and having the encrypt/decrypt unit bypass them into the ciphertext network
o 通过让明文路由器上的RSVP进程生成消息，并让加密/解密单元绕过它们进入密文网络
o by having the plaintext RSVP process advise a process in the encrypt/decrypt implementation of what needs to be generated using some local exchange, and having it generate such messages, or
o 通过让明文RSVP进程向加密/解密实现中的进程建议需要使用某些本地交换生成的内容，并让其生成此类消息，或
o by having a separate parallel network management system intermediate between the plaintext and ciphertext routers, in which case, the encrypt/decrypt unit and the parallel network system must use the same address, and the ciphertext router must distinguish between traffic for them based on SPI or the presence of encryption.
o 通过在明文路由器和密文路由器之间具有单独的并行网络管理系统，在这种情况下，加密/解密单元和并行网络系统必须使用相同的地址，并且密文路由器必须基于SPI或加密的存在来区分它们的通信量。
Control plane signaling using this additional path is described in Section 3.2. The information flow between the plaintext and ciphertext domains includes
第3.2节描述了使用此附加路径的控制平面信令。明文域和密文域之间的信息流包括
o IP datagrams via the encrypt/decrypt unit,
o 通过加密/解密单元的IP数据报，
o RSVP signaling via the bypass path,
o 通过旁路路径发送RSVP信号，
o Control information coordinating security associations, and
o 控制信息协调安全关联，以及
o precious little else.
o 除此之外几乎没有什么。
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'
/ \
( +--+ +--+ enclave ) ,---------.
.----------. \ |H2+---+R2| / ,-' `
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+
|H1+---+R1| \`. | ,' / |R3+---+H3|
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+
| / _.`---|VPN2||''-. \ |
enclave +----+-i.--'' +----++ `----.\ +----+ enclave
--------|VPN1|' | ``|VPN3| ,
,+----+ | +----+------'
,' --+-------+----------+------------------+---`.
,' ++-+ `.
,' |R7+--------+ `.
/ interface +--+ | \
domain 1 +-+--+ \
_.--------|VPN7|--------.
,-----'' +--+-+ `------. .
`-. ,-' | `-. .-'
`-: inner domain +-++ `.'
( |R9| )
.'. ++-+ ;-.
.' `-. | ,-' `-.
' `------. +-+--+ _.-----' `
interface `---------|VPN8|-------''
domain 2 +-+--+ /
\ | +--+ /
`. +----------+R8| ,'
`. ++-+ ,'
`. --+------------------+-----------+------+-- ,'
,-----+----+ | +----+------.
,' |VPN6|. | _.|VPN4| `
+----+.`----. +----+ _.--'' ,+----+
| \ `--=.-|VPN5|---:' / |
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+
|H6+---+R6| | ,' | `.| |R4+---+H4|
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+
// |H5+---+R5| \
enclave ,'( +--+ +--+ `. enclave
`. ,' \ enclave / '-. ,
`-------' \ / `-------'
Figure 5: Reservations in a Nested VPN
图5：嵌套VPN中的保留
Let us discuss how a resource reservation protocol, and specifically RSVP, might be used in a nested virtual private network.
让我们讨论如何在嵌套的虚拟专用网络中使用资源保留协议，特别是RSVP。
A reservation in a nested VPN is very much like a reservation in any other network, with one exception: it is composed of multiple reservations that must be coordinated. These include a reservation within the originating and receiving enclaves and a reservation at each layer of the VPN, as shown in Figure 5.
嵌套VPN中的保留与任何其他网络中的保留非常相似，只有一个例外：它由多个必须协调的保留组成。这些包括发起和接收飞地内的保留以及VPN每层的保留，如图5所示。
Thus, when a host in one enclave opens a reservation to a host in another enclave, a reservation of the appropriate type and size is created end to end. As it traverses the VPN router leaving its enclave, the reservation information and the data are placed within the appropriate tunnel (e.g., the IPsec Security Association for its precedence level to the appropriate remote VPN router). At the remote VPN router, it is extracted from the tunnel and passed on its way to the target system. The data in the enclave will be marked with a DSCP appropriate to its application and (if there is a difference) precedence level, and the signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating that value. RSVP signaling datagrams (PATH and RESV) are marked with a DCLASS object indicating the value used for the corresponding data. The DSCP on the signaling datagrams, however, is a DSCP for signaling, and has the one provision that if routing varies by DSCP, then it must be a DSCP that is routed the same way as the relevant data. The [RFC2872] policy object specifies the applicable policy (e.g., "routine service for voice traffic") and asserts a [RFC3182] credential indicating its user (which may be a person or a class of persons). As specified in [RFC3181], it also specifies its Preemption Priority and its Defending Priority; these enable the Preemption Priority of a new session to be compared with the Defending Priority of previously admitted sessions.
因此，当一个飞地中的主机向另一个飞地中的主机打开保留时，将端到端创建适当类型和大小的保留。当它穿过VPN路由器离开其飞地时，保留信息和数据被放置在适当的隧道中（例如，IPsec安全关联，其优先级与适当的远程VPN路由器）。在远程VPN路由器上，它被从隧道中提取出来并传递到目标系统。enclave中的数据将标记为适合其应用的DSCP和（如果存在差异）优先级，信令数据报（PATH和RESV）将标记为指示该值的DCLASS对象。RSVP信令数据报（PATH和RESV）用DCLASS对象标记，该对象指示用于相应数据的值。然而，信令数据报上的DSCP是用于信令的DSCP，并且有一个规定，即如果路由因DSCP而异，则它必须是以与相关数据相同的方式路由的DSCP。[RFC2872]策略对象指定适用的策略（例如，“语音通信的例行服务”），并断言指示其用户的[RFC3182]凭证（可能是一个人或一类人）。如[RFC3181]所述，它还规定了其抢占优先级和防御优先级；这些允许将新会话的抢占优先级与先前允许的会话的防御优先级进行比较。
On the ciphertext side of the VPN router, no guarantees result unless the VPN router likewise sets up a reservation to the peer VPN Router across the ciphertext domain. Thus, the VPN router sets up an [RFC2207], [RFC4860], or [RFC3175] reservation to its peer.
在VPN路由器的密文端，除非VPN路由器同样在密文域中设置对对等VPN路由器的保留，否则不能保证结果。因此，VPN路由器向其对等方设置[RFC2207]、[RFC4860]或[RFC3175]保留。
The Session Object defined by [RFC2207] or [RFC4860] contains a field called a "virtual destination port", which allows the multiplexing of many reservations over a common security association and, in the latter case, a common DSCP value. Thus, the voice traffic at every precedence level might use the Expedited Forwarding (EF) DSCP and service as described in [RFC3246], but the reservations would be for "the aggregate of voice sessions at precedence Pn between these VPN routers". This would allow the network administration to describe policies with multiple thresholds, such as "a new session at precedence Pn may be accepted if the total reserved bandwidth does not exceed threshold Qn; if it is necessary and sufficient to accept
[RFC2207]或[RFC4860]定义的会话对象包含一个称为“虚拟目的地端口”的字段，该字段允许通过公共安全关联和公共DSCP值复用多个保留。因此，每个优先级别的语音通信可能使用[RFC3246]中所述的快速转发（EF）DSCP和服务，但保留的是“这些VPN路由器之间优先Pn的语音会话的集合”。这将允许网络管理部门描述具有多个阈值的策略，例如“如果总保留带宽不超过阈值Qn，则可以接受优先级为Pn的新会话；如果有必要且足以接受，则可以接受
the reservation, existing reservations at lower precedences may be preemptively reduced to make acceptance of the new session possible".
在保留方面，先例较低的现有保留可以先发制人地减少，以便能够接受新的会议”。
In the [RFC3175] case, since the DSCP must be used to identify both the reservation and the corresponding data stream, the aggregate reservations for different precedence levels require different DSCP values.
在[RFC3175]情况下，由于必须使用DSCP来标识保留和相应的数据流，不同优先级的聚合保留需要不同的DSCP值。
In either case, the fundamental necessity is for one VPN router to act as what [RFC3175] calls the "aggregator" and another to act as the "deaggregator", and extend a VPN tunnel between them. If the VPN Tunnel is an IPsec Security Association between the VPN routers and the IP packet is entirely contained within (such as is used to cross a firewall), then the behavior of [RFC2746] is required of the tunnel. That bearer will have the following characteristics:
在这两种情况下，最基本的需要是一个VPN路由器充当[RFC3175]所称的“聚合器”，另一个充当“解聚合器”，并在它们之间扩展VPN隧道。如果VPN隧道是VPN路由器之间的IPsec安全关联，并且IP数据包完全包含在其中（例如用于穿越防火墙），则隧道需要[RFC2746]的行为。该持有人将具有以下特征：
o it will have a DSCP corollary to the DSCP for the data or the same DSCP as the data it carries,
o 对于数据，它将有DSCP的推论，或与它所承载的数据相同的DSCP，
o the reservations and data will be carried in security associations between the VPN routers, and
o 保留和数据将在VPN路由器之间的安全关联中进行，以及
o the specification for the reservation for the tunnel itself will not be less than the sum of the requirements of the aggregated reservations.
o 隧道本身的预留规范不得小于合计预留要求的总和。
The following requirements relationships apply between the set of enclosed reservations and the tunnel reservation:
以下要求关系适用于封闭保留区和隧道保留区之间：
o The sum of the average rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the average rate of the tunnel reservation.
o 已针对附加IP头进行调整的所包含保留的平均速率之和将小于或等于隧道保留的平均速率。
o The sum of the peak rates of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the peak rate of the tunnel reservation.
o 已针对附加IP报头进行调整的所包含保留的峰值速率之和将小于或等于隧道保留的峰值速率。
o The sum of the burst sizes of the contained reservations, having been adjusted for the additional IP headers, will be less than or equal to the burst size of the tunnel reservation.
o 已针对附加IP报头调整的所包含保留的突发大小之和将小于或等于隧道保留的突发大小。
o The Preemption Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
o 隧道保留的优先购买权与其聚合的单个保留的优先购买权相同。
o The Defending Priority of a tunnel reservation is identical to that of the individual reservations it aggregates.
o 隧道保留地的防御优先权与其聚合的单个保留地的防御优先权相同。
This would differ only in the case that measurement-based admission is in use in the tunnel but not in the end system. In that case, the tunnel's average bandwidth specification would be greater than or equal to the actual average offered traffic. Such systems are beyond the scope of this specification.
这仅在隧道中使用基于测量的入口，而非末端系统中使用的情况下有所不同。在这种情况下，隧道的平均带宽规格将大于或等于实际平均提供的流量。此类系统超出了本规范的范围。
As a policy matter, it may be useful to note a quirk in the way Internet QoS works. If the policies for various precedence levels specify different thresholds (e.g., "to accept a new routine call, the total reserved bandwidth after admission may not exceed X; to accept a call with a higher precedence level, the total reserved bandwidth after admission may not exceed X+Y, and this may be achieved by preempting a call with a lower precedence level"), the bandwidth Y effectively comes from the bandwidth in use by elastic traffic rather than forcing a preemption event.
作为一个政策问题，注意Internet QoS工作方式中的一个怪癖可能是有用的。如果不同优先级的策略指定了不同的阈值（例如。，“接受新的例行呼叫时，允许后的总保留带宽不得超过X；接受优先级较高的呼叫时，允许后的总保留带宽不得超过X+Y，这可以通过抢占优先级较低的呼叫来实现”），带宽Y有效地来自弹性流量使用的带宽，而不是强制抢占事件。
As discussed in Section 1.5, preemption is specified in [RFC3181] and further addressed in [RFC4495]. The issue is that in many cases the need is to reduce the bandwidth of a reservation due to a change in the network, not simply to remove the reservation. In the case of an end-system-originated reservation, the end system might be able to accommodate the need through a change of codec; in the case of an aggregate of some kind, it could reduce the bandwidth it is sending by dropping one or more reservations entirely.
如第1.5节所述，[RFC3181]中规定了抢占权，并在[RFC4495]中进一步阐述了抢占权。问题是，在许多情况下，由于网络的变化，需要减少保留的带宽，而不仅仅是删除保留。在终端系统发起的预订的情况下，终端系统可能能够通过改变编解码器来满足需求；在某种聚合的情况下，它可以通过完全删除一个或多个保留来减少发送的带宽。
In a nested VPN or other kind of aggregated reservation, this means that the deaggregator (the VPN router initiating the RESV signal for the tunnel) must
在嵌套VPN或其他类型的聚合保留中，这意味着解聚合器（为隧道启动RESV信号的VPN路由器）必须
o receive the RESV Error signaling it to reduce its bandwidth,
o 接收RESV错误信号以减少其带宽，
o re-issue its RESV accordingly,
o 重新发布相应的RESV，
o identify one or more of its aggregated reservations, enough to do the job, and
o 确定一个或多个足以完成工作的聚合预订，以及
o signal them to reduce their bandwidth accordingly.
o 向他们发出信号，相应地减少他们的带宽。
It is possible, of course, that it is signaling them to reduce their bandwidth to zero, which is functionally equivalent to removing the reservation as described in [RFC3181].
当然，它可能是在向他们发送信号，将他们的带宽减少到零，这在功能上等同于删除[RFC3181]中所述的保留。
In the routers in the core, an additional case arises. One could imagine that some enclave presents the VPN with a single session, and that session has a higher precedence level. If some interior link is congested (e.g., the reserved bandwidth will exceed policy if the
在核心路由器中，出现了另一种情况。可以想象，某个enclave为VPN提供了一个会话，该会话具有更高的优先级。如果某些内部链路拥塞（例如，如果
call is admitted), a session between a different pair of VPN routers must be preempted. More generally, in selecting a reservation to preempt, the core router must always select a reservation at the lowest available Defending Priority. This is the reason that various precedence levels must be kept separate in the core.
呼叫被允许），必须抢占不同VPN路由器对之间的会话。更一般地说，在选择要抢占的预留时，核心路由器必须始终选择具有最低可用防御优先级的预留。这就是各优先级在核心中必须保持分离的原因。
The network in Figure 5 shows three security layers: six plaintext enclaves around the periphery, two ciphertext domains connecting them at one layer (referred to in the diagram as an "interface domain"), and a third ciphertext domain connecting the first two (referred to in the diagram as an "inner domain"). The following distribution of information exists:
图5中的网络显示了三个安全层：围绕外围的六个明文飞地，两个密文域在一个层上连接它们（在图中称为“接口域”），第三个密文域连接前两个（在图中称为“内部域”）。存在以下信息分布：
o Each enclave has access to general routing information concerning other enclaves it is authorized to communicate with: systems in it can translate a DNS name for a remote host or domain and obtain the corresponding address or prefix.
o 每个飞地都可以访问有关其授权与之通信的其他飞地的一般路由信息：其中的系统可以翻译远程主机或域的DNS名称，并获得相应的地址或前缀。
o Each enclave router also has specific routing information regarding its own enclave.
o 每个enclave路由器还具有关于其自身enclave的特定路由信息。
o A default route is distributed within the enclave, pointing to its VPN router.
o 默认路由分布在enclave内，指向其VPN路由器。
o VPN Routers 1-6 are able to translate remote enclave prefixes to the appropriate remote enclave's VPN router addresses.
o VPN路由器1-6能够将远程enclave前缀转换为适当的远程enclave的VPN路由器地址。
o Each interface domain has access to general routing information concerning the other interface domains, but not the enclaves. Systems in an interface domain can translate a DNS name for a remote interface domain and obtain the corresponding address or prefix.
o 每个接口域都可以访问有关其他接口域的常规路由信息，但不能访问飞地。接口域中的系统可以转换远程接口域的DNS名称并获得相应的地址或前缀。
o Each interface domain router also has specific routing information regarding its own interface domain.
o 每个接口域路由器还具有关于其自身接口域的特定路由信息。
o A default route is distributed within the interface domain, pointing to the "inner" VPN router.
o 默认路由分布在接口域中，指向“内部”VPN路由器。
o VPN Routers 7 and 8 are able to translate remote interface domain prefixes to remote VPN router addresses.
o VPN路由器7和8能够将远程接口域前缀转换为远程VPN路由器地址。
o Routers in the inner domain have routing information for that domain only.
o 内部域中的路由器只有该域的路由信息。
While the example shows three levels, there is nothing magic about the number three. The model can be extended to any number of concentric layers.
虽然示例显示了三个级别，但数字三并没有什么神奇之处。该模型可以扩展到任意数量的同心层。
Note that this example places unidirectional reservations in the forward direction. In voice and video applications, one generally has a reservation in each direction. The reverse direction is not discussed, for the sake of clarity, but operates in the same way in the reverse direction and uses the same security associations.
请注意，此示例将单向保留放置在前进方向。在语音和视频应用中，通常每个方向都有预约。为了清楚起见，不讨论反向，而是在反向中以相同的方式操作，并使用相同的安全关联。
Now let us install a set of reservations from H1 to H4, H2 to H5, and H3 to H6, and for the sake of argument, let us presume that these are at the "routine" precedence. H1, H2, and H3 each initiate a PATH signal describing their traffic. For the sake of argument, let us presume that H1's reservation is for an [RFC2205] session, H2's reservation is for a session encrypted using IPsec, and therefore depends on [RFC2207], and H3 (which is a Public Switched Telephone Network (PSTN) gateway) sends an [RFC3175] reservation comprising a number of distinct sessions. Since these are going to H4, H5, and H6, respectively, the default route leads them to VPN1, VPN2, and VPN3, respectively.
现在，让我们安装一组从H1到H4，从H2到H5，从H3到H6的保留，为了便于论证，让我们假设这些保留处于“常规”优先级。H1、H2和H3各自启动描述其流量的路径信号。为了便于论证，我们假设H1的保留是针对[RFC2205]会话的，H2的保留是针对使用IPsec加密的会话的，因此取决于[RFC2207]，H3（公共交换电话网络（PSTN）网关）发送包含多个不同会话的[RFC3175]保留。由于它们将分别连接到H4、H5和H6，因此默认路径将分别连接到VPN1、VPN2和VPN3。
The VPN routers each ensure that they have an appropriate security association or tunnel open to the indicated remote VPN router (VPN4, VPN5, or VPN6). This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, these tunnel/SA reservations will follow the default route to VPN7.
VPN路由器每个都确保它们有一个适当的安全关联或隧道，该安全关联或隧道打开到指定的远程VPN路由器（VPN4、VPN5或VPN6）。这将是指定应用程序在指定优先级的安全关联或通道。完成后，它将把路径信号放入安全关联并转发它。如果这种情况不存在，遵循[RFC3175]的聚合模型，它现在将在接口域内为隧道/SA打开保留（发送路径信号）；如果保留确实存在，VPN路由器将适当增加ADSPEC中指示的带宽。在本例中，这些隧道/SA预订将遵循到VPN7的默认路线。
VPN7 ensures that it has an appropriate security association or tunnel open to VPN8. This will be a security association or tunnel for the indicated application at the indicated precedence level. Having accomplished that, it will place the PATH signal into the security association and forward it. If such does not already exist, following [RFC3175]'s aggregation model, it will now open a reservation (send a PATH signal) for the tunnel/SA within the interface domain; if the reservation does exist, the VPN router will increase the bandwidth indicated in the ADSPEC appropriately. In this example, this tunnel/SA reservation is forwarded to VPN8.
VPN7确保它有一个对VPN8开放的适当的安全关联或通道。这将是指定应用程序在指定优先级的安全关联或通道。完成后，它将把路径信号放入安全关联并转发它。如果这种情况不存在，遵循[RFC3175]的聚合模型，它现在将在接口域内为隧道/SA打开保留（发送路径信号）；如果保留确实存在，VPN路由器将适当增加ADSPEC中指示的带宽。在本例中，此隧道/SA预订被转发到VPN8。
VPN8 acts as an [RFC3175] deaggregator for the inner domain. This means that it receives the PATH signal for the inner domain reservation and stores state, decrypts the data stream from VPN7, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated PATH signals) into its interface domain. The PATH signals originated by VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and VPN6 according to the routing of the interface domain.
VPN8充当内部域的[RFC3175]解聚器。这意味着它接收内部域保留的路径信号并存储状态，解密来自VPN7的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的路径信号）转发到其接口域。因此，由VPN1、VPN2和VPN3产生的路径信号根据接口域的路由转发到VPN4、VPN5和VPN6。
VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the interface domain. This means that it receives the PATH signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated PATH signals) into its enclave. The PATH signals originated by H1, H2, and H3 are therefore forwarded towards H4, H5, and H6 according to the routing of the enclave.
VPN4、VPN5和VPN6分别充当接口域的[RFC3175]解聚集器。这意味着它接收接口域保留的路径信号并存储状态，解密来自其对等方的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的路径信号）转发到其enclave中。因此，由H1、H2和H3产生的路径信号根据飞地的路由转发到H4、H5和H6。
H4, H5, and H6 now receive the original PATH signals and deliver them to their application.
H4、H5和H6现在接收原始路径信号并将其传送到应用程序。
The application in H4, H5, and H6 decides to install the indicated reservations, meaning that they now reply with RESV signals. These signals request the bandwidth reservation. Following the trail left by the PATH signals, the RESV signals traipse back to their respective sources. The state left by the PATH signals leads them to VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves are configured for RSVP, this will be explicitly via R4, R5, or R6; if they are not, routing will lead them through those routers.
H4、H5和H6中的应用程序决定安装指定的保留，这意味着它们现在使用RESV信号进行回复。这些信号请求带宽预留。沿着路径信号留下的轨迹，RESV信号返回各自的源。路径信号留下的状态分别将它们引导到VPN4、VPN5和VPN6。如果飞地中的路由器配置为RSVP，这将通过R4、R5或R6显式实现；如果它们不是，路由将引导它们通过这些路由器。
The various RSVP-configured routers en route in the enclave (including the VPN router on the "enclave" side) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. The VPN routers will also each generate an RESV for the reservation within the interface domain, attempting to set or increase the bandwidth of the reservation appropriately.
enclave中路由的各种RSVP配置路由器（包括“enclave”侧的VPN路由器）将验证其链路上是否有足够的带宽，以及是否符合任何其他规定的策略。完成此操作后，每一个将更新其保留状态并将RESV信号转发给下一个。VPN路由器还将为接口域内的保留生成一个RESV，试图适当地设置或增加保留的带宽。
The various RSVP-configured routers en route in the interface domain (including VPN8) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the
接口域（包括VPN8）中路由的各种RSVP配置路由器将验证其链路上是否有足够的带宽，以及是否满足任何其他规定的策略。完成此操作后，每一个将更新其保留状态并将RESV信号转发给下一个。VPN8还将为
reservation within the inner domain, attempting to set or increase the bandwidth of the reservation appropriately. This gets the reservation to the inner deaggregator, VPN8.
内部域内的保留，尝试适当设置或增加保留的带宽。这将获得对内部解聚集器VPN8的保留。
The various RSVP-configured routers en route in the inner domain (including VPN7) will verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. This gets the signal to VPN7.
内部域（包括VPN7）中路由的各种RSVP配置路由器将验证其链路上是否有足够的带宽，以及是否满足任何其他规定的策略。完成此操作后，每一个将更新其保留状态并将RESV信号转发给下一个。这会将信号发送到VPN7。
VPN7 acts as an [RFC3175] aggregator for the inner domain. This means that it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and VPN3 through the interface domain.
VPN7充当内部域的[RFC3175]聚合器。这意味着它接收用于内部域保留的RESV信号并存储状态，解密来自VPN8的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的RESV信号）转发到其接口域。因此，由VPN4、VPN5和VPN6发出的RESV信号通过接口域转发到VPN1、VPN2和VPN3。
VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator for the interface domain. This means that it receives the RESV signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its enclave. The RESV signals originated by H4, H5, and H6 are therefore forwarded towards H1, H2, and H3 according to the routing of the enclave.
VPN1、VPN2和VPN3分别充当接口域的[RFC3175]聚合器。这意味着它接收接口域保留的RESV信号并存储状态，解密来自其对等方的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的RESV信号）转发到其enclave中。因此，由H4、H5和H6发出的RESV信号根据飞地的路由转发到H1、H2和H3。
H1, H2, and H3 now receive the original RESV signals and deliver them to their application.
H1、H2和H3现在接收原始RESV信号并将其传送到应用程序。
Without going through the details called out in Sections 2.3.1 and 2.3.2, if sufficient bandwidth exists to support them, reservations of other precedence levels or other applications may also be installed across this network. If the "routine" reservations already described are for voice, for example, and sufficient bandwidth is available under the relevant policy, a reservation for voice at the "priority" precedence level might be installed. Due to the mechanics of preemption, however, this would not expand the existing "routine" reservations in the interface and inner domains, as doing this causes loss of information - how much of the reservation is now "routine" and how much is "priority"? Rather, this new reservation will open up a separate set of tunnels or security associations for traffic of its application class at its precedence between that aggregator and deaggregator.
如果有足够的带宽支持第2.3.1节和第2.3.2节中所述的细节，则也可以通过该网络安装其他优先级别的保留或其他应用程序。例如，如果已经描述的“例行”预留是针对语音的，并且在相关策略下有足够的带宽可用，则可以安装“优先级”优先级别的语音预留。然而，由于抢占机制，这不会扩展接口和内部域中现有的“常规”保留，因为这样做会导致信息丢失——有多少保留现在是“常规”保留，有多少是“优先级”保留？相反，这个新的保留将为其应用程序类的流量在聚合器和解聚合器之间的优先级打开一组单独的隧道或安全关联。
As a side note, there is an opportunity here that does not exist in the PSTN. In the PSTN, all circuits are potentially usable by any PSTN application under a certain set of rules (H channels, such as those used by video streams, must be contiguous and ordered). As such, if a channel is not made available to routine traffic but is made available to priority traffic, the operator is potentially losing revenue on the reserved bandwidth and deserves remuneration. However, in the IP Internet, some bandwidth must be kept for basic functions such as routing, and, in general, policies will not permit 100% of the bandwidth on an interface to be allocated to one application at one precedence. As a result, it may be acceptable to permit a certain portion (e.g., 50%) to be used by routine voice and a larger amount (e.g., 60%) to be used by voice at a higher precedence level. Under such a policy, a higher precedence reservation for voice might not result in the preemption of a routine call, but rather impact elastic traffic, and might be accepted at a time that a new reservation of lower precedence might be denied.
作为旁注，这里有一个在PSTN中不存在的机会。在PSTN中，所有电路都可能由任何PSTN应用程序在特定规则集下使用（H信道，例如视频流所使用的信道，必须是连续且有序的）。因此，如果信道不可用于常规业务，但可用于优先级业务，则运营商可能会损失保留带宽的收入，并应获得报酬。但是，在IP Internet中，必须为路由等基本功能保留一些带宽，而且一般来说，策略不允许将接口上的100%带宽以一个优先级分配给一个应用程序。因此，允许特定部分（例如，50%）用于常规语音，允许更高优先级的语音使用更大数量（例如，60%）是可以接受的。在这种策略下，语音的高优先级保留可能不会导致对例行呼叫的抢占，而是会影响弹性通信量，并且可能在低优先级的新保留被拒绝时被接受。
In microwave networks, such as satellite or mobile ad hoc, one could also imagine network management intervention that could change the characteristics of the radio signal to increase the bandwidth under some appropriate policy.
在微波网络中，如卫星或移动adhoc网络，人们还可以想象网络管理干预可以改变无线电信号的特性，从而在某种适当的策略下增加带宽。
So we now have a number of reservations across the network described in Figure 5 including several reservations at "routine" precedence and one at "priority" precedence. For sake of argument, let us presume that the link from VPN7 to R9 is now fully utilized - all of the bandwidth allocated by policy to voice at the routine or priority level has been reserved. Let us further imagine that a new "priority" reservation is now placed from H3 to H6.
因此，我们现在在图5中描述的网络中有许多保留，包括几个“常规”优先级的保留和一个“优先级”优先级的保留。为了便于论证，让我们假设从VPN7到R9的链路现在已被充分利用——策略以例程或优先级分配给语音的所有带宽已被保留。让我们进一步设想，一个新的“优先”预订现在从H3放置到H6。
The process described in Section 2.3.1 is followed, resulting in PATH state across the network for the new reservation. This is installed even though it is not possible to install a new reservation on VPN7- R9, as it does not install any reservation and the network does not know whether H6 will ultimately require a reservation.
遵循第2.3.1节中描述的过程，产生新预订的网络路径状态。即使无法在VPN7-R9上安装新的保留，也会安装此功能，因为它不安装任何保留，并且网络不知道H6最终是否需要保留。
The process described in Section 2.3.2 is also followed. The application in H6 decides to install the indicated reservation, meaning that it now replies with an RESV signal. Following the trail left by the PATH signal, the RESV signal traipses back towards H3. VPN6 and (if RSVP was configured) R6 verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation
还应遵循第2.3.2节中描述的过程。H6中的应用程序决定安装指定的保留，这意味着它现在用RESV信号进行响应。沿着路径信号留下的轨迹，RESV信号向后拖向H3。VPN6和（如果配置了RSVP）R6验证其链路上是否有足够的带宽，以及是否符合任何其他规定的策略。完成后，每个人都将更新其保留
state and forward the RESV signal to the next. VPN6 also generates an RESV for the reservation within the interface domain, attempting to set or increase the bandwidth of the reservation appropriately.
状态并将RESV信号转发至下一个。VPN6还为接口域内的保留生成一个RESV，试图适当地设置或增加保留的带宽。
VPN6, R8, and VPN8's "interface domain" sides now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. Having accomplished that, each will update its reservation state and forward the RESV signal to the next. VPN8 will also generate an RESV for the reservation within the inner domain, attempting to set or increase the bandwidth of the reservation appropriately. This gets the reservation to the inner deaggregator, VPN8.
VPN6、R8和VPN8的“接口域”端现在验证其链路上是否有足够的带宽，以及是否符合任何其他规定的策略。完成此操作后，每一个将更新其保留状态并将RESV信号转发给下一个。VPN8还将为内域内的保留生成RESV，尝试适当设置或增加保留的带宽。这将获得对内部解聚集器VPN8的保留。
VPN8's "inner domain" side and R9 now verify that there is sufficient bandwidth on their links and that any other stated policy is also met. At R9, a problem is detected - there is not sufficient bandwidth under the relevant policy. In the absence of precedence, R9 would now return an RESV Error indicating that the reservation could not be increased or installed. In such a case, if a preexisting reservation of lower bandwidth already existed, the previous reservation would remain in place but the new bandwidth would not be granted, and the originator (H6) would be informed. Let us clarify what it means to be at a stated precedence: it means that the POLICY_DATA object in the RESV contains a Preemption Priority and a Defending Priority with values specified in some memo. With precedence, [RFC4495]'s algorithm would have the Preemption Priority of the new reservation compared to the Defending Priority of extant reservations in the router, of which there are two: one VPN7->VPN8 at "routine" precedence and one VPN7->VPN8 at "priority" precedence. Since the Defending Priority of routine reservation is less than the Preemption Priority of a "priority" reservation, the "routine" reservation is selected. R9 determines that it will accept the increase in its "priority" reservation VPN7->VPN8 and reduce the corresponding "routine" reservation. Two processes now occur in parallel:
VPN8的“内域”端和R9现在验证它们的链路上是否有足够的带宽，以及是否满足任何其他声明的策略。在R9，检测到问题-相关策略下没有足够的带宽。在没有优先权的情况下，R9现在将返回一个RESV错误，指示无法增加或安装保留。在这种情况下，如果先前存在的较低带宽的保留已经存在，则先前的保留将保持不变，但不会授予新带宽，并且将通知发端人（H6）。让我们澄清一下处于规定优先级意味着什么：这意味着RESV中的POLICY_数据对象包含抢占优先级和防御优先级，其值在某些备注中指定。与路由器中现有保留的防御优先级相比，[RFC4495]的算法具有新保留的抢占优先级，其中有两个：一个VPN7->VPN8处于“例程”优先级，另一个VPN7->VPN8处于“优先级”优先级。由于例行保留的防御优先级小于“优先级”保留的抢占优先级，因此选择“例行”保留。R9确定它将接受其“优先级”保留VPN7->VPN8的增加，并减少相应的“例程”保留。现在有两个过程并行进行：
o The routine reservation is reduced following the algorithms in [RFC4495] and
o 按照[RFC4495]中的算法和
o The priority reservation continues according to the usual rules.
o 优先权保留按照通常的规则继续进行。
R9 reduces its "routine" reservation by sending an RESV Error updating its internal state to reflect the reduced reservation and sending an RESV Error to VPN8 requesting that it reduce its reservation to a number less than or equal to the relevant threshold less the sum of the competing reservations. VPN8, acting as a deaggregator, makes two changes. On the "inner domain" side, it marks its reservation down to the indicated rate (the most it is now
R9通过发送RESV错误更新其内部状态以反映减少的保留，并向VPN8发送RESV错误，请求将其保留减少到小于或等于相关阈值减去竞争保留之和的数字，从而减少其“例行”保留。VPN8作为一个解聚器进行了两个更改。在“内部域”方面，它将其保留标记为指定的速率（目前的最大速率）
permitted to reserve), so that if an RESV Refresh event happens, it will request the specified rate. On the "interface domain" side, it selects one or more of the relevant reservations by an algorithm of its choosing and requests that it likewise reduce its rate. For the sake of argument, let us imagine that the selected reservation is the one to VPN5. The RESV Error now makes its way through R8 to VPN5, which similarly reduces its bandwidth request to the stated amount and passes a RESV Error signal on the "enclave" side requesting that the reservation be appropriately reduced.
允许保留），以便在发生RESV刷新事件时，它将请求指定的速率。在“接口域”方面，它通过其选择的算法选择一个或多个相关保留，并请求它同样降低其速率。为了便于讨论，让我们假设所选的预订是VPN5的预订。RESV错误现在通过R8到达VPN5，VPN5同样将其带宽请求减少到规定的数量，并在“enclave”侧传递RESV错误信号，请求适当减少保留。
H5 is now faced with a decision. If the request is to reduce its reservation to zero, that is equivalent to tearing down the reservation. In this simple case, it sends an RESV Tear to tear down the reservation entirely and advises its application to adjust its expectations of the session accordingly, which may mean shutting down the session. If the request is to reduce it below a certain value, however, it may be possible for the application to do so and remain viable. For example, if a VoIP application using a G.711 codec (80 kbps) is asked to reduce its bandwidth below 70 kbps, it may be possible to renegotiate the codec in use to G.729 or some other codec. In such a case, the originating application should re-reserve at the stated bandwidth (in this case, 70 kbps), initiate the application level change, and let the application change the reservation again (perhaps to 60 kbps) when it has completed that process.
H5现在面临一项决定。如果请求将其保留减少到零，则相当于取消保留。在这种简单的情况下，它发送一个RESV-Tear来完全删除保留，并建议其应用程序相应地调整其对会话的期望，这可能意味着关闭会话。但是，如果请求将其降低到某个值以下，则应用程序可能会这样做并保持可行。例如，如果要求使用G.711编解码器（80 kbps）的VoIP应用程序将其带宽降低到70 kbps以下，则可以将使用中的编解码器重新协商为G.729或其他编解码器。在这种情况下，发起应用程序应在规定的带宽（在本例中为70 kbps）下重新保留，启动应用程序级别更改，并在完成该过程后让应用程序再次更改保留（可能为60 kbps）。
At the time the reservation is being processed at R9, for the "priority" reservation, R9 believes that it has sufficient bandwidth and that any other stated policy is also met, and it forwards the RESV to VPN7. Each will update its reservation state and forward the RESV signal to the next. VPN7 now acts as an [RFC3175] aggregator for the inner domain. This means that it receives the RESV signal for the inner domain reservation and stores state, decrypts the data stream from VPN8, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its interface domain. The RESV signals originated by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and VPN3 through the interface domain.
在R9处理保留时，对于“优先级”保留，R9认为它有足够的带宽，并且也满足任何其他声明的策略，并且它将RESV转发给VPN7。每个将更新其保留状态，并将RESV信号转发给下一个。VPN7现在充当内部域的[RFC3175]聚合器。这意味着它接收用于内部域保留的RESV信号并存储状态，解密来自VPN8的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的RESV信号）转发到其接口域。因此，由VPN4、VPN5和VPN6发出的RESV信号通过接口域转发到VPN1、VPN2和VPN3。
VPN3 now acts as an [RFC3175] aggregator for the interface domain. This means that it receives the RESV signal for the interface domain reservation and stores state, decrypts the data stream from its peer, operates on the RSVP signals as an RSVP-configured router, and forwards the received IP datagrams (including the updated RESV signals) into its enclave. The RESV signal originated by H6 is therefore forwarded towards H3 according to the routing of the enclave.
VPN3现在充当接口域的[RFC3175]聚合器。这意味着它接收接口域保留的RESV信号并存储状态，解密来自其对等方的数据流，作为RSVP配置的路由器对RSVP信号进行操作，并将接收到的IP数据报（包括更新的RESV信号）转发到其enclave中。因此，H6发出的RESV信号根据飞地的路由转发到H3。
H3 now receives the original RESV signals and delivers it to the relevant application.
H3现在接收原始RESV信号并将其发送至相关应用程序。
This section details the data flows within a VPN router, in the context of sessions as described in Section 2. It specifically identifies the signaling flow at a given VPN boundary and additionally elaborates the signaling mechanism with the aid of a Network Guard. A use case describing the proposal in the context of an operational scenario is presented herein.
本节在第2节所述的会话上下文中详细介绍VPN路由器内的数据流。它专门标识给定VPN边界处的信令流，并借助网络防护装置进一步阐述信令机制。本文给出了在操作场景上下文中描述该方案的用例。
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || ||
| |Per session: || ID ||Agg. Session ||
| | Destination ||--->|| Agg. Destination ||
| | Source || || Agg. Source= self ||
| | potential SPI || || Agg. SPI generated||
| | DSCP ---------> DSCP ||
| | vPort or protocol---------> vPort ||
| | and port || || ||
| | Mean rate ---------> Sum of mean rates ||
| | Peak rate ---------> f(Peak rates) ||
| | Burst Size ---------> Sum of Burst sizes||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | Plaintext Interface|| ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || ||
| |Per session: || ID ||Agg. Session ||
| | Destination ||--->|| Agg. Destination ||
| | Source || || Agg. Source= self ||
| | potential SPI || || Agg. SPI generated||
| | DSCP ---------> DSCP ||
| | vPort or protocol---------> vPort ||
| | and port || || ||
| | Mean rate ---------> Sum of mean rates ||
| | Peak rate ---------> f(Peak rates) ||
| | Burst Size ---------> Sum of Burst sizes||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | Plaintext Interface|| ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 6: Data Flows in a VPN Router Outbound
图6:VPN路由器出站中的数据流
Parameters on a reservation include:
预订的参数包括：
Destination Address: On the plaintext side, the VPN router participates in the end-to-end reservations being installed for plaintext sessions. These may include individual flows as described in [RFC2205], IPsec data flows [RFC2207], aggregate reservations [RFC3175], or other types. It passes an identifier for the ciphertext side of the deaggregator to its ciphertext unit.
目标地址：在明文侧，VPN路由器参与为明文会话安装的端到端保留。这些可能包括[RFC2205]、IPsec数据流[RFC2207]、聚合保留[RFC3175]或其他类型中描述的单个流。它将解聚集器的密文端的标识符传递给其密文单元。
DSCP: The DSCP of the plaintext data flow is provided to the cipher text side.
DSCP：明文数据流的DSCP提供给密文端。
Virtual Port: The virtual destination port is provided to the cipher text side. This may be derived from an [RFC2207] session object or from policy information.
虚拟端口：虚拟目标端口提供给密码文本端。这可能来自[RFC2207]会话对象或策略信息。
Mean Rate: The sum of the plaintext mean rates is provided to the ciphertext unit.
平均速率：将明文平均速率之和提供给密文单元。
Peak Rate: A function of the plaintext peak rates is provided to the ciphertext unit. This function is less than or equal to the sum of the peak rates.
峰值速率：向密文单元提供明文峰值速率的函数。此函数小于或等于峰值速率之和。
Burst Size: The sum of the burst sizes is provided to the cipher text unit.
突发大小：向密码文本单元提供突发大小的总和。
Messages include:
信息包括：
Path: The plaintext PATH message is sent as encrypted data to the ciphertext unit. In parallel, a trigger needs to be sent to the ciphertext unit that results in it generating the corresponding aggregated PATH message for the ciphertext side.
路径：明文路径消息作为加密数据发送到密文单元。同时，需要向密文单元发送一个触发器，该触发器将导致密文单元为密文端生成相应的聚合路径消息。
Path Error: This indicates that a PATH message sent to the remote enclave was in error. In the error case, the message itself is sent on as encrypted data, but a signal is sent to the ciphertext side in case the error affects the ciphertext reservation (such as removing or changing state).
路径错误：这表示发送到远程enclave的路径消息出错。在错误情况下，消息本身作为加密数据发送，但如果错误影响密文保留（例如删除或更改状态），则会向密文端发送信号。
Path Tear: The PATH Tear message is sent as encrypted data to the ciphertext unit. In parallel, a signal is sent to the cipher text side; it will trigger a Path Tear on its reservation in the event that this is the last aggregated session, or change the SENDER_TSPEC of the aggregated session.
路径撕裂：路径撕裂消息作为加密数据发送到密文单元。并行地，向密码文本侧发送信号；如果这是最后一个聚合会话，它将在其保留上触发路径撕裂，或者更改聚合会话的发送方规格。
RESV: The plaintext RESV message is sent as encrypted data to the ciphertext unit. In parallel, a trigger needs to be sent to the ciphertext unit that results in it generating the corresponding aggregated RESV message for the ciphertext side.
RESV：明文RESV消息作为加密数据发送到密文单元。同时，需要向密文单元发送一个触发器，该触发器将导致密文单元为密文端生成相应的聚合RESV消息。
RESV Error: This indicates that a RESV message that was received as data and forwarded into the enclave was in error or needed to be preempted as described in [RFC3181] or [RFC4495]. In the error case, the message itself is sent on as encrypted data, but a signal is sent to the ciphertext side in case the error affects the ciphertext reservation (such as removing or changing state).
RESV错误：这表示作为数据接收并转发到enclave的RESV消息出错或需要抢占，如[RFC3181]或[RFC4495]所述。在错误情况下，消息本身作为加密数据发送，但如果错误影响密文保留（例如删除或更改状态），则会向密文端发送信号。
RESV Tear: The RESV Tear message is sent as encrypted data to the ciphertext unit. In parallel, a signal is sent to the cipher text side; it will trigger a RESV Tear on its reservation in the event that this is the last aggregated session, or reduce the bandwidth of an existing reservation.
RESV Tear：RESV Tear消息作为加密数据发送到密文单元。并行地，向密码文本侧发送信号；如果这是最后一次聚合会话，它将在其保留上触发RESV撕裂，或者减少现有保留的带宽。
RESV Confirm: This indicates that a RESV message received as data and forwarded into the enclave, and is now being confirmed. This message is sent as encrypted data to the ciphertext side, and, in parallel, a signal is sent to potentially trigger an RESV Confirm on the aggregate reservation.
RESV确认：这表示RESV消息作为数据接收并转发到enclave，现在正在确认。此消息作为加密数据发送到密文端，同时，发送一个信号以潜在地触发聚合保留上的RESV确认。
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || terminated ||
| |Per session: |+ || ||
| | Destination || || ||
| | Source <---------Decrypted RSVP ||
| | potential SPI || || message sent to ||
| | DSCP || || Plaintext unit ||
| | vPort or protocol || || *as data* for ||
| | and port || || normal processing ||
| | Mean rate || || ||
| | Peak rate || || ||
| | Burst Size || || ||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| |Plaintext Interface || ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
+-----------------------+ +----------------------+
| +--------------------+| |+--------------------+|
| |RSVP || ||Aggregate RSVP ||
| | || || terminated ||
| |Per session: |+ || ||
| | Destination || || ||
| | Source <---------Decrypted RSVP ||
| | potential SPI || || message sent to ||
| | DSCP || || Plaintext unit ||
| | vPort or protocol || || *as data* for ||
| | and port || || normal processing ||
| | Mean rate || || ||
| | Peak rate || || ||
| | Burst Size || || ||
| | || || ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| | IP || || IP ||
| +--------------------+| |+--------------------+|
| +--------------------+| |+--------------------+|
| |Plaintext Interface || ||Ciphertext Interface||
| +--------------------+| |+--------------------+|
+-----------------------+ +----------------------+
Figure 7: Data Flows in a VPN Router Inbound
图7：入站VPN路由器中的数据流
The aggregate reservation is terminated by the ciphertext side of the VPN router. The RSVP messages related to the subsidiary sessions are carried in the encrypted tunnel as data, and therefore arrive at the plaintext side with other data. As the plaintext side participates in these reservations, some information is returned to the ciphertext size to parameterize the aggregate reservation as described in Section 3.1.1 in the processing of the outbound messages.
聚合保留由VPN路由器的密文端终止。与子会话相关的RSVP消息作为数据在加密隧道中传输，因此与其他数据一起到达明文端。当明文端参与这些保留时，一些信息会返回到密文大小，以参数化出站消息处理中第3.1.1节所述的聚合保留。
3.2. VPN Routers That Use the Network Guard for Signaling across the Cryptographic Boundary
3.2. VPN路由器，它使用网络保护来跨加密边界发送信号
As described in Section 1.6 the Network Guard provides an additional path for the reservation signaling between the plaintext and cipher text domains.
如第1.6节所述，网络保护为明文和密文域之间的保留信令提供了额外的路径。
_.------------.
,--'' Plaintext Domain--.
,-' +--------+ +--------+ `-.
,' | Host | | Host | `.
,' +--------+ +--------+ `.
; :
| +----------------------+ |
: | +--------+ | |
`. | | Router | | ,'
`. | +---+----+ | ,'
`- | +----------+ | ,'
---| +-+--+ +-+--+--+ |'
|----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \
,' | +---+----+ | `.
,' | | Router | | |
/ | +--------+ | \
; +----------------------+ :
| |
: Ciphertext Domain ;
_.------------.
,--'' Plaintext Domain--.
,-' +--------+ +--------+ `-.
,' | Host | | Host | `.
,' +--------+ +--------+ `.
; :
| +----------------------+ |
: | +--------+ | |
`. | | Router | | ,'
`. | +---+----+ | ,'
`- | +----------+ | ,'
---| +-+--+ +-+--+--+ |'
|----|E/D |--|Net Grd| | VPN Router
,-'| +-+--+ +-+--+--+ |\
, | +----------+ | \
,' | +---+----+ | `.
,' | | Router | | |
/ | +--------+ | \
; +----------------------+ :
| |
: Ciphertext Domain ;
Figure 8: RSVP Passage via Network Guard
图8：通过网络防护的RSVP通道
In this context, the VPN router is composed of a plaintext router, a ciphertext router, an encrypt/decrypt implementation (such as a line card or interface device), and a network management process that manages the encrypt/decrypt implementation and potentially passes defined information flows between the plaintext and ciphertext domains. If the Network Guard is implemented as a software process that exchanges configuration instructions between the routers, this is simple to understand. If it is built as a separate systems exchanging datagrams, it is somewhat more complex, but conceptually equivalent. For example, the ciphertext router would consider an IP datagram received via the Network Guard (control plane) as having been received from and concerning the interface used in the data plane to the encrypt/decrypt unit.
在此上下文中，VPN路由器由明文路由器、密文路由器、加密/解密实现（例如线路卡或接口设备）和网络管理过程组成，该网络管理过程管理加密/解密实现并可能在明文域和密文域之间传递定义的信息流。如果Network Guard是作为在路由器之间交换配置指令的软件过程实现的，那么这很容易理解。如果将它构建为一个单独的系统来交换数据报，那么它会稍微复杂一些，但在概念上是等效的。例如，密文路由器将考虑通过网络保护（控制平面）接收的IP数据报，作为从数据平面中使用的接口和接收到加密/解密单元的接口。
Encrypt/decrypt units may not be capable of terminating and originating flows as described in Section 3.1, and policy may prevent knowledge of the ciphertext network addresses in the plaintext router. In such a case, the plaintext and ciphertext routers may use the Network Guard as the path for the signaling flows. The Network Guard performs the following functions to enable the flow of reservation signaling across the cryptographic domain
加密/解密单元可能无法终止和发起第3.1节所述的流，并且策略可能会阻止在明文路由器中知道密文网络地址。在这种情况下，明文和密文路由器可以使用网络保护作为信令流的路径。Network Guard执行以下功能，以启用跨加密域的保留信令流
o transforms plaintext session identifiers into ciphertext session identifiers and vice-versa in IP datagrams and RSVP objects (e.g. IP addresses)
o 将IP数据报和RSVP对象（例如IP地址）中的明文会话标识符转换为密文会话标识符，反之亦然
o performs resource management of aggregated reservations (e.g., including ciphertext encapsulation overhead to resources requested)
o 执行聚合保留的资源管理（例如，包括请求资源的密文封装开销）
o reads and writes configuration on the encrypt/decrypt units as necessary (e.g., reads plaintext to ciphertext IP address mapping)
o 根据需要读取和写入加密/解密单元上的配置（例如，读取明文到密文IP地址映射）
In addition, the plaintext and ciphertext routers must support a routing function or local interface that ensures that aggregated RSVP messages flow via the Network Guard. However, the signaling flow across the entire VPN router at a cryptographic boundary remains identical to the description in Section 3.1.
此外，明文和密文路由器必须支持路由功能或本地接口，以确保聚合的RSVP消息通过网络保护。然而，在加密边界处通过整个VPN路由器的信令流仍然与第3.1节中的描述相同。
A reader may note that the VPN router described in Figure 8 can be collapsed into a single router with two halves, or the Network Guard and the encrypt/decrypt units can be part of the plaintext router. The details of alternate logical and physical architectures for the VPN router are beyond the scope of this document.
读者可能会注意到，图8中描述的VPN路由器可以折叠成一个有两半的路由器，或者网络守卫和加密/解密单元可以是明文路由器的一部分。VPN路由器的备用逻辑和物理架构的详细信息超出了本文档的范围。
........................................
: VPN Router A :
: :
:+-----------++----------++-----------+:
+------+ RSVP :| || NetGrd-A || |:
|Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+------+ :| || E/D-A || |: ::
:+-----------++----------++-----------+: ::
: A-RSVP : ::
: <:::::::::::::> : ::
:......................................: ::
A-RSVP ::
,---.
,' `.
/ \
; Interface :
| Domain |
: ;
\ /
`. ,'
'---'
A-RSVP ::
........................................ ::
: VPN Router B : ::
: : ::
:+-----------++----------++-----------+: ::
+------+ RSVP :| || NetGrd-B || |: ::
|Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+------+ :| || E/D-B || |:
:+-----------++----------++-----------+:
: A-RSVP :
: <:::::::::::::> :
:......................................:
........................................
: VPN Router A :
: :
:+-----------++----------++-----------+:
+------+ RSVP :| || NetGrd-A || |:
|Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+------+ :| || E/D-A || |: ::
:+-----------++----------++-----------+: ::
: A-RSVP : ::
: <:::::::::::::> : ::
:......................................: ::
A-RSVP ::
,---.
,' `.
/ \
; Interface :
| Domain |
: ;
\ /
`. ,'
'---'
A-RSVP ::
........................................ ::
: VPN Router B : ::
: : ::
:+-----------++----------++-----------+: ::
+------+ RSVP :| || NetGrd-B || |: ::
|Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+------+ :| || E/D-B || |:
:+-----------++----------++-----------+:
: A-RSVP :
: <:::::::::::::> :
:......................................:
Figure 9: Aggregated RSVP via Network Guard
图9：通过网络保护聚合的RSVP
The above figure depicts a simple use case for aggregated signaling with the Network Guard. In this scenario, Host A initiates RSVP signaling to Host B for a reservation. The RSVP signaling between the hosts is encapsulated by the VPN routers into encrypted tunnels. Aggregated RSVP signaling is triggered by VPN routers, and flows into the CT-Routers, as well as the interface domains, to reserve resources at RSVP-capable routers on the path. The aggregation/ deaggregation point for RSVP reservations in this use case are the PT-Routers. The signaling aggregation of RSVP into A-RSVP at the PT-Router is similar to the data flow described in Section 3.1. The
上图描述了使用网络保护进行聚合信令的简单用例。在这种情况下，主机A向主机B发出RSVP信令以进行预订。主机之间的RSVP信令由VPN路由器封装到加密隧道中。聚合RSVP信令由VPN路由器触发，并流入CT路由器以及接口域，以在路径上支持RSVP的路由器上保留资源。在这个用例中，RSVP保留的聚合/解聚点是PT路由器。PT路由器上RSVP到A-RSVP的信令聚合类似于第3.1节中描述的数据流。这个
Network Guard performs the additional functions described in Section 3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext A-RSVP messages. A typical reservation set up in this case would follow these steps.
Network Guard执行第3.2.1节所述的附加功能，将明文A-RSVP消息转换为合适的密文A-RSVP消息。在这种情况下设置的典型预订将遵循以下步骤。
o Host A sends RSVP PATH message to Host B.
o 主机A向主机B发送RSVP路径消息。
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to VPN Router B.
o PT-Router-A将RSVP路径消息封装在到VPN路由器B的加密隧道中。
o CT Routers and Interface domain carry encrypted RSVP PATH message (like any other encrypted data message).
o CT路由器和接口域携带加密的RSVP路径消息（与任何其他加密数据消息一样）。
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr message to PT-Router-A in the encrypted tunnel.
o PT-Router-B对RSVP Path消息进行解密，并在加密隧道中将E2E PathErr消息发送给PT-Router-A。
o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host B.
o PT-Router-B将解密的明文RSVP路径消息转发给主机B。
o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH message towards PT-Router-B via the Network Guard.
o PT-Router-A接收E2E PathErr并通过网络保护向PT-Router-B发送聚合RSVP路径消息。
o The NetGrd-A transforms the plaintext aggregate RSVP into the ciphertext aggregate RSVP message as described in Section 3.2.1 and sends it to the CT-Router-A.
o NetGrd-A将明文聚合RSVP转换为第3.2.1节所述的密文聚合RSVP消息，并将其发送至CT-Router-A。
o The ciphertext aggregated RSVP message travels through ciphertext routers in the interface domain.
o 密文聚合RSVP消息通过接口域中的密文路由器传输。
o CT-Router-B receives the ciphertext aggregate RSVP message and sends it to the NetGrd-B.
o CT-Router-B接收密文聚合RSVP消息并将其发送给NetGrd-B。
o The NetGrd-B transforms the ciphertext aggregate RSVP into the plaintext aggregate RSVP message as described in Section 3.2.1 and sends it to the PT-Router-B.
o NetGrd-B将密文聚合RSVP转换为第3.2.1节所述的明文聚合RSVP消息，并将其发送至PT-Router-B。
The subsequent RSVP and Aggregate RSVP signaling follows a similar flow, as described in detail in [RFC3175] and [RFC4860]to aggregate each plaintext reservation into a corresponding ciphertext reservation. This ensures that RSVP-capable ciphertext routers reserve the required resources for a plaintext end-to-end reservation. Subsequent mechanisms, such as preemption or the increase and decrease of resources reserved, may be applied to these reservations as described before in this document. The RSVP data flow as described in Section 3.1 within the VPN router (from the plaintext router to the ciphertext router via the Guard) provides necessary and sufficient information to routers in the ciphertext domain to implement the QoS solution presented in the document.
随后的RSVP和聚合RSVP信令遵循类似的流程，如[RFC3175]和[RFC4860]中详细描述的，以将每个明文保留聚合为相应的密文保留。这确保支持RSVP的密文路由器为明文端到端保留所需的资源。后续机制，如抢占或保留资源的增加和减少，可适用于本文件前面所述的这些保留。VPN路由器内第3.1节所述的RSVP数据流（通过Guard从明文路由器到密文路由器）为密文域中的路由器提供必要和充分的信息，以实现文件中提出的QoS解决方案。
In this description, we have described the Network Guard as being separate from the encrypt/decrypt unit. This separation exists because in certain implementations, it is mandated by those who specify the devices. The separation does not come for free, however; the separation of the devices for system-engineering purposes is expensive, and it imposes architectural problems. For example, when the Guard is used to aggregate RSVP messages or Protocol Independent Multicast (PIM) routing, the traffic is destined to the remote VPN router. This means that the Guard must somehow receive and respond to, on behalf of the VPN Router, messages that are not directed to it. Several possible solutions exist; they should be selected carefully based on the security and implementation needs of the environment. They are as follows:
在此描述中，我们将网络保护描述为与加密/解密单元分离。这种分离的存在是因为在某些实现中，它是由指定设备的人强制执行的。然而，分离并不是免费的；为了系统工程的目的而分离设备是昂贵的，并且会带来架构问题。例如，当Guard用于聚合RSVP消息或协议独立多播（PIM）路由时，流量将发送到远程VPN路由器。这意味着警卫必须以某种方式代表VPN路由器接收和响应未定向到它的消息。存在几种可能的解决办法；应根据环境的安全性和实现需要仔细选择它们。详情如下:
o In the simplest case, the Network Guard and encrypt/decrypt unit can be two independent functions that utilize a common network and MAC layer. This can allow the two functions to share a common MAC and IP address, so that traffic destined for one function is also received by the other. In the case that these two functions are physically separated on two devices, they can still share a common MAC and IP address; however, additional modifications may be required on the Guard to filter and not process IP traffic not destined for itself.
o 在最简单的情况下，网络保护和加密/解密单元可以是利用公共网络和MAC层的两个独立功能。这可以允许两个功能共享一个共同的MAC和IP地址，以便为一个功能发送的流量也被另一个功能接收。在这两个功能在两个设备上物理分离的情况下，它们仍然可以共享一个共同的MAC和IP地址；然而，可能需要在防护装置上进行额外的修改，以过滤而不是处理非目的地为自身的IP流量。
o The ciphertext interface of the Guard could be placed into promiscuous mode, allowing it to receive all messages and discard all but the few it is interested in. The security considerations on putting a device in promiscuous mode at the VPN boundary needs to be taken into account in this method.
o Guard的密文接口可以设置为混杂模式，允许它接收所有消息，并丢弃除感兴趣的少数消息外的所有消息。在这种方法中，需要考虑在VPN边界将设备置于混杂模式的安全考虑。
o The Guard could be engineered to receive all from the ciphertext router and pass the bulk of it on to the VPN router through another interface. In this case, the Guard and the VPN router would use the same IP address. This mechanism puts the load of all data and management traffic destined for the VPN router upon the Guard.
o 防护装置可以设计成接收来自密文路由器的所有信息，并通过另一个接口将大部分信息传递给VPN路由器。在这种情况下，警卫和VPN路由器将使用相同的IP地址。该机制将所有发送到VPN路由器的数据和管理流量的负载置于防护装置上。
o The VPN router could be engineered to receive all traffic from the ciphertext router and pass any unencrypted traffic it receives to the Guard through another interface. In this case, the Guard and the VPN router would use the same IP address.
o VPN路由器可以设计为接收来自密文路由器的所有流量，并通过另一个接口将其接收到的任何未加密流量传递给警卫。在这种情况下，警卫和VPN路由器将使用相同的IP地址。
o All the VPN router functions, as shown in Figure 9, could be incorporated into a single chassis, with appropriate internal traffic management to send some traffic into the plaintext enclave and some to the Guard. In this case, the Guard and the VPN router would be -- at least, functionally -- the same system.
o 如图9所示，所有VPN路由器功能都可以整合到一个机箱中，通过适当的内部流量管理，将一些流量发送到明文飞地，另一些发送到警卫。在这种情况下，警卫和VPN路由器至少在功能上是相同的系统。
Of these, clearly the last is the simplest architecturally and the one that most minimizes the attendant risk.
其中，最后一个显然是最简单的架构，也是最大限度地降低伴随风险的架构。
The typical security concerns of datagram integrity, node and user authentication are implicitly met by the security association that exists between the VPN routers. The secure data stream that flows between the VPN routers is also used for the reservation signaling datagrams flowing between VPN routers. Information that is contained in these signaling datagrams receives the same level of encryption that is received by the data streams.
VPN路由器之间存在的安全关联隐式地满足了数据报完整性、节点和用户身份验证的典型安全问题。在VPN路由器之间流动的安全数据流也用于在VPN路由器之间流动的预约信令数据报。这些信令数据报中包含的信息接收的加密级别与数据流接收的加密级别相同。
One of the reasons cited for the nesting of VPN routes in Section 1.3 is the different levels of security across the nested VPN routers. If the security level decreases from one VPN router to the next VPN Router in the nested path, the reservation signaling datagrams will, by default, receive the lower security-level treatment. For most cases, the lower security treatment is acceptable. In certain networks, however, the reservation signaling across the entire nested path must receive the highest security-level treatment (e.g., encryption, authentication of signaling nodes). For example, the highest precedence level may only be signaled to VPN routers that can provide the highest security levels. If any VPN router in the nested path is incapable of providing the highest security level, it cannot participate in the reservation mechanism.
第1.3节中提到的VPN路由嵌套的原因之一是嵌套VPN路由器的安全级别不同。如果安全级别从一个VPN路由器降低到嵌套路径中的下一个VPN路由器，则默认情况下，保留信令数据报将接受较低的安全级别处理。在大多数情况下，较低安全性的处理是可以接受的。然而，在某些网络中，整个嵌套路径上的保留信令必须接受最高安全级别的处理（例如，加密、信令节点的身份验证）。例如，最高优先级别可能仅发信号给能够提供最高安全级别的VPN路由器。如果嵌套路径中的任何VPN路由器无法提供最高安全级别，则它无法参与保留机制。
In the general case, the nested path may contain routers that are either incapable of participating in VPNs or providing required security levels. These routers can participate in the reservation only if the lower security level is acceptable (as configured by policy) for the signaling of reservation datagrams.
在一般情况下，嵌套路径可能包含无法参与VPN或提供所需安全级别的路由器。这些路由器只有在较低的安全级别可接受（由策略配置）用于预留数据报的信令时才能参与预留。
VPN routers encapsulate encrypted IP packets and prepend an extra header on each packet. These packets, whether used for signaling or data, should be identifiable, at a minimum by the IP addresses and DSCP value. Therefore, the prepended header should contain, at a minimum, the DSCP value corresponding to the signaled reservation in each packet. This may literally be the same DSCP as is used for the data (forcing control plane traffic to receive the same QoS treatment as its data), or a different DSCP that is routed identically (separating control and data-plane traffic QoS but not routing).
VPN路由器封装加密的IP数据包，并在每个数据包上预加一个额外的报头。这些数据包，无论是用于信令还是数据，至少应通过IP地址和DSCP值进行识别。因此，前置报头应至少包含与每个数据包中的信号预留相对应的DSCP值。这实际上可能是用于数据的相同DSCP（强制控制平面流量接收与其数据相同的QoS处理），或者是相同路由的不同DSCP（分离控制平面和数据平面流量QoS，但不路由）。
Additionally security considerations as described in [RFC4860] and [RFC3175] are also applicable in this environment; they include the integrity of RSVP messages can be ensured via mechanisms described in [RFC2747] and [RFC3097] and related key management (through manual configuration or a key management protocol) at nodes between any
此外，[RFC4860]和[RFC3175]中所述的安全注意事项也适用于此环境；它们包括可通过[RFC2747]和[RFC3097]中所述的机制以及在任何节点之间的相关密钥管理（通过手动配置或密钥管理协议）确保RSVP消息的完整性
aggregator and deaggregator pair that processes the messages. In addition, confidentiality can be provided between hops by employing IPsec. Further work in the IETF MSEC Working Group may be applicable in these environments for key management and confidentiality.
处理消息的聚合器和反聚合器对。此外，可以通过使用IPsec在跃点之间提供机密性。IETF MSEC工作组的进一步工作可能适用于这些环境中的密钥管理和保密。
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger Levesque, and Subha Dhesikan gave early review comments.
道格·马奎斯、詹姆斯·波尔克、迈克·蒂博多、皮特·巴本德雷尔、罗杰·列夫斯克和苏巴·德西坎在早期评论中发表了评论。
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou, and their associates resulted in Section 3.2.
Sean O'Keefe、Tony De Simone、Julie Tarr、Chris Christou及其同事的评论导致了第3.2节。
Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik Bose) added [RFC4860], which clarified the interaction of this approach with the DSCP.
Francois Le Faucheur、Bruce Davie和Chris Christou（与Pratik Bose一起）添加了[RFC4860]，阐明了这种方法与DSCP的相互作用。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996]Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4495]Polk，J.和S.Dhesikan，“减少预留流带宽的资源预留协议（RSVP）扩展”，RFC 4495，2006年5月。
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4542]Baker，F.和J.Polk，“在互联网协议套件中为实时服务实施紧急电信服务（ETS）”，RFC 4542，2006年5月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用聚合资源预留协议（RSVP）预留”，RFC 48602007年5月。
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel Precedence and Preemption Service", ITU-T Recommendation I.255.3, 1990.
[ITU.MLPP.1990]国际电信联盟，“多级优先和抢占服务”，ITU-T建议I.255.3，1990年。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]Braden，B.和L.Zhang，“资源预留协议（RSVP）——第1版消息处理规则”，RFC 2209，1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000.
[RFC2872]Bernet，Y.和R.Pabbati，“与RSVP一起使用的应用程序和子应用程序标识策略元素”，RFC 2872，2000年6月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 3474, March 2003.
[RFC3474]Lin，Z.和D.Pendarakis，“通用多协议标签交换（GMPLS）资源预留协议的IANA分配文件-自动交换光网络（ASON）的流量工程（RSVP-TE）使用和扩展”，RFC 3474，2003年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
Authors' Addresses
作者地址
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave Gaithersburg, Maryland 20871 USA
Pratik Bose洛克希德马丁700美国马里兰州盖瑟斯堡北弗雷德里克大街20871
Phone: +1-301-240-7041
Fax: +1-301-240-5748
EMail: pratik.bose@lmco.com
Phone: +1-301-240-7041
Fax: +1-301-240-5748
EMail: pratik.bose@lmco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。