Incremental deployment service of hop by hop multicast routing protocol(synopsis)

Incremental deployment service of
Hop by hop multicast routing protocol

(Synopsis)

INTRODUCTION
About Hop-By-Hop Multicast Routing Protocol
IP multicast is facing a slow take-off although it has been a hotly
debated topic for more than a decade. Many reasons are responsible for
this status. Hence, the Internet is likely to be organized with both unicast
and multicast enabled networks. Thus, it is of utmost importance to
design protocols that allow the progressive deployment of the multicast
service by supporting unicast clouds. This paper presents HBH (hop-byhop multicast routing protocol). HBH adopts the source-specific channel
abstraction to simplify address allocation and implements data distribution
using recursive unicast trees, which allow the transparent support of
unicast- only routers. An important original feature of HBH is its tree
construction algorithm that takes into account the unicast routing
asymmetries. Since most multicast routing protocols rely on the unicast
infrastructure, the unicast asymmetries impact the structure of the
multicast trees. We show through simulation that HBH outperforms other
multicast routing protocols in terms of the delay experienced by the
receivers

and

the

bandwidth

consumption

of

the

multicast

trees.

Additionally, we show that HBH can be incrementally deployed and that
with a small fraction of HBH-enabled routers in the network HBH
outperforms application-layer multicast.

Benefits of Hop-By-Hop Multicast Routing Protocol
The IP Multicast architecture is completed by group addressing and
routing protocols. A multicast group is identified by a class-D IP address
which is not related to any topological
information, as opposed to the hierarchical unicast addressing model.
Therefore,

multicast

address

allocation

is

complex,

and

multicast

forwarding state is difficult to aggregate. Currently, there is no scalable
solution to inter-domain multicast routing. The approach used is to
connect different domains through MBGP (multiprotocol extensions to
BGP-4) [2] and MSDP (multicast source discovery protocol) [3]. MBGP is
used to announce different unicast- and multicast-capable routes whereas
MSDP exchanges active source information between the domains. The
configuration

complexity

of

this

solution

works

against

multicast

deployment. On the other hand, backbone operators are currently overprovisioning their networks and thus have one reason less to use
multicast. Nevertheless, ISPs (Internet Service Providers) have interest in
multicast to face the increasing demand for network resources and
content distribution. As a consequence, the Internet is likely to be
organized with both unicast- and multicast-enabled networks. Therefore,
it is of utmost importance to design protocols that allow the progressive
deployment of the multicast service by
supporting unicast clouds.
Different solutions that simplify the multicast service by reducing
the distribution model were proposed. EXPRESS [5] restricts the multicast
conversation to 1 to (the channel abstraction), simplifying address
allocation and data distribution, and still covering most of the current
multicast applications.

SYSTEM ANALYSIS
EXISTING SYSTEM:
The existing system related to Hop-By-Hop Multicast Routing
Protocol is namely the EXPRESS and REUNITE protocols.
EXPRESS [5] provides a simple solution to the multicast address
allocation problem, introducing the channel abstraction that reduces the
multicast conversation from to to 1 to
. A channel is identified by the pair , where is the unicast address of the
source and is a class-D multicast address. The concatenation of a unicast
address with a class-D address solves the address allocation problem
since the unicast address is unique. The channel model introduced by
EXPRESS also simplifies group management issues such as sender access
control. Nevertheless, the SSM service [6], which was inspired by
EXPRESS and standardized by the IETF, does not change the group
management support provided by IGMP [7].
REUNITE [13] implements multicast distribution based on the
unicast routing infrastructure. The basic motivation of REUNITE is that, in
typical multicast trees, the majority of routers simply forward packets
from one incoming interface to only one outgoing interface, because only
a few routers are branching nodes [18]. REUNITE identifies a conversation
by a pair, where is the unicast address of the source and is a port
number. Class-D IP addresses are not used. As receivers join the group
REUNITE populates its tables to construct the distribution tree, using two
control messages: and . messages travel upstream from the receivers to
the source, whereas messages are periodically multicast by the source to
refresh the soft-state of the tree. Only the branching nodes for the group
keep entries in their MFTs. The control table, MCT, is exclusively used for
tree construction, not for packet forwarding. Nonbranching routers in the
tree have MCT entries for but no MFT entry.

Limitations
The following are the limitations of the existing system.
•

does not change the group management support provided by IGMP

•

The control table, MCT, is exclusively used for tree construction, not
for packet forwarding

•

Nonbranching routers in the tree have MCT entries for but no MFT
entry

•

REUNITE may fail to construct shortest-path branches in the
presence of unicast routing asymmetries

