¿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?
¿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?
Respuestas:
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:
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 ...
0x600
un 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.
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
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.
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.
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.