RFC 8378

Signal-Free Locator/ID Separation Protocol (LISP) Multicast

📅 published May 2018, from ietf

RFC 8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast 🦋

okay bestie, this is RFC 8378, and it's giving IETF energy 💅 It was written by V. Moreno of Cisco Systems and D. Farinacci of lispers.net. It's an Experimental document (category: Experimental, ISSN: 2070-1721), published in May 2018 🌸 The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

okay so when multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. but when multicast isn't available to connect the multicast sites together, a signal-free mechanism can be used to let traffic flow between sites 🦋 this doc describes a mechanism that uses unicast replication and encapsulation over the core network for the data plane. it also uses the LISP mapping database system, so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. literally iconic 💖

Status of This Memo 📜

this document is not an Internet Standards Track specification. it's published for examination, experimental implementation, and evaluation 🧪

it defines an Experimental Protocol for the Internet community. it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). not every document the IESG approves is a candidate for any level of Internet Standard. see Section 2 of RFC 7841 for that 🎀

if you want info about the current status of this document, any errata, or how to give feedback on it, check https://www.rfc-editor.org/info/rfc8378 🔍

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. all rights reserved. 🔒

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚠️

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
4.  Reference Model . . . . . . . . . . . . . . . . . . . . . . .   6
5.  General Procedures  . . . . . . . . . . . . . . . . . . . . .   7
  5.1.  General Receiver-Site Procedures  . . . . . . . . . . . .   8
    5.1.1.  Multicast Receiver Detection  . . . . . . . . . . . .   8
    5.1.2.  Receiver-Site Registration  . . . . . . . . . . . . .   9
    5.1.3.  Consolidation of the Replication List . . . . . . . .  10
  5.2.  General Source-Site Procedures  . . . . . . . . . . . . .  10
    5.2.1.  Multicast Tree Building at the Source Site  . . . . .  10
    5.2.2.  Multicast Destination Resolution  . . . . . . . . . .  11
  5.3.  General LISP Notification Procedures  . . . . . . . . . .  11
6.  Source-Specific Multicast Trees . . . . . . . . . . . . . . .  12
  6.1.  Source Directly Connected to Source-ITRs  . . . . . . . .  12
  6.2.  Source Not Directly Connected to Source-ITRs  . . . . . .  12
7.  Multihoming Considerations  . . . . . . . . . . . . . . . . .  13
  7.1.  Multiple ITRs at a Source Site  . . . . . . . . . . . . .  13
  7.2.  Multiple ETRs at a Receiver Site  . . . . . . . . . . . .  13
  7.3.  Multiple RLOCs for an ETR at a Receiver Site  . . . . . .  14
  7.4.  Multicast RLOCs for an ETR at a Receiver Site . . . . . .  14
8.  PIM Any-Source Multicast Trees  . . . . . . . . . . . . . . .  15
9.  Signal-Free Multicast for Replication Engineering . . . . . .  16
10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
  12.1.  Normative References . . . . . . . . . . . . . . . . . .  19
  12.2.  Informative References . . . . . . . . . . . . . . . . .  20
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

okay so when multicast sources and receivers are active at LISP sites, and the core network between those sites doesn't provide multicast support, a signal-free mechanism can be used to create an overlay. that overlay lets multicast traffic flow between sites and connects the multicast trees at the different sites 🌈

this mechanism does not extend PIM [RFC7761] over the overlay the way [RFC6831] proposes. it also doesn't use direct signaling between the Receiver-ETRs and Sender-ITRs like [LISP-MULTI-SIGNALING] describes. instead, it cuts the amount of signaling between sites down to a minimum. the big idea is registering receiver sites for a particular multicast group or multicast channel with the LISP mapping system 💖

registrations from the different receiver sites get merged at the mapping system. this builds a multicast-replication-list that includes all of the Routing Locators (RLOCs) leading to receivers for a particular multicast group or multicast channel. each specific multicast entry's replication list is kept as a database mapping entry in the LISP mapping system 🗺️

when the Ingress Tunnel Router (ITR) at the source site gets multicast traffic from sources at its site, the ITR can query the mapping system by sending Map-Request messages for the (S,G) source and destination addresses in the packets it received. the mapping system returns the RLOC replication list to the ITR, and the ITR caches it following standard LISP procedure. because the core is assumed not to support multicast, the ITR replicates the multicast traffic for each RLOC on the replication list and unicast encapsulates the traffic to each RLOC. this combined function of replicating and encapsulating traffic to the RLOCs in the replication list is referred to as "rep-encapsulation" in this document 🫶

the document describes the general procedures (Section 5) and the information encoding that are needed at receiver sites and source sites to get signal-free multicast interconnectivity. it also describes the general procedures for mapping system notifications to different sites. there's a section on the specific case of Source-Specific Multicast (SSM) trees, which talks about how the general procedures change for SSM trees across different topological scenarios. and there's a section on Any-Source Multicast (ASM) support that identifies the constraints that come with supporting it using LISP signal-free multicast 🎀

last but not least, there's a section on Replication Engineering, which is a mechanism for reducing the impact of head-end replication. using LISP signal-free mechanisms, the mapping system can be used to build a layer of Re-encapsulating Tunnel Routers (RTRs) 🧚

2. Definition of Terms 📚

bestie, the LISP-related terms Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and Map-Resolver (MR) are all defined in the LISP specification [RFC6830] 🙌

the extensions to those definitions for multicast routing are documented in [RFC6831] 🔁

terms about how things interact with the LISP mapping system are defined in [RFC6833] 🗂️

the following terms are consistent with the definitions in [RFC6830] and [RFC6831]. they're specific cases of the general terms, defined here so the descriptions and discussions in this particular document are easier to follow 💅

Source: Multicast source endpoint. the host that originates multicast packets.

Receiver: Multicast group member endpoint. the host joins a multicast group as a receiver of multicast packets sent to the group.

Receiver site: LISP site where multicast receivers are located.

Source site: LISP site where multicast sources are located.

RP site: LISP site where an ASM PIM Rendezvous Point (RP) [RFC7761] is located. the RP site and the source site MAY be the same in some situations 👀

Receiver-ETR: LISP decapsulating Tunnel Router (xTR) at the receiver site. this is a multicast ETR.

Source-ITR: LISP encapsulating xTR at the source site. this is a multicast ITR.

RP-xTR: LISP xTR at the RP site. this is typically a multicast ITR.

Replication list: Mapping-entry containing the list of RLOCs that have registered receivers for a particular multicast entry.

Multicast entry: A tuple identifying a multicast tree. multicast entries are in the form (S-prefix, G-prefix) ✨

Rep-encapsulation: The process of replicating and then encapsulating traffic to multiple RLOCs.

Re-encapsulating Tunnel Router (RTR): An RTR is a router that implements the re-encapsulating tunnel function detailed in Section 8 of the main LISP specification [RFC6830]. a LISP RTR does packet re-routing by chaining ETR and ITR functions. it first removes the LISP header of an ingress packet, and then prepends a new LISP header to an egress packet 🔄

RTR Level: An RTR level is encoded in a Replication List Entry (RLE) LISP Canonical Address Format (LCAF) Type detailed in [RFC8060]. each entry in the replication list contains an address of an xTR and a level value. level values create a replication hierarchy, so ITRs at source LISP sites replicate to the lowest (smaller value) level number RTRs in an RLE. then RTRs at a given level replicate to the next higher level of RTRs. the number of RTRs at each level is engineered to control the fan-out or replication factor, so you can pick a trade-off between the width of the level and the number of levels 🌳

ASM: Any-Source Multicast as defined in [RFC3569], where multicast distribution trees are built with a Rendezvous Point [RFC7761] 🎤

SSM: Source-Specific Multicast as defined in [RFC3569], where multicast distribution trees are built and rooted at the multicast router(s) directly connected to the multicast source 🌸

3. Requirements Language 🧠

this part is the rulebook for the capital letters, so pay attention bestie 🫡 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. lowercase versions don't count, so you're safe 💜

more to come next part, don't go anywhere 💅🎀

4. Reference Model ✨

