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

Introduction When a multicast capable underlay connects multiple LISP sites, we can take advantage of the multicast capabilities and perform replication more efficiently than using head-end replication. This draft addresses the problem of selecting the underlay multicast group(s), to transport a given overlay multicast flow. There are 4 different scenarios possible:

A 1:1 mapping of a overlay multicast flow, either a (Source, Group) or (*, Group) to an underlay group.
A many:1 mapping where many overlay multicast flows share the same underlay group.
A 1: many mapping where a single overlay group is transported over different underlay groups. Note in this case, the "many" means mapping one EID to multiple RLOCs in a RLE-set where the set can be a mix of underlay groups and underlay unciast addresses. It is really important that this algorithm compute unicast RLOCs as well as multicast RLOCs.
A special (actually realistic) case is the combination of 2 and 3 where m:n mapping is achieved. Typically we expect m>>n.

There are two methods proposed to derive such mappings described above:

Computation based underlay group assignment using hash functions: Here all ETRs will use the same multicast underlay group, when they are all on the same underlay e.g we hash (S-EID, G) Multicast EID, and append either 24 bits in terms of IPv4 or 120 bits in terms of IPv6. If we have disjoint native multicast underlays, we may have to discuss more complicated schemes e.g. different address ranges for IPv4 v/s IPv6 or different ranges inside either of these as well. Since this is a very simple and powerful method, we want to include this design in the current draft.
Lookup based group assignment: The LISP signal free mechanism can be extended to have the co-ordinated assignment of underlay group(s) for a given overlay multicast flow. To implement this, we need a signaling mechanism that is independent of any mutlicast routing protocol that runs in the LISP underlay (e.g PIM)

The scope of this draft covers underlays based on IPv4 and IPv6 only. It does not cover other transport mechanisms like BIER or MPLS or Layer-2 underlays. Note: All terminology used in this document are based on the definitions of RFC8378.

Requirements Language 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 RFC 2119.

Definition of Terms

(S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside of a site.
(S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from the (S-EID,G) entry by doing a mapping database lookup for the EID- Prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/ Prune message when it travels from an ETR to an ITR over the Internet core.

A set of receivers spread across multiple LISP sites having interest on a given (S-EID, G-EID) can be generically represented by the mapping below:

(S-EID,G-EID) -> RLE [(S-RLOC1, G-RLOCa), (S-RLOC1, G-RLOCb), (S-RLOC1, U-RLOCc), (S-RLOC2, U-RLOCd)]

The following additions are made to the General Procedures defined in RFC 8378:

The receiver site procedures require the following extensions to that outlined in RFC 8378: The Map-Register messages RFC 8060 sent by the Receiver-ETRs MUST have the following fields set as specified here:

The RLOC in the Map-Register message MUST be encoded using the RLE LCAF Type defined in RFC 8060 . The address encoded indicates that the RLOC is requesting the flow to be mapped to an underlay multicast group.
want-map-notify bit (M) set to 1. Unlike the use-case of the unicast underlay, the Receiver-ETR MUST be map-notified about the initial assignment of the underlay multicast group(s) and subsequent changes if any to the replication list.
- Comment from Dino: We need the mapping system to tell ITRs when the RLE-set changes so it can updaate its map-cache. This was part of the LISP architecture before we had PubSub, but PubSub uses the same technique. It is just implicit for multicast where with PubSub you send subscribe-requests. So all you have to specifiy is that each ETR that registers mappings sets the M-bit, but now that I am writing this the M-bit is used to acknowledge the Map-Register. So you don't need to set it for updates to mapping entries, because when you register an (S,G) EID encoding, the map-server knows to send RLOC/RLE changes. It knows where to send them because the S-EID is registered in the mapping system, so it knows the RLOCs for that site. But the Merge-bit is crucial or else, from above example, RLOCc and RLOCd could not both be added to the RLE set. So the map-server knows to merge in U-RLOCc from RLOCc and U-RLOCd from RLOCd when they come separately from the ETRs. Ditto, for the entity that regsisters G-RLOCa and G-RLOCb (could be ETRs or could be a controller somewhere).
The consolidated replication list of underlay group(s) assigned to transport the overlay (S-EID, G) is constructed as a RLE by the mapping system and sent as Map-notification to the ETR.
After the above step, the mapping system sends a Map-notify message containing a list of underlay group addresses encoded as RLE LCAF RFC 8060 elements.
The ETR can then join these underlay group addresses to receive the traffic for the multicast entry EIDs.

Another method of explaining the sequence is as below:

The ETR receives an IGMPv3 (S,G) report. That should be spec'ed as (S-EID, G-EID).
The ETR will hash that 2-tuple to get a G-RLOC.
The ETR sends a Map-Register for (S-EID,G-EID) with G-RLOC.
Other ETRs will do the same so only when the last member leaves the G-EID, then there will be no (S-EID,G-EID) registered.
If one ETR (call it x) doesnt think it can get packets natively via G-RLOC, then it will register (U-RLOCx). That is, its IP address that can get it multicast packes on the unicast underlay.

TODO: Merge the above two sequences later

After the mapping system merges all Receiver-ETR or delivery-group RLOCs to build the comprehensive replication list, it allocates one or more underlay group addresses to enable underlay multicast transport for the overlay flow. The allocated group(s) are then notified to both ITR and ETR using the procedures listed in the respective sections.
The mapping system MUST NOT merge any duplicate RLOC requests for the unicast and multicast level value fields.
With a mixed RLE-set, a generic representation of the mapping is of the form below:
- (S-EID,G-EID) -> RLE [(S-RLOC1, G-RLOCa), (S-RLOC1, G-RLOCb), (S-RLOC1, U-RLOCc), (S-RLOC2, U-RLOCd)]
The above notation is really important because for each replication that is encapsulated, the packet could go out a different interface which means the source address in the outer header is different (e.g. this ITR has RLOC1 and RLOC2 on each interface). There may be different pockets of native multicast connectivity in the underlay, so we may have to replicate to different (G-RLOCi) and hence the notation above of G-RLOCa and G-RLOCb. The unicast RLOCs are included above because RLOCc and RLOCd do not have native multicast connectivity to them so they need the use the unicast underlay.

The following points are added:

The source site must include both underlay multicast groups allocated for and unicast RLOCs in the format TBD.
When an ITR receives a packet with header addresses (S-EID, G-EID), it does an (S-EID, G-EID) lookup in the mapping sytstem by sending a Map-Request.
When a Map-Reply is returned, there will be 1 RLOC-record in the RLOC-set. The RLOC-record is encoded as an RLE LCAF per RFC 8060.
The ITR will replicate a packet for each entry in the RLE-set and encapsulate the replicated packet to each G-RLOC and U-RLOC in the RLOC-set.

Placeholder text from Dino: We need a section that just focuses on all the combination of the RLE-set. And we have to recommend how to setup the RLE-set in an ETR when it doesn't know how any ITR will get multicast packets to it (via G-RLOC or U-RLOC).

TBD

Acknowledgements TBD

Contributors Cisco

svenaas@cisco.com

IANA Considerations No new requests to IANA

Security Considerations TBD