Архітектура інтегрованих послуг

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

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.

4. Коли кожен маршрутизатор, який підтримує RSVP, уздовж зворотнього шляху одержує повідомлення RESV, то він визначає прийнятність зазначених у запиті параметрів резервування як було описано вище з використанням процесів управління доступом і управління політикою. Якщо запит не може бути задоволений (через недолік ресурсів або помилки авторизації), маршрутизатор повертає повідомлення про помилку джерелу. Якщо запит приймається, то маршрутизатор посилає повідомлення RESV уверх наступному маршрутизаторові (у напрямку джерела). Прийом запиту резервування маршрутизатором означає також передачу параметрів QoS на відпрацьовування у відповідні блоки маршрутизатора. Конкретний спосіб відпрацьовування параметрів QoS маршрутизатором у протоколі RSVP не описується. Якщо технологія канального рівня, що обслуговує вихідний інтерфейс, не підтримує управління якістю обслуговування, то відпрацьовування виконується механізмом управління чергами, таким як WFQ або CQ. Якщо ж ця технологія підтримує QoS, то параметри специфікації RSpec відображаються на параметри QoS даної технології, наприклад, ATM.

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

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

Механізм RSVP-резервування схематично показаний на рис. 3.

Рисунок 3 – Механізм RSVP-резервування

Отже, RSVP-компоненти виконують такі функції.

• RSVP-джерело (RSVP sender) ініціює відправлення трафіка в RSVP-сеансі. RSVP- джерела передають параметри свого трафіка – специфікацію потоку даних відправника Sender_TSpec – проміжним маршрутизаторам і RSVP-одержувачеві. Специфікація Sender_TSpec є частиною об'єкта RSVP SENDER_TSPEC повідомлення PATH (див. нижче). Під час передавання RSVP-мережею зміст специфікації Sender_TSpec не змінюється;

• RSVP-одержувач (RSVP-receiver) одержує трафік у RSVP-сеансі. У процесі резервування ресурсів у відповідь на повідомлення PATH формує повідомлення, до якого включено об'єкт RSVP FLOWSPEC (див. нижче), що містить інформацію Receiver_TSpec і RSpec. Під час передавання RSVP-мережею зміст даних специфікацій може змінюватися в результаті злиття декількох RSVP-запитів або з інших причин.

Специфікація потоку даних Sender_TSpec або Receiver_TSpec містить у собі таку інформацію про трафік (RFC 2210): середню швидкість передачі даних, розмір «кошика маркерів» (узгоджений розмір сплеску), пікову швидкість (максимальний розмір сплеску), мінімальний і максимальний розміри пакетів. Специфікація RSpec містить вимоги щодо виділених ресурсів у термінах смуги пропускання і затримки.

Підтримка резервування. RSVP є протоколом гнучких станів (soft-state). Це означає, що потрібне періодичне оновлення резервування в мережі шляхом посилання додаткових повідомлень, чим власне протоколи даного типу відрізняються від hard-state протоколів, в яких запит посилається один раз і виконується доти, поки не буде явно скасований.

Для відновлення резервування усі компоненти, що беруть участь у резервуванні (RSVP-джерело, RSVP-одержувач, RSVP-сумісні маршрутизатори), періодично через кожні 30 с відсилають своїм сусідам повідомлення PATH (у прямому напрямку) і RESV (у зворотному напрямку). Якщо маршрутизатор відправляє чотири повідомлення PATH підряд і не одержує протягом цього часу жодного повідомлення RESV, резервування вважається втраченим і одержувачеві відправляється повідомлення про розрив з'єднання.

Скасування резервування. Резервування можна скасувати прямо або непрямо. Пряме скасування виконується з ініціативи RSVP-джерела або RSVP-одержувача за допомогою відповідних повідомлень протоколу RSVP (PATHTEAR уздовж шляху, яким передавалося повідомлення PATH, і RESVTEAR уздовж шляху, яким передавалося повідомлення RESV). Повідомлення RESVTEAR відправляється у відповідь на отримане PATHTEAR, що сигналізує про те, що RSVP-одержувач скасував резервування. Cisco IOS Software очікує від RSVP-джерела відсилання RSVP-одержувачеві підтвердження про одержання RESVTEAR – повідомлення RESVTEARCONF.

Непряме скасування відбувається за тайм-аутом: стан резервування має термін життя, і RSVP-компоненти мають періодично підтверджувати резервування. Якщо ж повідомлення-підтвердження перестають надходити, то резервування скасовується після закінчення його терміну життя.

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