okay so bestie, let's look at the big picture first 🗺️ The reference model used to talk about signal-free multicast tree interconnection is in Figure 1 and it is giving structure 💅

                                  MS/MR
                                  +---+
                                  |   |
             +---+     +---+      +---+      +---+      +---+
   Src-1 ----| R1|-----|ITR|        |        |ETR|------| R2|----- Rcv-2
             +---+     +---+        |        +---+      +---+
                            \       |       /
             Source-site-1   \      |      /    Receiver-site-2
                              \     |     /
                               \    |    /
                                \   |   /
                                  Core
                                /       \
                               /         \
                              /           \
                             /             \
                            /               \
                       +---+                 +---+
   Src-3 --------------|ITR|                 |ETR|---------------- Rcv-4
                       +---+                 +---+

            Source-site-3                      Receiver-site-4


             Figure 1: LISP Multicast Generic Reference Model

Sites 1 and 3 are the source sites 🎀

Source-site-3 has a source (Src-3) sitting directly connected to the Source-ITR 🫶

Source-site-1 has a source (Src-1) that is one hop or more away from the Source-ITR 🦋

Receiver-site-2 and Receiver-site-4 are the receiver sites. Receiver-site-2 has receiver endpoints that are not directly connected, and Receiver-site-4 has receiver endpoints that are directly connected 🌸

R1 is a multicast router in Source-site-1 🧚

R2 is a multicast router at the receiver site 💜

Map-Servers and Map-Resolvers live in the RLOC space in the core. Only one of each is drawn so the picture stays clean, but there can be lots of them, or they can be part of a distributed mapping system like a Delegated Database Tree (DDT) 🌈

The procedures for interconnecting multicast trees over an overlay split into three functional areas:

  • Receiver-site procedures
  • Source-site procedures
  • LISP notification procedures

The receiver-site procedures are common across most tree types and topologies 🍓

The source-site procedures can change depending on what kind of trees are being interconnected, and also on how the sources relate topologically to the source-site xTRs 🔥 For ASM trees, the RP site is a special case of the source site. A variation of the source-site procedures MAY be necessary there if ASM trees are going to be supported in future specifications of LISP signal-free multicast 👑

The LISP notification procedures between sites are normalized across the different possible scenarios. Some scenarios MAY benefit from a simplified notification mechanism, or from no notification requirement at all ✨

5. General Procedures

Here's the general flow for interconnecting multicast trees across different LISP sites 🦋 It builds the multicast distribution trees across sites in these steps:

  1. The Receiver-ETRs at the receiver sites detect that multicast receiver endpoints are present.
  2. Receiver-ETRs register their RLOCs as part of the replication list for the multicast entry that the detected receivers subscribe to.
  3. The mapping system merges all Receiver-ETR or delivery-group RLOCs into a comprehensive replication list. It includes all receiver sites, for each multicast entry.
  4. LISP Map-Notify messages MUST be sent to the Source-ITR, informing it of any changes in the replication list 💌
  5. Multicast tree building at the source site starts when the Source-ITR receives the LISP notification 🌷

Once the multicast distribution trees are built, the following forwarding procedures may take place:

  1. The source sends multicast packets to the multicast group destination address.
  2. Multicast traffic follows the multicast tree built at the source site and makes its way to the Source-ITRs.
  3. The Source-ITR will issue a Map-Request to resolve the replication list for the multicast entry.
  4. The mapping system responds to the Source-ITR with a Map-Reply containing the replication list for the requested multicast group.
  5. The Source-ITR caches the replication list it received in the map-reply for the multicast entry.
  6. Multicast traffic is rep-encapsulated. That is, the packet is replicated for each RLOC in the replication list, and then encapsulated to each one 💖

5.1. General Receiver-Site Procedures

5.1.1. Multicast Receiver Detection

When the Receiver-ETRs are directly connected to the receivers (for example, Receiver-site-4 in Figure 1), they receive IGMP reports from the receivers. Those reports say which group each receiver wants to subscribe to. From these IGMP reports, the Receiver-ETR finds out that receivers are present, and which group they're interested in 🫶

