Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Процедура предварительного уведомления как один из путей усовершенствования протокола RSVP

А. Ю. Виноградов

В статье “Новое в RSVP” (Сети и системы связи. 2003. № 2. С. 32) уже отмечалось, что на сегодняшний день отсутствует стандартизованная технология, которая обеспечивала бы необходимый уровень качества обслуживания (QoS) при передаче речевых пакетов через пакетные сети связи. Большинство производителей оборудования предлагают собственные решения в этой области, но они в основном предполагают непосредственную настройку администратором сети механизмов, выполняющих обработку речевых пакетов на каждом маршрутизаторе пакетной сети связи. Например, основным механизмом, который используется для обработки речевых пакетов на маршрутизаторах производства компании Cisco Systems, является механизм Low Latency Queuing (LLQ).

К его достоинствам можно отнести обеспечение гарантированных величин полосы пропускания и минимальной задержки обработки речевых пакетов на выходном интерфейсе маршрутизатора. Это достигается благодаря организации на выходном интерфейсе маршрутизатора высокоприоритетной очереди, предназначенной для обработки речевых пакетов.

Полную версию данной статьи смотрите в 10-ом номере журнала за 2003 год.

Но для эффективного применения механизма LLQ дополнительным условием является поддержка маршрутизаторами протокола Multilink Point-to-Point Protocol (MLPPP), который позволяет на выходном интерфейсе маршрутизатора выполнять процедуру фрагментации пакетов данных, имеющих значительно больший размер по сравнению с размером речевых пакетов, и процедуру чередования отправки речевых пакетов и пакетов данных (Link Fragmentation and Interleaving, LFI). В случае передачи речи через пакетную сеть Frame Relay для применения механизма LLQ необходима поддержка маршрутизаторами рекомендаций FRF.11 и FRF.12, обеспечивающих приоритетную обработку речевых пакетов и фрагментацию пакетов данных.

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

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

Для администраторов пакетных сетей доступно и другое средство, позволяющее автоматизировать контроль за изменением состояния процессов в сети. Это использование динамических протоколов. Одним из таких протоколов, обеспечивающих необходимый уровень качества обслуживания речевых потоков, является протокол резервирования ресурсов RSVP (RFC 2205), который по запросу от приложения выполняет резервирование необходимой полосы пропускания на устройствах маршрутизации по пути от источника до получателя данных.

К преимуществам RSVP следует отнести возможность строгого резервирования полосы пропускания для передачи любого типа трафика через пакетную сеть с гарантией минимальных значений задержки передачи пакетов и вариации этой задержки (джиттера). Но из-за недостатков существующей версии данного протокола применение его в пакетных сетях ограничено. Среди этих недостатков можно назвать неэффективное использование доступной полосы пропускания при выполнении процедуры резервирования и плохую масштабируемость (подробнее о недостатках RSVP см.: Сети и системы связи. 2003. № 2. С. 32).

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

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

Напомним, что в существующей версии протокола RSVP параметры резервирования передаются маршрутизаторам непосредственно в момент выполнения процедуры резервирования. В однопроходном алгоритме передача параметров резервирования выполняется сразу же после указания администратором сети параметров резервирования на речевых шлюзах. В качестве параметра резервирования также выступает величина полосы пропускания, необходимая для передачи речевого потока. Вычисление полосы пропускания может быть осуществлено протоколом резервирования автоматически на основе следующих данных: тип используемого кодека, состояние (включен/выключен) механизмов обнаружения речи (Voice Activity Detection — VAD) и компрессии заголовков речевых пакетов. Автоматический расчет необходимой полосы пропускания с учетом типа кодека, механизма компрессии и обнаружения речи позволит устранить главный недостаток существующей версии протокола RSVP — неэффективное использование полосы пропускания при резервировании ресурсов.

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

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

Об авторе
Виноградов Алексей Юрьевич,
ведущий инженер телекоммуникационного
департамента компании “Крок”
Телефон: (095) 974-2274
E-mail: avinogradov@croc.ru





  
10 '2003
СОДЕРЖАНИЕ

электронная Россия

• Нижегородский форум инфокоммуникаций

бизнес

• Собеседование: как правильно оценить кандидата

инфраструктура

• ИБП в параллель

• Тестируем адаптеры iSCSI

• Сканируя эфир

информационные системы

• Как бороться с текучкой в call-центрах

• Корпоративные системы мгновенного обмена сообщениями

• Корпоративный контакт-центр

• Базы данных как источник сетевых заторов

сети связи

• Сети сигнализации будущего

• Процедура предварительного уведомления как один из путей усовершенствования протокола RSVP

• Хот-споты набирают силу

• Поставщики услуг хот-спотов: общие цели, уникальные достоинства

кабельные системы

• Высокоскоростной доступ по нескольким медным парам

• Маркирование кабельных систем по стандарту TIA/EIA-606-A

защита данных

• Сделайте свою сеть безопасной

новые продукты

• Switch 7700: возврат на рынок корпоративных решений


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх