Типы кадров 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.

Рисунок 1.

Базовые пакеты Ethernet II и IEEE 802.3 имеют одинаковую структуру. Их различие - в назначении 13-го и 14-го байтов: поля типа протокола и длины кадра соответственно. Совместное использование разных форматов кадров в одном сегменте Ethernet возможно благодаря тому, что тип протокола характеризуется числом, большим 0x05FE.

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

В случае обычных адресов первые три байта служат для идентификации производителя сетевой платы, а последние три байта составляют уникальный номер конкретной платы. Так, первые три байта адреса популярных сетевых плат производства 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 32 +x 26 +x 23 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +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, и он выделил следующие номера:

Поля 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.

(1x1)

Рисунок 3.

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

Если нет, следует продолжить проверку. Если первые два байта равны 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 - ПРОТОКОЛЫ И СООТВЕТСТВУЮЩИЕ ТИПЫ КАДРОВ

.
Сегодня постараемся разобраться в Ethernet кадре .

В сетевых технологиях, различают такие понятия как фрейм (frame ) и пакет packet . Новички сетевых технологий, часто делают ошибки в использовании этих терминов и считают что эти термины являются синонимами, но это не так.

Давайте определимся, что же называют фреймами, а что называют пакетами.

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

Пакетами в свою очередь часто описывают Layer 3 заголовок вместе с данными. (так же инкапсулированы могут быть заголовки вышестоящих уровней), но уже без заголовка Layer 2 и концевика (trailer).

Используя знания, полученные в предыдущих статьях, мы знаем, что hub это устройство первого уровня (то есть устройство не знает ни о какой информации, оно не знает о Layer 2 заголовках, и тем более уж о Layer 3).
Но, в то же время, обычно это Layer 2 устройство (то есть оно понимает заголовок Layer 2 Header) и исходя из этого может делать некоторые действия (например брать MAC адрес получателя, искать к какому порту этот MAC-адрес привязан и отправлять фрейм только туда и никуда больше). Так же существуют и Layer 3 коммутаторы.

Итак, спецификация .

Давайте поговорим о ней. Какие они были, какие они сейчас.

Первым основателем Ethernet спецификации стала такая компания как DIX , на самом деле это группа компаний: Digital Equipment Corp, Intel , Xerox.
В начале 1980х годов, IEEE стандартизировала технологию Ethernet. Эта технология разделялась на две части:

1. 802.3 Media Access Control (MAC)
2. 802.2 Logical Link Control (LLC)

Существует несколько версий Ethernet фрейма, давайте рассмотрим их.

Теперь разберем поля поподробнее.

1. Preamble — преамбула, существует во всех версиях Ethernet кадра. Но есть некоторые отличия.Эти отличия есть между DIX версией и остальными. В DIX версии, это поле занимало 8 байт.
   Вообще, что такое преамбула вообще? Это некая совокупность 0 и 1, которая используется для синхронизации. То есть говорит ресиверу, что будет принят ethernet кадр.

   В DIX преамбула была 8 байт, семь первых байтов содержало последовательность 10101010 и так семь раз (7 байт), последний 8-ой байт выглядел так: 10101011.
   В 802.3 преамбула стала 7 байт, которые так содержало последовательность 10101010 (7 раз, 7 байт) и было добавлено еще одно поле, которое назвали SD (Start of Frame Delimiter), что означает: начало ethernet кадра.
   Собственно тоже самое что и в DIX реализации, только выделено дополнительное поле. Вместо одного как в DIX’е.

2. Destination address — адрес получателя. MAC адрес. — 6 байт.
3. Source address — адрес отправителя. MAC адрес. — 6 байт.
4. Length — длина фрейма. Это поле указывает на размер фрейма целиком, для того, чтоб получатель мог «предсказать» окончание пакета. Размер поля 2 байта.
5. Data — непосредственно сами данные, их размер может варьироваться от 46 до 1500 байт.
6. FCS — проверка целостности фрейма.Эти поля относятся к первой части 802.3 Ethernet — MAC.
   Так же присутствует как мы помним и вторая часть LLC, давайте рассмотрим ее поля.
7. DSAP — Destination Service Access Point. 1 байтовое поле. Это точка доступа к сервису системы получателя, которая указывает на то, в каком месте системы получателя буферов памяти следует разместить данные фрейма.
8. SSAP — Source Service Access Point — так же 1 байтовое поле. Это точка доступа к сервису системы отправителя, которая указывает на то, в каком месте системы отправителя буферов памяти следует разместить данные фрейма.
9. Control — Управление. Размер поля 1-2 байта. Это поле указывает на тип сервиса, который необходим для данных. В зависимости от того, какой сервис нужно предоставить, поле может быть как 1 так и 2 байта.
10. Заголовок SNAP — занимает 5 байт. Состоит из двух полей — OUI и TYPE. При приеме данных, приемник должен знать, какой из сетевых протоколов должен получить входящие данные (например, IP). Для этого и предназначено набор этих полей SNAP — Sub Network Access Protocol (протокол доступа к подсетям).
11. OUI — Код организации, 3 байта. Идентификатор организации или производителя. Совпадает с первыми 3-мя байтами MAC адреса отправителя.
12. TYPE — Локальный код. Поле длиной 2 байта. Функцианально это тоже самое что и Ethertype в заголовке Ethernet II.

