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

Несмотря на наличие стандарта, кадры Ethernet отличаются друг от друга своим форматом.

Как и на производстве, кадры в сети 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.

ETHERNET II

Несмотря на то что мы привычно называем стандарт 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) (см. Рисунок 1). При передаче каждого байта адреса младшие биты (крайние справа) передаются первыми. В адресе получателя первый передаваемый бит (бит 0 байта 0) указывает тип адреса - обычный или групповой. Таким образом, нечетный первый байт адреса получателя означает, что кадр предназначен группе станций. Разновидностью многоадресной передачи является широковещательная передача. В этом случае все биты адреса получателя задаются равными 1.

Однако поле адреса отправителя должно содержать адрес конкретной станции-отправителя.

В случае обычных адресов первые три байта служат для идентификации производителя сетевой платы, а последние три байта составляют уникальный номер конкретной платы. Так, первые три байта адреса популярных сетевых плат производства 3Com выражаются следующим числом - 02608С в шестнадцатеричной системе счисления (далее для обозначения чисел в шестнадцатеричной системе счисления мы будем использовать обозначение 0x, т. е. идентификатор 3Com будет иметь вид 0x02608C). Адрес получателя называется также физическим или MAC-адресом.

Вообще говоря, адрес получателя идентифицирует непосредственного, а не конечного получателя, например маршрутизатор в сети Ethernet. Конечный получатель идентифицируется с помощью высокоуровневых протоколов. В случае TCP/IP - это IP-адрес станции и TCP- или UDP-порт процесса на данной станции.

Поле типа протокола идентифицирует высокоуровневый протокол, такой как IP, AppleTalk и т. д., контейнером для пакета которого служит кадр. Ниже мы приводим значения поля типа протокола для некоторых распространенных сетевых протоколов:

Internet Protocol (IP) - 0x0800;

Address Resolution Protocol (ARP) - 0x0806;

AppleTalk - 0x809B;

Xerox Network System (XNS) - 0x0600;

NetWare IPX/SPX - 0x8137.

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

В отличие от служебных полей, поле данных имеет переменную длину, причем оно не может быть короче 46 байт и длиннее 1500 байт. Таким образом, общая длина кадра без учета преамбулы и начального ограничителя кадра находится в диапазоне от 64 до 1518 байт. В случае, когда реальный объем передаваемых данных меньше 46 байт (например, для эмуляции терминала часто передается всего один символ, вводимый с клавиатуры), поле данных дополняется до минимального размера заполнителем. Байт заполнения может вставляться, даже если объем передаваемых данных более 46 байт. По предложению Novell, в случае нечетного количества байт драйвер сетевой платы добавляет еще один. Это сделано потому, что некоторые старые маршрутизаторы не понимают кадры нечетной длины.

Последнее поле в кадре - это четырехбайтное поле контрольной последовательности кадра (Frame Check Sequence, FCS). Значение этого поля вычисляется на основе содержимого заголовка и данных (вместе с заполнителем, но без учета преамбулы и ограничителя) с помощью 32-разрядного циклического избыточного кода (Cyclic Redundancy Code, CRC-32) по следующей формуле (в двоичной системе счисления):

контрольная последовательность = MOD(данные/полином)

В Ethernet порождающим полиномом служит многочлен x³²+x²⁶+x²³+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1. Данный код позволяет обнаружить 99,999999977% всех ошибок в сообщениях длиной до 64 байт! Таким образом, вероятность того, что принимающая станция воспримет испорченный кадр как целый, практически равна нулю.

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

БАЗОВЫЙ ФОРМАТ КАДРА 802.3

Определяемый спецификацией 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) и однобайтное управляющее поле (см. Рисунок 2). Назначением номеров точек доступа к сервису (Service Access Point, SAP) занимается IEEE, и он выделил следующие номера:

0xE0 для Novell;

0xF0 для NetBIOS;

0x06 для TCP/IP;

AA для SNAP.

(1x1)

Рисунок 2.

Формат 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 от другого не представляет большого труда, и сделать это можно с помощью следующего простого алгоритма (см. Рисунок 3). Сначала драйвер должен проверить значение поля типа протокола/длины кадра (13-й и 14-й байты в заголовке). Если записанное там значение превышает 0x05FE (максимально возможная длина кадра), то это кадр Ethernet_II.

Если нет, следует продолжить проверку. Если первые два байта равны 0xFFFF, то это формат Ethernet_802.3 для NetWare 3.х. В противном случае это стандартный формат кадра 802.2, и нам остается только выяснить, какой из двух - обычный (Ethernet_802.2) или расширенный (Ether-net_SNAP). В случае Ethernet_SNAP значение первого, впрочем, как и второго, байта в поле данных равняется 0xAA. (Значение третьего байта равняется 0x03, но это проверять излишне.)

ЗА КАДРОМ

Разные протоколы используют разные форматы кадров (см. Таблицу 1). Однако число последних не так уж велико, и их несложно отличить один от другого. К тому же протокол TCP/IP выдвигается на доминирующую позицию не только в глобальных, но и в локальных сетях, поэтому даже Novell решила отказаться от своего протокола IPX/SPX в пользу TCP/IP в следующей версии NetWare. Это означает, что в большинстве случаев администратору сети не придется беспокоиться о том, какой формат кадров Ethernet используется. Однако, как показывает опыт, унаследованные технологии живут довольно долго, так что знание форматов кадров может представлять не только теоретический, но и практический интерес.

ТАБЛИЦА 1 - ПРОТОКОЛЫ И СООТВЕТСТВУЮЩИЕ ТИПЫ КАДРОВ