Интегрированное обслуживание и протокол RSVP

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

Рис. 18.3. Резервирование ресурсов по протоколу RSVP

Резервирование в модели IntServ выполняется с помощью уже упоминавшегося прото­кола резервирования ресурсов (RSVP). Это сигнальный протокол, во многом подобный сигнальным протоколам телефонных сетей. Однако специфика дейтаграммных пакетных сетей естественно накладывает свой отпечаток. Так, параметры коммутации в IP-сетях не являются атрибутом резервирования, потому что IP-пакеты в любом случае (при резерви­ровании или без него) будут передаваться маршрутизаторами на основе записей таблицы маршрутизации.

Далее описана процедура резервирования необходимых ресурсов сети с помощью про­токола RSVP, а в табл. 18.1 сведены воедино все упоминаемые в этом описании типы сообщений.

1. Источник данных (компьютер С1 на рис. 18.3) посылает получателям по уникальному или групповому (как на рисунке) адресу специальное РАТН-сообщение, в котором ука­зывает рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки. Эти па­раметры составляют спецификацию трафика источника. РАТН-сообщение передается маршрутизаторами сети в направлении ко всем указанным в групповом адресе получате­лям. В качестве параметров трафика применяются параметры алгоритма ведра маркеров, то есть средняя скорость и глубина ведра. Кроме того, дополнительно могут быть заданы максимально допустимая скорость и предельные размеры пакетов потока.

2. Каждый маршрутизатор, поддерживающий протокол RSVP, получив РАТН-сообщение, фиксирует «состояние пути», которое включает предыдущий адрес источника РАТН- сообщения, то есть последний по времени шаг в обратном направлении (ведущий к ис­точнику). Это необходимо для того, чтобы ответ приемника прошел по тому же пути, что и РАТН-сообщение.

3. После получения РАТН-сообщения приемник отправляет в обратном направлении маршрутизатору, от которого он получил это сообщение, запрос на резервирование ресурсов, то есть RESV-сообщение. На рис. 18.3 показано два приемника, компьютеры С2 и СЗ. В дополнение к спецификациям трафика источника С1 (которые содержат параметры для качественного приема его трафика: верхние и нижние границы про­пускной способности, задержки и вариации задержки) RESV-сообщение дополнительно включает спецификацию запроса приемника, в которой указываются требуемые при­емнику параметры качества обслуживания, и спецификацию фильтра, которая опреде­ляет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта). Вместе спецификации запроса и фильтра представляют собой дескриптор потока, для которого выполняется резервирование. Запрашиваемые параметры QoS в спецификации запроса могут отличаться от ука­занных в спецификации трафика. Например, если приемник решает принимать не все посылаемые источником пакеты, а только их часть (что указывается в спецификации фильтра), то ему нужна, соответственно, меньшая пропускная способность.

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

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

6. Когда последний в обратном направлении маршрутизатор получает RESV-сообщение и принимает запрос, то он посылает подтверждающее сообщение узлу-источнику. При групповом резервировании учитывается тот факт, что в точках разветвления дерева до­ставки несколько резервируемых потоков сливаются в один. Так, в маршрутизаторе R1 в рассматриваемом примере сливаются RESV-сообщения от приемников С2 и СЗ. Если для всех резервируемых потоков запрашивается одинаковая пропускная способность, то она требуется и для общего потока, а если запрашиваются различные величины про­пускной способности, то для общего потока выбирается максимальная.

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

Таблица 18.1. Таблица сообщений протокола резервирования ресурсов (RSVP)

Типы сообщений	Содержание сообщений
РАТН-сообщение от ис­точника к приемнику	Спецификация трафика источника
Спецификация трафика источника	Рекомендуемые параметры для качественного приема своего трафика: верхние и нижние границы пропускной способности, задержки и вариации задержки, параметры алгоритма ведра маркеров, то есть среднюю скорость и глубину ведра, дополнительно могут быть заданы максимально допусти­мая скорость и предельные размеры пакетов потока
Спецификация фильтра	Определяет, к каким пакетам сеанса применять данное резервирование (например, по типу транспортного протокола и номеру порта)
Спецификация запроса приемника	Требуемые приемнику параметры качества обслуживания
Дескриптор потока	Спецификация фильтра плюс спецификация запроса приемника
RESV-сообщение — за­прос на резервирование ресурсов	Спецификация трафика источника плюс дескриптор потока

 

Нужно подчеркнуть, что описанная схема обеспечивает резервирование только в одном направлении. Для того чтобы в рамках пользовательского сеанса данные передавались с за­данным качеством обслуживания также и в обратном направлении, нужно, чтобы приемник и источник поменялись местами и выполнили RSVP-резервирование еще раз.

Для того чтобы параметры резервирования можно было применить затем к трафику дан­ных, необходимо, чтобы RSVP-сообщения и пакеты данных следовали через сеть одним и тем же маршрутом. Это можно обеспечить, если передавать RSVP-сообщения на основе

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

ВНИМАНИЕ

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

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

Для протокола RSVP в настоящее время разработано большое количество расширений, которые делают его пригодным не только для работы в рамках архитектуры RS VP. Одними из наиболее важных являются расширения, относящиеся к инжинирингу трафика. Эти расширения применяются в технологии MPLS, рассматриваемой в главе 20.