¿Por qué se calculó el tamaño de MTU para tramas de Ethernet como 1500 bytes?


38

¿Hay algún cálculo específico que se hizo para llegar a este número, y cuáles fueron los factores que se tuvieron en cuenta para ese cálculo?


2
Las personas de IEEE se resisten a agregar 9k al estándar porque las garantías matemáticas que FCS ofrece hoy en 1.5k ya no serían ciertas en 9k.
ytti

55
@ytti, ese es solo uno de los argumentos en contra de respaldar> 1500 fotogramas. El texto completo de la carta de Geoff Thomson (que contiene las objeciones de IEEE para estandarizar los marcos jumbo) se encuentra en el borrador-ietf-isis-ext-eth-01 Apéndice 1 . Las objeciones comienzan con la palabra "Consideración"
Mike Pennington

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


27

La respuesta está en draft-ietf-isis-ext-eth-01 , Secciones 3-5. Ethernet utiliza los mismos dos bytes de formas diferentes en las encapsulaciones Ethernet II (DIX) y 802.3:

  • Ethernet II usa los primeros dos bytes después de la dirección MAC de origen de Ethernet para un Tipo
  • 802.3 usa esos mismos dos bytes para un campo Longitud .

Incluyo un diagrama anotado debajo de cada tipo de trama, que muestra exactamente dónde están los bytes en conflicto en el encabezado de Ethernet:

  • RFC 894 (comúnmente conocido como tramas Ethernet II) utiliza estos bytes para Tipo

       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^
    
       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
    
  • IEEE 802.3 con 802.2 LLC / SNAP (usado por Spanning-Tree, ISIS) usa estos bytes para Longitud

       +----+----+------+------+-----+
       | DA | SA | Len  | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^
    
       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
    

Ambas encapsulaciones Ethernet II y 802.3 deben poder existir en el mismo enlace. Si el IEEE permitiera que las cargas útiles de Ethernet superaran los 1536 bytes (0x600 hexadecimales), entonces sería imposible distinguir las tramas grandes 802.3 LLC o SNAP de las tramas Ethernet II; Los valores de tipo de ethernet comienzan en 0x600 hexadecimal.

EDITAR:

Incluyo un enlace a copias en pdf de la especificación Ethernet Versión 1 y la especificación Ethernet Versión 2 , en caso de que alguien esté interesado ...



2
Bueno, las tramas Ethernet II tienen su campo de tipo que comienza en 0x0600 (de la especificación IEEE 802.3x-1997) porque la longitud máxima máxima de 802.3 estaba justo por debajo de eso. Entonces eso es solo un efecto, no una causa.
nos

1
@nos, afirmar que este es un efecto en lugar de una causa presupone que usted puede probar la causa ... ¿puede proporcionar evidencia autorizada para su causa propuesta? La especificación original de Ethernet Versión 1 publicada en 1980 ya usa el campo Tipo, y en 1984, el protocolo IP se especificó usando Ethertype 0x0800
Mike Pennington

2
De hecho, la especificación Ethernet I y II ya tenía un campo de tipo (que en ese momento no tenía restricciones), y ya especificaba la longitud máxima de datos de 1500, en ese momento no había marcos 802.3. Por lo tanto, no se puede concluir que el límite de 1500 se agregó en una especificación posterior debido al campo de tipo.
nos

2
@nos no estoy de acuerdo, Ethernet II tuvo que coexistir con el estándar preexistente. Y también definió el uso del mismo campo para actuar como un campo de tipo en el estándar anterior y un campo de longitud en el nuevo estándar. Dado que NO DEBE haber posibilidad de confusión entre los dos estándares, que deben coexistir en la misma red, no se permitiría ninguna longitud que pudiera parecer un tipo existente. Como la lista de tipos existente comenzó en 0x600un número menor que el que tuvo que ser elegido. Para no permitir una mayor expansión al estándar, tenía que haber alguna banda disponible en caso de ser necesario.

14

En el otro extremo del rango, 1500 bytes, hubo dos factores que llevaron a la introducción de este límite. Primero, si los paquetes son demasiado largos, introducen demoras adicionales a otro tráfico usando el cable Ethernet. El otro factor fue un dispositivo de seguridad integrado en los primeros transceptores de cable compartido. Este dispositivo de seguridad era un sistema anti-balbuceo.Si el dispositivo conectado a un transceptor desarrolló una falla y comenzó a transmitir continuamente, entonces bloqueará efectivamente cualquier otro tráfico para que no use ese segmento de cable Ethernet. Para evitar que esto ocurra, los primeros transceptores se diseñaron para apagarse automáticamente si la transmisión excedía aproximadamente 1,25 milisegundos. Esto equivale a un contenido de datos de poco más de 1500 bytes. Sin embargo, como el transceptor usaba un temporizador analógico simple para apagar la transmisión si se detectaba balbuceo, entonces se seleccionó el límite de 1500 como una aproximación segura al tamaño máximo de datos que no activaría el dispositivo de seguridad.

Fuente: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1