When the Receiver-ETRs are several hops away from the receivers (for example, Receiver-site-2 in Figure 1), they receive PIM join messages instead. Those let the Receiver-ETR know there are multicast receivers at the site, and also which multicast group they're for 🧚

5.1.2. Receiver-Site Registration

Once the Receiver-ETRs detect receivers at the receiver site, the Receiver-ETRs MUST issue Map-Register messages. These include the Receiver-ETR RLOCs in the replication list for the multicast entry the receivers joined 💅

The Map-Register message MUST use the multicast entry (Source, Group) tuple as its Endpoint ID (EID) record type, with the Receiver-ETR RLOCs conforming the locator set.

The EID in the Map-Register message MUST be encoded using the Multicast Info LCAF Type defined in [RFC8060].

The RLOC in the Map-Register message MUST be encoded using the RLE LCAF Type defined in [RFC8060], with the Level Value fields for all entries set to 128 (decimal) 🔢

The encoding described above MUST be used consistently for Map-Register messages, entries in the mapping system, Map-Reply messages, and the map-cache at the Source-ITRs. Consistency is everything, periodt 💜

The Map-Register messages [RFC6830] sent by the Receiver-ETRs MUST have the following bits set as specified here:

  1. merge-request bit set to 1. The Map-Register messages are sent with "Merge Semantics". The Map-Server will receive registrations from a whole bunch of Receiver-ETRs. It merges the registrations for common EIDs and keeps one consolidated replication list for each multicast entry 🌈
  2. want-map-notify bit (M) set to 0. This tells the mapping system that the Receiver-ETR does not expect to receive Map-Notify messages, because it doesn't need to be told about every change to the replication list 🙈
  3. proxy-reply bit (P) set to 1. The merged replication list is kept in the Map-Servers. By setting the proxy-reply bit, the Receiver-ETRs tell the mapping system to proxy reply to Map-Requests issued for the multicast entries 👑

Map-Register messages for a particular multicast entry MAY be sent for every receiver detected, even if previous receivers were already detected for that multicast entry. This keeps the replication list up to date ✨

Receiver-ETRs MUST be configured to know which Map-Servers their Map-Register messages are sent to. The configuration is likely to be tied to an S-prefix that multiple (S,G) entries match, and that is more specific for them. So the S-prefix decides the Map-Server set in the fewest configuration statements possible 🍓

5.1.3. Consolidation of the Replication List

The Map-Server will receive registrations from a whole bunch of Receiver-ETRs. It merges the registrations for common EIDs and consolidates a replication list for each multicast entry 🫶

When an ETR sends an RLE RLOC-record in a Map-Register, and that RLE already exists in the Map-Server's RLE-merged list, the Map-Server replaces the single RLE with the information from the Map-Register RLOC-record. The Map-Server MUST NOT merge duplicate RLOCs in the consolidated replication list. No duplicates allowed, bestie 🙅‍♀️

5.2. General Source-Site Procedures

Source-ITRs MUST register the unicast EIDs of any sources or Rendezvous Points that may be present on the source site. In other words, it's assumed that the sources and RPs are LISP EIDs 🦋

Registering the unicast EIDs for the sources or Rendezvous Points lets the Map-Server know where to send Map-Notify messages. So the Source-ITR MUST register the unicast S-prefix EID with the want-map-notify bit set, so it can receive Map-Notify messages whenever the replication list changes 🔔

5.2.1. Multicast Tree Building at the Source Site

When the source site receives Map-Notify messages from the mapping system (as described in Section 5.3), it starts the process of building a multicast distribution tree. That tree lets the multicast packets from the source reach the Source-ITR 🌸

The Source-ITR MUST issue a PIM join for the multicast entry it received the Map-Notify message for. The join goes toward the source or toward the RP, for the SSM and ASM cases respectively 💜

5.2.2. Multicast Destination Resolution

When multicast packets arrive, the Source-ITR gets the replication list for the (S,G) addresses in those packets 👀

To get the replication list, the Source-ITR MUST issue a Map-Request message in which the EID is the (S,G) multicast tuple, encoded using the Multicast Info LCAF Type defined in [RFC8060] 🧠

