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