Internet Engineering Task Force (IETF) V. Moreno
Request for Comments: 8378 Cisco Systems
Category: Experimental D. Farinacci
ISSN: 2070-1721 lispers.net
May 2018
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.
当多播源和接收器在定位器/ID分离协议（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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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-SIGNING]中所述那样利用接收器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.
当源站点的入口隧道路由器（ITR）从其站点的源接收多播流量时，ITR可以通过发出针对所接收数据包中的（S，G）源地址和目的地址的映射请求消息来查询映射系统。映射系统将把RLOC复制列表返回到ITR，ITR将按照标准LISP过程对其进行缓存。由于假设核心不支持多播，ITR将为复制列表上的每个RLOC复制多播通信量，并将通信量单播封装到每个RLOC。在本文档中，将通信量复制和封装到复制列表中的RLOCs的组合功能称为“rep封装”。
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多播树的一般过程的含义。其中包含了关于任何源多播（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规范[RFC6830]中定义了与LISP相关的术语，尤其是映射请求、映射应答、入口隧道路由器（ITR）、出口隧道路由器（ETR）、映射服务器（MS）和映射解析器（MR）。
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:LISP在接收器站点解除对隧道路由器（xTR）的封装。这是一个多播ETR。
Source-ITR: LISP encapsulating xTR at the source site. This is a multicast ITR.
源ITR:LISP在源站点封装xTR。这是一个多播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封装：复制流量并将其封装到多个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级别以复制列表条目（RLE）LISP规范地址格式（LCAF）类型进行编码，详见[RFC8060]。复制列表中的每个条目都包含一个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:[RFC3569]中定义的任何源多播，其中多播分发树是通过集合点[RFC7761]构建的。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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
+---+ +---+
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表示直接连接到源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表示距离源ITR一跳或多跳的源（Src-1）。
Receiver-site-2 and -4 are receiver sites with not-directly connected and directly connected receiver endpoints, respectively.
Receiver-site-2和-4分别是未直接连接和直接连接接收器端点的接收器站点。
R1 is a multicast router in Source-site-1.
R1是源站点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).
地图服务器和地图解析器可在核心的RLOC空间中访问；图中仅显示了一个用于说明，但它们可以是分布式映射系统的许多部分，甚至是一部分，例如委托数据库树（DDT）。
The procedures for interconnecting multicast trees over an overlay can be broken down into three functional areas:
在覆盖上互连多播树的过程可分为三个功能区域：
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站点，如果在未来的LISP无信号多播规范中支持ASM树，则可能需要对源站点程序进行修改。
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消息必须发送到源ITR，通知复制列表中的任何更改。
5. Multicast tree building at the source site is initiated when the Source-ITR receives the LISP notification.
5. 当源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. 多播流量遵循在源站点构建的多播树，并到达源ITR。
3. The Source-ITR will issue a Map-Request to resolve the replication list for the multicast entry.
3. 源ITR将发出映射请求以解析多播条目的复制列表。
4. The mapping system responds to the Source-ITR with a Map-Reply containing the replication list for the multicast group requested.
4. 映射系统使用包含所请求的多播组的复制列表的映射回复来响应源ITR。
5. The Source-ITR caches the replication list received in the map-reply for the multicast entry.
5. 源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. 多播通信被重新封装。也就是说，为复制列表中的每个RLOC复制数据包，然后封装到每个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报告，让接收者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 join消息，这将允许接收器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.
映射寄存器消息必须使用多播条目（源、组）元组作为其端点ID（EID）记录类型，且接收方ETR RLOCs符合定位器集。
The EID in the Map-Register message MUST be encoded using the Multicast Info LCAF Type defined in [RFC8060].
映射寄存器消息中的EID必须使用[RFC8060]中定义的多播信息LCAF类型进行编码。
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).
映射寄存器消息中的RLOC必须使用[RFC8060]中定义的RLE LCAF类型进行编码，所有条目的级别值字段设置为128（十进制）。
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.
上述编码必须始终用于映射寄存器消息、映射系统中的条目、映射回复消息以及源ITR的映射缓存。
The Map-Register messages [RFC6830] sent by the Receiver-ETRs MUST have the following bits set as specified here:
接收器ETR发送的映射寄存器消息[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. 合并请求位设置为1。映射寄存器消息以“合并语义”发送。地图服务器将从多个接收器ETR接收注册。Map服务器将合并公共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. 要将映射通知位（M）设置为0。这会告诉映射系统，接收方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。合并的复制列表保存在映射服务器中。通过设置代理回复位，接收方ETRs指示映射系统代理回复为多播条目发出的映射请求。
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必须配置为知道将映射寄存器消息发送到哪些映射服务器。该配置可能与多个（S，G）条目匹配且更具体的S前缀相关联。因此，S前缀决定了在最少数量的配置语句中设置的映射服务器。
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.
地图服务器将从多个接收器ETR接收注册。Map服务器将合并公共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在映射寄存器中发送RLE RLOC记录，并且该RLE已存在于映射服务器的RLE合并列表中时，映射服务器将使用映射寄存器RLOC记录中的信息替换单个RLE。映射服务器不得合并合并的复制列表中的重复RLOC。
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服务器知道向何处发送Map Notify消息。因此，源ITR必须使用want map notify位集合注册单播S前缀EID，以便在复制列表发生更改时接收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消息时，它将启动构建多播分发树的过程，该多播分发树将允许来自源的多播数据包到达源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.
源ITR必须为收到Map Notify消息的多播条目发出PIM join。对于SSM和ASM情况，连接将分别沿震源方向或RP方向发出。
On reception of multicast packets, the Source-ITR obtains the replication list for the (S,G) addresses in the packets.
在接收多播数据包时，源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].
为了获得复制列表，源ITR必须发出映射请求消息，其中EID是（S，G）多播元组，该元组使用[RFC8060]中定义的多播信息LCAF类型进行编码。
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].
映射系统（很可能是映射服务器）将使用映射系统中维护的合并复制列表映射Reply。Map回复消息必须遵循[RFC6830]中定义的格式；其EID使用多播信息LCAF类型编码，相应的RLOC记录使用RLE LCAF类型编码。[RFC8060]中定义了两种LCAF类型。
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服务器将发出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.
每次从接收站点收到新注册时，都应发出更新的地图通知消息。这保证了源站点知道多播分发列表成员资格中的任何潜在更改。
The Map-Notify messages carry (S,G) multicast EIDs encoded using the Multicast Info LCAF Type defined in [RFC8060].
Map Notify消息使用[RFC8060]中定义的多播信息LCAF类型编码（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服务器发送到注册了单播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.
当接收站点和源站点都注册到同一映射服务器时，映射服务器具有将映射通知消息发送到源站点所需的所有信息。
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
当地图服务器是分布式的（使用LISP-DDT[RFC8111]时），接收站点可以注册到一个地图服务器，而源站点可以注册到另一个地图服务器。在这种情况下，接收方站点的映射服务器必须按照标准LISP查找过程，在分布式映射传输系统中解析单播S前缀EID，并获取发送请求所需的信息
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 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.
分布地图服务器时，不同的接收站点可能会注册到不同的地图服务器。但是，当前定义的机制不支持这一点。
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.
当源直接连接到源ITR时，无需触发信令以在源站点构建本地多播树。因此，在源站点上启动多播树的构建不需要映射通知消息。
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.
仍然需要Map Notify消息，以确保复制列表的任何更改都传送到源站点，从而使源ITRs处的Map缓存保持更新。
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.
当源未直接连接到源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映射系统中注册。因此，映射系统可以解析源地址的映射，以便向正确的源ITR发送映射通知消息。
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上的一个或多个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是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时，其中一个ITR必须加入RP。当ITR从Map服务器接收到Map通知时，只有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且每个ETR创建多播连接状态时，每个映射将其RLOC地址注册到映射系统。在此场景中，复制发生在覆盖上，导致多个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.
当多个ETR作为接收器主机存在于同一LAN上时，PIM DR（启用PIM时）或IGMP查询器负责为其RLOC发送映射寄存器。在IGMP情况下，LAN上的一个或多个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的参考底图路径。这可以通过将多个RLOC分配给ETR并为其所有RLOC设置ETR发送映射寄存器来实现。通过这样做，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:
建议ETR发送带有单个RLOC记录的映射寄存器，该记录使用嵌套在RLE LCAF中的显式定位器路径（ELP）LCAF类型[RFC8060]。例如，假设ETR1为LISP接收器站点分配了RLOC1和RLOC2。另外，在另一个具有RLOC3的LISP接收器站点中也有ETR2。两个接收器站点具有相同的（S，G）连接。以下是RLOC记录在每个ETR上的编码方式：
ETR1: EID-record: (S,G)
RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
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:
以下是如何合并条目并将其存储在地图服务器上，因为地图寄存器具有RLE编码的RLOC记录：
MS: EID-record: (S,G)
RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
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服务器返回的合并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条目。在这种情况下，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站点中独立运行PIM-ASM，以简化跨LISP覆盖构建ASM树的过程。这意味着在每个LISP站点中配置了PIM RP，因此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位于同一位置。不同组的RPs可以分布在每个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. 当在ETR中创建（*，G）状态时，应遵循第5.1.2节中的程序。此外，ETR向映射系统注册（S前缀，G），其中S前缀为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位于同一位置。不同组的RPs可以分布在每个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寄存器消息被传送到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请求且没有为（S，G）注册接收站点时，映射系统将向ITR返回（0/0，G）条目，以便其具有已接收（*，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. ETRs根据其站点中的（*，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分层层次结构用于在复制距离多播源最近的节点时避免前端复制。与其让多播ITR复制到（S，G）映射数据库条目的RLE中的每个ETR，不如复制到LISP-RE层次结构中的一个或多个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）映射数据库条目可能有两种格式。一种格式是“完整格式”，另一种是“过滤格式”。“完整格式”要求一个（S，G）条目具有多个RLOC记录，其中包含已注册的ETR以及ITR要复制到的LISP-RE层次结构第一级的RTR。使用“完整格式”时，ITR能够选择是复制到RTR还是复制到接收站点的已注册ETR。“过滤格式”（S，G）条目是映射服务器返回其决定ITR应使用的RLOC记录的条目。因此，复制策略从ITRs转移到映射系统。如果给定的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-prefix，G-prefix）条目来完成注册，这样它就可以为各种源/组组合发布其复制服务。
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-
当地图服务器从ETR接收（S，G）注册和从RTRs接收（S-prefix，G-prefix）注册时，它可以选择合并每个（S，G）的RTR RLOC记录，这些记录对于（S-prefix，G-prefix）条目更为具体，或者将它们分开。合并时，地图服务器准备返回“完整格式”地图-
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.
回复当将条目分开时，当接收到映射请求时，映射服务器可以决定在映射回复中包括什么。它可以包括来自每个条目的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
+----+ +----+
+---+ +----+
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
接收器-site-2接收器-site-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:
下面是一个具体示例，如图2所示，当源S位于ITR之后，并且存在通过ETR1、ETR2和ETR3连接到（S，G）的接收站点时，（S，G）和（S-前缀，G-前缀）映射数据库条目。0级存在RTR1和RTR2的LISP-RE层次结构，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
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:
上述条目以其注册的形式存储在地图服务器中。当地图服务器使用“完整格式”时，它发起的地图回复将地图记录编码为：
EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
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回复允许ITR决定是复制到ETR，还是只复制到0级RTR1。由于两个RLOC记录的优先级均为1，因此此决定由ITR决定。如果映射服务器想要强制ITR复制到RTR1，它会将ETRs RLOC记录的优先级设置为大于1。
When a Map_server uses 'filtered-format', the Map-Reply it originates has the mapping record encoded as:
当Map_服务器使用“过滤格式”时，它发起的Map应答将映射记录编码为：
EID-record: (S,G)
RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
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集，而不是复制到多个RTR。ITR可以使用RLOC探测测试任何层0 RTR的可达性状态，因此它可以从一组RTR中选择一个进行复制。完成此操作后，RTR编码在不同的RLOC记录中，而不是一起编码在一个RLE 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:
以下映射将被编码在映射服务器发送的映射应答中，并存储在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到RLOC映射数据提供源身份验证、完整性和反重放保护。LISP-SEC还支持验证映射回复消息中EID前缀声明的授权。
Additional security mechanisms to protect the LISP Map-Register messages are defined in [RFC6833].
[RFC6833]中定义了保护LISP映射寄存器消息的其他安全机制。
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.
源ITR收到的Map回复可以（由Map服务器）签名，因此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.，编辑，“源特定多播（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]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（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]Farinaci，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.Farinaci，“定位器/ID分离协议（LISP）地图服务器接口”，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]Farinaci，D.，Meyer，D.，和J.Snijders，“LISP规范地址格式（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，“定位器/身份分离协议委托数据库树（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.Farinaci，“使用统一控制平面的LISP L2/L3 EID移动”，正在进行的工作，草案-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]Farinaci，D.和M.Napierala，“LISP控制平面多播信令”，正在进行的工作，draft-Farinaci-LISP-mr-SIGNALING-062015年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.Farinaci，“LISP复制工程”，在建工程，草稿-Coras-LISP-RE-082015年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安全（LISP-SEC）”，正在进行的工作，草案-ietf-LISP-SEC-15，2018年4月。
[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]Farinaci，D.和B.Weis，“定位器/ID分离协议（LISP）数据平面机密性”，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工作组共同主席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
Victor Moreno Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道170号95134
Email: vimoreno@cisco.com
Email: vimoreno@cisco.com
Dino Farinacci lispers.net San Jose, CA 95120 United States of America
Dino Farinaci lispers.net加利福尼亚州圣何塞95120美利坚合众国
Email: farinacci@gmail.com
Email: farinacci@gmail.com