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

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

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

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

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


Rambler's Top100

  

Новое в RSVP

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

Сегодня, наверное, уже никому не надо доказывать, насколько актуальны задачи, связанные с обеспечением качества обслуживания QoS (Quality of Service) в пакетных сетях связи. В свое время для их решения организация IETF предложила модель интегрированного обслуживания (Integrated Services Architecture - IntServ) [RFC 1633]. Она определяет два класса по обеспечению гарантированного уровня обслуживания в пакетных сетях, а именно класс контролируемой загрузки (controlled-load) [RFC 2211] и класс гарантированного обслуживания (guaranteed QoS) [RFC 2212]. На основе данной модели (в зависимости от класса обслуживания) для определенного типа трафика может быть предоставлена необходимая полоса пропускания в канале связи, а также гарантироваться минимальная задержка при передаче пакетов или минимальный уровень их потерь.

Основными компонентами модели IntServ являются следующие функциональные составляющие: модуль резервирования ресурсов (flow resource reservation), модуль управления доступом (flow admission control), классификатор трафика (packet classifier) и диспетчер очередей (packet scheduler). Модуль резервирования ресурсов, обеспечивая управление другими модулями (рис. 1), по запросу выполняет необходимое резервирование ресурсов и поддерживает его вплоть до момента окончания выполнения процедуры резервирования. Именно взаимодействие двух основных модулей - резервирования ресурсов и управления доступом - обеспечивает контроль доступных ресурсов (при запросе приложения на предоставление необходимого уровня качества обслуживания) и резервирование их на всем пути передачи трафика.

Функции протокола, отвечающего за работу модуля резервирования ресурсов, в модели IntServ выполняет протокол резервирования ресурсов )Resource Reservation Protocol - RSVP). Он был предложен организацией IETF [RFC 2205] в качестве основного протокола в модели интегрированного обслуживания. Его отличительной особенностью является универсальность, так как фактически инициатором запросов на резервирование может выступать любое приложение, поддерживающее данный протокол. Однако, кроме явных преимуществ применения данного протокола по обеспечению гарантированного обслуживания (приложению, запросившему этот сервис, гарантируются необходимая полоса пропускания и определенная величина задержки), RSVP имеет ряд недостатков, препятствующих его широкому применению в пакетных сетях.

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

О недостатках

Итак, протокол резервирования ресурсов, во-первых, увеличивает время установления соединения, что особенно нежелательно при функционировании такого протокола, как, например, H.323. Эта "неспешность" протокола RSVP связана с тем, что он работает в два этапа (рис. 2): сначала служебные пакеты RSVP обрабатываются маршрутизаторами на пути от речевого шлюза источника до речевого шлюза назначения (сообщение Path), а затем, если шлюз назначения готов принять речевой поток, они должны еще обработать служебные пакеты "резервирования", следующие от речевого шлюза назначения к шлюзу источника (сообщение Resv).

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

Следует отметить, что протокол RSVP не задействует механизмы, предотвращающие потерю его служебных сообщений. Дело в том, что для отправки своих служебных сообщений он использует транспортный протокол UDP, который является протоколом, не ориентированным на установление соединения (connectionless), т. е. он не обеспечивает подтверждение доставки. Поэтому при потере подряд нескольких служебных сообщений протокола RSVP процедура выполнения резервирования будет прервана по обнулению таймера, отвечающего за состояние приема подтверждений резервирования.

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

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

От IntServ к DiffServ

Ввиду особой важности масштабируемости в больших пакетных сетях организация IETF предложила другую модель, качественно отличающуюся от IntServ и получившую название модели дифференцированного обслуживания (Differentiated Services - DiffServ). В ней введено понятие классов обслуживания, основанных на маркировке IP-пакетов с использованием поля "тип сервиса" (ToS) в их заголовке. Одной из реализаций модели DiffServ является технология многопротокольной коммутации на основе меток (MPLS), которая на сегодняшний день стала одной из основных для построения крупных сетей операторов, предоставляющих услуги с обеспечением качества обслуживания (QoS).

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

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

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

Новые механизмы

Эти дополнения вынесены в отдельные рекомендации:

* Рекомендация RFC 2998 описывает принципы взаимной комбинации двух моделей - интегрированного (IntServ) и дифференцированного (DiffServ) обслуживания. Она расширяет возможности протокола резервирования ресурсов для больших сетей.

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

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

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

В связи с этим в качестве альтернативного решения производители активного сетевого оборудования предлагают различные фирменные механизмы или "доводят до ума" протокол RSVP. Та же Cisco Systems внесла серьезные доработки к существующей рекомендации RSVP, дополнив ее механизмами синхронизации вызовов между протоколами RSVP и H.323, резервирования с учетом применения механизма компрессии заголовков речевых пакетов (cRTP) и маркировки служебных сообщений протокола RSVP с использованием полей DSCP.

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

Об авторе

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





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

бизнес

• Юридические аспекты хранения электронных данных

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

• Технология Hyper-Threading повышает производительность серверов

• Новое в RSVP

• "Песочницы" для Web-серверов

• Тестируем регулировщики трафика территориально распределенных сетей

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

• Абонентские сервисы в контакт-центре

• Обращаем ошибки себе на пользу

• На все руки мастер

сети связи

• Обеспечение безопасности сетей ОКС-7

• "Софтсвич" - это по-нашему!

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

• Развитие стандарта на кабельные системы жилых зданий

• Сети Industrial Ethernet

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

• Обзор решений HIP

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

• "Дэйтлайнер" соединяет

только на сервере

• ETM сделает менее уязвимой телефонную сеть вашей компании


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



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