[要約] RFC 6514は、MPLS/BGP IP VPNsにおけるマルチキャストのためのBGPエンコーディングと手順について説明しています。このRFCの目的は、マルチキャストトラフィックを効率的にルーティングするためのBGPプロトコルの拡張を提供することです。

Internet Engineering Task Force (IETF)                       R. Aggarwal
Request for Comments: 6514                              Juniper Networks
Category: Standards Track                                       E. Rosen
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                                T. Morin
                                                 France Telecom - Orange
                                                              Y. Rekhter
                                                        Juniper Networks
                                                           February 2012
        

BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs

MPLS/BGP IP VPNSのマルチキャストのBGPエンコーディングと手順

Abstract

概要

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513.

このドキュメントでは、RFC 6513で指定されているように、MPLS/BGP IP VPNSでマルチキャストが必要とする情報要素を交換するための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/rfc6514.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc6514で取得できます。

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.

このドキュメントは、BCP 78およびIETFドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

目次

   1. Introduction ....................................................4
   2. Specification of Requirements ...................................4
   3. Terminology .....................................................4
   4. MCAST-VPN NLRI ..................................................5
     4.1. Intra-AS I-PMSI A-D Route ...................................6
     4.2. Inter-AS I-PMSI A-D Route ...................................7
     4.3. S-PMSI A-D Route ............................................7
     4.4. Leaf A-D Route ..............................................8
     4.5. Source Active A-D Route .....................................9
     4.6. C-Multicast Route ..........................................10
   5. PMSI Tunnel Attribute ..........................................10
   6. Source AS Extended Community ...................................13
   7. VRF Route Import Extended Community ............................14
   8. PE Distinguisher Labels Attribute ..............................15
   9. MVPN Auto-Discovery/Binding ....................................16
     9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations ..........16
       9.1.1. Originating Intra-AS I-PMSI A-D Routes .................16
       9.1.2. Receiving Intra-AS I-PMSI A-D Routes ...................19
     9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations ..........20
       9.2.1. Originating Inter-AS I-PMSI A-D Routes .................22
       9.2.2. When Not to Originate Inter-AS I-PMSI A-D Routes .......23
       9.2.3. Propagating Inter-AS I-PMSI A-D Routes .................23
         9.2.3.1. Propagating Inter-AS I-PMSI A-D Routes - Overview ..23
         9.2.3.2. Inter-AS I-PMSI A-D Route Received via EBGP ........24
           9.2.3.2.1. Originating Leaf A-D Route into EBGP ...........25
         9.2.3.3. Leaf A-D Route Received via EBGP ...................26
         9.2.3.4. Inter-AS I-PMSI A-D Route Received via IBGP ........27
           9.2.3.4.1. Originating Leaf A-D Route into IBGP ...........28
         9.2.3.5. Leaf A-D Route Received via IBGP ...................29
         9.2.3.6. Optimizing Bandwidth by IP Filtering on ASBRs ......30
   10. Non-Congruent Unicast and Multicast Connectivity ..............30
   11. Exchange of C-Multicast Routing Information among PEs .........32
     11.1. Originating C-Multicast Routes by a PE ....................32
       11.1.1. Originating Routes: PIM as the C-Multicast Protocol ...32
         11.1.1.1. Originating Source Tree Join C-Multicast Route ....33
         11.1.1.2. Originating Shared Tree Join C-Multicast Route ....33
       11.1.2. Originating Routes: mLDP as the C-Multicast Protocol ..34
       11.1.3. Constructing the Rest of the C-Multicast Route ........34
       11.1.4. Unicast Route Changes .................................35
     11.2. Propagating C-Multicast Routes by an ASBR .................36
     11.3. Receiving C-Multicast Routes by a PE ......................37
       11.3.1. Receiving Routes: PIM as the C-Multicast Protocol .....37
         11.3.1.1. Receiving Source Tree Join C-Multicast Route ......38
         11.3.1.2. Receiving Shared Tree Join C-Multicast Route ......38
       11.3.2. Receiving Routes: mLDP as the C-Multicast Protocol ....39
     11.4. C-Multicast Routes Aggregation ............................39
        
   12. Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels ..........40
     12.1. Originating S-PMSI A-D Routes .............................40
     12.2. Handling S-PMSI A-D Routes by ASBRs .......................43
       12.2.1. Merging S-PMSI into an I-PMSI .........................43
     12.3. Receiving S-PMSI A-D Routes by PEs ........................44
   13. Switching from Shared a C-Tree to a Source C-Tree .............45
     13.1. Source within a Site - Source Active Advertisement ........46
     13.2. Receiving Source Active A-D Route .........................47
       13.2.1. Pruning Sources off the Shared Tree ...................48
   14. Supporting PIM-SM without Inter-Site Shared C-Trees ...........49
     14.1. Discovering Active Multicast Sources ......................50
     14.2. Receiver(s) within a Site .................................51
     14.3. Receiving C-Multicast Routes by a PE ......................52
   15. Carrier's Carrier .............................................52
   16. Scalability Considerations ....................................52
     16.1. Dampening C-Multicast Routes ..............................54
       16.1.1. Dampening Withdrawals of C-Multicast Routes ...........54
       16.1.2. Dampening Source/Shared Tree Join C-Multicast Routes ..55
     16.2. Dampening Withdrawals of Leaf A-D Routes ..................55
   17. Security Considerations .......................................55
   18. IANA Considerations ...........................................56
   19. Acknowledgements ..............................................57
   20. References ....................................................57
     20.1. Normative References ......................................57
     20.2. Informative References ....................................58
        
1. Introduction
1. はじめに

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. This document assumes a thorough familiarity with the procedures, concepts, and terms described in [MVPN].

このドキュメントでは、[MVPN]で指定されているように、MPLS/BGP IP VPNSでマルチキャストが必要とする情報要素を交換するためのBGPエンコーディングと手順について説明します。このドキュメントでは、[MVPN]で説明されている手順、概念、用語に徹底的に精通しています。

This document defines a new Network Layer Reachability Information (NLRI), MCAST-VPN NLRI. The MCAST-VPN NLRI is used for MVPN auto-discovery, advertising MVPN to Inclusive P-Multicast Service Interface (I-PMSI) tunnel binding, advertising (C-S,C-G) to Selective PMSI (S-PMSI) tunnel binding, VPN customer multicast routing information exchange among Provider Edge routers (PEs), choosing a single forwarder PE, and for procedures in support of co-locating a Customer Rendezvous Point (C-RP) on a PE.

このドキュメントでは、新しいネットワークレイヤーReachability情報(NLRI)、MCAST-VPN NLRIを定義しています。MCAST-VPN NLRIは、MVPNオートディスコービリに使用され、MVPNを包括的P-Multicast Serviceインターフェイス(I-PMSI)トンネルバインディング、広告(C-S、C-G)に選択的PMSI(S-PMSI)トンネルバインディング、VPNカスタマーマルチカスタムプロバイダーエッジルーター(PES)間のルーティング情報交換、単一のフォワーダーPEの選択、およびPEでの顧客ランデブーポイント(C-RP)の共同配置をサポートする手順のために。

This document specifies two new BGP attributes: the P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute and the PE Distinguisher Label attribute.

このドキュメントは、2つの新しいBGP属性を指定します。P-Multicast Service Interface Tunnel(PMSI Tunnel)属性とPE distimuisherラベル属性です。

This document also defines two new BGP Extended Communities: the Source Autonomous System (AS) Extended Community and the VPN Routing and Forwarding (VRF) Route Import Extended Community.

このドキュメントでは、2つの新しいBGP拡張コミュニティも定義します。ソース自律システム(AS)拡張コミュニティとVPNルーティングおよび転送(VRF)ルートインポートエクステンションコミュニティも定義されています。

2. Specification of Requirements
2. 要件の仕様

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]に記載されているように解釈される。

3. Terminology
3. 用語

In the context of this document, we will refer to the MVPN auto-discovery/binding information carried in BGP as "auto-discovery routes" ("A-D routes"). For a given MVPN, there are the following types of A-D routes:

このドキュメントのコンテキストでは、BGPで運ばれたMVPN自動配信/バインディング情報を「自動配置ルート」(「A-Dルート」)と呼びます。特定のMVPNについては、次のタイプのA-Dルートがあります。

+ Intra-AS I-PMSI A-D route;

+ INTRA-AS I-PMSI A-Dルート。

+ Inter-AS I-PMSI A-D route;

+ INTER-AS I-PMSI A-Dルート。

+ S-PMSI A-D route;

+ S-PMSI A-Dルート。

+ Leaf A-D route;

+ リーフA-Dルート;

+ Source Active A-D route.

+ ソースアクティブA-Dルート。

In the context of this document, we will refer to the MVPN customers' multicast routing information carried in BGP as "C-multicast routes". For a given MVPN, there are the following types of C-multicast routes:

このドキュメントのコンテキストでは、BGPで運ばれるMVPN顧客のマルチキャストルーティング情報を「C-Multicastルート」と呼びます。特定のMVPNについては、次のタイプのCマルチキャストルートがあります。

+ Shared Tree Join route;

+ 共有ツリー結合ルート。

+ Source Tree Join route;

+ ソースツリー結合ルート。

For each MVPN present on a PE, the PE maintains a Tree Information Base (MVPN-TIB). This is the same as TIB defined in [RFC4601], except that instead of a single TIB, a PE maintains multiple MVPN-TIBs: one per each MVPN.

PEに存在する各MVPNについて、PEはツリー情報ベース(MVPN-TIB)を維持します。これは、[RFC4601]で定義されているTIBと同じですが、単一のTIBの代わりに、PEは複数のMVPN-TIBSを維持していることを除きます。

Throughout this document, we will use the term "VPN-IP route" to mean a route that is either in the VPN-IPv4 address family [RFC4364] or in the VPN-IPv6 address family [RFC4659].

このドキュメント全体で、「VPN-IPルート」という用語を使用して、VPN-IPV4アドレスファミリー[RFC4364]またはVPN-IPV6アドレスファミリー[RFC4659]のいずれかのルートを意味します。

4. MCAST-VPN NLRI
4. mcast-vpn nlri

This document defines a new BGP NLRI, called the MCAST-VPN NLRI.

このドキュメントでは、MCAST-VPN NLRIと呼ばれる新しいBGP NLRIを定義しています。

The following is the format of the MCAST-VPN NLRI:

以下は、mcast-vpn nlriの形式です。

      +-----------------------------------+
      |    Route Type (1 octet)           |
      +-----------------------------------+
      |     Length (1 octet)              |
      +-----------------------------------+
      | Route Type specific (variable)    |
      +-----------------------------------+
        

The Route Type field defines the encoding of the rest of MCAST-VPN NLRI (Route Type specific MCAST-VPN NLRI).

ルートタイプフィールドは、MCAST-VPN NLRIの残りの部分(ルートタイプ固有のMCAST-VPN NLRI)のエンコードを定義します。

The Length field indicates the length in octets of the Route Type specific field of the MCAST-VPN NLRI.

長さフィールドは、MCAST-VPN NLRIのルートタイプ固有フィールドのオクテットの長さを示します。

This document defines the following Route Types for A-D routes:

このドキュメントでは、A-Dルートの次のルートタイプを定義します。

      + 1 - Intra-AS I-PMSI A-D route;
      + 2 - Inter-AS I-PMSI A-D route;
      + 3 - S-PMSI A-D route;
      + 4 - Leaf A-D route;
      + 5 - Source Active A-D route.
        

This document defines the following Route Types for C-multicast routes:

このドキュメントでは、C-Multicastルートの次のルートタイプを定義します。

      + 6 - Shared Tree Join route;
      + 7 - Source Tree Join route;
        

The MCAST-VPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of MCAST-VPN. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPN NLRI (encoded as specified above). The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the MCAST-VPN NLRI determines whether the multicast source and multicast group addresses carried in the S-PMSI A-D routes, Source Active A-D routes, and C-multicast routes are IPv4 or IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates IPv6 addresses).

MCAST-VPN NLRIは、BGPマルチプロトコル拡張[RFC4760]を使用してBGP [RFC4271]で運ばれます。MP_REACH_NLRI/MP_UNREACH_NLRI属性のNLRIフィールドには、MCAST-VPN NLRI(上記のようにエンコード)が含まれています。MP_REACH_NLRI/MP_UNREACH_NLRI属性のMP_REACH_NLRI/MP_UNREACH_NLRI属性のAFIフィールドの値は、S-PMSI A-Dルートで運ばれるマルチキャストソースとマルチキャストグループアドレスが、アクティブA-Dルートをソース、Cマルチキャストルートであるかどうかを決定します。IPv6アドレス(AFI 1はIPv4アドレスを示し、AFI 2はIPv6アドレスを示します)。

In order for two BGP speakers to exchange labeled MCAST-VPN NLRIs, they must use a BGP Capabilities Advertisement to ensure that they both are capable of properly processing such an NLRI. This is done as specified in [RFC4760], by using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and an SAFI of MCAST-VPN.

2人のBGPスピーカーがラベルのmcast-vpn nlrisを交換するためには、BGP機能広告を使用して、どちらもそのようなNLRIを適切に処理できるようにする必要があります。これは、[RFC4760]で指定されているように、1または2のAFIとMCAST-VPNのSAFIを使用して機能コード1(MultiProtocol BGP)を使用して行われます。

The following describes the format of the Route Type specific MCAST-VPN NLRI for various Route Types defined in this document.

以下は、このドキュメントで定義されているさまざまなルートタイプのルートタイプ固有のMCAST-VPN NLRIの形式について説明します。

4.1. Intra-AS I-PMSI A-D Route
4.1. INTRA-AS I-PMSI A-Dルート

An Intra-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI consists of the following:

INTRA-AS I-PMSI A-Dルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      RD   (8 octets)              |
      +-----------------------------------+
      |   Originating Router's IP Addr    |
      +-----------------------------------+
        

The Route Distinguisher (RD) is encoded as described in [RFC4364].

Route Distinguisher(RD)は、[RFC4364]に記載されているようにエンコードされています。

Usage of Intra-AS I-PMSI A-D routes is described in Section 9.2.

INTRA-AS I-PMSI A-Dルートの使用については、セクション9.2に記載されています。

4.2. Inter-AS I-PMSI A-D Route
4.2. INTER-AS I-PMSI A-Dルート

An Inter-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI consists of the following:

INTER-AS I-PMSI A-Dルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      RD   (8 octets)              |
      +-----------------------------------+
      |      Source AS (4 octets)         |
      +-----------------------------------+
        

The RD is encoded as described in [RFC4364].

RDは[RFC4364]で説明されているようにエンコードされます。

The Source AS contains an Autonomous System Number (ASN).

ASのソースには、自律システム番号(ASN)が含まれています。

Two-octet ASNs are encoded in the two low-order octets of the Source AS field, with the two high-order octets set to zero.

2オクテットのASNは、ソースの2つの低次のオクテットでフィールドとしてエンコードされ、2つの高次オクテットがゼロに設定されています。

Usage of Inter-AS I-PMSI A-D routes is described in Section 9.1.

INTER-AS I-PMSI A-Dルートの使用については、セクション9.1で説明しています。

4.3. S-PMSI A-D Route
4.3. S-PMSI A-Dルート

An S-PMSI A-D Route Type specific MCAST-VPN NLRI consists of the following:

S-PMSI A-Dルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      RD   (8 octets)              |
      +-----------------------------------+
      | Multicast Source Length (1 octet) |
      +-----------------------------------+
      |  Multicast Source (variable)      |
      +-----------------------------------+
      |  Multicast Group Length (1 octet) |
      +-----------------------------------+
      |  Multicast Group   (variable)     |
      +-----------------------------------+
      |   Originating Router's IP Addr    |
      +-----------------------------------+
        

The RD is encoded as described in [RFC4364].

RDは[RFC4364]で説明されているようにエンコードされます。

The Multicast Source field contains the C-S address. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128.

マルチキャストソースフィールドには、C-Sアドレスが含まれています。マルチキャストソースフィールドにIPv4アドレスが含まれている場合、マルチキャストソースの長さフィールドの値は32です。マルチキャストソースフィールドにIPv6アドレスが含まれている場合、マルチキャストソース長フィールドの値は128です。

The Multicast Group field contains the C-G address or C-LDP (Label Distribution Protocol) MP Opaque Value Element (use of C-LDP MP Opaque Value Element is described in the Section 11.3.2. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128.

マルチキャストグループフィールドには、C-GアドレスまたはC-LDP(ラベル分布プロトコル)MP不透明値要素が含まれています(C-LDP MP不透明値要素の使用は、セクション11.3.2で説明されています。マルチキャストグループフィールドにIPv4アドレスが含まれている場合、次に、マルチキャストグループ長フィールドの値は32です。マルチキャストグループフィールドにIPv6アドレスが含まれている場合、マルチキャストグループ長フィールドの値は128です。

Usage of other values of the Multicast Source Length and Multicast Group Length fields is outside the scope of this document.

マルチキャストソースの長さとマルチキャストグループの長さフィールドの他の値の使用は、このドキュメントの範囲外です。

Usage of S-PMSI A-D routes is described in Section 12.

S-PMSI A-Dルートの使用については、セクション12で説明されています。

4.4. Leaf A-D Route
4.4. リーフA-Dルート

A Leaf A-D Route Type specific MCAST-VPN NLRI consists of the following:

リーフA-Dルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      Route Key (variable)         |
      +-----------------------------------+
      |   Originating Router's IP Addr    |
      +-----------------------------------+
        

Leaf A-D routes may be originated as a result of processing a received Inter-AS I-PMSI A-D route or S-PMSI A-D route. A Leaf A-D route is originated in these situations only if the received route has a PMSI Tunnel attribute whose "Leaf Information Required" bit is set to 1.

リーフA-Dルートは、受信したI-PMSI A-DルートまたはS-PMSI A-Dルートを処理した結果として発生する場合があります。葉のA-Dルートは、受信ルートに「リーフ情報が必要」ビットが1に設定されているPMSIトンネル属性がある場合にのみ、これらの状況で発生します。

If a Leaf A-D route is originated as a result of processing one of the received routes specified in the previous paragraph, the Route Key of the Leaf A-D route is set to the NLRI of the received route.

前の段落で指定された受信ルートの1つを処理した結果としてリーフA-Dルートが発生する場合、リーフA-Dルートのルートキーが受信ルートのNLRIに設定されます。

Details of the use of the Leaf A-D route may be found in Sections 9.2.3.2.1, 9.2.3.3, 9.2.3.4.1, 9.2.3.5, and 12.3.

リーフA-Dルートの使用の詳細は、セクション9.2.3.2.1、9.2.3.3、9.2.3.4.1、9.2.3.5、および12.3に記載されています。

4.5. Source Active A-D Route
4.5. ソースアクティブA-Dルート

A Source Active A-D Route Type specific MCAST-VPN NLRI consists of the following:

ソースアクティブA-Dルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      RD   (8 octets)              |
      +-----------------------------------+
      | Multicast Source Length (1 octet) |
      +-----------------------------------+
      |   Multicast Source (variable)     |
      +-----------------------------------+
      |  Multicast Group Length (1 octet) |
      +-----------------------------------+
      |  Multicast Group (variable)       |
      +-----------------------------------+
        

The RD is encoded as described in [RFC4364].

RDは[RFC4364]で説明されているようにエンコードされます。

The Multicast Source field contains the C-S address. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128.

マルチキャストソースフィールドには、C-Sアドレスが含まれています。マルチキャストソースフィールドにIPv4アドレスが含まれている場合、マルチキャストソースの長さフィールドの値は32です。マルチキャストソースフィールドにIPv6アドレスが含まれている場合、マルチキャストソース長フィールドの値は128です。

Use of the Source Active A-D routes with the Multicast Source Length field of 0 is outside the scope of this document.

0のマルチキャストソース長フィールドを使用したソースアクティブA-Dルートの使用は、このドキュメントの範囲外です。

The Multicast Group field contains the C-G address. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128.

マルチキャストグループフィールドには、C-Gアドレスが含まれています。マルチキャストグループフィールドにIPv4アドレスが含まれている場合、マルチキャストグループ長フィールドの値は32です。マルチキャストグループフィールドにIPv6アドレスが含まれている場合、マルチキャストグループ長フィールドの値は128です。

Source Active A-D routes with a Multicast group belonging to the Source Specific Multicast (SSM) range (as defined in [RFC4607], and potentially extended locally on a router) MUST NOT be advertised by a router and MUST be discarded if received.

ソース固有のマルチキャスト(SSM)範囲に属するマルチキャストグループを持つソースアクティブA-Dルート([RFC4607]で定義されており、ルーターでローカルに拡張される可能性がある)をルーターによって宣伝してはならず、受け取った場合は廃棄する必要があります。

Usage of Source Active A-D routes is described in Sections 13 and 14.

ソースアクティブA-Dルートの使用については、セクション13および14で説明します。

4.6. C-Multicast Route
4.6. C-Multicastルート

A Shared Tree Join route and a Source Tree Join Route Type specific MCAST-VPN NLRI consists of the following:

共有ツリー結合ルートとソースツリー結合ルートタイプ固有のMCAST-VPN NLRIは次のもので構成されています。

      +-----------------------------------+
      |      RD   (8 octets)              |
      +-----------------------------------+
      |    Source AS (4 octets)           |
      +-----------------------------------+
      | Multicast Source Length (1 octet) |
      +-----------------------------------+
      |   Multicast Source (variable)     |
      +-----------------------------------+
      |  Multicast Group Length (1 octet) |
      +-----------------------------------+
      |  Multicast Group   (variable)     |
      +-----------------------------------+
        

The RD is encoded as described in [RFC4364].

RDは[RFC4364]で説明されているようにエンコードされます。

The Source AS contains an ASN. Two-octet ASNs are encoded in the low-order two octets of the Source AS field.

ASのソースにはASNが含まれています。2オクテットのASNは、ソースの低次の2オクテットでフィールドとしてエンコードされます。

For a Shared Tree Join route, the Multicast Source field contains the C-RP address; for a Source Tree Join route, the Multicast Source field contains the C-S address. If the Multicast Source field contains an IPv4 address, then the value of the Multicast Source Length field is 32. If the Multicast Source field contains an IPv6 address, then the value of the Multicast Source Length field is 128.

共有ツリー結合ルートの場合、マルチキャストソースフィールドにはC-RPアドレスが含まれています。ソースツリー結合ルートの場合、マルチキャストソースフィールドにはC-Sアドレスが含まれています。マルチキャストソースフィールドにIPv4アドレスが含まれている場合、マルチキャストソースの長さフィールドの値は32です。マルチキャストソースフィールドにIPv6アドレスが含まれている場合、マルチキャストソース長フィールドの値は128です。

The Multicast Group field contains the C-G address or C-MP Opaque Value Element. If the Multicast Group field contains an IPv4 address, then the value of the Multicast Group Length field is 32. If the Multicast Group field contains an IPv6 address, then the value of the Multicast Group Length field is 128.

マルチキャストグループフィールドには、C-GアドレスまたはC-MP不透明な値要素が含まれています。マルチキャストグループフィールドにIPv4アドレスが含まれている場合、マルチキャストグループ長フィールドの値は32です。マルチキャストグループフィールドにIPv6アドレスが含まれている場合、マルチキャストグループ長フィールドの値は128です。

Usage of C-multicast routes is described in Section 11.

C-Multicastルートの使用については、セクション11で説明されています。

5. PMSI Tunnel Attribute
5. PMSIトンネル属性

This document defines and uses a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". This is an optional transitive BGP attribute. The format of this attribute is defined as follows:

このドキュメントは、「P-Multicast Service Interface Tunnel(PMSI Tunnel)属性」と呼ばれる新しいBGP属性を定義および使用します。これは、オプションの推移的なBGP属性です。この属性の形式は、次のように定義されています。

      +---------------------------------+
      |  Flags (1 octet)                |
      +---------------------------------+
      |  Tunnel Type (1 octets)         |
      +---------------------------------+
      |  MPLS Label (3 octets)          |
      +---------------------------------+
      |  Tunnel Identifier (variable)   |
      +---------------------------------+
        

The Flags field has the following format:

Flagsフィールドには次の形式があります。

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |  reserved   |L|
      +-+-+-+-+-+-+-+-+
        

This document defines the following flags:

このドキュメントでは、次のフラグを定義しています。

+ Leaf Information Required (L)

+ 必要な葉の情報(L)

The Tunnel Type identifies the type of the tunneling technology used to establish the PMSI tunnel. The type determines the syntax and semantics of the Tunnel Identifier field. This document defines the following Tunnel Types:

トンネルタイプは、PMSIトンネルの確立に使用されるトンネル技術のタイプを識別します。このタイプは、トンネル識別子フィールドの構文とセマンティクスを決定します。このドキュメントでは、次のトンネルタイプを定義します。

      + 0 - No tunnel information present
      + 1 - RSVP-TE P2MP LSP
      + 2 - mLDP P2MP LSP
      + 3 - PIM-SSM Tree
      + 4 - PIM-SM Tree
      + 5 - BIDIR-PIM Tree
      + 6 - Ingress Replication
      + 7 - mLDP MP2MP LSP
        

If the MPLS Label field is non-zero, then it contains an MPLS label encoded as 3 octets, where the high-order 20 bits contain the label value. Absence of an MPLS Label is indicated by setting the MPLS Label field to zero.

MPLSラベルフィールドがゼロ以外の場合、3オクテットとしてエンコードされたMPLSラベルが含まれ、高次の20ビットにラベル値が含まれています。MPLSラベルの欠如は、MPLSラベルフィールドをゼロに設定することにより示されます。

When the Tunnel Type is set to "No tunnel information present", the PMSI Tunnel attribute carries no tunnel information (no Tunnel Identifier). This type is to be used only in the following case: to enable explicit tracking for a particular customer multicast flow (by setting the Leaf Information Required flag to 1), but without binding this flow to a particular provider tunnel (by omitting any tunnel information).

トンネルの種類が「トンネル情報が存在しない」に設定されている場合、PMSIトンネル属性はトンネル情報(トンネル識別子なし)を持ちません。このタイプは、次のケースでのみ使用されます。特定の顧客マルチキャストフローの明示的な追跡を可能にするため(葉の情報が必要なフラグを1に設定することにより)、このフローを特定のプロバイダートンネルに結合することなく(トンネル情報を省略します)。

When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE) Point-to-Multipoint (P2MP) Label Switched Path (LSP), the Tunnel Identifier is <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID> as carried in the RSVP-TE P2MP LSP SESSION Object [RFC4875].

トンネルタイプがRSVPに設定されている場合、トラフィックエンジニアリング(RSVP-TE)ポイントツーマルチポイント(P2MP)ラベルスイッチパス(LSP)は、トンネル識別子が<拡張トンネルID、予約済み、トンネルID、P2MP ID>RSVP-TE P2MP LSPセッションオブジェクト[RFC4875]。

When the Tunnel Type is set to multipoint Label Distribution Protocol (mLDP) P2MP LSP, the Tunnel Identifier is a P2MP Forwarding Equivalence Class (FEC) Element [mLDP].

トンネルタイプがマルチポイントラベル分布プロトコル(MLDP)P2MP LSPに設定されている場合、トンネル識別子はP2MP転送等価クラス(FEC)要素[MLDP]になります。

When the Tunnel Type is set to Protocol Independent Multicast - Sparse Mode (PIM-SM) tree, the Tunnel Identifier is <Sender Address, P-Multicast Group>. The node that originated the attribute MUST use the address carried in the Sender Address as the source IP address for the IP/GRE (Generic Routing Encapsulation) encapsulation of the MVPN data.

トンネルタイプがプロトコルに依存しないマルチキャスト - スパースモード(PIM-SM)ツリーに設定されている場合、トンネル識別子は<Senderアドレス、P-Multicast Group>です。属性を発信したノードは、MVPNデータのIP/GRE(汎用ルーティングカプセル化)カプセル化のソースIPアドレスとして送信者アドレスに掲載されたアドレスを使用する必要があります。

When the Tunnel Type is set to PIM-SSM tree, the Tunnel Identifier is <P-Root Node Address, P-Multicast Group>. The node that originates the attribute MUST use the address carried in the P-Root Node Address as the source IP address for the IP/GRE encapsulation of the MVPN data. The P-Multicast Group in the Tunnel Identifier of the Tunnel attribute MUST NOT be expected to be the same group for all Intra-AS A-D routes for the same MVPN. According to [RFC4607], the group address can be locally allocated by the originating PE without any consideration for the group address used by other PE on the same MVPN.

トンネルタイプがPIM-SSMツリーに設定されている場合、トンネル識別子は<P-Rootノードアドレス、P-Multicast Group>です。属性を発信するノードは、MVPNデータのIP/GREカプセル化のソースIPアドレスとしてP-ROOTノードアドレスにあるアドレスを使用する必要があります。トンネル属性のトンネル識別子のP-Multicastグループは、同じMVPNのすべてのAS A-Dルートのすべてのグループであると同じグループになることは期待されてはなりません。[RFC4607]によれば、グループアドレスは、同じMVPNで他のPEが使用するグループアドレスを考慮せずに、発信元PEによってローカルに割り当てることができます。

When the Tunnel Type is set to BIDIR-PIM tree, the Tunnel Identifier is <Sender Address, P-Multicast Group>. The node that originated the attribute MUST use the address carried in the Sender Address as the source IP address for the IP/GRE encapsulation of the MVPN data.

トンネルタイプがBidir-PIMツリーに設定されている場合、トンネル識別子は<送信者アドレス、p-multicastグループ>です。属性を発信したノードは、MVPNデータのIP/GREカプセル化のソースIPアドレスとして送信者アドレスに掲載されたアドレスを使用する必要があります。

When the Tunnel Type is set to PIM-SM or BIDIR-PIM tree, then the P-Multicast Group in the Tunnel Identifier of the Tunnel attribute SHOULD contain the same multicast group address for all Intra-AS I-PMSI A-D routes for the same MVPN originated by PEs within a given AS. How this multicast group address is chosen is outside the scope of this specification.

トンネルタイプがPIM-SMまたはBidir-PIMツリーに設定されている場合、トンネル属性のトンネル識別子のp-multicastグループには、同じマルチキャストグループアドレスがすべてI-PMSI A-Dルートに対して同じマルチキャストグループアドレスを含める必要があります。MVPNは、与えられたAS内のPESによって発生しました。このマルチキャストグループアドレスがどのように選択されるかは、この仕様の範囲外です。

When the Tunnel Type is set to Ingress Replication, the Tunnel Identifier carries the unicast tunnel endpoint IP address of the local PE that is to be this PE's receiving endpoint address for the tunnel.

トンネルタイプが複製を侵入するように設定されている場合、トンネル識別子は、トンネルのこのPEの受信エンドポイントアドレスであるローカルPEのユニキャストトンネルエンドポイントIPアドレスを運びます。

When the Tunnel Type is set to mLDP Multipoint-to-Multipoint (MP2MP) LSP, the Tunnel Identifier is an MP2MP FEC Element [mLDP].

トンネルタイプがMLDPマルチポイントツーマルチポイント(MP2MP)LSPに設定されている場合、トンネル識別子はMP2MP FEC要素[MLDP]です。

The use of mLDP MP2MP LSPs as Provider tunnels (P-tunnels) requires procedures that are outside the scope of this document.

MLDP MP2MP LSPをプロバイダートンネル(Pタンネル)として使用するには、このドキュメントの範囲外の手順が必要です。

A router that supports the PMSI Tunnel attribute considers this attribute to be malformed if either (a) it contains an undefined tunnel type in the Tunnel Type field of the attribute, or (b) the router cannot parse the Tunnel Identifier field of the attribute as a tunnel identifier of the tunnel types specified in the Tunnel Type field of the attribute.

PMSIトンネル属性をサポートするルーターは、(a)属性のトンネルタイプフィールドに未定義のトンネルタイプが含まれている場合、または(b)ルーターが属性のトンネル識別子フィールドを解析できない場合、この属性は奇形であると見なします。属性のトンネルタイプフィールドで指定されたトンネルタイプのトンネル識別子。

When a router that receives a BGP Update that contains the PMSI Tunnel attribute with its Partial bit set determines that the attribute is malformed, the router SHOULD treat this Update as though all the routes contained in this Update had been withdrawn.

部分的なビットセットを備えたPMSIトンネル属性を含むBGPアップデートを受信するルーターが、属性が奇形であると判断すると、この更新に含まれるすべてのルートが撤回されたかのようにこのアップデートを扱う必要があります。

An implementation MUST provide debugging facilities to permit issues caused by a malformed PMSI Tunnel attribute to be diagnosed. At a minimum, such facilities MUST include logging an error when such an attribute is detected.

実装は、奇形のPMSIトンネル属性が診断されることによって引き起こされる問題を許可するために、デバッグ施設を提供する必要があります。少なくとも、そのような施設には、そのような属性が検出された場合、エラーのログの記録を含める必要があります。

The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf A-D routes.

PMSIトンネル属性は、INTRA-AS I-PMSI A-Dルート、INTER-AS I-PMSI A-Dルート、S-PMSI A-Dルート、およびリーフA-Dルートと組み合わせて使用されます。

6. Source AS Extended Community
6. 拡張コミュニティとしてのソース

This document defines a new BGP Extended Community called "Source AS".

このドキュメントでは、「Source As」と呼ばれる新しいBGP拡張コミュニティを定義しています。

The Source AS is an AS-specific Extended Community, of an extended type, and is transitive across AS boundaries [RFC4360].

ソースは、AS固有の拡張コミュニティであり、拡張されたタイプであり、境界[RFC4360]として推移的です。

The Global Administrator field of this Community MUST be set to the ASN of the PE. The Local Administrator field of this Community MUST be set to 0.

このコミュニティのグローバル管理者分野は、PEのASNに設定する必要があります。このコミュニティのローカル管理者フィールドは0に設定する必要があります。

Consider a given MVPN that uses BGP for exchanging C-multicast routes, and/or uses segmented inter-AS tunnels. A PE that has sites of that MVPN connected to it, and originates a (unicast) route to VPN-IP addresses associated with the destinations within these sites, MUST include in the BGP Update message that carries this route the Source AS Extended Community.

C-Multicastルートを交換するためにBGPを使用する特定のMVPNを検討し、および/またはセグメント化されたトンネルを使用します。そのMVPNのサイトがそれに接続され、これらのサイト内の目的地に関連付けられたVPN-IPアドレスへの(ユニキャスト)ルートを発信するPEは、このルートを拡張コミュニティとしてソースに伝えるBGPアップデートメッセージに含める必要があります。

The usage of a received Source AS Extended Community is described in Section 11.1.3.

拡張コミュニティとしての受信ソースの使用については、セクション11.1.3で説明されています。

7. VRF Route Import Extended Community
7. VRFルートインポート拡張コミュニティ

This document defines a new BGP Extended Community called "VRF Route Import".

このドキュメントでは、「VRFルートインポート」と呼ばれる新しいBGP拡張コミュニティを定義しています。

The VRF Route Import is an IP-address-specific Extended Community, of an extended type, and is transitive across AS boundaries [RFC4360].

VRFルートのインポートは、拡張タイプのIPアドレス固有の拡張コミュニティであり、境界として推移的です[RFC4360]。

To support MVPN in addition to the import/export Route Target(s) Extended Communities used by the unicast routing, each VRF on a PE MUST have an import Route Target Extended Community, except if it is known a priori that none of the (local) MVPN sites associated with the VRF contain multicast source(s) and/or C-RP; in which case, the VRF need not have this import Route Target.

MVPNをサポートするには、ユニキャストルーティングで使用されるインポート/エクスポートルートターゲットの拡張コミュニティに加えて、PEの各VRFには、輸入ルートターゲット拡張コミュニティが必要です。)VRFに関連付けられたMVPNサイトには、マルチキャストソースおよび/またはC-RPが含まれています。その場合、VRFにはこのインポートルートターゲットが必要です。

