Network Working Group T. Takeda, Ed.
Request for Comments: 5253 NTT
Category: Informational July 2008
Network Working Group T. Takeda, Ed.
Request for Comments: 5253 NTT
Category: Informational July 2008
Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
第1层虚拟专用网（L1VPN）基本模式适用性声明
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).
本文档提供了关于使用通用多协议标签交换（GMPLS）协议和机制支持基本模式第1层虚拟专用网络（L1VPN）的适用性声明。
L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN.
L1VPN通过第1层网络在第1层提供客户服务和连接。L1VPN的操作分为基本模式和增强模式，其中基本操作模式的特点是在第1层网络和客户域之间不交换路由信息。本文件探讨了如何使用GMPLS协议来满足基本模式L1VPN的要求。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Basic Mode Overview .............................................3
3. Supported Network Types .........................................4
3.1. Data Plane .................................................4
3.2. Control Plane ..............................................4
4. Addressing ......................................................5
5. Provider Control of Its Infrastructure ..........................5
5.1. Provisioning Model .........................................5
5.2. PE-to-PE Segment Control ...................................6
5.2.1. Path Computation and Establishment ..................6
5.2.2. Resource Management .................................7
5.2.3. Consideration of CE-to-PE Traffic Engineering
Information .........................................8
5.3. Connectivity Restriction ...................................8
6. Customer Control of Its L1VPN ...................................8
6.1. Topology Control ...........................................8
6.2. Note on Routing ............................................9
7. Scalability and Resiliency .....................................10
7.1. Scalability ...............................................10
7.2. Data Plane Resiliency .....................................11
7.3. Control Plane Resiliency ..................................12
8. Security Considerations ........................................12
8.1. Topology Confidentiality ..................................12
8.2. External Control of the Provider Network ..................13
8.3. Data Plane Security .......................................13
8.4. Control Plane Security ....................................14
9. Manageability Considerations ...................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
11. Acknowledgments ...............................................17
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Basic Mode Overview .............................................3
3. Supported Network Types .........................................4
3.1. Data Plane .................................................4
3.2. Control Plane ..............................................4
4. Addressing ......................................................5
5. Provider Control of Its Infrastructure ..........................5
5.1. Provisioning Model .........................................5
5.2. PE-to-PE Segment Control ...................................6
5.2.1. Path Computation and Establishment ..................6
5.2.2. Resource Management .................................7
5.2.3. Consideration of CE-to-PE Traffic Engineering
Information .........................................8
5.3. Connectivity Restriction ...................................8
6. Customer Control of Its L1VPN ...................................8
6.1. Topology Control ...........................................8
6.2. Note on Routing ............................................9
7. Scalability and Resiliency .....................................10
7.1. Scalability ...............................................10
7.2. Data Plane Resiliency .....................................11
7.3. Control Plane Resiliency ..................................12
8. Security Considerations ........................................12
8.1. Topology Confidentiality ..................................12
8.2. External Control of the Provider Network ..................13
8.3. Data Plane Security .......................................13
8.4. Control Plane Security ....................................14
9. Manageability Considerations ...................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
11. Acknowledgments ...............................................17
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as specified in [RFC4847].
本文件提供了[RFC4847]中规定的通用多协议标签交换（GMPLS）协议和机制对基本模式第1层虚拟专用网络（L1VPN）的适用性声明。
The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode. The Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain, while the Enhanced Mode of operation features exchange of routing information between the Layer 1 network and the customer domain.
L1VPNs的操作分为基本模式和增强模式。基本操作模式的特点是在第一层网络和客户域之间不交换路由信息，而增强操作模式的特点是在第一层网络和客户域之间交换路由信息。
The main GMPLS protocols and mechanisms applicable to the L1VPN Basic Mode are described in [RFC5251], [RFC5195], and [RFC5252], along with several other documents referenced within this document.
[RFC5251]、[RFC5195]和[RFC5252]中描述了适用于L1VPN基本模式的主要GMPLS协议和机制，以及本文件中引用的其他几个文件。
Note that discussion in this document is focused on areas where GMPLS protocols and mechanisms are relevant.
注意，本文件中的讨论集中在GMPLS协议和机制相关的领域。
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and [RFC4847].
假定读者熟悉[RFC3031]、[RFC3209]、[RFC3471]、[RFC3473]、[RFC4202]、[RFC4026]和[RFC4847]中的术语。
As described in [RFC4847], in the Basic Mode service model, there is no routing exchange between the Customer Edge (CE) and the Provider Edge (PE). CE-to-CE L1VPN connections (i.e., the CE-to-CE VPN connection in RFC 4847) are set up by GMPLS signaling between the CE and the PE, and then across the provider network. A L1VPN connection is limited to the connection between CEs belonging to the same L1VPN.
如[RFC4847]所述，在基本模式服务模型中，客户边缘（CE）和提供商边缘（PE）之间没有路由交换。CE到CE L1VPN连接（即RFC 4847中的CE到CE VPN连接）通过CE和PE之间的GMPLS信令建立，然后通过提供商网络建立。L1VPN连接仅限于属于同一L1VPN的CE之间的连接。
Note that in L1VPNs, routing operates within the provider network. Also note that routing may be used by PEs to exchange information specific to the L1VPNs supported by the provider network (e.g., membership information).
请注意，在L1VPN中，路由在提供商网络内运行。还请注意，PEs可使用路由来交换提供商网络支持的L1VPN的特定信息（例如，成员信息）。
In the L1VPN Basic Mode, the provider network is completely under the control of the provider. This includes the PE-to-PE segment of the CE-to-CE L1VPN connection that is controlled and computed by the provider (PE-to-PE segment control). On the other hand, the L1VPN itself, constructed from a set of CEs and the L1VPN connections provided by the provider, is under the control of each customer. This control includes that a customer can request between which CEs a
在L1VPN基本模式下，提供商网络完全由提供商控制。这包括由提供商控制和计算的CE到CE L1VPN连接的PE到PE段（PE到PE段控制）。另一方面，L1VPN本身由一组CEs和提供商提供的L1VPN连接构成，由每个客户控制。此控件包括客户可以请求
connection is to be established (topology control). Note that a customer may outsource the management of its L1VPN to a third party, including to the provider itself. There is a confidentiality requirement between the provider and each customer.
要建立连接（拓扑控制）。请注意，客户可以将其L1VPN的管理外包给第三方，包括提供商本身。供应商和每个客户之间都有保密要求。
[RFC5251], which extends [RFC4208], specifies GMPLS signaling to establish CE-to-CE L1VPN connections.
[RFC5251]扩展了[RFC4208]，它指定了用于建立CE到CE L1VPN连接的GMPLS信令。
[RFC5195] and [RFC5252] specify alternative mechanisms to exchange L1VPN membership information between PEs, based on BGP and OSPF, respectively.
[RFC5195]和[RFC5252]分别基于BGP和OSPF指定在PEs之间交换L1VPN成员信息的替代机制。
The provider network can be constructed from any type of Layer 1 switches, such as Time Division Multiplexing (TDM) switches, Optical Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). Furthermore, a PE may be an Ethernet Private Line (EPL) type of device, that maps Ethernet frames onto Layer 1 connections (by means of Ethernet over TDM, etc.). The provider network may be constructed from switches providing a single switching granularity (e.g., only VC3 switches), or from switches providing multiple switching granularities (e.g., from VC3/VC4 switches, or from VC3 switches and OXCs). The provider network may provide a single type of L1VPN connection (e.g., VC3 connections only), or multiple types of connection (e.g., VC3/VC4 connections, or VC3 connections and wavelength connections).
提供商网络可以由任何类型的第1层交换机构成，例如时分复用（TDM）交换机、光交叉连接（OXCs）或光子交叉连接（PXCs）。此外，PE可以是以太网专用线（EPL）类型的设备，其将以太网帧映射到第1层连接上（通过TDM上的以太网等）。提供商网络可以由提供单一交换粒度的交换机（例如，仅VC3交换机）或由提供多个交换粒度的交换机（例如，从VC3/VC4交换机，或从VC3交换机和oxc）构成。提供商网络可提供单一类型的L1VPN连接（例如，仅VC3连接），或多种类型的连接（例如，VC3/VC4连接，或VC3连接和波长连接）。
A CE does not have to have the capability to switch at Layer 1, but it must be capable of receiving a Layer 1 signal and either switching it or terminating it with adaptation.
CE不必具有在第1层切换的能力，但它必须能够接收第1层信号，并通过自适应进行切换或终止。
As described in [RFC4847] and [RFC5251], a CE and a PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it.
如[RFC4847]和[RFC5251]中所述，CE和PE通过一个或多个链路连接。CE还可以连接到多个PE，并且一个PE可以有多个CE连接到它。
A CE may belong to a single L1VPN, or to multiple L1VPNs, and a PE may support one or more L1VPNs through a single CE or through multiple CEs.
CE可以属于单个L1VPN，也可以属于多个L1VPN，PE可以通过单个CE或多个CE支持一个或多个L1VPN。
The provider network is controlled by GMPLS. L1VPN Basic Mode provider networks are limited to a single AS within the scope of this document. Multi-AS Basic Mode L1VPNs are for future study.
供应商网络由GMPLS控制。L1VPN基本模式提供商网络仅限于本文档范围内的单个AS。Multi-AS基本模式L1VPN供将来研究。
As described in [RFC4847] and [RFC5251], a CE and a PE need to be connected by at least one control channel. It is necessary to disambiguate control plane messages exchanged between a CE and a PE if the CE-to-PE relationship is applicable to more than one L1VPN. This makes it possible to determine to which L1VPN such control plane messages apply. Such disambiguation can be achieved by allocating a separate control channel to each L1VPN (either using a separate physical channel, a separate logical channel such as an IP tunnel, or using separate addressing).
如[RFC4847]和[RFC5251]中所述，CE和PE需要通过至少一个控制通道连接。如果CE-to-PE关系适用于多个L1VPN，则有必要消除CE和PE之间交换的控制平面消息的歧义。这使得可以确定此类控制平面消息应用于哪个L1VPN。可以通过为每个L1VPN分配单独的控制通道（使用单独的物理通道、单独的逻辑通道（如IP隧道）或使用单独的寻址）来实现这种消歧。
GMPLS allows any type of control channel to be used, as long as there is IP level reachability. In the L1VPN context, instantiation of a control channel between a CE and a PE may differ depending on security requirements, etc. This is discussed in Section 8.
GMPLS允许使用任何类型的控制信道，只要存在IP级可达性。在L1VPN上下文中，CE和PE之间的控制通道的实例化可能因安全要求等而异。这将在第8节中讨论。
As described in [RFC5251], the L1VPN Basic Mode allows that customer addressing realms overlap with each other, and also overlap with the service provider addressing realm. That is, a customer network may reuse addresses used by the provider network, and may reuse addresses used in another customer network supported by the same provider network. This is the same as in any other VPN model.
如[RFC5251]所述，L1VPN基本模式允许客户寻址域彼此重叠，也允许与服务提供商寻址域重叠。也就是说，客户网络可以重用提供商网络使用的地址，并且可以重用由相同提供商网络支持的另一客户网络中使用的地址。这与任何其他VPN模型中的情况相同。
In addition, the L1VPN Basic Mode allows CE-to-PE control channel addressing realms to overlap. That is, a CE-to-PE control channel address (CE's address of this control channel and PE's address of this control channel) is unique within the L1VPN that the CE-to-PE control channel belongs to, but not necessarily unique across multiple L1VPNs.
此外，L1VPN基本模式允许CE-to-PE控制信道寻址域重叠。也就是说，CE到PE控制通道地址（此控制通道的CE地址和此控制通道的PE地址）在CE到PE控制通道所属的L1VPN中是唯一的，但不一定在多个L1VPN中是唯一的。
Furthermore, once a L1VPN connection has been established, the L1VPN Basic Mode does not enforce any restriction on address assignment for this L1VPN connection (treated as a link) for customer network operation (e.g., IP network, MPLS network).
此外，一旦建立了L1VPN连接，L1VPN基本模式不会对客户网络操作（例如，IP网络、MPLS网络）的该L1VPN连接（视为链路）的地址分配实施任何限制。
As described in [RFC5251], for each L1VPN that has at least one customer-facing port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. A PIT provides a cross-reference between Customer Port Indices (CPIs) and Provider Port Indices (PPIs) and contains a list of <CPI, PPI> tuples for all the ports within the L1VPN. In addition, for local PE ports of a given L1VPN, the PE retains an identifier known as the VPN-PPI, and this is stored in the PIT with the <CPI, PPI> tuples.
如[RFC5251]中所述，对于给定PE上至少有一个面向客户端口的每个L1VPN，PE维护与该L1VPN关联的端口信息表（PIT）。PIT提供客户端口索引（CPI）和提供商端口索引（PPI）之间的交叉引用，并包含L1VPN内所有端口的<CPI，PPI>元组列表。此外，对于给定L1VPN的本地PE端口，PE保留一个称为VPN-PPI的标识符，该标识符与<CPI，PPI>元组一起存储在PIT中。
When a new CE belonging to one or more L1VPNs is added to a PE, PIT entries associated to those L1VPNs need to be configured on the PE. Section 4 of [RFC5251] specifies such procedures:
当属于一个或多个L1VPN的新CE添加到PE时，需要在PE上配置与这些L1VPN关联的PIT条目。[RFC5251]第4节规定了此类程序：
- If no PIT exists for the L1VPN on the PE, a new PIT is created by the provider and associated with the VPN identifier.
- 如果PE上的L1VPN不存在PIT，则提供商将创建一个新的PIT，并将其与VPN标识符关联。
- The PIT (new or pre-existing) is updated to include information related to the newly added CE. The VPN-PPI, PPI, and CPI are installed in the PIT. Note that the PPI is well-known by the PE, but the CPI must be discovered either through manual configuration or automatically by mechanisms such as the Link Management Protocol (LMP) [RFC4204]. In addition, a CE-to-PE control channel needs to be configured.
- PIT（新的或预先存在的）将更新，以包括与新添加的CE相关的信息。VPN-PPI、PPI和CPI安装在坑中。请注意，PPI是PE所熟知的，但必须通过手动配置或通过链路管理协议（LMP）[RFC4204]等机制自动发现CPI。此外，需要配置CE到PE控制通道。
- The updated PIT information needs to be configured in the PITs on the remote PE associated with the L1VPN. For such purposes, manual configuration or some sort of auto-discovery mechanisms can be used. [RFC5195] and [RFC5252] specify alternative auto-discovery mechanisms.
- 需要在与L1VPN关联的远程PE上的PIT中配置更新的PIT信息。为此，可以使用手动配置或某种自动发现机制。[RFC5195]和[RFC5252]指定替代自动发现机制。
- In addition, remote PIT information associated with the L1VPN needs to be configured on this PE if the PIT has been newly created. Again, this can be achieved through manual configuration or through auto-discovery; see [RFC5195] and [RFC5252].
- 此外，如果PIT是新创建的，则需要在此PE上配置与L1VPN关联的远程PIT信息。同样，这可以通过手动配置或自动发现来实现；参见[RFC5195]和[RFC5252]。
When L1VPN membership of an existing CE changes, or when a CE is removed from a PE, similar procedures need to be applied to update the local and remote PITs.
当现有CE的L1VPN成员身份发生变化时，或者当CE从PE中删除时，需要应用类似的程序来更新本地和远程PIT。
In the L1VPN Basic Mode, a PE-to-PE segment of a CE-to-CE L1VPN connection is completely under the control of the provider network.
在L1VPN基本模式下，CE到CE L1VPN连接的PE到PE段完全受提供商网络的控制。
A PE-to-PE segment of a CE-to-CE L1VPN connection may be established based on various policies. Those policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
可以基于各种策略建立CE到CE L1VPN连接的PE到PE段。这些策略可以应用于每个L1VPN或每个L1VPN连接。该策略由提供商配置，可能基于与每个客户的合同。
Examples of PE-to-PE segment connection establishment polices supported in the L1VPN Basic Mode are as follows.
L1VPN基本模式中支持的PE到PE段连接建立策略示例如下。
- Policy 1: On-demand establishment, on-demand path computation - Policy 2: On-demand establishment, pre-computed path - Policy 3: Pre-establishment, pre-computed path
- 策略1：按需建立，按需路径计算-策略2：按需建立，预计算路径-策略3：预建立，预计算路径
In each policy, the PE-to-PE path may be computed by the local PE or by a path computation entity outside of the local PE (e.g., a Path Computation Element (PCE) [RFC4655] or a management system).
在每个策略中，PE到PE路径可以由本地PE或本地PE之外的路径计算实体（例如，路径计算元素（PCE）[RFC4655]或管理系统）计算。
In policies 2 and 3, pre-computation of paths (and pre-establishment if applicable) can be done at the network planning phase, or just before signaling (e.g., triggered by an off-line customer request). As the result of pre-computation (and pre-establishment), there could be multiple PE-to-PE segments for a specific pair of PEs. When a PE receives a Path message from a CE for a L1VPN connection, a PE needs to determine which PE-to-PE segment to use. In such cases, the provider may want to control:
在策略2和3中，路径的预计算（以及预建立，如果适用）可以在网络规划阶段进行，或者在发信号之前进行（例如，由离线客户请求触发）。作为预计算（和预建立）的结果，一对特定PE可能有多个PE-to-PE段。当PE从CE接收到L1VPN连接的路径消息时，PE需要确定要使用哪个PE到PE段。在这种情况下，提供商可能希望控制：
- Which L1VPN uses which PE-to-PE L1VPN segment. - Which CE-to-CE L1VPN connection uses which PE-to-PE L1VPN segment.
- 哪个L1VPN使用哪个PE到PE L1VPN段。-哪个CE到CE L1VPN连接使用哪个PE到PE L1VPN段。
The former requires mapping between the PIT and the PE-to-PE segment. The latter requires some more sophisticated mapping method, for example:
前者需要PIT和PE-to-PE段之间的映射。后者需要一些更复杂的映射方法，例如：
- Mapping between individual PIT entries and PE-to-PE segments. - Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE, and signaled by the CE as part of the L1VPN connection request.
- 单个矿坑入口和PE到PE段之间的映射。-使用由提供者提供给CE的路径密钥ID[CONF-SEG]，并由CE作为L1VPN连接请求的一部分发出信号。
The L1VPN Basic Mode does not preclude usage of other methods, if applicable.
L1VPN基本模式不排除使用其他方法（如适用）。
In policy 3, stitching or nesting is necessary in order to map the CE-to-CE L1VPN connection to a pre-established PE-to-PE segment.
在策略3中，为了将CE-to-CE L1VPN连接映射到预先建立的PE-to-PE段，需要缝合或嵌套。
The provider network may operate resource management based on various policies. These policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
提供商网络可以基于各种策略操作资源管理。这些策略可以应用于每个L1VPN或每个L1VPN连接。该策略由提供商配置，可能基于与每个客户的合同。
For example, a provider may choose to partition the resources of the provider network for limited use by different L1VPNs or customers. Such a function might be achieved within the scope of the Basic Mode using resource affinities [RFC3209], but the details of per-L1VPN resource models (especially in terms of CE-to-PE routing) are considered as part of the Enhanced Mode.
例如，提供商可以选择对提供商网络的资源进行分区，以供不同的L1VPN或客户有限地使用。这种功能可能在使用资源亲缘关系的基本模式范围内实现[RFC3209]，但per-L1VPN资源模型的细节（尤其是CE到PE路由）被视为增强模式的一部分。
[RFC5252] and [BGP-TE] allow CE-to-PE Traffic Engineering (TE) link information to be injected into the provider network, and in particular to be exchanged between PEs. This may be helpful for the ingress PE to prevent connection setup failure due to lack of resources or incompatible switching capabilities on remote CE-to-PE TE links.
[RFC5252]和[BGP-TE]允许CE-to-PE流量工程（TE）链路信息注入提供商网络，特别是在PE之间交换。这可能有助于入口PE防止由于缺乏资源或远程CE-to-PE-TE链路上不兼容的交换能力而导致的连接设置失败。
Furthermore, the L1VPN Basic Mode allows a remote CE to be reached through more than one TE link connected to the same PE (single-homed) or to different PEs (dual-homed). In such cases, to facilitate route choice, the ingress CE needs to initiate signaling by specifying the egress CE's router ID, not the egress CPI, in the Session Object and the Explicit Route Object (ERO), if present, so as to not constrain the choice of route within the provider network. Therefore, the CE's router ID needs to be configured in the PITs.
此外，L1VPN基本模式允许通过连接到同一个PE（单宿）或不同PE（双宿）的多个TE链路到达远程CE。在这种情况下，为了促进路由选择，入口CE需要通过在会话对象和显式路由对象（ERO）（如果存在）中指定出口CE的路由器ID而不是出口CPI来发起信令，以便不限制提供商网络内的路由选择。因此，CE的路由器ID需要在PITs中配置。
Note that, as described in Section 7.2, consideration of the full feature set enabled by dual-homing (such as resiliency) is out of scope of the L1VPN Basic Mode.
请注意，如第7.2节所述，考虑双归宿（如弹性）启用的完整功能集超出L1VPN基本模式的范围。
The L1VPN Basic Mode allows restricting connection establishment between CEs belonging to the same L1VPN for policy reasons (including L1VPN security). Since the PIT at each PE is associated with a L1VPN, this function can be easily supported. The restriction can be applied at the ingress PE or at the egress PE according to the applicable restriction policy, but note that applying the policy at the egress may waste signaling effort within the network as L1VPN connections are pointlessly attempted.
L1VPN基本模式允许出于策略原因（包括L1VPN安全性）限制属于同一L1VPN的CE之间的连接建立。由于每个PE处的PIT与L1VPN关联，因此可以轻松支持此功能。根据适用的限制策略，可以在入口PE或出口PE处应用限制，但是注意，在出口处应用策略可能会浪费网络内的信令工作，因为L1VPN连接是无意义的尝试。
In addition, the L1VPN Basic Mode does not restrict use of any advanced admission control based on various policies.
此外，L1VPN基本模式不限制基于各种策略的任何高级准入控制的使用。
In the L1VPN Basic Mode, L1VPN connection topology is controlled by the customer. That is, a customer can request setup/deletion/modification of L1VPN connections using signaling mechanisms specified in [RFC5251].
在L1VPN基本模式中，L1VPN连接拓扑由客户控制。也就是说，客户可以使用[RFC5251]中指定的信令机制请求设置/删除/修改L1VPN连接。
Also note that if there are multiple CE-to-PE TE links (single-homed or multi-homed), a customer can specify which CE-to-PE TE link to use to support any L1VPN connection. Alternatively, a customer may let the provider choose the CE-to-PE TE link at the egress side, as described in Section 5.2.3.
还请注意，如果存在多个CE到PE TE链路（单宿或多宿），客户可以指定使用哪个CE到PE TE链路来支持任何L1VPN连接。或者，如第5.2.3节所述，客户可让提供商选择出口侧的CE-to-PE-TE链路。
A CE needs to obtain the remote CPI to which it wishes to request a connection. Since, in the L1VPN Basic Mode, there is no routing information exchange between a CE and a PE, there is no dynamic mechanism supported as part of the Basic Mode L1VPN service, and the knowledge of remote CPIs must be acquired in a L1VPN-specific way, perhaps through configuration or through a directory server.
CE需要获取其希望请求连接的远程CPI。由于在L1VPN基本模式中，CE和PE之间没有路由信息交换，因此基本模式L1VPN服务不支持动态机制，远程CPI的知识必须以L1VPN特定的方式获取，可能通过配置或通过目录服务器。
If an L1VPN is used by a customer to operate a private IP network, the customer may wish to form routing adjacencies over the CE-to-CE L1VPN connections. The L1VPN Basic Mode does not enforce any restriction on such operation by a customer, and the use made of the L1VPN connections is transparent to the provider network.
如果客户使用L1VPN操作专用IP网络，则客户可能希望通过CE到CE L1VPN连接形成路由邻接。L1VPN基本模式不对客户的此类操作实施任何限制，并且L1VPN连接的使用对提供商网络是透明的。
Furthermore, if an L1VPN is used by a customer to operate a private Multiprotocol Label Switching (MPLS) or GMPLS network, the customer may wish to treat a L1VPN connection as a TE link, and this requires a CE-to-CE control channel. Note that a Forwarding Adjacency [RFC4206] cannot be formed from the CE-to-CE L1VPN connection in the Basic Mode because there is no routing exchange between CE and PE. That is, the customer network and the provider network do not share a routing instance, and the customer control channel cannot be carried within the provider control plane. But where the CE provides suitable adaptation (for example, where the customer network is a packet- switched MPLS or GMPLS network), the customer control channel may be in-band and a routing adjacency may be formed between the CEs using the L1VPN connection. Otherwise, CE-to-CE control plane connectivity may form part of the L1VPN service provided to the customer by the provider and may be achieved within the L1VPN connection (for example, through the use of overhead bytes) or through a dedicated control channel connection or tunnel. The options available are discussed further in Section 10.2 of [RFC4847].
此外，如果客户使用L1VPN来操作专用多协议标签交换（MPLS）或GMPLS网络，则客户可能希望将L1VPN连接视为TE链路，这需要CE到CE控制信道。注意，在基本模式下，无法从CE到CE L1VPN连接形成转发邻接[RFC4206]，因为CE和PE之间没有路由交换。即，客户网络和提供商网络不共享路由实例，并且客户控制信道不能在提供商控制平面内承载。但是，在CE提供适当适配的情况下（例如，在客户网络是分组交换MPLS或GMPLS网络的情况下），客户控制信道可以是带内的，并且可以使用L1VPN连接在CE之间形成路由邻接。否则，CE到CE控制平面连接可以形成提供商向客户提供的L1VPN服务的一部分，并且可以在L1VPN连接内（例如，通过使用开销字节）或通过专用控制信道连接或隧道来实现。[RFC4847]第10.2节进一步讨论了可用选项。
There are several factors that impact scalability.
有几个因素会影响可伸缩性。
o Number of L1VPNs (PITs) configured on each PE
o 每个PE上配置的L1VPN（PITs）数量
With the increase of this number, information to be maintained on the PE increases. Theoretically, the upper limit of the number of L1VPNs supported in a provider network is governed by how the ID associated with a L1VPN is allocated, and the number of PITs configured on each PE is limited by this number. However, implementations may impose arbitrary limits on the number of PITs supported by any one PE.
随着该数字的增加，要在PE上维护的信息也会增加。理论上，提供商网络中支持的L1VPN数量的上限取决于与L1VPN关联的ID的分配方式，每个PE上配置的PIT数量受该数量的限制。但是，实施可能会对任何一个PE支持的坑数施加任意限制。
o Number of CE-to-PE TE links for each L1VPN
o 每个L1VPN的CE到PE TE链路数
With the increase of this number, information to be maintained in each PIT increases. When auto-discovery mechanisms are used, the amount of information that an auto-discovery mechanism can support may restrict this number.
随着该数量的增加，每个坑中需要维护的信息也会增加。使用自动发现机制时，自动发现机制可以支持的信息量可能会限制此数量。
Note that [RFC5252] floods membership information not only among PEs, but also to all P nodes. This may lead to scalability concerns, compared to [RFC5195], which distributes membership information only among PEs. Alternatively, a separate instance of the OSPF protocol can be used just between PEs for distributing membership information. In such a case, Ps do not participate in flooding.
注意，[RFC5252]不仅在PEs之间，而且向所有P节点发送成员信息。与[RFC5195]相比，这可能导致可伸缩性问题，后者只在PEs之间分发成员信息。或者，OSPF协议的单独实例可以仅在PEs之间用于分发成员信息。在这种情况下，Ps不参与洪水。
Note that in the L1VPN Basic Mode, a PE needs to obtain only CE-to-PE TE link information, and not customer routing information, which is quite different from the mode of operation of an L3VPN. Therefore, the scalability concern is considered to be less problematic.
请注意，在L1VPN基本模式中，PE只需要获取CE到PE TE链路信息，而不需要获取客户路由信息，这与L3VPN的操作模式大不相同。因此，可伸缩性问题被认为问题较少。
o Number of L1VPN connections
o L1VPN连接数
With the increase of this number, information to be maintained on each PE/P increases. When stitching or nesting is used, the state to be maintained at each PE increases compared to when connectivity is achieved without stitching or nesting.
随着该数字的增加，每个PE/P上需要维护的信息增加。当使用缝合或嵌套时，与在不缝合或嵌套的情况下实现连接时相比，每个PE上要保持的状态会增加。
However, in a Layer 1 core, this number is always bounded by the available physical resource because each LSP uses a separate label which is directly bound to a physical, switchable resource
但是，在第1层核心中，该数字始终受可用物理资源的限制，因为每个LSP使用单独的标签，该标签直接绑定到物理的可切换资源
(timeslot, lambda, or fiber). Thus, it can be safely assumed that the PEs/Ps can comfortably handle the number of LSPs that they may be called on to switch for a L1VPN.
（时隙、λ或光纤）。因此，可以安全地假设，PEs/Ps可以轻松地处理它们可能被调用以切换到L1VPN的LSP的数量。
The L1VPN Basic Mode supports the following data plane recovery techniques [RFC5251].
L1VPN基本模式支持以下数据平面恢复技术[RFC5251]。
o PE-to-PE segment recovery
o PE到PE段恢复
The CE indicates to protect the PE-to-PE segment by including Protection Object specified in [RFC4873] in the Path message and setting Segment Recovery Flags. The CE may also indicate the branch and merge nodes by including a Secondary Explicit Route Object.
CE指示通过在路径消息中包括[RFC4873]中指定的保护对象并设置段恢复标志来保护PE到PE段。CE还可以通过包括次显式路由对象来指示分支和合并节点。
Depending on the signaling mechanisms used within the provider network, details on how to protect the PE-to-PE segment may differ as follows.
根据提供商网络中使用的信令机制，关于如何保护PE-to-PE段的细节可能会有所不同，如下所示。
- If LSP stitching or LSP hierarchy are used to provision the PE-to-PE segment, then the PE-to-PE LSP may be protected using end-to-end recovery within the provider network.
- 如果使用LSP缝合或LSP层次结构来提供PE-to-PE段，则可以使用提供商网络内的端到端恢复来保护PE-to-PE LSP。
- If the CE-to-CE L1VPN connection is a single end-to-end LSP (including if session shuffling is used), then the PE-to-PE LSP segment may be protected using segment protection [RFC4873].
- 如果CE到CE L1VPN连接是单端到端LSP（包括如果使用了会话洗牌），则PE到PE LSP段可以使用段保护进行保护[RFC4873]。
o CE-to-PE recovery and PE-to-PE recovery via link protection
o 通过链路保护实现CE到PE恢复和PE到PE恢复
The CE indicates to protect ingress and egress CE-to-PE links as well as links within the provider network by including the Protection Object specified in [RFC3473] and setting Link Flags in the Path message.
CE指示通过包括[RFC3473]中指定的保护对象并在路径消息中设置链接标志来保护CE到PE链路以及提供商网络内的链路的入口和出口。
- The ingress and egress CE-to-PE link may be protected at a lower layer.
- PE链路的入口和出口可在较低层受到保护。
Depending on the signaling mechanisms used within the provider network, details on how to protect links within the provider network may differ as follows.
取决于提供商网络内使用的信令机制，关于如何保护提供商网络内的链路的细节可能不同，如下所示。
- If the PE-to-PE segment is provided as a single TE link (stitching or hierarchy) so that the provider network can perform simple PE-to-PE routing, then the TE link may offer link-level protection through the instantiation of multiple PE-to-PE LSPs.
- 如果PE-to-PE段作为单个TE链路（缝合或层次）提供，以便提供商网络可以执行简单的PE-to-PE路由，则TE链路可以通过实例化多个PE-to-PE lsp来提供链路级保护。
- The PE-to-PE segment may be provisioned using only link-protected links within the core network.
- 可仅使用核心网络内的链路保护链路来供应PE-to-PE段。
Note that it is not possible to protect only the CE-to-PE portion or the PE-to-PE portion by link protection because the CE-to-CE signaling request asks for a certain level of link protection on all links used by the LSP. Also, it is not possible to protect the CE-to-PE portion by link recovery and the PE-to-PE portion by segment recovery at the same time.
注意，由于CE-to-CE信令请求请求在LSP使用的所有链路上请求一定级别的链路保护，因此不可能仅保护CE-to-PE部分或逐链路保护的PE-to-PE部分。此外，不可能同时通过链路恢复保护CE到PE部分和通过段恢复保护PE到PE部分。
CE-to-CE recovery through the use of connections from one CE to diverse PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode.
在L1VPN基本模式下，不支持通过使用从一个CE到多个PE的连接（即双归巢）实现CE到CE的恢复。
The L1VPN Basic Mode allows use of GMPLS control plane resiliency mechanisms. This includes, but is not limited to, control channel management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] and [RFC5063]) between a CE and a PE, as well as within the provider network.
L1VPN基本模式允许使用GMPLS控制平面弹性机制。这包括但不限于LMP[RFC4204]中的控制信道管理以及CE和PE之间以及提供商网络内的RSVP-TE（[RFC3473]和[RFC5063]）中的故障处理。
Security considerations are described in [RFC4847], and this section describes how these considerations are addressed in the L1VPN Basic Mode.
[RFC4847]中描述了安全注意事项，本节描述了如何在L1VPN基本模式中解决这些注意事项。
Additional discussion of GMPLS security can be found in [GMPLS-SEC].
有关GMPLS安全性的更多讨论，请参见[GMPLS-SEC]。
As specified in [RFC5251], a provider's topology confidentiality is preserved by the Basic Mode. Since there is no routing exchange between PE and CE, the customer network can gather no information about the provider network. Further, as described in Section 4 of [RFC4208], a PE may filter the information present in a Record Route Object (RRO) that is signaled from the provider network to the customer network. In addition, as described in Section 5 of [RFC4208] and Section 4.4 of [RFC5251], when a Notify message is sent to a CE, it is possible to hide the provider internal address. This is accomplished by a PE updating the Notify Node Address with its own address when the PE receives a NOTIFY_REQUEST object from the CE.
如[RFC5251]中所述，提供程序的拓扑机密性由基本模式保留。由于PE和CE之间没有路由交换，因此客户网络无法收集有关提供商网络的任何信息。此外，如[RFC4208]第4节所述，PE可以过滤记录路由对象（RRO）中存在的信息，该记录路由对象从提供商网络发信号到客户网络。此外，如[RFC4208]第5节和[RFC5251]第4.4节所述，当向CE发送通知消息时，可以隐藏提供商内部地址。这是通过PE在从CE接收到Notify_请求对象时用自己的地址更新Notify Node地址来实现的。
Even in the case of pre-computed and/or pre-signaled PE-to-PE segments, provider topology confidentiality may be preserved through the use of path key IDs [CONF-SEG].
即使在预先计算和/或预先发信号的PE-to-PE段的情况下，也可以通过使用路径密钥id[CONF-SEG]来保持提供者拓扑的机密性。
The customer's topology confidentiality cannot be completely hidden from the provider network. At the least, the provider network will know about the addresses and locations of CEs. Other customer topology information will remain hidden from the provider in the Basic Mode, although care may be needed to protect the customer control channel as described in Section 8.4.
不能对提供商网络完全隐藏客户的拓扑机密性。至少，提供商网络将知道CE的地址和位置。在基本模式下，其他客户拓扑信息将对提供商保持隐藏，尽管可能需要注意保护客户控制通道，如第8.4节所述。
The provider network is responsible for maintaining confidentiality of topology information between customers and across L1VPNs. Since there is no distribution of routing information from PE to CE in the Basic Mode, there is no mechanism by which the provider could accidentally, or deliberately but automatically, distribute this information.
提供商网络负责维护客户之间以及跨L1VPN的拓扑信息的机密性。由于在基本模式下没有从PE到CE的路由信息分发，因此没有提供程序可以意外地或有意地自动分发此信息的机制。
The provider network is protected from direct control from within customer networks through policy and through filtering of signaling messages.
通过策略和信令消息过滤，保护提供商网络免受来自客户网络内部的直接控制。
There is a service-based policy installed at each PE that directs how a PE should react to a L1VPN connection request received from any CE. Each CE is configured at the PE (or through a policy server) for its membership of a L1VPN, and so CEs cannot dynamically bind to a PE or join a L1VPN. With this configuration comes the policy that tells the PE how to react to a L1VPN connection request (for example, whether to allow dynamic establishment of PE-to-PE connections). Thus, the provider network is protected against spurious L1VPN connection requests and can charge for all L1VPN connections according to the service agreement with the customers. Hence, the provider network is substantially protected against denial-of-service (DoS) attacks.
每个PE上都安装了基于服务的策略，该策略指导PE如何响应从任何CE收到的L1VPN连接请求。每个CE都在PE（或通过策略服务器）上配置为其L1VPN的成员身份，因此CE无法动态绑定到PE或加入L1VPN。此配置附带的策略告诉PE如何响应L1VPN连接请求（例如，是否允许动态建立PE到PE的连接）。因此，提供商网络受到保护，不受虚假L1VPN连接请求的影响，并且可以根据与客户的服务协议对所有L1VPN连接收费。因此，提供商网络基本上受到了拒绝服务（DoS）攻击的保护。
At the same time, if a Path message from a CE contains an Explicit Route Object (ERO) specifying the route within provider network, it is rejected by the PE. Thus, the customer network has no control over the resources in the provider network.
同时，如果来自CE的Path消息包含指定提供商网络内路由的显式路由对象（ERO），则PE将拒绝该消息。因此，客户网络无法控制提供商网络中的资源。
As described in [RFC4847], at Layer 1, data plane information is normally assumed to be secure once connections are established since the optical signals themselves are normally considered to be hard to intercept or modify, and it is considered difficult to insert data into an optical stream. The very use of an optical signal may be considered to provide confidentiality and integrity to the payload data. Furthermore, as indicated in [RFC4847], L1VPN connections are
如[RFC4847]所述，在第1层，一旦建立连接，数据平面信息通常被认为是安全的，因为光信号本身通常被认为难以截获或修改，并且被认为难以将数据插入光流。光信号的使用本身可被视为提供有效载荷数据的机密性和完整性。此外，如[RFC4847]所示，L1VPN连接是
each dedicated to a specific L1VPN by which an additional element of security for the payload data is provided.
每个专用于特定的L1VPN，通过该L1VPN为有效负载数据提供额外的安全元素。
Misconnection remains a security vulnerability for user data. If a L1VPN connection were to be misconnected to the wrong destination, user data would be delivered to the wrong consumers. In order to protect against mis-delivery, each L1VPN connection is restricted to use only within a single L1VPN. That is, a L1VPN connection does not connect CEs that are in different L1VPNs. In order to realize this, the identity of CEs is assured as part of the service contract. And upon receipt of a request for connection setup, the provider network assures that the connection is requested between CEs belonging to the same L1VPN. This is achieved as described in Section 5.3.
错误连接仍然是用户数据的一个安全漏洞。如果L1VPN连接错误地连接到错误的目的地，则用户数据将传递到错误的使用者。为了防止错误传递，每个L1VPN连接仅限于在单个L1VPN内使用。也就是说，L1VPN连接不会连接不同L1VPN中的CE。为了实现这一点，CEs的身份作为服务合同的一部分得到了保证。并且在接收到连接设置请求时，提供商网络确保在属于相同L1VPN的ce之间请求连接。这是按照第5.3节所述实现的。
Furthermore, users with greater sensitivity to the security of their payload data should apply appropriate security measures within their own network layer. For example, a customer exchanging IP traffic over a L1VPN connection may choose to use IPsec to secure that traffic (i.e., to operate IPsec on the CE-to-CE exchange of IP traffic).
此外，对有效负载数据的安全性更敏感的用户应在其自己的网络层内应用适当的安全措施。例如，通过L1VPN连接交换IP流量的客户可以选择使用IPsec来保护该流量（即，在IP流量的CE到CE交换上操作IPsec）。
There are two aspects for control plane security.
控制飞机的安全性有两个方面。
First, the entity connected over a CE-to-PE control channel must be identified. This is done when a new CE is added as part of the service contract and the necessary control channel is established. This identification can use authentication procedures available in RSVP-TE [RFC3209]. That is, control plane entities are identified within the core protocols used for signaling, but are not authenticated unless the authentication procedures of [RFC3209] are used.
首先，必须识别通过CE-to-PE控制通道连接的实体。当新的CE作为服务合同的一部分被添加，并且建立了必要的控制渠道时，就可以实现这一点。此标识可以使用RSVP-TE[RFC3209]中提供的身份验证程序。也就是说，在用于信令的核心协议中标识控制平面实体，但除非使用[RFC3209]的认证程序，否则不会对其进行认证。
Second, it must be possible to secure communication over a CE-to-PE control channel. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, the communication channel could be considered as secure. However, when the communication channel is physically shared among customers, security mechanisms need to be available and should be enforced. RSVP-TE [RFC3209] provides for tamper-protection of signaling message exchanges through the optional Integrity object. IPsec tunnels can be used to carry the control plane messages to further ensure the integrity of the signaling messages.
第二，必须能够通过CE到PE控制通道保护通信。如果客户和提供商之间的通信通道（控制通道、管理接口）在物理上是每个客户独立的，则可以认为该通信通道是安全的。但是，当通信通道在客户之间物理共享时，安全机制需要可用，并且应该强制执行。RSVP-TE[RFC3209]通过可选的完整性对象为信令消息交换提供篡改保护。IPsec隧道可用于承载控制平面消息，以进一步确保信令消息的完整性。
Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms, such as
注意，即使在物理上独立的通信信道的情况下，客户也可能希望应用安全机制，例如
IPsec, to assure higher security, and such mechanisms must be available.
IPsec，以确保更高的安全性，并且此类机制必须可用。
Furthermore, the provider network needs mechanisms to detect DoS attacks and to protect against them reactively and proactively. In the Basic Mode, this relies on management systems. For example, management systems collect and analyze statistics on signaling requests from CEs, and protect against malicious behaviors where necessary.
此外，提供商网络需要检测DoS攻击的机制，并主动和被动地防范DoS攻击。在基本模式中，这依赖于管理系统。例如，管理系统收集和分析来自CEs的信令请求的统计数据，并在必要时防止恶意行为。
Lastly, it should be noted that customer control plane traffic carried over the provider network between CEs needs to be protected. Such protection is normally the responsibility of the customer network and can use the security mechanisms of the customer signaling and routing protocols (for example, RSVP-TE [RFC3209]) or may use IPsec tunnels between CEs. CE-to-CE control plane security may form part of the data plane protection where the control plane traffic is carried in-band in the L1VPN connection. Where the CE-to-CE control plane connectivity is provided as an explicit part of the L1VPN service by the provider, control plane security should form part of the service agreement between the provider and customer.
最后，需要注意的是，在CEs之间通过提供商网络传输的客户控制平面流量需要得到保护。这种保护通常由客户网络负责，可以使用客户信令和路由协议（例如，RSVP-TE[RFC3209]）的安全机制，或者可以在CE之间使用IPsec隧道。CE-to-CE控制平面安全性可能构成数据平面保护的一部分，其中控制平面流量在L1VPN连接中带内传输。如果供应商将CE到CE控制平面连接作为L1VPN服务的明确部分提供，则控制平面安全性应构成供应商和客户之间服务协议的一部分。
Manageability considerations are described in [RFC4847]. In the L1VPN Basic Mode, we rely on management systems for various aspects of the different service functions, such as fault management, configuration and policy management, accounting management, performance management, and security management (as described in Section 8).
[RFC4847]中描述了可管理性注意事项。在L1VPN基本模式中，我们依靠管理系统实现不同服务功能的各个方面，如故障管理、配置和策略管理、记帐管理、性能管理和安全管理（如第8节所述）。
In order to support various management functionalities, MIB modules need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD-MIB) [RFC4802] can be used for GMPLS-based traffic engineering configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) [RFC4220] can be used for configuration and management of TE links.
为了支持各种管理功能，需要支持MIB模块。具体而言，GMPLS TE MIB（GMPLS-TE-STD-MIB）[RFC4802]可用于基于GMPLS的流量工程配置和管理，而TE链路MIB（TE-Link-STD-MIB）[RFC4220]可用于TE链路的配置和管理。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[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月。
[RFC4026] Anderssion, L. and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersion，L.和Madsen，T.，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，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月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，2007年4月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]Ould Brahim，H.，Fedyk，D.，和Y.Rekhter，“基于BGP的第一层VPN自动发现”，RFC 51952008年6月。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
[RFC5251]Fedyk，D.，Ed.，Rekhter，Y.，Ed.，Papadimitriou，D.，Rabbat，R.，和L.Berger，“第1层VPN基本模式”，RFC 52512008年7月。
[RFC5252] Bryskin, I. and Berger, L., "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[RFC5252]Bryskin，I.和Berger，L.，“基于OSPF的第1层VPN自动发现”，RFC 5252，2008年7月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[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月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220]Dubuc，M.，Nadeau，T.，和J.Lang，“交通工程链路管理信息库”，RFC 4220，2005年11月。
[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月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 4802，2007年2月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana，A.，Ed.，和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，2007年10月。
[BGP-TE] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-TE]Ould Brahim，H.，Fedyk，D.，和Y.Rekhter，“交通工程属性”，在建工程，2008年1月。
[CONF-SEG] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, May 2008.
[CONF-SEG]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于密钥的机制在域间路径计算中保持拓扑机密性”，正在进行的工作，2008年5月。
[GMPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[GMPLS-SEC]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年2月。
The authors would like to thank Ichiro Inoue for valuable comments. In addition, the authors would like to thank Marco Carugi and Takumi Ohba for valuable comments in the early development of this document.
作者要感谢井上一郎的宝贵评论。此外，作者还要感谢Marco Carugi和Takumi Ohba在本文件早期开发过程中提出的宝贵意见。
Thanks to Tim Polk and Mark Townsley for comments during IESG review.
感谢Tim Polk和Mark Townsley在IESG审查期间的评论。
Authors' Addresses
作者地址
Tomonori Takeda (editor) NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7434 EMail: takeda.tomonori@lab.ntt.co.jp
武田智诺里（编辑）NTT网络服务系统实验室，NTT公司3-9-11，东京武藏市中岛町，180-8585日本电话：+81 422 59 7434电子邮件：武田。tomonori@lab.ntt.co.jp
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com
德博拉·布伦加德AT&T室。D1-3C22-200美国新泽西州米德尔顿南劳雷尔大道07748号电话：+1732 4201573电子邮件：dbrungard@att.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
阿德里安·法雷尔老狗咨询电话：+44（0）1978 860944电子邮件：adrian@olddog.co.uk
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 EMail: hbrahim@nortel.com
Hamid Ould Brahim Nortel Networks邮政信箱3511加拿大渥太华C站K1Y 4H7电话：+1（613）765 3418电子邮件：hbrahim@nortel.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1，B-2018比利时安特卫普电话：+32 3 2408491电子邮件：Dimitri。papadimitriou@alcatel-朗讯
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.