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