We refer to this Route Target as the "C-multicast Import RT", as this Route Target controls imports of C-multicast routes into a particular VRF.

このルートターゲットは、C-Multicastルートのインポートを特定のVRFに制御するため、このルートターゲットを「C-Multicast Import RT」と呼びます。

A PE constructs C-multicast Import RT as follows:

PEは次のようにc-multicastのインポートRTを構築します。

+ The Global Administrator field of the C-multicast Import RT MUST be set to an IP address of the PE. This address SHOULD be common for all the VRFs on the PE (e.g., this address may be the PE's loopback address).

+ C-MulticastインポートRTのグローバル管理者フィールドは、PEのIPアドレスに設定する必要があります。このアドレスは、PE上のすべてのVRFで共通する必要があります(たとえば、このアドレスはPEのループバックアドレスである場合があります)。

+ The Local Administrator field of the C-multicast Import RT associated with a given VRF contains a 2-octet number that uniquely identifies that VRF within the PE that contains the VRF (procedures for assigning such numbers are purely local to the PE and are outside the scope of this document).

+ 特定のVRFに関連付けられたC-Multicast Import RTのローカル管理者フィールドには、VRFを含むPE内のVRFを一意に識別する2-OCTET番号が含まれています(そのような数値を割り当てる手順はPEに純粋にローカルであり、外側にありますこのドキュメントの範囲)。

The way C-multicast Import RT is constructed allows it to uniquely identify a VRF.

C-MulticastのインポートRTの構築方法により、VRFを一意に識別できます。

A PE that has site(s) of a given MVPN connected to it needs to communicate the value of the C-multicast Import RT associated with the VRF of that MVPN on the PE to all other PEs that have sites of that MVPN. To accomplish this, a PE that originates a (unicast) route to VPN-IP addresses MUST include in the BGP Updates message that carries this route the VRF Route Import Extended Community that has the value of the C-multicast Import RT of the VRF associated with the route, except if it is known a priori (e.g., via provisioning) that none of these addresses could act as multicast sources and/or RP; in which case, the (unicast) route MUST NOT carry the VRF Route Import Extended Community.

ITに接続された特定のMVPNのサイトを持つPEは、そのMVPNのサイトを持つ他のすべてのPESに、そのMVPNのVRFに関連付けられたCマルチキャストインポートRTの値を通信する必要があります。これを達成するために、VPN-IPアドレスへの(ユニキャスト)ルートを発信するPEには、このルートを掲載するBGP更新メッセージに、関連するVRFのC-MulticastインポートRTの値を持つVRFルートインポートエクステンションコミュニティを含める必要があります。ルートでは、これらのアドレスのいずれもマルチキャストソースおよび/またはRPとして機能しないという先験的な(例えば、プロビジョニングを介して)が知られている場合を除きます。その場合、(ユニキャスト)ルートは、VRFルートインポートエクステンションコミュニティを携帯してはなりません。

If a PE uses Route Target Constraint [RT-CONSTRAIN], the PE SHOULD advertise all such C-multicast Import RTs using Route Target Constraints (note that doing this requires just a single Route Target Constraint advertisement by the PE). This allows each C-multicast route to reach only the relevant PE. To constrain distribution of the Route Target Constraint routes to the AS of the advertising PE, these routes SHOULD carry the NO_EXPORT Community [RFC1997].

PEがルートターゲット制約[RT-Constrain]を使用する場合、PEはルートターゲット制約を使用してそのようなC-MulticastインポートRTをすべて宣伝する必要があります(これを行うには、PEによる単一のルートターゲット制約広告のみが必要であることに注意してください)。これにより、各C-Multicastルートは関連するPEのみに到達できます。ルートターゲット制約ルートの分布をAs As Ads Ads PEに制限するために、これらのルートはNO_Exportコミュニティ[RFC1997]を運ぶ必要があります。

Usage of VRF Route Import Extended Community is described in Section 11.1.3.

VRFルートインポート拡張コミュニティの使用については、セクション11.1.3で説明されています。

8. PE Distinguisher Labels Attribute
8. PE distinguisherラベル属性

This document defines a new BGP attribute, called the "PE Distinguisher Labels" attribute. This is an optional transitive BGP attribute. The format of this attribute is defined as follows:

このドキュメントは、「PE distimuisherラベル」属性と呼ばれる新しいBGP属性を定義します。これは、オプションの推移的なBGP属性です。この属性の形式は、次のように定義されています。

      +---------------------------------+
      |           PE Address            |
      +---------------------------------+
      |     Label (3 octets)            |
      +---------------------------------+
      .......
      +---------------------------------+
      |           PE Address            |
      +---------------------------------+
      |     Label (3 octets)            |
      +---------------------------------+
        

The Label field contains an MPLS label encoded as 3 octets, where the high-order 20 bits contain the label value.

ラベルフィールドには、3オクテットとしてエンコードされたMPLSラベルが含まれており、高次の20ビットにはラベル値が含まれています。

A router that supports the PE Distinguisher Labels attribute considers this attribute to be malformed if the PE Address field does not contain a unicast address. The attribute is also considered to be malformed if: (a) the PE Address field is expected to be an IPv4 address, and the length of the attribute is not a multiple of 7 or (b) the PE Address field is expected to be an IPv6 address, and the length of the attribute is not a multiple of 19. The length of the Route Type field of MCAST-VPN NLRI of the route that carries the PE Distinguisher Labels attribute provides the information on whether the PE Address field contains an IPv4 or IPv6 address. Each of the PE addresses in the PE Distinguisher Labels attribute MUST be of the same address family as the "Originating Router's IP Address" of the route that is carrying the attribute.

PE distimingerラベル属性をサポートするルーターは、PEアドレスフィールドにユニキャストアドレスが含まれていない場合、この属性が奇形であると見なします。属性は、次の場合に奇形であると見なされます。(a)PEアドレスフィールドがIPv4アドレスであると予想され、属性の長さは7の倍数ではないか(b)PEアドレスフィールドはIPv6アドレス、および属性の長さは19の倍数ではありません。PEdistiutiuserラベル属性を運ぶルートのmcast-vpn nlriのルートタイプフィールドの長さは、PEアドレスフィールドにIPv4が含まれているかどうかに関する情報を提供します。またはIPv6アドレス。PE distimingerラベル属性のPEアドレスのそれぞれは、属性を運んでいるルートの「ROINITION LUTERのIPアドレス」と同じアドレスファミリでなければなりません。

When a router that receives a BGP Update that contains the PE Distinguisher Labels attribute with its Partial bit set determines that the attribute is malformed, the router SHOULD treat this Update as though all the routes contained in this Update had been withdrawn.

PE distimingerラベル属性を部分的なビットセットに含むBGPアップデートを受信するルーターが、属性が奇形であることを決定する場合、ルーターはこの更新に含まれるすべてのルートが撤回されたかのように扱う必要があります。

An implementation MUST provide debugging facilities to permit issues caused by malformed PE Distinguisher Label attribute to be diagnosed. At a minimum, such facilities MUST include logging an error when such an attribute is detected.

実装は、不正なPE違いラベル属性によって引き起こされる問題を診断するために、デバッグ施設を提供する必要があります。少なくとも、そのような施設には、そのような属性が検出された場合、エラーのログの記録を含める必要があります。

Usage of this attribute is described in [MVPN].

この属性の使用法は[MVPN]で説明されています。

9. MVPN Auto-Discovery/Binding
9. MVPNオートディスコーブリ/バインディング

This section specifies procedures for the auto-discovery of MVPN memberships and the distribution of information used to instantiate I-PMSIs.

このセクションでは、MVPNメンバーシップの自動発見の手順と、I-PMSISをインスタンス化するために使用される情報の分布を指定します。

There are two MVPN auto-discovery/binding mechanisms, dubbed "intra-AS" and "inter-AS" respectively.

それぞれ「Intra-AS」と「Inter-AS」と呼ばれる2つのMVPN自動発見/結合メカニズムがあります。

The intra-AS mechanisms provide auto-discovery/binding within a single AS.

Intra-ASメカニズムは、単一のAS内で自動発見/結合を提供します。

The intra-AS mechanisms also provide auto-discovery/binding across multiple ASes when non-segmented inter-AS tunnels are being used.

AS Intra-ASメカニズムは、非セグメント化されたASトンネルが使用されている場合、複数のASEにわたって自動発見/結合を提供します。

The inter-AS mechanisms provide auto-discovery/binding across multiple ASes when segmented inter-AS tunnels are being used.

AS間のメカニズムは、セグメント化されたトンネルが使用されている場合、複数のASEにわたって自動発見/結合を提供します。

Note that if a multi-AS system uses option (a) of section 10 of [RFC4364], the notion of inter-AS tunnels does not apply, and so it needs only the intra-AS mechanisms.

Multi-ASシステムが[RFC4364]のセクション10のオプション(a)を使用している場合、トンネル間の概念は適用されないため、ASイントラASメカニズムのみが必要であることに注意してください。

9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations
9.1. MVPNオート配分/バインディング - AS Intra-AS操作

This section describes exchanges of Intra-AS I-PMSI A-D routes originated/received by PEs within the same AS, or if non-segmented inter-AS tunnels are used, then by all PEs.

このセクションでは、INTRA-AS I-PMSI A-Dルートの交換は、同じものと同じPESによって発生/受信された/受信された、または非セグメント化されていないトンネルを使用して、すべてのPEによって使用される場合について説明します。

9.1.1. Originating Intra-AS I-PMSI A-D Routes
9.1.1. I-PMSI A-Dルートとしての発生型

To participate in the MVPN auto-discovery/binding, a PE router that has a given VRF of a given MVPN MUST, except for the cases specified in this section, originate an Intra-AS I-PMSI A-D route and advertises this route in IBGP. The route is constructed as follows.

MVPNオート配管/バインディングに参加するには、このセクションで指定されたケースを除き、特定のMVPNの特定のVRFを持つPEルーターがIPMSI A-DルートとしてINTRA-IPMSI A-Dルートを発生し、IBGPでこのルートを宣伝する必要があります。。ルートは次のように構築されています。

The route carries a single MCAST-VPN NLRI with the RD set to the RD of the VRF, and the Originating Router's IP Address field set to the IP address that the PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the PE. Note that the <RD, Originating Router's IP Address> tuple uniquely identifies a given multicast VRF.

ルートには、VRFのRDにRDセットを備えた単一のMCAST-VPN NLRIと、VRFルートインポートのグローバル管理者フィールドにPEが配置するIPアドレスに設定された原始ルーターのIPアドレスフィールドが搭載されています。PEによって宣伝されたVPN-IPルート。<rd、由来のルーターのIPアドレス>タプルは、特定のマルチキャストVRFを一意に識別することに注意してください。

The route carries the PMSI Tunnel attribute if and only if an I-PMSI is used for the MVPN (the conditions under which an I-PMSI is used can be found in [MVPN]). Depending on the technology used for the P-tunnel for the MVPN on the PE, the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D route is constructed as follows.

ルートは、I-PMSIがMVPNに使用される場合にのみPMSIトンネル属性を運びます(I-PMSIが使用される条件は[MVPN]で見つけることができます)。PE上のMVPNのPトンネルに使用される技術に応じて、INTRA-AS I-PMSI A-DルートのPMSIトンネル属性は、次のように構築されます。

+ If the PE that originates the advertisement uses a P-multicast tree for the P-tunnel for the MVPN, the PMSI Tunnel attribute MUST contain the identity of the tree (note that the PE could create the identity of the tree prior to the actual instantiation of the tree).

+ 広告を発信するPEがMVPNのPトンネルにP-Multicastツリーを使用する場合、PMSIトンネル属性にはツリーのIDが含まれている必要があります(PEは実際のインスタンスの前にツリーのアイデンティティを作成できることに注意してください木の)。

+ A PE that uses a P-multicast tree for the P-tunnel MAY aggregate two or more MVPNs present on the PE onto the same tree. In this case, in addition to carrying the identity of the tree, the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D route MUST carry an MPLS upstream-assigned label that the PE has bound uniquely to the MVPN associated with this route (as determined by its RTs).

+ PトンネルにP-Multicastツリーを使用するPEは、同じツリーにPEに存在する2つ以上のMVPNを集約する場合があります。この場合、ツリーのアイデンティティを運ぶことに加えて、PEがこのルートに関連付けられたMVPNに一意に結合しているMPLSアップストリーム割り当てラベルをMPLS AS I-PMSI A-DルートのPMSIトンネル属性を運ぶ必要があります(RTSによって決定されています)。

If the PE has already advertised Intra-AS I-PMSI A-D routes for two or more MVPNs that it now desires to aggregate, then the PE MUST re-advertise those routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute and the label carried in that attribute.

PEが、現在集計したい2つ以上のMVPNに対してI-PMSI A-Dルートとして既に宣伝している場合、PEはそれらのルートを再承認する必要があります。再承認されたルートは、PMSIトンネル属性とその属性に携帯されているラベルを除き、元のルートと同じでなければなりません。

+ If the PE that originates the advertisement uses ingress replication for the P-tunnel for the MVPN, the route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication and Tunnel Identifier set to a routable address of the PE. The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label. This label is used to demultiplex the MVPN traffic received over a unicast tunnel by the PE.

+ 広告を発信するPEがMVPNのPトンネルにIngressレプリケーションを使用する場合、ルートには、PEのルーティング可能なアドレスに設定された、レプリケーションとトンネル識別子を侵入するトンネルタイプに設定されたPMSIトンネル属性をPMSIトンネル属性を含める必要があります。PMSIトンネル属性は、下流で割り当てられたMPLSラベルを搭載する必要があります。このラベルは、PEによってユニキャストトンネルを介して受け取ったMVPNトラフィックを非難するために使用されます。

+ The Leaf Information Required flag of the PMSI Tunnel attribute MUST be set to zero and MUST be ignored on receipt.

+ PMSIトンネル属性のフラグが必要なリーフ情報は、ゼロに設定する必要があり、受領時に無視する必要があります。

Discovery of PE capabilities in terms of what tunnel types they support is outside the scope of this document. Within a given AS, PEs participating in an MVPN are expected to advertise tunnel bindings whose tunnel types are supported by all other PEs that are

彼らがサポートするトンネルタイプがこのドキュメントの範囲外であるという点で、PE機能の発見。特定のAS内で、MVPNに参加するPESは、トンネルの種類が他のすべてのPESによってサポートされているトンネルバインディングを宣伝することが期待されています

participating in this MVPN and are part of the same AS. In addition, in the inter-AS scenario with non-segmented inter-AS tunnels, the tunnel types have to be supported by all PEs that are participating in this MVPN, irrespective of whether or not these PEs are in the same AS.

このMVPNに参加し、同じものの一部です。さらに、セグメント化されていないトンネルを使用したセグメント化されていないシナリオでは、これらのPEが同じかどうかに関係なく、このMVPNに参加しているすべてのPESによってトンネルタイプをサポートする必要があります。

The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field.

ルートのMP_REACH_NLRI属性の次のホップフィールドは、元のルーターのIPアドレスフィールドで運ばれたものと同じIPアドレスに設定する必要があります。

By default, the distribution of the Intra-AS I-PMSI A-D routes is controlled by the same Route Targets as the ones used for the distribution of VPN-IP unicast routes. That is, by default, the Intra-AS I-PMSI A-D route MUST carry the export Route Target used by the unicast routing. If any other PE has one of these Route Targets configured as an import Route Target for a VRF present on the PE, it treats the advertising PE as a member in the MVPN to which the VRF belongs. The default could be modified via configuration by having a set of Route Targets used for the Intra-AS I-PMSI A-D routes being distinct from the ones used for the VPN-IP unicast routes (see also Section 10).

デフォルトでは、I-PMSI A-Dルート内の分布は、VPN-IPユニキャストルートの分布に使用されたルートターゲットと同じルートターゲットによって制御されます。つまり、デフォルトでは、INTRA-AS I-PMSI A-Dルートは、ユニキャストルーティングで使用されるエクスポートルートターゲットを搭載する必要があります。PEに存在するVRFのインポートルートターゲットとして構成されたこれらのルートターゲットのいずれかが他のPEを持っている場合、広告PEはVRFが属するMVPNのメンバーとして扱います。デフォルトは、VPN-IPユニキャストルートに使用されるものとは異なるIPMSI A-Dルートに使用されるルートターゲットのセットを使用することにより、構成によって変更できます(セクション10も参照)。

To constrain distribution of the intra-AS membership/binding information to the AS of the advertising PE, the BGP Update message originated by the advertising PE SHOULD carry the NO_EXPORT Community [RFC1997].

ASメンバーシップ/拘束力のある情報の配布を広告PEのASに制約するために、広告PEから発信されるBGP更新メッセージはNO_EXPORTコミュニティ[RFC1997]を搭載する必要があります。

Note that if non-segmented inter-AS P-tunnels are being used, then the Intra-AS I-PMSI routes need to be distributed to other ASes and MUST NOT carry the NO_EXPORT Community.

非セグメント化されていないP-tunnelsが使用されている場合、Intra-As I-PMSIルートは他のASEに配布する必要があり、NO_Exportコミュニティを運ばないでください。

When BGP is used to exchange C-multicast routes, if (a) it is known a priori that, as a matter of policy, none of the MVPN sites connected to a given PE are allowed to send multicast traffic to other sites of that MVPN (in other words, all these sites are only in the Receiver Sites set), (b) the PE does not use ingress replication for the incoming traffic of that MVPN, and (c) none of the other PEs that have VRFs of that MVPN use RSVP-TE P2MP LSP for that MVPN, then the local PE SHOULD NOT originate an Intra-AS I-PMSI A-D route.

BGPがC-Multicastルートを交換するために使用される場合、(a)ポリシーの問題として、特定のPEに接続されているMVPNサイトのいずれも、そのMVPNの他のサイトにマルチキャストトラフィックを送信することは許可されていないことが知られている場合、(言い換えれば、これらのすべてのサイトはセットされたレシーバーサイトのみにあります)、(b)PEはそのMVPNの着信トラフィックにイングレス複製を使用せず、(c)そのMVPNのVRFを持っている他のPESはありませんそのMVPNにRSVP-TE P2MP LSPを使用すると、ローカルPEはI-PMSI A-Dルートとして発生するべきではありません。

When BGP is used to exchange C-multicast routes, if it is known a priori that, as a matter of policy, none of the MVPN sites connected to a given PE can receive multicast traffic from other sites of that MVPN (in other words, all these sites are only in the Sender Sites set), and the PE uses ingress replication for that MVPN, then the PE SHOULD NOT originate an Intra-AS I-PMSI A-D route for that MVPN.

BGPを使用してC-Multicastルートを交換する場合、ポリシーの問題として、特定のPEに接続されているMVPNサイトのいずれも、そのMVPNの他のサイトからマルチキャストトラフィックを受け取ることができないという先験的に知られている場合(言い換えれば、これらのすべてのサイトはセットセットのみにあります)、PEはそのMVPNにイングレスレプリケーションを使用します。その場合、PEはそのMVPNのI-PMSI A-DルートとしてのINTRA-INTRA-AS AS INTRA-AS AS INTRA-AS AS INTRA-AS AS INTRA-AS AS AS AS INTASを発生させるべきではありません。

9.1.2. Receiving Intra-AS I-PMSI A-D Routes
9.1.2. IPMSI AS I-PMSI A-Dルートを受信します

When a PE receives a BGP Update message that carries an Intra-AS I-PMSI A-D route such that (a) at least one of the Route Targets of the route matches one of the import Route Targets configured for a particular VRF on the local PE, (b) either the route was originated by some other PE within the same AS as the local PE, or the MVPN associated with the VRF uses non-segmented inter-AS tunnels, and (c) the BGP route selection determines that this is the best route with respect to the NLRI carried by the route, the PE performs the following.

PEがINTRA-AS I-PMSI A-Dルートを運ぶBGPアップデートメッセージを受信した場合、(a)ルートのルートターゲットの少なくとも1つが、ローカルPEの特定のVRFに対して構成されたインポートルートターゲットの1つと一致するようにする場合(b)ルートは、ローカルPEと同じ他のPEから発信されたか、VRFに関連付けられたMVPNが非セグメント化されたトンネルを使用し、(c)BGPルートの選択はこれがあると判断します。ルートで運ばれるNLRIに関して最適なルートは、PEが次のことを実行します。

If the route does not carry the PMSI Tunnel attribute and ingress replication is not used, either a) the PE that originated the route will be using only S-PMSIs to send traffic to remote PEs, or b) as a matter of policy, the PE that originated the route cannot send multicast traffic from the MVPN sites connected to it to other sites of that MVPN (in other words, the sites connected to the PE are only in the Receiver Sites set).

