Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6831 D. Meyer
Category: Experimental J. Zwiebel
ISSN: 2070-1721 S. Venaas
Cisco Systems
January 2013
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6831 D. Meyer
Category: Experimental J. Zwiebel
ISSN: 2070-1721 S. Venaas
Cisco Systems
January 2013
The Locator/ID Separation Protocol (LISP) for Multicast Environments
用于多播环境的定位器/ID分离协议（LISP）
Abstract
摘要
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.
本文档描述了域间多播路由将如何在使用Locator/ID分离协议（LISP）体系结构部署Locator/ID分离的环境中工作。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6831.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6831.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Source Addresses versus Group Addresses . . . . . . . . . . . 10
6. Locator Reachability Implications on LISP-Multicast . . . . . 11
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 12
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 14
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 15
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 15
8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 15
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 16
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 17
9.1. LISP and Non-LISP Mixed Sites . . . . . . . . . . . . . . 17
9.1.1. LISP Source Site to Non-LISP Receiver Sites . . . . . 18
9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites . . . 20
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 20
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 21
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 21
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22
9.3. Making a Multicast Interworking Decision . . . . . . . . . 24
10. Considerations When RP Addresses Are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 25
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Source Addresses versus Group Addresses . . . . . . . . . . . 10
6. Locator Reachability Implications on LISP-Multicast . . . . . 11
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 12
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 14
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 15
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 15
8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 15
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 16
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 17
9.1. LISP and Non-LISP Mixed Sites . . . . . . . . . . . . . . 17
9.1.1. LISP Source Site to Non-LISP Receiver Sites . . . . . 18
9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites . . . 20
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 20
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 21
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 21
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22
9.3. Making a Multicast Interworking Decision . . . . . . . . . 24
10. Considerations When RP Addresses Are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 25
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 27
The Locator/ID Separation Protocol [RFC6830] architecture provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an Endpoint ID (EID) namespace used by sites and a Routing Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information.
Locator/ID分离协议[RFC6830]体系结构提供了一种机制，用于将标识和位置语义从当前的IP地址定义中分离出来。通过创建两个名称空间，站点使用的端点ID（EID）名称空间和核心路由使用的路由定位器（RLOC）名称空间，核心路由基础设施可以通过路由信息的拓扑聚合进行扩展。
Since LISP creates a new namespace, a mapping function must exist to map a site's EID-Prefixes to its associated Locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology dependent. Therefore, this specification focuses on mapping a source EID address of a multicast flow during distribution tree setup and packet delivery.
由于LISP创建了一个新的名称空间，因此必须存在一个映射函数来将站点的EID前缀映射到其关联的定位器。对于单播数据包，必须映射源地址和目标地址。对于多播数据包，只需要映射源地址。不需要映射目标组地址，因为IPv4或IPv6组地址的语义本质上是逻辑的，而不依赖于拓扑。因此，本规范侧重于在分发树设置和数据包交付期间映射多播流的源EID地址。
This specification will address the following scenarios:
本规范将解决以下情况：
1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled.
1. LISP站点中的多播源主机如何将多播数据包发送到其站点内的接收器以及其他启用LISP的站点中的接收器。
2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed.
2. 如何构建域间（或LISP站点之间）多播分发树，以及如何将多播数据包从源站点转发到接收方站点。
3. What protocols are affected and what changes are required to such multicast protocols.
3. 哪些协议受到影响，需要对这些多播协议进行哪些更改。
4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source Multicast), and Bidir-mode (Bidirectional Shared Trees) service models will operate.
4. ASM模式（任意源多播）、SSM模式（单源多播）和Bidir模式（双向共享树）服务模型将如何运行。
5. How multicast packet flow will occur for multiple combinations of LISP-enabled and non-LISP-enabled source and receiver sites. For example:
5. 对于启用LISP和未启用LISP的源站点和接收站点的多个组合，多播数据包流将如何发生。例如：
A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites.
A.当LISP站点中的源主机都是非LISP站点时，如何将来自LISP站点中的源主机的多播数据包发送到其他站点中的接收器。
B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites.
B.如何将LISP站点中源主机的多播数据包发送到启用LISP站点和非LISP站点中的接收器。
C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP-enabled sites.
C.当非LISP站点中的源主机都是启用LISP的站点时，如何将多播数据包发送到其他站点中的接收器。
D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites.
D.如何将来自非LISP站点中的源主机的多播数据包发送到启用LISP的站点和非LISP站点中的接收器。
This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multiprotocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no packet format changes to the protocols and no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged, regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites that are LISP enabled.
本规范着重于需要对多播路由协议进行哪些更改以支持LISP多播以及用于域间多播的其他协议，如多协议BGP（MBGP）[RFC4760]。本规范中提出的方法不需要对协议进行数据包格式更改，也不需要对站点内部的多播基础设施进行操作程序更改（当所有源和接收器都位于该站点时），即使该站点启用了LISP。也就是说，多播的内部操作是不变的，无论站点是否启用了LISP，或者其他启用了LISP的站点中是否存在接收器。
Therefore, we see only operational (and not protocol) changes for PIM-ASM [RFC4601], Multicast Source Discovery Protocol (MSDP) [RFC3618], and PIM-SSM [RFC4607]. BIDIR-PIM [RFC5015], which typically does not run in an inter-domain environment, is not addressed in depth in this RFC.
因此，我们只看到PIM-ASM[RFC4601]、多播源发现协议（MSDP）[RFC3618]和PIM-SSM[RFC4607]的操作（而不是协议）更改。BIDIR-PIM[RFC5015]通常不在域间环境中运行，本RFC中未对其进行深入讨论。
Also, the current version of this specification does not describe multicast-based Traffic Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in [RFC6830]. Further work is also needed to determine the detailed behavior for multicast Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6). Finally, further deployment and experimentation would be useful to understand the real-life performance of the LISP-Multicast solution. For instance, the design optimizes for minimal state and control traffic in the core, but can in some cases cause extra multicast traffic to be sent Section 8.1.2.
此外，本规范的当前版本没有描述与[RFC6830]中的TE-ITR（基于TE的入口隧道路由器）和TE-ETR（基于TE的出口隧道路由器）描述相关的基于多播的流量工程（TE）。还需要进一步的工作来确定多播代理ITR（MPITR）（第9.1.3节）、mtrace（第12节）和定位器可达性（第6节）的详细行为。最后，进一步的部署和实验将有助于了解LISP多播解决方案的实际性能。例如，该设计优化核心中的最小状态和控制流量，但在某些情况下会导致发送额外的多播流量（见第8.1.2节）。
Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830]. Section 12 of that document provides additional issues and concerns raised by this document.
[RFC6830]中讨论了有关为Internet流量部署LISP的问题和顾虑。该文件第12节提供了本文件提出的其他问题和关切。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terminology in this section is consistent with the definitions in [RFC6830] but is extended specifically to deal with the application of the terminology to multicast routing.
本节中的术语与[RFC6830]中的定义一致，但专门扩展以处理术语在多播路由中的应用。
LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture.
LISP多播：参考本规范中的设计。也就是说，当参与多播通信的任何站点升级为LISP站点时，控制平面和数据平面协议的操作被视为LISP多播体系结构的一部分。
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-Prefix block associated with the site in which the host is located. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider-Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system.
端点ID（EID）：在多播数据包的第一个（最内部）LISP头的源地址字段中使用的32位（对于IPv4）或128位（对于IPv6）值。主机获取目的地组地址的方式与今天获取目的地组地址的方式相同，就像它是非LISP站点时一样。源EID通过用于设置主机“本地”IP地址的现有机制获得。EID从与主机所在站点关联的EID前缀块分配给主机。当主机使用IGMP版本3[RFC4604]加入SSM（S-EID，G）路由时，EID可被主机用来引用另一台主机。LISP为EID使用独立于提供程序（PI）的块；此类EID不得用作LISP RLOC。注意，EID块可以独立于网络拓扑以分层方式分配，以便于映射数据库的缩放。此外，分配给站点的EID块可以具有用于在站点内路由的站点本地结构（子网）；此结构对全局路由系统不可见。
Routing Locator (RLOC): the IPv4 or IPv6 address of an Ingress Tunnel Router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site.
路由定位器（RLOC）：入口隧道路由器（ITR）的IPv4或IPv6地址，它是多播源主机站点中封装多播数据包的路由器。它是EID到RLOC映射查找的输出。EID映射到一个或多个RLOC。通常，RLOC从拓扑上可聚合的块中进行编号，这些块被分配到其连接到全球互联网的每个点处的站点；如果拓扑由提供商网络的连接性定义，则可以将RLOC视为提供商分配（PA）地址。可以将多个RLOC分配给同一个ITR设备或一个站点上的多个ITR设备。
Ingress Tunnel Router (ITR): a router that accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally routable RLOCs as the source address field. This RLOC is known to other multicast receiver
入口隧道路由器（ITR）：一种路由器，它接受带有单个IP报头的IP多播数据包（更准确地说，是不包含LISP报头的IP数据包）。路由器不透明地处理这个“内部”IP目的地多播地址，因此不需要对组地址执行映射查找，因为它在拓扑上不重要。然后，路由器在“外部”IP报头前加上一个全局可路由RLOC作为源地址字段。其他多播接收器已知此RLOC
sites that have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated multicast IP packets out all external interfaces that have been joined.
使用映射数据库加入以ITR为根的多播树的站点。通常，ITR从一端的站点端系统接收IP数据包，并将LISP封装的多播IP数据包发送到所有已加入的外部接口。
An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers.
当1）ITR位于从多播源到内部连接接收器的路径上，或2）ITR位于从多播源到外部连接接收器的路径上时，ITR将从其站点内部的源接收多播数据包。
Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site-internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/ Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers.
出口隧道路由器（ETR）：在从另一站点的多播源主机到其自身站点的多播接收器的路径上的路由器。ETR接受来自站点内部PIM路由器的PIM加入/删减消息，该路由器的目的地为多播源站点中源的EID。ETR根据EID到RLOC的映射，将加入/删除消息中的源EID映射到RLOC地址。这将设置ETR以接受来自源多播站点中ITR的多播封装数据包。多播ETR解除多播封装数据包的封装，并在通向内部接收器的接口上进行复制。
xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint; it is used synonymously with the term "tunnel router". For example, "an xTR can be located at the Customer Edge (CE) router" means that both ITR and ETR functionality can be at the CE router.
xTR：当数据流的方向不是上下文描述的一部分时，是对ITR或ETR的引用。xTR是指作为隧道端点的路由器；它与术语“隧道路由器”同义。例如，“xTR可以位于客户边缘（CE）路由器”意味着ITR和ETR功能都可以位于CE路由器。
LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers, and an ETR strips headers. A LISP-encapsulated multicast packet will have an "inner" header with the source EID in the source field, an "outer" header with the source RLOC in the source field, and the same globally unique group address in the destination field of both the inner and outer header.
LISP标头：本文档中使用的术语，用于指外部IPv4或IPv6标头、UDP标头和LISP标头。ITR预处理标题，ETR剥离标题。LISP封装的多播数据包将在源字段中有一个带有源EID的“内部”报头，在源字段中有一个带有源RLOC的“外部”报头，在内外报头的目标字段中有相同的全局唯一组地址。
(S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state that resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core).
（S，G）状态：形式定义采用PIM稀疏模式[RFC4601]规范。对于本规范，术语通常用于指多播状态。根据其拓扑位置，驻留在路由器中的（S，G）状态可以是（S-EID，G）状态（在（S，G）状态驻留的位置）或（S-RLOC，G）状态（在互联网核心中）。
(S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside of a site.
（S-EID，G）状态：指多播源和接收站点中的多播状态，其中S-EID是多播源主机（其EID）的IP地址。S-EID可以出现在IGMPv3报告、MSDP SA消息或在站点内部传播的PIM加入/删除消息中。
(S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from the (S-EID,G) entry by doing a mapping database lookup for the EID-Prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/ Prune message when it travels from an ETR to an ITR over the Internet core.
（S-RLOC，G）状态：指核心中的多播状态，其中S是具有多播源的站点的源定位器（多播ITR的IP地址）。通过对S-EID映射到的EID前缀执行映射数据库查找，从（S-EID，G）条目映射（S-RLOC，G）。当S-RLOC通过互联网核心从ETR传输到ITR时，它可能出现在PIM加入/删减消息中。
uLISP Site: a unicast-only LISP site according to [RFC6830] that has not deployed the procedures of this specification and, therefore, for multicast purposes, follows the procedures from Section 9. A uLISP site can be a traditional multicast site.
uLISP站点：根据[RFC6830]的规定，仅单播的LISP站点，未部署本规范的过程，因此，出于多播目的，遵循第9节中的过程。uLISP站点可以是传统的多播站点。
LISP Site: a unicast LISP site (uLISP Site) that is also multicast capable according to the procedures in this specification.
LISP站点：单播LISP站点（uLISP站点），根据本规范中的程序，该站点也具有多播功能。
mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID-Prefix to which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune messages. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy-ETRs for supporting multicast routing in a LISP infrastructure. It is likely a uPITR [RFC6832] and an mPETR will be co-located since the single device advertises a coarse EID-Prefix in the underlying unicast routing system.
mPETR：这是一个多播代理ETR，负责宣传非常粗糙的EID前缀，非LISP和uLISP站点可以将其（S-EID，G）PIM加入/删除消息作为目标。MPETR的使用使得LISP源多播站点可以使用EID命名空间中的源地址发送多播数据包。MPETR充当代理ETR，用于在LISP基础设施中支持多播路由。它可能是uPITR[RFC6832]和mPETR将位于同一位置，因为单个设备在底层单播路由系统中播发粗略的EID前缀。
Mixed Locator-Sets: this is a Locator-Set for a LISP database mapping entry where the RLOC addresses in the Locator-Set are in both IPv4 and IPv6 format.
混合定位器集：这是LISP数据库映射项的定位器集，其中定位器集中的RLOC地址同时为IPv4和IPv6格式。
Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (LISP-encapsulated with destination UDP port 4341) that is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the OIF-list for the (S-EID,G) entry for which the ETR is joining.
单播封装的PIM加入/删减消息：这是一条标准PIM加入/删减消息（用目标UDP端口4341封装的LISP），由ETRs在多播接收站点发送到多播源站点的ITR。只要ETR正在加入的（S-EID，G）条目的OIF列表中存在接口，则会定期发送此消息。
OIF-list: this is notation to describe the outgoing interface list a multicast router stores per multicast routing table entry so it knows on which interfaces to replicate multicast packets.
OIF list：这是一种表示法，用于描述多播路由器在每个多播路由表条目上存储的传出接口列表，以便知道在哪些接口上复制多播数据包。
RPF: Reverse Path Forwarding is a procedure used by multicast routers. A router will accept a multicast packet for forwarding if the packet was received on the path that the router would use to forward unicast packets to the multicast packet's source.
RPF：反向路径转发是多播路由器使用的一个过程。如果在路由器用于将单播数据包转发到多播数据包源的路径上接收到多播数据包，则路由器将接受该数据包进行转发。
LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the Traffic Engineering features of LISP [RFC6830], a multicast source site can control the egress of its multicast traffic. By controlling the priorities of Locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site.
LISP用于单播路由时，提高了站点控制入口流量的能力。出口交通流由源站点的IGP控制。对于多播，IGP和PIM可以决定多播数据包进入的路径。通过使用LISP[RFC6830]的流量工程特性，多播源站点可以控制其多播流量的出口。通过从映射数据库条目控制定位器的优先级，源多播站点可以控制多播接收方站点加入源站点的方式。
At this point in time, there is no requirement for different Locator-Sets, priority, and weight policies for multicast than there is for unicast. However, when Traffic Engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages.
此时，与单播相比，多播不需要不同的定位集、优先级和权重策略。然而，当单播和多播流的流量工程策略不同时，最好在Map应答消息中使用基于多播的优先级和权重值。
The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in a LISP-Multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR.
基本的多播转发模型是将一个多播包封装到另一个多播包中。ITR将封装从LISP多播报头中服务的源接收的多播数据包。将内部标头的目标组地址复制到外部标头的目标地址。内部源地址是多播源主机的EID，外部源地址是封装ITR的RLOC。
The LISP-Multicast architecture will follow this high-level protocol and operational sequence:
LISP多播架构将遵循以下高级协议和操作顺序：
1. Receiver hosts in multicast sites will join multicast content the way they do today -- they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs; that is, they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is, the closest exit for the Join/Prune message and the closest entrance for the multicast packet to the receiver).
1. 多播站点中的接收主机将以今天的方式加入多播内容——它们使用IGMP。当他们使用指定源地址的IGMPv3时，他们使用源EID；也就是说，它们加入（S-EID，G）。如果多播源在此接收方站点外部，PIM加入/删减消息将流向ETR，找到最短的出口（即，加入/删减消息的最近出口和多播数据包到接收方的最近入口）。
2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping.
2. ETR对S-EID执行映射数据库查找。如果映射是从以前的查找（从源多播站点的以前加入/删除或到该站点的单播数据包）缓存的，则它将使用映射中的RLOC信息。
The ETR will use the same priority and weighting mechanism as for unicast. So, the source site can decide which way multicast packets egress.
ETR将使用与单播相同的优先级和权重机制。因此，源站点可以决定多播数据包以何种方式退出。
3. The ETR will build two PIM Join/Prune messages, one that contains an (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other that contains an (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR.
3. ETR将构建两条PIM加入/删减消息，一条包含（S-EID，G）条目，该条目单播到与ETR选择的RLOC相匹配的ITR，另一条包含（S-RLOC，G）条目，以便核心网络可以创建从该ETR到ITR的多播状态。
4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message, it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR.
4. 当ITR获得单播加入/删减消息（正式定义见第3节）时，它将处理消息中的（S-EID，G）条目，并通过IGP在站点内部传播这些条目，在该站点中它有EID的显式路由信息。当ITR接收到（S-RLOC，G）PIM加入/删减消息时，它将像处理今天互联网上的任何其他加入一样对其进行处理。S-RLOC地址是此ITR的IP地址。
5. At this point, there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site).
5. 此时，从接收器多播站点中的加入主机到接收器多播站点的ETR存在（S-EID，G）状态。从多播接收器站点的ETR到多播源站点中的ITR，核心网络中存在（S-RLOC，G）状态，而在源多播站点中存在（S-EID，G）状态。注意，（S-EID，G）状态在每个多播站点中都是相同的S-EID。当其他ETR加入相同的多播树时，它们可以通过相同的ITR（在这种情况下，数据包复制在核心中完成）或不同的ITR（在这种情况下，数据包复制在源站点上完成）加入。
6. When a packet is originated by the multicast host in the source site, the packet will flow to one or more ITRs that will prepend a LISP header. By copying the group address to the outer destination address field, the ITR inserts its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface on which an (S-RLOC,G) join was received. The core has (S-RLOC,G) so where fan-out occurs to multiple sites, a core router will do packet replication.
6. 当数据包由源站点中的多播主机发起时，该数据包将流到一个或多个ITR，该ITR将在LISP报头之前。通过将组地址复制到外部目标地址字段，ITR在外部源地址字段中插入自己的定位器地址。ITR将查看其（S-RLOC，G）状态，其中S-RLOC是其自己的定位地址，并在接收（S-RLOC，G）连接的每个接口上复制数据包。核心具有（S-RLOC，G），因此当多个站点发生扇出时，核心路由器将执行数据包复制。
7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would not have received the packets because it would not have joined. The ETR decapsulates and does an (S-EID,G) lookup in its multicast Forwarding Information Base (FIB) to forward packets out one or more interfaces to forward the packet to internal receivers.
7. 当源站点或核心复制数据包时，ETR将收到一个带有目标组地址的LISP数据包。它将解除数据包的封装，因为它具有组的接收器。否则，它将不会收到数据包，因为它不会加入。ETR解除封装并在其多播转发信息库（FIB）中执行（S-EID，G）查找，以将数据包转发出一个或多个接口，从而将数据包转发给内部接收器。
This architecture is consistent and scalable with the architecture presented in [RFC6830] where multicast state in the core operates on Locators, and multicast state at the sites operates on EIDs.
该体系结构与[RFC6830]中提出的体系结构一致且可扩展，其中核心的多播状态在定位器上运行，站点的多播状态在EID上运行。
Alternatively, [RFC6830] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF Vectors [RFC5496] in PIM Join/Prune messages. However, few PIM implementations support RPF Vectors, and LISP should avoid S-EID state in the core. See Section 5 for details.
或者，[RFC6830]还具有一种机制，其中（S-EID，G）状态可以通过在PIM连接/修剪消息中使用RPF向量[RFC5496]驻留在核心中。然而，很少有PIM实现支持RPF向量，LISP应该避免核心中的S-EID状态。详见第5节。
However, some observations can be made on the algorithm above. The control plane can scale but at the expense of sending data to sites that may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G), and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the OIF-list state for the (S-RLOC,G) entry. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G), packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC.
但是，可以对上述算法进行一些观察。控制平面可以扩展，但代价是将数据发送到可能尚未加入分发树的站点，在分发树中传递封装的数据。例如，一个站点加入（S-EID1，G），另一个站点加入（S-EID2，G）。两个EID位于同一个多播源站点中。两个多播接收器站点都以状态（S-RLOC，G）加入到相同的ITR，其中S-RLOC是ITR的RLOC。ITR在站点内部连接（S-EID1，G）和（S-EID2，G）。ITR接收（S-RLOC，G）加入并填充（S-RLOC，G）条目的OIF列表状态。由于（S-EID1，G）和（S-EID2，G）都映射到一个（S-RLOC，G），因此即使每个多播接收器站点都加入了一个基于源的分发树，数据包也将由核心交付到两个多播接收器站点。这种行为是S-EID和S-RLOC之间多对一映射的结果。
There is a possible solution to this problem that reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one-to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but "n" can reduce to a smaller number in the "n-to-1" relationship. And in turn, this reduces the opportunity for data packets to be delivered to sites for groups not joined.
这个问题有一个可能的解决方案，它可以减少（S-EID，G）项聚合为单个（S-RLOC，G）项的多对一出现次数。如果可以为物理ITR分配多个RLOC地址，并且这些地址在映射数据库条目中公布，则接收方站点的ETR具有更多RLOC地址选项，因此可以为在接收方站点加入的每个（S-EID，G）条目加入不同的（RLOC，G）条目。一个源站点的S-EID源数量与分配给该站点所有ITR的RLOC数量之间不存在一对一的关系，但在“n对1”关系中，“n”可以减少到一个较小的数字。反过来，这减少了数据包被传送到未加入组的站点的机会。
Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast.
多播组地址不必与EID或RLOC命名空间相关联。它们实际上是它们自己的名称空间，可以用相对不透明的分配将其视为逻辑名称空间。因此，从本质上讲，它们不会影响LISP多播的增量部署。
As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs. EID addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet.
至于源地址，就像在单播LISP场景中一样，存在标识与位置的分离。在LISP站点中，数据包来自使用其分配的EID的主机。EID地址用于标识主机以及主机在站点拓扑中的位置，但不用于标识主机连接到Internet的方式和位置。
Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)}, where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site; the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites; and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites.
因此，当在网络中从任何多播接收器到多播源的路径上的任何位置创建多播分发树状态时，EID状态在源和接收器多播站点保持，RLOC状态在核心中保持。即，多播分布树将被表示为{（S-EID，G）（S-RLOC，G）（S-EID，G）}的3元组，其中3元组的第一个元素是从源到源多播站点中的一个或多个itr的路由器中存储的状态；三元组的第二个元素是存储在ITR下游路由器中的状态，在核心中，到所有LISP接收器多播站点；三元组中的第三个元素是存储在每个ETR下游路由器中的状态，在每个接收器多播站点中，到达每个接收器。请注意，（S-EID，G）在源和接收器多播站点中都是相同的。
The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR, and from the second element to the third element is done at the ETRs.
从3元组的第一个元素到第二个元素的连接/映射由ITR完成，从第二个元素到第三个元素的连接/映射由ETR完成。
Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that uses RPF against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast, the source S is a single ITR of the multicast source site.
存储在核心中的多播状态始终是当前存在的（S，G）状态或部署LISP站点时将存在的（S-RLOC，G）状态。核心路由器无法区分两者。它们不需要这样做，因为是state对RLOC命名空间中的核心路由表使用RPF。区别在于特定源的分发树的根在哪里。在传统的多播核心中，源S是源主机的IP地址。对于LISP多播，源S是多播源站点的单个ITR。
An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So, an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR becomes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally
ITR是根据ETR将PIM加入/删减消息传播出接收方多播站点时使用的LISP EID到RLOC映射选择的。选择基于ITR在向站点发送单播数据包时用于选择ETR的相同算法。在单播情况下，ITR可以根据ETR的可达性在每个分组的基础上改变。因此，ITR可以使用局部可达状态相对容易地改变。但是，在多播情况下，当无法访问ITR时，必须建立新的分发树状态，因为封装根已更改。这比RPF更改事件更重要，在RPF更改事件中，任何路由器通常在本地
change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be built and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined.
将其RPF接口更改为其现有树状态。但是当封装的LISP多播ITR无法访问时，必须构建新的分发状态并反映新的封装器。因此，当无法访问ITR时，当前加入该ITR的所有ETR将必须触发新ITR的（S-RLOC，G）加入/删除消息，并发送单播封装的加入/删除消息，告知新ITR正在加入的（S-EID，G）。
This issue can be mitigated by using anycast addressing for the ITRs, so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed, so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures.
可以通过对ITR使用选播寻址来缓解此问题，因此问题确实会减少到核心中的RPF更改，但仍然需要单播封装的Join/Prune消息来告诉新的ITR（S-EID，G）。这种方法的问题在于ETR实际上不知道ITR何时更改，因此新的选播ITR只有在ETR下次在其定期发送过程中发送时才会获得（S-EID，G）状态。
A number of protocols are used today for inter-domain multicast routing:
目前，许多协议用于域间多播路由：
IGMPv1-v3, MLDv1-v2: These protocols [RFC4604] do not require any changes for LISP-Multicast for two reasons. One is that they are link-local and not used over site boundaries, and the second is that they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and Multicast Listener Discovery version 2 (MLDv2) messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses, which are therefore from the EID namespace.
IGMPv1-v3、MLDv1-v2：出于两个原因，这些协议[RFC4604]不需要对LISP多播进行任何更改。一是它们是本地链接，不在站点边界上使用，二是它们宣传不需要翻译的组地址。在IGMPv3和多播侦听器发现版本2（MLDv2）消息中提供源地址的情况下，它们在语义上被视为EID，在ETR在站点边界接收到多播树构建协议（如PIM）之前，不需要转换为RLOCs。用于IGMP和MLD的地址来自源站点分配的地址，因此这些地址来自EID名称空间。
MBGP: Even though the Multiprotocol Extensions for BGP-4 (MBGP) [RFC4760] are not part of a multicast routing protocol, they are used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes that are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. There are no MBGP changes required to support LISP-Multicast.
MBGP：尽管BGP-4（MBGP）[RFC4760]的多协议扩展不是多播路由协议的一部分，但当单播BGP对等拓扑和多播MBGP对等拓扑不一致时，它们用于查找多播源。在LISP多播环境中使用MBGP时，播发的前缀来自RLOC命名空间。这允许接收方多播站点查找到源多播站点的ITR的路径。MBGP对等地址将来自RLOC命名空间。支持LISP多播不需要MBGP更改。
MSDP: MSDP [RFC3618] is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the
MSDP:MSDP[RFC3618]用于向其他路由域（或LISP站点）宣布活动多播源。这些公告来自PIM集合点（RPs），这些集合点来自有活动多播源发送到各个组的站点。在
context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of the site will be from the EID namespace so it can be advertised and reached by an internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. Also, the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. There are no MSDP changes required to support LISP-Multicast.
在LISP多播上下文中，MSDP中公布的源地址在语义上来自EID命名空间，因为它们描述源多播主机的标识。确实，存储在核心路由器的MSDP缓存中的状态将来自EID命名空间。站点内部的RP地址将来自EID名称空间，因此可以通过内部单播路由机制进行播发和访问。但是，要使MSDP对等RPF检查在站点间正常工作，RP地址必须转换或映射为可路由地址，该地址在核心的BGP路由表中公布和维护。MSDP对等地址可以来自EID或可路由地址命名空间。此外，可以单方面做出选择，因为站点的ITR将通过查看映射数据库服务来确定目标对等地址不在哪个命名空间中。支持LISP多播不需要MSDP更改。
PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode [RFC4607], a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to how PIM Join/Prune messages are sent by the LISP-Multicast component. No modifications to any message format, but to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [RFC5135].
PIM-SSM：在构建分发树的最简单形式中，当PIM在SSM模式[RFC4607]下运行时，跨站点边界构建并维护源分发树。在本例中，LISP多播组件发送PIM加入/删减消息的方式有一个小的修改。不修改任何消息格式，但支持从EID命名空间中获取源自LISP站点内部的包含嵌入地址的Join/Prune消息，并在Join/Prune消息跨越站点边界时将其转换为RLOC命名空间中的地址。这与[RFC5135]中记录的要求类似。
BIDIR-PIM: Bidirectional PIM [RFC5015] is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were in a well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using BIDIR-PIM for inter-domain multicast routing, it is recommended to use statically configured RPs. This allows core routers to associate a Bidir group's RP address with an ITR's RLOC address, and site routers to associate the Bidir group's RP address as an EID address. With respect to Designated Forwarder (DF) election in BIDIR-PIM, no changes are required since all messaging and addressing is link-local.
BIDIR-PIM：双向PIM[RFC5015]通常在路由域内运行，但如果部署在域间环境中，则必须确定共享树的RP地址是来自EID命名空间还是来自RLOC命名空间。如果RP位于基于站点的路由器中，则RP地址来自EID命名空间。如果RP位于路由RLOC地址的核心中，则RP地址来自RLOC命名空间。如果EID地址位于RLOC命名空间的已知地址分配块中，则可以很容易地区分这一点。此外，当使用嵌入式RP进行RP确定[RFC3956]时，组地址的格式可以指示RP地址来自的名称空间。但是，有关使用嵌入式RP IPv6组地址时核心路由器需要注意的事项，请参阅第10节。当使用BIDIR-PIM进行域间多播路由时，建议使用静态配置的RPs。这允许核心路由器将Bidir组的RP地址与ITR的RLOC地址相关联，站点路由器将Bidir组的RP地址与EID地址相关联。关于BIDIR-PIM中的指定转发器（DF）选择，无需更改，因为所有消息和寻址都是本地链路。
PIM-ASM: The ASM mode of PIM [RFC4601], the most popular form of PIM, is deployed in the Internet today by having shared trees within a site and using source trees across sites. By the use of MSDP and PIM-SSM techniques described above, multicast connectivity can occur across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared tree that is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and Bootstrap Router (BSR) [RFC5059].
PIM-ASM:PIM[RFC4601]的ASM模式是目前最流行的PIM形式，它通过在站点内共享树和跨站点使用源树在Internet上部署。通过使用上述MSDP和PIM-SSM技术，可以跨LISP站点实现多播连接。话虽如此，这意味着处理（*，G）或（S，G，R）加入/删减消息不需要特殊操作，因为它们都针对站点驻留的共享树进行操作。与ASM一样，当使用LISP多播时，核心中没有（*，G）。RP映射机制自动RP和引导路由器（BSR）[RFC5059]也是如此。
Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change.
根据上面的协议描述，结论是没有协议消息格式的更改，只是在控制平面上执行了翻译功能。这将使LISP的转换更容易、更快，因为网络中需要更改的组件更少。
It should also be stated just like it is in [RFC6830] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets.
还应该像在[RFC6830]中一样说明，让多播源主机发送多播数据包和让多播接收主机接收多播数据包不需要任何主机更改。
The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [RFC6830]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC) as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding.
LISP多播数据平面操作符合[RFC6830]中规定的操作和数据包格式。然而，从ITR封装多播数据包是一个简单得多的过程。该过程只是将内部组地址复制到外部目标地址。并让ITR使用其自己的IP地址（其RLOC）作为源地址。对于多播，该过程更简单，因为在数据包转发期间没有执行EID到RLOC的映射查找。
In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then, the OIF-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts.
在解除封装的情况下，ETR只需删除外部报头并对内部报头（S-EID，G）地址执行多播路由表查找。然后，使用（S-EID，G）条目的OIF列表在通向多播接收器主机的面向站点的接口上复制数据包。
There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case.
ETR没有单播转发情况下可能存在的数据探测逻辑。
The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site:
当ITR从其站点内部的源接收多播数据包时，使用以下过程：
1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow.
1. LISP站点中的主机发送的多播数据包的源地址等于主机的EID，目标地址等于多播组的地址。假设组信息是通过当前方法获得的。对于多播接收器来说，获得多播流的源地址和组地址也是如此。
2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the OIF-list contains interfaces that are site facing and external facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header that the host built as the outer destination address.
2. 当ITR接收到多播数据包时，它将同时存储S-EID状态和S-RLOC状态。由于数据包是在面向站点的接口上接收的，因此RPF查找基于S-EID状态。如果RPF检查成功，则OIF列表包含面向站点和面向外部的接口。对于面向站点的接口，不预先添加LISP头。对于面向外部的接口，会预先添加LISP标头。当ITR在LISP报头前加前缀时，它使用自己的RLOC地址作为源地址，并复制由主机构建为外部目标地址的IP报头提供的组地址。
Typically, an ITR will have a single RLOC address, but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case, when (S-RLOC,G) Join/ Prune messages are received for each RLOC, there is a OIF-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on an (S-EID,G) entry, the interfaces of the OIF-list from all (RLOC,G) entries joined to the ITR as well as the site-facing OIF-list joined for (S-EID,G) must be included in packet replication. In addition to replicating for all types of OIF-lists, each OIF-list entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined.
通常，一个ITR将有一个RLOC地址，但在某些情况下，可能有多个RLOC地址从相同或不同的服务提供商分配。在这种情况下，当为每个RLOC接收（S-RLOC，G）加入/删减消息时，必须执行OIF列表合并操作。因此，当从与（S-EID，G）条目匹配的面向站点的接口接收到数据包时，来自加入ITR的所有（RLOC，G）条目的OIF列表的接口以及为（S-EID，G）加入的面向站点的OIF列表必须包括在数据包复制中。除了为所有类型的OIF列表进行复制外，每个OIF列表条目都必须使用RLOC地址进行标记，因此封装使用外部源地址作为RLOC的连接地址。
Note that when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because
请注意，当来自不同多播接收器站点的ETR接收（S-EID，G）加入时，由于策略原因，它们可能会为多播源站点选择不同的S-RLOC（多播ITR可以为每个ETR映射请求返回不同的多播优先级和权重值）。在这种情况下，相同的（S-EID，G）由内核中的不同（S-RLOC，G）状态实现。这不会导致重复的数据包，因为
each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs.
多播源站点中的每个ITR将为封装的多播流量的源地址选择自己的RLOC。RLOC地址是由远程多播ETR连接的地址。
When different (S-EID,G) traffic is combined into a single (RLOC,G) core distribution tree, this may cause traffic to go to a receiver multicast site when it does not need to. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2-EID,Gi) through the same core distribution tree of (RLOC1,Gi). When ETRs decapsulate such traffic, they should know from their local (S-EID,G) state if the packet should be forwarded. If there is no (S-EID,G) state that matches the inner packet header, the packet is discarded.
当不同的（S-EID，G）通信量组合到单个（RLOC，G）核心分发树中时，这可能会导致通信量在不需要时转到接收器多播站点。当一个接收方多播站点通过（RLOC1，Gi）的核心分发树加入（S1-EID，Gi），而另一个多播接收方站点通过（RLOC1，Gi）的相同核心分发树加入（S2-EID，Gi）时，就会发生这种情况。当ETR解除对此类流量的封装时，他们应该从本地（S-EID，G）状态知道是否应该转发数据包。如果没有（S-EID，G）状态与内部数据包报头匹配，则丢弃该数据包。
The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site:
当ETR从其站点外部的源接收多播数据包时，ETR使用以下过程：
1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the OIF-list are used for replication to interfaces that are site facing as well as interfaces that are external facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header is not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped.
1. 当ETR在面向外部的接口上接收到多播数据包时，它将对其存储的S-RLOC状态执行RPF查找。如果RPF检查成功，OIF列表中的接口将用于复制到面向站点的接口以及面向外部的接口（此ETR也可以是其站点外接收器的传输多播路由器）。当要为面向外部的接口复制数据包时，不会剥离LISP封装头。当为面向站点的接口复制数据包时，封装头被剥离。
2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site.
2. 没有LISP报头的数据包现在被转发到接收方多播站点中的（S-EID，G）分发树下。
Multicast packet replication can happen in the following topological locations:
多播数据包复制可以在以下拓扑位置进行：
o In an IGP multicast router inside a site that operates on S-EIDs.
o 在运行于S-EIDs的站点内的IGP多播路由器中。
o In a transit multicast router inside of the core that operates on S-RLOCs.
o 在S-RLOCs上运行的核心内部的传输多播路由器中。
o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site.
o 在一个或多个ETR路由器上，根据加入/删减消息退出接收器多播站点的路径而定。
o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites.
o 在源多播站点中的一个或多个ITR路由器上，取决于在对接收器多播站点的Map应答中返回的优先级。
In the last case, the source multicast site can do replication rather than having a single exit from the site. But this can occur only when the priorities in the Map-Reply are modified for different receiver multicast sites so that the PIM Join/Prune messages arrive at different ITRs.
在最后一种情况下，源多播站点可以进行复制，而不需要从站点退出。但是，只有当针对不同的接收方多播站点修改Map应答中的优先级，以便PIM加入/删减消息到达不同的itr时，才会发生这种情况。
This policy technique, also used in [RFC6836] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6.
此策略技术也在[RFC6836]中用于单播，可用于多播，以缓解第6节中讨论的更改分发树状态的问题。
This section describes the multicast corollary to [RFC6832] regarding the interworking of multicast routing among LISP and non-LISP sites.
本节介绍[RFC6832]关于LISP和非LISP站点间多播路由互通的多播推论。
Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same, regardless of whether or not the site is LISP enabled. So, most of the implications are in the core with respect to storing routable EID-Prefixes from either PA or PI blocks.
由于多播通信可能涉及两个以上的实体一起通信，因此更涉及互通场景的组合。但是，无论站点是否启用LISP，站点上为分发树维护的状态都是相同的。因此，大多数含义都是关于存储来自PA或PI块的可路由EID前缀的核心。
Before enumerating the multicast interworking scenarios, let's define three deployment states of a site:
在枚举多播互通场景之前，让我们定义站点的三种部署状态：
o A non-LISP site that will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable.
o 一个非LISP站点，将像今天一样使用MSDP运行PIM-SSM或PIM-ASM。站点的地址是全局可路由的。
o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site.
o 为单播路由部署LISP的站点。站点的地址不可全局路由。让我们将此类站点的名称定义为uLISP站点。
o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site.
o 为单播和多播路由部署LISP的站点。站点的地址不可全局路由。让我们将此类站点的名称定义为LISP多播站点。
A LISP site enabled for multicast purposes only will not be considered in this document, but a uLISP site as documented in [RFC6832] will be considered. In this section there is no discussion of how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections.
本文件不考虑仅为多播目的启用的LISP站点，但将考虑[RFC6832]中记录的uLISP站点。在本节中，没有讨论当所有接收站点都启用LISP多播时，LISP站点如何发送多播数据包；这已经在前面的章节中讨论过。
The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites:
存在以下场景以使LISP多播站点与非LISP多播站点交互：
1. A LISP site must be able to send multicast packets to receiver sites that are a mix of non-LISP sites and uLISP sites.
1. LISP站点必须能够将多播数据包发送到由非LISP站点和uLISP站点组成的接收站点。
2. A non-LISP site must be able to send multicast packets to receiver sites that are a mix of non-LISP sites and uLISP sites.
2. 非LISP站点必须能够向混合了非LISP站点和uLISP站点的接收方站点发送多播数据包。
3. A non-LISP site must be able to send multicast packets to receiver sites that are a mix of LISP sites, uLISP sites, and non-LISP sites.
3. 非LISP站点必须能够向混合了LISP站点、uLISP站点和非LISP站点的接收方站点发送多播数据包。
4. A uLISP site must be able to send multicast packets to receiver sites that are a mix of LISP sites, uLISP sites, and non-LISP sites.
4. uLISP站点必须能够向包含LISP站点、uLISP站点和非LISP站点的接收方站点发送多播数据包。
5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites.
5. LISP站点必须能够将多播数据包发送到包含LISP站点、uLISP站点和非LISP站点的接收站点。
In the first scenario, a site is LISP enabled for both unicast and multicast traffic and as such operates on EIDs. Therefore, there is a possibility that the EID-Prefix block is not routable in the core. For LISP receiver multicast sites, this isn't a problem, but for non-LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP Network Address Translation (LISP-NAT) in [RFC6832] solves.
在第一个场景中，站点对单播和多播流量都启用LISP，因此在EID上运行。因此，EID前缀块可能无法在核心中路由。对于LISP接收器多播站点，这不是问题，但对于非LISP或uLISP接收器多播站点，当边缘路由器接收到PIM加入/删减消息时，它没有将加入/删减消息传播出站点的路由。这与[RFC6832]中的LISP网络地址转换（LISP-NAT）解决的单播情况没有什么不同。
LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non-LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So, the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site because it is desirable for ITRs to process a PIM Join/Prune message that is received from an external-facing interface. If the message will be propagated inside of the site, the site-part of the distribution tree is built.
LISP-NAT允许退出LISP站点的单播数据包在ITR意识到不应封装发送到非LISP站点的数据包之前，将其源地址映射到全局可路由地址。对于要离开LISP站点的多播数据包，需要建立分发树状态，以便ITR知道将数据包发送到哪里。因此，接收方多播站点需要通过其可路由地址而不是EID地址来了解多播源主机。在这种情况下，可路由地址是存储和维护在核心路由器中的（S-RLOC，G）状态。请务必注意，主机的可路由地址不能与站点的RLOC相同，因为ITRs需要处理从外部接口接收的PIM加入/删除消息。如果消息将在站点内部传播，则构建分发树的站点部分。
Using a globally routable source address allows non-LISP and uLISP multicast receivers to join, create, and maintain a multicast distribution tree. However, the LISP-Multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find an (S-RLOC,G) entry to Join in the core. So, there is a conflict of behavior between the two types of sites.
使用全局可路由源地址允许非LISP和uLISP多播接收器加入、创建和维护多播分发树。但是，当在面向站点的接口上接收到PIM Join/Prune消息时，LISP多播接收器站点将希望执行EID到RLOC映射表查找。它这样做是因为它想找到一个（S-RLOC，G）条目来加入核心。因此，这两种类型的站点之间存在行为冲突。
The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs to determine if the site is LISP enabled or not. When it is not LISP enabled, the ITR does not encapsulate the packet. So, for the multicast case, when the ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the mapping database because the source multicast site is using a routable address and not an EID-Prefix address. So, the ETR knows to simply propagate the PIM Join/Prune message to an external-facing interface without converting the (S-EID,G) because it is an (S,G), where S is routable and reachable via core routing tables.
此问题的解决方案与ITR希望向目标站点发送单播数据包时相同，但需要确定站点是否启用LISP。未启用LISP时，ITR不会封装数据包。因此，对于多播情况，当ETR收到（S-EID，G）状态的PIM Join/Prune消息时，它将在S-EID上执行映射表查找。在这种情况下，S-EID不在映射数据库中，因为源多播站点使用的是可路由地址，而不是EID前缀地址。因此，ETR知道只需将PIM Join/Prune消息传播到外部接口，而无需转换（S-EID，G），因为它是（S，G），其中S可通过核心路由表路由和访问。
Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way the packet forwarding model is used can be explained.
既然多播分发树是从任何非LISP或uLISP接收器多播站点构建和维护的，那么就可以解释包转发模型的使用方式了。
Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable (and not registered to the mapping database system), it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router.
由于源多播站点中的ITR从未从接收方多播站点中的任何ETR接收到单播封装的PIM加入/删减消息，因此它知道不存在LISP多播接收方站点。因此，ITR不需要封装数据。由于它将先验地（通过配置）知道其站点的EID不可路由（且未注册到映射数据库系统），因此它假定来自源主机的多播数据包是通过可路由地址发送的。也就是说，多播源主机的系统管理员有责任确保源主机使用可路由的源地址发送多播流量。当这种情况发生时，ITR只是充当路由器，并像普通多播路由器一样转发多播数据包。
There is an alternative to using a LISP-NAT scheme just as there is an alternative to using unicast [RFC6832] forwarding by employing Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) that make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID-Prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree
使用LISP-NAT方案有一个替代方案，正如使用代理隧道路由器（PXTR）使用单播[RFC6832]转发有一个替代方案一样。这同样适用于多播路由，但不同之处在于，非LISP和uLISP站点将为（S-EID，G）发送PIM加入/删减消息，这些消息将在核心中发送到多播PXTR。让我们将PxTR的这种使用称为“多播代理ETR”（或mPETR）。由于MPETR宣传非常粗糙的EID前缀，因此它们会绘制PIM连接/修剪控制流量，使其成为分发树的目标。要从LISP源多播站点获取多播数据包，请单击树
needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen, the mPETR acts as a "Proxy-ETR" (where in unicast it acts as a "Proxy-ITR", or an uPITR [RFC6832]).
需要在从mPETR到LISP源多播站点的路径上构建。为了实现这一点，mPETR充当“代理ETR”（在单播中，它充当“代理ITR”或uPITR[RFC6832]）。
The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs.
核心中MPETR的存在允许源多播站点ITRs根据（S-RLOC，G）状态封装多播数据包。（S-RLOC，G）状态是从mPETRs构建到多播ITRs的。封装的多播数据包由mPETRs解封，然后根据（S-EID，G）状态转发。（S-EID，G）状态是从非LISP和uLISP接收器多播站点构建到MPETR的。
Clearly non-LISP-Multicast sites can send multicast packets to non-LISP receiver multicast sites. That is what they do today. However, discussion is required to show how non-LISP-Multicast sites send multicast packets to uLISP receiver multicast sites.
显然，非LISP多播站点可以向非LISP接收方多播站点发送多播数据包。这就是他们今天所做的。但是，需要进行讨论，以说明非LISP多播站点如何将多播数据包发送到uLISP接收器多播站点。
Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non-LISP source multicast site. Since the source multicast site in this case has not been upgraded to LISP, all multicast source host addresses are routable. So, this case is simplified to where a uLISP receiver multicast site appears to the source multicast site to be a non-LISP receiver multicast site.
由于uLISP接收方多播站点不是任何（S，G）状态的目标，因此它们只向非LISP源多播站点发送（S，G）PIM Join/Prune消息。由于本例中的源多播站点尚未升级到LISP，因此所有多播源主机地址都是可路由的。因此，这种情况被简化为源多播站点认为uLISP接收方多播站点是非LISP接收方多播站点的情况。
When a non-LISP source multicast site has receivers in either a non-LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. It is known from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. It has been shown in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does an EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to an (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site, so it simply forwards the Join/Prune message. (It also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source.)
当非LISP源多播站点在非LISP/uLISP站点或LISP站点中具有接收器时，需要确定LISP接收器多播站点将如何连接到分发树。从第9.1.2节可知，非LISP和uLISP接收器多播站点可以加入分发树，但LISP接收器多播站点ETR需要知道多播源主机的源地址是否可路由。第9.1.1节显示，ETR在外部接口上发送PIM加入/删减消息之前，会进行EID到RLOC的映射查找，以确定是否应将（S，G）状态从在面向站点的接口上接收的PIM加入/删减消息转换为（S-RLOC，G）。如果查找失败，ETR可以断定源多播站点是非LISP站点，因此它只转发加入/删除消息。（它也不需要发送单播封装的Join/Prune消息，因为在非LISP站点中没有ITR，并且ETR和源之间存在命名空间连续性。）
For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy-ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast
对于非LISP源多播站点，通过使用多播代理ITRs（mPITRs），可以将（S-EID，G）状态限制在网络的边缘。mPITRs可以采用本机的、未封装的多播
packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non-LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as configured for sending unicast joins to mPITRs so they can propagate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is a work in progress.
来自非LISP源多播和uLISP站点的数据包，并将它们封装到接收器多播站点中的ETR或可以为非LISP接收器多播或uLISP站点解封装的MPETR。mPITRs负责将（S-EID，G）连接发送到非LISP源多播站点。要将分发树连接在一起，多播ETR需要配置mPITR的RLOC地址，以便它们可以发送两个（s-RLOC，G）连接以构建分发树到mPITR，并且配置为向mPITR发送单播连接，以便它们可以将（s-EID，G）连接传播到源多播站点。mPITRs的使用正在进行更多的研究，这是一项正在进行的工作。
In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled, but the ITR, by definition, is not capable of doing multicast encapsulation. So, for the purposes of multicast routing, the uLISP source multicast site is treated as a non-LISP source multicast site.
在最后一节中，解释了多播接收器站点中的ETR如何通过查看映射数据库来确定源多播站点是否启用了LISP。当源多播站点是uLISP站点时，它启用了LISP，但根据定义，ITR不能进行多播封装。因此，出于多播路由的目的，uLISP源多播站点被视为非LISP源多播站点。
Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled.
非LISP接收方多播站点可以将分发树连接到uLISP源多播站点，因为从转发角度看，源站点的行为与非LISP源站点相同。uLISP接收器多播站点也是如此，因为ETR没有内置或启用多播功能。
Special considerations are required for LISP receiver multicast sites; since they think the source multicast site is LISP enabled, the ETR cannot know if the ITR is LISP-Multicast enabled. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC [RFC6830]. When the Mpriority is set to 255, the site is considered not multicast capable. So, an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is a LISP-Multicast site or a uLISP site.
LISP接收器多播站点需要特别考虑；由于他们认为源多播站点已启用LISP，ETR无法知道ITR是否已启用LISP多播。为了解决这个问题，每个映射数据库条目将有一个每个RLOC[RFC6830]的多播2元组（Mpriority，Mweight）。当Mpriority设置为255时，该站点被视为不支持多播。因此，LISP接收方多播站点中的ETR可以区分LISP源多播站点是LISP多播站点还是uLISP站点。
When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet-forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site, then it could receive packets like a non-LISP receiver multicast site, thereby making all receiver multicast sites have homogeneous behavior. However, this poses the following issues:
当LISP源多播站点在LISP、非LISP和uLISP接收器多播站点中有接收器时，它在如何发送多播数据包方面存在冲突。ITR可以封装或本机转发多播数据包。由于接收方多播站点的行为是异构的，一种数据包转发机制不能同时满足这两种要求。但是，如果LISP接收方多播站点的行为类似于uLISP站点，那么它可以像非LISP接收方多播站点一样接收数据包，从而使所有接收方多播站点具有相同的行为。然而，这带来了以下问题：
o LISP-NAT techniques with routable addresses would be required in all cases.
o 在所有情况下都需要具有可路由地址的LISP-NAT技术。
o Or, alternatively, mPETR deployment would be required, thus forcing coarse EID-Prefix advertisement in the core.
o 或者，可能需要部署mPETR，从而强制在核心中发布粗略的EID前缀。
o But, what is most disturbing is that when all sites that participate are LISP-Multicast sites but a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a viable alternative.
o 但是，最令人不安的是，如果所有参与的站点都是LISP多播站点，但非LISP或uLISP站点加入了分发树，那么现有的加入的LISP接收方多播站点将不得不改变其行为。这将造成太多的动态树构建搅动，成为一个可行的替代方案。
So, the solution space options are:
因此，解决方案空间选项包括：
1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.
1. 使源多播站点中的LISP ITR发送两个数据包，一个用（S-RLOC，G）封装以到达LISP接收器多播站点，另一个未用（S-EID，G）封装以到达非LISP和uLISP接收器多播站点。
2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites.
2. 使LISP ITR始终使用（S-RLOC，G）封装数据包，以到达LISP多播站点，并到达可以解除封装并将（S-EID，G）数据包转发到非LISP和uLISP接收器多播站点的MPETR。
A LISP database mapping entry that describes the Locator-Set, Mpriority, and Mweight per locator address (RLOC), for an EID-Prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC-formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets.
描述与站点关联的EID前缀的定位器集、Mpriority和每个定位器地址的mWweight（RLOC）的LISP数据库映射项可以具有IPv4或IPv6格式的RLOC地址。当映射项混合使用RLOC格式的地址时，站点会隐式地宣布它是双堆栈站点。也就是说，站点可以接收IPv4或IPv6单播数据包。
To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [RFC6830] for packet format details.
为了区分站点是否可以接收双堆栈单播数据包以及双堆栈多播数据包，Mpriority值设置将与IPv4或IPv6 RLOC相关。有关数据包格式的详细信息，请参阅[RFC6830]。
If one considers the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension.
如果考虑共享同一分发树的LISP、非LISP和uLISP站点的组合，并考虑支持IPv4、IPv6或双堆栈的能力，那么组合总数的增长将超出人们的理解。
Using some combinatorial math, the following profiles of a site and the combinations that can occur:
使用一些组合数学，以下是场地概况和可能出现的组合：
1. LISP-Multicast IPv4 Site
1. LISP多播IPv4站点
2. LISP-Multicast IPv6 Site
2. LISP多播IPv6站点
3. LISP-Multicast Dual-Stack Site
3. LISP多播双栈站点
4. uLISP IPv4 Site
4. uLISP IPv4站点
5. uLISP IPv6 Site
5. uLISP IPv6站点
6. uLISP Dual-Stack Site
6. uLISP双栈站点
7. non-LISP IPv4 Site
7. 非LISP IPv4站点
8. non-LISP IPv6 Site
8. 非LISP IPv6站点
9. non-LISP Dual-Stack Site
9. 非LISP双栈站点
Let's define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below.
让我们定义（mn）=m/（n！*（m-n）！），发音为“m选择n”以说明下面的一些组合数学。
When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If we sum this up to (9 9), then:
当一个站点与另一个站点对话时，组合数为（92），当一个站点与另两个站点对话时，组合数为（93）。如果我们将其总结为（9），那么：
(9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =
(9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =
36 + 84 + 126 + 126 + 84 + 36 + 9 + 1
36 + 84 + 126 + 126 + 84 + 36 + 9 + 1
which results in 502 as the total number of cases to be considered.
这将导致502个案例作为需要考虑的总数。
This combinatorial gets even worse when one considers a site using one address family inside of the site and the xTRs using the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs).
当考虑一个站点使用站点内部的一个地址族，而XTR使用另一个地址族时（如使用IPv4 EID和IPv6 RLOCs，或使用IPv6 EID和IPv4 RLOCs），这种组合会变得更糟。
To rationalize this combinatorial nightmare, there are some guidelines that need to be put in place:
为了使这一组合噩梦合理化，需要制定一些指导方针：
o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, head-end replication can be avoided by building and sending packets on each address-family-based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family.
o 站点之间共享的每个分发树将是IPv4分发树或IPv6分发树。因此，通过在每个基于地址族的分发树上构建和发送数据包，可以避免头端复制。尽管可能有一种将多播数据包从一种地址族格式转换到另一种地址族格式的冲动，但这是一种不可行的过于复杂的冲动。多播ITR仅封装内部和外部头来自同一地址族的数据包。
o All LISP sites on a multicast distribution tree must share a common address family that is determined by the source site's Locator-Set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP enabled. This means that priority-based policy modification is prohibited. When a receiver multicast site ETR receives an (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID.
o 多播分发树上的所有LISP站点必须共享由源站点在其LISP数据库映射项中设置的定位器确定的公共地址族。所有接收器多播站点将使用由源多播站点控制的最佳RLOC优先级。当源站点启用了LISP多播或uLISP时，情况就是这样。这意味着禁止基于优先级的策略修改。当接收器多播站点ETR接收到（S-EID，G）加入时，它必须为与S-EID相同的地址系列选择一个S-RLOC。
o When a multicast Locator-Set has more than one locator, only locators from the same address family MUST be set to the same best priority value. A mixed Locator-Set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators.
o 当一个多播定位器集有多个定位器时，只有来自同一地址族的定位器必须设置为相同的最佳优先级值。可以存在混合定位器集（用于单播），但多播优先级必须为相同地址族定位器设置。
o When the source site is not LISP enabled, determining the address family for the flow is up to how receivers find the source and group information for a multicast flow.
o 当源站点未启用LISP时，确定流的地址族取决于接收者如何查找多播流的源和组信息。
Thus far, Section 9 has shown all combinations of multicast connectivity that could occur. As already concluded, this can be quite complicated, and, if the design is too ambitious, the dynamics of the protocol could cause a lot of instability.
到目前为止，第9节已经展示了可能出现的所有多播连接组合。如前所述，这可能相当复杂，而且，如果设计过于雄心勃勃，协议的动态性可能会导致很多不稳定性。
The trade-off decisions are hard to make, and so the same single solution is desirable to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state.
很难做出折衷的决定，因此需要为IPv4和IPv6多播使用相同的单一解决方案。必须为所有IPv4单播和多播以及IPv6单播和多播提供可增量部署的解决方案，同时最小化（或消除）单播和多播EID命名空间状态。
Therefore, the design decision to go with uPITRs [RFC6832] for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space in order to optimize state requirements and avoid head-end data replication at ITRs.
因此，采用uPITRs[RFC6832]进行单播路由和mPETRs进行多播路由的设计决策似乎是解决方案空间中的最佳选择，以优化状态需求并避免ITRs处的前端数据复制。
When ASM and PIM-BIDIR are used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in an IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message that contains an Embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace and need to extract an RP address from the RLOC namespace.
当ASM和PIM-BIDIR用于IPv6域间环境时，存在一种将RP的单播地址嵌入IPv6组地址的技术[RFC3956]。当终端站点中的路由器处理包含嵌入式RP组地址的PIM加入/删减消息时，它们从组地址中提取RP地址，并从EID命名空间中处理该地址。但是，核心路由器没有EID名称空间的状态，需要从RLOC名称空间提取RP地址。
Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the Embedded-RP address is from the RLOC namespace. The mapped RP address is obtained from an EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created.
因此，多播接收器站点中的ETR负责将组地址映射到组地址，其中嵌入的RP地址来自RLOC命名空间。映射的RP地址是从EID到RLOC映射数据库查找中获得的。ETR还将向ITR发送单播（*，G）加入/删减消息，以便创建从源站点驻留RP到ITR的分发树分支。
This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address.
此技术与本规范中描述的将（S，G）状态转换和将连接/删除消息传播到核心中的技术没有什么不同。唯一的区别是，Join/Prune消息中的（*，G）状态被映射，因为它们包含在嵌入式RP组地址中编码的单播地址。
If the core routers are upgraded to support [RFC5496], then the EID-specific data can be passed through the core without, possibly, having to store the state in the core.
如果核心路由器升级为支持[RFC5496]，则EID特定数据可以通过核心传递，而可能不必在核心中存储状态。
By doing this, one can eliminate the ETR from unicast encapsulated PIM Join/Prune messages to the source site's ITR.
通过这样做，可以从单播封装的PIM加入/删减消息到源站点的ITR中消除ETR。
However, this solution is restricted to a small set of workable cases that would not be good for general use of LISP-Multicast. In addition, due to slow convergence properties, it is not recommended for LISP-Multicast.
但是，此解决方案仅限于一小部分可行的情况，这不利于LISP多播的一般使用。此外，由于收敛速度较慢，不建议将其用于LISP多播。
Mtrace functionality MUST be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible.
Mtrace功能必须与单播跟踪路由功能一致，其中从多播接收器到多播源的所有跳数都可见。
The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon mtrace version 2 specified in [MTRACE].
用于LISP多播环境的mtrace设计有待确定，但应基于[mtrace]中指定的mtrace版本2进行构建。
The security concerns for LISP-Multicast are mainly the same as for the base LISP specification [RFC6830] and for multicast in general, including PIM-ASM [RFC4601].
LISP多播的安全问题主要与基本LISP规范[RFC6830]和多播（包括PIM-ASM[RFC4601]）的安全问题相同。
There may be a security concern with respect to unicast PIM messages. When multiple receiver sites are joining an (S-EID1,G) distribution tree that maps to a (RLOC1,G) core distribution tree, and a malicious receiver site joins an (S-EID2,G) distribution tree that also maps to
单播PIM消息可能存在安全问题。当多个接收方站点加入映射到（RLOC1，G）核心分发树的（S-EID1，G）分发树时，恶意接收方站点加入也映射到的（S-EID2，G）分发树
the (RLOC1,G) core distribution tree, the legitimate sites will receive data from S-EID2 when they did not ask for it.
在（RLOC1，G）核心分发树中，合法站点将在未请求时从S-EID2接收数据。
Other than as noted above, there are currently no known security differences between multicast with LISP and multicast without LISP. However, this has not been a topic that has been investigated deeply so far; therefore, additional issues might arise in future.
除了如上所述，目前使用LISP的多播和不使用LISP的多播之间没有已知的安全性差异。然而，到目前为止，这还不是一个被深入研究的话题；因此，将来可能会出现其他问题。
The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at the Summer 2008 IETF in Dublin were Toerless Eckert and IJsbrand Wijnands.
作者衷心感谢为本提案和规范的制定提供讨论、想法和评论的人士。提供专家评审的人有斯科特·布里姆、格雷格·谢泼德和戴夫·奥兰。2008年夏季在都柏林举行的IETF讨论会上的其他评论是Toerless Eckert和IJsbrand Wijnands。
The authors would also like to thank the MBONED working group for constructive and civil verbal feedback when this document was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko.
作者还想感谢MBONED工作组在2008年秋季明尼阿波利斯IETF上提交本文件时提供的建设性和民间口头反馈。特别是，汤姆·普萨特里、史蒂夫·卡斯纳、马歇尔·尤班克斯、迪米特里·帕帕迪米特里欧、罗恩·博尼卡、莱尼·瓜迪诺、艾莉亚·阿特拉斯、耶稣·阿兰戈和贾里·阿尔科发表了精彩的评论。
An expert review of this specification was done by Yiqun Cai and Liming Wei. The authors thank them for their detailed comments.
蔡益群和魏黎明对本规范进行了专家评审。作者感谢他们的详细评论。
This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into a LISP working group document.
这项工作起源于IRTF的路由研究小组（RRG）。个人提交的文件已转换为LISP工作组文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135]Wing，D.和T.Eckert，“网络地址转换器（NAT）和网络地址端口转换器（NAPT）的IP多播要求”，BCP 135，RFC 5135，2008年2月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496]Wijnands，IJ.，Boers，A.，和E.Rosen，“反向路径转发（RPF）向量TLV”，RFC 54962009年3月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832]Lewis，D.，Meyer，D.，Farinaci，D.，和V.Fuller，“定位器/ID分离协议（LISP）和非LISP站点之间的互通”，RFC 6832，2013年1月。
[MTRACE] Asaeda, H. and W. Lee, Ed., "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, October 2012.
[MTRACE]Asaeda，H.和W.Lee，Ed.，“MTRACE版本2：用于IP多播的跟踪路由设施”，正在进行的工作，2012年10月。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，2008年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 68362013年1月。
Authors' Addresses
作者地址
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA USA
美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司
EMail: farinacci@gmail.com
EMail: farinacci@gmail.com
Dave Meyer Cisco Systems Tasman Drive San Jose, CA USA
Dave Meyer思科系统公司美国加利福尼亚州圣何塞塔斯曼大道
EMail: dmm@cisco.com
EMail: dmm@cisco.com
John Zwiebel Cisco Systems Tasman Drive San Jose, CA USA
John Zwiebel思科系统公司美国加利福尼亚州圣何塞塔斯曼大道
EMail: jzwiebel@cruzio.com
EMail: jzwiebel@cruzio.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA USA
Stig Venaas思科系统公司美国加利福尼亚州圣何塞塔斯曼大道
EMail: stig@cisco.com
EMail: stig@cisco.com