DESIGN OF MInP MULTICAST ROUTING PROTOCOL

Daniel Emilio Lopez Garibay

A thesis subnitted in conformity with the requirements

for the degree of Master of Applied Science

Graduate Department of Electncal and Cornputer Engineering

University of Toronto

@Copyright by Daniel Lopez 2000

National Library I*I of Canada Bibliothèque nationale du Canada

Acquisitions and Acquisitions et Bibliographie Services services bibliographiques

395 Wellington Street 395. nie Wellington Ottawa ON K I A ON4 Ottawa ON K1A ON4 Canada Canada

The author has granted a non- L'auteur a accordé une licence non exclusive licence dowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, loan, distribute or sel1 reproduire, prêter, distribuer ou copies of this thesis in microform, vendre des copies de cette thèse sous paper or electronic formats. la forme de microfiche/nlm, de

reproduction sur papier ou sur format électronique.

The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts &om it Ni la thèse ni des extraits substantiels may be printed or otherwise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation.

DESIGN OF MInP MULTICAST ROUTING PROTOCOL

Daniel Emilio Lopez Garibay

Master of Applied Science, 2000

Gnduate Department of Electrical and Cornputer Engineering

University of Toronto

ABSTRACT

Many multimedia applications, such as video conferencing, require the transmission of

information ffom multiple sources to multiple destinations. The y require the continuous

flow of multimedia data to be processed and exchanged. Multimedia information is

subject to Quality of Service (QoS) delivery constraints such as available bandwidth and

bounded delay. This QoS-sensitive information requires the underlying multicast

protocol to find a QoS constrained communication tree. Most multicast protocols do not

consider the QoS requirements of the application in cornputing the distribution tree.

We propose MInP, a new QoS-sensitive Multicast Routing Protocol based on selective

probing for packet-switching networks. The protocol is fully distributed and depends on

the local States maintained at every individual node. Through simulations, we compare

the simulated performance of MInP with existing protocols, such as P M , DVMRP and

CBT. The performance metrics include end-to-end delay, network processing usage, and

O verhead traffic percentage.

Acknowledgements

1 would like to express my gratitude to my supervisor, hofessor Irene Katzela. for her

advice, guidance. support and encouragement throughout the course of this project.

1 would also like to thank my cornmittee members, Professor Kostas Plataniotis.

Professor Jinwoo Choe, Professor Eddie Law and Professor Andreas Veneris for

reviewing my thesis and providing al1 the helpful çornments.

1 also want to pratefully acknowledge the financial support of CONACYT (Mexico) in

performing this research.

Saving the best for the last, 1 am deeply indebted to my wife, my daughter, my parents,

my brother, my sister and a11 my family for their love. endless emotional support and

caring.

i i i

Contents

Introduction

.................................................................... 1.1 Muitimedia Tzchnology

1.2 Quality of Service Requirements ...................................................... .............................. 1.3 Network Design Issues for Multimedia Support

. . ................................................................. 1.4 Multicast Comunrcatron

.............................................................................. 1.4.1 Definition

.................................................................... 1 A.2 Multicast Model

.......................................................... 1.4.3 Multicast Applications

........................................................ 1.4.4 Multicast Design Issues

1 A.41 Multicast Routing ...................................................... 1.4.4.2 Group Management ...................................................

............................................................................ 1.5 Problem Statement

................................................................................ 1.6 Thesis Objective

......................................................... 1.7 Thesis Organizat ion

Quality of Senice Multicast Routing

Quality of Service Routing ............................................................... ............................................... Quality of Service Routing Problems

2.2.1 Unicast Routing ..................................................................... .................................................................. 2.2.2 Multicast Routing

Routing S trategies ............................................................................. 2.3.1 SourceRouting ...................................................................... 2.3.2 Distnbuted Routing ............................................................... 2.3.3 Hierarchical Routing .............................................................

.......................................................... Multicast Routing Algorithm

2.4.1 Source Routing Algorithms ..................................................

............................................ 2.4.2 Distributeci Routing Algonthms

.............................................................. 2.5 Multicast Routing Protocols

2.6 Sumrnary .....................................................................

Multicast Inter-domain Protocol (MInP)

3.1 Overview ............................................................................................. 3.2 Net~vorkModel ...................................................................................

. . .......................................................................................... 3.3 Description

............................................ 3.3.1 Quality of Service Requirements

.............................................................. 3.3.2 Multicast Forwarding

..................................................................... 3.3.3 Candidate Search

....................................................... 3.3.4 Connection Establishment

3.3.4.1 new-node is a receiver ................................................. 3 A4.2 new-node is a source ...................................................

3.3.5 State Update and Refresh ........................................................ 3.4 Surnmary

Simulation Results

................................................................... 4.1 Implementation Overview

............................................................... 4.1.1 Protocol Cornparison

.......................................................................... 41.2 Graph Models

4.1.2.1 MBone ......................................................................... 4.1.2.2 Waxman .......................................................................

................................................................. 4.1.2.3 Hierarc hical

......................................................... 4.1.3 Simulation Environment

............................................................................ 4.2 Experiments Results

.............................................. 4.2.1 End-to-End Delay Performance

..................................................... 4.2.2 Network Processing Usage

4.2.3 Overhead Trafic Percentage ................................................... 4.3 S u m a r y .............................................................................................

Conclusions . .

5.1 Contributions ... .. .. .. .. .. .. .. . . .. .. .... .. .. . . .. ..- ..... .. .. -... .. .. .... .. ...-.. .. . ..- .. .. .. .. . . .. .. 5 2 Future Work. .. .. .. .. .. .. .. .. .. ... . .- .. .. ...- -... .. .... .. .. .. .... .. .. ... ... .. .. ... . .. .. .... .... .... .

List of Tables

Table 1 . 1 . Multicast applications characteristics .................................... 10

Table 2.1 : An example showing the global state in distance vectors at node A . 22

Table 3.1. The roles of the different routers .......................................... 48

Table 3.2. Available Bandwidth and Delay characteristics of the links in G .... 50

Table 3.3. Sequence of join requests for the network G of Figure 3.2 ............ 50

Table 4.1. Properties of network topologies .......................................... 74

Table 4.2: The end-to-end delay obsewed by receiven in seconds using the

uniform delay distributions ................................................. 76

vii

List of Figures

Figure 1.1: An example showing how multicast packets flood the network links

Figure 1.2: An example showing how a series of unicast cm be used to perforrn

mu lt icas t ing ................................................................................. ....... Figure 1.3: An exarnple showing how a tree efficient ly performs rnulticast

Figure 7.1: An example showing the global state in link state protocols at any

Figure 2.2. An example showing the widest path fkom A to H ...................... Figure 2.3: An example showing the bandwidth-constrained paths from A to H.

with a bandwidth requirement of at least 1.5. .......................................... ................. Figure 2.4: An example showing the least-delay path From A to H

Figure 2.5: An example showing the delay-constrained paths from A to H. with

a delay requirement of at most 7 ......................................................... Figure 2.6: An example showing the bandwidth constrained least-delay path

kom A to H. with a bandwidth requirement of at least 2 ............................. Figure 2.7. An example showing the least-cost tree from A to D. E. and H ....... Figure 2.8: An example showing the delay-constrained tree from node A to

nodes D. E. and H. with a delay requirement of at most 7 ........................... Figure 2.9: An examp le show ing the de lay-constrained least -cost tree fro m

............... node A to nodes D. E. and H. with a delay requirernent of at most 8

Figure 3.1 : An overview of MInP ........................................................ ............... Figure 3.2: An exarnple showing the States kept at the in-tree nodes

Figure 3.3: An exarnple of a network G and the embedded current multicast

tree T ................... ,,.,. ............................................................... .................. Figure 3.4: An example showing the Candidate Search procedure

viii

Figure 3.5: An example showing the states kept at the in-tree nodes after a

receiver member joins the multicast tree T.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3.6: An example show ing the states kept at the in-tree nodes after a

receiver member leaves the multicast tree T... . . . . .. .. . . .. . .. , . . . . . ... ... . .. . .. . . . . .... Figure 3.7: An example showing the states kept at the in-tree nodes aher a

source member joins the multicast tree T .... .. ......................................... Figure 3.8: An example showing the states kept at the in-tree nodes after a

source member leaves the mukicast tree T.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . Figure 4.1: Intemet dornain structure ......... .. .... .. .... ..... ... .. .. . .. .... .. ... . . . . .. Figure 4.2: Fraction of nodes below an end-to-end performance value using the

uniform delay distnbution: MBone graph.. . . . . .. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4.3: Fraction of nodes below an end-to-end performance value using the

uniform delay distribution: Waxman flat Euclidean graphs (node degree 3.08) ... Figure 4.4: Fraction of nodes below an end-to-end performance value using the

uniform delay distnbution: Waxman flat Euclidean graphs (node degree 3.54) ... Figure 4.5: Fraction of nodes below an end-to-end performance value using the

uni form delay distribut ion: Waxman flat Euclidean graphs (node degree 5.52). .. Figure 4.6: Fraction of nodes below an end-to-end performance value using the

uni form delay distribution: Hierarchical graph.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Figure 4.7: End-to-end delay performances relative to M W . . . . . . .. . ... . . . . . . . . .... Figure 4.8: Network processing usage relative to MInP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4.9: Overhead percentage cornparison. .. .... .. .. . . . . . . . . . . . . . . .. .... .. . . . . . . . . .

Chapter 1

Introduction

Multimedia computing. communications and applications are playing an important role

on today's Intemet, therefore, are areas of intense current interest and development.

Computer networks used to carry cornputer data only. Today, they are also used for

Intemet telephony, multimedia conferencing, transmission of lectures and meetings,

distance learning, distributed simulations. network games. collaborative environments,

and other applications that invo lve multiple users.

Whereas traditional Intemet applications, such as the World Wide Web (WWW). File

Transfer Protocol (FTP). or Telnet, cannot tolerate packet loss and are less sensitive to

variable delays, most multimedia applications can compensate for reasonable amount of

packet loss but are usually very sensitive to delays. These multimedia applications are

bandwidth intensive and real-time in nature, If real-time data does not arrive in time,

such as in case of congestion, it becomes obsolete. As a consequence. real-time

applications deliver poor quality during periods of congestion.

Multimedia applications are not solely point-to-point. with a single source and a single

destination. Instead, they are most often multipoint applications where users often need

to send the same information to severai, but not necessarily all, destinations Iocated on

different networks, and hence the importance of multipoint communication. This

multipoint communication is much more efficient than one-to-one communication in

terms of resources usage.

Multimedia applications are characterized by a wide range of bandwidth specifications

and real-t ime performance requirernents, kno wn as Qualit y of Service (QoS) parameters,

which must be provided by the underlying network. The QoS parameters of these

applications are generally expressed in terms of end-to-end delay, delay-jitter, loss rate,

bandwidth, etc. A multipoint protocol that considers QoS metncs to select routes can

create distribution trees better suited to the transmission needs of multimedia

applications. While traditional best-effort routing have its dynamic performance subject

to the current availability of shared resources.

The QoS agreement between an application and the network is simple. and can be

negotiated and maintained in point-to-point communication. but this task becomes very

dificult when considering multipoint communication. Several techniques have k e n

proposed to support point-to-multipoint routing [l] but few explicitly support QoS

routing, and less support QoS multipoint-to-multipoint routing. It is clear that the

provision of an efficient multipoint-to-multipoint protocol in a distributed multimedia

environment is crucial to the success of rhese applications.

1.1 Multimedia Technology

Advances in computer technology and data communication have resulted in a new

genention of high-speed computer networks that can achieve speeds of up to a few

terabits per second (Tbps), dong with very low bit error rates. The progress in cornputer,

audio, video, and data storage technologies has given nse to new distributed real-time

applications. Efficient compression techniques provide feasible and cost-effective

solutions. Inexpensive microprocessors capable of performing billions of instructions per

second are readily available. Multiprocessor technology is quickly matunng, rnaking it

possible to hrther irnprove computer speed. In addition, the capacity of data storage

devices has improved considerably. All these new advances are making it easier to

support powerful applications with high-processing requirements and large storage

requirements.

Concurrently, a tremendous improvement in networking technology has k e n taking

place. Local Area Networks (LAN), once limited to a few megabits per second (Mbps),

are now supporting transmission speeds in excess of a gigabit per second (Gbps). These

speed improvements have k e n coupled with an increase in the reliability of network

links. Furthemore, optical switches. which won't need to convert optical signals to

electricai ones, are currently being developed. Therefore, these developments will allow

the deplo yment of very high speed networking environments in the near future.

The above technological advances have blurred the lines between computing, switching,

and digital transmission equipment. Digital cornputer network technology can now be

used to transmit both continuous and discrete data. This has paved the way for the rapid

development of a new class of multimedia applications involving the processing, stonng,

and communication of text, images, audio and video in integrated fashion. Video

conferencing, multimedia mail, online shopping, and distance leaming are but a few of

the wide range of current and future distributed multimedia applications. The

proliferation of these new applications brings out new challenges in the design and

development of communication networks.

1.2 Quality of Service Requirements

Multimedia applications impose strong requirements on the underlying network. They

require the continuous flow of large volumes of multimedia data to be processed and

exchanged. A key property of multimedia data is its time dependency. For example,

video and audio streams can tolerate certain loss rates, but they have stnngent end-to-end

delay and delay-jitter requirements, while data strearns requires very low loss rates, but

are tolerable to end-to-end delay and delay-jitter. In a real-time session. the upper bound

on end-to-end delay represents the maximum acceptable end-to-end delay along any path

kom source to destination. The delay-jitter bound gives the maximum difference in

delay that cm be tolerated between source and destination. Another critical resource to

be managed rffectively in order to meet the requirements of multimedia applications, is

network bandwidth. For example, high bandwidth must be guaranteed in order to

accommodate the high transmission rates of real-time video. Depending on the nature of

applications, a user may require multipoint services to fulfill a single QoS parameter or a

combination of several. The need for a bounded end-to-end delay and guaranteed

bandwidth has k e n well justified in the open literature.

Multimedia transmission requires resource reservation and guarantees. A request for

reservation for later resource guarantees is defined through QoS parameters. which

correspond to the requirernents of the multimedia trafic. The reservation must be done

along the path between the communicating nodes.

Mdressing and efficiently supporting the quality of service requirements of different

applications in an integated environment represent a major challenge faced by network

infrastructure components supporting multimedia systems and applications.

1.3 Network Design Issues for Multimedia Support

Networks are driven by the trafic of the applications they suppon, therefore, they must

be designed to accommodate the requirements imposed by these applications. It is clear

that multimedia applications will generate a very large part of the trafic that will be

c d e d by Future networks.

As stated above. the performance requirements of multimedia applications span a wide

range in t e m of bandwidth (throughput), reliability, delay-jitter, and delay

characteristics. The support of these new applications often requires that a level of

performance requirements be guaranteed. A guarantee is a contract between an

application and the service provider to satisfy a requested level of QoS requirements.

With the advent of multimedia applications, the focus of the communication network has

shifted from initial emphasis on reliable delivery of text to include support for QoS

requirements ot' continuous multimedia data. Complex control algorithms and

sophisticated routing, scheduling, and resource allocation rnechanisms are needed to

support the bandwidth and QoS requirements in a context where the network

transmission speed are increasing at a rate faster than the processing speed. Thus, the

network control algorithms and protocols must be sufficiently simple to operate at or near

link bandwidth speeds. but be flexible enough to support applications with different QoS

requirements. For exarnple, in conferencing applications, the video and audio from the

rarious participmts shouid k c~ntrolled and distrihuted. If the receivers have different

capabilities. the network may be required to distribute information strearns for difierent

qualities and bit rates.

The %est effort" pûradigrn offered by the current datagram service. which proved to be

very successful in the realization of the Intemet. is not adequate to support real-time

trafic. The network protocol offers no guarantees about timely, reliable. and ordered

delivery of packets. At the same time, circuit switching, which is the standard method for

providing real-tirne performance. does not optimize the utilizat ion of the network

resources. and may be very inadequate for variable bit-rate applications.

To address real-time requirernents for multimedia applications in an efficient manner and

to provide network performance guarantees, two approaches can be used. The first

approach is to over-engineer the network to the extent that an application is certain to get

the resources it needs. Thus, the applications can be unconstrained in their resource

usage and still receive the guaranteed level of performance. In a high-speed network. this

approach would require a prohibitively large amount of resources. The second approach

involves the monitoring and controlling of resource allocation and usage for each

application. This approach requires that an application specifies its resource needs a

priori, and unless its needs can be met; it is blocked or rejected.

In order to support the requirements of multimedia applications, the network architecture

should provide a basic hmework upon which applications with widely varying traffic

requirements cm receive satisfactory service. Building such an architecture reqiiires the

investigation of multiple design issues. These issues can be divided as follows:

