Ethernet Frame

 

Ethernet Frame

Here we discuss both legal and illegal Ethernet frames.  The receiver will drop all illegal frames.

The vast majority of all local (LAN) data traffic in the world is Ethernet frames !!  There is no single unit of data that is more common.  So anyone in any type of technical field would benefit by understanding the contents of these frames, and how they are transmitted and received. 

 

Min Frame Size = Header+CRC+DataMin = 64
Max Frame Size = Header_CRC+DataMax = 1518

 

IP packets encapsulated into Ethernet Frames

Note that maximum length Ethernet II frames (1518 bytes, with a payload of 1500 bytes) are much smaller that maximum length IP packets (65,535 bytes).  Therefore, for large packets, they must be fragmented into many frames !! 

For example, the number of Ethernet frames required to deliver a maxed out packet of 65535 bytes across an Ethernet LAN, between two workstations can be calculated as follows:

 

65535 divide by 1500 = 43.69

 

Therefore it will take 44 Ethernet frames to carry one maximum-sized IP packet across a data link.  Now, does this mean that IP packets are constantly being fragmented?  Not at all !!  Most applications send small chunks of data, that is below the maximum frame size.

 

The term "Frames" Defined

The term frames is most often used to describe Ethernet Layer 2 data units, or Token Ring Layer 2, or Frame Relay Layer 2, or T-carrier Layer 1 data units.  Typically layer 1 frames are delivered using the T-carrier system, and layer 2 frames are delivered using the Ethernet or Token Ring protocol..

  

Frames are sometimes loosely referred to as Packets, but the term "packets" should only be be used to describe layer 3 IP data units.  The OSI model is used to define self-contained units of binary information at seven different layers - and the protocols that allow communication between the layers.  Some people call all of these self-contained blocks of information  "packets" - no matter what level they are on.  But officially, a packet is at Layer 3, and a frame is at Layer 2 or Layer 1.  Just realize that in everyday conversation, it is easier to talk about the data units at all Layers as packets, and this is usually acceptable.  For this website, however, we will always refer to Layer 2 units as Frames, and Layer 3 units as Packets. 

 

Ethernet II (DIX),  IEEE 802.3 (LLC), and SNAP Frames

Ethernet II is the predominant type.  SNAP and LLC are rarely used, particularly not in a TCP/IP context. (They are used for things like AppleTalk, and NetBIOS/NetBEUI, but these are minor players today, relative to TCP/IP.)

Note: in the the three frame types below - the Data field min and max values vary, to adjust for the variance in the header sizes.  This causes all full frame size maximums and minimums to be identical (64 bytes min  -  1518 bytes max) !!

 

 

Important Notes

