B Коды и значения ошибки

Нижеприведенные коды ошибок могут встретиться в объектах ERROR_SPEC, и предназначены для пересылки оконечным системам. За исключением специально оговоренных случаев эти коды могут использоваться только в сообщениях ResvErr.

Код ошибки = 00: Подтверждение.

Это код зарезервирован для использования в объекте ERROR_SPEC сообщения ResvConf. Значение ошибки также будет равно нулю.

Код ошибки = 01: Отказ системы управления допуском.

Запрос резервирования отвергнут системой управления допуском из-за недостатка ресурсов. Для этого кода ошибки 16 бит поля значение ошибки имеют формат:

ssur cccc cccc cccc

где биты имеют следующие значения:

ss = 00: Младшие 12 бит содержат глобально-определенный субкод (значение приведены ниже).

ss = 10: Младшие 12 бит содержат организационно-специфический субкод. Предполагается, что RSVP интерпретирует этот код как обычное число.

ss = 11: Младшие 12 бит содержат субкод, зависящий от вида услуг. Предполагается, что RSVP интерпретирует этот код как обычное число.

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

u = 0: RSVP отвергает сообщение без модификации локального состояния

u = 1: RSVP может использовать сообщение для модификации локального состояния и для последующей пересылки. Это означает, что сообщение является информационным.

r: зарезервированный бит, должен быть равен нулю.

cccc cccc cccc: 12 битовый код.

Следующие глобально-заданные субкоды могут появиться в младших 12 битах, когда ssur = 0000:

- Субкод = 1: Предел (bound) по задержке не может быть обеспечен.
- Субкод = 2: Запрашиваемая полоса пропускания недоступна.
- Субкод = 3: MTU в flowspec больше чем MTU интерфейса.

Код ошибки = 02: Policy Control failure

Сообщение резервирования или path было отвергнуто по административным причинам, например, не выполнены условия аутентификации, недостаточная квота и т.д.. Этот код ошибки может появиться в сообщении PathErr или ResvErr.

Содержимое поля значение ошибки должно быть определено в будущем.

Код ошибки = 03: Нет информации о проходе для этого сообщения Resv. Нет состояния прохода для данной сессии. Сообщение Resv не может быть переслано.
Код ошибки = 04: Нет информации отправителя для этого сообщения Resv. Имеется состояние прохода для этой сессии, но оно не включает в себя записи отправителя, соответствующей дескриптору потока, который содержится в сообщении Resv. Сообщение Resv не может быть переслано.
Код ошибки = 05: Конфликт со стилем резервирования. Стиль резервирования конфликтует со стилем существующего состояния резервирования. Поле значение ошибки содержит младшие 16 бит вектора опций существующего стиля, с которым произошел конфликт. Сообщение Resv не может быть переслано.
Код ошибки = 06: Неизвестный стиль резервирования. Стиль резервирования неизвестен. Сообщение Resv не может быть переслано.
Код ошибки = 07: Конфликт портов места назначения. Появились сессии для одного и того же адреса места назначения с нулевым и ненулевым значением полей порта назначения. Этот код ошибки может появиться в сообщении PathErr или ResvErr.
Код ошибки = 08: Конфликт портов отправителя. Для одной и той же сессии имеются нулевые и ненулевые порты отправителя в сообщениях Path. Этот код ошибки может появиться только в сообщении PathErr.
Код ошибки = 09, 10, 11: (зарезервировано)
Код ошибки = 12: Привилегированное обслуживание. Запрос обслуживания, определенный объектом STYLE, и дескриптор потока были административно перехвачены.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ssur cccc cccc cccc

Ниже приведены значения старших бит ssur, как они определены при коде ошибки 01. Глобально-заданные субкоды, которые могут появиться в младших 12 битах, когда ssur = 0000 должны быть определены в будущем.

