Ethernet padding что это

Обновлено: 03.07.2024

Это продолжение цикла статей об основах Ethernet. Мы уже рассмотрели тему о физической среде передачи данных Ethernet (медь), познакомились со стандартами T568A и T568B.
Сегодня постараемся разобраться в Ethernet кадре.

В сетевых технологиях, различают такие понятия как фрейм (frame) и пакет packet. Новички сетевых технологий, часто делают ошибки в использовании этих терминов и считают что эти термины являются синонимами, но это не так.

Давайте определимся, что же называют фреймами, а что называют пакетами.

Фреймами называют некоторое число байт, которые содержат в себе заголовк Layer 2 OSI и концевик, вместе с инкапсулированными данными (в инкапсулированных данных обычно содержатся так же другие заголовки, других уровней).

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

Используя знания, полученные в предыдущих статьях, мы знаем, что hub это устройство первого уровня (то есть устройство не знает ни о какой информации, оно не знает о Layer 2 заголовках, и тем более уж о Layer 3).
Но, в то же время, Switch обычно это Layer 2 устройство (то есть оно понимает заголовок Layer 2 Header) и исходя из этого может делать некоторые действия (например брать MAC адрес получателя, искать к какому порту этот MAC-адрес привязан и отправлять фрейм только туда и никуда больше). Так же существуют и Layer 3 коммутаторы.

Итак, спецификация Ethernet.

Давайте поговорим о ней. Какие они были, какие они сейчас.

Первым основателем Ethernet спецификации стала такая компания как DIX , на самом деле это группа компаний: Digital Equipment Corp, Intel , Xerox.
В начале 1980х годов, IEEE стандартизировала технологию Ethernet. Эта технология разделялась на две части:

802.3 Media Access Control (MAC)
802.2 Logical Link Control (LLC)

Существует несколько версий Ethernet фрейма, давайте рассмотрим их.

Теперь разберем поля поподробнее.

Как же может устройство определить, какой тип ethernet кадра принимается?

Ведь существует DIX формат (Ethernet II), 802.3 и 802_3 с SNAP ?

Все очень просто. Давайте рассмотрим алгоритм определения.

Устройство получает фрейм. Смотрит на поле Lenght/Type (помним, оно занимает 2 байта). Если значение больше чем 1518 байт (размер всего фрейма с заголовками), то это уже не Ethernet II , а 802.3 или 802.3 SNAP, потому как только в Ethernet II указывается размер в указанном поле.
Допустим Lenght/Type у нас больше 1518 (0x5FE).
Здесь нам нужно определить, какой фрейм 802.3 или 802.3 SNAP. Это делается на основе заголовка LLC (802.2), таких как DSAP,SSAP и SNAP. Заметим, что SNAP это расширение заголовков DSAP и SSAP (Сервисов стало настолько много, что в 1 байте не удавалось закодировать тот или иной сервис и пришлось создавать еще одну реализацию, которая называется 802.3 SNAP).
SSAP и DSAP обычно принимают одно и тоже значение. Поле Control принимает обычно значение 0x03, что означает, что нет необходимости устанавливать соединение на канальном уровне (Layer 2).

И все же, как определить какой формат Ethernet передается, 802.3 или 802.3 SNAP?

Если передается кадр с SNAP, то значение первого и второго байта данных (по сути это наши SSAP и DSAP) равны 0xAA, а третьего (по сути нашего Control) равняется 0x03.

Вот такой алгоритм работает при том, как определить какой формат кадра передается на приемник.

На канальном уровне, адресация проходит по MAC адресам (помните, когда рассматривали ethernet кадр, первые поля были Destination Address и Source Address, которые занимали 6 байт). Эти адреса имеют 48 битный формат и записываются в 16-ом виде.

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

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

Статья получилась довольно объёмная, рассмотренные темы — форматы 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, описанный в документе IEEE 802.3, дает описание единственного формата кадра уровня MAC. Так как в кадр уровня MAC должен вкладываться кадр уровня LLC, описанный в документе IEEE 802.2, то по стандартам IEEE в сети Ethernet может использоваться только единственный вариант кадра канального уровня, заголовок которого является комбинацией заголовков MAC и LLC подуровней.

Тем не менее на практике в сетях Ethernet на канальном уровне используются кадры 4-х различных форматов (типов). Это связано с длительной историей развития технологии Ethernet, насчитывающей период существования до принятия стандартов IEEE 802, когда подуровень LLC не выделялся из общего протокола и, соответственно, заголовок LLC не применялся.

