[要約] RFC 7246は、仮想ルーティングおよびフォワーディング（VRF）テーブルコンテキストでのマルチポイントラベル配布プロトコル（MLDP）インバンドシグナリングに関するものです。このRFCの目的は、VRFテーブル内でのMLDPの効果的な使用を可能にするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7246 Cisco Systems
Category: Standards Track P. Hitchen
ISSN: 2070-1721 BT
N. Leymann
Deutsche Telekom
W. Henderickx
Alcatel-Lucent
A. Gulko
Thomson Reuters
J. Tantsura
Ericsson
June 2014
Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
Virtual Routing and Forwarding（VRF）テーブルコンテキストでのマルチポイントラベル配布プロトコルインバンドシグナリング
Abstract
概要
An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.
IPマルチキャスト配信ツリー（MDT）は、ネットワークのラベルスイッチング（マルチプロトコルラベルスイッチング、またはMPLS）と非ラベルスイッチングの両方の領域を通過できます。通常、MDTは非MPLSリージョンで開始および終了しますが、MPLSリージョンを通過します。そのような場合、MDTを純粋なIP MDTとして構築し始め、それがMPLS対応の領域に入るときにMPLSマルチポイントラベルスイッチドパス（MP-LSP）に変換し、次に変換して戻すと便利です。 MPLSが有効になっていないリージョンに入るときの純粋なIP MDT。他のドキュメントでは、ネットワークの非MPLSリージョンでProtocol Independent Multicast（PIM）を使用し、MPLSリージョンでMultipoint Label Distribution Protocol（mLDP）を使用して、このようなハイブリッドMDTを構築する手順を指定しています。このドキュメントでは、これらの手順を拡張して、「BGP IP / MPLS VPN」仕様で定義されているように、2つのリージョンを接続するリンクが仮想ルーティングおよび転送（VRF）テーブルリンクである場合を処理します。ただし、このドキュメントは主に、VRFを使用してマルチキャストVPN以外のマルチキャストアプリケーションをサポートする特定の使用例を対象としています。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7246.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7246で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. VRF In-Band Signaling for MP LSPs . . . . . . . . . . . . . . 5
3. Encoding the Opaque Value of an LDP MP FEC . . . . . . . . . . 7
3.1. Transit VPNv4 Source TLV . . . . . . . . . . . . . . . . . 7
3.2. Transit VPNv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit VPNv4 Bidir TLV . . . . . . . . . . . . . . . . . 9
3.4. Transit VPNv6 Bidir TLV . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Sometimes an IP Multicast Distribution Tree (MDT) traverses both MPLS-enabled and non-MPLS-enabled regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends the procedures from [RFC6826] to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification [RFC6513]. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.
IPマルチキャスト配布ツリー（MDT）は、ネットワークのMPLS対応領域と非MPLS対応領域の両方を通過する場合があります。通常、MDTは非MPLSリージョンで開始および終了しますが、MPLSリージョンを通過します。このような場合、MDTを純粋なIP MDTとして構築し始め、MPLS対応リージョンに入るときにMPLSマルチポイントラベルスイッチドパス（LSP）に変換してから、純粋なIPに戻すと便利です。 MPLSが有効になっていない領域に入るときのMDT。他のドキュメントでは、ネットワークの非MPLSリージョンでProtocol Independent Multicast（PIM）を使用し、MPLSリージョンでMultipoint Label Distribution Protocol（mLDP）を使用して、このようなハイブリッドMDTを構築する手順を指定しています。このドキュメントは、[BGP IP / MPLS VPN]仕様[RFC6513]で定義されているように、2つの領域を接続するリンクが仮想ルーティングおよび転送（VRF）テーブルリンクである場合を処理するために[RFC6826]から手順を拡張します。ただし、このドキュメントは主に、VRFを使用してマルチキャストVPN以外のマルチキャストアプリケーションをサポートする特定の使用例を対象としています。
In PIM, a tree is identified by a source address (or in the case of bidirectional trees [RFC5015], a rendezvous point address or "RPA") and a group address. The tree is built from the leaves up, by sending PIM control messages in the direction of the source address or the RPA. In mLDP, a tree is identified by a root address and an "opaque value", and is built by sending mLDP control messages in the direction of the root. The procedures of [RFC6826] explain how to convert a PIM <source address or RPA, group address> pair into an mLDP <root node, opaque value> pair and how to convert the mLDP <root node, opaque value> pair back into the original PIM <source address or RPA, group address> pair.
PIMでは、ツリーは送信元アドレス（または双方向ツリー[RFC5015]の場合、ランデブーポイントアドレスまたは「RPA」）とグループアドレスによって識別されます。送信元アドレスまたはRPAの方向にPIM制御メッセージを送信することにより、ツリーはリーフから構築されます。 mLDPでは、ツリーはルートアドレスと「不透明な値」によって識別され、ルートの方向にmLDP制御メッセージを送信することによって構築されます。 [RFC6826]の手順では、PIM <ソースアドレスまたはRPA、グループアドレス>ペアをmLDP <ルートノード、不透明な値>ペアに変換する方法と、mLDP <ルートノード、不透明な値>ペアを変換して、元のPIM <送信元アドレスまたはRPA、グループアドレス>ペア。
However, the procedures in [RFC6826] assume that the routers doing the PIM/mLDP conversion have routes to the source address or RPA in their global routing tables. Thus, the procedures cannot be applied exactly as specified when the interfaces connecting the non-MPLS-enabled region to the MPLS-enabled region are interfaces that belong to a VRF as described in [RFC4364]. This specification extends the procedures of [RFC6826] so that they may be applied in the VRF context.
ただし、[RFC6826]の手順では、PIM / mLDP変換を行うルーターが、グローバルルーティングテーブルに送信元アドレスまたはRPAへのルートを持っていると想定しています。したがって、[RFC4364]で説明されているように、非MPLS対応リージョンをMPLS対応リージョンに接続するインターフェイスがVRFに属するインターフェイスである場合、手順は指定どおりに適用できません。この仕様は、[RFC6826]の手順を拡張して、VRFコンテキストで適用できるようにします。
As in [RFC6826], the scope of this document is limited to the case where the multicast content is distributed in the non-MPLS-enabled regions via PIM-created source-specific or bidirectional trees. Bidirectional trees are always mapped onto multipoint-to-multipoint LSPs, and source-specific trees are always mapped onto point-to-multipoint LSPs.
[RFC6826]と同様に、このドキュメントの範囲は、マルチキャストコンテンツがPIMで作成されたソース固有または双方向ツリーを介して非MPLS対応領域に配信される場合に限定されます。双方向ツリーは常にマルチポイントツーマルチポイントLSPにマッピングされ、ソース固有のツリーは常にポイントツーマルチポイントLSPにマッピングされます。
Note that the procedures described herein do not support non-bidirectional PIM Any-Source Multicast (ASM) groups, do not support the use of multicast trees other than mLDP multipoint LSPs in the core, and do not provide the capability to aggregate multiple PIM trees onto a single multipoint LSP. If any of those features are needed, they can be provided by the procedures of [RFC6513] and [RFC6514]. However, there are cases where multicast services are offered through interfaces associated with a VRF, and where mLDP is used in the core, but where aggregation is not desired. For example, some service providers offer multicast content to their customers, but have chosen to use VRFs to isolate the various customers and services. This is a simpler scenario than one in which the customers provide their own multicast content, out of the control of the service provider, and can be handled with a simpler solution. Also, when PIM trees are mapped one-to-one to multipoint LSPs, it is helpful for troubleshooting purposes to have the PIM source/group addresses encoded into the mLDP FEC (Forwarding Equivalence Class) element in what this document terms "mLDP in-band signaling".
ここで説明する手順は、非双方向PIM Any-Source Multicast（ASM）グループをサポートせず、コアでのmLDPマルチポイントLSP以外のマルチキャストツリーの使用をサポートせず、複数のPIMツリーを集約する機能を提供しないことに注意してください単一のマルチポイントLSPに。これらの機能のいずれかが必要な場合は、[RFC6513]および[RFC6514]の手順で提供できます。ただし、マルチキャストサービスがVRFに関連付けられたインターフェイスを介して提供される場合や、コアでmLDPが使用されているが、集約が望ましくない場合があります。たとえば、一部のサービスプロバイダーはマルチキャストコンテンツを顧客に提供していますが、VRFを使用してさまざまな顧客とサービスを分離することを選択しています。これは、顧客がサービスプロバイダーの制御外で独自のマルチキャストコンテンツを提供するシナリオよりも簡単なシナリオであり、より簡単なソリューションで処理できます。また、PIMツリーが1対1でマルチポイントLSPにマッピングされる場合、トラブルシューティングの目的で、このドキュメントで「mLDP in-」と呼ばれているPIMソース/グループアドレスをmLDP FEC（Forwarding Equivalence Class）要素にエンコードしておくと役立ちます。バンドシグナリング」。
In order to use the mLDP in-band signaling procedures for a particular group address in the context of a particular set of VRFs, those VRFs MUST be configured with a range of multicast group addresses for which mLDP in-band signaling is to be enabled. This configuration is per VRF defined in [RFC4364]). For those groups, and those groups only, the procedures of this document are used. For other groups, the general-purpose multicast VPN procedures MAY be used, although it is more likely this VRF is dedicated to mLDP in-band signaling procedures and all other groups are discarded. The configuration MUST be present in all PE routers that attach to sites containing senders or receivers for the given set of group addresses. Note that because the provider most likely owns the multicast content and the method of transportation across the network, which are both transparent to the end user, no coordination needs to happen between the end user and the provider.
特定のVRFのセットのコンテキストで特定のグループアドレスのmLDPインバンドシグナリング手順を使用するには、これらのVRFに、mLDPインバンドシグナリングを有効にするマルチキャストグループアドレスの範囲を設定する必要があります。この設定は、[RFC4364]で定義されているVRFごとです。これらのグループ、およびそれらのグループのみに対して、このドキュメントの手順が使用されます。他のグループでは、汎用マルチキャストVPN手順を使用できますが、このVRFはmLDPインバンドシグナリング手順専用であり、他のすべてのグループは破棄されます。設定は、特定のグループアドレスセットの送信者または受信者を含むサイトに接続するすべてのPEルータに存在する必要があります。プロバイダーはマルチキャストコンテンツとネットワークを介した転送方法を所有している可能性が高いため、どちらもエンドユーザーに対して透過的であるため、エンドユーザーとプロバイダーの間で調整を行う必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In-band signaling: Using the opaque value of an mLDP FEC element to encode the (S,G) or (*,G) identifying a particular IP multicast tree.
インバンドシグナリング：mLDP FEC要素の不透明な値を使用して、特定のIPマルチキャストツリーを識別する（S、G）または（*、G）をエンコードします。
Ingress LSR: Source of a P2MP LSP, also referred to as root node.
入力LSR：ルートノードとも呼ばれるP2MP LSPのソース。
IP multicast tree: An IP multicast distribution tree identified by a source IP address and/or IP multicast destination address, also referred to as (S,G) and (*,G).
IPマルチキャストツリー：送信元IPアドレスまたはIPマルチキャスト宛先アドレス、あるいはその両方で識別されるIPマルチキャスト配信ツリー。（S、G）および（*、G）とも呼ばれます。
mLDP: Multipoint LDP.
mLDP：マルチポイントLDP。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：P2MPまたはMP2MP LSPのいずれかのマルチポイントLSP。
MP2MP LSP: An LSP that connects a set of leaf nodes, acting indifferently as ingress or egress (see [RFC6388]).
MP2MP LSP：リーフノードのセットを接続するLSPで、入力または出力として区別なく機能します（[RFC6388]を参照）。
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs (see [RFC6388]).
P2MP LSP：1つの入力LSRと1つ以上の出力LSRを持つLSP（[RFC6388]を参照）。
RPA: Rendezvous Point Address, the address that is used as the root of the distribution tree for a range of multicast groups.
RPA：ランデブーポイントアドレス。マルチキャストグループの範囲の配布ツリーのルートとして使用されるアドレス。
RD: Route Distinguisher, an identifier that makes a route unique in the context of a VRF.
RD：Route Distinguisher、VRFのコンテキストでルートを一意にする識別子。
UMH: Upstream Multicast Hop, the upstream router in that is in the path to reach the source of the multicast flow.
UMH：アップストリームマルチキャストホップ。マルチキャストフローのソースに到達するためのパスにある上流ルーター。
VRF: Virtual Routing and Forwarding table.
VRF：Virtual Routing and Forwardingテーブル。
Suppose that a PE router, PE1, receives a PIM Join(S,G) message over one of its interfaces that is associated with a VRF. Following the procedure of Section 5.1 of [RFC6513], PE1 determines the "upstream RD", the "upstream PE", and the "upstream multicast hop" (UMH) for the source address S.
PEルータPE1が、VRFに関連付けられているインターフェイスの1つを介してPIM Join（S、G）メッセージを受信するとします。 [RFC6513]のセクション5.1の手順に従って、PE1は送信元アドレスSの「アップストリームRD」、「アップストリームPE」、および「アップストリームマルチキャストホップ」（UMH）を決定します。
In order to transport the multicast tree via a multipoint (MP) LSP using VRF in-band signaling, an mLDP Label Mapping message is sent by PE1. This message will contain either a P2MP FEC or an MP2MP FEC (see [RFC6388]), depending upon whether the PIM tree being transported is a source-specific tree, or a bidirectional tree, respectively. The FEC contains a "root" and an "opaque value".
VRFインバンドシグナリングを使用してマルチポイント（MP）LSP経由でマルチキャストツリーを転送するために、PE1によってmLDPラベルマッピングメッセージが送信されます。このメッセージには、転送されるPIMツリーがソース固有のツリーであるか双方向ツリーであるかに応じて、P2MP FECまたはMP2MP FEC（[RFC6388]を参照）が含まれます。 FECには「ルート」と「不透明な値」が含まれています。
If the UMH and the upstream PE have the same IP address (i.e., the upstream PE is the UMH), then the root of the multipoint FEC is set to the IP address of the upstream PE. If, in the context of this VPN, (S,G) refers to a source-specific MDT, then the values of S, G, and the upstream RD are encoded into the opaque value. If, in the context of this VPN, G is a bidirectional group address, then S is replaced with the value of the RPA associated with G.
UMHとアップストリームPEが同じIPアドレスを持っている場合（つまり、アップストリームPEがUMHである場合）、マルチポイントFECのルートはアップストリームPEのIPアドレスに設定されます。このVPNのコンテキストで（S、G）がソース固有のMDTを参照している場合、S、G、およびアップストリームRDの値は不透明な値にエンコードされます。このVPNのコンテキストで、Gが双方向グループアドレスの場合、SはGに関連付けられたRPAの値に置き換えられます。
The encoding details are specified in Section 3. Conceptually, the multipoint FEC can be thought of as an ordered pair: {root=<Upstream-PE>; opaque_value=<S or RPA , G, Upstream-RD>}. The mLDP Label Mapping message is then sent by PE1 on its LDP session to the "next hop" on the message's path to the upstream PE. The "next hop" is usually the directly connected next hop, but see [RFC7060] for cases in which the next hop is not directly connected.
エンコーディングの詳細はセクション3で指定されています。概念的には、マルチポイントFECは順序付けられたペアと考えることができます。{root = <Upstream-PE>; opaque_value = <SまたはRPA、G、Upstream-RD>}。次に、mLDPラベルマッピングメッセージは、LDPセッションのPE1によって、アップストリームPEへのメッセージのパス上の「ネクストホップ」に送信されます。 「ネクストホップ」は通常直接接続されたネクストホップですが、ネクストホップが直接接続されていない場合については[RFC7060]を参照してください。
If the UMH and the upstream PE do not have the same IP address, the procedures of Section 2 of [RFC6512] should be applied. The root node of the multipoint FEC is set to the UMH. The recursive opaque value is then set as follows: the root node is set to the upstream PE, and the opaque value is set to the multipoint FEC described in the previous paragraph. That is, the multipoint FEC can be thought of as the following recursive ordered pair: {root=<UMH>; opaque_value=<root=Upstream-PE, opaque_value=<S or RPA, G, Upstream-RD>>}.
UMHとアップストリームPEのIPアドレスが異なる場合は、[RFC6512]のセクション2の手順を適用する必要があります。マルチポイントFECのルートノードがUMHに設定されます。次に、再帰的な不透明な値を次のように設定します。ルートノードを上流のPEに設定し、不透明な値を前の段落で説明したマルチポイントFECに設定します。つまり、マルチポイントFECは、次の再帰的な順序のペアと考えることができます。{root = <UMH>; opaque_value = <root = Upstream-PE、opaque_value = <SまたはRPA、G、Upstream-RD >>}。
The encoding of the multipoint FEC also specifies the "type" of PIM MDT being spliced onto the multipoint LSP. Four opaque encodings are defined in [RFC6826]: IPv4 source-specific tree, IPv6 source-specific tree, IPv4 bidirectional tree, and IPv6 bidirectional tree.
マルチポイントFECのエンコーディングは、マルチポイントLSPに接合されるPIM MDTの「タイプ」も指定します。 [RFC6826]には、IPv4ソース固有のツリー、IPv6ソース固有のツリー、IPv4双方向ツリー、IPv6双方向ツリーの4つの不透明なエンコーディングが定義されています。
When a PE router receives an mLDP message with a P2MP or MP2MP FEC, where the PE router itself is the root node, and the opaque value is one of the types defined in Section 3, then it uses the RD encoded in the opaque value field to determine the VRF context. (This RD will be associated with one of the PEs VRFs.) Then, in the context of that VRF, the PE follows the procedure specified in section 2 of [RFC6826].
PEルーターがP2MPまたはMP2MP FECでmLDPメッセージを受信すると、PEルーター自体がルートノードであり、不透明値がセクション3で定義されたタイプの1つである場合、不透明値フィールドにエンコードされたRDを使用します。 VRFコンテキストを判別します。 （このRDはPE VRFの1つに関連付けられます。）次に、そのVRFのコンテキストで、PEは[RFC6826]のセクション2で指定された手順に従います。
This section documents the different transit opaque encodings.
このセクションでは、さまざまな通過不透明エンコードについて説明します。
This opaque value type is used when transporting a source-specific mode multicast tree whose source and group addresses are IPv4 addresses.
この不透明な値タイプは、ソースおよびグループアドレスがIPv4アドレスであるソース固有モードのマルチキャストツリーを転送するときに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 250
タイプ：250
Length: 16
長さ：16
Source: IPv4 multicast source address, 4 octets.
送信元：IPv4マルチキャスト送信元アドレス、4オクテット。
Group: IPv4 multicast group address, 4 octets.
グループ：IPv4マルチキャストグループアドレス、4オクテット。
RD: Route Distinguisher, 8 octets.
RD：Route Distinguisher、8オクテット。
This opaque value type is used when transporting a source-specific mode multicast tree whose source and group addresses are IPv6 addresses.
この不透明な値のタイプは、ソースおよびグループアドレスがIPv6アドレスであるソース固有モードのマルチキャストツリーを転送するときに使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 251
タイプ：251
Length: 40
長さ：40
Source: IPv6 multicast source address, 16 octets.
送信元：IPv6マルチキャスト送信元アドレス、16オクテット。
Group: IPv6 multicast group address, 16 octets.
グループ：IPv6マルチキャストグループアドレス、16オクテット。
RD: Route Distinguisher, 8 octets.
RD：Route Distinguisher、8オクテット。
This opaque value type is used when transporting a bidirectional multicast tree whose group address is an IPv4 address. The RP address is also an IPv4 address in this case.
この不透明な値タイプは、グループアドレスがIPv4アドレスである双方向マルチキャストツリーを転送するときに使用されます。この場合、RPアドレスもIPv4アドレスです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 9
タイプ：9
Length: 17
長さ：17
Mask Len: The number of contiguous one bits that are left justified and used as a mask, 1 octet.
マスク長：左揃えでマスクとして使用される連続する1ビットの数、1オクテット。
RP: Rendezvous Point (RP) IPv4 address used for the encoded Group, 4 octets.
RP：エンコードされたグループに使用されるランデブーポイント（RP）IPv4アドレス、4オクテット。
Group: IPv4 multicast group address, 4 octets.
グループ：IPv4マルチキャストグループアドレス、4オクテット。
RD: Route Distinguisher, 8 octets.
RD：Route Distinguisher、8オクテット。
This opaque value type is used when transporting a bidirectional multicast tree whose group address is an IPv6 address. The RP address is also an IPv6 address in this case.
この不透明な値タイプは、グループアドレスがIPv6アドレスである双方向マルチキャストツリーを転送するときに使用されます。この場合、RPアドレスもIPv6アドレスです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ RD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10
タイプ：10
Length: 41
長さ：41
Mask Len: The number of contiguous one bits that are left justified and used as a mask, 1 octet.
マスク長：左揃えでマスクとして使用される連続する1ビットの数、1オクテット。
RP: Rendezvous Point (RP) IPv6 address used for the encoded group, 16 octets.
RP：エンコードされたグループに使用されるRendezvous Point（RP）IPv6アドレス、16オクテット。
Group: IPv6 multicast group address, 16 octets.
グループ：IPv6マルチキャストグループアドレス、16オクテット。
RD: Route Distinguisher, 8 octets.
RD：Route Distinguisher、8オクテット。
The same security considerations apply as for the base LDP specification, described in [RFC5036], and the base mLDP specification, described in [RFC6388].
[RFC5036]で説明されているベースLDP仕様、および[RFC6388]で説明されているベースmLDP仕様と同じセキュリティ上の考慮事項が適用されます。
Operators MUST configure packet filters to ensure that the mechanism described in this memo does not cause non-global-scoped IPv6 multicast packets to be tunneled outside of their intended scope.
オペレーターは、このメモで説明されているメカニズムによって、グローバルスコープではないIPv6マルチキャストパケットが目的のスコープ外でトンネリングされないように、パケットフィルターを構成する必要があります。
[RFC6388] defines a registry for the "LDP MP Opaque Value Element basic type". IANA has assigned four new code points in this registry:
[RFC6388]は、「LDP MP Opaque Value Element basic type」のレジストリを定義しています。 IANAは、このレジストリに4つの新しいコードポイントを割り当てました。
Transit VPNv4 Source TLV type - 250
中継VPNv4ソースTLVタイプ-250
Transit VPNv6 Source TLV type - 251
中継VPNv6ソースTLVタイプ-251
Transit VPNv4 Bidir TLV type - 9
中継VPNv4 Bidir TLVタイプ-9
Transit VPNv6 Bidir TLV type - 10
中継VPNv6 Bidir TLVタイプ-10
Thanks to Eric Rosen, Andy Green, Yakov Rekhter, and Eric Gray for their comments on the document.
ドキュメントへのコメントを提供してくれたEric Rosen、Andy Green、Yakov Rekhter、およびEric Greyに感謝します。
[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月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[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月。
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012.
[RFC6512] Wijnands、IJ。、Rosen、E.、Napierala、M。、およびN. Leymann、「バックボーンにルートへのルートがない場合のマルチポイントLDPの使用」、RFC 6512、2012年2月。
[RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, January 2013.
[RFC6826] Wijnands、IJ。、Ed。、Eckert、T.、Leymann、N。、およびM. Napierala、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのマルチポイントLDPインバンドシグナリング」、 RFC 6826、2013年1月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513] Rosen、E.、Ed。、and R. Aggarwal、Ed。、 "Multicast in MPLS / BGP IP VPNs"、RFC 6513、February 2012。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[RFC6514] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャストのためのBGPエンコーディングおよび手順」、RFC 6514、2012年2月。
[RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, November 2013.
[RFC7060] Napierala、M.、Rosen、E。、およびIJ。 Wijnands、「Using LDP Multipoint Extensions on Targeted LDP Sessions」、RFC 7060、2013年11月。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijnands（editor）Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium E-mail：ice@cisco.com
Paul Hitchen BT BT Adastral Park Ipswich IP53RE United Kingdom EMail: paul.hitchen@bt.com
ポールヒッチェンBT BTアダストラルパークイプスウィッチIP53REイギリスEメール：paul.hitchen@bt.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: n.leymann@telekom.de
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21ベルリン10781ドイツEメール：n.leymann@telekom.de
Wim Henderickx Alcatel-Lucent Copernicuslaan 50 Antwerp 2018 Belgium EMail: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucent Copernicuslaan 50アントワープ2018ベルギーEメール：wim.henderickx@alcatel-lucent.com
Arkadiy Gulko Thomson Reuters 195 Broadway New York, NY 10007 United States EMail: arkadiy.gulko@thomsonreuters.com
Arkadiy Gulko Thomson Reuters 195 Broadway New York、NY 10007米国Eメール：arkadiy.gulko@thomsonreuters.com
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States EMail: jeff.tantsura@ericsson.com
Jeff Tantsura Ericsson 300 Holger Way San Jose、CA 95134米国Eメール：jeff.tantsura@ericsson.com