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

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

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