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

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.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

А вот откуда взялись эти пресловутые 1500 байт, вопрос сложнее. Я нашел следующее объяснение - предпосылок на введение верхнего ограничения размера фрейма было несколько:

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

Итого, в стандарте 802.3 размер фрейма ограничивался 1518 байтами сверху, а payload 1500 байтами (отсюда и дефолтный размер MTU для Ethernet интерфейса).

Замечание: Фреймы меньше 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 заголовков.

С развитием технологий и спецификаций линейки IEEE 802 претерпевал изменения и размер фрейма. Основные дальнейшее изменения размера фрейма (не MTU!):

• 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.

И последний «бастард» Ethernet это Jumbo Frame (хотя если перевести Jumbo, то вырисовывается скорее Ходор – отсылка к Game of Thrones). Под это описание попадают все фреймы превосходящие размером стандарт в 1518 байт, за исключением рассмотренных выше. Jumbo пакеты никак не отражены в спецификациях 802.3 и поэтому реализация остаётся на совести каждого конкретного вендора. Тем не менее, Jumbo фреймы существуют столько же, сколько существует Ethernet. Определено это следующим:

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

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-запрос)

Рисунок 6 - Широковещательная передача ARP-запроса компьютером A

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-ответ)

Рисунок 7 - ARP-ответа компьютера B

2.2.2 Работа ARP протокола в случае, когда отправитель и получатель расположены в разных сетях

Пусть компьютер A с именем Vito и компьютер B с именем Maxx так же, как и в первом случае, находятся в одной сети класса C 192.168.0.0, не разделенной на подсети, но компьютер B подключен и к внешней сети и помимо своих обычных функций выполняет функции шлюза (маршрутизатора). Компьютер A хочет обратиться через внешнюю сеть к некоторому компьютеру C с IP-адресом 195.5.27.10, т.е. получатель находится в другой сети. На рисунке 8 приведена соответствующая иллюстрация.

Компьютер C (получатель)

IP-адрес: 195.5.27.10

Компьютер

