Примеры стилей

На рис. 4.4.9.6.2. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1 (S2 и S3), подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1 (R2 и R3), которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.

Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на рис. 4.4.9.6.2. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 4.4.9.6.3, 4.4.9.6.4 и 4.4.9.6.5 проиллюстрированы стили резервирования WF, FF и SE, соответственно.

Рис. 4.4.9.6.2. Конфигурация маршрутизатора

Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" показывает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" показывает результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует” каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.

Рис. 4.4.9.6.3, демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение.

Каждый из двух узлов, следующих за интерфейсом IГ посылают независимые запросы резервирования RSVP, эти два запроса должны быть объединены в одну спецификацию flowspec (3B), которая используется для выполнения резервирования в интерфейсе IГ.
Резервирования для интерфейсов IB и IГ должны быть объединены, для того чтобы осуществить переадресацию запросов резервирования далее и получить спецификацию flowspec (4B).

Рис. 4.4.9.6.3. Пример резервирования WF (Wildcard-Filter)
На рис. 4.4.9.6. 4 проиллюстрирован стиль резервирования FF (Fixed-Filter). Для каждого выходного интерфейса, имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различных дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF( S1{4B} ), который посылается предыдущему узлу (IА).
На рис. 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)
Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть рис. 4.4.9.6.2 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, напр., из-за того что сеть обеспечивает более короткий путь для пакетов отправителя к R1. Рис. 4.4.9.6.3 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.

5. Механизмы протокола RSVP
5.1. Сообщения RSVP

Рис. 4.4.9.6.6. Маршрутизатор, использующий RSVP
На рис. 4.4.9.6.6 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль.

Несколько предшествующих узлов и/ или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ. Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений (Resv) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком.
Каждая ЭВМ отправитель передает RSVP сообщения "Path" вдоль уникаст/мультикаст маршрутов, сформированных с помощью маршрутных протоколов. Эти сообщения Path запоминают состояние пути в каждом узле вдоль маршрута. Это состояние пути включает в себя уникастный IP-адрес предыдущего узла, который используется для маршрутизации сообщений Resv от узла к узлу в противоположном направлении. Сообщение Path содержит помимо этого следующую информацию:

Шаблон отправителя

Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.
Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.

Спецификация Tspec отправителя

Сообщения Path должны содержать спецификацию отправителя Tspec, которая определяет характеристики информационного трафика, формируемого отправителем. Спецификация Tspec используется для предотвращения избыточного резервирования.

Спецификация Adspec

Сообщение Path может нести в себе пакет данных оповещения OPWA, известный, как "Adspec". Пакет Adspec, полученный с сообщением Path, передается системе управления трафиком, которая присылает скорректированную версию Adspec. Последняя пересылается далее в виде сообщения Path.
Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP.
6. Объединение Flowspecs
Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является “наибольшей” из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные.
Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec.
Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной. Например, если один запрос требует высокой пропускной способности, а другой – жесткого ограничения задержек, один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна быть способна сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound). В некоторых случаях спецификация flowspec по крайне мере настолько мала насколько возможно; это наибольший верхний предел GLB (Greatest Lower Bound).
Для вычисления эффективного значения flowspec (Re, Te), инсталлируемого в интерфейс, используются следующие шаги [RFC 2210].

Здесь Te – эффективная спецификация Tspec, а Re – эффективная спецификация Rspec.

Определяется эффективная спецификация flowspec для выходного интерфейса. В зависимости от технологии канального уровня, это может требовать объединения спецификаций flowspecs различных последующих узлов. Это означает вычисление эффективной спецификации flowspec, как LUB flowspecs. Какие спецификации следует объединять, определяется средой канального уровня, в то время как процедура объединения определяется используемой моделью обслуживания [RFC 2210]. В результате получается спецификация flowspec, которая непрозрачна для RSVP, но в действительности состоит из пары (Re, Resv_Te), где Re является эффективной спецификацией Rspec, а Resv_Te - эффективная спецификация Tspec.
Производится вычисление спецификации Path_Te, зависящей от приложения и представляющей собой сумму всех Tspecs, которые были присланы в сообщениях Path, пришедших от различных предшествующих узлов (напр., некоторые или все узлы A, Б, и Б' на рис. 4.4.9.6.6).
(Re, Resv_Te) и Path_Te передаются системе управления трафиком. Управление трафиком вычислит эффективную спецификацию flowspec, как минимум Path_Te и Resv_Te.

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). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 4.4.9.6.7 “Получает” и “Отправляет” подразумевает внешнее направление по отношению к маршрутизатору).

Интерфейс IА		Интерфейс IБ
Получает	Отправляет	Получает	Отправляет
WF (* {4B})	WF (* {3B})	WF (* {3B})	WF(*{4B})
Резервирует
* {4B}		* {3B}

