Supporting the routing protocol wireless network for tap-wifi-virtual-machine.cc

[Jinxue Zhang]

Hi all,

Thanks for the update for the TapBridge on container in ns-3.8. I built an emulation environment on OpenVZ, and tap-wifi-virtual-machine.cc can run perfectly.

However, I can not use this model to run a ns-3 with MANET routing protocol, such as AODV, OLSR. The testing configuration file is attached "tap-aodv-not-work-on-original-tapbridge.cc".
The possible reason is that UseLocal model of TapBridge substitutes the MAC address of bridged device to the MAC of tap device, which is only OK in the local single-hop wireless network.
If the source A and destination B are apart with multi hops, the communication will fail, as follows:

1. Ethernet device in container A will send a ping packet to Ethernet device in Container B
2. Ethernet device in A finds that there is no route to the destination in its cache and kernel FIB. Since the default gateway is "*", it will conclude that the destination is in local network,
and send an "ARP" request to the bridge.
3. TapBridge device then will capture the ARP request and forward it to the ns-3 network. But at multihop situation, it can't get the response, resulting the sending failure in tap device
in container A. Note that, in single hop local wireless network, this ARP request can be captured by tap device in container B, resulting in successful response and then transmission.

To support the routing protocol, I propose a tentitive plan, as follows:
1. TapBridge in source replies the initial ARP request with its own (bridged device) MAC address. This can give the tap device an illusion that TapBridge/Bridged device is the default L2
gateway for it. Thus all the packets can be received by TapBridge.
2. TapBridge then sends this packet to ns-3 network. However, the packet need to be modified. The source IP will change to bridged device, and the destination IP also needs to be
changed to the bridged device of the corresponding container. Thus, ns-3 will route the "modified" packet to the bridged device of the destination container by AODV/OLSR in ns-3.
3. When receiving the packet, the TapBridge device in destination node needs to revert the packet to the original one by IP substitution. In addition, the destination TapBridge needs
to decide whether to forward the packet to the tap device since the packet may be used for routing updating in AODV/OLSR. We will extract the packet and find the feature to classify it.

Based on this thinking, I implemented the initial proposal. The MAC and IP address of the Ethernet card in container will be collected in configuration, and the addresses from all
containers will form a global static map between container and bridged device. Then at sender side, the MAC and IP addresses will be replaced to the remote corresponding bridged
by looking this global static map. At the receiver side, the packet will first classified. The packets for routing updating in ns-3 will forward back to ns-3, while the ones for application
container will revert first according to the global map and then send to the tap device by IPC.

I have tested it on AODV. It works well.

The patch and corresponding configuration are attached. If you are interested with it, please have a try:-).

I will appreciate your comments on this proposal.


Best wishes
Jinxue Zhang

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.