ルートがPMSIトンネル属性とイングレスレプリケーションを使用していない場合、a)ルートを発信したPEは、S-PMSISのみを使用してリモートPEにトラフィックを送信するか、b)ポリシーの問題として、ルートを発信したPEは、MVPNサイトからそのMVPNの他のサイトに接続されているMVPNサイトからマルチキャストトラフィックを送信できません(つまり、PEに接続されたサイトはセットされたレシーバーサイトのみです)。

When BGP is used to exchange C-multicast routes, to distinguish between cases (a) and (b), we use the presence/absence of the VRF Route Import Extended Community in the unicast VPN routes, as follows. As specified in Section 7, if it is know a priori that none of the addresses carried in the NLRI of a given (unicast) VPN route could act as multicast sources and/or C-RP, then such a route does not carry the VRF Route Import Extended Community. Hence, based on the Upstream Multicast Hop (UMH) selection algorithm specified in [MVPN], such a route will be ineligible for the UMH selection. This implies that if a given VPN route is selected by the UMH selection procedures, and the PE that originates this VPN route also originates an Intra-AS I-PMSI A-D route, but this route does not carry the PMSI Tunnel attribute, then this PE will be using only S-PMSIs for sending (multicast) data.

BGPを使用してC-Multicastルートを交換し、ケース(a)と(b)を区別するために、次のようにUnicast VPNルートでVRFルートインポートエクステンデッドコミュニティの存在/不在を使用します。セクション7で指定されているように、特定の(Unicast)VPNルートのNLRIに携帯されているアドレスがマルチキャストソースおよび/またはC-RPとして機能する可能性があるという先験的なものがわかっている場合、そのようなルートはVRFを運びませんルートインポート拡張コミュニティ。したがって、[MVPN]で指定されたアップストリームマルチキャストホップ(UMH)選択アルゴリズムに基づいて、このようなルートはUMH選択に適していません。これは、特定のVPNルートがUMH選択手順によって選択され、このVPNルートを発信するPEがI-PMSI A-Dルートとしても発生することを意味しますが、このルートにはPMSIトンネル属性がありません。(マルチキャスト)データの送信にS-PMSISのみを使用します。

If the route carries the PMSI Tunnel attribute, then:

ルートにPMSIトンネル属性がある場合は、次のとおりです。

+ If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress Replication, then the MPLS label and the address carried in the Tunnel Identifier field of the PMSI Tunnel attribute should be used when the local PE sends multicast traffic to the PE that originated the route.

+ PMSIトンネル属性のトンネルタイプがレプリケーションを侵入するように設定されている場合、MPLSラベルとPMSIトンネル属性のトンネル識別子フィールドに配置されたアドレスを使用する必要があります。。

+ If the Tunnel Type in the PMSI Tunnel attribute is set to mLDP P2MP LSP, mLDP MP2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM tree, the PE SHOULD join as soon as possible the P-multicast tree whose identity is carried in the Tunnel Identifier.

+ PMSIトンネル属性のトンネルタイプがMLDP P2MP LSP、MLDP MP2MP LSP、PIM-SSMツリー、PIM-SMツリー、またはBidir-PIMツリーに設定されている場合、PEはできるだけ早くP-Multicastツリーに結合する必要があります。アイデンティティはトンネル識別子に運ばれます。

+ If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE P2MP LSP, then the PE that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE as a leaf. This LSP may have been established before the local PE receives the route, or it may be established after the local PE receives the route.

+ PMSIトンネル属性のトンネルタイプがRSVP-TE P2MP LSPに設定されている場合、ルートを発信したPEは、ローカルPEを葉としてRSVP-TE P2MP LSPを確立する必要があります。このLSPは、ローカルPEがルートを受信する前に確立された可能性があります。または、ローカルPEがルートを受け取った後に確立される場合があります。

+ The receiving PE has to establish the appropriate state to properly handle the traffic received on the P-multicast tree.

+ 受信PEは、P-Multicastツリーで受信したトラフィックを適切に処理するために適切な状態を確立する必要があります。

+ If the PMSI Tunnel attribute does not carry a label, then all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, are forwarded using the VRF that has at least one of its import Route Targets that matches one of the Route Targets of the received Intra-AS I-PMSI A-D route.

+ PMSIトンネル属性がラベルを搭載していない場合、PMSIトンネル属性によって識別されるP-Multicastツリーで受信されるすべてのパケットは、1つに一致する輸入ルートターゲットの少なくとも1つを持つVRFを使用して転送されます。受信したINTRA-AS I-PMSI A-Dルートのルートターゲットの。

+ If the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree, PIM-SM tree, BIDIR-PIM tree, or RSVP-TE P2MP LSP, and the attribute also carries an MPLS label, then this is an upstream-assigned label, and all packets that are received on the P-multicast tree, as identified by the PMSI Tunnel attribute, with that upstream-assigned label are forwarded using the VRF that has at least one of its import Route Targets that matches one of the Route Targets of the received Intra-AS I-PMSI A-D route.

+ PMSIトンネル属性のトンネルタイプがMLDP P2MP LSP、PIM-SSMツリー、PIM-SMツリー、Bidir-PIMツリー、またはRSVP-TE P2MP LSPに設定されており、属性にもMPLSラベルが付いている場合、これはこれです。アップストリーム割り当てのラベル、およびPMSIトンネル属性によって識別されるP-Multicastツリーで受信されるすべてのパケットは、そのアップストリーム割り当てラベルが、1つに一致する輸入ルートターゲットの少なくとも1つを持つVRFを使用して転送されます。受信したINTRA-AS I-PMSI A-Dルートのルートターゲットの。

Irrespective of whether the route carries the PMSI Tunnel attribute, if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic from the VRF to the sites attached to other PEs, then the local PE uses the Originating Router's IP address information carried in the route to add the PE that originated the route as a leaf node to the LSP.

ルートがPMSIトンネル属性を持っているかどうかに関係なく、ローカルPEがVRFから他のPEに接続されたサイトに(マルチキャスト)トラフィックを送信するためにRSVP-TE P2MP LSPを使用する場合、ローカルPEは発生するルーターのIPアドレス情報を使用します。ルートでは、LSPへのリーフノードとしてルートを発信したPEを追加します。

9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations
9.2. MVPNオート配管/バインディング - AS操作間操作

This section applies only to the case where segmented inter-AS tunnels are used.

このセクションは、セグメント化されたトンネルが使用される場合にのみ適用されます。

An Autonomous System Border Router (ASBR) may be configured to support a particular MVPN as follows:

自律システムの境界ルーター(ASBR)は、次のように特定のMVPNをサポートするように構成できます。

+ An ASBR MUST be configured with a set of (import) Route Targets (RTs) that specifies the set of MVPNs supported by the ASBR. These Route Targets control acceptance of Intra-AS/Inter-AS I-PMSI A-D routes by the ASBR. As long as unicast and multicast connectivity are congruent, this could be the same set of Route Targets as the one used for supporting unicast (and therefore would not require any additional configuration above and beyond of

+ ASBRは、ASBRがサポートするMVPNのセットを指定する(インポート)ルートターゲットのセット(RT)で構成する必要があります。これらのルートターゲットは、ASBRによるI-PMSI A-DルートとしてのAS/Inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-inter-as inter-as inter-inter-inter-as inter-as inter-as inter-as inter-as inter-as inter-asを制御します。ユニキャストとマルチキャストの接続性が一致している限り、これはユニキャストのサポートに使用されたターゲットと同じセットのルートターゲットになる可能性があります(したがって、より上以上の構成は必要ありません。

what is required for unicast). Note that instead of being configured, the ASBR MAY obtain this set of (import) Route Targets (RTs) by using Route Target Constraint [RT-CONSTRAIN].

ユニキャストに必要なもの)。ASBRは、構成される代わりに、ルートターゲット制約[RT-Constrain]を使用して、この(インポート)ルートターゲット(RTS)のセットを取得できることに注意してください。

+ The ASBR MUST be (auto-)configured with an import Route Target called "ASBR Import RT". ASBR Import RT controls acceptance of Leaf A-D routes and C-multicast routes by the ASBR, and is used to constrain distribution of both Leaf A-D routes and C-multicast routes (see Section 11).

+ ASBRは、「ASBRインポートRT」と呼ばれるインポートルートターゲットで(自動)構成されている必要があります。ASBR Import RTは、ASBRによるリーフA-DルートとCマルチキャストルートの受け入れを制御し、Leaf A-DルートとCマルチキャストルートの両方の分布を制限するために使用されます(セクション11を参照)。

ASBR Import RT is an IP-address-specific Route Target. The Global Administrator field of the ASBR Import RT MUST be set to the IP address carried in the Next Hop of all the Inter-AS I-PMSI A-D routes and S-PMSI A-D routes advertised by this ASBR (if the ASBR uses different Next Hops, then the ASBR MUST be (auto-)configured with multiple ASBR Import RTs, one per each such Next Hop). The Local Administrator field of the ASBR Import RT MUST be set to 0.

