Wireless Multicast

Wireless Multicast

CS599 presentation April 27

What I’m gonna talk about

• Overview

• On-Demand Multicast Routing Protocol(ODMRP)

• Adhoc Multicast Routing Protocol(AMRoute)

• Core-Assisted Mesh Protocol(CAMP) • AMRIS

Characteristics of wireless Ad

Hoc network..

•Lossy

•dynamic (node mobility)

–frequently reconfiguring the tree => substantial control traffic

..Characteristics of wireless Ad

Hoc network

•limited battery power

Why we don’t just use existing

mcast protocol for adhoc network

• Frequent tree reorganization

– signaling overhead – loss of datagram

Application of multicast in Ad

Hoc wireless network

• 1-to-many : battlefield data dissemination • many-to-many : search/rescue team

On-Demand Multicast Routing

Protocol(ODMRP)

In a nutshell

• Create a mesh of nodes (called forwarding group ) which forward multicast packets via flooding

• soft state: member nodes are refreshed as needed & do not send explicit leave msg • a request phase and a reply phase

• group membership and routes are

Overview..

• Sender: if have data to send => periodically flood the network with JOIN_REQUEST

..Overview

• intermediate router:

– when receive a non-duplicate JOIN_REQUEST • store upstream node ID

• rebroadcast the packet

– when receive a JOIN_TABLE

• check if it is the specified next_hop in the received JOIN_TABLE

• if yes, set FG_Flag and broadcast its own

JOIN_TABLE (only broadcast once for different triggering if the source is the same)

..Overview

• For those routers with FG_Flag set are called forwarding group

• receiver: when receive JOIN_REQUEST

– create or update the source entry in its Member Table

– broadcast Join_Table periodically to the neighbors(source:next_hop) – the next hop will be the one which is on the minimum delay path to

the source

..Overview

• Flooding :

• + : create redundancy to overcome network dynamics

• - : not scalable large network

• periodic control packet are sent only when source is still sending packet, and

forwarding group nodes only forward packet when FG_flag has not expired

..Overview

• No explicit control packet to leave the group

– sender: stop sending JOIN_REQUEST – receiver:

• remove (src,grp) entry from its Member Table • stop broadcasting JOIN_TABLE

..Overview

• Flooding interval is critical : mobility prediction will help to determine how frequent route will change

s _r i j k n s | i

Data structure

• Member Table:(grp,src,timestamp for the last received JOIN_REQUEST)

• Routing Table:(source,next_hop)

– next_hop:the last node that propagate JOIN_REQUEST to me

• Forwarding Group Table(grp, the last timestamp FG_Flag is set)

..Data structure

• Message Cache

– when a node receive a JOIN_REQUEST or data

• store the source ID and sequence # for that packet • LRU/FIFO can be used to limit the size

Adhoc Multicast Routing

Protocol

Highlight of AMRoute..

• create a mesh to establish connectivity before tree creation

• only group sender and receiver are tree

nodes(replication/forwarding only performed by group members, and state only in tree

..Highlight of AMRoute

• Use virtual mesh links to establish the multicast tree

– as long as routes between tree member exist via mesh links , the tree need not be readjusted when network topology change

..Highlight of AMRoute

• Core nodes

– not a central point for data distribution like in CBT,PIM-SM(no single point of failure)

– can migrate dynamically among member

nodes(according to group membership/network connectivity, not preset))

..Highlight of AMRoute

• unicast tunnel are used as tree links

• independent of the underlying unicast protocol

• Emphasize on robustness (not try to minimize bandwidth/delay)

What’s required to become a

member node ?

• IP-in-IP encapsulation capability

• forwarding and replicating datagram • set TTL field of IP header

Mesh Creation..

• Establish connectivity

• might have loop at member discovery phase • but increase robustness

• use expanding ring search based on TTL-limited broadcast

..Mesh Creation

• A new node designate itself as a core of 1-node mesh

• all core nodes periodically broadcast JOIN-REQ (the period is proportional to TTL

associated with the last JOIN-REQ)

..Mesh Creation

• Upon receiving a JOIN-REQ

– if I’m a core

• if the message is from myself => drop it

• if the source of message is in my group and I don’t have a mesh/tree link to it => return a JOIN-ACK • otherwise, decrement the TTL and re-broadcast

– if I’m a non-core member

• if the message is from my core or for another group => decrement the TTL and re-broadcast

• if it’s from a different core => return JOIN-ACK and mark the source as a mesh neighbor