The mapping system (most likely the Map-Server) answers with a Map-Reply that carries the merged replication list maintained in the mapping system. The Map-Reply message MUST follow the format defined in [RFC6830]. Its EID is encoded using the Multicast Info LCAF Type, and the corresponding RLOC-records are encoded using the RLE LCAF Type. Both LCAF Types are defined in [RFC8060] 💖

5.3. General LISP Notification Procedures ✨

Okay so the Map-Server is the one sending out LISP Map-Notify messages 💌 to tell the source site that there are receivers for a particular multicast group hanging out over the overlay 🦋

Updated Map-Notify messages SHOULD be issued every single time a new registration comes in from a receiver site 💅 That way the source sites always know if anything changes in the multicast-distribution-list membership, no surprises 👀

The Map-Notify messages carry (S,G) multicast EIDs encoded using the Multicast Info LCAF Type defined in [RFC8060] 🎀

Map-Notify messages get sent by the Map-Server to the RLOCs that the unicast S-prefix EID was registered with. Now, when sources are found dynamically [LISP-EID-MOBILITY], xTRs MUST register sources explicitly with the want-map-notify bit set 🧚 The reason is so the ITR in the site the source has moved to can grab the most current replication list 🫶

When both the receiver sites and the source sites register to the same Map-Server, that Map-Server has everything it needs to send the Map-Notify messages to the source site. Iconic and easy 👑

When the Map-Servers are distributed (when using LISP-DDT [RFC8111]), the receiver sites MAY register to one Map-Server while the source site registers to a different one 🌈 In this situation, the Map-Server for the receiver sites MUST resolve the unicast S-prefix EID across a distributed mapping transport system, per standard LISP lookup procedures, so it can get the info it needs to send the Map-Notify messages to the source site 💖 The Map-Notify messages are sent with an authentication length of 0 as they would not be authenticated 🙈

When the Map-Servers are distributed, different receiver sites MAY register to different Map-Servers. Honestly though, this is not supported with the currently defined mechanisms 💀

6. Source-Specific Multicast Trees 🦋

The interconnection of SSM trees across sites follows the general receiver-site procedures described in Section 5.1 on the receiver sites. Slay, nothing new to learn there 💅

The source-site procedures will vary depending on the topological location of the source within the source site, as described in Sections 6.1 and 6.2 🌸

6.1. Source Directly Connected to Source-ITRs

When the source is directly connected to the Source-ITR, it is not necessary to trigger signaling to build a local multicast tree at the source site. So Map-Notify messages are not required to kick off building the multicast tree at the source site 🍓

Map-Notify messages are still required, though, to make sure that any changes to the replication list get communicated to the source site, so that the map-cache at the Source-ITRs stays updated 🫶

6.2. Source Not Directly Connected to Source-ITRs

The general LISP notification procedures described in Section 5.3 MUST be followed when the source is not directly connected to the Source-ITR 🔥 On reception of Map-Notify messages, local multicast signaling MUST be initiated at the source site per the general source-site procedures for multicast tree building described in Section 5.2.1. Main character energy 👑

In the SSM case, the IP address of the source is known, and it is also registered with the LISP mapping system. So the mapping system MAY resolve the mapping for the source address in order to send Map-Notify messages to the correct Source-ITR 🧚

7. Multihoming Considerations 🌈

7.1. Multiple ITRs at a Source Site

When multiple ITRs exist at a source multicast site, care MUST be taken that more than one ITR does not head-end replicate packets. Otherwise, receiver multicast sites will receive duplicate packets, and nobody wants that 🙈 The following procedures will be used for each topology scenario:

  • When more than one ITR is directly connected to the source host, either the PIM DR or the IGMP querier (when PIM is not enabled on the ITRs) is responsible for packet replication. All other ITRs silently drop the packet. In the IGMP querier case, one or more ITRs on the source LAN MUST be IGMP querier candidates. Therefore, it is required that they be configured as such 💅
  • When more than one ITR is multiple hops away from the source host and one of the ITRs is the PIM Rendezvous Point, then the PIM RP is responsible for packet replication 🦋
  • When more than one ITR is multiple hops away from the source host and the PIM Rendezvous Point is not one of the ITRs, then one of the ITRs MUST join to the RP. When a Map-Notify is received from the Map-Server by an ITR, only the highest RLOC addressed ITR will join toward the PIM RP or toward the source 🔥

