Протокол резервирования ресурсов 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, нет необходимости осуществлять явную отмену ненужного более резервирования. Однако рекомендуется, чтобы все конечные станции посылали отменяющее сообщение, если резервирование больше не нужно.

Дата добавления: 2015-07-13