RFC 6831

The Locator/ID Separation Protocol (LISP) for Multicast Environments

📅 published January 2013, from ietf

RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments 🦋

Okay bestie, gather round 💖 This is RFC 6831, published in January 2013 by D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, all from Cisco Systems ✨ It's an Experimental doc, so it's here for examining, trying things out, and evaluating, not a Standards Track thing 🧪 It's a product of the IETF, with ISSN 2070-1721, and it's all about making LISP work with multicast 🌈

Abstract 🌸

This doc describes how inter-domain multicast routing will work in a world where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. It's giving future-proof vibes 🔮

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published so people can examine it, experimentally implement it, and evaluate it 🧪

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🤓

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6831.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 📖 Any Code Components pulled from this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🍓

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 ✨

Okay so the Locator/ID Separation Protocol [RFC6830] architecture is giving main character energy 💅 It splits up Identification and Location semantics, which are normally crammed together into one IP address 🧩 You get two namespaces: the Endpoint ID (EID) namespace that sites use, and the Routing Locator (RLOC) namespace that core routing uses. Because of that split, the core routing infrastructure can scale by doing topological aggregation of routing information 📈 Iconic, honestly.

Since LISP creates a whole new namespace, there has to be a mapping function that maps a site's EID-Prefixes to their associated Locators 🗺️ For unicast packets, both the source address and the destination address need mapping. For multicast packets, only the source address needs mapping. The destination group address doesn't need to be mapped, because IPv4 and IPv6 group addresses are logical in nature and not topology dependent 🙅‍♀️ So this spec zeroes in on mapping the source EID address of a multicast flow during distribution tree setup and packet delivery 🎯

This spec is going to cover the following scenarios:

  1. How a multicast source host in a LISP site sends multicast packets to receivers inside its own site, and also to receivers in other sites that are LISP enabled 🦋
  2. How inter-domain (between LISP sites) multicast distribution trees get built, and how forwarding of multicast packets leaving a source site toward receiver sites works 🚀
  3. What protocols are affected, and what changes are required to those multicast protocols 🔧
  4. How the ASM-mode (Any Source Multicast), SSM-mode (Single Source Multicast), and Bidir-mode (Bidirectional Shared Trees) service models will operate 🌸
  5. How multicast packet flow happens for the different combos of LISP-enabled and non-LISP-enabled source and receiver sites. For example:
    • A. How multicast packets from a source host in a LISP site get sent to receivers in other sites when they're all non-LISP sites 💀
    • B. How multicast packets from a source host in a LISP site get 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 get sent to receivers in other sites when they're all LISP-enabled sites 🧚
    • D. How multicast packets from a source host in a non-LISP site get sent to receivers in both LISP-enabled sites and non-LISP sites 👑

This spec focuses on what changes are needed in the multicast routing protocols to support LISP-Multicast, along with other protocols used for inter-domain multicast, like Multiprotocol BGP (MBGP) [RFC4760] 🌈 The big selling point is that this approach needs no packet format changes to the protocols and no operational procedural changes to the multicast infrastructure inside a site when all sources and receivers live in that site, even if the site is LISP enabled ✨ So internal multicast operation stays exactly the same, whether or not the site is LISP enabled, and whether or not receivers exist in other LISP enabled sites 🫶

So we only see operational changes (not protocol changes) for PIM-ASM [RFC4601], Multicast Source Discovery Protocol (MSDP) [RFC3618], and PIM-SSM [RFC4607] 🙌 BIDIR-PIM [RFC5015] typically doesn't run in an inter-domain environment, so it isn't covered in depth in this RFC 🙈

This version of the spec also doesn't 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] 💅 More work is needed to nail down the detailed behavior for multicast Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator reachability (Section 6) 🔍 Further deployment and experimentation would also be super useful for understanding the real-life performance of LISP-Multicast. For instance, the design optimizes for minimal state and control traffic in the core, but in some cases it can cause extra multicast traffic to be sent Section 8.1.2. 😭

Issues and concerns about deploying LISP for Internet traffic are discussed in [RFC6830]. Section 12 of that document covers additional issues and concerns raised by this document 🧠

2. Requirements Notation 📝

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] 🫶 Read those words exactly as [RFC2119] defines them, no vibes-based interpretations allowed 🤓

3. Definition of Terms ✨

okay bestie, let's get into the vocab 🎀 the terms here line up with [RFC6830] but get extended so they actually work for multicast routing 🦋

LISP-Multicast 💜 this is just the name for the design in this spec. so if any site that's doing multicast has been upgraded to a LISP site, the control-plane and data-plane protocols running there count as part of the LISP-Multicast architecture 🫶

