Фреймы Ethernet.

Те, кто работает с ОС Unix, возможно, даже не знают, что существует несколько различных типов кадров (или фреймов) которые могут "бегать" между ethernet'овскими карточками (и нести в себе пакеты более высокого уровня - IP, IPX и т.п.). Потому, что для TCP/IP, который (которые) являются основным (и часто единственным) сетевым протоколом в Unix, используется как правило только один тип кадра.

А те, кто так или иначе сталкивался с сетями от Novell, использующими протокол IPX, знают, что система Novell NetWare может "упаковывать" свои данные в различные кадры: Ethernet_II, 802.3, 802.2, 802.2-SNAP.

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

• Почему они так называются?
  • Ethernet и IEEE 802.3.
  • Что такое 802.2, 802.3 и т.п.?
    • "Что и как" стандартизует IEEE.
    • Чем же занимается "подкомитет 802.2"?
    • Опять про Ethernet
    • "фрейм 802.2-SNAP"
• Так что же Novell подразумевает под своими "фреймами"?
• А куда "упаковывается" IP?
• А если много разных фреймов на одном Ethernet'е?
• Так какой же фрейм лучше?
• Список литературы.

Почему они так называются?

Ethernet и IEEE 802.3.

Немного истории. Технология и первые стандарты на Ethernet были разработаны компанией Xerox Corporation в 1970 году. Поэтому первоначально это был просто производственный стандарт одной из фирм, производящих сетевое оборудование, не "узаконенный" никаким комитетом по стандартам.

Идея оказалась удачной, и через некоторой время (в 1980) похожий стандарт был принят IEEE (Институт инженеров по электротехнике и радиоэлектронике), который является "законодателем" в области стандартов на локальные компьютерные сети. (Этот Институт разрабатывает и другие стандарты, но в данном случае речь именно о локальных сетях). Стандарт этот назывался IEEE 802.3.
Примерно в это же время, группа фирм, производителей сетевых карточек, в которую входили - та же Xerox Corporation, DEC и Intel. Доработали промышленный стандарт Ethernet, который стал называться "Ethernet версия 2", или просто Ethernet-II.

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

По стандарту Ethernet-II, заголовок кадра выглядит так:

Что такое 802.2, 802.3 и т.п.?

Если стандарт на ethernet от IEEE называется IEEE 802.3, то откуда же взялись 802.2 и 802.2-SNAP ?

Чтобы прояснить этот вопрос, придется поближе познакомиться с тем,

"Что и как" стандартизует IEEE.

Собственно стандартами по локальным вычислительным сетям занимается один из комитетов, образованных при IEEE. Этот комитет (как это принято в IEEE) имеет свой номер - 802.

Естественно, технологии локальных сетей не исчерпываются одним Ethernet'ом. Поэтому "Комитет 802" делится на подкомитеты (802.1, 802.3, 802.2, и т.д.) каждый из которых занимается своим кругом вопросов, связанных с локальными сетями. Как можно догадаться, Ethernet'ом занимается подкомитет 802.3. (Кстати, подкомитет 802.4 занимается технологией "общая шина с передачей полномочий", а подкомитет 802.5 - технологией "передача полномочий по кольцу", которой соответствует промышленный стандарт "Token Ring").

Чем же занимается "подкомитет 802.2"?

Для ответа на этот вопрос придется рассмотреть "иерархию протоколов" принятую "Комитетом 802".

В отличии от "семиуровневой модели OSI-ISO", в которой

канальный уровень

- отвечает за доставку данных между машинами, объединенными общим физическим носителем,

сетевой уровень

- отвечает за доставку данных между любыми машинами, в глобальной сети (через устройства - маршрутизаторы),

транспортный уровень

- отвечает за разбиение больших сообщений на пакеты и сборку из пакетов на "принимающей" стороне, и, в общем то, обеспечивает связь между конкретными программами (клиентами и серверами),

MAC (Media Access Control - управление доступом к среде)

- отвечает за доставку данных между машинами, объединенными общим физическим носителем(что примерно соответствует канальному уровню), и

LLC (Logical Link Control - управление логическим каналом)

- отвечает за связь между конкретными программами - "сервисами" (что примерно соответствует транспортному уровню).