JOIN-NAK

• To leave a group => send JOIN-NAK to neighboring nodes

• when the number of links exceed LINK-THRESHOLD, a node must break some links by sending JOIN-NAK(might result temporary data loss & additional overhead)

Core Resolution..

• Why need it ? => one core per group

• node will receive multiple TREE-CREATE from different cores when multiple cores

existing

• Run a core resolution algorithm to pick the winner (pick the one with highest IP )

Why need a Core

• node designates itself as a core when first joining a group

• core node periodically sends out TREE-CREATE

• when core node dies (or leave group), one of the nodes will designate itself as core on not receiving any join/tree-create msg after some random time

Tree Creation..

• Periodically core send out TREE-CREATE to all its mesh neighbors

• periodicity of TREE-CREATE depends on size of mesh and mobility of nodes (still

under research)

..Tree Creation

• Upon receiving TREE-CREATE

– if I’m a core

• run core resolution algorithm • if I win, drop the message

• if the source of message wins

– transit myself into non-core state

– mark the wining core a mesh neighbor

– forward TREE-CREATE onto downstream mesh links, which are then marked as tree links

..Tree Creation

• Upon receiving TREE-CREATE

– if I’m a non-core member

• if the source of this message is from my logical core

– the message has a new sequence # => mark the incoming links as a tree link , forward it to downstream mesh

neighbors and mark them as tree links

– if it’s a duplicate, mark the incoming link as a mesh link and send TREE-CREATE-NAK back to the source

..Tree Creation

• If the message is from different core • Upon receiving

– run core resolution algorithm – if new core wins

» set CORE ID to new code

» forward the TREE-CREATE onto all downstream mesh links & mark the incoming and outgoing links as tree links

..Tree Creation

• transient loop and data loss are expected

• basically a core consider its mesh neighbor as its tree neighbor until receiving a TREE-CREATE-NAK

Leaving the group(node failure)

case (1)

Leaving the group(node failure)

case (1)

Leaving the group(node failure)

case (2)

Leaving the group(node failure)

case (2)

Message type

• Control message

• Join-REQ:detect group member (the only one being broadcast using expanding ring search)

• JOIN-ACK:response for receiving JOIN-REQ from a different core

• JOIN-NAK:leave the group

• TREE-CREATE:refresh the tree

Timer

• JOIN-REQ-SEND timer

– compute new TTL value to use for the expanding ring search

– the TTL value has a specific upper bound

• TREE-CREATE-RCV timer

– wait for some random amount of time before it reset itself to be a core

Data structure

• One table for the mesh neighbors

• one table for the hop-count associated with each mesh link

• ID of logical core

Core-Assisted Mesh Protocol

(CAMP)

Overview..

• Use mesh instead of tree

• assume the underlying unicast routing protocol can provide correct distance to known

destination within a finite time

• ensure reverse shortest paths from receivers to sources are part of a group’s mesh

Core in CAMP..

• Extends the basic receiver-initiated approach introduced in CBT to create multicast mesh • core is used to limit the control traffic needed

for receivers to join the group

• can have multiple cores for each mesh

• cores need not to be part of mesh of their group

..Core in CAMP

• Mapping of multicast address to (one or

more) core addresses are disseminated from each core out to the network as part of

Date structure needed for a router

• For router i

– unicast routing table: destination j:successor s(i,j):distance (i,j)

Date structure needed for a router

(cont)

– Packet-forwarding cache :CACHE(i)

• maintain the ID of packets recently processed by the router

• to avoid unnecessary packet replication by keeping track of packets already received by the router

• src:pktID:Offset:grp:xmtAdr:timstamp(where xmtAdr is the last relay node of the data packet)

Date structure needed for a router

(cont)

– N(i,g,) : contains all neighbors that through

update are known to be mesh member of group g

• even non-member router needs to keep this list

updated (so it can become a member when receiving a join request , without the need to send the request any further)

Date structure needed for a router

(cont)

– Multicast routing table:MRT(g,i)

• status:group:modified_flag

• status: CORE|NON_CORE|DUPLEX|SIMPLEX| NON MEMBER

• modified_flag: whether an update has to be sent with information about group g

Date structure needed for a router

(cont)

– Anchor table AT(i)

• anchor : an anchor is a neighbor router who is the next hop in the reverse shortest path to at least one source in the group

• prevent routers that are required by their neighbors to forward packets from leaving groups prematurely

• obtained from unicast RT

• router doesn’t maintain anchor for each source

