Архітектура інтегрованих послуг (стр. 1 из 4)

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

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 має свої переваги та недоліки. Головною перевагою даної моделі є забезпечення твердих гарантій щодо якості обслуговування: аплікація отримує той обсяг ресурсів, який їй необхідний, не менше і не більше. Крім того, це сприяє ефективному використанню ресурсів мережі. Однак моделі IntServ властиві серйозні недоліки, завдяки яким вона не одержала широкого поширення на практиці. Перший і найголовніший недолік полягає в низькій масштабованості, що пов'язано із обслуговуванням кожного потоку окремо. Нагадаємо, що для кожного окремого потоку необхідно не тільки зарезервувати ресурси, а також підтримувати це резервування, крім того, на кожному маршрутизаторі уздовж шляху доставки необхідно зберігати інформацію про стан потоку.

Другий недолік пов'язаний із утратою якості обслуговування при проходженні через ділянку мережі, у якій не підтримується IntServ. Тут відбувається або передача з якістю best effort, або відображення запиту на класи DiffServ (DSCP) при проходженні через DiffServ-домен.

інтегрований intserv протокол

2. Протокол сигналізації RSVP

2.1 Призначення протоколу RSVP

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

RSVP працює на рівні протоколу IP і має свій власний тип протоколу – 46, хоча можлива інкапсуляція повідомлень RSVP у датаграми UDP. Для такої інкапсуляції використовуються UDP-порти 1698 і 1699.

Спочатку протокол RSVP розроблявся для мультимедійного трафіка (аудіо- та відео-), орієнтуючись на групове мовлення. Однак RSVP успішно застосовується для резервування ресурсів для односпрямованого трафіка, наприклад, трафіка мережної файлової системи (Network File System, NFS) і управляючого трафіка віртуальних приватних мереж (Virtual Private Network, VPN).

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

2.2 Принципи функціонування протоколу RSVP

Функціонування RSVP пов'язане з виконанням таких задач:

- резервування ресурсів і підтримка резервування;

- звільнення зарезервованих ресурсів;

- сигналізація про помилки.

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

Рисунок 2 – Агенти RSVP на маршрутизаторах мережі

Перед тим як зарезервувати ресурси, RSVP-демон (RSVPD) маршрутизатора з'єднується з двома локальними модулями прийняття рішення – модулем управління доступом (admission control) і модулем управління політикою (policy control). Модуль управління доступом визначає, чи має вузол досить вільних ресурсів для забезпечення відповідного рівня QoS. Модуль управління політикою визначає, чи є в користувача адміністраторські права, для того, щоб зробити резервування. Якщо яка-небудь з перевірок не пройшла, RSVP-демон відправляє повідомлення про помилку процесові аплікації, який надіслав запит. Якщо обидві перевірки пройшли нормально, RSVP-демон установлює параметри класифікатора пакетів (packet classifier) і планувальника пакетів (packet scheduler) для надання потрібного рівня QoS. Класифікатор пакетів визначає клас QoS для кожного пакета, а планувальник пакетів управляє передачею пакетів, базуючись на їхньому класі QoS. На рівні планувальника передбачається використання алгоритмів WFQ або СQ і алгоритму WRED.

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

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

Процес встановлення резервування складається з п'яти окремих кроків.

1. Джерело даних посилає за унікальною або груповою адресою одержувача спеціальне повідомлення PATH, у якому воно вказує параметри свого трафіка – специфікацію потоку даних відправника (Sender_TSpec). Повідомлення PATH передається маршрутизаторами мережі у напрямку від джерела (або джерел) з використанням таблиць маршрутизації, які отримані за допомогою будь-якого протоколу маршрутизації.

2. Кожен RSVP-маршрутизатор перехоплює РАТН-повідомлення, зберігає IP-адресу попередньої точки призначення, записує замість нього свою власну адресу і відправляє оновлене повідомлення далі тим же шляхом, яким передаються дані. Тим самим у мережі утвориться фіксований маршрут передачі повідомлень у рамках сесії RSVP.

3. Після одержання повідомлення РАТН приймач відправляє маршрутизаторові, від якого він одержав це повідомлення, запит резервування ресурсів — повідомлення RESV (reservation request). До повідомлення RESV крім інформації Receiver_TSpec (специфікація потоку даних) включається специфікація запиту (RSpec), в якій указуються необхідні приймачеві параметри якості обслуговування, і специфікація фільтра (FilterSpec), що визначає, до яких пакетів сесії застосовується дане резервування (наприклад, за типом транспортного протоколу і номером порту). Разом RSpec і FilterSpec складають дескриптор потоку, який маршрутизатор використовує для ідентифікації кожного резервування ресурсів (RFC 2205). Фільтр може визначити потік пакетів з будь-яким ступенем деталізації і на підставі будь-якої інформації, у тому числі і прикладному рівні. Запитувані параметри QoS у специфікації RSpec можуть відрізнятися від зазначених у специфікації TSpec.