[Ns-developers] release update [feedback needed]

[Mathieu Lacage]

On Tue, 2009-06-09 at 22:38 -0700, Tom Henderson wrote:
> +  virtual void NotifyInterface (uint32_t i, bool isUp) = 0;
> 
> This is similar to what is found in RTM_NEWLINK and RTM_DELLINK for 
> rtnetlink in Linux (man rtnetlink), except that the boolean flag allows 
> both to be in a single method NotifyInterface.  Since the routing 
> protocol consuming this message will presumably be able to acquire a 
> pointer to class Ipv4 to get whatever other information is needed, the 
> interface index is probably sufficient information to pass up.
> 
> The questions/concerns I have:
> 
> 1) implicit assumptions are made about the order in which these 
> operations occur:
> - set an IP interface to up
> - add an IP address to an interface
> - set an IPv4RoutingProtocol to the Ipv4 object
> - add an additional routing protocol to the Ipv4ListRouting protocol
> 
> There are certain combinations of operations that will cause this to 
> lose information; e.g.
> - add the Ipv4ListRouting to the Ipv4, and subsequently add protocols 
> like OLSR (the protocols added later will not get the notifications)

I believe that the above needs to be dealt with by asking routing
protocols to discover existing interfaces and handle them when they are
added to a node. The Notify methods then only notify about changes in
the existing configuration. Initially, to avoid that complexity, I think
that it would be reasonable to ask users to first setup routing
protocols and, then, setup ip interfaces. We can improve the routing
protocol implementations to make them able to handle any ordering of
operations (add to node, then, add interfaces or add interfaces, then
add to node) in a separate step. Faker and I have done some work towards
that recently with the changes you merged to the InternetStackHelper to
allow users to aggregate the different elements of a udp/tcp/ip/arp
stack in any order.

> - add an IP address to an interface (such as a second address) after the 
> first address was added and interface was SetUp()

As you mention below, it's easy to deal with the above with extra Notify
methods.

> so, it would help to add code to deal with users possibly rearranging 
> these operations.  For instance, I think that probably these additions 
> are needed:
>    - NotifyAddAddress (uint32_t i, Ipv4InterfaceAddress addr)
>    - NotifyRemoveAddress (uint32_t i, Ipv4InterfaceAddress addr)

ok, will do the above and split NotifyInterface in NotifyInterfaceUp and
NotifyInterfaceDown. I was lazy :)

> 
> or, for symmetry with NotifyInterface(), it could be:
>    - NotifyAddress (uint32_t i, Ipv4InterfaceAddress addr, bool IsAdded);
> 
> and probably Ipv4ListRoutingImpl::AddRoutingProtocol () needs to notify 
> the new routing protocol added of the interfaces, in case it is added 
> after being hooked to Ipv4.

What do you mean by this exactly ?

> 2) implicit assumption about the user not repeating these methods or
> calling them out of order-- e.g. can NotifyInterface (i, true); be 
> called multiple times (resulting in multiple redundant routes)?  Should, 

No.

> for instance, the current state of an interface be saved so that these 
> calls can be detected and avoided?

It should be easy to invoke these methods only on real state changes.

> 3) I had thought about putting in an rtnetlink-like framework for what 
> you posted, but that may be overkill for the moment.  However, suppose 

It feels overkill for the moment.

> someone wanted to add an rtnetlink notification framework to ns-3 in the 
> future.  What kind of notification framework would you recommend? 
> Multicast messaging internally?  Some kind of callback framework (could 
> you have multiple users register callbacks somewhere for the same event, 
> and where would they register (a Netlink object?)?

I don't have any good idea about this.

Mathieu