5. 14.2. Интегральное обслуживание IntServ

Главный протокол архитектуры интегрального обслуживания, разработанный IETF, называется протоколом резервирования ресурсов RSVP (Resource reservation Protocol). Как следует из названия, протокол предназначен для резервирования ресурсов. RSVP является протоколом сигнализации, который позволяет приложениям информировать сеть о своих требованиях. На основе этих требований сеть может либо резервировать внутри себя ресурсы, чтобы гарантировать выполнение требований, либо отказать приложению. Протокол RSVP позволяет запрашивать, например, гарантированный показатель трафика, задержку, максимальный уровень потерь блоков данных. Рассмотрим процедуру резервирования по протоколу RSVP (рис. 14.1).

Рис. 14.1. Резервирование ресурсов с помощью RSVP

R1, R2, R3 – маршрутизаторы.

Как показано на рисунке 14.1, протокол RSVP передает информацию с использованием двух типов сообщений: PATH и RESV. Сообщения PATH передаются от отправителя к одному или нескольким получателям и включают в себя:

15. спецификацию потока данных Tspec, которая определяет тип потока данных приложения, входящего в сеть (Т означает трафик);

16. шаблон отправителя (IP-адрес, UDP/TCP порт как опция).

Получив сообщение PATH, получатель передает отправителю сообщение RESV, идентифицируя сеанс, для которого производится резервирование, а также спецификацию Rspec (R означает резервирование, Reserve). Rspec включает уровень QoS, требуемый получателем. После того как резервирование выполнено, маршрутизаторы, находящиеся на маршруте, могут идентифицировать пакеты, принадлежащие к определенному блоку зарезервированных ресурсов, путем анализа следующих полей в заголовке протокола IP и в заголовке транспортного протокола: IP-адрес получателя, порт получателя, IP-адрес отправителя и его порт. Пакеты, идентифицированные таким образом, называются зарезервированным потоком. К пакетам в зарезервированном потоке применяются определенные правила для того чтобы не генерировался больший трафик, чем объявлено в спецификации Тspec. Для пакетов потока также устанавливается соответствующий приоритет обработки с целью обеспечения требуемого уровня обслуживания.

При разработке протокола RSVP предусматривалось резервирование ресурсов для индивидуальных микропотоков приложений. Однако такой подход имеет несколько практических недостатков. При его использовании каждый элемент сети на всем пути следования пакета, включая оконечные системы, должен иметь полную информацию протокола RSVP и участвовать в сигнализации, требуемой механизмом QoS. На каждом сетевом элементе, лежащем на маршруте, должна поддерживаться информация каждого резервирования. Такое требование может привести к потенциальному расширению сети до состояния, когда через базовую IP-сеть будут проходить сотни тысяч потоков. При этом требуется предварительная договоренность при установке канала для каждого потока. Это не позволяет расширить систему в достаточной мере. Поэтому в системах с тысячами потоков интегральное обслуживание применить не удастся. В результате выжило очень мало реализаций RSVP в IP-сетях. Однако этот протокол может выполнить резервирование для объединенных потоков данных. Это позволило использовать протокол RSVP в технологии MPLS.