•

Next undesirable behavior of REUNITE is that the route for one
receiver may change after the departure of another receiver. This is
undesirable if some QoS mechanism is to be implemented.

PROPOSED SYSTEM:
The HBH multicast protocol has a tree construction algorithm that is able
to better deal with the pathological cases due to asymmetric unicast
routes. HBH uses two tables, an MCT and
anMFT, that have nearly the same function as in REUNITE. The difference
is that one entry table in HBH stores the address of a next branching node
instead of the address of a receiver, except the branching router nearest
the receiver. The MFT has no entry. Data received by a branching router, ,
has unicast destination address set to (in REUNITE, data are addressed
to). This choice makes the tree structure more stable than in REUNITE

The system can be broadly divided into 4modules:
1. Group Generation
2. Path Discovery
3. Recursive UniCast Trees
4. Hop By Hop Transmission

Group Generation:
In this module, all the nodes that are attached to the
particular node will be displayed in the list and the left and the right
node to which the message has to be sent are selected from the
list. When we want to send a message the data will be sent to those
nodes which are selected from the list.

Path Discovery
The shortest path from the source node i.e.n the root to the
left and the right is found out and the request is sent from the left
and right nodes to the root node by which the shortest path is found
and the message is sent along the shortest path found through the
found shortest path.
Recursive UniCast Trees
 The MFT has no destination entry. Data received by a
branching router Hb, has unicast destination address set to

Hb(in REUNITE, data are addressed to MFT(s).dst). This
choice makes the tree structure more stablethan in REUNITE.
 Non branching routers simply keep
group information in their MCT, whereas
branching nodes keep MFT entries which are
used to recursively create packet copies to
reach all group members.
 Multicasting the data from the source node to the
REUNITE (REcursive UNI cast TrEes) server.
Key idea of REUNITE is to separate multicast
routing
information in two tables: a multicast control table (MCT),
which is stored in the control plane, and a multicast
forwarding table (MFT), which is installed in the data
plane.


Hop By Hop Transmission
The HBH multicast protocol has a tree construction algorithm
which finds the end-host
in the specified subnet by checking node by node.
 This is achieved by checking the every node IP address
against destination IP


Advantages of Proposed system:
•

A multicast channel in HBH is identified by , where is the unicast
address of the source and is a class-D IP address allocated by the
source. This definition solves the address allocation problem while
being compatible with SSM’s channel definition. Therefore, HBH can
support IP Multicast clouds as leaves of the distribution tree.

•

The tree structure of HBH has the advantage of an enhanced
stability of the table entries when compared with REUNITE.

The

tree management scheme of HBH minimizes the impact of member
departures in the tree structure.
•

There is no route changes for other members when a member
leaves the group because the unicast routes are symmetric.

Tree reconfiguration in REUNITE may cause route changes to the
remaining receivers, as for in the example of Fig. 2. This is avoided in
HBH.

PROBLEM FORMULATION
HBH has three control messages: , , and messages are periodically
unicast by the receivers in the direction of the source and are used to
refresh the forwarding state (MFT entry) at the router where the receiver
was connected to the tree. A branching router itself “joins” the multicast
channel at the next upstream branching router. The messages may be
intercepted by the branching routers, which must sign themselves
messages, and filter the messages received from downstream nodes. The
source periodically multicasts a message that refreshes the tree structure.
Messages are sent by potential branching routers and construct the
distribution tree together with the messages.

Objectives
The following are the objectives of the Hop-By-Hop Multicast Routing
Protocol,
•

a multicast routing protocol that implements multicast distribution
through recursive unicast trees.

•

The main goals of HBH are: to support unicast clouds, allowing
incremental deployment; to have a stable tree structure, by
minimizing the impact of receiver departures; and to construct lowcost trees.

•

To reduce administrative costs.

•

To lower error rates.

•

To increase productivity.

HARDWARE SPECIFICATION

Processor

: Intel Pentium III Processor

Random Access Memory
Hard Disk
Processor Speed

: 128MB
: 20GB
: 300 min

SOFTWARE SPECIFICATION
Operating System
Front end Tool
Data Bases

: Windows 98.
: Java Swing and Java Networking
: SQL Server

Incremental deployment service of hop by hop multicast routing protocol(synopsis)

Recommended

More Related Content

What's hot (18)

Viewers also liked (17)

Similar to Incremental deployment service of hop by hop multicast routing protocol(synopsis) (20)

More from Mumbai Academisc (20)

Recently uploaded (20)

Incremental deployment service of hop by hop multicast routing protocol(synopsis)