]> lispers.net

farinacci@gmail.com

Cisco Systems

Tasman Drive San Jose CA USA dmm613@gmail.com

Cisco Systems

Tasman Drive San Jose CA USA jzwiebel@cruzio.com

Cisco Systems

Tasman Drive San Jose CA USA stig@cisco.com

Cisco Systems

venggovi@cisco.com

example This document specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. This document when approved obsoletes RFC6831

Introduction The Locator/ID Separation Protocol 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 underlay routing, the underlay 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 addresses 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.
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. While the design principles of how such trees are built and maintained are the same, there are some procedural differences based on whether the underlay is unicast or multicast
3. What protocols are affected and what changes are required to such multicast protocols.
4. How ASM-mode (Any Source Multicast) and SSM-mode (Single Source Multicast) service models will operate.
5. How multicast packet flow will occur for multiple combinations of LISP-enabled and non-LISP-enabled source and receiver sites. For example:
   1. 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.
   2. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites.
   3. 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.
   4. 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) . The approach of 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, there are only operational (and not protocol) changes for PIM-ASM , Multicast Source Discovery Protocol (MSDP) , Anycast-RP , and PIM-SSM . BIDIR-PIM , which typically does not run in an inter-domain environment, is not addressed in this document. The scope of this document does not cover 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 . Similarly, specifying the detailed behavior for multicast Proxy-ITRs (mPITRs) (), mtrace (), and locator reachability () is outside the scope of this document. Deployment experiences of LISP Multicast over both unicast and multicast underlays have been documented . Deployments have successfuly demonstrated the successful minimization of multicast state in the underlay. The cost of this optimization is the extra amount of multicast packets that get sent in the same underlay tunnel. Issues and concerns about the deployment of LISP for Internet traffic are discussed in . This document obsolotes , please see for changes.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definition of Terms The terminology in this section is consistent with the definitions in 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):

As defined in , 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 or Multicast Listener Discovery Version 2 . LISP uses Provider-Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.

Routing Locator (RLOC):

as defined in

Ingress Tunnel Router (ITR):

as defined in . Additionally, it is 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):

as defined in . Additionally it is 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:

as defined in .

LISP Header:

as defined in . 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 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 underlay).

(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-RLOC,G) State:

refers to multicast state in the underlay 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 underlay.

uLISP Site:

a unicast-only LISP site according to that has not deployed the procedures of this specification and, therefore, for multicast purposes, follows the procedures from . A uLISP site can be a traditional multicast site.

LISP Site:

as defined in , 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 unicast PITR hereafter referred to as uPITR in this document 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 LISP 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. A multicast ETR LISP encapsulates PIM Join/Prune messages so PIM signalling is achieved between the ETR and ITR.

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.

RPF:

Reverse Path Forwarding is a procedure used by multicast routers as described in . 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.

Basic Overview 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 , 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. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet or a unicast 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. Alternately, the destination address of the outer header could be the RLOC of the ETR. 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/ MLD. When they use IGMPv3/ MLDv2 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.
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. The ETR will use the same priority and weighting mechanism as for unicast. So, the source site can decide which way multicast packets egress similar to the way unicast packets flow.
3. When using a multicast underlay, 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 underlay network can create multicast state from this ETR to the ITR.
4. When using a unicast underlay, the ETR will build one PIM Join/Prune message, one that contains an (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects. This PIM Join/ Prune message contains enough information to help the ITR build ingress-replicated unicast trees.
5. When the ITR gets the unicast Join/Prune message (see 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.
6. When using the multicast underlay 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.
7. When using the unicast underlay the ITR create an explicitly tracked list of unicast RLOC addresses that have joined the tree. This information is used for ingress-replication.
8. The creation, refresh, timeout and removal of the receiver-ETR RLOC entries tracked by the ITR follow the PIM Join/Prune state rules of as extended by the attributes in ; this document specifies no additional state machinery.
9. 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 underlay 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 underlay) or a different ITR (in which case the packet replication is done at the source site).
10. 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.
11. For the unicast underlay, the ITR makes individual copies for every ETR, the outer destination is set to the receiver RLOC's ETR and the outer source address is set to the S-RLOC of the ITR.
12. For the multicast underlay, the ITR copies 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 underlay has (S-RLOC,G) so where fan-out occurs to multiple sites, a underlay router will do packet replication.
13. When either the source site or the underlay 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.

This architecture is consistent and scalable with the architecture presented in where multicast state in the underlay operates on Locators, and multicast state at the sites operates on EIDs. Alternatively, also has a mechanism where (S-EID,G) state can reside in the underlay through the use of RPF Vectors in PIM Join/Prune messages. However, few PIM implementations support RPF Vectors, and LISP should avoid S-EID state in the underlay. See 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 underlay 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.

Source Addresses versus Group Addresses 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 underlay. 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 underlay, 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.

Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the underlay is either (S,G) state for sources in non-LISP sites or (RLOC,G) state for sources in LISP sites. The underlay routers cannot distinguish one from the other. They don't need to because it is state that uses RPF against the underlay 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 underlay, 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 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 underlay, 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.

Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing:

IGMPv3, MLDv2:

These protocols 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) 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 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 underlay 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 underlay. 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 , 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 .