ASBRインポートRTは、IPアドレス固有のルートターゲットです。ASBRインポートRTのグローバル管理者フィールドは、すべてのINTER-AS I-PMSI A-DルートとS-PMSI A-Dルートの次のホップで運ばれるIPアドレスに設定する必要があります(ASBRが異なる次のホップを使用する場合、次に、ASBRは、複数のASBRインポートRTSで(自動)構成されている必要があります。ASBRインポートRTのローカル管理者フィールドは0に設定する必要があります。

If the ASBR supports Route Target Constraint [RT-CONSTRAIN], the ASBR SHOULD advertise its ASBR Import RT within its own AS using Route Target Constraints. To constrain distribution of the Route Target Constraint routes to the AS of the advertising ASBR, these routes SHOULD carry the NO_EXPORT Community [RFC1997].

ASBRがルートターゲットの制約[RT-Constrain]をサポートする場合、ASBRはRoute Target Constraintsを使用してASBRインポートRTを独自の内で宣伝する必要があります。ルートターゲット制約ルートの分布をAS AS ASBRに制限するために、これらのルートはNO_EXPORTコミュニティ[RFC1997]を運ぶ必要があります。

+ The ASBR MUST be configured with the tunnel types for the intra-AS segments of the MVPNs supported by the ASBR, as well as (depending on the tunnel type) the information needed to create the PMSI attribute for these tunnel types. Note that instead of being configured, the ASBR MAY derive the tunnel types from the Intra-AS I-PMSI A-D routes received by the ASBR.

+ ASBRは、ASBRがサポートするMVPNのセグメントとしてのトンネルタイプで構成する必要があります。また、これらのトンネルタイプのPMSI属性を作成するために必要な情報を(トンネルタイプによって異なります)。ASBRは、構成される代わりに、ASBRが受信したI-PMSI A-Dルート内からトンネルタイプを導出する場合があることに注意してください。

+ If the ASBR originates an Inter-AS I-PMSI A-D route for a particular MVPN present on some of the PEs within its own AS, the ASBR MUST be (auto-)configured with an RD for that MVPN. It is RECOMMENDED that one of the following two options be used:

+ ASBRが、特定のMVPNのI-PMSI A-Dルートを発信している場合、AS ASの一部に存在する特定のMVPNの場合、ASBRはそのMVPNのRDで(自動)構成する必要があります。次の2つのオプションのいずれかを使用することをお勧めします。

(1) To allow more aggregation of Inter-AS I-PMSI A-D routes, it is recommended that all the ASBRs within an AS that are configured to originate an Inter-AS I-PMSI A-D route for a particular MVPN be configured with the same RD (although for a given MVPN each AS may assign this RD on its own, without coordination with other ASes).

(1) I-PMSI A-Dルートの間での集約を可能にするには、特定のMVPNのI-PMSI A-DルートとしてのINTER-AS I-PMSI A-Dルートを同じRDで構成するように構成されているAS内のAS内のすべてのASBRを構成することをお勧めします(ただし特定のMVPNについては、他のASEとの調整なしに、このRDを単独で割り当てることができます。

(2) To allow more control over spreading MVPN traffic among multiple ASBRs within a given AS, it is recommended that each ASBR have a distinct RD per each MVPN; in which case, such an RD SHOULD be auto-configured.

(2) 与えられたAS内の複数のASBR間のMVPNトラフィックの拡散をより強く制御できるようにするには、各ASBRが各MVPNごとに異なるRDを持つことをお勧めします。その場合、そのようなRDは自動構成する必要があります。

If an ASBR is configured to support a particular MVPN, the ASBR MUST participate in the intra-AS MVPN auto-discovery/binding procedures for that MVPN within the ASBR's own AS, as specified in Section 9.1.

ASBRが特定のMVPNをサポートするように構成されている場合、ASBRは、セクション9.1で指定されているように、ASBR自身のASBR自身のMVPNのAS AS AS AS AS AS AS AS-ASO-Discovery/Binding手順に参加する必要があります。

Moreover, in addition to the above, the ASBR performs procedures described in Sections 9.2.1, 9.2.2, and 9.2.3.

さらに、上記に加えて、ASBRはセクション9.2.1、9.2.2、および9.2.3で説明されている手順を実行します。

9.2.1. Originating Inter-AS I-PMSI A-D Routes
9.2.1. I-PMSI A-Dルートとしての発生型

For a given MVPN configured on an ASBR when the ASBR determines (using the intra-AS auto-discovery procedures) that at least one of the PEs of its own AS has (directly) connected site(s) of the MVPN, the ASBR originates an Inter-AS I-PMSI A-D route and advertises it in External BGP (EBGP). The route is constructed as follows:

ASBRが(AS Intra-AS Auto Discovery手順を使用)を決定したときにASBRで構成された特定のMVPNについて、MVPNの(直接)接続されたサイトがある独自のPESの少なくとも1つは、ASBRが発生することをINTER-AS I-PMSI A-Dルートと外部BGP(EBGP)で宣伝します。ルートは次のように構築されます。

+ The route carries a single MCAST-VPN NLRI with the RD set to the RD configured for that MVPN on the ASBR, and the Source AS set to the ASN of the ASBR.

+ このルートには、ASBRでそのMVPN用に構成されたRDセットとASBRのASNに設定されたソースを備えたRDセットを備えた単一のMCAST-VPN NLRIを搭載しています。

+ The route carries the PMSI Tunnel attribute if and only if an I-PMSI is used for the MVPN. The Tunnel Type in the attribute is set to Ingress Replication; the Leaf Information Required flag is set to 1; the attribute carries no MPLS labels.

+ ルートは、I-PMSIがMVPNに使用されている場合にのみ、PMSIトンネル属性を運びます。属性のトンネルタイプは、複製を侵入するように設定されています。必要なフラグが1に設定されています。属性にはMPLSラベルが含まれていません。

+ The Next Hop field of the MP_REACH_NLRI attribute is set to a routable IP address of the ASBR.

+ MP_REACH_NLRI属性の次のホップフィールドは、ASBRのルーティング可能なIPアドレスに設定されています。

+ The default policy for aggregation of Intra-AS I-PMSI A-D routes into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI A-D route aggregates only the Intra-AS I-PMSI A-D routes that carry exactly the same set of RTs (note that this set may have just one RT). In this case, an Inter-AS I-PMSI A-D route originated by an ASBR carries exactly the same RT(s) as the RT(s) carried by the Intra-AS I-PMSI A-D routes that the ASBR aggregates into that Inter-AS I-PMSI A-D route. An implementation MUST support the default policy for aggregation of Intra-AS I-PMSI A-D routes into an Inter-AS I-PMSI A-D route.

+ INTRA-AS I-PMSI A-DルートをINTER-AS I-PMSI A-Dルートに集約するためのデフォルトポリシーは、特定のI-PMSI A-Dルートを正確に運ぶIPMSI A-Dルートのみを集約することです。同じセットのRTS(このセットには1つのRTしかない可能性があることに注意してください)。この場合、ASBRによって発生したI-PMSI A-Dルート間では、INTRA-AS I-PMSI A-Dルートによって運ばれるRT(s)とまったく同じRTを運びます。I-PMSI A-Dルートとして。実装は、I-PMSI A-DルートをINTER-AS I-PMSI A-Dルートに分類するためのデフォルトのポリシーをサポートする必要があります。

+ The default policy for aggregation could be modified via configuration on the ASBR. An implementation MAY support such functionality. Modified policy MUST include rules for constructing RTs carried by the Inter-AS I-PMSI A-D routes originated by the ASBR.

+ 集約のデフォルトのポリシーは、ASBRの構成を介して変更できます。実装はそのような機能をサポートする場合があります。修正されたポリシーには、ASBRが発信するINTER-AS I-PMSI A-Dルートによって運ばれるRTを構築するためのルールを含める必要があります。

An Inter-AS I-PMSI A-D route for a given <AS, MVPN> indicates the presence of the MVPN sites connected to one or more PEs of the AS.

特定の<AS、MVPN>のI-PMSI A-Dルート間は、ASの1つ以上のPESに接続されたMVPNサイトの存在を示します。

An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-AS I-PMSI A-D routes originated within the ASBR's own AS. Thus, while the Intra-AS I-PMSI A-D routes originated within an AS are at the granularity of <PE, MVPN> within that AS, outside of that AS the (aggregated) Inter-AS I-PMSI A-D routes could be at the granularity of <AS, MVPN>.

Inter-AS I-PMSI A-Dルートは、ASBR自身のAS内で発生するASBR凝集体Intra-AS I-PMSI A-Dルートによって発生しました。したがって、INTRA-AS I-PMSI A-Dルートは、<PE、MVPN>の粒度の中にあるように、その中には(集約された)I-PMSI A-Dルートとしてのものとして、それ以外では、<as、mvpn>の粒度。

9.2.2. When Not to Originate Inter-AS I-PMSI A-D Routes
9.2.2. INTER-AS I-PMSI A-Dルートを発信しない場合

If, for a given MVPN and a given AS, all of the sites connected to the PEs within the AS are known a priori to have no multicast sources, then ASBRs of that AS MAY refrain from originating an Inter-AS I-PMSI A-D route for that MVPN at all.

特定のMVPNおよび与えられたASの場合、マルチキャストソースがないことが知られているAS内のPESに接続されているすべてのサイトが、I-PMSI A-Dルートを介して発信することを控える可能性がある場合そのMVPNのために。

9.2.3. Propagating Inter-AS I-PMSI A-D Routes
9.2.3. I-PMSI A-Dルートとしての間の伝播

An Inter-AS I-PMSI A-D route for a given MVPN originated by an ASBR within a given AS is propagated via BGP to other ASes.

特定のMVPNのINTER-AS I-PMSI A-Dルートは、BGPを介して他のASEに伝播されるように、与えられたASBRによって発生しました。

9.2.3.1. Propagating Inter-AS I-PMSI A-D Routes - Overview
9.2.3.1. I-PMSI A-Dルートとしての間の伝播 - 概要

Suppose that ASBR A installs an Inter-AS I-PMSI A-D route for MVPN V that originated at a particular AS, AS1. The BGP Next Hop of that route becomes A's "upstream multicast hop" on a multicast distribution tree for V that is rooted at AS1. When the Inter-AS I-PMSI A-D routes have been distributed to all the necessary ASes, they define a "reverse path" from any AS that supports MVPN V back to AS1. For instance, if AS2 supports MVPN V, then there will be a reverse path for MVPN V from AS2 to AS1. This path is a sequence of ASBRs, the first of which is in AS2, and the last of which is in AS1. Each ASBR in the sequence is the BGP Next Hop of the previous ASBR in the sequence on the given Inter-AS I-PMSI A-D route.

ASBR Aが、特定のAS1で発生したMVPN VのI-PMSI A-Dルートをインストールすると仮定します。そのルートのBGP次のホップは、AS1にルート化されたVのマルチキャスト配布ツリーのAの「アップストリームマルチキャストホップ」になります。INTER-AS I-PMSI A-Dルートが必要なすべてのASEに分布すると、MVPN VをサポートするAS AS1にAS1に「逆パス」を定義します。たとえば、AS2がMVPN Vをサポートする場合、AS2からAS1へのMVPN Vの逆パスがあります。このパスはASBRのシーケンスであり、最初はAS2で、最後はAS1です。シーケンス内の各ASBRは、指定されたI-PMSI A-Dルートのシーケンスにある以前のASBRのBGP次のホップです。

This reverse path information can be used to construct a unidirectional multicast distribution tree for MVPN V, containing all the ASes that support V, and having AS1 at the root. We call such a tree an "inter-AS tree". Multicast data originating in MVPN sites connected to PEs within a given AS will travel downstream along the tree, which is rooted at that AS.

このリバースパス情報は、MVPN Vの単方向マルチキャスト分布ツリーを構築するために使用できます。これは、VをサポートするすべてのASEを含む、およびrootにAS1を含むことができます。私たちはそのような木を「界のツリー」と呼びます。MVPNサイトに由来するマルチキャストデータは、特定のものに沿って下流に移動します。

The path along an inter-AS tree is a sequence of ASBRs; it is still necessary to specify how the multicast data gets from a given ASBR to the set of ASBRs that are immediately downstream of the given ASBR along the tree. This is done by creating "segments": ASBRs in adjacent ASes will be connected by inter-AS segments, ASBRs in the same AS will be connected by "intra-AS segments".

AS間のツリーに沿ったパスは、ASBRのシーケンスです。特定のASBRから、ツリーに沿って与えられたASBRのすぐ下流にあるASBRのセットにマルチキャストデータがどのように得られるかを指定する必要があります。これは、「セグメント」を作成することによって行われます。隣接するASEのASBRは、「セグメント内」で接続されるのと同じASBRS、ASBRによって接続されます。

An ASBR initiates creation of an intra-AS segment when the ASBR receives an Inter-AS I-PMSI A-D route from an EBGP neighbor. Creation of the segment is completed as a result of distributing, via IBGP, this route within the ASBR's own AS.

ASBRは、ASBRがEBGPネイバーからINTER-AS I-PMSI A-Dルートを受け取ったときに、ASイントラASセグメントの作成を開始します。セグメントの作成は、IBGPを介してASBR自身のAS内のこのルートの分布の結果として完了します。

For a given inter-AS tunnel, each of its intra-AS segments could be constructed by its own independent mechanism. Moreover, by using upstream-assigned labels within a given AS multiple intra-AS segments of different inter-AS tunnels of either the same or different MVPNs may share the same P-multicast tree.

特定のアサイズ間トンネルの場合、それぞれのセグメントは独自の独立したメカニズムによって構築される可能性があります。さらに、同じまたは異なるMVPNのいずれかの異なるトンネルの複数のASセグメントとして、与えられた複数のASセグメントとして上流で割り当てられたラベルを使用することにより、同じP-Multicastツリーを共有する場合があります。

If the P-multicast tree that serves as a particular intra-AS segment of an inter-AS tunnel is created by a multicast control protocol that uses receiver-initiated joins (e.g., mLDP, any PIM variant), and this P-multicast tree does not aggregate multiple segments, then all the information needed to create that segment is present in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D routes. However, if the P-multicast tree that serves as the segment is created by a protocol that does not use receiver-initiated joins (e.g., RSVP-TE, ingress unicast replication), or if this P-multicast tree aggregates multiple segments (irrespective of the multicast control protocol used to create the tree), then it is also necessary to use Leaf A-D routes. The precise conditions under which Leaf A-D routes need to be used are described in subsequent sections.

AS間トンネルの特定のAS ASセグメントとして機能するP-Multicastツリーは、レシーバー開始結合(MLDP、PIMバリアントなど)、およびこのP-Multicastツリーを使用するマルチキャスト制御プロトコルによって作成されている場合複数のセグメントを集約しないでください。その後、そのセグメントを作成するために必要なすべての情報は、INTER-AS I-PMSI A-DルートのPMSIトンネル属性に存在します。ただし、セグメントとして機能するP-Multicastツリーが、受信機が開始した結合を使用しないプロトコル(たとえば、RSVP-TE、Ingress Unicast Replication)によって作成されている場合、またはこのP-Multicastツリーが複数のセグメントを集計する場合ツリーの作成に使用されるマルチキャスト制御プロトコルのうち、Leaf A-Dルートを使用する必要もあります。葉のA-Dルートを使用する必要がある正確な条件については、後続のセクションで説明します。

Since (aggregated) Inter-AS I-PMSI A-D routes could have granularity of <AS, MVPN>, an MVPN that is present in N ASes could have a total of N inter-AS tunnels. Thus, for a given MVPN, the number of inter-AS tunnels constituting the I-PMSIs is independent of the number of PEs that have this MVPN.

I-PMSI a-Dルートとしての(集約)inter-as as <as、mvpn>の粒度を持つ可能性があるため、n asesに存在するmvpnは合計n in inter-as tunnelを持つことができます。したがって、特定のMVPNの場合、I-PMSISを構成するトンネル間のインター数は、このMVPNを持っているPEの数とは無関係です。

The precise rules for distributing and processing the Inter-AS I-PMSI A-D routes across ASes are given in the following sections.

ASを横切るI-PMSI A-Dルートとしての分布と処理のための正確なルールは、次のセクションに記載されています。

9.2.3.2. Inter-AS I-PMSI A-D Route Received via EBGP
9.2.3.2. EBGPを介して受信したI-PMSI A-DルートをAS IPS-PMSI A-Dルート

When an ASBR receives, from one of its EBGP neighbors, a BGP Update message that carries an Inter-AS I-PMSI A-D route, if (a) at least one of the Route Targets carried in the message matches one of the import Route Targets configured on the ASBR, and (b) the ASBR determines that the received route is the best route for its NLRI, the ASBR re-advertises this route to other PEs and ASBRs within its own AS (handling of this route by other PEs and ASBRs is described in Section 9.2.3.4).

ASBRがEBGP近隣の1つから受信すると、INTER-AS I-PMSI A-Dルートを搭載したBGP更新メッセージが、(a)メッセージに掲載されたルートターゲットの少なくとも1つが、インポートルートターゲットの1つと一致する場合ASBRで構成されており、(b)ASBRは、受信ルートがNLRIに最適なルートであると判断し、ASBRはこのルートを独自の他のPESおよびASBRに再告発します(他のPESおよびASBRによるこのルートの処理セクション9.2.3.4で説明されています)。

When re-advertising an Inter-AS I-PMSI A-D route, the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR.

I-PMSI A-Dルートを再承認するとき、ASBRはMP_REACH_NLRI属性の次のホップフィールドをASBRのルーティング可能なIPアドレスに設定する必要があります。

If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute, then, depending on the technology used to instantiate the intra-AS segment of the inter-AS tunnel, the ASBR constructs the PMSI Tunnel attribute of the re-advertised Inter-AS I-PMSI A-D route as follows.

受信したINTER-AS I-PMSI A-DルートがPMSIトンネル属性を運ぶ場合、ASBRが再版画のPMSIトンネル属性を構築するために、ASBRはAS Inter-ASトンネルのセグメントをインスタンス化するために使用される技術に応じて運ばれた場合次のように、I-PMSI A-DルートをAS I-PMSI A-Dルート。

+ If the ASBR uses ingress replication for the intra-AS segment of the inter-AS tunnel, the re-advertised route MUST carry the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, but no MPLS labels.

+ ASBRがトンネル間トンネルのセグメント内に侵入レプリケーションを使用している場合、再承認されたルートは、PMSIトンネル属性を、複製を侵入するために設定されたが、MPLSラベルはありません。

+ If the ASBR uses a P-multicast tree for the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree (note that the ASBR could create the identity of the tree prior to the actual instantiation of the tree). If, in order to instantiate the tree, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the Leaf A-D routes received from other PEs/ASBRs in the ASBR's own AS (as described in Section 9.2.3.5) by setting the Leaf Information Required flag in the PMSI Tunnel attribute to 1.

+ ASBRがトンネル間トンネルのセグメント内にP-Multicastツリーを使用している場合、PMSIトンネル属性にはツリーのアイデンティティが含まれている必要があります(ASBRは実際のインスタンスの前にツリーのアイデンティティを作成できることに注意してください木の)。ツリーをインスタンス化するために、ASBRがツリーの葉を知る必要がある場合、ASBRはASBR自身の他のPES/ASBRから受け取ったLeaf A-Dルートからこの情報を取得します(セクション9.2.3.5で説明されています。)PMSIトンネル属性に必要なフラグを葉情報に設定することにより、

+ An ASBR that uses a P-multicast tree as the intra-AS segment of the inter-AS tunnel MAY aggregate two or more MVPNs present on the ASBR onto the same tree. In this case, in addition to the identity of the tree, the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route MUST carry an MPLS upstream-assigned label that the PE has bound uniquely to the MVPN associated with this route (as determined by its RTs).

+ P-Multicast TreeをAS Inter-As-ASトンネルのセグメントとして使用するASBRは、ASBRに存在する2つ以上のMVPNを同じツリーに集約できます。この場合、ツリーのアイデンティティに加えて、INTER-AS I-PMSI A-DルートのPMSIトンネル属性は、PEがこのルートに関連付けられたMVPNに一意に結合しているMPLSアップストリーム割り当てラベルを運ぶ必要があります(RTSによって決定されます)。

If the ASBR has already advertised Inter-AS I-PMSI A-D routes for two or more MVPNs that it now desires to aggregate, then the ASBR MUST re-advertise those routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute and the MVPN label.

ASBRが、現在集計したい2つ以上のMVPNのI-PMSI A-Dルートとして既に宣伝している場合、ASBRはそれらのルートを再承認する必要があります。再承認されたルートは、PMSIトンネル属性とMVPNラベルを除き、元のルートと同じでなければなりません。

9.2.3.2.1. Originating Leaf A-D Route into EBGP
9.2.3.2.1. BGPへの葉A-D-Dルートの発生

In addition, the ASBR MUST send to the EBGP neighbor from whom it received the Inter-AS I-PMSI A-D route, a BGP Update message that carries a Leaf A-D route constructed as follows.

さらに、ASBRは、次のように構築されたリーフA-Dルートを運ぶBGP更新メッセージであるInter-As I-PMSI A-Dルートを受け取ったEBGP隣人に送信する必要があります。

+ The route carries a single MCAST-VPN NLRI with the Route Key field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route received from that neighbor and the Originating Router's IP address set to the IP address of the ASBR (this MUST be a routable IP address).

+ ルートには、その隣人から受信されたI-PMSI A-DルートとしてのMCAST-VPN NLRIに設定されたルートキーフィールドと、ASBRのIPアドレスに設定されているRouterのIPアドレスに設定されたI-PMSI A-Dルートの単一のMCAST-VPN NLRIを搭載しています(これはルーティング可能なIPアドレスである必要があります)。

+ The Leaf A-D route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication and the Tunnel Identifier set to a routable address of the advertising router. The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used by the advertising router to demultiplex the MVPN traffic received over a unicast tunnel from the EBGP neighbor.

+ Leaf A-Dルートには、PMSIトンネル属性を、レプリケーションを侵入するためのトンネルタイプに設定されたトンネル識別子と、広告ルーターのルーティング可能なアドレスに設定されたトンネル識別子を含める必要があります。PMSIトンネル属性は、AdvertisingルーターがEBGP隣人からユニキャストトンネルを介して受け取ったMVPNトラフィックを非難するために使用する下流で割り当てられたMPLSラベルを搭載する必要があります。

+ The ASBR constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received Inter-AS I-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0 and setting the Extended Communities attribute of the Leaf A-D route to that Community. Note that this Route Target is the same as the ASBR Import RT of the EBGP neighbor from which the ASBR received the Inter-AS I-PMSI A-D route.

+ ASBRは、このコミュニティセットのローカル管理者フィールドを使用して、コミュニティのグローバル管理者フィールドにある、受信したINTER-AS INTER AS I-PMSI A-Dルートの次のホップに配置されたIPアドレスを配置することにより、IPベースのルートターゲット拡張コミュニティを構築します。0に、そのコミュニティへのリーフA-Dルートの拡張コミュニティ属性を設定します。このルートターゲットは、ASBRがINTER-AS I-PMSI A-Dルートを受け取ったEBGP隣接のASBRインポートRTと同じであることに注意してください。

+ The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field of the route.

+ ルートのMP_REACH_NLRI属性の次のホップフィールドは、ルートの元のルーターのIPアドレスフィールドで運ばれたものと同じIPアドレスに設定する必要があります。

+ To constrain the distribution scope of this route, the route MUST carry the NO_ADVERTISE BGP Community [RFC1997].

+ このルートの分布範囲を制約するには、ルートはNO_Advertise BGPコミュニティ[RFC1997]を運ぶ必要があります。

Handling of this Leaf A-D route by the EBGP neighbor is described in Section 9.2.3.3.

EBGP隣人によるこのリーフA-Dルートの取り扱いについては、セクション9.2.3.3で説明しています。

The ASBR MUST set up its forwarding state such that packets that arrive on the one-hop ASBR-ASBR LSP, as specified in the PMSI Tunnel attribute of the Leaf A-D route, are transmitted on the intra-AS segment, as specified in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route that the ASBR re-advertises in its own AS. However, the packets MAY be filtered before forwarding, as specified in Section 9.2.3.6.

ASBRは、Leaf A-DルートのPMSIトンネル属性で指定されているように、ワンホップASBR-ASBR LSPに到着するパケットがPMSIで指定されているように、セグメント内に送信されるように、転送状態を設定する必要があります。ASBRが独自のASで再告発するI-PMSI A-Dルートのトンネル属性。ただし、セクション9.2.3.6で指定されているように、転送前にパケットをフィルタリングできます。

9.2.3.3. Leaf A-D Route Received via EBGP
9.2.3.3. BGPを介して受信したリーフA-N-Dルート

When an ASBR receives, via EBGP, a Leaf A-D route originated by its neighbor ASBR, if the Route Target carried in the Extended Communities attribute of the route matches one of the ASBR Import RT (auto-)configured on the ASBR, the ASBR performs the following.

ASBRがEBGPを介して隣接するASBRから発生するリーフA-Dルートを受信すると、ルートの拡張コミュニティ属性にターゲットが携帯されている場合、ASBRで構成されたASBRインポートRT(自動)の1つが一致する場合、ASBRはASBRを実行します。以下。

+ The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has the same value as the Route Key field of the Leaf A-D route.

+ ASBRは、MCAST-VPN NLRIがLeaf A-Dルートのルートキーフィールドと同じ値を持っているI-PMSI A-Dルートを見つけます。

+ If the found Inter-AS I-PMSI A-D route was originated by ASBR itself, then the ASBR sets up its forwarding state such that packets received on the intra-AS tunnels originating in the ASBR's own AS are transmitted on the one-hop ASBR-ASBR LSP specified by

+ 発見されたINTER-AS I-PMSI A-DルートがASBR自体によって発生した場合、ASBRはその転送状態を設定し、1ホップのASBR-に送信されるASBR自身のアスブラルで受信されたパケットを受け取ったパケットを設定します。によって指定されたASBR LSP

the MPLS label carried in the PMSI Tunnel attribute of the received Leaf A-D route. (However, the packets MAY be filtered before transmission as specified in Section 9.2.3.6). The intra-AS tunnels are specified in the PMSI Tunnel attribute of all the Intra-AS I-PMSI A-D routes received by the ASBR that the ASBR aggregated into the Inter-AS I-PMSI A-D route. For each of these intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI Tunnel attribute (i.e., aggregation is used), then only packets received on the inner LSP corresponding to that label MUST be forwarded, not the packets received on the outer LSP, as the outer LSP possibly carries the traffic of other VPNs.

MPLSラベルは、受信したLeaf A-DルートのPMSIトンネル属性に搭載されています。(ただし、セクション9.2.3.6で指定されているように、送信前にパケットをフィルター処理できます)。AS-ASトンネルは、ASBRがINTER-AS I-PMSI A-Dルートに集約したASBRが受け取ったすべてのIPMSI A-DルートのPMSIトンネル属性で指定されています。これらの各トンネル内では、非ゼロMPLSラベルがPMSIトンネル属性(つまり、集約が使用されます)に運ばれている場合、そのラベルに対応する内側のLSPで受信したパケットのみが、パケットではなく転送する必要があります。外側のLSPは他のVPNのトラフィックを運ぶ可能性があるため、外側のLSPで受信します。

+ If the found Inter-AS I-PMSI A-D route was originated by some other ASBR, then the ASBR sets up its forwarding state such that packets received on the intra-AS tunnel segment, as specified in the PMSI Tunnel attribute of the found Inter-AS I-PMSI A-D route, are transmitted on the one-hop ASBR-ASBR LSP, as specified by the MPLS label carried in the PMSI Tunnel attribute of the Leaf A-D route.

+ 見つかったINTER-AS I-PMSI A-Dルートが他のASBRから発信された場合、ASBRは、発見されたインターインターインターインターインターのPMSIトンネル属性で指定されているように、トンネル内セグメントで受信されたパケットが受信されるように転送状態を設定します。I-PMSI A-Dルートと同様に、Leaf A-DルートのPMSIトンネル属性に運ばれるMPLSラベルで指定されているように、ワンホップASBR-ASBR LSPに送信されます。

9.2.3.4. Inter-AS I-PMSI A-D Route Received via IBGP
9.2.3.4. INTER-AS I-PMSI A-DルートIBGPを介して受信しました

In the context of this section, we use the term "PE/ASBR router" to denote either a PE or an ASBR router.

このセクションのコンテキストでは、「PE/ASBRルーター」という用語を使用して、PEまたはASBRルーターのいずれかを示します。

If a given Inter-AS I-PMSI A-D route is received via IBGP by a BGP route reflector, the BGP route reflector MUST NOT modify the Next Hop field of the MP_REACH_NLRI attribute when re-advertising the route into IBGP (this is because the information carried in the Next Hop is used for controlling flow of C-multicast routes, as specified in Section 11.2).

特定のINTER-AS I-PMSI A-DルートがBGPルートリフレクターによってIBGPを介して受信された場合、BGPルートリフレクターは、ルートをIBGPに再評価するときにMP_REACH_NLRI属性の次のホップフィールドを変更してはなりません(これは、情報が情報のためです。次のホップで運ばれるのは、セクション11.2で指定されているように、Cマルチキャストルートの流れを制御するために使用されます。

If a given Inter-AS I-PMSI A-D route is advertised within an AS by multiple ASBRs of that AS, the BGP best route selection performed by other PE/ASBR routers within the AS does not require all these PE/ASBR routers to select the route advertised by the same ASBR -- to the contrary, different PE/ASBR routers may select routes advertised by different ASBRs.

与えられたINTER-AS I-PMSI A-DルートがそのASの複数のASBRによって宣伝されている場合、AS内の他のPE/ASBRルーターによって実行されるBGPベストルート選択は、これらすべてのPE/ASBRルーターを選択する必要はありません。同じasbrによって宣伝されているルート - 反対に、異なるPE/ASBRルーターは、異なるASBRによって宣伝されているルートを選択する場合があります。

When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP Update message that carries an Inter-AS I-PMSI A-D route, if (a) at least one of the Route Targets carried in the message matches one of the import Route Targets configured on the PE/ASBR, and (b) the PE/ASBR determines that the received route is the best route to the destination carried in the NLRI of the route, the PE/ASBR performs the following operations.

PE/ASBRルーターがIBGP近隣の1つから受信すると、IPMSIがI-PMSI A-Dルートを扱うBGP更新メッセージを受け取ると、(a)メッセージに掲載されたルートターゲットの少なくとも1つが1つに一致する場合、PE/ASBRで構成されたルートターゲットをインポートし、(b)PE/ASBRは、受信ルートがルートのNLRIで運ばれる目的地への最適なルートであると判断し、PE/ASBRは次の操作を実行します。

+ If the router is a PE, then the router imports the route into the VRF(s) that have the matching import Route Targets.

+ ルーターがPEの場合、ルーターはルートをVRFにインポートし、一致するインポートルートターゲットを備えています。

+ If the router is an ASBR, then the ASBR propagates the route to its EBGP neighbors. When propagating the route to the EBGP neighbors, the ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a routable IP address of the ASBR. If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute, then the propagated route MUST carry the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication; the attribute carries no MPLS labels.

+ ルーターがASBRである場合、ASBRはEBGPの隣人へのルートを伝播します。EBGPネイバーへのルートを伝播する場合、ASBRはMP_REACH_NLRI属性の次のホップフィールドをASBRのルーティング可能なIPアドレスに設定する必要があります。受信したINTER-AS I-PMSI A-DルートがPMSIトンネル属性を運ぶ場合、伝播されたルートは、複製を侵入するためにトンネルタイプを設定してPMSIトンネル属性を運ぶ必要があります。属性にはMPLSラベルが含まれていません。

+ If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM tree, the PE/ASBR SHOULD join as soon as possible the P-multicast tree whose identity is carried in the Tunnel Identifier.

+ 受信したINTER-AS I-PMSI A-Dルートが、MLDP P2MP LSP、PIM-SSMツリー、PIM-SMツリー、またはBidir-PIMツリーに設定されたトンネルタイプを使用してPMSIトンネル属性を搭載している場合、PE/ASBRはすぐに結合する必要があります。可能な限り、そのアイデンティティがトンネル識別子に運ばれているP-Multicastツリー。

+ If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSP MAY have been established before the local PE/ASBR receives the route, or it MAY be established after the local PE receives the route.

+ 受信したINTER-AS I-PMSI A-DルートがPMSIトンネル属性をRSVP-TE P2MP LSPに設定したトンネル識別子を搭載している場合、ルートを発信したASBRは、ローカルPE/ASBRとしてRSVP-TE P2MP LSPを確立する必要があります。葉。このLSPは、ローカルPE/ASBRがルートを受信する前に確立された可能性があります。または、ローカルPEがルートを受け取った後に確立される場合があります。

+ If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to mLDP P2MP LSP, RSVP-TE P2MP LSP, PIM-SSM, PIM-SM tree, or BIDIR-PIM tree, but the attribute does not carry a label, then the P-multicast tree, as identified by the PMSI Tunnel attribute, is an intra-AS LSP segment that is part of the inter-AS tunnel for the MVPN advertised by the Inter-AS I-PMSI A-D route and rooted at the AS that originated the Inter-AS I-PMSI A-D route. If the PMSI Tunnel attribute carries a (upstream-assigned) label, then a combination of this tree and the label identifies the intra-AS segment. If the receiving router is an ASBR, this intra-AS segment may further be stitched to the ASBR-ASBR inter-AS segment of the inter-AS tunnel. If the PE/ASBR has local receivers in the MVPN, packets received over the intra-AS segment must be forwarded to the local receivers using the local VRF.

+ 受信したINTER-AS I-PMSI A-DルートがPMSIトンネル属性をMLDP P2MP LSP、RSVP-TE P2MP LSP、PIM-SSM、PIM-SMツリー、またはBidir-PIMツリーに設定してPMSIトンネル属性を運ぶ場合、属性PMSIトンネル属性によって識別されるように、P-Multicastツリーはラベルを持ちません。PMSIトンネル属性によって識別されるように、I-PMSI AS I-PMSI A-Dによって宣伝されているMVPNのトンネル間トンネルの一部であるLSPセグメント内です。ルートとルート化されたASに根付いたのは、INTER-IPMSI A-Dルートを発生しました。PMSIトンネル属性が(上流で割り当てられた)ラベルを持っている場合、このツリーとラベルの組み合わせがセグメント内を識別します。受信ルーターがASBRである場合、このセグメント内は、ASBR-ASBR AS Inter-ASトンネルのセグメントにさらにステッチされる可能性があります。PE/ASBRがMVPNにローカルレシーバーを持っている場合、AS Intra-ASセグメントで受信したパケットは、ローカルVRFを使用してローカルレシーバーに転送する必要があります。

9.2.3.4.1. Originating Leaf A-D Route into IBGP
9.2.3.4.1. IBGPへの葉a-Dルートの発生

If the Leaf Information Required flag in the PMSI Tunnel attribute of the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR MUST originate a new Leaf A-D route as follows.

リーフ情報が、受信したINTER-AS I-PMSI A-DルートのPMSIトンネル属性のフラグが1に設定されている場合、PE/ASBRは次のように新しいリーフA-Dルートを発信する必要があります。

+ The route carries a single MCAST-VPN NLRI with the Route Key field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route received from that neighbor and the Originating Router's IP address set to the IP address of the PE/ASBR (this MUST be a routable IP address).

+ ルートには、その隣人から受信されたI-PMSI A-DルートのMAST-VPN NLRIに設定されたルートキーフィールドと、PE/のIPアドレスに設定されているRouterのIPアドレスを設定したI-PMSI A-Dルートとしてのルートキーフィールドを備えた単一のMCAST-VPN NLRIが搭載されています。ASBR(これはルーティング可能なIPアドレスである必要があります)。

+ If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, then the Leaf A-D route MUST carry the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication. The Tunnel Identifier MUST carry a routable address of the PE/ASBR. The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used to demultiplex the MVPN traffic received over a unicast tunnel by the PE/ASBR.

+ 受信したINTER-AS I-PMSI A-DルートがPMSIトンネル属性を複製に浸すように設定されたトンネルタイプを搭載している場合、Leaf A-Dルートは、PMSIトンネル属性を、トンネルタイプを設定して複製に設定する必要があります。トンネル識別子は、PE/ASBRのルーティング可能なアドレスを搭載する必要があります。PMSIトンネル属性は、PE/ASBRによってユニキャストトンネルを介して受け取ったMVPNトラフィックを非難するために使用されるダウンストリーム割り当てのMPLSラベルを運ぶ必要があります。

+ The PE/ASBR constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received Inter-AS I-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0 and setting the Extended Communities attribute of the Leaf A-D route to that Community.

+ PE/ASBRは、Communityのグローバル管理者フィールドで受信したI-PMSI A-Dルートの次のホップに運ばれたIPアドレスを配置することにより、IPベースのルートターゲット拡張コミュニティを構築します。コミュニティは0に設定され、そのコミュニティへのリーフA-Dルートの拡張コミュニティ属性を設定します。

+ The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field of the route.

+ ルートのMP_REACH_NLRI属性の次のホップフィールドは、ルートの元のルーターのIPアドレスフィールドで運ばれたものと同じIPアドレスに設定する必要があります。

+ To constrain the distribution scope of this route, the route MUST carry the NO_EXPORT Community [RFC1997].

+ このルートの分布範囲を制約するには、ルートはNO_Exportコミュニティ[RFC1997]を運ぶ必要があります。

+ Once the Leaf A-D route is constructed, the PE/ASBR advertises this route into IBGP.

+ リーフA-Dルートが構築されると、PE/ASBRはこのルートをIBGPに宣伝します。

9.2.3.5. Leaf A-D Route Received via IBGP
9.2.3.5. IBGPを介して受信したリーフA-Dルート

When an ASBR receives, via IBGP, a Leaf A-D route, if the Route Target carried in the Extended Communities attribute of the route matches one of the ASBR Import RT (auto-)configured on the ASBR, the ASBR performs the following.

ASBRがIBGPを介してLeaf A-Dルートを受信すると、ルートの拡張コミュニティ属性に携帯されているルートターゲットがASBRで構成されたASBRインポートRT(Auto-)の1つと一致する場合、ASBRはASBRを実行します。

The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has the same value as the Route Key field of the Leaf A-D route.

ASBRは、MCAST-VPN NLRIがLeaf A-Dルートのルートキーフィールドと同じ値を持っているI-PMSI A-Dルートを見つけます。

The received route may carry either (a) no PMSI Tunnel attribute, or (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to Ingress Replication.

受信したルートには、(a)PMSIトンネル属性なし、または(b)PMSIトンネル属性のいずれかを搭載する場合がありますが、複製を侵入するために設定されたトンネルタイプのみを使用できます。

If the received route does not carry the PMSI Tunnel attribute, the ASBR uses the information from the received route to determine the leaves of the P-multicast tree rooted at the ASBR that would be used for the intra-AS segment associated with the found Inter-AS I-PMSI A-D route. The IP address of a leaf is the IP address carried in the Originating Router's IP address field of the received Leaf A-D route.

受信したルートがPMSIトンネル属性を搭載していない場合、ASBRは受信したルートから情報を使用して、発見されたInterに関連付けられたAS Intra-As ASセグメントに使用されるASBRに根付いたPマルチカストツリーの葉を決定します。-PMSI A-Dルートとして。リーフのIPアドレスは、受信した葉のA-Dルートの発信元ルーターのIPアドレスフィールドに運ばれるIPアドレスです。

If the received route carries the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication, the ASBR uses the information carried by the route to construct the intra-AS segment with ingress replication.

受信したルートが、複製を侵入するために設定されたトンネルタイプを使用してPMSIトンネル属性を搭載している場合、ASBRはルートによって運ばれる情報を使用して、イングレスレプリケーションでセグメント内を構築します。

9.2.3.6. Optimizing Bandwidth by IP Filtering on ASBRs
9.2.3.6. ASBRのIPフィルタリングにより帯域幅を最適化します

An ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some of the traffic carried in the tunnel specified in the PMSI Tunnel attribute of this route, if the ASBR determines that there are no downstream receivers for that traffic.

I-PMSI A-Dルートとしての特定のInter-asを持つASBRは、ASBRがそのトラフィックの下流レシーバーがないと判断した場合、このルートのPMSIトンネル属性で指定されたトンネルで運ばれるトラフィックの一部を破棄する場合があります。

When BGP is being used to distribute C-multicast routes, an ASBR that has a given Inter-AS I-PMSI A-D route MAY discard traffic from a particular customer multicast source C-S and destined to a particular customer multicast group address C-G that is carried over the tunnel specified in the PMSI Tunnel attribute of the route, if none of the C-multicast routes on the ASBR with RD and Source AS being the same as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the (C-S,C-G) tuple. A C-multicast route is said to match a (C-S,C-G) tuple, if it is a Source Tree Join route with Multicast Source set to C-S and Multicast Group set to C-G or a Shared Tree Join route with Multicast Group set to C-G.

BGPがC-Multicastルートを配布するために使用されている場合、特定のI-PMSI A-Dルートを備えたASBRは、特定の顧客マルチキャストソースC-Sからトラフィックを破棄し、特定の顧客マルチキャストグループアドレスC-Gに運命づけられている可能性があります。ルートのPMSIトンネル属性で指定されたトンネルは、RDを備えたASBRのCマルチキャストルートがいない場合、I-PMSI A-Dルートと同じようにRDおよびソースと同じであるとソースがRDとソースと同じである場合(c-s、c-g)タプル。C-Multicastルートは、C-Sに設定されたマルチキャストソースセットを備えたソースツリー結合ルートである場合、C-Gまたは共有ツリー結合ツリー結合ルートをC-Gに設定した場合、(C-S、C-G)タプルに一致すると言われています。

The above procedures MAY also apply to an ASBR that originates a given Inter-AS I-PMSI A-D route. In this case, the ASBR applies them to the traffic carried over the tunnels specified in the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates into the Inter-AS I-PMSI A-D route and whose tails are stitched to the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D route.

上記の手順は、特定のI-PMSI A-Dルートを発信するASBRにも適用される場合があります。この場合、ASBRは、ASBRがINTER-AS I-PMSI A-Dルートに凝集し、その尾が縫合されるIPMSI A-DルートのPMSIトンネル属性で指定されたトンネルを運ぶトラフィックにそれらを適用します。Inter-As-PMSI A-Dルートで指定されたワンホップASBR-ASBRトンネルへ。

10. Non-Congruent Unicast and Multicast Connectivity
10. 非条件のユニキャストおよびマルチキャスト接続

It is possible to deploy MVPN such that the multicast routing and the unicast routing are "non-congruent". For instance, the CEs may be distributing to the PEs a special set of unicast routes that are to be used exclusively for the purpose of upstream multicast hop selection, and not used for unicast routing at all. (For example, when BGP is the CE-PE unicast routing protocol, the CEs may be using SAFI 2 ("Network Layer Reachability Information used for multicast

マルチキャストルーティングとユニキャストルーティングが「非次第」になるようにMVPNを展開することができます。たとえば、CESは、上流のマルチキャストホップ選択を目的としてのみ使用されるユニキャストルートの特別なセットであり、ユニキャストルーティングにはまったく使用されないPESに分配されている場合があります。(たとえば、BGPがCE-PEユニキャストルーティングプロトコルである場合、CESはSAFI 2を使用している可能性があります( "マルチキャストに使用されるネットワークレイヤーリーチ可能性情報

forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection.) In such a situation, we will speak of the MVPN as having two VRFs on a given PE: one containing the routes that are used for unicast, the other containing the unicast routes that are used for UMH selection. We will call the former the "unicast routing VRF" and the latter the "UMH VRF" (upstream-multicast-hop VRF).

「[IANA-Safi])を転送し、IPv4またはIPv6 AFIのいずれかで、上流のマルチキャストホップ選択に使用される特別なルートセットを配布します。)このような状況では、MVPNについて話します。特定のPEに2つのVRFがあるとして:1つはユニキャストに使用されるルートを含むもの、もう1つはUMH選択に使用されるユニキャストルートを含む。前者は「ユニキャストルーティングVRF」と呼び、後者は「UMH VRFと呼びます「(Upstream-Multicast-Hop VRF)。

In this document, when we speak without qualification of the MVPN's VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we are speaking of the UMH VRF. (Of course, if there is no separate UMH VRF, then we are speaking of the unicast VRF.)

このドキュメントでは、MVPNのVRFの資格なしに話すとき、MVPNにユニキャストVRFとUMH VRFの両方がある場合、UMH VRFについて話しています。(もちろん、別のUMH VRFがない場合、Unicast VRFについて話しています。)

If there is a separate UMH VRF, it MAY have its own import and export Route Targets, different from the ones used by the unicast VRF. These Route Targets MUST be used to control distribution of auto-discovery routes. In addition, the export Route Targets of the UMH VRF are added to the Route Targets used by the unicast VRF when originating (unicast) VPN-IP routes. The import Route Targets associated with a given UMH VRF are used to determine which of the received (unicast) VPN-IP routes should be accepted into the UMH VRF.

別のUMH VRFがある場合、ユニキャストVRFが使用するものとは異なる独自のインポートおよびエクスポートルートターゲットがある場合があります。これらのルートターゲットは、自動発見ルートの分布を制御するために使用する必要があります。さらに、UMH VRFのエクスポートルートターゲットは、発信(Unicast)VPN-IPルートの際にユニキャストVRFが使用するルートターゲットに追加されます。特定のUMH VRFに関連付けられた輸入ルートターゲットを使用して、受信した(ユニキャスト)VPN-IPルートのどれをUMH VRFに受け入れる必要があるかを決定します。

If a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED that the UMH VRF use the same RD as the one used by the unicast VRF of that MVPN.

PEがそのMVPNのUMH VRFを維持している場合、UMH VRFはそのMVPNのユニキャストVRFが使用したものと同じRDを使用することをお勧めします。

If an MVPN site is multihomed to several PEs, then to support non-congruent unicast and multicast connectivity, on each of these PEs, the UMH VRF of the MVPN MUST use its own distinct RD (although on a given PE, the RD used by the UMH VRF SHOULD be the same as the one used by the unicast VRF).

MVPNサイトがいくつかのPESにマルチホームされている場合、非条件のユニキャストおよびマルチキャスト接続をサポートするために、これらの各PESでは、MVPNのUMH VRFは独自の異なるRDを使用する必要があります(ただし、特定のPEでは、RDは使用されますが、UMH VRFは、Unicast VRFが使用するものと同じでなければなりません。

If an MVPN has a UMH VRF distinct from its unicast VRF, then one option to support non-congruency is to exchange the routes to/from that UMH VRF by using the same AFI/SAFI as used by the routes from the unicast VRF.

MVPNがユニキャストVRFとは異なるUMH VRFを持っている場合、非次回をサポートする1つのオプションは、Unicast VRFのルートで使用されるのと同じAFI/SAFIを使用して、そのUMH VRFとのルートを交換することです。

Another option is to exchange the routes to/from the UMH VRF using the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to SAFI 129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI]. The NLRI carried by these routes is defined as follows:

別のオプションは、IPv4またはIPv6 AFI(必要に応じて)を使用してUMH VRFとの間でルートを交換することですが、SAFIセットを使用してBGP/MPLS IP仮想ネットワーク(VPNS)のマルチキャストに設定します[IANA-Safii]。これらのルートによって運ばれるNLRIは、次のように定義されています。

      +---------------------------+
      |   Length (1 octet)        |
      +---------------------------+
      |   Prefix (variable)       |
      +---------------------------+
        

The use and the meaning of these fields are as follows:

これらのフィールドの使用と意味は次のとおりです。

a) Length:

a) 長さ:

The Length field indicates the length, in bits, of the address prefix.

長さフィールドは、アドレスプレフィックスの長さ、ビット内の長さを示します。

b) Prefix:

b) プレフィックス:

The Prefix field contains a Route Distinguisher as defined in [RFC4364] prepended to an IPv4 or IPv6 address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of trailing bits is irrelevant.

プレフィックスフィールドには、[RFC4364]で定義されているルート違いをIPv4またはIPv6アドレスのプレフィックスに加え、その後、フィールドの終わりをオクテットの境界に該当するのに十分なトレーリングビットが含まれます。トレーリングビットの値は無関係であることに注意してください。

These routes MUST carry the VRF Route Import Extended Community. If, for a given MVPN, BGP is used for exchanging C-multicast routes, or if segmented inter-AS tunnels are used, then these routes MUST also carry the Source AS Extended Community.

これらのルートは、VRFルートインポート拡張コミュニティを運ぶ必要があります。特定のMVPNに対して、BGPがCマルチキャストルートの交換に使用される場合、またはセグメント化されたトンネルを使用する場合、これらのルートも拡張コミュニティとしてソースを運ぶ必要があります。

The detailed procedures for selecting forwarder PE in the presence of such routes are outside the scope of this document. However, this document requires these procedures to preserve the constraints imposed by the single forwarder PE selection procedures, as specified in [MVPN].

このようなルートの存在下でフォワーダーPEを選択するための詳細な手順は、このドキュメントの範囲外です。ただし、このドキュメントでは、[MVPN]で指定されているように、単一のフォワーダーPE選択手順によって課される制約を保持するために、これらの手順が必要です。

11. Exchange of C-Multicast Routing Information among PEs
11. PES間のCマルチキャストルーティング情報の交換

VPN C-Multicast Routing Information is exchanged among PEs by using C-multicast routes that are carried using an MCAST-VPN NLRI. These routes are originated and propagated as follows.

VPN C-Multicastルーティング情報は、MCAST-VPN NLRIを使用して運ばれるC-Multicastルートを使用してPES間で交換されます。これらのルートは、次のように発信され、伝播されます。

11.1. Originating C-Multicast Routes by a PE
11.1. PEによるC-Multicastルートの発生

Part of the procedures for constructing MCAST-VPN NLRI depends on the multicast routing protocol between CE and PE (C-multicast protocol).

MCAST-VPN NLRIを構築する手順の一部は、CEとPE(C-Multicastプロトコル)の間のマルチキャストルーティングプロトコルに依存します。

11.1.1. Originating Routes: PIM as the C-Multicast Protocol
11.1.1. 発信ルート:C-MulticastプロトコルとしてのPIM

The following specifies the construction of MCAST-VPN NLRI of C-multicast routes for the case where the C-multicast protocol is PIM. These C-multicast routes are originated as a result of updates in the (C-S,C-G), or (C-*,C-G) state learned by a PE via the C-multicast protocol.

以下は、C-MulticastプロトコルがPIMである場合のC-MulticastルートのMCAST-VPN NLRIの構築を指定しています。これらのCマルチキャストルートは、(c-s、c-g)、または(c - *、c-g)の更新の結果として発信されます。C-Multicastプロトコルを介してPEによって学習されました。

Note that creation and deletion of (C-S,C-G,rpt) states on a PE when the C-multicast protocol is PIM do not result in any BGP actions.

C-MulticastプロトコルがPIMである場合、(C-S、C-G、RPT)の作成と削除は、BGPアクションにつながらない場合にPEに記載されていることに注意してください。

11.1.1.1. Originating Source Tree Join C-Multicast Route
11.1.1.1. ソースツリーはC-Multicastルートに結合します

Whenever (a) a C-PIM instance on a particular PE creates a new (C-S,C-G) state, and (b) the selected upstream PE for C-S (see [MVPN]) is not the local PE, then the local PE MUST originate a C-multicast route of type Source Tree Join. The Multicast Source field in the MCAST-VPN NLRI of the route is set to C-S; the Multicast Group field is set of C-G.

(a)特定のPEのC-PIMインスタンスが新しい(C-S、C-G)状態を作成する場合はいつでも、(b)C-Sの選択された上流のPE([MVPN]を参照)はローカルPEではありません。タイプソースツリー結合のCマルチキャストルートを発信します。ルートのMCAST-VPN NLRIのマルチキャストソースフィールドは、C-Sに設定されています。マルチキャストグループフィールドはC-Gのセットです。

This C-multicast route is said to "correspond" to the C-PIM (C-S,C-G) state.

このC-Multicastルートは、C-PIM(C-S、C-G)状態に「対応」すると言われています。

The semantics of the route are such that the PE has one or more receivers for (C-S,C-G) in the sites connected to the PE (the route has the (C-S,C-G) Join semantics).

ルートのセマンティクスは、PEにPE(ルートには(C-S、C-G)結合セマンティクスがある)に接続されたサイトに(C-S、C-G)の1つ以上の受信機を持っているようなものです。

Whenever a C-PIM instance on a particular PE deletes a (C-S,C-G) state, the corresponding C-multicast route MUST be withdrawn. (The withdrawal of the route has the (C-S,C-G) Prune semantics). The MCAST-VPN NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI attribute.

特定のPE上のC-PIMインスタンスが(C-S、C-G)状態を削除する場合はいつでも、対応するCマルチカストルートを取り下げる必要があります。(ルートの撤回には(C-S、C-G)プルーンセマンティクスがあります)。撤回されたルートのmcast-vpn nlriは、mp_unreach_nlri属性で運ばれます。

11.1.1.2. Originating Shared Tree Join C-Multicast Route
11.1.1.2. 発生する共有ツリーはC-Multicastルートに参加します

Whenever (a) a C-PIM instance on a particular PE creates a new (C-*,C-G) state, and (b) the selected upstream PE for the C-RP corresponding to the C-G (see [MVPN]) is not the local PE, then the local PE MUST originate a C-multicast route of type Shared Tree Join. The Multicast Source field in the MCAST-VPN NLRI of the route is set to the C-RP address. The Multicast Group field in the MCAST-VPN NLRI is set to the C-G address.

(a)特定のPEのC-PIMインスタンスが新しい(c-*、c-g)状態を作成し、(b)C-gに対応するC-RPの選択された上流のPE([MVPN]を参照)はそうではありません。ローカルPE、次に、ローカルPEは、タイプ共有ツリー結合のCマルチキャストルートを発生する必要があります。ルートのMCAST-VPN NLRIのマルチキャストソースフィールドは、C-RPアドレスに設定されています。MCAST-VPN NLRIのマルチキャストグループフィールドは、C-Gアドレスに設定されています。

This C-multicast route is said to "correspond" to the C-PIM (C-*,C-G) state.

このC-Multicastルートは、C-PIM(C-*、C-G)状態に「対応」と言われています。

The semantics of the route are such that the PE has one or more receivers for (C-*,C-G) in the sites connected to the PE (the route has the (C-*,C-G) Join semantics).

ルートのセマンティクスは、PEにPEに接続されたサイトに(c - *、c-g)の1つ以上の受信機が(c - *、c-g)semanticsに結合されているようなものです。

Whenever a C-PIM instance on a particular PE deletes a (C-*,C-G) state, the corresponding C-multicast route MUST be withdrawn. (The withdrawal of the route has the (C-S,C-G) Prune semantics). The MCAST-VPN NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI attribute.

特定のPE上のC-PIMインスタンスが(c - *、c-g)状態を削除する場合はいつでも、対応するCマルチキャストルートを取り下げる必要があります。(ルートの撤回には(C-S、C-G)プルーンセマンティクスがあります)。撤回されたルートのmcast-vpn nlriは、mp_unreach_nlri属性で運ばれます。

11.1.2. Originating Routes: mLDP as the C-Multicast Protocol
11.1.2. 発信ルート:C-MulticastプロトコルとしてのMLDP

The following specifies the construction of the MCAST-VPN NLRI of C-multicast routes for the case where the C-multicast protocol is mLDP [mLDP].

以下は、C-MulticastプロトコルがMLDP [MLDP]である場合のC-MulticastルートのMCAST-VPN NLRIの構築を指定しています。

Whenever a PE receives, from one of its CEs, 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 checks whether it already has state for <X, Y> in the VRF associated with the CE. If so, then all the PE needs to do in this case is to update its forwarding state by adding <I, L> to the forwarding state associated with <X, Y>.

PEがCESの1つから受信するたびに、P2MPラベルマップ<x、y、l>インターフェイスI、ここで、xはルートノードアドレス、yは不透明な値、lはmplsラベルであるPEチェックCEに関連付けられたVRFに<x、y>の状態が既にあるかどうか。もしそうなら、この場合、すべてのPEは、<x、y>に関連付けられた転送状態に<i、l>を追加することにより、転送状態を更新することです。

If the PE does not have state for <X, Y> in the VRF associated with the CE, then 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に関連付けられたVRFの<x、y>の状態を持っていない場合、PEは、MCAST-VPN NLRIがマルチキャストソースフィールドとしてxを含むc-Multicastルートを結合し、yを、yとしてc-Multicastルートを結合します。マルチキャストグループフィールド。

Whenever a PE deletes a previously created <X, Y> state that had resulted in originating a C-multicast route, the PE withdraws the C-multicast route. The MCAST-VPN NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI attribute.

PEがC-Multicastルートを発信した以前に作成された<X、Y>状態を削除するたびに、PEはCマルチキャストルートを撤回します。撤回されたルートのmcast-vpn nlriは、mp_unreach_nlri属性で運ばれます。

11.1.3. Constructing the Rest of the C-Multicast Route
11.1.3. C-Multicastルートの残りの部分を構築します

The rest of the C-multicast route is constructed as follows (the same procedures apply to both PIM and mLDP as the C-Multicast protocol).

C-Multicastルートの残りの部分は、次のように構築されます(C-Multicastプロトコルと同じ手順とMLDPの両方に適用されます)。

The local PE executes the procedures of [MVPN] to find the selected Upstream Multicast Hop (UMH) route and the selected upstream PE for the address carries in the Multicast Source field of MCAST-VPN NLRI.

ローカルPEは、[MVPN]の手順を実行して、選択したアップストリームマルチキャストホップ(UMH)ルートを見つけ、アドレスの選択したアップストリームPEは、MCAST-VPN NLRIのマルチキャストソースフィールドに伝達されます。

From the selected UMH route, the local PE extracts (a) the ASN of the upstream PE (as carried in the Source AS Extended Community of the route), and (b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route). The Source AS field in the C-multicast route is set to that AS. The Route Target Extended Community of the C-multicast route is set to that C-multicast Import RT.

選択したUMHルートから、ローカルPE抽出物(a)上流のPEのASN(ルートの拡張コミュニティとしてソースで運ばれます)、および(b)上流PEのVRFのc-multicastインポートRT(このC-MulticastインポートRTの値は、ルートで運ばれるVRFルートインポートの拡張コミュニティの値です)。C-Multicastルートのフィールドとしてのソースは、Asに設定されています。C-Multicastルートのルートターゲット拡張コミュニティは、そのCマルチキャストインポートRTに設定されています。

If there is more than one (remote) PE that originates the (unicast) route to the address carried in the Multicast Source field of the MCAST-VPN NLRI, then the procedures for selecting the UMH route and the upstream PE to reach that address are as specified in [MVPN].

MCAST-VPN NLRIのマルチキャストソースフィールドに掲載されたアドレスへの(ユニキャスト)ルートを発信する複数の(リモート)PEがある場合、UMHルートを選択する手順とそのアドレスに到達するためのアップストリームPEを選択する手順は次のとおりです。[MVPN]で指定されているとおり。

If the local and the upstream PEs are in the same AS, then the RD of the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route that contains the address carried in the Multicast Source field.

ローカルと上流のPEが同じである場合、広告されたMCAST-VPN NLRIのRDは、マルチキャストソースフィールドに運ばれるアドレスを含むVPN-IPルートのRDに設定されます。

The C-multicast route is then advertised into IBGP.

C-MulticastルートはIBGPに宣伝されます。

If the local and the upstream PEs are in different ASes, then the local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source AS field carries the ASN of the upstream PE. The RD of the found Inter-AS I-PMSI A-D route is used as the RD of the advertised C-multicast route. The local PE constructs an IP-based Route Target Extended Community by placing the Next Hop of the found Inter-AS I-PMSI A-D route in the Global Administrator field of this Community, with the Local Administrator field of this Community set to 0; it then adds this Community to the Extended Communities attribute of the C-multicast route. (Note that this Route Target is the same as the ASBR Import RT of the ASBR identified by the Next Hop of the found Inter-AS I-PMSI A-D route.)

ローカルと上流のPEが異なるASEにある場合、ローカルPEは、そのソースが上流のPEのASNを運ぶソースをそのvrfでINTER-AS I-PMSI A-Dルートを見つけます。発見されたINTER-AS I-PMSI A-DルートのRDは、広告されたC-MulticastルートのRDとして使用されます。ローカルPEは、このコミュニティのローカル管理者フィールドを0に設定して、このコミュニティのグローバル管理者分野で発見されたINTER-AS I-PMSI A-Dルートの次のホップを配置することにより、IPベースのルートターゲット拡張コミュニティを構築します。次に、このコミュニティをC-Multicastルートの拡張コミュニティ属性に追加します。(このルートターゲットは、発見されたI-PMSI A-Dルートの次のホップによって識別されたASBRのASBRインポートRTと同じであることに注意してください。)

Inter-AS I-PMSI A-D routes are not used to support non-segmented inter-AS tunnels. To support non-segmented inter-AS tunnels, if the local and the upstream PEs are in different ASes, the local system finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE (the Originating Router's IP Address field of that route has the same value as the one carried in the VRF Route Import of the (unicast) route to the address carried in the Multicast Source field). The RD of the found Intra-AS I-PMSI A-D route is used as the RD of the advertised C-multicast route. The Source AS field in the C-multicast route is set to value of the Originating Router's IP Address field of the found Intra-AS I-PMSI A-D route.

INTER-AS I-PMSI A-Dルートは、非セグメント化されたトンネルをサポートするために使用されません。非セグメント化されたトンネルをサポートするために、ローカルと上流のPEが異なるASEにある場合、ローカルシステムは、そのVRFで、上流のPEからのI-PMSI A-Dルート内のI-PMSI A-Dルートを発見します(発信ルーターのIPアドレスフィールドフィールドそのルートは、マルチキャストソースフィールドにあるアドレスへの(ユニキャスト)ルートのVRFルートインポートで運ばれたものと同じ値を持っています)。INTRA-AS I-PMSI A-DルートのRDは、広告されたC-MulticastルートのRDとして使用されます。c-multicastルートのフィールドとしてのソースは、発見されたI-PMSI A-Dルートの発生するルーターのIPアドレスフィールドの値に設定されています。

The Next Hop field of the MP_REACH_NLRI attribute MUST be set to a routable IP address of the local PE.

MP_REACH_NLRI属性の次のホップフィールドは、ローカルPEのルーティング可能なIPアドレスに設定する必要があります。

If the Next Hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route is an EBGP neighbor of the local PE, then the PE advertises the C-multicast route to that neighbor. If the Next Hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route is within the same AS as the local PE, then the PE advertises the C-multicast route into IBGP.

発見された(Inter-ASまたはAS)I-PMSI A-Dルートの次のホップがローカルPEのEBGPネイバーである場合、PEはその隣人へのC-Multicastルートを宣伝します。見つかった(Inter-ASまたはAS)I-PMSI A-Dルートの次のホップがローカルPEと同じ内にある場合、PEはC-MulticastルートをIBGPに宣伝します。

11.1.4. Unicast Route Changes
11.1.4. ユニキャストルートの変更

The particular UMH route that is selected by a given PE for a given C-S may be influenced by the network's unicast routing. In that case, a change in the unicast routing may invalidate prior choices of the UMH route for some C-S. If this happens, the local PE MUST execute the UMH route selection procedures for C-S again. If the

特定のC-Sの特定のPEによって選択される特定のUMHルートは、ネットワークのユニキャストルーティングの影響を受ける可能性があります。その場合、ユニキャストルーティングの変更は、一部のC-SのUMHルートの以前の選択を無効にする可能性があります。これが発生した場合、ローカルPEはC-SのUMHルート選択手順を再度実行する必要があります。場合

result is that a different UMH route is selected, then for all C-G, any previously originated C-multicast routes for (C-S,C-G) MUST be re-originated.

その結果、異なるUMHルートが選択され、その後、すべてのC-gに対して、以前に発生したC-Multicastルート(C-S、C-G)を再起動する必要があります。

Similarly, if a unicast routing change results in a change of the UMH route for a C-RP, then for all C-G such that C-RP is the RP associated with C-G, any previously originated C-multicast routes for (C-*,C-G) MUST be re-originated.

同様に、ユニキャストルーティングの変更がC-RPのUMHルートの変更をもたらす場合、C-RPがC-Gに関連付けられたRPであるすべてのC-Gの場合、以前に発生したC-Multicastルート(C-*、c-g)再起動する必要があります。

11.2. Propagating C-Multicast Routes by an ASBR
11.2. ASBRによるCマルチキャストルートの伝播

When an ASBR receives a BGP Update message that carries a C-multicast route, if at least one of the Route Targets of the route matches one of the ASBR Import RTs (auto-)configured on the ASBR, the ASBR finds an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD and Source AS carried in the C-multicast route. If no matching route is found, the ASBR takes no further action. If a matching route is found, the ASBR proceeds as follows.

ASBRがC-Multicastルートを運ぶBGPアップデートメッセージを受信した場合、ルートのルートターゲットの少なくとも1つがASBRで構成されたASBRインポートRTS(Auto-)の1つと一致する場合、ASBRはASを見つけます。RDとソースがRDとソースと一致するI-PMSI A-DルートとC-Multicastルートで運ばれます。一致するルートが見つからない場合、ASBRはそれ以上のアクションを取りません。一致するルートが見つかった場合、ASBRは次のように進みます。

To support non-segmented inter-AS tunnels, instead of matching the RD and Source AS carried in the C-multicast route against the RD and Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it against the RD and the Originating Router's IP Address of the Intra-AS I-PMSI A-D routes.

I-PMSI A-Dルートの時点で、RDとソースをRDおよびソースに対してC-Multicastルートで運ぶものと一致させる代わりに、ASBRはRDと一致する必要があります。IPMSI A-DルートのIntra-Intra-IntraのRouterのIPアドレス。

The ASBR first checks if it already has one or more C-multicast routes that have the same MCAST-VPN NLRI as the newly received route. If such a route(s) already exists, the ASBR keeps the newly received route, but SHALL NOT re-advertise the newly received route. Otherwise, the ASBR re-advertises the route, as described in this section.

ASBRは、新しく受信したルートと同じMCAST-VPN NLRIを備えた1つ以上のCマルチキャストルートが既にあるかどうかを最初に確認します。そのようなルートが既に存在する場合、ASBRは新しく受信したルートを保持しますが、新しく受け取ったルートを再承認してはなりません。それ以外の場合、ASBRは、このセクションで説明されているように、ルートを再承認します。

When an ASBR receives a BGP Update message that carries a withdrawal of a previously advertised C-multicast route, the ASBR first checks if it already has at least one other C-multicast route that has the same MCAST-VPN NLRI. If such a route already exists, the ASBR processes the withdrawn route, but SHALL NOT re-advertise the withdrawal. Otherwise, the ASBR re-advertises the withdrawal of the previously advertised C-multicast route, as described below.

ASBRが以前に宣伝されていたC-Multicastルートの引き出しを担当するBGPアップデートメッセージを受信したとき、ASBRは最初に同じMCAST-VPN NLRIを持つ他のC-Multicastルートを既に持っているかどうかを確認します。そのようなルートが既に存在する場合、ASBRは撤回したルートを処理しますが、引き出しを再承認してはなりません。それ以外の場合、ASBRは、以下で説明するように、以前に宣伝されたC-Multicastルートの撤回を再承認します。

If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route into IBGP, the ASBR removes from the route the Route Target that matches one of the ASBR Import RTs (auto-)configured on the ASBR.

ASBRが、I-PMSI A-Dルートを発見したASBRである場合、C-MulticastルートをIBGPに再承認する前に、ASBRはASBRインポートRTSの1つに一致するルートターゲットをルートから除去します(Auto-)ASBRで構成されています。

If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route, the ASBR modifies the Extended Communities attribute of the C-multicast route

ASBRが発見されたI-PMSI A-Dルートを発信したASBRではない場合、C-Multicastルートを再承認する前に、ASBRはC-Multicastルートの拡張コミュニティ属性属性を変更します

by replacing the Route Target of the route that matches one of the ASBR Import RTs (auto-)configured on the ASBR with a new Route Target constructed as follows. The new Route Target is an IP-based Route Target that has the Global Administrator field set to the Next Hop of the found Inter-AS I-PMSI A-D route, and Local Administrator field of this Community set to 0. Note that this newly constructed Route Target is the same as the ASBR Import RT of the ASBR identified by the Next Hop of the found Inter-AS I-PMSI A-D route. The rest of the Extended Communities attribute of the route SHOULD be passed unmodified.

ASBRで構成されたASBRインポートRTS(Auto-)の1つに一致するルートのルートターゲットを、次のように構築された新しいルートターゲットで構成します。新しいルートターゲットは、Global Admanistratorフィールドを次のホップに設定したIPベースのルートターゲットです。ルートターゲットは、発見されたI-PMSI A-Dルートの次のホップによって識別されたASBRのASBRインポートRTと同じです。ルートの残りの拡張コミュニティ属性は、変更されていない渡される必要があります。

The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an IP address of the ASBR.

MP_REACH_NLRI属性の次のホップフィールドは、ASBRのIPアドレスに設定する必要があります。

If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, then the ASBR re-advertises the C-multicast route to that neighbor. If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra-AS) I-PMSI A-D route is an IBGP neighbor of the ASBR, the ASBR re-advertises the C-multicast route into IBGP. If it is the ASBR that originated the found Inter-AS I-PMSI A-D route in the first place, then the ASBR just re-advertises the C-multicast route into IBGP.

発見されたMP_REACH_NLRIの次のホップフィールド(INTER-ASまたはAS)I-PMSI A-DルートがASBRのEBGPネイバーである場合、ASBRはその隣人へのCマルチキャストルートを再承認します。発見されたMP_REACH_NLRIの次のホップフィールド(INTER-ASまたはAS)I-PMSI A-DルートがASBRのIBGP隣接である場合、ASBRはC-MulticastルートをIBGPに再承認します。最初にI-PMSI A-Dルートとして発見されたのはASBRである場合、ASBRはC-MulticastルートをIBGPに再版画します。

11.3. Receiving C-Multicast Routes by a PE
11.3. PEでC-Multicastルートを受信します

When a PE receives a C-multicast route the PE checks if any of the Route Target Extended Communities carried in the Extended Communities attribute of the route match any of the C-multicast Import RTs associated with the VRFs of any MVPN maintained by the PE. If no match is found, the PE SHOULD discard the route. Otherwise, (if a match is found), the PE checks if the address carried in the Multicast Source field of the C-multicast route matches one of the (unicast) VPN-IP routes advertised by PE from the VRF. If no match is found the PE SHOULD discard the route. Otherwise, (if a match is found), the PE proceeds as follows, depending on the multicast routing protocol between CE and PE (C-multicast protocol).

PEがC-Multicastルートを受信すると、PEが維持されているMVPNのVRFに関連付けられているC-Multicast Import RTSの拡張コミュニティ属性属性に属するルートターゲット拡張コミュニティのいずれかが拡張されたコミュニティのいずれかが拡張されたコミュニティのいずれかをチェックします。一致が見つからない場合、PEはルートを破棄する必要があります。それ以外の場合は、(一致が見つかった場合)、PEは、C-Multicastルートのマルチキャストソースフィールドに掲載されているアドレスが、VRFからPEによって宣伝されている(ユニキャスト)VPN-IPルートの1つと一致するかどうかをチェックします。一致が見つからない場合、PEはルートを破棄する必要があります。それ以外の場合は、(一致が見つかった場合)、CEとPE(C-Multicastプロトコル)の間のマルチキャストルーティングプロトコルに応じて、PEは次のように進みます。

11.3.1. Receiving Routes: PIM as the C-Multicast Protocol
11.3.1. 受信ルート:C-MulticastプロトコルとしてのPIM

The following describes procedures when PIM is used as the multicast routing protocol between CE and PE (C-multicast protocol).

以下は、PIMがCEとPE(C-Multicastプロトコル)の間のマルチキャストルーティングプロトコルとして使用される場合の手順について説明します。

Since C-multicast routing information is disseminated by BGP, PIM messages are never sent from one PE to another.

C-Multicastルーティング情報はBGPによって広まっているため、PIMメッセージはPEから別のPEに送信されることはありません。

11.3.1.1. Receiving Source Tree Join C-Multicast Route
11.3.1.1. ソースツリーの受信C-Multicastルートに参加します

If the received route has the Route Type set to Source Tree Join, then the PE creates a new (C-S,C-G) state in its MVPN-TIB from the Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of the route, if such a state does not already exist.

受信ルートのソースツリー結合にルートタイプが設定されている場合、PEは、ルートのMCASTソースおよびマルチキャストグループフィールドからMVPN-TIBに新しい(C-S、C-G)状態を作成します。そのような状態はまだ存在していません。

If the local policy on the PE is to bind (C-S,C-G) to an S-PMSI, then the PE adds the S-PMSI to the outgoing interface list of the (C-S,C-G) state, if it is not already there. Otherwise, the PE adds an I-PMSI to the outgoing interface list of the (C-S,C-G) state, if it is not already there.

PEに関するローカルポリシーが(C-S、C-G)をS-PMSIに結合することである場合、PEはS-PMSIを(C-S、C-G)状態の発信インターフェイスリストに追加します。それ以外の場合、PEは、まだ存在していない場合、(C-S、C-G)状態の発信インターフェイスリストにI-PMSIを追加します。

When, for a said VRF, the last Source Tree Join C-multicast route for (C-S,C-G) is withdrawn, resulting in the situation where the VRF contains no Source Tree Join C-multicast route for (C-S,C-G), the PE MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the (C-S,C-G) state. Depending on the (C-S,C-G) state of the PE-CE interfaces, this may result in the PE using PIM procedures to prune itself off the (C-S,C-G) tree. If C-G is not in the SSM range for the VRF, then removing the I-PMSI/S-PMSI from the outgoing interface list of the (C-S,C-G) state SHOULD be done after a delay that is controlled by a timer. The value of the timer MUST be configurable.

上記のVRFの場合、最後のソースツリーが(C-S、C-G)のC-Multicastルートを結合する場合、VRFにソースツリーが(C-S、C-G)のC-Multicastルートを結合しない状況になります。(c-s、c-g)状態の発信インターフェイスリストからi-pmsi/s-pmsiを削除する必要があります。PE-CEインターフェイスの(C-S、C-G)状態に応じて、これによりPEがPIM手順を使用して(C-S、C-G)ツリーから剪定する可能性があります。C-GがVRFのSSM範囲にない場合、(C-S、C-G)状態の発信インターフェイスリストからI-PMSI/S-PMSIを削除する必要があります。タイマーの値は構成可能でなければなりません。

The purpose of this timer is to ensure that the PE does not stop forwarding (C-S,C-G) onto a PMSI tunnel until all the PEs of the same MVPN have had time to receive the withdrawal of the Source Active A-D route for (C-S,C-G) (see Section 13.1), and the PE connected to C-RP starts forwarding (C-S,C-G) on the C-RPT.

このタイマーの目的は、同じMVPNのすべてのPESがソースアクティブA-Dルート(C-S、C-Gの引き出しを受ける時間があるまで、PEがPMSIトンネルへの転送(C-S、C-G)を停止しないようにすることです。)(セクション13.1を参照)、C-RPに接続されたPEはC-RPTの転送(C-S、C-G)を開始します。

Note that before the PE stops forwarding (C-S,C-G), there is a possibility to have (C-S,C-G) packets being sent at the same time on the PMSI by both the local PE and the PE connected to the site that contains C-RP. This would result in a transient unnecessary traffic on the provider backbone. However, no duplicates will reach customer hosts subscribed to C-G as long as the downstream PEs apply procedures described in Section 9.1 of [MVPN].

PEが転送を停止する前に(C-S、C-G)、C-を含むサイトに接続されたPEとPEの両方によってPMSI上で同時に(C-S、C-G)パケットが送信される可能性があることに注意してください。RP。これにより、プロバイダーのバックボーンに一時的に不必要なトラフィックが発生します。ただし、[MVPN]のセクション9.1で説明されている手順を下流のPES適用手順を適用する限り、C-Gにサブスクライブされた顧客ホストに到達する重複はありません。

11.3.1.2. Receiving Shared Tree Join C-Multicast Route
11.3.1.2. 共有ツリーを受信して、C-Multicastルートに参加します

If the received route has the Route Type set to Shared Tree Join, then the PE creates a new (C-*,C-G) state in its MVPN-TIB with the RP address for that state taken from the Multicast Source, and C-G for that state taken from the Multicast Group fields of the MCAST-VPN NLRI of the route, if such a state does not already exist. If there is no S-PMSI for (C-*,C-G), then the PE adds I-PMSI to the outgoing

受信ルートに共有ツリー結合に設定されたルートタイプがある場合、PEはマルチキャストソースから取られたその状態のRPアドレスを使用して、そのMVPN-TIBに新しい(C - *、C-G)状態を作成し、そのためにC-Gを作成します。そのような状態がまだ存在していない場合、ルートのMCAST-VPN NLRIのマルチキャストグループフィールドから取得した状態。(c - *、c-g)のs-pmsiがない場合、PEはi-pmsiを発信に追加します

interface list of the state if it is not already there. If there is an S-PMSI for (C-*,C-G), then the PE adds S-PMSI to the outgoing interface list of the state if it is not already there.

まだ存在していない場合の状態のインターフェイスリスト。(c - *、c-g)のs-pmsiがある場合、PEは、まだ存在していない場合は、状態の発信インターフェイスリストにs-pmsiを追加します。

When, for a said VRF, the last Shared Tree Join C-multicast route for (C-*,C-G) is withdrawn, resulting in the situation where the VRF contains no Shared Tree Join C-multicast route for (C-*,C-G), the PE MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the (C-*,C-G) state. Depending on the (C-*,C-G) state of the PE-CE interfaces, this may result in the PE using PIM procedures to prune itself off the (C-*,C-G) tree.

上記のVRFの場合、最後の共有ツリーは(C-*、C-G)のC-Multicastルートを結合し、VRFに共有ツリーがC-Multicastルートを含む状況(C-*、C-gが含まれない場合))、PEは、(c - *、c-g)状態の発信インターフェイスリストからi-pmsi/s-pmsiを除去する必要があります。PE-CEインターフェイスの(c - *、c-g)状態に応じて、これによりPEがPIM手順を使用して(c - *、c-g)ツリーから剪定する可能性があります。

