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

Обработка отказов

Обработка двух типов отказов в системе управления рассмотрены ниже. Первый связан с отказами узлов, и относится к случаю, когда узел теряет свое состояние управления (например, после повторного старта), но не теряет своего состояния переадресации данных. Второй связан с отказом в канале управления и относится к случаю, когда между узлами потеряно управляющее соединение. Обработка обоих отказов поддерживается объектом Restart_Cap, определенным ниже и требующим использования сообщений Hello. Заметим, что, объект Restart_Cap не должен посылаться, когда нет механизма разделения отказов каналов данных и управления.

Объект Restart_Cap

Объект Restart_Cap транспортируется в сообщении Hello. Объект Restart_Cap имеет формат (рис. 12.72):

Рис. 12.72.

Время перезагрузки: 32 бита

Время перезагрузки (повторного старта) измеряется в миллисекундах. Оно должно быть установлено равным сумме времени, необходимого отправителю объекта для перезапуска его компонента RSVP-TE (до точки, где он может обмениваться сообщениями RSVP Hello со своими соседями) и коммуникационного канала, который используется для RSVP коммуникаций. Значение 0xffffffff указывает, что рестарт управляющей функции отправителя может произойти через неопределенное время и что работа его информационной части не нарушена отказом в системе управления.

Время восстановления: 32 бит

Период времени, в миллисекундах, спустя которое отправитель хотел бы заново синхронизовать с получателем состояния переадресации RSVP и MPLS после восстановления синхронизации Hello. Значение нуль указывает на то, что состояние переадресации MPLS не было сохранено при перезагрузке системы.

Обработка объекта Restart_Cap

Узлы, поддерживающие восстановление состояния, анонсируют эту способность, транспортируя объект Restart_Cap в сообщениях Hello. Такие узлы должны включать объекты Restart_Cap во все сообщения Hello. (Заметим, что это касается сообщений Hello, содержащих объекты ACK.) Когда узел получает сообщение Hello с объектом Restart_Cap, он должен записать значения полученных параметров.

Модификация обработки сообщения 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. Если значение отличается от полученного от соседа до отказа, тогда соседа следует считать рестартующим. В противном случае, отказ ограничен каналом управления. Процедуры обработки для каждого из случаев описаны ниже.

Отказы канала управления

В случае отказа канала управления узел должен обновить все состояния, которые являются общими с соседом. Следует применять совокупность процедур восстановления [RFC-2961] с флагом ACK_Desired =1 (если они поддерживаются).

Отказы узлов

Восстановление при отказе узла использует один новый объект и другие существующие протокольные сообщения и объекты.

Метка восстановления

Объект Recovery_Label задействуется в процессе восстановления узла после отказа. Формат объекта Recovery_Label идентичен формату обобщенной метки. Объект Recovery_Label использует номер класса 34 (в форме 0bbbbbbb ) и C-тип предлагаемой метки.

Процедуры для перезапускаемого узла

После того как узел перезапускает свои функции управления, узел, который поддерживает состояние восстановления, должен проверить, способен ли он сохранить свое состояние переадресации 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 должно молча отбрасываться.

Процедуры для соседа перезапускаемого узла

Узел определяет (используя процедуры, определенные в [RFC-3209]), какую систему управления соседа следует перезапустить и сохранил ли сосед состояние переадресации при перезапуске. Заметим, что значение времени перезапуска 0xffffffff означает бесконечный временной интервал.

После детектирования рестарта соседа, который поддерживает восстановление состояния, узел должен обновить все состояния Path, используемые совместно с соседом. Исходящие сообщения Path должны включать объект Recovery_Label, содержащий значение метки, которое соответствует метке, полученной в последнем сообщении Resv. Все состояния Path должны быть обновлены в пределах примерно 1/2 от времени восстановления, объявленного рестартующим соседом. Если имеется несколько LSP, проходящих через рестартующий узел, соседний узел должен избегать посылки сообщений Path в пределах ограниченного временного интервала, чтобы не перегружать ЦПУ соседа. Вместо этого ему следует распределить сообщения в пределах 1/2 времени восстановления. После детектирования рестарта соседа, который поддерживает восстановление состояния, все состояния Resv, используемые совместно с рестартующим узлом, не должны обновляться до тех пор, пока не будет получено соответствующее сообщение Path. Это требует подавления обычной обра ботки Resv и обновлений на время восстановления, объявленного рестартующим соседом. Как только приходит соответствующее сообщение Path, должно быть послано сообщение Resv и разрешена обычная обработка состояния.

RSVP сконструирован так, чтобы работать с динамическими изменениями маршрута и с узлами, не поддерживающими RSVP. С этой целью сообщения Path, PathTear и ResvConf несут в себе адрес места назначения сессии в IP-заголовке. Узлы, которые не могут присваивать метки, не могут существовать в LSP. Другим отличием от традиционного RSVP является то, что временами сообщение RSVP может транспортироваться за пределами информационного канала LSP.