Спецификация LDP, RSVPTE, GMPLS

12.3. Расширения протокола управления резервированием (RSVP-TE) при обобщенной многопротокольной коммутации по меткам (GMPLS)

Введение

Протокол обобщенного MPLS раздвигает его применимость с поддержки пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации: TDM (TimeDivision Multiplex — мультиплексирование по времени), ?коммутатор (LSC) и волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов интерфейсов и коммутации, сделано в [RFC-3471]. Ниже рассматриваются специфические форматы RSVP-TE и механизмы, необходимые для поддержки всех четырех классов интерфейсов (RFC-3473, L. Berger, January 2003).

RFC-3471 следует рассматривать как составную часть этого документа. Здесь определены также возможности RSVP-TE для поддержки быстрого уведомления об отказах.

Форматы, относящиеся к меткам. Объект запроса обобщенной метки

Сообщение Path, которое запоминают состояние пути в каждом узле вдоль маршрута и транспортирует запрос метки, должно содержать специфический тип кодирования LSP (Label Switched Path — путь с коммутацией по меткам), чтобы гарантировать максимальную гибкость коммутации в транзитных LSR (Label Switching Router). Объект запроса обобщенной метки устанавливается входным узлом, передается без изменений транзитными узлами, и используется узлом адресатом. Поле тип коммутации может изменяться от шага к шагу. Формат объекта запроса обобщенной метки показан ниже (рис. 12.58).

Рис. 12.58.

Описание параметров смотри в [RFC-3471].

Узел, который обрабатывает сообщение Path, содержащее запрос обобщенной метки, должен проверить, что запрошенные параметры отвечают возможностям самого узла и интерфейса, через который передается трафик и которому приходящая метка должна быть присвоена. Узел может непосредственно поддерживать LSP или использовать туннель (FA), т.е. другой класс коммутации. В любом случае, должен проверяться каждый параметр. Заметим, что локальная политика узла определяет то, когда могут применяться туннели и когда они могут создаваться. Локальная политика допускает динамическое создание туннелей или динамическое управление. Более подробную информацию о туннелях и обработке ER-шагов при использовании туннелей можно найти в [MPLS_HIERARCHY].

Транзитные и оконечный узел должны проверять, что сам узел и, где необходимо, интерфейс или туннель, куда предается трафик, поддерживают запрошенный тип кодирования LSP. Если кодирование не поддерживается, узел должен генерировать сообщение PathErr с указанием "Routing problem/Unsupported Encoding" (проблема маршрутизации/неподдерживаемое кодирование).

Узлы должны проверять, что тип, указанный в параметре тип коммутации (Switching Type), поддерживается соответствующим входным интерфейсом. Если тип не поддерживается, узел должен сформировать сообщение PathErr с индикацией "Routing problem/Switching Type" (проблема маршрутизации/тип коммутации).

Параметр G-PID контролируется только на выходе. Если указанный G-PID не поддерживается, тогда выходной узел должен сформировать сообщение PathErr с указанием "Routing problem/Unsupported L3PID" (проблема маршрутизации/неподдерживаемый L3PID). В этом случае PSC и, когда запрашивается выдача предпоследнего узла (PHP), предпоследний узел также проверяет (запоминает) G-PID при обработке сообщения Resv. При этом, если G-PID не поддерживается, тогда предпоследний узел должен сформировать сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение ResvErr может содержать набор приемлемых меток.

Когда не формируется сообщение об ошибке, происходит нормальная обработка. В случае транзитных узлов это обычно приводит к передаче сообщения Path. В случае оконечного узла и специального варианта PHP это вызывает генерацию сообщения Resv.

Кодирование полосы

Кодирование частотного диапазона выполняется в объектах SENDER_TSPEC и FLOWSPEC. Определения значений, используемых для специальных сигнальных типов, смотри в [RFC-3471]. Эти величины устанавливаются в поле Peak Data Rate (пиковая скорость передачи данных) объектов In t-Serv.

Объект обобщенной метки

