draft-ietf-mboned-mcast-apps-02.txt   rfc3170.txt 
MBoneD Working Group Bob Quinn Network Working Group B. Quinn
Internet Engineering Task Force Celox Networks Request for Comments: 3170 Celox Networks
INTERNET-DRAFT Kevin Almeroth Category: Informational K. Almeroth
March 2001 UC-Santa Barbara UC-Santa Barbara
Expires September 2001 September 2001
IP Multicast Applications:
Challenges and Solutions
<draft-ietf-mboned-mcast-apps-02.txt> IP Multicast Applications:
Challenges and Solutions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
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 for implementing multicast applications. It is an introductory guide for
application developers that highlights the unique considerations of application developers that highlights the unique considerations 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 support. application I/O models and examples of the services they can support.
It then describes the service requirements of these multicast It then describes the service requirements of these multicast
applications, and the recent and ongoing efforts to build protocol applications, and the recent and ongoing efforts to build protocol
solutions to support these services. solutions to support these services.
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 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4 2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4 2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
2.1 Essential Protocol Components. . . . . . . . . . . . . . 5 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
2.1.2 Send without a Join. . . . . . . . . . . . . . . . . 6 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6 4. Common Multicast Service Requirements . . . . . . . . . . . . .13
3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13
3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10 5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
4. Common Multicast Service Requirements . . . . . . . . . . . 13 5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 13 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
5. Unique Multicast Service Requirements . . . . . . . . . . . 14 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
5.1 Address Management . . . . . . . . . . . . . . . . . . . 16 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
5.2 Session Management . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 18 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 20 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 23 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .28
6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 24
9. References. . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 28
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 coming IP Multicast will play a prominent role on the Internet in the coming
years. It is a requirement, not an option, if the Internet is going years. It is a requirement, not an option, if the Internet is going
to scale. Multicast allows application developers "to add more to scale. Multicast allows application developers to add more
functionality without significantly impacting the network" functionality without significantly impacting the network.
[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 a value) to allow outgoing datagrams to traverse routers. To receive a
multicast datagram, applications join the multicast group, which multicast datagram, applications join the multicast group, which
transparently generates an [IGMPv2, IGMPv3] 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. Such need to be aware of efforts underway to provide these services. Such
efforts range in maturity from deployed commercial products to basic efforts range in maturity from deployed commercial products to basic
research efforts to evaluate feasibility. research efforts to evaluate feasibility.
Multicast-based applications and services will play an important role Multicast-based applications and services will play an important 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 [BeauW, Maufer, Miller]. Since this is an introductory documents [BeauW, Maufer, Miller]. Since this is an
introductory survey rather than a comprehensive examination, we refer introductory survey rather than a comprehensive examination, we refer
readers to other multicast application requirements descriptions [RM, readers to other multicast application requirements descriptions [RM,
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 survey requirements, the challenges they present, and provide a brief survey
of the solutions available or under development. We wrap up with a of the solutions available or under development. We wrap up with a
discussion of application programming interfaces (APIs) for multicast discussion of application programming interfaces (APIs) for multicast
services. services.
2. IP Multicast Enabled Network 2. IP Multicast Enabled Network
skipping to change at page 10, line ? skipping to change at page 4, line 14
There are two kinds of multicast-enabled networks available. The There are two kinds of multicast-enabled networks available. The
first is based on the original multicast service model as defined in first is based on the original multicast service model as defined in
RFC 1112 [Deering]. In this model, a receiver simply joins the group 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 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 is known by a number of names including Internet Standard Multicast
(ISM), Internet Traditional Multicast (ITM), Deering multicast, etc. (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc.
The second kind of multicast modifies the original service model such The second kind of multicast modifies the original service model such
that in addition to knowing the group address, a receiver must know that in addition to knowing the group address, a receiver must know
the set of relevant sources. This type of multicast is called Source the set of relevant sources. This type of multicast is called Source
Specific Multicast (SSM) [SSM]. It becomes the applications Specific Multicast (SSM) [SSM]. It becomes the application's
responsibility of knowing what kind of multicast capability the responsibility to know what kind of multicast capability the network
network provides. Currently, the only way for an application to know provides. Currently, the only way for an application to know the
the type of multicast is based on the group address. If the group is type of multicast is based on the group address. If the group is in
in the 232/8 range, the application should assume SSM is the service the 232/8 range, the application should assume SSM is the service
model. Otherwise, the application should assume source-generic model. Otherwise, the application should assume source-generic
multicast is the service model. 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 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 exchanges multicast routing protocols and multicast-friendly Internet exchanges
[MIX] have enabled peering between major ISPs. This, along with the have enabled peering between major ISPs. This, along with the
increasing availability of compelling content, is spurring deployment increasing availability of compelling content, is spurring deployment
and availability of the IP Multicast Enabled Network. and availability of the IP Multicast Enabled 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
skipping to change at page 10, line ? skipping to change at page 5, line 20
- 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 with usability or functionality are sensitive to the latency involved 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,IGMPv3]
[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 delays Each channel change generates a group leave and group join, so delays
in either will affect usability. In a sense, this is more of a user in either will affect usability. In a sense, this is more of 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 received. long, the information provided may be old by the time it is 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 latency, Applications cannot affect control over either join or leave latency,
but are dependent on the multicast infrastructure to enable expedient but are dependent on the multicast infrastructure to enable expedient
operations. This is a basic multicast service requirement. operations. This is a basic multicast service requirement.
2.1.2 Sends without a Join 2.1.2 Sends without a Join
skipping to change at page 10, line ? skipping to change at page 6, line 17
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 unicast What differentiates IP multicast applications from one-to-one 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
multicast group address, as well as receiving from it
Many-to-One (Mto1): Any number of receivers sending data back to a Many-to-Many (MtoM): Any number of hosts sending to the same
(source) sender via unicast or multicast multicast group address, as well as receiving from it
+-----------------------------------+ Many-to-One (Mto1): Any number of receivers sending data back to a
| Host 2->n ("many") | (source) sender via unicast or multicast
+-------------+---------------------+ +-----------------------------------+
| One-Way | Two-Way | | Host 2->n ("many") |
+-------------+---------------------| +-------------+---------------------+
| A B | C D E | | One-Way | Two-Way |
+-----------+-------------+---------------------+ +-------------+---------------------|
| I/O | | S(m)/ S(u)/ S(m)/| | A B | C D E |
| Operations| S(m) R(m) | R(m) R(m) R(u) | +-----------+-------------+---------------------+
+-------+---+-----------+-------------+---------------------| | I/O | | S(m)/ S(u)/ S(m)/|
| | 1 | S(m) | 1toM | MtoM | | Operations| S(m) R(m) | R(m) R(m) R(u) |
| Host | 2 | R(m) | Mto1 | MtoM | +-------+---+-----------+-------------+---------------------|
| +---+-----------+-------------+ | | | 1 | S(m) | 1toM | MtoM |
| 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM | | Host | 2 | R(m) | Mto1 | MtoM |
| | 4 | S(m)/R(u) | Mto1 | | +---+-----------+-------------+ |
|("one")| 5 | S(u)/R(m) | Mto1 | | 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM |
+-------+---+-----------+-----------------------------------+ | | 4 | S(m)/R(u) | Mto1 |
|("one")| 5 | S(u)/R(m) | Mto1 |
+-------+---+-----------+-----------------------------------+
Legend: S: "Send" (u): "unicast" 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 several one-to-one (1to1). The Mto1 category, for example, refers to several
possible combinations of IP-level relationships, including unicast. possible combinations of IP-level relationships, including unicast.
We created the Mto1 category to help differentiate between the many We created the Mto1 category to help differentiate between 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
skipping to change at page 10, line ? skipping to change at page 8, line 24
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, and represents a fraction of the multicast application possibilities, 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.
television and radio "broadcasts"). One or more constant-bit-
Quinn and Almeroth Expires September 2001 [Page 8] rate (CBR) datastreams and relatively high-bandwidth demands
television and radio "broadcasts"). One or more constant-bit- characterize these applications. When more than one datastream
rate (CBR) datastreams and relatively high-bandwidth demands is present--as with an audio/video combination--the two are
characterize these applications. When more than one datastream synchronized and one typically has a higher priority than the
is present--as with an audio/video combination--the two are other(s). For example, in an a/v combination it is more
synchronized and one typically has a higher priority than the important to ensure an intelligible audio stream, than perfect
other(s). For example, in an a/v combination it is more 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
user or replication/caching sites end-user or replication/caching sites
d) Announcements: Network time, multicast session schedules, random d) Announcements: Network time, multicast session schedules,
numbers, keys, configuration updates, (scoped) network locality random numbers, keys, configuration updates, (scoped) network
beacons, or other types of information that are commonly useful. locality beacons, or other types of information that are
Their bandwidth demands can vary, but generally they are very commonly useful. Their bandwidth demands can vary, but
low bandwidth. generally they are very 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, and Bandwidth demands vary with sample frequency and resolution,
may be either constant-bit-rate or bursty (if event-driven). and may be either constant-bit-rate or bursty (if event-
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 also In many-to-Many (MtoM) applications two or more of the receivers also
act as senders. In other words, MtoM applications are characterized act as senders. In other words, MtoM applications are 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 may and powerful applications. Each host running an MtoM application may
receive data from multiple senders while it also sends data to all of receive data from multiple senders while it also sends data to all of
them. As a result, many-to-many applications often present complex them. As a result, many-to-many applications often present complex
coordination and management challenges. coordination and management challenges.
f) Multimedia Conferencing: Audio/Video and whiteboard comprise the f) Multimedia Conferencing: Audio/Video and whiteboard comprise
classic conference application. Having multiple datastreams the classic conference application. Having multiple
with different priorities characterizes this type of datastreams with different priorities characterizes this type
application. Co-ordination issues--such as determining who gets of application. Co-ordination issues--such as determining who
to talk when--complicate their development and usability. There gets to talk when--complicate their development and usability.
are common heuristics and "rules of play", but no standards There are common heuristics and "rules of play", but no
exist for managing conference group dynamics. standards exist for managing conference group dynamics.
Quinn and Almeroth Expires September 2001 [Page 9] g) Synchronized Resources: Shared distributed databases of any
g) Synchronized Resources: Shared distributed databases of any type type (schedules, directories, as well as traditional
(schedules, directories, as well as traditional Information Information System databases).
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 also k) Chat Groups: These are like text-based conferences, but may
provide simulated representations ("avatars") for each "speaker" also provide simulated representations ("avatars") for each
in simulated environments. "speaker" 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 today's capabilities. Bandwidth usage can vary widely, although
first-generation multi-player games attempt to minimize today's 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
demands vary based on the encoding technique, sample rate, bandwidth demands vary based on the encoding technique, sample
sample resolution, number of channels, etc. rate, sample resolution, number of channels, etc.
3.3 Many-to-One Applications 3.3 Many-to-One Applications
Unlike the one-to-many and many-to-many application categories, the Unlike the one-to-many and many-to-many application categories, the
many-to-one (Mto1) category does not represent a communications many-to-one (Mto1) category does not represent a communications
mechanism at the IP layer. Mto1 applications have multiple senders mechanism at the IP layer. Mto1 applications have multiple senders
and one (or a few) receiver(s), as defined by the application layer. and one (or a few) receiver(s), as defined by the application layer.
Table 1 shows that Mto1 applications can be one-way or use a two-way Table 1 shows that Mto1 applications can be one-way or use a two-way
request/response type protocol, where either senders or receiver(s) request/response type protocol, where either senders or receiver(s)
may generate the request. Figure 2 characterizes the I/O may generate the request. Figure 2 characterizes the I/O
relationship possibilities in Mto1 applications: relationship possibilities in Mto1 applications:
1) S1 2) S1 3) S1 4) S1
\ \ \ \
S2-R S2-R S2-R S2-R
.../ .../ .../ .../
Sn Sn Sn Sn
Data(m) Request(m) Request(m) Request(u)
------> ----------> <---------- ---------->
Response(u) Response(u) Response(m)
<----------- -----------> <----------
Figure 2: Characterization of Mto1 I/O possibilities
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 transparent having many multicast senders generates. This is largely transparent
to applications and the effect may be diminished in the future with to applications and the effect may be diminished in the future with
the use of bi-directional trees in multicast routing protocols, but the use of bi-directional trees in multicast routing protocols, but
nonetheless it should be considered by application designers. nonetheless it should be considered by application designers.
1) S1 2) S1 3) S1 4) S1
\ \ \ \
S2-R S2-R S2-R S2-R
.../ .../ .../ .../
Sn Sn Sn Sn
Data(m) Request(m) Request(m) Request(u)
------> ----------> <---------- ---------->
Response(u) Response(u) Response(m)
<----------- -----------> <----------
Figure 2: Characterization of Mto1 I/O possibilities
No standards yet exist for alternate and equivalent Mto1 application 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 address alternative is for each receiver to advertise its unicast address via
via multicast. However, since this strategy still leaves the multicast. However, since this strategy still leaves the potential
potential for implosion on each receiver, additional strategies may for implosion on each receiver, additional strategies may be needed
be needed to distribute the load. For example, it may be possible to to distribute the load. For example, it may be possible to increase
increase the number of receivers (in a "flat" receiver topology) or the number of receivers (in a "flat" receiver topology) or establish
establish localized receivers (in a "hierarchical" topology) as used localized receivers (in a "hierarchical" topology) as used in "local
in "local recovery" (section 5.3). Such methods have coordination recovery" (section 5.3). Such methods have coordination issues, and
issues, and although standard solutions have not yet been identified, since standard solutions have not yet been identified, Mto1
Mto1 application developers should consider their alternatives application developers should consider 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 they group address, to elicit responses from the closest host so
can satisfy the request. The responses might also contain they can satisfy the request. The responses might also contain
information that allows the receiver to determine the most information that allows the receiver to determine the most
appropriate (e.g. closest) service provider to use. appropriate (e.g., closest) service provider to use.
In Table 1, this application is entry D4. It is also In Table 1, this application is entry D4. It is also
illustrated in Figure 2 by possibility number 3. Alternately, illustrated in Figure 2 by possibility number 3.
the response could be to a multicast rather than unicast Alternately, the response could be to a multicast rather
address, although technically that would make it an MtoM than unicast address, although technically that would make
application type (this is how the Service Location Protocol it an MtoM application type (this is how the Service
[SLP] operates, when a user agent attempts to locate a directory Location Protocol [SLP] operates, when a user agent attempts
agent). to locate a directory 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 2, difference being that A3 has a loopback interface. In Figure
this is possibility number 1. Since the number of receivers can 2, this is possibility number 1. Since the number of receivers
easily be more than one, this is really an MtoM application. can easily be more than one, this is really an MtoM
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 2, respond with answers. This is possibility number 2 in Figure
and could also be characterized as an MtoM application if the 2, and could also be characterized as an MtoM application if
response is to a multicast address. the response is to a multicast address.
s) Juke Box: Allows near-on-demand a/v playback. Receivers use an s) Jukebox: 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 information about each receiver, possibly in real-time. But such
can be overwhelming[MRM]. Current mechanisms, like RTCP (which information can be overwhelming [MRM]. Current mechanisms,
is actually MtoM since it is multicast but could be made Mto1), like RTCP (which is actually MtoM since it is multicast but
use scaling techniques but trade-off information granularity. As could be made Mto1), use scaling techniques but trade-off
a group grows the total amount of feedback is constant but each information granularity. As a group grows the total amount of
receiver sends less. feedback is constant but each receiver sends less.
4. Common Multicast Service Requirements 4. Common Multicast Service Requirements
Some multicast application service requirements are common to unicast Some multicast application service requirements are common to unicast
network applications as well. We characterize two of them here-- network applications as well. We characterize two of them 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 5.3, it is the need to accommodate multiple
heterogeneous multicast receivers--with their diversity of bandwidth heterogeneous multicast receivers--with their diversity of bandwidth
capacity and delivery delays--that presents the unique challenge for capacity and delivery delays--that presents the unique challenge for
multicast applications to satisfy these requirements. multicast applications to satisfy these requirements.
| |
1toM | b, d c, e a 1toM | b, d c, e a
| |
MtoM | k g, i f, h, j, l, m, n MtoM | k g, i f, h, j, l, m, n
| |
Mto1 | o, q, r p, q, t s Mto1 | o, q, r p, 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 have real-time monitoring information), most one-to-many applications have
a high tolerance for delay and delay variance (jitter). Constant bit- a high tolerance for delay and delay variance (jitter). Constant
rate (CBR) data--such as streaming media (audio/video)--are sensitive bit-rate (CBR) data--such as streaming media (audio/video)--are
to jitter, but applications commonly counteract the effects by sensitive to jitter, but applications commonly counteract the effects
buffering data and delaying playback. by buffering data and delaying playback.
Most many-to-one and many-to-many multicast applications are Most many-to-one and many-to-many multicast applications are
intolerant of delays because they are bidirectional, interactive and intolerant of delays because they are bidirectional, interactive and
request/response dependent. As a result, delays should be minimized, request/response dependent. As a result, delays should be minimized,
since they can adversely affect the application's usability. since they can adversely affect the application's 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
or video is delayed more than 500 milliseconds. For this and other 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
| |
skipping to change at page 15, line 22 skipping to change at page 15, line 17
+--------------------------------------+ +-------------------+ +--------------------------------------+ +-------------------+
+-------------------------------------+| |+--------++--------+ +-------------------------------------+| |+--------++--------+
| Multicast Security || || || | | Multicast Security || || || |
+----------------------+ +----------+| || System || | +----------------------+ +----------+| || System || |
+----------++---------+| |+---------+| || Time || Codecs | +----------++---------+| |+---------+| || Time || Codecs |
| Reliable || Address || || Session || || || | | Reliable || Address || || Session || || || |
| Delivery || Mgt || || Mgt || || || | | Delivery || Mgt || || Mgt || || || |
+----------++---------++---++---------++---++--------++--------+ +----------++---------++---++---------++---++--------++--------+
+----------------------------------------++--------------------+ +----------------------------------------++--------------------+
| Basic IP Multicast Service || IP Unicast | | Basic IP Multicast Service || IP Unicast |
| (e.g. UDP and IGMPv2/v3) || 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 Selection and coordinated of address Address Management - Selection and coordinated of address
allocation. The need is provide assurances against address allocation. The need is to provide assurances against "address
collision and provide address ownership. collision" and to provide address ownership.
Session Management Perform application-layer services on top of Session Management - Perform application-layer services on top of
multicast transport. These services depend heavily on the multicast transport. These services depend heavily on the
application but include functions like session advertisement, application but include functions like session advertisement,
billing, group member monitoring, key distribution, etc. 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 by Reliable Data Delivery - Ensuring that all data sent is received
all receivers. by 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, and application services in more detail, the challenges they present, 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, and assigned to individual hosts, assignments can change dynamically, and
addresses sometimes have semantics of their own (e.g. Admin Scoping). addresses sometimes have semantics of their own (e.g., Admin
Multicast applications require an address management service that Scoping). Multicast applications require an address management
provides address allocation or assignment queries. There are a service that provides address allocation or assignment 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 executable, Hard-Coded: Software configuration, encoded in a binary
or burned into ROM in embedded devices. These applications executable, or burned into ROM in embedded devices. These
typically reference IANA statically allocated multicast applications typically reference IANA statically allocated
addresses (including relative addresses). multicast addresses (including relative addresses).
Advertised: Session announcements (as described in the next Advertised: Session announcements (as described in the next
section), or via another "out-of-band" query or discovery section), or via another "out-of-band" query or discovery protocol
protocol mechanism. mechanism.
Algorithmically Derived: Using a programmatic algorithm to allocate Algorithmically Derived: Using a programmatic algorithm to
a statistically random (unused) address. allocate a statistically random (unused) address.
| |
1toM | c, e a, b d 1toM | c, e a, b d
| |
MtoM | f, j, k, n g, h, i, l, m MtoM | f, j, k, n g, h, i, l, m
| |
Mto1 | r o, p, s q, 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
In almost all cases, application designers should assume that In almost all cases, application designers should assume that
multicast addresses are to be dynamic. Very little of the multicast multicast addresses are to be dynamic. Very little of the multicast
address space is available for static assignment by IANA [MADDR]. address space is available for static assignment by IANA [MADDR].
Also, given the host-specific addressing available with SSM, Internet- Also, given the host-specific addressing available with SSM,
wide, static address assignment is expected to be very rare. Internet-wide, static address assignment is expected to be very rare.
5.2 Session Management 5.2 Session Management
Session management is one of the most misunderstood services with Session management is one of the most misunderstood services with
respect to multicast. Most application developers assume that respect to multicast. Most application developers assume that
multicast will provide services like security, encryption, multicast will provide services like security, encryption,
reliability, session advertisement, monitoring, billing, etc. In reliability, session advertisement, monitoring, billing, etc. In
fact, multicast is simply a transport mechanism that provides end-to- fact, multicast is simply a transport mechanism that provides end-
end delivery. All of the other services are application-layer to-end delivery. All of the other services are application-layer
services that must be provided by each particular application. services that must be provided by each particular application.
Furthermore, in most cases there are not defined standards for how Furthermore, in most cases there are not defined standards for how
these functions should be provided. The particular functions are these functions should be provided. The particular functions are
dependent on the particular needs of the application, and no single dependent on the particular needs of the application, and no single
method (or standard) can be made to be sufficient for all cases. method (or standard) can be made to be sufficient for all cases.
While there are no generic solutions which provide all session While there are no generic solutions which provide all session
management functions, there are some protocols and common techniques management functions, there are some protocols and common techniques
that provide support for some of the functions. Techniques for that provide support for some of the functions. Techniques for
congestion control and heterogeneous receiver support are discussed congestion control and heterogeneous receiver support are discussed
skipping to change at page 17, line 46 skipping to change at page 17, line 38
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, but currently use it. SAP limits distribution via multicast scoping, but
the current protocol definition has scaling issues that need to be the current protocol definition has scaling issues that need to be
addressed. Specifically, the initialization latency for a session addressed. Specifically, the initialization latency for a session
directory can be quite long, and it increases in proportion to the directory can be quite long, and it increases in proportion to the
number of session announcements. This is to an extent a multicast number of session announcements. This is to an extent a multicast
infrastructure issue, however, as this level of protocol detail infrastructure issue, however, as this level of protocol 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
- Provide a query mechanism for retrieving information about - Advertise scheduled sessions
session schedules - Provide a query mechanism for retrieving
information about 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) provides network conditions. The Transmission Control Protocol (TCP) provides
skipping to change at page 18, line 38 skipping to change at page 18, line 38
algorithms to achieve the same result, or even improve on it. algorithms to achieve the same result, or even 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, it audio/video stream requires. When a UDP application detects loss, it
can adapt the data itself to accommodate the lower send rate. For can adapt the data itself to accommodate the lower send rate. For
example, a UDP application can: example, a UDP application can:
- Reduce the data resolution (e.g. send lower fidelity audio/video - Reduce the data resolution (e.g., send lower fidelity
by reducing sample frequency or frame rate) to reduce data rate. audio/video by reducing sample frequency or frame rate) to
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 another - Reduce the send rate of one datastream in order to favor another
of higher priority (e.g. sacrifice video in order to ensure of higher priority (e.g., sacrifice video in order to 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. If capabilities and dynamically due to transient traffic conditions. If
a sender adapts its send rate and data resolution based on the loss a sender adapts its send rate and data resolution based on the loss
rate of its worst receiver(s), then it can only service the lowest rate of its worst receiver(s), then it can only service the lowest
common denominator. Hence, a single "crying baby" can spoil it for common denominator. Hence, a single "crying baby" can spoil 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 waits receives a data loss report sent by another receiver as it waits
for the timer to expire, it stops the timer and does not send a for the timer to expire, it stops the timer and does not send a
report. Otherwise, it sends a report when the timer expires. report. Otherwise, it sends a report when the timer expires.
The Real-Time Protocol and its feedback-loop counterpart Real- The Real-Time Protocol and its feedback-loop counterpart Real-
Time Control Protocol [RTP/RTCP] employ a strategy similar to Time Control Protocol [RTP/RTCP] employ a strategy similar to
this to keep feedback traffic to 5 percent or less than the this to keep feedback traffic to 5 percent or less than the
overall session traffic. This technique was originally utilized overall session traffic. This technique was originally utilized
in IGMP. in IGMP.
skipping to change at page 20, line 15 skipping to change at page 20, line 20
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 common feedback for multicast, with the ultimate goal of developing a 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 fidelity is lost. For example, audio might have a short gap or lower fidelity
but will remain legible despite some data loss. but will remain intelligible 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 this Intolerant" column in Figure 7 shows a list of applications with this
requirement, while the others can tolerate varying levels of data requirement, while the others can tolerate varying levels of data
loss. The tolerance levels are typically determined by the nature of loss. The tolerance levels are typically determined by the 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
skipping to change at page 21, line 22 skipping to change at page 21, line 27
Scalability is the paramount concern, and it implies the general need Scalability is the paramount concern, and it implies the general need
for "network friendly" protocols that detect and avoid congestion as for "network friendly" protocols that detect and avoid congestion as
they provide reliable delivery. Other considerations are protocol they provide reliable delivery. Other considerations are protocol
robustness, support for "late joins", group management and security robustness, support for "late joins", group management 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 number of reliable multicast protocols, rather than a single one
one[BULK]. [BULK, RMT].
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 complexity without it--the challenges increase also. Security system complexity
and overhead is commensurate with the protection it provides. "No one and overhead is commensurate with the protection it provides. "No
can guarantee 100% security. But we can work toward 100% risk one can guarantee 100% security. But we can work toward 100% risk
acceptance ...Strong cryptography can withstand targeted attacks up acceptance...Strong cryptography can withstand targeted attacks up to
to a point--the point at which it becomes easier to get the a point--the point at which it becomes easier to get the information
information some other way ...A good design starts with a threat some other way...A good design starts with a threat model: what the
model: what the system is designed to protect, from whom, and for how system is designed to protect, from whom, and for how long."
long." [Schneier] [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 for privacy and user privacy (anonymity). However, enabling security for
multicast applications is even more of a challenge than for unicast. multicast applications is even more of a challenge than for unicast.
Having multiple receivers makes a difference, as does their Having multiple receivers makes a difference, as does their
heterogeneity and the dynamic nature of multicast group memberships. heterogeneity and the dynamic nature of multicast group 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
possible yet) possible yet)
Verifying Content - Ensuring that data originated from an Verifying Content - Ensuring that data originated from an
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 [Finlayson].
This list is not comprehensive, but includes the most commonly needed This list is not comprehensive, but includes the most commonly needed
security services. Different multicast applications and different security services. Different multicast applications and different
application contexts can have very different needs with respect to application contexts can have very different needs with respect to
these services, and others. "Two main issues emerge, where the these services, and others. Two main issues emerge, where the
performance of current solutions leaves much to be desired" performance of current solutions leaves much to be desired [MSec].
[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
their possession disabled)? 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
during joins or re-keying current members after a member leaves can during joins or re-keying current members after a member leaves can
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 under investigation
investigation in the Internet Research Task Force [IRTF]. Protocol in the Internet Research Task Force [IRTF]. Protocol mechanisms for
mechanisms for many of the most important of these services--such as many of the most important of these services--such as limiting
limiting senders--have not yet been defined, let alone developed and 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 sometimes- single security protocol will satisfy the wide diversity of
contradictory requirements among multicast applications. Hence, sometimes-contradictory requirements among multicast applications.
multicast security will also likely require a number of different Hence, multicast security will also likely require a number of
protocols. different 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 stereo system that is wired throughout a home (via analog). With the stereo
skipping to change at page 23, line 25 skipping to change at page 23, line 36
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
2) datastreams must be framed with timestamps 2) datastreams must be framed with timestamps
3) the playback latency of the multimedia hardware 3) you must know the playback latency of the multimedia hardware
The third of these is the most difficult to achieve at this time. The third of these is the most difficult to achieve at this time.
Hardware and drivers don't provide any mechanism for retrieving this Hardware and drivers don't provide any mechanism for retrieving this
information, although different audio and video devices have a wide- information, although different audio and video devices have a wide-
range of performance. range of performance.
6. Service APIs 6. Service APIs
In some cases, the protocol services mentioned in this document can In some cases, the protocol services mentioned in this document can
be enabled transparently by passive configuration mechanisms and be enabled transparently by passive configuration mechanisms and
"middleware." For example, it is conceivable that a UDP "middleware". For example, it is conceivable that a UDP
implementation could implicitly enable a reliable multicast protocol implementation could implicitly enable a reliable multicast protocol
without the explicit interaction of the application. without the explicit interaction of the application.
Sometimes, however, applications need explicit access to these Sometimes, however, applications need explicit access to these
services for flexibility and control. For example, an adaptive services for flexibility and control. For example, an adaptive
application sending to a heterogeneous group of receivers using RTP application sending to a heterogeneous group of receivers using RTP
may need to process RTCP reports from receivers in order to adapt may need to process RTCP reports from receivers in order to adapt
accordingly (by throttling send rate or changing data encoders, for accordingly (by throttling send rate or changing data encoders, for
example) [RTP API]. Hence, there is often a need for service APIs example) [RTP API]. Hence, there is often a need for service APIs
that allow an application to qualify and initiate service requests, that allow an application to qualify and initiate service requests,
and receive event notifications. In Figure 4, the top edge of the and receive event notifications. In Figure 5, the top edge of the
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 be this document might also identify the protocol features that could be
mapped to define a (generic) API definition for that service. APIs mapped to define a (generic) API definition for that service. APIs
are often controversial, however. Not only are there many language are often controversial, however. Not only are there many language
differences, but it is also possible to create different APIs by differences, but it is also possible to create different APIs by
exposing different levels of detail in trade-offs between flexibility exposing different levels of detail in trade-offs between flexibility
and simplicity. and simplicity.
7. Security Considerations 7. Security Considerations
See section 4.4 See section 5.4
8. Acknowledgements 8. Acknowledgements
The author would like to acknowledge and thank the following The authors 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] Partridge, C., Mendez, T. and W. Milliken, "Host
Service", RFC 1546, November 1993 Anycasting Service", RFC 1546, November 1993.
[BeauW] B. Williamson, Developing IP Multicast Networks,
Volume I, (c) 2000 Cisco Press, Indianapolis IN,
ISBN 1-57870-077-9
[Bradner] S. Bradner, "Internet Protocol Multicast Problem
Statement", <draft-bradner-multicast-problem-00.txt>,
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
issues", <draft-irtf-smug-taxonomy-00.txt>, April 1999,
Work in Progress
[Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to [BeauW] B. Williamson, "Developing IP Multicast Networks, Volume
Facilitate Multicast Firewall Traversal", <draft-ietf- I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
aft-mcast-fw-traversal-01.txt>, November 1997, Work in 077-9.
Progress
[Deering] S. Deering, Host Extensions for {IP} Multicasting, RFC [BULK] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
1112, August 1989 Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", RFC
3048, January 2001.
[DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of [Deering] Deering, S., "Host Extensions for IP Multicasting", STD
Internet Protocol Suite for Distributed Simulation in the 5, RFC 1112, August 1989.
Large Multicast Environment", RFC 2502, February 1999
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, [DIS] Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
M. Speer, R. Braden, B. Davie, "Integrated Services Internet Protocol Suite for Distributed Simulation in the
Operation over Diffserv Networks", <draft-ietf-issll- Large Multicast Environment", RFC 2502, February 1999.
diffserv-rsvp-02.txt>, June 1999, Work in Progress
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech [E2EQOS] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Earthlink Seminar Series, April 22, 1998 Speer, M., Braden, R. and B. Davie, "Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[Finlayson] R. Finlayson, "IP Multicast and Firewalls", RFC 2588, [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech
May 1999 Earthlink Seminar Series, April 22, 1998.
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy [Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
of Feedback for Multicast", June 1999, Work in Progress May 1999.
[IGMPv2] B. Fenner, "Internet Group Management Protocol, Version [HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
2", RFC 2236, November 1997 of Feedback for Multicast", June 1999, Work in Progress.
[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan, [IGMPv2] Fenner, B., "Internet Group Management Protocol, Version
Internet Group Management Protocol, Version 3, 2", RFC 2236, November 1997.
<draft-ietf-idmr-igmp-v3-03.txt>, March 2000, Work
in Progress
[IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia [IGMPv3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
Jukebox (IMJ): A New Paradigm for the On-Demand Delivery "Internet Group Management Protocol, Version 3", Work in
of Audio/Video", Proceedings of the Seventh International Progress.
World Wide Web Conference, Brisbane, AUSTRALIA, April
1998
[IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia
Procedures", RFC 2014, January 1996 Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
of Audio/Video", Proceedings of the Seventh International
World Wide Web Conference, Brisbane, AUSTRALIA, April
1998.
[Kermode] R. Kermode, "MADCAP Multicast Scope Nesting State [IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and
Option", February 1999, <draft-kermode-madcap-nest-opt- Procedures", BCP 8, RFC 2014, January 1996.
00.txt>, Work in Progress
[LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of [Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State
Communication Requirements, for Large-scale Multicast Option", RFC 2907, September 2000.
Applications," <draft-ietf-lsma-requirements-03.txt>,
May 1999, Work in Progress
[MADDR] Z. Albanna, K. Almeroth, D. Meyer, IANA Guidelines for [LSMA] Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
IPv4 Multicast Address Allocation, <draft-albanna-iana- Communication Requirements for Large-scale Multicast
IPv4-mcast-guidelines-00.txt>, 2001, Work in Progress Applications", RFC 2729, December 1999.
[MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. [MADDR] Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
Radoslavov, D. Thaler, "The Multicast Address-Set Claim "IANA Guidelines for IPv4 Multicast Address Assignments",
(MASC) Protocol", <draft-ietf-malloc-masc-01.txt>, August BCP 51, RFC 3171, August 2001.
1998, Work in Progress
[Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise", [MASC] Estrin, D., Govindan, R., Handley, M., Kumar, S.,
(c) 1998 Prentice Hall, Upper Saddle River NJ Radoslavov, P. and D. Thaler, "The Multicast Address-Set
ISBN 0-13-897687-2 Claim (MASC) Protocol", RFC 2909, September 2000.
[Miller] C. K. Miller, "Multicast Networking and Applications", [Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise",
(c) 1999 Addison Wesley Longman, Reading MA (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
ISBN 0-201-30979-3 897687-2.
[MADCAP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address [Miller] C. K. Miller, "Multicast Networking and Applications",
Dynamic Client Allocation Protocol (MADCAP)", (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
<draft-ietf-malloc-madcap-04.txt>, February 1999, 30979-3.
Work in Progress
[MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast- [MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Friendly Internet Exchange (MIX)", <draft-ietf-mboned- Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
mix-00.txt>, Dec 1998, Work in Progress December 1999.
[MRM] K. Almeroth, L. Wei, D. Farinacci, Multicast [MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment
Reachability Monitor (MRM), <draft-ietf-mboned-mrm- Efforts: A Survey of Tools for Multicast Monitoring",
00.txt>, April 1999, Work in Progress Journal of High Speed Networking--Special Issue on
Management of Multimedia Networking, March 2001
[MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone [MSec] Multicast Security (msec) IETF Working Group charter
Announcement Protocol (MZAP) ", <draft-ietf-mboned-mzap-
03.txt>, Feb 1999, Work in Progress
[Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and [MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, Zone Announcement Protocol (MZAP)", RFC 2776, February
January 1998 2000.
[Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98 [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and
workshop, June 1998, UCL London Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
http://www.iet.unipi.it/~luigi/hipparc98.ps.gz January 1998.
[RM] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF [Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
Criteria for Evaluating Reliable Multicast Transport and workshop, June 1998, UCL London
Application Protocols", RFC 2357, June 1998 http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
[RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated [RM] Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
Services", RFC 2210, September 1997 "IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols", RFC 2357, June
1998.
[RTP API] J. Rosenberg, "Columbia RTP Library API Specification," [RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
(Note: Does not include RTCP processing), February 1997 Services", RFC 2210, September 1997.
[RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP API] H. Schulzrinne, et al, "RTP Library API Specification,"
"RTP: A Transport Protocol for Real-Time Applications", http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
RFC 1889, January 1996 1.0a1/rtp_api.html
[SAP] M. Handley, "SAP: Session Announcement Protocol", <draft- [RTP/RTCP] Schulzrinne, H., Casner, S., Frederick, R. and V.
ietf-mmusic-sap-00.txt>, November 1996, Work in Progress Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol [SAP] Handley, M., Perkins, C. and E. Whelan, "Session
(SADP) ", <draft-ietf-mboned-sadp-01.txt>, Jan 1999, Work Announcement Protocol", RFC 2974, October 2000.
in Progress
[SDP] M. Handley, V. Jacobson, "SDP: Session Description [SDP] Handley, M., and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998 Protocol", RFC 2327, April 1998.
[Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks", [Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks",
December 1996, http://www.counterpane.com/whycrypto.html December 1996, http://www.counterpane.com/whycrypto.html
[SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast [SlowStart] Stevens, W., "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] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
Location Protocol", RFC 2165, June 1997 "Service Location Protocol", RFC 2165, June 1997.
[SSM] H. Holbrook, B. Cain, Specific Multicast for IP, <draft- [SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP",
holbrook-ssm-arch-01.txt>, Nov 2000, Work in Progress Work in Progress.
10. Authors' Addresses 10. Authors' Addresses
Bob Quinn Bob Quinn
Celox Networks Celox Networks
2 Park Central Drive 2 Park Central Drive
Southborough, MA 01772 Southborough, MA 01772
+1 508 305 7000 Phone: +1 508 305 7000
bquinn@celoxnetworks.com EMail: bquinn@celoxnetworks.com
Kevin Almeroth Kevin Almeroth
Department of Computer Science Department of Computer Science
University of California University of California
Santa Barbara, CA 93106-5110 Santa Barbara, CA 93106-5110
+1 805 893 2777 Phone: +1 805 893 2777
almeroth@cs.ucsb.edu EMail: 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 (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or 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 in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet languages other than English. copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 148 change blocks. 
504 lines changed or deleted 448 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/