Jumbo фреймы что это

Включение использования Jumbo Frame в Windows

Под Jumbo Frame обычно обозначают кадр сети Ethernet, в котором, можно передать данные, размером более 1500 байт (MTU). Обычно jumbo-фреймы могут передавать до 9000 байтов данных. По умолчанию, в операционной системе Windows, jumbo-фреймы отключены на уровне драйвера сетевой карты.
Чтобы включить поддержку jumbo-фреймов в Windows необходимо сделать следующее:
1. Открыть свойства сетевого подключения и нажать Properties (свойства)
2. в открывшемся окне нажать кнопку Configure (сконфигурировать) под названием сетевой карты
3. в окне Advanced перейти в пункт Jumbo Frame и в выпадающем списке справа выбрать желаемый ( или максимальный) размер Jumbo фрейма.4. После включения Jumbo Frame (выбора значения MTU в 9000), значение MTU выставляется в свойствах сетевого адаптера.

Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря

Статья получилась довольно объёмная, рассмотренные темы — форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

Форматы Ehternet фреймов.

1) Ethernet II

Рис. 1

Preamble – последовательность бит, по сути, не являющаяся частью ETH заголовка определяющая начало Ethernet фрейма.

DA (Destination Address) – MAC адрес назначения, может быть юникастом, мультикастом, бродкастом.

SA (Source Address) – MAC адрес отправителя. Всегда юникаст.

E-TYPE (EtherType) – Идентифицирует L3 протокол (к примеру 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100- указывает что фрейм тегирован заголовком 802.1q, и т.д. Список всех EtherType — standards.ieee.org/develop/regauth/ethertype/eth.txt )

Payload – L3 пакет размером от 46 до 1500 байт

FCS (Frame Check Sequences) – 4 байтное значение CRC используемое для выявления ошибок передачи. Вычисляется отправляющей стороной, и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.

Данный формат был создан в сотрудничестве 3-х компаний – DEC, Intel и Xerox. В связи с этим, стандарт также носит название DIX Ethernet standard. Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I – в 1980г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997г. году данный стандарт был добавлен IEEE к стандарту 802.3, и на данный момент, подавляющее большинство пакетов в Ethernet сетях инкапсулированы согласно этого стандарта.

2) Ethernet_802.3/802.2 (802.3 with LLC header)

Рис. 2

Как вы понимаете, комитет IEEE не мог смотреть спокойно, как власть, деньги и женщины буквально ускользают из рук. Поэтому, занятый более насущными проблемами, за стандартизацию технологии Ethernet взялся с некоторым опозданием (в 1980 взялись за дело, в 1983 дали миру драфт, а в 1985 сам стандарт), но большим воодушевлением. Провозгласив инновации и оптимизацию своими главными принципами, комитет выдал следующий формат фрейма, который вы можете наблюдать на Рисунке 2.

Первым делом обращаем внимание на то, что “ненужное” поле E-TYPE преобразовано в поле Length, которое указывало на количество байт следующее за этим полем и до поля FCS. Теперь, понять у кого длинее можно было уже на втором уровне системы OSI. Жить стало лучше. Жить стало веселее.

Но, указатель на тип протокола 3его уровня был нужен, и IEEE дало миру следующую инновацию — два поля по 1 байту — Source Service Access Point(SSAP) и Destination Service Access Point (DSAP). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Замечание: В жизни же это мало пригодилось и SSAP/DSAP значения обычно совпадают. К примеру SAP для IP – 6, для STP — 42 (полный список значений — standards.ieee.org/develop/regauth/llc/public.html)

Не давая себе передышки, в IEEE зарезервировали по 1 биту в SSAP и DSAP. В SSAP под указание command или response пакета, в DSAP под указание группового или индивидуального адреса (см. Рис. 6). В Ethernet сетях эти вещи распространения не получили, но количество бит в полях SAP сократилось до 7, что оставило лишь 128 возможных номера под указание вышестоящего протокола. Запоминаем этот факт, к нему мы ещё вернёмся.

