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