Network Working Group X. Xiao, Ed.
Request for Comments: 3916 Riverstone Networks
Category: Informational D. McPherson, Ed.
Arbor Networks
P. Pate, Ed.
Overture Networks
September 2004
Network Working Group X. Xiao, Ed.
Request for Comments: 3916 Riverstone Networks
Category: Informational D. McPherson, Ed.
Arbor Networks
P. Pate, Ed.
Overture Networks
September 2004
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
伪线仿真边到边（PWE3）的要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.
本文件描述了伪导线仿真边到边工作组（PWE3 WG）的基本要求。它为其他工作组文件提供了指南，这些文件将定义提供以太网、ATM和帧中继的伪线仿真的机制。TDM（即“以ITU G.702定义的速率同步比特流”）的伪线仿真要求在另一份文件中定义。应该注意的是，PWE3工作组标准化了可用于提供PWE3服务的机制，而不是服务本身。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Are Pseudo Wires?. . . . . . . . . . . . . . . . . 2
1.2. Current Network Architecture. . . . . . . . . . . . . . 3
1.3. PWE3 as a Path to Convergence . . . . . . . . . . . . . 4
1.4. Suitable Applications for PWE3. . . . . . . . . . . . . 4
1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Model of PWE3 . . . . . . . . . . . . . . . . . . . 6
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Frame Ordering. . . . . . . . . . . . . . . . . . . . . 8
4.3. Frame Duplication . . . . . . . . . . . . . . . . . . . 8
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Are Pseudo Wires?. . . . . . . . . . . . . . . . . 2
1.2. Current Network Architecture. . . . . . . . . . . . . . 3
1.3. PWE3 as a Path to Convergence . . . . . . . . . . . . . 4
1.4. Suitable Applications for PWE3. . . . . . . . . . . . . 4
1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Model of PWE3 . . . . . . . . . . . . . . . . . . . 6
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Frame Ordering. . . . . . . . . . . . . . . . . . . . . 8
4.3. Frame Duplication . . . . . . . . . . . . . . . . . . . 8
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Consideration of Per-PSN Packet Overhead. . . . . . . . 9
5. Maintenance of Emulated Services. . . . . . . . . . . . . . . 9
5.1. Setup and Teardown of Pseudo-Wires. . . . . . . . . . . 9
5.2. Handling Maintenance Message of the Native Services . . 10
5.3. PE-initiated Maintenance Messages . . . . . . . . . . . 10
6. Management of Emulated Services . . . . . . . . . . . . . . . 12
6.1. MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. General MIB Requirements. . . . . . . . . . . . . . . . 12
6.3. Configuration and Provisioning. . . . . . . . . . . . . 13
6.4. Performance Monitoring. . . . . . . . . . . . . . . . . 13
6.5. Fault Management and Notifications. . . . . . . . . . . 13
6.6. Pseudo-Wire Connection Verification and Traceroute. . . 13
7. Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
7.1. Characteristics of an Emulated Service. . . . . . . . . 14
7.2. Service Quality of Emulated Services. . . . . . . . . . 14
8. Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
9. Quality of Service (QoS) Considerations . . . . . . . . . . . 15
10. Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References. . . . . . . . . . . . . . . . . . 17
13.2. Informative References. . . . . . . . . . . . . . . . . 17
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
4.5. Consideration of Per-PSN Packet Overhead. . . . . . . . 9
5. Maintenance of Emulated Services. . . . . . . . . . . . . . . 9
5.1. Setup and Teardown of Pseudo-Wires. . . . . . . . . . . 9
5.2. Handling Maintenance Message of the Native Services . . 10
5.3. PE-initiated Maintenance Messages . . . . . . . . . . . 10
6. Management of Emulated Services . . . . . . . . . . . . . . . 12
6.1. MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. General MIB Requirements. . . . . . . . . . . . . . . . 12
6.3. Configuration and Provisioning. . . . . . . . . . . . . 13
6.4. Performance Monitoring. . . . . . . . . . . . . . . . . 13
6.5. Fault Management and Notifications. . . . . . . . . . . 13
6.6. Pseudo-Wire Connection Verification and Traceroute. . . 13
7. Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
7.1. Characteristics of an Emulated Service. . . . . . . . . 14
7.2. Service Quality of Emulated Services. . . . . . . . . . 14
8. Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
9. Quality of Service (QoS) Considerations . . . . . . . . . . . 15
10. Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References. . . . . . . . . . . . . . . . . . 17
13.2. Informative References. . . . . . . . . . . . . . . . . 17
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that emulates the essential attributes of a service such as ATM, Frame Relay or Ethernet over a Packet Switched Network (PSN). The required functions of PWs include encapsulating service-specific PDUs arriving at an ingress port, and carrying them across a path or tunnel, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as faithfully as possible.
伪线模拟边到边（PWE3）是一种通过分组交换网络（PSN）模拟ATM、帧中继或以太网等服务基本属性的机制。PWs所需的功能包括封装到达入口端口的特定于服务的PDU，并将其穿过路径或隧道，管理其时序和顺序，以及尽可能忠实地模拟服务的行为和特征所需的任何其他操作。
From the customer perspective, the PW is perceived as an unshared link or circuit of the chosen service. However, there may be deficiencies that impede some applications from being carried on a PW. These limitations should be fully described in the appropriate service-specific documents and Applicability Statements.
从客户的角度来看，PW被视为所选服务的非共享链路或电路。然而，可能存在妨碍某些应用程序在PW上进行的缺陷。这些限制应在适当的服务特定文件和适用性声明中充分说明。
The following sections give some background on where networks are today and why they are changing. It also talks about the motivation to provide converged networks while continuing to support existing services. Finally, it discusses how PWs can be a solution for this dilemma.
以下各节介绍了网络的现状以及网络变化的原因。它还讨论了在继续支持现有服务的同时提供融合网络的动机。最后，讨论了PWs如何解决这一困境。
For any given service provider delivering multiple services, the current infrastructure usually consists of parallel or "overlay" networks. Each of these networks implements a specific service, such as Frame Relay, Internet access, etc. This is expensive, both in terms of capital expense and operational costs. Furthermore, the presence of multiple networks complicates planning. Service providers wind up asking themselves these questions:
对于提供多种服务的任何给定服务提供商，当前的基础设施通常由并行或“覆盖”网络组成。这些网络中的每一个都实现特定的服务，如帧中继、互联网接入等。这在资本费用和运营成本方面都很昂贵。此外，多个网络的存在使规划复杂化。服务提供商最终会问自己以下问题：
- Which of my networks do I build out? - How many fibers do I need for each network? - How do I efficiently manage multiple networks?
- 我应该建立哪些人际网络每个网络需要多少光纤？-如何有效地管理多个网络？
A converged network helps service providers answer these questions in a consistent and economical fashion.
融合网络帮助服务提供商以一致且经济的方式回答这些问题。
In order to maximize return on their assets and minimize their operating costs, service providers often look to consolidate the delivery of multiple service types onto a single networking technology.
为了实现资产回报最大化和运营成本最小化，服务提供商通常希望将多种服务类型的交付整合到一种网络技术上。
As packet traffic takes up a larger and larger portion of the available network bandwidth, it becomes increasingly useful to optimize public networks for the Internet Protocol. However, many service providers are confronting several obstacles in engineering packet-optimized networks. Although Internet traffic is the fastest growing traffic segment, it does not generate the highest revenue per bit. For example, Frame Relay traffic currently generates higher revenue per bit than native IP services do. Private line TDM services still generate even more revenue per bit than does Frame Relay. In addition, there is a tremendous amount of legacy equipment deployed within public networks that does not communicate using the Internet Protocol. Service providers continue to utilize non-IP equipment to deploy a variety of services, and see a need to interconnect this legacy equipment over their IP-optimized core networks.
由于数据包流量占用了越来越多的可用网络带宽，因此为Internet协议优化公共网络变得越来越有用。然而，许多服务提供商在设计包优化网络时面临着一些障碍。虽然互联网流量是增长最快的流量细分市场，但它不会产生最高的每比特收入。例如，帧中继通信目前比本机IP服务产生更高的每比特收入。专线TDM服务仍然比帧中继产生更多的每比特收入。此外，在公共网络中部署了大量传统设备，这些设备不使用互联网协议进行通信。服务提供商继续利用非IP设备部署各种服务，并认为有必要通过其IP优化的核心网络互连这些传统设备。
How do service providers realize the capital and operational benefits of a new packet-based infrastructure, while leveraging the existing equipment and also protecting the large revenue stream associated with this equipment? How do they move from mature Frame Relay or ATM networks, while still being able to provide these lucrative services?
服务提供商如何实现新的基于数据包的基础设施的资本和运营效益，同时利用现有设备并保护与此设备相关的大量收入流？他们如何从成熟的帧中继或ATM网络中转移，同时仍然能够提供这些有利可图的服务？
One possibility is the emulation of circuits or services via PWs. Circuit emulation over ATM and interworking of Frame Relay and ATM have already been standardized. Emulation allows existing services to be carried across the new infrastructure, and thus enables the interworking of disparate networks.
一种可能性是通过PWs模拟电路或服务。ATM上的电路仿真以及帧中继和ATM的互通已经标准化。仿真允许在新的基础设施上承载现有服务，从而实现不同网络的互通。
Implemented correctly, PWE3 can provide a means for supporting today's services over a new network.
通过正确实施，PWE3可以提供一种通过新网络支持当前服务的方法。
What makes an application suitable (or not) for PWE3 emulation? When considering PWs as a means of providing an application, the following questions must be considered:
什么使应用程序适合（或不适合）PWE3仿真？当考虑将PWs作为提供申请的手段时，必须考虑以下问题：
- Is the application sufficiently deployed to warrant emulation? - Is there interest on the part of service providers in providing an emulation for the given application? - Is there interest on the part of equipment manufacturers in providing products for the emulation of a given application? - Are the complexities and limitations of providing an emulation worth the savings in capital and operational expenses?
- 应用程序是否已充分部署以保证仿真服务提供商是否有兴趣为给定的应用程序提供仿真设备制造商是否有兴趣提供用于模拟给定应用的产品提供模拟的复杂性和局限性是否值得节省资本和运营费用？
If the answer to all four questions is "yes", then the application is likely to be a good candidate for PWE3. Otherwise, there may not be sufficient overlap between the customers, service providers, equipment manufacturers and technology to warrant providing such an emulation.
如果这四个问题的答案都是“是”，那么该应用程序很可能是PWE3的一个很好的候选人。否则，客户、服务提供商、设备制造商和技术之间可能没有足够的重叠来保证提供此类仿真。
To maximize the return on their assets and minimize their operational costs, many service providers are looking to consolidate the delivery of multiple service offerings and traffic types onto a single IP-optimized network.
为了最大限度地提高资产回报率和降低运营成本，许多服务提供商正在寻求将多种服务产品和流量类型的交付整合到一个IP优化的网络上。
In order to create this next-generation converged network, standard methods must be developed to emulate existing telecommunications
为了创建下一代融合网络，必须开发标准方法来模拟现有的电信系统
formats such as Ethernet, Frame Relay, and ATM over IP-optimized core networks. This document describes requirements for accomplishing this goal.
以太网、帧中继和ATM over IP优化核心网络等格式。本文件描述了实现该目标的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“SHALLNOT”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Some terms used throughout this document are listed below.
本文件中使用的一些术语如下所示。
Attachment Circuit (AC) The physical or virtual circuit attaching a CE to a PE. An AC can be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC link, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc.
连接电路（AC）将CE连接到PE的物理或虚拟电路。AC可以是帧中继DLCI、ATM VPI/VCI、以太网端口、VLAN、HDLC链路、物理接口上的PPP连接、L2TP隧道中的PPP会话、MPLS LSP等。
Customer Edge (CE) A device where one end of a service originates and/or terminates. The CE is not aware that it is using an emulated service rather than a native service.
客户边缘（CE）服务一端发起和/或终止的设备。CE不知道它正在使用模拟服务而不是本机服务。
Packet Switched Network (PSN) Within the context of PWE3, this is a network using IP or MPLS as the mechanism for packet forwarding.
分组交换网络（PSN）在PWE3的上下文中，这是一个使用IP或MPLS作为分组转发机制的网络。
Provider Edge (PE) A device that provides PWE3 to a CE.
提供商边缘（PE）向CE提供PWE3的设备。
Pseudo Wire (PW) A mechanism that carries the essential elements of an emulated circuit from one PE to another PE over a PSN.
伪线（PW）通过PSN将模拟电路的基本元件从一个PE传输到另一个PE的机制。
Pseudo Wire Emulation Edge to Edge (PWE3) A mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN.
伪线模拟边到边（PWE3）一种机制，通过PSN模拟服务（如T1专线或帧中继）的基本属性。
Pseudo Wire PDU A Protocol Data Unit (PDU) sent on the PW that contains all of the data and control information necessary to emulate the desired service.
伪线PDU在PW上发送的协议数据单元（PDU），包含模拟所需服务所需的所有数据和控制信息。
PSN Tunnel A tunnel across a PSN inside which one or more PWs can be carried.
PSN隧道穿过PSN的隧道，其中可承载一个或多个PW。
A pseudo-wire (PW) is a connection between two provider edge (PE) devices which connects two attachment circuits (ACs). An AC can be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC link, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc.
伪线（PW）是连接两个连接两个连接电路（ACs）的两个提供商边缘（PE）设备之间的连接。AC可以是帧中继DLCI、ATM VPI/VCI、以太网端口、VLAN、HDLC链路、物理接口上的PPP连接、L2TP隧道中的PPP会话、MPLS LSP等。
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | |==================| | +-----+
^ | +----+ +----+ ^
| | Provider Edge 1 Provider Edge 2 |
| | |
| Attachment Circuit |
| |
|<-------------- Emulated Service ---------------->|
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | |==================| | +-----+
^ | +----+ +----+ ^
| | Provider Edge 1 Provider Edge 2 |
| | |
| Attachment Circuit |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer Edge 1 Edge 2
客户边缘1边缘2
Figure 1: PWE3 Reference Model
图1:PWE3参考模型
During the setup of a PW, the two PEs will be configured or will automatically exchange information about the service to be emulated so that later they know how to process packets coming from the other end. After a PW is set up between two PEs, frames received by one PE from an AC are encapsulated and sent over the PW to the remote PE, where native frames are re-constructed and forwarded to the other CE. For a detailed PWE3 architecture overview, readers should refer to the PWE3 architecture document [PWE3_ARCH].
在PW的设置过程中，两个PE将被配置或自动交换有关要模拟的服务的信息，以便以后它们知道如何处理来自另一端的数据包。在两个PE之间建立PW之后，一个PE从AC接收的帧被封装并通过PW发送到远程PE，其中本地帧被重新构造并转发到另一个CE。有关详细的PWE3体系结构概述，读者应参考PWE3体系结构文档[PWE3_ARCH]。
This document does not assume that a particular type of PWs (e.g., [L2TPv3] sessions or [MPLS] LSPs) or PSNs (e.g., IP or MPLS) is used. Instead, it describes generic requirements that apply to all PWs and PSNs, for all services including Ethernet, ATM, and Frame Relay, etc.
本文档不假设使用特定类型的PWs（例如，[L2TPv3]会话或[MPLS]LSP）或PSN（例如，IP或MPLS）。相反，它描述了适用于所有PWs和PSN的通用要求，适用于所有服务，包括以太网、ATM和帧中继等。
This section describes data plane requirements for PWE3.
本节描述了PWE3的数据平面要求。
Every PE MUST provide an encapsulation mechanism for PDUs from an AC. It should be noted that the PDUs to be encapsulated may or may not contain L2 header information. This is service specific. Every PWE3 service MUST specify what the PDU is.
每个PE必须为来自AC的PDU提供封装机制。应注意，要封装的PDU可能包含也可能不包含L2报头信息。这是特定于服务的。每个PWE3服务必须指定PDU是什么。
A PW header consists of all the header fields in a PW PDU that are used by the PW egress to determine how to process the PDU. The PSN tunnel header is not considered as part of the PW header.
PW报头由PW PDU中的所有报头字段组成，PW出口使用这些字段来确定如何处理PDU。PSN隧道集管不被视为PW集管的一部分。
Specific requirements on PDU encapsulation are listed below.
PDU封装的具体要求如下所示。
The egress of a PW needs some information, e.g., which native service the PW PDUs belong to, and possibly some L2 header information, in order to know how to process the PDUs received. A PWE3 encapsulation approach MUST provide some mechanism for conveying such information from the PW ingress to the egress. It should be noted that not all such information must be carried in the PW header of the PW PDUs. Some information (e.g., service type of a PW) can be stored as state information at the egress during PW setup.
PW的出口需要一些信息，例如，PW PDU属于哪个本机服务，并且可能需要一些L2报头信息，以便知道如何处理接收到的PDU。PWE3封装方法必须提供某种机制，用于将此类信息从PW入口传输到出口。应注意的是，并非所有此类信息都必须包含在PW PDU的PW标题中。在PW设置期间，一些信息（例如PW的服务类型）可以作为状态信息存储在出口处。
A PWE3 approach MUST accommodate variable length PDUs, if variable length PDUs are allowed by the native service. For example, a PWE3 approach for Frame Relay MUST accommodate variable length frames.
如果本机服务允许可变长度PDU，则PWE3方法必须适应可变长度PDU。例如，帧中继的PWE3方法必须适应可变长度帧。
If a service in its native form is capable of grouping multiple circuits into a "trunk", e.g., multiple ATM VCCs in a VPC or multiple Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be provided so that a single PW can be used to connect two end-trunks. From encapsulation perspective, sufficient information MUST be carried so that the egress of the PW can demultiplex individual circuits from the PW.
如果本机形式的服务能够将多个电路分组为一个“中继”，例如，VPC中的多个ATM VCC或端口中的多个以太网802.1Q接口，则应提供某种机制，以便使用单个PW连接两个终端中继。从封装的角度来看，必须携带足够的信息，以便PW的出口能够将单个电路从PW解复用。
Most L2 frames have a checksum field to assure frame integrity. Every PWE3 service MUST specify whether the frame's checksum should be preserved across the PW, or should be removed at the ingress PE and then be re-calculated and inserted at the egress PE. For protocols such as ATM and FR, the checksum covers link-local information such as the circuit identifiers (e.g., FR DLCI or ATM VPI/VCI). Therefore, such checksum MUST be removed at the ingress PE and recalculated at the egress PE.
大多数L2帧都有一个校验和字段，以确保帧的完整性。每个PWE3服务必须指定帧的校验和是应在整个PW中保留，还是应在入口PE处移除，然后重新计算并插入出口PE。对于诸如ATM和FR之类的协议，校验和覆盖链路本地信息，例如电路标识符（例如，FR DLCI或ATM VPI/VCI）。因此，必须在入口PE处移除此类校验和，并在出口PE处重新计算。
Under some circumstances, it is desirable to be able to distinguish PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN, this additional distinguishability can be used to reduce the chance that PW packets get misordered by the load balancing mechanism. Some mechanism SHOULD provide this distinguishability if needed. Such mechanism MAY be defined in the PWE3 WG or other WGs.
在某些情况下，希望能够将PW流量与其他类型的流量（如IPv4、IPv6或OAM）区分开来。例如，如果在PSN中采用等成本多路径（ECMP），则该额外的可分辨性可用于减少PW分组被负载平衡机制误序的机会。如果需要，某些机制应该提供这种区分性。此类机制可在PWE3工作组或其他工作组中定义。
When packets carrying the PW PDUs traverse a PW, they may arrive at the egress out of order. For some services, the frames (either control frames only or both control and data frames) must be delivered in order. For such services, some mechanism MUST be provided for ensuring in-order delivery. Providing a sequence number in the PW header for each packet is one possible approach to detect out-of-order frames. Mechanisms for re-ordering frames may be provided by Native Service Processing (NSP) [PWE3_ARCH] but are out of scope of PWE3.
当携带PW PDU的数据包穿过PW时，它们可能会无序到达出口。对于某些服务，必须按顺序交付帧（仅控制帧或控制帧和数据帧）。对于此类服务，必须提供某种机制来确保有序交付。在PW报头中为每个分组提供序列号是检测无序帧的一种可能方法。用于重新排序帧的机制可以由本机服务处理（NSP）[PWE3_ARCH]提供，但不在PWE3的范围内。
In rare cases, packets traversing a PW may be duplicated. For some services, frame duplication is not allowed. For such services some mechanism MUST be provided to ensure that duplicated frames will not be delivered. The mechanism may or may not be the same as the mechanism used to ensure in-order frame delivery.
在极少数情况下，穿过PW的数据包可能被复制。对于某些服务，不允许帧复制。对于此类服务，必须提供一些机制以确保不会交付重复的帧。该机制可能与用于确保有序框架交付的机制相同，也可能不同。
If the combined size of the L2 payload and its associated PWE3 and PSN headers exceeds the PSN path MTU, the L2 payload may need to be fragmented (Alternatively the L2 frame may be dropped). For certain native service, fragmentation may also be needed to maintain a control frame's relative position to the data frames (e.g., an ATM PM
如果二级有效载荷及其相关联的PWE3和PSN报头的组合大小超过PSN路径MTU，则二级有效载荷可能需要分段（或者二级帧可能被丢弃）。对于某些本机服务，还可能需要分段来维持控制帧相对于数据帧的相对位置（例如，ATM PM）
cell's relative position). In general, fragmentation has a performance impact. It is therefore desirable to avoid fragmentation if possible. However, for different services, the need for fragmentation can be different. When there is potential need for fragmentation, each service-specific PWE3 document MUST specify whether to fragment the frame in question or to drop it. If an emulated service chooses to drop the frame, the consequence MUST be specified in its applicability statement.
单元的相对位置）。通常，碎片会影响性能。因此，如果可能，最好避免碎片化。但是，对于不同的服务，碎片化的需求可能不同。当可能需要分段时，每个特定于服务的PWE3文档必须指定是对有问题的帧进行分段还是删除它。如果模拟服务选择丢弃帧，则必须在其适用性语句中指定结果。
When the L2 PDU size is small, in order to reduce PSN tunnel header overhead, multiple PDUs MAY be concatenated before a PSN tunnel header is added. Each encapsulated PDU still carries its own PW header so that the egress PE knows how to process it. However, the benefit of concatenating multiple PDUs for header efficiency should be weighed against the resulting increase in delay, jitter and the larger penalty incurred by packet loss.
当L2 PDU大小较小时，为了减少PSN隧道报头开销，可以在添加PSN隧道报头之前连接多个PDU。每个封装的PDU仍然携带其自己的PW报头，以便出口PE知道如何处理它。然而，为了提高报头效率而连接多个PDU的好处应该与由此产生的延迟、抖动增加和丢包带来的更大惩罚进行权衡。
This section describes maintenance requirements for PWE3.
本节描述了PWE3的维护要求。
A PW must be set up before an emulated circuit can be established, and must be torn down when an emulated circuit is no longer needed. Setup and teardown of a PW can be triggered by a command from the management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
在建立仿真电路之前必须建立PW，并且在不再需要仿真电路时必须拆除PW。PW的设置和拆卸可通过来自PE管理平面的命令、AC（例如ATM SVC）的设置/拆卸或自动发现机制触发。
Every PWE3 approach MUST define some setup mechanism for establishing the PWs. During the setup process, the PEs need to exchange some information (e.g., to learn each other's capability). The setup mechanism MUST enable the PEs to exchange all necessary information. For example, both endpoints must agree on methods for encapsulating PDUs and handling frame ordering. Which signaling protocol to use and what information to exchange are service specific. Every PWE3 approach MUST specify them. Manual configuration of PWs can be considered as a special kind of signaling and is allowed.
每个PWE3方法必须定义一些建立PWs的设置机制。在设置过程中，PEs需要交换一些信息（例如，了解彼此的能力）。设置机制必须使PEs能够交换所有必要的信息。例如，两个端点必须就封装PDU和处理帧顺序的方法达成一致。要使用的信令协议和要交换的信息是特定于服务的。每个PWE3方法都必须指定它们。PWs的手动配置可被视为一种特殊的信令，是允许的。
If a native circuit is bi-directional, the corresponding emulated circuit can be signaled "Up" only when the associated PW and PSN tunnels in both directions are functional.
如果本机电路是双向的，则只有当两个方向上的相关PW和PSN隧道都正常工作时，相应的仿真电路才能发出“向上”信号。
Some native services have mechanisms for maintenance purpose, e.g., ATM OAM and FR LMI. Such maintenance messages can be in-band (i.e., mixed with data messages in the same AC) or out-of-band (i.e., sent in a dedicated control circuit). For such services, all in-band maintenance messages related to a circuit SHOULD be transported in-band just like data messages through the corresponding PW to the remote CE. In other words, no translation is needed at the PEs for in-band maintenance messages. In addition, it MAY be desirable to provide higher reliability for maintenance messages. The mechanisms for providing high reliability do not have to be defined in the PWE3 WG.
一些本机服务具有用于维护的机制，例如ATM OAM和FR LMI。此类维护消息可以是带内（即，与同一AC中的数据消息混合）或带外（即，在专用控制电路中发送）。对于此类服务，与电路相关的所有带内维护消息应在带内传输，就像数据消息一样，通过相应的PW传输到远程CE。换句话说，PEs不需要翻译带内维护消息。此外，可能希望为维护消息提供更高的可靠性。PWE3工作组中无需定义提供高可靠性的机制。
Out-of-band maintenance messages between a CE and a PE may relate to multiple ACs between the CE and the PE. They need to be processed at the local PE and possibly at the remote PE as well. If a native service has some out-of-band maintenance messages, the corresponding emulated service MUST specify how to process such messages at the PEs. In general, an out-of-band maintenance message is either translated into an in-band maintenance message of the native service or a PWE-specific maintenance message for every AC related to that out-of-band message. As an example, assume the ACs between a CE and a PE are some ATM VCCs inside a VPC. When a F4 AIS [UNI3.0] from the CE is received by the PE, the PE should translate that F4 AIS into a F5 AIS and send it to the remote CE for every VCC. Alternatively, the PE should generate a PWE-specific maintenance message (e.g., label withdrawal) to the remote PE for every VCC. When the remote PE receives such a PWE-specific maintenance message, it may need to generate a maintenance message of the native service and send it to the attached CE.
CE和PE之间的带外维护消息可能与CE和PE之间的多个AC有关。它们需要在本地PE上处理，也可能在远程PE上处理。如果本机服务具有一些带外维护消息，则相应的模拟服务必须指定如何在PEs处理此类消息。通常，带外维护消息被转换为本机服务的带内维护消息或与该带外消息相关的每个AC的PWE特定维护消息。例如，假设CE和PE之间的ACs是VPC内的一些ATM VCC。当PE接收到来自CE的F4 AIS[UNI3.0]时，PE应将该F4 AIS转换为F5 AIS，并针对每个VCC将其发送到远程CE。或者，PE应为每个VCC向远程PE生成特定于PWE的维护消息（例如，标签撤回）。当远程PE接收到这种特定于PWE的维护消息时，它可能需要生成本机服务的维护消息并将其发送给连接的CE。
A PE needs to initiate some maintenance messages under some circumstances without being triggered by any native maintenance messages from the CE. These circumstances are usually caused by fault, e.g., a PW failure in the PSN or a link failure between the CE and the PE.
PE在某些情况下需要启动一些维护消息，而不会被来自CE的任何本机维护消息触发。这些情况通常由故障引起，例如PSN中的PW故障或CE和PE之间的链路故障。
The reason the PEs need to initiate some maintenance messages under a fault condition is because the existence of a PW between two CEs would otherwise reduce the CEs' maintenance capability. This is illustrated in the following example. If two CEs are directly connected by a physical wire, a native service (e.g., ATM) can use notifications from the lower layer (e.g., the physical link layer) to
PEs需要在故障条件下启动一些维护消息的原因是，如果两个CE之间存在PW，则会降低CE的维护能力。下面的示例对此进行了说明。如果两个CE通过物理线路直接连接，则本机服务（例如ATM）可以使用来自较低层（例如物理链路层）的通知来
assist its maintenance. For example, an ATM PVC can be signaled "Down" if the physical wire fails. However, consider the following scenario.
协助维修。例如，如果物理线路发生故障，ATM PVC可以发出“停机”信号。但是，考虑下面的场景。
+-----+ Phy-link +----+ +----+ Phy-link +-----+
| CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+-----+ +----+ +----+ +-----+
+-----+ Phy-link +----+ +----+ Phy-link +-----+
| CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+-----+ +----+ +----+ +-----+
If the PW between PE1 and PE2 fails, CE1 and CE2 will not receive physical link failure notification. As a result, they cannot declare failure of the emulated circuit in a timely fashion, which will in turn affect higher layer applications. Therefore, when the PW fails, PE1 and PE2 need to initiate some maintenance messages to notify the client layer on CE1 and CE2 that use the PW as a server layer. (In this case, the client layer is the emulated service). Similarly, if the physical link between PE1-CE1 fails, PE1 needs to initiate some maintenance message(s) so that the client layer at CE2 will be notified. PE2 may need to be involved in this process.
如果PE1和PE2之间的PW发生故障，CE1和CE2将不会收到物理链路故障通知。因此，他们无法及时声明仿真电路的故障，这反过来会影响更高层的应用程序。因此，当PW出现故障时，PE1和PE2需要启动一些维护消息，以通知CE1和CE2上使用PW作为服务器层的客户机层。（在本例中，客户端层是模拟服务）。类似地，如果PE1-CE1之间的物理链路出现故障，PE1需要启动一些维护消息，以便通知CE2处的客户端层。PE2可能需要参与这一过程。
In the rare case when a physical wire between two CEs incurs many bit errors, the physical link can be declared "Down" and the client layer at the CEs be notified. Similarly, a PW can incur packet loss, corruption, and out-of-order delivery. These can be considered as "generalized bit error". Upon detection of excessive "generalized bit error", a PW can be declared "Down" and the detecting PE needs to initiate a maintenance message so that the client layer at the CE is notified.
在罕见的情况下，当两个CEs之间的物理线路发生许多位错误时，可以将物理链路声明为“关闭”，并通知CEs上的客户端层。类似地，PW可能导致数据包丢失、损坏和无序交付。这些可被视为“广义误码”。在检测到过多的“广义比特错误”时，可以将PW声明为“向下”，并且检测PE需要发起维护消息，以便通知CE处的客户端层。
In general, every emulated service MUST specify: * Under what circumstances PE-initiated maintenance messages are needed, * Format of the maintenance messages, and * How to process the maintenance messages at the remote PE.
通常，每个模拟服务必须指定：*在什么情况下需要PE启动的维护消息，*维护消息的格式，以及*如何在远程PE处理维护消息。
Some monitoring mechanisms are needed for detecting such circumstances, e.g., a PW failure. Such mechanisms can be defined in the PWE3 WG or elsewhere.
需要一些监测机制来检测此类情况，例如PW故障。此类机制可在PWE3工作组或其他地方定义。
Status of a group of emulated circuits may be affected identically by a single network incidence. For example, when the physical link between a CE and a PE fails, all the emulated circuits that go through that link will fail. It is desirable that a single maintenance message be used to notify failure of the whole group of emulated circuits connected to the same remote PE. A PWE3 approach MAY provide some mechanism for notifying status changes of a group of emulated circuits. One possible approach is to associate each
一组仿真电路的状态可能会受到单一网络关联的相同影响。例如，当CE和PE之间的物理链路出现故障时，通过该链路的所有仿真电路都将出现故障。希望使用单个维护消息来通知连接到同一远程PE的整个模拟电路组的故障。PWE3方法可以提供一些机制来通知一组仿真电路的状态变化。一种可能的方法是将每个
emulated circuit with a group ID while setting up the PW for that emulated circuit. In a maintenance message, that group ID can be used to refer to all the emulated circuits in that group.
为该仿真电路设置PW时，使用组ID创建仿真电路。在维护消息中，该组ID可用于引用该组中的所有仿真电路。
If a PE needs to generate and send a maintenance message to a CE, the PE MUST use a maintenance message of the native service. This is essential in keeping the emulated service transparent to the CEs.
如果PE需要生成维护消息并将其发送给CE，则PE必须使用本机服务的维护消息。这对于保持仿真服务对CEs透明至关重要。
The requirements stated in this section are aligned with the ITU-T maintenance philosophy for telecommunications networks [G805] (i.e., client layer/server layer concept).
本节所述要求与电信网络的ITU-T维护理念[G805]（即客户层/服务器层概念）一致。
Each PWE3 approach SHOULD provide some mechanisms for network operators to manage the emulated service. These mechanisms can be in the forms described below.
每种PWE3方法都应该为网络运营商提供一些机制来管理模拟服务。这些机制的形式如下所述。
SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit as well as pseudo-wire in general. These MIBs SHOULD be created with the following requirements.
必须提供SNMP MIB[SMIV2]来管理每个模拟电路以及一般的伪线。应按照以下要求创建这些MIB。
New MIBs MUST augment or extend where appropriate, existing tables as defined in other existing service-specific MIBs for existing services such as MPLS or L2TP. For example, the ifTable as defined in the Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-order packets. A second example is the extension of the MPLS-TE-MIB [TEMIB] when emulating circuit services over MPLS. Rather than redefining the tunnelTable so that PWE can utilize MPLS tunnels, for example, entries in this table MUST instead be extended to add additional PWE-specific objects. A final example might be to extend the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3- specific semantics when tunnels other than MPLS are used as PSN transport. Doing so facilitates a natural extension of those objects defined in the existing MIBs in terms of management, as well as leveraging existing agent implementations.
新的MIB必须在适当的情况下扩充或扩展现有表，如MPLS或L2TP等现有服务的其他现有特定于服务的MIB中定义的。例如，接口MIB[IFMIB]中定义的ifTable必须进行扩充，以提供无序数据包的计数。第二个例子是在MPLS上模拟电路服务时对MPLS-TE-MIB[TEMIB]的扩展。例如，与重新定义隧道表以便PWE可以利用MPLS隧道不同，必须扩展此表中的条目以添加额外的PWE特定对象。最后一个例子可能是扩展IP隧道MIB[IPTunnel MIB]，以便在将MPLS以外的隧道用作PSN传输时提供特定于PWE3的语义。这样做有助于在管理方面自然扩展现有MIB中定义的对象，并利用现有代理实现。
An AC MUST appear as an interface in the ifTable.
AC必须显示为ifTable中的接口。
MIB Tables MUST be designed to facilitate configuration and provisioning of the AC.
MIB表的设计必须便于AC的配置和供应。
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of ACs.
MIB必须有助于PSN内部配置和ACs监控。
MIBs MUST collect statistics for performance and fault management.
MIB必须收集性能和故障管理的统计信息。
MIBs MUST provide a description of how existing counters are used for PW emulation and SHOULD not replicate existing MIB counters.
MIB必须提供现有计数器如何用于PW仿真的说明，并且不应复制现有MIB计数器。
Notifications SHOULD be defined where appropriate to notify the network operators of any interesting situations, including faults detected in the AC.
应在适当情况下定义通知，以通知网络运营商任何感兴趣的情况，包括AC中检测到的故障。
Objects defined to augment existing protocol-specific notifications in order to add PWE functionality MUST explain how these notifications are to be emitted.
为添加PWE功能而定义的用于增强现有协议特定通知的对象必须解释如何发出这些通知。
For network management purpose, a connection verification mechanism SHOULD be supported by PWs. Connection verification as well as other alarming mechanisms can alert network operators that a PW has lost its remote connection. It is sometimes desirable to know the exact functional path of a PW for troubleshooting purpose, thus a traceroute function capable of reporting the path taken by data packets over the PW SHOULD be provided.
出于网络管理目的，PWs应支持连接验证机制。连接验证以及其他报警机制可以向网络运营商发出PW失去远程连接的警报。为了进行故障排除，有时需要知道PW的确切功能路径，因此应提供能够报告PW上数据包所走路径的跟踪路由功能。
An emulated service SHOULD be as similar to the native service as possible, but NOT REQUIRED to be identical. The applicability statement of a PWE3 service MUST report limitations of the emulated service.
模拟服务应尽可能类似于本机服务，但不要求完全相同。PWE3服务的适用性声明必须报告模拟服务的限制。
Some basic requirements on faithfulness of an emulated service are described below.
下面描述了模拟服务的忠实性的一些基本要求。
From the perspective of a CE, an emulated circuit is characterized as an unshared link or circuit of the chosen service, although service quality of the emulated service may be different from that of a native one. Specifically, the following requirements MUST be met:
从CE的角度来看，仿真电路的特征是所选服务的非共享链路或电路，尽管仿真服务的服务质量可能不同于本地服务的服务质量。具体而言，必须满足以下要求：
1) It MUST be possible to define type (e.g., Ethernet, which is inherited from the native service), speed (e.g., 100Mbps), and MTU size for an emulated circuit, if it is possible to do so for a native circuit.
1) 必须能够为模拟电路定义类型（例如，从本机服务继承的以太网）、速度（例如，100Mbps）和MTU大小（如果可以为本机电路定义）。
2) If the two endpoints CE1 and CE2 of emulated circuit #1 are connected to PE1 and PE2, respectively, and CE3 and CE4 of emulated circuit #2 are also connected to PE1 and PE2, then the PWs of these two emulated circuits may share the same physical paths between PE1 and PE2. But from each CE's perspective, its emulated circuit MUST appear as unshared. For example, CE1/CE2 MUST NOT be aware of existence of emulated circuit #2 or CE3/CE4.
2) 如果仿真电路#1的两个端点CE1和CE2分别连接到PE1和PE2，并且仿真电路#2的CE3和CE4也连接到PE1和PE2，则这两个仿真电路的PW可能在PE1和PE2之间共享相同的物理路径。但从每个CE的角度来看，其模拟电路必须显示为非共享。例如，CE1/CE2不得意识到仿真电路#2或CE3/CE4的存在。
3) If an emulated circuit fails (either at one of the ACs or in the middle of the PW), both CEs MUST be notified in a timely manner, if they will be notified in the native service (see Section 5.3 for more information). The definition of "timeliness" is service-dependent.
3) 如果仿真电路发生故障（无论是在ACS中还是在PW的中间），都必须及时通知两个CES，如果它们将在本机服务中得到通知（请参阅第5.3节以获取更多信息）。“及时性”的定义取决于服务。
4) If a routing protocol (e.g., IGP) adjacency can be established over a native circuit, it MUST be possible to be established over an emulated circuit as well.
4) 如果可以在本机电路上建立路由协议（例如，IGP）邻接，则也必须能够在仿真电路上建立该邻接。
It is NOT REQUIRED that an emulated service provide the same service quality as the native service. The PWE3 WG only defines mechanisms for providing PW emulation, not the services themselves. What quality to provide for a specific emulated service is a matter between a service provider (SP) and its customers, and is outside scope of the PWE3 WG.
模拟服务不需要提供与本机服务相同的服务质量。PWE3 WG只定义了提供PW仿真的机制，而不是服务本身。为特定的模拟服务提供什么样的质量是服务提供商（SP）及其客户之间的问题，不在PWE3工作组的范围之内。
Some non-requirements are mentioned in various sections of this document. Those work items are outside scope of the PWE3 WG. They are summarized below:
本文件各节中提到了一些非要求。这些工作项不在PWE3工作组的范围内。总结如下：
- Service interworking;
- 业务互通；
In Service Interworking, the IWF (Interworking Function) between two dissimilar protocols (e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM & L2TP, etc.) terminates the protocol used in one network and translates (i.e., maps) its Protocol Control Information (PCI) to the PCI of the protocol used in other network for User, Control and Management Plane functions to the extent possible.
在业务互通中，两个不同协议（如ATM和MPLS、帧中继和ATM、ATM和IP、ATM和L2TP等）之间的IWF（互通功能）终止一个网络中使用的协议，并将其协议控制信息（PCI）转换（即映射）为用户在另一个网络中使用的协议的PCI，尽可能控制和管理平面功能。
- Selection of a particular type of PWs;
- 选择特定类型的PWs；
- To make the emulated services perfectly match their native services;
- 使模拟服务与本地服务完全匹配；
- Defining mechanisms for signaling the PSN tunnels;
- 定义用于向PSN隧道发送信号的机制；
- Defining how to perform traffic management on packets that carry PW PDUs;
- 定义如何对携带PW PDU的数据包执行流量管理；
- Providing any multicast service that is not native to the emulated medium.
- 提供非模拟介质本机的任何多播服务。
To illustrate this point, Ethernet transmission to a multicast IEEE-48 address is considered in scope, while multicast services like [MARS] that are implemented on top of the medium are out of scope;
为了说明这一点，范围内考虑了到多播IEEE-48地址的以太网传输，而在介质顶部实现的多播服务（如[MARS]）超出了范围；
Some native services such as ATM can offer higher service quality than best effort Internet service. QoS is therefore essential for ensuring that emulated services are compatible (but not necessarily identical) to their native forms. It is up to network operators to decide how to provide QoS - They can choose to rely on over-provisioning and/or deploy some QoS mechanisms.
一些本地服务（如ATM）可以提供比尽力而为的Internet服务更高的服务质量。因此，QoS对于确保模拟服务与其本机形式兼容（但不一定完全相同）至关重要。由网络运营商决定如何提供QoS——他们可以选择依赖过度供应和/或部署一些QoS机制。
In order to take advantage of QoS mechanisms defined in other working groups, e.g., the traffic management schemes defined in DiffServ WG, it is desirable that some mechanisms exists for differentiating the packets resulted from PDU encapsulation. These mechanisms do not have to be defined in the PWE3 approaches themselves. For example, if the resulted packets are MPLS or IP packets, their EXP or DSCP field can be used for marking and differentiating. A PWE3 approach MAY provide guidelines for marking and differentiating.
为了利用其他工作组中定义的QoS机制，例如DiffServ WG中定义的流量管理方案，希望存在一些机制来区分PDU封装产生的分组。这些机制不必在PWE3方法中定义。例如，如果生成的数据包是MPLS或IP数据包，则其EXP或DSCP字段可用于标记和区分。PWE3方法可提供标记和区分的指南。
The applicability of PWE3 to a particular service depends on the sensitivity of that service (or the CE implementation) to delay/jitter etc and the ability of the application layer to mask them. PWE3 may not be applicable to services that have severe constraints in this respect.
PWE3对特定服务的适用性取决于该服务（或CE实现）对延迟/抖动等的敏感性以及应用层屏蔽它们的能力。PWE3可能不适用于在这方面有严重限制的服务。
PWE is a matter between the PW end-points and is transparent to the network devices between the PW end-points. Therefore, inter-domain PWE is fundamentally similar to intra-domain PWE. As long as PW end-points use the same PWE approach, they can communicate effectively, regardless of whether they are in the same domain. Security may become more important in the inter-domain case and some security measure such as end-point authentication MAY be applied. QoS may become more difficult to deliver too, as one service provider has no control over another service provider's provisioning and traffic management policy. To solve the inter-domain QoS problem, service providers have to cooperate. Once they agree at a contractual level to provider high quality of service to certain traffic (e.g., PWE traffic), the mechanisms defined in other working groups, e.g., Diffserv WG, can be used.
PWE是PW端点之间的问题，对PW端点之间的网络设备是透明的。因此，域间PWE与域内PWE基本相似。只要PW端点使用相同的PWE方法，它们就可以有效地通信，无论它们是否在同一领域。在域间情况下，安全性可能变得更加重要，并且可以应用一些安全措施，例如端点身份验证。QoS也可能变得更加难以提供，因为一个服务提供商无法控制另一个服务提供商的供应和流量管理策略。为了解决域间QoS问题，服务提供商必须进行合作。一旦他们在合同层面上同意向某些流量（如PWE流量）提供高质量服务，就可以使用其他工作组（如Diffserv WG）中定义的机制。
Inter-domain PSN tunnels are generally more difficult to set up, tear down and maintain than intra-domain ones. But that is an issue for PSN tunneling protocols such as MPLS and L2TPv3 and is outside the scope of PWE3.
域间PSN隧道通常比域内PSN隧道更难建立、拆除和维护。但这对于MPLS和L2TPv3等PSN隧道协议来说是一个问题，并且超出了PWE3的范围。
The PW end-point, PW demultiplexing mechanism, and the payloads of the native service can all be vulnerable to attack. PWE3 should leverage security mechanisms provided by the PW Demultiplexer or PSN Layers. Such mechanisms SHOULD protect PW end-point and PW Demultiplexer mechanism from denial-of-service (DoS) attacks and spoofing of the native data units. Preventing unauthorized access to PW end-points and other network devices is generally effective against DoS attacks and spoofing, and can be part of protection mechanism. Protection mechanisms SHOULD also address the spoofing of tunneled PW data. The validation of traffic addressed to the PW Demultiplexer end-point is paramount in ensuring integrity of PW encapsulation. Security protocols such as IPsec [RFC2401] can be used.
PW端点、PW解复用机制和本机服务的有效负载都容易受到攻击。PWE3应利用PW解复用器或PSN层提供的安全机制。此类机制应保护PW端点和PW解复用器机制免受拒绝服务（DoS）攻击和本机数据单元的欺骗。防止未经授权访问PW端点和其他网络设备通常对DoS攻击和欺骗有效，并且可以作为保护机制的一部分。保护机制还应解决隧道PW数据的欺骗问题。验证发送到PW解复用器端点的通信量对于确保PW封装的完整性至关重要。可以使用诸如IPsec[RFC2401]之类的安全协议。
The authors would like to acknowledge input from M. Aissaoui, M. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, and S. Vainshtein.
作者希望感谢M.Aissaoui、M.Bocci、S.Bryant、R.Cohen、N.Harrison、G.Heron、T.Johnson、A.Malis、L.Martini、E.Rosen、J.Rutemiller、T.So、Y.Stein和S.Vainstein的意见。
[IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[IFMIB]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[SMIV2]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息结构版本2（SMIV2）”，STD 58，RFC 2578，1999年4月。
[G805] "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, 2000.
[G805]“传输网络的通用功能架构”，ITU-T建议G.8052000。
[IPTUNMIB] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[IPTUNB]Thaler，D.，“IP隧道MIB”，RFC 2667，1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., "Layer Two Tunneling Protocol (Version 3)", Work in Progress, June 2004.
[L2TPv3]Lau，J.，Townsley，M.，和I.Goyret，等，“第二层隧道协议（版本3）”，正在进行的工作，2004年6月。
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[MARS]Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", Work in Progress, March 2004.
[PWE3_ARCH]S.Bryant和P.Pate等人，“PWE3架构”，正在进行的工作，2004年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[TEMIB]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Sept. 1993.
[UNI3.0]ATM论坛，“ATM用户网络接口规范3.0版”，1993年9月。
XiPeng Xiao (Editor) Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054
肖锡鹏（编辑）Riverstone Networks加利福尼亚州圣克拉拉大美洲公园路5200号，邮编95054
EMail: xxiao@riverstonenet.com
EMail: xxiao@riverstonenet.com
Danny McPherson (Editor) Arbor Networks
Danny McPherson（编辑）Arbor Networks
EMail: danny@arbor.net
EMail: danny@arbor.net
Prayson Pate (Editor) Overture Networks 507 Airport Boulevard, Suite 111 Morrisville, NC, USA 27560
Prayson Pate（编辑）序曲网络美国北卡罗来纳州莫里斯维尔机场大道507号111室27560
EMail: prayson.pate@overturenetworks.com
EMail: prayson.pate@overturenetworks.com
Vijay Gill AOL Time Warner
维杰·吉尔美国在线时代华纳
EMail: vijaygill9@aol.com
EMail: vijaygill9@aol.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Drive Boxborough, MA 01719 EMail: tnadeau@cisco.com
Thomas D.Nadeau Cisco Systems，Inc.马萨诸塞州Boxborough市比弗布鲁克大道300号电子邮件：tnadeau@cisco.com
Craig White Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
克雷格·怀特三层通信有限责任公司，埃尔多拉多大道1025号。科罗拉多州布鲁姆菲尔德，80021
EMail: Craig.White@Level3.com
EMail: Craig.White@Level3.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。