АРХІТЕКТУРАІНТЕГРОВАНИХ ПОСЛУГ
1. Модель IntServ
Архітектураінтегрованих послуг IntServ з'явилася у 1994 році, раніше за DiffServ, увідповідь на необхідність у модифікації інфрастуктури Internet. Метою цієїархітектури є підтримка QoS, у першу чергу для аплікацій реального часу, яка бзабезпечувала управління міжкінцевою затримкою пакета, а також управліннярозподілом смуги між потоками трафіка. Термін «інтегровані послуги» відповіднодо специфікації RFC 1633 містить у собі існуючу раніше доставку best effort, атакож додає доставку потоків трафіка реального часу з гарантованою затримкою ідоставку пакетів з гарантованою швидкістю.
Головна ідея(постулат) моделі IntServ полягає в тому, що ресурсами, у тому числі смугою,можна явно управляти з метою задоволення вимог потоків трафіка. Другий момент(постулат) – забезпечення твердих гарантій щодо якості обслуговування неможливебез резервування ресурсів, де під резервуванням ресурсів розумієтьсявідображення QoS-вимог потоків на стан (конфігурацію) маршрутизаторів.
Основнимифункціональними блоками моделі IntServ є резервування ресурсів (resourcereservation) і управління доступом (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
ReSerVationProtocol (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 (RFC2205).
/>
Рисунок 2 –Агенти RSVP на маршрутизаторах мережі
Перед тим якзарезервувати ресурси, RSVP-демон (RSVPD) маршрутизатора з'єднується з двомалокальними модулями прийняття рішення – модулем управління доступом (admissioncontrol) і модулем управління політикою (policy control). Модуль управліннядоступом визначає, чи має вузол досить вільних ресурсів для забезпеченнявідповідного рівня QoS. Модуль управління політикою визначає, чи є вкористувача адміністраторські права, для того, щоб зробити резервування. Якщояка-небудь з перевірок не пройшла, RSVP-демон відправляє повідомлення пропомилку процесові аплікації, який надіслав запит. Якщо обидві перевірки пройшлинормально, RSVP-демон установлює параметри класифікатора пакетів (packetclassifier) і планувальника пакетів (packet scheduler) для надання потрібногорівня QoS. Класифікатор пакетів визначає клас QoS для кожного пакета, апланувальник пакетів управляє передачею пакетів, базуючись на їхньому класіQoS. На рівні планувальника передбачається використання алгоритмів WFQ або СQ іалгоритму WRED.
Під час процесуприйняття рішення модулем управління доступом резервування необхідної смугипропускання виконується тільки в тому випадку, якщо для запитуваного класу трафікамаються вільні ресурси в достатній кількості. У протилежному випадку запит надоступ відхиляється, але трафік передається з якістю обслуговування, визначеноюза замовчуванням для даного класу трафіка. У багатьох випадках, навіть якщозапит на доступ відхилений на одному або декількох маршрутизаторах, модуль усеще може реалізувати прийнятну якість обслуговування, встановивши резервуванняна перевантажених маршрутизаторах. Це можливо через те, що інші потоки данихможуть не цілком використовувати замовлену ними смугу пропускання.
Резервуваннязавжди має здійснюватися тим самим одноадресним шляхом (маршрутом) абобагатоадресним деревом. У випадку виходу з ладу лінії зв'язку маршрутизатор маєсповістити про це RSVP-демона, щоб його RSVP-повідомлення передавалися новимшляхом.
Процесвстановлення резервування складається з п'яти окремих кроків.
1. Джерело даних посилає заунікальною або груповою адресою одержувача спеціальне повідомлення PATH, уякому воно вказує параметри свого трафіка – специфікацію потоку данихвідправника (Sender_TSpec). Повідомлення PATH передається маршрутизаторамимережі у напрямку від джерела (або джерел) з використанням таблицьмаршрутизації, які отримані за допомогою будь-якого протоколу маршрутизації.
2. Кожен RSVP-маршрутизаторперехоплює РАТН-повідомлення, зберігає IP-адресу попередньої точки призначення,записує замість нього свою власну адресу і відправляє оновлене повідомленнядалі тим же шляхом, яким передаються дані. Тим самим у мережі утворитьсяфіксований маршрут передачі повідомлень у рамках сесії RSVP.
3. Після одержання повідомленняРАТН приймач відправляє маршрутизаторові, від якого він одержав цеповідомлення, запит резервування ресурсів — повідомлення RESV (reservationrequest). До повідомлення 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 повідомленьПовідомлення Функція Напрямок Адреса призначення PATH Використовується для ініціалізації встановлення і підтримки резервування Униз (до одержувача) Вузол-одержувач RESV Інформує про успішне проходження повідомлення PATH; резервує ресурси Уверх (до джерела) Наступний вузол PATHERR Посилається в напрямку джерела у випадку виявлення помилки в PATH (наприклад, коли розірване з'єднання або пакет PATH пошкоджений) Уверх Наступний вузол RESVERR Посилається в напрямку до кінцевого вузла, якщо в процесі обробки повідомлення RESV виявлена помилка Униз Наступний вузол PATHTEAR Посилається до кінцевого вузла для розриву існуючого резервування Униз Вузол-одержувач RESVTEAR Посилається в напрямку до вузла-джерела для розриву існуючого резервування Уверх Вузол- джерело RESVCONF Посилається у відповідь на повідомлення RESV або RESVTEAR для запиту підтвердження одержання повідомлення Униз Вузол-одержувач RESVTEARCONF (Cisco) Посилається в підтвердження на RESVTEAR Униз Вузол-одержувач HELLO (RFC 3209) Посилається сусіднім RSVP- вузлам з якими існує пряме з'єднання з метою підтримки встановленого з'єднання Уверх / униз Наступний вузол
Повідомлення RSVP мають чіткий формат: кожне повідомленняRSVP обов'язково має заголовок (рис. 4) і наступний за ним один або кілька об'єктів.У табл. 2 описані поля заголовка RSVP-повідомлення.
/>
Рисунок 4 – Загальний формат заголовка RSVP
Таблиця 2 – Поясненняполів заголовка RSVPПоле Опис Версія (Version) Версія протоколу RSVP. Поточна версія 1. Прапорці (Flags) Прапорці не визначені Тип повідомлення (Message Type)
1=повідомлення PATH
2= повідомлення RESV
3= повідомлення PATHERR
4= повідомлення RESVERR
5= повідомлення PATHTEAR
6= повідомлення RESVTEAR
7= повідомлення RESVCONF
10= повідомлення RESVTEARCONF
20= повідомлення HELLO RSVP Checksum Контрольна сума в RSVP-повідомленні TTL передачі Вказує на те, з яким значенням позначки часу життя (TTL) відправлений даний IP пакет Зарезервоване (Reserved) Не використовується Довжина (RSVP Length) Довжина RSVP повідомлення в байтах, включаючи заголовок. Мінімальна довжина 8 байт
Що стосується об'єктів, які розміщуються після заголовка, тоїхня кількість і типи залежать від призначення повідомлення. Різнимидокументами 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
Кількість
джерел Стилі резервування Індивідуальне Загальне Явне резервування FF (резервування з фіксованим фільтром) SE (загальне явне резервування)
Групове
резервування Не визначено WF (резервування з груповим фільтром)
Індивідуальнерезервування (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) або групового (WildcardFilter – 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-LoadService, RFC 2211) і службу гарантованого обслуговування (Guaranteed Service,RFC 2212).
Службарегульованого навантаження забезпечує гарантію того, що зарезервований потікдосягне свого пункту призначення з мінімальним втручанням з боку трафіка, щодоставляється без гарантій. Більш того, реалізацією цієї послуги компанієюCisco передбачена ізоляція окремих зарезервованих потоків. Ізоляція потокудозволяє виключити вплив інших присутніх у мережі зарезервованих потоків прирезервуванні ресурсів.
Як правило,служба регульованого навантаження застосовується при передачі трафікаInternet-аплікацій, що чутливі до перевантажень у мережі. Такі аплікаціївідмінно працюють у незавантажених мережах, але відразу «стають непридатним»при перевантаженні. Прикладом є аплікація, що працює за протоколом FTP.
Службагарантованого обслуговування забезпечує обмеження затримки без відкиданняпакетів, що задовольняють параметрам трафіка, в умовах відсутності збоїв уроботі мережних компонентів або змін в інформації про маршрути під час життяпотоку. Ця служба гарантує мінімальне втручання з боку трафіка, щодоставляється без гарантій, ізоляцію зарезервованих потоків і числове вираженнямаксимальної затримки.
Слід мати наувазі, що гарантоване обслуговування може забезпечити тільки максимальну, алене мінімальну або середню затримку пакетів. Більш того, щоб підрахуватимаксимальну затримку пакета, спочатку потрібно визначити фіксовану затримкушляху (затримка поширення і затримка передачі) і додати її до гарантованоїмаксимальної затримки черги. Важливо відзначити, що служба гарантованої бітовоїшвидкості визначає максимальну затримку черги, а не максимальну загальнунаскрізну затримку, оскільки такі компоненти останньої, як затримка поширення ізатримка передачі, цілком залежать від вибору шляху, яким передається трафік.
Максимальназатримка черги — це кумулятивна затримка передачі РАТН-повідомлення від джереладо одержувача. РАТН-повідомлення містить інформацію про затримку на всьомушляху від джерела до одержувача й у будь-який час надає одержувачеві її точнуоцінку. Одержувач використовує інформацію про затримку під час запитугарантованого обслуговування.
Службагарантованої бітової швидкості найкраще підходить для тих аплікацій масштабу реальногочасу, що дозволяють відтворювати аудіо- і відеофайли. Подібні аплікаціївикористовують для своєї нормальної роботи буфер джитера з метою компенсаціїнерівномірності прибуття пакетів. Визначаючи максимальну затримку черги, службагарантованої бітової швидкості допомагає оцінити необхідний розмір буфераджитера. Отже, аплікації масштабу реального часу можуть розраховувати нагарантовані смугу пропускання і максимальну затримку. Іншими словами, службарегулювання навантаження обіцяє тільки «добре обслуговування», а службагарантованого обслуговування надає інформацію (у PATH-повідомленнях), з якоїможна обчислити значення затримки.
Указівка на типобслуговування надається в спеціальному полі об'єкта FlowSpec, причому самформат об'єкта FlowSpec залежить від типу сервісу: у випадку виборугарантованого обслуговування в об'єкт FlowSpec входять специфікації RSpec, якихнемає у випадку регулювання навантаження. Нагадаємо, що специфікація RSpecмістить інформацію про необхідну смугу і припустиму величину затримки.
2.6 Висновки щодоRSVP
Узагальнюючи,можна сказати, що:
v RSVP забезпечує резервуванняресурсів як для трафіка групового мовлення (multicast), так і дляодноспрямованого (unticast) трафіку, динамічно адаптуючись як до зміни групиадресатів, так і до зміни маршрутів;
v RSVP – це не транспортний, ауправляючий протокол. Він не переносить дані, а працює паралельно з потокамиданих TCP або UDP;
v RSVP транспортує і підтримуєпараметри управління трафіком і політикою, що залишаються непрозорими для RSVP;
v RSVP не є маршрутнимпротоколом, але залежить від існуючих і майбутніх маршрутних протоколів;
v RSVP є симплекснимпротоколом, тобто він виконує резервування для потоку даних лише в одномунапрямку передачі;
v RSVP – це протокол гнучкихстанів, що означає необхідність періодичного оновлення резервуванняRSVP-компонетами;
v Аплікаціям потрібні API длязадання вимог до потоку, ініціювання вимог на резервування й одержанняповідомлень про успіх або невдачу резервування під час початкового запиту абопротягом сесії;
v Резервування базується наодержувачі для того, щоб ефективно підтримувати великі мультикастовігетерогенні групи одержувачів. Саме одержувач даних ініціює і підтримуєрезервування ресурсів для потоку;
v RSVP забезпечує кількамоделей резервування або стилів, для того щоб задовольнити вимоги різнихаплікацій;
v Групове резервування«зливається» у точках реплікації трафіка на шляху „уверх”, що вимагає розробкискладних алгоритмів;
v RSVP-трафік може проходитичерез маршрутизатори, які не підтримують RSVP. Це створює слабкі ланки вланцюзі QoS, де рівень обслуговування знижений до рівня обслуговування «змаксимальними зусиллями» – best effort.
v RSVP може працювати з IPv4 іIPv6.
Недолікомпротоколу RSVP є те, що обсяг необхідної інформації про стан потоківзбільшується із зростанням кількості резервувань ресурсів для потоків трафіка.Враховуючи, що в Internet-магістралі в будь-який час можуть існувати багатосотень тисяч одноадресних та багатоадресних потоків, використання інформації простан кожного потоку вважається немасштабованим рішенням для магістралейInternet.
Протокол RSVP зрезервуванням ресурсів для кожного потоку добре масштабується в корпоративнихintranet-мережах середнього розміру зі швидкістю ліній зв'язку DS3 або менше.При застосуванні у великих intranet-мережах і магістралях постачальників послугInternet (Internet Service Provider, ISP) протокол RSVP добре масштабується заумови використання великих багатоадресних груп, великих статичних класів абооб'єднання потоків на границях мережі. Агрегування RSVP-резервувань передбачаєзлиття декількох наскрізних резервувань, що мають загальні маршрутизатори входуі виходу, в одне велике наскрізне резервування. Інший підхід до вирішенняпроблеми масштабованості протоколу RSVP в ядрі великої мережі полягає увикористанні протоколу RSVP на границях мережі і реалізації DiffServ-послуг уїї магістралі.