[要約] RFC 6512は、バックボーンがルートへの経路を持たない場合に、Multipoint LDPを使用する方法について説明しています。このRFCの目的は、ネットワークの拡張性と柔軟性を向上させるために、Multipoint LDPの使用を可能にすることです。
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
バックボーンにルートへのルートがないときにマルチポイントLDPを使用する
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フリーコアの一部である場合、これは不可能です。このドキュメントは、MP LSPをBGPフリーコアを介して構築できるようにする手順を指定します。これらの手順では、ルートノードアドレスは、中間ノードに知られているアドレスに一時的に置き換えられ、真のルートノードへのパスにあります。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 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.
この文書の公開。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]を拡張して、マルチポイントラベルスイッチ付きパスをサポートします。これらの拡張機能は、「Multipoint LDP」として、またはより単純に「MLDP」として知られています。[MLDP]は、いくつかのLDP転送等価クラス（FEC）要素エンコーディングを定義します：「ポイントツーマルチポイント」（P2MP）、「マルチポイントツーマルチポイント（MP2MP）アップストリーム」、および「MP2MPダウンストリーム」。
The encoding for these three FEC elements, as defined in [mLDP], is shown in Figure 1.
[MLDP]で定義されているように、これら3つのFEC要素のエンコードを図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」）は、「ルートノード」と変数の長さの「オパーク値」の組み合わせによって識別されることに注意してください。ルートノードは、MLDP手順で特別な役割を果たします。特定のMP LSPが「約」であるMLDPメッセージは、ルートノードへのルートの次のホップであるLDP隣接に転送されます。
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.
このような環境では、rにアドレス指定されたCE1からのユニキャストデータパケットは、PE1によってカプセル化され、PE2にトンネルされ、PE2によって脱カプセル化され、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メッセージは、CE1からPE1にPE1からP1、...、P2からPE2からCE2まで、CE2からCE2に渡す必要があります。
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はRORDADEをルートノードアドレスとしてrのアドレスでMP FEC要素を作成し、MLDPを介してPE1にそのFEC要素を渡します。ただし、P1にはRへのルートがないため、PE1はこの同じFEC要素を使用してLDPメッセージのLSPを識別することはできません。
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がPE2自体ではなくRに本当に根ざしていることを判断できます。
- PE2 can determine the original FEC element that CE1 passed to PE1, so that PE2 can pass it on to CE2.
- PE2は、CE1がPE1に渡した元のFEC要素を決定し、PE2がCE2に渡すことができます。
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がRにルート化されたLSPを作成できるようにする手順を定義します。これらの手順では、MLDPメッセージをP1に送信する前にMP FEC要素を変更するためにPE1が必要です。修正されたFEC要素は、ルートとしてPE2、元のFEC要素を不透明値として持っています。これには、新しいタイプの不透明な値が必要です。不透明な値にはFEC要素が含まれているため、これを「再帰的な不透明値」と呼びます。PE2がMLDPメッセージをCE2に送信すると、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
再帰的な不透明値の値フィールドは、それ自体が[MLDP]で指定されたとおりにエンコードされたP2MPまたはMP2MP FEC要素であり、タイプフィールド、長さフィールド、および独自の値フィールドを備えています。したがって、再帰的な不透明値の長さには、含まれる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がルートノードがRであり、その不透明な値がQであるMP FEC要素をPE1に送信すると仮定しましょう。このFEC要素を「CE1-FEC」と呼びます。CE1-FECを次のように順序付けられたペアと考えるかもしれません。
CE1-FEC = <root=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がBGPルートと一致し、BGPがPE2の次のホップであると判断します。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は新しいMP FEC要素を作成します。そのルートノードアドレスはPE2のアドレスであり、その不透明な値は、値フィールドにCE1-FECが含まれる再帰的な不透明値です。このFEC要素をPE2-FECと呼びます。
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
PE2-FEC = <root=PE2, opaque_value=<root=R,
opaque_value=Q>>
PE1 then sends this FEC element to P1.
PE1は、このFEC要素をP1に送信します。
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はIT（PE2）が特定されたルートノードであり、不透明な値が再帰的な不透明値であることに注意してください。したがって、PE2は、さらに処理する前に、PE2-FECを再帰的な不透明値の内容（つまり、CE1-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オクテットのルート違い（RD）で構成され、その後、[MLDP]で指定されたとおりにエンコードされたP2MPまたはMP2MP FEC要素が続き、タイプフィールド、長さフィールド、および、、および長さフィールド、およびの値フィールドは独自のものです。したがって、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）であると仮定します。これは、最初の自律システム（つまり、ASBR1）の自律システム境界ルーター（ASBR）には、他のASE（PE2など）のPEルーターへのルートがないことを意味します。また、マルチキャストVPN（MVPN）ポリシーは、MLDPを使用してプロバイダーマルチキャストサービスインターフェイス（PMSIS）[MVPN]をインスタンス化することであり、「非セグメント化されたP-Tunnels」[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へのルートがない場合でも、ASBR1がPE2への次のホップを見つけるのに十分な情報を含める必要があります。
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アドレスが含まれている包括的PMSI（I-PMSI）自動配信（A-D）ルート[MVPN]を含むBGP Intra-AS Intra-As-As-As-As As-As-As-As-Aso-Discovery（A-D）ルートがあります。特定のrd。PE1には、このINTER-AS I-PMSI A-Dルートもあります。LSPは、IPMSI AS 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-Tunnelsに提供されるMLDP P-Tunnelsに同じ機能を提供できます。
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は、PE2から発生するI-PMSI A-DルートとしてのIntra-as Intra-as as intra-intra-as intra-as intra-as as in the brfを調べます。そのルートのBGP次のホップはASBR1であることがわかります。したがって、ルートがASBR1であり、その不透明な値がVPN回復的なFEC要素である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から発信された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>>.
<root = asbr1、opaque_value = <root = 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が、このFEC要素を含むMLDPラベルマッピングメッセージである非VRFインターフェイスを受信すると、それがルートであり、不透明値が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>
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のアドレスが含まれているI-PMSI A-Dルート内のINTRA-AS I-PMSI A-Dルートを探します。そのルートのBGP次のホップはASBR2であるとします。次に、ASBR1は次のFEC要素を使用してLSPのセットアップを続けます。
<root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>.
<root = asbr2、opaque_value = <root = 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.
この場合、ルートはASBR1からASBR2に変更されましたが、不透明な値は変更されていない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のもう1つの使用可能な使用は、「キャリアのキャリアサービス」の限られたバージョンを提供することです。図2のトポロジーを再度参照すると、PE1/PE2が「キャリアのキャリアVPNサービス」[VPN]をCE1/CE2に提供していると仮定します。CE1は、ルートノードがRであり、オパーク値がQであるMP FEC要素をPE1に送信します。このFEC要素を「CE1-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再回帰不透明値の値フィールドは、8-OCTET RDに続くCE1-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 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ラベルマッピングメッセージがVRFインターフェイスを介してPE2に到着すると、PE2は識別されたルートノードであり、不透明な値はVPN回復的な不透明値であることに注意してください。したがって、さらに処理する前に、PE2-FECをVPN再回帰不透明値の内容（つまり、CE1-FEC）に置き換える必要があります。VRFを使用してRへのパスを検索します。これにより、CE1-FECがCE2に送信され、おそらくCE2からR.
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 Inter-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 Opaque Value Element Basic Type」のレジストリを定義します。このレジストリには、2つの新しいコードポイントが割り当てられています。
- 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].
このタイプの不透明な値は、[VPN]で定義されている8オクテットのルート違いの違いで構成され、その後、[MLDP]で定義されているMLDP FECタイプをコードするTLVが続きます。
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 Eckertに感謝したいと考えています。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「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。、ed。、Minei、I.、Ed。、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチパスのラベル分布プロトコル拡張」、RFC 6388、2011年11月。
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[MVPN] Rosen、E.、ed。、およびR. Aggarwal、ed。、「マルチキャスト/BGP IP VPNS」、RFC 6513、2012年2月。
[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月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「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 Cisco Systems、Inc。de Kleetlaan 6a Diegem 1831 Belgiumメール：ice@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 EMail: erosen@cisco.com
Eric C. Rosen Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719メール：erosen@cisco.com
Maria Napierala AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 EMail: mnapierala@att.com
Maria Napierala AT＆T Labs 200 Laurel Avenue Middletown、NJ 07748メール：mnapierala@att.com
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany EMail: n.leymann@telekom.de
ニコライ・レイマン・ドイツ・テューシェ・テレコム・ウィンターフェルドストラッシ21ベルリン10781ドイツメール：n.leymann@telekom.de