Консорциум трех фирм Digital, Intel и Xerox в 1980 году представил на рассмотрение комитету 802.3 свою фирменную версию стандарта Ethernet (в которой был, естественно, описан определенный формат кадра) в качестве проекта международного стандарта, но комитет 802.3 принял стандарт, отличающийся в некоторых деталях от предложения DIX. Отличия касались и формата кадра, что породило существование двух различных типов кадров в сетях Ethernet.

Еще один формат кадра появился в результате усилий компании Novell по ускорению работы своего стека протоколов в сетях Ethernet.

И наконец, четвертый формат кадра стал результатом деятельности комитета 802.2 по приведению предыдущих форматов кадров к некоторому общему стандарту.

Различия в форматах кадров могут приводить к несовместимости в работе аппаратуры и сетевого программного обеспечения, рассчитанного на работу только с одним стандартом кадра Ethernet. Однако сегодня практически все сетевые адаптеры, драйверы сетевых адаптеров, мосты/коммутаторы и маршрутизаторы умеют работать со всеми используемыми на практике форматами кадров технологии Ethernet, причем распознавание типа кадра выполняется автоматически.

кадр 802.3/LLC (кадр 802.3/802.2 или кадр Novell 802.2);
кадр Raw 802.3 (или кадр Novell 802.3);
кадр Ethernet DIX (или кадр Ethernet II);
кадр Ethernet SNAP.

Форматы всех этих четырех типов кадров Ethernet приведены на рисунке.

Кадр 802.3/LLC

Заголовок кадра 802.3/LLC является результатом объединения полей заголовков кадров, определенных в стандартах IEEE 802.3 и 802.2.

Стандарт 802.3 определяет восемь полей заголовка ( поле преамбулы и начальный ограничитель кадра на рисунке не показаны).
• Поле преамбулы (Preamble)состоит из семи синхронизирующих байт 10101010. При манчестерском кодировании эта комбинация представляется в физической среде периодическим волновым сигналом с частотой 5 МГц.
• Начальный ограничитель кадра (Start-of-frame-delimiter, SFD)состоит из одного байта 10101011. Появление этой комбинации бит является указанием на то, что следующий байт - это первый байт заголовка кадра.
• Адрес назначения (Destination Address, DA)может быть длиной 2 или 6 байт. На практике всегда используются адреса из 6 байт. Первый бит старшего байта адреса назначения является признаком того, является адрес индивидуальным или групповым. Если он равен 0, то адрес является индивидуальным (unicast),a если 1, то это групповой адрес (multicast).Групповой адрес может предназначаться всем узлам сети или же определенной группе узлов сети. Если адрес состоит из всех единиц, то есть имеет шестнадцатеричное представление 0*FFFFFFFFFFFF, то он предназначается всем узлам сети и называется широковещательным адресом (broadcast).В остальных случаях групповой адрес связан только с теми узлами, которые сконфигурированы (например, вручную) как члены группы, номер которой указан в групповом адресе. Второй бит старшего байта адреса определяет способ назначения адреса - централизованный или локальный. Если этот бит равен 0 (что бывает почти всегда в стандартной аппаратуре Ethernet), то адрес назначен централизованно, с помощью комитета IEEE. Комитет IEEE распределяет между производителями оборудования так называемые организационно уникальные идентификаторы (Organizationally Unique Identifier, OUI). Этот идентификатор помещается в 3 старших байта адреса (например, идентификатор 000081 определяет компанию Bay Networks). За уникальность младших 3-х байт адреса отвечает производитель оборудования. Двадцать четыре бита, отводимые производителю для адресации интерфейсов его продукции, позволяют выпустить 16 миллионов интерфейсов под одним идентификатором организации. Уникальность централизованно распределяемых адресов распространяется на все основные технологии локальных сетей - Ethernet, Token Ring, FDDI и т. д.

