5.3. Протокол rsvp

Одним із засобів забезпечення якості IP телефонії й особливо Інтернет-телефонії є використання протоколу резервування ресурсів (Resource Reservation Protocol, RSVP), рекомендованого комітетом IETF. За допомогою RSVP мультимедіа-програми можуть зажадати спеціальної якості обслуговування (Specific Quality of Service, SQoS) за допомогою кожного з існуючих мережних протоколів - головним чином IP, хоча можливо використовувати й UDP, щоб забезпечити передачу відео- і аудіо сигналів з високою якістю. Протокол RSVP передбачає гарантовану якість обслуговування завдяки тому, що через кожний вузол (маршрутизатор), який зв'язує між собою учасників телефонної розмови, може передаватися певна кількість даних.

Протокол RSVP призначений тільки для резервування частини пропускної здатності лінії. Використовуючи RSVP, відправник періодично інформує одержувача про вільну кількість ресурсів повідомленням RSVP Path рис.5.1. Транзитні маршрутизатори в міру проходження цього повідомлення також аналізують наявне в них кількість вільних ресурсів і підтверджують його відповідним повідомленням RSVP Resv, переданим у зворотному напрямку. Якщо ресурсів досить, то відправник починає передачу. Якщо ресурсів не достатньо, одержувач повинен знизити вимоги або припинити передачу інформації. Одна із цікавих особливостей RSVP полягає в тому, що запити на резервування ресурсів направляються тільки від одержувачів даних відправникам, а не навпаки.

Рис.5.1.Застосування протоколу RSVP

Такий підхід обумовлений тим, що лише обладнання-одержувач знає, з якою швидкістю воно повинне одержувати дані, щоб надійно декодувати аудіо- або відеосигнали. Інша унікальна особливість RSVP полягає в тому, що резервування проводиться лише для одного напрямку. Крім того, RSVP не допускає змішання аудіо- і відеосигналів на зарезервованому каналі. Коли RVSP-програми закінчать сеанс зв'язку, вони повинні викликати функцію скасування, передбачену цим протоколом. Скасування анулює всі запити на ресурси, зроблені програмою, і дозволяє іншим прикладним програмам використовувати комунікаційні можливості Internet. Якщо програмі не вдається виконати скасування, то передбачені протоколом засобу після закінчення деякого проміжку часу виявлять це й автоматично скасують запит на ресурси.

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

Як альтернатива цьому способу може використовуватися алгоритм керування потоками на основі системи пріоритетів, однак в існуючій версії IP цей механізм розвинений недостатньо. Механізм керування пріоритетами повинен бути реалізований у наступній (шостий) версії IP, де передбачається введення до 16 пріоритетів, а також можливість організації декількох логічних потоків у рамках одного фізичного з'єднання. Однак у цей час апаратура, що реалізує IP версії 6, тільки почала з'являтися на ринку.

Через залежність RSVP від сумісності проміжних вузлів - у більшості випадків маршрутизаторів - це спричиняє неминучі проблеми, зокрема, у глобальних мережах. Якщо який-небудь маршрутизатор дійшов до межі своїх можливостей, коли він не може гарантувати запитаний рівень якості обслуговування, GoS (Grade of Service), усі наступні запити будуть ігноруватися й віддалятися. Якщо тільки один вузол відмовляє в обслуговуванні запиту, то вся струнка система резервування розпадається.

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