Difference between revisions of "GSOC2010Click/MidTermReport"

From Nsnam
Jump to: navigation, search
(Achieved Goals)
(Remaining Work)
 
Line 34: Line 34:
 
=Remaining Work=
 
=Remaining Work=
  
I'll proceed to implement the helpers as of now and prepare some good documentation. Once that is done, we plan to explore some use cases that Ruben had in mind which involves having Click co-exist with some ns-3 routing protocols. We also intend on exploring a model wherein Click handles MAC layer functionality (with an eye on 802.11) as well.
+
I'll proceed to prepare some good documentation now. Once that is done, we plan to explore some use cases that Ruben had in mind which involves having Click co-exist with some ns-3 routing protocols. We also intend on exploring a model wherein Click handles MAC layer functionality (with an eye on 802.11) as well.

Latest revision as of 14:20, 6 July 2010

Work Approach

The exact methodology of the work has been described in the wiki page [0] for the project. I'll be summarising the steps Ruben and I have followed in the section below.

Achieved Goals

To enable the use of the Click Modular router in NS-3, we first implemented a class Ipv4ClickRouting, which derives from an abstract class Ipv4ExternalRouting. Ipv4ExternalRouting is used to enforce the use of Send() and Receive() methods for external routing. This can be used in future if we're integrating any other external router like Click. Ipv4ClickRouting does the actual interfacing with Click. This includes instantiating a Click router for a node, handing packets to and from Click, and providing services to Click like resolving a node's IP/MAC addresses from an interface name. Test cases were also implemented to ensure that Ipv4ClickRouting's internals work as expected.

Next, as per Tom's suggestion, we implemented the Ipv4L3ClickProtocol class (derived from Ipv4), which handles the L3 functionality for Click. It is similiar to much of Ipv4L3Protocol, except where packets are sent up and down the stack, and where the protocol handlers are registered. The TCP and UPD L4 protocols were slightly modified to work with both kinds of L3 protocols.

We then went on to deal with L2, which was slightly confusing at first because we needed to ensure that we have a common way of handling both CSMA and Wifi devices with Click running on top of them. This was handled as follows:

  • Sending of a packet by a Click node:

Every packet received from Click has its ethernet header stripped off, sent down the stack directly using NetDevice::Send() with the destination header and protocol fields being extracted from the received header. The NetDevice then adds the headers again as required. In case of Wifi, Wifi specific elements are not required in this portion of the Click graph. (keeping the sending side for Csma and Wifi the same in the Click graph)

  • Receiving of a packet by a Click node:

CsmaNetDevice::Receive() and MacLow::ReceiveOk() were slightly modified so that incoming packets are sent directly upto L3, to be handled by Click. In the case of Wifi, only data packets are sent to Click. RTS/CTS/ACK and 802.11 Management packets are handled by the Mac Low/High models in ns-3. The Click graph has to have the necessary decapsulation elements to remove the MAC headers (for Wifi and Csma). We tested this for Adhoc and Nqap/Nqsta configurations and it works as expected.

Furthermore, we expect the Click graph to handle ARP and ICMP which leaves more flexibility within Click.

We also have examples scripts inside examples/click to demonstrate the following:

  • nsclick-simple-lan.cc and nsclick-raw-wlan.cc:

A Click based node communicating with a normal ns-3 node without Click, using Csma and Wifi respectively. It also demonstrates the use of TCP on top of Click, something which the original nsclick implementation for NS-2 couldn't achieve.

  • nsclick-udp-client-server-csma.cc and nsclick-udp-client-server-wifi.cc

A 3 node LAN (Csma and Wifi respectively) wherein 2 Click based nodes run a UDP client, that sends packets to a third Click based node running a UDP server.

  • nsclick-routing.cc

One Click based node communicates to another via a third node that acts as an IP router (using the IP router Click configuration). This demonstrates routing using Click.

We have also implemented a helper class ClickInternetStackHelper to set up and configure Click based nodes.

Remaining Work

I'll proceed to prepare some good documentation now. Once that is done, we plan to explore some use cases that Ruben had in mind which involves having Click co-exist with some ns-3 routing protocols. We also intend on exploring a model wherein Click handles MAC layer functionality (with an eye on 802.11) as well.