PIM-ASM:

The ASM mode of PIM , 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 underlay when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and Bootstrap Router (BSR) .

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

PIM Join Attributes for LISP The PIM Join/Prune attributes used to build multicast distribution trees with either a multicast or a unicast underlay, including the attribute by which a receiver site selects between them, are specified in .

LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in . There is no D -->ata-Probe logic for ETRs as there can be in the unicast forwarding case.

Forwarding Procedures common to multicast and unicast underlay

ITR Forwarding Procedure

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

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

1. 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.
2. Note that there are RPF checks that need to be performed when using a multicast underlay as described in the specific section below.

Forwarding Procedures with multicast underlay

ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site in addition to the common procedures:

1. 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. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding.

Multiple RLOCs for an ITR 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.

Multiple ITRs for a LISP Source Site 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 underlay. 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) underlay 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 underlay distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2-EID,Gi) through the same underlay 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.

ETR Forwarding Procedure 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.

Replication Locations Multicast packet replication can happen in the following topological locations:

• In an IGP multicast router inside a site that operates on S-EIDs.
• In a transit multicast router inside of the underlay that operates on S-RLOCs.
• At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site.
• 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.

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 for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in .

Forwarding Procedures with unicast underlay

ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site in addition to the common procedures:

• When the ITR prepends a LISP header, it uses its own RLOC address as the source address and makes one copy for each ETR that has expressed interest in the (S-EID, G). The outer destination IP address is set to that of the corresponding RLOC from which the PIM join was received

ETR Forwarding Procedure When using a unicast underlay, an ETR MUST accept a unicast LISP-encapsulated multicast packet only where the outer destination address is one of its own RLOCs. Additionally, it MAY check whether the outer source address is the ITR RLOC it selected for the (S-EID,G) in question. It MUST discard the packet otherwise.

LISP-Multicast Interworking This section describes the multicast corollary to regarding the interworking of multicast routing among LISP and non-LISP sites.

LISP and Non-LISP Mixed Sites 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 underlay 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:

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

A LISP site enabled for multicast purposes only will not be considered in this document, but a uLISP site as documented in 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.
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.
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.
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.
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.

LISP Source Site to Non-LISP Receiver Sites 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 underlay. 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 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 underlay 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 underlay. So, there is a conflict of behavior between the two types of sites. 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 underlay routing tables. 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 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 underlay 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 ). The existence of mPETRs in the underlay 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.

Non-LISP Source Site to Non-LISP Receiver Sites 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.

Non-LISP Source Site to Any Receiver Site 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 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 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, or it receives a Negative Map-Reply, 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.)

Unicast LISP Source Site to Any Receiver Sites 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 (M Priority, M Weight) per RLOC . The definition and usage of the 2-tuple MUST be done in accordance to the procedure defined in Sec 5.4 of When the M Priority 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 Source Site to Any Receiver Sites 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-NAT techniques with routable addresses would be required in all cases.
• Or, alternatively, mPETR deployment would be required, thus forcing coarse EID-Prefix advertisement in the underlay.
• 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.

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

LISP Sites with Mixed Address Families A LISP database mapping entry that describes the Locator-Set, M Priority, and M Weight 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 M Priority value setting will be relative to an IPv4 or IPv6 RLOC See for packet format details. 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. Some of the combinations that can occur are listed below:

1. LISP-Multicast IPv4 Site
2. LISP-Multicast IPv6 Site
3. LISP-Multicast Dual-Stack Site
4. uLISP IPv4 Site
5. uLISP IPv6 Site
6. uLISP Dual-Stack Site
7. non-LISP IPv4 Site
8. non-LISP IPv6 Site
9. non-LISP Dual-Stack Site

The above 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). To rationalize this combinatorial nightmare, there are some guidelines that need to be put in place:

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

Making a Multicast Interworking Decision Thus far, 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 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.

Considerations When RP Addresses Are Embedded in Group Addresses When ASM is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in an IPv6 group address . 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, underlay 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 underlay. 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.

