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

Рисунок 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) або групового (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.