Резервирование ресурсов

Протокол сигнализации Resource reSerVation Protocol (RSVP) обеспечивает управление резервированием сетевых ресурсов в IP-сети для реализации интегрированных сервисов (Integrated Services, IntServ). Первоначальная его спецификация, разработанная сотрудниками Университета шт. Южная Каролина и компании Xerox, была опубликована консорциумом IETF в 1997 году (RFC 2205). Около трех лет назад появилась обновленная версия RSVP (RFC 2750). Архитектура IntServ впервые описана в 1994 году в документе RFC 1633.

Протокол RSVPпредусматривает два принципиально различных типа сервисов — гарантированный (IntServ Guaranteed) и с контролируемой сетевой нагрузкой (IntServ Controlled). В первом случае речь идет об эмуляции выделенного виртуального канала в IP-сети: потоку гарантируется доступность запрошенной полосы пропускания и одновременно задаются жесткие границы для величины суммарной задержки. Сервис IntServ Guaranteed можно воспринимать как формирование сети коммутации каналов, наложенной на сеть коммутации пакетов. Второй случай аналогичен сервису best effort в условиях незагруженной сети; конкретные диапазоны задержек и других параметров передачи не устанавливаются.

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

Собственно резервирование ресурсов инициируется получателем, который после приема сообщения PATH отправляет в обратном направлении (источнику) запрос RESV. Помимо характеристик трафика, полученных от источника, этот запрос содержит спецификации потока (тип сервиса и ряд вспомогательных параметров) и фильтра (транспортный протокол и номер порта). Две последние спецификации играют роль дескриптора потока.

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

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

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

Выбор режима определяется спецификацией фильтра. Для фиксированного фильтра (Fixed Filter, FF) используется индивидуальное резервирование: каждому отправителю соответствует отдельный запрос RESV, а общая емкость выделенных ресурсов определяется совокупностью запросов к явно заданному набору отправителей. (Если несколько получателей ожидают трафик от одного и того же отправителя, их запросы объединяются, а ресурсы выделяются на разделяемой основе.) Спецификация фильтра с явным указанием отправителей применяется и для разделяемого резервирования (Shared Explicit, SE), только потоки от источников, перечисленных в запросе RESV, используют одни и те же ресурсы. Неявная спецификация (Wildcard Filter, WF) предполагает, что по единому виртуальному каналу будет передаваться трафик от всех отправителей.

Фильтры SE и WF подходят для обработки многоадресного трафика, например при проведении аудиоконференций. Применение FF предпочтительнее для передачи видеосигналов.

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

§ сам по себе протокол RSVP не отвечает за транспортировку или маршрутизацию данных, а лишь управляет этими процессами, а потому может функционировать параллельно с TCP или UDP;

§ RSVP ориентирован только на полудуплексную передачу, и для двустороннего обмена требуется устанавливать два самостоятельных сеанса RSVP;

§ каждый маршрутизатор выделяет ресурсы на ограниченный промежуток времени (soft reservation), в течение которого получатель должен успеть обновить свой запрос RESV. Процедура периодического обновления полезна для оперативного реагирования на изменения маршрутов и состава групп многоадресной рассылки;

§ при передаче трафика через несколько сетей на его пути могут встретиться устройства, не поддерживающие RSVP. Протокол применим и в этом случае (вариант с туннелированием), хотя вне доменов RSVP можно рассчитывать только сервис best effort;

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

С точки зрения поддержки на уровне приложений и сетевых устройств протокол RSVP является, пожалуй, самым сложным из всех аналогичных технологий. Радикальное отступление от принципа best effort позволяет достичь наивысшего уровня сервиса в плане гарантированности параметров передачи, степени детализации при описании запрашиваемых ресурсов и качества обратной связи с приложениями. Применение архитектуры IntServ и протокола RSVP оказывается идеальным выбором для поддержки приложений реального времени, но в других случаях обеспечиваемый уровень QoS становится ненужным, а «цена» (излишняя сложность конкретных реализаций) — неоправданно высокой. Это обстоятельство обусловило появление не столь изощренных методов поддержки QoS в глобальной сетевой среде, одним из которых является DiffServ.