Почему размер MTU для кадров Ethernet рассчитан как 1500 байт?

Существуют ли какие-либо конкретные расчеты, которые были сделаны для получения этого числа, и какие факторы были приняты во внимание для этого расчета.

Ответ на этот вопрос в черновиках IETF-ISIS-Ext-Eth-01 , разделы 3-5. Ethernet использует одни и те же два байта разными способами в инкапсуляциях Ethernet II (DIX) и 802.3:

• Ethernet II использует первые два байта после Mac-адреса источника Ethernet для типа
• 802.3 использует те же два байта для поля длины .

Ниже приведена аннотированная диаграмма для каждого типа фрейма, которая показывает, где именно конфликтующие байты находятся в заголовке ethernet:

• RFC 894 (обычно известный как кадры Ethernet II) использует эти байты для типа

     +----+----+------+------+-----+
     | 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 с 802.2 LLC / SNAP (используется Spanning-Tree, ISIS) использует эти байты для длины

     +----+----+------+------+-----+
     | 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)
  

Инкапсуляции Ethernet II и 802.3 должны существовать на одном и том же канале. Если бы IEEE разрешал полезную нагрузку Ethernet превышать 1536 байт (0x600 шестнадцатеричное), то было бы невозможно отличить большие кадры LLC или SNAP 802.3 от кадров Ethernet II; Типовые значения ethernet начинаются с 0x600 hex.

РЕДАКТИРОВАТЬ:

Я включаю ссылку на PDF-копии спецификации Ethernet версии 1 и Ethernet версии 2 на случай, если кому-то будет интересно ...

На другом конце диапазона - 1500 байт были два фактора, которые привели к введению этого предела. Во-первых, если пакеты слишком длинные, они создают дополнительные задержки для другого трафика с помощью кабеля Ethernet. Другим фактором было устройство безопасности, встроенное в ранние совместно используемые кабельные трансиверы. Это защитное устройство было противоболевой системой.Если устройство, подключенное к приемопередатчику, обнаружит неисправность и начнет непрерывную передачу, тогда оно будет эффективно блокировать любой другой трафик от использования этого сегмента кабеля Ethernet. Чтобы предотвратить это, ранние приемопередатчики были спроектированы так, чтобы автоматически отключаться, если передача превысила примерно 1,25 миллисекунды. Это соответствует содержанию данных чуть более 1500 байтов. Однако, поскольку приемопередатчик использовал простой аналоговый таймер для отключения передачи, если было обнаружено жужжание, тогда предел 1500 был выбран в качестве безопасного приближения к максимальному размеру данных, который не вызвал бы срабатывание защитного устройства.

Источник: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

Когда Ethernet изначально разрабатывался как общая среда или шина с 10Base5 и 10Base2, коллизии кадров были частыми и ожидаемыми как часть проекта. Сравните это с сегодняшним днем, когда большинство всего переключается с отдельными доменами коллизий и работает в дуплексном режиме, где никто не ожидает увидеть коллизии.

Механизм совместного использования «эфира», используемый CMSA / CD (обнаружение множественного доступа / обнаружения столкновений с несущей)

Carrier Sense означало, что станция, желающая передавать, должна прослушивать телеграмму - распознавать сигнал несущей - чтобы гарантировать, что никто не говорил, так как это был множественный доступ на этой среде. 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. Чем больше байтов передается в кадре, тем дольше все другие станции должны ждать, пока эта передача завершится. Другими словами, более короткие пакеты или меньший MTU означали, что другие станции получили больше возможностей для передачи и более справедливую долю. Чем медленнее скорость среды передачи (10 Мбит / с), тем больше задержка передачи для станций при увеличении MTU (если разрешено превышать 1500).

Интересным следствием будет вопрос, почему минимальный размер кадра составляет 64 байта? Кадры передавались в «слотах», которые составляют 512 бит и занимали 51,2 мкс для распространения сигнала в обоих направлениях в среде. Станция должна не только слушать, когда начинать разговор, считывая IFG (межкадровый интервал 96 бит), но и прослушивать столкновения с другими кадрами. Обнаружение столкновений предполагает максимальную задержку распространения и удваивает ее (для безопасности), чтобы не пропустить передачу, начинающуюся примерно в то же время с другого конца провода, или отражение сигнала собственной передачи, когда кто-то забыл согласующий резистор на концы кабеля. Станция не должна завершать отправку своих данных до обнаружения коллизии, поэтому ожидание 512 бит или 64 байта гарантирует это.

Первоначально макс. Полезная нагрузка была определена как 1500 байт в 802.3. Ethernet v2 поддерживает длину кадра> = 1536, и это то, что используют реализации IP. Большинство поставщиков операторского класса в наши дни поддерживают около 9000 байт («гигантских кадров»). Поскольку 1500 байт является стандартом, который должны поддерживаться всеми реализациями Ethernet, это то, что обычно устанавливается по умолчанию на всех интерфейсах.

Минимальный кадр Ethernet основан на времени слота Ethernet, которое составляет 512 битов (64 байта) для 10M Ethernet. Вычитая 18 байтов для заголовка Ethernet и CRC, вы получаете 46 байтов полезной нагрузки.

Время слота Ethernet было указано, чтобы CSMA / CD работал правильно. Необходимо убедиться, что минимальный размер кадра не превышает максимально возможную длину кабеля; если бы он сделал детерминистическое обнаружение столкновения было бы невозможно. После обнаружения столкновения на максимальной длине кабеля вам потребуется сигнал обнаружения столкновения, чтобы вернуться к отправителю.