Протокол резервирования ресурсов RSVP

Интегрированная модель предоставления услуг использует протокол резервирования ресурсов RSVP для того, чтобы устанавливать качество обслуживания и управлять им методами резервирования. Протокол RSVP описан в документе RFC 2205 и имеет статус предложенного стандарта. Поскольку RSVP – это протокол управления IP-сетью, а не протокол маршрутизации, то необходимо, чтобы совместно с ним работал один из существующих протоколов маршрутизации. Протокол RSVP функционирует на уровне выше протоколов IP и UDP и должен быть поддержан на всех маршрутизаторах на пути резервирования. Ключевые понятия протокола RSVP – это потоки и резервирование ресурсов.

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

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

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

Для резервирования ресурсов с помощью протокола RSVP получатели посылают запросы на резервирование ресурсов к отправителям с учетом своих возможностей. Например, пользователь быстрого автоматизированного рабочего места и пользователь, у которого есть устаревший компьютер, хотят получить высококачественный видеопоток со скоростью 30 кадров в секунду (соответствующая скорость передачи данных – 1.5 Мбит/с). Автоматизированное рабочее место имеет достаточно ресурсов центрального процессора для того, чтобы в полном объеме декодировать поток видео, но вот устаревший компьютер может декодировать только 10 кадров в секунду. Если в такой ситуации видеосервер посылает сообщения двум своим клиентам о том, что он может обеспечивать поток видео со скоростью 1.5 Мбит/с, то автоматизированное рабочее место может в ответ выслать просьбу о резервировании полосы со скоростью 1.5 Мбит/с. Устаревший компьютер не нуждается в полной ширине полосы пропускания для своего потока, потому что он не сможет декодировать все кадры. Поэтому он посылает просьбу о резервировании потока с 10 кадрами в секунду, то есть о скорости 500 Кбит/с.

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

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

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

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

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

На каждом маршрутизаторе запрос на резервирование ресурсов инициализирует два действия:

q Резервирование QoS. Процесс резервирования протокола RSVP передает запрос к контролю доступа (policy control) и контролю политики (policy control) на маршрутизаторе. Контроль доступа проверяет наличие у маршрутизатора необходимых ресурсов для резервирования требуемого QoS, а контроль политики проверяет, имеет ли приложение разрешение делать запросы на предоставление указанного QoS. Если одна из этих проверок дает отрицательный ответ, то резервирование отклоняется и процесс резервирования протокола RSVP возвращает сообщение об ошибке RES-VErr соответствующему получателю. Если обе проверки прошли успешно, то маршрутизатор использует информацию из спецификации фильтра в сообщении RESV для установки параметров классификатора пакетов, а информацию спецификации потока – для установления параметров планировщика пакетов. После того как классификатор пакетов «признает» пакеты, которые принадлежат этому потоку, планировщик пакетов получит желаемые параметры QoS, определенные в технических требованиях к потоку. На рис. 14.2 показан процесс резервирования ресурсов протоколом RSVP.

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

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

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

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

Путь и резервирование могут также быть удалены при помощи отменяющих (teardown) сообщений RSVP. Существуют два типа отменяющих сообщений:

q Сообщение PathTear. Сообщения PathTear проходят вниз по сети из точки инициирования ко всем получателям, отменяя резервирование на всех устройствах, поддерживающих протокол RSVP;

q Сообщение ResvTear. Сообщения ResvTear проходят вверх по сети из точки инициирования ко всем отправителям, отменяя резервирование на всех маршрутизаторах и рабочих станциях.

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

Стили резервирования

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

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

Таблица 14.1. Стили резервирования

Методы выбора отправителей следующие:

q Фильтр указателей (Wildcard-Filter, WF). Фильтр указателей использует опции общедоступного резервирования и выбор отправителя по указателям. Этот стиль резервирования устанавливает общее резервирование для всех отправителей в данном сеансе связи. Резервирование от различных отправителей объединяется вместе по пути таким образом, чтобы отправителей достиг только запрос на резервирование наибольших ресурсов. Резервирование по указателям отправляется вверх по сети всем конечным станциям-отправителям. Если в сеансе связи появляются новые отправители, например, к видеоконференции присоединяются сотрудники, резервирование расширяется и для этих отправителей.

q Устанавливаемый фильтр (Fixed-Filter, FF). Устанавливаемый фильтр использует опции, отличные от резервирования с явным выбором отправителя. Это означает, что в зависимости от отправителя используется различное резервирование. Пакеты от разных отправителей, которые участвуют в одном сеансе связи, задействуют раздельное резервирование.