55
Hola @ user1171: el estilo preferido de StackExchange es incluir el material de respuesta aquí y vincularlo como referencia. De esa manera, cuando el enlace finalmente se pudre, la respuesta sigue siendo útil.
Craig Constantine

La función jabber requería que la MAU se apagara después de 20 a 150 ms para 10 Mbit / s (IEEE 802.3 Cláusula 8.2.1.5), 40 a 75 kbit para Fast Ethernet (Cláusula 27.3.2.1.4) y el doble que para Gigabit Ethernet, muy por encima de la longitud del marco. La publicación de Yahoo está mal.
Zac67

10

Cuando Ethernet se desarrolló originalmente como un medio o bus compartido con 10Base5 y 10Base2, las colisiones de tramas eran frecuentes y se esperaban como parte del diseño. Compare esto con el de hoy cuando casi todo se cambia con dominios de colisión separados y se ejecuta full-duplex donde nadie espera ver colisiones.

El mecanismo para compartir el "éter" empleó CMSA / CD (Acceso múltiple de detección de portador / Detección de colisión)

Sentido del operador significaba que una estación que desea transmitir debe escuchar el cable, detectar la señal del operador, para asegurarse de que nadie más estaba hablando, ya que era un acceso múltiple en ese medio. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. Cuantos más bytes se transmiten en una trama, más tiempo deben esperar todas las demás estaciones hasta que se complete la transmisión. En otras palabras, ráfagas más cortas o MTU más pequeñas significaron que otras estaciones tuvieron más oportunidades de transmitir y una participación más justa. Cuanto más lenta sea la velocidad del medio de transmisión (10Mb / s), las estaciones tendrían demoras más largas para transmitir a medida que aumenta la MTU (si se permite que exceda 1500).

Una pregunta interesante sobre el corolario sería ¿por qué el tamaño mínimo de trama de 64 bytes? Las tramas se transmitieron en "ranuras" que son 512 bits y tomaron 51.2us para la propagación de la señal de ida y vuelta en el medio. Una estación no solo tiene que escuchar cuándo comenzar a hablar detectando el IFG (intervalo entre cuadros de 96 bits), sino también escuchar colisiones con otras tramas. La detección de colisión supone un retraso de propagación máximo y lo duplica (para estar seguro) para que no pierda una transmisión que comience aproximadamente al mismo tiempo desde el otro extremo del cable o una señal de reflejo de su propia transmisión cuando alguien olvidó la resistencia de terminación en el extremos del cable. La estación no debe completar el envío de sus datos antes de detectar una colisión, por lo que esperar 512 bits o 64 bytes lo garantiza.


2

Originalmente, máx. la carga útil se definió como 1500 bytes en 802.3. Ethernet v2 admite una longitud de trama de> = 1536 y esto es lo que usan las implementaciones de IP. La mayoría de los proveedores de clase portadora admiten alrededor de 9000 bytes ("tramas gigantes") en estos días. Dado que 1500 bytes es el estándar que todas las implementaciones de Ethernet deben admitir, esto es lo que normalmente se establece como predeterminado en todas las interfaces.


Deberías google maxValidFrame, fue definido por IEEE; en consecuencia, las implementaciones de trama jumbo de 9 KB que son comunes hoy en día no cumplen oficialmente con Ethernet, pero funcionan bastante bien para las cargas útiles de Ethernet II
Mike Pennington

Estrictamente hablando, no cumple con 802.3. IP utiliza Ethernet v2 sin embargo, por lo que tienden a no incluso piensan de 802.3 ...

55
Los Jumbos no cumplen con Ethernet II o 802.3 después de que se ratificó 802.3x. La cláusula 802.3x 4.2.7.1 define maxValidFrame en cargas útiles de 1500B. Por lo tanto, después de 1997, cualquier carga útil que exceda los 1500 bytes no es compatible. Consulte la carta que el presidente de IEEE 802.3 envió a IETF sobre este tema . En resumen, 802.3 es mucho más que un estándar de trama ... define los requisitos de estructura y hardware. Esto significa que las implementaciones de hardware dependen del cumplimiento del formato de trama. Half Duplex con CSMA-CD necesita <= 1500B de cargas útiles.
Mike Pennington

-1

La trama mínima de Ethernet se basa en el tiempo de ranura de Ethernet, que es de 512 bits de longitud (64 bytes) para 10M de Ethernet. Después de restar 18 bytes para el encabezado de ethernet y CRC, obtienes 46 bytes de carga útil.

Se especificó el tiempo de la ranura de Ethernet para que CSMA / CD funcione correctamente. Hay que asegurarse de que el tamaño mínimo del marco no exceda la longitud más larga posible del cable; si lo hiciera, la detección de colisión determinista sería imposible. Después de la detección de colisión en la longitud máxima del cable, necesita la señal de detección de colisión para regresar al remitente.


3
Tengo problemas para entender cómo el mecanismo para determinar el tamaño mínimo de trama de Ethernet tiene algo que ver con el estándar de facto máximo de 1500 bytes actual. ¡Por favor elabora!
Stuggi

2
@Stuggi No lo hace.
Ken Sharp
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.