Формати кадрів 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, хоча дуже несуттєвою, можна сказати, схоластичною, тим більше, що дуже часто преамбула взагалі розглядається як частина фізичного механізму синхронізації передавальної та приймаючої сторони, а не як частина кадру (тому на малюнках ми не буде позначати преамбулу та початковий обмежувач).

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

Поле типу протоколу ідентифікує високорівневий протокол, такий як 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

Відповідно до еталонної моделі OSI, кожен протокольний блок даних містить (інкапсулює) пакети вищележачих протоколів свого стека. Протокол 802.3 описує метод доступу до середовища передачі - нижній рівень канального рівня, і для нього вищележачим протоколом є протокол логічного

управління каналом (Logical Link Control, LLC) – верхній підрівень канального рівня. Таким чином, згідно з вимогами стандарту, поле даних має містити заголовок LLC. У ранніх версіях NetWare компанія Novell проігнорувала цей заголовок і поміщала пакети IPX/SPX безпосередньо за полем довжини кадру, і поле даних починалося так само, як і звичайний заголовок IPX, з двох байтів, що складаються з одиниць (число 0xFFFF). Іншими словами, Novell використовувала кадри просто як контейнер.

У принципі, застосування базового формату кадру 802.3 без службової інформації верхнього підрівня канального рівня дозволяє Novell дещо скоротити накладні витрати в розрахунку на кадр. Проте виграш невеликий, а гетерогенної середовищі застосування нестандартного формату веде до програшу, оскільки маршрутизатор чи мережна плата змушені перевіряти додаткові поля визначення типу пакета. Це стало одним із спонукальних мотивів, чому починаючи з версії 4.0 Novell перейшла за замовчуванням на стандартний формат Ethernet_802.2. Іншою причиною було те, що використання базових кадрів Ethernet_802.3 унеможливлювало застосування таких опцій захисту, як підпис пакетів, через те, що поле контрольної суми пакета було фіксованим і рівним 0хFFFF, щоб кадр Ethernet_802.3 можна було відрізнити від інших типів кадрів.

ДВАСТАНДАРТНИХ ФОРМАТУ

Специфікації IEEE передбачають лише два стандартні формати - 802.2 і 802.2 SNAP, причому другий є природним розширенням першого. Як мовилося раніше, стандартний кадр повинен містити у полі даних службову інформацію логічного управління каналом, саме однобайтне поле точки доступу до сервісу для одержувача (Destination Service Access Point, DSAP), однобайтне поле точки доступу до сервісу для відправника (Source Service Access Point, SSAP) та однобайтне керуюче поле (див. Рисунок 2). Призначенням номерів точок доступу до сервісу (Service Access Point, SAP) займається IEEE, і він виділив такі номери:

0xE0 для Novell; 0xF0 для NetBIOS; 0x06 для TCP/IP; AA для SNAP.

Малюнок 2. Формат IEEE 802.2 SNAP є розширенням стандартного формату IEEE 802.2. Кадри обох типів містять заголовок 802.2 LLC на початку поля даних.

Поля DSAP і SSAP служать визначення вищележачого протоколу і, зазвичай, містять одне й те значення. Керуюче поле зазвичай задається рівним 0x03 (відповідно до протоколу LLC це означає, що з'єднання на канальному рівні не встановлюється).

Протокол доступу до підмережі (Sub-Network Access Protocol, SNAP) був розроблений з метою збільшення числа протоколів, що підтримуються, так як однобайтні поля SAP дозволяють підтримувати не більше 256 протоколів. Формат Ethernet_SNAP передбачає додаткове п'ятибайтне поле для ідентифікації протоколу (Protocol Identification, PI) всередині поля даних, причому значення двох останніх байтів цього поля збігаються зі значеннями поля протоколу в Ethernet_II у разі, якщо кадри містять пакети одного і того ж високорівневого протоколу, наприклад, вони рівні 0x8137 для NetWare

АЛГОРИТМ ВИЗНАЧЕННЯФОРМАТА КАДРУ

Відрізнити один формат кадру Ethernet від іншого не становить великої праці, і зробити це можна за допомогою наступного простого алгоритму (див. рис. 3). Спочатку драйвер повинен перевірити значення поля типу протоколу/довжини кадру (13-й та 14-й байти у заголовку). Якщо записане там значення перевищує 0x05FE (максимально можлива довжина кадру), це кадр Ethernet_II.

Якщо ні, слід перевірити. Якщо перші два байти дорівнюють 0xFFFF, це формат Ethernet_802.3 для NetWare 3.х. В іншому випадку це стандартний формат кадру 802.2, і нам залишається лише з'ясувати, який із двох – звичайний (Ethernet_802.2) або розширений (Ether-net_SNAP). У разі Ethernet_SNAP значення першого, втім, як і другого, байта у даних дорівнює 0xAA. (Значення третього байта дорівнює 0x03, але це перевіряти зайве.)

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

ТАБЛИЦЯ 1 - ПРОТОКОЛИ І ВІДПОВІДНІ ТИПИ КАДРІВ

Спосіб ідентифікації протоколу