Qos rsvp что это за служба
Протокол RSVP
Важно отметить, что RSVP не является протоколом маршрутизации. Он работает совместно с протоколами маршрутизации и создает вдоль маршрутов, вычисляемых при помощи последних, эквиваленты списков динамического доступа. Поэтому применение RSVP в существующей сети не требует перехода на новый протокол маршрутизации.
Потоки данных протокола RSVP
1. Гарантированная доставка.
2. Гарантированная скорость.
3. Гарантированная задержка.
Рис. 50.1. В протоколе RSVP информация об узле доставляется получателям вместе с потоками данных
Режим негарантированной доставки (best-effort traffic) представляют собой традиционные потоки данных протокола IP. Этот режим применяется при передаче файлов (например, электронной почты), монтировании дисков, интерактивной регистрации, а также при электронных транзакциях. Эти приложения требуют гарантированной доставки данных независимо от того, сколько времени на это потребуется. Для упорядочения принятых случайным образом дейтаграмм и для запроса повторной передачи потерянных и искаженных дейтаграмм передача данных гарантированной доставки опирается на собственные механизмы протокола TCP.
Режим гарантированной скорости (rate-sensitive traffic) требует гарантированной скорости передачи от источника к получателю. Примером такого приложения являются видеоконференции Н.323, работающие под управлением ISDN (Н.320) или ATM (Н.310), но применяемые также в Internet и во многих интранет-сетях протокола IP. Шифрование Н.323 имеет постоянную (или почти постоянную)
скорость и требует постоянной скорости передачи, такой как в сети с коммутацией каналов. IP-сети по своей природе является сетями с коммутацией пакетов. Им не хватает механизмов для поддержки постоянной битовой скорости обслуживания потоков данных любых приложений. обеспечивает постоянную битовую скорость обслуживания в сети с коммутацией благодаря уровню обслуживания с гарантированной скоростью. Эту службу иногда называют службой гарантированной скорости.
Режим гарантированной максимальной задержки (delay-sensitive traffic) применяется к потокам данных, требующим своевременной доставки и соответствующего изменения скорости. Например, скорость передачи видео MPEG-II колеблется от 3 до 7 Мбит/с, в зависимости от того, насколько интенсивно изменяется изображение. Если на экране показывают окрашенную стену, то достаточно 3 Мбит/с, а для океанских волн потребуется 7 Мбит/с. Источник видеосигнала MPEG-II посылает ключевые и дельта-фреймы. Обычно в секунду передается 1 или 2 ключевых фрейма с изображением всей картинки и от 13 до 28 дельта-фреймов, описывающих изменения ключевого фрейма. Дельта-фреймы, как правило, значительно меньше ключевых. В результате скорость передачи фреймов может изменяется в широких пределах. Однако для нормальной работы кодека (кодера-декодера) необходимо, чтобы каждый фрейм передавался в течение заданного времени. Необходимо согласовать определенный приоритет передачи данных в дельта-фреймах. К службам RSVP, поддерживающим передачу данных с гарантированной задержкой, относятся служба управления задержками (не являющаяся службой реального времени) и прогнозирующая служба (служба реального времени).
Обработка потоков данных по протоколу RSVP
В отличие от протоколов маршрутизации, протокол RSVP предназначен для управления потоками данных, а не для принятия решений относительно каждой дейтаграммы. Потоки данных состоят из дискретных сеансов связи между источником и получателями. Более точное определение сеанса — простой поток дейтаграмм к получателю и протокол транспортного уровня. Таким образом, сеансы идентифицируются следующими параметрами: адрес получателя, идентификатор протокола и порт получателя. поддерживает как одно-, так и многоадресатные симплексные сеансы.
Следует обратить внимание, что сеансы RSVP являются симплексными. Таким образом, двунаправленный обмен данными между двумя станциями в действительности состоит из двух отдельных симплексных сеансов RSVP.
При многоадресатной сеансе копия каждой дейтаграммы, переданной одним источником, отправляется нескольким получателям. Одноадресатный сеанс характеризуется одним источником и одним получателем. Иногда адреса источника и получателя RSVP указывают на один и тот же Internet-узел. Однако один узел может содержать несколько логических источников и получателей, различающихся номерами портов, так что каждый номер порта соответствует отдельному приложению. Если RSVP отслеживает такую информацию о приложении, то одноадресатный сеанс может привести к передаче данных нескольким приложениям, расположенным на одном узле-получателе.
Качество обслуживания RSVP
В контексте RSVP качество обслуживания (Quality of Service — QoS) является атрибутом, описанным в спецификациях потока, которые используются для определения маршрута обмена данными между объектами (маршрутизаторами, получателями и источниками). используется для определения QoS узлами и маршрутизаторами, узлы используют RSVP для запросов уровня QoS потоков данных приложений. Маршрутизаторы применяют RSVP для доставки запросов QoS другим маршрутизаторам по маршруту следования потока данных. Таким образом, RSVP поддерживает состояние маршрутизаторов и узлов для предоставления запрашиваемой службы.
Запуск сеанса RSVP
Для того чтобы запустить многоадресатный сеанс RSVP, получатель первым присоединяется к многоадресатной группе, определенной IP-адресом получателя при помощи протокола IGMP. При одноадресатном сеансе одноадресатная маршрутизация выполняет ту же роль, что и IGMP совместно с адресом протокола PIM (Protocol-Independent Multicast, независимый от протокола групповой адрес) для многоадресатного сеанса. После того как получатель присоединится к группе, потенциальный источник начинает посылать сообщения по маршруту RSVP на IP-адрес получателя. Приложение- получатель получает маршрутное сообщение и начинает посылать соответствующие запросы на резервирование, определяющие желательные признаки потока, используя протокол RSVP. После получения запроса на резервирование приложение-источник начинает отправлять пакеты данных.
Стиль резервирования RSVP
Стилем резервирования называют набор управляющих переменных, которые определяют количество поддерживаемых параметров. поддерживает два основных класса резервирования: раздельное и совместное. При раздельном резервировании каждому источнику в каждом сеансе выделяется свой поток. Совместное резервирование применяется для нескольких источников, которые заведомо не пересекаются друг с другом. На рис. 50.2 показаны схемы раздельного и совместного резервирования RSVP и их назначение. Все возможные варианты «стиль/назначение» описываются ниже.
Стиль групповой фильтрации
Стиль групповой фильтрации (Wildcard-Filter — WF) заключается в совместном или групповом резервировании. WF-резервирование представляет собой одиночное резервирование, при котором смешиваются все источники. Резервирование можно представить как «трубу» с совместным доступом, размер которой определяется наибольшим из ресурсов, запрошенных всеми получателями данного канала, независимо от количества источников. Резервирование распространяется на все узлы источников, в том числе автоматически — на новые источники по мере их появления.
Рис. 50.2. поддерживает как совместное, так и индивидуальное резервирование
Стиль фиксированной фильтрации
Стиль фиксированной фильтрации (Fixed-Filter — FF) определяет индивидуальное резервирование с явным указанием масштаба. При использовании FF-стиля создаются отдельные запросы на резервирование для пакетов данных, поступающих из разных источников. Масштаб резервирования определяется явно, по списку источников. Общее резервирование канала для данного сеанса представляет собой совокупность FF-резервирований для всех источников, указанных в запросе. Запросы на FF-резервирование от разных получателей, но для одного источника, должны быть объединены для совместного резервирования в данном узле.
Стиль явного совместного резервирования
Стиль явного совместного резервирования (Shared-Explicit — SE) определяет совместное резервирование среды с явным указанием масштаба. При использовании SE-сгиля создается одиночное резервирование, в котором смешиваются все источники. Как и при FF-резервировании, набор источников (и, следовательно, масштаб) явно определяются получателем, создающим данное резервирование.
Применение стилей резервирования RSVP
WF и SE являются вариантами совместного резервирования, подходящими для тех многоадресатных приложений, которые в силу своих особенностей не предполагают одновременной передачи данных из нескольких источников. В качестве примера можно привести аудиоконференции, где говорит одновременно только ограниченное количество людей. Каждый получатель может послать запрос на WF- или SE-резервирование для одного аудиоканала дважды (чтобы обеспечить некоторый избыток). FF-стиль создает независимое резервирование для потоков, поступающих из различных источников. FF-стиль больше подходит для видеосигналов. К сожалению, объединить совместное и одиночное резервирование невозможно.
Гибкое состояние RSVP
В любой RSVP-сети гибким состоянием (soft state) называется состояние, когда обновление маршрутизаторов и конечных узлов становится возможным благодаря специальным RSVP-сообщениям. Параметры гибкого состояния обеспечивают динамическое изменение членства в группах сети RSVP и настройку сети в соответствии с изменениями в маршрутизации. Обычно гибкое состояние поддерживается сетью RSVP для того, чтобы можно было изменять ее состояние без обращения к конечным точкам, в отличие от архитектуры с коммутацией каналов, где конечные точки посылают запрос и в случае сбоя повторяют его.
Механизмы протокола RSVP обеспечивают общие средства создания и обслуживания состояния распределенного резервирования многоадресатных и одноадресатных маршрутов доставки.
Для обслуживания состояния резервирования RSVP следит за гибким состоянием в узлах маршрутизаторов и узлов. Гибкое состояние RSVP создается и должно периодически обновляться запросами маршрута и резервирования. Если в течение заданного времени соответствующих сообщений обновления не поступит, то состояние удаляется. Гибкое состояние также может быть удалено в результате явного сообщения о разрыве. RSVP периодически проверяет гибкое состояние, чтобы формировать и передавать запросы об обновлении маршрутов и резервирования следующим узлам.
При изменении маршрута следующее маршрутное сообщение инициализирует состояние нового маршрута. Последующие запросы на резервирование устанавливают состояние резервирования. Состояние неиспользуемого сегмента сбрасывается по истечении установленного времени. (Спецификация RSVP требует, чтобы новое резервирование начиналось через 2 секунды после изменения топологии.)
При изменении состояния RSVP распространяет сообщения об этом по всей сети RSVP без задержки. Если полученное состояние отличается от предыдущего, то последнее обновляется. Если результат приводит к изменению генерируемых сообщений об обновлении, то такие сообщения генерируются и отправляются немедленно.
Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.
Qos rsvp что это за служба
Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP используется также маршрутизаторами для доставки QOS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг. RSVP-запросы обеспечивают резервирование определенных сетевых ресурсов, которые нужны, чтобы обеспечить конкретный уровень QOS вдоль всего маршрута транспортировки данных. Функция этого протокола крайне важна и многообразна, именно по этой причине это один из самых сложных протоколов.
RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных.
RSVP предназначен для работы с существующими и будущими маршрутными протоколами, управляющими как обычными, так и мультикастными потоками. В последнем случае ЭВМ сначала посылает IGMP-запрос, для того чтобы подключиться к мультикастинг-группе, а затем уже RSVP-сообщение для резервирования ресурсов по маршруту доставки.
Механизм обеспечения QOS включает в себя классификацию пакетов, административный контроль и диспетчеризацию. Классификатор пакетов определяет QoS класс (а иногда и маршрут движения) для каждого пакета. В процессе реализации резервирования RSVP-запрос проходит два местных управляющих модуля: «контроль доступа» и «управление политикой». Контроль доступа определяет, имеет ли узел достаточно ресурсов для удовлетворения поступившей заявки. Управление политикой определяет, имеет ли пользователь административное разрешение сделать данное резервирование. Если обе проверки завершились успешно, параметры передаются классификатору пакетов и интерфейсу канального уровня (диспетчеру пакетов). Если же какой-либо из тестов не прошел, программа RSVP присылает прикладному процессу сообщение об ошибке.
Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:
Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Схема работы процесса RSVP показана на рис. 4.4.9.6.1.
Рис. 4.4.9.6.1. RSVP в ЭВМ и маршрутизаторе
RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.
Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.
2. Модель резервирования
Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:
Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).
Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.
Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации. В каждом промежуточном узле запрос резервирования запускает две процедуры:
A. Резервирование канала
Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec.
Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS.
Б. Переадресация запроса назад
Запрос резервирования посылается от получателя отправителю (или отправителям) данных. Запрос резервирования, который переадресуется узлом дальше может отличаться от того, который он получил по двум причинам. Механизм управления трафиком модифицирует flowspec от узла к узлу. Что более важно, запросы резервирования, поступающие от получателей мультикастинг-дерева должны объединяться по мере продвижения процесса резервирования в направлении отправителя данных.
Когда получатель данных отправляет запрос резервирования, он может запросить также присылку сообщения, подтверждающего резервирование. Процесс резервирования распространяется от получателей к отправителям, от узла к узлу. В каждом узле требования резервирования объединяются и сопоставляются с имеющимися возможностями. Это продолжается до тех пор, пока запрос не достигнет отправителя или пока не возникнет конфликт перегрузки. В результате получатель данных, направивший запрос резервирования, получит сообщение об успехе или ошибке.
Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.
3. Стили резервирования
Стиль WF использует опции: «разделенного» резервирования и произвольного выбора отправителя («wildcard»). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая «труба», чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.
Символически можно представить запрос резервирования стиля WF как:
Стиль FF использует опции: «четкое» (distinct) резервирование и «явный» (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как:
Разделенное резервирование, выполненное с применением стилей WF и SE, пригодно для мультикастных приложений, где несколько источников данных редко осуществляют передачу одновременно. Пакетная передача голоса может служить примером разделенного резервирования, так как лишь ограниченное число людей говорят одновременно. Каждый получатель может направить запрос резервирования WF или SE на удвоенную полосу пропускания, необходимую одному отправителю, позволяя тем самым говорить обоим партнерам одновременно. С другой стороны стиль FF, который осуществляет четкое резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов.
Правила RSVP не позволяют объединять разделенные резервирования с четкими резервированиями, так как эти модели абсолютно несовместимы. Не допускается также объединение явного и произвольного (wildcard) выбора отправителей, так как это может вызвать предоставление незаказанных услуг получателю, который указал тип услуг явно. Таким образом, стили WF, SE и FF не совместимы.
Можно моделировать эффект WF резервирования, используя стиль SE. Когда приложение запрашивает WF, процесс RSVP получателя может использовать местный статус для выполнения эквивалентного резервирования SE, которое в явном виде перечисляет всех отправителей. Однако резервирование SE вынуждает классификатор пакетов в каждом узле в явном виде выбрать каждого отправителя из списка, в то время как WF позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью «wild card». Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE.
Рис. 4.4.9.6.2. Конфигурация маршрутизатора
Рис. 4.4.9.6.3, демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение.
Рис. 4.4.9.6.3. Пример резервирования WF (Wildcard-Filter)
На рис. 4.4.9.6.5 показан пример стиля резервирования SE. Когда резервирования стиля SE объединяются, результирующая спецификация фильтра является объединением исходных спецификаций, а результирующая спецификация flowspec равна наибольшей из flowspec.
Рис. 4.4.9.6.4. Пример резервирования FF (Fixed-Filter)
Рис. 4.4.9.6.5. Пример резервирования SE (Shared-Explicit)
5. Механизмы протокола RSVP
5.1. Сообщения RSVP
Рис. 4.4.9.6.6. Маршрутизатор, использующий RSVP
Каждая ЭВМ отправитель передает RSVP сообщения «Path» вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Это состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит помимо этого следующую информацию:
Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.
Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.
Сообщения Path должны содержать спецификацию отправителя Tspec, которая определяет характеристики информационного трафика, формируемого отправителем. Спецификация Tspec используется для предотвращения избыточного резервирования.
Сообщение Path может нести в себе пакет данных оповещения OPWA, известный, как «Adspec». Пакет Adspec, полученный с сообщением Path, передается системе управления трафиком, которая присылает скорректированную версию Adspec. Последняя пересылается далее в виде сообщения Path.
Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP.
6. Объединение Flowspecs
Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является «наибольшей» из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные.
Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec.
7. Гибкое состояние
RSVP использует подход «soft state» (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения «teardown» (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.
Сообщения Path и Resv практически эквивалентны (idempotent). Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние же на неиспользованном в данный момент сегменте маршрута будет аннулировано по таймауту. Следовательно, определение того, является ли сообщение «новым» или «обновляющим» принимается отдельно для каждого узла в зависимости от его текущего состояния.
Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP сообщений. Если таймаут удаления установлен равным K периодам обновления, тогда RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP, чтобы предотвратить их потерю из-за перегрузки канала.
Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, неиспользуемые состояния будут аннулированы по таймауту, если не поступит прямых указаний по их ликвидации до этого.
В стабильном состоянии осуществляется обновление статуса узел за узлом. Когда полученное состояние отличается от хранящегося, последнее обновляется. О модификации состояния соседи оповещаются с помощью сообщений обновления, которые рассылаются сразу после изменения состояния. Но эта волна изменений может остановиться в узле, где в результате слияния получается состояние, которое не отличается от прежнего. Это минимизирует трафик управления RSVP, что весьма существенно для больших мультикастинг-групп.
Состояние, которое получено через конкретный интерфейс I* никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I* должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на рис. 4.4.9.6.7, на котором показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы I A и I Б выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 4.4.9.6.7 «Получает» и «Отправляет» подразумевает внешнее направление по отношению к маршрутизатору).
Рис. 4.4.9.6.7. Независимые резервирования
Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io.
8. Аннулирование (Teardown)
Сообщения RSVP «аннулирование» удаляет проход или состояние резервирования. Хотя прямое уничтожение старого резервирования не является обязательным, оно настоятельно рекомендуется, так как ускоряет переходные процессы в сети.
Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.
Запрос аннулирование (teardown) может посылаться приложением оконечной системы (получатель или отправитель), или маршрутизатором в результате таймаута или при появлении привилегированной задачи. После инициализации запрос-аннулирование должен переадресовываться от узла к узлу без задержки. Сообщение аннулирование уничтожает специфицированное состояние в узле-получателе.
Подобно другим сообщениям RSVP, запросы-аннулирования доставляются без гарантии надежности. Потеря такого запроса не вызовет катастрофы, так как не используемое состояние будет рано или поздно ликвидировано по таймауту. Если маршрутизатор не получил сообщения аннулирования, он ликвидирует соответствующее состояние по таймауту и формирует сообщение аннулирование, рассылаемое последующим узлам. Предполагая, что вероятность потери сообщения RSVP мала, наибольшее среднее время ликвидации ненужного состояния не превышает периода обновления.
Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.
Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.
Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.
Однако для синтаксически верных запросов резервирования имеется много способов быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема «резервирования килера», в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.
Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, «состояние блокады», в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным.
Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако, эти резервирования были сохранены по следующим причинам:
Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос.
Этот механизм подтверждения имеет следующую последовательность:
11. Управление политикой
Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Такого рода обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя.
Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: «Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?» и «Позволено ли данному пользователю осуществлять резервирование?» Эти два решения называются «управлением доступа» и «управлением политикой», соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования.
На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.
Перенос таких данных, поставляемых пользователями, в сообщениях Resv может представлять проблему в случае существенного увеличения числа пользователей. Когда мультикастинг-группа содержит большое число получателей, может оказаться невозможно или нежелательно транспортировать данные, описывающие политику, вдоль всего маршрута. Эти данные должны объединяться как можно ближе к получателям, чтобы избежать чрезмерного информационного потока.
При использовании протокола RSVP возникают определенные проблемы безопасности.
Повреждение или фальсификация запросов резервирования может привести к получению услуг неавторизованными пользователями или к отказам в услугах. RSVP осуществляет защиту против таких атак с помощью механизма аутентификации, действующего в каждом из узлов и использующего шифрование с применением хэш-функций. Механизм поддерживается объектами INTEGRITY, которые могут быть включены в любое сообщение RSVP. Эти объекты используют технику криптографических дайджестов, которая предполагает, что соседи RSVP совместно владеют секретом шифрования (см. [Baker96]).
Управление политикой будет зависеть от положительного результата аутентификации для каждого из запросов резервирования. Информация, характеризующая политику, может быть включена в сообщение в виде криптографически защищенного сертификата пользователя.
Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя.
Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207].
13. Области, не поддерживающие RSVP
Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP вероятно никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако, если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг реального времени.
Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие RSVP так и не поддерживающие RSVP маршрутизаторы переадресуют сообщения Path в соответствие с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего RSVP-маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему RSVP-маршрутизатору на пути к отправителю.
Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP’ и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210].
При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.
Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.
Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress.
Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress.
Приложение получателя принимает сообщение Path.
Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков.
Приложение отправителя получает сообщение Resv.
Отправитель начинает посылать информационные пакеты.
Существует несколько соображений, касающихся синхронизации.
Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.
15. Функциональная спецификация RSVP
15.1. Формат сообщений RSVP
Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.
16. Общий заголовок
Рис. 4.4.9.6.8. Формат общего заголовка
В общем заголовке имеются следующие поля:
Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.
Значение TTL для протокола IP, с которым было послано сообщение.
Длина RSVP : 16 бит
Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.
17. Форматы объектов
Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 4.4.9.6.9:
Рис. 4.4.9.6.9. Формат объекта
Заголовок объекта имеет следующие поля:
16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4.
Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы:
Объект NULL имеет код Class-Num равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется.
Содержит IP-адрес места назначения (DestAddress), идентификатор протокола IP, и обобщенный номер порта назначения, для того чтобы специфицировать сессию для других объектов, которые следуют далее. Этот класс должен присутствовать в любом сообщении RSVP.
Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). Этот класс характеризует предшествующий узел (previous hop).
Содержит значение периода обновления R, используемого отправителем сообщения. Необходим в каждом сообщении Path и Resv.
Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Необходим в каждом сообщении Resv.
Определяет желательный уровень QoS, в сообщениях Resv.
Определяет субнабор информационных пакетов сессии, которые должны получить желательный уровень QoS (специфицированный объектом FLOWSPEC), в сообщениях Resv.
Содержит IP-адрес отправителя и, может быть, некоторые дополнительную информацию, идентифицирующую отправителя. Необходим в сообщениях Path.
Определяет характеристики информационного трафика отправителя. Необходим в сообщениях Path.
Несет в себе данные OPWA, в сообщении Path.
Специфицирует ошибку в сообщениях PathErr, ResvErr, или подтверждение в сообщении ResvConf.
Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr.
Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного документа.
Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear.
Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf.
Тип объекта, уникален в пределах класса Class-Num.
Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно, как 16-битовое число, для определения уникального типа для каждого из объектов.
Старшие два бита Class-Num используются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.
Каждая ЭВМ-отправитель периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA).
Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP. Формат сообщения Path имеет следующий вид:
Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным.
Объект PHOP (т.е., RSVP_HOP) каждого сообщения Path содержит адрес предшествующего узла, напр., IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH).
Каждый узел, поддерживающий RSVP, вдоль пути перехватывает сообщение Path и обрабатывает его, с тем чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path.
Периодически процесс RSVP в узле сканирует состояние прохода, чтобы сформировать новые сообщения Path для посылки их получателям. Каждое сообщение содержит дескриптор, характеризующий одного отправителя, несет в себе IP-адреса отправителя и его источника.
Процесс RSVP переадресует и размножает (если требуется, например при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP адрес, сообщения Path, посланные разными интерфейсами содержат отличные адреса PHOP. Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов.
Состояние пути для данной сессии и отправителя не обязательно должны иметь уникальные PHOP или уникальный входной интерфейс. Существует два случая, соответствующие мультикастной и уникастной сессиям.
Мультикастинговая маршрутизация позволяет иметь стабильное дерево распределения, в котором сообщения Path от одного и того же отправителя приходят от более чем одного PHOP, и RSVP должен быть готов поддерживать все такие состояния пути. RSVP не должен пересылать сообщения Path, которые прибывают через входной интерфейс, отличный от указанного в маршрутной таблице.
В течение короткого периода времени, следующего после изменения уникастного маршрута, узел может получать сообщения Path от нескольких PHOP для данной сессии и отправителя. Узел не может надежно определить, какой из PHOP является правильным, хотя узел будет получать одновременно только один из PHOP. Одним из вариантов реализации RSVP является игнорирование PHOP и допущение для PHOP переключаться между имеющимися кандидатами. Другим вариантом является поддержание состояния пути для каждого PHOP и посылка сообщения Resv всем таким PHOP. В любом варианте ситуация является переходной, неиспользуемые состояния пути все равно будут удалены (явно или по таймауту).
Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат:
Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны следовать требованиям записанных в BNF.
Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.
Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.
Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.
Каждый запрос стиля FF описывается одной парой (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.
Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом:
Резервирование переадресуется всем отправителям, чьи объекты SENDER_TEMPLATE, записанные в состоянии прохода соответствуют объекту FILTER_SPEC.
Запрос с произвольным выбором отправителя соответствует всем отправителям, которые маршрутизированы на данный выходной интерфейс.
Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте.
Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, больше чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле.
20. Сообщения отмены прохода
Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки.
Сообщения PathTear инициализируются непосредственно отправителем или в результате таймаута состояния прохода в каком-либо узле и направляются всем отправителям. Уникастное PathTear не должно переадресовываться, если состояние прохода соответствует той же сессии и отправителю, но имеет другой PHOP.
Сообщение PathTear должно маршрутизоваться в точности также как соответствующие сообщения Path. Следовательно, его IP-адрес места назначения должен совпадать с DestAddress, а его IP-адрес источника должен быть адресом отправителя из состояния прохода.
Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться.
Удаление состояния прохода в результате получения сообщения PathTear или таймаута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Если стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрования, соответствующей отправителю S, должно быть удалено; если стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений.
21. Сообщения отмены Resv
Получение сообщения ResvTear (reservation teardown) удаляет соответствующие состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.
Сообщения ResvTear отправляются получателями или любым узлом, в котором состояние резервирование аннулируется в результате таймаута, далее они движутся в направлении получателей.
Сообщение ResvTear должно маршрутизироваться аналогично соответствующим сообщениям Resv, а его IP-адрес места назначения является уникастным адресом предыдущего узла.
Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.
В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 4.4.9.6.4.
22. Сообщения об ошибке прохода
Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя.
Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA.
23. Сообщения об ошибках Resv
Сообщения ResvErr (reservation error) сообщают об ошибках при обработке сообщений Resv, или о спонтанном нарушении резервирования, напр., в результате административного вмешательства.
Сообщения ResvErr направляются соответствующим получателям, они маршрутизируются от узла к узлу с использованием состояния резервирования. В каждом из узлов в качестве IP-адреса места назначения используется уникастный адрес следующего узла.
Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv.
Следующие правила, зависящие от стиля, определяют структуру ошибки дескриптора потока.
Каждый дескриптор потока в сообщении Resv стиля FF должен обрабатываться независимо и для каждого из них, имеющего ошибку, должно посылаться отдельное сообщение ResvErr.
Сообщение ResvErr стиля SE может представит список субнабора спецификаций фильтрации, которые вызвали ошибки, в соответствующем сообщении Resv.
Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF) может быть причиной N сообщений ResvErr.
Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки. Конкретнее:
Это сообщение ResvErr должно содержать информацию, необходимую для определения ошибки и для маршрутизации сообщения об ошибке последующим узлам. Такое сообщение, следовательно, включает в себя объект ERROR_SPEC, копию объекта STYLE и соответствующий дескриптор потока, где зафиксирована ошибка. Если ошибка является результатом отказа при попытке увеличить резервирование, тогда существующее резервирование должно быть сохранено и должен быть установлен бит-флаг InPlace в ERROR_SPEC сообщения ResvErr.
24. Сообщения подтверждения
Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM.
Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address). Равенство кода ошибки и значения (Value) нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение.
25. Использование портов
Сессия RSVP определяется в норме тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения.
RSVP допускает любое значение для ProtocolId. Однако, реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и в частности значения для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:
Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP.
1. Порты назначения должны быть взаимосогласованными.
Состояния прохода и резервирования для одного и того же DestAddress и ProtocolId должны иметь свои значения DstPort, которые все равны нулю или все не равны нулю. Нарушение этого условия в узле является ошибкой «конфликт портов назначения (Conflicting Dest Ports)».
2. Правило портов назначения.
Если DstPort в описании сессии равен нулю, все поля SrcPort, используемые для этой сессии, также должны быть равны нулю. При этом предполагается, что протокол не имеет портов типа UDP/TCP. Нарушение этого условия в узле вызовет ошибку «Bad Src Ports».
3. Порты источников должны быть взаимосогласованы.
ЭВМ-отправитель не должна посылать состояния прохода со значением SrcPort равным так и неравным нулю. Нарушение этого условия вызовет ошибку «Conflicting Sender Port». Заметим, что протокол не допускает произвольного назначения номеров портов (wildcard), т.е., нулевой порт не может соответствовать ненулевому порту.
26. Посылка сообщений RSVP
Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.
Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.
По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой.
Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий:
RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание. Если RSVP-пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов.
Некоторые мультикастные протоколы маршрутизации обеспечивают туннели, которые организуют IP-инкапсуляцию мультикастных пакетов и их транспортировку через маршрутизаторы, которые не поддерживают мультикастную маршрутизацию. RSVP может работать через такие мультикастные туннели следующим образом:
27. Исключение циклов сообщений RSVP
Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель «автоматического обновления». Такие петли автоматического обновления сохраняют состояние «вечно», даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов.
Рассмотрим каждый тип сообщения.
Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако, когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.
Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:
На рис. 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.