Bug 75

I'm not sure what you mean.  Multicast is integrated into the modular routing framework.  Added routing protocols can either handle multicast, unicast, either or both -- multicast is supported just like unicast.  If you want to add an ad-hoc multicast routing protocol, you can do so.

Can you clarify what you see as the problem?

(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.

Add explicit documentation to resolve.