[Ns-developers] review request for ns-3 IPv4 refactoring

Tom Henderson tomh at tomh.org
Wed Jan 28 22:45:47 PST 2009

Mathieu Lacage wrote:

>> The general problem here is that an agent (at runtime) needs to insert
>> a routing protocol into a node.  It has a Ptr<Ipv4>.  Take OLSR for
>> example.  OLSR could be inserted as the only routing protocol, or it
>> could be added to an existing routing protocol (the proposed
>> Ipv4ListRouting protocol) in the manner as is presently done in ns-3.
>> It can find out whether Ipv4 has a routing protocol, but in that case,
>> it needs to know whether it should insert itself as another protocol,
>> or assert due to trying to overwrite some other protocol.  
>> One way that I originally had this working was to DynamicCast the
>> Ipv4->GetRoutingProtocol to a ListRouting protocol (i.e., what you
>> call overengineering above).
>> Another possible solution would be to add some API to OLSR to instruct
>> it how it should add itself at runtime into the stack, rather than let
>> OLSR figure it out with such mechanisms. 
> ... I think that the right way to deal with this is to delegate the
> routing configuration to the user with helper classes. If you do this,
> then, you free yourself from all these hard problems. i.e.,
> // pseudo code
> class ListRoutingHelper
> {
> public:
>   void Add (std::string tid, std::string n0, const AttributeValue
> &v0, ...) {
>     ObjectFactory factory;
>     factory.SetTypeId (tid);
>     factory.SetAttribute (...);
>     ...
>     m_protocols.push_back (factory);
>   }
>   void Install (NodeContainer n) {
>     foreach node in n {
>       Ptr<Ipv4ListRoutingProtocol> list = CreateObject<> ();
>       for prot in m_protocols {
>         list->Add (prot.Create<Ipv4RoutingProtocol> ());
>       }
>     }
>   }
> };

I don't think the above suggestion helps in this case.  I have been 
trying not to change OLSR other than port it to the new Ipv4 API, and as 
a result it is not a configuration-time issue for a helper.  The basic 
problem is that OlsrAgentImpl::Start() calls:
   m_ipv4->AddRoutingProtocol (m_routingTable, 10);

It is the dynamically created OlsrRoutingTable that is the 
Ipv4RoutingProtocol to be inserted.

Now, if the Ipv4 routing API were simply
Ipv4::AddRoutingProtocol (Ptr<Ipv4RoutingProtocol>, int priority)
then there would be no problem.  But that method implies that the 
Ipv4RoutingProtocol is being added to some list with a relative 
priority, which is not necessarily the case if we, for instance, would 
like to simply enable Olsr as a node's only routing protocol.

In other words, part of this proposed API change is to not assume that a 
list routing protocol is the underlying implementation, and therefore 
adding a routing protocol with a priority value may not make any sense 
in some configurations.  That is why the priority value disappeared from 
class Ipv4's AddRoutingProtocol method.

So, it seems to me that either Olsr has to ask Ipv4 or its routing 
protocol how it should insert itself (hence, the 
"SupportsAddRoutingProtocol()" call), or OlsrAgent needs to be 
configured by something like a helper so that it knows at runtime how it 
should insert itself.


More information about the Ns-developers mailing list