Таким образом, если в "модели OSI-ISO" данные, которыми обмениваются прикладные программы, "вкладываются" в пакеты транспортного уровня, которые, в свою очередь "вкладываются" в пакеты сетевого уровня, которые, в свою очередь, "вкладываются" в пакеты канального уровня. То по стандартам IEEE данные прикладных программ должны "размещаться" в пакетах LLC, которые, в свою очередь "вкладываются" в MAC-пакеты.

(Некоторые сложности возникают, когда пытаются совместить эти две модели - модель локальных сетей от IEEE и модель "глобальных" сетей OSI-ISO. Обычно считают, что MAC и LLC - это "подуровни" в модели OSI-ISO, на которые "распадается" канальный уровень. С точки зрения "что во что вкладывается" это, конечно, правильно. Но, не надо забывать, что это две различные модели, которые не всегда надо "смешивать" в одну).

Так вот. Подкомитет 802.2 как раз и занимается стандартизацией уровня (или подуровня) LLC. И, в частности, им разработан формат кадра LLC или IEEE 802.2 (понятно, что весь стандарт на уровень "управления логическим каналом" не исчерпывается только форматом кадра LLC).

Опять про Ethernet

Если теперь вернутся к Ethernet'у, то можно сказать, что стандарт 802.3 (как и стандарты 802.4, 802.5) относятся к MAC уровню. Если посмотреть на формат кадра "IEEE 802.3", то можно заметить, что в нем указывается только - от какой машины (карточки) к какой машине (карточке), должен быть доставлен этот кадр. Никакого указания на то, пакет какого протокола верхнего уровня (IP, IPX и т.п.) в нем содержится, и, следовательно, какая программа (или драйвер) на "принимающей" стороне, должна занятся этим пакетом, вы в заголовке кадра не найдете.

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

Как я уже сказал, стандарты на LLC-уровень (и, соответственно, формат LLC-кадра) носят имя своего "родителя" - подкомитета 802.2.

Следовательно, то, что у Novell называется "фрейм 802.2" это на самом деле тот же ethernet'овский кадр 802.3 с "вложенным" в него кадром 802.2.

"фрейм 802.2-SNAP"

Осталось выяснить еще - что такое "фрейм 802.2-SNAP". Для этого придется опять углубится в технические детали и рассмотреть структуру кадра LLC.

Его заголовок состоит из трех байт, каждый из которых представляет собой отдельное (по своему смыслу) поле

Последнее поле (Control) по замыслу IEEE может содержать различные команды для установления/проверки/уничтожения "логического соединения" между программами (драйверами) на связывающихся машинах, и, соответственно, откликов на эти команды.

А вот первые два байта как раз и определяют - какие программы ("точки доступа к сервису") пытаются обменяться данными. Если мы хотим использовать различные протоколы более высоких уровней (IP, IPX, AppleTalk и т.п.), то драйверы для этих протоколов будут разными SAP'ами ("точками доступа к сервису") и, следовательно, должны иметь разные номера. Обратите внимание, что под такой номер протокола выделяется только один байт. К тому же, номера с единицей в старшем бите зарезервированы для "групповых" адресов, следовательно, возможных значений для номера протокола всего 127.

Конечно, и этого количества хватило бы, чтобы перенумеровать наиболее популярные сетевые протоколы. Но тот же IEEE уже успел присвоить этим протоколам стандартные значения в диапазоне 0x0000 - 0xFFFF. Это как раз те значения, что стоят в поле "тип пакета" в кадре Ethernet-II (IP - 0x0800, IPX - 0x8137, AppleTalk - 0x809b и т.д.).
Как же разместить эти двухбайтные номера в одном байте (DSAP или SSAP)?
IEEE решил эту проблему радикально, изобретя расширенный заголовок кадра LLC, который и назвал 802.2-SNAP (кстати, SNAP означает SubNetwork Access Protocol, хотя, в данном случае, это мало что проясняет).

Суть этого решения в том, что, если в полях DSAP и SSAP стоит определенный код (0xAA), то после третьего байта (Control), должны быть еще два поля, "расширяющие" заголовок LLC-кадра. Первое дополнительное поле из трех (!) байт должно содержать код некой организации (фирма, комитет по стандартизации и т.п.), а второе поле из двух байт - номер протокола высшего уровня, разработанного этой организацией.

Таким образом, в мире может существовать чуть более 16 млн. организаций, каждая из которых может придумать чуть более 65 тыс. различных протоколов, и им всем хватит места в расширенном заголовке кадра LLC, чтобы иметь на каждый протокол уникальный номер-идентификатор.