Ниже представлен формат объекта обобщенной метки (рис. 12.59):

Рис. 12.59.

Описание параметров и кодирования меток смотри выше и в [RFC-3471].

Обобщенные метки передаются вышестоящим LSR сообщениями Resv. Присутствие объектов обобщенной и нормальной метки в сообщении Resv является протокольной ошибкой и должно обрабатываться получателем как некорректное сообщение.

Получатель сообщения Resv, содержащего обобщенную метку, проверяет приемлемость полученных параметров. Если метка неприемлема, тогда получатель должен сформировать сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).

Объект коммутируемого интервала длин волн

Коммутация частотных диапазонов использует тот же формат, что и обобщенная метка. Метка полосы частот использует C-тип (3).

В контексте коммутации частотных диапазонов обобщенная метка имеет следующий формат (рис. 12.60).

Рис. 12.60.

Описание параметров смотри в [RFC-3471].

Рассматриваемые процедуры работают при коммутации диапазонов длин волн. Если какое-либо поле метки не распознано или имеет неприемлемое значение, генерируется сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).

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

Эта операция должна быть выполнена для обоих направлений, если для диапазона длин волн используется двунаправленный туннель.

Объект предлагаемой метки

Формат объекта Suggested_Label аналогичен описанному для обобщенной метки. Он применяется в сообщениях Path. Объект Suggested_Label использует номер класса 129 (в форме 10bbbbbb ) и C-тип предлагаемой метки.

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

Согласно [RFC-3471], если в нижерасположенный узел приходит метка, которая отличается от предложенной сверху, вышестоящий LSR должен либо реконфигурироваться, либо отравлять сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Кроме того, входной узел не должен передавать данные, используя предложенную метку, до тех пор, пока нижерасположенный узел не пришлет соответствующую метку вверх.

Объект набора меток

Объект Label_Set использует номер класса 36 (в форме 0bbbbbbb ) и C-тип 1. Он применяется в сообщениях Path. Label_Set имеет следующий формат (рис. 12.61).

Рис. 12.61.

Тип метки: 14 бит

Указывает на тип и формат меток, содержащихся в объекте. Значения соответствуют C-типу объекта RSVP_LABEL. В этом поле используются только младшие 8 бит. Описания других параметров смотри выше в разделе 12 и в [RFC-3471].

Набор меток определяется одним или более объектами Label_Set. Специфические метки/субканалы могут быть добавлены или удалены из набора меток посредством объектов операций нуль (0) и один (1), соответственно. Диапазоны меток/субканалов могут дополняться или удаляться из набора меток посредством операций два (2) и три (3) объектов, соответственно. Когда объекты Label_Set только перечисляют метки/субканалы, подлежащие удалению, это подразумевает, что остальные метки приемлемы. Отсутствие любого объекта Label_Set подразумевает, что все метки приемлемы. Набор меток (Label Set) включается, когда узел желает ограничить перечень меток, которые могут использоваться ниже по течению.

По получении сообщения Path принимающий узел ограничит выбор меток одной из (Label Set). Узлы, способные осуществлять преобразования меток, могут также удалять набор меток, прежде чем переадресовать сообщение Path. Если узел не может извлечь метку из набора или если возникает проблема с анализом объектов Label_Set, тогда реализация запроса завершается и формируется сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

После получения сообщения Path список меток сравнивается с набором доступных меток для выходного интерфейса и список перекрытия пересылается в сообщении Path. Когда результирующий набор меток пуст, маршрут разрывается и посылается сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

Заметим, что перекрытие базируется на физических метках (действительные длины волн/диапазонов), которые могут отличаться логическими значениями в других сегментах пути; в результате узел ответственен за то, что физические характеристики адекватны, или за отбрасывание конкретных величин из набора меток, если подходящей логической метки нет.

При обработке сообщения Resv в промежуточном узле, метка, передаваемая наверх, должна входить в перечень меток (Label Set).

