[mcnet4l-devel] eui-48 and moniker conversion.

[Daniel S. <st...@in...>]

hi "all" :)

first of all, i noticed yesterday that somewhere between D0.64 and
D1.0 the moniker byte order has been reverted to true EUI-64 byte
ordering (big endian) as opposed to the rest of binary number formats
being le.

whoever proposed this: thank you, good idea (no kidding). makes my
day.

second, an issue regarding 48/64-bit conversions:

the following is taken from
http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html 
(i must admit i actually never read that page before)

* MAC-48: A 48-bit identifier used to address hardware interfaces
  within existing 802 based networking applications
* EUI-48: A 48-bit identifier used to identify a design instance, as
  opposed to a hardware instance. Examples include software interface
  standards (such as VGA) or the model number for a product.
* EUI-64: A 64-bit identifier used to identify each hardware instance
  of a product, regardless of application, such as wireless devices
  and computerized toasters.

while the difference between MAC-48 and EUI-48 is pretty zero
regarding the resulting addressing scheme, the above statement makes
2.14 appear to me rather as a MAC-48 application than EUI-48.
Ok, the question whether 2.14 is 802 based is definition dependant,
but a moniker is definitely not a design instance as defined above.

Why I care? 48-bit encapsulation:

   ccccccFFFEeeeeee16   (an EUI-48 extension)

   ccccccFFFFeeeeee16   (a MAC-48 extension)

from this standpoint the encapsulation scheme described in 2.14
chapter 3.1, defining a fill sequence of ff:fe would be wrong.

assuming to be right here: i'm not sure about the implications. As
long as everybody is coding along the picmg spec and does not look
into ieee documents, this certainly does not break interoperability on
the backplane. any 'theoretical' danger when bridging into 802.x LANs
or stuff like that?

regards,
dns

-- 
___________________________________________________________________________
mailto:st...@in...