RFC 7441 - Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7441
タイトル : RFC 7441 - BGP MCAST-VPNルートのNLRIでのマルチポイントLDP（mLDP）転送等価クラス（FEC）のエンコード
翻訳編集 : 自動生成

[要約] RFC 7441は、BGP MCAST-VPNルートのNLRIにmLDP転送等価クラス（FEC）をエンコードする方法を提案しています。このRFCの目的は、マルチポイントLDP（mLDP）とBGP MCAST-VPNの統合を可能にし、マルチキャストトラフィックの効率的な転送を実現することです。

Internet Engineering Task Force (IETF)                      IJ. Wijnands
Request for Comments: 7441                           Cisco Systems, Inc.
Updates: 6514                                                   E. Rosen
Category: Standards Track                         Juniper Networks, Inc.
ISSN: 2070-1721                                                U. Joorde
                                                        Deutsche Telekom
                                                            January 2015

Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes

BGP MCAST-VPNルートのNLRIでのマルチポイントLDP（mLDP）転送等価クラス（FEC）のエンコード

Abstract

概要

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

多くのサービスプロバイダーは、「BGP / MPLS IP VPN」サービスを顧客に提供しています。既存のIETF標準は、VPNでIPユニキャストおよびIPマルチキャストトラフィックを持つ顧客にこのサービスを提供するためにサービスプロバイダーが使用する手順とプロトコルを指定しています。また、VPNでMPLSマルチキャストトラフィックを持つ顧客をサポートできることが望ましいです。このドキュメントでは、MPLSマルチキャストトラフィックの制御プロトコルとしてマルチポイントLDP（mLDP）を使用する顧客をサポートするために必要な手順とプロトコル拡張を指定します。既存の標準は、mLDPを使用する顧客にいくつかのサポートを提供しますが、制限された一連の状況下でのみです。このドキュメントでは、既存のサポートを一般化して、お客様がmLDPを使用するすべてのケースを制限なしに含めます。このドキュメントはRFC 6514を更新します。

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/rfc7441.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7441で入手できます。

著作権表示

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. Why This Document is Needed .....................................3
   3. Encoding an mLDP FEC in the MCAST-VPN NLRI ......................5
   4. Wildcards .......................................................7
   5. IANA Considerations .............................................7
   6. Security Considerations .........................................8
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References .....................................9
   Acknowledgments ...................................................10
   Authors' Addresses ................................................10

1. Introduction

1. はじめに

Many service providers (SPs) offer BGP/MPLS IP VPN service to their customers. When a customer has IP multicast traffic in its VPN, the service provider needs to signal the customer multicast states across the backbone. A customer with IP multicast traffic is typically using PIM (Protocol Independent Multicast) [PIM] and/or IGMP (Internet Group Management Protocol) [IGMP] as the multicast control protocol in its VPN. The IP multicast states of these protocols are commonly denoted as "(S,G)" and/or "(*,G)" states, where "S" is a multicast source address and "G" is a multicast group address. [MVPN-BGP] specifies the way an SP may use BGP to signal a customer's IP multicast states across the SP backbone. This is done by using Multiprotocol BGP Updates whose Subsequent Address Family Identifier (SAFI) values contain the codepoint for MCAST-VPN (as defined in [MVPN-BGP]). The NLRI (Network Layer Reachability Information) field of these BGP Updates includes a customer Multicast Source field and a customer Multicast Group field, thus enabling the customer's (S,G) or (*,G) states to be encoded in the NLRI.

