Протокол резервирования ресурсов

Протокол резервирования ресурсов ( RSVP ) — это транспортный уровень. ^{[ 1 ]} протокол, предназначенный для резервирования ресурсов в сети с использованием модели интегрированных услуг . RSVP работает через IPv4 или IPv6 и обеспечивает инициируемую получателем настройку резервирования ресурсов для многоадресных или одноадресных потоков данных. Он не передает данные приложения, но аналогичен протоколу управления, например протоколу управляющих сообщений Интернета (ICMP) или протоколу управления группами Интернета (IGMP). RSVP описан в РФК 2205 .

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

В 2003 году усилия по разработке были перенесены с RSVP на RSVP-TE для проектирования телетрафика . Следующие шаги в сигнализации (NSIS) были предложенной заменой RSVP.

Основные атрибуты

RSVP запрашивает ресурсы для симплексных потоков: потока трафика только в одном направлении от отправителя к одному или нескольким получателям.
RSVP не является протоколом маршрутизации, но работает с текущими и будущими протоколами маршрутизации.
RSVP ориентирован на получателя, поскольку получатель потока данных инициирует и поддерживает резервирование ресурсов для этого потока.
RSVP поддерживает мягкое состояние (резервирование на каждом узле требует периодического обновления) резервирования ресурсов хоста и маршрутизаторов, тем самым поддерживая динамическую автоматическую адаптацию к изменениям в сети.
RSVP предоставляет несколько стилей резервирования (набор параметров резервирования) и позволяет добавлять будущие стили в версии протокола для соответствия различным приложениям.
RSVP передает и поддерживает параметры управления трафиком и политикой, которые непрозрачны для RSVP. ^{[ нужны дальнейшие объяснения ]}

История и связанные стандарты

Основные концепции RSVP были первоначально предложены в 1993 году. ^{[ 2 ]}

RSVP описан в серии документов RFC от IETF:

RFC 2205 : Функциональная спецификация версии 1 была описана в RFC 2205 (сентябрь 1997 г.) IETF . Версия 1 описывает интерфейс управления доступом (трафиком), который основан «только» на доступности ресурсов. Позже RFC2750 расширил поддержку контроля доступа.
RFC 2210 определяет использование RSVP с контролируемой нагрузкой RFC 2211 и гарантированными службами управления QoS RFC 2212. Подробности в разделе «Интегрированные услуги» . Также определяет использование и формат данных объектов данных (которые несут информацию о резервировании ресурсов), определенных RSVP в RFC 2205.
RFC 2211 определяет поведение сетевых элементов, необходимое для предоставления услуг с контролируемой нагрузкой.
RFC 2212 определяет поведение сетевого элемента, необходимое для предоставления гарантированных услуг QoS.
RFC 2750 описывает предлагаемое расширение для поддержки управления доступом на основе общей политики в RSVP. Расширение включало спецификацию объектов политики и описание обработки событий политики. (январь 2000 г.).
RFC 3209 , «RSVP-TE: Расширения RSVP для туннелей LSP» (декабрь 2001 г.).
RFC 3473 , «Расширения протокола резервирования ресурсов сигнализации с универсальной многопротокольной коммутацией по меткам (GMPLS) и инженерии трафика (RSVP-TE)» (январь 2003 г.).
RFC 3936 «Процедуры изменения ( ресурсов резервирования практики и определяет RSVP ) » (октябрь 2004 г.) описывает текущие лучшие протокола процедуры изменения RSVP.
RFC 4495 , «Расширение протокола резервирования ресурсов (RSVP) для уменьшения пропускной способности потока резервирования» (май 2006 г.), расширяет RSVP, позволяя уменьшить пропускную способность существующего резервирования вместо разрушения резервирования.
RFC 4558 , «Протокол резервирования ресурсов на основе идентификатора узла (RSVP) Здравствуйте: поясняющее заявление» (июнь 2006 г.).

Ключевые понятия

Двумя ключевыми концепциями модели резервирования RSVP являются спецификация потока и спецификация фильтра .

расход

RSVP резервирует ресурсы для потока. Поток идентифицируется адресом назначения, идентификатором протокола и, необязательно, портом назначения. В многопротокольной коммутации по меткам (MPLS) поток определяется как путь с коммутацией меток (LSP). Для каждого потока RSVP также определяет конкретное качество обслуживания (QoS), требуемое потоком. Эта информация QoS называется спецификацией потока , и RSVP передает спецификацию потока от приложения к хостам и маршрутизаторам по пути. Затем эти системы анализируют спецификацию потока , чтобы принять и зарезервировать ресурсы. Спецификация потока состоит из:

Класс обслуживания
Спецификация резервирования — определяет качество обслуживания.
Спецификация трафика — описывает поток данных.

Спецификация фильтра

Спецификация фильтра определяет набор пакетов, на которые должна влиять спецификация потока (т. е. пакеты данных для получения QoS, определенного спецификацией потока). Спецификация фильтра обычно выбирает подмножество всех пакетов, обрабатываемых узлом. Выбор может зависеть от любого атрибута пакета (например, IP-адреса и порта отправителя).

В настоящее время определены следующие стили резервирования RSVP:

Фиксированный фильтр – резервирует ресурсы для определенного потока.
Общий явный — резервирует ресурсы для нескольких потоков и все разделяют ресурсы.
Фильтр подстановочных знаков — резервирует ресурсы для потока общего типа без указания потока; все потоки разделяют ресурсы