q Общедоступный явный (Shared-Explicit, SE). Общедоступный явный метод использует опции общедоступного резервирования и явного выбора отправителя. Это означает, что общее резервирование охватывает потоки от указанного подмножества отправителей. Поэтому список отправителей должен быть включен в запрос на резервирование от получателя.

Резервирование, установленное методами WF и SE, используется главным образом для групповых приложений. Для этого типа приложений маловероятно, что несколько источников информации будут передавать данные одновременно, так, чтобы было необходимо резервировать параметры QoS для каждого отправителя.

Например, при проведении аудиоконференции, которая состоит из 5 участников, каждый участник посылает поток данных со скоростью 64 Кбит/с. При резервировании методом FF все члены конференции должны установить 4 запроса на резервирование полосы в 64 Кбит/с для потоков от других участников. Но на аудиоконференции редко одновременно говорят более двух человек. Поэтому было бы достаточно зарезервировать полосу пропускания в 128 Кбит/с для всех участников. В противном случае резко понижается эффективность использования программного обеспечения аудиоконференции, так как много ресурсов направляется на подавление пауз. Такая схема может быть реализована, если технические средства каждого участника способны поддерживать заданный уровень резервирования.

При использовании метода SE все участники должны обладать способностью явно идентифицировать всех других участников аудиоконференции. В методе FF резервированием охвачены все отправители, которые соответствуют техническим требованиям резервирования. Если, например, звуковой адаптер для передачи голоса посылает пакеты данных специальному TCP/IP-порту, получатели могут проводить резервирование по методу FF для всех пакетов с этим портом адресата.

Развитие сетей с IS

Все большее число производителей маршрутизаторов включают поддержку протокола RSVP в свои изделия. Но для обеспечения интегрированных услуг (Integrated Services, IS) для большой группы пользователей все маршрутизаторы в сети должны поддерживать протокол RSVP.

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

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

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

Дифференцированные услуги

Концепцию предоставления дифференцированных услуг (Differentiated Services, DS) развивает в настоящее время рабочая группа IETF DS. Технические требования для DS определены в некоторых проектах группы IETF. Здесь мы можем дать только обзор базовых идей, заложенных в обеспечение сервисного дифференцированного обслуживания в Internet. Поскольку этот метод все еще находится в стадии развития, некоторые из рассмотренных технических требований могут быть изменены на конечной стадии определения дифференцированных услуг.

Цель внедрения и развития DS состоит в обеспечении дифференцированными услугами трафика Internet с возможностью поддержки различных типов приложений и определенных бизнес-требований. DS предлагает передачу трафика с предсказуемыми параметрами (задержкой, пропускной способностью, потерями пакетов и т. д.). Различие между предоставлением интегрированных услуг и дифференцированных услуг в том, что при предоставлении DS обеспечивается масштабируемое сервисное разделение без необходимости выделения потоков и проведения сигнализации при каждом переходе. Поэтому нет необходимости проводить уникальное резервирование параметров QoS для каждого потока. При работе с DS трафик Internet разбивают на различные классы с различными требованиями к QoS.

Центральный компонент DS – соглашение об уровне сервиса (Service Level Agreement, SLA). SLA – это сервисный контракт между клиентом и провайдером услуг, который определяет подробный перечень предоставляемых услуг. Клиентом может быть отдельный пользователь, организация или любой другой объект DS. Провайдер услуг должен гарантировать, что трафик клиента, с которым заключено SLA, получит оговоренные параметры QoS. Поэтому администрация сети провайдера услуг должна установить соответствующую сервисную политику и проводить оценку предоставляемых услуг для того, чтобы гарантировать согласованную передачу трафика.

Для того чтобы отличать пакеты данных, принадлежащих разным клиентам, устройства, поддерживающие DS, изменяют определенное поле в пакетах IP. Байт DS в каждом пакете IP используется для того, чтобы отметить те пакеты, которые должны пройти соответствующую обработку в каждом сетевом узле. Байт DS расположен в октете TOS в заголовке протокола IPv4 и в поле класса трафика в заголовке протокола IPv6. Весь сетевой трафик внутри домена получает обслуживание в зависимости от своего класса, который определен в байте DS.

Для использования услуг, предусмотренных SLA, в сети должны быть реализованы механизмы:

q установки битов в байте DS (поле TOS), на основании которых в сети определяются административные границы;

q использования этих бит для определения способа обработки этих пакетов маршрутизаторами внутри сети;

q создание условий для прохождения отмеченных пакетов в заданных сетевых границах в соответствии с требованиями QoS для каждого класса обслуживания.

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