11.3.2. Receiving Routes: mLDP as the C-Multicast Protocol
11.3.2. 受信ルート:C-MulticastプロトコルとしてのMLDP

The following describes procedures when mLDP is used as the multicast routing protocol between CE and PE (C-multicast protocol).

以下は、MLDPがCEとPE(C-Multicastプロトコル)の間のマルチキャストルーティングプロトコルとして使用される場合の手順について説明します。

When mLDP is used as a C-multicast protocol, the only valid type of a C-multicast route that a PE could receive is a Source Tree Join C-multicast route.

MLDPがC-Multicastプロトコルとして使用される場合、PEが受信できるC-Multicastルートの唯一の有効なタイプは、ソースツリーがC-Multicastルートに結合することです。

When the PE receives a Source Tree Join C-multicast route, the PE applies, in the scope of this VRF, the P2MP mLDP procedures for a transit node using the value carried in the Multicast Source field of the route as the C-Root Node Identifier, and the value carried in the Multicast Group of the route as the C-LDP MP Opaque Value Element.

PEがソースツリーを受信した場合、C-Multicastルートが結合すると、PEはこのVRFの範囲で、C-Rootノードとしてルートのマルチキャストソースフィールドに掲載された値を使用して、トランジットノードのP2MP MLDP手順を適用します。識別子、およびルートのマルチキャストグループにC-LDP MP Opaque値要素として伝達される値。