多くのサービスプロバイダー（SP）は、BGP / MPLS IP VPNサービスを顧客に提供しています。カスタマーのVPNにIPマルチキャストトラフィックがある場合、サービスプロバイダーはバックボーン全体にカスタマーマルチキャストステートを通知する必要があります。 IPマルチキャストトラフィックを使用する顧客は、通常、VPNのマルチキャスト制御プロトコルとしてPIM（プロトコル独立マルチキャスト）[PIM]またはIGMP（インターネットグループ管理プロトコル）[IGMP]を使用しています。これらのプロトコルのIPマルチキャスト状態は、一般に「（S、G）」または「（*、G）」状態として表されます。「S」はマルチキャストソースアドレス、「G」はマルチキャストグループアドレスです。 [MVPN-BGP]は、SPがBGPを使用して、SPバックボーン全体で顧客のIPマルチキャスト状態を通知する方法を指定します。これは、後続プロトコルファミリ識別子（SAFI）の値にMCAST-VPNのコードポイント（[MVPN-BGP]で定義）が含まれているマルチプロトコルBGPアップデートを使用して行われます。これらのBGPアップデートのNLRI（ネットワーク層到達可能性情報）フィールドには、顧客のマルチキャストソースフィールドと顧客のマルチキャストグループフィールドが含まれているため、顧客の（S、G）または（*、G）状態をNLRIでエンコードできます。

It is also desirable for the BGP/MPLS IP VPN service to be able to support customers who are using MPLS multicast, either instead of or in addition to IP multicast. This document specifies the procedures and protocol extensions needed to support customers who use mLDP [mLDP] to create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs). While mLDP is not the only protocol that can be used to create and maintain multipoint LSPs, consideration of other MPLS multicast control protocols is outside the scope of this document.

また、BGP / MPLS IP VPNサービスが、IPマルチキャストの代わりに、またはIPマルチキャストに加えて、MPLSマルチキャストを使用している顧客をサポートできることが望ましい。このドキュメントでは、mLDP [mLDP]を使用してポイントツーマルチポイント（P2MP）またはマルチポイントツーマルチポイント（MP2MP）ラベルスイッチドパス（LSP）を作成および保守するお客様をサポートするために必要な手順とプロトコル拡張を指定します。 mLDPはマルチポイントLSPを作成および維持するために使用できる唯一のプロトコルではありませんが、他のMPLSマルチキャスト制御プロトコルの考慮はこのドキュメントの範囲外です。

When a customer is using mLDP in its VPN, the customer multicast states associated with mLDP are denoted by an mLDP FEC Element (Forwarding Equivalence Class Element; see [mLDP]) instead of by an (S,G) or (*,G). Thus, it is necessary to have a way to encode a customer's mLDP FEC Elements in the NLRI field of the BGP MCAST-VPN routes.

お客様がVPNでmLDPを使用している場合、mLDPに関連付けられているお客様のマルチキャストステートは、（S、G）または（*、G）ではなく、mLDP FEC要素（転送等価クラス要素。[mLDP]を参照）で示されます。。したがって、BGP MCAST-VPNルートのNLRIフィールドに顧客のmLDP FEC要素をエンコードする方法が必要です。

While [MVPN-BGP] does specify a way of encoding an mLDP FEC Element in the MCAST-VPN NLRI field, the encoding specified therein makes a variety of restrictive assumptions about the customer's use of mLDP. (These assumptions are described in Section 2 of this document.) The purpose of this document is to update RFC 6514 [MVPN-BGP] so that customers using mLDP in their VPNs can be supported even when those assumptions do not hold.

[MVPN-BGP]は、MCAST-VPN NLRIフィールドでmLDP FEC要素をエンコードする方法を指定しますが、そこで指定されたエンコードは、お客様によるmLDPの使用についてさまざまな制限を前提としています。（これらの前提条件は、このドキュメントのセクション2で説明されています。）このドキュメントの目的は、RFC 6514 [MVPN-BGP]を更新して、VPNでmLDPを使用している顧客がそれらの前提条件が満たされていない場合でもサポートできるようにすることです。

Some SPs use the MVPN procedures to provide "global table multicast" service (i.e., multicast service that is not in the context of a VPN) to customers. Methods for doing this are specified in [GTM] and in [SEAMLESS-MCAST]. The procedures described in this document can be used along with the procedures of [GTM] or [SEAMLESS-MCAST] to provide global table multicast service to customers that use MPLS multicast in a global table context.

一部のSPは、MVPN手順を使用して、「グローバルテーブルマルチキャスト」サービス（つまり、VPNのコンテキストにないマルチキャストサービス）を顧客に提供します。これを行う方法は、[GTM]と[SEAMLESS-MCAST]で指定されています。このドキュメントで説明されている手順は、[GTM]または[SEAMLESS-MCAST]の手順とともに使用して、グローバルテーブルコンテキストでMPLSマルチキャストを使用する顧客にグローバルテーブルマルチキャストサービスを提供できます。

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]で説明されているように解釈されます。

