O frame Ethernet campo a campo: do preâmbulo ao FCS, a tag 802.1Q e os tamanhos que importam

Todo frame Ethernet segue a mesma sequência curta de campos: um preâmbulo que prepara o receptor, dois endereços, um campo que indica um tamanho ou um tipo, o payload e um checksum. O que cada campo leva, por que o mínimo é de 64 octetos e o máximo de 1518, onde fica a tag 802.1Q e o que ela carrega, e por que os jumbo frames não fazem parte do padrão.

Quase tudo o que acontece numa rede local viaja em frames , os quadros, e todo frame tem o mesmo formato. Quem aprende esse formato uma vez passa a entender sem esforço uma captura de pacotes, os contadores de erro de um switch e um problema de (maximum transmission unit, a unidade máxima de transmissão): cada um deles diz alguma coisa sobre um dos poucos campos do frame.

Os campos, na ordem em que passam pelo fio

A apresentação do próprio grupo de trabalho IEEE 802.3 mostra o frame como uma sequência curta de campos (Law, IEEE 802.3, 2011):

Campo	Octetos	Para que serve
Preâmbulo	7	Uns e zeros alternados, para o receptor se sincronizar com o sinal
Start frame delimiter (SFD)	1	Marca onde começa o frame propriamente dito
Endereço de destino	6	Para quem é o frame
Endereço de origem	6	Quem enviou o frame
Tag 802.1Q (opcional)	4	A (virtual ) e a prioridade, quando a tag existe
Length/Type	2	O tamanho do payload (a carga útil) ou o protocolo que vai dentro dele
Payload (MAC client data)	46 a 1500	O pacote transportado, com padding se for curto
Frame check sequence ()	4	Um checksum calculado sobre o frame

A documentação da Juniper traz os mesmos tamanhos, campo por campo: um preâmbulo de "7 octets of alternating 0s and 1s", "a 1-octet start-of-frame delimiter", dois endereços de 6 octetos, um campo length/type de 2 octetos e um campo de 4 octetos "that contains the calculated CRC value" (Juniper). Os tamanhos de frame que todo mundo cita (64, 1518, 1522) contam do endereço de destino até o FCS, como mostra a conta: 6 + 6 + 2 + 46 + 4 = 64, e 6 + 6 + 2 + 1500 + 4 = 1518. O preâmbulo e o SFD ficam fora dessa conta.

O preâmbulo e o SFD

O preâmbulo existe para ajudar quem recebe, não quem envia: uma sequência de bits alternados dá ao circuito de recepção um sinal regular para ele se sincronizar antes que chegue qualquer informação. O SFD é mais um octeto, com um padrão que quebra esse ritmo; o guia de troubleshooting da Cisco observa que ele "ends with 2 consecutive 1 bits" (Cisco, Troubleshooting Ethernet). Tudo o que vem depois desses dois bits ligados é o frame.

Dois endereços e os dois bits que mais importam

Cada endereço é um endereço MAC (media access control) de 48 bits. As diretrizes da Registration Authority descrevem a estrutura: os três primeiros octetos de um endereço administrado universalmente formam o (organizationally unique identifier), um bloco de 24 bits atribuído a uma organização, normalmente o fabricante; e dois bits do primeiro octeto mudam o significado do endereço inteiro (diretrizes da IEEE RA):

o bit menos significativo do primeiro octeto é o bit I/G (individual/group): 0 para uma única estação, 1 para um grupo (multicast ou broadcast);
o bit seguinte é o bit U/L (universal/local): 0 para um endereço atribuído dentro de um bloco do IEEE, 1 para um endereço atribuído localmente.

O endereço com todos os bits ligados, FF-FF-FF-FF-FF-FF, quer dizer todas as estações da rede: é o broadcast. Como a Ethernet transmite cada octeto começando pelo bit menos significativo (RFC 9542) e o primeiro octeto do destino sai primeiro, o bit I/G é o primeiro bit do endereço a passar pelo fio: antes de qualquer outra coisa, ele diz se o frame é para uma estação ou para um grupo. A consulta de OUI deste site pega os três primeiros octetos e devolve o fabricante a quem eles foram atribuídos.

Length ou Type: um campo, dois significados