If there is no S-PMSI for <C-Root Node Identifier, C-LDP MP Opaque Value Element>, then the PE creates and advertises an S-PMSI as described in Section 12 using C-Root Node Identifier as the value for the Multicast Source field of the S-PMSI A-D route and C-LDP MP Opaque Value Element as the value for the Multicast Group field of the route.

<C-Rootノード識別子、C-LDP MP Opaque Value Element>にS-PMSIがない場合、PEはC-Rootノード識別子を使用してセクション12で説明されているようにS-PMSIを作成および宣伝します。ルートのマルチキャストグループフィールドの値として、S-PMSI A-DルートのマルチキャストソースフィールドとC-LDP MP Opaque値要素。

To improve scalability when mLDP is used as the C-Multicast protocol for a given MVPN, within each AS that has sites of that MVPN connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be aggregated into a single P-multicast tree (by using upstream-assigned labels).

スケーラビリティを改善するために、MLDPが特定のMVPNのCマルチキャストプロトコルとして使用されている場合、それぞれ内でそのMVPNのサイトがそのPESに接続されている場合、そのMVPNのすべてのS-PMSIが単一のpに集計される場合があります-Multicast Tree(上流で割り当てられたラベルを使用すること)。

11.4. C-Multicast Routes Aggregation
11.4. C-Multicastルートの集約

Note that C-multicast routes are "de facto" aggregated by BGP. This is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C-multicast route for a particular C-S and C-G (or a particular C-* and C-G) of a given MVPN are identical.

C-MulticastルートはBGPによって「事実上」集約されていることに注意してください。これは、特定のMVPNの特定のC-SおよびC-G(または特定のC-*およびC-G)のCマルチキャストルートの複数のPESによって宣伝されているMCAST-VPN NLRISが同一であるためです。

Hence, a BGP route reflector or ASBR that receives multiple such routes with the same NLRI will re-advertise only one of these routes to other BGP speakers.

したがって、同じNLRIで複数のそのようなルートを受け取るBGPルートリフレクターまたはASBRは、これらのルートの1つのみを他のBGPスピーカーに再承認します。

This implies that C-multicast routes for a given (S,G) of a given MVPN originated by PEs that are clients of a given route reflector are aggregated by the route reflector. For instance, if multiple PEs that are clients of a route reflector, have receivers for a specific SSM channel of a MVPN, they will all advertise an identical NLRI for the Source Tree Join C-multicast route. However, only one C-multicast route will be advertised by the route reflector for this specific SSM channel of that MVPN, to other PEs and route reflectors that are clients of the route reflector.

これは、特定のルートリフレクターのクライアントであるPESから発信された特定のMVPNの特定のMVPNの特定の(s、g)のc-multicastルートがルートリフレクターによって集約されることを意味します。たとえば、ルートリフレクターのクライアントである複数のPESがMVPNの特定のSSMチャネルの受信機を持っている場合、それらはすべて、ソースツリーがC-Multicastルートに結合する同一のNLRIを宣伝します。ただし、そのMVPNのこの特定のSSMチャネルのルートリフレクターによって、ルートリフレクターのクライアントである他のPESおよびルートリフレクターに宣伝されるC-Multicastルートは1つだけです。

This also implies that an ASBR aggregates all the received C-multicast routes for a given (S,G) (or a given (*,G)) of a given MVPN into a single C-multicast route.

これはまた、ASBRが、特定のMVPNの特定の(s、g)(または与えられた(*、g))の受信したすべてのCマルチキャストルートを単一のCマルチキャストルートに集約することを意味します。

To further reduce the routing churn due to C-multicast routes changes, a route reflector that re-advertises a C-multicast route SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the route to an IP address of the route reflector. Likewise, an ASBR that re-advertises a C-multicast route SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the route to an IP address of the ASBR.

C-Multicastルートの変更によりルーティングチャーンをさらに削減するために、C-Multicastルートを再承認するルートリフレクターは、ルートリフレクターのIPアドレスへのルートのMP_REACH_NLRI属性の次のホップフィールドを設定する必要があります。同様に、C-Multicastルートを再承認するASBRは、ルートのMP_REACH_NLRI属性の次のホップフィールドをASBRのIPアドレスに設定する必要があります。

Further, a BGP receiver, which receives multiple such routes with the same NLRI for the same C-multicast route, will potentially create forwarding state based on a single C-multicast route. Per the procedures described in Section 11.3, this forwarding state will be the same as the state that would have been created based on another route with same NLRI.

さらに、同じc-multicastルートに対して同じNLRIを持つ複数のそのようなルートを受信するBGPレシーバーは、単一のCマルチキャストルートに基づいて転送状態を作成する可能性があります。セクション11.3で説明されている手順に従って、この転送状態は、同じNLRIを持つ別のルートに基づいて作成されたはずの状態と同じです。

12. Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels
12. S-PMSI A-Dルートを使用して、CツリーをPトゥンネルに結合します

This section describes BGP-based procedures for using S-PMSIs A-D routes to bind (C-S,C-G) trees to P-tunnels.

このセクションでは、S-PMSIS A-Dルートを使用して(C-S、C-G)ツリーをPタンネルにバインドするためのBGPベースの手順について説明します。

12.1. Originating S-PMSI A-D Routes
12.1. S-PMSI A-Dルートの発生

The following describes procedures for originating S-PMSI A-D routes by a PE.

以下は、PEでS-PMSI A-Dルートを発信する手順について説明します。

The PE constructs the MCAST-VPN NLRI of an S-PMSI A-D route for a given (C-S,C-G) as follows.

PEは、次のように、特定の(C-S、C-G)のS-PMSI A-DルートのMCAST-VPN NLRIを構築します。

+ The RD in this NLRI is set to the RD of the MVPN's VRF associated with (C-S,C-G).

+ このNLRIのRDは、(C-S、C-G)に関連付けられたMVPNのVRFのRDに設定されています。

+ The Multicast Source field MUST contain the source address associated with the C-multicast stream, and the Multicast Source Length field is set appropriately to reflect this.

+ マルチキャストソースフィールドには、C-Multicastストリームに関連付けられたソースアドレスを含める必要があり、マルチキャストソースの長さフィールドは、これを反映するように適切に設定されています。

+ The Multicast Group field MUST contain the group address associated with the C-multicast stream, and the Multicast Group Length field is set appropriately to reflect this.

+ マルチキャストグループフィールドには、C-Multicastストリームに関連付けられたグループアドレスを含める必要があり、マルチキャストグループの長さフィールドは、これを反映するように適切に設定されています。

+ The Originating Router's IP Address field MUST be set to the IP address that the (local) PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the PE. Note that the <RD, Originating Router's IP address> tuple uniquely identifies a given multicast VRF.

+ 発信元のルーターのIPアドレスフィールドは、VRFルートのグローバル管理者フィールドにある(ローカル)PEがPEによって宣伝されたVPN-IPルートの拡張コミュニティの拡張コミュニティに設定されるIPアドレスに設定する必要があります。<rd、由来のルーターのIPアドレス>タプルは、特定のマルチキャストVRFを一意に識別することに注意してください。

The PE constructs the rest of the S-PMSI A-D route as follows.

PEは、次のようにS-PMSI A-Dルートの残りの部分を構築します。

Depending on the type of P-multicast tree used for the P-tunnel, the PMSI Tunnel attribute of the S-PMSI A-D route is constructed as follows:

Pトンネルに使用されるP-Multicastツリーのタイプに応じて、S-PMSI A-DルートのPMSIトンネル属性は次のように構築されます。

+ The PMSI Tunnel attribute MUST contain the identity of the P-multicast tree (note that the PE could create the identity of the tree prior to the actual instantiation of the tree).

+ PMSIトンネル属性には、P-Multicastツリーのアイデンティティが含まれている必要があります(PEは、ツリーの実際のインスタンス化の前にツリーのアイデンティティを作成できることに注意してください)。

+ If, in order to establish the P-multicast tree, the PE needs to know the leaves of the tree within its own AS, then the PE obtains this information from the Leaf A-D routes received from other PEs/ASBRs within its own AS (as other PEs/ASBRs originate Leaf A-D routes in response to receiving the S-PMSI A-D route) by setting the Leaf Information Required flag in the PMSI Tunnel attribute to 1.

