Ограничение ethernet кадра снизу

Обновлено: 07.07.2024

Преамбула: 7 байт, каждый из которых представляет чередование единиц и нулей 10101010. Преамбула позволяет установить битовую синхронизацию на приемной стороне.
Ограничитель начала кадра (SFD, start frame delimiter): 1 байт, последовательность 10101011, указывает, что далее последуют информационные поля кадра. Этот байт можно относить к преамбуле.
Адрес назначения (DA, destination address): 6 байт, указывает MAC-адрес станции (MAC-адреса станций), для которой (которых) предназначен этот кадр. Это может быть единственный физический адрес (unicast), групповой адрес (multicast) или широковещательный адрес (broadcast).
Адрес отправителя (SA, source address): 6 байт, указывает MAC-адрес станции, которая посылает кадр.
Поле типа или длины кадра (T or L, type or length): 2 байта. Существуют два базовых формата кадра Ethernet (в английской терминологии raw formats - сырые форматы) - Ethernet_II и IEEE 802.3 (рис.1), причем различное назначение у них имеет именно рассматриваемое поле. Для кадра Ethernet_II в этом поле содержится информация о типе кадра. Ниже приведены значения в шестнадцатеричной системе этого поля для некоторых распространенных сетевых протоколов: 0x0800 для IP, 0x0806 для ARP, 0x809B для AppleTalk, 0x0600 для XNS, и 0x8137 для IPX/SPX. С указанием в этом поле конкретного значения (одного из перечисленных) кадр приобретает реальный формат, и в таком формате кадр уже может распространяться по сети.

Для кадра IEEE 802.3 в этом поле содержится выраженный в байтах размер следующего поля - поля данных (LLC Data). Если эта цифра приводит к общей длине кадра меньше 64 байт, то за полем LLC Data добавляется поле Pad. Для протокола более высокого уровня не возникает путаницы с определением типа кадра, так как для кадра IEEE 802.3 значение этого поля не может быть больше 1500 (0x05DC). По этому, в одной сети могут свободно сосуществовать оба формата кадров, более того один сетевой адаптер может взаимодействовать с обоими типами посредством стека протоколов.

2. Основные
варианты
алгоритмов
случайного
доступа
к среде

Однако сеть со случайным доступом имеет один пожалуй главный недостаток - это не совсем устойчивая работа сети при большой загруженности, когда может проходить достаточно большое время, прежде чем данной станции удается передать данные. Виной тому коллизии, которые возникают между станциями, начавшими передачу одновременно или почти одновременно. При возникновении коллизии передаваемые данные не доходят до получателей, а передающим станциям приходится повторно возобновлять передачу. Дадим определение:

множество всех станций сети, одновременная передача любой пары из которых приводит к коллизии, называется коллизионным доменом (collision domain).

Из-за коллизии могут возникать непредсказуемые задержки при распространении кадров по сети, особенно при большой загруженности сети (много станций пытаются одновременно передавать внутри коллизионного домена, > 20-25) и при большом диаметре коллизионного домена (> 2 км). Поэтому при построении сетей желательно избегать таких экстремальных режимов работы.

Проблема построения протокола, способного наиболее оптимальным образом разрешать коллизии, и оптимизирующего работу сети при больших загрузках, была одной из ключевых на этапе формирования стандарта Ethernet IEEE 802.3. Первоначально рассматривались три основных подхода в качестве кандидатов для реализации стандарта случайного доступа к среде: непостоянный, 1-постоянный и р-постоянный (рис.2).

Непостоянный (nonpersistent) алгоритм. При этом алгоритме станция, желающая передавать, руководствуется следующими правилами.

Прослушивает среду, и если среда свободна (т.е. если нет другой передача или нет сигнала коллизии) передает, в противном случае - среда занята - переходит к шагу 2;
Если среда занята, ждет случайное (в соответствии c определенной кривой распределения вероятностей) время и возвращается к шагу 1.

1-постоянный (1-persistent) алгоритм. Для сокращения времени, когда среда не занята, мог бы использоваться 1-постоянный алгоритм. При этом алгоритме станция, желающая передавать, руководствуется следующими правилами.

Прослушивает среду, и если среда не занята передает, в противном случае переходит к шагу 2;
Если среда занята, продолжает прослушивать среду до тех пор пока среда не освободится, и как только среда освобождается сразу же начинает передавать.

