[Ns-developers] ns-3.5 planning

[Tom Henderson]

> Here is my understanding of the status of each separate item:
> 
> 1) ipv4 rework: tom and I agreed to try to split it, and specifically,
> try to split the API changes from the implementation changes. Right now,
> the proposal is to merge the following trees:
>   - mathieu/ns-3-olsr
>   - tomh/ns-3-ip-interfaces
 >   - tomh/ns-3-ip-routing

I didn't yet socialize these trees to the list yet for review but they 
are ready for review.  I will introduce these in a separate mail.

>    -tomh/ns-3-ip-interfaces: my main comment for this tree is that I am
> still unsure I understand what the peer field is supposed to represent
> and how it is expected to be used.

This is a field in struct in_addr used for point-to-point links in 
Linux; documentation from iproute2:

  peer ADDRESS--- address of remote endpoint for pointopoint interfaces.

We do not use this in our code right now, so it could be commented out 
until it is used.

>   - tomh/ns-3-ip-routing: missing a README.api. Ipv4Route should derive
> from src/node/ref-count-based.h instead of implementing Ref+Unref.

OK.  This tree is not as far along as the other tree in incorporating 
the proposed routing changes that are in ns-3-ip tree.

> 
> Needed followup patches:
>   - new src/helper/ipv4-routing-helper.h 
>   - move src/internet-stack/static-routing-protocol.h to src/node,
> modify it to implement a linux-like routing table API
>   - introduce a loopback device, remove Ipv4LoopbackInterface
>   - remove virtual methods from Ipv4Interface
>   - add src/node/arp.h, implement it in ArpL3Protocol

agree with all of the above

>   - remove ::SetNode in src/internet-stack/*.h|cc: all these objects are
> aggregated to a node, so, they can call GetObject.
>   - remove src/internet-stack/internet-stack.cc:
>       a) make UdpL4Protocol aggregate UdpSocketFactory to self from
> constructor. Same for TcpL4Protocol/TcpSocketFactory.
>       b) add src/core/object.h: call NotifyNewAggregate from
> AggregateObject
>       c) Hook in NotifyNewAggregate from UdpL4Protocol, check for
> Ipv4L3Protocol, register new l4 protocol when Ipv4L3Protocol is
> aggregated or when they are created

I hadn't planned to do the above replumbing, but one improvement that 
the current ns-3-ip-interfaces has is the removal of class Ipv4Impl. 
I'll leave the above alone for now since they are somewhat orthogonal to 
the routing stuff (which is where I want to focus).

> 
> 4) virtual devices was sent here for review a long time ago:
> http://code.nsnam.org/gjc/ns-3-virtual-netdevice/ I think that it could
> be useful to more users so, I would support merging it and would be
> happy to help gustavo port this to ns-3-dev.

+1 but we could probably call this one a TapDevice.

> 8) so far, ipv6 is blocked on item 1) and item 1. is far from being
> finished. If I put my realistic hat on, I predict that there is zero
> chance to complete 1) sufficiently early to allow ipv6 to go in this
> release cycle.

I would like to move forward on a few IPv6 things at least in this 
release cycle, but I agree that the item 1 work is substantial.


> 
> 10) This was posted a while ago: tom agreed on the basic idea with minor
> comments, and there were no other comments. I think that it could go in
> in a couple of days once we have fixed the identified issues.
> 

Agree.

- Tom