Network Working Group D. Fedyk, Ed.
Request for Comments: 5251 Nortel
Category: Standards Track Y. Rekhter, Ed.
Juniper Networks
D. Papadimitriou
Alcatel-Lucent
R. Rabbat
Google
L. Berger
LabN
July 2008
Network Working Group D. Fedyk, Ed.
Request for Comments: 5251 Nortel
Category: Standards Track Y. Rekhter, Ed.
Juniper Networks
D. Papadimitriou
Alcatel-Lucent
R. Rabbat
Google
L. Berger
LabN
July 2008
Layer 1 VPN Basic Mode
第1层VPN基本模式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM.
本文档描述了第1层VPN（L1VPN）的基本模式。L1VPN基本模式（L1VPN BM）是基于端口的VPN。在L1VPN基本模式中，服务的基本单元是给定VPN端口拓扑内一对客户端口之间的标签交换路径（LSP）。本文档定义了使用配置或VPN自动发现机制的操作模型，以及L1VPN BM的信令扩展。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Layer 1 VPN Service .............................................4
3. Addressing, Ports, Links, and Control Channels ..................7
3.1. Service Provider Realm .....................................7
3.2. Layer 1 Ports and Index ....................................7
3.3. Port and Index Mapping .....................................8
4. Port-Based L1VPN Basic Mode ....................................10
4.1. L1VPN Port Information Tables .............................11
4.1.1. Local Auto-Discovery Information ...................12
4.1.2. PE Remote Auto-Discovery Information ...............12
4.2. CE-to-CE LSP Establishment ................................14
4.3. Signaling .................................................15
4.3.1. Signaling Procedures ...............................15
4.3.1.1. Shuffling Sessions ........................16
4.3.1.2. Stitched or Nested Sessions ...............17
4.3.1.3. Other Signaling ...........................18
4.4. Recovery Procedures .......................................19
5. Security Considerations ........................................20
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................22
7. Acknowledgments ................................................23
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Layer 1 VPN Service .............................................4
3. Addressing, Ports, Links, and Control Channels ..................7
3.1. Service Provider Realm .....................................7
3.2. Layer 1 Ports and Index ....................................7
3.3. Port and Index Mapping .....................................8
4. Port-Based L1VPN Basic Mode ....................................10
4.1. L1VPN Port Information Tables .............................11
4.1.1. Local Auto-Discovery Information ...................12
4.1.2. PE Remote Auto-Discovery Information ...............12
4.2. CE-to-CE LSP Establishment ................................14
4.3. Signaling .................................................15
4.3.1. Signaling Procedures ...............................15
4.3.1.1. Shuffling Sessions ........................16
4.3.1.2. Stitched or Nested Sessions ...............17
4.3.1.3. Other Signaling ...........................18
4.4. Recovery Procedures .......................................19
5. Security Considerations ........................................20
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................22
7. Acknowledgments ................................................23
This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM) that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is covered in [RFC5253]. In this document, we consider a layer 1 service provider network that consists of devices that support GMPLS (e.g., Lambda Switch Capable (LSC) devices, optical cross-connects, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) cross-connects, etc.). We partition these devices into P (provider) and PE (provider edge) devices. In the context of this document we will refer to the former devices as just "P", and to the latter devices as just "PE". The Ps are connected only to the devices within the provider's network. The PEs are connected to the other devices within the network (either Ps or PEs), as well as to the devices outside of the service provider network. We'll refer to such other devices as Customer Edge (CE) devices. An example of a CE would be a GMPLS-enabled device that is either a router, an SDH cross-connect, or an Ethernet switch.
本文档描述了[RFC4847]中概述的第1层VPN（L1VPN BM）的基本模式。[RFC5253]中介绍了第1层VPN的适用性。在本文档中，我们考虑由支持GMPLS的设备组成的层1服务提供商网络（例如，lambda开关能力（LSC）设备、光交叉连接、同步光网络/同步数字体系结构（SONET / SDH）交叉连接等）。我们将这些设备划分为P（提供者）和PE（提供者边缘）设备。在本文件中，我们将前一种设备称为“P”，后一种设备称为“PE”。Ps仅连接到提供商网络内的设备。PEs连接到网络内的其他设备（Ps或PEs）以及服务提供商网络外的设备。我们将提及其他设备，如客户边缘（CE）设备。CE的一个示例是启用GMPLS的设备，它是路由器、SDH交叉连接或以太网交换机。
[RFC4208] defines signaling from the CE to the PE. In [RFC4208], the term "Core Node (CN)" corresponds to P and PE nodes, and the term "Edge Node (EN)" corresponds to CE nodes. We additionally define an "edge Core Node" corresponding to a PE.
[RFC4208]定义从CE到PE的信令。在[RFC4208]中，术语“核心节点（CN）”对应于P和PE节点，术语“边缘节点（EN）”对应于CE节点。我们还定义了一个对应于PE的“边缘核心节点”。
Figure 1 illustrates the components in an L1VPN network.
图1显示了L1VPN网络中的组件。
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+ +--+
+--+ | PE | | |----| |
|CE|----| | | | |CE|
+--+\ +-----+ | |----| |
\ | | PE | +--+
\ +-----+ | |
\| PE | | | +--+
| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+ +--+
+--+ | PE | | |----| |
|CE|----| | | | |CE|
+--+\ +-----+ | |----| |
\ | | PE | +--+
\ +-----+ | |
\| PE | | | +--+
| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Generalized Layer 1 VPN Reference Model
图1：通用第1层VPN参考模型
This document specifies how the L1VPN Basic Mode service can be realized using off-line provisioning or VPN auto-discovery, Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] mechanisms.
本文档规定了如何使用离线配置或VPN自动发现、通用多协议标签交换（GMPLS）信令[RFC3471]、[RFC3473]、路由[RFC4202]和LMP[RFC4204]机制实现L1VPN基本模式服务。
L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN auto-discovery. As with L3VPNs, there are protocol choices to be made with auto-discovery. Section 4.1.1 deals with the information that needs to be discovered.
L3VPN自动发现具有与L3VPN自动发现类似的要求[RFC4847]。与L3VPN一样，通过自动发现可以选择协议。第4.1.1节涉及需要发现的信息。
GMPLS routing and signaling are used without extensions within the service provider network to establish and maintain LSC or SONET/SDH (Time Division Multiplexing (TDM)) connections between service provider nodes. This follows the model in [RFC4208].
GMPLS路由和信令在服务提供商网络内无需扩展即可用于建立和维护服务提供商节点之间的LSC或SONET/SDH（时分复用（TDM））连接。这遵循[RFC4208]中的模型。
In L1VPN Basic Mode, the use of LMP facilitates the population of the Port Information Tables of the service provider. Indeed, LMP MAY be used as an option to automate local CE-to-PE link discovery. LMP also MAY augment routing (in enhanced mode) as well as failure handling capabilities.
在L1VPN基本模式中，使用LMP有助于填充服务提供商的端口信息表。事实上，LMP可以用作自动化本地CE到PE链路发现的选项。LMP还可以增强路由（在增强模式下）以及故障处理能力。
Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document.
对AS间和供应商间L1VPN的考虑需要进行超出本文件范围的进一步分析。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document expects that the reader is familiar with the terminology defined and used in [RFC3945], [RFC3471], [RFC3473], [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the documents referenced therein.
本文件要求读者熟悉[RFC3945]、[RFC3471]、[RFC3473]、[RFC3477]、[RFC4201]、[RFC4202]、[RFC4204]、[RFC4208]中定义和使用的术语以及其中引用的文件。
Layer 1 VPN services on the interfaces of customer and service provider ports MAY be any of the Layer 1 interfaces supported by GMPLS. Since the mechanisms specified in this document use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and LSC interfaces, it follows that L1VPN services include (but are not restricted) to LSC- or TDM-based equipment. Note that this document describes Basic Mode L1VPNs and as such requires that:
客户和服务提供商端口接口上的第1层VPN服务可以是GMPLS支持的任何第1层接口。由于本文件中规定的机制使用GMPLS作为信令机制，并且GMPLS同时适用于SONET/SDH（TDM）和LSC接口，因此L1VPN服务包括（但不限于）基于LSC或TDM的设备。请注意，本文件描述了基本模式L1VPN，因此要求：
(1) GMPLS RSVP-TE is used for signaling both within the service provider (between PEs), as well as between the customer and the service provider (between CE and PE);
(1) GMPLS RSVP-TE用于服务提供商内部（PEs之间）以及客户和服务提供商之间（CE和PE之间）的信令；
(2) GMPLS Routing on the CE-to-PE link is outside the scope of the Basic Mode of operation of L1VPN; see [RFC4847].
(2) CE-to-PE链路上的GMPLS路由超出L1VPN基本操作模式的范围；见[RFC4847]。
A CE is connected to a PE via one or more links. In the context of this document, a link is a GMPLS Traffic Engineering (TE) link construct, as defined in [RFC4202]. In the context of this document, a TE link is a logical construct that is a member of a VPN, hence introducing the notion of membership to a set of CEs forming the VPN. Interfaces at the end of each link are limited to either TDM or LSC as supported by GMPLS. More specifically, a <CE, PE> link MUST be of the type <X, LSC> or <Y, TDM> where X = PSC (Packet Switch Capable), L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM. One of the applications of a L1VPN connection is to provide a "virtual private lambda" or similar. In this case, the CE is truly the endpoint in GMPLS terms, and its switching capability on the TE link is not relevant (although its Generalized Protocol Identifier (GPID) MUST be signaled and identical at both CEs, i.e., head-end and tail-end CE).
CE通过一个或多个链路连接到PE。在本文件中，链路是[RFC4202]中定义的GMPLS流量工程（TE）链路结构。在本文档的上下文中，TE链路是作为VPN成员的逻辑结构，因此将成员的概念引入到形成VPN的一组CE中。每个链路末端的接口仅限于GMPLS支持的TDM或LSC。更具体地说，<CE，PE>链路必须是<X，LSC>或<Y，TDM>类型，其中X=PSC（支持分组交换）、L2SC（支持第2层交换）或TDM且Y=PSC或L2SC。在LSP没有被CE终止的情况下，X还可以＝LSC，Y＝TDM。L1VPN连接的一个应用是提供“虚拟专用lambda”或类似连接。在这种情况下，CE实际上是GMPLS术语中的端点，并且其在TE链路上的切换能力不相关（尽管其通用协议标识符（GPID）必须在两个CE上发出信号并相同，即前端和后端CE）。
Likewise, PEs could be any Layer 1 devices that are supported by GMPLS (e.g., optical cross-connects, SDH cross-connects), while CEs MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect, an Ethernet switch, and a router, respectively).
同样，PEs可以是GMPLS支持的任何第1层设备（例如，光交叉连接、SDH交叉连接），而CE可以是第1、2和3层的设备，例如，SDH交叉连接、以太网交换机和路由器。
Each TE link MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively). For the purpose of this discussion, all the channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type, etc.), and MAY be selected independently from the CE's point of view. Channels on different links of a CE need not have the same characteristics.
每个TE链路可包括一个或多个信道或子信道（例如，分别为波长或波长和时隙）。为了本讨论的目的，给定链路内的所有信道必须具有类似的共享特性（例如，交换能力、编码、类型等），并且可以从CE的角度独立选择。CE不同链路上的信道不必具有相同的特性。
There MAY be more than one TE link between a given CE-PE pair. A CE MAY be connected to more than one PE (with at least one port per PE). And, conversely, a PE MAY have more than one CE from different VPNs connected to it.
给定CE-PE对之间可能有多个TE链路。CE可以连接到多个PE（每个PE至少有一个端口）。并且，相反地，一个PE可以有多个来自连接到它的不同VPN的CE。
If a CE is connected to a PE via multiple TE links and all the links belong to the same VPN, these links (referred to as component links) MAY be treated as a single TE link using the link bundling constructs [RFC4201].
如果CE通过多个TE链路连接到PE，并且所有链路都属于同一VPN，则可以使用链路捆绑构造将这些链路（称为组件链路）视为单个TE链路[RFC4201]。
In order to satisfy the requirements of the L1VPN Basic Mode, it is REQUIRED that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or that there is IP reachability between the CE and the PE that could be used to exchange control information.
为了满足L1VPN基本模式的要求，要求对于给定的CE-PE对，它们之间的链路中的至少一个具有至少一个数据承载信道和至少一个控制承载信道，或者CE和PE之间存在可用于交换控制信息的IP可达性。
A point-to-point link has two end-points: one on the CE and one on the PE. This document refers to the former as "CE port", and to the latter as "PE port". From the above, it follows that a CE is connected to a PE via one or more ports, where each port MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively), and all the channels within a given port have shared similar characteristics and can be interchanged from the CE's point of view. Similar to the definition of a TE link, in the context of this document, ports are logical constructs that are used to represent a grouping of physical resources that are used to connect a CE to a PE on a per-L1VPN basis.
点到点链接有两个端点：一个在CE上，一个在PE上。本文件将前者称为“CE端口”，将后者称为“PE端口”。从上面可以看出，CE通过一个或多个端口连接到PE，其中每个端口可以由一个或多个信道或子信道（例如，分别为波长或波长和时隙）组成，并且给定端口内的所有信道具有相似的特征，并且可以从CE的角度互换。与TE链路的定义类似，在本文档的上下文中，端口是逻辑结构，用于表示一组物理资源，这些物理资源用于按每L1VPN将CE连接到PE。
At any point in time, a given port on a PE is associated with at most one L1VPN, or, to be more precise, with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or, to be more precise, with different Port Information Tables). The association of a port with a VPN MAY be defined by provisioning the relationship on the service provider devices. In other words, the context of a VPN membership in Basic Mode is enforced through service provider control.
在任何时间点，PE上的给定端口最多与一个L1VPN关联，或者更准确地说，最多与PE维护的一个端口信息表关联（尽管给定PE上的不同端口可以与不同的L1VPN关联，或者更准确地说，与不同的端口信息表关联）。端口与VPN的关联可以通过在服务提供商设备上设置关系来定义。换句话说，基本模式下VPN成员身份的上下文是通过服务提供商控制来实现的。
It is REQUIRED that the interface (that is between the CE and PE and that is used for the purpose of signaling) be capable of initiating/processing GMPLS protocol messages [RFC3473] and of following the procedures described in [RFC4208].
要求接口（在CE和PE之间，用于信令）能够启动/处理GMPLS协议消息[RFC3473]，并遵循[RFC4208]中描述的程序。
An important goal of L1VPN service is the ability to support what is known as "single-ended provisioning", where the addition of a new port to a given L1VPN involves configuration changes only on the PE that has this port. The extension of this model to the CE is outside the scope of the L1VPN BM.
L1VPN服务的一个重要目标是能够支持所谓的“单端资源调配”，在这种情况下，向给定L1VPN添加新端口只涉及具有此端口的PE上的配置更改。此模型对CE的扩展超出了L1VPN BM的范围。
Another important goal in the L1VPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within an L1VPN from the CE devices without involving configuration changes in any of the service provider's devices. In other words, the VPN topology is under the CE device control (assuming that the underlying PE-to-PE connectivity is provided and allowed by the network).
L1VPN服务的另一个重要目标是能够从CE设备在L1VPN内的一对（现有）端口之间建立/终止LSP，而不涉及任何服务提供商设备中的配置更改。换句话说，VPN拓扑在CE设备控制下（假设网络提供并允许基础PE-to-PE连接）。
The mechanisms outlined in this document aim to achieve the above goals. Specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected and (2) enable a CE to establish the actual LSP to a subset of ports. Finally, the mechanisms allow arbitrary L1VPN topologies to be supported; including topologies ranging from hub-and-spoke to full mesh point-to-point connections. Only point-to-point links are supported.
本文件概述的机制旨在实现上述目标。具体地说，作为L1VPN服务产品的一部分，这些机制（1）使服务提供商能够限制给定端口可以连接到的端口集，（2）使CE能够将实际LSP建立到端口子集。最后，这些机制允许支持任意L1VPN拓扑；包括从轮毂和轮辐到全网格点到点连接的拓扑。仅支持点到点链接。
The exchange of CE routing or topology information to the service provider is out of scope for L1VPN BM mode.
向服务提供商交换CE路由或拓扑信息超出L1VPN BM模式的范围。
GMPLS-established conventions for addressing and link numbering are discussed in [RFC3945]. This section builds on those definitions for the L1VPN case where we now have customer and service provider addresses in a Layer 1 context.
[RFC3945]中讨论了GMPLS建立的寻址和链路编号约定。本节基于L1VPN案例的这些定义，我们现在在第1层上下文中拥有客户和服务提供商地址。
It is REQUIRED that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service. This is necessary to enable GMPLS mechanisms for path establishment and maintenance. We will refer to this realm as the service provider addressing realm. It is further REQUIRED that each L1VPN customer have its own addressing realm with complete freedom to use private or public addresses. We will refer to such realms as the customer addressing realms. Customer addressing realms MAY overlap addresses (i.e., non-unique address) with each other, and MAY also overlap addresses with the service provider realm.
要求一个服务提供商或一组共同提供L1VPN服务的服务提供商具有一个单一的寻址域，该域跨越提供L1VPN服务所涉及的所有PE设备。这对于启用GMPLS机制以建立和维护路径是必要的。我们将这个领域称为服务提供者寻址领域。还要求每个L1VPN客户拥有自己的寻址域，完全可以自由使用私人或公共地址。我们将这些领域称为客户寻址领域。客户寻址域可能相互重叠地址（即非唯一地址），也可能与服务提供商域重叠地址。
Within a given L1VPN, each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN, and use this address as a port identifier. Another way to construct such an identifier is to assign each port on a CE an index that is unique within that CE, assign each CE an address that is unique within a given L1VPN, and then use a tuple <port index, CE address> as a port identifier. Note that both the port and the CE address MAY be an address in several formats. This includes, but is not limited to, IPv4 and IPv6. This identifier is part of the
在给定的L1VPN中，将CE连接到PE的CE上的每个端口都有一个标识符，该标识符在该L1VPN中是唯一的（但在多个L1VPN中不必是唯一的）。构造这种标识符的一种方法是为每个端口分配一个在给定L1VPN中唯一的地址，并将此地址用作端口标识符。构造此类标识符的另一种方法是为CE上的每个端口分配该CE内唯一的索引，为每个CE分配给定L1VPN内唯一的地址，然后使用元组<端口索引，CE地址>作为端口标识符。请注意，端口和CE地址都可以是几种格式的地址。这包括但不限于IPv4和IPv6。此标识符是
Customer addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs do not know or understand the service provider realm addresses.
客户寻址域，由CE设备用于标识CE端口和CE远程端口以进行信令。CEs不知道或不了解服务提供商领域地址。
Within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network. One way to construct such an identifier is to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider addressing realm, and then use a tuple <port index, PE IPv4 address> or <port index, PE IPv6 address> as a port identifier within the service provider network. Another way to construct such an identifier is to assign an IPv4 or IPv6 address that is unique within the service provider addressing realm to each such port. Either way, this IPv4 or IPv6 address is internal to the service provider network and is used for GMPLS signaling within the service provider network.
在服务提供商网络中，将PE连接到CE的PE上的每个端口都有一个在该网络中唯一的标识符。构造这种标识符的一种方法是为PE上的每个端口分配一个在该PE内唯一的索引，为每个PE分配一个在服务提供商寻址域内唯一的IP地址，然后使用元组<端口索引，PE IPv4地址>或<端口索引，PE IPv6地址>，作为服务提供商网络内的端口标识符。构造这样一个标识符的另一种方法是为每个这样的端口分配一个在服务提供者寻址领域内唯一的IPv4或IPv6地址。无论哪种方式，此IPv4或IPv6地址都是服务提供商网络的内部地址，用于服务提供商网络内的GMPLS信令。
As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network. We'll refer to the former as the Customer Port Identifier (CPI), and to the latter as the Provider Port Identifier (PPI).
因此，将CE连接到PE的每条链路都与给定L1VPN内具有唯一标识符的CE端口以及服务提供商网络内具有唯一标识符的PE端口相关联。我们将前者称为客户端口标识符（CPI），后者称为提供商端口标识符（PPI）。
This document requires that each PE port that has a PPI also has an identifier that is unique within the L1VPN customer addressing realm of the L1VPN associated with that port. One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN customer addressing realm, and use this address as a port identifier. Another way to construct such an identifier is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given L1VPN customer addressing realm (but need not be unique within the service provider network), and then use a tuple <port index, PE IP address> that acts as a port identifier. We'll refer to such port identifier as the VPN-PPI. See Figure 2.
本文档要求每个具有PPI的PE端口还具有一个标识符，该标识符在与该端口关联的L1VPN的L1VPN客户寻址域中是唯一的。构造这种标识符的一种方法是为每个端口分配一个地址，该地址在给定的L1VPN客户寻址域中是唯一的，并将此地址用作端口标识符。构造这种标识符的另一种方法是为每个端口分配一个在给定PE中唯一的索引，为每个PE分配一个在给定L1VPN客户寻址域中唯一的IP地址（但在服务提供商网络中不必唯一），然后使用元组<port index，PE IP address>作为端口标识符。我们将把这种端口标识符称为VPN-PPI。参见图2。
For L1VPNs, it is a requirement that service provider operations are independent of the VPN customer's addressing realm and the service provider addressing realm is hidden from the customer. To achieve this, we define two identifiers at the PE, one customer facing and the other service provider facing. The PE IP address used for the VPN-PPI is independent of the PE IP address used for the PPI (as the two are taken from different address realms, the former from the customer's addressing realm and the latter from a VPN service provider's addressing realm). If for a given port on a PE, the PPI
对于L1VPN，要求服务提供商的操作独立于VPN客户的寻址域，并且服务提供商的寻址域对客户隐藏。为了实现这一点，我们在PE上定义了两个标识符，一个面向客户，另一个面向服务提供商。用于VPN-PPI的PE IP地址独立于用于PPI的PE IP地址（因为两者来自不同的地址域，前者来自客户的地址域，后者来自VPN服务提供商的地址域）。对于PE上的给定端口，PPI
and the VPN-PPI port identifiers are unnumbered, then they both could use exactly the same port index. This is a mere convenience since the PPI and VPN_PPI can be in any combination of valid formats.
如果VPN-PPI端口标识符没有编号，那么它们都可以使用完全相同的端口索引。这仅仅是一种方便，因为PPI和VPN_PPI可以是任何有效格式的组合。
(Customer realm)
+----+ +----+
| |<Port Index> <Port Index> | |
| |CPI VPN-PPI | |
---| CE |-----------------------------| PE |---
| | <Port Index> | |
| | PPI | |
+----+ +----+
(Provider realm)
(Customer realm)
+----+ +----+
| |<Port Index> <Port Index> | |
| |CPI VPN-PPI | |
---| CE |-----------------------------| PE |---
| | <Port Index> | |
| | PPI | |
+----+ +----+
(Provider realm)
Figure 2: Customer/Provider Port/Index Mapping
Figure 2: Customer/Provider Port/Index Mapping
Note, as stated earlier, that IP addresses used for the CPIs, PPIs, and VPN-PPIs could be either IPv4 or IPv6 format addresses.
请注意，如前所述，用于CPI、PPI和VPN PPI的IP地址可以是IPv4或IPv6格式的地址。
For a given link connecting a CE to a PE:
对于将CE连接到PE的给定链路：
- If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv4 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv4 address> tuple for the same reason.
- 如果CPI是IPv4地址，则VPN-PPI也必须是IPv4地址，因为VPN PPI是从客户地址空间创建的。如果CPI是<端口索引，CPI IPv4地址>元组，则VPN-PPI必须是<端口索引，PE IPv4地址>元组，原因相同。
- If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv6 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv6 address> tuple for the same reason.
- 如果CPI是IPv6地址，则VPN-PPI也必须是IPv6地址，因为VPN PPI是从客户地址空间创建的。如果CPI是<端口索引，CPI IPv6地址>元组，则VPN-PPI必须是<端口索引，PE IPv6地址>元组，原因相同。
Note: for a given port on the PE, whether the VPN-PPI of that port is an IP address or a <port index, PE IP address> is independent of the format of the PPI of that port.
注意：对于PE上的给定端口，该端口的VPN-PPI是IP地址还是<端口索引，PE IP地址>与该端口的PPI格式无关。
This document assumes that assignment of the PPIs is controlled solely by the service provider (without any coordination with the L1VPN customers), while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN. This provides maximum flexibility. The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. This function may be owned by the service provider but may also be performed by a third party who has agreements with the service provider. And, of course, each L1VPN customer could assign such addresses on its own, without any coordination with other L1VPNs.
本文件假设PPI的分配仅由服务提供商控制（不与L1VPN客户进行任何协调），而CPI和VPN PPI使用的地址分配仅由L1VPN的管理员控制。这提供了最大的灵活性。L1VPN管理员是控制L1VPN客户的L1VPN服务细节的实体。此功能可能归服务提供商所有，但也可能由与服务提供商有协议的第三方执行。当然，每个L1VPN客户可以自行分配此类地址，而无需与其他L1VPN进行任何协调。
This document also requires IP connectivity between the CE and the PE as specified earlier, which is used for the control channel between CE and PE. This connectivity could be either a single IP hop, which could be realized by either a dedicated link or by an L2 VPN, or an IP private network, such as an L3VPN. The only requirement on this connectivity is an unambiguous way to correlate a particular CE-to-PE control channel with a particular L1VPN. When such a channel is realized by a dedicated link, such a link should be associated with a particular L1VPN. When such channel is realized by an L2VPN, a distinct L2VPN should be associated with an L1VPN. When such channel is realized by an L3VPN, a distinct L3VPN should be associated with an L1VPN.
本文件还要求CE和PE之间的IP连接如前所述，用于CE和PE之间的控制通道。这种连接可以是单个IP跃点，可以通过专用链路或L2 VPN实现，也可以是IP专用网络，如L3VPN。这种连接的唯一要求是明确地将特定CE到PE控制通道与特定L1VPN关联起来。当这样的信道由专用链路实现时，这样的链路应该与特定的L1VPN相关联。当此类通道由L2VPN实现时，不同的L2VPN应与L1VPN相关联。当此类通道由L3VPN实现时，不同的L3VPN应与L1VPN相关联。
We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to, but are not REQUIRED to be unique across multiple L1VPNs. Control channel addresses are not shared amongst multiple VPNs. Assignment of CE-CC-Addr and PE-CC-Addr is controlled by the administrators of the L1VPN.
我们将此通道的CE地址称为CE控制通道地址（CE CC Addr），将此通道的PE地址称为PE控制通道地址（PE CC Addr）。CE CC Addr和PE CC Addr在它们所属的L1VPN中都要求是唯一的，但在多个L1VPN中不要求是唯一的。控制通道地址不在多个VPN之间共享。CE CC Addr和PE CC Addr的分配由L1VPN的管理员控制。
Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same L1VPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same L1VPN.
CE上的多个端口只能共享同一控制通道，只要所有这些端口都属于同一个L1VPN。同样，一个PE上的多个端口只能共享同一个控制通道，只要所有这些端口都属于同一个L1VPN。
An L1VPN is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS-based LSP within a given VPN port topology. It is precisely this LSP that forms the basic unit of the L1VPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs in the same VPN over this single port.
L1VPN是基于端口的VPN服务，其中一对CE可以通过服务提供商网络通过给定VPN端口拓扑内基于GMPLS的LSP连接。正是这个LSP构成了服务提供商网络提供的L1VPN服务的基本单元。如果CE连接到PE的端口由多个信道（例如，多个波长）组成，则CE可以通过该单个端口建立到同一VPN中多个其他CE的LSP。
In the L1VPN, the service provider does not initiate the creation of an LSP between a pair of CE ports. The LSP establishment is initiated by the CE. However, the SP, by using the mechanisms/toolkit outlined in this document, restricts the set of other CE ports, which may be the remote endpoints of LSPs that have the given port as the local endpoint. Subject to these restrictions, the CE-to-CE connectivity is under the control of the CEs themselves. In other words, the SP allows a L1VPN to have a certain set of
在L1VPN中，服务提供商不会在一对CE端口之间创建LSP。LSP的建立由行政长官发起。但是，SP通过使用本文档中概述的机制/工具包，限制了其他CE端口集，这些端口可能是以给定端口作为本地端点的LSP的远程端点。根据这些限制，CE到CE的连接由CE自身控制。换句话说，SP允许L1VPN具有特定的
topologies (expressed as a port-to-port connectivity matrix). CE-initiated signaling is used to choose a particular topology from that set.
拓扑（表示为端口到端口连接矩阵）。CE发起的信令用于从该集合中选择特定拓扑。
For each L1VPN that has at least one port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. This table contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. In addition, for local PE ports of a given L1VPN, the tuples also include the VPN-PPIs of these ports.
对于给定PE上至少有一个端口的每个L1VPN，PE维护与该L1VPN关联的端口信息表（PIT）。此表包含其L1VPN内所有端口的<CPI，PPI>元组列表。此外，对于给定L1VPN的本地PE端口，元组还包括这些端口的VPN PPI。
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+|Dissemination| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+|Dissemination| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 3: Basic Mode L1VPN Service
图3：基本模式L1VPN服务
Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C, with their associated PITs. A PIT consists of local information as well as remote information. It follows that a PIT on a given PE is populated from two information sources:
图3显示了三个VPN，VPN-A、VPN-B和VPN-C及其相关的PIT。PIT由本地信息和远程信息组成。因此，给定PE上的PIT由两个信息源填充：
1. The information related to the CEs' ports that are attached to the ports local to that PE.
1. 与连接到该PE本地端口的CEs端口相关的信息。
2. The information about the CEs connected to the remote PEs.
2. 有关连接到远程PEs的CEs的信息。
A PIT MAY be populated via provisioning or by auto-discovery procedures. When provisioning is used, the entire table MAY be populated by provisioning commands either at a console or by a management system that may have some automation capability. As the network grows, some form of automation is desirable.
PIT可以通过供应或自动发现过程填充。使用资源调配时，可以通过控制台上的资源调配命令或具有某种自动化功能的管理系统填充整个表。随着网络的发展，需要某种形式的自动化。
For local information between a CE and a PE, a PE MAY leverage LMP to populate the <CPI, VPN-PPI> link information. This local information also needs to be propagated to other PEs that share the same VPN. The mechanisms for this are out of scope for this document, but the information needed to be exchanged is described in Section 4.1.1.
对于CE和PE之间的本地信息，PE可以利用LMP来填充<CPI，VPN-PPI>链路信息。该本地信息还需要传播到共享同一VPN的其他PE。这方面的机制不在本文件的范围内，但第4.1.1节中描述了需要交换的信息。
The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a PIT for each L1VPN for which it has member CEs locally attached. A PE does not need to maintain PITs for other L1VPNs. However, the full set of PITs with all L1VPN entries for multiple VPNs MAY also be available to all PEs.
这个坑本质上是特定的。PE需要为其在本地连接了成员CE的每个L1VPN维护一个PIT。PE不需要为其他L1VPN维护PIT。但是，具有多个VPN的所有L1VPN条目的全套PIT也可用于所有PE。
The remote information in the context of a VPN identifier (i.e., the remote CEs of this VPN) MAY also be sent to the local CE belonging to the same VPN. Exchange of this information is outside the scope of this document.
VPN标识符上下文中的远程信息（即，该VPN的远程CE）也可以发送到属于同一VPN的本地CE。此信息的交换不在本文件的范围内。
The information that needs to be discovered on a PE local port is the local CPI and the VPN-PPI.
需要在PE本地端口上发现的信息是本地CPI和VPN-PPI。
This information MAY be configured; or, if LMP is used between the CE and PE, LMP MAY be used to exchange this information.
可以配置该信息；或者，如果在CE和PE之间使用LMP，则可以使用LMP来交换该信息。
Once a CPI has been discovered, the corresponding VPN-PPI maps in a local context to a VPN identifier and a corresponding PPI. One way to enforce a provider-controlled VPN context is to pre-provision VPN-PPIs with a VPN identifier. Other policy mechanisms to achieve this are outside the scope of this document. In this manner, a relationship of a CPI to a VPN and PPI port can be established when the port is provisioned as belonging to the VPN.
一旦发现CPI，相应的VPN-PPI将在本地上下文中映射到VPN标识符和相应的PPI。强制提供程序控制的VPN上下文的一种方法是使用VPN标识符预先提供VPN PPI。实现这一目标的其他政策机制不在本文件的范围之内。以这种方式，当端口被设置为属于VPN时，可以建立CPI与VPN和PPI端口的关系。
This section provides the information that is carried by any auto-discovery mechanism, and is used to dynamically populate a PIT. The information provides a single <CPI, PPI> mapping. Each auto-discovery mechanism will define the method(s) by which multiple <CPI, PPI> mappings are communicated, as well as invalidated.
本节提供任何自动发现机制所携带的信息，并用于动态填充PIT。该信息提供了单个<CPI，PPI>映射。每个自动发现机制将定义多个<CPI，PPI>映射的通信方法以及失效方法。
This information should be consistent regardless of the mechanism used to distribute the information [RFC5195], [RFC5252].
无论使用何种机制分发信息[RFC5195]、[RFC5252]，该信息都应保持一致。
The format of encoding a single <PPI, CPI> tuple is:
编码单个<PPI，CPI>元组的格式为：
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
Figure 4: Auto-Discovery Information
图4：自动发现信息
The use and meaning of these fields are as follows:
这些字段的用法和含义如下：
PPI Length:
PPI长度：
A one-octet field whose value indicates the length of the PPI field.
一个八位字节字段，其值表示PPI字段的长度。
PPI:
PPI：
A variable-length field that contains the value of the PPI (either an address or <port index, address> tuple). Note, PPI is always encoded consistently within a provider domain so the format of the PPI field is implicit within a given provider network.
包含PPI值的可变长度字段（地址或<端口索引，地址>元组）。注意，PPI始终在提供者域中进行一致编码，因此PPI字段的格式在给定提供者网络中是隐式的。
CPI AFI:
CPI AFI：
A two-octet field whose value indicates the address family of the CPI. This value is taken from [RFC1700].
一个两个八位字节的字段，其值表示CPI的地址族。该值取自[RFC1700]。
CPI Length:
消费物价指数长度：
A one-octet field whose value indicates the length of the CPI field.
一个八位字节字段，其值表示CPI字段的长度。
CPI:
消费物价指数：
A variable-length field that contains the CPI value (either an address or <port index, address> tuple).
包含CPI值（地址或<端口索引，地址>元组）的可变长度字段。
<PPI, CPI> tuples MUST also be associated with one or more globally unique identifiers associated with a particular VPN. A globally unique identifier can encode a VPN-ID, a route target, or any other globally unique identifier. The globally unique identifiers are under control of network providers. Uniqueness within a service provider administrative domain is sufficient for Basic Mode operation. In the case of multiple provider networks (which is beyond the scope of this document), the globally unique identifier need only be unique and consistent between the those providers. In this document, we specify a generic encoding format for the globally unique identifier common to all the auto-discovery mechanisms. However, each auto-discovery mechanism will define the specific method(s) by which the encoding is distributed and the association with a <PPI, CPI> tuple is made. The encoding of the globally unique identifier associated with the VPN is:
<PPI，CPI>元组还必须与一个或多个与特定VPN关联的全局唯一标识符相关联。全局唯一标识符可以编码VPN-ID、路由目标或任何其他全局唯一标识符。全球唯一标识符由网络提供商控制。服务提供商管理域内的唯一性足以进行基本模式操作。对于多个提供商网络（不在本文档范围内），全局唯一标识符只需在这些提供商之间唯一且一致。在本文中，我们为所有自动发现机制通用的全局唯一标识符指定了通用编码格式。但是，每个自动发现机制都将定义特定的方法，通过该方法分发编码并与<PPI，CPI>元组进行关联。与VPN关联的全局唯一标识符的编码为：
+------------------------------------------------+
| L1VPN globally unique identifier (8 octets) |
+------------------------------------------------+
+------------------------------------------------+
| L1VPN globally unique identifier (8 octets) |
+------------------------------------------------+
Figure 5: Auto-Discovery Globally Unique Identifier Format
图5：自动发现全局唯一标识符格式
In order to establish an LSP, a CE needs to identify all other CEs in the CE's L1VPN that it wants to connect to. A CE may already have obtained this information through provisioning or through some other schemes (such schemes are outside the scope of this document).
为了建立LSP，CE需要识别CE的L1VPN中要连接的所有其他CE。CE可能已经通过供应或其他方案（此类方案不在本文件范围内）获得了该信息。
Ports associated with a given CE-to-PE link MAY also have other information, in addition to their CPI and PPI, associated with them that describes characteristics and constraints of the channels within these ports, such as encoding supported by the channels, bandwidth of a channel, total unreserved bandwidth within the port, etc. This information could be further augmented with the information about certain capabilities of the service provider network (e.g., support regeneration section overhead (RSOH), Data Communications Channel (DCC) transparency, arbitrary concatenation, etc.). This information is used to ensure that ports at each end of an LSP have compatible characteristics, and that there are sufficient unallocated resources to establish an LSP between these ports.
与给定CE-to-PE链路相关联的端口除了它们的CPI和PPI之外，还可以具有与它们相关联的其他信息，这些信息描述了这些端口内信道的特性和约束，例如信道支持的编码、信道的带宽、端口内的总未保留带宽、，该信息可通过关于服务提供商网络的某些能力的信息（例如，支持再生部分开销（RSOH）、数据通信信道（DCC）透明度、任意连接等）进一步增强。此信息用于确保LSP两端的端口具有兼容特性，并且有足够的未分配资源在这些端口之间建立LSP。
It may happen that for a given pair of ports within an L1VPN, each of the CEs connected to these ports would concurrently try to establish an LSP to the other CE. If having a pair of LSPs between a pair of ports is viewed as undesirable, the way to resolve this is to require
可能发生的情况是，对于L1VPN内的给定端口对，连接到这些端口的每个CE将同时尝试建立到另一个CE的LSP。如果在一对端口之间有一对LSP被认为是不可取的，那么解决这一问题的方法是
the CE with the lower value of the CPI to terminate the LSP originated by the CE. This option could be controlled by configuration on the CE devices.
具有较低CPI值的CE终止由CE发起的LSP。此选项可以通过CE设备上的配置进行控制。
In L1VPN BM, a CE needs to be configured with the CPIs of other ports. Once a CE is configured with the CPIs of the other ports within the same L1VPN, which we'll refer to as "target ports", the CE uses a subset of GMPLS signaling to request the provider network to establish an LSP to a target port.
在L1VPN BM中，CE需要配置其他端口的CPI。一旦CE配置了同一L1VPN内其他端口的CPI（我们称之为“目标端口”），CE将使用GMPLS信令的子集来请求提供商网络建立到目标端口的LSP。
For inter-CE connectivity, the CE originates a request that contains the CPI of one of its ports that it wants to use for the LSP, and the CPI of the target port. When the PE attached to the CE that originated the request receives the request, the PE identifies the appropriate PIT, and then uses the information in that PIT to find out the PPI associated with the CPI of the target port carried in the request. The PPI should be sufficient for the PE to establish an LSP. Ultimately, the request reaches the CE associated with the target CPI (note that the request still carries the CPI of the CE that originated the request). If the CE associated with the target CPI accepts the request, the LSP is established.
对于CE间连接，CE发起一个请求，该请求包含其要用于LSP的一个端口的CPI和目标端口的CPI。当附加到发起请求的CE的PE接收到请求时，PE识别适当的PIT，然后使用该PIT中的信息找出与请求中携带的目标端口的CPI相关联的PPI。PPI应足以使PE建立LSP。最终，请求到达与目标CPI相关联的CE（注意，请求仍然携带发起请求的CE的CPI）。如果与目标CPI相关联的CE接受该请求，则建立LSP。
Note that a CE needs not establish an LSP to every target port that the CE knows about, i.e., it is a local CE policy matter to select a subset of target ports to which that CE will try to establish LSPs.
注意，CE不需要为CE知道的每个目标端口建立LSP，即，选择CE将尝试建立LSP的目标端口子集是本地CE策略问题。
The procedures for establishing an individual connection between two corresponding CEs is the same as the procedure specified for GMPLS overlay [RFC4208].
在两个相应CE之间建立单独连接的程序与GMPLS覆盖[RFC4208]规定的程序相同。
When an ingress CE sends an RSVP Path message to an ingress PE, the source IP address in the IP packet that carries the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the ingress PE sends back to the ingress CE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC-Addr.
当入口CE向入口PE发送RSVP Path消息时，携带该消息的IP数据包中的源IP地址设置为适当的CE CC Addr，数据包中的目标IP地址设置为适当的PE CC Addr。当入口PE向入口CE发送回相应的Resv消息时，承载该消息的IP数据包中的源IP地址设置为PE CC Addr，目标IP地址设置为CE CC Addr。
Likewise, when an egress PE sends an RSVP Path message to an egress CE, the source IP address in the IP packet that carries the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the egress CE sends back to the egress PE the corresponding Resv message, the
类似地，当出口PE向出口CE发送RSVP Path消息时，携带该消息的IP分组中的源IP地址被设置为适当的PE CC Addr，并且分组中的目的地IP地址被设置为适当的CE CC Addr。当出口向出口PE发送回相应的Resv消息时，出口PE
source IP address in the IP packet that carries the message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC-Addr.
承载消息的IP数据包中的源IP地址设置为CE CC Addr，目标IP地址设置为PE CC Addr。
In addition to being used for IP addresses in the IP packet that carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr are also used in the Next/Previous Hop Address field of the IF_ID RSVP_Hop Object that is carried between CEs and PEs.
除了用于在CE和PE之间传输RSVP消息的IP数据包中的IP地址外，CE CC Addr和PE CC Addr还用于在CE和PE之间传输的IF_ID RSVP_Hop对象的下一个/上一个Hop地址字段。
In the case where a link between CE and PE is a numbered non-bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP_Hop Object that is carried between the CE and PE. In the case where a link between CE and PE is an unnumbered non-bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. In the case where a link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs.
在CE和PE之间的链路是编号的非捆绑链路的情况下，该链路的CPI和VPN-PPI用于CE和PE之间携带的IF_ID RSVP_Hop对象的类型1或2 tlv。在CE和PE之间的链路是未编号的非捆绑链路的情况下，该链路的CPI和VPN-PPI用于类型3 TLV的IP地址字段。在CE和PE之间的链路是捆绑链路的情况下，该链路的CPI和VPN-PPI用于类型3 TLV的IP地址字段。
Additional processing related to unnumbered links is described in Sections 3 ("Processing the IF_ID RSVP_HOP object") and 4.1 ("Unnumbered Forwarding Adjacencies") of RFC 3477 [RFC3477].
RFC 3477[RFC3477]第3节（“处理IF_ID RSVP_HOP对象”）和第4.1节（“未编号的转发邻接”）中描述了与未编号链路相关的附加处理。
When an ingress CE originates a Path message to establish an LSP from a particular port on that CE to a particular target port, the CE uses the CPI of its port in the Sender Template object. If the CPI of the target port is an IP address, then the CE uses it in the Session object. And if the CPI of the target port is a <port index, IP address> tuple, then the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the Explicit Route Object (ERO).
当入口CE发起路径消息以建立从该CE上的特定端口到特定目标端口的LSP时，CE在发送方模板对象中使用其端口的CPI。如果目标端口的CPI是IP地址，则CE在会话对象中使用它。如果目标端口的CPI是<端口索引，IP地址>元组，则CE使用会话对象中元组的IP地址部分，并将整个元组作为显式路由对象（ERO）中未编号的接口ID子对象。
There are two options for RSVP-TE sessions. One option is to have a single RSVP-TE session end to end where the addresses of the customer and the provider are swapped at the PE; this is termed shuffling. The other option is when stitching or hierarchy is used to create two LSP sessions, one between the provider PE(s) and another end-to-end session between the CEs.
RSVP-TE会话有两个选项。一种选择是拥有一个端到端的RSVP-TE会话，其中客户和提供商的地址在PE交换；这被称为洗牌。另一个选项是使用缝合或层次结构创建两个LSP会话时，一个在提供商PE之间，另一个在CEs之间的端到端会话。
Shuffling sessions are used when the desire is to have a single LSP originating at the CE and terminating at the far end CE. The customer addresses are shuffled to provider addresses at the ingress PE, and back to customer addresses at the egress PE by using the mapping provided by the PIT.
当希望有一个LSP从CE发起并在远端CE终止时，使用洗牌会话。通过使用PIT提供的映射，客户地址在入口PE处被洗牌到提供者地址，在出口PE处被洗牌到客户地址。
When the Path message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces CPIs with these PPIs. As a result, the Session and the Sender Template objects that are carried in the GMPLS signaling within the service provider network carry PPIs, and not CPIs.
当路径消息到达入口PE时，PE选择与L1VPN关联的PIT，然后使用该PIT将会话中携带的CPI和发送方模板对象映射到适当的PPI。映射完成后，入口PE将用这些PPI替换CPI。因此，在服务提供商网络内的GMPLS信令中承载的会话和发送方模板对象承载PPI，而不是CPI。
At the egress PE, the reverse mapping operation is performed. The PE extracts the ingress/egress PPI values carried in the Sender Template and Session objects (respectively). The egress PE identifies the appropriate PIT to find the appropriate CPI associated with the PPI of the egress CE. Once the mapping is retrieved, the egress PE replaces the ingress/egress PPI values with the corresponding CPI values. As a result, the Session and the Sender Template objects (included in the GMPLS RSVP-TE Path message sent from the egress PE to the egress CE) carry CPIs, and not PPIs.
在出口PE处，执行反向映射操作。PE提取发送方模板和会话对象（分别）中携带的入口/出口PPI值。出口PE识别适当的坑，以找到与出口PPI相关的适当CPI。一旦检索到映射，出口PE就用相应的CPI值替换入口/出口PPI值。因此，会话和发送方模板对象（包括在从出口PE发送到出口CE的GMPLS RSVP-TE路径消息中）携带CPI，而不是PPI。
Here also, for the GMPLS RSVP-TE Path messages sent from the egress PE to CE, the source IP address (of the IP packet carrying this message) is set to the appropriate PE-CC-Addr, and the destination IP address (of the IP packet carrying this message) is set to the appropriate CE-CC-Addr.
这里，对于从出口PE发送到CE的GMPLS RSVP-TE路径消息，源IP地址（承载该消息的IP分组的）被设置为适当的PE CC Addr，并且目标IP地址（承载该消息的IP分组的）被设置为适当的CE CC Addr。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual link between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs MAY filter the RSVP-TE signaling, i.e., remove information about the provider topology and replace it with a view of a virtual link.
此时，CE的视图是两个CE之间点对点的单个LSP，PE节点之间有一个虚拟链路：CE-PE（-）PE-CE。L1VPN PE节点可以查看PE到PE LSP段的所有详细信息。PEs可以过滤RSVP-TE信令，即移除关于提供商拓扑的信息，并用虚拟链路的视图替换它。
This translation of addresses and session IDs is termed shuffling and is driven by the L1VPN Port Information Tables (see Section 4). This MUST be performed for all RSVP-TE messages at the PE edges. In this case, there is one CE-to-CE session.
地址和会话ID的这种转换称为洗牌，由L1VPN端口信息表驱动（参见第4节）。必须对PE边缘的所有RSVP-TE消息执行此操作。在这种情况下，有一个CE-to-CE会话。
Stitching or Nesting options are dependent on the LSP switching types. If the CE-to-CE and PE-to-PE LSPs are identical in switching type and capacity, the LSP MAY be stitched together and the procedures in [RFC5150] apply. If the CE-to-CE LSPs and the PE-to-PE LSPs are of not the same switching type, or are of different but compatible capacity, the LSPs MAY be Nested and the procedures for [RFC4206] apply. As both Stitched and Nested LSP signaling procedures involve a PE-to-PE session establishment compatible with CE session parameters, they are described together.
缝合或嵌套选项取决于LSP切换类型。如果CE-to-CE和PE-to-PE LSP的开关类型和容量相同，则LSP可以缝合在一起，并且[RFC5150]中的程序适用。如果CE-to-CE LSP和PE-to-PE LSP不是相同的交换类型，或者具有不同但兼容的容量，则LSP可以嵌套并且[RFC4206]的程序适用。由于缝合和嵌套LSP信令过程都涉及与CE会话参数兼容的PE-to-PE会话建立，因此将它们一起描述。
When the Path Message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, a new PE-to-PE session is established with the parameters compatible with the CE session. Upon successful establishment of the PE-to-PE session, the CE signaling request is sent to the egress PE.
当路径消息到达入口PE时，PE选择与L1VPN关联的PIT，然后使用该PIT将会话中携带的CPI和发送方模板对象映射到适当的PPI。映射完成后，将使用与CE会话兼容的参数建立新的PE到PE会话。在成功建立PE到PE会话时，CE信令请求被发送到出口PE。
At the ingress PE, when stitching and nesting are used, a PE-to-PE session is established. This could be achieved by several means:
在入口PE，当使用缝合和嵌套时，建立PE到PE会话。这可以通过以下几种方式实现：
- Associating an already established PE-to-PE LSP or Forwarding Adjacency LSP (FA-LSP) to the destination that meets the requested parameters.
- 将已建立的PE-to-PE LSP或转发邻接LSP（FA-LSP）关联到满足请求参数的目的地。
- Establishing a compliant PE-to-PE LSP segment.
- 建立符合要求的PE-to-PE LSP段。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual node between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs do not have to filter the RSVP-TE signaling by removing information about the provider topology because the PE-to-PE signaling is not visible to the CE nodes.
此时，CE的视图是两个CE之间点对点的单个LSP，PE节点之间有一个虚拟节点：CE-PE（-）PE-CE。L1VPN PE节点可以查看PE到PE LSP段的所有详细信息。由于PE-to-PE信令对CE节点不可见，因此PE不必通过删除关于提供商拓扑的信息来过滤RSVP-TE信令。
An ingress PE may receive and potentially reject a Path message that contains an Explicit Route Object and so cause the switched connection setup to fail. However, the ingress PE may accept EROs, which include a sequence of {<ingress PE (strict), egress CE CPI (loose)>}.
入口PE可能接收并可能拒绝包含显式路由对象的路径消息，从而导致交换连接设置失败。然而，入口PE可以接受ero，其包括{<入口PE（严格）、出口CE CPI（松散）>}序列。
- Path message without ERO: when an ingress PE receives a Path message from an ingress CE that contains no ERO, it MUST calculate a route to the destination for the PE-to-PE LSP and include that route in an ERO, before forwarding the Path message. One exception would be if the egress core node were also adjacent to this core node.
- 无ERO的路径消息：当入口PE从入口CE接收到不包含ERO的路径消息时，它必须在转发路径消息之前计算PE到PE LSP到目的地的路由，并将该路由包括在ERO中。一个例外是，如果出口核心节点也与该核心节点相邻。
- Path message with ERO: when an ingress PE receives a Path message from an ingress CE that contains an ERO (of the form detailed above), the former computes a path to reach the egress PE. It then inserts this path as part of the ERO before forwarding the Path message.
- 带有ERO的路径消息：当入口PE从入口CE接收到包含ERO（如上所述形式）的路径消息时，前者计算到达出口PE的路径。然后，在转发路径消息之前，它将该路径作为ERO的一部分插入。
In the case of shuffling, the overlay rules for notification and RRO processing are identical to the User-Network Intercase (UNI) or Overlay Model [RFC4208], which state that Edge PE MAY remove/edit
在混洗的情况下，用于通知和RRO处理的覆盖规则与用户网络Intercase（UNI）或覆盖模型[RFC4208]相同，其表明边缘PE可以删除/编辑
Provider Notification and RRO objects when passing the messages to the CEs.
将消息传递给CEs时提供程序通知和RRO对象。
Signaling:
信号：
A CE requests a network-protected LSP (i.e., an LSP that is protected from PE-to-PE) by using the technique described in [RFC4873]. Dynamic identification of merge nodes is supported via the LSP Segment Recovery Flags carried in the Protection object (see Section 6.2 of [RFC4873]).
CE通过使用[RFC4873]中描述的技术请求网络保护的LSP（即，从PE到PE保护的LSP）。通过保护对象中携带的LSP段恢复标志支持合并节点的动态识别（参见[RFC4873]第6.2节）。
Notification:
通知:
A Notify Request object MAY be inserted in Path or Resv messages to indicate the address of a CE that should be notified of an LSP failure. Notifications MAY be requested in both the upstream and downstream directions:
可以在Path或Resv消息中插入Notify Request对象，以指示应被通知LSP故障的CE的地址。可在上游和下游方向请求通知：
- Upstream notification is indicated via the inclusion of a Notify Request object in the corresponding Path message.
- 上游通知通过在相应的路径消息中包含Notify请求对象来指示。
- Downstream notification is indicated via the inclusion of a Notify Request object in the corresponding Resv message.
- 下游通知通过在相应的Resv消息中包含Notify请求对象来指示。
A PE receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding RSVP state block. The PE SHOULD also include a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy. This means that a PE, upon receipt of this object from the CE, MAY update the value of the Notify Node Address.
接收包含Notify Request对象的消息的PE应将Notify节点地址存储在相应的RSVP状态块中。PE还应在传出路径或Resv消息中包含Notify请求对象。可以基于本地策略更新传出通知节点地址。这意味着PE在从CE接收到该对象后，可以更新通知节点地址的值。
If the ingress CE includes a Notify Request object into the Path message, the ingress PE MAY replace the received 'Notify Node Address' by its own selected 'Notify Node Address', and in particular the local TE Router_ID. The Notify Request object MAY be carried in Path or Resv messages (Section 7 of [RFC3473]). The format of the Notify Request object is defined in [RFC3473]. Per Section 4.2.1 of [RFC3473], Notify Node Addresses SHALL be set to either IPv4 or IPv6.
如果入口CE在Path消息中包含Notify请求对象，入口PE可将接收到的“Notify Node Address”替换为其自己选择的“Notify Node Address”，尤其是本地TE路由器ID。Notify请求对象可在Path或Resv消息中携带（RFC3473第7节）。通知请求对象的格式在[RFC3473]中定义。根据[RFC3473]第4.2.1节，通知节点地址应设置为IPv4或IPv6。
Inclusion of a Notify Request object is used to request the generation of notifications upon failure occurrence but does not guarantee that a Notify message will be generated.
包含Notify Request对象用于在发生故障时请求生成通知，但不能保证生成Notify消息。
Security for L1VPNs is covered in [RFC4847] and [RFC5253]. In this document, we discuss the security aspects with respect to the control plane.
[RFC4847]和[RFC5253]中介绍了L1VPN的安全性。在本文档中，我们将讨论与控制平面相关的安全方面。
The association of a particular port with a particular L1VPN (or to be more precise, with a particular PIT) is a configuration operation, generally done manually by the service provider as part of the service provisioning process. Thus, it cannot be altered via signaling between CE and PE. This means that the signaling cannot be used to deliver L1VPN traffic to the wrong customer. The operator should apply appropriate security mechanisms to the management and configuration process, and should consider data plane verification techniques to protect against accidental misconfiguration. The customer may also apply end-to-end (i.e., CE-to-CE) data plane connectivity tests over the L1VPN connection to detect misconnection. Data plane connectivity testing can be performed using the Link Management Protocol (LMP) [RFC4204].
特定端口与特定L1VPN（或者更准确地说，与特定PIT）的关联是一种配置操作，通常由服务提供商在服务提供过程中手动完成。因此，它不能通过CE和PE之间的信令来改变。这意味着信令不能用于将L1VPN流量传递给错误的客户。操作员应将适当的安全机制应用到管理和配置过程中，并应考虑数据平面验证技术来防止意外错误配置。客户还可以在L1VPN连接上应用端到端（即CE到CE）数据平面连接测试，以检测错误连接。可以使用链路管理协议（LMP）[RFC4204]执行数据平面连接测试。
Note that it is also possible to populate the local part of a PIT using auto-discovery through LMP. LMP may be secured as described in [RFC4204]. Signaling between CE and PE is assumed to be over a private link (for example, in-band or in-fiber) or a private network. Use of a private link makes the CE-to-PE connection secure at the same level as the data link described in the previous paragraphs. The use of a private network assumes that entities outside the network cannot spoof or modify control plane communications between CE and PE. Furthermore, all entities in the private network are assumed to be trusted. Thus, no security mechanisms are required by the protocol exchanges described in this document.
请注意，也可以通过LMP使用自动发现填充PIT的本地部分。LMP可以按照[RFC4204]中所述进行保护。假设CE和PE之间的信令通过专用链路（例如，带内或光纤）或专用网络。使用专用链路可使CE-to-PE连接的安全级别与前面段落中描述的数据链路相同。专用网络的使用假设网络外的实体不能欺骗或修改CE和PE之间的控制平面通信。此外，假设私有网络中的所有实体都是可信的。因此，本文件中描述的协议交换不需要任何安全机制。
However, an operator that is concerned about the security of their private control plane network may use the authentication and integrity functions available in RSVP-TE [RFC3473] or utilize IPsec ([RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]) for the point-to-point signaling between PE and CE. See [MPLS-SEC] for a full discussion of the security options available for the GMPLS control plane.
然而，关心其专用控制平面网络安全性的运营商可使用RSVP-TE[RFC3473]中可用的认证和完整性功能，或利用IPsec（[RFC4301]、[RFC4302]、[RFC4835]、[RFC4306]和[RFC2411]）在PE和CE之间进行点到点信令。有关GMPLS控制平面可用安全选项的完整讨论，请参阅[MPLS-SEC]。
Note further that a private network (e.g., Layer 2 VPN or Layer 3 VPN) might be used to provide control plane connectivity between a PE and more than one CE. In this scenario, it is RECOMMENDED that each L1 VPN customer have its own such private network. Then, the security mechanisms provided by the private network SHOULD be used to ensure security of the control plane communication between a customer and a service provider.
进一步注意，私有网络（例如，第2层VPN或第3层VPN）可用于提供PE和多个CE之间的控制平面连接。在这种情况下，建议每个L1 VPN客户拥有自己的专用网络。然后，应使用专用网络提供的安全机制来确保客户和服务提供商之间控制平面通信的安全。
[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月。
[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月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[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月。
[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月。
[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月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，RFC1700，1994年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，2007年4月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]Ould Brahim，H.，Fedyk，D.，和Y.Rekhter，“基于BGP的第一层VPN自动发现”，RFC 51952008年6月。
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[RFC5252]Bryskin，I.和L.Berger，“基于OSPF的第1层VPN自动发现”，RFC 5252，2008年7月。
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 2008.
[RFC5253]武田，T.，编辑，“第1层虚拟专用网络（L1VPN）基本模式的适用性声明”，RFC 5253，2008年7月。
[MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[MPLS-SEC]Fang，L.，Ed.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年2月。
The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and Tomonori Takeda for their valuable comments.
作者要感谢阿德里安·法雷尔、哈米德·乌尔德·布拉希姆和武田友诺里的宝贵评论。
Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk, and Ron Bonica provided input during the IESG review process.
Sandy Murphy、Charlie Kaufman、Pasi Eronen、Russ Housley、Tim Polk和Ron Bonica在IESG审查过程中提供了意见。
Authors' Addresses
作者地址
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: +1 (978) 288 3041 EMail: dwfedyk@nortel.com
Don Fedyk Nortel Networks 600科技园马萨诸塞州Billerica 01821电话：+1（978）288 3041电子邮件：dwfedyk@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: yakov@juniper.net
加利福尼亚州桑尼维尔马蒂尔达大道北1194号Yakov Rekhter Juniper Networks，邮编94089电子邮件：yakov@juniper.net
Dimitri Papadimitriou Alcatel-Lucent Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Fr.Wellesplein 1，B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。Papadimitriou@alcatel-朗讯
Richard Rabbat Google Inc. 1600 Amphitheatre Pky Mountain View, CA 95054 EMail: rabbat@alum.mit.edu
Richard Rabbat Google Inc.1600圆形剧场Pky Mountain View，加利福尼亚州95054电子邮件：rabbat@alum.mit.edu
Lou Berger LabN Consulting, LLC Phone: +1 301-468-9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，LLC电话：+1 301-468-9228电子邮件：lberger@labn.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.