[Ns-bugs] [Bug 75] Integrate multicast routing with the modular unicast routing framework

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=75





------- Comment #2 from gjcarneiro at gmail.com  2007-09-14 06:39 -------
(In reply to comment #1) 
> Can you clarify what you see as the problem?

  typedef Callback<void, bool, const Ipv4Route&, Packet, const Ipv4Header&>
RouteReplyCallback;

The route reply can only report a single route.  This does not work for
multicast, where the route for a multicast destination can generally have any
number of routes; in the limit, the routes can be one per number of interfaces
minus one (all outgoing interfaces except the one where the packet arrived). 
This is not supported.

Erm... now finally I was looking at the multicast implementation, and I see how
that is supported after all:

          NS_DEBUG ("Ipv4StaticRouting::RequestRoute (): "
            "Multicast route found");

          for (uint32_t i = 0; i < mRoute->GetNOutputInterfaces (); ++i)
            {
              Packet p = packet;
              Ipv4Header h = ipHeader;
              Ipv4Route route = 
                Ipv4Route::CreateHostRouteTo(h.GetDestination (), 
                  mRoute->GetOutputInterface(i));
              NS_DEBUG ("Ipv4StaticRouting::RequestRoute (): "
                "Send via interface " << mRoute->GetOutputInterface(i));
              routeReply (true, route, p, h);
            }

So basically for multicast destinations the routing protocol is supposed to
call the route reply several times, once per outgoing interface... so forget
what I said that it wasn't supported.

OK, re-evaluating the bug report...

I guess my only concern now is that this lacks the concept of transaction...
this way Ipv4 doesn't know whether a route reply is the last one or whether
more to follow.  I can't put my finger on why this is important.  My
"intuition" tells me it is important, but if you don't care about intuition
then feel free to ignore me :)

But at the very least the documentation should have been updated.  Now it says:

   * \brief Asynchronously requests a route for a given packet and IP header

Which implies only one route reply per request.  The documentation should have
been updated to clearly indicate that multiple replies can be expected, and
citing the multicast case to explain when this is may happen.

Finally, while this approach works fine, personally I would find it much
clearer to just have a different RequestMulticastRoute / MulticastRouteReply
interface specifically for multicast, although also integrated in the same
Ipv4RoutingProtocol class.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.