Процедуры
Узел, обрабатывающий сообщение 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.
Обобщенные метки передаются вверх по течению сообщениями Resv. Присутствие объектов обобщенной и нормальной метки в сообщении Resv является протокольной ошибкой и должно обрабатываться получателем, как некорректное сообщение.
Получатель сообщения Resv, содержащего обобщенную метку, проверяет, приемлемость полученных параметров. Если метка неприемлема, тогда получатель должен сформировать сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).
Процедуры, определенные в разделе 2.3.1, работают при коммутации диапазонов длин волн. Если какое-либо поле метки не распознано или имеет неприемлемое значение, генерируется сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).
Кроме того, когда частотный диапазон переключается, может так случиться, что длины волн в пределах диапазона зеркально поменяются местами относительно центра диапазона. Когда применяется такой тип коммутации, начальная и конечная метка диапазона частот в объекте метки должны быть поменяны местами до переадресации метки с новым идентификатором волнового диапазона. Таким образом, выходной/входной LSR, который получит метку частотного диапазона, с инвертированными значениями, будет знать, что он должен инвертировать выходную ассоциацию, чтобы корректно обойтись с частотным диапазоном.
Эта операция должна быть выполнена для обоих направлений, если для диапазона длин волн используется двунаправленный туннель.
Набор меток определяется одним или более объектами 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 с некоторыми дополнениями. Для поддержки двунаправленных 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 (нижестоящая) метки аннулируются, после чего они становятся непригодными для пересылки данных.
Объект запроса уведомления (Notify Request) может быть введен в сообщение Path или Resv, чтобы указать адрес узла, который должен быть уведомлен об отказе LSP. Как было замечено выше, могут посылаться запросы уведомления как вверх, так и вниз по течению. Уведомления, направленные вверх, отмечаются включением объекта запроса уведомления (Notify Request Object) в соответствующее сообщение Path. Уведомления, направленные вниз, отмечаются включением объекта запроса уведомления в соответствующее сообщение Resv. Узел, получающий сообщение, которое содержит объект запроса уведомления, должен запомнить адрес узла уведомления (Notify Node Address) в соответствующем блоке состояний. Если узел является транзитным, он также должен включить объект запроса уведомления в исходящее сообщение Path или Resv. Исходящий адрес узла уведомления может корректироваться на основе местной политики.
Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет генерировано.
Сообщения Notify чаще всего генерируются узлами, которые зарегистрировали ошибку, которая запустила процесс формирования сообщения PathErr или ResvErr. Если нужно сформировать сообщение PathErr и получен объект запроса уведомления в соответствующем сообщении Path, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Если должно быть сформировано сообщение ResvErr и в соответствующем сообщении Resv получен объект запроса уведомления, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Как ранее упоминалось, одна ошибка может вызвать сообщения Notify, направленные вверх и вниз по течению. Заметим, что сообщение Notify не должно генерироваться, если только не получен соответствующий объект запроса уведомления.
Когда генерируются сообщения Notify, узел должен попытаться объединить уведомления, адресованные одному и тому же узлу, и использовать в сообщении Notify одну и ту же общую ERROR_SPEC. Средства, с помощью которых узел определяет, какую информацию можно объединить, зависят от конкретной реализации. Если для этой цели используется таймер, реализация должна позволять пользователю конфигурировать интервал, в течение которого уведомления объединяются. Когда используется таймер, длительность интервала уведомлений по умолчанию равна 1 мсек. Сообщения Notify должны доставляться с использованием механизма надежной доставки, описанного в [RFC2961].
По получении сообщения уведомления узел должен послать соответствующие сообщение Ack.
Субобъект метки следует за субобъектом, содержащим 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".
Субобъекты RRO метки включаются в RRO, как это описано в [RFC3209]. Единственной модификация использования и обработки по сравнению с [RFC3209] заключается в том, что когда метки записываются для двунаправленных LSP, должны быть добавлены субобъекты для обоих направлений.
Транзитные узлы, обрабатывающие сообщение Path, которое содержит объект защиты (Protection Object), должны проверять, можно ли реализовать запрашиваемую защиту в выходном интерфейсе или туннеле (FA). Если это невозможно, узел должен сформировать сообщение PathErr, со значением "Routing problem/Unsupported Link Protection" (проблема маршрутизации/неподдерживаемая защита канала).
Объект 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 не является входным интерфейсом.
Узлы, желающие указать, какая ошибка относится к какому интерфейсу, должны использовать соответствующий объект IF_ID ERROR_SPEC в сообщениях PathErr или ResvErr. Объекты IF_ID ERROR_SPEC должны генерироваться и обрабатываться также, как и другие объекты ERROR_SPEC, смотри [RFC2205].
