При передачі кадрів даних на канальному рівні використовуються як дейтаграмні процедури, що працюють без встановлення з'єднання (connectionless), так і процедури з попереднім встановленням логічного з'єднання (connection-oriented).
При дейтаграмній передачі кадр посилається в мережу “без попередження”, і ніякої відповідальності за його втрату протокол не несе (рис. 6.2, а). Передбачається, що мережа завжди готова прийняти кадр від кінцевого вузла. Дейтаграмний метод працює швидко, тому що ніяких попередніх дій перед відправленням даних не виконується. Однак при такому методі важко організувати в рамках протоколу відстеження факту доставки кадру до вузла призначення. Цей метод не гарантує доставку пакету.
Передача з встановленням з'єднання більш надійна, але вимагає більше часу для передачі даних і обчислювальних витрат від кінцевих вузлів.
У цьому випадку вузлу-одержувачу відправляється службовий кадр спеціального формату з пропозицією встановити з'єднання (рис. 6.2, б). Якщо вузол-одержувач згоден із цим, то він посилає у відповідь інший службовий кадр, що підтверджує встановлення з'єднання і пропонує для даного логічного з'єднання деякі параметри, наприклад ідентифікатор з'єднання, максимальне значення поля даних кадрів, що будуть використовуватися в рамках даного з'єднання, і т.п. Вузол-ініціатор з'єднання може завершити процес установлення з'єднання відправленням третього службового кадру, у якому повідомить, що запропоновані параметри йому підходять. На цьому логічне з'єднання вважається встановленим, і в його рамках можна передавати інформаційні кадри з користувальницькими даними. Після передачі деякого закінченого набору даних, наприклад визначеного файлу, вузол ініціює розрив даного логічного з'єднання, посилаючи відповідний службовий кадр.
Рис 6.2. Протоколи без встановлення з'єднання (а) із встановленням з'єднання (б).
Замітимо, що, на відміну від протоколів дейтаграмного типу, що підтримують тільки один тип кадру – інформаційний, протоколи, що працюють по процедурі з встановленням з'єднання, повинні підтримувати кілька типів кадрів – службові, для встановлення (і розриву) з'єднання, і інформаційні, що переносять власне користувальницькі дані. Логічне з'єднання забезпечує передачу даних як в одному напрямку – від ініціатора з'єднання, так і в обох напрямках.
Процедура встановлення з'єднання може використовувати для досягнення різних цілей.
Для взаємної аутентифікації або користувачів, або устаткування ( маршрутизатори теж можуть мати імена і паролі, що потрібні для впевненості в тім, що зловмисник не підмінив корпоративний маршрутизатор і не відвів потік даних у свою мережу для аналізу).
Для узгодження змінюваних параметрів протоколу: MTU, різних тайм-аутів і т.п.
Для виявлення і корекції помилок. Встановлення логічного з'єднання, ставить точку відліку для завдання початкових значень номерів кадрів. При втраті нумерованого кадру приймач, по-перше, одержує можливість побачити цей факт, а по-друге, він може повідомити передавачу, який в точності кадр потрібно передати повторно.
У деяких технологіях усі процедуру встановлення логічного з'єднання використовують при динамічному налагодженні комутаторів мережі для маршрутизації всіх наступних кадрів, що будуть проходити через мережу в рамках даного логічного з'єднання. Так працюють мережі технологій Х.25, frame relay і ATM.
Протокол LLC забезпечує для технологій локальних мереж необхідну якість послуг транспортної служби, передаючи свої кадри або дейтаграмним способом, або за допомогою процедур з встановленням з'єднання і відновленням кадрів. Протокол LLC займає рівень між мережними протоколами і протоколами рівня MAC. Протоколи мережного рівня передають через межрівневий інтерфейс дані для протоколу LLC — свій пакет (наприклад, пакет IP, IPX чи NetBEUI), адресну інформацію про вузол призначення, а також вимоги до якості транспортних послуг, яку протокол LLC повинен забезпечити. Протокол LLC розміщує пакет протоколу верхнього рівня у свій кадр, що доповнюється необхідними службовими полями. Далі через міжрівневий інтерфейс протокол LLC передає свій кадр разом з адресною інформацією про вузол призначення відповідному протоколу рівня MAC, який запаковує кадр LLC у свій кадр (наприклад, кадр Ethernet).
Кадр Ethernet
В основу протоколу LLC покладений протокол HDLC (High-level Data Link Control Procedure), що є стандартом ISO. Власне стандарт HDLC являє собою узагальнення декількох близьких стандартів, характерних для різних технологій: протоколу LAP-B мереж Х.25 (стандарту, широко розповсюдженого в територіальних мережах), LAP-D, використовуваного в мережах ISDN, LAP-M, що працює в сучасних модемах. У специфікації IEEE 802.2 також є трохи невеликих відмінностей від стандарту HDLC.
Спочатку у фірмових технологіях підрівень LLC не виділявся в самостійний підрівень, та й його функції розчинялися в загальних функціях протоколу канального рівня. Через великі розходження у функціях протоколів фірмових технологій, які можна віднести до рівня LLC, на рівні LLC довелося ввести три типи процедур. Протокол мережного рівня може звертатися до однієї з цих процедур.
Три типи процедур рівня LLC
У відповідності із стандартом 802.2 рівень управління логічним каналом LLC надає верхнім рівням три типи процедур:
LLCI — процедура без встановлення з'єднання і без підтвердження;
LLC2 — процедура з встановленням з'єднання і підтвердженням;
LLC3 — процедура без встановлення з'єднання, але з підтвердженням.
Цей набір процедур є загальним для всіх методів доступу до середовища, визначених стандартами 802.3 – 802.5, а також стандартом FDDI і стандартом 802.12 на технологію lOOVG-AnyLAN.
Процедура без встановлення з'єднання і без підтвердження LLC1 дає користувачу засоби для передачі даних з мінімумом витрат. Це дейтаграмний режим роботи. Звичайно цей вид процедури використовується, коли такі функції, як відновлення даних після помилок і впорядкування даних, виконуються протоколами вищестоящих рівнів, тому немає потреби дублювати їх на рівні LLC.
Процедура з встановленням з'єднань і підтвердженням LLC2 дає користувачу можливість встановити логічне з'єднання перед початком передачі будь-якого блоку даних і, якщо це потрібно, виконати процедури відновлення після помилок і впорядкування потоку цих блоків у рамках встановленого з'єднання. Протокол LLC2 багато в чому аналогічний протоколам сімейства HDLC (LAP-B, LAP-D, LAP-M), що застосовуються в глобальних мережах для забезпечення надійної передачі кадрів на зашумлених лініях. Протокол LLC2 працює в режимі ковзного вікна.
У деяких випадках (наприклад, при використанні мереж в системах реального часу, керуючих промисловими об'єктами), коли тимчасові витрати встановлення логічного з'єднання перед відправленням даних неприйнятні, а підтвердження про коректність прийому переданих даних необхідне, базова процедура без встановлення з'єднання і без підтвердження не підходить. Для таких випадків передбачена додаткова процедура, яка називається процедурою без встановлення з'єднання, але з підтвердженням LLC3.
Використання одного з трьох режимів роботи рівня LLC залежить від стратегії розроблювачів конкретного стека протоколів. Наприклад, у стеці TCP/IP рівень LLC завжди працює в режимі LLCI, виконуючи просту роботу витягування з кадру і демультиплексування пакетів різних протоколів — IP, ARP, RARP. Аналогічно використовується рівень LLC стеком IPX/SPX.
А стек Microsoft/IBM, заснований на протоколі NetBIOS/NetBEUI, часто використовує режим LLC2. Це відбувається тоді, коли сам протокол NetBIOS/NetBEUI повинен працювати в режимі з відновленням втрачених і спотворених даних. У цьому випадку ця робота передоручається рівню LLC2. Якщо ж протокол NetBIOS/NetBEUI працює в дейтаграмному режимі, то протокол LLC працює в режимі LLCI.
Режим LLC2 використовується також стеком протоколів SNA у тому випадку, коли на нижньому рівні застосовується технологія Token Ring.
Структура кадрів LLC Процедура з відновленням кадрів LLC2
По своєму призначенню всі кадри рівня LLC (названі в стандарті 802.2 блоками даних (Protocol Data Unit, PDU) підрозділяються на три типи – інформаційні, керуючі і ненумеровані.
Інформаційні кадри (Information) призначені для передачі інформації в процедурах із встановленням логічного з'єднання LLC2 і повинні обов'язково містити поле інформації. У процесі передачі інформаційних блоків здійснюється їхня нумерація в режимі вікна.
Керуючі кадри (Supervisory) призначені для передачі команд і відповідей у процедурах із встановленням логічного з'єднання LLC2, в тому числі запитів на повторну передачу спотворених інформаційних блоків.
Ненумеровані кадри (Unnumbered) призначені для передачі ненумерованих команд і відповідей, що виконують у процедурах без встановлення логічного з'єднання передачу інформації, ідентифікацію і тестування LLC-рівня, а в процедурах із встановленням логічного з'єднання LLC2 — встановлення і роз'єднання логічного з'єднання, а також інформування про помилки.
Усі типи кадрів рівня LLC мають єдиний формат:
| Прапорець
| Адреса точки входу служби призначення (DSAP)
| Адреса точки входу служби джерела (SSAP)
| Керуюче поле
| Дані (Data)
| Прапорець
|
Кадр LLC обрамляється двома однобайтовими полями “Прапорець”, що мають значення 01111110. Прапорці використовуються на рівні MAC для визначення границь кадру LLC. Відповідно до багаторівневої структури протоколів стандартів IEEE 802, кадр LLC вкладається в кадр рівня MAC: кадр Ethernet, Token Ring, FDDI і т.д. При цьому прапори кадру LLC відкидаються. Кадр LLC містить поле даних і заголовок, що складається з трьох полів:
адреса точки входу служби призначення (Destination Service Access Point, DSAP);
адреса точки входу служби джерела (Source Service Access Point, SSAP);
керуюче поле (Control).
Поле даних кадру LLC призначено для передачі по мережі пакетів протоколів вищестоящих рівнів — мережних протоколів IP, IPX, AppleTalk, DECnet, у рідких випадках — прикладних протоколів, коли ті вкладають свої повідомлення безпосередньо в кадри канального рівня. Поле даних може бути відсутнім у керуючих кадрах і деяких ненумерованих кадрах.
Адресні поля DSAP і SSAP займають по 1 байту. Вони дозволяють вказати, яка служба верхнього рівня пересилає дані за допомогою цього кадру. Програмному забезпеченню вузлів мережі при одержанні кадрів канального рівня необхідно розпізнати, який протокол вклав свій пакет у поле даних кадру, що надійшов, щоб передати витягнутий з кадру пакет потрібному протоколу верхнього рівня для наступної обробки. Для ідентифікації цих протоколів вводяться так звані адреси точки входу служби (Service Access Point, SAP). Значення адрес SAP приписуються протоколам у відповідності зі стандартом 802.2. Наприклад, для протоколу IP значення SAP дорівнює 0х6, для протоколу NetBIOS — OxFO. Для одних служб визначена тільки одна точка входу і, відповідно, тільки один SAP, а для інших — кілька, коли адреси DSAP і SSAP збігаються. Наприклад, якщо в кадрі LLC значення DSAP і SSAP містять код протоколу IPX, то обмін кадрами здійснюється між двома IPX-модулями, що виконуються в різних вузлах. Але в деяких випадках у кадрі LLC вказуються DSAP і SSAP, що розрізняються. Це можливо тільки в тих випадках, коли служба має кілька адрес SAP, що може бути використано протоколом вузла відправника в спеціальних цілях, наприклад для повідомлення вузла одержувача про перехід протоколу-відправника в деякий специфічний режим роботи. Цією властивістю протоколу LLC часто користується протокол NetBEUI.
| |
| |  |
Поле керування (1 чи 2 байти) має складну структуру при роботі в режимі LLC2 і достатньо просту структуру при роботі в режимі LLC1 (див. рис. 6.3).
Рис. 6.3. Структура поля керування.
У режимі LLCI використовується тільки один тип кадру — ненумерований. Поле керування цього кадру має довжину в один байт. Усі підполя поля керування ненумерованих кадрів приймають нульові значення, так що важливими залишаються тільки перші два біти поля, які використовуються як ознака типу кадру. Враховуючи, що в протоколі Ethernet при записі реалізований зворотний порядок біт у байти, то запис полів керування кадру LLCI, вкладеного в кадр протоколу Ethernet, має значення 0х03 (тут і далі префікс 0х означає шістнадцяткове представлення).
У режимі LLC2 використовуються всі три типи кадрів. У цьому режимі кадри поділяються на команди і відповіді на ці команди. Біт P/F (Poll/Final) має наступне значення: у командах він називається бітом Poll і вимагає, щоб на команду була дана відповідь, а у відповідях він називається бітом Final і говорить про те, що відповідь складається з одного кадру.
Ненумеровані кадри використовуються на початковій стадії взаємодії двох вузлів, а саме стадії встановлення з'єднання по протоколі LLC2. Поле М ненумерованих кадрів визначає кілька типів команд, якими користаються два вузли на етапі встановлення з'єднання. Нижче приведені приклади деяких команд.
Встановити збалансований асинхронний розширений режим (SABME). Ця команда є запитом на встановлення з'єднання. Вона є однією з команд повного набору команд такого роду протоколу HDLC. Розширений режим означає використання двобайтних полів керування для кадрів інших двох типів.
Ненумероване підтвердження (UA). Служить для підтвердження чи встановлення розриву з'єднання.
Скидання з'єднання (REST). Запит на розрив з'єднання.
Після встановлення з'єднання дані і позитивні квитанції починають передаватися в інформаційних кадрах. Логічний канал протоколу LLC2 є дуплексним, так що дані можуть передаватися в обох напрямках. Якщо потік дуплексний, то позитивні квитанції на кадри також доставляються в інформаційних кадрах. Якщо ж потоку кадрів у зворотному напрямку немає чи ж потрібно передати негативну квитанцію, то використовуються супервізорні кадри.
В інформаційних кадрах є поле N(S) для вказівки номера відправленого кадру, а також поле N(R) для вказівки номера кадру, якого приймач очікує одержати від передавача наступним. При роботі протоколу LLC2 використовується ковзне вікно розміром у 127 кадрів, а для їхньої нумерації циклічно використовується 128 чисел, від 0 до 127.
Приймач завжди пам'ятає номер останнього кадру, прийнятого від передавача, і підтримує змінну із зазначеним номером кадру, яого він очікує прийняти від передавача наступним. Позначимо його через V(R). Саме це значення передається в поле N(R) кадру, що посилається передавачу. Якщо у відповідь на цей кадр приймач приймає кадр, у якому номер посланого кадру N(S) збігається з номером очікуваного кадру V(R), то такий кадр вважається коректним (якщо, звичайно, коректна його контрольна сума). Якщо приймач приймає кадр із номером N(S), нерівним V(R), то цей кадр відкидається і посилається негативна квитанція Відмовлення (REJ) з номером V(R). При прийомі негативної квитанції передавач зобов'язаний повторити передачу кадру з номером V(R), а також усіх кадрів з великими номерами, що він уже устиг відіслати, користаючись механізмом вікна в 127 кадрів. До складу супервізорних кадрів входять наступні:
Відмова (REJect)\
Приймач не готовий (Receiver Not Ready, RNR),
Приймач готовий (Receiver Ready, RR).
Команда RR з номером N(R) часто використовується як позитивна квитанція, коли потік даних від приймача до передавача відсутній, а команда RNR — для уповільнення потоку кадрів, що надходять на приймач. Це може бути необхідно, якщо приймач не встигає обробити потік кадрів, що надсилаються йому з великою швидкістю за рахунок механізму вікна. Одержання кадру RNR вимагає від передавача повного припинення передачі, до одержання кадру RR. За допомогою цих кадрів здійснюється керування потоком даних, що особливо важливо для комутованих мереж, у яких немає поділюваного середовища, що автоматично гальмує роботу передавача за рахунок того, що новий кадр не можна передати, поки приймач не закінчив прийом попереднього.
