WikiDer > Jumbo-кадр

Jumbo frame

В компьютерная сеть, большие кадры находятся Кадры Ethernet с полезной нагрузкой более 1500 байт предел, установленный IEEE 802.3 стандарт.[1] Обычно jumbo-кадры могут нести до 9000 байтов полезной нагрузки, но существуют все меньшие и большие вариации, и следует соблюдать осторожность при использовании этого термина. Много Гигабитный Ethernet коммутаторы и Gigabit Ethernet сетевые карты может поддерживать jumbo-кадры. Немного Fast Ethernet Коммутаторы и сетевые карты Fast Ethernet также могут поддерживать jumbo-кадры.[2]

Зарождение

Каждый кадр Ethernet должен обрабатываться при прохождении через сеть. Обработка содержимого одного большого кадра предпочтительнее обработки того же содержимого, разбитого на более мелкие кадры, так как это позволяет лучше использовать доступное время ЦП за счет уменьшения количества прерываний. Это также минимизирует количество служебных байтов и уменьшает количество кадров, которые необходимо обработать.[3] Это аналогично физической отправке пакета бумаг вместо нескольких отдельных конвертов по одному листу в каждом, что позволяет сэкономить конверты и сократить время сортировки.

Первоначально большую известность кадры Jumbo получили, когда Alteon WebSystems представил их в своем ACEnic Гигабитный Ethernet переходники.[4] Многие другие производители также приняли этот размер; однако jumbo-кадры не входят в официальную IEEE 802.3 Стандарт Ethernet.

Принятие

Jumbo-кадры могут снизить накладные расходы и циклы ЦП[5] и положительно влияют на сквозную производительность TCP.[6] Наличие кадров большого размера может отрицательно сказаться на задержке в сети, особенно на каналах с низкой пропускной способностью. Размер кадра, используемый при сквозном соединении, обычно ограничивается наименьшим размером кадра в промежуточных звеньях. 802.5 Token Ring может поддерживать кадры размером 4464 байта MTU, FDDI может транспортировать 4352 байта, Банкомат 9180 байт и 802.11 может транспортировать 7935 байтовых MTU. В IEEE 802.3 Стандарт Ethernet первоначально предусматривал поддержку 1500-байтовых кадров MTU, общий размер кадра 1518 байт (1522 байта с дополнительным IEEE 802.1Q VLAN/QoS тег). Обновление IEEE 802.3as включает в себя несколько общих заголовков, трейлеров и инкапсуляций, создавая концепцию конверта, в который может быть включено до 482 байтов заголовка и трейлера, а самый большой кадр Ethernet, поддерживаемый IEEE 802.3, стал 2000 байтов.

Использование 9000 байтов в качестве предпочтительного размера полезной нагрузки для больших кадров явилось результатом обсуждений в Объединенной группе инженеров Интернет2 и сети федерального правительства США.[7] Их рекомендация была принята всеми другими национальными исследовательскими и образовательными сетями. Чтобы соответствовать этому обязательному критерию закупки, производители, в свою очередь, приняли 9000 байт в качестве обычного размера MTU с размером кадра jumbo не менее 9018/9022 байта (без / с полем IEEE 802.1Q).[нужна цитата] Большая часть оборудования Ethernet может поддерживать кадры большого размера до 9216 байт.[8]

IEEE 802.1AB-2009 и IEEE 802.3bc-2009 добавлено LLDP обнаружение в стандартный Ethernet для максимальной длины кадра (TLV подтип 4).[9] Это позволяет определять длину кадра на порту по двухоктетному полю. Согласно IEEE 802.3-2015 допустимые значения: 1518 (только базовые кадры), 1522 (Кадры с тегами 802.1Q) и 2000 (многометочные, рамки-конверты).[10]

Обнаружение ошибок

Простые аддитивные контрольные суммы, содержащиеся в UDP и TCP Транспорты оказались неэффективными при обнаружении специфичных для шины битовых ошибок, поскольку эти ошибки с простым суммированием имеют тенденцию к самоподавлению. Тестирование, которое привело к принятию RFC 3309 смоделировали внедрение ошибок по сравнению с реальными данными и продемонстрировали, что до 2% этих ошибок не обнаруживаются.

Более крупные кадры с большей вероятностью будут иметь необнаруженные ошибки с помощью простого CRC32 обнаружение ошибок, используемое в кадрах Ethernet - по мере увеличения размера пакета возрастает вероятность того, что несколько ошибок уравняют друг друга.[а]