ВНИМАНИЕ В стандартах IEEE Ethernet младший бит байта изображается в самой левой позиции поля, а старший бит -в самой правой. Этот нестандартный способ отображения порядка бит в байте соответствует порядку передачи бит в линию связи передатчиком Ethernet. В стандартах других организаций, например RFC IETF, ITU-T, ISO, используется традиционное представление байта, когда младший бит считается самым правым битом байта, а старший - самым левым. При этом порядок следования байтов остается традиционным. Поэтому при чтении стандартов, опубликованных этими организациями, а также чтении данных, отображаемых на экране операционной системой или анализатором протоколов, значения каждого байта кадра Ethernet нужно зеркально отобразить, чтобы получить правильное представление о значении разрядов этого байта в соответствии с документами IEEE. Например, групповой адрес, имеющийся в нотации IEEE вид 1000 0000 0000 0000 1010 0111 1111 0000 0000 0000 0000 0000 или в шестнадцатеричной записи 80-00-A7-F0-00-00, будет, скорее всего, отображен анализатором протоколов в традиционном виде как 01-00-5E-0F-00-00.

• Адрес источника (Source Address, SA)- это 2- или 6-байтовое поле, содержащее адрес узла - отправителя кадра. Первый бит адреса всегда имеет значение 0.
• Длина (Length, L)- 2-байтовое поле, которое определяет длину поля данных в кадре.
• Поле данных (Data)может содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется следующее поле - поле заполнения, - чтобы дополнить кадр до минимально допустимого значения в 46 байт.
• Поле заполнения (Padding)состоит из такого количества байт заполнителей, которое обеспечивает минимальную длину поля данных в 46 байт. Это обеспечивает корректную работу механизма обнаружения коллизий. Если длина поля данных достаточна, то поле заполнения в кадре не появляется.
• Поле контрольной суммы (Frame Check Sequence, FCS)состоит из 4 байт, содержащих контрольную сумму. Это значение вычисляется по алгоритму CRC-32. После получения кадра рабочая станция выполняет собственное вычисление контрольной суммы для этого кадра, сравнивает полученное значение со значением поля контрольной суммы и, таким образом, определяет, не искажен ли полученный кадр.

Кадр 802.3 является кадром МАС-подуровня, поэтому в соответствии со стандартом 802.2 в его поле данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра. Формат кадра LLC был описан выше. Так как кадр LLC имеет заголовок длиной 3 (в режиме LLC1) или 4 байт (в режиме LLC2), то максимальный размер поля данных уменьшается до 1497 или 1496 байт.

Кадр Raw 802.3/Novell 802.3

Кадр Raw 8023,называемый также кадром Novell 8023,представлен на рисунке. Из рисунка видно, что это кадр подуровня MAC стандарта 802.3, но без вложенного кадра подуровня LLC. Компания Novell долгое время не использовала служебные поля кадра LLC в своей операционной системе NetWare из-за отсутствия необходимости идентифицировать тип информации, вложенной в поле данных, - там всегда находился пакет протокола IPX, долгое время бывшего единственным протоколом сетевого уровня в ОС NetWare.

Теперь, когда необходимость идентификации протокола верхнего уровня появилась, компания Novell стала использовать возможность инкапсуляции в кадр подуровня MAC кадра LLC, то есть использовать стандартные кадры 802.3/L'LC. Такой кадр компания обозначает теперь в своих операционных системах как кадр 802.2, хотя он является комбинацией заголовков 802.3 и 802.2.

Кадр Ethernet DIX/Ethernet II

Кадр Ethernet DIX, называемым.также кадром Ethernet II,имеет структуру, совпадающую со структурой кадра Raw 802.3. Однако 2-байтовое поле Длина(Ь) кадра Raw 802.3 в кадре Ethernet DIXиспользуется в качестве поля типа протокола. Это поле, теперь получившее название Type (Т) или EtherType, предназначено для тех же целей, что и поля DSAP и SSAP кадра LLC - для указания типа протокола верхнего уровня, вложившего свой пакет в поле данных этого кадра.

В то время как коды протоколов в полях SAP имеют длину в один байт, в поле Type для кода протокола отводятся 2 байта. Поэтому один и тот же протокол в поле SAP и поле Type будет кодироваться в общем случае разными числовыми значениями. Например, протокол IP имеет код 204810(0*0800) для поля Ether-Type и значение 6 для поля SAP. Значения кодов протоколов для поля Ethel-Type появились раньше значений SAP, так как фирменная версия Ethernet DIX существовала до появления стандарта 802.3, и ко времени распространения оборудования 802.3 уже стали стандартами де-факто для многих аппаратных и программных продуктов. Так как структуры кадров Ethernet DIX и Raw 802.3 совпадают, то поле длины/типа часто в документации обозначают как поле L/T.

