netviz

802.3 · LAN

La trama Ethernet dónde empieza y dónde termina

Todo el mundo sabe los números 64 y 1518. Casi nadie sabe decir desde dónde hasta dónde se cuentan — y de eso va toda la lámina. Arrastra el payload y mira moverse tres totales distintos: la trama, el packet y lo que el cable gasta de verdad.

Póster del diagrama de secuencia del handshake de 4 vías WPA2

Solicitando la escena al servicio de contenido…

64–1518
dirección destino → FCS, inclusive
84 B
lo que una trama mínima le cuesta al cable
1536
el umbral de Length/Type, no 1500
trama contra packet (802.3as)el slot time como suelo de 64 bytesla zona muerta de 35 valores802.1Q: +4 bytes, techo 1522

Qué vas a aprender

  • Dónde empieza y dónde acaba la trama de verdad: la cláusula 3.1 de IEEE 802.3 mide desde el campo de dirección de destino hasta la secuencia de verificación, inclusive — el preámbulo y el SFD quedan fuera.
  • Por qué el propio estándar renombró las cosas: 802.3as llamó packet al conjunto de preámbulo + SFD + trama, y por eso el hueco entre tramas pasó a ser el Inter-Packet Gap.
  • Por qué una trama de 64 bytes cuesta 84 bytes de cable, y por qué ése es el techo del rendimiento con paquete pequeño.
  • De dónde sale el mínimo de 64 bytes: es el slot time expresado en octetos — un parámetro de half duplex — para que un emisor no pueda terminar de transmitir antes de que le llegue la evidencia de una colisión. El full duplex quitó el mecanismo y dejó el suelo.
  • Que el umbral de Length/Type es 1536, no 1500 — y que entre 1501 y 1535 hay un hueco real de treinta y cinco valores que no son ni longitud ni tipo.
  • Qué mueve y qué no mueve la etiqueta 802.1Q: el techo se va a 1522 y el suelo se queda en 64 — y la etiqueta no es lo único que mueve un techo, porque 802.3as añadió un tercero, la envelope frame de 2000 bytes.
  • Qué cubre el FCS: destino, origen, la etiqueta 802.1Q cuando la hay, length/type, datos y pad — pero nunca el preámbulo, el SFD ni a sí mismo.

La frontera que nadie dibuja

Pregunta dónde empieza una trama Ethernet y casi todas las respuestas arrancan en el preámbulo. El estándar dice lo contrario, y lo dice en una sola frase. IEEE 802.3, cláusula 3.1: «The minimum and maximum frame size limits in 4.4 refer to that portion of the frame from the destination address field through the frame check sequence field, inclusive.» Los siete bytes de preámbulo y el byte del delimitador de inicio de trama van por delante de ese tramo, y el hueco de doce bytes va detrás. Ninguno cuenta en el 64 ni en el 1518.

El estándar acabó admitiendo que la confusión era suya. 802.3as le puso nombre al conjunto mayor — preámbulo más SFD más trama es un packet — y el interframe gap pasó a inter-packet gap para acompañarlo. Así que hay dos totales legítimos con dos nombres legítimos, y un tercero aún mayor si además cuentas el silencio que el cable tiene que dejar después. Cuando dos personas discuten sobre el tamaño de una trama Ethernet, normalmente cada una está midiendo uno distinto de los tres.

De dónde sale el 64, y lo que cuesta

El mínimo de 64 bytes no es una propiedad del dato. Es el slot time expresado en octetos — y el slot time es un parámetro de half duplex, que el estándar no iguala a nada: exige que sea mayor que la suma del tiempo de propagación de ida y vuelta de la capa física y el tiempo máximo de jam. Una trama más corta que ese suelo terminaría de transmitirse antes de que la evidencia de una colisión pudiera volver, y el emisor no se enteraría de haber colisionado. Por eso una tarjeta que sólo tiene unos pocos bytes que mandar rellena la trama con paja hasta llegar a 64. Y el relleno no es opcional: la MAC tiene que rellenar, por una regla fija, después de los datos del cliente y antes de calcular el FCS — por eso el FCS cubre el pad, y por eso lo único que queda sin especificar es su contenido.

La consecuencia es una aritmética que debería llevar encima cualquiera que dimensione un enlace. Una trama mínima ocupa 84 bytes del medio: ocho por delante, sesenta y cuatro de trama, doce de hueco. Si presupuestas 64, el cable gasta un 31 % más de lo que dice tu cálculo, y ése es el techo real del rendimiento con paquete pequeño. En el otro extremo de la regla, los dieciocho bytes de cabecera y FCS se apoyan en 1500 de payload y cuestan un 1,2 % — por eso las transferencias grandes se acercan a la tasa de línea y las tormentas de tramas diminutas no. La velocidad no movió el suelo: a 1 Gb/s el slot time subió a 4096 tiempos de bit y los emisores en half duplex rellenan la diferencia con carrier extension fuera del FCS, y a 10 Gb/s no hay slot time en absoluto porque no hay half duplex — ya no queda mecanismo de colisión que justifique el suelo, y el suelo sigue siendo 64.

El umbral es 1536, y hay un agujero

Los dos bytes que van detrás de las direcciones significan una de dos cosas mutuamente excluyentes: una longitud o un tipo. La línea divisoria no está donde la ponen casi todos los diagramas. En 1500 (0x05DC) y por debajo el campo es una longitud; en 1536 (0x0600) y por encima es un tipo. Entre medias, de 0x05DD a 0x05FF, hay un hueco de treinta y cinco valores al que no llega ninguna de las dos lecturas. El estándar no los declara «no asignados»: fija los dos límites y deja fuera de alcance lo que cae en medio. Es un agujero real, no un redondeo del dibujo.

De qué lado de la línea caiga una trama tiene un coste práctico. Una longitud significa que la trama lleva LLC, y LLC/SNAP antepone ocho bytes más de cabecera, dejando 1492 bytes para tu dato en vez de 1500. Hoy manda la lectura de tipo: RFC 1122 §2.3.3 obliga a soportar RFC 894 y dice que una implementación de ambas debe usar RFC-894 por defecto. La lámina dibuja el umbral como una ventana de 1480 a 1560, porque a escala completa el hueco de treinta y cinco valores mediría medio píxel.

Índice del atlas