• a single anchor only being stored once if it acts as a next hop to multiple source

Date structure needed for a router

(cont)

– Anchor table AT(i)

• two lists for AT : a list of neighbors that have router i as their anchor ; a list of neighbors who are anchors to router i • when MRT or AT is updated, send a multicast routing

update (MRU) to all neighbors

• MRU:grp:op_code:membership_notification • op_code: quit , simplex , duplex

Date structure needed for a router

(cont)

– Anchor table AT(i)

• when MRU will be triggered

– MRU from neighbor that change group membership – membership/anchor information change

Date structure needed for a router

(cont)

– LS(g,i) : a list of sender that directly attached to router i

– LR(g,i): a list of receiver that directly attached to router i

– help router i to know when it’s appropriate to terminate membership to the group

Join the group

• If any of my neighbor is member of group ? • send a join request toward core

• cores are not reachable => expanding ring search (flooding)

• when response are sent back => choose any of these response to use as a path to the

Join (in details)

– Host determine the address of group

– host ask the attached router to join the group – when router receive a join request from host

• announce its membership ,if it has neighbors that are duplex members of the multicast group, or

• use CAM to select a core and send join toward it (like CBT)

Join (in details)

– Group member who receives a join request can send back a ACK

– when the origin (or its relay) of a join request receive the first ACK => it becomes the

member

Leave the group

• When:

– it has no hosts that are members

– it has no neighbors for whom it is an anchor

• How:

– issue a quit notification (as part of MRU) to its neighbors, who in turn update their MRT

core

c

g h

Simplex Join..

• Motivation : to contain data traffic closer to

regions of the mesh where receivers are present • only for routers connected to sender-only hosts

to join the mesh(router only intends to send

traffic to group , don’t want to forward packets from the group)

..Simplex Join

• Traffic only travel in one direction : from

the sender-only host to the mesh and not the opposite

Simplex Join

• for any data source who needs to join the mesh to send packet

• avoid the dissemination of data to sender-only data

• data being sent before getting ACK for join request

Simplex Join(cont)

– To avoid core becomes a hot spot , the first router who is a member in the path from the source of data traffic to the core starts to

core c g h b d i j

core

c

g h

How to ensure the mesh contains

all the reverse shortest paths

Heartbeat & Push Join..

• To ensure all the reverse shortest paths

between sources and receivers are part of a group’s mesh

• periodically, router look up every single

entry in the packet forwarding cache to see the neighbor that relayed the packet is on the shortest reverse path to source

..Heartbeat & Push Join

• If the number of packets coming from the reverse shortest path of some source is

under a threshold => send heartbeat toward that source

• when a router receive a heartbeat

.. Push Join

• PJ will be propagate further ahead until it hit the router which directly connect to the source

.. Push Join

• When router receive a PJ:

– send a ACK if

• it’s the intended next hop • it’s a member

• it has a path to the end point of PJ

.. Push Join

• PJ will force the successor and all the

routers along the reverse shortest path to join the mesh

core c g h b d i j

Anchor

• Will age out after topology change

• mainly used for preventing routers from

leaving a mesh when they are in the reverse shortest path for some other routers

• i can add a neighbor p as an anchor if :

– p is in the reverse path to some source, and – i gets data packet or ACK (to PJ) from p

Topology change

• Link/node failure : less severe in CAMP due to

– mesh structure

Keep Mesh connected..

• Mesh might be partitioned due to router mobility or network itself

• when a router loses connectivity with all cores

– set a flag to remind itself to try to connect the cores again later

– when unicast RT indicates some core is reachable again => send join request via reverse shortest

..Keep Mesh connected

• Core explicit join:

– to ensure 2 or more mesh components with cores will eventually merge

– all cores periodically send CEJ to each other – group:next_hope:intended_core:gap_flag

..Keep Mesh connected

– when a router receive a CEJ:

• gap_flag = 0

– forward it to next relay ,if » it’s the specified relay

» it has a path to the specified core – set gap_flag =1 if it’s not a member

• when a core receive a CEJ with gap_flag = 1

– send an ACK , and this ACK is forwarded all the way back to the originator of CEJ

..Keep Mesh connected

– When a router that has a group member or it is an anchor for other routers detect that none of its successors in its shortest path to any core of the group => send a join request toward its

selected core

– flooding (ERS) only be used connect the mesh when all cores are unreachable

Data packet forwarding..

• Packet forwarding cache

– group:source:seq_no:TTL

• Router only accepts packet if

