idnits 2.17.1 draft-ietf-lisp-multicast-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2012) is 4433 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-02 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-16 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-09 == Outdated reference: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft D. Meyer 4 Intended status: Experimental J. Zwiebel 5 Expires: August 11, 2012 S. Venaas 6 cisco Systems 7 February 8, 2012 9 LISP for Multicast Environments 10 draft-ietf-lisp-multicast-14 12 Abstract 14 This draft describes how inter-domain multicast routing will function 15 in an environment where Locator/ID Separation is deployed using the 16 LISP architecture. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 11, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 55 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 56 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 57 6. Locator Reachability Implications on LISP-Multicast . . . . . 14 58 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 59 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 18 60 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 61 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 18 62 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 19 63 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 19 64 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 20 65 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 21 66 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 21 67 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 22 68 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 23 69 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 24 70 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 25 71 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 25 72 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 26 73 9.3. Making a Multicast Interworking Decision . . . . . . . . . 28 74 10. Considerations when RP Addresses are Embedded in Group 75 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 30 77 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 31 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 79 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 80 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 81 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 83 16.2. Informative References . . . . . . . . . . . . . . . . . . 36 84 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 37 85 A.1. Changes to draft-ietf-lisp-multicast-14.txt . . . . . . . 37 86 A.2. Changes to draft-ietf-lisp-multicast-13.txt . . . . . . . 37 87 A.3. Changes to draft-ietf-lisp-multicast-12.txt . . . . . . . 37 88 A.4. Changes to draft-ietf-lisp-multicast-11.txt . . . . . . . 37 89 A.5. Changes to draft-ietf-lisp-multicast-10.txt . . . . . . . 37 90 A.6. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 37 91 A.7. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 37 92 A.8. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 38 93 A.9. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 38 94 A.10. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 38 95 A.11. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 38 96 A.12. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 38 97 A.13. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 39 98 A.14. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 39 99 A.15. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 39 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 102 1. Requirements Notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Introduction 110 The Locator/ID Separation Architecture [LISP] provides a mechanism to 111 separate out Identification and Location semantics from the current 112 definition of an IP address. By creating two namespaces, an Endpoint 113 ID (EID) namespace used by sites and a Routing Locator (RLOC) 114 namespace used by core routing, the core routing infrastructure can 115 scale by doing topological aggregation of routing information. 117 Since LISP creates a new namespace, a mapping function must exist to 118 map a site's EID prefixes to its associated locators. For unicast 119 packets, both the source address and destination address must be 120 mapped. For multicast packets, only the source address needs to be 121 mapped. The destination group address doesn't need to be mapped 122 because the semantics of an IPv4 or IPv6 group address are logical in 123 nature and not topology-dependent. Therefore, this specification 124 focuses on to map a source EID address of a multicast flow during 125 distribution tree setup and packet delivery. 127 This specification will address the following scenarios: 129 1. How a multicast source host in a LISP site sends multicast 130 packets to receivers inside of its site as well as to receivers 131 in other sites that are LISP enabled. 133 2. How inter-domain (or between LISP sites) multicast distribution 134 trees are built and how forwarding of multicast packets leaving a 135 source site toward receivers sites is performed. 137 3. What protocols are affected and what changes are required to such 138 multicast protocols. 140 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source 141 Multicast), and Bidir-mode (Bidirectional Shared Trees) service 142 models will operate. 144 5. How multicast packet flow will occur for multiple combinations of 145 LISP and non-LISP capable source and receiver sites, for example: 147 A. How multicast packets from a source host in a LISP site are 148 sent to receivers in other sites when they are all non-LISP 149 sites. 151 B. How multicast packets from a source host in a LISP site are 152 sent to receivers in both LISP-enabled sites and non-LISP 153 sites. 155 C. How multicast packets from a source host in a non-LISP site 156 are sent to receivers in other sites when they are all LISP- 157 enabled sites. 159 D. How multicast packets from a source host in a non-LISP site 160 are sent to receivers in both LISP-enabled sites and non-LISP 161 sites. 163 This specification focuses on what changes are needed to the 164 multicast routing protocols to support LISP-Multicast as well as 165 other protocols used for inter-domain multicast, such as Multi- 166 protocol BGP (MBGP) [RFC4760]. The approach proposed in this 167 specification requires no packet format changes to the protocols and 168 no operational procedural changes to the multicast infrastructure 169 inside of a site when all sources and receivers reside in that site, 170 even when the site is LISP enabled. That is, internal operation of 171 multicast is unchanged regardless of whether or not the site is LISP 172 enabled or whether or not receivers exist in other sites which are 173 LISP-enabled. 175 Therefore, we see only operational (and not protocol) changes for 176 PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM 177 [RFC5015], which typically does not run in an inter-domain 178 environment is not addressed in depth in this version of the 179 specification. 181 Also, the current version of this specification does not describe 182 multicast-based Traffic Engineering relative to the TE-ITR (Traffic 183 Engineering based Ingress Tunnel Router) and TE-ETR (Traffic 184 Engineering based Egress Tunnel Router) descriptions in [LISP]. 185 Futher work is also needed to determine the detailed behavior for 186 multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), 187 and locator reachability (Section 6). Finally, further deployment 188 and experimentation would be useful to understand the real-life 189 performance of the LISP-Multicast solution. For instance, the design 190 optimizes for minimal state and control traffic in the core, but can 191 in some cases cause extra multicast traffic to be sent Section 8.1.2. 193 Issues and concerns about the deployment of LISP for Internet traffic 194 are discussed in [LISP]. Section 12 provides additional issues and 195 concerns raised by this document. 197 3. Definition of Terms 199 The terminology in this section is consistent with the definitions in 200 [LISP] but is extended specifically to deal with the application of 201 the terminology to multicast routing. 203 LISP-Multicast: a reference to the design in this specification. 204 That is, when any site that is participating in multicast 205 communication has been upgraded to be a LISP site, the operation 206 of control-plane and data-plane protocols is considered part of 207 the LISP-Multicast architecture. 209 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 210 used in the source address field of the first (most inner) LISP 211 header of a multicast packet. The host obtains a destination 212 group address the same way it obtains one today, as it would when 213 it is a non-LISP site. The source EID is obtained via existing 214 mechanisms used to set a host's "local" IP address. An EID is 215 allocated to a host from an EID prefix block associated with the 216 site the host is located in. An EID can be used by a host to 217 refer to another host, as when it joins an SSM (S-EID,G) route 218 using IGMP version 3 [RFC4604]. LISP uses Provider Independent 219 (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 220 Note that EID blocks may be assigned in a hierarchical manner, 221 independent of the network topology, to facilitate scaling of the 222 mapping database. In addition, an EID block assigned to a site 223 may have site-local structure (subnetting) for routing within the 224 site; this structure is not visible to the global routing system. 226 Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress 227 tunnel router (ITR), the router in the multicast source host's 228 site that encapsulates multicast packets. It is the output of a 229 EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. 230 Typically, RLOCs are numbered from topologically-aggregatable 231 blocks that are assigned to a site at each point to which it 232 attaches to the global Internet; where the topology is defined by 233 the connectivity of provider networks, RLOCs can be thought of as 234 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned 235 to the same ITR device or to multiple ITR devices at a site. 237 Ingress Tunnel Router (ITR): a router which accepts an IP multicast 238 packet with a single IP header (more precisely, an IP packet that 239 does not contain a LISP header). The router treats this "inner" 240 IP destination multicast address opaquely so it doesn't need to 241 perform a map lookup on the group address because it is 242 topologically insignificant. The router then prepends an "outer" 243 IP header with one of its globally-routable RLOCs as the source 244 address field. This RLOC is known to other multicast receiver 245 sites which have used the mapping database to join a multicast 246 tree for which the ITR is the root. In general, an ITR receives 247 IP packets from site end systems on one side and sends LISP- 248 encapsulated multicast IP packets out all external interfaces 249 which have been joined. 251 An ITR would receive a multicast packet from a source inside of 252 its site when 1) it is on the path from the multicast source to 253 internally joined receivers, or 2) when it is on the path from the 254 multicast source to externally joined receivers. 256 Egress Tunnel Router (ETR): a router that is on the path from a 257 multicast source host in another site to a multicast receiver in 258 its own site. An ETR accepts a PIM Join/Prune message from a site 259 internal PIM router destined for the source's EID in the multicast 260 source site. The ETR maps the source EID in the Join/Prune 261 message to an RLOC address based on the EID-to-RLOC mapping. This 262 sets up the ETR to accept multicast encapsulated packets from the 263 ITR in the source multicast site. A multicast ETR decapsulates 264 multicast encapsulated packets and replicates them on interfaces 265 leading to internal receivers. 267 xTR: is a reference to an ITR or ETR when direction of data flow is 268 not part of the context description. xTR refers to the router that 269 is the tunnel endpoint. Used synonymously with the term "Tunnel 270 Router". For example, "An xTR can be located at the Customer Edge 271 (CE) router", meaning both ITR and ETR functionality can be at the 272 CE router. 274 LISP Header: a term used in this document to refer to the outer 275 IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR 276 prepends headers and an ETR strips headers. A LISP encapsulated 277 multicast packet will have an "inner" header with the source EID 278 in the source field; an "outer" header with the source RLOC in the 279 source field: and the same globally unique group address in the 280 destination field of both the inner and outer header. 282 (S,G) State: the formal definition is in the PIM Sparse Mode 283 [RFC4601] specification. For this specification, the term is used 284 generally to refer to multicast state. Based on its topological 285 location, the (S,G) state resides in routers can be either 286 (S-EID,G) state (at a location where the (S,G) state resides) or 287 (S-RLOC,G) state (in the Internet core). 289 (S-EID,G) State: refers to multicast state in multicast source and 290 receiver sites where S-EID is the IP address of the multicast 291 source host (its EID). An S-EID can appear in an IGMPv3 report, 292 an MSDP SA message or a PIM Join/Prune message that travels inside 293 of a site. 295 (S-RLOC,G) State: refers to multicast state in the core where S is 296 a source locator (the IP address of a multicast ITR) of a site 297 with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) 298 entry by doing a mapping database lookup for the EID prefix that 299 S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message 300 when it travels from an ETR to an ITR over the Internet core. 302 uLISP Site: a unicast only LISP site according to [LISP] which has 303 not deployed the procedures of this specification and therefore, 304 for multicast purposes, follows the procedures from Section 9. A 305 uLISP site can be a traditional multicast site. 307 LISP Site: a unicast LISP site (uLISP Site) that is also multicast 308 capable according to the procedures in this specification. 310 mPETR: this is a multicast proxy-ETR that is responsible for 311 advertising a very coarse EID prefix which non-LISP and uLISP 312 sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs 313 are used so LISP source multicast sites can send multicast packets 314 using source addresses from the EID namespace. mPETRs act as Proxy 315 ETRs for supporting multicast routing in a LISP infrastructure. 316 It is likely an uPITR [INTWORK] and a mPETR will be co-located 317 since the single device advertises a coarse EID-prefix in the 318 underlying unicast routing system. 320 Mixed Locator-Sets: this is a locator-set for a LISP database 321 mapping entry where the RLOC addresses in the locator-set are in 322 both IPv4 and IPv6 format. 324 Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM 325 Join/Prune message (LISP encapsulated with destination UDP port 326 4341) which is sent by ETRs at multicast receiver sites to an ITR 327 at a multicast source site. This message is sent periodically as 328 long as there are interfaces in the OIF-list for the (S-EID,G) 329 entry the ETR is joining for. 331 OIF-list: this is notation to describe the outgoing interface list 332 a multicast router stores per multicast routing table entry so it 333 knows what interfaces to replicate multicast packets on. 335 RPF: Reverse Path Forwarding is a procedure used by multicast 336 routers. A router will accept a multicast packet for forwarding 337 if the packet was received on the path that the router would use 338 to forward unicast packets to the multicast packet's source. 340 4. Basic Overview 342 LISP, when used for unicast routing, increases the site's ability to 343 control ingress traffic flows. Egress traffic flows are controlled 344 by the IGP in the source site. For multicast, the IGP coupled with 345 PIM can decide which path multicast packets ingress. By using the 346 traffic engineering features of LISP [LISP], a multicast source site 347 can control the egress of its multicast traffic. By controlling the 348 priorities of locators from a mapping database entry, a source 349 multicast site can control which way multicast receiver sites join to 350 the source site. 352 At this point in time, there is no requirement for different locator- 353 sets, priority, and weight policies for multicast than there is for 354 unicast. However, when traffic engineering policies are different 355 for unicast versus multicast flows, it will be desirable to use 356 multicast-based priority and weight values in Map-Reply messages. 358 The fundamental multicast forwarding model is to encapsulate a 359 multicast packet into another multicast packet. An ITR will 360 encapsulate multicast packets received from sources that it serves in 361 a LISP multicast header. The destination group address from the 362 inner header is copied to the destination address of the outer 363 header. The inner source address is the EID of the multicast source 364 host and the outer source address is the RLOC of the encapsulating 365 ITR. 367 The LISP-Multicast architecture will follow this high-level protocol 368 and operational sequence: 370 1. Receiver hosts in multicast sites will join multicast content the 371 way they do today, they use IGMP. When they use IGMPv3 where 372 they specify source addresses, they use source EIDs, that is they 373 join (S-EID,G). If the multicast source is external to this 374 receiver site, the PIM Join/Prune message flows toward the ETRs, 375 finding the shortest exit (that is the closest exit for the Join/ 376 Prune message and the closest entrance for the multicast packet 377 to the receiver). 379 2. The ETR does a mapping database lookup for S-EID. If the mapping 380 is cached from a previous lookup (from either a previous Join/ 381 Prune for the source multicast site or a unicast packet that went 382 to the site), it will use the RLOC information from the mapping. 383 The ETR will use the same priority and weighting mechanism as for 384 unicast. So the source site can decide which way multicast 385 packets egress. 387 3. The ETR will build two PIM Join/Prune messages, one that contains 388 a (S-EID,G) entry that is unicast to the ITR that matches the 389 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 390 entry so the core network can create multicast state from this 391 ETR to the ITR. 393 4. When the ITR gets the unicast Join/Prune message (see Section 3 394 for formal definition), it will process (S-EID,G) entries in the 395 message and propagate them inside of the site where it has 396 explicit routing information for EIDs via the IGP. When the ITR 397 receives the (S-RLOC,G) PIM Join/Prune message it will process it 398 like any other join it would get in today's Internet. The S-RLOC 399 address is the IP address of this ITR. 401 5. At this point there is (S-EID,G) state from the joining host in 402 the receiver multicast site to the ETR of the receiver multicast 403 site. There is (S-RLOC,G) state across the core network from the 404 ETR of the multicast receiver site to the ITR in the multicast 405 source site and (S-EID,G) state in the source multicast site. 406 Note, the (S-EID,G) state is the same S-EID in each multicast 407 site. As other ETRs join the same multicast tree, they can join 408 through the same ITR (in which case the packet replication is 409 done in the core) or a different ITR (in which case the packet 410 replication is done at the source site). 412 6. When a packet is originated by the multicast host in the source 413 site, the packet will flow to one or more ITRs which will prepend 414 a LISP header. By copying the group address to the outer 415 destination address field, the ITR insert its own locator address 416 in the outer source address field. The ITR will look at its 417 (S-RLOC,G) state, where S-RLOC is its own locator address, and 418 replicate the packet on each interface a (S-RLOC,G) joined was 419 received on. The core has (S-RLOC,G) so where fanout occurs to 420 multiple sites, a core router will do packet replication. 422 7. When either the source site or the core replicates the packet, 423 the ETR will receive a LISP packet with a destination group 424 address. It will decapsulate packets because it has receivers 425 for the group. Otherwise, it would have not received the packets 426 because it would not have joined. The ETR decapsulates and does 427 a (S-EID,G) lookup in its multicast FIB to forward packets out 428 one or more interfaces to forward the packet to internal 429 receivers. 431 This architecture is consistent and scalable with the architecture 432 presented in [LISP] where multicast state in the core operates on 433 locators and multicast state at the sites operates on EIDs. 435 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can 436 reside in the core through the use of RPF-vectors [RFC5496] in PIM 437 Join/Prune messages. However, few PIM implementations support RPF 438 vectors and LISP should avoid S-EID state in the core. See Section 5 439 for details. 441 However, some observations can be made on the algorithm above. The 442 control plane can scale but at the expense of sending data to sites 443 which may have not joined the distribution tree where the 444 encapsulated data is being delivered. For example, one site joins 445 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 446 same multicast source site. Both multicast receiver sites join to 447 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 448 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 449 site. The ITR receives (S-RLOC,G) joins and populates the OIF-list 450 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 451 (S-RLOC,G) packets will be delivered by the core to both multicast 452 receiver sites even though each have joined a single source-based 453 distribution tree. This behavior is a consequence of the many-to-one 454 mapping between S-EIDs and a S-RLOC. 456 There is a possible solution to this problem which reduces the number 457 of many-to-one occurrences of (S-EID,G) entries aggregating into a 458 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 459 RLOC addresses and these addresses are advertised in mapping database 460 entries, then ETRs at receiver sites have more RLOC address options 461 and therefore can join different (RLOC,G) entries for each (S-EID,G) 462 entry joined at the receiver site. It would not scale to have a one- 463 to-one relationship between the number of S-EID sources at a source 464 site and the number of RLOCs assigned to all ITRs at the site, but 465 "n" can reduce to a smaller number in the "n-to-1" relationship. And 466 in turn, reduce the opportunity for data packets to be delivered to 467 sites for groups not joined. 469 5. Source Addresses versus Group Addresses 471 Multicast group addresses don't have to be associated with either the 472 EID or RLOC namespace. They actually are a namespace of their own 473 that can be treated as logical with relatively opaque allocation. 474 So, by their nature, they don't detract from an incremental 475 deployment of LISP-Multicast. 477 As for source addresses, as in the unicast LISP scenario, there is a 478 decoupling of identification from location. In a LISP site, packets 479 are originated from hosts using their allocated EIDs. EID addresses 480 are used to identify the host as well as where in the site's topology 481 the host resides but not how and where it is attached to the 482 Internet. 484 Therefore, when multicast distribution tree state is created anywhere 485 in the network on the path from any multicast receiver to a multicast 486 source, EID state is maintained at the source and receiver multicast 487 sites, and RLOC state is maintained in the core. That is, a 488 multicast distribution tree will be represented as a 3-tuple of 489 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 490 3-tuple is the state stored in routers from the source to one or more 491 ITRs in the source multicast site, the second element of the 3-tuple 492 is the state stored in routers downstream of the ITR, in the core, to 493 all LISP receiver multicast sites, and the third element in the 494 3-tuple is the state stored in the routers downstream of each ETR, in 495 each receiver multicast site, reaching each receiver. Note that 496 (S-EID,G) is the same in both the source and receiver multicast 497 sites. 499 The concatenation/mapping from the first element to the second 500 element of the 3-tuples is done by the ITR and from the second 501 element to the third element is done at the ETRs. 503 6. Locator Reachability Implications on LISP-Multicast 505 Multicast state as it is stored in the core is always (S,G) state as 506 it exists today or (S-RLOC,G) state as it will exist when LISP sites 507 are deployed. The core routers cannot distinguish one from the 508 other. They don't need to because it is state that RPFs against the 509 core routing tables in the RLOC namespace. The difference is where 510 the root of the distribution tree for a particular source is. In the 511 traditional multicast core, the source S is the source host's IP 512 address. For LISP-Multicast the source S is a single ITR of the 513 multicast source site. 515 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 516 ETR propagates a PIM Join/Prune message out of a receiver multicast 517 site. The selection is based on the same algorithm an ITR would use 518 to select an ETR when sending a unicast packet to the site. In the 519 unicast case, the ITR can change on a per-packet basis depending on 520 the reachability of the ETR. So an ITR can change relatively easily 521 using local reachability state. However, in the multicast case, when 522 an ITR goes unreachable, new distribution tree state must be built 523 because the encapsulating root has changed. This is more significant 524 than an RPF-change event, where any router would typically locally 525 change its RPF-interface for its existing tree state. But when an 526 encapsulating LISP-Multicast ITR goes unreachable, new distribution 527 state must be rebuilt and reflect the new encapsulator. Therefore, 528 when an ITR goes unreachable, all ETRs that are currently joined to 529 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 530 to the new ITR as well as send a unicast encapsulated Join/Prune 531 message telling the new ITR which (S-EID,G) is being joined. 533 This issue can be mitigated by using anycast addressing for the ITRs 534 so the problem does reduce to an RPF change in the core, but still 535 requires a unicast encapsulated Join/Prune message to tell the new 536 ITR about (S-EID,G). The problem with this approach is that the ETR 537 really doesn't know when the ITR has changed so the new anycast ITR 538 will get the (S-EID,G) state only when the ETR sends it the next time 539 during its periodic sending procedures. 541 7. Multicast Protocol Changes 543 A number of protocols are used today for inter-domain multicast 544 routing: 546 IGMPv1-v3, MLDv1-v2: These protocols [RFC4604] do not require any 547 changes for LISP-Multicast for two reasons. One being that they 548 are link-local and not used over site boundaries and second, they 549 advertise group addresses that don't need translation. Where 550 source addresses are supplied in IGMPv3 and MLDv2 messages, they 551 are semantically regarded as EIDs and don't need to be converted 552 to RLOCs until the multicast tree-building protocol, such as PIM, 553 is received by the ETR at the site boundary. Addresses used for 554 IGMP and MLD come out of the source site's allocated addresses 555 which are therefore from the EID namespace. 557 MBGP: Even though MBGP [RFC4760] is not a multicast routing 558 protocol, it is used to find multicast sources when the unicast 559 BGP peering topology and the multicast MBGP peering topology are 560 not congruent. When MBGP is used in a LISP-Multicast environment, 561 the prefixes which are advertised are from the RLOC namespace. 562 This allows receiver multicast sites to find a path to the source 563 multicast site's ITRs. MBGP peering addresses will be from the 564 RLOC namespace. There are no MBGP protocol changes required to 565 support LISP-Multicast. 567 MSDP: MSDP [RFC3618] is used to announce active multicast sources 568 to other routing domains (or LISP sites). The announcements come 569 from the PIM Rendezvous Points (RPs) from sites where there are 570 active multicast sources sending to various groups. In the 571 context of LISP-Multicast, the source addresses advertised in MSDP 572 will semantically be from the EID namespace since they describe 573 the identity of a source multicast host. It will be true that the 574 state stored in MSDP caches from core routers will be from the EID 575 namespace. An RP address inside of site will be from the EID 576 namespace so it can be advertised and reached by internal unicast 577 routing mechanism. However, for MSDP peer-RPF checking to work 578 properly across sites, the RP addresses must be converted or 579 mapped into a routable address that is advertised and maintained 580 in the BGP routing tables in the core. MSDP peering addresses can 581 come out of either the EID or a routable address namespace. And 582 the choice can be made unilaterally because the ITR at the site 583 will determine which namespace the destination peer address is out 584 of by looking in the mapping database service. There are no MSDP 585 protocol changes required to support LISP-Multicast. 587 PIM-SSM: In the simplest form of distribution tree building, when 588 PIM operates in SSM mode [RFC4607], a source distribution tree is 589 built and maintained across site boundaries. In this case, there 590 is a small modification to how PIM Join/Prune messages are sent by 591 the LISP-Multicast component. No modifications to any message 592 format, but to support taking a Join/Prune message originated 593 inside of a LISP site with embedded addresses from the EID 594 namespace and converting them to addresses from the RLOC namespace 595 when the Join/Prune message crosses a site boundary. This is 596 similar to the requirements documented in [RFC5135]. 598 PIM-Bidir: Bidirectional PIM [RFC5015] is typically run inside of a 599 routing domain, but if deployed in an inter-domain environment, 600 one would have to decide if the RP address of the shared-tree 601 would be from the EID namespace or the RLOC namespace. If the RP 602 resides in a site-based router, then the RP address is from the 603 EID namespace. If the RP resides in the core where RLOC addresses 604 are routed, then the RP address is from the RLOC namespace. This 605 could be easily distinguishable if the EID address were well-known 606 address allocation block from the RLOC namespace. Also, when 607 using Embedded-RP for RP determination [RFC3956], the format of 608 the group address could indicate the namespace the RP address is 609 from. However, refer to Section 10 for considerations core 610 routers need to make when using Embedded-RP IPv6 group addresses. 611 When using Bidir-PIM for inter-domain multicast routing, it is 612 recommended to use staticly configured RPs. Allowing core routers 613 to associate a Bidir group's RP address with an ITR's RLOC 614 address. And site routers to associate the Bidir group's RP 615 address as an EID address. With respect to DF-election in Bidir 616 PIM, no changes are required since all messaging and addressing is 617 link-local. 619 PIM-ASM: The ASM mode of PIM [RFC4601], the most popular form of 620 PIM, is deployed in the Internet today is by having shared-trees 621 within a site and using source-trees across sites. By the use of 622 MSDP and PIM-SSM techniques described above, multicast 623 connectivity can occur across LISP sites. Having said that, that 624 means there are no special actions required for processing (*,G) 625 or (S,G,R) Join/Prune messages since they all operate against the 626 shared-tree which is site resident. Just like with ASM, there is 627 no (*,G) in the core when LISP-Multicast is in use. This is also 628 true for the RP-mapping mechanisms Auto-RP and BSR. 630 Based on the protocol description above, the conclusion is that there 631 are no protocol message format changes, just a translation function 632 performed at the control-plane. This will make for an easier and 633 faster transition for LISP since fewer components in the network have 634 to change. 636 It should also be stated just like it is in [LISP] that no host 637 changes, whatsoever, are required to have a multicast source host 638 send multicast packets and for a multicast receiver host to receive 639 multicast packets. 641 8. LISP-Multicast Data-Plane Architecture 643 The LISP-Multicast data-plane operation conforms to the operation and 644 packet formats specified in [LISP]. However, encapsulating a 645 multicast packet from an ITR is a much simpler process. The process 646 is simply to copy the inner group address to the outer destination 647 address. And to have the ITR use its own IP address (its RLOC) as 648 the source address. The process is simpler for multicast because 649 there is no EID-to-RLOC mapping lookup performed during packet 650 forwarding. 652 In the decapsulation case, the ETR simply removes the outer header 653 and performs a multicast routing table lookup on the inner header 654 (S-EID,G) addresses. Then the OIF-list for the (S-EID,G) entry is 655 used to replicate the packet on site-facing interfaces leading to 656 multicast receiver hosts. 658 There is no Data-Probe logic for ETRs as there can be in the unicast 659 forwarding case. 661 8.1. ITR Forwarding Procedure 663 The following procedure is used by an ITR, when it receives a 664 multicast packet from a source inside of its site: 666 1. A multicast data packet sent by a host in a LISP site will have 667 the source address equal to the host's EID and the destination 668 address equal to the group address of the multicast group. It is 669 assumed the group information is obtained by current methods. 670 The same is true for a multicast receiver to obtain the source 671 and group address of a multicast flow. 673 2. When the ITR receives a multicast packet, it will have both S-EID 674 state and S-RLOC state stored. Since the packet was received on 675 a site-facing interface, the RPF lookup is based on the S-EID 676 state. If the RPF check succeeds, then the OIF-list contains 677 interfaces that are site-facing and external-facing. For the 678 site-facing interfaces, no LISP header is prepended. For the 679 external-facing interfaces a LISP header is prepended. When the 680 ITR prepends a LISP header, it uses its own RLOC address as the 681 source address and copies the group address supplied by the IP 682 header the host built as the outer destination address. 684 8.1.1. Multiple RLOCs for an ITR 686 Typically, an ITR will have a single RLOC address but in some cases 687 there could be multiple RLOC addresses assigned from either the same 688 or different service providers. In this case when (S-RLOC,G) Join/ 689 Prune messages are received for each RLOC, there is a OIF-list 690 merging action that must take place. Therefore, when a packet is 691 received from a site-facing interface that matches on a (S-EID,G) 692 entry, the interfaces of the OIF-list from all (RLOC,G) entries 693 joined to the ITR as well as the site-facing OIF-list joined for 694 (S-EID,G) must be part be included in packet replication. In 695 addition to replicating for all types of OIF-lists, each oif entry 696 must be tagged with the RLOC address, so encapsulation uses the outer 697 source address for the RLOC joined. 699 8.1.2. Multiple ITRs for a LISP Source Site 701 Note when ETRs from different multicast receiver sites receive 702 (S-EID,G) joins, they may select a different S-RLOC for a multicast 703 source site due to policy (the multicast ITR can return different 704 multicast priority and weight values per ETR Map-Request). In this 705 case, the same (S-EID,G) is being realized by different (S-RLOC,G) 706 state in the core. This will not result in duplicate packets because 707 each ITR in the multicast source site will choose their own RLOC for 708 the source address for encapsulated multicast traffic. The RLOC 709 addresses are the ones joined by remote multicast ETRs. 711 When different (S-EID,G) traffic is combined into a single (RLOC,G) 712 core distribution tree, this may cause traffic to go to a receiver 713 multicast site when it does not need to. This happens when one 714 receiver multicast site joins (S1-EID,Gi) through a core distribution 715 tree of (RLOC1,Gi) and another multicast receiver site joins (S2- 716 EID,Gi) through the same core distribution tree of (RLOC1,Gi). When 717 ETRs decapsulate such traffic, they should know from their local 718 (S-EID,G) state if the packet should be forwarded. If there is no 719 (S-EID,G) state that matches the inner packet header, the packet is 720 discarded. 722 8.2. ETR Forwarding Procedure 724 The following procedure is used by an ETR, when it receives a 725 multicast packet from a source outside of its site: 727 1. When a multicast data packet is received by an ETR on an 728 external-facing interface, it will do an RPF lookup on the S-RLOC 729 state it has stored. If the RPF check succeeds, the interfaces 730 from the OIF-list are used for replication to interfaces that are 731 site-facing as well as interfaces that are external-facing (this 732 ETR can also be a transit multicast router for receivers outside 733 of its site). When the packet is to be replicated for an 734 external-facing interface, the LISP encapsulation header are not 735 stripped. When the packet is replicated for a site-facing 736 interface, the encapsulation header is stripped. 738 2. The packet without a LISP header is now forwarded down the 739 (S-EID,G) distribution tree in the receiver multicast site. 741 8.3. Replication Locations 743 Multicast packet replication can happen in the following topological 744 locations: 746 o In an IGP multicast router inside a site which operates on S-EIDs. 748 o In a transit multicast router inside of the core which operates on 749 S-RLOCs. 751 o At one or more ETR routers depending on the path a Join/Prune 752 message exits a receiver multicast site. 754 o At one or more ITR routers in a source multicast site depending on 755 what priorities are returned in a Map-Reply to receiver multicast 756 sites. 758 In the last case the source multicast site can do replication rather 759 than having a single exit from the site. But this only can occur 760 when the priorities in the Map-Reply are modified for different 761 receiver multicast site so that the PIM Join/Prune messages arrive at 762 different ITRs. 764 This policy technique, also used in [ALT] for unicast, is useful for 765 multicast to mitigate the problems of changing distribution tree 766 state as discussed in Section 6. 768 9. LISP-Multicast Interworking 770 This section will describe the multicast corollary to [INTWORK] which 771 describes the interworking of multicast routing among LISP and non- 772 LISP sites. 774 9.1. LISP and non-LISP Mixed Sites 776 Since multicast communication can involve more than two entities to 777 communicate together, the combinations of interworking scenarios are 778 more involved. However, the state maintained for distribution trees 779 at the sites is the same regardless of whether or not the site is 780 LISP enabled or not. So most of the implications are in the core 781 with respect to storing routable EID prefixes from either PA or PI 782 blocks. 784 Before enumerating the multicast interworking scenarios, let's define 785 3 deployment states of a site: 787 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 788 does today. The addresses for the site are globally routable. 790 o A site that deploys LISP for unicast routing. The addresses for 791 the site are not globally routable. Let's define the name for 792 this type of site as a uLISP site. 794 o A site that deploys LISP for both unicast and multicast routing. 795 The addresses for the site are not globally routable. Let's 796 define the name for this type of site as a LISP-Multicast site. 798 What will not be considered is a LISP site enabled for multicast 799 purposes only but do consider a uLISP site as documented in 800 [INTWORK]. In this section there is no discussion how a LISP site 801 sends multicast packets when all receiver sites are LISP-Multicast 802 enabled; that has been discussed in previous sections. 804 The following scenarios exist to make LISP-Multicast sites interwork 805 with non-LISP-Multicast sites: 807 1. A LISP site must be able to send multicast packets to receiver 808 sites which are a mix of non-LISP sites and uLISP sites. 810 2. A non-LISP site must be able to send multicast packets to 811 receiver sites which are a mix of non-LISP sites and uLISP sites. 813 3. A non-LISP site must be able to send multicast packets to 814 receiver sites which are a mix of LISP sites, uLISP sites, and 815 non-LISP sites. 817 4. A uLISP site must be able to send multicast packets to receiver 818 sites which are a mix of LISP sites, uLISP sites, and non-LISP 819 sites. 821 5. A LISP site must be able to send multicast packets to receiver 822 sites which are a mix of LISP sites, uLISP sites, and non-LISP 823 sites. 825 9.1.1. LISP Source Site to non-LISP Receiver Sites 827 In the first scenario, a site is LISP capable for both unicast and 828 multicast traffic and as such operates on EIDs. Therefore there is a 829 possibility that the EID prefix block is not routable in the core. 830 For LISP receiver multicast sites this isn't a problem but for non- 831 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 832 is received by the edge router, it has no route to propagate the 833 Join/Prune message out of the site. This is no different than the 834 unicast case that LISP-NAT in [INTWORK] solves. 836 LISP-NAT allows a unicast packet that exits a LISP site to get its 837 source address mapped to a globally routable address before the ITR 838 realizes that it should not encapsulate the packet destined to a non- 839 LISP site. For a multicast packet to leave a LISP site, distribution 840 tree state needs to be built so the ITR can know where to send the 841 packet. So the receiver multicast sites need to know about the 842 multicast source host by its routable address and not its EID 843 address. When this is the case, the routable address is the 844 (S-RLOC,G) state that is stored and maintained in the core routers. 845 It is important to note that the routable address for the host cannot 846 be the same as an RLOC for the site because it is desirable for ITRs 847 to process a received PIM Join/Prune message from an external-facing 848 interface to be propagated inside of the site so the site-part of the 849 distribution tree is built. 851 Using a globally routable source address allows non-LISP and uLISP 852 multicast receiver to join, create, and maintain a multicast 853 distribution tree. However, the LISP multicast receiver site will 854 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 855 Prune message is received on a site-facing interface. It does this 856 because it wants to find a (S-RLOC,G) entry to Join in the core. So 857 there is a conflict of behavior between the two types of sites. 859 The solution to this problem is the same as when an ITR wants to send 860 a unicast packet to a destination site but needs determine if the 861 site is LISP capable or not. When it is not LISP capable, the ITR 862 does not encapsulate the packet. So for the multicast case, when ETR 863 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 864 mapping table lookup on S-EID. In this case, S-EID is not in the 865 mapping database because the source multicast site is using a 866 routable address and not an EID prefix address. So the ETR knows to 867 simply propagate the PIM Join/Prune message to a external-facing 868 interface without converting the (S-EID,G) because it is an (S,G) 869 where S is routable and reachable via core routing tables. 871 Now that the multicast distribution tree is built and maintained from 872 any non-LISP or uLISP receiver multicast site, the way packet 873 forwarding model is performed can be explained. 875 Since the ITR in the source multicast site has never received a 876 unicast encapsulated PIM Join/Prune message from any ETR in a 877 receiver multicast site, it knows there are no LISP-Multicast 878 receiver sites. Therefore, there is no need for the ITR to 879 encapsulate data. Since it will know a priori (via configuration) 880 that its site's EIDs are not routable (and not registered to the 881 mapping database system), it assumes that the multicast packets from 882 the source host are sent by a routable address. That is, it is the 883 responsibility of the multicast source host's system administrator to 884 ensure that the source host sends multicast traffic using a routable 885 source address. When this happens, the ITR acts simply as a router 886 and forwards the multicast packet like an ordinary multicast router. 888 There is an alternative to using a LISP-NAT scheme just like there is 889 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 890 (PxTRs). This can work the same way for multicast routing as well, 891 but the difference is that non-LISP and uLISP sites will send PIM 892 Join/Prune messages for (S-EID,G) which make their way in the core to 893 multicast PxTRs. Let's call this use of a PxTR as a "Multicast 894 Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID 895 prefixes, they draw the PIM Join/Prune control traffic making them 896 the target of the distribution tree. To get multicast packets from 897 the LISP source multicast sites, the tree needs to be built on the 898 path from the mPETR to the LISP source multicast site. To make this 899 happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a 900 "Proxy ITR", or an uPITR [INTWORK]). 902 The existence of mPETRs in the core allows source multicast site ITRs 903 to encapsulate multicast packets according to (S-RLOC,G) state. The 904 (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The 905 encapsulated multicast packets are decapsulated by mPETRs and then 906 forwarded according to (S-EID,G) state. The (S-EID,G) state is built 907 from the non-LISP and uLISP receiver multicast sites to the mPETRs. 909 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 911 Clearly non-LISP multicast sites can send multicast packets to non- 912 LISP receiver multicast sites. That is what they do today. However, 913 discussion is required to show how non-LISP multicast sites send 914 multicast packets to uLISP receiver multicast sites. 916 Since uLISP receiver multicast sites are not targets of any (S,G) 917 state, they simply send (S,G) PIM Join/Prune messages toward the non- 918 LISP source multicast site. Since the source multicast site, in this 919 case has not been upgraded to LISP, all multicast source host 920 addresses are routable. So this case is simplified to where a uLISP 921 receiver multicast site looks to the source multicast site as a non- 922 LISP receiver multicast site. 924 9.1.3. Non-LISP Source Site to Any Receiver Site 926 When a non-LISP source multicast site has receivers in either a non- 927 LISP/uLISP site or a LISP site, one needs to decide how the LISP 928 receiver multicast site will attach to the distribution tree. It is 929 known from Section 9.1.2 that non-LISP and uLISP receiver multicast 930 sites can join the distribution tree, but a LISP receiver multicast 931 site ETR will need to know if the source address of the multicast 932 source host is routable or not. It has been shown in Section 9.1.1 933 that an ETR, before it sends a PIM Join/Prune message on an external- 934 facing interface, does a EID-to-RLOC mapping lookup to determine if 935 it should convert the (S,G) state from a PIM Join/Prune message 936 received on a site-facing interface to a (S-RLOC,G). If the lookup 937 fails, the ETR can conclude the source multicast site is a non-LISP 938 site so it simply forwards the Join/Prune message (it also doesn't 939 need to send a unicast encapsulated Join/Prune message because there 940 is no ITR in a non-LISP site and there is namespace continuity 941 between the ETR and source). 943 For a non-LISP source multicast site, (S-EID,G) state could be 944 limited to the edges of the network with the use of multicast proxy- 945 ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast 946 packets from non-LISP source multicast and uLISP sites and 947 encapsulate them to ETRs in receiver multicast sites or to mPETRs 948 that can decapsulate for non-LISP receiver multicast or uLISP sites. 949 The mPITRs are responsible for sending (S-EID,G) joins to the non- 950 LISP source multicast site. To connect the distribution trees 951 together, multicast ETRs will need to be configured with the mPITR's 952 RLOC addresses so they can send both (S-RLOC,G) joins to build a 953 distribution tree to the mPITR as well as for sending unicast joins 954 to mPITRs so they can propogate (S-EID,G) joins into source multicast 955 sites. The use of mPITRs is undergoing more study and is work in 956 progress. 958 9.1.4. Unicast LISP Source Site to Any Receiver Sites 960 In the last section, it was explained how an ETR in a multicast 961 receiver site can determine if a source multicast site is LISP- 962 enabled by looking into the mapping database. When the source 963 multicast site is a uLISP site, it is LISP enabled but the ITR, by 964 definition is not capable of doing multicast encapsulation. So for 965 the purposes of multicast routing, the uLISP source multicast site is 966 treated as non-LISP source multicast site. 968 Non-LISP receiver multicast sites can join distribution trees to a 969 uLISP source multicast site since the source site behaves, from a 970 forwarding perspective, as a non-LISP source site. This is also the 971 case for a uLISP receiver multicast site since the ETR does not have 972 multicast functionality built-in or enabled. 974 Special considerations are required for LISP receiver multicast sites 975 since they think the source multicast site is LISP capable, the ETR 976 cannot know if ITR is LISP-Multicast capable. To solve this problem, 977 each mapping database entry will have a multicast 2-tuple (Mpriority, 978 Mweight) per RLOC [LISP]. When the Mpriority is set to 255, the site 979 is considered not multicast capable. So an ETR in a LISP receiver 980 multicast site can distinguish whether a LISP source multicast site 981 is LISP-Multicast site from a uLISP site. 983 9.1.5. LISP Source Site to Any Receiver Sites 985 When a LISP source multicast site has receivers in LISP, non-LISP, 986 and uLISP receiver multicast sites, it has a conflict about how it 987 sends multicast packets. The ITR can either encapsulate or natively 988 forward multicast packets. Since the receiver multicast sites are 989 heterogeneous in their behavior, one packet forwarding mechanism 990 cannot satisfy both. However, if a LISP receiver multicast site acts 991 like a uLISP site then it could receive packets like a non-LISP 992 receiver multicast site making all receiver multicast sites have 993 homogeneous behavior. However, this poses the following issues: 995 o LISP-NAT techniques with routable addresses would be required in 996 all cases. 998 o Or alternatively, mPETR deployment would be required forcing 999 coarse EID prefix advertisement in the core. 1001 o But what is most disturbing is that when all sites that 1002 participate are LISP-Multicast sites but then a non-LISP or uLISP 1003 site joins the distribution tree, then the existing joined LISP 1004 receiver multicast sites would have to change their behavior. 1005 This would create too much dynamic tree-building churn to be a 1006 viable alternative. 1008 So the solution space options are: 1010 1. Make the LISP ITR in the source multicast site send two packets, 1011 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 1012 multicast sites and another that is not encapsulated with 1013 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 1015 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 1016 reach LISP-Multicast sites and to reach mPETRs that can 1017 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 1018 receiver multicast sites. 1020 9.2. LISP Sites with Mixed Address Families 1022 A LISP database mapping entry that describes the locator-set, 1023 Mpriority and Mweight per locator address (RLOC), for an EID prefix 1024 associated with a site could have RLOC addresses in either IPv4 or 1025 IPv6 format. When a mapping entry has a mix of RLOC formatted 1026 addresses, it is an implicit advertisement by the site that it is a 1027 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 1028 packets. 1030 To distinguish if the site can receive dual-stack unicast packets as 1031 well as dual-stack multicast packets, the Mpriority value setting 1032 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 1033 details. 1035 If one considers the combinations of LISP, non-LISP, and uLISP sites 1036 sharing the same distribution tree and considering the capabilities 1037 of supporting IPv4, IPv6, or dual-stack, the number of total 1038 combinations grows beyond comprehension. 1040 Using some combinatorial math, the following profiles of a site and 1041 the combinations that can occur: 1043 1. LISP-Multicast IPv4 Site 1045 2. LISP-Multicast IPv6 Site 1047 3. LISP-Multicast Dual-Stack Site 1049 4. uLISP IPv4 Site 1051 5. uLISP IPv6 Site 1052 6. uLISP Dual-Stack Site 1054 7. non-LISP IPv4 Site 1056 8. non-LISP IPv6 Site 1058 9. non-LISP Dual-Stack Site 1060 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 1061 illustrate some combinatorial math below. 1063 When 1 site talks to another site, the combinatorial is (9 2), when 1 1064 site talks to another 2 sites, the combinatorial is (9 3). If sum 1065 this up to (9 9), then: 1067 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 1069 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 1071 Which results in the total number of cases to be considered at 502. 1073 This combinatorial gets even worse when one considers a site using 1074 one address family inside of the site and the xTRs use the other 1075 address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs 1076 with IPv4 RLOCs). 1078 To rationalize this combinatorial nightmare, there are some 1079 guidelines which need to be put in place: 1081 o Each distribution tree shared between sites will either be an IPv4 1082 distribution tree or an IPv6 distribution tree. Therefore, head- 1083 end replication can be avoided by building and sending packets on 1084 each address family based distribution tree. Even though there 1085 might be an urge to do multicast packet translation from one 1086 address family format to the other, it is a non-viable over- 1087 complicated urge. Multicast ITRs will only encapsulate packets 1088 where the inner and outer headers are from the same address 1089 family. 1091 o All LISP sites on a multicast distribution tree must share a 1092 common address family which is determined by the source site's 1093 locator-set in its LISP database mapping entry. All receiver 1094 multicast sites will use the best RLOC priority controlled by the 1095 source multicast site. This is true when the source site is 1096 either LISP-Multicast or uLISP capable. This means that priority- 1097 based policy modification is prohibited. When a receiver 1098 multicast site ETR receives a (S-EID,G) join, it must select a 1099 S-RLOC for the same address family as S-EID. 1101 o When a multicast locator-set has more than one locator, only 1102 locators from the same address-family MUST be set to the same best 1103 priority value. A mixed locator-set can exist (for unicast use), 1104 but the multicast priorities MUST be the set for the same address 1105 family locators. 1107 o When the source site is not LISP capable, it is up to how 1108 receivers find the source and group information for a multicast 1109 flow. That mechanism decides the address family for the flow. 1111 9.3. Making a Multicast Interworking Decision 1113 This Multicast Interworking section has shown all combinations of 1114 multicast connectivity that could occur. As already concluded, this 1115 can be quite complicated and if the design is too ambitious, the 1116 dynamics of the protocol could cause a lot of instability. 1118 The trade-off decisions are hard to make and so the same single 1119 solution is desirable to work for both IPv4 and IPv6 multicast. It 1120 is imperative to have an incrementally deployable solution for all of 1121 IPv4 unicast and multicast and IPv6 unicast and multicast while 1122 minimizing (or eliminating) both unicast and multicast EID namespace 1123 state. 1125 Therefore the design decision to go with uPITRs [INTWORK] for unicast 1126 routing and mPETRs for multicast routing seems to be the sweet spot 1127 in the solution space so state requirements can be optimized and 1128 avoid head-end data replication at ITRs. 1130 10. Considerations when RP Addresses are Embedded in Group Addresses 1132 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1133 technique exists to embed the unicast address of an RP in a IPv6 1134 group address [RFC3956]. When routers in end sites process a PIM 1135 Join/Prune message which contain an embedded-RP group address, they 1136 extract the RP address from the group address and treat it from the 1137 EID namespace. However, core routers do not have state for the EID 1138 namespace, and need to extract an RP address from the RLOC namespace. 1140 Therefore, it is the responsibility of ETRs in multicast receiver 1141 sites to map the group address into a group address where the 1142 embedded-RP address is from the RLOC namespace. The mapped RP- 1143 address is obtained from a EID-to-RLOC mapping database lookup. The 1144 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1145 the branch of the distribution tree from the source site resident RP 1146 to the ITR is created. 1148 This technique is no different than the techniques described in this 1149 specification for translating (S,G) state and propagating Join/Prune 1150 messages into the core. The only difference is that the (*,G) state 1151 in Join/Prune messages are mapped because they contain unicast 1152 addresses encoded in an Embedded-RP group address. 1154 11. Taking Advantage of Upgrades in the Core 1156 If the core routers are upgraded to support [RFC5496], then the EID 1157 specific data can be passed through the core without, possibly, 1158 having to store the state in the core. 1160 By doing this one can eliminate the ETR from unicast encapsulating 1161 PIM Join/Prune messages to the source site's ITR. 1163 However, this solution is restricted to a small set of workable cases 1164 which would not be good for general use of LISP-Multicast. In 1165 addition due to slow convergence properties, it is not being 1166 recommended for LISP-Multicast. 1168 12. Mtrace Considerations 1170 Mtrace functionality MUST be consistent with unicast traceroute 1171 functionality where all hops from multicast receiver to multicast 1172 source are visible. 1174 The design for mtrace for use in LISP-Multicast environments is to be 1175 determined but should build upon the mtrace version 2 specified in 1176 [MTRACE]. 1178 13. Security Considerations 1180 The security concerns for LISP multicast are mainly the same as for 1181 the base LISP specification [LISP] and for multicast in general, 1182 including PIM-ASM [RFC4601]. 1184 There may be a security concern with respect to unicast PIM messages. 1185 When multiple receiver sites are joining a (S-EID1,G) distribution 1186 tree that maps to a (RLOC1,G) core distribution tree, and a malicious 1187 receiver site joins a (S-EID2,G) distribution tree that also maps to 1188 the (RLOC1,G) core distribution tree, the legitimate sites will 1189 receive data from S-EID2 when they did not ask for it. 1191 Other than as noted above there are currently no known security 1192 differences between multicast with LISP and multicast without LISP. 1193 However this has not been a topic that has been investigated deeply 1194 so far therefore additional issues might arise in future. 1196 14. Acknowledgments 1198 The authors would like to gratefully acknowledge the people who have 1199 contributed discussion, ideas, and commentary to the making of this 1200 proposal and specification. People who provided expert review were 1201 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1202 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1203 Ijsbrand Wijnands. 1205 The authors would also like to thank the MBONED working group for 1206 constructive and civil verbal feedback when this draft was presented 1207 at the Fall 2008 IETF in Minneapolis. In particular, good commentary 1208 came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri 1209 Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, 1210 and Jari Arkko. 1212 An expert review of this specification was done by Yiqun Cai and 1213 Liming Wei. The authors thank them for their detailed comments. 1215 This work originated in the Routing Research Group (RRG) of the IRTF. 1216 The individual submission [MLISP] was converted into this IETF LISP 1217 working group draft. 1219 15. IANA Considerations 1221 This document makes no request of the IANA. 1223 16. References 1225 16.1. Normative References 1227 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1228 with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt 1229 (work in progress). 1231 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1232 "Locator/ID Separation Protocol (LISP)", 1233 draft-ietf-lisp-16.txt (work in progress). 1235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1236 Requirement Levels", BCP 14, RFC 2119, March 1997. 1238 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1239 Protocol (MSDP)", RFC 3618, October 2003. 1241 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1242 Point (RP) Address in an IPv6 Multicast Address", 1243 RFC 3956, November 2004. 1245 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1246 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1247 Protocol Specification (Revised)", RFC 4601, August 2006. 1249 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1250 Group Management Protocol Version 3 (IGMPv3) and Multicast 1251 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1252 Specific Multicast", RFC 4604, August 2006. 1254 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1255 IP", RFC 4607, August 2006. 1257 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1258 "Multiprotocol Extensions for BGP-4", RFC 4760, 1259 January 2007. 1261 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1262 "Bidirectional Protocol Independent Multicast (BIDIR- 1263 PIM)", RFC 5015, October 2007. 1265 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 1266 Network Address Translator (NAT) and a Network Address 1267 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 1269 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 1270 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 1272 16.2. Informative References 1274 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1275 Topology (LISP-ALT)", draft-ietf-lisp-alt-09.txt (work in 1276 progress). 1278 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1279 "LISP for Multicast Environments", 1280 draft-farinacci-lisp-multicast-01.txt (work in progress). 1282 [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace 1283 Version 2: Traceroute Facility for IP Multicast", 1284 draft-ietf-mboned-mtrace-v2-08.txt (work in progress). 1286 Appendix A. Document Change Log 1288 A.1. Changes to draft-ietf-lisp-multicast-14.txt 1290 o Posted February 2012. 1292 o Resolve Adrian Farrel's final DISCUSS comment. 1294 A.2. Changes to draft-ietf-lisp-multicast-13.txt 1296 o Posted February 2012. 1298 o Resolution to Stewart Bryant's and Adrian Farrel's comments. 1300 A.3. Changes to draft-ietf-lisp-multicast-12.txt 1302 o Posted January 2012. 1304 o Added more security disclaimers to the Security Considerations 1305 section. 1307 A.4. Changes to draft-ietf-lisp-multicast-11.txt 1309 o Posted November 2011. 1311 o Added Stig text to Security Considerations section to reflect 1312 comments from IESG review comment from Stephen Farrell. 1314 o Changed how an unicast PIM join gets sent. Do not use an ECM or 1315 else an instance-ID cannot be included in the join. So go back to 1316 what we had where the unicast PIM join is encapsulated in a 4341 1317 UDP packet. 1319 A.5. Changes to draft-ietf-lisp-multicast-10.txt 1321 o Posted second half of October 2011. Changes to reflect IESG 1322 review comments from Stephen Farrell. 1324 A.6. Changes to draft-ietf-lisp-multicast-09.txt 1326 o Posted October 2011. Changes to reflect IESG review comments from 1327 Ralph Droms and Kathleen Moriarty. 1329 A.7. Changes to draft-ietf-lisp-multicast-08.txt 1331 o Posted September 2011. Minor editorial changes from Jari's 1332 commentary. 1334 A.8. Changes to draft-ietf-lisp-multicast-07.txt 1336 o Posted July 2011. Fixing IDnits errors. 1338 A.9. Changes to draft-ietf-lisp-multicast-06.txt 1340 o Posted June 2011 to complete working group last call. 1342 o Added paragraph to section 8.1.2 based on Jesus comment about 1343 making it more clear what happens when two (S-EID,G) trees use the 1344 same (RLOC,G) tree. 1346 o Make more references to [INTWORK] when mentioning uPITRs and 1347 uPETRs. 1349 o Made many changes based on editorial and wordsmithing comments 1350 from Alia. 1352 A.10. Changes to draft-ietf-lisp-multicast-05.txt 1354 o Posted April 2011 to reset expiration timer. 1356 o Updated references. 1358 A.11. Changes to draft-ietf-lisp-multicast-04.txt 1360 o Posted October 2010 to reset expiration timer. 1362 o Updated references. 1364 A.12. Changes to draft-ietf-lisp-multicast-03.txt 1366 o Posted April 2010. 1368 o Added section 8.1.2 to address Joel Halpern's comment about 1369 receiver sites joining the same source site via 2 different RLOCs, 1370 each being a separate ITR. 1372 o Change all occurences of "mPTR" to "mPETR" to become more 1373 consistent with uPITRs and uPETRs described in [INTWORK]. That 1374 is, an mPETR is a LISP multicast router that decapsulates 1375 multicast packets that are encapsulated to it by ITRs in multicast 1376 source sites. 1378 o Add clarifications in section 9 about how homogeneous multicast 1379 encapsulation should occur. As well as describing in this 1380 section, how to deal with mixed-locator sets to avoid 1381 heterogeneous encapsulation. 1383 o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges 1384 of LISP global multicast network. 1386 A.13. Changes to draft-ietf-lisp-multicast-02.txt 1388 o Posted September 2009. 1390 o Added Document Change Log appendix. 1392 o Specify that the LISP Encapsulated Control Message be used for 1393 unicasting PIM Join/Prune messages from ETRs to ITRs. 1395 A.14. Changes to draft-ietf-lisp-multicast-01.txt 1397 o Posted November 2008. 1399 o Specified that PIM Join/Prune unicast messages that get sent from 1400 ETRs to ITRs of a source multicast site get LISP encapsulated in 1401 destination UDP port 4342. 1403 o Add multiple RLOCs per ITR per Yiqun's comments. 1405 o Indicate how static RPs can be used when LISP is run using Bidir- 1406 PIM in the core. 1408 o Editorial changes per Liming comments. 1410 o Add Mttrace Considersations section. 1412 A.15. Changes to draft-ietf-lisp-multicast-00.txt 1414 o Posted April 2008. 1416 o Renamed from draft-farinacci-lisp-multicast-01.txt. 1418 Authors' Addresses 1420 Dino Farinacci 1421 cisco Systems 1422 Tasman Drive 1423 San Jose, CA 1424 USA 1426 Email: dino@cisco.com 1428 Dave Meyer 1429 cisco Systems 1430 Tasman Drive 1431 San Jose, CA 1432 USA 1434 Email: dmm@cisco.com 1436 John Zwiebel 1437 cisco Systems 1438 Tasman Drive 1439 San Jose, CA 1440 USA 1442 Email: jzwiebel@cisco.com 1444 Stig Venaas 1445 cisco Systems 1446 Tasman Drive 1447 San Jose, CA 1448 USA 1450 Email: stig@cisco.com