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

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

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

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

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


Rambler's Top100

  

RSVP — гарантия качества обслуживания в сетях TCP/IP

А. Е. Федотов

День ото дня растет популярность нового поколения приложений — приложений мультимедиа. Однако традиционные сети, как правило, не обеспечивают необходимого качества обслуживания (Quality of Service, QoS) для полноценной эксплуатации таких приложений. Под качеством обслуживания обычно понимают интеграцию ряда параметров, основные из которых — пропускная способность соединения и время задержки.

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

Понятно, что приложения мультимедиа предъявляют специфические требования к пропускной способности и времени задержки. Чтобы предоставить приложению определенное качество обслуживания, необходимо зарезервировать сетевые ресурсы, обеспечивающие выполнение предъявляемых требований. Для этого Инженерной проблемной группой Internet (Internet Engineering Task Force) разработан протокол Resource ReserVation Protocol (RSVP).

Одним из активных разработчиков продуктов, поддерживающих протокол RSVP, является фирма Cisco Systems. Так, уже в начале 1996 г. ею выпущена первая версия системного ПО, поддерживающего RSVP. В устройствах фирмы Cisco этот протокол, как правило, работает совместно с алгоритмом управления трафиком WFQ (Weighted Fair Queuing), который динамически распределяет приоритеты для потоков данных, обеспечивая необходимые им полосы пропускания и времена задержек.

Основные понятия

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

Протокол RSVP запрашивает ресурсы для симплексных потоков данных, т. е. требует выделения ресурсов только в одном направлении. Он функционирует над протоколом IP (IPv4 или IPv6) и является протоколом транспортного уровня. Однако RSVP не передает данные прикладных программ и подобно протоколам ICMP (Internet Control Message Protocol) и IGMP (Internet Group Management Protocol) или протоколам маршрутизации относится, скорее, к протоколу управления в сети Internet. Так же как и программы маршрутизации, программа, реализующая RSVP (агент RSVP), обычно выполняется в фоновом режиме. RSVP не является протоколом маршрутизации. Он разработан для совместного функционирования с уже действующими и вновь создаваемыми одно- и многоадресными (групповыми) протоколами маршрутизации. Для выбора маршрутов агент RSVP консультируется с локальной базой данных маршрутизации. В случае потребности в многоточечном соединении, чтобы войти в группу, хост посылает сообщения протокола IGMP и только после этого отправляет сообщения протокола RSVP для резервирования ресурсов по путям передачи данных этой группы. Протоколы маршрутизации определяют пути следования пакетов, а RSVP затрагивает только качество их обслуживания.

Любой узел, способный резервировать ресурсы сети, пропускает входящие пакеты данных через классификатор пакетов (packet classifier), который определяет маршрут и класс обслуживания для каждого из них (рис. 1). На исходящей стороне планировщик пакетов (packet scheduler) принимает решение об их пересылке, обеспечивая обещанное качество обслуживания.

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

Пропускную способность таких сред передачи, как, скажем, арендованные линии, планировщик пакетов распределяет сам.

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

В каждом узле агент RSVP связывается с модулем управления доступом (admission control) и административным модулем (policy control). Модуль управления доступом проверяет наличие ресурсов для удовлетворения запрашиваемому качеству обслуживания. Административный модуль проверяет права пользователя на резервирование ресурсов. Если обе проверки прошли успешно, то для обеспечения желаемого качества обслуживания агент RSVP устанавливает параметры в классификаторе и планировщике пакетов. Если хотя бы одна из проверок окажется неудачной, то агент RSVP возвращает сообщение об ошибке процессу прикладной программы, инициировавшей запрос.

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

Узлы-получатели

Узлы-получатели, нуждающиеся в повышенном качестве обслуживания при получении трафика, например, приложений мультимедиа, должны знать, какая адресация протокола IP (одно- или многоадресная) применяется для передачи данных, в которых они заинтересованы. Эти узлы используют протокол IGMP для вступления в многоадресную группу, либо открывают соединения по протоколу TCP или UDP для одноадресной передачи трафика. В начале процесса приема информации они получают от сети либо сообщение Path протокола RSVP, либо информацию о соединении, доставленную протоколом TCP. После этого определяется тип ожидаемых данных.

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

На основании информации, содержащейся в сообщении Resv, происходят резервирование полосы пропускания и установка необходимых параметров формирования очереди.

Узлы-отправители

Узлы-отправители периодически генерируют сообщение Path, содержащее информацию, необходимую как для узла-получателя (чтобы он смог сформировать сообщение Resv), так и для других узлов сети. Сообщение Path содержит:

· адрес(а) назначения;

· идентификатор резервирования;

· адрес IP предыдущего перехода (используется при пересылке сообщений Resv);

· шаблоны для идентификации трафика отправителя;

· описание (спецификацию) трафика отправителя.

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

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

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

Остановимся на нескольких примерах, иллюстрирующих функционирование протокола RSVP.

Примеры функционирования

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

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

Узлы A и В периодически посылают сообщения Path протокола RSVP, содержащие информацию о своем трафике. В свою очередь, узел С передает сообщения Resv протокола RSVP, запрашивающие резервирование полосы пропускания для получения видеоинформации от узлов A и B.