– it’s a group member

– the seq_no is not in its packet forwarding cache if it’s a duplex(avoid redundant packet)

– seq_no is not in its cache and the sender is also a simplex if it’s a simplex

..Data packet forwarding

• Router only forward accepted packet if it’s the anchor for at least one neighbor

Ad Hoc Multicast routing

Protocol utilizing Increasing

id-number(AMRIS)

overview..

• assign each node in a multicast session an id-number

• first build a DAG (directed acyclic graph) rooted at a special node called Sid, which is generally the

source node (and session initiator) and has the smallest id-number (for multiple sender, then an election might be needed )

• a shared delivery tree is thus formed by using a subset of the DAG

..overview

• node’s id-number increases as they radiate from the root

• repairs to broken link are performed locally • emphasize on rapid route reconstruction

..overview

• Sid initiates a multicast session by broadcasting a NEW-SESSION

• all nodes that receive NEW-SESSION generate their own “mutlicast session

member id” (msm-id) based on the value found in NEW-SESSION message , then

..overview

• NEW-SESSION travels in an expanding ring fashion outwards from Sid, so nodes closer to Sid will generally have smaller msm-ids than those further away

Join the Tree

• if the requesting node X has a neighbor who is already on the tree

– send JOIN-REQ to that neighbor Y

– neighbor Y will send back JOIN-ACK to confirm now X is its child

..Join the Tree

– after receiving JOIN-REQ, neighbor Y sends out its own JOIN-REQ

– if the parent node Y can successfully join the tree, then it sends a JOIN-ACK to X ,

otherwise, it will sends a JOIN-NACK to X – after some time, if Y found out it has no child

..Join the Tree

• otherwise,

– X will send a broadcast JOIN-REQ with limited ttl range, in turn will trigger all the nodes within that range will send out their JOIN-REQ

– X might possibly receive several JOIN_ACK from its potential parent . It will choose one of

..Join the Tree

• if links broken after X sends out JOIN-REQ => eventually X will time out and enter into broadcast mode

Msm-id

• a increasing function of hop count : for a node, the larger the hop-count value in

NEW-SESSION message it received , the larger will be its msm-id

When link is broken

• if a link breaks between two nodes, the child X (the one with larger msm-id) should

initiate the recovery by entering broadcasting mode

– if still no-reply after a certain time

• if x has child nodes : send New-Partition-ID to all its child node (intra-partition traffic can continue

normally)

..When link is broken

– if receive JOIN-ACK after some time

• send a JOIN-CONF to reestablish parent-child relationship with one of its neighbor

• node only start to forward traffic to its child nodes after it receives JOIN-CONF from them

Mutlicast Beacon

• a one-hop broadcast message sent by every node to detect link breakage within a fixed time

• node id

• msm-id & status (member/non-member, lifetime) • parent id

• child id

protocol _{AMRoute ODMRP CAMP AMRIS}

topology _{TREE MESH MESH TREE}

Loop-free _{NO YES YES YES}

Depend on unicast protocol YES NO YES NO Periodic message

YES YES YES YES

Control packet

Performance metrics

(in terms of mobility)

• packet delivery ratio : mesh is better than tree because path reducancy

• # of data transmission per data delivery : tree is better

metrics(in terms of # of sender)

• ODMRP is the best

– more forwarding nodes => path redudancy +

– collision is limited due to suppression for JOIN-REQ

• CAMP also show improved performance

– increase the number of anchors required . => more nodes are forced to join the mesh => better path redundancy

• tree-based protocol like AMRIS & AMRoute are not affected

metrics(in terms of # of sender)

• ODMRP is the best

– more forwarding nodes => path redudancy +

– collision is limited due to suppression for JOIN-REQ

• CAMP also show improved performance

– increase the number of anchors required . => more nodes are forced to join the mesh => better path redundancy

metrics(in terms of group size)

• ODMRP/flooding are not affected

• CAMP improve its performance as the number of receivers increases

– the mesh become massive with the growth of the member => More redundant paths

metrics(in terms of group size)

• AMroute : “critical links” increase as tree links increase

• critical link: the wireless link which might become temporarily unidirectional because node movement (affected by node speed and mobility pattern ) => packet might lose at these critical links

• no alternate route in AMRoute since it uses a shared tree to forward data

metrics(in terms of traffic load)

when the transmission and size of beacon increases

• AMroute : buffer overflow

• CAMP: when # of collision increases, which in turn cause control packets dropped, delay anchor construction