Resource Reservation Protocol¶

Resource Reservation Protocol (RSVP) — сетевой протокол сигнализации, предназначенный для резервирования сетевых ресурсов (полосы пропускания и буферного пространства) для обеспечения гарантированного качества обслуживания (Quality of Service, QoS) при передаче данных в IP-сетях. Протокол описан в RFC 2205 (1997 год) и используется преимущественно в архитектурах Integrated Services (IntServ).

¶Принцип работы

RSVP работает на транспортном уровне модели OSI, поверх IP-пакетов, и не является транспортным протоколом в классическом понимании — он не передаёт пользовательские данные, а лишь устанавливает и поддерживает состояние резервирования на каждом маршрутизаторе вдоль пути следования потока. Основная особенность RSVP — ориентация на получателя: именно принимающий узел (или приложение) инициирует запрос на резервирование ресурсов, что отличает протокол от многих других схем сигнализации, где запрос исходит от отправителя.

Протокол использует два основных типа сообщений:

• Path — отправляется от отправителя к получателю через все промежуточные маршрутизаторы. Это сообщение содержит описание характеристик трафика (Tspec) и собирает информацию об адресах всех узлов на пути следования.
• Resv — отправляется получателем обратно по тому же маршруту. Это сообщение содержит запрос на резервирование конкретного объёма ресурсов (Rspec) и распространяется в обратном направлении, устанавливая состояние резервирования на каждом маршрутизаторе.

При получении сообщения Resv маршрутизатор проверяет наличие достаточных ресурсов. Если ресурсы доступны, он выделяет их для данного потока и передаёт сообщение дальше к отправителю. Если ресурсов недостаточно, маршрутизатор отправляет получателю сообщение об ошибке (ResvErr), и резервирование не устанавливается.

¶Основные характеристики

• Мягкое состояние (soft state): все резервирования имеют ограниченный срок жизни и должны периодически обновляться сообщениями Path и Resv. При отсутствии обновлений состояние автоматически удаляется, что обеспечивает устойчивость к сбоям и изменениям маршрутизации.
• Мультикастинговая поддержка: RSVP изначально проектировался для поддержки многоадресной рассылки. Резервирование может объединяться (merge) для нескольких получателей одной группы, что позволяет эффективно использовать ресурсы.
• Два класса обслуживания: протокол поддерживает два типа резервирования — контролируемую нагрузку (controlled load), имитирующую поведение незагруженной сети, и гарантированную доставку (guaranteed service), обеспечивающую строгие ограничения на задержку и потери пакетов.

¶Применение

RSVP нашёл применение в следующих областях:

• Телефония и видеоконференции: обеспечение стабильной задержки и минимальных потерь для реального времени.
• MPLS-сети: используется для передачи параметров QoS в рамках технологии Traffic Engineering (RSVP-TE), где протокол резервирует не только ресурсы, но и явные маршруты.
• Интеграция с политиками доступа: RSVP может взаимодействовать с системами управления политиками (Policy Decision Point) для авторизации запросов на резервирование.

¶Ограничения и критика

Главным недостатком RSVP считается плохая масштабируемость. Поскольку протокол требует поддержания состояния на каждом маршрутизаторе для каждого потока, его применение в магистральных сетях с большим числом одновременных потоков приводит к значительным накладным расходам на память и вычислительные ресурсы. Это ограничение привело к тому, что RSVP в чистом виде не получил широкого распространения в глобальном масштабе и уступил место более простым схемам дифференцированного обслуживания (DiffServ), не требующим поддержания состояния потоков. Тем не менее, RSVP-TE остаётся важным компонентом MPLS-сетей, где количество резервируемых LSP-туннелей значительно меньше числа пользовательских потоков.

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

¶Источники

• RFC 2205 «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification»
• RFC 2210 «The Use of RSVP with IETF Integrated Services»
• RFC 3209 «RSVP-TE: Extensions to RSVP for LSP Tunnels»
• Braden R., Zhang L., Berson S., Herzog S., Jamin S. «Resource ReSerVation Protocol (RSVP)», 1997