Технология Ethernet и кабельные сети. Форматы кадров технологии Ethernet

П – преамбула (8 байт):

· используется для синхронизации станций сети;

· содержит код 10101010 в первых семи байтах и код 10101011 в последнем байте.

АН – адрес назначения (6 байт):

· длина поля составляет 6 байт, но может быть 2 байта, если адрес установлен администратором ЛВС только для внутреннего пользования;

· старший (самый первый) бит в поле адреса (рис.3.21) указывает тип адреса (I/G – Individual/Group):

- 0 – адрес назначения является индивидуальным , т.е. кадр предназначен конкретной рабочей станции; в остальных разрядах поля адреса назначения указывается уникальный физический адрес (МАС-адрес) конкретной рабочей станции;

- 1 – адрес назначения является групповым , т.е. кадр предназначен группе рабочих станций (тогда в последующих разрядах указывается адрес конкретной группы рабочих станций), или широковещательным , если все остальные разряды равны 1, то есть кадр адресован всем рабочим станциям в ЛВС;

· второй бит в поле адреса указывает способ назначения адреса (U/L – Universal/Local):

- 0 – адрес является универсальным физическим адресом в ЛВС, т.е. адрес сетевого адаптера назначен централизованно комитетом IEEE, который распределяет между производителями сетевых адаптеров так называемые организационно уникальные идентификаторы (Organizationally Unique Identifier, OUI), размещаемые в первых трех байтах адреса, а в следующих трех байтах помещается номер сетевого адаптера, присваиваемый производителем;

- 1 – адрес локальный , т.е. назначен администратором ЛВС и используется только в пределах этой сети.

АИ – адрес источника (6 байт):

· длина поля составляет 6 байт, но, как и адрес назначения, может иметь длину 2 байта;

· старший бит первого байта (поля I/G) всегда равен 0;

· не может содержать широковещательный адрес:

FF-FF-FF-FF-FF-FF.

Тип – тип протокола (2 байта):

· идентифицирует тип протокола более высокого уровня, используемого для его передачи или приема, и позволяющего множеству протоколов высокого уровня разделять ЛВС без вникания в содержимое кадров друг друга;

· примеры значений поля «тип», идентифицирующих различные протоколы:

IP (Internet Protocol) 080016

ARP (Adress Resolution Protocol) 080616

Reverse ARP 803516

Apple Talk 809B16

NetWare IPX/SPX 813716

(здесь индекс 16 – означает шестнадцатеричное число).

Данные – поле данных (46-1500 байт):

· может иметь длину от 46 до 1500 байт.

КС – контрольная сумма:

· содержит остаток избыточной циклической суммы (Cyclic Redundancy Checksum – CRC), вычисленной с помощью полиномов типа CRC-32 для всех полей кадра: АН+АИ+Тип+Данные (без преамбулы).

Таким образом, минимальная длина кадра Ethernet (без преамбулы) 64 байта, а максимальная – 1518 байтов.

Основные отличия этого кадра от кадра Ethernet II заключаются в следующем:

1) из восьмибайтового поля преамбулы П , которое стало длиной 7 байт, выделено однобайтовое поле НО – «Начальный ограничитель кадра», которое содержит код 10101011, указывающий на начало кадра;

2) вместо поля «Тип протокола» появилось двухбайтовое поле Д – «Длина», которое определяет длину поля данных в кадре; отсутствие поля «Тип протокола» обусловлено тем, что кадр 802.3/Novell соответствует только протоколу IPX/SPX и лишь этот протокол может работать с ним;

3) поле данных может содержать от 0 до 1500 байт , но если длина поля меньше 46 байт, то используется дополнительное поле Н – «Набивка», с помощью которого кадр дополняется до минимально допустимого значения в 46 байт, если поле данных меньше 46 байт.

Таким образом, длина кадра находится в диапазоне от 64 до 1518 байт, не считая преамбулы и признака начала кадра. Важной особенностью стандарта IEEE 802.3 является возможность передачи прикладным процессом данных длиной менее 46 байтов , благодаря тому, что кадр автоматически дополняется до нужного размера пустыми символами в поле «Набивка». В стандарте Ethernet II такие ситуации рассматриваются как ошибочные.

Кадр 802.3/LLC (кадр 802.3/802.2)

Кадр 802.3/LLC (802.3/802.2) содержит те же поля, что и Raw 802.3 (рис.3.23). Отличие состоит лишь в том, что в поле данных вставляется пакет подуровня управления логическим соединением LLC (без граничных флагов), содержащий в качестве заголовка три однобайтовых поля:

· DSAP (Destination Service Access Point) – точка доступа к услугам получателя (1 байт) определяет тип протокола верхнего (сетевого) уровня получателя кадра;

