Multicast-Enabled Landmark Multicast-Enabled Landmark (M-LANMAR) : (M-LANMAR) :

Implementation and scalabilityImplementation and scalability

YunJung Yi, Mario Gerla, JS Park, Yeng Lee, SW LeeYunJung Yi, Mario Gerla, JS Park, Yeng Lee, SW Lee

Computer Science DeptComputer Science DeptUniversity of California, Los AngelesUniversity of California, Los Angeles

The AINS ScenarioThe AINS Scenario

FLIRFLIR

LANMARLANMAR Key insight: Key insight: nodes move in teams/swarmsnodes move in teams/swarms Each team is mapped into aEach team is mapped into a logical subnet logical subnet IP-like Node addressIP-like Node address = <subnet, host> = <subnet, host> Address compatible with IPv6Address compatible with IPv6 Team leaderTeam leader (Landmark) (Landmark) elected in each group elected in each group

Logical SubnetLogical Subnet

LandmarkLandmark

Scalable Ad hoc Scalable Ad hoc multicastingmulticasting

Multicast (ie, transmit same message to all Multicast (ie, transmit same message to all member of a group) critical in battlefieldmember of a group) critical in battlefield

““Multiple unicast” does not scaleMultiple unicast” does not scale Current ad hoc Current ad hoc multicast solutions: multicast solutions: inappropriateinappropriate

They do not exploit affinity team modelThey do not exploit affinity team model multicast tree approach is “fragile” to mobility;multicast tree approach is “fragile” to mobility; no congestion control; no reliable end to end deliveryno congestion control; no reliable end to end delivery

Proposed approach:Proposed approach: TEAM MulticastTEAM Multicast

swarmswarm

Command postCommand post

Swarm Swarm LeaderLeader

UAVs: - equipped with video, chemical sensors - read data from ground sensors - “fuse” sensor data inputs - multicast fused data to other teams

Team Multicasting

Two-tier team multicast: M-Two-tier team multicast: M-LANMARLANMAR

Extension of LANMAR enabling Extension of LANMAR enabling multicastmulticast Inter-teamInter-team communication: communication: unicastunicast

tunneling from the source to the tunneling from the source to the representative of each subscribed team representative of each subscribed team

Intra-teamIntra-team communication: scoped communication: scoped floodingflooding within a team within a team

Source node

LM2

LM3

Subscribed Teams

LM4

Tunneling to landmarks

Flooding

Flooding

Scope = 2

Scope = 2

M-LANMAR

Testbed configurationTestbed configuration 3 teams (= 3 IPv4 subnets), 1 sender, 3 receivers3 teams (= 3 IPv4 subnets), 1 sender, 3 receivers

Dell P4 laptop with Lucent Orinoco 802.11b pcmcia cardDell P4 laptop with Lucent Orinoco 802.11b pcmcia card CBR traffic (512B/packet, 5~15 packets/sec)CBR traffic (512B/packet, 5~15 packets/sec) Protocols:Protocols: ODMRP; M-LANMARODMRP; M-LANMAR

Sender

Experimental Results: Experimental Results: Delivery Ratio and Control Delivery Ratio and Control

OverheadOverhead

0.0

0.2

0.4

0.6

0.8

1.0

1.2

5 10 15Sending rate (packet/sec)

Del

iver

y ra

tio

M-LANMAR delivery ratio ODMRP delivery ratio

M-LANMAR has higher Delivery Ratio than ODMRP: unicast tunneling helps reliable data delivery as it incorporates RTS/CTS/ACK)

M-LANMAR has higher control overhead

0.0

0.5

1.0

1.5

2.0

2.5

5 10 15Sending rate (packet/sec)

Con

trol

Ove

rhea

d

M-LANMAR control overhead

ODMRP control overhead

ScalabilityScalability Objective: test M-LANMAR scalabilityObjective: test M-LANMAR scalability Compared withCompared with

ODMRPODMRP Flooding Flooding

Simulation EnvironmentSimulation Environment QualNetQualNet 1000 nodes 1000 nodes forming forming 36 teams36 teams on on 6000 x 6000 m6000 x 6000 m22 field field CBR traffic (CBR traffic (512 bytes512 bytes/packet, 1packet/sec)/packet, 1packet/sec)

Simulation ResultsSimulation Results

As the number of multicast groups increasesAs the number of multicast groups increases ODMRP suffers from large control overhead and collisionsODMRP suffers from large control overhead and collisions M-LANMAR achieves high delivery ratio (by unicast tunneling M-LANMAR achieves high delivery ratio (by unicast tunneling

and flooding)and flooding)

Reliable Multicast Reliable Multicast SupportSupport

Reliable Adaptive Lightweight Multicast (RALM)Reliable Adaptive Lightweight Multicast (RALM) Source continually monitors the channel Source continually monitors the channel

conditioncondition No congestionNo congestion: the source transmits at “native” rate: the source transmits at “native” rate CongestionCongestion detecteddetected (i.e., packet loss feedback via (i.e., packet loss feedback via

NACK): the source falls back to “send-and-wait” NACK): the source falls back to “send-and-wait” mechanism (source stops upon receiving a NACK; it mechanism (source stops upon receiving a NACK; it resumes when it receives an ACK )resumes when it receives an ACK )

Combining with M-LANMARCombining with M-LANMAR Only landmarks return feedback (e.g. NACK/ACK) to Only landmarks return feedback (e.g. NACK/ACK) to

the sourcethe source Prevents unnecessary feedback implosionPrevents unnecessary feedback implosion

Simulation Results with RALMSimulation Results with RALM“Reliable Multicast”“Reliable Multicast”

(1000 nodes, 3 teams for each group, 5 (1000 nodes, 3 teams for each group, 5 multicast groups)multicast groups)

Delivery Ratio

0

0.2

0.4

0.6

0.8

1

1.2

512 1024 1280 1689.6 2560 5120

Offered Load (Bytes/sec)

Deliv

ery

Ratio

M- LANMAR w/ UDP ODMRP w/ UDPM- LANMAR w/ RALM ODMRP w/ RALM

ODMRP suffers from feedback implosion; congestion is unacceptable