Кадр Ethernet SNAP

Так как SNAP представляет собой протокол, вложенный в протокол LLC, то в полях DSAP и SSAP записывается код ОхАА, отведенный для протокола SNAP. Поле Control заголовка LLC устанавливается в 0х03, что соответствует использованию ненумерованных кадров.

Заголовок SNAP является дополнением к заголовку LLC, поэтому он допустим не только в кадрах Ethernet, но и в кадрах протоколов других технологий 802. Например, протокол IP всегда использует структуру заголовков LLC/SNAP при инкапсуляции в кадры всех протоколов локальных сетей: FDDI, Token Ring, 100VG-AnyLAN, Ethernet, Fast Ethernet, Gigabit Ethernet.

Правда, при передаче пакетов IP через сети Ethernet, Fast Ethernet и Gigabit Ethernet протокол IP использует кадры Ethernet DIX.

Использование различных типов кадров Ethernet

Автоматическое распознавание типов кадров Ethernet выполняется достаточно несложно. Для кодирования типа протокола в поле EtherType указываются значения, превышающие значение максимальной длины поля данных, равное 1500, поэтому кадры Ethernet II легко отличить от других типов кадров по значению поля L/T. Дальнейшее распознавание типа кадра проводится по наличию или отсутствию полей LLC. Поля LLC могут отсутствовать только в том случае, если за полем длины идет начало пакета IPX, а именно 2-байтовое поле контрольной суммы пакета, которое всегда заполняется единицами, что дает значение в 255 байт. Ситуация, когда поля DSAP и SSAP одновременно содержат такие значения, возникнуть не может, поэтому наличие двух байт 255 говорит о том, что это кадр Raw 802.3. В остальных случаях дальнейший анализ проводится в зависимости от значений полей DSAP и SSAP. Если они равны 0*АА, то это кадр Ethernet SNAP, а если нет, то 802.3/LLC.

В табл. 2 приведены данные о том, какие типы кадров Ethernet обычно поддерживают реализации популярных протоколов сетевого уровня.

Таблица 2.Типы кадров Ethernet, поддерживающие реализации популярных протоколов сетевого уровня .

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

Ethernet - кадр предшествует преамбулы и ограничителя начала кадра (SFD), которые являются одновременно частью Ethernet - пакета на физическом уровне . Каждый кадр Ethernet начинается с заголовка Ethernet, который содержит MAC-адреса назначения и источника в качестве первых двух полей. Средняя часть кадра - это данные полезной нагрузки, включая любые заголовки для других протоколов (например, Интернет-протокола ), переносимые в кадре. Кадр заканчивается проверочной последовательностью кадра (FCS), которая представляет собой 32-битную циклическую проверку избыточности, используемую для обнаружения любого повреждения данных при передаче.

СОДЕРЖАНИЕ

Состав

Пакет данных на проводе и кадр в качестве полезной нагрузки состоят из двоичных данных. Ethernet передает данные со старшим октетом (байтом) первым; однако в каждом октете младший бит передается первым.

Внутренняя структура кадра Ethernet определена в IEEE 802.3. В таблице ниже показан полный пакет Ethernet и фрейм внутри в том виде, в каком он был передан, для размера полезной нагрузки до MTU в 1500 октетов. Некоторые реализации Gigabit Ethernet и других высокоскоростных вариантов Ethernet поддерживают большие кадры, известные как jumbo-кадры .

Необязательный тег 802.1Q занимает дополнительное место в кадре. Размеры полей для этой опции указаны в скобках в таблице выше. IEEE 802.1ad (Q-in-Q) позволяет использовать несколько тегов в каждом кадре. Этот вариант здесь не проиллюстрирован.

Пакет Ethernet - физический уровень

Разделитель преамбулы и начального кадра

Кадр Ethernet внутри пакета Ethernet с SFD, обозначающим конец преамбулы пакета и указывающим начало кадра.

Пакет Ethernet начинается с семиоктетной преамбулы и однооктетного ограничителя начального кадра (SFD).

Преамбула состоит из 56-битного (семибайтового) шаблона с чередованием 1 и 0 битов, что позволяет устройствам в сети легко синхронизировать часы своих приемников, обеспечивая синхронизацию на уровне битов. За ним следует SFD, чтобы обеспечить синхронизацию на уровне байтов и пометить новый входящий фрейм. Для вариантов Ethernet, передающих последовательные биты вместо более крупных символов , (некодированный) битовый шаблон на проводе для преамбулы вместе с частью SFD кадра составляет 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011; Биты передаются по порядку слева направо.

