Введение
Протокол компьютерной сети
Протокол резервирования ресурсов (RSVP) — это протокол транспортного уровня, предназначенный для резервирования ресурсов в сети с использованием модели интегрированных услуг. RSVP работает поверх IPv4 или IPv6 и обеспечивает инициацию резервирования ресурсов получателем для потоков данных многоадресной (multicast) или одноадресной (unicast) передачи. Он не передает данные приложений, но функционирует как управляющий протокол, подобно протоколу управления интернет-сообщениями (ICMP) или протоколу управления группами в интернете (IGMP). RSVP может использоваться хостами и маршрутизаторами для запроса или предоставления определенных уровней качества обслуживания (QoS) для потоков данных приложений. RSVP определяет, как приложения выполняют резервирование и как они могут освободить зарезервированные ресурсы, когда они больше не требуются. Операции RSVP обычно приводят к резервированию ресурсов в каждом узле на пути следования. RSVP не является протоколом маршрутизации, но был разработан для взаимодействия с существующими и будущими протоколами маршрутизации. В 2003 году основные усилия по разработке были перенесены с RSVP на RSVP TE для инженерии трафика. Следующий шаг в сигнализации (NSIS) был предложен в качестве замены RSVP.
RSVP can be used by hosts and routers to request or deliver specific levels of quality of service (QoS) for application data streams. RSVP defines how applications place reservations and how they can relinquish the reserved resources once no longer required. RSVP operations will generally result in resources being reserved in each node along a path. RSVP is not a routing protocol but was designed to interoperate with current and future routing protocols. In 2003, development effort was shifted from RSVP to RSVP TE for teletraffic engineering. Next Steps in Signaling (NSIS) was a proposed replacement for RSVP.
Основные атрибуты
RSVP запрашивает ресурсы для симплексных потоков: потока трафика только в одном направлении от отправителя к одному или нескольким получателям. RSVP не является протоколом маршрутизации, но работает с существующими и будущими протоколами маршрутизации. RSVP ориентирован на получателя, поскольку именно получатель потока данных инициирует и поддерживает резервирование ресурсов для этого потока. RSVP поддерживает мягкое состояние (для поддержания резервации на каждом узле требуется периодическое обновление) резервирования ресурсов хостов и маршрутизаторов, что обеспечивает динамическую автоматическую адаптацию к изменениям в сети. RSVP предоставляет несколько стилей резервирования (набор опций резервирования) и позволяет добавлять новые стили в будущих версиях протокола для поддержки различных приложений. RSVP передает и поддерживает параметры управления трафиком и политикой, которые не обрабатываются RSVP.
Основные понятия
Две ключевые концепции модели резервирования RSVP — flowspec и filterspec.
Операция
Хост RSVP, которому необходимо отправлять поток данных с определенным уровнем обслуживания (QoS), будет передавать сообщение пути RSVP каждые 30 секунд, которое будет распространяться по заранее установленным рабочим протоколом маршрутизации одноадресным или многоадресным маршрутам. Если сообщение пути достигает маршрутизатора, не поддерживающего RSVP, этот маршрутизатор пересылает сообщение, не анализируя его содержимое, и не резервирует ресурсы для этого потока. Устройства, желающие получить этот поток, отправляют соответствующее сообщение resv (сокращение от reserve), которое затем проходит по пути обратно к отправителю. Сообщение resv содержит flowspec – спецификацию потока. В сообщении resv также содержится объект filterspec, определяющий пакеты, которым будет предоставлен запрошенный QoS, указанный в flowspec. Простой filterspec может включать только IP-адрес отправителя и, опционально, его UDP или TCP порт. Когда маршрутизатор получает сообщение RSVP resv, он выполняет следующие действия:
Выделяет ресурсы на основе параметров запроса. Механизм управления доступом обрабатывает параметры запроса и может либо дать указание классификатору пакетов правильно обрабатывать выбранное подмножество пакетов данных, либо согласовать с верхним уровнем способ обработки пакетов. Если запрос не может быть удовлетворен, отправителю отправляется сообщение об отказе. Пересылает запрос вверх по потоку (в направлении отправителя). На каждом узле flowspec в сообщении resv может быть модифицирован пересылающим узлом (например, в случае резервирования многоадресного потока запросы на резервирование могут быть объединены). Затем маршрутизаторы сохраняют информацию о потоке и, опционально, настраивают контроль трафика в соответствии с flowspec. Если в течение определенного времени не поступает подтверждений, резервирование истекает и отменяется. Это решает проблему, возникающую при аварийном завершении работы или отключении отправителя или получателя без предварительной отмены резервирования.
Make a reservation based on the request parameters. Admission control processes the request parameters and can either instruct the packet classifier to correctly handle the selected subset of data packets or negotiate with the upper layer how the packet handling should be performed. If the cannot be supported, a reject message is sent to let the listener know. Forward the request upstream (in the direction of the sender). At each node the flowspec in the resv message can be modified by a forwarding node (e. g. in the case of a multicast flow reservation the reservations requests can be merged). The routers then store the nature of the flow and optionally set up policing according to the flowspec for it. If nothing is heard for a certain length of time the reservation will time out and will be canceled. This solves the problem if either the sender or the receiver crash or are shut down without first canceling the reservation.