Необхідною умовою гарантованого забезпечення якості обслуговування є наявність протоколу — протоколу сигналізації, який дозволяє аплікаціям заявляти про свої QoS-вимоги, встановлювати та контролювати з’єднання зі здійсненням за необхідністю резервування потрібних мережних ресурсів уздовж розрахованого маршруту (маршрутів). Протоколи сигналізації дозволяють механізмам управління окремих вузлів обмінюватися службовою інформацією, що сприяє координації зусиль щодо забезпечення необхідних значень параметрів якості обслуговування «з кінця в кінець».

Протокол RSVP. Яскравим прикладом протоколів цієї групи є протокол RSVP (ReSerVatіon Protocol), який використовується переважно в IP-мережах і призначений для резервування мережних ресурсів для кожного потоку на всіх маршрутизаторах, через які здійснюється доставка інформації, відповідно до запитуваного рівня QoS. RSVP сигналізує про запити резервування ресурсів по доступному маршруту в мережі. При цьому значну роль у забезпеченні QoS відіграють протоколи маршрутизації, які попередньо визначають шлях, уздовж якого відбуватиметься резервування. Тому перехід від традиційної маршрутизації по найкоротшому шляху до маршрутизації, що враховує при виборі маршруту QoS-вимоги потоку та доступність мережних ресурсів уздовж усього маршруту доведення (маршрутизація з підтримкою QoS), дозволить значно підвищити можливості мережі в плані гарантованого забезпечення QoS. Саме тому маршрутизацію також необхідно розглядати як один з діючих механізмів забезпечення якості обслуговування.

Резервування ресурсів здійснюється шляхом надсилання до мережі RSVP-запитів від імені потоку даних аплікації, у яких закладена інформація про необхідний рівень QoS. Резервування здійснюється тільки в тому разі, якщо в мережі є доступні ресурси в необхідному обсязі, і якщо в користувача є права, для того щоб замовити резервування. RSVP-запити просуваються вздовж заздалегідь розрахованого маршруту та на кожному з пройдених вузлів (маршрутизаторів) здійснюється спроба зарезервувати необхідні ресурси.

Процес резервування полягає в такому (рис. 10.4.18):

1. Спочатку джерело даних надсилає в напрямку одержувача спеціальне повідомлення PATH, у якому він указує параметри свого трафіка.
2. Після одержання повідомлення РАТН одержувач відправляє маршрутизатору, від якого він одержав це повідомлення, запит резервування ресурсів — повідомлення RESV (reservatіon request), яке крім усього іншого містить специфікацію запиту, тобто вимоги щодо виділюваного обсягу ресурсів. Повідомлення RESV передається від одержувача до джерела, і після його одержання маршрутизатор визначає прийнятність зазначених у запиті параметрів резервування.
3. Якщо запит не може бути задовільнено (через нестачу ресурсів або помилки авторизації), маршрутизатор повертає повідомлення про помилку відправникові. Якщо запит приймається, то маршрутизатор надсилає повідомлення RESV наступному маршрутизатору на шляху до джерела.
4. Після встановлення з’єднання та здійснення резервування джерело починає відправляти дані, які обслуговуються на всьому шляху до одержувача (одержувачів) із заданою якістю обслуговування.

Рис. 10.4.18. Приклад роботи протоколу RSVP

Одним із примітивних засобів сигналізації є маркування пакета ознакою, яка несе інформацію про необхідний для пакета рівень якості обслуговування. Найчастіше в цих цілях використовується поле пріоритету (у пакеті ІPv4 — перші три біти поля TоS). Просуваючись від одного мережного вузла до іншого, пакет переносить уздовж шляху проходження свої вимоги щодо якості обслуговування, щоправда, у досить узагальненій формі, оскільки поле пріоритету має всього кілька можливих значень, тому і якість обслуговування надаватиметься диференційовано за декількома агрегованими потоками в мережі.

Ініціювати роботу протоколу сигналізації може не тільки кінцевий, але й транзитний вузол. Наприклад, приграничний маршрутизатор окремого сервіс-провайдера здатний виконати класифікацію трафіка та зарезервувати в мережі цього провайдера даному потоку певну пропускну здатність. У цьому разі координація роботи мережних пристроїв відбуватиметься не на всьому шляху проходження трафіка, а тільки в межах мережі даного провайдера, що, звичайно, знижує якість обслуговування трафіка.

Протокол LDP. У мережах MPLS поряд з протоколом RSVP може використовуватися як сигнальний також протокол Label Distribution Protocol (LDP) — протокол поширення міток. Цей протокол надає можливість маршрутизаторам з комутацією міток LSR (Label Swіtchіng Router) виявляти один одного та забезпечувати їх взаємодію шляхом встановлення шляху комутації міток Label Switch Path (LSP). Для забезпечення надійності передачі повідомлень протокол LDP працює «поверх» транспортного протоколу TCP, що дозволяє забезпечити гарантованість доставки пакетів уздовж встановленого LSP.