SFD - это восьмибитовое (однобайтное) значение, которое отмечает конец преамбулы, которая является первым полем пакета Ethernet, и указывает начало кадра Ethernet. SFD предназначен для разрыва битовой последовательности преамбулы и сигнализации о начале фактического кадра. Сразу за SFD следует MAC-адрес назначения , который является первым полем в кадре Ethernet. SFD - это двоичная последовательность 10101011 (0xD5, десятичное 213 в первом битовом порядке LSB Ethernet).

Схема приемопередатчика физического уровня (сокращенно PHY) требуется для подключения Ethernet MAC к физической среде. Соединение между PHY и MAC не зависит от физической среды и использует шину из средств массовой информации независимого интерфейс семья ( MII , GMII , RGMII , SGMII , XGMII ). Микросхемы приемопередатчиков Fast Ethernet используют шину MII, которая является четырехбитовой (один полубайт ) шиной, поэтому преамбула представлена как 14 экземпляров 0xA, а SFD - 0xA 0xB (в полубайтах). Микросхемы приемопередатчиков Gigabit Ethernet используют шину GMII, которая представляет собой восьмиразрядный интерфейс, поэтому последовательность преамбулы, за которой следует SFD, будет иметь вид 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5 (в байтах).

Кадр - уровень канала передачи данных

Заголовок

Заголовок содержит MAC-адреса назначения и источника (каждый длиной по шесть октетов), поле EtherType и, необязательно, тег IEEE 802.1Q или тег IEEE 802.1ad .

Поле EtherType имеет длину два октета и может использоваться для двух разных целей. Значения 1500 и ниже означают, что он используется для указания размера полезной нагрузки в октетах, а значения 1536 и выше указывают, что он используется как EtherType, чтобы указать, какой протокол инкапсулирован в полезной нагрузке кадра. При использовании в качестве EtherType длина кадра определяется местоположением межпакетного промежутка и действительной контрольной последовательностью кадра (FCS).

IEEE 802.1Q тег или IEEE 802.1ad тега, если он присутствует, представляет собой поле из четырех октетов , что указывает на то виртуальной локальной сети (VLAN) членство и IEEE 802.1p приоритет. Первые два октета тега называется Т аги Р rotocol ID entifier (TPID) и дважды как поле EtherType , указывающим , что кадр является либо 802.1Q или 802.1ad тегов. 802.1Q использует TPID 0x8100. 802.1ad использует TPID 0x88a8.

Полезная нагрузка

Минимальная полезная нагрузка составляет 42 октета при наличии тега 802.1Q и 46 октетов при отсутствии. Когда фактическая полезная нагрузка меньше, соответственно добавляются байты заполнения. Максимальная полезная нагрузка - 1500 октетов. Нестандартные кадры большого размера позволяют увеличить максимальный размер полезной нагрузки.

Последовательность проверки кадра

Последовательность проверки кадра (FCS) - это четырехоктетная проверка циклическим избыточным кодом (CRC), которая позволяет обнаруживать поврежденные данные во всем кадре, принятом на стороне получателя. Согласно стандарту значение FCS вычисляется как функция защищенных полей кадра MAC: адреса источника и назначения, поля длины / типа, данных клиента MAC и заполнения (то есть всех полей, кроме FCS).

Согласно стандарту, это вычисление выполняется с использованием алгоритма CRC32 BZIP2 со сдвигом влево (poly = 0x4C11DB7, начальный CRC = 0xFFFFFFFF, CRC дополняется после, значение проверки = 0x38FB2284). Стандарт гласит, что данные передаются первым младшим значащим битом (бит 0), тогда как FCS передается первым старшим значащим битом (бит 31). Альтернативой является вычисление CRC с использованием CRC32 со сдвигом вправо (poly = 0xEDB88320, начальный CRC = 0xFFFFFFFF, CRC дополняется пост-дополнением, значение проверки = 0x2144DF1C), что приведет к CRC, который является инверсией битов FCS, и передать сначала данные и младший бит CRC, что приводит к идентичным передачам.

