[Ns-developers] ns-3: LLC hardcoded in NetDevice?
Mathieu.Lacage at sophia.inria.fr
Tue Mar 6 05:24:40 PST 2007
On Tue, 2007-03-06 at
> I can understand the protocol number only as an optimisation in the
> simulator, not something that is needed...
I do not understand that statement. How would the higher layers know
that they get an ARP or a IP packet ? How would the low layers know that
they have to send an ARP and an IP packet ? In both cases, you need to
convey that information. It certainly seems to me that the higher layers
need to pass down the protocol number information and need to get it
back when they receive a packet.
> If so, as I said above, the two options are:
> - delegate llc/snap multiplexing/demultiplexing to the
> - implement llc/snap multiplexing/demultiplexing in a higher
> Protocol number could be derived either from the MAC layer directly
> (the Type/Length field of Ethernet II), or from LLC/SNAP. And either
> 802.3 or 802.11 cards could en theory use either of those methods.
> With that in mind, my recommendation would be to make this a
> composition relationship, i.e. a new optional shim layer, rather than
> creating new subclasses for each of the possible combinations. If you
If you are willing to use the ethernet II length field to encode the
type, I am not sure how you could really delegate the multiplexing work
to a third party independent of the subclass.
> agree it's something you want to improve eventually, should I then
> file a bug report for this?
You can always file a bug :)
More information about the Ns-developers