[要約] RFC 6826は、ポイントツーマルチポイントおよびマルチポイントツーマルチポイントのラベルスイッチパスに対するマルチポイントLDPインバンドシグナリングに関する仕様です。このRFCの目的は、マルチポイントLDPを使用して効率的かつ信頼性の高い通信を実現することです。
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6826 T. Eckert
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
M. Napierala
AT&T Labs
January 2013
Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチドパスのマルチポイントLDPインバンドシグナリング
Abstract
概要
Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs.
Protocol Independent Multicast（PIM）によって構築され、マルチポイントLDP（mLDP）ポイントツーマルチポイントおよび/またはマルチポイントツーマルチポイントラベルスイッチドパス（LSP）が通過できるMPLSドメインを通過する必要があるIPマルチキャストツリーについて考えます。作成されます。 MPLSドメインを通過するIPマルチキャストツリーの部分は、マルチポイントLSPとしてインスタンス化できます。 PLS参加メッセージがMPLSドメインの境界で受信されると、そのメッセージからの情報がmLDPメッセージにエンコードされます。 mLDPメッセージが次のIPドメインの境界に到達すると、エンコードされた情報を使用して、IPドメインを介して送信できるPIMメッセージが生成されます。結果は、マルチポイントLSPと一緒にスプライスされる一連のIPマルチキャストサブツリーで構成されるIPマルチキャストツリーです。このドキュメントでは、IPマルチキャストツリーがマルチポイントLSPとともにスプライスされる方法に関する手順について説明します。
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/rfc6826.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6826で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6
2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6
2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7
3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
The mLDP (Multipoint LDP) [RFC6388] specification describes mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are typically used for transporting end-user multicast packets. However, the mLDP specification does not provide any rules for associating particular end-user multicast packets with any particular LSP. Other documents, like [RFC6513], describe applications in which out-of-band signaling protocols, such as PIM and BGP, are used to establish the mapping between an LSP and the multicast packets that need to be forwarded over the LSP.
mLDP（マルチポイントLDP）[RFC6388]仕様では、ポイントツーマルチポイント（P2MP）およびマルチポイントツーマルチポイント（MP2MP）LSP（ラベルスイッチドパス）を作成するためのメカニズムについて説明しています。これらのLSPは通常、エンドユーザーマルチキャストパケットの転送に使用されます。ただし、mLDP仕様では、特定のエンドユーザーマルチキャストパケットを特定のLSPに関連付けるためのルールは提供されていません。 [RFC6513]などの他のドキュメントでは、LSPとLSPを介して転送する必要があるマルチキャストパケット間のマッピングを確立するために、PIMやBGPなどの帯域外シグナリングプロトコルを使用するアプリケーションについて説明しています。
This document describes an application in which the information needed to establish the mapping between an LSP and the set of multicast packets to be forwarded over it is carried in the "opaque value" field of an mLDP FEC (Forwarding Equivalence Class) element. When an IP multicast tree (either a source-specific tree or a bidirectional tree) enters the MPLS network, the (S,G) or (*,G) information from the IP multicast control-plane state is carried in the opaque value field of the mLDP FEC message. As the tree leaves the MPLS network, this information is extracted from the FEC Element and used to build the IP multicast control plane. PIM messages can be sent outside the MPLS domain. Note that although the PIM control messages are sent periodically, the mLDP messages are not.
このドキュメントでは、LSPとLSPを介して転送されるマルチキャストパケットのセット間のマッピングを確立するために必要な情報が、mLDP FEC（Forwarding Equivalence Class）要素の「不透明な値」フィールドに含まれるアプリケーションについて説明します。 IPマルチキャストツリー（送信元固有のツリーまたは双方向ツリー）がMPLSネットワークに入ると、IPマルチキャストコントロールプレーンステートからの（S、G）または（*、G）情報が不透明な値フィールドに保持されます。 mLDP FECメッセージの。ツリーがMPLSネットワークを離れると、この情報はFEC要素から抽出され、IPマルチキャストコントロールプレーンの構築に使用されます。 PIMメッセージは、MPLSドメインの外部に送信できます。 PIM制御メッセージは定期的に送信されますが、mLDPメッセージはそうではないことに注意してください。
Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in the MPLS network. A network operator should expect to see as many LSPs in the MPLS network as there are IP multicast trees. A network operator should be aware how IP multicast state is created in the network to ensure that it does not exceed the scalability numbers of the protocol, either PIM or mLDP.
各IPマルチキャストツリーは、MPLSネットワーク内のP2MPまたはMP2MP LSPに1対1でマッピングされます。ネットワークオペレータは、IPマルチキャストツリーと同じ数のLSPがMPLSネットワークに表示されることを期待する必要があります。ネットワークオペレーターは、ネットワークでIPマルチキャストステートがどのように作成されるかを認識し、プロトコルのスケーラビリティー番号（PIMまたはmLDP）を超えないようにする必要があります。
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]で説明されているように解釈されます。
ASM: PIM Any Source Multicast
ASM：PIM Any Source Multicast
Egress LSR: One of potentially many destinations of an LSP; also referred to as leaf node in the case of P2MP and MP2MP LSPs.
出力LSR：LSPの多くの宛先の1つ。 P2MPおよびMP2MP LSPの場合、リーフノードとも呼ばれます。
In-band signaling: Using the opaque value of an mLDP FEC Element to carry the (S,G) or (*,G) identifying a particular IP multicast tree.
インバンドシグナリング：mLDP FEC要素の不透明な値を使用して、特定のIPマルチキャストツリーを識別する（S、G）または（*、G）を伝送します。
Ingress LSR: Source of the P2MP LSP; also referred to as a root node.
入力LSR：P2MP LSPのソース。ルートノードとも呼ばれます。
IP multicast tree: An IP multicast distribution tree identified by an IP multicast Group address and, optionally, by a Source IP address, also referred to as (S,G) and (*,G).
IPマルチキャストツリー：IPマルチキャストグループアドレス、およびオプションで（S、G）および（*、G）とも呼ばれる送信元IPアドレスによって識別されるIPマルチキャスト配信ツリー。
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
LSP: Labels Switched Path
LSP：ラベルスイッチドパス
mLDP: Multipoint LDP
mLDP：マルチポイントLDP
MP2MP LSP: An LSP that connects a set of leaf nodes that may each independently act as ingress or egress.
MP2MP LSP：それぞれが独立して入力または出力として機能するリーフノードのセットを接続するLSP。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：P2MPまたはMP2MP LSPのいずれかのマルチポイントLSP。
P2MP LSP: An LSP that has one Ingress Label Switching Router (LSR) and one or more Egress LSRs.
P2MP LSP：1つの入力ラベルスイッチングルーター（LSR）と1つ以上の出力LSRを持つLSP。
RP: PIM Rendezvous Point
RP：PIMランデブーポイント
SSM: PIM Source-Specific Multicast
SSM：PIM送信元固有のマルチキャスト
Transit LSP: A P2MP or MP2MP LSP whose FEC Element contains the (S,G) or (*,G) identifying a particular IP multicast distribution tree.
トランジットLSP：P2MPまたはMP2MPLSP。FECエレメントには、特定のIPマルチキャスト配信ツリーを識別する（S、G）または（*、G）が含まれています。
Transit LSR: An LSR that has one or more directly connected downstream LSRs.
トランジットLSR：1つ以上の直接接続されたダウンストリームLSRを持つLSR。
Consider the following topology:
次のトポロジを検討してください。
|--- IPM ---|--- MPLS --|--- IPM ---|
S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
Figure 1
図1
Nodes A and B are IP-multicast-capable routers and connect to a Source/RP and a Receiver, respectively. Nodes U, C, and D are MPLS Label Switched Routers (LSRs).
ノードAとBはIPマルチキャスト対応ルーターであり、それぞれソース/ RPとレシーバーに接続します。ノードU、C、およびDは、MPLSラベルスイッチドルータ（LSR）です。
LSR D is attached to a network that is capable of MPLS multicast and IP multicast (see figure 1), and D is required to create a IP multicast tree due to a certain IP multicast event, like a PIM Join, MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-discovery route [SM-MLDP], or Rendezvous Point (RP) discovery. Suppose that D can determine that the IP multicast tree needs to travel through the MPLS network until it reaches LSR U. For instance, when D looks up the route to the Source or RP [RFC4601] of the IP multicast tree, it may discover that the route is a BGP route with U as the BGP next hop. Then D may choose to set up a P2MP or an MP2MP LSP, with U as root, and to make that LSP become part of the IP multicast distribution tree. Note that other methods are possible to determine that an IP multicast tree is to be transported across an MPLS network using P2MP or MP2MP LSPs. However, these methods are outside the scope of this document.
LSR Dは、MPLSマルチキャストおよびIPマルチキャストが可能なネットワークに接続され（図1を参照）、PIM加入、MSDPソースアナウンス（SAのような特定のIPマルチキャストイベントのためにIPマルチキャストツリーを作成するために必要です。 ）[RFC3618]、BGPソースアクティブ自動検出ルート[SM-MLDP]、またはランデブーポイント（RP）検出。 DがIPマルチキャストツリーがLSR Uに到達するまでMPLSネットワークを経由する必要があると判断できると仮定します。たとえば、DがIPマルチキャストツリーのソースまたはRP [RFC4601]へのルートを検索すると、ルートは、BGPネクストホップとしてUを持つBGPルートです。次に、Dは、UをルートとしてP2MPまたはMP2MP LSPをセットアップし、そのLSPをIPマルチキャスト配信ツリーの一部にすることを選択できます。 P2MPまたはMP2MP LSPを使用して、MPLSネットワークを介してIPマルチキャストツリーが転送されることを決定する他の方法が可能であることに注意してください。ただし、これらのメソッドはこのドキュメントの範囲外です。
In order to establish a multicast tree via a P2MP or MP2MP LSP using "in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with the IP address of LSR U as the "Root Node Address" and with the source and the group encoded into the "opaque value" ([RFC6388], Sections 2.2 and 3.2). Several different opaque value types are defined in this document. LSR D MUST NOT use a particular opaque value type unless it knows (through provisioning or through some other means outside the scope of this document) that LSR U supports the root node procedures for that opaque value type.
「インバンドシグナリング」を使用してP2MPまたはMP2MP LSPを介してマルチキャストツリーを確立するために、LSR Dは、「ルートノードアドレス」としてのLSR UのIPアドレスと、ソースおよび「不透明な値」にエンコードされたグループ（[RFC6388]、セクション2.2および3.2）。このドキュメントでは、いくつかの異なる不透明な値タイプが定義されています。 LSR Uがその不透明な値型のルートノードプロシージャをサポートしていることを（プロビジョニングまたはこのドキュメントの範囲外にある他の手段によって）知らない限り、LSR Dは特定の不透明な値型を使用してはなりません（MUST NOT）。
The particular type of FEC Element and opaque value used depends on the IP address family being used, and on whether the multicast tree being established is a source-specific or a bidirectional multicast tree.
使用されるFEC要素と不透明な値の特定のタイプは、使用されているIPアドレスファミリ、および確立されているマルチキャストツリーが送信元固有か双方向マルチキャストツリーかによって異なります。
When an LSR receives a label mapping or withdraw whose FEC Element contains one of the opaque value types defined in this document, and that LSR is not the one identified by the "Root Node Address" field of that FEC Element, the LSR follows the procedures provided in RFC 6388.
LSRがラベルマッピングを受信するか、FEC要素にこのドキュメントで定義されている不透明な値タイプの1つが含まれ、そのLSRがそのFEC要素の「ルートノードアドレス」フィールドで識別されるものではない場合、LSRは手順に従いますRFC 6388で提供されています。
When an LSR receives a label mapping or withdraw whose FEC Element contains one of the opaque value types defined in this document, and that LSR is the one identified by the Root Node Address field of that FEC Element, then the following procedure is executed. The multicast source and group are extracted and passed to the multicast code. If a label mapping is being processed, the multicast code will add the downstream LDP neighbor to the olist of the corresponding (S,G) or (*,G) state, creating such state if it does not already exist. If a label withdraw is being processed, the multicast code will remove the downstream LDP neighbor from the olist of the corresponding (S,G) or (*,G) state. From this point on, normal PIM processing will occur.
LSRが、FECエレメントにこのドキュメントで定義されている不透明な値タイプの1つが含まれているラベルマッピングまたは撤回を受信し、そのLSRがそのFECエレメントのルートノードアドレスフィールドで識別されるものである場合、次の手順が実行されます。マルチキャストソースとグループが抽出され、マルチキャストコードに渡されます。ラベルマッピングが処理されている場合、マルチキャストコードはダウンストリームLDPネイバーを対応する（S、G）または（*、G）状態のolistに追加し、まだ存在しない場合はそのような状態を作成します。ラベルの撤回が処理されている場合、マルチキャストコードは、対応する（S、G）または（*、G）状態のolistからダウンストリームLDPネイバーを削除します。この時点から、通常のPIM処理が行われます。
Note that if the LSR identified by the Root Node Address field does not recognize the opaque value type, the MP LSP will be established, but the root node will not send any multicast data packets on it.
ルートノードアドレスフィールドで識別されるLSRが不透明な値タイプを認識しない場合、MP LSPは確立されますが、ルートノードはマルチキャストデータパケットを送信しません。
Source or RP addresses that are reachable in a VPN context are outside the scope of this document.
VPNコンテキストで到達可能な送信元またはRPアドレスは、このドキュメントの範囲外です。
Multicast groups that operate in PIM Dense-Mode are outside the scope of this document.
PIM Dense-Modeで動作するマルチキャストグループは、このドキュメントの範囲外です。
Nothing prevents PIM shared trees, used by PIM-SM in the ASM service model, from being transported across an MPLS core. However, it is not possible to prune individual sources from the shared tree without the use of an additional out-of-band signaling protocol, like PIM or BGP [SM-MLDP]. For this reason, transiting shared trees across a transit LSP is outside the scope of this document.
ASMサービスモデルのPIM-SMで使用されるPIM共有ツリーがMPLSコアを介して転送されることを妨げるものはありません。ただし、PIMやBGP [SM-MLDP]などの追加の帯域外シグナリングプロトコルを使用しないと、共有ツリーから個々のソースをプルーニングすることはできません。このため、トランジットLSPを介して共有ツリーをトランジットすることは、このドキュメントの範囲外です。
IP multicast source trees can be created via PIM operating in either SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM mode, the usual means of discovering active sources is to join a sparse-mode shared tree. However, this document does not provide any method of establishing a sparse-mode shared tree across an MPLS network. To apply the technique of this document to PIM-SM in ASM mode, there must be some other means of discovering the active sources. One possible means is the use of MSDP [RFC3618]. Another possible means is to use BGP Source Active auto-discovery routes, as documented in [SM-MLDP]. However, the method of discovering the active sources is outside the scope of this document; as a result, this document does not specify everything that is needed to support the ASM service model using in-band signaling.
IPマルチキャストソースツリーは、SSMモード[RFC4607]またはASMモード[RFC4601]で動作するPIMを介して作成できます。 PIM-SMをASMモードで使用する場合、アクティブなソースを検出する通常の方法は、スパースモードの共有ツリーに参加することです。ただし、このドキュメントでは、MPLSネットワーク全体でスパースモードの共有ツリーを確立する方法については説明していません。このドキュメントの手法をASMモードのPIM-SMに適用するには、アクティブなソースを検出する他の方法がいくつか必要です。 1つの可能な手段は、MSDP [RFC3618]の使用です。別の可能な手段は、[SM-MLDP]で文書化されているように、BGPソースアクティブ自動検出ルートを使用することです。ただし、アクティブなソースを検出する方法は、このドキュメントの範囲外です。そのため、このドキュメントでは、インバンドシグナリングを使用してASMサービスモデルをサポートするために必要なすべてを指定しているわけではありません。
The source and group addresses are encoded into the a transit TLV as specified in Sections 3.1 and 3.2.
送信元およびグループアドレスは、セクション3.1および3.2で指定されているように、トランジットTLVにエンコードされます。
If a bidirectional IP multicast tree [RFC5015] has to be transported over an MPLS network using in-band signaling, as described in this document, it MUST be transported using an MP2MP LSPs. A bidirectional tree does not have a specific source address; the group address, subnet mask, and RP are relevant for multicast forwarding. This document does not provide procedures to discover RP-to-group mappings dynamically across an MPLS network and assumes the RP is statically defined. Support of dynamic RP mappings in combination with in-band signaling is outside the scope of this document.
このドキュメントで説明されているように、双方向IPマルチキャストツリー[RFC5015]をインバンドシグナリングを使用してMPLSネットワーク経由で転送する必要がある場合は、MP2MP LSPを使用して転送する必要があります。双方向ツリーには特定の送信元アドレスはありません。グループアドレス、サブネットマスク、およびRPは、マルチキャスト転送に関連しています。このドキュメントでは、MPLSネットワーク全体でRPからグループへのマッピングを動的に検出する手順については説明せず、RPが静的に定義されていることを前提としています。インバンドシグナリングと組み合わせたダイナミックRPマッピングのサポートは、このドキュメントの範囲外です。
The RP for the group is used to select the ingress LSR and the root of the LSP. The group address is encoded according to the rules of Sections 3.3 or 3.4, depending on the IP version. The subnet mask associated with the bidirectional group is encoded in the Transit TLV. There are two types of bidirectional states in IP multicast, the group specific state and the RP state. The first type is typically created when a PIM Join has been received and has a subnet mask of 32 for IPv4 and 128 for IPv6. The RP state is typically created via the static RP mapping and has a variable subnet mask. The RP state is used to build a tree to the RP and is used for sender-only branches. Each state (group specific and RP state) will result in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be done by PIM on the root LSR. No special procedures are necessary for PIM to merge the two LSPs. Each LSP is effectively treated as a PIM-enabled interface. Please see [RFC5015] for more details.
グループのRPは、入力LSRとLSPのルートを選択するために使用されます。グループアドレスは、IPバージョンに応じて、セクション3.3または3.4のルールに従ってエンコードされます。双方向グループに関連付けられたサブネットマスクは、Transit TLVでエンコードされます。 IPマルチキャストには、グループ固有の状態とRP状態の2種類の双方向状態があります。最初のタイプは、通常、PIM加入が受信されたときに作成され、IPv4の場合は32、IPv6の場合は128のサブネットマスクがあります。 RP状態は通常、静的RPマッピングを介して作成され、可変サブネットマスクがあります。 RP状態は、RPへのツリーを構築するために使用され、送信側のみのブランチに使用されます。各状態（グループ固有およびRP状態）は、個別のMP2MP LSPになります。 2つのMP2MP LSPのマージは、ルートLSR上のPIMによって行われます。 PIMが2つのLSPをマージするための特別な手順は必要ありません。各LSPは、実質的にPIM対応のインターフェイスとして扱われます。詳細については、[RFC5015]を参照してください。
For transporting the packets of a sender-only branch, we create a MP2MP LSP. Other sender-only branches will receive these packets and will not forward them because there are no receivers. These packets will be dropped. If that effect is undesirable, some other means of transport has to be established to forward packets to the root of the tree, for example, a multipoint-to-point LSP for example. A technique to unicast packets to the root of a P2MP or MP2MP LSP is documented in Section 3.2.2.1 of [MVPN-MSPMSI].
送信側のみのブランチのパケットを転送するために、MP2MP LSPを作成します。他の送信側のみのブランチはこれらのパケットを受信し、受信側がないためそれらを転送しません。これらのパケットはドロップされます。その影響が望ましくない場合は、ツリーのルートにパケットを転送するために、他のトランスポート手段（たとえば、マルチポイントツーポイントLSPなど）を確立する必要があります。 P2MPまたはMP2MP LSPのルートにパケットをユニキャストする手法は、[MVPN-MSPMSI]のセクション3.2.2.1に記載されています。
This section documents the different transit opaque encodings.
このセクションでは、さまざまな通過不透明エンコードについて説明します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3
タイプ：3
Length: 8 (octet size of Source and Group fields)
長さ：8（ソースおよびグループフィールドのオクテットサイズ）
Source: IPv4 multicast source address, 4 octets
送信元：IPv4マルチキャスト送信元アドレス、4オクテット
Group: IPv4 multicast group address, 4 octets
グループ：IPv4マルチキャストグループアドレス、4オクテット
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4
タイプ：4
Length: 32 (octet size of Source and Group fields)
長さ：32（ソースおよびグループフィールドのオクテットサイズ）
Source: IPv6 multicast source address, 16 octets
送信元：IPv6マルチキャスト送信元アドレス、16オクテット
Group: IPv6 multicast group address, 16 octets.
グループ：IPv6マルチキャストグループアドレス、16オクテット。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5
タイプ：5
Length: 9 (octet size of Mask Len, RP, and Group fields)
長さ：9（マスクLen、RP、およびグループフィールドのオクテットサイズ）
Mask Len: The number of contiguous one bits that are left-justified and used as a mask, 1 octet. Maximum value allowed is 32.
マスク長：左揃えされ、マスクとして使用される連続する1ビットの数、1オクテット。許可される最大値は32です。
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オクテット。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6
タイプ：6
Length: 33 (octet size of Mask Len, RP and Group fields)
長さ：33（Mask Len、RP、およびGroupフィールドのオクテットサイズ）
Mask Len: The number of contiguous one bits that are left-justified and used as a mask, 1 octet. Maximum value allowed is 128.
マスク長：左揃えされ、マスクとして使用される連続する1ビットの数、1オクテット。許可される最大値は128です。
RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 octets.
RP：エンコードされたグループに使用されるランデブーポイント（RP）IPv6アドレス、16オクテット。
Group: IPv6 multicast group address, 16 octets.
グループ：IPv6マルチキャストグループアドレス、16オクテット。
The same security considerations apply as for the base LDP specification, as described in [RFC5036].
[RFC5036]で説明されているように、基本のLDP仕様と同じセキュリティの考慮事項が適用されます。
IANA has allocated the following values from the "LDP MP Opaque Value Element basic type" registry: are:
IANAは、「LDP MP Opaque Value Element basic type」レジストリから次の値を割り当てました。
Transit IPv4 Source TLV type - 3
Transit IPv4 Source TLVタイプ-3
Transit IPv6 Source TLV type - 4
Transit IPv6 Source TLVタイプ-4
Transit IPv4 Bidir TLV type - 5
Transit IPv4 Bidir TLVタイプ-5
Transit IPv6 Bidir TLV type - 6
Transit IPv6 Bidir TLVタイプ-6
[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。
[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月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「ソース固有のIPマルチキャスト」、RFC 4607、2006年8月。
[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月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。、編、およびD. Meyer、編、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月。
[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。
[SM-MLDP] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Work in Progress, August 2011.
[SM-MLDP] Rekhter、Y.、Aggarwal、R。、およびN. Leymann、「PIM-SMをASMモードツリーでP2MP mLDP LSP上に運ぶ」、Work in Progress、2011年8月。
[MVPN-MSPMSI] Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers, MVPN: Optimized use of PIM via MS-PMSIs", February 2012.
[MVPN-MSPMSI] Cai、Y.、Rosen、E.、Ed。、Napierala、M.、A。Boers、MVPN：Optimized use of PIM via MS-PMSIs "、2012年2月。
Thanks to Eric Rosen for his valuable comments on this document. Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa Andersson and Arkadiy Gulko for providing comments on this document.
このドキュメントに対する貴重なコメントを提供してくれたEric Rosenに感謝します。このドキュメントにコメントを提供してくれたYakov Rekhter、Adrian Farrel、Uwe Joorde、Loa Andersson、およびArkadiy Gulkoにも感謝します。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（編集者）Cisco Systems、Inc. Kleetlaan 6a Diegem 1831ベルギー
EMail: ice@cisco.com
Toerless Eckert Cisco Systems, Inc. 170 Tasman Drive San Jose CA, 95134 USA
Toerless Eckert Cisco Systems、Inc. 170 Tasman Drive San Jose CA、95134 USA
EMail: eckert@cisco.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21ベルリン10781ドイツ
EMail: n.leymann@telekom.de
Maria Napierala AT&T Labs 200 Laurel Avenue Middletown NJ 07748 USA
Maria Napierala AT＆T Labs 200 Laurel Avenue Middletown NJ 07748 USA
EMail: mnapierala@att.com