Р-постоянный (p-persistent) алгоритм. Правила этого алгоритма следующие:

Если среда свободна, станция с вероятность p сразу же начинает передачу или с вероятность (1-p) ожидает в течение фиксированного интервал времени T. Интервал T обычно берется равным максимальному времени распространения сигнала из конца в конец;
Если среда занята, станция продолжает прослушивание до тех пор, пока среда не освободится, затем переходит к шагу 1;
Если передача задержана на один интервал T, станция возвращается к шагу 1.

3. Протокол
CSMA/CD

Протокол множественного случайного доступа к среде с разрешением коллизий CSMA/CD воплотил в себе идеи выше перечисленных алгоритмов и добавил важный элемент - разрешение коллизий. Поскольку коллизия разрушает все передаваемые в момент ее образования кадры, то и нет смысла станциям продолжать дальнейшую передачу своих кадров, коль скоро они (станции) обнаружили коллизии. В противном случае, значительной была бы потеря времени при передаче длинных кадров. По этому для своевременного обнаружения коллизии станция прослушивает среду на всем протяжении собственной передачи. Приведем основные правила алгоритма CSMA/CD для предающей станции.

Передача кадра (рис.3а):

Станция, собравшаяся передавать, прослушивает среду. И передает, если среда свободна. В противном случае (т.е. если среда занята) переходит к шагу 2. При передаче нескольких кадров подряд станция выдерживает определенную паузу между посылками кадров - межкадровый интервал, причем после каждой такой паузы перед отправкой следующего кадра станция вновь прослушивает среду (возвращение на начало шага 1);
Если среда занята, станция продолжает прослушивать среду до тех пор, пока среда не станет свободной, и затем сразу же начинает передачу;
Каждая станция, ведущая передачу прослушивает среду, и в случае обнаружения коллизии, не прекращает сразу же передачу а сначала передает короткий специальный сигнал коллизии - jam-сигнал, информируя другие станции о коллизии, и прекращает передачу;
После передачи jam-сигнала станция замолкает и ждет некоторое произвольное время в соответствии с правилом бинарной экспоненциальной задержки и затем возвращаясь к шагу 1.

Jam-сигнал (jamming - дословно глушение). Передача jam-сигнала гарантирует, что не один кадр не будет потерян, так как все узлы, которые передавали кадры до возникновения коллизии, приняв jam-сигнал, прервут свои передачи и замолкнут в преддверии новой попытки передать кадры. Jam-сигнал должен быть достаточной длины, чтобы он дошел до самых удаленных станций коллизионного домена, с учетом дополнительной задержки SF (safety margin) на возможных повторителях. Содержание jam-сигнала не принципиально за исключением того, что оно не должно соответствовать значению поля CRC частично переданного кадра (802.3), и первые 62 бита должны представлять чередование ‘1’ и ‘0’ со стартовым битом ‘1’.