2. Why This Document Is Needed

2. このドキュメントが必要な理由

An mLDP FEC Element consists of a FEC Type, a Root Node, and an Opaque Value. mLDP uses several FEC Types and, in particular, uses the FEC Type to distinguish between P2MP LSPs and MP2MP LSPs.

mLDP FEC要素は、FECタイプ、ルートノード、および不透明値で構成されます。 mLDPはいくつかのFECタイプを使用し、特にFECタイプを使用してP2MP LSPとMP2MP LSPを区別します。

Section 11.1.2 of [MVPN-BGP] ("Originating Routes: mLDP as the C-Multicast Protocol") states:

[MVPN-BGP]のセクション11.1.2（「発信ルート：CマルチキャストプロトコルとしてのmLDP」）には次のように記載されています。

Whenever a PE [Provider Edge router] receives, from one of its CEs [Customer Edge routers], a P2MP Label Map <X, Y, L> over interface I, where X is the Root Node Address, Y is the Opaque Value, and L is an MPLS label ... the PE constructs a Source Tree Join C-multicast route whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y as the Multicast Group field.

PE [プロバイダーエッジルーター]がそのCE [カスタマーエッジルーター]の1つから、インターフェイスIを介してP2MPラベルマップ<X、Y、L>を受信するたびに、Xはルートノードアドレス、Yは不透明な値、 LはMPLSラベル... PEは、MCAST-VPN NLRIにマルチキャストソースフィールドとしてXが含まれ、マルチキャストグループフィールドとしてYが含まれるソースツリー結合Cマルチキャストルートを構築します。

In other words, the Root Node of the mLDP FEC Element appears in the Multicast Source field, and the Opaque Value of the mLDP FEC Element appears in the Multicast Group field.

つまり、mLDP FEC要素のルートノードがMulticast Sourceフィールドに表示され、mLDP FEC要素の不透明値がMulticast Groupフィールドに表示されます。

This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be used if all of the following conditions hold:

MCAST-VPN NLRIでmLDP FECをエンコードするこの方法は、次の条件がすべて満たされた場合にのみ使用できます。

1. A customer using mLDP is not also using PIM/IGMP.

1. mLDPを使用しているお客様は、PIM / IGMPも使用していません。

The encoding in [MVPN-BGP] does not specify any way in which one can determine, upon receiving a BGP Update, whether the Multicast Group field contains an IP address or whether it contains an mLDP FEC Element Opaque Value. Therefore, it might not uniquely identify a customer multicast state if the customer is using both PIM/IGMP and mLDP in its VPN.

[MVPN-BGP]のエンコーディングでは、BGPアップデートを受信したときに、マルチキャストグループフィールドにIPアドレスが含まれているか、またはmLDP FECエレメントの不透明値が含まれているかを判別する方法は指定されていません。したがって、顧客がVPNでPIM / IGMPとmLDPの両方を使用している場合、顧客のマルチキャスト状態を一意に識別できない可能性があります。

2. A customer using mLDP is using only the mLDP P2MP FEC Element and is not using the mLDP MP2MP FEC Element.

2. mLDPを使用しているお客様は、mLDP P2MP FECエレメントのみを使用しており、mLDP MP2MP FECエレメントを使用していません。

The encoding in [MVPN-BGP] does not specify any way to encode the type of the mLDP FEC Element; it just assumes it to be a P2MP FEC Element.

[MVPN-BGP]のエンコードでは、mLDP FEC要素のタイプをエンコードする方法は指定されていません。 P2MP FEC要素であると想定しているだけです。

3. A customer using mLDP is using only an mLDP Opaque Value type for which the Opaque Value is exactly 32 bits or 128 bits long.

3. mLDPを使用しているお客様は、不透明値がちょうど32ビットまたは128ビットの長さであるmLDP不透明値タイプのみを使用しています。

