idnits 2.17.1 draft-ietf-mboned-mcast-apps-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 1999) is 8893 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: 'IGMPV2' is mentioned on line 106, but not defined == Missing Reference: 'RMT BLOCKS' is mentioned on line 937, but not defined == Missing Reference: 'RMT DESIGN' is mentioned on line 937, but not defined == Unused Reference: 'MASC' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'RM' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'RM BLOCKS' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: 'RM DESIGN' is defined on line 1202, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'AnyCast') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bradner' -- Possible downref: Non-RFC (?) normative reference: ref. 'Canetti' -- Possible downref: Non-RFC (?) normative reference: ref. 'Chouinard' -- Possible downref: Non-RFC (?) normative reference: ref. 'E2EQOS' ** Downref: Normative reference to an Informational RFC: RFC 2502 (ref. 'DIS') -- Possible downref: Non-RFC (?) normative reference: ref. 'Estrin' ** Downref: Normative reference to an Informational RFC: RFC 2588 (ref. 'Finlayson') -- Possible downref: Non-RFC (?) normative reference: ref. 'HNRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IMJ' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kermode' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MASC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maufer' -- Possible downref: Non-RFC (?) normative reference: ref. 'Miller' -- Possible downref: Non-RFC (?) normative reference: ref. 'MADCAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'MZAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Obraczka' -- Possible downref: Non-RFC (?) normative reference: ref. 'Rizzo' ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. 'RM') -- Possible downref: Non-RFC (?) normative reference: ref. 'RM BLOCKS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RM DESIGN' -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP API' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SADP' ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' ** Obsolete normative reference: RFC 2001 (ref. 'SlowStart') (Obsoleted by RFC 2581) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBoneD Working Group Bob Quinn 2 Internet Engineering Task Force Stardust Forums 3 INTERNET-DRAFT Kevin Almeroth 4 25 June 1999 UCSB 5 Expires December 1999 7 IP Multicast Applications: 8 Challenges and Solutions 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the challenges involved with designing and 37 implementing multicast applications. It is an introductory guide 38 for application developers that highlights the unique considerations 39 of multicast applications as compared to unicast applications. 41 To this end, the document presents a taxonomy of multicast 42 application I/O models and examples of the services they can 43 support. It then describes the service requirements of these 44 multicast applications, and the recent and ongoing efforts to build 45 protocol solutions to support these services. 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 49 Table of Contents 51 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 53 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4 57 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4 58 2.1 Essential Protocol Components. . . . . . . . . . . . . . 5 59 2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5 60 2.1.2 Send without a Join. . . . . . . . . . . . . . . . . 6 62 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6 63 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8 64 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9 65 3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10 67 4. Common Multicast Service Requirements . . . . . . . . . . . 12 68 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12 69 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13 71 5. Unique Multicast Service Requirements . . . . . . . . . . . 14 72 5.1 Address Management . . . . . . . . . . . . . . . . . . . 15 73 5.1.1 Scope Discovery . . . . . . . . . . . . . . . . . . 16 74 5.2 Session Management . . . . . . . . . . . . . . . . . . . 16 75 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 17 76 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 19 77 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20 78 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 22 80 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 23 84 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23 86 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26 90 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 IP Multicast will play a prominent role on the Internet in the 95 coming years. It is a requirement, not an option, if the Internet 96 is going to scale. Multicast allows application developers "to add 97 more functionality without significantly impacting the network" 98 [Bradner]. 100 Developing multicast-enabled applications is ostensibly simple. 101 Having datagram access allows any application to send to a multicast 102 address. A multicast application need only increase the Internet 103 Protocol (IP) time-to-live (TTL) value to more than 1 (the default 104 value) to allow outgoing datagrams to traverse routers. To receive 105 a multicast datagram, applications join the multicast group, which 106 transparently generates an [IGMPV2] group membership report. 108 This apparent simplicity is deceptive, however. Enabling multicast 109 support in applications and protocols that can scale well on a 110 heterogeneous network is a significant challenge. Specifically, 111 sending constant bit rate datastreams, reliable data delivery, 112 security, and managing many-to-many communications all require 113 special consideration. Some solutions are available, but many of 114 these services are still active research areas. 116 1.1 Motivation 118 The purpose of this document is to provide a framework for 119 understanding the challenges of designing and implementing multicast 120 applications. In order to use multicast communications correctly, 121 application developers must first understand the various I/O models 122 and the network services (in addition to basic multicast 123 communication) that are required. Secondly, application developers 124 need to be aware of efforts underway to provide these services. 125 Such efforts range in maturity from deployed commercial products to 126 basic research efforts to evaluate feasibility. 128 Multicast-based applications and services will play an important 129 role in the future of the Internet as continued multicast deployment 130 encourages their use and development. It is important that 131 developers be aware of the issues and solutions available--and 132 especially of their limitations--in order to avoid protocols that 133 negatively impact networks (thereby counter-acting the benefits of 134 multicast) or wasting their efforts "re-inventing the wheel." 136 The hope is that by raising developers' awareness, we can adjust 137 their expectations of finding solutions and lead them to successful, 138 scalable, and "network-friendly" development efforts. 140 1.2 Focus and Scope 142 Our initial premise is that the multicast infrastructure is 143 transparent to applications, so it is not directly relevant to this 144 discussion. Our focus here is on multicast application protocol 145 services, so this document explicitly avoids any discussion of 146 multicast routing issues. We identify and describe the multicast- 147 specific issues involved with developing applications. 149 We assume the reader has a general understanding of the mechanics of 150 multicast, and in this respect we intend to compliment other 151 introductory documents [Maufer, Miller]. Since this is an 152 introductory survey rather than a comprehensive examination, we 153 refer readers to other multicast application requirements 154 descriptions [LSMA, Miller] for more detail. 156 In the remainder of this document we first define the term "IP 157 multicast enabled network," the multicast infrastructure and 158 essential multicast services. Next we describe the types of new 159 functionality that multicast applications can enable and their 160 requirements. We then examine the services that satisfy these 161 requirements, the challenges they present, and provide a brief 162 survey of the solutions available or under development. We wrap up 163 with a discussion of application programming interfaces (APIs) for 164 multicast services. 166 2. IP Multicast Enabled Network 168 An "IP multicast-enabled network" provides end-to-end services in 169 the IP network infrastructure to allow any IP host to send datagrams 170 to an IP multicast address that any number of other IP hosts widely 171 dispersed can receive. 173 At the time of this writing end-to-end "global" multicast service is 174 not yet available, but the size of the "multicast-enabled" Internet 175 is growing. Recent development and deployment of interdomain 176 multicast routing protocols and multicast-friendly Internet 177 exchanges [MIX] have enabled peering between major ISPs. This, 178 along with the increasing availability of compelling content, is 179 spurring deployment and availability of the IP Multicast Enabled 180 Network. 182 In the remainder of this document we assume that the multicast- 183 enabled network is already ubiquitous. Since such a large and 184 growing portion of the global Internet is IP multicast-enabled now, 185 and many enterprise networks (intranets) are also, this perspective 186 is relevant today. 188 2.1 Essential Protocol Components 190 An IP multicast enabled network requires two essential protocol 191 components: 193 1) An IP host-based protocol to allow a receiver application to 194 notify a local router(s) that it has joined the group, and 195 initiate the data flow from all sender(s) within the scope 197 2) An IP router-based protocol to allow any routers with multicast 198 group members (receivers) on their local networks to 199 communicate with other routers to ensure that all datagrams 200 sent to the group address are forwarded to all receivers within 201 the intended scope 203 Ideally, these protocol components are transparent to multicast 204 applications. However, there are two aspects of their functionality 205 requirements that are worth mentioning specifically, since they 206 affect application performance and design. These are the multicast 207 application requirements for: 209 - Expedient Joins and Leaves 210 - Sends without a Join 212 2.1.1 Expedient Joins and Leaves 214 Some applications require expedient group joins and leaves, as their 215 usability or functionality are sensitive to the latency involved 216 with joining and leaving a group. 218 Join Latency: The time it takes for data to begin flowing after an 219 application issues a command to join a multicast group 221 Leave Latency: The time it takes for data to stop flowing after an 222 application issues a command to leave a multicast group 223 [IGMPv2] 225 For example, using distributed a/v as a multicast-based "television" 226 must allow users to "channel surf"--changing channels frequently. 227 Each channel change generates a group leave and group join, so 228 delays in either will affect usability. In a sense, this is more of 229 a user requirement than an application requirement. 231 The functionality of distributed interactive simulations [DIS] is 232 often sensitive to join/leave latency. This is particularly true 233 when trying to exchange information to represent fast moving objects 234 that quickly enter and exit the scope of a simulated environment 235 (e.g. low-flying, fast-moving aircraft). If the join latency is too 236 long, the information provided may be old by the time it is 237 received. 239 A fast leave phase is highly desirable both for effective congestion 240 control mechanisms, to stop undesirable flows quickly, and for the 241 network in general, to better filter unwanted traffic [Rizzo]. 242 Applications cannot affect control over either join or leave 243 latency, but are dependent on the multicast infrastructure to enable 244 expedient operations. This is a basic multicast service 245 requirement. 247 2.1.2 Sends without a Join 249 Applications that send to a multicast address should be able to 250 start sending immediately, without having to join the destination 251 group first. This is important for embedded devices and bursty- 252 source applications with low-delay delivery requirements. 254 The current IGMP-based multicast host model and all current 255 implementations allow senders to send to a group without joining it 256 as a standard feature. 258 3. IP Multicast Application Taxonomy 260 With an IP multicast-enabled network available, some unique and 261 powerful applications and application services are possible. 262 "Multicast enables coordination - it is well suited to loosely 263 coupled distributed systems (of people, servers, databases, 264 processes, devices...)" [Estrin]. 266 A "multicast application" is simply defined as any application that 267 sends to and/or receives from an IP multicast address. These may or 268 may not also reference IP unicast addresses, as we describe later. 270 What differentiates IP multicast applications from one-to-one 271 unicast applications are the other sender and receiver relationships 272 multicast enables. There are three general categories of multicast 273 applications: 275 One-to-Many (1toM): A single host sending to two or more (n) 276 receivers 278 Many-to-Many (MtoM): Any number of hosts sending to the same 279 multicast group address, as well as receiving from it 281 Many-to-One (Mto1): Any number of receivers sending data back to a 282 (source) sender via unicast or multicast 283 +-----------------------------------+ 284 | Host 2->n ("many") | 285 +-------------+---------------------+ 286 | One-Way | Two-Way | 287 +-------------+---------------------| 288 | A B | C D E | 289 +-----------+-------------+---------------------+ 290 | I/O | | S(m)/ S(u)/ S(m)/| 291 | Operations| S(m) R(m) | R(m) R(m) R(u) | 292 +-------+---+-----------+-------------+---------------------| 293 | | 1 | S(m) | 1toM | MtoM | 294 | Host | 2 | R(m) | Mto1 | MtoM | 295 | +---+-----------+-------------+ | 296 | 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM | 297 | | 4 | S(m)/R(u) | Mto1 | 298 |("one")| 5 | S(u)/R(m) | Mto1 | 299 +-------+---+-----------+-----------------------------------+ 301 Legend: S: "Send" (u): "unicast" 302 ------ R: "Receive" (m): "multicast" 304 Table 1: Application types characterized by I/O relationships 305 and destination address types (multicast or unicast) 307 Table 1 defines these application types in terms of the I/O 308 relationships they represent. These categories are defined in terms 309 of the combination of communication mechanisms they use. At the IP 310 level, all multicast I/O is only 1toM or MtoM and unicast is always 311 one-to-one (1to1). The Mto1 category, for example, refers to 312 several possible combinations of IP-level relationships, including 313 unicast. We created the Mto1 category to help differentiate between 314 the many applications and services that use multicast. 316 1toM: MtoM: Mto1: 317 R1 S1/R1 S1 318 / / | \ \ 319 S-R2 S2/R2-+-S3/R3 S2-R 320 \... \ | / .../ 321 Rn Sn/Rn Sn 323 Legend: S: "Sender" 324 ------ R: "Receiver" 326 Figure 1: Generalization of the three application categories 328 Figure 1 illustrates the general model for each of the three 329 multicast application categories. Again it is worth emphasizing 330 that Mto1 is an artificial category defined by the application-level 331 relationship between sender(s) and receiver. At the IP-level, 332 multicast does not provide an Mto1 I/O mechanism, since it does not 333 allow senders to limit receivers, nor even know who they are. 334 Receiver information and limitations are enabled at the application 335 level, as required by the multicast application. 337 We describe each of these general application types in more detail 338 and provide application examples of each in the sub-sections below. 339 The list of examples is not comprehensive, but attempts to define 340 the prominent multicast application and service types in each of the 341 three general categories. We reference the items in these lists in 342 the remainder of this document as we describe their specific service 343 requirements, define the challenges they present, and reference 344 solutions available or under development. 346 3.1 One-to-Many Applications 348 One-to-Many (1toM) applications have a single sender, and multiple 349 simultaneous receivers. Entry B1 in Table 1 represents the classic 350 1toM relationship. Entry B3 differs only slightly, as the sender 351 also acts as receiver (i.e. it has loopback enabled). 353 When people think of multicast, they most often think of broadcast- 354 based multimedia applications: television (video) and radio (audio). 355 This is a reasonable analogy and indeed these are significant 356 multicast applications, but these are far from the extent of 357 applications that multicast can enable. Audio/Video distribution 358 represents a fraction of the multicast application possibilities, 359 and most do not have analogs in today's consumer broadcast industry. 361 a) Scheduled audio/video (a/v) distribution: Lectures, 362 presentations, meetings, or any other type of scheduled event 363 whose multimedia coverage could benefit an audience (i.e. 364 television and radio "broadcasts"). One or more constant-bit- 365 rate (CBR) datastreams and relatively high-bandwidth demands 366 characterize these applications. When more than one datastream 367 is present--as with an audio/video combination--the two are 368 synchronized and one typically has a higher priority than the 369 other(s). For example, in an a/v combination it is more 370 important to ensure a legible audio stream, than perfect video. 372 b) Push media: News headlines, weather updates, sports scores, or 373 other types of non-essential dynamic information. "Drip-feed," 374 relatively low-bandwidth data characterize these applications. 376 c) File Distribution and Caching: Web site content, executable 377 binaries, and other file-based updates sent to distributed end- 378 user or replication/caching sites 380 d) Announcements: Network time, multicast session schedules, 381 random numbers, keys, configuration updates, (scoped) network 382 locality beacons, or other types of information that are 383 commonly useful. Their bandwidth demands can vary, but 384 generally they are very low bandwidth. 386 e) Monitoring: Stock prices, Sensor equipment (seismic activity, 387 telemetry, meteorological or oceanic readings), security 388 systems, manufacturing or other types of real-time information. 389 Bandwidth demands vary with sample frequency and resolution, 390 and may be either constant-bit-rate or bursty (if event- 391 driven). 393 3.2 Many-to-Many Applications 395 In many-to-Many (MtoM) applications two or more of the receivers 396 also act as senders. In other words, MtoM applications are 397 characterized by two-way multicast communications. 399 The many-to-many capabilities of IP multicast enable the most unique 400 and powerful applications. Each host running an MtoM application 401 may receive data from multiple senders while it also sends data to 402 all of them. As a result, many-to-many applications often present 403 complex coordination and management challenges. 405 f) Multimedia Conferencing: Audio/Video and whiteboard comprise 406 the classic conference application. Having multiple 407 datastreams with different priorities characterizes this type 408 of application. Co-ordination issues--such as determining who 409 gets to talk when--complicate their development and usability. 410 There are common heuristics and "rules of play", but no 411 standards exist for managing conference group dynamics. 413 g) Synchronized Resources: Shared distributed databases of any 414 type (schedules, directories, as well as traditional 415 Information System databases). 417 h) Concurrent Processing: Distributed parallel processing. 419 i) Collaboration: Shared document editing. 421 j) Distance Learning: This is a one-to-many a/v distribution 422 application with "upstream" capability that allows receivers to 423 question the speaker(s). 425 k) Chat Groups: These are like text-based conferences, but may 426 also provide simulated representations ("avatars") for each 427 "speaker" in simulated environments. 429 l) Distributed Interactive Simulations [DIS]: Each object in a 430 simulation multicasts descriptive information (e.g. telemetry) 431 so all other objects can render the object, and interact as 432 necessary. The bandwidth demands for these can be tremendous, 433 as the number of objects and the resolution of descriptive 434 information increases. 436 m) Multi-player Games: Many multi-player games are simply 437 distributed interactive simulations, and may include chat group 438 capabilities. Bandwidth usage can vary widely, although 439 today's first-generation multi-player games attempt to minimize 440 bandwidth usage to increase the target audience (many of whom 441 still use dial-up modems). 443 n) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth 444 demands vary based on the encoding technique, sample rate, 445 sample resolution, number of channels, etc. 447 3.3 Many-to-One Applications 449 Unlike the one-to-many and many-to-many application categories, the 450 many-to-one (Mto1) category does not represent a communications 451 mechanism at the IP layer. Mto1 applications have multiple senders 452 and one (or a few) receiver(s), as defined by the application layer. 453 Table 1 shows that Mto1 applications can be one-way or use a two-way 454 request/response type protocol, where either senders or receiver(s) 455 may generate the request. Figure 2 characterizes the I/O 456 relationship possibilities in Mto1 applications: 458 1) S1 2) S1 3) S1 4) S1 459 \ \ \ \ 460 S2-R S2-R S2-R S2-R 461 .../ .../ .../ .../ 462 Sn Sn Sn Sn 464 Data(m) Request(m) Request(m) Request(u) 465 ------> ----------> <---------- ----------> 466 Response(u) Response(u) Response(m) 467 <----------- -----------> <---------- 469 Figure 2: Characterization of Mto1 I/O possibilities 471 Mto1 applications have many scaling issues. Too many simultaneous 472 senders can potentially overwhelm receiver(s), a condition 473 characterized as an "implosion problem." Another considerable 474 scaling problem is the large amount of state in the network that 475 having many multicast senders generates. This is largely 476 transparent to applications and the effect may be diminished in the 477 future with the use of bidirectional trees in multicast routing 478 protocols, but nonetheless it should be considered by application 479 designers. 481 No standards yet exist for alternate and equivalent Mto1 application 482 designs, but there are a number of possibilities to consider [HNRS]. 483 Since the main advantage of using multicast in a Mto1 application is 484 that senders need not know the receiver(s) unicast address(es), one 485 alternative is for the each receiver to advertise its unicast 486 address via multicast. However, since this strategy still leaves 487 the potential for implosion on each receiver, additional strategies 488 may be needed to distribute the load. For example, it may be 489 possible to increase the number of receivers (in a "flat" receiver 490 topology) or establish localized receivers (in a "hierarchical" 491 topology) as used in "local recovery" (section 5.3). Such methods 492 have coordination issues, and although standard solutions have not 493 yet been identified, Mto1 application developers should consider 494 their alternatives carefully. 496 o) Resource Discovery: Service Location, for example, leverages IP 497 Multicast to enable something like a "host anycasting service" 498 capability [AnyCast]: A multicast receiver to send a query to a 499 group address, to elicit responses from the closest host so 500 they can satisfy the request. The responses might also contain 501 information that allows the receiver to determine the most 502 appropriate (e.g. closest) service provider to use. 504 In Table 1, this application is entry D4. It is also 505 illustrated in Figure 2 by possibility number 3. Alternately, 506 the response could be to a multicast rather than unicast 507 address, although technically that would make it an MtoM 508 application type (this is how the . Service Location Protocol 509 [SLP] operates, when a user agent attempts to locate a 510 directory agent). 512 p) Data Collection: This is the converse of a one-to-many 513 "monitoring" application described earlier. In this case there 514 may be any number of distributed "sensors" that send data to a 515 data collection host. The sensors might send updates in 516 response to a request from the data collector, or send 517 continuously at regular intervals, or send spontaneously when a 518 pre-defined event occurs. Bandwidth demands can vary based on 519 sample frequency and resolution. 521 This is illustrated in Table 1 by entries A1 and A3, the only 522 difference being that A3 has a loopback interface. In Figure 523 2, this is possibility number 1. Since the number of receivers 524 can easily be more than one, this is really an MtoM 525 application. 527 q) Auctions: The "auctioneer" starts the bidding by describing 528 whatever it is for sale (product or service or whatever), and 529 receivers send their bids privately or publicly (i.e. to a 530 unicast or multicast address). 532 This is possibility number 2 in Figure 2, and D5 in Table 1. 533 The response could be sent to a multicast address, although 534 technically that would make it an MtoM application. 536 r) Polling: The "pollster" sends out a question, and the "pollees" 537 respond with answers. This is possibility number 2 in Figure 538 2, and could also be characterized as an MtoM application if 539 the response is to a multicast address. 541 s) Juke Box: Allows near-on-demand a/v playback. Receivers use an 542 "out-of-band" protocol mechanism (via web, email, unicast or 543 multicast requests, etc.) to send their playback request into a 544 scheduling queue [IMJ]. 546 This is characterized by possibility number 4 in Figure 2, and 547 entry D4 in Table 1. The initial unicast request is the only 548 difference between this type of application and a typical 1toM. 549 If that initial request were sent to a multicast address, this 550 would effectively be an MtoM application. 552 t) Accounting: This is basically data collection but is worth 553 separating since it is such an important application. In some 554 multicast applications it is imperative to know information 555 about each receiver, possibly in real-time. But such 556 information can be overwhelming. Current mechanisms, like RTCP 557 (which is actually MtoM since it is multicast but could be made 558 Mto1), use scaling techniques but trade-off information 559 granularity. As a group grows the total amount of feedback is 560 constant but each receiver sends less. 562 4. Common Multicast Service Requirements 564 Some multicast application service requirements are common to 565 unicast network applications as well. We characterize two of them 566 here--bandwidth and delay requirements. 568 4.1 Bandwidth Requirements 570 Figure 3 shows multicast applications approximate bandwidth 571 requirements. 573 Unicast and multicast applications both need to design applications 574 to adapt to the variability of network conditions. But as we 575 describe in section 4.1, it is the need to accommodate multiple 576 heterogeneous multicast receivers--with their diversity of bandwidth 577 capacity and delivery delays--that presents the unique challenge for 578 multicast applications to satisfy these requirements. 580 | 581 1toM | b, d c, e a 582 | 583 MtoM | k g, i f, h, j, l, m, n 584 | 585 Mto1 | o, q, r p, q, t s 586 | 587 +----------------------------------------------- 588 Low Bandwidth High Bandwidth 590 Figure 3: Bandwidth Requirements of applications 592 4.2 Delay Requirements 594 Aside from those with time-sensitive data (e.g. stock prices, and 595 real-time monitoring information), most one-to-many applications 596 have a high tolerance for delay and delay variance (jitter). 597 Constant bit-rate (CBR) data--such as streaming media (audio/video)- 598 -are sensitive to jitter, but applications commonly counteract the 599 effects by buffering data and delaying playback. 601 Most many-to-one and many-to-many multicast applications are 602 intolerant of delays because they are bidirectional, interactive and 603 request/response dependent. As a result, delays should be 604 minimized, since they can adversely affect the application's 605 usability. 607 This need to minimize delays is most evident in (two-way) conference 608 applications, where users cannot converse effectively if the audio 609 or video is delayed more than 500 milliseconds. For this and other 610 examples see Figure 4, which plots multicast applications on a 611 (coarse) scale of sensitivity to delivery delays. 613 | 614 1toM | b, c a, d e 615 | 616 MtoM | g, i, j, k f, h, l, m, n 617 | 618 Mto1 | r o, p, s, t q 619 | 620 +----------------------------------------------- 621 Delay Tolerant Delay Intolerant 623 Figure 4: Delay tolerance of application types 625 For delay-intolerant multicast (or unicast) applications, quality of 626 service (QoS) is the only option. IP networks currently provide 627 only "best effort" delivery, so data are subject to variable router 628 queuing delays and loss due to network congestion (router queue 629 overflows). IP QoS standards do exist now [RSVP] and efforts to 630 enable end-to-end QoS support in the Internet are underway [E2EQOS]. 632 However, QoS support is an IP network infrastructure consideration. 633 Although there are multicast-specific challenges for implementing 634 QoS in the network for multicast flows, they are beyond the control 635 of applications, so further discussion of the QoS protocols and 636 services is beyond the scope of this document. 638 5. Unique Multicast Service Requirements 640 The three application categories described earlier are very general 641 in nature. Within each category and even among each of the 642 application types, specific application instances have a variety of 643 application requirements. One-to-many application types are 644 relatively simple to develop, but as we pointed out there are 645 challenges involved with developing many-to-one and many-to-many 646 applications. Some of these have requirements bandwidth and delay 647 requirements, similar to unicast applications. 649 Multicast applications can be further differentiated from unicast 650 applications and from each other by the services they require. In 651 this section we provide a survey of the various services that have 652 unique requirements for multicast applications. 654 +------------------------------------------------------+ 655 | Multicast Application | 656 +--------------------------------------+ +-----------+ 657 +-------------------------------------+| |+----++----+ 658 | Multicast Security || || || | 659 +----------------------+ +----------+| ||Sys-||Co- | 660 +----------++---------+| |+---------+| ||tem ||decs| 661 | Reliable || Address || || Session || ||Time|| | 662 | Delivery || Mgmnt. || || Mgmnt. || || || | 663 +----------++---------++---++---------++---++----++----+ 664 +----------------------------------------++------------+ 665 | Basic IP Multicast Service || IP Unicast | 666 | (e.g. UDP and IGMPv2) || Service | 667 +----------------------------------------++------------+ 669 Figure 5: Multicast service requirements summary 671 Here's the list of multicast application service requirements: 673 Address Management - Coordinated address allocation service that 674 provides some assurances against "address collisions". 676 Session Management - Making session descriptions available (via 677 advertisements and explicit queries) within appropriate scopes, 678 and also enabling registration of new sessions 680 Heterogeneous Receiver Support - Sending to receivers with a wide 681 variety of bandwidth capacities, latency characteristics, and 682 network congestion requires feedback to monitor receiver 683 performance. 685 Reliable Data Delivery - Ensuring that all data sent is received 686 by all receivers 688 Security - Ensuring content privacy among dynamic multicast group 689 memberships, and limiting senders 691 Synchronized Play-Out - Allow multiple receivers to "replay" data 692 received in synchronized fashion 694 In the remainder of this section, we describe each of these 695 application services in more detail, the challenges they present, 696 and the status of standardized solutions. 698 5.1 Address Management 700 One of the first questions facing a multicast application developer 701 is what multicast address to use. Multicast addresses are not 702 assigned to individual hosts, assignments can change dynamically, 703 and addresses sometimes have semantics of their own (e.g 704 Administrative Scoping). Multicast applications require an address 705 management service that provides address allocation or assignment 706 queries: 708 There are a number of ways for applications to learn about multicast 709 addresses: 711 Hard-Coded: Software configuration, encoded in a binary 712 executable, or burned into ROM in embedded devices. These 713 applications typically reference IANA statically allocated 714 multicast addresses (including relative addresses). 716 Advertised: Session announcements (as described in the next 717 section), or via another "out-of-band" query or discovery 718 protocol mechanism. 720 Algorithmically Derived: Using a programmatic algorithm to 721 allocate a statistically random (unused) address. 723 | 724 1toM | c, e a, b d 725 | 726 MtoM | f, j, k, n g, h, i, l, m 727 | 728 Mto1 | r o, p, s q, t 729 | 730 +----------------------------------------------- 731 Hard-Coded Advertised Algorithmic 733 Figure 6: Multicast address usage for application types 735 5.1.1 Scope Discovery 737 Scope Discovery is a function of address management required by some 738 applications. An option for [MADCAP] allows clients to learn which 739 scopes nest inside each other, for the purpose of executing 740 expanding ring searches (among other things) [Kermode]. Scoped 741 Address Discovery Protocol [SADP] allows applications to discover 742 the administratively scoped multicast addresses already allocated to 743 a session within one or more administrative scopes in a hierarchy of 744 nested scopes. These protocols assume the use of Multicast Zone 745 Announcement Protocol [MZAP] as a _back-end_ (transparent to 746 applications), since it enables the creation of such hierarchies. 748 5.2 Session Management 750 Multicast applications need a "namespace" that provides session 751 directory services that can be used to co-ordinate application 752 schedules and resources, and describe session attributes. These map 753 multicast address and port combinations to a date and time, content 754 description, and other session attributes (e.g. bandwidth and delay 755 requirements, encoding, security and authorization methods, etc.). 757 The session description protocol [SDP] is designed for this purpose, 758 but it does not provide the transport for dissemination of these 759 session descriptions, nor does it enable the address allocation and 760 management. SDP only provides the syntax for describing session 761 attributes. 763 SDP session descriptions may be conveyed publicly or privately by 764 means of any number of transports including web (HTTP) and MIME 765 encoded email. The session announcement protocol [SAP] is the de 766 facto standard transport and many multicast-enabled applications 767 currently use it. SAP limits distribution via multicast scoping, 768 but the current protocol definition has scaling issues that need to 769 be addressed. Specifically, the initialization latency for a 770 session directory can be quite long, and it increases in proportion 771 to the number of session announcements. This is to an extent a 772 multicast infrastructure issue, however, as this level of protocol 773 detail should be transparent to applications. 775 The session management service needs to: 776 - Advertise scheduled sessions 777 - Provide a query mechanism for retrieving information about 778 session schedules 780 5.3 Heterogeneous Receiver Support 782 The Internet is a network of networks. IP's strength is its ability 783 to enable seamless interoperability between hosts on disparate 784 network media, the heterogeneous network. 786 When two hosts communicate via unicast--one-to-one--across an IP 787 network, it is relatively easy for senders to adapt to varying 788 network conditions. The Transmission Control Protocol (TCP) 789 provides reliable data transport, and is the model of "network 790 friendly" adaptability. 792 TCP receivers send acknowledgements back to the sender for data 793 delivered. A TCP sender detects data loss from the data sent that 794 is not acknowledged. When it detects data loss, TCP infers that 795 there is network congestion or a low-bandwidth link, and adapts by 796 throttling down its send rate [SlowStart]. 798 User Datagram Protocol (UDP) does not enable a receiver feedback 799 loop the way TCP does, since UDP does not provide reliable data 800 delivery service. As a result, it also does not have a loss 801 detection and adaptive congestion control mechanism as TCP does. 802 However, it is possible for a unicast UDP application to enable 803 similar adaptive algorithms to achieve the same result, or even 804 improve on it. 806 A unicast UDP application that uses a feedback mechanism to detect 807 data loss and adapt the send rate, can do so better than TCP. TCP 808 automatically reduces the "congestion window" when data loss is 809 detected, although the updated send rate may be slower than a CBR 810 audio/video stream requires. When a UDP application detects loss, 811 it can adapt the data itself to accommodate the lower send rate. 812 For example, a UDP application can: 814 - Reduce the data resolution (e.g. send lower fidelity 815 audio/video by reducing sample frequency or frame rate) to 816 reduce data rate. 818 - Modify the data encoding to add redundant data (e.g. forward 819 error correction) offset in time to avoid fate sharing. This 820 could also be "layered", so a percentage of data loss will 821 simply reduce fidelity rather than corrupt the data. 823 - Reduce the send rate of one datastream in order to favor 824 another of higher priority (e.g. sacrifice video in order to 825 ensure audio delivery). 827 - Send data at a lower rate (i.e. with a different encoding) on a 828 separate multicast address and/or port number for high-loss 829 receivers. 831 However, with multicast applications--one-to-many or many-to-many-- 832 which have multiple receivers, the feedback loop design needs 833 modification. If all receivers return data loss reports 834 simultaneously, the sender is easily overwhelmed in the storm of 835 replies. This is known as the "implosion problem." 837 Another problem is that heterogeneous receiver capabilities can vary 838 widely due to the wide range of (static) network media bandwidth 839 capabilities and dynamically due to transient traffic conditions. 840 If a sender adapts its send rate and data resolution based on the 841 loss rate of its worst receiver(s), then it can only service the 842 lowest common denominator. Hence, a single "crying baby" can spoil 843 it for all other receivers. 845 Strategies exist for dealing with these heterogeneous receiver 846 problems. Here are two examples: 848 Shared Learning - When loss is detected (i.e. a sequenced packet 849 isn't received), a receiver starts a random timer. If it 850 receives a data loss report sent by another receiver as it 851 waits for the timer to expire, it stops the timer and does not 852 send a report. Otherwise, it sends a report when the timer 853 expires. The Real-Time Protocol and its feedback-loop 854 counterpart Real-Time Control Protocol [RTP/RTCP] employ a 855 strategy similar to this to keep feedback traffic to 5 percent 856 or less than the overall session traffic. This technique was 857 originally utilized in IGMP. 859 Local Recovery - Some receivers may be designated as local 860 distribution points or "transcoders" that either re-send data 861 locally (possibly via unicast) when loss is reported or they 862 re-encode the data for lower bandwidth receivers before re- 863 sending. No standards exist for these strategies, although 864 "local recovery" is used by several reliable multicast 865 protocols. 867 Adaptive multicast application design for heterogeneous receivers is 868 still an active area of research. The fundamental requirements are 869 to maximize application usability, while accommodating network 870 conditions in a "network friendly" manner. In other words, 871 congestion detection and avoidance are (at least) as important in 872 protocol design as the user experience. The adaptive mechanisms 873 must also be stable, so they do not adapt too quickly--changing 874 encoding and rates based on too little information about what may be 875 a transient condition--to avoid oscillation. 877 This "feedback loop" service necessary for support of heterogeneous 878 receivers is not illustrated in the services summary in Figure 4, 879 although it could be added alongside "Reliable Transport" and the 880 others. This service could be implemented within an application or 881 accessed externally, as provided by the operating system or a third 882 party. See [HNRS] for a taxonomy of strategies for providing 883 feedback for multicast, with the ultimate goal of developing a 884 common multicast feedback protocol. 886 5.4 Reliable Data Delivery 888 Many of the multicast application examples in our list--like 889 audio/video distribution--have loss-tolerant data content. In other 890 words, the data content itself can remain useful even if some of it 891 is lost. For example, audio might have a short gap or lower 892 fidelity but will remain legible despite some data loss. 894 Other application examples--like caching and synchronized resources- 895 -require reliable data delivery. They deliver content that must be 896 complete, unchanged, in sequence, and without duplicates. The "Loss 897 Intolerant" column in Figure 7 shows a list of applications with 898 this requirement, while the others can tolerate varying levels of 899 data loss. The tolerance levels are typically determined by the 900 nature of the data and the encoding in use. 902 | 903 1toM | b a, d c, e 904 | 905 MtoM | f, j, k, l, m, n g, h, i 906 | 907 Mto1 | o, p, r, s, t q 908 | 909 +------------------------------------------------ 910 Loss Tolerant Loss Intolerant 912 Figure 7: Reliability Requirements of Application types 914 Some of the challenges involved with enabling reliable multicast 915 transport are the same as those of sending to heterogeneous 916 receivers, and some solutions are similar also. For example, many 917 reliable multicast transport protocols avoid the implosion problem 918 by using negative acknowledgements (NAKs) from receivers to indicate 919 what was lost. They also use "shared learning" whereby receivers 920 listen to others' NAKs and then listen for the resulting 921 retransmission of data, rather than requesting retransmission by 922 sending a NAK themselves. 924 Although reliable delivery cannot change the data sent--except, 925 perhaps, to use a loss-less data compression algorithm--they can use 926 other adaptive techniques like sending redundant data, or adjusting 927 the send rate. 929 Although many reliable multicast protocol implementations exist 930 [Obraczka], and a few are already available in commercial products, 931 none of them are standardized. Work is ongoing in the "Reliable 932 Multicast" research group of the Internet Research Task Force [IRTF] 933 to provide a better definition of the problem, the multicast 934 transport requirements, and protocol mechanisms. The IETF Relialbe 935 Multicast Transport (RMT) working group is focusing on designing 936 some working solutions in recognition of the urgent need for 937 scalable reliable multicast transport [RMT BLOCKS, RMT DESIGN]. 939 Scalability is the paramount concern, and it implies the general 940 need for "network friendly" protocols that detect and avoid 941 congestion as they provide reliable delivery. Other considerations 942 are protocol robustness, support for "late joins", group management 943 and security (which we discuss next). 945 The current consensus is that due to the wide variety of multicast 946 application requirements--some of which are at odds--no single 947 multicast transport will likely be appropriate for all applications. 948 As a result, most believe that we will eventually standardize a 949 number of reliable multicast protocols, rather than a single one. 951 5.5 Security 953 For any IP network application--unicast or multicast--security is 954 necessary because networks comprise users with different levels of 955 trust. 957 Network application security is challenging, even for unicast. And 958 as the need for security increases--gauged by the risks of being 959 without it--the challenges increase also. Security system 960 complexity and overhead is commensurate with the protection it 961 provides. "No one can guarantee 100% security. But we can work 962 toward 100% risk acceptance ...Strong cryptography can withstand 963 targeted attacks up to a point--the point at which it becomes easier 964 to get the information some other way ...A good design starts with a 965 threat model: what the system is designed to protect, from whom, and 966 for how long." [Schneier] 967 Multicast applications are no different than unicast applications 968 with respect to their need for security, and they require the same 969 basic security services: user authentication, data integrity, data 970 privacy and user privacy (anonymity). However, enabling security 971 for multicast applications is even more of a challenge than for 972 unicast. Having multiple receivers makes a difference, as does 973 their heterogeneity and the dynamic nature of multicast group 974 memberships. 976 Multicast security requirements can include any combination of the 977 following services: 979 Limiting Senders - Controlling who can send to group addresses 981 Limiting Receivers - Controlling who can receive 983 Limiting Access - Controlling who can "read" multicast content 984 either by encrypting content or limiting receivers (which isn't 985 possible yet) 987 Verifying Content - Ensuring that data originated from an 988 authenticated sender and was not altered en route 990 Protecting Receiver Privacy - Controlling whether sender(s) or 991 other receivers know receiver identity 993 Firewall Traversal - Proxying outgoing "join" requests through 994 firewalls, allowing incoming or outgoing traffic through, and 995 (possibly) authenticating receivers for filtering purposes and 996 security [Chouinard, Finlayson]. 998 This list is not comprehensive, but includes the most commonly 999 needed security services. Different multicast applications and 1000 different application contexts can have very different needs with 1001 respect to these services, and others. "Two main issues emerge, 1002 where the performance of current solutions leaves much to be 1003 desired" [Canetti]: 1005 Individual authentication - how is sender identity verified for 1006 each multicast datagram received? 1008 Membership revocation - how is further group access disabled for 1009 group members that leave the group (e.g. encryption keys in 1010 their possession disabled)? 1012 Performance is largely a factor when a user joins or leaves a group. 1013 For example, methods used to authenticate potential group members 1014 during joins or re-keying current members after a member leaves can 1015 involve significant processing and protocol overhead and result in 1016 significant delays that affect usability. 1018 Like reliable multicast, secure multicast is also still under 1019 investigation in the Internet Research Task Force [IRTF]. Protocol 1020 mechanisms for many of the most important of these services--such as 1021 limiting senders--have not yet been defined, let alone developed and 1022 deployed. 1024 As is true for reliable multicast, the current consensus is that no 1025 single security protocol will satisfy the wide diversity of 1026 sometimes-contradictory requirements among multicast applications. 1027 Hence, multicast security will also likely require a number of 1028 different protocols. 1030 5.6 Synchronized Play-Out 1032 This refers to having all receivers simultaneously play-out the 1033 multicast data they received. This may be necessary for fairness-- 1034 playing-out prices for auctions, or stock-prices--or to ensure 1035 synchronization with other receivers, such as when playing music. 1037 Here is an analogy to illustrate: Imagine a multi-speaker stereo 1038 system that is wired throughout a home (via analog). With the 1039 stereo playing on all speaker sets, you will hear continuous music 1040 as you walk from room-to-room. 1042 Now imagine a house full of multi-media and network enabled computer 1043 systems. Although they will all receive the same music datastream 1044 simultaneously via multicast, they will provide discontinuous music 1045 playback as you walk room-to-room. 1047 To provide synchronized playback that would enable continuous music 1048 from room-to-room would require three things: 1050 1) system clocks on all systems should be synchronized 1051 2) datastreams must be framed with timestamps 1052 3) the playback latency of the multimedia hardware 1054 The third of these is the most difficult to achieve at this time. 1055 Hardware and drivers don't provide any mechanism for retrieving this 1056 information, although different audio and video devices have a wide- 1057 range of performance. 1059 6. Service APIs 1061 In some cases, the protocol services mentioned in this document can 1062 be enabled transparently by passive configuration mechanisms and 1063 "middleware." For example, it is conceivable that a UDP 1064 implementation could implicitly enable a reliable multicast protocol 1065 without the explicit interaction of the application. 1067 Sometimes, however, applications need explicit access to these 1068 services for flexibility and control. For example, an adaptive 1069 application sending to a heterogeneous group of receivers using RTP 1070 may need to process RTCP reports from receivers in order to adapt 1071 accordingly (by throttling send rate or changing data encoders, for 1072 example) [RTP API]. Hence, there is often a need for service APIs 1073 that allow an application to qualify and initiate service requests, 1074 and receive event notifications. In Figure 4, the top edge of the 1075 box for each service effectively represents its API. 1077 Network APIs generally reflect the protocols they support. Their 1078 functionality and argument values are a (varying) subset of protocol 1079 message types, header fields and values. Although some protocol 1080 details and actions may not be exposed in APIs--since many protocol 1081 mechanics need not be exposed--others are crucial to efficient and 1082 flexible application operation. 1084 A more complete examination of the application services described in 1085 this document might also identify the protocol features that could 1086 be mapped to define a (generic) API definition for that service. 1087 APIs are often controversial, however. Not only are there many 1088 language differences, but it is also possible to create different 1089 APIs by exposing different levels of detail in trade-offs between 1090 flexibility and simplicity. 1092 7. Security Considerations 1094 See section 4.4 1096 8. Acknowledgements 1098 The author would like to acknowledge and thank the following 1099 individuals for their helpful feedback: Ran Canetti, Brian Haberman, 1100 Eric A. Hall, Kenneth C. Miller, and Dave Thaler. 1102 9. References 1104 [AnyCast] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting 1105 Service", RFC 1546, November 1993 1107 [Bradner] S. Bradner, "Internet Protocol Multicast Problem 1108 Statement", , 1109 September 1997, Work in Progress 1111 [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security 1112 issues", , April 1999, 1113 Work in Progress 1115 [Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to 1116 Facilitate Multicast Firewall Traversal", , November 1997, Work in 1118 Progress 1120 [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, 1121 M. Speer, R. Braden, B. Davie, "Integrated Services 1122 Operation over Diffserv Networks", , June 1999, Work in Progress 1125 [DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of 1126 Internet Protocol Suite for Distributed Simulation in the 1127 Large Multicast Environment", RFC 2502, February 1999 1129 [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech 1130 Earthlink Seminar Series, April 22, 1998 1132 [Finlayson] R. Finlayson, "IP Multicast and Firewalls", RFC 2588, 1133 May 1999 1135 [HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy 1136 of Feedback for Multicast", June 1999, Work in Progress 1138 [IGMPv2] B. Fenner, "Internet Group Management Protocol, Version 1139 2", RFC 2236, November 1997 1141 [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia 1142 Jukebox (IMJ): A New Paradigm for the On-Demand Delivery 1143 of Audio/Video", Proceedings of the Seventh International 1144 World Wide Web Conference, Brisbane, AUSTRALIA, April 1145 1998 1147 [IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and 1148 Procedures", RFC 2014, January 1996 1150 [Kermode] R. Kermode, "MADCAP Multicast Scope Nesting State 1151 Option", February 1999, , Work in Progress 1154 [LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of 1155 Communication Requirements, for Large-scale Multicast 1156 Applications," , 1157 May 1999, Work in Progress 1159 [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. 1160 Radoslavov, D. Thaler, "The Multicast Address-Set Claim 1161 (MASC) Protocol", , August 1162 1998, Work in Progress 1164 [Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise", 1165 (c) 1998 Prentice Hall, Upper Saddle River NJ 1166 ISBN 0-13-897687-2 1168 [Miller] C. K. Miller, "Multicast Networking and Applications", 1169 (c) 1999 Addison Wesley Longman, Reading MA 1170 ISBN 0-201-30979-3 1172 [MADCAP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address 1173 Dynamic Client Allocation Protocol (MADCAP)", 1174 , February 1999, 1175 Work in Progress 1177 [MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast- 1178 Friendly Internet Exchange (MIX)", , Dec 1998, Work in Progress 1181 [MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone 1182 Announcement Protocol (MZAP) ", , Feb 1999, Work in Progress 1185 [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and 1186 Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, 1187 January 1998 1189 [Rizzo] L. Rizzo, "Fast Group management in IGMP", Hipparc 98 1190 workshop, June 1998, UCL London 1191 http://www.iet.unipi.it/~luigi/hipparc98.ps.gz 1193 [RM] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF 1194 Criteria for Evaluating Reliable Multicast Transport and 1195 Application Protocols", RFC 2357, June 1998 1197 [RM BLOCKS] B. Whetten, L. Vicisano, R. Kermode, M. Handley, 1198 S. Floyd, "Reliable Multicast Transport Building Blocks 1199 for One-to-Many Bulk-Data Transfer", , June 1999, Work in Progress 1202 [RM DESIGN] M. Handley, B. Whetten, R. Kermode, S. Floyd, 1203 L. Vicisano, "The Reliable Multicast Design Space for 1204 Bulk Data Transfer", 1205 June 1999, Work in Progress 1207 [RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated 1208 Services", RFC 2210, September 1997 1210 [RTP API] J. Rosenberg, "Columbia RTP Library API Specification," 1211 (Note: Does not include RTCP processing), February 1997 1213 [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1214 "RTP: A Transport Protocol for Real-Time Applications", 1215 RFC 1889, January 1996 1217 [SAP] M. Handley, "SAP: Session Announcement Protocol", , November 1996, Work in Progress 1220 [SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol 1221 (SADP) ", , Jan 1999, Work 1222 in Progress 1224 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 1225 Protocol", RFC 2327, April 1998 1227 [Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks", 1228 December 1996, http://www.counterpane.com/whycrypto.html 1230 [SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 1231 Retransmit, and Fast Recovery Algorithms", RFC 2001, 1232 January 1997 1234 [SLP] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service 1235 Location Protocol", RFC 2165, June 1997 1237 10. Authors' Addresses 1239 Bob Quinn 1240 IP Multicast Initiative (IPMI) 1241 Stardust Forums, Inc. 1242 1901 S. Bascom Ave. #333 1243 Campbell, CA 95008 1245 +1 408 879 8080 1246 rcq@ipmulticast.com 1248 Kevin Almeroth 1249 Department of Computer Science 1250 Office: 2113, Engineering I 1251 University of California 1252 Santa Barbara, CA 93106-5110 1254 +1 805 893 2777 1255 almeroth@cs.ucsb.edu 1257 11. Full Copyright Statement 1259 Copyright (C) The Internet Society (1999). All Rights Reserved. 1261 This document and translations of it may be copied and furnished 1262 toothers, and derivative works that comment on or otherwise explain 1263 it orassist in its implmentation may be prepared, copied, published 1264 anddistributed, in whole or in part, without restriction of any 1265 kind,provided that the above copyright notice and this paragraph are 1266 includedon all such copies and derivative works. However, this 1267 document itselfmay not be modified in any way, such as by removing 1268 the copyright noticeor references to the Internet Society or other 1269 Internet organizations,except as needed for the purpose of 1270 developing Internet standards inwhich case the procedures for 1271 copyrights defined in the Internetlanguages other than English. 1273 The limited permissions granted above are perpetual and will not be 1274 revoked by the Internet Society or its successors or assigns. 1276 This document and the information contained herein is provided on an 1277 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1278 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1279 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1280 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1281 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."