· SSAP (Source Service Access Point) – точка доступа к услугам источника (1 байт) определяет тип протокола верхнего (сетевого) уровня источника кадра;

· У – управление (1 или 2 байта) – содержит информацию для управления одним из трех сервисов, предоставляемых подуровнем LLC;

Поля DSAP , SSAP и У образуют заголовок пакета LLC .

Так как поле «Управление» пакета LLC имеет длину 1 (в режиме LLC1) или 2 байта (в режиме LLC2), то максимальный размер поля данных уменьшается до 1497 или 1496 байт соответственно.

Кадр Ethernet SNAP

Кадр Ethernet SNAP (SNAP – SubNetwork Access Protocol), протокол доступа к подсетям) предназначен для устранения разнообразия в форматах кадров и в кодировках типов протоколов, сообщения которых вложены в поле данных кадров Ethernet.

Структура кадра SNAP является развитием структуры кадра 802.3/LLC за счет введения дополнительного заголовка протокола SNAP , который находится за заголовком пакета LLC и включает в себя 2 поля:

· идентификатор организации (3 байта) содержит идентификатор той организации, которая контролирует коды протоколов, указываемые в поле «тип» (коды протоколов для ЛВС контролирует IEEE, который имеет идентификатор организации, равный 000000; если в будущем потребуются другие коды протоколов, то достаточно указать другой идентификатор организации, назначающей эти коды, не меняя старые значения кодов);

· тип (2 байта) – состоит из 2-х байт и соответствует полю «Тип» кадра Ethernet II, то есть в нем используются те же значения кодов протоколов более высокого сетевого уровня.

При этом 3 поля заголовка пакета LLC в кадре Ethernet SNAP имеют вполне конкретные значения:

· DSAP

· SSAP (1 байт) всегда содержит AA16 и указывает на то, что кадр имеет формат типа Ethernet SNAP;

· управление (1 байт) содержит число 0316.

Алгоритм определения типа кадра

Практически все сетевые адаптеры Ethernet могут работать со всеми четырьмя типами кадров, автоматически распознавая их.

Поскольку для кодирования типа протокола в двухбайтовом поле «Тип/Длина» указываются значения, превышающие значение максимальной длины поля данных, равное 1500 или в шестнадцатеричной системе счисления 05DC16, кадры Ethernet II легко отличить от других типов кадров по значению этого поля. Затем проверяется наличие или отсутствие полей LLC, которые могут отсутствовать только в том случае, если за полем длины следует заголовок пакета IPX, а именно 2-байтовое поле заполненное единицами. Затем проверяются значения полей DSAP и SSAP: если они равны АА16, то это кадр Ethernet SNAP, в противном случае – кадр 802.3/LLC.

Протокол CSMA/CD

Битовый интервал – это интервал, соответствующий передаче одного бита, то есть это время между появлением двух последовательных бит.

Поскольку протокол CSMA/CD применяется в ЛВС Ethernet с пропускными способностями среды передачи данных 10 Мбит/с, 100 Мбит/с и 1 Гбит/с, использование понятия битового интервала позволяет обобщить описание протокола CSMA/CD для всех этих сетей.

При передаче данных согласно протоколу CSMA/CD станции выполняют следующие этапы.

1. Прослушивание до начала передачи.

2. Задержка передачи, если канал занят.

3. Начало передачи кадра, если канал свободен.

4. Передача кадра и прослушивание коллизий ..

Если коллизия возникла, но другие станции еще не обнаружили ее, они могут попытаться начать передачу. Кадры этих станций тогда будут вовлечены в новую коллизию. Для исключения такой ситуации вовлеченные в коллизию станции начинают передавать сигнал затора с тем, чтобы все остальные станции сегмента удостоверились в том, что линия занята. Сигнал затора – специальная последовательность из 32 бит, называемая jam-последовательностью . Станции, вовлеченные в коллизию, увеличивают на 1 свои счетчики числа попыток передачи . Станция считает, что она управляет сегментом кабеля, если ею уже передано более 64 байт . Коллизия, возникающая с кадром длиной более 64 байт, называется поздней коллизией , что обычно свидетельствует о некорректном монтаже кабельной системы, например, о том, что какой-то сегмент может быть длиннее, чем это определено спецификацией для данного типа кабельной системы.

5. Ожидание перед повторной передачей.

6. Повторная передача или прекращение работы.

При приёме данных станция, находящаяся в сети, должна выполнять следующие действия.

1. Просмотр поступающих кадров данных и обнаружение фрагментов.

2. Проверка адреса получателя.

3. Проверка целостности кадра данных.

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

· длину кадра: если кадр длиннее 1518 байт, он считается переполненным; переполненные кадры могут появляться в результате неисправностей сетевого драйвера;

· контрольную последовательность кадра с помощью циклического избыточного кода;