+ P-Multicastツリーを確立するために、PEが独自のツリーの葉を知る必要がある場合、PEは、それ自体内の他のPES/ASBRから受け取った葉のA-Dルートからこの情報を取得します(他のPES/ASBRSは、PMSIトンネル属性に必要なフラグを1に設定することにより、S-PMSI A-Dルートの受信に応じて葉のA-Dルートを発生します。

+ If a PE originates S-PMSI A-D routes with the Leaf Information Required flag in the PMSI Tunnel attribute set to 1, then the PE MUST be (auto-)configured with an import Route Target, which controls acceptance of Leaf A-D routes by the PE. (Procedures for originating Leaf A-D routes by the PEs that receive the S-PMSI A-D route are described in Section 12.3.)

+ PEがS-PMSI A-Dルートを葉の情報で導き、PMSIトンネル属性が1に設定されたフラグを必要とする場合、PEは、PEによるリーフA-Dルートの受け入れを制御する輸入ルートターゲットで構成されている必要があります。。(S-PMSI A-Dルートを受け取ったPESによる葉A-Dルートの発生手順については、セクション12.3で説明します。)

This Route Target is IP address specific. The Global Administrator field of this Route Target MUST be set to the IP address carried in the Next Hop of all the S-PMSI A-D routes advertised by this PE (if the PE uses different Next Hops, then the PE MUST be (auto-)configured with multiple import RTs, one per each such Next Hop). The Local Administrator field of this Route Target MUST be set to 0.

このルートターゲットはIPアドレス固有です。このルートターゲットのグローバル管理者フィールドは、このPEによって宣伝されているすべてのS-PMSI A-Dルートの次のホップで運ばれるIPアドレスに設定する必要があります(PEが異なる次のホップを使用する場合、PEは(auto-)でなければなりません複数のインポートRTで構成され、次のホップごとに1つ)。このルートターゲットのローカル管理者フィールドは、0に設定する必要があります。

If the PE supports Route Target Constraint [RT-CONSTRAIN], the PE SHOULD advertise this import Route Target within its own AS using Route Target Constraints. To constrain distribution of the Route Target Constraint routes to the AS of the advertising PE, these routes SHOULD carry the NO_EXPORT Community [RFC1997].

PEがルートターゲットの制約[RT-Constrain]をサポートする場合、PEはルートターゲット制約を使用してこのインポートルートターゲットを独自のターゲット内で宣伝する必要があります。ルートターゲット制約ルートの分布をAs As Ads Ads PEに制限するために、これらのルートはNO_Exportコミュニティ[RFC1997]を運ぶ必要があります。

+ A PE MAY aggregate two or more S-PMSIs originated by the PE onto the same P-multicast tree. If the PE already advertises S-PMSI A-D routes for these S-PMSIs, then aggregation requires the PE to re-advertise these routes. The re-advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised S-PMSI A-D routes for these S-PMSIs, then the aggregation requires the PE to advertise (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-multicast tree that aggregates the S-PMSIs. If at least some of the S-PMSIs aggregated onto the same P-multicast tree belong to different MVPNs, then all these routes MUST carry an MPLS upstream-assigned label [RFC5331].

+ PEは、PEによって同じP-Multicastツリーに由来する2つ以上のS-PMSISを集約する場合があります。PEがこれらのS-PMSIのS-PMSI A-Dルートを既に宣伝している場合、集約にはこれらのルートを再承認するためにPEが必要です。再承認されたルートは、PMSIトンネル属性を除き、元のルートと同じでなければなりません。PEがこれらのS-PMSIのS-PMSI A-Dルートを以前に宣伝していなかった場合、集約はこれらのS-PMSIの広告(新しい)S-PMSI A-Dルートを広告する必要があります。新しく宣伝された/再承認されたルートのPMSIトンネル属性は、S-PMSISを集約するP-MulticastツリーのIDを運ぶ必要があります。同じP-Multicastツリーに集約されたS-PMSISの少なくとも一部が異なるMVPNに属している場合、これらのルートはすべて、上流で割り当てられたMPLS [RFC5331]を運ぶ必要があります。

If all these aggregated S-PMSIs belong to the same MVPN, and this MVPN uses PIM as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned label [RFC5331]. Moreover, in this case, the labels MUST be distinct on a per-MVPN basis and MAY be distinct on a per-route basis.

これらすべての凝集したS-PMSISが同じMVPNに属し、このMVPNがC-MulticastルーティングプロトコルとしてPIMを使用している場合、対応するS-PMSI A-DルートはMPLSアップストリーム割り当てラベル[RFC5331]を運ぶ場合があります。さらに、この場合、ラベルはMVPNごとに明確でなければならず、ルートごとに異なる場合があります。

If all these aggregated S-PMSIs belong to the MVPN(s) that uses mLDP as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MUST carry an MPLS upstream-assigned label [RFC5331], and these labels MUST be distinct on a per-route (per-mLDP FEC) basis, irrespective of whether the aggregated S-PMSIs belong to the same or different MVPNs.

これらすべての集計されたS-PMSISがMLDPをC-Multicastルーティングプロトコルとして使用するMVPNに属している場合、対応するS-PMSI A-DルートはMPLSアップストリーム割り当てラベル[RFC5331]を運ぶ必要があり、これらのラベルは必要でなければなりません。集約されたS-PMSIが同じまたは異なるMVPNに属しているかどうかに関係なく、ルートごと(PEC)ベースでは異なります。

The Next Hop field of the MP_REACH_NLRI attribute of the route MUST be set to the same IP address as the one carried in the Originating Router's IP Address field.

ルートのMP_REACH_NLRI属性の次のホップフィールドは、元のルーターのIPアドレスフィールドで運ばれたものと同じIPアドレスに設定する必要があります。

The route always carries a set of Route Targets. The default set of Route Targets is determined as follows:

+ If there is a (unicast) VPN-IP route to C-S originated from the VRF, but no (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the Intra-AS I-PMSI A-D route originated from the VRF and the set of Route Targets carried by the (unicast) VPN-IP route to C-S.

+ VRFに由来するC-Sへの(ユニキャスト)VPN-IPルートがあるが、VRFに由来するC-RPへの(Unicast)VPN-IPルートがない場合、ルートターゲットのセットは、セットの交差点によって形成されます。INTRA-AS I-PMSI A-Dルートで運ばれるルートターゲットのセットは、VRFから発生し、(Unicast)VPN-IPルートがC-Sに運ぶルートターゲットのセットから発生しました。

+ If there is no (unicast) VPN-IP route to C-S originated from the VRF, but there is a (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the intra-AS I-PMSI A-D route originated from the VRF and the set of Route Targets carried by the (unicast) VPN-IP route to C-RP.

+ VRFに由来するC-Sへの(Unicast)VPN-IPルートがない場合、VRFから発信されるC-RPへの(Unicast)VPN-IPルートがある場合、ルートターゲットのセットはセット交差点によって形成されます。INTRA-AS I-PMSI A-Dルートで運ばれるルートターゲットのセットは、VRFから発生し、(ユニキャスト)VPN-IPルートがC-RPに運ぶルートターゲットのセットとの間です。

+ If there is a (unicast) VPN-IP route to C-S originated from the VRF, and a (unicast) VPN-IP route to C-RP originated from the VRF, then the set of Route Targets is formed by a set intersection between the set of Route Targets carried in the Intra-AS I-PMSI A-D route originated from the VRF and the set union of Route Targets carried by the (unicast) VPN-IP route to C-S and the (unicast) VPN-IP route to C-RP.

+ VRFに由来するC-Sへの(ユニキャスト)VPN-IPルートがある場合、VRFに由来するC-RPへの(ユニキャスト)VPN-IPルートがある場合、ルートターゲットのセットは、セットのセットが設定された交差点によって形成されます。INTRA-AS I-PMSI A-Dルートで運ばれるルートターゲットのセットは、VRFと(Unicast)VPN-IPルートがC-Sと(Unicast)VPN-IPルートがC-Sに運ぶルートターゲットのセットユニオンから発生しました。RP。

In each of the above cases, an implementation MUST allow the set of Route Targets carried by the route to be specified by configuration. In the absence of a configured set of Route Targets, the route MUST carry the default set of Route Targets, as specified above.

上記の各ケースでは、実装では、ルートで運ばれるルートターゲットのセットを構成によって指定することを許可する必要があります。構成されたルートターゲットのセットがない場合、ルートは上記で指定されているように、ルートターゲットのデフォルトセットを搭載する必要があります。

12.2. Handling S-PMSI A-D Routes by ASBRs
12.2. ASBRSによるS-PMSI A-Dルートの処理

Procedures for handling an S-PMSI A-D route by ASBRs (both within and outside of the AS of the PE that originates the route) are the same as specified in Section 9.2.3, except that instead of Inter-AS I-PMSI A-D routes, the procedures apply to S-PMSI A-D routes.

ASBRによってS-PMSI A-Dルートを処理する手順(ルートを発信するPEの内外の両方)は、I-PMSI A-Dルートの代わりに、セクション9.2.3で指定されたものと同じです。、手順はS-PMSI A-Dルートに適用されます。

12.2.1. Merging S-PMSI into an I-PMSI
12.2.1. S-PMSIをi-PMSIにマージします

Consider the situation where:

状況を考えてみましょう:

+ An ASBR is receiving (or expecting to receive) inter-AS (C-S,C-G) data from upstream via an S-PMSI.

+ ASBRは、S-PMSIを介して上流からAS(C-S、C-G)データを受け取る(または受信することを期待しています)。

+ The ASBR is sending (or expecting to send) the inter-AS (C-S,C-G) data downstream via an I-PMSI.

+ ASBRは、I-PMSIを介して下流のAS(C-S、C-G)データを送信(または送信する予定)です。

This situation may occur if the upstream providers have a policy of using S-PMSIs but the downstream providers have a policy of using I-PMSIs. To support this situation, an ASBR MAY, under certain conditions, merge one or more upstream S-PMSIs into a downstream I-PMSI.

上流のプロバイダーにS-PMSISを使用するポリシーがあるが、下流のプロバイダーにはI-PMSISを使用するポリシーがある場合、この状況が発生する可能性があります。この状況をサポートするために、ASBRは、特定の条件下で、1つ以上の上流のS-PMSIを下流のI-PMSIに統合する場合があります。

An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be merged by a particular ASBR into an I-PMSI (corresponding to a particular Inter-AS I-PMSI A-D route) if and only if the following conditions all hold:

S-PMSI(特定のS-PMSI A-Dルートに対応)は、特定のASBRによってI-PMSI(特定のAS I-PMSI A-Dルートに対応)にマージされます。:

+ BGP is used to exchange C-multicast routes.

+ BGPは、C-Multicastルートを交換するために使用されます。

+ The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate in the same AS. The Inter-AS I-PMSI A-D route carries the originating AS in the Source AS field of the NLRI of the route and in the AS_PATH attribute of the route. The S-PMSI A-D route carries the originating AS in the AS_PATH attribute of the route.

+ S-PMSI A-DルートとINTER-AS I-PMSI A-Dルートは、同じと同じで発生します。INTER-AS I-PMSI A-Dルートは、ルートのNLRIのフィールドとして、およびルートのAS_PATH属性のフィールドとしてソースのように発信するものを運びます。S-PMSI A-Dルートは、ルートのAS_PATH属性のように発生するものを運びます。

+ The S-PMSI A-D route and the Inter-AS I-PMSI A-D route have exactly the same set of RTs.

+ S-PMSI A-DルートとINTER-AS I-PMSI A-Dルートには、まったく同じRTSセットがあります。

+ For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has installed a Source Tree Join (C-S,C-G) C-multicast route, then the S-PMSI route was originated by the upstream PE of the C-multicast route. The address of the upstream PE is carried in the RT of the C-multicast route. The address of the PE that originated the S-PMSI route is carried in the Originating Router's IP Address field of the MCAST-VPN NLRI of the route.

+ S-PMSIルートで言及された各(C-S、C-G)について、ASBRがソースツリー結合(C-S、C-G)Cマルチカストルートをインストールした場合、S-PMSIルートはC-の上流PEによって発信されました。マルチキャストルート。上流のPEのアドレスは、C-MulticastルートのRTで運ばれます。S-PMSIルートを発信したPEのアドレスは、ルートのMCAST-VPN NLRIの発信元ルーターのIPアドレスフィールドに運ばれます。

+ The ASBR supports the optional capability to discard (C-S,C-G) traffic received on an I-PMSI.

+ ASBRは、I-PMSIで受け取った(C-S、C-G)トラフィックを破棄するオプションの機能をサポートしています。

An ASBR performs merging by stitching the tail end of the P-tunnel, as specified in the PMSI Tunnel attribute of the S-PMSI A-D route received by the ASBR, to the head of the P-tunnel, as specified in the PMSI Tunnel attribute of the Inter-AS I-PMSI A-D route re-advertised by the ASBR.

ASBRは、PMSIトンネル属性で指定されているように、ASBRが受け取ったS-PMSI A-DルートのPMSIトンネル属性で指定されているP-Tunnelのヘッドに指定されているように、Pトンネルのテールエンドをステッチすることによりマージを実行します。ASBRによって再承認されたI-PMSI A-DルートとしてのINTER-AS I-PMSI A-Dルートの。

IP processing during merge: If an ASBR merges a (C-S,C-G) S-PMSI A-D route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all (C-S,C-G) traffic it receives on the tunnel advertised in the I-PMSI A-D route.

マージ中のIP処理:ASBRがA(C-S、C-G)S-PMSI A-DルートをINTER-AS I-PMSI A-Dルートにマージする場合、ASBRはすべて(C-S、C-G)トラフィックを廃棄する必要があります。I-PMSI A-Dルート。

An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D route MUST NOT re-advertise the S-PMSI A-D route.

S-PMSI A-DルートをINTER-AS I-PMSI A-Dルートに統合するASBRは、S-PMSI A-Dルートを再承認してはなりません。

12.3. Receiving S-PMSI A-D Routes by PEs
12.3. PESでS-PMSI A-Dルートを受信します

Consider a PE that receives an S-PMSI A-D route. If one or more of the VRFs on the PE have their import Route Targets that contain one or more of the Route Targets carried by the received S-PMSI A-D route, then for each such VRF (and associated MVPN-TIB) the PE performs the following.

S-PMSI A-Dルートを受信するPEを検討してください。PE上の1つ以上のVRFが、受信したS-PMSI A-Dルートによって運ばれるルートターゲットの1つ以上を含むインポートルートターゲットを持っている場合、そのようなVRF(および関連するMVPN-TIB)ごとにPEが実行されます。続く。

Procedures for receiving an S-PMSI A-D route by a PE (both within and outside of the AS of the PE that originates the route) are the same as specified in Section 9.2.3.4 except that (a) instead of Inter-AS

PEによってS-PMSI A-Dルートを受信する手順(ルートを発信するPEの内側と外側の両方)は、(a)Inter-asではなく(a)を除き、セクション9.2.3.4で指定されたものと同じです。

I-PMSI A-D routes, the procedures apply to S-PMSI A-D routes and (b) a PE performs procedures specified in that section only if, in addition to the criteria there, one of the following is true:

I-PMSI A-Dルート、手順はS-PMSI A-Dルートに適用され、(b)PEは、そのセクションで指定された手順を実行します。

+ the PE originates a Source Tree Join (C-S,C-G) C-multicast route, and the upstream PE of that route is the PE that originates the S-PMSI A-D route; or

+ PEは、ソースツリー結合(C-S、C-G)Cマルチカストルートを発信し、そのルートの上流のPEはS-PMSI A-Dルートを発信するPEです。また

+ the PE does not originate a Source Tree Join (C-S,C-G) C-multicast route, but it originates a Shared Tree Join (C-*,C-G) C-multicast route. The best (as determined by the BGP route selection procedures) Source Active A-D route for (C-S,C-G) selected by the PE is originated by the same PE as the one that originates the S-PMSI A-D route; or

+ PEは、ソースツリー結合(C-S、C-G)Cマルティリカストルートを発生するものではありませんが、共有ツリー結合(C - *、C-G)C-Multicastルートを発信します。PEによって選択された(C-S、C-G)の最良の(BGPルート選択手順によって決定される)ソースアクティブA-Dルートは、S-PMSI A-Dルートを発信するものと同じPEから発信されます。また

+ the PE does not originate a Source Tree Join (C-S,C-G), has not received any Source Active A-D routes for (C-S,C-G), but does originate a Shared Tree Join (C-*,C-G) route. The upstream PE for that route is the PE that originates the received S-PMSI A-D route.

+ PEはソースツリー結合(C-S、C-G)を発信するものではなく、(C-S、C-G)のソースアクティブA-Dルートを受信していませんが、共有ツリー結合(C-*、C-G)ルートを発信します。そのルートの上流のPEは、受信したS-PMSI A-Dルートを発信するPEです。

If the received S-PMSI A-D route has a PMSI Tunnel attribute with the Leaf Information Required flag set to 1, then the PE originates a Leaf A-D route. The Route Key of the Leaf A-D route is set to the MCAST-VPN NLRI of the S-PMSI A-D route. The rest of the Leaf A-D route is constructed using the same procedures as specified in section 9.2.3.4.1, except that instead of originating Leaf A-D routes in response to receiving Inter-AS I-PMSI A-D routes, the procedures apply to originating Leaf A-D routes in response to receiving S-PMSI A-D routes.

受信したS-PMSI A-Dルートに、Leaf情報が1に設定されるフラグが必要なPMSIトンネル属性がある場合、PEはリーフA-Dルートを発信します。リーフA-Dルートのルートキーは、S-PMSI A-DルートのMCAST-VPN NLRIに設定されています。リーフA-Dルートの残りの部分は、セクション9.2.3.4.1で指定されているのと同じ手順を使用して構築されます。ただし、I-PMSI A-Dルートを受け取ることに応じてリーフA-Dルートを発信する代わりに、手順は発生葉に適用されます。A-DルートS-PMSI A-Dルートの受信に応じて。

In addition to the procedures specified in Section 9.2.3.4.1, the PE MUST set up its forwarding path to receive (C-S,C-G) traffic from the tunnel advertised by the S-PMSI A-D route (the PE MUST switch to the S-PMSI).

セクション9.2.3.4.1で指定された手順に加えて、PEはS-PMSI A-Dルートによって宣伝されたトンネルからの(C-S、C-G)トラフィックを受信するための転送パスを設定する必要があります(PEはS-に切り替える必要があります。PMSI)。

If a PE that is a leaf node of a particular Selective tunnel determines that it no longer needs to receive any of (C-S,C-G)s carried over that tunnel, the PE SHOULD prune itself off that tunnel. Procedures for pruning are specific to a particular tunneling technology.

特定の選択トンネルの葉のノードであるPEが、そのトンネルを運ぶ(C-S、C-G)Sのいずれかを受け取る必要がなくなると判断した場合、PEはそのトンネルから剪定する必要があります。剪定の手順は、特定のトンネル技術に固有です。

13. Switching from Shared a C-Tree to a Source C-Tree
13. C-Treeの共有からソースCツリーに切り替えました

The procedures defined in this section only apply when the C-multicast routing protocol is PIM [RFC4601]; moreover, they only apply for the multicast ASM mode and MUST NOT be applied to multicast

このセクションで定義されている手順は、C-MulticastルーティングプロトコルがPIM [RFC4601]である場合にのみ適用されます。さらに、それらはマルチキャストASMモードにのみ申請し、マルチキャストに適用してはなりません

group addresses belonging to the SSM range. The procedures also MUST NOT be applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015].

SSM範囲に属するグループアドレス。また、C-MulticastルーティングプロトコルがBidir-PIM [RFC5015]である場合、手順を適用しないでください。

The procedures of this section are applicable only to MVPNs that use both shared (i.e., rooted at a C-RP) and source (i.e., rooted at a C-S) inter-site C-trees.

このセクションの手順は、共有(すなわち、C-RPにルート化された)とソース(つまり、C-Sに根付いた)の両方を使用するMVPNにのみ適用されます。

These procedures are not applicable to MVPNs that do not use shared inter-site C-trees and rely solely on source inter-site C-trees. See Section 14 for the procedures applicable to that scenario.

これらの手順は、共有された敷地間Cツリーを使用しておらず、ソースインターサイトCツリーのみに依存していないMVPNには適用されません。そのシナリオに適用される手順については、セクション14を参照してください。

Whether or not a given MVPN uses both inter-site shared and source C-trees must be known a priori (e.g., via provisioning).

所定のMVPNがサイト間共有とソースの両方のC-Treeを使用するかどうかは、先験的なものを知っている必要があります(例:プロビジョニングを介して)。

In the scenario where an MVPN customer switches from a C-RP-based tree (RPT) to the shortest path tree (SPT), in order to avoid packet duplication, choosing of a single consistent upstream PE, as described in [MVPN], may not suffice. To illustrate this, consider a set of PEs {PE2, PE4, PE6} that are on the C-RP tree for (C-*,C-G) and have chosen a consistent upstream PE, as described in [MVPN], for (C-*,C-G) state. Further, this upstream PE, say PE1, is using a Multidirectional Inclusive PMSI (MI-PMSI) for (C-*,C-G). If a site attached to one of these PEs, say PE2, switches to the C-S tree for (C-S,C-G), PE2 generates a Source Tree Join C-multicast route towards the upstream PE that is on the path to C-S, say PE3. PE3 also uses the MI-PMSI for (C-S,C-G), as PE1 uses for (C-*,C-G). This results in {PE2, PE4, PE6} receiving duplicate traffic for (C-S,C-G) -- both on the C-RP tree (from PE1) and C-S tree (from PE3). If it is desirable to suppress receiving duplicate traffic, then it is necessary to choose a single forwarder PE for (C-S,C-G). The following describes how this is achieved.

MVPN顧客がパケットの複製を避けるために、C-RPベースのツリー(RPT)から最短パスツリー(SPT)に切り替えるシナリオでは、[MVPN]で説明されているように、単一の一貫した上流PEを選択します。十分ではないかもしれません。これを説明するために、(c - *、c-g)のc-rpツリー上にあるpes {pe2、pe4、pe6}のセットを検討し、[mvpn]で説明されているように、一貫した上流peを選択しています(c) - *、c-g)状態。さらに、この上流のPE、たとえばPE1は、(c - *、c-g)に多方向包括的PMSI(MI-PMSI)を使用しています。これらのPESのいずれかに接続された部位、たとえばPE2が(C-S、C-G)のC-Sツリーに切り替えた場合、PE2はC-Sへのパスにある上流のPEに向かってC-Multicastルートを結合します。 PE3は(C-S、C-G)のMi-PMSIを(C-*、C-G)に使用します。これにより、{PE2、PE4、PE6}は、C-RPツリー(PE1から)とC-Sツリー(PE3から)の両方で重複するトラフィックを受け取ります。重複するトラフィックの受信を抑制することが望ましい場合は、(C-S、C-G)に対して単一のフォワーダーPEを選択する必要があります。以下は、これがどのように達成されるかを説明しています。

13.1. Source within a Site - Source Active Advertisement
13.1. サイト内のソース - ソースアクティブ広告

When, as a result of receiving a Source Tree Join C-multicast route for (C-S,C-G) from some other PE the local PE adds either the S-PMSI or the I-PMSI to the outgoing interface list of the (C-S,C-G) state (see Section 11.3.1.1), the local PE MUST originate a Source Active A-D route if the PE has not originated such route already. The route carries a single MCAST-VPN NLRI constructed as follows:

ソースツリーを受信した結果、他のPEからの(C-S、C-G)のC-Multicastルートに参加する場合、ローカルPEはS-PMSIまたはI-PMSIを(C-S、C-Gの発信インターフェイスリストに追加します。)状態(セクション11.3.1.1を参照)、PEがすでにそのようなルートを発生していない場合、ローカルPEはソースアクティブA-Dルートを発生する必要があります。ルートには、次のように構築された単一のmcast-vpn nlriが搭載されています。

+ The RD in this NLRI is set to the RD of the VRF of the MVPN on the PE.

+ このNLRIのRDは、PE上のMVPNのVRFのRDに設定されています。

+ The Multicast Source field MUST be set to C-S. The Multicast Source Length field is set appropriately to reflect this.

+ マルチキャストソースフィールドは、C-Sに設定する必要があります。マルチキャストソースの長さフィールドは、これを反映するように適切に設定されています。

+ The Multicast Group field MUST be set to C-G. The Multicast Group Length field is set appropriately to reflect this.

+ マルチキャストグループフィールドは、C-Gに設定する必要があります。マルチキャストグループ長フィールドは、これを反映するように適切に設定されています。

The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the IP address that the PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the PE from the MVPN's VRF.

MP_REACH_NLRI属性の次のホップフィールドは、MVPNのVRFからPEによって宣伝されているVPN-IPルートの拡張コミュニティをインポートするVRFルートのインポートフィールドにPEが配置するIPアドレスに設定する必要があります。

The route SHOULD carry the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN originated by the PE.

ルートは、PEによって発生するMVPNのI-PMSI A-DルートのAs Intra-As-As-As-As-As-As-As-As-As-As-As-As-As-as Asのルートターゲットセットを搭載する必要があります。

Using the normal BGP procedures, the Source Active A-D route is propagated to all the PEs of the MVPN.

通常のBGP手順を使用して、ソースアクティブA-DルートがMVPNのすべてのPESに伝播されます。

Note that the advertisement of a Source Active A-D route for a given (C-S,C-G) could be combined, if desired, with the advertisement of an S-PMSI A-D route for the same (C-S,C-G). This is accomplished by using the same BGP Update message to carry both the NLRI of the S-PMSI A-D route and the NLRI of the Source Active A-D route.

特定の(C-S、C-G)のソースアクティブA-Dルートの広告は、必要に応じて、同じ(C-S、C-G)のS-PMSI A-Dルートの広告と組み合わせることができることに注意してください。これは、同じBGPアップデートメッセージを使用して、S-PMSI A-DルートのNLRIとソースアクティブA-DルートのNLRIの両方を運ぶことで実現されます。

Note that even if the originating PE advertises both the Source Active A-D route and the S-PMSI A-D route in the same BGP Update message, an implementation cannot assume that all other PEs will receive both of these routes in the same Update message.

発信元PEが同じBGPアップデートメッセージにソースActive A-DルートとS-PMSI A-Dルートの両方を宣伝している場合でも、実装は他のすべてのPEが同じ更新メッセージでこれらのルートを受信すると仮定できないことに注意してください。

When, as a result of receiving a withdrawal of the previously advertised Source Tree Join C-multicast route for (C-S,C-G), the PE is going to remove the S-PMSI/I-PMSI from the outgoing interface list of the (C-S,C-G) state. The local PE MUST also withdraw the Source Active A-D route for (C-S,C-G), if such a route has been advertised.

(C-S、C-G)の以前に宣伝されたソースツリーがC-Multicastルートを結合した結果として、PEは(C-S、C-Sの発信インターフェイスリストからS-PMSI/I-PMSIを削除する場合)、c-g)状態。このようなルートが宣伝されている場合、ローカルPEはまた、(C-S、C-G)のソースアクティブA-Dルートを引き出しなければなりません。

Note that if the PE is also acting as a C-RP, but inter-site shared trees are being used, the reception of a PIM Register message by the PE does not result in the origination of a Source Active A-D route.

PEがC-RPとしても機能しているが、サイト間共有ツリーが使用されている場合、PEによるPIMレジスタメッセージの受信は、ソースアクティブA-Dルートの起源につながらないことに注意してください。

13.2. Receiving Source Active A-D Route
13.2. ソースアクティブA-Dルートを受信します

When a PE receives a new Source Active A-D route from some other PE, the PE finds a VRF whose import Route Targets match one or more of the Route Targets carried by the route. If the match is found, then the PE updates the VRF with the received route.

PEが他のPEから新しいソースActive A-Dルートを受信すると、PEは輸入ルートターゲットがルートで運ばれるルートターゲットの1つ以上に一致するVRFを見つけます。一致が見つかった場合、PEは受信ルートでVRFを更新します。

We say that a given (C-S,C-G) Source Active A-D route stored in a given VRF on a PE matches a given (C-*,C-G) entry present in the MVPN-TIB associated with the VRF if C-G carried by the route is the same as C-G of the entry, and the PE originates a Shared Tree Join C-multicast route for the same C-G as the C-G of the entry.

特定のVRFに保存されている特定の(C-S、C-G)ソースアクティブA-Dルートは、ルートによって運ばれた場合のVRFに関連付けられたMVPN-TIBに存在する特定の(C - *、C-G)エントリが一致すると言います。エントリのC-gと同じであり、PEはエントリのC-gと同じC-gの共有ツリーがC-Multicastルートに結合します。

When (as a result of receiving PIM messages from one of its CEs) a PE creates in one of its MVPN-TIBs a (new) (C-*,C-G) entry with a non-empty outgoing interface list that contains one or more PE-CE interfaces, the PE MUST check if it has any matching Source Active A-D routes. If there is one or more such matching route, such that the PE does not have (C-S,C-G) state in its MVPN-TIB for (C-S,C-G) carried in the route, then the PE selects one of them (using the BGP route selection procedures), and sets up its forwarding path to receive (C-S,C-G) traffic from the tunnel that the originator of the selected Source Active A-D route uses for sending (C-S,C-G).

(CESの1つからPIMメッセージを受信した結果)A PEは、MVPN-TIBS A(new)(c - *、c-g)エントリの1つに1つ以上の空白の発信インターフェイスリストを使用して作成する場合PE-CEインターフェイスでは、PEは一致するソースActive A-Dルートがあるかどうかを確認する必要があります。PEがルートで運ばれた(C-S、C-G)のMVPN-TIBに(C-S、C-G)状態がないように、そのような一致するルートが1つ以上ある場合、PEはそれらの1つを選択します(BGPを使用しますルート選択手順)、および選択したソースActive A-Dルートの発信元が送信(C-S、C-G)に使用するトンネルから(C-S、C-G)トラフィックを受信するための転送パスを設定します。

When, as a result of receiving a new Source Active A-D route, a PE updates its VRF with the route, the PE MUST check if the newly received route matches any (C-*,C-G) entries. If (a) there is a matching entry, (b) the PE does not have (C-S,C-G) state in its MVPN-TIB for (C-S,C-G) carried in the route, and (c) the received route is selected as the best (using the BGP route selection procedures), then the PE sets up its forwarding path to receive (C-S,C-G) traffic from the tunnel the originator of the selected Source Active A-D route uses for sending (C-S,C-G).

新しいソースActive A-Dルートを受信した結果、PEはルートでVRFを更新する場合、PEは新しく受信したルートが(C - *、C-G)エントリと一致するかどうかを確認する必要があります。(a)マッチングエントリがある場合、(b)PEには(c-s、c-g)MVPN-tib for(c-s、c-g)がルートに携帯されていない場合、(c)受信ルートが選択されています。最適な(BGPルート選択手順を使用)、PEは転送パスを設定して、トンネルから(C-S、C-G)トラフィックを受け取り、選択したソースActive A-Dルートの発信元が送信に使用します(C-S、C-G)。

Note that if the PE is also acting as a C-RP, and inter-site shared trees are being used, the BGP Source Active A-D routes do not replace the Multicast Source Discovery Protocol (MSDP) or PIM-based Anycast RP peerings among C-RPs that would be needed to disseminate source discovery information among C-RPs.

PEがC-RPとしても作用し、サイト間共有ツリーが使用されている場合、BGPソースアクティブA-Dルートは、マルチキャストソースディスカバリープロトコル(MSDP)またはPIMベースのAnycast RPピアリングをCの中で置き換えないことに注意してください。-C-RPS間でソース発見情報を広めるために必要なRPS。

13.2.1. Pruning Sources off the Shared Tree
13.2.1. 共有ツリーから剪定ソース

In addition to the procedures in the previous section, a PE applies the following procedure when importing a Source Active A-D route for (C-S,C-G) into a VRF.

前のセクションの手順に加えて、PEは、(C-S、C-G)のソースアクティブA-DルートをVRFにインポートするときに、次の手順を適用します。

The PE finds a (C-*,C-G) entry in the MVPN-TIB whose C-G is the same as the C-G carried in the Multicast Group field of the Source Active A-D route.

PEは、C-gがソースActive A-Dルートのマルチキャストグループフィールドで運ばれたC-gと同じMVPN-TIBの(C - *、C-G)エントリを見つけます。

If the outgoing interface list (oif) for the found (C-*,C-G) entry in the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, and the PE does not originate the Source Tree Join C-multicast route for (C-S,C-G) (where C-S is address carried in the Multicast Source field and C-G is the address carried in the Multicast Group field of the received Source Active A-D route), then the PE MUST transition the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the Prune state. (Conceptually, the C-PIM state machine on the PE will act "as if" it had received Prune (C-S,C-G,rpt) on I-PMSI/S-PMSI, without

PEのMVPN-TIBの発見(C - *、C-G)エントリの発信インターフェイスリスト(OIF)にはI-PMSIまたはS-PMSIが含まれている場合、PEはソースツリーがC-Multicastに結合しない場合(C-S、C-G)のルート(C-Sはマルチキャストソースフィールドに掲載され、C-Gが受信したソースActive A-Dルートのマルチキャストグループフィールドに運ばれるアドレスです)、PEは(C-S、C-G、RPTを遷移する必要があります。)プルーン状態へのI-PMSI/S-PMSI上の下流の状態マシン。(概念的には、PE上のC-PIM状態マシンは、i-PMSI/S-PMSIでプルーン(C-S、C-G、RPT)を受け取ったかのように「」行動します。

actually having received one.) Depending on the (C-S,C-G,rpt) state of the PE-CE interfaces, this may result in the PE using PIM procedures to prune the C-S off the (C-*,C-G) tree.

PE-CEインターフェイスの(C-S、C-G、RPT)状態に応じて、PEがPIM手順を使用してC-Sを(c - *、c-g)ツリーからプルナンスすることになる場合があります。

Transitioning the state machine to the Prune state SHOULD be done after a delay that is controlled by a timer. The value of the timer MUST be configurable. The purpose of this timer is to ensure that the C-S is not pruned off the shared tree until all PEs have had time to receive the Source Active A-D route for (C-S,C-G).

状態マシンをプルーン状態に移行することは、タイマーによって制御される遅延後に行う必要があります。タイマーの値は構成可能でなければなりません。このタイマーの目的は、すべてのPEが(C-S、C-G)のソースアクティブA-Dルートを受信する時間があるまで、C-Sが共有ツリーから剪定されないようにすることです。

Note that before C-S is pruned off the shared tree, there is a possibility to have (C-S,C-G) packets sent at the same time on the PMSI by distinct PEs. This would result in a transient unnecessary traffic on the provider backbone. However, no duplicates will reach customer hosts subscribed to C-G as long as the downstream PEs apply procedures described in Section 9.1 of [MVPN].

C-Sが共有ツリーから剪定される前に、異なるPESによってPMSIで同時に(C-S、C-G)パケットが送信される可能性があることに注意してください。これにより、プロバイダーのバックボーンに一時的に不必要なトラフィックが発生します。ただし、[MVPN]のセクション9.1で説明されている手順を下流のPES適用手順を適用する限り、C-Gにサブスクライブされた顧客ホストに到達する重複はありません。

The PE MUST keep the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI in the Prune state for as long as (a) the outgoing interface list (oif) for the found (C-*,C-G) entry in the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, (b) the PE has at least one Source Active A-D route for (C-S,C-G), and (c) the PE does not originate the Source Tree Join C-multicast route for (C-S,C-G). Once any of these conditions become no longer valid, the PE MUST transition the (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the NoInfo state.

PEは、(a)発見された(c - *、c-gの発信インターフェイスリスト(OIF)である限り、プルーン状態のI-PMSI/S-PMSI上の(c-s、c-g、rpt)下流の状態マシンを保持する必要があります。)PEのMVPN-TIBのエントリには、I-PMSIまたはS-PMSIのいずれか、(b)PEには(C-S、C-G)の少なくとも1つのソースアクティブA-Dルートがあり、(c)PEはPEが発生しません。ソースツリー(C-S、C-G)のC-Multicastルートに結合します。これらの条件のいずれかが有効になったら、PEはI-PMSI/S-PMSI上の(C-S、C-G、RPT)下流の状態マシンをNOINFO状態に遷移する必要があります。

Note that changing the state on the downstream state machine on I-PMSI/S-PMSI, as described above, does not imply exchanging PIM messages over I-PMSI/S-PMSI.

上記のように、I-PMSI/S-PMSI上の下流の状態マシンの状態を変更することは、I-PMSI/S-PMSIを介してPIMメッセージを交換することを意味しないことに注意してください。

Also, note that except for the scenario described in the third paragraph of this section, in all other scenarios relying solely on PIM procedures on the PE is sufficient to ensure the correct behavior when pruning sources off the shared tree.

また、このセクションの3番目の段落で説明されているシナリオを除き、PEのPIM手順のみに依存する他のすべてのシナリオでは、共有ツリーを剪定するときに正しい動作を確保するのに十分であることに注意してください。

14. Supporting PIM-SM without Inter-Site Shared C-Trees
14. 敷地間共有CツリーなしでPIM-SMをサポートします

The procedures defined in this section only apply when the C-multicast routing protocol is PIM [RFC4601]; moreover, only apply for the multicast ASM mode, and MUST NOT be applied to multicast group addresses belonging to the SSM range. The procedures also MUST NOT be applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015].

このセクションで定義されている手順は、C-MulticastルーティングプロトコルがPIM [RFC4601]である場合にのみ適用されます。さらに、マルチキャストASMモードのみを適用し、SSM範囲に属するマルチキャストグループアドレスに適用しないでください。また、C-MulticastルーティングプロトコルがBidir-PIM [RFC5015]である場合、手順を適用しないでください。

The procedures of this section are applicable only to MVPNs that do not use inter-site shared (i.e., rooted at a C-RP) C-trees.

このセクションの手順は、敷地間共有(つまり、C-RPに根付いている)C-Treeを使用しないMVPNにのみ適用されます。

These procedures are not applicable to MVPNs that use both shared and shortest path inter-site C-trees. See Section 13 for the procedures applicable to that scenario.

これらの手順は、共有パスと最短の両方のパス間C-Treeを使用するMVPNには適用されません。そのシナリオに適用される手順については、セクション13を参照してください。

Whether or not a given MVPN uses inter-site shared C-trees must be known a priori (e.g., via provisioning).

特定のMVPNがサイト間共有Cツリーを使用するかどうかは、アプリオリ(例:プロビジョニングを介して)を知られる必要があります。

14.1. Discovering Active Multicast Sources
14.1. アクティブなマルチキャストソースの発見

A PE can obtain information about active multicast sources within a given MVPN in a variety of ways. One way is for the PE to act as a fully functional customer RP (C-RP) for that MVPN. Another way is to use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information about active multicast sources from one or more of the MVPN C-RPs to the PE. Yet another way is to use MSDP [MSDP] to convey information about active multicast sources from the MVPN C-RPs to the PE.

PEは、さまざまな方法で、特定のMVPN内のアクティブなマルチキャストソースに関する情報を取得できます。1つの方法は、PEがそのMVPNの完全に機能する顧客RP(C-RP)として機能することです。別の方法は、PIM Anycast RP手順[PIM-AnyCast-RP]を使用して、MVPN C-RPの1つ以上からPEにアクティブなマルチキャストソースに関する情報を伝えることです。さらに別の方法は、MSDP [MSDP]を使用して、MVPN C-RPSからPEにアクティブなマルチキャストソースに関する情報を伝えることです。

When a PE using any of the above methods first learns of a new (multicast) source within that MVPN, the PE constructs a Source Active A-D route and sends this route to all other PEs that have one or more sites of that MVPN connected to them. The route carries a single MCAST-VPN NLRI constructed as follows:

上記のメソッドのいずれかを使用してPEがそのMVPN内の新しい(マルチキャスト)ソースを最初に学習する場合、PEはソースアクティブA-Dルートを構築し、そのMVPNの1つ以上のサイトがそれらに接続されている他のすべてのPESにこのルートを送信します。。ルートには、次のように構築された単一のmcast-vpn nlriが搭載されています。

+ The RD in this NLRI is set to the RD of the VRF of the MVPN on the PE.

+ このNLRIのRDは、PE上のMVPNのVRFのRDに設定されています。

+ The Multicast Source field MUST be set to the source IP address of the multicast data packet carried in the PIM Register message (RP/PIM register case) or of the MSDP Source-Active message (MSDP case). The Multicast Source Length field is set appropriately to reflect this.

+ マルチキャストソースフィールドは、PIMレジスタメッセージ(RP/PIMレジスタケース)またはMSDPソースアクティブメッセージ(MSDPケース)にあるマルチキャストデータパケットのソースIPアドレスに設定する必要があります。マルチキャストソースの長さフィールドは、これを反映するように適切に設定されています。

+ The Multicast Group field MUST be set to the group IP address of the multicast data packet carried in the PIM Register message (RP/PIM register case) or of the MSDP Source-Active message (MSDP case). The Multicast Group Length field is set appropriately to reflect this.

+ マルチキャストグループフィールドは、PIMレジスタメッセージ(RP/PIMレジスタケース)またはMSDPソースアクティブメッセージ(MSDPケース)にあるマルチキャストデータパケットのグループIPアドレスに設定する必要があります。マルチキャストグループ長フィールドは、これを反映するように適切に設定されています。

The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the IP address that the PE places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the PE.

MP_REACH_NLRI属性の次のホップフィールドは、PEが宣伝されているVPN-IPルートの拡張コミュニティをインポートするVRFルートのグローバル管理者フィールドにPEが配置するIPアドレスに設定する必要があります。

The route SHOULD carry the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN originated by the PE.

ルートは、PEによって発生するMVPNのI-PMSI A-DルートのAs Intra-As-As-As-As-As-As-As-As-As-As-As-As-As-as Asのルートターゲットセットを搭載する必要があります。

Using the normal BGP procedures, the Source Active A-D route is propagated to all the PEs of the MVPN.

通常のBGP手順を使用して、ソースアクティブA-DルートがMVPNのすべてのPESに伝播されます。

When a PE that previously advertised a Source Active A-D route for a given (multicast) source learns that the source is no longer active (the PE learns this by using the same mechanism by which the PE learned that the source was active), the PE SHOULD withdraw the previously advertised Source Active route.

特定の(マルチキャスト)ソースのソースアクティブA-Dルートを以前に宣伝していたPEが、ソースがもはやアクティブではないことを知っている場合(PEは、PEがソースがアクティブであることを学習したのと同じメカニズムを使用してこれを学習します)、PEはPEです)以前に宣伝されていたソースアクティブルートを撤回する必要があります。

14.2. Receiver(s) within a Site
14.2. サイト内のレシーバー

A PE follows the procedures specified in Section 11.1, except that the procedures specified in Section 11.1.1.2 are replaced with the procedures specified in this section.

PEは、セクション11.1で指定された手順に従います。ただし、セクション11.1.1.2で指定された手順は、このセクションで指定された手順に置き換えられます。

When a PE receives a new Source Active A-D route, the PE finds a VRF whose import Route Targets match one or more of the Route Targets carried by the route. If the match is found, then the PE updates the VRF with the received route.

PEが新しいソースActive A-Dルートを受信すると、PEは、ルートがルートで運ばれるルートターゲットの1つ以上と一致する輸入ルートターゲットと一致するVRFを見つけます。一致が見つかった場合、PEは受信ルートでVRFを更新します。

We say that a given (C-S,C-G) Source Active A-D route stored in a given VRF matches a given (C-*,C-G) entry present in the MVPN-TIB associated with the VRF if C-G carried by the route is the same as C-G of the entry.

特定のVRFに保存されている特定の(C-S、C-G)ソースActive A-Dルートは、ルートで運ばれたC-gが同じである場合、VRFに関連付けられたMVPN-TIBに存在する特定の(c - *、C-g)エントリが同じであると一致すると言います。エントリのC-g。

When (as a result of receiving PIM messages from one of its CEs) a PE creates, in one of its MVPN-TIBs, a (new) (C-*,C-G) entry with a non-empty outgoing interface list that contains one or more PE-CE interfaces, the PE MUST check if it has any matching Source Active A-D routes. If there is one or more such matching routes, and the best path to C-S carried in the matching route(s) is reachable through some other PE, then for each such route the PE MUST originate a Source Tree Join C-multicast route. If there is one or more such matching routes, and the best path to C-S carried in the matching route(s) is reachable through a CE connected to the PE, then for each such route the PE MUST originate a PIM Join (C-S,C-G) towards the CE.

(CESの1つからPIMメッセージを受信した結果)PEが、そのMVPN-TIBSの1つで、1つを含む非空白の発信インターフェイスリストを備えた(C-*、C-G)エントリを作成する場合またはそれ以上のPE-CEインターフェイスでは、PEは、一致するソースActive A-Dルートがあるかどうかを確認する必要があります。1つ以上のそのような一致するルートがあり、一致するルートで運ばれるC-Sへの最適なパスが他のPEを介して到達可能である場合、そのようなルートごとに、PEはソースツリーがC-Multicastルートに結合する必要があります。そのような一致するルートが1つ以上あり、マッチングルートで運ばれるC-Sへの最適なパスがPEに接続されたCEを介して到達可能である場合、そのようなルートごとにPEはPIM結合(C-S、C-gを発信する必要があります。)CEに向かって。

When, as a result of receiving a new Source Active A-D route, a PE updates its VRF with the route, the PE MUST check if the newly received route matches any (C-*,C-G) entries. If there is a matching entry, and the best path to C-S carried in the (A-D) route is reachable through some other PE, the PE MUST originate a Source Tree Join C-multicast route for the (C-S,C-G) carried by the route. If there is a matching entry, and the best path to C-S carried in the (A-D) route is reachable through a CE connected to the PE, the PE MUST originate a PIM Join (C-S,C-G) towards the CE.

新しいソースActive A-Dルートを受信した結果、PEはルートでVRFを更新する場合、PEは新しく受信したルートが(C - *、C-G)エントリと一致するかどうかを確認する必要があります。一致するエントリがあり、(A-D)ルートで運ばれるC-Sへの最適なパスが他のPEを介して到達可能な場合、PEはルートによって運ばれる(C-S、C-G)のソースツリーがC-Multicastルートを結合する必要があります。。一致するエントリがあり、(A-D)ルートで運ばれるC-Sへの最適なパスがPEに接続されたCEを介して到達可能である場合、PEはCEに向かってPIM結合(C-S、C-G)を発信する必要があります。

Construction and distribution of the Source Tree Join C-multicast route follows the procedures specified in Section 11.1.1.1, except that the Multicast Source Length, Multicast Source, Multicast Group

ソースツリーの構造と分布結合C-Multicastルートは、マルチキャストソースの長さ、マルチキャストソース、マルチキャストグループを除き、セクション11.1.1.1で指定された手順に従います。

Length, and Multicast Group fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast route are copied from the corresponding field in the Source Active A-D route.

ソースツリーのMCAST-VPN NLRIの長さ、およびマルチキャストグループフィールドは、C-Multicastルートを結合します。ソースActive A-Dルートの対応するフィールドからコピーされます。

A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G) if, as a result of having received PIM messages from one of its CEs, the PE creates a Prune (C-S,C-G,rpt) upstream state in one of its MVPN-TIBs but has no (C-S,C-G) Joined state in that MVPN-TIB and had previously advertised the said route. (This is even if the VRF associated with the MVPN-TIB still has a (C-S,C-G) Source Active A-D route.)