7.2. Multiple ETRs at a Receiver Site

When multiple ETRs exist in a receiver multicast site and each one creates a multicast join state, each one Map-Registers its RLOC address to the mapping system. In this scenario, the replication happens on the overlay, which means multiple ETR entry points replicate to all receivers, instead of a single ETR entry point replicating to all receivers 🌸 If an ETR does not create join state (because it has not received PIM joins or IGMP reports), it will not Map-Register its RLOC addresses to the mapping system. The same procedures in Section 5.1 are followed 💖

When multiple ETRs exist on the same LAN as a receiver host, then the PIM DR (when PIM is enabled) or the IGMP querier is responsible for sending a Map-Register for its RLOC. In the IGMP case, one or more ETRs on a LAN MUST be IGMP querier candidates. Therefore, it is required that they are configured as such 🎀

7.3. Multiple RLOCs for an ETR at a Receiver Site

It MAY be desirable to have multiple underlay paths to an ETR for multicast packet delivery 🦋 This can be done by having multiple RLOCs assigned to an ETR, and having the ETR send Map-Registers for all of its RLOCs. By doing this, an ITR can choose a specific path based on underlay performance and/or RLOC reachability ✨

It is recommended that an ETR send a Map-Register with a single RLOC-record that uses the Explicit Locator Path (ELP) LCAF Type [RFC8060] nested inside the RLE LCAF. Here's an example: say ETR1 has assigned RLOC1 and RLOC2 for a LISP receiver site. There's also ETR2 in another LISP receiver site that has RLOC3. The two receiver sites have the same (S,G) being joined. Here is how the RLOC-record is encoded on each ETR:

ETR1: EID-record: (S,G)
      RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]

ETR2: EID-record: (S,G)
      RLOC-record: RLE[ RLOC3 ]

And here is how the entry is merged and stored on the Map-Server, since the Map-Registers have an RLE-encoded RLOC-record:

MS: EID-record: (S,G)
    RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]

When the ITR receives a packet from a multicast source S for group G, it uses the merged RLOC-record returned from the Map-Server. The ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). Since it is required for the s-bit to be set for RLOC1, the ITR MUST replicate to RLOC1 if it is reachable 🫶 When the required p-bit is also set, the RLOC-reachability mechanisms from [RFC6830] are followed. If the ITR determines that RLOC1 is unreachable, it uses RLOC2, as long as RLOC2 is reachable 💜

7.4. Multicast RLOCs for an ETR at a Receiver Site

This specification is focused on underlays without multicast support, but it does not preclude the use of multicast RLOCs in RLEs 🌈 ETRs MAY register multicast EID entries using multicast RLOCs. In such cases, the ETRs will be joined to underlay multicast distribution trees by using IGMP as a multicast host, using the mechanisms in [RFC2236] and [RFC3376] ✨

8. PIM Any-Source Multicast Trees 🧚

LISP signal-free multicast can support ASM trees in limited but acceptable topologies 💅 For simplicity when building ASM trees across the LISP overlay, it is suggested to have PIM-ASM run independently in each LISP site. What this means is that a PIM RP is configured in each LISP site, so PIM Register procedures and (*,G) state maintenance stay contained within the LISP site 🦋

The following procedure will be used to support ASM in each LISP site:

  1. In a receiver site, the RP is co-located with the ETR. RPs for different groups can be spread across each ETR, but is not required 🍓
  2. When (*,G) state is created in an ETR, the procedures in Section 5.1.2 are followed. In addition, the ETR registers (S-prefix,G), where S-prefix is 0/0 (the respective unicast default route for the address-family), to the mapping system 🎀
  3. In a source site, the RP is co-located with the ITR. RPs for different groups can be spread across each ITR, but is not required 🌸
  4. When a multicast source sends a packet, a PIM Register message is delivered to the ITR, and the procedures in Section 5.2 are followed 💖
  5. When the ITR sends a Map-Request for (S,G) and no receiver site has registered for (S,G), the mapping system will return the (0/0,G) entry to the ITR, so it has a replication list of all the ETRs that have received (*,G) state 🌈
  6. The ITR stores the replication list in its map-cache for (S,G). It replicates packets to all ETRs in the list ✨
  7. ETRs decapsulate packets and forward based on (*,G) state in their site 🫶
  8. When last-hop PIM routers join the newly discovered (S,G), the ETR will store the state and follow the procedures in Section 5.1.2 👑