Один из подходов IETF для принятия jumbo-кадров позволяет избежать снижения целостности данных блок служебных данных путем выполнения дополнительной CRC на следующем уровне сетевого протокола выше Ethernet. SCTP транспорт (RFC 4960) и iSCSI (RFC 7143) использовать CRC полином Кастаньоли. Многочлен Кастаньоли 0x1EDC6F41 достигает Расстояние Хэмминга HD = 6 сверх одного Ethernet MTU (до длины слова данных 16 360 бит) и HD = от 4 до 114 663 бит, что более чем в 9 раз превышает длину MTU Ethernet. Это дает два дополнительных бита способности обнаруживать ошибки в словах данных размера MTU по сравнению со стандартным полиномом CRC Ethernet, не жертвуя при этом возможностью HD = 4 для слов данных размером до 72 кбит и выше.[12] Поддержка полинома CRC Кастаньоли в транспорте общего назначения, предназначенном для обработки фрагментов данных, и в транспорте TCP, предназначенном для передачи данных SCSI, оба обеспечивают повышенную частоту обнаружения ошибок, несмотря на использование больших кадров, в которых увеличение MTU Ethernet могло бы иначе привело к значительному сокращению обнаружения ошибок.

Конфигурация

Некоторые поставщики включают заголовки в настройки размера, а другие нет, то есть максимальный размер кадра (включая заголовки кадров, максимальный размер пакета уровня 2) или максимальная единица передачи (максимальный размер пакета уровня 3, исключая заголовки кадров). Таким образом, вы можете обнаружить, что в оборудовании от разных поставщиков должны быть настроены разные значения, чтобы параметры совпадали.[нужна цитата]

Сочетание устройств, настроенных для работы с jumbo-кадрами, и устройств, не настроенных для jumbo-кадров в сети, может вызвать проблемы с производительностью сети.[13]

Эффективность полосы пропускания

Jumbo-кадры могут повысить эффективность Ethernet и сетевой обработки на хостах за счет уменьшения накладные расходы протокола, как показано в следующем примере с TCP через IPv4. В накладные расходы на обработку хостов потенциально может уменьшиться пропорционально размеру полезной нагрузки (примерно в шесть раз больше в этом примере). Насколько это важно, зависит от того, как пакеты обрабатываются на хосте. Хосты, использующие Механизм разгрузки TCP получит меньше преимуществ, чем хосты, обрабатывающие кадры с помощью своего процессора.

Эффективность полосы пропускания на уровне кадра
Тип кадраMTUНакладные расходы уровня 1Накладные расходы уровня 2Накладные расходы уровня 3Накладные расходы уровня 4Размер полезной нагрузкиВсего передано[A]Эффективность[B]
Стандарт1500преамбула
8 байт		IPG
12 байт		заголовок кадра
14 байт		FCS
4 байта		Заголовок IPv4
20 байт		Заголовок TCP
20 байт		1460 байт1538 байт94.93%
Джамбо9000преамбула
8 байт		IPG
12 байт		заголовок кадра
14 байт		FCS
4 байта		Заголовок IPv4
20 байт		Заголовок TCP
20 байт		8960 байт9038 байт99.14%
Другие размеры кадров для справки
IEEE 802.11[14][15]7935Преамбула и заголовок PLCP
24 байта		IPG
варьируется		заголовок кадра и безопасность ovhd
52 байта		FCS
4 байта		Заголовок IPv4
20 байт		Заголовок TCP
20 байт		7895 байт8015 + байт размера IPG< 98.5%
IEEE 802.11 подключен к Ethernet1500Преамбула и заголовок PLCP
24 байта		IPG
варьируется		заголовок кадра и безопасность ovhd
52 байта		FCS
4 байта		Заголовок IPv4
20 байт		Заголовок TCP
20 байт		1460 байт1580 + байт размера IPG< 92.4%
  1. ^ Общий передаваемый размер - это сумма размера полезной нагрузки и всех размеров служебных данных.
  2. ^ Эффективность рассчитывается путем деления размера полезной нагрузки на общий передаваемый размер.

Относительная масштабируемость пропускной способности сетевых данных в зависимости от скорости передачи пакетов сложным образом связана с размером полезной нагрузки на пакет.[16] Как правило, по мере увеличения скорости передачи данных в линии размер полезной нагрузки пакета должен увеличиваться прямо пропорционально для поддержания эквивалентных параметров синхронизации. Однако это подразумевает масштабирование множества промежуточных логических схем на сетевом пути для обеспечения максимального требуемого размера кадра.

Детские гигантские рамки

Малыш-гигант или же ребенок джамбо фреймы - это фреймы Ethernet, которые лишь немного больше, чем разрешено стандартами IEEE Ethernet.[2] Например, для IP /MPLS через Ethernet для предоставления услуг Ethernet со стандартной полезной нагрузкой 1500 байт. Большинство реализаций потребуют инкапсуляции пользовательских кадров, не являющихся jumbo, в формат кадра MPLS, который, в свою очередь, может быть инкапсулирован в соответствующий формат кадра Ethernet с EtherType значения 0x8847 и 0x8848.[17] Увеличенные накладные расходы на дополнительные заголовки MPLS и Ethernet означают, что требуется поддержка кадров размером до 1600 байт. Операторский Ethernet сети.[18]