Endpoint ID (EID) 🌸 an EID is a 32-bit value for IPv4 or a 128-bit value for IPv6, and it shows up in the source address field of the first (most inner) LISP header on a multicast packet. a host gets its destination group address the exact same way it would at a non-LISP site, which is giving consistency 💅 the source EID comes from the same existing mechanisms that set a host's "local" IP address. every EID gets allocated from an EID-Prefix block tied to the site the host lives in. a host can also use an EID to point at another host, like when it joins an SSM (S-EID,G) route with IGMP version 3 [RFC4604] 👀 LISP uses Provider-Independent (PI) blocks for EIDs, and these EIDs MUST NOT be used as LISP RLOCs, so no mixing them up 🙅‍♀️ EID blocks can be handed out in a hierarchical way that doesn't depend on network topology, which helps the mapping database scale 📈 and a site's EID block can also have its own internal structure (subnetting) for routing inside the site. that structure is invisible to the global routing system, so it stays private to the site 🔒

Routing Locator (RLOC) 🧚 an RLOC is an IPv4 or IPv6 address belonging to an Ingress Tunnel Router (ITR), which is the router in the multicast source host's site that does the encapsulating 🎁 it's the output of an EID-to-RLOC mapping lookup, and one EID can map to one or more RLOCs. usually RLOCs come from topologically aggregatable blocks given to a site at each point where it attaches to the global Internet. where the topology is set by provider network connectivity, you can think of RLOCs as Provider-Assigned (PA) addresses ✨ multiple RLOCs can be assigned to one ITR device, or spread across several ITR devices at the same site 🌈

Ingress Tunnel Router (ITR) 🦋 an ITR is a router that takes in an IP multicast packet with a single IP header, meaning an IP packet with no LISP header on it yet. it treats that "inner" IP destination multicast address as opaque, so it doesn't have to do a map lookup on the group address, because that address is topologically insignificant 🙈 the ITR then prepends an "outer" IP header and uses one of its globally routable RLOCs as the source address field. other multicast receiver sites that used the mapping database to join a multicast tree rooted at that ITR know about this RLOC 🫶 generally speaking, an ITR gets IP packets from site end-systems on one side and sends LISP-encapsulated multicast IP packets out every external interface that's been joined 🔥

an ITR would receive a multicast packet from a source inside its own site when 1) it's on the path from the multicast source to internally joined receivers, or 2) it's on the path from the multicast source to externally joined receivers 🧐

Egress Tunnel Router (ETR) 💅 an ETR is a router on the path from a multicast source host in another site to a multicast receiver in its own site. it accepts a PIM Join/Prune message from a site-internal PIM router that's aimed at the source's EID in the multicast source site 🎯 the ETR maps the source EID in that Join/Prune message to an RLOC address using the EID-to-RLOC mapping. that sets the ETR up to accept multicast encapsulated packets from the ITR in the source site 🍓 a multicast ETR decapsulates those packets and replicates them out the interfaces that lead to internal receivers 📦

xTR 🎀 xTR is shorthand for an ITR or ETR when the direction of the data flow isn't part of the context. an xTR is the router that's the tunnel endpoint, and it's used interchangeably with "tunnel router" 💖 for example, "an xTR can be located at the Customer Edge (CE) router" means both ITR and ETR functionality can live on the CE router 🏠

LISP Header 🌷 in this document, LISP Header is a term for the outer IPv4 or IPv6 header, plus a UDP header, plus a LISP header all together 🧁 an ITR prepends these headers and an ETR strips them off. a LISP-encapsulated multicast packet has an "inner" header with the source EID in the source field, and an "outer" header with the source RLOC in the source field. the group address in the destination field is the same globally unique group address in both the inner and outer headers 🌈

(S,G) State 🫧 the formal definition lives in the PIM Sparse Mode [RFC4601] specification. in this spec, the term is used more generally to mean multicast state. depending on where a router sits topologically, its (S,G) state can be either (S-EID,G) state (where that state lives at a site) or (S-RLOC,G) state (in the Internet core) 🗺️

(S-EID,G) State 🏡 this 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 show up in an IGMPv3 report, an MSDP SA message, or a PIM Join/Prune message that travels inside a site 💌

(S-RLOC,G) State 🌍 this refers to multicast state in the core, where S is a source locator, meaning the IP address of a multicast ITR at a site with a multicast source 🛰️ the (S-RLOC,G) entry gets mapped from the (S-EID,G) entry by doing a mapping database lookup for the EID-Prefix that the S-EID maps to. an S-RLOC can appear in a PIM Join/Prune message when that message travels from an ETR to an ITR across the Internet core 🚀

uLISP Site 🥹 a uLISP Site is a unicast-only LISP site under [RFC6830] that hasn't deployed the procedures in this spec. so for multicast purposes it follows the procedures from Section 9 📜 a uLISP site can be a traditional multicast site, no shade 💜

LISP Site ✨ a LISP Site is a unicast LISP site (uLISP Site) that's also multicast capable according to the procedures in this spec. it's the upgraded version, and we love a glow-up 💅

mPETR 👑 this is a multicast proxy-ETR. it's responsible for advertising a very coarse EID-Prefix, which is the thing non-LISP and uLISP sites target their (S-EID,G) PIM Join/Prune messages at 🎯 mPETRs exist so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. they act as Proxy-ETRs to support multicast routing in a LISP infrastructure 🧚 it's likely that a uPITR [RFC6832] and an mPETR get co-located, since one device advertises that coarse EID-Prefix in the underlying unicast routing system. two jobs, one device, very efficient 🙌

Mixed Locator-Sets 🌸 a Mixed Locator-Set 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 that's LISP-encapsulated with destination UDP port 4341. ETRs at multicast receiver sites send it to an ITR at a multicast source site 📨 it gets sent periodically for as long as there are interfaces in the OIF-list for the (S-EID,G) entry that the ETR is joining 🔁

OIF-list 📋 this is notation for the outgoing interface list a multicast router stores per multicast routing table entry, so it knows which interfaces to replicate multicast packets out of 🦋

RPF 🌊 Reverse Path Forwarding is a procedure that multicast routers use. a router will accept a multicast packet for forwarding if the packet arrived on the path the router would use to forward unicast packets back toward that packet's source. it's giving "check your route before you trust the stranger" 😤💅

4. Basic Overview ✨

okay so bestie, LISP for unicast routing gives a site way more say over its ingress traffic (the stuff coming in) 🌸. Egress (the stuff going out) is still handled by the IGP in the source site. For multicast, the IGP plus PIM decides which path multicast packets take to come in 🧚. 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 in a mapping database entry, a source multicast site can control which way its multicast receiver sites join back to the source site 👑.

right now there is no requirement for Locator-Sets, priority, and weight policies to be different for multicast than they are for unicast 🎀. BUT when the Traffic Engineering policies differ between unicast and multicast flows, it will be super desirable to use multicast-based priority and weight values in Map-Reply messages 🫶.

the fundamental multicast forwarding model is to encapsulate a multicast packet inside another multicast packet 🦋. An ITR encapsulates the multicast packets it gets from the sources it serves in a LISP-Multicast header 💖. The destination group address from the inner header gets copied into 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 follows this high-level protocol and operational sequence, and it's giving clean 🔥:

  1. Receiver hosts in multicast sites join multicast content the way they always do, using IGMP 🙈. When they use IGMPv3 and specify source addresses, they use source EIDs, so 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. 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 uses the RLOC information from that mapping 🍓.

The ETR uses the same priority and weighting mechanism as it does for unicast 🦋. So the source site gets to decide which way multicast packets egress 👑.

  1. The ETR builds two PIM Join/Prune messages 📬. One contains an (S-EID,G) entry and is unicast to the ITR that matches the RLOC the ETR selected. The other contains an (S-RLOC,G) entry, so the core network can create multicast state from this ETR to the ITR 💜.
  2. When the ITR gets the unicast Join/Prune message (see Section 3 for the formal definition), it processes the (S-EID,G) entries in the message and propagates them inside 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 processes it like any other join it would get on today's Internet 🎀. The S-RLOC address is the IP address of this ITR ✨.
  3. At this point, there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of that site 🫶. There is (S-RLOC,G) state across the core network from the ETR of the receiver multicast site to the ITR in the source multicast site, and (S-EID,G) state in the source multicast site 🌈. Heads up, 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 packet replication happens in the core) or through a different ITR (in which case packet replication happens at the source site) 🧚.
  4. When a packet comes from the multicast host in the source site, it flows to one or more ITRs that prepend a LISP header 💅. By copying the group address into the outer destination address field, the ITR puts its own locator address in the outer source address field 💖. The ITR looks at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicates the packet on each interface where an (S-RLOC,G) join was received 🦋. The core has (S-RLOC,G), so wherever fan-out to multiple sites happens, a core router does the packet replication 👑.
  5. When either the source site or the core replicates the packet, the ETR receives a LISP packet with a destination group address 🙈. It decapsulates the packets because it has receivers for the group. Otherwise, it would never have received them, 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 the packets out one or more interfaces, delivering them to the internal receivers 🎀.

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

ALSO, [RFC6830] has another mechanism where (S-EID,G) state can live in the core through the use of RPF Vectors [RFC5496] in PIM Join/Prune messages 🧚. BUT few PIM implementations support RPF Vectors, so LISP should avoid S-EID state in the core 💀. See Section 5 for details 💅.

ngl this is where it gets a little messy. The control plane can scale, but the cost is sending data to sites that may not have joined the distribution tree that the encapsulated data is being delivered on 😭. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs live in the same multicast source site 🙈. Both multicast receiver sites join the same ITR, which holds (S-RLOC,G) state where S-RLOC is the RLOC for that ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside the site 💜. The ITR receives the (S-RLOC,G) joins and fills in 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), the core delivers packets to both multicast receiver sites, even though each one joined a single source-based distribution tree 💀. This behavior is a consequence of the many-to-one mapping between S-EIDs and an S-RLOC 😤.

there is a possible fix for this that cuts down on the number of many-to-one cases where (S-EID,G) entries pile into a single (S-RLOC,G) entry 🦋. If a physical ITR can be assigned multiple RLOC addresses and those addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options 🫶. That means they can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site 🌸. A strict 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 would not scale 😭. But "n" can drop to a smaller number in the "n-to-1" relationship 🔥. And in turn, that reduces the chances of data packets being delivered to sites for groups they never joined 💖.

