Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 6512 E. Rosen
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Napierala
AT&T
N. Leymann
Deutsche Telekom
February 2012
Using Multipoint LDP When the Backbone Has No Route to the Root
Abstract
抽象
The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node.
制御プロトコルポイントツーマルチ構築するために使用され、マルチポイント・ツー・マルチラベル（「MPのLSP」）パスのスイッチは、「ルートノード」のアドレスを識別するフィールドを含みます。中間ノードは、そのルーティングテーブルにそのアドレスを調べることができるように期待されています。ルートノードへの経路がBGPルートであり、中間ノードは、BGP-フリーコアの一部である場合は、これは不可能です。この文書では、BGP-フリーコアを構築するMP LSPを有効に処置を指定します。これらの手順では、ルートノードのアドレスを一時的に中間ノードに知られており、真のルートノードへの経路上にあるされたアドレスに置き換えられています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc6512.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6512で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
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.
本書の出版物。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. The Recursive Opaque Value ......................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
3. The VPN-Recursive Opaque Value ..................................6
3.1. Encoding ...................................................6
3.2. Procedures .................................................7
3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
3.2.2. Limited Carrier's Carrier Function ..................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
The document [mLDP] extends LDP [LDP] to support multipoint Label Switched Paths. These extensions are known as "Multipoint LDP", or more simply, as "mLDP". [mLDP] defines several LDP Forwarding Equivalence Class (FEC) element encodings: "Point-to-Multipoint" (P2MP), "Multipoint-to-Multipoint (MP2MP) Upstream", and "MP2MP Downstream".
文書には、[MLDP]マルチラベルはパスの交換をサポートするためにLDP [LDP]を拡張します。これらの拡張機能は、「MLDP」として、「マルチLDP」として知られている、または単により多くされています。 「ポイントツーマルチポイント」（P2MP）、「マルチポイント・ツー・マルチポイント（MP2MP）上流」および「下流MP2MP」：[MLDP]いくつかのLDP転送等価クラス（FEC）要素エンコーディングを定義します。
The encoding for these three FEC elements, as defined in [mLDP], is shown in Figure 1.
これら三つのFEC要素に対する符号化は、[MLDP]で定義されるように、図1に示されています。
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 | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| Opaque Value |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: mLDP FEC Element Encoding
図1：MLDP FEC要素のエンコーディング
Note that a P2MP or MP2MP Label Switched Path ("MP LSP") is identified by the combination of a "root node" and a variable length "opaque value". The root node also plays a special role in the mLDP procedures: mLDP messages that are "about" a particular MP LSP are forwarded to the LDP adjacency that is the next hop on the route to the root node.
P2MP又はMP2MPラベルスイッチパス（「MP LSP」）は、「ルートノード」と可変長「不透明値」の組み合わせによって識別されることに留意されたいです。特定のMP LSPがルートノードへの経路上の次のホップであるLDP隣接に転送されている「約」ですMLDPメッセージ：ルートノードはまた、MLDP手順で特別な役割を果たしています。
Sometimes, it is desirable for an MP LSP to pass through a part of the network in which there is no route to the root node. For instance, consider the topology of Figure 2.
MP LSPがルートノードへの経路が存在しないれたネットワークの一部を通過するために、時には、それが望ましいです。例えば、図2のトポロジーを考えます。
CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
Figure 2
図2
In Figure 2, CE1 and CE2 are "Customer Edge routers", R is a customer router at the same VPN site as CE2, and PE1 and PE2 are "Provider Edge routers". Suppose that PE1 has a BGP-learned route for R, with
図2では、CE1とCE2は、「カスタマーエッジルータ」であり、RはCE2と同じVPNサイトでの顧客のルータで、PE1とPE2は「プロバイダーエッジルータ」です。 PE1は、R用BGP学習ルートを持っていると仮定し、と
PE2 as the BGP next hop. Suppose also that the provider's interior routers (such as P1 and P2) do not have any BGP-learned routes and, in particular, do not have any routes to R.
BGPネクストホップとしてPE2。 （例えばP1とP2など）プロバイダの内部ルータは、任意のBGP学習ルートを持っていないと、特に、R.へのルートを持っていないことも想定
In such an environment, unicast data packets from CE1 addressed to R would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and forwarded to CE2.
このような環境では、CE1からのユニキャストデータパケットはR宛はPE2でデカプセル化PE2、にトンネリング、PE1によってカプセル化、およびCE2に転送になるだろう。
Suppose now that CE1 is trying to set up an MP LSP whose root is R, and the intention is that the provider's network will participate in the construction of the LSP. Then, the mLDP messages identifying the LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to PE2, from PE2 to CE2, and from CE2 to R.
CE1は、ルートRであるMP LSPを設定しようとしている、との意図がプロバイダのネットワークは、LSPの建設に参加することであるということになりましたと。次に、LSPを識別MLDPメッセージは、PE1からP1に、CE1からPE1に渡さなければならない...、P2からPE2へ、PE2からCE2に、及びCE2からRに
To begin the process, CE1 creates an MP FEC element with the address of R as the root node address and passes that FEC element via mLDP to PE1. However, PE1 cannot use this same FEC element to identify the LSP in the LDP messages it sends to P1, because P1 does not have a route to R.
プロセスを開始するために、CE1は、ルートノードアドレスとしてRのアドレスとMP FEC要素を作成し、PE1にMLDPを介してそのFEC要素を通過します。 P1はR.へのルートを持っていないためしかし、PE1は、それがP1に送信するLDPメッセージにLSPを識別するために、この同じFEC要素を使用することはできません
However, PE1 does know that PE2 is the BGP next hop on the path to R. What is needed is a method whereby:
しかし、PE1はPE2が必要とされているR.へのパス上のBGPネクストホップが法となるであることを知っています：
- PE1 can tell P1 to set up an LSP as if the root node were PE2,
- PE1がルートノードがPE2たかのようにLSPを設定するP1を伝えることができ、
- PE2 can determine that the LSP in question is really rooted at R, not at PE2 itself, and
- PE2は、問題のLSPは本当にRではなく、PE2自体に根ざしていることを決定することができ、かつ
- PE2 can determine the original FEC element that CE1 passed to PE1, so that PE2 can pass it on to CE2.
- PE2はCE2にそれを渡すことができるように、PE2は、CE1はPE1に渡された元のFEC要素を決定することができます。
This document defines the procedures that allow CE1 to create an LSP rooted at R. These procedures require PE1 to modify the MP FEC element before sending an mLDP message to P1. The modified FEC element has PE2 as the root and the original FEC element as the opaque value. This requires a new type of opaque value. Since the opaque value contains a FEC element, we call this a "Recursive Opaque Value". When PE2 sends an mLDP message to CE2, it replaces the FEC element with the opaque value, thus undoing the recursion. Details are in Section 2.
この文書では、CE1は、これらの手順は、PE1がP1にMLDPメッセージを送信する前に、MP FEC要素を変更する必要がR.をルートLSPを作成することを可能にする手順を定義します。修飾されたFEC要素がルートと不透明な値として、元のFEC要素としてPE2を有します。これは不透明値の新しいタイプを必要とします。不透明な値がFEC要素を含んでいるので、私たちは、この「再帰的な不透明値」と呼びます。 PE2はCE2にMLDPメッセージを送信するとき、それは、このように再帰を取り消し、不透明な値とFEC要素を置き換えます。詳細は、2章です。
Section 3 defines the "VPN-Recursive Opaque Value". Whereas the "Recursive Opaque Value" carries the original FEC, the "VPN-Recursive Opaque Value" carries the original FEC plus a Route Distinguisher (RD). This is applicable when MP LSPs are being used to carry the multicast traffic of a VPN [MVPN]. Details are in Section 3.
第3節では、「VPN-再帰不透明値」を定義します。 「再帰不透明値が」元のFECを運び、一方、「VPN-再帰不透明値は」元のFECプラスルート識別子（RD）を運びます。 MP用のLSPは、VPN [MVPN]のマルチキャストトラフィックを運ぶために使用されている場合にも適用可能です。詳細は、セクション3です。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
We define a new type of opaque value, the Recursive Opaque Value. This is a "basic type", identified by a 1-octet type field.
私たちは、不透明な値の新しいタイプの、再帰不透明値を定義します。これは、1オクテットのタイプフィールドで識別される「基本型」、です。
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 = 7 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Recursive Opaque Value
図3：再帰的な不透明値
The value field of the Recursive Opaque Value is itself a P2MP or MP2MP FEC element, encoded exactly as specified in [mLDP], with a type field, a length field, and value field of its own. The length of the Recursive Opaque Value thus includes the lengths of the type, length, and value fields of the contained FEC element.
再帰不透明値の値フィールドは、P2MP又はMP2MP FEC素子自体であり、タイプフィールド、長さフィールド、および独自の値フィールドで、[MLDP]で指定されたとおりに符号化されました。再帰不透明値の長さは、このように含まれるFEC要素のタイプ、長さ、および値フィールドの長さを含みます。
In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP FEC element whose root node is R and whose opaque value is Q. We will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC as an ordered pair, as follows:
図2のトポロジでは、私たちはCE1はPE1に、ルートノードであるR、その不透明な値私たちは、「CE1-FEC」として、このFEC要素を参照しますQ.あるMP FEC要素を送信したとしましょう。次のように我々は、順序対としてCE1-FECを考えることがあります。
CE1-FEC = <root=R, opaque_value=Q>.
CE1-FEC = <ルート= R、opaque_value = Q>。
PE1 determines that the root node R matches a BGP route, with a BGP next hop of PE2. PE1 also knows by its configuration that the interior routers on the path to PE2 are "BGP-free" and thus have no route to R.
PE1は、ルートノードRは、PE2のBGPネクストホップと、BGPルートと一致することを決定します。 PE1はまた、PE2へのパス上の内部ルータは、「BGP-自由」であり、したがってR.へのルートを持っていないこと、その構成によって知っています
PE1 therefore creates a new MP FEC element, whose root node address is the address of PE2 and whose opaque value is a Recursive Opaque Value whose value field contains CE1-FEC. We refer to this FEC element as PE2-FEC:
PE1は、したがって、ルートノードアドレス不透明値値フィールドCE1-FECが含ま再帰不透明値であるPE2のアドレスと新しいMP FEC要素を作成します。私たちは、PE2-FECとして、このFEC要素を参照してください。
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
PE2-FEC = <ルート= PE2、opaque_value = CE1-FEC>、すなわち、
PE2-FEC = <root=PE2, opaque_value=<root=R, opaque_value=Q>>
PE2-FEC = <ルート= PE2、opaque_value = <ルート= R、opaque_value = Q >>
PE1 then sends this FEC element to P1.
PE1は、P1に、このFEC要素を送ります。
As far as the interior routers are concerned, they are being requested to build an MP LSP whose root node is PE2. They MUST NOT interpret the opaque value at all.
限り内部ルータが懸念しているとして、彼らは、ルートノードPE2であるMP LSPを構築するために要求されています。彼らは全く不透明な値を解釈してはなりません。
When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the identified root node and that the opaque value is a Recursive Opaque Value. Therefore, PE2 MUST replace PE2-FEC with the contents of the Recursive Opaque Value (i.e., with CE1-FEC) before doing any further processing. This will result in CE1-FEC being sent on to CE2, and further from CE2 to R. Note that CE1-FEC will contain the LSP root node specified by CE1; the presumption is that PE2 has a route to this root node.
PE2-FECがPE2に到着すると、PE2は（PE2）が同定されたルートノードであり、不透明な値は再帰不透明値であることを指摘しています。したがって、PE2は、任意のさらなる処理を行う前に（CE1-FEC有する即ち、）再帰不透明値の内容とPE2-FECを交換しなければなりません。これはCE1-FECをもたらすがCE2へ送られ、さらにCE2からRにCE1-FECはCE1で指定されたLSPのルートノードを含むことに注意してください。推定はPE2が、このルートノードへのルートが設定されていることです。
We define a new type of opaque value, the VPN-Recursive Opaque Value. This is a "basic type", identified by a 1-octet type field.
私たちは、不透明な値の新しいタイプの、VPN-再帰不透明値を定義します。これは、1オクテットのタイプフィールドで識別される「基本型」、です。
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 = 8 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VPN-Recursive Opaque Value
図4：VPN-再帰不透明値
The value field of the VPN-Recursive Opaque Value consists of an 8-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC element, encoded exactly as specified in [mLDP], with a type field, a length field, and value field of is own. The length of the VPN-Recursive Opaque Value thus includes the 8 octets of RD plus the
VPN-再帰不透明値の値フィールドは、から成る8オクテットタイプフィールド、長さフィールドと、[MLDP]で指定されるように正確に符号化されたP2MP又はMP2MP FEC要素、続いてルート区分（RD）、及び値フィールドは、独自のです。 VPN-再帰不透明値の長さは、このようにRDプラスの8つのオクテットを含みます
lengths of the type, length, and values fields of the contained FEC element.
タイプの長さ、長さ、及び含まれるFEC要素のフィールド値。
Consider the inter-AS (Autonomous System) VPN scenario depicted in Figure 5.
図5に示されているインターAS（自律システム）VPNシナリオを考えます。
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
Figure 5
図5
Suppose this is an "option B" VPN interconnect ([VPN], Section 10). This means that the Autonomous System Border Router (ASBR) in the first Autonomous System (i.e., ASBR1) does not have a route to PE routers in other ASes (such as PE2). Suppose also that the Multicast VPN (MVPN) policy is to instantiate Provider Multicast Service Interfaces (PMSIs) [MVPN] using mLDP and that "non-segmented inter-AS P-tunnels" [MVPN] are being used.
これは、 "オプションB" VPN相互接続（[VPN]、セクション10）であると仮定する。これは、最初の自律システム内の自律システム境界ルータ（ASBR）（即ち、ASBR1）が（例えばPE2のような）他のAS内のルータをPEに経路を有していないことを意味します。マルチキャストVPN（MVPN）ポリシーがMLDPを使用してプロバイダマルチキャストサービスインターフェイス（PMSIs）MVPN]をインスタンス化することも想定し、その「非分節間AS P-トンネルは」[MVPN]は使用されています。
In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root is PE2. P1 has no route to PE2, and all PE1 knows about the route to PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2, PE1 needs to originate an mLDP message with a FEC element that identifies ASBR1 as the root. This FEC element must contain enough information to enable ASBR1 to find the next hop towards PE2 even though ASBR1 does not have a route to PE2.
このシナリオでは、PE1は、そのルートPE2であるP2MP又はMP2MP LSPに参加する必要があるかもしれません。 P1は、PE2へのルートを持っていない、とPE1はPE2へのルートについて知っているすべてはASBR1は、BGPネクストホップであるということです。 P1は、PE2へのルートを持っていないので、PE1は、ルートとしてASBR1を識別するFEC要素とMLDPメッセージを発信する必要があります。このFEC要素はASBR1はPE2へのルートを持っていないにもかかわらず、PE2に向けた次のホップを見つけるために、ASBR1を可能にするために十分な情報が含まれている必要があります。
Although ASBR1 does not have a route to PE2, it does have a BGP Intra-AS Inclusive PMSI (I-PMSI) auto-discovery (A-D) route [MVPN] whose Network Layer Reachability Information (NLRI) contains PE2's IP address together with a particular RD. PE1 also has this Inter-AS I-PMSI A-D route. The LSP needs to be set up along the path established by the Intra-AS I-PMSI A-D routes. Therefore, one must use a Recursive FEC element that contains the RD as well as the address of PE2. The "VPN-Recursive FEC Element" defined herein is used for this purpose.
ASBR1はPE2へのルートを持っていませんが、それは、そのネットワーク層到達可能性情報（NLRI）が一緒になってPE2のIPアドレスが含まれているBGPイントラASインクルーシブPMSI（I-PMSI）自動検出（AD）ルート[MVPN]を持っています特定のRD。 PE1も、このインターAS I-PMSI A-Dのルートを持っています。 LSPは、イントラAS I-PMSI A-Dの経路によって確立された経路に沿って設定する必要があります。そのため、一つはRDだけでなく、PE2のアドレスが含まれている再帰FEC要素を使用する必要があります。本明細書に定義される「VPN-再帰FEC要素は、」この目的のために使用されます。
This enables us to provide the same functionality for mLDP P-tunnels that is provided for PIM P-tunnels in Section 8.1.3.2 of [MVPN] through the use of the MVPN Join Attribute.
これは、MVPNを使用して[MVPN]のセクション8.1.3.2でPIM-Pトンネルのために提供されてMLDP P-トンネルの同じ機能を提供することを可能属性に参加。
At PE1 in Figure 4, the LSP to be created is associated with a particular VPN Routing and Forwarding Table (VRF). PE1 looks up in that VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that the BGP next hop of that route is ASBR1. So, it creates a P2MP or MP2MP FEC element whose root is ASBR1 and whose opaque value is a VPN-Recursive FEC element. The VPN-Recursive FEC element itself consists of a root, an RD, and an opaque value, set as follows:
図4のPE1で、作成されるLSPは、特定のVPNルーティングおよび転送テーブル（VRF）に関連付けられています。 PE1は、そのVRFにPE2によって発信イントラAS I-PMSI A-Dのルートを検索します。これは、そのルートのBGPネクストホップがASBR1であることを発見します。だから、それは、そのルート不透明値VPN-再帰FEC要素でASBR1とあるP2MPまたはMP2MP FEC要素を作成します。 VPN-再帰FEC要素自体は、以下のように設定ルート、RD、不透明値、から構成されています。
- The root is PE2.
- ルートはPE2です。
- The RD is the RD from the NLRI of the Intra-AS A-D route originated by PE2.
- RDはPE2によって発信イントラAS A-Dの経路のNLRIからRDです。
- The opaque value is chosen (by some method outside the scope of this document) so as to be unique in the context of PE2. (For example, it may have been specified in a PMSI Tunnel Attribute originated by PE2.) We will refer to this opaque value as "Q".
- PE2の文脈内で一意になるように不透明な値（この文書の範囲外のいくつかの方法によって）選択されます。 （例えば、それはPE2によって発信PMSIトンネル属性で指定された可能性があります。）私たちは、「Q」として、この不透明な値を参照します。
The resulting FEC element can be informally represented as
得られたFEC要素は、非公式のように表すことができます。
<root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.
<ルート= ASBR1、opaque_value = <ルート= PE2、RD、opaque_value = Q >>。
PE1 can now begin setting up the LSP by using this FEC element in an LDP Label Mapping message sent towards ASBR1.
PE1は今ASBR1に向けて送られたLDPラベルマッピングメッセージにこのFEC要素を使用してLSPの設定を開始することができます。
When ASBR1 receives, over a non-VRF interface, an mLDP Label Mapping message containing this FEC element, it sees that it is the root and that the opaque value is a VPN-Recursive Opaque Value. It parses the VPN-Recursive Opaque value and extracts the root value, PE2.
ASBR1が受信した場合、非VRFインタフェースを介して、このFEC要素を含むMLDP Label Mappingメッセージは、それがルートであることと不透明値はVPN-再帰不透明値であることを見ます。これは、VPN-再帰不透明値を解析し、ルート値、PE2を抽出します。
If ASBR1 has a route to PE2, it continues setting up the LSP by using the following FEC element:
ASBR1はPE2へのルートを持っている場合、それは以下のFEC要素を使用してLSPを設定し続けます。
<root=PE2, opaque_value=Q>
<ルート= PE2、opaque_value = Q>
However, if ASBR1 does not have a route to PE2, it looks for an Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along with the specified RD value. Say the BGP next hop of that route is ASBR2. Then ASBR1 continues setting up the LSP by using the following FEC element:
ASBR1はPE2へのルートを持っていない場合しかし、それは、そのNLRIが指定したRD値と共にPE2のアドレスが含まれているイントラAS I-PMSI A-Dのルートを探します。そのルートのBGPネクストホップがASBR2であると言います。その後、ASBR1は、次のFEC要素を使用してLSPを設定し続けます。
<root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>.
<ルート= ASBR2、opaque_value = <ルート= PE2、RD、opaque_value = Q >>。
Note that in this case, the root has changed from ASBR1 to ASBR2, but the opaque value is the unchanged VPN-Recursive FEC element.
この場合、ルートはASBR2にASBR1から変更されているが、不透明な値は変化しないVPN-再帰FEC要素であることに留意されたいです。
Another possible use of the VPN-Recursive FEC is to provide a limited version of "Carrier's Carrier Service". Referring again to the topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC element whose root node is R and whose opaque value is Q. We will refer to this FEC element as "CE1-FEC". However, PE1's route to R will be in a VRF. Therefore, the FEC element created by PE1 must contain some identifier that PE2 can use to find the proper VRF in which to look up the address of R.
VPN-再帰FECのもう一つの可能な用途は、「キャリアのキャリアサービス」の限定バージョンを提供することです。図2のトポロジを再び参照すると、CE1 / CE2に[VPN]「キャリアのキャリアVPNサービス」を提供しているPE1 / PE2と仮定します。 CE1はPE1に、ルートノードRと不透明値Q.我々は「CE1-FEC」としてFEC要素を参照しますされMP FEC要素を送信します。しかし、RへのPE1のルートはVRFになります。したがって、PE1によって作成されたFEC要素はPE2はR.のアドレスを検索するには、適切なVRFを見つけるために使用できるいくつかの識別子が含まれている必要があります
When PE1 looks up the address of R in a VRF, it will find a route in the VPN-IP address family. The next hop will be PE2, but there will also be a Route Distinguisher (RD) as part of that NLRI of the matching route. In this case, the new FEC element created by PE1 has the address of PE2 as the root node address and has a VPN-Recursive Opaque Value. The value field of the VPN-Recursive Opaque Value consists of the 8-octet RD followed by CE1-FEC.
PE1はVRF内Rのアドレスを検索する場合は、VPN-IPアドレスファミリのルートを検索します。次のホップはPE2であろうが、また、マッチングルートのNLRIの一部として、ルート識別子（RD）が存在することになります。この場合、PE1によって作成された新たなFEC要素は、ルートノードアドレスとしてPE2のアドレスを持ち、VPN-再帰不透明値を有します。 VPN-再帰不透明値の値フィールドは、CE1-FEC続く8オクテットRDから成ります。
As far as the interior routers are concerned, they are being requested to build an MP LSP whose root node is PE2. They MUST NOT interpret the opaque value at all.
限り内部ルータが懸念しているとして、彼らは、ルートノードPE2であるMP LSPを構築するために要求されています。彼らは全く不透明な値を解釈してはなりません。
When an mLDP Label Mapping message containing PE2-FEC arrives at PE2 over a VRF interface, PE2 notes that it is the identified root node and that the opaque value is a VPN-Recursive Opaque Value. Therefore, it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque Value (i.e., with CE1-FEC) before doing any further processing. It uses the VRF to look up the path to R. This will result in CE1-FEC being sent on to CE2, and presumably further from CE2 to R.
PE2-FECを含有MLDP Label Mappingメッセージは、VRFインターフェイス上PE2に到着すると、PE2は、識別されたルートノードであり、不透明な値は、VPN-再帰不透明値であることを指摘しています。したがって、任意のさらなる処理を行う前に（CE1-FEC有する即ち、）VPN-再帰不透明値の内容とPE2-FECを交換しなければなりません。これは、CE1-FECになります。これは、RにCE2から、おそらくさらにCE2の上で送信され、中のR.へのパスを検索するためにVRFを使用しています
In this scenario, the RD in the VPN-Recursive Opaque Value also ensures uniqueness of the FEC element within the inner carrier's network.
このシナリオでは、VPN-再帰不透明値でRDはまた、内側キャリアのネットワーク内のFEC要素の一意性を保証します。
This way of providing Carrier's Carrier service has limited applicability, as it only works under the following conditions:
それだけで以下の条件の下で働くように、キャリアのキャリアサービスを提供するこの方法は、適用可能性を制限されています：
- Both the inner carrier and the outer carrier are using non-segmented mLDP P-tunnels.
- 内側キャリアと外側のキャリアの両方が非セグメントMLDP P-トンネルを使用しています。
- The inner carrier is not aggregating the P-tunnels of the outer carrier but is content to carry each such P-tunnel in a single P-tunnel of its own.
- 内側のキャリアは、外側キャリアのP-トンネルを集約が、独自の単P-トンネル内でこのような各P-トンネルを伝送するコンテンツであるれていません。
The Carrier's Carrier scenario can be distinguished from the inter-AS scenario by the fact that in the former, the mLDP messages are being exchanged on VRF interfaces.
キャリアのキャリアのシナリオは、前者では、MLDPメッセージは、VRFインターフェイス上で交換されているという事実によってAS間のシナリオを区別することができます。
[mLDP] defines a registry for "The LDP MP Opaque Value Element Basic Type". Two new code points have been assigned in this registry:
[MLDP]「LDP MP不透明要素値基本タイプ」のレジストリを定義します。二つの新しいコードポイントは、このレジストリに割り当てられています：
- Recursive Opaque Value: Type 7
- 再帰不透明値：タイプ7
An opaque value of this type is itself a TLV that encodes an mLDP FEC type, as defined in [mLDP].
このタイプの不透明な値は、[MLDP]で定義されるように、MLDP FECタイプをコードTLV自体です。
- VPN-Recursive Opaque Value: Type 8
- VPN-再帰不透明値：タイプ8
An opaque value of this type consists of an 8-octet Route Distinguisher as defined in [VPN], followed by a TLV that encodes an mLDP FEC type, as defined in [mLDP].
このタイプの不透明な値は、[MLDP]で定義されるように、MLDP FECタイプをコードTLVに続いて、[VPN]で定義されるように8オクテットルート識別子から成ります。
The security considerations of [LDP] and [mLDP] apply.
[LDP]のセキュリティの考慮はして[MLDP]適用されます。
Unauthorized modification of the FEC elements defined in this document can disrupt the creation of the multipoint LSPs or can cause the multipoint LSPs to pass through parts of the network where they are not supposed to go. This could potentially be used as part of an attack to illegitimately insert or intercept multicast traffic. However, since the FEC elements defined in this document are not inherently more vulnerable to this form of attack than are the previously defined FEC elements, this document does not add new security vulnerabilities.
この文書で定義されたFEC要素の不正な変更は、マルチポイントLSPの作成を中断したり、マルチポイントのLSPは、彼らが行くことになっていないネットワークの部分を通過する可能性があります。これは、潜在的に違法にマルチキャストトラフィックを挿入したり、傍受する攻撃の一部として使用することができます。この文書で定義されたFEC要素は、本質的に以前に定義されたFEC要素よりも、この形式の攻撃に対して脆弱ではありませんので、この文書は、新しいセキュリティの脆弱性を追加しません。
A description of general security issues for MPLS can be found in [RFC5920].
MPLSのための一般的なセキュリティ上の問題の記述は、[RFC5920]で見つけることができます。
The authors wish to thank Toerless Eckert for his contribution to this work.
作者はこの作品への彼の貢献のためにToerlessエッカートに感謝したいです。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[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。、エド。、Minei、I.、エド。、Kompella、K.、およびB.トーマス、「ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスのスイッチのためのラベル配布プロトコルの拡張機能」 、RFC 6388、2011年11月。
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[MVPN]ローゼン、E.、エド。、およびR.アガルワル、エド。、RFC 6513、2012年2月 "MPLS / BGP VPNのIPにおけるマルチキャスト"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijnandsシスコシステムズ株式会社Kleetlaan 6aはディーゲム1831ベルギーEメール：ice@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 Eメール：erosen@cisco.com
Maria Napierala AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 EMail: mnapierala@att.com
マリアNapierala AT＆T Labsの200ローレルアベニューミドルタウン、NJ 07748 Eメール：mnapierala@att.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: n.leymann@telekom.de
ニコライLeymannドイツテレコムWinterfeldtstrasse 21ベルリン10781ドイツEメール：n.leymann@telekom.de