12-20-2012 05:13 AM - edited 03-07-2019 10:43 AM
The difference between the 3/4 framing types.
Frames
So there are four ether frame types.
a. Orignal Ethernet frame 'aka' Ethernet DIX
b. IEEE 802.3 LLC frame 'aka' Ethernet 802.3
c. IEEE 802.3 with SNAP
d. Eternet 2 'aka' Revised IEEE 802.3
I get this, whats throwing me is that each book is calling them something different, I need clarity here with the correct names for these different frame types. For example is (b.) called IEEE 802.3 LLC, Ethernet 802.3 or something else?
What would you call the 4 types to distinguish the difference betwen them?
And how important in the preamble field? Do I just need to know that it's 8 bytes in size, or do I need to understand the signalling used?
CCIE-Written prep.
Solved! Go to Solution.
12-20-2012 03:19 PM
Hello Samuel,
I get this, whats throwing me is that each book is calling them something different, I need clarity here with the correct names for these different frame types. For example is (b.) called IEEE 802.3 LLC, Ethernet 802.3 or something else?
Okay, let's have a look at the individual types, and let me take that from my own perspective, not commenting the options at first.
The original Ethernet 1 frame was the initial Xerox Ethernet implementation and according to Wikipedia, it was never comercially deployed. In fact, I have troubles finding any specification on this prehistoric Ethernet format. You should not bother with that very much, as that frame type is totally obsolete.
The second generation of Ethernet, also called Ethernet II, Ethernet 2, or Ethernet DIX, was developed by Xerox in cooperation with Digital and Intel. These three names - Ethernet II, Ethernet 2 and Ethernet DIX all refer to the very same frame format - the one we are using today:
DstMAC, SrcMAC, EthType, Data, FCS.
When DIX approached IEEE with the request to standardize the Ethernet, IEEE took it and made a little twist on the frame format, making it slightly more similar to HDLC which was a popular basic frame format at that time. What resulted was a basic frame skeleton:
DstMAC, SrcMAC, Length, Data, FCS
Note that the only difference here is in the redefinition of the EthType field to Length field. There was also a format change to the preamble but let's skip that for now. This basic IEEE Ethernet frame skeleton is standardized in 802.3.
I am calling the 802.3 a skeleton for a reason. It is not really a usable frame format because this frame structure is missing any identification of the payload. You simply don't know what the frame carries. IEEE obviously did not intend this 802.3 frame skeleton to be used just this plainly, but rather, they reused the Logical Link Control from HDLC and they adapted it for Ethernet in their 802.2 standard. This adaptation of the LLC consisted of adding at least three bytes to the header (stealing bytes from the Data section as the frame was not allowed to grow larger): the DSAP, SSAP and Control bytes. So when we take the 802.3 skeleton and compound it with the 802.2-derived LLC fields, we get
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, Data, FCS
This frame format in its entirety should be called 802.2 LLC. Note that if you call it 802.3 LLC, you are not saying anything wrong - you have the basic 802.3 skeleton plus the 802.2 LLC. I personally like to call it 802.2 LLC, though.
The limitations of this frame format soon became apparent, as the DSAP/SSAP fields intended to describe the protocol inside the frame are just 1 byte long, with half of values being reserved for private/group service addressing, and the remaining values being too few to realistically describe all existing higher-level protocols (not even mentioning a rigid process of obtaining an official SAP value for a protocol). Therefore, IEEE came up with the SNAP frame format that keeps the basic 802.2 LLC structure but steals another 5 bytes from the Data field for the protocol vendor OUI and protocol ID. The entire frame then becomes
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, OUI, ProtoID, Data, FCS
Interestingly enough, this SNAP extension is described in the basic 802 document (not any 802.x addendum). Therefore, this frame format should be called simply 802 SNAP.
So to sum it up:
DstMAC, SrcMAC, EthType, Data, FCS: Ethernet II, Ethernet DIX, Ethernet 2
DstMAC, SrcMAC, Length, Data, FCS: IEEE 802.3 (not really usable, just a basic container)
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, Data, FCS: IEEE 802.3 + IEEE 802.2 LLC
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, OUI, ProtoID, Data, FCS: IEE 802 SNAP
And how important in the preamble field? Do I just need to know that it's 8 bytes in size, or do I need to understand the signalling used?
There are more important things on the CCIE R&S Written than the Ethernet preamble, but just in case:
DIX Preamble = 802.3 Preamble + 802.3 Start-of-Frame Delimiter
Preamble: 7 bytes of binary 10101010 (0xAA or 170)
Start-of-Frame Delimiter = 1 byte of binary 10101011 (0xAB or 171)
IEEE just formally split the 8B DIX preamble into 7B field they call preamble, and 1B field called SOF.
Feel welcome to ask further!
Best regards,
Peter
12-20-2012 10:18 AM
Hi Samuel,
Seek guidance from earlier Novell and IBM books\urls for your answers - I could not do this topic justice, perhaps someone else could\would.
However,
The preamble is used to signify a valid frame is on the wire. Meaning if a receiving device's NIC sees 11111111 ( 8 ones is a valid preamble) then the NIC "prepares" for the frame. If a NIC sees 11111110 (or something other than 8 ones) ) this is not a preamble so the frame is ignored. If you are using Wireshark, you will never see the preamble as the preamble is to alert other devices on the "wire" (transfer medium) a frame is about to be sent, but I guess if you used an oscilloscope you would see the preamble.
Hope this helps
Frank
12-20-2012 03:19 PM
Hello Samuel,
I get this, whats throwing me is that each book is calling them something different, I need clarity here with the correct names for these different frame types. For example is (b.) called IEEE 802.3 LLC, Ethernet 802.3 or something else?
Okay, let's have a look at the individual types, and let me take that from my own perspective, not commenting the options at first.
The original Ethernet 1 frame was the initial Xerox Ethernet implementation and according to Wikipedia, it was never comercially deployed. In fact, I have troubles finding any specification on this prehistoric Ethernet format. You should not bother with that very much, as that frame type is totally obsolete.
The second generation of Ethernet, also called Ethernet II, Ethernet 2, or Ethernet DIX, was developed by Xerox in cooperation with Digital and Intel. These three names - Ethernet II, Ethernet 2 and Ethernet DIX all refer to the very same frame format - the one we are using today:
DstMAC, SrcMAC, EthType, Data, FCS.
When DIX approached IEEE with the request to standardize the Ethernet, IEEE took it and made a little twist on the frame format, making it slightly more similar to HDLC which was a popular basic frame format at that time. What resulted was a basic frame skeleton:
DstMAC, SrcMAC, Length, Data, FCS
Note that the only difference here is in the redefinition of the EthType field to Length field. There was also a format change to the preamble but let's skip that for now. This basic IEEE Ethernet frame skeleton is standardized in 802.3.
I am calling the 802.3 a skeleton for a reason. It is not really a usable frame format because this frame structure is missing any identification of the payload. You simply don't know what the frame carries. IEEE obviously did not intend this 802.3 frame skeleton to be used just this plainly, but rather, they reused the Logical Link Control from HDLC and they adapted it for Ethernet in their 802.2 standard. This adaptation of the LLC consisted of adding at least three bytes to the header (stealing bytes from the Data section as the frame was not allowed to grow larger): the DSAP, SSAP and Control bytes. So when we take the 802.3 skeleton and compound it with the 802.2-derived LLC fields, we get
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, Data, FCS
This frame format in its entirety should be called 802.2 LLC. Note that if you call it 802.3 LLC, you are not saying anything wrong - you have the basic 802.3 skeleton plus the 802.2 LLC. I personally like to call it 802.2 LLC, though.
The limitations of this frame format soon became apparent, as the DSAP/SSAP fields intended to describe the protocol inside the frame are just 1 byte long, with half of values being reserved for private/group service addressing, and the remaining values being too few to realistically describe all existing higher-level protocols (not even mentioning a rigid process of obtaining an official SAP value for a protocol). Therefore, IEEE came up with the SNAP frame format that keeps the basic 802.2 LLC structure but steals another 5 bytes from the Data field for the protocol vendor OUI and protocol ID. The entire frame then becomes
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, OUI, ProtoID, Data, FCS
Interestingly enough, this SNAP extension is described in the basic 802 document (not any 802.x addendum). Therefore, this frame format should be called simply 802 SNAP.
So to sum it up:
DstMAC, SrcMAC, EthType, Data, FCS: Ethernet II, Ethernet DIX, Ethernet 2
DstMAC, SrcMAC, Length, Data, FCS: IEEE 802.3 (not really usable, just a basic container)
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, Data, FCS: IEEE 802.3 + IEEE 802.2 LLC
DstMAC, SrcMAC, Length, DSAP, SSAP, Control, OUI, ProtoID, Data, FCS: IEE 802 SNAP
And how important in the preamble field? Do I just need to know that it's 8 bytes in size, or do I need to understand the signalling used?
There are more important things on the CCIE R&S Written than the Ethernet preamble, but just in case:
DIX Preamble = 802.3 Preamble + 802.3 Start-of-Frame Delimiter
Preamble: 7 bytes of binary 10101010 (0xAA or 170)
Start-of-Frame Delimiter = 1 byte of binary 10101011 (0xAB or 171)
IEEE just formally split the 8B DIX preamble into 7B field they call preamble, and 1B field called SOF.
Feel welcome to ask further!
Best regards,
Peter
12-21-2012 12:10 AM
Peter,
Makes a lot more sense now, did some additional reading to and I think I have clarity.
The SOF bits were useful to know as I could not find any documentation for this.
Just trying to cover everything and not get to hung up on the minute details, I feel this is going to be one hell of a ride.
Frank, I don't think I am quite ready for the oscilloscope just yet, cheers for the help.
Cheers' Sam.
Sent from Cisco Technical Support Android App
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide