summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3170.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3170.txt')
-rw-r--r--doc/rfc/rfc3170.txt1571
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc3170.txt b/doc/rfc/rfc3170.txt
new file mode 100644
index 0000000..dfdaf59
--- /dev/null
+++ b/doc/rfc/rfc3170.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group B. Quinn
+Request for Comments: 3170 Celox Networks
+Category: Informational K. Almeroth
+ UC-Santa Barbara
+ September 2001
+
+
+ IP Multicast Applications:
+ Challenges and Solutions
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document describes the challenges involved with designing and
+ implementing multicast applications. It is an introductory guide for
+ application developers that highlights the unique considerations of
+ multicast applications as compared to unicast applications.
+
+ To this end, the document presents a taxonomy of multicast
+ application I/O models and examples of the services they can support.
+ It then describes the service requirements of these multicast
+ applications, and the recent and ongoing efforts to build protocol
+ solutions to support these services.
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
+ 2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
+ 2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
+ 2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
+ 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
+ 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
+ 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
+ 3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
+ 4. Common Multicast Service Requirements . . . . . . . . . . . . .13
+ 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13
+
+
+
+Quinn, et al. Informational [Page 1]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
+ 5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
+ 5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
+ 5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
+ 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
+ 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
+ 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
+ 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
+ 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
+ 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
+ 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
+ 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .28
+
+1. Introduction
+
+ IP Multicast will play a prominent role on the Internet in the coming
+ years. It is a requirement, not an option, if the Internet is going
+ to scale. Multicast allows application developers to add more
+ functionality without significantly impacting the network.
+
+ Developing multicast-enabled applications is ostensibly simple.
+ Having datagram access allows any application to send to a multicast
+ address. A multicast application need only increase the Internet
+ Protocol (IP) time-to-live (TTL) value to more than 1 (the default
+ value) to allow outgoing datagrams to traverse routers. To receive a
+ multicast datagram, applications join the multicast group, which
+ transparently generates an [IGMPv2, IGMPv3] group membership report.
+
+ This apparent simplicity is deceptive, however. Enabling multicast
+ support in applications and protocols that can scale well on a
+ heterogeneous network is a significant challenge. Specifically,
+ sending constant bit rate datastreams, reliable data delivery,
+ security, and managing many-to-many communications all require
+ special consideration. Some solutions are available, but many of
+ these services are still active research areas.
+
+1.1 Motivation
+
+ The purpose of this document is to provide a framework for
+ understanding the challenges of designing and implementing multicast
+ applications. In order to use multicast communications correctly,
+ application developers must first understand the various I/O models
+ and the network services (in addition to basic multicast
+ communication) that are required. Secondly, application developers
+
+
+
+
+
+Quinn, et al. Informational [Page 2]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ need to be aware of efforts underway to provide these services. Such
+ efforts range in maturity from deployed commercial products to basic
+ research efforts to evaluate feasibility.
+
+ Multicast-based applications and services will play an important role
+ in the future of the Internet as continued multicast deployment
+ encourages their use and development. It is important that
+ developers be aware of the issues and solutions available--and
+ especially of their limitations--in order to avoid protocols that
+ negatively impact networks (thereby counter-acting the benefits of
+ multicast) or wasting their efforts "re-inventing the wheel".
+
+ The hope is that by raising developers' awareness, we can adjust
+ their expectations of finding solutions and lead them to successful,
+ scalable, and "network-friendly" development efforts.
+
+1.2 Focus and Scope
+
+ Our initial premise is that the multicast infrastructure is
+ transparent to applications, so it is not directly relevant to this
+ discussion. Our focus here is on multicast application protocol
+ services, so this document explicitly avoids any discussion of
+ multicast routing issues. We identify and describe the multicast-
+ specific issues involved with developing applications.
+
+ We assume the reader has a general understanding of the mechanics of
+ multicast, and in this respect we intend to compliment other
+ introductory documents [BeauW, Maufer, Miller]. Since this is an
+ introductory survey rather than a comprehensive examination, we refer
+ readers to other multicast application requirements descriptions [RM,
+ LSMA, Miller] for more detail.
+
+ In the remainder of this document we first define the term "IP
+ multicast enabled network", the multicast infrastructure and
+ essential multicast services. Next we describe the types of new
+ functionality that multicast applications can enable and their
+ requirements. We then examine the services that satisfy these
+ requirements, the challenges they present, and provide a brief survey
+ of the solutions available or under development. We wrap up with a
+ discussion of application programming interfaces (APIs) for multicast
+ services.
+
+2. IP Multicast Enabled Network
+
+ An "IP multicast-enabled network" provides end-to-end services in the
+ IP network infrastructure to allow any IP host to send datagrams to
+ an IP multicast address that any number of other IP hosts widely
+ dispersed can receive.
+
+
+
+Quinn, et al. Informational [Page 3]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ There are two kinds of multicast-enabled networks available. The
+ first is based on the original multicast service model as defined in
+ RFC 1112 [Deering]. In this model, a receiver simply joins the group
+ and does not need to know the identity of the source(s). This model
+ is known by a number of names including Internet Standard Multicast
+ (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc.
+ The second kind of multicast modifies the original service model such
+ that in addition to knowing the group address, a receiver must know
+ the set of relevant sources. This type of multicast is called Source
+ Specific Multicast (SSM) [SSM]. It becomes the application's
+ responsibility to know what kind of multicast capability the network
+ provides. Currently, the only way for an application to know the
+ type of multicast is based on the group address. If the group is in
+ the 232/8 range, the application should assume SSM is the service
+ model. Otherwise, the application should assume source-generic
+ multicast is the service model.
+
+ At the time of this writing, end-to-end "global" multicast service is
+ not yet available, but the size of the "multicast-enabled" Internet
+ is growing. Recent development and deployment of interdomain
+ multicast routing protocols and multicast-friendly Internet exchanges
+ have enabled peering between major ISPs. This, along with the
+ increasing availability of compelling content, is spurring deployment
+ and availability of the IP Multicast Enabled Network.
+
+ In the remainder of this document we assume that the multicast-
+ enabled network is already ubiquitous. Since such a large and
+ growing portion of the global Internet is IP multicast-enabled now,
+ and many enterprise networks (intranets) are also, this perspective
+ is relevant today.
+
+2.1 Essential Protocol Components
+
+ An IP multicast enabled network requires two essential protocol
+ components:
+
+ 1) An IP host-based protocol to allow a receiver application to
+ notify a local router(s) that it has joined the group, and
+ initiate the data flow from all sender(s) within the scope
+
+ 2) An IP router-based protocol to allow any routers with multicast
+ group members (receivers) on their local networks to communicate
+ with other routers to ensure that all datagrams sent to the
+ group address are forwarded to all receivers within the intended
+ scope
+
+
+
+
+
+
+Quinn, et al. Informational [Page 4]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ Ideally, these protocol components are transparent to multicast
+ applications. However, there are two aspects of their functionality
+ requirements that are worth mentioning specifically, since they
+ affect application performance and design. These are the multicast
+ application requirements for:
+
+ - Expedient Joins and Leaves
+ - Sends without a Join
+
+2.1.1 Expedient Joins and Leaves
+
+ Some applications require expedient group joins and leaves, as their
+ usability or functionality are sensitive to the latency involved with
+ joining and leaving a group.
+
+ Join Latency: The time it takes for data to begin flowing after an
+ application issues a command to join a multicast group
+
+ Leave Latency: The time it takes for data to stop flowing after an
+ application issues a command to leave a multicast group
+ [IGMPv2,IGMPv3]
+
+ For example, using distributed a/v as a multicast-based "television"
+ must allow users to "channel surf"--changing channels frequently.
+ Each channel change generates a group leave and group join, so delays
+ in either will affect usability. In a sense, this is more of a user
+ requirement than an application requirement.
+
+ The functionality of distributed interactive simulations [DIS] is
+ often sensitive to join/leave latency. This is particularly true
+ when trying to exchange information to represent fast moving objects
+ that quickly enter and exit the scope of a simulated environment
+ (e.g., low-flying, fast-moving aircraft). If the join latency is too
+ long, the information provided may be old by the time it is received.
+
+ A fast leave phase is highly desirable both for effective congestion
+ control mechanisms, to stop undesirable flows quickly, and for the
+ network in general, to better filter unwanted traffic [Rizzo].
+ Applications cannot affect control over either join or leave latency,
+ but are dependent on the multicast infrastructure to enable expedient
+ operations. This is a basic multicast service requirement.
+
+2.1.2 Sends without a Join
+
+ Applications that send to a multicast address should be able to start
+ sending immediately, without having to join the destination group
+ first. This is important for embedded devices and bursty-source
+ applications with low-delay delivery requirements.
+
+
+
+Quinn, et al. Informational [Page 5]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ The current IGMP-based multicast host model and all current
+ implementations allow senders to send to a group without joining it
+ as a standard feature.
+
+3. IP Multicast Application Taxonomy
+
+ With an IP multicast-enabled network available, some unique and
+ powerful applications and application services are possible.
+ "Multicast enables coordination - it is well suited to loosely
+ coupled distributed systems (of people, servers, databases,
+ processes, devices...)" [Estrin].
+
+ A "multicast application" is simply defined as any application that
+ sends to and/or receives from an IP multicast address. These may or
+ may not also reference IP unicast addresses, as we describe later.
+
+ What differentiates IP multicast applications from one-to-one unicast
+ applications are the other sender and receiver relationships
+ multicast enables. There are three general categories of multicast
+ applications:
+
+ One-to-Many (1toM): A single host sending to two or more (n)
+ receivers
+
+ Many-to-Many (MtoM): Any number of hosts sending to the same
+ multicast group address, as well as receiving from it
+
+ Many-to-One (Mto1): Any number of receivers sending data back to a
+ (source) sender via unicast or multicast
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 6]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ +-----------------------------------+
+ | Host 2->n ("many") |
+ +-------------+---------------------+
+ | One-Way | Two-Way |
+ +-------------+---------------------|
+ | A B | C D E |
+ +-----------+-------------+---------------------+
+ | I/O | | S(m)/ S(u)/ S(m)/|
+ | Operations| S(m) R(m) | R(m) R(m) R(u) |
+ +-------+---+-----------+-------------+---------------------|
+ | | 1 | S(m) | 1toM | MtoM |
+ | Host | 2 | R(m) | Mto1 | MtoM |
+ | +---+-----------+-------------+ |
+ | 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM |
+ | | 4 | S(m)/R(u) | Mto1 |
+ |("one")| 5 | S(u)/R(m) | Mto1 |
+ +-------+---+-----------+-----------------------------------+
+
+ Legend: S: "Send" (u): "unicast"
+ ------ R: "Receive" (m): "multicast"
+
+ Table 1: Application types characterized by I/O relationships
+ and destination address types (multicast or unicast)
+
+ Table 1 defines these application types in terms of the I/O
+ relationships they represent. These categories are defined in terms
+ of the combination of communication mechanisms they use. At the IP
+ level, all multicast I/O is only 1toM or MtoM and unicast is always
+ one-to-one (1to1). The Mto1 category, for example, refers to several
+ possible combinations of IP-level relationships, including unicast.
+ We created the Mto1 category to help differentiate between the many
+ applications and services that use multicast.
+
+ 1toM: MtoM: Mto1:
+ R1 S1/R1 S1
+ / / | \ \
+ S-R2 S2/R2-+-S3/R3 S2-R
+ \... \ | / .../
+ Rn Sn/Rn Sn
+
+ Legend: S: "Sender"
+ ------ R: "Receiver"
+
+ Figure 1: Generalization of the three application categories
+
+ Figure 1 illustrates the general model for each of the three
+ multicast application categories. Again it is worth emphasizing that
+ Mto1 is an artificial category defined by the application-level
+
+
+
+Quinn, et al. Informational [Page 7]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ relationship between sender(s) and receiver. At the IP-level,
+ multicast does not provide an Mto1 I/O mechanism, since it does not
+ allow senders to limit receivers, nor even know who they are.
+ Receiver information and limitations are enabled at the application
+ level, as required by the multicast application.
+
+ We describe each of these general application types in more detail
+ and provide application examples of each in the sub-sections below.
+ The list of examples is not comprehensive, but attempts to define the
+ prominent multicast application and service types in each of the
+ three general categories. We reference the items in these lists in
+ the remainder of this document as we describe their specific service
+ requirements, define the challenges they present, and reference
+ solutions available or under development.
+
+3.1 One-to-Many Applications
+
+ One-to-Many (1toM) applications have a single sender, and multiple
+ simultaneous receivers. Entry B1 in Table 1 represents the classic
+ 1toM relationship. Entry B3 differs only slightly, as the sender
+ also acts as receiver (i.e., it has loopback enabled).
+
+ When people think of multicast, they most often think of broadcast-
+ based multimedia applications: television (video) and radio (audio).
+ This is a reasonable analogy and indeed these are significant
+ multicast applications, but these are far from the extent of
+ applications that multicast can enable. Audio/Video distribution
+ represents a fraction of the multicast application possibilities, and
+ most do not have analogs in today's consumer broadcast industry.
+
+ a) Scheduled audio/video (a/v) distribution: Lectures,
+ presentations, meetings, or any other type of scheduled event
+ whose multimedia coverage could benefit an audience (i.e.
+ television and radio "broadcasts"). One or more constant-bit-
+ rate (CBR) datastreams and relatively high-bandwidth demands
+ characterize these applications. When more than one datastream
+ is present--as with an audio/video combination--the two are
+ synchronized and one typically has a higher priority than the
+ other(s). For example, in an a/v combination it is more
+ important to ensure an intelligible audio stream, than perfect
+ video.
+
+ b) Push media: News headlines, weather updates, sports scores, or
+ other types of non-essential dynamic information. "Drip-feed",
+ relatively low-bandwidth data characterize these applications.
+
+
+
+
+
+
+Quinn, et al. Informational [Page 8]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ c) File Distribution and Caching: Web site content, executable
+ binaries, and other file-based updates sent to distributed
+ end-user or replication/caching sites
+
+ d) Announcements: Network time, multicast session schedules,
+ random numbers, keys, configuration updates, (scoped) network
+ locality beacons, or other types of information that are
+ commonly useful. Their bandwidth demands can vary, but
+ generally they are very low bandwidth.
+
+ e) Monitoring: Stock prices, Sensor equipment (seismic activity,
+ telemetry, meteorological or oceanic readings), security
+ systems, manufacturing or other types of real-time information.
+ Bandwidth demands vary with sample frequency and resolution,
+ and may be either constant-bit-rate or bursty (if event-
+ driven).
+
+3.2 Many-to-Many Applications
+
+ In many-to-Many (MtoM) applications two or more of the receivers also
+ act as senders. In other words, MtoM applications are characterized
+ by two-way multicast communications.
+
+ The many-to-many capabilities of IP multicast enable the most unique
+ and powerful applications. Each host running an MtoM application may
+ receive data from multiple senders while it also sends data to all of
+ them. As a result, many-to-many applications often present complex
+ coordination and management challenges.
+
+ f) Multimedia Conferencing: Audio/Video and whiteboard comprise
+ the classic conference application. Having multiple
+ datastreams with different priorities characterizes this type
+ of application. Co-ordination issues--such as determining who
+ gets to talk when--complicate their development and usability.
+ There are common heuristics and "rules of play", but no
+ standards exist for managing conference group dynamics.
+
+ g) Synchronized Resources: Shared distributed databases of any
+ type (schedules, directories, as well as traditional
+ Information System databases).
+
+ h) Concurrent Processing: Distributed parallel processing.
+
+ i) Collaboration: Shared document editing.
+
+ j) Distance Learning: This is a one-to-many a/v distribution
+ application with "upstream" capability that allows receivers to
+ question the speaker(s).
+
+
+
+Quinn, et al. Informational [Page 9]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ k) Chat Groups: These are like text-based conferences, but may
+ also provide simulated representations ("avatars") for each
+ "speaker" in simulated environments.
+
+ l) Distributed Interactive Simulations [DIS]: Each object in a
+ simulation multicasts descriptive information (e.g., telemetry)
+ so all other objects can render the object, and interact as
+ necessary. The bandwidth demands for these can be tremendous,
+ as the number of objects and the resolution of descriptive
+ information increases.
+
+ m) Multi-player Games: Many multi-player games are simply
+ distributed interactive simulations, and may include chat group
+ capabilities. Bandwidth usage can vary widely, although
+ today's first-generation multi-player games attempt to minimize
+ bandwidth usage to increase the target audience (many of whom
+ still use dial-up modems).
+
+ n) Jam Sessions: Shared encoded audio (e.g., music). The
+ bandwidth demands vary based on the encoding technique, sample
+ rate, sample resolution, number of channels, etc.
+
+3.3 Many-to-One Applications
+
+ Unlike the one-to-many and many-to-many application categories, the
+ many-to-one (Mto1) category does not represent a communications
+ mechanism at the IP layer. Mto1 applications have multiple senders
+ and one (or a few) receiver(s), as defined by the application layer.
+ Table 1 shows that Mto1 applications can be one-way or use a two-way
+ request/response type protocol, where either senders or receiver(s)
+ may generate the request. Figure 2 characterizes the I/O
+ relationship possibilities in Mto1 applications:
+
+ Mto1 applications have many scaling issues. Too many simultaneous
+ senders can potentially overwhelm receiver(s), a condition
+ characterized as an "implosion problem". Another considerable
+ scaling problem is the large amount of state in the network that
+ having many multicast senders generates. This is largely transparent
+ to applications and the effect may be diminished in the future with
+ the use of bi-directional trees in multicast routing protocols, but
+ nonetheless it should be considered by application designers.
+
+
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 10]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ 1) S1 2) S1 3) S1 4) S1
+ \ \ \ \
+ S2-R S2-R S2-R S2-R
+ .../ .../ .../ .../
+ Sn Sn Sn Sn
+
+ Data(m) Request(m) Request(m) Request(u)
+ ------> ----------> <---------- ---------->
+ Response(u) Response(u) Response(m)
+ <----------- -----------> <----------
+
+ Figure 2: Characterization of Mto1 I/O possibilities
+
+ No standards yet exist for alternate and equivalent Mto1 application
+ designs, but there are a number of possibilities to consider [HNRS].
+ Since the main advantage of using multicast in a Mto1 application is
+ that senders need not know the receiver(s) unicast address(es), one
+ alternative is for each receiver to advertise its unicast address via
+ multicast. However, since this strategy still leaves the potential
+ for implosion on each receiver, additional strategies may be needed
+ to distribute the load. For example, it may be possible to increase
+ the number of receivers (in a "flat" receiver topology) or establish
+ localized receivers (in a "hierarchical" topology) as used in "local
+ recovery" (section 5.3). Such methods have coordination issues, and
+ since standard solutions have not yet been identified, Mto1
+ application developers should consider their alternatives carefully.
+
+ o) Resource Discovery: Service Location, for example, leverages IP
+ Multicast to enable something like a "host anycasting service"
+ capability [AnyCast]: A multicast receiver to send a query to a
+ group address, to elicit responses from the closest host so
+ they can satisfy the request. The responses might also contain
+ information that allows the receiver to determine the most
+ appropriate (e.g., closest) service provider to use.
+
+ In Table 1, this application is entry D4. It is also
+ illustrated in Figure 2 by possibility number 3.
+ Alternately, the response could be to a multicast rather
+ than unicast address, although technically that would make
+ it an MtoM application type (this is how the Service
+ Location Protocol [SLP] operates, when a user agent attempts
+ to locate a directory agent).
+
+ p) Data Collection: This is the converse of a one-to-many
+ "monitoring" application described earlier. In this case there
+ may be any number of distributed "sensors" that send data to a
+ data collection host. The sensors might send updates in
+ response to a request from the data collector, or send
+
+
+
+Quinn, et al. Informational [Page 11]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ continuously at regular intervals, or send spontaneously when a
+ pre-defined event occurs. Bandwidth demands can vary based on
+ sample frequency and resolution.
+
+ This is illustrated in Table 1 by entries A1 and A3, the only
+ difference being that A3 has a loopback interface. In Figure
+ 2, this is possibility number 1. Since the number of receivers
+ can easily be more than one, this is really an MtoM
+ application.
+
+ q) Auctions: The "auctioneer" starts the bidding by describing
+ whatever it is for sale (product or service or whatever), and
+ receivers send their bids privately or publicly (i.e., to a
+ unicast or multicast address).
+
+ This is possibility number 2 in Figure 2, and D5 in Table 1.
+ The response could be sent to a multicast address, although
+ technically that would make it an MtoM application.
+
+ r) Polling: The "pollster" sends out a question, and the "pollees"
+ respond with answers. This is possibility number 2 in Figure
+ 2, and could also be characterized as an MtoM application if
+ the response is to a multicast address.
+
+ s) Jukebox: Allows near-on-demand a/v playback. Receivers use an
+ "out-of-band" protocol mechanism (via web, email, unicast or
+ multicast requests, etc.) to send their playback request into a
+ scheduling queue [IMJ].
+
+ This is characterized by possibility number 4 in Figure 2, and
+ entry D4 in Table 1. The initial unicast request is the only
+ difference between this type of application and a typical 1toM.
+ If that initial request were sent to a multicast address, this
+ would effectively be an MtoM application.
+
+ t) Accounting: This is basically data collection but is worth
+ separating since it is such an important application. In some
+ multicast applications it is imperative to know information
+ about each receiver, possibly in real-time. But such
+ information can be overwhelming [MRM]. Current mechanisms,
+ like RTCP (which is actually MtoM since it is multicast but
+ could be made Mto1), use scaling techniques but trade-off
+ information granularity. As a group grows the total amount of
+ feedback is constant but each receiver sends less.
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 12]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+4. Common Multicast Service Requirements
+
+ Some multicast application service requirements are common to unicast
+ network applications as well. We characterize two of them here--
+ bandwidth and delay requirements.
+
+4.1 Bandwidth Requirements
+
+ Figure 3 shows multicast applications approximate bandwidth
+ requirements.
+
+ Unicast and multicast applications both need to design applications
+ to adapt to the variability of network conditions. But as we
+ describe in section 5.3, it is the need to accommodate multiple
+ heterogeneous multicast receivers--with their diversity of bandwidth
+ capacity and delivery delays--that presents the unique challenge for
+ multicast applications to satisfy these requirements.
+
+ |
+ 1toM | b, d c, e a
+ |
+ MtoM | k g, i f, h, j, l, m, n
+ |
+ Mto1 | o, q, r p, t s
+ |
+ +-----------------------------------------------
+ Low Bandwidth High Bandwidth
+
+ Figure 3: Bandwidth Requirements of applications
+
+4.2 Delay Requirements
+
+ Aside from those with time-sensitive data (e.g., stock prices, and
+ real-time monitoring information), most one-to-many applications have
+ a high tolerance for delay and delay variance (jitter). Constant
+ bit-rate (CBR) data--such as streaming media (audio/video)--are
+ sensitive to jitter, but applications commonly counteract the effects
+ by buffering data and delaying playback.
+
+ Most many-to-one and many-to-many multicast applications are
+ intolerant of delays because they are bidirectional, interactive and
+ request/response dependent. As a result, delays should be minimized,
+ since they can adversely affect the application's usability.
+
+ This need to minimize delays is most evident in (two-way) conference
+ applications, where users cannot converse effectively if the audio or
+ video is delayed more than 500 milliseconds. For this and other
+
+
+
+
+Quinn, et al. Informational [Page 13]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ examples see Figure 4, which plots multicast applications on a
+ (coarse) scale of sensitivity to delivery delays.
+
+ |
+ 1toM | b, c a, d e
+ |
+ MtoM | g, i, j, k f, h, l, m, n
+ |
+ Mto1 | r o, p, s, t q
+ |
+ +-----------------------------------------------
+ Delay Tolerant Delay Intolerant
+
+ Figure 4: Delay tolerance of application types
+
+ For delay-intolerant multicast (or unicast) applications, quality of
+ service (QoS) is the only option. IP networks currently provide only
+ "best effort" delivery, so data are subject to variable router
+ queuing delays and loss due to network congestion (router queue
+ overflows). IP QoS standards do exist now [RSVP] and efforts to
+ enable end-to-end QoS support in the Internet are underway [E2EQOS].
+
+ However, QoS support is an IP network infrastructure consideration.
+ Although there are multicast-specific challenges for implementing QoS
+ in the network for multicast flows, they are beyond the control of
+ applications, so further discussion of the QoS protocols and services
+ is beyond the scope of this document.
+
+5. Unique Multicast Service Requirements
+
+ The three application categories described earlier are very general
+ in nature. Within each category and even among each of the
+ application types, specific application instances have a variety of
+ application requirements. One-to-many application types are
+ relatively simple to develop, but as we pointed out there are
+ challenges involved with developing many-to-one and many-to-many
+ applications. Some of these have requirements bandwidth and delay
+ requirements, similar to unicast applications.
+
+ Multicast applications can be further differentiated from unicast
+ applications and from each other by the services they require. In
+ this section we provide a survey of the various services that have
+ unique requirements for multicast applications.
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 14]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ +--------------------------------------------------------------+
+ | Multicast Application |
+ +--------------------------------------+ +-------------------+
+ +-------------------------------------+| |+--------++--------+
+ | Multicast Security || || || |
+ +----------------------+ +----------+| || System || |
+ +----------++---------+| |+---------+| || Time || Codecs |
+ | Reliable || Address || || Session || || || |
+ | Delivery || Mgt || || Mgt || || || |
+ +----------++---------++---++---------++---++--------++--------+
+ +----------------------------------------++--------------------+
+ | Basic IP Multicast Service || IP Unicast |
+ | (e.g., UDP and IGMPv2/v3) || Service |
+ +----------------------------------------++--------------------+
+
+ Figure 5: Multicast service requirements summary
+
+ Here's the list of multicast application service requirements:
+
+ Address Management - Selection and coordinated of address
+ allocation. The need is to provide assurances against "address
+ collision" and to provide address ownership.
+
+ Session Management - Perform application-layer services on top of
+ multicast transport. These services depend heavily on the
+ application but include functions like session advertisement,
+ billing, group member monitoring, key distribution, etc.
+
+ Heterogeneous Receiver Support - Sending to receivers with a wide
+ variety of bandwidth capacities, latency characteristics, and
+ network congestion requires feedback to monitor receiver
+ performance.
+
+ Reliable Data Delivery - Ensuring that all data sent is received
+ by all receivers.
+
+ Security - Ensuring content privacy among dynamic multicast group
+ memberships, and limiting senders.
+
+ Synchronized Play-Out - Allow multiple receivers to "replay" data
+ received in synchronized fashion.
+
+ In the remainder of this section, we describe each of these
+ application services in more detail, the challenges they present, and
+ the status of standardized solutions.
+
+
+
+
+
+
+Quinn, et al. Informational [Page 15]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+5.1 Address Management
+
+ One of the first questions facing a multicast application developer
+ is what multicast address to use. Multicast addresses are not
+ assigned to individual hosts, assignments can change dynamically, and
+ addresses sometimes have semantics of their own (e.g., Admin
+ Scoping). Multicast applications require an address management
+ service that provides address allocation or assignment queries.
+ There are a number of ways for applications to learn about multicast
+ addresses:
+
+ Hard-Coded: Software configuration, encoded in a binary
+ executable, or burned into ROM in embedded devices. These
+ applications typically reference IANA statically allocated
+ multicast addresses (including relative addresses).
+
+ Advertised: Session announcements (as described in the next
+ section), or via another "out-of-band" query or discovery protocol
+ mechanism.
+
+ Algorithmically Derived: Using a programmatic algorithm to
+ allocate a statistically random (unused) address.
+
+ |
+ 1toM | c, e a, b d
+ |
+ MtoM | f, j, k, n g, h, i, l, m
+ |
+ Mto1 | r o, p, s q, t
+ |
+ +-----------------------------------------------
+ Hard-Coded Advertised Algorithmic
+
+ Figure 6: Multicast address usage for application types
+
+ In almost all cases, application designers should assume that
+ multicast addresses are to be dynamic. Very little of the multicast
+ address space is available for static assignment by IANA [MADDR].
+ Also, given the host-specific addressing available with SSM,
+ Internet-wide, static address assignment is expected to be very rare.
+
+5.2 Session Management
+
+ Session management is one of the most misunderstood services with
+ respect to multicast. Most application developers assume that
+ multicast will provide services like security, encryption,
+ reliability, session advertisement, monitoring, billing, etc. In
+ fact, multicast is simply a transport mechanism that provides end-
+
+
+
+Quinn, et al. Informational [Page 16]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ to-end delivery. All of the other services are application-layer
+ services that must be provided by each particular application.
+ Furthermore, in most cases there are not defined standards for how
+ these functions should be provided. The particular functions are
+ dependent on the particular needs of the application, and no single
+ method (or standard) can be made to be sufficient for all cases.
+
+ While there are no generic solutions which provide all session
+ management functions, there are some protocols and common techniques
+ that provide support for some of the functions. Techniques for
+ congestion control and heterogeneous receiver support are discussed
+ in Section 5.3. Protocols for reliability are discussed in Section
+ 5.4. Security considerations are discussed in Section 5.5.
+
+ With respect to session advertisement, there are a number of
+ mechanisms for advertising sessions. One commonly used technique is
+ to advertise sessions via the WWW. Users can join a group by
+ clicking on URLs, and then having a response returned to the user
+ that includes the group address and maybe information about group
+ source(s). Another mechanism is the session description protocol
+ [SDP]. It provides a format for representing information about
+ sessions, but it does not provide the transport for dissemination of
+ these session descriptions, nor does it provide address allocation
+ and management. SDP only provides the syntax for describing session
+ attributes.
+
+ SDP session descriptions may be conveyed publicly or privately by
+ means of any number of transports including web (HTTP) and MIME
+ encoded email. The session announcement protocol [SAP] is the de
+ facto standard transport and many multicast-enabled applications
+ currently use it. SAP limits distribution via multicast scoping, but
+ the current protocol definition has scaling issues that need to be
+ addressed. Specifically, the initialization latency for a session
+ directory can be quite long, and it increases in proportion to the
+ number of session announcements. This is to an extent a multicast
+ infrastructure issue, however, as this level of protocol detail
+ should be transparent to applications.
+
+ The session management service needs to:
+
+ - Advertise scheduled sessions
+ - Provide a query mechanism for retrieving
+ information about session schedules
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 17]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+5.3 Heterogeneous Receiver Support
+
+ The Internet is a network of networks. IP's strength is its ability
+ to enable seamless interoperability between hosts on disparate
+ network media, the heterogeneous network.
+
+ When two hosts communicate via unicast--one-to-one--across an IP
+ network, it is relatively easy for senders to adapt to varying
+ network conditions. The Transmission Control Protocol (TCP) provides
+ reliable data transport, and is the model of "network friendly"
+ adaptability.
+
+ TCP receivers send acknowledgements back to the sender for data
+ delivered. A TCP sender detects data loss from the data sent that is
+ not acknowledged. When it detects data loss, TCP infers that there
+ is network congestion or a low-bandwidth link, and adapts by
+ throttling down its send rate [SlowStart].
+
+ User Datagram Protocol (UDP) does not enable a receiver feedback loop
+ the way TCP does, since UDP does not provide reliable data delivery
+ service. As a result, it also does not have a loss detection and
+ adaptive congestion control mechanism as TCP does. However, it is
+ possible for a unicast UDP application to enable similar adaptive
+ algorithms to achieve the same result, or even improve on it.
+
+ A unicast UDP application that uses a feedback mechanism to detect
+ data loss and adapt the send rate, can do so better than TCP. TCP
+ automatically reduces the "congestion window" when data loss is
+ detected, although the updated send rate may be slower than a CBR
+ audio/video stream requires. When a UDP application detects loss, it
+ can adapt the data itself to accommodate the lower send rate. For
+ example, a UDP application can:
+
+ - Reduce the data resolution (e.g., send lower fidelity
+ audio/video by reducing sample frequency or frame rate) to
+ reduce data rate.
+
+ - Modify the data encoding to add redundant data (e.g., forward
+ error correction) offset in time to avoid fate sharing. This
+ could also be "layered", so a percentage of data loss will
+ simply reduce fidelity rather than corrupt the data.
+
+ - Reduce the send rate of one datastream in order to favor another
+ of higher priority (e.g., sacrifice video in order to ensure
+ audio delivery).
+
+
+
+
+
+
+Quinn, et al. Informational [Page 18]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ - Send data at a lower rate (i.e., with a different encoding) on a
+ separate multicast address and/or port number for high-loss
+ receivers.
+
+ However, with multicast applications--one-to-many or many-to-many--
+ which have multiple receivers, the feedback loop design needs
+ modification. If all receivers return data loss reports
+ simultaneously, the sender is easily overwhelmed in the storm of
+ replies. This is known as the "implosion problem".
+
+ Another problem is that heterogeneous receiver capabilities can vary
+ widely due to the wide range of (static) network media bandwidth
+ capabilities and dynamically due to transient traffic conditions. If
+ a sender adapts its send rate and data resolution based on the loss
+ rate of its worst receiver(s), then it can only service the lowest
+ common denominator. Hence, a single "crying baby" can spoil it for
+ all other receivers.
+
+ Strategies exist for dealing with these heterogeneous receiver
+ problems. Here are two examples:
+
+ Shared Learning - When loss is detected (i.e., a sequenced packet
+ isn't received), a receiver starts a random timer. If it
+ receives a data loss report sent by another receiver as it waits
+ for the timer to expire, it stops the timer and does not send a
+ report. Otherwise, it sends a report when the timer expires.
+ The Real-Time Protocol and its feedback-loop counterpart Real-
+ Time Control Protocol [RTP/RTCP] employ a strategy similar to
+ this to keep feedback traffic to 5 percent or less than the
+ overall session traffic. This technique was originally utilized
+ in IGMP.
+
+ Local Recovery - Some receivers may be designated as local
+ distribution points or "transcoders" that either re-send data
+ locally (possibly via unicast) when loss is reported or they re-
+ encode the data for lower bandwidth receivers before re-sending.
+ No standards exist for these strategies, although "local
+ recovery" is used by several reliable multicast protocols.
+
+ Adaptive multicast application design for heterogeneous receivers is
+ still an active area of research. The fundamental requirements are
+ to maximize application usability, while accommodating network
+ conditions in a "network friendly" manner. In other words,
+ congestion detection and avoidance are (at least) as important in
+ protocol design as the user experience. The adaptive mechanisms must
+ also be stable, so they do not adapt too quickly--changing encoding
+ and rates based on too little information about what may be a
+ transient condition--to avoid oscillation.
+
+
+
+Quinn, et al. Informational [Page 19]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ This "feedback loop" service necessary for support of heterogeneous
+ receivers is not illustrated in the services summary in Figure 4,
+ although it could be added alongside "Reliable Transport" and the
+ others. This service could be implemented within an application or
+ accessed externally, as provided by the operating system or a third
+ party. See [HNRS] for a taxonomy of strategies for providing
+ feedback for multicast, with the ultimate goal of developing a common
+ multicast feedback protocol.
+
+5.4 Reliable Data Delivery
+
+ Many of the multicast application examples in our list--like
+ audio/video distribution--have loss-tolerant data content. In other
+ words, the data content itself can remain useful even if some of it
+ is lost. For example, audio might have a short gap or lower fidelity
+ but will remain intelligible despite some data loss.
+
+ Other application examples--like caching and synchronized resources-
+ -require reliable data delivery. They deliver content that must be
+ complete, unchanged, in sequence, and without duplicates. The "Loss
+ Intolerant" column in Figure 7 shows a list of applications with this
+ requirement, while the others can tolerate varying levels of data
+ loss. The tolerance levels are typically determined by the nature of
+ the data and the encoding in use.
+
+ |
+ 1toM | b a, d c, e
+ |
+ MtoM | f, j, k, l, m, n g, h, i
+ |
+ Mto1 | o, p, r, s, t q
+ |
+ +------------------------------------------------
+ Loss Tolerant Loss Intolerant
+
+ Figure 7: Reliability Requirements of Application types
+
+ Some of the challenges involved with enabling reliable multicast
+ transport are the same as those of sending to heterogeneous
+ receivers, and some solutions are similar also. For example, many
+ reliable multicast transport protocols avoid the implosion problem by
+ using negative acknowledgements (NAKs) from receivers to indicate
+ what was lost. They also use "shared learning" whereby receivers
+ listen to others' NAKs and then listen for the resulting
+ retransmission of data, rather than requesting retransmission by
+ sending a NAK themselves.
+
+
+
+
+
+Quinn, et al. Informational [Page 20]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ Although reliable delivery cannot change the data sent--except,
+ perhaps, to use a loss-less data compression algorithm--they can use
+ other adaptive techniques like sending redundant data, or adjusting
+ the send rate.
+
+ Although many reliable multicast protocol implementations exist
+ [Obraczka], and a few are already available in commercial products,
+ none of them are standardized. Work is ongoing in the "Reliable
+ Multicast" research group of the Internet Research Task Force [IRTF]
+ to provide a better definition of the problem, the multicast
+ transport requirements, and protocol mechanisms.
+
+ Scalability is the paramount concern, and it implies the general need
+ for "network friendly" protocols that detect and avoid congestion as
+ they provide reliable delivery. Other considerations are protocol
+ robustness, support for "late joins", group management and security
+ (which we discuss next).
+
+ The current consensus is that due to the wide variety of multicast
+ application requirements--some of which are at odds--no single
+ multicast transport will likely be appropriate for all applications.
+ As a result, most believe that we will eventually standardize a
+ number of reliable multicast protocols, rather than a single one
+ [BULK, RMT].
+
+5.5 Security
+
+ For any IP network application--unicast or multicast--security is
+ necessary because networks comprise users with different levels of
+ trust.
+
+ Network application security is challenging, even for unicast. And
+ as the need for security increases--gauged by the risks of being
+ without it--the challenges increase also. Security system complexity
+ and overhead is commensurate with the protection it provides. "No
+ one can guarantee 100% security. But we can work toward 100% risk
+ acceptance...Strong cryptography can withstand targeted attacks up to
+ a point--the point at which it becomes easier to get the information
+ some other way...A good design starts with a threat model: what the
+ system is designed to protect, from whom, and for how long."
+ [Schneier]
+
+ Multicast applications are no different than unicast applications
+ with respect to their need for security, and they require the same
+ basic security services: user authentication, data integrity, data
+ privacy and user privacy (anonymity). However, enabling security for
+
+
+
+
+
+Quinn, et al. Informational [Page 21]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ multicast applications is even more of a challenge than for unicast.
+ Having multiple receivers makes a difference, as does their
+ heterogeneity and the dynamic nature of multicast group memberships.
+
+ Multicast security requirements can include any combination of the
+ following services:
+
+ Limiting Senders - Controlling who can send to group addresses
+
+ Limiting Receivers - Controlling who can receive
+
+ Limiting Access - Controlling who can "read" multicast content
+ either by encrypting content or limiting receivers (which isn't
+ possible yet)
+
+ Verifying Content - Ensuring that data originated from an
+ authenticated sender and was not altered en route
+
+ Protecting Receiver Privacy - Controlling whether sender(s) or
+ other receivers know receiver identity
+
+ Firewall Traversal - Proxying outgoing "join" requests through
+ firewalls, allowing incoming or outgoing traffic through, and
+ (possibly) authenticating receivers for filtering purposes and
+ security [Finlayson].
+
+ This list is not comprehensive, but includes the most commonly needed
+ security services. Different multicast applications and different
+ application contexts can have very different needs with respect to
+ these services, and others. Two main issues emerge, where the
+ performance of current solutions leaves much to be desired [MSec].
+
+ Individual authentication - how is sender identity verified for
+ each multicast datagram received?
+
+ Membership revocation - how is further group access disabled for
+ group members that leave the group (e.g., encryption keys in their
+ possession disabled)?
+
+ Performance is largely a factor when a user joins or leaves a group.
+ For example, methods used to authenticate potential group members
+ during joins or re-keying current members after a member leaves can
+ involve significant processing and protocol overhead and result in
+ significant delays that affect usability.
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 22]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ Like reliable multicast, secure multicast is also under investigation
+ in the Internet Research Task Force [IRTF]. Protocol mechanisms for
+ many of the most important of these services--such as limiting
+ senders--have not yet been defined, let alone developed and deployed.
+
+ As is true for reliable multicast, the current consensus is that no
+ single security protocol will satisfy the wide diversity of
+ sometimes-contradictory requirements among multicast applications.
+ Hence, multicast security will also likely require a number of
+ different protocols.
+
+5.6 Synchronized Play-Out
+
+ This refers to having all receivers simultaneously play-out the
+ multicast data they received. This may be necessary for fairness--
+ playing-out prices for auctions, or stock-prices--or to ensure
+ synchronization with other receivers, such as when playing music.
+
+ Here is an analogy to illustrate: Imagine a multi-speaker stereo
+ system that is wired throughout a home (via analog). With the stereo
+ playing on all speaker sets, you will hear continuous music as you
+ walk from room-to-room.
+
+ Now imagine a house full of multi-media and network enabled computer
+ systems. Although they will all receive the same music datastream
+ simultaneously via multicast, they will provide discontinuous music
+ playback as you walk room-to-room.
+
+ To provide synchronized playback that would enable continuous music
+ from room-to-room would require three things:
+
+ 1) system clocks on all systems should be synchronized
+ 2) datastreams must be framed with timestamps
+ 3) you must know the playback latency of the multimedia hardware
+
+ The third of these is the most difficult to achieve at this time.
+ Hardware and drivers don't provide any mechanism for retrieving this
+ information, although different audio and video devices have a wide-
+ range of performance.
+
+6. Service APIs
+
+ In some cases, the protocol services mentioned in this document can
+ be enabled transparently by passive configuration mechanisms and
+ "middleware". For example, it is conceivable that a UDP
+ implementation could implicitly enable a reliable multicast protocol
+ without the explicit interaction of the application.
+
+
+
+
+Quinn, et al. Informational [Page 23]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ Sometimes, however, applications need explicit access to these
+ services for flexibility and control. For example, an adaptive
+ application sending to a heterogeneous group of receivers using RTP
+ may need to process RTCP reports from receivers in order to adapt
+ accordingly (by throttling send rate or changing data encoders, for
+ example) [RTP API]. Hence, there is often a need for service APIs
+ that allow an application to qualify and initiate service requests,
+ and receive event notifications. In Figure 5, the top edge of the
+ box for each service effectively represents its API.
+
+ Network APIs generally reflect the protocols they support. Their
+ functionality and argument values are a (varying) subset of protocol
+ message types, header fields and values. Although some protocol
+ details and actions may not be exposed in APIs--since many protocol
+ mechanics need not be exposed--others are crucial to efficient and
+ flexible application operation.
+
+ A more complete examination of the application services described in
+ this document might also identify the protocol features that could be
+ mapped to define a (generic) API definition for that service. APIs
+ are often controversial, however. Not only are there many language
+ differences, but it is also possible to create different APIs by
+ exposing different levels of detail in trade-offs between flexibility
+ and simplicity.
+
+7. Security Considerations
+
+ See section 5.4
+
+8. Acknowledgements
+
+ The authors would like to acknowledge and thank the following
+ individuals for their helpful feedback: Ran Canetti, Brian Haberman,
+ Eric A. Hall, Kenneth C. Miller, and Dave Thaler.
+
+9. References
+
+ [AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host
+ Anycasting Service", RFC 1546, November 1993.
+
+ [BeauW] B. Williamson, "Developing IP Multicast Networks, Volume
+ I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
+ 077-9.
+
+ [BULK] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
+ Floyd, S. and M. Luby, "Reliable Multicast Transport
+ Building Blocks for One-to-Many Bulk-Data Transfer", RFC
+ 3048, January 2001.
+
+
+
+Quinn, et al. Informational [Page 24]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ [Deering] Deering, S., "Host Extensions for IP Multicasting", STD
+ 5, RFC 1112, August 1989.
+
+ [DIS] Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
+ Internet Protocol Suite for Distributed Simulation in the
+ Large Multicast Environment", RFC 2502, February 1999.
+
+ [E2EQOS] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
+ Speer, M., Braden, R. and B. Davie, "Integrated Services
+ Operation over Diffserv Networks", RFC 2998, November
+ 2000.
+
+ [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech
+ Earthlink Seminar Series, April 22, 1998.
+
+ [Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
+ May 1999.
+
+ [HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
+ of Feedback for Multicast", June 1999, Work in Progress.
+
+ [IGMPv2] Fenner, B., "Internet Group Management Protocol, Version
+ 2", RFC 2236, November 1997.
+
+ [IGMPv3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
+ "Internet Group Management Protocol, Version 3", Work in
+ Progress.
+
+ [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia
+ Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
+ of Audio/Video", Proceedings of the Seventh International
+ World Wide Web Conference, Brisbane, AUSTRALIA, April
+ 1998.
+
+ [IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and
+ Procedures", BCP 8, RFC 2014, January 1996.
+
+ [Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State
+ Option", RFC 2907, September 2000.
+
+ [LSMA] Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
+ Communication Requirements for Large-scale Multicast
+ Applications", RFC 2729, December 1999.
+
+ [MADDR] Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
+ "IANA Guidelines for IPv4 Multicast Address Assignments",
+ BCP 51, RFC 3171, August 2001.
+
+
+
+
+Quinn, et al. Informational [Page 25]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ [MASC] Estrin, D., Govindan, R., Handley, M., Kumar, S.,
+ Radoslavov, P. and D. Thaler, "The Multicast Address-Set
+ Claim (MASC) Protocol", RFC 2909, September 2000.
+
+ [Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise",
+ (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
+ 897687-2.
+
+ [Miller] C. K. Miller, "Multicast Networking and Applications",
+ (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
+ 30979-3.
+
+ [MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address
+ Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
+ December 1999.
+
+ [MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment
+ Efforts: A Survey of Tools for Multicast Monitoring",
+ Journal of High Speed Networking--Special Issue on
+ Management of Multimedia Networking, March 2001
+
+ [MSec] Multicast Security (msec) IETF Working Group charter
+
+ [MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
+ Zone Announcement Protocol (MZAP)", RFC 2776, February
+ 2000.
+
+ [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and
+ Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
+ January 1998.
+
+ [Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
+ workshop, June 1998, UCL London
+ http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
+
+ [RM] Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
+ "IETF Criteria for Evaluating Reliable Multicast
+ Transport and Application Protocols", RFC 2357, June
+ 1998.
+
+ [RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
+ Services", RFC 2210, September 1997.
+
+ [RTP API] H. Schulzrinne, et al, "RTP Library API Specification,"
+ http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
+ 1.0a1/rtp_api.html
+
+
+
+
+
+Quinn, et al. Informational [Page 26]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+ [RTP/RTCP] Schulzrinne, H., Casner, S., Frederick, R. and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", RFC 1889, January 1996.
+
+ [SAP] Handley, M., Perkins, C. and E. Whelan, "Session
+ Announcement Protocol", RFC 2974, October 2000.
+
+ [SDP] Handley, M., and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks",
+ December 1996, http://www.counterpane.com/whycrypto.html
+
+ [SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
+ Retransmit, and Fast Recovery Algorithms", RFC 2001,
+ January 1997.
+
+ [SLP] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
+ "Service Location Protocol", RFC 2165, June 1997.
+
+ [SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP",
+ Work in Progress.
+
+10. Authors' Addresses
+
+ Bob Quinn
+ Celox Networks
+ 2 Park Central Drive
+ Southborough, MA 01772
+
+ Phone: +1 508 305 7000
+ EMail: bquinn@celoxnetworks.com
+
+
+ Kevin Almeroth
+ Department of Computer Science
+ University of California
+ Santa Barbara, CA 93106-5110
+
+ Phone: +1 805 893 2777
+ EMail: almeroth@cs.ucsb.edu
+
+
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 27]
+
+RFC 3170 IP Multicast Applications September 2001
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Quinn, et al. Informational [Page 28]
+