[要約] RFC 8378は、Signal-Free Locator/ID Separation Protocol (LISP) Multicastに関する規格です。この規格の目的は、LISPを使用してマルチキャストトラフィックを効率的に配信するための手法を提供することです。
Internet Engineering Task Force (IETF) V. Moreno
Request for Comments: 8378 Cisco Systems
Category: Experimental D. Farinacci
ISSN: 2070-1721 lispers.net
May 2018
Signal-Free Locator/ID Separation Protocol (LISP) Multicast
無信号ロケータ/ ID分離プロトコル（LISP）マルチキャスト
Abstract
概要
When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.
Locator / ID Separation Protocol（LISP）サイトでマルチキャストソースとレシーバーがアクティブな場合、コアネットワークはネイティブマルチキャストを使用してパケットをソースからグループメンバーに配信できるようにする必要があります。マルチキャストを使用してマルチキャストサイトを接続できない場合は、信号のないメカニズムを使用して、サイト間でトラフィックを流すことができます。このドキュメントで説明するメカニズムは、データプレーンのコアネットワーク上でユニキャストレプリケーションとカプセル化を使用し、LISPマッピングデータベースシステムを使用して、ソースLISPマルチキャストサイトのカプセル化者が受信者LISPマルチキャストサイトのカプセル開放者を見つけられるようにします。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8378.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8378で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6
5. General Procedures . . . . . . . . . . . . . . . . . . . . . 7
5.1. General Receiver-Site Procedures . . . . . . . . . . . . 8
5.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8
5.1.2. Receiver-Site Registration . . . . . . . . . . . . . 9
5.1.3. Consolidation of the Replication List . . . . . . . . 10
5.2. General Source-Site Procedures . . . . . . . . . . . . . 10
5.2.1. Multicast Tree Building at the Source Site . . . . . 10
5.2.2. Multicast Destination Resolution . . . . . . . . . . 11
5.3. General LISP Notification Procedures . . . . . . . . . . 11
6. Source-Specific Multicast Trees . . . . . . . . . . . . . . . 12
6.1. Source Directly Connected to Source-ITRs . . . . . . . . 12
6.2. Source Not Directly Connected to Source-ITRs . . . . . . 12
7. Multihoming Considerations . . . . . . . . . . . . . . . . . 13
7.1. Multiple ITRs at a Source Site . . . . . . . . . . . . . 13
7.2. Multiple ETRs at a Receiver Site . . . . . . . . . . . . 13
7.3. Multiple RLOCs for an ETR at a Receiver Site . . . . . . 14
7.4. Multicast RLOCs for an ETR at a Receiver Site . . . . . . 14
8. PIM Any-Source Multicast Trees . . . . . . . . . . . . . . . 15
9. Signal-Free Multicast for Replication Engineering . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
When multicast sources and receivers are active at LISP sites, and the core network between the sites does not provide multicast support, a signal-free mechanism can be used to create an overlay that will allow multicast traffic to flow between sites and connect the multicast trees at the different sites.
LISPサイトでマルチキャストソースとレシーバーがアクティブで、サイト間のコアネットワークがマルチキャストサポートを提供していない場合、シグナルフリーメカニズムを使用して、マルチキャストトラフィックがサイト間を流れ、マルチキャストツリーに接続できるようにするオーバーレイを作成できます。別のサイトで。
The signal-free mechanism proposed here does not extend PIM [RFC7761] over the overlay as proposed in [RFC6831], nor does the mechanism utilize direct signaling between the Receiver-ETRs and Sender-ITRs as described in [LISP-MULTI-SIGNALING]. The signal-free mechanism proposed reduces the amount of signaling required between sites to a minimum and is centered around the registration of receiver sites for a particular multicast group or multicast channel with the LISP mapping system.
ここで提案されている無信号メカニズムは、[RFC6831]で提案されているようにPIM [RFC7761]をオーバーレイに拡張しません。また、[LISP-MULTI-SIGNALING]で説明されているように、メカニズムはレシーバETRとセンダITR間の直接シグナリングを利用しません。 。提案された無信号メカニズムにより、サイト間で必要なシグナリングの量が最小限に抑えられ、LISPマッピングシステムを使用した特定のマルチキャストグループまたはマルチキャストチャネルの受信サイトの登録が中心になります。
Registrations from the different receiver sites will be merged at the mapping system to assemble a multicast-replication-list inclusive of all Routing Locators (RLOCs) that lead to receivers for a particular multicast group or multicast channel. The replication list for each specific multicast entry is maintained as a database mapping entry in the LISP mapping system.
異なるレシーバーサイトからの登録は、マッピングシステムでマージされ、特定のマルチキャストグループまたはマルチキャストチャネルのレシーバーにつながるすべてのルーティングロケーター（RLOC）を含むマルチキャストレプリケーションリストを組み立てます。特定の各マルチキャストエントリの複製リストは、LISPマッピングシステムのデータベースマッピングエントリとして維持されます。
When the Ingress Tunnel Router (ITR) at the source site receives multicast traffic from sources at its site, the ITR can query the mapping system by issuing Map-Request messages for the (S,G) source and destination addresses in the packets received. The mapping system will return the RLOC replication list to the ITR, which the ITR will cache as per standard LISP procedure. Since the core is assumed to not support multicast, the ITR will replicate the multicast traffic for each RLOC on the replication list and will unicast encapsulate the traffic to each RLOC. The combined function or replicating and encapsulating the traffic to the RLOCs in the replication list is referred to as "rep-encapsulation" in this document.
送信元サイトのIngress Tunnel Router（ITR）がそのサイトの送信元からマルチキャストトラフィックを受信すると、ITRは、受信したパケットの（S、G）送信元アドレスと宛先アドレスに対するMap-Requestメッセージを発行して、マッピングシステムにクエリを実行できます。マッピングシステムは、RLOCレプリケーションリストをITRに返します。ITRは、標準のLISP手順に従ってキャッシュします。コアはマルチキャストをサポートしていないと想定されているため、ITRはレプリケーションリストの各RLOCのマルチキャストトラフィックを複製し、トラフィックを各RLOCにユニキャストカプセル化します。このドキュメントでは、レプリケーションリスト内のRLOCへのトラフィックを複製およびカプセル化する機能の組み合わせを「rep-encapsulation」と呼びます。
The document describes general procedures (Section 5) and information encoding that are required at the receiver sites and source sites to achieve signal-free multicast interconnectivity. The general procedures for mapping system notifications to different sites are also described. A section dedicated to the specific case of Source-Specific Multicast (SSM) trees discusses the implications to the general procedures for SSM multicast trees over different topological scenarios. A section on Any-Source Multicast (ASM) support is included to identify the constraints that come along with supporting it using LISP signal-free multicast.
このドキュメントでは、シグナルフリーのマルチキャスト相互接続を実現するためにレシーバーサイトとソースサイトで必要な一般的な手順（セクション5）と情報のエンコードについて説明します。システム通知をさまざまなサイトにマッピングする一般的な手順についても説明します。ソース固有マルチキャスト（SSM）ツリーの特定のケースに特化したセクションでは、さまざまなトポロジシナリオにおけるSSMマルチキャストツリーの一般的な手順への影響について説明します。 Any-Source Multicast（ASM）サポートに関するセクションは、LISPシグナルフリーマルチキャストを使用してそれをサポートすることに伴う制約を識別するために含まれています。
There is a section dedicated to Replication Engineering, which is a mechanism to reduce the impact of head-end replication. The mapping system, via LISP signal-free mechanisms, can be used to build a layer of Re-encapsulating Tunnel Routers (RTRs).
ヘッドエンドレプリケーションの影響を軽減するメカニズムであるレプリケーションエンジニアリング専用のセクションがあります。 LISPシグナルフリーメカニズムを介したマッピングシステムを使用して、再カプセル化トンネルルータ（RTR）の層を構築できます。
LISP-related terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and Map-Resolver (MR) are defined in the LISP specification [RFC6830].
LISP関連の用語、特にMap-Request、Map-Reply、Ingress Tunnel Router（ITR）、Egress Tunnel Router（ETR）、Map-Server（MS）、およびMap-Resolver（MR）は、LISP仕様[RFC6830 ]。
Extensions to the definitions in [RFC6830] for their application to multicast routing are documented in [RFC6831].
マルチキャストルーティングへの適用のための[RFC6830]の定義に対する拡張は、[RFC6831]に文書化されています。
Terms defining interactions with the LISP mapping system are defined in [RFC6833].
LISPマッピングシステムとの相互作用を定義する用語は、[RFC6833]で定義されています。
The following terms are consistent with the definitions in [RFC6830] and [RFC6831]. The terms are specific cases of the general terms and are defined here to facilitate the descriptions and discussions within this particular document.
以下の用語は、[RFC6830]および[RFC6831]の定義と一致しています。用語は一般的な用語の特定のケースであり、この特定のドキュメント内の説明と議論を容易にするためにここで定義されています。
Source: Multicast source endpoint. The host that originates multicast packets.
ソース：マルチキャストソースエンドポイント。マルチキャストパケットを発信するホスト。
Receiver: Multicast group member endpoint. The host joins a multicast group as a receiver of multicast packets sent to the group.
受信者：マルチキャストグループメンバーのエンドポイント。ホストは、グループに送信されたマルチキャストパケットの受信者としてマルチキャストグループに参加します。
Receiver site: LISP site where multicast receivers are located.
レシーバーサイト：マルチキャストレシーバーが配置されているLISPサイト。
Source site: LISP site where multicast sources are located.
ソースサイト：マルチキャストソースが配置されているLISPサイト。
RP site: LISP site where an ASM PIM Rendezvous Point (RP) [RFC7761] is located. The RP site and the source site MAY be the same in some situations.
RPサイト：ASM PIMランデブーポイント（RP）[RFC7761]が配置されているLISPサイト。 RPサイトとソースサイトは、状況によっては同じになる場合があります。
Receiver-ETR: LISP decapsulating the Tunnel Router (xTR) at the receiver site. This is a multicast ETR.
レシーバーETR：レシーバーサイトでトンネルルーター（xTR）のカプセル化を解除するLISP。これはマルチキャストETRです。
Source-ITR: LISP encapsulating xTR at the source site. This is a multicast ITR.
Source-ITR：ソースサイトでxTRをカプセル化するLISP。これはマルチキャストITRです。
RP-xTR: LISP xTR at the RP site. This is typically a multicast ITR.
RP-xTR：RPサイトのLISP xTR。これは通常、マルチキャストITRです。
Replication list: Mapping-entry containing the list of RLOCs that have registered receivers for a particular multicast entry.
複製リスト：特定のマルチキャストエントリの受信者を登録したRLOCのリストを含むマッピングエントリ。
Multicast entry: A tuple identifying a multicast tree. Multicast entries are in the form of (S-prefix, G-prefix).
マルチキャストエントリ：マルチキャストツリーを識別するタプル。マルチキャストエントリは（Sプレフィックス、Gプレフィックス）の形式です。
Rep-encapsulation: The process of replicating and then encapsulating traffic to multiple RLOCs.
Rep-encapsulation：複数のRLOCへのトラフィックを複製してカプセル化するプロセス。
Re-encapsulating Tunnel Router (RTR): An RTR is a router that implements the re-encapsulating tunnel function detailed in Section 8 of the main LISP specification [RFC6830]. A LISP RTR performs packet re-routing by chaining ETR and ITR functions, whereby it first removes the LISP header of an ingress packet and then prepends a new LISP header to an egress packet.
再カプセル化トンネルルーター（RTR）：RTRは、メインのLISP仕様[RFC6830]のセクション8で詳述されている再カプセル化トンネル機能を実装するルーターです。 LISP RTRは、ETR機能とITR機能を連鎖させてパケットの再ルーティングを実行します。これにより、最初に入力パケットのLISPヘッダーが削除され、次に新しいLISPヘッダーが出力パケットの前に付加されます。
RTR Level: An RTR level is encoded in a Replication List Entry (RLE) LISP Canonical Address Format (LCAF) Type detailed in [RFC8060]. Each entry in the replication list contains an address of an xTR and a level value. Level values are used to create a replication hierarchy so that ITRs at source LISP sites replicate to the lowest (smaller value) level number RTRs in an RLE. And then RTRs at a given level replicate to the next higher level of RTRs. The number of RTRs at each level are engineered to control the fan-out or replication factor, so a trade-off between the width of the level versus the number of levels can be selected.
RTRレベル：RTRレベルは、[RFC8060]で詳述されているレプリケーションリストエントリ（RLE）LISP正規アドレス形式（LCAF）タイプでエンコードされます。レプリケーションリストの各エントリには、xTRのアドレスとレベル値が含まれています。レベル値は、レプリケーション階層を作成するために使用されます。これにより、ソースLISPサイトのITRは、RLE内の最も低い（値が小さい）レベル番号RTRに複製されます。そして、特定のレベルのRTRは、次に高いレベルのRTRに複製されます。各レベルのRTRの数は、ファンアウトまたはレプリケーション係数を制御するように設計されているため、レベルの幅とレベルの数の間のトレードオフを選択できます。
ASM: Any-Source Multicast as defined in [RFC3569] where multicast distribution trees are built with a Rendezvous Point [RFC7761].
ASM：ランデブーポイント[RFC7761]を使用してマルチキャスト配信ツリーが構築される[RFC3569]で定義されているAny-Source Multicast。
SSM: Source-Specific Multicast as defined in [RFC3569] where multicast distribution trees are built and rooted at the multicast router(s) directly connected to the multicast source.
SSM：[RFC3569]で定義されている送信元固有のマルチキャスト。マルチキャスト配信ツリーは、マルチキャスト送信元に直接接続されているマルチキャストルーターで構築およびルート化されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The reference model that will be used for the discussion of the signal-free multicast tree interconnection is illustrated in Figure 1.
無信号マルチキャストツリー相互接続の説明に使用される参照モデルを図1に示します。
MS/MR
+---+
| |
+---+ +---+ +---+ +---+ +---+
Src-1 ----| R1|-----|ITR| | |ETR|------| R2|----- Rcv-2
+---+ +---+ | +---+ +---+
\ | /
Source-site-1 \ | / Receiver-site-2
\ | /
\ | /
\ | /
Core
/ \
/ \
/ \
/ \
/ \
+---+ +---+
Src-3 --------------|ITR| |ETR|---------------- Rcv-4
+---+ +---+
Source-site-3 Receiver-site-4
ソースサイト3レシーバサイト4
Figure 1: LISP Multicast Generic Reference Model
図1：LISPマルチキャスト汎用参照モデル
Sites 1 and 3 are source sites.
サイト1と3はソースサイトです。
Source-site-3 presents a source (Src-3) that is directly connected to the Source-ITR.
Source-site-3は、Source-ITRに直接接続されているソース（Src-3）を表します。
Source-site-1 presents a source (Src-1) that is one hop or more away from the Source-ITR.
Source-site-1は、Source-ITRから1ホップ以上離れたソース（Src-1）を提示します。
Receiver-site-2 and -4 are receiver sites with not-directly connected and directly connected receiver endpoints, respectively.
レシーバーサイト2と-4は、直接接続されていないレシーバーサイトと直接接続されているレシーバーエンドポイントをそれぞれ備えたレシーバーサイトです。
R1 is a multicast router in Source-site-1.
R1はSource-site-1のマルチキャストルーターです。
R2 is a multicast router at the receiver site.
R2は受信側サイトのマルチキャストルータです。
Map-Servers and Map-Resolvers are reachable in the RLOC space in the core; only one is shown for illustration purposes, but these can be many or even part of a distributed mapping system, such as a Delegated Database Tree (DDT).
Map-ServerとMap-Resolverは、コアのRLOCスペースで到達可能です。説明のために1つだけを示していますが、これらは委任データベースツリー（DDT）などの分散マッピングシステムの多くの場合やその一部である場合もあります。
The procedures for interconnecting multicast trees over an overlay can be broken down into three functional areas:
オーバーレイを介してマルチキャストツリーを相互接続する手順は、3つの機能領域に分類できます。
o Receiver-site procedures
o レシーバーサイトの手順
o Source-site procedures
o ソースサイトの手順
o LISP notification procedures
o LISP通知手順
The receiver-site procedures will be common for most tree types and topologies.
レシーバーサイトの手順は、ほとんどのツリータイプとトポロジに共通です。
The procedures at the source site can vary depending on the type of trees being interconnected as well as the topological relation between sources and source-site xTRs. For ASM trees, a special case of the source site is the RP site for which a variation of the source-site procedures MAY be necessary if ASM trees are to be supported in future specifications of LISP signal-free multicast.
ソースサイトでの手順は、相互接続されているツリーのタイプや、ソースとソースサイトのxTR間のトポロジの関係によって異なります。 ASMツリーの場合、ソースサイトの特別なケースはRPサイトです。AISPツリーがLISPシグナルフリーマルチキャストの将来の仕様でサポートされる場合、ソースサイト手順のバリエーションが必要になる場合があります。
The LISP notification procedures between sites are normalized for the different possible scenarios. Certain scenarios MAY benefit from a simplified notification mechanism or no notification requirement at all.
サイト間のLISP通知手順は、考えられるさまざまなシナリオに合わせて正規化されています。特定のシナリオでは、通知メカニズムが簡素化されているか、通知要件がまったくない場合があります。
The interconnection of multicast trees across different LISP sites involves the following procedures to build the necessary multicast distribution trees across sites.
異なるLISPサイト間でのマルチキャストツリーの相互接続には、サイト間で必要なマルチキャスト配信ツリーを構築するための次の手順が含まれます。
1. The presence of multicast receiver endpoints is detected by the Receiver-ETRs at the receiver sites.
1. マルチキャストレシーバエンドポイントの存在は、レシーバサイトのレシーバETRによって検出されます。
2. Receiver-ETRs register their RLOCs as part of the replication list for the multicast entry the detected receivers subscribe to.
2. レシーバーETRは、RLOCを、検出されたレシーバーがサブスクライブするマルチキャストエントリのレプリケーションリストの一部として登録します。
3. The mapping system merges all Receiver-ETR or delivery-group RLOCs to build a comprehensive replication list inclusive of all receiver sites for each multicast entry.
3. マッピングシステムは、すべての受信者ETRまたは配信グループRLOCをマージして、各マルチキャストエントリのすべての受信者サイトを含む包括的な複製リストを作成します。
4. LISP Map-Notify messages MUST be sent to the Source-ITR informing of any changes in the replication list.
4. レプリケーションリストの変更を通知するLISP Map-NotifyメッセージをSource-ITRに送信する必要があります。
5. Multicast tree building at the source site is initiated when the Source-ITR receives the LISP notification.
5. Source-ITRがLISP通知を受信すると、ソースサイトでのマルチキャストツリーの構築が開始されます。
Once the multicast distribution trees are built, the following forwarding procedures may take place:
マルチキャスト配信ツリーが構築されると、次の転送手順が実行される場合があります。
1. The source sends multicast packets to the multicast group destination address.
1. 送信元は、マルチキャストパケットをマルチキャストグループの宛先アドレスに送信します。
2. Multicast traffic follows the multicast tree built at the source site and makes its way to the Source-ITRs.
2. マルチキャストトラフィックは、ソースサイトで構築されたマルチキャストツリーに従い、Source-ITRに到達します。
3. The Source-ITR will issue a Map-Request to resolve the replication list for the multicast entry.
3. Source-ITRはMap-Requestを発行して、マルチキャストエントリのレプリケーションリストを解決します。
4. The mapping system responds to the Source-ITR with a Map-Reply containing the replication list for the multicast group requested.
4. マッピングシステムは、要求されたマルチキャストグループの複製リストを含むMap-ReplyでSource-ITRに応答します。
5. The Source-ITR caches the replication list received in the map-reply for the multicast entry.
5. Source-ITRは、マルチキャストエントリのマップ応答で受信した複製リストをキャッシュします。
6. Multicast traffic is rep-encapsulated. That is, the packet is replicated for each RLOC in the replication list and then encapsulated to each one.
6. マルチキャストトラフィックはrepカプセル化されます。つまり、パケットは複製リスト内の各RLOCに対して複製され、それぞれにカプセル化されます。
When the Receiver-ETRs are directly connected to the receivers (e.g., Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP reports from the receivers indicating which group the receivers wish to subscribe to. Based on these IGMP reports, the Receiver-ETR is made aware of the presence of receivers as well as which group they are interested in.
レシーバーETRがレシーバー（たとえば、図1のレシーバーサイト4）に直接接続されている場合、レシーバーETRは、レシーバーからサブスクライブするグループを示すIGMPレポートをレシーバーから受信します。これらのIGMPレポートに基づいて、Receiver-ETRは、レシーバーの存在と、どのグループに関心があるかを認識させます。
When the Receiver-ETRs are several hops away from the receivers (e.g., Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join messages, which will allow the Receiver-ETR to know that there are multicast receivers at the site and also to learn which multicast group the receivers are for.
レシーバーETRがレシーバーから数ホップ離れている場合（たとえば、図1のレシーバーサイト2）、レシーバーETRはPIM加入メッセージを受信します。これにより、レシーバーETRはマルチキャストレシーバーがサイトと、受信者がどのマルチキャストグループ用であるかを学習します。
Once the Receiver-ETRs detect the presence of receivers at the receiver site, the Receiver-ETRs MUST issue Map-Register messages to include the Receiver-ETR RLOCs in the replication list for the multicast entry the receivers joined.
レシーバーETRがレシーバーサイトでレシーバーの存在を検出すると、レシーバーETRはMap-Registerメッセージを発行して、レシーバーが参加したマルチキャストエントリのレプリケーションリストにレシーバーETR RLOCを含める必要があります。
The Map-Register message MUST use the multicast entry (Source, Group) tuple as its Endpoint ID (EID) record type with the Receiver-ETR RLOCs conforming the locator set.
Map-Registerメッセージは、ロケーターセットに準拠するReceiver-ETR RLOCを持つエンドポイントID（EID）レコードタイプとしてマルチキャストエントリ（Source、Group）タプルを使用する必要があります。
The EID in the Map-Register message MUST be encoded using the Multicast Info LCAF Type defined in [RFC8060].
Map-RegisterメッセージのEIDは、[RFC8060]で定義されているMulticast Info LCAF Typeを使用してエンコードする必要があります。
The RLOC in the Map-Register message MUST be encoded using the RLE LCAF Type defined in [RFC8060] with the Level Value fields for all entries set to 128 (decimal).
Map-RegisterメッセージのRLOCは、[RFC8060]で定義されたRLE LCAFタイプを使用して、すべてのエントリのレベル値フィールドを128（10進数）に設定してエンコードする必要があります。
The encoding described above MUST be used consistently for Map-Register messages, entries in the mapping system, Map-Reply messages, as well as the map-cache at the Source-ITRs.
上記のエンコーディングは、Map-Registerメッセージ、マッピングシステムのエントリ、Map-Replyメッセージ、およびSource-ITRのマップキャッシュに一貫して使用する必要があります。
The Map-Register messages [RFC6830] sent by the Receiver-ETRs MUST have the following bits set as specified here:
Receiver-ETRによって送信されるMap-Registerメッセージ[RFC6830]には、ここで指定されている次のビットが設定されている必要があります。
1. merge-request bit set to 1. The Map-Register messages are sent with "Merge Semantics". The Map-Server will receive registrations from a multitude of Receiver-ETRs. The Map-Server will merge the registrations for common EIDs and maintain a consolidated replication list for each multicast entry.
1. merge-requestビットを1に設定します。Map-Registerメッセージは「Merge Semantics」で送信されます。 Map-Serverは、多数のReceiver-ETRから登録を受け取ります。 Map-Serverは、一般的なEIDの登録をマージし、各マルチキャストエントリの統合レプリケーションリストを維持します。
2. want-map-notify bit (M) set to 0. This tells the mapping system that the Receiver-ETR does not expect to receive Map-Notify messages as it does not need to be notified of all changes to the replication list.
2. want-map-notifyビット（M）は0に設定されます。これは、Replication-Listに対するすべての変更を通知する必要がないため、Receiver-ETRがMap-Notifyメッセージを受信することを期待しないことをマッピングシステムに通知します。
3. proxy-reply bit (P) set to 1. The merged replication list is kept in the Map-Servers. By setting the proxy-reply bit, the Receiver-ETRs instruct the mapping system to proxy reply to Map-Requests issued for the multicast entries.
3. プロキシー応答ビット（P）が1に設定されています。マージされた複製リストは、マップサーバーに保持されます。プロキシ応答ビットを設定することにより、Receiver-ETRはマッピングシステムに、マルチキャストエントリに対して発行されたMap-Requestへのプロキシ応答を指示します。
Map-Register messages for a particular multicast entry MAY be sent for every receiver detected, even if previous receivers have been detected for the particular multicast entry. This allows the replication list to remain up to date.
特定のマルチキャストエントリの以前の受信者が検出されていたとしても、特定のマルチキャストエントリのMap-Registerメッセージは、検出されたすべての受信者に送信される場合があります。これにより、レプリケーションリストを最新の状態に保つことができます。
Receiver-ETRs MUST be configured to know what Map-Servers Map-Register messages are sent to. The configuration is likely to be associated with an S-prefix that multiple (S,G) entries match to and are more specific for. Therefore, the S-prefix determines the Map-Server set in the least number of configuration statements.
受信者ETRは、Map-Servers Map-Registerメッセージの送信先を認識するように構成する必要があります。構成は、複数の（S、G）エントリが一致し、より具体的なSプレフィックスに関連付けられている可能性があります。したがって、Sプレフィックスは、最小数の構成ステートメントで設定されるMap-Serverセットを決定します。
The Map-Server will receive registrations from a multitude of Receiver-ETRs. The Map-Server will merge the registrations for common EIDs and consolidate a replication list for each multicast entry.
Map-Serverは、多数のReceiver-ETRから登録を受け取ります。 Map-Serverは、一般的なEIDの登録をマージし、各マルチキャストエントリのレプリケーションリストを統合します。
When an ETR sends an RLE RLOC-record in a Map-Register and the RLE already exists in the Map-Server's RLE-merged list, the Map-Server will replace the single RLE with the information from the Map-Register RLOC-record. The Map-Server MUST NOT merge duplicate RLOCs in the consolidated replication list.
ETRがMap-RegisterでRLE RLOCレコードを送信し、RLEがMap-ServerのRLE-mergedリストにすでに存在する場合、Map-Serverは単一のRLEをMap-Register RLOC-recordからの情報で置き換えます。 Map-Serverは、統合レプリケーションリスト内の重複するRLOCをマージしてはなりません（MUST NOT）。
Source-ITRs MUST register the unicast EIDs of any sources or Rendezvous Points that may be present on the source site. In other words, it is assumed that the sources and RPs are LISP EIDs.
ソースITRは、ソースサイトに存在する可能性のあるすべてのソースまたはランデブーポイントのユニキャストEIDを登録する必要があります。つまり、送信元とRPはLISP EIDであると想定されています。
The registration of the unicast EIDs for the sources or Rendezvous Points allows the Map-Server to know where to send Map-Notify messages to. Therefore, the Source-ITR MUST register the unicast S-prefix EID with the want-map-notify bit set in order to receive Map-Notify messages whenever there is a change in the replication list.
ソースまたはランデブーポイントのユニキャストEIDを登録すると、Map-ServerはMap-Notifyメッセージの送信先を知ることができます。したがって、レプリケーションリストに変更がある場合は常にMap-Notifyメッセージを受信するために、Source-ITRは、ユニキャストSプレフィックスEIDをwant-map-notifyビットセットに登録する必要があります。
When the source site receives the Map-Notify messages from the mapping system as described in Section 5.3, it will initiate the process of building a multicast distribution tree that will allow the multicast packets from the source to reach the Source-ITR.
ソースサイトは、セクション5.3で説明されているようにマッピングシステムからMap-Notifyメッセージを受信すると、ソースからのマルチキャストパケットがSource-ITRに到達できるようにするマルチキャスト配信ツリーを構築するプロセスを開始します。
The Source-ITR MUST issue a PIM join for the multicast entry for which it received the Map-Notify message. The join will be issued in the direction of the source or in the direction of the RP for the SSM and ASM cases, respectively.
Source-ITRは、Map-Notifyメッセージを受信したマルチキャストエントリに対してPIM加入を発行する必要があります。結合は、SSMおよびASMの場合、それぞれソースの方向またはRPの方向で発行されます。
On reception of multicast packets, the Source-ITR obtains the replication list for the (S,G) addresses in the packets.
マルチキャストパケットを受信すると、Source-ITRはパケット内の（S、G）アドレスの複製リストを取得します。
In order to obtain the replication list, the Source-ITR MUST issue a Map-Request message in which the EID is the (S,G) multicast tuple, which is encoded using the Multicast Info LCAF Type defined in [RFC8060].
レプリケーションリストを取得するために、Source-ITRはEIDが（S、G）マルチキャストタプルであるMap-Requestメッセージを発行する必要があります。これは、[RFC8060]で定義されているMulticast Info LCAF Typeを使用してエンコードされます。
The mapping system (most likely the Map-Server) will Map-Reply with the merged replication list maintained in the mapping system. The Map-Reply message MUST follow the format defined in [RFC6830]; its EID is encoded using the Multicast Info LCAF Type, and the corresponding RLOC-records are encoded using the RLE LCAF Type. Both LCAF Types are defined in [RFC8060].
マッピングシステム（ほとんどの場合Map-Server）は、マッピングシステムで維持されるマージされた複製リストを使用してMap-Replyを行います。 Map-Replyメッセージは、[RFC6830]で定義されたフォーマットに従う必要があります。そのEIDはMulticast Info LCAF Typeを使用してエンコードされ、対応するRLOCレコードはRLE LCAF Typeを使用してエンコードされます。どちらのLCAFタイプも[RFC8060]で定義されています。
The Map-Server will issue LISP Map-Notify messages to inform the source site of the presence of receivers for a particular multicast group over the overlay.
Map-ServerはLISP Map-Notifyメッセージを発行して、オーバーレイ上の特定のマルチキャストグループの受信者の存在をソースサイトに通知します。
Updated Map-Notify messages SHOULD be issued every time a new registration is received from a receiver site. This guarantees that the source sites are aware of any potential changes in the multicast-distribution-list membership.
更新されたMap-Notifyメッセージは、受信者サイトから新しい登録が受信されるたびに発行される必要があります。これにより、ソースサイトがマルチキャスト配布リストメンバーシップの潜在的な変更を認識できることが保証されます。
The Map-Notify messages carry (S,G) multicast EIDs encoded using the Multicast Info LCAF Type defined in [RFC8060].
Map-Notifyメッセージは、[RFC8060]で定義されているMulticast Info LCAF Typeを使用してエンコードされた（S、G）マルチキャストEIDを伝送します。
Map-Notify messages will be sent by the Map-Server to the RLOCs with which the unicast S-prefix EID was registered. In the case when sources are discovered dynamically [LISP-EID-MOBILITY], xTRs MUST register sources explicitly with the want-map-notify bit set. This is so the ITR in the site the source has moved to can get the most current replication list.
Map-Notifyメッセージは、Map-Serverによって、ユニキャストSプレフィックスEIDが登録されたRLOCに送信されます。ソースが動的に検出される場合[LISP-EID-MOBILITY]、xTRは、want-map-notifyビットセットでソースを明示的に登録する必要があります。これは、ソースが移動したサイトのITRが最新のレプリケーションリストを取得できるようにするためです。
When both the receiver sites and the source sites register to the same Map-Server, the Map-Server has all the necessary information to send the Map-Notify messages to the source site.
レシーバーサイトとソースサイトの両方が同じMap-Serverに登録されている場合、Map-ServerはMap-Notifyメッセージをソースサイトに送信するために必要なすべての情報を持っています。
When the Map-Servers are distributed (when using LISP-DDT [RFC8111]), the receiver sites MAY register to one Map-Server while the source site registers to a different Map-Server. In this scenario, the Map-Server for the receiver sites MUST resolve the unicast S-prefix EID across a distributed mapping transport system, per standard LISP lookup procedures, and obtain the necessary information to send the Map-Notify messages to the source site. The Map-Notify messages are sent with an authentication length of 0 as they would not be authenticated.
Map-Serverが分散されている場合（LISP-DDT [RFC8111]を使用している場合）、受信側サイトは1つのMap-Serverに登録できますが、ソースサイトは別のMap-Serverに登録できます。このシナリオでは、受信サイトのMap-Serverは、標準のLISPルックアップ手順に従って、分散マッピングトランスポートシステム全体でユニキャストSプレフィックスEIDを解決し、Map-Notifyメッセージをソースサイトに送信するために必要な情報を取得する必要があります。 Map-Notifyメッセージは認証されないため、認証の長さが0で送信されます。
When the Map-Servers are distributed, different receiver sites MAY register to different Map-Servers. However, this is not supported with the currently defined mechanisms.
Map-Serverが分散されている場合、異なるレシーバーサイトが異なるMap-Serverに登録される場合があります。ただし、これは現在定義されているメカニズムではサポートされていません。
The interconnection of SSM trees across sites will follow the general receiver-site procedures described in Section 5.1 on the receiver sites.
サイト間のSSMツリーの相互接続は、レシーバーサイトのセクション5.1で説明されている一般的なレシーバーサイト手順に従います。
The source-site procedures will vary depending on the topological location of the source within the source site as described in Sections 6.1 and 6.2 .
ソースサイトの手順は、セクション6.1および6.2で説明されているように、ソースサイト内のソースのトポロジ上の場所によって異なります。
When the source is directly connected to the Source-ITR, it is not necessary to trigger signaling to build a local multicast tree at the source site. Therefore Map-Notify messages are not required to initiate building of the multicast tree at the source site.
ソースがSource-ITRに直接接続されている場合、ソースサイトでローカルマルチキャストツリーを構築するためにシグナリングをトリガーする必要はありません。したがって、ソースサイトでマルチキャストツリーの構築を開始するためにMap-Notifyメッセージは必要ありません。
Map-Notify messages are still required to ensure that any changes to the replication list are communicated to the source site so that the map-cache at the Source-ITRs is kept updated.
Source-ITRのマップキャッシュが更新され続けるように、レプリケーションリストへの変更がソースサイトに確実に伝達されるようにするには、Map-Notifyメッセージが引き続き必要です。
The general LISP notification procedures described in Section 5.3 MUST be followed when the source is not directly connected to the Source-ITR. On reception of Map-Notify messages, local multicast signaling MUST be initiated at the source site per the general source-site procedures for multicast tree building described in Section 5.2.1.
ソースがSource-ITRに直接接続されていない場合は、セクション5.3で説明されている一般的なLISP通知手順に従う必要があります。 Map-Notifyメッセージを受信すると、ローカルマルチキャストシグナリングは、セクション5.2.1で説明されているマルチキャストツリー構築の一般的なソースサイト手順に従って、ソースサイトで開始する必要があります。
In the SSM case, the IP address of the source is known, and it is also registered with the LISP mapping system. Thus, the mapping system MAY resolve the mapping for the source address in order to send Map-Notify messages to the correct Source-ITR.
SSMの場合、送信元のIPアドレスは既知であり、LISPマッピングシステムにも登録されています。したがって、マッピングシステムは、Map-Notifyメッセージを正しいSource-ITRに送信するために、ソースアドレスのマッピングを解決できます（MAY）。
When multiple ITRs exist at a source multicast site, care MUST be taken that more than one ITR does not head-end replicate packets; otherwise, receiver multicast sites will receive duplicate packets. The following procedures will be used for each topology scenario:
ソースマルチキャストサイトに複数のITRが存在する場合、複数のITRがパケットをヘッドエンドで複製しないように注意する必要があります。そうでない場合、受信側マルチキャストサイトは重複したパケットを受信します。次の手順は、トポロジシナリオごとに使用されます。
o When more than one ITR is directly connected to the source host, either the PIM DR or the IGMP querier (when PIM is not enabled on the ITRs) is responsible for packet replication. All other ITRs silently drop the packet. In the IGMP querier case, one or more ITRs on the source LAN MUST be IGMP querier candidates. Therefore, it is required that they be configured as such.
o 複数のITRが送信元ホストに直接接続されている場合、PIM DRまたはIGMPクエリア（ITRでPIMが有効になっていない場合）がパケット複製を担当します。他のすべてのITRは静かにパケットをドロップします。 IGMPクエリアの場合、ソースLAN上の1つ以上のITRがIGMPクエリア候補である必要があります。したがって、それらをそのように構成する必要があります。
o When more than one ITR is multiple hops away from the source host and one of the ITRs is the PIM Rendezvous Point, then the PIM RP is responsible for packet replication.
o 複数のITRが送信元ホストから複数ホップ離れており、ITRの1つがPIMランデブーポイントである場合、PIM RPがパケット複製を担当します。
o When more than one ITR is multiple hops away from the source host and the PIM Rendezvous Point is not one of the ITRs, then one of the ITRs MUST join to the RP. When a Map-Notify is received from the Map-Server by an ITR, only the highest RLOC addressed ITR will join toward the PIM RP or toward the source.
o 複数のITRが送信元ホストから複数ホップ離れていて、PIMランデブーポイントがITRの1つではない場合、ITRの1つがRPに参加する必要があります。 ITRがMap-ServerからMap-Notifyを受信すると、最も高いRLOCアドレスのITRのみがPIM RPまたは送信元に参加します。
When multiple ETRs exist in a receiver multicast site and each one creates a multicast join state, each Map-Registers its RLOC address to the mapping system. In this scenario, the replication happens on the overlay causing multiple ETR entry points to replicate to all receivers instead of a single ETR entry point replicating to all receivers. If an ETR does not create join state, because it has not received PIM joins or IGMP reports, it will not Map-Register its RLOC addresses to the mapping system. The same procedures in Section 5.1 are followed.
レシーバーマルチキャストサイトに複数のETRが存在し、それぞれがマルチキャスト参加状態を作成する場合、各Map-RegisterはそのRLOCアドレスをマッピングシステムに登録します。このシナリオでは、複製がオーバーレイで発生し、単一のETRエントリーポイントがすべてのレシーバーに複製されるのではなく、複数のETRエントリーポイントがすべてのレシーバーに複製されます。 ETRが結合状態を作成しない場合、ETRはPIM結合またはIGMPレポートを受信していないため、RLOCアドレスをマッピングシステムにマップ登録しません。セクション5.1と同じ手順に従います。
When multiple ETRs exist on the same LAN as a receiver host, then the PIM DR (when PIM is enabled) or the IGMP querier is responsible for sending a Map-Register for its RLOC. In the IGMP case, one or more ETRs on a LAN MUST be IGMP querier candidates. Therefore, it is required that they are configured as such.
レシーバーホストと同じLANに複数のETRが存在する場合、PIM DR（PIMが有効な場合）またはIGMPクエリアは、そのRLOCのMap-Registerを送信します。 IGMPの場合、LAN上の1つ以上のETRがIGMPクエリア候補である必要があります。したがって、そのように構成する必要があります。
It MAY be desirable to have multiple underlay paths to an ETR for multicast packet delivery. This can be done by having multiple RLOCs assigned to an ETR and having the ETR send Map-Registers for all its RLOCs. By doing this, an ITR can choose a specific path based on underlay performance and/or RLOC reachability.
マルチキャストパケット配信のために、ETRへの複数のアンダーレイパスがあることが望ましい場合があります。これは、ETRに複数のRLOCを割り当て、ETRにそのすべてのRLOCのMap-Registerを送信させることで実行できます。これにより、ITRはアンダーレイのパフォーマンスやRLOCの到達可能性に基づいて特定のパスを選択できます。
It is recommended that an ETR send a Map-Register with a single RLOC-record that uses the Explicit Locator Path (ELP) LCAF Type [RFC8060] that is nested inside the RLE LCAF. For example, say ETR1 has assigned RLOC1 and RLOC2 for a LISP receiver site. Also, there is ETR2 in another LISP receiver site that has RLOC3. The two receiver sites have the same (S,G) being joined. Here is how the RLOC-record is encoded on each ETR:
ELEは、RLE LCAF内にネストされている明示的ロケーターパス（ELP）LCAFタイプ[RFC8060]を使用する単一のRLOCレコードでMap-Registerを送信することをお勧めします。たとえば、ETR1がLISPレシーバーサイトにRLOC1とRLOC2を割り当てたとします。また、RLOC3を持つ別のLISPレシーバーサイトにはETR2があります。 2つの受信側サイトが同じ（S、G）に参加しています。次に、RLOCレコードが各ETRでどのようにエンコードされるかを示します。
ETR1: EID-record: (S,G)
RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
ETR2: EID-record: (S,G) RLOC-record: RLE[ RLOC3 ]
ETR2：EIDレコード：（S、G）RLOCレコード：RLE [RLOC3]
And here is how the entry is merged and stored on the Map-Server since the Map-Registers have an RLE-encoded RLOC-record:
また、Map-RegisterにはRLEエンコードされたRLOCレコードがあるため、エントリがどのようにマージされてMap-Serverに格納されるかを次に示します。
MS: EID-record: (S,G)
RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
When the ITR receives a packet from a multicast source S for group G, it uses the merged RLOC-record returned from the Map-Server. The ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). Since it is required for the s-bit to be set for RLOC1, the ITR MUST replicate to RLOC1 if it is reachable. When the required p-bit is also set, the RLOC-reachability mechanisms from [RFC6830] are followed. If the ITR determines that RLOC1 is unreachable, it uses RLOC2, as long as RLOC2 is reachable.
ITRはグループGのマルチキャストソースSからパケットを受信すると、Map-Serverから返されたマージ済みRLOCレコードを使用します。 ITRはパケットを（RLOC3およびRLOC1）または（RLOC3およびRLOC2）に複製します。 RLOC1にsビットを設定する必要があるため、到達可能な場合、ITRはRLOC1に複製する必要があります。必要なpビットも設定されている場合、[RFC6830]のRLOC到達可能性メカニズムに従います。 ITRは、RLOC1に到達できないと判断した場合、RLOC2に到達できる限り、RLOC2を使用します。
This specification is focused on underlays without multicast support, but it does not preclude the use of multicast RLOCs in RLEs. ETRs MAY register multicast EID entries using multicast RLOCs. In such cases, the ETRs will be joined to underlay multicast distribution trees by using IGMP as a multicast host using mechanisms in [RFC2236] and [RFC3376].
この仕様は、マルチキャストサポートのないアンダーレイに焦点を当てていますが、RLEでのマルチキャストRLOCの使用を排除するものではありません。 ETRは、マルチキャストRLOCを使用してマルチキャストEIDエントリを登録できます（MAY）。このような場合、ETRは、[RFC2236]および[RFC3376]のメカニズムを使用してマルチキャストホストとしてIGMPを使用することにより、アンダーレイマルチキャスト配布ツリーに参加します。
LISP signal-free multicast can support ASM trees in limited but acceptable topologies. It is suggested, for the simplification of building ASM trees across the LISP overlay, to have PIM-ASM run independently in each LISP site. What this means is that a PIM RP is configured in each LISP site so PIM Register procedures and (*,G) state maintenance is contained within the LISP site.
LISPシグナルフリーマルチキャストは、限られた許容可能なトポロジでASMツリーをサポートできます。 LISPオーバーレイ全体でASMツリーを簡単に構築するために、PIM-ASMを各LISPサイトで個別に実行することをお勧めします。これは、PIM RPが各LISPサイトで構成されているため、PIM登録手順と（*、G）状態のメンテナンスがLISPサイト内に含まれていることを意味します。
The following procedure will be used to support ASM in each LISP site:
次の手順は、各LISPサイトでASMをサポートするために使用されます。
1. In a receiver site, the RP is co-located with the ETR. RPs for different groups can be spread across each ETR, but is not required.
1. レシーバーサイトでは、RPはETRと同じ場所に配置されます。異なるグループのRPは各ETRに分散できますが、必須ではありません。
2. When (*,G) state is created in an ETR, the procedures in Section 5.1.2 are followed. In addition, the ETR registers (S-prefix,G), where S-prefix is 0/0 (the respective unicast default route for the address-family) to the mapping system.
2. （*、G）状態がETRで作成されると、セクション5.1.2の手順に従います。さらに、ETRレジスター（S-prefix、G）です。S-prefixは0/0（アドレスファミリのそれぞれのユニキャストデフォルトルート）であり、マッピングシステムに送信されます。
3. In a source site, the RP is co-located with the ITR. RPs for different groups can be spread across each ITR, but is not required.
3. ソースサイトでは、RPはITRと同じ場所に配置されます。異なるグループのRPは各ITRに分散できますが、必須ではありません。
4. When a multicast source sends a packet, a PIM Register message is delivered to the ITR, and the procedures in Section 5.2 are followed.
4. マルチキャストソースがパケットを送信すると、PIM RegisterメッセージがITRに配信され、セクション5.2の手順に従います。
5. When the ITR sends a Map-Request for (S,G) and no receiver site has registered for (S,G), the mapping system will return the (0/0,G) entry to the ITR so it has a replication list of all the ETRs that have received (*,G) state.
5. ITRが（S、G）のMap-Requestを送信し、（S、G）に登録されている受信側サイトがない場合、マッピングシステムは（0/0、G）エントリをITRに返すため、レプリケーションリストが作成されます（*、G）状態を受け取ったすべてのETRの。
6. The ITR stores the replication list in its map-cache for (S,G). It replicates packets to all ETRs in the list.
6. ITRは、（S、G）のマップキャッシュにレプリケーションリストを格納します。リスト内のすべてのETRにパケットを複製します。
7. ETRs decapsulate packets and forward based on (*,G) state in their site.
7. ETRはパケットをカプセル化解除し、サイトの（*、G）状態に基づいて転送します。
8. When last-hop PIM routers join the newly discovered (S,G), the ETR will store the state and follow the procedures in Section 5.1.2.
8. ラストホップPIMルーターが新しく検出された（S、G）に参加すると、ETRは状態を保存し、セクション5.1.2の手順に従います。
The mechanisms in this specification can be applied to the "LISP Replication Engineering" [LISP-RE] design. Rather than have the layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can register their availability for multicast tree replication via the mapping database system.
この仕様のメカニズムは、「LISPレプリケーションエンジニアリング」[LISP-RE]設計に適用できます。レイヤ化されたLISP-RE RTR階層でシグナリングメカニズムを使用するのではなく、RTRは、マッピングデータベースシステムを介してマルチキャストツリーレプリケーションの可用性を登録できます。
As stated in [LISP-RE], the RTR-layered hierarchy is used to avoid head-end replication in replicating nodes closest to a multicast source. Rather than have multicast ITRs replicate to each ETR in an RLE of an (S,G) mapping database entry, it could replicate to one or more layer 0 RTRs in the LISP-RE hierarchy.
[LISP-RE]で述べたように、RTR階層化階層は、マルチキャストソースに最も近いノードを複製する際のヘッドエンドレプリケーションを回避するために使用されます。 （S、G）マッピングデータベースエントリのRLE内の各ETRにマルチキャストITRを複製するのではなく、LISP-RE階層内の1つ以上のレイヤー0 RTRに複製することができます。
This document specifies how the RTR hierarchy is determined but not the optimal layers of RTRs to be used. Methods for determining optimal paths or RTR topological closeness are out of scope for this document.
このドキュメントでは、RTR階層がどのように決定されるかを指定しますが、使用するRTRの最適なレイヤーは指定しません。最適なパスまたはRTRトポロジーの近さを決定する方法は、このドキュメントの範囲外です。
There are two formats an (S,G) mapping database entry could have. One format is a 'complete-format', and the other is a 'filtered-format'. A 'complete-format' entails an (S,G) entry having multiple RLOC-records that contain both ETRs that have registered as well as the RTRs at the first level of the LISP-RE hierarchy for the ITR to replicate to. When using 'complete-format', the ITR has the ability to select if it replicates to RTRs or to the registered ETRs at the receiver sites. A 'filtered-format' (S,G) entry is one where the Map-Server returns the RLOC-records that it decides the ITR SHOULD use. So replication policy is shifted from the ITRs to the mapping system. The Map-Servers can also decide for a given ITR if it uses a different set of replication targets per (S,G) entry for which the ITR is replicating for.
（S、G）マッピングデータベースエントリには2つの形式があります。 1つの形式は「完全な形式」で、もう1つの形式は「フィルターされた形式」です。 「完全フォーマット」には、登録されているETRと、ITRが複製するLISP-RE階層の最初のレベルのRTRの両方を含む複数のRLOCレコードを持つ（S、G）エントリが必要です。 「完全フォーマット」を使用する場合、ITRは、RTRに複製するか、レシーバーサイトで登録されたETRに複製するかを選択できます。 'filtered-format'（S、G）エントリは、Map-ServerがITR SHOULDが使用すると決定したRLOCレコードを返すエントリです。したがって、レプリケーションポリシーはITRからマッピングシステムに移行されます。 Map-Serverは、ITRがレプリケートする（S、G）エントリごとに異なるレプリケーションターゲットのセットを使用する場合、特定のITRを決定することもできます。
The procedure for the LISP-RE RTRs to make themselves available for replication can occur before or after any receivers join an (S,G) entry or any sources send for a particular (S,G) entry. Therefore, newly configured RTR state will be used to create new (S,G) state and will be inherited into existing (S,G) state. A set of RTRs can register themselves to the mapping system or a third party can do so on their behalf. When RTR registration occurs, it is done with an (S-prefix, G-prefix) entry so it can advertise its replication services for a wide range of source/group combinations.
LISP-RE RTRが複製に使用できるようにする手順は、受信者が（S、G）エントリに参加する前、または特定の（S、G）エントリに送信元が送信する前または後に実行できます。したがって、新しく構成されたRTR状態は、新しい（S、G）状態を作成するために使用され、既存の（S、G）状態に継承されます。 RTRのセットは、それ自体をマッピングシステムに登録するか、サードパーティが代わりに登録できます。 RTR登録が発生すると、（Sプレフィックス、Gプレフィックス）エントリを使用して行われるため、さまざまなソース/グループの組み合わせのレプリケーションサービスをアドバタイズできます。
When a Map-Server receives (S,G) registrations from ETRs and (S-prefix, G-prefix) registrations from RTRs, it has the option of merging the RTR RLOC-records for each (S,G) that is more specific for the (S-prefix, G-prefix) entry or keeping them separate. When merging, a Map-Server is ready to return a 'complete-format' Map- Reply. When keeping the entries separate, the Map-Server can decide what to include in a Map-Reply when a Map-Request is received. It can include a combination of RLOC-records from each entry or decide to use one or the other depending on policy configured.
Map-Serverは、ETRから（S、G）登録を受け取り、RTRから（S-prefix、G-prefix）登録を受け取ると、より具体的な（S、G）ごとにRTR RLOCレコードをマージするオプションがあります。 （Sプレフィックス、Gプレフィックス）エントリの場合、またはそれらを別々に保つ場合。マージすると、Map-Serverは「完全な形式」のMap-Replyを返す準備が整います。エントリを個別に保持する場合、Map-Serverは、Map-Requestを受信したときに、Map-Replyに何を含めるかを決定できます。各エントリからのRLOCレコードの組み合わせを含めることも、構成されたポリシーに応じてどちらか一方を使用することを決定することもできます。
+---+ +----+
Src-1 --------------|ITR| |ETR1|--------------- Rcv-1
+---+ +----+
\ /
Source-site-1 \ / Receiver-site-1
\ /
\ /
+----+ \ / +----+
|RTR1| \ / |RTR2| Level-0
+----+ \ / +----+
\ <^^^^^^^^^^^^^^> /
\ < > /
< Core Network >
< >
<vvvvvvvvvvvvvv>
/ / \ \
/ / \ \
+----+ / / \ \ +----+
|RTR3| / \ |RTR4| Level-1
+----+ / \ +----+
/ \
/ \
+----+ +----+
Rcv-2 --------------|ETR2| |ETR3|--------------- Rcv-3
+----+ +----+
Receiver-site-2 Receiver-site-3
レシーバーサイト2レシーバーサイト3
Figure 2: LISP-RE Reference Model
図2：LISP-RE参照モデル
Here is a specific example, illustrated in Figure 2, of (S,G) and (S-prefix, G-prefix) mapping database entries when a source S is behind an ITR, and there are receiver sites joined to (S,G) via ETR1, ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and RTR2 at level-0 and RTR3 and RTR4 at level-1:
（S、G）および（S-prefix、G-prefix）マッピングデータベースエントリの図2に示されている特定の例を次に示します。ソースSがITRの背後にあり、（S、G ）ETR1、ETR2、およびETR3経由。また、レベル0にはRTR1とRTR2、レベル1にはRTR3とRTR4のLISP-RE階層があります。
EID-record: (S,G)
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
EID-record: (S-prefix, G-prefix)
RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1
The above entries are in the form in which they were registered and are stored in a Map-Server. When a Map-Server uses 'complete-format', the Map-Reply it originates has the mapping record encoded as:
上記のエントリは、登録された形式であり、Map-Serverに保存されます。 Map-Serverが「complete-format」を使用する場合、それが生成するMap-Replyには、次のようにエンコードされたマッピングレコードがあります。
EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
The above Map-Reply allows the ITR to decide if it replicates to the ETRs or if it SHOULD replicate only to level-0 RTR1. This decision is left to the ITR since both RLOC-records have priority 1. If the Map-Server wanted to force the ITR to replicate to RTR1, it would set the ETRs RLOC-record to a priority greater than 1.
上記のMap-Replyにより、ITRはETRに複製するか、レベル0 RTR1にのみ複製する必要があるかを決定できます。 RLOCレコードは両方とも優先度1であるため、この決定はITRに委ねられます。Map-ServerがITRをRTR1に複製するように強制したい場合、ETRのRLOCレコードを1より大きい優先度に設定します。
When a Map_server uses 'filtered-format', the Map-Reply it originates has the mapping record encoded as:
Map_serverが 'filtered-format'を使用する場合、それが生成するMap-Replyは、次のようにエンコードされたマッピングレコードを持ちます。
EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
An (S,G) entry can contain alternate RTRs. So rather than replicating to multiple RTRs, one RTR set MAY be used based on the RTR reachability status. An ITR can test reachability status to any layer 0 RTR using RLOC-probing, so it can choose one RTR from a set to replicate to. When this is done, the RTRs are encoded in different RLOC-records instead of together in one RLE RLOC-record. This moves the replication load off the ITRs at the source site to the RTRs inside the network infrastructure. This mechanism can also be used by level-n RTRs to level-n+1 RTRs.
（S、G）エントリには、代替RTRを含めることができます。したがって、複数のRTRに複製するのではなく、RTR到達可能性ステータスに基づいて1つのRTRセットを使用できます。 ITRは、RLOCプローブを使用して任意のレイヤ0 RTRへの到達可能性ステータスをテストできるため、レプリケートするセットから1つのRTRを選択できます。これが行われると、RTRは1つのRLE RLOCレコードにまとめられるのではなく、異なるRLOCレコードにエンコードされます。これにより、複製負荷がソースサイトのITRからネットワークインフラストラクチャ内のRTRに移動します。このメカニズムは、レベルnのRTRからレベルn + 1のRTRにも使用できます。
The following mapping would be encoded in a Map-Reply sent by a Map-Server and stored in the ITR. The ITR would use RTR1 until it went unreachable and then switch to use RTR2:
次のマッピングは、Map-Serverによって送信されたMap-Replyでエンコードされ、ITRに格納されます。 ITRは、到達不能になるまでRTR1を使用してから、RTR2を使用するように切り替えます。
EID-record: (S,G) RLOC-record: RTR1, p1 RLOC-record: RTR2, p2
EIDレコード：（S、G）RLOCレコード：RTR1、p1 RLOCレコード：RTR2、p2
[LISP-SEC] defines a set of security mechanisms that provide origin authentication, integrity, and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-prefix claims in Map-Reply messages.
[LISP-SEC]は、マッピングルックアッププロセスを介して伝達されるLISPのEID-to-RLOCマッピングデータに発信元認証、整合性、およびアンチリプレイ保護を提供する一連のセキュリティメカニズムを定義します。 LISP-SECは、Map-Replyメッセージ内のEIDプレフィックス要求の承認の検証も可能にします。
Additional security mechanisms to protect the LISP Map-Register messages are defined in [RFC6833].
LISP Map-Registerメッセージを保護するための追加のセキュリティメカニズムは、[RFC6833]で定義されています。
The security of the mapping system infrastructure depends on the particular mapping database used. As an example, [RFC8111] defines a public-key-based mechanism that provides origin authentication and integrity protection to the LISP DDT protocol.
マッピングシステムインフラストラクチャのセキュリティは、使用される特定のマッピングデータベースによって異なります。例として、[RFC8111]は、LISP DDTプロトコルにオリジン認証と完全性保護を提供する公開鍵ベースのメカニズムを定義しています。
Map-Replies received by the Source-ITR can be signed (by the Map-Server), so the ITR knows the replication list is from a legitimate source.
Source-ITRによって受信されたMap-Repliesは（Map-Serverによって）署名できるため、ITRは複製リストが正当な送信元からのものであることを認識します。
Data-plane encryption can be used when doing unicast rep-encapsulation as described in [RFC8061].
[RFC8061]で説明されているように、ユニキャストrepカプセル化を行う場合、データプレーン暗号化を使用できます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、DOI 10.17487 / RFC2236、1997年11月、<https://www.rfc-editor.org/info/rfc2236>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< https://www.rfc-editor.org/info/rfc3376>。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <https://www.rfc-editor.org/info/rfc3569>.
[RFC3569] Bhattacharyya、S。、編、「An Source Overview of Source-Specific Multicast（SSM）」、RFC 3569、DOI 10.17487 / RFC3569、2003年7月、<https://www.rfc-editor.org/info/ rfc3569>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<https：/ /www.rfc-editor.org/info/rfc6830>。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「マルチキャスト環境のためのロケータ/ ID分離プロトコル（LISP）」、RFC 6831、DOI 10.17487 / RFC6831、2013年1月、< https://www.rfc-editor.org/info/rfc6831>。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <https://www.rfc-editor.org/info/rfc6833>.
[RFC6833] Fuller、V。およびD. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、RFC 6833、DOI 10.17487 / RFC6833、2013年1月、<https://www.rfc-editor.org / info / rfc6833>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「プロトコル独立マルチキャスト-スパースモード（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https://www.rfc-editor.org/info/rfc7761>。
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8060] Farinacci、D.、Meyer、D。、およびJ. Snijders、「LISP Canonical Address Format（LCAF）」、RFC 8060、DOI 10.17487 / RFC8060、2017年2月、<https：//www.rfc-editor。 org / info / rfc8060>。
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8111] Fuller、V.、Lewis、D.、Ermagan、V.、Jain、A。、およびA. Smirnov、「Locator / ID Separation Protocol Delegated Database Tree（LISP-DDT）」、RFC 8111、DOI 10.17487 / RFC8111、2017年5月、<https://www.rfc-editor.org/info/rfc8111>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[LISP-EID-MOBILITY] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, draft-ietf-lisp-eid-mobility-01, November 2017.
[LISP-EID-MOBILITY] Portoles-Comeras、M.、Ashtaputre、V.、Moreno、V.、Maino、F。、およびD. Farinacci、「統合コントロールプレーンを使用したLISP L2 / L3 EIDモビリティ」、進捗、draft-ietf-lisp-eid-mobility-01、2017年11月。
[LISP-MULTI-SIGNALING] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", Work in Progress, draft-farinacci-lisp-mr-signaling-06, February 2015.
[LISP-MULTI-SIGNALING] Farinacci、D.およびM. Napierala、「LISP Control-Plane Multicast Signaling」、Work in Progress、draft-farinacci-lisp-mr-signaling-06、2015年2月。
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015.
[LISP-RE] Coras、F.、Cabellos-Aparicio、A.、Domingo-Pascual、J.、Maino、F。、およびD. Farinacci、「LISP Replication Engineering」、Work in Progress、draft-coras-lisp- re-08、2015年11月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-15, April 2018.
[LISP-SEC] Maino、F.、Ermagan、V.、Cabellos-Aparicio、A。、およびD. Saucez、「LISP-Security（LISP-SEC）」、Work in Progress、draft-ietf-lisp-sec- 2018年4月15日。
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.
[RFC8061] Farinacci、D。およびB. Weis、「Locator / ID Separation Protocol（LISP）Data-Plane Confidentiality」、RFC 8061、DOI 10.17487 / RFC8061、2017年2月、<https://www.rfc-editor.org / info / rfc8061>。
Acknowledgements
謝辞
The authors want to thank Greg Shepherd, Joel Halpern, and Sharon Barkai for their insightful contribution to shaping the ideas in this document. A special thanks to Luigi Iannone, LISP WG co-chair, for shepherding this working group document. Thanks also goes to Jimmy Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for testing an implementation of this document.
このドキュメントのアイデアを形作るための洞察に満ちた貢献をしてくれたGreg Shepherd、Joel Halpern、Sharon Barkaiに感謝します。このワーキンググループの文書を作成してくれたLISP WG共同議長のLuigi Iannoneに特に感謝します。このドキュメントの実装をテストしてくれたJimmy Kyriannis、Paul Vinciguerra、Florin Coras、Yan Filyurinにも感謝します。
Authors' Addresses
著者のアドレス
Victor Moreno Cisco Systems 170 Tasman Drive San Jose, California 95134 United States of America
ビクターモレノシスコシステムズ170タスマンドライブサンノゼ、カリフォルニア95134アメリカ合衆国
Email: vimoreno@cisco.com
Dino Farinacci lispers.net San Jose, CA 95120 United States of America
Dino Farinacci lispers.net San Jose、CA 95120アメリカ合衆国
Email: farinacci@gmail.com