idnits 2.17.1 draft-ietf-mboned-iesg-gap-analysis-00.txt: ** The Abstract section seems to be numbered -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(86): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 2003) is 7328 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 99 looks like a reference -- Missing reference section? 'RFC 1075' on line 233 looks like a reference -- Missing reference section? 'ARP' on line 549 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editors: D. Meyer 2 Sprint 3 Document: B. Nickless 4 draft-ietf-mboned-iesg-gap-analysis-00.txt Argonne National 5 Laboratory 6 Expires: July 2002 7 January 2003 9 Internet Multicast Gap Analysis 10 from the MBONED Working Group 11 for the IESG 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 An overview of IP multicast as deployed in the Internet today, from 37 the perspective of the MBONED working group. Existing 38 infrastructure is examined critically. Suggestions for possible 39 improvement of the overall architecture are presented for the IESG. 41 3. Table of Contents 43 1. Status of this Memo.............................................1 44 2. Abstract........................................................1 45 4. Overview and Background.........................................2 46 5. Conventions used in this document...............................2 47 6. RFC 1112........................................................3 48 7. Source-Specific Multicast.......................................3 49 8. Host Extensions for IP Multicast................................3 51 Meyer, 52 9. Mapping of Multicast Group Addresses to Ethernet MAC Addresses..4 53 10. Local Subnet Receiver Interest Protocol (IGMP).................4 54 11. Collision-Sense Media Access Sender Model......................4 55 12. Multicast Gateways.............................................5 56 13. Dense Mode Internet Multicast Routing..........................5 57 14. Reachability Protocol Independent Multicast Routing............6 58 15. Sparse Mode Internet Multicast Routing.........................7 59 16. Mixed Dense/Sparse Mode Internet Multicast Routing.............7 60 17. Bursty Sources vs. Sparse Mode Forwarding State Maintenance....8 61 18. Co-mingled Source Knowledge and Packet Forwarding..............8 62 19. Co-mingled IP and Ethernet Routing.............................9 63 20. Inter-Domain IP Multicast Exchange Points......................9 64 21. IP Multicast Architectural Gaps...............................11 65 22. Recommendations from MBONED to IESG...........................11 66 23. Acknowledgements..............................................13 67 24. Security Considerations.......................................13 68 25. References....................................................14 69 26. Editors� Addresses............................................14 71 4. Overview and Background 73 At the IETF-54 meeting, the MBONED working group recommended that 74 the MSDP working group publish their current work as an 75 Informational RFC and shut down. Some participants in the MBONED 76 and MSDP working groups believed that the recurring discussions 77 about the operation of MSDP were proxy arguments about the IP 78 Multicast service model, and how that model can be supported in the 79 Internet. Participants came to rough consensus that the best place 80 for these overall service model and deployment questions is the 81 MBONED working group. 83 A two phase approach was adopted. The short-term objective is to 84 document existing MSDP implementations and deployments. A longer- 85 term objective for the MBONED working group is to perform a �gap 86 analysis� of the existing IP multicast service model, protocols, and 87 deployment. 89 This document represents that �gap analysis,� and is intended as 90 advice to IESG. The MBONED participants hope the IESG will consider 91 this advice in the context of IESG guidance for further IP multicast 92 protocol development and deployment work. 94 5. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in RFC-2119 [1]. 100 Meyer, 101 6. RFC 1112 103 The seminal specification for IP Multicast is RFC 1112. It 104 describes five elements required for IP Multicast on a local subnet: 105 extensions to host software, an IPv4 address range reserved for 106 group addresses, a method for mapping multicast group addresses to 107 Ethernet Media Access Control (MAC) addresses, a protocol to 108 discover receivers interested in packets addressed to a group 109 (Internet Group Management Protocol), and a collision-sense multiple 110 access (CSMA) method for multicast packet senders. 112 This model was inspired by Ethernet. The IEEE 802.3 Ethernet 113 specification includes a bit in the MAC address format that 114 indicates the frame may be intended for multiple receivers. 115 Ethernet interfaces can be programmed to receive these multicast MAC 116 addresses and forward them to the host for processing. On a 117 traditional 10Base5 Ethernet, any station can put a frame on the 118 wire, with the only requirement being to sense collisions and 119 retransmit if necessary. 121 RFC 1112 also suggests that gateways may exist for moving IP 122 multicast datagrams to other subnets with interested receivers. 124 The RFC 1112 service model has since become known as Any Source 125 Multicast (ASM). When a receiver registers interest in a group, it 126 will be delivered datagrams from any source that transmits datagrams 127 addressed to that group. 129 7. Source-Specific Multicast 131 Just as early Ethernet controllers were programmable to only receive 132 frames with certain MAC addresses, RFC 1112 and IGMP Version 2 only 133 allowed IP Multicast receivers to elect to receive datagrams 134 addressed to specific group addresses. Receivers could not select 135 the sources participating in a group from which they would receive. 137 Later Ethernet controllers allowed more sophisticated filtering, 138 including the capability of choosing from which senders the host 139 wished to accept frames. Similarly, Source-Specific Multicast (SSM) 140 is an extension to the basic IP multicast model that allows 141 receivers to select the source addresses from which to receive 142 datagrams. IGMP Version 3 implements this service model extension 143 for IPv4, and the Multicast Listener Discovery (MLD) protocol 144 Version 2 implements this service model extension for IPv6. 146 8. Host Extensions for IP Multicast 148 Ultimately, user applications originate and accept IP multicast 149 datagrams. RFC 1112 describes the extensions to various host 150 software modules to support applications sending and receiving 152 Meyer, 153 datagrams. It also describes the operations a user application can 154 perform to transmit and receive multicast datagrams. 156 9. Mapping of Multicast Group Addresses to Ethernet MAC Addresses 158 When preparing an IP datagram for transmission on an Ethernet, it is 159 necessary for the host to specify the destination MAC address. (The 160 source MAC address is typically constant, based on the IEEE- 161 controlled address hard-wired into the Ethernet controller.) Before 162 sending unicast datagrams, the Address Resolution Protocol (ARP) is 163 generally used by a host to learn the destination MAC address for a 164 given destination IPv4 address. RFC 2461 describes the equivalent 165 Neighbor Discovery protocol procedure used for IPv6. 167 IPv4 multicast datagrams are not addressed to specific host 168 addresses; instead, they are addressed to group addresses in the 169 224.0.0.0/4 range. Likewise, IPv6 multicast datagrams are addressed 170 to group addresses in the FF00::/8 range. 172 RFC 1112 specifies a static 32:1 mapping from IPv4 multicast group 173 addresses to Ethernet MAC addresses. One reason to define the 32:1 174 mapping was financial; to reserve enough Ethernet MAC addresses from 175 the IEEE for a 1:1 mapping would have cost USD$16,000 in 1988. The 176 32:1 mapping reduced that cost to USD$1,000. 178 RFC 2464 (section 7) specifies a static 2^96:1 (that is, 179 79,228,162,514,264,337,593,543,950,336:1) mapping from IPv6 180 multicast group addresses to Ethernet MAC addresses. Note that it 181 is impossible to determine the RFC 2375 scope directly from the 182 Ethernet 802.3 MAC address, as the RFC 2464 mapping does not include 183 the scope octet. 185 10. Local Subnet Receiver Interest Protocol (IGMP) 187 RFCs 1112 and 2236 define the Internet Group Management Protocol 188 (IGMP) Version 2. IGMPv2 notifies the network of the interest of a 189 host for datagrams addressed to a given group address. Again, this 190 is analogous to a host notifying an Ethernet controller to accept 191 frames with a given MAC address. 193 The IPv6 equivalent of IGMP is the Multicast Listener Discovery 194 Protocol (MLD), originally defined in RFC 2710. 196 11. Collision-Sense Media Access Sender Model 198 Any host connected to a 10Base5 Ethernet can choose to transmit a 199 frame at any time, subject only to the operation of the collision- 200 sense media access (CSMA) protocol. 202 Meyer, 203 Given the static mapping of IPv4 group addresses to Ethernet MAC 204 addresses, RFC 1112 specifies that an IPv4 datagram, addressed to a 205 multicast group, can be transmitted by a host at any time. 207 Similarly, RFC 2464 implies that an IPv6 datagram addressed to a 208 multicast group can be transmitted by a host at any time. 210 12. Multicast Gateways 212 RFC 1112 suggested that gateways might exist to pass multicast 213 traffic between networks. Through the operation of the local subnet 214 receiver interest protocol IGMP, these gateways can learn of the 215 interest of receivers in multicast group datagrams. 217 As the technology for internetwork routing was unknown at the time 218 of publication, RFC 1112 does not specify how that routing is to 219 take place. 221 13. Dense Mode Internet Multicast Routing 223 Following the Ethernet broadcast model, the first scheme for routing 224 IP multicast datagrams between Ethernets was for a multi-homed 225 gateway to flood all multicast datagrams on each Ethernet to all 226 other Ethernets. In other words, gateways become the IP multicast 227 equivalent of Ethernet repeaters. 229 Ethernet bridges generally run the Spanning Tree Protocol (IEEE 230 Specification 802.1d) to eliminate forwarding loops. Forwarding 231 loops can also happen when there is more than one multi-homed 232 gateway in an internetwork. The Distance Vector Multicast Routing 233 Protocol (DVMRP) [RFC 1075] operates to eliminate forwarding loops. 234 DVMRP, operating on a gateway, keeps track of the Reverse Path 235 Forwarding (RPF) interface from which a multicast datagram with a 236 given source address should arrive. If such multicast datagrams 237 arrive on the appropriate RPF interfaces, they are replicated and 238 flooded to all other interfaces by the gateway. 240 The effect of this procedure is to replicate all IP multicast 241 datagrams transmitted by any host to all subnets. This limits the 242 available bandwidth for all multicast traffic in the internetwork to 243 that bandwidth available on the slowest link. 245 One optimization to this procedure is for gateways to use a receiver 246 interest protocol such as IGMP to limit traffic flooded out an 247 interface. Only if there are receivers interested in a group, on a 248 network attached to a given interface, will the gateway flood 249 datagrams addressed to that group out that interface. Of course, 250 gateways are generally assumed by fellow gateways to be interested 251 in all groups, so this optimization does not apply to networks with 252 more than one gateway. 254 Meyer, 255 A second optimization further limits flooding. Consider a situation 256 where a gateway has no interested receivers on all attached networks 257 for a given group, yet receives an IP multicast datagram addressed 258 to that group. DVMRP provides for gateways to send Prune messages 259 out the appropriate RPF interface to notify fellow gateways that 260 they have no interested receivers. 262 A third optimization provides for this limiting process to continue 263 recursively. Once a gateway receives Prune messages from all other 264 gateways on a network, and has no interested hosts, it stops 265 forwarding messages out the attached interface. If all interfaces 266 have such stoppages for a given group, it can generate its own Prune 267 towards out the appropriate RPF interface to notify upstream 268 gateways to stop sending datagrams addressed to a given group. 270 Through repeated application of this procedure, the distribution of 271 multicast datagrams is limited only to the networks that have 272 attached interested receivers, and to intermediate networks between 273 sources and interested receivers. Multicast datagrams are 274 distributed down a tree rooted at the source. Vertexes of the tree 275 are the gateways, and the edges of the tree are the networks 276 connecting gateways. 278 This general strategy is known as �dense mode� multicast routing. 280 As the number of multicast sources and receivers increase, the core 281 of the multicast-enabled internetwork becomes more and more heavily 282 loaded. Fewer opportunities for pruning occur. 284 As dense mode routing was experimentally deployed, a meta-stable 285 failure mode was discovered. A gateway (or its attached network) 286 can be overwhelmed with multicast traffic. Even though the gateway 287 may have no interested receivers, it can fail to generate the 288 required number of Prune messages. Unfortunately this failure mode 289 can spread, because upstream gateways (closer to the sources) assume 290 that packet replication and transmission is required, adding to 291 their own load. Eventually the whole multicast internet collapses 292 under the weight of un-Pruned traffic. 294 14. Reachability Protocol Independent Multicast Routing 296 In addition to controlling whether forwarding occurs (based on 297 receiver interest), DVMRP maintains the topology of the forwarding 298 trees from source to receivers. As its name implies, a distance- 299 vector procedure similar to RIP is used. 301 Experience has shown that a distance-vector reachability protocol 302 does not scale for large internets. Link-state protocols such as 303 IS-IS and OSPF are generally used within administrative domains, and 304 the Border Gateway Protocol is generally used between administrative 305 domains. Convergence speed, policy flexibility, and other 306 considerations motivate this diversity of reachability protocol use. 308 Meyer, 309 The Protocol Independent Multicast (PIM) multicast routing protocol 310 takes its name from the fact that it can take its reachability 311 information from any underlying reachability protocol. PIM 312 concentrates on maintaining and controlling the multicast forwarding 313 tree along the topology provided by whatever underlying reachability 314 protocol(s) is/are used. 316 15. Sparse Mode Internet Multicast Routing 318 One way to eliminate the dense mode meta-stable failure mode is by 319 adjusting the inter-gateway forwarding procedure to require 320 downstream gateways to explicitly request datagrams for a given 321 group based on receiver interest. 323 In this regime, the forwarding tree is built from the interested 324 receivers towards the source. Datagrams from the source are 325 distributed back down the tree to the interested receivers. 327 Through IGMPv3 (or any similar SSM-style receiver interest discovery 328 protocol) the receivers provide both pieces of information necessary 329 for the internetwork to create and maintain the source-rooted 330 forwarding tree: the IP addresses of the source and multicast group. 332 16. Mixed Dense/Sparse Mode Internet Multicast Routing 334 A straightforward sparse mode forwarding protocol alone cannot 335 support the RFC 1112 Any Source Multicast service model. Although 336 the receivers supply the group address for which they�re interested 337 in receiving datagrams, the internetwork is responsible for 338 identifying active sources so the source-rooted forwarding trees can 339 be created. 341 The hybrid approach taken in RFC 2362 (PIM Sparse Mode Version 2) 342 and MSDP is to flood the initial datagrams from any sender, 343 typically under strict rate controls. When a gateway receives one 344 of these flooded datagrams from a given sender, whose group address 345 matches that of an attached interested receiver, the gateway grafts 346 itself to the source-rooted forwarding tree for that sender. 348 So long as the source continues to transmit packets, the forwarding 349 tree associated with the source is preserved. After a period of 350 quiescence the forwarding tree is torn down. 352 The result is a dual-plane routing architecture. A dense-mode, 353 rate-limited, flooding plane distributes datagrams from newly active 354 sources. A sparse-mode, source-rooted tree based forwarding plane 355 distributes and replicates datagrams from established sources. 357 Meyer, 358 17. Bursty Sources vs. Sparse Mode Forwarding State Maintenance 360 Prior to the development of the client-server-based World Wide Web, 361 a session announcement protocol (SAP) was developed to allow 362 interested parties to discover and participate in multilateral 363 multimedia conference. Periodically a multicast datagram would be 364 generated and sourced, providing the multicast group addresses, 365 media formats, and other such information needed for interested 366 parties to join the conference. 368 As in any real-world application protocol, two factors required an 369 engineering trade-off: the bandwidth consumed by the announcements 370 vs. the frequency of announcements. Recall that early internetwork 371 multicast routing used a dense mode approach; datagrams were flooded 372 everywhere unless they were explicitly known to be unwanted. Given 373 the propensity of the entire internetwork multicast infrastructure 374 to collapse under load, great emphasis was placed on limiting the 375 total bandwidth consumed by the announcements. Thus, the SAP 376 announcement frequency was often measured in tens of minutes. 378 As sparse-mode multicast routing became more widely deployed, this 379 tens-of-minutes frequency of SAP announcements became a problem. 380 Each time an SAP announcement was sourced, the sparse-mode source- 381 based distribution tree would be created towards interested 382 receivers. But due to the low frequency of each independent 383 announcement, the distribution tree would have been deemed quiescent 384 and would be torn down. 386 The resulting �bursty source� traffic would often follow only the 387 dense-mode, rate-limited flooding routing plane. The sparse-mode, 388 higher-performance forwarding plane would assume the source has gone 389 quiescent long before the next �burst�. 391 18. Co-mingled Source Knowledge and Packet Forwarding 393 There�s a chicken-and-egg problem at the heart of internetwork 394 multicast routing. On the one hand, experience has shown that a 395 source-based distribution tree is the most efficient way to forward 396 datagrams from a source to all interested listeners. On the other 397 hand, such a source-based distribution tree cannot be created until 398 the source is known, and RFC 1112 decrees that sources be able to 399 transmit at any time without warning. 401 In other words, RFC 1112 defines an active source as a source that 402 has placed a datagram on the wire. But by the time the datagram has 403 been placed on the wire, it�s too late to create a source-based 404 distribution tree to all interested receivers. 406 There have been several approaches taken to resolve this problem. 408 The first was to not use source-based distribution trees at all. 409 Unfortunately this approach resulted in an internetwork that would 410 collapse under load. 412 Meyer, 413 The second approach has been to create dual routing planes: a dense- 414 mode plane to forward the initial datagrams from a source, and as a 415 side effect create a source-based distribution tree in the sparse- 416 mode plane. Unfortunately these dual routing planes lead to a great 417 deal of complexity. 419 The third approach has been SSM: put the burden of spreading the 420 knowledge of active sources on the application rather than the 421 network. This approach has two major drawbacks: first, it requires 422 the replacement or upgrade of edge IEEE 802.x devices to support 423 IGMPv3 snooping, along with a wholesale upgrade to host operating 424 systems. Second, it requires applications to develop their own 425 rendezvous mechanisms. 427 19. Co-mingled IP and Ethernet Routing 429 For primarily historical reasons, the IETF has pushed vendors of 430 nominally IEEE 802.x compliant equipment to also become IPv4-aware 431 enough to understand the IGMP Version 2 protocol. 433 IEEE has responded with the GARP/GMRP protocol suite, which are 434 intended to allow 802.x hosts to control MAC-layer multicast 435 replication and filtering. However, the IETF has continued work on 436 IGMP and MLD while ignoring media-specific protocols like GARP/GMRP. 438 Arguably, this has marginalized IP multicast deployment, especially 439 IPv6 multicast deployment. Only the very high-end IEEE 802.x 440 devices have the sophistication to interpret IPv4/IGMP and IPv6/MLD 441 datagrams. 443 20. Inter-Domain IP Multicast Exchange Points 445 Autonomous Systems often wish to exchange traffic. Exchange points 446 have been developed to meet this demand. One popular type of 447 exchange point is realized in an 802.x Ethernet switch. Each 448 participating Autonomous System is provided an 802.x Ethernet port 449 and an IP address on the exchange point network, to which the 450 Autonomous System connects a router. Bilateral BGP sessions are 451 then established between Autonomous Systems across the 802.x network 452 fabric. 454 When an Autonomous System router wishes to deliver a unicast 455 datagram to another Autonomous System router participating at such 456 an exchange point, it follows this procedure: 458 - The datagram�s IP Destination Address is compared to the 459 Forwarding Information Base (FIB). The FIB returns a so-called 460 �next-hop� IP address. This next-hop address is generally 461 assigned to another Autonomous System�s router at the exchange 462 point. 464 Meyer, 465 - Through the operation of the Address Resolution Protocol (ARP), 466 the 802.x Ethernet MAC address associated with the next-hop IP 467 address is determined. 469 - An Ethernet frame is assembled with the destination MAC address 470 set to the MAC address determined through ARP, and is transmitted 471 to the Exchange Point 802.x Ethernet switch. 473 - The exchange point 802.x Ethernet switch examines the destination 474 MAC address of the Ethernet frame. Based on that address, the 475 exchange point switch delivers the Ethernet frame to the 476 destination Autonomous System�s router. 478 Consider an analogous procedure for multicast routing. The object 479 is to graft the Autonomous System�s router onto a source-rooted 480 distribution tree across the exchange point. Here is one procedure 481 that a downstream router can follow: 483 - The downstream router compares the source address to its Multicast 484 Reachability Information Base (M-RIB). The M-RIB returns the IP 485 address of an �upstream� router across the exchange point. 487 - Through the operation of the PIM Sparse Mode Protocol, the 488 downstream router registers interest in that source and group 489 addresses to the upstream router across the exchange point. 491 - Upon receipt of a matching datagram for the downstream router, the 492 upstream router assembles an Ethernet frame and transmits it to 493 the exchange point 802.x Ethernet switch. As per RFC 1112 or RFC 494 2464, the destination MAC address of the frame is statically 495 derived from the destination group address of the datagram. 497 - The exchange point 802.x Ethernet switch examines the destination 498 MAC address. As this MAC address is a multicast address, the 499 802.x Ethernet switch replicates this frame and sends it to all 500 output ports. 502 This presents three problems: 504 First, the multicast traffic is needlessly replicated to all 505 participants in the exchange point. In the unicast case above, the 506 802.x Ethernet exchange point switch could use the Ethernet 507 destination MAC address to uniquely identify which port should 508 receive a given frame. The static mapping of destination multicast 509 group address to Ethernet MAC addresses makes that determination 510 impossible. 512 Second, the needlessly replicated multicast traffic can trigger the 513 PIM Assert process, as per RFC 2362 Section 2.9. The PIM Assert 514 process has been observed to override the policy decisions of 515 downstream routers in exchange points. 517 Meyer, 518 Third, it is impossible for multicast traffic to pass through an 519 exchange point more than once. Any given exchange point participant 520 may not have a peering agreement with all other participants, 521 requiring an intermediate hop through a transit Autonomous System 522 participant. Due to the operation of ARP this is not a problem for 523 unicast traffic, but due to the static mapping of multicast groups 524 to (e.g.) Ethernet MAC addresses, this cannot work. 526 In summary, it is impossible to support IP multicast at an exchange 527 point, when that exchange point is based on IEEE 802.3 Ethernet. 529 21. IP Multicast Architectural Gaps 531 In general, the IETF focus is on Internet protocols. IGMP snooping 532 places the requirement of IPv4-awareness on IEEE-standardized 802.x 533 Ethernet switches. The current drafts for IPv6 MLD seek to extend 534 that requirement to include IPv6. The IESG would rightfully refuse 535 to allow IETF working groups to impose such requirements on devices 536 standardized by organizations outside the IETF (such as IEEE), but 537 somehow has excepted the IP multicast work from this discipline. 539 The Internet is more complex than a simple CSMA-style Ethernet 540 segment, where sources can transmit at any time. Experience clearly 541 indicates that internetwork multicast datagram forwarding is most 542 efficiently done by source-rooted distribution trees. Experience 543 compels revisitation of the assumption that sources should be able 544 to transmit at any time, yet receive the same level of service as 545 that provided by a fully instantiated source-rooted distribution 546 tree. 548 Registration of soon-to-be-active sources (along the lines of the 549 unicast Address Resolution Protocol [ARP]) should be seriously 550 considered. 552 Part of the registration of soon-to-be-active sources could include 553 allocation of link-local media-specific multicast addresses, rather 554 than relying solely on the static mappings defined in RFC 1112 and 555 RFC 2464. 557 The static mapping of IP multicast group addresses to media-specific 558 multicast addresses (in particular, Ethernet) cannot operate 559 properly at exchange points. 561 22. Recommendations from MBONED to IESG 563 The IESG should direct the MAGMA working group to develop a 564 successor to IGMP/MLD. 566 - The successor should perform the receiver interest discovery 567 functions of existing versions of IGMP/MLD, but in addition 568 should support the registration of active sources. 570 Meyer, 571 - At least three modes of operation should be supported. As in 572 IGMPv2/MLDv1, sources and receivers should be able to transmit 573 to and receive from group addresses without respect to the 574 identities of sources. In a second mode, analogous to 575 IGMPv3/MLDv2, receivers should be able to select the sources 576 from which they want to receive traffic for a particular group. 577 A third mode should permit receivers to select the source 578 address, group address, and upstream gateway from which to 579 receive traffic. 581 - The successor should be media-agnostic. Media-specific 582 multicast addresses should be treated as opaque handles. 583 Examples of media-specific multicast addresses might include 584 802.x MAC addresses, ATM Forum NSAP point-to-multipoint 585 addresses, etc. 587 - Adaptation layers for this successor protocol should be 588 developed to use media-specific mechanisms for multicast 589 transport and replication. For example, the IEEE 802.1p 590 GARP/GMRP protocol should be used on Ethernet. ATM Forum UNI 591 point-to-multipoint signaling should be used on ATM networks 592 (c.f. RFC 2022). 594 - This successor protocol would provide for the dynamic assignment 595 of media-specific addresses. As necessary, the media address 596 assignment mechanism might control the creation and maintenance 597 of media-specific intra-subnet distribution mechanisms, such as 598 ATM point-to-multipoint switched virtual circuits. When in 599 operation on an IEEE 802.3 Ethernet, this mechanism would 600 supercede RFC 1112 Section 6.4 and RFC 2464 Section 7. 602 - The first application for this successor protocol would be at 603 public internetwork exchange points. The third mode of 604 operation (allowing receivers to select the source address, 605 group address, and upstream gateway) would allow participants at 606 exchange points to select their upstream neighbor towards a 607 source based on explicit policy, rather than the vagaries of the 608 PIM Assert mechanisms. 610 - This successor protocol may not be applicable for IP datagrams 611 with TTL=1, so as to preserve semantics for link-local 612 rendezvous (e.g. OSPF). Likewise, it may not be applicable for 613 IPv6 RFC 2375 scopes 0, 1, and 2. 615 The IESG should encourage the development of a protocol to spread 616 the knowledge of active sources to interested gateways. Given a 617 successor to IGMP that supports the registration of active sources, 618 this spreading of knowledge can happen independently of actual 619 multicast datagram forwarding. 621 The IESG should discourage any further work on IGMP or MLD snooping, 622 as implemented by otherwise nominally IEEE 802 compliant equipment. 624 Meyer, 625 Instead, the IESG should encourage the use of GARP/GMRP on IEEE 802 626 networks. 628 The IESG should guide protocols that use IP multicast to maintain a 629 minimum frequency of datagram transmission, so as to preserve 630 source-based forwarding trees. 632 23. Acknowledgements 634 This work was supported by the Mathematical, Information, and 635 Computational Sciences Division subprogram of the Office of Advanced 636 Scientific Computing Research, U.S. Department of Energy, under 637 Contract W-31-109-Eng-38. 639 24. Security Considerations 641 Security considerations are not yet discussed in this draft memo. 643 Meyer, 644 25. References 646 Most of the references are called out in-line. This section will be 647 completed more fully before final publication. 649 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997 652 26. Editors� Addresses 654 David Meyer Email: dmm@sprint.net 656 Bill Nickless 657 Argonne National Laboratory 658 9700 South Cass Avenue #221 Phone: +1 630 252 7390 659 Argonne, IL 60439 Email: nickless@mcs.anl.gov 661 Meyer,