draft-ietf-mboned-mcast-apps-01.txt   draft-ietf-mboned-mcast-apps-02.txt 
MBoneD Working Group Bob Quinn MBoneD Working Group Bob Quinn
Internet Engineering Task Force Stardust Forums Internet Engineering Task Force Celox Networks
INTERNET-DRAFT Kevin Almeroth INTERNET-DRAFT Kevin Almeroth
25 June 1999 UCSB March 2001 UC-Santa Barbara
Expires December 1999 Expires September 2001
IP Multicast Applications: IP Multicast Applications:
Challenges and Solutions Challenges and Solutions
<draft-ietf-mboned-mcast-apps-01.txt> <draft-ietf-mboned-mcast-apps-02.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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as "work in progress."
"work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the challenges involved with designing and This document describes the challenges involved with designing and
implementing multicast applications. It is an introductory guide implementing multicast applications. It is an introductory guide for
for application developers that highlights the unique considerations application developers that highlights the unique considerations of
of multicast applications as compared to unicast applications. multicast applications as compared to unicast applications.
To this end, the document presents a taxonomy of multicast To this end, the document presents a taxonomy of multicast
application I/O models and examples of the services they can application I/O models and examples of the services they can support.
support. It then describes the service requirements of these It then describes the service requirements of these multicast
multicast applications, and the recent and ongoing efforts to build applications, and the recent and ongoing efforts to build protocol
protocol solutions to support these services. solutions to support these services.
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Quinn and Almeroth Expires September 2001 [Page 1]
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.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5 2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5
2.1.2 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 . . . . . . . . . . . 13
4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 13
4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13
5. Unique Multicast Service Requirements . . . . . . . . . . . 14 5. Unique Multicast Service Requirements . . . . . . . . . . . 14
5.1 Address Management . . . . . . . . . . . . . . . . . . . 15 5.1 Address Management . . . . . . . . . . . . . . . . . . . 16
5.1.1 Scope Discovery . . . . . . . . . . . . . . . . . . 16 5.2 Session Management . . . . . . . . . . . . . . . . . . . 17
5.2 Session Management . . . . . . . . . . . . . . . . . . . 16 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 18
5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 17 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 20
5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 19 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 21
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 23
5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 22
6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 24
9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 28
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 28
Quinn and Almeroth Expires September 2001 [Page 2]
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
coming years. It is a requirement, not an option, if the Internet years. It is a requirement, not an option, if the Internet is going
is going to scale. Multicast allows application developers "to add to scale. Multicast allows application developers "to add more
more functionality without significantly impacting the network" 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
a multicast datagram, applications join the multicast group, which multicast datagram, applications join the multicast group, which
transparently generates an [IGMPV2] group membership report. transparently generates an [IGMPv2, IGMPv3] 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
The purpose of this document is to provide a framework for The purpose of this document is to provide a framework for
understanding the challenges of designing and implementing multicast understanding the challenges of designing and implementing multicast
applications. In order to use multicast communications correctly, applications. In order to use multicast communications correctly,
application developers must first understand the various I/O models application developers must first understand the various I/O models
and the network services (in addition to basic multicast and the network services (in addition to basic multicast
communication) that are required. Secondly, application developers communication) that are required. Secondly, application developers
need to be aware of efforts underway to provide these services. need to be aware of efforts underway to provide these services. Such
Such efforts range in maturity from deployed commercial products to efforts range in maturity from deployed commercial products to basic
basic research efforts to evaluate feasibility. research efforts to evaluate feasibility.
Multicast-based applications and services will play an important Multicast-based applications and services will play an important role
role in the future of the Internet as continued multicast deployment in the future of the Internet as continued multicast deployment
encourages their use and development. It is important that encourages their use and development. It is important that
developers be aware of the issues and solutions available--and developers be aware of the issues and solutions available--and
especially of their limitations--in order to avoid protocols that especially of their limitations--in order to avoid protocols that
negatively impact networks (thereby counter-acting the benefits of negatively impact networks (thereby counter-acting the benefits of
multicast) or wasting their efforts "re-inventing the wheel." multicast) or wasting their efforts "re-inventing the wheel."
The hope is that by raising developers' awareness, we can adjust The hope is that by raising developers' awareness, we can adjust
their expectations of finding solutions and lead them to successful, their expectations of finding solutions and lead them to successful,
scalable, and "network-friendly" development efforts. scalable, and "network-friendly" development efforts.
Quinn and Almeroth Expires September 2001 [Page 3]
1.2 Focus and Scope 1.2 Focus and Scope
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, Miller]. Since this is an introductory documents [BeauW, Maufer, Miller]. Since this is an
introductory survey rather than a comprehensive examination, we introductory survey rather than a comprehensive examination, we refer
refer readers to other multicast application requirements readers to other multicast application requirements descriptions [RM,
descriptions [LSMA, Miller] for more detail. 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 survey
survey of the solutions available or under development. We wrap up of the solutions available or under development. We wrap up with a
with a discussion of application programming interfaces (APIs) for discussion of application programming interfaces (APIs) for multicast
multicast services. services.
2. IP Multicast Enabled Network 2. IP Multicast Enabled Network
An "IP multicast-enabled network" provides end-to-end services in An "IP multicast-enabled network" provides end-to-end services in the
the IP network infrastructure to allow any IP host to send datagrams IP network infrastructure to allow any IP host to send datagrams to
to an IP multicast address that any number of other IP hosts widely an IP multicast address that any number of other IP hosts widely
dispersed can receive. dispersed can receive.
At the time of this writing end-to-end "global" multicast service is 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 of knowing 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.
Quinn and Almeroth Expires September 2001 [Page 4]
At the time of this writing, end-to-end "global" multicast service is
not yet available, but the size of the "multicast-enabled" Internet not yet available, but the size of the "multicast-enabled" Internet
is growing. Recent development and deployment of interdomain is growing. Recent development and deployment of interdomain
multicast routing protocols and multicast-friendly Internet multicast routing protocols and multicast-friendly Internet exchanges
exchanges [MIX] have enabled peering between major ISPs. This, [MIX] have enabled peering between major ISPs. This, along with the
along with the increasing availability of compelling content, is increasing availability of compelling content, is spurring deployment
spurring deployment and availability of the IP Multicast Enabled and availability of the IP Multicast Enabled Network.
Network.
In the remainder of this document we assume that the multicast- In the remainder of this document we assume that the multicast-
enabled network is already ubiquitous. Since such a large and enabled network is already ubiquitous. Since such a large and
growing portion of the global Internet is IP multicast-enabled now, growing portion of the global Internet is IP multicast-enabled now,
and many enterprise networks (intranets) are also, this perspective and many enterprise networks (intranets) are also, this perspective
is relevant today. is relevant today.
2.1 Essential Protocol Components 2.1 Essential Protocol Components
An IP multicast enabled network requires two essential protocol An IP multicast enabled network requires two essential protocol
components: components:
1) An IP host-based protocol to allow a receiver application to 1) An IP host-based protocol to allow a receiver application to
notify a local router(s) that it has joined the group, and notify a local router(s) that it has joined the group, and
initiate the data flow from all sender(s) within the scope initiate the data flow from all sender(s) within the scope
2) An IP router-based protocol to allow any routers with multicast 2) An IP router-based protocol to allow any routers with multicast
group members (receivers) on their local networks to group members (receivers) on their local networks to communicate
communicate with other routers to ensure that all datagrams with other routers to ensure that all datagrams sent to the
sent to the group address are forwarded to all receivers within group address are forwarded to all receivers within the intended
the intended scope scope
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.1.1 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
with joining and leaving a group. 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
Quinn and Almeroth Expires September 2001 [Page 5]
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
[IGMPv2] [IGMPv2,IGMPv3]
For example, using distributed a/v as a multicast-based "television" For example, using distributed a/v as a multicast-based "television"
must allow users to "channel surf"--changing channels frequently. must allow users to "channel surf"--changing channels frequently.
Each channel change generates a group leave and group join, so Each channel change generates a group leave and group join, so delays
delays in either will affect usability. In a sense, this is more of in either will affect usability. In a sense, this is more of a user
a user requirement than an application requirement. 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 A fast leave phase is highly desirable both for effective congestion
control mechanisms, to stop undesirable flows quickly, and for the control mechanisms, to stop undesirable flows quickly, and for the
network in general, to better filter unwanted traffic [Rizzo]. 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,
latency, but are dependent on the multicast infrastructure to enable but are dependent on the multicast infrastructure to enable expedient
expedient operations. This is a basic multicast service operations. This is a basic multicast service requirement.
requirement.
2.1.2 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
start sending immediately, without having to join the destination sending immediately, without having to join the destination group
group first. This is important for embedded devices and bursty- first. This is important for embedded devices and bursty-source
source applications with low-delay delivery requirements. 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.
3. IP Multicast Application Taxonomy 3. IP Multicast Application Taxonomy
With an IP multicast-enabled network available, some unique and With an IP multicast-enabled network available, some unique and
powerful applications and application services are possible. powerful applications and application services are possible.
"Multicast enables coordination - it is well suited to loosely "Multicast enables coordination - it is well suited to loosely
coupled distributed systems (of people, servers, databases, coupled distributed systems (of people, servers, databases,
processes, devices...)" [Estrin]. processes, devices...)" [Estrin].
Quinn and Almeroth Expires September 2001 [Page 6]
A "multicast application" is simply defined as any application that A "multicast application" is simply defined as any application that
sends to and/or receives from an IP multicast address. These may or sends to and/or receives from an IP multicast address. These may or
may not also reference IP unicast addresses, as we describe later. may not also reference IP unicast addresses, as we describe later.
What differentiates IP multicast applications from one-to-one What differentiates IP multicast applications from one-to-one unicast
unicast applications are the other sender and receiver relationships applications are the other sender and receiver relationships
multicast enables. There are three general categories of multicast multicast enables. There are three general categories of multicast
applications: applications:
One-to-Many (1toM): A single host sending to two or more (n) One-to-Many (1toM): A single host sending to two or more (n)
receivers receivers
Many-to-Many (MtoM): Any number of hosts sending to the same Many-to-Many (MtoM): Any number of hosts sending to the same
multicast group address, as well as receiving from it multicast group address, as well as receiving from it
Many-to-One (Mto1): Any number of receivers sending data back to a Many-to-One (Mto1): Any number of receivers sending data back to a
skipping to change at page 7, line 32 skipping to change at page 10, line ?
Legend: S: "Send" (u): "unicast" Legend: S: "Send" (u): "unicast"
------ R: "Receive" (m): "multicast" ------ R: "Receive" (m): "multicast"
Table 1: Application types characterized by I/O relationships Table 1: Application types characterized by I/O relationships
and destination address types (multicast or unicast) and destination address types (multicast or unicast)
Table 1 defines these application types in terms of the I/O Table 1 defines these application types in terms of the I/O
relationships they represent. These categories are defined in terms relationships they represent. These categories are defined in terms
of the combination of communication mechanisms they use. At the IP 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 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 one-to-one (1to1). The Mto1 category, for example, refers to several
several possible combinations of IP-level relationships, including possible combinations of IP-level relationships, including unicast.
unicast. We created the Mto1 category to help differentiate between We created the Mto1 category to help differentiate between the many
the many applications and services that use multicast. applications and services that use multicast.
Quinn and Almeroth Expires September 2001 [Page 7]
1toM: MtoM: Mto1: 1toM: MtoM: Mto1:
R1 S1/R1 S1 R1 S1/R1 S1
/ / | \ \ / / | \ \
S-R2 S2/R2-+-S3/R3 S2-R S-R2 S2/R2-+-S3/R3 S2-R
\... \ | / .../ \... \ | / .../
Rn Sn/Rn Sn Rn Sn/Rn Sn
Legend: S: "Sender" Legend: S: "Sender"
------ R: "Receiver" ------ R: "Receiver"
Figure 1: Generalization of the three application categories Figure 1: Generalization of the three application categories
Figure 1 illustrates the general model for each of the three Figure 1 illustrates the general model for each of the three
multicast application categories. Again it is worth emphasizing multicast application categories. Again it is worth emphasizing that
that Mto1 is an artificial category defined by the application-level Mto1 is an artificial category defined by the application-level
relationship between sender(s) and receiver. At the IP-level, relationship between sender(s) and receiver. At the IP-level,
multicast does not provide an Mto1 I/O mechanism, since it does not multicast does not provide an Mto1 I/O mechanism, since it does not
allow senders to limit receivers, nor even know who they are. allow senders to limit receivers, nor even know who they are.
Receiver information and limitations are enabled at the application Receiver information and limitations are enabled at the application
level, as required by the multicast application. level, as required by the multicast application.
We describe each of these general application types in more detail We describe each of these general application types in more detail
and provide application examples of each in the sub-sections below. and provide application examples of each in the sub-sections below.
The list of examples is not comprehensive, but attempts to define The list of examples is not comprehensive, but attempts to define the
the prominent multicast application and service types in each of the prominent multicast application and service types in each of the
three general categories. We reference the items in these lists in three general categories. We reference the items in these lists in
the remainder of this document as we describe their specific service the remainder of this document as we describe their specific service
requirements, define the challenges they present, and reference requirements, define the challenges they present, and reference
solutions available or under development. solutions available or under development.
3.1 One-to-Many Applications 3.1 One-to-Many Applications
One-to-Many (1toM) applications have a single sender, and multiple One-to-Many (1toM) applications have a single sender, and multiple
simultaneous receivers. Entry B1 in Table 1 represents the classic simultaneous receivers. Entry B1 in Table 1 represents the classic
1toM relationship. Entry B3 differs only slightly, as the sender 1toM relationship. Entry B3 differs only slightly, as the sender
also acts as receiver (i.e. it has loopback enabled). also acts as receiver (i.e. it has loopback enabled).
When people think of multicast, they most often think of broadcast- When people think of multicast, they most often think of broadcast-
based multimedia applications: television (video) and radio (audio). based multimedia applications: television (video) and radio (audio).
This is a reasonable analogy and indeed these are significant This is a reasonable analogy and indeed these are significant
multicast applications, but these are far from the extent of multicast applications, but these are far from the extent of
applications that multicast can enable. Audio/Video distribution applications that multicast can enable. Audio/Video distribution
represents a fraction of the multicast application possibilities, represents a fraction of the multicast application possibilities, and
and most do not have analogs in today's consumer broadcast industry. most do not have analogs in today's consumer broadcast industry.
a) Scheduled audio/video (a/v) distribution: Lectures, a) Scheduled audio/video (a/v) distribution: Lectures,
presentations, meetings, or any other type of scheduled event presentations, meetings, or any other type of scheduled event
whose multimedia coverage could benefit an audience (i.e. whose multimedia coverage could benefit an audience (i.e.
Quinn and Almeroth Expires September 2001 [Page 8]
television and radio "broadcasts"). One or more constant-bit- television and radio "broadcasts"). One or more constant-bit-
rate (CBR) datastreams and relatively high-bandwidth demands rate (CBR) datastreams and relatively high-bandwidth demands
characterize these applications. When more than one datastream characterize these applications. When more than one datastream
is present--as with an audio/video combination--the two are is present--as with an audio/video combination--the two are
synchronized and one typically has a higher priority than the synchronized and one typically has a higher priority than the
other(s). For example, in an a/v combination it is more other(s). For example, in an a/v combination it is more
important to ensure a legible audio stream, than perfect video. important to ensure a legible audio stream, than perfect video.
b) Push media: News headlines, weather updates, sports scores, or b) Push media: News headlines, weather updates, sports scores, or
other types of non-essential dynamic information. "Drip-feed," other types of non-essential dynamic information. "Drip-feed,"
relatively low-bandwidth data characterize these applications. relatively low-bandwidth data characterize these applications.
c) File Distribution and Caching: Web site content, executable c) File Distribution and Caching: Web site content, executable
binaries, and other file-based updates sent to distributed end- binaries, and other file-based updates sent to distributed end-
user or replication/caching sites user or replication/caching sites
d) Announcements: Network time, multicast session schedules, d) Announcements: Network time, multicast session schedules, random
random numbers, keys, configuration updates, (scoped) network numbers, keys, configuration updates, (scoped) network locality
locality beacons, or other types of information that are beacons, or other types of information that are commonly useful.
commonly useful. Their bandwidth demands can vary, but Their bandwidth demands can vary, but generally they are very
generally they are very low bandwidth. low bandwidth.
e) Monitoring: Stock prices, Sensor equipment (seismic activity, e) Monitoring: Stock prices, Sensor equipment (seismic activity,
telemetry, meteorological or oceanic readings), security telemetry, meteorological or oceanic readings), security
systems, manufacturing or other types of real-time information. systems, manufacturing or other types of real-time information.
Bandwidth demands vary with sample frequency and resolution, Bandwidth demands vary with sample frequency and resolution, and
and may be either constant-bit-rate or bursty (if event- may be either constant-bit-rate or bursty (if event-driven).
driven).
3.2 Many-to-Many Applications 3.2 Many-to-Many Applications
In many-to-Many (MtoM) applications two or more of the receivers In many-to-Many (MtoM) applications two or more of the receivers also
also act as senders. In other words, MtoM applications are act as senders. In other words, MtoM applications are characterized
characterized by two-way multicast communications. by two-way multicast communications.
The many-to-many capabilities of IP multicast enable the most unique The many-to-many capabilities of IP multicast enable the most unique
and powerful applications. Each host running an MtoM application and powerful applications. Each host running an MtoM application may
may receive data from multiple senders while it also sends data to receive data from multiple senders while it also sends data to all of
all of them. As a result, many-to-many applications often present them. As a result, many-to-many applications often present complex
complex coordination and management challenges. coordination and management challenges.
f) Multimedia Conferencing: Audio/Video and whiteboard comprise f) Multimedia Conferencing: Audio/Video and whiteboard comprise the
the classic conference application. Having multiple classic conference application. Having multiple datastreams
datastreams with different priorities characterizes this type with different priorities characterizes this type of
of application. Co-ordination issues--such as determining who application. Co-ordination issues--such as determining who gets
gets to talk when--complicate their development and usability. to talk when--complicate their development and usability. There
There are common heuristics and "rules of play", but no are common heuristics and "rules of play", but no standards
standards exist for managing conference group dynamics. exist for managing conference group dynamics.
g) Synchronized Resources: Shared distributed databases of any Quinn and Almeroth Expires September 2001 [Page 9]
type (schedules, directories, as well as traditional g) Synchronized Resources: Shared distributed databases of any type
Information System databases). (schedules, directories, as well as traditional Information
System databases).
h) Concurrent Processing: Distributed parallel processing. h) Concurrent Processing: Distributed parallel processing.
i) Collaboration: Shared document editing. i) Collaboration: Shared document editing.
j) Distance Learning: This is a one-to-many a/v distribution j) Distance Learning: This is a one-to-many a/v distribution
application with "upstream" capability that allows receivers to application with "upstream" capability that allows receivers to
question the speaker(s). question the speaker(s).
k) Chat Groups: These are like text-based conferences, but may k) Chat Groups: These are like text-based conferences, but may also
also provide simulated representations ("avatars") for each provide simulated representations ("avatars") for each "speaker"
"speaker" in simulated environments. in simulated environments.
l) Distributed Interactive Simulations [DIS]: Each object in a l) Distributed Interactive Simulations [DIS]: Each object in a
simulation multicasts descriptive information (e.g. telemetry) simulation multicasts descriptive information (e.g. telemetry)
so all other objects can render the object, and interact as so all other objects can render the object, and interact as
necessary. The bandwidth demands for these can be tremendous, necessary. The bandwidth demands for these can be tremendous,
as the number of objects and the resolution of descriptive as the number of objects and the resolution of descriptive
information increases. information increases.
m) Multi-player Games: Many multi-player games are simply m) Multi-player Games: Many multi-player games are simply
distributed interactive simulations, and may include chat group distributed interactive simulations, and may include chat group
capabilities. Bandwidth usage can vary widely, although capabilities. Bandwidth usage can vary widely, although today's
today's first-generation multi-player games attempt to minimize first-generation multi-player games attempt to minimize
bandwidth usage to increase the target audience (many of whom bandwidth usage to increase the target audience (many of whom
still use dial-up modems). still use dial-up modems).
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
skipping to change at page 10, line 48 skipping to change at page 11, line 22
------> ----------> <---------- ----------> ------> ----------> <---------- ---------->
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
Mto1 applications have many scaling issues. Too many simultaneous Mto1 applications have many scaling issues. Too many simultaneous
senders can potentially overwhelm receiver(s), a condition senders can potentially overwhelm receiver(s), a condition
characterized as an "implosion problem." Another considerable characterized as an "implosion problem." Another considerable
scaling problem is the large amount of state in the network that scaling problem is the large amount of state in the network that
having many multicast senders generates. This is largely having many multicast senders generates. This is largely transparent
transparent to applications and the effect may be diminished in the to applications and the effect may be diminished in the future with
future with the use of bidirectional trees in multicast routing the use of bi-directional trees in multicast routing protocols, but
protocols, but nonetheless it should be considered by application nonetheless it should be considered by application designers.
designers.
No standards yet exist for alternate and equivalent Mto1 application No standards yet exist for alternate and equivalent Mto1 application
designs, but there are a number of possibilities to consider [HNRS]. designs, but there are a number of possibilities to consider [HNRS].
Since the main advantage of using multicast in a Mto1 application is Since the main advantage of using multicast in a Mto1 application is
that senders need not know the receiver(s) unicast address(es), one that senders need not know the receiver(s) unicast address(es), one
alternative is for the each receiver to advertise its unicast alternative is for the each receiver to advertise its unicast address
address via multicast. However, since this strategy still leaves via multicast. However, since this strategy still leaves the
the potential for implosion on each receiver, additional strategies potential for implosion on each receiver, additional strategies may
may be needed to distribute the load. For example, it may be be needed to distribute the load. For example, it may be possible to
possible to increase the number of receivers (in a "flat" receiver increase the number of receivers (in a "flat" receiver topology) or
topology) or establish localized receivers (in a "hierarchical" establish localized receivers (in a "hierarchical" topology) as used
topology) as used in "local recovery" (section 5.3). Such methods in "local recovery" (section 5.3). Such methods have coordination
have coordination issues, and although standard solutions have not issues, and although standard solutions have not yet been identified,
yet been identified, Mto1 application developers should consider Mto1 application developers should consider their alternatives
their alternatives carefully. 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
they can satisfy the request. The responses might also contain 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
illustrated in Figure 2 by possibility number 3. Alternately, illustrated in Figure 2 by possibility number 3. Alternately,
the response could be to a multicast rather than unicast the response could be to a multicast rather than unicast
address, although technically that would make it an MtoM address, although technically that would make it an MtoM
application type (this is how the . Service Location Protocol application type (this is how the Service Location Protocol
[SLP] operates, when a user agent attempts to locate a [SLP] operates, when a user agent attempts to locate a directory
directory agent). agent).
p) Data Collection: This is the converse of a one-to-many p) Data Collection: This is the converse of a one-to-many
"monitoring" application described earlier. In this case there "monitoring" application described earlier. In this case there
may be any number of distributed "sensors" that send data to a may be any number of distributed "sensors" that send data to a
data collection host. The sensors might send updates in data collection host. The sensors might send updates in
response to a request from the data collector, or send response to a request from the data collector, or send
continuously at regular intervals, or send spontaneously when a continuously at regular intervals, or send spontaneously when a
pre-defined event occurs. Bandwidth demands can vary based on pre-defined event occurs. Bandwidth demands can vary based on
sample frequency and resolution. sample frequency and resolution.
This is illustrated in Table 1 by entries A1 and A3, the only This is illustrated in Table 1 by entries A1 and A3, the only
difference being that A3 has a loopback interface. In Figure difference being that A3 has a loopback interface. In Figure 2,
2, this is possibility number 1. Since the number of receivers this is possibility number 1. Since the number of receivers can
can easily be more than one, this is really an MtoM easily be more than one, this is really an MtoM application.
application.
q) Auctions: The "auctioneer" starts the bidding by describing q) Auctions: The "auctioneer" starts the bidding by describing
whatever it is for sale (product or service or whatever), and whatever it is for sale (product or service or whatever), and
receivers send their bids privately or publicly (i.e. to a receivers send their bids privately or publicly (i.e. to a
unicast or multicast address). unicast or multicast address).
This is possibility number 2 in Figure 2, and D5 in Table 1. This is possibility number 2 in Figure 2, and D5 in Table 1.
The response could be sent to a multicast address, although The response could be sent to a multicast address, although
technically that would make it an MtoM application. technically that would make it an MtoM application.
r) Polling: The "pollster" sends out a question, and the "pollees" r) Polling: The "pollster" sends out a question, and the "pollees"
respond with answers. This is possibility number 2 in Figure respond with answers. This is possibility number 2 in Figure 2,
2, and could also be characterized as an MtoM application if and could also be characterized as an MtoM application if the
the response is to a multicast address. response is to a multicast address.
s) Juke Box: Allows near-on-demand a/v playback. Receivers use an s) Juke Box: Allows near-on-demand a/v playback. Receivers use an
"out-of-band" protocol mechanism (via web, email, unicast or "out-of-band" protocol mechanism (via web, email, unicast or
multicast requests, etc.) to send their playback request into a multicast requests, etc.) to send their playback request into a
scheduling queue [IMJ]. scheduling queue [IMJ].
This is characterized by possibility number 4 in Figure 2, and This is characterized by possibility number 4 in Figure 2, and
entry D4 in Table 1. The initial unicast request is the only entry D4 in Table 1. The initial unicast request is the only
difference between this type of application and a typical 1toM. difference between this type of application and a typical 1toM.
If that initial request were sent to a multicast address, this If that initial request were sent to a multicast address, this
would effectively be an MtoM application. would effectively be an MtoM application.
t) Accounting: This is basically data collection but is worth t) Accounting: This is basically data collection but is worth
separating since it is such an important application. In some separating since it is such an important application. In some
multicast applications it is imperative to know information multicast applications it is imperative to know information
about each receiver, possibly in real-time. But such about each receiver, possibly in real-time. But such information
information can be overwhelming. Current mechanisms, like RTCP can be overwhelming[MRM]. Current mechanisms, like RTCP (which
(which is actually MtoM since it is multicast but could be made is actually MtoM since it is multicast but could be made Mto1),
Mto1), use scaling techniques but trade-off information use scaling techniques but trade-off information granularity. As
granularity. As a group grows the total amount of feedback is a group grows the total amount of feedback is constant but each
constant but each receiver sends less. 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
unicast network applications as well. We characterize two of them network applications as well. We characterize two of them here--
here--bandwidth and delay requirements. bandwidth and delay requirements.
4.1 Bandwidth Requirements 4.1 Bandwidth Requirements
Figure 3 shows multicast applications approximate bandwidth Figure 3 shows multicast applications approximate bandwidth
requirements. requirements.
Unicast and multicast applications both need to design applications Unicast and multicast applications both need to design applications
to adapt to the variability of network conditions. But as we to adapt to the variability of network conditions. But as we
describe in section 4.1, it is the need to accommodate multiple describe in section 4.1, it is the need to accommodate multiple
heterogeneous multicast receivers--with their diversity of bandwidth heterogeneous multicast receivers--with their diversity of bandwidth
skipping to change at page 13, line 20 skipping to change at page 13, line 48
Mto1 | o, q, r p, q, t 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
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
have a high tolerance for delay and delay variance (jitter). a high tolerance for delay and delay variance (jitter). Constant bit-
Constant bit-rate (CBR) data--such as streaming media (audio/video)- rate (CBR) data--such as streaming media (audio/video)--are sensitive
-are sensitive to jitter, but applications commonly counteract the to jitter, but applications commonly counteract the effects by
effects by buffering data and delaying playback. 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,
minimized, since they can adversely affect the application's 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 4, 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, t 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
only "best effort" delivery, so data are subject to variable router "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 [E2EQOS]. enable end-to-end QoS support in the Internet are underway [E2EQOS].
However, QoS support is an IP network infrastructure consideration. However, QoS support is an IP network infrastructure consideration.
Although there are multicast-specific challenges for implementing Although there are multicast-specific challenges for implementing QoS
QoS in the network for multicast flows, they are beyond the control in the network for multicast flows, they are beyond the control of
of applications, so further discussion of the QoS protocols and applications, so further discussion of the QoS protocols and services
services is beyond the scope of this document. 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
requirements, similar to unicast applications. requirements, similar to unicast applications.
Multicast applications can be further differentiated from unicast Multicast applications can be further differentiated from unicast
applications and from each other by the services they require. In applications and from each other by the services they require. In
this section we provide a survey of the various services that have this section we provide a survey of the various services that have
unique requirements for multicast applications. unique requirements for multicast applications.
+------------------------------------------------------+ +--------------------------------------------------------------+
| Multicast Application | | Multicast Application |
+--------------------------------------+ +-----------+ +--------------------------------------+ +-------------------+
+-------------------------------------+| |+----++----+ +-------------------------------------+| |+--------++--------+
| Multicast Security || || || | | Multicast Security || || || |
+----------------------+ +----------+| ||Sys-||Co- | +----------------------+ +----------+| || System || |
+----------++---------+| |+---------+| ||tem ||decs| +----------++---------+| |+---------+| || Time || Codecs |
| Reliable || Address || || Session || ||Time|| | | Reliable || Address || || Session || || || |
| Delivery || Mgmnt. || || Mgmnt. || || || | | Delivery || Mgt || || Mgt || || || |
+----------++---------++---++---------++---++----++----+ +----------++---------++---++---------++---++--------++--------+
+----------------------------------------++------------+ +----------------------------------------++--------------------+
| Basic IP Multicast Service || IP Unicast | | Basic IP Multicast Service || IP Unicast |
| (e.g. UDP and IGMPv2) || Service | | (e.g. UDP and IGMPv2/v3) || Service |
+----------------------------------------++------------+ +----------------------------------------++--------------------+
Figure 5: Multicast service requirements summary Figure 5: Multicast service requirements summary
Here's the list of multicast application service requirements: Here's the list of multicast application service requirements:
Address Management - Coordinated address allocation service that Address Management ű Selection and coordinated of address
provides some assurances against "address collisions". allocation. The need is provide assurances against ˘address
collision÷ and provide address ownership.
Session Management - Making session descriptions available (via Session Management ű Perform application-layer services on top of
advertisements and explicit queries) within appropriate scopes, multicast transport. These services depend heavily on the
and also enabling registration of new sessions application but include functions like session advertisement,
billing, group member monitoring, key distribution, etc.
Heterogeneous Receiver Support - Sending to receivers with a wide Heterogeneous Receiver Support - Sending to receivers with a wide
variety of bandwidth capacities, latency characteristics, and variety of bandwidth capacities, latency characteristics, and
network congestion requires feedback to monitor receiver network congestion requires feedback to monitor receiver
performance. performance.
Reliable Data Delivery - Ensuring that all data sent is received Reliable Data Delivery - Ensuring that all data sent is received by
by all receivers all receivers.
Security - Ensuring content privacy among dynamic multicast group Security - Ensuring content privacy among dynamic multicast group
memberships, and limiting senders memberships, and limiting senders.
Synchronized Play-Out - Allow multiple receivers to "replay" data Synchronized Play-Out - Allow multiple receivers to "replay" data
received in synchronized fashion received in synchronized fashion.
In the remainder of this section, we describe each of these In the remainder of this section, we describe each of these
application services in more detail, the challenges they present, application services in more detail, the challenges they present, and
and the status of standardized solutions. the status of standardized solutions.
5.1 Address Management 5.1 Address Management
One of the first questions facing a multicast application developer One of the first questions facing a multicast application developer
is what multicast address to use. Multicast addresses are not is what multicast address to use. Multicast addresses are not
assigned to individual hosts, assignments can change dynamically, assigned to individual hosts, assignments can change dynamically, and
and addresses sometimes have semantics of their own (e.g addresses sometimes have semantics of their own (e.g. Admin Scoping).
Administrative Scoping). Multicast applications require an address Multicast applications require an address management service that
management service that provides address allocation or assignment provides address allocation or assignment queries. There are a
queries: number of ways for applications to learn about multicast addresses:
There are a number of ways for applications to learn about multicast
addresses:
Hard-Coded: Software configuration, encoded in a binary Hard-Coded: Software configuration, encoded in a binary executable,
executable, or burned into ROM in embedded devices. These or burned into ROM in embedded devices. These applications
applications typically reference IANA statically allocated typically reference IANA statically allocated multicast
multicast addresses (including relative addresses). 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 allocate
allocate a statistically random (unused) address. 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, t 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.1.1 Scope Discovery In almost all cases, application designers should assume that
multicast addresses are to be dynamic. Very little of the multicast
Scope Discovery is a function of address management required by some address space is available for static assignment by IANA [MADDR].
applications. An option for [MADCAP] allows clients to learn which Also, given the host-specific addressing available with SSM, Internet-
scopes nest inside each other, for the purpose of executing wide, static address assignment is expected to be very rare.
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 Session management is one of the most misunderstood services with
directory services that can be used to co-ordinate application respect to multicast. Most application developers assume that
schedules and resources, and describe session attributes. These map multicast will provide services like security, encryption,
multicast address and port combinations to a date and time, content reliability, session advertisement, monitoring, billing, etc. In
description, and other session attributes (e.g. bandwidth and delay fact, multicast is simply a transport mechanism that provides end-to-
requirements, encoding, security and authorization methods, etc.). 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.
The session description protocol [SDP] is designed for this purpose, While there are no generic solutions which provide all session
but it does not provide the transport for dissemination of these management functions, there are some protocols and common techniques
session descriptions, nor does it enable the address allocation and that provide support for some of the functions. Techniques for
management. SDP only provides the syntax for describing session 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. attributes.
SDP session descriptions may be conveyed publicly or privately by SDP session descriptions may be conveyed publicly or privately by
means of any number of transports including web (HTTP) and MIME means of any number of transports including web (HTTP) and MIME
encoded email. The session announcement protocol [SAP] is the de encoded email. The session announcement protocol [SAP] is the de
facto standard transport and many multicast-enabled applications facto standard transport and many multicast-enabled applications
currently use it. SAP limits distribution via multicast scoping, currently use it. SAP limits distribution via multicast scoping, but
but the current protocol definition has scaling issues that need to the current protocol definition has scaling issues that need to be
be addressed. Specifically, the initialization latency for a addressed. Specifically, the initialization latency for a session
session directory can be quite long, and it increases in proportion directory can be quite long, and it increases in proportion to the
to the number of session announcements. This is to an extent a number of session announcements. This is to an extent a multicast
multicast infrastructure issue, however, as this level of protocol infrastructure issue, however, as this level of protocol detail
detail should be transparent to applications. should be transparent to applications.
The session management service needs to: The session management service needs to:
- Advertise scheduled sessions - Advertise scheduled sessions
- Provide a query mechanism for retrieving information about - Provide a query mechanism for retrieving information about
session schedules session schedules
5.3 Heterogeneous Receiver Support 5.3 Heterogeneous Receiver Support
The Internet is a network of networks. IP's strength is its ability The Internet is a network of networks. IP's strength is its ability
to enable seamless interoperability between hosts on disparate to enable seamless interoperability between hosts on disparate
network media, the heterogeneous network. network media, the heterogeneous network.
When two hosts communicate via unicast--one-to-one--across an IP When two hosts communicate via unicast--one-to-one--across an IP
network, it is relatively easy for senders to adapt to varying network, it is relatively easy for senders to adapt to varying
network conditions. The Transmission Control Protocol (TCP) network conditions. The Transmission Control Protocol (TCP) provides
provides reliable data transport, and is the model of "network reliable data transport, and is the model of "network friendly"
friendly" adaptability. adaptability.
TCP receivers send acknowledgements back to the sender for data TCP receivers send acknowledgements back to the sender for data
delivered. A TCP sender detects data loss from the data sent that delivered. A TCP sender detects data loss from the data sent that is
is not acknowledged. When it detects data loss, TCP infers that not acknowledged. When it detects data loss, TCP infers that there
there is network congestion or a low-bandwidth link, and adapts by is network congestion or a low-bandwidth link, and adapts by
throttling down its send rate [SlowStart]. throttling down its send rate [SlowStart].
User Datagram Protocol (UDP) does not enable a receiver feedback User Datagram Protocol (UDP) does not enable a receiver feedback loop
loop the way TCP does, since UDP does not provide reliable data the way TCP does, since UDP does not provide reliable data delivery
delivery service. As a result, it also does not have a loss service. As a result, it also does not have a loss detection and
detection and adaptive congestion control mechanism as TCP does. adaptive congestion control mechanism as TCP does. However, it is
However, it is possible for a unicast UDP application to enable possible for a unicast UDP application to enable similar adaptive
similar adaptive algorithms to achieve the same result, or even algorithms to achieve the same result, or even improve on it.
improve on it.
A unicast UDP application that uses a feedback mechanism to detect 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 data loss and adapt the send rate, can do so better than TCP. TCP
automatically reduces the "congestion window" when data loss is automatically reduces the "congestion window" when data loss is
detected, although the updated send rate may be slower than a CBR detected, although the updated send rate may be slower than a CBR
audio/video stream requires. When a UDP application detects loss, audio/video stream requires. When a UDP application detects loss, it
it can adapt the data itself to accommodate the lower send rate. can adapt the data itself to accommodate the lower send rate. For
For example, a UDP application can: example, a UDP application can:
- Reduce the data resolution (e.g. send lower fidelity - Reduce the data resolution (e.g. send lower fidelity audio/video
audio/video by reducing sample frequency or frame rate) to by reducing sample frequency or frame rate) to reduce data rate.
reduce data rate.
- Modify the data encoding to add redundant data (e.g. forward - Modify the data encoding to add redundant data (e.g. forward
error correction) offset in time to avoid fate sharing. This error correction) offset in time to avoid fate sharing. This
could also be "layered", so a percentage of data loss will could also be "layered", so a percentage of data loss will
simply reduce fidelity rather than corrupt the data. simply reduce fidelity rather than corrupt the data.
- Reduce the send rate of one datastream in order to favor - Reduce the send rate of one datastream in order to favor another
another of higher priority (e.g. sacrifice video in order to of higher priority (e.g. sacrifice video in order to ensure
ensure audio delivery). audio delivery).
- Send data at a lower rate (i.e. with a different encoding) on a - Send data at a lower rate (i.e. with a different encoding) on a
separate multicast address and/or port number for high-loss separate multicast address and/or port number for high-loss
receivers. receivers.
However, with multicast applications--one-to-many or many-to-many-- However, with multicast applications--one-to-many or many-to-many--
which have multiple receivers, the feedback loop design needs which have multiple receivers, the feedback loop design needs
modification. If all receivers return data loss reports modification. If all receivers return data loss reports
simultaneously, the sender is easily overwhelmed in the storm of simultaneously, the sender is easily overwhelmed in the storm of
replies. This is known as the "implosion problem." replies. This is known as the "implosion problem."
Another problem is that heterogeneous receiver capabilities can vary Another problem is that heterogeneous receiver capabilities can vary
widely due to the wide range of (static) network media bandwidth widely due to the wide range of (static) network media bandwidth
capabilities and dynamically due to transient traffic conditions. capabilities and dynamically due to transient traffic conditions. If
If a sender adapts its send rate and data resolution based on the a sender adapts its send rate and data resolution based on the loss
loss rate of its worst receiver(s), then it can only service the rate of its worst receiver(s), then it can only service the lowest
lowest common denominator. Hence, a single "crying baby" can spoil common denominator. Hence, a single "crying baby" can spoil it for
it for all other receivers. all other receivers.
Strategies exist for dealing with these heterogeneous receiver Strategies exist for dealing with these heterogeneous receiver
problems. Here are two examples: problems. Here are two examples:
Shared Learning - When loss is detected (i.e. a sequenced packet Shared Learning - When loss is detected (i.e. a sequenced packet
isn't received), a receiver starts a random timer. If it isn't received), a receiver starts a random timer. If it
receives a data loss report sent by another receiver as it receives a data loss report sent by another receiver as it waits
waits for the timer to expire, it stops the timer and does not for the timer to expire, it stops the timer and does not send a
send a report. Otherwise, it sends a report when the timer report. Otherwise, it sends a report when the timer expires.
expires. The Real-Time Protocol and its feedback-loop The Real-Time Protocol and its feedback-loop counterpart Real-
counterpart Real-Time Control Protocol [RTP/RTCP] employ a Time Control Protocol [RTP/RTCP] employ a strategy similar to
strategy similar to this to keep feedback traffic to 5 percent this to keep feedback traffic to 5 percent or less than the
or less than the overall session traffic. This technique was overall session traffic. This technique was originally utilized
originally utilized in IGMP. in IGMP.
Local Recovery - Some receivers may be designated as local Local Recovery - Some receivers may be designated as local
distribution points or "transcoders" that either re-send data distribution points or "transcoders" that either re-send data
locally (possibly via unicast) when loss is reported or they locally (possibly via unicast) when loss is reported or they re-
re-encode the data for lower bandwidth receivers before re- encode the data for lower bandwidth receivers before re-sending.
sending. No standards exist for these strategies, although No standards exist for these strategies, although "local
"local recovery" is used by several reliable multicast recovery" is used by several reliable multicast protocols.
protocols.
Adaptive multicast application design for heterogeneous receivers is Adaptive multicast application design for heterogeneous receivers is
still an active area of research. The fundamental requirements are still an active area of research. The fundamental requirements are
to maximize application usability, while accommodating network to maximize application usability, while accommodating network
conditions in a "network friendly" manner. In other words, conditions in a "network friendly" manner. In other words,
congestion detection and avoidance are (at least) as important in congestion detection and avoidance are (at least) as important in
protocol design as the user experience. The adaptive mechanisms protocol design as the user experience. The adaptive mechanisms must
must also be stable, so they do not adapt too quickly--changing also be stable, so they do not adapt too quickly--changing encoding
encoding and rates based on too little information about what may be and rates based on too little information about what may be a
a transient condition--to avoid oscillation. 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. See [HNRS] for a taxonomy of strategies for providing party. See [HNRS] for a taxonomy of strategies for providing
feedback for multicast, with the ultimate goal of developing a feedback for multicast, with the ultimate goal of developing a common
common multicast feedback protocol. 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
fidelity but will remain legible despite some data loss. 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 7 shows a list of applications with Intolerant" column in Figure 7 shows a list of applications with this
this requirement, while the others can tolerate varying levels of requirement, while the others can tolerate varying levels of data
data loss. The tolerance levels are typically determined by the loss. The tolerance levels are typically determined by the nature of
nature of the data and the encoding in use. 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, t 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 by
by using negative acknowledgements (NAKs) from receivers to indicate using negative acknowledgements (NAKs) from receivers to indicate
what was lost. They also use "shared learning" whereby receivers what was lost. They also use "shared learning" whereby receivers
listen to others' NAKs and then listen for the resulting listen to others' NAKs and then listen for the resulting
retransmission of data, rather than requesting retransmission by retransmission of data, rather than requesting retransmission by
sending a NAK themselves. sending a NAK themselves.
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. The IETF Relialbe transport requirements, and protocol mechanisms.
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
need for "network friendly" protocols that detect and avoid for "network friendly" protocols that detect and avoid congestion as
congestion as they provide reliable delivery. Other considerations they provide reliable delivery. Other considerations are protocol
are protocol robustness, support for "late joins", group management robustness, support for "late joins", group management and security
and security (which we discuss next). (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.
As a result, most believe that we will eventually standardize a As a result, most believe that we will eventually standardize a
number of reliable multicast protocols, rather than a single one. number of reliable multicast protocols, rather than a single
one[BULK].
5.5 Security 5.5 Security
For any IP network application--unicast or multicast--security is For any IP network application--unicast or multicast--security is
necessary because networks comprise users with different levels of necessary because networks comprise users with different levels of
trust. trust.
Network application security is challenging, even for unicast. And Network application security is challenging, even for unicast. And
as the need for security increases--gauged by the risks of being as the need for security increases--gauged by the risks of being
without it--the challenges increase also. Security system without it--the challenges increase also. Security system complexity
complexity and overhead is commensurate with the protection it and overhead is commensurate with the protection it provides. "No one
provides. "No one can guarantee 100% security. But we can work can guarantee 100% security. But we can work toward 100% risk
toward 100% risk acceptance ...Strong cryptography can withstand acceptance ...Strong cryptography can withstand targeted attacks up
targeted attacks up to a point--the point at which it becomes easier to a point--the point at which it becomes easier to get the
to get the information some other way ...A good design starts with a information some other way ...A good design starts with a threat
threat model: what the system is designed to protect, from whom, and model: what the system is designed to protect, from whom, and for how
for how long." [Schneier] long." [Schneier]
Multicast applications are no different than unicast applications Multicast applications are no different than unicast applications
with respect to their need for security, and they require the same with respect to their need for security, and they require the same
basic security services: user authentication, data integrity, data basic security services: user authentication, data integrity, data
privacy and user privacy (anonymity). However, enabling security privacy and user privacy (anonymity). However, enabling security for
for multicast applications is even more of a challenge than for multicast applications is even more of a challenge than for unicast.
unicast. Having multiple receivers makes a difference, as does Having multiple receivers makes a difference, as does their
their heterogeneity and the dynamic nature of multicast group heterogeneity and the dynamic nature of multicast group memberships.
memberships.
Multicast security requirements can include any combination of the Multicast security requirements can include any combination of the
following services: following services:
Limiting Senders - Controlling who can send to group addresses Limiting Senders - Controlling who can send to group addresses
Limiting Receivers - Controlling who can receive Limiting Receivers - Controlling who can receive
Limiting Access - Controlling who can "read" multicast content Limiting Access - Controlling who can "read" multicast content
either by encrypting content or limiting receivers (which isn't either by encrypting content or limiting receivers (which isn't
skipping to change at page 21, line 35 skipping to change at page 22, line 24
authenticated sender and was not altered en route authenticated sender and was not altered en route
Protecting Receiver Privacy - Controlling whether sender(s) or Protecting Receiver Privacy - Controlling whether sender(s) or
other receivers know receiver identity other receivers know receiver identity
Firewall Traversal - Proxying outgoing "join" requests through Firewall Traversal - Proxying outgoing "join" requests through
firewalls, allowing incoming or outgoing traffic through, and firewalls, allowing incoming or outgoing traffic through, and
(possibly) authenticating receivers for filtering purposes and (possibly) authenticating receivers for filtering purposes and
security [Chouinard, Finlayson]. security [Chouinard, Finlayson].
This list is not comprehensive, but includes the most commonly This list is not comprehensive, but includes the most commonly needed
needed security services. Different multicast applications and security services. Different multicast applications and different
different application contexts can have very different needs with application contexts can have very different needs with respect to
respect to these services, and others. "Two main issues emerge, these services, and others. "Two main issues emerge, where the
where the performance of current solutions leaves much to be performance of current solutions leaves much to be desired"
desired" [Canetti]: [Canetti]:
Individual authentication - how is sender identity verified for Individual authentication - how is sender identity verified for
each multicast datagram received? each multicast datagram received?
Membership revocation - how is further group access disabled for Membership revocation - how is further group access disabled for
group members that leave the group (e.g. encryption keys in group members that leave the group (e.g. encryption keys in
their possession disabled)? their possession disabled)?
Performance is largely a factor when a user joins or leaves a group. Performance is largely a factor when a user joins or leaves a group.
For example, methods used to authenticate potential group members For example, methods used to authenticate potential group members
skipping to change at page 22, line 12 skipping to change at page 22, line 51
involve significant processing and protocol overhead and result in involve significant processing and protocol overhead and result in
significant delays that affect usability. significant delays that affect usability.
Like reliable multicast, secure multicast is also still under Like reliable multicast, secure multicast is also still under
investigation in the Internet Research Task Force [IRTF]. Protocol investigation in the Internet Research Task Force [IRTF]. Protocol
mechanisms for many of the most important of these services--such as mechanisms for many of the most important of these services--such as
limiting senders--have not yet been defined, let alone developed and limiting senders--have not yet been defined, let alone developed and
deployed. deployed.
As is true for reliable multicast, the current consensus is that no As is true for reliable multicast, the current consensus is that no
single security protocol will satisfy the wide diversity of single security protocol will satisfy the wide diversity of sometimes-
sometimes-contradictory requirements among multicast applications. contradictory requirements among multicast applications. Hence,
Hence, multicast security will also likely require a number of multicast security will also likely require a number of different
different protocols. protocols.
5.6 Synchronized Play-Out 5.6 Synchronized Play-Out
This refers to having all receivers simultaneously play-out the This refers to having all receivers simultaneously play-out the
multicast data they received. This may be necessary for fairness-- multicast data they received. This may be necessary for fairness--
playing-out prices for auctions, or stock-prices--or to ensure playing-out prices for auctions, or stock-prices--or to ensure
synchronization with other receivers, such as when playing music. synchronization with other receivers, such as when playing music.
Here is an analogy to illustrate: Imagine a multi-speaker stereo Here is an analogy to illustrate: Imagine a multi-speaker stereo
system that is wired throughout a home (via analog). With the system that is wired throughout a home (via analog). With the stereo
stereo playing on all speaker sets, you will hear continuous music playing on all speaker sets, you will hear continuous music as you
as you walk from room-to-room. walk from room-to-room.
Now imagine a house full of multi-media and network enabled computer Now imagine a house full of multi-media and network enabled computer
systems. Although they will all receive the same music datastream systems. Although they will all receive the same music datastream
simultaneously via multicast, they will provide discontinuous music simultaneously via multicast, they will provide discontinuous music
playback as you walk room-to-room. playback as you walk room-to-room.
To provide synchronized playback that would enable continuous music To provide synchronized playback that would enable continuous music
from room-to-room would require three things: from room-to-room would require three things:
1) system clocks on all systems should be synchronized 1) system clocks on all systems should be synchronized
skipping to change at page 23, line 25 skipping to change at page 24, line 13
box for each service effectively represents its API. box for each service effectively represents its API.
Network APIs generally reflect the protocols they support. Their Network APIs generally reflect the protocols they support. Their
functionality and argument values are a (varying) subset of protocol functionality and argument values are a (varying) subset of protocol
message types, header fields and values. Although some protocol message types, header fields and values. Although some protocol
details and actions may not be exposed in APIs--since many protocol details and actions may not be exposed in APIs--since many protocol
mechanics need not be exposed--others are crucial to efficient and mechanics need not be exposed--others are crucial to efficient and
flexible application operation. flexible application operation.
A more complete examination of the application services described in A more complete examination of the application services described in
this document might also identify the protocol features that could this document might also identify the protocol features that could be
be mapped to define a (generic) API definition for that service. mapped to define a (generic) API definition for that service. APIs
APIs are often controversial, however. Not only are there many are often controversial, however. Not only are there many language
language differences, but it is also possible to create different differences, but it is also possible to create different APIs by
APIs by exposing different levels of detail in trade-offs between exposing different levels of detail in trade-offs between flexibility
flexibility and simplicity. 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: Ran Canetti, Brian Haberman, individuals for their helpful feedback: Ran Canetti, 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
[BeauW] B. Williamson, ˘Developing IP Multicast Networks,
Volume I÷, (c) 2000 Cisco Press, Indianapolis IN,
ISBN 1-57870-077-9
[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
[BULK] B. Whetten, L. Vicisano, R. Kermode, M. Handley,
S. Floyd, M. Luby, ˘Reliable Multicast Transport Building
Blocks for One-to-Many Bulk-Data Transfer÷, <draft-ietf-
rmt-buildingblocks-02.txt>, September 2000, Work in
Progress
[Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security
issues", <draft-irtf-smug-taxonomy-00.txt>, April 1999, issues", <draft-irtf-smug-taxonomy-00.txt>, April 1999,
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>, November 1997, Work in aft-mcast-fw-traversal-01.txt>, November 1997, Work in
Progress Progress
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, [Deering] S. Deering, ˘Host Extensions for {IP} Multicasting÷, RFC
M. Speer, R. Braden, B. Davie, "Integrated Services 1112, August 1989
Operation over Diffserv Networks", <draft-ietf-issll-
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
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang,
M. Speer, R. Braden, B. Davie, "Integrated Services
Operation over Diffserv Networks", <draft-ietf-issll-
diffserv-rsvp-02.txt>, June 1999, Work in Progress
[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", RFC 2588, [Finlayson] R. Finlayson, "IP Multicast and Firewalls", RFC 2588,
May 1999 May 1999
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy [HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
of Feedback for Multicast", June 1999, Work in Progress 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
[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan,
˘Internet Group Management Protocol, Version 3÷,
<draft-ietf-idmr-igmp-v3-03.txt>, March 2000, Work
in Progress
[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 [Kermode] R. Kermode, "MADCAP Multicast Scope Nesting State
Option", February 1999, <draft-kermode-madcap-nest-opt- Option", February 1999, <draft-kermode-madcap-nest-opt-
00.txt>, Work in Progress 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-03.txt>, Applications," <draft-ietf-lsma-requirements-03.txt>,
May 1999, Work in Progress May 1999, Work in Progress
[MADDR] Z. Albanna, K. Almeroth, D. Meyer, ˘IANA Guidelines for
IPv4 Multicast Address Allocation÷, <draft-albanna-iana-
IPv4-mcast-guidelines-00.txt>, 2001, 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, "Deploying IP Multicast in the Enterprise", [Maufer] 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
skipping to change at page 25, line 24 skipping to change at page 26, line 30
[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
[MRM] K. Almeroth, L. Wei, D. Farinacci, ˘Multicast
Reachability Monitor (MRM), <draft-ietf-mboned-mrm-
00.txt>, April 1999, Work in Progress
[MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone [MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone
Announcement Protocol (MZAP) ", <draft-ietf-mboned-mzap- Announcement Protocol (MZAP) ", <draft-ietf-mboned-mzap-
03.txt>, Feb 1999, Work in Progress 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 [Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
workshop, June 1998, UCL London workshop, June 1998, UCL London
http://www.iet.unipi.it/~luigi/hipparc98.ps.gz 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
[SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol [SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol
(SADP) ", <draft-ietf-mboned-sadp-01.txt>, Jan 1999, Work (SADP) ", <draft-ietf-mboned-sadp-01.txt>, Jan 1999, Work
in Progress in Progress
skipping to change at page 26, line 30 skipping to change at page 27, line 28
[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
[SSM] H. Holbrook, B. Cain, ˘Specific Multicast for IP÷, <draft-
holbrook-ssm-arch-01.txt>, Nov 2000, Work in Progress
10. Authors' Addresses 10. Authors' Addresses
Bob Quinn Bob Quinn
IP Multicast Initiative (IPMI) Celox Networks
Stardust Forums, Inc. 2 Park Central Drive
1901 S. Bascom Ave. #333 Southborough, MA 01772
Campbell, CA 95008
+1 408 879 8080 +1 508 305 7000
rcq@ipmulticast.com bquinn@celoxnetworks.com
Kevin Almeroth Kevin Almeroth
Department of Computer Science Department of Computer Science
Office: 2113, Engineering I
University of California University of California
Santa Barbara, CA 93106-5110 Santa Barbara, CA 93106-5110
+1 805 893 2777 +1 805 893 2777
almeroth@cs.ucsb.edu almeroth@cs.ucsb.edu
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished to
toothers, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain it
it orassist in its implmentation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
anddistributed, in whole or in part, without restriction of any anddistributed, in whole or in part, without restriction of any
kind,provided that the above copyright notice and this paragraph are kind,provided that the above copyright notice and this paragraph are
includedon all such copies and derivative works. However, this includedon all such copies and derivative works. However, this
document itselfmay not be modified in any way, such as by removing document itselfmay not be modified in any way, such as by removing
the copyright noticeor references to the Internet Society or other the copyright noticeor references to the Internet Society or other
Internet organizations,except as needed for the purpose of Internet organizations,except as needed for the purpose of
developing Internet standards inwhich case the procedures for developing Internet standards inwhich case the procedures for
copyrights defined in the Internetlanguages other than English. copyrights defined in the Internetlanguages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
 End of changes. 

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