У технології MPLS передбачається, що призначення мітки, тобто її прив’язку до певного класу еквівалентного пересилання (Forwardіng Equіvalence Classes, FEC), робить LSR, що є вихідним приграничним маршрутизатором для пакетів цього FEC — нижній або нижчий від LSR (downstream LSR), а розташований «вище за течією» LSR — верхній або вищий від LSR (upstream LSR) (рис. 10.4.19).

Рис. 10.4.19. Фрагмент MPLS-мережі

Таким чином, призначення міток завжди здійснюється у бік, протилежний напрямку передачі пакетів трафіка. Нижній LSR інформує сусідні верхні LSR про те, які мітки він прив’язав до кожного з FEC-пакетів, що до нього надходять. Також у протоколі визначений механізм передачі повідомлень і виявлення в LSP маршрутів з петлями.

При обміні інформацією між LSR, пов’язаною з прив’язкою «мітка-FEC», використовуються чотири категорії повідомлень LDP:

• повідомлення виявлення (dіscovery messages), які використовуються для того, щоб оголосити та підтримувати присутність LSR у мережі;
• сеансові повідомлення (sessіon messages), які призначені для створення, підтримки та припинення LDP-сеансів між LSR;
• повідомлення-оголошення (advertіsement messages), які використовуються для створення, зміни та скасування прив’язки мітки до FEC;
• повідомлення-оповіщення, які містять допоміжну інформацію та інформацію про помилки.

Модифікації сигнальних протоколів резервування мережних ресурсів. Модифікації сигнальних протоколів пов’язані з необхідністю реалізації вимог перспективних мережних концепцій і технологій Constraint-based Routing (Load-Balancing Routing) і Traffic Engineering. Наприклад, протокол CR-LDP (Constraint-Based LDP) є варіантом LDP, у якому визначені механізми створення та підтримки трактів LSP з явно заданим маршрутом. Для створення шляху CR-LSP використовується більше інформації, ніж можна одержати від традиційних протоколів внутрішньої маршрутизації. CR-LDP застосовується для таких аплікацій MPLS, як ТЕ-управління трафіком і QoS, де потрібна додаткова інформація про маршрути. У цьому протоколі запит мітки може не слідувати сліпо вздовж дерева маршрутизації для даного адресата, оскільки передбачено можливість точно повідомити, як він повинен проходити, включивши в повідомлення явно заданий маршрут. При цьому програмне забезпечення CR-LDP не використовує для маршрутизації таблиці пересилання, а маршрутизує запит відповідно до інструкцій, які містяться в повідомленні.

Протокол CR-LDP не підтримує динамічного розрахунку маршрутів, які явно задаються, тому відомості про динамічне резервування пропускної здатності мають включатися у віщальну інформацію протоколів OSPF або ІS-ІS, або в повідомлення про стан каналів LSA. Використовуючи ці механізми, CR-LDP може займати й резервувати пропускну здатність. При встановленні нового шляху в повідомленні сигналізації поряд з послідовністю адрес шляху вказується також і пропускна здатність, яка повинна бути зарезервована. Кожний LSR, одержавши таке повідомлення, віднімає запитувану пропускну здатність із пула вільної пропускної здатності відповідного інтерфейсу. Доступна пропускна здатність змінюється відповідно до запиту, і її нове значення розсилається іншим вузлам за допомогою розширень протоколів OSPF й ІS-ІS, наприклад протоколу CSPF (Constrained SPF). У результаті протокол CR-LDP одержує у своє розпорядження явний маршрут для організації LSR. Шлях створюється за допомогою повідомлення запиту мітки, що містить динамічно обчислений явний маршрут.

Протокол CR-LDP має також інші, нові порівняно з базовою версією LDP, функціональні можливості:

• явна маршрутизація з точно визначеними та вільними маршрутами, за якої маршрут задається у вигляді послідовності груп вузлів. Якщо ж у групі зазначено більше одного маршрутизатора, забезпечується певна гнучкість при створенні явного маршруту;
• специфікація параметрів трафіка (наприклад пікова швидкість передачі, гарантована швидкість передачі та припустима варіація затримки — джитер);
• закріплення маршруту (route pіnnіng), яке може використовуватися в тих випадках, де змінювати LSP небажано, наприклад, у сегментах з вільною маршрутизацією, коли в цьому сегменті стає доступним кращий маршрут;
• механізм пріоритетного витиснення LSP за допомогою системи пріоритетів створення та утримання. Існуючі тракти LSP (пріоритет утримання) і нові тракти LSP (пріоритет створення) ранжуються для того, щоб визначити, чи може новий LSP витісняти існуючий LSR. Для пріоритетів запропоновано діапазон значень від 0 (вищий пріоритет) до 7 (нижчий пріоритет);
• введено нові коди станів LSR;
• введено LSPІ — унікальний ідентифікатор тракту CR-LSP у мережі;
• введено класи (кольори) мережних ресурсів, які призначаються в мережі адміністративно.

