[Ns-developers] GSoC '10: Click Modular Router Integration

[Lalith Suresh]

Hello Ruben,

I've been through most of the patch, and I've gotten a better idea of how
things are currently working. My comments below.

On Mon, Mar 22, 2010 at 1:39 AM, Ruben Merz
<ruben at net.t-labs.tu-berlin.de>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Lalith,
>
> Comments below.
>
> On 3/19/10 1:25 PM, Lalith Suresh wrote:
> > Hello Ruben,
> >
> > On Tue, Mar 9, 2010 at 2:43 AM, Ruben Merz <
> ruben at net.t-labs.tu-berlin.de>wrote:
> >
> >>
> >>> 1) As is used in the current implementation, we'll need to implement
> new
> >>> Click elements to get packets from the Simulator Devices
> (FromSimDevice,
> >>> ToSimDevice, which should replace FromDevice and SimDevice elements
> >>> respectively). A Kernel tap device is used to send packets from Click
> to
> >> the
> >>
> >> If you look at the Click elements, there are already ToSimDevice and
> >> FromSimDevice elements
> >> (http://read.cs.ucla.edu/click/elements/tosimdevice.u and
> >> http://read.cs.ucla.edu/click/elements/fromsimdevice.u).
> >>
> >> I'm not sure what you mean with the kernel tap device.
> >>
> >
> > As per the nsclick manual, Kernel tap device (tap0) is used to get
> packets
> > to and from the operating system (ToSimDevice (tap0) and FromSimDevice
> > (tap0) respectively). In the case of ns-3, these would be packets to and
> > from the traffic generator sink/source.
>
> Sure. Pay attention that this tap device is actually not a real device.
> If you haven't done it yet, clone the click git repository and have a
> look at the following files:
>
> etc/ns-2.30-patch
> ns/nsclick.cc
> ns/nsclick-test.cc
>
> and the code in elements/ns, in particular tosimdevice.{cc,hh} and
> fromsimdevice.{cc,hh}.
>
> and also include/click/simdevice.h which provides the API on click's side.
>
> A few things in the above will, likely, need to be changed.
>

Seems like FromSimDevice and ToSimDevice can be mostly used as it is because
it depends only the Simulator API (the interface provided through
include/click/simclick.h). Currently, simclick_click_send() is used to send
a packet to Click, which is called from the Click Classifier when the
function route() and LinkLayerFailed() is called.

Now in ns-3, the closest analogy to ns-2's classifiers would be in
Ipv4L3Protocol::AddInterface(). The callbacks used by the node for handling
a packet at Ipv4L3Protocol and ArpL3Protocol are registered here. We could
simply do something like:

if (node->IsClickNode())
{
   node->RegisterProtocolHandler (MakeCallback (pass_packet_to_click),
                                 Ipv4L3Protocol::PROT_NUMBER, device);
}
else
{
  node->RegisterProtocolHandler (MakeCallback (&Ipv4L3Protocol::Receive,
this),
                                 Ipv4L3Protocol::PROT_NUMBER, device);
}

node->RegisterProtocolHandler (MakeCallback (&ArpL3Protocol::Receive,
PeekPointer (GetObject<ArpL3Protocol> ())),
                                 ArpL3Protocol::PROT_NUMBER, device);

This seems ok since Click won't need the ns-3 Ipv4/Ipv6 stacks since Click
should be handling all the layer 3 activity.



> >
> >>
> >>> layer above it on the stack (towards the application).
> >>> 2) The reason why TCP isn't supported in nsclick is because with ns-2,
> >> Raw
> >>> Packets had to be enforced since Click understands only wire frame
> format
> >>> packets. In ns-3, this shouldn't be much of a problem since packet
> >> headers
> >>> are Serialized/Deserialized.
> >>
> >> Not sure. Because you would typically have a traffic generator in ns-3
> >> feeding a Click configuration, with its outputs to ns-3.
> >>
> >>> 3) A new API should be implemented to allow Click to talk with the ns-3
> >>> Simulation environment. This includes tracking events, and using the
> >>> Simulator Time (that is, the value given by Simulator::Now() instead of
> >>> gettimeofday() to refer to the current time).
> >>
> >> See the --simtime option from Click:
> >> https://pdos.csail.mit.edu/pipermail/click/2010-February/008803.html
> >>
> >> Ruben
> >>
> >
> > Thanks for that link! Looks very convenient for the integration. I'll get
> to
> > reading on it.
> >
> >
> >>
> >>> 4) In an nsclick network interface, a ClickQueue is used between the LL
> >> and
> >>> MAC layers. I'm a little confused about this and I am trying to figure
> it
> >>> out.
> >>
> >>
> >
> > From what I've understood so far, I believe we need to do something like
> > this:
> >
> > 1) Use a special RecvCallback at the NetDevice level which will pass on
> the
> > packet (to be sent up the stack) to the Click device. FromSimDevice(eth0)
> > (say) will be used from Click's side to receive the packet.
>
> That sounds reasonable. If you remember an earlier mail I wrote you, I
> hinted that it would be great to also be able to send packets directly
> to the physical layer. In this case, the click code would also contain
> elements that implement the MAC layer and you would have something like
> ToSimDevice(ath0).
>
> See https://euterpe.cmi.ua.ac.be/~nletor/nsmadwifi/nsmadwifi-intro.pdf<https://euterpe.cmi.ua.ac.be/%7Enletor/nsmadwifi/nsmadwifi-intro.pdf>
> and http://systems.cs.colorado.edu/Papers/Generated/nsclick_mswim2002.pdf
>