Кстати, IEEE взял себе номер 0x000000. То есть, если в поле "организация" все нули, то следующее двухбайтное поле, как раз, содержит те двухбайтные номера протоколов, стандартизованные IEEE.

Так что же Novell подразумевает под своими "фреймами"?

Novell NetWare может упаковывать свои IPX пакеты во все четыре типа кадров.

"Фрейм" Ethernet_II означает, что заголовок будет выглядеть

"Фрейм" 802.3 означает, что IPX-пакет вкладывается просто в MAC-кадр (и LLC кадр просто отсутствует)

"Фрейм" 802.2 означает, что внутри MAC-кадра, как и положено, находится еще LLC-кадр, а в нем уже лежит IPX-пакет

Ну и, наконец, "фрейм" 802.2-SNAP для IPX выглядит

А куда "упаковывается" IP?

А для передачи по Ethernet'у пакетов IP обычно используется только один тип кадра, а именно - Ethernet-II. То есть заголовок будет

Кстати, протокол ARP, с помощью которого машины выясняют между собой соответствия между IP и ethernet'овскими адресами, имеет свой номер - 0806. И, соответственно, заголовок кадра для этого протокола будет

Кроме того, теоретически, IP (и ARP) пакеты можно передавать в кадрах 802.2-SNAP. Тогда, для IP, например, заголовок будет выглядеть

А если много разных фреймов на одном Ethernet'е?

Надо заметить, что весь этот "зоопарк" вполне может уживаться на одном сегменте.

Во-первых, все стандартные номера протоколов, которые используются в Ethernet-II, имеют значения больше чем максимальная длина пакета, который может быть "вложен" в ethernet'овский кадр (0x05bc). Благодаря этому, "грамотный" драйвер просто проверяет соответствующее поле в заголовке кадра и если его значение меньше чем 0x05bc, то это длина "вложенных" данных и, следовательно, ему попался MAC-кадр 802.3, а если больше, то это номер протокола "вышележащего" уровня и он имеет дело с кадром Ethernet-II.

Во-вторых, если уж это оказался кадр 802.3, то разновидность "вложения" можно легко определить по его первым двум байтам.

• FFFF - простой 802.3 с IPX-пакетом внутри
• AAAA - 802.2-SNAP, то есть номер протокола надо искать дальше в расширенном заголовке
• все остальное - обычный 802.2 (не SNAP) и, следовательно, эти два байта и определяют тип вложенного пакета. Для IPX - E0E0.

Так какой же фрейм лучше?

Проще сказать - что хуже.

Однозначно - не надо пользовать "просто 802.3". Он не подразумевает "многопротокольность" и, кроме того, IPX-пакеты, упакованные в него, не имеют контрольной суммы.

Не стоит, также, использовать 802.2-SNAP. Причина простая - заголовок LLC-кадра значительно длиннее, а выгоды (в большинстве случаев) никакой.

Что касается оставшихся двух типов, то это вопрос сложный. Конечно, Ethernet-II наиболее "многопротокольный", то есть может служить оболочкой и для IP, и для IPX (и других). В связи с этим, он "более приятен" Юниксам (хотя это - смотря какой Юникс).

С другой стороны 802.2 тоже не плох (для IPX). Кроме того, я встречал утверждения, что если IP и IPX "рассовать" по разным кадрам (IP в Ethernet-II, а IPX в 802.2), то драйверам будет легче разбираться "кто есть кто", и это несколько ускорит обработку пакетов драйверами.

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

• у вас "завалялся" софт, который желает только определенный фрейм
  например, надо маршрутизировать IPX через Юникс, а он понимает только "любимый" Ethernet-II (именно так обстоят дела с FreeBSD'2.x и 3.x; FreeBSD'3.4 можно пропатчить, а FreeBSD'4.x умеет работать с IPX по всем типам фреймов);
• или "железо", которое не понимает какой-то из фреймов...

Список литературы.

На всякий случай, все, что написано выше было почерпнуто из следующих источников:

1. Internetworking Technology Overview. Cisco CD.
2. Протоколы информационно-вычислительных сетей. Справочник.М."Радио и Связь".1990.
3. Howard C.Bercowitz. How did Novell get framed?.
4. UnixFAQ.