Рис. 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 будет убрана, если все ее спецификации фильтров будут ликвидированы.
9. Ошибки
Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.
Однако для синтаксически верных запросов резервирования имеется много способов быть отвергнутыми. Узел может решить аннулировать установленное резервирование из-за более приоритетных заданий. Так как неудовлетворение запроса может быть вызвано объединением нескольких запросов, ошибка резервирования должна быть ретранслирована всем получателям группы. Кроме того, объединение разнородных запросов создает потенциальную трудность, известную как проблема "резервирования килера", в которой один запрос может блокировать услуги другого. В действительности существует две такие проблемы.

Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0.

Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.
Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняется даже в случае не прохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю, установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.

Чтобы решить эту проблему сообщения ResvErr устанавливают дополнительное состояние, называемое, "состояние блокады", в каждом из узлов, через которые проходит это сообщение. Состояние блокады в узле модифицирует процедуру объединения, так чтобы игнорировать блокирующие спецификации flowspec (Q1 в вышеприведенном примере), позволяя скромным запросам проходить и осуществлять свое резервирование. Состояние резервирования Q1 считается в данном случае заблокированным.
Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако, эти резервирования были сохранены по следующим причинам:

Имеется две возможные причины получателю настаивать на резервировании:

Заказываемый ресурс доступен по всей длине пути, или
Нужно получить желаемый уровень QoS вдоль оговоренного пути так далеко, как это возможно. Конечно, во втором случае, а может быть и в первом, получатель захочет настаивать на резервировании, осуществленном вплоть до точки блокировки.

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

Состояние блокады в каждом из маршрутизаторов до узкого места не должно быть немедленно удалено, так как не позволит системе быстро восстановиться.
Если бы мы не обновляли резервирование в предшествующих узлах каждые Tb секунд, они могли бы быть удалены по таймауту (Tb время таймаута состояния блокады).

10. Подтверждение
Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и, если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос.
Этот механизм подтверждения имеет следующую последовательность:

Новый запрос резервирования со спецификацией flowspec больше чем любая из действующих в данной точке спецификаций сессии обычно вызывает либо сообщение ResvErr, либо ResvConf, отправляемое получателю каждым из отправителей данных. В этом случае, сообщение ResvConf будет подтверждением, относящимся ко всему пути.
Получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и он может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.

11. Управление политикой
Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме.

RSVP- запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Такого рода обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя.
Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования.
На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.
Перенос таких данных, поставляемых пользователями, в сообщениях Resv может представлять проблему в случае существенного увеличения числа пользователей. Когда мультикастинг-группа содержит большое число получателей, может оказаться невозможно или нежелательно транспортировать данные, описывающие политику, вдоль всего маршрута. Эти данные должны объединяться как можно ближе к получателям, чтобы избежать чрезмерного информационного потока.
12. Безопасность
При использовании протокола 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 правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.

14. Модель ЭВМ
Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

H1	Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress.
H2	Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress.
H3	Приложение получателя принимает сообщение Path.
H4	Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков.
H5	Приложение отправителя получает сообщение Resv.
H6	Отправитель начинает посылать информационные пакеты.

Существует несколько соображений, касающихся синхронизации.

H1 и H2 могут произойти в любом порядке.
Предположим, что новый отправитель начинает отправку данных (H6), но пока нет мультикастинг маршрутов, так как ни один получатель не подключился к группе (H1). Тогда данные будут выбрасываться в некотором узловом маршрутизаторе (какой это будет узел, зависит от используемого протокола маршрутизации), пока не появится хотя бы один получатель.
Предположим, что новый отправитель начинает рассылку сообщений Path (H2) и данных (H6) одновременно, и имеется некоторое число получателей, но сообщения Resv пока не достигли отправителя (напр., потому что его сообщения Path еще не дошли до получателей). Тогда исходные данные могут прийти к получателю без желаемого уровня QoS. Отправитель может немного облегчить эту проблему, подождав прибытия первого сообщения Resv (H5). Однако получатели, которые достаточно далеко, могут еще не получить необходимого резервирования.
Если получатель начинает посылать сообщения Resv (H4) до получения какого-либо сообщения Path (H3), RSVP пришлет получателю сообщение об ошибке.

Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.

15. Функциональная спецификация RSVP
15.1. Формат сообщений RSVP
Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.
16. Общий заголовок

Рис. 4.4.9.6.8. Формат общего заголовка
В общем заголовке имеются следующие поля:
Vers. 4 бита – Номер версии протокола. В данном описании = 1.
Флаги: 4 бита - 0x01-0x08. Зарезервированы.
Флаги пока не определены.
Тип Msg. Тип сообщения (8 бит).
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
Контрольная сумма RSVP: 16 бит
Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.
Send_TTL: 8 бит
Значение TTL для протокола IP, с которым было послано сообщение.
Длина RSVP: 16 бит
Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.

Содержание раздела