Internet Engineering Task Force (IETF) F. Jounay, Ed.
Request for Comments: 7338 Orange CH
Category: Informational Y. Kamite, Ed.
ISSN: 2070-1721 NTT Communications
G. Heron
Cisco Systems
M. Bocci
Alcatel-Lucent
September 2014
Internet Engineering Task Force (IETF) F. Jounay, Ed.
Request for Comments: 7338 Orange CH
Category: Informational Y. Kamite, Ed.
ISSN: 2070-1721 NTT Communications
G. Heron
Cisco Systems
M. Bocci
Alcatel-Lucent
September 2014
Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks
MPLS分组交换网络上点对多点伪线的要求和框架
Abstract
摘要
This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).
本文档提出了一组要求和一个框架，用于在MPLS分组交换网络上提供点对多点伪线（PW）。本文件中确定的要求与点对多点PW运行的架构、信号和维护方面有关。建议将其作为此类机制标准化的指导方针。在其他潜在应用中，点对多点PWs可用于优化多播层2服务（虚拟专用LAN服务和虚拟专用多播服务）的支持。
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/rfc7338.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7338.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Problem Statement ..........................................3
1.2. Scope of This Document .....................................4
1.3. Conventions Used in This Document ..........................4
2. Definitions .....................................................5
2.1. Acronyms ...................................................5
2.2. Terminology ................................................5
3. P2MP PW Requirements ............................................6
3.1. Reference Model ............................................6
3.2. P2MP PW and Underlying Layer ...............................7
3.3. P2MP PW Construction .......................................9
3.4. P2MP PW Signaling Requirements ............................10
3.4.1. P2MP PW Identifier .................................10
3.4.2. PW Type Mismatch ...................................10
3.4.3. Interface Parameters Sub-TLV .......................10
3.4.4. Leaf Grafting/Pruning ..............................10
3.4.5. Failure Detection and Reporting ....................11
3.4.6. Protection and Restoration .........................11
3.4.7. Scalability ........................................13
4. Backward Compatibility .........................................13
5. Security Considerations ........................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
7. Acknowledgments ................................................15
8. Contributors ...................................................16
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Scope of This Document .....................................4
1.3. Conventions Used in This Document ..........................4
2. Definitions .....................................................5
2.1. Acronyms ...................................................5
2.2. Terminology ................................................5
3. P2MP PW Requirements ............................................6
3.1. Reference Model ............................................6
3.2. P2MP PW and Underlying Layer ...............................7
3.3. P2MP PW Construction .......................................9
3.4. P2MP PW Signaling Requirements ............................10
3.4.1. P2MP PW Identifier .................................10
3.4.2. PW Type Mismatch ...................................10
3.4.3. Interface Parameters Sub-TLV .......................10
3.4.4. Leaf Grafting/Pruning ..............................10
3.4.5. Failure Detection and Reporting ....................11
3.4.6. Protection and Restoration .........................11
3.4.7. Scalability ........................................13
4. Backward Compatibility .........................................13
5. Security Considerations ........................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
7. Acknowledgments ................................................15
8. Contributors ...................................................16
As defined in the pseudowire architecture [RFC3985], a pseudowire (PW) is a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over an IP or MPLS Packet Switched Network (PSN). It provides a single service that is perceived by its user as an unshared link or circuit of the chosen service. A pseudowire is used to transport Layer 1 or Layer 2 traffic (e.g., Ethernet, Time-Division Multiplexing (TDM), ATM, and Frame Relay) over a Layer 3 PSN. Pseudowire Emulation Edge-to-Edge (PWE3) operates "edge to edge" to provide the required connectivity between the two endpoints of the PW.
如伪线体系结构[RFC3985]中所定义，伪线（PW）是一种通过IP或MPLS分组交换网络（PSN）模拟电信服务（如T1专线或帧中继）基本属性的机制。它提供单个服务，用户将其视为所选服务的非共享链路或电路。伪线用于通过第3层PSN传输第1层或第2层流量（例如，以太网、时分复用（TDM）、ATM和帧中继）。伪线仿真边到边（PWE3）操作“边到边”，以在PW的两个端点之间提供所需的连接。
The point-to-multipoint (P2MP) topology described in [VPMS-REQS] and required to provide P2MP Layer 2 VPN service can be achieved using one or more P2MP PWs. The use of PW encapsulation enables P2MP
[VPMS-REQS]中描述的提供P2MP第2层VPN服务所需的点对多点（P2MP）拓扑可以使用一个或多个P2MP PW实现。使用PW封装可以实现P2MP
services to transport Layer 1 or Layer 2 data. This could be achieved using a set of point-to-point PWs, with traffic replication at the Root Provider Edge (PE), but at the cost of bandwidth efficiency, as duplicate traffic would be carried multiple times on shared links.
用于传输第1层或第2层数据的服务。这可以通过使用一组点对点PW实现，在根提供商边缘（PE）进行流量复制，但要以带宽效率为代价，因为重复流量将在共享链路上多次传输。
This document defines the requirements for a point-to-multipoint PW (P2MP PW). A P2MP PW is a mechanism that emulates the essential attributes of a P2MP telecommunications service such as a P2MP ATM Virtual Circuit over a Packet Switched Network.
本文件定义了点对多点PW（P2MP PW）的要求。P2MP PW是一种模拟P2MP电信服务基本属性的机制，例如分组交换网络上的P2MP ATM虚拟电路。
The required functions of P2MP PWs include encapsulating service-specific Protocol Data Units (PDUs) arriving at an ingress Attachment Circuit (AC), carrying them across a tunnel to one or more egress ACs, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as faithfully as possible.
P2MP PW所需的功能包括封装到达入口连接电路（AC）的特定于服务的协议数据单元（PDU），将它们穿过隧道运送到一个或多个出口AC，管理它们的定时和顺序，以及尽可能忠实地模拟服务的行为和特征所需的任何其他操作。
The document describes the general architecture of P2MP PW with a reference model, mentions the notion of data encapsulation, and outlines specific requirements for the setup and maintenance of a P2MP PW. In this document, the requirements focus on the Single-Segment PW model. The requirements for realizing P2MP PW in the Multi-Segment PW model [RFC5254] are left for further study. This document refers to [RFC3916] for other aspects of P2MP PW implementation, such as "Packet Processing" (Section 4 of that document) and "Faithfulness of Emulated Services" (Section 7 of that document).
本文件通过参考模型描述了P2MP PW的总体架构，提到了数据封装的概念，并概述了P2MP PW的设置和维护的具体要求。在本文件中，需求集中于单段PW模型。在多段PW模型[RFC5254]中实现P2MP PW的要求留待进一步研究。本文件参考[RFC3916]了解P2MP PW实施的其他方面，如“数据包处理”（该文件第4节）和“模拟服务的忠实性”（该文件第7节）。
Although this is a requirements specification not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted to apply to protocol solutions designed to meet these requirements as described in [RFC2119].
尽管本规范为要求规范而非协议规范，但本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应解释为适用于旨在满足[RFC2119]中所述要求的协议解决方案。
P2P: Point-to-Point P2MP: Point-to-Multipoint PW: Pseudowire PSN: Packet Switched Network SS-PW: Single-Segment Pseudowire
P2P：点对点P2MP：点对多点PW：伪线PSN：分组交换网络SS-PW：单段伪线
This document uses terminology described in [RFC5659]. It also introduces additional terms needed in the context of P2MP PW.
本文件使用[RFC5659]中描述的术语。它还介绍了P2MP PW上下文中需要的其他术语。
P2MP PW (also referred to as PW tree): Point-to-Multipoint Pseudowire. A PW attached to a source Customer Edge (CE) used to distribute Layer 1 or Layer 2 traffic to a set of one or more receiver CEs. The P2MP PW is unidirectional (i.e., carrying traffic from Root PE to Leaf PEs) and optionally supports a return path.
P2MP PW（也称为PW树）：点对多点伪线。连接到源客户边缘（CE）的PW，用于将第1层或第2层通信量分配到一组或多个接收器CE。P2MP PW是单向的（即，从根PE到叶PE承载流量），并且可选地支持返回路径。
P2MP SS-PW: Point-to-Multipoint Single-Segment Pseudowire. A single-segment P2MP PW set up between the Root PE attached to the source CE and the Leaf PEs attached to the receiver CEs. The P2MP SS-PW uses P2MP Label Switched Paths (LSPs) as PSN tunnels.
P2MP SS-PW：点对多点单段伪线。在连接到源CE的根PE和连接到接收器CE的叶PE之间设置的单个段P2MP PW。P2MP SS-PW使用P2MP标签交换路径（LSP）作为PSN隧道。
Root PE: P2MP PW Root Provider Edge. The PE attached to the traffic source CE for the P2MP PW via an Attachment Circuit (AC).
根PE:P2MP PW根提供程序边缘。PE通过连接电路（AC）连接到P2MP PW的流量源CE。
Leaf PE: P2MP PW Leaf Provider Edge. A PE attached to a set of one or more traffic receiver CEs, via ACs. The Leaf PE replicates traffic to the CEs based on its Forwarder function [RFC3985].
叶PE:P2MP PW叶提供程序边缘。通过ACs连接到一组一个或多个业务接收器CE的PE。Leaf PE根据其转发器功能将流量复制到CEs[RFC3985]。
P2MP PSN Tunnel: In the P2MP SS-PW topology, the PSN tunnel is a general term indicating a virtual P2MP connection between the Root PE and the Leaf PEs. A P2MP tunnel may potentially carry multiple P2MP PWs inside (aggregation). This document uses terminology from the document describing the MPLS multicast architecture [RFC5332] for MPLS PSN.
P2MP PSN隧道：在P2MP SS-PW拓扑中，PSN隧道是一个通用术语，表示根PE和叶PE之间的虚拟P2MP连接。P2MP隧道可能在内部承载多个P2MP PW（聚合）。本文档使用描述MPLS PSN的MPLS多播架构[RFC5332]的文档中的术语。
As per the definition in [RFC3985], a pseudowire (PW) both originates and terminates on the edge of the same packet switched network (PSN). The PW label is unchanged between the originating and terminating Provider Edges (PEs). This is also known as a single-segment pseudowire (SS-PW) -- the most fundamental network model of PWE3.
根据[RFC3985]中的定义，伪线（PW）在同一分组交换网络（PSN）的边缘发起和终止。原始和终止提供程序边缘（PE）之间的PW标签保持不变。这也称为单段伪线（SS-PW）——PWE3最基本的网络模型。
A P2MP PW can be defined as point-to-multipoint connectivity from a Root PE connected to a traffic source CE to one or more Leaf PEs connected to traffic receiver CEs. It is considered to be an extended architecture of the existing P2P SS-PW technology.
P2MP PW可定义为从连接到业务源CE的根PE到连接到业务接收器CE的一个或多个叶PE的点对多点连接。它被认为是现有P2P SS-PW技术的扩展架构。
Figure 1 describes the P2MP PW reference model that is derived from [RFC3985] to support P2MP emulated services.
图1描述了源于[RFC3985]的P2MP PW参考模型，以支持P2MP模拟服务。
|<-------------P2MP PW------------->|
Native | | Native
ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF
V (AC) V V V V (AC) V
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC2 | +----+
| | | | ......PW1.......>|---------->|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+AC4 | +----+
| | | | . |=========|PE4 |---------->|CE4 |
| | | | ......PW1.......>| | +----+
| | | | |=========| |AC5 | +----+
| | | | | | |---------->|CE5 |
| +----+ +-----+ +----+ | +----+
|<-------------P2MP PW------------->|
Native | | Native
ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF
V (AC) V V V V (AC) V
| +----+ +-----+ +----+ |
| |PE1 | | P |=========|PE2 |AC2 | +----+
| | | | ......PW1.......>|---------->|CE2 |
| | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+ |
+----+ | AC1 | | | . |=========|PE3 |AC3 | +----+
|CE1 |-------->|........PW1.............PW1.......>|---------->|CE3 |
+----+ | | | | . |=========| | | +----+
| | | | . | +----+ |
| | |=========| . | |
| | | | . | +----+AC4 | +----+
| | | | . |=========|PE4 |---------->|CE4 |
| | | | ......PW1.......>| | +----+
| | | | |=========| |AC5 | +----+
| | | | | | |---------->|CE5 |
| +----+ +-----+ +----+ | +----+
Figure 1: P2MP PW Reference Model
图1:P2MP PW参考模型
This architecture applies to the case where a P2MP PSN tunnel extends between edge nodes of a single PSN domain to transport a unidirectional P2MP PW with endpoints at these edge nodes. In this model, a single copy of each PW packet is sent over the PW on the P2MP PSN tunnel and is received by all Leaf PEs due to the P2MP
此体系结构适用于P2MP PSN隧道在单个PSN域的边缘节点之间延伸以传输端点位于这些边缘节点的单向P2MP PW的情况。在该模型中，每个PW数据包的一个副本通过P2MP PSN隧道上的PW发送，并且由于P2MP，所有叶PE都接收到该数据包
nature of the PSN tunnel. The P2MP PW SHOULD be traffic optimized, i.e., only one copy of a P2MP PW packet or PSN tunnel (underlying layer) packet is sent on any single link along the P2MP path. P routers participate in P2MP PSN tunnel operation but not in the signaling of P2MP PWs.
PSN隧道的性质。P2MP PW应该是流量优化的，即，沿着P2MP路径的任何单个链路上只发送P2MP PW数据包或PSN隧道（底层）数据包的一个副本。P路由器参与P2MP PSN隧道操作，但不参与P2MP PWs的信令。
The Reference Model outlines the basic pieces of a P2MP PW. However, several levels of replication need to be considered when designing a P2MP PW solution:
参考模型概述了P2MP PW的基本部件。但是，在设计P2MP PW解决方案时，需要考虑几个复制级别：
- Ingress PE replication to CEs: traffic is replicated to a set of local receiver CEs
- 入口PE复制到CEs：流量复制到一组本地接收器CEs
- P router replication in the core: traffic is replicated by means of a P2MP PSN tunnel (P2MP LSP)
- P核心路由器复制：通过P2MP PSN隧道（P2MP LSP）复制流量
- Egress PE replication to CEs: traffic is replicated to local receiver CEs
- 出口PE复制到CEs：流量复制到本地接收器CEs
Theoretically, it is also possible to consider Ingress PE replication in the core; that is, all traffic is replicated to a set of P2P PSN transport tunnels at ingress, not using P router replication at all.
从理论上讲，也可以考虑在核心中侵入PE复制；也就是说，所有流量在入口复制到一组P2P PSN传输隧道，而根本不使用P路由器复制。
However, this approach may lead to duplicate copies of each PW packet being sent over the same physical link, specifically in the case where multiple PSN tunnels transit that physical link. Hence, this approach is not preferred.
然而，这种方法可能导致在同一物理链路上发送的每个PW分组的副本，特别是在多个PSN隧道传输该物理链路的情况下。因此，这种方法并不可取。
Specific operations that MUST be performed at the PE on the native data units are not described here since the required pre-processing (Forwarder (FWRD) and Native Service Processing (NSP)) defined in Section 4.2 of [RFC3985] is also applicable to P2MP PW.
由于[RFC3985]第4.2节中定义的所需预处理（转发器（FWRD）和本机服务处理（NSP））也适用于P2MP PW，因此此处不描述必须在PE对本机数据单元执行的特定操作。
P2MP PWs are generally unidirectional, but a Root PE may need to receive unidirectional P2P return traffic from any Leaf PE. For that purpose, the P2MP PW solution MAY support an optional return path from each Leaf PE to the Root PE.
P2MP PW通常是单向的，但是根PE可能需要接收来自任何叶PE的单向P2P返回流量。为此，P2MP PW解决方案可以支持从每个叶PE到根PE的可选返回路径。
The definition of MPLS multicast encapsulation [RFC5332] specifies the procedure to carry MPLS packets that are to be replicated and a copy of the packet sent to each of the specified next hops. This notion is also applicable to a P2MP PW packet carried by a P2MP PSN tunnel.
MPLS多播封装的定义[RFC5332]规定了携带要复制的MPLS数据包以及发送到每个指定下一跳的数据包副本的过程。这个概念也适用于P2MP PSN隧道携带的P2MP PW数据包。
To be more precise, a P2MP PSN tunnel corresponds to a "point-to-multipoint data link or tunnel" described in Section 3 of [RFC5332].
更准确地说，P2MP PSN隧道对应于[RFC5332]第3节中描述的“点对多点数据链路或隧道”。
Similarly, P2MP PW labels correspond to "the top labels (before applying the data link or tunnel encapsulation) of all MPLS packets that are transmitted on a particular point-to-multipoint data link or tunnel".
类似地，P2MP PW标签对应于“在特定点对多点数据链路或隧道上传输的所有MPLS分组的顶部标签（在应用数据链路或隧道封装之前）”。
In the P2MP PW architecture using the SS-PW network model, the PW-PDU [RFC3985] is replicated by the underlying P2MP PSN tunnel layer. Note that the PW label is unchanged, and hidden in switching, by the transit P routers.
在使用SS-PW网络模型的P2MP PW体系结构中，PW-PDU[RFC3985]由底层P2MP PSN隧道层复制。请注意，PW标签由transit P路由器保持不变，并隐藏在交换中。
In a solution, a P2MP PW MUST be supported over a single P2MP PSN tunnel as the underlying layer of traffic distribution. Figure 2 gives an example of P2MP PW topology relying on a single P2MP LSP. The PW tree is composed of one Root PE (i1) and several Leaf PEs (e1, e2, e3, e4).
在解决方案中，必须在单个P2MP PSN隧道上支持P2MP PW，作为流量分布的底层。图2给出了依赖于单个P2MP LSP的P2MP PW拓扑的示例。PW树由一个根PE（i1）和几个叶PE（e1、e2、e3、e4）组成。
The mechanisms for establishing the PSN tunnel are outside the scope of this document, as long as they enable the essential attributes of the service to be emulated.
建立PSN隧道的机制不在本文档的范围内，只要它们能够模拟服务的基本属性。
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
i1
/
/ \
/ \
/ \
/\ \
/ \ \
/ \ \
/ \ / \
e1 e2 e3 e4
Figure 2: Example of P2MP Underlying Layer for P2MP PW
图2:P2MP PW的P2MP底层示例
A single P2MP PSN tunnel MUST be able to serve the traffic from more than one P2MP PW in an aggregated way, i.e., multiplexing.
单个P2MP PSN隧道必须能够以聚合方式（即多路复用）为来自多个P2MP PW的流量提供服务。
A P2MP PW solution MAY support different P2MP PSN tunneling technology (e.g., MPLS over GRE [RFC4023] or P2MP MPLS LSP) or different setup protocols (e.g., multipoint extensions for LDP (mLDP) [RFC6388] and P2MP RSVP-TE [RFC4875]).
P2MP PW解决方案可支持不同的P2MP PSN隧道技术（例如，GRE上的MPLS[RFC4023]或P2MP MPLS LSP）或不同的设置协议（例如，LDP（mLDP）[RFC6388]和P2MP RSVP-TE[RFC4875]的多点扩展）。
The P2MP LSP associated to the P2MP PW can be selected either by user configuration or by dynamically using a multiplexing/demultiplexing mechanism.
与P2MP PW相关联的P2MP LSP可以通过用户配置或通过动态使用复用/解复用机制来选择。
The P2MP PW multiplexing SHOULD be used based on the overlap rate between P2MP LSP and P2MP PW. As an example, an existing P2MP LSP may attach more leaves than the ones defined as Leaf PEs for a given
应根据P2MP LSP和P2MP PW之间的重叠率使用P2MP PW多路复用。例如，现有P2MP LSP可能附加的叶数比为给定时间定义为叶PEs的叶数更多
P2MP PW. It may be attractive to reuse it to minimize new configuration, but using this P2MP LSP would cause non-Leaf PEs (i.e., not part of the P2MP PW) to receive unwanted traffic.
P2MP-PW。重用它以最小化新配置可能很有吸引力，但使用此P2MP LSP将导致非叶PE（即，不是P2MP PW的一部分）接收不需要的流量。
Note: no special configuration is needed for non-Leaf PEs to drop that unwanted traffic because they do not have forwarding information entries unless they process the setup operation for corresponding P2MP PWs (e.g., signaling).
注意：非叶PEs不需要特殊配置来丢弃不需要的流量，因为它们没有转发信息条目，除非它们处理相应P2MP PW的设置操作（例如，信令）。
The operator SHOULD determine whether it is acceptable to partially multiplex the P2MP PW onto a P2MP LSP, and a minimum congruency rate may be defined to enable the Root PE to make this determination. The congruency rate SHOULD take into account several items, including:
操作员应确定是否可以将P2MP PW部分复用到P2MP LSP上，并且可以定义最小一致性率以使根PE能够进行此确定。一致性率应考虑以下几项，包括：
- the amount of overlap between the Leaf PEs of the P2MP PW and the existing egress PE routers of the P2MP LSP. If there is a complete overlap, the congruency is perfect and the rate is 100%.
- P2MP PW的叶PE和P2MP LSP的现有出口PE路由器之间的重叠量。如果存在完全重叠，则一致性是完美的，比率为100%。
- the impact on other traffic (e.g., from other VPNs) supported over the P2MP LSP.
- 对P2MP LSP支持的其他流量（例如来自其他VPN）的影响。
With this procedure, a P2MP PW is nested within a P2MP LSP. This allows multiplexing several PWs over a common P2MP LSP. Prior to the P2MP PW signaling phase, the Root PE determines which P2MP LSP will be used for this P2MP PW. The PSN tunnel can be an existing PSN tunnel or the Root PE can create a new P2MP PSN tunnel. Note that the ingress PE may modify or re-create an existing P2MP PSN tunnel in order to add one or more leaf PEs to enable it to transport the P2MP PW.
通过此过程，P2MP PW嵌套在P2MP LSP中。这允许在公共P2MP LSP上多路复用多个PW。在P2MP PW信令阶段之前，根PE确定该P2MP PW将使用哪个P2MP LSP。PSN隧道可以是现有的PSN隧道，或者根PE可以创建新的P2MP PSN隧道。注意，入口PE可修改或重新创建现有P2MP PSN隧道，以添加一个或多个叶PE，使其能够传输P2MP PW。
[RFC5332] introduces two approaches to assigning MPLS labels (meaning PW labels in the P2MP PW context): Upstream-Assigned [RFC5331] and Downstream-Assigned. However, it is out of scope of this document which one should be used in PW construction. It is left to the specification of the solution.
[RFC5332]介绍了两种分配MPLS标签的方法（在P2MP PW上下文中指PW标签）：上游分配[RFC5331]和下游分配。但是，在PW施工中应使用哪一个超出了本文件的范围。这取决于解决方案的规格。
The following requirements apply to the establishment of P2MP PWs:
以下要求适用于P2MP PWs的建立：
- PE nodes MUST be configurable with the P2MP PW identifiers and ACs.
- PE节点必须可配置P2MP PW标识符和ACs。
- A discovery mechanism SHOULD allow the Root PE to discover the Leaf PEs, or vice versa.
- 发现机制应允许根PE发现叶PE，反之亦然。
- Solutions SHOULD allow single-sided operation at the Root PE for the selection of some AC(s) at the Leaf PE(s) to be attached to the PW tree so that the Root PE controls the leaf attachment.
- 解决方案应允许在根PE处单面操作，以选择要连接到PW树的叶PE处的一些AC，以便根PE控制叶连接。
- The Root PE SHOULD support a method to be informed about whether a Leaf PE has successfully attached to the PW tree.
- 根PE应支持一种方法，告知叶PE是否已成功连接到PW树。
The P2MP PW MUST be uniquely identified. This unique P2MP PW identifier MUST be used for all signaling procedures related to this PW (PW setup, monitoring, etc.).
P2MP PW必须具有唯一标识。此唯一P2MP PW标识符必须用于与此PW相关的所有信号程序（PW设置、监控等）。
The Root PE and Leaf PEs of a P2MP PW MUST be configured with the same PW type as defined in [RFC4446] for P2P PW. In case of a type mismatch, a PE SHOULD abort attempts to attach the Leaf PE to the P2MP PW.
P2MP PW的根PE和叶PE必须配置为与[RFC4446]中定义的P2P PW相同的PW类型。如果类型不匹配，PE应中止将叶PE连接到P2MP PW的尝试。
Some interface parameters [RFC4446] related to the AC capability have been defined according to the PW type and are signaled during the PW setup.
根据PW类型定义了一些与交流能力相关的接口参数[RFC4446]，并在PW设置期间发出信号。
Where applicable, a solution is REQUIRED to ascertain whether the AC at the Leaf PE is capable of supporting traffic coming from the AC at the Root PE.
在适用的情况下，需要一种解决方案来确定叶PE处的AC是否能够支持来自根PE处的AC的流量。
In case of a mismatch, the passive PE (Root or Leaf PE, depending on the signaling process) SHOULD support mechanisms to reject attempts to attach the Leaf PE to the P2MP PW.
在不匹配的情况下，被动PE（根PE或叶PE，取决于信号处理）应支持拒绝将叶PE连接到P2MP PW的尝试的机制。
Once the PW tree is established, the solution MUST allow the addition or removal of a Leaf PE, or a subset of leaves to/from the existing tree, without any impact on the PW tree (data and control planes) for the remaining Leaf PEs.
一旦建立了PW树，解决方案必须允许在现有树中添加或删除叶PE或叶子集，而不会对剩余叶PE的PW树（数据和控制平面）产生任何影响。
The addition or removal of a Leaf PE MUST also allow the P2MP PSN tunnel to be updated accordingly. This may cause the P2MP PSN tunnel to add or remove the corresponding Leaf PE.
叶片PE的添加或删除还必须允许P2MP PSN隧道相应更新。这可能导致P2MP PSN通道添加或删除相应的叶PE。
Since the underlying layer has an end-to-end P2MP topology between the Root PE and the Leaf PEs, the failure reporting and processing procedures are implemented only on the edge nodes.
由于底层在根PE和叶PE之间具有端到端P2MP拓扑，因此故障报告和处理过程仅在边缘节点上实现。
Failure events may cause one or more Leaf PEs to become detached from the PW tree. These events MUST be reported to the Root PE, using appropriate out-of-band or in-band Operations, Administration, and Maintenance (OAM) messages for monitoring.
故障事件可能导致一个或多个叶PE从PW树上分离。必须使用适当的带外或带内操作、管理和维护（OAM）消息将这些事件报告给根PE进行监控。
It MUST be possible for the operator to choose the out-of-band or in-band monitoring tools or both to monitor the Leaf PE status. For management purposes, the solution SHOULD allow the Root PE to be informed of Leaf PEs' failure.
操作员必须能够选择带外或带内监测工具，或同时选择两者来监测叶片PE状态。出于管理目的，该解决方案应允许将Leaf PE的故障通知给根PE。
Based on these failure notifications, solutions MUST allow the Root PE to update the remaining leaves of the PW tree.
基于这些故障通知，解决方案必须允许根PE更新PW树的剩余叶子。
- A solution MUST support an in-band status notification mechanism to detect failures: unidirectional point-to-multipoint traffic failure. This MUST be realized by enhancing existing unicast PW methods, such as Virtual Circuit Connectivity Verification (VCCV) for seamless and familiar operation as defined in [RFC5085].
- 解决方案必须支持带内状态通知机制来检测故障：单向点对多点通信故障。这必须通过增强现有单播PW方法来实现，如[RFC5085]中定义的无缝和熟悉操作的虚拟电路连接验证（VCCV）。
- In case of failure, it MUST correctly report which Leaf PEs are affected. This MUST be realized by enhancing existing PW methods, such as LDP Status Notification. The notification message SHOULD include the type of fault (P2MP PW, AC, or PSN tunnel).
- 如果出现故障，必须正确报告哪些叶PEs受到影响。这必须通过增强现有的PW方法来实现，例如LDP状态通知。通知消息应包括故障类型（P2MP PW、AC或PSN隧道）。
- A Leaf PE MAY be notified of the status of the Root PE's AC.
- 叶PE可以被通知根PE的AC的状态。
- A solution MUST support OAM message mapping [RFC6310] at the Root PE and Leaf PE if a failure is detected on the source CE.
- 如果在源CE上检测到故障，则解决方案必须在根PE和叶PE上支持OAM消息映射[RFC6310]。
It is assumed that if recovery procedures are required, the P2MP PSN tunnel will support standard MPLS-based recovery techniques. In that case, a mechanism SHOULD be implemented to avoid race conditions between recovery at the PSN level and recovery at the PW level.
假设如果需要恢复过程，P2MP PSN隧道将支持基于MPLS的标准恢复技术。在这种情况下，应实施一种机制，以避免PSN级别的恢复和PW级别的恢复之间出现争用情况。
An alternative protection scheme MAY rely on the PW layer.
替代保护方案可依赖于PW层。
Leaf PEs MAY be protected via a P2MP PW redundancy mechanism. In the example depicted below, a standby P2MP PW is used to protect the active P2MP PW. In that protection scheme, the AC at the Root PE MUST serve both P2MP PWs. In this scenario, the criteria for
叶PEs可通过P2MP PW冗余机制进行保护。在下面描述的示例中，备用P2MP PW用于保护活动P2MP PW。在该保护方案中，根PE处的AC必须服务于两个P2MP PW。在此场景中，以下条件
switching over SHOULD be defined, e.g., failure of one or all leaves of the active P2MP PW will trigger switchover of the whole P2MP PW.
应定义切换，例如，激活P2MP PW的一个或所有叶片故障将触发整个P2MP PW的切换。
CE1
|
ROOT active PE1 standby
P2MP PW .../ \....P2MP PW
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
LEAF PE4 PE5 PE6 PE7
| | | |
| \ / |
\ CE2 /
\ /
------CE3-----
CE1
|
ROOT active PE1 standby
P2MP PW .../ \....P2MP PW
/ \
P2 P3
/ \ / \
/ \ / \
/ \ / \
LEAF PE4 PE5 PE6 PE7
| | | |
| \ / |
\ CE2 /
\ /
------CE3-----
Figure 3: Example of P2MP PW Redundancy for Protecting Leaf PEs
图3：保护叶PEs的P2MP PW冗余示例
Note that some of the nodes/links in this figure can be physically shared; this depends on the service provider policy of network redundancy.
请注意，此图中的一些节点/链接可以物理共享；这取决于网络冗余的服务提供商策略。
The Root PE MAY be protected via a P2MP PW redundancy mechanism. In the example depicted below, a standby P2MP PW is used to protect the active P2MP. A single AC at the Leaf PE MUST be used to attach the CE to the primary and the standby P2MP PW. The Leaf PE MUST support protection mechanisms in order to select the active P2MP PW.
根PE可通过P2MP PW冗余机制进行保护。在下面描述的示例中，备用P2MP PW用于保护活动P2MP。必须使用叶PE处的单个AC将CE连接到主和备用P2MP PW。叶PE必须支持保护机制，以便选择活动P2MP PW。
CE1
/ \
| |
ROOT active PE1 PE2 standby
P2MP PW1 | | P2MP PW2
| |
P2 P3
/ \/ \
/ /\ \
/ / \ \
/ / \ \
LEAF PE4 PE5
| |
CE2 CE3
CE1
/ \
| |
ROOT active PE1 PE2 standby
P2MP PW1 | | P2MP PW2
| |
P2 P3
/ \/ \
/ /\ \
/ / \ \
/ / \ \
LEAF PE4 PE5
| |
CE2 CE3
Figure 4: Example of P2MP PW Redundancy for Protecting Root PEs
图4：保护根PE的P2MP PW冗余示例
The solution SHOULD scale at worst linearly for message size, memory requirements, and processing requirements, with the number of Leaf PEs.
该解决方案在最坏情况下，应根据消息大小、内存需求和处理需求，以及叶PE的数量线性扩展。
Increasing the number of P2MP PWs between a Root PE and a given set of Leaf PEs SHOULD NOT cause the P router to increase the number of entries in its forwarding table by the same or greater proportion. Multiplexing P2MP PWs to P2MP PSN tunnels achieves this.
增加根PE和给定的一组叶PE之间的P2MP PW数不应导致P路由器将其转发表中的条目数增加相同或更大的比例。将P2MP PW多路复用到P2MP PSN隧道可以实现这一点。
Solutions MUST be backward compatible with current PW standards. Solutions SHOULD utilize existing capability advertisement and negotiation procedures for the PEs implementing P2MP PW endpoints.
解决方案必须与当前PW标准向后兼容。解决方案应利用PEs实施P2MP PW端点的现有能力宣传和协商程序。
The implementation of OAM mechanisms also implies the advertisement of PE capabilities to support specific OAM features. The solution MAY allow advertising P2MP PW OAM capabilities. A solution MUST NOT allow a P2MP PW to be established to PEs that do not support P2MP PW functionality. It MUST have a mechanism to report an error for incompatible PEs.
OAM机制的实现还意味着PE功能的发布，以支持特定的OAM功能。该解决方案可能允许广告P2MP PW OAM功能。解决方案不得允许为不支持P2MP PW功能的PE建立P2MP PW。它必须具有报告不兼容PEs错误的机制。
In some cases, upstream traffic is needed from downstream CEs to upstream CEs. The P2MP PW solution SHOULD allow a return path (i.e., from the Leaf PE to the Root PE) that provides upstream connectivity.
在某些情况下，需要从下游CEs到上游CEs的上游流量。P2MP PW解决方案应允许提供上游连接的返回路径（即从叶PE到根PE）。
In particular, the same ACs MAY be shared between the downstream and upstream directions. For downstream, a CE receives traffic originated by the Root PE over its AC. For upstream, the CE MAY also send traffic destined to the same Root PE over the same AC.
具体地，相同的ACs可在下游和上游方向之间共享。对于下游，CE通过其AC接收根PE发起的通信量。对于上游，CE还可以通过相同AC发送目的地为相同根PE的通信量。
The security requirements common to PW are raised in Section 11 of [RFC3916]. P2MP PW is a variant of the initial P2P PW definition, and those requirements (and the security considerations from [RFC3985]) also apply. The security considerations from [RFC5920] and [RFC6941] also apply to the IP/MPLS and MPLS-TP deployment scenarios, respectively.
[RFC3916]第11节提出了PW通用的安全要求。P2MP PW是初始P2P PW定义的变体，这些要求（以及[RFC3985]中的安全注意事项）也适用。[RFC5920]和[RFC6941]中的安全注意事项也分别适用于IP/MPLS和MPLS-TP部署场景。
Some issues specifically due to P2MP topology need to be addressed in the definition of the solution:
在解决方案的定义中，需要解决一些与P2MP拓扑相关的问题：
- The solution SHOULD provide means to protect the traffic delivered to receivers (Integrity, Confidentiality, Endpoint Authentication).
- 该解决方案应提供保护传递给接收者的流量的方法（完整性、机密性、端点身份验证）。
- The solution SHOULD support means to protect the P2MP PW as a whole against attacks that would lead to any kind of denial of service.
- 该解决方案应支持保护P2MP PW作为一个整体免受可能导致任何类型拒绝服务的攻击的方法。
Specifically, safeguard mechanisms should be considered to avoid any negative impact on the whole PW tree when any one receiver or any group of receivers is attacked. Safeguard mechanisms for both the data plane and the control plane need to be considered.
具体而言，应考虑保护机制，以避免在任何一个接收器或任何接收器组受到攻击时对整个PW树产生任何负面影响。需要考虑数据平面和控制平面的安全机制。
[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月。
[RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916]Xiao，X.，Ed.，McPherson，D.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）的要求”，RFC 39162004年9月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，RFC 5659，2009年10月。
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011.
[RFC6310]Aissaoui，M.，Busschbach，P.，Martini，L.，Morrow，M.，Nadeau，T.，和Y（J）。Stein，“伪线（PW）操作、管理和维护（OAM）消息映射”，RFC63102011年7月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254]Bitar，N.，Ed.，Bocci，M.，Ed.，和L.Martini，Ed.，“多段伪线仿真边到边（PWE3）的要求”，RFC 5254，2008年10月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941]Fang，L.，Ed.，Niven Jenkins，B.，Ed.，Mansfield，S.，Ed.，和R.Graveman，Ed.，“MPLS传输配置文件（MPLS-TP）安全框架”，RFC 69412013年4月。
[VPMS-REQS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Work in Progress, October 2012.
[VPMS-REQS]Kamite，Y.，Jounay，F.，Niven Jenkins，B.，Brungard，D.，和L.Jin，“虚拟专用多播服务（VPMS）的框架和要求”，正在进行的工作，2012年10月。
The authors thank the following people: the authors of [RFC4461] since the structure and content of this document were, for some sections, largely inspired by [RFC4461]; JL. Le Roux and A. Cauvin for the discussions, comments, and support; Adrian Farrel for his Routing Area Director review; and IESG reviewers.
作者感谢以下人员：[RFC4461]的作者，因为本文件的结构和内容在某些章节中主要受[RFC4461]的启发；JL。Le Roux和A.Cauvin的讨论、评论和支持；阿德里安·法雷尔的路由区域总监评论；和IESG评论员。
Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
菲利普尼日尔法国电信2号，皮埃尔马津大街22307拉尼翁塞德斯法国
EMail: philippe.niger@orange-ftgroup.com
EMail: philippe.niger@orange-ftgroup.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
卢卡·马蒂尼思科系统公司，地址：美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway
Lei Wang Telenor Snaroyveien 30为挪威内布1331
EMail: lei.wang@telenor.com
EMail: lei.wang@telenor.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 US
Rahul Aggarwal Juniper Networks美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net
Simon Delord Telstra 380 Flinders Lane Melbourne Australia
澳大利亚墨尔本弗林德斯巷380号西蒙·德洛德电信
EMail: simon.delord@gmail.com
EMail: simon.delord@gmail.com
Martin Vigoureux Alcatel-Lucent France Route de Villejust 91620 Nozay France
Martin Vigoureux Alcatel-Lucent法国维勒赫斯特路线91620法国诺扎伊
EMail: martin.vigoureux@alcatel-lucent.fr
EMail: martin.vigoureux@alcatel-lucent.fr
Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203 China
中国上海碧波路889号中兴通讯有限公司，邮编：201203
EMail: lizho.jin@gmail.com
EMail: lizho.jin@gmail.com
Authors' Addresses
作者地址
Frederic Jounay (editor) Orange CH 4 rue caudray 1020 Renens Switzerland
Frederic Jounay（编辑）Orange CH 4 rue caudray 1020 Renens瑞士
EMail: frederic.jounay@orange.ch
EMail: frederic.jounay@orange.ch
Yuji Kamite (editor) NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan
Yuji Kamite（编辑）NTT通信公司日本东京千代田区内石湾町1-1-6 100-8019
EMail: y.kamite@ntt.com
EMail: y.kamite@ntt.com
Giles Heron Cisco Systems, Inc. 9 New Square Bedfont Lakes Feltham Middlesex TW14 8HA United Kingdom
Giles Heron Cisco Systems，Inc.9 New Square Bedfont Lakes Feltham Middlesex TW14 8HA英国
EMail: giheron@cisco.com
EMail: giheron@cisco.com
Matthew Bocci Alcatel-Lucent Telecom Ltd Voyager Place Shoppenhangers Road Maidenhead Berks United Kingdom
Matthew Bocci Alcatel-Lucent电信有限公司英国梅登黑德伯克斯路Voyager Place Shoppenivers路
EMail: Matthew.Bocci@alcatel-lucent.com
EMail: Matthew.Bocci@alcatel-lucent.com