Стандарт гласит, что получатель должен вычислять новую FCS по мере получения данных, а затем сравнивать полученную FCS с FCS, вычисленным получателем. Альтернативой является вычисление CRC как для полученных данных, так и для FCS, что приведет к фиксированному ненулевому значению «проверки». (Результат не равен нулю, потому что CRC дополняется во время генерации CRC). Поскольку данные принимаются первым из младших битов, и чтобы избежать необходимости буферизовать октеты данных, приемник обычно использует CRC32 со сдвигом вправо. Это делает значение «проверки» (иногда называемое «магической проверкой») 0x2144DF1C.

Однако аппаратная реализация CRC с логическим сдвигом вправо может использовать регистр сдвига с линейной обратной связью со сдвигом влево в качестве основы для вычисления CRC, реверсирования битов и получения значения проверки 0x38FB2284. Поскольку дополнение CRC может выполняться после вычисления и во время передачи, то, что остается в аппаратном регистре, является результатом без дополнений, поэтому остаток для реализации с правым сдвигом будет дополнением к 0x2144DF1C = 0xDEBB20E3, а для сдвига влево реализация, дополнение 0x38FB2284 = 0xC704DD7B.

Конец кадра - физический уровень

Конец кадра обычно обозначается символом конца из-потока данных на физическом уровне или по потере сигнала несущей; примером является 10BASE-T , где принимающая станция определяет конец переданного кадра по потере несущей. Более поздние физические уровни используют явный конец данных или конец символа или последовательности потока , чтобы избежать неоднозначности, особенно когда несущая постоянно пересылается между кадрами; примером является Gigabit Ethernet с его схемой кодирования 8b / 10b , в которой используются специальные символы, которые передаются до и после передачи кадра.

Межпакетный разрыв - физический уровень

Межпакетный интервал (IPG) - это время простоя между пакетами. После отправки пакета передатчики должны передать как минимум 96 бит (12 октетов) состояния незанятой линии перед передачей следующего пакета.

Дифференциация кадров Ethernet

Тип кадра	Ethertype или длина	Начало полезной нагрузки два байта
Ethernet II	≥ 1536	Любой
Novell raw IEEE 802.3	≤ 1500	0xFFFF
IEEE 802.2 LLC	≤ 1500	Другой
IEEE 802.2 SNAP	≤ 1500	0xAAAA

Есть несколько типов кадров Ethernet:

Фрейм Ethernet II, или Ethernet версии 2, или фрейм DIX является наиболее распространенным типом, используемым сегодня, поскольку он часто используется непосредственно Интернет-протоколом.
Необработанный нестандартный вариант кадра NovellIEEE 802.3
Кадр IEEE 802.2Logical Link Control (LLC)
Кадрпротокола доступа к подсети (SNAP) IEEE 802.2

Различные типы кадров имеют разные форматы и значения MTU , но могут сосуществовать на одном физическом носителе. Различие между типами кадров возможно на основании таблицы справа.

Кроме того, все четыре типа кадров Ethernet могут дополнительно содержать тег IEEE 802.1Q для определения того, к какой VLAN он принадлежит, и его приоритета ( качества обслуживания ). Эта инкапсуляция определена в спецификации IEEE 802.3ac и увеличивает максимальный кадр на 4 октета.

Тег IEEE 802.1Q, если он присутствует, помещается между полями Source Address и EtherType или Length. Первые два октета тега - это значение идентификатора протокола тега (TPID) 0x8100. Он расположен в том же месте, что и поле EtherType / Length в немаркированных кадрах, поэтому значение EtherType 0x8100 означает, что кадр помечен, а истинный EtherType / Length находится после Q-тега. За TPID следуют два октета, содержащие информацию управления тегами (TCI) (приоритет IEEE 802.1p ( качество обслуживания ) и идентификатор VLAN). За Q-тегом следует остальная часть кадра, используя один из типов, описанных выше.

Ethernet II

Фрейминг Ethernet II (также известный как DIX Ethernet , названный в честь DEC , Intel и Xerox , основных участников его разработки), определяет двухоктетное поле EtherType в кадре Ethernet , которому предшествуют MAC-адреса назначения и источника, которые идентифицируют верхний протокол уровня, инкапсулированный данными кадра. Например, значение 0x0800 EtherType сигнализирует, что фрейм содержит дейтаграмму IPv4 . Аналогично, EtherType 0x0806 указывает кадр ARP , 0x86DD указывает кадр IPv6, а 0x8100 указывает наличие тега IEEE 802.1Q (как описано выше).