Маршрутизатор D определяет, к примеру, что ЛВС, содержащая узел С, имеет достаточную полосу пропускания и посылает сообщение Resv маршрутизатору C.

Маршрутизатор C приходит к заключению о существовании достаточной полосы пропускания (600 Кбит/с + 600 Кбит/с = 1,2 Мбит/с < 1,536 Мбит/с) на линии T1 к маршрутизатору D и устанавливает параметры формирования очереди, предоставляющие 78% пропускной способности этой линии для передачи видеоинформации. Он также подыскивает различные пути к узлам A и B, дублирует сообщения Resv и передает их маршрутизаторам A и B.

Маршрутизатор A определяет, что величина полосы пропускания на линии Т1 к маршрутизатору С достаточна для передачи трафика от узла A, устанавливает параметры формирования очереди, предоставляющие 39% пропускной способности линии T1 для передачи видеоинформации, а затем передает сообщение Resv узлу A.

Аналогичны действия и маршрутизатора B. Он также определяет, что величина полосы пропускания на линии Т1 к маршрутизатору С достаточна для передачи трафика от узла В, устанавливает параметры формирования очереди, дающие право на захват 39% пропускной способности линии T1 для передачи видеоинформации, и затем передает сообщение Resv узлу В. Однако, это не может не сказаться на передаче файлов большого объема. Появление видеоинформации на линии вызовет вынужденное замедление передачи файлов, поскольку предпочтение будет отдано потоку видеоинформации.

Пример 2. Предположим, что в некой сети узлы А и В (узлы-отправители) передают некоторому числу других узлов (узлы-получатели) потоки видеоинформации со скоростью 150 Кбит/с каждый (рис. 4). Появляется новый узел (узел С), который также хочет получать видеоинформацию, передаваемую узлами А и В.

Как и в примере 1, узел С использует протокол IGMP, чтобы послать запрос на включение в группу просмотра видеоинформации. Однако в этом случае пропускная способность сети не позволяет в полной мере удовлетворить потребности узла С, так как суммарный поток видеоинформации от узлов А и В (300 Кбит/с) превышает пропускную способность сети на участке между маршрутизаторами С и D (256 Кбит/с). Кроме того, на этом участке весьма вероятно присутствие других видов трафика.

Узлы A и B периодически посылают сообщения Path, содержащие информацию о типе генерируемого трафика. Узел С определяет, скажем, что трафик узла A для него важнее, и хочет улучшать обслуживание только этого трафика. После получения сообщения Path от узла A узел С может инициализировать резервирование ресурса для передачи от него трафика.

Такое резервирование, вероятно, не окажет серьезного влияния на линию T1 на участке между маршрутизаторами A и C, поскольку резервируемая полоса пропускания составит лишь 10% от общей полосы пропускания этой линии. Однако для линии с пропускной способностью 256 Кбит/с эффект от такого резервирования будет куда серьезнее: маршрутизатор C скорректирует формирование очереди таким образом, чтобы гарантировать передачу видеоинформации, а это потребует задействовать всю полосу пропускания за счет прекращения пересылки всех других данных. Таким образом, качество обслуживания трафика узла B будет неудовлетворительным.

Если же узел С попытается запросить аналогичную степень резервирования и для трафика узла B, то маршрутизатор C уведомит его, что пропускная способность линии передачи исчерпана.

***

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


распечатать статью




  
7 '1996
СОДЕРЖАНИЕ

колонка редактора

• Камо грядеши, сетевой компьютер?

локальные сети

• Новатор или умеренный консерватор?

• LANtegrity — новое средство защиты серверов NetWare

• Контроль за работой сервера

• Нелегкое бремя сетевого планирования

• Основы построения структурированной кабельной системы. Часть I

• Накопители DAT

• Инфракрасная последовательная связь

• NetWare/IP разгружает распределенную сеть

корпоративные сети

• Услуги связи в сетях АТМ

• RSVP — гарантия качества обслуживания в сетях TCP/IP

• Эх, дороги...

• ЛВС: коммутатор, маршрутизатор... и толстый-толстый слой программного обеспечения

• Гарантированное качество обслуживания в сетях АТМ и TCP/IP

услуги сетей связи

• Многофункциональные мультиплексоры и системы телефонной сигнализации

• Цифровые каналы для распределенных компьютерных сетей

• Роуминг и сотовый пейджинг

• Технологии коммуникаций мультимедиа

• Архитектуры и технологии систем беспроводного абонентского доступа

• CDMA. По пути обманутых надежд

• Передача речи по сетям Frame Relay

• Что мешает внедрению ISDN

интернет и интрасети

• Мир TCP/IP. Протокол SNMP

• Готовьте “виртуальный кошелек”

• ILTF на пути к мировому порядку ХХI века

• MIME: передача двоичных файлов через Internet

приложения клиент-сервер

• Средства разработки приложений для Internet

• Informix примеpяет “перчатки” MobileWare

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

• Системы бесперебойного питания

• Передача конфиденциальной информации в корпоративных сетях

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

• Sniffer 5.0: все лучше с годами Семейство TurboStack фирмы Allied Telesyn International, Семейство стековых коммутаторов Visage, Elite 23: рекордная емкость, Optivity 7.0 и StackProbe: коммутируемые сети в надежных руках

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

• На пороге компьютеризации общения

• Пять способов улучшить доступ к Web-серверу



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