The use of Multicast Group fields that have other lengths is declared by [MVPN-BGP] to be "out of scope" of that document (see, e.g., Section 4.3 of that document).

他の長さを持つマルチキャストグループフィールドの使用は、[MVPN-BGP]によってそのドキュメントの「範囲外」であると宣言されています（たとえば、そのドキュメントのセクション4.3を参照）。

This condition holds if the customer uses only the mLDP "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). However, mLDP supports many other Opaque Value types whose length is not restricted to be 32 or 128 bits.

この条件は、お客様がmLDP "Generic LSP Identifier"不透明値タイプ（[mLDP]で定義）のみを使用する場合に当てはまります。ただし、mLDPは、長さが32ビットまたは128ビットに制限されていない他の多くの不透明値タイプをサポートします。

The purpose of this document is to update [MVPN-BGP] so that customers using mLDP can be supported, even when these conditions do not hold.

このドキュメントの目的は、[MVPN-BGP]を更新して、これらの条件が満たされていない場合でもmLDPを使用しているお客様をサポートできるようにすることです。

3. Encoding an mLDP FEC in the MCAST-VPN NLRI

3. MCAST-VPN NLRIでのmLDP FECのエンコード

When mLDP is used as the customer multicast control protocol, [MVPN-BGP] presupposes that an mLDP FEC Element will be encoded in the NLRI of the following three MCAST-VPN route types:

mLDPがカスタマーマルチキャスト制御プロトコルとして使用される場合、[MVPN-BGP]は、mLDP FEC要素が次の3つのMCAST-VPNルートタイプのNLRIでエンコードされることを前提としています。

- C-multicast Source Tree Join route,

- Cマルチキャストソースツリーの参加ルート、

- S-PMSI A-D route, and

- S-PMSI A-Dルート、および

- Leaf A-D route.

- リーフA-Dルート。

The other four MCAST-VPN route types defined in [MVPN-BGP] do not ever need to carry mLDP FEC Elements. The C-multicast Shared Tree Join route and the Source Active A-D route are used to communicate state about unidirectional shared trees; since mLDP does not have unidirectional shared trees, these routes are not used to signal mLDP states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D route do not identify specific customer multicast states and hence do not carry any information that is specific to the customer's multicast control protocol.

[MVPN-BGP]で定義されている他の4つのMCAST-VPNルートタイプは、mLDP FEC要素を伝送する必要がありません。 Cマルチキャスト共有ツリー参加ルートとソースアクティブA-Dルートは、単方向共有ツリーに関する状態を通信するために使用されます。 mLDPには単方向の共有ツリーがないため、これらのルートはmLDP状態の信号送信には使用されません。 Intra-AS I-PMSI A-DルートおよびInter-AS I-PMSI A-Dルートは、特定のカスタマーマルチキャストステートを識別しないため、カスタマーのマルチキャスト制御プロトコルに固有の情報を伝送しません。

This document defines three new route types:

このドキュメントでは、3つの新しいルートタイプを定義しています。

- C-Multicast Source Tree Join route for C-multicast mLDP,

- C-マルチキャストソースツリーC-マルチキャストmLDPのルートに参加、

- S-PMSI A-D route for C-multicast mLDP, and

- C-マルチキャストmLDPのS-PMSI A-Dルート、および

- Leaf A-D route for C-multicast mLDP.

- CマルチキャストmLDPのリーフA-Dルート。

The term "C-multicast mLDP" in the names of these route types is intended to indicate that the NLRI of these routes contains mLDP FEC Elements.

これらのルートタイプの名前に含まれる「C-マルチキャストmLDP」という用語は、これらのルートのNLRIにmLDP FEC要素が含まれていることを示すことを目的としています。

Each of these route types corresponds to a route type defined in [MVPN-BGP]. IANA has been requested to allocate codepoints for these three route types such that (a) the high-order two bits have the value 0x01, and (b) the low-order six bits have the same value as the codepoints for the corresponding route types from [MVPN-BGP].

これらの各ルートタイプは、[MVPN-BGP]で定義されたルートタイプに対応しています。 IANAは、（a）上位2ビットが値0x01であり、（b）下位6ビットが対応するルートタイプのコードポイントと同じ値になるように、これら3つのルートタイプにコードポイントを割り当てるように要求されました[MVPN-BGP]から。

