draft-ietf-mboned-mcast-apps-00.txt   draft-ietf-mboned-mcast-apps-01.txt 
MBoneD Working Group Bob Quinn MBoneD Working Group Bob Quinn
Internet Engineering Task Force Stardust Forums Internet Engineering Task Force Stardust Forums
INTERNET-DRAFT Kevin Almeroth INTERNET-DRAFT Kevin Almeroth
26 February 1999 UCSB 25 June 1999 UCSB
Expires August 1999 Expires December 1999
IP Multicast Applications: IP Multicast Applications:
Challenges and Solutions Challenges and Solutions
<draft-ietf-mboned-mcast-apps-00.txt> <draft-ietf-mboned-mcast-apps-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4
2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4
2.1 Essential Protocol Components. . . . . . . . . . . . . . 5 2.1 Essential Protocol Components. . . . . . . . . . . . . . 5
2.11 Expedient Joins and Leaves. . . . . . . . . . . . . . 5 2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5
2.12 Send without a Join . . . . . . . . . . . . . . . . . 6 2.1.2 Send without a Join. . . . . . . . . . . . . . . . . 6
3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6
3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8
3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9
3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10 3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10
4. Common Multicast Service Requirements . . . . . . . . . . . 12 4. Common Multicast Service Requirements . . . . . . . . . . . 12
4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12
4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 12 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13
5. Unique Multicast Service Requirements . . . . . . . . . . . 13 5. Unique Multicast Service Requirements . . . . . . . . . . . 14
5.1 Address Management . . . . . . . . . . . . . . . . . . . 15 5.1 Address Management . . . . . . . . . . . . . . . . . . . 15
5.11 Scope Discovery . . . . . . . . . . . . . . . . . . . 15 5.1.1 Scope Discovery . . . . . . . . . . . . . . . . . . 16
5.2 Session Management . . . . . . . . . . . . . . . . . . . 16 5.2 Session Management . . . . . . . . . . . . . . . . . . . 16
5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 16 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 17
5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 18 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 19
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 21 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 22
6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23
9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 25 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 26 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
IP Multicast will play a prominent role on the Internet in the IP Multicast will play a prominent role on the Internet in the
coming years. It is a requirement, not an option, if the Internet coming years. It is a requirement, not an option, if the Internet
is going to scale. Multicast allows application developers "to add is going to scale. Multicast allows application developers "to add
more functionality without significantly impacting the network" more functionality without significantly impacting the network"
[Bradner]. [Bradner].
Developing multicast-enabled applications is ostensibly simple. Developing multicast-enabled applications is ostensibly simple.
Having datagram access allows any application to send to a multicast Having datagram access allows any application to send to a multicast
address. A multicast application need only increase the Internet address. A multicast application need only increase the Internet
Protocol (IP) time-to-live (TTL) value to more than 1 (the default Protocol (IP) time-to-live (TTL) value to more than 1 (the default
value) to allow outgoing datagrams to traverse routers. To receive value) to allow outgoing datagrams to traverse routers. To receive
a multicast datagram, applications join the multicast group, which a multicast datagram, applications join the multicast group, which
transparently generates an IGMP [IGMPV2] group membership report. transparently generates an [IGMPV2] group membership report.
This apparent simplicity is deceptive, however. Enabling multicast This apparent simplicity is deceptive, however. Enabling multicast
support in applications and protocols that can scale well on a support in applications and protocols that can scale well on a
heterogeneous network is a significant challenge. Specifically, heterogeneous network is a significant challenge. Specifically,
sending constant bit rate datastreams, reliable data delivery, sending constant bit rate datastreams, reliable data delivery,
security, and managing many-to-many communications all require security, and managing many-to-many communications all require
special consideration. Some solutions are available, but many of special consideration. Some solutions are available, but many of
these services are still active research areas. these services are still active research areas.
1.1 Motivation 1.1 Motivation
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Our initial premise is that the multicast infrastructure is Our initial premise is that the multicast infrastructure is
transparent to applications, so it is not directly relevant to this transparent to applications, so it is not directly relevant to this
discussion. Our focus here is on multicast application protocol discussion. Our focus here is on multicast application protocol
services, so this document explicitly avoids any discussion of services, so this document explicitly avoids any discussion of
multicast routing issues. We identify and describe the multicast- multicast routing issues. We identify and describe the multicast-
specific issues involved with developing applications. specific issues involved with developing applications.
We assume the reader has a general understanding of the mechanics of We assume the reader has a general understanding of the mechanics of
multicast, and in this respect we intend to compliment other multicast, and in this respect we intend to compliment other
introductory documents [Maufer, Maufer2, Miller]. Since this is an introductory documents [Maufer, Miller]. Since this is an
introductory survey rather than a comprehensive examination, we introductory survey rather than a comprehensive examination, we
refer readers to other multicast application requirements refer readers to other multicast application requirements
descriptions [LSMA, Miller] for more detail. descriptions [LSMA, Miller] for more detail.
In the remainder of this document we first define the term "IP In the remainder of this document we first define the term "IP
multicast enabled network," the multicast infrastructure and multicast enabled network," the multicast infrastructure and
essential multicast services. Next we describe the types of new essential multicast services. Next we describe the types of new
functionality that multicast applications can enable and their functionality that multicast applications can enable and their
requirements. We then examine the services that satisfy these requirements. We then examine the services that satisfy these
requirements, the challenges they present, and provide a brief requirements, the challenges they present, and provide a brief
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Ideally, these protocol components are transparent to multicast Ideally, these protocol components are transparent to multicast
applications. However, there are two aspects of their functionality applications. However, there are two aspects of their functionality
requirements that are worth mentioning specifically, since they requirements that are worth mentioning specifically, since they
affect application performance and design. These are the multicast affect application performance and design. These are the multicast
application requirements for: application requirements for:
- Expedient Joins and Leaves - Expedient Joins and Leaves
- Sends without a Join - Sends without a Join
2.11 Expedient Joins and Leaves 2.1.1 Expedient Joins and Leaves
Some applications require expedient group joins and leaves, as their Some applications require expedient group joins and leaves, as their
usability or functionality are sensitive to the latency involved usability or functionality are sensitive to the latency involved
with joining and leaving a group. with joining and leaving a group.
Join Latency: The time it takes for data to begin flowing after an Join Latency: The time it takes for data to begin flowing after an
application issues a command to join a multicast group application issues a command to join a multicast group
Leave Latency: The time it takes for data to stop flowing after an Leave Latency: The time it takes for data to stop flowing after an
application issues a command to leave a multicast group application issues a command to leave a multicast group
skipping to change at page 6, line 8 skipping to change at page 6, line 7
a user requirement than an application requirement. a user requirement than an application requirement.
The functionality of distributed interactive simulations [DIS] is The functionality of distributed interactive simulations [DIS] is
often sensitive to join/leave latency. This is particularly true often sensitive to join/leave latency. This is particularly true
when trying to exchange information to represent fast moving objects when trying to exchange information to represent fast moving objects
that quickly enter and exit the scope of a simulated environment that quickly enter and exit the scope of a simulated environment
(e.g. low-flying, fast-moving aircraft). If the join latency is too (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 long, the information provided may be old by the time it is
received. 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 Applications cannot affect control over either join or leave
latency, but are dependent on the multicast infrastructure to enable latency, but are dependent on the multicast infrastructure to enable
expedient operations. This is a basic multicast service expedient operations. This is a basic multicast service
requirement. requirement.
2.12 Sends without a Join 2.1.2 Sends without a Join
Applications that send to a multicast address should be able to Applications that send to a multicast address should be able to
start sending immediately, without having to join the destination start sending immediately, without having to join the destination
group first. This is important for embedded devices and bursty- group first. This is important for embedded devices and bursty-
source applications with low-delay delivery requirements. source applications with low-delay delivery requirements.
The current IGMP-based multicast host model and all current The current IGMP-based multicast host model and all current
implementations allow senders to send to a group without joining it implementations allow senders to send to a group without joining it
as a standard feature. as a standard feature.
skipping to change at page 10, line 28 skipping to change at page 10, line 25
n) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth n) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth
demands vary based on the encoding technique, sample rate, demands vary based on the encoding technique, sample rate,
sample resolution, number of channels, etc. sample resolution, number of channels, etc.
3.3 Many-to-One Applications 3.3 Many-to-One Applications
Unlike the one-to-many and many-to-many application categories, the Unlike the one-to-many and many-to-many application categories, the
many-to-one (Mto1) category does not represent a communications many-to-one (Mto1) category does not represent a communications
mechanism at the IP layer. Mto1 applications have multiple senders mechanism at the IP layer. Mto1 applications have multiple senders
and a single receiver, as defined by the application layer. Table 1 and one (or a few) receiver(s), as defined by the application layer.
shows that Mto1 applications can be one-way or use a two-way Table 1 shows that Mto1 applications can be one-way or use a two-way
request/response type protocol, where either senders or receivers request/response type protocol, where either senders or receiver(s)
may generate the request. Figure 2 characterizes the I/O may generate the request. Figure 2 characterizes the I/O
relationship possibilities in Mto1 applications: relationship possibilities in Mto1 applications:
1) S1 2) S1 3) S1 4) S1 1) S1 2) S1 3) S1 4) S1
\ \ \ \ \ \ \ \
S2-R S2-R S2-R S2-R S2-R S2-R S2-R S2-R
.../ .../ .../ .../ .../ .../ .../ .../
Sn Sn Sn Sn Sn Sn Sn Sn
Data(m) Request(m) Request(m) Request(u) Data(m) Request(m) Request(m) Request(u)
------> ----------> <---------- ----------> ------> ----------> <---------- ---------->
Response(u) Response(u) Response(m) Response(u) Response(u) Response(m)
<----------- -----------> <---------- <----------- -----------> <----------
Figure 2: Characterization of Mto1 I/O possibilities Figure 2: Characterization of Mto1 I/O possibilities
Receivers in Mto1 applications have scaling issues. Too many Mto1 applications have many scaling issues. Too many simultaneous
simultaneous senders can potentially overwhelm a receiver. In other senders can potentially overwhelm receiver(s), a condition
words, they may have an "implosion problem." 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 bidirectional trees in multicast routing
protocols, but nonetheless it should be considered by application
designers.
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 the 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 although standard solutions have not
yet been identified, Mto1 application developers should consider
their alternatives carefully.
o) Resource Discovery: Service Location, for example, leverages IP o) Resource Discovery: Service Location, for example, leverages IP
Multicast to enable something like a "host anycasting service" Multicast to enable something like a "host anycasting service"
capability [AnyCast]: A multicast receiver to send a query to a capability [AnyCast]: A multicast receiver to send a query to a
group address, to elicit responses from the closest host so group address, to elicit responses from the closest host so
they can satisfy the request. The responses might also contain they can satisfy the request. The responses might also contain
information that allows the receiver to determine the most information that allows the receiver to determine the most
appropriate (e.g. closest) service provider to use. appropriate (e.g. closest) service provider to use.
In Table 1, this application is entry D4. It is also In Table 1, this application is entry D4. It is also
skipping to change at page 12, line 26 skipping to change at page 12, line 44
constant but each receiver sends less. constant but each receiver sends less.
4. Common Multicast Service Requirements 4. Common Multicast Service Requirements
Some multicast application service requirements are common to Some multicast application service requirements are common to
unicast network applications as well. We characterize two of them unicast network applications as well. We characterize two of them
here--bandwidth and delay requirements. here--bandwidth and delay requirements.
4.1 Bandwidth Requirements 4.1 Bandwidth Requirements
Figure 2 shows multicast applications approximate bandwidth Figure 3 shows multicast applications approximate bandwidth
requirements. requirements.
Unicast and multicast applications both need to design applications
to adapt to the variability of network conditions. But as we
describe in section 4.1, 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 1toM | b, d c, e a
| |
MtoM | k g, i f, h, j, l, m, n MtoM | k g, i f, h, j, l, m, n
| |
Mto1 | o, q, r p, q s Mto1 | o, q, r p, q, t s
| |
+----------------------------------------------- +-----------------------------------------------
Low Bandwidth High Bandwidth Low Bandwidth High Bandwidth
Figure 3: Bandwidth Requirements of applications Figure 3: Bandwidth Requirements of applications
Unicast and multicast applications both need to design applications
to adapt to the variability of network conditions. But as we
describe in section 4.1, 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.
4.2 Delay Requirements 4.2 Delay Requirements
Aside from those with time-sensitive data (e.g. stock prices, and Aside from those with time-sensitive data (e.g. stock prices, and
real-time monitoring information), most one-to-many applications real-time monitoring information), most one-to-many applications
have a high tolerance for delay and delay variance (jitter). have a high tolerance for delay and delay variance (jitter).
Constant bit-rate (CBR) data--such as streaming media (audio/video)- Constant bit-rate (CBR) data--such as streaming media (audio/video)-
-are sensitive to jitter, but applications commonly counteract the -are sensitive to jitter, but applications commonly counteract the
effects by buffering data and delaying playback. effects by buffering data and delaying playback.
Most many-to-one and many-to-many multicast applications are Most many-to-one and many-to-many multicast applications are
intolerant of delays because they are bidirectional, interactive and intolerant of delays because they are bidirectional, interactive and
request/response dependent. As a result, delays should be request/response dependent. As a result, delays should be
minimized, since they can adversely affect the application's minimized, since they can adversely affect the application's
usability. usability.
skipping to change at page 13, line 18 skipping to change at page 13, line 35
Most many-to-one and many-to-many multicast applications are Most many-to-one and many-to-many multicast applications are
intolerant of delays because they are bidirectional, interactive and intolerant of delays because they are bidirectional, interactive and
request/response dependent. As a result, delays should be request/response dependent. As a result, delays should be
minimized, since they can adversely affect the application's minimized, since they can adversely affect the application's
usability. usability.
This need to minimize delays is most evident in (two-way) conference This need to minimize delays is most evident in (two-way) conference
applications, where users cannot converse effectively if the audio applications, where users cannot converse effectively if the audio
or video is delayed more than 500 milliseconds. For this and other or video is delayed more than 500 milliseconds. For this and other
examples see Figure 3, which plots multicast applications on a examples see Figure 4, which plots multicast applications on a
(coarse) scale of sensitivity to delivery delays. (coarse) scale of sensitivity to delivery delays.
| |
1toM | b, c a, d e 1toM | b, c a, d e
| |
MtoM | g, i, j, k f, h, l, m, n MtoM | g, i, j, k f, h, l, m, n
| |
Mto1 | r o, p, s q Mto1 | r o, p, s, t q
| |
+----------------------------------------------- +-----------------------------------------------
Delay Tolerant Delay Intolerant Delay Tolerant Delay Intolerant
Figure 4: Delay tolerance of application types Figure 4: Delay tolerance of application types
For delay-intolerant multicast (or unicast) applications, quality of For delay-intolerant multicast (or unicast) applications, quality of
service (QoS) is the only option. IP networks currently provide service (QoS) is the only option. IP networks currently provide
only "best effort" delivery, so data are subject to variable router only "best effort" delivery, so data are subject to variable router
queuing delays and loss due to network congestion (router queue queuing delays and loss due to network congestion (router queue
overflows). IP QoS standards do exist now [RSVP] and efforts to overflows). IP QoS standards do exist now [RSVP] and efforts to
enable end-to-end QoS support in the Internet are underway enable end-to-end QoS support in the Internet are underway [E2EQOS].
[DiffServ].
However, QoS support is an IP network infrastructure consideration However, QoS support is an IP network infrastructure consideration.
and relevant to unicast as well as multicast. Since our focus is on Although there are multicast-specific challenges for implementing
multicast-specific application services, further discussion of the QoS in the network for multicast flows, they are beyond the control
QoS protocols and services is beyond the scope of this document. of applications, so further discussion of the QoS protocols and
services is beyond the scope of this document.
5. Unique Multicast Service Requirements 5. Unique Multicast Service Requirements
The three application categories described earlier are very general The three application categories described earlier are very general
in nature. Within each category and even among each of the in nature. Within each category and even among each of the
application types, specific application instances have a variety of application types, specific application instances have a variety of
application requirements. One-to-many application types are application requirements. One-to-many application types are
relatively simple to develop, but as we pointed out there are relatively simple to develop, but as we pointed out there are
challenges involved with developing many-to-one and many-to-many challenges involved with developing many-to-one and many-to-many
applications. Some of these have requirements bandwidth and delay applications. Some of these have requirements bandwidth and delay
skipping to change at page 15, line 31 skipping to change at page 15, line 50
Hard-Coded: Software configuration, encoded in a binary Hard-Coded: Software configuration, encoded in a binary
executable, or burned into ROM in embedded devices. These executable, or burned into ROM in embedded devices. These
applications typically reference IANA statically allocated applications typically reference IANA statically allocated
multicast addresses (including relative addresses). multicast addresses (including relative addresses).
Advertised: Session announcements (as described in the next Advertised: Session announcements (as described in the next
section), or via another "out-of-band" query or discovery section), or via another "out-of-band" query or discovery
protocol mechanism. protocol mechanism.
Algorithmically Derived: Using a programmatic algorithm to Algorithmically Derived: Using a programmatic algorithm to
statistically allocate a statistically random (unused) address.
| |
1toM | c, e a, b d 1toM | c, e a, b d
| |
MtoM | f, j, k, n g, h, i, l, m MtoM | f, j, k, n g, h, i, l, m
| |
Mto1 | r o, p, s q Mto1 | r o, p, s q, t
| |
+----------------------------------------------- +-----------------------------------------------
Hard-Coded Advertised Algorithmic Hard-Coded Advertised Algorithmic
Figure 6: Multicast address usage for application types Figure 6: Multicast address usage for application types
5.11 Scope Discovery 5.1.1 Scope Discovery
Scope Discovery is a function of address management required by some Scope Discovery is a function of address management required by some
applications, to discover the scoped multicast addresses in use applications. An option for [MADCAP] allows clients to learn which
[SADP]. This service assumes the use of Multicast Zone Announcement scopes nest inside each other, for the purpose of executing
Protocol [MZAP] as a back-end. expanding ring searches (among other things) [Kermode]. Scoped
Address Discovery Protocol [SADP] allows applications to discover
the administratively scoped multicast addresses already allocated to
a session within one or more administrative scopes in a hierarchy of
nested scopes. These protocols assume the use of Multicast Zone
Announcement Protocol [MZAP] as a _back-end_ (transparent to
applications), since it enables the creation of such hierarchies.
5.2 Session Management 5.2 Session Management
Multicast applications need a "namespace" that provides session Multicast applications need a "namespace" that provides session
directory services that can be used to co-ordinate application directory services that can be used to co-ordinate application
schedules and resources, and describe session attributes. These map schedules and resources, and describe session attributes. These map
multicast address and port combinations to a date and time, content multicast address and port combinations to a date and time, content
description, and other session attributes (e.g. bandwidth and delay description, and other session attributes (e.g. bandwidth and delay
requirements, encoding, security and authorization methods, etc.). requirements, encoding, security and authorization methods, etc.).
skipping to change at page 18, line 42 skipping to change at page 19, line 16
protocol design as the user experience. The adaptive mechanisms protocol design as the user experience. The adaptive mechanisms
must also be stable, so they do not adapt too quickly--changing must also be stable, so they do not adapt too quickly--changing
encoding and rates based on too little information about what may be encoding and rates based on too little information about what may be
a transient condition--to avoid oscillation. a transient condition--to avoid oscillation.
This "feedback loop" service necessary for support of heterogeneous This "feedback loop" service necessary for support of heterogeneous
receivers is not illustrated in the services summary in Figure 4, receivers is not illustrated in the services summary in Figure 4,
although it could be added alongside "Reliable Transport" and the although it could be added alongside "Reliable Transport" and the
others. This service could be implemented within an application or others. This service could be implemented within an application or
accessed externally, as provided by the operating system or a third accessed externally, as provided by the operating system or a third
party. 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 5.4 Reliable Data Delivery
Many of the multicast application examples in our list--like Many of the multicast application examples in our list--like
audio/video distribution--have loss-tolerant data content. In other audio/video distribution--have loss-tolerant data content. In other
words, the data content itself can remain useful even if some of it 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 is lost. For example, audio might have a short gap or lower
fidelity but will remain legible despite some data loss. fidelity but will remain legible despite some data loss.
Other application examples--like caching and synchronized resources- Other application examples--like caching and synchronized resources-
-require reliable data delivery. They deliver content that must be -require reliable data delivery. They deliver content that must be
complete, unchanged, in sequence, and without duplicates. The "Loss complete, unchanged, in sequence, and without duplicates. The "Loss
Intolerant" column in Figure 5 shows a list of applications with Intolerant" column in Figure 7 shows a list of applications with
this requirement, while the others can tolerate varying levels of this requirement, while the others can tolerate varying levels of
data loss. The tolerance levels are typically determined by the data loss. The tolerance levels are typically determined by the
nature of the data and the encoding in use. nature of the data and the encoding in use.
| |
1toM | b a, d c, e 1toM | b a, d c, e
| |
MtoM | f, j, k, l, m, n g, h, i MtoM | f, j, k, l, m, n g, h, i
| |
Mto1 | o, p, r, s q Mto1 | o, p, r, s, t q
| |
+------------------------------------------------ +------------------------------------------------
Loss Tolerant Loss Intolerant Loss Tolerant Loss Intolerant
Figure 7: Reliability Requirements of Application types Figure 7: Reliability Requirements of Application types
Some of the challenges involved with enabling reliable multicast Some of the challenges involved with enabling reliable multicast
transport are the same as those of sending to heterogeneous transport are the same as those of sending to heterogeneous
receivers, and some solutions are similar also. For example, many receivers, and some solutions are similar also. For example, many
reliable multicast transport protocols avoid the implosion problem reliable multicast transport protocols avoid the implosion problem
skipping to change at page 19, line 42 skipping to change at page 20, line 19
Although reliable delivery cannot change the data sent--except, Although reliable delivery cannot change the data sent--except,
perhaps, to use a loss-less data compression algorithm--they can use perhaps, to use a loss-less data compression algorithm--they can use
other adaptive techniques like sending redundant data, or adjusting other adaptive techniques like sending redundant data, or adjusting
the send rate. the send rate.
Although many reliable multicast protocol implementations exist Although many reliable multicast protocol implementations exist
[Obraczka], and a few are already available in commercial products, [Obraczka], and a few are already available in commercial products,
none of them are standardized. Work is ongoing in the "Reliable none of them are standardized. Work is ongoing in the "Reliable
Multicast" research group of the Internet Research Task Force [IRTF] Multicast" research group of the Internet Research Task Force [IRTF]
to provide a better definition of the problem, the multicast to provide a better definition of the problem, the multicast
transport requirements, and protocol mechanisms. transport requirements, and protocol mechanisms. The IETF Relialbe
Multicast Transport (RMT) working group is focusing on designing
some working solutions in recognition of the urgent need for
scalable reliable multicast transport [RMT BLOCKS, RMT DESIGN].
Scalability is the paramount concern, and it implies the general Scalability is the paramount concern, and it implies the general
need for "network friendly" protocols that detect and avoid need for "network friendly" protocols that detect and avoid
congestion as they provide reliable delivery. Other considerations congestion as they provide reliable delivery. Other considerations
are protocol robustness, support for "late joins", group management are protocol robustness, support for "late joins", group management
and security (which we discuss next). and security (which we discuss next).
The current consensus is that due to the wide variety of multicast The current consensus is that due to the wide variety of multicast
application requirements--some of which are at odds--no single application requirements--some of which are at odds--no single
multicast transport will likely be appropriate for all applications. multicast transport will likely be appropriate for all applications.
skipping to change at page 23, line 12 skipping to change at page 23, line 39
APIs by exposing different levels of detail in trade-offs between APIs by exposing different levels of detail in trade-offs between
flexibility and simplicity. flexibility and simplicity.
7. Security Considerations 7. Security Considerations
See section 4.4 See section 4.4
8. Acknowledgements 8. Acknowledgements
The author would like to acknowledge and thank the following The author would like to acknowledge and thank the following
individuals for their helpful feedback: Kevin Almeroth, Ran Canetti, individuals for their helpful feedback: Ran Canetti, Brian Haberman,
Brian Haberman, Eric A. Hall, Kenneth C. Miller, and Dave Thaler. Eric A. Hall, Kenneth C. Miller, and Dave Thaler.
9. References 9. References
[AnyCast] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting [AnyCast] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993 Service", RFC 1546, November 1993
[Bradner] S. Bradner, "Internet Protocol Multicast Problem [Bradner] S. Bradner, "Internet Protocol Multicast Problem
Statement", <draft-bradner-multicast-problem-00.txt>, Statement", <draft-bradner-multicast-problem-00.txt>,
September 1997, Work in Progress September 1997, Work in Progress
[Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security
issues(temporary version)", <draft-canetti-secure- issues", <draft-irtf-smug-taxonomy-00.txt>, April 1999,
multicast-taxonomy-00.txt>, May 1998, Work in Progress Work in Progress
[Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to [Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to
Facilitate Multicast Firewall Traversal", <draft-ietf- Facilitate Multicast Firewall Traversal", <draft-ietf-
aft-mcast-fw-traversal-01.txt>, Nov 1997, Work in aft-mcast-fw-traversal-01.txt>, November 1997, Work in
Progress Progress
[DiffServ] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang,
Nichols, and M. Speer, "A Framework for Use of RSVP with M. Speer, R. Braden, B. Davie, "Integrated Services
Diff-serv Networks", Internet Draft <draft-ietf-diffserv- Operation over Diffserv Networks", <draft-ietf-issll-
rsvp-01.txt>, November 1998, Work in Progress diffserv-rsvp-02.txt>, June 1999, Work in Progress
[DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of [DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of
Internet Protocol Suite for Distributed Simulation in the Internet Protocol Suite for Distributed Simulation in the
Large Multicast Environment", RFC 2502, February 1999 Large Multicast Environment", RFC 2502, February 1999
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech
Earthlink Seminar Series, April 22, 1998 Earthlink Seminar Series, April 22, 1998
[Finlayson] R. Finlayson, "IP Multicast and Firewalls", <draft-ietf- [Finlayson] R. Finlayson, "IP Multicast and Firewalls", RFC 2588,
mboned-mcast-firewall-02.txt>, November 1998, Work in May 1999
Progress
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
of Feedback for Multicast", June 1999, Work in Progress
[IGMPv2] B. Fenner, "Internet Group Management Protocol, Version [IGMPv2] B. Fenner, "Internet Group Management Protocol, Version
2", RFC 2236, November 1997 2", RFC 2236, November 1997
[IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia
Jukebox (IMJ): A New Paradigm for the On-Demand Delivery Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
of Audio/Video", Proceedings of the Seventh International of Audio/Video", Proceedings of the Seventh International
World Wide Web Conference, Brisbane, AUSTRALIA, April World Wide Web Conference, Brisbane, AUSTRALIA, April
1998 1998
[IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and [IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and
Procedures", RFC 2014, January 1996 Procedures", RFC 2014, January 1996
[Kermode] R. Kermode, "MADCAP Multicast Scope Nesting State
Option", February 1999, <draft-kermode-madcap-nest-opt-
00.txt>, Work in Progress
[LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of [LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of
Communication Requirements, for Large-scale Multicast Communication Requirements, for Large-scale Multicast
Applications," <draft-ietf-lsma-requirements-02.txt>, Applications," <draft-ietf-lsma-requirements-03.txt>,
November 1998, Work in Progress May 1999, Work in Progress
[MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P.
Radoslavov, D. Thaler, "The Multicast Address-Set Claim Radoslavov, D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", <draft-ietf-malloc-masc-01.txt>, August (MASC) Protocol", <draft-ietf-malloc-masc-01.txt>, August
1998, Work in Progress 1998, Work in Progress
[Maufer] T. Maufer, C. Semeria, "Introduction to IP Multicast [Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise",
Routing," <draft-ietf-mboned-intro-multicast-03.txt>,
July 1997, Work in Progress
[Maufer2] T. Maufer, "Deploying IP Multicast in the Enterprise",
(c) 1998 Prentice Hall, Upper Saddle River NJ (c) 1998 Prentice Hall, Upper Saddle River NJ
ISBN 0-13-897687-2 ISBN 0-13-897687-2
[Miller] C. K. Miller, "Multicast Networking and Applications", [Miller] C. K. Miller, "Multicast Networking and Applications",
(c) 1999 Addison Wesley Longman, Reading MA (c) 1999 Addison Wesley Longman, Reading MA
ISBN 0-201-30979-3 ISBN 0-201-30979-3
[MADCAP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address [MADCAP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", Dynamic Client Allocation Protocol (MADCAP)",
<draft-ietf-malloc-madcap-04.txt>, February 1999, <draft-ietf-malloc-madcap-04.txt>, February 1999,
Work in Progress Work in Progress
[MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast- [MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast-
Friendly Internet Exchange (MIX)," <draft-ietf-mboned- Friendly Internet Exchange (MIX)", <draft-ietf-mboned-
mix-00.txt>, Dec 1998, Work in Progress mix-00.txt>, Dec 1998, Work in Progress
[MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone
Announcement Protocol (MZAP) ", <draft-ietf-mboned-mzap-
03.txt>, Feb 1999, Work in Progress
[Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and
Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
January 1998 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] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF [RM] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998 Application Protocols", RFC 2357, June 1998
[RM BLOCKS] B. Whetten, L. Vicisano, R. Kermode, M. Handley,
S. Floyd, "Reliable Multicast Transport Building Blocks
for One-to-Many Bulk-Data Transfer", <draft-ietf-rmt-
buildingblocks-00.txt>, June 1999, Work in Progress
[RM DESIGN] M. Handley, B. Whetten, R. Kermode, S. Floyd,
L. Vicisano, "The Reliable Multicast Design Space for
Bulk Data Transfer", <draft-ietf-rmt-design-space-00.txt>
June 1999, Work in Progress
[RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated [RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997 Services", RFC 2210, September 1997
[RTP API] J. Rosenberg, "Columbia RTP Library API Specification," [RTP API] J. Rosenberg, "Columbia RTP Library API Specification,"
(Note: Does not include RTCP processing), February 1997 (Note: Does not include RTCP processing), February 1997
[RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996 RFC 1889, January 1996
[SAP] M. Handley, "SAP: Session Announcement Protocol", <draft- [SAP] M. Handley, "SAP: Session Announcement Protocol", <draft-
ietf-mmusic-sap-00.txt>, November 1996, Work in Progress ietf-mmusic-sap-00.txt>, November 1996, Work in Progress
skipping to change at page 25, line 14 skipping to change at page 26, line 13
[RTP API] J. Rosenberg, "Columbia RTP Library API Specification," [RTP API] J. Rosenberg, "Columbia RTP Library API Specification,"
(Note: Does not include RTCP processing), February 1997 (Note: Does not include RTCP processing), February 1997
[RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996 RFC 1889, January 1996
[SAP] M. Handley, "SAP: Session Announcement Protocol", <draft- [SAP] M. Handley, "SAP: Session Announcement Protocol", <draft-
ietf-mmusic-sap-00.txt>, November 1996, Work in Progress ietf-mmusic-sap-00.txt>, November 1996, Work in Progress
[SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol
(SADP) ", <draft-ietf-mboned-sadp-01.txt>, Jan 1999, Work
in Progress
[SDP] M. Handley, V. Jacobson, "SDP: Session Description [SDP] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998 Protocol", RFC 2327, April 1998
[Schneier] B. Schneier, _ Why Cryptography Is Harder Than It Looks", [Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks",
December 1996, http://www.counterpane.com/whycrypto.html December 1996, http://www.counterpane.com/whycrypto.html
[SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast [SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001, Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997 January 1997
[SLP] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service [SLP] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service
Location Protocol", RFC 2165, June 1997 Location Protocol", RFC 2165, June 1997
10. Authors' Addresses 10. Authors' Addresses
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/