Запрос резервирования RSVP состоит из спецификации потока и спецификации фильтра , и эта пара называется дескриптором потока . Спецификация потока устанавливает параметры планировщика пакетов на узле, а спецификация фильтра устанавливает параметры классификатора пакетов.

Сообщения

Существует два основных типа сообщений:

Сообщения о пути ( путь )

Сообщение о пути отправляется от хоста-отправителя по пути данных и сохраняет состояние пути в каждом узле по пути.

Состояние пути включает IP-адрес предыдущего узла и некоторые объекты данных:

шаблон отправителя для описания формата данных отправителя в виде спецификации фильтра. ^{[ 3 ]}
sender tspec для описания характеристик трафика потока данных
adspec , который содержит рекламные данные (более подробную информацию см. в RFC 2210).

Сообщения о резервировании ( resv )

Сообщение resv отправляется от получателя к хосту-отправителю по обратному пути передачи данных. На каждом узле IP-адрес назначения сообщения resv изменится на адрес следующего узла на обратном пути, а IP-адрес источника на адрес предыдущего узла на обратном пути.

Сообщение resv включает объект данных flowspec , который идентифицирует ресурсы, необходимые потоку.

Объекты данных в сообщениях RSVP могут передаваться в любом порядке. Полный список сообщений и объектов данных RSVP см. в RFC 2205.

Операция

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

Те, кто хочет их прослушать, отправляют соответствующее сообщение resv (сокращение от «reserve »), которое затем прослеживает путь обратно к отправителю. Сообщение resv содержит спецификацию потока . Сообщение resv также имеет объект filterspec ; он определяет пакеты, которые получат запрошенное качество обслуживания, определенное в спецификации потока. Простая спецификация фильтра может включать только IP-адрес отправителя и, при необходимости, его порт UDP или TCP. Когда маршрутизатор получает сообщение RSVP resv, он:

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

Если в течение определенного времени ничего не будет слышно, резервирование истечет и будет отменено. Это решает проблему, если отправитель или получатель выходят из строя или отключаются без предварительной отмены резервирования.

Другие особенности

Честность: К сообщениям RSVP добавляется дайджест сообщения, созданный путем объединения содержимого сообщения и общего ключа с использованием алгоритма дайджеста сообщения (обычно MD5 ). Ключ может быть распространен и подтвержден с использованием двух типов сообщений: запрос на проверку целостности и ответ на проверку целостности .
Отчеты об ошибках: Когда узел обнаруживает ошибку, сообщение об ошибке генерируется с кодом ошибки и распространяется вверх по обратному пути к отправителю.
Информация о потоке ответа на приглашение: Два типа диагностических сообщений позволяют оператору сети запрашивать информацию о состоянии RSVP для определенного потока.
Диагностический центр: Расширение стандарта, которое позволяет пользователю собирать информацию о состоянии RSVP на пути. ^{[ 4 ]}

RFC

РФК 2205
РФК 2210
РФК 2211
РФК 2212

Ссылки

^ Гарретт, Авива; Дренан, Гэри; Моррис, Крис (2002). Полевое руководство и справочник по Juniper Networks . Аддисон-Уэсли Профессионал. п. 583. ИСБН 9780321122445 .
^ Чжан Л., Диринг С., Эстрин Д., Шенкер С. и Д. Заппала, «RSVP: новый протокол резервирования ресурсов», сеть IEEE, сентябрь 1993 г.
^ Лися, Чжан; Стив, Берсон; Шай, Герцог; Суги, Джамин (сентябрь 1997 г.). Протокол резервирования ресурсов (RSVP) — функциональная спецификация версии 1 . п. 19. дои : 10.17487/RFC2205 . РФК 2205 .
^ Диагностические сообщения RSVP . дои : 10.17487/RFC2745 . РФК 2745 .

Джон Эванс; Кларенс Филсфилс (2007). Развертывание QoS IP и MPLS для мультисервисных сетей: теория и практика . Морган Кауфманн. ISBN 978-0-12-370549-5 .

Внешние ссылки

«Протокол резервирования ресурсов» . Циско. Архивировано из оригинала 5 июля 2017 г. Проверено 16 февраля 2011 г.
Навин Джой (17 июня 2002 г.). «RSVP обеспечивает качество обслуживания» . Сетевой мир . Архивировано из оригинала 29 июня 2013 г. Проверено 14 февраля 2012 г.
«Проект РСВП» . Институт информационных наук Университета Южной Калифорнии. Архивировано из оригинала 27 апреля 2017 г.

[1] Гарретт, Авива; Дренан, Гэри; Моррис, Крис (2002). Полевое руководство и справочник по Juniper Networks . Аддисон-Уэсли Профессионал. п. 583. ИСБН 9780321122445 .

[RSVP93-2] Чжан Л., Диринг С., Эстрин Д., Шенкер С. и Д. Заппала, «RSVP: новый протокол резервирования ресурсов», сеть IEEE, сентябрь 1993 г.

[3] Лися, Чжан; Стив, Берсон; Шай, Герцог; Суги, Джамин (сентябрь 1997 г.). Протокол резервирования ресурсов (RSVP) — функциональная спецификация версии 1 . п. 19. дои : 10.17487/RFC2205 . РФК 2205 .

[4] Диагностические сообщения RSVP . дои : 10.17487/RFC2745 . РФК 2745 .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]