In general, the procedures defined in other MVPN specifications for the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the Leaf A-D route also apply to the C-Multicast Source Tree Join route for C-multicast mLDP, the S-PMSI A-D route for C-multicast mLDP, and the Leaf A-D route for C-multicast mLDP, respectively. However, the NLRI of these three new route types is constructed differently than the NLRI of the corresponding routes from [MVPN-BGP]: the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields are omitted, and in their place is a single mLDP FEC Element, as defined in [mLDP]. (See Section 2.2 of [mLDP] for a diagram of the mLDP FEC Element.)

一般に、C-Multicast Source Tree Joinルート、S-PMSI ADルート、およびLeaf ADルートの他のMVPN仕様で定義されている手順は、C-Multicast mLDPのC-Multicast Source Tree Joinルートにも適用されます。 CマルチキャストmLDPのS-PMSI ADルート、およびCマルチキャストmLDPのリーフADルート。ただし、これら3つの新しいルートタイプのNLRIは、[MVPN-BGP]からの対応するルートのNLRIとは異なる方法で構築されます。マルチキャストソースの長さ、マルチキャストソース、マルチキャストグループの長さ、およびマルチキャストグループフィールドは省略され、代わりに[mLDP]で定義されている単一のmLDP FEC要素です。（mLDP FEC要素の図については、[mLDP]のセクション2.2を参照してください。）

As a result, the NLRI of an S-PMSI A-D route for C-multicast mLDP will consist of a Route Distinguisher, followed by the mLDP FEC, followed by the Originating Router's IP Address field.

その結果、CマルチキャストmLDPのS-PMSI A-DルートのNLRIは、ルート識別子、その後にmLDP FEC、その後に発信元ルーターのIPアドレスフィールドで構成されます。

The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP will consist of a Route Distinguisher, followed by the Source AS, followed by the mLDP FEC.

CマルチキャストmLDPのCマルチキャストソースツリー参加ルートのNLRIは、ルート識別子、ソースAS、続いてmLDP FECで構成されます。

In a Leaf A-D route for C-multicast mLDP that has been derived from an S-PMSI A-D route for C-multicast mLDP, the Route Key field remains the NLRI of the S-PMSI A-D route from which it was derived.

CマルチキャストmLDPのS-PMSI A-Dルートから派生したCマルチキャストmLDPのリーフA-Dルートでは、ルートキーフィールドは、それが派生したS-PMSI A-DルートのNLRIのままです。

In a Leaf A-D route for C-multicast mLDP that has not been derived from an S-PMSI A-D, the Route Key field is as specified in [SEAMLESS-MCAST], except that the Multicast Source Length, Multicast Source, Multicast Group Length, and Multicast Group fields are omitted, and in their place is a single mLDP FEC Element. Thus, the Route Key field consists of a Route Distinguisher, an mLDP FEC Element, and the IP address of the Ingress PE router.

S-PMSI ADから派生していないCマルチキャストmLDPのリーフADルートでは、ルートキーフィールドは[SEAMLESS-MCAST]で指定されているとおりですが、マルチキャストソース長、マルチキャストソース、マルチキャストグループ長、マルチキャストグループフィールドは省略され、代わりに単一のmLDP FEC要素が配置されています。したがって、ルートキーフィールドは、ルート識別子、mLDP FEC要素、および入力PEルータのIPアドレスで構成されます。

Please note that [BGP-ERR], Section 5.4 ("Typed NLRI") is applicable if the Route Type field of the NLRI of a received MCAST-VPN route contains an unrecognized value. Any such routes will be discarded.

[BGP-ERR]、セクション5.4（「Typed NLRI」）は、受信したMCAST-VPNルートのNLRIのRoute Typeフィールドに認識されない値が含まれている場合に適用されることに注意してください。そのようなルートは破棄されます。

