Как и на производстве, кадры в сети Ethernet решают все. Они служат вместилищем для всех высокоуровневых пакетов, поэтому, чтобы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадров Ethernet. К счастью (или к сожалению), кадры могут быть всего четырех разных форматов, и к тому же не сильно отличающихся друг от друга. Более того, базовых форматов кадров существует всего два (в английской терминологии их называют "raw formats") - Ethernet_II и Ethernet_802.3, причем они отличаются назначением всего одного поля.
Современные компьютерные сети гетерогенны по своей природе, а сетевые протоколы третьего уровня используют зачастую разные типы кадров Ethernet. Так, в старых версиях NetWare 3.х компании Novell базовым форматом по умолчанию является Ethernet_802.3, а не 802.2 или SNAP, как это предусмотрено стандартами IEEE, причем, кроме нее, этот формат больше никто не применяет. С выходом NetWare 4.х протоколы IPX/SPX используют по умолчанию стандартные кадры Ethernet_802.2, а с планируемым переводом IntranetWare на протоколы TCP/IP эта сетевая ОС будет, возможно, работать по умолчанию с кадрами Ethernet_SNAP, так как именно этот формат применяется в новейших реализациях TCP/IP. Вообще говоря, пакеты протоколов IPX/SPX могут передаваться с помощью кадров любых типов, поэтому - а также потому, что тип Ethernet_802.3 используется исключительно Novell, - в этом уроке мы будем рассматривать кадры Ethernet преимущественно с точки зрения сетей NetWare.
Несмотря на то что мы привычно называем стандарт 802.3 именем Ethernet, это не совсем правильно, так как последнее название является торговой маркой Xerox, Intel и Digital, чья технология послужила прототипом этого столь популярного стандарта. Формат Ethernet_II соответствует оригинальному формату кадров Ethernet и имеет следующий вид.
Как и всякий кадр, Ethernet_II начинается с семибайтной преамбулы, состоящей из чередующихся единиц и нулей, и однобайтного начального ограничителя кадра, в котором два младших бита равны 112, а не 102, как остальные биты в преамбуле и ограничителе. Однако, если быть более точным, в Ethernet_II преамбула не разделяется на собственно преамбулу и начальный ограничитель кадра - и это является одним из отличий Ethernet от IEEE 802.3, хотя весьма несущественным, можно сказать, схоластическим, тем более что очень часто преамбула вообще рассматривается как часть физического механизма синхронизации передающей и принимающей стороны, а не как часть кадра (поэтому на рисунках мы не будет обозначать преамбулу и начальный ограничитель).
Собственно заголовок кадра состоит из
шестибайтного поля адреса получателя (Destination
Address), шестибайтного поля адреса отправителя (Source
Address) и двухбайтного поля типа протокола (Frame Type)
(см. Рисунок 2). При передаче каждого байта адреса
младшие биты (крайние справа) передаются первыми.
В адресе получателя первый передаваемый бит (бит
0 байта 0) указывает тип адреса - обычный или
групповой. Таким образом, нечетный первый байт
адреса получателя означает, что кадр
предназначен группе станций. Разновидностью
многоадресной передачи является
широковещательная передача. В этом случае все
биты адреса получателя задаются равными 1.
Рисунок 2.
Базовые пакеты Ethernet II и IEEE 802.3 имеют одинаковую структуру. Их различие - в назначении 13-го и 14-го байтов: поля типа протокола и длины кадра соответственно. Совместное использование разных форматов кадров в одном сегменте Ethernet возможно благодаря тому, что тип протокола характеризуется числом, большим 0x05FE.
Однако поле адреса отправителя должно содержать адрес конкретной станции-отправителя.
В случае обычных адресов первые три байта служат для идентификации производителя сетевой платы, а последние три байта составляют уникальный номер конкретной платы. Так, первые три байта адреса популярных сетевых плат производства 3Com выражаются следующим числом - 02608С в шестнадцатеричной системе счисления (далее для обозначения чисел в шестнадцатеричной системе счисления мы будем использовать обозначение 0x, т. е. идентификатор 3Com будет иметь вид 0x02608C). Адрес получателя называется также физическим или MAC-адресом.
Вообще говоря, адрес получателя идентифицирует непосредственного, а не конечного получателя, например маршрутизатор в сети Ethernet. Конечный получатель идентифицируется с помощью высокоуровневых протоколов. В случае TCP/IP - это IP-адрес станции и TCP- или UDP-порт процесса на данной станции.
Поле типа протокола идентифицирует высокоуровневый протокол, такой как IP, AppleTalk и т. д., контейнером для пакета которого служит кадр. Ниже мы приводим значения поля типа протокола для некоторых распространенных сетевых протоколов:
Следующее поле кадра служит собственно для передачи полезной информации (на уровне кадра к полезной нагрузке мы относим такую служебную информацию высокоуровневых протоколов, как заголовок пакета и т. п.).
В отличие от служебных полей, поле данных имеет переменную длину, причем оно не может быть короче 46 байт и длиннее 1500 байт. Таким образом, общая длина кадра без учета преамбулы и начального ограничителя кадра находится в диапазоне от 64 до 1518 байт. В случае, когда реальный объем передаваемых данных меньше 46 байт (например, для эмуляции терминала часто передается всего один символ, вводимый с клавиатуры), поле данных дополняется до минимального размера заполнителем. Байт заполнения может вставляться, даже если объем передаваемых данных более 46 байт. По предложению Novell, в случае нечетного количества байт драйвер сетевой платы добавляет еще один. Это сделано потому, что некоторые старые маршрутизаторы не понимают кадры нечетной длины.
Последнее поле в кадре - это четырехбайтное поле контрольной последовательности кадра (Frame Check Sequence, FCS). Значение этого поля вычисляется на основе содержимого заголовка и данных (вместе с заполнителем, но без учета преамбулы и ограничителя) с помощью 32-разрядного циклического избыточного кода (Cyclic Redundancy Code, CRC-32) по следующей формуле (в двоичной системе счисления):
контрольная последовательность = MOD(данные/полином)
В Ethernet порождающим полиномом служит многочлен x32+x26+x23+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. Данный код позволяет обнаружить 99,999999977% всех ошибок в сообщениях длиной до 64 байт! Таким образом, вероятность того, что принимающая станция воспримет испорченный кадр как целый, практически равна нулю.
После приема кадра принимающая станция заново вычисляет контрольную последовательность и сравнивает полученный результат с содержимым поля FCS. В случае несовпадения пакет считается испорченным и игнорируется.
Определяемый спецификацией 802.3 формат кадра практически идентичен своему предшественнику за исключением того, что поле типа протокола имеет смысл длины кадра. На первый взгляд это неизбежно должно привести к путанице, когда кадры Ethernet_II и Ethernet_802.3 передаются между станциями в одном сегменте. Однако на практике эти кадры не представляет труда отличить друг от друга. Как мы уже говорили, длина поля данных не превышает 1500 байт, поэтому, в соответствии с принятыми соглашениями, тип высокоуровневого протокола задается большим, чем 0х05FE (1518 в шестнадцатеричной системе счисления - полная длина кадра), благо двухбайтное поле может принимать 65 536 разных значений. Таким образом, если значение поля между адресом отправителя и данными меньше или равно 1518, то это кадр 802.3, в противном случае - это кадр Ethernet_II.
Другое небольшое отличие между Ethernet и 802.3 состоит в классификации групповых адресов. В отличие от Ethernet, спецификация 802.3 подразделяет групповые адреса на имеющие глобальное и локальное значение. Однако это разделение редко используется на практике. (О третьем незначительном отличии - в преамбуле - мы говорили выше.)
В соответствии с эталонной моделью OSI, каждый протокольный блок данных содержит (инкапсулирует) пакеты вышележащих протоколов своего стека. Протокол 802.3 описывает метод доступа к среде передачи - нижний подуровень канального уровня, и для него вышележащим протоколом является протокол логического
управления каналом (Logical Link Control, LLC) - верхний подуровень канального уровня. Таким образом, согласно требованиям стандарта, поле данных должно содержать заголовок LLC. В ранних версиях NetWare компания Novell проигнорировала этот заголовок и стала помещать пакеты IPX/SPX непосредственно за полем длины кадра, и поле данных начиналось так же, как и обычный заголовок IPX, с двух байтов, состоящих из единиц (число 0xFFFF). Иными словами, Novell использовала кадры просто в качестве контейнера.
В принципе применение базового формата кадра 802.3 без служебной информации верхнего подуровня канального уровня позволяет Novell несколько сократить накладные расходы в расчете на кадр. Однако выигрыш невелик, а в гетерогенной среде применение нестандартного формата ведет к проигрышу, так как маршрутизатор или сетевая плата вынуждены проверять дополнительные поля для определения типа пакета. Это послужило одним из побудительных мотивов, почему начиная с версии 4.0 Novell перешла по умолчанию на стандартный формат Ethernet_802.2. Другой причиной было то, что использование базовых кадров Ethernet_802.3 делало невозможным применение таких опций защиты, как подпись пакетов, из-за того, что поле контрольной суммы пакета было фиксированным и равным 0хFFFF, чтобы кадр Ethernet_802.3 можно было отличить от других типов кадров.
Спецификации IEEE предусматривают всего два стандартных формата - 802.2 и 802.2 SNAP, причем второй является естественным расширением первого. Как уже говорилось, стандартный кадр должен содержать в поле данных служебную информацию логического управления каналом, а именно однобайтное поле точки доступа к сервису для получателя (Destination Service Access Point, DSAP), однобайтное поле точки доступа к сервису для отправителя (Source Service Access Point, SSAP) и однобайтное управляющее поле (см. Рисунок 3). Назначением номеров точек доступа к сервису (Service Access Point, SAP) занимается IEEE, и он выделил следующие номера:
Рисунок 3.
Формат IEEE 802.2 SNAP представляет собой расширение стандартного формата IEEE 802.2. Кадры обоих типов содержат заголовок 802.2 LLC в начале поля данных.
Поля DSAP и SSAP служат для определения вышележащего протокола и, как правило, содержат одно и то же значение. Управляющее поле обычно задается равным 0x03 (в соответствии с протоколом LLC это означает, что соединение на канальном уровне не устанавливается).
Протокол доступа к подсети (Sub-Network Access Protocol, SNAP) был разработан с целью увеличения числа поддерживаемых протоколов, так как однобайтные поля SAP позволяют поддерживать не более 256 протоколов. Формат Ethernet_SNAP предусматривает дополнительное пятибайтное поле для идентификации протокола (Protocol Identification, PI) внутри поля данных, причем значения двух последних байтов этого поля совпадают со значениями поля протокола в Ethernet_II в случае, если кадры содержат пакеты одного и того же высокоуровневого протокола, например они равны 0x8137 для NetWare.
Отличить один формат кадра Ethernet от
другого не представляет большого труда, и
сделать это можно с помощью следующего простого
алгоритма (см. Рисунок 4). Сначала драйвер должен
проверить значение поля типа протокола/длины
кадра (13-й и 14-й байты в заголовке). Если
записанное там значение превышает 0x05FE
(максимально возможная длина кадра), то это кадр
Ethernet_II. 
Рисунок 4.
Для определения типа кадра Ethernet сначала необходимо проверить значение поля после адреса отправителя, а затем первых двух байтов поля данных.
Если нет, следует продолжить проверку. Если первые два байта равны 0xFFFF, то это формат Ethernet_802.3 для NetWare 3.х. В противном случае это стандартный формат кадра 802.2, и нам остается только выяснить, какой из двух - обычный (Ethernet_802.2) или расширенный (Ether-net_SNAP). В случае Ethernet_SNAP значение первого, впрочем, как и второго, байта в поле данных равняется 0xAA. (Значение третьего байта равняется 0x03, но это проверять излишне.)
Разные протоколы используют разные форматы кадров (см. Таблицу 2). Однако число последних не так уж велико, и их несложно отличить один от другого. К тому же протокол TCP/IP выдвигается на доминирующую позицию не только в глобальных, но и в локальных сетях, поэтому даже Novell решила отказаться от своего протокола IPX/SPX в пользу TCP/IP в следующей версии NetWare. Это означает, что в большинстве случаев администратору сети не придется беспокоиться о том, какой формат кадров Ethernet используется. Однако, как показывает опыт, унаследованные технологии живут довольно долго, так что знание форматов кадров может представлять не только теоретический, но и практический интерес.
ТАБЛИЦА 2 - ПРОТОКОЛЫ И
СООТВЕТСТВУЮЩИЕ ТИПЫ КАДРОВ
Формат кадра |
Протокол |
Способ идентификации вышележащего протокола |
| Ethernet_II | DecNET, LAT, старые реализации TCP/IP | Поле типа протокола |
| 802.3 | NetWare 3.х | Первые два байта поля данных равны 0xFFFF |
| 802.2 | NetWare 4.х, LLC2 | Поле DSAP |
| SNAP | EtherTalk, новые реализации TCP/IP | Пятибайтное поле после служебной информации LLC |
 |
 |
 |