· если контрольная последовательность некорректна, проверяется выравненность кадра: все кадры должны содержать целое число байт (например, не 122,5 байт).

Если контрольная последовательность кадра некорректна, но кадр содержит целое число байт (корректно выровнен), считается, что имеет место ошибка контрольной последовательности.

Таким образом, проверка кадра принимающей станцией заключается в определении:

· является ли кадр фрагментом;

· не слишком ли велика его длина;

· ошибочна ли его контрольная последовательность;

· корректно ли он выровнен.

Если какая-либо проверка завершилась неудачей, кадр уничтожается

и его содержимое не передается для обработки протоколу сетевого уровня.

4. Обработка кадра.

Многосегментные ЛВС Ethernet. Условие корректности ЛВС. Расчёт времени двойного оборота (PDV). Расчёт уменьшения межкадрового интервала (PVV). Расчет показателей производительности ЛВС Ethernet. Достоинства и недостатки ЛВС Ethernet.

ЛВС Ethernet может объединять сегменты, построенные на основе разных типов кабелей: толстого или тонкого коаксиального кабеля, витой пары, волоконно-оптического кабеля. При этом количество сегментов в сети может превышать указанное ранее в соответствии с правилом «5-4-3» значение 5. Чтобы сеть Ethernet, состоящая из сегментов различной физической природы, работала корректно, необходимо выполнение четырех основных условий:

· количество станций в сети не более 1024;

· максимальная длина каждого сегмента не более величины,

определенной в соответствующем стандарте физического уровня (500 м и

185 м – соответственно для толстого и тонкого коаксиального кабеля;

100 м – для неэкранированной витой пары; 2000 м – для оптоволоконного кабеля);

· время двойного оборота сигнала (Path Delay Value, PDV) между двумя самыми удаленными друг от друга станциями сети не более 575 битовых интервала;

· сокращение межкадрового интервала (Path Variability Value, PVV) при прохождении последовательности кадров через все повторители должно быть не больше, чем 49 битовых интервала. Так как при отправке кадров конечные узлы обеспечивают начальное межкадровое расстояние в 96 битовых интервалов, то после прохождения повторителей оно должно быть не меньше, чем 96–49=47 битовых интервала.

Соблюдение этих требований обеспечивает корректность работы сети даже в тех случаях, когда нарушаются правила конфигурирования, определяющие максимальное количество повторителей и общую длину сети в 2500 м.

Условие корректности ЛВС

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

Аппаратный

Аппаратн

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

получателя

назначения

источника

отправителя

получате

