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




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.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


2. Requirements Notation
2. 需求符号

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].


3. Definition of Terms
3. 术语的定义

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.


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.


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.


Ingress Tunnel Router (ITR): a router that accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally routable RLOCs as the source address field. This RLOC is known to other multicast receiver


sites that have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated multicast IP packets out all external interfaces that have been joined.


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.


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.


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.


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.


(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-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.


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.


LISP Site: a unicast LISP site (uLISP Site) that is also multicast capable according to the procedures in this specification.


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.


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.


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.


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.


4. Basic Overview
4. 基本概况

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.


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.


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.


The LISP-Multicast architecture will follow this high-level protocol and operational sequence:


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.


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.


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.


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.


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.


5. Source Addresses versus Group Addresses
5. 源地址与组地址

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.


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.


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.


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.


6. Locator Reachability Implications on LISP-Multicast
6. LISP组播中的定位可达性问题

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.


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.


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.


7. Multicast Protocol Changes
7. 多播协议更改

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.


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.


MSDP: MSDP [RFC3618] is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the


context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of the site will be from the EID namespace so it can be advertised and reached by an internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. Also, the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. There are no MSDP changes required to support LISP-Multicast.


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].


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].


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.


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.


8. LISP-Multicast Data-Plane Architecture
8. LISP多播数据平面体系结构

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.


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.


There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case.


8.1. ITR Forwarding Procedure
8.1. ITR转发程序

The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site:


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报头提供的组地址。

8.1.1. Multiple RLOCs for an ITR
8.1.1. ITR的多个RLOC

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.


8.1.2. Multiple ITRs for a LISP Source Site
8.1.2. LISP源站点的多个ITR

Note that when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because


each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs.


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.


8.2. ETR Forwarding Procedure
8.2. ETR转发过程

The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site:


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)分发树下。

8.3. Replication Locations
8.3. 复制位置

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.


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.


9. LISP-Multicast Interworking
9. LISP多播互通

This section describes the multicast corollary to [RFC6832] regarding the interworking of multicast routing among LISP and non-LISP sites.


9.1. LISP and Non-LISP Mixed Sites
9.1. 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.


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.


The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites:


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站点的接收站点。

9.1.1. LISP Source Site to Non-LISP Receiver Sites
9.1.1. LISP源站点到非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-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.


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.


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.


There is an alternative to using a LISP-NAT scheme just as there is an alternative to using unicast [RFC6832] forwarding by employing Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) that make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID-Prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree


needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen, the mPETR acts as a "Proxy-ETR" (where in unicast it acts as a "Proxy-ITR", or an uPITR [RFC6832]).


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.


9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites
9.1.2. 非LISP源站点到非LISP接收器站点

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.


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接收方多播站点的情况。

9.1.3. Non-LISP Source Site to Any Receiver Site
9.1.3. 非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.)


For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy-ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast


packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non-LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as configured for sending unicast joins to mPITRs so they can propagate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is a work in progress.


9.1.4. Unicast LISP Source Site to Any Receiver Sites
9.1.4. 将LISP源站点单播到任何接收站点

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.


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.


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.


9.1.5. LISP Source Site to Any Receiver Sites
9.1.5. LISP源站点到任何接收站点

When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet-forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site, then it could receive packets like a non-LISP receiver multicast site, thereby making all receiver multicast sites have homogeneous behavior. However, this poses the following issues:


o LISP-NAT techniques with routable addresses would be required in all cases.

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。

9.2. LISP Sites with Mixed Address Families
9.2. 具有混合地址族的LISP站点

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.


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.


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.


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:


   (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.


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时,确定流的地址族取决于接收者如何查找多播流的源和组信息。

9.3. Making a Multicast Interworking Decision
9.3. 多播互通决策

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.


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.


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.


10. Considerations When RP Addresses Are Embedded in Group Addresses
10. RP地址嵌入组地址时的注意事项

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.


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.


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.


11. Taking Advantage of Upgrades in the Core
11. 利用核心的升级

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.


By doing this, one can eliminate the ETR from unicast encapsulated PIM Join/Prune messages to the source site's ITR.


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.


12. Mtrace Considerations
12. Mtrace考虑因素

Mtrace functionality MUST be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible.


The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon mtrace version 2 specified in [MTRACE].


13. Security Considerations
13. 安全考虑

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].


There may be a security concern with respect to unicast PIM messages. When multiple receiver sites are joining an (S-EID1,G) distribution tree that maps to a (RLOC1,G) core distribution tree, and a malicious receiver site joins an (S-EID2,G) distribution tree that also maps to


the (RLOC1,G) core distribution tree, the legitimate sites will receive data from S-EID2 when they did not ask for it.


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.


14. Acknowledgments
14. 致谢

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.


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.


15. References
15. 工具书类
15.1. Normative References
15.1. 规范性引用文件

[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.


[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.


[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月。

15.2. Informative References
15.2. 资料性引用

[MTRACE] Asaeda, H. and W. Lee, Ed., "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, October 2012.


[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



Dave Meyer Cisco Systems Tasman Drive San Jose, CA USA

Dave Meyer思科系统公司美国加利福尼亚州圣何塞塔斯曼大道


John Zwiebel Cisco Systems Tasman Drive San Jose, CA USA

John Zwiebel思科系统公司美国加利福尼亚州圣何塞塔斯曼大道


Stig Venaas Cisco Systems Tasman Drive San Jose, CA USA

Stig Venaas思科系统公司美国加利福尼亚州圣何塞塔斯曼大道