На рис.4 проиллюстрирован процесс обнаружения коллизии применительно к топологии шина (на основе тонкого или толстого коаксиального кабеля (стандарты 10Base5 и 10Base2 соответственно).

В момент времени узел A (DTEA) начинает передачу, естественно прослушивая свой же передаваемый сигнал. В момент времени , когда кадр почти дошел узла B (DTE B), этот узел, не зная о том, что уже идет передача, сам начинает передавать. В момент времени , узел B обнаруживает коллизию (увеличивается постоянная составляющей электрического сигнала в прослушиваемой линии). После этого узел B передает jam-сигнал и прекращает передачу. В момент времени сигнал коллизии доходит до узла A, после чего A также передает jam-сигнал и прекращает передачу.

По стандарту Ethernet узел не может предавать очень короткие кадры, или иными словами вести очень короткие передачи. Как говорилось при описании формата кадра, даже если поле данных не заполнено до конца, то появляется специальное дополнительное поле, удлиняющее кадр до минимальной длины 64 байта без учета преамбулы. Время канала ST (slot time)- это минимальное время, в течении которого узел обязан вести передачу, занимать канал. Это время соответствует передаче кадра минимального допустимого размера, принятого стандартом Ethernet IEEE 802.3. Время канала связано с максимальным допустимым расстоянием между узлами сети - диаметром коллизионного домена. Допустим, что в приведенном выше примере реализуется наихудший сценарий, когда станции A и B удалены друг от друга на максимальное расстояние. Время, распространения сигнала от A до B обозначим через . Узел A начинает передавать в нулевой момент времени. Узел B начинает передавать в момент времени и обнаруживает коллизию спустя интервал после начала своей передачи. Узел A обнаруживает коллизию в момент времени . Для того, чтобы кадр, испущенный A, не был потерян, необходимо, чтобы узел A не прекращал вести передачу к этому моменту, так как тогда, обнаружив коллизию, узел A будет знать, что его кадр не дошел, и попытается передавать его повторно. В противном случае кадр будет потерян. Максимальное время, спустя которое с момента начала передачи узел A еще может обнаружить коллизию равно - это время называется задержкой на двойном пробеге RTD (round-trip delay). В более общем случае RTD определяет суммарную задержку, связанную как с задержкой из-за конечной длины сегментов, так и с задержкой, возникающей при обработке кадров на физическим уровнем промежуточных повторителей и оконечных узлов сети. Для дальнейшего удобно использовать также другую единицу измерения времени: битовое время BT (bit time). Время в 1 BT соответствует времени, необходимому для передачи одного бита, т.е. 0,1 мкс при скорости 10 Мбит/с.

Стандартом Ethernet регламентированы следующие правила обнаружения коллизии конечным узлом сети :

Узел A должен обнаружить коллизию до того, как передаст свой 512-й бит, включая биты преамбулы;
Узел A должен прекратить передачу раньше, чем будет передан кадр минимальной длины - передано 576 бит (512 бит, начиная отсчет после ограничителя начала кадра SFD);
Перекрытие между передачами узлов A и B - битовый интервал начиная с момента передачи первого бита преамбулы узлом A и заканчивая приемом узлом A последнего бита испущенного узлом B - должно быть меньше чем 575 BT.

При передаче больших кадров, например 1500 байт, коллизия, если она вообще возникнет, обнаруживается практически в самом начале передачи, не позднее первых 64 переданных байт (если коллизия не возникла в это время, то позже она уже не возникнет, поскольку все станции прослушивают линию и, "слыша" передачу, будут молчать). Так как jam-сигнал значительно короче полного размера кадра, то при использовании алгоритма CSMA/CD количество в холостую израсходованной емкости канала сокращается до времени, требуемого на обнаружение коллизии. Раннее обнаружение коллизий приводит к более эффективным использование канала. Позднее обнаружение коллизий, свойственное более протяженным сетям, когда диаметре коллизионного домена составляет несколько километров, снижает эффективность работы сети. На основании упрощенной теоретической модели поведения загруженной сети (в предположении большого числа одновременно передающих станций и фиксированной минимальной длины передаваемых кадров у всех станций) можно выразить производительность сети U через отношение RTD/ST:

где - основание натурального логарифма. На производительность сети влияет размер транслируемых кадров и диаметр сети. Производительность в наихудшем случае (когда RDT=ST) составляет около 37%, а в наилучшем случае (когда RTD много меньше, чем ST) стремится к 1. Хотя формула и выведена в пределе большого числа станций, пытающихся передавать одновременно, она не учитывает особенностей алгоритма усеченной бинарной экспоненциальной задержки, рассмотренного ниже, и не справедлива для сильно перегруженной коллизиями сети, например, когда станций, желающих передавать становится больше 15.

Усеченная бинарная экспоненциальная задержка (truncated binary exponential backoff). Алгоритм, принятый в стандарте IEEE 802.3 CSMA/CD, наиболее близок к 1-постоянному алгоритму, но отличается дополнительным элементом - усеченной бинарной экспоненциальной задержкой. При возникновения коллизии стация подсчитывает, сколько раз подряд при отправке пакета возникает коллизия. Поскольку повторяющиеся коллизии свидетельствуют о высокой загруженности среды, MAC-узел пытается увеличивать задержку между повторными попытками передачи кадра. Соответствующая процедура увеличения интервалов времени подчиняется правилу усеченной бинарной экспоненциальной задержки и работает следующим образом.

Прием кадра. (рис.3б) Принимающая станция или другое сетевое устройство, например, концентратор или коммутатор первым делом синхронизируется по преамбуле и затем преобразовывает манчестерский код в бинарную форму (на физическом уровне). Далее обрабатывается бинарный поток.

На уровне MAC оставшиеся биты преамбулы сбрасываются, а станция читает адрес назначения и сравнивает его со своим собственным. Если адреса совпадают, то поля кадра за исключением преамбулы, SDF и FCS помещаются в буфер и вычисляется контрольная сумма, которая сравнивается с полем контрольной последовательности кадра FCS (используется метод циклического суммирования CRC-32). Если они равны, то содержимое буфера передается протоколу более высокого уровня. В противном случае кадр сбрасывается. Возникновении коллизии при приеме кадра обнаруживается либо по изменению электрического потенциала, если используется коаксиальный сегмент, либо по факту приема дефектного кадра, неверная контрольная сумма, если используется витая пара или оптическое волокно. В обоих случая принятая информация сбрасывается.

Основные функциональные параметры стандарта Ethernet приведены в табл.1.

4. Физический
уровень
IEEE 802.3
и типы
портов

Стандарт 10Base-F в свою очередь подразделяется еще на три спецификации:

10Base-FP - определяет топологию пассивной звезды на основе волоконно-оптических сегментов длиной до 1 км и числом станций до 33. При такой топологии каждый удаленный узел связывается с центральным узлом парой волокон. Сигнал из центрального узла размножается оптическим ответвителем и идет на все удаленные узлы. Сигналы от удаленных узлов идут по обратному волокну на оптический комбайнер, после чего попадают на вход центрального узла. При приходе одновременно нескольких сигналов на центральный узел, возникает коллизия, которая разрешается стандартным путем.
10Base-FB. Эта спецификация определяет двухволоконный канал протяженностью до 2 км для создания магистральных сегментов точка-точка между повторителями. Она базируется на синхронной системе приема-передачи, обеспечивая восстановление таймерных характеристик и большое число (до 15) последовательно установленных повторителей.
10Base-FL - определяет двухволоконный канал протяженностью до 2 км, который может использоваться для установлении соединения точка-точка между станцией и повторителем, или между двумя повторителями. Асинхронная система приема-передачи (в отличии от принятой в 10Base-FB) позволяет значительно снизить стоимость оборудования. Появление стандарта на одномодовое волокно дало возможность строить сверхпротяженные сегменты (до 100 км, дуплексный режим), и сделало более весомыми аргументы в пользу стандарта 10Base-FL. Эта спецификация получила наиболее широкое распространение в современных сетях Ethernet.

MDI интерфейс, свойственен сетевой карте; MDI-X интерфейс свойственен портам повторителя или коммутатора. Повторитель/коммутатор также могут иметь один или несколько портов RJ-45 типа MDI.

* - Длина волны 850 нм используется для многомодового (mm) ВОК - собственно стандарт 10Base-FL, и 1310 нм - для одномодового (sm) и многомодового ВОК.

** - Допустима также смешанная физическая топология, однако логическая топология всегда остается шина.

*** - При использовании одномодового ВОК, длина сегмента ограничивается максимальным диаметром коллизионного домена Ethernet. Если связь осуществляется между двумя коммутаторами в режиме полного дуплекса, то расстояние может достигать 100 км.

Статья получилась довольно объёмная, рассмотренные темы — форматы 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 адрес отправителя. Всегда юникаст.

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). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Не давая себе передышки, в 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 протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.

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). Мифы и рифы».