An mLDP FEC Element contains an address family field whose value is from IANA's "Address Family Numbers" registry. The value of the address family field identifies the address family of the Root Node Address field of the FEC Element. When an mLDP FEC Element is encoded into the NLRI of a BGP Update whose SAFI is MCAST-VPN, the address family of the Root Node Address (as indicated in the FEC Element) MUST correspond to the address family that is identified in the Address Family Identifier (AFI) field of that BGP Update. These two address family fields are considered to correspond to each other under the following conditions:

mLDP FEC要素には、IANAの「アドレスファミリ番号」レジストリからの値であるアドレスファミリフィールドが含まれています。アドレスファミリフィールドの値は、FECエレメントのルートノードアドレスフィールドのアドレスファミリを識別します。 SADPがMCAST-VPNであるBGP更新のNLRIにmLDP FEC要素がエンコードされている場合、ルートノードアドレスのアドレスファミリ（FEC要素に示されている）は、アドレスファミリで識別されているアドレスファミリに対応している必要があります。そのBGPアップデートの識別子（AFI）フィールド。これら2つのアドレスファミリフィールドは、次の条件下で互いに対応すると見なされます。

- they contain identical values,

- それらは同一の値を含み、

- the BGP Update's AFI field identifies IPv4 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv4" as the address family of the Root Node, or

- BGPアップデートのAFIフィールドはIPv4をアドレスファミリとして識別し、mLDP FEC要素は「マルチトポロジIPv4」をルートノードのアドレスファミリとして識別します。

- the BGP Update's AFI field identifies IPv6 as the address family, and the mLDP FEC Element identifies "Multi-Topology IPv6" as the address family of the Root Node.

- BGPアップデートのAFIフィールドはIPv6をアドレスファミリとして識別し、mLDP FEC要素は「マルチトポロジIPv6」をルートノードのアドレスファミリとして識別します。

For more information about the "multi-topology" address families, see [LDP-MT] and [mLDP-MT].

「マルチトポロジ」アドレスファミリの詳細については、[LDP-MT]および[mLDP-MT]を参照してください。

4. Wildcards

4. ワイルドカード

[MVPN-WILDCARDS] specifies encodings and procedures that allow "wildcards" to be specified in the NLRI of S-PMSI A-D routes. A set of rules are given that specify when a customer multicast flow "matches" a given S-PMSI A-D route whose NLRI contains wildcards. However, the use of these wildcards is defined only for the case where the customer is using PIM as its multicast control protocol. The use of wildcards when the customer is using mLDP as its multicast control protocol is outside the scope of this document.

[MVPN-WILDCARDS]は、S-PMSI A-DルートのNLRIで「ワイルドカード」を指定できるようにするエンコーディングと手順を指定します。 NLRIにワイルドカードが含まれている特定のS-PMSI A-Dルートがカスタマーマルチキャストフローに「一致する」ときを指定する一連のルールが提供されます。ただし、これらのワイルドカードの使用は、顧客がマルチキャスト制御プロトコルとしてPIMを使用している場合にのみ定義されています。顧客がマルチキャスト制御プロトコルとしてmLDPを使用している場合のワイルドカードの使用は、このドキュメントの範囲外です。

5. IANA Considerations

5. IANAに関する考慮事項

[MVPN-BGP] does not create a registry for the allocation of new MCAST-VPN Route Type values. In retrospect, it seems that it should have done so. IANA has created a new registry called "BGP MCAST-VPN Route Types", which references this document and [MVPN-BGP]. The registry has been created under the top-level registry: "Border Gateway Protocol (BGP) Parameters" <http://www.iana.org/assignments/bgp-parameters>. The allocation policy is "Standards Action". Values may be assigned from one of several ranges:

[MVPN-BGP]は、新しいMCAST-VPNルートタイプ値を割り当てるためのレジストリを作成しません。振り返ってみると、そうすべきだったようです。 IANAは、「BGP MCAST-VPNルートタイプ」と呼ばれる新しいレジストリを作成しました。これは、このドキュメントと[MVPN-BGP]を参照しています。レジストリはトップレベルのレジストリ「Border Gateway Protocol（BGP）パラメータ」<http://www.iana.org/assignments/bgp-parameters>の下に作成されています。割り当てポリシーは「標準アクション」です。値は、いくつかの範囲の1つから割り当てることができます。

