13-04-2013, 04:14 PM
ZBMRP: A Zone Based Multicast Routing Protocol for Mobile Ad Hoc Networks
[attachment=53054]
Abstract.
In this paper, we propose a Multicast Routing Protocol termed
ZBMRP (Zone Based Multicast Routing Protocol) for Mobile Ad Hoc Networks
(MANETs). ZBMRP applies on-demand procedures to dynamically establish
mesh-based multicast routing zones along the path from the multicast
source node to the multicast receivers. Control packet flooding is employed
inside multicast zones, thus multicast overhead is vastly reduced, and good
scalability can be achieved. It will also be easier to secure multicast routing.
ZBMRP fits well for MANETs where bandwidth is limited, topology changes
frequently, power is constrained and security problem is serious. Simulation
results are presented to support our claim.
Introduction
Mobile Ad hoc Networks (MANETs) is the cooperative engagement of a collection of
wireless mobile nodes that also performs as routers. Nodes in MANETs communicate
with each other through multi-hop transmission that does not need any existing infrastructure
or communication supporting center. Topologies of MANETs may change
quickly. Nodes in MANETs often perform a given task with other nodes together.
This often leads to sending the same information to a group of members. Instead of
sending data packets to each of the group members individually as unicast technique
does, multicast technique allows the source node to send packets to a group of nodes
as a single entity that will be sent only once on the shared path, greatly conserving
network bandwidth on the shared path of the group member.
Zone Based Multicast Routing Protocol Overview
Mesh Created in the Entire Network in the Establishment Phase
When a multicast source has packets to send but cannot find any route and group
membership information, it broadcasts a member advertising and route request
packet, termed RREQ, to the entire network. Only multicast receivers send back a
route reply message, called RREP, in order to allow the source node to get the current
routing information. Then ZBMRP uses the same strategy as ODMRP does [1] to establish
a mesh of nodes for forwarding packets between a multicast source and receivers.
The mesh is created using the forwarding group concept. The forwarding
group is a set of nodes that are in charge of forwarding multicast packets. It supports
shortest paths between any member pairs. A multicast receiver may serve as a forwarding
group node if it is on the path between a multicast source and another receiver.
In ZBMRP, we further classify forwarding group nodes into two categories:
FG-F and FG-B.
Source Zone Creation
After the forwarding mesh between a multicast source and receivers is established in
the entire network, mesh-based multicast routing zones are created according to the
distribution of source node, FG-Bs, and multicast receiving member nodes, i.e. ZANs.
Multicast source node will firstly establish mesh-based multicast zone, named
source zone. It collects the information of its nearest downstream ZANs from RREP
messages that it receives. Such information includes IP address and distance (in terms
of hop counts). If the source’s nearest downstream ZAN is far away from itself, e.g.,
more than 3 hops away, and relatively sparse, then the source node will not establish
source zone (or we can say the zone size is 0). It just tunnels multicast packets in the
unicast packets to its nearest downstream ZANs. If the source node finds many ZANs
within N hops, then it establishes source zone with a zone radius of N. Source node
becomes the leader of this source zone. A zone leader is in charge of constructing and
maintaining a zone. When N is no less than the size of the entire network, ZBMRP
becomes ODMRP.
Branch Zone Creation
If a FG-B gets data packets without zone information, which means it gets the packets
through tunneling, it is outside upper level zone, then it has to create and maintain its
mesh based routing zone according to the distribution of its nearest ZANs. We call
this kind of zone as branch zone. Other FG-Bs inside this zone just join it and will not
create the zone of itself as in FG-B IN source zone does. It is a kind of FDW (First
Declare Win) strategy. This kind of work will continue until the far end of the network.
There are no two or more FG-Bs to contend for building a same branch zone.
If a ZAN resides in multiple zones, it will receive multiple copies of the same multicast
packet from several zone leaders with different zone ID. It then just discards the
replicate packet. Note that, if this ZAN received a replicate packet tunneled from its
upstream ZAN, it needs to send an N-Tunnel message packet to its upstream ZAN to
save bandwidth. Upon receiving data packets without zone information, FG-B will
start establish its zone. Thus along with the data packets delivering, multiple mesh
based routing zones will be established along the path from the source node to multicast
receivers.
Zone and Route Maintenance.
Zone leader periodically broadcasts RREQ message inside zone with TTL equal to N
(zone radius). Every node inside zone that receives RREQ forwards RREQ until TTL
becomes zero. It also sends RREP back to zone leader. With these, zone leader updates
mesh routing inside zone.
For the sporadic ZANs that are not included in any zone, the upstream ZAN of it
tunnels packets to it unless the upstream ZAN receives explicit N-Tunnel messages
from these sporadic ZANs. A periodic positive update of tunneling membership is
also possible. In this technique, the downstream nodes periodically send the upstream
nodes a Tunnel message. Reception of such message indicates validity of the tunnel.
New Node Joining the Multicast Group
During the process of multicasting, if a new node wants to join the multicast group, it
explicitly generates a RREP-R packet that will be broadcasted to its neighbors. This
RREP-R message will be forwarded until it is received by a forwarding group node,
or source node. Then this node will be added to the multicast group, through a zone or
a forwarding route.
If the RREP-R is terminated at the normal forwarding group node with no
branch, i.e. FG-F, then this FG-F node will become as a FG-B node which will update
this information to its upstream ZAN and responsible for forwarding packets to this
new group member.
[attachment=53054]
Abstract.
In this paper, we propose a Multicast Routing Protocol termed
ZBMRP (Zone Based Multicast Routing Protocol) for Mobile Ad Hoc Networks
(MANETs). ZBMRP applies on-demand procedures to dynamically establish
mesh-based multicast routing zones along the path from the multicast
source node to the multicast receivers. Control packet flooding is employed
inside multicast zones, thus multicast overhead is vastly reduced, and good
scalability can be achieved. It will also be easier to secure multicast routing.
ZBMRP fits well for MANETs where bandwidth is limited, topology changes
frequently, power is constrained and security problem is serious. Simulation
results are presented to support our claim.
Introduction
Mobile Ad hoc Networks (MANETs) is the cooperative engagement of a collection of
wireless mobile nodes that also performs as routers. Nodes in MANETs communicate
with each other through multi-hop transmission that does not need any existing infrastructure
or communication supporting center. Topologies of MANETs may change
quickly. Nodes in MANETs often perform a given task with other nodes together.
This often leads to sending the same information to a group of members. Instead of
sending data packets to each of the group members individually as unicast technique
does, multicast technique allows the source node to send packets to a group of nodes
as a single entity that will be sent only once on the shared path, greatly conserving
network bandwidth on the shared path of the group member.
Zone Based Multicast Routing Protocol Overview
Mesh Created in the Entire Network in the Establishment Phase
When a multicast source has packets to send but cannot find any route and group
membership information, it broadcasts a member advertising and route request
packet, termed RREQ, to the entire network. Only multicast receivers send back a
route reply message, called RREP, in order to allow the source node to get the current
routing information. Then ZBMRP uses the same strategy as ODMRP does [1] to establish
a mesh of nodes for forwarding packets between a multicast source and receivers.
The mesh is created using the forwarding group concept. The forwarding
group is a set of nodes that are in charge of forwarding multicast packets. It supports
shortest paths between any member pairs. A multicast receiver may serve as a forwarding
group node if it is on the path between a multicast source and another receiver.
In ZBMRP, we further classify forwarding group nodes into two categories:
FG-F and FG-B.
Source Zone Creation
After the forwarding mesh between a multicast source and receivers is established in
the entire network, mesh-based multicast routing zones are created according to the
distribution of source node, FG-Bs, and multicast receiving member nodes, i.e. ZANs.
Multicast source node will firstly establish mesh-based multicast zone, named
source zone. It collects the information of its nearest downstream ZANs from RREP
messages that it receives. Such information includes IP address and distance (in terms
of hop counts). If the source’s nearest downstream ZAN is far away from itself, e.g.,
more than 3 hops away, and relatively sparse, then the source node will not establish
source zone (or we can say the zone size is 0). It just tunnels multicast packets in the
unicast packets to its nearest downstream ZANs. If the source node finds many ZANs
within N hops, then it establishes source zone with a zone radius of N. Source node
becomes the leader of this source zone. A zone leader is in charge of constructing and
maintaining a zone. When N is no less than the size of the entire network, ZBMRP
becomes ODMRP.
Branch Zone Creation
If a FG-B gets data packets without zone information, which means it gets the packets
through tunneling, it is outside upper level zone, then it has to create and maintain its
mesh based routing zone according to the distribution of its nearest ZANs. We call
this kind of zone as branch zone. Other FG-Bs inside this zone just join it and will not
create the zone of itself as in FG-B IN source zone does. It is a kind of FDW (First
Declare Win) strategy. This kind of work will continue until the far end of the network.
There are no two or more FG-Bs to contend for building a same branch zone.
If a ZAN resides in multiple zones, it will receive multiple copies of the same multicast
packet from several zone leaders with different zone ID. It then just discards the
replicate packet. Note that, if this ZAN received a replicate packet tunneled from its
upstream ZAN, it needs to send an N-Tunnel message packet to its upstream ZAN to
save bandwidth. Upon receiving data packets without zone information, FG-B will
start establish its zone. Thus along with the data packets delivering, multiple mesh
based routing zones will be established along the path from the source node to multicast
receivers.
Zone and Route Maintenance.
Zone leader periodically broadcasts RREQ message inside zone with TTL equal to N
(zone radius). Every node inside zone that receives RREQ forwards RREQ until TTL
becomes zero. It also sends RREP back to zone leader. With these, zone leader updates
mesh routing inside zone.
For the sporadic ZANs that are not included in any zone, the upstream ZAN of it
tunnels packets to it unless the upstream ZAN receives explicit N-Tunnel messages
from these sporadic ZANs. A periodic positive update of tunneling membership is
also possible. In this technique, the downstream nodes periodically send the upstream
nodes a Tunnel message. Reception of such message indicates validity of the tunnel.
New Node Joining the Multicast Group
During the process of multicasting, if a new node wants to join the multicast group, it
explicitly generates a RREP-R packet that will be broadcasted to its neighbors. This
RREP-R message will be forwarded until it is received by a forwarding group node,
or source node. Then this node will be added to the multicast group, through a zone or
a forwarding route.
If the RREP-R is terminated at the normal forwarding group node with no
branch, i.e. FG-F, then this FG-F node will become as a FG-B node which will update
this information to its upstream ZAN and responsible for forwarding packets to this
new group member.