Taking Advantage of Upgrades in the Underlay If the underlay routers are upgraded to support , then the EID-specific data can be passed through the underlay without, possibly, having to store the state in the underlay. 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.

Mtrace Considerations Mtrace version 2 does not currently define behaviour for LISP-Multicast environments. Defining it is left to future work.

Security Considerations The security concerns for LISP-Multicast are mainly the same as for the base LISP specification and for multicast in general, including PIM-ASM . 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) underlay distribution tree, and a malicious receiver site joins an (S-EID2,G) distribution tree that also maps to the (RLOC1,G) underlay distribution tree, the legitimate sites will receive data from S-EID2 when they did not ask for it. Deployments have been successfully able to leverage existing security mechanisms deployed for PIM

IANA Considerations No requests are made to IANA

Acknowledgments The authors would like to gratefully acknowledge the following individuals for their contributions, discussions, ideas, commentary, and expert reviews during the development of this document: Alia Atlas, Dave Oran, Darren Dukes, Dimitri Papadimitriou, Eric Vyncke, Greg Shepherd, IJsbrand Wijnands, Jari Arkko, Jesus Arango, Ketan Talaulikar, Lenny Guardino, Liming Wei, Luigi Iannone, Marshall Eubanks, Mike McBride, Ron Bonica, Scott Brim, Steve Casner, Toerless Eckert, Tom Pusateri, and Yiqun Cai. The authors also thank the MBONED working group for their constructive verbal feedback, and the Routing Research Group (RRG) of the IRTF where this work originated.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document updates RFC 2710 and obsoletes RFC 3810. The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK] This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK] IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply. This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features. This document obsoletes RFC 6830. This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases. By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced. This document obsoletes RFCs 6830 and 6833. Cisco Cisco This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport, to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router) and to signal the underlay multicast group to the control plane of the root ITR. This document updates RFC 8059 and RFC 9798. Informative References This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK] This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK] This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK] The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations. 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. This document defines an Experimental Protocol for the Internet community. This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community. Cisco Systems

Changes since RFC6831 The major change since is the inclusion of the Unicast underlay. This has been specified in a manner that allows co-existence with the multicast underlay specified in . Other important changes incude:

1. Terminology modernization to maintain consistency with the Standards track LISP RFCs
2. Narrowed scope to include only fully specified multicast modes (PIM-ASM and SSM)
3. Referenced the latest PIM RFCs
4. Deferred MTRACE related specifications
5. Deferred mPITR related specifications
6. Formalized the specification of M Priority and M Weight

Document Change Log [RFC Editor: Please delete this section on publication as RFC.]

Changes to draft-ietf-lisp-rfc6831bis-03

• Posted Nov 2025.
• Address one missing comment from Dino

Changes to draft-ietf-lisp-rfc6831bis-03

• Posted Nov 2025.
• Update document for comments from Luigi as prep for wGLC.

Changes to draft-ietf-lisp-rfc6831bis-02

• Posted July 2025.
• Update document timer and references.
• Update Dave Meyer's email address.

Changes to draft-ietf-lisp-rfc6831bis-01

• Posted January 2025 (Mike McBride).
• Changed all instances of "core" to "underlay".
• Changed "we see" to "there are".
• Changed "RFC" to "document".
• Updated the Requirements Notation.
• Added a reference to RFC 7761 for the RPF definition.
• Removed part of a sentence "...the exit is chosen according to routing policies..."
• Rephrased sentence to: "Multicast state as it is stored in the core is either (S,G) state for sources in non-LISP sites or (RLOC,G) state for sources in LISP sites."
• Added "...or it receives a Negative Map-Reply".
• Added a reference to RFC8487 for MTRACE.
• Moved a few downrefs that needed to be moved to the Informative section.
• Added Mike and Stig to acknowledgements

Changes to draft-ietf-lisp-rfc6831bis-00

• Posted August 2024.
• Make draft-farinacci-lisp-rfc6831bis-02 working group document draft-ietf-lisp-rfc6831bis-00.

Changes to draft-farinacci-lisp-rfc6831bis-02

• Posted May 2024 (Vengada Prasad Govindan).
• Added reference to RFC8059

Changes to draft-farinacci-lisp-rfc6831bis-01

• Posted May 2024 (Vengada Prasad Govindan).
• Add support for unicast underlay in signal-based approach (RFC6831)

Changes to draft-farinacci-lisp-rfc6831bis-00

• Posted May 2024.
• Starting with to move it to a bis document for standards track.
• Changed references to standards track RFCs.
• Address comments from Prasad Govindan.