Те, кто работает с ОС Unix, возможно, даже не знают, что существует несколько различных типов кадров (или фреймов) которые могут "бегать" между ethernet'овскими карточками (и нести в себе пакеты более высокого уровня - IP, IPX и т.п.). Потому, что для TCP/IP, который (которые) являются основным (и, часто, единственным) сетевым протоколом в Unix, используется как правило только один тип кадра.
А те, кто так или иначе сталкивался с сетями от Novell, использующими протокол IPX, знают, что система Novell NetWare может "упаковывать" свои данные в различные кадры: Ethernet_II, 802.3, 802.2, 802.2-SNAP.
Однако, как я заметил, многие не представляют себе, чем эти кадры отличаются и, поэтому, не всегда знают - какой из них предпочесть, и чем это им грозит.
Немного истории. Технология и первые стандарты на Ethernet были разработаны компанией Xerox Corporation в 1970 году. Поэтому, первоначально, это был просто производственный стандарт одной из фирм, производящих сетевое оборудование, не "узаконенный" никаким комитетом по стандартам.
Идея оказалась удачной, и через некоторой время (в 1980) похожий
стандарт был принят IEEE (Институт инженеров по электротехнике и
радиоэлектронике), который является "законодателем" в области
стандартов на локальные компьютерные сети. (Этот Институт
разрабатывает и другие стандарты, но в данном случае речь именно о
локальных сетях). Стандарт этот назывался IEEE 802.3.
Примерно в это же время, группа фирм, производителей сетевых
карточек, в которую входили - та же Xerox Corporation, DEC и Intel.
Доработали промышленный стандарт Ethernet, который стал называться
"Ethernet версия 2", или просто Ethernet-II.
Конечно, эти стандарты определяли не только формат кадра, а все процедуры взаимодействия карточек друг с другом. То, что называется CSMA/CD - "множественный доступ (к шине) с контролем передачи и обнаружением конфликтов". Так вот, совпадая почти по всем деталям, эти два стандарта отличаются форматом кадра, передаваемого между карточками. Точнее одним полем в заголовке кадра.
По стандарту Ethernet-II, заголовок кадра выглядит так
| адрес получателя | адрес отправителя | тип "вложенного" пакета | ...
6 байт 6 байт 2 байта
А по стандарту IEEE 802.3
| адрес получателя | адрес отправителя | длина "вложенного" пакета | ...
6 байт 6 байт 2 байта
"Тип пакета" в стандарте Ethernet-II - это стандартный номер,
присвоенный протоколам более высокого уровня. Например, IP имеет номер
0x0800, IPX - 0x8137, AppleTalk - 0x809b и т.д.
Если стандарт на ethernet от IEEE называется IEEE 802.3, то откуда же взялись 802.2 и 802.2-SNAP ?
Чтобы прояснить этот вопрос, придется поближе познакомиться с тем,
Собственно стандартами по локальным вычислительным сетям занимается один из комитетов, образованных при IEEE. Этот комитет (как это принято в IEEE) имеет свой номер - 802.
Естественно, технологии локальных сетей не исчерпываются одним Ethernet'ом. Поэтому "Комитет 802" делится на подкомитеты (802.1, 802.2, 802.3 и т.д.) каждый из которых занимается своим кругом вопросов, связанных с локальными сетями. Как можно догадаться, Ethernet'ом занимается подкомитет 802.3. (Кстати, подкомитет 802.4 занимается технологией "общая шина с передачей полномочий", а подкомитет 802.5 - технологией "передача полномочий по кольцу", которой соответствует промышленный стандарт "Token Ring").
В отличии от "семиуровневой модели OSI-ISO", в которой
Таким образом, если в "модели OSI-ISO" данные, которыми обмениваются прикладные программы, "вкладываются" в пакеты транспортного уровня, которые, в свою очередь "вкладываются" в пакеты сетевого уровня, которые, в свою очередь, "вкладываются" в пакеты канального уровня. То по стандартам IEEE данные прикладных программ должны "размещаться" в пакетах LLC, которые, в свою очередь "вкладываются" в MAC-пакеты.
(Некоторые сложности возникают, когда пытаются совместить эти две модели - модель локальных сетей от IEEE и модель "глобальных" сетей OSI-ISO. Обычно считают, что MAC и LLC - это "подуровни" в модели OSI-ISO, на которые "распадается" канальный уровень. С точки зрения "что во что вкладывается" это, конечно, правильно. Но, не надо забывать, что это две различные модели, которые не всегда надо "смешивать" в одну).
Так вот. Подкомитет 802.2 как раз и занимается стандартизацией уровня (или подуровня) LLC. И, в частности, им разработан формат кадра LLC или IEEE 802.2 (понятно, что весь стандарт на уровень "управления логическим каналом" не исчерпывается только форматом кадра LLC).
Если теперь вернутся к 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". Для этого придется опять углубится в технические детали и рассмотреть структуру кадра LLC.
Его заголовок состоит из трех байт, каждый из которых представляет собой отдельное (по своему смыслу) поле
DSAP | SSAP | Control | .... 1 байт 1 байт 1 байт
Последнее поле (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.
"Фрейм" Ethernet_II означает, что заголовок будет выглядеть
"кому" | "от кого" | 8137 | ... IPX-пакет ... \________________________/ Заголовок Ethernet-II
"Фрейм" 802.3 означает, что IPX-пакет вкладывается просто в MAC-кадр (и LLC кадр просто отсутствует)
"кому" | "от кого" | длина пакета | FFFF ... IPX-пакет ...
\________________________________/
Заголовок IEEE 802.3
это очень нехорошее решение (не использовать LLC пакет), поскольку
подразумевает, что на этом сегменте ethernet не "бегают" никакие другие
протоколы, кроме IPX. Для того, чтобы не вводить в заблуждение драйверы,
которые ожидают нормального LLC-кадра, Novell пожертвовал первым полем
(двухбайтовым) в IPX пакете. Если IPX-пакет размещается прямо в MAC-кадре,
он должен начинаться с кода FFFF, при этом подразумевается, что LLC-кадр
не может в полях DSAP/SSAP содержать такой код.
"Фрейм" 802.2 означает, что внутри MAC-кадра, как и положено, находится еще LLC-кадр, а в нем уже лежит IPX-пакет
"кому" | "от кого" | длина пакета | E0 | E0 | 03 | ... IPX-пакет ...
\________________________________/ \____________/
Заголовок IEEE 802.3 Заголовок 802.2
обратите внимание, что для IPX поля DSAP и SSAP имеют значение 0xE0
(по договоренности с IEEE), а поле Control всегда содержит код 03.
Ну и, наконец, "фрейм" 802.2-SNAP для IPX выглядит
"кому" | "от кого" | длина | AA | AA | 03 | 000000 | 8137 | ... IPX-пакет ...
\_________________________/ \____________/ \_____________/
Заголовок IEEE 802.3 Заголовок 802.2 SNAP-расширение
"кому" | "от кого" | 0800 | ... IP-пакет ... \________________________/ Заголовок Ethernet-IIКстати, протокол ARP, с помощью которого машины выясняют между собой соответствия между IP и ethernet'овскими адресами, имеет свой номер - 0806. И, соответственно, заголовок кадра для этого протокола будет
"кому" | "от кого" | 0806 | ... ARP-пакет ... \________________________/ Заголовок Ethernet-IIКроме того, теоретически, IP (и ARP) пакеты можно передавать в кадрах 802.2-SNAP. Тогда, для IP, например, заголовок будет выглядеть
"от кого" | "кому" | длина | AA | AA | 03 | 000000 | 0800 | ... IP-пакет ...
\_________________________/ \____________/ \_____________/
Заголовок IEEE 802.3 Заголовок 802.2 SNAP-расширение
Но я не знаю - делает ли так кто-нибудь где-нибудь.
Надо заметить, что весь этот "зоопарк" вполне может уживаться на одном сегменте.
Во-первых, все стандартные номера протоколов, которые используются в Ethernet-II, имеют значения больше чем максимальная длина пакета, который может быть "вложен" в ethernet'овский кадр (0x05bc). Благодаря этому, "грамотный" драйвер просто проверяет соответствующее поле в заголовке кадра и если его значение меньше чем 0x05bc, то это длина "вложенных" данных и, следовательно, ему попался MAC-кадр 802.3, а если больше, то это номер протокола "вышележащего" уровня и он имеет дело с кадром Ethernet-II.
Во-вторых, если уж это оказался кадр 802.3, то разновидность "вложения" можно легко определить по его первым двум байтам.
Проще сказать - что хуже.
Однозначно - не надо пользовать "просто 802.3". Он не подразумевает "многопротокольность" и, кроме того, IPX-пакеты, упакованные в него, не имеют контрольной суммы.
Не стоит, также, использовать 802.2-SNAP. Причина простая - заголовок LLC-кадра значительно длиннее, а выгоды (в большинстве случаев) никакой.
Что касается оставшихся двух типов, то это вопрос сложный. Конечно, Ethernet-II наиболее "многопротокольный", то есть может служить оболочкой и для IP, и для IPX (и других). В связи с этим, он "более приятен" Юниксам (хотя это - смотря какой Юникс).
С другой стороны 802.2 тоже не плох (для IPX). Кроме того, я встречал утверждения, что если IP и IPX "рассовать" по разным кадрам (IP в Ethernet-II, а IPX в 802.2), то драйверам будет легче разбираться "кто есть кто" и это несколько ускорит обработку пакетов драйверами.
Короче, однозначно ответить на этот вопрос можно только в конкретной ситуации. Особенно, если ставятся дополнительные условия. Например
На всякий случай, все, что написано выше было почерпнуто из следующих источников