2005 г.
1. Введение
Протокол обобщенного MPLS раздвигает его применимость с поддержки
пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации:TDM (Time-Division Multiplex -
мультиплексирование по времени), l-коммутатор (LSC) и
волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов
интерфейсов и коммутации сделано в [RFC3471]. Этот документ рассматривает специфические форматы RSVP-TE и механизмы, необходимые
для поддержки всех четырех классов интерфейсов.
[RFC3471] следует рассматривать как составную часть этого документа. В этом документе определены также возможности RSVP-TE,
для поддержки быстрого уведомления об отказах, смотри разделы 4.2 и 4.3.
2. Форматы, относящиеся к меткам
В этом разделе определены форматы запросов обобщенных меток, обобщенные метки, поддержка коммутации
интервалов длин волн, предлагаемые метки и наборы меток.
2.1. Объект запроса обобщенной метки
Сообщение Path должно содержать специфический тип кодирования LSP (Label Switched Path - путь с коммутацией по меткам),
чтобы гарантировать максимальную гибкость коммутации в транзитных LSR. Объект запроса обобщенной метки устанавливается входным
узлом, передается без изменений транзитными узлами, и используется оконечным узлом. Поле тип коммутации может изменяться от шага к шагу.
Формат объекта запроса обобщенной метки показан ниже:
Описание параметров смотри в [RFC3471].
2.1.1. Процедуры
Узел, обрабатывающий сообщение 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 может содержать набор приемлемых меток, смотри раздел 4.1.
Когда не формируется сообщение об ошибке, происходит нормальная обработка. В случае транзитных узлов это обычно приводит
к передаче сообщения Path. В случае оконечного узла и специального варианта PHP это вызывает генерацию сообщения Resv.
2.2. Кодирование полосы
Кодирование частотного диапазона выполняется в объектах SENDER_TSPEC и FLOWSPEC. Определения значений,
используемых для специальных сигнальных типов, смотри в [RFC3471]. Эти величины устанавливаются
в поле Peak Data Rate (пиковая скорость передачи данных) объектов Int-Serv, смотри [RFC2210].
2.3. Объект обобщенной метки
Ниже представлен формат объекта обобщенной метки:
Описание параметров и кодирования меток смотри в [RFC3471].
2.3.1. Процедуры
Обобщенные метки передаются вверх по течению сообщениями Resv. Присутствие объектов обобщенной и нормальной метки в сообщении
Resv является протокольной ошибкой и должно обрабатываться получателем, как некорректное сообщение.
Получатель сообщения Resv, содержащего обобщенную метку, проверяет, приемлемость полученных параметров. Если метка неприемлема,
тогда получатель должен сформировать сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure"
(проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).
2.4. Объект коммутируемого интервала длин волн
Коммутация частотных диапазонов использует тот же формат, что и обобщенная метка, смотри раздел 2.2. Метка полосы частот использует
C-тип (3),
В контексте коммутации частотных диапазонов, обобщенная метка имеет следующий формат:
Описание параметров смотри в [RFC3471].
2.4.1. Процедуры
Процедуры, определенные в разделе 2.3.1, работают при коммутации диапазонов длин волн. Если какое-либо поле метки
не распознано или имеет неприемлемое значение, генерируется сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка
присвоения обобщенной метки MPLS).
Кроме того, когда частотный диапазон переключается, может так случиться, что длины волн в пределах диапазона зеркально
поменяются местами относительно центра диапазона. Когда применяется такой тип коммутации, начальная и конечная метка диапазона частот в
объекте метки должны быть поменяны местами до переадресации метки с новым идентификатором волнового
диапазона. Таким образом, выходной/входной LSR, который получит метку частотного диапазона, с инвертированными
значениями, будет знать, что он должен инвертировать выходную ассоциацию, чтобы корректно обойтись с частотным диапазоном.
Эта операция должна быть выполнена для обоих направлений, если для диапазона длин волн используется двунаправленный туннель.
2.5. Объект предлагаемой метки
Формат объекта Suggested_Label аналогичен описанному для обобщенной метки. Он используется
в сообщениях Path. Объект Suggested_Label использует номер класса 129 (в форме 10bbbbbb) и C-тип предлагаемой метки.
Ошибки в полученных объектах Suggested_Label должны игнорироваться. Это касается любых полученных несогласованных и неприемлемых
значений.
Согласно [RFC3471], если в нижерасположенный узел приходит метка, которая отличается от предложенной сверху, вышестоящий LSR
должен либо реконфигурироваться, либо отравлять сообщение ResvErr с указанием "Routing problem/Unacceptable label value"
(проблема маршрутизации/неприемлемое значение метки). Кроме того, входной узел не должен передавать данные, используя предложенную метку до тех пор,
пока нижерасположенный узел не пришлет соответствующую метку вверх.
2.6. Объект набора меток
Объект Label_Set использует номер класса 36 (в форме 0bbbbbbb) и C-тип 1. Он используется в сообщениях Path. Label_Set
имеет следующий формат:
Тип метки: 14 бит
Указывает на тип и формат меток, содержащихся в объекте. Значения соответствуют C-типу объекта RSVP_LABEL.
В этом поле используются только младшие 8 бит. Описания других параметров смотри в [RFC3471].
2.6.1. Процедуры
Набор меток определяется одним или более объектами 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. В этом случае использование и передача далее набора
меток существенно сократит вероятность того, что это присвоение потерпит неудачу.
3. Двунаправленные LSP
Установление двунаправленного LSP отмечается наличием вышестоящей
метки (Upstream Label) в сообщении Path. Объект Upstream_Label имеет тот же формат,
что и обобщенная метка, смотри раздел 2.3. Объект Upstream_Label использует номер класса 35 (в форме 0bbbbbbb) и C-тип метки.
3.1. Процедуры
Процесс установления двунаправленного LSP реализуется также как и для однонаправленного
LSP с некоторыми дополнениями. Для поддержки двунаправленных LSP в сообщение Path добавляется объект Upstream_Label.
Объект Upstream_Label должен определять метку, которая пригодна для переадресации в момент отправки сообщения Path.
Когда получено сообщение Path, содержащее объект Upstream_Label, получатель сначала проверяет то, что вышестоящая
метка приемлема. Если метка неприемлема, получатель должен послать сообщение PathErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение
метки). Сформированное сообщение PathErr может содержать набор приемлемых меток, смотри раздел 4.1.
Промежуточный узел должен присвоить метку для исходящего интерфейса
и установить внутренние проходы для данных перед записью исходящей метки и отправкой сообщения Path. Если промежуточный узел не может
присвоить метку или выделить внутренние ресурсы, то он должен послать сообщение PathErr с указанием "Routing problem/MPLS
label allocation failure" (проблема маршрутизации/отказ выделения метки MPLS). Оконечные узлы обрабатывают сообщения Path как
обычно, за исключением того, что вышестоящая метка может быть использована немедленно для передачи трафика данных, ассоциированных с LSP в направлении узла-инициатора.
Когда удаляется двунаправленный LSP, upstream (вышестоящая) и downstream (нижестоящая) метки аннулируются,
после чего они становятся непригодными для пересылки данных.
3.2. Разрешение конфликта
Существует два потенциальных конфликта, которые следует рассматривать при формировании двунаправленного LSP
с поддержкой RSVP-TE. Первый связан с тем, что в RSVP ID узла равно IP-адресу, используемому в объекте RSVP_HOP. Второй связан
с тем, что ID узла соседа может быть неизвестен при посылке исходного сообщения Path. Когда это происходит, узел должен выбрать
метку случайным образом из доступного набора.
4. Уведомление
В этом разделе рассмотрено несколько типов расширений, связанных с уведомлениями. Первое расширение определяет объект набора
приемлемых меток (Acceptable Label Set) для поддержки уведомлений в случае ошибок, связанных с метками и других событий в узлах, ответственных
за восстановление разрушенных LSP. Второе расширение, объект запроса уведомления (Notify Request), определяет ситуацию, при которой
следует посылать уведомление. Третье расширение, сообщение Notify, предоставляет уведомление об общих
событиях. Последнее расширение, относящееся к уведомлениям, позволяет удалять состояние Path при обработке сообщений PathErr.
4.1. Объект набора приемлемых меток
Объекты Acceptable_Label_Set используют номер класса 130 (в форме 10bbbbbb). Остальное содержимое объекта,
включая C-тип, имеет идентичный формат с объектом Label_Set, смотри раздел 2.6.
Объекты Acceptable_Label_Set могут транспортироваться в сообщениях PathErr и ResvErr. Процедуры определения приемлемого
списка меток (Acceptable Label Set) следуют за процедурами определения набора меток (Label Set), смотри раздел 2.6.1. В частности, приемлемый
набор меток определяется из одного или нескольких объектов Acceptable_Label_Set. С помощью объектов действия нуль (0) и один (1), соответственно,
могут быть добавлены или исключены специфические метки/субканалы из перечня приемлемых меток. С помощью объектов действия нуль (2) и один (3),
соответственно, могут быть добавлены или исключены диапазоны меток/субканалов. Когда объекты Acceptable_Label_Set просто перечисляют метки/субканалы,
подлежащие удалению. Это подразумевает, что все остальные метки являются приемлемыми.
Включение объектов Acceptable_Label_Set является опционным. Если он включен, сообщение PathErr или ResvErr должно
содержать указание на "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение
метки). Отсутствие объекта Acceptable_Label_Set не имеет никакого специального значения.
4.2. Объекты запросов уведомления
Уведомления могут посылаться с помощью сообщений Notify, определенных ниже. Объект запроса уведомления используется для
запроса генерации уведомления. Уведомление, т.e., посылка сообщения Notify, может быть запрошено как сверху, так и снизу LSP.
4.2.1. Необходимая информация
Объект запроса уведомления может транспортироваться в сообщениях Path или Resv, смотри раздел 7.
Номер класса Notify_Request равен 195 (в форме 11bbbbbb). Запрос уведомления имеет следующий формат:
o Объект запроса уведомления IPv4
Адрес узла уведомления IPv4: 32 бита
IP-адрес узла, который должен быть уведомлен при генерации сообщения ошибки.
o Объект запроса уведомления IPv6
Адрес узла уведомления IPv6: 16 байт
IP-адрес узла, который должен быть уведомлен при генерации сообщения ошибки.
Если сообщение содержит несколько объектов Notify_Request, только первый объект имеет
значение. Последующие объекты Notify_Request могут игнорироваться и не передаваться далее.
4.2.2. Процедуры
Объект запроса уведомления (Notify Request) может быть введен в сообщение Path или Resv, чтобы указать адрес узла, который должен быть
уведомлен об отказе LSP. Как было замечено выше, могут посылаться запросы уведомления как вверх, так и вниз по
течению. Уведомления, направленные вверх, отмечаются включением объекта запроса уведомления (Notify Request Object) в соответствующее сообщение Path.
Уведомления, направленные вниз, отмечаются включением объекта запроса уведомления в соответствующее сообщение Resv. Узел, получающий сообщение,
которое содержит объект запроса уведомления, должен запомнить адрес узла
уведомления (Notify Node Address) в соответствующем блоке состояний. Если узел является транзитным, он также должен включить объект запроса
уведомления в исходящее сообщение Path или Resv. Исходящий адрес узла уведомления может корректироваться на основе местной политики.
Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет генерировано.
4.3. Сообщение уведомления
Сообщение Notify предоставляет механизм информирования несмежных узлов LSP о событиях. Сообщения Notify обычно генерируются только после
получения объекта запроса уведомления. Сообщение Notify отличается от определенных ранее сообщений об ошибках (т.e., сообщения PathErr и ResvErr) тем, что они могут быть адресованы
узлу, отличному от ближайшего соседа сверху или снизу. Сообщение Notify не заменяет существующие сообщения об ошибках. Сообщение
Notify может быть послано либо (a) в норме, когда транзитные узлы переадресуют
сообщения Notify узлу-адресату, подобно обработке ResvConf в [RFC2205]; или (b) путем инкапсуляции в новый IP заголовок,
чье место назначения соответствует IP-адресу места назначения. Вне зависимости от механизма передачи, узлы, получающие
сообщение Notify, не адресованное им, просто передают его дальше без модификации.
Чтобы обеспечить надежную доставку сообщения Notify, используется сообщение Ack [RFC2961] для подтверждения
получения сообщения. Подробности надежной доставки сообщений RSVP смотри в [RFC2961].
4.3.1. Необходимая информация
Сообщение уведомления Notify является обобщенным сообщением уведомления.
IP-адрес места назначения устанавливается равным адресу запросившего получателя. Сообщение Notify посылается без аварийной опции маршрутизатора.
Одно сообщение Notify может содержать несколько уведомлений.
Сообщение Notify имеет тип сообщения 21. Формат сообщения Notify представлен ниже:
<Notify message> ::= <Common Header> [<INTEGRITY>]
[[<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[<MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
<notify session list> ::= [<notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>
Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, детектировавшего ошибку или отказавшего канала.
Определение ERROR_SPEC смотри в [RFC2205]. MESSAGE_ID и сопряженные с ним объекты определены в [RFC2961].
4.3.2. Процедуры
Сообщения Notify чаще всего генерируются узлами, которые зарегистрировали ошибку,
которая запустила процесс формирования сообщения PathErr или ResvErr. Если нужно сформировать сообщение PathErr и получен объект запроса уведомления в соответствующем сообщении
Path, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Если
должно быть сформировано сообщение ResvErr и в соответствующем сообщении Resv получен
объект запроса уведомления, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Как
ранее упоминалось, одна ошибка может вызвать сообщения Notify, направленные вверх и вниз по течению. Заметим, что
сообщение Notify не должно генерироваться, если только не получен соответствующий объект запроса уведомления.
Когда генерируются сообщения Notify, узел должен попытаться объединить уведомления, адресованные одному и тому же узлу,
и использовать в сообщении Notify одну и ту же общую ERROR_SPEC. Средства, с помощью которых узел определяет,
какую информацию можно объединить, зависят от конкретной реализации. Если для этой цели используется таймер, реализация должна позволять
пользователю конфигурировать интервал, в течение которого уведомления объединяются. Когда
используется таймер, длительность интервала уведомлений по умолчанию равна 1 мсек.
Сообщения Notify должны доставляться с использованием механизма надежной доставки, описанного в [RFC2961].
По получении сообщения уведомления узел должен послать соответствующие сообщение Ack.
4.4. Удаление состояния с помощью сообщения PathErr
Сообщение PathErr, как это определено в [RFC2205], посылается от узла к узлу
отправителю соответствующего сообщения 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. Заметим, что использование этого флага не вызывает каких-либо проблем совместимости.
5. Явное управление по меткам
ERO (Explicit Route Object) метки и субобъекты RRO (Record Route Object) определены для поддержки явного управления метками.
Заметим, что субобъект RRO метки определен в [RFC3209] и расширен для поддержки двунаправленных LSP.
5.1. Субобъект ERO метки
Субобъект ERO метки определен следующим образом:
Описание L, U и параметров метки смотри в [RFC3471].
Тип 3 метки
Длина
Поле длина содержит общую длину субобъекта в байтах, включая поля тип и длина. Длина должна быть кратной 4.
C-тип
C-тип включенного объекта метка. Копируется из объекта метка.
5.1.1. Процедуры
Субобъект метки следует за субобъектом, содержащим IP-адрес, или идентификатор интерфейса [RFC3477],
ассоциированные с каналом, где его планируется использовать. Могут присутствовать до двух субобъектов метки, один
для метки вниз и один для метки вверх по течению. В следующих ситуациях вырабатывается
сигнал ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута):
Если субобъект, содержащий IP-адрес, не предшествует первый субобъект
метки или идентификатор интерфейса [RFC3477], ассоциированные с исходящим каналом.
Для субобъекта метки, следующего за субобъектом с установленным битом 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".
5.2. Субобъект RRO метки
Субобъект RRO метки имеет следующий формат:
Описания параметров U и метки смотри в [RFC3471].
Тип 3 метки
Длина смотри в [RFC3209].
Флаги смотри в [RFC3209].
C-тип C-тип включенного объекта метки. Копируется из объекта метки.
5.2.1. Процедуры
Субобъекты RRO метки включаются в RRO, как это описано в [RFC3209].
Единственной модификация использования и обработки по сравнению с [RFC3209] заключается в том, что когда
метки записываются для двунаправленных LSP, должны быть добавлены субобъекты для обоих направлений.
6. Объект защиты
Использование объекта защиты
является опционным. Объект включается для описания специфических атрибутов
защиты LSP. Объект защиты использует номер класса 37 (в форма 0bbbbbbb). Объект защиты имеет формат:
Описания параметров смотри в [RFC3471].
6.1. Процедуры
Транзитные узлы, обрабатывающие сообщение Path, которое содержит объект защиты (Protection Object), должны проверять,
можно ли реализовать запрашиваемую защиту в выходном интерфейсе или туннеле (FA). Если это невозможно, узел должен сформировать сообщение
PathErr, со значением "Routing problem/Unsupported Link Protection" (проблема маршрутизации/неподдерживаемая защита канала).
7. Административная информация состояний
Административная статусная информация содержится в объекте Admin_Status. Объект предоставляет информацию, относящуюся к
административному состоянию конкретного LSP. Информация используется двумя способами. В первом, объект содержится в сообщениях Path и Resv
для указания административного состояния LSP. Во втором, объект транспортируется в сообщении уведомления для запроса к входному узлу изменить
административное состояние LSP.
7.1. Объект административного статуса
Использование объекта Admin_Status является опционным. Он использует номер класса (Class-Number) 196 (в виде 11bbbbbb).
Формат объекта Admin_Status имеет вид:
Описания параметров смотри в [RFC3471].
7.2. Процедуры для сообщений Path и Resv
Объект Admin_Status используется для уведомления каждого узла вдоль пути о состоянии LSP. Статусная информация
обрабатывается всеми узлами, основываясь на местной политике, и затем передается соответствующими сообщениями. Объект может быть вставлен в
сообщение Path для входного узла или Resv для выходного. Отсутствие объекта эквивалентно получению объекта, со всеми значениями равными нулю.
Транзитные узлы, получая сообщения non-refresh Path или Resv, содержащие объект Admin_Status, обновляют свое локальное состояние,
выполняют какую-то локальную операцию в соответствии со статусом и затем передают полученный объект Admin_Status посредством
исходящего сообщения Path или Resv. Если значения объекта Admin_Status, полученного в сообщении Resv отличаются от значений,
полученных в сообщении Path, тогда, с одним исключением, никаких локальных действий не должно быть предпринято,
но значения должны быть переданы дальше. Единственная ситуация, когда с полученными в Resv значениями следует осуществить
некоторые локальные действия, это случай получения R и D битов равными 1.
Краевые узлы, получающие сообщение non-refresh 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).
7.2.1. Процедура аннулирования
Для некоторых оптических
сетей, полезно установить административный статус LSP, прежде чем его ликвидировать. В таких обстоятельствах
при ликвидации LSP со стороны входа должна выполняться следующая процедура:
Входной узел предваряет
ликвидацию LSP введением объекта административного статуса в сообщение Path и установкой битов R (Reflect) и D (Delete).
Транзитные и выходной узлы обрабатывают объект административного статуса, как это было описано выше.
По получении объекта административного статуса с битом D (Delete) =1 в сообщении Resv, входной узел посылает
сообщение PathTear вниз по течению, чтобы ликвидировать LSP, при выполняется обычная обработка RSVP.
В таких обстоятельствах при ликвидации LSP со стороны выходного узла эта процедура должна предусматривать следующие действия:
Выходной узел индицирует свое желание аннулирования
путем введения объекта своего административного состояния в сообщение Resv и установки битов R (Reflect) и D (Delete).
Транзитные узлы обрабатывают объект административного состояния, как это описано выше.
По получении в сообщении Resv объекта Admin Status
с битом D (Delete) =1, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP.
7.2.2. Совместимость и процедуры обработки ошибок
Возможно, что некоторые узлы вдоль LSP не будут поддерживать объект
административного статуса. В случае не поддерживающего транзитного узла объект
будет передан через узел без модификации и обычная обработка продолжится. В случае
не поддерживающего выходного узла, объект административного состояния не будет
передан назад в сообщении Resv. Чтобы поддержать вариант не поддерживающего выходного узла, входной узел должен
только ждать оговоренное время. Когда период ожидания истек, входной узел
посылает сообщение PathTear. По умолчанию этот период должен равняться 30 секундам.
7.3. Процедуры сообщения уведомления
Промежуточный и оконечный узлы могут запустить процесс установления административного статуса посредством
использования сообщений Notify. Чтобы выполнить это, промежуточный или оконечный узел генерирует сообщение
уведомления (Notify) с соответствующей информацией сессии в направлении вверх по течению. Объект административного состояния должен
включаться в информацию сессии. Бит R (Reflect) не должен быть установлен. Сообщение Notify может быть,
если требуется, инкапсулировано, смотри раздел 4.3.
Входной узел, получив сообщение уведомления, содержащее объект административного состояния с битом D (Delete)
=1, должен инициировать процедуру аннулирования, описанную в предыдущем разделе. Другие биты должны передаваться в исходящем сообщении Path
обычным образом.
7.3.1. Совместимость и процедуры обработки ошибок
Для того чтобы решить проблему в случае узлов, не поддерживающих объект административного состояния,
необходима специальная обработка и другие условия формирования сигнала ошибки. В частности, узел, который посылает сообщение
уведомления, содержащее объект административного состояния с битом D (Down) =1, должен проверять, получил ли он соответствующее
сообщение Path с битом D (Down) =1 за определенный период времени, заданный при конфигурации. По умолчанию этот период
должен равняться 30 секундам. Если узел не получает такого сообщения, он должен послать сообщение PathTear вниз
по течению и сообщение ResvTear или PathErr с флагом Path_State_Removed =1 вверх.
8. Отделение канала управления
В этом разделе описаны протокольные форматы и процедуры для поддержки канала управления, не совмещенного с каналом данных.
8.1. Идентификация интерфейса
Выбор информационного интерфейса всегда осуществляется отправителем сообщения Path путем включения идентификатора
интерфейса информационного канала в сообщение, используя новый подтип объекта RSVP_HOP. Для двунаправленных LSP, отправитель
выбирает интерфейс данных для каждого направления. Во всех случаях кроме объединения
каналов, нижестоящий интерфейс предполагает, что это вышестоящий интерфейс. В случае
объединения, отправитель идентифицирует явно интерфейс, используемый для обоих направлений. Новый объект RSVP_HOP
используется в сообщении Resv, чтобы указать интерфейсы, используемые нижележащими узлами.
8.1.1. Объекты IF_ID RSVP_HOP
Формат объекта IPv4 IF_ID RSVP_HOP:
Формат объекта IPv6 IF_ID RSVP_HOP:
Описания адресов узлов и полей указателя смотри в [RFC2205]. Описания параметров и кодирование TLV содержится в [RFC3471].
8.1.2. Процедуры
Объект IF_ID RSVP_HOP используется вместо определенных выше объектов RSVP_HOP. Он применяется в соединениях, где нет
однозначных ассоциаций между каналами управления и данных, смотри [RFC3471]. Поля Hop Address (адрес шага) и указатель
логического интерфейса используются в соответствии со стандартом RSVP [RFC2205].
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 не является входным интерфейсом.
8.2. Идентификация сбойного интерфейса
Существуют случаи, когда полезно указать интерфейс, ответственный за ошибку. Для решения этой проблемы определен
объект IF_ID ERROR_SPEC.
8.2.1. Объекты IF_ID ERROR_SPEC
Формат объекта IPv4 IF_ID ERROR_SPEC имеет вид:
Формат объекта IPv6 IF_ID ERROR_SPEC имеет вид:
Описание адресов, флагов, кодов ошибок и значений поля ошибка можно найти в [RFC2205]. Описание параметров и кодирования
TLV имеется в [RFC3471].
8.2.2. Процедуры
Узлы, желающие указать, какая ошибка относится к какому интерфейсу, должны использовать соответствующий объект IF_ID ERROR_SPEC в
сообщениях PathErr или ResvErr. Объекты IF_ID ERROR_SPEC должны генерироваться и
обрабатываться также, как и другие объекты ERROR_SPEC, смотри [RFC2205].
9. Обработка отказов
Обработка двух типов отказов в системе управления рассмотрены ниже. Первый, связан с отказами узлов, и относится к случаю,
когда узел теряет свое состояние управления (напр., после повторного старта), но не теряет своего состояния переадресации данных. Второй связан
с отказом в канале управления, и относится к случаю, когда между узлами потеряно управляющее соединение. Обработка обоих отказов поддерживается
объектом Restart_Cap, определенным ниже и требующим использования сообщений Hello. Заметим, что, объект Restart_Cap не должен посылаться,
когда нет механизма разделения отказов каналов данных и управления.
9.1. Объект Restart_Cap
Объект Restart_Cap транспортируется в сообщении Hello. Объект Restart_Cap имеет формат:
Время перезагрузки: 32 бита
Время перезагрузки (повторного старта) измеряется в миллисекундах. Время повторного старта должно быть установлено
равным сумме времени, необходимого отправителю объекта для перезапуска его компонента RSVP-TE (до точки, где он может обмениваться
сообщениями RSVP Hello со своими соседями) и коммуникационного канала, который используется для RSVP коммуникаций. Значение 0xffffffff
указывает, что рестарт управляющей функции отправителя может произойти через неопределенное время и что работа его
информационной части не нарушена отказом в системе управления.
Время восстановления: 32 бит
Период времени, в миллисекундах, спустя которое отправитель хотел бы ресинхронизоваться с получателем состояния переадресации
RSVP и MPLS после восстановления синхронизации Hello. Значение нуль указывает на то, что состояние переадресации
MPLS не было сохранено при перезагрузке системы.
9.2. Обработка объекта Restart_Cap
Узлы, поддерживающие восстановление состояния, анонсируют эту способность, транспортируя объект Restart_Cap в сообщениях Hello.
Такие узлы должны включать объекты Restart_Cap во все сообщения Hello. (Заметим, что это касается сообщений
Hello, содержащих объекты ACK.) Когда узел получает сообщение Hello с объектом Restart_Cap, он должен записать значения полученных параметров.
9.3. Модификация обработки сообщения Hello для поддержки восстановления состояния
Когда узел определяет, что RSVP связь с соседом потеряна, а узел по прошлому знает, что сосед поддерживает восстановление состояния,
он должен подождать, по крайней мере, некоторое время, указанное в параметре Restart Time (время повторного запуска) соседа, прежде чем включать
процедуры, сопряженные с потерей соединения. Узел может ждать разное время в зависимости от местной политики или конфигурации.
Во время этого периода ожидания, все
сообщения Hello должны посылаться со значением Dst_Instance равным нулю, а Src_Instance должен оставаться неизменным. Во время
ожидания узел должен также сохранять состояние переадресации RSVP и MPLS для уже установленного LSP, который проходит между данным узлом и соседом. В известном
смысле с точки зрения сформированного LSP узел ведет себя так, как если бы он получал периодически от соседа сообщения
обновления RSVP. Узел может сбросить состояния RSVP и переадресации для LSP, которые находятся в процессе
установления, в случае таймаута их обновления. Обновление состояний Resv и Path на период ожидания должно быть подавлено.
Во время этого периода ожидания, узел может проинформировать вышестоящие
узлы о потере связности посредством сообщения PathErr и/или сообщения уведомления с указанием "Control
Channel Degraded State" (канал управления не работает). Если такое уведомление
послано, тогда по восстановлении канала управления узел должен информировать
другие узлы о восстановлении посредством сообщений PathErr и/или уведомления Notify с
индикацией "Control Channel Active State" (управляющий канал в активном состоянии).
Когда от соседа приходит новое сообщение Hello, узел должен определить, произошел ли отказ в канале управления или
это выход из строя узла. Этот анализ основывается на полученном от соседа Src_Instance. Если значение отличается от полученного
от соседа до отказа, тогда соседа следует считать рестартующим. В противном случае, отказ ограничен каналом управления.
Процедуры обработки для каждого из случаев описаны ниже.
9.4. Отказы канала управления
В случае отказа канала управления узел должен обновить все состояния, которые являются общими с соседом.
Следует использовать совокупность процедур восстановления [RFC2961] с флагом ACK_Desired =1 (если они поддерживаются).
9.5. Отказы узлов
Восстановление при отказе узла использует один новый объект и другие существующие протокольные сообщения и объекты.
9.5.1. Метка восстановления
Объект Recovery_Label используется в процессе восстановления узла после отказа.
Формат объекта Recovery_Label идентичен формату обобщенной метки. Объект Recovery_Label использует номер класса 34 (в форме 0bbbbbbb) и C-тип
предлагаемой метки.
9.5.2. Процедуры для перезапускаемого узла
После того как узел перезапускает свои функции управления, узел, который поддерживает состояние восстановления, должен
проверить, способен ли он сохранить свое состояние переадресации MPLS. Если никакого состояния переадресации
не сохранено, тогда в сообщении Hello, посланном своим соседям, узел должен установить время восстановления равным 0.
Если состояние переадресации сохранено, тогда узел инициирует процесс восстановления. Период, в течение которого узел поддерживает
процесс восстановления, называется периодом восстановления (Recovery Period). Полная длительность периода восстановления анонсируется
восстанавливающимся узлом в параметре Recovery Time (время восстановления) объекта Restart_Cap. Время восстановления должно быть установлено
равным длительности периода восстановления во всех сообщениях Hello, посланных за время периода
восстановления. Состояние, которое не синхронизовано в период восстановления, должно быть удалено в конце этого периода.
Заметим, что если во время Hello-синхронизации рестартующий узел определит, что сосед не поддерживает состояние восстановления,
а перезапускаемый узел поддерживает свое состояние переадресации MPLS на основе контактов с соседями, данный узел должен
немедленно считать период восстановления со своим соседом завершенным. Состояние
переадресации может рассматриваться как базирующееся на кооперации с соседями,
когда используются метки, сопряженные с интерфейсами при соединениях точка-точка.
Когда узел получает сообщение Path за время периода восстановления, узел
сначала проверяет, имеется ли состояние RSVP, ассоциированное с сообщением. Если состояние найдено,
тогда узел обрабатывает это сообщение согласно определенным ранее процедурам.
Если состояние RSVP не найдено, и сообщение не содержит в себе объект Recovery_Label, узел рассматривает это, как сигнал к установлению
нового LSP, и обрабатывает его согласно определенным ранее процедурам.
Если состояние RSVP не найдено, а сообщение несет в себе объект Recovery_Label, узел ищет в его маршрутной таблице MPLS
(которая восстановлена при перезапуске) рекорд, чей входной интерфейс согласуется с сообщением Path, и чья входная метка равна метке, содержащейся в
объекте Recovery_Label.
Если запись таблицы переадресации MPLS не найдена, узел рассматривает это,
как сигнал к установлению нового LSP, и обрабатывает его согласно определенным ранее процедурам.
Если рекорд маршрутной таблицы MPLS найден, формируется состояние RSVP, рекорд связывается с LSP, ассоциированным с сообщением, а
состояние переадресации обрабатывается как корректное и обновленное. Должна быть
произведена также обработка обычного сообщения Path. При отправке соответствующего исходящего
сообщения Path узел должен включить в него объект Suggested_Label со значением метки, согласованным с рекордом восстановленной
таблицы маршрутизации. Выходной интерфейс должен выбираться также с учетом
рекорда маршрутной таблицы. В особом случае, где перезапускаемый узел имеет также
перезапускаемого нижерасположенного соседа, вместо объекта Suggested_Label следует использовать объект Recovery_Label.
Кроме того, для двунаправленных LSP, узел извлекает метку из объекта UPSTREAM_LABEL, содержащегося в полученном сообщении Path, и просматривает таблицу маршрутизации
MPLS на предмет рекорда, чья выходная метка равна метке, содержащейся в объекте (в случае многоканальности связи, это
может также включать идентификацию соответствующего входного компонента соединения).
Если рекорд таблицы маршрутизации MPLS не найден, узел рассматривает это,
как сигнал к установлению нового LSP, и обрабатывает его согласно определенным ранее процедурам.
Если рекорд таблицы маршрутизации MPLS найден, рекорд связывается с LSP, ассоциированным с сообщением Path, и рекорд рассматривается как
ресинхронизированный. Кроме того, если узел не является окончанием LSP, посылаются соответствующие сообщения
Path с входной меткой, которая содержится в объекте UPSTREAM_LABEL рекорда.
Во время восстановления сообщения Resv обрабатываются обычным образом с двумя исключениями. В случае, когда рекорд таблицы
маршрутизации восстановлен, при обработке сообщения Resv не требуется никакой новой метки или выделения ресурсов. Вторым исключением является
то, что не нужно генерировать сообщения ResvErr, когда получено сообщение Resv с несогласованным состоянием Path. В этом случае сообщение Resv
должно молча отбрасываться.
9.5.3. Процедуры для соседа перезапускаемого узла
Ниже специфицированы процедуры, которые используются, когда узел восстанавливает
коммуникации с системой управления соседа в пределах периода рестарта (Restart Time). Узел определяет (используя процедуры,
определенные в разделе 5 [RFC3209]), какую систему управления соседа следует перезапустить, и сохранил ли сосед состояние
переадресации при перезапуске. Заметим, что значение времени перезапуска 0xffffffff означает бесконечный временной интервал.
После детектирования рестарта соседа, который поддерживает восстановление состояния, узел должен обновить
все состояния Path, используемые совместно с соседом. Исходящие сообщения Path должны включать объект Recovery_Label,
содержащий значение метки, соответствующее метке, полученной в последнем сообщении Resv. Все состояния Path должны быть
обновлены в пределах примерно 1/2 от времени восстановления, объявленного рестартующим соседом. Если имеется несколько
LSP проходящих через рестартующий узел, соседний узел должен избегать посылки сообщений Path в пределах ограниченного временного интервала, чтобы не
перегружать ЦПУ соседа. Вместо этого, ему следует распределить сообщения в пределах
1/2 времени восстановления. После детектирования рестарта соседа, который поддерживает
восстановление состояния, все состояния Resv используемые совместно с рестартующим узлом не должны
обновляться до тех пор, пока не будет получено соответствующее сообщение Path. Это требует подавления обычной обработки
Resv и обновлений на время восстановления, объявленного рестартующим соседом. Как только приходит соответствующее сообщение
Path, должно быть послано сообщение Resv и разрешена обычная обработка состояния.
10. Обработка и форматы сообщения RSVP
10.1. Форматы сообщений RSVP
В этом разделе описаны форматы сообщений
RSVP. Там где они отличаются, форматы для однонаправленных LSP представлены отдельно от
двунаправленных LSP. MESSAGE_ID и сопряженные объекты определены в [RFC2961]. Формат сообщения Path представлен ниже:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION><RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE>]
<LABEL_REQUEST>
[ <PROTECTION>]
[ <LABEL_SET>... ]
[ <SESSION_ATTRIBUTE>]
[ <NOTIFY_REQUEST>]
[ <ADMIN_STATUS>]
[ <POLICY_DATA>... ]
<sender descriptor>
Формат дескриптора отправителя для однонаправленного LSP имеет вид:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC>]
[ <RECORD_ROUTE>]
[ <SUGGESTED_LABEL>]
[ <RECOVERY_LABEL> ]
Формат дескриптора отправителя для двунаправленного LSP имеет вид:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC>]
[ <RECORD_ROUTE>]
[ <SUGGESTED_LABEL>]
[ <RECOVERY_LABEL>]
<UPSTREAM_LABEL>
Формат сообщения PathErr имеет вид:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK>| <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID>]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET>... ]
[ <POLICY_DATA>... ]
<sender descriptor>
Формат сообщения Resv имеет вид:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK>| <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID>]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM>] [ <SCOPE> ]
[ <NOTIFY_REQUEST>]
[ <ADMIN_STATUS>]
[ <POLICY_DATA>... ]
<STYLE> <flow descriptor list>
<flow descriptor list> в данном документе не модифицировался.
Формат сообщения ResvErr имеет вид:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[[<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[<MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[<ACCEPTABLE_LABEL_SET> ... ]
[<POLICY_DATA> ... ]
<STYLE><error flow descriptor>
Формат модифицированного сообщения Hello имеет вид:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[<RESTART_CAP> ]
10.2. Сообщения Addressing Path, PathTear и ResvConf
RSVP сконструирован, чтобы работать с динамическими
изменениями маршрута и с узлами не поддерживающими RSVP. С этой целью сообщения Path, PathTear и ResvConf несут в себе адрес места назначения сессии
в IP-заголовке. Узлы, которые не могут присваивать метки, не могут существовать в LSP. Другим отличием от традиционного RSVP является то, что временами,
сообщение RSVP может транспортироваться за пределами информационного канала LSP.
11. Соображения безопасности
Безопасность сообщения RSVP описана в [RFC2747] и обеспечивает целостность сообщения и
аутентификацию узла. Для сообщений, передаваемых шаг-за-шагом, в данном документе не предлагается новых возможностей.
В данном документе вводится возможность посылки сообщения уведомления (Notify)
вне схемы шаг-за-шагом. Это мешает реализовать модель целостности и аутентификации RSVP. В случае, когда RSVP генерирует сообщения из-конца-в-конец
и желательна безопасность, предоставляемая [RFC2747], можно использовать стандарт IPSEC. При использовании IPSEC для обеспечения аутентификации
сообщений применяется следующее:
Селекторы
Селектор идентифицирован RSVP сообщениями, которыми обмениваются узлы, не являющиеся смежными.
Узлы идентифицируются IP-адресами отправителя и получателя, используемыми в сообщениях Notify.
Режим
Передаваемая информация, как правило, не является конфиденциальной, поэтому шифрование необязательно. Можно использовать AH
[RFC2402] или ESP [RFC2406]. Если используется ESP, IP-адрес отправителя должен быть сравнен с адресом, используемым при управлении ключевым обменом.
Управление ключами
Чтобы разрешить детектирование откликов, должна использоваться автоматическая система управления ключами, такая как
IKE [RFC2409]. Могут использоваться конфигурируемые ключи.
Политика безопасности
Сообщения не должны восприниматься, если они посланы неизвестными узлами.
Идентификация
Механизмы общих ключей должны быть адекватны исходным
установкам для небольших сетей. Для крупномасштабных систем следует применять IKE, базирующуюся на сертификатах. Какая
бы система не использовалась, она должна каким-то образом быть привязана к IP-адресу отправителя.
Доступность
Многие маршрутизаторы и переключатели поддерживают IPSEC. Для случаев, когда IPSEC недоступна, а безопасность
необходима, следует посылать сообщения Notify по схеме шаг-за-шагом.
12. Соображения IANA
IANA присваивает значения протокольным параметрам RSVP. В пределах данного документа определено несколько объектов.
Каждый из этих объектов содержит C-тип. В этом разделе определены правила присвоения значений C-типа. В этом разделе используется
терминология BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
Согласно [RFC2205], C-тип представляет собой 8-битовое число, которое идентифицирует функцию объекта. Приемлемы
все возможные величины за исключением нуля.
Присвоение значений C-типа объектам, определенное в данном
документе, делится на три категории. Первая категория наследует C-типы из объекта метки, т.e., номер класса объекта 16 [RFC3209].
Задача IANA ввести политику, в соответствии с которой все значения C-типа, присвоенные объектам метка, присвоены также следующим объектам:
Suggested_Label (Class-Num 129)
Upstream_Label (Class-Num 35)
Recovery_Label (Class-Num 34)
Вторая категория объектов следует
независимой политике. В частности, следующие виды политики рассмотрены в [BCP26], значения C-типа в диапазоне 0x00 - 0x3F выделяются по согласованию с IETF, значения из диапазона 00x40 - 0x5F выделяются по принципу “первым пришел
- первым обслужен”, а значения из диапазона 0x60 - 0x7F зарезервированы для частного использования. Эта политика
применима к следующим объектам.
Label_Set (Class-Num 36)
Notify_Request (Class-Num 195)
Protection (Class-Num 37)
Admin Status (Class-Num 196)
Restart_Cap (Class-Num 131)
Присвоение значений C-типа для остающегося объекта Acceptable_Label_Set,
следует правилам присвоения значений C-типа объекта Label_Set. IANA устанавливает политику, в соответствии с которой все значения
C-типа, присвоенные для объекта Label_Set, присвоены также и для объекта Acceptable_Label_Set.
12.1. Регламентации IANA
В этом разделе представлены значения, используемые в данном документе и регламентированные IANA.
---------------------------------------------------------------------
Типы сообщений
o Сообщение уведомления (Тип сообщения = 21)
---------------------------------------------------------------------
Класс типов
o RSVP_HOP (C-Num 3)
- IPv4 IF_ID RSVP_HOP (C-тип = 3)
- IPv6 IF_ID RSVP_HOP (C-тип = 4)
o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (C-тип = 3)
- IPv6 IF_ID ERROR_SPEC (C-тип = 4)
o LABEL_REQUEST (Class-Num 19) - Generalized_Label_Request (C-тип = 4)
o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (C-тип = 2)
- Waveband_Switching_Label C-тип (C-тип = 3)
---------------------------------------------------------------------
Новые Class-Nums, C-типы, наследованные от объекта метка (тоже что и CNum16)
o RECOVERY_LABEL Class-Num в форме 0bbbbbbb (= 34)
o SUGGESTED_LABEL Class-Num в форме 10bbbbbb (= 129)
o UPSTREAM_LABEL Class-Num в форме 0bbbbbbb (= 35)
---------------------------------------------------------------------
Новые Class-Num
o LABEL_SET Class-Num в форме 0bbbbbbb (= 36)
- Тип 1 (C-тип = 1)
o ACCEPTABLE_LABEL_SET Class-Num в форме 10bbbbbb (= 130)
- Тип 1 Acceptable_Label_Set (C-тип из label_set cnum)
o NOTIFY_REQUEST Class-Num в форме 11bbbbbb (= 195)
- Запрос уведомления IPv4 (C-тип = 1)
- Запрос уведомления IPv6 (C-тип = 2)
o PROTECTION Class-Num в форме 0bbbbbbb (= 37)
- Тип 1 (C-тип = 1)
o ADMIN STATUS Class-Num в форме 11bbbbbb (= 196)
- Тип 1 (C-тип = 1)
o RESTART_CAP Class-Num в форме 10bbbbbb (= 131)
- Тип 1 (C-тип = 1)
---------------------------------------------------------------------
ERO/RRO типы субобъектов
o Субобъект ERO метки Тип 3 - метка
o Субобъект RRO метки Тип 3 - метка
---------------------------------------------------------------------
Коды ошибок
o "Routing problem/Label Set" (значение = 11)
o "Routing problem/Switching Type" (значение = 12) (duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (значение = 14)
o "Routing problem/Unsupported Link Protection" (значение = 15)
o "Notify Error/Control Channel Active State" (значение = 4)
o "Notify Error/Control Channel Degraded State" (значение = 5)
---------------------------------------------------------------------
13. Ссылки
13.1. Нормативные ссылки
[RFC2119] | Bradner,
S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC2205] | Braden,
R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation
Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. |
[RFC2210] | Wroclawski,
J., "The Use of RSVP with IETF Integrated Services", RFC 2210,
September 1997. |
[RFC2402] | Kent,
S. and R. Atkinson, "IP Authentication Header", RFC 2401, November 1998. |
[RFC2406] | Kent,
S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2401, November 1998. |
[RFC2409] | Harkins,
D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. |
[RFC2747] | Baker,
F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication",RFC 2747, January 2000. |
[RFC2961] | Berger,
L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP
Refresh Overhead Reduction Extensions", RFC 2961, April 2001. |
[RFC3209] | Awduche,
D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. |
[RFC3471] | Berger,
L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description", RFC 3471, January 2003. |
[RFC3477] | Kompella,
K. and Y. Rekhter, "Signalling Unnumbered Links in Resource Reservation
Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. |
13.2. Информационные ссылки
[BCP26] | Narten,
T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 2434, October 1998. |
[MPLS-HIERARCHY] | Kompella,
K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress. |
[PAN-RESTART] | Pan,
P., et. al., "Graceful Restart Mechanism for RSVP-TE", Work in Progress. |
[RFC2026] | Bradner,
S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
