Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 5994 M. Morrow
Category: Informational G. Swallow
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
T. Nadeau
Huawei Technologies
N. Harrison
BT
B. Niven-Jenkins
Velocix
October 2010
Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 5994 M. Morrow
Category: Informational G. Swallow
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
T. Nadeau
Huawei Technologies
N. Harrison
BT
B. Niven-Jenkins
Velocix
October 2010
Application of Ethernet Pseudowires to MPLS Transport Networks
以太网伪线在MPLS传输网络中的应用
Abstract
摘要
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
以太网伪线广泛用于支持以太网服务的数据包传输。这些服务反过来为各种客户端网络提供传输，例如IP和MPLS。本文件使用现有IETF规范中定义的通过MPLS网络传输的以太网伪线的程序。
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
IETF和ITU-T联合形成的MPLS传输配置文件（MPLS-TP）设计工作也承认了本文件中解释的机制所提供服务的许多要求。此处描述的解决方案并未满足所有MPLS-TP要求，但它使用现有的工具提供了一种可行的包传输服务形式。
This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully-featured packet transport solution addressing all of the requirements of MPLS-TP.
本文件还表明，现有MPLS技术构成了设计满足MPLS-TP所有要求的全功能分组传输解决方案的适当基础。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5994.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5994.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PWE3 Configuration . . . . . . . . . . . . . . . . . . . . . . 5
3. Operations, Administration, and Maintenance (OAM) . . . . . . 5
3.1. VCCV Profile 1: BFD without IP/UDP Headers . . . . . . . . 6
3.2. VCCV Profile 2: BFD with IP/UDP Headers . . . . . . . . . 6
4. MPLS Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. External Configuration . . . . . . . . . . . . . . . . . . 6
4.2. Control Plane Configuration . . . . . . . . . . . . . . . 7
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PWE3 Configuration . . . . . . . . . . . . . . . . . . . . . . 5
3. Operations, Administration, and Maintenance (OAM) . . . . . . 5
3.1. VCCV Profile 1: BFD without IP/UDP Headers . . . . . . . . 6
3.2. VCCV Profile 2: BFD with IP/UDP Headers . . . . . . . . . 6
4. MPLS Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. External Configuration . . . . . . . . . . . . . . . . . . 6
4.2. Control Plane Configuration . . . . . . . . . . . . . . . 7
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
以太网伪线广泛用于支持以太网服务的数据包传输。这些服务反过来为各种客户端网络提供传输，例如IP和MPLS。本文件使用现有IETF规范中定义的通过MPLS网络传输的以太网伪线的程序。
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T [RFC5654]. For example, the ability to operate solely with network management control, the ability to use Operations, Administration, and Maintenance (OAM) that does not rely on IP forwarding, and the ability to provide light-weight proactive connection verification (CV) functionality.
IETF和ITU-T[RFC5654]共同制定的MPLS传输配置文件（MPLS-TP）设计工作也承认了本文件中解释的机制所提供服务的许多要求。例如，能够单独使用网络管理控制进行操作，能够使用不依赖IP转发的操作、管理和维护（OAM），以及能够提供轻型主动连接验证（CV）功能。
The solution described in this document does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
本文档中描述的解决方案并没有满足所有MPLS-TP要求，但它使用现有工具提供了一种可行的分组传输服务形式。
The key purpose of this document is to demonstrate that there is an existing IETF mechanism with known implementations that satisfies the requirements posed by the operator community. It is recognized that it is possible to design a more efficient method of satisfying the requirements, and the IETF anticipates that improved solutions will be proposed in the future as part of the MPLS-TP effort. Indeed, the solution described in this document is not intended to detract from the MPLS-TP effort. Instead, it provides legitimacy for that work by showing that there is a real demand from networks that are already deployed, and by indicating that the MPLS-TP solutions work is based on sound foundations.
本文件的主要目的是证明现有IETF机制及其已知实现满足运营商社区提出的要求。人们认识到，设计一种更有效的满足需求的方法是可能的，IETF预计，作为MPLS-TP工作的一部分，未来将提出改进的解决方案。事实上，本文档中描述的解决方案并不是为了减少MPLS-TP的工作量。相反，它通过表明已经部署的网络存在真正的需求，并表明MPLS-TP解决方案的工作基于良好的基础，为这项工作提供了合法性。
Much of the notation used in this document is defined in [RFC3985] to which the reader is referred for definitions.
本文件中使用的大部分符号在[RFC3985]中有定义，读者可参考该定义。
The architecture required for this mechanism is illustrated in Figure 1.
该机制所需的体系结构如图1所示。
+----------------------------------------------------------------+
| |
| IP/MPLS PSN (PHP may be enabled) |
| (client) |
| |
| +---------------------------+ |
| | | |
| | MPLS PSN (No PHP) | |
| | (server) | |
| | | |
| CE1 |PE1 PE2| CE2 |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | | | | | | | | | |
| | | | +------+ | | | | | | +------+ | | | |
| | | | | 802.3| | | | | | | | 802.3| | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | |
| | | +-- ---------------------- -+ | | |
+----- --- -------- -- ---------------------- - -------- --- ----+
| | | |<--MPLS LSP (no PHP)->| | | |
| | | | (server) | | | |
| | | | | |
| | |<------------PW----------->| | |
| | | (server) | | |
| | | |
| |<-------------802.3 (Ethernet)-------------->| |
| | (client) | |
| |
|<---------IP/MPLS LSP (PHP may be supported)-------->|
| (client) |
+----------------------------------------------------------------+
| |
| IP/MPLS PSN (PHP may be enabled) |
| (client) |
| |
| +---------------------------+ |
| | | |
| | MPLS PSN (No PHP) | |
| | (server) | |
| | | |
| CE1 |PE1 PE2| CE2 |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | | | | | | | | | |
| | | | +------+ | | | | | | +------+ | | | |
| | | | | 802.3| | | | | | | | 802.3| | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | |
| | | +-- ---------------------- -+ | | |
+----- --- -------- -- ---------------------- - -------- --- ----+
| | | |<--MPLS LSP (no PHP)->| | | |
| | | | (server) | | | |
| | | | | |
| | |<------------PW----------->| | |
| | | (server) | | |
| | | |
| |<-------------802.3 (Ethernet)-------------->| |
| | (client) | |
| |
|<---------IP/MPLS LSP (PHP may be supported)-------->|
| (client) |
Figure 1: Application Ethernet over MPLS PW to MPLS Transport Networks
图1:MPLS PW到MPLS传输网络上的应用以太网
An 802.3 (Ethernet) circuit is established between CE1 and CE2. This circuit may be used for the concurrent transport of MPLS packets as well as IPv4 and IPv6 packets. The MPLS packets may carry IPv4, IPV6, or pseudowire payloads, and Penultimate Hop Popping (PHP) may be used. For clarity, these paths are labeled as the client in Figure 1.
在CE1和CE2之间建立了一个802.3（以太网）电路。该电路可用于MPLS数据包以及IPv4和IPv6数据包的并发传输。MPLS数据包可以承载IPv4、IPV6或伪线有效载荷，并且可以使用倒数第二跳弹出（PHP）。为了清楚起见，这些路径在图1中被标记为客户机。
An Ethernet pseudowire (PW) is provisioned between PE1 and PE2 and is used to carry the Ethernet from PE1 to PE2. The Ethernet PW is carried over an MPLS Packet Switched Network (PSN), but this PSN MUST NOT be configured with PHP. For clarity, this Ethernet PW and the MPLS PSN are labeled as the server in Figure 1. In the remainder of this document, call the server network a transport network.
在PE1和PE2之间提供以太网伪线（PW），用于将以太网从PE1传输到PE2。以太网PW通过MPLS分组交换网络（PSN）传输，但此PSN不得使用PHP配置。为清楚起见，此以太网PW和MPLS PSN在图1中标记为服务器。在本文档的其余部分中，将服务器网络称为传输网络。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The PWE3 encapsulation used by this specification to satisfy the transport requirement is Ethernet [RFC4448]. This is used in "raw" mode.
本规范用于满足传输要求的PWE3封装为以太网[RFC4448]。这在“原始”模式下使用。
The Control Word MUST be used. The sequence number MUST be zero.
必须使用控制字。序列号必须为零。
The use of the Pseudowire Setup and Maintenance Label Distribution Protocol [RFC4447] is not required by the profile of the PWE3 Ethernet pseudowire functionality defined in this document.
本文档中定义的PWE3以太网伪线功能配置文件不要求使用伪线设置和维护标签分发协议[RFC4447]。
The pseudowire label is statically provisioned.
伪导线标签是静态设置的。
Within a connection, traffic units sent from the single source are constrained to stay within the connection under defect-free conditions. During misconnected defects, a connection can no longer be assumed to be constrained, and traffic units (and by implication also OAM packets) can 'leak' unidirectionally outside a connection. Therefore, during a misconnected state, it is not possible to rely on OAM, which relies on a request/response mechanism, and, for this reason, such OAM should be treated with caution if used for diagnostic purposes.
在一个连接中，在无缺陷的条件下，从单个源发送的流量单元被限制在连接中。在错误连接缺陷期间，不能再假设连接受到约束，并且通信单元（也包括OAM数据包）可以在连接外部单向“泄漏”。因此，在错误连接状态期间，不可能依赖依赖依赖于请求/响应机制的OAM，因此，如果出于诊断目的使用此类OAM，则应谨慎对待。
Further, when implementing an Equal Cost Multipath (ECMP) function with MPLS, use of the label stack as the path selector such that the OAM and data are not in a co-path SHOULD be avoided, as any failure in the data path will not be reflected in the OAM path. Therefore, an OAM that is carried within the data-path below the PW label (such as Virtual Circuit Connectivity Verification (VCCV)) is NOT vulnerable to the above failure mode. For these reasons, the OAM mechanism is as described in [RFC5085], which uses Bidirectional Forwarding Detection (BFD) [RFC5880] for connection verification (CV). The method of using BFD as a CV method in VCCV is described in [RFC5885]. One of the VCCV profiles described in Section 3.1 or Section 3.2 MUST be used. Once a VCCV control channel is provisioned and the operational status of the PW is UP, no other profile should be used until such time as the PW's operational status is set to DOWN.
此外，当使用MPLS实现等成本多路径（ECMP）功能时，应避免使用标签堆栈作为路径选择器，使得OAM和数据不在共同路径中，因为数据路径中的任何故障都不会反映在OAM路径中。因此，在PW标签下方的数据路径中携带的OAM（例如虚拟电路连接验证（VCCV））不易受到上述故障模式的影响。由于这些原因，OAM机制如[RFC5085]所述，它使用双向转发检测（BFD）[RFC5880]进行连接验证（CV）。[RFC5885]中描述了在VCCV中使用BFD作为CV方法的方法。必须使用第3.1节或第3.2节中描述的VCCV配置文件之一。一旦提供VCCV控制通道，并且PW的运行状态为UP，则在PW的运行状态设置为DOWN之前，不得使用其他配置文件。
When PE1 and PE2 are not IP capable or have not been configured with IP addresses, the following VCCV mechanism SHOULD be used.
当PE1和PE2不支持IP或未配置IP地址时，应使用以下VCCV机制。
The connection verification method used by VCCV is BFD with diagnostics as defined in [RFC5885].
VCCV使用的连接验证方法是BFD，诊断见[RFC5885]。
[RFC5085] specifies that the first nibble is set to 0x1 to indicate a channel associated with a pseudowire [RFC4385].
[RFC5085]指定将第一个半字节设置为0x1，以指示与伪线[RFC4385]关联的通道。
The Version and the Reserved fields are set to zero, and the Channel Type is set to 0x7 to indicate that the payload carried is BFD without IP/UDP headers, as is defined in [RFC5885].
版本和保留字段设置为零，通道类型设置为0x7，以指示所携带的有效负载为BFD，不带IP/UDP标头，如[RFC5885]中所定义。
When PE1 and PE2 are IP capable and have been configured with IP addresses, the following VCCV mechanism may be used.
当PE1和PE2具有IP能力且已配置IP地址时，可使用以下VCCV机制。
The connection verification method used by VCCV is BFD with diagnostics as defined in [RFC5885].
VCCV使用的连接验证方法是BFD，诊断见[RFC5885]。
[RFC5085] specifies that the first nibble is set to 0x1 to indicate a channel associated with a pseudowire [RFC4385].
[RFC5085]指定将第一个半字节设置为0x1，以指示与伪线[RFC4385]关联的通道。
The Version and the Reserved fields are set to 0, and the Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads [RFC4446].
版本和保留字段设置为0，通道类型设置为0x21（IPv4）和0x56（IPv6有效负载）[RFC4446]。
The architecture of MPLS-enabled networks is described in [RFC3031]. This section describes a subset of the functionality of the MPLS-enabled PSN. There are two cases that need to be considered:
[RFC3031]中描述了支持MPLS的网络的体系结构。本节描述启用MPLS的PSN功能的子集。有两种情况需要考虑：
1. The case where external configuration is used.
1. 使用外部配置的情况。
2. The case where a control plane is available.
2. 控制平面可用的情况。
Where the use of a control plane is desired, this may be based on Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945].
如果需要使用控制平面，这可以基于通用多协议标签交换（GMPLS）[RFC3945]。
The use of external provisioning is not precluded from being supported by the current MPLS specifications. It is however explicitly described in this specification to address the
当前MPLS规范并不排除使用外部资源调配。然而，本规范中明确描述了这一点，以解决以下问题：
requirements specified by the ITU [RFC5654] to address the needs in a transport environment.
ITU[RFC5654]规定的满足传输环境需求的要求。
The MPLS encapsulation is specified in [RFC3032]. All MPLS labels used in the server layer (Figure 1) MUST be statically provisioned. Labels may be selected from either the per-platform or the per-interface label space.
[RFC3032]中规定了MPLS封装。服务器层（图1）中使用的所有MPLS标签都必须静态配置。可以从每个平台或每个接口标签空间中选择标签。
All transport Label Switched Paths (LSPs) utilized by the PWs described in Section 2 MUST support both unidirectional and bidirectional point-to-point connections.
第2节所述PWs使用的所有传输标签交换路径（LSP）必须支持单向和双向点到点连接。
The transport LSPs SHOULD support unidirectional point-to-multipoint connections.
传输LSP应支持单向点对多点连接。
The forward and backward directions of a bidirectional connection SHOULD follow a symmetrically routed (reciprocal) LSP in the server network.
双向连接的前向和后向应遵循服务器网络中的对称路由（互惠）LSP。
Equal Cost Multipath (ECMP) load balancing MUST NOT be configured on the transport LSPs utilized by the PWs described in Section 2.
不得在第2节所述PWs使用的传输LSP上配置等成本多路径（ECMP）负载平衡。
The merging of Label Switched Paths is prohibited and MUST NOT be configured for the transport LSPs utilized by the PWs described in Section 2.
禁止合并标签交换路径，且不得为第2节所述PWs使用的传输LSP配置。
Penultimate hop popping by the transport Label Switched Routers (LSRs) MUST be disabled on transport LSPs.
传输标签交换路由器（LSR）的倒数第二跳弹出必须在传输LSP上禁用。
Both EXP-Inferred-PSC LSPs (E-LSP) and Label-Only-Inferred-PSC LSPs (L-LSP) MUST be supported as defined in [RFC3270].
EXP推断的PSC LSP（E-LSP）和Label-Only推断的PSC LSP（L-LSP）必须按照[RFC3270]中的定义得到支持。
For the MPLS EXP field [RFC3270] [RFC5462], only the pipe and short-pipe models are supported.
对于MPLS EXP字段[RFC3270][RFC5462]，仅支持管道和短管模型。
In this section, we describe the control plane configuration when [RFC3209] or the bidirectional support in GMPLS ([RFC3471] and [RFC3473]) are used to configure the transport MPLS PSN. When these protocols are used to provide the control plane, the following are automatically provided:
在本节中，我们描述了使用[RFC3209]或GMPLS中的双向支持（[RFC3471]和[RFC3473]）配置传输MPLS PSN时的控制平面配置。当这些协议用于提供控制平面时，将自动提供以下内容：
1. There is no label merging unless it is deliberately enabled to support Fast Re-route (FRR) [RFC3209].
1. 除非有意启用标签合并以支持快速重路由（FRR）[RFC3209]，否则不会进行标签合并。
2. A single path is provided end-to-end (there is no ECMP).
2. 提供端到端的单一路径（没有ECMP）。
3. Label Switched Paths may be unidirectional or bidirectional as required.
3. 标签交换路径可以是单向的，也可以是双向的。
Additionally, the following configuration restrictions required to support external configuration MUST be applied:
此外，必须应用以下支持外部配置所需的配置限制：
o Penultimate hop popping [RFC3031] by the LSRs MUST be disabled on LSPs providing PWE3 transport network functionality.
o 必须在提供PWE3传输网络功能的LSP上禁用LSR的倒数第二跳弹出[RFC3031]。
o Both E-LSP and L-LSP MUST be supported as defined in [RFC3270].
o 必须按照[RFC3270]中的定义支持E-LSP和L-LSP。
o The MPLS EXP [RFC5462] field is supported according to [RFC3270] only when the pipe and short-pipe models are utilized.
o 根据[RFC3270]，仅当使用管道和短管模型时，才支持MPLS EXP[RFC5462]字段。
This document describes a method of using the existing PWE3 Ethernet pseudowire [RFC4448] to solve a particular network application. The congestion considerations associated with that pseudowire and all subsequent work on congestion considerations regarding Ethernet pseudowires are applicable to this RFC.
本文档描述了使用现有PWE3以太网伪线[RFC4448]解决特定网络应用的方法。与该伪线相关的拥塞注意事项以及关于以太网伪线的拥塞注意事项的所有后续工作均适用于该RFC。
This RFC provides a description of the use of existing IETF Proposed Standards to solve a network problem, and raises no new security issues.
本RFC描述了如何使用现有IETF提议的标准来解决网络问题，并且没有提出新的安全问题。
The PWE3 security considerations are described in [RFC3985] and the Ethernet pseudowire security considerations of [RFC4448].
[RFC3985]中描述了PWE3安全注意事项，[RFC4448]中描述了以太网伪线安全注意事项。
The Ethernet pseudowire is transported on an MPLS PSN; therefore, the security of the pseudowire itself will only be as good as the security of the MPLS PSN. The server MPLS PSN can be secured by various methods, as described in [RFC3031].
以太网伪线在MPLS PSN上传输；因此，伪线本身的安全性将只与MPLS PSN的安全性一样好。如[RFC3031]所述，服务器MPLS PSN可以通过各种方法进行保护。
The use of static configuration exposes an MPLS PSN to a different set of security risks to those found in a PSN using dynamic routing. If a path is misconfigured in a statically configured network, the result can be a persistent black hole, or much worse, a persistent forwarding loop. On the other hand, most of the distributed components are less complex. This is however offset by the need to provide fail-over and redundancy in the management and configuration system and the communications paths between those central systems and the LSRs.
使用静态配置会使MPLS PSN面临与使用动态路由的PSN不同的安全风险。如果路径在静态配置的网络中被错误配置，结果可能是一个持久的黑洞，或者更糟糕的是，一个持久的转发循环。另一方面，大多数分布式组件不那么复杂。然而，需要在管理和配置系统以及这些中央系统和LSR之间的通信路径中提供故障切换和冗余，这一点被抵消了。
Security achieved by access control of media access control (MAC) addresses, and the security of the client layers, is out of the scope of this document.
通过媒体访问控制（MAC）地址的访问控制实现的安全性以及客户端层的安全性不在本文档的范围内。
The authors wish to thank Matthew Bocci, John Drake, Adrian Farrel, Andy Malis, and Yaakov Stein for their review and proposed enhancements to the text.
作者希望感谢Matthew Bocci、John Drake、Adrian Farrel、Andy Malis和Yaakov Stein对文本的审查和改进建议。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年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月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年6月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
Authors' Addresses
作者地址
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park Reading RG2 6GB UK
Stewart Bryant（编辑）思科系统250，绿色公园朗沃特阅读RG2 6GB英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Monique Morrow Cisco Systems Glatt-com CH-8301 Glattzentrum Switzerland
Monique Morrow Cisco Systems Glatt com CH-8301 Glattzentrum Switzerland
EMail: mmorrow@cisco.com
EMail: mmorrow@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719
马萨诸塞州伯斯堡马萨诸塞大道1414号George Swallow思科系统公司，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Rao Cherukuri Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: cherukuri@juniper.net
EMail: cherukuri@juniper.net
Thomas D. Nadeau Huawei Technologies Central Expressway Santa Clara, CA 95050
托马斯·纳多华为技术中心高速公路加利福尼亚州圣克拉拉95050
EMail: thomas.nadeau@huawei.com
EMail: thomas.nadeau@huawei.com
Neil Harrison BT
尼尔·哈里森英国电信公司
EMail: neil.2.harrison@bt.com
EMail: neil.2.harrison@bt.com
Ben Niven-Jenkins Velocix 326 Science Park Milton Road, Cambridge CB4 0WG UK
英国剑桥CB4 0WG米尔顿路科学园326号Ben Niven Jenkins Velocix
EMail: ben@niven-jenkins.co.uk
EMail: ben@niven-jenkins.co.uk