Как же может устройство определить, какой тип ethernet кадра принимается?

Ведь существует DIX формат (Ethernet II), 802.3 и 802_3 с SNAP ?

Все очень просто. Давайте рассмотрим алгоритм определения.

1. Устройство получает фрейм. Смотрит на поле Lenght/Type (помним, оно занимает 2 байта). Если значение больше чем 1518 байт (размер всего фрейма с заголовками), то это уже не Ethernet II , а 802.3 или 802.3 SNAP, потому как только в Ethernet II указывается размер в указанном поле.
2. Допустим Lenght/Type у нас больше 1518 (0x5FE).
   Здесь нам нужно определить, какой фрейм 802.3 или 802.3 SNAP. Это делается на основе заголовка LLC (802.2), таких как DSAP,SSAP и SNAP. Заметим, что SNAP это расширение заголовков DSAP и SSAP (Сервисов стало настолько много, что в 1 байте не удавалось закодировать тот или иной сервис и пришлось создавать еще одну реализацию, которая называется 802.3 SNAP).
   SSAP и DSAP обычно принимают одно и тоже значение. Поле Control принимает обычно значение 0x03, что означает, что нет необходимости устанавливать соединение на канальном уровне (Layer 2).

И все же, как определить какой формат Ethernet передается, 802.3 или 802.3 SNAP?

Если передается кадр с SNAP, то значение первого и второго байта данных (по сути это наши SSAP и DSAP) равны 0xAA, а третьего (по сути нашего Control) равняется 0x03.

Вот такой алгоритм работает при том, как определить какой формат кадра передается на приемник.

По формату кадров пока все.

Сейчас немного поговорим о адресации на канальном уровне, так же называемой Mac — адресацией.

На канальном уровне, адресация проходит по MAC адресам (помните, когда рассматривали ethernet кадр, первые поля были Destination Address и Source Address, которые занимали 6 байт). Эти адреса имеют 48 битный формат и записываются в 16-ом виде.

Тут стоит отметить тот факт, что, существуют юникастовые рассылки (грубо говоря точка-точка), а существуют множественные рассылки (от одного к нескольким). Это определяется по первому биту MAC адреса, если этот бит равен 1, то это значит что осуществляется множественная рассылка (например широковещательная рассылка, такой адрес имеет все единицы), если первый бит равен «0», юникастовая рассылка.

Mac адрес состоит как бы из двух частей. Первые три байта прикреплены к той или иной компании, которая производит сетевые устройства, тоесть например устройства имеет определнные 3 байта одинаковые (некоторые компании имеют не один такой адрес, а целый пул адресов), а вторые 3 байта, это непосредственно уникальный адрес сетевого устройства.

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

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

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

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

Рис. 1. Формат кадра Ethernet DIX (II)

Первые два поля заголовка отведены под адреса:

DA (Destination Address) - МАС-адрес узла назначения;

SA (Source Address) - МАС-адрес узла отправителя. Для доставки кадра достаточно одного адреса - адреса назначения; адрес источника помещается в кадр для того, чтобы узел, получивший кадр, знал, от кого пришел кадр и кому нужно на него ответить. Принятие решения об ответе не входит в компетенцию протокола Ethernet, это дело протоколов верхних уровней. Ethernet же только выполнит такое действие, если с сетевого уровня поступит соответствующее указание.

Поле Т (Туре, или EtherType) содержит условный код протокола верхнего уровня, данные которого находятся в поле данных кадра, например шестнадцатеричное значение 08-00 соответствует протоколу IP. Это поле требуется для поддержки интерфейсных функций мультиплексирования и демультиплексирования кадров при взаимодействии с протоколами верхних уровней.

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

Поле контрольной последовательности кадра (Frame Check Sequence, FCS) состоит из 4 байт контрольной суммы. Это значение вычисляется по алгоритму CRC-32.

Кад р Ethernet DIX (II) не отражает разделения канального уровня Ethernet на уровень MAC и уровень LLC: его поля поддерживают функции обоих уровней, например интерфейсные функции поля Г относятся к функциям уровня LLC, в то время как все остальные поля поддерживают функции уровня MAC.

Существуют еще три стандартных формата кадра Ethernet:

• Кадр 802.3/LLC является стандартом комитета IEEE 802 и построен в соответствии с принятым разбиением функций канального уровня на уровень MAC и уровень LLC. Поэтому результирующий кадр является вложением кадра LLC, определяемого стандартом 802.2, в кадр MAC, определяемого стандартом 802.3.
• Кадр Raw 802.3, или Novell 802.3, появился в результате усилий компании Novell по ускорению разработки своего стека протоколов в сетях Ethernet.
• Кадр Ethernet SNAP стал результатом деятельности комитета 802.2 по приведениюпредыдущих форматов кадров к некоторому общему стандарту и приданию кадру необходимой гибкости для учета в будущем возможностей добавления полей или изменения их назначения.

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