802.3 Raw (Novell's version of 802.3) - this Frame version is not shown above because it is rare.   Novell Netware was being implemented before the standards were set, and ended up using 803.3 WITHOUT 802.2 LLC.  Hence the term, Raw.  This raw mode was the default for Netware out of the box until Netware 4.X.   Current versions of Netware can be configured to use Ethernet II, 802.3/raw, 802.3/802.2 or 802.3/802.2/SNAP, with 802.3/802.2 the default.

 

The 802.2 LLC Control byte - this is sometines called "U", for Un-numbered control field command/response.

 

Difference between Ethernet II and 802.3  -  Ethernet II is the only frame that has a "Type" field (bytes 13-14), which lists a number that identifies the protocol of the Data contained in the frame.  Here are a few Ethernet II Type field values:

 

        0x0600 XNS (Xerox)
        0x0800 IP (the Internet protocol)
        0x0806 ARP
        0x6003 DECNET

 

IEEE 802.3 decided to include the Type of both source and destination in the 802.2 LLC header.  So they replaced the Type field (bytes 13-14) with a Length field.  The length" is not the full frame size - rather, it is the 802.2 packet length - the number of bytes of the 802.2 (LLC and data) portion of the frame, excluding padding.

 

OK - then how does the Receiver determine the Length of Ethernet II frames (since they have no "Length" field) - even with 802.3, which has a length field - oddly, the length field has never been used to determine the length of the frame !! In Ethernet, a frame is over when the carrier drops.  The packet driver simply counts bytes as they come in.  When they stop, that is the end of the frame, and the current byte count is the total frame length.

 

How does the Network know if the Frames are Ethernet II or 802.3 ??  By the value of that 2-byte field (bytes 13 and 14).  When the IEEE came up with the 802.3 frame, there were only a few Ethernet II protocol Type numbers below 0x600.  They were retired and assigned new numbers above 0x600.  Therefore . . .

• packet with bytes 13-14 less than 0x600 are IEEE 802.3
• packets with bytes 13-14 equal or greater than 0x600 are Ethernet II.

How does the Network identify 802.3 Raw frames??  (802.3 Raw is very rare these days) First, the value of bytes 13-14 are inspected to identify that the frame is 802.3.  Then bytes 15-16 are inspected to see if the frame is standard 802.3 or RAW 802.3.  Novell does not use LLC, but it's "raw 802.3" framing uses "FFFF" for what normally would be the 802.2 LLC DSAP and SSAP fields.   In otherwords, if bytes 15-16 are all 1's, then the frame is Novel 802.3 Raw and has no LLC.  If they are anything other than all 1's then the frame is standard 802.3 and the fields are DSAP and SSAP.  Unfortunately, Novell had to insert FFFF for those bytes to identify the frame as Raw to the networking world - but prior to that, those fields had been used by IPX as a checksum.  So, all 802.3 Raw frames have checksum disabled !!!  For this reason, modern Novel networks do not use 802.3 Raw.

 

How does the Network identify SNAP frames ??  First, the value of bytes 13-14 are inspected to identify that the frame is 802.3.  Then bytes 15-17 are inspected to see if the frame is standard 802.3 LLC or 802.3 SNAP.  SNAP has the LLC field, but does not use it - other than to identify the frame as SNAP !!  It's framing uses "AAAA03" for what normally would be the 802.2 LLC DSAP, SSAP, and Control fields.   In otherwords, if bytes 15-17 are AAAA03, then the frame is 802.3 SNAP.

length" is the length of the 802.2 (LLC and data) portion of the frame, excluding padding. The 802.2 LLC starts with the DSAP field. "DSAP" is the destination service access point. "SSAP" is the source service access point. "U" is unnumbered control field command/response.

 

SNAP

SNAP is an extension to the LLC header, so that all protocols can be identified.  With Ethernet II, the Type field is 2 bytes.  But with 802.3, they moved the Type field into the LLC header, and they made a big mistake - they only alloted one byte to each SAP field !!  

The value of the one-byte LLC SAP fields (DSAP & SSAP) are limited to between 1 and 255, since it is a 8 bit field. But there are many more protocols than 255 !!!  For example, IP and ARP use registered protocol numbers above 1500 !!   Ethernet II and it's 2-byte Type field has no problem with these numbers.  But for 802.3 they had to extend the LLC by adding a SNAP header.

 

One SAP value (the "SNAP" SAP, AA AA hex or 170 170 decimal) was reserved to denote that this is a SNAP (Sub-Network Access Protocol) frame.  In a SNAP frame, both the SAP values will be 0xAA and the first 5 bytes of the data will give the protocol ID. Well, some show the 5 bytes as a separate field, and others show it as part of the data field.  It is easier to understand if it is shown as a separate field.  Out of the 5 bytes of data, the last 2 bytes are same as the protocol type field of the Ethernet II frame. The first 3 bytes are called as 'Organizationally Unique Identifer' (OUI) and are allocated as a vendor identifier. Typically, OUI will be zero.

 

Assembling a Frame

The sending station assembles PDU's (Protocol Data Units), which are binary units of info, one layer at a time, moving downward from Layer 7 to Layer 2 - to be placed on the cable for transmission by Layer 1.  Each successive, lower layer, adds it's own "header" (additional info) to the PDU that has been passed down to it by the layer above.  Layer 2 PDU's are called frames, and they are placed on the cable by Layer1, one bit at a time.  

 

NOTE:  Layer 1 does not add any headers, and therefore does not change the Frame size.  However, it does add a 9.6 usec IFG, Inter-Frame gap (9.6 usec at 10 Mbps = 12 bytes worth of silence followed by an 8-byte Preamble, which includes 2 bits called SOF (Start of Frame), which notify the receiving station that the frame is about to begin coming in.  Layer 1's only function is to convert the frames to a serial stream of bits for transmission (and reception).  

 

The receiving station reverses the process.  It receives the frame from the cable, and dis-assembles it, one layer at a time, moving upward from Layer 1 to Layer 7 - to be placed on the cable for transmission.  Each successive lower layer adds it's own "header" (additional info) to the unit that has been passed down to it by the layer above.  Therefore, the "data" portion keeps growing - and by the time you get down to the Ethernet layer 2 - the "data" portion contains numerous headers from the layers above, but as far as Layer 2 is concerned, it is only a unit of data !!!

 

NOTE:  the Data portion of the Layer 2 Frame, contains headers from the layers above.  But frames do not necessarily contain headers for all layers above.  For example, a packet could begin it's assembly at the Transport Layer (layer 4) and work it's way down from there.  Most control packets such as ACK, routing protocol info, etc, are created beginning at layers lower than the top Layer 7 (below the Application Layer).

 

 

 

Ethernet Frames as compared to the Layered Models

Layer 2 with Ethernet is actually divided into two sublayers . . . the LLC and the MAC.  However, the LLC (Logical Link Control), as it's name implies, is just a logical sub-layer and does not add any physical data.  The MAC (Media Access Control) sub-layer does add a header and optionally, a CRC trailer.  The competed frame is shown below - next to the two most popular protocol standards . . . the OSI model, and the TCP/IP model:

NOTE: this is an Ethernet II Frame (DIX) - if it were an 802.3 Frame, the Type field would be replaced by Length and LLC  fields.

 

 

Pre-Frame Components  -  IFG Inter-Frame Gap, Preamble, and SOF 

When dealing with frame byte counts, and frame diagrams, etc. - the standard is to leave out these "pre-frame" occurences.

Although it is true that all Ethernet frames are preceded by a small idle period (the minimum inter-frame gap, 9.6 microsecond (µS)) and a 8 byte "preamble + SOF"  .  .  .  they are not considered part of the frame, as the following diagram shows:

 

<^--- 

Ethernet II Frame

IFG (Inter Frame Gap)

Between transmission of each frame, a transmitter must wait for a period of 9.6 microseconds for Fast Ethernet and .096 usec for Gigabit Ethernet.  At 10 Mbps this corresponds to about the time it takes for 12 bytes to be transmitted.  The IFG will allow the signal time to propagate through the receiver electronics at the destination. While every transmitter must wait for this time between sending frames, receivers do not necessarily see a "silent" period of 9.6 microseconds. The way in which repeaters operate is such that they may reduce the IFG between the frames which they regenerate.

 

Preamble and SOF (Start Of Frame)

The purpose of the preamble is to allow time before transmission starts is to allow a small time interval for the receiver electronics in each of the nodes to settle after completion of the previous frame. The purpose of the SOF is to notify the receiving station that the frame bits are going to come in next.  There are two ways of defining the Preamble and SOF depending on the source:

1)  the preamble is 8 bytes and includes the SOF, which is the last 2 bits of the preamble, "11" :

 

 

2)  the preamble is 7 bytes and the SOF is 1 byte (10101011):

 

