[要約] RFC 8338は、LDPを使用してルート起点のポイントツーマルチポイント擬似ワイヤをシグナリングするための仕様です。目的は、LDPを使用してネットワーク上でポイントツーマルチポイント接続を確立するための手法を提供することです。
Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 8338 VMware
Updates: 7385 S. Sivabalan, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 March 2018
Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP
LDPを使用したルート開始のポイントツーマルチポイント疑似配線のシグナリング
Abstract
概要
This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.
このドキュメントでは、LDPを使用してポイントツーマルチポイント（P2MP）疑似配線（PW）ツリーに信号を送るメカニズムを指定します。このようなメカニズムは、IPまたはMPLS対応のPSNを介したP2MP接続を必要とするレイヤー2 VPNサービスに適しています。提案されたメカニズムによって確立されたP2MP PWは、ルートで開始されます。このドキュメントでは、予約済みの値0xFFをワイルドカードトランスポートトンネルタイプに再割り当てすることにより、RFC 7385を更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8338.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8338で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PW Ingress-to-Egress Incompatibility Issues . . . . . . . 6
3.2. P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. P2MP PW Upstream FEC Element . . . . . . . . . . . . 7
3.2.2. P2P PW Downstream FEC Element . . . . . . . . . . . . 11
3.3. Typed Wildcard FEC Format for a New FEC . . . . . . . . . 11
3.4. Group ID Usage . . . . . . . . . . . . . . . . . . . . . 12
3.5. Generic Label TLV . . . . . . . . . . . . . . . . . . . . 12
4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . 12
5. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 15
7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . 15
7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . 15
7.4. Selective Tree Interface Parameter Sub-TLV Type . . . . . 15
7.5. Wildcard PMSI Tunnel Type . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over PSN. A major difference between a Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is intended for bidirectional service whereas the latter is intended for both unidirectional and, optionally, bidirectional service. Requirements for P2MP PWs are described in [RFC7338]. P2MP PWs can be constructed as either Single Segment Pseudowires (P2MP SS-PWs) or Multi-Segment Pseudowires (P2MP MS-PWs) as mentioned in [RFC7338]. P2MP MS-PW is outside the scope of this document. A reference model or a P2MP PW is depicted in Figure 1. A transport Label Switched Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP Traffic Engineering (TE) tunnel established via RSVP-TE [RFC4875] or P2MP LSP established via Multipoint LDP (mLDP) [RFC6388]) spanning from the Root PE (Provider Edge) to the Leaf PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel or P2MP LSP setup using mLDP originating from PE1 and terminating at PE2, PE3, and PE4.
ポイントツーマルチポイント（P2MP）疑似配線（PW）は、P2MP ATM over PSNなどの単方向P2MPテレコミュニケーションサービスの重要な属性をエミュレートします。 [RFC3985]で概説されているポイントツーポイント（P2P）PWとP2MP PWの主な違いは、前者は双方向サービスを対象としているのに対し、後者は単方向サービスとオプションで双方向サービスの両方を対象としていることです。 P2MP PWの要件は、[RFC7338]で説明されています。 [RFC7338]で述べられているように、P2MP PWはシングルセグメント疑似配線（P2MP SS-PW）またはマルチセグメント疑似配線（P2MP MS-PW）として構築できます。 P2MP MS-PWは、このドキュメントの範囲外です。参照モデルまたはP2MP PWを図1に示します。P2MPSS-PWに関連付けられたトランスポートラベルスイッチドパス（LSP）は、RSVP-TEを介して確立されたP2MP MPLS LSP（つまり、P2MPトラフィックエンジニアリング（TE）トンネルである必要があります[ RFC4875]またはマルチポイントLDP（mLDP）[RFC6388]を介して確立されたP2MP LSP）は、ルートPE（プロバイダーエッジ）からP2MP SS-PWツリーのリーフPEにまたがっています。たとえば、図1では、PW1は、PE1から始まりPE2、PE3、およびPE4で終端するmLDPを使用して、P2MP TEトンネルまたはP2MP LSPセットアップに関連付けることができます。
|<--------------P2MP PW---------------->|
Native | | Native
Service | |<--PSN1->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +-----+ +------+ +------+ |
| | | | P1 |=========|T-PE2 |AC3 | +---+
| | | | .......PW1.........>|-------->|CE3|
| |T-PE1|=========| . |=========| | | +---+
| | .......PW1........ | +------+ |
| | . |=========| . | +------+ |
| | . | | . |=========|T-PE3 |AC4 | +---+
+---+ |AC1 | . | | .......PW1.........>|-------->|CE4|
|CE1|------->|... | | |=========| | | +---+
+---+ | | . | +------+ +------+ |
| | . | +------+ +------+ |
| | . |=========| P2 |=========|T-PE4 |AC5 | +---+
| | .......PW1..............PW1.........>|-------->|CE5|
| | |=========| |=========| | | +---+
| +-----+ +------+ +------+ |
Figure 1: P2MP PW
図1：Π2MPPW
Mechanisms for establishing a P2P SS-PW using LDP are described in [RFC8077]. This document specifies a method of signaling P2MP PW using LDP. In particular, this document defines a new Forwarding Equivalence Class (FEC), TLVs, parameters, and status codes to facilitate LDP signaling and maintaining P2MP PWs.
LDPを使用してP2P SS-PWを確立するメカニズムは、[RFC8077]で説明されています。このドキュメントでは、LDPを使用してP2MP PWをシグナリングする方法を指定します。特に、このドキュメントでは、LDPシグナリングとP2MP PWの維持を容易にするために、新しいForwarding Equivalence Class（FEC）、TLV、パラメーター、およびステータスコードを定義しています。
As outlined in [RFC7338], even though the traffic flow from a Root PE (R-PE) to Leaf PE(s) (L-PEs) is P2MP in nature, it may be desirable for any L-PE to send unidirectional P2P traffic destined only to the R-PE. The proposed mechanism takes such an option into consideration.
[RFC7338]で概説されているように、ルートPE（R-PE）からリーフPE（L-PE）へのトラフィックフローは本質的にP2MPですが、L-PEは単方向のP2Pを送信することが望ましい場合がありますR-PE宛てのトラフィック。提案されたメカニズムは、そのようなオプションを考慮に入れています。
The P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS packets carrying the PW upstream label will be encapsulated according to the methods described in [RFC5332].
P2MP PWは、PWトラフィックを伝送するためにMPLS LSPを必要とし、PWアップストリームラベルを伝送するMPLSパケットは、[RFC5332]で説明されている方法に従ってカプセル化されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
AGI: Attachment Group Identifier
AGI：添付ファイルグループ識別子
CE: Customer Edge
CE：カスタマーエッジ
FEC: Forwarding Equivalence Class
FEC：転送同等クラス
L-PE: Leaf PE (egress PE)
L-PE：PEリーフ（PE出力）
LDP: Label Distribution Protocol
LDP：ラベル配布プロトコル
LSP: Label Switched Path
LSP：ラベルスイッチドパス
mLDP: Multipoint Label Distribution Protocol (for P2MP/MP2MP LSP)
mLDP：マルチポイントラベル配布プロトコル（P2MP / MP2MP LSP用）
MS-PW: Multi-Segment Pseudowire
MS-PW：マルチセグメント疑似配線
P2MP: Point-to-Multipoint
P2MP：ポイントツーマルチポイント
P2P: Point-to-Point
P2P：ポイントツーポイント
PE: Provider Edge
PE：プロバイダーエッジ
PSN: Packet Switched Network
PSN：パケット交換ネットワーク
PW: Pseudowire
説明：シュードビル
R-PE: Root PE (ingress PE, PE initiating P2MP PW setup)
R-PE：ルートPE（PE入力、PEがP2MP PWセットアップを開始）
S-PE: Switching Provider Edge (of MS-PW)
S-PE：スイッチングプロバイダーエッジ（MS-PWの）
SS-PW: Single-Segment Pseudowire
SS-PW：単一セグメント疑似配線
TE: Traffic Engineering
て： Ｔらっふぃｃ えんぎねえりんｇ
In order to advertise labels as well as exchange PW-related LDP messages, PEs must establish LDP sessions among themselves. A PE discovers other PEs that are to be connected via P2MP PWs either via manual configuration or autodiscovery [RFC6074].
ラベルをアドバタイズし、PW関連のLDPメッセージを交換するために、PEはそれらの間にLDPセッションを確立する必要があります。 PEは、手動構成または自動検出[RFC6074]を介して、P2MP PWを介して接続される他のPEを検出します。
An R-PE and each L-PE MUST be configured with the same FEC as defined in Section 3.2.
R-PEおよび各L-PEは、セクション3.2で定義されているのと同じFECで構成する必要があります。
P2MP PW requires that there be an active P2MP PSN LSP set up between an R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP is different depending on the signaling protocol used (RSVP-TE or mLDP).
P2MP PWでは、R-PEとL-PEの間にアクティブなP2MP PSN LSPが設定されている必要があります。 P2MP PSN LSPを設定する手順は、使用するシグナリングプロトコル（RSVP-TEまたはmLDP）によって異なることに注意してください。
In the case of mLDP, a Leaf PE can decide to join the P2MP LSP at any time. In the case of RSVP-TE, the P2MP LSP is set up by the R-PE, generally at the initial service provisioning time. It should be noted that local policy can override any decision to join, add, or prune existing or new L-PEs from the tree. In any case, the PW setup can ignore these differences and simply assume that the P2MP PSN LSP is available when needed.
mLDPの場合、リーフPEはいつでもP2MP LSPに参加することを決定できます。 RSVP-TEの場合、P2MP LSPは、通常は初期サービスプロビジョニング時にR-PEによってセットアップされます。ローカルポリシーは、ツリーの既存または新規のL-PEに参加、追加、またはプルーニングする決定を上書きできることに注意してください。いずれの場合でも、PWセットアップはこれらの違いを無視して、必要なときにP2MP PSN LSPが使用可能であると単純に想定できます。
P2MP PW signaling is initiated by the R-PE, which sends a separate P2MP PW LDP Label Mapping Message to each of the L-PE(s) belonging to that P2MP PW. This Label Mapping Message will contain the following:
P2MP PWシグナリングはR-PEによって開始され、R-PEは、そのP2MP PWに属する各L-PEに個別のP2MP PW LDPラベルマッピングメッセージを送信します。このラベルマッピングメッセージには、次のものが含まれます。
1. A FEC TLV containing a P2MP PW Upstream FEC Element that includes a Transport LSP sub-TLV.
1. トランスポートLSPサブTLVを含むP2MP PWアップストリームFEC要素を含むFEC TLV。
2. An Interface Parameters TLV, as described in [RFC8077].
2. [RFC8077]で説明されているインターフェイスパラメータTLV。
3. A PW Group ID TLV, as described in [RFC8077].
3. [RFC8077]で説明されているPWグループID TLV。
4. A label TLV for the upstream-assigned label used by an R-PE for the traffic going from the R-PE to L-PE(s).
4. R-PEからL-PEに向かうトラフィックのためにR-PEによって使用されるアップストリーム割り当てラベルのラベルTLV。
The R-PE imposes the upstream-assigned PW label on the outbound packets sent over the P2MP PW; using this label, an L-PE identifies the inbound packets arriving over the P2MP PW.
R-PEは、P2MP PWを介して送信される送信パケットにアップストリーム割り当てのPWラベルを適用します。このラベルを使用して、L-PEはP2MP PW経由で到着する着信パケットを識別します。
Additionally, the R-PE MAY send Label Mapping Messages to one or more L-PEs to signal a unidirectional P2P PW(s). The L-PE(s) can use such a PW(s) to send traffic to the R-PE. This optional Label Mapping Message will contain the following:
さらに、R-PEは、ラベルマッピングメッセージを1つ以上のL-PEに送信して、単方向のP2P PWをシグナリングする場合があります。 L-PEは、このようなPWを使用してトラフィックをR-PEに送信できます。このオプションのラベルマッピングメッセージには、次のものが含まれます。
1. A P2P PW Downstream FEC Element
1. P2P PWダウンストリームFEC要素
2. A label TLV for the downstream-assigned label used by the corresponding L-PE to send traffic to the R-PE
2. R-PEにトラフィックを送信するために対応するL-PEによって使用されるダウンストリーム割り当てラベルのラベルTLV
The LDP liberal label retention mode MUST be used; per requirements specified in [RFC5036], the Label Request message MUST also be supported.
LDPリベラルラベル保持モードを使用する必要があります。 [RFC5036]で指定された要件ごとに、ラベル要求メッセージもサポートする必要があります。
The upstream-assigned label is allocated according to the rules in [RFC5331].
アップストリームに割り当てられたラベルは、[RFC5331]のルールに従って割り当てられます。
When an L-PE receives a PW Label Mapping Message, it MUST verify the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place and its type is LDP P2MP LSP, the L-PE MUST attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW and MUST notify the user. In this case, a PW status message with status code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST also be sent to the R-PE.
L-PEがPWラベルマッピングメッセージを受信すると、関連付けられたP2MP PSN LSPが配置されていることを確認する必要があります。関連付けられたP2MP PSN LSPが所定の場所になく、そのタイプがLDP P2MP LSPである場合、L-PEは、P2MP PWに関連付けられたP2MP LSPへの参加を試行する必要があります。関連付けられたP2MP PSN LSPが配置されておらず、そのタイプがRSVP-TE P2MP LSPである場合、L-PEは、P2MPトランスポートLSPが通知されるまで待機する必要があります。 L-PEがP2MP PSN LSPに参加できない場合、そのL-PEはPWを有効にしてはならず（MUST）、ユーザーに通知しなければなりません（MUST）。この場合、ステータスコード0x00000008のPWステータスメッセージ（ローカルPSNに面するPW（入力）受信障害）もR-PEに送信する必要があります。
If an R-PE signals a PW with a PW Type, Control Word (CW) mode, or interface parameters that a particular L-PE cannot accept, then the L-PE MUST NOT enable the PW and should notify the user. In this case, a PW status message with status code of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent to the R-PE.
R-PEが、PWタイプ、コントロールワード（CW）モード、または特定のL-PEが受け入れることができないインターフェイスパラメーターを使用してPWを通知する場合、L-PEはPWを有効にしてはならず、ユーザーに通知する必要があります。この場合、ステータスコード0x00000001（Pseudowire Not Forwarding）のPWステータスメッセージもR-PEに送信する必要があります。
Note that this procedure does not apply if the L-PE was not provisioned with this particular P2MP PW. In this case, according to the LDP liberal label retention rules, no action is taken.
L-PEがこの特定のP2MP PWでプロビジョニングされていない場合、この手順は適用されないことに注意してください。この場合、LDPリベラルラベル保持ルールに従って、アクションは実行されません。
[RFC8077] specifies two types of LDP FEC elements used to signal P2P PWs: "PWid FEC Element" and "Generalized PWid FEC Element". This document uses two FEC elements: "P2MP PW Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC elements are associated with a mandatory upstream-assigned label and an optional downstream-assigned label, respectively.
[RFC8077]は、P2P PWを通知するために使用される2つのタイプのLDP FEC要素、「PWid FEC Element」と「Generalized PWid FEC Element」を指定します。このドキュメントでは、「P2MP PWアップストリームFECエレメント」と「P2P PWダウンストリームFECエレメント」の2つのFECエレメントを使用しています。これらのFEC要素は、必須の上流割り当てラベルとオプションの下流割り当てラベルにそれぞれ関連付けられています。
The FEC type for the P2MP PW Upstream FEC Element is encoded as follows:
P2MP PWアップストリームFEC要素のFECタイプは、次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP PW Up=0x82|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PMSI Tunnel Typ|PMSI TT Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ +
~ Transport LSP ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: P2MP PW Upstream FEC Element
図2：P2MP PWアップストリームFEC要素
* P2MP PW Up:
* P2MP PW Up：
8-bit representation for the P2MP PW Upstream FEC type.
P2MP PWアップストリームFECタイプの8ビット表現。
* C bit:
* Cビット：
A value of 1 or 0 indicating whether a control word is present or absent for the P2MP PW.
P2MP PWのコントロールワードの有無を示す1または0の値。
* PW Type:
* PWタイプ：
15-bit representation of PW Type as specified in [RFC8077].
[RFC8077]で指定されているPWタイプの15ビット表現。
* PW Info Length:
* PW情報の長さ：
Sum of the AGI Length, SAII Length, PMSI Tunnel Type Length, and Optional Parameters fields in octets. If this value is 0, then it references all PWs using the specified group ID. In this case, there are neither other FEC element fields (AGI Type, SAII Value, etc.) present, nor any interface parameters TLVs. Alternatively, typed wildcard FEC described in Section 2.3, can be used to achieve the same or to have better filtering.
オクテットのAGI長、SAII長、PMSIトンネルタイプ長、およびオプションパラメータフィールドの合計。この値が0の場合、指定されたグループIDを使用してすべてのPWを参照します。この場合、他のFEC要素フィールド（AGIタイプ、SAII値など）も、インターフェイスパラメーターTLVも存在しません。あるいは、セクション2.3で説明されているタイプ付きワイルドカードFECを使用して、同じことを達成したり、より優れたフィルタリングを行うことができます。
* AGI:
* AGI：
An Attachment Group Identifier TLV can be used to uniquely identify a VPN or Virtual Private LAN Service (VPLS) instance associated with the P2MP PW. This has the same format as the Generalized PWid FEC Element [RFC8077].
アタッチメントグループ識別子TLVを使用して、P2MP PWに関連付けられたVPNまたは仮想プライベートLANサービス（VPLS）インスタンスを一意に識別できます。これは、一般化されたPWid FEC要素[RFC8077]と同じ形式です。
* SAII Value:
* SAII値：
A Source Attachment Individual Identifier is used to identify the root of the P2MP PW. The root is represented using AII Type 2 format specified in [RFC5003]. Note that the SAII can be omitted by simply setting the length and type to zero.
ソースアタッチメント個別識別子は、P2MP PWのルートを識別するために使用されます。ルートは、[RFC5003]で指定されたAIIタイプ2形式を使用して表されます。 SAIIは、長さとタイプをゼロに設定するだけで省略できることに注意してください。
The P2MP PW is identified by the Source Attachment Identifier (SAI). If the AGI is non-null, the SAI is the combination of the SAII and the AGI, if the AGI is null, the SAI is the SAII.
P2MP PWは、Source Attachment Identifier（SAI）によって識別されます。 AGIがnullでない場合、SAIはSAIIとAGIの組み合わせであり、AGIがnullの場合、SAIはSAIIです。
* PMSI Tunnel Info:
* PMSIトンネル情報：
The PMSI Tunnel Info is the combination of the PMSI Tunnel Type, PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), and Transport LSP ID fields.
PMSIトンネル情報は、PMSIトンネルタイプ、PMSIトンネルタイプの長さ（図ではPMSI TT長として示されています）、およびトランスポートLSP IDフィールドの組み合わせです。
A P2MP PW MUST be associated with a transport LSP, which can be established using RSVP-TE or mLDP.
P2MP PWは、RSVP-TEまたはmLDPを使用して確立できるトランスポートLSPに関連付ける必要があります。
* PMSI Tunnel Type:
* PMSIトンネルタイプ：
The PMSI Tunnel Type is defined in [RFC6514].
PMSIトンネルタイプは[RFC6514]で定義されています。
When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element as defined in [RFC6388]. The new mLDP Opaque Value Element type for the L2VPN-MCAST application TLV (as specified in the IANA Considerations section (Section 7)) MUST be used.
タイプがmLDP P2MP LSPに設定されている場合、トンネル識別子は、[RFC6388]で定義されているP2MP FEC要素です。 L2VPN-MCASTアプリケーションTLVの新しいmLDP Opaque Value Elementタイプ（IANAの考慮事項セクション（セクション7）で指定）を使用する必要があります。
* Transport LSP ID:
* トランスポートLSP ID：
This is the Tunnel Identifier that is defined in [RFC6514].
これは、[RFC6514]で定義されているトンネル識別子です。
An R-PE sends a Label Mapping Message as soon as the transport LSP ID associated with the P2MP PW is known (e.g., via configuration) regardless of the operational state of that transport LSP.
R2 PEは、そのトランスポートLSPの動作状態に関係なく、P2MP PWに関連付けられたトランスポートLSP IDが（構成などによって）わかるとすぐにラベルマッピングメッセージを送信します。
Similarly, an R-PE does not withdraw the labels when the corresponding transport LSP goes down. Furthermore, an L-PE retains the P2MP PW labels regardless of the operational status of the transport LSP.
同様に、対応するトランスポートLSPがダウンしても、R-PEはラベルを撤回しません。さらに、L-PEは、トランスポートLSPの動作ステータスに関係なく、P2MP PWラベルを保持します。
Note that a given transport LSP can be associated with more than one P2MP PW; in which case, P2MP PWs will be sharing the same R-PE and L-PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets.
特定のトランスポートLSPを複数のP2MP PWに関連付けることができることに注意してください。この場合、P2MP PWは同じR-PEおよびL-PEを共有します。 R-PEには、互いに素なL-PEセットを持つ多くのP2MP PWがある場合もあります。
In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping Message, it can initiate the process of joining the P2MP LSP tree associated with the P2MP PW.
LDP P2MP LSPの場合、L-PEはラベルマッピングメッセージを受信すると、P2MP PWに関連付けられたP2MP LSPツリーに参加するプロセスを開始できます。
In the case of RSVP-TE P2MP LSP, only the R-PE initiates the signaling of P2MP LSP.
RSVP-TE P2MP LSPの場合、R-PEのみがP2MP LSPのシグナリングを開始します。
* Optional Parameters:
* オプションのパラメーター：
The Optional Parameter field can contain some TLVs that are not part of the FEC, but are necessary for the operation of the PW. This proposed mechanism uses two such TLVs: the Interface Parameters TLV and the PW Group ID TLV.
オプションパラメータフィールドには、FECの一部ではないがPWの操作に必要ないくつかのTLVを含めることができます。この提案されたメカニズムは、そのような2つのTLVを使用します。インターフェイスパラメータTLVとPWグループID TLVです。
The Interface Parameters TLV and PW Group ID TLV specified in [RFC8077] can also be used in conjunction with P2MP PW FEC in a label message. For the PW Group ID TLV, the sender and receiver of these TLVs should follow the same rules and procedures specified in [RFC8077]. For the Interface Parameters TLV, the procedure differs from the one specified in [RFC8077] due to specifics of P2MP connectivity. When the interface parameters are signaled by an R-PE, each L-PE must check if its configured value(s) is less than or equal to the threshold value provided by the R-PE (e.g., MTU size (Ethernet), max number of concatenated ATM cells, etc.). For other interface parameters, like CEP/TDM Payload Bytes, the value MUST exactly match the values signaled by the R-PE.
[RFC8077]で指定されているインターフェイスパラメータTLVおよびPWグループID TLVは、ラベルメッセージでP2MP PW FECと組み合わせて使用することもできます。 PWグループID TLVの場合、これらのTLVの送信者と受信者は、[RFC8077]で指定されているのと同じルールと手順に従う必要があります。インターフェイスパラメータTLVの場合、手順はP2MP接続の仕様により[RFC8077]で指定されているものとは異なります。インターフェイスパラメータがR-PEによってシグナリングされた場合、各L-PEは、その設定値がR-PEによって提供されるしきい値（たとえば、MTUサイズ（イーサネット）、最大値）以下であるかどうかを確認する必要があります連結されたATMセルの数など）。 CEP / TDMペイロードバイトなどの他のインターフェイスパラメータの場合、値はR-PEによってシグナリングされた値と正確に一致する必要があります。
A multicast traffic stream associated with a P2MP PW can be selective or inclusive. To support the former, this document defines a new optional Selective Tree Interface Parameter sub-TLV, as described in the IANA Considerations section (Section 7) and according to the format described in [RFC8077]. The value of the sub-TLV contains the source and the group for a given multicast tree, as shown in Figure 3. Also, if a P2MP PW is associated with multiple selective trees, the corresponding Label Mapping Message will carry more than one instance of this sub-TLV. Furthermore, in the absence of this sub-TLV, the P2MP PW is associated with all multicast traffic streams originating from the root.
P2MP PWに関連付けられたマルチキャストトラフィックストリームは、選択的または包括的です。前者をサポートするために、このドキュメントでは、IANAの考慮事項セクション（セクション7）で説明されているように、[RFC8077]で説明されている形式に従って、新しいオプションの選択ツリーインターフェイスパラメーターサブTLVを定義します。図3に示すように、サブTLVの値には、特定のマルチキャストツリーのソースとグループが含まれます。また、P2MP PWが複数の選択ツリーに関連付けられている場合、対応するラベルマッピングメッセージは、このサブTLV。さらに、このサブTLVがない場合、P2MP PWはルートから発信されるすべてのマルチキャストトラフィックストリームに関連付けられます。
+-----------------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------------+
| Length (1 Octet) |
+-----------------------------------------+
| Multicast Source Length (1 Octet) |
+-----------------------------------------+
| Multicast Source (variable length) |
+-----------------------------------------+
| Multicast Group Length (1 Octet) |
+-----------------------------------------+
| Multicast Group (variable length) |
+-----------------------------------------+
Figure 3: Selective Tree Interface Parameter Sub-TLV Value
図3：選択的ツリーインターフェイスパラメーターのサブTLV値
Note that since the LDP Label Mapping Message is only sent by the R-PE to all the L-PEs, it is not possible to negotiate any interface parameters.
LDPラベルマッピングメッセージはR-PEからすべてのL-PEにのみ送信されるため、インターフェイスパラメータをネゴシエートすることはできないことに注意してください。
The optional P2P PW Downstream FEC Element is encoded as follows:
オプションのP2P PWダウンストリームFEC要素は、次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2P PWDown=0x84|C| PW Type | PW Info Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: P2P PW Downstream FEC Element
図4：P2P PWダウンストリームFEC要素
The definition of the fields in the P2P PW Downstream FEC Element is the same as those of P2MP PW Upstream FEC Element, shown in Figure 2.
P2P PWダウンストリームFECエレメントのフィールドの定義は、図2に示すP2MP PWアップストリームFECエレメントのフィールドの定義と同じです。
[RFC5918] defines the general notion of a Typed Wildcard FEC Element; it requires FEC designers to specify a Typed Wildcard FEC Element for newly defined FEC element types. This document uses two FEC elements: "P2MP PW Upstream" and "P2P PW Downstream". Hence, definition of their Typed Wildcard format is required.
[RFC5918]は、型付きワイルドカードFEC要素の一般的な概念を定義しています。 FEC設計者は、新しく定義されたFEC要素タイプに対して、型付きワイルドカードFEC要素を指定する必要があります。このドキュメントでは、「P2MP PWアップストリーム」と「P2P PWダウンストリーム」という2つのFEC要素を使用しています。したがって、それらのTyped Wildcard形式の定義が必要です。
[RFC6667] defines the Typed Wildcard FEC Element format for other PW FEC Element types (PWid and Generalized PWid FEC Element) in Section 3 as follows:
[RFC6667]は、セクション3で他のPW FEC要素タイプ（PWidおよび一般化PWid FEC要素）の型付きワイルドカードFEC要素形式を次のように定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | PMSI Tun Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Typed Wildcard Format for P2MP PW FEC Elements
図5：P2MP PW FEC要素の型付きワイルドカード形式
[RFC6667] specifies that the Type field can be either the "PWid" (0x80) or "Generalized PWid" (0x81) FEC Element type. This document reuses the existing Typed Wildcard format specified in [RFC6667] and illustrated in Figure 5 and extends the definition of the Type field to also include the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element types. This document adds an additional field called the "PMSI Tunnel Type". This document reserves PMSI Tunnel Type 0xFF to mean "wildcard transport tunnel type". The PMSI Tunnel Type field only applies to the Typed Wildcard P2MP PW Upstream FEC Element and MUST be set to "wildcard" for "P2P PW Downstream FEC Element" typed wildcard.
[RFC6667]は、Typeフィールドが "PWid"（0x80）または "Generalized PWid"（0x81）FEC Elementタイプのいずれかになることを指定しています。このドキュメントは、[RFC6667]で指定され、図5に示されている既存のTyped Wildcard形式を再利用し、Typeフィールドの定義を拡張して、P2MP PWアップストリームFECエレメントおよびP2P PWダウンストリームFECエレメントタイプも含めるようにします。このドキュメントは、「PMSIトンネルタイプ」と呼ばれる追加フィールドを追加します。このドキュメントでは、「ワイルドカードトランスポートトンネルタイプ」を意味するPMSIトンネルタイプ0xFFを予約しています。 PMSIトンネルタイプフィールドは、タイプ付きワイルドカードP2MP PWアップストリームFECエレメントにのみ適用され、「P2P PWダウンストリームFECエレメント」タイプ付きワイルドカードに対して「ワイルドカード」に設定する必要があります。
The PW Group ID TLV as defined in [RFC8077] contains a group ID capable of indicating an arbitrary group membership of a P2MP PW. This group ID can be used in LDP "wildcard" status and withdraw label messages, as described in [RFC8077].
[RFC8077]で定義されているPWグループID TLVには、P2MP PWの任意のグループメンバーシップを示すことができるグループIDが含まれています。このグループIDは、[RFC8077]で説明されているように、LDPの「ワイルドカード」ステータスとwithdraw labelメッセージで使用できます。
As in the case of P2P PW signaling, P2MP PW labels are carried within the Generic Label TLV contained in the LDP Label Mapping Message. A Generic Label TLV is formatted and processed as per the rules and procedures specified in [RFC8077]. For a given P2MP PW, a single upstream-assigned label is allocated by the R-PE and is advertised to all L-PEs using the Generic Label TLV in Label Mapping Messages containing the P2MP PW Upstream FEC Element.
P2P PWシグナリングの場合と同様に、P2MP PWラベルは、LDPラベルマッピングメッセージに含まれるGeneric Label TLV内で運ばれます。 Generic Label TLVは、[RFC8077]で指定されたルールと手順に従ってフォーマットおよび処理されます。特定のP2MP PWについて、単一のアップストリーム割り当てラベルがR-PEによって割り当てられ、P2MP PWアップストリームFEC要素を含むラベルマッピングメッセージのGeneric Label TLVを使用してすべてのL-PEにアドバタイズされます。
The R-PE can also allocate a unique label for each L-PE from which it intends to receive P2P traffic. Such a label is advertised to the L-PE using the Generic Label TLV and P2P PW Downstream FEC Element in Label Mapping Messages.
R-PEは、P2Pトラフィックの受信元となる各L-PEに一意のラベルを割り当てることもできます。このようなラベルは、ラベルマッピングメッセージのGeneric Label TLVおよびP2P PWダウンストリームFEC要素を使用してL-PEにアドバタイズされます。
The capability of supporting P2MP PWs MUST be advertised to all LDP peers. This is achieved by using the methods in [RFC5561] to advertise the LDP P2MP PW Capability TLV. If an LDP peer supports the dynamic capability advertisement, this can be done by sending a new Capability message with the S bit set for the P2MP PW Capability TLV. If the peer does not support dynamic capability advertisement, then the P2MP PW Capability TLV MUST be included in the LDP Initialization message during session establishment. A Label Switched Router (LSR) having P2MP PW capability MUST recognize both the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in LDP label messages.
P2MP PWをサポートする機能は、すべてのLDPピアにアドバタイズされる必要があります。これは、[RFC5561]のメソッドを使用して、LDP P2MP PW機能TLVをアドバタイズすることによって実現されます。 LDPピアが動的機能アドバタイズメントをサポートしている場合、これは、P2MP PW機能TLVのSビットが設定された新しい機能メッセージを送信することで実行できます。ピアが動的機能アドバタイズメントをサポートしていない場合、P2MP PW機能TLVがセッション確立中のLDP初期化メッセージに含まれている必要があります。 P2MP PW機能を持つラベルスイッチドルータ（LSR）は、LDPラベルメッセージ内のP2MP PWアップストリームFEC要素とP2P PWダウンストリームFEC要素の両方を認識しなければなりません（MUST）。
In line with requirements listed in [RFC5561], the following TLV is defined to indicate the P2MP PW capability:
[RFC5561]にリストされている要件に沿って、P2MP PW機能を示すために次のTLVが定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| P2MP PW Capability TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: LDP P2MP PW Capability TLV
図6：LDP P2MP PW機能TLV
* U bit:
* Uビット：
The Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood).
不明なビット[RFC5036]は1であるべきです（理解できない場合は無視してください）。
* F bit:
* Fビット：
The Forward unknown bit [RFC5036] SHOULD be 0 (don't forward if not understood).
Forward unknown bit [RFC5036]は0であるべきです（理解できない場合は転送しないでください）。
* P2MP PW Capability TLV Code Point:
* P2MP PW機能TLVコードポイント：
The TLV type, which identifies a specific capability. Note that the P2MP PW Capability Code Point appears in the IANA Considerations section (Section 7).
特定の機能を識別するTLVタイプ。 P2MP PW機能コードポイントは、IANAに関する考慮事項のセクション（セクション7）に記載されています。
* S bit:
* Sビット：
The State Bit indicates whether the sender is advertising or withdrawing the P2MP PW capability. The State bit is used as follows:
状態ビットは、送信者がP2MP PW機能をアドバタイズしているか、撤回しているかを示します。状態ビットは次のように使用されます。
1 - The TLV is advertising the capability specified by the P2MP PW Capability TLV Code Point.
1-TLVは、P2MP PW機能TLVコードポイントで指定された機能をアドバタイズしています。
0 - The TLV is withdrawing the capability specified by the P2MP PW Capability TLV Code Point.
0-TLVは、P2MP PW機能TLVコードポイントで指定された機能を撤回しています。
* Length:
* 長さ：
MUST be set to 2 (octet).
2（オクテット）に設定する必要があります。
In order to support the proposed mechanism, an LSR MUST be capable of handling PW status. As such, the PW status negotiation procedures described in [RFC8077] are not applicable to P2MP PW. An LSR MUST NOT claim to be P2MP PW capable by sending an LDP P2MP PW Capability TLV if it is not also capable of handling PW status.
提案されたメカニズムをサポートするために、LSRはPWステータスを処理できなければなりません（MUST）。そのため、[RFC8077]で説明されているPWステータスネゴシエーション手順は、P2MP PWには適用されません。 LSRは、PWステータスを処理することもできない場合、LDP P2MP PW機能TLVを送信することによってP2MP PW対応であることを主張してはなりません。
Once an L-PE successfully processes a Label Mapping Message for a P2MP PW, it MUST send appropriate PW status according to the procedure specified [RFC8077] to report the PW status. If no PW status notification is required, then no PW status notification is sent (for example, if the P2MP PW is established and operational with a status code of 0x00000000 (Success), a PW status message is not necessary). A PW status message sent from an L-PE to an R-PE MUST contain the P2P PW Downstream FEC Element to identify the PW.
L-PEがP2MP PWのラベルマッピングメッセージを正常に処理したら、指定された手順[RFC8077]に従って適切なPWステータスを送信して、PWステータスを報告する必要があります。 PWステータス通知が不要な場合、PWステータス通知は送信されません（たとえば、P2MP PWが確立されており、ステータスコード0x00000000（成功）で動作している場合、PWステータスメッセージは不要です）。 L-PEからR-PEに送信されるPWステータスメッセージには、PWを識別するためのP2P PWダウンストリームFECエレメントが含まれている必要があります。
An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP PW state. Such a PW status message contains a P2MP PW Upstream FEC Element to identify the PW.
R-PEは、P2MP PW状態のビューを反映するために、PWステータスをL-PEにも送信します。このようなPWステータスメッセージには、PWを識別するためのP2MP PWアップストリームFECエレメントが含まれています。
Connectivity status of the underlying P2MP LSP that the P2MP PW is associated with can be verified using LSP ping and traceroute procedures described in [RFC6425].
P2MP PWが関連付けられている基礎となるP2MP LSPの接続ステータスは、[RFC6425]で説明されているLSP pingおよびtraceroute手順を使用して確認できます。
In general, the security measures described in [RFC8077] are adequate for this protocol. However, the use of MD5 as the method of securing an LDP control plane is no longer considered adequately secure. Implementations should be written in such a way that they can migrate to a more secure cryptographic hash function when the next authentication method to be used in the LDP might not be a simple hash-based authentication algorithm.
一般に、[RFC8077]で説明されているセキュリティ対策は、このプロトコルに適しています。ただし、LDPコントロールプレーンを保護する方法としてMD5を使用することは、十分に安全であるとは見なされなくなりました。実装は、LDPで使用される次の認証方法が単純なハッシュベースの認証アルゴリズムではない場合に、より安全な暗号化ハッシュ関数に移行できるように作成する必要があります。
This document uses two FEC element types, 0x82 and 0x84, in the "Forwarding Equivalence Class (FEC) Type Name Space" registry for the Label Distribution Protocol (LDP) [RFC5036]. IANA has added this document as a reference for the following entries:
このドキュメントでは、Label Distribution Protocol（LDP）[RFC5036]の「Forwarding Equivalence Class（FEC）Type Name Space」レジストリで2つのFEC要素タイプ、0x82と0x84を使用しています。 IANAは、このドキュメントを次のエントリの参照として追加しました。
Value Hex Name Reference
------ ----- ----------------------------- --------------------
130 0x82 P2MP PW Upstream FEC Element [RFC8338] [RFC7358]
132 0x84 P2P PW Downstream FEC Element [RFC8338] [RFC7358]
This document defines a new LDP TLV type in the "TLV Type Name Space" registry [RFC5036]. IANA has assigned the following value:
このドキュメントでは、「TLVタイプ名前空間」レジストリ[RFC5036]で新しいLDP TLVタイプを定義しています。 IANAは次の値を割り当てました。
TLV Type Description
-------- ----------------------
0x0703 P2MP PW Capability TLV
IANA has assigned a new mLDP Opaque Value Element Type in the "LDP MP Opaque Value Element basic type" registry [RFC6388] as follows:
IANAは、「LDP MP Opaque Value Element Basic Type」レジストリ[RFC6388]に次のように新しいmLDP Opaque Value Element Typeを割り当てました。
TLV Type Description
------- ---------------------------
13 L2VPN-MCAST application TLV
Length: 4
長さ：4
Value: A 32-bit integer, unique in the context of the root, as identified by the root's address.
値：ルートのアドレスによって識別される、ルートのコンテキストで一意の32ビット整数。
IANA has assigned a sub-TLV from the "Pseudowire Interface Parameters Sub-TLV type Registry" [RFC4446] as follows:
IANAは、「Pseudowire Interface Parameters Sub-TLV type Registry」[RFC4446]からサブTLVを次のように割り当てました。
TLV Type Description
-------- ----------------------------------
0x1B Selective Tree Interface Parameter
IANA has modified an entry in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry [RFC7385]. Value 0xFF, which was previously marked as "Reserved", has been updated as follows:
IANAは、「Border Gateway Protocol（BGP）Parameters」レジストリ[RFC7385]内の「P-Multicast Service Interface Tunnel（PMSI Tunnel）Tunnel Types」レジストリのエントリを変更しました。以前は「予約済み」としてマークされていた値0xFFが次のように更新されました。
Value Meaning Reference
----- ------------------------------ ---------
0xFF wildcard transport tunnel type [RFC8338]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANA割り当て」、BCP 116、RFC 4446、DOI 10.17487 / RFC4446、2006年4月、<https://www.rfc-editor.org/info / rfc4446>。
[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, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[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、DOI 10.17487 / RFC4875、2007年5月、<https://www.rfc-editor.org/info/rfc4875>。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, DOI 10.17487/RFC5003, September 2007, <https://www.rfc-editor.org/info/rfc5003>.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「Attachment Individual Identifier（AII）Types for Aggregation」、RFC 5003、DOI 10.17487 / RFC5003、2007年9月、<https：/ /www.rfc-editor.org/info/rfc5003>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https：// www。 rfc-editor.org/info/rfc5036>。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、DOI 10.17487 / RFC5331、2008年8月、<https：//www.rfc -editor.org/info/rfc5331>。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.
[RFC5332] Eckert、T.、Rosen、E.、Ed。、Aggarwal、R。、およびY. Rekhter、「MPLSマルチキャストカプセル化」、RFC 5332、DOI 10.17487 / RFC5332、2008年8月、<https：// www。 rfc-editor.org/info/rfc5332>。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、DOI 10.17487 / RFC5561、2009年7月、<https://www.rfc-editor.org/info/rfc5561>。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, <https://www.rfc-editor.org/info/rfc5918>.
[RFC5918] Asati、R.、Minei、I。、およびB. Thomas、「Label Distribution Protocol（LDP） 'Typed Wildcard' Forward Equivalence Class（FEC）」、RFC 5918、DOI 10.17487 / RFC5918、2010年8月、<https ：//www.rfc-editor.org/info/rfc5918>。
[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, DOI 10.17487/RFC6388, November 2011, <https://www.rfc-editor.org/info/rfc6388>.
[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、DOI 10.17487 / RFC6388、2011年11月、<https://www.rfc-editor.org/info/rfc6388>。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、DOI 10.17487 / RFC6514、2012年2月、< https://www.rfc-editor.org/info/rfc6514>。
[RFC6667] Raza, K., Boutros, S., and C. Pignataro, "LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements", RFC 6667, DOI 10.17487/RFC6667, July 2012, <https://www.rfc-editor.org/info/rfc6667>.
[RFC6667] Raza、K.、Boutros、S。、およびC. Pignataro、「PWidおよび一般化されたPWid FEC要素のLDP 'Typed Wildcard' Forwarding Equivalence Class（FEC）」、RFC 6667、DOI 10.17487 / RFC6667、2012年7月、 <https://www.rfc-editor.org/info/rfc6667>。
[RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <https://www.rfc-editor.org/info/rfc7385>.
[RFC7385] Andersson、L.およびG. Swallow、「I-ANA Registry for P-Multicast Service Interface（PMSI）Tunnel Type Code Points」、RFC 7385、DOI 10.17487 / RFC7385、2014年10月、<https：//www.rfc- editor.org/info/rfc7385>。
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077]マティーニ、L。、エド。 and G. Heron、Ed。、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、STD 84、RFC 8077、DOI 10.17487 / RFC8077、February 2017、<https://www.rfc-editor.org/ info / rfc8077>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https://www.rfc-editor.org/info/rfc3985 >。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、DOI 10.17487 / RFC6074 、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>.
[RFC6425] Saxena、S.、Ed。、Swallow、G.、Ali、Z.、Farrel、A。、安川S.、およびT. Nadeau、「ポイントツーマルチポイントMPLSでのデータプレーン障害の検出- LSP Pingの拡張機能」、RFC 6425、DOI 10.17487 / RFC6425、2011年11月、<https://www.rfc-editor.org/info/rfc6425>。
[RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", RFC 7338, DOI 10.17487/RFC7338, September 2014, <https://www.rfc-editor.org/info/rfc7338>.
[RFC7338] Jounay、F.、Ed。、Kamite、Y.、Ed。、Heron、G.、and M. Bocci、 "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks"、RFC 7338、 DOI 10.17487 / RFC7338、2014年9月、<https://www.rfc-editor.org/info/rfc7338>。
[RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October 2014, <https://www.rfc-editor.org/info/rfc7358>.
[RFC7358] Raza、K.、Boutros、S.、Martini、L。、およびN. Leymann、「Label Advertisement Discipline for LDP Forwarding Equivalence Classes（FECs）」、RFC 7358、DOI 10.17487 / RFC7358、2014年10月、<https ：//www.rfc-editor.org/info/rfc7358>。
Acknowledgments
謝辞
The authors would like to thank Andre Pelletier and Parag Jain for their valuable suggestions.
著者は、貴重な提案をしてくれたAndre PelletierとParag Jainに感謝します。
Contributors
貢献者
The following people contributed substantially to the content of this document and should be considered coauthors:
次の人々はこのドキュメントの内容に実質的に貢献し、共著者と見なされるべきです：
Luca Martini Cisco Systems, Inc.
Luca Martini Cisco Systems、Inc.
Email: lmartini@cisco.com
Maciek Konstantynowicz Cisco Systems, Inc.
Maciek Konstantynowicz Cisco Systems、Inc.
Email: maciek@cisco.com Gianni Del Vecchio Swisscom
メール：maciek@cisco.com Gianni Del Vecchio Swisscom
Email: Gianni.DelVecchio@swisscom.com
Thomas D. Nadeau Brocade
トーマス・D・ナドー・ブロケード
Email: tnadeau@lucidvision.com
Frederic Jounay Orange CH
フレデリックジュネオレンジCH
Email: Frederic.Jounay@salt.ch
Philippe Niger Orange CH
フィリップニジェールオレンジCH
Email: philippe.niger@orange.com
Yuji Kamite NTT Communications Corporation
UG Commit Nutt Communications Corporation
Email: y.kamite@ntt.com
Lizhong Jin
私は一種のジン
Email: lizho.jin@gmail.com
Martin Vigoureux Nokia
マーティンヴィグールーノキア
Email: martin.vigoureux@nokia.com
Laurent Ciavaglia Nokia
ローラン・シアンフロン・ノキア
Email: laurent.ciavaglia@nokia.com
Simon Delord Telstra
サイモンデロードテルストラ
Email: simon.delord@gmail.com
Kamran Raza Cisco Systems
カムランラジャシスコシステムズ
Email: skraza@cisco.com
Authors' Addresses
著者のアドレス
Sami Boutros (editor) VMware, Inc.
Sami Boutros（編集者）VMware、Inc.
Email: sboutros@vmware.com
Siva Sivabalan (editor) Cisco Systems, Inc.
Shiva Sivabalan（編集者）Cisco Systems、Inc.
Email: msiva@cisco.com