idnits 2.17.1 draft-ietf-lisp-signal-free-multicast-06.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 1, 2017) is 2453 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 868, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-00 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-12 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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: February 2, 2018 lispers.net 6 August 1, 2017 8 Signal-Free LISP Multicast 9 draft-ietf-lisp-signal-free-multicast-06 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 http://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 February 2, 2018. 46 Copyright Notice 48 Copyright (c) 2017 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 (http://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-06 . . . 21 93 A.2. Changes to draft-ietf-lisp-signal-free-multicast-05 . . . 21 94 A.3. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 21 95 A.4. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 22 96 A.5. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 22 97 A.6. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 22 98 A.7. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 22 99 A.8. Changes to draft-farinacci-lisp-signal-free-multicast-04 22 100 A.9. Changes to draft-farinacci-lisp-signal-free-multicast-03 23 101 A.10. Changes to draft-farinacci-lisp-signal-free-multicast-02 23 102 A.11. Changes to draft-farinacci-lisp-signal-free-multicast-01 23 103 A.12. Changes to draft-farinacci-lisp-signal-free-multicast-00 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 When multicast sources and receivers are active at LISP sites, and 109 the core network between the sites does not provide multicast 110 support, a signal-free mechanism can be used to create an overlay 111 that will allow multicast traffic to flow between sites and connect 112 the multicast trees at the different sites. 114 The signal-free mechanism here proposed does not extend PIM over the 115 overlay as proposed in [RFC6831], nor does the mechanism utilize 116 direct signaling between the Receiver-ETRs and Sender-ITRs as 117 described in [I-D.farinacci-lisp-mr-signaling]. The signal-free 118 mechanism proposed reduces the amount of signaling required between 119 sites to a minimum and is centered around the registration of 120 Receiver-sites for a particular multicast-group or multicast-channel 121 with the LISP Mapping System. 123 Registrations from the different receiver-sites will be merged at the 124 Mapping System to assemble a multicast-replication-list inclusive of 125 all RLOCs that lead to receivers for a particular multicast-group or 126 multicast-channel. The replication-list for each specific multicast- 127 entry is maintained as a LISP database mapping entry in the Mapping 128 Database. 130 When the ITR at the source-site receives multicast traffic from 131 sources at its site, the ITR can query the mapping system by issuing 132 Map-Request messages for the (S,G) source and destination addresses 133 in the packets received. The Mapping System will return the RLOC 134 replication-list to the ITR, which the ITR will cache as per standard 135 LISP procedure. Since the core is assumed to not support multicast, 136 the ITR will replicate the multicast traffic for each RLOC on the 137 replication-list and will unicast encapsulate the traffic to each 138 RLOC. The combined function or replicating and encapsulating the 139 traffic to the RLOCs in the replication-list is referred to as "rep- 140 encapsulation" in this document. 142 The document describes the General Procedures and information 143 encoding that are required at the Receiver-sites and Source-sites to 144 achieve signal-free multicast interconnectivity. The General 145 Procedures for Mapping System Notifications to different sites are 146 also described. A section dedicated to the specific case of SSM 147 trees discusses the implications to the General Procedures for SSM 148 multicast trees over different topological scenarios. A section on 149 ASM support is included to identify the constraints that come along 150 with supporting it using LISP Signal-Free multicast. 152 There is a section dedicated to Replication Engineering. A mechanism 153 to reduce the impact of head-end replication. The mapping system, 154 via LISP Signal-Free mechanisms, can be used to build a layer of 155 RTRs. 157 2. Definition of Terms 159 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 160 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 161 Resolver (MR) are defined in the LISP specification [RFC6830]. 163 Extensions to the definitions in [RFC6830] for their application to 164 multicast routing are documented in [RFC6831]. 166 Terms defining interactions with the LISP Mapping System are defined 167 in [RFC6833]. 169 The following terms are consistent with the definitions in [RFC6830] 170 and [RFC6831]. The terms are specific cases of the general terms and 171 are here defined to facilitate the descriptions and discussions 172 within this particular document. 174 Source: Multicast source end-point. Host originating multicast 175 packets. 177 Receiver: Multicast group member end-point. Host joins multicast 178 group as a receiver of multicast packets sent to the group. 180 Receiver-site: LISP site where multicast receivers are located. 182 Source-site: LISP site where multicast sources are located. 184 RP-site: LISP site where an ASM PIM Rendezvous Point is located. The 185 RP-site and the Source-site may be the same in some situations. 187 Receiver-ETR: LISP xTR at the Receiver-site. This is a multicast 188 ETR. 190 Source-ITR: LISP xTR at the Source-site. This is a multicast ITR. 192 RP-xTR: LISP xTR at the RP-site. This is typically a multicast ITR. 194 Replication-list: Mapping-entry containing the list of RLOCs that 195 have registered Receivers for a particular multicast-entry. 197 Multicast-entry: A tuple identifying a multicast tree. Multicast- 198 entries are in the form of (S-prefix, G-prefix). 200 Rep-encapsulation: The process of replicating and then encapsulating 201 traffic to multiple RLOCs. 203 Re-encapsulating Tunnel Router (RTR): An RTR is a router that 204 implements the re-encapsulating tunnel function detailed in Section 8 205 of the main LISP specification [RFC6830]. A LISP RTR performs packet 206 re-routing by chaining ETR and ITR functions, whereby it first 207 removes the LISP header of an ingress packet and then prepends a new 208 LISP header to an egress packet. 210 RTR Level: An RTR level is encoded in a Replication-List-Entry (RLE) 211 LCAF Type detailed in [RFC8060]. Each entry in the replication list 212 contains an address of an xTR and a level value. Level values are 213 used to create a replication hierarchy so that ITRs at source LISP 214 sites replicate to the lowest (smaller value) level number RTRs in a 215 RLE entry. And then RTRs at a given level replicate to the next 216 higher level of RTRs. The number of RTRs at each level are 217 engineered to control the fan-out or replication factor so a tradeoff 218 between the width of the level versus the number of levels can be 219 selected. 221 3. Reference Model 223 The reference model that will be used for the discussion of the 224 Signal-Free multicast tree interconnection is illustrated in 225 Figure 1. 227 MS/MR 228 +---+ 229 | | 230 +---+ +---+ +---+ +---+ +---+ 231 Src-1 ----| R1|-----|ITR| | |ETR|------| R2|------ Rcv-2 232 +---+ +---+ | +---+ +---+ 233 \ | / 234 Source-site-1 \ | / Receiver-site-2 235 \ | / 236 \ | / 237 \ | / 238 Core 239 / \ 240 / \ 241 / \ 242 / \ 243 / \ 244 +---+ +---+ 245 Src-3 --------------|ITR| |ETR|----------------- Rcv-4 246 +---+ +---+ 248 Source-site-3 Receiver-site-4 250 Figure 1: LISP Multicast Generic Reference Model 252 Sites 1 and 3 are Source-sites. 254 Source-site-3 presents a Source (Src-3) that is directly connected to 255 the Source-ITR 257 Source-site-1 presents a Source (Src-1) that is one hop or more away 258 from the Source-ITR 260 Receiver-site-2 and 4 are receiver sites with not-directly connected 261 and directly connected Receiver end-points respectively 263 R1 is a router in Source-site-1. 265 R2 is a PIM router at the Receiver-site. 267 The Map-Servers and Resolvers are reachable in the RLOC space in the 268 Core, only one is shown for illustration purposes, but these can be 269 many or even part of a DDT tree. 271 The procedures for interconnecting multicast Trees over an overlay 272 can be broken down into three functional areas: 274 o Receiver-site procedures 276 o Source-site procedures 278 o LISP notification procedures 280 The receiver site procedures will be common for most tree types and 281 topologies. 283 The procedures at the source site can vary depending on the type of 284 trees being interconnected as well as based on the topological 285 relation between sources and source-site xTRs. For ASM trees, a 286 special case of the Source-site is the RP-site for which a variation 287 of the Source-site procedures may be necessary if ASM trees are to be 288 supported in future specifications of LISP Signal-Free multicast. 290 The LISP notification procedures between sites are normalized for the 291 different possible scenarios. Certain scenarios may benefit from a 292 simplified notification mechanism or no notification requirement at 293 all. 295 4. General Procedures 297 The interconnection of multicast trees across different LISP sites 298 involves the following procedures to build the necessary multicast 299 distribution trees across sites. 301 1. The presence of multicast Receiver end-points is detected by the 302 Receiver-ETRs at the Receiver-sites. 304 2. Receiver-ETRs register their RLOCs as part of the replication- 305 list for the multicast-entry the detected Receivers subscribe to. 307 3. The Mapping-system merges all receiver-ETR or delivery-group 308 RLOCs to build a comprehensive replication-list inclusive of all 309 Receiver-sites for each multicast-entry. 311 4. LISP Map-Notify messages should be sent to the Source-ITR 312 informing of any changes in the replication-list. 314 5. Multicast-tree building at the Source-site is initiated when the 315 Source-ITR receives the LISP Notification. 317 Once the multicast distribution trees are built, the following 318 forwarding procedures may take place: 320 1. The Source sends multicast packets to the multicast group 321 destination address. 323 2. Multicast traffic follows the multicast tree built at the Source- 324 site and makes its way to the Source-ITRs. 326 3. The Source-ITR will issue a map-request to resolve the 327 replication-list for the multicast-entry. 329 4. The Mapping System responds to the Source-ITR with a map-reply 330 containing the replication-list for the multicast group 331 requested. 333 5. The Source-ITR caches the replication-list received in the map- 334 reply for the multicast-entry. 336 6. Multicast traffic is rep-encapsulated. That is, the packet is 337 replicated for each RLOC in the replication-list and then 338 encapsulated to each one. 340 4.1. General Receiver-Site Procedures 342 4.1.1. Multicast Receiver Detection 344 When the Receiver-ETRs are directly connected to the Receivers (e.g. 345 Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP 346 Reports from the Receivers indicating which group the Receivers wish 347 to subscribe to. Based on these IGMP Reports, the receiver-ETR is 348 made aware of the presence of Receivers as well as which group they 349 are interested in. 351 When the Receiver-ETRs are several hops away from the Receivers (e.g. 352 Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join 353 messages which will allow the Receiver-ETR to know that there are 354 multicast Receivers at the site and also learn which multicast group 355 the Receivers are for. 357 4.1.2. Receiver-Site Registration 359 Once the Receiver-ETRs detect the presence of Receivers at the 360 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 361 include the Receiver-ETR RLOCs in the replication-list for the 362 multicast-entry the Receivers joined. 364 The Map-Register message will use the multicast-entry (Source, Group) 365 tuple as its EID record type with the Receiver-ETR RLOCs conforming 366 the locator set. 368 The EID in the Map-Register message must be encoded using the 369 Multicast Information LCAF type defined in [RFC8060]. 371 The RLOC in the Map-Register message must be encoded using the 372 Replication List Entry (RLE) LCAF type defined in [RFC8060] with the 373 Level Value fields for all entries set to 128 (decimal). 375 The encoding described above must be used consistently for Map- 376 Register messages, entries in the Mapping Database, Map-reply 377 messages as well as the map-cache at the Source-ITRs. 379 The Map-Register messages [RFC6830] sent by the receiver-ETRs should 380 have the following bits set as here specified: 382 1. merge-request-bit set to 1. The Map-Register messages must be 383 sent with "Merge Semantics". The Map-Server will receive 384 registrations from a multitude of Receiver-ETRs. The Map-Server 385 will merge the registrations for common EIDs and maintain a 386 consolidated replication-list for each multicast-entry. 388 2. want-map-notify-bit (M) set to 0. This tells the Mapping System 389 that the receiver-ETR does not expect to receive Map-Notify 390 messages as it does not need to be notified of all changes to the 391 replication-list. 393 3. proxy-reply-bit (P) set to 1. The merged replication-list is 394 kept in the Map-Servers. By setting the proxy-reply bit, the 395 receiver-ETRs instruct the Mapping-system to proxy reply to map- 396 requests issued for the multicast entries. 398 Map-Register messages for a particular multicast-entry should be sent 399 for every receiver detected, even if previous receivers have been 400 detected for the particular multicast-entry. This allows the 401 replication-list to remain up to date. 403 Receiver-ETRs must be configured to know what Map-Servers Map- 404 Register messages are sent to. The configuration is likely to be 405 associated with an S-prefix that multiple (S,G) entries match to and 406 are more specific for. Therefore, the S-prefix determines the Map- 407 Server set in the least number of configuration statements. 409 4.1.3. Consolidation of the Replication-List 411 The Map-Server will receive registrations from a multitude of 412 Receiver-ETRs. The Map-Server will merge the registrations for 413 common EIDs and consolidate a replication-list for each multicast- 414 entry. 416 When an ETR sends an RLE RLOC-record in a Map-Register and the RLE 417 entry already exists in the Map-Server's RLE merged list, the Map- 418 Server will replace the single RLE entry with the information from 419 the Map-Register RLOC-record. The Map-Server MUST never merge 420 duplicate RLOCs in the consolidated replication-list. 422 4.2. General Source-Site Procedures 424 Source-ITRs must register the unicast EIDs of any Sources or 425 Rendezvous Points that may be present on the Source-site. In other 426 words, it is assumed that the Sources and RPs are LISP EIDs. 428 The registration of the unicast EIDs for the Sources or Rendezvous 429 Points allows the map-server to know where to send Map-Notify 430 messages to. Therefore, the Source-ITR must register the unicast 431 S-prefix EID with the want-map-notify-bit set in order to receive 432 Map-Notify messages whenever there is a change in the replication- 433 list. 435 4.2.1. Multicast Tree Building at the Source-Site 437 When the source site receives the Map-Notify messages from the 438 mapping system as described in Section 4.3, it will initiate the 439 process of building a multicast distribution tree that will allow the 440 multicast packets from the Source to reach the Source-ITR. 442 The Source-ITR will issue a PIM join for the multicast-entry for 443 which it received the Map-Notify message. The join will be issued in 444 the direction of the source or in the direction of the RP for the SSM 445 and ASM cases respectively. 447 4.2.2. Multicast Destination Resolution 449 On reception of multicast packets, the source-ITR must obtain the 450 replication-list for the (S,G) addresses in the packets. 452 In order to obtain the replication-list, the Source-ITR must issue a 453 Map-Request message in which the EID is the (S,G) multicast tuple 454 which is encoded using the Multicast Info LCAF type defined in 455 [RFC8060]. 457 The Mapping System (most likely the Map-Server) will Map-reply with 458 the merged replication-list maintained in the Mapping System. The 459 Map-reply message must follow the format defined in [RFC6830], its 460 EID must be encoded using the Multicast Info LCAF type and the 461 corresponding RLOC-records must be encoded using the RLE LCAF type. 462 Both LCAF types defined in [RFC8060]. 464 4.3. General LISP Notification Procedures 466 The Map-Server will issue LISP Map-Notify messages to inform the 467 Source-site of the presence of receivers for a particular multicast 468 group over the overlay. 470 Updated Map-Notify messages should be issued every time a new 471 registration is received from a Receiver-site. This guarantees that 472 the source-sites are aware of any potential changes in the multicast- 473 distribution-list membership. 475 The Map-Notify messages carry (S,G) multicast EIDs encoded using the 476 Multicast Info LCAF type defined in [RFC8060]. 478 Map-Notify messages will be sent by the Map-Server to the RLOCs with 479 which the unicast S-prefix EID was registered. In the case when 480 sources are discovered dynamically [I-D.ietf-lisp-eid-mobility], xTRs 481 must register sources explicitly with the want-map-notify-bit set. 482 This is so the ITR in the site the source has moved to can get the 483 most current replication list. 485 When both the Receiver-sites and the Source-sites register to the 486 same Map-Server, the Map-Server has all the necessary information to 487 send the Map-Notify messages to the Source-site. 489 When the Map-Servers are distributed in a DDT, the Receiver-sites may 490 register to one Map-Server while the Source-site registers to a 491 different Map-Server. In this scenario, the Map-Server for the 492 receiver sites must resolve the unicast S-prefix EID in the DDT per 493 standard LISP lookup procedures and obtain the necessary information 494 to send the Map-Notify messages to the Source-site. The Map-Notify 495 messages must be sent with an authentication length of 0 as they 496 would not be authenticated. 498 When the Map-Servers are distributed in a DDT, different Receiver- 499 sites may register to different Map-Servers. This is an unsupported 500 scenario with the currently defined mechanisms. 502 5. Source Specific Multicast Trees 504 The interconnection of Source Specific Multicast (SSM) Trees across 505 sites will follow the General Receiver-site Procedures described in 506 Section 4.1 on the Receiver-sites. 508 The Source-site Procedures will vary depending on the topological 509 location of the Source within the Source-site as described in 510 Section 5.1 and Section 5.2 . 512 5.1. Source Directly Connected to Source-ITRs 514 When the Source is directly connected to the source-ITR, it is not 515 necessary to trigger signaling to build a local multicast tree at the 516 Source-site. Therefore Map-Notify messages may not be required to 517 initiate building of the multicast tree at the Source-site. 519 Map-Notify messages are still required to ensure that any changes to 520 the replication-list are communicated to the Source-site so that the 521 map-cache at the Source-ITRs is kept updated. 523 5.2. Source not Directly Connected to Source-ITRs 525 The General LISP Notification Procedures described in Section 4.3 526 must be followed when the Source is not directly connected to the 527 source-ITR. On reception of Map-Notify messages, local multicast 528 signaling must be initiated at the Source-site per the General Source 529 Site Procedures for Multicast Tree building described in 530 Section 4.2.1. 532 In the SSM case, the IP address of the Source is known and it is also 533 registered with the LISP mapping system. Thus, the mapping system 534 may resolve the mapping for the Source address in order to send Map- 535 Notify messages to the correct source-ITR. 537 6. Multi-Homing Considerations 539 6.1. Multiple ITRs at a Source-Site 541 When multiple ITRs exist at a source multicast site, care should be 542 taken that more than one ITR does not head-end replicate packets else 543 receiver multicast sites will receive duplicate packets. The 544 following procedures will be used for each topology scenarios: 546 o When more than one ITR is directly connected to the source host, 547 either the PIM DR or the IGMP querier (when PIM is not enabled on 548 the ITRs) is responsible for packet replication. All other ITRs 549 silently drop the packet. In the IGMP querier case, it is 550 required to configure the source LAN to have one of the ITRs be 551 the IGMP querier. 553 o When more than one ITR is multiple hops away from the source host 554 and one of the ITRs is the PIM Rendezvous Point, then the PIM RP 555 is responsible for packet replication. 557 o When more than one ITR is multiple hops away from the source host 558 and the PIM Rendezvous Point is not one of the ITRs, then one of 559 the ITRs must join to the RP. When a Map-Notify is received from 560 the Map-Server by an ITR, only the highest RLOC addressed ITR will 561 join toward the PIM RP or toward the source. 563 6.2. Multiple ETRs at a Receiver-Site 565 When multiple ETRs exist in a receiver multicast site, and each 566 create multicast join state, they each Map-Register their RLOC 567 addresses to the mapping system. In this scenario, the replication 568 happens on the overlay causing multiple ETR entry points to replicate 569 to all receivers versus a single ETR entry point replicating to all 570 receivers. If an ETR does not create join state, because it has not 571 received PIM joins or IGMP reports, it will not Map-Register its RLOC 572 addresses to the mapping system. The same procedures in Section 4.1 573 should be followed. 575 When multiple ETRs exist on the same LAN as a receiver host, then the 576 PIM DR, when PIM is enabled, or the IGMP querier is responsible for 577 sending a Map-Register for its RLOC. In the IGMP case, it is 578 required that the LAN is configured with one of the ETRs as IGMP 579 querier. 581 6.3. Multiple RLOCs for an ETR at a Receiver-Site 583 It may be desirable to have multiple underlay paths to an ETR for 584 multicast packet delivery. This can be done by having multiple RLOCs 585 assigned to an ETR and having the ETR send Map-Registers for all its 586 RLOCs. By doing this, an ITR can choose a specific path based on 587 underlay performance and/or RLOC reachability. 589 It is suggested that an ETR sends a Map-Register with a single RLOC- 590 record that uses the ELP LCAF type [RFC8060] that is nested inside 591 RLE entry LCAF. For example say ETR1 has assigned RLOC1 and RLOC2 592 for a LISP receiver site. And there is ETR2 in another LISP receiver 593 site, that has RLOC3. The two receiver sites have the same (S,G) 594 being joined. Here is how the RLOC-record is encoded on each ETR: 596 ETR1: EID-record: (S,G) 597 RLOC-record: RLE[ ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] 599 ETR2: EID-record: (S,G) 600 RLOC-record: RLE[ RLOC3 ] 602 And here is how the entry is merged and stored on the Map-Server 603 since the Map-Registers have an RLE encoded RLOC-record: 605 MS: EID-record: (S,G) 606 RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] 608 When the ITR receives a packet from a multicast source S for group G, 609 it uses the merged RLOC-record, returned from the Map-Server. The 610 ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). 611 Since it is required for the s-bit to be set for RLOC1, the ITR must 612 replicate to RLOC1 if it is reachable. When the required p-bit is 613 also set, the RLOC-reachability mechanisms from [RFC6830] are 614 followed. If the ITR determines that RLOC1 is unreachable, it uses 615 RLOC2, as long as RLOC2 is reachable. 617 6.4. Multicast RLOCs for an ETR at a Receiver-Site 619 This specification is focused on underlays without multicast support, 620 but does not preclude the use of multicast RLOCs in RLE entries. 621 ETRs MAY register multicast EID entries using multicast RLOCs. In 622 such cases the ETRs will get joined to underlay multicast 623 distribution trees by using IGMP as a multicast host using mechanisms 624 in [RFC2236] and [RFC3376]. 626 7. PIM Any Source Multicast Trees 628 LISP signal-free multicast can support ASM Trees in limited but 629 acceptable topologies. It is suggested for the simplification of 630 building ASM trees across the LISP overlay to have PIM-ASM run 631 independently in each LISP site. What this means, is that a PIM 632 Rendezvous Point (RP) is configured in each LISP site so PIM Register 633 procedures and (*,G) state maintenance is contained within the LISP 634 site. 636 The following procedure will be used to support ASM in each LISP 637 site: 639 1. In a Receiver-site, the RP is colocated with the ETR. RPs for 640 different groups can be spread across each ETR, but is not 641 required. 643 2. When (*,G) state is created in an ETR, the procedures in 644 Section 4.1.2 are followed. In addition, the ETR registers 645 (S-prefix,G), where S-prefix is 0/0 (the respective unicast 646 default route for the address-family) to the mapping system. 648 3. In a Source-site, the RP is colocated with the ITR. RPs for 649 different groups can be spread across each ITR, but is not 650 required. 652 4. When a multicast source sends a packet, a PIM Register message is 653 delivered to the ITR and the procedures in Section 4.2 are 654 followed. 656 5. When the the ITR sends a Map-Request for (S,G) and no Receiver- 657 site has registered for (S,G), the mapping system will return the 658 (0/0,G) entry to the ITR so it has a replication list of all the 659 ETRs that have received (*,G) state. 661 6. The ITR stores the replication-list in its map-cache for (S,G). 662 It replicates packets to all ETRs in the list. 664 7. ETRs decapsulate packets and forward based on (*,G) state in 665 their site. 667 8. When last-hop PIM routers join the newly discovered (S,G), the 668 ETR will store the state and follow the procedures in 669 Section 4.1.2. 671 8. Signal-Free Multicast for Replication Engineering 673 The mechanisms in this draft can be applied to the LISP Replication- 674 Engineering [I-D.coras-lisp-re] design. Rather than having the 675 layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can 676 register their availability for multicast tree replication via the 677 mapping database system. 679 As stated in [I-D.coras-lisp-re], the RTR layered hierarchy is used 680 to avoid head-end replication in replicating nodes closest to a 681 multicast source. Rather than have multicast ITRs replicate to each 682 ETR in an RLE entry of a (S,G) mapping database entry, it could 683 replicate to one or more layer-0 RTRs in the LISP-RE hierarchy. 685 This draft documents how the RTR hierarchy is determined but not what 686 are the optimal layers of RTRs to use. Methods for determining 687 optimal paths or RTR topological closeness are out of scope for his 688 document. 690 There are two formats an (S,G) mapping database entry could have. 691 One format is a 'complete-format' and the other is a 'filtered- 692 format'. A 'complete-format' entails an (S,G) entry having multiple 693 RLOC records which contain both ETRs that have registered as well as 694 the RTRs at the first level of the LISP-RE hierarchy for the ITR to 695 replicate to. When using 'complete-format', the ITR has the ability 696 to select if it replicates to RTRs or to the registered ETRs at the 697 receiver sites. A 'filtered-format' (S,G) entry is one where the 698 Map-Server returns the RLOC-records that it decides the ITR should 699 use. So replication policy is shifted from the ITRs to the mapping 700 system. The Map-Servers can also decide for a given ITR, if it uses 701 a different set of replication targets per (S,G) entry for which the 702 ITR is replicating for. 704 The procedure for the LISP-RE RTRs to make themselves available for 705 replication can occur before or after any receivers join an (S,G) 706 entry or any sources send for a particular (S,G) entry. Therefore, 707 newly configured RTR state will be used to create new (S,G) state and 708 inherited into existing (S,G) state. A set of RTRs can register 709 themselves to the mapping system or a third-party can do so on their 710 behalf. When RTR registration occurs, it is done with an (S-prefix, 711 G-prefix) entry so it can advertise its replication services for a 712 wide-range of source/group combinations. 714 When a Map-Server receives (S,G) registrations from ETRs and 715 (S-prefix, G-prefix) registrations from RTRs, it has the option of 716 merging the RTR RLOC-records for each (S,G) that is more-specific for 717 the (S-prefix, G-prefix) entry or keep them separate. When merging, 718 a Map-Server is ready to return a 'complete-format' Map-Reply. When 719 keeping the entries separate, the Map-Server can decide what to 720 include in a Map-Reply when a Map-Request is received. It can 721 include a combination of RLOC-records from each entry or decide to 722 use one or the other depending on policy configured. 724 +---+ +----+ 725 Src-1 --------------|ITR| |ETR1|----------------- Rcv-1 726 +---+ +----+ 727 \ / 728 Source-site-1 \ / Receiver-site-1 729 \ / 730 \ / 731 +----+ \ / +----+ 732 |RTR1| \ / |RTR2| Level-0 733 +----+ \ / +----+ 734 \ <^^^^^^^^^^^^^^> / 735 \ < > / 736 < Core-Network > 737 < > 738 739 / / \ \ 740 / / \ \ 741 +----+ / / \ \ +----+ 742 |RTR3| / \ |RTR4| Level-1 743 +----+ / \ +----+ 744 / \ 745 / \ 746 +----+ +----+ 747 Rcv-2 --------------|ETR2| |ETR3|----------------- Rcv-3 748 +----+ +----+ 750 Receiver-site-2 Receiver-site-3 752 Figure 2: LISP-RE Reference Model 754 Here is a specific example, illustrated in Figure 2, of (S,G) and 755 (S-prefix, G-prefix) mapping database entries when a source S is 756 behind an ITR and there are receiver sites joined to (S,G) via ETR1, 757 ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and 758 RTR2 at level-0 and RTR3 and RTR4 at level-1: 760 EID-record: (S,G) 761 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 762 EID-record: (S-prefix, G-prefix) 763 RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1 765 The above entries are in the form of how they were registered and 766 stored in a Map-Server. When a Map-Server uses 'complete-format', a 767 Map-Reply it originates has the mapping record encoded as: 769 EID-record: (S,G) 770 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 771 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 773 The above Map-Reply allows the ITR to decide if it replicates to the 774 ETRs or if it should replicate only to level-0 RTR1. This decision 775 is left to the ITR since both RLOC-records have priority 1. If the 776 Map-Server wanted to force the ITR to replicate to RTR1, it would set 777 the ETRs RLOC-record to priority greater than 1. 779 When a Map_server uses "filtered-format', a Map-Reply it originates 780 has the mapping record encoded as: 782 EID-record: (S,G) 783 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 785 An (S,G) entry can contain alternate RTRs. So rather than 786 replicating to multiple RTRs, one of a RTR set may be used based on 787 the RTR reachability status. An ITR can test reachability status to 788 any layer-0 RTR using RLOC-probing so it can choose one RTR from a 789 set to replicate to. When this is done the RTRs are encoded in 790 different RLOC-records versus together in one RLE RLOC-record. This 791 moves the replication load off the ITRs at the source site to the 792 RTRs inside the network infrastructure. This mechanism can also be 793 used by level-n RTRs to level-n+1 RTRs. 795 The following mapping would be encoded in a Map-Reply sent by a Map- 796 Server and stored in the ITR. The ITR would use RTR1 until it went 797 unreachable and then switch to use RTR2: 799 EID-record: (S,G) 800 RLOC-record: RTR1, p1 801 RLOC-record: RTR2, p2 803 9. Security Considerations 805 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 806 origin authentication, integrity and anti-replay protection to LISP's 807 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 808 SEC also enables verification of authorization on EID-prefix claims 809 in Map-Reply messages. 811 Additional security mechanisms to protect the LISP Map-Register 812 messages are defined in [RFC6833]. 814 The security of the Mapping System Infrastructure depends on the 815 particular mapping database used. The [I-D.ietf-lisp-ddt] 816 specification, as an example, defines a public-key based mechanism 817 that provides origin authentication and integrity protection to the 818 LISP DDT protocol. 820 Map-Replies received by the source-ITR can be signed (by the Map- 821 Server) so the ITR knows the replication-list is from a legit source. 823 Data-plane encryption can be used when doing unicast rep- 824 encapsulation as described in [RFC8061]. For further study we will 825 look how to do multicast rep-encapsulation. 827 10. IANA Considerations 829 This document has no IANA implications 831 11. Acknowledgements 833 The authors want to thank Greg Shepherd, Joel Halpern and Sharon 834 Barkai for their insightful contribution to shaping the ideas in this 835 document. Thanks also goes to Jimmy Kyriannis, Paul Vinciguerra, 836 Florin Coras, and Yan Filyurin for testing an implementation of this 837 draft. 839 12. References 841 12.1. Normative References 843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", BCP 14, RFC 2119, 845 DOI 10.17487/RFC2119, March 1997, 846 . 848 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 849 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 850 . 852 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 853 Thyagarajan, "Internet Group Management Protocol, Version 854 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 855 . 857 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 858 Discovery Protocol (MSDP)", RFC 3618, 859 DOI 10.17487/RFC3618, October 2003, 860 . 862 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 863 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 864 Protocol Specification (Revised)", RFC 4601, 865 DOI 10.17487/RFC4601, August 2006, 866 . 868 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 869 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 870 . 872 12.2. Informative References 874 [I-D.coras-lisp-re] 875 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 876 Maino, F., and D. Farinacci, "LISP Replication 877 Engineering", draft-coras-lisp-re-08 (work in progress), 878 November 2015. 880 [I-D.farinacci-lisp-mr-signaling] 881 Farinacci, D. and M. Napierala, "LISP Control-Plane 882 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 883 (work in progress), February 2015. 885 [I-D.ietf-lisp-ddt] 886 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 887 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 888 ddt-09 (work in progress), January 2017. 890 [I-D.ietf-lisp-eid-mobility] 891 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 892 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 893 Unified Control Plane", draft-ietf-lisp-eid-mobility-00 894 (work in progress), May 2017. 896 [I-D.ietf-lisp-sec] 897 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 898 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 899 (work in progress), November 2016. 901 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 902 Locator/ID Separation Protocol (LISP)", RFC 6830, 903 DOI 10.17487/RFC6830, January 2013, 904 . 906 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 907 Locator/ID Separation Protocol (LISP) for Multicast 908 Environments", RFC 6831, DOI 10.17487/RFC6831, January 909 2013, . 911 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 912 Protocol (LISP) Map-Server Interface", RFC 6833, 913 DOI 10.17487/RFC6833, January 2013, 914 . 916 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 917 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 918 February 2017, . 920 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 921 (LISP) Data-Plane Confidentiality", RFC 8061, 922 DOI 10.17487/RFC8061, February 2017, 923 . 925 Appendix A. Document Change Log 927 A.1. Changes to draft-ietf-lisp-signal-free-multicast-06 929 o Posted July 2017. 931 o Stig made a comment about referencing RFC6831 when an RLOC is a 932 multicast address. It opens up a lot of assumptions on what parts 933 of RFC6831 is performed and which parts should not be performed. 934 In the case of signal-free-multicast, join the underlay trees as a 935 multicast host by using IGMP. 937 A.2. Changes to draft-ietf-lisp-signal-free-multicast-05 939 o Posted July 2017. 941 o Make it clear that when a RLE is sent by an ETR and it is already 942 in the merged RLE list on the Map-Server, that the Map-Server 943 replaces the RLE entry (versus adding a duplicate RLE entry to the 944 list). 946 o Make it clear that an RLOC can be a unicast or multicast address. 947 Then make a reference to RFC6831 about mechanisms to support 948 multicast RLOCs. 950 o Fix some typos. 952 A.3. Changes to draft-ietf-lisp-signal-free-multicast-04 954 o Posted May 2017. 956 o Make it clear that recieiver-ETRs need configuraiton information 957 for what Map-Servers (S,G) entries are registered to. 959 o Make it clear this document indicates what RTR layered hierarchy 960 to use and not if its the best hierarchy to use. 962 A.4. Changes to draft-ietf-lisp-signal-free-multicast-03 964 o Posted April 2017. 966 o Add "Multi-Homing Considerations" section to describe the case 967 where a source LISP site has multiple ITRs and the multicast 968 distribution tree at the source site branches to more than one 969 ITR. And at receiver sites where there are multiple ETRs and 970 multiple RLOCs per ETR. 972 A.5. Changes to draft-ietf-lisp-signal-free-multicast-02 974 o Posted October 2016. 976 o Updated document expiration timer. 978 A.6. Changes to draft-ietf-lisp-signal-free-multicast-01 980 o Posted April 2016. 982 o Add text to define RTRs and indicate how RTR level number is used 983 for LISP-RE. 985 o Draw figure 2 that shows a LISP-RE topology. 987 o Indicate that PIM-ASM or (*,G) trees can be supported in LISP 988 Signal-Free Multicast. 990 A.7. Changes to draft-ietf-lisp-signal-free-multicast-00 992 o Posted late December 2015. 994 o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP 995 working group draft. 997 A.8. Changes to draft-farinacci-lisp-signal-free-multicast-04 999 o Posted early December 2015. 1001 o Update references and document timer. 1003 A.9. Changes to draft-farinacci-lisp-signal-free-multicast-03 1005 o Posted June 2015. 1007 o Update references and document timer. 1009 A.10. Changes to draft-farinacci-lisp-signal-free-multicast-02 1011 o Posted December 2014. 1013 o Added section about how LISP-RE can use the mechanisms from 1014 signal-free-multicast so we can avoid head-end replication and 1015 avoid signalling across a layered RE topology. 1017 A.11. Changes to draft-farinacci-lisp-signal-free-multicast-01 1019 o Posted June 2014. 1021 o Changes based on implementation experience of this draft. 1023 A.12. Changes to draft-farinacci-lisp-signal-free-multicast-00 1025 o Posted initial draft February 2014. 1027 Authors' Addresses 1029 Victor Moreno 1030 Cisco Systems 1031 170 Tasman Drive 1032 San Jose, California 95134 1033 USA 1035 Email: vimoreno@cisco.com 1037 Dino Farinacci 1038 lispers.net 1039 San Jose, CA 95120 1040 USA 1042 Email: farinacci@gmail.com