idnits 2.17.1 draft-ietf-lisp-signal-free-multicast-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2018) is 2250 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5698' is defined on line 874, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-01 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Farinacci 5 Expires: August 30, 2018 lispers.net 6 February 26, 2018 8 Signal-Free LISP Multicast 9 draft-ietf-lisp-signal-free-multicast-08 11 Abstract 13 When multicast sources and receivers are active at LISP sites, the 14 core network is required to use native multicast so packets can be 15 delivered from sources to group members. When multicast is not 16 available to connect the multicast sites together, a signal-free 17 mechanism can be used to allow traffic to flow between sites. The 18 mechanism within here uses unicast replication and encapsulation over 19 the core network for the data-plane and uses the LISP mapping 20 database system so encapsulators at the source LISP multicast site 21 can find decapsulators at the receiver LISP multicast sites. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 30, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 65 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8 68 4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8 69 4.1.2. Receiver-Site Registration . . . . . . . . . . . . . 8 70 4.1.3. Consolidation of the Replication-List . . . . . . . . 9 71 4.2. General Source-Site Procedures . . . . . . . . . . . . . 10 72 4.2.1. Multicast Tree Building at the Source-Site . . . . . 10 73 4.2.2. Multicast Destination Resolution . . . . . . . . . . 10 74 4.3. General LISP Notification Procedures . . . . . . . . . . 11 75 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11 76 5.1. Source Directly Connected to Source-ITRs . . . . . . . . 12 77 5.2. Source not Directly Connected to Source-ITRs . . . . . . 12 78 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12 79 6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12 80 6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 13 81 6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13 82 6.4. Multicast RLOCs for an ETR at a Receiver-Site . . . . . . 14 83 7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14 84 8. Signal-Free Multicast for Replication Engineering . . . . . . 15 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 12.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 21 92 A.1. Changes to draft-ietf-lisp-signal-free-multicast-08 . . . 21 93 A.2. Changes to draft-ietf-lisp-signal-free-multicast-07 . . . 21 94 A.3. Changes to draft-ietf-lisp-signal-free-multicast-06 . . . 21 95 A.4. Changes to draft-ietf-lisp-signal-free-multicast-05 . . . 21 96 A.5. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 22 97 A.6. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 22 98 A.7. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 22 99 A.8. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 22 100 A.9. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 22 101 A.10. Changes to draft-farinacci-lisp-signal-free-multicast-04 23 102 A.11. Changes to draft-farinacci-lisp-signal-free-multicast-03 23 103 A.12. Changes to draft-farinacci-lisp-signal-free-multicast-02 23 104 A.13. Changes to draft-farinacci-lisp-signal-free-multicast-01 23 105 A.14. Changes to draft-farinacci-lisp-signal-free-multicast-00 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 When multicast sources and receivers are active at LISP sites, and 111 the core network between the sites does not provide multicast 112 support, a signal-free mechanism can be used to create an overlay 113 that will allow multicast traffic to flow between sites and connect 114 the multicast trees at the different sites. 116 The signal-free mechanism proposed here does not extend PIM [RFC7761] 117 over the overlay as proposed in [RFC6831], nor does the mechanism 118 utilize direct signaling between the Receiver-ETRs and Sender-ITRs as 119 described in [I-D.farinacci-lisp-mr-signaling]. The signal-free 120 mechanism proposed reduces the amount of signaling required between 121 sites to a minimum and is centered around the registration of 122 Receiver-sites for a particular multicast-group or multicast-channel 123 with the LISP Mapping System. 125 Registrations from the different receiver-sites will be merged at the 126 Mapping System to assemble a multicast-replication-list inclusive of 127 all RLOCs that lead to receivers for a particular multicast-group or 128 multicast-channel. The replication-list for each specific multicast- 129 entry is maintained as a database mapping entry in the LISP Mapping 130 System. 132 When the ITR at the source-site receives multicast traffic from 133 sources at its site, the ITR can query the mapping system by issuing 134 Map-Request messages for the (S,G) source and destination addresses 135 in the packets received. The Mapping System will return the RLOC 136 replication-list to the ITR, which the ITR will cache as per standard 137 LISP procedure. Since the core is assumed to not support multicast, 138 the ITR will replicate the multicast traffic for each RLOC on the 139 replication-list and will unicast encapsulate the traffic to each 140 RLOC. The combined function or replicating and encapsulating the 141 traffic to the RLOCs in the replication-list is referred to as "rep- 142 encapsulation" in this document. 144 The document describes the General Procedures (Section 4) and 145 information encoding that are required at the Receiver-sites and 146 Source-sites to achieve signal-free multicast interconnectivity. The 147 General Procedures for Mapping System Notifications to different 148 sites are also described. A section dedicated to the specific case 149 of SSM trees discusses the implications to the General Procedures for 150 SSM multicast trees over different topological scenarios. A section 151 on ASM support is included to identify the constraints that come 152 along with supporting it using LISP Signal-Free multicast. 154 There is a section dedicated to Replication Engineering. A mechanism 155 to reduce the impact of head-end replication. The mapping system, 156 via LISP Signal-Free mechanisms, can be used to build a layer of 157 RTRs. 159 2. Definition of Terms 161 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 162 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 163 Resolver (MR) are defined in the LISP specification [RFC6830]. 165 Extensions to the definitions in [RFC6830] for their application to 166 multicast routing are documented in [RFC6831]. 168 Terms defining interactions with the LISP Mapping System are defined 169 in [RFC6833]. 171 The following terms are consistent with the definitions in [RFC6830] 172 and [RFC6831]. The terms are specific cases of the general terms and 173 are here defined to facilitate the descriptions and discussions 174 within this particular document. 176 Source: Multicast source end-point. Host originating multicast 177 packets. 179 Receiver: Multicast group member end-point. Host joins multicast 180 group as a receiver of multicast packets sent to the group. 182 Receiver-site: LISP site where multicast receivers are located. 184 Source-site: LISP site where multicast sources are located. 186 RP-site: LISP site where an ASM PIM Rendezvous Point [RFC7761] is 187 located. The RP-site and the Source-site MAY be the same in some 188 situations. 190 Receiver-ETR: LISP decapsulating xTR at the Receiver-site. This is a 191 multicast ETR. 193 Source-ITR: LISP encapsulating xTR at the Source-site. This is a 194 multicast ITR. 196 RP-xTR: LISP xTR at the RP-site. This is typically a multicast ITR. 198 Replication-list: Mapping-entry containing the list of RLOCs that 199 have registered Receivers for a particular multicast-entry. 201 Multicast-entry: A tuple identifying a multicast tree. Multicast- 202 entries are in the form of (S-prefix, G-prefix). 204 Rep-encapsulation: The process of replicating and then encapsulating 205 traffic to multiple RLOCs. 207 Re-encapsulating Tunnel Router (RTR): An RTR is a router that 208 implements the re-encapsulating tunnel function detailed in Section 8 209 of the main LISP specification [RFC6830]. A LISP RTR performs packet 210 re-routing by chaining ETR and ITR functions, whereby it first 211 removes the LISP header of an ingress packet and then prepends a new 212 LISP header to an egress packet. 214 RTR Level: An RTR level is encoded in a Replication-List-Entry (RLE) 215 LCAF Type detailed in [RFC8060]. Each entry in the replication list 216 contains an address of an xTR and a level value. Level values are 217 used to create a replication hierarchy so that ITRs at source LISP 218 sites replicate to the lowest (smaller value) level number RTRs in a 219 RLE entry. And then RTRs at a given level replicate to the next 220 higher level of RTRs. The number of RTRs at each level are 221 engineered to control the fan-out or replication factor so a tradeoff 222 between the width of the level versus the number of levels can be 223 selected. 225 ASM: Any-Source Multicast as defined in [RFC3569] and [RFC7761] where 226 multicast distribution trees are built with a Rendezvous Point. 228 SSM: Source Specific Multicast as defined in [RFC3569] where 229 multicast distribution trees are built and rooted at the multicast 230 router(s) directly connected to the multicast source. 232 3. Reference Model 234 The reference model that will be used for the discussion of the 235 Signal-Free multicast tree interconnection is illustrated in 236 Figure 1. 238 MS/MR 239 +---+ 240 | | 241 +---+ +---+ +---+ +---+ +---+ 242 Src-1 ----| R1|-----|ITR| | |ETR|------| R2|------ Rcv-2 243 +---+ +---+ | +---+ +---+ 244 \ | / 245 Source-site-1 \ | / Receiver-site-2 246 \ | / 247 \ | / 248 \ | / 249 Core 250 / \ 251 / \ 252 / \ 253 / \ 254 / \ 255 +---+ +---+ 256 Src-3 --------------|ITR| |ETR|----------------- Rcv-4 257 +---+ +---+ 259 Source-site-3 Receiver-site-4 261 Figure 1: LISP Multicast Generic Reference Model 263 Sites 1 and 3 are Source-sites. 265 Source-site-3 presents a Source (Src-3) that is directly connected to 266 the Source-ITR 268 Source-site-1 presents a Source (Src-1) that is one hop or more away 269 from the Source-ITR 271 Receiver-site-2 and 4 are receiver sites with not-directly connected 272 and directly connected Receiver end-points respectively 274 R1 is a multicast router in Source-site-1. 276 R2 is a multicast router at the Receiver-site. 278 The Map-Servers and Resolvers are reachable in the RLOC space in the 279 Core, only one is shown for illustration purposes, but these can be 280 many or even part of a Distributed Mapping System, such as a DDT 281 Tree. 283 The procedures for interconnecting multicast Trees over an overlay 284 can be broken down into three functional areas: 286 o Receiver-site procedures 288 o Source-site procedures 290 o LISP notification procedures 292 The receiver site procedures will be common for most tree types and 293 topologies. 295 The procedures at the source site can vary depending on the type of 296 trees being interconnected as well as based on the topological 297 relation between sources and source-site xTRs. For ASM trees, a 298 special case of the Source-site is the RP-site for which a variation 299 of the Source-site procedures MAY be necessary if ASM trees are to be 300 supported in future specifications of LISP Signal-Free multicast. 302 The LISP notification procedures between sites are normalized for the 303 different possible scenarios. Certain scenarios MAY benefit from a 304 simplified notification mechanism or no notification requirement at 305 all. 307 4. General Procedures 309 The interconnection of multicast trees across different LISP sites 310 involves the following procedures to build the necessary multicast 311 distribution trees across sites. 313 1. The presence of multicast Receiver end-points is detected by the 314 Receiver-ETRs at the Receiver-sites. 316 2. Receiver-ETRs register their RLOCs as part of the replication- 317 list for the multicast-entry the detected Receivers subscribe to. 319 3. The Mapping-system merges all receiver-ETR or delivery-group 320 RLOCs to build a comprehensive replication-list inclusive of all 321 Receiver-sites for each multicast-entry. 323 4. LISP Map-Notify messages MUST be sent to the Source-ITR informing 324 of any changes in the replication-list. 326 5. Multicast-tree building at the Source-site is initiated when the 327 Source-ITR receives the LISP Notification. 329 Once the multicast distribution trees are built, the following 330 forwarding procedures may take place: 332 1. The Source sends multicast packets to the multicast group 333 destination address. 335 2. Multicast traffic follows the multicast tree built at the Source- 336 site and makes its way to the Source-ITRs. 338 3. The Source-ITR will issue a map-request to resolve the 339 replication-list for the multicast-entry. 341 4. The Mapping System responds to the Source-ITR with a map-reply 342 containing the replication-list for the multicast group 343 requested. 345 5. The Source-ITR caches the replication-list received in the map- 346 reply for the multicast-entry. 348 6. Multicast traffic is rep-encapsulated. That is, the packet is 349 replicated for each RLOC in the replication-list and then 350 encapsulated to each one. 352 4.1. General Receiver-Site Procedures 354 4.1.1. Multicast Receiver Detection 356 When the Receiver-ETRs are directly connected to the Receivers (e.g. 357 Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP 358 Reports from the Receivers indicating which group the Receivers wish 359 to subscribe to. Based on these IGMP Reports, the receiver-ETR is 360 made aware of the presence of Receivers as well as which group they 361 are interested in. 363 When the Receiver-ETRs are several hops away from the Receivers (e.g. 364 Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join 365 messages which will allow the Receiver-ETR to know that there are 366 multicast Receivers at the site and also learn which multicast group 367 the Receivers are for. 369 4.1.2. Receiver-Site Registration 371 Once the Receiver-ETRs detect the presence of Receivers at the 372 Receiver-site, the Receiver-ETRs MUST issue Map-Register messages to 373 include the Receiver-ETR RLOCs in the replication-list for the 374 multicast-entry the Receivers joined. 376 The Map-Register message MUST use the multicast-entry (Source, Group) 377 tuple as its EID record type with the Receiver-ETR RLOCs conforming 378 the locator set. 380 The EID in the Map-Register message MUST be encoded using the 381 Multicast Information LCAF type defined in [RFC8060]. 383 The RLOC in the Map-Register message MUST be encoded using the 384 Replication List Entry (RLE) LCAF type defined in [RFC8060] with the 385 Level Value fields for all entries set to 128 (decimal). 387 The encoding described above MUST be used consistently for Map- 388 Register messages, entries in the Mapping System, Map-reply messages 389 as well as the map-cache at the Source-ITRs. 391 The Map-Register messages [RFC6830] sent by the receiver-ETRs MUST 392 have the following bits set as here specified: 394 1. merge-request-bit set to 1. The Map-Register messages are sent 395 with "Merge Semantics". The Map-Server will receive 396 registrations from a multitude of Receiver-ETRs. The Map-Server 397 will merge the registrations for common EIDs and maintain a 398 consolidated replication-list for each multicast-entry. 400 2. want-map-notify-bit (M) set to 0. This tells the Mapping System 401 that the receiver-ETR does not expect to receive Map-Notify 402 messages as it does not need to be notified of all changes to the 403 replication-list. 405 3. proxy-reply-bit (P) set to 1. The merged replication-list is 406 kept in the Map-Servers. By setting the proxy-reply bit, the 407 receiver-ETRs instruct the Mapping-system to proxy reply to map- 408 requests issued for the multicast entries. 410 Map-Register messages for a particular multicast-entry MAY be sent 411 for every receiver detected, even if previous receivers have been 412 detected for the particular multicast-entry. This allows the 413 replication-list to remain up to date. 415 Receiver-ETRs MUST be configured to know what Map-Servers Map- 416 Register messages are sent to. The configuration is likely to be 417 associated with an S-prefix that multiple (S,G) entries match to and 418 are more specific for. Therefore, the S-prefix determines the Map- 419 Server set in the least number of configuration statements. 421 4.1.3. Consolidation of the Replication-List 423 The Map-Server will receive registrations from a multitude of 424 Receiver-ETRs. The Map-Server will merge the registrations for 425 common EIDs and consolidate a replication-list for each multicast- 426 entry. 428 When an ETR sends an RLE RLOC-record in a Map-Register and the RLE 429 entry already exists in the Map-Server's RLE merged list, the Map- 430 Server will replace the single RLE entry with the information from 431 the Map-Register RLOC-record. The Map-Server MUST NOT merge 432 duplicate RLOCs in the consolidated replication-list. 434 4.2. General Source-Site Procedures 436 Source-ITRs MUST register the unicast EIDs of any Sources or 437 Rendezvous Points that may be present on the Source-site. In other 438 words, it is assumed that the Sources and RPs are LISP EIDs. 440 The registration of the unicast EIDs for the Sources or Rendezvous 441 Points allows the Map-Server to know where to send Map-Notify 442 messages to. Therefore, the Source-ITR MUST register the unicast 443 S-prefix EID with the want-map-notify-bit set in order to receive 444 Map-Notify messages whenever there is a change in the replication- 445 list. 447 4.2.1. Multicast Tree Building at the Source-Site 449 When the source site receives the Map-Notify messages from the 450 mapping system as described in Section 4.3, it will initiate the 451 process of building a multicast distribution tree that will allow the 452 multicast packets from the Source to reach the Source-ITR. 454 The Source-ITR MUST issue a PIM join for the multicast-entry for 455 which it received the Map-Notify message. The join will be issued in 456 the direction of the source or in the direction of the RP for the SSM 457 and ASM cases respectively. 459 4.2.2. Multicast Destination Resolution 461 On reception of multicast packets, the source-ITR obtains the 462 replication-list for the (S,G) addresses in the packets. 464 In order to obtain the replication-list, the Source-ITR MUST issue a 465 Map-Request message in which the EID is the (S,G) multicast tuple 466 which is encoded using the Multicast Info LCAF type defined in 467 [RFC8060]. 469 The Mapping System (most likely the Map-Server) will Map-reply with 470 the merged replication-list maintained in the Mapping System. The 471 Map-reply message MUST follow the format defined in [RFC6830], its 472 EID is encoded using the Multicast Info LCAF type and the 473 corresponding RLOC-records are encoded using the RLE LCAF type. Both 474 LCAF types defined in [RFC8060]. 476 4.3. General LISP Notification Procedures 478 The Map-Server will issue LISP Map-Notify messages to inform the 479 Source-site of the presence of receivers for a particular multicast 480 group over the overlay. 482 Updated Map-Notify messages SHOULD be issued every time a new 483 registration is received from a Receiver-site. This guarantees that 484 the source-sites are aware of any potential changes in the multicast- 485 distribution-list membership. 487 The Map-Notify messages carry (S,G) multicast EIDs encoded using the 488 Multicast Info LCAF type defined in [RFC8060]. 490 Map-Notify messages will be sent by the Map-Server to the RLOCs with 491 which the unicast S-prefix EID was registered. In the case when 492 sources are discovered dynamically [I-D.ietf-lisp-eid-mobility], xTRs 493 MUST register sources explicitly with the want-map-notify-bit set. 494 This is so the ITR in the site the source has moved to can get the 495 most current replication list. 497 When both the Receiver-sites and the Source-sites register to the 498 same Map-Server, the Map-Server has all the necessary information to 499 send the Map-Notify messages to the Source-site. 501 When the Map-Servers are distributed (when using LISP-DDT [RFC8111]), 502 the Receiver-sites MAY register to one Map-Server while the Source- 503 site registers to a different Map-Server. In this scenario, the Map- 504 Server for the receiver sites MUST resolve the unicast S-prefix EID 505 across a distributed mapping transport system, per standard LISP 506 lookup procedures and obtain the necessary information to send the 507 Map-Notify messages to the Source-site. The Map-Notify messages are 508 sent with an authentication length of 0 as they would not be 509 authenticated. 511 When the Map-Servers are distributed, different Receiver-sites MAY 512 register to different Map-Servers. However, this is not supported 513 with the currently defined mechanisms. 515 5. Source Specific Multicast Trees 517 The interconnection of Source Specific Multicast (SSM) Trees across 518 sites will follow the General Receiver-site Procedures described in 519 Section 4.1 on the Receiver-sites. 521 The Source-site Procedures will vary depending on the topological 522 location of the Source within the Source-site as described in 523 Section 5.1 and Section 5.2 . 525 5.1. Source Directly Connected to Source-ITRs 527 When the Source is directly connected to the source-ITR, it is not 528 necessary to trigger signaling to build a local multicast tree at the 529 Source-site. Therefore Map-Notify messages are not required to 530 initiate building of the multicast tree at the Source-site. 532 Map-Notify messages are still required to ensure that any changes to 533 the replication-list are communicated to the Source-site so that the 534 map-cache at the Source-ITRs is kept updated. 536 5.2. Source not Directly Connected to Source-ITRs 538 The General LISP Notification Procedures described in Section 4.3 539 MUST be followed when the Source is not directly connected to the 540 source-ITR. On reception of Map-Notify messages, local multicast 541 signaling MUST be initiated at the Source-site per the General Source 542 Site Procedures for Multicast Tree building described in 543 Section 4.2.1. 545 In the SSM case, the IP address of the Source is known and it is also 546 registered with the LISP mapping system. Thus, the mapping system 547 MAY resolve the mapping for the Source address in order to send Map- 548 Notify messages to the correct source-ITR. 550 6. Multi-Homing Considerations 552 6.1. Multiple ITRs at a Source-Site 554 When multiple ITRs exist at a source multicast site, care MUST be 555 taken that more than one ITR does not head-end replicate packets else 556 receiver multicast sites will receive duplicate packets. The 557 following procedures will be used for each topology scenarios: 559 o When more than one ITR is directly connected to the source host, 560 either the PIM DR or the IGMP querier (when PIM is not enabled on 561 the ITRs) is responsible for packet replication. All other ITRs 562 silently drop the packet. In the IGMP querier case, one or more 563 ITRs on the source LAN MUST be IGMP querier candidates. 564 Therefore, it is required they are configured as such. 566 o When more than one ITR is multiple hops away from the source host 567 and one of the ITRs is the PIM Rendezvous Point, then the PIM RP 568 is responsible for packet replication. 570 o When more than one ITR is multiple hops away from the source host 571 and the PIM Rendezvous Point is not one of the ITRs, then one of 572 the ITRs MUST join to the RP. When a Map-Notify is received from 573 the Map-Server by an ITR, only the highest RLOC addressed ITR will 574 join toward the PIM RP or toward the source. 576 6.2. Multiple ETRs at a Receiver-Site 578 When multiple ETRs exist in a receiver multicast site, and each 579 create multicast join state, they each Map-Register their RLOC 580 addresses to the mapping system. In this scenario, the replication 581 happens on the overlay causing multiple ETR entry points to replicate 582 to all receivers versus a single ETR entry point replicating to all 583 receivers. If an ETR does not create join state, because it has not 584 received PIM joins or IGMP reports, it will not Map-Register its RLOC 585 addresses to the mapping system. The same procedures in Section 4.1 586 are followed. 588 When multiple ETRs exist on the same LAN as a receiver host, then the 589 PIM DR, when PIM is enabled, or the IGMP querier is responsible for 590 sending a Map-Register for its RLOC. In the IGMP case, one or more 591 ETRs on LAN MUST be IGMP querier candidates. Therefore, it is 592 required they are configured as such. 594 6.3. Multiple RLOCs for an ETR at a Receiver-Site 596 It MAY be desirable to have multiple underlay paths to an ETR for 597 multicast packet delivery. This can be done by having multiple RLOCs 598 assigned to an ETR and having the ETR send Map-Registers for all its 599 RLOCs. By doing this, an ITR can choose a specific path based on 600 underlay performance and/or RLOC reachability. 602 It is recommended that an ETR sends a Map-Register with a single 603 RLOC-record that uses the ELP LCAF type [RFC8060] that is nested 604 inside RLE entry LCAF. For example say ETR1 has assigned RLOC1 and 605 RLOC2 for a LISP receiver site. And there is ETR2 in another LISP 606 receiver site, that has RLOC3. The two receiver sites have the same 607 (S,G) being joined. Here is how the RLOC-record is encoded on each 608 ETR: 610 ETR1: EID-record: (S,G) 611 RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] 613 ETR2: EID-record: (S,G) 614 RLOC-record: RLE[ RLOC3 ] 616 And here is how the entry is merged and stored on the Map-Server 617 since the Map-Registers have an RLE encoded RLOC-record: 619 MS: EID-record: (S,G) 620 RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] 622 When the ITR receives a packet from a multicast source S for group G, 623 it uses the merged RLOC-record, returned from the Map-Server. The 624 ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). 625 Since it is required for the s-bit to be set for RLOC1, the ITR MUST 626 replicate to RLOC1 if it is reachable. When the required p-bit is 627 also set, the RLOC-reachability mechanisms from [RFC6830] are 628 followed. If the ITR determines that RLOC1 is unreachable, it uses 629 RLOC2, as long as RLOC2 is reachable. 631 6.4. Multicast RLOCs for an ETR at a Receiver-Site 633 This specification is focused on underlays without multicast support, 634 but does not preclude the use of multicast RLOCs in RLE entries. 635 ETRs MAY register multicast EID entries using multicast RLOCs. In 636 such cases the ETRs will get joined to underlay multicast 637 distribution trees by using IGMP as a multicast host using mechanisms 638 in [RFC2236] and [RFC3376]. 640 7. PIM Any Source Multicast Trees 642 LISP signal-free multicast can support ASM Trees in limited but 643 acceptable topologies. It is suggested for the simplification of 644 building ASM trees across the LISP overlay to have PIM-ASM run 645 independently in each LISP site. What this means, is that a PIM 646 Rendezvous Point (RP) is configured in each LISP site so PIM Register 647 procedures and (*,G) state maintenance is contained within the LISP 648 site. 650 The following procedure will be used to support ASM in each LISP 651 site: 653 1. In a Receiver-site, the RP is colocated with the ETR. RPs for 654 different groups can be spread across each ETR, but is not 655 required. 657 2. When (*,G) state is created in an ETR, the procedures in 658 Section 4.1.2 are followed. In addition, the ETR registers 659 (S-prefix,G), where S-prefix is 0/0 (the respective unicast 660 default route for the address-family) to the mapping system. 662 3. In a Source-site, the RP is colocated with the ITR. RPs for 663 different groups can be spread across each ITR, but is not 664 required. 666 4. When a multicast source sends a packet, a PIM Register message is 667 delivered to the ITR and the procedures in Section 4.2 are 668 followed. 670 5. When the ITR sends a Map-Request for (S,G) and no Receiver-site 671 has registered for (S,G), the mapping system will return the 672 (0/0,G) entry to the ITR so it has a replication list of all the 673 ETRs that have received (*,G) state. 675 6. The ITR stores the replication-list in its map-cache for (S,G). 676 It replicates packets to all ETRs in the list. 678 7. ETRs decapsulate packets and forward based on (*,G) state in 679 their site. 681 8. When last-hop PIM routers join the newly discovered (S,G), the 682 ETR will store the state and follow the procedures in 683 Section 4.1.2. 685 8. Signal-Free Multicast for Replication Engineering 687 The mechanisms in this draft can be applied to the LISP Replication- 688 Engineering [I-D.coras-lisp-re] design. Rather than having the 689 layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can 690 register their availability for multicast tree replication via the 691 mapping database system. 693 As stated in [I-D.coras-lisp-re], the RTR layered hierarchy is used 694 to avoid head-end replication in replicating nodes closest to a 695 multicast source. Rather than have multicast ITRs replicate to each 696 ETR in an RLE entry of a (S,G) mapping database entry, it could 697 replicate to one or more layer-0 RTRs in the LISP-RE hierarchy. 699 This draft documents how the RTR hierarchy is determined but not what 700 are the optimal layers of RTRs to use. Methods for determining 701 optimal paths or RTR topological closeness are out of scope for his 702 document. 704 There are two formats an (S,G) mapping database entry could have. 705 One format is a 'complete-format' and the other is a 'filtered- 706 format'. A 'complete-format' entails an (S,G) entry having multiple 707 RLOC records which contain both ETRs that have registered as well as 708 the RTRs at the first level of the LISP-RE hierarchy for the ITR to 709 replicate to. When using 'complete-format', the ITR has the ability 710 to select if it replicates to RTRs or to the registered ETRs at the 711 receiver sites. A 'filtered-format' (S,G) entry is one where the 712 Map-Server returns the RLOC-records that it decides the ITR SHOULD 713 use. So replication policy is shifted from the ITRs to the mapping 714 system. The Map-Servers can also decide for a given ITR, if it uses 715 a different set of replication targets per (S,G) entry for which the 716 ITR is replicating for. 718 The procedure for the LISP-RE RTRs to make themselves available for 719 replication can occur before or after any receivers join an (S,G) 720 entry or any sources send for a particular (S,G) entry. Therefore, 721 newly configured RTR state will be used to create new (S,G) state and 722 inherited into existing (S,G) state. A set of RTRs can register 723 themselves to the mapping system or a third-party can do so on their 724 behalf. When RTR registration occurs, it is done with an (S-prefix, 725 G-prefix) entry so it can advertise its replication services for a 726 wide-range of source/group combinations. 728 When a Map-Server receives (S,G) registrations from ETRs and 729 (S-prefix, G-prefix) registrations from RTRs, it has the option of 730 merging the RTR RLOC-records for each (S,G) that is more-specific for 731 the (S-prefix, G-prefix) entry or keep them separate. When merging, 732 a Map-Server is ready to return a 'complete-format' Map-Reply. When 733 keeping the entries separate, the Map-Server can decide what to 734 include in a Map-Reply when a Map-Request is received. It can 735 include a combination of RLOC-records from each entry or decide to 736 use one or the other depending on policy configured. 738 +---+ +----+ 739 Src-1 --------------|ITR| |ETR1|---------------- Rcv-1 740 +---+ +----+ 741 \ / 742 Source-site-1 \ / Receiver-site-1 743 \ / 744 \ / 745 +----+ \ / +----+ 746 |RTR1| \ / |RTR2| Level-0 747 +----+ \ / +----+ 748 \ <^^^^^^^^^^^^^^> / 749 \ < > / 750 < Core-Network > 751 < > 752 753 / / \ \ 754 / / \ \ 755 +----+ / / \ \ +----+ 756 |RTR3| / \ |RTR4| Level-1 757 +----+ / \ +----+ 758 / \ 759 / \ 760 +----+ +----+ 761 Rcv-2 --------------|ETR2| |ETR3|---------------- Rcv-3 762 +----+ +----+ 764 Receiver-site-2 Receiver-site-3 766 Figure 2: LISP-RE Reference Model 768 Here is a specific example, illustrated in Figure 2, of (S,G) and 769 (S-prefix, G-prefix) mapping database entries when a source S is 770 behind an ITR and there are receiver sites joined to (S,G) via ETR1, 771 ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and 772 RTR2 at level-0 and RTR3 and RTR4 at level-1: 774 EID-record: (S,G) 775 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 776 EID-record: (S-prefix, G-prefix) 777 RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1 779 The above entries are in the form of how they were registered and 780 stored in a Map-Server. When a Map-Server uses 'complete-format', a 781 Map-Reply it originates has the mapping record encoded as: 783 EID-record: (S,G) 784 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 785 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 787 The above Map-Reply allows the ITR to decide if it replicates to the 788 ETRs or if it SHOULD replicate only to level-0 RTR1. This decision 789 is left to the ITR since both RLOC-records have priority 1. If the 790 Map-Server wanted to force the ITR to replicate to RTR1, it would set 791 the ETRs RLOC-record to priority greater than 1. 793 When a Map_server uses "filtered-format', a Map-Reply it originates 794 has the mapping record encoded as: 796 EID-record: (S,G) 797 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 799 An (S,G) entry can contain alternate RTRs. So rather than 800 replicating to multiple RTRs, one of a RTR set MAY be used based on 801 the RTR reachability status. An ITR can test reachability status to 802 any layer-0 RTR using RLOC-probing so it can choose one RTR from a 803 set to replicate to. When this is done the RTRs are encoded in 804 different RLOC-records versus together in one RLE RLOC-record. This 805 moves the replication load off the ITRs at the source site to the 806 RTRs inside the network infrastructure. This mechanism can also be 807 used by level-n RTRs to level-n+1 RTRs. 809 The following mapping would be encoded in a Map-Reply sent by a Map- 810 Server and stored in the ITR. The ITR would use RTR1 until it went 811 unreachable and then switch to use RTR2: 813 EID-record: (S,G) 814 RLOC-record: RTR1, p1 815 RLOC-record: RTR2, p2 817 9. Security Considerations 819 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 820 origin authentication, integrity and anti-replay protection to LISP's 821 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 822 SEC also enables verification of authorization on EID-prefix claims 823 in Map-Reply messages. 825 Additional security mechanisms to protect the LISP Map-Register 826 messages are defined in [RFC6833]. 828 The security of the Mapping System Infrastructure depends on the 829 particular mapping database used. The [RFC8111] specification, as an 830 example, defines a public-key based mechanism that provides origin 831 authentication and integrity protection to the LISP DDT protocol. 833 Map-Replies received by the source-ITR can be signed (by the Map- 834 Server) so the ITR knows the replication-list is from a legit source. 836 Data-plane encryption can be used when doing unicast rep- 837 encapsulation as described in [RFC8061]. 839 10. IANA Considerations 841 This document has no IANA implications 843 11. Acknowledgements 845 The authors want to thank Greg Shepherd, Joel Halpern and Sharon 846 Barkai for their insightful contribution to shaping the ideas in this 847 document. A special thanks to Luigi Iannone, LISP WG co-chair, for 848 shepherding this working group document. Thanks also goes to Jimmy 849 Kyriannis, Paul Vinciguerra, Florin Coras, and Yan Filyurin for 850 testing an implementation of this draft. 852 12. References 854 12.1. Normative References 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, 858 DOI 10.17487/RFC2119, March 1997, 859 . 861 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 862 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 863 . 865 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 866 Thyagarajan, "Internet Group Management Protocol, Version 867 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 868 . 870 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 871 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 872 2003, . 874 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure 875 for the Security Suitability of Cryptographic Algorithms 876 (DSSC)", RFC 5698, DOI 10.17487/RFC5698, November 2009, 877 . 879 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 880 Locator/ID Separation Protocol (LISP)", RFC 6830, 881 DOI 10.17487/RFC6830, January 2013, 882 . 884 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 885 Locator/ID Separation Protocol (LISP) for Multicast 886 Environments", RFC 6831, DOI 10.17487/RFC6831, January 887 2013, . 889 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 890 Protocol (LISP) Map-Server Interface", RFC 6833, 891 DOI 10.17487/RFC6833, January 2013, 892 . 894 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 895 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 896 Multicast - Sparse Mode (PIM-SM): Protocol Specification 897 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 898 2016, . 900 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 901 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 902 February 2017, . 904 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 905 Smirnov, "Locator/ID Separation Protocol Delegated 906 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 907 May 2017, . 909 12.2. Informative References 911 [I-D.coras-lisp-re] 912 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 913 Maino, F., and D. Farinacci, "LISP Replication 914 Engineering", draft-coras-lisp-re-08 (work in progress), 915 November 2015. 917 [I-D.farinacci-lisp-mr-signaling] 918 Farinacci, D. and M. Napierala, "LISP Control-Plane 919 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 920 (work in progress), February 2015. 922 [I-D.ietf-lisp-eid-mobility] 923 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 924 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 925 Unified Control Plane", draft-ietf-lisp-eid-mobility-01 926 (work in progress), November 2017. 928 [I-D.ietf-lisp-sec] 929 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 930 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 931 (work in progress), October 2017. 933 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 934 (LISP) Data-Plane Confidentiality", RFC 8061, 935 DOI 10.17487/RFC8061, February 2017, 936 . 938 Appendix A. Document Change Log 940 A.1. Changes to draft-ietf-lisp-signal-free-multicast-08 942 o Posted February 2018. 944 o Fixed last call editorial comments. 946 A.2. Changes to draft-ietf-lisp-signal-free-multicast-07 948 o Posted November 2017. 950 o Changes after shepherd review and RFC1918 terminology compliant. 952 A.3. Changes to draft-ietf-lisp-signal-free-multicast-06 954 o Posted July 2017. 956 o Stig made a comment about referencing RFC6831 when an RLOC is a 957 multicast address. It opens up a lot of assumptions on what parts 958 of RFC6831 is performed and which parts should not be performed. 959 In the case of signal-free-multicast, join the underlay trees as a 960 multicast host by using IGMP. 962 A.4. Changes to draft-ietf-lisp-signal-free-multicast-05 964 o Posted July 2017. 966 o Make it clear that when a RLE is sent by an ETR and it is already 967 in the merged RLE list on the Map-Server, that the Map-Server 968 replaces the RLE entry (versus adding a duplicate RLE entry to the 969 list). 971 o Make it clear that an RLOC can be a unicast or multicast address. 972 Then make a reference to RFC6831 about mechanisms to support 973 multicast RLOCs. 975 o Fix some typos. 977 A.5. Changes to draft-ietf-lisp-signal-free-multicast-04 979 o Posted May 2017. 981 o Make it clear that recieiver-ETRs need configuraiton information 982 for what Map-Servers (S,G) entries are registered to. 984 o Make it clear this document indicates what RTR layered hierarchy 985 to use and not if its the best hierarchy to use. 987 A.6. Changes to draft-ietf-lisp-signal-free-multicast-03 989 o Posted April 2017. 991 o Add "Multi-Homing Considerations" section to describe the case 992 where a source LISP site has multiple ITRs and the multicast 993 distribution tree at the source site branches to more than one 994 ITR. And at receiver sites where there are multiple ETRs and 995 multiple RLOCs per ETR. 997 A.7. Changes to draft-ietf-lisp-signal-free-multicast-02 999 o Posted October 2016. 1001 o Updated document expiration timer. 1003 A.8. Changes to draft-ietf-lisp-signal-free-multicast-01 1005 o Posted April 2016. 1007 o Add text to define RTRs and indicate how RTR level number is used 1008 for LISP-RE. 1010 o Draw figure 2 that shows a LISP-RE topology. 1012 o Indicate that PIM-ASM or (*,G) trees can be supported in LISP 1013 Signal-Free Multicast. 1015 A.9. Changes to draft-ietf-lisp-signal-free-multicast-00 1017 o Posted late December 2015. 1019 o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP 1020 working group draft. 1022 A.10. Changes to draft-farinacci-lisp-signal-free-multicast-04 1024 o Posted early December 2015. 1026 o Update references and document timer. 1028 A.11. Changes to draft-farinacci-lisp-signal-free-multicast-03 1030 o Posted June 2015. 1032 o Update references and document timer. 1034 A.12. Changes to draft-farinacci-lisp-signal-free-multicast-02 1036 o Posted December 2014. 1038 o Added section about how LISP-RE can use the mechanisms from 1039 signal-free-multicast so we can avoid head-end replication and 1040 avoid signalling across a layered RE topology. 1042 A.13. Changes to draft-farinacci-lisp-signal-free-multicast-01 1044 o Posted June 2014. 1046 o Changes based on implementation experience of this draft. 1048 A.14. Changes to draft-farinacci-lisp-signal-free-multicast-00 1050 o Posted initial draft February 2014. 1052 Authors' Addresses 1054 Victor Moreno 1055 Cisco Systems 1056 170 Tasman Drive 1057 San Jose, California 95134 1058 USA 1060 Email: vimoreno@cisco.com 1062 Dino Farinacci 1063 lispers.net 1064 San Jose, CA 95120 1065 USA 1067 Email: farinacci@gmail.com