Обеспечение качества IP-телефонии на базе протокола RSVP

Для обеспечения должного качества обслуживания трафика речевых и

видеоприложений, необходим механизм, позволяющий приложениям информировать сеть о своих требованиях. На основе этой информации сеть может резервировать ресурсы для того, чтобы гарантировать выполнение требований к качеству или отказать приложению, вынуждая его либо пересмотреть требования, либо отложить сеанс связи. В роли такого механизма выступает протокол резервирования ресурсов (ResourceReservationProtocol, RSVP), рекомендованный комитетом IETF. С помощью RSVP мультимедиа-программы могут потребовать специального качества обслуживания (specificqualityofservice, QoS) посредством любого из существующих сетевых протоколов, чтобы обеспечить качественную передачу видео и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

Используя RSVP, отправитель посылает получателю сообщение RSVPPath, в котором указывает желательные характеристики качества обслуживания трафика - верхнюю и нижнюю границы полосы пропускания, величину задержки и вариации задержки (рис. 13.3). Каждый транзитный маршрутизатор, получивсообщение RSVPPath, фиксирует адрес предыдущего маршрутизатора. Таким образом, в сети образуется фиксированный маршрут.

Приняв сообщение RSVPPath, его получатель передаёт к маршрутизатору, от которого пришло этосообщение, запрос резервирования ресурсов - сообщение RSVPResv. При чтении этого сообщения каждый транзитный маршрутизатор определяет,приемлем ли этот запрос. Если запрос не может быть удовлетворён, то маршрутизатор отвечает на него сообщением об ошибке. Если же ресурсов достаточно, то отправитель начинает передачу.

RSVPPath

Отправитель Получатель

Рис. 13.3. Применение протокола RSVP

Когда RSVP-программы закончат сеанс связи, они должны вызвать функцию отмены, предусмотренную этим протоколом. Отмена аннулирует все запросы на ресурсы, сделанные программой, и позволяет другим прикладным программам использовать коммуникационные возможности Internet. Если программе не удается выполнить отмену, то предусмотренные протоколом средства по истечении некоторого промежутка времени обнаружат это и автоматически отменят запрос на ресурсы.

Недостатком протокола RSVP является то, что полоса пропускания, выделяемая источнику информации, при снижении активности источника не может быть использована для передачи другой информации. Поскольку для реализации QoS протокол RSVP требует резервирования ресурсов, некоторые пользователи могут захватить ресурсы сети, инициируя несколько сеансов QoS подряд. Как только канал зарезервирован, он становится недоступным для других пользователей,даже если тот, кто его затребовал, ничего не передает. К сожалению, в RSVP отсутствует четкий механизм предотвращения подобных ошибок, и решение этой проблемы

возлагается на сетевых администраторов. Очевидно, что необходимо предусмотреть более жесткий контроль, чтобы RSVPимел успех.Ввиду зависимости RSVP от совместимости промежуточных узлов (в большинстве случаев маршрутизаторов), то это влечет за собой неизбежные проблемы, в частности, в глобальных сетях. Если какой-либо маршрутизатор достиг предела своих возможностей, когда он не может гарантировать запрошенный уровень QoS, все последующие запросы будут игнорироваться и удаляться. При отказе только одного узла обслуживать запрос вся стройная система RSVP распадается на части.RSVP имеет весьма хорошие перспективы на корпоративном уровне, где администратор имеет возможность определить, какие параметры маршрутизатор будет использовать для обслуживания запросов о предоставлении QoS. В глобальных сетях маршрутизаторы вовсе не обязательно находятся под той же юрисдикцией, что и хосты и приложения, производящие запросы, что осложняетгарантирование QoS.