Рисунок 5.9 - Применение протокола RSVP
Одним из средств обеспечения качества IP-телефонии и особенно Интернет-телефонии является использование протокола резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованного комитетом IETF. С помощью RSVP мультимедиа-программы могут потребовать специального качества обслуживания (Specific Quality of Service, SQoS) посредством любого из существующих сетевых протоколов - главным образом IP, хотя возможно использовать и UDP, чтобы обеспечить передачу видео- и аудио сигналов с высоким качеством. Протокол RSVP предусматривает гарантированное качество обслуживания благодаря тому, что через каждый узел (маршрутизатор), который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.
Протокол RSVP предназначен только для резервирования части пропускной способности линии. Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (рисунок 5.9). Транзитные маршрутизаторы по мере прохождения этого сообщения также анализируют имеющееся у них количество свободных ресурсов и подтверждают его соответствующим сообщением RSVP Resv, передаваемым в обратном направлении. Если ресурсов достаточно, то отправитель начинает передачу. Если ресурсов не достаточно, получатель должен снизить требования или прекратить передачу информации.
Рисунок 5.9 - Применение протокола RSVP
Одна из интересных особенностей RSVP заключается в том, что запросы на резервирование ресурсов направляются только от получателей данных отправителям, а не наоборот. Такой подход обусловлен тем, что лишь устройство-получатель знает, с какой скоростью оно должно получать данные, чтобы надежно декодировать аудио- или видеосигналы. Другая уникальная особенность RSVP состоит в том, что резервирование производится лишь для одного направления. Кроме того, RSVP не допускает смешения аудио- и видеосигналов на зарезервированном канале.
Когда RSVP-программы закончат сеанс связи, они должны вызвать функцию отмены, предусмотренную этим протоколом. Отмена аннулирует все запросы на ресурсы, сделанные программой, и позволяет другим прикладным программам использовать коммуникационные возможности Internet. Если программе не удается выполнить отмену, то предусмотренные протоколом средства по истечении некоторого промежутка времени обнаружат это и автоматически отменят запрос на ресурсы.
Недостатком протокола RSVP является то, что полоса пропускания, выделяемая источнику информации, при снижении активности источника не может быть использована для передачи другой информации.
Поскольку протокол RSVP требует резервирования ресурсов или каналов связи, небрежные или безответственные пользователи могут захватить ресурсы сети, инициируя несколько сеансов подряд. Как только канал зарезервирован, он становится недоступным для других пользователей, даже если тот, кто его затребовал, ничего не передает. К сожалению, в RSVP отсутствует четкий механизм предотвращения подобных ситуаций, и решение этой проблемы возлагается на сетевых администраторов. Очевидно, что необходимо предусмотреть более жесткий контроль, чтобы использование RSVP имело успех.
Как альтернатива этому способу может использоваться алгоритм управления потоками на основе системы приоритетов, однако в существующей версии IP этот механизм развит недостаточно. Механизм управления приоритетами должен быть реализован в следующей (шестой) версии IP, где предусматривается введение до 16 приоритетов, а также возможность организации нескольких логических потоков в рамках одного физического соединения. Однако в настоящее время аппаратура, реализующая IP версии 6, только начала появляться на рынке.
Ввиду зависимости RSVP от совместимости промежуточных узлов - в большинстве случаев маршрутизаторов - это влечет за собой неизбежные проблемы, в частности, в глобальных сетях. Если какой-либо маршрутизатор достиг предела своих возможностей, когда он не может гарантировать запрошенный уровень качества обслуживания (Grade of Service, GoS), все последующие запросы будут игнорироваться и удаляться. Если только один узел отказывает в обслуживании запроса, то вся стройная система резервирования распадается.
Протокол RSVP имеет весьма хорошие перспективы на корпоративном уровне, где администратор имеет возможность определить, какие параметры маршрутизатор будет использовать для обслуживания запросов, связанных с предоставлением требуемого качества обслуживания. В глобальных сетях маршрутизаторы вовсе не обязательно находятся под той же юрисдикцией, что приложения и хосты, инициирующие запросы. Это осложняет решение вопроса о гарантиях качества обслуживания вызова.
