idnits 2.17.1 draft-ietf-lisp-multicast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1164 has weird spacing: '...ss (and port)...' -- The document date (May 28, 2009) is 5441 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-01 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-00 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-multicast-07 == Outdated reference: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-03 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-06 Summary: 3 errors (**), 0 flaws (~~), 8 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: November 29, 2009 S. Venaas 6 cisco Systems 7 May 28, 2009 9 LISP for Multicast Environments 10 draft-ietf-lisp-multicast-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 29, 2009. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This draft describes how inter-domain multicast routing will function 49 in an environment where Locator/ID Separation is deployed using the 50 LISP architecture. 52 Table of Contents 54 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 57 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 59 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 60 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 61 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 62 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 63 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 64 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 65 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 66 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 67 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 68 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 69 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 70 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 71 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22 72 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 73 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23 74 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25 75 10. Considerations when RP Addresses are Embedded in Group 76 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27 78 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 80 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 82 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31 83 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 86 1. Requirements Notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 The Locator/ID Separation Architecture [LISP] provides a mechanism to 95 separate out Identification and Location semantics from the current 96 definition of an IP address. By creating two namespaces, an EID 97 namespace used by sites and a Locator (RLOC) namespace used by core 98 routing, the core routing infrastructure can scale by doing 99 topological aggregation of routing information. 101 Since LISP creates a new namespace, a mapping function must exist to 102 map a site's EID prefixes to its associated locators. For unicast 103 packets, both the source address and destination address must be 104 mapped. For multicast packets, only the source address needs to be 105 mapped. The destination group address doesn't need to be mapped 106 because the semantics of an IPv4 or IPv6 group address are logical in 107 nature and not topology-dependent. Therefore, this specifications 108 focuses on to map a source EID address of a multicast flow during 109 distribution tree setup and packet delivery. 111 This specification will address the following scenarios: 113 1. How a multicast source host in a LISP site sends multicast 114 packets to receivers inside of its site as well as to receivers 115 in other sites that are LISP enabled. 117 2. How inter-domain (or between LISP sites) multicast distribution 118 trees are built and how forwarding of multicast packets leaving a 119 source site toward receivers sites is performed. 121 3. What protocols are affected and what changes are required to such 122 multicast protocols. 124 4. How ASM-mode, SSM-mode, and Bidir-mode service models will 125 operate. 127 5. How multicast packet flow will occur for multiple combinations of 128 LISP and non-LISP capable source and receiver sites, for example: 130 A. How multicast packets from a source host in a LISP site are 131 sent to receivers in other sites when they are all non-LISP 132 sites. 134 B. How multicast packets from a source host in a LISP site are 135 sent to receivers in both LISP-enabled sites and non-LISP 136 sites. 138 C. How multicast packets from a source host in a non-LISP site 139 are sent to receivers in other sites when they are all LISP- 140 enabled sites. 142 D. How multicast packets from a source host in a non-LISP site 143 are sent to receivers in both LISP-enabled sites and non-LISP 144 sites. 146 This specification focuses on what changes are needed to the 147 multicast routing protocols to support LISP-Multicast as well as 148 other protocols used for inter-domain multicast, such as Multi- 149 protocol BGP (MBGP) [RFC4760]. The approach proposed in this 150 specification requires no changes to the multicast infrastructure 151 inside of a site when all sources and receivers reside in that site, 152 even when the site is LISP enabled. That is, internal operation of 153 multicast is unchanged regardless of whether or not the site is LISP 154 enabled or whether or not receivers exist in other sites which are 155 LISP-enabled. 157 Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], 158 and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not 159 run in an inter-domain environment is not addressed in depth in this 160 version of the specification. 162 Also, the current version of this specification does not describe 163 multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR 164 descriptions in [LISP]. 166 3. Definition of Terms 168 The terminology in this section is consistent with the definitions in 169 [LISP] but is extended specifically to deal with the application of 170 the terminology to multicast routing. 172 LISP-Multicast: a reference to the design in this specification. 173 That is, when any site that is participating in multicast 174 communication has been upgraded to be a LISP site, the operation 175 of control-plane and data-plane protocols is considered part of 176 the LISP-Multicast architecture. 178 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 179 used in the source address field of the first (most inner) LISP 180 header of a multicast packet. The host obtains a destination 181 group address the same way it obtains one today, as it would when 182 it is a non-LISP site. The source EID is obtained via existing 183 mechanisms used to set a host's "local" IP address. An EID is 184 allocated to a host from an EID prefix block associated with the 185 site the host is located in. An EID can be used by a host to 186 refer to another host, as when it joins an SSM (S-EID,G) route 187 using IGMP version 3 [RFC4604]. LISP uses Provider Independent 188 (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 189 Note that EID blocks may be assigned in a hierarchical manner, 190 independent of the network topology, to facilitate scaling of the 191 mapping database. In addition, an EID block assigned to a site 192 may have site-local structure (subnetting) for routing within the 193 site; this structure is not visible to the global routing system. 195 Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress 196 tunnel router (ITR), the router in the multicast source host's 197 site that encapsulates multicast packets. It is the output of a 198 EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. 199 Typically, RLOCs are numbered from topologically-aggregatable 200 blocks that are assigned to a site at each point to which it 201 attaches to the global Internet; where the topology is defined by 202 the connectivity of provider networks, RLOCs can be thought of as 203 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned 204 to the same ITR device or to multiple ITR devices at a site. 206 Ingress Tunnel Router (ITR): a router which accepts an IP multicast 207 packet with a single IP header (more precisely, an IP packet that 208 does not contain a LISP header). The router treats this "inner" 209 IP destination multicast address opaquely so it doesn't need to 210 perform a map lookup on the group address because it is 211 topologically insignificant. The router then prepends an "outer" 212 IP header with one of its globally-routable RLOCs as the source 213 address field. This RLOC is known to other multicast receiver 214 sites which have used the mapping database to join a multicast 215 tree for which the ITR is the root. In general, an ITR receives 216 IP packets from site end systems on one side and sends LISP- 217 encapsulated multicast IP packets out all external interfaces 218 which have been joined. 220 An ITR would receive a multicast packet from a source inside of 221 its site when 1) it is on the path from the multicast source to 222 internally joined receivers, or 2) when it is on the path from the 223 multicast source to externally joined receivers. 225 Egress Tunnel Router (ETR): a router that is on the path from a 226 multicast source host in another site to a multicast receiver in 227 its own site. An ETR accepts a PIM Join/Prune message from a site 228 internal PIM router destined for the source's EID in the multicast 229 source site. The ETR maps the source EID in the Join/Prune 230 message to an RLOC address based on the EID-to-RLOC mapping. This 231 sets up the ETR to accept multicast encapsulated packets from the 232 ITR in the source multicast site. A multicast ETR decapsulates 233 multicast encapsulated packets and replicates them on interfaces 234 leading to internal receivers. 236 xTR: is a reference to an ITR or ETR when direction of data flow is 237 not part of the context description. xTR refers to the router that 238 is the tunnel endpoint. Used synonymously with the term "Tunnel 239 Router". For example, "An xTR can be located at the Customer Edge 240 (CE) router", meaning both ITR and ETR functionality can be at the 241 CE router. 243 LISP Header: a term used in this document to refer to the outer 244 IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR 245 prepends headers and an ETR strips headers. A LISP encapsulated 246 multicast packet will have an "inner" header with the source EID 247 in the source field; an "outer" header with the source RLOC in the 248 source field: and the same globally unique group address in the 249 destination field of both the inner and outer header. 251 (S,G) State: the formal definition is in the PIM Sparse Mode 252 [RFC4601] specification. For this specification, the term is used 253 generally to refer to multicast state. Based on its topological 254 location, the (S,G) state resides in routers can be either 255 (S-EID,G) state (at a location where the (S,G) state resides) or 256 (S-RLOC,G) state (in the Internet core). 258 (S-EID,G) State: refers to multicast state in multicast source and 259 receiver sites where S-EID is the IP address of the multicast 260 source host (its EID). An S-EID can appear in an IGMPv3 report, 261 an MSDP SA message or a PIM Join/Prune message that travels inside 262 of a site. 264 (S-RLOC,G) State: refers to multicast state in the core where S is 265 a source locator (the IP address of a multicast ITR) of a site 266 with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) 267 entry by doing a mapping database lookup for the EID prefix that 268 S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message 269 when it travels from an ETR to an ITR over the Internet core. 271 uLISP Site: a unicast only LISP site according to [LISP] which has 272 not deployed the procedures of this specification and therefore, 273 for multicast purposes, follows the procedures from Section 9. 275 mPTR: this is a multicast PTR that is responsible for advertising a 276 very coarse EID prefix which non-LISP and uLISP sites can target 277 their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP 278 source multicast sites can send multicast packets using source 279 addresses from the EID namespace. mPTRs act as Proxy ETRs for 280 supporting multicast routing in a LISP infrastructure. 282 Mixed Locator-Sets: this is a locator-set for a LISP database 283 mapping entry where the RLOC addresses in the locator-set are in 284 both IPv4 and IPv6 format. 286 Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM 287 Join/Prune message (LISP encapsulated with destination UDP port 288 4341) which is sent by ETRs at multicast receiver sites to an ITR 289 at a multicast source site. This message is sent periodically as 290 long as there are interfaces in the oif-list for the (S-EID,G) 291 entry the ETR is joining for. 293 4. Basic Overview 295 LISP, when used for unicast routing, increases the site's ability to 296 control ingress traffic flows. Egress traffic flows are controlled 297 by the IGP in the source site. For multicast, the IGP coupled with 298 PIM can decide which path multicast packets ingress. By using the 299 traffic engineering features of LISP, a multicast source site can 300 control the egress of its multicast traffic. By controlling the 301 priorities of locators from a mapping database entry, a source 302 multicast site can control which way multicast receiver sites join to 303 the source site. 305 At this point in time, we don't see a requirement for different 306 locator-sets, priority, and weight policies for multicast than we 307 have for unicast. 309 The fundamental multicast forwarding model is to encapsulate a 310 multicast packet into another multicast packet. An ITR will 311 encapsulate multicast packets received from sources that it serves in 312 another LISP multicast header. The destination group address from 313 the inner header is copied to the destination address of the outer 314 header. The inner source address is the EID of the multicast source 315 host and the outer source address is the RLOC of the encapsulating 316 ITR. 318 The LISP-Multicast architecture will follow this high-level protocol 319 and operational sequence: 321 1. Receiver hosts in multicast sites will join multicast content the 322 way they do today, they use IGMP. When they use IGMPv3 where 323 they specify source addresses, they use source EIDs, that is they 324 join (S-EID,G). If the S-EID is a local multicast source host. 325 If the multicast source is external to this receiver site, the 326 PIM Join/Prune message flows toward the ETRs, finding the 327 shortest exit (that is the closest exit for the Join/Prune 328 message but it is the closest entrance for the multicast packet 329 to the receiver). 331 2. The ETR does a mapping database lookup for S-EID. If the mapping 332 is cached from a previous lookup (from either a previous Join/ 333 Prune for the source multicast site or a unicast packet that went 334 to the site), it will use the RLOC information from the mapping. 335 The ETR will use the same priority and weighting mechanism as for 336 unicast. So the source site can decide which way multicast 337 packets egress. 339 3. The ETR will build two PIM Join/Prune messages, one that contains 340 a (S-EID,G) entry that is unicast to the ITR that matches the 341 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 342 entry so the core network can create multicast state from this 343 ETR to the ITR. 345 4. When the ITR gets the unicast Join/Prune message (see Section 3 346 for formal definition), it will process (S-EID,G) entries in the 347 message and propagate them inside of the site where it has 348 explicit routing information for EIDs via the IGP. When the ITR 349 receives the (S-RLOC,G) PIM Join/Prune message it will process it 350 like any other join it would get in today's Internet. The S-RLOC 351 address is the IP address of this ITR. 353 5. At this point there is (S-EID,G) state from the joining host in 354 the receiver multicast site to the ETR of the receiver multicast 355 site. There is (S-RLOC,G) state across the core network from the 356 ETR of the multicast receiver site to the ITR in the multicast 357 source site and (S-EID,G) state in the source multicast site. 358 Note, the (S-EID,G) state is the same S-EID in each multicast 359 site. As other ETRs join the same multicast tree, they can join 360 through the same ITR (in which case the packet replication is 361 done in the core) or a different ITR (in which case the packet 362 replication is done at the source site). 364 6. When a packet is originated by the multicast host in the source 365 site, it will flow to one or more ITRs which will prepend a LISP 366 header by copying the group address to the outer destination 367 address field and insert its own locator address in the outer 368 source address field. The ITR will look at its (S-RLOC,G) state, 369 where S-RLOC is its own locator address, and replicate the packet 370 on each interface a (S-RLOC,G) joined was received on. The core 371 has (S-RLOC,G) so where fanout occurs to multiple sites, a core 372 router will do packet replication. 374 7. When either the source site or the core replicates the packet, 375 the ETR will receive a LISP packet with a destination group 376 address. It will also decapsulate packets because it has 377 receivers for the group. Otherwise, it would have not received 378 the packets because it would not have joined. The ETR 379 decapsulates and does a (S-EID,G) lookup in its multicast FIB to 380 forward packets out one or more interfaces to forward the packet 381 to internal receivers. 383 This architecture is consistent and scalable with the architecture 384 presented in [LISP] where multicast state in the core operates on 385 locators and multicast state at the sites operates on EIDs. 387 Alternatively, [LISP] does present a mechanism where (S-EID,G) state 388 can reside in the core through the use of RPF-vectors [RPFV] in PIM 389 Join/Prune messages. However, this will require EID state in core as 390 well as the use of RPF-vector formatted Join/Prune messages which are 391 not the default implementation choice. So we choose a design that 392 can allow the separation of namespaces as unicast LISP provides. It 393 will be at the expense of creating new (S-RLOC,G) state when ITRs go 394 unreachable. See Section 5 for details. 396 However, we have some observations on the algorithm above. We can 397 scale the control plane but at the expense of sending data to sites 398 which may have not joined the distribution tree where the 399 encapsulated data is being delivered. For example, one site joins 400 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 401 same multicast source site. Both multicast receiver sites join to 402 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 403 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 404 site. The ITR receives (S-RLOC,G) joins and populates the oif-list 405 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 406 (S-RLOC,G) packets will be delivered by the core to both multicast 407 receiver sites even though each have joined a single source-based 408 distribution tree. This behavior is a consequence of the many-to-one 409 mapping between S-EIDs and a S-RLOC. 411 There is a possible solution to this problem which reduces the number 412 of many-to-one occurrences of (S-EID,G) entries aggregating into a 413 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 414 RLOC addresses and these addresses are advertised in mapping database 415 entries, then ETRs at receiver sites have more RLOC address options 416 and therefore can join different (RLOC,G) entries for each (S-EID,G) 417 entry joined at the receiver site. It would not scale to have a one- 418 to-one relationship between the number of S-EID sources at a source 419 site and the number of RLOCs assigned to all ITRs at the site, but we 420 can reduce the "n" to a smaller number in the "n-to-1" relationship. 421 And in turn, reduce the opportunity for data packets to be delivered 422 to sites for groups not joined. 424 5. Source Addresses versus Group Addresses 426 Multicast group addresses don't have to be associated with either the 427 EID or RLOC namespace. They actually are a namespace of their own 428 that can be treated as logical with relatively opaque allocation. 429 So, by their nature, they don't detract from an incremental 430 deployment of LISP-Multicast. 432 As for source addresses, as in the unicast LISP scenario, there is a 433 decoupling of identification from location. In a LISP site, packets 434 are originated from hosts using their allocated EIDs, those addresses 435 are used to identify the host as well as where in the site's topology 436 the host resides but not how and where it is attached to the 437 Internet. 439 Therefore, when multicast distribution tree state is created anywhere 440 in the network on the path from any multicast receiver to a multicast 441 source, EID state is maintained at the source and receiver multicast 442 sites, and RLOC state is maintained in the core. That is, a 443 multicast distribution tree will be represented as a 3-tuple of 444 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 445 3-tuple is the state stored in routers from the source to one or more 446 ITRs in the source multicast site, the second element of the 3-tuple 447 is the state stored in routers downstream of the ITR, in the core, to 448 all LISP receiver multicast sites, and the third element in the 449 3-tuple is the state stored in the routers downstream of each ETR, in 450 each receiver multicast site, reaching each receiver. Note that 451 (S-EID,G) is the same in both the source and receiver multicast 452 sites. 454 The concatenation/mapping from the first element to the second 455 element of the 3-tuples is done by the ITR and from the second 456 element to the third element is done at the ETRs. 458 6. Locator Reachability Implications on LISP-Multicast 460 Multicast state as it is stored in the core is always (S,G) state as 461 it exists today or (S-RLOC,G) state as it will exist when LISP sites 462 are deployed. The core routers cannot distinguish one from the 463 other. They don't need to because it is state that RPFs against the 464 core routing tables in the RLOC namespace. The difference is where 465 the root of the distribution tree for a particular source is. In the 466 traditional multicast core, the source S is the source host's IP 467 address. For LISP-Multicast the source S is a single ITR of the 468 multicast source site. 470 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 471 ETR propagates a PIM Join/Prune message out of a receiver multicast 472 site. The selection is based on the same algorithm an ITR would use 473 to select an ETR when sending a unicast packet to the site. In the 474 unicast case, the ITR can change on a per-packet basis depending on 475 the reachability of the ETR. So an ITR can change relatively easily 476 using local reachability state. However, in the multicast case, when 477 an ITR goes unreachable, new distribution tree state must be built 478 because the encapsulating root has changed. This is more significant 479 than an RPF-change event, where any router would typically locally 480 change its RPF-interface for its existing tree state. But when an 481 encapsulating LISP-Multicast ITR goes unreachable, new distribution 482 state must be rebuilt and reflect the new encapsulator. Therefore, 483 when an ITR goes unreachable, all ETRs that are currently joined to 484 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 485 to the new ITR as well as send a unicast encapsulated Join/Prune 486 message telling the new ITR which (S-EID,G) is being joined. 488 This issue can be mitigated by using anycast addressing for the ITRs 489 so the problem does reduce to an RPF change in the core, but still 490 requires a unicast encapsulated Join/Prune message to tell the new 491 ITR about (S-EID,G). The problem with this approach is that the ETR 492 really doesn't know when the ITR has changed so the new anycast ITR 493 will get the (S-EID,G) state only when the ETR sends it the next time 494 during its periodic sending procedures. 496 7. Multicast Protocol Changes 498 A number of protocols are used today for inter-domain multicast 499 routing: 501 IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for 502 LISP-Multicast for two reasons. One being that they are link- 503 local and not used over site boundaries and second they advertise 504 group addresses that don't need translation. Where source 505 addresses are supplied in IGMPv3 and MLDv2 messages, they are 506 semantically regarded as EIDs and don't need to be converted to 507 RLOCs until the multicast tree-building protocol, such as PIM, is 508 received by the ETR at the site boundary. Addresses used for IGMP 509 and MLD come out of the source site's allocated addresses which 510 are therefore from the EID namespace. 512 MBGP: Even though MBGP is not a multicast routing protocol, it is 513 used to find multicast sources when the unicast BGP peering 514 topology and the multicast MBGP peering topology are not 515 congruent. When MBGP is used in a LISP-Multicast environment, the 516 prefixes which are advertised are from the RLOC namespace. This 517 allows receiver multicast sites to find a path to the source 518 multicast site's ITRs. MBGP peering addresses will be from the 519 RLOC namespace. 521 MSDP: MSDP is used to announce active multicast sources to other 522 routing domains (or LISP sites). The announcements come from the 523 PIM Rendezvous Points (RPs) from sites where there are active 524 multicast sources sending to various groups. In the context of 525 LISP-Multicast, the source addresses advertised in MSDP will 526 semantically be from the EID namespace since they describe the 527 identity of a source multicast host. It will be true that the 528 state stored in MSDP caches from core routers will be from the EID 529 namespace. An RP address inside of site will be from the EID 530 namespace so it can be advertised and reached by internal unicast 531 routing mechanism. However, for MSDP peer-RPF checking to work 532 properly across sites, the RP addresses must be converted or 533 mapped into a routable address that is advertised and maintained 534 in the BGP routing tables in the core. MSDP peering addresses can 535 come out of either the EID or a routable address namespace. And 536 the choice can be made unilaterally because the ITR at the site 537 will determine which namespace the destination peer address is out 538 of by looking in the mapping database service. 540 PIM-SSM: In the simplest form of distribution tree building, when 541 PIM operates in SSM mode, a source distribution tree is built and 542 maintained across site boundaries. In this case, there is a small 543 modification to the operation of the PIM protocol (but not to any 544 message format) to support taking a Join/Prune message originated 545 inside of a LISP site with embedded addresses from the EID 546 namespace and converting them to addresses from the RLOC namespace 547 when the Join/Prune message crosses a site boundary. This is 548 similar to the requirements documented in [MNAT]. 550 PIM-Bidir: Bidirectional PIM is typically run inside of a routing 551 domain, but if deployed in an inter-domain environment, one would 552 have to decide if the RP address of the shared-tree would be from 553 the EID namespace or the RLOC namespace. If the RP resides in a 554 site-based router, then the RP address is from the EID namespace. 555 If the RP resides in the core where RLOC addresses are routed, 556 then the RP address is from the RLOC namespace. This could be 557 easily distinguishable if the EID address were well-known address 558 allocation block from the RLOC namespace. Also, when using 559 Embedded-RP for RP determination [RFC3956], the format of the 560 group address could indicate the namespace the RP address is from. 561 However, refer to Section 10 for considerations core routers need 562 to make when using Embedded-RP IPv6 group addresses. When using 563 Bidir-PIM for inter-domain multicast routing, it is recommended to 564 use staticly configured RPs so core routers think the Bidir group 565 is associated with an ITR's RLOC as the RP address and site 566 routers think the Bidir group is associated with the site resident 567 RP with an EID address. With respect to DF-election in Bidir PIM, 568 no changes are required since all messaging and addressing is 569 link-local. 571 PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is 572 deployed in the Internet today is by having shared-trees within a 573 site and using source-trees across sites. By the use of MSDP and 574 PIM-SSM techniques described above, we can get multicast 575 connectivity across LISP sites. Having said that, that means 576 there are no special actions required for processing (*,G) or 577 (S,G,R) Join/Prune messages since they all operate against the 578 shared-tree which is site resident. Just like with ASM, there is 579 no (*,G) in the core when LISP-Multicast is in use. This is also 580 true for the RP-mapping mechanisms Auto-RP and BSR. 582 Based on the protocol description above, the conclusion is that there 583 are no protocol message format changes, just a translation function 584 performed at the control-plane. This will make for an easier and 585 faster transition for LISP since fewer components in the network have 586 to change. 588 It should also be stated just like it is in [LISP] that no host 589 changes, whatsoever, are required to have a multicast source host 590 send multicast packets and for a multicast receiver host to receive 591 multicast packets. 593 8. LISP-Multicast Data-Plane Architecture 595 The LISP-Multicast data-plane operation conforms to the operation and 596 packet formats specified in [LISP]. However, encapsulating a 597 multicast packet from an ITR is a much simpler process. The process 598 is simply to copy the inner group address to the outer destination 599 address. And to have the ITR use its own IP address (its RLOC), and 600 as the source address. The process is simpler for multicast because 601 there is no EID-to-RLOC mapping lookup performed during packet 602 forwarding. 604 In the decapsulation case, the ETR simply removes the outer header 605 and performs a multicast routing table lookup on the inner header 606 (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is 607 used to replicate the packet on site-facing interfaces leading to 608 multicast receiver hosts. 610 There is no Data-Probe logic for ETRs as there can be in the unicast 611 forwarding case. 613 8.1. ITR Forwarding Procedure 615 The following procedure is used by an ITR, when it receives a 616 multicast packet from a source inside of its site: 618 1. A multicast data packet sent by a host in a LISP site will have 619 the source address equal to the host's EID and the destination 620 address equal to the group address of the multicast group. It is 621 assumed the group information is obtained by current methods. 622 The same is true for a multicast receiver to obtain the source 623 and group address of a multicast flow. 625 2. When the ITR receives a multicast packet, it will have both S-EID 626 state and S-RLOC state stored. Since the packet was received on 627 a site-facing interface, the RPF lookup is based on the S-EID 628 state. If the RPF check succeeds, then the oif-list contains 629 interfaces that are site-facing and external-facing. For the 630 site-facing interfaces, no LISP header is prepended. For the 631 external-facing interfaces a LISP header is prepended. When the 632 ITR prepends a LISP header, it uses its own RLOC address as the 633 source address and copies the group address supplied by the IP 634 header the host built as the outer destination address. 636 8.1.1. Multiple RLOCs for an ITR 638 Typically, an ITR will have a single RLOC address but in some cases 639 there could be multiple RLOC addresses assigned from either the same 640 or different service providers. In this case when (S-RLOC,G) Join/ 641 Prune messages are received for each RLOC, there is a oif-list 642 merging action that must take place. Therefore, when a packet is 643 received from a site-facing interface that matches on a (S-EID,G) 644 entry, the interfaces of the oif-list from all (RLOC,G) entries 645 joined to the ITR as well as the site-facing oif-list joined for 646 (S-EID,G) must be part be included in packet replication. In 647 addition to replicating for all types of oif-lists, each oif entry 648 must be tagged with the RLOC address, so encapsulation uses the outer 649 source address for the RLOC joined. 651 8.2. ETR Forwarding Procedure 653 The following procedure is used by an ETR, when it receives a 654 multicast packet from a source outside of its site: 656 1. When a multicast data packet is received by an ETR on an 657 external-facing interface, it will do an RPF lookup on the S-RLOC 658 state it has stored. If the RPF check succeeds, the interfaces 659 from the oif-list are used for replication to interfaces that are 660 site-facing as well as interfaces that are external-facing (this 661 ETR can also be a transit multicast router for receivers outside 662 of its site). When the packet is to be replicated for an 663 external-facing interface, the LISP encapsulation header are not 664 stripped. When the packet is replicated for a site-facing 665 interface, the encapsulation header is stripped. 667 2. The packet without a LISP header is now forwarded down the 668 (S-EID,G) distribution tree in the receiver multicast site. 670 8.3. Replication Locations 672 Multicast packet replication can happen in the following topological 673 locations: 675 o In an IGP multicast router inside a site which operates on S-EIDs. 677 o In a transit multicast router inside of the core which operates on 678 S-RLOCs. 680 o At one or more ETR routers depending on the path a Join/Prune 681 message exits a receiver multicast site. 683 o At one or more ITR routers in a source multicast site depending on 684 what priorities are returned in a Map-Reply to receiver multicast 685 sites. 687 In the last case the source multicast site can do replication rather 688 than having a single exit from the site. But this only can occur 689 when the priorities in the Map-Reply are modified for different 690 receiver multicast site so that the PIM Join/Prune messages arrive at 691 different ITRs. 693 This policy technique, also used in [ALT] for unicast, is useful for 694 multicast to mitigate the problems of changing distribution tree 695 state as discussed in Section 6. 697 9. LISP-Multicast Interworking 699 This section will describe the multicast corollary to [INTWORK] which 700 describes the interworking of multicast routing among LISP and non- 701 LISP sites. 703 9.1. LISP and non-LISP Mixed Sites 705 Since multicast communication can involve more than two entities to 706 communicate together, the combinations of interworking scenarios are 707 more involved. However, the state maintained for distribution trees 708 at the sites is the same regardless of whether or not the site is 709 LISP enabled or not. So most of the implications are in the core 710 with respect to storing routable EID prefixes from either PA or PI 711 blocks. 713 Before we enumerate the multicast interworking scenarios, we must 714 define 3 deployment states of a site: 716 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 717 does today. The addresses for the site are globally routable. 719 o A site that deploys LISP for unicast routing. The addresses for 720 the site are not globally routable. Let's define the name for 721 this type of site as a uLISP site. 723 o A site that deploys LISP for both unicast and multicast routing. 724 The addresses for the site are not globally routable. Let's 725 define the name for this type of site as a LISP-Multicast site. 727 We will not consider a LISP site enabled for multicast purposes only 728 but do consider a uLISP site as documented in [INTWORK]. In this 729 section we don't discuss how a LISP site sends multicast packets when 730 all receiver sites are LISP-Multicast enabled; that has been 731 discussed in previous sections. 733 The following scenarios exist to make LISP-Multicast sites interwork 734 with non-LISP-Multicast sites: 736 1. A LISP site must be able to send multicast packets to receiver 737 sites which are a mix of non-LISP sites and uLISP sites. 739 2. A non-LISP site must be able to send multicast packets to 740 receiver sites which are a mix of non-LISP sites and uLISP sites. 742 3. A non-LISP site must be able to send multicast packets to 743 receiver sites which are a mix of LISP sites, uLISP sites, and 744 non-LISP sites. 746 4. A uLISP site must be able to send multicast packets to receiver 747 sites which are a mix of LISP sites, uLISP sites, and non-LISP 748 sites. 750 5. A LISP site must be able to send multicast packets to receiver 751 sites which are a mix of LISP sites, uLISP sites, and non-LISP 752 sites. 754 9.1.1. LISP Source Site to non-LISP Receiver Sites 756 In the first scenario, a site is LISP capable for both unicast and 757 multicast traffic and as such operates on EIDs. Therefore there is a 758 possibility that the EID prefix block is not routable in the core. 759 For LISP receiver multicast sites this isn't a problem but for non- 760 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 761 is received by the edge router, it has no route to propagate the 762 Join/Prune message out of the site. This is no different than the 763 unicast case that LISP-NAT in [INTWORK] solves. 765 LISP-NAT allows a unicast packet that exits a LISP site to get its 766 source address mapped to a globally routable address before the ITR 767 realizes that it should not encapsulate the packet destined to a non- 768 LISP site. For a multicast packet to leave a LISP site, distribution 769 tree state needs to be built so the ITR can know where to send the 770 packet. So the receiver multicast sites need to know about the 771 multicast source host by its routable address and not its EID 772 address. When this is the case, the routable address is the 773 (S-RLOC,G) state that is stored and maintained in the core routers. 774 It is important to note that the routable address for the host cannot 775 be the same as an RLOC for the site. Because we want the ITRs to 776 process a received PIM Join/Prune message from an external-facing 777 interface to be propagated inside of the site so the site-part of the 778 distribution tree is built. 780 Using a globally routable source address allows non-LISP and uLISP 781 multicast receiver to join, create, and maintain a multicast 782 distribution tree. However, the LISP multicast receiver site will 783 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 784 Prune message is received on a site-facing interface. It does this 785 because it wants to find a (S-RLOC,G) entry to Join in the core. So 786 we have a conflict of behavior between the two types of sites. 788 The solution to this problem is the same as when an ITR wants to send 789 a unicast packet to a destination site but needs determine if the 790 site is LISP capable or not. When it is not LISP capable, the ITR 791 does not encapsulate the packet. So for the multicast case, when ETR 792 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 793 mapping table lookup on S-EID. In this case, S-EID is not in the 794 mapping database because the source multicast site is using a 795 routable address and not an EID prefix address. So the ETR knows to 796 simply propagate the PIM Join/Prune message to a external-facing 797 interface without converting the (S-EID,G) because it is an (S,G) 798 where S is routable and reachable via core routing tables. 800 Now that the multicast distribution tree is built and maintained from 801 any non-LISP or uLISP receiver multicast site, the way packet 802 forwarding model is performed can be explained. 804 Since the ITR in the source multicast site has never received a 805 unicast encapsulated PIM Join/Prune message from any ETR in a 806 receiver multicast site, it knows there are no LISP-Multicast 807 receiver sites. Therefore, there is no need for the ITR to 808 encapsulate data. Since it will know a priori (via configuration) 809 that its site's EIDs are not routable, it assumes that the multicast 810 packets from the source host are sent by a routable address. That 811 is, it is the responsibility of the multicast source host's system 812 administrator to ensure that the source host sends multicast traffic 813 using a routable source address. When this happens, the ITR acts 814 simply as a router and forwards the multicast packet like an ordinary 815 multicast router. 817 There is an alternative to using a LISP-NAT scheme just like there is 818 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 819 (PTRs). This can work the same way for multicast routing as well, 820 but the difference is that non-LISP and uLISP sites will send PIM 821 Join/Prune messages for (S-EID,G) which make their way in the core to 822 PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). 823 Since the PTRs advertise very coarse EID prefixes, they draw the PIM 824 Join/Prune control traffic making them the target of the distribution 825 tree. To get multicast packets from the LISP source multicast sites, 826 the tree needs to be built on the path from the mPTR to the LISP 827 source multicast site. To make this happen the mPTR acts as a "Proxy 828 ETR" (where in unicast it acts as a "Proxy ITR"). 830 The existence of mPTRs in the core allows LISP source multicast site 831 ITRs to encapsulate multicast packets so the state built between the 832 ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can 833 decapsulate packets and forward natively to the non-LISP and uLISP 834 receiver multicast sites. 836 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 838 Clearly non-LISP multicast sites can send multicast packets to non- 839 LISP receiver multicast sites. That is what they do today. However, 840 discussion is required to show how non-LISP multicast sites send 841 multicast packets to uLISP receiver multicast sites. 843 Since uLISP receiver multicast sites are not targets of any (S,G) 844 state, they simply send (S,G) PIM Join/Prune messages toward the non- 845 LISP source multicast site. Since the source multicast site, in this 846 case has not been upgraded to LISP, all multicast source host 847 addresses are routable. So this case is simplified to where a uLISP 848 receiver multicast site looks to the source multicast site as a non- 849 LISP receiver multicast site. 851 9.1.3. Non-LISP Source Site to Any Receiver Site 853 When a non-LISP source multicast site has receivers in either a non- 854 LISP/uLISP site or a LISP site, one needs to decide how the LISP 855 receiver multicast site will attach to the distribution tree. We 856 know from Section 9.1.2 that non-LISP and uLISP receiver multicast 857 sites can join the distribution tree, but a LISP receiver multicast 858 site ETR will need to know if the source address of the multicast 859 source host is routable or not. We showed in Section 9.1.1 that an 860 ETR, before it sends a PIM Join/Prune message on an external-facing 861 interface, does a EID-to-RLOC mapping lookup to determine if it 862 should convert the (S,G) state from a PIM Join/Prune message received 863 on a site-facing interface to a (S-RLOC,G). If the lookup fails, the 864 ETR can conclude the source multicast site is a non-LISP site so it 865 simply forwards the Join/Prune message (it also doesn't need to send 866 a unicast encapsulated Join/Prune message because there is no ITR in 867 a non-LISP site and there is namespace continuity between the ETR and 868 source). 870 9.1.4. Unicast LISP Source Site to Any Receiver Sites 872 In the last section, it was explained how an ETR in a multicast 873 receiver site can determine if a source multicast site is LISP- 874 enabled by looking into the mapping database. When the source 875 multicast site is a uLISP site, it is LISP enabled but the ITR, by 876 definition is not capable of doing multicast encapsulation. So for 877 the purposes of multicast routing, the uLISP source multicast site is 878 treated as non-LISP source multicast site. 880 Non-LISP receiver multicast sites can join distribution trees to a 881 uLISP source multicast site since the source site behaves, from a 882 forwarding perspective, as a non-LISP source site. This is also the 883 case for a uLISP receiver multicast site since the ETR does not have 884 multicast functionality built-in or enabled. 886 Special considerations are required for LISP receiver multicast sites 887 since they think the source multicast site is LISP capable, the ETR 888 cannot know if ITR is LISP-Multicast capable. To solve this problem, 889 each mapping database entry will have a multicast 2-tuple (Mpriority, 890 Mweight) per RLOC. When the Mpriority is set to 255, the site is 891 considered not multicast capable. So an ETR in a LISP receiver 892 multicast site can distinguish whether a LISP source multicast site 893 is LISP-Multicast site from a uLISP site. 895 9.1.5. LISP Source Site to Any Receiver Sites 897 When a LISP source multicast site has receivers in LISP, non-LISP, 898 and uLISP receiver multicast sites, it has a conflict about how it 899 sends multicast packets. The ITR can either encapsulate or natively 900 forward multicast packets. Since the receiver multicast sites are 901 heterogeneous in their behavior, one packet forwarding mechanism 902 cannot satisfy both. However, if a LISP receiver multicast site acts 903 like a uLISP site then it could receive packets like a non-LISP 904 receiver multicast site making all receiver multicast sites have 905 homogeneous behavior. However, this poses the following issues: 907 o LISP-NAT techniques with routable addresses would be required in 908 all cases. 910 o Or alternatively, mPTR deployment would be required forcing coarse 911 EID prefix advertisement in the core. 913 o But what is most disturbing is that when all sites that 914 participate are LISP-Multicast sites but then a non-LISP or uLISP 915 site joins the distribution tree, then the existing joined LISP 916 receiver multicast sites would have to change their behavior. 917 This would create too much dynamic tree-building churn to be a 918 viable alternative. 920 So the solution space options are: 922 1. Make the LISP ITR in the source multicast site send two packets, 923 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 924 multicast sites and another that is not encapsulated with 925 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 927 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 928 reach LISP-Multicast sites and to reach mPTRs that can 929 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 930 receiver multicast sites. 932 9.2. LISP Sites with Mixed Address Families 934 A LISP database mapping entry that describes the locator-set, 935 Mpriority and Mweight per locator address (RLOC), for an EID prefix 936 associated with a site could have RLOC addresses in either IPv4 or 937 IPv6 format. When a mapping entry has a mix of RLOC formatted 938 addresses, it is an implicit advertisement by the site that it is a 939 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 940 packets. 942 To distinguish if the site can receive dual-stack unicast packets as 943 well as dual-stack multicast packets, the Mpriority value setting 944 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 945 details. 947 If you consider the combinations of LISP, non-LISP, and uLISP sites 948 sharing the same distribution tree and considering the capabilities 949 of supporting IPv4, IPv6, or dual-stack, the number of total 950 combinations grows beyond comprehension. 952 Using some combinatorial math, we have the following profiles of a 953 site and the combinations that can occur: 955 1. LISP-Multicast IPv4 Site 957 2. LISP-Multicast IPv6 Site 959 3. LISP-Multicast Dual-Stack Site 961 4. uLISP IPv4 Site 963 5. uLISP IPv6 Site 965 6. uLISP Dual-Stack Site 967 7. non-LISP IPv4 Site 969 8. non-LISP IPv6 Site 971 9. non-LISP Dual-Stack Site 973 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 974 illustrate some combinatorial math below. 976 When 1 site talks to another site, the combinatorial is (9 2), when 1 977 site talks to another 2 sites, the combinatorial is (9 3). If sum 978 this up to (9 9), we have: 980 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 982 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 984 Which results in the total number of cases to be considered at 502. 986 This combinatorial gets even worse when you consider a site using one 987 address family inside of the site and the xTRs use the other address 988 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 989 RLOCs). 991 To rationalize this combinatorial nightmare, there are some 992 guidelines which need to be put in place: 994 o Each distribution tree shared among sites will either be an IPv4 995 distribution tree or an IPv6 distribution tree. Therefore, we can 996 avoid head-end replication by building and sending packets on each 997 address family based distribution tree. Even though there might 998 be an urge to do multicast packet translation from one address 999 family format to the other, it is a non-viable over-complicated 1000 urge. 1002 o All LISP sites on a multicast distribution tree must share a 1003 common address family which is determined by the source site's 1004 locator-set in its LISP database mapping entry. All receiver 1005 multicast sites will use the best RLOC priority controlled by the 1006 source multicast site. This is true when the source site is 1007 either LISP-Multicast or uLISP capable. This means that priority- 1008 based policy modification is prohibited. 1010 o When the source site is not LISP capable, it is up to how 1011 receivers find the source and group information for a multicast 1012 flow. That mechanism decides the address family for the flow. 1014 9.3. Making a Multicast Interworking Decision 1016 This Multicast Interworking section has shown all combinations of 1017 multicast connectivity that could occur. As you might have already 1018 concluded, this can be quite complicated and if the design is too 1019 ambitious, the dynamics of the protocol could cause a lot of 1020 instability. 1022 The trade-off decisions are hard to make and we want the same single 1023 solution to work for both IPv4 and IPv6 multicast. It is imperative 1024 to have an incrementally deployable solution for all of IPv4 unicast 1025 and multicast and IPv6 unicast and multicast while minimizing (or 1026 eliminating) both unicast and multicast EID namespace state. 1028 Therefore the design decision to go with PTRs for unicast routing and 1029 mPTRs for multicast routing seems to be the sweet spot in the 1030 solution space so we can optimize state requirements and avoid head- 1031 end data replication at ITRs. 1033 10. Considerations when RP Addresses are Embedded in Group Addresses 1035 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1036 technique exists to embed the unicast address of an RP in a IPv6 1037 group address [RFC3956]. When routers in end sites process a PIM 1038 Join/Prune message which contain an embedded-RP group address, they 1039 extract the RP address from the group address and treat it from the 1040 EID namespace. However, core routers do not have state for the EID 1041 namespace, need to extract an RP address from the RLOC namespace. 1043 Therefore, it is the responsibility of ETRs in multicast receiver 1044 sites to map the group address into a group address where the 1045 embedded-RP address is from the RLOC namespace. The mapped RP- 1046 address is obtained from a EID-to-RLOC mapping database lookup. The 1047 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1048 the branch of the distribution tree from the source site resident RP 1049 to the ITR is created. 1051 This technique is no different than the techniques described in this 1052 specification for translating (S,G) state and propagating Join/Prune 1053 messages into the core. The only difference is that the (*,G) state 1054 in Join/Prune messages are mapped because they contain unicast 1055 addresses encoded in an Embedded-RP group address. 1057 11. Taking Advantage of Upgrades in the Core 1059 If the core routers are upgraded to support [RPFV] and [RFC5496], 1060 then we can pass EID specific data through the core without, 1061 possibly, having to store the state in the core. 1063 By doing this we can eliminate the ETR from unicast encapsulating PIM 1064 Join/Prune messages to the source site's ITR. 1066 However, this solution is restricted to a small set of workable cases 1067 which would not be good for general use of LISP-Multicast. In 1068 addition to slow convergence properties, it is not being recommended 1069 for LISP-Multicast. 1071 12. Mtrace Considerations 1073 Mtrace functionality must be consistent with unicast traceroute 1074 functionality where all hops from multicast receiver to multicast 1075 source are visible. 1077 The design for mtrace for use in LISP-Multicast environments is to be 1078 determined but should build upon the mtrace version 2 specified in 1079 [MTRACE]. 1081 13. Security Considerations 1083 Refer to the [LISP] specification. 1085 14. Acknowledgments 1087 The authors would like to gratefully acknowledge the people who have 1088 contributed discussion, ideas, and commentary to the making of this 1089 proposal and specification. People who provided expert review were 1090 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1091 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1092 Ijsbrand Wijnands. 1094 We would also like to thank the MBONED working group for constructive 1095 and civil verbal feedback when this draft was presented at the Fall 1096 2008 IETF in Minneapolis. In particular, good commentary came from 1097 Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, 1098 Ron Bonica, and Lenny Guardino. 1100 An expert review of this specification was done by Yiqun Cai and 1101 Liming Wei. We thank them for their detailed comments. 1103 This work originated in the Routing Research Group (RRG) of the IRTF. 1104 The individual submission [MLISP] was converted into this IETF LISP 1105 working group draft. 1107 15. References 1109 15.1. Normative References 1111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1112 Requirement Levels", BCP 14, RFC 2119, March 1997. 1114 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1115 Protocol (MSDP)", RFC 3618, October 2003. 1117 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1118 Point (RP) Address in an IPv6 Multicast Address", 1119 RFC 3956, November 2004. 1121 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1122 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1123 Protocol Specification (Revised)", RFC 4601, August 2006. 1125 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1126 Group Management Protocol Version 3 (IGMPv3) and Multicast 1127 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1128 Specific Multicast", RFC 4604, August 2006. 1130 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1131 IP", RFC 4607, August 2006. 1133 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1134 "Multiprotocol Extensions for BGP-4", RFC 4760, 1135 January 2007. 1137 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1138 "Bidirectional Protocol Independent Multicast (BIDIR- 1139 PIM)", RFC 5015, October 2007. 1141 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 1142 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 1144 15.2. Informative References 1146 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1147 Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in 1148 progress), May 2009. 1150 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1151 with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt 1152 (work in progress), May 2009. 1154 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1155 "Locator/ID Separation Protocol (LISP)", 1156 draft-ietf-lisp-01.txt (work in progress), May 2009. 1158 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1159 "LISP for Multicast Environments", 1160 draft-farinacci-lisp-multicast-01.txt (work in progress), 1161 November 2008. 1163 [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a 1164 Network Address (and port) Translator (NAT)", 1165 draft-ietf-behave-multicast-07.txt (work in progress), 1166 June 2007. 1168 [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace 1169 Version 2: Traceroute Facility for IP Multicast", 1170 draft-ietf-mboned-mtrace-v2-03.txt (work in progress), 1171 March 2009. 1173 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1174 TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), 1175 February 2008. 1177 Authors' Addresses 1179 Dino Farinacci 1180 cisco Systems 1181 Tasman Drive 1182 San Jose, CA 1183 USA 1185 Email: dino@cisco.com 1187 Dave Meyer 1188 cisco Systems 1189 Tasman Drive 1190 San Jose, CA 1191 USA 1193 Email: dmm@cisco.com 1195 John Zwiebel 1196 cisco Systems 1197 Tasman Drive 1198 San Jose, CA 1199 USA 1201 Email: jzwiebel@cisco.com 1203 Stig Venaas 1204 cisco Systems 1205 Tasman Drive 1206 San Jose, CA 1207 USA 1209 Email: stig@cisco.com