[Ns-developers] Ns-3 Multicast Support

[Joseph Kopena]

On 8/29/07, Tom Henderson <tomh at tomh.org> wrote:
> craigdo at ee.washington.edu wrote:
> >> Address NetDevice::ConvertMulticast (Ipv4Address address)
> >> Address NetDevice::ConvertMulticast (Ipv6Address address)
> >
> > This is exactly what I proposed originally, and shows the signature of the
> > method currently in ArpIpv4Interface.  Is everyone okay with moving the
> > method down into the Net Device?
> >
> > Is there a consensus on pushing the repo given this change?
>
> Although I originally suggested to put this into the Arp layer, I have
> been persuaded by your proposal, because otherwise it seems like we will
> impose more requirements on the Arp layer to figure out each NetDevice's
> IP to multicast mapping.

If I can chime in: RFC 1112 doesn't actually stipulate anything in
general about eui48 addresses.  It's only specifying that, sensibly,
for IP layers running over local Ethernet hardware.  It explicitly
discusses other possible mappings, i.e. converting all IP multicast
addresses to the hardware broadcast address if the MAC supports the
latter but not the former.  It also discusses mapping multicast
traffic to a unicast address for a local router which bounces the
messages back out.

More requirements on the "ARP" layer isn't necessarily a bad thing.
It is somewhat unfortunate currently that you have to have an ARP
wrapper around your NetDevice, even if it's not being used.

I think the change to make is to not directly attach NetDevice objects
to the Ipv4 interface, but rather to attach a local address mapping
object/local network service interface to the Ipv4 interface, which in
turn works with the NetDevice.  This is already implicitly happening
with the ARP wrapper, but that should be made into a more
powerful/general local network service interface object to cover
unicast/broadcast/multicast, and the scenario writer given more
control over it, i.e. explicitly choosing what interface object to
add.  This is directly in line w/ the generally accepted IP stack
structure, e.g. the figure on page 3 of RFC 1112.

Several cases to keep in mind:

- There may be models for which ARP isn't necessary, that work on IP
addresses natively.  The API supports this by disabling ARP, but it
seems cleaner to have the scenario attach the device under a local
network service interface object which simply passes through the
addresses forwarded done the stack.

- ARP may not function the same way on all networks even when
necessary.  For example, my limited understanding of some of the
drafts from IETF's 16ng group is that they specify very different ARP
protocols for IP over 802.16.  I have to read about it more, but my
understanding was that they propose things like unicasting up to an
access router behind the base station to retrieve CIDs or SIDs
(connection or subscriber IDs) because the broadcast/multicast channel
has deleterious effects on bandwidth and power consumption for the
whole network (no beamforming, MIMO, less sleep windows, etc).


Modifying the ARP wrapper to be a more general local network service
interface object, of which many variants may exist and the current ARP
wrapper being a particular implementation of it, and giving scenario
writers more obvious control over it, allows NetDevices to be
constructed and used without any knowledge of IP, and provides for
different address resolution mechanisms to be used, while being
straightforward and mirroring real life IP integration and the stack
specifications.

Thx

-- 
- joe kopena
  right here and now