Yes, I noticed the ToSimDevice() calls sim_if_ready() which calls the
SIMCLICK_IF_READY command through the classifier, which uses LLExt to probe
the Click Queue, which checks whether it is ready to accept a packet, and
then calls simclick_click_run() to give the external router the green signal
to pass down a packet. * whew *

Now I'm trying to see if we can do without the Click Queue, because it's
purpose is still a little unclear to me. Why can't Click directly pass down
a packet to NetDevice? That way, we needn't end up writing a different MAC
layer, and we could probably wrap the click router as something like
Ipv4ClickRouting. (As Fig 28.2 in
http://www.nsnam.org/docs/manual.html#Routing-overview envisions)

I'm guessing the Click Queue's purpose is to match the speeds of ns-2 and
the Click router itself. To prevent the Click instance from pumping in
packets at a speed that doesn't match the speed at which ns-2 is probably
working. If my guess is right, then it is possible do away with the Click
Queue thanks to the new --simtime option provided with Click. If we can sync
both the Click and ns-3 timers, then the above shouldn't be a problem. I
haven't explored the --simtime option fully, will work on it now.


>
> > 2) UdpL4Protocol and TcpL4Protocol implementations act as interfaces
> between
> > the socket implementation and the IP layer. This implementation can be
> > modified to pass on and receive packets from an external router like
> Click.
> > The Send() and Receive() methods in UdpL4Protocol and TcpL4Protocol are
> used
> > by the respective sockets. Click can then receive a packet from above the
> > stack using FromSimDevice(tap0) and send a packet up the stack using
> > ToSimDevice (tap0).
>
> Ok. I, personally, do not like at all this naming with tap0. Why not
> something like FromSim(tcp|udp) and ToSim(tcp|udp).
>

I went through
http://www.nsnam.org/docs/manual.html#Example-path-of-a-packet. From there
it seems like sending a packet down the stack from Layer 4 is slightly
different in the sense that there is a query made to Ipv4RoutingProtocol
instance _before_ the packet is pushed down to layer 3. So looks like we'll
need to make RouteOutput() and RouteInput() wrappers for the Click router.
Again, all of this seems to be screaming out for a separate Ipv4ClickRouting
type! :)


>
> > 3) A packet coming down the stack, after being processed by Click, can be
> > sent out from Click using ToSimDevice(eth0) (say) and then have the
> > NetDevice send it further down the stack. For this, I believe we'll need
> to
> > pass on the packet to the NetDevice' Send() method.
>
> Ok.
>
> > I hope these are the points at which the packet handoffs should be made
> to
> > and from Click. The fact that the packets are serialised and deserialised
> as
> > required at each layer in ns-3 makes it more convenient to talk with
> Click.
> > Furthermore, I'm exploring whether we'd actually need to modify all the
> > individual devices in devices/ to account for this integration (I know,
> that
> > sounds ugly), or if there's a more graceful way of doing it only through
> > NetDevice itself (Add something like ToClick and FromClick in the base
> > class, which would be called by only Click nodes instead of the usual
> Send()
> > routine and the RecvCallback. This wouldn't require too much changes to
> the
> > subclasses).
>
> I believe this is solved in the nsclick patch with the addition of a
> specific "node type" to interface between click and ns. I'm right now
> not so sure how can this be transposed in ns-3.
>

The above comments should answer your doubt? I think it's possible to work
around the special node type if we strive to wrap Click entirely around
layer 3.


>
> > Now that I'm done with exams, I can focus on this full time! :)
>
> Good luck then!
>
> Ruben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJLpnz8AAoJEF+2tk4uvSJP7d8H/0AZaaizsycXd46yuDnmzRqb
> FWw6HpTJko/93nX/xe3Jx+5gBiOQ5RNO9NUCwmi9aKJQEgmL9dTGvE+VZzljc6RP
> qk9PEsV0FfCnA3/xB/W29+XitFMICwG/EdixA1Gl5SKvxpaMKi+9DErXyX+O4miW
> 8S0oY3tI/2j66MAUW9OJWQHVJ0BSLxLNAb6ATU8z4VsZSbn2RD1YS1cCyb9Sh3OX
> 0OHwdGo3nZDTN4dSNMelfzYSSpBLLi9MnJVhvgYiAXbzUKftGm0qNIZQvLHCoWdA
> O12uyv5mLKJBz+AYk4x9of+6m4+VjUfaX7gBNpucTJf5DsPKM+63I0kA0som9tM=
> =oHBI
> -----END PGP SIGNATURE-----
>


All in all, we need to figure out how to do the packet handoff, the timer
handling, and the event handling. I think the packet handing off part has
become a lot clearer now. I'll work on the timer handling part (using
--simtime) now before moving on to event handling.

-- 
Thanks and regards,
Lalith Suresh
Department of Computer Engineering
Malaviya National Institute of Technology, Jaipur
+91-9982190365 , www.lalith.in