Описание технологии Ethernet

Форматы кадров Ethernet

Данные, передаваемые в сети Ethernet, разбиты на кадры. Напомним, что практически каждой сетевой технологии (независимо от её уровня) соответствует единица передачи данных : Ethernet - кадр, АТМ - ячейка, IP - дейтаграмма и т.д. Данные по сети в чистом виде не передаются. Как правило, к единице данных "пристраевается" заголовок. В некоторых сетевых технологиях добавляется также окончание. Заголовок и окончание несут служебную информацию и состоят из определённых полей.

Так как существует несколько типов кадров,то для того, чтобы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадров. Кадры могут быть четырёх разных форматов, несколько отличающихся друг от друга. Базовых форматов кадров (raw formats) существует всего два - Ethernet II и Ethernet 802.3. Эти форматы отличаются назначением всего одного поля.

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

Большинство сетевых администраторов не уделяет должного внимания типам кадров Ethernet, а это может явиться источником проблем. Например, если клиентское сетевое программное обеспечение настроено на неверный тип кадра, то пользователь не сможет взаимодействовать с сервером. За типом кадра приходится особенно внимательно следить в сетях Nowell NetWare, так как в новых версиях этой операционной системы тип кадра по умолчанию был изменён с 802.3 на 802.2. Кроме того, в корпоративных сетях применяются устройства от нескольких поставщиков, базирующихся на разных протоколах взаимодействия и использующих различные типы кадров.