При получении сообщения Resv узел, который не может осуществлять преобразования меток, не имеет иной возможности реагирования, кроме использования физической метки (длины волны/диапазона волн), которую получил в сообщении Resv. В этом случае применение и передача далее набора меток существенно сократит вероятность того, что это присвоение потерпит неудачу.

Двунаправленные LSP

Установление двунаправленного LSP отмечается наличием вышестоящей метки (Upstream Label) в сообщении Path. Объект Upstream_Label имеет тот же формат, что и обобщенная метка. Объект Upstream_Label использует номер класса 35 (в форме 0bbbbbbb ) и C-тип метки.

Процедуры

Процесс установления двунаправленного LSP реализуется так же, как и для однонаправленного LSP с некоторыми дополнениями. Для поддержки двунаправленных LSP в сообщение Path добавляется объект Upstream_Label. Объект Upstream_Label должен определять метку, которая пригодна для переадресации в момент отправки сообщения Path.

Когда получено сообщение Path, содержащее объект Upstream_Label, получатель сначала проверяет, что вышестоящая метка приемлема. Если метка неприемлема, получатель должен послать сообщение PathErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение PathErr может содержать набор приемлемых меток.

Промежуточный узел должен присвоить метку для исходящего интерфейса и установить внутренние проходы для данных перед записью исходящей метки и отправкой сообщения Path. Если промежуточный узел не может присвоить метку или выделить внутренние ресурсы, то он должен послать сообщение PathErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/отказ выделения метки MPLS). Оконечные узлы обрабатывают сообщения Path как обычно, за исключением того, что вышестоящая метка может быть использована немедленно для передачи трафика данных, ассоциированных с LSP в направлении узла-инициатора.

Когда удаляется двунаправленный LSP, upstream (вышестоящая) и downstream (нижестоящая) метки аннулируются, после чего они становятся непригодными для пересылки данных.

Разрешение конфликтов

Существует два потенциальных конфликта, которые следует рассматривать при формировании двунаправленного LSP с поддержкой RSVP-TE. Первый связан с тем, что в RSVP ID узла равно IP-адресу, используемому в объекте RSVP_HOP. Второй связан с тем, что ID узла соседа может быть неизвестен при посылке исходного сообщения Path. Когда это происходит, узел должен выбрать метку случайным образом из доступного набора.

Уведомление

Ниже рассмотрено несколько типов расширений, связанных с уведомлениями. Первое расширение определяет объект набора приемлемых меток (Acceptable Label Set) для поддержки уведомлений в случае ошибок с метками и других событий в узлах, ответственных за восстановление разрушенных LSP. Второе расширение, объект запроса уведомления (Notify Request), определяет ситуацию, при которой следует посылать уведомление. Третье расширение, сообщение Notify, предоставляет уведомление об общих событиях. Последнее расширение, относящееся к уведомлениям, позволяет удалять состояние Path при обработке сообщений PathErr.

Объект набора приемлемых меток

Объекты Acceptable_Label_Set используют номер класса 130 (в форме 10bbbbbb ). Остальное содержимое объекта, включая C-тип, имеет идентичный формат с объектом Label_Set.

Объекты Acceptable_Label_Set могут транспортироваться в сообщениях PathErr и ResvErr. Процедуры определения приемлемого списка меток (Acceptable Label Set) следуют за процедурами определения набора меток (Label Set). В частности, приемлемый набор меток определяется из одного или нескольких объектов Acceptable_Label_Set. С помощью объектов операций нуль (0) и один (1), соответственно, могут быть добавлены или исключены специфические метки/субканалы из перечня приемлемых меток. С помощью объектов операций (2) и (3), соответственно, могут быть добавлены или исключены диапазоны меток/субканалов. Когда объекты Acceptable_Label_Set просто перечисляют метки/субканалы, подлежащие удалению, это подразумевает, что все остальные метки являются приемлемыми.

Включение объектов Acceptable_Label_Set является опционным. Если такой объект включен, сообщение PathErr или ResvErr должно содержать указание на "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Отсутствие объекта Acceptable_Label_Set не имеет никакого специального значения.

