UNICAST EXTENSIONS TO IP MULTICAST
Tarik Čičić
Haakon Bryhni
Steinar Sørlie
Department of Informatics, University of Oslo
Pb. 1080 Blindern, 0316 Oslo, Norway, e-mail: {tarikc, bryhni, steinaso}@ifi.uio.no
A BSTRACT
IP multicast is still not widespread in the Internet.
Its slow acceptance is caused by immature multicast
network infrastructure but also by inadequate end-user
applications. In this paper we present an architecture
for unicast extensions to IP multicast that can be used
to solve several detected multicast-related problems.
The architecture is based on a data forwarding tool,
the Multicast-Unicast Reflector, providing a solution
to the problems at the network level. We also present
solutions at the application level, providing web-based
access to announced multicast sessions, integration of
multicast multimedia sessions with participants with a
Voice over IP, PSTN or cellular telephone terminal and,
finally, use of the proposed architecture to provide a
scalable H.323 Multipoint Control Unit.
1
I NTRODUCTION
In numerous communication scenarios, a data source
needs to send the same data packet to a predefined
group of receivers. The network service that enables
this operation to be performed in a single step is called
multicast. Multicast was introduced to IP networks in
1988 through Steven Deering Ph.D. thesis [5] and subsequent IETF work [24, 4]. This resulted in development of Mbone [7], the virtual overlay multicast network on top of the Internet, where the first successful wide area multicast sessions took place in the early
nineties.
The traditional Mbone became a victim of its own
success. Due to inherent properties of early multicast
routing protocols (e.g. flat topology, data flooding),
Mbone could not scale to the growing requirements of
multicast applications. The traditional Mbone practically collapsed in the late nineties. Nowadays, more
scalable multicast routing protocols, most prominently
Protocol Independent Multicast [8, 3], are being deployed in IP networks. IP multicast is becoming a na-
tive IP service and is proposed to be a mandatory part of
IPv6. Furthermore, efforts have been made to organize
IP multicast in a hierarchical topology, where domains
running PIM or other intra-domain protocols will be
interconnected using an inter-domain multicast routing
protocol such as Multicast Source Discovery Protocol
[10] or Border Gateway Multicast Protocol [9]. We believe that this development will eventually lead to omnipresent IP multicast.
However, ubiquitous IP multicast is not easy to
achieve. First, IP resides on network technologies ranging from low bandwidth PPP-based Public Switched
Telephone Networks (PSTN) and mobile networks to
broadband access networks. It will take a long time
and lots of parameter and performance tuning in the
multicast routing protocols to make IP multicast effective regardless of the underlying network technology.
Second, IP multicast is inherently sensitive to network
phenomena such as data looping, path and data duplicating etc. Therefore IP multicast is difficult to combine with several other popular networking concepts
(e.g. Virtual Private Networks, VPN1 ) that may cause
these anomalies. Third, many important services based
on IP are not designed with IP multicast in mind, although they would benefit from many-to-many communication (such as H.323 conferences). Furthermore,
the success of any network service is indistinguishable
from the benefits it gives to the end-users. To be accepted among the end-users, IP multicast needs useful
applications and simple control facilities.
In this paper we show that many of the problems
identified above can be partly or totally avoided by using a multicast proxy architecture that can seamlessly
connect a set of unicast participants with a multicast
session on a multicast enabled network. We discuss de1 VPN in this context is regarded as an ordering of geographically
distributed physical networks that constitutes a single logical IP network.
sign issues and present an architecture for a multicastto-unicast interconnection. We present a data forwarding unit, the Multicast-Unicast Reflector. We show how
the reflector can be controlled through a WWW interface and directly from the applications using the Real
Time Streaming Protocol [21]. We further show how
IP multicast audio sessions can be joined from public telephone networks using an H.323 compliant IP–
PSTN gateway and H.225 Call Signaling protocol [13].
We present two cases where the reflector solves identified IP multicast network problems and three application level cases. We also give a short assessment of
performance properties of our prototype implementation.
The rest of the paper is organized as follows. In Section 2 we present background and argument why unicast extensions to IP multicast are needed. In Section 3
the system architecture is described and discussed. Potential use of the proposed architecture is discussed in
Section 4. Performance of a prototype implementation
is presented in Section 5. Conclusion and future work
are presented in Sections 6 and 7 respectively.
2
BACKGROUND
2.1 IP Multicast Deployment Issues
Multicast service can be provided in any IP network,
regardless of the underlying network technology. The
service may be suboptimal in some types of stub networks or under VPN deployment.
2.1.2 Virtual Connections
Even in modern, broadband network configurations,
problems may occur if two physically neighboring
LANs are administratively located in two separate domains, a situation typical for VPNs. In Figure 1,
Routers 1 and 7 are configured so that they are both
members of a single autonomous system4 (e.g. AS2).
There is a virtual link (1-7) connecting routers 1 and 7.
A multicast flow originating from a source attached to
router 7 can easily be routed to router 1 and its attached
receiver R1 through the virtual link. If R2 wishes to
join the multicast group, it can do so only through the
"regular" multicast path 2-3-4-5-6-7. Multicast traffic
must not be routed between routers 1 and 2; in the case
of well ordered hierarchical multicast topology, only a
single path will be established between any two ASes.
Naïve attempt to establish intradomain multicast routing between routers 1 and 2 will give one or more of the
following effects, depending on the particular protocol
choice and configuration:
• pruning of intradomain multicast tree branches
• using link 1-7 as the main data injector to AS1
(pruning link 4-5)
• data duplication
• oscillating data path.
2.1.1 Stub Networks
Many network operators and even end users may be reluctant in deploying multicast technology in their networks due to the overhead introduced by control of the
multicast traffic2 or data flooding3. In particular, this
may be the case for low bandwidth ISDN and modem
lines as well as (older) switching equipment, which often non-selectively replicates multicast traffic at all interfaces.
Furthermore, emerging network technologies are
sometimes not tuned for IP multicast. For example, our
experience shows that IEEE 802.11 wireless LANs often set down the bit rate for multicast traffic to the lowest available, to avoid link layer retransmissions and resource monopolization by the multicast traffic.
All these situations occur in stub networks, close to
the end users. In many cases, forwarding multicast data
to selected end-users using unicast flows from a nearby,
stable multicast network will be a better solution than
using IP multicast in the stub networks suffering from
the described problems.
2 Sparse-mode protocols and group membership protocols (e.g.
[8, 4]) generate periodic control messages.
3 Dense-mode multicast routing protocols (e.g. [24, 3]) use periodic data flooding to reach new receivers in the network.
Figure 1: IP multicast deployment in presence of virtual links. S sends a multicast flow to receivers R1 and
R2
Although it is certainly possible to carefully configure
routers 1 and 7 with an inter-domain multicast routing protocol and the desired routing policy, installing
a multicast-unicast reflector close to router 1 may be a
much simpler solution.
2.2 User-friendliness of IP Multicast
Multicast was introduced to the Internet before WWW,
but remained almost unknown outside academic com4 A single VPN will normally be distributed among several ASes,
i.e. among independent networks under different administrative authorities and possibly with different routing protocols deployed.
munity. While the network problems were the major
obstacle for a large-scale deployment, the early multicast applications were difficult to use for untrained
personnel. Thus, the applications have been an effective barrier for the wide public to use multicast on
their machines, even if the network supported multicast. Wide deployment and usage of IP multicast needs
user-friendly tools and control systems.
In Section 3 we propose two user-friendly mechanisms to provide access to multicast sessions.
2.3 Multimedia Control Protocols
The IETF architecture for multimedia communications
supports IP multicast in (among others) Real-Time
Transport Protocol [20] and several control protocols
(Session Initiation Protocol [12], Session Description
Protocol [11] and Real Time Streaming Protocol [21]).
This architecture has proved to be both scalable and
adaptable. Clear distinction between data and control
protocols and communication channels is probably the
most important factor of this success. On the other
hand, the ITU-T multimedia protocol suite for packet
networks H.323 [14] has more data/control interleaving, leading to complex, centralized implementations.
We believe that this is a part of the reason for H.323’s
slow acceptance in the Internet.
RTSP, the application-level protocol for control over
the delivery of data flows with real-time properties, is
of particular interest for this study. RTSP provides
means for control of the Multicast-Unicast Reflector,
and in addition is easy to integrate in the existing
WWW infrastructure. We believe that RTSP can play
a major role in making IP Multicast accessible to the
wide Internet community.
2.4 IP Telephony
Interconnection of IP telephones and public telephone
networks is normally done using the H.323 standard.
IETF has proposed use of SIP, but this protocol is not
yet widely deployed in the Voice over IP industry. Use
of H.323 in point-to-point telephony applications, either directly between Voice over IP terminals or between a voice terminal and an H.323–PSTN gateway,
is straightforward. However, use of the H.323 protocol for non-local multiparty conferences mandates the
use of a Multipoint Control Unit (MCU), a complex
system for audio and video multiplexing. The MCU
architecture is not scalable, due to the fact that it terminates each media stream and perform CPU intensive
media stream splicing and takes care of distribution of
the combined media stream to each participant of the
conference using point-to-point IP streams.
2.5 Related Work
The concept of multicast-unicast reflector (or translator
or replicator) is not new. It is introduced in the RTP and
RTSP standards, and several implementations are publicly available, e.g. RTPtrans [22], UCL Transcoding
Gateway (UTG) [23], LiveGate [17] and Reflex [15].
These applications are mainly designed to solve
lacking multicast connectivity. Several provide additional features (e.g. transcoding), which may be an advantage in some scenarios but limits the usability in
others. Installation and usage of these reflectors requires knowledge of system administration and IP multicast concepts.
Darwin Streaming Server [1], an open source project
from Apple Computers Inc., includes a multicastunicast reflector in its RTSP server. As we discuss in
Section 3, we believe that the RTSP server and the
reflector should be separated components in order to
achieve better scalability of the system. We have, however, chosen Darwin as basis for our RTSP server modifications (Section 3.2).
3
A RCHITECTURE
We suggest that the architecture of the MulticastUnicast Reflector and the control systems should
1. be component based
2. be scalable, which is achieved by a distributed architecture
3. separate data and control traffic and functions.
In addition, units that take place in the data traffic
chain (i.e. the Multicast-Unicast Reflector) should introduce minimal or no communication overhead and
forward data efficiently in terms of the computer resource consumption and the introduced delay. Complying to these requirements is important for system scalability and the price/performance ratio.
Finally, the control system should feature
lightweight client software and be simple to install and manage. The control system should be easy
to integrate in the existing communication systems
such as WWW, Internet multimedia applications and
PSTN. We note that the implementational complexity
is hereby moved to the control servers, which is an
acceptable tradeoff having in mind relatively low
expected volume of control traffic compared to data
traffic.
3.1 The Multicast-Unicast Reflector
The Multicast-Unicast Reflector architecture should
support the following functions:
1. forwarding of data traffic bidirectionally between
a multicast address and a set of unicast addresses5
2. forwarding of any associated control traffic (e.g.
RTCP packets) in the same way
3. handling of multiple multicast groups, each with
one or many unicast users attached, by a single
reflector
4. session administration and control through a distinct control channel.
We design the reflector to consist of two loosely connected units: session controller and reflector engine.
The reflector engine maintains tasks (1) – (3), while the
session controller does (4).
The reflector engine transmits UDP or RTP/RTCP
packets from multicast groups to attached unicast participants and vice versa. A data packet accepted from a
registered unicast address is forwarded to the multicast
address and to all other associated unicast addresses.
The reflector engine is based on a data structure representing a set of multicast “channels”, each identifying a multicast session and a set of unicast participants.
Packet forwarding is performed in separate threads, as
shown in Figure 2.
add and remove unicast participants to a group, pause
and resume transmission etc. Introduction of the new
protocol is justified by the fact that no other known
protocol provides the needed functionality and that it
is necessary in order to achieve the distributed general
architecture.
3.2 RTSP Control Unit
As discussed in Section 2, simplicity and userfriendliness are among the factors of success for IP
multicast applications. Here, we present our RTSPbased system for WWW-integrated control of the
Multicast-Unicast Reflector.
We suggest an architecture with
1. session announcements on WWW. Session descriptions are accessible using standard WWW
browsers, and linked to RTSP servers.
2. RTSP media stream control. The user exchanges
RTSP messages (C ONNECT, P LAY, PAUSE etc.)
only with the RTSP server, while the RTSP server
controls one or more associated reflectors using
our RSP protocol.
In this way the participation in multicast sessions becomes simple even for untrained users, while the reflector becomes transparent for the users — direct control
of the reflector is unnecessary.
3.2.1 RTSP Server
Figure 2: Reflector architecture. For simplicity, data
flows for only one RTP channel with a single unicast
participant are shown.
We design the session controller as an interface between external applications (e.g. RTSP servers) and the
reflector engine. We implement the session controller
as a server thread supporting the reflector-specific Reflector Session Protocol (RSP, [19]). RSP represents a
minimal protocol for control of Multicast-Unicast Reflector functions. By using this protocol the reflector
can be instructed to join and leave multicast groups,
5 Unicast address in this context means ”unicast address and port
number”. Multicast address is an abbreviation for ”multicast address,
port and time-to-live value”.
The RTSP server controls one or more nearby reflector(s). Out from the standard RTSP commands sent by
the client, the RTSP server can determine if the client
is directly accessible through the multicast network or
not. If not, the RTSP server establishes a connection
to the reflector using the RSP protocol, and sets up a
reflector session. The RTSP server returns status and
connection parameters (unicast ports, timing etc.) to
the client in form of the standard RTSP response.
There is no need for extending RTSP protocol to
achieve this functionality. It is however necessary to
extend the RTSP server with routines for controlling
RSP clients (the reflectors) and maintaining reflector
state information.
3.2.2 RTSP Client
On the user side, a simple RTSP client application takes
care of starting and stopping media tools (e.g. Robust
Audio Tool and Videoconferencing Tool [23]). During the installation process, the local WWW browser
should be configured so that the RTSP client is its default helper application for RTSP files. This greatly
enhances user-friendliness of the whole system, since
joining multicast sessions becomes as simple as browsing the web.
The communication between the RTSP client and the
media tools is best achieved using a local control channel like Message Bus [16]. In this way the media tools
can be instructed e.g. to change the media parameters
or to quit.
3.2.3 Session Announcement Collector
At this point we have explained both the data forwarding procedures and the RTSP control of the reflector.
Two important points have not been discussed so far:
how to announce multicast sessions to a non-multicast
user and how to ensure that the reflector and the RTSP
server have the same view of announced multicast sessions and their parameters.
To solve these two questions we introduce the last
component in the control architecture — the Session
Announcement Collector. It collects session announcements in form of SDP packets that are multicasted at
a well-known multicast address and caches them in a
local database. It provides server functionality so that
interested parts (HTTP and RTSP servers) can collect
information about ongoing sessions. The SDP descriptions are carried using a trivial transport protocol. The
announcement collector and the reflector should have
the same view of which multicast sessions are accessible. In other words, multicast scooping issues must be
taken into account when the announcement collector is
deployed. A simple but somewhat ineffective heuristic is to deploy it at the same host computer where the
reflector resides.
3.2.4 System Operation
Figure 3: RTSP server and other components in a distributed environment. Only Host 4 must reside on a
multicast network.
The RTSP control system and the reflector are depicted in Figure 3. Full double arrows represent TCP
based control protocols, dashed lines represent UDPbased RTP data flows. A typical usage pattern is as
follows6 . The HTTP server (at Host 2) announces the
multicast sessions collected by the Session Announcement Collector at Host 4. The sessions are presented in
a human intelligible form (e.g. name, author, description, timing). The user at Host 1 reads these announcements and selects a session. An RTSP URL is returned,
identifying the RTSP server and the session ID. The
HTTP client automatically starts the RTSP client with
this URL as parameter. The RTSP client informs the
RTSP server that the given multicast session should be
reflected to this computer at given unicast ports. The
RTSP server sets up the reflector session and informs
the RTSP client about the result. If the setup was successful, the RTSP client starts the needed media tools.
The RTSP client remains active during the session and
may be used to renegotiate parameters with the server
or close the media tools.
3.3 H.323 Control Unit
Another reflector control system we present is an H.323
Control Unit (CU) that uses our Reflector Session Protocol to control a collocated Multicast-Unicast Reflector. CU reacts on H.225 Call Processing primitives
(C ALL SETUP, R ELEASE etc.) issued by H.323 compliant equipment as if it was a regular H.323 end-point.
CU uses our RSP protocol to instruct the reflector to
join multicast groups and establish unicast RTP peering
with the H.323 unit that requested the connection. The
H.323 unit is in turn informed about the port it should
send the RTP packets to and any other connection parameters.
The H.323 Control Unit and the Multicast-Unicast
Reflector together constitute the H.323–Mbone Gateway.
Figure 4: H.323 Control Unit in the H.323–Mbone
Gateway
CU needs to map H.323 call IDs to IP multicast session in order to instruct the reflector to open the data
6A
prototype implementation of this system is available at
HTTP :// WWW. IFI . UIO . NO /∼ MECCANO / REFLECTOR /
channels. Semantic of these mappings is application
dependent; we show two examples in Section 4.
3.4 Scalability Considerations
Unicast extensions to IP multicast are not a replacement
for fully deployed multicast service. Scalability of the
reflector is inherently limited.
However, the architecture we presented can always
be deployed to cover the needs in any particular scenario. The increased bandwidth demands or the number of users can be matched by deploying a pool of reflectors with a single RTSP server which acts as a load
balancing element. When it comes to the scalability of
the H.323-Mbone Gateway, the connected H.323 unit
also needs to maintain an increasing number of pointto-point connections as the reflector does — their bandwidth and computing power requirements grow proportionally.
4
4.1.2 Satellite Networks
An example of the VPN issues we discussed in Section
2 is shown in Figure 6 and presents a real scenario we
tested within the EU project MECCANO [18].
Two bordering LANs (LAN1 and LAN2) are administratively in two separate autonomous systems (AS).
LAN2 and LAN3 are geographically displaced, but in
the same IP network. Receiver 1 receives a high-quality
IP multicast stream over the satellite link, based on
Unidirectional Link Routing [6] and Direct Broadcast
Satellite (DBS) technology [2].
D EPLOYMENT C ASES
We present different deployment strategies for our
Multicast-Unicast Reflector: two for solving multicast
network problems and three at application level.
Figure 6: IP multicast over satellite link. LAN2 and
LAN3 are in the same IP network, in AS2.
4.1 Network Level
4.1.1 Non-Multicast Networks
As discussed in Section 2, Internet Service Provider
supporting a number of PPP links (modem or ISDN)
would normally not provide direct multicast service to
its clients.
In Figure 5, an example network based on ISDN
links has no multicast support. A reflector is located on
a multicast network close to the ISDN router, enabling
the unicast-only terminals to join multicast groups efficiently e.g. using RTSP servers.
Figure 5: Connecting unicast terminals to Mbone over
low bandwidth ISDN links.
Router R2 cannot route multicast traffic on interface 1 to avoid the satellite link becoming data injector for the global multicast sessions present in AS1 and
AS2. It can, however, use the reflector to receive the
data stream from LAN1 instead of receiving it through
the Internet, where the media quality will probably be
degraded.
4.2 Application Level
4.2.1 Internet TV
Future Internet TV providers will probably use multicast services to distribute the video streams to their network Points of Presence. From there, unicast streams
can be sent to the consumers, since unicast streams
are much simpler to administer and bill than multicast.
This is particularly important for the commercial channels, as their unauthorized reception will be prohibited.
Our RTSP control system described in Section 3.2
can be used in this scenario without architectural modifications. Interactive WWW-based program overview
can be used to start video streams from a reflector at
the closest Point of Presence. The RTSP server can
be extended to assert viewing policies. Billing mechanisms and symmetric data encryption may be added
to the presented architecture.
4.2.2 H.323–Mbone Audio Gateway
The scope of IP multicast multimedia teleconferences
is limited by the low availability of the multicast service in common office and private networks. In particular, mobile users are left with low bandwidth unicast
IP service when they are on travel. Enabling use of
the regular telephone as a terminal for participation in
multicast conferences solves this problem. We present
a prototype that demonstrates how a cellular or PSTN
telephone call can be extended to a multicast IP network by use of the H.323–Mbone Audio Gateway, an
application of the general H.323–Mbone Gateway presented in Section 3.3.
Figure 8: Emulating MCU functionality: the gateways
are members of a single multicast group
5
Figure 7: H.323–Mbone Audio Gateway deployment
In Figure 7, an H.323–Mbone Audio Gateway is deployed as a gateway between the PSTN and Mbone,
enabling the users to dial in Mbone conferences from
any telephone in the world.
To make this scenario possible, a mapping between
telephone extensions and multicast audio sessions must
exist in the gateway. The mapping may be automatically generated and published as a WWW or WAP
page, or configured by a system operator. The user just
dials the gateway’s telephone number and the provided
extension number to join the audio conference.
4.2.3 Multipoint Control Unit Emulation
The H.323 Multipoint Control Unit (MCU) is generally
regarded as an inadequately scalable network component, due to the heavy requirements H.323 puts on its
functionality. The MCU functionality can be emulated
by configuring a number of H.323–Mbone gateways as
the members of the same IP multicast session, effectively providing a distributed MCU architecture (Figure 8).
Drawbacks of this architecture are possible loss of
other functionality that the standard MCU provides,
such as caller authentication, flow control etc. The distributed architecture based on H.323–Mbone Gateway
needs additional mechanisms to support this functionality.
P ERFORMANCE A NALYSIS
In this section we assess the performance of our
Multicast-Unicast Reflector7 . The purpose of this performance study is to identify possible bottlenecks in the
system and to determine sustainable bit rate for our implementation.
Our Reflector Session Protocol is a lightweight, textbased control protocol. Clients (e.g. RTSP or H.323
control units) issue requests based on user’s actions —
no periodic or other additional messages are sent. The
control traffic overhead is therefore assumed to be negligible compared to the data traffic.
The Multicast-Unicast Reflector forwards data unmodified. The total forwarding bit rate for a reflector
with n active channels with m1 , m2 , · · · , mn unicast
participants and no data loss is:
B=
n
X
(mi + 1)bi
(1)
i=1
where bi is bit rate of channel i, 0 < i ≤ n.
While (1) represents the ideal situation, the packets may be dropped due to the inability of the network interface(s) to handle the given traffic amount, or
the inability of the host computer to copy data quickly
enough from input buffer to the memory and back to
the output buffer at the network adapter.
5.1 Testbed Description
The Multicast-Unicast Reflector application is developed and run using Java Development Kit 1.1.8. The
reflector host is a Linux RedHat 6.2 Pentium III
600MHz PC with 128MByte RAM. We used 3Com
3C509 PCI Fast Ethernet adapters.
The reflector joins a single multicast channel8 , with
measured mean bit rate of 612 kbit/s. The bit rate varies
7 Source
code
may
be
downloaded
from
HTTP :// WWW. IFI . UIO . NO /∼ MECCANO / REFLECTOR /.
8A
Norwegian state TV broadcast (NRK1), coded in H.261 video
codec, video resolution 352x288 pixels, 25 frames/s.
in range 200-900 kbit/s, as shown in Figure 9. The
number of unicast connections have been progressively
increased. The unicast participants do not generate data
packets, but send periodic RTCP reports that can be
used to monitor the reception quality. We used the RTP
Quality Matrix tool [23] for this monitoring.
1000
900
800
Throughput (kbit/s)
700
600
Figure 10: Experiment setup, single network adapter.
~
Multicast and unicast traffic share the same link. M
~ the unicast flow.
depicts the multicast flow, U
500
400
300
200
100
0
0
10
20
30
Time (s)
40
50
60
Figure 9: Throughput as recorded in the reflector, mean
= 612 kbit/s. At bit rate of ∼750kbit/s, the singleadapter configuration starts throwing packets when 6
unicast receivers join; the double-adapter configuration
when 30 receivers join.
CPU and memory consumption of the reflector are
monitored in course of the experiment.
Fast Ethernet is used as the network infrastructure in
the experiment. The network is free of traffic noise.
The experiment is conducted in configuration with
one network adapter on the reflector host (the usual
configuration for most Internet hosts) and two adapters
so that the reflector host behaves as a application level
router.
for more than 80% time. Memory consumption does
not exceed 5% out of the available RAM.
5.3 Two Adapter Experiment
In this scenario, Network Adapter 1 at the reflector host
serves the multicast traffic, while Adapter 2 serves unicast flows to the receivers (Figure 11). In this configuration, up to 20 unicast participants receive all packets.
With 30 receivers, moderate packet loss (1-5%) occurs
when the bit rate exceeds approximately 750 kbit/s. Total throughput is ∼24Mbit/s, which is close to what can
be expected from the IO subsystem.
5.2 Single Network Adapter Experiment
The reflector host is connected to router R, as shown
in Figure 10. All unicast receivers are in the network
connected to interface 2 at the router, through a Fast
Ethernet switch.
The adapter starts to discard packets already when 6
unicast participants are attached. With 9 unicast participants, the packet loss varies between 0 and 20%, With
20 unicast receivers attached, the packet loss varies between 25 and 35%.
In all receivers, the packet loss varies synchronously
with the bit rate. At any given time, all receivers register similar packet loss. The packet loss reaches the top
when the bit rate is highest (peaks in Figure 9).
The CPU time consumed by the reflector application
has been always under 10%, while the CPU was idle
Figure 11: Experiment setup, double network adapter.
The reflector forwards an unidirectional data stream.
The link between the router and the FE switch is not
in use.
CPU usage with 30 receivers varies between 15 and
20%, while memory consumption is still less than 5%.
5.4 Conclusion from the Experiments
Having in mind the powerful network infrastructure for
this experiment, we conclude that the single network
adapter is the main performance constraint for the reflector. In the two adapter configuration, the achieved
bit rate is close to what may be expected from the IO
subsystem.
The reflector consumes a moderate amount of CPU
power. This leaves room for application level data processing (e.g. data encryption) if needed.
6
C ONCLUSION
Multicasting is a natural solution in many communication scenarios. Its successful use depends on both
network and application support.
Extending multicast networks with an efficient
multicast-unicast reflector is useful with respect to the
lack of multicast support on both network and application level. Combining reflector functionality with
well-known control protocols adds value to multicast
services and enhances user-friendliness.
In this paper we have presented a distributed
multicast-unicast reflector architecture together with
two control systems and five deployment cases. The
architecture is general enough to be deployed in various other scenarios.
We have supplied a set of requirements for the system architecture. Our prototype implementations meet
these requirements, have the desired functionality and
perform well.
We have presented several useful applications, including e.g. multicast audio conference dial-in from
cellular and PSTN telephones. We believe that these
applications may profile the IP multicast service in the
Internet society.
While the reflector has its performance limitations
on a single system, the total architecture is distributed
and scales well. For example, increasing demand for
bandwidth can be met by deploying a pool of reflectors
controlled by a single RTSP server. Thus, the server
acts as a load balancing element.
7
F UTURE W ORK
The described prototype could be extended in many
ways in order to match different needs. As an example, policy servers, data encryption and billing would
be needed in many possible commercial scenarios. Feasibility of these extensions is unquestionable, and we
regard them as engineering problems.
Communication within a pool of RTSP servers and
multicast-unicast reflectors would be more effective if
a local communication channel is available. Similarly,
the RTSP clients need to control media tools on the end
user’s computer. Both tasks can be accomplished using
Message bus (Mbus) technology. Details of this extension are still to be studied.
Effective load balancing mechanism in a configuration with a single RTSP server and many reflectors is a
subject for further study.
Announcement of call number extensions for the
H.323 Control Unit needs to be implemented. Possibilities we consider include WWW and WAP announcements as well as GSM messages (SMS).
In the MCU emulation, implementation of e.g. policing and flow control, which are supplied by the standard
H.323 MCU, is a subject for further study.
ACKNOWLEDGMENTS
We would like to thank the MECCANO project team
for numerous discussions and fruitful suggestions to
applications of the reflector. We would also like to
thank Dr. David Singer of Apple Computer for initial
ideas related to this work. We further thank professor
Stein Gjessing for helpful suggestions to improvements
of this paper. Tarik Cicic is supported by a PhD grant
from Uninett AS, the Norwegian Research and Education Network.
References
[1] Inc. Apple Computer. Darwin streaming server,
2000.
HTTP :// PUBLICSOURCE . APPLE . COM /PROJECTS / STREAMING /.
[2] H.D. Clausen, H. Linder, and B. Collini-Nocker.
Internet over direct broadcast satellites. IEEE
Communications Magazine, 37(6):146–151, June
1999.
[3] S. Deering, D. Estrin, D. Farinacci, V. Jacobson,
A. Helmy, D. Meyer, and L. Wei. Protocol independent multicast version 2 dense mode specification. Internet Draft, June 1999. draft-ietf-pimv2-dm-03.txt.
[4] Steve Deering. Host extensions for IP multicasting. RFC 1112, August 1989.
[5] Steve Deering. Multicast Routing in a Datagram
Internetwork. PhD thesis, Stanford University,
1991.
[6] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii,
and Y. Zhang. A link layer tunneling mechanism for unidirectional links. Internet Draft, April
2000. draft-ietf-udlr-lltunnel-04.txt.
[7] Hans Eriksson. MBONE: The multicast backbone. Communications of the ACM, 37(8), August 1994.
[8] D. Estrin, D. Farinacci, A. Helmy, D. Thaler,
S. Deering, M. Handley, V. Jacobson, C. Liu,
P. Sharma, and L. Wei. Protocol independent
multicast-sparse mode (PIM-SM): Protocol specification. RFC 2362, June 1998.
[9] D. Estrin, D. Meyer, and D. Thaler. Border gateway multicast protocol (BGMP): Protocol specification. Internet Draft, March 2000.
[10] D. Farinacci, P. Lothberg, D. Meyer, Y Rekhter,
H. Kilmer, and J. Hall. Multicast source discovery
protocol (MSDP). Internet Draft, February 2000.
[11] M. Handley and V. Jacobson. SDP: Session description protocol. RFC 2327, April 1998.
[12] M. Handley, H. Schulzrinne, E. Schooler, and
J. Rosenberg. SIP: Session initiation protocol.
RFC 2543, March 1999.
[13] ITU. Call signaling protocol and multimedia
stream packetization for packet-based multimedia
communication systems. ITU Recommendation
H.225, February 1998.
[14] ITU. Packet-based multimedia communication
systems. ITU Recommendation H.323, September 1999.
[15] Mathias Johanson. RTP translator R EFLEX.
Swedish Institute for System Development, January 2000.
[16] Dirk Kutcher and Jörg Ott. The message bus.
White Paper, January 2000. HTTP :// WWW.MBUS . ORG.
[17] Inc.
Live
Networks.
livegate,
2000.
HTTP :// WWW. LIVEGATE . COM / LIVE G ATE /.
[18] MECCANO.
Telematic
for
research
project
4007,
1998-2000.
HTTP :// WWW- MICE . CS . UCL . AC . UK /MULTIMEDIA / PROJECTS / MECCANO /.
[19] University of Oslo. Reflector session protocol
(RSP) specification, 2000. HTTP :// WWW. IFI .UIO . NO /∼ MECCANO / REFLECTOR /RSP. HTML .
[20] H. Schulzrinne, S. Casner, R. Frederick, and
V. Jacobson. RTP: A transport protocol for realtime applications. RFC 1889, January 1996.
[21] H. Schulzrinne, A. Rao, and R. Lanphier. Real
time streaming protocol (RTSP). RFC 2326, April
1998.
[22] Henning Schulzrinne.
RTP translator RTP TRANS, August 1999.
HTTP :// WWW. CS .COLUMBIA . EDU /∼ HGS / RTP /.
[23] Computer
Science
Department
University College London.
Mbone conferencing applications, 2000.
HTTP :// WWWMICE . CS . UCL . AC . UK / MULTIMEDIA / SOFTWARE /.
[24] D. Waitzman, C. Partridge, and S.E. Deering.
Distance vector multicast routing protocol. RFC
1075, November 1988.