[Ns-developers] creating MAC-level multicast addresses (was: ns-3.5 planning / mac multicast)

[Fabian Mauchle]

I will split this up to keep a separate focus on each of the topics

-----Ursprüngliche Nachricht-----
Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr] 
Gesendet: Donnerstag, 16. April 2009 13:42
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: ns-developers at ISI.EDU
Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast

On Wed, 2009-04-15 at 10:03 +0200, Fabian Mauchle wrote:

> I recently worked on multicasting in Wifi networks. The current
> implementation of MAC multicast in Wifi and Csma networks do basically
their
> thing, but they do not correctly represent reality.
> 
> 1. The NetDevice is currently responsible for creating the multicast MAC
> address [NetDevice::GetMulticast(Ipv4Address)]. I don't know of any real
API
> which would do this.

It is merely responsible for creating a MAC-level multicast address
which matches the higher-layer multicast address. The reason this is
done is to encapsulate the MAC address format from the higher layers. If
you don't do this, you will have to move knowledge of the MAC-level
address format to the ip layer. Linux does this, BSD too, but it's not
very pretty.
-----Ursprüngliche Nachricht-----

Currently, some knowledge (mainly the IP address format) of the IP layer is
in the MAC-layer, which I think is neither very pretty. Basically, the
responsibility for mapping IP addresses to MAC addresses is implemented in
the ArpIpv4Interface class (except for multicast).

- A network stack is a layered architecture, therefore the layer n should
not need to know details about the n+1 layer (but the n+1 layer needs to
know about the API (including address format) of the layer n it uses).
- In the actual implementation, the L2 needs to know about the L3, in order
that the L3 is able to use the L2.
- All NetDevice implementations (except one) do exactly the same in the
GetMulticast(...) methods. (I don't like duplicate code)
- The GetMulticast(...) method is only called at one single place within
IPv4 (in ArpIpv4Interface).
- If I wanted (hypothetically) to create a new L3 protocol, I would have to
make changes to the NetDevice interface, and subsequently to all
implementations.

To summarize: I agree with you that knowledge of the MAC-level will not look
pretty in the IP-layer, but in my opinion, the current implementation
violates layer separation.

I don't have a real use-case for this, it's just for refactoring
consideration.

Fabian