Объекты запросов уведомления

Уведомления могут посылаться с помощью сообщений Notify, определенных ниже. Объект запроса уведомления используется для запроса генерации уведомления. Уведомление, т.е., посылка сообщения Notify, может быть запрошено как сверху, так и снизу LSP.

Необходимая информация

Объект запроса уведомления может транспортироваться в сообщениях Path или Resv. Номер класса Notify_Request равен 195 (в форме 11bbbbbb). Запрос уведомления имеет следующий формат (рис. 12.62):

Рис. 12.62.

• Объект запроса уведомления IPv4

  Адрес узла уведомления IPv4: 32 бита

  IP-адрес узла, который должен быть уведомлен при генерации сообщения ошибки.
• Объект запроса уведомления IPv6 (рис. 12.63)

  Адрес узла уведомления IPv6: 16 байт

  IP-адрес узла, который должен быть уведомлен при генерации сообщения ошибки.

Рис. 12.63.

Если сообщение содержит несколько объектов Notify_Request, только первый объект имеет значение. Последующие объекты Notify_Request могут игнорироваться и не передаваться далее.

Объект запроса уведомления (Notify Request) может быть введен в сообщение Path или Resv, чтобы указать адрес узла, который должен быть уведомлен об отказе LSP. Как было замечено выше, могут посылаться запросы уведомления как вверх, так и вниз по течению. Уведомления, направленные вверх, отмечаются включением объекта запроса уведомления (Notify Request Object) в соответствующее сообщение Path. Уведомления, направленные вниз, отмечаются включением объекта запроса уведомления в соответствующее сообщение Resv. Узел, получающий сообщение, которое содержит объект запроса уведомления, должен запомнить адрес узла уведомления (Notify Node Address) в соответствующем блоке состояний. Если узел является транзитным, он также должен включить объект запроса уведомления в исходящее сообщение Path или Resv. Исходящий адрес узла уведомления может корректироваться на основе местной политики.

Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет сформировано.

Сообщение уведомления

Сообщение Notify предоставляет механизм информирования несмежных узлов LSP о событиях. Сообщения Notify обычно генерируются только после получения объекта запроса уведомления. Сообщения Notify отличается от определенных ранее сообщений об ошибках (т.е., сообщения PathErr и ResvErr) тем, что они могут быть адресованы узлу, отличному от ближайшего соседа сверху или снизу. Сообщение Notify не заменяет существующие сообщения об ошибках. Оно может быть послано либо (a) в нормальной ситуации, когда транзитные узлы переадресуют сообщения Notify узлу-адресату, подобно обработке ResvConf в [RFC-2205]; либо (b) путем инкапсуляции в новый IP заголовок, чье место назначения соответствует IP-адресу места назначения. Вне зависимости от механизма передачи, узлы, получающие сообщение Notify, не адресованное им, просто передают его дальше без модификации.

Чтобы обеспечить надежную доставку сообщения Notify, используется сообщение Ack [RFC-2961] для подтверждения получения сообщения. Подробности надежной доставки сообщений RSVP смотри в [RFC-2961].

Сообщение уведомления Notify является обобщенным сообщением уведомления. IP-адрес места назначения устанавливается равным адресу запросившего получателя. Сообщение Notify посылается без аварийной опции маршрутизатора. Одно сообщение Notify может содержать несколько уведомлений.

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, детектировавшего ошибку, или отказавшего канала. Определение ERROR_SPEC смотри в [RFC-2205]. MESSAGE_ID и сопряженные с ним объекты определены в [RFC-2961].

Сообщения Notify чаще всего генерируются узлами, зарегистрировавшими ошибку, которая запустила процесс формирования сообщения PathErr или ResvErr. Если нужно сформировать сообщение PathErr и получен объект запроса уведомления в соответствующем сообщении Path, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Если должно быть сформировано сообщение ResvErr и в соответствующем сообщении Resv получен объект запроса уведомления, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Как ранее упоминалось, одна ошибка может вызвать сообщения Notify, направленные вверх и вниз по течению. Заметим, что сообщение Notify не должно генерироваться, если только не получен соответствующий объект запроса уведомления.

Когда генерируются сообщения Notify, узел должен попытаться объединить уведомления, адресованные одному и тому же узлу, и использовать в сообщении Notify одну и ту же общую ERROR_SPEC. Средства, с помощью которых узел определяет, какую информацию можно объединить, зависят от конкретной реализации. Если для этой цели применяется таймер, реализация должна позволять пользователю конфигурировать интервал, в течение которого уведомления объединяются; длительность интервала уведомлений в этом случае по умолчанию равна 1 мсек. Сообщения Notify должны доставляться с использованием механизма надежной доставки, описанного в [RFC-2961].

После получения сообщения уведомления узел должен послать соответствующие сообщение Ack.

Удаление состояния с помощью сообщения PathErr

Сообщение PathErr, как это определено в [RFC-2205], посылается от узла к узлу отправителю соответствующего сообщения Path. Промежуточные узлы могут инспектировать это сообщение, но не должны ничего предпринимать. В среде, где сообщения Path маршрутизируются согласно IGP, а маршруты могут изменяться динамически, такое поведение является позитивным.

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

Ситуация может существенно улучшиться, если разрешить промежуточным узлам при определенных ошибках удалять состояния. Чтобы облегчить эту процедуру, в объекте ERROR_SPEC определен новый флаг. Два описанных в настоящее время объекта ERROR_SPEC (объекты спецификации ошибки IPv4 и IPv6) содержат однобайтное поле флага. В этом поле определены два флага. Данная спецификация определяет третий флаг, 0x04, Path_State_Removed.

Семантика флага Path_State_Removed означает, что узел, переадресующий сообщение ошибки, удалил состояние Path, ассоциированное с PathErr. По умолчанию, флаг Path_State_Removed всегда равен нулю при генерации или при переадресации сообщения PathErr. Узел, который сталкивается с ошибкой, может установить этот флаг, если ошибка вызывает ликвидацию состояния, заданного в Path. Если узел, устанавливающий флаг, не является местом назначения, он должен сформировать соответствующее сообщение PathTear. Узел, получающий сообщение PathErr, которое содержит объект ERROR_SPEC с установленным флагом Path_State_Removed, может также удалить соответствующее состояние Path. Если состояние Path удалено, в исходящем сообщении PathErr следует установить флаг Path_State_Removed. Узел, который не удаляет ассоциированное состояние Path, не должен устанавливать флаг Path_State_Removed. Узел, который получает сигнал ошибки с флагом Path_State_Removed, равным нулю, не должен устанавливать этот флаг, если только он не генерирует соответствующее сообщение PathTear. Заметим, что использование этого флага не вызывает каких-либо проблем совместимости.

Явное управление по меткам

Метки ERO (Explicit Route Object) и субобъекты RRO (Record Route Object) определены для поддержки явного управления метками. Заметим, что субобъект RRO метки определен в [RFC-3209] и расширен для поддержки двунаправленных LSP.

Субобъект ERO метки

Субобъект ERO метки определен следующим образом (рис. 12.64):

Рис. 12.64.

Описание L, U и параметров метки смотри в [RFC-3471].

Тип = 3 (метка)

Длина

Поле длина содержит общую длину субобъекта в байтах, включая поля тип и длина. Длина должна быть кратной 4.

C-тип

C-тип включенного объекта метка. Копируется из объекта метка.

Субобъект метки следует за субобъектом, содержащим IP-адрес или идентификатор интерфейса [RFC-3477], ассоциированные с каналом, где его планируется использовать. Могут присутствовать до двух субобъектов метки, один для метки вниз и один для метки вверх по течению. В следующих ситуациях вырабатывается сигнал ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута):

• если субобъекту, содержащему IP-адрес, не предшествует первый субобъект метки или идентификатор интерфейса [RFC-3477], ассоциированные с исходящим каналом;
• для субобъекта метки, следующего за субобъектом с установленным битом L;
• при установке однонаправленного LSP, если должен быть субобъект метки с установленным битом U ;
• если имеются два субобъекта метки с идентичными значениями бита U.

Чтобы поддерживать субобъект метки, узел должен проверять, является ли субобъект, следующий за его ассоциированным адресом/интерфейсом, субобъектом метки. Если это так, один субобъект просматривается для однонаправленных LSP и два — для двунаправленных. Если бит U субобъекта равен нулю, тогда значение метки копируется в новый объект Label_Set. Этот объект Label_Set должен быть включен в соответствующее исходящее сообщение Path.

Если U -бит рассматриваемого субобъекта равен 1, то метка относится к восходящему потоку (для двунаправленного LSP). Если эта метка неприемлема, должно формироваться сообщение ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута). Если метка приемлема, она копируется в новый объект Upstream_Label. Этот объект Upstream_Label должен быть включен в соответствующее исходящее сообщение Path. После обработки субобъекты метки удаляются из ERO.

Из рассмотрения описанных процедур следует вывод, что субобъекты метки никогда не могут быть первыми субобъектами во вновь полученном сообщении. Если субобъект метки является первым субобъектом в полученном ERO, тогда ситуация должна рассматриваться как ошибка "Bad strict node".

Субобъект RRO метки

Субобъект RRO метки имеет следующий формат (рис. 12.65):

Рис. 12.65.

Описания параметров U и метки смотри в [RFC-3471].

Тип 3 (метка)

Длина. Описание смотри в [RFC-3209].

Флаги. Описание смотри в [RFC-3209].

C-тип. C-тип включенного объекта метки. Копируется из объекта метки.

Субобъекты RRO метки включаются в RRO, как это описано в [RFC-3209]. Единственное отличие в использовании и обработке по сравнению с [RFC-3209] заключается в том, что для меток двунаправленных LSP должны быть добавлены субобъекты для обоих направлений.

Объект защиты

Использование объекта защиты является опционным. Объект включается для описания специфических атрибутов защиты LSP. Объект защиты использует номер класса 37 (в форме 0bbbbbbb ). Объект защиты имеет формат (рис. 12.66):

Рис. 12.66.

Процедуры

Транзитные узлы, обрабатывающие сообщение Path, которое содержит объект защиты (Protection Object), должны проверять, можно ли реализовать запрашиваемую защиту в выходном интерфейсе или туннеле (FA). Если это невозможно, узел должен сформировать сообщение PathErr, со значением "Routing problem/Unsupported Link Protection" (проблема маршрутизации/неподдерживаемая защита канала).

Административная информация состояний

Административная статусная информация содержится в объекте Admin_Status. Объект предоставляет информацию, относящуюся к административному состоянию конкретного LSP. Информация используется двумя способами. В первом — объект содержится в сообщениях Path и Resv для указания административного состояния LSP. Во втором — объект транспортируется в сообщении уведомления для запроса к входному узлу изменить административное состояние LSP.

Объект административного статуса

Использование объекта Admin_Status является опционным. Он использует номер класса (ClassNumber) 196 (в виде 11bbbbbb ). Формат объекта Admin_Status имеет вид (рис. 12.67):

Рис. 12.67.

Описания параметров смотри выше и в [RFC-3471].

Процедуры для сообщений Path и Resv

Объект Admin_Status используется для уведомления каждого узла вдоль пути о состоянии LSP. Статусная информация обрабатывается всеми узлами, основываясь на местной политике, и затем передается соответствующими сообщениями. Объект может быть вставлен в сообщение Path для входного узла или Resv — для выходного. Отсутствие объекта эквивалентно получению объекта, со всеми значениями, равными нулю. Транзитные узлы, получая сообщения nonrefresh Path или Resv, содержащие объект Admin_Status, обновляют свое локальное состояние, выполняют какую-то локальную операцию в соответствии со статусом и затем передают полученный объект Admin_Status посредством исходящего сообщения Path или Resv. Если значения объекта Admin_Status, полученного в сообщении Resv, отличаются от значений, полученных в сообщении Path, тогда, с одним исключением, никаких локальных действий не должно быть предпринято, но значения должны быть переданы дальше. Единственная ситуация, когда с получ енными в Resv значениями следует осуществить некоторые локальные действия, — это случай получения R и D битов равными 1.

Краевые узлы, которые получают сообщение nonrefresh Path или Resv, содержащее объект Admin_Status, также обновляют свои состояния и выполняют соответствующие локальные операции с учетом текущего состояния. Когда поступил объект административного состояния с битом R =1, получивший краевой узел должен перенести полученные значения в соответствующее исходящее сообщение. В частности, если выходной узел получает сообщение Path с битом R Admin_Status =1, а узел ранее послал сообщение Resv, соответствующее сообщению Path, узел должен послать обновленное сообщение Resv, содержащее объект Admin_Status с тем же набором значений, за исключением бита R. Более того, выходной узел должен гарантировать, что последующие сообщения Resv, посланные узлом, содержат тот же самый объект административного состояния.

Кроме того, если входной узел получает сообщение Resv с установленным битом R в объекте Admin_Status, узел должен послать обновленное сообщение Path, содержащее объект Admin_Status со значениями, полученными в сообщении Resv, за исключением R -бита. Кроме того, входной узел должен также гарантировать, что последующие сообщения Path, посланные этим узлом, содержат объект административного статуса (Admin Status Object).

Процедура аннулирования

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

1. Входной узел предваряет ликвидацию LSP введением объекта административного статуса в сообщение Path и установкой битов R (Reflect) и D (Delete).
2. Транзитные и выходной узлы обрабатывают объект административного статуса, как это было описано выше.
3. По получении объекта административного статуса с битом D (Delete) =1 в сообщении Resv, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP, при этом выполняется обычная обработка RSVP.

В таких обстоятельствах при ликвидации LSP со стороны выходного узла эта процедура должна предусматривать следующие действия.

1. Выходной узел индицирует свое желание аннулирования путем введения объекта своего административного состояния в сообщение Resv и установки битов R (Reflect) и D (Delete).
2. Транзитные узлы обрабатывают объект административного состояния, как это описано выше.
3. После получения в сообщении Resv объекта Admin Status с битом D (Delete) =1, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP.

Совместимость и процедуры обработки ошибок

Возможно, что некоторые узлы вдоль LSP не будут поддерживать объект административного статуса. В случае не поддерживающего транзитного узла объект будет передан через узел без модификации и обычная обработка продолжится. В случае не поддерживающего выходного узла объект административного состояния не будет передан назад в сообщении Resv. Чтобы поддержать вариант не поддерживающего выходного узла входной узел должен только ждать оговоренное время. Когда период ожидания истек, входной узел посылает сообщение PathTear. По умолчанию этот период должен равняться 30 секундам.

Процедуры сообщения уведомления

Промежуточный и оконечный узлы могут запустить процесс установления административного статуса посредством использования сообщений Notify. Чтобы выполнить это, промежуточный или оконечный узел генерирует сообщение уведомления (Notify) с соответствующей информацией сессии в направлении вверх по течению. Объект административного состояния должен включаться в данные сессии. Бит R (Reflect) не должен быть установлен. Сообщение Notify может быть, если требуется, инкапсулировано.

Входной узел, получив сообщение уведомления, содержащее объект административного состояния с битом D (Delete) =1, должен инициировать процедуру аннулирования, описанную в предыдущем разделе. Другие биты должны передаваться в исходящем сообщении Path обычным образом.

Совместимость и процедуры обработки ошибок

Для того, чтобы решить проблему в случае узлов, не поддерживающих объект административного состояния, необходима специальная обработка и другие условия формирования сигнала ошибки. В частности, узел, который посылает сообщение уведомления, содержащее объект административного состояния с битом D (Down) =1, должен проверять, получил ли он соответствующее сообщение Path с битом D (Down) =1 за определенный период, заданный при конфигурации. По умолчанию этот период должен равняться 30 секундам. Если узел не получает такого сообщения, он должен послать сообщение PathTear вниз по течению и сообщение ResvTear или PathErr с флагом Path_State_Removed =1 — вверх.

