idnits 2.17.1 draft-ietf-ssm-overview-03.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 12 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 13 pages 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.) ** 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 367 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 (04 March 2002) is 8082 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 477 looks like a reference -- Missing reference section? 'RFC1112' on line 79 looks like a reference -- Missing reference section? 'SSM-ARCH' on line 463 looks like a reference -- Missing reference section? 'EXPRESS' on line 447 looks like a reference -- Missing reference section? 'IANA-ALLOC' on line 94 looks like a reference -- Missing reference section? 'SSM-IPv6' on line 528 looks like a reference -- Missing reference section? 'IGMPv3' on line 457 looks like a reference -- Missing reference section? 'MLDv2' on line 524 looks like a reference -- Missing reference section? 'RFC2365' on line 491 looks like a reference -- Missing reference section? 'IGMPv2' on line 350 looks like a reference -- Missing reference section? 'MSDP' on line 494 looks like a reference -- Missing reference section? 'MBGP' on line 157 looks like a reference -- Missing reference section? 'RFC2236' on line 454 looks like a reference -- Missing reference section? 'RFC2710' on line 521 looks like a reference -- Missing reference section? 'PIM-DM' on line 482 looks like a reference -- Missing reference section? 'RFC2189' on line 485 looks like a reference -- Missing reference section? 'RFC2201' on line 488 looks like a reference -- Missing reference section? 'IPMULTICAST' on line 466 looks like a reference -- Missing reference section? 'PIM-SM' on line 474 looks like a reference -- Missing reference section? 'BGP' on line 157 looks like a reference -- Missing reference section? 'GLOP00' on line 175 looks like a reference -- Missing reference section? 'MAAA' on line 497 looks like a reference -- Missing reference section? 'SSM-BCP' on line 518 looks like a reference -- Missing reference section? 'HABE1' on line 305 looks like a reference -- Missing reference section? 'THAL00' on line 340 looks like a reference -- Missing reference section? 'MLDv1' on line 351 looks like a reference -- Missing reference section? 'SSM-IGMPv3' on line 460 looks like a reference -- Missing reference section? 'DEER99' on line 367 looks like a reference -- Missing reference section? 'VIDA01' on line 369 looks like a reference -- Missing reference section? 'IANA-ALLOCATION' on line 451 looks like a reference -- Missing reference section? 'PIM-ARCH' on line 470 looks like a reference -- Missing reference section? 'MCAST-DEPLOY' on line 501 looks like a reference -- Missing reference section? 'SSM-RULES' on line 506 looks like a reference -- Missing reference section? 'MSF-API' on line 509 looks like a reference -- Missing reference section? 'RFC2770' on line 512 looks like a reference -- Missing reference section? 'RCVR-INTEREST' on line 514 looks like a reference -- Missing reference section? 'IPSEC' on line 532 looks like a reference -- Missing reference section? 'IPv6-ALLOC' on line 536 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 41 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Supratik Bhattacharyya 3 Expires 04 September 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 04 March 2002 19 An Overview of Source-Specific Multicast (SSM) 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. An IPv4 address range has been reserved by IANA for use 54 by the SSM service. An SSM destination address range already exists 55 for IPv6. A source S transmits IP datagrams to an SSM destination 56 address G. A receiver can receive these datagrams by subscribing to 57 the channel (S,G). Channel subscription is supported by version 3 of 58 the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. 59 The interdomain tree for forwarding IP multicast datagrams is rooted 60 at the source S, and is constructed using the PIM Sparse Mode [PIM- 61 SM-NEW] protocol. 63 This document is not intended to be a standard for Source-Specific 64 Multicast (SSM). Instead, its goal is to serve as an introduction to 65 SSM and and its benefits for anyone interested in deploying SSM 66 services. It provides an overview of SSM and and how it solves a 67 number of problems faced in the deployment of inter-domain multicast. 68 It outlines changes to protocols and applications both at end-hosts 69 and routers for supporting SSM, with pointers to more detailed 70 documents where appropriate. Issues of interoperability with the 71 multicast service model defined by RFC 1112 are also discussed. 73 1. Terminology 75 This section defines some terms that are used in the rest of this 76 document : 78 Any-Source Multicast (ASM) : This is the IP multicast service model 79 defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a 80 "host group", a set of zero or more end-hosts identified by a single 81 IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). 82 End-hosts may join and leave the group any time, and there is no 83 restriction on their location or number. Moreover, this model supports 84 multicast groups with arbitrarily many senders - any end-host may 85 transmit to a host group, even if it is not a member of that group. 87 Source-Specific Multicast (SSM) : This is the multicast service model 88 defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to 89 an SSM destination address G, and receivers can receive this datagram 90 by subscribing to channel (S,G). SSM provides host applications with a 91 "channel" abstraction, in which each channel has exactly one source 92 and any number of receivers. SSM is derived from earlier work in 93 EXPRESS [EXPRESS].The address range 232/8 has been assigned by IANA 94 [IANA-ALLOC] for SSM service in IPv4. For IPv6, the range FF3x::/96 is 95 defined for SSM services [SSM-IPv6]. 97 Source-Filtered Multicast (SFM) : This is a variant of the ASM service 98 model, and uses the same address range as ASM 99 (224.0.0.0-239.255.255.255). It extends the ASM service model as 100 follows. Each "upper layer protocol module" can now request data sent 101 to a host group G by only a specific set of sources, or can request 102 data sent to host group G from all BUT a specific set of sources. 103 Support for source filtering is provided by version 3 of the Internet 104 Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2 105 of the Multicast Listener Discovery (or MLDv2) [MLDv2] protocol for 106 IPv6. We shall henceforth refer to these two protocols as "SFM- 107 capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and 108 MLDv1 - do not provide support for source-filtering, and are referred 109 to as "non-SFM-capable". Note that while SFM is a different model than 110 ASM from a receiver standpoint, there is no distinction between the 111 two for a sender. 113 For the purpose of this document, we treat the scoped multicast model of 114 [RFC2365] to be a variant of ASM since it does not explicitly restrict 115 the number of sources, but only requires that they be located within the 116 scope zone of the group. 118 2. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM 120 As of this writing, all multicast-capable networks support the ASM 121 service model. One of the most common multicast protocol suites for 122 supporting ASM consists of IGMP version 2 [IGMPv2], PIM-SM [PIM- 123 SM,PIM-SM-NEW], MSDP [MSDP] and MBGP [MBGP] protocols. IGMPv2 124 [RFC2236] is the most commonly used protocol for hosts to specify 125 membership in a multicast group, and nearly all multicast routers 126 support (at least) IGMPv2. In case of IPv6, MLDv1 [RFC2710] is the 127 commonly used protocol. 129 Although a number of protocols such as PIM-DM [PIM-DM], CBT 130 [RFC2189,RFC2201], DVMRP [IPMULTICAST], etc. exist for building 131 multicast tree among all receivers and sources in the same 132 administrative domain, PIM-SM [PIM-SM, PIM-SM-NEW] is the most widely 133 used protocol. PIM-SM builds a spanning multicast tree rooted at a 134 core rendezvous point or RP for all group members within a single 135 administrative domain. A 'first-hop' router adjacent to a multicast 136 source sends the source's traffic to the RP for its domain. The RP 137 forwards the data down the shared spanning tree to all interested 138 receivers within the domain. PIM-SM also allows receivers to switch 139 to a source-based shortest path tree. 141 As of this writing, multicast end-hosts with SFM capabilities are not 142 widely available. Hence a client can only specify interest in an 143 entire host group and receives data sent from any source to this 144 group. 146 Inter-domain multicast service (i.e., where at least one source for a 147 multicast group is located in a different domain than the receivers) 148 requires additional protocols - MSDP [MSDP] and MBGP [MBGP] are the 149 most commonly used ones. An RP uses the MSDP [MSDP] protocol to 150 announce multicast sources to RPs in other domains. When an RP 151 discovers a source in a different domain transmitting data to a 152 multicast group for which there are interested receivers in its own 153 domain, it joins the shortest-path source based tree rooted at that 154 source. It then redistributes the data received to all interested 155 receivers via the intra-domain shared tree rooted at itself. 157 The MBGP protocol [MBGP] defines extensions to the BGP protocol [BGP] 158 to support the advertisement of reachability information for 159 multicast routes. This allows an autonomous system (AS) to support 160 incongruent unicast and multicast routing topologies, and thus 161 implement separate routing policies for each. 163 3. Problems with Current Architecture 165 There are several deployment problems associated with current 166 multicast architecture: 168 A) Address Allocation : 170 Address allocation is one of core deployment challenges posed by 171 the ASM service model. The current multicast architecture does not 172 provide a deployable solution to prevent address collisions among 173 multiple applications. The problem is much less serious for IPv6 174 than for IPv4 since the size of the multicast address space is 175 much larger. A static address allocation scheme, GLOP [GLOP00] 176 has been proposed as an interim solution for IPv4; however, GLOP 177 addresses are allocated per registered AS, which is inadequate in 178 cases where the number of sources exceeds the AS numbers available 179 for mapping. Proposed longer-term solutions such as the Multicast 180 Address Allocation Architecture [MAAA] are generally perceived as 181 being too complex (with respect to the dynamic nature of multicast 182 address allocation) for widespread deployment. 184 B) Lack of Access control : 186 In the ASM service model, a receiver cannot specify which 187 specific sources it would like to receive when it joins a given 188 group. A receiver will be forwarded data sent to a host group by 189 any source. Moreover, even when a source is allocated a multicast 190 group address to transmit on, it has no way of enforcing that no 191 other source will use the same address. This is true even in the 192 case of IPv6, where address collisions are less likely due to the 193 much larger size of the address space. 195 C) Inefficient handling of well-known sources : 197 In cases where the address of the source is well known in advance 198 of the receiver joining the group, and when the shortest 199 forwarding path is the preferred forwarding mode, then shared tree 200 mechanisms and MSDP are not necessary. 202 4. Source Specific Multicast (SSM) : Benefits and Requirements 204 As mentioned before, the Source Specific Multicast (SSM) service 205 model defines a "channel" identified by an (S,G) pair, where S is a 206 source address and G is an SSM destination address. Channel 207 subscriptions are described using an SFM-capable group management 208 protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees 209 are needed to implement this model. 211 The SSM service model alleviates all of the deployment problems 212 described earlier : 214 A) Address Allocation : SSM defines channels on a per-source 215 basis, i.e., the channel (S1,G) is distinct from the channel 216 (S2,G), where S1 and S2 are source addresses, and G is an SSM 217 destination address. This averts the problem of global allocation 218 of SSM destination addresses, and makes each source independently 219 responsible for resolving address collisions for the various 220 channels that it creates. 222 B) Access Control : SSM lends itself to an elegant solution to the 223 access control problem. When a receiver subscribes to an (S,G) 224 channel, it receives data sent by a only the source S. In 225 contrast, any host can transmit to an ASM host group. At the same 226 time, when a sender picks a channel (S,G) to transmit on, it is 227 automatically ensured that no other sender will be transmitting on 228 the same channel (except in the case of malicious acts such as 229 address spoofing). This makes it much harder to "spam" an SSM 230 channel than an ASM multicast group. 232 C) Handling of well-known sources : SSM requires only source-based 233 forwarding trees; this eliminates the need for a shared tree 234 infrastructure. In terms of the IGMP/PIM-SM/MSDP/MBGP protocol 235 suite, this implies that neither the RP-based shared tree 236 infrastructure of PIM-SM nor the MSDP protocol is required. Thus 237 the complexity of the multicast routing infrastructure for SSM is 238 low, making it viable for immediate deployment. Note that MBGP is 239 still required for distribution of multicast reachability 240 information. 242 D) It is widely held that point-to-multipoint applications such as 243 Internet TV will be important in the near future. The SSM model is 244 ideally suited for such applications. 246 5. SSM Framework 248 Figure 1 illustrates the elements in an end-to-end implementation 249 framework for SSM : 251 -------------------------------------------------------------- 252 IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION 253 FF3x::/12 for IPv6 254 -------------------------------------------------------------- 255 | 256 v 257 +--------------+ session directory/web page 258 | source,group | SESSION DESCRIPTION 259 -------------------------------------------------------------- 260 ^ | 261 Query | | (S,G) 262 | v 263 +-----------------+ host 264 | SSM-aware app | CHANNEL DISCOVERY 265 -------------------------------------------------------------- 266 | SSM-aware app | SSM-AWARE APPLICATION 267 -------------------------------------------------------------- 268 | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING 269 +-----------------+ 270 |(source specific host report) 271 -------------------------------------------------------------- 272 v 273 +-----------------+ Querier Router 274 | IGMPv3/MLDv2 | QUERIER 275 -------------------------------------------------------------- 276 | PIM-SSM | PIM-SSM ROUTING 277 +------------+ Designated Router 278 | 279 | (S,G) Join only 280 v 281 +-----------+ Backbone Router 282 | PIM-SSM | 283 +-----------+ 284 | 285 | (S,G) Join only 286 V 288 Figure 1 : SSM Framework: elements in end-to-end model 290 We now discuss the framework elements in detail : 292 5.1 Address Allocation 294 For IPv4, the address range of 232/8 has been assigned by IANA for 295 SSM. To ensure global SSM functionality in 232/8, including in 296 networks where routers run non-SFM-capable protocols, operational 297 policies are being proposed [SSM-BCP] which recommend that routers 298 should not send SSM traffic to parts of the network that do not have 299 channel subscribers. 301 Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 302 range. However, SSM service, as defined in [SSM-ARCH], is available 303 only in this address range for IPv4. 305 In case of IPv6, [HABE1] has defined an extension to the addressing 306 architecture to allow for unicast prefix-based multicast addresses. 307 Bytes 0-3 (starting from the least significant byte) of the IP 308 address are used to specify a multicast group id, bytes 4-11 are used 309 to specify a unicast address prefix (of up to 64 bits) that owns this 310 multicast group id, and byte 12 is used to specify the length of the 311 prefix. A source-specific multicast address is specified by setting 312 both the prefix length field and the prefix field to zero. 314 5.2 Session Description and Channel Discovery 316 An SSM receiver application must know both the SSM destination 317 address G and the source address S before subscribing to a 318 channel. Channel discovery is the responsibility of applications. 319 This information can be made available in a number of ways, 320 including via web pages, sessions announcement applications, etc. 321 This is similar to what is used for ASM applications where a 322 multicast session needs to be announced so that potential 323 subscribers can know of the multicast group adddres, encoding 324 schemes used, etc. In fact, the only additional piece of 325 information that needs to be announced is the source address for 326 the channel being advertised. However, the exact mechanisms for 327 doing this is outside the scope of this framework document. 329 5.3. SSM-Aware Applications 331 -- An application that wants to received an SSM session must first 332 discover the channel address in use. Any of the mechanisms 333 described in Section 5.2 can be used for this purpose. 335 -- A receiving application must be able to specify both a source 336 address and a destination address to the network layer protocol 337 module on the end-host. In other words, the application must be 338 "SSM-aware". 340 Specific API requirements are identified in [THAL00]. [THAL00] 341 describes a recommended application programming interface for a 342 host operating system to support the SFM service model. Although 343 it is intended for SFM, a subset of this interface is sufficient 344 for supporting SSM. 346 5.4. IGMPv3/MLDv2 Host Reporting and Querier 348 In order to use SSM service, an end-host must be able to specify a 349 channel address, consisting of a source's unicast address and an 350 SSM destination address. IGMP version 2 [IGMPv2] and MLD version 1 351 [MLDv1] allows an end-host to specify only a destination multicast 352 address. The ability to specify an SSM channel address c is 353 provided by IGMP version 3 [IGMPv3] and MLD version 2 [MLDv2]. 354 These protocols support "source filtering", i.e., the ability of 355 an end-system to express interest in receiving data packets sent 356 only by SPECIFIC sources, or from ALL BUT some specific sources. 357 In fact, IGMPv3 provides a superset of the capabilities required 358 to realize the SSM service model. 360 A detailed discussion of the use of IGMPv3 in the SSM destination 361 address range is provided in [SSM-IGMPv3]. 363 The Multicast Listener Discovery (MLD) protocol used by an IPv6 364 router to discover the presence of multicast listeners on its 365 directly attached links, and to discover the multicast addresses 366 that are of interest to those neighboring nodes. Version 1 of MLD 367 [DEER99] is derived from IGMPv2 and does not provide the source 368 filtering capability required for the SSM service model. Version 2 369 of MLD [VIDA01] is derived from, and provides the same support for 370 source-filtering as, IGMPv3. THus IGMPv3 (or MLDv2 for IPv6) 371 provides a host with the ability to request the network for an SSM 372 channel subscription. 374 5.5. PIM-SSM Routing 376 [PIM-SM-NEW] provides guideliness for how a PIM-SM implementation 377 should handle source-specific host reports as required by SSM. 378 Earlier versions of the PIM protocol specifications did not describe 379 how to do this. 381 The router requirements for operation in the SSM range are detailed 382 in [SSM-ARCH]. These rules are primarily concerned with preventing 383 ASM-style behaviour in the SSM address range. In order to comply with 384 [SSM-ARCH] several changes to the PIM-SM protocol are required, as 385 described in [PIM-SM-NEW].The most important changes in PIM-SM 386 required for compliance with [SSM-ARCH] are : 388 -- When a DR receives an (S,G) join request with the address G in 389 the SSM address range, it must initiate a (S,G) join and NEVER a 390 (*,G) join. 392 --Backbone routers (i.e. routers that do not have directly 393 attached hosts) must not propagate (*,G) joins for group addresses 394 in the SSM address range. 396 --Rendezvous Points (RPs) must not accept PIM Register messages or 397 (*,G) Join messages in the SSM address range. 399 Note that only a small subset of the full PIM-SM protocol 400 functionality is needed to support the SSM service model. This subset 401 is explicitly documented in [PIM-SM-NEW]. 403 6. Interoperability with Existing Multicast Service Models 405 Interoperability with ASM is one of the most important issues in 406 moving to SSM deployment, since both models are expected to be used 407 at least in the foreseeable future. SSM is the ONLY service model for 408 the SSM address range - the correct protocol behaviour for this range 409 is specified in [SSM-ARCH]. The ASM service model will be offered for 410 the non-SSM adddress range, where receivers can issue (*,G) join 411 requests to receive multicast data. A receiver is also allowed to 412 issue an (S,G) join request in the non-SSM address range; however, in 413 that case there is no guarantee that it will receive service 414 according to the SSM model. 416 Another interoperability issue concerns the MSDP protocol, which is 417 used between PIM-SM rendezvous points (RPs) to discover multicast 418 sources across multiple domains. MSDP is not needed for SSM, but is 419 needed if ASM is supported. [SSM-BCP] specifies operational 420 recommendations to help ensure that MSDP does not interfere with the 421 ability of a network to support the SSM service model. Specifically, 422 [SSM-BCP] states that RPs must not accept, originate or forward MSDP 423 SA messages for the SSM address range [SSM-BCP]. 425 7. Security Considerations 427 SSM does not introduce new security considerations for IP multicast. 428 It can help in preventing denial-of-service attacks resulting from 429 unwanted sources transmitting data to a multicast channel (S, G). 430 However no guarantee is provided. 432 8. Acknowledgments 434 We would like to thank Gene Bowen, Ed Kress, Bryan Lyles and Timothy 435 Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, Tony Speakman 436 and Nidhi Bhaskar at Cisco Systems for participating in lengthy 437 discussions and design work on SSM, and providing feedback on this 438 document. Thanks are also due to Mujahid Khan and Ted Seely at 439 SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T 440 Research, Kevin Almeroth at the University of California Santa 441 Barbara, Brian Levine at the University of Massachusetts Amherst, 442 Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their 443 valuable insights and continuing support. 445 9. References: 447 [EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : 448 EXPRESS Support for Large-scale Single-Source Applications. In 449 Proceedings of SIGCOMM 1999. 451 [IANA-ALLOCATION] Internet Assigned Numbers Authority. 452 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 454 [RFC2236] W. Fenner. Internet Group Management Protocol, Version 2. 455 Request For Comments 2236. 457 [IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. 458 Internet Group Management Protocol, Version 3. Work in Progress. 460 [SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in 461 Progress. 463 [SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for 464 IP. Work in Progress. 466 [IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in 467 Datagram Networks and Extended LANs. ACM Transactions on Computer 468 Systems, 8(2):85-110, May 1990. 470 [PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area 471 Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, 472 April 1996. 474 [PIM-SM] D. Estrin et al. Protocol Independent Multicast - Sparse 475 Mode (PIM-SM) : Protocol Specification. Request for Comments 2362. 477 [PIM-SM-NEW] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. 478 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 479 Specification (Revised)", Work In Progress, 2000. . 482 [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 483 Dense Mode Specification. Work in Progress. 485 [RFC2189] A. Ballardie. Core-Based Trees (CBT Version 2) Multicast 486 Routing -- Protocol Specification. Request for Comments 2189. 488 [RFC2201] A. Ballardie. Core-Based Trees (CBT) Multicast Routing 489 Architecture. Request for Comments 2201. 491 [RFC2365] D. Meyer. Adminstratively Scoped IP Multicast. Request for 492 Comments 2365. 494 [MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in 495 Progress. 497 [MAAA] M. Handley, D. Thaler and D. Estrin. The Internet Multicast 498 Address Allocation Architecture. Work in Progress (draft-ietf- 499 malloc-arch-**.txt) June 2000. 501 [MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. 502 Balensiefen. Deployment Issues for the IP Multicast Service and 503 Architecture. In IEEE Networks Magazine's Special Issue on 504 Multicast, January, 2000. 506 [SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of 507 Single-Source Multicast. Work in Progress. 509 [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface 510 Extensions for Multicast Source Filters. Work in Progress. 512 [RFC2770] GLOP Addressing in 233/8. Request For Comments 2770. 514 [RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest 515 for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 516 2000. 518 [SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent 519 Multicast in 232/8. Work in Progress. 521 [RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener 522 Discovery for IPv6. Request for Comments 2710. 524 [MLDv2] R. Vida, et. al. 525 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. 526 Work in progress. 528 [SSM-IPv6] B. Haberman and D. Thaler. 529 Unicast-Prefix-Based IPv6 Multicast Addresses. Work in 530 Progress. 532 [IPSEC] S. Kent, R. Atkinson. 533 Security Architecture for the Internet Protocol. Request for 534 Comments 2401. 536 [IPv6-ALLOC] B. Haberman. 537 Dynamic Allocation Guidelines for IPv6 Multicast Addresses. 538 Work in Progress. 540 12. Authors' Address: 542 Supratik Bhattacharyya 543 Christophe Diot 544 Sprint Advanced Technology Labs 545 One Adrian Court 546 Burlingame CA 94010 USA 547 {supratik,cdiot}@sprintlabs.com 548 http://www.sprintlabs.com 550 Leonard Giuliano 551 Greg Shepherd 552 Juniper Networks, Inc. 553 1194 North Mathilda Avenue 554 Sunnyvale, CA 94089 USA 555 {lenny,shep}@juniper.net 557 Robert Rockell 558 David Meyer 559 Sprint E|Solutions 560 Reston Virginia USA 561 {rrockell,dmm}@sprint.net 563 John Meylor 564 Cisco Systems 565 San Jose CA USA 566 jmeylor@cisco.com 568 Brian Haberman 569 No Affiliation 570 haberman@innovationslab.net