idnits 2.17.1 draft-ietf-lisp-multicast-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 1225 has weird spacing: '...ss (and port)...' -- The document date (June 20, 2011) is 4687 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-13 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-06 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-02 == 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: December 22, 2011 S. Venaas 6 cisco Systems 7 June 20, 2011 9 LISP for Multicast Environments 10 draft-ietf-lisp-multicast-06 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 to IETF 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), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 22, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 61 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 63 6. Locator Reachability Implications on LISP-Multicast . . . . . 14 64 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 65 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 66 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 67 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 68 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 69 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 70 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19 71 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 72 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 73 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 74 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 75 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 76 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 77 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 78 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 79 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 80 10. Considerations when RP Addresses are Embedded in Group 81 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 83 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 84 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 85 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 88 15.2. Informative References . . . . . . . . . . . . . . . . . . 33 89 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 90 A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 91 A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 92 A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 93 A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 94 A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 95 A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 96 A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 99 1. Requirements Notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 The Locator/ID Separation Architecture [LISP] provides a mechanism to 108 separate out Identification and Location semantics from the current 109 definition of an IP address. By creating two namespaces, an EID 110 namespace used by sites and a Locator (RLOC) namespace used by core 111 routing, the core routing infrastructure can scale by doing 112 topological aggregation of routing information. 114 Since LISP creates a new namespace, a mapping function must exist to 115 map a site's EID prefixes to its associated locators. For unicast 116 packets, both the source address and destination address must be 117 mapped. For multicast packets, only the source address needs to be 118 mapped. The destination group address doesn't need to be mapped 119 because the semantics of an IPv4 or IPv6 group address are logical in 120 nature and not topology-dependent. Therefore, this specifications 121 focuses on to map a source EID address of a multicast flow during 122 distribution tree setup and packet delivery. 124 This specification will address the following scenarios: 126 1. How a multicast source host in a LISP site sends multicast 127 packets to receivers inside of its site as well as to receivers 128 in other sites that are LISP enabled. 130 2. How inter-domain (or between LISP sites) multicast distribution 131 trees are built and how forwarding of multicast packets leaving a 132 source site toward receivers sites is performed. 134 3. What protocols are affected and what changes are required to such 135 multicast protocols. 137 4. How ASM-mode, SSM-mode, and Bidir-mode service models will 138 operate. 140 5. How multicast packet flow will occur for multiple combinations of 141 LISP and non-LISP capable source and receiver sites, for example: 143 A. How multicast packets from a source host in a LISP site are 144 sent to receivers in other sites when they are all non-LISP 145 sites. 147 B. How multicast packets from a source host in a LISP site are 148 sent to receivers in both LISP-enabled sites and non-LISP 149 sites. 151 C. How multicast packets from a source host in a non-LISP site 152 are sent to receivers in other sites when they are all LISP- 153 enabled sites. 155 D. How multicast packets from a source host in a non-LISP site 156 are sent to receivers in both LISP-enabled sites and non-LISP 157 sites. 159 This specification focuses on what changes are needed to the 160 multicast routing protocols to support LISP-Multicast as well as 161 other protocols used for inter-domain multicast, such as Multi- 162 protocol BGP (MBGP) [RFC4760]. The approach proposed in this 163 specification requires no changes to the multicast infrastructure 164 inside of a site when all sources and receivers reside in that site, 165 even when the site is LISP enabled. That is, internal operation of 166 multicast is unchanged regardless of whether or not the site is LISP 167 enabled or whether or not receivers exist in other sites which are 168 LISP-enabled. 170 Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], 171 and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not 172 run in an inter-domain environment is not addressed in depth in this 173 version of the specification. 175 Also, the current version of this specification does not describe 176 multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR 177 descriptions in [LISP]. 179 3. Definition of Terms 181 The terminology in this section is consistent with the definitions in 182 [LISP] but is extended specifically to deal with the application of 183 the terminology to multicast routing. 185 LISP-Multicast: a reference to the design in this specification. 186 That is, when any site that is participating in multicast 187 communication has been upgraded to be a LISP site, the operation 188 of control-plane and data-plane protocols is considered part of 189 the LISP-Multicast architecture. 191 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 192 used in the source address field of the first (most inner) LISP 193 header of a multicast packet. The host obtains a destination 194 group address the same way it obtains one today, as it would when 195 it is a non-LISP site. The source EID is obtained via existing 196 mechanisms used to set a host's "local" IP address. An EID is 197 allocated to a host from an EID prefix block associated with the 198 site the host is located in. An EID can be used by a host to 199 refer to another host, as when it joins an SSM (S-EID,G) route 200 using IGMP version 3 [RFC4604]. LISP uses Provider Independent 201 (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 202 Note that EID blocks may be assigned in a hierarchical manner, 203 independent of the network topology, to facilitate scaling of the 204 mapping database. In addition, an EID block assigned to a site 205 may have site-local structure (subnetting) for routing within the 206 site; this structure is not visible to the global routing system. 208 Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress 209 tunnel router (ITR), the router in the multicast source host's 210 site that encapsulates multicast packets. It is the output of a 211 EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. 212 Typically, RLOCs are numbered from topologically-aggregatable 213 blocks that are assigned to a site at each point to which it 214 attaches to the global Internet; where the topology is defined by 215 the connectivity of provider networks, RLOCs can be thought of as 216 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned 217 to the same ITR device or to multiple ITR devices at a site. 219 Ingress Tunnel Router (ITR): a router which accepts an IP multicast 220 packet with a single IP header (more precisely, an IP packet that 221 does not contain a LISP header). The router treats this "inner" 222 IP destination multicast address opaquely so it doesn't need to 223 perform a map lookup on the group address because it is 224 topologically insignificant. The router then prepends an "outer" 225 IP header with one of its globally-routable RLOCs as the source 226 address field. This RLOC is known to other multicast receiver 227 sites which have used the mapping database to join a multicast 228 tree for which the ITR is the root. In general, an ITR receives 229 IP packets from site end systems on one side and sends LISP- 230 encapsulated multicast IP packets out all external interfaces 231 which have been joined. 233 An ITR would receive a multicast packet from a source inside of 234 its site when 1) it is on the path from the multicast source to 235 internally joined receivers, or 2) when it is on the path from the 236 multicast source to externally joined receivers. 238 Egress Tunnel Router (ETR): a router that is on the path from a 239 multicast source host in another site to a multicast receiver in 240 its own site. An ETR accepts a PIM Join/Prune message from a site 241 internal PIM router destined for the source's EID in the multicast 242 source site. The ETR maps the source EID in the Join/Prune 243 message to an RLOC address based on the EID-to-RLOC mapping. This 244 sets up the ETR to accept multicast encapsulated packets from the 245 ITR in the source multicast site. A multicast ETR decapsulates 246 multicast encapsulated packets and replicates them on interfaces 247 leading to internal receivers. 249 xTR: is a reference to an ITR or ETR when direction of data flow is 250 not part of the context description. xTR refers to the router that 251 is the tunnel endpoint. Used synonymously with the term "Tunnel 252 Router". For example, "An xTR can be located at the Customer Edge 253 (CE) router", meaning both ITR and ETR functionality can be at the 254 CE router. 256 LISP Header: a term used in this document to refer to the outer 257 IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR 258 prepends headers and an ETR strips headers. A LISP encapsulated 259 multicast packet will have an "inner" header with the source EID 260 in the source field; an "outer" header with the source RLOC in the 261 source field: and the same globally unique group address in the 262 destination field of both the inner and outer header. 264 (S,G) State: the formal definition is in the PIM Sparse Mode 265 [RFC4601] specification. For this specification, the term is used 266 generally to refer to multicast state. Based on its topological 267 location, the (S,G) state resides in routers can be either 268 (S-EID,G) state (at a location where the (S,G) state resides) or 269 (S-RLOC,G) state (in the Internet core). 271 (S-EID,G) State: refers to multicast state in multicast source and 272 receiver sites where S-EID is the IP address of the multicast 273 source host (its EID). An S-EID can appear in an IGMPv3 report, 274 an MSDP SA message or a PIM Join/Prune message that travels inside 275 of a site. 277 (S-RLOC,G) State: refers to multicast state in the core where S is 278 a source locator (the IP address of a multicast ITR) of a site 279 with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) 280 entry by doing a mapping database lookup for the EID prefix that 281 S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message 282 when it travels from an ETR to an ITR over the Internet core. 284 uLISP Site: a unicast only LISP site according to [LISP] which has 285 not deployed the procedures of this specification and therefore, 286 for multicast purposes, follows the procedures from Section 9. 288 mPETR: this is a multicast proxy-ETR that is responsible for 289 advertising a very coarse EID prefix which non-LISP and uLISP 290 sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs 291 are used so LISP source multicast sites can send multicast packets 292 using source addresses from the EID namespace. mPETRs act as Proxy 293 ETRs for supporting multicast routing in a LISP infrastructure. 294 It is likely an uPITR [INTWORK] and a mPETR will be co-located 295 since the single device advertises a coarse EID-prefix in the 296 underlying unicast routing system. 298 Mixed Locator-Sets: this is a locator-set for a LISP database 299 mapping entry where the RLOC addresses in the locator-set are in 300 both IPv4 and IPv6 format. 302 Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM 303 Join/Prune message (encapsulated in a LISP Encapsulated Control 304 Message with destination UDP port 4342) which is sent by ETRs at 305 multicast receiver sites to an ITR at a multicast source site. 306 This message is sent periodically as long as there are interfaces 307 in the oif-list for the (S-EID,G) entry the ETR is joining for. 309 4. Basic Overview 311 LISP, when used for unicast routing, increases the site's ability to 312 control ingress traffic flows. Egress traffic flows are controlled 313 by the IGP in the source site. For multicast, the IGP coupled with 314 PIM can decide which path multicast packets ingress. By using the 315 traffic engineering features of LISP, a multicast source site can 316 control the egress of its multicast traffic. By controlling the 317 priorities of locators from a mapping database entry, a source 318 multicast site can control which way multicast receiver sites join to 319 the source site. 321 At this point in time, we don't see a requirement for different 322 locator-sets, priority, and weight policies for multicast than we 323 have for unicast. However, when traffic engineering policies are 324 different for unicast versus multicast flows, it will be desirable to 325 use multicast-based priority and weight values in Map-Reply messages. 327 The fundamental multicast forwarding model is to encapsulate a 328 multicast packet into another multicast packet. An ITR will 329 encapsulate multicast packets received from sources that it serves in 330 another LISP multicast header. The destination group address from 331 the inner header is copied to the destination address of the outer 332 header. The inner source address is the EID of the multicast source 333 host and the outer source address is the RLOC of the encapsulating 334 ITR. 336 The LISP-Multicast architecture will follow this high-level protocol 337 and operational sequence: 339 1. Receiver hosts in multicast sites will join multicast content the 340 way they do today, they use IGMP. When they use IGMPv3 where 341 they specify source addresses, they use source EIDs, that is they 342 join (S-EID,G). If the multicast source is external to this 343 receiver site, the PIM Join/Prune message flows toward the ETRs, 344 finding the shortest exit (that is the closest exit for the Join/ 345 Prune message and the closest entrance for the multicast packet 346 to the receiver). 348 2. The ETR does a mapping database lookup for S-EID. If the mapping 349 is cached from a previous lookup (from either a previous Join/ 350 Prune for the source multicast site or a unicast packet that went 351 to the site), it will use the RLOC information from the mapping. 352 The ETR will use the same priority and weighting mechanism as for 353 unicast. So the source site can decide which way multicast 354 packets egress. 356 3. The ETR will build two PIM Join/Prune messages, one that contains 357 a (S-EID,G) entry that is unicast to the ITR that matches the 358 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 359 entry so the core network can create multicast state from this 360 ETR to the ITR. 362 4. When the ITR gets the unicast Join/Prune message (see Section 3 363 for formal definition), it will process (S-EID,G) entries in the 364 message and propagate them inside of the site where it has 365 explicit routing information for EIDs via the IGP. When the ITR 366 receives the (S-RLOC,G) PIM Join/Prune message it will process it 367 like any other join it would get in today's Internet. The S-RLOC 368 address is the IP address of this ITR. 370 5. At this point there is (S-EID,G) state from the joining host in 371 the receiver multicast site to the ETR of the receiver multicast 372 site. There is (S-RLOC,G) state across the core network from the 373 ETR of the multicast receiver site to the ITR in the multicast 374 source site and (S-EID,G) state in the source multicast site. 375 Note, the (S-EID,G) state is the same S-EID in each multicast 376 site. As other ETRs join the same multicast tree, they can join 377 through the same ITR (in which case the packet replication is 378 done in the core) or a different ITR (in which case the packet 379 replication is done at the source site). 381 6. When a packet is originated by the multicast host in the source 382 site, it will flow to one or more ITRs which will prepend a LISP 383 header by copying the group address to the outer destination 384 address field and insert its own locator address in the outer 385 source address field. The ITR will look at its (S-RLOC,G) state, 386 where S-RLOC is its own locator address, and replicate the packet 387 on each interface a (S-RLOC,G) joined was received on. The core 388 has (S-RLOC,G) so where fanout occurs to multiple sites, a core 389 router will do packet replication. 391 7. When either the source site or the core replicates the packet, 392 the ETR will receive a LISP packet with a destination group 393 address. It will decapsulate packets because it has receivers 394 for the group. Otherwise, it would have not received the packets 395 because it would not have joined. The ETR decapsulates and does 396 a (S-EID,G) lookup in its multicast FIB to forward packets out 397 one or more interfaces to forward the packet to internal 398 receivers. 400 This architecture is consistent and scalable with the architecture 401 presented in [LISP] where multicast state in the core operates on 402 locators and multicast state at the sites operates on EIDs. 404 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can 405 reside in the core through the use of RPF-vectors [RPFV] in PIM Join/ 406 Prune messages. However, few PIM implementations support RPF vectors 407 and LISP should avoid S-EID state in the core. See Section 5 for 408 details. 410 However, we have some observations on the algorithm above. We can 411 scale the control plane but at the expense of sending data to sites 412 which may have not joined the distribution tree where the 413 encapsulated data is being delivered. For example, one site joins 414 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 415 same multicast source site. Both multicast receiver sites join to 416 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 417 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 418 site. The ITR receives (S-RLOC,G) joins and populates the oif-list 419 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 420 (S-RLOC,G) packets will be delivered by the core to both multicast 421 receiver sites even though each have joined a single source-based 422 distribution tree. This behavior is a consequence of the many-to-one 423 mapping between S-EIDs and a S-RLOC. 425 There is a possible solution to this problem which reduces the number 426 of many-to-one occurrences of (S-EID,G) entries aggregating into a 427 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 428 RLOC addresses and these addresses are advertised in mapping database 429 entries, then ETRs at receiver sites have more RLOC address options 430 and therefore can join different (RLOC,G) entries for each (S-EID,G) 431 entry joined at the receiver site. It would not scale to have a one- 432 to-one relationship between the number of S-EID sources at a source 433 site and the number of RLOCs assigned to all ITRs at the site, but we 434 can reduce the "n" to a smaller number in the "n-to-1" relationship. 435 And in turn, reduce the opportunity for data packets to be delivered 436 to sites for groups not joined. 438 5. Source Addresses versus Group Addresses 440 Multicast group addresses don't have to be associated with either the 441 EID or RLOC namespace. They actually are a namespace of their own 442 that can be treated as logical with relatively opaque allocation. 443 So, by their nature, they don't detract from an incremental 444 deployment of LISP-Multicast. 446 As for source addresses, as in the unicast LISP scenario, there is a 447 decoupling of identification from location. In a LISP site, packets 448 are originated from hosts using their allocated EIDs, those addresses 449 are used to identify the host as well as where in the site's topology 450 the host resides but not how and where it is attached to the 451 Internet. 453 Therefore, when multicast distribution tree state is created anywhere 454 in the network on the path from any multicast receiver to a multicast 455 source, EID state is maintained at the source and receiver multicast 456 sites, and RLOC state is maintained in the core. That is, a 457 multicast distribution tree will be represented as a 3-tuple of 458 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 459 3-tuple is the state stored in routers from the source to one or more 460 ITRs in the source multicast site, the second element of the 3-tuple 461 is the state stored in routers downstream of the ITR, in the core, to 462 all LISP receiver multicast sites, and the third element in the 463 3-tuple is the state stored in the routers downstream of each ETR, in 464 each receiver multicast site, reaching each receiver. Note that 465 (S-EID,G) is the same in both the source and receiver multicast 466 sites. 468 The concatenation/mapping from the first element to the second 469 element of the 3-tuples is done by the ITR and from the second 470 element to the third element is done at the ETRs. 472 6. Locator Reachability Implications on LISP-Multicast 474 Multicast state as it is stored in the core is always (S,G) state as 475 it exists today or (S-RLOC,G) state as it will exist when LISP sites 476 are deployed. The core routers cannot distinguish one from the 477 other. They don't need to because it is state that RPFs against the 478 core routing tables in the RLOC namespace. The difference is where 479 the root of the distribution tree for a particular source is. In the 480 traditional multicast core, the source S is the source host's IP 481 address. For LISP-Multicast the source S is a single ITR of the 482 multicast source site. 484 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 485 ETR propagates a PIM Join/Prune message out of a receiver multicast 486 site. The selection is based on the same algorithm an ITR would use 487 to select an ETR when sending a unicast packet to the site. In the 488 unicast case, the ITR can change on a per-packet basis depending on 489 the reachability of the ETR. So an ITR can change relatively easily 490 using local reachability state. However, in the multicast case, when 491 an ITR goes unreachable, new distribution tree state must be built 492 because the encapsulating root has changed. This is more significant 493 than an RPF-change event, where any router would typically locally 494 change its RPF-interface for its existing tree state. But when an 495 encapsulating LISP-Multicast ITR goes unreachable, new distribution 496 state must be rebuilt and reflect the new encapsulator. Therefore, 497 when an ITR goes unreachable, all ETRs that are currently joined to 498 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 499 to the new ITR as well as send a unicast encapsulated Join/Prune 500 message telling the new ITR which (S-EID,G) is being joined. 502 This issue can be mitigated by using anycast addressing for the ITRs 503 so the problem does reduce to an RPF change in the core, but still 504 requires a unicast encapsulated Join/Prune message to tell the new 505 ITR about (S-EID,G). The problem with this approach is that the ETR 506 really doesn't know when the ITR has changed so the new anycast ITR 507 will get the (S-EID,G) state only when the ETR sends it the next time 508 during its periodic sending procedures. 510 7. Multicast Protocol Changes 512 A number of protocols are used today for inter-domain multicast 513 routing: 515 IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for 516 LISP-Multicast for two reasons. One being that they are link- 517 local and not used over site boundaries and second they advertise 518 group addresses that don't need translation. Where source 519 addresses are supplied in IGMPv3 and MLDv2 messages, they are 520 semantically regarded as EIDs and don't need to be converted to 521 RLOCs until the multicast tree-building protocol, such as PIM, is 522 received by the ETR at the site boundary. Addresses used for IGMP 523 and MLD come out of the source site's allocated addresses which 524 are therefore from the EID namespace. 526 MBGP: Even though MBGP is not a multicast routing protocol, it is 527 used to find multicast sources when the unicast BGP peering 528 topology and the multicast MBGP peering topology are not 529 congruent. When MBGP is used in a LISP-Multicast environment, the 530 prefixes which are advertised are from the RLOC namespace. This 531 allows receiver multicast sites to find a path to the source 532 multicast site's ITRs. MBGP peering addresses will be from the 533 RLOC namespace. 535 MSDP: MSDP is used to announce active multicast sources to other 536 routing domains (or LISP sites). The announcements come from the 537 PIM Rendezvous Points (RPs) from sites where there are active 538 multicast sources sending to various groups. In the context of 539 LISP-Multicast, the source addresses advertised in MSDP will 540 semantically be from the EID namespace since they describe the 541 identity of a source multicast host. It will be true that the 542 state stored in MSDP caches from core routers will be from the EID 543 namespace. An RP address inside of site will be from the EID 544 namespace so it can be advertised and reached by internal unicast 545 routing mechanism. However, for MSDP peer-RPF checking to work 546 properly across sites, the RP addresses must be converted or 547 mapped into a routable address that is advertised and maintained 548 in the BGP routing tables in the core. MSDP peering addresses can 549 come out of either the EID or a routable address namespace. And 550 the choice can be made unilaterally because the ITR at the site 551 will determine which namespace the destination peer address is out 552 of by looking in the mapping database service. 554 PIM-SSM: In the simplest form of distribution tree building, when 555 PIM operates in SSM mode, a source distribution tree is built and 556 maintained across site boundaries. In this case, there is a small 557 modification to the operation of the PIM protocol (but not to any 558 message format) to support taking a Join/Prune message originated 559 inside of a LISP site with embedded addresses from the EID 560 namespace and converting them to addresses from the RLOC namespace 561 when the Join/Prune message crosses a site boundary. This is 562 similar to the requirements documented in [MNAT]. 564 PIM-Bidir: Bidirectional PIM is typically run inside of a routing 565 domain, but if deployed in an inter-domain environment, one would 566 have to decide if the RP address of the shared-tree would be from 567 the EID namespace or the RLOC namespace. If the RP resides in a 568 site-based router, then the RP address is from the EID namespace. 569 If the RP resides in the core where RLOC addresses are routed, 570 then the RP address is from the RLOC namespace. This could be 571 easily distinguishable if the EID address were well-known address 572 allocation block from the RLOC namespace. Also, when using 573 Embedded-RP for RP determination [RFC3956], the format of the 574 group address could indicate the namespace the RP address is from. 575 However, refer to Section 10 for considerations core routers need 576 to make when using Embedded-RP IPv6 group addresses. When using 577 Bidir-PIM for inter-domain multicast routing, it is recommended to 578 use staticly configured RPs so core routers think the Bidir group 579 is associated with an ITR's RLOC as the RP address and site 580 routers think the Bidir group is associated with the site resident 581 RP with an EID address. With respect to DF-election in Bidir PIM, 582 no changes are required since all messaging and addressing is 583 link-local. 585 PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is 586 deployed in the Internet today is by having shared-trees within a 587 site and using source-trees across sites. By the use of MSDP and 588 PIM-SSM techniques described above, we can get multicast 589 connectivity across LISP sites. Having said that, that means 590 there are no special actions required for processing (*,G) or 591 (S,G,R) Join/Prune messages since they all operate against the 592 shared-tree which is site resident. Just like with ASM, there is 593 no (*,G) in the core when LISP-Multicast is in use. This is also 594 true for the RP-mapping mechanisms Auto-RP and BSR. 596 Based on the protocol description above, the conclusion is that there 597 are no protocol message format changes, just a translation function 598 performed at the control-plane. This will make for an easier and 599 faster transition for LISP since fewer components in the network have 600 to change. 602 It should also be stated just like it is in [LISP] that no host 603 changes, whatsoever, are required to have a multicast source host 604 send multicast packets and for a multicast receiver host to receive 605 multicast packets. 607 8. LISP-Multicast Data-Plane Architecture 609 The LISP-Multicast data-plane operation conforms to the operation and 610 packet formats specified in [LISP]. However, encapsulating a 611 multicast packet from an ITR is a much simpler process. The process 612 is simply to copy the inner group address to the outer destination 613 address. And to have the ITR use its own IP address (its RLOC), and 614 as the source address. The process is simpler for multicast because 615 there is no EID-to-RLOC mapping lookup performed during packet 616 forwarding. 618 In the decapsulation case, the ETR simply removes the outer header 619 and performs a multicast routing table lookup on the inner header 620 (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is 621 used to replicate the packet on site-facing interfaces leading to 622 multicast receiver hosts. 624 There is no Data-Probe logic for ETRs as there can be in the unicast 625 forwarding case. 627 8.1. ITR Forwarding Procedure 629 The following procedure is used by an ITR, when it receives a 630 multicast packet from a source inside of its site: 632 1. A multicast data packet sent by a host in a LISP site will have 633 the source address equal to the host's EID and the destination 634 address equal to the group address of the multicast group. It is 635 assumed the group information is obtained by current methods. 636 The same is true for a multicast receiver to obtain the source 637 and group address of a multicast flow. 639 2. When the ITR receives a multicast packet, it will have both S-EID 640 state and S-RLOC state stored. Since the packet was received on 641 a site-facing interface, the RPF lookup is based on the S-EID 642 state. If the RPF check succeeds, then the oif-list contains 643 interfaces that are site-facing and external-facing. For the 644 site-facing interfaces, no LISP header is prepended. For the 645 external-facing interfaces a LISP header is prepended. When the 646 ITR prepends a LISP header, it uses its own RLOC address as the 647 source address and copies the group address supplied by the IP 648 header the host built as the outer destination address. 650 8.1.1. Multiple RLOCs for an ITR 652 Typically, an ITR will have a single RLOC address but in some cases 653 there could be multiple RLOC addresses assigned from either the same 654 or different service providers. In this case when (S-RLOC,G) Join/ 655 Prune messages are received for each RLOC, there is a oif-list 656 merging action that must take place. Therefore, when a packet is 657 received from a site-facing interface that matches on a (S-EID,G) 658 entry, the interfaces of the oif-list from all (RLOC,G) entries 659 joined to the ITR as well as the site-facing oif-list joined for 660 (S-EID,G) must be part be included in packet replication. In 661 addition to replicating for all types of oif-lists, each oif entry 662 must be tagged with the RLOC address, so encapsulation uses the outer 663 source address for the RLOC joined. 665 8.1.2. Multiple ITRs for a LISP Source Site 667 Note when ETRs from different multicast receiver sites receive 668 (S-EID,G) joins, they may select a different S-RLOC for a multicast 669 source site due to policy (the multicast ITR can return different 670 multicast priority and weight values per ETR Map-Request). In this 671 case, the same (S-EID,G) is being realized by different (S-RLOC,G) 672 state in the core. This will not result in duplicate packets because 673 each ITR in the multicast source site will choose their own RLOC for 674 the source address for encapsulated multicast traffic. The RLOC 675 addresses are the ones joined by remote multicast ETRs. 677 When different (S-EID,G) traffic is combined into a single (RLOC,G) 678 core distribution tree, this may cause traffic to go to a receiver 679 multicast site when it does not need to. This happens when one 680 receiver multicast site joins (S1-EID,Gi) through a core distribution 681 tree of (RLOC1,Gi) and another multicast receiver site joins (S2- 682 EID,Gi) through the same core distribution tree of (RLOC1,Gi). When 683 ETRs decapsulate such traffic, they should know from their local 684 (S-EID,G) state if the packet should be forwarded. If there is no 685 (S-EID,G) state that matches the inner packet header, the packet is 686 discarded. 688 8.2. ETR Forwarding Procedure 690 The following procedure is used by an ETR, when it receives a 691 multicast packet from a source outside of its site: 693 1. When a multicast data packet is received by an ETR on an 694 external-facing interface, it will do an RPF lookup on the S-RLOC 695 state it has stored. If the RPF check succeeds, the interfaces 696 from the oif-list are used for replication to interfaces that are 697 site-facing as well as interfaces that are external-facing (this 698 ETR can also be a transit multicast router for receivers outside 699 of its site). When the packet is to be replicated for an 700 external-facing interface, the LISP encapsulation header are not 701 stripped. When the packet is replicated for a site-facing 702 interface, the encapsulation header is stripped. 704 2. The packet without a LISP header is now forwarded down the 705 (S-EID,G) distribution tree in the receiver multicast site. 707 8.3. Replication Locations 709 Multicast packet replication can happen in the following topological 710 locations: 712 o In an IGP multicast router inside a site which operates on S-EIDs. 714 o In a transit multicast router inside of the core which operates on 715 S-RLOCs. 717 o At one or more ETR routers depending on the path a Join/Prune 718 message exits a receiver multicast site. 720 o At one or more ITR routers in a source multicast site depending on 721 what priorities are returned in a Map-Reply to receiver multicast 722 sites. 724 In the last case the source multicast site can do replication rather 725 than having a single exit from the site. But this only can occur 726 when the priorities in the Map-Reply are modified for different 727 receiver multicast site so that the PIM Join/Prune messages arrive at 728 different ITRs. 730 This policy technique, also used in [ALT] for unicast, is useful for 731 multicast to mitigate the problems of changing distribution tree 732 state as discussed in Section 6. 734 9. LISP-Multicast Interworking 736 This section will describe the multicast corollary to [INTWORK] which 737 describes the interworking of multicast routing among LISP and non- 738 LISP sites. 740 9.1. LISP and non-LISP Mixed Sites 742 Since multicast communication can involve more than two entities to 743 communicate together, the combinations of interworking scenarios are 744 more involved. However, the state maintained for distribution trees 745 at the sites is the same regardless of whether or not the site is 746 LISP enabled or not. So most of the implications are in the core 747 with respect to storing routable EID prefixes from either PA or PI 748 blocks. 750 Before we enumerate the multicast interworking scenarios, we must 751 define 3 deployment states of a site: 753 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 754 does today. The addresses for the site are globally routable. 756 o A site that deploys LISP for unicast routing. The addresses for 757 the site are not globally routable. Let's define the name for 758 this type of site as a uLISP site. 760 o A site that deploys LISP for both unicast and multicast routing. 761 The addresses for the site are not globally routable. Let's 762 define the name for this type of site as a LISP-Multicast site. 764 We will not consider a LISP site enabled for multicast purposes only 765 but do consider a uLISP site as documented in [INTWORK]. In this 766 section we don't discuss how a LISP site sends multicast packets when 767 all receiver sites are LISP-Multicast enabled; that has been 768 discussed in previous sections. 770 The following scenarios exist to make LISP-Multicast sites interwork 771 with non-LISP-Multicast sites: 773 1. A LISP site must be able to send multicast packets to receiver 774 sites which are a mix of non-LISP sites and uLISP sites. 776 2. A non-LISP site must be able to send multicast packets to 777 receiver sites which are a mix of non-LISP sites and uLISP sites. 779 3. A non-LISP site must be able to send multicast packets to 780 receiver sites which are a mix of LISP sites, uLISP sites, and 781 non-LISP sites. 783 4. A uLISP site must be able to send multicast packets to receiver 784 sites which are a mix of LISP sites, uLISP sites, and non-LISP 785 sites. 787 5. A LISP site must be able to send multicast packets to receiver 788 sites which are a mix of LISP sites, uLISP sites, and non-LISP 789 sites. 791 9.1.1. LISP Source Site to non-LISP Receiver Sites 793 In the first scenario, a site is LISP capable for both unicast and 794 multicast traffic and as such operates on EIDs. Therefore there is a 795 possibility that the EID prefix block is not routable in the core. 796 For LISP receiver multicast sites this isn't a problem but for non- 797 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 798 is received by the edge router, it has no route to propagate the 799 Join/Prune message out of the site. This is no different than the 800 unicast case that LISP-NAT in [INTWORK] solves. 802 LISP-NAT allows a unicast packet that exits a LISP site to get its 803 source address mapped to a globally routable address before the ITR 804 realizes that it should not encapsulate the packet destined to a non- 805 LISP site. For a multicast packet to leave a LISP site, distribution 806 tree state needs to be built so the ITR can know where to send the 807 packet. So the receiver multicast sites need to know about the 808 multicast source host by its routable address and not its EID 809 address. When this is the case, the routable address is the 810 (S-RLOC,G) state that is stored and maintained in the core routers. 811 It is important to note that the routable address for the host cannot 812 be the same as an RLOC for the site because we want the ITRs to 813 process a received PIM Join/Prune message from an external-facing 814 interface to be propagated inside of the site so the site-part of the 815 distribution tree is built. 817 Using a globally routable source address allows non-LISP and uLISP 818 multicast receiver to join, create, and maintain a multicast 819 distribution tree. However, the LISP multicast receiver site will 820 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 821 Prune message is received on a site-facing interface. It does this 822 because it wants to find a (S-RLOC,G) entry to Join in the core. So 823 we have a conflict of behavior between the two types of sites. 825 The solution to this problem is the same as when an ITR wants to send 826 a unicast packet to a destination site but needs determine if the 827 site is LISP capable or not. When it is not LISP capable, the ITR 828 does not encapsulate the packet. So for the multicast case, when ETR 829 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 830 mapping table lookup on S-EID. In this case, S-EID is not in the 831 mapping database because the source multicast site is using a 832 routable address and not an EID prefix address. So the ETR knows to 833 simply propagate the PIM Join/Prune message to a external-facing 834 interface without converting the (S-EID,G) because it is an (S,G) 835 where S is routable and reachable via core routing tables. 837 Now that the multicast distribution tree is built and maintained from 838 any non-LISP or uLISP receiver multicast site, the way packet 839 forwarding model is performed can be explained. 841 Since the ITR in the source multicast site has never received a 842 unicast encapsulated PIM Join/Prune message from any ETR in a 843 receiver multicast site, it knows there are no LISP-Multicast 844 receiver sites. Therefore, there is no need for the ITR to 845 encapsulate data. Since it will know a priori (via configuration) 846 that its site's EIDs are not routable (and not registered to the 847 mapping database system), it assumes that the multicast packets from 848 the source host are sent by a routable address. That is, it is the 849 responsibility of the multicast source host's system administrator to 850 ensure that the source host sends multicast traffic using a routable 851 source address. When this happens, the ITR acts simply as a router 852 and forwards the multicast packet like an ordinary multicast router. 854 There is an alternative to using a LISP-NAT scheme just like there is 855 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 856 (PxTRs). This can work the same way for multicast routing as well, 857 but the difference is that non-LISP and uLISP sites will send PIM 858 Join/Prune messages for (S-EID,G) which make their way in the core to 859 multicast PxTRs. Let's call this use of a PxTR as a "Multicast 860 Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID 861 prefixes, they draw the PIM Join/Prune control traffic making them 862 the target of the distribution tree. To get multicast packets from 863 the LISP source multicast sites, the tree needs to be built on the 864 path from the mPETR to the LISP source multicast site. To make this 865 happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a 866 "Proxy ITR", or an uPITR [INTWORK]). 868 The existence of mPETRs in the core allows source multicast site ITRs 869 to encapsulate multicast packets according to (S-RLOC,G) state. The 870 (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The 871 encapsulated multicast packets are decapsulated by mPETRs and then 872 forwarded according to (S-EID,G) state. The (S-EID,G) state is built 873 from the non-LISP and uLISP receiver multicast sites to the mPETRs. 875 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 877 Clearly non-LISP multicast sites can send multicast packets to non- 878 LISP receiver multicast sites. That is what they do today. However, 879 discussion is required to show how non-LISP multicast sites send 880 multicast packets to uLISP receiver multicast sites. 882 Since uLISP receiver multicast sites are not targets of any (S,G) 883 state, they simply send (S,G) PIM Join/Prune messages toward the non- 884 LISP source multicast site. Since the source multicast site, in this 885 case has not been upgraded to LISP, all multicast source host 886 addresses are routable. So this case is simplified to where a uLISP 887 receiver multicast site looks to the source multicast site as a non- 888 LISP receiver multicast site. 890 9.1.3. Non-LISP Source Site to Any Receiver Site 892 When a non-LISP source multicast site has receivers in either a non- 893 LISP/uLISP site or a LISP site, one needs to decide how the LISP 894 receiver multicast site will attach to the distribution tree. We 895 know from Section 9.1.2 that non-LISP and uLISP receiver multicast 896 sites can join the distribution tree, but a LISP receiver multicast 897 site ETR will need to know if the source address of the multicast 898 source host is routable or not. We showed in Section 9.1.1 that an 899 ETR, before it sends a PIM Join/Prune message on an external-facing 900 interface, does a EID-to-RLOC mapping lookup to determine if it 901 should convert the (S,G) state from a PIM Join/Prune message received 902 on a site-facing interface to a (S-RLOC,G). If the lookup fails, the 903 ETR can conclude the source multicast site is a non-LISP site so it 904 simply forwards the Join/Prune message (it also doesn't need to send 905 a unicast encapsulated Join/Prune message because there is no ITR in 906 a non-LISP site and there is namespace continuity between the ETR and 907 source). 909 For a non-LISP source multicast site, (S-EID,G) state could be 910 limited to the edges of the network with the use of multicast proxy- 911 ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast 912 packets from non-LISP source multicast and uLISP sites and 913 encapsulate them to ETRs in receiver multicast sites or to mPETRs 914 that can decapsulate for non-LISP receiver multicast or uLISP sites. 915 The mPITRs are responsible for sending (S-EID,G) joins to the non- 916 LISP source multicast site. To connect the distribution trees 917 together, multicast ETRs will need to be configured with the mPITR's 918 RLOC addresses so they can send both (S-RLOC,G) joins to build a 919 distribution tree to the mPITR as well as for sending unicast joins 920 to mPITRs so they can propogate (S-EID,G) joins into source multicast 921 sites. The use of mPITRs is undergoing more study and is work in 922 progress. 924 9.1.4. Unicast LISP Source Site to Any Receiver Sites 926 In the last section, it was explained how an ETR in a multicast 927 receiver site can determine if a source multicast site is LISP- 928 enabled by looking into the mapping database. When the source 929 multicast site is a uLISP site, it is LISP enabled but the ITR, by 930 definition is not capable of doing multicast encapsulation. So for 931 the purposes of multicast routing, the uLISP source multicast site is 932 treated as non-LISP source multicast site. 934 Non-LISP receiver multicast sites can join distribution trees to a 935 uLISP source multicast site since the source site behaves, from a 936 forwarding perspective, as a non-LISP source site. This is also the 937 case for a uLISP receiver multicast site since the ETR does not have 938 multicast functionality built-in or enabled. 940 Special considerations are required for LISP receiver multicast sites 941 since they think the source multicast site is LISP capable, the ETR 942 cannot know if ITR is LISP-Multicast capable. To solve this problem, 943 each mapping database entry will have a multicast 2-tuple (Mpriority, 944 Mweight) per RLOC. When the Mpriority is set to 255, the site is 945 considered not multicast capable. So an ETR in a LISP receiver 946 multicast site can distinguish whether a LISP source multicast site 947 is LISP-Multicast site from a uLISP site. 949 9.1.5. LISP Source Site to Any Receiver Sites 951 When a LISP source multicast site has receivers in LISP, non-LISP, 952 and uLISP receiver multicast sites, it has a conflict about how it 953 sends multicast packets. The ITR can either encapsulate or natively 954 forward multicast packets. Since the receiver multicast sites are 955 heterogeneous in their behavior, one packet forwarding mechanism 956 cannot satisfy both. However, if a LISP receiver multicast site acts 957 like a uLISP site then it could receive packets like a non-LISP 958 receiver multicast site making all receiver multicast sites have 959 homogeneous behavior. However, this poses the following issues: 961 o LISP-NAT techniques with routable addresses would be required in 962 all cases. 964 o Or alternatively, mPETR deployment would be required forcing 965 coarse EID prefix advertisement in the core. 967 o But what is most disturbing is that when all sites that 968 participate are LISP-Multicast sites but then a non-LISP or uLISP 969 site joins the distribution tree, then the existing joined LISP 970 receiver multicast sites would have to change their behavior. 971 This would create too much dynamic tree-building churn to be a 972 viable alternative. 974 So the solution space options are: 976 1. Make the LISP ITR in the source multicast site send two packets, 977 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 978 multicast sites and another that is not encapsulated with 979 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 981 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 982 reach LISP-Multicast sites and to reach mPETRs that can 983 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 984 receiver multicast sites. 986 9.2. LISP Sites with Mixed Address Families 988 A LISP database mapping entry that describes the locator-set, 989 Mpriority and Mweight per locator address (RLOC), for an EID prefix 990 associated with a site could have RLOC addresses in either IPv4 or 991 IPv6 format. When a mapping entry has a mix of RLOC formatted 992 addresses, it is an implicit advertisement by the site that it is a 993 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 994 packets. 996 To distinguish if the site can receive dual-stack unicast packets as 997 well as dual-stack multicast packets, the Mpriority value setting 998 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 999 details. 1001 If you consider the combinations of LISP, non-LISP, and uLISP sites 1002 sharing the same distribution tree and considering the capabilities 1003 of supporting IPv4, IPv6, or dual-stack, the number of total 1004 combinations grows beyond comprehension. 1006 Using some combinatorial math, we have the following profiles of a 1007 site and the combinations that can occur: 1009 1. LISP-Multicast IPv4 Site 1011 2. LISP-Multicast IPv6 Site 1013 3. LISP-Multicast Dual-Stack Site 1015 4. uLISP IPv4 Site 1017 5. uLISP IPv6 Site 1018 6. uLISP Dual-Stack Site 1020 7. non-LISP IPv4 Site 1022 8. non-LISP IPv6 Site 1024 9. non-LISP Dual-Stack Site 1026 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 1027 illustrate some combinatorial math below. 1029 When 1 site talks to another site, the combinatorial is (9 2), when 1 1030 site talks to another 2 sites, the combinatorial is (9 3). If sum 1031 this up to (9 9), we have: 1033 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 1035 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 1037 Which results in the total number of cases to be considered at 502. 1039 This combinatorial gets even worse when you consider a site using one 1040 address family inside of the site and the xTRs use the other address 1041 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 1042 RLOCs). 1044 To rationalize this combinatorial nightmare, there are some 1045 guidelines which need to be put in place: 1047 o Each distribution tree shared between sites will either be an IPv4 1048 distribution tree or an IPv6 distribution tree. Therefore, we can 1049 avoid head-end replication by building and sending packets on each 1050 address family based distribution tree. Even though there might 1051 be an urge to do multicast packet translation from one address 1052 family format to the other, it is a non-viable over-complicated 1053 urge. Multicast ITRs will only encapsulate packets where the 1054 inner and outer headers are from the same address family. 1056 o All LISP sites on a multicast distribution tree must share a 1057 common address family which is determined by the source site's 1058 locator-set in its LISP database mapping entry. All receiver 1059 multicast sites will use the best RLOC priority controlled by the 1060 source multicast site. This is true when the source site is 1061 either LISP-Multicast or uLISP capable. This means that priority- 1062 based policy modification is prohibited. When a receiver 1063 multicast site ETR receives a (S-EID,G) join, it must select a 1064 S-RLOC for the same address family as S-EID. 1066 o A mixed multicast locator-set with the best multicast priority 1067 values MUST NOT be configured on multicast ITRs. A mixed locator- 1068 set can exist (for unicast use), but the multicast priorities MUST 1069 be the set for the same address family locators. 1071 o When the source site is not LISP capable, it is up to how 1072 receivers find the source and group information for a multicast 1073 flow. That mechanism decides the address family for the flow. 1075 9.3. Making a Multicast Interworking Decision 1077 This Multicast Interworking section has shown all combinations of 1078 multicast connectivity that could occur. As you might have already 1079 concluded, this can be quite complicated and if the design is too 1080 ambitious, the dynamics of the protocol could cause a lot of 1081 instability. 1083 The trade-off decisions are hard to make and we want the same single 1084 solution to work for both IPv4 and IPv6 multicast. It is imperative 1085 to have an incrementally deployable solution for all of IPv4 unicast 1086 and multicast and IPv6 unicast and multicast while minimizing (or 1087 eliminating) both unicast and multicast EID namespace state. 1089 Therefore the design decision to go with uPITRs [INTWORK] for unicast 1090 routing and mPETRs for multicast routing seems to be the sweet spot 1091 in the solution space so we can optimize state requirements and avoid 1092 head-end data replication at ITRs. 1094 10. Considerations when RP Addresses are Embedded in Group Addresses 1096 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1097 technique exists to embed the unicast address of an RP in a IPv6 1098 group address [RFC3956]. When routers in end sites process a PIM 1099 Join/Prune message which contain an embedded-RP group address, they 1100 extract the RP address from the group address and treat it from the 1101 EID namespace. However, core routers do not have state for the EID 1102 namespace, need to extract an RP address from the RLOC namespace. 1104 Therefore, it is the responsibility of ETRs in multicast receiver 1105 sites to map the group address into a group address where the 1106 embedded-RP address is from the RLOC namespace. The mapped RP- 1107 address is obtained from a EID-to-RLOC mapping database lookup. The 1108 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1109 the branch of the distribution tree from the source site resident RP 1110 to the ITR is created. 1112 This technique is no different than the techniques described in this 1113 specification for translating (S,G) state and propagating Join/Prune 1114 messages into the core. The only difference is that the (*,G) state 1115 in Join/Prune messages are mapped because they contain unicast 1116 addresses encoded in an Embedded-RP group address. 1118 11. Taking Advantage of Upgrades in the Core 1120 If the core routers are upgraded to support [RPFV] and [RFC5496], 1121 then we can pass EID specific data through the core without, 1122 possibly, having to store the state in the core. 1124 By doing this we can eliminate the ETR from unicast encapsulating PIM 1125 Join/Prune messages to the source site's ITR. 1127 However, this solution is restricted to a small set of workable cases 1128 which would not be good for general use of LISP-Multicast. In 1129 addition due to slow convergence properties, it is not being 1130 recommended for LISP-Multicast. 1132 12. Mtrace Considerations 1134 Mtrace functionality must be consistent with unicast traceroute 1135 functionality where all hops from multicast receiver to multicast 1136 source are visible. 1138 The design for mtrace for use in LISP-Multicast environments is to be 1139 determined but should build upon the mtrace version 2 specified in 1140 [MTRACE]. 1142 13. Security Considerations 1144 Refer to the [LISP] specification. 1146 14. Acknowledgments 1148 The authors would like to gratefully acknowledge the people who have 1149 contributed discussion, ideas, and commentary to the making of this 1150 proposal and specification. People who provided expert review were 1151 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1152 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1153 Ijsbrand Wijnands. 1155 We would also like to thank the MBONED working group for constructive 1156 and civil verbal feedback when this draft was presented at the Fall 1157 2008 IETF in Minneapolis. In particular, good commentary came from 1158 Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, 1159 Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. 1161 An expert review of this specification was done by Yiqun Cai and 1162 Liming Wei. We thank them for their detailed comments. 1164 This work originated in the Routing Research Group (RRG) of the IRTF. 1165 The individual submission [MLISP] was converted into this IETF LISP 1166 working group draft. 1168 15. References 1170 15.1. Normative References 1172 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1173 "Locator/ID Separation Protocol (LISP)", 1174 draft-ietf-lisp-13.txt (work in progress), June 2011. 1176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1177 Requirement Levels", BCP 14, RFC 2119, March 1997. 1179 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1180 Protocol (MSDP)", RFC 3618, October 2003. 1182 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1183 Point (RP) Address in an IPv6 Multicast Address", 1184 RFC 3956, November 2004. 1186 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1187 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1188 Protocol Specification (Revised)", RFC 4601, August 2006. 1190 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1191 Group Management Protocol Version 3 (IGMPv3) and Multicast 1192 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1193 Specific Multicast", RFC 4604, August 2006. 1195 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1196 IP", RFC 4607, August 2006. 1198 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1199 "Multiprotocol Extensions for BGP-4", RFC 4760, 1200 January 2007. 1202 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1203 "Bidirectional Protocol Independent Multicast (BIDIR- 1204 PIM)", RFC 5015, October 2007. 1206 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 1207 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 1209 15.2. Informative References 1211 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1212 Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in 1213 progress), March 2011. 1215 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1216 with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt 1217 (work in progress), March 2011. 1219 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1220 "LISP for Multicast Environments", 1221 draft-farinacci-lisp-multicast-01.txt (work in progress), 1222 November 2008. 1224 [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a 1225 Network Address (and port) Translator (NAT)", 1226 draft-ietf-behave-multicast-07.txt (work in progress), 1227 June 2007. 1229 [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace 1230 Version 2: Traceroute Facility for IP Multicast", 1231 draft-ietf-mboned-mtrace-v2-03.txt (work in progress), 1232 March 2009. 1234 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1235 TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), 1236 February 2008. 1238 Appendix A. Document Change Log 1240 A.1. Changes to draft-ietf-lisp-multicast-06.txt 1242 o Posted June 2011 to complete working group last call. 1244 o Added paragraph to section 8.1.2 based on Jesus comment about 1245 making it more clear what happens when two (S-EID,G) trees use the 1246 same (RLOC,G) tree. 1248 o Make more references to [INTWORK] when mentioning uPITRs and 1249 uPETRs. 1251 o Made many changes based on editorial and wordsmithing comments 1252 from Alia. 1254 A.2. Changes to draft-ietf-lisp-multicast-05.txt 1256 o Posted April 2011 to reset expiration timer. 1258 o Updated references. 1260 A.3. Changes to draft-ietf-lisp-multicast-04.txt 1262 o Posted October 2010 to reset expiration timer. 1264 o Updated references. 1266 A.4. Changes to draft-ietf-lisp-multicast-03.txt 1268 o Posted April 2010. 1270 o Added section 8.1.2 to address Joel Halpern's comment about 1271 receiver sites joining the same source site via 2 different RLOCs, 1272 each being a separate ITR. 1274 o Change all occurences of "mPTR" to "mPETR" to become more 1275 consistent with uPITRs and uPETRs described in [INTWORK]. That 1276 is, an mPETR is a LISP multicast router that decapsulates 1277 multicast packets that are encapsulated to it by ITRs in multicast 1278 source sites. 1280 o Add clarifications in section 9 about how homogeneous multicast 1281 encapsulation should occur. As well as describing in this 1282 section, how to deal with mixed-locator sets to avoid 1283 heterogeneous encapsulation. 1285 o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges 1286 of LISP global multicast network. 1288 A.5. Changes to draft-ietf-lisp-multicast-02.txt 1290 o Posted September 2009. 1292 o Added Document Change Log appendix. 1294 o Specify that the LISP Encapsulated Control Message be used for 1295 unicasting PIM Join/Prune messages from ETRs to ITRs. 1297 A.6. Changes to draft-ietf-lisp-multicast-01.txt 1299 o Posted November 2008. 1301 o Specified that PIM Join/Prune unicast messages that get sent from 1302 ETRs to ITRs of a source multicast site get LISP encapsulated in 1303 destination UDP port 4342. 1305 o Add multiple RLOCs per ITR per Yiqun's comments. 1307 o Indicate how static RPs can be used when LISP is run using Bidir- 1308 PIM in the core. 1310 o Editorial changes per Liming comments. 1312 o Add Mttrace Considersations section. 1314 A.7. Changes to draft-ietf-lisp-multicast-00.txt 1316 o Posted April 2008. 1318 o Renamed from draft-farinacci-lisp-multicast-01.txt. 1320 Authors' Addresses 1322 Dino Farinacci 1323 cisco Systems 1324 Tasman Drive 1325 San Jose, CA 1326 USA 1328 Email: dino@cisco.com 1330 Dave Meyer 1331 cisco Systems 1332 Tasman Drive 1333 San Jose, CA 1334 USA 1336 Email: dmm@cisco.com 1338 John Zwiebel 1339 cisco Systems 1340 Tasman Drive 1341 San Jose, CA 1342 USA 1344 Email: jzwiebel@cisco.com 1346 Stig Venaas 1347 cisco Systems 1348 Tasman Drive 1349 San Jose, CA 1350 USA 1352 Email: stig@cisco.com