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