Vito(отправи

MAC-адрес:00-02-44-63-D3-87 MAC-адрес: 00-80-48-B7-BD-

IP-адрес: 192.168.0.147
	IP-адрес: 192.168.0.145

Компь ютер B

ARP-запрос

Рисунок 8 - Расположение отправителя и получателя в разных сетях

При обращении компьютера A к компьютеру C, например, при вводе на компьютере A команды ping –n 1 195.5.27.10 , компьютер A действует следующим образом.

Сначала компьютер A определяет, в какой сети – локальной или удаленной – находится компьютер C. Для этого он “накладывает” стандартную маску подсети класса C 255.255.255.0 на свой IP-адрес 192.168.0.147 и получает результат 192.168.0.0.

Затем он “накладывает” ту же маску на IP-адрес компьютера-получателя 195.5.27.10 и получает результат 195.5.27.0. Т.к. результаты этих двух операций различны, компьютер A делает вывод о том, что компьютер C находится в другой сети и передачу данных нужно выполнить через шлюз (компьютер B).

Затем компьютер A должен послать кадр Ethernet с эхо-запросом, указав в заголовке вложенного в этот кадр пакета ICMP IP-адрес компьютера-получателя 195.5.27.10, а в заголовке кадра Ethernet – MAC-адрес шлюза, т.е. компьютера B (а не

MAC-адрес компьютера-получателя ), т.к. сначала кадр по сети Ethernet должен достигнуть шлюза. Следовательно, компьютер A должен знать MAC-адрес шлюза, но в настройках TCP/IP компьютера указывается не MAC-адрес, а IP-адрес шлюза. Если компьютер A недавно обращался к шлюзу, то MAC-адрес шлюза может находиться в таблице ARP компьютера A. Если же компьютер A после начальной загрузки еще не обращался к шлюзу или обращался к нему давно и соответствующая динамическая запись соответствия “IP-адрес – MAC-адрес” уже удалена, то таблица ARP компьютера A не будет содержать MAC-адреса шлюза (если только он не введен туда администратором вручную). В этом случае компьютер A должен выяснить MAC-адрес шлюза с помощью протокола ARP.

Процесс выяснения компьютером A MAC-адреса шлюза (компьютера B) описан выше. После определения MAC-адреса шлюза компьютер A посылает эхо-запрос компьютеру C. Этот эхо-запрос поступает на компьютер B, который, выполняя функцию маршрутизатора, направляет эхо-запрос компьютеру C через внешнюю сеть.

При передаче данных от отправителя получателю, находящемуся в удаленной сети, в заголовке IP-пакета указывается IP-адрес получателя, а в заголовке кадра Ethernet указывается MAC-адрес не получателя, а MAC-адрес шлюза, через который

должны быть переданы данные. Аналогично, при поступлении на отправитель (компьютер А) ответных данных от получателя (компьютера C) через шлюз (компьютер В) в поле MAC-адреса источника заголовка кадра Ethernet указывается MAC-адрес не компьютера C, а MAC-адрес шлюза (компьютера В), а в поле IP-адреса источника заголовка IP-пакета указывается IP-адрес не шлюза В, а IP-адрес компьютера C.

2.2.3 Использование протокола ARP для проверки наличия в сети дублированного IP-адреса

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

Такой ARP-запрос называется самообращенным (от слова gratuitous – “беспричинным”, т.е. не вызванным необходимостью последующей передачи данных, или “безвозмездным”, т.е. не требующим ответа). Компьютер, пославший самообращенный ARP-запрос, не ждет на него ответа. Если ответа на самообращенный ARP-запрос не поступает, значит, такого же IP-адреса, как у данного компьютера, в локальной сети больше нет. Если же какой-либо компьютер локальной сети отвечает на самообращенный ARP-запрос своим MAC-адресом, значит, в локальной сети уже есть компьютер с таким IP-адресом. В этом случае на экране компьютера, пославшего самообращенный ARP-запрос, и на экране компьютера, ответившего на этот запрос, выводятся сообщения об ошибке - “Конфликт IP-адреса с другой системой в сети”.

2.3 Протокол ICMP

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) входит с состав стека TCP/IP. Протокол ICMP используется для тестирования доступности узлов сети и представляет собой эхо-протокол (на посланный запрос должен быть получен ответ). ICMP протокол работает с двумя типами сообщений: эхо-запрос и эхо-ответ . Компьютер или маршрутизатор посылают по сети эхо-запрос, в котором указывают IP-адрес узла, доступность которого нужно проверить. Компьютер (маршрутизатор), который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу - отправителю запроса. В запросе могут содержаться некоторые данные (контрольная сумма), которые должны быть возвращены в ответе. Так как эхо-запрос и эхо-ответ передаются по сети внутри IPпакетов (см. рис. 9), то их успешная доставка означает нормальное функционирование всей транспортной системы интерсети.

Рисунок 9 - Инкапсуляция (вложение) ICMP-сообщения в IP-датаграмму

Для отправки эхо-запросов и приема эхо-ответов используется утилита (программа)ping .

2.4 Протокол DHCP

Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

При автоматическом статическом способе DHCP-сервер присваивает IP-адрес клиенту из пула (массива) наличных IP-адресов без вмешательства администратора. Границы пула (массива) назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и присвоенным ему IP-адресом, как и при ручном назначении, существует соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последующих запросах (на получение IP-адреса) сервер возвращает клиенту тот же самый IP-адрес.

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

DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.

Протокол DHCP использует модель клиент-сервер. Во время старта системы DHCP - клиент, находится в состоянии "инициализации" и посылает широковещательное сообщение discover (обнаружить) для поиска в сети DHCPсервера. DHCP-сервер, получив это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию. DHCP - клиент, получив предложение от DHCP-сервера, переходит в состояние "запрос" и отправляет сообщение request (запрос) DHCP-серверу. DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для

этого адреса. Кроме того, DHCP-сервер посылает параметры сетевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние "связь", находясь в котором он может принимать участие в работе сети TCP/IP. По истечения срока аренды IP-адреса компьютер пытается обновить параметры аренды у DHCPсервера, а если этот IP-адрес не может быть выделен снова, то компьютеру выделяется другой IP-адрес. На рисунке 10 приведен формат DHCP пакета.

Рисунок 10 - Формат DHCP пакета

Использование протокола DHCP кроме своих достоинств имеет ряд недостатков. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS (система доменных имен). DNS служит для преобразования символьных имен в IP-адреса, если IP-адреса, будут, динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.

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

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