Flow speci fication: The network and the app Iications require a cornmon language to

specify the requirements for transmitting real-time data. A source transmitting real-

time data need to inform the network of its QoS requirements.

Admission Control: Since the network resources are finite, the network cannot accept

211 conr?ection requert s while maint ain ing QoS requirements. The network has to

verify that there are enough resources before accepting any request.

Path Establishment and Routing: The network needs to decide which route to pick to

send the packets of a session. Selecting a route is harder for real-time

communications where there are some requirements on the QoS that have to be

satis fied.

Policing: In order to venfy that applications conform to their specified rates. a

policing mechanism is needed at the cdge of the neiwork. By preventing an

offending application From excessively ut ilizing the network resources, the likelihood

that this application negatively affects other application's QoS is great ly reduced.

A very important aspect of multimedia applications, which will play a major role in their

successful deplo yment. is multipoint communication. Multimedia applications may

require group communication between multiple end-points. Multimedia conferencing,

cornputer-supported collaborative work, and distance Iearning are typical examples of

multimedia applications, where a host may receive data From multiple sources while it

also sends data to multiple receivers.

Support for rnultipoint communication will play a prominent role in the fùture as the

deployrnent of multipoint-based applications will continue to grow. It is, therefore,

important that network developers be aware of the design issues related to rnultipoint

communication in order to avoid impact ing the performance of the multimedia

applications.

1.4 Multicast Communication

1.4.1 Definition

Multicast is the capability of delivenng a packet to multiple receivers such that exactly

one copy of the packet traverses each link in the distribution tree. A multicast-enabled

network m~s t , therefore, allow any host to transmit a single copy of a packet to a

multicast address and have the packet be delivered to the dispersed members of the

multimedia communication group.

It is important to efficiently support multicast communication in a computer network.

The current approach to improve efficiency of resource usage by a multicast session is to

construct a multicast distribution tree, which spans the group members in a session. A

single copy of a message is sent From the source to the multiple receivers over

communication links shared by the paths to the receivers. Duplication of information is

only performed at the forks in the tree defined for the multicast communication. Sending

only a copy saves bandwidth on links and reduces congestion in the network layer. The

information is sent in parallel to the receivers dong the branches of the tree, improving

the average latency from the sources to the receivers.

The realization of multicasting is not an easy task. The routing system must be made a

aware of which networks have hosts participating in each multicast group, so that the

amival of a multicast-addressed packet can triggered proper forwarding to the destination

networks. To avoid multiple replications of multicast packets by multiple routers, a

spanning tree of routen is constructs as part of the multicasting algorithm, to route and

duplicate multicast packets.

The Intemet has been providing an IP rnulticast routing service for some time now,

through an Intemet seDrnent called MBone [2]. MBone is a collection of routers running

an implementation of the Distance Vector Multicast Routing Protocol (DVMRP) [3].

The popularity and availability of multicast applications has lead to a phenomenal growth

of the multicast backbone or MBone. The MBone is Iayered on top of the Intemet's

unicast topology, and the connections between the MBone's routers are provided by the

same links that are used for the usual applications. As multicast packets are forwarded

From one MBone router to another. they are b?unneled", so that to intermediate non-

multicast routers they look Iike regular unicast trafic.

The host group mode1 proposed by Deering [4] for representing multicast sessions is

adopted by sevenl multicast protocols. It defines a multicast group as the set of receivers

of a multicast session. A unique group class D address identifies a multicast group. The

use of a unique address allows logical addressing, so a source only needs to know the

group address in order to reach al1 receivers. It does not need to know the address of the

individual receivers. To send messages to a group, sources specify the destination of the

messages with the multicast address of the sroup. In addition. the source itself need not

to be member of the multicast group. Logical addressing is beneficial for applications

with large number of sources and receiven. such as mailing lists or newsgroups, and for

dynarnic applications, such as cornputer-supported cooperative work, where receivers

may join or leave at any time and sources may start or stop transmission to that group at

any tirne.

Intemet Group Management Protocol (IGMP)[S] is a protocol for managing Internet

multicasting groups. It is used by applications to join and leave a particular multicast

group. The basic service permits a source to send datagrarns to ail members of a

multicast group. There are no guarantees of the delivery to any or al1 destinations in the

P U P .