In any case, combined they are a total of 64 bits, or 8 bytes.  The frame does not officially begin until just after the SOF.  Therefore the preamble and SOF are not part of the frame !!!

 

When encoded using Manchester encoding, at 10 Mbps, the 62 alternating bits produce a 5 MHz square wave.  The purpose of the preamble is to allow time for the receiver in each node to achieve lock of the receiver Digital Phase Lock Loop which is used to synchronise the receive data clock to the transmit data clock. At the point when the first bit of the preamble is received, each receiver may be in an arbitrary state (i.e. have an arbitrary phase for its local clock). During the course of the preamble it learns the correct phase, but in so doing it may miss (or gain) a number of bits. A special pattern (11), is therefore used to mark the last two bits of the preamble. When this is received, the Ethernet receive interface starts collecting the bits into bytes for processing by the MAC layer.

 

Legal Ethernet Frames

Minimum and Maximum Frame Size

As shown in the Frame types diagram at the top - the full frame min=64 bytes, and the max = 1518 bytes.  The headers sizes vary, so in order to come up with the same full frame min and max values for all frame types - the min/max Data values change accordingly :

 

Frame Type	Header & CRC	Data Min	Data Max
Ethernet II (DIX)	18	46	1500
802.3 (IEEE)	21	43	1497
SNAP	26	38	1492

In all three cases:  
Full Frame Min Size = Header+CRC+DataMin = 64
Full Frame Max Size = Header_CRC+DataMax = 1518

 

NOTE - when calculating Frame size - do not include the IFG (Inter-Frame Gap), 7-byte Preamble, or 1-byte SOF ( Start of Frame) in your frame size calculations - they are not considered part of the Ethernet frame !!!

 

Reasons for the 1500 byte Limit (Ethernet II)

The 1500 byte payload limit was somewhat arbitrary. *Some* upper limit
is needed for a number of reasons:

• The longer the maximum frame allowed, the longer the maximum delay on a shared medium. All stations must wait for a frame-in-progress to
  complete before attempting their own transmission; longer frames means longer wait time.
