Network Working Group J. Wroclawski
Request for Comments: 2210 MIT LCS
Category: Standards Track September 1997
Использование протокола RSVP с интегрированными службами
The Use of RSVP with IETF Integrated Services
Статус документа
Этот документ содержит проект стандартного протокола для сообщества Internet и служит запросом для обсуждения в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.
Аннотация
В этом документе описано использование протокола резервирования ресурсов RSVP со службами управления качеством обслуживания Controlled-Load и Guaranteed QoS. Протокол RSVP определяет несколько объектов данных, которые могут передавать информацию о резервировании ресурсов, но не обрабатываются (непрозрачны) самим протоколом RSVP. Применение таких объектов и форматы их данных описаны здесь.
1. Введение
Модель интегрированных услуг Internet обеспечивает приложениям возможность выбора из множества контролируемых уровней сервиса доставки своих пакетов данных. Для реализации такой возможности требуется:
-
обеспечить поддержку механизмов контроля качества обслуживания для этих пакетов на всех сетевых элементах (подсетях и маршрутизаторах IP) по пути следования пакетов;
-
обеспечить пути передачи потребностей приложений сетевым элементам вдоль пути, а также передачи информации управления QoS между сетевыми элементами и приложениями.
В модели интегрированных услуг первая функция реализуется службами управления QoS типа Controlled-Load [RFC 2211] и Guaranteed [RFC 2212]. Вторая функция может быть реализована множеством способов, но часто для нее используют протокол организации резервирования ресурсов типа RSVP [RFC 2205].
Поскольку протокол RSVP предназначен для использования с разными службами управления QoS, а эти службы, в свою очередь, рассчитаны на работу с разными механизмами, имеется логическое разделение между двумя спецификациями. Спецификация RSVP не определяет внутренних форматов тех полей и объектов RSVP, которые связаны с вызовом служб управления QoS. Протокол RSVP рассматривает такие объекты, как непрозрачные. Объекты могут передавать разную информацию в соответствии с требованиями различных приложений и механизмов QoS.
Аналогично интерфейсы к службам управления QoS определяются в обобщенном формате, чтобы эти службы могли применяться с различными механизмами.
В данном RFC представлена информация, требуемая для совместного использования RSVP и службами управления QoS модели интегрированных услуг. Документ определяет использование и содержимое трех объектов протокола RSVP – FLOWSPEC, ADSPEC и SENDER_TSPEC в средах, поддерживающих службы управления QoS Controlled-Load и/или Guaranteed. При добавлении новых служб или возможностей в модель интегрированных услуг этот документ будет пересматриваться.
2. Использование RSVP
Для корректного вызова служб управления QoS требуется обеспечить транспортировку нескольких типов данных между приложениями и элементами сети.
Примечание. В дополнение к данным, используемым для прямых вызовов служб управления QoS, протокол RSVP переносит данные аутентификации, учета и политики, требуемые для управления использованием сервиса. Приведенная ниже информация относится только к объектам RSVP, требуемым для реального вызова функций управления QoS, и не относится к объектам учета и политики.
Эти данные включают:
-
Информацию, генерируемую каждым получателем и описывающую желаемый сервис управления QoS, описание потока трафика, к которому следует применить резервирование ресурсов (TSpec получателя), а также указание параметров, требуемых для вызова сервиса (RSpec получателя). Информация передается от получателей к промежуточным сетевым элементам и отправителям в объектах RSVP FLOWSPEC. Информация, передаваемая в объектах FLOWSPEC, может меняться промежуточными узлами сети в результате слияния резервов и иных факторов.
-
Информацию, генерируемую каждым отправителем, которая описывает генерируемый им трафик (TSpec отправителя). Эта информация передается от отправителей промежуточным элементам сети и получателям протоколом RSVP, не подвергаясь каким-либо изменениям на промежуточных элементах сети. Информация переносится в объектах RSVP SENDER_TSPEC.
-
Генерируемую и изменяемую в сети информацию, которая используется получателями для принятия решений о резервировании. Такая информация может включать списки доступных служб, оценку полосы и задержек, а также операционные параметры конкретных служб управления QoS. Информация собирается на элементах сети и передается в направлении получателей в объектах RSVP ADSPEC. Вместо раздельного переноса получателям информации от каждого промежуточного узла, данные в ADSPEC представляют собой «суммарное» значение ADSPEC от всех интервалов. Размер этого значения остается (приблизительно) постоянным по мере прохождения ADSPEC, что обеспечивает достаточный уровень масштабируемости.
С точки зрения объектов различия состоят в следующем:
-
Объект RSVP SENDER_TSPEC содержит спецификацию трафика (TSpec отправителя), генерируемого каждым источником данных в сессии RSVP. Объект передается через сеть без изменений и доставляется промежуточным узлам и принимающим приложениям.
-
Объект RSVP ADSPEC переносит информацию, которая генерируется источниками данных и промежуточными элементами сети, передается в нисходящем направлении в сторону получателей. Объект может использоваться и обновляться промежуточными узлами до доставки объекта принимающему приложению. Данные объекта включают параметры описывающие свойства пути, включая доступность конкретных услуг управления QoS, а также параметры, требуемые указанными службами управления QoS для корректной работы.
-
Объект RSVP FLOWSPEC переносит запросы резервирования (TSpec и RSpec получателя), генерируемые получателями данных. Информация FLOWSPEC перемещается в восходящем направлении к источникам данных. Объект может использоваться и обновляться промежуточными узлами до его доставки передающему данные приложению.
Примечание. Существование объектов SENDER_TSPEC и ADSPEC RSVP обусловлено историческими причинами. Использование описанного здесь формата позволяет заменить всю эту информацию данными, которые RSVP передает в нисходящем направлении с помощью одного объекта. Однако различие между данными, которые могут (ADSPEC) и не могут (SENDER_TSPEC) обновляться в сети, может оказаться полезным на практике и по этой причине было сохранено.
2.1 Сущность операций
Экземпляр приложения, участвующий в сессии RSVP в качестве отправителя данных, регистрируется в RSVP. Одним из элементов информации, предоставленной экземпляром приложения, является спецификация Sender Tspec, описывающая трафик, который предполагает генерировать приложение. Эта информация служит для создания объекта RSVP SENDER_TSPEC, который включается в сообщения RSVP PATH, генерируемые для приложения.
Передающее приложение также создает первичный объект RSVP ADSPEC. Этот объект содержит сведения о возможностях и требованиях управления QoS со стороны самого передающего приложения, а также формирует стартовую точку сбора данных о свойствах пути, описанных ниже. Объект ADSPEC добавляется в сообщение RSVP PATH, созданное отправителем.
Примечание. Для удобства создания программных приложений реализация хоста RSVP может позволять передающему предложению отказаться от создания первичного объекта ADSPEC, используя вместо него принятый по умолчанию. Это обычно происходит в тех случаях, когда приложение-отправитель само по себе не участвует в процессе сквозного управления QoS (путем активного планирования загрузки CPU и т. п.) и само не принимает во внимание выбранные получателями параметры управления QoS.
Обычно принятый по умолчанию объект ADSPEC, представляемый хостом RSVP, в таких случаях поддерживает все службы управления QoS, известные хосту. Однако точное поведение этого механизма зависит от реализации.
Объект ADSPEC изменяется элементами сети по мере продвижения сообщения RSVP PATH от отправителя к получателю(ям). На каждом элементе сети ADSPEC передается от RSVP модулю управления трафиком, который обновляет объект ADSPEC, где могут содержаться данные для нескольких служб управления QoS, идентифицируя каждую из указанных в ADSPEC служб и вызывая ее для обновления соответствующей части ADSPEC. Если модуль управления трафиком обнаруживает службу управления QoS, означенную в ADSPEC, но не реализованную на данном элементе сети, устанавливается флаг информирования получателя об этом. Обновленный объект ADSPEC возвращается протоколу RSVP для доставки на следующий интервал пути.
При получении сообщения PATH приложением на приемной стороне данные в объектах SENDER_TSPEC и ADSPEC передаются приложению через RSVP API. Приложение (возможно, с помощью библиотеки общих функций резервирования ресурсов) интерпретирует полученные данные и использует их в качестве рекомендаций при выборе параметров резервирования ресурсов. Примеры этого включают использование полученного в PATH_MTU параметра [RFC 2215] для определения максимального размера пакетов в параметрах запроса резервирования, а также использование параметров C и D сервиса Guaranteed [RFC 2212] для расчета границы задержки пакета при использовании сервиса Guaranteed.
Желающее организовать резервирование приложение-получатель предоставляет локальному модулю RSVP требуемые параметры резервирования. Эти параметры включают желаемый уровень управления QoS (Guaranteed или Controlled-Load), спецификацию трафика (Tspec), описывающую уровень трафика, для которого следует резервировать ресурсы, а также (при необходимости для выбранного сервис управления QoS) спецификацию Rspec, описывающую желаемый уровень обслуживания. Эти параметры объединяются в объект RSVP FLOWSPEC и передаются в восходящем направлении протоколом RSVP.
В каждой поддерживающей RSVP точке сети получение SENDER_TSPEC в сообщении PATH и FLOWSPEC в сообщении RESV используется для запроса соответствующего резервирования ресурсов от желаемой службы управления QoS. Слияние состояний, пересылка сообщений и обработка ошибок выполняются в соответствии с правилами протокола RSVP.
В заключении собранный (слитый) объект FLOWSPEC, прибывающий каждому отправителю данных в сессии RSVP, доставляется приложению в целях информирования того о итоговом запросе на резервирование и свойствах пути передачи данных.
2.2. Поддержка в RSVP множества служб управления QoS
Описанное здесь решение поддерживает сессии RSVP, в которых получатели выбирают службу управление QoS в процессе работы.
Для решения этой задачи получателю требуется вся информация, которая нужна для выбора конкретного сервиса до того, как получатель сделает свой выбор. Это означает, что объекты RSVP SENDER_TSPEC и ADSPEC должны обеспечить получателей информацией о всех службах, которые можно выбрать.
Значения TSpec отправителя, используемые двумя определенными службами управления QoS, идентичны. Это упрощает объекты RSVP SENDER_TSPEC, от которых требуется передача единственной структуры TSpec в этом совместно используемом формате. Это общее значение SENDER_TSPEC может применяться со службами Guaranteed и Controlled-Load.
RSVP ADSPEC содержит информацию, требуемую получателям для выбора службы и определения параметров резервирования, включая:
-
Сведения о наличии на пути не поддерживающих RSVP интервалов. При их наличии трафик приложения будет получать класс обслуживания «как получится» (best-effort) в по крайней мере на одном участке пути.
-
Сведения о реализации указанного сервиса QoS на каждом этапе пути. Например, получатель может узнать, что по крайней мере один из интервалов с интеграцией услуг на пути поддерживает сервис Controlled-Load, но не поддерживает Guaranteed.
-
Принятые по умолчанию или глобальные значения для параметров общего назначения, описанных в [RFC 2215]. Эти значения описывают свойства самого пути, безотносительно к выбранному сервису QoS. Значение, указанной в данной сессии с помощью ADSPEC, применимо ко всем службам, если в ADSPEC не указано иное, конкретное значение для сервиса.
-
Связанное с сервисом значение для одного или множества общих параметров при отличии этого значения от принятого по умолчанию.
-
Значения специфических для сервиса параметров, определенные каждой поддерживаемой службой.
Данные в ADSPEC поделены на блоки или фрагменты, каждый из которых связан с конкретным сервисом. Это позволяет в одном объекте передавать сведения о множестве служб, что дает возможность развернуть в будущем новые типы сервиса без необходимости обновления существующего кода, а также позволяет приложениям, не использующим тот или иной сервис, пропускать соответствующий блок ADSPEC. Структура ADSPEC подробно описана в параграфе 3.3.
Отправитель может указать, что тот или иной сервис управления QoS не следует использовать получателям в данной сессии RSVP. Это осуществляется за счет исключения упоминаний об этом сервисе из ADSPEC, как описано в параграфе 3.3. По прибытии к получателю полное отсутствие фрагмента ADSPEC для конкретного сервиса указывает, что им не следует пользоваться.
Примечание: В RSVP версии 1 все получатели в сессии должны выбирать одну службу управления QoS. Это ограничение обусловлено сложностью слияния запросов на резервирование разных служб управления QoS и отсутствием механизма замены сервиса. В будущих версиях это ограничение может быть снято.
С учетом этого ограничения может оказаться полезной координация выбранного получателем сервиса QoS с предлагающими только один вариант получателями за счет использования упомянутого выше механизма ADSPEC. В этом случае все получатель должны будут выбрать один сервис. В дополнение к этому координация может достигнута за счет анонсирования сессии на вышележащем уровне и организации механизма информирования получателей об используемом сервисе управления QoS путем минимальной настройки конфигурации получателей или за счет протокола согласования между получателями в рамках одной сессии.
Как и ADSPEC, объекты FLOWSPEC и SENDER_TSPEC, формат которых описан в разделе 3, могут передавать значения TSpec и RSpec для множества служб управления QoS в раздельных фрагментах данных. В настоящее время использование FLOWSPEC и SENDER_TSPEC, содержащих фрагменты для более, чем одной службы QoS, не поддерживается. В будущем это свойство может применяться для реализации более гибких запросов обслуживания и схем замены, позволяющих приложениям найти полезный сквозной сервис QoS, когда не все промежуточные узлы поддерживают общий набор служб QoS. Интерфейсы API в приложениях RSVP следует разрабатывать с учетом поддержки передачи объектов SENDER_TSPEC, FLOWSPEC и ADSPEC переменного размера, содержащих информацию о множестве служб управления QoS между RSVP и его клиентами.
2.3. Использование информации ADSPEC
В этом разделе рассматриваются некоторые детали параметров резервирования ресурсов и использование информации из объектов RSVP ADSPEC.
2.3.1. Определение доступности службы управления QoS
Объекты RSVP ADSPEC передают флаги, говорящие приложениям получателям о возможностях поддержки резервирования на всем пути между отправителем и получателем. Эти биты называют break bit (бит прерывания), поскольку они указывают точки прерывания поддержки управления QoS на пути через сеть. Биты прерывания передаются в заголовке, которым начинается каждый связанный с сервисом фрагмент данных RSVP ADSPEC.
Служба номер 1 (Service number 1) используется в ADSPEC для идентификации фрагмента, содержащего информацию о значениях глобальных параметров, которые применимы ко всем службам (см. [RFC 2215]). Бит прерывания в заголовке службы 1 говорит получателям о наличии поддержки на всем пути между отправителем и получателем RSVP и интегрированных услуг. Если получатель видит установленный бит (1), это означает, что по крайней мере один из элементов сети на пути передачи данных между отправителем ADSPEC и получателем совсем не поддерживает управление QoS. Этот бит соответствует глобальному параметру NON_IS_HOP, определенному в [RFC 2215].
Примечание. Если этот бит установлен, значениям всех остальных параметров в ADSPEC не следует доверять. Установка бита говорит, что по крайней мере один из узлов на пути между отправителем и получателем не может полностью обработать ADSPEC.
Биты прерывания для конкретных служб говорят получателям о возможности поддержки на всех узлах сети по пути от отправителя к получателю конкретного сервиса управления QoS. Бит прерывания для каждого сервиса передается в связанном со службами заголовке ADSPEC для данного сервиса. Установленный бит говорит получателю, что по крайней мере один элемент на пути через сеть поддерживает RSVP, но не поддерживает службу управления QoS, соответствующую заголовку. Эти биты соответствуют специфическим для служб параметрам NON_IS_HOP, определенным в [RFC 2215].
Более подробное описание битов прерывания дано в разделе 3.
2.3.2. Определение Path MTU
Обе службы управления QoS (Guaranteed и Controlled-Load) задают верхнюю границу размера пакетов и требуют от приложений ограничивать размер пакетов, для которых организуется резервирование ресурсов. Для обеих служб желаемый максимальный размер пакетов является параметром запроса на резервирование и служба будет отвергать (с возвратом ошибки контроля доступа) запросы на резервирование, задающие размер пакетов, который превышает поддерживаемый службой.
Поскольку запросы на резервирование RSVP выдаются получателями, это означает, что получателям в сессии RSVP (а также отправителям) нужно знать величину MTU, поддерживаемого службами управления QoS на пути передачи данных. Кроме того, в некоторых не совсем обычных случаях значение MTU, поддерживаемое службой управления QoS, может отличаться от значения, поддерживаемого тем же маршрутизатором для остального трафика (best effort).
Для решения этой проблемы используется масштабируемая форма согласования MTU. В системе RSVP согласование MTU осуществляется следующим способом:
-
Каждое приложение-отправитель, присоединяющееся к сессии RSVP указывает в параметре M (максимальный размер пакета) генерируемого им Sender_TSpec (передается от отправителей к получателям в объекте SENDER_TSPEC) максимальный размер пакетов, которые он планирует передавать через резерв.
-
Каждое сообщение RSVP PATH от передающего приложения также содержит объект ADSPEC, в котором имеется по крайней мере один параметр PATH_MTU. Когда объект поступает к получателю, этот параметр определяет минимальное значение MTU на всем пути от отправителя к получателю. Как правило присутствует лишь один «глобальный» параметр PATH_MTU (служба 1, параметр 9) и его значение будет определять MTU для всех запросов на резервирование. При наличии специфического для службы значения PATH_MTU оно будет меньше глобального параметра и его следует использовать в запросах для данной службы.
-
Каждый получатель берет минимальное из значений PATH_MTU (для желаемой службы QoS), полученных в сообщениях ADSPEC от разных отправителей и использует это значение в качестве MTU для своих запросов на резервирование. Это значение используется для параметра M в создаваемых получателем Tspec. При использовании стиля резервирования FF может также выбрать использование MTU из ADSPEC от каждого отправителя в спецификации FLOWSPEC для этого отправителя, если получатель желает воспользоваться максимальным MTU для каждого из путей. Для учета изменений в пути получатель может продолжать отслеживание приходящих ADSPEC и менять резервирование, если ADSPEC показывает снижение MTU.
-
По мере перемещения запросов на резервирование (сообщения RESV) от получателей к отправителям параметры резервирования объединяются на промежуточных узлах. В процессе такого слияния выбирается меньшее из значений M, полученных в точке слияния, для пересылки сообщения RESV в восходящем направлении.
-
По прибытии запросов на резервирование на промежуточные узлы RSVP берется минимальное значение из запрошенных получателями TSpec и сумма TSpec отправителя, а затем выполняется резервирование для результирующей спецификации TSpec. Это резервирование будет использовать минимальное из значений MTU для пути, определенных получателями, и максимальный размер пакетов, декларированный отправителями (функция sum() для TSpec обеспечивает для параметра M максимальное значение среди M суммируемых TSpec).
-
Когда после полного слияния сообщение RESV приходит каждому отправителю, значение MTU (парамерр M) в результирующем объекте FLOWSPEC будет указывать минимальное приемлемое значение MTU на путях между отправителем и всеми получателями в данной сессии. Все пакеты с размером больше этого MTU будут доставляться «по возможности» (best-effort) и резервирование для них может не работать.
Отметим, что отправитель не подстраивает значение поля M в своих Sender_TSpec с целью соответствия реальному размеру пакетов, выбранному на этом этапе. Значение M представляет максимальный размер пакетов, которые может передавать отправитель, а выбранное в настоящее время максимальное значение.
Отметим, что описанная схема позволяет каждому отправителю в сессии использовать наибольшее значение MTU, приемлемое для него, в тех случаях, когда на разных путях или у разных отправителей приемлемы разные MTU.
3. Формат объектов RSVP
В этом разделе подробно описано содержимое и формат объектов RSVP SENDER_TSPEC, ADSPEC и FLOWSPEC для использования со службами управления QoS типа Guaranteed и Controlled-Load. Описанный здесь формат пакетов основан на общих правилах создания сообщений, описанных в Приложении 1.
3.1. Объект RSVP SENDER_TSPEC
Объект RSVP SENDER_TSPEC передает информацию о трафике, генерируемом отправителем. Обязательный объект RSVP SENDER_TSPEC содержит глобальный параметр Token_Bucket_TSpec (service_number 1, parameter 127, в соответствии с [RFC 2215]). Информация TSpec применима для управления QoS Guaranteed и Controlled-Load QoS.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | резерв | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |0| резерв | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] 32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Номер версии формата сообщений (0)
(b) Общий размер (7 слов без учета заголовка)
(c) Сервисный заголовок, служба 1 (глобальная информация, используемая по умолчанию)
(d) Размер данных службы 1 (6 слов без учета заголовка)
(e) Идентификатор для параметра 127 (Token_Bucket_TSpec)
(f) Флаги параметра 127 (нет)
(g) Размер параметра 127 (5 слов без учета заголовка)
В этой спецификации TSpec параметры [r] и [b] устанавливаются в соответствии с представлением отправителя о генерируемом им трафике. Пиковая скорость [p] может быть установлена в соответствии с максимальной скоростью генерации трафика (если она известна и контролируется), скоростью физического интерфейса (если она известна) или указана положительно бесконечной (если лучшего значения не найдено). Положительное бесконечное значение в формате IEEE одинарной точности с плавающей запятой задается показателем степени из одних единиц (255) с нулевыми значениями в полях знака и мантиссы. Описание формате IEEE FP дано в [RFC 1832].
Параметр Minimum Policed Unit [m] обычно следует задавать равным размеру минимального пакета, генерируемого приложением. Этот размер включает данные приложения и протокольные заголовки до уровня IP, включительно (IP, TCP, UDP, RTP и т. п.). Заголовки канального уровня не учитываются, поскольку размер этих заголовков будет меняться при прохождении пакетов через сеть.
Параметр [m] используется узлами сети для расчета максимальных издержек полосы пропускания при передаче пакетов с использованием конкретной технологии канального уровня через отношение [m] к размеру заголовка канального уровня. Это позволяет корректировать полосу пропускания, выделяемую для потока в каждой точке сети. Отметим, что уменьшение значения этого параметра ведет к переоценке при учете заголовков канального уровня и может приводить к тому, что резервирование будет отвернуто на некоторых узлах. В некоторых случаях приложение, передающее совсем немного пакетов малого размера, может установить значение [m], превышающее реальный размер коротких пакетов. Это повышает вероятность успешного резервирования, поскольку для пакетов размера меньше [m] будут применяться правила, как для [m].
Отметим, что нулевое значение [m] является некорректным. Такое значение говорит об отсутствии данных и заголовков IP, что дает при расчете издержек канального уровня бесконечное значение.
Параметр Maximum Packet Size [M] следует задавать равным размеру самого большого пакета, который может быть создан приложением (см. параграф 2.3.2). Это значение (по определению) не может быть меньше [m].
3.2. Объект RSVP FLOWSPEC
Объект RSVP FLOWSPEC переносит информацию, требуемую для организации резервирования от получателей в сеть. Такая информация включает запращиваемый сервис управления QoS и требуемые параметры этого сервиса.
Запрашиваемый сервис QoS указывается значением service_number в сервисном заголовке FLOWSPEC.
3.2.1 Объект FLOWSPEC при запросе сервиса Controlled-Load
Формат объекта RSVP FLOWSPEC, исходящего от получателя, который запрашивает сервис Controlled-Load, показан ниже. Каждое поле TSpec указывается с использованием конкретного представления, описанного в параграфе Invocation Information [RFC 2211]. Значение 5 в сервисном заголовке (поле (c) на рисунке ниже) указывает запрос сервиса Controlled-Load.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | резерв | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 5 (c) |0| резерв | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Номер версии формата сообщений (0)
(b) Общий размер (7 слов без учета заголовка)
(c) Сервисный заголовок, служба 5 (Controlled-Load)
(d) Размер данных controlled-load, 6 без учета заголовка сервиса
(e) Идентификатор для параметра 127 (Token_Bucket_TSpec)
(f) Флаги параметра 127 (нет)
(g) Размер параметра 127 (5 слов без учета сервисного заголовка)
В этом объекте параметры TSpec [r], [b] и [p] устанавливаются в соответствии с характеристиками трафика желаемого получателями резервирования (Reservation TSpec). Значение этих полей подробно рассмотрено в [RFC 2211]. Отметим, что вряд ли имеет смысл делать значение [p] меньше, чем [r].
Параметр Maximum Packet Size [M] следует задавать равным наименьшему MTU, определенному получателем из данных в объектах RSVP ADSPEC. В дополнение к этому, если принимающее приложение имеет встроенную информацию о максимальном размере пакетов, используемом в сессии RSVP, и это значение меньше, чем меньшее MTU для пути, данное значение можно установить в качестве [M]. Отметим, что запрос значения [M], превышающего поддерживаемый сервисными модулями на пути, может вызывать отказ при резервировании. Дополнительное рассмотрение значения MTU приведено в параграфе 2.3.2.
Значение [m] может быть выбрано несколькими способами. Отметим, что при организации резервирования на каждом промежуточном узле используемое для [m] значение будет меньшим значением из запросов получателей и SENDER_TSPEC каждого отправителя.
Если приложение имеет фиксированный, известный минимальный размер пакетов, это значение следует применять в качестве [m]. Такая ситуация является наиболее подходящей.
Для разделяемого резервирования получатель может выбрать один из двух описанных ниже вариантов или что-то среднее между ними:
-
при выборе получателем большого значения [m] снижаются издержки резервирования, связанные с заголовками канального уровня; однако, если потом к сессии присоединится отправитель с меньшим SENDER_TSPEC [m], организованное ранее резервирование может дать отказ;
-
при выборе для [m] наименьшего из значений, которые могут использовать отправители возрастают издержки, связанные с резервированием на заголовки канального уровня; однако вероятность отказа по причине присоединения к сессии отправителя с малым значением SENDER_TSPEC [m] снижается.
Для резервирования в стиле FF если не известно специфичное для приложения значение, получателю просто следует применять [m] из каждого SENDER_TSPEC для запросов на резервирование, связанных с этим отправителем.
3.2.2. Объект FLOWSPEC при запросе сервиса Guaranteed
Формат объекта RSVP FLOWSPEC, создаваемого получателями, которые запрашивают сервис Guaranteed, показан ниже. Объект, используемый для запроса гарантированного обслуживания, содержит поля TSpec и RSpec, задающие параметры трафика для запрашиваемого получателем потока.
Каждое поле TSpec и RSpec указывается с использованием предпочтительного конкретного представления, описанного в параграфе Invocation Information [RFC 2212]. Значение 2 для идентификатора сервисного заголовка (поле (c) на рисунке ниже) указывает, что запрашивается сервис Guaranteed.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | не используется | 10 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 2 (c) |0| резерв | 9 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 130 (h) | 0 (i) | 2 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Rate [R] (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | Slack Term [S] (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Номер версии формата сообщений (0)
(b) Общий размер (9 слов без учета заголовка)
(c) Сервисный заголовок, служба 2 (Guaranteed)
(d) Размер данных сервиса, 9 слов без учета сервисного заголовка
(e) Идентификатор для параметра 127 (Token_Bucket_TSpec)
(f) Флаги параметра 127 (нет)
(g) Размер параметра 127 (5 слов без учета сервисного заголовка)
(h) Идентификатор для параметра 130 (Guaranteed Service RSpec)
(i) Флаги параметра 130 (нет)
(j) Размер параметра 130 (2 слова без учета заголовка параметра).
В этом объекте параметры TSpec [r], [b] и [p] устанавливаются в соответствии с характеристиками трафика желаемого получателями резервирования (Reservation TSpec). Значение этих полей подробно рассмотрено в [RFC 2211]. Отметим, что вряд ли имеет смысл делать значение [p] меньше, чем [r].
Поля RSpec [R] и [S] указывают запрашиваемую полосу и величину задержки. Выбор этих параметров описан в [RFC 2212].
Параметры [m] и [M] устанавливаются аналогично одноименным параметрам FLOWSPEC для сервиса Controlled-Load, описанным в предыдущем параграфе.
3.3. Объект RSVP ADSPEC
Объект RSVP ADSPEC состоит их фрагментов данных, предоставляемых каждой службой, которая может быть использована приложением. ADSPEC начинается с общего заголовка сообщения, за которым следует фрагмент для принятых по умолчанию общих параметров, а далее фрагменты данных для всех служб управления QoS, которые могут быть выбраны принимающими приложениями. Размер ADSPEC меняется в зависимости от числа и размера фрагментов данных служб и присутствия общих параметров, сверх принятых по умолчанию (см. параграф 3.3.5).
Полное отсутствие фрагмента данных для какого-либо сервиса говорит о том, что приложение-отправитель не знает о нем или не поддерживает его, и указывает промежуточным узлам, что не нужно добавлять или обновлять информацию об этом сервисе в ADSPEC. Это также говорит принимающим приложениям о том, что не следует выбирать этот сервис при запросе резервирования.
Каждый фрагмент данных идентифицируется сервисным заголовком, содержащим идентификатор сервиса, бит прерывания и поле размера.
Поле размера позволяет пропустить информацию ADSPEC для сервиса не элементах сети, которые не понимают или не поддерживают данный сервис. Пропуская такую информацию сетевой элемент устанавливает флаг прерывания (break bit), указывающий, что данные ADSPEC для этого сервиса не были обновлены по крайней мере на одном интервале. Отметим, что флаг прерывания может быть установлен даже для неподдерживаемого сервиса. В любом случае элемент сети, столкнувшись с непонятным сервисным заголовком, просто устанавливает бит 23 для информирования об отсутствии поддержки сервиса и пропускает остаток фрагмента.
Фрагменты данных всегда должны размещаться в ADSPEC по порядку service_number. В частности, фрагмент используемых по умолчанию общих параметров (service_number 1) всегда должен быть первым.
Внутри фрагмента данных сначала должны размещаться специфические для сервиса данные, а за ними — отличные от принятых по умолчанию общие параметры в порядке parameter_number. Размер и структура специфических для сервиса данных фиксируются определением сервиса и не требуют разбора. Остальная часть фрагмента, содержащая отличные от принятых по умолчанию параметры, может менять размер и структуру в зависимости от присутствия конкретных параметров. Эта часть фрагмента должна разбираться с использованием заголовков параметров.
Поскольку общий размер каждого фрагмента данных может меняться, всегда нужно проверять поле размера для определения конца фрагмента, не предполагая фиксированных размеров.
3.3.1. Формат RSVP ADSPEC
Базовый формат ADSPEC показан ниже. Заголовок сообщения и используемые по умолчанию общие параметры присутствуют всегда. Фрагменты для служб Guaranteed и Controlled-Load могут отсутствовать, если сервис не используется в сессии RSVP. При определении новых служб могут добавляться фрагменты данных для них.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (a) | резерв | Msg length - 1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Default General Parameters fragment (Service 1) (c) | | (Присутствует всегда) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Guaranteed Service Fragment (Service 2) (d) | | (Присутствует, если приложение может использовать Guaranteed)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Controlled-Load Service Fragment (Service 5) (e) | |(Присутствует, если прилож. может использовать Controlled-Load)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) — Номер версии формата сообщения (0)
(b) — Общий размер сообщения без учета слова заголовка
(c, d, e) — Фрагменты данных
3.3.2. Принятые по умолчанию общие параметры ADSPEC
Все объекты RSVP ADSPEC содержат общие параметры характеризации, определенные в [RFC 2215]. Значения для глобальных или принятых по умолчанию параметров (значения, применяемые ко всем службам или самому пути) передаются в сервисном фрагменте данных с номером 1, как показано на рисунке выше. Этот фрагмент присутствует всегда и размещается первым.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 1 (c) |x| резерв | 8 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 4 (e) | (f) | 1 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | IS hop cnt (32-битовое целое число без знака) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 6 (h) | (i) | 1 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Path b/w estimate (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 8 (k) | (l) | 1 (m) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum path latency (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 10 (n) | (o) | 1 (p) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Composed MTU (32-битовое целое число без знака) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(c) Сервисный заголовок для службы 1 (Default General Parameters)
(d) Глобальный бит прерывания ([RFC 2215], параметр 2) (маркируется x) и размер блока данных General Parameters.
(e) Идентификатор параметра 4 (параметр Number-of-IS-hops из [RFC 2215])
(f) Байт флагов параметра 4
(g) Размер параметра 4 (1 слово без учета заголовка)
(h) Идентификатор параметра 6 (параметр Path-BW из [RFC 2215])
(i) Байт флагов параметра 6
(j) Размер параметра 6 (1 слово без учета заголовка)
(k) Идентификатор параметра 8 (minimum path latency из [RFC 2215])
(l) Байт флагов параметра 8
(m) Размер параметра 8 (1 слово без учета заголовка)
(n) Идентификатор параметра 10 (composed path MTU из [RFC 2215])
(o) Байт флагов параметра 10
(p) Размер параметра 10 (1 слово без учета заголовка).
Правила создания общих параметров описаны в [RFC 2215].
В показанном выше фрагменте глобальный бит прерывания (бит 23 слова 1, отмеченный (x) на рисунке) служит для индикации присутствия в сети элемента, не поддерживающего службы управления QoS. Этот бит сбрасывается при создании ADSPEC и устанавливается, если в сети встречается элемент, который не поддерживает RSVP или интегрированное обслуживание. Прибытие к получателю ADSPEC с установленным битом указывает на то, что все остальные параметры ADSPEC могут быть некорректными, поскольку не все элементы пути поддерживают обновление ADSPEC.
Общие параметры обновляются каждым узлом сети, который поддерживает RSVP:
-
Когда ADSPEC сообщения PATH встречается с элементом сети, поддерживающим интегрированное обслуживание, часть ADSPEC, связанная с сервисом номер 1, передается модулю, реализующему общие параметры, который обновляет глобальные параметры общего назначения.
-
Когда ADSPEC сообщения PATH встречается с элементом сети, не поддерживающим интегрированное обслуживание или RSVP, должен устанавливаться бит прерывания в сервисном заголовке общих параметров. На практике обычно такая установка выполняется другим элементом сети, который поддерживает RSVP, но уверен в наличии разрывов поддержки интегрированного обслуживания.
-
В любом случае ADSPEC передается обратно RSVP для доставки на следующий интервал пути.
3.3.3. Фрагмент данных ADSPEC для сервиса Guaranteed
Сервис Guaranteed использует RSVP ADSPEC для переноса данных, требуемых для расчета значений C и D, которые передаются из сети в приложение. Минимальный размер непустого фрагмента данных Guaranteed составляет восемь 32-битовых слов. Формат фрагмента ADSPEC для сервиса Guaranteed показан ниже.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 2 (a) |x| резерв | N-1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 133 (c) | 0 (d) | 1 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | End-to-end composed value for C [Ctot] (32-битовое целое) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | 134 (f) | (g) | 1 (h) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | End-to-end composed value for D [Dtot] (32-битовое целое) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | 135 (i) | (j) | 1 (k) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Since-last-reshaping point composed C [Csum](32-битовое целое)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | 136 (l) | (m) | 1 (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | Since-last-reshaping point composed D [Dsum](32-битовое целое)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Service-specific general parameter headers/values, if present | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Сервисный заголовок для службы номер 2 (Guaranteed).
(b) Бит прерывания и размер сервисных данных в 32-битовых словах без учета слова заголовка.
(c) Идентификатор параметра 133 (Composed Ctot).
(d) Байт флагов параметра 133.
(e) Размер параметра 133 (1 слово, не включая заголовка).
(f) Идентификатор параметра 134 (Composed Dtot)
(g) Байт флагов параметра 134.
(h) Размер параметра 134 (1 слово, не включая заголовка).
(i) Идентификатор параметра 135 (Composed Csum).
(j) Байт флагов параметра 135.
(k) Размер параметра 135 (1 слово, не включая заголовка).
(l) Идентификатор параметра 136 (Composed Dsum).
(m) Байт флагов параметра 136.
(n) Размер параметра 136 (1 слово, не включая заголовка).
Когда узел, реально поддерживающий услуги Guaranteed, создает фрагмент adspec для сервиса, значения параметров устанавливаются в соответствии с локальными параметрами. Когда приложение или элемент сети, который не реализует сервис Guaranteed, создает фрагмент adspec для сервиса, ему следует задать для каждого параметра нулевое значение и установить флаг прерывания, показывающий, что сервис не реализован на узле.
Приложение или хост RSVP, создающее сервисный фрагмент adspec, но само не поддерживающее сервис Guaranteed, может создавать усеченный (пустой) фрагмент adspec, содержащий лишь слово заголовка:
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 2 (a) |1| (b) | 0 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Сервисный заголовок для службы номер 2 (Guaranteed).
(b) Бит прерывания (установлен, поскольку сервис не поддерживается).
(c) Размер сервисных данных в 32-битовых словах без учета слова заголовка.
Это может произойти, если передающее приложение или хост не выполняют резервирования сами, но хотят получить его в сети. Отметим, что в этом случае всегда устанавливается бит прерывания, поскольку создатель фрагмента adspec не поддерживает сервиса Guaranteed.
Когда сообщение PATH с фрагментом ADSPEC, содержащим сервисный заголовок для Guaranteed, сталкивается с элементом сети, поддерживающим сервис Guaranteed, фрагмент данных сервиса обновляется, как показано ниже:
-
Если блок данных в ADSPEC пуст (только заголовок), он должен быть сначала расширен до полного фрагмента данных, описанного выше, с начальными значениями Ctot, Dtot, Csum и Dsum, установленными в 0. Пустой фрагмент можно быстро распознать по нулевому значению в поле размера. Значение флага прерывания в заголовке сохраняется при добавлении данных сервиса Guaranteed. Общий размер сообщения и размер фрагмента сервисных данных (поле (b) на рисунке выше) изменяются в соответствии с изменением размера сообщения.
Значения Ctot, Csum, Dtot и Dsum во фрагменте данных ADSPEC заполняются с использованием локальных значений, экспортируемых элементом сети, в соответствии с функциями, определенными в [RFC 2212].
-
Когда сообщение PATH с фрагментом ADSPEC, содержащим сервисный заголовок для Guaranteed, сталкивается с элементом сети, поддерживающим RSVP, но не поддерживающим сервис Guaranteed, этот элемент устанавливает флаг прерывания в сервисном заголовке Guaranteed.
-
Новые значения помещаются в соответствующие поля ADSPEC и объект ADSPEC возвращается RSVP для доставки на следующий интервал пути.
Когда сообщение PATH с фрагментом ADSPEC, содержащим сервисный заголовок для Guaranteed, сталкивается с элементом сети, поддерживающим RSVP, но не поддерживающим сервис Guaranteed, этот элемент устанавливает флаг прерывания в сервисном заголовке Guaranteed.
Когда сообщение PATH с фрагментом ADSPEC без сервисного заголовка Guaranteed встречается с элементом сети, поддерживающим сервис Guaranteed, сервисный модуль Guaranteed этого элемента оставляет ADSPEC неизменным. Отсутствие сервисного заголовка Guaranteed в ADSPEC показывает, что приложение не заботится о сервисе Guaranteed.
3.3.4. Фрагмент данных ADSPEC для сервиса Controlled-Load
В отличие от Guaranteed, сервис Controlled-Load не требует дополнительных данных ADSPEC для корректной работы. Единственными данными ADSPEC, относящимися к сервису Controlled-Load, является бит прерывания Controlled-Load. Следовательно, обычный сервисный блок данных Controlled-Load не содержит дополнительной информации. Минимальный размер сервисного фрагмента данных составляет одно 32-битовое слово.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 5 (a) |x| (b) | N-1 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Service-specific general parameter headers/values, if present | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Сервисный заголовок для службы номер 5 (Controlled-Load).
(b) Бит прерывания.
(c) Размер сервисных данных в 32-битовых словах без учета заголовка.
Связанная с Controlled-Load часть ADSPEC обрабатывается в соответствии со следующими правилами:
-
Когда ADSPEC из сообщения PATH с сервисным заголовком Controlled-Load сталкивается с элементом сети, поддерживающим сервис Controlled-Load, этот элемент не вносит изменений в сервисный заголовок.
-
Когда ADSPEC из сообщения PATH с сервисным заголовком Controlled-Load сталкивается с элементом сети, поддерживающим RSVP, но не поддерживающим сервис Controlled-Load, этот элемент устанавливает бит прерывания в сервисном заголовке Controlled-Load.
-
В любом случае объект ADSPEC возвращается RSVP для доставки на следующий интервал пути.
3.3.5. Замена глобальных данных ADSPEC специфичными для сервиса
В некоторых случаях принятые по умолчанию значения общих параметров не подходят для конкретного сервиса. Например, реализация сервиса Guaranteed может воспринимать только пакеты с меньшим минимальным размером, нежели MTU для канала или доля полосы исходящего канала, доступной для сервиса Controlled-Load на элементе сети, может быть ограничена административно.
В таких случаях специфическое для сервиса значение вместе с принятым по умолчанию сообщается получателю, принимающему объект ADSPEC. Специфические для сервера данные, которые отменяют принятые по умолчанию значения передаются в параметрах с теми же именами, что и общие параметры, но размещаются во фрагменте данных службы управления QoS, к которой относятся. Такие значения называют специфическими для сервиса общими параметрами.
Например, показанный ниже фрагмент Controlled-Load ADSPEC содержит информацию, которая отменяет глобальную оценку пропускной способности пути и задает другое значение:
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 5 (a) |x| (b) | 2 (c) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 6 (d) | 0 (e) | 1 (f) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Path b/w estimate for C-L service (32-битовое число IEEE FP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Сервисный заголовок для службы номер 5 (Controlled-Load).
(b) Бит прерывания.
(c) Размер сервисных данных (два слова без учета заголовка).
(d) Идентификатор параметра 6 (общий параметр AVAILABLE_PATH_BANDWIDTH из [RFC 2215]).
(e) Флаги параметра 6 (не установлены).
(f) Размер параметра 6 (одно слово без учета заголовка).
Присутствие измененных значений параметров во фрагменте данных может быть быстро обнаружено путем проверки поля размера фрагмента, который будет больше «стандартного». Конкретные измененные параметры можно легко идентифицировать проверкой заголовков параметров, поскольку они будут иметь значения parameter_number из общей части пространства номеров параметров (1-127), но при этом будут располагаться в сервисных блоках данных (значения service_numbers от 2 до 254 в поле сервисного заголовка).
Присутствие измененных параметров во фрагменте данных не обязательно. Пара «заголовок-значение» для параметра добавляется только в тех случаях, когда конкретное приложение или служба управления QoS хотят заменить глобальное значение общего параметра специфическим для сервиса.
Как и для опций IP использование замененных параметров не является обязательным. Все реализации должны быть готовы к приему и обработке замененных параметров.
Базовым принципом обработки замененных параметров является использование переписанного значения (локальное или adspec), если оно имеется и применение принятого по умолчанию в противном случае. Если локальный узел экспортирует замененное значение для общего параметра, но в прибывающем adspec нет переписанного значения, локальный узел добавляет его. Ниже приведен псевдокод, описывающий процесс:
/* Параметры правил обработки Adspec *
<принять прибывающий объект ADSPEC от RSVP>
for ( <каждого сервиса с номером N, имеющего фрагмент в ADSPEC> ) {
if ( <локальный узел не поддерживает сервис> ) {
<установить бит прерывания в сервисном заголовке>
} else {
for ( <каждого фрагмента данных для сервиса N> ) {
if ( <локальный сервис N представляет значение параметра> ) {
<объединить значения и обновить adspec>
} else {
/* Должен быть общий параметр или сервис N будет иметь представленное значение.*/
<объедин. полученное значение с принятым по умолчанию локальным и обновить adspec>
}
}
for ( <всех параметров, представленных локальной реализацией сервиса N, но не
найденных в adspec> ) {
/* Значение общего параметра должно быть заменено или adspec будет иметь
* содержащееся значение. */
<объединить локальное замененное значение с принятым значением по умолчанию
(из фрагмента данных сервиса 1) и добавить параметр в adspec фрагмента данных
сервиса N с соблюдением порядка parameter_number>
}
}
}
<передать обновленный ADSPEC обратно в RSVP>
На практике два цикла for могут объединяться. Поскольку замененные параметры в сервисном блоке передаются в порядке нумерации, можно определить присутствие параметров без сканирования всего фрагмента. А поскольку фрагменты данных упорядочиваются по service_number, принятые по умолчанию значения общих параметров всегда будут считываться раньше, чем они могут потребоваться для обновления локальных замененных значений во втором цикле for.
3.3.6. Пример
Приведенный ниже рисунок показывает полный объект adspec для приложения, которое может использовать сервис Controlled-load или Guaranteed. В примере присутствуют фрагменты данных для общих параметров, а также для служб Controlled-load и Guaranteed. Все фрагменты имеют стандартный размер, замены параметров не происходит.
31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Не используется | 19 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |x| резерв (d) | 8 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 4 (f) | (g) | 1 (h) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | zero extension of .. IS hop cnt (16 битов без знака) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 6 (i) | (j) | 1 (k) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Path b/w estimate (32-битовое число IEEE floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 8 (l) | (m) | 1 (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Minimum path latency (32-битовое целое число) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 10 (o) | (p) | 1 (q) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | zero extension of .. composed MTU (16 битов без знака) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 2 (r) |x| reserved (s)| 8 (t) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12 | 133 (u) | (v) | 1 (w) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13 | End-to-end composed value for C [Ctot] (32-битовое целое) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 | 134 (x) | (y) | 1 (z) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15 | End-to-end composed value for D [Dtot] (32-битовое целое) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16 | 135 (aa | (bb | 1 (cc) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 | Since-last-reshaping point composed C [Csum](32-битовое целое)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18 | 136 (dd) | (ee) | 1 (ff) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 19 | Since-last-reshaping point composed D [Dsum](32-битовое целое)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20 | 5 (gg |x 0 (hh) | 0 (ii) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Слово 1: Заголовок сообщения
(a) Заголовок сообщения и номер версии
(b) Размер сообщения (19 слов без учета заголовка)
Слова 2-7: Используемые по умолчанию общие параметры
(c)Сервисный заголовок для службы 1 (Общие параметры, используемые по умолчаню)
(d) Глобальный бит прерывания (NON_IS_HOP – общий параметр 2, маркируется x)
(e) Размер блока данных общих параметров (8 слов)
(f) Идентификатор параметра 4 (общий параметр NUMBER_OF_IS_HOPS)
(g) Байт флагов параметра 4
(h) Размер параметра 4 (1 слово без учета заголовка)
(i) Идентификатор параметра 6 (общий параметр AVAILABLE_PATH_BANDWIDTH)
(j) Байт флагов параметра 6
(k) Размер параметра 6 (1 слово без учета заголовка)
(l) Идентификатор параметра 8 (общий параметр MINIMUM_PATH_LATENCY)
(m) Байт флагов параметра 8
(n) Размер параметра 8 (1 слово без учета заголовка)
(o) Идентификатор параметра 10 (общий параметр PATH_MTU)
(p) Байт флагов параметра 10
(q) Размер параметра 10 (1 слово без учета заголовка)
Слова 11-19: Параметры сервиса Guaranteed
(r) Сервисный заголовок для службы номер 2 (Guaranteed)
(s) Бит прерывания
(t) Размер сервисных данных (8 слов без учета заголовка)
(u) Идентификатор параметра 133 (Composed Ctot)
(v) Байт флагов Composed Ctot
(w) Размер Composed Ctot (1 слово без учета заголовка)
(x) Идентификатор параметра 134 (Composed Dtot)
(y) Байт флагов Composed Dtot
(z0 Размер Composed Dtot (1 слово без учета заголовка)
(aa) Идентификатор параметра 135 (Composed Csum).
(bb) Байт флагов Composed Csum
(cc) Размер Composed Csum (1 слово без учета заголовка)
(dd) Идентификатор параметра 136 (Composed Dsum).
(ee) Байт флагов Composed Dsum
(ff) Размер Composed Dsum (1 слово без учета заголовка)
Слово 20: Параметры Controlled-Load
(gg) Сервисный заголовок для службы номер 5 (Controlled-Load)
(hh) Бит прерывания
(ii) Размер данных Controlled-load (0 слов без учета заголовка).
4. Вопросы безопасности
Правила форматирования и использования сообщений, описанные в этом документе, не создают новых проблем безопасности. Общее применение этих правил для реализации множества служб QoS с использованием RSVP и интегрированных услуг вносит новые требования безопасности — нужно контролировать и аутентифицировать доступ к более качественным услугам. Это требование дополнительно рассмотрено в [RFC 2205], [RFC 2212] и [RFC 2211]. В [RFCRSVPMD5] описан механизм защиты целостности сообщений RSVP, переносящих описанную здесь информацию.
Приложение 1. Правила создания сообщений
В этом разделе приведены правила генерации объектов, форматы которых описаны в разделе 3. Это общий формат кодирования сигналов для объектов данных интегрированных служб в протокольных сообщениях организации и управления. Формат имеет 3-уровневую структуру:
-
Общий заголовок сообщения содержит номер версии и размер сообщения. Стандартный формат этого заголовка обеспечивает возможность использования общего программного кода библиотек для обработки объектов данных множества протоколов организации (соединений).
-
Сервисные фрагменты содержат информацию о конкретных службах управления QoS типа Guaranteed [RFC 2212] или Controlled-load [RFC 2211]. Каждый сервисный фрагмент содержит один или множество параметров. Набор параметров во фрагменте определяется потребностями используемого протокола. Примеры приведены в разделе 2.
-
Параметры представляют собой актуальные данные, используемые для контроля или мониторинга сервиса. Параметры могут быт отдельными величинами (например, целое число) или структурами данных типа TSpec. Специфические для того или иного сервиса параметры определяются спецификацией этого сервиса. Общие параметры с определениями, используемые многими службами, определены в [RFC 2215].
A1.1. Заголовок сообщения
32-битовый заголовок сообщения задает номер версии формата сообщения и его общий размер. Сообщение должно быть выровнено по 32-битовой границе внутри пакета данных транспортного протокола. Размер сообщения указывается в 32-битовых словах без учета слова самого заголовка. Это снижает вероятность случайного сброса (очистки) слова, приводящего к бесконечному циклу при разборе сообщения.
Заголовок сообщения (Message Header) представляет 32-битовым полем, схема которого показана ниже. Заголовок представляется беззнаковым целым числом в формате XDR. Представление в форме беззнакового целого XDR эквивалентно преобразованию битового поля из машинного формата в сетевой порядок байтов (big-endian).
Заголовок сообщения
MSB LSB 31 28 27 16 15 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Не используется | OVERALL LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V – версия формата сообщения (в настоящее время 0).
OVERALL LENGTH – размер сообщения в 32-битовых словах без учета заголовка.
A1.2. Заголовок данных сервиса
После заголовка сообщения размещается один или несколько специфичных для служб блоков данных, каждый из которых содержит данные о конкретной службе управления QoS. Каждый из таких блоков данных начинается с идентифицирующего заголовка. Этот 32-битовый заголовок содержит номер сервиса, однобитовый флаг (бит прерывания – break bit, показывающий отсутствие поддержки управления QoS на пути) и поле размера. Размер блока данных задается в 32-битовых словах и не учитывает размер самого заголовка.
Бит прерывания (если он установлен) показывает, что указанный в заголовке сервис не поддерживается или не распознается в некоторой точке на пути передачи сообщения через сеть. Этот бит соответствует общему параметру NON_IS_HOP, определенному в [RFC 2215]. Бит сбрасывается при генерации сообщения и устанавливается при прохождении через элемент сети, который не поддерживает или не понимает значение service_number, указанное в сервисном заголовке.
Сервисный заголовок (Per-Service Data Header) представляется 32-битовым полем (см. ниже), представляемым, как целое число без знака XDR.
Сервисный заголовок
MSB LSB 31 24 23 16 15 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SVC_NUMBER |B| Резерв | SVC_LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SVC_NUMBER – номер сервиса (Service ID), определяемый его спецификацией.
B – бит прерывания (Break bit) – флаг отсутствия поддержки сервиса на пути.
SVC_LENGTH – размер данных сервиса в 32-битовых словах без учета заголовка.
A1.3. Заголовок параметра
За серверным заголовком следует один или множество блоков параметров сервиса, каждый из которых идентифицируется своим заголовком (Parameter Header). Этот заголовок содержит идентификатор (номер) параметра, размер данных параметра и поле флагов. Далее следует поле (поля) данных параметра. Номер параметра, а также его значение и формат слов данных параметра задаются спецификацией этого параметра.
Заголовок параметра представляется 32-битовым полем, которое кодируется в форме беззнакового целого XDR.
Заголовок параметра
MSB LSB 31 24 23 16 15 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PARAM_NUM |I FLAGS | PARAM_LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PARAM_NUM – номер параметра (определяется спецификацией параметра).
FLAGS – флаги параметра.
PARAM_LENGTH – размер данных параметра в 32-битовых словах без учета слова заголовка.
В настоящее время для поля FLAGS определено значение:
I (бит 23) – INVALID
Этот флаг показывает, что значение параметра не было корректно обработано на одном или множестве элементов пути через сеть. Флаг предназначен для использования в будущих схемах составных служб.
Остальные биты поля FLAGS в настоящее время считаются резервными и должны быть установлены в 0.
A1.4. Данные параметра
Вслед за Parameter Header размещаются реальные данные параметра. Значения параметра представляются в форме одного или множества 32–битовых слов, использующих представление XDR, описанное в [RFC 1832].
Документ, определяющий параметр, должен включать XDR-описание поля данных параметра. Если это не так, описание следует искать в данном документе.
Литература
[RFC 2205] Braden, B., Ed., et. al., “Resource Reservation Protocol (RSVP) – Version 1 Functional Specification”, RFC 2205, September 1997.
[RFC 2216] Shenker, S., and J. Wroclawski. “Network Element QoS Control Service Specification Template”, RFC 2216, September 1997.
[RFC 2212] Shenker, S., Partridge, C., and R Guerin, “Specification of Guaranteed Quality of Service”, RFC 2212, September 1997.
[RFC 2211] Wroclawski, J., “Specification of the Controlled Load Quality of Service”, RFC 2211, September 1997.
[RFC 2215] Shenker, S., and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements”, RFC 2215, September 1997.
[RFCRSVPMD5] Baker, F., “RSVP Cryptographic Authentication”, Work in Progress1.
[RFC 1832] Srinivansan, R., “XDR: External Data Representation Standard”, RFC 1832, August 1995.
Адрес автора
John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139
Phone: 617-253-7885
Fax: 617-253-2673 (FAX)
EMail: jtw@lcs.mit.edu
Перевод на русский язык
Николай Малых
