Re: [ns] Multicast routing in ad hoc network

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Sat, 4 Mar 2000, Wong Hau Shian wrote:

> I'm interested in studying the behaviour of a multicast routing protocol
> for ad hoc network. After reading through the documentation, I understand
> multicast routing for ad hoc network is not supported in NS. I would like
> to know if the correct procedure is to port the multicast portion for wired
> network (with some modification of course) over to the wireless
> environment. I also wondering if doing this is a non trival issue. Thanks

This is something we were discussing doing for the satellite code,
which inherits from wireless and has a number of the same problems due
to lack of OTcl/C++ routing integration. Some points on this based on
discussions with Tom Henderson (any mistakes are my own):

a. In wireless code, links sit on top of channels which really are
   multipoint, whereas OTcl thinks of links as direct connections
   between nodes. So, add a receiver to a channel in C++, and you need
   to create links between that receiver's node and all possible
   senders on the same channel. OTcl routing as is assumes that
   either you've got point-to-point links between routers, or LANs
   with broadcast, and wireless functionality breaks that. If you
   want multicast over a wireless channel, much less over a realistic
   MAC, you've got your work cut out.

b. Link changes do not shadow each other in the two language realms
   (bad), and the OTcl multicast code pretty much assumes a static
   topology and a static tree - try something as simple as moving a
   multicast core...  The elegant way to solve this would be to rework
   the ns architecture to the status of C++ and OTcl links visible in
   both C++ and OTcl so that you could have properly dynamic
   simulations and get e.g. the OTcl multicast code to see and handle
   link changes, but that doesn't strike me as easy, even for someone
   who is
     i. experienced with ns, intimately familiar with its inner
        workings, and in the VINT developer loop, 
    ii. the world's best obsessive coder,
   iii. has all the time in the world on her hands and is living in an
        extremely boring environment without undue distractions.

c. making all of the OTcl routing work correctly over C++ links would
   be difficult, due to additional routing shim layers that have been
   implemented in OTcl for multipath links. However, since multipath
   isn't general (only works with DV routing, which few care about,
   has only just been gotten working on a per-node basis) you'd
   probably just end up shrugging and breaking multipath permanently.
   (I've got to figure out a decent test script against that
    possibility.)


Tom suggested having the satellite code do an OTcl callup each time a
link event happened, or implementing multicast routing in C++ for the
satellite code, but both those (satellite-specific) approaches would
need considerable additional work to get anywhere near functional, and
just make the satellite code even more different from the rest of ns
as it diverges.

Basically, since link changes don't shadow each other, parts of ns
(mostly OTcl routing) assume fixed topologies, other parts (mostly
C++) assume changing topologies - and the parts with different
assumptions don't work together. The real fix is to make all of ns
handle dynamic changes in the network, and that involves a bit of
rewriting of all parts.

hth,

L.

'trivial' is matter of perspective. so is 'scary'.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>