Код ошибки = 13: Неизвестный класс объекта. Этот код ошибки содержит 16-битовое слово, состоящее из (Class-Num, C-тип) неизвестного объекта. Эта ошибка должна быть послана только в случае, когда RSVP намеревается отвергнуть сообщение, как это определено старшими битами Class-Num.

Этот код ошибки может появиться в сообщении PathErr или ResvErr.
Код ошибки = 14: Неизвестный объект C-типа. Значение ошибки содержит 6-битовый код, состоящий из (Class-Num, C-тип) объекта.
Код ошибки = 15-19: (зарезервировано)
Код ошибки = 20: Зарезервировано для API. Поле значение ошибки содержит код ошибки API, которая была обнаружена асинхронно и о которой необходимо уведомить систему соответствующим откликом.
Код ошибки = 21: Ошибка управления трафиком. Запрос управления трафиком не прошел из-за формата или содержимого параметров запроса. Сообщения Resv или Path, которые инициировали вызов, не могут быть пересланы, повторные вызовы бесполезны.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ss00 cccc cccc cccc

Ниже представлены значения старших бит ss, как это определено для кода ошибки 01.

Следующие глобально-заданные субкоды могут появляться в младших 12 битах (cccc cccc cccc), когда ss = 00:

Субкод = 01: Конфликт сервиса. Попытка объединить два несовместимых запроса обслуживания.
Субкод = 02: Сервис не поддерживается. Управление трафиком не может обеспечить запрашиваемый сервис или его приемлемую замену.
Субкод = 03: Плохое значение Flowspec. Запрос неверного формата или неприемлемые требования.
Субкод = 04: Плохое значение Tspec. Запрос неверного формата или неприемлемых требований.
Субкод = 05: Плохое значение Adspec. Запрос неверного формата или неприемлемые требования.
Код ошибки = 22: Ошибка системы управления трафиком. Модули управления трафиком обнаружели системную ошибку. Значение ошибки будет содержать специфический для системы код, предоставляющий дополнительную информацию об ошибке. Предполагается, что RSVP не может интерпретировать его значение.
Код ошибки = 23: Системная ошибка RSVP

Поле значения ошибки предоставляет информацию об ошибке с учетом конкретной реализации приложения. Предполагается, что RSVP не может интерпретировать его значение.

Вообще каждое сообщение RSVP переформируется в каждом узле, а узел, в котором генерируется RSVP сообщение, несет ответственность за его правильную структуру.

Аналогично, каждый узел должен контролировать корректность структуры полученного им сообщения. В случае, когда из-за ошибки программы будет генерировано сообщение с некорректным форматом, оконечная система не обязательно будет проинформирована об этом. Ошибка, скорее всего, будет зафиксирована локально и передана через механизмы управления сетью.

Единственными ошибками формата сообщений, которые доводятся до сведения оконечной системы, являются несоответствия версии.

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

Неверная длина сообщения: Поле длины RSVP не соответствует реальной длине сообщения.
Неизвестная или неподдерживаемая версия RSVP.
Ошибка в контрольной сумме RSVP
Ошибка в INTEGRITY
Нелегальный тип сообщения RSVP
Нелегальная длина объекта: не кратна 4, или меньше 4 байт.
Адрес предыдущего/следующего узла в объекте HOP является нелегальным.
Неверный номер порта источника: Порт источника не равен нулю в спецификации фильтра или шаблоне отправителя для сессии с нулевым портом назначения.
Отсутствует необходимый класс объекта
Нелегальный класс объекта для данного типа сообщения.
Нарушение регламентируемого порядка объектов
Неверное число дескрипторов потока для данного типа сообщения или стиля
Неверный дескриптор логического интерфейса
Неизвестный объект Class-Num.
Адрес места назначения сообщения ResvConf не согласуется с адресом получателя в объекте RESV_CONFIRM.

42. Приложение C. UDP-инкапсуляция

Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы.

Базовая схема UDP-инкапсуляции использует два предположения:

Все ЭВМ способны посылать и получать мультикастные пакеты, если требуется поддержка мультикастных адресов назначения.
Маршрутизаторы первого/последнего узлов должны поддерживать RSVP.

Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов.

Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов.