2.3 Повідомлення і пакети RSVP

У табл. 1 наведено типи повідомлень, які використовуються в RSVP. Документом RFC 2205 визначено сім типів повідомлень: PATH, RESV, PATHERR, RESVERR, PATHTEAR, RESVTEAR, RESVCONF. Повідомлення HELLO введене в RFC 3209 як розширення RSVP і призначене для підтримки встановленого резервування. Повідомлення RESVTEARCONF не описане в документах RFC, а є запатентованою компанією Cisco розробкою.

Таблиця 1 – Типи RSVP повідомлень

Повідомлення RSVP мають чіткий формат: кожне повідомлення RSVP обов'язково має заголовок (рис. 4) і наступний за ним один або кілька об'єктів. У табл. 2 описані поля заголовка RSVP-повідомлення.

Рисунок 4 – Загальний формат заголовка RSVP

Таблиця 2 – Пояснення полів заголовка RSVP

Що стосується об'єктів, які розміщуються після заголовка, то їхня кількість і типи залежать від призначення повідомлення. Різними документами RFC визначено 23 класи об'єктів RSVP. Всі об'єкти мають однаковий формат (RFC 2205), що складається з заголовка (32 біта) і змісту об'єкта (рис. 5). У відповідності зі стандартним форматом у заголовку кожного об'єкта вказується його загальна довжина в байтах (величина обов'язково кратна чотирьом); номер класу об'єкта (кожен клас об'єктів має як свою назву, так і номер); С-тип (тип об'єкта, унікальний у рамках одного класу). Номер класу і С-тип використовуються разом як 16-бітовий ідентифікатор унікального типу для кожного об'єкта. Об'єкт несе в собі різну інформацію, наприклад, про стиль резервування ресурсів (клас STYLE), специфікацію потоку даних, переданих джерелом (клас Sender_TSpec), специфікацію потоку даних і вимог до ресурсів, запитуваних одержувачем (клас Flowspec, RFC 2210). Об'єкт розміщується в повідомленні з урахуванням його типу, наприклад, об'єкт класу Sender_TSpec розміщається тільки в PATH-повідомленнях, об'єкт класу Flowspec тільки в повідомленнях RESV, RESVERR, RESVTEAR, RESVCONF, RESVTEARCONF.

Рисунок 5 – Формат об'єкта RSVP

2.4 Стилі резервування протоколу RSVP

Запит на резервування містить у собі набір опцій, що у сукупності називаються стилем. Одна опція резервування визначає спосіб резервування різними джерелами в рамках однієї сесії – індивідуальне (distinct) резервування або загальне (shared) резервування. Інша опція резервування контролює вибір джерел: явний (explicit) або довільний (wildcard) вибір. У випадку явного вибору кожному джерелу ставиться у відповідність певна специфікація фільтра, у випадку довільного вибору – таких специфікацій не потрібно зовсім. В даний час визначені наступні три стилі резервування (табл. 3 ):

Таблиця 3 – Фільтри резервування RSVP

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

Індивідуальне резервування відбувається явно для відправника і встановлюється за допомогою стилю резервування з фіксованим фільтром (Fixed Filter – FF). Символічно запит на резервування в стилі FF можна записати як FF(S{Q}), де S – це джерело, a Q – об'єкт FlowSpec. Нагадаємо, що пара S{Q} є дескриптором потоку. RSVP дозволяє застосовувати стиль резервування FF одночасно для декількох потоків, при цьому формується список дескрипторів потоків FF(S1{Q1}, S2{Q2}, ...). Повне резервування в каналі для даної сесії характеризується сумою Q1, Q2, ... для усіх відправників.

Загальне резервування (shared reservations) застосовується в тих аплікаціях, в яких кілька джерел даних не схильні передавати інформацію одночасно, наприклад, цифрові аудіоаплікцаії, такі, як аплікації VoIP. У цьому випадку, оскільки в будь-який окремо узятий проміжок часу розмову веде невелика кількість людей, інформація передається лише невеликою обмеженою кількістю джерел. Такий потік не має потреби в окремому резервуванні ресурсів для кожного відправника, для нього необхідно усього лише одне резервування, яке за необхідності можна буде застосувати до будь-якого відправника в групі. У термінах протоколу RSVP такий потік називається загальним потоком (shared flow); він установлюється за допомогою загального явного (Shared Explicit – SE) або групового (Wildcard Filter – WF) резервування.

При загальному явному резервуванні SE потоки, що резервують мережні ресурси, вказуються окремо. Іншими словами, створюється резерв ресурсів, що використовується спільно декількома відправниками, перелік яких задається безпосередньо. Символічно запит на резервування в стилі SE можна подати як SE((S1,S2){Q}), де S1, S2, ... – окремі джерела, що потребують резервування ресурсів, a Q – об'єкт FlowSpec.

За допомогою групового фільтра WF смуга пропускання і характеристики затримки можна зарезервувати для будь-якого джерела. Такий фільтр не дозволяє вказати джерела окремо – він приймає усі джерела, на що вказує встановлення адреси джерела і порту в нуль. Резервування здійснюється в найбільшому серед запитаних одержувачами обсязі ресурсів, що не залежить від кількості відправників. Зарезервований груповий ресурс поділяється поміж потоками усіх відправників. Символічно запит на резервування в стилі WF можна подати як WF(*{Q}), де символ «*» є груповим символом вибору джерел, a Q – об'єкт FlowSpec.

Використання стилю резервування FF аналогічно встановленню з'єднання «точка – точка», SE і WF – «група точок – точка». На рис. 6 проілюстровані всі три стилі резервування ресурсів. Відзначимо, по-перше, стиль резервування вказується в об'єкті класу STYLE повідомлень RESV, що передаються в напрямку від одержувача до джерела, по-друге, при об'єднанні запитів на резервування як результуючою необхідною смугою обирається найбільша величина з усіх запитаних одержувачами.

2.5 Типи інтегрованих послуг, які надаються RSVP

Протокол RSVP надає два типи інтегрованих послуг, які одержувачі можуть отримати за допомогою повідомлень RSVP RESV: службу регульованого навантаження (Controlled-Load Service, RFC 2211) і службу гарантованого обслуговування (Guaranteed Service, RFC 2212).

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

Як правило, служба регульованого навантаження застосовується при передачі трафіка Internet-аплікацій, що чутливі до перевантажень у мережі. Такі аплікації відмінно працюють у незавантажених мережах, але відразу «стають непридатним» при перевантаженні. Прикладом є аплікація, що працює за протоколом FTP.

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

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

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

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

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

2.6 Висновки щодо RSVP

Узагальнюючи, можна сказати, що:

-RSVP забезпечує резервування ресурсів як для трафіка групового мовлення (multicast), так і для односпрямованого (unticast) трафіку, динамічно адаптуючись як до зміни групи адресатів, так і до зміни маршрутів;

-RSVP – це не транспортний, а управляючий протокол. Він не переносить дані, а працює паралельно з потоками даних TCP або UDP;

-RSVP транспортує і підтримує параметри управління трафіком і політикою, що залишаються непрозорими для RSVP;

-RSVP не є маршрутним протоколом, але залежить від існуючих і майбутніх маршрутних протоколів;

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

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

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

-Резервування базується на одержувачі для того, щоб ефективно підтримувати великі мультикастові гетерогенні групи одержувачів. Саме одержувач даних ініціює і підтримує резервування ресурсів для потоку;

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

- Групове резервування «зливається» у точках реплікації трафіка на шляху „уверх”, що вимагає розробки складних алгоритмів;

-RSVP-трафік може проходити через маршрутизатори, які не підтримують RSVP. Це створює слабкі ланки в ланцюзі QoS, де рівень обслуговування знижений до рівня обслуговування «з максимальними зусиллями» – best effort.

- RSVP може працювати з IPv4 і IPv6.

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

Протокол RSVP з резервуванням ресурсів для кожного потоку добре масштабується в корпоративних intranet-мережах середнього розміру зі швидкістю ліній зв'язку DS3 або менше. При застосуванні у великих intranet-мережах і магістралях постачальників послуг Internet (Internet Service Provider, ISP) протокол RSVP добре масштабується за умови використання великих багатоадресних груп, великих статичних класів або об'єднання потоків на границях мережі. Агрегування RSVP-резервувань передбачає злиття декількох наскрізних резервувань, що мають загальні маршрутизатори входу і виходу, в одне велике наскрізне резервування. Інший підхід до вирішення проблеми масштабованості протоколу RSVP в ядрі великої мережі полягає у використанні протоколу RSVP на границях мережі і реалізації DiffServ-послуг у її магістралі.