[Ns-developers] upcoming work on Ipv4 routing

[Tom Henderson]

Mathieu Lacage wrote:
> A couple of comments:
> 
> On Tue, 2008-10-21 at 19:58 +0000, Tom Henderson wrote:
> 
>> Here is a link to the overall design approach:
>> http://code.nsnam.org/tomh/ns-3-ip/raw-file/0c9f7a1e050a/README.routing.txt
>>
>> There is also a file "README.routing.api" with more details about the
>> API:
>> http://code.nsnam.org/tomh/ns-3-ip/raw-file/0c9f7a1e050a/README.routing.api
> 
> What is the return type of this method ?

it could be an int or an enum.  In Linux, it can return an error code 
that takes values such as ENETUNREACH, ENODEV, and EINVAL.  I am not 
sure what values we may want to support, but it seemed like bool would 
be too limiting, and enum might be preferable to int.


 > I would also feel better if the
> outgoing parameter (route) was the last parameter of this method.

I can move it to the end-- I put it in the beginning because that is 
where the corresponding Linux parameter is located.
> 
> virtual enum RouteOutput (Ptr<Ipv4Route> route, const Ipv4Header
> &header, uint32_t oif) = 0;
> 
> Is it possible for a callback to be invoked more than once for one call
> to this method RouteInput ?

I wasn't planning on that.

> 
> virtual void RouteInput  (Ptr<const Packet> p,
> 
> What does rtm stand for ? Would you mind extend it ?

The abbreviation comes from the below netlink functions. RTM stands for 
routing message, I believe.
> 
>   // Linux inet_rtm_newroute
>   bool RtmNewRoute (RoutingMessage rtm);
>   // Linux inet_rtm_delroute
>   bool RtmDelRoute (RoutingMessage rtm);
>   // Linux inet_rtm_getroute
>   Ipv4RouteList RtmGetRoute (RoutingMessage rtm);
> 
> 
> What is the point of item 6 ? Ipv4RoutingProtocol looks like a subset of
> Ipv4Routing so, I can't figure out why you want to keep it.

Ipv4RoutingProtocol is considered to be basically the same as what we 
have now-- such as ns-3 OLSR, a user-space daemon, while Ipv4Routing is 
like a kernel routing component.

However, it may be helpful to converge these two classes, so that one 
might be able to just plug in OLSR as a routing protocol by itself, and 
also doing so might enable recursive routing protocol hierarchies.  I'll 
think about that some more.

- Tom