В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'.

Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'.

В таблицах используются следующие символы.

D является портом назначения (DestAddress) конкретной сессии.
G* является стандартным групповым адресом формата 224.0.0.14, т.е., группа ограничена пределами локальной сети.
Pu и Pu' являются стандартными UDP-портами для UDP-инкапсуляции RSVP, с номерами 1698 и 1699.
Ra равен IP-адресу интерфейса маршрутизатора `a'.
Интерфейс маршрутизатора `a' локально доступен для Hu и Hr.

Таблица 4.4.9.6.1. Правила UDP-инкапсуляции для уникастных сообщений Path и Resv
(D – уникастный адрес места назначения; R – маршрутизатор; Raw – режим произвольных операций сетевого ввода/вывода.)

Узел	RSVP посылает	RSVP получает
Hu	UDP(D/Ra,Pu) [1]	UDP(D,Pu) и UDP(D,Pu’) [2]
Hr	Raw(D) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(D, Pu) [2] (игнорировать Pu’)
R (интерфейс а)	Raw(D) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(Ra, Pu) (игнорировать Pu’)

<

/p>

[1]	Hu посылает уникастные сообщения Path либо по адресу D, если D является локальным, либо по адресу Ra маршрутизатора первого узла. Ra предполагается известным.
[2]	Здесь D является адресом локального интерфейса, через который приходит сообщение.
[3]	Это предполагает, что приложение присоединилось к группе D.

Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path

Узел	RSVP посылает	RSVP получает
Hu	UDP(G*,Pu)	UDP(D,Pu’) [3] и UDP(G*,Pu)
Hr	Raw(D,Tr) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(G*, Pu) (игнорировать Pu’)
R (интерфейс а)	Raw(D,Tr) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(G*, Pu) (игнорировать Pu’)

Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора.

Когда получен UDP-инкапсулированный пакет, в большинстве систем TTL не доступно для приложения. Процесс RSVP, который получает UDP-инкапсулированное сообщение Path или PathTear должен использовать поле Send_TTL общего RSVP-заголовка для извлечения значения TTL. В тех случаях, когда это по каким-либо причинам не приемлемо, значение TTL может быть задано вручную при конфигурации.

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

Hu может запускать как уникастные, так и мультикастные сессии в UDP(Ra,Pu) с TTL=Ta. Здесь Ta должно быть достаточным, чтобы достичь R. Если Ta слишком мало, сообщение Path не дойдет до R. Если Ta слишком велико, R и последующие маршрутизаторы могут переправлять UDP-пакет до тех пор, пока не иссякнет запас по TTL.

Это включит UDP-инкапсуляцию между маршрутизаторами в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Hu должна быть непосредственно сконфигурирована с использованием Ra и Ta.
Конкретная ЭВМ локальной сети, соединенная с Hu может считаться “транспортной ЭВМ RSVP". Транспортная ЭВМ будет прослушивать (G*,Pu) и переправлять любое сообщение Path непосредственно R, хотя это и не будет маршрутом передачи данных. Транспортная ЭВМ должна быть сконфигурирована с использованием Ra и Ta.

Библиография

[Baker96]	Baker, F., "RSVP Cryptographic Authentication", Work in Progress.
[RFC 1633]	Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994.
[FJ94]	Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994.
[RFC 2207]	Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC-2208]	“Resource Reservation Protocol (RSVP) – Version 1. Applicability Statement”.
[RFC-2209]	“Resource Reservation Protocol (RSVP) – Version 1.Message Processing Rules”
[RFC 2113]	Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997.
[RFC 2210]	Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997.
[RFC-2211]	“Specification of the Controlled-Load Network Element Service”
[RFC-2212]	“Specification of Guarantied Quality of Service”
[PolArch96]	Herzog, S., "Policy Control for RSVP: Architectural Overview". Work in Progress.
[OPWA95]	Shenker, S. and L. Breslau, "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.

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