5

When MAC addresses are sent out they are sent such that the Group Address Indicator is the first bit of the Ethernet frame but when stored in memory this forms the LSB of the leftmost byte of the MAC address. For example-

             In memory,      12       34       56       78       9A       BC
               canonical:   00010010 00110100 01010110 01111000 10011010 10111100

                            1st bit appearing on LAN (group address indicator)
                            |
               On LAN:      01001000 00101100 01101010 00011110 01011001 00111101

What is the reason for this design decision that requires swapping of the bits of a byte in the a address before it is sent out on the LAN? Does it have a historic importance in that it made sense when the protocol was designed? Does this design have certain specific advantages?

Also something of relevance to my question that I thought I must mention is that this wasn't the case with all the of the LAN adopters. (mentioned here:RFC 2469)

7

There is no real advantage to sending LSB (Little-endian) or MSB (Big-endian) first. As long as the same convention is followed by everyone, this allows communication to take place. To your final note, other communications protocols such as RS-232 (serial) also used Little-endian and in general, I believe it was much more common to do so.

Keep in mind that computers operate based purely on bits. Anything else you see is simply a conversion to a more "human" way to deal with the bits.

If you were to use Big-endian, then the easiest way to store the same 48-bit address in memory would be as follows:

0100 1000 0010 1100 0110 1010 0001 1110 0101 1001 0011 1101

If the bits actually had significance beyond being just bits, then you would end up with the following in hex:

4 8 2 C 6 A 1 E 5 9 3 D

So your Little-endian address hex representation of the bits is 12-34-56-78-9A-BC, but the very same address in a Big-endian network would be 48-2C-6A-1E-59-3D (if I did all that right...been a while since I had to convert Little-endian addressing to Big-endian). The exact same address, just a different way to store/transmit the bits.

Heading off the beaten path, so feel free to stop reading...

This lead to some really interesting interactions with TCP/IP. Since Ethernet (Little-endian) came before Token Ring (Big-endian), ARP was designed around the Little-endian addressing. When you bridged traffic between Ethernet and Token Ring, the bridge has to support IP (in order to recognize ARP packets) and re-order the bits in the ARP address fields appropriately. This was a less than ideal solution as it forced L3 functionality on L2, but it did resolved the problem.

When FDDI (Big-endian) came along even later, the TCP/IP designers wanted to avoid this problem and designed ARP on FDDI to use Little-endian for the address fields. This avoided having to modify both the headers and the payload of ARP packets when bridging Ethernet to FDDI. However, it also meant a bridge connecting Token Ring to FDDI would need to re-order the bits in the address fields. It was just much rarer to bridge Token Ring to FDDI than it was to bridge Ethernet to FDDI.

Other protocols such as AppleTalk were also similarly affected, but generally weren't provided a solution as they were not as prevalent as TCP/IP. So, if you were to bridge Ethernet to Token Ring, this would break AppleTalk.

0

Computers do not work with individual bits. On virtually all current computers the smallest addressable unit of memory is the 8-bit byte. Our higher level communications protocols also assume bytes as their basic unit of data. Similarly the internal busses in computers don't move data one bit at a time but in groups of 8, 16, 32, 64 or more bits.

When desinging a serial comunications protocol the protocol designer must decide which bit to send first. The actual choice is largely arbitary, it makes no real differentce to implementation complexity because the bits in a byte don't really have a natural order.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.