Internet Engineering Task Force (IETF) K. Ogawa
Request for Comments: 7121 NTT Corporation
Updates: 5810 W. Wang
Category: Standards Track Zhejiang Gongshang University
ISSN: 2070-1721 E. Haleplidis
University of Patras
J. Hadi Salim
Mojatatu Networks
February 2014
High Availability within a Forwarding and Control Element Separation (ForCES) Network Element
Высокий уровень доступности в элементах сети ForCES
Аннотация
Этот документ описывает элемент управления с высокой доступностью (CE1 HA2) внутри элемента сети ForCES3 NE4. Кроме того, этот документ обновляет RFC 5810, предоставляя новое описание механизма Cold Standby High Availability5.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF6 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG7. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7121.
Авторские права
Авторские права (Copyright (c) 2014) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
На рисунке 1 показан элемент сети ForCES NE, управляемый избыточным множеством CE, где CE1 является основным, в CE2 и CEn – резервными.
Элемент сети ForCES
+-------------------------------------+
| +---------------------+ |
| |Управляющ. приложение| |
| +--+--------------+---+ |
| | | +------+|
| | | | CEn ||
| | | |(рез.)||
-------------- Fc | -----------+--+ +----+-------+||
| Менеджер CE|---------+-| CE1 |------| CE2 |+|
-------------- | | (активный) | Fr | (резервный)| |
| | +-+---------+-+ +-------+----+ |
| Fl | | | Fp / | |
| | | +--------+ / | |
| | | Fp |/ | |
| | | | | |
| | | Fp /|----+ | |
| | | /--------/ | | |
-------------- Ff | ---+---------- ---------+---- |
| Менеджер FE|---------+-| FE1 | Fi | FE2 | |
-------------- | | |------| | |
| -------------- -------------- |
| | | | | | | | | |
----+--+--+--+----------+--+--+--+-----
| | | | | | | |
| | | | | | | |
Fi/f Fi/f
Fp: интерфейс CE-FE
Fi: интерфейс FE-FE
Fr: интерфейс CE-CE
Fc: интерфейс между CE и менеджером CE
Ff: интерфейс между FE и менеджером FE
Fl: интерфейс между менеджерами CE и FE
Fi/f: внешний интерфейс FE
Рисунок 1. Архитектура ForCES.
Архитектура ForCES позволяет элементам FE знать о множестве CE, но выбирать среди них один в качестве первичного контроллера. Это называется резервированием 1+N. Первичный элемент CE управляет элементами FE по протоколу ForCES, работающему на интерфейсе Fp. При отказе основного CE, т. е. неполадках в работе или потере связности управление операциями NE принимает на себя резервный CE. Такой режим называют «холодным» резервированием (cold standby). Набор CE, управляющих FE является статическим и передается элементу FE менеджером FE (FEM8) через интерфейс Ff и каждому CE менеджером CE (CEM9) на интерфейсе Fc в фазе до создания ассоциации (pre-association phase).
С точки зрения FE рабочие параметры для установки CE определены как компоненты в FEPO LFB [RFC5810], Приложение B. В параграфе 2.1 этого документа детали параметров рассматриваются дополнительно.
Предполагается, что читатель знаком с архитектурой ForCES для понимания изменений, описываемых в этом документе. Здесь представлена базовая информация для организации контекста обсуждения в разделе 3.
На момент написания этого документа интерфейс Fr не входил в сферу действия архитектуры ForCES. Однако предполагается, что организациям, разворачивающим набор CE потребуется организовать взаимодействие между этими CE через интерфейсы Fr для синхронизации, требуемой при управлении элементами FE.
Проблему, решаемую в этом документе, можно разделить на две части:
-
обновление описания [RFC5810] с разъяснением работы текущего режима «холодного» резервирования в кластере NE;
-
описание развития «холодного» резервирования [RFC5810] для снижения времени восстановления и улучшения доступности NE.
1.1. Определение круга задач
Доступность и восстановление NE зависят от нескольких временных параметров:
-
время обнаружения отказа на уровне CE элементом FE;
-
время перехода резервного CE в рабочее состояние;
-
время организации элементами FE связей с новым основным CE;
-
время восстановления состояния и работоспособности элементов FE (каждое состояние FE является набором состояний всех экземпляров LFB в нем).
Целью [RFC5810] и данного документа является решение перечисленных выше задач с минимальными сложностями.
Для количественного выражения перечисленных выше параметров предписанной в [RFC5810] установки ForCES CE нужно выполнить ряд оценок.
-
Время обнаружения FE отказа CE остается неопределенным. Для рассмотрения крайнего случая представим оператора, обеспечивающего мониторинг с целью обнаружения отказов CE. Время обнаружения в таком случае может занимать от секунд до дней. Более активный монитор на интерфейсе Fp сможет ускорить обнаружение отказа. Обычно FE будет детектировать отказы CE с помощью транспортного отображения (TML10), если оно завершается на интерфейсе Fp или с помощью механизма ForCES Heartbeat.
-
Время перехода в рабочее состояние резервного CE в настоящее время просто не рассматривается. В текущей модели от резервного CE работоспособность не требуется совсем (например, в целях экономии энергии он может быть выключен), поэтому контролирующий элемент может загружать резервный CE уже после отказа основного CE. В разделе 3 предлагается держать включенным по меньшей мере один резервный CE для ускорения процесса.
-
Время организации FE связи с новым основным CE в настоящее время не определено. Время на подключение FE и создание ассоциации увеличивает время восстановления. Как отмечено выше, предлагается иметь по меньшей мере один резервный CE подключенным. В разделе 3 предлагается исключить время на соединение FE и создание ассоциации из времени восстановления, за счет связывания FE со всеми включенными резервными CE после организации связи с активным/основным CE. Отметим, что организация FE предварительной ассоциации хотя бы с одним резервным CE переводит систему в режим «горячего» резервирования.
-
Время восстановления состояния FE зависит времени существования состояния NE. Согласно текущему определению ForCES, новый основной элемент CE предполагает нулевое (пустое) состояние FE и начинает обновлять FE с нуля. Поэтому время восстановления растет с увеличением размера состояния.
1.2. Определения
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
Приведенные ниже определения заимствованы из [RFC3654], [RFC3746] и [RFC5810]. Они повторены для удобства, а нормативными являются определения в указанных RFC.
LFB (Logical Function Block) – логический функциональный блок
Шаблон, представляющий четко обозначенные, логически разделенные аспекты обработки FE.
Forwarding Element (FE) – элемент пересылки
Логический элемент, реализующий протокол ForCES. Элементы FE используют базовое оборудование для обработки каждого пакета и управляются (контролируются) CE по протоколу ForCES.
Control Element (CE) – элемент управления
Логический объект, который реализует протокол ForCES и инструктирует один или множество FE по части обработки пакетов. Функциональность CE включает исполнение протоколов управления и сигнализации.
ForCES Network Element (NE) – элемент сети ForCES
Объект, состоящий из одного или множества CE и одного или множества FE. Для внешних наблюдателей NE представляется единой точкой управления и скрывает свою внутреннюю структуру от внешних наблюдателей.
FE Manager (FEM) – менеджер FE
Логический элемент, которые работает в фазе до объединения и отвечает за определение CE, с которыми элементу FE следует взаимодействовать. Этот процесс называется обнаружением CE и может включать определение менеджером FE возможностей доступных CE.
CE Manager (CEM) – менеджер элементов управления
Логический объект, который работает на этапе до объединения (pre-association phase) для определения FE, с которым CE следует взаимодействовать. Этот процесс называется обнаружением FE и может включать определение менеджером CE возможностей доступных FE.
ForCES Protocol – протокол ForCES
Протокол, применяемый для взаимодействия между CE и FE. Этот протокол не применяется для взаимодействия между элементами CE, взаимодействия между элементами FE или менеджерами FE и CE. Протокол ForCES работает в режиме «ведущий-ведомый» (master-slave) где FE являются ведомыми, а CE – ведущими. Этот протокол включает управление коммуникационным каналом (например, организацию соединения, обмен heartbeat) и сами управляющие сообщения.
ForCES Protocol Layer (ForCES PL) – уровень протокола ForCES
Уровень архитектуры протокола ForCES, который определяет протокольные сообщения ForCES, схему передачи состояний протокола и архитектуру самого протокола ForCES (включая требования ForCES TML, как показано ниже). Спецификация ForCES PL также задана в этом документе. Спецификация ForCES PL задана в [RFC5810].
ForCES Protocol Transport Mapping Layer (ForCES TML) – уровень транспортного отображения ForCES
Уровень архитектуры протокола ForCES, которые использует возможности существующих транспортных протоколов для решения задач доставки протокольных сообщений, таких как отображения этих сообщений на различные транспортные среды (SCTP11, IP, TCP, UDP, ATM, Ethernet и пр.), обеспечения гарантий доставки, групповой адресации, сохранения порядка и т. п. Спецификации ForCES TML задаются в отдельных документах ForCES для каждого типа TML.
2. Схема RFC 5810 для CE HA
Для обеспечения CE HA12 элементы FE и CE должны взаимодействовать в соответствии с определением [RFC5810], которое повторено в параграфе 2.1. Следует отметить, что принятая по умолчанию установка, которая должна быть реализована в CE и FE, которым требуется HA, на уровне Fr выходит за рамки документа (и при ее доступности является «фирменной» для реализации).
2.1. Поддержка RFC 5810 CE HA
Как отмечено выше, несмотря на возможность подключения множества избыточных CE, лишь один элемент CE активно управляет FE в рамках ForCES NE. На практике резервный элемент CE может быть единственным. В любой момент лишь один элемент CE может управлять FE. Кроме того, FE подключается и связывается лишь с одним ведущим CE. FE и CE знают об основном и одном или нескольких резервных CE. Эта информация (основной и резервные CE) настраивается в FE и CE перед созданием ассоциации (pre-association) менеджерами FEM и CEM, соответственно.
В этом параграфе дано новое нормативное описание механизма «холодного» резервирования (Cold Standby High Availability), которое обновляет описание в [RFC5810].
На рисунке 2 показана последовательность сообщений ForCES, которые FE использует для восстановления соединения в соответствии с текущей схемой «холодного» резервирования.
FE Основной CE Резервный CE | | | | Создание ассоциации | | | Обмен возможностями | | 1 |<------------------------->| | | | | | Обновление состояния | | 2 |<------------------------->| | | | | | | | | Отказ | | | | Создание ассоциации, обмен возможностями | 3 |<----------------------------------------------->| | | | Уведомление о событии (отказ основного CE) | 4 |------------------------------------------------>| | | | Обновление состояния | 5 |<----------------------------------------------->|
Рисунок 2. «Холодное» резервирование CE
2.1.1. Взаимодействие «холодного» резервирования с протоколом ForCES
Параметризация HA в FE управляется конфигурацией FE Protocol Object (FEPO) LFB.
FE пытается организовать связь
+-->-----+
| |
(Смена основного CE|| | |
CE выдает Teardown || +---+--------v----+
потеря ассоциации) && | Pre-association |
CE failover policy = 0 | (ассоциация |
+------------>-->-->| в процессе +<----+
| | создания) | |
| | | |
| +--------+--------+ |
| Отклик | | Отсчет
| CE Association V | таймера
| +------------------+ | CEFTI
| |FE выдает CEPrimaryDown ^ завершен
| V |
+-+-----------+ +------+-----+
| | (Смена основного CE || | Нет |
| | CE выдает Teardown || | ассоциации |
| | потеря ассоциации) && | +->---+
| Ассоциация | CE failover policy = 1 |(Можно | FE |
| | | продолжать |повт.v
| |-------->------->------>| пересылку) |попыт|
| | Запуск таймера CEFTI | |-<---+
| | | |
+-------------+ +-------+----+
^ |
| Успешное V
| создание |
| ассоциации |
| (отключение таймера CEFTI) |
+_________________________________________+
FE выдает событие CEPrimaryDown
Рисунок 3. Конечный автомат FE HA.
Компонента FEPO Control Element ID (CEID) указывает текущий основной элемент CE, а таблица BackupCEs – настроенные резервные CE. Параметры FEPO FE Heartbeat Interval (FEHI), CE Heartbeat Dead Interval (CEHDI) и CE Heartbeat помогают детектировать проблемы связности между FE и CE. Политика обработки отказов CE (failover policy) определяет реакцию FE на обнаруженный отказ. Компонента FEObject FEState [RFC5812] определяет рабочее состояние и управление для пересылки. CE может отключить операции пересылки FE путем установки FEState = AdminDisable и включить с помощью OperEnable. Отметим, что параграф 5.1 в [RFC5812] был обновлен в соответствии с информацией об ошибке [Err3487] в части полномочий доступа к FEState.
На рисунке 3 показан конечный автомат для восстановления состояния связности.
FE подключен к CE, заданному компонентой FEPO CEID. При отказе соединения с заданным CE, этот элемент переносится в конец таблицы BackupCEs и в качестве CEID используется идентификатор первого CE из таблицы BackupCEs. Затем FE пытается организовать связь с CE назначенным в качестве нового первичного CE. Эта процедура продолжается, пока FE не соединится с одним из элементов CE или не завершится интервал CEFTI13.
Имеется несколько событий, вызывающих смену ведущего. Смену может указать основной элемент CE (изменив компоненту CEID), это может быть результатом разрыва имеющейся ассоциации или потери связности между CE и FE.
При отказе коммуникаций между FE и CE (отказ CE или канала, не связанный с FE) TML на элементе FE будет запускать FE PL для этого отказа или отказ будет обнаружен с помощью сообщений Heartbeat, передаваемых между FE и CE. Коммуникационный отказ, независимо от способа его обнаружения, должен считаться потерей ассоциации между CE и соответствующим FE.
Если в FE FEPO политика восстановления CE установлена в режим 0 (принято по умолчанию), FE незамедлительно перейдет в фазу pre-association. Это означает, что при восстановлении ассоциации с CE все состояния FE потребуется создавать заново.
Если в FE FEPO политика восстановления CE установлена в режим 1, Это указывает, что FE работает в режиме HA с восстановлением при перезапуске. В таком случае FE переходит в несвязанное состояние и запускает таймер CEFTI [RFC5810]. В этом состоянии FE может продолжать пересылку пакетов в зависимости от значения компоненты CEFailoverPolicy в FEPO LFB. FE циклически перебирает по порядку заданные в конфигурации резервные CE. Сначала он помещает прежний основной CE в конец таблицы BackupCEs и устанавливает в своей компоненте CEID идентификатор первого резервного CE из таблицы BackupCEs. Затем FE пытается организовать связь с этим CE. Если создать новую ассоциацию не удалось ни с одним из резервных CE или завершился отсчет таймера CEFTI, элемент FE переходит в состояние pre-association и сбрасывает свои пути пересылки (а также устанавливает [RFC5812] для компоненты FEObject FEState значение OperDisable).
Если FE из несвязанного состояния удается соединиться с новым основным CE до завершения таймера CEFTI, он переходит в связанное состояние. После восстановления ассоциации CE может попытаться синхронизировать состояние, которое FE мог потерять за время разъединения. Процедура ресинхронизации состояния выходит за рамки современной архитектуры ForCES но обычно включает обмен запросами и сообщениями Config.
Явное сообщение (сообщение Config, устанавливающее основной CE в ForCES Protocol Object) от основного CE также позволяет сменить основной CE для элемента FE в процессе нормальной работы. В этом случае FE переходит в несвязанное состояние и пытается связаться с новым CE.
2.1.2. Ответственность за HA
Уровень TML
-
TML контролирует доступность и восстановление логических соединений.
-
TML также контролирует поддержку HA.
На этом уровне контроль нижележащих уровней (например, адреса IP и MAC14 и т. п.) и связанных каналов также относится к TML.
Уровень PL
Вся остальная функциональность, включая настройку HA при организации соединения, идентификаторы CE для указания основного и резервных CE, протокольные сообщения для уведомления об отказе CE (уведомления о событиях), сообщения Heartbeat для детектирования отказов ассоциации, сообщения для обмена с основным CE (Config) и другие операции, связанные с HA (параграф 2.1) относятся к уровню PL.
При совместной работе уровней TML будет помогать при восстановлении пути к основному CE путем переключения на другой путь, если он имеется. Если CE полностью недоступен, уровень PL будет проинформирован об этом и выполнит нужные действия, описанные выше.
3. HA с «горячей» заменой CE
В этом разделе описаны незначительные расширения существующей схемы для поддержки HA с «горячим» резервированием. Для этого предлагается улучшить конкретные показатели, упомянутые в параграфе 1.1:
-
время перехода резервного CE в рабочее состояние;
-
время создания ассоциации элементов FE с новым основным CE.
Как описано в параграфе 2.1, в фазе подготовки ассоциации (pre-association) FEM настраивает FE, осведомляя его обо всех CE в NE. Менеджер FEM должен настроить FE так, чтобы тот знал, какой из CE является основным и может указать любые резервные CE.
3.1. Изменения модели FEPO
Для достижения означенных выше целей нужно внести некоторые изменения в модель FEPO. В Приложении A приведено определение XML для новой версии FEPO LFB 1.1.
Отличия от FEPO версии 1 перечислены ниже.
-
Добавлено 4 новых типа данных.
-
CEStatusType – символ без знака (unsigned char) для указания статуса соединения с CE:
-
0 (Disconnected – отключен) говорит, что попыток связаться с CE еще не было;
-
1 (Connected – подключен) говорит о наличии соединения FE с CE на уровне TML;
-
2 (Associated – связан) говорит о наличии ассоциации между FE и CE;
-
3 (IsMaster – основной) говорит о наличии ассоциации FE с основным CE;
-
4 (LostConnection – потеря соединения) говорит о том, что FE был связан с CE, но связь потеряна;
-
5 (Unreachable – недоступен) говорит о том, что FE считает данный CE недоступным (не удалось связаться в заданном интервале времени).
-
-
HAModeValues – символ без знака для указания выбранного режима HA:
-
0 (No HA Mode) указывает, что FE не работает в режиме HA;
-
1 (HA Mode – Cold Standby) указывает, что FE работает в режиме HA с «холодным» резервом;
-
-
-
-
-
2 (HA Mode – Hot Standby) указывает, что FE работает в режиме HA с «горячим» резервом.
-
-
-
-
Statistics – комплексная структура, представляющая коммуникационную статистику между FE и CE.
-
RecvPackets – счетчик пакетов, принятых от CE.
-
-
-
-
-
RecvBytes – счетчик байтов, принятых от CE.
-
-
-
-
-
RecvErrPackets – счетчик пакетов с ошибками, принятых от CE. Здесь учитываются пакеты с ошибками в формате, а также корректные пакеты, переданные FE элементом CE, который не является основным, для установки компонент (т. е. пакеты, на которые не реагировали).
-
-
-
-
-
RecvErrBytes – счетчик байтов, принятых от CE в RecvErrPackets.
-
-
-
-
-
TxmitPackets – счетчик пакетов, переданных элементу CE.
-
-
-
-
-
TxmitErrPackets – счетчик пакетов, переданных элементу CE. Обычно это связано с коммуникационными сбоями.
-
-
-
-
-
TxmitBytes – счетчик байтов, переданных элементу CE.
-
-
-
-
-
TxmitErrBytes- счетчик байтов с ошибками, переданных элементу CE.
-
-
-
-
AllCEType – комплексная структура, содержащая идентификаторы CE, статистику и CEStatusType для одного CE. Применяется в массиве AllCEs.
-
-
В конце добавлены две новых компоненты.
-
Массив AllCEs элементов AllCEType доступен лишь для чтения и содержит статус всех CE.
-
Доступное для чтения и записи поле HAMode типа HAModeValues, указывающее режим HA, используемый FE.
-
-
Добавлено событие PrimaryCEChanged, указывающее идентификатор нового основного CE при смене.
Поскольку никакие компоненты FEPO v1 не были изменены, FEPO v1.1 остается совместимым с CE, которые поддерживают только версию 1.0. Однако такие CE не смогут пользоваться возможностями HA новой версии FEPO.
3.2. Обработка FEPO
Таблица AllCEs в FEPO LFB версии 1.1 элемента FE содержит идентификаторы всех CE, с которыми FE может соединиться и создать ассоциацию. Порядок CE ID в этой таблице определяет порядок попыток FE соединиться с элементами CE. Эта таблица изначально предоставляется уровнем настройки конфигурации (FEM). В фазе pre-association первый CE (с наименьшим индексом) в таблице AllCEs должен быть первым элементом CE, с которым FE будет пытаться создать ассоциацию. Если FE не сможет связаться с первым CE из списка, попытка будет повторена со вторым и т. д., пока ассоциация не будет организована. Элемент FE должен связаться по меньшей мере с одним CE. При успешной организации связи компонента FEPO LFB, а именно CEID, указывает текущий основной элемент CE.
Хотя проще было бы FE не отвечать на любые сообщения от элементов CE, кроме основного, на практике полезно также отвечать на запросы и сообщения heartbeat от резервных CE. По этой причине резервным CE разрешается передавать запросы к FE. Конфигурационные сообщения (SET/DEL) от резервных CE должны отбрасываться с записью ошибки в системный журнал.
Асинхронные события, на которые подписан основной CE, а также сообщения heartbeat передаются всем связанным CE. Перенаправление пакетов осуществляется только в основной элемент CE. Интервал Heartbeat, политика CE Heartbeat (CEHB) и FE Heartbeat (FEHB) являются глобальными для всех CE (и меняются лишь ведущим CE).
На рисунке 4 показан конечный автомат, который упрощает восстановление соединений при включенном режиме HA.
FE пытается создать ассоциацию
+-->-----+
| |
(Смена основного CE|| | |
CE выдает Teardown || +---+--------v----+
потеря ассоциации) && | Pre-association |
CE failover policy = 0 | (Процесс |
+------------>-->-->| создания +<----+
| | ассоциации) | |
| | | |
| +--------+--------+ |
| Отклик | | Завершен
| о создании ассоциации V | отсчет
| +------------------+ | таймера
| |FE выдает CEPrimaryDown ^ CEFTI
| |FE выдает PrimaryCEChanged ^
| V |
+-+-----------+ +------+-----+
| | (Смена основного CE|| | Нет |
| | CE выдает Teardown || | ассоциации |
| | потеря ассоциации) && | +->----------+
| Ассоциация | CE failover policy = 1 |(можно |Найти первый|
| | | продолжать |связанный v
| |-------->------->------>| пересылку) |CE или прод.|
| | Начало отсчета CEFTI | |попытки |
| | | |-<----------+
| | | |
+----+--------+ +-------+----+
| |
^ Найден | ассоциированный CE
| или вновь | ассоциирован CE
| V
| (отключение таймера CEFTI) |
+_________________________________________+
FE выдает событие CEPrimaryDown
FE выдает событие PrimaryCEChanged
Рисунок 4. Конечный автомат FE HA.
После того, как FE свяжется с основным CE, он переходит в фазу post-association (связанное состояние). Предполагается, что основной CE будет взаимодействовать с другими CE внутри NE для синхронизации через интерфейс CE-CE. Рассмотрение этого интерфейса выходит за рамки документа CE-CE. В результате выбора среди элементов CE может возникать желание использовать в качестве основного другой CE – в таких случаях текущий основной CE будет инструктировать FE на переход к другому ведущему CE.
FE CE#1 CE#2 ... CE#N | | | | | Создание ассоциации | | | | Обмен возможностями | | | 1 |<------------------------->| | | | | | | | Обновление состояния | | | 2 |<------------------------->| | | | | | | | Создание ассоциации | | | Обмен возможностями | | 3I|<-------------------------------------->| | ... ... ... ... | Создание ассоциации, обмен возможностями | 3N|<----------------------------------------------->| | | | | 4 |<------------------------->| | | . . . . 4x|<------------------------->| | | | Отказ | | | | | | | Уведомление (смена LastCEID) | | 5 |--------------------------------------->|------->| | Уведомление (CE#2 стал новым ведущим) | | 6 |--------------------------------------->|------->| | | | 7 |<-------------------------------------->| | . . . . 7x|<-------------------------------------->| | . . . .
Рисунок 5. Восстановление CE в горячем режиме.
Если в фазе post-association для политики восстановления CE установлено значение 1, а HAMode = 2 («горячий» резерв), FE после связывания с основным CE должен попытаться организовать связи с остальными, известными ему CE. На рисунке 5 этапы #1 и #2 показывают связывание FE с основным CE#1, а последующие этапы #3I – #3N показывают организацию связей с резервными CE – CE#2 – CE#N. Если FE не сможет связаться с некоторыми CE, он может пометить их как недоступные для предотвращения последующих попыток соединения. FE может повторить попытку связи с такими CE, когда это будет возможно.
Когда основной CE по какой-либо причине отключается (down), FE должен попытаться найти первый связанный CE из своего списка, перебирая элементы по кругу.
Если элемент FE не способен найти связанного CE в своем списке, он должен попытаться соединиться и организовать ассоциацию с первым CE из списка, перебирая их по кругу, пока не удастся организовать ассоциацию с CE или не завершится отсчет таймера CEFTI.
Как только FE выберет связанный элемент CE в качестве нового основного элемента управления, FE выдает уведомление о событии PrimaryCEDown для всех связанных CE, сообщающее об отключении прежнего основного CE (с его идентификацией) и второе уведомление PrimaryCEChanged, указывающее новый CE, который FE сейчас считает основным.
В большинстве имеющихся вариантов архитектуры HA возможно разделение «мозга». Однако в нашем случае FE никогда будет воспринимать конфигурационные сообщения лишь от ведущего CE, поэтому FE считается защищенным от повреждений со стороны других CE, которые сочли себя ведущими. Поэтому задача «расщепления мозга» переносится на уровень взаимодействия между CE, выходящего за рамки этого документа.
Благодаря наличию множества соединений с CE переключение FE на новый ведущий элемент CE будет существенно быстрее. Общий эффект заключается в улучшении времени восстановления NE в случаях отказа коммуникаций с ведущим CE или самого элемента. Это удовлетворяет заявленному выше требованию.
4. Взаимодействие с IANA
В соответствии с правилами «Guidelines for Writing an IANA Considerations Section in RFCs» [RFC5226] пространство имен «Logical Functional Block (LFB) Class Names and Class Identifiers» было обновлено.
Добавлена колонка «LFB version» после колонки «LFB Class Name» и сейчас таблица имеет вид
|
Идентификатор класса LFB |
Имя класса LFB |
Версия LFB |
Описание |
Документ |
|---|
Применяются правила [RFC5812] с учетом необходимости добавления строкового значения LFB version.
При публикации этого документа всем прежним записям назначена версия 1.0.
Новым версиям уже определенных LFB недопустимо удалять записи имеющихся версий.
Имеет смысл располагать LFB в порядке роста версии. Таблицу следует сортировать сначала по значениям Class ID, а затем по номерам версий.
Этот документ добавляет FE Protocol Object версии 1.1, как показано ниже.
|
Идентификатор класса LFB |
Имя класса LFB |
Версия LFB |
Описание |
Документ |
|---|---|---|---|---|
|
2 |
FE Protocol Object |
1.1 |
Определяет параметры протокольных операций ForCES |
[RFC7121] |
5. Вопросы безопасности
Вопросы безопасности, указанные в разделе 9 [RFC5810], применимы к защите всем коммуникаций между CE и FE. При соединении множества CE с одним FE требуется следовать тем же процедурам в фазе per-association.
Следует отметить, что FE инициирует соединение CE, а CE не может выступать инициатором соединения с FE и такие сообщения должны отбрасываться. Таким путем FE защищается от обманных CE, которые пытаются связаться с ним.
Разработчикам CE следует учитывать, что после организации связи FE не сможет отличить компрометацию CE или отказы при работе без потери соединения. Защита CE выходит за рамки этого документа. Хотя взаимодействие между CE и не рассматривается в настоящее время в рамках ForCES, мы понимаем, что оно может быть подвержено атакам, влияющим на взаимодействие между CE и FE.
Следует учитывать приведенные ниже соображения.
-
Следует использовать защищенные каналы связи между CE для координации и сохранения состояний хотя бы для предотвращения соединений со злонамеренными CE.
-
Основному CE следует принимать во внимание атаки DoS и DDoS15 от враждебных или настроенных с ошибками CE.
-
CE следует учитывать «расщепление мозга». В настоящее время FE имеет два механизма защиты. Во-первых, FE имеет компоненту CEID, указывающую основной CE. Во-вторых, FE не позволяет резервным CE настраивать свою конфигурацию. Однако резервному CE, считающему, что основной CE был сменен и он сам стал ведущим, нужно сначала выполнить проверку работоспособности и запросить у FE компоненту CEID.
6. Литература
6.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification”, RFC 5810, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, “Forwarding and Control Element Separation (ForCES) Forwarding Element Model”, RFC 5812, March 2010.
6.2. Дополнительная литература
[Err3487] RFC Errata, Errata ID 3487, RFC 5812, <http://www.rfc-editor.org>.
[RFC3654] Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding”, RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework”, RFC 3746, April 2004.
Приложение A. Новая версия FEPO
Код xml был проверен на предмет соответствия схеме, определенной в [RFC5812].
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO"> <!-- XXX --> <dataTypeDefs> <dataTypeDef> <name>CEHBPolicyValues</name> <synopsis> Возможные значения политики CE Heartbeat </synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>CEHBPolicy0</name> <synopsis> CE будет передавать Heartbeat FE каждый интервал CEHDI, если за это время не было других сообщений. </synopsis> </specialValue> <specialValue value="1"> <name>CEHBPolicy1</name> <synopsis> CE будет не передавать Heartbeat FE </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>FEHBPolicyValues</name> <synopsis> Возможные значения политики FE Heartbeat </synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>FEHBPolicy0</name> <synopsis> FE не будет не генерировать Heartbeat для CE </synopsis> </specialValue> <specialValue value="1"> <name>FEHBPolicy1</name> <synopsis> FE будет генерировать Heartbeat для CE каждый интервал FEHI, если CE не передавалось других сообщений. </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>FERestartPolicyValues</name> <synopsis> Возможные значения политики перезапуска FE </synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>FERestartPolicy0</name> <synopsis> FE восстанавливает свое состояние с нуля </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>HAModeValues</name> <synopsis>Возможные значения режимов HA</synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>NoHA</name> <synopsis>FE не работает в режиме HA</synopsis> </specialValue> <specialValue value="1"> <name>ColdStandby</name> <synopsis> FE работает в режиме «холодного» резерва </synopsis> </specialValue> <specialValue value="2"> <name>HotStandby</name> <synopsis> FE работает в режиме «горячего» резерва </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>CEFailoverPolicyValues</name> <synopsis> Возможные значения политики восстановления CE </synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>CEFailoverPolicy0</name> <synopsis> FE следует незамедлительно прервать работу и перейти в состояние FE OperDisable </synopsis> </specialValue> <specialValue value="1"> <name>CEFailoverPolicy1</name> <synopsis> FE следует продолжать пересылку даже без связанного CE для CEFTI. FE переходит с состояние FE OperDisable по завершении отсчета CEFTI при отсутствии ассоциации. Требуется поддержка аккуратного перезапуска. </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>FEHACapab</name> <synopsis> Поддерживаемые возможности HA </synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>GracefullRestart</name> <synopsis> FE поддерживает аккуратный перезапуск </synopsis> </specialValue> <specialValue value="1"> <name>HA</name> <synopsis>FE поддерживает HA</synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>CEStatusType</name> <synopsis>Значения статуса для каждого CE</synopsis> <atomic> <baseType>uchar</baseType> <specialValues> <specialValue value="0"> <name>Disconnected</name> <synopsis>Еще не было попытки соединения с CE </synopsis> </specialValue> <specialValue value="1"> <name>Connected</name> <synopsis>Соединение FE с CE на уровне TML организовано. </synopsis> </specialValue> <specialValue value="2"> <name>Associated</name> <synopsis>FE связан с CE</synopsis> </specialValue> <specialValue value="3"> <name>IsMaster</name> <synopsis>CE является основным (и связанным) </synopsis> </specialValue> <specialValue value="4"> <name>LostConnection</name> <synopsis>FE был связан с CE, но потерял соединение. </synopsis> </specialValue> <specialValue value="5"> <name>Unreachable</name> <synopsis>CE представляется недоступным для FE </synopsis> </specialValue> </specialValues> </atomic> </dataTypeDef> <dataTypeDef> <name>StatisticsType</name> <synopsis>Определение статистики</synopsis> <struct> <component componentID="1"> <name>RecvPackets</name> <synopsis>Принято пакетов</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="2"> <name>RecvErrPackets</name> <synopsis>Принято от CE пакетов с ошибками </synopsis> <typeRef>uint64</typeRef> </component> <component componentID="3"> <name>RecvBytes</name> <synopsis>Число принятых от CE байтов</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="4"> <name>RecvErrBytes</name> <synopsis>Число принятых от CE байтов с ошибками</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="5"> <name>TxmitPackets</name> <synopsis>Число переданных элементу CE пакетов</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="6"> <name>TxmitErrPackets</name> <synopsis> Число переданных элементу CE пакетов с ошибками </synopsis> <typeRef>uint64</typeRef> </component> <component componentID="7"> <name>TxmitBytes</name> <synopsis>Число переданных элементу CE байтов</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="8"> <name>TxmitErrBytes</name> <synopsis> Число переданных элементу CE байтов с ошибками </synopsis> <typeRef>uint64</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>AllCEType</name> <synopsis>Таблица для AllCE</synopsis> <struct> <component componentID="1"> <name>CEID</name> <synopsis>Идентификатор CE</synopsis> <typeRef>uint32</typeRef> </component> <component componentID="2"> <name>Statistics</name> <synopsis>Статистика для CE</synopsis> <typeRef>StatisticsType</typeRef> </component> <component componentID="3"> <name>CEStatus</name> <synopsis>Статус CE</synopsis> <typeRef>CEStatusType</typeRef> </component> </struct> </dataTypeDef> </dataTypeDefs> <LFBClassDefs> <LFBClassDef LFBClassID="2"> <name>FEPO</name> <synopsis> FE Protocol Object с новым CEHA </synopsis> <version>1.1</version> <components> <component componentID="1" access="read-only"> <name>CurrentRunningVersion</name> <synopsis>Работающая версия ForCES</synopsis> <typeRef>uchar</typeRef> </component> <component componentID="2" access="read-only"> <name>FEID</name> <synopsis>Индивидуальный FEID</synopsis> <typeRef>uint32</typeRef> </component> <component componentID="3" access="read-write"> <name>MulticastFEIDs</name> <synopsis> Таблица всех групповых идентификаторов </synopsis> <array type="variable-size"> <typeRef>uint32</typeRef> </array> </component> <component componentID="4" access="read-write"> <name>CEHBPolicy</name> <synopsis>Политика CE Heartbeat</synopsis> <typeRef>CEHBPolicyValues</typeRef> </component> <component componentID="5" access="read-write"> <name>CEHDI</name> <synopsis> CE Heartbeat Dead Interval в миллисекундах </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="6" access="read-write"> <name>FEHBPolicy</name> <synopsis>Политика FE Heartbeat</synopsis> <typeRef>FEHBPolicyValues</typeRef> </component> <component componentID="7" access="read-write"> <name>FEHI</name> <synopsis> FE Heartbeat Interval в миллисекундах </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="8" access="read-write"> <name>CEID</name> <synopsis> Основной CE с которым связан данный FE </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="9" access="read-write"> <name>BackupCEs</name> <synopsis> Таблица всех резервных CE (без основного) </synopsis> <array type="variable-size"> <typeRef>uint32</typeRef> </array> </component> <component componentID="10" access="read-write"> <name>CEFailoverPolicy</name> <synopsis> Политика восстановления при отказах CE </synopsis> <typeRef>CEFailoverPolicyValues</typeRef> </component> <component componentID="11" access="read-write"> <name>CEFTI</name> <synopsis> CE Failover Timeout Interval в миллисекундах </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="12" access="read-write"> <name>FERestartPolicy</name> <synopsis> Политика перезапуска FE </synopsis> <typeRef>FERestartPolicyValues</typeRef> </component> <component componentID="13" access="read-write"> <name>LastCEID</name> <synopsis> Основной CE, с которым этот FE был связан в последний раз </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="14" access="read-write"> <name>HAMode</name> <synopsis>Используемый режим HA</synopsis> <typeRef>HAModeValues</typeRef> </component> <component componentID="15" access="read-only"> <name>AllCEs</name> <synopsis>Таблица всех CE</synopsis> <array type="variable-size"> <typeRef>AllCEType</typeRef> </array> </component> </components> <capabilities> <capability componentID="30"> <name>SupportableVersions</name> <synopsis> Таблица версий ForCES, поддерживаемых FE </synopsis> <array type="variable-size"> <typeRef>uchar</typeRef> </array> </capability> <capability componentID="31"> <name>HACapabilities</name> <synopsis> Таблица возможностей HA, поддерживаемых FE </synopsis> <array type="variable-size"> <typeRef>FEHACapab</typeRef> </array> </capability> </capabilities> <events baseID="61"> <event eventID="1"> <name>PrimaryCEDown</name> <synopsis>Основной CE изменен</synopsis> <eventTarget> <eventField>LastCEID</eventField> </eventTarget> <eventChanged/> <eventReports> <eventReport> <eventField>LastCEID</eventField> </eventReport> </eventReports> </event> <event eventID="2"> <name>PrimaryCEChanged</name> <synopsis>Выбран новый основной CE</synopsis> <eventTarget> <eventField>CEID</eventField> </eventTarget> <eventChanged/> <eventReports> <eventReport> <eventField>CEID</eventField> </eventReport> </eventReports> </event> </events> </LFBClassDef> </LFBClassDefs> </LFBLibrary>
Адреса авторов
Kentaro Ogawa
NTT Corporation
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
EMail: k.ogawa@ntt.com
Weiming Wang
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Evangelos Haleplidis
University of Patras
Department of Electrical and Computer Engineering
Patras 26500
Greece
EMail: ehalep@ece.upatras.gr
Jamal Hadi Salim
Mojatatu Networks
Suite 400, 303 Moodie Dr.
Ottawa, Ontario K2H 9R4
Canada
EMail: hadi@mojatatu.com
Перевод на русский язык
Николай Малых
1Control Element.
2High Availability.
3Forwarding and Control Element Separation – разделение элементов управления и пересылки.
4Network Element.
5Cold Standby High Availability – высокая доступность с «холодным» резервированием.
6Internet Engineering Task Force.
7Internet Engineering Steering Group.
8FE Manager.
9CE Manager.
10Transport Mapping Layer – уровень транспортного отображения
11Stream Control Transmission Protocol – протокол управления передачей потоков.
12High Availability – высокий уровень доступности.
13CE Failover Timeout Interval – интервал ожидания восстановления связности с CE.
14Media Access Control – контроль доступа к среде.
15Distributed Denial-of-Service – распределенная атака, нацеленная на отказ в обслуживании.