[要約] RFC 7060は、ターゲットLDPセッションでLDPマルチポイント拡張を使用するためのガイドラインです。このRFCの目的は、LDPセッションの効率を向上させ、ネットワークのスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) M. Napierala
Request for Comments: 7060 AT&T
Category: Standards Track E. Rosen
ISSN: 2070-1721 IJ. Wijnands
Cisco Systems, Inc.
November 2013
Using LDP Multipoint Extensions on Targeted LDP Sessions
ターゲットLDPセッションでのLDPマルチポイント拡張の使用
Abstract
概要
Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.
ラベル配布プロトコル（LDP）を使用して、ポイントツーマルチポイント（P2MP）およびマルチポイントツーマルチポイント（MP2MP）ラベルスイッチドパスをセットアップできます。ただし、LDPのマルチポイント拡張の仕様では、LDPセッションの2つのエンドポイントが直接接続されていることを前提としています。 LDP基本仕様では、LDPセッションの2つのエンドポイントが直接接続されていない場合を考慮しています。このようなセッションは、「ターゲットLDP」セッションと呼ばれます。このドキュメントでは、ターゲットLDPセッションでLDPマルチポイント拡張機能を使用するための仕様について説明します。
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/rfc7060.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7060で入手できます。
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 ....................................................2
2. Targeted mLDP and the Upstream LSR ..............................3
2.1. Selecting the Upstream LSR .................................3
2.2. Sending Data from U to D ...................................4
3. Applicability of Targeted mLDP ..................................4
4. LDP Capabilities ................................................5
5. Targeted mLDP with Unicast Replication ..........................5
6. Targeted mLDP with Multicast Tunneling ..........................6
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. Normative References ............................................8
Label Distribution Protocol (LDP) extensions for setting up Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This set of extensions is generally known as "Multipoint LDP" (mLDP).
ポイントツーマルチポイント（P2MP）ラベルスイッチドパス（LSP）およびマルチポイントツーマルチポイント（MP2MP）LSPを設定するためのラベル配布プロトコル（LDP）拡張は、[mLDP]で指定されます。この拡張セットは、一般に「マルチポイントLDP」（mLDP）として知られています。
A pair of Label Switched Routers (LSRs) that are the endpoints of an LDP session are considered to be "LDP peers". When a pair of LDP peers are "directly connected" (e.g., they are connected by a layer 2 medium or are otherwise considered to be neighbors by the network's interior routing protocol), the LDP session is said to be a "directly connected" LDP session. When the pair of LDP peers are not directly connected, the session between them is said to be a "Targeted" LDP session.
LDPセッションのエンドポイントであるラベルスイッチドルータ（LSR）のペアは、「LDPピア」と見なされます。 LDPピアのペアが「直接接続」されている場合（たとえば、それらはレイヤー2メディアによって接続されているか、ネットワークの内部ルーティングプロトコルによってネイバーであると見なされている場合）、LDPセッションは「直接接続された」LDPと呼ばれます。セッション。 LDPピアのペアが直接接続されていない場合、それらの間のセッションは「ターゲット」LDPセッションと呼ばれます。
The base specification for mLDP does not explicitly cover the case where the LDP multipoint extensions are used over a Targeted LDP session. This document provides that specification.
mLDPの基本仕様は、LDPマルチポイント拡張がターゲットLDPセッションで使用される場合を明示的にカバーしていません。このドキュメントはその仕様を提供します。
We will use the term "Multipoint" to mean "either P2MP or MP2MP".
「マルチポイント」という用語は、「P2MPまたはMP2MPのいずれか」を意味するために使用します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that is an ordered pair of the form <root, opaque value>. The first element of the ordered pair is the IP address of the MP-LSP's "root node". The second element of the ordered pair is an identifier that is unique in the context of the root node.
mLDPでは、マルチポイントLSP（MP-LSP）には、<ルート、不透明な値>という形式の順序付けられたペアである一意の識別子があります。順序付きペアの最初の要素は、MP-LSPの「ルートノード」のIPアドレスです。順序付きペアの2番目の要素は、ルートノードのコンテキストで一意の識別子です。
If LSR D is setting up the MP-LSP <R, X>, D must determine the "upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>, U, is defined to be the "next hop" on D's path to R, and "next hop" is tacitly assumed to mean "IGP next hop". It is thus assumed that there is a direct LDP session between D and U. In this specification, we extend the notion of "upstream LSR" to cover the following cases:
LSR DがMP-LSP <R、X>をセットアップしている場合、Dは<R、X>の「アップストリームLSR」を決定する必要があります。 [mLDP]では、<R、X>、UのアップストリームLSRは、DのRへのパス上の「ネクストホップ」として定義され、「ネクストホップ」は暗黙的に「IGPネクストホップ」を意味すると見なされます。したがって、DとUの間に直接LDPセッションがあると想定されます。この仕様では、「アップストリームLSR」の概念を拡張して、次のケースをカバーします。
- U is the "BGP next hop" on D's path to R, where U and D are not necessarily IGP neighbors, and where there is a Targeted LDP session between U and D. In this case, we allow D to select U as the "upstream LSR" for <R,X>.
- Uは、RへのDのパス上の「BGPネクストホップ」です。UとDは必ずしもIGPネイバーではなく、UとDの間にターゲットLDPセッションがあります。この場合、DがUを「 <R、X>のアップストリームLSR」。
- If the "next-hop interface" on D's path to R is an RSVP Traffic Engineering (RSVP-TE) P2P tunnel whose remote endpoint is U, and if there is known to be an RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP session between U and D, then we allow D to select U as the "upstream LSR" for <R,X>. This is useful when D and U are part of a network area that is fully meshed via RSVP-TE P2P tunnels.
- DのRへのパス上の「ネクストホップインターフェイス」が、リモートエンドポイントがUであるRSVPトラフィックエンジニアリング（RSVP-TE）P2Pトンネルであり、UからDへのRSVP-TE P2Pトンネルがあることがわかっている場合、およびUとDの間にターゲットLDPセッションがある場合、Dが<R、X>の「アップストリームLSR」としてUを選択できるようにします。これは、DとUがRSVP-TE P2Pトンネルを介して完全にメッシュ化されているネットワークエリアの一部である場合に役立ちます。
The particular method used to select an "upstream LSR" is determined by the Service Provider (SP) and must be made known a priori (i.e., by provisioning) to all the LSRs involved.
「アップストリームLSR」を選択するために使用される特定の方法は、サービスプロバイダー（SP）によって決定され、関係するすべてのLSRに事前に（つまり、プロビジョニングによって）通知される必要があります。
Other methods than the two specified above MAY be used; however, the specification of other methods is outside the scope of this document.
上記で指定した2つの方法以外の方法を使用できます。ただし、他のメソッドの仕様はこのドキュメントの範囲外です。
By using Targeted mLDP, we can construct an MP-LSP <R,X> containing an LSR U, where U has one or more downstream LSR neighbors (D1, ..., Dn) to which it is not directly connected. In order for a data packet to travel along this MP-LSP, U must have some way of transmitting the packet to D1, ..., Dn. We will cover two methods of transmission:
Targeted mLDPを使用すると、LSR Uを含むMP-LSP <R、X>を構築できます。Uには、直接接続されていない1つ以上のダウンストリームLSRネイバー（D1、...、Dn）があります。データパケットがこのMP-LSPに沿って移動するためには、UがパケットをD1、...、Dnに送信する何らかの方法を備えている必要があります。 2つの送信方法について説明します。
- Unicast Replication
- ユニキャストレプリケーション
In this method, U creates n copies of the packet and unicasts each copy to exactly one of D1, ..., Dn.
この方法では、Uはパケットのn個のコピーを作成し、各コピーをD1、...、Dnのいずれかに正確にユニキャストします。
- Multicast Tunneling
- マルチキャストトンネリング
In this method, U becomes the root node of a multicast tunnel, with D1, ..., Dn as leaf nodes. When a packet traveling along the MP-LSP <R,X> arrives at U, U transmits it through the multicast tunnel, and as a result it arrives at D1, ..., Dn.
この方法では、Uがマルチキャストトンネルのルートノードになり、D1、...、Dnがリーフノードになります。 MP-LSP <R、X>に沿って移動するパケットがUに到着すると、Uはそれをマルチキャストトンネルを介して送信し、その結果、D1、...、Dnに到着します。
When this method is used, it may be desirable to carry traffic of multiple MP-LSPs through a single multicast tunnel. We specify procedures that allow for the proper demultiplexing of the MP-LSPs at the leaf nodes of the multicast tunnel. We do not assume that all the leaf nodes of the tunnel are on all the MP-LSPs traveling through the tunnel; thus, some of the tunnel leaf nodes may need to discard some of the packets received through the tunnel. For example, suppose MP-LSP <R1,X1> contains node U with downstream LSRs D1 and D2, while MP-LSP <R2,X2> contains node U with downstream LSRs D2 and D3. Suppose also that there is a multicast tunnel with U as root and with D1, D2, and D3 as leaf nodes. U can aggregate both MP-LSPs in this one tunnel. However, D1 will have to discard packets that are traveling on <R2,X1>, while D3 will have to discard packets that are traveling on <R1,X2>.
この方法を使用する場合、単一のマルチキャストトンネルを通じて複数のMP-LSPのトラフィックを伝送することが望ましい場合があります。マルチキャストトンネルのリーフノードでMP-LSPの適切な逆多重化を可能にする手順を指定します。トンネルのすべてのリーフノードが、トンネルを通過するすべてのMP-LSPにあるとは限りません。したがって、トンネルリーフノードの一部は、トンネルを介して受信したパケットの一部を破棄する必要がある場合があります。たとえば、MP-LSP <R1、X1>にダウンストリームLSR D1およびD2のノードUが含まれ、MP-LSP <R2、X2>にダウンストリームLSR D2およびD3のノードUが含まれているとします。また、ルートとしてU、リーフノードとしてD1、D2、およびD3を使用するマルチキャストトンネルがあるとします。 Uは、この1つのトンネルで両方のMP-LSPを集約できます。ただし、D1は<R2、X1>を移動するパケットを破棄する必要がありますが、D3は<R1、X2>を移動するパケットを破棄する必要があります。
When LSR D is setting up MP-LSP <R,X>, it MUST NOT use Targeted mLDP unless D implements a procedure that can select an LSR U that is a Targeted mLDP peer of D as the "upstream LSR" for <R,X>. See Section 2.1.
LSR DがMP-LSP <R、X>を設定している場合、Dが<Rの「アップストリームLSR」としてDのターゲットmLDPピアであるLSR Uを選択できる手順を実装しない限り、ターゲットmLDPを使用してはなりません（MUST NOT）。 X>。セクション2.1を参照してください。
Whether D uses Targeted mLDP when this condition holds is determined by provisioning or by other methods that are outside the scope of this specification.
この条件が満たされたときにDがTargeted mLDPを使用するかどうかは、プロビジョニングまたはこの仕様の範囲外のその他の方法によって決定されます。
When Targeted mLDP is used, the choice between unicast replication and multicast tunneling is determined by provisioning or by other methods that are outside the scope of this specification. It is presupposed that all nodes will have a priori knowledge of whether to use unicast replication or to use multicast tunneling. If the latter, it is presupposed that all nodes will have a priori knowledge of the type of multicast tunneling to use.
Targeted mLDPを使用する場合、ユニキャストレプリケーションとマルチキャストトンネリングのどちらを選択するかは、この仕様の範囲外のプロビジョニングまたはその他の方法によって決まります。すべてのノードが、ユニキャストレプリケーションを使用するか、マルチキャストトンネリングを使用するかについて、事前に知識があることが前提となっています。後者の場合、すべてのノードが、使用するマルチキャストトンネリングのタイプを事前に知っていると想定されます。
Per [mLDP], any LSR that needs to set up an MP-LSP must support the procedures of [LDP-CAP], and in particular must send and receive the P2MP Capability and/or the MP2MP Capability. This specification does not define any new capabilities; the advertisement of the P2MP and/or MP2MP Capabilities on a Targeted LDP session means that the advertising LSR is capable of following the procedures set forth in this document.
[mLDP]ごとに、MP-LSPを設定する必要のあるすべてのLSRは、[LDP-CAP]の手順をサポートする必要があり、特にP2MP機能またはMP2MP機能、あるいはその両方を送受信する必要があります。この仕様では、新しい機能は定義されていません。ターゲットLDPセッションでのP2MPまたはMP2MP機能のアドバタイズは、LSRのアドバタイズがこのドキュメントで説明されている手順に従うことができることを意味します。
Some of the procedures described in this document require the use of upstream-assigned labels [LDP-UP]. In order to use upstream-assigned labels as part of Targeted mLDP, an LSR must advertise the LDP Upstream-Assigned Label Capability [LDP-UP] on the Targeted LDP session.
このドキュメントで説明されている手順の一部では、上流に割り当てられたラベル[LDP-UP]を使用する必要があります。アップストリーム割り当てラベルをターゲットmLDPの一部として使用するには、LSRがターゲットLDPセッションでLDPアップストリーム割り当てラベル機能[LDP-UP]をアドバタイズする必要があります。
When unicast replication is used, the mLDP procedures are exactly the same as described in [mLDP], with the following exception. If LSR D is setting up MP-LSP <R,X>, its "upstream LSR" is selected according to the procedures of Section 2.1, and is not necessarily the "IGP next hop" on D's path to R.
ユニキャストレプリケーションを使用する場合、mLDPの手順は[mLDP]で説明されている手順とまったく同じですが、次の点が異なります。 LSR DがMP-LSP <R、X>をセットアップしている場合、その「アップストリームLSR」はセクション2.1の手順に従って選択され、DのRへのパス上の「IGPネクストホップ」であるとは限りません。
Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP <R,X>, and that LSR U is the upstream LSR on each of their paths to R. D1 and D2 each binds a label to <R,X> and each uses a Label Mapping message to inform U of the label binding. Suppose D1 has assigned label L1 to <R,X> and D2 has assigned label L2 to <R,X>. (Note that L1 and L2 could have the same value or different values; D1 and D2 do not coordinate their label assignments.) When U has a packet to transmit on the MP-LSP <R,X>, it makes a copy of the packet, pushes on label L1, and unicasts the resulting packet to D1. It also makes a second copy of the packet, pushes on label L2, and then unicasts the resulting packet to D2.
LSR D1とD2が両方ともP2MP MP-LSP <R、X>をセットアップしており、LSR UがRへの各パスのアップストリームLSRであるとします。D1とD2はそれぞれラベルを<R、X>にバインドしますそして、それぞれがラベルマッピングメッセージを使用して、ラベルバインディングをUに通知します。 D1がラベルL1を<R、X>に割り当て、D2がラベルL2を<R、X>に割り当てたとします。 （L1とL2は同じ値または異なる値を持つ可能性があることに注意してください。D1とD2はラベルの割り当てを調整しません。）UがMP-LSP <R、X>で送信するパケットを持っている場合、パケット、ラベルL1をプッシュし、結果のパケットをD1にユニキャストします。また、パケットの2番目のコピーを作成し、ラベルL2をプッシュしてから、結果のパケットをD2にユニキャストします。
This procedure also works when the MP-LSP <R,X> is an MP2MP LSP. Suppose that in addition to labels L1 and L2 described above, U has assigned label L3 for <R,X> traffic received from D1 and label L4 for <R,X> traffic received from D2. When U processes a packet with label L3 at the top of its label stack, it knows the packet is from D1, so U sends a unicast copy of the packet to D2, after swapping L3 for L2. U does not send a copy back to D1.
この手順は、MP-LSP <R、X>がMP2MP LSPの場合にも機能します。上記のラベルL1とL2に加えて、UがD1から受信した<R、X>トラフィックにラベルL3を割り当て、D2から受信した<R、X>トラフィックにラベルL4を割り当てたとします。 Uは、ラベルスタックの最上位にあるラベルL3のパケットを処理するときに、パケットがD1からのものであることを認識しているため、L3をL2に交換した後、パケットのユニキャストコピーをD2に送信します。 UはコピーをD1に送り返しません。
Note that all labels used in this procedure are downstream-assigned labels.
この手順で使用されるすべてのラベルは、下流に割り当てられたラベルであることに注意してください。
The method of unicast is a local matter, outside the scope of this specification. The only requirement is that D1 will receive the copy of the packet carrying label L1 and that D1 will process the packet by looking up label L1. (And similarly, D2 must receive the copy of the packet carrying label L2 and must process the packet by looking up label L2.)
ユニキャストの方法はローカルな問題であり、この仕様の範囲外です。唯一の要件は、D1がラベルL1を運ぶパケットのコピーを受信し、D1がラベルL1を検索してパケットを処理することです。 （同様に、D2はラベルL2を運ぶパケットのコピーを受信し、ラベルL2を検索してパケットを処理する必要があります。）
Note that if the method of unicast is MPLS, U will need to push another label on each copy of the packet before transmitting it. This label needs to ensure that delivery of the packet to the appropriate LSR, D1 or D2. Use of penultimate-hop popping for that label is perfectly legitimate.
ユニキャストの方法がMPLSの場合、Uはパケットを送信する前に、パケットの各コピーに別のラベルをプッシュする必要があることに注意してください。このラベルは、適切なLSR、D1またはD2へのパケットの配信を保証する必要があります。そのラベルの最後から2番目のホップのポップの使用は完全に正当です。
Suppose that LSRs D1 and D2 are both setting up MP-LSP <R,X> and that LSR U is the upstream LSR on each of their paths to R. Since multicast tunneling is being used, when U has a packet to send on this MP-LSP, it does not necessarily send two copies, one to D1 and one to D2. It may send only one copy of the packet, which will get replicated somewhere downstream in the multicast tunnel. Therefore, the label that gets bound to the MP-LSP must be an upstream-assigned label assigned by U. This requires a change from the procedures of [mLDP]. D1 and D2 do not send Label Mapping messages to U; instead, they send Label Request messages to U, following the procedures of Section 4 of [LDP-UP], asking U to assign a label to the MP-LSP <R,X>. U responds with a Label Mapping message containing an upstream-assigned label L (using the procedures specified in [LDP-UP]). As part of the same Label Mapping message, U also sends an Interface TLV (as specified in [LDP-UP]) identifying the multicast tunnel in which data on the MP-LSP will be carried. When U transmits a packet on this tunnel, it first pushes on the upstream-assigned label L and then pushes on the label that corresponds to the multicast tunnel.
LSR D1とD2の両方がMP-LSP <R、X>をセットアップしており、LSR UがRへの各パスのアップストリームLSRであると想定します。マルチキャストトンネリングが使用されているため、Uにこれに送信するパケットがある場合MP-LSP。1つがD1に、もう1つがD2に送信されるとは限りません。パケットのコピーを1つだけ送信し、マルチキャストトンネルの下流のどこかに複製されます。したがって、MP-LSPにバインドされるラベルは、Uによって割り当てられた上流割り当てラベルでなければなりません。これには、[mLDP]の手順からの変更が必要です。 D1とD2はUにラベルマッピングメッセージを送信しません。代わりに、[LDP-UP]のセクション4の手順に従って、ラベル要求メッセージをUに送信し、MP-LSP <R、X>にラベルを割り当てるようUに要求します。 Uは、上流に割り当てられたラベルLを含むラベルマッピングメッセージで応答します（[LDP-UP]で指定された手順を使用）。 Uは、同じラベルマッピングメッセージの一部として、MP-LSP上のデータが伝送されるマルチキャストトンネルを識別するインターフェイスTLV（[LDP-UP]で指定）も送信します。 Uがこのトンネルでパケットを送信する場合、Uはまずアップストリームに割り当てられたラベルLをプッシュし、次にマルチキャストトンネルに対応するラベルをプッシュします。
If the numerical value L of the upstream-assigned label is the value 3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the specified multicast tunnel will carry only the specified MP-LSP. That is, aggregation of multiple MP-LSPs into a single multicast tunnel is not being done. In this case, no upstream-assigned label is pushed onto a packet that is transmitted through the multicast tunnel.
[LDP]および[RFC3032]で定義されている、上流に割り当てられたラベルの数値Lが値3である場合、「暗黙のNULL」として指定されたマルチキャストトンネルは、指定されたMP-LSPのみを伝送します。つまり、単一のマルチキャストトンネルへの複数のMP-LSPの集約は行われていません。この場合、上流に割り当てられたラベルは、マルチキャストトンネルを介して送信されるパケットにプッシュされません。
Various types of multicast tunnel may be used. The choice of tunnel type is determined by provisioning, or by some other method that is outside the scope of this document. [LDP-UP] specifies encodings allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well as other types of multicast tunnel.
さまざまなタイプのマルチキャストトンネルを使用できます。トンネルタイプの選択は、プロビジョニング、またはこのドキュメントの範囲外のその他の方法によって決定されます。 [LDP-UP]は、UがmLDP MP-LSP、RSVP-TE P2MP LSP、およびその他のタイプのマルチキャストトンネルを識別できるようにするエンコーディングを指定します。
Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are outside the scope of this document.
P2MPまたはMP2MP LSPを介してMP2MP LSPをトンネリングする手順は、このドキュメントの範囲外です。
If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, when U transmits a packet on the MP-LSP <R,X>, the upstream-assigned label L will be the second label in the label stack. Penultimate-hop popping MUST NOT be done, because the top label provides the context in which the second label is to be interpreted. See [RFC5331].
マルチキャストトンネルがmLDP MP-LSPまたはRSVP-TE P2MP LSPの場合、UがMP-LSP <R、X>でパケットを送信すると、上流に割り当てられたラベルLがラベルスタックの2番目のラベルになります。 2番目のラベルが解釈されるコンテキストをトップラベルが提供するため、最後から2番目のホップのポップは行わないでください。 [RFC5331]を参照してください。
When LSR U uses these procedures to inform LSR D that a particular MP-LSP is being carried in a particular multicast tunnel, U and D MUST take appropriate steps to ensure that the packets U sends into this tunnel will be received by D. The exact steps to take depend on the tunnel type. As long as U is D's upstream LSR for any MP-LSP that has been assigned to this tunnel, D must remain joined to the tunnel.
LSR Uがこれらの手順を使用して、特定のMP-LSPが特定のマルチキャストトンネルで運ばれていることをLSR Dに通知する場合、UとDは、Uがこのトンネルに送信するパケットがDによって受信されることを保証するために適切な手順を実行する必要があります。実行する手順は、トンネルのタイプによって異なります。 Uがこのトンネルに割り当てられているMP-LSPのDのアップストリームLSRである限り、Dはトンネルに参加したままである必要があります。
Note that U MAY assign the same multicast tunnel for multiple different MP-LSPs. However, U MUST assign a distinct upstream-assigned label to each MP-LSP. This allows the packets traveling through the tunnel to be demultiplexed into the proper MP-LSPs.
Uは複数の異なるMP-LSPに同じマルチキャストトンネルを割り当ててもよいことに注意してください。ただし、Uは各MP-LSPに異なるアップストリーム割り当てラベルを割り当てなければなりません（MUST）。これにより、トンネルを通過するパケットを適切なMP-LSPに逆多重化できます。
If U has an MP-LSP <R1,X1> with downstream LSRs D1 and D2, and an MP-LSP <R2,X2> with downstream LSRs D2 and D3, U may assign both MP-LSPs to the same multicast tunnel. In this case, D3 will receive packets traveling on <R1,X1>. However, the upstream-assigned label carried by those packets will not be recognized by D3, hence D3 will discard those packets. Similarly, D1 will discard the <R2,X2> packets.
Uに、ダウンストリームLSR D1およびD2を持つMP-LSP <R1、X1>、およびダウンストリームLSR D2およびD3を持つMP-LSP <R2、X2>がある場合、Uは両方のMP-LSPを同じマルチキャストトンネルに割り当てることができます。この場合、D3は<R1、X1>を移動するパケットを受信します。ただし、これらのパケットによって運ばれるアップストリーム割り当てラベルはD3によって認識されないため、D3はそれらのパケットを破棄します。同様に、D1は<R2、X2>パケットを破棄します。
This document does not specify any rules for deciding whether to aggregate two or more MP-LSPs into a single multicast tunnel. Such rules are outside the scope of this document.
このドキュメントでは、2つ以上のMP-LSPを単一のマルチキャストトンネルに集約するかどうかを決定するための規則は指定していません。このような規則は、このドキュメントの範囲外です。
Except for the procedures explicitly detailed in this document, the procedures of [mLDP] and [LDP-UP] apply unchanged.
このドキュメントで明示的に詳述されている手順を除いて、[mLDP]と[LDP-UP]の手順は変更されずに適用されます。
This document raises no new security considerations beyond those discussed in [LDP], [LDP-UP], and [RFC5331].
このドキュメントは、[LDP]、[LDP-UP]、および[RFC5331]で説明されているものを超える新しいセキュリティの考慮事項を提起しません。
The authors wish to thank Lizhong Jin and Lizhen Bin for their comments.
著者は、コメントを提供してくれたLizhong JinとLizhen Binに感謝します。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[LDP-CAP] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[LDP-CAP]トーマス、B、ラザ、K、アガーワル、S、アガーワル、JL。 Le Roux、「LDP Capabilities」、RFC 5561、2009年7月。
[mLDP] 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.
[mLDP] 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月。
[LDP-UP] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011.
[LDP-UP] Aggarwal、R.、JL。 Le Roux、「MPLS Upstream Label Assignment for LDP」、RFC 6389、2011年11月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
Authors' Addresses
著者のアドレス
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
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 USA
えりｃ Ｃ。 ろせん しｓこ Ｓｙｓてｍｓ、 いんｃ。 １４１４ まっさちゅせっｔｓ あゔぇぬえ ぼｘぼろうｇｈ、 ま、 ０１７１９ うさ
EMail: erosen@cisco.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands Cisco Systems、Inc. Kleetlaan 6a Diegem 1831ベルギー
EMail: ice@cisco.com