Для работы с протоколом DHCP в ОС “Windows” используется команда ipconfig , которая служит для отображения всех текущих параметров сети TCP/IP и обновления параметров DHCP и DNS. При вызове командыipconfig можно использовать ряд параметров, например:

/all - вывод полной конфигурации TCP/IP для всех адаптеров. Без этого параметра командаipconfig выводит только IP-адреса, маску подсети и основной шлюз для каждого адаптера.

Стандарт на технологию Ethernet, описанный в документе 802.3, дает описание единственного формата кадра МАС-уровня. Так как в кадр МАС-уровня должен вкладываться кадр уровня LLC, описанный в документе 802.2, то по стандартам IEEE в сети Ethernet может использоваться только единственный вариант кадра канального уровня, образованный комбинацией заголовков МАС и 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 (здесь под кадром понимается весь набор полей, которые относятся к канальному уровню, то есть поля MACиLLCуровней):

Кадр 802.3/LLC (кадр 802.3/802.2 или кадр Novell 802.2)

Кадр Raw 802.3 (или кадр Novell 802.3)

Кадр Ethernet DIX (или кадр Ethernet II)

Кадр Ethernet SNAP

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

Рис.6. 2 . Форматы кадров Ethernet.

Рис. 14.3. Форматы кадров Ethernet.

Кадр 802.3/llc

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

Стандарт 802.3 определяет восемь полей заголовка:

Поле преамбулы ( Preamble ) состоит изсеми байтов синхронизирующих данных . Каждый байт содержит одну и ту же последовательность битов -10101010 . При манчестерском кодировании эта комбинация представляется в физической среде периодическим волновым сигналом с частотой 5 МГц.

Начальный ограничитель кадра (Start - of - frame - delimiter , SFD ) состоит из одного байта с набором битов10101011 . Появление этой комбинации бит является указанием на то, что следующий байт - это первый байт заголовка кадра.

Адрес назначения (Destination Address, DA) - 6 байт. Первый бит старшего байта адреса назначения являетсяпризнак ом того, являетсяадрес индивидуальным или групповым . Если0 , то адрес являетсяиндивидуальным ( unicast ), а если1 , то этогрупповой адрес ( multicast ). Групповой адрес сети может предназначаться всем узлам сети или же определенной группе узлов сети.Если адрес состоит из всех единиц, то есть имеет шестнадцатеричное представление0* FFFFFFFFFFFF , то он предназначенвсем узлам сети и называетсяшироковещательным адресом ( broadcast ) . В остальных случаях групповой адрес связан только с теми узлами, которые сконфигурированы (например, вручную) как члены группы, номер которой указан в групповом адресе.Второй бит старшего байта адреса определяетспособ назначения адреса - централизованный или локальный . Если этот бит равен0 (что бывает почти всегда в стандартной аппаратуреEthernet), тоадрес назначен централизованно , с помощью комитетаIEEE. КомитетIEEEраспределяет между производителями оборудования так называемыеорганизационно уникальные идентификаторы (Organizationally Unique Identifier , OUI ) . Этот идентификатор помещается в3 старших байта адреса (например, идентификатор 000081 определяет компаниюBay Networks) .За уникальность младших 3-х байт адреса отвечает производитель оборудования. Двадцать четыре бита , отводимые производителю для адресации интерфейсов его продукции, позволяют выпустить16 миллионов интерфейсов под одним идентификатором организации . Уникальность централизованно распределяемых адресов распространяется на все основные технологии локальных сетей -Ethernet,TokenRing,FDDIи т.д.

Внимание: В стандартахIEEEEthernetмладший бит байта изображается в самой левой позиции поля, а старший бит - в самой правой. Это нестандартный способ отображения порядка бит в байте соответствует порядку передачи бит в линию связи передатчикомEthernet.

Адрес источника ( Source Address , SA ) - 6-ти байтовое поле, содержащее адрес станции - отправителя кадра. Первый бит - всегда имеет значение 0.

Длина (Length, L ) . Двухбайтовоеполе длины определяет длину поля данных в кадре.

Кадр 802.3 является кадром MAС-подуровня, в соответствии со стандартом 802.2 в егополе данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра

DSAP адрес доступа к службе получателя ( Destination Service Access Point ) -1 байт.

SSAP адрес доступа службы отпрвителя (Source Service Access Point) - 1 байт.

Control поле управления – 1 байт в режимеLLC1 и 2 байта в режимеLLC2.

