[Ns-developers] NS3: Integrating routing protocols into ns-3

[Gustavo Carneiro]

Context: for my PhD I am currently trying to port OLSR code written by
Francisco J. Ros from NS-2 to NS-3.  Serialization of OLSR headers is
implemented, and went well.  Now I am looking at routing table integration
issues.

The OLSR implementation is supposed to add routing table entries.  The ns-3
equivalent of "routing table interface" is part of the IPv4 interface:

class Ipv4 : public Object
{
[...]
  virtual void AddHostRouteTo (Ipv4Address dest,
                   Ipv4Address nextHop,
                   uint32_t interface) = 0;
  virtual void AddHostRouteTo (Ipv4Address dest,
                   uint32_t interface) = 0;
  virtual void AddNetworkRouteTo (Ipv4Address network,
                  Ipv4Mask networkMask,
                  Ipv4Address nextHop,
                  uint32_t interface) = 0;
  virtual void AddNetworkRouteTo (Ipv4Address network,
                  Ipv4Mask networkMask,
                  uint32_t interface) = 0;
  virtual void SetDefaultRoute (Ipv4Address nextHop,
                uint32_t interface) = 0;
  virtual uint32_t GetNRoutes (void) = 0;
  virtual Ipv4Route GetRoute (uint32_t i) = 0;
  virtual void RemoveRoute (uint32_t i) = 0;
[...]
};

My current concerns are:
    1. Shouldn't the Add*Route methods return the route index, so that later
I can retrieve it again with GetRoute?

    2. Related tot the above question, why not instead of returning an
'index' return a unique numeric identifier?  My concern here is that a route
index is not stable, and becomes invalid as soon as routes are reordered,
removed, or inserted.

    3. The OLSR code I'm porting has its own "routing table":

typedef struct OLSR_rt_entry {
    nsaddr_t    dest_addr_;    ///< Address of the destination node.
    nsaddr_t    next_addr_;    ///< Address of the next hop.
    nsaddr_t    iface_addr_;    ///< Address of the local interface.
    uint32_t    dis_;        ///< Distance in hops to the destination.
[...]
} OLSR_rt_entry;

class OLSR_rtable {
[...]
    void        clear();
    void        rm_entry(nsaddr_t dest);
    OLSR_rt_entry*    add_entry(nsaddr_t dest, nsaddr_t next, nsaddr_t
iface, u_int32_t dist);
    OLSR_rt_entry*    lookup(nsaddr_t dest);
    OLSR_rt_entry*    find_send_entry(OLSR_rt_entry*);
    u_int32_t    size();
};

  The main differences between ns-3 routing table and the ns-2/olsr one are:
   a) the olsr table provides a lookup-by-address method;
   b) olsr routing table entries have an additional 'distance' member;

  It would be nice to enhance the ns-3 routing table so that i won't need a
duplicate olsr table.  This is why I think it makes sense:
   a) lookup-by-address is a simple algorithm that is unlikely to change
regardless of routing protocol, so it might as well be exposed as a public
method;
   b) the olsr 'distance' field is equivalent to the 'metric' of e.g. a
Linux routing table:

"man route" says:
[...]
       Metric The 'distance' to the target (usually counted in hops). It is
not used by recent kernels, but may  be  needed
              by routing daemons.
[...]

  Sorry, I know it is probably too soon to push  ns-3 to adhoc routing
protocols development :)  Unfortunately I need it now and can't wait :-/

  In any case, any feedback is appreciated.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert