idnits 2.17.1 draft-farinacci-lisp-multicast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1192. 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 Copyright Line does not match the current year == Line 1112 has weird spacing: '...ss (and port)...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 26, 2008) is 5602 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 (-05) exists of draft-fuller-lisp-alt-02 == Outdated reference: A later version (-02) exists of draft-lewis-lisp-interworking-00 == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-03 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-10 == Outdated reference: A later version (-12) exists of draft-ietf-behave-multicast-07 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-06 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). 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: May 30, 2009 cisco Systems 6 S. Venaas 7 Uninett 8 November 26, 2008 10 LISP for Multicast Environments 11 draft-farinacci-lisp-multicast-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 30, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This draft describes how inter-domain multicast routing will function 45 in an environment where Locator/ID Separation is deployed using the 46 LISP architecture. 48 Table of Contents 50 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 53 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 54 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 55 6. Locator Reachability Implications on LISP-Multicast . . . . . 13 56 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 57 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 58 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 59 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 60 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 61 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18 62 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 18 63 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 19 64 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 20 65 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 21 66 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 21 67 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 22 68 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22 69 9.3. Making a Multicast Interworking Decision . . . . . . . . . 24 70 10. Considerations when RP Addresses are Embedded in Group 71 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 74 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 77 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 79 Intellectual Property and Copyright Statements . . . . . . . . . . 32 81 1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 The Locator/ID Separation Architecture [LISP] provides a mechanism to 90 separate out Identification and Location semantics from the current 91 definition of an IP address. By creating two namespaces, an EID 92 namespace used by sites and a Locator (RLOC) namespace used by core 93 routing, the core routing infrastructure can scale by doing 94 topological aggregation of routing information. 96 Since LISP creates a new namespace, a mapping function must exist to 97 map a site's EID prefixes to its associated locators. For unicast 98 packets, both the source address and destination address must be 99 mapped. For multicast packets, only the source address needs to be 100 mapped. The destination group address doesn't need to be mapped 101 because the semantics of an IPv4 or IPv6 group address are logical in 102 nature and not topology-dependent. Therefore, this specifications 103 focuses on to map a source EID address of a multicast flow during 104 distribution tree setup and packet delivery. 106 This specification will address the following scenarios: 108 1. How a multicast source host in a LISP site sends multicast 109 packets to receivers inside of its site as well as to receivers 110 in other sites that are LISP enabled. 112 2. How inter-domain (or between LISP sites) multicast distribution 113 trees are built and how forwarding of multicast packets leaving a 114 source site toward receivers sites is performed. 116 3. What protocols are affected and what changes are required to such 117 multicast protocols. 119 4. How ASM-mode, SSM-mode, and Bidir-mode service models will 120 operate. 122 5. How multicast packet flow will occur for multiple combinations of 123 LISP and non-LISP capable source and receiver sites, for example: 125 A. How multicast packets from a source host in a LISP site are 126 sent to receivers in other sites when they are all non-LISP 127 sites. 129 B. How multicast packets from a source host in a LISP site are 130 sent to receivers in both LISP-enabled sites and non-LISP 131 sites. 133 C. How multicast packets from a source host in a non-LISP site 134 are sent to receivers in other sites when they are all LISP- 135 enabled sites. 137 D. How multicast packets from a source host in a non-LISP site 138 are sent to receivers in both LISP-enabled sites and non-LISP 139 sites. 141 This specification focuses on what changes are needed to the 142 multicast routing protocols to support LISP-Multicast as well as 143 other protocols used for inter-domain multicast, such as Multi- 144 protocol BGP (MBGP) [RFC4760]. The approach proposed in this 145 specification requires no changes to the multicast infrastructure 146 inside of a site when all sources and receivers reside in that site, 147 even when the site is LISP enabled. That is, internal operation of 148 multicast is unchanged regardless of whether or not the site is LISP 149 enabled or whether or not receivers exist in other sites which are 150 LISP-enabled. 152 Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], 153 and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not 154 run in an inter-domain environment is not addressed in depth in this 155 version of the specification. 157 Also, the current version of this specification does not describe 158 multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR 159 descriptions in [LISP]. 161 3. Definition of Terms 163 The terminology in this section is consistent with the definitions in 164 [LISP] but is extended specifically to deal with the application of 165 the terminology to multicast routing. 167 LISP-Multicast: a reference to the design in this specification. 168 That is, when any site that is participating in multicast 169 communication has been upgraded to be a LISP site, the operation 170 of control-plane and data-plane protocols is considered part of 171 the LISP-Multicast architecture. 173 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 174 used in the source address field of the first (most inner) LISP 175 header of a multicast packet. The host obtains a destination 176 group address the same way it obtains one today, as it would when 177 it is a non-LISP site. The source EID is obtained via existing 178 mechanisms used to set a host's "local" IP address. An EID is 179 allocated to a host from an EID prefix block associated with the 180 site the host is located in. An EID can be used by a host to 181 refer to another host, as when it joins an SSM (S-EID,G) route 182 using IGMP version 3 [RFC4604]. LISP uses Provider Independent 183 (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 184 Note that EID blocks may be assigned in a hierarchical manner, 185 independent of the network topology, to facilitate scaling of the 186 mapping database. In addition, an EID block assigned to a site 187 may have site-local structure (subnetting) for routing within the 188 site; this structure is not visible to the global routing system. 190 Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress 191 tunnel router (ITR), the router in the multicast source host's 192 site that encapsulates multicast packets. It is the output of a 193 EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. 194 Typically, RLOCs are numbered from topologically-aggregatable 195 blocks that are assigned to a site at each point to which it 196 attaches to the global Internet; where the topology is defined by 197 the connectivity of provider networks, RLOCs can be thought of as 198 Provider Assigned (PA) addresses. Multiple RLOCs can be assigned 199 to the same ITR device or to multiple ITR devices at a site. 201 Ingress Tunnel Router (ITR): a router which accepts an IP multicast 202 packet with a single IP header (more precisely, an IP packet that 203 does not contain a LISP header). The router treats this "inner" 204 IP destination multicast address opaquely so it doesn't need to 205 perform a map lookup on the group address because it is 206 topologically insignificant. The router then prepends an "outer" 207 IP header with one of its globally-routable RLOCs as the source 208 address field. This RLOC is known to other multicast receiver 209 sites which have used the mapping database to join a multicast 210 tree for which the ITR is the root. In general, an ITR receives 211 IP packets from site end systems on one side and sends LISP- 212 encapsulated multicast IP packets out all external interfaces 213 which have been joined. 215 An ITR would receive a multicast packet from a source inside of 216 its site when 1) it is on the path from the multicast source to 217 internally joined receivers, or 2) when it is on the path from the 218 multicast source to externally joined receivers. 220 Egress Tunnel Router (ETR): a router that is on the path from a 221 multicast source host in another site to a multicast receiver in 222 its own site. An ETR accepts a PIM Join/Prune message from a site 223 internal PIM router destined for the source's EID in the multicast 224 source site. The ETR maps the source EID in the Join/Prune 225 message to an RLOC address based on the EID-to-RLOC mapping. This 226 sets up the ETR to accept multicast encapsulated packets from the 227 ITR in the source multicast site. A multicast ETR decapsulates 228 multicast encapsulated packets and replicates them on interfaces 229 leading to internal receivers. 231 xTR: is a reference to an ITR or ETR when direction of data flow is 232 not part of the context description. xTR refers to the router that 233 is the tunnel endpoint. Used synonymously with the term "Tunnel 234 Router". For example, "An xTR can be located at the Customer Edge 235 (CE) router", meaning both ITR and ETR functionality can be at the 236 CE router. 238 LISP Header: a term used in this document to refer to the outer 239 IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR 240 prepends headers and an ETR strips headers. A LISP encapsulated 241 multicast packet will have an "inner" header with the source EID 242 in the source field; an "outer" header with the source RLOC in the 243 source field: and the same globally unique group address in the 244 destination field of both the inner and outer header. 246 (S,G) State: the formal definition is in the PIM Sparse Mode 247 [RFC4601] specification. For this specification, the term is used 248 generally to refer to multicast state. Based on its topological 249 location, the (S,G) state resides in routers can be either 250 (S-EID,G) state (at a location where the (S,G) state resides) or 251 (S-RLOC,G) state (in the Internet core). 253 (S-EID,G) State: refers to multicast state in multicast source and 254 receiver sites where S-EID is the IP address of the multicast 255 source host (its EID). An S-EID can appear in an IGMPv3 report, 256 an MSDP SA message or a PIM Join/Prune message that travels inside 257 of a site. 259 (S-RLOC,G) State: refers to multicast state in the core where S is 260 a source locator (the IP address of a multicast ITR) of a site 261 with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) 262 entry by doing a mapping database lookup for the EID prefix that 263 S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message 264 when it travels from an ETR to an ITR over the Internet core. 266 uLISP Site: a unicast only LISP site according to [LISP] which has 267 not deployed the procedures of this specification and therefore, 268 for multicast purposes, follows the procedures from Section 9. 270 mPTR: this is a multicast PTR that is responsible for advertising a 271 very coarse EID prefix which non-LISP and uLISP sites can target 272 their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP 273 source multicast sites can send multicast packets using source 274 addresses from the EID namespace. mPTRs act as Proxy ETRs for 275 supporting multicast routing in a LISP infrastructure. 277 Mixed Locator-Sets: this is a locator-set for a LISP database 278 mapping entry where the RLOC addresses in the locator-set are in 279 both IPv4 and IPv6 format. 281 Unicast PIM Join/Prune Message: this is a standard PIM Join/Prune 282 message (encapsulated in an IP header with protocol number 103) 283 which is sent by ETRs at multicast receiver sites to an ITR at a 284 multicast source site. This message is sent periodically as long 285 as there are interfaces in the oif-list for the (S-EID,G) entry 286 the ETR is joining for. 288 4. Basic Overview 290 LISP, when used for unicast routing, increases the site's ability to 291 control ingress traffic flows. Egress traffic flows are controlled 292 by the IGP in the source site. For multicast, the IGP coupled with 293 PIM can decide which path multicast packets ingress. By using the 294 traffic engineering features of LISP, a multicast source site can 295 control the egress of its multicast traffic. By controlling the 296 priorities of locators from a mapping database entry, a source 297 multicast site can control which way multicast receiver sites join to 298 the source site. 300 At this point in time, we don't see a requirement for different 301 locator-sets, priority, and weight policies for multicast than we 302 have for unicast. 304 The fundamental multicast forwarding model is to encapsulate a 305 multicast packet into another multicast packet. An ITR will 306 encapsulate multicast packets received from sources that it serves in 307 another LISP multicast header. The destination group address from 308 the inner header is copied to the destination address of the outer 309 header. The inner source address is the EID of the multicast source 310 host and the outer source address is the RLOC of the encapsulating 311 ITR. 313 The LISP-Multicast architecture will follow this high-level protocol 314 and operational sequence: 316 1. Receiver hosts in multicast sites will join multicast content the 317 way they do today, they use IGMP. When they use IGMPv3 where 318 they specify source addresses, they use source EIDs, that is they 319 join (S-EID,G). If the S-EID is a local multicast source host. 320 If the multicast source is external to this receiver site, the 321 PIM Join/Prune message flows toward the ETRs, finding the 322 shortest exit (that is the closest exit for the Join/Prune 323 message but it is the closest entrance for the multicast packet 324 to the receiver). 326 2. The ETR does a mapping database lookup for S-EID. If the mapping 327 is cached from a previous lookup (from either a previous Join/ 328 Prune for the source multicast site or a unicast packet that went 329 to the site), it will use the RLOC information from the mapping. 330 The ETR will use the same priority and weighting mechanism as for 331 unicast. So the source site can decide which way multicast 332 packets egress. 334 3. The ETR will build two PIM Join/Prune messages, one that contains 335 a (S-EID,G) entry that is unicast to the ITR that matches the 336 RLOC the ETR selects, and the other which contains a (S-RLOC,G) 337 entry so the core network can create multicast state from this 338 ETR to the ITR. 340 4. When the ITR gets the unicast Join/Prune message (see Section 3 341 for formal definition), it will process (S-EID,G) entries in the 342 message and propagate them inside of the site where it has 343 explicit routing information for EIDs via the IGP. When the ITR 344 receives the (S-RLOC,G) PIM Join/Prune message it will process it 345 like any other join it would get in today's Internet. The S-RLOC 346 address is the IP address of this ITR. 348 5. At this point there is (S-EID,G) state from the joining host in 349 the receiver multicast site to the ETR of the receiver multicast 350 site. There is (S-RLOC,G) state across the core network from the 351 ETR of the multicast receiver site to the ITR in the multicast 352 source site and (S-EID,G) state in the source multicast site. 353 Note, the (S-EID,G) state is the same S-EID in each multicast 354 site. As other ETRs join the same multicast tree, they can join 355 through the same ITR (in which case the packet replication is 356 done in the core) or a different ITR (in which case the packet 357 replication is done at the source site). 359 6. When a packet is originated by the multicast host in the source 360 site, it will flow to one or more ITRs which will prepend a LISP 361 header by copying the group address to the outer destination 362 address field and insert its own locator address in the outer 363 source address field. The ITR will look at its (S-RLOC,G) state, 364 where S-RLOC is its own locator address, and replicate the packet 365 on each interface a (S-RLOC,G) joined was received on. The core 366 has (S-RLOC,G) so where fanout occurs to multiple sites, a core 367 router will do packet replication. 369 7. When either the source site or the core replicates the packet, 370 the ETR will receive a LISP packet with a destination group 371 address. It will also decapsulate packets because it has 372 receivers for the group. Otherwise, it would have not received 373 the packets because it would not have joined. The ETR 374 decapsulates and does a (S-EID,G) lookup in its multicast FIB to 375 forward packets out one or more interfaces to forward the packet 376 to internal receivers. 378 This architecture is consistent and scalable with the architecture 379 presented in [LISP] where multicast state in the core operates on 380 locators and multicast state at the sites operates on EIDs. 382 Alternatively, [LISP] does present a mechanism where (S-EID,G) state 383 can reside in the core through the use of RPF-vectors [RPFV] in PIM 384 Join/Prune messages. However, this will require EID state in core as 385 well as the use of RPF-vector formatted Join/Prune messages which are 386 not the default implementation choice. So we choose a design that 387 can allow the separation of namespaces as unicast LISP provides. It 388 will be at the expense of creating new (S-RLOC,G) state when ITRs go 389 unreachable. See Section 5 for details. 391 However, we have some observations on the algorithm above. We can 392 scale the control plane but at the expense of sending data to sites 393 which may have not joined the distribution tree where the 394 encapsulated data is being delivered. For example, one site joins 395 (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the 396 same multicast source site. Both multicast receiver sites join to 397 the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the 398 ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the 399 site. The ITR receives (S-RLOC,G) joins and populates the oif-list 400 state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one 401 (S-RLOC,G) packets will be delivered by the core to both multicast 402 receiver sites even though each have joined a single source-based 403 distribution tree. This behavior is a consequence of the many-to-one 404 mapping between S-EIDs and a S-RLOC. 406 There is a possible solution to this problem which reduces the number 407 of many-to-one occurrences of (S-EID,G) entries aggregating into a 408 single (S-RLOC,G) entry. If a physical ITR can be assigned multiple 409 RLOC addresses and these addresses are advertised in mapping database 410 entries, then ETRs at receiver sites have more RLOC address options 411 and therefore can join different (RLOC,G) entries for each (S-EID,G) 412 entry joined at the receiver site. It would not scale to have a one- 413 to-one relationship between the number of S-EID sources at a source 414 site and the number of RLOCs assigned to all ITRs at the site, but we 415 can reduce the "n" to a smaller number in the "n-to-1" relationship. 416 And in turn, reduce the opportunity for data packets to be delivered 417 to sites for groups not joined. 419 5. Source Addresses versus Group Addresses 421 Multicast group addresses don't have to be associated with either the 422 EID or RLOC namespace. They actually are a namespace of their own 423 that can be treated as logical with relatively opaque allocation. 424 So, by their nature, they don't detract from an incremental 425 deployment of LISP-Multicast. 427 As for source addresses, as in the unicast LISP scenario, there is a 428 decoupling of identification from location. In a LISP site, packets 429 are originated from hosts using their allocated EIDs, those addresses 430 are used to identify the host as well as where in the site's topology 431 the host resides but not how and where it is attached to the 432 Internet. 434 Therefore, when multicast distribution tree state is created anywhere 435 in the network on the path from the any multicast receiver to a 436 multicast source, EID state is maintained at the source and receiver 437 multicast sites, and RLOC state is maintained in the core. That is, 438 a multicast distribution tree will be represented as a 3-tuple of 439 {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 440 3-tuple is the state stored in routers from the source to one or more 441 ITRs in the source multicast site, the second element of the 3-tuple 442 is the state stored in routers downstream of the ITR, in the core, to 443 all LISP receiver multicast sites, and the third element in the 444 3-tuple is the state stored in the routers downstream of each ETR, in 445 each receiver multicast site, reaching each receiver. Note that 446 (S-EID,G) is the same in both the source and receiver multicast 447 sites. 449 The concatenation/mapping from the first element to the second 450 element of the 3-tuples is done by the ITR and from the second 451 element to the third element is done at the ETRs. 453 6. Locator Reachability Implications on LISP-Multicast 455 Multicast state as it is stored in the core is always (S,G) state as 456 it exists today or (S-RLOC,G) state as it will exist when LISP sites 457 are deployed. The core routers cannot distinguish one from the 458 other. They don't need to because it is state that RPFs against the 459 core routing tables in the RLOC namespace. The difference is where 460 the root of the distribution tree for a particular source is. In the 461 traditional multicast core, the source S is the source host's IP 462 address. For LISP-Multicast the source S is a single ITR of the 463 multicast source site. 465 An ITR is selected based on the LISP EID-to-RLOC mapping used when an 466 ETR propagates a PIM Join/Prune message out of a receiver multicast 467 site. The selection is based on the same algorithm an ITR would use 468 to select an ETR when sending a unicast packet to the site. In the 469 unicast case, the ITR can change on a per-packet basis depending on 470 the reachability of the ETR. So an ITR can change relatively easily 471 using local reachability state. However, in the multicast case, when 472 an ITR goes unreachable, new distribution tree state must be built 473 because the encapsulating root has changed. This is more significant 474 than an RPF-change event, where any router would typically locally 475 change its RPF-interface for its existing tree state. But when an 476 encapsulating LISP-Multicast ITR goes unreachable, new distribution 477 state must be rebuilt and reflect the new encapsulator. Therefore, 478 when an ITR goes unreachable, all ETRs that are currently joined to 479 that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) 480 to the new ITR as well as send a unicast Join/Prune message telling 481 the new ITR which (S-EID,G) is being joined. 483 This issue can be mitigated by using anycast addressing for the ITRs 484 so the problem does reduce to an RPF change in the core, but still 485 requires a unicast Join/Prune message to tell the new ITR about 486 (S-EID,G). The problem with this approach is that the ETR really 487 doesn't know when the ITR has changed so the new anycast ITR will get 488 the (S-EID,G) state only when the ETR sends it the next time during 489 its periodic sending procedures. 491 7. Multicast Protocol Changes 493 A number of protocols are used today for inter-domain multicast 494 routing: 496 IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for 497 LISP-Multicast for two reasons. One being that they are link- 498 local and not used over site boundaries and second they advertise 499 group addresses that don't need translation. Where source 500 addresses are supplied in IGMPv3 and MLDv2 messages, they are 501 semantically regarded as EIDs and don't need to be converted to 502 RLOCs until the multicast tree-building protocol, such as PIM, is 503 received by the ETR at the site boundary. Addresses used for IGMP 504 and MLD come out of the source site's allocated addresses which 505 are therefore from the EID namespace. 507 MBGP: Even though MBGP is not a multicast routing protocol, it is 508 used to find multicast sources when the unicast BGP peering 509 topology and the multicast MBGP peering topology are not 510 congruent. When MBGP is used in a LISP-Multicast environment, the 511 prefixes which are advertised are from the RLOC namespace. This 512 allows receiver multicast sites to find a path to the source 513 multicast site's ITRs. MBGP peering addresses will be from the 514 RLOC namespace. 516 MSDP: MSDP is used to announce active multicast sources to other 517 routing domains (or LISP sites). The announcements come from the 518 PIM Rendezvous Points (RPs) from sites where there are active 519 multicast sources sending to various groups. In the context of 520 LISP-Multicast, the source addresses advertised in MSDP will 521 semantically be from the EID namespace since they describe the 522 identity of a source multicast host. It will be true that the 523 state stored in MSDP caches from core routers will be from the EID 524 namespace. An RP address inside of site will be from the EID 525 namespace so it can be advertised and reached by internal unicast 526 routing mechanism. However, for MSDP peer-RPF checking to work 527 properly across sites, the RP addresses must be converted or 528 mapped into a routable address that is advertised and maintained 529 in the BGP routing tables in the core. MSDP peering addresses can 530 come out of either the EID or a routable address namespace. And 531 the choice can be made unilaterally because the ITR at the site 532 will determine which namespace the destination peer address is out 533 of by looking in the mapping database service. 535 PIM-SSM: In the simplest form of distribution tree building, when 536 PIM operates in SSM mode, a source distribution tree is built and 537 maintained across site boundaries. In this case, there is a small 538 modification to the operation of the PIM protocol (but not to any 539 message format) to support taking a Join/Prune message originated 540 inside of a LISP site with embedded addresses from the EID 541 namespace and converting them to addresses from the RLOC namespace 542 when the Join/Prune message crosses a site boundary. This is 543 similar to the requirements documented in [MNAT]. 545 PIM-Bidir: Bidirectional PIM is typically run inside of a routing 546 domain, but if deployed in an inter-domain environment, one would 547 have to decide if the RP address of the shared-tree would be from 548 the EID namespace or the RLOC namespace. If the RP resides in a 549 site-based router, then the RP address is from the EID namespace. 550 If the RP resides in the core where RLOC addresses are routed, 551 then the RP address is from the RLOC namespace. This could be 552 easily distinguishable if the EID address were well-known address 553 allocation block from the RLOC namespace. Also, when using 554 Embedded-RP for RP determination [RFC3956], the format of the 555 group address could indicate the namespace the RP address is from. 556 However, refer to Section 10 for considerations core routers need 557 to make when using Embedded-RP IPv6 group addresses. With respect 558 to DF-election in Bidir PIM, no changes are required since all 559 messaging and addressing is link-local. 561 PIM-ASM: The way ASM mode PIM, the most popular form of PIM, is 562 deployed in the Internet today is by having shared-trees within a 563 site and using source-trees across sites. By the use of MSDP and 564 PIM-SSM techniques described above, we can get multicast 565 connectivity across LISP sites. Having said that, that means 566 there are no special actions required for processing (*,G) or 567 (S,G,R) Join/Prune messages since they all operate against the 568 shared-tree which is site resident. This is also true for the RP- 569 mapping mechanisms Auto-RP and BSR. 571 Based on the protocol description above, the conclusion is that there 572 are no protocol message format changes, just a translation function 573 performed at the control-plane. This will make for an easier and 574 faster transition for LISP since fewer components in the network have 575 to change. 577 It should also be stated just like it is in [LISP] that no host 578 changes, whatsoever, are required to have a multicast source host 579 send multicast packets and for a multicast receiver host to receive 580 multicast packets. 582 8. LISP-Multicast Data-Plane Architecture 584 The LISP-Multicast data-plane operation conforms to the operation and 585 packet formats specified in [LISP]. However, encapsulating a 586 multicast packet from an ITR is a much simpler process. The process 587 is simply to copy the inner group address to the outer destination 588 address. And to have the ITR use its own IP address (its RLOC), and 589 as the source address. The process is simpler for multicast because 590 there is no EID-to-RLOC mapping lookup performed during packet 591 forwarding. 593 In the decapsulation case, the ETR simply removes the outer header 594 and performs a multicast routing table lookup on the inner header 595 (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is 596 used to replicate the packet on site-facing interfaces leading to 597 multicast receiver hosts. 599 There is no Data-Probe logic for ETRs as there can be in the unicast 600 forwarding case. 602 8.1. ITR Forwarding Procedure 604 The following procedure is used by an ITR, when it receives a 605 multicast packet from a source inside of its site: 607 1. A multicast data packet sent by a host in a LISP site will have 608 the source address equal to the host's EID and the destination 609 address equal to the group address of the multicast group. It is 610 assumed the group information is obtained by current methods. 611 The same is true for a multicast receiver to obtain the source 612 and group address of a multicast flow. 614 2. When the ITR receives a multicast packet, it will have both S-EID 615 state and S-RLOC state stored. Since the packet was received on 616 a site-facing interface, the RPF lookup is based on the S-EID 617 state. If the RPF check succeeds, then the oif-list contains 618 interfaces that are site-facing and external-facing. For the 619 site-facing interfaces, no LISP header is prepended. For the 620 external-facing interfaces a LISP header is prepended. When the 621 ITR prepends a LISP header, it uses its own RLOC address as the 622 source address and copies the group address supplied by the IP 623 header the host built as the outer destination address. 625 8.2. ETR Forwarding Procedure 627 The following procedure is used by an ETR, when it receives a 628 multicast packet from a source outside of its site: 630 1. When a multicast data packet is received by an ETR on an 631 external-facing interface, it will do an RPF lookup on the S-RLOC 632 state it has stored. If the RPF check succeeds, the interfaces 633 from the oif-list are used for replication to interfaces that are 634 site-facing as well as interfaces that are external-facing (this 635 ETR can also be a transit multicast router for receivers outside 636 of its site). When the packet is to be replicated for an 637 external-facing interface, the LISP encapsulation header are not 638 stripped. When the packet is replicated for a site-facing 639 interface, the encapsulation header is stripped. 641 2. The packet without a LISP header is now forwarded down the 642 (S-EID,G) distribution tree in the receiver multicast site. 644 8.3. Replication Locations 646 Multicast packet replication can happen in the following topological 647 locations: 649 o In an IGP multicast router inside a site which operates on S-EIDs. 651 o In a transit multicast router inside of the core which operates on 652 S-RLOCs. 654 o At one or more ETR routers depending on the path a Join/Prune 655 message exits a receiver multicast site. 657 o At one or more ITR routers in a source multicast site depending on 658 what priorities are returned in a Map-Reply to receiver multicast 659 sites. 661 In the last case the source multicast site can do replication rather 662 than having a single exit from the site. But this only can occur 663 when the priorities in the Map-Reply are modified for different 664 receiver multicast site so that the PIM Join/Prune messages arrive at 665 different ITRs. 667 This policy technique, also used in [ALT] for unicast, is useful for 668 multicast to mitigate the problems of changing distribution tree 669 state as discussed in Section 6. 671 9. LISP-Multicast Interworking 673 This section will describe the multicast corollary to [INTWORK] which 674 describes the interworking of multicast routing among LISP and non- 675 LISP sites. 677 9.1. LISP and non-LISP Mixed Sites 679 Since multicast communication can involve more than two entities to 680 communicate together, the combinations of interworking scenarios are 681 more involved. However, the state maintained for distribution trees 682 at the sites is the same regardless of whether or not the site is 683 LISP enabled or not. So most of the implications are in the core 684 with respect to storing routable EID prefixes from either PA or PI 685 blocks. 687 Before we enumerate the multicast interworking scenarios, we must 688 define 3 deployment states of a site: 690 o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it 691 does today. The addresses for the site are globally routable. 693 o A site that deploys LISP for unicast routing. The addresses for 694 the site are not globally routable. Let's define the name for 695 this type of site as a uLISP site. 697 o A site that deploys LISP for both unicast and multicast routing. 698 The addresses for the site are not globally routable. Let's 699 define the name for this type of site as a LISP-Multicast site. 701 We will not consider a LISP site enabled for multicast purposes only 702 but do consider a uLISP site as documented in [INTWORK]. In this 703 section we don't discuss how a LISP site sends multicast packets when 704 all receiver sites are LISP-Multicast enabled; that has been 705 discussed in previous sections. 707 The following scenarios exist to make LISP-Multicast sites interwork 708 with non-LISP-Multicast sites: 710 1. A LISP site must be able to send multicast packets to receiver 711 sites which are a mix of non-LISP sites and uLISP sites. 713 2. A non-LISP site must be able to send multicast packets to 714 receiver sites which are a mix of non-LISP sites and uLISP sites. 716 3. A non-LISP site must be able to send multicast packets to 717 receiver sites which are a mix of LISP sites, uLISP sites, and 718 non-LISP sites. 720 4. A uLISP site must be able to send multicast packets to receiver 721 sites which are a mix of LISP sites, uLISP sites, and non-LISP 722 sites. 724 5. A LISP site must be able to send multicast packets to receiver 725 sites which are a mix of LISP sites, uLISP sites, and non-LISP 726 sites. 728 9.1.1. LISP Source Site to non-LISP Receiver Sites 730 In the first scenario, a site is LISP capable for both unicast and 731 multicast traffic and as such operates on EIDs. Therefore there is a 732 possibility that the EID prefix block is not routable in the core. 733 For LISP receiver multicast sites this isn't a problem but for non- 734 LISP or uLISP receiver multicast sites, when a PIM Join/Prune message 735 is received by the edge router, it has no route to propagate the 736 Join/Prune message out of the site. This is no different than the 737 unicast case that LISP-NAT in [INTWORK] solves. 739 LISP-NAT allows a unicast packet that exits a LISP site to get its 740 source address mapped to a globally routable address before the ITR 741 realizes that it should not encapsulate the packet destined to a non- 742 LISP site. For a multicast packet to leave a LISP site, distribution 743 tree state needs to be built so the ITR can know where to send the 744 packet. So the receiver multicast sites need to know about the 745 multicast source host by its routable address and not its EID 746 address. When this is the case, the routable address is the 747 (S-RLOC,G) state that is stored and maintained in the core routers. 748 It is important to note that the routable address for the host cannot 749 be the same as an RLOC for the site. Because we want the ITRs to 750 process a received PIM Join/Prune message from an external-facing 751 interface to be propagated inside of the site so the site-part of the 752 distribution tree is built. 754 Using a globally routable source address allows non-LISP and uLISP 755 multicast receiver to join, create, and maintain a multicast 756 distribution tree. However, the LISP multicast receiver site will 757 want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ 758 Prune message is received on a site-facing interface. It does this 759 because it wants to find a (S-RLOC,G) entry to Join in the core. So 760 we have a conflict of behavior between the two types of sites. 762 The solution to this problem is the same as when an ITR wants to send 763 a unicast packet to a destination site but needs determine if the 764 site is LISP capable or not. When it is not LISP capable, the ITR 765 does not encapsulate the packet. So for the multicast case, when ETR 766 receives a PIM Join/Prune message for (S-EID,G) state, it will do a 767 mapping table lookup on S-EID. In this case, S-EID is not in the 768 mapping database because the source multicast site is using a 769 routable address and not an EID prefix address. So the ETR knows to 770 simply propagate the PIM Join/Prune message to a external-facing 771 interface without converting the (S-EID,G) because it is an (S,G) 772 where S is routable and reachable via core routing tables. 774 Now that the multicast distribution tree is built and maintained from 775 any non-LISP or uLISP receiver multicast site, the way packet 776 forwarding model is performed can be explained. 778 Since the ITR in the source multicast site has never received a 779 unicast PIM Join/Prune message from any ETR in a receiver multicast 780 site, it knows there are no LISP-Multicast receiver sites. 781 Therefore, there is no need for the ITR to encapsulate data. Since 782 it will know a priori (via configuration) that its site's EIDs are 783 not routable, it assumes that the multicast packets from the source 784 host are sent by a routable address. That is, it is the 785 responsibility of the multicast source host's system administrator to 786 ensure that the source host sends multicast traffic using a routable 787 source address. When this happens, the ITR acts simply as a router 788 and forwards the multicast packet like an ordinary multicast router. 790 There is an alternative to using a LISP-NAT scheme just like there is 791 for unicast [INTWORK] forwarding by using Proxy Tunnel Routers 792 (PTRs). This can work the same way for multicast routing as well, 793 but the difference is that non-LISP and uLISP sites will send PIM 794 Join/Prune messages for (S-EID,G) which make their way in the core to 795 PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). 796 Since the PTRs advertise very coarse EID prefixes, they draw the PIM 797 Join/Prune control traffic making them the target of the distribution 798 tree. To get multicast packets from the LISP source multicast sites, 799 the tree needs to be built on the path from the mPTR to the LISP 800 source multicast site. To make this happen the mPTR acts as a "Proxy 801 ETR" (where in unicast it acts as a "Proxy ITR"). 803 The existence of mPTRs in the core allows LISP source multicast site 804 ITRs to encapsulate multicast packets so the state built between the 805 ITRs and the mPTRs is (S-RLOC,G) state. Then the mPTRs can 806 decapsulate packets and forward natively to the non-LISP and uLISP 807 receiver multicast sites. 809 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 811 Clearly non-LISP multicast sites can send multicast packets to non- 812 LISP receiver multicast sites. That is what they do today. However, 813 discussion is required to show how non-LISP multicast sites send 814 multicast packets to uLISP receiver multicast sites. 816 Since uLISP receiver multicast sites are not targets of any (S,G) 817 state, they simply send (S,G) PIM Join/Prune messages toward the non- 818 LISP source multicast site. Since the source multicast site, in this 819 case has not been upgraded to LISP, all multicast source host 820 addresses are routable. So this case is simplified to where a uLISP 821 receiver multicast site looks to the source multicast site as a non- 822 LISP receiver multicast site. 824 9.1.3. Non-LISP Source Site to Any Receiver Site 826 When a non-LISP source multicast site has receivers in either a non- 827 LISP/uLISP site or a LISP site, one needs to decide how the LISP 828 receiver multicast site will attach to the distribution tree. We 829 know from Section 9.1.2 that non-LISP and uLISP receiver multicast 830 sites can join the distribution tree, but a LISP receiver multicast 831 site ETR will need to know if the source address of the multicast 832 source host is routable or not. We showed in Section 9.1.1 that an 833 ETR, before it sends a PIM Join/Prune message on an external-facing 834 interface, does a EID-to-RLOC mapping lookup to determine if it 835 should convert the (S,G) state from a PIM Join/Prune message received 836 on a site-facing interface to a (S-RLOC,G). If the lookup fails, the 837 ETR can conclude the source multicast site is a non-LISP site so it 838 simply forwards the Join/Prune message (it also doesn't need to send 839 a unicast Join/Prune message because there is no ITR in a non-LISP 840 site and there is namespace continuity between the ETR and source). 842 9.1.4. Unicast LISP Source Site to Any Receiver Sites 844 In the last section, it was explained how an ETR in a multicast 845 receiver site can determine if a source multicast site is LISP- 846 enabled by looking into the mapping database. When the source 847 multicast site is a uLISP site, it is LISP enabled but the ITR, by 848 definition is not capable of doing multicast encapsulation. So for 849 the purposes of multicast routing, the uLISP source multicast site is 850 treated as non-LISP source multicast site. 852 Non-LISP receiver multicast sites can join distribution trees to a 853 uLISP source multicast site since the source site behaves, from a 854 forwarding perspective, as a non-LISP source site. This is also the 855 case for a uLISP receiver multicast site since the ETR does not have 856 multicast functionality built-in or enabled. 858 Special considerations are required for LISP receiver multicast sites 859 since they think the source multicast site is LISP capable, the ETR 860 cannot know if ITR is LISP-Multicast capable. To solve this problem, 861 each mapping database entry will have a multicast 2-tuple (Mpriority, 862 Mweight) per RLOC. When the Mpriority is set to 255, the site is 863 considered not multicast capable. So an ETR in a LISP receiver 864 multicast site can distinguish whether a LISP source multicast site 865 is LISP-Multicast site from a uLISP site. 867 9.1.5. LISP Source Site to Any Receiver Sites 869 When a LISP source multicast site has receivers in LISP, non-LISP, 870 and uLISP receiver multicast sites, it has a conflict about how it 871 sends multicast packets. The ITR can either encapsulate or natively 872 forward multicast packets. Since the receiver multicast sites are 873 heterogeneous in their behavior, one packet forwarding mechanism 874 cannot satisfy both. However, if a LISP receiver multicast site acts 875 like a uLISP site then it could receive packets like a non-LISP 876 receiver multicast site making all receiver multicast sites have 877 homogeneous behavior. However, this poses the following issues: 879 o LISP-NAT techniques with routable addresses would be required in 880 all cases. 882 o Or alternatively, mPTR deployment would be required forcing coarse 883 EID prefix advertisement in the core. 885 o But what is most disturbing is that when all sites that 886 participate are LISP-Multicast sites but then a non-LISP or uLISP 887 site joins the distribution tree, then the existing joined LISP 888 receiver multicast sites would have to change their behavior. 889 This would create too much dynamic tree-building churn to be a 890 viable alternative. 892 So the solution space options are: 894 1. Make the LISP ITR in the source multicast site send two packets, 895 one that is encapsulated with (S-RLOC,G) to reach LISP receiver 896 multicast sites and another that is not encapsulated with 897 (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 899 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to 900 reach LISP-Multicast sites and to reach mPTRs that can 901 decapsulate and forward (S-EID,G) packets to non-LISP and uLISP 902 receiver multicast sites. 904 9.2. LISP Sites with Mixed Address Families 906 A LISP database mapping entry that describes the locator-set, 907 Mpriority and Mweight per locator address (RLOC), for an EID prefix 908 associated with a site could have RLOC addresses in either IPv4 or 909 IPv6 format. When a mapping entry has a mix of RLOC formatted 910 addresses, it is an implicit advertisement by the site that it is a 911 dual-stack site. That is, the site can receive IPv4 or IPv6 unicast 912 packets. 914 To distinguish if the site can receive dual-stack unicast packets as 915 well as dual-stack multicast packets, the Mpriority value setting 916 will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format 917 details. 919 If you consider the combinations of LISP, non-LISP, and uLISP sites 920 sharing the same distribution tree and considering the capabilities 921 of supporting IPv4, IPv6, or dual-stack, the number of total 922 combinations grows beyond comprehension. 924 Using some combinatorial math, we have the following profiles of a 925 site and the combinations that can occur: 927 1. LISP-Multicast IPv4 Site 929 2. LISP-Multicast IPv6 Site 931 3. LISP-Multicast Dual-Stack Site 933 4. uLISP IPv4 Site 935 5. uLISP IPv6 Site 937 6. uLISP Dual-Stack Site 939 7. non-LISP IPv4 Site 941 8. non-LISP IPv6 Site 943 9. non-LISP Dual-Stack Site 945 Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to 946 illustrate some combinatorial math below. 948 When 1 site talks to another site, the combinatorial is (9 2), when 1 949 site talks to another 2 sites, the combinatorial is (9 3). If sum 950 this up to (9 9), we have: 952 (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = 954 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 956 Which results in the total number of cases to be considered at 502. 958 This combinatorial gets even worse when you consider a site using one 959 address family inside of the site and the xTRs use the other address 960 family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 961 RLOCs). 963 To rationalize this combinatorial nightmare, there are some 964 guidelines which need to be put in place: 966 o Each distribution tree shared among sites will either be an IPv4 967 distribution tree or an IPv6 distribution tree. Therefore, we can 968 avoid head-end replication by building and sending packets on each 969 address family based distribution tree. Even though there might 970 be an urge to do multicast packet translation from one address 971 family format to the other, it is a non-viable over-complicated 972 urge. 974 o All LISP sites on a multicast distribution tree must share a 975 common address family which is determined by the source site's 976 locator-set in its LISP database mapping entry. All receiver 977 multicast sites will use the best RLOC priority controlled by the 978 source multicast site. This is true when the source site is 979 either LISP-Multicast or uLISP capable. This means that priority- 980 based policy modification is prohibited. 982 o When the source site is not LISP capable, it is up to how 983 receivers find the source and group information for a multicast 984 flow. That mechanism decides the address family for the flow. 986 9.3. Making a Multicast Interworking Decision 988 This Multicast Interworking section has shown all combinations of 989 multicast connectivity that could occur. As you might have already 990 concluded, this can be quite complicated and if the design is too 991 ambitious, the dynamics of the protocol could cause a lot of 992 instability. 994 The trade-off decisions are hard to make and we want the same single 995 solution to work for both IPv4 and IPv6 multicast. It is imperative 996 to have an incrementally deployable solution for all of IPv4 unicast 997 and multicast and IPv6 unicast and multicast while minimizing (or 998 eliminating) both unicast and multicast EID namespace state. 1000 Therefore the design decision to go with PTRs for unicast routing and 1001 mPTRs for multicast routing seems to be the sweet spot in the 1002 solution space so we can optimize state requirements and avoid head- 1003 end data replication at ITRs. 1005 10. Considerations when RP Addresses are Embedded in Group Addresses 1007 When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a 1008 technique exists to embed the unicast address of an RP in a IPv6 1009 group address [RFC3956]. When routers in end sites process a PIM 1010 Join/Prune message which contain an embedded-RP group address, they 1011 extract the RP address from the group address and treat it from the 1012 EID namespace. However, core routers do not have state for the EID 1013 namespace, need to extract an RP address from the RLOC namespace. 1015 Therefore, it is the responsibility of ETRs in multicast receiver 1016 sites to map the group address into a group address where the 1017 embedded-RP address is from the RLOC namespace. The mapped RP- 1018 address is obtained from a EID-to-RLOC mapping database lookup. The 1019 ETR will also send a unicast (*,G) Join/Prune message to the ITR so 1020 the branch of the distribution tree from the source site resident RP 1021 to the ITR is created. 1023 This technique is no different than the techniques described in this 1024 specification for translating (S,G) state and propagating Join/Prune 1025 messages into the core. The only difference is that the (*,G) state 1026 in Join/Prune messages are mapped because they contain unicast 1027 addresses encoded in an Embedded-RP group address. 1029 11. Taking Advantage of Upgrades in the Core 1031 If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], 1032 then we can pass EID specific data through the core without, 1033 possibly, having to store the state in the core. 1035 By doing this we can eliminate the ETR from unicasting PIM Join/Prune 1036 messages to the source site's ITR. 1038 12. Security Considerations 1040 Refer to the [LISP] specification. 1042 13. Acknowledgments 1044 The authors would like to gratefully acknowledge the people who have 1045 contributed discussion, ideas, and commentary to the making of this 1046 proposal and specification. People who provided expert review were 1047 Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from 1048 discussions at Summer 2008 Dublin IETF were Toerless Eckert and 1049 Ijsbrand Wijnands. 1051 We would also like to thank the MBONED working group for constructive 1052 and civil verbal feedback when this draft was presented at the Fall 1053 2008 IETF in Minneapolis. In particular, good commentary came from 1054 Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, 1055 Ron Bonica, and Lenny Guardino. 1057 14. References 1059 14.1. Normative References 1061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1062 Requirement Levels", BCP 14, RFC 2119, March 1997. 1064 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1065 Protocol (MSDP)", RFC 3618, October 2003. 1067 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1068 Point (RP) Address in an IPv6 Multicast Address", 1069 RFC 3956, November 2004. 1071 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1072 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1073 Protocol Specification (Revised)", RFC 4601, August 2006. 1075 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1076 Group Management Protocol Version 3 (IGMPv3) and Multicast 1077 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1078 Specific Multicast", RFC 4604, August 2006. 1080 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1081 IP", RFC 4607, August 2006. 1083 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1084 "Multiprotocol Extensions for BGP-4", RFC 4760, 1085 January 2007. 1087 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1088 "Bidirectional Protocol Independent Multicast (BIDIR- 1089 PIM)", RFC 5015, October 2007. 1091 14.2. Informative References 1093 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1094 Topology (LISP-ALT)", draft-fuller-lisp-alt-02.txt (work 1095 in progress), April 2008. 1097 [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1098 with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt 1099 (work in progress), December 2007. 1101 [JOIN-ATTR] 1102 Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM 1103 messages", draft-ietf-pim-join-attributes-03.txt (work in 1104 progress), May 2007. 1106 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 1107 "Locator/ID Separation Protocol (LISP)", 1108 draft-farinacci-lisp-10.txt (work in progress), 1109 November 2008. 1111 [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a 1112 Network Address (and port) Translator (NAT)", 1113 draft-ietf-behave-multicast-07.txt (work in progress), 1114 June 2007. 1116 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1117 TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), 1118 February 2008. 1120 Authors' Addresses 1122 Dino Farinacci 1123 cisco Systems 1124 Tasman Drive 1125 San Jose, CA 1126 USA 1128 Email: dino@cisco.com 1130 Dave Meyer 1131 cisco Systems 1132 Tasman Drive 1133 San Jose, CA 1134 USA 1136 Email: dmm@cisco.com 1138 John Zwiebel 1139 cisco Systems 1140 Tasman Drive 1141 San Jose, CA 1142 USA 1144 Email: jzwiebel@cisco.com 1146 Stig Venaas 1147 Uninett 1148 Abels gate 5, 4th Floor 1149 N-7465, Trondheim 1150 Norway 1152 Email: Stig.Venaas@uninett.no 1154 Full Copyright Statement 1156 Copyright (C) The IETF Trust (2008). 1158 This document is subject to the rights, licenses and restrictions 1159 contained in BCP 78, and except as set forth therein, the authors 1160 retain all their rights. 1162 This document and the information contained herein are provided on an 1163 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1164 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1165 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1166 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1167 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1168 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1170 Intellectual Property 1172 The IETF takes no position regarding the validity or scope of any 1173 Intellectual Property Rights or other rights that might be claimed to 1174 pertain to the implementation or use of the technology described in 1175 this document or the extent to which any license under such rights 1176 might or might not be available; nor does it represent that it has 1177 made any independent effort to identify any such rights. Information 1178 on the procedures with respect to rights in RFC documents can be 1179 found in BCP 78 and BCP 79. 1181 Copies of IPR disclosures made to the IETF Secretariat and any 1182 assurances of licenses to be made available, or the result of an 1183 attempt made to obtain a general license or permission for the use of 1184 such proprietary rights by implementers or users of this 1185 specification can be obtained from the IETF on-line IPR repository at 1186 http://www.ietf.org/ipr. 1188 The IETF invites any interested party to bring to its attention any 1189 copyrights, patents or patent applications, or other proprietary 1190 rights that may cover technology that may be required to implement 1191 this standard. Please address the information to the IETF at 1192 ietf-ipr@ietf.org. 1194 Acknowledgment 1196 Funding for the RFC Editor function is provided by the IETF 1197 Administrative Support Activity (IASA).