(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-адреса, маску подсети и основной шлюз для каждого адаптера.

Сетевые технологии

Статья получилась довольно объёмная, рассмотренные темы - форматы 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. Определено это следующим:

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

Данные, передаваемые в сети Ethernet, разбиты на кадры. Напомним, что практически каждой сетевой технологии (независимо от ее уровня) соответствует единица передачи данных: Ethernet-кадр, АТМ-ячейка, IP-дейтаграмма и т. д. Данные по сети в чистом виде не передаются. Как правило, к единице данных «пристраивается» заголовок. В некоторых сетевых технологиях добавляется также окончание. Заголовок и окончание несут служебную информацию и состоят из определенных полей.

Так как существует несколько типов кадров, для того, чтобы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадров. Кадры могут быть четырех разных форматов, несколько отличающихся друг от друга. Базовых форматов кадров (raw formats) существует всего два - Ethernet II и Ethernet 802.3. Эти форматы отличаются назначением всего одного поля.

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

Большинство сетевых администраторов не уделяет должного внимания типам кадров Ethernet, а это может явиться источником проблем. Например, если клиентское сетевое программное обеспечение настроено на неверный тип кадра, то пользователь не сможет взаимодействовать с сервером. За типом кадра приходится особенно внимательно следить в сетях Novell NetWare, так как в новых версиях этой операционной системы тип кадра по умолчанию был изменен с 802.3 на 802.2. Кроме того, в корпоративных сетях применяются устройства от нескольких поставщиков, базирующихся на разных протоколах взаимодействия и использующих различные типы кадров.

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

Ethernet Type II

q Ethernet 802.2

Ethernet SNAP (SubNetwork Access Protocol).

Рассмотрим поля, общие для всех четырех типов кадров (рис. 3.1).

Рис. 3.1 Общий формат кадров Ethernet

Поля в кадре имеют следующие значения:

Поля «Преамбула» и «Признак начала кадра» предназначены для синхронизации отправителя и получателя. Преамбула представляет собой 7-байтовую последовательность единиц и нулей. Поле признака начала кадра имеет размер 1 байт. Эти поля не принимаются в расчет при вычислении длины кадра.

Поле «Адрес получателя» состоит из 6 байт и содержит физический адрес устройства в сети, которому адресован данный кадр. Значения этого и следующего поля являются уникальными. Каждому производителю адаптеровEthernet назначаются первые три байта адреса, а оставшиеся три байта определяются непосредственно самим производителем. Например, для адаптеров фирмы 3Com физические адреса будут начинаться с 0020AF. Первый бит адреса получателя имеет специальное значение. Если он равен 0, то это адрес конкретного устройства (только в этом случае первые три байта служат для идентификации производителя сетевой платы), а если 1 - широковещательный. Обычно в широковещательном адресе все оставшиеся биты тоже устанавливаются равными единице (FF FF FF FF FF FF).

Поле «Адрес отправителя» состоит из 6 байт и содержит физический адрес устройства в сети, которое отправило данный кадр. Первый бит адреса отправителя всегда равен нулю.

Поле «Длина/тип» может содержать длину или тип кадра в зависимости от используемого кадра Ethernet. Если поле задает длину, она указывается в двух байтах. Если тип - то содержимое поля указывает на тип протокола верхнего уровня, которому принадлежит данный кадр. Например, при использовании протокола IPX поле имеет значение 8137, а для протокола IP - 0800.

Поле «Данные» содержит данные кадра. Чаще всего - это информация, нужная протоколам верхнего уровня. Данное поле не имеет фиксированной длины.

Поле «Контрольная сумма» содержит результат вычисления контрольной суммы всех полей за исключением преамбулы, признака начала кадра и самой контрольной суммы. Вычисление выполняется отправителем и добавляется в кадр. Аналогичная процедура вычисления выполняется и на устройстве получателя. В случае, если результат вычисления не совпадает со значением данного поля, предполагается, что произошла ошибка при передаче. В этом случае кадр считается испорченным и игнорируется.

Следует отметить, что минимальная допустимая длина для всех четырех типов кадров Ethernet составляет 64 байта, а максимальная - 1518 байт. Так как на служебную информацию в кадре отводится 18 байт, то поле «Данные» может иметь длину от 46 до 1500 байт. Если передаваемые по сети данные меньше допустимой минимальной длины, кадр будет автоматически дополняться до 46 байт. Столь жесткие ограничения на минимальную длину кадра введены для обеспечения нормальной работы механизма обнаружения коллизий.

Рассмотрим более подробно форматы кадров разных типов. Тип кадра Ethernet II используется многими протоколами верхнего уровня, такими как TCP/IP, IPX и AppleTalk. Данный тип кадра был разработан фирмамиDEC, Intel и Xerox. Необходимо учитывать, что хотя данный тип кадра является наиболее широко используемым, он не одобрен организациями IEEE и ISO. Формат данного типа кадра отличается от рассмотренного выше только тем, что в поле «Длина/тип» всегда указывается тип протокола.

Сетевые операционные системы Novell NetWare 2.х и З.х (за исключением 3.12) по умолчанию используют кадрыEthernet 802.3. Хотя в названии этого типа кадра есть упоминание комитета IEEE, последний не имел никакого отношения к его разработке.

Данный тип кадра не содержит никакой информации о протоколе. Поле «Длина/тип» всегда указывает длину кадра. В результате нет стандартных методов идентификации сетевого протокола, которому принадлежит данный кадр. Однако в соответствии с концепцией фирмы Novell, только протокол IPX может использоваться с данным типом кадров. Разработана специальная последовательность действий для определения того, что именно протоколIPX был инкапсулирован в кадр данного типа.

Проверяется поле «Длина/тип». Если оно содержит значение между 0 и 1518 (05ЕЕ), то данное поле определяет длину кадра, а не тип протокола (то есть это кадр 802.3, в противном случае - кадр Ethernet II).

Проверяются следующие два байта за полем «Длина/тип». Если они содержат FFFF, это означает, что кадр принадлежит протоколу IPX, так как заголовок этого протокола всегда начинается с FFFF.

В результате стандартизации сетей Ethernet подкомитетом IEEE 802.3 появился кадр Ethernet 802.2. Этот кадр является базовым для операционных систем Novell Netware версий 3.12 и 4-х. В данном типе кадра сразу за адресом отправителя следует поле длины, имеющее такое же назначение. Кроме того, этот тип кадра содержит несколько дополнительных полей, рекомендованных подкомитетом IEEE 802.3 Эти поля располагаются за полем «Длина/тип» и имеют следующее назначение:

Поле «DSAP» указывает на используемый получателем протокол сетевого уровня. Размер поля составляет 1 байт (один бит в нем зарезервирован). Для протокола IPX значение поля равно Е0, для протоколов IP - 06, дляNetBIOS – F0.

Поле «SSAP» указывает на используемый отправителем протокол сетевого уровня. Размер данного поля составляет 1 байт (один бит зарезервирован). Обычно значение данного поля совпадает со значением поля DSAP.

Поле «Контроль» указывает на тип сервиса, требуемый для сетевого протокола. Размер данного поля составляет 1 байт. Сетевая операционная система Novell NetWare устанавливает значение данного поля в 03.

Формат кадра Ethernet 802.2 имеет некоторые недостатки, в частности он содержит нечетное число байтов служебной информации. Это не совсем удобно для работы большинства сетевых устройств. Кроме того, для идентификации протокола сетевого уровня отводится 7 бит, что позволяет поддерживать «всего» 128 различных протоколов. Кадр Ethernet SNAP, являющийся дальнейшим развитием Ethernet 802.2, содержит следующие дополнительные поля (рис. 1.6):

Поле «Код организации» имеет длину три байта и указывает на код организации (фирмы), которая присвоила значения поля «Идентификатор протокола». Если значение поля равно 000000 (а это так практически всегда, за исключением сетей AplleTalk), то поле «Идентификатор протокола» содержит значение, которое обычно помещается в поле «Длина/ тип», то есть идентификатор протокола верхнего уровня.

Поле «Идентификатор протокола» имеет длину два байта и идентифицирует протокол верхнего уровня, инкапсулированный в поле «Данные» кадра. При использовании протокола IPX это поле содержит значение 8137.

В большинстве локальных и глобальных сетей есть ограничение на максимальный размер кадра. Эту величину называют максимальной единицей передачи (MTU- maximum Transmission Unit).

В совокупности эти два поля составляют дополнительное пятибайтовое поле для идентификации протокола. Это было сделано для увеличения числа поддерживаемых протоколов.

Рис.3.2 Формат кадра Ethernet SNAP

Нужно отметить, что сетевой протокол IPX может использовать любой из рассмотренных выше четырех типов кадров, чего нельзя сказать об остальных сетевых протоколах. В таблице 3.1. приводятся протоколы, которые могут быть использованы с тем или иным типом кадра.

Таблица 3.1.

Совместимость кадров Ethernet с протоколами верхних уровней

Дальнейшее развитие технологии Ethernet

В настоящее время самой распространенной сетевой технологией является именно Ethernet. По данным IDC, в 1997 году более 80 % всех сетей были построены на базе Ethernet. Все популярные операционные системы и стеки протоколов (TCP/IP, IPX, DECNet и т. д.) поддерживают Ethernet. Причинами такого господства Ethernet в сетевом мире являются высокая надежность, доступность инструментов управления, масштабируемость, гибкость, низкая стоимость и легкость внедрения.

Технология Ethernet достаточно бурно эволюционировала с момента своего зарождения. В табл. 3.2 показана шкала эволюционного развития, представленная в формате nBASE-X (n - номинальная скорость передачи информации в Мбит/с, а Х - среда передачи). В табл. 3.3 также приведена максимально допустимая длина кабеля.

Таблица 3.3.4.

Технологии и соответствующие скорости передачи

Тип	Скорость передачи	Длина
10BASE-5	10 Мбит/с, толстый коаксиал	500м
10BASE-2	10 Мбит/с, тонкий коаксиал	185м
10BASE-T	10 Мбит/с, неэкранированная витая пара	100м
10BASE-FL	10 Мбит/с, оптоволоконный кабель	2км
100BASE-TX	100 Мбит/с, неэкранированная витая пара (2 пары)	100м
100BASE-T4	100 Мбит/с, неэкранированная витая пара (4 пары)	100м
100BASE-FX	100 Мбит/с, оптоволоконный кабель	412 м/2 км
1000BASE-SX*		260м
1000BASE-SX		500м
1000BASE-LX	1000 Мбит/с (1 Гбит/с), многомодовый оптоволоконный кабель (62.5/125 мкм)	400м
1000BASE-LX	1000 Мбит/с (1 Гбит/с), многомодовый оптоволоконный кабель (50/125 мкм)	550м
1000BASE-LX	1000 Мбит/с (1 Гбит/с), одномодовый оптоволоконный кабель (9/126 мкм)	5000м
1000BASE-CX	1000 Мбит/с, экранированный сбалансированный медный кабель	25м

Протяженность кабеля для скоростей 1 Гбит/с приведена из текущего стандарта IEEE 802.3z, находящегося в стадии утверждения.

Изначально технология Ethernet была ограничена тем, что множество пользователей конкурировали за одну полосу пропускания в 10 Мбит/с. Однако со временем были найдены интересные решения, частично снимающие эту проблему. В их основе лежит использование коммутаторов, которые в отличие от традиционных мостов имеют большое количество портов и обеспечивают передачу кадров между несколькими портами одновременно. Это позволяет эффективно применять коммутаторы и для таких сетей, в которых трафик между сегментами практически не отличался от трафика, циркулирующего в самих сегментах. Технология Ethernet после появления коммутаторов перестала казаться совершенно бесперспективной, так как появилась возможность соединить низкую стоимость устройств Ethernet с высокой производительностью сетей, построенных на основе коммутаторов. Используя технологию коммутируемого Ethernet, каждое устройство получает выделенный канал между собой и портом коммутатора. Технология коммутации прижилась в сетях очень быстро. Обеспечивая передачу данных со скоростью канала связи между различными сегментами локальной сети (иными словами, между портами коммутатора), коммутация позволяет создавать крупные сети с эффективной системой управления. Кроме того, эта технология стала толчком к созданию концепции виртуальных локальных вычислительных сетей (ВЛВС).

Однако необходимость организации магистрали сети, к которой подключаются отдельные коммутаторы, не отпала. Если множество сегментов сети работают на скорости 10 Мбит/с, то магистраль должна иметь скорость значительно большую.

В начале 90-х годов начала ощущаться недостаточная пропускная способность Ethernet. Для компьютеров на процессорах Intel 80286 или 80386 с шинами ISA (8 Мбайт/с) или EISA (32 Мбайт/с) пропускная способность сегмента Ethernet составляла 1/8 или 1/32 часть канала «память-диск» и хорошо согласовывалась с соотношением между объемом локальных и внешних данных, циркулирующих в компьютере. Теперь же у мощных клиентских станций с процессорами Pentium или Pentium Pro и шиной PCI (133 Мбайт/с) эта доля упала до 1/133, что явно недостаточно. Поэтому многие сегменты Ethernet на 10 Мбит/с стали перегруженными, время реакции серверов и частота возникновения коллизий в таких сегментах значительно возросли, еще более снижая реальную пропускную способность. В ответ на эти требования была разработана технология Fast Ethernet, являющаяся 100-мегабитной версией Ethernet.

Следует отметить, что увеличение скорости в 10 раз приводит к уменьшению максимального расстояния между узлами. Сначала было предложено простое решение задачи построения магистрали - несколько коммутаторовEthernet связывались вместе по витой паре или волоконно-оптическому кабелю - так называемая коллапсированная магистраль. Но возникла проблема, когда потребовалось связать коммутаторы, находящиеся на больших расстояниях. Она была решена с помощью организации выделенного, свободного от коллизий оптоволоконного канала связи. В этом случае коммутаторы могли связываться напрямую на расстояния до 2 км. Как видно, технология Fast Ethernet обеспечила достаточно всеобъемлющее решение для построения сетей масштаба одного или нескольких зданий. Одобрение стандарта на технологию Fast Ethernet в 1995 году стало важным событием для сообщества производителей сетевого оборудования, так как появилась гибкая, быстрая и масштабируемая технология передачи данных.

До разработки технологий коммутации и Fast Ethernet среди специалистов по сетевым технологиям господствовало мнение, что технологии ATM и FDDI будут оптимальным решением для организации магистрали сети. Однако в настоящее время технология Fast Ethernet часто конкурирует с упомянутыми технологиями в этой области. Кроме того, активно разрабатывается и внедряется технология Gigabit Ethernet.

Fast Ethernet

Идея технологии Fast Ethernet родилась в 1992 году. В августе следующего года группа производителей объединилась в организацию, названную Альянсом Fast Ethernet (Fast Ethernet Alliance - FEA). Цель этого альянса заключалась в скорейшем одобрении стандарта Fast Ethernet комитетом IEEE. В июне 1995 года все процедуры стандартизации были успешно завершены, и технология Fast Ethernet была стандартизирована в документе 802.3и.

При рассмотрении стандарта много времени уделялось сохранению метода доступа CSMA/CD. Все предложенные решения опирались на этот метод, что вполне естественно, так как он позволяет сохранить преемственность с сетями l0Base-T и l00Base-T. CSMA/CD определяет способ передачи данных по сети от одного узла к другому через кабельную систему. В модели OSI протокол CSMA/CD является частью уровня управления доступом к среде (Media Access Control, MAC). На этом уровне определяется формат, в котором информация передается по сети, и способ получения доступа сетевого устройства к сети для передачи данных. Компании HP и AT&T предложили совершенно отличный от CSMA/CD метод доступа, который был назван Demand Priority. Однако он был поддержан гораздо меньшим числом сетевых производителей. Для его стандартизации был организован новый комитет IEEE 802.12.

Стандарт Fast Ethernet определяет три модификации для работы с разными видами кабелей: 100BaseTX, 100BaseT4 и 100BaseFX. Модификации 100BaseTX и 100BaseT4 рассчитаны на витую пару, а 100BaseFX был разработан для оптического кабеля.

Стандарт 100BaseTX требует применения двух пар неэкранированных или экранированных витых пар. Одна пара служит для передачи, другая - для приема. Этим требованиям отвечают два основных кабельных стандарта: на неэкранированную витую пару категории 5 и экранированную витую пару типа 1 от IBM.

Стандарт 100BaseT4 имеет менее ограничительные требования к кабелю, так как в нем задействуются все четыре пары восьмижильного кабеля: одна пара для передачи, другая для приема, а оставшиеся две пары работают как на передачу, так и на прием. В результате в стандарте 100BaseT4 и прием, и передача данных могут осуществляться по трем парам. Для реализации сетей 100BaseT4 подойдут кабели с неэкранированной витой парой категорий 3-5 и экранированный типа 1.

Технология Fast Ethernet включает в себя также стандарт для работы с многомодовым оптоволоконным кабелем. Этот стандарт (100BaseFX) ориентирован, в основном, на применение в магистрали сети или для организации связи удаленных объектов.

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

Хотя Fast Ethernet и является развитием стандарта Ethernet, переход к 100BaseT требует некоторого изменения в топологии сети. Теоретический предел диаметра сегмента сети Fast Ethernet составляет 250 м. Это ограничение определено самой природой метода доступа CSMA/CD и скоростью передачи в 100 Мбит/с.

Для классического Ethernet время прослушивания сети определяется максимальным расстоянием, которое 512-битный кадр может пройти по сети за время, равное времени обработки этого кадра на рабочей станции. Для сетиEthernet это расстояние равно 2500 м. В сети Fast Ethernet этот же самый 512-битный кадр за время, необходимое на его обработку рабочей станцией, пройдет всего 250 м. Если принимающая станция будет удалена от передающей на расстояние свыше 250 м, то кадр может вступить в конфликт с другим кадром на линии, а передающая станция, завершив передачу, уже опоздала бы с реакцией на этот конфликт. Поэтому максимальный диаметр сети 100BaseT составляет 250 м.

Для увеличения допустимой дистанции необходимо использовать два повторителя для соединения всех узлов. В соответствии со стандартом Fast Ethernet расстояние между концентратором и рабочей станцией не должно превышать 100 м. Для установки Fast Ethernet потребуются сетевые адаптеры для рабочих станций и серверов, концентраторы 100BaseT и, возможно, некоторое количество коммутаторов 100BaseT. К моменту появления стандарта Fast Ethernet в построении локальных сетей масштаба здания сложился следующий подход - магистраль крупной сети строилась на технологии FDDI (высокоскоростной и отказоустойчивой, но весьма дорогой), а сети рабочих групп и отделов использовали Ethernet или Token Ring.

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

Данные, передаваемые в сети Ethernet, разбиты на кадры. Так как существует несколько типов кадров, для того, что бы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадра. Кадры могут быть четырех различных форматов, несколько отличающихся друг от друга. Базовых форматов кадров (raw formats) существует всего два – Ethernet II и Ethernet 802.3. эти форматы отличаются назначением всего одного поля.

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

Существует четыре основных разновидности кадров Ethernet:

Ethernet Type II

Ethernet 802.3

Ethernet 802.2

Ethernet SNAP (SubNetwork Adress Protokol).

Рассмотрим поля, общие для всех четырех типов кадров:

Рис. 11.1 – Формат кадра Ethernet

Поля в кадре имеют следующее значение:

Поле «Преамбула» и «Признак начала кадра» . Предназначены для синхронизации отправителя и получателя. Преамбула представляет собой 7-байтовую последовательность единиц и нулей. Признак начала кадра имеет длину 1 байт. Эти поля не принимаются в расчет, при вычислении длинны кадра.

Поле «Адрес получателя» . Состоит из 6 байт и содержит физический адрес устройства в сети, которому адресован данный кадр. Значения этого и следующего поля являются уникальными. Каждому производителю адаптеров Ethernet назначаются первые три байта адреса, а оставшиеся три байта определяет сам производитель. Например, для адаптеров фирмы 3Com физические адреса будут начинаться с 0020AF. Первый бит адреса получателя имеет специальное назначение, если он равен 0, то адрес конкретного устройства (только в этом случае первые три байта служат для идентификации производителя сетевой платы), а если 1 – широковещательный. Обычно в широковещательном адресе все оставшиеся биты тоже устанавливаются равными единице (FF FF FF FF FF FF).

Поле «Адрес отправителя» . Состоит из 6 байт и содержит физический адрес устройства в сети, которое отправило данный кадр. Первый бит адреса отправителя всегда равен нулю.

Поле «Длинна/тип» . Может содержать длину или тип кадра в зависимости от используемого кадра Ethernet. Если поле зает длину, она указывается в двух байтах. Если тип – то поле указывает на тип протокола верхнего уровня, которому принадлежит данный кадр. Например, при использовании протокола IPX поле имеет значение 8137, а для протокола IP – 0800.

Поле «Данные» . Содержит данные кадра. Чаще всего эта информация необходима протоколам верхнего уровня. Данное поле не имеет фиксированного размера.

Поле «Контрольная сумма». Содержит результаты вычисления контрольной суммы всех полей за исключением преамбулы, признака начала кадра и самой контрольной суммы. Вычисление производится отправителем и добавляется в кадр. Аналогичная процедура вычисления производится и на устройстве получателя. В случае, если результат вычисления не совпадает со значением данного поля, предполагается, что произошла ошибка при передаче. В этом случае кадр считается испорченным и игнорируется.

Минимально допустимая длинна всех четырех типов кадров Ethernet составляет 64 байта, а максимальна – 1518 байт. Так как на служебную информацию в кадре отводится 18 байт, то поле «Данные» может принимать значение от 46 до 1500 байт. Если передаваемые данные меньше допустимой длинны. Кадр будет автоматически дополняться до 46 байт. Эти ограничения на минимальную длину кадра введены для обеспечения нормальной работы механизма обнаружения коллизий.

Рассмотрим более подробно форматы кадров различных типов. Тип кадра Ethernet II используется многими протоколами верхнего уровня, такими как TCP/IP, IPX и AppleTalk. Данный тип кадра был разработан такими фирмами как DEC, Intel и Xerox. Необходимо учитывать, что хотя данный тип кадра и является наиболее широко используемым, он не одобрен организациями IEEE и ISO. Формат данного типа кадра отличается от рассмотренного выше только тем, что в поле «Длинна/тип» всегда указывается тип протокола.

Сетевые операционные системы Novell Net Ware 2.x и 3.x (за исключением 3.12) по умолчанию используют кадр Ethernet 802.3. Хотя в названии этого кадра есть упоминание комитета IEEE, последний не имел никакого отношения к его разработке.

Данный тип кадра не содержит никакой информации о протоколе. Поле «Длинна/тип» всегда указывает длину кадра. В результате нет стандартных методов идентификации сетевого протокола, которому принадлежит данный кадр. Однако в соответствии с концепцией фирмы Novell, только протокол IPX может использоваться с данным типом кадров. Разработана специальная последовательность действий для определения того, что именно протокол IPX был инкапсулирован в кадр данного типа.

Проверяется поле «Длинна/тип». Если оно содержит значение между 0 и 1518 (05ЕЕ), то данное поле определяет длину кадра, а не тип протокола (то есть это кадр Ethernet 802.3, в противном случае – Ethernet II).

Проверяются следующие два байта за полем «Длинна/тип». Если они содержат FFFF, это означает, что кадр принадлежит протоколу IPX, так как заголовок этого протокола всегда начинается с FFFF.

В результате стандартизации сетей Ethernet подкомитетом IEEE 802.3 появился кадр Ethernet 802.2. этот кадр является базовым для операционных сиcтем Novell Net Ware 3.12 и 4.x. В данном типе кадра сразу же за полем адреса отправителя следует поле длинны, имеющее такое же назначение. кроме того, этот тип кадра содержит несколько дополнительных полей, рекомендованных IEEE 802.3. Эти поля располагаются за полем «Длинна/тип» и имеют следующее значение:

Поле «DSAP» указывает на используемый получателем протокол сетевого уровня. Размер поля составляет 1 байт (один бит в нем зарезервирован). Для протокола IPX значение поля равно E0, для протоколов IP – 06, для NetBIOS – F0.

Поле «SSAP» указывает на используемый отправителем протокол сетевого уровня. Размер поля составляет 1 байт (один бит из которого зарезервирован).

Поле «Контроль» указывает на тип сервиса, требуемый для сетевого протокола. Размер данного поля составляет 1 байт.

Формат кадра Ethernet 802.2 имеет некоторые недостатки, в частности он содержит нечетное число байт служебной информации. Это не совсем удобно для работы большинства сетевых устройств. Кроме того, для идентификации протокола сетевого уровня отводится 7 бит, что позволяет поддерживать всего 128 различных протоколов. Кадр Ethernet SNAP, являющийся развитием спецификации Ethernet 802.2 содержит следующие дополнительные поля:

Поле «Код организации» имеет длину три байта и содержит код организации (фирмы), которая присвоила значения поля «Идентификатор протокола». Если значение поля равно 000000, то поле «Идентификатор протокола» содержит значение, которое обычно помещается в поле «Длинна/тип», то есть идентификатор протокола верхнего уровня.

Поле «Идентификатор протокола» имеет длину два байта и идентифицирует протокол верхнего уровня, инкапсулированный в поле «Данные» кадра. При использовании протокола IPX это поле содержит значение 8137.

В совокупности эти два поля составляют дополнительное пяти байтовое поле для идентификации протокола. Это было сделано для увеличения числа поддерживаемых протоколов.