9. Signal-Free Multicast for Replication Engineering ✨

okay so this section is about taking the multicast replication stuff and making it work with the LISP-RE design 🦋 the big idea is that instead of the layered LISP-RE RTRs using signaling, the RTRs just register their availability for multicast tree replication through the mapping database system. no signaling needed, bestie 💅

the whole point of the RTR layers is to avoid head-end replication at the replicating nodes closest to a multicast source 🌸 so instead of the multicast ITR copying packets to every ETR in an RLE of an (S,G) mapping database entry, it could replicate to one or more layer 0 RTRs in the LISP-RE hierarchy. iconic, honestly 👑

this document says how the RTR hierarchy is determined, but it does NOT say what the optimal layers of RTRs should be 🙈 figuring out optimal paths or RTR topological closeness is out of scope here. not me saying "that's a problem for another day" lol 💀

there are two formats an (S,G) mapping database entry can have 🧚 the first is a 'complete-format', and the second is a 'filtered-format'.

  • complete-format: the (S,G) entry has multiple RLOC-records with both the ETRs that registered AND the first-level RTRs in the LISP-RE hierarchy, so the ITR can choose whether it replicates to the RTRs or to the registered ETRs at the receiver sites. ITR gets the power 💖
  • filtered-format: the Map-Server returns only the RLOC-records it decides the ITR SHOULD use. so replication policy moves from the ITRs over to the mapping system 🎀 the Map-Servers can also decide, per (S,G) entry, whether a given ITR uses a different set of replication targets.

the procedure for LISP-RE RTRs to make themselves available for replication can happen before or after receivers join an (S,G) entry or sources send to it ✨ so newly configured RTR state gets used to create new (S,G) state AND gets inherited into existing (S,G) state. a set of RTRs can register themselves with the mapping system, or a third party can do it on their behalf 🫶 when RTR registration happens, it's done with an (S-prefix, G-prefix) entry, so it can advertise replication services for a wide range of source/group combos. main character energy 🌈

when a Map-Server gets (S,G) registrations from ETRs and (S-prefix, G-prefix) registrations from RTRs, it has the option to merge the RTR RLOC-records for each (S,G) that's more specific than the (S-prefix, G-prefix) entry, or keep them separate. if it merges, the Map-Server is ready to return a 'complete-format' Map-Reply 💜 if it keeps them separate, it decides what goes into a Map-Reply when a Map-Request comes in. it can mix RLOC-records from each entry, or pick one or the other based on configured policy. the policy part is giving control freak energy, ngl 😭

here's the LISP-RE reference model, Figure 2 🦋

                   +---+                 +----+
   Src-1 --------------|ITR|                 |ETR1|--------------- Rcv-1
                       +---+                 +----+
                           \                 /
            Source-site-1   \               /    Receiver-site-1
                             \             /
                              \           /
                   +----+      \         /     +----+
                   |RTR1|       \       /      |RTR2|     Level-0
                   +----+        \     /       +----+
                         \  <^^^^^^^^^^^^^^>  /
                          \ <              > /
                            < Core Network >
                            <              >
                            <vvvvvvvvvvvvvv>
                            /     /   \    \
                           /     /     \    \
                   +----+ /     /       \    \ +----+
                   |RTR3|      /         \     |RTR4|     Level-1
                   +----+     /           \    +----+
                             /             \
                            /               \
                       +----+                +----+
   Rcv-2 --------------|ETR2|                |ETR3|--------------- Rcv-3
                       +----+                +----+

            Receiver-site-2                      Receiver-site-3

                     Figure 2: LISP-RE Reference Model