PEは、CESの1つからPIMメッセージを受信した結果、PEがプルーン(C-S、C-G、RPT)上流の状態を1つに作成した場合、ソースツリーがC-Multicastルート(C-S、C-G)のc-multicastルートを結合する必要があります。そのMVPN-TIBSのうち、そのMVPN-TIBで(C-S、C-G)は状態に加わり、以前に上記のルートを宣伝していました。(これは、MVPN-TIBに関連付けられているVRFがまだ(C-S、C-G)ソースActive A-Dルートを持っている場合でもです。)

A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G) if the Source Active A-D route that triggered the advertisement of the C-multicast route is withdrawn.

PEは、C-Multicastルートの広告をトリガーしたソースアクティブA-Dルートが撤回された場合、ソースツリーがC-Multicastルート(C-S、C-G)のC-Multicastルートを結合する必要があります。

When a PE deletes the (C-*,C-G) state (e.g., due to receiving PIM Prune (C-*,C-G) from its CEs), the PE MUST withdraw all the Source Tree Join C-multicast routes for C-G that have been advertised by the PE, except for the routes for which the PE still maintains the corresponding (C-S,C-G) state.

PEが(c - *、c-g)状態を削除する場合(たとえば、CESからpim prune(c-*、c-g)を受信したため、PEはすべてのソースツリーがC-gのC-Multicastルートを結合するすべてのソースツリーを引き出しなければなりません。PEが対応する(C-S、C-G)状態をまだ維持するルートを除いて、PEによって宣伝されています。

Even though PIM is used as a C-multicast protocol, procedures described in Section 11.1.1.2 do not apply here, as only the Source Tree Join C-multicast routes are exchanged among PEs.

PIMはC-Multicastプロトコルとして使用されていますが、セクション11.1.1.2で説明されている手順はここでは適用されません。ソースツリーの結合C-MulticastルートのみがPES間で交換されます。

14.3. Receiving C-Multicast Routes by a PE
14.3. PEでC-Multicastルートを受信します

In this model, the only valid type of a C-multicast route that a PE could receive is a Source Tree Join C-multicast route. Processing of such a route follows the procedures specified in Section 11.3.1.1.

このモデルでは、PEが受信できるCマルチキャストルートの唯一の有効なタイプは、ソースツリーがC-Multicastルートに結合することです。このようなルートの処理は、セクション11.3.1.1で指定された手順に従います。

15. Carrier's Carrier
15. キャリアのキャリア

A way to support the Carrier's Carrier model is provided by using mLDP as the CE-PE multicast routing and label distribution protocol, as specified in this document.

このドキュメントで指定されているように、キャリアのキャリアモデルをサポートする方法は、CE-PEマルチキャストルーティングおよびラベル分布プロトコルとしてMLDPを使用して提供されます。

To improve scalability, it is RECOMMENDED that for the Carrier's Carrier scenario within an AS, all the S-PMSIs of a given MVPN be aggregated into a single P-multicast tree (by using upstream-assigned labels).

スケーラビリティを向上させるには、AS内のキャリアのキャリアシナリオでは、特定のMVPNのすべてのS-PMSIを単一のPマルチキャストツリーに集約することをお勧めします(アップストリーム割り当てラベルを使用して)。

16. Scalability Considerations
16. スケーラビリティの考慮事項

A PE should use Route Target Constraint [RT-CONSTRAIN] to advertise the Route Targets that the PE uses for the VRF Route Imports Extended Community (note that doing this requires just a single Route Target

PEはルートターゲット制約[RT-Constrain]を使用して、VRFルートインポート拡張コミュニティにPEが使用するルートターゲットを宣伝する必要があります(これを行うには、単一のルートターゲットのみが必要であることに注意してください

Constraint advertisement by the PE). This allows each C-multicast route to reach only the relevant PE, rather than all the PEs participating the an MVPN.

PEによる制約広告)。これにより、各C-Multicastルートは、MVPNに参加するすべてのPESではなく、関連するPEのみに到達できます。

To keep the intra-AS membership/binding information within the AS of the advertising router the BGP Update message originated by the advertising router SHOULD carry the NO_EXPORT Community [RFC1997].

ASのAS ASのメンバーシップ/拘束力のある情報を広告ルーター内に維持するには、広告ルーターから発信されるBGP更新メッセージがNO_EXPORTコミュニティ[RFC1997]を搭載する必要があります。

An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-AS I-PMSI A-D routes originated within the ASBR's own AS. Thus, while the Intra-AS I-PMSI A-D routes originated within an AS are at the granularity of <PE, MVPN> within that AS, outside of that AS the (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of <AS, MVPN>. An Inter-AS I-PMSI A-D route for a given <AS, MVPN> indicates the presence of one or more sites of the MVPN connected to the PEs of the AS.

Inter-AS I-PMSI A-Dルートは、ASBR自身のAS内で発生するASBR凝集体Intra-AS I-PMSI A-Dルートによって発生しました。したがって、INTRA-AS I-PMSI A-Dルートは、その中にある<PE、MVPN>の粒度内で、I-PMSI A-Dルートとしての(集約された)INTER AS INTER AS AS AS AS AS AS AS AS AS内で発生しましたが、粒度にあります<as、mvpn>。特定の<AS、MVPN>のI-PMSI A-Dルート間は、ASのPESに接続されたMVPNの1つ以上のサイトの存在を示します。

For a given inter-AS tunnel, each of its intra-AS segments could be constructed by its own mechanism. Moreover, by using upstream-assigned labels within a given AS, multiple intra-AS segments of different inter-AS tunnels of either the same or different MVPNs may share the same P-multicast tree.

特定のトンネル間では、各セグメントの各セグメントは、独自のメカニズムによって構築される可能性があります。さらに、与えられたAS内で上流で割り当てられたラベルを使用することにより、同じまたは異なるMVPNの異なるアナの異なるトンネルの複数のASセグメントのセグメントが同じP-Multicastツリーを共有する場合があります。

Since (aggregated) Inter-AS I-PMSI A-D routes may have a granularity of <AS, MVPN>, an MVPN that is present in N ASes would have total of N inter-AS tunnels. Thus, for a given MVPN, the number of inter-AS tunnels is independent of the number of PEs that have this MVPN.

I-PMSI a-Dルートをinter-as inter-as as <as、mvpn>の粒度を持っている可能性があるため、n asesに存在するmvpnは、トンネル間で合計nを持つことがあります。したがって、与えられたMVPNの場合、トンネル間のインターの数は、このMVPNを持っているPEの数とは無関係です。

Within each Autonomous System, BGP route reflectors can be partitioned among MVPNs present in that Autonomous System so that each partition carries routes for only a subset of the MVPNs supported by the service provider. Thus, no single route reflector is required to maintain routes for all MVPNs. Moreover, route reflectors used for MVPN do not have to be used for VPN-IP routes (although they may be used for VPN-IP routes as well).

各自律システム内で、BGPルートリフレクターは、その自律システムに存在するMVPNに分割することができ、各パーティションはサービスプロバイダーによってサポートされるMVPNのサブセットのみのルートのみを運ぶことができます。したがって、すべてのMVPNのルートを維持するために、単一のルートリフレクターは必要ありません。さらに、MVPNに使用されるルートリフレクターは、VPN-IPルートに使用する必要はありません(ただし、VPN-IPルートにも使用できます)。

As described in Section 11.4, C-multicast routes for a given (S,G) of a given MVPN originated by PEs that are clients of a given route reflector are aggregated by the route reflector. Therefore, even if, within a route reflector cluster, there are multiple C-multicast routes for a given (S,G) of a given MVPN, outside of the cluster, all these routes are aggregated into a single C-multicast route. Additional aggregation of C-multicast routes occurs at ASBRs, where an ASBR aggregates all the received C-multicast routes for a given (S,G) of a given MVPN into a single C-multicast route. Moreover, both route reflectors and ASBRs maintain C-multicast routes only in the control plane, but not in the data plane.

セクション11.4で説明されているように、特定のルートリフレクターのクライアントであるPESが発信する特定のMVPNの特定のMVPNのCマルチキャストルートは、ルートリフレクターによって集約されます。したがって、ルートリフレクタークラスター内で、特定のMVPNの特定の(s、g)の複数のCマルチキャストルートがクラスターの外側にある場合でも、これらすべてのルートは単一のCマルチキャストルートに集約されます。C-Multicastルートの追加の集約はASBRで発生します。ASBRは、特定のMVPNの特定の(S、G)のすべての受信されたCマルチキャストルートを単一のCマルチキャストルートに集約します。さらに、ルートリフレクターとASBRの両方は、コントロールプレーンでのみCマルチキャストルートを維持しますが、データプレーンでは維持していません。

16.1. Dampening C-Multicast Routes
16.1. C-Multicastルートの減衰

The rate of C-multicast routing changes advertised by a PE is not necessarily directly proportional to the rate of multicast routing changes within the MVPN sites connected to the PE, as after the first (C-S,C-G) Join originated within a site, all the subsequent Joins for same (C-S,C-G) originated within the sites of the same MVPN connected to the PE do not cause origination of new C-multicast routes by the PE.

PEによって宣伝されているc-multicastルーティングの変更のレートは、最初の(c-s、c-g)結合後、すべてのサイト内で発信された後、PEに接続されたMVPNサイト内のマルチキャストルーティングの変化のレートに必ずしも直接比例しないとは限りません。後続の結合は、PEに接続された同じMVPNの部位内で同じ(C-S、C-G)で結合されても、PEによる新しいCマルチキャストルートの起源を引き起こしません。

Depending on how multicast VPN is engineered, dynamic addition and removal of P2MP RSVP-TE leaves through advertisement/withdrawal of Leaf A-D routes will happen. Dampening techniques can be used to limit corresponding processing.

マルチキャストVPNの設計方法に応じて、Leaf A-Dルートの広告/引き出しを通じてP2MP RSVP-TE葉の動的な追加と除去が発生します。減衰技術を使用して、対応する処理を制限できます。

To lessen the control plane overhead associated with the processing of C-multicast routes, this document proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]. The following OPTIONAL procedures can be enabled on a PE, ASBR, or BGP Route Reflector advertising or receiving C-multicast routes.

C-Multicastルートの処理に関連するコントロールプレーンのオーバーヘッドを軽減するために、このドキュメントは、[RFC2439]で説明されているものと同様のオプションのルート減衰手順を提案します。PE、ASBR、またはBGPルートリフレクターの広告またはCマルチキャストルートの受信で、次のオプション手順を有効にできます。

16.1.1. Dampening Withdrawals of C-Multicast Routes
16.1.1. C-Multicastルートの撤退を減衰させます

A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of withdrawals of C-multicast routes. An implementation SHOULD provide the ability to control the delay via a configurable timer, possibly with some backoff algorithm to adapt the delay to multicast routing activity.

PE/ASBR/ルートリフレクターは、オプションでC-Multicastルートの引き出しの広告を遅らせることができます。実装は、おそらくマルチキャストルーティングアクティビティに遅延を適応させるためのバックオフアルゴリズムを使用して、構成可能なタイマーを介して遅延を制御する機能を提供する必要があります。

Dampening of withdrawals of C-multicast routes does not impede the multicast Join latency observed by MVPN customers, and it also does not impede the multicast leave latency observed by a CE, as multicast forwarding from the VRF will stop as soon as C-multicast state is removed in the VRF.

Cマルチキャストルートの撤退の減衰は、MVPNの顧客が観察したマルチキャスト結合レイテンシーを妨げません。また、VRFからのマルチキャスト転送がC-Multicast状態になるとすぐに停止するため、CEによって観察されるマルチキャストの休暇の遅延を妨げません。VRFで削除されます。

The potential drawbacks of dampening of withdrawals of C-multicast routes are as follows:

Cマルチキャストルートの撤退の減衰の潜在的な欠点は次のとおりです。

+ Until the withdrawals are actually sent, multicast traffic for the C-multicast routes in question will be continued to be transmitted to the PE, which will just have to discard it. Note that the PE may receive useless (multicast) traffic anyway, irrespective of dampening of withdrawals of C-multicast routes due to the use of I-PMSIs.

+ 撤退が実際に送信されるまで、問題のCマルチキャストルートのマルチキャストトラフィックはPEに送信され続けます。これはただ廃棄する必要があります。とにかく、PEは、I-PMSISの使用によるCマルチキャストルートの引き出しの減衰に関係なく、役に立たない(マルチキャスト)トラフィックを受ける可能性があることに注意してください。

+ Any state in the upstream PEs that would be removed as a result of processing the withdrawals will remain until the withdrawals are sent.

+ 処理の結果として削除される上流のPESのすべての状態は、引き出しが送られるまで残ります。

Discussion on whether the potential drawbacks mentioned above are of any practical significance is outside the scope of this document.

上記の潜在的な欠点が実際的に重要であるかどうかについての議論は、このドキュメントの範囲外です。

16.1.2. Dampening Source/Shared Tree Join C-Multicast Routes
16.1.2. SOURCE/共有ツリーがC-Multicastルートに参加します

A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of Source/Shared Tree Join C-multicast routes. An implementation SHOULD provide the ability to control the delay via a configurable timer, possibly with some backoff algorithm to adapt the delay to multicast routing activity.

PE/ASBR/ルートリフレクターは、オプションでSource/Shared Tree Join C-Multicastルートの広告を遅らせることができます。実装は、おそらくマルチキャストルーティングアクティビティに遅延を適応させるためのバックオフアルゴリズムを使用して、構成可能なタイマーを介して遅延を制御する機能を提供する必要があります。

Dampening Source/Shared Tree Join C-multicast routes will not impede multicast Join latency observed by a given MVPN, except if the PE advertising the Source/Shared Tree Join C-multicast route for a particular C-S/C-RP is the first to do so for all the sites of the MVPN that share the same upstream PE with respect to the C-S/C-RP.

SOURCE/共有ツリーの減衰C-Multicastルートの結合ルートは、特定のC-S/C-RPのソース/共有ツリーにC-Multicastルートを宣伝するPEが最初に行う場合を除きます。したがって、C-S/C-RPに関して同じ上流のPEを共有するMVPNのすべてのサイトに対して。

16.2. Dampening Withdrawals of Leaf A-D Routes
16.2. 葉のA-Dルートの撤退を減衰させます

Similar to the procedures proposed above for withdrawal of C-multicast routes, dampening can be applied to the withdrawal of Leaf A-D routes.

c-multicastルートの撤退のために上記の提案された手順と同様に、湿潤は葉のA-Dルートの撤回に適用できます。

17. Security Considerations
17. セキュリティに関する考慮事項

The mechanisms described in this document could reuse the existing BGP security mechanisms [RFC4271] [RFC4272]. The security model and threats specific to Provider Provisioned VPNs, including L3VPNs, are discussed in [RFC4111]. [MVPN] discusses additional threats specific to the use of multicast in L3VPNs. There is currently work in progress to improve the security of TCP authentication. When the document is finalized as an RFC, the method defined in [RFC5925] SHOULD be used where authentication of BGP control packets is needed.

このドキュメントで説明されているメカニズムは、既存のBGPセキュリティメカニズム[RFC4271] [RFC4272]を再利用できます。L3VPNを含むプロバイダープロビジョニングVPNに固有のセキュリティモデルと脅威については、[RFC4111]で説明しています。[MVPN]は、L3VPNでのマルチキャストの使用に固有の追加の脅威について説明します。現在、TCP認証のセキュリティを改善するための作業が進行中です。ドキュメントがRFCとして確定されている場合、[RFC5925]で定義された方法を使用する必要があります。ここでは、BGP制御パケットの認証が必要です。

A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI.

PEルーターは、CESルートからmcast-vpn safiを使用して受け入れてはなりません。

If BGP is used as a CE-PE routing protocol, then when a PE receives a route from a CE, if this route carries the VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPN-IP route. Routes that a PE advertises to a CE MUST NOT carry the VRF Route Import Extended Community.

BGPがCE-PEルーティングプロトコルとして使用される場合、PEがCEからルートを受信する場合、このルートがVRFルートインポートエクステンションコミュニティを運ぶ場合、PEはVPNに変える前にこのコミュニティをルートから削除する必要があります。ipルート。PEがCEに宣伝するルートは、VRFルートインポートエクステンションコミュニティを運ぶべきではありません。

It is important to protect the control plane resources within the PE to prevent any one VPN from hogging excessive resources. This is the subject of the remainder of the Security Considerations section.

PE内のコントロールプレーンのリソースを保護して、1つのVPNが過剰なリソースを抱えないようにすることが重要です。これは、セキュリティ上の考慮事項の残りのセクションの主題です。

When C-multicast routing information is exchanged among PEs using BGP, an implementation SHOULD provide the ability to rate limit BGP messages used for this exchange. This SHOULD be provided on a per-PE, per-MVPN granularity.

C-Multicastルーティング情報がBGPを使用してPES間で交換される場合、実装はこの交換に使用されるBGPメッセージを制限する機能を提供する必要があります。これは、PE、PER-MVPN粒度で提供する必要があります。

An implementation SHOULD provide capabilities to impose an upper bound on the number of S-PMSI A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per-PE, per-MVPN granularity.

実装は、S-PMSI A-Dルートの数とそれらがどれだけ頻繁に発生するかに上限を課す機能を提供する必要があります。これは、PE、PER-MVPN粒度で提供する必要があります。

In conjunction with the procedures specified in Section 14, an implementation SHOULD provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per-PE, per-MVPN granularity.

セクション14で指定された手順と併せて、実装は、ソースアクティブA-Dルートの数とそれらがどれだけ頻繁に発生するかに上限を課す機能を提供する必要があります。これは、PE、PER-MVPN粒度で提供する必要があります。

In conjunction with the procedures specified in Section 13 limiting the amount of (C-S,C-G) state would limit the amount of Source Active A-D route, as in the context of this section, Source Active A-D routes are created in response to Source Tree Join C-multicast routes, and Source Tree Join C-multicast routes are created as a result of creation of (C-S,C-G) state on PEs. However, to provide an extra level of robustness in the context of these procedures, an implementation MAY provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This MAY be provided on a per-PE, per-MVPN granularity.

(C-S、C-G)状態の量を制限するセクション13で指定された手順と併せて、このセクションのコンテキストでは、ソースアクティブA-Dルートがソースツリー結合Cに応答して作成されるように、ソースアクティブA-Dルートの量を制限します。-Multicastルート、およびソースツリー結合Cマルチキャストルートは、PESで(C-S、C-G)状態の作成の結果として作成されます。ただし、これらの手順のコンテキストで余分なレベルの堅牢性を提供するために、実装は、ソースアクティブA-Dルートの数とそれらがどれだけ頻繁に発生するかに上限を課す機能を提供する場合があります。これは、PE、PER-MVPN粒度で提供される場合があります。

Section 16.1.1 describes optional procedures for dampening withdrawals of C-multicast routes. It is RECOMMENDED that an implementation support such procedures.

セクション16.1.1では、Cマルチキャストルートの撤退を減衰させるためのオプションの手順について説明します。実装がそのような手順をサポートすることをお勧めします。

Section 16.1.1 describes optional procedures for dampening withdrawals of Leaf A-D routes. It is RECOMMENDED that an implementation support such procedures.

セクション16.1.1では、Leaf A-Dルートの引き下げを減衰させるためのオプションの手順について説明します。実装がそのような手順をサポートすることをお勧めします。

18. IANA Considerations
18. IANAの考慮事項

This document defines a new BGP Extended Community called "Source AS". This Community is of an extended type and is transitive. The Type value for this Community has been allocated from the two-octet AS-Specific Extended Community registry as 0x0009 and from the four-octet AS-Specific Extended Community registry as 0x0209.

このドキュメントでは、「Source As」と呼ばれる新しいBGP拡張コミュニティを定義しています。このコミュニティは拡張されたタイプであり、推移的です。このコミュニティのタイプ値は、0x0009として2-OCTET AS固有の拡張コミュニティレジストリから、および4-OCTET AS固有の拡張コミュニティレジストリから0x0209として割り当てられています。

This document defines a new BGP Extended Community called "VRF Route Import" (Type value 0x010b). This Community is IP address specific, of an extended type, and is transitive.

このドキュメントでは、「VRFルートインポート」(タイプ値0x010B)と呼ばれる新しいBGP拡張コミュニティを定義します。このコミュニティは、拡張タイプのIPアドレス固有であり、推移的です。

This document defines a new NLRI, called "MCAST-VPN", to be carried in BGP using multiprotocol extensions. It has been assigned SAFI 5. Also, SAFI 129 has been assigned to "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)".

このドキュメントでは、マルチプロトコル拡張を使用してBGPで携帯する「mcast-vpn」と呼ばれる新しいNLRIを定義します。SAFI 5が割り当てられています。SAFI129は、「BGP/MPLS IP仮想ネットワーク(VPNS)のマルチキャスト」に割り当てられています。

This document defines a new BGP optional transitive attribute, called "PMSI_TUNNEL". IANA has assigned the codepoint 22 in the "BGP Path Attributes" registry to the PMSI_TUNNEL attribute.

このドキュメントでは、「PMSI_Tunnel」と呼ばれる新しいBGPオプションのTransitive属性を定義します。IANAは、「BGPパス属性」レジストリにPMSI_Tunnel属性にCodePoint 22を割り当てました。

This document defines a new BGP optional transitive attribute, called "PE Distinguisher Labels". IANA has assigned the codepoint 27 in the "BGP Path Attributes" registry to the PE Distinguisher Labels attribute.

このドキュメントでは、「PE distiutiuseerラベル」と呼ばれる新しいBGPオプションのTransitive属性を定義します。IANAは、「BGPパス属性」レジストリにCodePoint 27をPE Distimuisher Labels属性に割り当てました。

19. Acknowledgements
19. 謝辞

We would like to thank Chaitanya Kodeboniya for helpful discussions. We would also like to thank members of the L3VPN IETF Working Group for insightful comments and review.

有益な議論をしてくれたChaitanya Kodeboniyaに感謝します。また、L3VPN IETFワーキンググループのメンバーに洞察に富んだコメントとレビューについて感謝したいと思います。

20. References
20. 参考文献
20.1. Normative References
20.1. 引用文献

[IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", http://www.iana.org.

[IANA-Safi] IANA、「後続の住所ファミリ識別子(SAFI)パラメーター」、http://www.iana.org。

[MVPN] Rosen, E., Ed. and R. Aggarwal, Ed., "Mulitcast in MPLS/BGP IP VPNs", RFC 6513, February 2012.

[MVPN] Rosen、E.、ed。and R. Aggarwal、ed。、「MPLS/BGP IP VPNSのMulitcast」、RFC 6513、2012年2月。

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.

[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities属性」、RFC 1997、1996年8月。

[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月。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4(BGP-4)」、RFC 4271、2006年1月。

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク(VPNS)」、RFC 4364、2006年2月。

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード(PIM -SM):プロトコル仕様(改訂)」、RFC 4601、2006年8月。

[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.

[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想プライベートネットワーク(VPN)IPv6 VPNの拡張」、RFC 4659、2006年9月。

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。

20.2. Informative References
20.2. 参考引用

[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月。

[MSDP] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[MSDP] Fenner、B.、ed。、およびD. Meyer、ed。、「Multicast Source Discovery Protocol(MSDP)」、RFC 3618、2003年10月。

[PIM-ANYCAST-RP] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.

[PIM-ANYCAST-RP] Farinacci、D。およびY. Cai、「プロトコル独立マルチキャスト(PIM)を使用したAnycast-RP」、RFC 4610、2006年8月。

[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 Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。

[RT-CONSTRAIN] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.

[RT-Constrain] Marques、P.、Bonica、R.、Fang、L.、Martini、L.、Raszuk、R.、Patel、K。、およびJ. Guichard、 "境界ゲートウェイプロトコル/マルチプロトコルの制約付きルート分布ラベルスイッチング(BGP/MPLS)インターネットプロトコル(IP)仮想プライベートネットワーク(VPNS) "、RFC 4684、2006年11月。

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.

[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。

[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.

[RFC4111] Fang、L.、ed。、「プロバイダーが提供する仮想プライベートネットワーク(PPVPNS)のセキュリティフレームワーク」、RFC 4111、2005年7月。

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.

[RFC4272] Murphy、S。、「BGPセキュリティ脆弱性分析」、RFC 4272、2006年1月。

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.

[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学(RSVP-TE)スイッチPaths(LSP) "、RFC 4875、2007年5月。

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.

[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト(Bidir-PIM)」、RFC 5015、2007年10月。

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.

[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 5925、2010年6月。

Authors' Addresses

著者のアドレス

Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: raggarwa_1@yahoo.com

Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール:raggarwa_1@yahoo.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

Thomas Morin France Telecom - Orange 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@orange.com

トーマスモリンフランステレコム - オレンジ2、アベニューピエールマルジン22307ラニオンセデックスフランスメール:thomas.morin@orange.com

Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: yakov@juniper.net

Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール:yakov@juniper.net