Internet Engineering Task Force (IETF) K. Kumaki, Ed.
Request for Comments: 5824 KDDI Corporation
Category: Informational R. Zhang
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications Corporation
April 2010
Internet Engineering Task Force (IETF) K. Kumaki, Ed.
Request for Comments: 5824 KDDI Corporation
Category: Informational R. Zhang
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications Corporation
April 2010
Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN
在BGP/MPLS IP-VPN上支持客户资源预留协议（RSVP）和RSVP流量工程（RSVP-TE）的要求
Abstract
摘要
Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.
如今，客户希望通过BGP/MPLS IP VPN运行三网融合服务。一些服务提供商将通过网络部署从本地客户边缘（CE）到远程CE请求服务质量（QoS）保证的服务。因此，应用程序（例如，语音、视频、带宽保证数据管道等）对端到端QoS和保留足够带宽的要求继续增加。
Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN.
服务提供商可以同时使用MPLS和MPLS流量工程（MPLS-TE）标签交换路径（LSP）来满足其服务目标。本文档描述了服务提供商在BGP/MPLS IP-VPN上支持客户资源预留协议（RSVP）和RSVP-TE的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5824.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5824.
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
2. Requirements Language ...........................................4
3. Terminology .....................................................5
4. Problem Statement ...............................................5
5. Application Scenarios ...........................................7
5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............8
5.2. Scenario II: Strict C-TE LSP QoS Guarantees ................8
5.3. Scenario III: Load Balance of CE-to-CE Traffic .............9
5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........11
5.5. Scenario V: RSVP over Non-TE LSPs .........................12
5.6. Scenario VI: RSVP-TE over Non-TE LSPs .....................13
6. Detailed Requirements for C-TE LSP Model .......................14
6.1. Selective P-TE LSPs .......................................14
6.2. Graceful Restart Support for C-TE LSPs ....................14
6.3. Rerouting Support for C-TE LSPs ...........................15
6.4. FRR Support for C-TE LSPs .................................15
6.5. Admission Control Support on P-TE LSP Head-Ends ...........15
6.6. Admission Control Support for C-TE LSPs in
LDP-Based Core Networks ...................................16
6.7. Policy Control Support for C-TE LSPs ......................16
6.8. PCE Features Support for C-TE LSPs ........................16
6.9. Diversely Routed C-TE LSP Support .........................16
6.10. Optimal Path Support for C-TE LSPs .......................17
6.11. Reoptimization Support for C-TE LSPs .....................17
6.12. DS-TE Support for C-TE LSPs ..............................17
7. Detailed Requirements for C-RSVP Path Model ....................18
7.1. Admission Control between PE-CE for C-RSVP Paths ..........18
7.2. Aggregation of C-RSVP Paths by P-TE LSPs ..................18
7.3. Non-TE LSP Support for C-RSVP Paths .......................18
7.4. Transparency of C-RSVP Paths ..............................18
8. Commonly Detailed Requirements for Two Models ..................18
8.1. CE-PE Routing .............................................18
8.2. Complexity and Risks ......................................19
8.3. Backward Compatibility ....................................19
8.4. Scalability Considerations ................................19
8.5. Performance Considerations ................................19
8.6. Management Considerations .................................20
9. Security Considerations ........................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
Acknowledgments....................................................23
Appendix A. Reference Model........................................24
A.1 End-to-End C-RSVP Path Model................................24
A.2 End-to-End C-TE LSP Model...................................25
1. Introduction ....................................................4
2. Requirements Language ...........................................4
3. Terminology .....................................................5
4. Problem Statement ...............................................5
5. Application Scenarios ...........................................7
5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............8
5.2. Scenario II: Strict C-TE LSP QoS Guarantees ................8
5.3. Scenario III: Load Balance of CE-to-CE Traffic .............9
5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........11
5.5. Scenario V: RSVP over Non-TE LSPs .........................12
5.6. Scenario VI: RSVP-TE over Non-TE LSPs .....................13
6. Detailed Requirements for C-TE LSP Model .......................14
6.1. Selective P-TE LSPs .......................................14
6.2. Graceful Restart Support for C-TE LSPs ....................14
6.3. Rerouting Support for C-TE LSPs ...........................15
6.4. FRR Support for C-TE LSPs .................................15
6.5. Admission Control Support on P-TE LSP Head-Ends ...........15
6.6. Admission Control Support for C-TE LSPs in
LDP-Based Core Networks ...................................16
6.7. Policy Control Support for C-TE LSPs ......................16
6.8. PCE Features Support for C-TE LSPs ........................16
6.9. Diversely Routed C-TE LSP Support .........................16
6.10. Optimal Path Support for C-TE LSPs .......................17
6.11. Reoptimization Support for C-TE LSPs .....................17
6.12. DS-TE Support for C-TE LSPs ..............................17
7. Detailed Requirements for C-RSVP Path Model ....................18
7.1. Admission Control between PE-CE for C-RSVP Paths ..........18
7.2. Aggregation of C-RSVP Paths by P-TE LSPs ..................18
7.3. Non-TE LSP Support for C-RSVP Paths .......................18
7.4. Transparency of C-RSVP Paths ..............................18
8. Commonly Detailed Requirements for Two Models ..................18
8.1. CE-PE Routing .............................................18
8.2. Complexity and Risks ......................................19
8.3. Backward Compatibility ....................................19
8.4. Scalability Considerations ................................19
8.5. Performance Considerations ................................19
8.6. Management Considerations .................................20
9. Security Considerations ........................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
Acknowledgments....................................................23
Appendix A. Reference Model........................................24
A.1 End-to-End C-RSVP Path Model................................24
A.2 End-to-End C-TE LSP Model...................................25
Some service providers want to build a service that guarantees Quality of Service (QoS) and a bandwidth from a local Customer Edge (CE) to a remote CE through the network. A CE includes the network client equipment owned and operated by the service provider. However, the CE may not be part of the MPLS provider network.
一些服务提供商希望构建一种服务，以保证服务质量（QoS）和通过网络从本地客户边缘（CE）到远程CE的带宽。CE包括由服务提供商拥有和操作的网络客户端设备。然而，CE可能不是MPLS提供商网络的一部分。
Today, customers expect to run triple-play services such as Internet access, telephone, and television through BGP/MPLS IP-VPNs [RFC4364].
如今，客户希望通过BGP/MPLS IP VPN[RFC4364]运行三网融合服务，如互联网接入、电话和电视。
As these services evolve, the requirements for an end-to-end QoS to meet the application requirements also continue to grow. Depending on the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.), a native IP using an RSVP and/or an end-to-end constrained MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) may be required. The RSVP path may be used to provide QoS guarantees and reserve an adequate bandwidth for the data. An end-to-end MPLS-TE LSP may also be used to guarantee a bandwidth, and provide extended functionality like MPLS fast reroute (FRR) [RFC4090] for maintaining the service continuity around node and link, including the CE-PE link, failures. It should be noted that an RSVP session between two CEs may also be mapped and tunneled into an MPLS-TE LSP across an MPLS provider network.
随着这些服务的发展，满足应用程序需求的端到端QoS需求也在不断增长。根据应用（例如，语音、视频、带宽保证数据管道等），可能需要使用RSVP和/或端到端受限MPLS流量工程（MPLS-TE）标签交换路径（LSP）的本机IP。RSVP路径可用于提供QoS保证并为数据保留足够的带宽。端到端MPLS-TE LSP还可用于保证带宽，并提供诸如MPLS快速重路由（FRR）[RFC4090]之类的扩展功能，以维持节点和链路（包括CE-PE链路）周围的服务连续性。应当注意，两个ce之间的RSVP会话也可以通过MPLS提供商网络映射并隧道到MPLS-TE LSP中。
A number of advantages exist for deploying the model previously mentioned. The first is that customers can use these network services while being able to use both private addresses and global addresses. The second advantage is that the traffic is tunneled through the service-provider backbone so that customer traffic and route confidentiality are maintained.
部署前面提到的模型有许多优点。首先，客户可以使用这些网络服务，同时可以使用专用地址和全局地址。第二个优点是，流量通过服务提供商主干网进行隧道传输，以便维护客户流量和路由机密性。
This document defines a reference model, example application scenarios, and detailed requirements for a solution supporting a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
本文档定义了通过BGP/MPLS IP-VPN支持客户RSVP和RSVP-TE的解决方案的参考模型、示例应用场景和详细要求。
A specification for a solution is out of scope in this document.
解决方案的规范超出了本文档的范围。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the BGP/MPLS IP-VPN terminology defined in [RFC4364] and also uses Path Computation Element (PCE) terms defined in [RFC4655].
本文件使用了[RFC4364]中定义的BGP/MPLS IP-VPN术语，还使用了[RFC4655]中定义的路径计算元素（PCE）术语。
TE LSP: Traffic Engineering Label Switched Path
TE LSP：流量工程标签交换路径
MPLS-TE LSP: Multiprotocol Label Switching TE LSP
MPLS-TE LSP：多协议标签交换TE LSP
C-RSVP path: Customer RSVP path: a native RSVP path with the bandwidth reservation of X for customers
C-RSVP路径：客户RSVP路径：为客户预留X带宽的本机RSVP路径
C-TE LSP: Customer Traffic Engineering Label Switched Path: an end-to-end MPLS-TE LSP for customers
C-TE LSP：客户流量工程标签交换路径：面向客户的端到端MPLS-TE LSP
P-TE LSP: Provider Traffic Engineering Label Switched Path: a transport TE LSP between two Provider Edges (PEs)
P-TE LSP：提供商流量工程标签交换路径：两个提供商边缘（PE）之间的传输TE LSP
LSR: a Label Switched Router
LSR：一种标签交换路由器
Head-end LSR: an ingress LSR
前端LSR：入口LSR
Tail-end LSR: an egress LSR
尾端LSR：出口LSR
Service providers want to deliver triple-play services with QoS guarantees to their customers. Various techniques are available to achieve this. Some service providers will wish to offer advanced services using an RSVP signaling for native IP flows (C-RSVP) or an RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over BGP/MPLS IP-VPNs.
服务提供商希望向其客户提供具有QoS保证的三网融合服务。可以使用各种技术来实现这一点。一些服务提供商希望通过BGP/MPLS IP VPN为本机IP流（C-RSVP）使用RSVP信令或为客户TE LSP（C-TE LSP）使用RSVP-TE信令来提供高级服务。
The following examples outline each method:
以下示例概述了每种方法：
A C-RSVP path with the bandwidth reservation of X can be used to transport voice traffic. In order to achieve recovery in under 50 ms during link, node, and Shared Risk Link Group (SRLG) failures, and to provide strict QoS guarantees, a C-TE LSP with bandwidth X between data centers or customer sites can be used to carry voice and video traffic. Thus, service providers or customers can choose a C-RSVP path or a C-TE LSP to meet their requirements.
带宽保留为X的C-RSVP路径可用于传输语音流量。为了在链路、节点和共享风险链路组（SRLG）故障期间在50毫秒内实现恢复，并提供严格的QoS保证，可以使用数据中心或客户站点之间带宽为X的C-TE LSP来承载语音和视频流量。因此，服务提供商或客户可以选择C-RSVP路径或C-TE LSP来满足他们的需求。
When service providers offer a C-RSVP path between hosts or CEs over BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP path with the bandwidth reservation of X to the remote CE/host. However, if a C-RSVP signaling is to send within a VPN, the service-provider
当服务提供商通过BGP/MPLS IP VPN在主机或CE之间提供C-RSVP路径时，CE/主机向远程CE/主机请求保留带宽为X的端到端C-RSVP路径。但是，如果要在VPN内发送C-RSVP信令，则服务提供商
network will face scalability issues because routers need to retain the RSVP state per a customer. Therefore, in order to solve scalability issues, multiple C-RSVP reservations can be aggregated at a PE, where a P-TE LSP head-end can perform admission control using the aggregated C-RSVP reservations. The method that is described in [RFC4804] can be considered as a useful approach. In this case, a reservation request from within the context of a Virtual Routing and Forwarding (VRF) instance can get aggregated onto a P-TE LSP. The P-TE LSP can be pre-established, resized based on the request, or triggered by the request. Service providers, however, cannot provide a C-RSVP path over the VRF instance as defined in [RFC4364]. The current BGP/MPLS IP-VPN architecture also does not support an RSVP instance running in the context of a VRF to process RSVP messages and integrated services (int-serv) ([RFC1633], [RFC2210]). One solution is described in [RSVP-L3VPN].
网络将面临可伸缩性问题，因为路由器需要为每个客户保留RSVP状态。因此，为了解决可伸缩性问题，可以在PE处聚合多个C-RSVP预留，其中P-TE LSP前端可以使用聚合的C-RSVP预留执行接纳控制。[RFC4804]中描述的方法可视为一种有用的方法。在这种情况下，来自虚拟路由和转发（VRF）实例上下文中的保留请求可以聚合到P-TE LSP上。P-TE LSP可以预先建立、根据请求调整大小或由请求触发。但是，服务提供商不能在[RFC4364]中定义的VRF实例上提供C-RSVP路径。当前的BGP/MPLS IP-VPN体系结构也不支持在VRF上下文中运行的RSVP实例来处理RSVP消息和综合服务（int serv）（[RFC1633]，[RFC2210]）。[RSVP-L3VPN]中描述了一种解决方案。
If service providers offer a C-TE LSP from a CE to a CE over the BGP/MPLS IP-VPN, they require that an MPLS-TE LSP from a local CE to a remote CE be established. However, if a C-TE LSP signaling is to send within the VPN, the service-provider network may face the following scalability issues:
如果服务提供商通过BGP/MPLS IP-VPN提供从CE到CE的C-TE LSP，他们要求建立从本地CE到远程CE的MPLS-TE LSP。然而，如果要在VPN内发送C-TE LSP信令，则服务提供商网络可能面临以下可伸缩性问题：
- A C-TE LSP can be aggregated by a P-TE LSP at a PE (i.e., hierarchical LSPs). In this case, only a PE maintains the state of customer RSVP sessions.
- C-TE LSP可由PE处的P-TE LSP聚合（即，分层LSP）。在这种情况下，只有PE维护客户RSVP会话的状态。
- A C-TE LSP cannot be aggregated by a P-TE LSP at a PE, depending on some policies (i.e., continuous LSPs). In this case, both Ps and PEs maintain the state of customer RSVP sessions.
- 根据某些策略（即连续LSP），PE上的P-TE LSP无法聚合C-TE LSP。在这种情况下，Ps和PE都保持客户RSVP会话的状态。
- A C-TE LSP can be aggregated by the non-TE LSP (i.e., LDP). In this case, only a PE maintains the state of customer RSVP-TE sessions. Note that it is assumed that there is always enough bandwidth available in the service-provider core network.
- C-TE LSP可以由非TE LSP（即LDP）聚合。在这种情况下，只有PE维护客户RSVP-TE会话的状态。注意，假定服务提供商核心网络中始终有足够的可用带宽。
Furthermore, if service providers provide the C-TE LSP over the BGP/MPLS IP-VPN, they currently cannot provide it over the VRF instance as defined in [RFC4364]. Specifically, the current BGP/MPLS IP-VPN architecture does not support the RSVP-TE instance running in the context of a VRF to process RSVP messages and trigger the establishment of the C-TE LSP over the service-provider core network. If every C-TE LSP is to trigger the establishment or resizing of a P-TE LSP, the service-provider network will also face scalability issues that arise from maintaining a large number of P-TE LSPs and/or
此外，如果服务提供商通过BGP/MPLS IP-VPN提供C-TE LSP，则目前无法通过[RFC4364]中定义的VRF实例提供。具体而言，当前BGP/MPLS IP-VPN体系结构不支持在VRF上下文中运行的RSVP-TE实例来处理RSVP消息并触发通过服务提供商核心网络建立C-TE LSP。如果每个C-TE LSP要触发P-TE LSP的建立或大小调整，则服务提供商网络还将面临由于维护大量P-TE LSP和/或
the dynamic signaling of these P-TE LSPs. Section 8.4 of this document, "Scalability Considerations", provides detailed scalability requirements.
这些P-TE lsp的动态信令。本文件第8.4节“可伸缩性注意事项”提供了详细的可伸缩性要求。
Two different models have been described above. The differences between C-RSVP paths and C-TE LSPs are as follows:
上面已经描述了两种不同的模型。C-RSVP路径和C-TE LSP之间的区别如下：
- C-RSVP path model: data packets among CEs are forwarded by "native IP packets" (i.e., not labeled packets).
- C-RSVP路径模型：CE之间的数据包由“本机IP包”（即未标记的包）转发。
- C-TE LSP model: data packets among CEs are forwarded by "labeled IP packets".
- C-TE LSP模型：CE之间的数据包通过“标记IP包”转发。
Depending on the service level and the need to meet specific requirements, service providers should be able to choose P-TE LSPs or non-TE LSPs in the backbone network. The selection may be dependent on the service provider's policy and the node's capability to support the mechanisms described.
根据服务级别和满足特定要求的需要，服务提供商应能够在主干网中选择P-TE LSP或非TE LSP。选择可能取决于服务提供商的策略和节点支持所述机制的能力。
The items listed below are selectively required to support C-RSVP paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service level. For example, some service providers need all of the following items to provide a service, and some service providers need only some of them to provide the service. It depends on the service level and policy of service providers. Detailed requirements are described in Sections 6, 7, and 8.
根据服务级别，在BGP/MPLS IP VPN上支持C-RSVP路径和C-TE LSP有选择地需要下列各项。例如，一些服务提供商需要以下所有项目来提供服务，而一些服务提供商只需要其中的一部分来提供服务。这取决于服务提供商的服务水平和政策。详细要求见第6、7和8节。
- C-RSVP path QoS guarantees.
- C-RSVP路径QoS保证。
- Fast recovery over the BGP/MPLS IP-VPN to protect traffic for the C-TE LSP against CE-PE link failure and PE node failure.
- 通过BGP/MPLS IP-VPN进行快速恢复，以保护C-TE LSP的流量，防止CE-PE链路故障和PE节点故障。
- Strict C-TE LSP bandwidth and QoS guarantees.
- 严格的C-TE LSP带宽和QoS保证。
- Resource optimization for C-RSVP paths and C-TE LSPs.
- C-RSVP路径和C-TE LSP的资源优化。
- Scalability for C-RSVP paths and C-TE LSPs.
- C-RSVP路径和C-TE LSP的可扩展性。
The following sections present a few application scenarios for C-RSVP paths and C-TE LSPs in BGP/MPLS IP-VPN environments. Appendix A, "Reference Model", describes a C-RSVP path, a C-TE LSP, and a P-TE LSP.
以下各节介绍了BGP/MPLS IP-VPN环境中C-RSVP路径和C-TE LSP的一些应用场景。附录A“参考模型”描述了C-RSVP路径、C-TE LSP和P-TE LSP。
In all scenarios, it is the responsibility of the service provider to ensure that enough bandwidth is available to meet the customers' application requirements.
在所有情况下，服务提供商都有责任确保有足够的带宽满足客户的应用程序需求。
In this scenario, as shown in Figure 1, a customer uses a VoIP application between its sites (i.e., between CE1 and CE2). H0 and H1 represent voice equipment.
在此场景中，如图1所示，客户在其站点之间（即CE1和CE2之间）使用VoIP应用程序。H0和H1表示语音设备。
In this case, the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
在这种情况下，客户将C-TE LSP1建立为主路径，并将C-TE LSP2建立为备份路径。如果PE1和CE1之间的链路或PE1的节点出现故障，则C-TE LSP1需要C-TE LSP2作为路径保护。
Generally speaking, C-RSVP paths are used by customers, and P-TE LSPs are used by service providers.
一般来说，客户使用C-RSVP路径，服务提供商使用P-TE LSP路径。
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
network network
<--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
network network
Figure 1. Scenario I
图1。情景一
In this scenario, as shown in Figure 2, service provider B (SP B) transports voice and video traffic between its sites (i.e., between CE1 and CE2). In this case, service provider B establishes C-TE LSP1 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic, and C-TE LSP2 with preemption priority 1 and 200-Mbps bandwidth for the unicast video traffic. On the other hand, service provider A (SP A) also pre-establishes P-TE LSP1 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2 with preemption priority 1 and 2-Gbps bandwidth for the video
在此场景中，如图2所示，服务提供商B（SP B）在其站点之间（即CE1和CE2之间）传输语音和视频流量。在这种情况下，服务提供商B为语音业务建立抢占优先级为0和100 Mbps带宽的C-TE LSP1，为单播视频业务建立抢占优先级为1和200 Mbps带宽的C-TE LSP2。另一方面，服务提供商A（SP A）还为语音业务预先建立具有抢占优先级0和1-Gbps带宽的P-TE LSP1，为视频业务预先建立具有抢占优先级1和2-Gbps带宽的P-TE LSP2
traffic. In this scenario, P-TE LSP1 and P-TE LSP2 should support Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124].
交通在此场景中，P-TE LSP1和P-TE LSP2应支持区分服务感知MPLS流量工程（DS-TE）[RFC4124]。
PE1 and PE3 should choose an appropriate P-TE LSP based on the preemption priority. In this case, C-TE LSP1 must be associated with P-TE LSP1 at PE1, and C-TE LSP2 must be associated with P-TE LSP2 at PE3.
PE1和PE3应根据抢占优先级选择适当的P-TE LSP。在这种情况下，C-TE LSP1必须与PE1处的P-TE LSP1相关联，C-TE LSP2必须与PE3处的P-TE LSP2相关联。
Furthermore, PE1 and PE3 head-ends should control the bandwidth of C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the amount of maximum available bandwidth for each P-TE LSP, respectively.
此外，PE1和PE3头端应控制C-TE LSP的带宽。在这种情况下，PE1和PE3可以分别根据每个P-TE LSP的最大可用带宽量来选择C-TE LSP。
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
network SP A network network
<---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
network SP A network network
Figure 2. Scenario II
图2。情景二
It's possible that the customer and the service provider have differing preemption priorities. In this case, the PE policy will override the customers. In the case where the service provider does not support preemption priorities, then such priorities should be ignored.
客户和服务提供商可能有不同的优先权。在这种情况下，PE策略将覆盖客户。如果服务提供商不支持抢占优先级，则应忽略此类优先级。
In this scenario, as shown in Figure 3, service provider C (SP C) uses voice and video traffic between its sites (i.e., between CE0 and CE5/CE7, between CE2 and CE5/CE7, between CE5 and CE0/CE2, and between CE7 and CE0/CE2). H0 and H1 represent voice and video equipment. In this case, service provider C establishes C-TE LSP1,
在该场景中，如图3所示，服务提供商C（SP C）使用其站点之间的语音和视频流量（即CE0和CE5/CE7之间、CE2和CE5/CE7之间、CE5和CE0/CE2之间以及CE7和CE0/CE2之间）。H0和H1表示语音和视频设备。在这种情况下，服务提供商C建立C-TE LSP1，
C-TE LSP3, C-TE LSP5, and C-TE LSP7 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic, and establishes C-TE LSP2, C-TE LSP4, C-TE LSP6, and C-TE LSP8 with preemption priority 1 and 200-Mbps bandwidth for the video traffic. On the other hand, service provider A also pre-establishes P-TE LSP1 and P-TE LSP3 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2 and P-TE LSP4 with preemption priority 1 and 2-Gbps bandwidth for the video traffic. In this scenario, P-TE LSP1, P-TE LSP2, P-TE LSP3, and P-TE LSP4 should support DS-TE [RFC4124].
为语音业务建立抢占优先级为0和100 Mbps带宽的C-TE LSP3、C-TE LSP5和C-TE LSP7，为视频业务建立抢占优先级为1和200 Mbps带宽的C-TE LSP2、C-TE LSP4、C-TE LSP6和C-TE LSP8。另一方面，服务提供商A还为语音业务预先建立具有抢占优先级0和1-Gbps带宽的P-TE LSP1和P-TE LSP3，为视频业务预先建立具有抢占优先级1和2-Gbps带宽的P-TE LSP2和P-TE LSP4。在此场景中，P-TE LSP1、P-TE LSP2、P-TE LSP3和P-TE LSP4应支持DS-TE[RFC4124]。
All PEs should choose an appropriate P-TE LSP based on the preemption priority. To minimize the traffic disruption due to a single network failure, diversely routed C-TE LSPs are established. In this case, the FRR [RFC4090] is not necessarily required.
所有PE应根据抢占优先级选择适当的P-TE LSP。为了最大限度地减少由于单一网络故障造成的流量中断，建立了不同路由的C-TE LSP。在这种情况下，不一定需要FRR[RFC4090]。
Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with 0 bandwidth) [RFC5330] are applicable to this scenario.
此外，无约束TE LSP（即，带宽为0的C-TE LSP/P-TE LSP）[RFC5330]也适用于该场景。
Furthermore, the load balancing for any communication between H0 and H1 can be done by setting up full-mesh C-TE LSPs between CE0/CE2 and CE5/CE7.
此外，可以通过在CE0/CE2和CE5/CE7之间设置全网状C-TE LSP来实现H0和H1之间任何通信的负载平衡。
C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
(CE0<-CE1<-...<-CE4<-CE5)
<---------------------------------------------->
C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
(CE0<-CE1<-...<-CE4<-CE5)
<---------------------------------------------->
C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
(CE2<-CE1<-...<-CE4<-CE7)
<---------------------------------------------->
P-TE LSP1 (p=0)
<-------------------->
P-TE LSP2 (p=1)
<-------------------->
.................. ..................
. --- --- . --- --- --- --- . --- --- .
. |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
. --- /--- --- . --- --- --- --- . --- ---\ --- .
.|H0 | + . + . + |H1 |.
. --- \--- --- . --- --- --- --- . --- ---/ --- .
. |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
. --- --- . --- --- --- --- . --- --- .
.................. ..................
<-------------------->
P-TE LSP3 (p=0)
<-------------------->
P-TE LSP4 (p=1)
<---------------------------------------------->
C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
(CE0<-CE3<-...<-CE6<-CE5)
C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
(CE2<-CE1<-...<-CE4<-CE7)
<---------------------------------------------->
P-TE LSP1 (p=0)
<-------------------->
P-TE LSP2 (p=1)
<-------------------->
.................. ..................
. --- --- . --- --- --- --- . --- --- .
. |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
. --- /--- --- . --- --- --- --- . --- ---\ --- .
.|H0 | + . + . + |H1 |.
. --- \--- --- . --- --- --- --- . --- ---/ --- .
. |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
. --- --- . --- --- --- --- . --- --- .
.................. ..................
<-------------------->
P-TE LSP3 (p=0)
<-------------------->
P-TE LSP4 (p=1)
<---------------------------------------------->
C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
(CE0<-CE3<-...<-CE6<-CE5)
<---------------------------------------------->
C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
(CE2<-CE3<-...<-CE6<-CE7)
<---------------------------------------------->
C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
(CE2<-CE3<-...<-CE6<-CE7)
<-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
network SP A network network
<-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
network SP A network network
Figure 3. Scenario III
图3。情景三
In this scenario, as shown in Figure 4, the customer has two hosts connecting to CE1 and CE2, respectively. CE1 and CE2 are connected to PE1 and PE2, respectively, within a VRF instance belonging to the same VPN. The requesting host (H1) may request from H2 an RSVP path with the bandwidth reservation of X. This reservation request from within the context of VRF will get aggregated onto a pre-established P-TE/DS-TE LSP based upon procedures similar to [RFC4804]. As in the case of [RFC4804], there may be multiple P-TE LSPs belonging to different DS-TE class-types. Local policies can be implemented to
在这个场景中，如图4所示，客户有两台主机分别连接到CE1和CE2。CE1和CE2分别连接到属于同一VPN的VRF实例中的PE1和PE2。请求主机（H1）可以从H2请求带宽保留为X的RSVP路径。VRF上下文中的该保留请求将根据类似于[RFC4804]的程序聚合到预先建立的P-TE/DS-TE LSP上。与[RFC4804]的情况一样，可能存在属于不同DS-TE类类型的多个P-TE LSP。地方政策可以实施到
map the incoming RSVP path request from H1 to the P-TE LSP with the appropriate class-type. Please note that the end-to-end (e2e) RSVP path request may also be initiated by the CE devices themselves.
将传入的RSVP路径请求从H1映射到具有适当类类型的P-TE LSP。请注意，端到端（e2e）RSVP路径请求也可能由CE设备本身发起。
C-RSVP path
<----------------------------------------------------->
C-RSVP path
<----------------------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
network network
<-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 4. Scenario IV
图4。情景四
In this scenario, as shown in Figure 5, a customer has two hosts connecting to CE1 and CE2, respectively. CE1 and CE2 are connected to PE1 and PE2, respectively, within a VRF instance belonging to the same VPN. The requesting host (H1) may request from H2 an RSVP path with the bandwidth reservation of X. In this case, a non-TE LSP (i.e., LDP, etc.) is provided between PEs and has LDP, which supports MPLS Diffserv [RFC3270].
在这个场景中，如图5所示，客户有两台主机分别连接到CE1和CE2。CE1和CE2分别连接到属于同一VPN的VRF实例中的PE1和PE2。请求主机（H1）可以从H2请求带宽保留为X的RSVP路径。在这种情况下，在PEs和has LDP之间提供非TE LSP（即LDP等），其支持MPLS区分服务[RFC3270]。
Note that this only provides Diffserv, and not the bandwidth reservation as is done with RSVP-TE.
请注意，这只提供区分服务，而不提供与RSVP-TE相同的带宽预留。
Local policies can be implemented to map the customer's reserved flow to the LSP with the appropriate Traffic Class [RFC5462] at PE1.
可以实施本地策略，以将客户的保留流量映射到PE1处具有适当流量等级[RFC5462]的LSP。
C-RSVP path
<------------------------------------------>
C-RSVP path
<------------------------------------------>
Non-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
Non-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 5. Scenario V
图5。情景五
In this scenario, as shown in Figure 6, a customer uses a VoIP application between its sites (i.e., between CE1 and CE2). H0 and H1 represent voice equipment. In this case, a non-TE LSP means LDP, and the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
在此场景中，如图6所示，客户在其站点之间（即CE1和CE2之间）使用VoIP应用程序。H0和H1表示语音设备。在这种情况下，非TE LSP意味着LDP，并且客户建立C-TE LSP1作为主路径，C-TE LSP2作为备份路径。如果PE1和CE1之间的链路或PE1的节点出现故障，则C-TE LSP1需要C-TE LSP2作为路径保护。
C-TE LSP1
<----------------------------------------->
Non-TE LSP
<-------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
--- --- --- ---
C-TE LSP1
<----------------------------------------->
Non-TE LSP
<-------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
--- --- --- ---
<-------------------------->
Non-TE LSP
<----------------------------------------->
C-TE LSP2
<-------------------------->
Non-TE LSP
<----------------------------------------->
C-TE LSP2
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
Figure 6. Scenario VI
图6。情景六
This section describes detailed requirements for C-TE LSPs in BGP/MPLS IP-VPN environments.
本节描述了BGP/MPLS IP-VPN环境中C-TE LSP的详细要求。
The solution MUST provide the ability to decide which P-TE LSPs a PE uses for a C-RSVP path and a C-TE LSP. When a PE receives a native RSVP and/or a path message from a CE, it MUST be able to decide which P-TE LSPs it uses. In this case, various kinds of P-TE LSPs exist in the service-provider network. For example, the PE MUST choose an appropriate P-TE LSP based on local policies such as:
该解决方案必须能够决定PE将哪些P-TE LSP用于C-RSVP路径和C-TE LSP。当PE从CE接收本机RSVP和/或path消息时，它必须能够决定使用哪个P-TE LSP。在这种情况下，服务提供商网络中存在各种P-TE lsp。例如，PE必须根据当地政策选择适当的P-TE LSP，例如：
1. preemption priority 2. affinity 3. class-type 4. on the data plane: (Differentiated Services Code Point (DSCP) or Traffic Class bits)
1. 抢占优先权2。亲和力3。第四类。在数据平面上：（区分服务代码点（DSCP）或流量类位）
The solution SHOULD support the graceful restart capability, where the C-TE LSP traffic continues to be forwarded during a PE graceful restart. Graceful restart mechanisms related to this architecture are described in [RFC3473], [RFC3623], and [RFC4781].
该解决方案应支持优雅重启功能，其中在PE优雅重启期间，C-TE LSP流量将继续转发。[RFC3473]、[RFC3623]和[RFC4781]中描述了与此体系结构相关的优雅重启机制。
The solution MUST provide the rerouting of a C-TE LSP in case of link, node, and SRLG failures, or in case of preemption. Such rerouting may be controlled by a CE or by a PE, depending on the failure. In a dual-homed environment, the ability to perform rerouting MUST be provided against a CE-PE link failure or a PE failure, if another CE-PE link or PE is available between the head-end and the tail-end of the C-TE LSP.
解决方案必须在链路、节点和SRLG故障或抢占情况下提供C-TE LSP的重新路由。这种重路由可以由CE或PE控制，具体取决于故障。在双宿环境中，如果在C-TE LSP的前端和后端之间存在另一个CE-PE链路或PE，则必须针对CE-PE链路故障或PE故障提供执行重路由的能力。
The solution MUST support FRR [RFC4090] features for a C-TE LSP over a VRF instance.
解决方案必须支持VRF实例上C-TE LSP的FRR[RFC4090]功能。
In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end router) needs to support link protection or node protection.
在BGP/MPLS IP-VPN环境中，来自CE的C-TE LSP穿过多个PE和Ps，尽管是通过P-TE LSP进行隧道传输。为了避免PE-CE链路/PE节点/SRLG故障，CE（客户的前端路由器）需要支持链路保护或节点保护。
The following protection MUST be supported:
必须支持以下保护：
1. CE link protection 2. PE node protection 3. CE node protection
1. CE链路保护2。PE节点保护3。CE节点保护
The solution MUST support admission control on a P-TE LSP tunnel head-end for C-TE LSPs. C-TE LSPs may potentially try to reserve the bandwidth that exceeds the bandwidth of the P-TE LSP. The P-TE LSP tunnel head-end SHOULD control the number of C-TE LSPs and/or the bandwidth of C-TE LSPs. For example, the transport TE LSP head-end SHOULD have a configurable limit on the maximum number of C-TE LSPs that it can admit from a CE. As for the amount of bandwidth that can be reserved by C-TE LSPs, there could be two situations:
该解决方案必须支持C-TE LSP的P-TE LSP隧道前端的准入控制。C-TE LSP可能尝试保留超过P-TE LSP带宽的带宽。P-TE LSP隧道前端应控制C-TE LSP的数量和/或C-TE LSP的带宽。例如，传输TE LSP前端应具有可配置的限制，限制其可从CE接收的最大C-TE LSP数量。至于C-TE LSP可以保留的带宽量，可能有两种情况：
1. Let the P-TE LSP do its natural bandwidth admission 2. Set a cap on the amount of bandwidth, and have the configuration option to:
1. 让P-TE LSP执行其自然带宽许可2。设置带宽的上限，并具有以下配置选项：
a. Reserve the minimum cap bandwidth or the C-TE LSP bandwidth on the P-TE LSP if the required bandwidth is available b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP is not available
a. 如果所需带宽可用，则在P-TE LSP上保留最小cap带宽或C-TE LSP带宽b。如果C-TE LSP所需的带宽不可用，则拒绝C-TE LSP
6.6. Admission Control Support for C-TE LSPs in LDP-Based Core Networks
6.6. 基于LDP的核心网中对C-TE LSP的接纳控制支持
The solution MUST support admission control for a C-TE LSP at a PE in the LDP-based core network. Specifically, PEs MUST have a configurable limit on the maximum amount of bandwidth that can be reserved by C-TE LSPs for a given VRF instance (i.e., for a given customer). Also, a PE SHOULD have a configurable limit on the total amount of bandwidth that can be reserved by C-TE LSPs between PEs.
该解决方案必须支持基于LDP的核心网络中PE上的C-TE LSP的准入控制。具体而言，PEs必须对C-TE LSP为给定VRF实例（即，为给定客户）保留的最大带宽量具有可配置的限制。此外，PE之间的C-TE LSP可以保留的带宽总量应具有可配置的限制。
The solution MUST support the policy control for a C-TE LSP at a PE.
The solution MUST support the policy control for a C-TE LSP at a PE.translate error, please retry
The PE MUST be able to perform the following:
PE必须能够执行以下操作：
1. Limit the rate of RSVP messages per CE link. 2. Accept and map, or reject, requests for a given affinity. 3. Accept and map, or reject, requests with a specified setup and/or preemption priorities. 4. Accept or reject requests for fast reroutes. 5. Ignore the requested setup and/or preemption priorities, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF. 6. Ignore the requested affinity, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF. 7. Perform mapping in the data plane between customer Traffic Class bits and transport P-TE LSP Traffic Class bits, as signaled per [RFC3270].
1. 限制每个CE链路的RSVP消息速率。2.接受并映射或拒绝给定关联的请求。3.接受并映射或拒绝具有指定设置和/或抢占优先级的请求。4.接受或拒绝快速重路由请求。5.忽略请求的设置和/或抢占优先级，并根据适用于CE-PE链路或VRF的本地策略选择P-TE LSP。6.忽略请求的关联，并根据适用于CE-PE链路或VRF的本地策略选择P-TE LSP。7.按照[RFC3270]发出的信号，在数据平面中执行客户流量类位和传输P-TE LSP流量类位之间的映射。
The solution SHOULD support the PCE architecture for a C-TE LSP establishment in the context of a VRF instance. When a C-TE LSP is provided, CEs, PEs, and Ps may support PCE features ([RFC4655], [RFC5440]).
该解决方案应支持在VRF实例上下文中建立C-TE LSP的PCE体系结构。当提供C-TE LSP时，CE、PE和Ps可支持PCE功能（[RFC4655]、[RFC5440]）。
In this case, CE routers or PE routers may be Path Computation Clients (PCCs), and PE routers and/or P routers may be PCEs. Furthermore, the solution SHOULD support a mechanism for dynamic PCE discovery. Specifically, all PCEs are not necessarily discovered automatically, and only specific PCEs that know VPN routes should be discovered automatically.
在这种情况下，CE路由器或PE路由器可以是路径计算客户端（pcc），并且PE路由器和/或P路由器可以是pce。此外，解决方案应支持动态PCE发现机制。具体来说，不一定会自动发现所有PCE，只有知道VPN路由的特定PCE才会自动发现。
The solution MUST provide for setting up diversely routed C-TE LSPs over the VRF instance. These diverse C-TE LSPs MAY be traversing
解决方案必须提供在VRF实例上设置不同路由的C-TE LSP。这些不同的C-TE LSP可能正在穿越
over two different P-TE LSPs that are fully disjoint within a service-provider network. When a single CE has multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between a pair of LSRs. When two CEs have multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between two different pairs of LSRs. In these cases, for example, the following points will be beneficial to customers.
在服务提供商网络内完全不相交的两个不同的P-TE LSP上。当单个CE具有连接到不同PEs的多个上行链路时，期望在一对lsr之间建立VRF实例上的多个C-TE lsp。当两个ce具有连接到不同PEs的多个上行链路时，期望在两个不同的lsr对之间建立VRF实例上的多个C-TE lsp。例如，在这些情况下，以下几点将对客户有利。
1. load balance of the CE-to-CE traffic across diverse C-TE LSPs so as to minimize the traffic disruption in case of a single network element failure 2. path protection (e.g., 1:1, 1:N)
1. 跨不同C-TE LSP的CE到CE流量的负载平衡，以便在单个网元发生故障时将流量中断降至最低2。路径保护（例如，1:1、1:N）
The solution MUST support the optimal path for a C-TE LSP over the VRF instance. Depending on an application (e.g., voice and video), an optimal path is needed for a C-TE LSP over the VRF instance. In the case of a TE LSP, an optimal route may be the shortest path based on the TE metric applied. For a non-TE LSP using LDP, the IGP metric may be used to compute optimal paths.
解决方案必须支持VRF实例上C-TE LSP的最佳路径。根据应用（例如，语音和视频），VRF实例上的C-TE LSP需要最佳路径。在TE LSP的情况下，最优路由可以是基于所应用的TE度量的最短路径。对于使用LDP的非TE LSP，可以使用IGP度量来计算最优路径。
The solution MUST support the reoptimization of a C-TE LSP over the VRF instance. These LSPs MUST be reoptimized using "make-before-break" [RFC3209].
解决方案必须支持在VRF实例上重新优化C-TE LSP。必须使用“先通后断”[RFC3209]重新优化这些LSP。
In this case, it is desirable for a CE to be configured with regard to the timer-based or event-driven reoptimization. Furthermore, customers SHOULD be able to reoptimize a C-TE LSP manually. To provide for delay-sensitive or jitter-sensitive traffic (i.e., voice traffic), C-TE LSP path computation and route selection are expected to be optimal for the specific application.
在这种情况下，期望针对基于定时器或事件驱动的再优化配置CE。此外，客户应该能够手动重新优化C-TE LSP。为了提供对延迟敏感或抖动敏感的业务（即语音业务），预计C-TE LSP路径计算和路由选择对于特定应用是最佳的。
The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the VRF instance. In the event that the service provider and the customer have differing bandwidth constraint models, then only the service-provider bandwidth model should be supported.
解决方案必须在VRF实例上支持C-TE LSP的DS-TE[RFC4124]。如果服务提供商和客户具有不同的带宽约束模型，则只应支持服务提供商带宽模型。
Applications, which have different traffic characteristics, are used in BGP/MPLS IP-VPN environments. Service providers try to achieve the fine-grained optimization of transmission resources, efficiency, and further-enhanced network performance. It may be desirable to perform TE at a per-class level.
BGP/MPLS IP-VPN环境中使用具有不同流量特性的应用程序。服务提供商试图实现传输资源的细粒度优化、效率和进一步增强的网络性能。可能需要在每类级别执行TE。
By mapping the traffic from a given Diffserv class of service on a separate C-TE LSP, DS-TE allows this traffic to utilize resources available to the given class on both shortest paths and non-shortest paths, and also to follow paths that meet TE constraints that are specific to the given class.
通过在单独的C-TE LSP上映射来自给定Diffserv服务类别的通信量，DS-TE允许该通信量利用给定类别在最短路径和非最短路径上可用的资源，并遵循满足特定于给定类别的TE约束的路径。
This section describes detailed requirements for C-RSVP paths in BGP/MPLS IP-VPN environments.
本节介绍BGP/MPLS IP-VPN环境中C-RSVP路径的详细要求。
The solution MUST support admission control at the ingress PE. PEs MUST control RSVP messages per a VRF instance.
解决方案必须支持入口PE的准入控制。PEs必须控制每个VRF实例的RSVP消息。
The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs. P-TE LSPs SHOULD be pre-established manually or dynamically by operators and MAY be established if triggered by C-RSVP messages. Also, the P-TE LSP SHOULD support DS-TE.
解决方案应支持由P-TE LSP聚合的C-RSVP路径。P-TE LSP应由操作员手动或动态预先建立，如果由C-RSVP消息触发，则可建立。此外，P-TE LSP应该支持DS-TE。
The solution SHOULD support non-TE LSPs (i.e., LDP-based LSP, etc.). Non-TE LSPs are established by LDP [RFC5036] between PEs and support MPLS Diffserv [RFC3270]. The solution MAY support local policies to map the customer's reserved flow to the LSP with the appropriate Traffic Class at the PE.
解决方案应支持非TE LSP（即基于LDP的LSP等）。非TE LSP由LDP[RFC5036]在PEs和支持MPLS Diffserv[RFC3270]之间建立。该解决方案可以支持本地策略，以将客户的保留流映射到具有PE上的适当流量类别的LSP。
The solution SHOULD NOT change RSVP messages from the local CE to the remote CE (Path, Resv, Path Error, Resv Error, etc.). The solution SHOULD allow customers to receive RSVP messages transparently between CE sites.
解决方案不应将RSVP消息从本地CE更改为远程CE（路径、Resv、路径错误、Resv错误等）。该解决方案应允许客户在CE站点之间透明地接收RSVP消息。
This section describes commonly detailed requirements for C-TE LSPs and C-RSVP paths in BGP/MPLS IP-VPN environments.
本节描述了BGP/MPLS IP-VPN环境中C-TE LSP和C-RSVP路径的一般详细要求。
The solution SHOULD support the following routing configuration on the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
解决方案应支持CE-PE链路上的以下路由配置，CE-PE链路上有RSVP或RSVP-TE：
1. static routing 2. BGP routing 3. OSPF 4. OSPF-TE (RSVP-TE case only)
1. 静态路由2。BGP路由3。OSPF 4。OSPF-TE（仅限RSVP-TE案例）
The solution SHOULD avoid introducing unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks.
该解决方案应避免将不必要的复杂性引入当前的运营网络，以免影响稳定性并降低在SP网络上部署该解决方案的好处。
The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid impacting existing RSVP and MPLS-TE mechanisms, respectively, but should allow for a smooth migration or co-existence.
C-RSVP路径和C-TE LSP的部署应分别避免影响现有的RSVP和MPLS-TE机制，但应允许平滑迁移或共存。
The solution SHOULD minimize the impact on network scalability from a C-RSVP path and a C-TE LSP over the VRF instance. As identified in earlier sections, PCE provides a method for offloading computation of C-TE LSPs and helps with the solution scalability.
该解决方案应将VRF实例上的C-RSVP路径和C-TE LSP对网络可伸缩性的影响降至最低。如前几节所述，PCE提供了一种卸载C-TE LSP计算的方法，并有助于解决方案的可伸缩性。
The solution MUST address the scalability of C-RSVP paths and C-TE LSPs for the following protocols.
解决方案必须解决以下协议的C-RSVP路径和C-TE LSP的可伸缩性问题。
1. RSVP (e.g., number of RSVP messages, retained state, etc.). 2. RSVP-TE (e.g., number of RSVP control messages, retained state, message size, etc.). 3. BGP (e.g., number of routes, flaps, overload events, etc.).
1. RSVP（例如，RSVP消息的数量、保留状态等）。2.RSVP-TE（例如，RSVP控制消息的数量、保留状态、消息大小等）。3.BGP（例如，路线数、襟翼、过载事件等）。
The solution SHOULD be evaluated with regard to the following criteria.
应根据以下标准评估解决方案。
1. Degree of path optimality of the C-TE LSP. 2. TE LSP setup time. 3. Failure and restoration time. 4. Impact and scalability of the control plane due to added overhead. 5. Impact and scalability of the data/forwarding plane due to added overhead.
1. C-TE LSP的路径最优度。2.TE LSP设置时间。3.故障和恢复时间。4.由于增加的开销，控制平面的影响和可伸缩性。5.由于增加的开销，数据/转发平面的影响和可扩展性。
The solution MUST address the manageability of C-RSVP paths and C-TE LSPs for the following considerations.
出于以下考虑，解决方案必须解决C-RSVP路径和C-TE LSP的可管理性。
1. Need for a MIB module for the control plane (including mapping of P-TE LSPs and C-TE LSPs) and bandwidth monitoring. 2. Need for diagnostic tools (this includes traceroute and Ping).
1. 控制平面需要MIB模块（包括P-TE LSP和C-TE LSP的映射）和带宽监控。2.需要诊断工具（包括traceroute和Ping）。
The solution MUST allow routers to support the MIB module for C-RSVP paths and C-TE LSPs per a VRF instance. If a CE is managed by service providers, the solution MUST allow service providers to collect MIB information for C-RSVP paths and C-TE LSPs from the CE per a customer.
解决方案必须允许路由器支持每个VRF实例的C-RSVP路径和C-TE LSP的MIB模块。如果CE由服务提供商管理，则解决方案必须允许服务提供商为每个客户从CE收集C-RSVP路径和C-TE LSP的MIB信息。
Diagnostic tools can detect failures of the control plane and data plane for general MPLS-TE LSPs [RFC4379]. The solution MUST allow routers to be able to detect failures of the control plane and the data plane for C-TE LSPs over a VRF instance.
诊断工具可以检测通用MPLS-TE LSP的控制平面和数据平面故障[RFC4379]。解决方案必须允许路由器能够通过VRF实例检测C-TE LSP的控制平面和数据平面的故障。
MPLS Operations, Administration, and Maintenance (OAM) for C-TE LSPs MUST be supported within the context of VRF, except for the above.
C-TE LSP的MPLS操作、管理和维护（OAM）必须在VRF上下文中得到支持，但上述情况除外。
Any solution should consider the following general security requirements:
任何解决方案都应考虑以下一般安全要求：
1. The solution SHOULD NOT divulge the service-provider topology information to the customer network. 2. The solution SHOULD minimize the service-provider network's vulnerability to Denial of Service (DoS) attacks. 3. The solution SHOULD minimize the misconfiguration of DSCP marking, preemption, and holding priorities of the customer traffic.
1. 解决方案不应将服务提供商拓扑信息泄露给客户网络。2.该解决方案应尽量减少服务提供商网络遭受拒绝服务（DoS）攻击的漏洞。3.该解决方案应尽量减少DSCP标记、抢占和保持客户流量优先级的错误配置。
The following additional security issues for C-TE LSPs relate to both the control plane and the data plane.
C-TE LSP的以下附加安全问题涉及控制平面和数据平面。
In terms of the control plane, in both the C-RSVP path and C-TE LSP models, a PE receives IPv4 or IPv6 RSVP control packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate and number of IPv4 or IPv6 RSVP control packets.
就控制平面而言，在C-RSVP路径和C-TE LSP模型中，PE从CE接收IPv4或IPv6 RSVP控制数据包。如果CE是服务提供商不信任的路由器，则PE必须能够限制IPv4或IPv6 RSVP控制数据包的速率和数量。
In terms of the data plane, in the C-TE LSP model, a PE receives labeled IPv4 or IPv6 data packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate of labeled IPv4 or IPv6 data packets. If the CE is a
在数据平面方面，在C-TE LSP模型中，PE从CE接收标记为IPv4或IPv6的数据包。如果CE是服务提供商不信任的路由器，则PE必须能够限制标记的IPv4或IPv6数据包的速率。如果行政长官是
trusted router for service providers, the PE MAY be able to limit the rate of labeled IPv4 or IPv6 data packets. Specifically, the PE must drop MPLS-labeled packets if the MPLS label was not assigned over the PE-CE link on which the packet was received. The PE must also be able to police traffic to the traffic profile associated with the LSP on which traffic is received on the PE-CE link.
对于服务提供商的受信任路由器，PE可能能够限制标记的IPv4或IPv6数据包的速率。具体而言，如果MPLS标签未通过接收数据包的PE-CE链路分配，则PE必须丢弃MPLS标签的数据包。PE还必须能够监控与在PE-CE链路上接收流量的LSP相关联的流量配置文件的流量。
Moreover, flooding RSVP/RSVP-TE control packets from malicious customers must be avoided. Therefore, a PE MUST isolate the impact of such customers' RSVP/RSVP-TE packets from other customers.
此外，必须避免恶意客户的RSVP/RSVP-TE控制数据包泛滥。因此，PE必须将此类客户的RSVP/RSVP-TE数据包的影响与其他客户隔离开来。
In the event that C-TE LSPs are diversely routed over VRF instances, the VRF should indicate to the CE how such diversity was provided.
如果C-TE LSP在VRF实例上不同路由，VRF应向CE说明如何提供这种分集。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[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月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623]Moy，J.，Pillay Esnault，P.，和A.Lindem，“OSPF的优雅重启”，RFC 36232003年11月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS", RFC 4781, January 2007.
[RFC4781]Rekhter，Y.和R.Aggarwal，“带MPLS的BGP的优雅重启机制”，RFC 4781，2007年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RSVP-L3VPN] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for RSVP in Layer 3 VPNs", Work in Progress, November 2009.
[RSVP-L3VPN]Davie，B.，Le Faucheur，F.，和A.Narayanan，“第3层VPN中对RSVP的支持”，正在进行的工作，2009年11月。
[RFC4804] Le Faucheur, F., Ed., "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月。
[RFC5330] Vasseur, JP., Ed., Meyer, M., Kumaki, K., and A. Bonda, "A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link", RFC 5330, October 2008.
[RFC5330]Vasseur，JP.，Ed.，Meyer，M.，Kumaki，K.，和A.Bonda，“一种链路类型的子TLV，用于传输在链路上以零保留带宽发送信号的流量工程标签交换路径的数量”，RFC 5330，2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
The authors would like to express thanks to Nabil Bitar, David McDysan, and Daniel King for their helpful and useful comments and feedback.
作者要感谢Nabil Bitar、David McDysan和Daniel King提供的有用的评论和反馈。
In this appendix, a C-RSVP path, a C-TE LSP, and a P-TE LSP are explained.
在本附录中，解释了C-RSVP路径、C-TE LSP和P-TE LSP。
All scenarios in this appendix assume the following:
本附录中的所有场景均假设以下情况：
- A P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within a BGP/MPLS IP-VPN.
- 在PE1和PE2之间建立P-TE LSP。VRF实例使用此LSP在BGP/MPLS IP-VPN内转发客户数据包。
- The service provider has ensured that enough bandwidth is available to meet the service requirements.
- 服务提供商已确保有足够的带宽满足服务要求。
A C-RSVP path and a P-TE LSP are shown in Figure 7, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. In the case of a non-TE mechanism, however, it may be difficult to guarantee an end-to-end bandwidth, as resources are shared.
图7显示了BGP/MPLS IP-VPN上下文中的C-RSVP路径和P-TE LSP。在某些情况下，P-TE LSP可以是非TE LSP（即，LDP）。然而，在非TE机制的情况下，由于资源共享，可能难以保证端到端带宽。
CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth reservation of X. At PE1, this reservation request received in the context of a VRF will get aggregated onto a pre-established P-TE LSP, or trigger the establishment of a new P-TE LSP. It should be noted that C-RSVP sessions across different BGP/MPLS IP-VPNs can be aggregated onto the same P-TE LSP between the same PE pair, achieving further scalability. [RFC4804] defines this scenario in more detail.
CE0/CE1请求到CE3/CE2的e2e C-RSVP路径，带宽保留为X。在PE1，在VRF上下文中收到的该保留请求将聚合到预先建立的P-TE LSP上，或触发建立新的P-TE LSP。应该注意的是，跨不同BGP/MPLS IP VPN的C-RSVP会话可以聚合到相同PE对之间的相同P-TE LSP上，从而实现进一步的可伸缩性。[RFC4804]更详细地定义了该场景。
The RSVP control messages (e.g., an RSVP PATH message and an RSVP RESV message) exchanged among CEs are forwarded by IP packets through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path through the BGP/MPLS IP-VPN.
CE之间交换的RSVP控制消息（例如，RSVP路径消息和RSVP RESV消息）通过BGP/MPLS IP-VPN由IP分组转发。CE0和/或CE1收到来自CE2和/或CE3的保留消息后，CE0/CE1通过BGP/MPLS IP-VPN建立C-RSVP路径。
C-RSVP path
<------------------------------------------>
C-RSVP path
<------------------------------------------>
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
or or
another another
service-provider service-provider
network network
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 7. e2e C-RSVP Path Model
图7。e2e C-RSVP路径模型
A C-TE LSP and a P-TE LSP are shown in Figure 8, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. As described in the previous sub-section, it may be difficult to guarantee an end-to-end QoS in some cases.
图8显示了BGP/MPLS IP-VPN上下文中的C-TE LSP和P-TE LSP。在某些情况下，P-TE LSP可以是非TE LSP（即，LDP）。如前一小节所述，在某些情况下，可能难以保证端到端的QoS。
CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth reservation of X. At PE1, this reservation request received in the context of a VRF will get aggregated onto a pre-established P-TE LSP, or trigger the establishment of a new P-TE LSP. It should be noted that C-TE LSPs across different BGP/MPLS IP-VPNs can be aggregated onto the same P-TE LSP between the same PE pair, achieving further scalability.
CE0/CE1请求到CE3/CE2的e2e TE LSP路径，带宽保留为X。在PE1，在VRF上下文中收到的该保留请求将聚合到预先建立的P-TE LSP上，或触发建立新的P-TE LSP。应该注意的是，跨不同BGP/MPLS IP VPN的C-TE LSP可以聚合到相同PE对之间的相同P-TE LSP上，从而实现进一步的可伸缩性。
The RSVP-TE control messages (e.g., an RSVP PATH message and an RSVP RESV message) exchanged among CEs are forwarded by a labeled packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-TE LSP through the BGP/MPLS IP-VPN.
CE之间交换的RSVP-TE控制消息（例如，RSVP路径消息和RSVP RESV消息）通过BGP/MPLS IP-VPN由标记的分组转发。CE0和/或CE1收到来自CE2和/或CE3的保留消息后，CE0/CE1通过BGP/MPLS IP-VPN建立C-TE LSP。
A P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within the BGP/MPLS IP-VPN.
在PE1和PE2之间建立P-TE LSP。VRF实例使用此LSP在BGP/MPLS IP-VPN内转发客户数据包。
C-TE LSP
<------------------------------------------------------->
C-TE LSP
<------------------------------------------------------->
or
或
C-TE LSP
<----------------------------------------->
C-TE LSP
<----------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
or or
another another
service-provider service-provider
network network
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 8. e2e C-TE LSP Model
图8。e2e C-TE LSP模型
Authors' Addresses
作者地址
Kenji Kumaki (Editor) KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku Tokyo 102-8460, JAPAN EMail: ke-kumaki@kddi.com
久木健二（编辑）日本千代田区三大坂市KDDI公司花园航空塔日本东京102-8460电子邮件：ke-kumaki@kddi.com
Raymond Zhang BT Farady Building, PP1.21 1 Knightrider Street London EC4V 5BT UK EMail: raymond.zhang@bt.com
Raymond Zhang BT Farady大厦，PP1.21伦敦骑士街1号EC4V 5BT英国电子邮件：Raymond。zhang@bt.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura，Minato ku东京108-8118日本电子邮件：y。kamite@ntt.com