[Ns-developers] NetDevice::SetAddress

[Tom Henderson]

>-----Original Message-----
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Wednesday, June 24, 2009 11:17 PM
>To: ns-developers at ISI.EDU
>Subject: [Ns-developers] NetDevice::SetAddress
>
>hi,
>
>While reviewing recent changesets for API changes in the ns-3.5 release,
>I stumbled upon:
>
>changeset:   4578:88434ff8f0a5
>summary:     Finally make tap bridge work with VMs (bug 569)
>
>which adds NetDevice::SetAddress in src/node/net-device.h
>
>I can't comment on how this thing relates to the tap bridge (I did not
>look carefully at bug 569) but, I wanted to point out a couple of things
>about this change which make it look a bit fishy without more
>information. Hopefully, someone can chime in and comment on my concerns.

I am not sure of where to point you to past list discussions on this but in the tracker recently for bug 569, I had suggested NetDevice::SetAddress() while this current patch was cooking.

>
>NetDevice::SetAddress requires that the caller knows the address format
>of the underlying NetDevice. This means that, as a caller, you have to
>know the exact type of the underlying NetDevice to construct the needed
>Address object. If this is the case, I don't understand why the caller
>can't just DynamicCast and call the appropriate SetAddress method on the
>subclass.

As a caller, you need to know whether it supports a Mac48Address, and you need to know how to set it if you have a base class pointer.  NetDevice::SetAddress() solves the second part.  As for the first part, there is no easy way AFAICS with the current setup to know this short of downcasting to everything, so the current solution just goes for it.

>
>i.e., I am concerned that, so far, the NetDevice API was designed to
>make it possible for a caller to ignore the underlying address format to
>call any method defined in this class and SetAddress is breaking this
>design assumption. The methods we currently have which take an Address
>as argument are expected to pass an address coming from somewhere else
>so, until now, we never had to know the address format of an underlying
>device to call any method defined in the NetDevice base class. 
>

To summarize, to support tying containers to ns-3 NetDevices, we need to achieve alignment of virtual device and ns-3 mac addresses, because we decided last release cycle to not ask "non-bridging" NetDevices to support SendFrom().  If you do not have alignment between these device mac addresses, Arp will break, or else you need to munge addresses within Arp messages in the TapBridge.

If you do not want to have to edit TapBridge every time a new, compatible, ns-3 NetDevice is added, then there needs to be some abstraction.  If there were an intermediate abstract base class such as Mac48BasedNetDevice : public NetDevice and we supported a uniform SetAddress (Mac48Address addr) method in that class, and make Csma, Wifi, derive from it, that would work too.  A SupportsMac48Address() method might also help detect incompatibilities but doesn't teach the TapBridge how to set the address.  Other ideas?

Tom