Why preamble is not considered a part of the Ethernet Header?

Question

1. If I search where does my data start in an Ethernet frame, I get a common answer which says TCP header( 20 bytes) + IP header ( 20 bytes) + Ethernet header( SA + DA + Type) i.e 14 bytes. So, in short the answer to that question becomes at 52-54 bytes the data starts in an Ethernet frame but shouldn't we add 8 bytes of preamble too in it ?

2. Also, I searched about ethernet frame size which is 1514 for ethernet frames. Why are we ignoring Preamble and CRC here ?

Answer 1

Adding to jonathanjo's answer:

Ethernet has components in both layers 1 (because it can run over different media) and 2 (because the frames are the same on the different media).

The Preamble, SoF Delimiter, and Inter-packet Gap are really in layer-1 (waking up the receiver, etc.), while the frame (including the header, payload, and FCS) is in layer-2.

The data in an ethernet frame is the payload of an ethernet frame. Your Question 1 assumes that every layer-3 protocol is IPv4, and every layer-4 protocol is TCP, which are bad assumptions. Ethernet doesn't know or care which layer-3 protocol it carries (IPv4, IPX, IPv6, AppleTalk, etc.), so the data of the frame is the payload. For example, the IPv4 packet header is 20 to 60 octets, while the IPv6 packet header is always 40 octets. Ethernet doesn't know this, it only knows that it has a payload field, not what is in that field.

The ethernet frame header is normally 14 octets, unless you have a tagged frame, then it is 18 octets. The MTU is the maximum payload size. Ethernet also has a minimum frame size of 64 octets, including the FCS, so the payload can range from 42 (with tag) or 46 (without tag) octets, up to the maximum payload size of 1500 octets. That means that ethernet frames (header and payload) are from 60 octets to 1514 (without tag) or 1518 (with tag) octets.

If by where the data starts, you mean application data, that is really going to depend on all the protocols. The UDP header is only 8 octets, and the UDP payload may be the application data, or it may be a datagram for an application-layer protocol that has its own header that may not be counted as application data. In your example of TCP, you may be running a web browser to a web server. Do you count HTTP (an application-layer-protocol) or HTML as the data (HTML is the data for HTTP)? When you refer to the data, it is relative to the protocol to which you are referring.

Answer 2

The preamble is actually 7 octets,followed by a framing octet, the start frame delimiter (SFD). They just mark that a frame is coming and serve synchronisation purposes, they are not part of the frame. Just like the interframe gap, doesn't count as part of the frame. Preamble and SFD never go into memory, and so there is never any memory offset which includes that 8.

Ethernet frames are sometimes described as 1514 octets because the hardware usually computes/checks the FCS, and the CPU never sees it or puts it in memory: only the src, dest, type, payload. But the frame is defined to include the FCS, unambiguously, according to the standard. The basic frame is defined as having maximum client data field length of at least 1500 octets, which plus the 14 plus 4 FCS = 1520.

PS. Don't forget optional 802.1q tag, another 4 octets for packets on trunks; and there are some other special types.

EDIT The standard mostly speaks of frames, which are defined to include the FCS (thanks Richard for comment). It also speaks of packets which go from the beginning of the preamble to the end of the extension bits (which sometimes are needed after the FCS, to ensure good collision detection.) This packet is all the bits which the hardware transmits on the wire. (This usage of "packet" can be confusing, as we normally speak of IP packets inside the ethernet frame.)

It's just a matter of definitions, in the end, and we thankfully can look them up. If you weren't aware, the standard is freely available. The core is 4,000 pages long (!), but most of the things like definitions are very easy to read, and absolutely unambiguous. Highly recommended to have at least looked at Section 3.1.1 Packet Format. http://www.ieee802.org/3/

Answer 3

In addition to the already present, good answers:

The preamble is an essential function of the physical layer. Note that when you serialize data to a single bit or symbol stream you need to provide some form of synchronization - first to bits/symbols, then to words.

The symbol pattern the preamble generates on the wire (it's really only 01010... with 10BASE-x Manchester code) allows the receiver to tune its symbol clock to the exact speed of the transmitter. It will know how many symbols it has just received even if there's no change on the wire. (All physical layers provide means for intermediate synchronization as well, so it's a continuous process.)

The SOF pattern behind the preamble marks the beginning of the first word (or octet/byte). The receiver activates its buffer and clocks the decoded bits into it, deserializing the bits coming out the decoder and transmitting it to the buffer word for word. It doesn't matter if it's a byte or a 32-bit word at a time, but it's important that the byte boundaries are correct.

So, preamble and SOF are necessarily part of the physical transport mechanism, thus belong to the physical layer. From the layer 2 perspective, a frame doesn't require a start marker - it just starts with the first octet coming in.

Answer 4

In addition to others' excellent answers about layering, some protocols sit right on top of the L2 ethernet frame, of which the best known are ARP, RARP, CDP etc, which relate directly to the link (also, as I'm reminded by Zac, other protocols such LLDP and STP's BPDUs.)

It is very uncommon, but on occasion you'll find applications which send their data in the ethernet frame, though the only reasons I've seen for this are either a) proprietary protocols designed to be obscure or purely local like license management, b) experimentation, especially real-time transfers or evaluation of protocol stack timimg. Pros and cons of this are way outside the scope of this answer!

This is output of a timing test packet with "data" starting at 0x0e.

14:54:29.698140 34:02:86:9f:f2:fc > 00:04:75:c8:28:e5, 802.3, length 64: length 50
    0x0000:  0004 75c8 28e5 3402 869f f2fc 0000 4041  ..u.(.4.......@A
    0x0010:  4243 4445 4647 4849 4a4b 4c4d 4e4f 5051  BCDEFGHIJKLMNOPQ
    0x0020:  5253 5455 5657 5859 5a5b 5c5d 5e5f 6061  RSTUVWXYZ[\]^_`a
    0x0030:  6263 6465 6667 6869 6a6b 6c6d 6e6f 7071  bcdefghijklmnopq