- Range 0x01-0x3f: Generic/PIM Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that PIM or IGMP is the C-multicast control protocol or when the NLRI format associated with the route type is independent of the C-multicast control protocol.

- 範囲0x01-0x3f：汎用/ PIM範囲。ルートタイプに関連付けられたNLRI形式がPIMまたはIGMPがCマルチキャスト制御プロトコルであると仮定した場合、またはルートタイプに関連付けられたNLRI形式がCマルチキャスト制御プロトコルから独立している場合、値はこの範囲から割り当てられます。

- Range 0x43-0x7f: mLDP Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that mLDP is the C-multicast control protocol.

- 範囲0x43-0x7f：mLDP範囲。ルートタイプに関連付けられたNLRI形式がmLDPがCマルチキャスト制御プロトコルであることを前提とする場合、値はこの範囲から割り当てられます。

- Range 0x80-0xff: This range is reserved; values should not be assigned from this range.

- 範囲0x80-0xff：この範囲は予約されています。この範囲から値を割り当てないでください。

In general, whenever an assignment is requested from this registry, two codepoints should be requested at the same time: one from the Generic/PIM range and one from the mLDP range. The two codepoints should have the same low-order 6 bits. If one of the two codepoints is not actually needed, it should be registered anyway and marked as "Reserved".

一般に、このレジストリから割り当てが要求されるときは常に、2つのコードポイントが同時に要求されます。1つはGeneric / PIM範囲から、もう1つはmLDP範囲からです。 2つのコードポイントの下位6ビットは同じである必要があります。 2つのコードポイントのいずれかが実際に必要ない場合は、いずれにしても登録し、「予約済み」としてマークする必要があります。

The "BGP MCAST-VPN Route Types" contains the following initial assignments:

「BGP MCAST-VPNルートタイプ」には、次の初期割り当てが含まれています。

   Value       Meaning                              Reference
   ---------   ----------------------------------   -------------------
   0x00        Reserved                             This RFC

0x01 Intra-AS I-PMSI A-D route This RFC, [RFC6514]

0x01 Intra-AS I-PMSI A-DルートこのRFC、[RFC6514]

0x02 Inter-AS I-PMSI A-D route This RFC, [RFC6514]

0x02 Inter-AS I-PMSI A-DルートこのRFC、[RFC6514]

0x03 S-PMSI A-D route This RFC, [RFC6514]

0x03 S-PMSI A-DルートこのRFC、[RFC6514]

0x04 Leaf A-D route This RFC, [RFC6514]

0x04リーフA-DルートこのRFC、[RFC6514]

0x05 Source Active A-D route This RFC, [RFC6514]

0x05ソースアクティブA-DルートこのRFC、[RFC6514]

0x06 Shared Tree Join route This RFC, [RFC6514]

0x06共有ツリー参加ルートこのRFC、[RFC6514]

0x07 Source Tree Join route This RFC, [RFC6514]

0x07 Source Tree Join route This RFC、[RFC6514]

0x08-0x3f Unassigned (Generic/PIM range) This RFC

0x08-0x3f Unassigned（Generic / PIM range）このRFC

0x40-0x42 Reserved This RFC

0x40-0x42予約済みRFC

0x43 S-PMSI A-D route for C-multicast mLDP This RFC

CマルチキャストmLDPの0x43 S-PMSI A-DルートこのRFC

0x44 Leaf A-D route for C-multicast mLDP This RFC

CマルチキャストmLDPの0x44リーフA-DルートこのRFC

0x45-0x46 Reserved This RFC

0x45-0x46予約済みRFC

0x47 Source Tree Join route for C-multicast mLDP This RFC

CマルチキャストmLDPの0x47ソースツリー参加ルートこのRFC

0x48-0x7f Unassigned (mLDP range) This RFC

0x48-0x7f未割り当て（mLDP範囲）このRFC

0x80-0xff Reserved This RFC

0x80-0xff予約済みRFC

6. Security Considerations

6. セキュリティに関する考慮事項