Было уже сложно остановиться в своём стремлении сделать лучший формат фрейма на земле, и в IEEE фрейм формате появляется 1 байтное поле Control. Отвечающее, не много, не мало, за Connection-less или же Connection-oriented соединение!

Выдохнув и осмотрев своё детище, в IEEE решили взять паузу.

Замечание: Рассматриваемые 3 поля — DSAP, SNAP и Control и являются LLC заголовком.

3) «Raw» 802.3

Рис. 3

Данный «недостандарт» явил в мир Novell. Это были лихие 80-ые, все выживали, как могли, и Novell не был исключением. Заполучив ещё в процессе разработки спецификации стандарта 802.3/802.2, и лёгким движением руки выкинув LLC заголовок, в Novell получили вполне себе неплохой фрейм формат (с возможность измерения длины на втором уровне!), но одним существенным недостатком – отсутствием возможности указания вышестоящего протокола. Но, как вы уже могли догадаться, работали там ребята не глупые, и по здравому размышлению выработали решение – «а обратим ка мы свои недостатки в свои же достоинства», и ограничили этот фрейм-формат исключительно IPX протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.

https://amdy.su/wp-admin/options-general.php?page=ad-inserter.php#tab-8

4) 802.3 with SNAP Header.

Время шло. В комитет IEEE приходило осознание того, что номера протоколов и деньги кончаются. Благодарные пользователи засыпали редакцию письмами, где 3-х байтный LLC заголовок ставился в один ряд с такими великими инновациями человечества, как оборудование собаки 5ой ногой, или же с рукавом, который можно использовать для оптимизации женской анатомии. Выжидать дальше было нельзя, настало время заявить о себе миру повторно.

Рис. 4

И в помощь страждущим от нехватки номеров протоколов (их всего могло быть 128 – мы упоминали), IEEE вводит новый стандарт фрейма Ethernet SNAP (Рис. 4). Основное нововведение — добавление 5-ти байтного поля Subnetwork Access Protocol (SNAP), которое в свою очередь состоит из двух частей – 3х байтного поля Organizationally Unique Identifier (OUI) и 2х байтного Protocol ID (PID) — Рис. 5.

Рис. 5

