idnits 2.17.1 draft-ietf-ssm-overview-02.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 abstract seems to contain references ([PIM-SM-NEW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 340 has weird spacing: '...R99] is deriv...' -- 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 (4 December 2001) is 8180 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? 'RFC 2119' on line 46 looks like a reference -- Missing reference section? 'PIM-SM-NEW' on line 446 looks like a reference -- Missing reference section? 'RFC1112' on line 80 looks like a reference -- Missing reference section? 'SSM-ARCH' on line 432 looks like a reference -- Missing reference section? 'EXPRESS' on line 416 looks like a reference -- Missing reference section? 'IANA-ALLOC' on line 93 looks like a reference -- Missing reference section? 'SSM-IPv6' on line 489 looks like a reference -- Missing reference section? 'IGMPv3' on line 426 looks like a reference -- Missing reference section? 'MLDv2' on line 485 looks like a reference -- Missing reference section? 'IGMPv2' on line 320 looks like a reference -- Missing reference section? 'PIM-SM' on line 443 looks like a reference -- Missing reference section? 'MSDP' on line 454 looks like a reference -- Missing reference section? 'MBGP' on line 147 looks like a reference -- Missing reference section? 'RFC2236' on line 423 looks like a reference -- Missing reference section? 'RFC2710' on line 482 looks like a reference -- Missing reference section? 'BGP' on line 147 looks like a reference -- Missing reference section? 'GLOP00' on line 179 looks like a reference -- Missing reference section? 'MAAA' on line 457 looks like a reference -- Missing reference section? 'SSM-BCP' on line 479 looks like a reference -- Missing reference section? 'HABE1' on line 285 looks like a reference -- Missing reference section? 'THAL00' on line 316 looks like a reference -- Missing reference section? 'SSM-IGMPv3' on line 429 looks like a reference -- Missing reference section? 'DEER99' on line 340 looks like a reference -- Missing reference section? 'VIDA01' on line 342 looks like a reference -- Missing reference section? 'IANA-ALLOCATION' on line 420 looks like a reference -- Missing reference section? 'IPMULTICAST' on line 435 looks like a reference -- Missing reference section? 'PIM-ARCH' on line 439 looks like a reference -- Missing reference section? 'PIM-DM' on line 451 looks like a reference -- Missing reference section? 'MCAST-DEPLOY' on line 461 looks like a reference -- Missing reference section? 'SSM-RULES' on line 467 looks like a reference -- Missing reference section? 'MSF-API' on line 470 looks like a reference -- Missing reference section? 'RFC2770' on line 473 looks like a reference -- Missing reference section? 'RCVR-INTEREST' on line 475 looks like a reference -- Missing reference section? 'IPSEC' on line 493 looks like a reference -- Missing reference section? 'IPv6-ALLOC' on line 497 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Supratik Bhattacharyya 3 Expires 04 June 2002 Christophe Diot 4 Sprint ATL 5 Leonard Giuliano 6 Juniper Networks 7 Rob Rockell 8 Sprint E|Solutions 9 John Meylor 10 Cisco Systems 11 David Meyer 12 Sprint E|Solutions 13 Greg Shepherd 14 Juniper Networks 15 Brian Haberman 16 No Affiliation 17 4 December 2001 19 An Overview of Source-Specific Multicast(SSM) Deployment 20 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC 2119]. 47 Abstract 49 This document provides an overview of the Source-Specific Multicast 50 (SSM) service and its deployment using the PIM-SM and IGMP/MLD 51 protocols. The network layer service provided by SSM is a "channel", 52 identified by an SSM destination IP address (G) and a source IP 53 address S. The IPv4 address range 232/8 has been reserved by IANA fo 54 use by the SSM service. An SSM destination address range already 55 exists for IPv6. A source S transmits IP datagrams to an SSM 56 destination address G. A receiver can receive these datagrams by 57 subscribing to the channel (S,G). Channel subscription is supported 58 by version 3 of the IGMP protocol for IPv4 and version2 of the MLD 59 protocol for IPv6. The interdomain tree for forwarding IP multicast 60 datagrams is rooted at the source S. Although a number of protocols 61 exists for constructing source-rooted forwarding trees, this document 62 discusses one of the most widely implemented one - PIM Sparse Mode 63 [PIM-SM-NEW]. 65 This document is intended as a starting point for deploying SSM 66 services. It provides an architectural overview of SSM and describes 67 how it solves a number of problems faced in the deployment of inter- 68 domain multicast. It outlines changes to protocols and applications 69 both at end-hosts and routers for supporting SSM, with pointers to 70 more detailed documents where appropriate. Issues of interoperability 71 with the multicast service model defined by RFC 1112 are also 72 discussed. 74 1. Terminology 76 This section defines some terms that are used in the rest of this 77 document : 79 Any-Source Multicast (ASM) : This is the IP multicast service model 80 defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a 81 "host group", a set of zero or more end-hosts identified by a single 82 IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). 83 This model supports one-to-many and and many-to-many multicast groups. 84 End-hosts may join and leave the group any time, and there is no 85 restriction on their location or number. Moreover, any end-host may 86 transmit to a host group, even if it is not a member of that group. 88 Source-Specific Multicast (SSM) : This is the multicast service model 89 defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to 90 an SSM destination address G, and receivers can receive this datagram 91 by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] 92 and supports one-to-many multicast.The address range 232/8 has been 93 assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the 94 range FF3x::/96 is defined for SSM services [SSM-IPv6]. 96 Source-Filtered Multicast (SFM) : This is a variant of the multicast 97 service model defined in RFC 1112. A source transmits IP datagrams to 98 a host group address in the range of 224.0.0.0 to 239.255.255.255. 99 However, each "upper layer protocol module" can now request data sent 100 to a host group G by only a specific set of sources, or can request 101 data sent to host group G from all BUT a specific set of sources. 102 Such support for source filtering is provided by version 3 of the 103 Internet Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and 104 version 2 of the Multicast Listener Discovery (or MLD) protocol for 105 IPv6 [MLDv2]. We shall henceforth refer to these two protocols as 106 "SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and 107 MLDv1 - do not provide support for source-filtering, and are referred 108 to as "non-SFM-capable". 110 2. The IGMP/PIM-SM/MSDP/MBGP Architecture for ASM 112 All multicast-capable networks of today support the ASM service 113 model. One of the most common multicast protocol architectures for 114 supporting ASM in wide-area backbones consists of IGMP version 2 115 [IGMPv2], PIM-SM [PIM-SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP] 116 protocols. To become a member of a particular host group end-hosts 117 report multicast group membership with querier routers handling 118 multicast group membership function using the IGMP version 2 (IGMPv2) 119 protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1) protocol 120 [RFC2710] for IPv6. Routers then exchange messages with each other 121 according to a routing protocol to construct a distribution tree 122 connecting all the end-hosts. A number of different protocols exist 123 for building multicast forwarding trees, which differ mainly in the 124 type of delivery tree constructed [IPMULTICAST,PIM-ARCH, PIM-SM, PIM- 125 SM-NEW, PIM-DM]. For scalability reasons, sparse-mode protocols 126 (e.g., PIM-SM) are preferred over dense-mode protocols (e.g., DVMRP, 127 PIM-DM) for deployment in large backbone networks (though many 128 smaller networks deploy dense-mode protocols). PIM-SM, most widely 129 deployed sparse-mode protocol, builds a spanning multicast tree 130 rooted at a core rendezvous point or RP for all group members within 131 a single administrative domain. Multicast sources within this domain 132 send their data to this RP which forwards the data down the shared 133 tree to interested receivers within the domain. As of this writing, 134 multicast end-hosts with SFM capabilities are not widely available. 135 Hence a client can only specify interest in an entire host group and 136 receives data sent from any source to this group. PIM-SM also allows 137 receivers to switch to a source-based shortest path tree. 139 An RP uses the MSDP [MSDP] protocol to announce multicast sources to 140 RPs in other domains. When an RP discovers a source in a different 141 domain transmitting data to a multicast group for which there are 142 interested receivers in its own domain, it joins the shortest-path 143 source based tree rooted at that source. It then redistributes the 144 data received to all interested receivers via the intra-domain shared 145 tree rooted at itself. 147 The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP] 148 to support the advertisement of reachability information for 149 multicast routes. This allows an autonomous system (AS) to support 150 incongruent unicast and multicast routing topologies, and thus 151 implement separate routing policies for each. 153 3. Problems with Current Architecture 155 There are several deployment problems associated with current 156 multicast architecture: 158 A) Inefficient handling of well-known sources : 160 In cases where the address of the source is well known in advance 161 of the receiver joining the group, and when the shortest 162 forwarding path is the preferred forwarding mode, then shared tree 163 mechanisms and MSDP are not necessary. 165 B) Lack of access control : 167 In the ASM service model, a receiver can not specify which 168 specific sources it would like to receive when it joins a given 169 group. A receiver will be forwarded data sent to a host group by 170 any source. 172 C) Address Allocation : 174 Address allocation is one of core deployment challenges posed by 175 the ASM service model. The current multicast architecture does not 176 provide a deployable solution to prevent address collisions among 177 multiple applications. The problem is more serious for IPv4 than 178 IPv6 since the total number of multicast addresses is smaller. A 179 static address allocation scheme, GLOP [GLOP00] has been proposed 180 as an interim solution for IPv4; however, GLOP addresses are 181 allocated per registered AS, which is inadequate in cases where 182 the number of sources exceeds the AS numbers available for 183 mapping. Proposed longer-term solutions such as the Multicast 184 Address Allocation Architecture [MAAA] are generally perceived as 185 being too complex (with respect to the dynamic nature of multicast 186 address allocation) for widespread deployment. 188 4. Source Specific Multicast (SSM) : Benefits and Requirements 190 As mentioned before, the Source Specific Multicast (SSM) service 191 model defines a "channel" identified by an (S,G) pair, where S is a 192 source address and G is an SSM destination address. Channel 193 subscriptions are described using an SFM-capable group management 194 protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees 195 are needed to implement this model. 197 The SSM service model alleviates all of the deployment problems 198 described earlier : 200 4.1 SSM lends itself to an elegant solution to the access control 201 problem. When a receiver subscribes to an (S,G) channel, it 202 receives data sent by a only the source S. In contrast, any host 203 can transmit to an ASM host group. Hence, it is more difficult to 204 spam an SSM channel than an ASM host group. 206 4.2 SSM defines channels on a per-source basis, i.e., the channel 207 (S1,G) is distinct from the channel (S2,G), where S1 and S2 are 208 source addresses, and G is an SSM destination address. This averts 209 the problem of global allocation of SSM destination addresses, and 210 makes each source independently responsible for resolving address 211 collisions for the various channels that it creates. 213 4.3 SSM requires only source-based forwarding trees; this 214 eliminates the need for a shared tree infrastructure. In terms of 215 the IGMP/PIM-SM/MSDP/MBGP protocol suite, this implies that 216 neither the RP-based shared tree infrastructure of PIM-SM nor the 217 MSDP protocol is required. Thus the complexity of the multicast 218 routing infrastructure for SSM is low, making it viable for 219 immediate deployment. 221 4.4 It is widely held that point-to-multipoint applications such 222 as Internet TV will dominate the Internet multicast application 223 space in the near future. The SSM model is ideally suited for such 224 applications. 226 5. SSM Framework 228 Figure 1 illustrates the elements in an end-to-end implementation 229 framework for SSM : 231 -------------------------------------------------------------- 232 IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION 233 FF3x::/12 for IPv6 234 -------------------------------------------------------------- 235 | 236 v 237 +--------------+ session directory/web page 238 | source,group | SESSION DESCRIPTION 239 -------------------------------------------------------------- 240 ^ | 241 Query | | (S,G) 242 | v 243 +-----------------+ host 244 | SSM-aware app | CHANNEL DISCOVERY 245 -------------------------------------------------------------- 246 | SSM-aware app | SSM-AWARE APPLICATION 247 -------------------------------------------------------------- 248 | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING 249 +-----------------+ 250 |(source specific host report) 251 -------------------------------------------------------------- 252 v 253 +-----------------+ Querier Router 254 | IGMPv3/MLDv2 | QUERIER 255 -------------------------------------------------------------- 256 | PIM-SSM | PIM-SSM ROUTING 257 +------------+ Designated Router 258 | 259 | (S,G) Join only 260 v 261 +-----------+ Backbone Router 262 | PIM-SSM | 263 +-----------+ 264 | 265 | (S,G) Join only 266 V 268 Figure 1 : SSM Framework: elements in end-to-end model 270 We now discuss the framework elements in detail : 272 5.1 Address Allocation 274 For IPv4, the address range of 232/8 has been assigned by IANA for 275 SSM. To ensure global SSM functionality in 232/8, including in 276 networks where routers run non-SFM-capable protocols, operational 277 policies are being proposed [SSM-BCP] which prevent data sent to 278 232/8 from being delivered to parts of the network that do not have 279 channel subscribers. 281 Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 282 range. However, SSM service, as defined in [SSM-ARCH], is guaranteed 283 only in this address range for IPv4. 285 In case of IPv6, [HABE1] has defined an extension to the addressing 286 architecture to allow for unicast prefix-based multicast addresses. 287 In this case, bytes 0-3 (starting from the least significant byte) of 288 the IP address is used to specify a multicast group id, bytes 4-11 is 289 be used to specify a unicast address prefix (of up to 64 bits) that 290 owns this multicast group id, and byte 12 is used to specify the 291 length of the prefix. A source-specific multicast address can be 292 specified by setting both the prefix length field and the prefix 293 field to zero. 295 5.2 Session Description and Channel Discovery 297 An SSM receiver application must know both the SSM destination 298 address G and the source address S before subscribing to a 299 channel. Thus the function of channel discovery becomes the 300 responsibility of applications. This information can be made 301 available in a number of ways, including via web pages, sessions 302 announcement applications, etc. The exact mechanisms for doing 303 this is outside the scope of this framework document. 305 5.3. SSM-Aware Applications 307 -- For applications sourcing content via SSM channels, the session 308 must be advertised including a source address as well as an SSM 309 address. 311 -- Applications expecting to subscribe to an SSM channel must be 312 capable of specifying a source address in addition to an SSM 313 destination address. In other words, the application must be "SSM- 314 aware". 316 Specific API requirements are identified in [THAL00]. 318 5.4. IGMPv3/MLDv2 Host Reporting and Querier 320 IGMP version 2 [IGMPv2] allows end-hosts to report their interest 321 in a multicast group by specifying a class-D IP address for IPv4. 322 However in order to implement the SSM service model, an end-host 323 must specify a source's unicast address as well as an SSM 324 destination address. This capability is provided by IGMP version 3 325 [IGMPv3]. IGMPv3 supports "source filtering", i.e., the ability of 326 an end-system to express interest in receiving data packets sent 327 only by SPECIFIC sources, or from ALL BUT some specific sources. 328 Thus, IGMPv3 provides a superset of the capabilities required to 329 realize the SSM service model. 331 There are a number of backward compatibility issues between IGMP 332 versions 2 and 3 which have to be addressed. A detailed discussion 333 of the use of IGMPv3 in the SSM destination address range is 334 provided in [SSM-IGMPv3]. 336 The Multicast Listener Discovery (MLD) protocol used by an IPv6 337 router to discover the presence of multicast listeners on its 338 directly attached links, and to discover the multicast addresses 339 that are of interest to those neighboring nodes. Version 1 of MLD 340 [DEER99] is derived from IGMPv2 and allows a multicast listener 341 to specify the multicast group(s) that it is interested in. 342 Version 2 of MLD [VIDA01] is derived from, and provides the same 343 support for source-filtering as, IGMPv3. 345 5.5. PIM-SSM Routing 347 PIM-SM [PIM-SM-NEW] itself supports two types of trees, a shared tree 348 rooted at a core (RP), and a source-based shortest path tree. Thus 349 PIM-SM already supports source-based trees. The original 350 PIM-SM [PIM-SM] did not allow a router to choose between a shared 351 tree and a source-based tree. In fact, a receiver always joined a PIM 352 shared tree to start with, and may later be switched to a per-source 353 tree by its adjacent edge router. However, the more recent PIM-SM 354 specification [PIM-SM-NEW] has support for source-specific join. 356 Supporting SSM with PIM-SM involves several changes to PIM-SM as 357 described in [PIM-SM-NEW]. The resulting PIM functionality is 358 described as PIM-SSM. The specific architectural issues associated 359 with PIM-SSM and IGMPv3/MLDv2 are detailed in [SSM-ARCH]. The most 360 important changes to PIM-SM with respect to SSM are as follows: 362 -- When a DR receives an (S,G) join request with the address G in 363 the SSM address range, it must initiate a (S,G) join and NEVER a 364 (*,G) join. 366 --Backbone routers (i.e. routers that do not have directly 367 attached hosts) must not propagate (*,G) joins for group addresses 368 in the SSM address range. 370 --Rendezvous Points (RPs) must not accept PIM Register messages or 371 (*,G) Join messages in the SSM address range. 373 6. Interoperability with Existing Multicast Service Models 375 Interoperability with ASM is one of the most important issues in 376 moving to SSM deployment. ASM and SSM will always coexist; hence 377 there will be two service models for Internet multicast. SSM is the 378 ONLY service model for the SSM address range - the correct protocol 379 behaviour for this range is specified in [SSM-ARCH]. The ASM service 380 model will be offered for the non-SSM adddress range, where receivers 381 can issue (*,G) join requests to receive multicast data. A receiver 382 is also allowed to issue an (S,G) join request in the non-SSM address 383 range; however, in that case there is no guarantee that it will 384 receive service according to the SSM model. 386 Another backward compatibility issue concerns the MSDP protocol, 387 which is used between PIM-SM rendezvous points (RPs) to discover 388 multicast sources across multiple domains. SSM obviates the needs for 389 MSDP, but MSDP is still required to support ASM for non-SSM class-D 390 IPv4 addresses. In order to ensure that SSM is the sole forwarding 391 model in 232/8, RPs must not accept, originate or forward MSDP SA 392 messages for the SSM address range [SSM-BCP]. 394 7. Security Considerations 396 SSM does not introduce new security considerations for IP multicast. 397 It can help in preventing denial-of-service attacks resulting from 398 unwanted sources transmitting data to a multicast channel (S, G). 399 However no guarantee is provided. 401 8. Acknowledgments 403 We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon 404 and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, 405 Tony Speakman and Nidhi Bhaskar at Cisco Systems for participating in 406 lengthy discussions and design work on SSM, and providing feedback on 407 this document. Thanks are also due to Mujahid Khan and Ted Seely at 408 SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T 409 Research, Kevin Almeroth at the University of California Santa 410 Barbara, Brian Levine at the University of Massachusetts Amherst, 411 Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their 412 valuable insights and continuing support. 414 9. References: 416 [EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : 417 EXPRESS Support for Large-scale Single-Source Applications. In 418 Proceedings of SIGCOMM 1999. 420 [IANA-ALLOCATION] Internet Assigned Numbers Authority. 421 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 423 [RFC2236] W. Fenner. Internet Group Management Protocol, Version 2. 424 Request For Comments 2236. 426 [IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. 427 Internet Group Management Protocol, Version 3. Work in Progress. 429 [SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in 430 Progress. 432 [SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for 433 IP. Work in Progress. 435 [IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in 436 Datagram Networks and Extended LANs. ACM Transactions on Computer 437 Systems, 8(2):85-110, May 1990. 439 [PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area 440 Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, 441 April 1996. 443 [PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse 444 Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362. 446 [PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. 447 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 448 Specification (Revised)", Work In Progress, 2000. . 451 [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 452 Dense Mode Specification. Work in Progress. 454 [MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in 455 Progress. 457 [MAAA] M. Handley, D. Thaler and D. Estrin. The Internet Multicast 458 Address Allocation Architecture. Work in Progress (draft-ietf- 459 malloc-arch-**.txt) June 2000. 461 [MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. 463 Balensiefen. Deployment Issues for the IP Multicast Service and 464 Architecture. In IEEE Networks Magazine's Special Issue on 465 Multicast, January, 2000. 467 [SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of 468 Single-Source Multicast. Work in Progress. 470 [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface 471 Extensions for Multicast Source Filters. Work in Progress. 473 [RFC2770] GLOP Addressing in 233/8. Request For Comments 2770. 475 [RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest 476 for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 477 2000. 479 [SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent 480 Multicast in 232/8. Work in Progress. 482 [RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener 483 Discovery for IPv6. Request for Comments 2710. 485 [MLDv2] R. Vida, et. al. 486 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. 487 Work in progress. 489 [SSM-IPv6] B. Haberman and D. Thaler. 490 Unicast-Prefix-Based IPv6 Multicast Addresses. Work in 491 Progress. 493 [IPSEC] S. Kent, R. Atkinson. 494 Security Architecture for the Internet Protocol. Request for 495 Comments 2401. 497 [IPv6-ALLOC] B. Haberman. 498 Dynamic Allocation Guidelines for IPv6 Multicast Addresses. 499 Work in Progress. 501 12. Authors' Address: 503 Supratik Bhattacharyya 504 Christophe Diot 505 Sprint Advanced Technology Labs 506 One Adrian Court 507 Burlingame CA 94010 USA 508 {supratik,cdiot}@sprintlabs.com 509 http://www.sprintlabs.com 510 Leonard Giuliano 511 Greg Shepherd 512 Juniper Networks, Inc. 513 1194 North Mathilda Avenue 514 Sunnyvale, CA 94089 USA 515 {lenny,shep}@juniper.net 517 Robert Rockell 518 David Meyer 519 Sprint E|Solutions 520 Reston Virginia USA 521 {rrockell,dmm}@sprint.net 523 John Meylor 524 Cisco Systems 525 San Jose CA USA 526 jmeylor@cisco.com 528 Brian Haberman 529 No Affiliation 530 haberman@innovationslab.net