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

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

IGP-маршрутизатор (групповая рассылка) Рис. 20.3. Резервирование ресурсов по протоколу RSVP

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

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

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

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

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

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

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

маршрутизатор запоминает новые параметры резервирования и вычитает их из счетчиков соответствующих свободных ресурсов.

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

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

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

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

ВНИМАНИЕ ----------------------------------------------------------------------------------------------------------------------------------------------

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

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

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