5. Source Addresses versus Group Addresses 💅

multicast group addresses don't have to be tied to either the EID or the RLOC namespace 🌈. They're actually a namespace of their own, which can be treated as logical with fairly opaque allocation 🧚. So by their nature, they don't get in the way of an incremental deployment of LISP-Multicast 🫶.

as for source addresses, just like the unicast LISP scenario, identification gets decoupled from location 🦋. In a LISP site, packets come from hosts using their allocated EIDs 🎀. EID addresses are used to identify the host and to show where the host sits in the site's topology, but NOT how and where it's attached to the Internet 💅. (lowercase "not" here, obviously, it's just the vibe 😉)

so when multicast distribution tree state gets created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is kept at the source and receiver multicast sites, and RLOC state is kept in the core 👑. In other words, a multicast distribution tree is represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} ✨. The first element is the state stored in routers from the source to one or more ITRs in the source multicast site 💖. The second element is the state stored in routers downstream of the ITR, in the core, reaching all LISP receiver multicast sites 🍓. The third element is the state stored in 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 the mapping from the second element to the third element is done at the ETRs 🔥.

6. Locator Reachability Implications on LISP-Multicast 🦋

multicast state as it's stored in the core is always either (S,G) state, the way it exists today, or (S-RLOC,G) state, the way it will exist once LISP sites are deployed 🌈. The core routers can't tell one from the other 🧚. They don't need to, because it's 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 sits 👑. 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 gets 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 uses the same algorithm an ITR would use to pick 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 pretty easily using local reachability state 🌸. BUT in the multicast case, when an ITR becomes unreachable, new distribution tree state has to be built, because the encapsulating root has changed 😭. This is a bigger deal than an RPF-change event, where any router would typically change its RPF-interface locally for its existing tree state 💀. When an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be built and must reflect the new encapsulator 🔥. So when an ITR goes unreachable, all ETRs currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR, AND 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 reduces to an RPF change in the core 🫶. It still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G) 💜. The catch is that the ETR really doesn't know when the ITR has changed, so the new anycast ITR only gets the (S-EID,G) state when the ETR sends it again during its periodic sending procedures 😭✨.

7. Multicast Protocol Changes 🎀

okay so there are a bunch of protocols doing inter-domain multicast routing today, and they all need a little check-in. 💅

  • IGMPv1-v3, MLDv1-v2: these ([RFC4604]) need zero changes for LISP-Multicast, and there are two reasons this is giving easy mode 🫶. First, they're link-local and never used over site boundaries. Second, they advertise group addresses that don't need translating. When source addresses show up in IGMPv3 and Multicast Listener Discovery version 2 (MLDv2) messages, they're semantically EIDs, so they don't get converted to RLOCs until the multicast tree-building protocol (like PIM) reaches the ETR at the site boundary. And the addresses used for IGMP and MLD come out of the source site's allocated addresses, which means they're from the EID namespace 🌸.
  • MBGP: the Multiprotocol Extensions for BGP-4 (MBGP) ([RFC4760]) aren't technically a multicast routing protocol, but they're used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology aren't congruent 👀. In a LISP-Multicast environment, the prefixes that get advertised are from the RLOC namespace, which lets receiver multicast sites find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace too. Bottom line: there are no MBGP changes required to support LISP-Multicast ✨.
  • MSDP: MSDP ([RFC3618]) is how active multicast sources get announced to other routing domains (or LISP sites) 📣. The announcements come from the PIM Rendezvous Points (RPs) in sites with active multicast sources sending to various groups. With LISP-Multicast, the source addresses advertised in MSDP are semantically from the EID namespace, since they describe the identity of a source multicast host. The state stored in MSDP caches on core routers will also be from the EID namespace. An RP address inside the site is from the EID namespace so it can be advertised and reached by an internal unicast routing mechanism. BUT, for MSDP peer-RPF checking to work across sites, those RP addresses have to be converted or mapped into a routable address that's 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. The choice can be made unilaterally, because the ITR at the site figures out which namespace the destination peer address is from 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 gets built and maintained across site boundaries 🌈. In this case there's a small tweak to how PIM Join/Prune messages are sent by the LISP-Multicast component. No message formats get modified. What changes is that a Join/Prune message originated inside a LISP site, with embedded addresses from the EID namespace, has to have those addresses converted to addresses from the RLOC namespace when it crosses a site boundary. This is similar to the requirements documented in [RFC5135] 🫧.
  • BIDIR-PIM: Bidirectional PIM ([RFC5015]) is typically run inside a single routing domain, but if you deploy it inter-domain, you have to decide whether the RP address of the shared tree comes from the EID namespace or the RLOC namespace 🤔. If the RP lives in a site-based router, the RP address is from the EID namespace. If the RP lives in the core, where RLOC addresses are routed, the RP address is from the RLOC namespace. This is easy to tell apart if the EID address sits in a well-known address allocation block from the RLOC namespace. When using Embedded-RP for RP determination ([RFC3956]), the format of the group address can indicate which namespace the RP address is from. However, refer to Section 10 for the 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. That lets core routers associate a Bidir group's RP address with an ITR's RLOC address, and lets site routers associate the Bidir group's RP address as an EID address 🧚. As for Designated Forwarder (DF) election in BIDIR-PIM, no changes are required, since all messaging and addressing is link-local.
  • PIM-ASM: the ASM mode of PIM ([RFC4601]), the most popular form of PIM, is deployed on the Internet today by using shared trees within a site and source trees across sites 🍓. Through MSDP and the PIM-SSM techniques described above, multicast connectivity can happen across LISP sites. Having said that, this 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 lives in the site. 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 🧠. That makes 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 for a multicast source host to send multicast packets, or for a multicast receiver host to receive multicast packets 🙌.