9. Поле данных ( Data ) может содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется поле заполнения(Padding ) , чтобы дополнить кадр до минимально допустимого значения в 46 байт. Так как кадр LLC имеет заголовок длиной 3 (в режимеLLC1) или 4 байт (в режимеLLC2), то максимальный размер поля данных уменьшается до 1497 (1796) байт.

10. Поле контрольной суммы ( frame Check Sequence , FCS ) - 4 байта, содержащие значение, которое вычисляется по определенному алгоритму CRC-32.

Шаблон технологии Ethernet, написан в доке IEEE 802,3. Это единственное описание кадра формата уровня MAC. В сети Ethernet реализован только один тип кадра канального уровня, заголовок которого есть множество заголовков подуровней MAC и LLC что есть некой .

• Ethernet DIX/Ethernet II , появился в 1980 году в результате совместной роботы трех фирм Xerox, Intel и Digital которые представил версию 802,3в качестве международного стандарта;
• Комитет принял 802,3 и немного переделал его. Так появились 802,3/LLC, 802,3/802,2 или Novell 802,2 ;
• Raw 802,3 или Novell 802,3 — созданы для ускорения работы своего стека протоколов в сетях Ethernet;
• Ethernet SNAP является итогом комитета 802,2 которые приведен к общему стандарту и стал гибок к будущим возможным добавлением полей;

Сегодня сетевое аппаратное и программное обеспечение умеют работать со всеми форматами кадров, и распознавание кадров работает автоматически что уменьшает и одним из . Форматы кадров показано на рис.1.

Рисунок 1

Кадр 802.3/LLC

Заголовок этого кадра объединяет поля заголовком кадров IEEE 802,3 и 802,2. Стандарт 802,3 состоит из:

• Поле преамбулы — называется полем синхронизирующих байтов — 10101010. В манчестерском кодировании этот код модифицируется в физической среде в сигнал с частотой 5 МГц.
• Начальный ограничитель кадра — является одним байтом 10101011. Это поле указывает на то, что следующий байт — это первый байт заголовка кадра.
• Адрес назначения — это поле может быть длиной 6 или 2 байта. Обычно это поле используют для MAC-адреса в 6 байт.
• Адрес источника — это поле которое содержит 6 или 2 байта MAC-адреса узла отправителя. Первый бит всегда является — 0.
• Длина — поле которое имеет размер 2 байта, и содержит длину поля данных в кадре.
• Поле данных — поле может иметь от 0 до 1500 байт. Но если вдруг данные занимают меньше 46 байт, то используется поле заполнителя , который дополняет поле до 46 байт.
• Поле заполнителя — Обеспечивает заполнение поля данных, если там вес меньший 46 байт. Нужен для корректной работы механизму обнаружений коллизий.
• Поле контрольной последовательности кадра — в этом поле записывается контрольная сума размером в 4 байта. Используется алгоритм CRC-32/

Этот кадр есть кадр подуровня MAC, в его поле данных влажуется кадр подуровня LLC с удаленными флагами в конце и начала кадра который передается через .

Кадр Raw 802.3/Novell 802,3

Раньше этот кадр был протоколом сетевого уровня в ОС MetWare. Но теперь, когда нужда в идентификации протокола верхнего уровня отпала, то кадр был инкапсулирован в кадр MAC кадра LLC.

Кадр Ethernet DIX/Ethernet II

Этот кадр имеет структуру, которая похожа на структуру Ras 802,3. Но 2-байтовое поле длины здесь имеет назначения поля типа протокола. Указывает тип протокола верхнего уровня, вложившей свой пакет в поле данных этого кадра. Различают эти кадры по длине поля, если значении меньше 1500 то это поле длины, если больше — то типа.

Кадр Ethernet SNAP

Кадр появился в результате устранения разнобоя в кодировках типов протоколов. Протокол используется также в протоколе IP при инкапсуляции следующих сетей: Token Ring, FDDI, 100VC-AnyLan. Но при передаче IP пакетов через Ethernet протокол использует кадры Ethernet DIX.

Протокол IPX

Этот протокол может использовать все четыре типа кадра Ethernet. Он определяет тип по проверки отсутствия или наличия поля LLC. Также за полями DSAP/SSAP. Если значение полей равны 0хАА, то это кадр SNAP иначе это 802,3/LLC.