This document specifies a method of encoding an mLDP FEC Element in the NLRI of some of the BGP Update messages that are specified in [MVPN-BGP]. The security considerations of [mLDP] and of [MVPN-BGP] are applicable, but no new security considerations are raised.

このドキュメントでは、[MVPN-BGP]で指定されている一部のBGPアップデートメッセージのNLRIでmLDP FEC要素をエンコードする方法を指定します。 [mLDP]および[MVPN-BGP]のセキュリティに関する考慮事項は適用されますが、新しいセキュリティに関する考慮事項はありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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, <http://www.rfc-editor.org/info/rfc6388>.

[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月、<http://www.rfc-editor.org/info/rfc6388>。

[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[MVPN-BGP] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS / BGP IP VPNにおけるマルチキャスト用のBGPエンコーディングおよび手順」、RFC 6514、2012年2月、<http：/ /www.rfc-editor.org/info/rfc6514>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

7.2. Informative References

7.2. 参考引用

[BGP-ERR] Chen, E., Ed, Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, draft-ietf-idr-error-handling-18, December 2014.

[BGP-ERR] Chen、E.、Ed、Scudder、J.、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂」、Work in Progress、draft-ietf-idr-error-handling -18、2014年12月。

[GTM] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-mvpn-global-table-mcast-00, November 2014.

[GTM] Zhang、J.、Giuliano、L.、Rosen、E.、Ed。、Subramanian、K.、Pacella、D。、およびJ. Schiller、「BGP-MVPNプロシージャを使用したグローバルテーブルマルチキャスト」、進行中の作業、draft-ietf-bess-mvpn-global-table-mcast-00、2014年11月。

[IGMP] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.

[IGMP] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月、<http：// www .rfc-editor.org / info / rfc3376>。

[LDP-MT] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, July 2014, <http://www.rfc-editor.org/info/rfc7307>.

[LDP-MT] Zhao、Q.、Raza、K.、Zhou、C.、Fang、L.、Li、L。、およびD. King、「LDP Extensions for Multi-Topology」、RFC 7307、2014年7月、 <http://www.rfc-editor.org/info/rfc7307>。

[mLDP-MT] Wijnands, IJ. and K. Raza, "mLDP Extensions for Multi Topology Routing", Work in Progress, draft-iwijnand-mpls-mldp-multi-topology-03, June 2013.

[mLDP-MT] Wijnands、IJ。 K. Raza、「マルチトポロジルーティングのmLDP拡張機能」、作業中、draft-iwijnand-mpls-mldp-multi-topology-03、2013年6月。

[MVPN-WILDCARDS] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.

[MVPN-WILDCARDS] Rosen、E.、Ed。、Rekhter、Y.、Ed。、Hendrickx、W.、and R. Qiu、 "Wildcards in Multicast VPN Auto-Discovery Routes"、RFC 6625、May 2012、<http ：//www.rfc-editor.org/info/rfc6625>。

[PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.

[PIM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月、< http://www.rfc-editor.org/info/rfc4601>。

[SEAMLESS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Segmented LSPs", Work in Progress, draft-ietf-mpls-seamless-mcast-14, June 2014.

[シームレス-MCAST] Rekhter、Y.、Aggarwal、R.、Morin、T.、Grosclaude、I.、Leymann、N。、およびS. Saad、「Inter-Area P2MP Segmented LSPs」、Work in Progress、draft- ietf-mpls-seamless-mcast-14、2014年6月。

Acknowledgments

謝辞

The authors wish to thank Pradosh Mohapatra and Saquib Najam for their ideas and comments. We also thank Yakov Rekhter and Martin Vigoureux for their comments.

著者は、彼らのアイデアとコメントを提供してくれたPradosh MohapatraとSaquib Najamに感謝したいと思います。 Yakov Rekhter氏とMartin Vigoureux氏のコメントにも感謝します。

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 E-mail：ice@cisco.com

Eric C. Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States EMail: erosen@juniper.net

Eric C. Rosen Juniper Networks、Inc. 10 Technology Park Drive Westford、MA 01886米国Eメール：erosen@juniper.net

Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany EMail: Uwe.Joorde@telekom.de

Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany Eメール：Uwe.Joorde@telekom.de