Отделение канала управления. Идентификация интерфейса

Выбор информационного интерфейса всегда осуществляется отправителем сообщения Path путем включения идентификатора интерфейса информационного канала в сообщение, используя новый подтип объекта RSVP_HOP. Для двунаправленных LSP отправитель выбирает интерфейс данных для каждого направления. Во всех случаях, кроме объединения каналов, нижестоящий интерфейс предполагает, что это вышестоящий интерфейс. В случае объединения отправитель идентифицирует явно интерфейс, используемый для обоих направлений. Новый объект RSVP_HOP применяется в сообщении Resv, чтобы указать интерфейсы, используемые нижележащими узлами.

Объекты IF_ID RSVP_HOP

Формат объекта IPv4 IF_ID RSVP_HOP (рис. 12.68):

Рис. 12.68.

Формат объекта IPv6 IF_ID RSVP_HOP (рис. 12.69):

Рис. 12.69.

Описания адресов узлов и полей указателя смотри в [RFC-2205]. Описания параметров и кодирование TLV содержится в [RFC-3471].

Объект IF_ID RSVP_HOP используется вместо определенных выше объектов RSVP_HOP. Он применяется в соединениях, где нет однозначных ассоциаций между каналами управления и данных (смотри [RFC-3471]). Поля Hop Address (адрес шага) и указатель логического интерфейса используются в соответствии со стандартом RSVP [RFC-2205].

TLV применяются для идентификации каналов данных, ассоциированных с LSP. Для однонаправленных LSP должен быть указан нисходящий канал данных. Для двунаправленных LSP указывается общий нисходящий и восходящий информационный канал. В специальном случае, когда двунаправленный LSP проходит через многоканальное (объединенное) соединение, можно специфицировать нисходящий информационный канал, отличающийся от восходящего канала. Информационные каналы специфицируются с точки зрения отправителя сообщения Path. Объект IF_ID RSVP_HOP не должен использоваться, когда TLV не нужны.

Узел, получающий один или более TLV в сообщении Path, сохраняет их величины и возвращает в объектах HOP последующих сообщений Resv, посылаемых узлу, откуда пришли TLV.

Заметим, что узел, создающий объект IF_ID, должен гарантировать, что выбранный выходной интерфейс, как это определено в объекте IF_ID, согласуется с ERO. Узел, который получает объект IF_ID, должен проверить, является ли информация, содержащаяся в объекте, совместимой с данными, полученными в ERO, и, если это не так, должен послать отправителю сообщение PathErr с кодом ошибки "Routing Error" (ошибка маршрутизации) и значением ошибки "Bad Explicit Route Object" (плохой объект маршрута, заданного явно). Эта проверка не может быть выполнена, когда исходный субобъект ERO не является входным интерфейсом.

Идентификация сбойного интерфейса

Существуют случаи, когда полезно указать интерфейс, ответственный за ошибку. Для решения этой проблемы определен объект IF_ID ERROR_SPEC.

Объекты IF_ID ERROR_SPEC

Формат объекта IPv4 IF_ID ERROR_SPEC имеет вид (рис. 12.70):

Рис. 12.70.

Формат объекта IPv6 IF_ID ERROR_SPEC имеет вид (рис. 12.71):

Рис. 12.71.

Описание адресов, флагов, кодов ошибок и значений поля ошибка можно найти в [RFC-2205]. Описание параметров и кодирования TLV имеется в [RFC-3471].

Узлы, желающие указать, какая ошибка относится к какому интерфейсу, должны использовать соответствующий объект IF_ID ERROR_SPEC в сообщениях PathErr или ResvErr. Объекты IF_ID ERROR_SPEC должны генерироваться и обрабатываться так же, как и другие объекты ERROR_SPEC, смотри [RFC-2205].