• Longer frames increases the probability that one or more bits in the frame will be received in error, necessitating retransmission of the
  frame. (In the extreme case, an infinitely-long frame is *guaranteed* to contain bit errors, ensuring that it would *never* be correctly
  received!)
• A longer maximum frame increases the memory requirement for a NIC using a simple, fixed buffer design. This is the *real* reason for the 1500
  byte limit; at the time we designed it (1979), buffer memory was much more expensive than it is now, and DMA controllers were too complex to
  be implemented in anything less than a full-custom chip.

Header

The header consists of three parts:

• A 6-byte destination address, which specifies either a single recipient node (unicast mode), a group of recipient nodes (multicast mode), or the set of all recipient nodes (broadcast mode).
• A 6-byte source address, which is set to the sender's globally unique node address. This may be used by the network layer protocol to identify the sender, but usually other mechanisms are used (e.g. arp). Its main function is to allow address learning which may be used to configure the filter tables in a bridge.
• A 2-byte type field (Ethernet II, DIX frames)  OR  a 2-byte Length and 3-byte LLC Field (IEEE 802.3 frames).  With Ethernet II, the type field provides a Service Access Point (SAP) to identify the type of protocol being carried (e.g. the values 0x0800 is used to identify the IP network protocol, other values are used to indicate other network layer protocols).  With 802.3, the LLC 802.2 header is included, which contains the DSAP and SSAP.

CRC (Cyclic Redundancy Check)

The 32-bit (4-byte) CRC field is added at the end of the frame (trailer) and provides error detection in the case where line errors (or transmission collisions in Ethernet) result in corruption of the MAC frame. Any frame with an invalid CRC is discarded by the MAC receiver without further processing. The MAC protocol does not provide any indication that a frame has been discarded due to an invalid CRC.

 

Illegal Ethernet Frames

All illegal frames are dropped by the receiving station.  It is up to higher layer protocols, such as TCP/IP, to notify the sending station that the frame was dropped !!  They do this by numbering frames - any frame in the sequence that is dropped is identified by comparing the sequence numbers, and notifying the sender which frame was dropped so that he can re-transmit.

 

Runt Frame
Any frame which is received and which is less than 64 bytes (18 bytes Header/CRC and 46 bytes data) is illegal, and is called a "runt". In most cases, such frames arise from a collision, and while they indicate an illegal reception, they may be observed on correctly functioning networks. A receiver must discard all runt frames.

 

Padding to prevent Runts - if the network layer wishes to send less than 46 bytes of data, the MAC protocol adds a sufficient number of zero bytes (0x00, is also known as null padding characters) to satisfy this requirement.

 

Giant Frame
Any frame which is received and which is greater than the maximum frame size, and is called a "giant". In theory, the jabber control circuit in the transceiver should prevent any node from generating such a frame, but certain failures in the physical layer may also give rise to over-sized Ethernet frames. Like runts, giants are discarded by the Ethernet receiver.

 

Misaligned Frame
Any frame which does not contain an integral number of received octets (bytes) is also illegal. A receiver has no way of knowing which bits are legal, and how to compute the CRC-32 of the frame. Such frames are therefore also discarded by the Ethernet receiver.

 

Transmitting the Frame (byte order and bit order)

Ethernet transmission is strange, in that the byte order is big-endian (leftmost byte is sent first), but bit order little-endian (rigthmost, or LSB (Least Significant Bit) of the byte is sent first).  For example, if you are sending a frame:

 

<^--- 

We assume the preamble has been sent, then the next to be sent is the destination MAC address - 6 bytes, but for this example we will show the first 4 bytes:

 

     11100001    00001111    10101010    10010011   
         Byte1            Byte2          Byte3            Byte4

 

The data normally moves to the left, using traditional images of frames.  This is true for each of the 4 bytes - they will be transmitted in big-endian, meaning "left byte first".  But we must reverse the bits in each byte, to show the actual serial stream of bits moving to the left.  So the actual bits being transmitted to the left, are as follows with the bits in each byte reversed:

 

<   10000111    11110000    01010101    11001001
         Byte1            Byte2          Byte3            Byte4
      (reversed)     (reversed)   (reversed)      (reversed)

 

NOTE:  Ethernet does not group bytes.  It has no idea that it is sending a 6-byte address, or a 2-byte Type, etc.  It simply sends the entire frame, one byte at a time, from left to right, with each byte being sent LSB first and MSB last.

 

 

 

참조 : http://www.infocellar.com/networks/ethernet/frame.htm