so here's a specific example from Figure 2 💅 a source S is behind an ITR, and there are receiver sites joined to (S,G) via ETR1, ETR2, and ETR3. there's also a LISP-RE hierarchy with RTR1 and RTR2 at level-0 and RTR3 and RTR4 at level-1 🧚

    EID-record: (S,G)
       RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
    EID-record: (S-prefix, G-prefix)
       RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1

those entries are in the form they were registered in and get stored in a Map-Server 🎀 when a Map-Server uses 'complete-format', the Map-Reply it sends out has the mapping record encoded like this:

    EID-record: (S,G)
        RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1
        RLOC-record: RLE: (ETR1, ETR2, ETR3), p1

so this Map-Reply lets the ITR decide whether it replicates to the ETRs or whether it SHOULD replicate only to level-0 RTR1 🌸 that decision is left to the ITR because both RLOC-records have priority 1. if the Map-Server wants to force the ITR to replicate to RTR1, it would set the ETRs' RLOC-record to a priority greater than 1 🙈 the power move, honestly.

when a Map_server uses 'filtered-format', the Map-Reply it sends out has the mapping record encoded like this:

    EID-record: (S,G)
        RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1

an (S,G) entry can also contain alternate RTRs ✨ so instead of replicating to multiple RTRs, one RTR set MAY be used based on RTR reachability status 💖 an ITR can test reachability to any layer 0 RTR using RLOC-probing, so it can choose one RTR from a set to replicate to. when that's done, the RTRs are encoded in different RLOC-records instead of all together in one RLE RLOC-record. this moves the replication load off the ITRs at the source site and onto the RTRs inside the network infrastructure 🦋 this mechanism can also be used by level-n RTRs to level-n+1 RTRs.

the following mapping would be encoded in a Map-Reply sent by a Map-Server and stored in the ITR. the ITR would use RTR1 until it goes unreachable, and then it switches to RTR2 🫶

    EID-record: (S,G)
        RLOC-record: RTR1, p1
        RLOC-record: RTR2, p2

10. Security Considerations 🔥

okay this part is seriously important, so let's go 🥹

[LISP-SEC] defines a set of security mechanisms that provide origin authentication, integrity, and anti-replay protection for LISP's EID-to-RLOC mapping data sent through the mapping lookup process 🔐 LISP-SEC also lets you verify authorization on EID-prefix claims in Map-Reply messages. no cap, that's a lot of protection 💜

additional security mechanisms to protect the LISP Map-Register messages are defined in [RFC6833] 🛡️

the security of the mapping system infrastructure depends on which mapping database you're using 🌈 as an example, [RFC8111] defines a public-key-based mechanism that gives origin authentication and integrity protection to the LISP DDT protocol 👑

Map-Replies received by the Source-ITR can be signed (by the Map-Server), so the ITR knows the replication list is from a legitimate source 🫶

data-plane encryption can be used when doing unicast rep-encapsulation, as described in [RFC8061] 🔒

11. IANA Considerations 🌸

this document has no IANA actions ✨ nothing to see here for registries, bestie.

12. References 📚

12.1. Normative References

12.2. Informative References

  • [LISP-EID-MOBILITY] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", Work in Progress, draft-ietf-lisp-eid-mobility-01, November 2017.
  • [LISP-MULTI-SIGNALING] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", Work in Progress, draft-farinacci-lisp-mr-signaling-06, February 2015.
  • [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015.
  • [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-15, April 2018.
  • [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.

Acknowledgements ✨🫶

The authors want to thank Greg Shepherd, Joel Halpern, and Sharon Barkai for their insightful contribution to shaping the ideas in this document 💖 Like, these people basically helped the ideas glow up 🌸 A special thanks goes to Luigi Iannone, the LISP WG co-chair, for shepherding this working group document 👑 Thanks also to Jimmy Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for testing an implementation of this document 🧪💅 Literal legends, all of them 😭

Authors' Addresses 🎀

Victor Moreno Cisco Systems 170 Tasman Drive San Jose, California 95134 United States of America

Email: vimoreno@cisco.com

Dino Farinacci lispers.net San Jose, CA 95120 United States of America

Email: farinacci@gmail.com 🦋

📦 where this page comes from