Os dois octetos que vêm depois dos endereços (ou depois da tag) servem para duas coisas diferentes, e é o valor do campo que diz qual delas vale. Valores iguais ou maiores que 0x0600 (1536) são um , que identifica o protocolo que vai no payload; valores iguais ou menores que 0x05DC (1500) indicam um tamanho; os poucos valores entre um e outro ficam indefinidos (Seifert, arquivo do IEEE 802.1, 1996; RFC 9542). Quem atribui os EtherTypes é a IEEE Registration Authority, e a (Internet Assigned Numbers Authority) mantém uma cópia pública dos que os protocolos da internet usam (IANA, IEEE 802 Numbers):

EtherType	Protocolo
0x0800	IPv4
0x0806	(Address Resolution Protocol)
0x86DD	IPv6
0x8100	Tag 802.1Q de VLAN de cliente (a C-tag)
0x88A8	Tag 802.1Q de VLAN de serviço (a S-tag do provider bridging)
0x8847	(Multiprotocol Label Switching)
0x88CC	(Link Layer Discovery Protocol)

Esse duplo significado tem origem histórica. A Ethernet que veio antes do padrão do IEEE, conhecida como Ethernet DIX por causa da Digital, da Intel e da Xerox, colocava um tipo nesse campo; o IEEE 802.3 original colocava ali um tamanho e identificava o protocolo dentro do payload com um header (cabeçalho) 802.2 LLC (logical link control) (Cisco, Troubleshooting Ethernet; RFC 9542). Para levar IP desse jeito, é preciso o LLC mais um header SNAP (subnetwork access protocol), oito octetos a mais, e é daí que vem o 1492 de algumas configurações de MTU: 1518 menos 18 octetos de header e trailer, menos 8 (RFC 1042). O IP sobre a Ethernet comum usa a forma com tipo, com 0x0800 nesse campo (RFC 894).

O payload e o tamanho mínimo

O payload é o pacote que está sendo transportado: um pacote IP, uma mensagem ARP, qualquer coisa que tenha um tipo. Ele não pode ter menos de 46 octetos. Um pacote menor é "padded" ("with octets of zero"), ou seja, completado com zeros até chegar ao mínimo, e esse padding "is not part of the IP packet and is not included in the total length field of the IP header" (RFC 894). O receptor sabe onde termina o pacote de verdade pelo campo de tamanho do próprio pacote, não pelo frame. O teto é de 1500 octetos de payload, e é por isso que 1500 é a MTU da Ethernet comum; a calculadora de MTU e MSS parte desse número.

A tag 802.1Q

Um frame que pertence a uma VLAN e passa por um trunk leva quatro octetos a mais, "between the Source Address and Type/Length fields" (Cisco, formato do frame 802.1Q):

o TPID (tag protocol identifier), 0x8100, fica exatamente onde estaria o campo Length/Type; assim, o receptor que lê essa posição sabe que vem uma tag em seguida;
três bits de PCP (priority code point), a prioridade 802.1p;
um bit de DEI (drop eligible indicator), que marca o frame como elegível para descarte quando há congestionamento. Documentos mais antigos chamam esse bit de CFI (canonical format indicator); o 802.1Q-2011 substituiu o CFI pelo DEI nas tags de cliente (Haddock, IEEE 802.1, 2013);
doze bits de VID (VLAN identifier). O VID 0 indica que a tag leva só a prioridade, e o 4095 é reservado; por isso, as VLANs que dá para usar vão de 1 a 4094 (Microsoft, tag 802.1Q; Huawei, formato do frame QinQ).

O campo Length/Type original vem logo depois da tag. Como o conteúdo do frame mudou, o switch que coloca ou tira uma tag "recomputes the FCS on the modified frame" (Cisco, como acima), e o maior frame com tag cresce quatro octetos e chega a 1522.

O campo FCS (frame check sequence)

Os quatro últimos octetos são um CRC-32, uma verificação de redundância cíclica (cyclic redundancy check) de 32 bits, que o emissor calcula sobre o endereço de destino, o endereço de origem, o length/type, os dados e o padding, mas não sobre o preâmbulo nem sobre o SFD (Intel, inserção do FCS). O receptor faz a mesma conta de novo; se o resultado não bater, pelo menos um bit mudou no caminho, e o frame é descartado. Um contador de erros de FCS que não para de subir numa porta é pista de problema na camada física (um cabo, um conector, um duplex mismatch), não de protocolo.