Наиболее распространенный формат кадра Ethernet, тип II

Поскольку этот промышленно разработанный стандарт прошел формальный процесс стандартизации IEEE , поле EtherType было изменено на поле длины (данных) в новом стандарте 802.3. Поскольку получателю все еще необходимо знать, как интерпретировать кадр, стандарт требовал, чтобы заголовок IEEE 802.2 соответствовал длине и указывал тип. Много лет спустя стандарт 802.3x-1997 и более поздние версии стандарта 802.3 официально одобрили оба типа кадрирования. Фрейминг Ethernet II является наиболее распространенным в локальных сетях Ethernet из-за его простоты и меньших накладных расходов.

Чтобы разрешить использование некоторых кадров, использующих кадрирование Ethernet v2, и некоторых, использующих исходную версию формирования кадров 802.3, в одном и том же сегменте Ethernet, значения EtherType должны быть больше или равны 1536 (0x0600). Это значение было выбрано, потому что максимальная длина поля полезной нагрузки кадра Ethernet 802.3 составляет 1500 октетов (0x05DC). Таким образом, если значение поля больше или равно 1536, кадр должен быть кадром Ethernet v2, причем это поле является полем типа. Если оно меньше или равно 1500, это должен быть кадр IEEE 802.3, где это поле является полем длины. Исключительные значения от 1500 до 1536 не определены. Это соглашение позволяет программному обеспечению определять, является ли кадр кадром Ethernet II или кадром IEEE 802.3, обеспечивая сосуществование обоих стандартов на одном физическом носителе.

Novell raw IEEE 802.3

"Необработанный" формат кадра 802.3 от Novell был основан на ранней работе IEEE 802.3. Novell использовала это как отправную точку для создания первой реализации собственного сетевого протокола IPX через Ethernet. Они не использовали заголовок LLC, а начали пакет IPX сразу после поля длины. Это не соответствует стандарту IEEE 802.3, но поскольку IPX всегда имеет FF в качестве первых двух октетов (в то время как в IEEE 802.2 LLC этот шаблон теоретически возможен, но крайне маловероятен), на практике это обычно сосуществует на проводе с другими реализациями Ethernet, за заметным исключением некоторых ранних форм DECnet, которые это сбивали с толку.

Novell NetWare по умолчанию использовала этот тип кадра до середины девяностых годов, и поскольку NetWare тогда была очень широко распространена, а IP - нет, в какой-то момент большая часть мирового трафика Ethernet проходила через «чистый» 802.3, несущий IPX. Начиная с NetWare 4.10, NetWare по умолчанию использует IEEE 802.2 с LLC (тип кадра NetWare Ethernet_802.2) при использовании IPX.

IEEE 802.2 LLC

Некоторые протоколы, например, разработанные для стека OSI , работают непосредственно поверх инкапсуляции IEEE 802.2 LLC, которая обеспечивает как сетевые службы с установлением соединения, так и без установления соединения.

Инкапсуляция IEEE 802.2 LLC в настоящее время не широко используется в обычных сетях, за исключением крупных корпоративных установок NetWare, которые еще не перешли на NetWare через IP . В прошлом многие корпоративные сети использовали IEEE 802.2 для поддержки прозрачных мостов трансляции между сетями Ethernet и Token Ring или FDDI .

Существует Интернет-стандарт для инкапсуляции трафика IPv4 в кадры SAP / SNAP IEEE 802.2 LLC. Он почти никогда не реализуется в Ethernet, хотя используется в FDDI, Token Ring, IEEE 802.11 (за исключением диапазона 5,9 ГГц , где используется EtherType) и других локальных сетях IEEE 802 . IPv6 также может передаваться через Ethernet с использованием IEEE 802.2 LLC SAP / SNAP, но, опять же, это почти никогда не используется.

IEEE 802.2 SNAP

Изучив заголовок 802.2 LLC, можно определить, следует ли за ним заголовок SNAP. Заголовок LLC включает два восьмибитовых адресных поля, которые в терминологии OSI называются точками доступа к услугам (SAP); когда и исходный, и целевой SAP имеют значение 0xAA, за заголовком LLC следует заголовок SNAP. Заголовок SNAP позволяет использовать значения EtherType со всеми протоколами IEEE 802, а также поддерживает пространства идентификаторов частных протоколов.

В IEEE 802.3x-1997 стандарт IEEE Ethernet был изменен, чтобы явно разрешить использование 16-битного поля после MAC-адресов в качестве поля длины или поля типа.

