[要約] RFC 6831は、マルチキャスト環境でのLocator/ID Separation Protocol（LISP）についての要約です。このRFCの目的は、LISPを使用してマルチキャストトラフィックの効率とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6831 D. Meyer
Category: Experimental J. Zwiebel
ISSN: 2070-1721 S. Venaas
Cisco Systems
January 2013
The Locator/ID Separation Protocol (LISP) for Multicast Environments
マルチキャスト環境用のロケーター/ ID分離プロトコル（LISP）
Abstract
概要
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.
このドキュメントでは、Locator / ID Separation Protocol（LISP）アーキテクチャを使用してLocator / ID Separationが展開されている環境でドメイン間マルチキャストルーティングがどのように機能するかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6831.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6831で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Source Addresses versus Group Addresses . . . . . . . . . . . 10
6. Locator Reachability Implications on LISP-Multicast . . . . . 11
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 12
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 14
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 15
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 15
8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 15
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 16
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 17
9.1. LISP and Non-LISP Mixed Sites . . . . . . . . . . . . . . 17
9.1.1. LISP Source Site to Non-LISP Receiver Sites . . . . . 18
9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites . . . 20
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 20
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 21
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 21
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22
9.3. Making a Multicast Interworking Decision . . . . . . . . . 24
10. Considerations When RP Addresses Are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 25
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 27
The Locator/ID Separation Protocol [RFC6830] architecture provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an Endpoint ID (EID) namespace used by sites and a Routing Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information.
Locator / ID Separation Protocol [RFC6830]アーキテクチャは、IPアドレスの現在の定義から識別と場所のセマンティクスを分離するメカニズムを提供します。サイトが使用するエンドポイントID（EID）名前空間とコアルーティングが使用するルーティングロケーター（RLOC）名前空間の2つの名前空間を作成することにより、コアルーティングインフラストラクチャは、ルーティング情報のトポロジー集約を行うことで拡張できます。
Since LISP creates a new namespace, a mapping function must exist to map a site's EID-Prefixes to its associated Locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology dependent. Therefore, this specification focuses on mapping a source EID address of a multicast flow during distribution tree setup and packet delivery.
LISPは新しい名前空間を作成するため、サイトのEIDプレフィックスを関連するロケーターにマップするためのマッピング関数が存在する必要があります。ユニキャストパケットの場合、送信元アドレスと宛先アドレスの両方をマップする必要があります。マルチキャストパケットの場合、マッピングする必要があるのは送信元アドレスだけです。 IPv4またはIPv6グループアドレスのセマンティクスは本来論理的であり、トポロジーに依存しないため、宛先グループアドレスをマップする必要はありません。したがって、この仕様は、配信ツリーのセットアップとパケット配信中のマルチキャストフローの送信元EIDアドレスのマッピングに重点を置いています。
This specification will address the following scenarios:
この仕様は、次のシナリオに対応します。
1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled.
1. LISPサイトのマルチキャスト送信元ホストがマルチキャストパケットをサイト内の受信者だけでなく、LISPが有効になっている他のサイトの受信者に送信する方法。
2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed.
2. ドメイン間（またはLISPサイト間）のマルチキャスト配信ツリーの構築方法、およびソースサイトから送信されるマルチキャストパケットのレシーバーサイトへの転送方法。
3. What protocols are affected and what changes are required to such multicast protocols.
3. 影響を受けるプロトコルと、そのようなマルチキャストプロトコルに必要な変更点。
4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source Multicast), and Bidir-mode (Bidirectional Shared Trees) service models will operate.
4. ASMモード（Any Source Multicast）、SSMモード（Single Source Multicast）、およびBidirモード（Bidirectional Shared Trees）サービスモデルの動作方法。
5. How multicast packet flow will occur for multiple combinations of LISP-enabled and non-LISP-enabled source and receiver sites. For example:
5. LISP対応と非LISP対応の送信元サイトと受信サイトの複数の組み合わせでマルチキャストパケットフローがどのように発生するか。例えば：
A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites.
A. LISPサイトの送信元ホストからのマルチキャストパケットが、すべて非LISPサイトである場合に、他のサイトの受信者に送信される方法。
B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites.
B. LISPサイトの送信元ホストからのマルチキャストパケットがLISP対応サイトと非LISPサイトの両方の受信者に送信される方法。
C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP-enabled sites.
C.非LISPサイトの送信元ホストからのマルチキャストパケットが、すべてLISP対応サイトである場合に、他のサイトの受信者に送信される方法。
D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites.
D.非LISPサイトの送信元ホストからのマルチキャストパケットが、LISP対応サイトと非LISPサイトの両方の受信者に送信される方法。
This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multiprotocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no packet format changes to the protocols and no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged, regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites that are LISP enabled.
この仕様は、LISPマルチキャストをサポートするためにマルチキャストルーティングプロトコルに必要な変更、およびマルチプロトコルBGP（MBGP）[RFC4760]などのドメイン間マルチキャストに使用される他のプロトコルに焦点を当てています。この仕様で提案されているアプローチでは、サイトでLISPが有効になっている場合でも、すべてのソースとレシーバーがそのサイトにある場合、プロトコルのパケット形式の変更やサイト内のマルチキャストインフラストラクチャの運用手順の変更は必要ありません。つまり、サイトでLISPが有効になっているかどうか、またはLISPが有効になっている他のサイトにレシーバーが存在しているかどうかに関係なく、マルチキャストの内部動作は変わりません。
Therefore, we see only operational (and not protocol) changes for PIM-ASM [RFC4601], Multicast Source Discovery Protocol (MSDP) [RFC3618], and PIM-SSM [RFC4607]. BIDIR-PIM [RFC5015], which typically does not run in an inter-domain environment, is not addressed in depth in this RFC.
したがって、PIM-ASM [RFC4601]、Multicast Source Discovery Protocol（MSDP）[RFC3618]、およびPIM-SSM [RFC4607]の運用上の（プロトコルではない）変更のみが表示されます。 BIDIR-PIM [RFC5015]は、通常、ドメイン間環境では実行されませんが、このRFCでは詳細に説明されていません。
Also, the current version of this specification does not describe multicast-based Traffic Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in [RFC6830]. Further work is also needed to determine the detailed behavior for multicast Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6). Finally, further deployment and experimentation would be useful to understand the real-life performance of the LISP-Multicast solution. For instance, the design optimizes for minimal state and control traffic in the core, but can in some cases cause extra multicast traffic to be sent Section 8.1.2.
また、この仕様の現在のバージョンでは、[RFC6830]のTE-ITR（TEベースの入力トンネルルーター）およびTE-ETR（TEベースの出力トンネルルーター）の説明に関連するマルチキャストベースのトラフィックエンジニアリング（TE）については説明していません。 。マルチキャストプロキシITR（mPITR）（セクション9.1.3）、mtrace（セクション12）、およびロケーター到達可能性（セクション6）の詳細な動作を決定するには、さらに作業が必要です。最後に、LISPマルチキャストソリューションの実際のパフォーマンスを理解するには、さらに展開して実験することが役立ちます。たとえば、コアの状態と制御トラフィックが最小限になるように設計が最適化されますが、場合によっては、追加のマルチキャストトラフィックがセクション8.1.2に送信される可能性があります。
Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830]. Section 12 of that document provides additional issues and concerns raised by this document.
インターネットトラフィック用のLISPの展開に関する問題と懸念事項は、[RFC6830]で説明されています。そのドキュメントのセクション12は、このドキュメントによって提起された追加の問題と懸念を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terminology in this section is consistent with the definitions in [RFC6830] but is extended specifically to deal with the application of the terminology to multicast routing.
このセクションの用語は、[RFC6830]の定義と一致していますが、特に、マルチキャストルーティングへの用語の適用を扱うために拡張されています。
LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture.
LISP-Multicast：この仕様の設計への参照。つまり、マルチキャスト通信に参加しているサイトがLISPサイトにアップグレードされている場合、コントロールプレーンおよびデータプレーンプロトコルの動作は、LISPマルチキャストアーキテクチャの一部と見なされます。
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-Prefix block associated with the site in which the host is located. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider-Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system.
エンドポイントID（EID）：マルチキャストパケットの最初（最も内側）のLISPヘッダーの送信元アドレスフィールドで使用される32ビット（IPv4の場合）または128ビット（IPv6の場合）の値。ホストは、LISP以外のサイトの場合と同様に、今日取得するのと同じ方法で宛先グループアドレスを取得します。ソースEIDは、ホストの「ローカル」IPアドレスを設定するために使用される既存のメカニズムを介して取得されます。 EIDは、ホストが配置されているサイトに関連付けられているEID-Prefixブロックからホストに割り当てられます。 EIDは、IGMPバージョン3 [RFC4604]を使用してSSM（S-EID、G）ルートに参加する場合と同様に、ホストが別のホストを参照するために使用できます。 LISPは、プロバイダーに依存しない（PI）ブロックをEIDに使用します。このようなEIDは、LISP RLOCとして使用してはなりません（MUST NOT）。 EIDブロックは、マッピングデータベースのスケーリングを容易にするために、ネットワークトポロジーとは無関係に階層的に割り当てることができます。さらに、サイトに割り当てられたEIDブロックには、サイト内でルーティングするためのサイトローカル構造（サブネット化）がある場合があります。この構造は、グローバルルーティングシステムからは見えません。
Routing Locator (RLOC): the IPv4 or IPv6 address of an Ingress Tunnel Router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site.
ルーティングロケーター（RLOC）：マルチキャストパケットをカプセル化するマルチキャストソースホストのサイト内のルーターである、入力トンネルルーター（ITR）のIPv4またはIPv6アドレス。これは、EIDからRLOCへのマッピングルックアップの出力です。 EIDは1つ以上のRLOCにマップします。通常、RLOCは、グローバルインターネットに接続する各ポイントでサイトに割り当てられるトポロジ的に集約可能なブロックから番号が付けられます。トポロジがプロバイダーネットワークの接続によって定義される場合、RLOCはプロバイダー割り当て（PA）アドレスと考えることができます。複数のRLOCを同じITRデバイスまたはサイトの複数のITRデバイスに割り当てることができます。
Ingress Tunnel Router (ITR): a router that accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally routable RLOCs as the source address field. This RLOC is known to other multicast receiver sites that have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated multicast IP packets out all external interfaces that have been joined.
Ingress Tunnel Router（ITR）：単一のIPヘッダーを持つIPマルチキャストパケット（より正確には、LISPヘッダーを含まないIPパケット）を受け入れるルーター。ルータはこの「内部」IP宛先マルチキャストアドレスを不透明に処理するため、トポロジ的に重要ではないため、グループアドレスに対してマップルックアップを実行する必要はありません。次にルーターは、「外部」IPヘッダーの先頭に、グローバルにルーティング可能なRLOCの1つを送信元アドレスフィールドとして付加します。このRLOCは、マッピングデータベースを使用して、ITRがルートであるマルチキャストツリーに参加した他のマルチキャストレシーバーサイトに知られています。一般に、ITRは片側のサイトエンドシステムからIPパケットを受信し、参加しているすべての外部インターフェイスからLISPカプセル化マルチキャストIPパケットを送信します。
An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers.
ITRがサイト内のソースからマルチキャストパケットを受信するのは、1）マルチキャストソースから内部で結合されたレシーバーへのパス上にある場合、または2）マルチキャストソースから外部で結合されたレシーバーへのパス上にある場合です。
Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site-internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/ Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers.
Egress Tunnel Router（ETR）：別のサイトのマルチキャストソースホストから自身のサイトのマルチキャストレシーバーへのパス上にあるルーター。 ETRは、マルチキャストソースサイト内のソースのEIDを宛先とするサイト内部のPIMルーターからのPIM Join / Pruneメッセージを受け入れます。 ETRは、EIDからRLOCへのマッピングに基づいて、Join / Pruneメッセージ内のソースEIDをRLOCアドレスにマッピングします。これにより、ソースマルチキャストサイトのITRからのマルチキャストカプセル化パケットを受け入れるようにETRが設定されます。マルチキャストETRは、マルチキャストカプセル化されたパケットをカプセル化解除し、内部レシーバーにつながるインターフェイスで複製します。
xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint; it is used synonymously with the term "tunnel router". For example, "an xTR can be located at the Customer Edge (CE) router" means that both ITR and ETR functionality can be at the CE router.
xTR：データフローの方向がコンテキストの説明に含まれていない場合のITRまたはETRへの参照です。 xTRは、トンネルエンドポイントであるルーターを指します。 「トンネルルーター」という用語の同義語として使用されます。たとえば、「xTRはカスタマーエッジ（CE）ルーターに配置できる」とは、ITR機能とETR機能の両方をCEルーターに配置できることを意味します。
LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers, and an ETR strips headers. A LISP-encapsulated multicast packet will have an "inner" header with the source EID in the source field, an "outer" header with the source RLOC in the source field, and the same globally unique group address in the destination field of both the inner and outer header.
LISPヘッダー：このドキュメントで使用されている用語で、外側のIPv4またはIPv6ヘッダー、UDPヘッダー、およびLISPヘッダーを指します。 ITRはヘッダーを付加し、ETRはヘッダーを削除します。 LISPカプセル化マルチキャストパケットには、ソースフィールドにソースEIDを持つ「内部」ヘッダー、ソースフィールドにソースRLOCを持つ「外部」ヘッダー、および両方の宛先フィールドに同じグローバルに一意のグループアドレスがあります。内部および外部ヘッダー。
(S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state that resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core).
（S、G）状態：正式な定義はPIMスパースモード[RFC4601]仕様にあります。この仕様では、用語は一般的にマルチキャスト状態を指すために使用されます。トポロジー上の場所に基づいて、ルーターに存在する（S、G）状態は、（S-EID、G）状態（（S、G）状態が存在する場所）または（S-RLOC、G）のいずれかになります。状態（インターネットコア内）。
(S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside of a site.
（S-EID、G）状態：S-EIDがマルチキャスト送信元ホスト（そのEID）のIPアドレスである、マルチキャスト送信元サイトと受信側サイトのマルチキャスト状態を指します。 S-EIDは、IGMPv3レポート、MSDP SAメッセージ、またはサイト内を移動するPIM Join / Pruneメッセージに表示されます。
(S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from the (S-EID,G) entry by doing a mapping database lookup for the EID-Prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/ Prune message when it travels from an ETR to an ITR over the Internet core.
（S-RLOC、G）状態：Sがマルチキャストソースを持つサイトのソースロケーター（マルチキャストITRのIPアドレス）であるコアのマルチキャスト状態を指します。 （S-RLOC、G）は、S-EIDがマップするEIDプレフィックスのマッピングデータベースルックアップを実行することにより、（S-EID、G）エントリからマップされます。 S-RLOCは、インターネットコアを介してETRからITRに移動するときに、PIM Join / Pruneメッセージに表示されることがあります。
uLISP Site: a unicast-only LISP site according to [RFC6830] that has not deployed the procedures of this specification and, therefore, for multicast purposes, follows the procedures from Section 9. A uLISP site can be a traditional multicast site.
uLISPサイト：この仕様の手順を展開していない[RFC6830]によるユニキャスト専用LISPサイト。したがって、マルチキャストの目的で、セクション9の手順に従います。uLISPサイトは、従来のマルチキャストサイトにすることができます。
LISP Site: a unicast LISP site (uLISP Site) that is also multicast capable according to the procedures in this specification.
LISPサイト：ユニキャストLISPサイト（uLISPサイト）。この仕様の手順に従ってマルチキャストも可能です。
mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID-Prefix to which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune messages. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy-ETRs for supporting multicast routing in a LISP infrastructure. It is likely a uPITR [RFC6832] and an mPETR will be co-located since the single device advertises a coarse EID-Prefix in the underlying unicast routing system.
mPETR：これは、非LISPおよびuLISPサイトが（S-EID、G）PIM Join / Pruneメッセージをターゲットにできる非常に大まかなEIDプレフィックスのアドバタイズを担当するマルチキャストプロキシETRです。 mPETRが使用されるため、LISP送信元マルチキャストサイトは、EID名前空間の送信元アドレスを使用してマルチキャストパケットを送信できます。 mPETRは、LISPインフラストラクチャでマルチキャストルーティングをサポートするためのProxy-ETRとして機能します。単一のデバイスが基礎となるユニキャストルーティングシステムで粗いEIDプレフィックスをアドバタイズするため、uPITR [RFC6832]とmPETRが同じ場所に配置される可能性があります。
Mixed Locator-Sets: this is a Locator-Set for a LISP database mapping entry where the RLOC addresses in the Locator-Set are in both IPv4 and IPv6 format.
混合ロケータセット：これは、ロケータセットのRLOCアドレスがIPv4とIPv6の両方の形式であるLISPデータベースマッピングエントリのロケータセットです。
Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (LISP-encapsulated with destination UDP port 4341) that is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the OIF-list for the (S-EID,G) entry for which the ETR is joining.
ユニキャストカプセル化PIM加入/プルーンメッセージ：これは、マルチキャストレシーバーサイトのETRからマルチキャストソースサイトのITRに送信される標準のPIM加入/プルーンメッセージ（宛先UDPポート4341でLISPカプセル化）です。このメッセージは、ETRが参加している（S-EID、G）エントリのインターフェイスがOIFリストにある限り、定期的に送信されます。
OIF-list: this is notation to describe the outgoing interface list a multicast router stores per multicast routing table entry so it knows on which interfaces to replicate multicast packets.
OIFリスト：これは、マルチキャストルーターがマルチキャストルーティングテーブルエントリごとに格納する発信インターフェイスリストを表す表記であり、マルチキャストパケットを複製するインターフェイスを認識します。
RPF: Reverse Path Forwarding is a procedure used by multicast routers. A router will accept a multicast packet for forwarding if the packet was received on the path that the router would use to forward unicast packets to the multicast packet's source.
RPF：リバースパス転送は、マルチキャストルーターで使用される手順です。ルーターがマルチキャストパケットのソースにユニキャストパケットを転送するために使用するパスでパケットが受信された場合、ルーターはマルチキャストパケットを転送用に受け入れます。
LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the Traffic Engineering features of LISP [RFC6830], a multicast source site can control the egress of its multicast traffic. By controlling the priorities of Locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site.
LISPをユニキャストルーティングに使用すると、入力トラフィックフローを制御するサイトの機能が向上します。出力トラフィックフローは、ソースサイトのIGPによって制御されます。マルチキャストの場合、IGPとPIMを組み合わせて、マルチキャストパケットが進入するパスを決定できます。 LISP [RFC6830]のトラフィックエンジニアリング機能を使用することにより、マルチキャストソースサイトはマルチキャストトラフィックの出力を制御できます。マッピングデータベースエントリからロケーターの優先度を制御することにより、ソースマルチキャストサイトは、マルチキャストレシーバーサイトがソースサイトに参加する方法を制御できます。
At this point in time, there is no requirement for different Locator-Sets, priority, and weight policies for multicast than there is for unicast. However, when Traffic Engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages.
この時点で、マルチキャストには、ユニキャストの場合とは異なるロケータセット、優先度、および重みポリシーの要件はありません。ただし、トラフィックエンジニアリングポリシーがユニキャストフローとマルチキャストフローで異なる場合は、Map-Replyメッセージでマルチキャストベースの優先順位と重みの値を使用することが望ましいでしょう。
The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in a LISP-Multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR.
基本的なマルチキャスト転送モデルは、マルチキャストパケットを別のマルチキャストパケットにカプセル化することです。 ITRは、LISP-Multicastヘッダーで機能するソースから受信したマルチキャストパケットをカプセル化します。内部ヘッダーの宛先グループアドレスは、外部ヘッダーの宛先アドレスにコピーされます。内部ソースアドレスはマルチキャストソースホストのEIDであり、外部ソースアドレスはカプセル化ITRのRLOCです。
The LISP-Multicast architecture will follow this high-level protocol and operational sequence:
LISPマルチキャストアーキテクチャは、次の高レベルのプロトコルと操作シーケンスに従います。
1. Receiver hosts in multicast sites will join multicast content the way they do today -- they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs; that is, they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is, the closest exit for the Join/Prune message and the closest entrance for the multicast packet to the receiver).
1. マルチキャストサイトのレシーバーホストは、現在と同じ方法でマルチキャストコンテンツに参加します。IGMPを使用します。送信元アドレスを指定するIGMPv3を使用する場合、送信元EIDを使用します。つまり、（S-EID、G）に参加します。マルチキャストソースがこのレシーバーサイトの外部にある場合、PIM Join / PruneメッセージはETRに向かって流れ、最短の出口（つまり、Join / Pruneメッセージの最も近い出口とマルチキャストパケットのレシーバーに最も近い入口）を見つけます。 ）。
2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping.
2. ETRはS-EIDのマッピングデータベースルックアップを行います。マッピングが以前のルックアップ（ソースマルチキャストサイトの以前のJoin / Pruneまたはサイトに送信されたユニキャストパケット）からキャッシュされている場合、マッピングからのRLOC情報を使用します。
The ETR will use the same priority and weighting mechanism as for unicast. So, the source site can decide which way multicast packets egress.
ETRは、ユニキャストと同じ優先度と重み付けメカニズムを使用します。そのため、送信元サイトは、マルチキャストパケットの出力方法を決定できます。
3. The ETR will build two PIM Join/Prune messages, one that contains an (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other that contains an (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR.
3. ETRは2つのPIM Join / Pruneメッセージを作成します。1つは、ETRが選択するRLOCと一致するITRにユニキャストされる（S-EID、G）エントリを含み、もう1つは（S-RLOC、G）を含みます。コアネットワークがこのETRからITRへのマルチキャスト状態を作成できるように、エントリ。
4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message, it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR.
4. ITRがユニキャストのJoin / Pruneメッセージ（正式な定義についてはセクション3を参照）を取得すると、メッセージの（S-EID、G）エントリを処理し、サイト経由でEIDの明示的なルーティング情報があるサイト内に伝達します。 IGP。 ITRが（S-RLOC、G）PIM Join / Pruneメッセージを受信すると、ITRは、今日のインターネットで取得する他の参加と同様に処理します。 S-RLOCアドレスは、このITRのIPアドレスです。
5. At this point, there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site).
5. この時点で、受信側マルチキャストサイトの参加ホストから受信側マルチキャストサイトのETRへの（S-EID、G）状態があります。マルチキャストレシーバーサイトのETRからマルチキャストソースサイトのITRまでのコアネットワーク全体に（S-RLOC、G）状態があり、ソースマルチキャストサイトには（S-EID、G）状態があります。 （S-EID、G）状態は、各マルチキャストサイトで同じS-EIDであることに注意してください。他のETRは同じマルチキャストツリーに参加するため、同じITR（この場合、パケットレプリケーションはコアで実行されます）または別のITR（この場合、パケットレプリケーションはソースサイトで実行されます）を介して参加できます。
6. When a packet is originated by the multicast host in the source site, the packet will flow to one or more ITRs that will prepend a LISP header. By copying the group address to the outer destination address field, the ITR inserts its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface on which an (S-RLOC,G) join was received. The core has (S-RLOC,G) so where fan-out occurs to multiple sites, a core router will do packet replication.
6. パケットがソースサイトのマルチキャストホストによって発信された場合、パケットは、LISPヘッダーを付加する1つ以上のITRに流れます。グループアドレスを外部宛先アドレスフィールドにコピーすることにより、ITRは独自のロケーターアドレスを外部ソースアドレスフィールドに挿入します。 ITRは、（S-RLOC、G）状態を確認します。S-RLOCは独自のロケーターアドレスであり、（S-RLOC、G）結合が受信された各インターフェイスでパケットを複製します。コアには（S-RLOC、G）があるため、複数のサイトにファンアウトが発生すると、コアルーターがパケットの複製を行います。
7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would not have received the packets because it would not have joined. The ETR decapsulates and does an (S-EID,G) lookup in its multicast Forwarding Information Base (FIB) to forward packets out one or more interfaces to forward the packet to internal receivers.
7. ソースサイトまたはコアのいずれかがパケットを複製すると、ETRは宛先グループアドレスを持つLISPパケットを受信します。グループのレシーバーがあるため、パケットのカプセル化を解除します。それ以外の場合は、参加していないため、パケットを受信していません。 ETRはカプセル化を解除し、マルチキャスト転送情報ベース（FIB）で（S-EID、G）ルックアップを実行して、パケットを1つ以上のインターフェースから転送し、パケットを内部レシーバーに転送します。
This architecture is consistent and scalable with the architecture presented in [RFC6830] where multicast state in the core operates on Locators, and multicast state at the sites operates on EIDs.
このアーキテクチャは、コアのマルチキャストステートがロケーターで動作し、サイトのマルチキャストステートがEIDで動作する[RFC6830]で提示されたアーキテクチャと整合性があり、スケーラブルです。
Alternatively, [RFC6830] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF Vectors [RFC5496] in PIM Join/Prune messages. However, few PIM implementations support RPF Vectors, and LISP should avoid S-EID state in the core. See Section 5 for details.
あるいは、[RFC6830]には、PIM Join / PruneメッセージでRPFベクトル[RFC5496]を使用して、（S-EID、G）状態がコアに常駐できるメカニズムもあります。ただし、RPFベクトルをサポートするPIM実装はほとんどなく、LISPはコアのS-EID状態を回避する必要があります。詳細については、セクション5を参照してください。
However, some observations can be made on the algorithm above. The control plane can scale but at the expense of sending data to sites that may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G), and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the OIF-list state for the (S-RLOC,G) entry. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G), packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC.
ただし、上記のアルゴリズムでいくつかの観察を行うことができます。コントロールプレーンは拡張できますが、カプセル化されたデータが配信されている配布ツリーに参加していない可能性があるサイトにデータを送信することを犠牲にしています。たとえば、あるサイトが参加（S-EID1、G）し、別のサイトが参加（S-EID2、G）します。両方のEIDが同じマルチキャストソースサイトにあります。両方のマルチキャストレシーバーサイトは、状態（S-RLOC、G）で同じITRに参加します。S-RLOCはITRのRLOCです。 ITRは、サイト内の（S-EID1、G）と（S-EID2、G）の両方に参加します。 ITRは（S-RLOC、G）結合を受信し、（S-RLOC、G）エントリのOIFリスト状態を入力します。 （S-EID1、G）と（S-EID2、G）の両方が1つの（S-RLOC、G）にマップされるため、それぞれが単一のソースに参加している場合でも、パケットはコアによって両方のマルチキャストレシーバーサイトに配信されます。ベースの配布ツリー。この動作は、S-EIDとS-RLOC間の多対1マッピングの結果です。
There is a possible solution to this problem that reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one-to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but "n" can reduce to a smaller number in the "n-to-1" relationship. And in turn, this reduces the opportunity for data packets to be delivered to sites for groups not joined.
（S-EID、G）エントリが1つの（S-RLOC、G）エントリに集約される多対1のオカレンスの数を減らす、この問題に対する可能な解決策があります。物理ITRに複数のRLOCアドレスを割り当てることができ、これらのアドレスがマッピングデータベースエントリでアドバタイズされる場合、レシーバーサイトのETRにはより多くのRLOCアドレスオプションがあり、それぞれの（S-EID、G）の異なる（RLOC、G）エントリに参加できます。エントリは受信側サイトで結合されました。ソースサイトのS-EIDソースの数とサイトのすべてのITRに割り当てられたRLOCの数の間に1対1の関係を持つようにスケールすることはできませんが、「n」は、 「n対1」の関係。これにより、参加していないグループのサイトにデータパケットが配信される機会が減ります。
Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast.
マルチキャストグループアドレスは、EIDまたはRLOC名前空間に関連付ける必要はありません。それらは実際には独自の名前空間であり、比較的不透明な割り当てで論理的に扱うことができます。したがって、その性質上、LISP-Multicastの段階的な展開を損なうことはありません。
As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs. EID addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet.
送信元アドレスに関しては、ユニキャストLISPシナリオの場合と同様に、場所からの識別の分離があります。 LISPサイトでは、パケットは割り当てられたEIDを使用してホストから発信されます。 EIDアドレスは、ホストのほか、サイトのトポロジのどこにホストが存在するかを識別するために使用されますが、インターネットに接続する方法と場所は識別しません。
Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)}, where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site; the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites; and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites.
したがって、マルチキャスト配信ツリー状態が、マルチキャストレシーバーからマルチキャストソースへのパス上のネットワーク内のどこかに作成されると、EID状態はソースおよびレシーバーマルチキャストサイトで維持され、RLOC状態はコアで維持されます。つまり、マルチキャスト配信ツリーは{（S-EID、G）（S-RLOC、G）（S-EID、G）}の3タプルとして表され、3タプルの最初の要素は送信元から送信元マルチキャストサイトの1つ以上のITRまでのルーターに保存されている状態。 3タプルの2番目の要素は、ITRの下流のルーター、コア、すべてのLISPレシーバーマルチキャストサイトに格納されている状態です。 3タプルの3番目の要素は、各レシーバーマルチキャストサイトの各ETRの下流のルーターに格納され、各レシーバーに到達する状態です。 （S-EID、G）は、送信元と受信者の両方のマルチキャストサイトで同じであることに注意してください。
The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR, and from the second element to the third element is done at the ETRs.
3タプルの最初の要素から2番目の要素への連結/マッピングはITRによって行われ、2番目の要素から3番目の要素への連結はETRで行われます。
Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that uses RPF against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast, the source S is a single ITR of the multicast source site.
コアに格納されるときのマルチキャスト状態は、現在のように常に（S、G）状態、またはLISPサイトが展開されるときに存在するので（S-RLOC、G）状態です。コアルーターは互いに区別できません。 RLOC名前空間のコアルーティングテーブルに対してRPFを使用する状態であるため、これらは必要ありません。違いは、特定のソースの配布ツリーのルートの場所です。従来のマルチキャストコアでは、送信元Sは送信元ホストのIPアドレスです。 LISP-Multicastの場合、ソースSはマルチキャストソースサイトの単一のITRです。
An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So, an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR becomes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be built and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined.
ITRは、ETRがPIM Join / Pruneメッセージをレシーバーマルチキャストサイトから伝播するときに使用されるLISP EID-to-RLOCマッピングに基づいて選択されます。選択は、サイトにユニキャストパケットを送信するときにITRがETRを選択するために使用するのと同じアルゴリズムに基づいています。ユニキャストの場合、ETRの到達可能性に応じて、ITRはパケットごとに変更できます。そのため、ITRはローカルの到達可能性状態を使用して比較的簡単に変更できます。ただし、マルチキャストの場合、ITRが到達不能になると、カプセル化ルートが変更されたため、新しい配布ツリーの状態を構築する必要があります。これはRPF変更イベントよりも重要です。RPF変更イベントでは、ルーターは通常、既存のツリー状態のRPFインターフェイスをローカルで変更します。ただし、カプセル化LISPマルチキャストITRが到達不能になった場合、新しい配布状態を構築し、新しいカプセル化を反映する必要があります。したがって、ITRが到達不能になった場合、そのITRに現在参加しているすべてのETRは、（S-RLOC、G）の新しいJoin / Pruneメッセージをトリガーし、ユニキャストカプセル化されたJoin / Pruneメッセージを送信する必要があります。参加している（S-EID、G）を新しいITRに通知します。
This issue can be mitigated by using anycast addressing for the ITRs, so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed, so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures.
この問題は、ITRにエニーキャストアドレッシングを使用することで軽減できるため、コアでのRPFの変更まで問題は軽減されますが、新しいITRに（S-EID、G）を通知するには、ユニキャストカプセル化された結合/プルーンメッセージが必要です。このアプローチの問題は、ETRがITRがいつ変更されたかを実際に認識しないため、新しいエニーキャストITRが（S-EID、G）状態を取得するのは、ETRが定期的な送信手順中に次回それを送信したときのみです。
A number of protocols are used today for inter-domain multicast routing:
現在、ドメイン間マルチキャストルーティングには多くのプロトコルが使用されています。
IGMPv1-v3, MLDv1-v2: These protocols [RFC4604] do not require any changes for LISP-Multicast for two reasons. One is that they are link-local and not used over site boundaries, and the second is that they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and Multicast Listener Discovery version 2 (MLDv2) messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses, which are therefore from the EID namespace.
IGMPv1-v3、MLDv1-v2：これらのプロトコル[RFC4604]では、2つの理由により、LISP-Multicastを変更する必要はありません。 1つはリンクローカルであり、サイトの境界を越えて使用されないこと、2つ目は変換が不要なグループアドレスをアドバタイズすることです。送信元アドレスがIGMPv3およびマルチキャストリスナーディスカバリバージョン2（MLDv2）メッセージで提供される場合、それらは意味的にEIDと見なされ、PIMなどのマルチキャストツリー構築プロトコルがによって受信されるまで、RLOCに変換する必要はありません。サイト境界でのETR。 IGMPおよびMLDに使用されるアドレスは、ソースサイトに割り当てられたアドレスから取得されます。したがって、これらのアドレスはEID名前空間からのものです。
MBGP: Even though the Multiprotocol Extensions for BGP-4 (MBGP) [RFC4760] are not part of a multicast routing protocol, they are used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes that are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. There are no MBGP changes required to support LISP-Multicast.
MBGP：BGP-4（MBGP）のマルチプロトコル拡張（MBGP）[RFC4760]はマルチキャストルーティングプロトコルの一部ではありませんが、ユニキャストBGPピアリングトポロジとマルチキャストMBGPピアリングトポロジが一致しない場合、マルチキャストソースを見つけるために使用されます。 MBGPがLISPマルチキャスト環境で使用される場合、アドバタイズされるプレフィックスはRLOC名前空間からのものです。これにより、受信側マルチキャストサイトは、送信元マルチキャストサイトのITRへのパスを見つけることができます。 MBGPピアリングアドレスは、RLOC名前空間からのものです。 LISP-Multicastをサポートするために必要なMBGPの変更はありません。
MSDP: MSDP [RFC3618] is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of the site will be from the EID namespace so it can be advertised and reached by an internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. Also, the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. There are no MSDP changes required to support LISP-Multicast.
MSDP：MSDP [RFC3618]は、アクティブなマルチキャストソースを他のルーティングドメイン（またはLISPサイト）にアナウンスするために使用されます。アナウンスは、アクティブなマルチキャストソースがさまざまなグループに送信しているサイトからのPIMランデブーポイント（RP）から送られます。 LISPマルチキャストのコンテキストでは、MSDPでアドバタイズされる送信元アドレスは、送信元マルチキャストホストのIDを記述するため、意味的にはEID名前空間からのものになります。コアルーターからMSDPキャッシュに保存される状態は、EID名前空間からのものであるのは事実です。サイト内のRPアドレスはEID名前空間からのものであるため、内部ユニキャストルーティングメカニズムによってアドバタイズおよび到達できます。ただし、MSDPピアRPFチェックがサイト間で適切に機能するためには、RPアドレスを、コアのBGPルーティングテーブルでアドバタイズおよび維持されるルーティング可能なアドレスに変換またはマッピングする必要があります。 MSDPピアリングアドレスは、EIDまたはルーティング可能なアドレス名前空間から取得できます。また、サイトのITRがマッピングデータベースサービスを調べて宛先ピアアドレスが存在しないネームスペースを判別するため、一方的に選択することもできます。 LISP-Multicastをサポートするために必要なMSDPの変更はありません。
PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode [RFC4607], a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to how PIM Join/Prune messages are sent by the LISP-Multicast component. No modifications to any message format, but to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [RFC5135].
PIM-SSM：配布ツリー構築の最も単純な形式では、PIMがSSMモード[RFC4607]で動作すると、ソース配布ツリーが構築され、サイト境界を越えて維持されます。この場合、LISP-MulticastコンポーネントがPIM Join / Pruneメッセージを送信する方法に小さな変更があります。メッセージ形式への変更はありませんが、EID名前空間からの埋め込みアドレスを使用してLISPサイト内から発信されたJoin / Pruneメッセージの取得をサポートし、Join / Pruneメッセージがサイト境界を超えたときにそれらをRLOC名前空間からのアドレスに変換します。これは、[RFC5135]で文書化されている要件に似ています。
BIDIR-PIM: Bidirectional PIM [RFC5015] is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were in a well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using BIDIR-PIM for inter-domain multicast routing, it is recommended to use statically configured RPs. This allows core routers to associate a Bidir group's RP address with an ITR's RLOC address, and site routers to associate the Bidir group's RP address as an EID address. With respect to Designated Forwarder (DF) election in BIDIR-PIM, no changes are required since all messaging and addressing is link-local.
BIDIR-PIM：双方向PIM [RFC5015]は通常、ルーティングドメイン内で実行されますが、ドメイン間環境に展開する場合、共有ツリーのRPアドレスがEID名前空間からのものか、RLOCからのものかを決定する必要があります。名前空間。 RPがサイトベースのルーターにある場合、RPアドレスはEID名前空間からのものです。 RPがRLOCアドレスがルーティングされるコアにある場合、RPアドレスはRLOC名前空間からのものです。 EIDアドレスがRLOC名前空間からの既知のアドレス割り当てブロックにある場合、これは簡単に区別できます。また、RP決定[RFC3956]にEmbedded-RPを使用する場合、グループアドレスの形式は、RPアドレスの名前空間を示す可能性があります。ただし、Embedded-RP IPv6グループアドレスを使用するときにコアルーターが行う必要がある考慮事項については、セクション10を参照してください。ドメイン間マルチキャストルーティングにBIDIR-PIMを使用する場合は、静的に構成されたRPを使用することをお勧めします。これにより、コアルーターはBidirグループのRPアドレスをITRのRLOCアドレスに関連付けることができ、サイトルーターはBidirグループのRPアドレスをEIDアドレスとして関連付けることができます。 BIDIR-PIMでの指定フォワーダー（DF）の選択に関しては、すべてのメッセージングとアドレス指定がリンクローカルであるため、変更は必要ありません。
PIM-ASM: The ASM mode of PIM [RFC4601], the most popular form of PIM, is deployed in the Internet today by having shared trees within a site and using source trees across sites. By the use of MSDP and PIM-SSM techniques described above, multicast connectivity can occur across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared tree that is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and Bootstrap Router (BSR) [RFC5059].
PIM-ASM：PIMの最も一般的な形式であるPIM [RFC4601]のASMモードは、サイト内でツリーを共有し、サイト間でソースツリーを使用することにより、今日インターネットに導入されています。上記のMSDPおよびPIM-SSM技術を使用すると、LISPサイト全体でマルチキャスト接続を確立できます。とはいえ、（*、G）または（S、G、R）のJoin / Pruneメッセージの処理には、サイトに常駐する共有ツリーに対してすべて動作するため、特別なアクションは必要ありません。 ASMと同様に、LISP-Multicastが使用されている場合、コアには（*、G）はありません。これは、RPマッピングメカニズムAuto-RPおよびBootstrap Router（BSR）[RFC5059]にも当てはまります。
Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change.
上記のプロトコルの説明に基づいて、結論は、プロトコルメッセージフォーマットの変更はなく、コントロールプレーンで実行される変換機能だけであるということです。これにより、ネットワーク内の変更する必要のあるコンポーネントが少なくなるため、LISPの移行がより簡単で高速になります。
It should also be stated just like it is in [RFC6830] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets.
また、[RFC6830]の場合と同様に、マルチキャストソースホストにマルチキャストパケットを送信させ、マルチキャストレシーバーホストがマルチキャストパケットを受信するために必要なホストの変更はありません。
The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [RFC6830]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC) as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding.
LISP-マルチキャストデータプレーン操作は、[RFC6830]で指定されている操作およびパケット形式に準拠しています。ただし、ITRからのマルチキャストパケットのカプセル化は、はるかに簡単なプロセスです。プロセスは、内部グループアドレスを外部宛先アドレスにコピーするだけです。また、ITRが独自のIPアドレス（そのRLOC）をソースアドレスとして使用するようにします。パケット転送中にEIDからRLOCへのマッピング検索が実行されないため、マルチキャストのプロセスはより簡単です。
In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then, the OIF-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts.
カプセル化解除の場合、ETRは単に外部ヘッダーを削除し、内部ヘッダー（S-EID、G）アドレスに対してマルチキャストルーティングテーブルルックアップを実行します。次に、（S-EID、G）エントリのOIFリストを使用して、マルチキャストレシーバーホストにつながるサイト側のインターフェイスでパケットを複製します。
There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case.
ユニキャスト転送の場合のように、ETRのデータプローブロジックはありません。
The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site:
次の手順は、サイト内のソースからマルチキャストパケットを受信するときに、ITRによって使用されます。
1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow.
1. LISPサイトのホストによって送信されたマルチキャストデータパケットには、ホストのEIDと等しい送信元アドレスと、マルチキャストグループのアドレスと等しい宛先アドレスがあります。現在の方法でグループ情報を取得していることを前提としています。マルチキャストレシーバーがマルチキャストフローのソースアドレスとグループアドレスを取得する場合も同様です。
2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the OIF-list contains interfaces that are site facing and external facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header that the host built as the outer destination address.
2. ITRがマルチキャストパケットを受信すると、S-EID状態とS-RLOC状態の両方が保存されます。パケットはサイトに面したインターフェイスで受信されたため、RPFルックアップはS-EID状態に基づいています。 RPFチェックが成功した場合、OIFリストにはサイト向けと外部向けのインターフェイスが含まれます。サイト側インターフェイスの場合、LISPヘッダーは付加されません。外部向けインターフェイスの場合、LISPヘッダーが付加されます。 ITRがLISPヘッダーを付加する場合、それは独自のRLOCアドレスを送信元アドレスとして使用し、ホストが外部宛先アドレスとして構築したIPヘッダーによって提供されるグループアドレスをコピーします。
Typically, an ITR will have a single RLOC address, but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case, when (S-RLOC,G) Join/ Prune messages are received for each RLOC, there is a OIF-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on an (S-EID,G) entry, the interfaces of the OIF-list from all (RLOC,G) entries joined to the ITR as well as the site-facing OIF-list joined for (S-EID,G) must be included in packet replication. In addition to replicating for all types of OIF-lists, each OIF-list entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined.
通常、ITRには単一のRLOCアドレスがありますが、同じまたは異なるサービスプロバイダーから割り当てられた複数のRLOCアドレスが存在する場合もあります。この場合、RLOCごとに（S-RLOC、G）Join / Pruneメッセージを受信すると、実行する必要があるOIFリストのマージアクションがあります。したがって、（S-EID、G）エントリで一致するサイトに面したインターフェイスからパケットを受信すると、サイトだけでなくITRに参加しているすべての（RLOC、G）エントリのOIFリストのインターフェイス（S-EID、G）に参加する-facing OIF-listは、パケット複製に含める必要があります。すべてのタイプのOIFリストの複製に加えて、各OIFリストエントリにはRLOCアドレスのタグを付ける必要があるため、カプセル化では、結合されたRLOCの外部ソースアドレスを使用します。
Note that when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs.
異なるマルチキャストレシーバーサイトからのETRが（S-EID、G）加入を受信すると、ポリシーにより、マルチキャストソースサイトに対して異なるS-RLOCを選択する場合があることに注意してください（マルチキャストITRは、ETRマップごとに異なるマルチキャスト優先度と重み値を返すことができます-リクエスト）。この場合、同じ（S-EID、G）がコアの異なる（S-RLOC、G）状態によって実現されています。マルチキャストソースサイトの各ITRは、カプセル化されたマルチキャストトラフィックのソースアドレスに独自のRLOCを選択するため、これによってパケットが重複することはありません。 RLOCアドレスは、リモートマルチキャストETRによって結合されたアドレスです。
When different (S-EID,G) traffic is combined into a single (RLOC,G) core distribution tree, this may cause traffic to go to a receiver multicast site when it does not need to. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2-EID,Gi) through the same core distribution tree of (RLOC1,Gi). When ETRs decapsulate such traffic, they should know from their local (S-EID,G) state if the packet should be forwarded. If there is no (S-EID,G) state that matches the inner packet header, the packet is discarded.
異なる（S-EID、G）トラフィックが単一の（RLOC、G）コア配布ツリーに結合されると、トラフィックが不要なときに受信マルチキャストサイトに送信される可能性があります。これは、1つのレシーバーマルチキャストサイトが（RLOC1、Gi）のコア配布ツリーを通じて（S1-EID、Gi）に参加し、別のマルチキャストレシーバーサイトが（RLOC1、Gi）の同じコア配布ツリーを通じて（S2-EID、Gi）に参加するときに発生します。 ）。 ETRがこのようなトラフィックをカプセル化解除するとき、パケットを転送する必要があるかどうかをローカル（S-EID、G）状態から知る必要があります。内部パケットヘッダーと一致する（S-EID、G）状態がない場合、パケットは破棄されます。
The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site:
次の手順は、ETRがサイト外のソースからマルチキャストパケットを受信するときに使用します。
1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the OIF-list are used for replication to interfaces that are site facing as well as interfaces that are external facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header is not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped.
1. マルチキャストデータパケットが外部に面するインターフェイスのETRによって受信されると、格納されているS-RLOC状態でRPFルックアップを実行します。 RPFチェックが成功した場合、OIFリストのインターフェイスは、サイト向けのインターフェイスと外部向けのインターフェイスへのレプリケーションに使用されます（このETRは、サイト外の受信者の中継マルチキャストルータにもなります）。パケットが外部に面したインターフェイスに複製される場合、LISPカプセル化ヘッダーは削除されません。パケットがサイト側インターフェイスに複製されると、カプセル化ヘッダーが削除されます。
2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site.
2. LISPヘッダーのないパケットは、受信側マルチキャストサイトの（S-EID、G）配信ツリーに転送されます。
Multicast packet replication can happen in the following topological locations:
マルチキャストパケットの複製は、次のトポロジの場所で発生する可能性があります。
o In an IGP multicast router inside a site that operates on S-EIDs.
o S-EIDで動作するサイト内のIGPマルチキャストルータ。
o In a transit multicast router inside of the core that operates on S-RLOCs.
o S-RLOCで動作するコア内部の中継マルチキャストルータ。
o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site.
o パスに応じて1つ以上のETRルーターで、Join / Pruneメッセージがレシーバーマルチキャストサイトを出ます。
o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites.
o 受信側マルチキャストサイトへのMap-Replyで返される優先度に応じて、ソースマルチキャストサイト内の1つ以上のITRルーター。
In the last case, the source multicast site can do replication rather than having a single exit from the site. But this can occur only when the priorities in the Map-Reply are modified for different receiver multicast sites so that the PIM Join/Prune messages arrive at different ITRs.
最後のケースでは、ソースマルチキャストサイトは、サイトから単一の出口を持つのではなく、レプリケーションを実行できます。ただし、これが発生する可能性があるのは、PIM Join / Pruneメッセージが異なるITRに到着するように、Map-Replyの優先順位が異なるレシーバーマルチキャストサイトに対して変更されている場合のみです。
This policy technique, also used in [RFC6836] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6.
[RFC6836]でもユニキャストに使用されているこのポリシー手法は、セクション6で説明したように、配信ツリーの状態を変更する問題を緩和するためにマルチキャストに役立ちます。
This section describes the multicast corollary to [RFC6832] regarding the interworking of multicast routing among LISP and non-LISP sites.
このセクションでは、LISPサイトと非LISPサイト間のマルチキャストルーティングのインターワーキングに関して、[RFC6832]へのマルチキャストの帰結について説明します。
Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same, regardless of whether or not the site is LISP enabled. So, most of the implications are in the core with respect to storing routable EID-Prefixes from either PA or PI blocks.
マルチキャスト通信では、3つ以上のエンティティが一緒に通信するため、インターワーキングシナリオの組み合わせがより複雑になります。ただし、サイトでLISPが有効になっているかどうかに関係なく、サイトで配布ツリーに対して維持される状態は同じです。したがって、ほとんどの影響は、PAまたはPIブロックからのルーティング可能なEIDプレフィックスの格納に関してコアにあります。
Before enumerating the multicast interworking scenarios, let's define three deployment states of a site:
マルチキャストインターワーキングシナリオを列挙する前に、サイトの3つの展開状態を定義しましょう。
o A non-LISP site that will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable.
o 現在と同様にMSDPを使用してPIM-SSMまたはPIM-ASMを実行する非LISPサイト。サイトのアドレスはグローバルにルーティング可能です。
o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site.
o ユニキャストルーティング用にLISPを配置するサイト。サイトのアドレスはグローバルにルーティングできません。このタイプのサイトの名前をuLISPサイトとして定義してみましょう。
o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site.
o ユニキャストルーティングとマルチキャストルーティングの両方にLISPを展開するサイト。サイトのアドレスはグローバルにルーティングできません。このタイプのサイトの名前をLISP-Multicastサイトとして定義してみましょう。
A LISP site enabled for multicast purposes only will not be considered in this document, but a uLISP site as documented in [RFC6832] will be considered. In this section there is no discussion of how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections.
マルチキャストの目的でのみ有効化されたLISPサイトは、このドキュメントでは考慮されませんが、[RFC6832]で文書化されているuLISPサイトが考慮されます。このセクションでは、すべての受信側サイトでLISPマルチキャストが有効になっている場合にLISPサイトがマルチキャストパケットを送信する方法については説明しません。これについては前のセクションで説明しました。
The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites:
LISPマルチキャストサイトを非LISPマルチキャストサイトと相互運用させるために、次のシナリオが存在します。
1. A LISP site must be able to send multicast packets to receiver sites that are a mix of non-LISP sites and uLISP sites.
1. LISPサイトは、非LISPサイトとuLISPサイトが混在する受信サイトにマルチキャストパケットを送信できる必要があります。
2. A non-LISP site must be able to send multicast packets to receiver sites that are a mix of non-LISP sites and uLISP sites.
2. 非LISPサイトは、非LISPサイトとuLISPサイトが混在する受信サイトにマルチキャストパケットを送信できる必要があります。
3. A non-LISP site must be able to send multicast packets to receiver sites that are a mix of LISP sites, uLISP sites, and non-LISP sites.
3. 非LISPサイトは、LISPサイト、uLISPサイト、および非LISPサイトが混在する受信サイトにマルチキャストパケットを送信できる必要があります。
4. A uLISP site must be able to send multicast packets to receiver sites that are a mix of LISP sites, uLISP sites, and non-LISP sites.
4. uLISPサイトは、LISPサイト、uLISPサイト、および非LISPサイトが混在する受信サイトにマルチキャストパケットを送信できる必要があります。
5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites.
5. LISPサイトは、LISPサイト、uLISPサイト、および非LISPサイトが混在する受信サイトにマルチキャストパケットを送信できる必要があります。
In the first scenario, a site is LISP enabled for both unicast and multicast traffic and as such operates on EIDs. Therefore, there is a possibility that the EID-Prefix block is not routable in the core. For LISP receiver multicast sites, this isn't a problem, but for non-LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP Network Address Translation (LISP-NAT) in [RFC6832] solves.
最初のシナリオでは、サイトはユニキャストトラフィックとマルチキャストトラフィックの両方に対してLISPが有効になっているため、EIDで動作します。したがって、EID-Prefixブロックがコアでルーティングできない可能性があります。 LISPレシーバーマルチキャストサイトの場合、これは問題ではありませんが、非LISPまたはuLISPレシーバーマルチキャストサイトの場合、PIM Join / Pruneメッセージがエッジルーターによって受信されると、Join / Pruneメッセージを伝搬するルートがありません。サイトの。これは、[RFC6832]のLISPネットワークアドレス変換（LISP-NAT）が解決するユニキャストの場合と同じです。
LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non-LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So, the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site because it is desirable for ITRs to process a PIM Join/Prune message that is received from an external-facing interface. If the message will be propagated inside of the site, the site-part of the distribution tree is built.
LISP-NATを使用すると、ITRが非LISPサイト宛てのパケットをカプセル化してはならないことに気づく前に、LISPサイトを出るユニキャストパケットがソースアドレスをグローバルにルーティング可能なアドレスにマッピングできます。マルチキャストパケットがLISPサイトを離れるには、ITRがパケットの送信先を認識できるように、配信ツリーの状態を構築する必要があります。したがって、受信側マルチキャストサイトは、EIDアドレスではなく、ルーティング可能なアドレスによってマルチキャスト送信元ホストを認識する必要があります。この場合、ルーティング可能なアドレスは、コアルータに保存および維持される（S-RLOC、G）状態です。外部向けインターフェイスから受信したPIM Join / PruneメッセージをITRが処理することが望ましいため、ホストのルーティング可能なアドレスをサイトのRLOCと同じにすることはできないことに注意することが重要です。メッセージがサイト内に伝播される場合、配布ツリーのサイト部分が構築されます。
Using a globally routable source address allows non-LISP and uLISP multicast receivers to join, create, and maintain a multicast distribution tree. However, the LISP-Multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find an (S-RLOC,G) entry to Join in the core. So, there is a conflict of behavior between the two types of sites.
グローバルにルーティング可能な送信元アドレスを使用すると、非LISPおよびuLISPマルチキャストレシーバーがマルチキャスト配信ツリーに参加、作成、および維持できます。ただし、LISPマルチキャストレシーバーサイトは、PIM加入/プルーニングメッセージがサイトに面したインターフェイスで受信されたときに、EIDからRLOCへのマッピングテーブルルックアップを実行する必要があります。これは、コアに参加する（S-RLOC、G）エントリを検索するためです。したがって、2つのタイプのサイト間で動作の競合があります。
The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs to determine if the site is LISP enabled or not. When it is not LISP enabled, the ITR does not encapsulate the packet. So, for the multicast case, when the ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the mapping database because the source multicast site is using a routable address and not an EID-Prefix address. So, the ETR knows to simply propagate the PIM Join/Prune message to an external-facing interface without converting the (S-EID,G) because it is an (S,G), where S is routable and reachable via core routing tables.
この問題の解決策は、ITRが宛先サイトにユニキャストパケットを送信したいが、サイトでLISPが有効になっているかどうかを判別する必要がある場合と同じです。 LISPが有効になっていない場合、ITRはパケットをカプセル化しません。したがって、マルチキャストの場合、ETRが（S-EID、G）状態のPIM Join / Pruneメッセージを受信すると、S-EIDでマッピングテーブルルックアップを実行します。この場合、ソースマルチキャストサイトはEIDプレフィックスアドレスではなくルーティング可能なアドレスを使用しているため、S-EIDはマッピングデータベースにありません。したがって、ETRは（S-EID、G）である（S、G）であり、Sはルーティング可能なコアルーティングテーブルを介して到達可能であるため、（S-EID、G）を変換せずに、PIM Join / Pruneメッセージを外部に面するインターフェイスに単に伝播することを知っています。 。
Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way the packet forwarding model is used can be explained.
これで、マルチキャスト配信ツリーが非LISPまたはuLISPレシーバーマルチキャストサイトから構築および保守されたので、パケット転送モデルの使用方法を説明できます。
Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable (and not registered to the mapping database system), it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router.
ソースマルチキャストサイトのITRは、受信側マルチキャストサイトのETRからユニキャストカプセル化PIM Join / Pruneメッセージを受信したことがないため、LISP-Multicast受信側サイトがないことがわかります。したがって、ITRがデータをカプセル化する必要はありません。サイトのEIDがルーティング可能でない（そしてマッピングデータベースシステムに登録されていない）ことを（構成によって）アプリオリに認識しているため、ソースホストからのマルチキャストパケットはルーティング可能なアドレスから送信されると想定しています。つまり、送信元ホストがルーティング可能な送信元アドレスを使用してマルチキャストトラフィックを送信するようにするのは、マルチキャスト送信元ホストのシステム管理者の責任です。これが発生すると、ITRは単にルーターとして機能し、通常のマルチキャストルーターのようにマルチキャストパケットを転送します。
There is an alternative to using a LISP-NAT scheme just as there is an alternative to using unicast [RFC6832] forwarding by employing Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) that make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID-Prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen, the mPETR acts as a "Proxy-ETR" (where in unicast it acts as a "Proxy-ITR", or an uPITR [RFC6832]).
プロキシトンネルルーター（PxTR）を使用してユニキャスト[RFC6832]転送を使用する代わりに、LISP-NATスキームを使用する方法もあります。これはマルチキャストルーティングでも同じように機能しますが、LISP以外のサイトとuLISPサイトは、コアでPxTRをマルチキャストする（S-EID、G）のPIM Join / Pruneメッセージを送信するという違いがあります。このPxTRの使用を「マルチキャストプロキシETR」（またはmPETR）と呼びましょう。 mPETRは非常に粗いEIDプレフィックスをアドバタイズするため、PIM加入/プルーニング制御トラフィックを描画して、それらを配布ツリーのターゲットにします。 LISPソースマルチキャストサイトからマルチキャストパケットを取得するには、mPETRからLISPソースマルチキャストサイトへのパス上にツリーを構築する必要があります。これを実現するために、mPETRは「Proxy-ETR」として機能します（ユニキャストでは「Proxy-ITR」またはuPITR [RFC6832]として機能します）。
The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs.
コアにmPETRが存在することにより、ソースマルチキャストサイトITRは、（S-RLOC、G）状態に従ってマルチキャストパケットをカプセル化できます。 （S-RLOC、G）状態は、mPETRからマルチキャストITRに構築されます。カプセル化されたマルチキャストパケットは、mPETRによってカプセル化が解除され、（S-EID、G）状態に従って転送されます。 （S-EID、G）状態は、非LISPおよびuLISPレシーバーマルチキャストサイトからmPETRに構築されます。
Clearly non-LISP-Multicast sites can send multicast packets to non-LISP receiver multicast sites. That is what they do today. However, discussion is required to show how non-LISP-Multicast sites send multicast packets to uLISP receiver multicast sites.
明らかに、非LISPマルチキャストサイトは、非LISPレシーバマルチキャストサイトにマルチキャストパケットを送信できます。それが今日彼らがしていることです。ただし、非LISPマルチキャストサイトがマルチキャストパケットをuLISPレシーバマルチキャストサイトに送信する方法を示すには、説明が必要です。
Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non-LISP source multicast site. Since the source multicast site in this case has not been upgraded to LISP, all multicast source host addresses are routable. So, this case is simplified to where a uLISP receiver multicast site appears to the source multicast site to be a non-LISP receiver multicast site.
uLISPレシーバーマルチキャストサイトは（S、G）状態のターゲットではないため、非LISPソースマルチキャストサイトに向けて（S、G）PIM加入/プルーニングメッセージを送信するだけです。この場合の送信元マルチキャストサイトはLISPにアップグレードされていないため、すべてのマルチキャスト送信元ホストアドレスはルーティング可能です。したがって、このケースは、uLISPレシーバーマルチキャストサイトがソースマルチキャストサイトから非LISPレシーバーマルチキャストサイトに見えるように簡略化されています。
When a non-LISP source multicast site has receivers in either a non-LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. It is known from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. It has been shown in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does an EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to an (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site, so it simply forwards the Join/Prune message. (It also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source.)
LISP以外のソースマルチキャストサイトに非LISP / uLISPサイトまたはLISPサイトのいずれかにレシーバーがある場合、LISPレシーバーマルチキャストサイトを配布ツリーに接続する方法を決定する必要があります。セクション9.1.2から、非LISPおよびuLISPレシーバーマルチキャストサイトが配信ツリーに参加できることがわかっていますが、LISPレシーバーマルチキャストサイトETRは、マルチキャストソースホストのソースアドレスがルーティング可能かどうかを知る必要があります。セクション9.1.1に示されているように、ETRは、外部に面するインターフェースでPIM Join / Pruneメッセージを送信する前に、EIDからRLOCへのマッピング検索を行い、（S、G）を変換する必要があるかどうかを判断しますサイト側インターフェイスで受信したPIM加入/プルーニングメッセージから（S-RLOC、G）への状態。ルックアップが失敗した場合、ETRはソースマルチキャストサイトが非LISPサイトであると結論付けることができるため、Join / Pruneメッセージを転送するだけです。 （非LISPサイトにはITRがなく、ETRとソースの間に名前空間の連続性があるため、ユニキャストカプセル化されたJoin / Pruneメッセージを送信する必要もありません。）
For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy-ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non-LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as configured for sending unicast joins to mPITRs so they can propagate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is a work in progress.
非LISPのソースマルチキャストサイトの場合、（S-EID、G）状態は、マルチキャストプロキシITR（mPITR）を使用してネットワークのエッジに制限できます。 mPITRは、非LISPソースマルチキャストサイトおよびuLISPサイトからネイティブのカプセル化されていないマルチキャストパケットを受け取り、それらをレシーバーマルチキャストサイトのETRまたは非LISPレシーバーマルチキャストまたはuLISPサイトのカプセル化を解除できるmPETRにカプセル化できます。 mPITRは、（S-EID、G）結合を非LISPソースマルチキャストサイトに送信します。配布ツリーを接続するには、マルチキャストETRをmPITRのRLOCアドレスで構成して、両方の（S-RLOC、G）結合を送信してmPITRに配布ツリーを構築し、ユニキャスト結合をmPITRに送信するように構成する必要があります。そのため、（S-EID、G）結合をソースマルチキャストサイトに伝播できます。 mPITRの使用については、さらに研究が進められており、進行中の作業です。
In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled, but the ITR, by definition, is not capable of doing multicast encapsulation. So, for the purposes of multicast routing, the uLISP source multicast site is treated as a non-LISP source multicast site.
前のセクションでは、マッピングデータベースを調べて、マルチキャストレシーバーサイトのETRがソースマルチキャストサイトがLISP対応かどうかを判断する方法について説明しました。ソースマルチキャストサイトがuLISPサイトである場合、LISPは有効ですが、定義上、ITRはマルチキャストカプセル化を行うことができません。したがって、マルチキャストルーティングのために、uLISPソースマルチキャストサイトは非LISPソースマルチキャストサイトとして扱われます。
Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled.
ソースサイトは転送の観点から非LISPソースサイトとして動作するため、非LISPレシーバマルチキャストサイトは、配信ツリーをuLISPソースマルチキャストサイトに結合できます。 ETRにはマルチキャスト機能が組み込まれていないか、有効になっていないため、これはuLISPレシーバーマルチキャストサイトの場合にも当てはまります。
Special considerations are required for LISP receiver multicast sites; since they think the source multicast site is LISP enabled, the ETR cannot know if the ITR is LISP-Multicast enabled. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC [RFC6830]. When the Mpriority is set to 255, the site is considered not multicast capable. So, an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is a LISP-Multicast site or a uLISP site.
LISPレシーバマルチキャストサイトには特別な考慮事項が必要です。ソースマルチキャストサイトはLISP対応であると考えているため、ETRはITRがLISP-Multicast対応であるかどうかを知ることができません。この問題を解決するために、各マッピングデータベースエントリには、RLOC [RFC6830]ごとにマルチキャスト2タプル（優先度、重み）があります。 Mpriorityが255に設定されている場合、サイトはマルチキャスト対応ではないと見なされます。したがって、LISPレシーバマルチキャストサイトのETRは、LISPソースマルチキャストサイトがLISP-マルチキャストサイトであるか、uLISPサイトであるかを区別できます。
When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet-forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site, then it could receive packets like a non-LISP receiver multicast site, thereby making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases.
LISPソースマルチキャストサイトのレシーバーがLISP、非LISP、およびuLISPレシーバーマルチキャストサイトにある場合、マルチキャストパケットの送信方法について競合します。 ITRは、マルチキャストパケットをカプセル化するか、ネイティブに転送できます。レシーバマルチキャストサイトの動作は異なるため、1つのパケット転送メカニズムでは両方を満足させることはできません。ただし、LISPレシーバーマルチキャストサイトがuLISPサイトのように機能する場合、非LISPレシーバーマルチキャストサイトのようにパケットを受信できるため、すべてのレシーバーマルチキャストサイトの動作が均一になります。ただし、これにより次の問題が発生します。oルーティング可能なアドレスを使用したLISP-NAT技術がすべての場合に必要になります。
o Or, alternatively, mPETR deployment would be required, thus forcing coarse EID-Prefix advertisement in the core.
o または、代わりに、mPETRの展開が必要になるため、コアに大まかなEIDプレフィックスアドバタイズが強制されます。
o But, what is most disturbing is that when all sites that participate are LISP-Multicast sites but a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a viable alternative.
o ただし、最も気がかりなのは、参加するすべてのサイトがLISPマルチキャストサイトであるが、非LISPまたはuLISPサイトが配信ツリーに参加している場合、既存の参加しているLISPレシーバマルチキャストサイトはその動作を変更する必要があることです。これは、あまりにも多くの動的なツリー構築チャーンを作成し、実行可能な代替策にはなりません。
So, the solution space options are:
したがって、ソリューションスペースのオプションは次のとおりです。
1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.
1. ソースマルチキャストサイトのLISP ITRが2つのパケットを送信するようにします。1つは（S-RLOC、G）でカプセル化されてLISPレシーバーマルチキャストサイトに到達し、もう1つは（S-EID、G）でカプセル化されずに非LISPに到達します。およびuLISPレシーバーマルチキャストサイト。
2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites.
2. LISP ITRが常に（S-RLOC、G）でパケットをカプセル化して、LISPマルチキャストサイトに到達し、（S-EID、G）パケットをカプセル化解除して非LISPおよびuLISP受信者マルチキャストサイトに転送できるmPETRに到達するようにします。
A LISP database mapping entry that describes the Locator-Set, Mpriority, and Mweight per locator address (RLOC), for an EID-Prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC-formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets.
サイトに関連付けられたEIDプレフィックスのロケーターセット、Mpriority、およびMweight per locator address（RLOC）を記述するLISPデータベースマッピングエントリは、IPv4またはIPv6形式のRLOCアドレスを持つことができます。マッピングエントリにRLOC形式のアドレスが混在している場合、それはデュアルスタックサイトであることをサイトが暗黙的に通知します。つまり、サイトはIPv4またはIPv6ユニキャストパケットを受信できます。
To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [RFC6830] for packet format details.
サイトがデュアルスタックユニキャストパケットおよびデュアルスタックマルチキャストパケットを受信できるかどうかを区別するために、Mpriority値の設定は、IPv4またはIPv6 RLOCに関連します。パケット形式の詳細については、[RFC6830]を参照してください。
If one considers the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension.
同じ配布ツリーを共有するLISP、非LISP、およびuLISPサイトの組み合わせを検討し、IPv4、IPv6、またはデュアルスタックをサポートする機能を検討すると、合計の組み合わせの数は、理解を超えて増加します。
Using some combinatorial math, the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site
いくつかの組み合わせ数学を使用して、サイトの次のプロファイルと発生する可能性のある組み合わせ：1. LISPマルチキャストIPv4サイト
2. LISP-Multicast IPv6 Site
2. LISP-マルチキャストIPv6サイト
3. LISP-Multicast Dual-Stack Site
3. LISPマルチキャストデュアルスタックサイト
4. uLISP IPv4 Site
4. uLISP IPv4サイト
5. uLISP IPv6 Site
5. uLISP IPv6サイト
6. uLISP Dual-Stack Site
6. uLISPデュアルスタックサイト
7. non-LISP IPv4 Site
7. 非LISP IPv4サイト
8. non-LISP IPv6 Site
8. 非LISP IPv6サイト
9. non-LISP Dual-Stack Site
9. 非LISPデュアルスタックサイト
Let's define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below.
（m n）= m！/（n！*（m-n）！）と定義してみましょう。「m choose n」と発音して、以下の組み合わせ数学を説明します。
When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If we sum this up to (9 9), then:
1つのサイトが別のサイトと通信する場合、組み合わせは（9 2）であり、1つのサイトが別の2つのサイトと通信する場合、組み合わせは（9 3）です。これを（9 9）まで合計すると、次のようになります。
(9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =
36 + 84 + 126 + 126 + 84 + 36 + 9 + 1
which results in 502 as the total number of cases to be considered.
検討対象のケースの総数は502になります。
This combinatorial gets even worse when one considers a site using one address family inside of the site and the xTRs using the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs).
この組み合わせは、サイト内の1つのアドレスファミリを使用しているサイトと、他のアドレスファミリを使用しているxTRを検討するとさらに悪化します（IPv6 RLOCでIPv4 EIDを使用するか、IPv4 RLOCでIPv6 EIDを使用する場合など）。
To rationalize this combinatorial nightmare, there are some guidelines that need to be put in place:
この組み合わせの悪夢を合理化するために、導入する必要があるいくつかのガイドラインがあります。
o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, head-end replication can be avoided by building and sending packets on each address-family-based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family.
o サイト間で共有される各配布ツリーは、IPv4配布ツリーまたはIPv6配布ツリーのいずれかになります。したがって、各アドレスファミリベースの配布ツリーでパケットを作成して送信することにより、ヘッドエンドレプリケーションを回避できます。 1つのアドレスファミリ形式から別のアドレスファミリ形式へのマルチキャストパケット変換を実行したいという衝動があるかもしれませんが、それは実行不可能な過度に複雑な衝動です。マルチキャストITRは、内部ヘッダーと外部ヘッダーが同じアドレスファミリからのものであるパケットのみをカプセル化します。
o All LISP sites on a multicast distribution tree must share a common address family that is determined by the source site's Locator-Set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP enabled. This means that priority-based policy modification is prohibited. When a receiver multicast site ETR receives an (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID.
o マルチキャスト配信ツリー上のすべてのLISPサイトは、LISPデータベースマッピングエントリのソースサイトのLocator-Setによって決定される共通のアドレスファミリを共有する必要があります。すべてのレシーバーマルチキャストサイトは、ソースマルチキャストサイトによって制御される最高のRLOC優先度を使用します。これは、ソースサイトでLISP-MulticastまたはuLISPが有効になっている場合に当てはまります。つまり、優先順位に基づくポリシーの変更は禁止されています。レシーバーマルチキャストサイトETRが（S-EID、G）加入を受信すると、S-EIDと同じアドレスファミリのS-RLOCを選択する必要があります。
o When a multicast Locator-Set has more than one locator, only locators from the same address family MUST be set to the same best priority value. A mixed Locator-Set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators.
o マルチキャストLocator-Setに複数のロケーターがある場合、同じアドレスファミリのロケーターのみが同じ最高の優先度の値に設定される必要があります。混合ロケーターセットは存在できますが（ユニキャスト使用の場合）、マルチキャスト優先順位は同じアドレスファミリーロケーターのセットである必要があります。
o When the source site is not LISP enabled, determining the address family for the flow is up to how receivers find the source and group information for a multicast flow.
o ソースサイトでLISPが有効になっていない場合、フローのアドレスファミリの決定は、受信者がマルチキャストフローのソースおよびグループ情報をどのように見つけるかによって決まります。
Thus far, Section 9 has shown all combinations of multicast connectivity that could occur. As already concluded, this can be quite complicated, and, if the design is too ambitious, the dynamics of the protocol could cause a lot of instability.
これまで、セクション9では、発生する可能性のあるマルチキャスト接続のすべての組み合わせを示してきました。すでに結論したように、これは非常に複雑になる可能性があり、設計が野心的すぎる場合、プロトコルのダイナミクスによって多くの不安定性が生じる可能性があります。
The trade-off decisions are hard to make, and so the same single solution is desirable to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state.
トレードオフの決定は難しいため、IPv4とIPv6の両方のマルチキャストで同じソリューションを使用することが望ましいです。ユニキャストとマルチキャストの両方のEID名前空間の状態を最小化（または削除）しながら、IPv4ユニキャストとマルチキャスト、およびIPv6ユニキャストとマルチキャストのすべてに対して段階的に展開可能なソリューションを用意することが不可欠です。
Therefore, the design decision to go with uPITRs [RFC6832] for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space in order to optimize state requirements and avoid head-end data replication at ITRs.
したがって、ユニキャストルーティングのuPITR [RFC6832]とマルチキャストルーティングのmPETRを採用するという設計上の決定は、状態要件を最適化し、ITRでのヘッドエンドデータレプリケーションを回避するためのソリューションスペースのスイートスポットのようです。
When ASM and PIM-BIDIR are used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in an IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message that contains an Embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace and need to extract an RP address from the RLOC namespace.
ASMとPIM-BIDIRがIPv6ドメイン間環境で使用される場合、RPのユニキャストアドレスをIPv6グループアドレスに埋め込む手法が存在します[RFC3956]。エンドサイトのルータが、Embedded-RPグループアドレスを含むPIM Join / Pruneメッセージを処理するとき、グループアドレスからRPアドレスを抽出し、EID名前空間から扱います。ただし、コアルーターにはEID名前空間の状態がないため、RLOC名前空間からRPアドレスを抽出する必要があります。
Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the Embedded-RP address is from the RLOC namespace. The mapped RP address is obtained from an EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created.
したがって、Embedded-RPアドレスがRLOC名前空間からのものであるグループアドレスにグループアドレスをマップするのは、マルチキャストレシーバーサイトのETRの責任です。マッピングされたRPアドレスは、EIDからRLOCへのマッピングデータベースルックアップから取得されます。また、ETRはユニキャスト（*、G）のJoin / PruneメッセージをITRに送信するため、ソースサイトの常駐RPからITRへの配布ツリーのブランチが作成されます。
This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address.
この手法は、（S、G）状態を変換し、Join / Pruneメッセージをコアに伝播するための、この仕様で説明されている手法と同じです。唯一の違いは、Join / Pruneメッセージの（*、G）状態は、Embedded-RPグループアドレスでエンコードされたユニキャストアドレスが含まれているため、マップされることです。
If the core routers are upgraded to support [RFC5496], then the EID-specific data can be passed through the core without, possibly, having to store the state in the core.
コアルーターが[RFC5496]をサポートするようにアップグレードされている場合は、EID固有のデータをコアに渡すことができます。コアに状態を保存する必要はありません。
By doing this, one can eliminate the ETR from unicast encapsulated PIM Join/Prune messages to the source site's ITR.
これを行うことで、ソースサイトのITRへのユニキャストカプセル化PIM加入/プルーニングメッセージからETRを排除できます。
However, this solution is restricted to a small set of workable cases that would not be good for general use of LISP-Multicast. In addition, due to slow convergence properties, it is not recommended for LISP-Multicast.
ただし、このソリューションは、LISP-Multicastの一般的な使用には適さない、実行可能な少数のケースに制限されています。さらに、収束プロパティが遅いため、LISP-Multicastには推奨されません。
Mtrace functionality MUST be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible.
Mtrace機能は、マルチキャストレシーバーからマルチキャストソースへのすべてのホップが可視であるユニキャストtraceroute機能と一致している必要があります。
The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon mtrace version 2 specified in [MTRACE].
LISPマルチキャスト環境で使用するmtraceの設計は決定されますが、[MTRACE]で指定されたmtraceバージョン2に基づいて構築する必要があります。
The security concerns for LISP-Multicast are mainly the same as for the base LISP specification [RFC6830] and for multicast in general, including PIM-ASM [RFC4601].
LISP-Multicastのセキュリティ上の問題は、基本的なLISP仕様[RFC6830]と同じであり、一般にPIM-ASM [RFC4601]を含むマルチキャストに関するものです。
There may be a security concern with respect to unicast PIM messages. When multiple receiver sites are joining an (S-EID1,G) distribution tree that maps to a (RLOC1,G) core distribution tree, and a malicious receiver site joins an (S-EID2,G) distribution tree that also maps to the (RLOC1,G) core distribution tree, the legitimate sites will receive data from S-EID2 when they did not ask for it.
ユニキャストPIMメッセージに関してセキュリティ上の懸念があるかもしれません。複数の受信側サイトが（RLOC1、G）コア配布ツリーにマップする（S-EID1、G）配布ツリーに参加していて、悪意のある受信者サイトが（S-EID2、G）配布ツリーに参加している（RLOC1、G）コア配布ツリー。正当なサイトは、S-EID2から要求されなかったときにデータを受信します。
Other than as noted above, there are currently no known security differences between multicast with LISP and multicast without LISP. However, this has not been a topic that has been investigated deeply so far; therefore, additional issues might arise in future.
上記以外に、LISPを使用したマルチキャストとLISPを使用しないマルチキャストとの間には、現時点で既知のセキュリティの違いはありません。ただし、これはこれまで深く調査されてきたトピックではありません。そのため、今後さらに問題が発生する可能性があります。
The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at the Summer 2008 IETF in Dublin were Toerless Eckert and IJsbrand Wijnands.
著者は、この提案と仕様の作成に議論、アイデア、およびコメントを提供してくれた人々に感謝したいと思います。専門家によるレビューを提供したのは、スコットブリム、グレッグシェパード、デイブオランです。 2008年夏のダブリンでのIETFでの議論からの他の解説は、Toerless EckertとIJsbrand Wijnandsでした。
The authors would also like to thank the MBONED working group for constructive and civil verbal feedback when this document was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko.
この文書がミネアポリスで開催された2008年秋のIETFで発表されたとき、著者は建設的で市民の言葉によるフィードバックについてMBONEDワーキンググループに感謝します。特に、Tom Pusateri、Steve Casner、Marshall Eubanks、Dimitri Papadimitriou、Ron Bonica、Lenny Guardino、Alia Atlas、Jesus Arango、Jari Arkkoによる良い解説がありました。
An expert review of this specification was done by Yiqun Cai and Liming Wei. The authors thank them for their detailed comments.
この仕様の専門家によるレビューは、Yiqun CaiとLiming Weiによって行われました。著者は彼らの詳細なコメントを彼らに感謝します。
This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into a LISP working group document.
この作業は、IRTFのルーティングリサーチグループ（RRG）から始まりました。個々の提出物は、LISPワーキンググループドキュメントに変換されました。
[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月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「Multicast Source Discovery Protocol（MSDP）」、RFC 3618、2003年10月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、2004年11月。
[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、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPv3）およびソース固有のマルチキャスト用のマルチキャストリスナー検出プロトコルバージョン2（MLDv2）の使用」、RFC 4604、8月2006年
[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月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[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、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135] Wing、D。およびT. Eckert、「ネットワークアドレストランスレータ（NAT）およびネットワークアドレスポートトランスレータ（NAPT）のIPマルチキャスト要件」、BCP 135、RFC 5135、2008年2月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496] Wijnands、IJ。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、2009年3月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）and Non-LISP Sites between Interworking」、RFC 6832、2013年1月。
[MTRACE] Asaeda, H. and W. Lee, Ed., "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, October 2012.
[MTRACE] Asaeda、H. and W. Lee、Ed。、 "Mtrace Version 2：Traceroute Facility for IP Multicast"、Work in Progress、2012年10月。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059] Bhaskar、N.、Gall、A.、Lingard、J。、およびS. Venaas、「Bootstrap Router（BSR）Mechanism for Protocol Independent Multicast（PIM）」、RFC 5059、2008年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（LISP + ALT）」、RFC 6836、2013年1月。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA USA
ディノファリナッチシスコシステムズタスマンドライブサンノゼ、カリフォルニア州アメリカ合衆国
EMail: farinacci@gmail.com
Dave Meyer Cisco Systems Tasman Drive San Jose, CA USA
Dave Meyer Cisco Systems Tasman Drive San Jose、CA USA
EMail: dmm@cisco.com
John Zwiebel Cisco Systems Tasman Drive San Jose, CA USA
ジョンズウィーベルシスコシステムズタスマンドライブアメリカ合衆国カリフォルニア州サンノゼ
EMail: jzwiebel@cruzio.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA USA
EMail: stig@cisco.com