idnits 2.17.1 draft-ietf-lisp-multicast-05.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 1212 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 5, 2011) is 4763 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-06 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-01 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-12 == 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 7, 2011 S. Venaas 6 cisco Systems 7 April 5, 2011 9 LISP for Multicast Environments 10 draft-ietf-lisp-multicast-05 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 7, 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 . . . . . . . . . . . . . . . . . . 18 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-05.txt . . . . . . . 35 91 A.2. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 92 A.3. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 93 A.4. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 35 94 A.5. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 95 A.6. 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 and a mPETR will be co-loacted since the 295 single device advertises a coarse EID-prefix in the underlying 296 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. 325 The fundamental multicast forwarding model is to encapsulate a 326 multicast packet into another multicast packet. An ITR will 327 encapsulate multicast packets received from sources that it serves in 328 another LISP multicast header. The destination group address from 329 the inner header is copied to the destination address of the outer 330 header. The inner source address is the EID of the multicast source 331 host and the outer source address is the RLOC of the encapsulating 332 ITR. 334 The LISP-Multicast architecture will follow this high-level protocol 335 and operational sequence: 337 1. Receiver hosts in multicast sites will join multicast content the 338 way they do today, they use IGMP. When they use IGMPv3 where 339 they specify source addresses, they use source EIDs, that is they 340 join (S-EID,G). If the multicast source is external to this 341 receiver site, the PIM Join/Prune message flows toward the ETRs, 342 finding the shortest exit (that is the closest exit for the Join/ 343 Prune message and the closest entrance for the multicast packet 344 to the receiver). 346 2. The ETR does a mapping database lookup for S-EID. If the mapping 347 is cached from a previous lookup (from either a previous Join/ 348 Prune for the source multicast site or a unicast packet that went 349 to the site), it will use the RLOC information from the mapping. 350 The ETR will use the same priority and weighting mechanism as for 351 unicast. So the source site can decide which way multicast 352 packets egress. 354 3. The ETR will build two PIM Join/Prune messages, one that contains 355 a (S-EID,G) entry that is unicast to the ITR that matches the 356 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 357 entry so the core network can create multicast state from this 358 ETR to the ITR. 360 4. When the ITR gets the unicast Join/Prune message (see Section 3 361 for formal definition), it will process (S-EID,G) entries in the 362 message and propagate them inside of the site where it has 363 explicit routing information for EIDs via the IGP. When the ITR 364 receives the (S-RLOC,G) PIM Join/Prune message it will process it 365 like any other join it would get in today's Internet. The S-RLOC 366 address is the IP address of this ITR. 368 5. At this point there is (S-EID,G) state from the joining host in 369 the receiver multicast site to the ETR of the receiver multicast 370 site. There is (S-RLOC,G) state across the core network from the 371 ETR of the multicast receiver site to the ITR in the multicast 372 source site and (S-EID,G) state in the source multicast site. 373 Note, the (S-EID,G) state is the same S-EID in each multicast 374 site. As other ETRs join the same multicast tree, they can join 375 through the same ITR (in which case the packet replication is 376 done in the core) or a different ITR (in which case the packet 377 replication is done at the source site). 379 6. When a packet is originated by the multicast host in the source 380 site, it will flow to one or more ITRs which will prepend a LISP 381 header by copying the group address to the outer destination 382 address field and insert its own locator address in the outer 383 source address field. The ITR will look at its (S-RLOC,G) state, 384 where S-RLOC is its own locator address, and replicate the packet 385 on each interface a (S-RLOC,G) joined was received on. The core 386 has (S-RLOC,G) so where fanout occurs to multiple sites, a core 387 router will do packet replication. 389 7. When either the source site or the core replicates the packet, 390 the ETR will receive a LISP packet with a destination group 391 address. It will decapsulate packets because it has receivers 392 for the group. Otherwise, it would have not received the packets 393 because it would not have joined. The ETR decapsulates and does 394 a (S-EID,G) lookup in its multicast FIB to forward packets out 395 one or more interfaces to forward the packet to internal 396 receivers. 398 This architecture is consistent and scalable with the architecture 399 presented in [LISP] where multicast state in the core operates on 400 locators and multicast state at the sites operates on EIDs. 402 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can 403 reside in the core through the use of RPF-vectors [RPFV] in PIM Join/ 404 Prune messages. However, few PIM implementations support RPF vectors 405 and LISP should avoid S-EID state in the core. See Section 5 for 406 details. 408 However, we have some observations on the algorithm above. We can 409 scale the control plane but at the expense of sending data to sites 410 which may have not joined the distribution tree where the 411 encapsulated data is being delivered. For example, one site joins 412 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 413 same multicast source site. Both multicast receiver sites join to 414 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 415 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 416 site. The ITR receives (S-RLOC,G) joins and populates the oif-list 417 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 418 (S-RLOC,G) packets will be delivered by the core to both multicast 419 receiver sites even though each have joined a single source-based 420 distribution tree. This behavior is a consequence of the many-to-one 421 mapping between S-EIDs and a S-RLOC. 423 There is a possible solution to this problem which reduces the number 424 of many-to-one occurrences of (S-EID,G) entries aggregating into a 425 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 426 RLOC addresses and these addresses are advertised in mapping database 427 entries, then ETRs at receiver sites have more RLOC address options 428 and therefore can join different (RLOC,G) entries for each (S-EID,G) 429 entry joined at the receiver site. It would not scale to have a one- 430 to-one relationship between the number of S-EID sources at a source 431 site and the number of RLOCs assigned to all ITRs at the site, but we 432 can reduce the "n" to a smaller number in the "n-to-1" relationship. 433 And in turn, reduce the opportunity for data packets to be delivered 434 to sites for groups not joined. 436 5. Source Addresses versus Group Addresses 438 Multicast group addresses don't have to be associated with either the 439 EID or RLOC namespace. They actually are a namespace of their own 440 that can be treated as logical with relatively opaque allocation. 441 So, by their nature, they don't detract from an incremental 442 deployment of LISP-Multicast. 444 As for source addresses, as in the unicast LISP scenario, there is a 445 decoupling of identification from location. In a LISP site, packets 446 are originated from hosts using their allocated EIDs, those addresses 447 are used to identify the host as well as where in the site's topology 448 the host resides but not how and where it is attached to the 449 Internet. 451 Therefore, when multicast distribution tree state is created anywhere 452 in the network on the path from any multicast receiver to a multicast 453 source, EID state is maintained at the source and receiver multicast 454 sites, and RLOC state is maintained in the core. That is, a 455 multicast distribution tree will be represented as a 3-tuple of 456 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 457 3-tuple is the state stored in routers from the source to one or more 458 ITRs in the source multicast site, the second element of the 3-tuple 459 is the state stored in routers downstream of the ITR, in the core, to 460 all LISP receiver multicast sites, and the third element in the 461 3-tuple is the state stored in the routers downstream of each ETR, in 462 each receiver multicast site, reaching each receiver. Note that 463 (S-EID,G) is the same in both the source and receiver multicast 464 sites. 466 The concatenation/mapping from the first element to the second 467 element of the 3-tuples is done by the ITR and from the second 468 element to the third element is done at the ETRs. 470 6. Locator Reachability Implications on LISP-Multicast 472 Multicast state as it is stored in the core is always (S,G) state as 473 it exists today or (S-RLOC,G) state as it will exist when LISP sites 474 are deployed. The core routers cannot distinguish one from the 475 other. They don't need to because it is state that RPFs against the 476 core routing tables in the RLOC namespace. The difference is where 477 the root of the distribution tree for a particular source is. In the 478 traditional multicast core, the source S is the source host's IP 479 address. For LISP-Multicast the source S is a single ITR of the 480 multicast source site. 482 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 483 ETR propagates a PIM Join/Prune message out of a receiver multicast 484 site. The selection is based on the same algorithm an ITR would use 485 to select an ETR when sending a unicast packet to the site. In the 486 unicast case, the ITR can change on a per-packet basis depending on 487 the reachability of the ETR. So an ITR can change relatively easily 488 using local reachability state. However, in the multicast case, when 489 an ITR goes unreachable, new distribution tree state must be built 490 because the encapsulating root has changed. This is more significant 491 than an RPF-change event, where any router would typically locally 492 change its RPF-interface for its existing tree state. But when an 493 encapsulating LISP-Multicast ITR goes unreachable, new distribution 494 state must be rebuilt and reflect the new encapsulator. Therefore, 495 when an ITR goes unreachable, all ETRs that are currently joined to 496 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 497 to the new ITR as well as send a unicast encapsulated Join/Prune 498 message telling the new ITR which (S-EID,G) is being joined. 500 This issue can be mitigated by using anycast addressing for the ITRs 501 so the problem does reduce to an RPF change in the core, but still 502 requires a unicast encapsulated Join/Prune message to tell the new 503 ITR about (S-EID,G). The problem with this approach is that the ETR 504 really doesn't know when the ITR has changed so the new anycast ITR 505 will get the (S-EID,G) state only when the ETR sends it the next time 506 during its periodic sending procedures. 508 7. Multicast Protocol Changes 510 A number of protocols are used today for inter-domain multicast 511 routing: 513 IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for 514 LISP-Multicast for two reasons. One being that they are link- 515 local and not used over site boundaries and second they advertise 516 group addresses that don't need translation. Where source 517 addresses are supplied in IGMPv3 and MLDv2 messages, they are 518 semantically regarded as EIDs and don't need to be converted to 519 RLOCs until the multicast tree-building protocol, such as PIM, is 520 received by the ETR at the site boundary. Addresses used for IGMP 521 and MLD come out of the source site's allocated addresses which 522 are therefore from the EID namespace. 524 MBGP: Even though MBGP is not a multicast routing protocol, it is 525 used to find multicast sources when the unicast BGP peering 526 topology and the multicast MBGP peering topology are not 527 congruent. When MBGP is used in a LISP-Multicast environment, the 528 prefixes which are advertised are from the RLOC namespace. This 529 allows receiver multicast sites to find a path to the source 530 multicast site's ITRs. MBGP peering addresses will be from the 531 RLOC namespace. 533 MSDP: MSDP is used to announce active multicast sources to other 534 routing domains (or LISP sites). The announcements come from the 535 PIM Rendezvous Points (RPs) from sites where there are active 536 multicast sources sending to various groups. In the context of 537 LISP-Multicast, the source addresses advertised in MSDP will 538 semantically be from the EID namespace since they describe the 539 identity of a source multicast host. It will be true that the 540 state stored in MSDP caches from core routers will be from the EID 541 namespace. An RP address inside of site will be from the EID 542 namespace so it can be advertised and reached by internal unicast 543 routing mechanism. However, for MSDP peer-RPF checking to work 544 properly across sites, the RP addresses must be converted or 545 mapped into a routable address that is advertised and maintained 546 in the BGP routing tables in the core. MSDP peering addresses can 547 come out of either the EID or a routable address namespace. And 548 the choice can be made unilaterally because the ITR at the site 549 will determine which namespace the destination peer address is out 550 of by looking in the mapping database service. 552 PIM-SSM: In the simplest form of distribution tree building, when 553 PIM operates in SSM mode, a source distribution tree is built and 554 maintained across site boundaries. In this case, there is a small 555 modification to the operation of the PIM protocol (but not to any 556 message format) to support taking a Join/Prune message originated 557 inside of a LISP site with embedded addresses from the EID 558 namespace and converting them to addresses from the RLOC namespace 559 when the Join/Prune message crosses a site boundary. This is 560 similar to the requirements documented in [MNAT]. 562 PIM-Bidir: Bidirectional PIM is typically run inside of a routing 563 domain, but if deployed in an inter-domain environment, one would 564 have to decide if the RP address of the shared-tree would be from 565 the EID namespace or the RLOC namespace. If the RP resides in a 566 site-based router, then the RP address is from the EID namespace. 567 If the RP resides in the core where RLOC addresses are routed, 568 then the RP address is from the RLOC namespace. This could be 569 easily distinguishable if the EID address were well-known address 570 allocation block from the RLOC namespace. Also, when using 571 Embedded-RP for RP determination [RFC3956], the format of the 572 group address could indicate the namespace the RP address is from. 573 However, refer to Section 10 for considerations core routers need 574 to make when using Embedded-RP IPv6 group addresses. When using 575 Bidir-PIM for inter-domain multicast routing, it is recommended to 576 use staticly configured RPs so core routers think the Bidir group 577 is associated with an ITR's RLOC as the RP address and site 578 routers think the Bidir group is associated with the site resident 579 RP with an EID address. With respect to DF-election in Bidir PIM, 580 no changes are required since all messaging and addressing is 581 link-local. 583 PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is 584 deployed in the Internet today is by having shared-trees within a 585 site and using source-trees across sites. By the use of MSDP and 586 PIM-SSM techniques described above, we can get multicast 587 connectivity across LISP sites. Having said that, that means 588 there are no special actions required for processing (*,G) or 589 (S,G,R) Join/Prune messages since they all operate against the 590 shared-tree which is site resident. Just like with ASM, there is 591 no (*,G) in the core when LISP-Multicast is in use. This is also 592 true for the RP-mapping mechanisms Auto-RP and BSR. 594 Based on the protocol description above, the conclusion is that there 595 are no protocol message format changes, just a translation function 596 performed at the control-plane. This will make for an easier and 597 faster transition for LISP since fewer components in the network have 598 to change. 600 It should also be stated just like it is in [LISP] that no host 601 changes, whatsoever, are required to have a multicast source host 602 send multicast packets and for a multicast receiver host to receive 603 multicast packets. 605 8. LISP-Multicast Data-Plane Architecture 607 The LISP-Multicast data-plane operation conforms to the operation and 608 packet formats specified in [LISP]. However, encapsulating a 609 multicast packet from an ITR is a much simpler process. The process 610 is simply to copy the inner group address to the outer destination 611 address. And to have the ITR use its own IP address (its RLOC), and 612 as the source address. The process is simpler for multicast because 613 there is no EID-to-RLOC mapping lookup performed during packet 614 forwarding. 616 In the decapsulation case, the ETR simply removes the outer header 617 and performs a multicast routing table lookup on the inner header 618 (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is 619 used to replicate the packet on site-facing interfaces leading to 620 multicast receiver hosts. 622 There is no Data-Probe logic for ETRs as there can be in the unicast 623 forwarding case. 625 8.1. ITR Forwarding Procedure 627 The following procedure is used by an ITR, when it receives a 628 multicast packet from a source inside of its site: 630 1. A multicast data packet sent by a host in a LISP site will have 631 the source address equal to the host's EID and the destination 632 address equal to the group address of the multicast group. It is 633 assumed the group information is obtained by current methods. 634 The same is true for a multicast receiver to obtain the source 635 and group address of a multicast flow. 637 2. When the ITR receives a multicast packet, it will have both S-EID 638 state and S-RLOC state stored. Since the packet was received on 639 a site-facing interface, the RPF lookup is based on the S-EID 640 state. If the RPF check succeeds, then the oif-list contains 641 interfaces that are site-facing and external-facing. For the 642 site-facing interfaces, no LISP header is prepended. For the 643 external-facing interfaces a LISP header is prepended. When the 644 ITR prepends a LISP header, it uses its own RLOC address as the 645 source address and copies the group address supplied by the IP 646 header the host built as the outer destination address. 648 8.1.1. Multiple RLOCs for an ITR 650 Typically, an ITR will have a single RLOC address but in some cases 651 there could be multiple RLOC addresses assigned from either the same 652 or different service providers. In this case when (S-RLOC,G) Join/ 653 Prune messages are received for each RLOC, there is a oif-list 654 merging action that must take place. Therefore, when a packet is 655 received from a site-facing interface that matches on a (S-EID,G) 656 entry, the interfaces of the oif-list from all (RLOC,G) entries 657 joined to the ITR as well as the site-facing oif-list joined for 658 (S-EID,G) must be part be included in packet replication. In 659 addition to replicating for all types of oif-lists, each oif entry 660 must be tagged with the RLOC address, so encapsulation uses the outer 661 source address for the RLOC joined. 663 8.1.2. Multiple ITRs for a LISP Source Site 665 Note when ETRs from different multicast receiver sites receive 666 (S-EID,G) joins, they may select a different S-RLOC for a multicast 667 source site due to policy (the multicast ITR can return different 668 multicast priority and weight values per ETR Map-Request). In this 669 case, the same (S-EID,G) is being realized by different (S-RLOC,G) 670 state in the core. This will not result in duplicate packets because 671 each ITR in the multicast source site will choose their own RLOC for 672 the source address for encapsulated multicast traffic. The RLOC 673 addresses are the ones joined by remote multicast ETRs. 675 8.2. ETR Forwarding Procedure 677 The following procedure is used by an ETR, when it receives a 678 multicast packet from a source outside of its site: 680 1. When a multicast data packet is received by an ETR on an 681 external-facing interface, it will do an RPF lookup on the S-RLOC 682 state it has stored. If the RPF check succeeds, the interfaces 683 from the oif-list are used for replication to interfaces that are 684 site-facing as well as interfaces that are external-facing (this 685 ETR can also be a transit multicast router for receivers outside 686 of its site). When the packet is to be replicated for an 687 external-facing interface, the LISP encapsulation header are not 688 stripped. When the packet is replicated for a site-facing 689 interface, the encapsulation header is stripped. 691 2. The packet without a LISP header is now forwarded down the 692 (S-EID,G) distribution tree in the receiver multicast site. 694 8.3. Replication Locations 696 Multicast packet replication can happen in the following topological 697 locations: 699 o In an IGP multicast router inside a site which operates on S-EIDs. 701 o In a transit multicast router inside of the core which operates on 702 S-RLOCs. 704 o At one or more ETR routers depending on the path a Join/Prune 705 message exits a receiver multicast site. 707 o At one or more ITR routers in a source multicast site depending on 708 what priorities are returned in a Map-Reply to receiver multicast 709 sites. 711 In the last case the source multicast site can do replication rather 712 than having a single exit from the site. But this only can occur 713 when the priorities in the Map-Reply are modified for different 714 receiver multicast site so that the PIM Join/Prune messages arrive at 715 different ITRs. 717 This policy technique, also used in [ALT] for unicast, is useful for 718 multicast to mitigate the problems of changing distribution tree 719 state as discussed in Section 6. 721 9. LISP-Multicast Interworking 723 This section will describe the multicast corollary to [INTWORK] which 724 describes the interworking of multicast routing among LISP and non- 725 LISP sites. 727 9.1. LISP and non-LISP Mixed Sites 729 Since multicast communication can involve more than two entities to 730 communicate together, the combinations of interworking scenarios are 731 more involved. However, the state maintained for distribution trees 732 at the sites is the same regardless of whether or not the site is 733 LISP enabled or not. So most of the implications are in the core 734 with respect to storing routable EID prefixes from either PA or PI 735 blocks. 737 Before we enumerate the multicast interworking scenarios, we must 738 define 3 deployment states of a site: 740 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 741 does today. The addresses for the site are globally routable. 743 o A site that deploys LISP for unicast routing. The addresses for 744 the site are not globally routable. Let's define the name for 745 this type of site as a uLISP site. 747 o A site that deploys LISP for both unicast and multicast routing. 748 The addresses for the site are not globally routable. Let's 749 define the name for this type of site as a LISP-Multicast site. 751 We will not consider a LISP site enabled for multicast purposes only 752 but do consider a uLISP site as documented in [INTWORK]. In this 753 section we don't discuss how a LISP site sends multicast packets when 754 all receiver sites are LISP-Multicast enabled; that has been 755 discussed in previous sections. 757 The following scenarios exist to make LISP-Multicast sites interwork 758 with non-LISP-Multicast sites: 760 1. A LISP site must be able to send multicast packets to receiver 761 sites which are a mix of non-LISP sites and uLISP sites. 763 2. A non-LISP site must be able to send multicast packets to 764 receiver sites which are a mix of non-LISP sites and uLISP sites. 766 3. A non-LISP site must be able to send multicast packets to 767 receiver sites which are a mix of LISP sites, uLISP sites, and 768 non-LISP sites. 770 4. A uLISP site must be able to send multicast packets to receiver 771 sites which are a mix of LISP sites, uLISP sites, and non-LISP 772 sites. 774 5. A LISP site must be able to send multicast packets to receiver 775 sites which are a mix of LISP sites, uLISP sites, and non-LISP 776 sites. 778 9.1.1. LISP Source Site to non-LISP Receiver Sites 780 In the first scenario, a site is LISP capable for both unicast and 781 multicast traffic and as such operates on EIDs. Therefore there is a 782 possibility that the EID prefix block is not routable in the core. 783 For LISP receiver multicast sites this isn't a problem but for non- 784 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 785 is received by the edge router, it has no route to propagate the 786 Join/Prune message out of the site. This is no different than the 787 unicast case that LISP-NAT in [INTWORK] solves. 789 LISP-NAT allows a unicast packet that exits a LISP site to get its 790 source address mapped to a globally routable address before the ITR 791 realizes that it should not encapsulate the packet destined to a non- 792 LISP site. For a multicast packet to leave a LISP site, distribution 793 tree state needs to be built so the ITR can know where to send the 794 packet. So the receiver multicast sites need to know about the 795 multicast source host by its routable address and not its EID 796 address. When this is the case, the routable address is the 797 (S-RLOC,G) state that is stored and maintained in the core routers. 798 It is important to note that the routable address for the host cannot 799 be the same as an RLOC for the site. Because we want the ITRs to 800 process a received PIM Join/Prune message from an external-facing 801 interface to be propagated inside of the site so the site-part of the 802 distribution tree is built. 804 Using a globally routable source address allows non-LISP and uLISP 805 multicast receiver to join, create, and maintain a multicast 806 distribution tree. However, the LISP multicast receiver site will 807 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 808 Prune message is received on a site-facing interface. It does this 809 because it wants to find a (S-RLOC,G) entry to Join in the core. So 810 we have a conflict of behavior between the two types of sites. 812 The solution to this problem is the same as when an ITR wants to send 813 a unicast packet to a destination site but needs determine if the 814 site is LISP capable or not. When it is not LISP capable, the ITR 815 does not encapsulate the packet. So for the multicast case, when ETR 816 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 817 mapping table lookup on S-EID. In this case, S-EID is not in the 818 mapping database because the source multicast site is using a 819 routable address and not an EID prefix address. So the ETR knows to 820 simply propagate the PIM Join/Prune message to a external-facing 821 interface without converting the (S-EID,G) because it is an (S,G) 822 where S is routable and reachable via core routing tables. 824 Now that the multicast distribution tree is built and maintained from 825 any non-LISP or uLISP receiver multicast site, the way packet 826 forwarding model is performed can be explained. 828 Since the ITR in the source multicast site has never received a 829 unicast encapsulated PIM Join/Prune message from any ETR in a 830 receiver multicast site, it knows there are no LISP-Multicast 831 receiver sites. Therefore, there is no need for the ITR to 832 encapsulate data. Since it will know a priori (via configuration) 833 that its site's EIDs are not routable, it assumes that the multicast 834 packets from the source host are sent by a routable address. That 835 is, it is the responsibility of the multicast source host's system 836 administrator to ensure that the source host sends multicast traffic 837 using a routable source address. When this happens, the ITR acts 838 simply as a router and forwards the multicast packet like an ordinary 839 multicast router. 841 There is an alternative to using a LISP-NAT scheme just like there is 842 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 843 (PxTRs). This can work the same way for multicast routing as well, 844 but the difference is that non-LISP and uLISP sites will send PIM 845 Join/Prune messages for (S-EID,G) which make their way in the core to 846 multicast PxTRs. Let's call this use of a PxTR as a "Multicast 847 Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID 848 prefixes, they draw the PIM Join/Prune control traffic making them 849 the target of the distribution tree. To get multicast packets from 850 the LISP source multicast sites, the tree needs to be built on the 851 path from the mPETR to the LISP source multicast site. To make this 852 happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a 853 "Proxy ITR", or an uPITR). 855 The existence of mPETRs in the core allows source multicast site ITRs 856 to encapsulate multicast packets according to (S-RLOC,G) state. The 857 (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The 858 encapsulated multicast packets are decapsulated by mPETRs and then 859 forwarded according to (S-EID,G) state. The (S-EID,G) state is built 860 from the non-LISP and uLISP receiver multicast sites to the mPETRs. 862 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 864 Clearly non-LISP multicast sites can send multicast packets to non- 865 LISP receiver multicast sites. That is what they do today. However, 866 discussion is required to show how non-LISP multicast sites send 867 multicast packets to uLISP receiver multicast sites. 869 Since uLISP receiver multicast sites are not targets of any (S,G) 870 state, they simply send (S,G) PIM Join/Prune messages toward the non- 871 LISP source multicast site. Since the source multicast site, in this 872 case has not been upgraded to LISP, all multicast source host 873 addresses are routable. So this case is simplified to where a uLISP 874 receiver multicast site looks to the source multicast site as a non- 875 LISP receiver multicast site. 877 9.1.3. Non-LISP Source Site to Any Receiver Site 879 When a non-LISP source multicast site has receivers in either a non- 880 LISP/uLISP site or a LISP site, one needs to decide how the LISP 881 receiver multicast site will attach to the distribution tree. We 882 know from Section 9.1.2 that non-LISP and uLISP receiver multicast 883 sites can join the distribution tree, but a LISP receiver multicast 884 site ETR will need to know if the source address of the multicast 885 source host is routable or not. We showed in Section 9.1.1 that an 886 ETR, before it sends a PIM Join/Prune message on an external-facing 887 interface, does a EID-to-RLOC mapping lookup to determine if it 888 should convert the (S,G) state from a PIM Join/Prune message received 889 on a site-facing interface to a (S-RLOC,G). If the lookup fails, the 890 ETR can conclude the source multicast site is a non-LISP site so it 891 simply forwards the Join/Prune message (it also doesn't need to send 892 a unicast encapsulated Join/Prune message because there is no ITR in 893 a non-LISP site and there is namespace continuity between the ETR and 894 source). 896 For a non-LISP source multicast site, (S-EID,G) state could be 897 limited to the edges of the network with the use of multicast proxy- 898 ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast 899 packets from non-LISP source multicast and uLISP sites and 900 encapsulate them to ETRs in receiver multicast sites or to mPETRs 901 that can decapsulate for non-LISP receiver multicast or uLISP sites. 902 The mPITRs are responsible for sending (S-EID,G) joins to the non- 903 LISP source multicast site. To connect the distribution trees 904 together, multicast ETRs will need to be configured with the mPITR's 905 RLOC addresses so they can send both (S-RLOC,G) joins to build a 906 distribution tree to the mPITR as well as for sending unicast oins to 907 mPITRs so they can propogate (S-EID,G) joins into source multicast 908 sites. The use of mPITRs is undergoing more study and is work in 909 progress. 911 9.1.4. Unicast LISP Source Site to Any Receiver Sites 913 In the last section, it was explained how an ETR in a multicast 914 receiver site can determine if a source multicast site is LISP- 915 enabled by looking into the mapping database. When the source 916 multicast site is a uLISP site, it is LISP enabled but the ITR, by 917 definition is not capable of doing multicast encapsulation. So for 918 the purposes of multicast routing, the uLISP source multicast site is 919 treated as non-LISP source multicast site. 921 Non-LISP receiver multicast sites can join distribution trees to a 922 uLISP source multicast site since the source site behaves, from a 923 forwarding perspective, as a non-LISP source site. This is also the 924 case for a uLISP receiver multicast site since the ETR does not have 925 multicast functionality built-in or enabled. 927 Special considerations are required for LISP receiver multicast sites 928 since they think the source multicast site is LISP capable, the ETR 929 cannot know if ITR is LISP-Multicast capable. To solve this problem, 930 each mapping database entry will have a multicast 2-tuple (Mpriority, 931 Mweight) per RLOC. When the Mpriority is set to 255, the site is 932 considered not multicast capable. So an ETR in a LISP receiver 933 multicast site can distinguish whether a LISP source multicast site 934 is LISP-Multicast site from a uLISP site. 936 9.1.5. LISP Source Site to Any Receiver Sites 938 When a LISP source multicast site has receivers in LISP, non-LISP, 939 and uLISP receiver multicast sites, it has a conflict about how it 940 sends multicast packets. The ITR can either encapsulate or natively 941 forward multicast packets. Since the receiver multicast sites are 942 heterogeneous in their behavior, one packet forwarding mechanism 943 cannot satisfy both. However, if a LISP receiver multicast site acts 944 like a uLISP site then it could receive packets like a non-LISP 945 receiver multicast site making all receiver multicast sites have 946 homogeneous behavior. However, this poses the following issues: 948 o LISP-NAT techniques with routable addresses would be required in 949 all cases. 951 o Or alternatively, mPETR deployment would be required forcing 952 coarse EID prefix advertisement in the core. 954 o But what is most disturbing is that when all sites that 955 participate are LISP-Multicast sites but then a non-LISP or uLISP 956 site joins the distribution tree, then the existing joined LISP 957 receiver multicast sites would have to change their behavior. 958 This would create too much dynamic tree-building churn to be a 959 viable alternative. 961 So the solution space options are: 963 1. Make the LISP ITR in the source multicast site send two packets, 964 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 965 multicast sites and another that is not encapsulated with 966 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 968 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 969 reach LISP-Multicast sites and to reach mPETRs that can 970 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 971 receiver multicast sites. 973 9.2. LISP Sites with Mixed Address Families 975 A LISP database mapping entry that describes the locator-set, 976 Mpriority and Mweight per locator address (RLOC), for an EID prefix 977 associated with a site could have RLOC addresses in either IPv4 or 978 IPv6 format. When a mapping entry has a mix of RLOC formatted 979 addresses, it is an implicit advertisement by the site that it is a 980 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 981 packets. 983 To distinguish if the site can receive dual-stack unicast packets as 984 well as dual-stack multicast packets, the Mpriority value setting 985 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 986 details. 988 If you consider the combinations of LISP, non-LISP, and uLISP sites 989 sharing the same distribution tree and considering the capabilities 990 of supporting IPv4, IPv6, or dual-stack, the number of total 991 combinations grows beyond comprehension. 993 Using some combinatorial math, we have the following profiles of a 994 site and the combinations that can occur: 996 1. LISP-Multicast IPv4 Site 998 2. LISP-Multicast IPv6 Site 1000 3. LISP-Multicast Dual-Stack Site 1002 4. uLISP IPv4 Site 1004 5. uLISP IPv6 Site 1005 6. uLISP Dual-Stack Site 1007 7. non-LISP IPv4 Site 1009 8. non-LISP IPv6 Site 1011 9. non-LISP Dual-Stack Site 1013 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 1014 illustrate some combinatorial math below. 1016 When 1 site talks to another site, the combinatorial is (9 2), when 1 1017 site talks to another 2 sites, the combinatorial is (9 3). If sum 1018 this up to (9 9), we have: 1020 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 1022 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 1024 Which results in the total number of cases to be considered at 502. 1026 This combinatorial gets even worse when you consider a site using one 1027 address family inside of the site and the xTRs use the other address 1028 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 1029 RLOCs). 1031 To rationalize this combinatorial nightmare, there are some 1032 guidelines which need to be put in place: 1034 o Each distribution tree shared between sites will either be an IPv4 1035 distribution tree or an IPv6 distribution tree. Therefore, we can 1036 avoid head-end replication by building and sending packets on each 1037 address family based distribution tree. Even though there might 1038 be an urge to do multicast packet translation from one address 1039 family format to the other, it is a non-viable over-complicated 1040 urge. Multicast ITRs will only encapsulate packets where the 1041 inner and outer headers are from the same address family. 1043 o All LISP sites on a multicast distribution tree must share a 1044 common address family which is determined by the source site's 1045 locator-set in its LISP database mapping entry. All receiver 1046 multicast sites will use the best RLOC priority controlled by the 1047 source multicast site. This is true when the source site is 1048 either LISP-Multicast or uLISP capable. This means that priority- 1049 based policy modification is prohibited. When a receiver 1050 multicast site ETR receives a (S-EID,G) join, it must select a 1051 S-RLOC for the same address family as S-EID. 1053 o A mixed multicast locator-set with the best multicast priority 1054 values MUST not be configured on multicast ITRs. A mixed locator- 1055 set can exist (for unicast use), but the multicast priorities MUST 1056 be the set for the same address family locators. 1058 o When the source site is not LISP capable, it is up to how 1059 receivers find the source and group information for a multicast 1060 flow. That mechanism decides the address family for the flow. 1062 9.3. Making a Multicast Interworking Decision 1064 This Multicast Interworking section has shown all combinations of 1065 multicast connectivity that could occur. As you might have already 1066 concluded, this can be quite complicated and if the design is too 1067 ambitious, the dynamics of the protocol could cause a lot of 1068 instability. 1070 The trade-off decisions are hard to make and we want the same single 1071 solution to work for both IPv4 and IPv6 multicast. It is imperative 1072 to have an incrementally deployable solution for all of IPv4 unicast 1073 and multicast and IPv6 unicast and multicast while minimizing (or 1074 eliminating) both unicast and multicast EID namespace state. 1076 Therefore the design decision to go with uPITRs for unicast routing 1077 and mPETRs for multicast routing seems to be the sweet spot in the 1078 solution space so we can optimize state requirements and avoid head- 1079 end data replication at ITRs. 1081 10. Considerations when RP Addresses are Embedded in Group Addresses 1083 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1084 technique exists to embed the unicast address of an RP in a IPv6 1085 group address [RFC3956]. When routers in end sites process a PIM 1086 Join/Prune message which contain an embedded-RP group address, they 1087 extract the RP address from the group address and treat it from the 1088 EID namespace. However, core routers do not have state for the EID 1089 namespace, need to extract an RP address from the RLOC namespace. 1091 Therefore, it is the responsibility of ETRs in multicast receiver 1092 sites to map the group address into a group address where the 1093 embedded-RP address is from the RLOC namespace. The mapped RP- 1094 address is obtained from a EID-to-RLOC mapping database lookup. The 1095 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1096 the branch of the distribution tree from the source site resident RP 1097 to the ITR is created. 1099 This technique is no different than the techniques described in this 1100 specification for translating (S,G) state and propagating Join/Prune 1101 messages into the core. The only difference is that the (*,G) state 1102 in Join/Prune messages are mapped because they contain unicast 1103 addresses encoded in an Embedded-RP group address. 1105 11. Taking Advantage of Upgrades in the Core 1107 If the core routers are upgraded to support [RPFV] and [RFC5496], 1108 then we can pass EID specific data through the core without, 1109 possibly, having to store the state in the core. 1111 By doing this we can eliminate the ETR from unicast encapsulating PIM 1112 Join/Prune messages to the source site's ITR. 1114 However, this solution is restricted to a small set of workable cases 1115 which would not be good for general use of LISP-Multicast. In 1116 addition to slow convergence properties, it is not being recommended 1117 for LISP-Multicast. 1119 12. Mtrace Considerations 1121 Mtrace functionality must be consistent with unicast traceroute 1122 functionality where all hops from multicast receiver to multicast 1123 source are visible. 1125 The design for mtrace for use in LISP-Multicast environments is to be 1126 determined but should build upon the mtrace version 2 specified in 1127 [MTRACE]. 1129 13. Security Considerations 1131 Refer to the [LISP] specification. 1133 14. Acknowledgments 1135 The authors would like to gratefully acknowledge the people who have 1136 contributed discussion, ideas, and commentary to the making of this 1137 proposal and specification. People who provided expert review were 1138 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1139 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1140 Ijsbrand Wijnands. 1142 We would also like to thank the MBONED working group for constructive 1143 and civil verbal feedback when this draft was presented at the Fall 1144 2008 IETF in Minneapolis. In particular, good commentary came from 1145 Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, 1146 Ron Bonica, and Lenny Guardino. 1148 An expert review of this specification was done by Yiqun Cai and 1149 Liming Wei. We thank them for their detailed comments. 1151 This work originated in the Routing Research Group (RRG) of the IRTF. 1152 The individual submission [MLISP] was converted into this IETF LISP 1153 working group draft. 1155 15. References 1157 15.1. Normative References 1159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1160 Requirement Levels", BCP 14, RFC 2119, March 1997. 1162 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1163 Protocol (MSDP)", RFC 3618, October 2003. 1165 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1166 Point (RP) Address in an IPv6 Multicast Address", 1167 RFC 3956, November 2004. 1169 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1170 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1171 Protocol Specification (Revised)", RFC 4601, August 2006. 1173 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1174 Group Management Protocol Version 3 (IGMPv3) and Multicast 1175 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1176 Specific Multicast", RFC 4604, August 2006. 1178 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1179 IP", RFC 4607, August 2006. 1181 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1182 "Multiprotocol Extensions for BGP-4", RFC 4760, 1183 January 2007. 1185 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1186 "Bidirectional Protocol Independent Multicast (BIDIR- 1187 PIM)", RFC 5015, October 2007. 1189 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 1190 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 1192 15.2. Informative References 1194 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1195 Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in 1196 progress), March 2011. 1198 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1199 with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt 1200 (work in progress), March 2010. 1202 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1203 "Locator/ID Separation Protocol (LISP)", 1204 draft-ietf-lisp-12.txt (work in progress), April 2011. 1206 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1207 "LISP for Multicast Environments", 1208 draft-farinacci-lisp-multicast-01.txt (work in progress), 1209 November 2008. 1211 [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a 1212 Network Address (and port) Translator (NAT)", 1213 draft-ietf-behave-multicast-07.txt (work in progress), 1214 June 2007. 1216 [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace 1217 Version 2: Traceroute Facility for IP Multicast", 1218 draft-ietf-mboned-mtrace-v2-03.txt (work in progress), 1219 March 2009. 1221 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1222 TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), 1223 February 2008. 1225 Appendix A. Document Change Log 1227 A.1. Changes to draft-ietf-lisp-multicast-05.txt 1229 o Posted April 2011 to reset expiration timer. 1231 o Updated references. 1233 A.2. Changes to draft-ietf-lisp-multicast-04.txt 1235 o Posted October 2010 to reset expiration timer. 1237 o Updated references. 1239 A.3. Changes to draft-ietf-lisp-multicast-03.txt 1241 o Posted April 2010. 1243 o Added section 8.1.2 to address Joel Halpern's comment about 1244 receiver sites joining the same source site via 2 different RLOCs, 1245 each being a separate ITR. 1247 o Change all occurences of "mPTR" to "mPETR" to become more 1248 consistent with uPITRs and uPETRs described in [INTWORK]. That 1249 is, an mPETR is a LISP multicast router that decapsulates 1250 multicast packets that are encapsulated to it by ITRs in multicast 1251 source sites. 1253 o Add clarifications in section 9 about how homogeneous multicast 1254 encapsulation should occur. As well as describing in this 1255 section, how to deal with mixed-locator sets to avoid 1256 heterogeneous encapsulation. 1258 o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges 1259 of LISP global multicast network. 1261 A.4. Changes to draft-ietf-lisp-multicast-02.txt 1263 o Posted September 2009. 1265 o Added Document Change Log appendix. 1267 o Specify that the LISP Encapsulated Control Message be used for 1268 unicasting PIM Join/Prune messages from ETRs to ITRs. 1270 A.5. Changes to draft-ietf-lisp-multicast-01.txt 1272 o Posted November 2008. 1274 o Specified that PIM Join/Prune unicast messages that get sent from 1275 ETRs to ITRs of a source multicast site get LISP encapsulated in 1276 destination UDP port 4342. 1278 o Add multiple RLOCs per ITR per Yiqun's comments. 1280 o Indicate how static RPs can be used when LISP is run using Bidir- 1281 PIM in the core. 1283 o Editorial changes per Liming comments. 1285 o Add Mttrace Considersations section. 1287 A.6. Changes to draft-ietf-lisp-multicast-00.txt 1289 o Posted April 2008. 1291 o Renamed from draft-farinacci-lisp-multicast-01.txt. 1293 Authors' Addresses 1295 Dino Farinacci 1296 cisco Systems 1297 Tasman Drive 1298 San Jose, CA 1299 USA 1301 Email: dino@cisco.com 1303 Dave Meyer 1304 cisco Systems 1305 Tasman Drive 1306 San Jose, CA 1307 USA 1309 Email: dmm@cisco.com 1311 John Zwiebel 1312 cisco Systems 1313 Tasman Drive 1314 San Jose, CA 1315 USA 1317 Email: jzwiebel@cisco.com 1319 Stig Venaas 1320 cisco Systems 1321 Tasman Drive 1322 San Jose, CA 1323 USA 1325 Email: stig@cisco.com