idnits 2.17.1 draft-ietf-ssm-overview-00.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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 310: '...SM functionality MUST allocate address...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 82 has weird spacing: '...sts may join ...' == Line 83 has weird spacing: '... on the locat...' == Line 408 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 (18 May 2001) is 8378 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 45 looks like a reference -- Missing reference section? 'PIM-SM-NEW' on line 425 looks like a reference -- Missing reference section? 'RFC1112' on line 78 looks like a reference -- Missing reference section? 'SSM-ARCH' on line 503 looks like a reference -- Missing reference section? 'EXPRESS' on line 487 looks like a reference -- Missing reference section? 'IANA-ALLOC' on line 91 looks like a reference -- Missing reference section? 'SSM-IPV6' on line 92 looks like a reference -- Missing reference section? 'IGMPv3' on line 497 looks like a reference -- Missing reference section? 'MLDv2' on line 549 looks like a reference -- Missing reference section? 'RFC2236' on line 494 looks like a reference -- Missing reference section? 'RFC2710' on line 546 looks like a reference -- Missing reference section? 'MSDP' on line 523 looks like a reference -- Missing reference section? 'GLOP00' on line 186 looks like a reference -- Missing reference section? 'HABE1' on line 326 looks like a reference -- Missing reference section? 'SSM-BCP' on line 543 looks like a reference -- Missing reference section? 'THAL00' on line 364 looks like a reference -- Missing reference section? 'CAIN99' on line 386 looks like a reference -- Missing reference section? 'DEER99' on line 408 looks like a reference -- Missing reference section? 'VIDA01' on line 410 looks like a reference -- Missing reference section? 'IANA-ALLOCATION' on line 491 looks like a reference -- Missing reference section? 'SSM-IGMPv3' on line 500 looks like a reference -- Missing reference section? 'IPMULTICAST' on line 506 looks like a reference -- Missing reference section? 'PIM-ARCH' on line 510 looks like a reference -- Missing reference section? 'RFC2362' on line 514 looks like a reference -- Missing reference section? 'PIM-SM' on line 517 looks like a reference -- Missing reference section? 'PIM-DM' on line 520 looks like a reference -- Missing reference section? 'MCAST-DEPLOY' on line 526 looks like a reference -- Missing reference section? 'SSM-RULES' on line 531 looks like a reference -- Missing reference section? 'MSF-API' on line 534 looks like a reference -- Missing reference section? 'RFC2770' on line 537 looks like a reference -- Missing reference section? 'RCVR-INTEREST' on line 539 looks like a reference -- Missing reference section? 'SSM-IPv6' on line 553 looks like a reference -- Missing reference section? 'IPSEC' on line 557 looks like a reference -- Missing reference section? 'IPv6-ALLOC' on line 561 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 36 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Supratik Bhattacharyya 3 Expires 18 November 2001 Christophe Diot 4 Sprint ATL 5 Leonard Giuliano 6 Juniper Networks 7 Rob Rockell 8 Sprint E|Solutions 9 John Meylor 10 Dave Meyer 11 Cisco Systems 12 Greg Shepherd 13 Juniper Networks 14 Brian Haberman 15 Nortel Networks 16 18 May 2001 18 An Overview of Source-Specific Multicast(SSM) Deployment 19 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC 2119]. 46 Abstract 48 This document provides an overview of the Source-Specific Multicast 49 (SSM) service and its deployment using the PIM-SM and IGMP/MLD 50 protocols. The network layer service provided by SSM is a "channel", 51 identified by an SSM destination IP address (G) and a source IP 52 address S. The IP address range 232/8 has been designated as SSM 53 addresses by IANA for IPv4. An SSM address range already exists for 54 IPv6. A source S transmits IP datagrams to an SSM address G. A 55 receiver can receive these datagrams by subscribing to the channel 56 (S,G). Channel subscription is supported by version 3 of the IGMP 57 protocol for IPv4 and version2 of the MLD protocol for IPv6. The 58 interdomain tree for forwarding UDP datagrams is rooted at the source 59 S. Although a number of protocols exists for constructing source- 60 rooted forwarding trees, this document discusses the most widely 61 implemented one - PIM Sparse Mode [PIM-SM-NEW]. 63 This document is intended as a starting point for deploying SSM 64 services. It provides an architectural overview of SSM and describes 65 how it solves a number of problems faced in the deployment of inter- 66 domain multicast. It outlines changes to protocols and applications 67 both at end-hosts and routers for supporting SSM, with pointers to 68 more detailed documents where appropriate. Issues of interoperability 69 with the existing multicast service model (as defined by RFC 1112) 70 are also discussed. 72 1. Terminology 74 This section defines some terms that are used in the rest of this 75 document : 77 Any-Source Multicast (ASM) : This is the IP multicast service model 78 defined in RFC 1112 [RFC1112]. An IP datagram is transmitted to a 79 "host group", a set of zero or more hosts identified by a single IP 80 destination address (224.0.0.0 through 239.255.255.255 for IPv4). This 81 model supports one-to-many and and many-to-many multicast groups. 82 Hosts may join and leave the group any time. There is no restriction 83 on the location or number of receivers, and a source need not be a 84 member of the host group it transmits to. 86 Source-Specific Multicast (SSM) : This is the multicast service model 87 defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to 88 an SSM address G, and receivers can receive this datagram by 89 subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] 90 and supports one-to-many multicast.The address range 232/8 has been 91 assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the 92 range FF2::/11 through FF3x::/11 is defined for SSM services [SSM- 93 IPV6]. 95 Source-Filtered Multicast (SFM) : This is a variant of the multicast 96 service model defined in RFC 1112. A source transmits IP datagrams to 97 a host group address in the range of 224.0.0.0 to 239.255.255.255. 98 However, each "upper layer protocol module" can now request data sent 99 to a host group G by only a specific set of sources, or can request 100 data sent to host group G from all BUT a specific set of sources. Such 101 support for source filtering is provided by version 3 of the Internet 102 Group Management Protocol (or IGMPv3) [IGMPv3] for IPv4, and version 2 103 of the Multicast Listener Discovery (or MLD) protocol for IPv6 104 [MLDv2]. We shall henceforth refer to these two protocols as "SFM- 105 capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and 106 MLDv1 - do not provide support for source-filtering, and are referred 107 to as "non-SFM-capable". 109 2. Current Interdomain Multicast Architecture 111 The current interdomain multicast architecture is based on the ASM 112 service model. To become a member of a particular host group end- 113 hosts register multicast group membership with querier routers 114 handling multicast group membership function using the IGMP version 2 115 (IGMPv2) protocol [RFC2236] for IPv4 or the MLD version 1 (MLDv1) 116 protocol [RFC2710] for IPv6. These protocols are non-SFM-capable, 117 hence source-filtering capabilities are unavailable to receivers. 119 Multicast-capable routers then exchange messages with each other 120 according to a routing protocol to construct a distribution tree 121 connecting all the end-hosts. A number of different protocols exist 122 for building multicast forwarding trees, which differ mainly in the 123 type of delivery tree constructed [IPMULTICAST,PIM-ARCH, RFC2362, 124 PIM-SM-NEW, PIM-DM]. Of these, the Protocol Independent Multicast 125 Sparse-Mode (PIM-SM) protocol [PIM-SM-NEW] is the most widely 126 deployed in today's public networks. PIM-SM, by default, constructs a 127 single spanning multicast tree rooted at a core rendezvous point or 128 RP for all group members within a domain. Local sources then send 129 their data to this RP which forwards the data down the shared tree to 130 interested local receivers. A receiver joining a host group can only 131 specify interest in the entire group and therefore will receive data 132 for any source to this group forwarded on the shared tree. 133 Distribution via a shared tree can be effective for certain types of 134 traffic, e.g., where the number of sources is large since forwarding 135 on the shared tree is performed via a single multicast forwarding 136 entry. However, there are many cases (e.g., Internet broadcast type 137 streams) where forwarding from a source to a receiver is most 138 efficient via the shortest path. PIM-SM also allows a designated 139 router serving a particular subnet to switch to a source-based 140 shortest path tree for a given source once the source's address is 141 learned from data arriving on the shared tree. This capability 142 provides for distribution of data from local sources to local 143 receivers both sharing a common RP inside a given PIM domain. 145 It is also possible for RP's to learn about sources in other PIM 146 domains by using the Multicast Source Discovery Protocol (MSDP) 147 [MSDP]. Once an active remote source is identified, an RP can join 148 the shortest path tree to that source and obtain data to forward down 149 the local shared tree on behalf of interested local receivers. 150 Designated routers for particular subnets can again switch to a 151 source-based shortest path tree for a given remote source once the 152 source's address is learned from data arriving on the shared tree. 154 The IGMPv2/PIM-SM/MSDP-based interdomain multicast architecture is 155 widely deployed in IPv4 networks and can be particularly effective 156 for groups where sources are not known in advance by hosts joining a 157 group, or when sources come and go dynamically, or when forwarding on 158 a common shared tree is found to be operationally beneficial. 160 3. Problems with Current Architecture 162 There are several deployment problems associated with current 163 multicast architecture: 165 A) Inefficient handling of well-known sources : 167 In cases where the address of the source is well known in advance 168 of the receiver joining the group, and when the shortest 169 forwarding path is the preferred forwarding mode, then shared tree 170 mechanisms and MSDP only are not necessary. 172 B) Lack of access control : 174 In the ASM service model, a receiver can not specify which 175 specific sources it would like to receive when it joins a given 176 group. A receiver will be forwarded data sent to a host group by 177 any source. 179 C) Address Allocation : 181 Address allocation is one of core deployment challenges posed by 182 the ASM service model. The current multicast architecture does not 183 provide an adequate solution to prevent address collisions among 184 multiple applications. The problem is more serious for IPv4 than 185 IPv6 since the total number of multicast addresses is smaller. A 186 static address allocation scheme, GLOP [GLOP00] has been proposed 187 as an interim solution for IPv4; however, GLOP addresses are 188 allocated per registered AS, which is inadequate in cases where 189 the number of sources exceeds the AS numbers available for 190 mapping. Proposed longer-term solutions such as the Multicast 191 Address Allocation Architecture (MAAA) are generally perceived as 192 being too complex (with respect to the dynamic nature of multicast 193 address allocation) for widespread deployment. However, the 194 unicast-prefix-based multicast architecture of IPv6 [HABE1] 195 expands on the GLOP approach, simplifies the multicast address 196 allocation solution and incorporates support for source-specific 197 multicast addresses. 199 4. Source Specific Multicast (SSM) : Benefits and Requirements 201 As mentioned before, Source Specific Multicast (SSM) defines a 202 service model for a "channel" identified by an (S,G) pair, where S is 203 a source address and G is an SSM address. This model can be realized 204 by a protocol architecture, where packet forwarding is restricted to 205 shortest path trees rooted at specific sources, and channel 206 subscriptions are described using an SFM-capable group management 207 protocol such as IGMPv3 or MLDv2. 209 The SSM service model alleviates all of the deployment problems 210 described earlier : 212 4.1 SSM lends itself to an elegant solution to the access control 213 problem. Only a single source S can transmit to a channel (S,G) 214 where G is an SSM address. This makes it significantly more 215 difficult to spam an SSM channel than an ASM host group. In 216 addition, data from unrequested sources need not be forwarded by 217 the network, which prevents unnecessary consumption of network 218 resources. 220 4.2 SSM defines channels on a per-source basis; hence SSM 221 addresses are "local" to each source. This averts the problem of 222 global allocation of SSM addresses, and makes each source 223 independently responsible for resolving address collisions for the 224 various channels that it creates. 226 4.3 The distribution tree for an SSM channel (S,G) is always 227 rooted at the source S. Thus there is no need for a shared tree 228 infrastructure. In terms of the IGMPv2/PIM-SM/MSDP architecture, 229 this implies that neither the RP-based shared tree infrastructure 230 of PIM-SM nor the MSDP protocol is required. Thus the complexity 231 of the multicast routing infrastructure for SSM is low, making it 232 viable for immediate deployment and more efficient for well-known 233 sources. 235 4.4 It is widely held that point-to-multipoint applications such 236 as Internet TV will dominate the Internet multicast application 237 space in the near future. The SSM model is ideally suited for such 238 applications. 240 A protocol architecture for SSM requires the following : 242 A) Source specific host membership reports : A SFM-capable 243 protocol is needed to allow a host to describe specific sources 244 from which it would like to receive data. 246 B) Shortest path forwarding. DR's must be capable of recognizing 247 receiver-initiated, source specific host reports and initiating 248 (S,G) joins directly and immediately as result. 250 C) Elimination of shared tree forwarding. In order to achieve 251 global effectiveness of SSM, all networks must agree to restrict 252 data forwarding to source trees (i.e., prevent shared tree 253 forwarding) for SSM addresses. The address range 232/8 has been 254 allocated by IANA for deploying source-specific IPv4 multicast 255 (SSM) services. In this range, SSM is the sole service model. For 256 IPv6, a source-specific multicast address range has been defined 257 in [HABE1], as a special case of unicast prefix-based multicast 258 addresses. 260 5. SSM Framework 262 Figure 1 illustrates the elements in an end-to-end SSM framework. 264 -------------------------------------------------------------- 265 IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION 266 SSM range exists for IPv6 267 -------------------------------------------------------------- 268 | 269 v 270 +--------------+ session directory/web page 271 | source,group | SESSION DESCRIPTION 272 -------------------------------------------------------------- 273 ^ | 274 Query | | s,g 275 | v 276 +-----------------+ host 277 | SSM-aware app | CHANNEL DISCOVERY 278 -------------------------------------------------------------- 279 | SSM-aware app | SSM-AWARE APPLICATION 281 -------------------------------------------------------------- 282 | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING 283 +---------------+ 284 |(source specific host report) 285 | 286 -------------------------------------------------------------- 287 v 288 +-----------------+ Querier Router 289 | IGMPv3/MLDv2 | QUERIER 290 -------------------------------------------------------------- 291 | PIM-SSM | PIM-SSM ROUTING 292 +------------+ Designated Router 293 | 294 | (S,G) Join only 295 v 296 +-----------+ Core Router 297 | PIM-SSM | 298 +-----------+ 299 | 300 | (S,G) Join only 301 V 303 Figure 1 : SSM Framework: elements in end-to-end model 305 We now discuss the framework elements in detail : 307 5.1 Address Allocation 309 For IPv4, the address range of 232/8 has been assigned by IANA for 310 SSM. Sessions expecting SSM functionality MUST allocate addresses 311 from the 232/8 range. To ensure global SSM functionality in 232/8, 312 including in networks where routers run non-SFM-capable protocols, 313 operational policies are being proposed [SSM-BCP] which prevent data 314 sent to 232/8 from being delivered via shared trees. 316 Note that it is possible to achieve the benefit of direct and 317 immediate (S,G) joins in response to IGMPv3 reports in other ranges 318 than 232/8.However, non-SSM address ranges allow for concurrent use 319 of both the ASM and SSM service models. Therefore, while we can 320 achieve the PIM join efficiency in the non-SSM address range with 321 IGMPv3, it is not possible to prevent the creation of shared trees or 322 shared tree data delivery, and thus cannot provide for certain types 323 of access control or assume per-source unrestricted address use as 324 with the SSM address range. 326 In case of IPv6, [HABE1] has defined an extension to the addressing 327 architecture to allow for unicast prefix-based multicast addresses. 329 In this case, bytes 0-3 (starting from the least significant byte) of 330 the IP address is used to specify a multicast group id, bytes 4-11 is 331 be used to specify a unicast address prefix (of up to 64 bits) that 332 owns this multicast group id, and byte 12 is used to specify the 333 length of the prefix. A source-specific multicast address can be 334 specified by setting both the prefix length field and the prefix 335 field to zero. Thus IPv6 allows for 2^32 SSM addresses per scope for 336 every source, while IPv4 allows 2^24 addresses per source. 338 5.2 Channel Discovery 340 In case of ASM, receivers need to know only the group address for 341 a specific session. In the IGMPv2/PIM-SM/MSDP architecture, 342 designated routers discover an active source via PIM-SM and MSDP, 343 and then graft themselves to the multicast forwarding tree rooted 344 at that source. 346 In case of the SSM, an application on an end-host must know both 347 the SSM address G and the source address S before subscribing to a 348 channel. Thus the function of channel discovery becomes the 349 responsibility of applications. This information can be made 350 available in a number of ways, including via web pages, sessions 351 announcement applications, etc. The exact mechanisms for doing 352 this is outside the scope of this framework document. 354 5.3. SSM-Aware Applications 356 -- For applications sourcing content expected to be available to 357 receivers via SSM channels, the session must be advertised 358 including a source address as well as an SSM address. 360 -- Applications expecting to subscribe to an SSM channel must be 361 capable of specifying a source address in addition to an SSM 362 address. In other words, the application must be "SSM-aware". 364 Specific API requirements are identified in [THAL00]. 366 5.4. IGMPv3 for SSM 368 The currently deployed version of IGMP (IGMPv2) allows end-hosts 369 to register their interest in a multicast group by specifying a 370 class-D IP address for IPv4. However in order to implement the SSM 371 service model, an end-host must specify a source's unicast address 372 as well as an SSM address. This capability is provided by the 373 recently proposed IGMP version 3 (IGMPv3). IGMPv3 supports "source 374 filtering", i.e., the ability of an end-system to express interest 375 in receiving data packets sent only by SPECIFIC sources, or from 376 ALL BUT some specific sources. Thus, IGMPv3 provides a superset of 377 the capabilities required to realize the SSM service model. Hence 378 an upgrade from IGMPv2 to IGMPv3 is an essential change for 379 implementing SSM. 381 IGMPv3 requires the API to provide the following operation (or its 382 logical equivalent) [CAIN99]: 384 IPMulticastListen (Socket, IF, G, filter-mode, source-list) 386 As explained in the IGMPv3 specifications [CAIN99], the above 387 IPMulticastListen() operation subsumes the group-specific join and 388 leave operations of IGMPv2. Performing (S,G)-specific joins and 389 leaves is also trivial. A join operation is equivalent to : 391 IPMulticastListen (Socket,IF,G,INCLUDE,{S}) 393 and a leave operation is equivalent to 395 IPMulticastListen (Socket,IF,G,EXCLUDE,{S}) 397 There are a number of backward compatibility issues between IGMP 398 versions 2 and 3 which have to be addressed. There are also some 399 additional requirements for using IGMPv3 for the SSM address 400 range. A detailed discussion of these issues is provided in [SSM- 401 IGMPv3]. 403 5.5 MLDv2 for SSM 405 The Multicast Listener Discovery (MLD) protocol used by an IPv6 router 406 to discover the presence of multicast listeners on its directly attached 407 links, and to discover the multicast addresses that are of interest to 408 those neighboring nodes. Version 1 of MLD [DEER99] is derived from 409 IGMPv2 and allows a multicast listener to specify the multicast group(s) 410 that it is interested in. Version 2 of MLD [VIDA01] is derived from, and 411 provides the same support for source-filtering as, IGMPv3. 413 5.6. PIM-SM Modifications for SSM 415 PIM-SM [PIM-SM-NEW] itself supports two types of trees, a shared tree 416 rooted at a core (RP), and a source-based shortest path tree. Thus 417 PIM-SM already supports source-based trees; however, PIM-SM is not 418 designed to allow a router to choose between a shared tree and a 419 source-based tree. In fact, a receiver always joins a PIM shared tree 420 to start with, and may later be switched to a per-source tree by its 421 adjacent edge router. 423 A key to implementing SSM is eliminate the need for starting with a 424 shared tree and then switching to a source-specific tree. This 425 involves several changes to PIM-SM as described in [PIM-SM-NEW]. The 426 resulting PIM functionality is described as PIM-SSM. The most 427 important changes to PIM-SM with respect to SSM are as follows: 429 -- When a DR receives an (S,G) join request with the address G in 430 the SSM address range, it must initiate a (S,G) join and NEVER a 431 (*,G) join. 433 --Core routers (i.e. routers that do not have directly attached 434 hosts) must not propagate (*,G) joins for group addresses in the 435 SSM address range. 437 --Rendezvous Points (RPs) must not accept PIM Register messages or 438 (*,G) Join messages in the SSM address range. 440 The specific architectural issues associated with PIM-SSM and 441 IGMPv3/MLDv2 are detailed in [SSM-ARCH]. 443 6. Interoperability with Existing Multicast Service Models 445 Interoperability with ASM is one of the most important issues in 446 moving to SSM deployment. ASM and SSM will always coexist; hence 447 there will be two service models for Internet multicast. SSM is the 448 ONLY service model for the SSM address range (232/8 for IPv4 and 449 FF::/8 for IPv6) - the correct protocol behaviour for this range is 450 specified in [SSM-ARCH]. The ASM service model will be offered for 451 the non-SSM adddress range, where receivers can issue (*,G) join 452 requests to receive multicast data. A receiver is also allowed to 453 issue an (S,G) join request in the non-SSM address range; however, in 454 that case there is no guarantee that it will receive service 455 according to the SSM model. 457 Another backward compatibility issue concerns the MSDP protocol, 458 which is used between PIM-SM rendezvous points (RPs) to discover 459 multicast sources across multiple domains. SSM obviates the needs for 460 MSDP, but MSDP is still required to support ASM for non-SSM class-D 461 IPv4 addresses. In order to ensure that SSM is the sole forwarding 462 model in 232/8, RPs must not accept, originate or forward MSDP SA 463 messages for the SSM address range [SSM-BCP]. 465 7. Security Considerations 467 SSM does not introduce new security considerations for IP multicast. 468 It can help in preventing denial-of-service attacks resulting from 469 unwanted sources transmitting data to a multicast channel (S, G). 470 However no guarantee is provided. 472 8. Acknowledgments 474 We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Sue Moon 475 and Timothy Roscoe at Sprintlabs, Hugh Holbrook, Isidor Kouvelas, 476 Tony Speakman and Nidhi Bhaskar at Cisco Systems for participating in 477 lengthy discussions and design work on SSM, and providing feedback on 478 this document. Thanks are also due to Mujahid Khan and Ted Seely at 479 SprintLink, Tom Pusateri at Juniper Networks, Bill Fenner at AT&T 480 Research, Kevin Almeroth at the University of California Santa 481 Barbara, Brian Levine at the University of Massachusetts Amherst, 482 Brad Cain at Cereva Networks and Hugh LaMaster at NASA for their 483 valuable insights and continuing support. 485 9. References: 487 [EXPRESS] H. Holbrook and D.R. Cheriton. IP Multicast Channels : 488 EXPRESS Support for Large-scale Single-Source Applications. In 489 Proceedings of SIGCOMM 1999. 491 [IANA-ALLOCATION] Internet Assigned Numbers Authority. 492 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 494 [RFC2236] W. Fenner. Internet Group Management Protocol, Version 2. 495 Request For Comments 2236. 497 [IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan. 498 Internet Group Management Protocol, Version 3. Work in Progress. 500 [SSM-IGMPv3] H. Holbrook and B. Cain. IGMPv3 for SSM. Work in 501 Progress. 503 [SSM-ARCH] H. Holbrook and B. Cain. Source-Specific Multicast for 504 IP. Work in Progress. 506 [IPMULTICAST] S. Deering and D. Cheriton. Multicast Routing in 507 Datagram Networks and Extended LANs. ACM Transactions on Computer 508 Systems, 8(2):85-110, May 1990. 510 [PIM-ARCH] S. Deering et al. PIM Architecture for Wide-Area 511 Multicast Routing. IEEE/ACM Transaction on Networking, pages 153-162, 512 April 1996. 514 [RFC2362] D. Estrin et al. Protocol Independent Multicast - Sparse 515 Mode (PIM-SM) : Protocol Specification. Request for Comments, 2362. 517 [PIM-SM] Bill Fenner, et al. Protocol Independent Multicast - Sparse 518 Mode (PIM-SM) : Protocol Specifications (Revised). Work in Progress. 520 [PIM-DM] S. Deering et al. Protocol Independent Multicast Version 2 521 Dense Mode Specification. Work in Progress. 523 [MSDP] Farinacci et al. Multicast Source Discovery Protocol. Work in 524 Progress. 526 [MCAST-DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. 527 Balensiefen. Deployment Issues for the IP Multicast Service and 528 Architecture. In IEEE Networks Magazine's Special Issue on 529 Multicast, January, 2000. 531 [SSM-RULES] H. Sandick and B. Cain. PIM-SM Rules for Support of 532 Single-Source Multicast. Work in Progress. 534 [MSF-API] Dave Thaler, Bill Fenner and Bob Quinn. Socket Interface 535 Extensions for Multicast Source Filters. Work in Progress. 537 [RFC2770] GLOP Addressing in 233/8. Request For Comments 2770. 539 [RCVR-INTEREST] B. Levine et al. Consideration of Receiver Interest 540 for IP Multicast Delivery. In Proceedings of IEEE Infocom, March 541 2000. 543 [SSM-BCP] G. Shepherd et al. Source-Specific Protocol Independent 544 Multicast in 232/8. Work in Progress. 546 [RFC2710] S. Deering, W. Fenner and B. Haberman. Multicast Listener 547 Discovery for IPv6. Request for Comments 2710. 549 [MLDv2] R. Vida, et. al. 550 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. 551 Work in progress. 553 [SSM-IPv6] B. Haberman and D. Thaler. 554 Unicast-Prefix-Based IPv6 Multicast Addresses. Work in 555 Progress. 557 [IPSEC] S. Kent, R. Atkinson. 558 Security Architecture for the Internet Protocol. Request for 559 Comments 2401. 561 [IPv6-ALLOC] B. Haberman. 562 Dynamic Allocation Guidelines for IPv6 Multicast Addresses. 563 Work in Progress. 565 12. Authors' Address: 567 Supratik Bhattacharyya 568 Christophe Diot 569 Sprint Advanced Technology Labs 570 One Adrian Court 571 Burlingame CA 94010 USA 572 {supratik,cdiot}@sprintlabs.com 573 http://www.sprintlabs.com 575 Leonard Giuliano 576 Greg Shepherd 577 Juniper Networks, Inc. 578 1194 North Mathilda Avenue 579 Sunnyvale, CA 94089 USA 580 {lenny,shep}@juniper.net 582 Robert Rockell 583 Sprint E|Solutions 584 Reston Virginia USA 585 rrockell@sprint.net 587 John Meylor 588 Dave Meyer 589 Cisco Systems 590 San Jose CA USA 591 {jmeylor,dmm,shep@cisco.com} 593 Brian Haberman 594 Nortel Networks 595 haberman@nortelnetworks.com