Набор протоколов AppleTalk v2 в сети Ethernet (« EtherTalk ») использует инкапсуляцию IEEE 802.2 LLC + SNAP.

Максимальная пропускная способность

Мы можем рассчитать накладные расходы протокола для Ethernet в процентах (размер пакета, включая IPG).

Мы можем рассчитать эффективность протокола для Ethernet

Максимальная эффективность достигается при максимально допустимом размере полезной нагрузки и составляет:

для немаркированных кадров, поскольку размер пакета составляет максимум 1500 октетов полезной нагрузки + 8 октетов преамбулы + 14 октетов заголовка + 4 октета завершающей части + минимальный межпакетный интервал, соответствующий 12 октетам = 1538 октетов. Максимальный КПД составляет:

когда используется тегирование 802.1Q VLAN.

Пропускная способность может быть вычислена по эффективности

где чистая скорость передачи данных физического уровня ( скорость передачи данных по проводам) зависит от стандарта физического уровня Ethernet и может составлять 10 Мбит / с, 100 Мбит / с, 1 Гбит / с или 10 Гбит / с. Следовательно, максимальная пропускная способность для 100BASE-TX Ethernet составляет 97,53 Мбит / с без 802.1Q и 97,28 Мбит / с с 802.1Q.

Использование канала - это понятие, которое часто путают с эффективностью протокола. Он учитывает только использование канала, не обращая внимания на характер передаваемых данных - полезную нагрузку или служебные данные. На физическом уровне канал связи и оборудование не знают разницы между кадрами данных и управления. Мы можем рассчитать использование канала :

Общее время учитывает время приема-передачи по каналу, время обработки на хостах и время передачи данных и подтверждений. Время, потраченное на передачу данных, включает данные и подтверждения.

Бегущие кадры

Короткий кадр - это кадр Ethernet, длина которого меньше минимальной длины в 64 октета согласно стандарту IEEE 802.3. Ошибочные кадры чаще всего вызываются коллизиями ; другие возможные причины - неисправная сетевая карта , опустошение буфера , несоответствие дуплексного режима или проблемы с программным обеспечением.

Семейство технологий Ethernet.

Модификации Ethernet.

Варианты соединения	Скорость
Ethernet	Коаксиальный кабель, оптика, витая пара	10 Мб/с
Fast Ethernet	Оптика, витая пара	100 Мб/с
Gigabit Ethernet	Оптика, витая пара	1 Гб/с
10G Ethernet	Оптика, витая пара	10 Гб/с

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

Ethernet (10 Мб/с)
10Base-2
10Base-5
10Base-T
10Base-F
10Base-FL

При этом различная физическая реализация подключения (разные кабели) приводят к возможности использования разных топологий сети. Для 10Base-5 максимально топорно:

А вот 10Base-T уже может использовать полнодуплексную передачу данных:

Здесь, как видите присутствует устройство под названием сетевой концентратор. Поэтому небольшое лирическое отступление на эту тему.

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

Сетевой концентратор (хаб) работает на 1-м (физическом) уровне модели OSI и ретранслирует сигнал с одного входящего порта, на несколько исходящих. На этом его функционал заканчивается.
Сетевой коммутатор (свитч) работает на 2-м (канальном уровне). Здесь также происходит передача данных от одного устройства нескольким, но при этом коммутатор анализирует кадры на предмет MAC-адреса получателя и передает пакет только тому узлу, которому он адресован(!). Адресацию и структуру кадров подробно разберем чуть ниже.
Маршрутизатор же и вовсе работает на 3-м уровне (сетевом) модели OSI.

Кадр Ethernet.

Вся передаваемая информация поделена на пакеты/кадры, имеющие следующий формат:

Рассмотрим блоки подробнее:

Все поля, кроме поля данных, являются служебными.

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

При работе он позволяет идентифицировать все устройства в сети и определить, какому именно из них предназначен тот или иной кадр данных. Распределением MAC-адресов занимается регулирующий комитет IEEE Registration Authority, именно сюда производитель сетевого устройства должен обращаться для выделения ему некоего диапазона адресов, которые он сможет использовать для своей продукции.

И на этой ноте заканчиваем вводную теоретическую часть по Ethernet, в дальнейшем приступим к практическому использованию в своих устройствах. До скорого!

Читайте также: