Managing Group Dynamics and Failures in QoS Multicasting

Article (PDF Available) · July 2002with18 Reads
Source: CiteSeer
Abstract
The recent proliferation of QoS-aware group applications over the Internet has accelerated the need for scalable and efficient multicast support. In this article, we present a multicast "life-cycle" model which identifies the various issues that are involved in a typical multicast session. During the life-cycle of a multicast session, three important events can occur: group dynamics, network dynamics, and traffic dynamics. The first two aspects are concerned with maintaining a good quality (e.g., cost) multicast tree taking into account member join/leave and changes in the network topology due to link/node failures/additions, respectively. The third aspect is concerned with flow, congestion, and error control. In this article, we examine various issues and solutions for managing group dynamics and failure handling in QoS multicasting and outline several future research directions.
1
Managing Group Dynamics and Failures in
QoS Multicasting
A. Striegel and G. Manimaran
Dependable Computing & Networking Laboratory
Department of Electrical and Computer Engineering
Iowa State University, USA
adstrieg@iastate.edu gmani@iastate.edu
Abstract
The recent proliferation of QoS-aware group applications
over the Internet has accelerated the need for scalable and
efficient multicast support. In this article, we present a mul-
ticast “life-cycle” model which identifies the various issues
that are involved in a typical multicast session. During the
life-cycle of a multicast session, three important events can
occur: group dynamics, network dynamics, and traffic dy-
namics. The first two aspects are concerned with maintain-
ing a good quality (e.g., cost) multicast tree taking into ac-
count member join/leave and changes in the network topol-
ogy due to link/node failures/additions, respectively. The
third aspect is concerned with flow, congestion, and error
control. In this article, we examine various issues and solu-
tions for managing group dynamics and failure handling in
QoS multicasting and outline several future research direc-
tions.
Keywords QoS multicasting, QoS routing, Group dynam-
ics, Fault-tolerance, Tree rearrangement, Core migration,
DiffServ
I. Introduction to Multicasting
The phenomenal growth of group communications and
QoS-aware application over the Internet have acceler-
ated the need for scalable and efficient network sup-
port [1], [2]. These group applications include video-
conferencing, shared workspaces, distributed interactive
simulations (DIS), software upgrading, and resource loca-
tion. The traditional unicast model is extremely inefficient
for such group-based applications as the same data is un-
necessarily transmitted across the network to each receiver.
The difference between multicasting and separately uni-
casting data to several destinations is best captured by
the host group model [3]: “a host group is a set of net-
work entities sharing a common identifying multicast ad-
dress, all receiving any data packets addressed to this mul-
ticast address by senders (sources) that may or may not be
members of the same group and have no knowledge of the
groups’ membership”. This definition implies that, from
the sender’s point of view, this model reduces the multi-
cast service interface to a unicast one. Thus, the multicast
model was proposed to reduce the many unicast connec-
tions into a single multicast connection for a group of re-
ceivers.
The multicast definition also allows the behavior of the
group to be unrestricted in multiple dimensions: groups
may have local (LAN) or global (WAN) membership, be
transient or persistent in time, and have constant or vary-
ing membership. Consequently, we have the following types
of multicast (or host) groups:
dense groups which have members on most of the links or
subnets in the network, whereas sparse groups have mem-
bers only on a small number of widely separated links.
open groups are those in which the sender need not be
a member of the group, whereas closed groups allow only
members to send to the group.
permanent groups are those groups which exist forever or
for a longer duration compared to the duration of transient
groups.
static groups are those groups whose membership re-
mains constant in time, whereas dynamic groups allow
members to join/leave the group.
A. Life-cycle of a Multicast Group
A network architecture that aims to provide complete
support for multicast communication is burdened with the
task of managing the multicast session in a manner trans-
parent to the users. This goal of transparent multicast
service imposes specific requirements on the network im-
plementation. To demonstrate the different functionalities
that such a network must provide, Figure 1 shows the var-
ious steps and events that can take place in the “life-cycle”
of a typical multicast session. The sequence of phases/steps
relevant to the multicast session are (i) multicast group
(session) creation, (ii) multicast tree construction and re-
source reservation, (iii) data transmission, and (iv) multi-
cast session tear-down.
B. Multicast Group Creation
The first step in the creation of a multicast session is
the assigning of a unique address to the multicast group
such that the data of one group does not clash with other
groups. Both groups and addresses have associated life-
times. Similar to groups, group addresses are classified as
either static or dynamic, depending on whether they are as-
signed permanently to a given group, or assigned to differ-
ent groups at different instants of time. The most obvious
matching between groups and addresses is to assign static
addresses to permanent groups and dynamic addresses to
transient groups. Note that assignment of static addresses
to transient groups could result in insecure communication
(wherein non-members receive messages meant for a cer-
2
Session
Tear-
Migration
Core
gement
Traffic
Control
COLM
Routing
life-time expires
Regulate/
adapt
problem
Arbitrate
Multiple senders
Node/link failure
Session
degrades
quality
Core
Reconfigure
graft/prune
Tx
New
center
degrades
quality
Tree
Rearranged
tree
Data Trans
-mission
down
Reser-
vation
Session
Control
Rearran-
Tree Failure
Handling
join/leave
Resource
tree
Multicast
Multicast
Routing
identifier
Group
Group
Creation
Multicast call request
established
Session
Fig. 1. Life-cycle of a multicast session
tain group) whereas assignment of dynamic addresses to
permanent groups merely causes unnecessary communica-
tion overhead.
C. Multicast Tree Construction & Resource Reservation
Once the group is created, the next phase in the mul-
ticast session is the construction of a multicast distribu-
tion tree, spanning the source(s) and all the receivers (QoS
routing), and reserving resources on the tree. Multicast
route determination is traditionally formulated as a prob-
lem related to tree construction. There are three reasons
for adopting the tree structure:
The source needs to only transmit a single packet down
the multicast tree.
The tree structure allows parallel transmission to the var-
ious receiver nodes
The tree structure minimizes data replication, since, the
packet is replicated by routers only at branch points in the
tree.
It has been established that determining an optimal mul-
ticast tree for a static multicast group can be modeled as
Steiner problem in networks which is shown to be NP-
complete [2]. A number of algorithms have been developed
using heuristic-based approaches such as KMB and TM
(discussed in [2]). An additional dimension to the multi-
cast routing problem is the need to construct trees that will
satisfy the QoS requirements of modern networked multi-
media applications (delay, delay jitter, loss, etc.).
QoS routing and resource reservation are two important,
closely related issues. Resource reservation is necessary
for the network to provide QoS guarantees - in terms of
throughput, end-to-end delay, and delay jitter - to multi-
media applications. Hence, the data transmission of the
connection will not be affected by the traffic dynamics of
other connections sharing the common links. Before the
reservation can be done, a tree that has the best chance
to satisfy the resource requirements must be selected. Re-
source reservation and tree construction are discussed fur-
ther in Section III.
D. Data Transmission
Once the above two phases have been completed success-
fully, data transmission can begin. During data transmis-
sion, the following four types of run-time events can occur:
Group dynamics: Since group membership can be dy-
namic, the network must be able to track current member-
ship during a session’s lifetime. Tracking is needed both
to start forwarding data to new group members and to
stop the wasteful transmission of packets to members that
have left the group (identified as COLM (Constrained On-
Line Multicast) routing in Figure 1). As a result of group
dynamics, the tree quality may degrade and may neces-
sitate re-optimization (identified as Tree Rearrangement).
For core-based trees, a similar degradation may occur that
may necessitate a change in the core node (identified as
Core Migration).
Network Dynamics: During the life-time of a multicast
session, if any node or link supporting the multicast session
fails, service will be disrupted. This requires mechanisms
to detect node and link failures and to reconfigure (restore)
the multicast tree around the faulty links/nodes (identified
as Failure Handling in Figure 1). Note that multicast rout-
ing protocols based on underlying unicast routing protocols
are as survivable as the unicast routing protocol. If the
multicast routing protocol is independent of the unicast
routing protocol, it must implement its own restoration
mechanism [5].
Transmission problems: This could include events such
as swamped receivers (needing flow control), or faulty
packet transmissions (needing error control). The traffic
control mechanism, working in conjunction with the sched-
ulers at the receivers and the routers, is responsible for per-
forming the necessary control activities to overcome these
transmission problems (identified as Traffic Control in Fig-
ure 1).
Competition among Senders: In a many-to-many mul-
ticasting, when multiple senders share the same multicast
tree (resources) for data transmission, resource contention
occurs among the senders. This will result in data loss
due to buffer overflow, thus triggering transmission prob-
lems. This requires a session control mechanism that arbi-
trates transmission among the senders. (identified as Ses-
sion Control in Figure 1).
3
E. Group Tear-Down
At some point in time, when the session’s lifetime has
elapsed, the source will initiate the session tear-down pro-
cedures. This involves releasing the resources reserved for
the session along all of the links of the multicast tree and
purging all session-specific routing table entries. Finally,
the multicast address is released and group tear-down is
complete.
As is evident from the life cycle of a multicast session,
the multicasting problem contains many interesting issues.
Rather than covering all of the issues associated with mul-
ticasting, this article focuses on two of the key areas from
the life cycle, group dynamics and failure recovery. The
rest of the article is structured as follows. Section II dis-
cusses an overview of multicast routing protocols. Section
III investigates QoS multicast routing from the perspective
of group dynamics. Next, Section IV examines the motiva-
tion for fault tolerance in multicasting and the implications
for QoS multicast routing. Finally, in Sections V and VI,
we make several concluding remarks and comment on open
areas of research.
II. An Overview of Multicast Routing
Protocols
Multicast routing protocols can be classified into two
main approaches: source-based protocols and center-based
protocols. The source-based approach uses the notion of
a shortest path tree (SPT) rooted at each source node.
The SPT is typically obtained by concatenating shortest
paths from the source to each receiver. Since the short-
est path is usually the shortest delay path, the receivers
in the multicast tree typically receive excellent delay per-
formance. However, source-based trees introduce scalabil-
ity problems for large networks as each individual source
must have a separate tree constructed, spanning all the re-
ceivers, rooted at the source node. Source-based routing is
currently employed in Distance Vector Multicast Routing
(DVMRP), dense-mode Protocol Independent Multicast-
ing (PIM-dense), and Multicast Open Shortest Path First
(MOSPF) [4].
The other type of protocols, center-based or shared-tree
protocols, construct a multicast tree spanning the members
whose root is the center or core node. These protocols are
highly suitable for sparse groups and are scalable for large
networks. However, just as shortest-path trees provided
excellent QoS at the cost of network bandwidth, shared
trees provide excellent bandwidth conservation at the cost
of poor QoS to the receivers. The Core Based Tree (CBT)
[6] is a well-known example of a shared tree routing pro-
tocol. When a node wishes to transmit a message to the
multicast group in the CBT protocol, it sends the mes-
sage towards the core. The message is distributed to group
members along the path to the core and then the message
is distributed to the remaining members once it reaches
the core. Requests to join or leave the multicast group are
processed by sending the request towards the group core.
When a join request reaches an on-tree node, the on-tree
node becomes the point of attachment for the new node.
Conversely, when a node leaves a group, the part of the
tree that does not support any members is pruned.
Recently, several hybrid routing protocols have been pro-
posed which allow receivers to switch from a shared-tree to
a shortest-path tree. Protocols such as sparse-mode PIM
(PIM-sparse) and Multicast Internet Protocol (MIP) are
examples of hybrid routing protocols [4].
III. Managing Group Dynamics
The QoS of the multicast tree (receiver-perceived QoS)
is not solely affected by the multicast routing protocol.
Rather, the QoS of the multicast tree is a function of group
dynamics which includes the following issues:
QoS-aware routing
Tree rearrangement
Core/tree migration
Figure 2 summarizes the issues that will be discussed in
the following sections.
A. QoS-aware Routing
A multicast tree is incrementally constructed as members
join and leave a group. When an existing member leaves
the group, it sends a control message up the tree to prune
the branch that no longer has active members. When a
new member joins the group, the tree must be extended to
cover it. The dynamic QoS multicast routing problem can
be informally stated as:
Given a new member M
new
, find a path from M
new
to an
on-tree node that satisfies the QoS requirements of M
new
.
The QoS requirements can be classified into link con-
straints (e.g., bandwidth) or path constraints (e.g., end-to-
end delay or path cost). The optimization problem with
two or more path constraints is known to be NP-complete
[2]. Many practical instances of QoS routing problems have
at least two path constraints and hence, most QoS multi-
cast routing protocols employ heuristic solutions.
In addition to satisfying the QoS requirements of the re-
ceiver, a good QoS-aware multicast routing protocol should
aim at:
improving the probability of successful join
minimizing the cost of the joining path
minimizing the joining time
being scalable to large networks
Based on how the new member is connected to the tree,
multicast routing protocols can be classified into two broad
categories: single-path routing (SPR) and multiple-path
routing (MPR). An SPR provides a single path connecting
the new member to the tree, whereas an MPR provides
multiple candidate paths.
Most SPR protocols were originally designed for best-
effort traffic. Well known examples are CBT and PIM
wherein a new member i is connected to the multicast tree
along the unicast shortest path from i to the core/source
of the tree. The unicast path is typically the shortest path
in terms of hop length which is good for best-effort traffic.
However, such a shortest path may not have the required
resources to support the QoS needs of the member. Sev-
eral SPR protocols such as DCUR and RDM [7] have been
4
MulticastGroup
Dynamics
QoSofexisting
members
QoSofnew
members
TreeType
Routing
Method
ShortestPath
SharedTree
Hybrid
SinglePath
MultiplePath
Tree
Rearrangement
Core/Tree
Migration
QualityMonitoring
RearrangementScheme
CoreSelection
TreeConstruction
Tree/MemberMigration
Fig. 2. Issues in Multicast Group Dynamics
proposed for QoS unicast routing which can be used for
multicast routing as well. These protocols typically use
delay and cost tables for making routing decisions during
QoS path setup.
In contrast to SPR protocols, MPR protocols provide
or probe multiple candidate paths in order to increase the
chances of finding a feasible path (i.e., a path that satis-
fies the QoS requirements of the member). Among these
candidate paths, the best path is selected. Spanning-join,
QoSMIC, QMRP, and parallel probing are among the re-
cently proposed MPR protocols [8], [9] (and the references
therein).
Spanning Join: In the Spanning-join protocol, the new
member broadcasts join-request messages in its neighbor-
hood to find on-tree nodes. Upon receiving the join-request
message, the on-tree nodes reply to this message and the
member chooses the best on-tree node to connect to from
the set of on-tree nodes that have replied.
QoSMIC: In QoSMIC, the search for candidate paths
consists of two parallel procedures: local search and tree
search. The local search is equivalent to spanning-join,
except that only a small neighborhood is searched. The
tree search handles the case when there is no on-tree node
in the neighborhood checked by local search. In the tree
search, the new member contacts a designated Manager
node which is responsible for ordering a subset of on-tree
nodes to establish a path from them to the member. Each
such path is a candidate path. The new member then se-
lects best path out of these candidate paths.
QRMP: The QMRP protocol consists of two sequential
procedures: single-path mode and multiple-path mode.
The protocol starts and continues with single-path mode
until it reaches a node that has insufficient resources to
satisfy the join request. When such a node is encountered,
the protocol switches to multi-path mode.
Parallel Probing: This protocol was originally proposed
for QoS unicast routing and can be adapted to multicast
routing. The objectives of the protocol are to minimize the
path setup time and to minimize the resource reservation
along the multiple candidate paths. To achieve this, the
member sends multiple probes, using different heuristics
for each probe, to an intermediate destination (ID). Upon
receiving the first probe message, the ID initiates a paral-
lel probe to the next ID. Upon receiving later probes, the
ID releases the resources reserved between the ID and the
previous ID (or member) by those later probes.
Although the above mentioned protocols do take into ac-
count some of the above requirements, none of the above
listed protocols are designed to take into account all the
requirements of a good multicast routing protocol. For
example, Spanning-join and QoSMIC are not scalable to
the Internet because of high message overhead due to their
flooding nature. Whereas, QMRP has the same problem in
multiple-path mode, QMRP also incurs a high joining time
due to its sequential invocation of multi-path mode from
single-path mode. Although parallel probing takes into ac-
count many of the stated goals, its effectiveness primarily
depends on the selection of intermediate destinations.
B. Tree Rearrangement
In a dynamic multicast session, it is important to ensure
that member join/leave will not disrupt the ongoing multi-
cast session, and the multicast tree after member join/leave
will still remain near-optimal and satisfy the QoS require-
ments of all on-tree receivers [2]. One way to handle dy-
namic member join/leave is by reconstructing the tree ev-
ery time a member joins or leaves the session. This in-
volves migration of on-tree nodes to the new tree which
may result in a large service disruption that may not be
tolerable, especially by QoS multicast sessions. Another
way to handle dynamic member join/leave is by incremen-
tally changing the multicast tree through the graft/prune
mechanism. This incremental change approach suffers be-
cause the quality (e.g., tree cost) of the tree maintained
may deteriorate over time. Therefore, an on-line multicast
routing algorithm must take into account two important
and possibly contradicting goals [10]: cost-reduction and
minimization of service disruption. Thus, a balance needs
to be struck between these goals by employing a technique
that monitors the quality of the tree or portion of the tree
and triggers tree rearrangement when the quality degrades
below a threshold. The tree rearrangement mechanism is a
means by which balance can be struck between these goals
[10].
C. Core & Tree Migration
Another significance of tree maintenance is in core-based
multicasting. In core-based multicasting, core selection is
5
an important problem because the location of the core in-
fluences the tree cost and delay. The quality (e.g., cost)
of the tree based on the current core may deteriorate over
time due to dynamic join and leave of members, i.e., the
core degenerates [11] with time. The maintenance of a
good quality multicast tree requires online selection of a
new core, online construction of a multicast tree based on
the new core, and migration of the members from the old
multicast tree to the new multicast tree.
Core migration can also be invoked as part of core failure
recovery when the current core fails. A number of heuris-
tics have been proposed in [12] for core selection. Also,
several algorithms have been proposed for multicast tree
construction of core-based trees (references in [2]). The is-
sues in core migration frequently involve tradeoffs which
are discussed below:
Tradeoff - Invocation of Core Migration: Maintaining a
good quality tree requires frequent core migration, but in-
curs service disruption and overhead. Thus, there exists
a tradeoff between (i) minimizing service disruption and
overhead and (ii) maintaining a good quality tree (i.e.,
cost). The triggering mechanism for core migration is crit-
ical for capturing the tradeoff between service disruption
and quality of the tree.
Tradeoff - Multicast Tree Construction: During tree con-
struction, again there exists a tradeoff between cost of the
tree and service disruption.
Tradeoff - Tree Migration: During tree migration, there
exists a tradeoff between service disruption and resource
wastage (i.e., the amount of resources overallocated mo-
mentarily during core migration). In other words, more
resource wastage may result in less service disruption and
vice-versa.
IV. Failure Recovery in QoS Multicasting
A communication network failure can have an adverse
effect on today’s society. In the future, as more applica-
tions employ multicast routing, a strong need will emerge
for algorithms that can be employed by survivable multi-
cast routing protocols [5]. Although faults may seem un-
common, the chance of faults is higher than one might ex-
pect. For example, it was recently observed that the Inter-
net occasionally experiences periods of routing instability,
also known as routing flaps, when network can lose con-
nectivity as floods of routing updates are processed. This
network instability could lead to timeouts that result in
transient faults. Moreover, fault handling is even more im-
portant in mobile and multi-hop adhoc networks wherein,
as the mobile host moves, the connectivity of the network is
likely to change and the structure of the multicast tree may
break. Therefore, multicast protocols must be equipped
with mechanisms to survive or detect and recover from
link/node failures. In order for them to be widely deploy-
able, these mechanisms need to take into account several
design considerations, such as scalability, fast recovery, and
minimizing protocol overhead.
The most important aspect of failure recovery is to min-
imize service disruption. For unicasting, one type of failure
Core Failure Recovery
Global RecoveryCore Selection &
Tree Construction
Local Recovery
Core Evaluation
& Tree Constrn.
Core/Tree
Migration
Multicast TreeMain & Candidate
Cores Selection Construction
Fig. 3. Issues in Core Failure Recovery
handling approach is the protection based approach wherein
dedicated protection mechanisms, such as backup paths,
are employed to cope with failures. This approach is more
suitable for hard real-time communication wherein every
packet is critical. The other type is the restoration based
approach wherein, on detection of a failure, an attempt
is made to reroute (restore) the path around the faulty
nodes/links with minimal service disruption.
With multimedia multicasting, the problem is much
more complicated than with unicasting, as resource reser-
vations are shared and group dynamics interact with net-
work reconfigurations. Very little is known as to how to
deal with such problems [1]. The use of the protection
based approach for multicasting is prohibitively expensive
in terms of resource usage as it requires one or more backup
trees for each primary tree, and hence not scalable. More-
over, for dynamic groups, this approach does not suit well
as the structure of the tree itself changes with time. There-
fore, it is more appropriate to use the restoration based
approach.
A. Failure Recovery in Core-Based Multicasting
With regard to core-based multicasting, the main prob-
lem is that it has a single point of failure at the core. If
the core fails, then the whole multicast session would be
disrupted. To provide reliable multicast services, the mul-
ticast routing protocols need to be equipped with mecha-
nisms for handling core failures as well as node/link fail-
ures.
Figure 3 details several of the issues associated with core
failure recovery. Core recovery may be further subdivided
into the following areas:
Core Selection & Tree Construction: A new core must
be selected from a list of candidate cores with a multicast
tree that minimizes service disruption and tree cost.
Local Recovery: Once a core failure or link/node fail-
ure has occurred, recovery may take place on a local scale
whereby nodes contact other nearby nodes and perform
local rerouting.
Global Recovery: In the event of a severe failure, it may
be necessary to globally recover the multicast group. For
these instances, the new core must be evaluated and the
members of the multicast tree must be migrated to the
new tree.
For core based trees, there has been some work for
link/node failure recovery. The original specification [6]
6
for core based trees included a mechanism for recovering
from link or node failure. In order to resolve the problem
of loop formation, the protocol specification of core based
trees was modified to eliminate the possibility of generat-
ing loops during failure recovery via flushing. Although
the flushing modification eliminated loop formation, it had
several drawbacks:
substantial time in rebuilding the tree.
substantial overhead if the number of members in the
subtree is large.
overhead at on-tree nodes may be high when processing
many simultaneous join requests.
Another protocol was proposed recently in [13] with the
aim of applying the flush operation less frequently. Al-
though this protocol has a reasonably high success rate of
restoring the tree without using the flush operation, it in-
curs a high message overhead and recovery time due to
more message exchanges.
V. Targeting Towards Next-Generation QoS
Architectures
Most of the QoS multicasting solutions discussed in this
article are well suited for per-flow QoS architectures such
as Integrated Services. However, the adaption of these so-
lutions to aggregation-based QoS architectures such as Dif-
ferentiated Services (DiffServ) is non-trivial due to several
architectural conflicts as given below [14].
DiffServ requires that the core routers be stateless
whereas multicasting relies on per-group (per-flow) state
information at all nodes in the multicast tree.
DiffServ employs sender-driven QoS whereas multicast-
ing typically employs receiver-driven QoS for accommodat-
ing heterogeneous members.
The issues of managing group dynamics and failures are
further compounded due to the distributed nature of de-
cision making by the edge routers in a DiffServ domain.
Moreover, an additional complexity arises when provid-
ing end-to-end QoS across multiple DiffServ and/or non-
DiffServ domains. In summary, the integration of DiffServ
and multicasting is an important and relatively unexplored
area and requires significant research attention.
VI. Conclusions
In this article, we first outlined the various issues in mul-
ticast communication through tracing the life-cycle of a
multicast session. Then, we focused on two key issues,
namely, managing group dynamics and failure recovery.
These issues have a profound impact on QoS multicast
routing and the QoS experienced by the end user. For
these issues, we identify the following important research
problems:
Join/Leave QoS Routing: Although significant work has
been done in QoS routing, the currently proposed schemes
do not meet all of the goals of a good multicast routing
protocol. Thus, further research is needed in developing
such schemes that provide better performance on both an
intra- and inter-domain routing scale.
Tree Maintenance: Tree rearrangement, has received sig-
nificant attention [10] in the recent past and needs further
research [2]. The management of group dynamics in an
integrated manner addressing all of the subproblems (QoS
routing, Tree rearrangement, and Tree migration) is an im-
portant problem for further research.
Core & Tree Migration: Though there has been some
work [11], [12] on online core evaluation, to the best of
our knowledge, there is no work on tree migration taking
service disruption aspect into account (Currently, the effect
of changing the core on data loss is not well-understood
[12]).
Failure Recovery: As of today, very little work ([13] for
link/node failure in core-based trees) has been done on fail-
ure recovery in multicast communication and hence this
topic needs further research [5].
Interaction with QoS Architectures: As discussed in Sec-
tion V, the interactions of multicasting with QoS architec-
tures need further research.
Besides group dynamics and failure handling, other is-
sues such as traffic control and session control have many
interesting problems which bear future research.
References
[1] J.C. Pasquale, G.C. Polyzos, and G. Xylomenos, “The multimedia
multicasting problem,” Multimedia Systems, vol.6, no.1, pp.43-
59, 1998.
[2] J. Hou and B. Wang, “Multicast routing and its QoS extension:
Problems, algorithms, and Protocols,” IEEE Network, Jan./Feb.
2000.
[3] D.R. Cheriton and S. Deering, “Host groups: A multicast exten-
sion for datagram internetworks,” in Proc. Data Communications
Symposium, pp.172-179, 1985.
[4] M. Ramalho, “Intra- and Inter- domain multicast routing pro-
tocols: A survey and taxonomy,” IEEE Commuications Surveys
and Tutorials, vol.3, no.1, pp.2-25, Jan.-Mar. 2000.
[5] L. Sahasrabuddhe and B. Mukherjee, “Multicast routing algo-
rithms and protocols: A tutorial,” IEEE Network, Jan./Feb.
2000.
[6] T. Ballardie, P. Francis, and J. Crowcroft, “Core-based trees
(CBT): An architecture for scalable inter-domain multicast rout-
ing,” in Proc. ACM SIGCOMM, pp.85-95, 1993.
[7] R. Sriram, G. Manimaran, and C. Siva Ram Murthy,“Preferred
link based delay-constrained least cost routing in wide area net-
works,” Computer Communications, vol.21, no.18, pp.1655-1669,
Nov. 1998.
[8] S. Chen, K. Nahrstedt, and Y. Shavitt, “A QoS-aware multicast
routing protocol,” IEEE INFOCOM, pp.1594-1603, 2000.
[9] G. Manimaran, H. Shankar Rahul, and C. Siva Ram Murthy,
“A new distributed route selection approach for channel estab-
lishment in real-time networks,” IEEE/ACM Trans. Networking,
vol.7, no.5, pp.698-709, Oct. 1999.
[10] R. Sriram, G. Manimaran, C. Siva Ram Murthy, “A rearrange-
able algorithm for the construction of delay-constrained dynamic
multicast trees,” IEEE/ACM Trans. Networking, vol.7, no.4,
pp.514-529, Aug. 1999.
[11] C. Donahoo and Zegura, “Core migration for dynamic multicast
routing,” in Proc. ICCCN, 1995.
[12] E. Fleury, Y. Huang, P.K. McKinley, “On the performance and
feasibility of multicast core selection heuristics,” in Proc. Intl.
Conf. on Computer Communications and Networks, pp.296-303,
1998.
[13] L. Schwiebert and R. Chintalapati, “Improved fault recovery for
core based trees,” Computer Communications, vol.23, no.9, Apr.
2000.
[14] A. Striegel, G. Manimaran, “A Scalable Protocol for Member
Join/Leave in DiffServ Multicast,” to appear at Proc. of IEEE
LCN’2001, Tampa, Florida, Nov. 2001.
    • "In this method, it is difficult to determine the number of channels needed to provide the desired QoS. In [9], [10], [11], [12], [13], various issues to manage group dynamics, resource reservation, allocation of resources and admission control in multicast applications are examined . Dynamic group management is critical as members can join and leave the group at any instant of time. "
    [Show abstract] [Hide abstract] ABSTRACT: The tremendous growth of the Internet paradigm has given rise to Quality of Service (QoS) problems in heterogeneous, ubiquitous, distributed real time applications such as video-on-Demand (VoD). The challenging task in VoD applications is to satisfy diverse client requests for discrete videos with restrained resources by invoking versatile QoS schemes. In this paper, a hybrid QoS strategy, which is a combination of batching and recursive patching is implemented in the local server to en- sure starvation-free resource management thereby enhancing the throughput. Batching shares network resources efficiently whereas recursive patching is adopted to reduce the time difference between the requests. The suggested algorithm delivers the complete video to the users based on one of the three communication channels: broadcast, multicast and unicast depending on whether the video is very popular, average popular and least popular respectively. The experimental results show that our strategy accomplishes 35% - 40% reduction in terms of blocking ratio and throughput is 10% - 15% higher than the Poon's strategy, which guarantees that not only the resources are efficiently utilized but also a suitable Quality of Service is provided to each user.
    Full-text · Article · Jan 2007
    • "QoS routing consists of determining a path through the network which has adequate resources to satisfy the QoS requirements of a connection, while simultaneously achieving global efficiency in network resource utilization. QoS routing can be classified into unicast routing and multicast routing [28] [33] [36] [41] [43] [51] [77] [78] [82] [83] [91] [102] [103] [106] [122] [128] [133] [135] [142] [143] [145] [147] [152] [155] [158] [159] [161] [163] [166]. It can be further classified as intra-domain routing and inter-domain routing. "
    Article ·
  • [Show abstract] [Hide abstract] ABSTRACT: The migration of classic Internet to support real time and multimedia applications (videoconference, VoIP) require improvement of the network level service. Since several real-time and multimedia applications are multicast, our interest is to integrate Diffserv and multicasting in order to satisfy QoS requirements of the multicast group. The problem on which we are concentrating in this paper is related to providing QoS requirements for multicast applications using Diffserv and principally on overload traffic, which may be created by replication of multicast packets in Diffserv domain. In this case, the policing component in Diffserv routers may perform dropping packets and because core routers are working by aggregation, thus other traffic (the rest of traffic) may be affected. In this paper, we present a new protocol called control for QoS-based multicasting in Diffserv (CQMD) to resolve the multicast and Diffserv integration problem. This paper shows under what conditions the new member can be accepted into the multicast group in Diffserv domain. In addition CQMD can achieve QoS-satisfaction, ensure protection for other traffic in the Diffserv domain, good resources management and incur less message overhead.
    Conference Paper · May 2003
Show more