Os tamanhos: 64, 1518, 1522, 2000

64 octetos, no mínimo. O IEEE 802.3 chama esse valor de minFrameSize, "512 bits (64 octets)" (Frazier, IEEE 802.3z, 1996). Na Ethernet compartilhada, em half-duplex, o emissor ainda tinha de estar transmitindo quando a notícia de uma colisão vinda da outra ponta da rede pudesse chegar até ele; por isso, o frame tinha de durar pelo menos um slot time. A Cisco descreve o slot time como "based on the round-trip time that it takes to send a 64-byte frame the maximum length of an Ethernet LAN", e uma colisão percebida depois do 512º bit é uma late collision, a colisão tardia (Cisco, colisões). Esse raciocínio vale para 10 e 100 Mb/s; para o gigabit em half-duplex, o trabalho do 802.3z propôs, em vez disso, um slot time de 4096 bit times com extension (Frazier, como acima). Um frame com menos de 64 octetos é um runt.
1518 octetos, no máximo, sem tag. Seis mais seis mais dois octetos de header, 1500 de payload e quatro de FCS. Acima disso, é um giant (Cisco, Troubleshooting Ethernet).
1522 octetos, com tag. Os 1518 mais os quatro octetos da tag 802.1Q (Cisco, 802.1Q).
2000 octetos, envelope frames. O IEEE 802.3as-2006 aumentou o frame máximo para 2000 octetos no caso de frames que carregam mais encapsulamento, mas manteve o payload em 1500 (relatório do P802.3as, 2005; Daines, 2005). A própria força-tarefa avisou que "some compliant implementations may not correctly handle envelope frames larger than 1518 octets".

Os jumbo frames, com payloads bem acima de 1500 octetos, não se encaixam em nenhum desses casos. A apresentação do presidente do grupo 802.3 diz com todas as letras "Jumbo frames not supported", e a Ethernet Alliance escreveu que "there is no industry standard that defines the size of a Jumbo frame" (Law, 2011; Ethernet Alliance, 2009). Eles só funcionam onde todos os equipamentos do caminho foram configurados com o mesmo tamanho, e esse é o assunto do artigo sobre jumbo frames.

O intervalo entre frames e quanto um link consegue transportar

Um frame não encosta no outro. Depois de cada frame, o emissor fica em silêncio durante um interpacket gap mínimo (o intervalo entre frames) de 96 bit times (interpretação do IEEE 802.3), o equivalente a doze octetos, e todo frame vem precedido dos seus oito octetos de preâmbulo e SFD. O guia de da Nokia calcula o overhead por frame em cerca de "12 + 8 = 20 bytes" (Nokia).

É por causa desse overhead que um link não consegue entregar a sua taxa nominal inteira como payload, e é por isso que os frames pequenos saem mais caros. Um frame mínimo ocupa 64 + 8 + 12 = 84 tempos de octeto no fio, ou 672 bits; a 1 Gb/s, isso dá no máximo 1.000.000.000 / 672, cerca de 1,49 milhão de frames por segundo, o número por trás das promessas de "line rate" para pacotes pequenos. Com frames de 1518 octetos, a mesma conta dá 1538 tempos de octeto por frame e cerca de 81 mil frames por segundo, quase tudo payload.

Para lembrar

O frame tem preâmbulo e SFD, dois endereços, uma tag opcional, Length/Type, payload e FCS. Os tamanhos de frame que todo mundo cita começam a contar no endereço de destino.
O primeiro bit do endereço de destino diz se o frame é unicast ou de grupo; FF-FF-FF-FF-FF-FF é broadcast.
Um Length/Type de 0x0600 ou mais indica um protocolo; 0x0800 é IPv4, 0x86DD é IPv6, 0x8100 é uma tag de VLAN.
O mínimo é 64 por causa das colisões no meio compartilhado; o máximo é 1518 sem tag e 1522 com tag; jumbo frames são uma convenção, não um padrão.
Erros de FCS apontam para a camada física.

Fontes