8. LISP-Multicast Data-Plane Architecture 🦋

The LISP-Multicast data plane follows the operation and packet formats specified in [RFC6830]. The big difference is that encapsulating a multicast packet at an ITR is a much simpler process 💅. You just copy the inner group address into the outer destination address, and the ITR uses its own IP address (its RLOC) as the source address. It's simpler for multicast because no EID-to-RLOC mapping lookup happens during packet forwarding 🫶.

On the decapsulation side, the ETR simply strips the outer header and does 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 onto the site-facing interfaces that lead to multicast receiver hosts.

There's no Data-Probe logic for ETRs, unlike the unicast forwarding case 🙈.

8.1. ITR Forwarding Procedure

Here's the procedure an ITR follows when it receives a multicast packet from a source inside 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. The group information is assumed to be obtained by current methods. The same goes for a multicast receiver getting the source and group address of a multicast flow 🎀.
  2. When the ITR receives a multicast packet, it has both S-EID state and S-RLOC state stored. Since the packet came in on a site-facing interface, the RPF lookup is based on the S-EID state 🔍. If the RPF check succeeds, the OIF-list contains interfaces that are site facing and external facing. Site-facing interfaces get no LISP header prepended. External-facing interfaces get a LISP header prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address, and copies the group address from the IP header the host built into the outer destination address 💖.

8.1.1. Multiple RLOCs for an ITR

Typically an ITR has a single RLOC address, but sometimes there can be multiple RLOC addresses assigned from the same or different service providers 🌍. In that case, when (S-RLOC,G) Join/Prune messages come in for each RLOC, an OIF-list merging action has to happen 🧩. So when a packet arrives from a site-facing interface and matches an (S-EID,G) entry, the interfaces from the OIF-list of all (RLOC,G) entries joined to the ITR, along with the site-facing OIF-list joined for (S-EID,G), must be included in packet replication. On top of replicating for all types of OIF-lists, each OIF-list entry must be tagged with the RLOC address, so the encapsulation uses the outer source address for the RLOC that was joined 🫧.

8.1.2. Multiple ITRs for a LISP Source Site

Here's a fun one 😭. When ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site because of policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In that case, the same (S-EID,G) is realized by different (S-RLOC,G) state in the core. This won't result in duplicate packets, because each ITR in the multicast source site chooses its own RLOC for the source address of encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs 🌸.

When different (S-EID,G) traffic gets combined into a single (RLOC,G) core distribution tree, traffic can end up going to a receiver multicast site that doesn't need it 🙅‍♀️. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi), and another receiver multicast site joins (S2-EID,Gi) through that same core distribution tree of (RLOC1,Gi). When ETRs decapsulate this traffic, they should know from their local (S-EID,G) state whether the packet should be forwarded 🕵️‍♀️. If there's no (S-EID,G) state that matches the inner packet header, the packet is discarded 🗑️.

8.2. ETR Forwarding Procedure

Here's how an ETR handles a multicast packet from a source outside its site 💜:

  1. When an ETR receives a multicast data packet on an external-facing interface, it does 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 its site 🌐). When the packet is 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 🎁.
  2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site 🌷.

8.3. Replication Locations

okay so multicast packets can get copied (replicated) in a few different spots in the topology, bestie 🌸:

  • in an IGP multicast router inside a site that works with S-EIDs ✨
  • in a transit multicast router inside the core that works with S-RLOCs 🦋
  • at one or more ETR routers, depending on which path a Join/Prune message leaves a receiver multicast site through 🫶
  • at one or more ITR routers in a source multicast site, depending on what priorities come back in a Map-Reply to receiver multicast sites 💅

in that last case, the source multicast site can do the replicating instead of having just one exit from the site 🔥 but this only happens when the priorities in the Map-Reply get changed for different receiver multicast sites, so that the PIM Join/Prune messages land on different ITRs. it's giving precision 💖

this policy trick is also used for unicast in [RFC6836], and for multicast it helps deal with the problems of changing distribution tree state that we talked about in Section 6. literally genius 👑

