Difference between Ethernet 2 and 802.3 Frame per the Ethernet FAQ

In other words, if the field is up to 1500 then this frame is a 802.3 frame, and the field is a length for the rest of the frame. If the filed is more than 1500 then the frame is an 802.2 frame and the field has frame type information instead of a length.

It's a total size. The LLC header is either constant length or contains additional size information (I don't recall which at the moment.)

Perhaps this page will answer your questions:

I'm not sure what the FAQ is saying but if it's calling differences between Ethernet 2 and 802.3, it's probably referring to 802.3 as a combination of the all of them (since they are all 802.3 frames). If you have a specific context, post that - it would be easier to point out what they mean in that instance.

Anoop

Bonjour,

I just take your first satement.

I think this is a necessary behaviour, not only for newbies but also for experts, to live with its time. And its difficult because it makes effort, always spend time for reading new standards and new versions of old standards.

Since years, the IEEE 802.3 talks about the "length/type" field. So you cannot opposite version 2 to 802.3 frame type. The version 2 you called is an integral part of the basic MAC frame format, as it is described in figure 3-1 IEEE 802.3 2005.

You can ask to clarify the FAQ.

Best regards, Michelot

Hi Walter,

can you please elaborate > >

Hi Anoop,

Thanks for your reply. I was referring to the answer given in general to the question "what is the difference between Ethernet 2 and 802.3". Are they referring to just the 802.3 format or are they referring to

Also when reading through the FAQ again and also looking at the different frame types specified in your link just had another question

What is the 802.2 LLC? I mean that isn't a frame type. The Faq says that the 802.3 frame type was developed to be used with 802.2 LLC. The difference between the ethernet 2 and 802.3 Frame type with 802.2 LLC is the addition of the DSAP and SSAP. Just wondering why introduce the same field split into 2. The type field specifies the same information in the ethernet 2 format. The 802.3 SNAP makes more sense as it allows for future expansion since now you can specify the OUI and the protocol type and than have 256 protocols under each category and OUI.

I know I guess I am asking way too many questions. Just trying to get a better understanding of the fundamentals since it is a grey area for me. Thanks for your help.

ano> >

I think the most basic difference is that the "Type" format uses the two bytes following the MAC addresses to define the protocol being encapsulated by the Ethernet frame, and the "Length" format instead uses those two bytes to specify the frame length, and follows these with a DSAP, SSAP, and CTL bytes. That's it.

Back when, the IEEE was expecting to be able to define connectionless or connection-oriented services over LANs, including Ethernet and Token Ring, and "command" vs. "response" messages, as well as "receive ready," "receive not ready," "acknowledgment," "disconnect," and other such special purpose frames. In principle, these LANs would not necessarily have required other protocol layers to provide useful service, which instead the Ethernet "type" format did require. Think in terms of replacing a serial RS-232, with lots of predefined hardware handshake lines, and many other ones defined and added in the future, with a LAN-based equivalent. So with the LLC, Ethernet and other IEEE 802 LANs would provide the same services. That was the idea.

Not only that, but the DSAP and SSAP values, which would define specific Layer 2 protocols, had their own global/local and group/individual bits each, which could have been used to create proprietary Layer 2 unicast and multicast protocols.

I think the fundamental problem was that this "good idea" of DSAP and SSAP, along with their G/I and G/L bits, resulted in a very tiny DSAP/SSAP numbering space. A mere 64 possible globally standard choices. A design by committee that didn't prove as useful as people might have imagined. The SNAP header was added to rectify this problem. Had there been a lot more bits assigned to DSAP and SSAP, no SNAP kludge would have been needed.

Anyway, none of this matters very much anymore. IP has become the de-facto standard, vs specialty Layer 2 protocols, and when IP is trsanferred over Ethernet, the original "type" format is used almost exclusively. And if other protocols are layered over Ethernet, the SNAP header is used, with predefined AA-AA-03 DSAP-SSAP-CTL values.

Bert

Try this:

- An encapsulation method that can be used over any MAC be it 802.3, 802.5, etc.

- A service that can be either connectionless and unreliable, or connection-oriented and reliable.

Protocols like SNA depended on the reliable delivery service provided by 802.2 LLC.

Anoop