Mult icast routers periodicall y send [GMP host membership query messages to update

their knowledge of mernberships present on a particular network. If no reports are

received for a particular group after sorne number of queries, the routers assume the

group has no local members, and that they do not need to fonvard multicast traffic for

that group ont0 the LAN. Othenvise, hosts respond to a query by generating an IGMP

host rnembership report message, reporting each host group to which they belong on the

network interface from which the query was received.

IGMP queries are normally sent intiequently, so as to keep the IGMP overhead on host

and routen very low. However, when a multicast routers starts up. it rnay issue several

queries to quickly build up its knowledge of local membership. When a host joins a

multicast grououp. it should immediately send a report for that group, rather than wait for a

query message.

For any LAN. there is a designated router (DR) to act on behalf of the end hosts on the

LAN to start. join. or leave a multicast session and to fonvard multicast packets of a

multicast session. A simple election mechanisms suffices to select the DR. e.g., the

router with the largest IP address becomes the DR.

1.4.3 Multicast Appücations

Cooperative work scenarios using multimedia conference systems are the main

application areas of multimedia cornmunicat ion systems. These systems should support

multicast connections to eficiently use resoumes. In addition. a user should be able to

join or leave a multicast group without having to request a new connection setup, which

needs to be handled by a11 other members of this group.

A multicast application is defined as any application that sends one or more data strearns,

namely video. audio, and text, to a multicast network address. Applications that require

support for multicasting include distance learning, audio and video conferencing,

interactive James, cooperative work. replicated file systems, distributed databases, and

real-time control applications.

Multicasting is not Iimited to multimedia applications. It is also used to support non-real-

time applications. For example, multicasting is often used for synchronization,

replication and coherency in non-real-tirne distributed databases. Another aspect of

distributed systems is the replication of data in order to provide some form of fault

tolerance. For example, in a file system where multiple distributed copies of data exist,

mult icasting provides a very convenient mechanism to update the file s ystem' s replicated

copies in a single operation. It also eases the tasks of rnaintaining data coherency and

resource location by contacting and updating multiple servers concurrently.

Multicast communication brings out challenging network issues that require the

development of new network protocols and components to support routing and group

management.

Type of Application 1 Bandwidth (bps) Real-time

File System

1 Audio Con ference 1 4-64K 1 Yes 1

Distributed Database

10K- 1M

I

Whiteboard 1 1K-lM Yes 1

No

1-1OM

Video Con Fer ence

No

Table 1.1 : Multicast applications characteristics

2-34M

Broadcast Emuiation

1.4.4 Multicast Design Issues

Yes

Two key issues are Fundamental to multicasting: Multicast routing and rnulticast group

1-1OM

management. Multicast routing requires the establishment of a multicast tree to allow

No

multicast group members to exchange data efficiently and ensure that the requirements of

the underlying multicast applications are met. Group management allows members to

dynamically join and leave a multicast group. Furthemore, some applications require

support for expedient join and Ieave operations, as their specifications are sensitive to the

latency involved in joining and leaving a group.

1.4.4.1 Multicast Routing

A rnulticast algorithm is a method to select routes connecting a set of resources belonging

to a given session to the set of receivers of the same session. Multicast algonthms

construct a multicast distribution tree by setting up a state in the rnulticast routing tables

of the routerr in the network. Thece tables maintain the pointers to neighbors to which

multicast packets are forwarded in order to reach their destinations.

A multicast routing protocol describes how to implement a theoretical routing algorithm

in practical networks. Support for multicast routing within the scope of a single LAN is

simple. Broadcast LANs include the provision of multicast address at the medium access

control level. Hosts can be configured to be a member of a selected set of multicast

groups. Group members take advantage of the broadcast nature of the LAN to exchange

data by transmitting a single copy of the data Frame to the multicast group. Upon

recognition of its multicast group oddress, a host captures and forwards the transmitted

kame to upper layer protocols. Usually multicast groups are statically set up and can be

changed only by a reconfiguntion of the network.

Multicast trees c m be classified into source-specific trees and shared trees. Source-

specific multicast trees constmct a one-to-many multicast tree for each source, whereas

shared rnulticast tress construct only one multicast tree to cany the trafic flowing from

any number of sources to any number of destinations. The construction of a shared

multicast tree consists of two parts: the center location part and the route selection part.

On the other hand, the construction of a source-specific multicast tree requires only the

selection of proper routes.

Multicasting is far more complex to support in a wide-area network (WAN) that a shared

LAN. Hosts rnust be able to join and leave the network without necessarily requiring the

intervention of the network service provider. Furthemore, multicast routen rnust be able

to identify and locate members of the multicast group. An efficient multicast routing

strategy must, therefore, efficiently transmit multicast trafic to al1 of the intended

receivers.

In the pst . several techniques have been proposed to suppon multicast routing [2].

FIooding provides the simplest way to achieve this by transrnitting a packet fkom a source

to every node in the network. This scheme guarantees that the nodes involved in the

p u p communication will receive the transmitted packet. When a node receives a packet

that is addressed to a multicast group. it ernploys a protocol mechanism to determine

whether it is the Fust time that it has seen this particular. If it is the Fust reception of the

packet, the packet is forwarded on al1 interfaces except the one on which it arrived. If the

node has seen the packet before. it is simpl y discuded.

The scheme, however, does not scale for Intemet applications and lead to a large waste of

bandwidth, because every node within the network receives the transrnitted packets and

nodes may receive multiple copies of the same packet. Also. it makes inefficient use of

node memory resources since each node is required to rnaintain a table entry for each

recently seen packet. For example. in Figure 1.1 twelve copies are sent to ensure that

each node in the network receives a copy of the packet.

source a destination

G H

Figure 1.1: An example showing how multicast packets flood the network links.

Multicasting can also be implemented by copying the onginal packet in the source node

and then transrnitting these copies to the multicast destinations using a series of unicasts.

However, this solution is usually undesirable for two reasons. Fust, large portions of the

network resources are wasted because multiple copies are independently sent to each

destination. Second, performing a serialized number of unicasts from the source makes it

harder to rneet the delay bounds. For example, in Figure 1.2 unicasts are used to send

data h m source -4 tc destinations D: E, F: and H. As a result. four copies are sent on

link ( A D ) and two copies on link (D,F). Even though the multicast data m y reach the

destinations, this type of implementation leads to inefficient utilization of network

resources.

source 0 destination

Figure 1.2: An example show ing how a series of unicast can be used to perform

multicasting

A more effective solution would be to select a subset of the Internet topology that forms a

distribution tree. To achieve this, a distribution tree connecting a source and al1

destinations must be constructed. Each packet goes through this tree and an adequate

number of copies is made at each branching point of the tree to ensure every destination

receives a copy. The routing algorithm in this case allows only one copy of the multicast

group to traverse each link of the distribution tree. In this method, significant network-

layer enhancements rnust be made to the packet copy Functions at the nodes. Once the

tree has been built. a node sirnply fonvards each multicast packet to aii interfaces rhat are

part of the distribution tree except the one on which the packet anived. Forwarding dong

the branches of a tree guarantees that the multicast packet will not loop and that it will

eventually reach al1 the destination nodes. For example in Figure 1.3 a single copy is sent

on link (A,D) as opposed to four copies if unicasting is used. This leads to more efficient

utilization of the network resources. Also, it reduces the overhead on the network links

since each network node receives at most one copy of the multicast group.

source 0 destination

Figure L .3: An example showing how a tree efficiently performs multicast.

The multicast strategy rnust determine the multicast distribution tree, which includes

rnembers of the multicast group. The source transmits a single packet dong the tree

which is then replicated by routers oniy at branch points of the multicast distribution tree.

Furthemore, the multicast strategy must take into consideration the dynarnic behavior of

group memberships of the multicast tree. The multicast distribution tree cm be either

static or dynamic. In a static multicast tree. members of the multicast group remain

connected for the whole duration of the multicast session. In a dynarnic rnulticast tree,

however, group members may join and leave the multicast tree dynamically.

Current implernentations of multicast routing algorithms are based on the least-delay

source to destination tree which is not efficient in utilizing network resources. That is

because using the least-delay paths does not optirnize the sharing of the network Iinks. In

order to support the wide range of QoS requirements of multipoint multimedia

applications and maximize the utilization of network, more efficient communication

mec hanis ms are necessary.

1.4.4.2 Group Management

Multicast applications such as distance education, remote collaboration, and

tekcûnfcnncing are usually dynamic in nature. They respire the M i t y to support

dynamic join or leave operations. There can be a large number of join and leave

operations in a short time. Designing a multicast routing algorithm for such applications,

requires supporting dynarnic join and leave operations without affecting the progress of

current multicast members. That is, the join of leave operations need to be performed

transparently to the current members. The management of the group membership in a

multicast environment is referred as online multicasting.

Group management in a rnulticast environment brings about new challenges that need to

be addressed. The strategy used to add new members to the rnulticast tree must assure

that the bounds on the network delay, suffered by packets transmitted dong the multicast

tree are not violated. When a node joins a multicast tree. branching nodes dong the new

path must be capable of replicating incorning multicast packets without violating the

delay bounds of currently supported multicast nodes. Another challenge that need to be

addressed is to avoid creating loops within the multicast tree when new multicast group

members are added.

1.5 Problem Statement

Much of the ongoing work related to Quality of Service support of multimedia

applications focuses on point-to-point communication [6]. However, there are additional

problems with multicast communication where the unicast solutions are not necessarily

extendable to multicasting. For exarnple, while it is easy to deterrnine an optimal route

for unicast communications, it has been shown that doing the same for multicast

communication is NP-complete [7]. Also, supporting QoS requirements for multicast is

more difficult than for unicast because there are multiple receivers as opposed to one

receiver in unicast communication.

Another aspect of the multicasting problem focuses on the issued that arise when the

nodes join or leave a multicast session dynarnically. This involves many additions and

deletions to the multicast session over time. Support for expedient join and leave

operztims hnngs a h u t fiew challenges that need to he addressed. As nodes join and

leave the group communication. the multicast tree rnay need to be updated or modified.

Hence the routing algorithm that builds the tree connect ing the multicast nodes should

maintain efficient connections between the nodes when the other nodes join or leave a

multicast session.

1.6 Thesis Objective

Given the need to support group communication in IP environrnents and to build efficient

mult icast communication, the objective of the thesis is the design a multipoint routing

protocol that satisfies the requested QoS and scales well to large network sizes.

The following are the issues that this thesis address to support QoS multipoint

cornmunicat ions:

Performance guarantees: Multimedia applications have stringent requirements on the

underlying network. These requirements are expressed by the QoS parameters, such

as end-to-end delay, bandwidth, loss rate, and delay-jitter. In a communication

network, delay consists of processing, propagation, and queuing. Propagation delay

is a fixed value per link in a network regardless of the link utilization. The bandwidth

specifications reflect the quantitative and qualitative characteristics of the

app iication's trafic. The quantitative bandwidth specification de fines the

application's average or maximum bandwidth requirements, while the qualitative

c haracteristics speci fy the traffic's burstiness of t r m c generation pattern. There fore.

the routing protocol rnust select a route that guarantees the required bandwidth and

end-to-end delay bound, if one exists.

FIexibiIity: The multicast routing protocol should support the requirements of the

different types of applications. It should also work with existing networks without

requiring modifications to the curent unicast and broadcast algorithms. Such protocol

should provide a baie Framework upon which other network layers and applications

with different QoS requirements can receive satisfactory service.

Efficiency: It is also important to maintain the efficiency when the protocol satisfies

the QoS requirements. A tree composed of the shortest-delay paths to the

destinations would give the shortest-delay tree. However, the overall cost or

overhead over the network can be high.

Dynamic Group Mernberships: Members hip in a multicast multimedia application

cm be dynamic. New members may join the multicast tree and other members may

leave. These changes may impact the topology and QoS characteristics of the

multicast tree. Consequently, an efficient multicast protocol must deal with online

changes in an efficient manner so that the actual delay observed by existing and new

members is not violated and the overall cost of the tree is rninirnized.

Asymmetry: Due to packet queuing and processing time, the delays on both the

fonvard and backward links between any two network nodes may not be the same.

The network in this case is not symmetric. The multicast routing problem for

asyrnmetric networks is more complex than for symmetric networks. Protocols

designed for symmetric networks are not guaranteed to work well for asymrnettic

ones. On the other hand, protocols that give good results in asyrnmetnc networks are

expected to give good results in symmetric networks as well.

First in Chapter 2, we will give a survey of previous work on Quality of Service (QoS)

multicast routing algorithms and protocols, where the problem is to find a QoS-

constrained multicast tree, which covers all senders and receivers.

in Chüpter 3, we wili give an ovrrvirw and &scribe the &tails on the design of MIRP. a

protocol for the Intemet that supports QoS multicast applications.

In Chapter 4, we describe the irnplementation of iWnP and introduce the simulation

platform, the Network Simulator (NS), in which we have implemented MInP. We

present Our measurements and compare the performance of MInP with the existing

multicast routing protocols, such as DVMRP, PIM-DM, PIM-DM and CBT.

In Chapter 5. we summarke the results of this thesis and suggest avenues for hrther

work.

Chapter 2

Quality of Service Multicast Routing

The main objective of this chapter is to give a survey of previous work on Quality of

Service (QoS) multicast routing algonthms and protocols, where the problem is to find a

constrained multicast tree. S uch multicast distribution tree covers al1 senders and

receivers, with every intemal path ftorn the senders to the receivers satisfying the QoS

requirements.

In the current Intemet. data packets of a session rnay follow different paths to the

destination. The network resources are fairly shared by packets from different sessions.

However, this architecture does not meet the requirements of future integrated networks

that will carry heterogeneous data traffk. First, it does not support resource reservation,

which is vital for the provision of guaranteed end-to-end performance. Second, data

packets may experience unpredictable delays and arrive at the destination out of order,

which is undesirable for continuous real-time media.

The notion of QoS has ken proposed to capture the qualitatively or quantitatively

defined performance contract between the network and the user applications. In QoS

multicast routing, the QoS requirements of a connection are given as a set of tree

constraints. A tree constraint specifies the QoS requirements for the entire multicast tree.

A bandwidth constraint of a multicast connection requires, for exarnple, that the links

composing the tme must have certain amount of free bandwidth available. The delay

constraint of a multicast connection requires that the Iongest end-to-end delay from the

sender to any receiver in the tree must not exceed an upper bound.

A feasible tree is one that has sufficient resources to satisfy the QoS requirements of a

connection. The basic function of QoS multicast routing is to find such feasible tree. In

addition, most QoS routing algorithms consider the optimization of resource utilization

measured by an abstract metnc, cost. The cost of a link can be defined in dollars or as a

function of the buffer or bandwidth utilization. The cost of a tree is the total cost of al1

links on the tree.

The problem of QoS multicast muting is unique for a number of reasons. First.

distnbuted applications such as Internet phone and distributed ;ames have very diverse

QoS constraints on delay, delay-jitter. bandwidth and so on. Multiple constraints often

make the routing problem intractable. For example, finding a feasible path with two

independent path constraints is NP-complete [7]. Second, any future integrated services

network is likely to carry both QoS and best-effort traffic. which rnakes the issue of

performance optimization complicated. It is hard to determine the best operating point

for both types of traffic if their distributions are independent. Although the QoS traffic

will not be affected due to resource reservation. the throughput of the best effort traffic

will suffer if the overall traffic distribution is rnisjudged. Third. the network state

changes dynamically due to transient load fluctuation. connections in and out, and links

up and down. The growing network size makes it increasingly difficult to gather up-to-

date state information in a dynamic environment. The performance of a QoS algorithm

or protocol can be senously degraded if the state information used is outdated.

2.1 Quality of Service Routing

Every link and node in a network has a state measured by the QoS metrics of concem. In

this thesis, the node state is rneasured combined into the state of the adjacent Links. So

the residual bandwidth is the minimal of the link available bandwidth and the

transmission rate; the delay of a link consists of the link propagation, transmission, and

the queuing delay at the node; the cost of a link is determined by the total resource

consumption at the link and node.

Routing consists of three basic tasks. The fust task is to collect the state information and

keep it up to date. The second task is to find a feasible path for a new connection based

on the collected information. The thrd task ensures that the information follows the

assigned route. The performance of any routing algorithm directly depends on how well

the first task is solved. The maintenance of the state information could be:

Local. where each node is assumed to maintain its up-to-date local state, including the

queuing and propagation delay, the available bandwidth of the outgoing links, and the

avaiiability of the other resources.

Global. where every node is able to maintain the global state by either a link state

protocol [S.9] or a distance vector protocol [10.L Il. which exchanges the local states

among the nodes periodically. Link state protocols broadcast the local state of every

node to every other node so that each node knows the topology of the network and the

state of rvery link (Figure 1.1).

(brindwidth, delay)

Figure 2. L: An example showing the ;loba1 state in link state protocols at any node.

Distance vector protocols periodically exchange distance vectors among adjacent nodes.

A distance vector has an entry for every possible destination. consisting of the property of

the best path and the next node on the best path. (Table 2.1)

TaDie 2.1: An example showing the global state in distance vestors a nodc A.

The global state kept at every node is always and approximation of the current network

state due to the non-negligible delay of propagating local States. As the network size

grows. the imprecision increases.

H

C

3 rn

C

3.3

2.2 Quality of Service Routing Problems

G

C

The routing problems can be divided into two major classes: unicast routing and

multicast routing. What differentiates multicast applications from unicast application is

the relationship between sources and receivers that multicüst communication enables.

F

C

2.2.1 Unicast Routing

In unicast routing, the QoS optimizations or requirements must be applied to the entire

path. For some QoS metncs such as available bandwidth and residual buffer space. the

state of a path is determined by the state of the bottleneck link. For example, in Figure

2.2, the bandwidth of the path (A,C,G,H) is 3, which is the bandwidth of the bottleneck

link (A,C). For these QoS metrics, two basic routing problems are defined:

D

D

C

C

Destination

Next Hop

Link-optimization routing problem. An example is bandwidth optirnization routing,

which is to find a path that has the largest bandwidth on the bottleneck link. Such a path

is called the widest path [12].

E

B

B

B

3

C

2

2

D

3

3

C

1

Bandwidth

Next Hop

Delay

3

C

4.3

2

D

5.5

2

D

5

(bandwidth, delay)

Figure 2.2: An example showing the widest path from A to H.

Link-constrained rout ing pro blem. An example is bandw idth-constrained routing, w hic h

is to find a path whose bottleneck bandwidth is above a required value.

(bandwidth. delriy)

Figure 2.3: An example showing the bandwidth-constrained paths from A to H. with a

bandwidth requirement of at Ieast 1.5.

For other QoS metrics such as delay, delay-jitter, and cost, the state of a path is

detennined by the combined state over al1 links on the path. For example, in Figure 2.1,

the delay of the path (A,C,G,H) is 6, which is the total delay of al1 links on the path. Two

basic routing problems cm be defined for this type of QoS metrics:

Path-optimization routing problem. An example is Ieast-delay routing, which is to find a

path whose total delay is minimized.

(bandwidth, delriy)

Figure 2.1: An example showing the least-delay path From A to H.

Path-constrained routing problem. An example is the delay-constrained routing, which is

to find a path whose delay is bounded by a required value.

(brindwidth. delay)

Figure 2.5: An example showing the delay-constrained paths fkom A to H, with a delay

requirement of at most 7.

Many composite routing problems can be derived fiom the above four basic problerns.

For example, the bandwidth-constrained least-delay routing problem belongs to the link-

constrained and path-optimization routing problems. It is to find the Ieast-delay path that

has at leûst the required bandwidth. A shonest path aigorithm on the graph can solve this

problem. w here the links that violate the bandwidth requuement are removed.

(bandwidth. delay)

Figure 2.6: An example show h g the bandwidth constnined least-delay path From A to H.

with a bandwidth requirement of at least 2.

2.2.2 Multicast Routing

In multicast routing. the QoS optimizations or requirements must be applied to the entire

tree. For example, bandw idth-optimizat ion routing asks for rnaxirnizing the bandwidth of

the bottleneck link of the tree. There are several well-known multicast routing problems:

Tree-optimization routing problem. An example is the Steiner tree problem, which is to

find the least-cost tree, i.e.. the tree covering a group of destinations with the minimum

total cost over al1 links. Finding a Steiner tree is NP-complete [7].

(cost, delay)

Figure 2.7: An example showing the least-cost tree from A to D, E, and H.

Tree-constrained routing problem. An example is the delay-constrained routing, which

finds a tree in which the end-to-end delay from a sender to any destination is bounded by

a given value.

(cost, delay)

Figure 2.8: An example showing the delay-constrained tree from node A to nodes D, E,

and H, with a delay requirement of at rnost 7.

Many composite routing problems can be derived from the above basic problems. For

example, the constrained Steiner tree problem is to find the least-cost tree with bounded

delay. It is also called the delay-constrained least-cost routing problem, belonging to the

tree-constrained and tree-optimization routing problems. A constrained Steiner tree is

also NP-complete [13].

(cost. deIay)

Figure 1.9: An example showing the delay-constrained least-cost tree from node A to

nodes D. E. and H, with a delay requirement of at most 8.

2.3 Routing Strategies

In order to find an optimal path which satisfies the requuements, the state information

about the intermediate links between sources and destinations must be known. The

search for a feasible path greatly depends on how the state information is collected and

w here the information is stored.

There are three routing strategies: source routing, distributed routing and hierarchical

routing. They are classified according to how the state information is maintained and

how the search of a feasible path is carried out.

2.3.1 Source Routing

In source routing, each node maintains the complete global state, including the network

topology and state information for every link. Based on the global state, a feasible path is

locally computed at the source node. A control message is then sent out dong the

szirsiccl path to inform the intermiliate nodes of thrir pwiedznr and s ~ c i e ~ ~ i v e iiodes.

A link state protocol is used to update the global state at every node.

Source routing achieves its simplicity by transforming a distributed problem into a

centralized one. B y maintaining complete global state. the source node calculates the

entire path locally. Many source algorithrns are conceptually simple and easy to

implement. evaluate. debug, and upgrade. In addition. it is much easier to design

centralized heuristics for some NP-complete routing problems than design distributed

ones.

Source routing has several problems. First, the global state maintained at every node has

to be updated fiequently enough to cope with the dynamics of network parameten such

as bandwidth and delay. This makes the communication overhead excessively high for

large-scale networks. Second. the link state algorithm can only provide approximate

global state due to the overhead concem and nonneglible propagation delay of state

messages. As a consequence. QoS routing may fail to find an existing feasible path due

to the imprecision in the global state used. Thûd, the computation overhead ai the source

is excessively high. This is especially true in the case of multicast routing or when

multiple constraints are involved. In sumrnary, source routing has a scalability problem.

It is impractical for any single node to have access to details state information about ail

nodes and links in a large network.

2.3.2 Distributed Routing

In distributed routing, the path is computed by a distributed computation. Nodes

exchange control messages among themselves and the state information kept at each node

is collectively used for the path search. Most distributed routing algorithms need a

distance vector protocol or 3 link stzte protocol to maintain a global state in the f o m of

distance vectors at every node. Based on the distance vector, the routing is done on a

hop-by-hop basis.

The pat h comput ations are distributed among the intermediate nodes between sources 'and

destinations. Hence. the routing response time can be made shorter. and the algorithm is

more scalable. than source mutin;. Searching multiple paths in parallel for a feasible one

is made possible. which increases the chance of success. Most existing distnbuted

algorithms require each node to maintain global network state. based on which the

routing decision is made on a hop-by-hop basis. Some flooding-based algorithms do not

require any global state to be rnaintained. The routing decision and optimization is done

based entirel y on the local states.

Distributed routing algorithms that depend on the global state share more or less the sarne

problems of source routing algorithms. The distnbuted algonthms that do not need any

global state tend to send more control messages. It is also very difficult to design

efficient heuristics for the NP-complete routing problems. especially in the case of

multicast routing, because there is no detailed topology and Iink state information

available. In addition, when the global states at different nodes are inconsistent, loops

may occur. A loop can easily be detected when a node receives the muting message for

the second time. However, loops generally make the routing fail because the distance

vecton do not provide sufficient information for an alternative path.

2.3.3 Hierarchical Routing

In hierarchical routing, nodes are clustered into groups, which are Further clustered into

higher-level groups, creating a multilevel hierarchy. Each physical node maintains an

aggregated global state, which contains detailed information about the nodes in the same

group and aggregate state information about the other groups. Source routing is used to

find a feasible path on which some nodes are logical nodes representing groups. Then. a

control message is sent dong this path to establish the connection.

Hierarchical routing has long k e n used to cope with the scalability problem of source

routing in large intemetworks. It scales well because each node only maintains a partial

global stûte where groups of nodes are aggregated into logical ones. The size of such an

aggregated state is logarithrnic in the size of the complete global state. Well-studied

source routing algorithms are directly used at each hierarchical level to find feasible paths

based on the aggregated state. Hence. hierarchical routing retains many advantages of

source routing. It also has some advantages OF distributed routing since many nodes

share the routing compu fat ion.

However. because the network state is aggrepted additional imprecision is introduced.

which has a significant negative impact on the QoS routing. A logical node in an

aggregate network image may represent a large subnet with complex intemal structure.

and a logical link may be the abstraction of multiple.

2.4 Multicast Routing Algorithms

2.4.1 Source Routing Algorithrns

Most heuristic algorithms for the source multicast routing problerns constnict a

constrained tree by adding one destination into the tree each t h e based on certain

criteria, and they require every node to maintain the global state of the network.

The objective of the Steiner tree problem is to find tree that rninimizes the cost of a

multicast tree that spans a given subset of nodes. If the multicast group includes al1

nodes in the network, the minimum Steiner tree problem reduces to the minimum

spanning tree problem. The best-known Steiner tree heuristics were proposed by Kou.

Markowski, and Berman [14], Takashi and Matsuyama [ 151, and Rayward-Smith [16].

In the Kou et nt. algorithm [ 141. a network is abstracted to a complete graph. where nodes

represent the source and destinations, and the edges represent the shortest paths between

these nodes. It uses Prim's minimum spanning tree algorithm [17], dunng its

computation, to construct a minimum spanning tree in the complete graph. Then the

Steiner tree of the original network is obtained by expanding the edges of the minimum

spanning tree into the shonest paths they represent. If any loops appear. they are

remo ved.

The Takashi-Matsuyama algorithm [IS] starts with â tree that contains the source node

only. Then it adds the multicast group members. one at a time, to the existing tree via the

cheapest least-cost path to ûny node already in the tree.

The Rayward-Smith algorithm [16] starts with a forest of trees, with each multicast group

member forming a tree. Then the algorithm unites trees with the cheapest path to each

other by adding the appropriate links until it ends up with a single tree. Many other

algorithms for constmcting Steiner trees in communications have been proposed.

The problem of finding the tree that minimizes the cost of a multicast tree with its paths

subject to an end-to-end delay (i.e., the delay-bound least-cost tree), is called the

Constrained Steiner tree problem. The increasing importance of end-to-end delay as a

QoS requirernent for multimedia communications has motivated the development of new

algorithms. Kompella, Pasquale, and Polyzos [18], Sun and Langendoerfer 1191, and Zhu,

Parsa, and Garcia-Luna-Aceves [20] proposed some heuristic source routing dgorithms

for this problem.

The fust heuristic for the delay-constrained Steiner tree was given by Kompella et al.

[18]. The fxst step of the algorithm is to create a complete graph where the nodes

represent the source and destinations, and the edges represent the delay-constrained least-

cost paths between these nodes. It assumes that the link delay and the delay constraint

are integers, while the link costs may take any positive real value. The second step is to

constnict a delay-constrained spanning tree of the complete graph. In this step, the tree is

cxpandcd by adding an edge rit ri time uniil erer; member is included. The selected edpe

connects a node in the tree (in-tree) and a node outside the tree (off-tree), does not violate

the delay requirement and minimizes a selection function. The authots proposed two

alternative objective hnctions to use dunng the tree construction. The first is a hnction

of the link cost only. The second objective function is a hnction of both the link cost and

the residual delay if this link is added to the tree.

Another source routing algorithm was proposed by Sun and Langendoerfer [19], which

constructs an approximated constrained tree by Dijkstra's algorithm. This alprithm

computes an unconstrained least-cost tree. Then the tree is modified to satisfy the delay

requirement. If the end-to-end delay to any member violates the delay constraint, the

path From the source to that member is replaced with the least-delay path. The advantage

of this algorithm is its low time cornplexity.

Zhu et al. [?O] proposed a source routin; heuristic to construct the constrained Steiner

tree. The algorithm allows variable delay bounds on destinations. A least-delay path is

first constructed. for a given source and a multicast group. by Dijkstra's algorithm. If the

delay requirement cannot be satisfied for any destination, it rnust be renegotiated.

Otherwise, the algorithm proceeds by iteratively refining the tree for lower cost. The

basic idea is to replace a path in the tree by another with lower cost, until the cost of the

tree cannot be reduced any further. The algorithm always find a constrained multicast

tree, if one exists, because it starts with a least-deiay tree. The authors defined the link

cost as a function of the link utilization and defined the link delay as the sum of the

queueing, transmission and propagation delay.

2.4.2 Distributed Routing Algorithm

Kornpella, Pasquale, and Polyzos first formulated the delay-constrained Steiner m e

problem [21]. They also proposed a distnbuted heuristic solution to the NP-complete

delay-constrained Steiner tree problem. The heuristic is based on Prim's algorithm [L7].

but it involves the making and breaking of cycles during the construction of the multicast

r . The algonrhix icquircs c v c q node :O mintain o distance xctor table, stonng the

minimum delay to every other node. Starting with the source node, the algorithm

constructs the multicast tree iteratively by adding one link to the tree each time. Fust, the

source node bmadcast a message down the partiaily constructed tree. When a node

receives the message, it finds the adjacent link that: lends to a destination out of the tree,

does not violate the delay requirement. and minimizes a seiection function. Second, the

selected links are sent to the source node, where the best link that minimizes the selection

is chosen. Third. a message is sent to add the selected link to the tree. The above process

continues until the tree coven al1 the destinations. Its communication overhead is high,

and every node needs to maintain global state.

Chen and Nahrstedt [27] proposed a distributed routing framework based on selective

probing. Afier a connection request arrives. probes are flooded ftom the source towards

the destinations of the multicast tree. Probes are flooded selectively along those paths

that lead to at least one destination and have sufficient resources to satisfy the QoS and

optimization requirernents. As probes travel toward a goup of destinations. a multicast

tree is built in a distributed manner. Every node maintains only its local state. Each

probe that arrives at the destination detects a feasible path.

In order to avoid rerouting of the entire tree whenever a node joins of leaves a rnulticast

session, Chen and Nahrstedt proposed the use of receiver-initiated probing. When a new

member joins the multicast group, it sends probes towards the rnulticast tree. Probes

proceed only dong the path that do not violate the QoS and optimization requirements.

Hence, a feasible path is determined when a probe reaches the rnulticast tree. Once a

node reaches any node in the multicast tree. a feasible branch of the tree is found. This

algorithm is suitable to construct shortest-path tree, but not the constrained Steiner tree,

because the probes searc h for the shortest pat hs individuall y without cooperation to

reduce the overall cost.

Carlberg and Crowcroft [23] proposed another distributed routing algorit hm. They

proposed the spanning-joins approach for the construction of multicast trees across

different domains. A new group member broadcast a join request message in its

neighborhood to find in-tree nodes. These messages are sent dong paths that may or may

not have enough resources; hence multiple candidate paths are used. Whenever an in-tree

node receives the message it sends a unicast reply back to the new member. The existing

unicast routing algorithm determines the path of the reply message. The message collects

the QoS metncs and resource availability of the path as it passes through. The new

member may receive multiple reply messages that correspond to multiple candidate pat hs

connecting to the multicast tree. Then it determines whether a feasible path rxists and

selects the best path according to the QoS information cmied by the received reply

messages. Consecutive broüdcast are necessary to search increasingly larger

neighborhood until in-tree nodes are found. In order to reduce the message overhead, it

uses reverse path multicasting, the time-to-live field. and directed spanning joins.

2.5 Multicast Routing Protocols

Efforts to develop multicast routing prorocols for wide area networks (WANs) have

started in the late 1980's motivated by the rapid growth of the Internet and the emergence

of new applications involving multiple users.

The Distance Vector Multicast Routing Protocol (DVMRP) [24] is the first standard

protocol for IP multicast routing. It is widely implemented in cornmercially available

routing equipment, and it is the protocol used in most routers of the MBone, which

currently spans thousand of nodes on al1 continents. DVMRP is based on the TRPB

heunstic 1251. It is a distributed protocol that uses Iimited information available in the

distance vectors of the Routing Information Protocol (RIP) [IO] to fonvard datagram

packets from the source to al1 receivers over the reverse shortest paths. DVMRP uses

source-specific multicast routing, and it allows receivers to dynarnically join and leave a

multicast session. In order to discover new members in a multicast session, and because

it depends on soft state, DVMRP periodically sends the source's packets over a broadcast

tree to al1 nodes in the network. Then leaf nodes which are not members of the multicast

groups prune messages upstream towards the source to prune the links leading to these

nodes from the tree. The occasional broadcasting behavior of DVMRP causes inefficient

use of the network bandwidth, especially if the size of the multicast group is small. This

limits the scalability of DVZvIRP to larger networks.

The Multicast Extensions to OSPF (MOSPF) [26] is a standard multicast routing protocol

for intenor gateway routing, i.e.. within a single autonomous domain. As the name

indicates. MOSPF is based on the Open Shortest Path Fust (OSPF) [8] unicast routing

protocol. MOSPF uses the centralized Dijkstn algorithm to construct the fonvard

shortest path multicast tree. To achieve this. a node that mns MOSPF must maintain

complete information about the network topology. Therefore. complete topology

information must be periodically broadcast to al1 MOSPF-capable nodes in the networks.

The centnlized nature of MOSPF as well as the necessary periodical broadcast

operations severely limits the scalability of the protocol.

In addition to the limitations mentioned above. both DVMRP and MOSPF rely on

specific routing protocols, EüP and OSPF, respectively. Thus, the y cannot be deplo yed

on routers not runnin; these unicast routing protocols. Two new protocols were

developed to avoid the shortcomings of DVMRP arid MOSPF. These protocols are

independent of the underlying unicast routing mechanisms.

The first protocol is Protocol Independent Multicasting (PIM) [27]. PIM specifies a

dense mode (PM-DM) 1281 and a sparse mode (PM-SM) [27]. When a multicast group

densely populates an internetwork, PIM-DM is used to create source-specific multicast

trees. The basic operation of PM-DM is very similar to that of DVMRP, but it is

independent of the underlying unicast routing protocol. PM-SM is specified for

multicast grououps where the members are sparsely distributed over an intemetwork. PM-

SM uses rendezvous points (RP) which are central nodes at which receivers can meet

sources of the same multicast session. A shared tree is constructed around the RP.

Receivers join the shared tree via the forward shortest paths towards the RP, and sources

transmit to the shared tree via the fonvard shortest paths towards the RP. Thus packets

are forwarded over the reverse shortest paths from the RP to the receivers. A receiver r

discovers the existence of a source s when it receives that source's packets over the

shared tree. Then the receiver r can elect to continue receiving packets from source s

over the shared tree, or altematively. it can join that source's specific tree via the reverse

shonest path from that s to r. Thus, PM-SM permits the use of both shared trees and

source-specific trees. Similar to D W . PIM relies on a soft stüte refreshment

mechanism, and thus it suffers From perîodical message overhead to maintnin the

multicast trees. However, soft state enhances the robustness of PIM.

Core Based Trees (CBT) [29] is the other protocol developed for the multicast routing

over the Internet. In CBT. al1 sources sending to the same group use a single multicast

tree to carry their traffic to al1 receivers belonging to that group. The multicast tree has

one or more cores. Similu to shared mode of PM-SM, a new receiver joins an existing

core based tree via the fonvard shortest path towards a core. and therefore. packets are

fonvarded on the iree dong the reverse shonest paths from the cores to the receivers.

The cores are interconnected via a core backbone. CBT relies on an explicit reliability

mechanism to maintain the multicast tree. This mechanism introduces much less

message overhead that that introduced by PIM's sofi state mechanism.

Interoperability with other multicast routing protocols is k ing considered in the

specifications of both PIM and CBT. A quantitative cornparison of the two protocols and

suggestions to irnprove their performance can be found in [30].

Work on QoS routing has started only very recently, 1996, motivated by the need for

routing algorithm capable of providing QoS guarantees. An initial draft of the QoS

routing protocol based on OSPF is now available. Quality of Service Extension to OSPF

(QOSPF) [3 11 is a protocol capable of routing both unicast and multicast connections and

reserving bandwidth and other resources for those connections. This protocol performs

path pre-computation and is based on a hop-by-hop routing mode. It computes QoS

paths using the widest-shortest path selection criterion. At a router, the protocol pre-

computes paths from the router to al1 destinations in the network. For each destination, it

computes paths of al1 possible bandwidth values, and uses them to build a QoS routing

table. The information in the routing table is used to identify paths capable of satisfying

the bandwidth requirements of new requests. The search stops at the first entry with an

avai lable bandw idth larger than the requested value. at w hich point the corresponding

next hop is retumed and used to determine where to fonvard the request next. It is

limited to handling requests with bandwidth requirements.

Cml berg and Crowcroft proposed Yet Another Multicast ( Y W [37] routing protocol,

which uses an on-demand adaptive tree construction mechanism to build shared trees.

The coiistmction of the shared tree involves the use of an explicit joining mechanism, in

which nodes fonvard control messages towards the cornmon root in order to build a new

branch. This protocol offers multiple routes to a new member w ho selects the best such

path. The destination router searches its neighborhood and finds routen that are prut of

the tree of the desired multicast group. This way. the new router selects the most

prornising path. Routing in YAM relies mainly in its neighborhood search. but this

procedure increases the control overhead significantly.

Faloutsos, Banerjea, and Pankaj [33] proposed a QoS-sensitive multicast routing

protocol. which improves the performance of spanning-joins by the help of a Manager

router. In their protocol, called QoSMIC. a new receiver join the multicast tree by

searc hing several alternative paths fi-om the tree itself. The searc h mec hanism involves

reverse-path flooding by the receiver. By fiooding bid-requests, a new member receives

bids fi-om candidate routers on the multicast tree. Based on the topology information, the

Manager router selects a subset of the in-tree nodes to send the reply messages without

receipt of the join request message. Then the new receiver selects a candidate as the

attachment point to the multicast tree, according to the QoS information in the bids.

QoSMIC employs the Steiner heuristic of Takashi [15] to produce a low-cost multicast

tree when a new receiver joins. However, with a dynarnic group membership. the overall

cost of the rnulticast tree constructed in this manner can becorne arbitrarily bad.

QoSMIC only deals with the addition of new receivers, and not with maintaining and

adapting trees of low cost as network changes, such as link failures, and group

membership changes occur.

Recently Biswas. Izmailov and Rajagopalan [34] have proposed a QoS multicast routing

framework based on enhancements to PIM-SM. Its objective is to design an incremental

tree construction algonthm which consider both bandwidt h and additive QoS

requirements, such as delay and Ioss probability. This framework has two components:

the deve lopment of rnulticast tree computation schemes t hat account for heterogeneous

receiver QoS requirements, and the incorporation of QoS capabilities into PM-SM for

establishinp computed paths. The framework includes two tree computation algorithms,

each assuming different amount of tree information available at the intermediate

multiçast routers. The first requires complete information rit each router about the

resource allocation in the network for the existing multicast tree, which is very successful

in discovering QoS constrained paths but suffers fiom scalability problems. The second

requires ri QoS version of the inter-domain routing algorithm (e-g. BGP). These

cilgorithms support both heterogeneity and receiver-oriented bandwidth reservation.

In this chapter we present an overview of previous work on Quality of Service (QoS)

multicast routing algorithm and protocols. where the problem is to find a constrained

rnulticast tree.

Chapter 3

Multicast Intra-domain Protocol (MInP)

In this chapter, we present MInP, a multicast protocol for the Lntemet that supports

multimedia multicast applications. The mult icast protocol considers the QoS needs in

order to create trees that are better suited for multimedia traffic. In section 2.1 we

provide an overview on the design of MInP. In section 2.2 we describe the network

model. In section 2.3 we describe in detail and mechanisms used by MInP.

To cany real-time multimedia traffic effectively, a network must support quality of

service (QoS) guarantees, based on such parameters as loss rate, bandwidth, and delay. A

QoS service allows multimedia applications to specify the quality of service required for

the transmission of their traffic. In addition, with the expected expansion in the volume

of group communication and the availability of multicast, a network must support

mult icast service with QoS guarantees; the support of these multimedia applications

needs efficient multicast communication and QoS mec hanisms. A multicast protocol that

considers QoS metrics in its routing phase can create better distribution trees suited to the

needs of the multimedia applications.

Most current routing protocols use only a single metnc, such as hop-count, delay, cost, or

bandwidth, to characterize routes in a network. The use of multiple metrics is needed to

better characterize a network and to support a wide range of QoS requirements. A single

mixed metric does not suffice in networks supponing multimedia applications because it

is difficult to accurately rnix the different metric into a single function. Furthermore, it

may be impossible to combine metrics that have different composition rules, e.g., delay

and bandwidth. Therefore. it is not possible, in general, to express the QoS requirements

in a single metric. On the other hand, multi-metric shortest path computation is a not

well-defined optimization problem unless al1 the metrics are combined into one single

objective function. So, in order to reduce the complexity of path computation and to

facilitate scalability of a routing protocol to large networks, only a subset of QoS

parameters are chosen. Each additional metric increases the computation and storage

complexity of the routing algorithm. Two QoS parameters of interest stand out. one is

available bandw idt h and the other is delay.

Most approaches to multicast routing currently under consideration for the Intemet

construct shortest-paths. in terms of a single metric. from a source/core to a11 receivers in

the group. Therefore. they are not well suited for real-time multimedia tr3ffic. These

approaches include DVMRP [X]. MOSPF [26]. PIM [27.25]. and CBT [19]. In addition.

only few algorithms and protocols have taken into account the nature of group

communications. where we may have multiple sources in a multicast session. These

approaches include YAM[32]. QoSWC[33]. and QoS extensions of PIM[ZS].

MOSPF[26] and CBT[29].

In this chapter. we present a MnP. ri multicast routing protocol. that:

constructs a multicast distribution tree considering QoS metrics:

constructs multipoint-to-multipoint multicast distribution trees that use network

resources efficient ly:

minimizes the unnecessary participation of al1 nodes in the network in the

construction of the multicast tree and therefore is scalable to larger networks;

handles the asymmetric nature of link parameters, such as delay, by setting up the tree

such that the data flow is within the delay bounds fiom any source to any receiver;

is robust to group membership dynamics (i.e., joins and leaves).

3.1 Overview

core

recei ver

7'

source & receiver

new member

- Resources reserved ----- Ferisibte paths

Figure 3.1 : An overview of MInP.

MInP constructs a shared tree based on a greedy heuristic [ l j ] , that connects each new

user to the closest branch of the existing multicast tree and leads to efficient resource use.

Our protocol offers alternate feasible paths for each connection to enable the support of

QoS requirements (Figure 3.1 ).

In MhP, one router for each multicast group is selected as the core router (or termed

elsewhere as rendezvous point (RP) [27]) for the multicast group. A tree rooted at the

cure is then constructed to span al1 the group mernbers. A host fiirst expresses its interest

in joining a group by rnulticasting an IGMP message [35] to its local router. The local

router will search the neighborhood for the most prornising nodes of the multicast tree to

connect with, according to the QoS metrics established by the application. The local

router will send probes with scope lirnited for its closest in-tree router in order to identify

these potential points to join the multicast distribution tree. Every in-tree node that

receives the probe will reply to the local router. This message lets the local router know

that the in-tree router is a possible point to join the multicast distribution tree. The probes

and reply messages will collect the QoS metrics of the path they traverse. These

messages proceed only along the paths that do not

established by the application. It should be clear From

protocol corresponds to a modified implementation of the

42

violate the bandwidth bound

the above description that our

greedy algonthm [ 151.

Eventually, the local router compares al1 the identified connection paths, and selects the

best, in terms of QoS metrics, among them The main idea is that at each member join,

the new member :vil1 be connected zith the k s t QoS p&h to the multicast tree. The

specific metric used by the routing protocol depends on the needs of the application.

Then the local router sends a join-reyiiest message upstream to the next hop on the path

towards the selected router to join the multicast tree.

The join-req~rest sets up transient join states in the routers it traverses. If the trnnsient

join state is not confirmed with ü join-ïicknoivledgrn~ message from upstrearn. the state

is eventually timed out. The join-reqiiest message travels upstream hop-by-hop toward

the corr router until it reaches the 'ore. at which point a juin-acXnoivfedgrnenr message is

sent back dong the reverse path. foming a new branch from the multicast distribution

tree to the requesting local router. When an intermediate router receives a join-

ncknowledgment message. it updates its fonvarding cache to reflect the fact that it now

becornes an in-tree router. and fonvards the juin-ncknowkdgment message downstrerim

io the requesting local router. The routing state is fixed, and the route does not change

once it has been established. Le.. al1 multicast traffic will travel dong the route

established. The QoS states kept at each in-tree nodes are updated and refieshed

periodically or when triggered by join or leave requests.

In order to support QoS. each join-reyrtest message carries, in addition to the interface

information, some QoS parameters of interest along the route. When a join-reqllest

message reaches the core or an in-tree router, it performs a set of delay tests to veriQ that

the requesting router does not violate the QoS parameters established. The in-tree router

have to collaborate with other upstream in-tree nodes, in order to conduct the delay tests

and verify that the QoS metrics from andor to other rnembers are within the bounds

established by the application. Moreover, the state kept at sorne other in-tree nodes may

have to be changed because of the member join. That is, collaboration arnong in-tree

nodes is inevitable in approving a join request. Only after the branch survives the delay

tests, it will be eligible to join the multicast tree, under which case a join-

acknowledgement message is then sent back.

If a host requests to leave fiom a multicast session, the directly attached local router has

to r&e c m of this request. The state h p t at the other in-tree nodes may have to he

updated, so proper procedures have to be taken to notify in-tree nodes of the need to

update their States. If the local router does not have any other directly attached members

or downstrearn in-tree nodes. it sends a ieave-notificc~rion message to its parent router on

the tree and deletes the corresponding fonvarding cache. thereby ceasing to be an in-tree

router for that multicast tree.

3.2 Network Mode1

We represent the network by a weighted directed graph G = ( V . 0 with a set of nodes V

and a set of edges. or links. E. The nodes represent routers and the edges represent the

network communication links connecting the nodes. The description of the protocol uses

nodes and routers interchangelibly. The links lire undireçted only if the communication

links are always symmetric. A symmetric link has the same properties (capacity,

propagation delay, etc.) and the same traffic volume in both directions. For most real

networks the communication links are asymmetric. and hence every link is represented

by two directed edges in the opposite direction.

Each link e = (u,v) E E has a link-bandwidth function b(e) and a link-delay function d(e).

The link-bandwidth Function and link-delay function can iake any non-negative real

value. The îink-bandwidth and link-delay metrics are not redundant in order to better

capture and mode1 distinct quaiities of a iink. The iink-bandwidth is associated with the

load of the iink and is a measure of the available bandwidth on the link e. The iink-delay

function is the sum of the perceived queueing delay and propagation delay over that Link,

i.e., is a measure of the delay experienced by a packet over the link e.

We denote as Mg a set of nodes to which hosts that belong to a multicast group g are

attached. M , is a subset of V, with each router v in M, as a ,wup member. Actually the

multicast group is the set of hosts that are directly attached to nodes in Mg. We denote Ms

as the set of source group members, which is a subset of 4. Packets originated from a

source router v in Ms have to be delivered to a set of receiver nodes Mt-(v} in the tree T.

A multicast distribution tree T is a subgraph of G that spans al1 the nodes in Mg and has

no cycles. In addition. T includes intermediate nodes dong the paths in the tree frorn

source nodes to destination nodes. We denote the tree routed at v as T,(v), i.e., the

subtree of router v. We use Pdnr ,n i ) to denote the path kom source node ni to a receiver

node 11, in LM,-lnl) in the tree T. Le.. a sequence of nodes (n l . .... nl ) such that each of the

pairs (nl.n2). (n2.n-:). ... . (nl.l.nl) are links in E.

The QoS requirements are specified as an upper bound on the end-to-end delûy, 4, and a

lower bound on the bandwidth ovailable. B. both from iiny source node to a receiver

node. The need for a bounded end-to-end delay and minimal available bandwidth has

been well justified [36.37].

The delay of a path Pd~i~.rit). end-to-end delüy which prickets from the source node nl to

a destination node ni experience, is additive and is equal to the sum of individual link

delays d( r ) dong the path Pdnr,nl )

The bandwidth of a path Pdnl ,nJ , available dong a path frorn the source node ni to a

destination node ni, is concave and is equal to the minimum bandwidth b(e) arnong the

links in path Pr(n1,ni)

The network is modeled as a set of nodes that are interconnected by a set of Ml-duplex,

asymmetric communication links. The following assumptions are made:

There exists an underlying unicast routing protocol, which can deliver a message

h m one node to any node in the network.

Each node maintains its up-to-date local state, including the available bandwidth and

delzy on e x h crutgoing link. .A node has neither the knowledge of the state of any

global network state nor the knowledge of the state of any other node.

A new mernber is able to rnap a multicast group address to the core node of the tree

on demand possibl y by a querylresponse Session Description Protocol (SDP) [38]

The çore is selected administratively

Sources use hierarchical encoding in order to allow each receiver to adapt the

accepted information to its own capacity, cg. Layered Multicast [39]

An in-tree muter will not process the next join or ieave request unri1 it finishes

processing the çurrent join request

QoS bounds (bandwidth and delay) are estüblished at the beginning of the session

according to the needs of the application

3.3 Description

3.3.1 Quality of Service Requirernents

In order to constmct the multicast distribution tree, MInP considers the end-to-end delay

and available bandwidth QoS requirements of the multicast application. These

requirements impose:

An upper bound, A. on the acceptable end-to-end delay perceived by a receiver router

along any path from a source router to the receiver nodes in a multicast group.

A Iower bound, B, on the minimum bandwidth that must be available along any path

from a source router to any receiver router in a multicast group.

To satisfy the end-to-end delay bound, A, each in-tree node u, keeps the following per-

node states:

dlnar(~i,*): the maximum delay among in-tree paths tom node 11 to the downstrearn in-

tree g o u p .

d,,,,(*.u): the maximum delay among the in-tree paths kom al1 the downstream in-

rrer source proup rnrrnbers.

Also each in-tree node 11 , keeps the following per-downstream-interface states:

L ( l i n r , l ( l ~ , ~ the maximum delay among in-tree paths from node n to the downstream

in-tree group rnernbers reachable on interface i. where the interface i is a downstream

interface and downstream is defined with respect to the cure.

&,,(*.u): the maximum delay among the in-tree paths from al1 the downstream in-

tree source group rnembers reachable on intefiace i to node 11.

The per-node stüte dmar(li.*) is nüturally defined as the maximum dmr.,(ri.*) value for al1

downstream interfaces i of node ri. Similarly &,(*.n) is defined as the maximum

(I,,,ar,t(*.ii) value ürnong the downstream interfaces i of node ri. One c m interpret

&mr(rl,*) and ~ i . , ~ ~ ( * , i r ) as the maximum outgoing and incorning downstream delays,

respectively, incurred when a multicast packet traverses the subtree frornlto node i i . i.e..

where DI is the set of downstream interfaces of node 11. Let TS(u) denote the subtree

rooted at node ri, then each in-tree node keeps the state information for T&). For

example, in Figure 3.2, the maximum downstream delay to receivers at the left interface

of the cure is 12, which is the downstream delay on the path (A,B,E), while at the right

interface it is 13, which is the downstream delay on the path (A,C,G). The maximum

outgoing delay at the core is 13. in the same way, the maximum upstream delay from

sources at the lefi interface of the core is 11, which is the downstream delay on the path

(AB,D), while at the right interface it is 10, which is the downstream delay on the path

(A.C.D. The maximum incoming delay at the core is I 1.

To satisfy the minimum bandwidth requirement, B, for a multicast group. each in-tree

nodc a nccds only to kecp of a per-node counie:, C, of how m n y source nodes currently

exist in the subtree, T,(lr), rooted at node ri. For example. in Figure 3.2, the number of

downstream sources in the subtree 7's(B) is one. so the value in the counter C kept at

router B is 1. In the süme way, the number of downstream sources in the subtree T,(A) is

two. so the value in the counter C kept at core is 3. The reason for keeping per-

downstream-interface (instead of per-node) state will become clear when we discuss the

member leave procedure.

router B dmcLJB. *) = 7 dmJ *. B ) = 6

core - &,(A, *) = 13 &'J 1 = 1 1

source & receiver receiver

source receiver

router E d-(E, *) = O

router F dm( F, *) = O d-(*JI = 0 C=O

router C dm,,( c. *, = 9

router G d,,,(G. *) = 0 1

Figure 3.2: An example showing the states kept at the in-tree nodes

Every router maintains multicast routing information, which enables it to fonvard each

multicast packet to an appropriate number of links. In more detail, each router maintains

a routing table for each link. A link has an entry in its table for each group for which the

link is part of the distribution tree. We denote such an entry for the shared tree of group

G by (*,a: !he symbol "*" represents " d l sources". A data packet of a gmup i s

fonvarded to al1 links that have the (*,G) entry, except from the iink that it anived from.

A router discards a data packet that arrives on a link that does not have a (*.G) entry,

which means that is not part of the tree. The state of a link is modified by the protocol

control messages. Adjacent nodes exchange messages periodically. and rehsh state of

their common links. If such state refresh does not happen, due to link or router failure.

the state link expires.

[ Router Name / Ro Ie

local router Connected to a set of hosts in a L M , receives request from

hosts via IGMP.

new-node

candidate

destination

router

Local router that initiaies ~*~zririidatr-searcIl; initiates join andor

leave procedures.

Considered as feasible joining point to the rnult icast distribution

router

source router

new-node connected to a L W containing a new receiver

rnember

tree for a new connection.

nriv-node connected to a L M containing a new source rnernber

1 in-tree router 1 Al1 routers that are part of the multicast distribution tree

intermediate

router

In-tree router that is not a source, destination or source-

destination router

Table 3.1: The roles of the different routers

Erample : We illustrate the protocol operations by means of a specific example. Figure

3.3 depicts a network of 10 nodes, each bearing a unique id. In order to simplify the

example, we use symmetric links. Boldfaced edges and nodes represent edges and nodes

of the current multicast tree T, respectively. The QoS requirements for the rnulticast

session are: a maximum end-to-end delay of 30, and a minimum available bandwidth of

15. The available bandwidth and delay characteristics of the network G are given in

Tahle 3.2. Suppose also that T has k e n constructed as a result of a sequence of join

requests, described in Table 3.3. The latter table also provides the joining paths,

computed dunn; the processing of each join request.

The tree is constructed in steps. incrementally adding ii new member at a time. with new

links and nodes king added after a successfully served join request. Initially. the tree

consists only of the core. After the first request. the tree consists of nodes {A. B. D } and

links ((A. B). (B. D). (D.B). (B.A)}. The second request adds node E and link (I3.E) to

the rnulticast tree. so the tree consists of nodes {A. B. D. E}. The expansion of the

multicast tree proceeds in a similiir fnshion. until we reach the instance depictcd in the

exarnple. Following our notation. w r have V ( T ) = (A. B. C. Dy E. F} and E(7) = {(A, B),

(A. C). (B. D). (B. E). (C. G). (D. B,. (B. (F. C). (C. A)} .

@ core @ receiver ont y

8 source only source ruid receiver

O intermediate 0 off-tree

Figure 3.3: An example of a network G and the embedded current multicast tree T.

Bandwidth

/ (FJ) 1 21

Table 3.2: Available Bandwidth and Delay characteristics of the links in G.

( New member 1 Join request 1 Joining path

Table 3.3: Sequence of join requests for the network G of Figure 3.2

D

E

Source and

Receiver

Receiver

(D,B.A) and

(A,BTD)

@,El

3.3.3 Candidate Search

MInP creates shared trees based with QoS guarantees using the spanning-juin approach

proposed by Cariberg and Crowcroft [23], and offers alternate paths for each connection

to enable the support of QoS requirements.

In MInP, one router for each multicast group is administratively selected as the core

router for the group. A tree routed at the core is then constructed to span al1 the group

members.

A host first expresses its interest in joining a group by multicasting a host membership

report [35] to its local router. which we cal1 neiv-node. The join request is received via

IGMP on a LcW at the intra-domain level. If the new-node is part of the group already.

the connection is established locally. If the new-node is not pan of the multicast group.

the candidate-sectrch procedure is employed. The neiwiode. router v. will search for the

most promising nodes of the multicast tree to connect with. according to the QoS metrics

defined. The nerv-node identifies several in-tree nodes as potential points to join to the

tree.

The search for a cnndiclatc is conducted by a candidate-senrcli procedure based in the

Chen and Nahrstedt algorithm [221, where the new-node. router v. searches its

neighborhood by flooding probe messages with scope limited by the use of the tirne-to-

live (TTL) field for its closest in-tree router ri. This field is initialized to a value,

decreased by one at each hop, and when it reaches zero, the message expires.

Furthemore, the search does not have to be a flooding of the neighborhood. Reverse

path broadcasting can be used to avoid the exchange of redundant message [25]. In more

detail, a router ignores probe messages that do not corne from the edge that is on the

shortest path from the node towards the router. This way each node forwards a specific

message only once. This procedure is the sarne as proposed in Y AM [32], but in addition

probes are only allowed to be sent along the paths that have sufficient resources to

support the required QoS [22], reducing the number of probes sent dong the links.

The new-node sends a specific type of probe message according to the type of join

request. e.g.. receiver only, source only. or both. We consider three cases:

If thc ncwnodc rrqucsts tu join the multicst session only 3s 3 receiver, router Y sen&

a receiver-probe message. Every in-tree router n, that receives the receivcr-probe

message. responds with a receiver-candidate-ndverriscrr~e~~t message. The receivcr-

candidate-adrprnisenzent message collects the downstream de lay and bandwidth

availability information kom router i l to router ir (i.e.. d(it.v) and b(i1.v)).

If the m i r - n o h requests to join the multicast session only as a source. router Y sends

a sotirce-probe message. Every in-tree router i l . that receives the recrivrr-probe

message. responds with a sonrce-c~zndidntr-ad~*c~iset~~ent message. The sonrce-

probe message collects the delay information in the upstream direction. Le.. the

message CO llects the upstream delay and bandwidth avnilability information from

router i-. to router tl (Le.. n ( v . r i ) and b(v,u)).

if the neic-node requests to join the multicast session as a source and receiver. router

v sends a sutircr-recrivrr-probe message. Every in-tree router ii, that receives the

receiver-probe message, responds with a soiirc*r-receiver-candidnte-advenismnt

message. The soiirce-receiver-probe message collects the delay information in the

upstrearn direction, i.e., the message collects the upstream delay and bandwidth

availability information From router v to router 11 (d(v,ic) and b(v,ti)); and the source-

receiver-candidate-advenisement message CO llects the downstrearn delay and

bandwidth availability information (d(u,v) and b(u,v)).

Once an advenisement message reaches back the new-node, a feasible extension of the

tree is found. The in-tree router 14, consider the nov-node as a tentative dependant.

Having a tentative dependant means that the router cannot leave the tree, but the router

does no forward data frodtowards a tentative dependant. The tentative status either

tirnes out or is confirmed and a connection established.

The candidate-advenisement message informs the new-node that the in-tree router ri is a

possible option to join the tree. Probes and candidate-advenisement messages proceed

only dong the paths that do not violate the minimum available bandwidth requirement,

8, for the rnulticast group. The unicast routing algorithm determines the path of the

messages. The carididure-~tdvcrrise~~~erzt messages collect QoS metrics only dong the

path on which they travel, so the new-riode could select the best path %om ûndlor toward

the multicast distribution tree according to the application requirements. For example,

real-time applications will prefer paths of minimum end-to-end delay. while data

tram fers may pre fer paths of maximum bandw idth.

The fie w-riodr may receive multiple catididate-ad~~enisei~t~rit messages t hat correspond

to multiple paths connecting to the multicast tree. It selects the shortest (delay) or widest

(bandw idth) path accordin j to the in format ion camed by the received crtndid~itr-

ndveni.srrnrnr messages. The main idea is that e x h join request connects to an in-tree

router with the minimum delay path to the existing multicast tree or connects to an in-tree

router with the widest bandwidth path [11] to the existing multicast tree. This is based on

an efficient grerdy heuristic for the Steiner tree problem [ 151. Eventuaily. the new-node

compares al1 the identified connection paths, and selects the best. which wç denote as

cnndicIn te.

Figure 3.4 provides a three part illustration of the Candidate Search procedure. In part

(a), a host expresses its interest in joining a rnulticast session by multicasting an IGMP

message to its local router (1 }. The local router, or new-node, broadcasts probe messages

in order to identib potential points to join the multicast tree. Part (b) shows that when

the probes reach in-tree nodes {D, ET F, G ) , candidate-advenisement messages are

unicast back to the local router. The candidate-advertisement message on ünk (G, I) is

eliminated since messages proceed only along the paths that do not violate the bandwidth

bound established by the application. Finally, in Part (c) the local router chooses one of

the ~aths and sends a join-request towards the candidate.

Part (A): [GbP join request and probe

messages

Part (B): Candidate-advertisement

messages

Part (C): loin request to the candidate selected

Figure 3 -4: An example show ing the Candidate Search procedure.

3.3.4 Connection Establishment (Join Request)

We consider three cases for the connection establishment

neio-node is a receiver only

new-node is a source only

9 tww-rru& is i î source and a reczi~er

3.3.4.1 new-node is a receiver

Recr iver Join Procedl re

When a new-node. router it. joins a multicast session only as a receiver. it sends a

recriwr-join-reyilesr message to the cunifihre node, router i l . When the join-rrrprsi

message from a joining router v m i v e s lit an in-tree router 11. router 1r checks if

There is no need to check bandwidth rivailability since messages are only allowed to be

sent dong the paths t hat have su fficient resources to support the required bandw idt h.

If Eq. (3) holds, it implies the QoS requirements to the new receiver, router v, are fulfilled

from al1 the multicast source group members in the subtree T,(il). rooted at router ri. If

Eq. (3) does not hold, the join request is immediately rejected and a receiver-rejection-

repb message is sent back to the joining router v. Otherwise, router u immediately

reserves bandwidth of amount B, along the reversed path (u,v), for the multicast session.

The bandwidth is reserved in combination with a separate signaling protocol such as

RSVP [40], used for resource reservation. Then router id forwards upmarn to its parent

router w the receiver-join-request message with the updated accumuIative delay

information d(ii,v), i.e., the parameter of the delay along the path from router u to router v

(d(i1,v)) is carried as the message travels from router u to router W.

Upon receipt of the join request on interface i, router rv conducts the delay test (i.e., Eq.

(3), except u is replaced by w) to verify if join of router v violates the delay requirement

fiom all the multicast sources in T,(w). Note that the delay along the path fiom router w

to router v will be equal to the sum of the delay alonp the path from router w to router n,

read from the underlying unicast rouiing protocol, plus the delay along the path From

rourcr :I to rorrtcr Y, cmied in the rerriirr-juin-reqnesr niessage. so d(r.:ip) = d(w,ll) + d(ti .v).

If the delay test succeeds, router i v fonvards upstream to its parent router the receiver-

join-reqtte-~t message with the updated accumulative delay information. Router iv

immediately reserves bandwidth alortg the revened path (\c.ti), if it hns not k e n reserved

for anothcr downstreûm goup member (there is no need to reserve bandwidth dong the

reversed path if the previous router ri. has already resen~ed bandwidth on the path from

the core to router cl). If the delay test does not succeed. it sends ri recriver-rejection-reply

message downstream townrds router iv dong the revened in-tree path. releasing the

resources reserved for this join request.

The process repeats until the join request is either rejected at some upstream in-tree router

or fonvarded to. and approved by. the core router. In the former case. the corelrouter

sends back a receiver-rejection-rep- message to the joining router v. releasing the

resources reserved in the downstream direction for this join request. In the latter case. the

core reserve bandwidth on the path to its child router w and then sends back a receiver-

join-nckno\~ierlgrrient message. towards router v , along the reversed in-tree path in order

to confirm the route and resources reserved.

Each in-tree router w, on the path from the core to router v updates its state upon receipt

of the receiver-join-acknowledgrnent message fiom upstream, i.e., router w checks if

where interface i is the interface on which router w received the corresponding join

request. Then router w forwards downstream the juin-ocknowledgment message, towards

router v, to its child router il.

If Eq. (4) hoIds, it implies that the state kept at muter iv is affected by the join request of

router v. so router w updates its interface i state with the value of the delay dong the path

fiom thc in-tree router it* to the re teher router v:

and updates its per-node state:

If Eq. (4) does not hold. it implies that the state kept ai router it* will not change as result

of this receiver join.

Each in-tree muter rr? keeps only its subtree state information. which eases the job of state

update and maintenance at the time of a member join. When a join request nmves at an

in-tree router il. it has to pûss a delay test before it is npproved. where each test is

performed router by router on the in-tree path from router ir to the cure router.

Note that to avoid potential QoS conflicts among multiple requests that intend to join a

multicast group at the same in-tree router, an in-tree router will not process the next

request untii it finishes processing the current join request and sends back either a

rejection-reply message or a join-acknowledgment message. As a result, a new join

request may be blocked between the time a previous join request is fonvarded upstream

and the corresponding response retums. We assume that since only the in-tree nodes

between router u and the core are involved in jointly approving a join request, this

transient penod cannot be prohibitive1 y long.

dM&,(A.*) = 14 dmaJ*A) = 11

d,,,,,(A,*) = 13

i 15.6)

G

dnirLr( D. *) = 3 receiver

&,L,( * D l = 0 \

router E drntL,(E, *) = O LI,,,, ( *. n = O C=O

router F dm,,,( F. *) = O

*F) = O C=O

router G d,,(G. *) = O LI,,,,,( *,O = O C=O

Figure 3.5: An example showing the States kept at the in-tree nodes after a receiver

member joins the multicast tree T.

Receiver Leave Procedure

When a receiver, router v, leaves a multicast session, it sends a receiver-leave-

notification to its parent router u.

Upon receipt of a receiver-leave-notirnion message on interface i, if router u does not

have any other local receivers on the directly attached subnet or downstrearn in-tree

nodes it:

sends a receiver-leave-notification message to its parent router w;

deietes the corresponding forwarding cache;

and releases the bandwidth reserved of arnount B, in the downstream direction.

Otherwise, router 14 fmt deletes, From the fonvarding cache, the interface on which the

receiver-leave-notification message amives, and then checks its interface i state:

If Eq. (7) holds. it implies the state kept at router ir as well as other in-tree upstream

nodes will not change as a result of this rnember leave. Othenvise. router 11 Fust update

its per-node state (Eq. (L)) to reflect the fact that router v has lefi the rnulticast tree and

sends upstream. to it s parent router W. the receiver-leavr -riotifîcation message that caries

the accumulat ive delay in formation d(ir.1~).

Upon reçeipt of n rrceii~r r-lrriir-110t~1~*~1tion message. router ic re leases the resources

reserved if router i i . does not have üny other receivers downstream. Router iv checks

whether or not its state is affected (Eq. (7) except ii is replaced by w ) by the member

leave. If it holds. it irnplies that the per-node state kept at router i r* as well as other in-tree

upstrem routers will not change. If it does not hold, then it update its per-node state

(Le.. Eq. ( 1 ) rxept ri is replaced by w ) and fonvards upstream the solirce-lecive-

notflccuion message w it h the accumu lüt ive delay in format ion rl(iv.v). Then router 11

fonvards the soiircr-lr~iir-notificntiori message upstream w ith the accurnulative delay

information. The update process repeats until the receiver-lenve-notification message

reaches the core router.

The aforementioned procedure also illustrates why in-tree nodes have to keep per-

downstream-interface state. If only per-node state were kept. when a Ieave request leads

to the update of Eq. (1), the node would not have information for the new value.

= 12 = i l \ core

source Sr receiver

30.6) / d F

source

recei ver

router C d,,,( C. *) = 0 d,,(*,C) = 6

router F ti,',i F, *) = 0 dw,rl( *. n = 0 c ' = O

Figure 3.6: An example showing the States kept at the in-tree nodes afier a receiver

member leaves the multicast tree T.

3.3.4.2 new-node is a source

Sort rce Join Procedrt re

When a new-node. router v, joins a multicast session only as a source, it reserves

bandwidth of amount B, dong the upstream path ( v . ~ ) , for the multicast group. Then it

sends a s o i m e - j i n r e e message to the candidate node, router ir. When the source-

join-request message frorn a joining router v arrives at an in-tree router u, router i f checks

if

The parameter d(v.u) is can-ied in the source-join-reqzrest message and updated as the

message travels from router v to router M. There is no need to check the bandwidth

availability because messages are only allowed to be sent dong the paths that have

sufficient resources to support the required bandw idt h.

If Eq. (8) holds, it implies the QoS requûements for the group receiver in the subtree

TS(u), rooted at router il. are not violated due to join of the new source router v.

If Eq. (8) does not hold. the join request is immediately rejected and a soiirce-rejection-

repiy message is sent back to the joining router v. releasing the resources reserved.

Othenvise. router ir checks the value of its counter C. if it is equal to zero. then router ti

reserves bandwidth of amount B on the upstreüm in-tree link (tr. iv).

After checking the value of its counter C. router ir increments its counter C by one and

fowards the soiircr-joi~i-reri~irst message upstream to its parent router W. w ith the

updated accumulative delay information cl(r..ii) (i.e. the parameter of the delay dong the

p h from router r to router w (r l (v .w) = tl(r.ir) + cl(1i.w)) is carried as the message travels

from router ti to router w).

Upon receipt of the join request on interface i. router i v conducts the delay test (i.c.. Eq.

(S), except 11 is replaced by iv in the expression) to venfy if the source join request

violates the delay requirement from router v towards al1 the in-tree receivers in T,(w). If

the delay test succeeds. router w checks the value of its counter C (reserving bandwidth

on the upstream link if its value is zero), increments the value of its counter C. and

fonvards upstrearn to its parent router the s o w - c e o n - r i e with the updated

accumulative delay information. Othenvise, it sends a source-rejection-reply message

downstream towards router v dong the revened in-tree path, releasing the resources

reserved for this join request and restoring the value of counters C.

The process repeats until the source join request is either rejected at some upstream in-

tree router or forwarded to, and approved by the core router. In the former case, the

corelrouter sends a source-rejection-repiy message downstream towards router v dong

the reversed in-tree path. Each in-tree router w, on the path between router v and router

decrements its counter C;

releares the handwidth reserved in the upstream direction if C hits zero (Le., if it does

not have another source in its subtree);

and fonvards downstream the sourcu-rejrction-rrplv message to its child router ri.

In the latter case. the core sends back a soiirce-join-ncX7ioi~~ledgemenr message. towards

router if. along the reversed in order to confirm the route and resources reserved.

Each in-tree router iv. on the path from the core to router rr updates its state upon receipt

of the soiircr-joirr-nclo~otc*Iedgentent message from upstream. i.e., router iv , checks if

where interface i is the interface on which router w received the correspondin, a source

join request. Then router w forwards downstream the sutirce-juiti-ii~.kiioi~.le~lget~~ent

message. towards the joining router ip. to its child router ti.

If Eq. (9) holds. it implies that the state kept at router ir. is affected by the source join

request of router v, so router bv updates its interface i state with the value of the delay

dong the path from the source router v to the in-tree router w:

and updates its per-node state:

If Eq. (9) does not hold, it irnplies that the state kept at router w will not change as result

of this member join.

In short, each in-tree router 11 keeps only its subtree state information, which eases the job

of state update and maintenance at the time of a source join. When a source join request

arrives at an in-tree router i l , it has to pass the delay test before it is approved, where each

test is performed miter hy router on the in-tree path from router u to the cnre router.

router B d",,,,tB, *) = 7

1 router D 1

cl,,,( *,.A ) = t O

G

source receiver

receiver \

router 1 dmx(L *) = 0 dmJ *.O = O C=O

router C &,CC. *, = 9

router G

router F dm1( F, *) = O dmr(*F) = O C=O

Figure 3.7: An example showing the states kept at the in-tree nodes after a source

member joins the multicast tree T.

Sortrce Leave Procedure

When a member router v leaves a multicast tree, it sends a sorirce-leave-notification

message with the accumulative delay information d(v.rc) to its parent router u, deletes

from the forwarding cache, and releases the bandwidth of amount B on the path (w).

Upon receipt of a soiirce-leave-notification message on interface i, router i l decrements

and checks its counter C. which deletes the forwarding cache and releases the resources

reserved on the upstreürn path ( i l . i v ) if C hits zero. Then router i i checks its interface i

state:

If Eq. (11) holds. it implics the state kept at router i i as well as other in-tree upstream

nodes will not chüngr as a result of rhis source Irave. Othenvise. router i t first updates its

per-node state (Eq. (2)) to retleect the fact that router v has left the multicast tree and sends

upstream to its parent router w the soiircr-leove-notificnfion message that cames the

accumul~tive delüy information </(Y. w). i.e. the pürümeter of the delay dong the path

from router v to router w {d(l*.ic) = d ( v . i i ) + LW)) is carried as the message travels from

router rr to router W.

Upon receipt of a source-leme-notimtion message, router i c decrements and checks

counter C, which deietes from the fonvarding cache and relerises the upstrem reserved

bandwidth if C hits zero. Then router rv checks whether or not its state is affected (i.e.,

Eq. (12) except ii is replaced by w) by the source Ieave. If it holds, it implies that the per-

node state kept at router w is not affected Othenvise, then it updates its per-node state

(i.e., Eq. ( 2 ) except z i is replaced by w). Then router tt forwards the source-leme-

notification message upstream with the accumulative delay information. The update

process repeats until the source-leave-notimon message reaches the core router.

The aforementioned procedure also illustrates why in-tree nodes have to keep per-

downstream-interface state. If only per-node state were kept, when a leave request leads

to the update of Eq. (3, the node would not have information for the new value.

router B &,,iB. *, = 7

router D d,,,,( D. * ) = 0

receiver

router E dm,,(&. *) = O (i,,,,( *. B = O C=O

Figure 3.5: An example showing the States kept at the in-tree nodes after a source

member leaves the multicast tree T.

3.3.5 State Update and Refresh

When a neiv-node. router v. joins a multicast tree, each router w on the path From router v

to router u establishes its state using the delay information carried in the join-request and

juin-acknowledgment messages. For example, the accumulat ive delay in format ion,

camied in the join-request message received on interface i, between router v and the

current router W. is used by router \v to establish its transient state (i.e., Eqs (5) and (10).

To be robust to message loss, many Intemet protocols (e-g., DVMRP, P M , CBT) have

adopted the soft state approach for state maintenance. i.e., the state kept at each router is

created and periodically refieshed by state-refresh messages. A state is deleted if no

refresh messages arrive before the expiration of its associated timer. For example, CBT

maintains its tree b y having eac h downstrearn router periodicdly send a echo-request

message to its upstream router. The receipt of an echo-request message over a valid child

interface prompts an eclto-rep- message that carries a list of groups for which the

corresponding interface is a child interface. If no response is received within the expire-

tirne time. the router sends a ieavr-notification message upstream, and flushes a11 of its

downstream branches by sendingj7rl.d~-tree messages.

We adopted the sofi state approach and proposed a state refiesh procedure that can be

easily inteerated with the cornmon tree maintenance procedure (Le.. sending of echo-

reïprest and eclzo-rqdy messages) thus müking the overheads small. The state kept at an

in-tree router is associated with the expire-tinie timer. if o timer expires. the

corresponding stüte is removed. An in-trce router initiates a statc update process by

periodically sending ccko-rqttrst messages and piggybxking its state in the message.

Upon receiving an eclio-reqiiest message. a parent router updates its state if needed.

resets the timer. responds with an eclto-reply message. and initiates an iipstream state

update process if its state does change.

If a downstrenm router does not hear Frorn its upstream router upon the expire-rime timer

expiration. it considen the path to its upstream router as damaged. Then it sends a irave-

notificatiori message upstrenm and fliisli-tree messages downstream to flush the subtree

rooted at it. Each downstream group member will then individually have to find another

route to rejoin the tree. This is the approach currently defined in the CBT protocol

specification [29].

If an upstream router w does not hear from its downstream router n upon the expire-time

timer expiration, it removes the state and the fonvarding cache entry as if the subtree

TS(u) were Rushed. Later when an echo-request message €rom the router 14 re-appears at

router w, router w, instead of establishing the state and the fonvarding cache, as the

current CBT specification specifies, it flushes the sub-tree. This is because during the

penod when router w and its upstrearn routers believe the subtree is Bushed, if a new join

request arrives at one of these in-tree routers, it rnay be approved when it could actually

be denied when the subtree is taken into accourt

If an y of the join-reqzirst or join-acknoivledgnient messages is lost. the transient state

established at each router on the path from the requesting router v to an in-tree router rit is

removed upon timer expiration. The state created on the path dong which join-

acknowledgment message traverses will eventually tirne out. due to the lack of rclzo-

rerptest messages from downstream. Similarly. if any lrave-nutiJcntion message is 10%

the valid state maintained at upstream routers. will eventually time out. due to the lack of

rclio-rrrpest messages from downstreüm. For example. if a joi~t-ncknoirlerign~ent

message is lost on its way back to the in-tree router at which the join request initially

amives. some upstreüm routen have changed their ternporary stcitc into valid soft state.

while other downstream routers rcmove thcm. But thcn the soft s t m m~intained ;it

downstream routers will be adjusted upon receipt of the next echo-rrqzirst message.

When a lenve-notificntion message is lost on its way upstream, the soft state maintained

at upstream routers will be adjusted upon receipt of the next eclio-recprest message.

However. during the transient period new join requests mny be erroneously rejected

because of outdated state kept at some upstream routers.

3.4 Summary

In this chapter, we have presented MInP, a protocol for establishing a multicast

distribution tree for applications with QoS requirements. Unlike previous protocols

Mn.. uses a modified greedy approach to add new participants into the existing multicast

tree.

Chapter 4

Simulation Results

In this chapter. we evaluate the sffectiveness of MInP in t e m of end-to-end dehy.

network usage and overhead performances. We experiment with different network

topologies. In section 5 . L, we provide an overview of the simulation model. In section

5.2. we discuss our simulation results. In section 5.3, we summririze Our work in this

chapter.

4.1 Implementation Overview

For our work. we used the Network Sirnulritor (NS) version 2.1b6 from

UCBlVlNTlLBNL to simulate the network and protocol behnvior. We selected NS

because it allows construction of detailed protocol models. We implemented the MInP

protocol in NS to compare its performance with the existing implementation of DVMRP.

PIM-DM. PIM-SM, and CBT.

In NS. the user defines arbitrary network topologies. composed of routers, links and

shared media. Protocol instances can then be attached to nodes. The routing model can

be static or dynamic and it has support for multicast routing. The simulator is event

a v e n and runs in non-real-time fashion.

41.1 Protocol Cornparison

To investigate the implementation of MInP. we examined the performance of the

fo 110 w ing protocols:

MInP (delay). We used an irnplementation of MInP that we developed for NS. This

version of MTnP selects. among the several feasible paths Idelay and bandwidth

constrained). the path wit h the minimum end-to-end delay between the new-node and the

multicast tree. if there is a tie. then MnP selects the path with the rnmimum available

bandwidth. The path should satisfy the minimum available bandwidth requirement.

DVbIRP. We used the existing ;YS implementation of DVMRP. The protocol creates

source specific minimum hop trees. which are expected to show low end-to-end delays.

Although it is not scalüble. it provides a good reference point.

PM-DM. We use an NS implementation o f P M dense-mode protocol. Where any

node that receives data for a particular multicast goup for which it has no downstream

receivers. send a prune upstream. A prune message causes the upstream node to initiate

prune stüte at that node. The prune stiite prevents thiit node from sending data for that

group downstream to the node that sent the original prune message while the state is

active.

PM-SM. We used the simple s h e d tree implementation of PIM-SM that is currently

available in NS. A Rendezvous Point (RP) rooted shared tree is built for a multicast

group. Multicast packets from the senders to a group are unicast to the RP. Then the RP

fonvards the pac kets using the multicast distribution tree.

CBT. We used an implementation of a bi-directional shared tree protocol similar to

CBT, available in NS.

For this we created a simulation for each protocol using NS. The implementation was

written in Otcl and Tcl/Tk under Linux environment.

4.1.2 Graph Modeis

The study of algonthms and protocols, that address intemetworking problems such as

rouring, cften in~ol res simuhtlon using 2 mode1 of the .ecc!~ia! netwwk ntrncture md

applications. The main reason is that it is difficult and expensive to have testbeds large

enough to be interesting, and that generally it is more efficient to examine solutions using

simulations if the model is a good abstraction of the real network. At the same time.

simulations allow the exploration of complicated scenarios that would be either difficult

or impossible to ünülyze.

A basic question for a network simulation is what topology to use for the network being

simu lntrd. Unfortunately. the topology of the Intrmet is difficult to characterize. Fint. it

is çonstantly changing. Second. the topology is cngineered by a nimber of different

domains [4 11.

Graphs are commonly used to model the structure of internetworks. for the problems

ranging from routinz to resource reservation. A vnriety of grûph models are found in the

literature. including regular topologies such as stars or meshes. topologies such as

ARPAnet or MBone. and randomly generated networks. The most recrnt and

comprehensive study of creating graphs that model Internet topologies is conducted by

Zrgura cr cil. [QI. Their work compares the several ways of creating realist ic models.

As we know, the Internet is a hierarchical network. It that can be viewed as a collection

of interconnected routing domains [4 11 administered by di fferent managers. w here

groups of nodes share routing information. A primary characteristic of these domains is

routing locality, where the path between any two nodes in a dornain stays entirely within

the domain. Each routing domain in the Intemet can be classified as a stub domain or a

transit domain. A domain is a stub dornain if the path connecting any nodes u and v goes

through that domain only if u or v is in that domain. The purpose of transit domains is to

interconnect stub dornains efficient ly ; w it hout them, every pair of stub domains would

need to be directly connected. For example, if ii is in domain (I and v is in dornain V, the

path from ti to v goes From U, through zero O more transit domains, to V.

Fust, we used a partial 1996 MBone topology with 255 nodes. Second, we used flat-

randcm gmphs, which xe often used to mode1 the inter-domain topology We wented tn

evaluate the protocols on richer topologies. so we constnicted three W ~ ~ r n a n topologies

with 100 nodes and different number of links. Third, we constmcted a hierarchicül gaph

with LOO nodes that reflects the properties and structure of real networks. We chose

graphs of LOO nodes to be on par with the graphs typically used by other researchers for

experimentat ion

In selecting graph models. WC would prefer to have a number of red topologies.

Unfonunately. it is difficult to O btain cornpiete topological descript ions of the Intemet.

We were able to use a 1996 MBone trace of a portion of the real gaph of the MBone.

nvailable in the NS package. We used this trace to generrite the partial 'vR3one topology.

so we could illustrate MInP's behrivior in a topology of what wns a real network. The

graph resembles a transit-stub graph. with n core component of nodes and a large number

of stubs. The gnph has 255 nodes and 766 undirecteci edges (or duplex links). that leads

to a node degree of 2.05. Full duplex links with capacities of 5 12 kbps were used in the

expenments.

In order to avoid lirniting ourselves to a specific network (Le.. widening Our range of

topologies), we generated random network topologies.

The flat (Le., non-hierarchical) random methods have k e n widely used in studies in the

communications networks communit y [43-461. After the Pure Random Model, the most

cornmon random graph mode1 is one proposed by Waxman [47]. The random graphs

used in the simulations were constructed using the Waxman method, where the

probability function ic alter in order to hetter refiect real networks structure. The n nodes

of a gaph are randomly placed on a Cartesian coordinate grid. and edges are added

between nodes on a probabilistic basis that favors pairs of nodes of srniil1 Euclidean

distance from each other. The ( x y ) coordinates of each node were selected uniformly

from integers in [O.n). Considering al1 possible pairs of nodes. edges are placed

connecting nodes with a probability

where d(ti ,v) is the Euclidean distance between nodes ii and v. and L is the maximum

possible distance between any two nodes. The parameters cc and lire in the range (0.11

and cm be selected to obtüin desircd charxtenstiçs in the graph. For csiirnple. ri large

gives nodes with a high average degrce (i.c.. increnscs the total numbcr of edgcs in the

graph), and a small c< gives long connections (i.e.. increases the nurnber of long edgrs).

Noronha and Tobagi [48 ] have shown that the simulation performance of multicast

algorithms is almost identical to the its performance on a real network performance, when

its node degree 22. The flat-random gaphs used were designed to be sparse with the

average k ing less than five. simply to capture the flavor of real network topologies in

which Links between nodes are still relatively expensive.

The flat random graph methods offer very Iittle control over the structure of the resulting

graphs. These non-hierarc hical networks, while the predorninant choice by many

researchers, miss essential details of real topologies such as lower average node degree.

They do not capture the hierarchy structure that is present in real networks, though they

may reflect some notion of locality if certain nodes are more likely to be connected than

others.

For Our hierarchical gaph. we used the mode1 proposed by Zegura et al. [42], which

yroducer gaphs composed nf interconnected transit and stubs domains. It fust constructs

a connected random graph (using an y of the Waxman methods): each node in that graph

represents an entire transit domain. Each node in that grüph is then replaced by cinother

connected randorn graph. represent ing the backbone topo logy of one transit domain.

Next. For each node in each transit domain, we generate a number of connected random

graphs representing the stub domains attached to that node. Finally, we added some

number of additional edges between pain of' nodes. one from a transit domain and one

from a stub, or one l iom e x h of two different stub domains.

Transit Domains

. =---/& Stub Domains

Figure 4.1: Intemet dornain structure

We used the Georgia Tech Intemet Topology Mode1 (GT-ITM) package to generate the

hierarchical model. Table 4.1 show the properties of the different network topologies

used for the simulations.

Links 1 Node Degree Network

Waxman 3.54

-- -

Table 4. L: Properties of network topolo=ies

4.13 Simulation Environment

Nodes

Waxman 4.94

In our simulations, we randomly chose ri single RP or Core node for the shued tree

multicÿst protocols. The RP for the multicast group in a PM-SM simulation was placed

at the same Iocation as the Core in the CBT and MInP simulation.

LOO

We performed a series of sirnuliitions for sach combination of network topologies. E x h

simulütion consistrd of generriting a rnulticrist instance with 1-10 sources and 1-30

receivers. The total number and identity of the sources and receivers were chosen

randomly. Each group member joined and left groups randomly throughout each

simulation.

1 O0

The bandwidth and the delay of each link were randomly chosen. The link bandwidth

and delay distributions were inrended to capture the effect of sevenl sources such as

congestion, switching delay, etc. However, instead of computing these bandwidth and

delay based on a model of the reservation state of the network. we simply assigned them

to each link from the distribution. The network topologies did not change during the

simulation and no packets were lost.

354 3.54

494 4.94

Note that we are mainly interested in comparing end-to-end delay between protocols and

not in its absolute value, since the absolute value directly depends on the mean of the

delay distribution used on the links. The artificial gaphs presented were based on a

uniform delay distribution fiom 10 to 100 ms. also the bandwidth on each link was

uniformly diçtributed from LO Mbps to 100 Mbps.

In ?IIInP simulations, sny source corild reser:e 2 f rxt icn of its cutgcing hmdwidth equa!

to the equivalent bandwidth [491 of the multicast session traffic. A link could accept QoS

multicast sessions and reserve bandwidth for them until its reserved bandwidth exceeded

85% of the link's çapacity. then it got sûturated. This admission control policy allowed

statisticnl rnultiplexing and efficient utilization of rivailable resources.

4.2 Experiments Results

We performed fivs rxperiments with the uniform delüy distribution, these corresponds to

one biBone grüph. three Waxman grciphs of different node degrees, and one Hierurchical

graph. For each topology. we repeated the experiments for a total of 200 iterations.

In the absence of wel l-understood models of multicast participant khavior. this mode1

does not favor any prorocol. As we expected. wc obtained qualitcitively similiir results for

al1 the different graphs.

42.1 End-to-End Delay Performance

The end-to-end delay refers to period of time required for a data packet to be routed

through the network from the node where it was created to al1 members of the multicast

group. Table 4.2 shows the maximum and average end-to-end delay performances (in

terms of seconds) seen by the receivers.

Expenment 1 Metnc 1 DVMRP

MBone 1 Max 1 2.687

1 Avg 1 1.333

Waxman3.08 1 Max 1 1.241

Avg 0.534

Waxman 3.54 Max 0.9 19

Avg 0.425

Waxman 4.94 Max 0.592

Hierarc hical 0.90 1

PM-DM 1 PM-SM 1 CBT 1 MInP

Table 4.7: The end-to-end delay observed by receivers in seconds using the uniform

delay distributions.

The end-to-end delay measurements of DVMRP. PIPI-DM. PIM-SiM. and MInP for the

MBone topology are shown in Figure 4.2. The delays are computed by simply adding the

link delays From the sources to the destinations.

0.3

0.7

0.6 Fraction of rccrivers U j

0.4

0.5

0.1

0. 1

O

Figure 4.2: Fraction of nodes below an end-to-end performance vaiue using the uniform

delay distribution: MBone graph.

Figure 4.2 shows the Fraction of receivers that obtain end-to-end delays lower than or

equal to a certain value, expressed as a function of the end-to-end delay value on the .Y-

a i s . We observe that MInP provides end-to-end delays between the performance of the

trees created by the other protocols. which exhibit approximately 12% less delay than the

PIM-SM'S and CBT's shared trees. The end-to-end delays are roughly the same between

the source-based distribution trees of DVMRP and PM-DM. and also between the shared

distribution trees of PIM-SM and CBT. On investigation. we found that the reason is due

to the MBone topology. which is cornposed of stub-trees. hanging of a sparse backbone

mesh. Even though MinP constructs shared trees. it performs better thrtn PIM-SM and

CBT. The improvement in blocked cnlls cornes from the consideration of the QoS

information.

. . . -. . . . . DL'hIRP --- PIXI-DXt --- P M - S M -.-* CBT - MlnP

Figure 4.3: Fraction of nodes below an end-to-end performance value using the uniform

delûy distribution: Waxman tlat Euclidean p p h s (node degree 3.08).

In Figure 4.3, when compare the end-to-end delay performance of iWnP with PIM-SM.

and CBT, it improves the blocking probability for delay sensitive applications

considerably. For example, for a 0.6 seconds delay bound, the blocking probability is

reduced from 80% (for PM-SM) and 85% (for CBT) blocked receiven to 65% blocked

receiven (for MInP). An alternative way of viewing the same data is that the average

delay is reduced by more than 8%.

From Figure 4.3 to Figun 1.5, we show the end-to-end periormance of DVMRP, PIM-

DM, PIM-SM, CBT, and MInP on the Waxman flat random graphs with average node

degree varying from 3.08 to 4.94. This series of graphs clearly indicate that the end-to-

end performance of MInP is always better compared to PIM-SM and CBT regardless of

the network topologies.

. .. .--. . DVhlRP --.. Plhl-Dhl ..--. PIAI-SM -.-. CBT - (cllnP

Figure 4.4: Fraction of nodes below an end-to-end performance value using the uniform

de lay distribution: Waxman flat Euclidean graphs (node degree 3.54).

Fraction of receivcrs

n 0.1 0.2 0.3 n.4 0.5 0.6 0.7 0.8 0.9

End-CO-end dehy (seconds)

.y-. DVhlRP --- PM-DM

.- PIM-SM -a-. CBT - W n P

Figure 4.5: Fraction of nodes below an end-to-end performance value using the uniform

delay distribution: Waxman flat Euclidean graphs (node degree 5.52).

Figure 4.6: Fraction of nodes bdoiv ;in end-to-end performance value using the uniform

delay distribution: Hierarchical graph.

In Figure 4.6. when we look at the performances for the hienrchicnl graph. we compare

the end-to-end delay performance of MInP with PM-DM. and D W . WnP stnkes

the balance between the shared tress and the source-bûsed trees. Here. the gap between

M n P and the source-tress decreases. For cxnrnple. for a 0.5 seconds deloy bound. the

blocking probability is 33% for DVMRP and 40% for CBT. while for iWnP it is 52%

blocked receiven. This indicates that denser topologies. with more alternate paths.

benefit more from the QoS metric büsed routin: siich as iWnP c m provide. This shows

the importance of QoS routing in future networks with more dense topologies.

The average of a11 end-to-end delay merisurements in our simulations is shown in Figure

1.6 for each protocol and each network topology. These values are normalized by the

average end-to-end de lay for the MinP protocol under the same simulation environment

and with the same simulation parameten.

Waxman 3 53 Waxman 4 94 Hierarchical

IQDVMRP . PIM-DM OPIM-SM OCBT /

Figure 4.7: End-to-end delay performances relative to MInP.

M R P and PM-DM deliver packets L 1% to 3 1% faster than IvlInP. while P

CET deliver packets 7% to 18% siower than MInP. depending on the topology simulated.

The largest improvement of source- büsed tree protocols over shared trees pmtocols were

observed for the low node degree topologies. We remind the reader that the amount

network States and control overhead created by source-based tree protocols makes then

not appropriate for large networks. The end-to-end delay of iWnP is ü sood compromise

between the shared tree protocols and the non-scalable source-based tree protocols.

4.2.2 Network Processing Usage Performance

For our experiments, then we evaluated the routing efîïciency of DVMRP. PIM-DM.

PIM-SM, CBT. and MInP from the viewpoint of network processing usage. We

computed the total cost of the distribution tree of the different protocols, i.e., the total

number of links that copies of a packet travel to reach al1 rnulticast group rnembers. The

number of links were computed by calculating the total number of times a data packet

was forwarded for delivery to every member of the multicast group.

To help route a packet to al1 interested receivers, unicasting uses several copies of the

sarne packet over the same Links in the network. However, the rnulticast protocols send

only a single copy of the packet over any link of the network and require fewer links or

hops to deliver the packet than that of unicast routing.

The Shared tree protocols (PM-DM. CBT. and M M ) route packets on a common tree

for greater distances. Even though the packets do not tnvel on the shonest path to the

receivers. they may use fewer overall hop than source-based tree protocols to reach al1

destinations.

MBone Waxrnan Waxman Waxman Hierarchical

: DVMRP IPIM-DM O PIM-SM 0CBT 1 !

Figure 4.8: Network processing usage relative to iLUnP.

The network processing usage results show in Figure 4.8 illustrate thüt PliCl-SM. CBT,

and MInP require similar number of links to deliver a multicast packet to multicast group

rnembers in each of the network topologies consider. The minor difference is due to the

oreedy approach of MInP, which causes the links to be more "shared" than in PM-SM &

and CBT. These measured values are normalized by the measured value for MInP under

the same simulation environment and with the same simulation parameters.

Figure 4.8 shows that the measured network resource usage for DVMRP and PIM-DM

are much larger than the network processing usage of the other protocols. This difference

is due to the penodic flooding, which, in some cases. is more than the double of the

number of data packets counted in some of our simulations. We remind the reader that

the source-based tress protocols de liver pac kets dong the s hortest pat hs from each

cmrce, hiit as the numher of sources increases. the number of distribution trees increases.

Examinat ion of individual simulation results shows that the network processing usage of

DVNlRP and PM-DM approach that of PIM-SM. CBT. and MInP as the network

becomes more denseiy populated with receivers for each multicast group. This result is

enpected because D W I R P and PM-DM were designed For a dense membership

environment with huge bandwidths

4.2.3 Overhead Traffic Percentage

For our experiments. we also examined the overhead traffic percentage of DVMRP, P M -

DM. PIM-SM. CBT, and MnP. We computed the overhead packets required by each

multicast protocol to set up. maintain the distribution trees used for routing multicast

data. In our simulations. we measured the size of rach type of pncket. and from these

values we computed the percentage of the total number of bits transmitted thlit are

overhead bits. These percentages are shown in Figure 4.9 for eüch protocol and eüch

network.

W a x m 3.08 Waxrrian 3.54

1

Figure 4.9: Overhead percentage cornparison.

Figure 4.9 shows that CBT has the lowest percentage of the protocols examined.

approximntely 4% PM-SM also has a low overhead percentage. only 1% to 2% greater

than the percentage measured for CBT. DVbIRP and PM-SM have more thm double

the percentage for MInP. since both source-bnsed tree protocols set iip more compliçatcd

trees. In addition. rach tirne a hosr requests to join ii multicast group, ovsrhcad messages

must be sent to çach source f the group to set up a branch of the multicüst tree for that

source, while on the share tree pmtocols only one tree needs to be updated. In some

simulations for the Wiixman 4-94 topology. the percentage of overhead was measured to

be almost 6%. since there are more paths to flood the data, thus the overhead percentase

was greater for this topology The overhead performance of PM-DM and DVMRP are

worse due to the data packets that are flooded but do not reach a multicast group receiver

are consider overhead.

The overhead traffic percentage of MI* was at times four times higher than that of CBT

and PIM-SM. The message overhead is contributed, in large, by the candidate search

procedure (when a new member searches for a feasible route to an in-tree router), rather

than in the stage of conducting delays tests and States updates. Fig 4.9 shows that the

message overhead introduced by MInP.

It is important to note, that the number of overhead messages required to maintain the

distribution trees depend on the number of members joining the multicast group. and not

OF. the amount of twffic sent to thnt rnulticart group. 41so. the overhead percentages

would be smaller for higher levels of traffic because these percentages are related to the

level of traffic in the network.

4.3 Summary

In this chapter. we enaminrd and çompüred the end-to-end delay, network processing

usage. and overhead traffic percentage of DVMRP. PM-DM. PIM-SM. CBT. and M h P

in various network topologies. Wc show t hat QoS-based routing protocols c m reduce

cal1 blocking significantly for applications with strict QoS requirements, in some cases

increasing the number of satisfied participants by 25% as compared to other shared tree

prorocols. if we imagine a commercial scenario. with paying custorners. it is rasy to see

the importance of QoS routing protocols. Furthcr, kUnP exhibits bctter end-to-cnd delay

performance than PIM-SM and CBT regürdless of the nrtwork iopolo jics. Wc lilso

found thüt for higher node degrec topologies. MInP could perform n ~ i r DVMRP micl

PM-DM. This in spite of the fact that DVMRP and PIMDM have scalability problems.

However. in the absence of real Intemet trafic measurements. we cannot make any

strong daim of the üpplicability of this result to the Intemet.

The end-to-end delay performance gain of MInP cornes From two aspects. First, MInP

searches for paths between the new rnember and the neighboring routers of the tree,

instead of joining to a predetermined core router. Second, given the multiple path

routing, MInP improves the routing hinher by selecting the path that meets the QoS

requirements.

The network resowce usage performance is sirnilar to the shared trees protocols (PM-

SM, CBT, and MInP). whereas the performances of the source-based tree protocols

(DVMRP and PM-DM) are much higher due to the periodic floods of data on the

network.

The high overhead traffic percentage of MInP is a possible weakness, since it relies on an

extensive candidate renrch prncediire to find altemate p t h s for a new multicast group

member.

We believe that MInP is a good compromise between the shared tree protocols and the

source-based Cree protocols. allowing the more scnlable shüred tree approach to be used

for the QoS-sensitive applications.

Chapter 5

Conclusions

In our work. we designed the iCLlnP protocol. an IP-multiçast routing framework based on

seleçtive probing thüt is capable of supporting QoS-sensitive applications. The end-to-end

guarantees. bandw idth and delay. are provided by requirin; bündw idth reservat ions.

MInP çonstructs a QoS shared multicast distribution tree with explicit rnember join and soft

stüte update procedures. while rnaking the minimum possible impact to the existing

infrastructure. Every node in the network maintains its local stare and no global stüte is

required. The algorithm uses a distributed computation to collectively utilize the rnost up-

to-date local state at rach node to find a Cüsible path.

\Vc irnplemcntcd the M n P protocol in a JctailcJ simulatioii cnvironmcnt and invcstigatd

its performance under realistic network conditions. Simulations w r c gcnercitcd by YS.

which wÿs augmented to include ;LUnP. First. we look at its end-to-end delay performance

across a range of network topologies and under different assumptions of the network link

delay distributions. Second. we examined the net work processing usage performance to

show that it efficiently use network resources. Finally, we evaluated the higher overhead

tnffic percentage associated with the QoS-enhancements of MInP.

Contributions

We designed the MInP protocol, a promising Intemet protocol that is able to support QoS

requirements. However, supporting QoS requires increased control overhead compared to

other QoS-insensitive protocols. Its routing uses the greedy approach in a flexible and

dynamic frarnework. A major innovation of MI# is that it has joidleave procedures that

deal with multiple membership changes in ü decentralized manner. Specificaiiy. we

devised auxiliary delay tests to determine whether or not the join of a new member at an in-

tree router rnay affect the stüte information kept at other in-tree routers and the subsequent

procedure. in case that the sttite information needs to be updtited.

.\ significant advantage of iLUnP is that it considers asymmetry of the network in its

routing. The role of routing is to provide patiis that can actually support the trriffic of ri

connection. There rire crises where the links are physicnlly asymmetric or even one-wüy.

In addition. MInP takes advrintage of the higher routing efficicnçy (sm:illcr trce cost) of rhc

greedy approach. as we saw in section 4.2.2.

Another design feriture is the ability of a joining node to exchange information with in-tree

nodes. This aIlows the joining node to select the püth thüt ba t sütisfics thc desircd QoS

reqiiirements.

The bi-directional shared trees constructed by MhP, where packts can tlow in either

direction on a branch of a tree, allows improved packets delivery. since packets from

sources to topologicülly nerirby receivers do not have to travel al1 the way to the core

router. It also takes advantage of the reduced per-group States kept at the routers, a basic

characteristic of shared trees protocols.

We investigated the end-to-end delay performance of MInP and compared it with existing

protocols such as DVMRP, PM-DM, PM-SM and CBT. We experîment with both real

and artificial graphs. Our results show that MInP can reduce the cal1 blocking of shared

trees protocols, it always exhibit better end-to-end delay performance, regardless of the

network topologies. From our experimental data, we also show that MInP could perfom

near the source-based trees protocols performance, which are not scalable for inter-domain

communications. Based on these expenmental res.ilts, we believe that the delay sensitive

applications will benefit from QoS routing, such as MinP.

Then we examined the effectiveness of MInP in using network resources across a range of

network tcpo!ogies. Our experimentz! resubs show that the use Mn! reducer the number

of links used by the distribution tree, and the number of copies that in-tree routers

forwarded and processed. The cost of EvIInP's distribution tree is the lowest among the

protocols simulated. and less number of copies (packets) need fonvarding and processing.

We also examined the overhead traffic generated by MInP. We show thnt the high

overheüd traffic percentüge of MinP is a possible weakness. since it relies on an extensive

ccmliclnfr senrcli procedure to End altemate paths for a new multicast group member.

In conclusion. MInP promises gain in the efficiency of the network to support reül-iime

multicast applications in t e m . We believe that MInP is a good compromise between the

shared t ree protocois and the source-based tree protocols. allowing the more scalable shnred

tree üpproach to be used for the QoS-sensitive applications.

5.2 Future Work

The iWnP protocol establishes a basis for more resenrch and implementation work. First.

we would Iike to mode1 in more detail the Internet environment: wc would like to merisure

membenhip behavior and identify the topology of the network. Second, we want to fine-

tune our protocol, according to the properties and needs of Intemet sessions, with a detailed

design specification including exact message, timers and protocol syntaxes. Third, we can

impiement our protocol and test it on real networks.

Several functions of our protocol, such as the candidate selection, cm be irnplemented in

different ways. For example, we could make the joidleave request decisions only at the

fîrst in-tree node, hence the routing response time can be shorter and the algorithm would

be more scalable. The framework should be simple, which enables an efficient

implementation, and extensible, so that new QoS metrics, such as delay-jitter, could be

easily added without affecting the existing ones.

MInP's abiiity to exchange information between a joining node and an eeisting tree opens a

niimher o f areas for future work. One example would be the inclusion of better policies.

both rationai and irntional, that determine how the protocol selects the best path towards a

cnndiclntr router. Rational policies beins those that describe the network related

characteristics. and irrational policies being those that are not directly related to the

capability of a network. such as pricin:.

Bibliography

H, Eriksson. "PVIBONE: The blulticrist Backbone," Communications of the ACbI.

Aug. 1994.

D. Br rtse kas. LMenr ~Venvork Optinr i:(ztiori: Algorirltttrs nrid Codes. ;MIT Press.

1991.

S. Deering. C. Partridge. and D. Waitzman. "Distance vector multicast routins

protocol." RFC 1075. Nov. 1985.

S. Deering. "Multicast Routing in a Datagram Intemetwork." Ph. D. dissertation.

Stanford University. Dec. 199 l . S. Deering, "Host Extensions for IP Multicasting," RFC 11 12, Aug. 1989.

D. Bertsekas and R. Gallager. Data Neni.orks. Prentice-Hall. 2nd ed.. 1992.

H.F. Salama. D.S. Reeves. and Y. Viniotis. "Evnluation of Muliicast Routing

Algorithms for Real-Time Communications on High-Speed Networks." IEEE

JSAC. Apr. 1997.

J. Moy, "OSPF Version 2," WC 1583. Mar. 1994.

D. Oran. "OS1 IS-IS Intra-domain Routing Protocol," RFC 1 143, Feb. 1990.

G. Malkin. "NP Version 2." RFC 3453, Nov. 1998.

Y. Rekhter, and T. Li. "A Border Gateway Protocol 4 (BGP J)." W C 177 1. Mar.

1995.

Z. Wang and J. Crowfioft, "QoS Routing for Supporting Resource Reservation,"

EEE BAC, Sept. 1996.

G.N. Rouskas and 1. Baidine, "Multicast Routing with End-to-End Delay and Delay

Variation Constraints," IEEE JS AC, Apr. 1997.

L. Kou, G. Markowski, and L. Berman, "A Fast Algorithm for Steiner Trees , "

Acta Informatica, 198 1

H. Takashi and A. Matsuyama, "An Approximate Solution for the Steiner Problem

in Graphs," Mathematica Japonica, Feb. 1980.

V. Rayward-Smith, 'The Computation of Nearly Minimal Steiner Trees in Graphs,"

International Journal of Mathematical Education in Science and Technology, Jan.

!W.

R.C. Prim, "Shortest Connection Networks and Some Generalizations," The Be11

S ystems Technical lournül. Nov. 1957.

V.P. Kompella. J.C. Pasquale. and G.C. Polyzos. "Multicnsting for Multimedia

Applications." I E E U X M Transactions on Networking. June 1993.

Q. Sun and H. Langendorfer. "Efficient Mu lticast Routing for Delay-Sensitive

Applications," 2"%orkshop Proiocols Multimedia S ystems, Oct. L995.

Q. Zhu. M. Parsa. and J.J. Garcia-Luna-keves. "A Source-Based Mgonthm for

Delay-Constrained Minimum-Cost ~Multicüsting." IEEE INFOCOMT95. Apr. 1995.

V.P. Kompella. J.C. Pasqunle. and G.C. Polyzos. 'Two distributed Algorithms for

Multicasting Multimedia Information." International Conference on Computer

Communication and Network. June 1993.

S. Chen and K. Nahrstcdi. "Disttibuted QoS Routing with Imprecise State

hformation." Intemationûl Conference on Cornpliter Commiinicütion ancl Yctwork.

Oct 1998.

K. Carlberg and J. Crowcroft. "Building Shared Trees Using One-to-Mmy Joining

Mechanism." Computer Communications Review, Jan. 1997.

D. Waitzman. C. Partridge. and S. Deering, "Distance Vector Multicast Routing

Protocol," RFC 1075, Nov. 1988.

S. Deenng and D. Cherîton. "Multicast Routing in Datagram Intemetworks and

Extended LANs," ACM Transactions on Computer Systems, May 1990.

J. Moy, "MOSPF: Analysis and Experience," RFC 1585, Mar. 1994.

D. Estnn et al., "Protocol Independent Multicast-Sparse Mode (PM-SM): Protocol

Specification," RFC 2362, June 1998.

S. Deering et al., "Protoc01 Independent Multicast-Dense Mode (PM-DM):

Protocol Specification," Internet Draft, June 1996.

A. Ballardie, T o r e Based Trees (CBT version 2) Multicast Routing," RFC 2189.

Sep. 1997.

T. Billhartz and J. Cain, "Performance and Resource Cost Cornparisons for CBT

and PIM Multicast Routing Protocols". IEEE JSAC, Apr. 1997

G. :\postolopoulcs et al.. "QoS Routing Mec hsnisms and OSPF Extenr ions".

Internet Draft, Apr. 1998.

K. Carlberg and I. CrowcroR. "Yet Another Multicüst ( Y ,LM) Routing Protoco 1:

Specification Version 1 ." Computer Unpublished manuscript. 1997.

A. Bnnerjea. M. Faloutsos. and R. Pankaj. "Designing QoSMC: ri QoS Multiciist

Intemet protocol." Interner Drüft. 1998.

S.K. Biswas et cd. . "A QoS-Awarr Routing Framework for PM-SM." Intemet

Draft. June L 999.

W. Fenner. "Intrmet Group Management Protocol: version 2 (IGMPv2." Intemet

Draft. 1998.

C. M. Aras. J.F. Kurose. D.S. Reeves. and H. Schulzrinne. "Real-Time

Communication in Packet-Switched Networks." Proceeding of the IEEE. Jan. 1994.

H. Zhang. "Service Disciplines for Gtixmtced Pcrformrince Service in Piicket-

Switching Networks." Proceedings of the IEEE. Oct. 1995.

M. Handley and V. Jacobson, "SDP: Session Description Protocol." W C 2337,

Apr. 1998.

S. McCanne. V. Jacobson. and M. Vetterli, "Receiver-driven Layered Multicast,",

XCM SIGCOMM'96. Aug. 1996.

R. Braden er al.. "Resource ReSerVation Protocol (RSVP) : Version 1 Functional

Specification". RFC 7205. Sep. 1997.

D. Clark, "Policy Routing in Intemet Protocols." RFC 1 102, May 1989.

E.W. Zegura, LL. Calvert, and M.J. Donahoo, "A Quantitative Cornparison of

Graph-based Models for the internet Topology," IEEElACM Transactions on

Networking, Dec. 1997.

[43] M. Doar and 1. Leslie, "How Bad is Naive Multicast Routing?," IEEE

DIF0COM793, 1993.

[44] H.F. Salama, D.S. Reeves, and Y. Viniotis, 'Zvaluation of Multicast Routing

Algorithms for Real-Time Communications on High-Speed Networks," IEEE

JSAC. Apr. 1997.

[45] V.P. Kompella. J.C. Pasquale, and G.C. Polyzos, "Multicasting for Multimedia

Applications." IEEWACM Transactions on Networking. June 1993.

(461 L. Wei and D. Estrin, 'The Trade-offs of Multicast Trees and AIgonthrns."

[ntemationiil Conference on Computer Communications and Network. Aug. 1994.

[47] B .M. Wnxman. "Routing of Multipoint Connections." IEEE JSAC. Dec. 1988.

[4S] C.A. 'loronhtl and FA. Tobagi. "Evaluat ion of Mult icrist Roi@ AIgorithms for

Multimedia Streams." International Te lecommiinications S ympositirn. Aug. 1994.

[JO] R. Guerin. H.Ahrniidi. and M. Naghshineh. "Equivdent Capocity and hs

Applications to Bandw idth Allocation in High-Speed Networks." IEEE JS AC. Sep.

1491.