ПРОТОКОЛ LLC
В основу протоколу LLC покладено протокол HDLC (High-level Data Link Control Procedure), що широко використовується в територіальних мережах. Протокол LLC забезпечує для технологій локальних мереж потрібну якість транспортної служби, передаючи свої кадри або датаграмним способом, або за допомогою процедур із встановленням з'єднання і відновленням кадрів. Протокол LLC займає рівень між мережевими протоколами і протоколами рівня MAC. Протоколи мережевого рівня передають через міжрівневий інтерфейс дані для протоколу LLC – свій пакет (наприклад, пакет IP, IPX чи NetBEUI), адресну інформацію про вузол призначення, а також вимоги до якості транспортних послуг, які протокол LLC повинен забезпечити. Протокол LLC вміщує пакет протоколу верхнього рівня у свій кадр, який доповнюється необхідними службовими полями. Потім через міжрівневий інтерфейс протокол LLC передає свій кадр разом з адресною інформацією про вузол призначення відповідному протоколу рівня MAC, що упаковує кадр LLC у свій кадр (наприклад, кадр Ethernet).
В основу протоколу LLC покладено протокол HDLC (High-level Data Link Control rocedure), що є стандартом ISO. Власне стандарт HDLC представляє собою узагальнення кількох близьких стандартів, характерних для різних технологій: протоколу LAP-B мереж Х.25 (стандарту, широко розповсюдженого в територіальних мережах), LAP-D, що використовується в мережах ISDN, LAP-M, і працює у сучасних модемах. У специфікації IEEE 802.2 також є декілька невеликих відмінностей від стандарту HDLC.
Три типи процедур рівня LLC.
У відповідності зі стандартом 802.2 рівень керування логічним каналом LLC надає верхнім рівням три типи процедур:
LLC1 – процедура без встановлення з'єднання і без підтвердження;
LLC2 – процедура із встановленням з'єднання і підтвердженням;
LLC3 – процедура без встановлення з'єднання, але з підтвердженням.
Цей набір процедур є загальним для всіх методів доступу до середовища, визначених стандартами 802.3 – 802.5, а також стандартом FDDI і стандартом 802.12 та технологію 100VG-AnyLAN.
Процедура без встановлення з'єднання і без підтвердження LLC1 дає користувачу засоби для передачі даних з мінімальними витратами. Це датаграмний режим роботи. Звичайно цей вид процедури використовується, коли такі функції, як відновлення даних після помилок і впорядкування даних, виконуються протоколами вищих рівнів, тому немає потреби дублювати їх на рівні LLC.
Процедура із встановленням з'єднань і підтвердженням LLC2 дає користувачу можливість встановити логічне з'єднання перед початком передачі будь-якого блоку даних і, якщо це потрібно, виконати процедури відновлення після помилок і впорядкування потоку цих блоків у рамках встановленого з'єднання. Протокол LLC2 багато в чому аналогічний протоколам сімейства HDLC (LAP-B, LAP-D, LAP-M), що застосовуються в глобальних мережах для забезпечення надійної передачі кадрів на зашумлених лініях.
У деяких випадках (наприклад, при використанні мереж у системах реального часу, що керують промисловими об'єктами), коли тимчасові витрати встановлення логічного з'єднання перед відправленням даних неприйнятні, а підтвердження про коректність прийому переданих даних необхідне, базова процедура без встановлення з'єднання і без підтвердження не підходить. Для таких випадків передбачена додаткова процедура, названа процедурою без встановлення з'єднання, але з підтвердженням LLC3.
Використання одного з трьох режимів роботи рівня LLC залежить від стратегії розробників конкретного стека протоколів. Наприклад, у стеці TCP/IP рівень LLC завжди працює в режимі LLC1, виконуючи просту роботу виділення з кадру і демультиплексування пакетів різних протоколів – IP, ARP, RARP. Аналогічно використовується рівень LLC стеком IPX/SPX.
А от стек Microsoft/IBM, створений на основі протоколу NetBIOS/NetBEUI, часто використовує режим LLC2. Це відбувається тоді, коли сам протокол NetBIOS/NetBEUI повинен працювати в режимі з відновленням загублених і спотворених даних. У такому випадку ця робота передоручається рівню LLC2. Якщо ж протокол NetBIOS/NetBEUI працює в датаграмному режимі, то протокол LLC працює в режимі LLC1. Режим LLC2 використовується також стеком протоколів SNA у тому випадку, коли на нижньому рівні застосовується технологія Token Ring.
LLC підтримує два режими передачі даних:
• операції крапка-крапка без підтвердження прийому даних;
• операції крапка-крапка з підтвердженням прийому даних.
Весь обмін інформацією між об'єктами одного рівня протоколу LLC здійснюється за допомогою кадрів, що мають наступний формат:
Адреса
Поле адреси містить значення SAPI і позначає DLCI, для якого призначений кадр, що передається, і DLCI для зустрічного потоку кадрів. Поле адреси має розмір 1 байт і використовує наступний формат:
PD
Ідентифікатор протоколу указує тип даного кадру - LLC або інший протокол. Для протоколу LLC значення даного поля повинне бути рівне 0. Якщо в отриманому кадрі PD = 1, такий кадр трактується як помилковий.
C/r
Поле C/r указує тип вмісту кадру - команда або відгук. MS передає кадрів команд з полем C/r = 0, а в кадрах відгуку встановлюється значення C/r = 1. Вузли обслуговування SGSN використовують зворотний порядок, тобто для командних кадрів C/r = 1, а для відгуків C/r = 0.
Тип кадру Напрям Значення C/r
Команда От SGSN до MS 1
Команда От MS до SGSN 0
Відгук От SGSN до MS 0
Відгук От MS до SGSN 1
XX
Зарезервовано (2 бита)
SAPI
Ідентифікатор точки доступу до сервісу (Service Access Point Identificator) позначає точку доступу, через яку LLE забезпечує для протоколу LLC доступ до процесу вищерозміщеного рівня (layer 3).
Управління Ідентифікує тип кадру. Протокол LLC використовує 4 типи кадрів:
• передача підтверджуваній інформації (формат I);
• функції контролю (supervisory) (формат S);
• передача інформації без підтвердження (формат UI)
• функції управління (формат U)
Інформація
Містить різні команди і відгуки на них.
FCS
Контрольна сума, що містить 24-бітовий CRC-код, який служить для виявлення помилок в заголовку і інформаційному полі кадру.
Структура кадрів LLC
За своїм призначенням всі кадри рівня LLC (звані в стандарті 802.2 блоками даних - Protocol Data Unit, PDU) підрозділяються на три типи - інформаційні, керуючі і ненумерованих:
Інформаційні кадри призначені для передачі інформації в процедурах з встановленням логічного з'єднання і повинні обов'язково містити поле інформації. У процесі передачі інформаційних блоків здійснюється їх нумерація в режимі ковзного вікна. Керуючі кадри призначені для передачі команд і відповідей у процедурах з встановленням логічного з'єднання, у тому числі запитів на повторну передачу перекручених інформаційних блоків.
Ненумерованих кадри призначені для передачі ненумерованих команд і відповідей, що виконують в процедурах без встановлення логічного з'єднання передачу інформації, ідентифікацію і тестування LLC-рівня, а в процедурах з встановленням логічного з'єднання - встановлення та роз'єднання логічного з'єднання, а також інформування про помилки.
Усі типи кадрів рівня LLC мають єдиний формат (рис. 1). Вони містять чотири поля:
адреса точки входу сервісу призначення (Destination Service Access Point, DSAP),
адреса точки входу сервісу джерела (Source Service Access Point, SSAP),
керуюче поле (Control)
поле даних (Data)
Кадр LLC оточеного двома однобайтових полями "Прапор", що мають значення 01111110. Прапори використовуються на MAC-рівні для визначення меж блоку. (Зазначимо, що формат кадрів LLC, за винятком поля адреси точки входу сервісу джерела, відповідає формату кадру HDLC, а також одного з варіантів протоколу HDLC - протоколу LAP-B, що використовується в мережах X.25).
Прапор (01111110)
Адреса точки входу сервісу призначення DSAP
Адреса точки входу сервісу джерела SSAP
Керуючий поле Control
Дані Data
Прапор (01111110)
рис. 1. Структура LLC-кадру стандарту 802-2
Поле даних кадру LLC призначене для передачі по мережі пакетів протоколів верхніх рівнів - IP, IPX, AppleTalk, DECnet, в окремих випадках - прикладних протоколів, коли ті не користуються мережевими протоколами, а вкладають свої повідомлення безпосередньо в кадри канального рівня. Поле даних може відображатися в керуючих кадрах і деяких ненумерованих кадрах.
Поле управління (один байт) використовується для позначення типу кадру даних - інформаційний, керуючий або ненумерований. Крім цього, в цьому полі вказуються порядкові номери відправлених і успішно прийнятих кадрів, якщо підрівень LLC працює за процедурою LLC2 з'єднання. Формат поля управління повністю збігається з форматом поля управління кадру LAP-B.
Поля DSAP і SSAP дозволяють вказати, який сервіс верхнього рівня пересилає дані за допомогою цього кадру. Програмного забезпечення вузлів мережі при отриманні кадрів канального рівня необхідно розпізнати, який протокол вклав свій пакет в поле даних надійшов кадру, для того, щоб передати витягнутий з кадру пакет потрібного протоколу для подальшої обробки. Наприклад, в якості значення DSAP і SSAP може виступати код протоколу IPX або ж код протоколу покриває дерева Spanning Tree.
Заголовок SNAP
Між заголовком LLC і полем даних LLC може використовуватися додатковий заголовок, що називається заголовком SNAP (Sub-Area Access Protocol). Додатковий заголовок SNAP використовується для надання більшої упорядкованості за умов згадування типу протоколу, який розміщує свою інформацію в поле даних кадру LLC.
Стандарт 802.2 використовує для цієї мети однобайтові поля DSAP і SSAP, у той час як рання версія протоколу Ethernet, запропонована спільно компаніями Digital, Intel і Xerox (так звана, версія Ethernet DIX), використовувала для цієї мети багатобайтових поле Type, для якого в якості стандарту де-факто застосовувалися багатобайтових коди протоколів мережевого рівня, наприклад, 0800 - для протоколу IP і т.п.
Заголовок SNAP також містить багатобайтових поле Type, призначення та формат якого збігається з призначенням з полем Type кадру Ethernet DIX. Трехбайтовий код організації (OUI) використовується для вказівки тієї організації зі стандартизації, що відповідає за числові значення поля Type. Так, числові значення поля Type для заголовка SNAP в разі використання його в кадрах Ethernet визначає комітет 802.3 IEEE, код якого дорівнює 00 00 00.
Для інших протоколів канального рівня значення кодів поля Type визначають інші організації зі стандартизації. Таким чином, при використанні додаткового заголовка SNAP досягається сумісність кадрів 802.3 з кадрами Ethernet DIX за способом кодування пакетів протоколів верхнього рівня, які переносяться в поле даних. В поля DSAP і SSAP при використанні заголовка SNAP поміщаються значення 170 (десяткове), які говорять про те, що в поле даних кадру LLC вкладений заголовок SNAP.
Тимчасова діаграма сервісів протоколу LLC
На малюнку 2 показана часова діаграма сервісів, що надаються рівнем LLC для старших рівнів. Всі примітиви, зображені на малюнку, мають такі параметри, як адреса відправника та одержувача.
При використанні сервісу без встановлення з'єднання і без підтвердження протокол LLC, отримавши запит від користувача (примітив L.DATA.request) на передачу даних, робить спробу послати дані, що супроводжують запит, використовуючи МАС-підрівень. У цьому випадку відсутнє підтвердження того, пройшла чи передача успішно чи ні. У цьому варіанті функції рівня LLC зведені до мінімуму - він використовується тільки як інтерфейс старших рівнів до MAC-рівня. При використанні цього типу сервісу використовуються тільки ненумерованих блоки.
При використанні сервісу без встановлення з'єднання, але з підтвердженням, користувач сповіщається про успішність або не успішності передачі даних (примітив L.DATA_ACK_STATUS.indication).
При використанні сервісу з одержанням відповіді використовуються наступні примітиви: Запит вмісту буфера повідомлення, керованого протоколом LLC віддаленого користувача: L.REPLY.request і L.REPLY_STATUS.indication; Оновлення вмісту буфера повідомлення, керованого протоколом LLC локального користувача: L.REPLY_UPDATE.request і L.REPLY_UPDATE_STATUS.indication.
При використанні сервісу з встановленням з'єднання перед відправленням будь-яких даних повинно бути встановлено логічне з'єднання за допомогою виконання примітиву L. CONNECT. Після того, як в рамках цього з'єднання будуть передані всі дані, з'єднання повинно бути розірвано з використанням примітиву L. DISCONNECT.
Під час фази передачі даних прийом кожного вільного від помилок блоку даних підтверджується віддаленим протоколом LLC. Це підтвердження перетвориться локальним протоколом LLC у примітив L.DATA_CONNECT.confirm і передається користувачеві.
