АРХІТЕКТУРА ІНТЕГРОВАНИХ ПОСЛУГ

1. Модель IntServ

Архітектура інтегрованих послуг IntServ з'явилася у 1994 році, раніше за DiffServ, у відповідь на необхідність у модифікації інфрастуктури Internet. Метою цієї архітектури є підтримка QoS, у першу чергу для аплікацій реального часу, яка б забезпечувала управління міжкінцевою затримкою пакета, а також управління розподілом смуги між потоками трафіка. Термін «інтегровані послуги» відповідно до специфікації RFC 1633 містить у собі існуючу раніше доставку best effort, а також додає доставку потоків трафіка реального часу з гарантованою затримкою і доставку пакетів з гарантованою швидкістю.

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

Основними функціональними блоками моделі IntServ є резервування ресурсів (resource reservation) і управління доступом (admission control). У рамках архітектури IntServ зроблено акцент на процесі сигналізації, за допомогою якого індивідуальні потоки повідомляють про свої вимоги щодо обсягу смуги, який потрібно зарезервувати, і припустимої величини затримки. Як протокол сигналізації в моделі IntServ передбачається використання протоколу резервування ресурсів RSVP (RFC 2205 – 2215).

Процесові резервування передує процес управління доступом, що на підставі аналізу доступних мережних ресурсів приймає рішення про прийняття потоку до обслуговування (якщо ресурсів досить) або відхилення запиту (за нестачі ресурсів). Обов'язковою умовою прийняття запиту до обслуговування є непогіршення якості обслуговування раніше прийнятих запитів. Функція управління доступом покладається на COPS-сервер.

Отже, ключовим поняттям у IntServ є резервування ресурсів. Коли мова йде про резервування смуги для потоку трафіка, то це означає таку конфігурацію механізму обслуговування черг, що при обслуговуванні черги з даним потоком йому надається така смуга, яка запитується. Коли мова йде про забезпечення припустимої величини затримки, то тут все трохи складніше. Наприклад, IOS Cisco забезпечує низьку затримку шляхом резервування місця в черзі. Взагалі в концепції IntServ з (RFC 1633) не обумовлюється спосіб забезпечення резервування ресурсів, залишаючи це питання розробникам обладнання.

Реалізація моделі IntServ згідно з RFC 1633 вимагає наявності в маршрутизаторі таких функціональних блоків (рис. 1 ):

-  класифікація (ідентифікація) потоків даних з метою визначення їхньої належності певному класу обслуговування;

-  механізм обслуговування черги, а також механізми визначення перевантаження і відкидання пакетів з низьким рівнем пріоритетного обслуговування;

-  управління доступом до ресурсів мережі з метою визначення можливості обслуговування запиту з заданим рівнем QoS на підставі аналізу наявності необхідного обсягу ресурсів;

-  механізм резервування ресурсів.

Рисунок 1 – Компоненти моделі IntServ, реалізовані в маршрутизаторі

Функції управління доступом, класифікації і планувальника можуть бути об'єднані в блок управління трафіком (traffic control), головна задача якого полягає в створенні різниці щодо якості обслуговування.

Модель IntServ має свої переваги та недоліки. ............