Network Working Group T. Takeda, Ed.
Request for Comments: 4847 NTT
Category: Informational April 2007
Network Working Group T. Takeda, Ed.
Request for Comments: 4847 NTT
Category: Informational April 2007
Framework and Requirements for Layer 1 Virtual Private Networks
第1层虚拟专用网络的框架和要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
本文档提供了第1层虚拟专用网络（L1VPN）的框架和服务级别要求。该框架旨在帮助开发和标准化协议和机制，以支持可互操作的L1VPN。
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
本文档分析了L1VPN的动机、高级（服务级别）需求，并概述了可用于构建L1VPN的一些体系结构模型。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview ........................................................5
3.1. Network Topology ...........................................5
3.2. Introducing Layer 1 VPNs ...................................5
3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6
3.4. Relationship with ITU-T ....................................7
4. Motivations .....................................................8
4.1. Basic Layer 1 Services .....................................8
4.1.1. L1VPN for Dynamic Layer 1 Provisioning ..............9
4.2. Merits of L1VPN ............................................9
4.2.1. Customer Merits .....................................9
4.2.2. Provider Merits ....................................10
4.3. L1VPN Deployment Scenarios ................................10
4.3.1. Multi-Service Backbone .............................11
4.3.2. Carrier's Carrier ..................................11
4.3.3. Layer 1 Resource Trading ...........................12
4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview ........................................................5
3.1. Network Topology ...........................................5
3.2. Introducing Layer 1 VPNs ...................................5
3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6
3.4. Relationship with ITU-T ....................................7
4. Motivations .....................................................8
4.1. Basic Layer 1 Services .....................................8
4.1.1. L1VPN for Dynamic Layer 1 Provisioning ..............9
4.2. Merits of L1VPN ............................................9
4.2.1. Customer Merits .....................................9
4.2.2. Provider Merits ....................................10
4.3. L1VPN Deployment Scenarios ................................10
4.3.1. Multi-Service Backbone .............................11
4.3.2. Carrier's Carrier ..................................11
4.3.3. Layer 1 Resource Trading ...........................12
4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
4.3.5. Scheduling Service .................................13
5. Reference Model ................................................14
5.1. Management Systems ........................................15
6. Generic Service Description ....................................15
6.1. CE Construct ..............................................15
6.2. Generic Service Features ..................................16
7. Service Models .................................................16
7.1. Management-Based Service Model ............................17
7.2. Signaling-Based Service Model (Basic Mode) ................17
7.2.1. Overlay Service Model ..............................18
7.3. Signaling and Routing Service Model (Enhanced Mode) .......19
7.3.1. Overlay Extension Service Model ....................20
7.3.2. Virtual Node Service Model .........................20
7.3.3. Virtual Link Service Model .........................21
7.3.4. Per-VPN Peer Service Model .........................22
8. Service Models and Service Requirements ........................22
8.1. Detailed Service Level Requirements .......................24
9. Recovery Aspects ...............................................25
9.1. Recovery Scope ............................................25
9.2. Recovery Resource Sharing Schemes .........................26
10. Control Plane Connectivity ....................................27
10.1. Control Plane Connectivity between a CE and a PE .........27
10.2. Control Plane Connectivity between CEs ...................28
11. Manageability Considerations ..................................29
12. Security Considerations .......................................31
12.1. Types of Information .....................................32
12.2. Security Features ........................................32
12.3. Scenarios ................................................33
13. Acknowledgements ..............................................34
14. Contributors ..................................................34
15. Normative References ..........................................35
16. Informative References ........................................35
4.3.5. Scheduling Service .................................13
5. Reference Model ................................................14
5.1. Management Systems ........................................15
6. Generic Service Description ....................................15
6.1. CE Construct ..............................................15
6.2. Generic Service Features ..................................16
7. Service Models .................................................16
7.1. Management-Based Service Model ............................17
7.2. Signaling-Based Service Model (Basic Mode) ................17
7.2.1. Overlay Service Model ..............................18
7.3. Signaling and Routing Service Model (Enhanced Mode) .......19
7.3.1. Overlay Extension Service Model ....................20
7.3.2. Virtual Node Service Model .........................20
7.3.3. Virtual Link Service Model .........................21
7.3.4. Per-VPN Peer Service Model .........................22
8. Service Models and Service Requirements ........................22
8.1. Detailed Service Level Requirements .......................24
9. Recovery Aspects ...............................................25
9.1. Recovery Scope ............................................25
9.2. Recovery Resource Sharing Schemes .........................26
10. Control Plane Connectivity ....................................27
10.1. Control Plane Connectivity between a CE and a PE .........27
10.2. Control Plane Connectivity between CEs ...................28
11. Manageability Considerations ..................................29
12. Security Considerations .......................................31
12.1. Types of Information .....................................32
12.2. Security Features ........................................32
12.3. Scenarios ................................................33
13. Acknowledgements ..............................................34
14. Contributors ..................................................34
15. Normative References ..........................................35
16. Informative References ........................................35
This document examines motivations for Layer 1 Virtual Private Networks (L1VPNs), provides high-level (service-level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
本文档分析了第1层虚拟专用网络（L1VPN）的动机，提供了高级（服务级别）要求，并概述了可用于构建L1VPN的一些体系结构模型。
The objective of the document is mainly to present the requirements and architecture based on the work undertaken within Question 11 of Study Group 13 of the ITU-T.
本文件的目的主要是根据ITU-T第13研究组问题11中开展的工作，提出要求和体系结构。
L1VPNs provide services over layer 1 networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by Generalized Multi-Protocol Label Switching (GMPLS) protocols.
L1VPN通过第1层网络提供服务。本文档提供L1VPN的框架，以及由通用多协议标签交换（GMPLS）协议控制的网络实现该框架。
Use of GMPLS protocols for providing L1VPN services has several advantages, such as:
使用GMPLS协议提供L1VPN服务有几个优点，例如：
- Flexible network operation.
- 灵活的网络操作。
- Use of standardized protocols.
- 使用标准化协议。
- Use of common control and measurement plane protocols applicable to various layer 1 networks, including Time Division Multiplexing (TDM) networks and optical networks.
- 使用适用于各种第1层网络的通用控制和测量平面协议，包括时分复用（TDM）网络和光网络。
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]中所述进行解释。
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026].
假定读者熟悉[RFC3031]、[RFC3209]、[RFC3471]、[RFC3473]、[RFC4202]、[RFC3945]、[RFC4208]和[RFC4026]中的术语。
In this context, a Layer 1 Network is any transport network that has connectivity and/or switching using spatial switching (e.g., incoming port or fiber to outgoing port or fiber), lambda-switching, or time-division-multiplex-switching.
在此上下文中，第1层网络是具有使用空间交换（例如，输入端口或光纤到输出端口或光纤）、lambda交换或时分复用交换的连接和/或交换的任何传输网络。
A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network to provide layer 1 connectivity between two or more customer sites, and where the customer has some control over the establishment and type of the connectivity. An alternative definition is simply to say that an L1VPN is a VPN whose data plane operates at layer 1. Further details of the essence of an L1VPN are provided in Section 3.
第1层VPN（L1VPN）是由核心第1层网络提供的一种服务，用于在两个或多个客户站点之间提供第1层连接，其中客户对连接的建立和类型具有一定的控制权。另一种定义是简单地说，L1VPN是数据平面在第1层运行的VPN。第3节提供了L1VPN本质的更多详细信息。
In addition, the following new terms are used within this document:
此外，本文件中使用了以下新术语：
- Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link.
- 虚拟链路：供应商网络流量工程（TE）链路，在路由信息中向客户公布，用于包括路径计算在内的目的。虚拟链路的两个端点之间可能存在也可能不存在直接数据链路。
- Virtual node: A provider network logical node advertised to customers in routing information. A virtual node may represent a single physical node, or multiple physical nodes and the links between them.
- 虚拟节点：在路由信息中通告给客户的提供商网络逻辑节点。虚拟节点可以表示单个物理节点，也可以表示多个物理节点及其之间的链路。
- VPN end point: A Customer Edge (CE) device's data plane interface, which is connected to a Provider Edge (PE) device, and which is part of the VPN membership. Note that a data plane interface is associated with a TE link end point. For example, if a CE router's interface is a channelized interface (defined in SONET/SDH), a channel in the channelized interface can be a data plane interface.
- VPN端点：客户边缘（CE）设备的数据平面接口，连接到提供商边缘（PE）设备，是VPN成员资格的一部分。请注意，数据平面接口与TE链接端点相关联。例如，如果CE路由器的接口是信道化接口（在SONET/SDH中定义），则信道化接口中的信道可以是数据平面接口。
- VPN connection (or connection in the L1VPN context): A connection between a pair of VPN end points. Note that in some scenarios a connection may be established between a pair of C (Customer) devices using this CE-CE VPN connection as a segment or forwarding adjacency defined in [RFC4206].
- VPN连接（或L1VPN上下文中的连接）：一对VPN端点之间的连接。注意，在某些情况下，可以使用此CE-CE VPN连接作为[RFC4206]中定义的段或转发邻接，在一对C（客户）设备之间建立连接。
Note that the following terms are aligned with Provider Provisioned VPN (PPVPN) terminology [RFC4026], and in this document, have a meaning in the context of L1VPNs, unless otherwise specified.
请注意，以下术语与提供商提供的VPN（PPVPN）术语[RFC4026]一致，在本文档中，除非另有规定，否则在L1VPN上下文中具有含义。
- CE device: A CE device is a customer device that receives L1VPN service from the provider. A CE device is connected to at least one PE device. A CE device can be a variety of devices, for example, Time Division Multiplexing (TDM) switch, router, and layer 2 switch. A CE device does not have to have the capability to switch at layer 1, but it is capable of receiving a layer 1 signal and either switching it or terminating it with adaptation. A CE device may be attached to one or more C devices on the customer site, and it may be a host using a layer 1 connection directly.
- CE设备：CE设备是从提供商接收L1VPN服务的客户设备。CE设备连接到至少一个PE设备。CE设备可以是多种设备，例如时分复用（TDM）交换机、路由器和第2层交换机。CE设备不必具备在第1层进行切换的能力，但它能够接收第1层信号并通过自适应进行切换或终止。CE设备可以连接到客户站点上的一个或多个C设备，并且它可以是直接使用第1层连接的主机。
- PE device: A PE device is a provider device that provides L1VPN service to the customer. A PE device is connected to at least one CE device. A layer 1 PE device is a TDM switch, an Optical Cross-Connect (OXC) (see [RFC3945]), or a Photonic Cross-Connect (PXC) (see [RFC3945]). Alternatively, a PE device 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.).
- PE设备：PE设备是向客户提供L1VPN服务的提供商设备。PE设备连接到至少一个CE设备。第1层PE设备是TDM交换机、光交叉连接（OXC）（参见[RFC3945]）或光子交叉连接（PXC）（参见[RFC3945]）。或者，PE设备可以是以太网专用线（EPL）类型的设备，其将以太网帧映射到第1层连接上（通过TDM上的以太网等）。
- P (Provider) device: A P device is a provider device that is connected only to other provider devices (P or PE devices). A layer 1 P is a TDM switch, OXC, or PXC.
- P（提供商）设备：P设备是仅连接到其他提供商设备（P或PE设备）的提供商设备。第1p层是TDM交换机、OXC或PXC。
- Customer: A customer has authority over a set of CE devices within the same VPN (e.g., the owner of CE devices). Note that a customer may outsource the management of CE devices to other organizations, including to the provider itself.
- 客户：客户对同一VPN内的一组CE设备拥有权限（例如，CE设备的所有者）。请注意，客户可以将CE设备的管理外包给其他组织，包括供应商本身。
- Provider: A provider has authority over the management of the provider network.
- 提供商：提供商有权管理提供商网络。
- Membership information: A list of CE-PE TE link addresses belonging to the same VPN. Membership information contains the association of a CE, a PE, and a VPN.
- 成员信息：属于同一VPN的CE-PE TE链路地址列表。成员资格信息包含CE、PE和VPN的关联。
The layer 1 network, made of OXCs, TDM switches, or PXCs may be seen as consisting of PE devices that give access from outside of the network, and P devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of C devices with access to the layer 1 network made through CE devices.
由OXC、TDM交换机或PXC构成的第1层网络可以被视为由允许从网络外部访问的PE设备和仅在网络核心内运行的P设备组成。类似地，在第1层网络之外是由C设备组成的客户网络，通过CE设备访问第1层网络。
A CE and 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.
CE和PE通过一个或多个链路连接。CE还可以连接到多个PE，并且一个PE可以有多个CE连接到它。
A layer 1 connection is provided between a pair of CEs. Such a connection follows the hierarchy defined in [RFC4206]. That is, a CE-CE connection may be nested in a lower layer connection (e.g., VC3 connection over STM1 connection). Likewise, the switching capabilities of the interfaces of the CEs, PEs, and Ps on which a connection is routed, follow the hierarchy defined in [RFC4206].
在一对CE之间提供第1层连接。这种连接遵循[RFC4206]中定义的层次结构。也就是说，CE-CE连接可以嵌套在较低层连接中（例如，STM1连接上的VC3连接）。同样，连接路由的CEs、PEs和Ps接口的交换能力遵循[RFC4206]中定义的层次结构。
The concept of a PPVPN has been established through many previous documents such as [RFC4664] and [RFC4110]. Terminology for PPVPNs is set out in [RFC4026] with special reference to layer 2 and layer 3 VPNs.
PPVPN的概念已通过[RFC4664]和[RFC4110]等许多以前的文件确立。[RFC4026]中规定了PPVPN的术语，特别是第2层和第3层VPN。
The realization of L1VPNs can be based on extensions of the concepts of the PPVPN to the layer 1 network. It must be understood that meeting the requirements set out in this document may necessitate
L1VPN的实现可以基于PPVPN概念到第1层网络的扩展。必须理解，满足本文件规定的要求可能需要
extensions to the existing mechanisms both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). It is at the interface between CE and PE devices that the L1VPN service is provided.
对现有机制的扩展，用于第1层网络内的控制平面和网络边缘（CE和PE设备）的服务供应。在CE和PE设备之间的接口处提供L1VPN服务。
Note that the fundamental difference between L1VPNs and L2/L3 VPNs is that in L1VPNs, data plane connectivity does not guarantee control plane connectivity (and vice versa). But CE-PE control plane connectivity is required for L1VPN services provisioned through the control plane, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. Furthermore, the provision of CE-CE control plane connectivity over the provider network is also required for certain levels of L1VPN service, and this can be achieved by the exchange of control packets between CEs over the control plane of the provider network. This aspect is discussed further in Section 10.2.
请注意，L1VPN和L2/L3 VPN之间的根本区别在于，在L1VPN中，数据平面连接不能保证控制平面连接（反之亦然）。但是，通过控制平面提供的L1VPN服务需要CE-PE控制平面连接，并且CE-CE数据平面连接通过基于此控制平面连接的信令机制来维护。此外，对于某些级别的L1VPN服务，还需要在提供商网络上提供CE-CE控制平面连接，这可以通过在提供商网络的控制平面上的CE之间交换控制分组来实现。第10.2节将进一步讨论这一方面。
Pre-existing efforts at standardization have focused on the provision of dynamic connections within the layer 1 network (signaling and routing) and the definition of interfaces for requesting services between the user and the layer 1 network over the User-Network Interface (UNI), and between networks across the External Network-Network Interface (E-NNI) (see [RFC3945], [RFC4208], [RFC4139], and [RFC4258]).
先前在标准化方面的努力集中于在第1层网络（信令和路由）内提供动态连接，并定义用户与第1层网络之间通过用户网络接口（UNI）请求服务的接口，以及通过外部网络接口在网络之间请求服务的接口（E-NNI）（参见[RFC3945]、[RFC4208]、[RFC4139]和[RFC4258]）。
Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) services that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations.
当前的UNIs包括促进端到端（即CE到CE）服务请求的功能，这些服务包括明确的路径、带宽要求、保护需求和（当然）目的地等约束的规范。
Current E-NNIs include features to exchange routing information, as well as to facilitate requests for end-to-end services.
当前的E-NNI包括交换路由信息以及促进端到端服务请求的功能。
The UNIs and E-NNIs may be applied in the context of L1VPNs. For example, the UNI may be applied between the CE and the PE, and the E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the CE and the PE.
UNIs和E-NNI可在L1VPN的上下文中应用。例如，UNI可应用于CE和PE之间，E-NNI可应用于PE之间（AS/SP间L1VPN），或CE和PE之间。
However, the existing UNI and E-NNI specifications do not provide sufficient parameters to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI/E-NNI, and these messages must be disambiguated to determine the L1VPN to which they apply. A control link is an IP link used for establishing a control channel between nodes.
然而，现有的UNI和E-NNI规范没有提供足够的参数来支持虚拟专用网络（VPN），而无需进行一些补充。例如，无法区分在UNI/e-NNI处通过共享控制链路（即，由多个VPN共享的控制链路）接收的控制消息，必须消除这些消息的歧义以确定它们应用的L1VPN。控制链路是用于在节点之间建立控制信道的IP链路。
Another example is that there is no clearly defined way of distributing membership information to be used in combination with UNI/E-NNI. This function is necessary in order to discover the existence and location of the CEs to be connected by L1 connections. Distribution of membership information is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]). Note that the method chosen for distribution of membership information depends on the solution used for supporting L1VPNs, which is outside of the scope of this document.
另一个例子是，没有明确定义的方式来分发要与UNI/E-NNI结合使用的成员信息。此功能对于发现要通过L1连接的CE的存在和位置是必需的。成员资格信息的分发通常由提供商完成，并可通过静态供应等机制或通过路由协议（例如，参见[RFC4110]第4.2.1节）实现。请注意，为分发成员资格信息而选择的方法取决于用于支持L1VPN的解决方案，这超出了本文档的范围。
Furthermore, customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. This requires address mapping mechanisms, but such mechanisms are not well defined in existing UNI/E-NNI specifications.
此外，客户寻址域可能相互重叠，也可能与服务提供商寻址域重叠。这需要地址映射机制，但现有的UNI/E-NNI规范中没有很好地定义这种机制。
Lastly, there is no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing information exchange, but there is no clearly defined way to allow limited routing information exchange (i.e., a specific set of routing information is distributed to a specific set of CEs).
最后，没有明确定义的方式来限制CE之间（或通过UNI/E-NNI）的连接。此外，E-NNI允许路由信息交换，但没有明确定义的方式允许有限的路由信息交换（即，一组特定的路由信息被分发到一组特定的CE）。
In order for L1VPNs to be supported in a fully functional manner, these additional capabilities and other requirements set out later in this document must be addressed.
为了使L1VPN能够以全功能的方式得到支持，必须解决这些附加功能和本文件后面列出的其他要求。
Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document.
请注意，AS/SP L1VPN之间需要进行本文档重点以外的其他分析。
The foundation of this document is based on the work of the ITU-T Study Group 13, Question 11, such as [Y.1312] and [Y.1313]. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, the foundation of this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that are familiar to the IETF.
该文件的基础是基于ITU-T研究小组13，问题11，如[Y.1312]和[Y1313]。一段时间以来，该小组一直在研究和指定L1VPN的需求和体系结构。在此背景下，本文档的基础是ITU-T的结果的表示，以及IETF所熟悉的术语和格式的这些结果的呈现。
In particular, this document is limited to the areas of concern of the IETF. That is, it is limited to layer 1 networks that utilize IP as the underlying support for their control plane.
特别是，本文件仅限于IETF关注的领域。也就是说，它仅限于使用IP作为其控制平面底层支持的第1层网络。
The foundation of this document presents the requirements and architectures developed within the ITU-T for better understanding within the IETF and to further cooperation between the two bodies.
该文件的基础提出了在ITU-T内开发的要求和架构，以便更好地理解IETF和进一步的合作。
Some work related to the L1VPN solution space has already been done within the IETF.
与L1VPN解决方案空间相关的一些工作已经在IETF中完成。
The general benefits and desirability of VPNs have been described many times and in many places ([RFC4110] and [RFC4664]). This document does not dwell on the merits of VPNs as such, but focuses entirely on the applicability of the VPN concept to layer 1 networks.
VPN的一般好处和可取性已在许多地方多次描述（[RFC4110]和[RFC4664]）。本文档不详细讨论VPN本身的优点，而是完全关注VPN概念对第1层网络的适用性。
Similarly, the utility and value of a control plane for the configuration, management, and operation of a layer 1 network is well-rehearsed [RFC3945].
类似地，控制平面对于第1层网络的配置、管理和操作的效用和价值也得到了充分的演练[RFC3945]。
Basic layer 1 services may be characterized in terms that include:
基本第1层服务的特征包括：
- Connectivity: Between a pair of CEs.
- 连通性：在一对CE之间。
- Capacity: For example, the bit rate for a TDM service or the capacity of a lambda.
- 容量：例如，TDM服务的比特率或lambda的容量。
- Transparency: For example, for an SDH network, overhead transparency.
- 透明度：例如，对于SDH网络，开销透明度。
- Availability: The percentage of time that the offered service meets the criteria that the provider defines, possibly agreed with each customer. To achieve the required level of availability for the customer connections the service provider's network may use restoration or protected resources [RFC4427].
- 可用性：提供的服务符合提供商定义的标准（可能与每个客户达成一致）的时间百分比。为了实现客户连接所需的可用性级别，服务提供商的网络可以使用恢复或受保护的资源[RFC4427]。
- Performance: The quality of the service delivered to customers, e.g., the number of error-seconds per month.
- 性能：向客户提供服务的质量，例如每月的错误秒数。
The layer 1 services may be categorized based on the combination of connectivity features (data plane) and service control capability features (control plane) available to the customer. A CE is associated with the service interface between a customer site and the provider network, and the categorization can be seen in the context of this service interface as follows.
第1层服务可基于可供客户使用的连接性特征（数据平面）和服务控制能力特征（控制平面）的组合进行分类。CE与客户站点和提供商网络之间的服务接口相关联，分类可以在该服务接口的上下文中看到，如下所示。
1. A single connection between a pair of CEs.
1. 一对CE之间的单个连接。
- Static Service: The classic private line service achieved through a permanent connection.
- 静态服务：通过永久连接实现的经典专线服务。
- Dynamic Service: Either a switched connection service, or a customer-controlled soft permanent connection service (i.e., the customer is in control of when the signaled part is established).
- 动态服务：交换连接服务或客户控制的软永久连接服务（即，客户控制信号部分建立的时间）。
2. Multiple connections among a set of CEs.
2. 一组CE之间的多个连接。
- Static Service: A private network service consisting of a mesh of permanent connections.
- 静态服务：由永久连接网组成的专用网络服务。
- Dynamic Service: A dynamic private network service consisting of any combination of switched connection services and customer-controlled soft permanent connection services.
- 动态服务：由交换连接服务和客户控制的软永久连接服务的任意组合组成的动态专用网络服务。
For service types 1 and 2, connections are point-to-point, and can be permanent, soft-permanent, or switched. For a static service, the management plane of the provider network is responsible for the management of both the network infrastructure and the end-user connections. For dynamic services, the management plane of the provider network is only responsible for the configuration of the infrastructure; end-user connections are established dynamically via the control plane of the provider network upon customer request.
对于服务类型1和2，连接是点对点的，可以是永久性连接、软永久性连接或交换式连接。对于静态服务，提供商网络的管理平面负责管理网络基础设施和最终用户连接。对于动态服务，提供商网络的管理平面仅负责基础设施的配置；根据客户请求，通过提供商网络的控制平面动态建立最终用户连接。
This document does not preclude other advanced services and topology support, such as point-to-multipoint (P2MP) services, as part of the layer 1 services, but these are for further study.
本文档不排除作为第1层服务的一部分的其他高级服务和拓扑支持，例如点对多点（P2MP）服务，但这些都有待进一步研究。
Private network services in the second category in Section 4.1 can be enhanced so that multiple private networks are supported across the layer 1 network as virtual private networks. These are Layer 1 Virtual Private Networks (L1VPNs). Note that the first category in Section 4.1 would include L1VPNs with only two CEs as a special case.
可以增强第4.1节第二类专用网络服务，以便跨第1层网络支持多个专用网络作为虚拟专用网络。这些是第1层虚拟专用网络（L1VPN）。请注意，作为特例，第4.1节中的第一类将包括只有两个CE的L1VPN。
Compared to the first category of service, the L1VPN service has features such as connectivity restriction, a separate policy, and distribution of membership information applied to a specific group.
与第一类服务相比，L1VPN服务具有诸如连接限制、单独策略和应用于特定组的成员资格信息分发等功能。
From the customer's perspective, there are two main benefits to a L1VPN. These benefits apply over and above the advantages of access to a dynamically provisioned network.
从客户的角度来看，L1VPN有两个主要好处。除了访问动态配置的网络的优势外，这些优势也同样适用。
- The customer can outsource the direct management of a layer 1 network by placing the VPN management in the control of a third party. This frees the customer from the need to configure and manage the connectivity information for the CEs that participate in the VPN.
- 客户可以通过将VPN管理置于第三方的控制下，将第1层网络的直接管理外包出去。这使客户无需为参与VPN的CE配置和管理连接信息。
- The customer can make small-scale use of a layer 1 network. So, for example, by sharing the layer 1 network infrastructure with many other users, the customer sites can be connected together across the layer 1 network without bearing the full cost of deploying and managing the layer 1 network.
- 客户可以小规模使用第1层网络。因此，例如，通过与许多其他用户共享第1层网络基础设施，客户站点可以跨第1层网络连接在一起，而无需承担部署和管理第1层网络的全部成本。
To some extent, the customer may also gain from the provider's benefits (see below). That is, if the provider is able to extract more value from the layer 1 network, the customer will benefit from lower priced services that are better tailored to the customer's needs.
在某种程度上，客户也可能从供应商的利益中获益（见下文）。也就是说，如果提供商能够从第1层网络中获取更多价值，客户将受益于更适合客户需求的低价服务。
The provider benefits from the customer's perception of benefits.
供应商从客户的利益感知中获益。
In particular, the provider can build on dynamic, on-demand services by offering new VPN services and off-loading the CE-to-CE configuration requirements from the customers.
特别是，提供商可以通过提供新的VPN服务和卸载客户的CE到CE配置要求，构建动态的按需服务。
Additionally, a more flexible VPN structure applied to the layer 1 network allows the provider to make more comprehensive use of the spare (that is, previously unused) resources within the network. This could be achieved by applying a network model where the provider is responsible for deciding how resources are used and for provisioning of the connection through the layer 1 network.
此外，应用于第1层网络的更灵活的VPN结构允许提供商更全面地利用网络内的备用（即以前未使用的）资源。这可以通过应用网络模型来实现，其中提供商负责决定资源的使用方式，并负责通过第1层网络提供连接。
In large carrier networks providing various kinds of service, it is often the case that multiple service networks are supported over a shared transport network. By applying L1VPNs, multiple internal service networks (which may be managed and operated separately) can be supported over a shared layer 1 transport network controlled and managed using GMPLS. In addition, L1VPNs can support capabilities to offer innovative services to external clients.
在提供各种服务的大型运营商网络中，通常在共享传输网络上支持多个服务网络。通过应用L1VPN，可以在使用GMPLS控制和管理的共享第1层传输网络上支持多个内部服务网络（可以单独管理和操作）。此外，L1VPN还可以支持向外部客户提供创新服务的功能。
Some more specific deployment scenarios are as follows.
下面是一些更具体的部署场景。
A multi-service backbone is characterized such that each service department of a carrier that receives the carrier's L1VPN service provides a different kind of higher-layer service. The customer receiving the L1VPN service (i.e., each service department) can offer its own services, whose payloads can be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and each service network belong to the same organization, but may be managed separately. From the L1VPN service provider's point of view, these services are not visible and are not part of the L1VPN service. That is, the type of service being carried within the layer 1 payload is not known by the service provider.
多业务骨干网的特征在于，接收运营商的L1VPN服务的运营商的每个服务部门提供不同种类的高层服务。接收L1VPN服务的客户（即每个服务部门）可以提供自己的服务，其有效负载可以是任何层（例如ATM、IP、TDM）。第1层传输网络和每个服务网络属于同一组织，但可以单独管理。从L1VPN服务提供商的角度来看，这些服务不可见，并且不是L1VPN服务的一部分。也就是说，服务提供商不知道在第1层有效载荷内承载的服务的类型。
The benefit is that the same layer 1 transport network resources are shared by multiple services. A large capacity backbone network (data plane) can be built economically by having the resources shared by multiple services usually with flexibility to modify topologies, while separating the control functions for each service department. Thus, each customer can select a specific set of features that are needed to provide their own service.
好处是相同的第1层传输网络资源由多个服务共享。通过让多个服务共享资源（通常具有修改拓扑的灵活性），同时分离每个服务部门的控制功能，可以经济地构建大容量主干网（数据平面）。因此，每个客户都可以选择提供自己的服务所需的一组特定功能。
Note that it is also possible to control and manage these service networks and the layer 1 transport network by using GMPLS in the integrated model [RFC3945] instead of using L1VPNs. However, using L1VPNs is beneficial in the following points:
注意，也可以通过在集成模型[RFC3945]中使用GMPLS而不是使用L1VPN来控制和管理这些服务网络和第1层传输网络。但是，使用L1VPN在以下几点上是有益的：
- Independent address space for each of the service networks.
- 每个服务网络的独立地址空间。
- Network isolation (topology information isolation, fault isolation among service networks).
- 网络隔离（拓扑信息隔离、服务网络间故障隔离）。
- Independent layer 1 resource view for each of the service networks.
- 每个服务网络的独立第1层资源视图。
- Independent policies that could be applied for each of the service networks.
- 可应用于每个服务网络的独立策略。
These points may apply to the management plane functionalities as well as to the control plane functionalities.
这些点可以应用于管理平面功能以及控制平面功能。
A carrier's carrier is characterized such that one carrier that receives another carrier's L1VPN service provides its own services. In this scenario, two carriers are in different organizations. It is, therefore, expected that the information provided at the service demarcation points is more limited than in the multi-service backbone case. Similarly, less control of the L1VPN service is given at the
运营商的运营商的特征在于，接收另一运营商的L1VPN服务的一家运营商提供其自己的服务。在这种情况下，两个运营商在不同的组织中。因此，预期在服务分界点处提供的信息比在多服务主干网情况下更为有限。类似地，L1VPN服务的控制也较少
service demarcation points. For example, customers of an L1VPN service receive:
服务分界点。例如，L1VPN服务的客户会收到：
- A more limited view of the L1VPN service provider network.
- L1VPN服务提供商网络的更有限视图。
- More limited control over the L1VPN service provider network.
- 对L1VPN服务提供商网络的控制更加有限。
One of the merits is that each carrier can concentrate on a specific service. For example, the customer of the L1VPN service may focus on L3 services, e.g., providing secure access to the Internet, leaving the L1VPN provider to focus on the layer 1 service, e.g., providing a long-haul bandwidth between cities. The L1VPN customer can construct its own network using layer 1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, while separating the control functions for each customer carrier.
优点之一是每个运营商可以专注于特定的服务。例如，L1VPN服务的客户可以专注于L3服务，例如，提供对互联网的安全访问，而L1VPN提供商则专注于第1层服务，例如，提供城市之间的长途带宽。L1VPN客户可以使用L1VPN提供商提供的第1层资源构建自己的网络，通常具有修改拓扑的灵活性，同时分离每个客户运营商的控制功能。
In addition to the scenarios where the second tier service provider is using a single core service provider as mentioned in Section 4.3.2, it is possible for the second tier provider to receive services from more than one core service provider. In this scenario, there are some benefits for the second tier service provider such as route redundancy and dynamic carrier selection based on the price.
除了第4.3.2节中提到的第二层服务提供商使用单一核心服务提供商的场景外，第二层服务提供商还可以从多个核心服务提供商处接收服务。在这种情况下，第二层服务提供商有一些好处，例如路由冗余和基于价格的动态载波选择。
The second tier service provider can support a function that enables a layer 1 resource trading service. Using resource information published by its core service providers, a second tier service provider can decide how to best use the core providers. For example, if one core service provider is no longer able to satisfy requests for service, an alternate service provider can be used. Or the second tier service provider could choose to respond to price changes of service over time.
第二层服务提供商可以支持启用第1层资源交易服务的功能。使用核心服务提供商发布的资源信息，第二层服务提供商可以决定如何最好地使用核心提供商。例如，如果一个核心服务提供商不再能够满足服务请求，则可以使用备用服务提供商。或者，第二层服务提供商可以选择响应服务价格随时间的变化。
Another example of second tier service provider use is to reduce exposure to failures in each provider (i.e., to improve availability).
第二层服务提供商使用的另一个例子是减少每个提供商的故障风险（即，提高可用性）。
In addition to the scenarios where a single connection between two CEs is routed over a single service provider as mentioned in Section 4.3.2, it is possible that a connection is routed over multiple ASes within a service provider (called inter-AS L1VPN) or over multiple service providers (called inter-SP L1VPN).
除了第4.3.2节中提到的两个CE之间的单个连接通过单个服务提供商路由的场景外，还可能通过服务提供商内的多个ASE（称为inter as L1VPN）或多个服务提供商（称为inter SP L1VPN）路由连接。
The inter-AS L1VPN scenario can be used to construct a single L1VPN from network resources administered by different domains of a single
inter-AS L1VPN场景可用于从单个域的不同域管理的网络资源构建单个L1VPN
service provider. These administrative domains might not usually have a collaborative relationship at layer 1, and so the inter-AS L1VPN offers a new business model for joint delivery of services to a customer. Consideration of inter-AS L1VPNs requires further analysis beyond the scope of this document.
服务提供商。这些管理域在第1层通常可能没有协作关系，因此inter AS L1VPN为联合向客户提供服务提供了一种新的业务模式。对AS间L1VPN的考虑需要进行超出本文件范围的进一步分析。
The inter-SP scenario can be used to construct a single L1VPN from services provided by multiple regional providers. There could be a variety of business relationships among providers and customers, and this scenario contains many more manageability, security, privacy, policy, and commercial issues than the more simple inter-AS L1VPN case. Consideration of inter-SP L1VPN requires further analysis beyond the scope of this document.
SP间场景可用于从多个区域提供商提供的服务构建单个L1VPN。提供商和客户之间可能存在各种业务关系，与更简单的inter-AS L1VPN案例相比，此场景包含更多的可管理性、安全性、隐私、策略和商业问题。考虑SP间L1VPN需要进行超出本文档范围的进一步分析。
In some deployment scenarios, customers of L1VPN services may wish to set up layer 1 connections not on-demand, but at a planned time in the future. Or, even though customers of L1VPN services may wish to use layer 1 connections on-demand, they can tolerate some delay, for example, due to lack of resources at that moment.
在某些部署场景中，L1VPN服务的客户可能希望不按需建立第1层连接，而是在将来的计划时间建立。或者，即使L1VPN服务的客户可能希望按需使用第1层连接，他们也可以容忍一些延迟，例如，由于当时缺乏资源。
In those scenarios, the provider can reserve bandwidth at a specified time in the future, and can establish the VPN connections according to a schedule. This makes it possible to use bandwidth more efficiently over time (i.e., support more demand). This service, the scheduling service, may be used to support customers who use layer 1 connections for data backup applications, content delivery applications, and some other applications.
在这些场景中，提供商可以在未来的指定时间保留带宽，并可以根据时间表建立VPN连接。这使得随着时间的推移能够更有效地使用带宽（即，支持更多需求）。此服务（调度服务）可用于支持将第1层连接用于数据备份应用程序、内容交付应用程序和某些其他应用程序的客户。
Furthermore, customers may be able to specify when to release layer 1 connections in advance. By considering this information, the provider may be able to further engineer scheduling, which leads to still more efficient bandwidth usage.
此外，客户可以提前指定何时释放第1层连接。通过考虑该信息，提供商可能能够进一步设计调度，从而导致更有效的带宽使用。
Note that scheduling of L1VPN services requires time-scoped resource management, which is not well considered in current GMPLS protocols and requires the support of the management plane. In addition, offering scheduling service and on-demand service on the same infrastructure needs careful consideration.
请注意，L1VPN服务的调度需要时间范围的资源管理，这在当前的GMPLS协议中没有得到很好的考虑，需要管理平面的支持。此外，在同一基础设施上提供调度服务和按需服务需要仔细考虑。
Figure 5.1 describes the L1VPN reference model.
图5.1描述了L1VPN参考模型。
: +--------------------+ :
: | +------------+ | :
: | | Management | | :
+------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device|
| : | | |=:=|VPN A| +------+
| : | | | : +------+
+------+ : | | PE | : +------+
+------+ | CE | : | |device| : | CE | +------+
| C | |device| : +------+ +------+ | | : |device| | C |
|device|--| of |=:=| |==| |==| |-:-| of |--|device|
+------+ |VPN A| : | | | | +------+ : |VPN B| +------+
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
+------+ | CE | : | | | | +------+ : | CE | +------+
| C |--|device|=:=| |==| |==| |-:-|device|--| C |
|device| | of | : +------+ +------+ | | : | of | |device|
+------+ |VPN B| : | | PE | : |VPN A| +------+
+------+ : | |device| : +------+
| : | | | : +------+
| : | | |=:=| CE | +------+
+------+ : | +------+ : |device| | C |
| C | : | | : | of |--|device|
|device| : | | : |VPN B| +------+
+------+ : | | : +------+
: | | :
Customer | | Customer
interface | | interface
+--------------------+
|<---- Provider ---->|
| network |
: +--------------------+ :
: | +------------+ | :
: | | Management | | :
+------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device|
| : | | |=:=|VPN A| +------+
| : | | | : +------+
+------+ : | | PE | : +------+
+------+ | CE | : | |device| : | CE | +------+
| C | |device| : +------+ +------+ | | : |device| | C |
|device|--| of |=:=| |==| |==| |-:-| of |--|device|
+------+ |VPN A| : | | | | +------+ : |VPN B| +------+
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
+------+ | CE | : | | | | +------+ : | CE | +------+
| C |--|device|=:=| |==| |==| |-:-|device|--| C |
|device| | of | : +------+ +------+ | | : | of | |device|
+------+ |VPN B| : | | PE | : |VPN A| +------+
+------+ : | |device| : +------+
| : | | | : +------+
| : | | |=:=| CE | +------+
+------+ : | +------+ : |device| | C |
| C | : | | : | of |--|device|
|device| : | | : |VPN B| +------+
+------+ : | | : +------+
: | | :
Customer | | Customer
interface | | interface
+--------------------+
|<---- Provider ---->|
| network |
Key: ==== Layer 1 Connection -- link
Key: ==== Layer 1 Connection -- link
Figure 5.1: L1VPN Reference Model
图5.1:L1VPN参考模型
In an L1VPN, layer 1 connections are provided between CEs' data plane interfaces within the same VPN. In Figure 5.1, a connection is provided between the left-hand CE of VPN A and the upper right-hand CE of VPN A, and another connection is provided between the left-hand CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). These layer 1 connections are called VPN connections.
在L1VPN中，在同一VPN内的CEs数据平面接口之间提供第1层连接。在图5.1中，VPN a的左侧CE和VPN a的右上方CE之间提供了一个连接，VPN B的左侧CE和VPN B的右下方CE之间提供了另一个连接（显示为“=”标记）。这些第1层连接称为VPN连接。
Note that as mentioned in Section 3.1, these VPN connections follow the hierarchy defined in [RFC4206].
请注意，如第3.1节所述，这些VPN连接遵循[RFC4206]中定义的层次结构。
As shown in the reference model, a provider network may contain one or more management systems. A management system may support functions including provisioning, monitoring, billing, and recording. Provider management systems may also communicate with customer management systems in order to provide services. Sections 7 and 11 provide more detail.
如参考模型所示，提供商网络可能包含一个或多个管理系统。管理系统可以支持包括供应、监控、计费和记录在内的功能。提供商管理系统还可以与客户管理系统通信以提供服务。第7节和第11节提供了更多细节。
This section describes generic L1VPN services. Detailed descriptions are provided through specific service models in Section 7.
本节介绍通用L1VPN服务。第7节通过特定服务模型提供了详细说明。
- The CE device may support more than one customer VPN.
- CE设备可以支持多个客户VPN。
- CE-PE data plane links (between data plane interfaces) may be shared by multiple VPNs.
- CE-PE数据平面链路（数据平面接口之间）可由多个VPN共享。
Note that it is necessary to disambiguate control plane messages exchanged between CE and PE if the CE-PE relationship is applicable to more than one VPN. This makes it possible to determine to which VPN such control plane messages apply. Such disambiguation might be achieved by allocating a separate control channel to each VPN (either using a separate physical channel, a separate logical channel such as IP tunnel, or using separate addressing).
注意，如果CE-PE关系适用于多个VPN，则有必要消除CE和PE之间交换的控制平面消息的歧义。这使得可以确定此类控制平面消息应用于哪个VPN。可以通过为每个VPN分配单独的控制通道（使用单独的物理通道、单独的逻辑通道（如IP隧道）或使用单独的寻址）来实现这种消除歧义。
A customer addressing realm consists of CE-PE TE link addresses and CE-PE control channel addresses as well as customer site addresses (C and CE addresses). Customer addressing realms may overlap, and may also overlap with the service provider addressing realm.
客户寻址域包括CE-PE TE链路地址、CE-PE控制通道地址以及客户站点地址（C和CE地址）。客户寻址域可能重叠，也可能与服务提供商寻址域重叠。
NATs or firewalls might reasonably be placed at customer interfaces, or between administrative domains within the core network. Addressing in the L1VPN model must handle such eventualities. Traversal of NATs and firewalls within the customer network might have implications for L1VPN services that connect C devices, and is for further study.
NAT或防火墙可以合理地放置在客户接口处，或核心网络内的管理域之间。L1VPN模型中的寻址必须处理此类事件。在客户网络中遍历NAT和防火墙可能会对连接C设备的L1VPN服务产生影响，有待进一步研究。
L1VPN has the following two generic service features.
L1VPN具有以下两个通用服务功能。
- Connectivity restriction: Layer 1 connectivity is provided to a limited set of CEs' data plane interfaces, called VPN end points. (This set forms the L1VPN membership.)
- 连接限制：第1层连接提供给一组有限的CEs数据平面接口，称为VPN端点。（此集合构成L1VPN成员身份。）
- Per VPN control and management: Some level of control and management capability is provided to the customer. Details differ depending on service models described in Section 7.
- 每VPN控制和管理：向客户提供一定级别的控制和管理能力。详细信息因第7节中所述的服务模式而异。
This section describes Layer 1 VPN service models that can be supported by GMPLS protocols enabled networks. These models are derived from the generic service description presented above.
本节介绍启用GMPLS协议的网络可以支持的第1层VPN服务模型。这些模型来源于上述通用服务描述。
Such layer 1 networks are managed and controlled using GMPLS signaling as described in [RFC3471] and [RFC3473], and GMPLS routing as described in [RFC4202]. It must be understood that meeting the requirements set out in this document may necessitate extensions to the existing GMPLS protocols both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). A CE and a PE are connected by one or more data links. The ends of each link are usually represented as GMPLS-capable interfaces.
使用[RFC3471]和[RFC3473]中所述的GMPLS信令以及[RFC4202]中所述的GMPLS路由来管理和控制此类第1层网络。必须理解，满足本文件中规定的要求可能需要对现有GMPLS协议进行扩展，既适用于第1层网络内的控制平面，也适用于网络边缘的服务供应（CE和PE设备）。CE和PE通过一个或多个数据链路连接。每个链路的端部通常表示为支持GMPLS的接口。
Note that in this document, service models are classified by the semantics of information exchanged over the customer interface. The customer interface may be instantiated by the CE-PE control plane communication and/or the management plane communication between the customer management systems(s) and the provider management system(s). Note that how to realize a CE-PE control channel is discussed in Section 10.1. Customer management system(s) and provider management systems(s) may communicate by utilizing the CE-PE control channel(s).
请注意，在本文档中，服务模型根据通过客户接口交换的信息的语义进行分类。客户接口可以通过客户管理系统和提供商管理系统之间的CE-PE控制平面通信和/或管理平面通信来实例化。注意，第10.1节讨论了如何实现CE-PE控制信道。客户管理系统和提供商管理系统可通过利用CE-PE控制信道进行通信。
Figure 7.1 describes the Management-based service model.
图7.1描述了基于管理的服务模型。
+--------------------+
: | |
+----------+ : | +----------+ |
| Customer | : | | Provider | |
|Management| : | |Management| |
| system(s)|-:-----+----| system(s)| |
+----------+ : | +----------+ |
: | | :
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |----:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+
: | |
+----------+ : | +----------+ |
| Customer | : | | Provider | |
|Management| : | |Management| |
| system(s)|-:-----+----| system(s)| |
+----------+ : | +----------+ |
: | | :
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |----:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.1: Management-Based Service Model
图7.1：基于管理的服务模型
In this service model, customer management systems and provider management systems communicate with each other. Customer management systems access provider management systems to request layer 1 connection setup/deletion between a pair of CEs. Customer management systems may obtain additional information, such as resource availability information and monitoring information, from provider management systems. There is no control message exchange between a CE and PE.
在此模型中，每个客户管理系统和服务提供商都可以相互通信。客户管理系统访问提供商管理系统，请求在一对CE之间建立/删除第1层连接。客户管理系统可以从提供商管理系统获取额外信息，例如资源可用性信息和监控信息。CE和PE之间没有控制消息交换。
The provider network may be based on GMPLS. In this case, mechanisms to support soft permanent connections can be applied. However, interfaces between management systems are not within the scope of this document.
提供商网络可以基于GMPLS。在这种情况下，可以应用支持软永久连接的机制。但是，管理系统之间的接口不在本文件的范围内。
In this service model, the CE-PE interface's functional repertoire is limited to path setup signaling only. The provider's network is not involved in distribution of customer network's routing information.
在此服务模型中，CE-PE接口的功能仅限于路径设置信令。提供商的网络不参与客户网络路由信息的分发。
Note in addition that there may be communication between customer management system(s) and provider management system(s) in order to provide customers with detailed monitoring, fault information, etc.
此外，请注意，客户管理系统和供应商管理系统之间可能存在通信，以便向客户提供详细的监控、故障信息等。
Figure 7.2 describes the Overlay service model.
图7.2描述了覆盖服务模型。
+--------------------+
: | | :
: | | :
+----+ : +----+ +----+ : +----+
| CE |---:---| PE | | PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+
: | | :
: | | :
+----+ : +----+ +----+ : +----+
| CE |---:---| PE | | PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.2: Overlay Service Model
图7.2：覆盖服务模型
In this service model, the customer interface is based on the GMPLS UNI Overlay [RFC4208]. The CE requests layer 1 connection setup/deletion to a remote CE. There is no routing protocol running (i.e., no routing neighbor/peering relationship) between a CE and a PE. The CE does not receive routing information from remote customer sites, nor routing information about the provider network.
在此服务模型中，客户接口基于GMPLS UNI覆盖[RFC4208]。CE向远程CE请求第1层连接设置/删除。CE和PE之间没有正在运行的路由协议（即，没有路由邻居/对等关系）。CE不接收来自远程客户站点的路由信息，也不接收有关提供商网络的路由信息。
The CE's interface may be assigned a public or private address, that designates VPN end points.
CE的接口可以分配一个公共或私有地址，用于指定VPN端点。
In this model, membership information needs to be configured on PEs, so that the PE that receives a Path message from the ingress CE can identify the remote PE connected to the egress CE. Distribution of membership information between PEs is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (auto-discovery).
在此模型中，需要在PE上配置成员信息，以便从入口CE接收路径消息的PE能够识别连接到出口CE的远程PE。PEs之间的成员信息分发通常由提供商完成，可以通过静态资源调配等机制或通过路由协议（自动发现）实现。
There are various ways that customers perceive the provider network. In one example, the whole provider network may be considered as one node -- the path specified and recorded in signaling messages reflects this. Note that this is distinct from the Virtual Node service model described in Section 7.3.2 because such a model requires that the network is represented to the VPN sites as a virtual node -- that is, some form of routing advertisement is
客户感知供应商网络的方式多种多样。在一个示例中，可以将整个提供商网络视为一个节点——信令消息中指定和记录的路径反映了这一点。请注意，这与第7.3.2节中描述的虚拟节点服务模型不同，因为这种模型要求将网络作为虚拟节点表示给VPN站点——也就是说，需要某种形式的路由公告
implied, and this is not in scope for the Signaling-based service model.
暗示，这不在基于信令的服务模型的范围内。
In this service model, the CE-PE interface provides the signaling capabilities as in the Basic Mode, plus permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of customer network routing information (i.e., reachability or TE information in remote customer sites), or parameters of the part of the provider's network dedicated to the customer.
在此服务模型中，CE-PE接口提供基本模式下的信令能力，并允许提供商和客户的控制平面之间有限的信息交换，以帮助发现客户网络路由信息（即远程客户站点中的可达性或TE信息）等功能，或供应商网络中专门用于客户的部分的参数。
By allowing CEs to obtain customer network routing information, a so-called N-square routing problem could be solved.
通过允许CEs获得客户网络路由信息，可以解决所谓的N平方路由问题。
In addition, by using the received traffic engineering-based routing information, a customer can use traffic engineering capabilities. For example, a customer can set up two disjoint connections between a pair of CEs. Another example is that a customer can request a connection between a pair of devices within customer sites, and not necessarily between CEs, with more effective traffic engineering.
此外，通过使用接收到的基于流量工程的路由信息，客户可以使用流量工程功能。例如，客户可以在一对CE之间建立两个不相交的连接。另一个例子是，客户可以通过更有效的流量工程在客户站点内的一对设备之间请求连接，而不必在CEs之间请求连接。
As such, the customer interface is based on GMPLS signaling and mechanisms to exchange reachability/TE information. Typically, a routing protocol is used between a CE and PE, or more precisely between a CE and the VPN routing context instantiated on the PE. Link state routing information would be needed to implement the above two example scenarios. Some scenarios may be satisfied with reachability routing information only.
因此，客户接口基于GMPLS信令和机制来交换可达性/TE信息。通常，在CE和PE之间使用路由协议，或者更准确地说，在CE和PE上实例化的VPN路由上下文之间使用路由协议。实现上述两个示例场景需要链路状态路由信息。某些场景可能仅满足可达性路由信息。
Note that this service model does not preclude the use of mechanisms other than routing protocols to exchange reachability/TE information.
请注意，此服务模型并不排除使用路由协议以外的机制来交换可达性/TE信息。
As with the Signaling-based service model, there may be communication between customer management system(s) and provider management system(s) in order to provide detailed monitoring, fault information etc. to customers.
与基于信令的服务模型一样，客户管理系统和提供商管理系统之间可能存在通信，以便向客户提供详细的监控、故障信息等。
Four specific types of the Signaling and Routing service model are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model and the Per-VPN Peer service model, depending on how customers perceive the provider network in routing and signaling (i.e., the level of information details that a customer is allowed to receive in routing and signaling).
信令和路由服务模型的四种特定类型是覆盖扩展服务模型、虚拟节点服务模型、虚拟链路服务模型和每VPN对等服务模型，具体取决于客户在路由和信令中对提供商网络的感知（即，允许客户在路由和信令中接收的信息详细程度）。
This service model complements the Overlay service model. In this service model, a CE receives a list of CE-PE TE link addresses to which it can request a VPN connection (i.e., membership information). This may include additional information concerning these TE links (e.g., switching type). Mechanisms other than routing could be used to exchange reachability/TE information between the CE and the PE.
此服务模型是对覆盖服务模型的补充。在此服务模型中，CE接收CE-PE TE链路地址列表，可向其请求VPN连接（即，成员信息）。这可能包括关于这些TE链路的附加信息（例如，切换类型）。除路由之外的机制可用于在CE和PE之间交换可达性/TE信息。
Figure 7.3 describes the Virtual Node service model.
图7.3描述了虚拟节点服务模型。
+--------------------+
: | | :
+----+ : | | : +----+
| CE |---:---| Virtual Node |---:---| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+
: | | :
+----+ : | | : +----+
| CE |---:---| Virtual Node |---:---| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.3: Virtual Node Service Model
图7.3：虚拟节点服务模型
In this type of service model, the whole provider network is represented as a virtual node (defined in Section 2). The customer perceives the provider network as one single node. The CE receives routing information about CE-PE links and the customer network (i.e., remote customer sites).
在这种类型的服务模型中，整个提供商网络被表示为一个虚拟节点（定义见第2节）。客户将提供商网络视为一个节点。CE接收有关CE-PE链路和客户网络（即远程客户站点）的路由信息。
Note that in this service model, there must be one single virtual node, and this virtual node must be connected with every CE in the VPN.
请注意，在此服务模型中，必须有一个虚拟节点，并且此虚拟节点必须与VPN中的每个CE连接。
Figure 7.4 describes the Virtual Link service model.
图7.4描述了虚拟链路服务模型。
+--------------------+
: | | :
: | Virtual | :
+----+ : +----+ link +----+ : +----+
| CE |---:---| PE |**************| PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+
: | | :
: | Virtual | :
+----+ : +----+ link +----+ : +----+
| CE |---:---| PE |**************| PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.4: Virtual Link Service Model
图7.4：虚拟链路服务模型
In this service model, a virtual link is constructed between PEs. For the definition of a virtual link, please refer to terminology in Section 2. A virtual link is assigned to each VPN and disclosed to the corresponding CEs. As such, the CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as virtual links assigned to each VPN. A special property of the virtual links used in this service model is that the provider network allocates data plane link resources for the exclusive use of each virtual link. The TE attributes of a virtual link are determined according to data plane link resources allocated to this virtual link. Virtual links are an abstraction of the provider network to customers for administrative purposes as well as to exclude "unnecessary information".
在该服务模型中，PEs之间构建了虚拟链路。有关虚拟链接的定义，请参阅第2节中的术语。将虚拟链路分配给每个VPN并公开给相应的ce。因此，CE接收关于CE-PE链路、客户网络（即，远程客户站点）以及分配给每个VPN的虚拟链路的路由信息。此服务模型中使用的虚拟链路的一个特殊属性是，提供商网络为每个虚拟链路的独占使用分配数据平面链路资源。根据分配给该虚拟链路的数据平面链路资源确定虚拟链路的TE属性。虚拟链接是为了管理目的以及排除“不必要的信息”而向客户提供的提供商网络的抽象。
Note that in this service model, both end points of each virtual link must be a PE device.
请注意，在此服务模型中，每个虚拟链路的两个端点都必须是PE设备。
Figure 7.5 describes the Per-VPN Peer service model.
图7.5描述了每VPN对等服务模型。
+--------------------+
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |---:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |---:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.5: Per-VPN Peer Service Model
图7.5：每个VPN对等服务模型
This service model is a generalization and combination of the Virtual Link service model and the Virtual Node service model mentioned in Sections 7.3.2 and 7.3.3 respectively.
该服务模型是第7.3.2节和第7.3.3节分别提到的虚拟链路服务模型和虚拟节点服务模型的推广和组合。
In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per-VPN TE link information to corresponding CEs. As such, a CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as partitioned portions of the provider network.
在该服务模型中，提供商将提供商网络内的TE链路按VPN进行划分，并将按VPN的TE链路信息披露给相应的CE。这样，CE接收关于CE-PE链路、客户网络（即，远程客户站点）以及提供商网络的分区部分的路由信息。
Note that PEs may advertise abstracted routing information about the provider network to CEs for administrative purpose as well as to exclude "unnecessary information". In other words, virtual links may be constructed between two nodes where direct data links do not exist, or virtual nodes may be constructed to represent multiple physical nodes and links between them.
注意，PEs可能出于管理目的向CEs公布关于提供商网络的抽象路由信息，并排除“不必要的信息”。换句话说，可以在不存在直接数据链路的两个节点之间构造虚拟链路，或者可以构造虚拟节点来表示多个物理节点及其之间的链路。
In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P or a set of Ps) must be visible to customers.
在每VPN对等服务模型中，至少一个对应于P设备（一个P或一组P）的虚拟节点必须对客户可见。
The service models mentioned in Section 7 are related to what information is exchanged between CE and PE. In addition, service models differ in how data plane resources are allocated for each VPN.
第7节中提到的服务模型与CE和PE之间交换的信息有关。此外，服务模型在如何为每个VPN分配数据平面资源方面有所不同。
Note that in the ITU-T documents, the term "U-Plane" is used instead of "data plane".
请注意，在ITU-T文件中，使用术语“U平面”代替“数据平面”。
o Data plane resource allocation
o 数据平面资源分配
- Shared or dedicated:
- 共享或专用：
Shared means that provider network data plane links are shared by multiple (i.e., any or a specific set of) VPNs. (Data plane links are dynamically allocated to a VPN when a VPN connection is requested, and data plane links allocated to one VPN at one time can be allocated to another VPN at another time.)
共享是指提供商网络数据平面链接由多个（即任何或特定的一组）VPN共享。（当请求VPN连接时，数据平面链接将动态分配给VPN，并且一次分配给一个VPN的数据平面链接可以在另一次分配给另一个VPN。）
Dedicated means that provider network data plane links are partitioned per VPN. (Data plane links are statically allocated to one VPN and can not be used by other VPNs.)
专用意味着提供商网络数据平面链接按照VPN进行分区。（数据平面链路静态分配给一个VPN，其他VPN不能使用。）
o Information exchanged between CE and PE
o 行政长官与行政长官交换资料
- Signaling
- 信号
- Membership information (optionally includes TE information of the associated CE-PE TE links)
- 成员信息（可选包括关联CE-PE TE链接的TE信息）
- Customer network routing information (reachability only, or may include TE information)
- 客户网络路由信息（仅可达性，或可能包括TE信息）
- Provider network routing information (TE information)
- 提供商网络路由信息（TE信息）
Note that link management information (e.g., LMP [RFC4204]) may be exchanged between a CE and a PE, but this is orthogonal to the definition of the service models.
注意，链路管理信息（例如，LMP[RFC4204]）可以在CE和PE之间交换，但是这与服务模型的定义正交。
Table 1 shows combination of service requirements and service models.
表1显示了服务需求和服务模型的组合。
| Data plane | Data plane
| shared | dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay | Overlay
Membership information | Extension | Extension
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual Node | Virtual Node
Customer network routing | |
information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | | Virtual Link
Customer network routing | Not applicable |
information + | | Per-VPN Peer
Provider network routing | |
information | |
| Data plane | Data plane
| shared | dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay | Overlay
Membership information | Extension | Extension
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual Node | Virtual Node
Customer network routing | |
information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | | Virtual Link
Customer network routing | Not applicable |
information + | | Per-VPN Peer
Provider network routing | |
information | |
Table 1: Combination of service requirements and service models
表1：服务需求和服务模型的组合
As described in previous sections, the difference between the Virtual Link service model and the Per-VPN Peer service model is whether customers have visibility of P devices. In the Virtual Link service model, the end points of virtual links must be PE devices, thus P devices are not visible to customers. In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P, or a set of Ps) is visible to customers.
如前几节所述，虚拟链路服务模型和每VPN对等服务模型之间的区别在于客户是否可以看到P设备。在虚拟链路服务模型中，虚拟链路的端点必须是PE设备，因此P设备对客户不可见。在每VPN对等服务模型中，客户至少可以看到与P设备（一个P或一组P）对应的一个虚拟节点。
Note that when customers receive provider network routing information in the form of virtual link, customers must be able to specify such links for a VPN connection over the provider network in signaling.
请注意，当客户收到虚拟链路形式的提供商网络路由信息时，客户必须能够在信令中为提供商网络上的VPN连接指定此类链路。
In addition to the requirements set out in table 1, more detailed service requirements are provided below. They are generally common to the various service models, except where indicated.
除表1所列要求外，下文还提供了更详细的服务要求。除另有说明外，它们通常适用于各种服务模型。
- Selection of layer 1 service class: Customers MAY be allowed to specify a layer 1 service class (e.g., availability level) for a VPN connection. Further details are described in Section 9.
- 选择第1层服务类别：可能允许客户为VPN连接指定第1层服务类别（例如，可用性级别）。第9节描述了进一步的细节。
- Reception of performance information: Customers MAY be allowed to receive performance information for their VPN connections (e.g., performance monitoring data). When data plane links are dedicated, customers MAY be allowed to receive performance information for links dedicated to them.
- 接收性能信息：可能允许客户接收其VPN连接的性能信息（例如，性能监控数据）。当数据平面链接专用时，可能允许客户接收专用链接的性能信息。
- Reception of fault information: Customers MAY be allowed to receive fault information for their VPN connections (e.g., failure notification by RSVP-TE, data plane alarm notification through the management plane, notification of connection setup rejection causes). Note that this does not prevent customers from using Operations and Management (OAM) mechanisms for, or on, their VPN connections. When data plane links are dedicated, customers MAY be allowed to receive fault information for links dedicated to them.
- 接收故障信息：可能允许客户接收其VPN连接的故障信息（例如，RSVP-TE的故障通知、通过管理平面的数据平面报警通知、连接设置拒绝原因通知）。请注意，这并不会阻止客户使用操作和管理（OAM）机制进行VPN连接。当数据平面链路专用时，可能允许客户接收专用链路的故障信息。
- Reception of connection information: Customers MAY be allowed to receive information for current VPN connections (through the management plane).
- 接收连接信息：允许客户接收当前VPN连接的信息（通过管理平面）。
- Reception of accounting information: Customers MUST be able to receive accounting information for each VPN.
- 接收会计信息：客户必须能够接收每个VPN的会计信息。
- Specification of policy: Customers MAY be allowed to specify policies (e.g., path computation policies, recovery policies including parameters) for each VPN.
- 策略规范：可以允许客户为每个VPN指定策略（例如，路径计算策略、包括参数的恢复策略）。
- Security: The communication between the customer and the provider MUST be secure. Further details are described in Section 12.
- 安全性：客户和提供商之间的通信必须是安全的。第12节描述了进一步的细节。
- Filtering: Unnecessary information (e.g., information concerning other VPNs) MUST NOT be provided to each customer. This applies particularly to the Signaling and Routing service model, but is also relevant to the Signaling-based service model and to the Management-based service model. Further details are described in Section 12.
- 过滤：不得向每个客户提供不必要的信息（例如，有关其他VPN的信息）。这尤其适用于信令和路由服务模型，但也与基于信令的服务模型和基于管理的服务模型相关。第12节描述了进一步的细节。
GMPLS provides various recovery techniques for use in different recovery scenarios [RFC4427]. The provider network may apply these recovery techniques to protect VPN connections as part of the L1VPN service, for example as follows:
GMPLS提供了各种恢复技术，可用于不同的恢复场景[RFC4427]。提供商网络可以应用这些恢复技术来保护作为L1VPN服务一部分的VPN连接，例如如下所示：
o PE-PE recovery
o PE-PE回收
The provider network constitutes a recovery domain, and the recovery scope is the PE-PE part of the CE-CE VPN connection.
提供商网络构成恢复域，恢复范围是CE-CE VPN连接的PE-PE部分。
It should be possible for the provider network to hide the provider network recovery operation from the customer. Namely, it should be possible to configure the provider network to not notify the customer when a failure occurs and a PE-PE recovery operation successfully repairs the failure. Further, when PE-PE recovery fails and the failure should be notified to the customer, it should be possible for the provider network to hide its internal topology.
提供商网络应该可以对客户隐藏提供商网络恢复操作。也就是说，应该可以将提供商网络配置为在发生故障时不通知客户，并且PE-PE恢复操作成功修复故障。此外，当PE-PE恢复失败且故障应通知客户时，提供商网络应能够隐藏其内部拓扑。
o CE-PE recovery
o CE-PE回收
The recovery scope is either or both of the ingress and egress CE-PE links of the CE-CE VPN connection.
恢复范围是CE-CE VPN连接的入口和出口CE-PE链路之一或两者。
o CE-CE recovery
o 铈铈回收
The recovery scope is the entire CE-CE VPN connection.
恢复范围是整个CE-CE VPN连接。
When a failure needs to be notified to a customer so that the customer can initiate recovery operation, it should be possible for the provider network to hide its internal topology.
当故障需要通知客户以便客户可以启动恢复操作时，提供商网络应该可以隐藏其内部拓扑。
These recovery schemes may be applied in combination.
这些回收方案可结合使用。
Customers may be allowed to specify the desired recovery level in a connection setup request. Furthermore, the customer may be allowed to specify the desired recovery level in a way that is agnostic of the recovery technique (e.g., when the recovery operation does not require cooperation between the provider network and the customer network). In such cases, the provider network must translate the specified recovery level into specific recovery techniques, based on operational policies. This allows enhanced recovery techniques above and beyond the GMPLS specifications to be used in the provider network.
可能允许客户在连接设置请求中指定所需的恢复级别。此外，可以允许客户以与恢复技术无关的方式指定期望的恢复级别（例如，当恢复操作不需要提供商网络和客户网络之间的合作时）。在这种情况下，提供商网络必须根据操作策略将指定的恢复级别转换为特定的恢复技术。这允许在提供商网络中使用超出GMPLS规范的增强恢复技术。
The provider network may support various recovery resource sharing schemes, such as the following:
提供商网络可以支持各种恢复资源共享方案，例如：
o Shared recovery
o 共享恢复
When the provider network supports shared recovery (e.g., shared mesh restoration [RFC4427]), the provider network may provide
当提供商网络支持共享恢复（例如，共享网格恢复[RFC4427]）时，提供商网络可以提供
sharing recovery resources between VPN connections that serve with only the same VPN, a specific set of VPNs, or any VPN. The default mode is sharing recovery resources with any VPN.
在仅使用相同VPN、特定VPN集或任何VPN的VPN连接之间共享恢复资源。默认模式是与任何VPN共享恢复资源。
o Extra traffic
o 额外流量
GMPLS recovery mechanisms support extra traffic. Extra traffic allows the transfer of preemptable traffic on the recovery resources when these resources are not being used for the recovery of protected normal traffic [RFC4427].
GMPLS恢复机制支持额外的流量。当恢复资源不用于恢复受保护的正常流量时，额外流量允许在恢复资源上传输可抢占流量[RFC4427]。
In the context of L1VPNs, extra traffic is applied for CE-CE VPN connections, or PE-PE part of CE-CE VPN connections. The latter case may be applied only when there is hierarchy (i.e., CE-CE VPN connection is nested on top of PE-PE connection). In this section, the latter aspect is analyzed.
在L1VPN的上下文中，额外的流量应用于CE-CE VPN连接或CE-CE VPN连接的PE-PE部分。后一种情况仅在存在层次结构时适用（即CE-CE VPN连接嵌套在PE-PE连接之上）。本节对后一个方面进行了分析。
When the provider network allows a CE-CE VPN connection to be set up as "extra traffic", it means that the VPN connection may use a PE-PE connection that protects some other CE-CE VPN connection. In such a case the provider network may restrict extra traffic CE-CE VPN connection to use resources (i.e., the PE-PE connections) that:
当提供商网络允许将CE-CE VPN连接设置为“额外流量”时，这意味着VPN连接可以使用保护其他CE-CE VPN连接的PE-PE连接。在这种情况下，提供商网络可限制额外流量CE-CE VPN连接以使用以下资源（即PE-PE连接）：
- protect VPN connections from the same VPN as the extra traffic connection.
- 从与额外流量连接相同的VPN保护VPN连接。
- are used for a specific set of VPNs.
- 用于一组特定的VPN。
- are available for any VPN.
- 可用于任何VPN。
The default mode is to support preemptable traffic on recovery resources reserved for any VPN.
默认模式是在为任何VPN保留的恢复资源上支持可抢占流量。
In the Signaling-based service model and the Signaling and Routing service model, there must be a control channel (IP-level connectivity) between a CE and its PE. The instantiation of the control channel may differ depending on addressing and security.
在基于信令的服务模型和信令和路由服务模型中，CE与其PE之间必须有一个控制信道（IP级连接）。根据寻址和安全性，控制通道的实例化可能有所不同。
As stated in Section 6.1, it is necessary to disambiguate control plane messages exchanged between the CE and PE if the CE-PE relationship is applicable to more than one VPN. Furthermore, private addresses may be assigned to CE-PE control channels.
如第6.1节所述，如果CE-PE关系适用于多个VPN，则有必要消除CE和PE之间交换的控制平面消息的歧义。此外，可以将专用地址分配给CE-PE控制信道。
Security aspects of the CE-PE control channel are discussed in Section 12.
CE-PE控制信道的安全方面在第12节中讨论。
A customer network connected by VPN connections may be controlled by MPLS or GMPLS, and the VPN connections may be treated as TE links within the customer network. In such cases, there must be control plane (IP-level) connectivity between the CEs, so that control messages, such as signaling and routing messages, can be exchanged between the CEs. Furthermore, in some recovery techniques, Notify message exchange is needed between the ingress and egress of the VPN connection, which requires control plane connectivity between the CEs. There are several potential ways to achieve this.
通过VPN连接连接的客户网络可由MPLS或GMPLS控制，并且VPN连接可被视为客户网络内的TE链路。在这种情况下，CEs之间必须有控制平面（IP级）连接，以便控制消息（例如信令和路由消息）可以在CEs之间交换。此外，在一些恢复技术中，VPN连接的入口和出口之间需要进行通知消息交换，这需要ce之间的控制平面连接。有几种可能的方法来实现这一点。
o Use of VPN connections as in-band control channels
o 将VPN连接用作带内控制通道
If the CEs have the ability to inject control messages into the VPN connections and to extract the messages at the far end of the VPN connections, then control messages can be exchanged in-band. For example, when a VPN connection is a Packet Switch Capable (PSC) TE link in the customer network, this operation is transparent to the L1VPN service provider.
如果CEs能够将控制消息注入VPN连接并在VPN连接的远端提取消息，则控制消息可以在频带内交换。例如，当VPN连接是客户网络中支持分组交换（PSC）的TE链路时，此操作对L1VPN服务提供商是透明的。
o Use of overhead associated with the VPN connections
o 使用与VPN连接相关的开销
If the VPN connection provides connectivity in the customer network at a different switching capability (implying network technology layer) from that used by the provider network to support the CE-PE and PE-PE connectivity, then the customer network can utilize any overhead available within the VPN connection as a control channel to connect the CEs. For example, if a VPN connection provides a TDM TE link in the customer network but is supported by a technology such as lambda or fiber, then the CEs may utilize the overhead (DCC) as a control channel, if the network supports transparent transfer of such overhead. This operation is transparent to the L1VPN service provider.
如果VPN连接在客户网络中以不同于提供商网络用于支持CE-PE和PE-PE连接的交换能力（意味着网络技术层）提供连接，然后，客户网络可以利用VPN连接中可用的任何开销作为连接CEs的控制信道。例如，如果VPN连接在客户网络中提供TDM-TE链路，但是由诸如lambda或光纤之类的技术支持，那么如果网络支持这种开销的透明传输，则CEs可以利用开销（DCC）作为控制信道。此操作对L1VPN服务提供商是透明的。
o Use of control-channel-specific VPN connections
o 使用特定于控制通道的VPN连接
A customer establishes VPN connections dedicated as control channels. This operation is transparent to the L1VPN service provider, but since control plane traffic is likely to be relatively low compared with the capacity of VPN connections, this may be an expensive solution for the customer.
客户建立专用于控制通道的VPN连接。此操作对L1VPN服务提供商是透明的，但由于与VPN连接的容量相比，控制平面流量可能相对较低，因此对于客户来说，这可能是一个昂贵的解决方案。
o Use of separate network
o 使用独立网络
A customer may utilize another network and network service, such as private line service, L3VPN service, L2VPN service, or Internet access service, to establish CE-CE control channel connectivity. This operation is transparent to the L1VPN service provider.
客户可利用另一网络和网络服务，例如专线服务、L3VPN服务、L2VPN服务或互联网接入服务，来建立CE-CE控制信道连接。此操作对L1VPN服务提供商是透明的。
o Use of CE-PE control channels
o CE-PE控制通道的使用
In the Signaling-based service model, and the Signaling and Routing service model, there must be control plane (IP-level) connectivity between the CE and PE, as described in Section 10.1.
在基于信令的服务模型以及信令和路由服务模型中，CE和PE之间必须有控制平面（IP级）连接，如第10.1节所述。
By utilizing this, CE-CE control message exchange could be realized as part of the service provided by the L1VPN service provider. Namely, the provider network transfers control messages received over the CE-PE control channel to the other side of the provider network and delivers them through the PE-CE control channel. The realization of this within the provider network is up to the operator, but where the provider network uses a GMPLS control plane, the customer control plane messages could be forwarded through the provider control plane, perhaps using IP tunnels.
通过利用这一点，CE-CE控制消息交换可以作为L1VPN服务提供商提供的服务的一部分来实现。即，提供商网络将通过CE-PE控制信道接收的控制消息传输到提供商网络的另一端，并通过PE-CE控制信道传递它们。在提供商网络内实现这一点取决于运营商，但如果提供商网络使用GMPLS控制平面，则可以通过提供商控制平面转发客户控制平面消息，可能使用IP隧道。
Care must be taken to protect the provider network and other customers from Denial of Service (DoS) attack. Traffic saturation over the control plane network needs to be carefully managed as well. Note that if private addresses are assigned to the CE-PE control channels, the provider network must support VPN-scoped routing and forwarding for control messages.
必须注意保护提供商网络和其他客户免受拒绝服务（DoS）攻击。控制平面网络上的流量饱和也需要仔细管理。请注意，如果将专用地址分配给CE-PE控制通道，则提供商网络必须支持控制消息的VPN范围路由和转发。
Manageability considerations for GMPLS are described in existing documents, such as [RFC3945]. Also, manageability considerations for L3VPN are described in existing documents, such as [RFC4176]. These manageability considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific manageability considerations for L1VPNs, such as configuration and accounting.
现有文件（如[RFC3945]）中描述了GMPLS的可管理性注意事项。此外，L3VPN的可管理性注意事项在现有文档中进行了描述，如[RFC4176]。这些可管理性注意事项也应应用于L1VPN，本节将介绍这些方面。此外，L1VPN还有一些特定的可管理性注意事项，如配置和记帐。
o Fault management
o 故障管理
The provider network MUST support fault management. It MUST support liveness detection, and monitoring and verification of correct operation.
提供商网络必须支持故障管理。它必须支持活性检测，以及对正确操作的监控和验证。
When a failure occurs, the provider network SHOULD correlate the failure. Also, it SHOULD be able to detect which customer is affected by the failure.
发生故障时，提供商网络应将故障关联起来。此外，它应该能够检测出哪个客户受到故障的影响。
If the provider network can resolve failures without intervention from the customer network, it MUST be possible to configure the provider network to not report failures to the customers. However, it MAY be part of an agreement between a customer and provider that failures are reported to the customer, regardless.
如果提供商网络能够在没有客户网络干预的情况下解决故障，则必须能够将提供商网络配置为不向客户报告故障。但是，客户和供应商之间的协议可能包括向客户报告故障，无论是什么。
o Configuration management
o 配置管理
The provider network MUST support configuration management, such as the following.
提供商网络必须支持以下配置管理。
- Service mode/model configuration.
- 服务模式/型号配置。
- Network representation configuration: Configuration of virtual node and virtual link.
- 网络表示配置：虚拟节点和虚拟链路的配置。
- Resource allocation configuration: Dedicated, shared. See Section 8 for more detail.
- 资源分配配置：专用、共享。详见第8节。
- Recovery policy configuration: For example, recovery resource sharing schemes, such as shared recovery, extra traffic. See Section 9 for more detail.
- 恢复策略配置：例如，恢复资源共享方案，如共享恢复、额外流量。详见第9节。
- Membership configuration.
- 成员资格配置。
- Network/Element level configuration: For example, TE link configuration.
- 网络/元件级配置：例如，TE链路配置。
It SHOULD be possible for the provider network to verify that configuration is correctly made.
提供商网络应该可以验证配置是否正确。
o Accounting management
o 会计管理
The provider network MUST support accounting management. It MUST be able to record usage of VPN connections for each customer.
提供商网络必须支持记帐管理。它必须能够记录每个客户的VPN连接使用情况。
o Performance management
o 绩效管理
The provider network MUST support performance management.
提供商网络必须支持性能管理。
In particular, it MUST support performance monitoring of parameters associated with the Service Level Agreement (SLA), such as bit error rate per VPN connection, and SLA verification.
特别是，它必须支持与服务级别协议（SLA）相关的参数的性能监控，例如每个VPN连接的误码率和SLA验证。
In addition, it MUST support performance monitoring and analysis of parameters related to the network and equipment not directly associated with the SLA, such as network resource utilization.
此外，它还必须支持与网络和与SLA不直接相关的设备相关的参数的性能监视和分析，如网络资源利用率。
o Security management
o 安全管理
The provider network MUST support security management. See Section 12 for details.
提供商网络必须支持安全管理。详情见第12节。
o Management systems
o 管理系统
In order to support various management functionalities, the provider network relies on management systems and related tools. GMPLS protocols and potential extensions of GMPLS MUST be able to work with management systems and related tools to provide such functionalities.
为了支持各种管理功能，提供商网络依赖于管理系统和相关工具。GMPLS协议和GMPLS的潜在扩展必须能够与管理系统和相关工具配合使用，以提供此类功能。
In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported.
特别是，必须支持用于GMPLS协议和潜在扩展的MIB模块。
o Management of customer networks
o 客户网络的管理
Customers MAY outsource management of their network (especially CEs and CE-CE links) to the provider network. In such case, the provider MUST be able to manage the customer network, as well as the provider network.
客户可以将其网络（特别是CE和CE-CE链路）的管理外包给提供商网络。在这种情况下，提供商必须能够管理客户网络以及提供商网络。
Security is clearly one of the essential requirements in L1VPNs. In this section, key security requirements are highlighted. Security considerations for L3VPNs and L2VPNs are described in existing documents, such as [RFC4110], [RFC4111], and [RFC4664]. These security considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific security considerations for L1VPNs, such as connectivity restriction and shared control links.
安全性显然是L1VPN的基本要求之一。在本节中，重点介绍了关键的安全要求。现有文档中描述了L3VPN和L2VPN的安全注意事项，如[RFC4110]、[RFC4111]和[RFC4664]。这些安全注意事项也应适用于L1VPN，本节将介绍这些方面。此外，L1VPN还有一些特定的安全注意事项，例如连接限制和共享控制链路。
This section first describes types of information to be secured. Then, security features or aspects are described. Finally, some considerations concerning scenarios where security mechanisms are applied is described.
本节首先介绍要保护的信息类型。然后，描述安全特性或方面。最后，描述了有关应用安全机制的场景的一些注意事项。
It MUST be possible to secure the information exchanged between the customer and the provider. This includes data plane information, control plane information, and management plane information.
必须能够保护客户和提供商之间交换的信息。这包括数据平面信息、控制平面信息和管理平面信息。
At layer 1, data plane information is normally assumed to be secured once connections are established, since those connections are dedicated to each VPN. That is, it is not possible to communicate unless there is a connection. Therefore, in L1VPNs, the main concern of data plane security is restricting VPN connections to be used only within the same VPN, as described in Section 6.2. Note that a customer may wish to assure data plane information security against not only other customers, but also the provider. In such case, the customer may wish to apply their own security mechanisms for data plane information (CE-CE security), as later described.
在第1层，一旦建立连接，通常假设数据平面信息是安全的，因为这些连接专用于每个VPN。也就是说，除非存在连接，否则无法进行通信。因此，在L1VPN中，数据平面安全的主要关注点是限制VPN连接仅在同一VPN内使用，如第6.2节所述。请注意，客户可能希望不仅针对其他客户，而且针对提供商，确保数据平面信息安全。在这种情况下，客户可能希望对数据平面信息应用他们自己的安全机制（CE-CE安全），如下文所述。
In addition, information contained in the provider network MUST be secured. This includes VPN service contract information, current VPN connection information, VPN membership information, and system information. Note these types of information MAY be accessible to authorized entities.
此外，必须保护提供商网络中包含的信息。这包括VPN服务合同信息、当前VPN连接信息、VPN成员信息和系统信息。注：授权实体可以访问这些类型的信息。
Security features include the following:
安全功能包括以下内容：
o Data integrity
o 数据完整性
The information exchanged between the customer and the provider MUST be delivered unchanged.
客户和提供商之间交换的信息必须原封不动地交付。
o Confidentiality
o 保密性
The information exchanged between the customer and the provider MUST NOT be disclosed to a third party.
客户和提供商之间交换的信息不得披露给第三方。
o Authentication
o 认证
The entity requesting the service to the provider MUST be identified and have its identity authenticated, and the provider providing the service MUST also be identified and have its identify authenticated.
必须识别向提供商请求服务的实体并对其身份进行验证，还必须识别提供服务的提供商并对其身份进行验证。
o Access control
o 访问控制
Access to the information contained in the provider network, which may be information about the customer networks or the existence of customers, as well as about the provider network, MUST be restricted to the authorized entity.
必须限制授权实体访问提供商网络中包含的信息，这些信息可能是关于客户网络或客户存在的信息，以及关于提供商网络的信息。
o DoS attack detection and protection
o DoS攻击检测与防护
The provider network MUST have mechanisms to detect DoS attack and to protect against it reactively and proactively.
提供商网络必须具有检测DoS攻击的机制，并主动和被动地对其进行保护。
There are two scenarios (or occasions) in which security mechanisms are applied. One is the service contract phase, where security mechanisms are applied once. The other is the service access phase, where security mechanisms are applied every time the service is requested.
应用安全机制的场景有两种（或两种情况）。一个是服务契约阶段，安全机制只应用一次。另一个是服务访问阶段，每次请求服务时都应用安全机制。
o Service contract scenario (static)
o 服务合同场景（静态）
This scenario includes the addition of new physical devices, such as CE devices, data links and control links. It MUST be guaranteed that these physical devices are connected to the right entity. In addition, authority to access specific information MAY be given to each customer as a part of service contract.
此场景包括添加新的物理设备，如CE设备、数据链路和控制链路。必须保证这些物理设备连接到正确的实体。此外，作为服务合同的一部分，可以授予每位客户访问特定信息的权限。
o Service access scenario (dynamic)
o 服务访问场景（动态）
This scenario includes the reception of connection requests, routing information exchange requests (e.g., attempts to establish a neighbor relationship in routing protocols, or command request via the management plane interface), and management information retrieval requests. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, and the entity connected over this communication channel is identified in the service contract phase, the provider can ensure who is requesting the service. Also, the communication channel could be considered as secure. However, when communication channel is physically shared among customers, security mechanisms MUST be available and SHOULD be enforced. Examples of such security mechanisms include IPsec [RFC4302] and [RFC4303]. Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms to assure higher security, and such mechanisms MUST be available.
此场景包括接收连接请求、路由信息交换请求（例如，尝试在路由协议中建立邻居关系，或通过管理平面接口发出命令请求）和管理信息检索请求。如果客户和提供商之间的通信通道（控制通道、管理接口）在物理上是每个客户分开的，并且通过该通信通道连接的实体在服务合同阶段被识别，那么提供商可以确保谁在请求服务。此外，可以认为通信信道是安全的。然而，当通信通道在客户之间物理共享时，安全机制必须可用，并且应该强制执行。此类安全机制的示例包括IPsec[RFC4302]和[RFC4303]。请注意，即使在物理上独立的通信信道的情况下，客户也可能希望应用安全机制以确保更高的安全性，并且这些机制必须可用。
When the entity requesting the service is identified, the provider MUST ensure that the request is authorized for that entity. This includes assuring that connection request is between VPN end points belonging to the same VPN.
当识别出请求服务的实体时，提供商必须确保该请求已获得该实体的授权。这包括确保连接请求位于属于同一VPN的VPN端点之间。
Also note that customers may wish to apply their own security mechanisms for data plane information (CE-CE security). This includes IPsec [RFC4302] and [RFC4303] for IP traffic.
还请注意，客户可能希望为数据平面信息应用自己的安全机制（CE-CE安全）。这包括IP通信的IPsec[RFC4302]和[RFC4303]。
The material in this document is based on the work of the ITU-T Study Group 13.
本文件中的材料基于ITU-T研究组13的工作。
We would like to thank Dimitri Papadimitriou, Deborah Brungard, Yakov Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel, and Ross Callon for their useful comments and suggestions.
我们要感谢迪米特里·帕帕迪米特里欧、黛博拉·布伦加德、亚科夫·雷克特、亚历克斯·齐宁、伊戈尔·布莱斯金、阿德里安·法雷尔和罗斯·卡隆提出了有益的意见和建议。
Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for helpful input during IESG review.
感谢Mark Townsley、Dan Romascanu和Cullen Jennings在IESG审查期间提供的有用信息。
The foundation of this document is based heavily on the work of ITU-T Study Group 13, Question 11. SG13/Q11 has been investigating the service requirements and architecture for Layer 1 VPNs for some time, and the foundation of this document is a summary and development of the conclusions they have reached. Based on such material, the IETF and the L1VPN WG in particular have developed this framework and requirements for the support of L1VPNs by use of GMPLS protocols.
这份文件的基础是基于ITU-T研究小组13，问题11的工作。SG13/Q11一直在研究第1层VPN的服务需求和体系结构，这篇文献的基础是对它们得出的结论的总结和发展。基于这些材料，IETF和L1VPN工作组特别制定了通过使用GMPLS协议支持L1VPN的框架和要求。
The details of this document are the result of contributions from several authors who are listed here in alphabetic order. Contact details for these authors can be found in a separate section near the end of this document.
本文档的详细信息是几位作者的贡献的结果，这些作者按字母顺序排列在这里。这些作者的联系方式可在本文件末尾附近的单独章节中找到。
Raymond Aubin (Nortel) Marco Carugi (Nortel) Ichiro Inoue (NTT) Hamid Ould-Brahim (Nortel) Tomonori Takeda (NTT)
雷蒙德·奥宾（北电）马可·卡鲁吉（北电）井上一郎（NTT）哈米德·乌尔德·布拉希姆（北电）武田知事（NTT）
[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月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（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月。
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003, available from <http://www.itu.int>.
[Y.1312]Y.1312-第1层虚拟专用网络通用要求和体系结构要素，ITU-T建议，2003年9月，可从<http://www.itu.int>.
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T Recommendation, July 2004, available from <http://www.itu.int>.
[Y.1313]Y.1313-第1层虚拟专用网络服务和网络架构，ITU-T建议，2004年7月，可从<http://www.itu.int>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110]Callon，R.和M.Suzuki，“第3层提供商提供的虚拟专用网络（PPVPN）框架”，RFC 4110，2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]Fang，L.，Ed.“提供商提供的虚拟专用网络（PPVPN）的安全框架”，RFC 4111，2005年7月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139]Papadimitriou，D.，Drake，J.，Ash，J.，Farrel，A.，和L.Ong，“自动交换光网络（ASON）的通用MPLS（GMPLS）信令使用和扩展要求”，RFC 4139，2005年7月。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176]El Mghazli，Y.，Ed.，Nadeau，T.，Boucadair，M.，Chan，K.，和A.Gonguet，“第三层虚拟专用网络（L3VPN）运营和管理框架”，RFC 41762005年10月。
[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月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258]Brungard，D.，Ed.“自动交换光网络（ASON）的通用多协议标签交换（GMPLS）路由要求”，RFC 4258，2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
Authors' Addresses
作者地址
Raymond Aubin Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 763 2208 EMail: aubin@nortel.com
Raymond Aubin Nortel Networks邮政信箱3511加拿大渥太华C站K1Y 4H7电话：+1（613）763 2208电子邮件：aubin@nortel.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE Phone: +33 1 6955 7027 EMail: marco.carugi@nortel.com
Marco Carugi Nortel Networks S.A.马格尼城堡活动公园Les Jeunes Bois-MS CTF 32B5-城堡78928 YVELINES Cedex 9-法国电话：+33 1 6955 7027电子邮件：Marco。carugi@nortel.com
Ichiro Inoue NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6076 EMail: inoue.ichiro@lab.ntt.co.jp
井上一郎NTT网络服务系统实验室，NTT公司3-9-11，日本东京武藏寺弥多里町180-8585电话：+81 422 59 6076电子邮件：井上一郎。ichiro@lab.ntt.co.jp
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
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
Takeda Tomonori，编辑，NTT网络服务系统实验室，NTT公司3-9-11，日本东京武藏市Midori Cho Musashino，180-8585电话：+81 422 59 7434电子邮件：Takeda。tomonori@lab.ntt.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。