OUI или же vendor code – позволяет идентифицировать пропиетарные протоколы указанием вендора. К примеру, если вы отловите WireShark`ом пакет PVST+, то в поле OUI увидите код 0x00000c, который является идентификатором Cisco Systems (Рис. 6).

Рис. 6

Замечание: Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP, протоколы CDP, VTP, DTP.

Поле PID это, по сути, то же поле EtherType из DIX Ethernet II — 2 байта под указание протокола вышестоящего уровня. Так как ранее, для этого использовались DSAP и SSAP поля LLC заголовка, то для указания того, что тип вышестоящего протокола нужно смотреть в поле SNAP, поля DSAP и SSAP принимают фиксированное значение 0xAA (также видно на Рис. 6)

Замечание: При использовании для переноса IP пакетов формата фрейма LLC/SNAP, IP MTU снижается с 1500 до 1497 и 1492 байт соответственно.

По заголовкам в формате фрейма в принципе всё. Хотел бы обратить внимание на ещё один момент в формате фрейма – размер payload. Откуда взялся этот диапазон — от 46 до 1500 байт?

Размер L3 Payload.

Откуда взялось нижнее ограничение, знает, пожалуй, каждый, кто хотя бы читал первый курикулум CCNA. Данное ограничение является следствием ограничения в размер фрейма в 64 байта (64 байта – 14 байт L2 заголовок — 4 байта FCS = 46 байт ) накладываемого методом CSMA/CD – время требуемое на передачу 64 байт сетевым интерфейсом является необходимым и достаточным для определения коллизии в среде Ethernet.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

Замечание: Фреймы меньше 64 байт называются Runts, фреймы больше 1518 байт называются Giants. Просмотреть кол-во таких фреймов полученных на интерфейсе можно командой show interface gigabitEthernet module/number и show interface gigabitEthernet module/number counters errors. Причём до IOS 12.1(19) в счётчики шли как фреймы с неверным, так и верным CRS (хотя вторые не всегда дропались – зависит от платформы и условий). А вот начиная с 12.1.(19) отображаются в этих счётчиках только те runt и giant фреймы, которые имеют неверный CRS, фреймы меньше 64 байт, но с верным CRS (причина возникновения обычно связана с детегированием 802.1Q или источником фреймов, а не проблемами физического уровня) с этой версии попадают в счётчик Undersize, дропаются они, или же форвардятся дальше, зависит от платформы.

Эволюция размеров Ethernet заголовков.

802.3AC — увеличивает максимальный размер фрейма до 1522 – добавляется Q-tag – несущий информацию о 802.1Q (VLAN tag) и 802.1p (биты под COS)
802.1AD — увеличивает максимальный размер фрейма до 1526, поддержка QinQ
802.1AH (MIM) – Provider Bridge Backbone Mac in Mac + 30 байт к размеру фрейма
MPLS – увеличиваем размер фрейма на стек меток 1518 + n*4, где n – количество меток в стеке.
802.1AE – Mac Security, к стандартным полям добавляются поля Security Tag и Message Authentication Code + 68 байт к размеру фрейма.

Все эти фреймы увеличенного размера группируются под одни именем – Baby-Giant frames. Негласное верхнее ограничение по размерам для Baby-Giant – это 1600 байт. Современные сетевые интерфейсы будут форвардить эти фреймы, зачастую, даже без изменения значения HW MTU.

Отдельно обратим внимание на спецификации 802.3AS — увеличивает максимальный размер фрейма до 2000 (но сохраняет размер MTU в 1500 байт!). Увеличение приходится на заголовок и трейлер. Изначально увеличение планировалось на 128 байт – для нативной поддержки стандартом 802.3 вышеперечисленных расширений, но в итоге сошлись на 2х тысячах, видимо, чтобы два раза не собираться (или как говорят в IEEE – this frame size will support encapsulation requirements of the foreseeable future). Стандарт утвержден в 2006 году, но кроме как на презентациях IEEE, я его не встречал. Если у кого есть что добавить здесь (и не только здесь) – добро пожаловать в комменты. В целом тенденция увеличения размера фрейма при сохранении размера PAYLOAD, порождает у меня в голове смутные сомнения в правильности выбранного направления движения.

Замечание: Немного в стороне от перечисленного обосновался FCoE фрейм – размер фрейма до 2500 байт, зачастую, эти фреймы называются mini-jumbo. Для их саппорта необходимо включать поддержку jumbo-frame.

Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
Увеличение TCP Throughput при изменении размера MTU — staff.psc.edu/rreddy/networking/mtu.html

Чем больше фрейм, тем дольше он будет передаваться (Рис. 8):
Буферы в памяти сетевых устройств заполняются быстрее, что может вызвать нежелательные последствия. По сути, решаемо на стадии проектирования оборудования, но увеличивает стоимость.
Проприетарная реализация у каждого производителя – все устройства должны поддерживать или одинаковые размеры Jumbo фрейма, или же наборы размеров.
Использование на больших участках сети находящихся под разным административным контролем, по сути, невозможно, из-за отсутствия механизма Jumbo Frame Discovery – промежуточный узел может не поддерживать Jumbo Frame совсем или определенный размер.

В серверных кластерах
При бэкапировании
Network File System (NFS) Protocol
iSCSI SANs
FCoE SANs

Замечание: Верхнее ограничение размера есть и у Jumbo MTU. Оно определяется размером поля FCS (4 байт) и алгоритмом Cyclic Redundancy Check и равняется 11 455 байт. На практике же, Jumbo MTU обычно ограничен размером в 9216 байт, на некоторых платформах в 9000 байт, на более старом железе в 8092 байт (речь о Cisco).

Фух, в принципе всё. Что хотел рассмотреть по теории, рассмотрели. По конфигурации размеров MTU и теории с финтами стоящими за этими тремя буквами, прошу в мою прошлую статью – «Maximum Transmission Unit (MTU). Мифы и рифы».

Jumbo Frames — что это такое и для чего нужно?

Jumbo-фреймы это сверхдлинные Ethernet-фреймы, которые используются в высокопроизводительных сетях для увеличения производительности на длинных расстояниях. В основном термином Jumbo-фреймы называют фреймы, которые имеют значение 9000 байт для Gigabit Ethernet, но так же могут называться все пакеты, превышающие стандартный размер MTU (Maximum Transmission Unit) 1518 байт на Ethernet.

В оборудовании Edge-Core:
Команда jumbo frame — нужна перезагрузка.

В оборудовании Cisco:

Увеличиваем mtu:
set system mtu
после чего необходимо перезагрузка коммутатора, о чем он сам напомнит.

В оборудовании ZyXEL:
Коммутаторы серии ES-3100 поддерживает Jumbo Frame на всех 28 портах (24FE+4GE).
Коммутаторы серии GS (Gigabit Ethernet-коммутаторы) по умолчанию поддерживают Jumbo Frame до 9 КБ.

Таким образом, в конфигурации никакие изменения вносить не нужно. Все сделано за Вас! 🙂

Джамбо-фрейм — Jumbo frame

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

СОДЕРЖАНИЕ

Зарождение

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

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

Принятие

Jumbo-кадры могут снизить накладные расходы и циклы ЦП, а также положительно повлиять на сквозную производительность TCP. Наличие кадров большого размера может отрицательно сказаться на задержке в сети, особенно на каналах с низкой пропускной способностью. Размер кадра, используемый при сквозном соединении, обычно ограничивается наименьшим размером кадра в промежуточных звеньях. 802.5 Token Ring может поддерживать кадры с размером MTU 4464 байта , FDDI может передавать 4352 байта, ATM — 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 байтов в качестве предпочтительного размера полезной нагрузки для jumbo-кадров явилось результатом обсуждений в Объединенной инженерной группе Internet2 и в сетях федерального правительства США. Их рекомендация была принята всеми другими национальными исследовательскими и образовательными сетями. Чтобы соответствовать этому обязательному критерию закупки, производители, в свою очередь, приняли 9000 байт в качестве обычного размера MTU с размером кадра jumbo не менее 9018/9022 байта (без / с полем IEEE 802.1Q). Большая часть оборудования Ethernet может поддерживать кадры большого размера до 9216 байт.

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

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

Простые аддитивные контрольные суммы, содержащиеся в транспортах 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 кбит и выше. Поддержка полинома CRC Кастаньоли в транспорте общего назначения, предназначенном для обработки фрагментов данных, и в транспорте TCP, предназначенном для передачи данных SCSI, оба обеспечивают повышенную частоту обнаружения ошибок, несмотря на использование больших кадров, в которых увеличение MTU Ethernet в противном случае привело бы к привело к значительному сокращению обнаружения ошибок.

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

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

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

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

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

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

Тип кадра	MTU	Накладные расходы уровня 1		Накладные расходы уровня 2		Накладные расходы уровня 3	Накладные расходы уровня 4	Размер полезной нагрузки	Всего передано	Эффективность
Стандарт	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	7935	Преамбула и заголовок PLCP 24 байта	IPG варьируется	заголовок кадра и безопасность ovhd 52 байта	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	7895 байт	8015 байт + размер IPG	<98,5%
IEEE 802.11 с подключением к Ethernet	1500	Преамбула и заголовок PLCP 24 байта	IPG варьируется	заголовок кадра и безопасность ovhd 52 байта	FCS 4 байта	Заголовок IPv4 20 байт	Заголовок TCP 20 байт	1460 байт	1580 байт + размер IPG	<92,4%

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

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

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

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

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

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

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