[要約] RFC 7338は、MPLSパケットスイッチングネットワーク上のポイントツーマルチポイント擬似ワイヤに関する要件とフレームワークを定義しています。その目的は、ポイントツーマルチポイント擬似ワイヤの設計と実装に関するガイドラインを提供することです。
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動作のアーキテクチャ、シグナリング、およびメンテナンスの側面に関連しています。それらは、そのようなメカニズムの標準化のためのガイドラインとして提案されています。他の潜在的なアプリケーションの中でも、ポイントツーマルチポイントPWは、マルチキャストレイヤー2サービス（仮想プライベートLANサービスおよび仮想プライベートマルチキャストサービス）のサポートを最適化するために使用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外で作成したりすることはできません。 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
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の2つのエンドポイント間に必要な接続を提供します。
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 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.
[VPMS-REQS]で説明され、P2MPレイヤー2 VPNサービスを提供するために必要なポイントツーマルチポイント（P2MP）トポロジは、1つ以上のP2MP PWを使用して実現できます。 PWカプセル化を使用すると、P2MPサービスでレイヤ1またはレイヤ2データを転送できます。これは、ルートプロバイダーエッジ（PE）でトラフィックを複製する一連のポイントツーポイントPWを使用して実現できますが、重複リンクは共有リンクで複数回伝送されるため、帯域幅効率が犠牲になります。
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 ATMバーチャルサーキットなどのP2MP電気通信サービスの重要な属性をエミュレートするメカニズムです。
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）のカプセル化、トンネルを介して1つ以上の出力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を実現するための要件は、今後の検討課題です。このドキュメントは、「パケット処理」（そのドキュメントのセクション4）や「エミュレートされたサービスの忠実性」（そのドキュメントのセクション7）など、P2MP PW実装の他の側面について[RFC3916]を参照しています。
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].
これはプロトコル仕様ではなく要件仕様ですが、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「このドキュメントの「MAY」および「OPTIONAL」は、[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ツリーとも呼ばれる）：ポイントツーマルチポイント疑似配線。レイヤー1またはレイヤー2トラフィックを1つ以上のレシーバーCEのセットに配信するために使用されるソースカスタマーエッジ（CE）に接続されたPW。 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ルートプロバイダーエッジ。接続回線（AC）を介してP2MP PWのトラフィックソースCEに接続されたPE。
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リーフプロバイダーエッジ。 ACを介して、1つ以上のトラフィックレシーバーCEのセットに接続されたPE。リーフPEは、そのフォワーダ機能[RFC3985]に基づいてCEにトラフィックを複製します。
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）のエッジで開始および終了します。 PWラベルは、発信側と着信側のプロバイダーエッジ（PE）間で変更されていません。これは、PWE3の最も基本的なネットワークモデルである単一セグメント疑似配線（SS-PW）とも呼ばれます。
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に接続された1つ以上のリーフPEへのポイントツーマルチポイント接続として定義できます。これは、既存のP2P SS-PWテクノロジーの拡張アーキテクチャーと見なされます。
Figure 1 describes the P2MP PW reference model that is derived from [RFC3985] to support P2MP emulated services.
図1は、P2MPエミュレートサービスをサポートするために[RFC3985]から派生したP2MP PWリファレンスモデルを示しています。
|<-------------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 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.
このアーキテクチャは、P2MP PSNトンネルが単一のPSNドメインのエッジノード間で拡張され、これらのエッジノードにエンドポイントを持つ単方向P2MP PWを転送する場合に適用されます。このモデルでは、各PWパケットの単一のコピーがP2MP PSNトンネルのPWを介して送信され、PSNトンネルのP2MPの性質により、すべてのリーフPEで受信されます。 P2MP PWはトラフィックを最適化する必要があります。つまり、P2MP PWパケットまたはPSNトンネル（基礎となるレイヤー）パケットの1つのコピーのみが、P2MPパスに沿った単一のリンクで送信されます。 PルーターはP2MP PSNトンネル操作に参加しますが、P2MP PWのシグナリングには参加しません。
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
- CEへの入力PEレプリケーション：トラフィックは一連のローカルレシーバーCEにレプリケートされます
- 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
- CEへの出力PEレプリケーション：トラフィックはローカルレシーバーCEにレプリケートされます
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.
理論的には、コアでIngress PEレプリケーションを検討することもできます。つまり、すべてのトラフィックは、Pルーターの複製をまったく使用せずに、入口でP2P PSNトランスポートトンネルのセットに複製されます。
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.
ただし、このアプローチでは、特に複数のPSNトンネルがその物理リンクを通過する場合に、各PWパケットの複製が同じ物理リンクを介して送信される可能性があります。したがって、このアプローチは好ましくありません。
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に適用できるため、ネイティブデータユニットのPEで実行する必要がある特定の操作はここでは説明しません。 PW。
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トンネルレイヤーによって複製されます。中継Pルータによって、PWラベルは変更されず、スイッチングでは非表示になることに注意してください。
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 PWは、トラフィック分散の基礎となる層として、単一のP2MP PSNトンネルを介してサポートされる必要があります。図2は、単一のP2MP LSPに依存するP2MP PWトポロジの例を示しています。 PWツリーは、1つのルート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
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からのトラフィックを集約された方法で、つまり多重化して提供できなければなりません（MUST）。
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トンネリング技術（たとえば、MPLS over GRE [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 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とP2MP PW間のオーバーラップレートに基づいて使用する必要があります。例として、既存のP2MP LSPは、特定のP2MP PWのリーフPEとして定義されたリーフよりも多くのリーフをアタッチする場合があります。新しい構成を最小限に抑えるために再利用することは魅力的ですが、この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).
注：対応するP2MP PWのセットアップ操作（シグナリングなど）を処理しない限り転送情報エントリがないため、非リーフPEが不要なトラフィックをドロップするための特別な構成は必要ありません。
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は、1つ以上のリーフPEを追加してP2MP PWを転送できるようにするために、既存のP2MP PSNトンネルを変更または再作成する場合があることに注意してください。
[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ラベルを意味する）を割り当てるための2つのアプローチを導入します：アップストリーム割り当て[RFC5331]とダウンストリーム割り当て。ただし、PWの構築でどちらを使用するかは、このドキュメントの範囲外です。ソリューションの仕様に任されています。
The following requirements apply to the establishment of P2MP PWs:
P2MP PWの確立には、次の要件が適用されます。
- PE nodes MUST be configurable with the P2MP PW identifiers and ACs.
- PEノードは、P2MP PW識別子とACで構成可能でなければなりません。
- 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がリーフの接続を制御するように、リーフPEの一部のACを選択するためにルートPEで片側操作をPWツリーに接続できるようにする必要があります（SHOULD）。
- 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ツリーに正常に接続されたかどうかを通知する方法をサポートする必要があります（SHOULD）。
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は、P2P PWの[RFC4446]で定義されているのと同じPWタイプで構成する必要があります。タイプが一致しない場合、PEはリーフPEをP2MP PWに接続する試みを中止する必要があります（SHOULD）。
Some interface parameters [RFC4446] related to the AC capability have been defined according to the PW type and are signaled during the PW setup.
AC機能に関連する一部のインターフェイスパラメータ[RFC4446]は、PWタイプに従って定義されており、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をP2MP PWに接続する試みを拒否するメカニズムをサポートする必要があります（SHOULD）。
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ツリーが確立されると、ソリューションは、残りのLeaf PEのPWツリー（データおよびコントロールプレーン）に影響を与えることなく、Leaf PEまたは既存のツリーへのリーフのサブセットの追加または削除を許可する必要があります（MUST）。 。
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.
障害イベントにより、1つ以上のリーフ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ステータスを監視するために、帯域外または帯域内監視ツール、あるいはその両方を選択できる必要があります。管理目的のために、ソリューションはルートPEにリーフPEの障害を通知できるようにする必要があります（SHOULD）。
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].
- ソリューションは、障害を検出するためのインバンドステータス通知メカニズムをサポートする必要があります：単方向ポイントツーマルチポイントトラフィック障害。これは、[RFC5085]で定義されているシームレスで使い慣れた操作のためのVirtual Circuit Connectivity Verification（VCCV）などの既存のユニキャストPWメソッドを拡張することによって実現する必要があります。
- 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).
- 障害が発生した場合、影響を受けるリーフPEを正しく報告する必要があります。これは、LDPステータス通知などの既存のPWメソッドを拡張することによって実現する必要があります。通知メッセージには、障害のタイプ（P2MP PW、AC、またはPSNトンネル）を含める必要があります（SHOULD）。
- 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レベルでの回復の間の競合状態を回避するメカニズムを実装する必要があります（SHOULD）。
An alternative protection scheme MAY rely on the PW layer.
代替の保護スキームは、PW層に依存してもよい（MAY）。
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 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.
リーフPEは、P2MP PW冗長メカニズムによって保護される場合があります。以下に示す例では、スタンバイP2MP PWを使用してアクティブP2MP PWを保護しています。その保護スキームでは、ルートPEのACが両方のP2MP PWを提供する必要があります。このシナリオでは、切り替えの基準を定義する必要があります。たとえば、アクティブなP2MP PWの1つまたはすべてのリーフで障害が発生すると、P2MP PW全体の切り替えがトリガーされます。
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：リーフPEを保護するための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
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標準と下位互換性がなければなりません。ソリューションは、P2MP PWエンドポイントを実装するPEの既存の機能アドバタイズメントおよびネゴシエーション手順を利用する必要があります。
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メカニズムの実装には、特定のOAM機能をサポートするPE機能のアドバタイズも含まれます。このソリューションは、P2MP PW OAM機能のアドバタイズを許可する場合があります。ソリューションでは、P2MP PW機能をサポートしていないPEに対してP2MP PWを確立することを許可してはなりません。互換性のないPEのエラーを報告するメカニズムが必要です。
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.
場合によっては、ダウンストリームCEからアップストリームCEへのアップストリームトラフィックが必要です。 P2MP PWソリューションは、アップストリーム接続を提供するリターンパス（つまり、リーフPEからルートPEへ）を許可する必要があります（SHOULD）。
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.
特に、同じACがダウンストリーム方向とアップストリーム方向で共有される場合があります。ダウンストリームの場合、CEはルートPEが発信したトラフィックをAC経由で受信します。アップストリームの場合、CEは同じルートPEを宛先とするトラフィックを同じAC経由で送信する場合があります。
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.
PWに共通のセキュリティ要件は、[RFC3916]のセクション11で提起されています。 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.
具体的には、1人の受信者または受信者のグループが攻撃された場合に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。、and P. Pate、Ed。、 "Requirements for Pseudo-Wire Emulation Edge-to-Edge（PWE3）"、RFC 3916、September 2004。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、Ed。、and P. Pate、Ed。、 "Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture"、RFC 3985、March 2005。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（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、「An-Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge」、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.、and Y（J）。 Stein、「Pseudowire（PW）Operations、Administration、and Maintenance（OAM）Message Mapping」、RFC 6310、2011年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またはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、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。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、2007年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。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、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。、and L. Martini、Ed。、 "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge（PWE3）"、RFC 5254、October 2008 。
[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 5331、2008年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、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.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、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。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、2013年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によるディスカッション、コメント、サポート。ルーティングエリアディレクターのレビューをしてくれたAdrian Farrel;およびIESGレビュアー。
Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Philippe Niger France Telecom 2、avenue Pierre-Marzin 22307 Lannion Cedex France
EMail: philippe.niger@orange-ftgroup.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
Luca Martini Cisco Systems、Inc. 9155 East Nichols Avenue、Suite 400 Englewood、CO 80112 US
EMail: lmartini@cisco.com
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway
Lei Wang Telenor Snaroyveien 30 Fornebu 1331ノルウェー
EMail: lei.wang@telenor.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 US
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089 US
EMail: rahul@juniper.net
Simon Delord Telstra 380 Flinders Lane Melbourne Australia
Simon Delord Telstra 380 Flinders Laneメルボルンオーストラリア
EMail: simon.delord@gmail.com Martin Vigoureux Alcatel-Lucent France Route de Villejust 91620 Nozay France
メール：simon.delord@gmail.com Martin Vigoureux Alcatel-Lucent France Route de Villejust 91620 Nozay France
EMail: martin.vigoureux@alcatel-lucent.fr
Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203 China
l i kind of jin ZT E Corporation 889、BI Bo Road Shanghai、201203中国
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
Yuji Kamite (editor) NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan
ゆじ かみて （えぢとｒ） んっｔ こっむにかちおんｓ こｒぽらちおん １ー１ー６ うちさいわいーちょ、 ちよだーく ときょ １００ー８０１９ じゃぱん
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
Matthew Bocci Alcatel-Lucent Telecom Ltd Voyager Place Shoppenhangers Road Maidenhead Berks United Kingdom
Matthew Bocci Alcatel-Lucent Telecom Ltd Voyager Place Shoppenhangers Road Maidenhead Berksイギリス
EMail: Matthew.Bocci@alcatel-lucent.com