[要約] RFC 8293は、ネットワーク仮想化におけるレイヤ3上のマルチキャストのためのフレームワークを提供しています。このRFCの目的は、ネットワーク仮想化環境でのマルチキャスト通信の設計と実装を支援することです。
Internet Engineering Task Force (IETF) A. Ghanwani
Request for Comments: 8293 Dell
Category: Informational L. Dunbar
ISSN: 2070-1721 M. McBride
Huawei
V. Bannai
Google
R. Krishnan
Dell
January 2018
A Framework for Multicast in Network Virtualization over Layer 3
レイヤー3上のネットワーク仮想化におけるマルチキャストのフレームワーク
Abstract
概要
This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.
このドキュメントは、レイヤー3（NVO3）上のネットワーク仮想化を使用するネットワークでマルチキャストトラフィックをサポートするためのフレームワークを提供します。インフラストラクチャマルチキャストとアプリケーション固有のマルチキャストの両方について説明します。このようなトラフィックの配信に使用できるさまざまなメカニズム、および各メカニズムのデータプレーンとコントロールプレーンの考慮事項について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8293.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8293で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Infrastructure Multicast . . . . . . . . . . . . . . . . 3
1.2. Application-Specific Multicast . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Multicast Mechanisms in Networks That Use NVO3 . . . . . . . 5
3.1. No Multicast Support . . . . . . . . . . . . . . . . . . 6
3.2. Replication at the Source NVE . . . . . . . . . . . . . . 6
3.3. Replication at a Multicast Service Node . . . . . . . . . 8
3.4. IP Multicast in the Underlay . . . . . . . . . . . . . . 10
3.5. Other Schemes . . . . . . . . . . . . . . . . . . . . . . 11
4. Simultaneous Use of More Than One Mechanism . . . . . . . . . 12
5. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Multicast-Agnostic NVEs . . . . . . . . . . . . . . . . . 12
5.2. Multicast Membership Management for DC with VMs . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Network Virtualization over Layer 3 (NVO3) [RFC7365] is a technology that is used to address issues that arise in building large, multi-tenant data centers (DCs) that make extensive use of server virtualization [RFC7364].
レイヤー3上のネットワーク仮想化（NVO3）[RFC7365]は、サーバー仮想化[RFC7364]を広範囲に使用する大規模なマルチテナントデータセンター（DC）の構築で発生する問題に対処するために使用されるテクノロジーです。
This document provides a framework for supporting multicast traffic in a network that uses NVO3. Both infrastructure multicast and application-specific multicast are considered. It describes various mechanisms, and the considerations of each of them, that can be used for delivering such traffic in networks that use NVO3.
このドキュメントは、NVO3を使用するネットワークでマルチキャストトラフィックをサポートするためのフレームワークを提供します。インフラストラクチャマルチキャストとアプリケーション固有のマルチキャストの両方が考慮されます。 NVO3を使用するネットワークでこのようなトラフィックを配信するために使用できるさまざまなメカニズムと、それぞれの考慮事項について説明します。
The reader is assumed to be familiar with the terminology and concepts as defined in the NVO3 Framework [RFC7365] and NVO3 Architecture [RFC8014] documents.
読者は、NVO3フレームワーク[RFC7365]およびNVO3アーキテクチャ[RFC8014]のドキュメントで定義されている用語と概念に精通していることを前提としています。
Infrastructure multicast refers to networking services that require multicast or broadcast delivery, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc., some of which are described in Sections 5 and 6 of RFC 3819 [RFC3819]. It is possible to provide solutions for these services that do not involve multicast in the underlay network. For example, in the case of ARP/ND, a Network Virtualization Authority (NVA) can be used for distributing the IP address to Media Access Control (MAC) address mappings to all of the Network Virtualization Edges (NVEs). An NVE can then trap ARP Request and/or ND Neighbor Solicitation messages from the Tenant Systems (TSs) that are attached to it and respond to them, thereby eliminating the need for the broadcast/multicast of such messages. In the case of DHCP, the NVE can be configured to forward these messages using the DHCP relay function [RFC2131].
インフラストラクチャマルチキャストとは、アドレス解決プロトコル（ARP）、近隣探索（ND）、動的ホスト構成プロトコル（DHCP）、マルチキャストドメインネームサーバー（mDNS）など、マルチキャストまたはブロードキャスト配信を必要とするネットワーキングサービスを指します。 RFC 3819 [RFC3819]のセクション5および6で説明されています。アンダーレイネットワークでのマルチキャストを含まないこれらのサービスのソリューションを提供することが可能です。たとえば、ARP / NDの場合、ネットワーク仮想化機関（NVA）を使用して、すべてのネットワーク仮想化エッジ（NVE）へのメディアアクセスコントロール（MAC）アドレスマッピングへのIPアドレスを配布できます。次に、NVEは、それに接続されているテナントシステム（TS）からのARP要求メッセージやND近隣要請メッセージをトラップして応答できるため、そのようなメッセージのブロードキャスト/マルチキャストの必要性がなくなります。 DHCPの場合、NVEはDHCPリレー機能[RFC2131]を使用してこれらのメッセージを転送するように構成できます。
Of course, it is possible to support all of these infrastructure multicast protocols natively if the underlay provides multicast transport. However, even in the presence of multicast transport, it may be beneficial to use the optimizations mentioned above to reduce the amount of such traffic in the network.
もちろん、アンダーレイがマルチキャストトランスポートを提供している場合は、これらのインフラストラクチャマルチキャストプロトコルをすべてネイティブでサポートできます。ただし、マルチキャストトランスポートが存在する場合でも、上記の最適化を使用してネットワーク内のそのようなトラフィックの量を減らすことは有益です。
Application-specific multicast traffic refers to multicast traffic that originates and is consumed by user applications. Several such applications are described elsewhere [DC-MC]. Application-specific multicast may be either Source-Specific Multicast (SSM) or Any-Source Multicast (ASM) [RFC3569] and has the following characteristics:
アプリケーション固有のマルチキャストトラフィックとは、ユーザーアプリケーションによって発信および消費されるマルチキャストトラフィックを指します。このようなアプリケーションのいくつかは、他の場所で説明されています[DC-MC]。アプリケーション固有のマルチキャストは、Source-Specific Multicast（SSM）またはAny-Source Multicast（ASM）[RFC3569]のいずれかであり、次の特性があります。
1. Receiver hosts are expected to subscribe to multicast content using protocols such as IGMP [RFC3376] (IPv4) or Multicast Listener Discovery (MLD) [RFC2710] (IPv6). Multicast sources and listeners participate in these protocols using addresses that are in the TS address domain.
1. レシーバーホストは、IGMP [RFC3376]（IPv4）またはマルチキャストリスナーディスカバリ（MLD）[RFC2710]（IPv6）などのプロトコルを使用してマルチキャストコンテンツにサブスクライブすることが期待されています。マルチキャストのソースとリスナーは、TSアドレスドメインにあるアドレスを使用してこれらのプロトコルに参加します。
2. The set of multicast listeners for each multicast group may not be known in advance. Therefore, it may not be possible or practical for an NVA to get the list of participants for each multicast group ahead of time.
2. 各マルチキャストグループのマルチキャストリスナーのセットは、事前にわかっていない場合があります。したがって、NVAが各マルチキャストグループの参加者のリストを事前に取得することは不可能または現実的ではない場合があります。
In this document, the terms host, Tenant System (TS), and Virtual Machine (VM) are used interchangeably to represent an end station that originates or consumes data packets.
このドキュメントでは、ホスト、テナントシステム（TS）、および仮想マシン（VM）という用語は、データパケットを発信または消費するエンドステーションを表すために同じ意味で使用されています。
ASM: Any-Source Multicast
ASM：Any-Source Multicast
IGMP: Internet Group Management Protocol
IGMP：インターネットグループ管理プロトコル
LISP: Locator/ID Separation Protocol
LISP：ロケーター/ ID分離プロトコル
MSN: Multicast Service Node
MSN：マルチキャストサービスノード
RLOC: Routing Locator
RLOC：ルーティングロケーター
NVA: Network Virtualization Authority
NVA：ネットワーク仮想化局
NVE: Network Virtualization Edge
NVE：ネットワーク仮想化エッジ
NVGRE: Network Virtualization using GRE
NVGRE：GREを使用したネットワーク仮想化
PIM: Protocol-Independent Multicast
PIM：プロトコルに依存しないマルチキャスト
SSM: Source-Specific Multicast
SSM：ソース固有のマルチキャスト
TS: Tenant System
TS：テナントシステム
VM: Virtual Machine VN: Virtual Network
VM：仮想マシンVN：仮想ネットワーク
VTEP: VXLAN Tunnel End Point
VTEP：VXLANトンネルエンドポイント
VXLAN: Virtual eXtensible LAN
VXLAN：仮想拡張可能LAN
In NVO3 environments, traffic between NVEs is transported using an encapsulation such as VXLAN [RFC7348] [VXLAN-GPE], Network Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637], Geneve [Geneve], Generic UDP Encapsulation [GUE], etc.
NVO3環境では、NVE間のトラフィックは、VXLAN [RFC7348] [VXLAN-GPE]、Generic Routing Encapsulation（NVGRE）[RFC7637]、Geneve [Geneve]、Generic UDP Encapsulation [GUE]などのカプセル化を使用して転送されます。 。
What makes networks using NVO3 different from other networks is that some NVEs, especially NVEs implemented in servers, might not support regular multicast protocols such as PIM. Instead, the only capability they may support would be that of encapsulating data packets from VMs with an outer unicast header. Therefore, it is important for networks using NVO3 to have mechanisms to support multicast as a network capability for NVEs, to map multicast traffic from VMs (users/applications) to an equivalent multicast capability inside the NVE, or to figure out the outer destination address if NVE does not support native multicast (e.g., PIM) or IGMP.
NVO3を使用するネットワークが他のネットワークと異なる点は、一部のNVE、特にサーバーに実装されたNVEは、PIMなどの通常のマルチキャストプロトコルをサポートしない可能性があることです。代わりに、サポートする機能は、VMからのデータパケットを外部ユニキャストヘッダーでカプセル化することだけです。したがって、NVO3を使用するネットワークには、NVEのネットワーク機能としてマルチキャストをサポートするメカニズム、VM（ユーザー/アプリケーション）からのマルチキャストトラフィックをNVE内の同等のマルチキャスト機能にマップする、または外部宛先アドレスを把握するメカニズムが重要です。 NVEがネイティブマルチキャスト（PIMなど）またはIGMPをサポートしていない場合。
With NVO3, there are many possible ways that multicast may be handled in such networks. We discuss some of the attributes of the following four methods:
NVO3を使用すると、このようなネットワークでマルチキャストを処理できる方法が多数あります。以下の4つのメソッドの属性のいくつかについて説明します。
1. No multicast support
1. マルチキャストサポートなし
2. Replication at the source NVE
2. ソースNVEでのレプリケーション
3. Replication at a multicast service node
3. マルチキャストサービスノードでのレプリケーション
4. IP multicast in the underlay
4. アンダーレイのIPマルチキャスト
These methods are briefly mentioned in the NVO3 Framework [RFC7365] and NVO3 Architecture [RFC8014] documents. This document provides more details about the basic mechanisms underlying each of these methods and discusses the issues and trade-offs of each.
これらのメソッドは、NVO3フレームワーク[RFC7365]およびNVO3アーキテクチャ[RFC8014]のドキュメントで簡単に説明されています。このドキュメントでは、これらの各メソッドの基礎となる基本的なメカニズムについて詳しく説明し、それぞれの問題とトレードオフについて説明します。
We note that other methods are also possible, such as [EDGE-REP], but we focus on the above four because they are the most common.
[EDGE-REP]などの他の方法も可能であることに注意しますが、最も一般的なので上記の4つに焦点を当てます。
It is worth noting that when selecting a multicast mechanism, it is useful to consider the impact of these on any multicast congestion control mechanisms that applications may be using to obtain the desired system dynamics. In addition, the same rules for Explicit Congestion Notification (ECN) would apply to multicast traffic being encapsulated, as for unicast traffic [RFC6040].
マルチキャストメカニズムを選択するとき、アプリケーションが目的のシステムダイナミクスを取得するために使用している可能性があるマルチキャスト輻輳制御メカニズムに対するこれらの影響を考慮することは重要です。さらに、ユニキャストトラフィック[RFC6040]と同様に、カプセル化されるマルチキャストトラフィックにも、明示的輻輳通知（ECN）と同じルールが適用されます。
In this scenario, there is no support whatsoever for multicast traffic when using the overlay. This method can only work if the following conditions are met:
このシナリオでは、オーバーレイを使用する場合、マルチキャストトラフィックはまったくサポートされません。この方法は、次の条件が満たされた場合にのみ機能します。
1. All of the application traffic in the network is unicast traffic, and the only multicast/broadcast traffic is from ARP/ND protocols.
1. ネットワーク内のすべてのアプリケーショントラフィックはユニキャストトラフィックであり、唯一のマルチキャスト/ブロードキャストトラフィックはARP / NDプロトコルからのものです。
2. An NVA is used by all of the NVEs to determine the mapping of a given TS's MAC and IP address to the NVE that it is attached to. In other words, there is no data-plane learning. Address resolution requests via ARP/ND that are issued by the TSs must be resolved by the NVE that they are attached to.
2. NVAはすべてのNVEによって使用され、接続されているNVEへの特定のTSのMACおよびIPアドレスのマッピングを決定します。つまり、データプレーンの学習はありません。 TSによって発行されたARP / NDを介したアドレス解決要求は、それらが接続されているNVEによって解決される必要があります。
With this approach, it is not possible to support application-specific multicast. However, certain multicast/broadcast applications can be supported without multicast; for example, DHCP, which can be supported by use of DHCP relay function [RFC2131].
このアプローチでは、アプリケーション固有のマルチキャストをサポートすることはできません。ただし、特定のマルチキャスト/ブロードキャストアプリケーションは、マルチキャストなしでサポートできます。たとえば、DHCPはDHCPリレー機能[RFC2131]を使用してサポートできます。
The main drawback of this approach, even for unicast traffic, is that it is not possible to initiate communication with a TS for which a mapping to an NVE does not already exist at the NVA. This is a problem in the case where the NVE is implemented in a physical switch and the TS is a physical end station that has not registered with the NVA.
このアプローチの主な欠点は、ユニキャストトラフィックであっても、NVEへのマッピングがNVAにまだ存在しないTSとの通信を開始できないことです。これは、NVEが物理スイッチに実装され、TSがNVAに登録されていない物理エンドステーションである場合の問題です。
With this method, the overlay attempts to provide a multicast service without requiring any specific support from the underlay, other than that of a unicast service. A multicast or broadcast transmission is achieved by replicating the packet at the source NVE and making copies, one for each destination NVE that the multicast packet must be sent to.
この方法では、オーバーレイは、ユニキャストサービス以外のアンダーレイからの特定のサポートを必要とせずに、マルチキャストサービスを提供しようとします。マルチキャストまたはブロードキャスト送信は、送信元NVEでパケットを複製し、マルチキャストパケットの送信先である宛先NVEごとに1つずつコピーを作成することで実現されます。
For this mechanism to work, the source NVE must know, a priori, the IP addresses of all destination NVEs that need to receive the packet. For the purpose of ARP/ND, this would involve knowing the IP addresses of all the NVEs that have TSs in the VN of the TS that generated the request.
このメカニズムが機能するためには、送信元NVEが、パケットを受信する必要があるすべての宛先NVEのIPアドレスをアプリオリに知っている必要があります。 ARP / NDの目的で、これには、要求を生成したTSのVNにTSを持つすべてのNVEのIPアドレスを知ることが含まれます。
For the support of application-specific multicast traffic, a method similar to that of receiver-sites registration for a particular multicast group, described in [LISP-Signal-Free], can be used. The registrations from different receiver sites can be merged at the NVA, which can construct a multicast replication list inclusive of all NVEs to which receivers for a particular multicast group are attached. The replication list for each specific multicast group is maintained by the NVA. Note that using receiver-sites registration does not necessarily mean the source NVE must do replication. If the NVA indicates that multicast packets are encapsulated to multicast service nodes, then there would be no replication at the NVE.
アプリケーション固有のマルチキャストトラフィックをサポートするには、[LISP-Signal-Free]で説明されている、特定のマルチキャストグループの受信側サイト登録と同様の方法を使用できます。異なるレシーバーサイトからの登録をNVAでマージできます。これにより、特定のマルチキャストグループのレシーバーが接続されているすべてのNVEを含むマルチキャストレプリケーションリストを構築できます。特定の各マルチキャストグループのレプリケーションリストは、NVAによって維持されます。レシーバーサイトの登録を使用しても、ソースNVEがレプリケーションを実行する必要があるとは限りません。 NVAがマルチキャストパケットがマルチキャストサービスノードにカプセル化されることを示している場合、NVEでの複製はありません。
The receiver-sites registration is achieved by egress NVEs performing IGMP/MLD snooping to maintain the state for which attached TSs have subscribed to a given IP multicast group. When the members of a multicast group are outside the NVO3 domain, it is necessary for NVO3 gateways to keep track of the remote members of each multicast group. The NVEs and NVO3 gateways then communicate with the multicast groups that are of interest to the NVA. If the membership is not communicated to the NVA, and if it is necessary to prevent TSs attached to an NVE that have not subscribed to a multicast group from receiving the multicast traffic, the NVE would need to maintain multicast group membership information.
受信側サイトの登録は、接続されたTSが特定のIPマルチキャストグループにサブスクライブした状態を維持するためにIGMP / MLDスヌーピングを実行する出力NVEによって実現されます。マルチキャストグループのメンバーがNVO3ドメインの外部にある場合、NVO3ゲートウェイは各マルチキャストグループのリモートメンバーを追跡する必要があります。次に、NVEとNVO3ゲートウェイは、NVAに関係のあるマルチキャストグループと通信します。メンバーシップがNVAに伝達されず、マルチキャストグループにサブスクライブしていないNVEに接続されたTSがマルチキャストトラフィックを受信しないようにする必要がある場合、NVEはマルチキャストグループメンバーシップ情報を維持する必要があります。
In the absence of IGMP/MLD snooping, the traffic would be delivered to all TSs that are part of the VN.
IGMP / MLDスヌーピングがない場合、トラフィックはVNの一部であるすべてのTSに配信されます。
In multihoming environments, i.e., in those where a TS is attached to more than one NVE, the NVA would be expected to provide information to all of the NVEs under its control about all of the NVEs to which such a TS is attached. The ingress NVE can then choose any one of those NVEs as the egress NVE for the data frames destined towards the multi-homed TS.
マルチホーミング環境、つまり、TSが複数のNVEに接続されている環境では、NVAは、そのTSが接続されているすべてのNVEについて、その制御下にあるすべてのNVEに情報を提供することが期待されます。次に、入力NVEは、マルチホームTS宛てのデータフレームの出力NVEとして、これらのNVEのいずれかを選択できます。
This method requires multiple copies of the same packet to all NVEs that participate in the VN. If, for example, a tenant subnet is spread across 50 NVEs, the packet would have to be replicated 50 times at the source NVE. Obviously, this approach creates more traffic to the network that can cause congestion when the network load is high. This also creates an issue with the forwarding performance of the NVE.
この方法では、VNに参加するすべてのNVEに同じパケットの複数のコピーが必要です。たとえば、テナントサブネットが50個のNVEに分散している場合、パケットはソースNVEで50回複製される必要があります。明らかに、このアプローチはネットワークへのトラフィックを増やし、ネットワークの負荷が高いときに輻輳を引き起こす可能性があります。これにより、NVEの転送パフォーマンスにも問題が発生します。
Note that this method is similar to what was used in Virtual Private LAN Service (VPLS) [RFC4762] prior to support of Multiprotocol Label Switching (MPLS) multicast [RFC7117]. While there are some similarities between MPLS Virtual Private Network (VPN) and NVO3, there are some key differences:
この方法は、マルチプロトコルラベルスイッチング（MPLS）マルチキャスト[RFC7117]をサポートする前は、仮想プライベートLANサービス（VPLS）[RFC4762]で使用されていた方法と似ていることに注意してください。 MPLSバーチャルプライベートネットワーク（VPN）とNVO3の間にはいくつかの類似点がありますが、いくつかの重要な違いがあります。
o The attachment from Customer Edge (CE) to Provider Edge (PE) in VPNs is somewhat static, whereas in a DC that allows VMs to migrate anywhere, the TS attachment to NVE is much more dynamic.
o VPNでのカスタマーエッジ（CE）からプロバイダーエッジ（PE）へのアタッチはやや静的ですが、VMをどこにでも移行できるDCでは、NVEへのTSアタッチははるかに動的です。
o The number of PEs to which a single VPN customer is attached in an MPLS VPN environment is normally far less than the number of NVEs to which a VN's VMs are attached in a DC.
o MPLS VPN環境で単一のVPNカスタマーが接続されているPEの数は、通常、VNのVMがDCで接続されているNVEの数よりはるかに少ないです。
When a VPN customer has multiple multicast groups, "Multicast VPN" [RFC6513] combines all those multicast groups within each VPN client to one single multicast group in the MPLS (or VPN) core. The result is that messages from any of the multicast groups belonging to one VPN customer will reach all the PE nodes of the client. In other words, any messages belonging to any multicast groups under customer X will reach all PEs of the customer X. When the customer X is attached to only a handful of PEs, the use of this approach does not result in an excessive waste of bandwidth in the provider's network.
VPNカスタマーが複数のマルチキャストグループを持っている場合、「マルチキャストVPN」[RFC6513]は、各VPNクライアント内のそれらすべてのマルチキャストグループをMPLS（またはVPN）コアの単一のマルチキャストグループに結合します。その結果、1人のVPNカスタマーに属する任意のマルチキャストグループからのメッセージは、クライアントのすべてのPEノードに到達します。つまり、顧客Xの下のマルチキャストグループに属するメッセージは、顧客XのすべてのPEに到達します。顧客Xが少数のPEにのみ接続されている場合、このアプローチを使用しても帯域幅が過度に浪費されることはありません。プロバイダーのネットワーク内。
In a DC environment, a typical hypervisor-based virtual switch may only support on the order of 10's of VMs (as of this writing). A subnet with N VMs may be, in the worst case, spread across N virtual switches (vSwitches). Using an "MPLS VPN multicast" approach in such a scenario would require the creation of a multicast group in the core in order for the VN to reach all N NVEs. If only a small percentage of this client's VMs participate in application-specific multicast, a great number of NVEs will receive multicast traffic that is not forwarded to any of their attached VMs, resulting in a considerable waste of bandwidth.
DC環境では、典型的なハイパーバイザーベースの仮想スイッチは、10のオーダーのVMのみをサポートする場合があります（この記事の執筆時点）。 N個のVMを持つサブネットは、最悪の場合、N個の仮想スイッチ（vSwitches）に広がる可能性があります。このようなシナリオで「MPLS VPNマルチキャスト」アプローチを使用するには、VNがすべてのN NVEに到達するために、コアにマルチキャストグループを作成する必要があります。このクライアントのVMのごく一部のみがアプリケーション固有のマルチキャストに参加している場合、多数のNVEが、接続されているどのVMにも転送されないマルチキャストトラフィックを受信するため、帯域幅がかなり浪費されます。
Therefore, the multicast VPN solution may not scale in a DC environment with the dynamic attachment of VNs to NVEs and a greater number of NVEs for each VN.
したがって、マルチキャストVPNソリューションは、VNをNVEに動的にアタッチし、各VNに多数のNVEを使用するDC環境では拡張できない場合があります。
With this method, all multicast packets would be sent using a unicast tunnel encapsulation from the ingress NVE to a Multicast Service Node (MSN). The MSN, in turn, would create multiple copies of the packet and would deliver a copy, using a unicast tunnel encapsulation, to each of the NVEs that are part of the multicast group for which the packet is intended.
この方法では、すべてのマルチキャストパケットは、ユニキャストトンネルカプセル化を使用して、入力NVEからマルチキャストサービスノード（MSN）に送信されます。次に、MSNはパケットの複数のコピーを作成し、ユニキャストトンネルカプセル化を使用して、パケットが対象とするマルチキャストグループの一部である各NVEにコピーを配信します。
This mechanism is similar to that used by the Asynchronous Transfer Mode (ATM) Forum's LAN Emulation (LANE) specification [LANE]. The MSN is similar to the Rendezvous Point (RP) in Protocol Independent Multicast - Sparse Mode (PIM-SM), but different in that the user data traffic is carried by the NVO3 tunnels.
このメカニズムは、非同期転送モード（ATM）フォーラムのLANエミュレーション（LANE）仕様[LANE]で使用されているものと似ています。 MSNは、プロトコル非依存マルチキャスト-スパースモード（PIM-SM）のランデブーポイント（RP）に似ていますが、ユーザーデータトラフィックがNVO3トンネルによって伝送される点が異なります。
The following are possible ways for the MSN to get the membership information for each multicast group:
以下は、MSNが各マルチキャストグループのメンバーシップ情報を取得するための可能な方法です。
o The MSN can obtain this membership information from the IGMP/MLD report messages sent by TSs in response to IGMP/MLD query messages from the MSN. The IGMP/MLD query messages are sent from the MSN to the NVEs, which then forward the query messages to TSs attached to them. An IGMP/MLD query message sent out by the MSN to an NVE is encapsulated with the MSN address in the outer IP source address field and the address of the NVE in the outer IP destination address field. An encapsulated IGMP/MLD query message also has a virtual network (VN) identifier (corresponding to the VN that the TSs belong to) in the outer header and a multicast address in the inner IP destination address field. Upon receiving the encapsulated IGMP/MLD query message, the NVE establishes a mapping for "MSN address" to "multicast address", decapsulates the received encapsulated IGMP/MLD message, and multicasts the decapsulated query message to the TSs that belong to the VN attached to that NVE. An IGMP/MLD report message sent by a TS includes the multicast address and the address of the TS. With the proper "MSN address" to "multicast address" mapping, the NVEs can encapsulate all multicast data frames containing the "multicast address" with the address of the MSN in the outer IP destination address field.
o MSNは、MSNからのIGMP / MLDクエリメッセージに応じてTSから送信されたIGMP / MLDレポートメッセージからこのメンバーシップ情報を取得できます。 IGMP / MLDクエリメッセージはMSNからNVEに送信され、NVEはそれに接続されているTSにクエリメッセージを転送します。 MSNからNVEに送信されたIGMP / MLDクエリメッセージは、外部IP送信元アドレスフィールドにMSNアドレス、外部IP宛先アドレスフィールドにNVEのアドレスでカプセル化されます。カプセル化されたIGMP / MLDクエリメッセージには、外部ヘッダーに仮想ネットワーク（VN）識別子（TSが属するVNに対応）があり、内部IP宛先アドレスフィールドにマルチキャストアドレスがあります。カプセル化されたIGMP / MLDクエリメッセージを受信すると、NVEは「MSNアドレス」から「マルチキャストアドレス」へのマッピングを確立し、受信したカプセル化されたIGMP / MLDメッセージをカプセル化解除し、カプセル化解除されたクエリメッセージを、接続されているVNに属するTSにマルチキャストします。そのNVEに。 TSによって送信されるIGMP / MLDレポートメッセージには、マルチキャストアドレスとTSのアドレスが含まれます。 「MSNアドレス」から「マルチキャストアドレス」への適切なマッピングにより、NVEは「マルチキャストアドレス」を含むすべてのマルチキャストデータフレームを、外部IP宛先アドレスフィールドのMSNのアドレスでカプセル化できます。
o The MSN can obtain the membership information from the NVEs that have the capability to establish multicast groups by snooping native IGMP/MLD messages (note that the communication must be specific to the multicast addresses) or by having the NVA obtain the information from the NVEs and in turn have MSN communicate with the NVA. This approach requires additional protocol between MSN and NVEs.
o MSNは、ネイティブIGMP / MLDメッセージをスヌーピングすることにより（マルチキャストアドレスに固有の通信である必要があることに注意）、またはNVAがNVEから情報を取得することにより、マルチキャストグループを確立する機能を持つNVEからメンバーシップ情報を取得できます。次に、MSNがNVAと通信するようにします。このアプローチでは、MSNとNVEの間に追加のプロトコルが必要です。
Unlike the method described in Section 3.2, there is no performance impact at the ingress NVE, nor are there any issues with multiple copies of the same packet from the source NVE to the MSN. However, there remain issues with multiple copies of the same packet on links that are common to the paths from the MSN to each of the egress NVEs. Additional issues that are introduced with this method include the availability of the MSN, methods to scale the services offered by the MSN, and the suboptimality of the delivery paths.
セクション3.2で説明した方法とは異なり、入力NVEでのパフォーマンスへの影響はありません。また、ソースNVEからMSNへの同じパケットの複数のコピーに問題もありません。ただし、MSNから各出力NVEへのパスに共通するリンク上の同じパケットの複数のコピーに関する問題が残っています。この方法で発生するその他の問題には、MSNの可用性、MSNによって提供されるサービスを拡張する方法、および配信パスの準最適性が含まれます。
Finally, the IP address of the source NVE must be preserved in packet copies created at the multicast service node if data-plane learning is in use. This could create problems if IP source address Reverse Path Forwarding (RPF) checks are in use.
最後に、データプレーン学習が使用されている場合、ソースNVEのIPアドレスは、マルチキャストサービスノードで作成されたパケットコピーに保持される必要があります。これにより、IPソースアドレスのリバースパス転送（RPF）チェックが使用されている場合に問題が発生する可能性があります。
In this method, the underlay supports IP multicast and the ingress NVE encapsulates the packet with the appropriate IP multicast address in the tunnel encapsulation header for delivery to the desired set of NVEs. The protocol in the underlay could be any variant of PIM, or a protocol-dependent multicast, such as [ISIS-Multicast].
この方法では、アンダーレイはIPマルチキャストをサポートし、入力NVEは、適切なIPマルチキャストアドレスを使用してパケットをカプセル化し、目的のNVEのセットに配信するためのトンネルカプセル化ヘッダーを作成します。アンダーレイのプロトコルは、PIMの任意のバリアント、または[ISIS-Multicast]などのプロトコル依存のマルチキャストである可能性があります。
If an NVE connects to its attached TSs via a Layer 2 network, there are multiple ways for NVEs to support the application-specific multicast:
NVEがレイヤー2ネットワークを介して接続されたTSに接続する場合、NVEがアプリケーション固有のマルチキャストをサポートする方法は複数あります。
o The NVE only supports the basic IGMP/MLD snooping function, while the "TS routers" handle the application-specific multicast. This scheme doesn't utilize the underlay IP multicast protocols. Instead routers, which are themselves TSs attached to the NVE, would handle multicast protocols for the application-specific multicast. We refer to such routers as TS routers.
o NVEは基本的なIGMP / MLDスヌーピング機能のみをサポートしますが、「TSルーター」はアプリケーション固有のマルチキャストを処理します。このスキームは、アンダーレイIPマルチキャストプロトコルを利用しません。代わりに、NVEに接続されたTSであるルーターは、アプリケーション固有のマルチキャストのマルチキャストプロトコルを処理します。このようなルーターをTSルーターと呼びます。
o The NVE can act as a pseudo multicast router for the directly attached TSs and support the mapping of IGMP/MLD messages to the messages needed by the underlay IP multicast protocols.
o NVEは、直接接続されたTSの疑似マルチキャストルーターとして機能し、アンダーレイIPマルチキャストプロトコルで必要なメッセージへのIGMP / MLDメッセージのマッピングをサポートできます。
With this method, there are none of the issues with the methods described in Sections 3.2 and 3.3 with respect to scaling and congestion. Instead, there are other issues described below.
この方法を使用すると、スケーリングと輻輳に関してセクション3.2および3.3で説明されている方法の問題はありません。代わりに、以下に説明する他の問題があります。
With PIM-SM, the number of flows required would be (n*g), where n is the number of source NVEs that source packets for the group, and g is the number of groups. Bidirectional PIM (BIDIR-PIM) would offer better scalability with the number of flows required being g. Unfortunately, many vendors still do not fully support BIDIR or have limitations on its implementation. [RFC6831] describes the use of SSM as an alternative to BIDIR, provided that the NVEs have a way to learn of each other's IP addresses so that they can join all of the SSM Shortest Path Trees (SPTs) to create/maintain an underlay SSM IP multicast tunnel solution.
PIM-SMでは、必要なフローの数は（n * g）になります。nはグループのパケットを送信する送信元NVEの数、gはグループの数です。双方向PIM（BIDIR-PIM）は、必要なフローの数をgにすると、より優れたスケーラビリティを提供します。残念ながら、多くのベンダーはまだBIDIRを完全にサポートしていないか、その実装に制限があります。 [RFC6831]では、NDIRがすべてのSSM最短パスツリー（SPT）に参加してアンダーレイSSMを作成/維持できるように互いのIPアドレスを知る方法がある場合、BIDIRの代替としてSSMの使用について説明していますIPマルチキャストトンネルソリューション。
In the absence of any additional mechanism (e.g., using an NVA for address resolution), for optimal delivery, there would have to be a separate group for each VN for infrastructure multicast plus a separate group for each application-specific multicast address within a tenant.
追加のメカニズムがない場合（たとえば、アドレス解決にNVAを使用）、最適な配信のためには、インフラストラクチャマルチキャスト用の各VNに個別のグループと、テナント内の各アプリケーション固有のマルチキャストアドレスに個別のグループが必要です。 。
An additional consideration is that only the lower 23 bits of the IP address (regardless of whether IPv4 or IPv6 is in use) are mapped to the outer MAC address, and if there is equipment that prunes multicasts at Layer 2, there will be some aliasing.
追加の考慮事項は、IPアドレスの下位23ビットのみ（IPv4またはIPv6が使用されているかどうかに関係なく）が外部MACアドレスにマップされ、レイヤー2でマルチキャストをプルーニングする機器がある場合、エイリアスが発生することです。 。
Finally, a mechanism to efficiently provision such addresses for each group would be required.
最後に、各グループにそのようなアドレスを効率的にプロビジョニングするメカニズムが必要になります。
There are additional optimizations that are possible, but they come with their own restrictions. For example, a set of tenants may be restricted to some subset of NVEs, and they could all share the same outer IP multicast group address. This, however, introduces a problem of suboptimal delivery (even if a particular tenant within the group of tenants doesn't have a presence on one of the NVEs that another one does, the multicast packets would still be delivered to that NVE). It also introduces an additional network management burden to optimize which tenants should be part of the same tenant group (based on the NVEs they share), which somewhat dilutes the value proposition of NVO3 (to completely decouple the overlay and physical network design allowing complete freedom of placement of VMs anywhere within the DC).
可能な追加の最適化がありますが、それらには独自の制限があります。たとえば、テナントのセットはNVEの一部のサブセットに制限されている可能性があり、それらはすべて同じ外部IPマルチキャストグループアドレスを共有できます。ただし、これにより次善の配信の問題が生じます（テナントのグループ内の特定のテナントが別のNVEの1つに存在しない場合でも、マルチキャストパケットはそのNVEに配信されます）。また、同じテナントグループに属する必要があるテナントを最適化するために（それらが共有するNVEに基づいて）追加のネットワーク管理負担が導入され、NVO3の価値命題が多少薄められます（完全な自由を可能にするオーバーレイと物理ネットワーク設計を完全に切り離すため） DC内の任意の場所にVMを配置する方法）。
Multicast schemes such as Bit Indexed Explicit Replication (BIER) [RFC8279] may be able to provide optimizations by allowing the underlay network to provide optimum multicast delivery without requiring routers in the core of the network to maintain per-multicast group state.
ビットインデックス付き明示的レプリケーション（BIER）[RFC8279]などのマルチキャストスキームは、ネットワークのコアにあるルーターがマルチキャストグループごとの状態を維持する必要なく、アンダーレイネットワークが最適なマルチキャスト配信を提供できるようにすることで、最適化を提供できる場合があります。
There are still other mechanisms that may be used that attempt to combine some of the advantages of the above methods by offering multiple replication points, each with a limited degree of replication [EDGE-REP]. Such schemes offer a trade-off between the amount of replication at an intermediate node (e.g., router) versus performing all of the replication at the source NVE or all of the replication at a multicast service node.
それぞれに限られた程度の複製[EDGE-REP]を備えた複数の複製ポイントを提供することにより、上記の方法のいくつかの利点を組み合わせようとする、使用可能なメカニズムがさらに他にもあります。このようなスキームは、中間ノード（ルーターなど）での複製の量と、ソースNVEですべての複製を実行するか、マルチキャストサービスノードですべての複製を実行するかとのトレードオフを提供します。
While the mechanisms discussed in the previous section have been discussed individually, it is possible for implementations to rely on more than one of these. For example, the method of Section 3.1 could be used for minimizing ARP/ND, while at the same time, multicast applications may be supported by one, or a combination, of the other methods. For small multicast groups, the methods of source NVE replication or the use of a multicast service node may be attractive, while for larger multicast groups, the use of multicast in the underlay may be preferable.
前のセクションで説明したメカニズムについて個別に説明しましたが、実装がこれらのメカニズムの複数に依存する可能性があります。たとえば、セクション3.1の方法は、ARP / NDを最小化するために使用できますが、同時に、マルチキャストアプリケーションは、他の方法の1つまたは組み合わせでサポートできます。小さなマルチキャストグループの場合は、ソースNVEレプリケーションの方法またはマルチキャストサービスノードの使用が魅力的ですが、大きなマルチキャストグループの場合は、アンダーレイでのマルチキャストの使用が望ましい場合があります。
Some hypervisor-based NVEs do not process or recognize IGMP/MLD frames, i.e., those NVEs simply encapsulate the IGMP/MLD messages in the same way as they do for regular data frames.
一部のハイパーバイザーベースのNVEは、IGMP / MLDフレームを処理または認識しません。つまり、これらのNVEは、通常のデータフレームの場合と同じ方法でIGMP / MLDメッセージを単純にカプセル化します。
By default, a TS router periodically sends IGMP/MLD query messages to all the hosts in the subnet to trigger the hosts that are interested in the multicast stream to send back IGMP/MLD reports. In order for the MSN to get the updated multicast group information, the MSN can also send the IGMP/MLD query message comprising a client-specific multicast address encapsulated in an overlay header to all of the NVEs to which the TSs in the VN are attached.
デフォルトでは、TSルーターは定期的にIGMP / MLDクエリメッセージをサブネット内のすべてのホストに送信して、マルチキャストストリームに関心のあるホストがIGMP / MLDレポートを返信するようトリガーします。 MSNが更新されたマルチキャストグループ情報を取得するために、MSNは、オーバーレイヘッダーにカプセル化されたクライアント固有のマルチキャストアドレスを含むIGMP / MLDクエリメッセージを、VN内のTSが接続されているすべてのNVEに送信することもできます。 。
However, the MSN may not always be aware of the client-specific multicast addresses. In order to perform multicast filtering, the MSN has to snoop the IGMP/MLD messages between TSs and their corresponding routers to maintain the multicast membership. In order for the MSN to snoop the IGMP/MLD messages between TSs and their router, the NVA needs to configure the NVE to send copies of the IGMP/MLD messages to the MSN in addition to the default behavior of sending them to the TSs' routers; e.g., the NVA has to inform the NVEs to encapsulate data frames with the Destination Address (DA) being 224.0.0.2 (DA of IGMP report) to the TSs' router and MSN.
ただし、MSNは常にクライアント固有のマルチキャストアドレスを認識しているとは限りません。マルチキャストフィルタリングを実行するには、MSNがTSと対応するルーター間でIGMP / MLDメッセージをスヌーピングして、マルチキャストメンバーシップを維持する必要があります。 MSNがTSとルーター間でIGMP / MLDメッセージをスヌープするために、NVAは、TSにメッセージを送信するデフォルトの動作に加えて、IGMP / MLDメッセージのコピーをMSNに送信するようにNVEを構成する必要があります。ルーター;たとえば、NVAは、NVEにデータフレームをカプセル化するように通知し、宛先アドレス（DA）を224.0.0.2（DAのIGMPレポート）にして、TSのルーターとMSNに送信する必要があります。
This process is similar to "Source Replication" described in Section 3.2, except the NVEs only replicate the message to the TSs' router and MSN.
このプロセスは、NVEがメッセージをTSのルーターとMSNにのみ複製することを除いて、セクション3.2で説明した「ソースレプリケーション」と同様です。
For DCs with virtualized servers, VMs can be added, deleted, or moved very easily. When VMs are added, deleted, or moved, the NVEs to which the VMs are attached are changed.
仮想化サーバーを備えたDCの場合、VMは非常に簡単に追加、削除、または移動できます。 VMが追加、削除、または移動されると、VMが接続されているNVEが変更されます。
When a VM is deleted from an NVE or a new VM is added to an NVE, the VM management system should notify the MSN to send the IGMP/MLD query messages to the relevant NVEs (as described in Section 3.3) so that the multicast membership can be updated promptly.
VMがNVEから削除された場合、または新しいVMがNVEに追加された場合、VM管理システムはMSNにIGMP / MLDクエリメッセージを関連するNVEに送信するように通知する必要があります（セクション3.3で説明）。迅速に更新することができます。
Otherwise, if there are changes of VMs attachment to NVEs (within the duration of the configured default time interval that the TSs routers use for IGMP/MLD queries), multicast data may not reach the VM(s) that moved.
それ以外の場合、NVEへのVMアタッチメントの変更があると（TSルーターがIGMP / MLDクエリに使用する構成済みのデフォルトの時間間隔内に）、移動したVMにマルチキャストデータが届かない可能性があります。
This document does not introduce any new security considerations beyond what is described in the NVO3 Architecture document [RFC8014].
このドキュメントでは、NVO3アーキテクチャドキュメント[RFC8014]で説明されている以上の新しいセキュリティの考慮事項を紹介していません。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This document has identified various mechanisms for supporting application-specific multicast in networks that use NVO3. It highlights the basics of each mechanism and some of the issues with them. As solutions are developed, the protocols would need to consider the use of these mechanisms, and coexistence may be a consideration. It also highlights some of the requirements for supporting multicast applications in an NVO3 network.
このドキュメントでは、NVO3を使用するネットワークでアプリケーション固有のマルチキャストをサポートするためのさまざまなメカニズムを特定しました。各メカニズムの基本とそれらの問題のいくつかを強調しています。ソリューションが開発されると、プロトコルはこれらのメカニズムの使用を考慮する必要があり、共存が考慮事項になる場合があります。また、NVO3ネットワークでマルチキャストアプリケーションをサポートするための要件のいくつかも取り上げています。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< https://www.rfc-editor.org/info/rfc3376>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNにおけるマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、2012年2月、<https://www.rfc-editor.org/info/rfc6513>。
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, <https://www.rfc-editor.org/info/rfc7364>.
[RFC7364] Narten、T.、Ed。、Gray、E.、Ed。、Black、D.、Fang、L.、Kreeger、L。、およびM. Napierala、「Problem Statement：Overlays for Network Virtualization」、RFC 7364、DOI 10.17487 / RFC7364、2014年10月、<https://www.rfc-editor.org/info/rfc7364>。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N。、およびY. Rekhter、「Framework for Data Center（DC）Network Virtualization」、RFC 7365、DOI 10.17487 / RFC7365、2014年10月、<https://www.rfc-editor.org/info/rfc7365>。
[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 2016, <https://www.rfc-editor.org/info/rfc8014>.
[RFC8014] Black、D.、Hudson、J.、Kreeger、L.、Lasserre、M。、およびT. Narten、「An Layer for Data-Center Network Virtualization over Layer 3（NVO3）」、RFC 8014、DOI 10.17487 / RFC8014、2016年12月、<https://www.rfc-editor.org/info/rfc8014>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、DOI 10.17487 / RFC2710、1999年10月、<https：//www.rfc-editor .org / info / rfc2710>。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <https://www.rfc-editor.org/info/rfc3569>.
[RFC3569] Bhattacharyya、S。、編、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、DOI 10.17487 / RFC3569、2003年7月、<https://www.rfc-editor.org/info/ rfc3569>。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <https://www.rfc-editor.org/info/rfc3819>.
[RFC3819]カーン、P。、編、ボーマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、DOI 10.17487 / RFC3819、2004年7月、<https://www.rfc-editor.org/info/rfc3819>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762]ラッセール、M。、エド。およびV. Kompella編、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https://www.rfc-editor.org/ info / rfc4762>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<https://www.rfc-editor.org/info/rfc6040>。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「マルチキャスト環境用のロケータ/ ID分離プロトコル（LISP）」、RFC 6831、DOI 10.17487 / RFC6831、2013年1月、< https://www.rfc-editor.org/info/rfc6831>。
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <https://www.rfc-editor.org/info/rfc7117>.
[RFC7117] Aggarwal、R.、Ed。、Kamite、Y.、Fang、L.、Rekhter、Y。、およびC. Kodeboniya、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、DOI 10.17487 / RFC7117 、2014年2月、<https://www.rfc-editor.org/info/rfc7117>。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlayed Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>。
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P.、Ed。およびY. Wang編、「NVGRE：Network Virtualization Using Generic Routing Encapsulation」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<https://www.rfc-editor.org/info/rfc7637>。
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279] Wijnands、IJ。、Ed。、Rosen、E.、Ed。、Dolganow、A.、Przygienda、T.、and S. Aldrin、 "Multicast Using Bit Index Explicit Replication（BIER）"、RFC 8279、DOI 10.17487 / RFC8279、2017年11月、<https://www.rfc-editor.org/info/rfc8279>。
[DC-MC] McBride, M. and H. Liu, "Multicast in the Data Center Overview", Work in Progress, draft-mcbride-armd-mcast-overview-02, July 2012.
[DC-MC]マクブライド、M.、H。リュー、「データセンターのマルチキャストの概要」、作業中、draft-mcbride-armd-mcast-overview-02、2012年7月。
[EDGE-REP] Marques, P., Fang, L., Winkworth, D., Cai, Y., and P. Lapukhov, "Edge multicast replication for BGP IP VPNs.", Work in Progress, draft-marques-l3vpn-mcast-edge-01, June 2012.
[EDGE-REP] Marques、P.、Fang、L.、Winkworth、D.、Cai、Y。、およびP. Lapukhov、「BGP IP VPNのエッジマルチキャストレプリケーション」、Work in Progress、draft-marques-l3vpn -mcast-edge-01、2012年6月。
[Geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-05, September 2017.
[Geneve] Gross、J.、Ganga、I。、およびT. Sridhar、「Geneve：Generic Network Virtualization Encapsulation」、Work in Progress、draft-ietf-nvo3-geneve-05、2017年9月。
[GUE] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", Work in Progress, draft-ietf-intarea-gue-05, December 2017.
[GUE] Herbert、T.、Yong、L.、O。Zia、「Generic UDP Encapsulation」、Work in Progress、draft-ietf-intarea-gue-05、2017年12月。
[ISIS-Multicast] Yong, L., Weiguo, H., Eastlake, D., Qu, A., Hudson, J., and U. Chunduri, "IS-IS Protocol Extension For Building Distribution Trees", Work in Progress, draft-yong-isis-ext-4-distribution-tree-03, October 2014.
[ISIS-Multicast] Yong、L.、Weiguo、H.、Eastlake、D.、Qu、A.、Hudson、J。、およびU. Chunduri、「IS-IS Protocol Extension for Building Distribution Trees」、作業中、draft-yong-isis-ext-4-distribution-tree-03、2014年10月。
[LANE] ATM Forum, "LAN Emulation Over ATM: Version 1.0", ATM Forum Technical Committee, af-lane-0021.000, January 1995.
[LAN] ATMフォーラム、「ATM上のLANエミュレーション：バージョン1.0」、ATMフォーラム技術委員会、af-lane-0021.000、1995年1月。
[LISP-Signal-Free] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Work in Progress, draft-ietf-lisp-signal-free-multicast-07, November 2017.
[LISP-Signal-Free] Moreno、V。およびD. Farinacci、「Signal-Free LISP Multicast」、Work in Progress、draft-ietf-lisp-signal-free-multicast-07、2017年11月。
[VXLAN-GPE] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017.
[VXLAN-GPE] Maino、F.、Kreeger、L。、およびU. Elzur、「Generic Protocol Extension for VXLAN」、Work in Progress、draft-ietf-nvo3-vxlan-gpe-05、2017年10月。
Acknowledgments
謝辞
Many thanks are due to Dino Farinacci, Erik Nordmark, Lucy Yong, Nicolas Bouliane, Saumya Dikshit, Joe Touch, Olufemi Komolafe, and Matthew Bocci for their valuable comments and suggestions.
Dino Farinacci、Erik Nordmark、Lucy Yong、Nicolas Bouliane、Saumya Dikshit、Joe Touch、Olufemi Komolafe、Matthew Bocciの貴重なコメントと提案に感謝します。
Authors' Addresses
著者のアドレス
Anoop Ghanwani Dell
Anoop Ghanwani Dell
Email: anoop@alumni.duke.edu
Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 1750 Plano, TX 75024 United States of America
Linda Dunbar Huawei Technologies 5340 Legacy Drive、Suite 1750 Plano、TX 75024アメリカ合衆国
Phone: (469) 277 5840 Email: ldunbar@huawei.com
電話：（469）277 5840メール：ldunbar@huawei.com
Mike McBride Huawei Technologies
Mike McBride Huawei Technologies
Email: mmcbride7@gmail.com
Vinay Bannai Google
ゔぃなｙ ばんあい ごおｇぇ
Email: vbannai@gmail.com
Ram Krishnan Dell
ラムクリシュナンデル
Email: ramkri123@gmail.com