Для того, чтобы рабочие станции имели возможность взаимодействовать с сервером в одном сегменте сети, они должны поддерживать единый формат кадра. Существует четыре основных разновидности кадров Ethernet :

Ethernet Type II
Ethernet 802.3
Ethernet 802.2
Ethernet SNAP (SubNetwork Access Protocol).

Рассмотрим поля, общие для всех четырёх типов кадров (рис. 1).

Рис. 1. Общий формат кадров Ethernet

Поля в кадре имеют следующие значения :

Поля "Преамбула" и "Признак начала кадра" предназначены для синхронизации отправителя и получателя. Преамбула представляет собой 7 - байтовую последовательность единиц и нулей. Поле признака начала кадра имеет размер 1 байт. Эти поля не принимаются в расчёт при вычислении длины кадра.
Поле "Адрес получателя" состоит из 6 байт и содержит физический адрес устройства в сети, которому адресован данный кадр. Значения этого и следующего поля являются уникальными. Каждому производителю адаптеров Ethernet назначаются первые три байта адреса, а оставшиеся три байта определяются непосредственно самим производителем. Например, для адаптеров фирмы 3Com физические адреса будут начинаться с 0020AF. Первый бит адреса получателя имеет специальное значение. Если он равен 0, то это адрес конкретного устройства (только в этом случае первые три байта служат для идентификации производителя сетевой платы), а если 1 - широковещательный. Обычно в широковещательном адресе все оставшиеся биты тоже устанавливаются равными единице (FF FF FF FF FF FF).
Поле "Адрес отправителя" состоит из 6 байт и содержит физический адрес устройства в сети, которое отправило данный кадр. Первый бит адреса отправителя всегда равен нулю.
Поле "Длина/тип" может содержать длину или тип кадра в зависимости от используемого кадра Ethernet. Если поле задаёт длину, она указывается в двух байтах. Если тип - то содержимое поля указывает на тип протокола верхнего уровня, которому принадлежит данный кадр. Например, при использовании протокола IPX поле имеет значение 8137, а для протокола IP - 0800.
Поле "Данные" содержит данные кадра. Чаще всего - это информация, нужная протоколам верхнего уровня. Данное поле не имеет фиксированной длины.
Поле "Контрольная сумма" содержит результат вычисления котрольной суммы всех полей, за исключением перамбулы, признака начала кадра и самой контрольной суммы. Вычисление выполняется отправителем и добавляется в кадр. Аналогичная процедура вычисления выполняется и на устройстве получателя. В случае, если результат вычисления не совпадает со значением данного поля, предполагается, что произошла ошибка при передаче. В этом случае кадр считается испорченным и игнорируется.

Следует отметить, что минимальная допустимая длина всех четырёх типов кадров Ethernet составляет 64 байта, а максимальная - 1518 байт. Так как на служебную информацию в кадре отводится 18 байт, то поле "Данных" может иметь длину от 46 до 1500 байт. Если передаваемые по сети данные меньше допустимой минимальной длины, кадр будет автоматически дополняться до 46 байт. Столь жёсткие ограничения на минимальную длину кадра ввдены для обеспечения нормальной работы механизма обнаружения коллизий.

Рассмотрим более подробно форматы кадров разных типов. Тип кадра Ethernet II используется многими протоколами верхнего уровня, такими как IPX, TCP/IP и Apple Talk. Данный тип кадра был разработан фирмами DEC, Intel и Xerox. Необходимо учитывать, что хотя данный тип кадра является наиболее широко используемым, он не одобрен организациями ISO и IEEE. Формат данного типа кадра отличается от рассмотренного выше только тем, что в поле "Длина/тип" всегда указывается тип протокола.

