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


38

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


2
Люди IEEE сопротивляются добавлению 9k к стандарту, потому что математические гарантии, которые FCS приносит сегодня при 1.5k, не будут верны больше при 9k.
2011 г.

5
@ytti, это только один из аргументов против одобрения> 1500 кадров. Полный текст письма Джеффа Томсона (содержащий возражения IEEE по стандартизации гигантских фреймов) приведен в черновом варианте приложения IETF-ISIS-Ext-Eth-01 . Возражения начинаются со слова «Рассмотрение»
Майк Пеннингтон

Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:


27

Ответ на этот вопрос в черновиках 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 на случай, если кому-то будет интересно ...



2
Ну, у фреймов Ethernet II поле типа начинается с 0x0600 (из спецификации IEEE 802.3x-1997), потому что максимальная максимальная длина 802.3 была чуть ниже. Так что это просто следствие, а не причина.
Nos

1
@ nos, чтобы утверждать, что это является следствием, а не причиной, предполагается, что вы можете доказать причину ... можете ли вы предоставить достоверные доказательства для предложенной вами причины? Первоначальная спецификация Ethernet версии 1, опубликованная в 1980 году, уже использует поле Тип, а в 1984 году протокол IP был указан с использованием Ethertype 0x0800
Майк Пеннингтон,

2
Действительно, спецификации Ethernet I и II уже имели поле типа (которое в то время не имело ограничений) и уже указывали максимальную длину данных 1500 - в то время не было кадров 802.3. Поэтому нельзя сделать вывод, что предел 1500 был добавлен в более поздней спецификации из-за поля типа.

2
@ nos Я не согласен, Ethernet II должен был сосуществовать с существовавшим ранее стандартом. Кроме того, он определил использование одного и того же поля в качестве поля типа в предыдущем стандарте и поля длины в новом стандарте. Учитывая, что НЕ ДОЛЖНО быть никакой путаницы между двумя стандартами, которые должны сосуществовать в одной сети, любая длина, которая может выглядеть как существующий тип, не будет разрешена. Поскольку существующий список типов начинался 0x600с номера, меньшего, чем тот, который должен был быть выбран. Чтобы не допустить дальнейшего расширения к стандарту, должна быть доступная полоса, если она потребуется.

14

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

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


5
Привет, @ user1171: Предпочтительный стиль StackExchange - включить сюда материал для ответов и ссылку в качестве ссылки. Таким образом, когда ссылка в конечном итоге гниет, ответ все еще полезен.
Крейг Константин

Функция jabber требовала, чтобы MAU отключался через 20–150 мс для скорости 10 Мбит / с (IEEE 802.3, пункт 8.2.1.5), от 40 до 75 кбит для Fast Ethernet (пункт 27.3.2.1.4) и в два раза больше, чем для Gigabit Ethernet, намного превышающий длину кадра. Сообщение Yahoo неверно.
Zac67

10

Когда 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 байта гарантирует это.


2

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


Вы должны Google MaxValidFrame, это было определено IEEE; следовательно, распространенные на сегодняшний день реализации 9-килобайтных фреймов jumbo не официально совместимы с Ethernet, но они достаточно хорошо работают для полезных нагрузок Ethernet II
Майк Пеннингтон,

Строго говоря, не соответствует стандарту 802.3. IP использует Ethernet v2, поэтому я даже не думаю о 802.3 ...

5
Jumbos не совместимы с Ethernet II или 802.3 после ратификации 802.3x. В п. 4.2.3.1 стандарта 802.3x определяется maxValidFrame для полезных нагрузок 1500B. Таким образом, после 1997 года любая полезная нагрузка, превышающая 1500 байт, не соответствует требованиям. См. Письмо, которое председатель IEEE 802.3 направил в IETF по этому вопросу . Короче говоря, 802.3 - это гораздо больше, чем стандарт кадров ... он определяет как требования к кадрам, так и требования к оборудованию. Это означает, что аппаратные реализации зависят от соответствия формату кадра. Для полудуплекса с CSMA-CD требуется <= 1500B полезной нагрузки.
Майк Пеннингтон

-1

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

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


3
У меня возникают проблемы с пониманием того, как механизм определения минимального размера кадра Ethernet имеет какое-либо отношение к текущему максимальному стандарту defacto на 1500 байт. Пожалуйста, дополните!
Стугги

2
@ Stuggi Это не так.
Кен Шарп
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.