idnits 2.17.1 draft-farinacci-lisp-signal-free-multicast-03.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 is 1 instance 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 8, 2015) is 3244 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 642, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-07 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-crypto-01 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-08 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-08 -- 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 (~~), 10 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: December 10, 2015 lispers.net 6 June 8, 2015 8 Signal-Free LISP Multicast 9 draft-farinacci-lisp-signal-free-multicast-03 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 de-capsulators 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 December 10, 2015. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. General Receiver-site Procedures . . . . . . . . . . . . 7 68 4.1.1. Multicast receiver detection . . . . . . . . . . . . 7 69 4.1.2. Receiver-site Registration . . . . . . . . . . . . . 7 70 4.1.3. Consolidation of the replication-list . . . . . . . . 9 71 4.2. General Source-site Procedures . . . . . . . . . . . . . 9 72 4.2.1. Multicast Tree Building at the Source-site . . . . . 9 73 4.2.2. Multicast Destination Resolution . . . . . . . . . . 9 74 4.3. General LISP Notification Procedures . . . . . . . . . . 10 75 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 10 76 5.1. Source directly connected to Source-ITRs . . . . . . . . 11 77 5.2. Source not directly connected to Source-ITRs . . . . . . 11 78 6. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 11 79 7. Signal-Free Multicast for Replication Engineering . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 15 87 A.1. Changes to draft-farinacci-lisp-signal-free-multicast-03 15 88 A.2. Changes to draft-farinacci-lisp-signal-free-multicast-02 16 89 A.3. Changes to draft-farinacci-lisp-signal-free-multicast-01 16 90 A.4. Changes to draft-farinacci-lisp-signal-free-multicast-00 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 When multicast sources and receivers are active at LISP sites, and 96 the core network between the sites does not provide multicast 97 support, a signal-free mechanism can be used to create an overlay 98 that will allow multicast traffic to flow between sites and connect 99 the multicast trees at the different sites. 101 The signal-free mechanism here proposed does not extend PIM over the 102 overlay as proposed in [RFC6831], nor does the mechanism utilize 103 direct signaling between the Receiver-ETRs and Sender-ITRs as 104 described in [I-D.farinacci-lisp-mr-signaling]. The signal-free 105 mechanism proposed reduces the amount of signaling required between 106 sites to a minimum and is centered around the registration of 107 Receiver-sites for a particular multicast-group or multicast-channel 108 with the LISP Mapping System. 110 Registrations from the different receiver-sites will be merged at the 111 Mapping System to assemble a multicast-replication-list inclusive of 112 all RLOCs that lead to receivers for a particular multicast-group or 113 multicast-channel. The replication-list for each specific multicast- 114 entry is maintained as a LISP database mapping entry in the Mapping 115 Database. 117 When the ITR at the source-site receives multicast traffic from 118 sources at its site, the ITR can query the mapping system by issuing 119 Map-Request messages for the (S,G) source and destination addresses 120 in the packets received. The Mapping System will return the RLOC 121 replication-list to the ITR, which the ITR will cache as per standard 122 LISP procedure. Since the core is assumed to not support multicast, 123 the ITR will replicate the multicast traffic for each RLOC on the 124 replication-list and will unicast encapsulate the traffic to each 125 RLOC. The combined function or replicating and encapsulating the 126 traffic to the RLOCs in the replication-list is referred to as "rep- 127 encapsulation" in this document. 129 The document describes the General Procedures and information 130 encoding that are required at the Receiver-sites and Source-sites to 131 achieve signal-free multicast interconnectivity. The General 132 Procedures for Mapping System Notifications to different sites are 133 also described. A section dedicated to the specific case of SSM 134 trees discusses the implications to the General Procedures for SSM 135 multicast trees over different topological scenarios. At this stage 136 ASM trees are not supported with LISP Signal-Free multicast. 138 2. Definition of Terms 140 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 141 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 142 Resolver (MR) are defined in the LISP specification [RFC6830]. 144 Extensions to the definitions in [RFC6830] for their application to 145 multicast routing are documented in [RFC6831]. 147 Terms defining interactions with the LISP Mapping System are defined 148 in [RFC6833]. 150 The following terms are consistent with the definitions in [RFC6830] 151 and [RFC6831]. The terms are specific cases of the general terms and 152 are here defined to facilitate the descriptions and discussions 153 within this particular document. 155 Source: Multicast source end-point. Host originating multicast 156 packets. 158 Receiver: Multicast group member end-point. Host joins multicast 159 group as a receiver of multicast packets sent to the group. 161 Receiver-site: LISP site where multicast receivers are located. 163 Source-site: LISP site where multicast sources are located. 165 RP-site: LISP site where an ASM PIM Rendezvous Point is located. The 166 RP-site and the Source-site may be the same in some situations. 168 Receiver-ETR: LISP xTR at the Receiver-site. This is a multicast 169 ETR. 171 Source-ITR: LISP xTR at the Source-site. This is a multicast ITR. 173 RP-xTR: LISP xTR at the RP-site. This is typically a multicast ITR. 175 Replication-list: Mapping-entry containing the list of RLOCs that 176 have registered Receivers for a particular multicast-entry. 178 Multicast-entry: A tuple identifying a multicast tree. Multicast- 179 entries are in the form of (S-prefix, G-prefix). 181 Rep-encapsulation: The process of replicating and then encapsulating 182 traffic to multiple RLOCs. 184 3. Reference Model 186 The reference model that will be used for the discussion of the 187 Signal-Free multicast tree interconnection is illustrated in 188 Figure 1. 190 MS/MR 191 +---+ 192 | | 193 +---+ +---+ +---+ +---+ +---+ 194 Src-1-----| R1|-----|ITR| | |ETR|------| R2|-------Rcv-2 195 +---+ +---+ | +---+ +---+ 196 \ | / 197 Source-site-1 \ | / Receiver-site-2 198 \ | / 199 \ | / 200 \ | / 201 Core 202 / \ 203 / \ 204 / \ 205 / \ 206 / \ 207 +---+ +---+ 208 Src-3 --------------|ITR| |ETR|------------------Rcv-4 209 +---+ +---+ 211 Source-site-3 Receiver-site-4 213 Figure 1: LISP Multicast Generic Reference Model 215 Sites 1 and 3 are Source-sites. 217 Source-site-3 presents a Source (Src-3) that is directly connected to 218 the Source-ITR 220 Source-site-1 presents a Source (Src-1) that is one hop or more away 221 from the Source-ITR 223 Receiver-site-2 and 4 are receiver sites with not-directly connected 224 and directly connected Receiver end-points respectively 226 R1 is a router in Source-site-1. 228 R2 is a PIM router at the Receiver-site. 230 The Map-Servers and Resolvers are reachable in the RLOC space in the 231 Core, only one is shown for illustration purposes, but these can be 232 many or even part of a DDT tree. 234 The procedures for interconnecting multicast Trees over an overlay 235 can be broken down into three functional areas: 237 o Receiver-site procedures 239 o Source-site procedures 241 o LISP notification procedures 243 The receiver site procedures will be common for most tree types and 244 topologies. 246 The procedures at the source site can vary depending on the type of 247 trees being interconnected as well as based on the topological 248 relation between sources and source-site xTRs. For ASM trees, a 249 special case of the Source-site is the RP-site for which a variation 250 of the Source-site procedures may be necessary if ASM trees are to be 251 supported in future specifications of LISP Signal-Free multicast. 253 The LISP notification procedures between sites are normalized for the 254 different possible scenarios. Certain scenarios may benefit from a 255 simplified notification mechanism or no notification requirement at 256 all. 258 4. General Procedures 260 The interconnection of multicast trees across different LISP sites 261 involves the following procedures to build the necessary multicast 262 distribution trees across sites. 264 1. The presence of multicast Receiver end-points is detected by the 265 Receiver-ETRs at the Receiver-sites. 267 2. Receiver-ETRs register their RLOCs as part of the replication- 268 list for the multicast-entry the detected Receivers subscribe to. 270 3. The Mapping-system merges all receiver-ETR or delivery-group 271 RLOCs to build a comprehensive replication-list inclusive of all 272 Receiver-sites for each multicast-entry. 274 4. LISP Map-Notify messages should be sent to the Source-ITR 275 informing of any changes in the replication-list. 277 5. Multicast-tree building at the Source-site is initiated when the 278 Source-ITR receives the LISP Notification. 280 Once the multicast distribution trees are built, the following 281 forwarding procedures may take place: 283 1. The Source sends multicast packets to the multicast group 284 destination address. 286 2. Multicast traffic follows the multicast tree built at the Source- 287 site and makes its way to the Source-ITRs. 289 3. The Source-ITR will issue a map-request to resolve the 290 replication-list for the multicast-entry. 292 4. The Mapping System responds to the Source-ITR with a map-reply 293 containing the replication-list for the multicast group 294 requested. 296 5. The Source-ITR caches the replication-list received in the map- 297 reply for the multicast-entry. 299 6. Multicast traffic is rep-encapsulated. That is, the packet is 300 replicated for each RLOC in the replication-list and then 301 encapsulated to each one. 303 4.1. General Receiver-site Procedures 305 4.1.1. Multicast receiver detection 307 When the Receiver-ETRs are directly connected to the Receivers (e.g. 308 Receiver-site-4 in Figure 1), the Receiver-ETRs will receive IGMP 309 Reports from the Receivers indicating which group the Receivers wish 310 to subscribe to. Based on these IGMP Reports, the receiver-ETR is 311 made aware of the presence of Receivers as well as which group they 312 are interested in. 314 When the Receiver-ETRs are several hops away from the Receivers (e.g. 315 Receiver-site-2 in Figure 1), the Receiver-ETRs will receive PIM join 316 messages which will allow the Receiver-ETR to know that there are 317 multicast Receivers at the site and also learn which multicast group 318 the Receivers are for. 320 4.1.2. Receiver-site Registration 322 Once the Receiver-ETRs detect the presence of Receivers at the 323 Receiver-site, the Receiver-ETRs will issue Map-Register messages to 324 include the Receiver-ETR RLOCs in the replication-list for the 325 multicast-entry the Receivers joined. 327 The Map-Register message will use the multicast-entry (Source, Group) 328 tuple as its EID record type with the Receiver-ETR RLOCs conforming 329 the locator set. 331 The EID in the Map-Register message must be encoded using the 332 Multicast Information LCAF type defined in [I-D.ietf-lisp-lcaf]. The 333 R, L and J bits in the Multicast-info LCAF frame are not used and 334 should be set to zero. 336 The RLOC in the Map-Register message must be encoded using the 337 Replication List Entry (RLE) LCAF type defined in 338 [I-D.ietf-lisp-lcaf] with the Level Value fields for all entries set 339 to 128 (decimal). 341 The encoding described above must be used consistently for Map- 342 Register messages, entries in the Mapping Database, Map-reply 343 messages as well as the map-cache at the Source-ITRs. 345 The Map-Register messages [RFC6830] sent by the receiver-ETRs should 346 have the following bits set as here specified: 348 1. merge-request-bit set to 1. The Map-Register messages must be 349 sent with "Merge Semantics". The Map-Server will receive 350 registrations from a multitude of Receiver-ETRs. The Map-Server 351 will merge the registrations for common EIDs and maintain a 352 consolidated replication-list for each multicast-entry. 354 2. want-map-notify-bit (M) set to 0. This tells the Mapping System 355 that the receiver-ETR does not expect to receive Map-Notify 356 messages as it does not need to be notified of all changes to the 357 replication-list. 359 3. proxy-reply-bit (P) set to 1. The merged replication-list is 360 kept in the Map-Servers. By setting the proxy-reply bit, the 361 receiver-ETRs instruct the Mapping-system to proxy reply to map- 362 requests issued for the multicast entries. 364 Map-Register messages for a particular multicast-entry should be sent 365 for every receiver detected, even if previous receivers have been 366 detected for the particular multicast-entry. This allows the 367 replication-list to remain up to date. 369 4.1.3. Consolidation of the replication-list 371 The Map-Server will receive registrations from a multitude of 372 Receiver-ETRs. The Map-Server will merge the registrations for 373 common EIDs and consolidate a replication-list for each multicast- 374 entry. 376 4.2. General Source-site Procedures 378 Source-ITRs must register the unicast EIDs of any Sources or 379 Rendezvous Points that may be present on the Source-site. In other 380 words, it is assumed that the Sources and RPs are LISP EIDs. 382 The registration of the unicast EIDs for the Sources or Rendezvous 383 Points allows the map-server to know where to send Map-Notify 384 messages to. Therefore, the Source-ITR must register the unicast 385 S-prefix EID with the want-map-notify-bit set in order to receive 386 Map-Notify messages whenever there is a change in the replication- 387 list. 389 4.2.1. Multicast Tree Building at the Source-site 391 When the source site receives the Map-Notify messages from the 392 mapping system as described in Section 4.3, it will initiate the 393 process of building a multicast distribution tree that will allow the 394 multicast packets from the Source to reach the Source-ITR. 396 The Source-ITR will issue a PIM join for the multicast-entry for 397 which it received the Map-Notify message. The join will be issued in 398 the direction of the source or in the direction of the RP for the SSM 399 and ASM cases respectively. 401 4.2.2. Multicast Destination Resolution 403 On reception of multicast packets, the source-ITR must obtain the 404 replication-list for the (S,G) addresses in the packets. 406 In order to obtain the replication-list, the Source-ITR must issue a 407 Map-Request message in which the EID is the (S,G) multicast tuple 408 which is encoded using the Multicast Info LCAF type defined in 409 [I-D.ietf-lisp-lcaf]. 411 The Mapping System (most likely the Map-Server) will Map-reply with 412 the merged replication-list maintained in the Mapping System. The 413 Map-reply message must follow the format defined in [RFC6830], its 414 EID must be encoded using the Multicast Info LCAF type and the 415 corresponding RLOC-records must be encoded using the RLE LCAF type. 416 Both LCAF types defined in [I-D.ietf-lisp-lcaf]. 418 4.3. General LISP Notification Procedures 420 The Map-Server will issue LISP Map-Notify messages to inform the 421 Source-site of the presence of receivers for a particular multicast 422 group over the overlay. 424 Updated Map-Notify messages should be issued every time a new 425 registration is received from a Receiver-site. This guarantees that 426 the source-sites are aware of any potential changes in the multicast- 427 distribution-list membership. 429 The Map-Notify messages carry (S,G) multicast EIDs encoded using the 430 Multicast Info LCAF type defined in [I-D.ietf-lisp-lcaf]. 432 Map-Notify messages will be sent by the Map-Server to the RLOCs with 433 which the unicast S-prefix EID was registered. 435 When both the Receiver-sites and the Source-sites register to the 436 same Map-Server, the Map-Server has all the necessary information to 437 send the Map-Notify messages to the Source-site. 439 When the Map-Servers are distributed in a DDT, the Receiver-sites may 440 register to one Map-Server while the Source-site registers to a 441 different Map-Server. In this scenario, the Map-Server for the 442 receiver sites must resolve the unicast S-prefix EID in the DDT per 443 standard LISP lookup procedures and obtain the necessary information 444 to send the Map-Notify messages to the Source-site. The Map-Notify 445 messages must be sent with an authentication length of 0 as they 446 would not be authenticated. 448 When the Map-Servers are distributed in a DDT, different Receiver- 449 sites may register to different Map-Servers. This is an unsupported 450 scenario with the currently defined mechanisms. 452 5. Source Specific Multicast Trees 454 The interconnection of Source Specific Multicast (SSM) Trees across 455 sites will follow the General Receiver-site Procedures described in 456 Section 4.1 on the Receiver-sites. 458 The Source-site Procedures will vary depending on the topological 459 location of the Source within the Source-site as described in 460 Section 5.1 and Section 5.2 . 462 5.1. Source directly connected to Source-ITRs 464 When the Source is directly connected to the source-ITR, it is not 465 necessary to trigger signaling to build a local multicast tree at the 466 Source-site. Therefore Map-Notify messages may not be required to 467 initiate building of the multicast tree at the Source-site. 469 Map-Notify messages are still required to ensure that any changes to 470 the replication-list are communicated to the Source-site so that the 471 map-cache at the Source-ITRs is kept updated. 473 5.2. Source not directly connected to Source-ITRs 475 The General LISP Notification Procedures described in Section 4.3 476 must be followed when the Source is not directly connected to the 477 source-ITR. On reception of Map-Notify messages, local multicast 478 signaling must be initiated at the Source-site per the General Source 479 Site Procedures for Multicast Tree building described in 480 Section 4.2.1. 482 In the SSM case, the IP address of the Source is known and it is also 483 registered with the LISP mapping system. Thus, the mapping system 484 may resolve the mapping for the Source address in order to send Map- 485 Notify messages to the correct source-ITR. 487 6. PIM Any Source Multicast Trees 489 LISP signal-free multicast will not support ASM Trees at this time. 490 A future revision of this specification may include procedures for 491 PIM ASM support. 493 PIM ASM in shared-tree only mode could be supported in the scenario 494 where the root of the shared tree (the PIM RP) is placed at the 495 source site. 497 7. Signal-Free Multicast for Replication Engineering 499 The mechanisms in this draft can be applied to the LISP Replication- 500 Engineering [I-D.coras-lisp-re] design. Rather than having the 501 layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can 502 register their availability for multicast tree replication via the 503 mapping database system. As stated in [I-D.coras-lisp-re], the RTR 504 layered hierarchy is used to avoid head-end replication in 505 replicating nodes closest to a multicast source. Rather than have 506 multicast ITRs replicate to each ETR in an RLE entry of a (S,G) 507 mapping database entry, it could replicate to one or more layer-0 508 RTRs in the LISP-RE hierarchy. 510 There are two formats an (S,G) mapping database entry could have. 511 One format is a 'complete-format' and the other is a 'filtered- 512 format'. A 'complete-format' entails an (S,G) entry having multiple 513 RLOC records which contain both ETRs that have registered as well as 514 the RTRs at the first level of the LISP-RE hierarchy for the ITR to 515 replicate to. When using 'complete-format', the ITR has the ability 516 to select if it replicates to RTRs or to the registered ETRs at the 517 receiver sites. A 'filtered-format' (S,G) entry is one where the 518 Map-Server returns the RLOC-records that it decides the ITR should 519 use. So replication policy is shifted from the ITRs to the mapping 520 system. The Map-Servers can also decide for a given ITR, if it uses 521 a different set of replication targets per (S,G) entry for which the 522 ITR is replicating for. 524 The procedure for the LISP-RE RTRs to make themselves available for 525 replication can occur before or after any receivers join an (S,G) 526 entry or any sources send for a particular (S,G) entry. Therefore, 527 newly configured RTR state will be used to create new (S,G) state and 528 inherited into existing (S,G) state. A set of RTRs can register 529 themselves to the mapping system or a third-party can do so on their 530 behalf. When RTR registration occurs, it is done with an (S-prefix, 531 G-prefix) entry so it can advertise its replication services for a 532 wide-range of source/group combinations. 534 When a Map-Server receives (S,G) registrations from ETRs and 535 (S-prefix, G-prefix) registrations from RTRs, it has the option of 536 merging the RTR RLOC-records for each (S,G) that is more-specific for 537 the (S-prefix, G-prefix) entry or keep them separate. When merging, 538 a Map-Server is ready to return a 'complete-format' Map-Reply. When 539 keeping the entries separate, the Map-Server can decide what to 540 include in a Map-Reply when a Map-Request is received. It can 541 include a combination of RLOC-records from each entry or decide to 542 use one or the other depending on policy configured. 544 Here is a specific example of (S,G) and (S-prefix, G-prefix) mapping 545 database entries when a source S is behind an ITR and there are 546 receiver sites joined to (S,G) via ETR1, ETR2, and ETR3. And there 547 exists a LISP-RE hierarchy of RTR1 and RTR2 at level-0 and RTR3 and 548 RTR4 at level-1: 550 EID-record: (S,G) 551 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 552 EID-record: (S-prefix, G-prefix) 553 RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1 555 The above entries are in the form of how they were registered and 556 stored in a Map-Server. When a Map-Server uses 'complete-format', a 557 Map-Reply it originates has the mapping record encoded as: 559 EID-record: (S,G) 560 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 561 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 563 The above Map-Reply allows the ITR to decide if it replicates to the 564 ETRs or if it should replicate only to level-0 RTR1. This decision 565 is left to the ITR since both RLOC-records have priority 1. If the 566 Map-Server wanted to force the ITR to replicate to RTR1, it would set 567 the ETRs RLOC-record to priority greater than 1. 569 When a Map_server uses "filtered-format', a Map-Reply it originates 570 has the mapping record encoded as: 572 EID-record: (S,G) 573 RLOC-record: RLE: (RTR1(L0), RTR3(L1)), p1 575 An (S,G) entry can contain alternate RTRs. So rather than 576 replicating to multiple RTRs, one of a RTR set may be used based on 577 the RTR reachability status. An ITR can test reachability status to 578 any layer-0 RTR using RLOC-probing so it can choose one RTR from a 579 set to replicate to. When this is done the RTRs are encoded in 580 different RLOC-records versus together in one RLE RLOC-record. This 581 moves the replication load off the ITRs at the source site to the 582 RTRs inside the network infrastructure. This mechanism can also be 583 used by level-n RTRs to level-n+1 RTRs. 585 The following mapping would be encoded in a Map-Reply sent by a Map- 586 Server and stored in the ITR. The ITR would use RTR1 until it went 587 unreachable and then switch to use RTR2: 589 EID-record: (S,G) 590 RLOC-record: RTR1, p1 591 RLOC-record: RTR2, p2 593 8. Security Considerations 595 [I-D.ietf-lisp-sec] defines a set of security mechanisms that provide 596 origin authentication, integrity and anti-replay protection to LISP's 597 EID-to-RLOC mapping data conveyed via mapping lookup process. LISP- 598 SEC also enables verification of authorization on EID-prefix claims 599 in Map-Reply messages. 601 Additional security mechanisms to protect the LISP Map-Register 602 messages are defined in [RFC6833]. 604 The security of the Mapping System Infrastructure depends on the 605 particular mapping database used. The [I-D.ietf-lisp-ddt] 606 specification, as an example, defines a public-key based mechanism 607 that provides origin authentication and integrity protection to the 608 LISP DDT protocol. 610 Map-Replies received by the source-ITR can be signed (by the Map- 611 Server) so the ITR knows the replication-list is from a legit source. 613 Data-plane encryption can be used when doing unicast rep- 614 encapsulation as described in [I-D.ietf-lisp-crypto]. For further 615 study we will look how to do multicast rep-encapsulation. 617 9. IANA Considerations 619 This document has no IANA implications 621 10. Acknowledgements 623 The authors want to thank Greg Shepherd, Joel Halpern and Sharon 624 Barkai for their insightful contribution to shaping the ideas in this 625 document. Thanks also goes to Jimmy Kyriannis, Paul Vinciguerra, and 626 Florin Coras for testing an implementation of this draft. 628 11. References 630 11.1. Normative References 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, March 1997. 635 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 636 Protocol (MSDP)", RFC 3618, October 2003. 638 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 639 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 640 Protocol Specification (Revised)", RFC 4601, August 2006. 642 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 643 IP", RFC 4607, August 2006. 645 11.2. Informative References 647 [I-D.coras-lisp-re] 648 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 649 Maino, F., and D. Farinacci, "LISP Replication 650 Engineering", draft-coras-lisp-re-07 (work in progress), 651 April 2015. 653 [I-D.farinacci-lisp-mr-signaling] 654 Farinacci, D. and M. Napierala, "LISP Control-Plane 655 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 656 (work in progress), February 2015. 658 [I-D.ietf-lisp-crypto] 659 Farinacci, D. and B. Weis, "LISP Data-Plane 660 Confidentiality", draft-ietf-lisp-crypto-01 (work in 661 progress), May 2015. 663 [I-D.ietf-lisp-ddt] 664 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 665 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 666 progress), April 2015. 668 [I-D.ietf-lisp-lcaf] 669 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 670 Address Format (LCAF)", draft-ietf-lisp-lcaf-08 (work in 671 progress), April 2015. 673 [I-D.ietf-lisp-sec] 674 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 675 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-08 676 (work in progress), April 2015. 678 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 679 Locator/ID Separation Protocol (LISP)", RFC 6830, January 680 2013. 682 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 683 Locator/ID Separation Protocol (LISP) for Multicast 684 Environments", RFC 6831, January 2013. 686 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 687 Protocol (LISP) Map-Server Interface", RFC 6833, January 688 2013. 690 Appendix A. Document Change Log 692 A.1. Changes to draft-farinacci-lisp-signal-free-multicast-03 694 o Posted June 2015. 696 o Update references and document timer. 698 A.2. Changes to draft-farinacci-lisp-signal-free-multicast-02 700 o Posted December 2014. 702 o Added section about how LISP-RE can use the mechanisms from 703 signal-free-multicast so we can avoid head-end replication and 704 avoid signalling across a layered RE topology. 706 A.3. Changes to draft-farinacci-lisp-signal-free-multicast-01 708 o Posted June 2014. 710 o Changes based on implementation experience of this draft. 712 A.4. Changes to draft-farinacci-lisp-signal-free-multicast-00 714 o Posted initial draft February 2014. 716 Authors' Addresses 718 Victor Moreno 719 Cisco Systems 720 170 Tasman Drive 721 San Jose, California 95134 722 USA 724 Email: vimoreno@cisco.com 726 Dino Farinacci 727 lispers.net 728 San Jose, CA 95120 729 USA 731 Email: farinacci@gmail.com