Полная версия

Главная arrow Техника arrow IP-телефония и традиционные телефонные сети

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

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

Одним из средств обеспечения качества IP-телефонии и особенно Интернет-телефонии является использование протокола резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованного комитетом IETF. С помощью PSVP (приложение) мультимедиа-программы могут потребовать специального качества обслуживания (specific quality of service, QoS) посредством любого из существующих сетевых протоколов - главным образом IP, хотя возможно использовать и UDP (приложение) - чтобы обеспечить качественную передачу видео- и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS (приложение) благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

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

Одна из интересных особенностей RSVP заключается в том, что запросы на резервирование ресурсов направляются только от получателей данных отправителям, а не наоборот. Такой подход обусловлен тем, что лишь устройство-получатель знает, с какой скоростью оно должно получать данные, чтобы надежно декодировать аудио- или видеосигналы. Другая уникальная особенность RSVP состоит в том, что резервирование производится лишь для одного направления. Кроме того, RSVP не допускает смешения аудио- и видеосигналов на зарезервированном канале.

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

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

Как альтернатива этому способу может использоваться алгоритм управления потоками на основе системы приоритетов, однако в существующей версии IP этот механизм развит недостаточно. Механизм управления приоритетами должен быть реализован в следующей шестой версии IP, где предусматривается введение до 16 приоритетов, а также возможность организации нескольких логических потоков в рамках одного физического соединения. Однако в настоящее время аппаратура, реализующая IP версии 6, только начала появляться на рынке.

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

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

 
Перейти к загрузке файла
<<   СОДЕРЖАНИЕ   >>