diff options
Diffstat (limited to 'doc/rfc/rfc8378.txt')
| -rw-r--r-- | doc/rfc/rfc8378.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8378.txt b/doc/rfc/rfc8378.txt new file mode 100644 index 0000000..75f0900 --- /dev/null +++ b/doc/rfc/rfc8378.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Moreno +Request for Comments: 8378 Cisco Systems +Category: Experimental D. Farinacci +ISSN: 2070-1721 lispers.net + May 2018 + + + Signal-Free Locator/ID Separation Protocol (LISP) Multicast + +Abstract + + 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. When multicast is not available to connect the multicast + sites together, a signal-free mechanism can be used to allow traffic + to flow between sites. The mechanism described in this document uses + unicast replication and encapsulation over the core network for the + data plane and uses the LISP mapping database system so encapsulators + at the source LISP multicast site can find decapsulators at the + receiver LISP multicast sites. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8378. + + + + + + + + + + + + +Moreno & Farinacci Experimental [Page 1] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +Copyright Notice + + 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 of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + + + +Moreno & Farinacci Experimental [Page 2] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +1. Introduction + + When multicast sources and receivers are active at LISP sites, and + the core network between the sites does not provide multicast + support, a signal-free mechanism can be used to create an overlay + that will allow multicast traffic to flow between sites and connect + the multicast trees at the different sites. + + The signal-free mechanism proposed here does not extend PIM [RFC7761] + over the overlay as proposed in [RFC6831], nor does the mechanism + utilize direct signaling between the Receiver-ETRs and Sender-ITRs as + described in [LISP-MULTI-SIGNALING]. The signal-free mechanism + proposed reduces the amount of signaling required between sites to a + minimum and is centered around the registration of receiver sites for + a particular multicast group or multicast channel with the LISP + mapping system. + + Registrations from the different receiver sites will be merged at the + mapping system to assemble a multicast-replication-list inclusive of + all Routing Locators (RLOCs) that lead to receivers for a particular + multicast group or multicast channel. The replication list for each + specific multicast entry is maintained as a database mapping entry in + the LISP mapping system. + + When the Ingress Tunnel Router (ITR) at the source site receives + multicast traffic from sources at its site, the ITR can query the + mapping system by issuing Map-Request messages for the (S,G) source + and destination addresses in the packets received. The mapping + system will return the RLOC replication list to the ITR, which the + ITR will cache as per standard LISP procedure. Since the core is + assumed to not support multicast, the ITR will replicate the + multicast traffic for each RLOC on the replication list and will + unicast encapsulate the traffic to each RLOC. The combined function + or replicating and encapsulating the traffic to the RLOCs in the + replication list is referred to as "rep-encapsulation" in this + document. + + The document describes general procedures (Section 5) and information + encoding that are required at the receiver sites and source sites to + achieve signal-free multicast interconnectivity. The general + procedures for mapping system notifications to different sites are + also described. A section dedicated to the specific case of Source- + Specific Multicast (SSM) trees discusses the implications to the + general procedures for SSM multicast trees over different topological + scenarios. A section on Any-Source Multicast (ASM) support is + included to identify the constraints that come along with supporting + it using LISP signal-free multicast. + + + + +Moreno & Farinacci Experimental [Page 3] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + There is a section dedicated to Replication Engineering, which is a + mechanism to reduce the impact of head-end replication. The mapping + system, via LISP signal-free mechanisms, can be used to build a layer + of Re-encapsulating Tunnel Routers (RTRs). + +2. Definition of Terms + + LISP-related terms, notably Map-Request, Map-Reply, Ingress Tunnel + Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and + Map-Resolver (MR) are defined in the LISP specification [RFC6830]. + + Extensions to the definitions in [RFC6830] for their application to + multicast routing are documented in [RFC6831]. + + Terms defining interactions with the LISP mapping system are defined + in [RFC6833]. + + The following terms are consistent with the definitions in [RFC6830] + and [RFC6831]. The terms are specific cases of the general terms and + are defined here to facilitate the descriptions and discussions + within this particular document. + + 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 the 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. + + + + + +Moreno & Farinacci Experimental [Page 4] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + Multicast entry: A tuple identifying a multicast tree. Multicast + entries are in the form of (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 performs packet + re-routing by chaining ETR and ITR functions, whereby 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 are used to create a replication + hierarchy so that ITRs at source LISP sites replicate to the lowest + (smaller value) level number RTRs in an RLE. And then RTRs at a + given level replicate to the next higher level of RTRs. The number + of RTRs at each level are engineered to control the fan-out or + replication factor, so a trade-off between the width of the level + versus the number of levels can be selected. + + 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 + + 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. + + + + + + + + + + + + + +Moreno & Farinacci Experimental [Page 5] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +4. Reference Model + + The reference model that will be used for the discussion of the + signal-free multicast tree interconnection is illustrated in + Figure 1. + + 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 source sites. + + Source-site-3 presents a source (Src-3) that is directly connected to + the Source-ITR. + + Source-site-1 presents a source (Src-1) that is one hop or more away + from the Source-ITR. + + Receiver-site-2 and -4 are receiver sites with not-directly connected + and directly connected receiver endpoints, respectively. + + R1 is a multicast router in Source-site-1. + + R2 is a multicast router at the receiver site. + + + + + +Moreno & Farinacci Experimental [Page 6] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + Map-Servers and Map-Resolvers are reachable in the RLOC space in the + core; only one is shown for illustration purposes, but these can be + many or even part of a distributed mapping system, such as a + Delegated Database Tree (DDT). + + The procedures for interconnecting multicast trees over an overlay + can be broken down into three functional areas: + + o Receiver-site procedures + + o Source-site procedures + + o LISP notification procedures + + The receiver-site procedures will be common for most tree types and + topologies. + + The procedures at the source site can vary depending on the type of + trees being interconnected as well as the topological relation + between sources and source-site xTRs. For ASM trees, a special case + of the source site is the RP site for which a variation of the + source-site procedures MAY be necessary if ASM trees are to be + supported in future specifications of LISP signal-free multicast. + + The LISP notification procedures between sites are normalized for the + different possible scenarios. Certain scenarios MAY benefit from a + simplified notification mechanism or no notification requirement at + all. + +5. General Procedures + + The interconnection of multicast trees across different LISP sites + involves the following procedures to build the necessary multicast + distribution trees across sites. + + 1. The presence of multicast receiver endpoints is detected by the + Receiver-ETRs at the receiver sites. + + 2. Receiver-ETRs register their RLOCs as part of the replication + list for the multicast entry the detected receivers subscribe to. + + 3. The mapping system merges all Receiver-ETR or delivery-group + RLOCs to build a comprehensive replication list inclusive of all + receiver sites for each multicast entry. + + 4. LISP Map-Notify messages MUST be sent to the Source-ITR informing + of any changes in the replication list. + + + + +Moreno & Farinacci Experimental [Page 7] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + 5. Multicast tree building at the source site is initiated 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 multicast group + requested. + + 5. The Source-ITR caches the replication list 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 (e.g., + Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP + reports from the receivers indicating which group the receivers wish + to subscribe to. Based on these IGMP reports, the Receiver-ETR is + made aware of the presence of receivers as well as which group they + are interested in. + + When the Receiver-ETRs are several hops away from the receivers + (e.g., Receiver-site-2 in Figure 1), the Receiver-ETRs will receive + PIM join messages, which will allow the Receiver-ETR to know that + there are multicast receivers at the site and also to learn which + multicast group the receivers are for. + + + + + + + + + +Moreno & Farinacci Experimental [Page 8] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +5.1.2. Receiver-Site Registration + + Once the Receiver-ETRs detect the presence of receivers at the + receiver site, the Receiver-ETRs MUST issue Map-Register messages to + 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, + as well as the map-cache at the Source-ITRs. + + 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 multitude of Receiver-ETRs. The Map-Server + will merge the registrations for common EIDs and maintain a + 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 as it does not need to be notified of all changes 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 instruct 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 have been + detected for the particular multicast entry. This allows the + replication list to remain up to date. + + + + + + +Moreno & Farinacci Experimental [Page 9] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + Receiver-ETRs MUST be configured to know what Map-Servers Map- + Register messages are sent to. The configuration is likely to be + associated with an S-prefix that multiple (S,G) entries match to and + are more specific for. Therefore, the S-prefix determines the Map- + Server set in the least number of configuration statements. + +5.1.3. Consolidation of the Replication List + + The Map-Server will receive registrations from a multitude of + Receiver-ETRs. The Map-Server will merge the registrations for + common EIDs and consolidate a replication list for each multicast + entry. + + When an ETR sends an RLE RLOC-record in a Map-Register and the RLE + already exists in the Map-Server's RLE-merged list, the Map-Server + will replace 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. + +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 is assumed that the sources and RPs are LISP EIDs. + + The registration of the unicast EIDs for the sources or Rendezvous + Points allows the Map-Server to know where to send Map-Notify + messages to. Therefore, the Source-ITR MUST register the unicast + S-prefix EID with the want-map-notify bit set in order to receive + Map-Notify messages whenever there is a change in the replication + list. + +5.2.1. Multicast Tree Building at the Source Site + + When the source site receives the Map-Notify messages from the + mapping system as described in Section 5.3, it will initiate the + process of building a multicast distribution tree that will allow the + multicast packets from the source to reach the Source-ITR. + + The Source-ITR MUST issue a PIM join for the multicast entry for + which it received the Map-Notify message. The join will be issued in + the direction of the source or in the direction of the RP for the SSM + and ASM cases, respectively. + + + + + + + + +Moreno & Farinacci Experimental [Page 10] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +5.2.2. Multicast Destination Resolution + + On reception of multicast packets, the Source-ITR obtains the + replication list for the (S,G) addresses in the packets. + + In order to obtain the replication list, the Source-ITR MUST issue a + Map-Request message in which the EID is the (S,G) multicast tuple, + which is encoded using the Multicast Info LCAF Type defined in + [RFC8060]. + + The mapping system (most likely the Map-Server) will Map-Reply with + 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 + + The Map-Server will issue LISP Map-Notify messages to inform the + source site of the presence of receivers for a particular multicast + group over the overlay. + + Updated Map-Notify messages SHOULD be issued every time a new + registration is received from a receiver site. This guarantees that + the source sites are aware of any potential changes in the multicast- + distribution-list membership. + + The Map-Notify messages carry (S,G) multicast EIDs encoded using the + Multicast Info LCAF Type defined in [RFC8060]. + + Map-Notify messages will be sent by the Map-Server to the RLOCs with + which the unicast S-prefix EID was registered. In the case when + sources are discovered dynamically [LISP-EID-MOBILITY], xTRs MUST + register sources explicitly with the want-map-notify bit set. This + is so the ITR in the site the source has moved to can get the most + current replication list. + + When both the receiver sites and the source sites register to the + same Map-Server, the Map-Server has all the necessary information to + send the Map-Notify messages to the source site. + + 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 Map-Server. In this scenario, 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, and obtain the necessary information to send the + + + +Moreno & Farinacci Experimental [Page 11] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + 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. However, this is not supported + with the currently defined mechanisms. + +6. Source-Specific Multicast Trees + + The interconnection of SSM trees across sites will follow the general + receiver-site procedures described in Section 5.1 on the receiver + sites. + + 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. Therefore Map-Notify messages are not required to + initiate building of the multicast tree at the source site. + + Map-Notify messages are still required to ensure that any changes to + the replication list are communicated to the source site so that the + map-cache at the Source-ITRs is kept 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. + + In the SSM case, the IP address of the source is known, and it is + also registered with the LISP mapping system. Thus, the mapping + system MAY resolve the mapping for the source address in order to + send Map-Notify messages to the correct Source-ITR. + + + + + + + + + +Moreno & Farinacci Experimental [Page 12] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +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. + The following procedures will be used for each topology scenario: + + o 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. + + o 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. + + o 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 Map-Registers its RLOC address + to the mapping system. In this scenario, the replication happens on + the overlay causing multiple ETR entry points to 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. + + + + + + + + +Moreno & Farinacci Experimental [Page 13] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +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 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] + that is nested inside the RLE LCAF. For example, say ETR1 has + assigned RLOC1 and RLOC2 for a LISP receiver site. Also, there is + 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 mechanisms in [RFC2236] + and [RFC3376]. + + + + + + +Moreno & Farinacci Experimental [Page 14] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +8. PIM Any-Source Multicast Trees + + LISP signal-free multicast can support ASM trees in limited but + acceptable topologies. It is suggested, for the simplification of + building ASM trees across the LISP overlay, 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 is 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. + + + + + + + + +Moreno & Farinacci Experimental [Page 15] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + +9. Signal-Free Multicast for Replication Engineering + + The mechanisms in this specification can be applied to the "LISP + Replication Engineering" [LISP-RE] design. Rather than have the + layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can + register their availability for multicast tree replication via the + mapping database system. + + As stated in [LISP-RE], the RTR-layered hierarchy is used to avoid + head-end replication in replicating nodes closest to a multicast + source. Rather than have multicast ITRs replicate to each 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. + + This document specifies how the RTR hierarchy is determined but not + the optimal layers of RTRs to be used. Methods for determining + optimal paths or RTR topological closeness are out of scope for this + document. + + There are two formats an (S,G) mapping database entry could have. + One format is a 'complete-format', and the other is a 'filtered- + format'. A 'complete-format' entails an (S,G) entry having multiple + RLOC-records that contain both ETRs that have registered as well as + the RTRs at the first level of the LISP-RE hierarchy for the ITR to + replicate to. When using 'complete-format', the ITR has the ability + to select if it replicates to RTRs or to the registered ETRs at the + receiver sites. A 'filtered-format' (S,G) entry is one where the + Map-Server returns the RLOC-records that it decides the ITR SHOULD + use. So replication policy is shifted from the ITRs to the mapping + system. The Map-Servers can also decide for a given ITR if it uses a + different set of replication targets per (S,G) entry for which the + ITR is replicating for. + + The procedure for the LISP-RE RTRs to make themselves available for + replication can occur before or after any receivers join an (S,G) + entry or any sources send for a particular (S,G) entry. Therefore, + newly configured RTR state will be used to create new (S,G) state and + will be inherited into existing (S,G) state. A set of RTRs can + register themselves to the mapping system or a third party can do so + on their behalf. When RTR registration occurs, it is done with an + (S-prefix, G-prefix) entry so it can advertise its replication + services for a wide range of source/group combinations. + + When a Map-Server receives (S,G) registrations from ETRs and + (S-prefix, G-prefix) registrations from RTRs, it has the option of + merging the RTR RLOC-records for each (S,G) that is more specific for + the (S-prefix, G-prefix) entry or keeping them separate. When + merging, a Map-Server is ready to return a 'complete-format' Map- + + + +Moreno & Farinacci Experimental [Page 16] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + Reply. When keeping the entries separate, the Map-Server can decide + what to include in a Map-Reply when a Map-Request is received. It + can include a combination of RLOC-records from each entry or decide + to use one or the other depending on policy configured. + + +---+ +----+ + 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 + + Here is a specific example, illustrated in Figure 2, of (S,G) and + (S-prefix, G-prefix) mapping database entries when a source S is + behind an ITR, and there are receiver sites joined to (S,G) via ETR1, + ETR2, and ETR3. And there exists a LISP-RE hierarchy of 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 + + + + + + +Moreno & Farinacci Experimental [Page 17] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + The above entries are in the form in which they were registered and + are stored in a Map-Server. When a Map-Server uses 'complete- + format', the Map-Reply it originates has the mapping record encoded + as: + + EID-record: (S,G) + RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 + RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 + + The above Map-Reply allows the ITR to decide if it replicates to the + ETRs or if it SHOULD replicate only to level-0 RTR1. This decision + is left to the ITR since both RLOC-records have priority 1. If the + Map-Server wanted to force the ITR to replicate to RTR1, it would set + the ETRs RLOC-record to a priority greater than 1. + + When a Map_server uses 'filtered-format', the Map-Reply it originates + has the mapping record encoded as: + + EID-record: (S,G) + RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 + + An (S,G) entry can contain alternate RTRs. So rather than + replicating to multiple RTRs, one RTR set MAY be used based on the + RTR reachability status. An ITR can test reachability status to any + layer 0 RTR using RLOC-probing, so it can choose one RTR from a set + to replicate to. When this is done, the RTRs are encoded in + different RLOC-records instead of together in one RLE RLOC-record. + This moves the replication load off the ITRs at the source site to + 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 went + unreachable and then switch to use RTR2: + + EID-record: (S,G) + RLOC-record: RTR1, p1 + RLOC-record: RTR2, p2 + +10. Security Considerations + + [LISP-SEC] defines a set of security mechanisms that provide origin + authentication, integrity, and anti-replay protection to LISP's EID- + to-RLOC mapping data conveyed via the mapping lookup process. LISP- + SEC also enables verification of authorization on EID-prefix claims + in Map-Reply messages. + + + + + +Moreno & Farinacci Experimental [Page 18] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + Additional security mechanisms to protect the LISP Map-Register + messages are defined in [RFC6833]. + + The security of the mapping system infrastructure depends on the + particular mapping database used. As an example, [RFC8111] defines a + public-key-based mechanism that provides 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. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2236] Fenner, W., "Internet Group Management Protocol, Version + 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, + <https://www.rfc-editor.org/info/rfc2236>. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, + <https://www.rfc-editor.org/info/rfc3376>. + + [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July + 2003, <https://www.rfc-editor.org/info/rfc3569>. + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + DOI 10.17487/RFC6830, January 2013, + <https://www.rfc-editor.org/info/rfc6830>. + + + + + + +Moreno & Farinacci Experimental [Page 19] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The + Locator/ID Separation Protocol (LISP) for Multicast + Environments", RFC 6831, DOI 10.17487/RFC6831, January + 2013, <https://www.rfc-editor.org/info/rfc6831>. + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + DOI 10.17487/RFC6833, January 2013, + <https://www.rfc-editor.org/info/rfc6833>. + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March + 2016, <https://www.rfc-editor.org/info/rfc7761>. + + [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, + February 2017, <https://www.rfc-editor.org/info/rfc8060>. + + [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. + Smirnov, "Locator/ID Separation Protocol Delegated + Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, + May 2017, <https://www.rfc-editor.org/info/rfc8111>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +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. + + + + + +Moreno & Farinacci Experimental [Page 20] + +RFC 8378 Signal-Free LISP Multicast May 2018 + + + [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. A special thanks to Luigi Iannone, LISP WG co-chair, for + shepherding this working group document. Thanks also goes to Jimmy + Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for + testing an implementation of this document. + +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 + + + + + + + + + + + + + + + + +Moreno & Farinacci Experimental [Page 21] + |