Internet Engineering Task Force (IETF) B. Davie
Request for Comments: 6016 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco Systems, Inc.
October 2010
Internet Engineering Task Force (IETF) B. Davie
Request for Comments: 6016 F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco Systems, Inc.
October 2010
Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
支持第3层VPN中的资源预留协议（RSVP）
Abstract
摘要
RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported.
RFC 4364和RFC 4659定义了一种为IPv4和IPv6构建提供商提供的第3层VPN（L3VPN）的方法。可能希望使用资源预留协议（RSVP）在客户边缘（CE）路由器和提供商边缘（PE）路由器之间的链路上执行接纳控制。本文件规定了通过L3VPN从CE到CE传输的RSVP消息可由PE路由器适当处理的程序，以便可在PE-CE链路上执行准入控制。可选地，还可以支持跨提供商主干的准入控制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6016.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6016.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Model of Operation .........................................8
3. Admission Control on PE-CE Links ................................9
3.1. New Objects of Type VPN-IPv4 ...............................9
3.2. Path Message Processing at Ingress PE .....................11
3.3. Path Message Processing at Egress PE ......................12
3.4. Resv Processing at Egress PE ..............................13
3.5. Resv Processing at Ingress PE .............................13
3.6. Other RSVP Messages .......................................14
4. Admission Control in Provider's Backbone .......................14
5. Inter-AS Operation .............................................15
5.1. Inter-AS Option A .........................................15
5.2. Inter-AS Option B .........................................15
5.2.1. Admission Control on ASBR ..........................16
5.2.2. No Admission Control on ASBR .......................16
5.3. Inter-AS Option C .........................................17
6. Operation with RSVP Disabled ...................................17
7. Other RSVP Procedures ..........................................18
7.1. Refresh Overhead Reduction ................................18
7.2. Cryptographic Authentication ..............................18
7.3. RSVP Aggregation ..........................................19
7.4. Support for CE-CE RSVP-TE .................................19
8. Object Definitions .............................................20
8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................20
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............21
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................22
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................22
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE Objects ...................................26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
FILTER_SPEC Objects .......................................27
9. IANA Considerations ............................................28
10. Security Considerations .......................................30
11. Acknowledgments ...............................................33
Appendix A. Alternatives Considered .............................34
A.1. GMPLS UNI Approach ........................................34
A.2. Label Switching Approach ..................................34
A.3. VRF Label Approach ........................................34
A.4. VRF Label Plus VRF Address Approach .......................35
References ........................................................35
Normative References ...........................................35
Informative References .........................................36
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Model of Operation .........................................8
3. Admission Control on PE-CE Links ................................9
3.1. New Objects of Type VPN-IPv4 ...............................9
3.2. Path Message Processing at Ingress PE .....................11
3.3. Path Message Processing at Egress PE ......................12
3.4. Resv Processing at Egress PE ..............................13
3.5. Resv Processing at Ingress PE .............................13
3.6. Other RSVP Messages .......................................14
4. Admission Control in Provider's Backbone .......................14
5. Inter-AS Operation .............................................15
5.1. Inter-AS Option A .........................................15
5.2. Inter-AS Option B .........................................15
5.2.1. Admission Control on ASBR ..........................16
5.2.2. No Admission Control on ASBR .......................16
5.3. Inter-AS Option C .........................................17
6. Operation with RSVP Disabled ...................................17
7. Other RSVP Procedures ..........................................18
7.1. Refresh Overhead Reduction ................................18
7.2. Cryptographic Authentication ..............................18
7.3. RSVP Aggregation ..........................................19
7.4. Support for CE-CE RSVP-TE .................................19
8. Object Definitions .............................................20
8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................20
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............21
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................22
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................22
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE Objects ...................................26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
FILTER_SPEC Objects .......................................27
9. IANA Considerations ............................................28
10. Security Considerations .......................................30
11. Acknowledgments ...............................................33
Appendix A. Alternatives Considered .............................34
A.1. GMPLS UNI Approach ........................................34
A.2. Label Switching Approach ..................................34
A.3. VRF Label Approach ........................................34
A.4. VRF Label Plus VRF Address Approach .......................35
References ........................................................35
Normative References ...........................................35
Informative References .........................................36
[RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ MPLS VPNs for IPv4 and for IPv6, respectively. [RFC2205] defines the Resource Reservation Protocol (RSVP), which may be used to perform admission control as part of the Integrated Services (Int-Serv) architecture [RFC1633][RFC2210].
[RFC4364]和[RFC4659]分别为IPv4和IPv6定义了称为BGP/MPLS VPN的第3层VPN服务。[RFC2205]定义了资源预留协议（RSVP），该协议可用于作为集成服务（Int Serv）体系结构的一部分执行准入控制[RFC1633][RFC2210]。
Customers of a Layer 3 VPN service may run RSVP for the purposes of admission control (and associated resource reservation) in their own networks. Since the links between Provider Edge (PE) and Customer Edge (CE) routers in a Layer 3 VPN may often be resource constrained, it may be desirable to be able to perform admission control over those links. In order to perform admission control using RSVP in such an environment, it is necessary that RSVP control messages, such as Path messages and Resv messages, are appropriately handled by the PE routers. This presents a number of challenges in the context of BGP/MPLS VPNs:
第3层VPN服务的客户可以在其自己的网络中运行RSVP以进行准入控制（和相关资源保留）。由于第3层VPN中的提供商边缘（PE）和客户边缘（CE）路由器之间的链路通常可能是资源受限的，因此可能希望能够对这些链路执行准入控制。为了在这样的环境中使用RSVP执行接纳控制，有必要由PE路由器适当地处理RSVP控制消息，例如路径消息和Resv消息。这在BGP/MPLS VPN环境中提出了许多挑战：
o RSVP Path message processing depends on routers recognizing the Router Alert Option ([RFC2113], [RFC2711]) in the IP header. However, packets traversing the backbone of a BGP/MPLS VPN are MPLS encapsulated, and thus the Router Alert Option may not be visible to the egress PE due to implementation or policy considerations (e.g., if the egress PE processes the message as "pop and go" without examining the IP header).
o RSVP路径消息处理取决于路由器识别IP报头中的路由器警报选项（[RFC2113]、[RFC2711]）。然而，通过BGP/mplsvpn主干的分组是MPLS封装的，因此，由于实施或策略考虑（例如，如果出口PE将消息处理为“pop-and-go”而不检查IP报头），出口PE可能看不到路由器警报选项。
o BGP/MPLS VPNs support non-unique addressing of customer networks. Thus, a PE at the ingress or egress of the provider backbone may be called upon to process Path messages from different customer VPNs with non-unique destination addresses within the RSVP message. Current mechanisms for identifying customer context from data packets are incompatible with RSVP message processing rules.
o BGP/MPLS VPN支持客户网络的非唯一寻址。因此，可以调用提供商主干网入口或出口处的PE来处理来自RSVP消息内具有非唯一目的地地址的不同客户vpn的路径消息。当前用于从数据包中识别客户上下文的机制与RSVP消息处理规则不兼容。
o A PE at the ingress of the provider's backbone may receive Resv messages corresponding to different customer VPNs from other PEs, and needs to be able to associate those Resv messages with the appropriate customer VPNs.
o 位于提供商主干网入口的PE可以从其他PE接收对应于不同客户VPN的Resv消息，并且需要能够将这些Resv消息与适当的客户VPN相关联。
Further discussion of these issues is presented in Section 2.
关于这些问题的进一步讨论见第2节。
This document describes a set of procedures to overcome these challenges and thus to enable admission control using RSVP over the PE-CE links. We note that similar techniques may be applicable to other protocols used for admission control such as the combination of the NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service (QoS) Signaling [RFC5974] and General Internet Signaling Transport (GIST) protocol [RFC5971].
本文件描述了一组克服这些挑战的程序，从而通过PE-CE链路使用RSVP实现准入控制。我们注意到，类似技术可适用于用于接纳控制的其他协议，例如用于服务质量（QoS）信令的NSIS信令层协议（NSLP）[RFC5974]和通用因特网信令传输（GIST）协议[RFC5971]的组合。
Additionally, it may be desirable to perform admission control over the provider's backbone on behalf of one or more L3VPN customers. Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for customer routes, and thus they cannot natively process RSVP messages for customer flows. Also, the core is a shared resource that carries traffic for many customers, so issues of resource allocation among customers and trust (or lack thereof) also ought to be addressed. This document specifies procedures for supporting such a scenario.
此外，可能希望代表一个或多个L3VPN客户对提供商的主干网执行准入控制。BGP/MPLS VPN中的核心（P）路由器没有客户路由的转发条目，因此它们无法在本机上处理客户流的RSVP消息。此外，核心是一个为许多客户提供流量的共享资源，因此客户之间的资源分配和信任（或缺乏信任）问题也应该得到解决。本文件规定了支持此类方案的程序。
This document deals with establishing reservations for unicast flows only. Because the support of multicast traffic in BGP/MPLS VPNs is still evolving, and raises additional challenges for admission control, we leave the support of multicast flows for further study at this point.
本文档仅涉及为单播流建立保留。由于BGP/MPLS VPN中对多播流量的支持仍在不断发展，并对接纳控制提出了额外的挑战，因此我们将多播流的支持留到目前进一步研究。
This document draws freely on the terminology defined in [RFC2205] and [RFC4364]. For convenience, we provide a few brief definitions here:
本文件自由引用了[RFC2205]和[RFC4364]中定义的术语。为了方便起见，我们在这里提供了一些简短的定义：
o Customer Edge (CE) Router: Router at the edge of a customer site that attaches to the network of the VPN provider.
o 客户边缘（CE）路由器：连接到VPN提供商网络的客户站点边缘的路由器。
o Provider Edge (PE) Router: Router at the edge of the service provider's network that attaches to one or more customer sites.
o 提供商边缘（PE）路由器：连接到一个或多个客户站点的服务提供商网络边缘的路由器。
o VPN Label: An MPLS label associated with a route to a customer prefix in a VPN (also called a VPN route label).
o VPN标签：与VPN中客户前缀的路由相关联的MPLS标签（也称为VPN路由标签）。
o VPN Routing and Forwarding (VRF) Table: A PE typically has multiple VRFs, enabling it to be connected to CEs that are in different VPNs.
o VPN路由和转发（VRF）表：一个PE通常有多个VRF，使其能够连接到不同VPN中的CE。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The problem space of this document is the support of admission control between customer sites when the customer subscribes to a BGP/ MPLS VPN. We subdivide the problem into (a) the problem of admission control on the PE-CE links (in both directions) and (b) the problem of admission control across the provider's backbone.
本文档的问题在于，当客户订阅BGP/MPLS VPN时，支持客户站点之间的准入控制。我们将问题细分为（a）PE-CE链路（双向）上的准入控制问题和（b）跨提供商主干的准入控制问题。
RSVP Path messages are normally addressed to the destination of a session, and contain the Router Alert Option (RAO) within the IP header. Routers along the path to the destination that are configured to process RSVP messages need to detect the presence of the RAO to allow them to intercept Path messages. However, the egress PEs of a network supporting BGP/MPLS VPNs receive packets destined for customer sites as MPLS-encapsulated packets, and they possibly forward those based only on examination of the MPLS label. In order to process RSVP Path messages, the egress VPN PE would have to pop the VPN label and examine the IP header underneath, before forwarding the packet (based on the VPN label disposition rules), which is not a requirement for data packet processing today. Hence, a Path message would be forwarded without examination of the IP options and would therefore not receive appropriate processing at the PE. Another potential issue is doing Connection Admission Control (CAC) at an Autonomous System Border Router (ASBR). Even an implementation that examines the IP header when removing the VPN label (e.g., PE-CE link) would not be able to do CAC at an Option-B ASBR; that requires examining the (interior) IP header while doing a label swap, which is much less desirable behavior.
RSVP路径消息通常发往会话的目标，并在IP报头中包含路由器警报选项（RAO）。配置为处理RSVP消息的目的地路径上的路由器需要检测RAO的存在，以允许它们拦截路径消息。然而，支持BGP/MPLS VPN的网络的出口PE接收作为MPLS封装的分组发送到客户站点的分组，并且它们可能仅基于对MPLS标签的检查来转发这些分组。为了处理RSVP路径消息，出口VPN PE必须在转发数据包之前弹出VPN标签并检查下面的IP报头（基于VPN标签配置规则），这在今天的数据包处理中不是必需的。因此，路径消息将在不检查IP选项的情况下转发，因此不会在PE处接收适当的处理。另一个潜在问题是在自治系统边界路由器（ASBR）上执行连接允许控制（CAC）。即使在移除VPN标签（例如PE-CE链路）时检查IP报头的实现也无法在选项B ASBR中执行CAC；这需要在进行标签交换时检查（内部）IP头，这是一种不太理想的行为。
In general, there are significant issues with requiring support for IP Router Alert outside of a controlled, "walled-garden" network, as described in [ALERT-USAGE]. The case of a MPLS L3VPN falls under the "Overlay Model" described therein. Fundamental to this model is that providers would seek to eliminate the requirement to process RAO-marked packets from customers, on any routers except the PEs facing those customers. Issues with requiring interior MPLS routers to process RAO-marked packets are also described in [LER-OPTIONS]. The approach for RSVP packet handling described in this document has the advantage of being independent of any data-plane requirements such as IP Router Alert support within the VPN or examining any IP options for MPLS-encapsulated packets. The only requirement for processing IP Router Alert packets is for RSVP packets received from the CE, which do not carry any MPLS encapsulation.
一般来说，需要在受控“围墙花园”网络之外支持IP路由器警报存在重大问题，如[Alert-USAGE]中所述。MPLS L3VPN的情况属于其中描述的“覆盖模型”。该模型的基础是，提供商将寻求消除在任何路由器上处理来自客户的带有RAO标记的数据包的要求，但面向这些客户的PEs除外。[LER-OPTIONS]中还描述了要求内部MPLS路由器处理RAO标记数据包的问题。本文档中描述的RSVP数据包处理方法的优点是独立于任何数据平面要求，如VPN内的IP路由器警报支持或检查MPLS封装数据包的任何IP选项。处理IP路由器警报数据包的唯一要求是从CE接收的RSVP数据包，它不携带任何MPLS封装。
For the PE-CE link subproblem, the most basic challenge is that RSVP control messages contain IP addresses that are drawn from the customer's address space, and PEs need to deal with traffic from many customers who may have non-unique (or overlapping) address spaces. Thus, it is essential that a PE be able, in all cases, to identify the correct VPN context in which to process an RSVP control message. The current mechanism for identifying the customer context is the VPN label, which is carried in an MPLS header outside of the RSVP message. This is divergent from the general RSVP model of session identification ([RFC2205], [RFC2209]), which relies solely on RSVP objects to identify sessions. Further, it is incompatible with protocols like COPS/RSVP (Common Open Policy Service) ([RFC2748],
对于PE-CE链路子问题，最基本的挑战是RSVP控制消息包含从客户地址空间提取的IP地址，PEs需要处理来自可能具有非唯一（或重叠）地址空间的许多客户的流量。因此，PE在所有情况下都必须能够识别正确的VPN上下文，以便在其中处理RSVP控制消息。当前用于标识客户上下文的机制是VPN标签，该标签在RSVP消息之外的MPLS报头中携带。这与会话标识的一般RSVP模型（[RFC2205]、[RFC2209]）不同，后者仅依赖RSVP对象来标识会话。此外，它与COPS/RSVP（公共开放策略服务）（[RFC2748]）等协议不兼容，
[RFC2749]), which replace the IP encapsulation of the RSVP message and send only RSVP objects to a COPS server. We believe it is important to retain the model of completely identifying an RSVP session from the contents of RSVP objects. Much of this document deals with this issue.
[RFC2749]），它取代了RSVP消息的IP封装，只向COPS服务器发送RSVP对象。我们认为，保留从RSVP对象内容中完全识别RSVP会话的模型非常重要。本文件的大部分内容都涉及这一问题。
For the case of making reservations across the provider backbone, we observe that BGP/MPLS VPNs do not create any per-customer forwarding state in the P (provider core) routers. Thus, in order to make reservations on behalf of customer-specified flows, it is clearly necessary to make some sort of aggregated reservation from PE-PE and then map individual, customer-specific reservations onto an aggregate reservation. That is similar to the problem tackled in [RFC3175] and [RFC4804], with the additional complications of handling customer-specific addressing associated with BGP/MPLS VPNs.
对于跨提供商主干网进行预订的情况，我们观察到BGP/MPLS VPN不会在P（提供商核心）路由器中创建任何每客户转发状态。因此，为了代表客户指定的流进行预订，显然有必要从PE-PE进行某种聚合预订，然后将特定于客户的单个预订映射到聚合预订上。这与[RFC3175]和[RFC4804]中解决的问题类似，但处理与BGP/MPLS VPN相关的特定于客户的寻址会带来额外的复杂性。
Consider the case where an MPLS VPN customer uses RSVP signaling across his sites for resource reservation and admission control. Let's further assume that, initially, RSVP is not processed through the MPLS VPN cloud (i.e., RSVP messages from the sender to the receiver travel transparently from CE to CE). In that case, RSVP allows the establishment of resource reservations and admission control on a subset of the flow path (from sender to ingress CE, and from the RSVP router downstream of the egress CE to the receiver). If admission control is then activated on any of the CE-PE link, the provider's backbone, or PE-CE link (as allowed by the present document), the customer will benefit from an extended coverage of admission control and resource reservation: the resource reservation will now span over a bigger subset of (and possibly the whole) flow path, which in turn will increase the QoS granted to the corresponding flow. Specific flows whose reservation is successful through admission control on the newly enabled segments will indeed benefit from this quality of service enhancement. However, it must be noted that, in case there are not enough resources on one (or more) of the newly enabled segments (e.g., say admission control is enabled on a given PE-->CE link and there is not enough capacity on that link to admit all reservations for all the flows traversing that link), then some flows will not be able to maintain, or establish, their reservation. While this may appear undesirable for these flows, we observe that this only occurs if there is indeed a lack of capacity on a segment, and that in the absence of admission control, all flows would be established but would all suffer from the resulting congestion on the bottleneck segment. We also observe that, in the case of such a lack of capacity, admission control allows enforcement of controlled and flexible policies (so that, for example, more important flows can be granted higher priority at
考虑MPLS VPN客户在其网站上使用RSVP信令进行资源预留和接纳控制的情况。让我们进一步假设，最初，RSVP不是通过MPLS VPN云处理的（即，从发送方到接收方的RSVP消息从CE透明地传输到CE）。在这种情况下，RSVP允许在流路径的子集（从发送方到入口CE，以及从出口下游的RSVP路由器到接收方）上建立资源预留和接纳控制。如果随后在任何CE-PE链路、提供商主干网或PE-CE链路（如本文件所允许）上激活准入控制，则客户将受益于准入控制和资源预留的扩展覆盖范围：资源预留现在将跨越更大的流径子集（可能是整个流径），这反过来将增加授予相应流的QoS。通过对新启用的段进行准入控制而成功保留的特定流确实将受益于这种服务质量增强。但是，必须注意的是，如果在一个（或多个）新启用的段上没有足够的资源（例如，假设在给定的PE-->CE链路上启用了准入控制，并且该链路上没有足够的容量来允许对通过该链路的所有流的所有保留），则某些流将无法维护，或者建立他们的保留。虽然这可能对这些流来说是不可取的，但我们观察到，只有当某个网段上确实缺乏容量时，才会发生这种情况，并且在没有准入控制的情况下，所有流都会建立起来，但所有流都会在瓶颈网段上遭受由此产生的拥塞。我们还注意到，在这种能力不足的情况下，准入控制允许实施受控和灵活的政策（例如，更重要的流量可以在更高的级别获得更高的优先级）
reserving resources). We note also that flows are given a chance to establish smaller reservations so that the aggregate load can adapt dynamically to the bottleneck capacity.
保留资源）。我们还注意到，流有机会建立较小的保留，以便聚合负载能够动态地适应瓶颈容量。
Figure 1 illustrates the basic model of operation with which this document is concerned.
图1说明了本文档涉及的基本操作模型。
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
Figure 1. Model of Operation for RSVP-Based Admission Control over MPLS/BGP VPN
图1。基于RSVP的MPLS/bgpvpn接入控制的操作模型
To establish a unidirectional reservation for a point-to-point flow from Sender to Receiver that takes account of resource availability on the CE-PE and PE-CE links only, the following steps need to take place:
要为从发送方到接收方的点到点流建立单向保留，仅考虑CE-PE和PE-CE链路上的资源可用性，需要执行以下步骤：
1. The Sender sends a Path message to an IP address of the Receiver.
1. 发送方向接收方的IP地址发送路径消息。
2. The Path message is processed by CE1 using normal RSVP procedures and forwarded towards the Receiver along the link CE1-PE1.
2. 路径消息由CE1使用正常的RSVP程序处理，并沿着链路CE1-PE1转发给接收机。
3. PE1 processes the Path message and forwards it towards the Receiver across the provider backbone.
3. PE1处理路径消息，并通过提供者主干将其转发给接收方。
4. PE2 processes the Path message and forwards it towards the Receiver along link PE2-CE2.
4. PE2处理路径消息，并沿链路PE2-CE2将其转发给接收器。
5. CE2 processes the Path message using normal RSVP procedures and forwards it towards the Receiver.
5. CE2使用正常的RSVP过程处理Path消息，并将其转发给接收方。
6. The Receiver sends a Resv message to CE2.
6. 接收器向CE2发送Resv消息。
7. CE2 sends the Resv message to PE2.
7. CE2向PE2发送Resv消息。
8. PE2 processes the Resv message (including performing admission control on link PE2-CE2) and sends the Resv message to PE1.
8. PE2处理Resv消息（包括在链路PE2-CE2上执行接纳控制）并将Resv消息发送给PE1。
9. PE1 processes the Resv message and sends the Resv message to CE1.
9. PE1处理Resv消息并将Resv消息发送给CE1。
10. CE1 processes the Resv message using normal RSVP procedures, performs admission control on the link CE1-PE1, and sends the Resv message to the Sender if successful.
10. CE1使用正常的RSVP过程处理Resv消息，在链路CE1-PE1上执行接纳控制，如果成功，则将Resv消息发送给发送方。
In each of the steps involving Resv messages (6 through 10) the node sending the Resv message uses the previously established Path state to determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to that address. We note that establishing that Path state correctly at PEs is one of the challenges posed by the BGP/MPLS environment.
在涉及Resv消息的每个步骤（6到10）中，发送Resv消息的节点使用先前建立的路径状态来确定“RSVP前一跳（PHOP）”并向该地址发送Resv消息。我们注意到，在PEs上正确建立路径状态是BGP/MPLS环境带来的挑战之一。
In the following sections, we trace through the steps outlined in Section 2.1 and expand on the details for those steps where standard RSVP procedures need to be extended or modified to support the BGP/ MPLS VPN environment. For all the remaining steps described in the preceding section, standard RSVP processing rules apply.
在以下各节中，我们将回顾第2.1节中概述的步骤，并详细介绍需要扩展或修改标准RSVP程序以支持BGP/MPLS VPN环境的步骤。对于上一节中描述的所有剩余步骤，标准RSVP处理规则适用。
All the procedures described below support both IPv4 and IPv6 addressing. In all cases where IPv4 is referenced, IPv6 can be substituted with identical procedures and results. Object definitions for both IPv4 and IPv6 are provided in Section 8.
下面描述的所有过程都支持IPv4和IPv6寻址。在引用IPv4的所有情况下，都可以用相同的过程和结果替换IPv6。第8节提供了IPv4和IPv6的对象定义。
For RSVP signaling within a VPN, certain RSVP objects need to be extended. Since customer IP addresses need not be unique, the current types of SESSION, SENDER_TEMPLATE, and FILTERSPEC objects are no longer sufficient to globally identify RSVP states in P/PE routers, since they are currently based on IP addresses. We propose new types of SESSION, SENDER_TEMPLATE, and FILTERSPEC objects, which contain globally unique VPN-IPv4 format addresses. The ingress and egress PE nodes translate between the regular IPv4 addresses for messages to and from the CE, and VPN-IPv4 addresses for messages to and from PE routers. The rules for this translation are described in later sections.
对于VPN内的RSVP信令，某些RSVP对象需要扩展。由于客户IP地址不必是唯一的，因此当前类型的会话、发送方模板和FILTERSPEC对象不再足以全局标识P/PE路由器中的RSVP状态，因为它们当前基于IP地址。我们提出了新类型的会话、发送方模板和FILTERSPEC对象，它们包含全局唯一的VPN-IPv4格式地址。入口和出口PE节点在往返于CE的消息的常规IPv4地址和往返于PE路由器的消息的VPN-IPv4地址之间进行转换。此翻译的规则将在后面的章节中描述。
The RSVP_HOP object in an RSVP message currently specifies an IP address to be used by the neighboring RSVP hop to reply to the message sender. However, MPLS VPN PE routers (especially those separated by Option-B ASBRs) are not required to have direct IP reachability to each other. To solve this issue, we propose the use of label switching to forward RSVP messages between nodes within an MPLS VPN. This is achieved by defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 RSVP_HOP object enables any two adjacent RSVP hops in an MPLS VPN (e.g., a PE in Autonomous System (AS) 1 and a PE in AS2) to correctly identify each other and send RSVP messages directly to each other.
RSVP消息中的RSVP_HOP对象当前指定了一个IP地址，相邻RSVP HOP将使用该IP地址回复消息发送方。然而，MPLS VPN PE路由器（尤其是那些由选项B ASBR分隔的路由器）不需要彼此具有直接的IP可达性。为了解决这个问题，我们建议使用标签交换在MPLS VPN内的节点之间转发RSVP消息。这是通过定义一个新的VPN-IPv4 RSVP_-HOP对象来实现的。使用VPN-IPv4 RSVP_-HOP对象可以使MPLS VPN中的任何两个相邻RSVP跳（例如，自治系统（AS）1中的PE和AS2中的PE）正确地相互识别，并直接向彼此发送RSVP消息。
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message sender and a Logical Interface Handle (LIH) as before, but in addition carries a VPN-IPv4 address that also represents the sender of the message. The message sender MUST also advertise this VPN-IPv4 address into BGP, associated with a locally allocated label, and this advertisement MUST be propagated by BGP throughout the VPN and to adjacent ASes if required to provide reachability to this PE. Frames received by the PE marked with this label MUST be given to the local control plane for processing. When a neighboring RSVP hop wishes to reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If this address is found and carries an associated label, the neighboring RSVP node MUST encapsulate the RSVP message with this label and send it via MPLS encapsulation to the BGP next hop associated with the route. The destination IP address of the message is taken from the IP address field of the RSVP_HOP object, as described in [RFC2205]. Additionally, the IPv4 address in the RSVP_HOP object continues to be used for all other existing purposes, including neighbor matching between Path/Resv and SRefresh messages [RFC2961], authentication [RFC2747], etc.
VPN-IPv4 RSVP_-HOP对象像以前一样携带消息发送方的IPv4地址和逻辑接口句柄（LIH），但另外还携带一个也代表消息发送方的VPN-IPv4地址。消息发送方还必须将此VPN-IPv4地址播发到BGP中，该地址与本地分配的标签相关联，并且此播发必须由BGP在整个VPN中传播，并在需要时传播到相邻的ASE，以提供对此PE的可访问性。标有此标签的PE接收到的帧必须交给本地控制平面进行处理。当相邻RSVP跃点希望回复包含VPN-IPv4 RSVP_跃点的消息时，它会查找该RSVP_跃点中包含的VPN-IPv4地址的BGP公告。如果找到此地址并带有相关标签，则相邻RSVP节点必须使用此标签封装RSVP消息，并通过MPLS封装将其发送到与路由相关联的BGP下一跳。消息的目标IP地址取自RSVP_-HOP对象的IP地址字段，如[RFC2205]所述。此外，RSVP_HOP对象中的IPv4地址继续用于所有其他现有目的，包括Path/Resv和SRefresh消息[RFC2961]之间的邻居匹配、身份验证[RFC2747]等。
The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY represent an existing address in the VRF that corresponds to the flow (e.g., a local loopback or PE-CE link address within the VRF for this customer), or it MAY be created specially for this purpose. In the case where the address is specially created for RSVP signaling (and possibly other control protocols), the BGP advertisement MUST NOT be redistributed to, or reachable by, any CEs outside the MPLS VPN. One way to achieve this is by creating a special "control protocols VPN" with VRF state on every PE/ASBR, carrying route targets not imported into customer VRFs. In the case where a customer VRF address is used as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST NOT be used to signal RSVP messages for a flow in a different VRF.
VPN-IPv4 RSVP_-HOP对象中使用的VPN-IPv4地址可以表示VRF中与流相对应的现有地址（例如，该客户的VRF中的本地环回或PE-CE链路地址），也可以为此专门创建。在专门为RSVP信令（以及可能的其他控制协议）创建地址的情况下，BGP播发不得重新分发给MPLS VPN之外的任何CE，也不得由其访问。实现这一点的一种方法是在每个PE/ASBR上创建一个带有VRF状态的特殊“控制协议VPN”，携带未导入客户VRF的路由目标。在客户VRF地址用作VPN-IPv4地址的情况下，一个客户VRF中的VPN-IPv4地址不得用于向不同VRF中的流发送RSVP消息信号。
If a PE/ASBR is sending a Path message to another PE/ASBR within the VPN, and it has any appropriate VPN-IPv4 address for signaling that satisfies the requirements outlined above, it MUST use a VPN-IPv4 RSVP_HOP object with this address for all RSVP messages within the VPN. If a PE/ASBR does not have any appropriate VPN-IPv4 address to use for signaling, it MAY send the Path message with a regular IPv4 RSVP_HOP object. In this case, the reply will be IP encapsulated. This option is not preferred because there is no guarantee that the neighboring RSVP hop has IP reachability to the sending node. If a PE/ASBR receives or originates a Path message with a VPN-IPv4 RSVP_HOP object, any RSVP_HOP object in corresponding upstream messages for this flow (e.g., Resv, ResvTear) or downstream messages (e.g., ResvError, PathTear) sent by this node within the VPN MUST be a VPN-IPv4 RSVP_HOP.
如果一个PE/ASBR正在向VPN内的另一个PE/ASBR发送路径消息，并且它有任何适当的VPN-IPv4地址用于满足上述要求的信令，则它必须使用一个VPN-IPv4 RSVP_-HOP对象，该对象具有VPN内所有RSVP消息的该地址。如果PE/ASBR没有任何适当的VPN-IPv4地址用于信令，它可能会使用常规IPv4 RSVP_-HOP对象发送路径消息。在这种情况下，应答将被IP封装。此选项不是首选选项，因为无法保证相邻RSVP跃点对发送节点具有IP可达性。如果PE/ASBR接收或发起带有VPN-IPv4 RSVP_-HOP对象的路径消息，则该节点在VPN内发送的该流的相应上游消息（如Resv、ResvTear）或下游消息（如ResvError、PATHTRAL）中的任何RSVP_-HOP对象都必须是VPN-IPv4 RSVP_-HOP。
When a Path message arrives at the ingress PE (step 3 of Section 2.1) the PE needs to establish suitable Path state and forward the Path message on to the egress PE. In the following paragraphs, we described the steps taken by the ingress PE.
当路径消息到达入口PE（第2.1节的步骤3）时，PE需要建立适当的路径状态，并将路径消息转发到出口PE。在以下段落中，我们描述了ingress PE采取的步骤。
The Path message is addressed to the eventual destination (the receiver at the remote customer site) and carries the IP Router Alert Option, in accordance with [RFC2205]. The ingress PE MUST recognize the Router Alert Option, intercept these messages and process them as RSVP signaling messages.
根据[RFC2205]，路径消息被发送到最终目的地（远程客户站点的接收器），并携带IP路由器警报选项。入口PE必须识别路由器警报选项，拦截这些消息并将其作为RSVP信令消息处理。
As noted above, there is an issue in recognizing Path messages as they arrive at the egress PE (PE2 in Figure 1). The approach defined here is to address the Path messages sent by the ingress PE directly to the egress PE, and send it without the IP Router Alert Option; that is, rather than using the ultimate receiver's destination address as the destination address of the Path message, we use the loopback address of the egress PE as the destination address of the Path message. This approach has the advantage that it does not require any new data-plane capabilities for the egress PE beyond those of a standard BGP/MPLS VPN PE. Details of the processing of this message at the egress PE are described below in Section 3.3. The approach of addressing a Path message directly to an RSVP next hop (that may or may not be the next IP hop) is already used in other environments such as those of [RFC4206] and [RFC4804].
如上所述，在路径消息到达出口PE时识别路径消息存在问题（图1中的PE2）。此处定义的方法是寻址入口PE直接发送到出口PE的路径消息，并在不使用IP路由器警报选项的情况下发送该路径消息；也就是说，我们使用出口PE的环回地址作为路径消息的目标地址，而不是使用最终接收方的目标地址作为路径消息的目标地址。这种方法的优点是，除了标准BGP/MPLS VPN PE之外，出口PE不需要任何新的数据平面功能。下文第3.3节描述了出口PE处该消息的处理细节。将路径消息直接寻址到RSVP下一个跃点（可能是也可能不是下一个IP跃点）的方法已经在其他环境中使用，例如[RFC4206]和[RFC4804]的环境。
The details of operation at the ingress PE are as follows. When the ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is addressed to the receiver, the VRF that is associated with the incoming interface is identified, just as for normal data path operations. The Path state for the session is stored, and is
入口PE的操作细节如下所示。当入口PE（图1中的PE1）从CE1接收到发送给接收器的路径消息时，识别与传入接口相关联的VRF，就像正常数据路径操作一样。将存储会话的路径状态，并且
associated with that VRF, so that potentially overlapping addresses among different VPNs do not appear to belong to the same session. The destination address of the receiver is looked up in the appropriate VRF, and the BGP next hop for that destination is identified. That next hop is the egress PE (PE2 in Figure 1). A new VPN-IPv4 SESSION object is constructed, containing the Route Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this destination, and the IPv4 address from the SESSION. In addition, a new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is used by this PE to advertise that prefix for this customer into the VPN. A new Path message is constructed with a destination address equal to the address of the egress PE identified above. This new Path message will contain all the objects from the original Path message, replacing the original SESSION and SENDER_TEMPLATE objects with the new VPN-IPv4 type objects. The Path message is sent without the Router Alert Option and contains an RSVP_HOP object constructed as specified in Section 3.1.
与该VRF关联，因此不同VPN之间可能重叠的地址似乎不属于同一会话。在适当的VRF中查找接收器的目的地地址，并识别该目的地的BGP下一跳。下一个跃点是出口PE（图1中的PE2）。将构造一个新的VPN-IPv4会话对象，其中包含作为此目标的VPN-IPv4路由前缀的一部分的路由标识符（RD）以及会话中的IPv4地址。此外，还构造了一个新的VPN-IPv4发送者_模板对象，其中包含来自传入发送者_模板的原始IPv4地址加上此PE用于将此客户的前缀播发到VPN中的RD。新路径消息的目的地地址等于上面标识的出口PE的地址。此新路径消息将包含原始路径消息中的所有对象，用新的VPN-IPv4类型对象替换原始会话和发送者模板对象。发送路径消息时不使用路由器警报选项，并且包含按照第3.1节的规定构造的RSVP_-HOP对象。
When a Path message arrives at the egress PE, (step 4 of Section 2.1) it is addressed to the PE itself, and is handed to RSVP for processing. The router extracts the RD and IPv4 address from the VPN-IPv4 SESSION object, and determines the local VRF context by finding a matching VPN-IPv4 prefix with the specified RD that has been advertised by this router into BGP. The entire incoming RSVP message, including the VRF information, is stored as part of the Path state.
当路径消息到达出口PE时（第2.1节的步骤4），它被发送到PE本身，并被交给RSVP进行处理。路由器从VPN-IPv4会话对象中提取RD和IPv4地址，并通过查找与指定RD匹配的VPN-IPv4前缀来确定本地VRF上下文，该RD已由该路由器播发到BGP中。整个传入RSVP消息（包括VRF信息）存储为路径状态的一部分。
Now the RSVP module can construct a Path message that differs from the Path it received in the following ways:
现在，RSVP模块可以通过以下方式构造不同于其接收路径的路径消息：
a. Its destination address is the IP address extracted from the SESSION object;
a. 其目的地址是从会话对象提取的IP地址；
b. The SESSION and SENDER_TEMPLATE objects are converted back to IPv4-type by discarding the attached RD;
b. 通过丢弃连接的RD，会话和发送方模板对象被转换回IPv4类型；
c. The RSVP_HOP Object contains the IP address of the outgoing interface of the egress PE and a Logical Interface Handle (LIH), as per normal RSVP processing.
c. 根据正常的RSVP处理，RSVP_-HOP对象包含出口PE的传出接口的IP地址和逻辑接口句柄（LIH）。
The router then sends the Path message on towards its destination over the interface identified above. This Path message carries the Router Alert Option as required by [RFC2205].
路由器然后通过上面标识的接口向其目的地发送路径消息。此路径消息包含[RFC2205]要求的路由器警报选项。
When a receiver at the customer site originates a Resv message for the session, normal RSVP procedures apply until the Resv, making its way back towards the sender, arrives at the "egress" PE (step 8 of Section 2.1). Note that this is the "egress" PE with respect to the direction of data flow, i.e., PE2 in Figure 1. On arriving at PE2, the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which the Resv was received, are used to find the matching Path state stored previously. At this stage, admission control can be performed on the PE-CE link.
当客户站点的接收方发起会话的Resv消息时，正常的RSVP程序适用，直到Resv返回发送方，到达“出口”PE（第2.1节的步骤8）。注意，这是关于数据流方向的“出口”PE，即图1中的PE2。到达PE2时，Resv中的SESSION和FILTER_SPEC对象以及接收Resv的VRF将用于查找先前存储的匹配路径状态。在此阶段，可在PE-CE链路上执行接纳控制。
Assuming admission control is successful, the PE constructs a Resv message to send to the RSVP previous hop stored in the Path state, i.e., the ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced with the same VPN-IPv4 SESSION object received in the Path. The IPv4 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, which copies the VPN-IPv4 address from the SENDER_TEMPLATE received in the matching Path message. The RSVP_HOP in the Resv message MUST be constructed as specified in Section 3.1. The Resv message MUST be addressed to the IP address contained within the RSVP_HOP object in the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP object, the Resv MUST be MPLS encapsulated using the label associated with that VPN-IPv4 address in BGP, as described in Section 3.1. If the Path message contained an IPv4 RSVP_HOP object, the Resv is simply IP encapsulated and addressed directly to the IP address in the RSVP_HOP object.
假设准入控制成功，PE构造一条Resv消息，发送到存储在路径状态中的RSVP前一跳，即入口PE（图1中的PE1）。IPv4会话对象将替换为路径中接收到的相同VPN-IPv4会话对象。IPv4筛选器_SPEC对象替换为VPN-IPv4筛选器_SPEC对象，该对象从匹配路径消息中接收的发送方_模板复制VPN-IPv4地址。Resv消息中的RSVP_跃点必须按照第3.1节的规定构造。Resv消息必须寻址到Path消息中RSVP_-HOP对象中包含的IP地址。如果路径消息包含VPN-IPv4 RSVP_-HOP对象，则必须使用BGP中与该VPN-IPv4地址关联的标签对Resv进行MPLS封装，如第3.1节所述。如果路径消息包含IPv4 RSVP_-HOP对象，则Resv只是IP封装并直接寻址到RSVP_-HOP对象中的IP地址。
If admission control is not successful on the egress PE, a ResvError message is sent towards the receiver as per normal RSVP processing.
如果出口PE上的准入控制未成功，则根据正常的RSVP处理向接收器发送ResvError消息。
Upon receiving a Resv message at the ingress PE (step 8 of Section 2.1) with respect to data flow (i.e., PE1 in Figure 1), the PE determines the local VRF context and associated Path state for this Resv by decoding the received SESSION and FILTER_SPEC objects. It is now possible to generate a Resv message to send to the appropriate CE. The Resv message sent to the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate Path state. Since we assume, in this section, that admission control over the provider's backbone is not needed, the ingress PE does not perform any admission control for this reservation.
在入口PE（第2.1节的步骤8）接收到关于数据流（即图1中的PE1）的Resv消息后，PE通过解码接收到的会话和筛选器规范对象来确定该Resv的本地VRF上下文和关联路径状态。现在可以生成Resv消息以发送给相应的CE。发送到入口CE的Resv消息将包含IPv4会话和筛选器规范对象，这些对象来自适当的路径状态。由于在本节中，我们假设不需要对提供商的主干网进行准入控制，因此入口PE不对该保留执行任何准入控制。
Processing of PathError, PathTear, ResvError, ResvTear, and ResvConf messages is generally straightforward and follows the rules of [RFC2205]. These additional rules MUST be observed for messages transmitted within the VPN (i.e., between the PEs):
PathError、PathTear、ResvError、ResvTear和ResvConf消息的处理通常很简单，并且遵循[RFC2205]的规则。对于在VPN内（即在PEs之间）传输的消息，必须遵守这些附加规则：
o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be converted from IPv4 to VPN-IPv4 form and back in the same manner as described above for Path and Resv messages.
o 会话、发送方\模板和筛选器\规范对象必须从IPv4格式转换为VPN-IPv4格式，并以与上述Path和Resv消息相同的方式返回。
o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be used as described above.
o 如上所述，必须使用适当类型的RSVP_-HOP对象（VPN-IPv4或IPv4）。
o Depending on the type of RSVP_HOP object received from the neighbor, the message MUST be MPLS encapsulated or IP encapsulated as described above.
o 根据从邻居接收的RSVP_-HOP对象的类型，消息必须是MPLS封装或IP封装，如上所述。
o The matching state and VRF MUST be determined by decoding the RD and IPv4 addresses in the SESSION and FILTER_SPEC objects.
o 必须通过解码会话和筛选器规范对象中的RD和IPv4地址来确定匹配状态和VRF。
o The message MUST be directly addressed to the appropriate PE, without using the Router Alert Option.
o 消息必须直接发送到相应的PE，而不使用路由器警报选项。
The preceding section outlines how per-customer reservations can be made over the PE-CE links. This may be sufficient in many situations where the backbone is well engineered with ample capacity and there is no need to perform any sort of admission control in the backbone. However, in some cases where excess capacity cannot be relied upon (e.g., during failures or unanticipated periods of overload), it may be desirable to be able to perform admission control in the backbone on behalf of customer traffic.
上一节概述了如何通过PE-CE链接按客户进行预订。在许多情况下，这可能是足够的，其中主干网设计良好，具有足够的容量，并且不需要在主干网中执行任何种类的接纳控制。然而，在不能依赖过剩容量的某些情况下（例如，在故障或意外过载期间），可能希望能够代表客户流量在主干中执行接纳控制。
Because of the fact that routes to customer addresses are not present in the P routers, along with the concerns of scalability that would arise if per-customer reservations were allowed in the P routers, it is clearly necessary to map the per-customer reservations described in the preceding section onto some sort of aggregate reservations. Furthermore, customer data packets need to be tunneled across the provider backbone just as in normal BGP/MPLS VPN operation.
由于P路由器中不存在到客户地址的路由，以及如果P路由器中允许每个客户的预订，则可能会出现的可伸缩性问题，因此显然有必要将前一节中描述的每个客户的预订映射到某种类型的聚合预订上。此外，与正常的BGP/MPLS VPN操作一样，客户数据包需要通过提供商主干进行隧道传输。
Given these considerations, a feasible way to achieve the objective of admission control in the backbone is to use the ideas described in [RFC4804]. MPLS-TE tunnels can be established between PEs as a means to perform aggregate admission control in the backbone.
考虑到这些因素，在主干网中实现接纳控制目标的可行方法是使用[RFC4804]中描述的思想。可以在PEs之间建立MPLS-TE隧道，作为在主干网中执行聚合接纳控制的一种方法。
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought of as a virtual link of a certain capacity. The main change to the procedures described above is that when a Resv is received at the ingress PE, an admission control decision can be performed by checking whether sufficient capacity of that virtual link remains available to admit the new customer reservation. We note also that [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel across the backbone, rather than the simple RSVP_HOP object described in Section 3.2. The procedures of [RFC4804] should be followed here as well.
从入口PE到出口PE的MPLS-TE隧道可以被认为是具有一定容量的虚拟链路。对上述过程的主要改变是，当在入口PE处接收到Resv时，可以通过检查该虚拟链路的足够容量是否保持可用以接纳新客户预约来执行接纳控制决策。我们还注意到，[RFC4804]使用IF_ID RSVP_HOP对象来标识主干上的隧道，而不是第3.2节中描述的简单RSVP_HOP对象。此处也应遵循[RFC4804]的程序。
To achieve effective admission control in the backbone, there needs to be some way to separate the data-plane traffic that has a reservation from that which does not. We assume that packets that are subject to admission control on the core will be given a particular MPLS EXP value, and that no other packets will be allowed to enter the core with this value unless they have passed admission control. Some fraction of link resources will be allocated to queues on core links for packets bearing that EXP value, and the MPLS-TE tunnels will use that resource pool to make their constraint-based routing and admission control decisions. This is all consistent with the principles of aggregate RSVP reservations described in [RFC3175].
为了在主干网中实现有效的接纳控制，需要有某种方法来分离有保留的数据平面通信量和没有保留的数据平面通信量。我们假设在核心上受许可控制的数据包将被赋予一个特定的MPLS EXP值，并且不允许其他数据包以该值进入核心，除非它们已经通过许可控制。链路资源的一部分将分配给核心链路上的队列，用于承载该EXP值的数据包，MPLS-TE隧道将使用该资源池来做出基于约束的路由和接纳控制决策。这与[RFC3175]中所述的总RSVP保留原则一致。
[RFC4364] defines three modes of inter-AS operation for MPLS/BGP VPNs, referred to as Options A, B, and C. In the following sections we describe how the scheme described above can operate in each inter-AS environment.
[RFC4364]为MPLS/BGP VPN定义了三种AS间操作模式，称为选项A、B和C。在以下部分中，我们将描述上述方案如何在每个AS间环境中操作。
Operation of RSVP in Inter-AS Option A is quite straightforward. Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed as PE-CE links in terms of admission control. If the procedures defined in Section 3 are enabled on both ASBRs, then admission control may be performed on the inter-ASBR links. In addition, the operator of each AS can independently decide whether or not to perform admission control across his backbone. The new objects described in this document MUST NOT be sent in any RSVP message between two Option-A ASBRs.
在Inter AS选项A中，RSVP的操作非常简单。每个ASBR都像PE一样运行，ASBR-ASBR链路在准入控制方面可以被视为PE-CE链路。如果在两个ASBR上都启用了第3节中定义的程序，则可以在ASBR间链路上执行准入控制。此外，每个AS的操作员可以独立决定是否跨其主干执行接纳控制。本文档中描述的新对象不得在两个选项A ASBR之间的任何RSVP消息中发送。
To support inter-AS Option B, we require some additional processing of RSVP messages on the ASBRs. Recall that, when packets are forwarded from one AS to another in Option B, the VPN label is swapped by each ASBR as a packet goes from one AS to another. The
为了支持inter-AS选项B，我们需要对ASBR上的RSVP消息进行一些额外的处理。回想一下，在选项B中，当数据包从一个AS转发到另一个AS时，每个ASBR会在数据包从一个AS转到另一个AS时交换VPN标签。这个
BGP next hop seen by the ingress PE will be the ASBR, and there need not be IP visibility between the ingress and egress PEs. Hence, when the ingress PE sends the Path message to the BGP next hop of the VPN-IPv4 route towards the destination, it will be received by the ASBR. The ASBR determines the next hop of the route in a similar way as the ingress PE -- by finding a matching BGP VPN-IPv4 route with the same RD and a matching prefix.
入口PE看到的BGP下一跳将是ASBR，入口和出口PE之间不需要IP可见性。因此，当入口PE将Path消息发送到通向目的地的VPN-IPv4路由的下一跳BGP时，ASBR将接收到该消息。ASBR以与入口PE类似的方式确定路由的下一跳——通过查找具有相同RD和匹配前缀的匹配BGP VPN-IPv4路由。
The provider(s) who interconnect ASes using Option B may or may not desire to perform admission control on the inter-AS links. This choice affects the detailed operation of ASBRs. We describe the two modes of operation -- with and without admission control at the ASBRs -- in the following sections.
使用选项B互连ASE的提供商可能希望也可能不希望在AS间链路上执行准入控制。此选择会影响ASBR的详细操作。我们在下面的章节中描述了两种操作模式——ASBR中有准入控制和没有准入控制。
In this scenario, the ASBR performs full RSVP signaling and admission control. The RSVP database is indexed on the ASBR using the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects (which uniquely identify RSVP sessions and flows as per the requirements of [RFC2205]). These objects are forwarded unmodified in both directions by the ASBR. All other procedures of RSVP are performed as if the ASBR was an RSVP hop. In particular, the RSVP_HOP objects sent in Path and Resv messages contain IP addresses of the ASBR, which MUST be reachable by the neighbor to whom the message is being sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects satisfy the uniqueness properties required for an RSVP database implementation as per [RFC2209], no customer VRF awareness is required on the ASBR.
在这种情况下，ASBR执行完全RSVP信令和准入控制。RSVP数据库使用VPN-IPv4会话、发送方模板和筛选器规范对象（根据[RFC2205]的要求唯一标识RSVP会话和流）在ASBR上建立索引。这些对象由ASBR在两个方向上转发，不做任何修改。RSVP的所有其他程序都像ASBR是RSVP跳一样执行。特别是，在Path和Resv消息中发送的RSVP_-HOP对象包含ASBR的IP地址，该地址必须可由消息发送到的邻居访问。请注意，由于VPN-IPv4会话、发送方模板和筛选器规范对象满足[RFC2209]中RSVP数据库实现所需的唯一性属性，因此ASBR上不需要客户VRF感知。
If the ASBR is not doing admission control, it is desirable that per-flow state not be maintained on the ASBR. This requires adjacent RSVP hops (i.e., the ingress and egress PEs of the respective ASes) to send RSVP messages directly to each other. This is only possible if they are MPLS encapsulated. The use of the VPN-IPv4 RSVP_HOP object described in Section 3.1 is REQUIRED in this case.
如果ASBR不进行准入控制，则最好不要在ASBR上保持每流状态。这需要相邻的RSVP跳（即，各个ASE的入口和出口PE）直接彼此发送RSVP消息。这只有在MPLS封装的情况下才可能实现。在这种情况下，需要使用第3.1节中描述的VPN-IPv4 RSVP_-HOP对象。
When an ASBR that is not installing local RSVP state receives a Path message, it looks up the next hop of the matching BGP route as described in Section 3.2, and sends the Path message to the next hop, without modifying any RSVP objects (including the RSVP_HOP). This process is repeated at subsequent ASBRs until the Path message arrives at a router that is installing local RSVP state (either the ultimate egress PE, or an ASBR configured to perform admission control). This router receives the Path and processes it as described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an
当未安装本地RSVP状态的ASBR收到Path消息时，它将按照第3.2节中的说明查找匹配BGP路由的下一个跃点，并将Path消息发送到下一个跃点，而不修改任何RSVP对象（包括RSVP_跃点）。此过程在后续ASBR重复，直到路径消息到达正在安装本地RSVP状态的路由器（最终出口PE或配置为执行准入控制的ASBR）。该路由器接收路径并按照第3.3节（如果是PE）或第5.2.1节（如果是PE）中的说明进行处理
ASBR performing admission control. When this router sends the Resv upstream, it looks up the routing table for a next hop+label for the VPN-IPv4 address in the PHOP, encapsulates the Resv with that label, and sends it upstream. This message will be received for control processing directly on the upstream RSVP hop (that last updated the RSVP_HOP field in the Path message), without any involvement of intermediate ASBRs.
ASBR执行准入控制。当此路由器向上游发送Resv时，它在PHOP中查找VPN-IPv4地址的下一跳+标签的路由表，用该标签封装Resv，并向上游发送。此消息将直接在上游RSVP跃点（上次更新路径消息中的RSVP_跃点字段）上接收以进行控制处理，中间ASBR不参与。
The ASBR is not expected to process any other RSVP messages apart from the Path message as described above. The ASBR also does not need to store any RSVP state. Note that any ASBR along the path that wishes to do admission control or insert itself into the RSVP signaling flow may do so by writing its own RSVP_HOP object with IPv4 and VPN-IPv4 addresses pointing to itself.
除如上所述的Path消息外，ASBR预计不会处理任何其他RSVP消息。ASBR也不需要存储任何RSVP状态。请注意，路径上希望进行准入控制或将自身插入RSVP信令流的任何ASBR都可以通过编写自己的RSVP_-HOP对象来实现，该对象的IPv4和VPN-IPv4地址指向自身。
If an Option-B ASBR that receives an RSVP Path message with an IPv4 RSVP_HOP does not wish to perform admission control but is willing to install local state for this flow, the ASBR MUST process and forward RSVP signaling messages for this flow as described in Section 5.2.1 (with the exception that it does not perform admission control). If an Option-B ASBR receives an RSVP Path message with an IPv4 RSVP_HOP, but does not wish to install local state or perform admission control for this flow, the ASBR MUST NOT forward the Path message. In addition, the ASBR SHOULD send a PathError message of Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not reachable across VPN" (see Section 9) signifying to the upstream RSVP hop that the supplied RSVP_HOP object is insufficient to provide reachability across this VPN. This failure condition is not expected to be recoverable.
如果接收带有IPv4 RSVP跳的RSVP Path消息的Option-B ASBR不希望执行准入控制，但愿意为此流安装本地状态，则ASBR必须按照第5.2.1节所述处理并转发此流的RSVP信令消息（不执行准入控制的除外）。如果Option-B ASBR接收到带有IPv4 RSVP_跃点的RSVP Path消息，但不希望安装本地状态或对此流执行许可控制，则ASBR不得转发该路径消息。此外，ASBR应发送错误代码“RSVP over MPLS Problem”和错误值“RSVP_-HOP not reachable over VPN”（参见第9节）的PathError消息，向上游RSVP-HOP表明提供的RSVP_-HOP对象不足以提供此VPN的可达性。该故障状态预计不可恢复。
Operation of RSVP in Inter-AS Option C is also quite straightforward, because there exists an LSP directly from ingress PE to egress PE. In this case, there is no significant difference in operation from the single AS case described in Section 3. Furthermore, if it is desired to provide admission control from PE to PE, it can be done by building an inter-AS TE tunnel and then using the procedures described in Section 4.
在Inter-AS选项C中的RSVP操作也非常简单，因为存在一个直接从入口PE到出口PE的LSP。在这种情况下，与第3节所述的单一情况相比，操作没有显著差异。此外，如果希望提供从一个PE到另一个PE的入口控制，可以通过建造一条AS-TE隧道，然后使用第4节中描述的程序来实现。
It is often the case that RSVP will not be enabled on the PE-CE links. In such an environment, a customer may reasonably expect that RSVP messages sent into the L3 VPN network should be forwarded just like any other IP datagrams. This transparency is useful when the customer wishes to use RSVP within his own sites or perhaps to perform admission control on the CE-PE links (in CE->PE direction
通常情况下，PE-CE链路上不会启用RSVP。在这样的环境中，客户可以合理地期望发送到L3 VPN网络的RSVP消息应该像任何其他IP数据报一样被转发。当客户希望在其自己的站点内使用RSVP或可能在CE-PE链接（CE->PE方向）上执行准入控制时，这种透明度非常有用
only), without involvement of the PEs. For this reason, a PE SHOULD NOT discard or modify RSVP messages sent towards it from a CE when RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT discard or modify RSVP messages that are destined for one of its attached CEs, even when RSVP is not enabled on those links. Note that the presence of the Router Alert Option in some RSVP messages may cause them to be forwarded outside of the normal forwarding path, but that the guidance of this paragraph still applies in that case. Note also that this guidance applies regardless of whether RSVP-TE is used in some, all, or none of the L3VPN network.
仅），不涉及PEs。因此，当PE-CE链路上未启用RSVP时，PE不应丢弃或修改CE向其发送的RSVP消息。同样，PE不应丢弃或修改发送至其连接的CE之一的RSVP消息，即使这些链路上未启用RSVP。请注意，某些RSVP消息中存在路由器警报选项可能会导致它们在正常转发路径之外转发，但本段的指导仍适用于这种情况。还请注意，无论RSVP-TE是否用于部分、全部或无L3VPN网络，本指南均适用。
This section describes modifications to other RSVP procedures introduced by MPLS VPNs.
本节介绍对MPLS VPN引入的其他RSVP过程的修改。
The following points ought to be noted regarding RSVP refresh overhead reduction [RFC2961] across an MPLS VPN:
关于跨MPLS VPN减少RSVP刷新开销[RFC2961]，应注意以下几点：
o The hop between the ingress and egress PE of a VPN is to be considered as traversing one or more non-RSVP hops. As such, the procedures described in Section 5.3 of [RFC2961] relating to non-RSVP hops SHOULD be followed.
o VPN的入口和出口PE之间的跳视为穿越一个或多个非RSVP跳。因此，应遵循[RFC2961]第5.3节中描述的与非RSVP跳数相关的程序。
o The source IP address of a SRefresh message MUST match the IPv4 address signaled in the RSVP_HOP object contained in the corresponding Path or Resv message. The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be used as the source address of that message for this purpose.
o SRefresh消息的源IP地址必须与相应路径或Resv消息中包含的RSVP_-HOP对象中发出信号的IPv4地址匹配。为此，任何接收到的VPN-IPv4 RSVP_-HOP对象中的IPv4地址必须用作该消息的源地址。
The following points ought to be noted regarding RSVP cryptographic authentication ([RFC2747]) across an MPLS VPN:
关于跨MPLS VPN的RSVP加密身份验证（[RFC2747]），应注意以下几点：
o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be used as the source address of that message for purposes of identifying the security association.
o 任何接收到的VPN-IPv4 RSVP_-HOP对象中的IPv4地址都必须用作该消息的源地址，以便识别安全关联。
o Forwarding of Challenge and Response messages MUST follow the same rules as described above for hop-by-hop messages. Specifically, if the originator of a Challenge/Response message has received a VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST use the label associated with that VPN-IPv4 address in BGP to forward the Challenge/Response message.
o 转发质询和响应消息必须遵循与上述逐跳消息相同的规则。具体而言，如果质询/响应消息的发起人已从相应的邻居接收到VPN-IPv4 RSVP_-HOP对象，则必须使用BGP中与该VPN-IPv4地址关联的标签转发质询/响应消息。
[RFC3175] and [RFC4860] describe mechanisms to aggregate multiple individual RSVP reservations into a single larger reservation on the basis of a common Differentiated Services Code Point/Per-Hop Behavior (DSCP/PHB) for traffic classification. The following points ought to be noted in this regard:
[RFC3175]和[RFC4860]描述了基于用于流量分类的公共区分服务代码点/每跳行为（DSCP/PHB）将多个单独RSVP保留聚合为单个较大保留的机制。在这方面应注意以下几点：
o The procedures described in this section apply only in the case where the Aggregator and Deaggregator nodes are C/CE devices, and the entire MPLS VPN lies within the Aggregation Region. The case where the PE is also an Aggregator/Deaggregator is more complex and not considered in this document.
o 本节中描述的过程仅适用于聚合器和解聚合器节点为C/CE设备且整个MPLS VPN位于聚合区域内的情况。PE同时也是聚合器/解聚器的情况更为复杂，本文件未考虑。
o Support of Aggregate RSVP sessions is OPTIONAL. When supported:
o 支持聚合RSVP会话是可选的。支持时：
* Aggregate RSVP sessions MUST be treated in the same way as regular IPv4 RSVP sessions. To this end, all the procedures described in Sections 3 and 4 MUST be followed for aggregate RSVP sessions. The corresponding new SESSION, SENDER_TEMPLATE, and FILTERSPEC objects are defined in Section 8.
* 聚合RSVP会话的处理方式必须与常规IPv4 RSVP会话相同。为此，必须遵循第3节和第4节中描述的所有程序进行RSVP聚合会话。第8节中定义了相应的新会话、发送方\模板和FILTERSPEC对象。
* End-To-End (E2E) RSVP sessions are passed unmodified through the MPLS VPN. These RSVP messages SHOULD be identified by their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any RSVP message with this IP protocol, it MUST process this frame as if it is regular customer traffic and ignore any Router Alert Option. The appropriate VPN and transport labels are applied to the frame and it is forwarded towards the remote CE. Note that this message will not be received or processed by any other P or PE node.
* 端到端（E2E）RSVP会话未经修改地通过MPLS VPN传递。这些RSVP消息应通过其IP协议识别（RSVP-E2E-IGNORE，134）。当ingress PE接收到此IP协议的任何RSVP消息时，它必须像处理常规客户流量一样处理此帧，并忽略任何路由器警报选项。将适当的VPN和传输标签应用于帧，并将其转发到远程CE。请注意，任何其他P或PE节点都不会接收或处理此消息。
* Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be conveyed unmodified across the MPLS VPN.
* 任何感兴趣的会话对象（在[RFC4860]中定义）必须在不修改的情况下通过MPLS VPN传输。
[RFC5824] describes a set of requirements for the establishment for CE-CE MPLS LSPs across networks offering an L3VPN service. The requirements specified in that document are similar to those addressed by this document, in that both address the issue of handling RSVP requests from customers in a VPN context. It is possible that the solution described here could be adapted to meet the requirements of [RFC5824]. To the extent that this document uses signaling extensions described in [RFC3473] that have already been used for GMPLS/TE, we expect that CE-CE RSVP/TE will be incremental work built on these extensions. These extensions will be considered in a separate document.
[RFC5824]描述了跨提供L3VPN服务的网络建立CE-CE MPLS LSP的一组要求。该文件中规定的要求与本文件中的要求类似，因为两者都解决了在VPN环境中处理客户RSVP请求的问题。这里描述的解决方案可能适合于满足[RFC5824]的要求。鉴于本文件使用[RFC3473]中所述的已用于GMPLS/TE的信令扩展，我们预计CE-CE RSVP/TE将是基于这些扩展的增量工作。这些扩展将在单独的文件中考虑。
The usage of the VPN-IPv4 (or VPN-IPv6) SESSION object is described in Sections 3.2 to 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION object appears in RSVP messages that ordinarily contain a SESSION object and are sent between ingress PE and egress PE in either direction. The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
第3.2节至第3.6节介绍了VPN-IPv4（或VPN-IPv6）会话对象的用法。VPN-IPv4（或VPN-IPv6）会话对象出现在通常包含会话对象的RSVP消息中，并在入口PE和出口PE之间以任意方向发送。该对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当该对象可能出现在AS间链路上时）。
The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 address ([RFC4364]).
VPN-IPv6会话对象类似于VPN-IPv4会话对象，使用VPN-IPv6地址（[RFC4659]）而不是VPN-IPv4地址（[RFC4364]）。
The formats of the objects are as follows:
对象的格式如下所示：
o VPN-IPv4 SESSION object: Class = 1, C-Type = 19
o VPN-IPv4会话对象：Class=1，C-Type=19
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SESSION object: Class = 1, C-Type = 20
o VPN-IPv6会话对象：Class=1，C-Type=20
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4 DestAddress（分别为VPN-IPv6 DestAddress）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。第3.2节和第3.3节讨论了该领域的内容。
The protocol ID, flags, and DstPort are identical to the same fields in the IPv4 and IPv6 SESSION objects ([RFC2205]).
协议ID、标志和DstPort与IPv4和IPv6会话对象（[RFC2205]）中的相同字段相同。
The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Sections 3.2 and 3.3. The VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages that ordinarily contain a SENDER_TEMPLATE object and are sent between ingress PE and egress PE in either direction (such as Path, PathError, and PathTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The format of the object is as follows:
第3.2节和第3.3节介绍了VPN-IPv4（或VPN-IPv6）发送方_模板对象的用法。VPN-IPv4（或VPN-IPv6）发送方_模板对象出现在RSVP消息中，这些消息通常包含发送方_模板对象，并在入口PE和出口PE之间以任意方向（例如路径、路径错误和路径撕裂）发送。该对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当该对象可能出现在AS间链路上时）。对象的格式如下所示：
o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 14
o VPN-IPv4发送方\模板对象：类=11，C类型=14
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 SrcAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 15
o VPN-IPv6发送方\模板对象：Class=11，C-Type=15
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 SrcAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 SrcAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | SrcPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 SrcAddress (respectively, VPN-IPv6 SrcAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4 SrcAddress（分别为VPN-IPv6 SrcAddress）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。第3.2节和第3.3节讨论了该领域的内容。
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]).
SrcPort与IPv4和IPv6发送者_模板对象（[RFC2205]）中的SrcPort字段相同。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
在传输时，保留字段必须设置为零，在接收时忽略。
The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object is described in Sections 3.4 and 3.5. The VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object appears in RSVP messages that ordinarily contain a FILTER_SPEC object and are sent between ingress PE and egress PE in either direction (such as Resv, ResvError, and ResvTear). The object MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
第3.4节和第3.5节介绍了VPN-IPv4（或VPN-IPv6）筛选器规范对象的用法。VPN-IPv4（或VPN-IPv6）筛选器规范对象出现在RSVP消息中，这些消息通常包含筛选器规范对象，并在入口PE和出口PE之间以任意方向（如Resv、ResvError和ResvTear）发送。该对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当该对象可能出现在AS间链路上时）。
o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 14
o VPN-IPv4筛选器_规范对象：Class=10，C-Type=14
Definition same as VPN-IPv4 SENDER_TEMPLATE object.
定义与VPN-IPv4发送方\模板对象相同。
o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 15
o VPN-IPv6筛选器_规格对象：Class=10，C-Type=15
Definition same as VPN-IPv6 SENDER_TEMPLATE object.
定义与VPN-IPv6发送方\模板对象相同。
The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field is discussed in Sections 3.4 and 3.5.
第3.4节和第3.5节讨论了VPN-IPv4 SrcAddress（或VPN-IPv6 SrcAddress）字段的内容。
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 SENDER_TEMPLATE objects ([RFC2205]).
SrcPort与IPv4和IPv6发送者_模板对象（[RFC2205]）中的SrcPort字段相同。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
在传输时，保留字段必须设置为零，在接收时忽略。
Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP object is described in Sections 3.1 and 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP object is used to establish signaling reachability between RSVP neighbors separated by one or more Option-B ASBRs. This object may appear in RSVP messages that carry an RSVP_HOP object, and that travel between the ingress and egress PEs. It MUST NOT be included in any RSVP
VPN-IPv4（或VPN-IPv6）RSVP_-HOP对象的使用在第3.1节和第5.2.2节中描述。VPN-IPv4（VPN-IPv6）RSVP_-HOP对象用于在由一个或多个Option-B ASBR分隔的RSVP邻居之间建立信令可达性。该对象可能出现在携带RSVP_-HOP对象的RSVP消息中，并在入口和出口PE之间移动。不得包含在任何RSVP中
messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The format of the object is as follows:
在提供商主干网之外发送的消息（如上文所述，在inter-AS选项B和选项C情况下，当消息可能出现在inter-AS链路上时除外）。对象的格式如下所示：
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = 5
o VPN-IPv4 RSVP_-HOP对象：类=3，C-Type=5
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = 6
o VPN-IPv6 RSVP_-HOP对象：Class=3，C-Type=6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address, and the Logical Interface Handle fields are identical to those of the RSVP_HOP object ([RFC2205]).
IPv4下一个/上一个跃点地址、IPv6下一个/上一个跃点地址和逻辑接口句柄字段与RSVP_跃点对象（[RFC2205]）的字段相同。
The VPN-IPv4 Next/Previous Hop Address (respectively, VPN-IPv6 Next/ Previous Hop Address) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Section 3.1.
VPN-IPv4下一个/上一个跃点地址（分别为VPN-IPv6下一个/上一个跃点地址）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。第3.1节讨论了该领域的内容。
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SESSION object as defined in [RFC3175] and are sent between ingress PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-VPN-IPv6) SESSION object should appear in all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in [RFC4860] and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6) SESSION object defined in Section 8.1. The format of the object is as follows:
第7.3节介绍了聚合VPN-IPv4（或VPN-IPv6）会话对象的用法。AGGREGATE-VPN-IPv4（分别为AGGREGATE-IPv6-VPN）会话对象出现在RSVP消息中，这些消息通常包含[RFC3175]中定义的AGGREGATE-IPv4（分别为AGGREGATE-IPv6）会话对象，并在入口PE和出口PE之间以任意方向发送。GENERIC-AGGREGATE-VPN-IPv4（分别为AGGREGATE-VPN-IPv6）会话对象应出现在通常包含[RFC4860]中定义的GENERIC-AGGREGATE-IPv4（分别为GENERIC-AGGREGATE-IPv6）会话对象并在入口PE和出口PE之间以任意方向发送的所有RSVP消息中。这些对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当它可能出现在AS间链路上时）。这些对象的处理规则在其他方面与第8.1节中定义的VPN-IPv4（分别为VPN-IPv6）会话对象的处理规则相同。对象的格式如下所示：
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 21
o 聚合-VPN-IPv4会话对象：类=1，C-Type=21
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 22
o 聚合-VPN-IPv6会话对象：Class=1，C-Type=22
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4 DestAddress（分别为VPN-IPv6 DestAddress）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。第3.2节和第3.3节讨论了该领域的内容。
The flags and DSCP are identical to the same fields of the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]).
标志和DSCP与AGGREGATE-IPv4和AGGREGATE-IPv6会话对象（[RFC3175]）的相同字段相同。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
在传输时，保留字段必须设置为零，在接收时忽略。
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 23
o GENERIC-AGGREGATE-VPN-IPv4会话对象：Class=1，C-Type=23
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 24
o GENERIC-AGGREGATE-VPN-IPv6会话对象：Class=1，C-Type=24
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content of this field is discussed in Sections 3.2 and 3.3.
VPN-IPv4 DestAddress（分别为VPN-IPv6 DestAddress）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。第3.2节和第3.3节讨论了该领域的内容。
The flags, PHB-ID, vDstPort, and Extended vDstPort are identical to the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION objects ([RFC4860]).
标志、PHB-ID、vDstPort和扩展vDstPort与GENERIC-AGGREGATE-IPv4和GENERIC-AGGREGATE-IPv6会话对象（[RFC4860]）的相同字段相同。
The Reserved field MUST be set to zero on transmit and ignored on receipt.
在传输时，保留字段必须设置为零，在接收时忽略。
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively, AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links). The processing rules for these objects are otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6) SENDER_TEMPLATE object defined in Section 8.2. The format of the object is as follows:
第7.3节介绍了聚合VPN-IPv4（或VPN-IPv6）发送方_模板对象的用法。AGGREGATE-VPN-IPv4（分别为AGGREGATE-VPN-IPv6）发送方_模板对象出现在RSVP消息中，这些消息通常包含[RFC3175]和[RFC4860]中定义的AGGREGATE-IPv4（分别为AGGREGATE-IPv6）发送方_模板对象，并在入口PE和出口PE之间以任意方向发送。这些对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当它可能出现在AS间链路上时）。这些对象的处理规则与第8.2节中定义的VPN-IPv4（分别为VPN-IPv6）发送方_模板对象的处理规则相同。对象的格式如下所示：
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 16
o AGGREGATE-VPN-IPv4发送方\模板对象：Class=11，C-Type=16
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 17
o 聚合-VPN-IPv6发送方\模板对象：Class=11，C-Type=17
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 AggregatorAddress (respectively, VPN-IPv6 AggregatorAddress) field contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as specified in [RFC4364] (respectively, [RFC4659]). The content and processing rules for these objects are similar to those of the VPN-IPv4 SENDER_TEMPLATE object defined in Section 8.2.
VPN-IPv4聚合地址（分别为VPN-IPv6聚合地址）字段包含按[RFC4364]（分别为[RFC4659]）中指定编码的VPN-IPv4（分别为VPN-IPv6）地址系列的地址。这些对象的内容和处理规则与第8.2节中定义的VPN-IPv4发送者_模板对象类似。
The flags and DSCP are identical to the same fields of the AGGREGATE-IPv4 and AGGREGATE-IPv6 SESSION objects.
标志和DSCP与AGGREGATE-IPv4和AGGREGATE-IPv6会话对象的相同字段相同。
The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are sent between ingress PE and egress PE in either direction. These objects MUST NOT be included in any RSVP messages that are sent outside of the provider's backbone (except in the inter-AS Option-B and Option-C cases, as described above, when it may appear on inter-AS links).
第7.3节介绍了聚合VPN-IPv4筛选器_SPEC对象的用法。聚合-VPN-IPv4筛选器_SPEC对象出现在RSVP消息中，这些消息通常包含[RFC3175]和[RFC4860]中定义的聚合-IPv4筛选器_SPEC对象，并在入口PE和出口PE之间以任意方向发送。这些对象不得包含在提供商主干网之外发送的任何RSVP消息中（在AS间选项B和选项C情况下除外，如上所述，当它可能出现在AS间链路上时）。
The processing rules for these objects are otherwise identical to those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The format of the object is as follows:
这些对象的处理规则在其他方面与第8.3节中定义的VPN-IPv4筛选器_SPEC对象的处理规则相同。对象的格式如下所示：
o AGGREGATE-VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 16
o AGGREGATE-VPN-IPv4筛选器_SPEC对象：Class=10，C-Type=16
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
定义与AGGREGATE-VPN-IPv4发送方\模板对象相同。
o AGGREGATE-VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 17
o 聚合-VPN-IPv6筛选器_规范对象：类=10，C类型=17
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
定义与AGGREGATE-VPN-IPv6发送方\模板对象相同。
Section 8 defines new objects. Therefore, IANA has modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and:
第8节定义了新对象。因此，IANA修改了RSVP参数注册表“类名、类号和类类型”子区，以及：
o assigned six new C-Types under the existing SESSION Class (Class number 1), as follows:
o 在现有课程类别（课程编号1）下分配了六种新的C类型，如下所示：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
1次会议[RFC2205]
Class Types or C-Types:
类别类型或C类型：
.. ... ...
19 VPN-IPv4 [RFC6016]
20 VPN-IPv6 [RFC6016]
21 AGGREGATE-VPN-IPv4 [RFC6016]
22 AGGREGATE-VPN-IPv6 [RFC6016]
23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016]
24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]
.. ... ...
19 VPN-IPv4 [RFC6016]
20 VPN-IPv6 [RFC6016]
21 AGGREGATE-VPN-IPv4 [RFC6016]
22 AGGREGATE-VPN-IPv6 [RFC6016]
23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016]
24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]
o assigned four new C-Types under the existing SENDER_TEMPLATE Class (Class number 11), as follows:
o 在现有SENDER_模板类别（类别编号11）下分配了四个新的C类型，如下所示：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
11 SENDER_TEMPLATE [RFC2205]
11发送者模板[RFC2205]
Class Types or C-Types:
类别类型或C类型：
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
o assigned four new C-Types under the existing FILTER_SPEC Class (Class number 10), as follows:
o 在现有过滤器规格类别（类别编号10）下分配了四种新的C型，如下所示：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
10 FILTER_SPEC [RFC2205]
10过滤器规格[RFC2205]
Class Types or C-Types:
类别类型或C类型：
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
o assigned two new C-Types under the existing RSVP_HOP Class (Class number 3), as follows:
o 在现有RSVP_HOP类别（类别编号3）下分配了两个新的C类型，如下所示：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
3 RSVP_HOP [RFC2205]
3 RSVP_-HOP[RFC2205]
Class Types or C-Types:
类别类型或C类型：
.. ... ... 5 VPN-IPv4 [RFC6016] 6 VPN-IPv6 [RFC6016]
.. ... ... 5 VPN-IPv4[RFC6016]6 VPN-IPv6[RFC6016]
In addition, a new PathError code/value is required to identify a signaling reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, IANA has modified the RSVP parameters registry, 'Error Codes and Globally-Defined Error Value Sub-Codes' subregistry, and:
此外，如第5.2.2节所述，需要新的PathError代码/值来识别信令可达性故障以及对VPN-IPv4或VPN-IPv6 RSVP_-HOP对象的需要。因此，IANA修改了RSVP参数注册表“错误代码和全局定义的错误值子代码”子区，以及：
o assigned a new Error Code and sub-code, as follows:
o 分配了新的错误代码和子代码，如下所示：
37 RSVP over MPLS Problem [RFC6016]
37基于MPLS的RSVP问题[RFC6016]
This Error Code has the following globally-defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
1 = RSVP_HOP not reachable across VPN [RFC6016]
1=无法通过VPN访问RSVP_跃点[RFC6016]
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in general. General RSVP security considerations are discussed in [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. Those protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. [RSVP-KEYING] discusses applicability of various keying approaches for RSVP Authentication. First, we note that the discussion about applicability of group keying to an intra-provider environment where RSVP hops are not IP hops is relevant to securing of RSVP among PEs of a given Service Provider deploying the solution specified in the present document. We note that the RSVP signaling in MPLS VPN is likely to spread over multiple administrative domains (e.g., the service provider operating the VPN service, and the customers of the service). Therefore the considerations in [RSVP-KEYING] about inter-domain issues are likely to apply.
[RFC4364]总体上解决了BGP/MPLS VPN的安全问题。[RFC2205]中讨论了一般RSVP安全注意事项。为确保RSVP的完整性，应支持[RFC2747]和[RFC3097]中定义的RSVP身份验证机制。它们逐跳保护RSVP消息完整性，并提供节点身份验证和重播保护，从而防止RSVP消息的损坏和欺骗。[RSVP-KEYING]讨论了用于RSVP身份验证的各种键控方法的适用性。首先，我们注意到，关于组键控适用于RSVP跳不是IP跳的提供商内部环境的讨论与部署本文档中指定的解决方案的给定服务提供商的PE之间的RSVP安全相关。我们注意到，MPLS VPN中的RSVP信令可能分布在多个管理域（例如，操作VPN服务的服务提供商和服务的客户）。因此，[RSVP-KEYING]中关于域间问题的考虑可能适用。
Since RSVP messages travel through the L3VPN cloud directly addressed to PE or ASBR routers (without IP Router Alert Option), P routers remain isolated from RSVP messages signaling customer reservations. Providers MAY choose to block PEs from sending datagrams with the Router Alert Option to P routers as a security practice, without impacting the functionality described herein.
由于RSVP消息通过L3VPN云直接发送到PE或ASBR路由器（无IP路由器警报选项），P路由器与发送客户预订信号的RSVP消息保持隔离。提供商可以选择阻止PEs使用路由器警报选项向P路由器发送数据报作为安全实践，而不会影响本文所述的功能。
Beyond those general issues, four specific issues are introduced by this document: resource usage on PEs, resource usage in the provider backbone, PE route advertisement outside the AS, and signaling exposure to ASBRs and PEs. We discuss these in turn.
除了这些一般问题外，本文还介绍了四个具体问题：PEs上的资源使用、提供商主干网中的资源使用、AS外的PE路由广告以及ASBR和PEs的信令暴露。我们依次讨论这些问题。
A customer who makes resource reservations on the CE-PE links for his sites is only competing for link resources with himself, as in standard RSVP, at least in the common case where each CE-PE link is dedicated to a single customer. Thus, from the perspective of the CE-PE links, the present document does not introduce any new security issues. However, because a PE typically serves multiple customers, there is also the possibility that a customer might attempt to use excessive computational resources on a PE (CPU cycles, memory, etc.) by sending large numbers of RSVP messages to a PE. In the extreme, this could represent a form of denial-of-service attack. In order to prevent such an attack, a PE SHOULD support mechanisms to limit the fraction of its processing resources that can be consumed by any one CE or by the set of CEs of a given customer. For example, a PE might implement a form of rate limiting on RSVP messages that it receives from each CE. We observe that these security risks and measures related to PE resource usage are very similar for any control-plane protocol operating between CE and PE (e.g., RSVP, routing, multicast).
在其站点的CE-PE链接上进行资源预订的客户仅与自己竞争链接资源，如在标准RSVP中，至少在每个CE-PE链接专用于单个客户的常见情况下。因此，从CE-PE链接的角度来看，本文件没有引入任何新的安全问题。然而，由于PE通常服务于多个客户，因此客户也可能试图通过向PE发送大量RSVP消息来使用PE上过多的计算资源（CPU周期、内存等）。在极端情况下，这可能代表一种形式的拒绝服务攻击。为了防止此类攻击，PE应支持限制任何一个CE或给定客户的一组CE可以消耗的部分处理资源的机制。例如，PE可能对从每个CE接收的RSVP消息实施一种速率限制形式。我们观察到，对于在CE和PE之间运行的任何控制平面协议（例如，RSVP、路由、多播），这些与PE资源使用相关的安全风险和措施非常相似。
The second concern arises only when the service provider chooses to offer resource reservation across the backbone, as described in Section 4. In this case, the concern may be that a single customer might attempt to reserve a large fraction of backbone capacity, perhaps with a coordinated effort from several different CEs, thus denying service to other customers using the same backbone. [RFC4804] provides some guidance on the security issues when RSVP reservations are aggregated onto MPLS tunnels, which are applicable to the situation described here. We note that a provider MAY use local policy to limit the amount of resources that can be reserved by a given customer from a particular PE, and that a policy server could be used to control the resource usage of a given customer across multiple PEs if desired. It is RECOMMENDED that an implementation of this specification support local policy on the PE to control the amount of resources that can be reserved by a given customer/CE.
第二个问题仅在服务提供商选择跨主干网提供资源预留时出现，如第4节所述。在这种情况下，问题可能是单个客户可能会试图保留主干网容量的很大一部分，这可能需要多个不同CE的协调工作，从而拒绝向使用同一主干网的其他客户提供服务。[RFC4804]提供了在将RSVP保留聚合到MPLS隧道时安全问题的一些指导，适用于此处描述的情况。我们注意到，提供商可以使用本地策略来限制给定客户可以从特定PE保留的资源量，并且如果需要，可以使用策略服务器来控制多个PE中给定客户的资源使用。建议本规范的实现支持PE上的本地策略，以控制给定客户/CE可以保留的资源量。
Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4 route to another AS, and potentially could allow unchecked access to remote PEs if those routes were indiscriminately redistributed. However, as described in Section 3.1, no route that is not within a customer's VPN should ever be advertised to (or be reachable from) that customer. If a PE uses a local address already within a customer VRF (like PE-CE link address), it MUST NOT send this address in any RSVP messages in a different customer VRF. A "control-plane" VPN MAY be created across PEs and ASBRs and addresses in this VPN can be used to signal RSVP sessions for any customers, but these routes MUST NOT be advertised to, or made reachable from, any customer. An implementation of the present document MAY support such operation using a "control-plane" VPN. Alternatively, ASBRs MAY implement the
使用VPN-IPv4 RSVP_-HOP对象需要将PE VPN-IPv4路由导出到另一个AS，并且如果不加区分地重新分配这些路由，则可能允许未经检查的访问远程PE。但是，如第3.1节所述，任何不在客户VPN内的路由都不应向该客户发布广告（或可从该客户访问）。如果PE使用客户VRF中已有的本地地址（如PE-CE链接地址），则不得在其他客户VRF中的任何RSVP消息中发送此地址。可在PEs和ASBR之间创建“控制平面”VPN，该VPN中的地址可用于向任何客户发送RSVP会话信号，但不得向任何客户播发或使任何客户都可以访问这些路由。本文档的一个实现可以使用“控制平面”VPN支持这种操作。或者，ASBR可以实现
signaling procedures described in Section 5.2.1, even if admission control is not required on the inter-AS link, as these procedures do not require any direct P/PE route advertisement out of the AS.
第5.2.1节中描述的信令程序，即使AS间链路上不需要准入控制，因为这些程序不需要AS外的任何直接P/PE路由广告。
Finally, certain operations described herein (Section 3) require an ASBR or PE to receive and locally process a signaling packet addressed to the BGP next hop address advertised by that router. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. This could be viewed as opening ASBRs and PEs to being directly addressable by customer devices where they were not open before, and could be considered a security issue. If a provider wishes to mitigate this situation, the implementation MAY support the "control protocol VPN" approach described above. That is, whenever a signaling message is to be sent to a PE or ASBR, the address of the router in question would be looked up in the "control protocol VPN", and the message would then be sent on the LSP that is found as a result of that lookup. This would ensure that the router address is not reachable by customer devices.
最后，本文描述的某些操作（第3节）要求ASBR或PE接收并本地处理寻址到该路由器所通告的BGP下一跳地址的信令分组。此要求不严格适用于MPLS/BGP VPN[RFC4364]。这可以被视为打开ASBR和PEs，使其可以由以前未打开的客户设备直接寻址，并且可以被视为一个安全问题。如果提供商希望缓解这种情况，则实现可支持上述“控制协议VPN”方法。也就是说，每当将信令消息发送到PE或ASBR时，将在“控制协议VPN”中查找所述路由器的地址，然后将在作为该查找结果而找到的LSP上发送该消息。这将确保客户设备无法访问路由器地址。
[RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE basis:
[RFC4364]提到在CE-CE和PE-PE基础上使用IPsec：
Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired.
该体系结构、帧中继或ATM VPN均不提供加密隐私。如果需要的话，这些体系结构都与CE-CE基础上的加密技术的使用兼容。
The use of cryptography on a PE-PE basis is for further study.
在PE-PE基础上使用密码学有待进一步研究。
The procedures specified in the present document for admission control on the PE-CE links (Section 3) are compatible with the use of IPsec on a PE-PE basis. The optional procedures specified in the present document for admission control in the Service Provider's backbone (Section 4) are not compatible with the use of IPsec on a PE-PE basis, since those procedures depend on the use of PE-PE MPLS TE Tunnels to perform aggregate reservations through the Service Provider's backbone.
本文件中规定的PE-CE链路准入控制程序（第3节）与在PE-PE基础上使用IPsec兼容。本文件中针对服务提供商主干网中的准入控制规定的可选程序（第4节）与在PE-PE基础上使用IPsec不兼容，因为这些程序依赖于使用PE-PE MPLS TE隧道通过服务提供商主干网执行聚合保留。
[RFC4923] describes a model for RSVP operation through IPsec Gateways. In a nutshell, a form of hierarchical RSVP reservation is used where an RSVP reservation is made for the IPsec tunnel and then individual RSVP reservations are admitted/aggregated over the tunnel reservation. This model applies to the case where IPsec is used on a CE-CE basis. In that situation, the procedures defined in the present document would simply apply "as is" to the reservation established for the IPsec tunnel(s).
[RFC4923]描述了通过IPsec网关进行RSVP操作的模型。简而言之，在为IPsec隧道进行RSVP预留的情况下，使用分层RSVP预留的形式，然后通过隧道预留允许/聚合单个RSVP预留。此模型适用于在CE-CE基础上使用IPsec的情况。在这种情况下，本文件中定义的程序将仅“按原样”适用于为IPsec隧道建立的保留。
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Rosen, Dan Tappan, and Lou Berger for their many contributions to solving the problems described in this document. Thanks to Ferit Yegenoglu for his useful comments. We also thank Stefan Santesson, Vijay Gurbani, and Alexey Melnikov for their review comments. We thank Richard Woundy for his very thorough review and comments including those that resulted in additional text discussing scenarios of admission control reject in the MPLS VPN cloud. Also, we thank Adrian Farrel for his detailed review and contributions.
感谢Ashwini Dahiya、Prashant Srinivas、Yakov Rekhter、Eric Rosen、Dan Tappan和Lou Berger为解决本文档中描述的问题做出的许多贡献。感谢Ferit Yegenoglu的有用评论。我们还感谢Stefan Santesson、Vijay Gurbani和Alexey Melnikov的评论。我们感谢Richard Woundy非常透彻的审查和评论，包括那些导致额外文本讨论MPLS VPN云中拒绝接纳控制场景的评论。此外，我们感谢阿德里安·法雷尔的详细评论和贡献。
At this stage, a number of alternatives to the approach described above have been considered. We document some of the approaches considered here to assist future discussion. None of these have been shown to improve upon the approach described above, and the first two seem to have significant drawbacks relative to the approach described above.
在这一阶段，已经考虑了上述方法的若干备选方案。我们记录了这里考虑的一些方法，以协助今后的讨论。这些都没有显示出对上述方法的改进，与上述方法相比，前两种方法似乎有明显的缺点。
Appendix A.1. GMPLS UNI Approach
附录A.1。GMPLS-UNI方法
[RFC4208] defines the GMPLS UNI. In Section 7, the operation of the GMPLS UNI in a VPN context is briefly described. This is somewhat similar to the problem tackled in the current document. The main difference is that the GMPLS UNI is primarily aimed at the problem of allowing a CE device to request the establishment of a Label Switched Path (LSP) across the network on the other side of the UNI. Hence, the procedures in [RFC4208] would lead to the establishment of an LSP across the VPN provider's network for every RSVP request received, which is not desired in this case.
[RFC4208]定义了GMPLS UNI。在第7节中，简要描述了GMPLS UNI在VPN上下文中的操作。这与当前文档中处理的问题有些类似。主要区别在于GMPLS UNI主要针对允许CE设备请求在UNI的另一侧的网络上建立标签交换路径（LSP）的问题。因此，[RFC4208]中的程序将导致在VPN提供商的网络上为接收到的每个RSVP请求建立LSP，这在这种情况下是不需要的。
To the extent possible, the approach described in this document is consistent with [RFC4208], while filling in more of the details and avoiding the problem noted above.
在可能的范围内，本文件中描述的方法与[RFC4208]一致，同时填写更多细节并避免上述问题。
Appendix A.2. Label Switching Approach
附录A.2。标签交换方法
Implementations that always look at IP headers inside the MPLS label on the egress PE can intercept Path messages and determine the correct VRF and RSVP state by using a combination of the encapsulating VPN label and the IP header. In our view, this is an undesirable approach for two reasons. Firstly, it imposes a new MPLS forwarding requirement for all data packets on the egress PE. Secondly, it requires using the encapsulating MPLS label to identify RSVP state, which runs counter to existing RSVP principle and practice where all information used to identify RSVP state is included within RSVP objects. RSVP extensions such as COPS/RSVP [RFC2749] which re-encapsulate RSVP messages are incompatible with this change.
始终查看出口PE上MPLS标签内IP报头的实现可以截获路径消息，并通过使用封装VPN标签和IP报头的组合来确定正确的VRF和RSVP状态。我们认为，这是一种不可取的做法，原因有二。首先，它对出口PE上的所有数据包施加了新的MPLS转发要求。其次，它需要使用封装MPLS标签来标识RSVP状态，这与现有的RSVP原则和实践背道而驰，在现有的RSVP原则和实践中，用于标识RSVP状态的所有信息都包含在RSVP对象中。重新封装RSVP消息的RSVP扩展（如COPS/RSVP[RFC2749]）与此更改不兼容。
Appendix A.3. VRF Label Approach
附录A.3。VRF标签法
Another approach to solving the problems described here involves the use of label switching to ensure that Path, Resv, and other RSVP messages are directed to the appropriate VRF on the next RSVP hop (e.g., egress PE). One challenge with such an approach is that [RFC4364] does not require labels to be allocated for VRFs, only for customer prefixes, and that there is no simple, existing method for
解决本文所述问题的另一种方法涉及使用标签交换，以确保路径、Resv和其他RSVP消息被定向到下一RSVP跳（例如出口PE）上的适当VRF。这种方法的一个挑战是[RFC4364]不要求为VRF分配标签，只要求为客户前缀分配标签，并且没有简单的现有方法来分配标签
advertising the fact that a label is bound to a VRF. If, for example, an ingress PE sent a Path message labelled with a VPN label that was advertised by the egress PE for the prefix that matches the destination address in the Path, there is a risk that the egress PE would simply label-switch the Path directly on to the CE without performing RSVP processing.
宣传标签与VRF绑定的事实。例如，如果入口PE发送带有VPN标签的路径消息，该VPN标签由出口PE针对与路径中的目的地地址匹配的前缀通告，则存在出口PE将直接将路径标记为切换到CE而不执行RSVP处理的风险。
A second challenge with this approach is that an IP address needs to be associated with a VRF and used as the PHOP address for the Path message sent from ingress PE to egress PE. That address needs to be reachable from the egress PE, and to exist in the VRF at the ingress PE. Such an address is not always available in today's deployments, so this represents at least a change to existing deployment practices.
这种方法的第二个挑战是，IP地址需要与VRF关联，并用作从入口PE发送到出口PE的路径消息的PHOP地址。该地址需要可从出口PE访问，并存在于入口PE的VRF中。这样的地址在今天的部署中并不总是可用的，因此这至少代表了对现有部署实践的更改。
Appendix A.4. VRF Label Plus VRF Address Approach
附录A.4。VRF标签加VRF地址方法
It is possible to create an approach based on that described in the previous section that addresses the main challenges of that approach. The basic approach has two parts: (a) define a new BGP Extended Community to tag a route (and its associated MPLS label) as pointing to a VRF; (b) allocate a "dummy" address to each VRF, specifically to be used for routing RSVP messages. The dummy address (which could be anything, e.g., a loopback of the associated PE) would be used as a PHOP for Path messages and would serve as the destination for Resv messages but would not be imported into VRFs of any other PE.
可以基于上一节中描述的方法创建一种解决该方法主要挑战的方法。基本方法有两部分：（a）定义一个新的BGP扩展社区，将路由（及其相关的MPLS标签）标记为指向VRF；（b） 为每个VRF分配一个“虚拟”地址，专门用于路由RSVP消息。虚拟地址（可以是任何东西，例如关联PE的环回）将用作路径消息的PHOP，并将用作Resv消息的目的地，但不会导入任何其他PE的VRF。
References
工具书类
Normative References
规范性引用文件
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[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月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月。
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804]Le Faucheur，F.，“MPLS TE/DS-TE隧道上资源预留协议（RSVP）预留的聚合”，RFC 4804，2007年2月。
Informative References
资料性引用
[ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, July 2010.
[警报使用]Le Faucheur，F.，Ed.，“IP路由器警报注意事项和使用”，正在进行的工作，2010年7月。
[LER-OPTIONS] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", Work in Progress, May 2010.
[LER-OPTIONS]Smith，D.，Mullooly，J.，Jaeger，W.，和T.Scholl，“IPv4选项数据包的标签边缘路由器转发要求”，正在进行的工作，2010年5月。
[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月。
[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月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]达勒姆，D.，博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.，和A.萨斯特里，“共同开放政策服务协议”，RFC 27482000年1月。
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[RFC2749]Herzog，S.，Boyle，J.，Cohen，R.，Durham，D.，Rajan，R.，和A.Sastry，“警察对RSVP的使用”，RFC 2749，2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[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月。
[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月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[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月。
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007.
[RFC4923]Baker，F.和P.Bose，“嵌套虚拟专用网络中的服务质量（QoS）信令”，RFC 49232007年8月。
[RFC5824] Kumaki, K., Zhang, R., and Y. Kamite, "Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN", RFC 5824, April 2010.
[RFC5824]Kumaki，K.，Zhang，R.，和Y.Kamite，“通过BGP/MPLS IP-VPN支持客户资源预留协议（RSVP）和RSVP流量工程（RSVP-TE）的要求”，RFC 58242010年4月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信号传输”，RFC 59712010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RSVP-KEYING] Behringer, M., Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", Work in Progress, September 2010.
[RSVP-KEYING]Behringer，M.，Faucheur，F.，和B.Weis，“RSVP安全的键控方法的适用性”，正在进行的工作，2010年9月。
Authors' Addresses
作者地址
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
布鲁斯·戴维斯思科系统公司，马萨诸塞州1414年。美国马萨诸塞州博克斯伯勒大道01719号
EMail: bsd@cisco.com
EMail: bsd@cisco.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille Biot Sophia-Antipolis 06410 France
Francois Le Faucheur Cisco Systems，Inc.绿边企业村-法国索菲亚安提波利斯市鲁曼尼耶大道T3400号巴蒂门特06410
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Ashok Narayanan Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
Ashok Narayanan思科系统公司，马萨诸塞州1414。美国马萨诸塞州博克斯伯勒大道01719号
EMail: ashokn@cisco.com
EMail: ashokn@cisco.com