[Ns-developers] GSOC & Optical Burst Switching Network patch port.

[Anush Elangovan]

Have we taken a look at Daytona.

http://nms.csail.mit.edu/~kandula/data/daytona.pdf .

Maybe that is something that could be re-used/updated to the latest
kernel. I had previously got this pointer to the source from the
author

http://www.cs.cornell.edu/~manpreet/non-threaded-daytona.tar.gz

Anush

On Tue, Apr 8, 2008 at 6:37 AM, Tom Henderson <tomh at tomh.org> wrote:
> rAjEs wrote:
>
> > Hi
> > Some confusions about Linux kernel network stack integration project idea.
> I have copy the project idea in one paragraph and my thoughts in the other
> paragraph with dash lines. I need to rectify my understanding so that i can
> modify my applications.
> >
> > The goal here is to be able to run a minimally modified (ideally,
> unmodified) linux kernel network stack (initially, ipv4/tcp) within our
> network simulator. There are two distinct components to this project:
> >  ---It means that are we modifying the code of kernel (like
> para-virtualization concept). Since the NetDevice Class is the class which
> defines the IP and ARP layer and it also manages  the instances of a network
> driver(Here network driver means the user-space network driver!!).
> >
>
>  rajes,
>  the NetDevice class does not define the IP and ARP layers; they sit above
> this class.
>
>
>
> >
> > Implement a set of glue layers to provide a 'kernel' environment for
> kernel code. This will require: a re-implementation of the basic kernel
> library functions (memory allocation, timers, etc.), the implementation of a
> fake linux network driver to act as a bridge between the ns-3 NetDevice
> class and the linux struct net_device, and, the implementation of an ns-3
> fake socket to act as a bridge between ns-3 applications and linux kernel
> sockets.
> >
> > --- what do you mean "kernel environment for kernel code".
> >
>
>  This means that we want to provide an environment that matches the kernel
> environment as much as possible, to avoid making unnecessary changes to the
> kernel code to get it to run within ns-3.
>
>
>  As far as i
>
> > understand we are modifying the kernel library. So then our kernel will be
> custom kernel(confused). This fake driver you mean reside on user space or
> kernel space . Since as i know Class NetDevice is analogous to the interface
> above the dev_queue_xmit() of linux kernel network code. This function uses
> the sk_buff (Data movement for sockets takes place using a core structure
> called the socket buffer). And can you elaborate about the ns-3 fake
> sockets.
> >
> > ---- Till know i am understanding that this linux kernel network
> integration can be implemented into linux kernel or user-space driver. And
> where are we planning to implement ?. If we are implementing the fake driver
> in kernel can we use NAPI apis for the network.
> >
>
>  The modified kernel code would run in the user-space ns-3 process.
>
>
>
> >
> > Re-use the network namespace code to allow instanciating multiple network
> stacks within a single address space. This area of the kernel code is still
> undergoing heavy development so, we expect that a lot of debugging will have
> to happen, as well, as, potentially, cleaning up some rought edges of the
> kernel implementation.
> >
> > ----- As stated the kernel code is undergoing heavy development in this
> area. What are we planning to do here ?? Just the debugging or cleaning the
> code or stick with the one linux kernel version and clean it .
> >
>
>  IMO, it would be useful to have a technique that was able to track the
> Linux kernel tree rather than freeze at a particular version.  But that
> would be much more challenging since the kernel APIs are not stable.
>
>  - Tom
>