Сетевые операционные системы Nowell NetWare 2.x и 3.x (за исключением 3.12) по умолчанию используют кадры Ethernet 802.3. Хотя в названии этого кадра есть упоминание комитета IEEE, последний не имел никакого отношения к его разработке.

Данный тип кадра не содержит никакой информации о протоколе. Поле "Длина/тип" всегда указывает длину кадра. В результате нет стандартных методов идентификации сетевого протокола, которому принадлежит данный кадр. Однако, только в соответствии с концепцией фирмы Nowell, только протокол IPX может использоваться с данным типом кадров. Разработана специальная последовательность действий для определения того, что именно протокол IPX был инкапсулирован в кадр данного типа :

Проверяется поле "Длина/тип". Если оно содержит значение от 0 до 1518 (05ЕЕ), то данное поле определяет длину кадра, а не тип протокола (то есть это кадр 802.3, в противном случае - кадр Ethernet II).
Проверяются два байта, следующие за полем "Длина/тип". Если они содержат FFFF, это означает, что кадр принадлежит протоколу IPX, так как заголовок этого протокола всегда начинается с FFFF.

В результате стандартизации сетей Ethernet подкомитетом IEEE 802.3 появился кадр Ethernet 802.2. Этот кадр является базовым для операционных систем Nowell NetWare версий 3.12 и 4.х. В данном типе кадра сразу за адресом отправителя следует поле длины, имеющее такое же назначение. Кроме того, этот тип кадра содержит несколько дополнительных полей, рекомендованных подкомитетом IEEE 802.3. Эти поля распологаются за полем "Длина/тип" и имеют следующее назначение :

Поле "DSAP" указывает на используемый получателем протокол сетевого уровня. Размер поля составляет 1 байт (один бит в нём зарезервирован). Для протокола IPX значение поля равно Е0, для протоколов IP - 06, для NetBIOS - F0.
Поле "SSAP" указывает на используемый отправителем протокол сетевого уровня. Размер данного поля составляет 1 байт (один бит зарезервирован). Обычно значение данного поля совпадает со значением поля DSAP.
Поле "Контроль" указывает на тип сервиса, требуемый для сетевого протокола. Размер данного поля составляет 1 байт. Сетевая операционная система Nowell NetWare устанавливает значение данного поля в 03.

Формат кадра Ethernet 802.2 имеет некоторые недостатки, в частности, он содержит нечётное число байтов служебной информации. Это не совсем удобно для работы большинства сетевых устройств. Кроме того, для идентификации протокола сетевого уровня отводится 7 бит,что позволяет поддерживать "всего" 128 различных протоколов. Кадр Ethernet SNAP, являющийся дальнейшим развитием Ether n et 802.2, содержит следующие дополнительные поля (рис. 2) :

Поле "Код организации" имеет длину 3 байта и указывает на код конкретной организации (фирмы), которая присвоила значение поля "Идентификатор протокола". Если значение поля равно 000000 (а это так практически всегда, за исключением сетей Apple Talk), то поле "Идентификатор протокола" содержит значение, которое обычно помещается в поле "Длина/тип", то есть идентификатор протокола верхнего уровня.
Поле "Идентификатор протокола" имеет длину два байта и идентифицирует протокол верхнего уровня, инкапсулированный в поле "Данные" кадра. При использовании протокола IPX это поле содержит значение 8137.

В совокупности эти два поля составляют дополнительное пятибайтовое поле для идентификации протокола.Это было сделано для увеличения числа поддерживаемых протоколов.

Передача в любой физической среде требует правил, определяющих режим работы системы связи. Управление режимом передачи по Ethernet-сетям контролируется с помощью стандартов IEEE 802, определенных для канала передачи данных Ethernet. Фундаментальные знания этих стандартов необходимы для полного понимания принципа организации связи на канальном уровне в сетях Ethernet.

Цели

По завершении этого раздела обучающиеся научатся:

Объяснять, как применять эталонные модели в сетях.

Описывать, как формируются кадры.

Объяснять принцип работы функции MAC-адресации на канальном уровне.

Описывать принцип обработки и передачи кадров Ethernet.

Управление сетевой связью