Хоча CR-LDP має досить широкі можливості інжинірингу трафіка (ТЕ) у мережах MPLS і не вимагає реалізації в обладнанні додаткового протоколу, а лише розширення вже існуючого, проте в ІETF паралельно ведуться також роботи щодо модифікації протоколу RSVP, який отримав відповідне розширення — RSVP-TE.

У розширеній версії протоколу, яка описана в RFC 3209 «Extensіons to RSVP for LSP Tunnels», визначений новий об’єкт LABEL (мітка), що переноситься в повідомленні RESV. Коли маршрутизатору LSR потрібно передати повідомлення RESV для нового потоку, він вибирає зі свого пула вільну мітку, створює запис у своїй таблиці LFІ, визначаючи обрану мітку як вхідну, і потім передає повідомлення RESV, що містить цю мітку в об’єкті LABEL. Слід зазначити, що, оскільки повідомлення RESV ідуть від одержувача до джерела, то це різновид розподілу міток знизу. При одержанні повідомлення RESV, яке містить мітку потоку, маршрутизатор записує її у своїй базі LIB як вихідну, призначає для даної вихідної мітки вхідну та пересилає її LSR, що розташований вище. Таким чином, уздовж шляху поширення повідомлення створюється тракт LSP. Оскільки в повідомленнях RESV указуються мітки, кожний LSR може легко зв’язати відповідні ресурси QoS із трактом LSP.

Протокол RSVP, розширений об’єктом LABEL, може створити LSP тільки вздовж маршруту, обчисленого за допомогою протоколів традиційної ІP-маршрутизації пакетів. Причина в тому, що при використанні звичайного протоколу RSVP шлях, за яким іде повідомлення PATH, управляється парадигмою пересилання на основі пункту призначення, а маршрут, за яким йде повідомлення PATH, задає шлях LSP. Коли маршрутизатор повинен переслати повідомлення PATH, він для визначення наступного маршрутизатора, до якого він повинен переслати повідомлення, використовує наявну в нього таблицю маршрутизації, що формується за допомогою таких протоколів, як ІS-ІS, OSPF, RІP або BGP, і адресу одержувача, що міститься в заголовку ІP-пакета. При цьому відсутня можливість «управляти» повідомленням PATH, відправляючи його вздовж конкретного, явно заданого маршруту.

Для можливості використання явного маршруту до протоколу RSVP-TE ввели ще один об’єкт — Explіcіt Route Object (ERO). ERO містить послідовність маршрутизаторів, яка є явно заданим маршрутом, і включається в повідомленні PATH. У відповідь на це повідомлення за даним маршрутом передається повідомлення RESV, завдяки чому резервуються ресурси мережі та встановлюється шлях LSP. Оскільки трафік, що проходить по LSP, визначається міткою, призначеною на вхідному маршрутизаторі, то цей шлях можна вважати своєрідним тунелем, який перебуває під рівнем ІP-маршрутизації, причому трафік, що йде по ньому, непрозорий для транзитних вузлів. Таким чином, з’явилося поняття LSP-тунелю.

Результати порівняння сигнальних протоколів CR-LDP і RSVP-TE наведено в табл. 10.4.2.

Таблиця 10.4.2 Порівняння протоколів CR-LDP і RSVP-TE

Тип протоколу	CR-LDP	RSVP-TE
Використовуваний транспортний протокол	TCP	Вихідний IP
Підтримка багатоадресного трафіка	Підтримується	Підтримується
Підтримка віщального розсилання	Не підтримується	Не підтримується
Підтримка злиття LSP	Підтримується	Підтримується
Явна маршрутизація	Зі строгими та нестрогими ділянками маршруту	Зі строгими та нестрогими ділянками маршруту
Ремаршрутизація LSP	Підтримується	Так, шляхом запису маршруту
Витиснення потоків у LSP	Підтримується, на основі пріоритету	Підтримується, на основі пріоритету
Засоби безпеки	Підтримується	Підтримується
Захист LSP	Підтримується	Підтримується
Стан LSP	Фіксований	Нефіксований
Регенерація стану LSP	Непотрібна	Потрібна, періодична, по ділянках
Резервування спільно використовуваних ресурсів	Не підтримується	Підтримується
Обмін параметрами трафіка	Підтримується	Підтримується
Управління трафіком	У прямому напрямку	У зворотному напрямку
Авторизація користувачів	Неявна	Явна
	Наявні	Немає