9. LISP-Multicast Interworking 🎀

this section is the multicast version of [RFC6832], all about how multicast routing works between LISP sites and non-LISP sites. we're going full group chat now 🍓

9.1. LISP and Non-LISP Mixed Sites

ngl this one is a little more involved, because multicast can have more than two entities talking together, so the possible interworking combos multiply 😭 the good news is that the distribution tree state kept at the sites is the same whether or not a site is LISP enabled. so most of the real implications live in the core, when it comes to storing routable EID-Prefixes from either PA or PI blocks 🌈

before we list the multicast interworking scenarios, let's define three deployment states a site can be in:

  • a non-LISP site that runs PIM-SSM or PIM-ASM with MSDP, just like it does today. its addresses are globally routable 🧚
  • a site that uses LISP for unicast routing. its addresses are not globally routable. let's call this kind of site a uLISP site 💜
  • a site that uses LISP for both unicast and multicast routing. its addresses are not globally routable. let's call this kind of site a LISP-Multicast site ✨

a LISP site that's enabled for multicast only won't be covered in this document 🙈 but a uLISP site, as described in [RFC6832], will be. this section also doesn't go over how a LISP site sends multicast packets when every receiver site is LISP-Multicast enabled, because we already covered that in the earlier sections 💅

these are the scenarios that 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. 👑

9.1.1. LISP Source Site to Non-LISP Receiver Sites

in the first scenario, a site is LISP enabled for both unicast and multicast traffic, so it works on EIDs. that means the EID-Prefix block might not be routable in the core 😭 for LISP receiver multicast sites this is no biggie, but for non-LISP or uLISP receiver multicast sites it's a problem. when a PIM Join/Prune message reaches the edge router, the router has no route to push that Join/Prune message out of the site. this is the same situation as the unicast case that LISP Network Address Translation (LISP-NAT) in [RFC6832] fixes 💖

LISP-NAT lets a unicast packet leaving a LISP site get its source address mapped to a globally routable address, before the ITR works out that it shouldn't encapsulate a packet headed to a non-LISP site ✨ for a multicast packet to leave a LISP site, distribution tree state has to exist so the ITR knows where to send it 🧚 so the receiver multicast sites need to know the multicast source host by its routable address, not its EID address. when that's the case, the routable address is the (S-RLOC,G) state that gets stored and maintained in the core routers 🦋 it's important to note that the host's routable address can't be the same as an RLOC for the site, because ITRs need to be able to process a PIM Join/Prune message that comes in on an external-facing interface 🌈 if the message gets propagated inside the site, then the site-part of the distribution tree gets built 🎀

using a globally routable source address lets non-LISP and uLISP multicast receivers join, create, and maintain a multicast distribution tree 💅 but the LISP-Multicast receiver site will want to do an EID-to-RLOC mapping table lookup whenever a PIM Join/Prune message comes in on a site-facing interface 😭 it does this because it wants to find an (S-RLOC,G) entry to Join in the core. so the two types of sites end up with a conflict of behavior 💀

the fix here is the same as when an ITR wants to send a unicast packet to a destination site but has to figure out whether that site is LISP enabled or not. when the site isn't LISP enabled, the ITR doesn't encapsulate the packet. so for the multicast case, when the ETR gets a PIM Join/Prune message for (S-EID,G) state, it does a mapping table lookup on S-EID. in this case S-EID isn't 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 just pass the PIM Join/Prune message along to an external-facing interface, without converting the (S-EID,G), because it's an (S,G) where S is routable and reachable through the core routing tables 👑

now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, we can explain how the packet forwarding model works 🍓

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 🙈 so the ITR has no reason to encapsulate data. it knows a priori (through configuration) that its site's EIDs aren't routable and aren't registered in the mapping database system, so it assumes the multicast packets from the source host are sent with a routable address. that means it's up to the multicast source host's system administrator to make sure the source host sends multicast traffic with a routable source address 🫶 when this happens, the ITR just acts like a router and forwards the multicast packet like any ordinary multicast router 🦋

there's an alternative to the LISP-NAT approach, the same way there's an alternative to unicast [RFC6832] forwarding using Proxy Tunnel Routers (PxTRs) 🧚 this can work for multicast routing in the same way, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) that travel through the core to multicast PxTRs. let's call a PxTR used this way a "Multicast Proxy-ETR" (or mPETR) 💖 since mPETRs advertise very coarse EID-Prefixes, they attract the PIM Join/Prune control traffic, which makes them the target of the distribution tree ✨ to get multicast packets from LISP source multicast sites, the tree has to be built on the path from the mPETR to the LISP source multicast site 🌈 to make that happen, the mPETR acts as a "Proxy-ETR" (where in unicast it acts as a "Proxy-ITR", or a uPITR [RFC6832]) 👑

the mPETRs in the core let source multicast site ITRs encapsulate multicast packets according to (S-RLOC,G) state 🎀 that (S-RLOC,G) state gets built from the mPETRs to the multicast ITRs 🦋 then the mPETRs decapsulate the encapsulated multicast packets and forward them according to (S-EID,G) state 💅 and that (S-EID,G) state gets 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