Супер большие кадры

Супер большие кадры (SJF) - это кадры, у которых есть полезная нагрузка размер более 9000 байт. Поскольку это был относительно сложный и довольно длительный процесс увеличения MTU пути высокопроизводительных национальных исследовательских и образовательных сетей с 1500 байтов до 9000 байтов или около того, последующее увеличение, возможно, до 64000 байтов, находится под вопросом. Основной фактор, связанный с увеличением максимальный размер сегмента (MSS) - это увеличение размера доступного буфера памяти во всех промежуточных механизмах сохранения на пути.

Альтернативный подход

Разгрузка большой отправки и большая разгрузка приема разгрузка покадровой обработки, благодаря которой загрузка ЦП в значительной степени не зависит от размера кадра. Это подход к устранению накладных расходов на каждый пакет, для уменьшения которых были разработаны большие кадры.[19] Jumbo-кадры по-прежнему полезны с точки зрения полосы пропускания, поскольку они уменьшают объем полосы пропускания, используемый для служебных данных, не связанных с данными.

Смотрите также

Примечания

  1. ^ Мэтт Матис обсуждал, действительно ли это практическая проблема, утверждая, что уменьшенное количество пакетов для больших кадров противодействует более высокому уровню необнаруженных ошибок.[11]

Рекомендации

  1. ^ "Ethernet Jumbo Frames". Ethernet Alliance. 2009-11-12. Получено 2015-06-18.
  2. ^ а б «Поддержка Jumbo / Giant Frame в примере конфигурации коммутаторов Catalyst». Cisco. Получено 2011-08-22. Коммутаторы Catalyst серии 3750/3560 поддерживают MTU в 1998 байт для всех интерфейсов 10/100.
  3. ^ "Ethernet Jumbo Frames" (PDF). EthernetAlliance.org. Получено 28 апреля, 2017.
  4. ^ Джефф Карузо (22 октября 1998 г.). "Alteon все еще не решает вопрос Jumbo Frames". Сетевой мир. Архивировано из оригинал на 2012-10-15. Получено 4 июля, 2011.
  5. ^ Фунг, А; Т. Хафф; H. Hum; Дж. Патвардхан; Дж. Ренье (2003). «Повторное посещение производительности TCP». Международный симпозиум IEEE 2003 г. по анализу производительности систем и программного обеспечения. ISPASS 2003. С. 70–79. Дои:10.1109 / ISPASS.2003.1190234. ISBN 978-0-7803-7756-1.
  6. ^ Д Мюррей; Т Козинец; К. Ли; М Диксон (2012). «Большие MTU и производительность в Интернете». 2012 13-я Международная конференция IEEE по высокопроизводительной коммутации и маршрутизации. С. 82–87. Дои:10.1109 / HPSR.2012.6260832. ISBN 978-1-4577-0833-6.
  7. ^ Рик Саммерхилл (17 февраля 2003 г.), rrsum-almes-mtu, Интернет2
  8. ^ Скотт Хогг (2013-03-06), Jumbo Frames, Сетевой мир, получено 2013-08-05, Большинство сетевых устройств поддерживают размер jumbo-кадра 9216 байт.
  9. ^ IEEE 802.3 79.3.4 TLV максимального размера кадра
  10. ^ IEEE 802.3 3.2.7 Поле данных клиента MAC
  11. ^ Матис, Мэтт (8 октября 2016 г.). «Аргументы по поводу Internet MTU». web.archive.org. Архивировано из оригинал на 2016-10-08. Получено 2019-08-23.
  12. ^ Филип Купман. «32-битные циклические коды избыточности для Интернет-приложений» (PDF). Департамент ECE и ICES, Университет Карнеги-Меллона.
  13. ^ «Руководство по использованию jumbo-кадров». Netgear. Получено 2020-03-21.
  14. ^ Филипп (20 октября 2016 г.). "Настройка скорости беспроводной сети". speedguide.net. Получено 20 октября, 2016.
  15. ^ IEEE 802.11-2012 8.2.3 Общий формат кадра
  16. ^ Rutherford, W .; Jorgenson, L .; Siegert, M .; Van Epp, P .; Лю, Л. (2007). «Эксперименты с моделированием 16000–64000 Б pMTU: пример супер-больших кадров в Supercomputing '05». Оптическая коммутация и сеть. 4 (2): 121–130. Дои:10.1016 / j.osn.2006.10.001.
  17. ^ RFC-3032, кодирование стека меток MPLS
  18. ^ Ceragon, Jumbo Frames: взгляд в микроволновую печь, Техническое описание В архиве 2012-09-15 в Wayback Machine
  19. ^ «Реликвия кодирования: Реквием по большим кадрам». 2011-12-07. Получено 2011-12-07.

внешняя ссылка