obviously non-LISP-Multicast sites can send multicast packets to non-LISP receiver multicast sites. that's what they already do today 🙈 but we still need to show how non-LISP-Multicast sites send multicast packets to uLISP receiver multicast sites 🍓

since uLISP receiver multicast sites aren't the target of any (S,G) state, they just send (S,G) PIM Join/Prune messages toward the non-LISP source multicast site 🧚 and because the source multicast site in this case hasn't been upgraded to LISP, all multicast source host addresses are routable 💜 so this case simplifies down to a uLISP receiver multicast site looking, from the source multicast site's point of view, just like a non-LISP receiver multicast site ✨

9.1.3. 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, we need to decide how the LISP receiver multicast site attaches to the distribution tree 🌈 we know 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 needs to know whether the source address of the multicast source host is routable or not 👑 we showed 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 decide whether to convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface into an (S-RLOC,G) 🎀 if the lookup fails, the ETR can conclude the source multicast site is a non-LISP site, so it just forwards the Join/Prune message 💅 (it also doesn't need to send a unicast encapsulated Join/Prune message, because there's no ITR in a non-LISP site and there's namespace continuity between the ETR and the source 🙈)

for a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network by using multicast proxy-ITRs (mPITRs) 🦋 the mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast sites and uLISP sites, and encapsulate them to ETRs in receiver multicast sites or to mPETRs, which can decapsulate them for non-LISP receiver multicast sites 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 need to be configured with the mPITR's RLOC addresses, so they can send (S-RLOC,G) joins to build a distribution tree to the mPITR, and also be configured to send unicast joins to mPITRs so the mPITRs can propagate (S-EID,G) joins into source multicast sites ✨ the use of mPITRs is still being studied and is a work in progress 🌸

9.1.4. Unicast LISP Source Site to Any Receiver Sites 🦋

okay so, last section we covered how an ETR in a multicast receiver site can check the mapping database to see if the source multicast site is LISP enabled 👀. when the source multicast site is a uLISP site, it IS LISP enabled, but the ITR (by definition) can't do multicast encapsulation 😭. so for multicast routing purposes, a uLISP source multicast site gets treated like a non-LISP source multicast site 💅

non-LISP receiver multicast sites can join distribution trees to a uLISP source site, bc from a forwarding perspective the source site acts like a non-LISP source site ✨. same deal for a uLISP receiver multicast site, bc its ETR doesn't have multicast functionality built in or turned on 🙈

now the tricky part: LISP receiver multicast sites. they think the source multicast site is LISP enabled, so the ETR literally can't tell if the ITR is LISP-Multicast enabled 💀. to fix this, each mapping database entry has a multicast 2-tuple (Mpriority, Mweight) per RLOC [RFC6830]. when Mpriority is set to 255, the site is considered not multicast capable 🚫. so an ETR in a LISP receiver multicast site can tell 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 🌸

okay this one is giving drama 🎭. when a LISP source multicast site has receivers in LISP, non-LISP, AND uLISP receiver multicast sites, it has a conflict about how to send multicast packets 😩. the ITR can either encapsulate or natively forward multicast packets, but the receiver sites behave differently, so ONE packet-forwarding mechanism can't satisfy everybody 💔

BUT, if a LISP receiver multicast site acts like a uLISP site, then it could receive packets like a non-LISP receiver site, and suddenly every receiver site behaves the same (homogeneous) ✨. the catch is that this creates some 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 core.
  • But, what is most disturbing is that when all the participating sites are LISP-Multicast sites and a non-LISP or uLISP site joins the distribution tree, the already-joined LISP receiver multicast sites would have to change their behavior 😱. that 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 encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites, and another 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.

9.2. LISP Sites with Mixed Address Families 🌈

okay so a LISP database mapping entry describes the Locator-Set, Mpriority, and Mweight per locator address (RLOC) for an EID-Prefix tied to a site. those RLOC addresses could be IPv4 OR IPv6 format 👑. when a mapping entry has a MIX of RLOC-formatted addresses, that's an implicit advertisement that the site is dual-stack, meaning it can receive IPv4 or IPv6 unicast packets 💖

to tell whether the site can receive dual-stack unicast packets AND dual-stack multicast packets, the Mpriority value setting is relative to an IPv4 or IPv6 RLOC. See [RFC6830] for packet format details 🧚

now if you mix LISP, non-LISP, and uLISP sites sharing the same distribution tree, PLUS think about whether each one supports IPv4, IPv6, or dual-stack... the number of combinations grows beyond comprehension 💀💀

using some combinatorial math, here are the profiles of a site and the combinations that can happen:

  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

let's define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" 🍓. when 1 site talks to another site, the combinatorial is (9 2). when 1 site talks to another 2 sites, the combinatorial is (9 3). if we sum this all the way up to (9 9), we get:

(9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

  36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

which results in 502 as the total number of cases to consider 😵‍💫

and it gets even worse when a site uses one address family inside the site while its xTRs use the other address family (like IPv4 EIDs with IPv6 RLOCs, or IPv6 EIDs with IPv4 RLOCs) 🙃

so to rationalize this combinatorial nightmare, we need some guidelines 📝:

  • Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. that means head-end replication can be avoided by building and sending packets on each address-family-based distribution tree ✨. there might be an urge to do multicast packet translation from one address family format to the other, but that's 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, 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 whether the source site is LISP-Multicast or uLISP enabled. that means priority-based policy modification is prohibited 🚫. when a receiver multicast site ETR receives an (S-EID,G) join, it must select an 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, figuring out the address family for the flow is up to how receivers find the source and group information for a multicast flow 🔍

9.3. Making a Multicast Interworking Decision 🧠

okay recap: so far, Section 9 has shown ALL the combinations of multicast connectivity that could happen 🌀. as we already concluded, this is super complicated, and if the design is too ambitious, the protocol dynamics could cause a LOT of instability 📉

the trade-off decisions are hard to make 😤, so we want the SAME single solution to work for both IPv4 and IPv6 multicast. it's imperative to have an incrementally deployable solution covering all of IPv4 unicast and multicast and IPv6 unicast and multicast, while minimizing (or eliminating) both unicast and multicast EID namespace state 🫶

so the design decision is to go with uPITRs [RFC6832] for unicast routing and mPETRs for multicast routing 🌟. this seems to be the sweet spot in the solution space for optimizing state requirements and avoiding head-end data replication at ITRs 👑

10. Considerations When RP Addresses Are Embedded in Group Addresses ✨

okay so when ASM and PIM-BIDIR are used in an IPv6 inter-domain environment, there's a technique to embed the unicast address of an RP inside an IPv6 group address [RFC3956] 🧚. when routers in end sites process a PIM Join/Prune message containing an Embedded-RP group address, they pull the RP address out of the group address and treat it as part of the EID namespace. but core routers don't have state for the EID namespace, so they need to pull the RP address out of the RLOC namespace instead 😬

which means it's the responsibility of ETRs in multicast receiver sites to map the group address into one where the Embedded-RP address is from the RLOC namespace 💅. the mapped RP address comes 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's resident RP to the ITR gets created 🌈

this technique is no different from the techniques 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 gets mapped, because it contains unicast addresses encoded in an Embedded-RP group address 🦋

11. Taking Advantage of Upgrades in the Core 🚀

if the core routers are upgraded to support [RFC5496], then EID-specific data can pass through the core without, possibly, having to store state in the core ✨

by doing this, you can eliminate the ETR from unicast encapsulated PIM Join/Prune messages to the source site's ITR 🙌

BUT, this solution is restricted to a small set of workable cases, so it wouldn't be good for general use of LISP-Multicast 🥲. plus, because of its slow convergence properties, it is not recommended for LISP-Multicast 🐌

12. Mtrace Considerations 🔎

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

the design for mtrace in LISP-Multicast environments is still to be determined 🚧, but it should build upon mtrace version 2 specified in [MTRACE] 🫶

13. Security Considerations 💀

⚠️ okay, read this one carefully, bestie, it matters 🥺

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 an (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 even though they never asked for it 😱😱

other than what's noted above, there are currently no known security differences between multicast with LISP and multicast without LISP ✅. HOWEVER, this topic hasn't been investigated deeply so far, so additional issues might come up in the future 👀

14. Acknowledgments ✨

okay bestie, the authors gave SO many shoutouts and I'm not going to skip a single one 🫶 First, huge thanks to the expert reviewers Scott Brim, Greg Shepherd, and Dave Oran 💅 The chats from the Summer 2008 IETF in Dublin also gave us Toerless Eckert and IJsbrand Wijnands 🍓

The authors also thanked the MBONED working group 🌸 for the constructive and civil verbal feedback when this doc was presented at the Fall 2008 IETF in Minneapolis. The standouts were Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko 👑

An expert review was done by Yiqun Cai and Liming Wei, and the authors thank them for their detailed comments 🎀

Last but not least, this work started in the Routing Research Group (RRG) of the IRTF 🌈 It was an individual submission that got converted into a LISP working group document. Iconic glow-up 🦋

15. References

15.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜
  • [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.
  • [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
  • [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. ✨
  • [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.
  • [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
  • [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.
  • [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
  • [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. 🦋
  • [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.

15.2. Informative References

  • [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.
  • [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.

Authors' Addresses 💖

Dino Farinacci Cisco Systems Tasman Drive San Jose, CA USA

EMail: farinacci@gmail.com

Dave Meyer Cisco Systems Tasman Drive San Jose, CA USA

EMail: dmm@cisco.com

John Zwiebel Cisco Systems Tasman Drive San Jose, CA USA

EMail: jzwiebel@cruzio.com

Stig Venaas Cisco Systems Tasman Drive San Jose, CA USA

EMail: stig@cisco.com

📦 where this page comes from