RFC 7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element

Опубликовано 28.02.2014 автором Nikolai Malykh

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

PDF

Аннотация

Этот документ описывает элемент управления с высокой доступностью (CE¹ HA²) внутри элемента сети ForCES³ NE⁴. Кроме того, этот документ обновляет RFC 5810, предоставляя новое описание механизма Cold Standby High Availability⁵.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF⁶ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG⁷. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7121.

Авторские права

К документу применимы права и ограничения, указанные в 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 (FEM⁸) через интерфейс Ff и каждому CE менеджером CE (CEM⁹) на интерфейсе 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 с помощью транспортного отображения (TML¹⁰), если оно завершается на интерфейсе 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, которые использует возможности существующих транспортных протоколов для решения задач доставки протокольных сообщений, таких как отображения этих сообщений на различные транспортные среды (SCTP¹¹, IP, TCP, UDP, ATM, Ethernet и пр.), обеспечения гарантий доставки, групповой адресации, сохранения порядка и т. п. Спецификации ForCES TML задаются в отдельных документах ForCES для каждого типа TML.

2. Схема RFC 5810 для CE HA

Для обеспечения CE HA¹² элементы 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 или не завершится интервал CEFTI¹³.

Имеется несколько событий, вызывающих смену ведущего. Смену может указать основной элемент 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 и MAC¹⁴ и т. п.) и связанных каналов также относится к 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 новых типа данных.
1. 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 недоступным (не удалось связаться в заданном интервале времени).
2. HAModeValues — символ без знака для указания выбранного режима HA:
  - 0 (No HA Mode) указывает, что FE не работает в режиме HA;
  - 1 (HA Mode — Cold Standby) указывает, что FE работает в режиме HA с «холодным» резервом;

1. - 2 (HA Mode — Hot Standby) указывает, что FE работает в режиме HA с «горячим» резервом.

1. Statistics — комплексная структура, представляющая коммуникационную статистику между FE и CE.
  - RecvPackets — счетчик пакетов, принятых от CE.

1. - RecvBytes — счетчик байтов, принятых от CE.

1. - RecvErrPackets — счетчик пакетов с ошибками, принятых от CE. Здесь учитываются пакеты с ошибками в формате, а также корректные пакеты, переданные FE элементом CE, который не является основным, для установки компонент (т. е. пакеты, на которые не реагировали).

1. - RecvErrBytes — счетчик байтов, принятых от CE в RecvErrPackets.

1. - TxmitPackets — счетчик пакетов, переданных элементу CE.

1. - TxmitErrPackets — счетчик пакетов, переданных элементу CE. Обычно это связано с коммуникационными сбоями.

1. - TxmitBytes — счетчик байтов, переданных элементу CE.

1. - TxmitErrBytes- счетчик байтов с ошибками, переданных элементу CE.

1. AllCEType — комплексная структура, содержащая идентификаторы CE, статистику и CEStatusType для одного CE. Применяется в массиве AllCEs.
В конце добавлены две новых компоненты.
1. Массив AllCEs элементов AllCEType доступен лишь для чтения и содержит статус всех CE.
2. Доступное для чтения и записи поле 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 и DDoS¹⁵ от враждебных или настроенных с ошибками 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

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

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 — распределенная атака, нацеленная на отказ в обслуживании.

Рубрика: RFC | Комментарии отключены

RFC 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

Опубликовано 14.02.2014 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                    M. Bhatia, Ed.
Request for Comments: 7130                                Alcatel-Lucent
Category: Standards Track                                   M. Chen, Ed.
ISSN: 2070-1721                                      Huawei Technologies
                                                         S. Boutros, Ed.
                                                    M. Binderberger, Ed.
                                                           Cisco Systems
                                                            J. Haas, Ed.
                                                        Juniper Networks
                                                           February 2014

Двухстороннее детектирование пересылки (BFD) на интерфейсах LAG

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

PDF

Аннотация

Этот документ определяет механизм для запуска двухстороннего детектирования пересылки (BFD¹) на интерфейсах LAG². Это выполняется путем запуска независимой асинхронной сессии BFD на каждом канале в составе LAG.

Механизм позволяет проверить целостность канала при наличии или отсутствии протокола LACP³. Механизм обеспечивает более короткое время детектирования по сравнению с LACP. Проверка целостности охватывает также элементы двухсторонней пересылки сетевого уровня (L3).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF⁴ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG⁵. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7130.

Авторские права

1. Введение

Протокол BFD [RFC5880] обеспечивает механизм потенциально быстрого обнаружения отказов на двухсторонних путях между парой машин пересылки, включая интерфейсы и каналы передачи данных, а также, насколько это возможно, сами машины. Протокол BFD также обеспечивает быстрый механизм обнаружения коммуникационных отказов на любых каналах данных и может работать через любую среду на любом физическом уровне.

LAG в соответствии с определением [IEEE802.1AX] обеспечивает механизмы объединения множества физических каналов в один логический. Этот логический канал обеспечивает большую пропускную способность и надежность, поскольку при отказе одного из физических каналов объединенный логический канал может продолжать пересылку трафика через оставшиеся физические каналы.

В настоящее время для обнаружения отказов на физических каналах группы используется протокол LACP. Однако использование BFD обеспечивает (1) более быстрое обнаружение, (2) не требует наличия LACP и (3) позволяет проверить способность каждого канала группы пересылать пакеты L3.

Организация одной сессии BFD на объединенном канале без информации о членах группы не позволяет BFD гарантированно обнаруживать отказы физических каналов данной группы.

Цель состоит в проверке связности (Continuity) для каждого канала в группе. Это соответствует параграфу 7.3 в [RFC5882].

Предложенный в этом документе подход заключается в организации асинхронной сессии BFD на каждом канале группы LAG и BFD-управления включением члена LAG в таблицу балансировки нагрузки L2 на интерфейсе LAG при наличии или отсутствии LACP.

Документ описывает организацию асинхронной сессии BFD на физических каналах группы интерфейса LAG.

Хотя в Ethernet имеются свои механизмы детектирования отказов (802.1ax, .3ah), которые можно использовать для LAG, предлагаемое здесь решение позволяет операторам, которые уже развернули BFD для других технологий (например, IP или MPLS) применять для детектирования отказов общий механизм.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. BFD на каналах LAG

Механизм быстрого обнаружения отказов на каналах группы LAG основан на организации асинхронной сессии BFD для каждого физического канала LAG. Такие сессии далее называются сессиями micro-BFD.

2.1. Семейство адресов сессий Micro-BFD

Сессии micro-BFD на каналах групп при использовании инкапсуляции IP/UDP, могут применять адреса IPv4 или IPv6. На канале группы могут существовать две сессии micro-BFD — одна IPv4, другая IPv6. При использовании семейства адресом на канале группы, оно должно применяться для всех каналов данной группы LAG.

2.2. Согласование сессии Micro-BFD

Для каждого разрешенного семейства адресов организуется одна сессия micro-BFD на каждом канале группы LAG. Согласование сессий micro-BFD должно выполняться в соответствии с процедурой, определенной в [RFC5880] и [RFC5881].

В этом документе рассматривается лишь асинхронный режим BFD, а использование эхо-функции BFD выходит за рамки документа. По крайней мере одна из систем должна быть активной (Active role). Сессии micro-BFD на каналах группы являются независимыми сессиями BFD. Они используют свои уникальные дискриминаторы, поддерживают свои наборы переменных состояния и имеют свои независимые машины состояний. Значения таймеров могут быть разными для для сессий micro-BFD, относящихся к одной группе, хотя предполагаются одинаковые значения таймеров для всех сессий micro-BFD одной группы каналов.

Демультиплексирование полученного пакета BFD основано исключительно на значениях поля Your Discriminator, если оно отлично от 0. Для начальных пакетов Down BFD в сессии BFD это поле может иметь нулевое значение. В таких случаях демультиплексирование должно выполняться на основе комбинации других полей, которая должна включать информацию об интерфейсе канала группы и номер порта получателя UDP из полученного пакета BFD.

Процедура приема управляющих пакетов BFD, описанная в параграфе 6.8.6 [RFC5880] переопределена для сессий micro-BFD на каналах группы LAG, как указано ниже.

Если поле Your Discriminator отлично от 0 и обнаружена сессия micro-BFD для канала LAG, интерфейс, на котором принят пакет управления micro-BFD, должен соответствовать связанному с этой сессией интерфейсу.

Этот документ определяет, что пакеты управления BFD для каждой сессии micro-BFD инкапсулируются в IP/UDP, как определено в [RFC5881], но используется порт получателя UDP 6784.

Использование нового порта UDP позволяет отличать BFD через LAG от BFD через один интервал (single-hop) IP. Примером такой ситуации может служить (некорректно) настроенная группа LAG с сессиями micro-BFD на одной стороне, использующая сессию [RFC5881] BFD для LAG (считается одним интерфейсом) на другой стороне.

Описанные в этом документе процедуры должны применяться для сообщений BFD, адресованных в порт 6784, и их недопустимо использовать для других портов, указанных в RFC для других режимов BFD.

Пакеты управления используют IP-адрес получателя, который настроен на партнерской системе и доступен через интерфейс LAG.

Реализации могут варьироваться от явной настройки адресов IP для сессий BFD до использования специальных (out-of-band) методов определения IP-адреса получателя. Детали этого выходят за рамки документа.

2.3. Сессии Micro-BFD на каналах Ethernet

На каналах Ethernet группы LAG в качестве MAC-адреса получателя используется выделенный групповой адрес MAC 01-00-5E-90-00-01 для ближайшего интервала пересылки. Выделенный MAC-адрес должен применяться для первоначальных пакетов BFD сессии micro-BFD в состояниях Down/AdminDown и Init. При переходе сессии micro-BFD в состояние Up, первые пакеты bfd.DetectMult для состояния Up должны передаваться по выделенному адресу MAC. Для пакетов BFD в состоянии Up, следующих за первыми пакетами bfd.DetectMult, может указываться MAC-адрес отправителя из полученного пакета BFD для этой сессии вместо использования выделенного MAC-адреса.

Все реализации должны быть способны принимать и передавать пакеты BFD в состоянии Up с использованием выделенного MAC-адреса. Реализациям, поддерживающим передачу пакетов BFD Up с выделенным и полученным MAC-адресом, следует обеспечить способ выбора поведения.

На Ethernet-каналах группы LAG в качестве MAC-адреса отправителя следует использовать MAC-адрес физического интерфейса, передающего пакет.

Этот механизм позволяет снизить потребность в дополнительных MAC-адресах, что ведет к снижению потребности в ресурсах Ethernet на приемной стороне входящих в группу каналов.

Пакеты сессий Micro-BFD следует во всех случаях передавать без тегов. Однако при использовании LAG в контексте IEEE 802.1q или IEEE 802.qinq пакеты micro-BFD могут передаваться без тегов или с нулевым значением тега vlan (тег приоритета 802.1p). Реализации, соответствующие данному стандарту, должны быть способны принимать оба типа пакетов micro-BFD.

3. Взаимодействие LAG и BFD

Сессии micro-BFD для определенного члена LAG должны запрашиваться, когда этот канал находится в состоянии Distributing или Standby. Сессии должны удаляться, когда состояние канала отличается от Distributing и Standby.

BFD используется для управления, если алгоритм распределения нагрузки способен выбирать отдельный канал в LAG. Иными словами, даже при использовании протокола LACP и готовности членов группы пересылать трафик балансировщику нагрузки недопустимо использовать канал, пока все сессии micro-BFD на этом канале не находятся в состоянии Up.

Если реализация имеет отдельные таблицы балансировки для IPv4 и IPv6 и на канале имеются сессии micro-BFD для IPv4 и IPv6, реализация может разрешить использование канала механизмом распределения нагрузки на основе сессии BFD для соответствующего семейства адресов.

Исключением являются сами пакеты BFD. Реализации могут принимать и передавать пакеты BFD через интерфейс MAC-сервиса агрегатора независимо от состояния сессии.

4. BFD на каналах LAG и приложения L3

Описанный в этом документе механизм скорей всего будет применяться модулями, управляющими интерфейсами или группами LAG, управляя тем самым отдельными каналами LAG. Типовые протоколы L3 (например, OSPF) не имеют представления о LAG и рассматривают его как один «большой» интерфейс. Сигнализация от микросессий в протоколы L3 реально осуществляется с помощью сессий micro-BFD в таблице балансировки нагрузки и возможного решения модуля управления Interface/LAG о закрытии (shut down) LAG. Активный метод проверки влияния сессий micro-BFD для протоколов L3 состоит в запросе одной сессии BFD на LAG.

5. Детектирование отказа члена группы

При отключении сессии micro-BFD соответствующий канал группы должен удаляться из таблиц(ы) распределения нагрузки LAG.

Если реализация использует разные таблицы балансировки нагрузки для IPv4 и IPv6 и на канале существуют сессии micro-BFD для IPv4 и IPv6, реализация может удалять канал лишь из той таблицы распределения нагрузки для того семейства адресов, сессия которого была разорвана. Например, сессия IPv4 micro-BFD может отказать, а сессия IPv6 micro-BFD остаться в состоянии Up и канал может быть удален из таблицы балансировки IPv4, но может быть сохранен в таблице балансировки IPv6. Допускается и удаление в таких случаях канала из обеих таблиц. Выбор решения определяется реализацией.

6. Вопросы безопасности

Этот не добавляет проблем безопасности, а механизмы защиты, описанные в [RFC5880], применимы к нему.

7. Взаимодействие с IANA

Агентство IANA назначило выделенный MAC-адрес 01-00-5E-90-00-01 (см. [RFC7042]), а также порт UDP 6784 для двухстороннего детектирования пересылки (BFD) на интерфейсах LAG. Была также указана ссылка на [RFC7130].

Агентство IANA изменило запись в реестре для порта 6784, чтобы показать выделение номера [IESG] и указать в качестве контакта [BFD_Chairs]. Преобразование [BFD_Chairs] указано как mailto:bfd-chairs@tools.ietf.org. Указана также ссылка на [RFC7130].

8. Благодарности

Авторы благодарны Dave Katz, Alexander Vainshtein, Greg Mirsky и Jeff Tantsura за их отзывы.

Началом текущего обсуждения послужило распространение документа Bidirectional Forwarding Detection (BFD) for Interface (июль 2011 г.).

9. Участники работы

Paul Hitchen

EMail: paul.hitchen@bt.com

George Swallow

Cisco Systems

EMail: swallow@cisco.com

Wim Henderickx

Alcatel-Lucent

EMail: wim.henderickx@alcatel-lucent.com

Nobo Akiya

Cisco Systems

EMail: nobo@cisco.com

Neil Ketley

Cisco Systems

EMail: nketley@cisco.com

Carlos Pignataro

Cisco Systems

EMail: cpignata@cisco.com

Nitin Bahadur

Bracket Computing

EMail: nitin@brkt.com

Zuliang Wang

Huawei Technologies

EMail: liang_tsing@huawei.com

Liang Guo

China Telecom

EMail: guoliang@gsta.com

Jeff Tantsura

Ericsson

EMail: jeff.tantsura@ericsson.com

10. Литература

10.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5880] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD)», RFC 5880, June 2010.

[RFC5881] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)», RFC 5881, June 2010.

[RFC5882] Katz, D. and D. Ward, «Generic Application of Bidirectional Forwarding Detection (BFD)», RFC 5882, June 2010.

10.2. Дополнительная литература

[IEEE802.1AX] IEEE Std. 802.1AX, «IEEE Standard for Local and metropolitan area networks — Link Aggregation», November 2008.

[RFC7042] Eastlake, D. and J. Abley, «IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters», BCP 141, RFC 7042, October 2013.

Приложение A. Вопросы использования BFD на каналах группы

Если функция BFD-over-LAG начала предоставляться на канале группы уже после активизации канала в LAG, состояние сессии BFD не следует учитывать в алгоритме распределения нагрузки, пока сессия BFD не перейдет в состояние Up. Если сессия BFD не перешла в состояние Up, но группа LAG стала неактивной, можно применять описанные ранее процедуры.

Это обеспечивает отсутствие влияния последовательности событий «включение LAG, затем включение BFD на LAG» на службы пересылки.

Если функция BFD-over-LAG перестала предоставляться на канале группы, когда связанная с ним сессия micro-BFD находилась в состоянии Up, BFD следует перейти в состояние AdminDown и предпринять попытку передать это состояние партнеру.

Если локальным или удаленным состоянием сессии micro-BFD является AdminDown, системе не следует показывать отказ соединения какому-либо клиенту и не следует удалять конкретный канал группы LAG из процесса пересылки. Это поведение не зависит от использования протокола LACP для LAG.

Когда трафик пересылается через канал в то время, как соответствующая сессия micro-BFD не находится в состоянии Up, реализация может использовать настраиваемый тайм-аут после которого сессия BFD должна перейти в состояние Up или пересылка через канал должна прекратиться.

При наличии такого тайм-аута должны обеспечиваться функция, позволяющая включать и отключать его применение.

Значение настраиваемого тайм-аута должно гарантировать, что LAG не останется навсегда в «несогласованном» состоянии, когда пересылка через канал происходит без подтверждения сессии micro-BFD о нормальной работе канала.

Когда устройство не использует сессию micro-BFD на канале в то время, как другое устройство делает это и воспринимает сессию как отключенную (Down), это будет приводить к двум разным представлениям о состоянии канала. Скорей всего это приведет к потере трафика в LAG. Использование другого протокола для загрузки BFD может обнаружить такое рассогласование конфигурации, поскольку не настроенная сторона будет возвращать ошибку (reject). Такие механизмы загрузки выходят за рамки этого документа.

Адреса авторов

Manav Bhatia (редактор)

Alcatel-Lucent

Bangalore 560045

India

EMail: manav.bhatia@alcatel-lucent.com

Mach(Guoyi) Chen (редактор)

Huawei Technologies

Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District

Beijing 100095

China

EMail: mach@huawei.com

Sami Boutros (редактор)

Cisco Systems

EMail: sboutros@cisco.com

Marc Binderberger (редактор)

Cisco Systems

EMail: mbinderb@cisco.com

Jeffrey Haas (редактор)

Juniper Networks

EMail: jhaas@juniper.net

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Bidirectional Forwarding Detection.

2Link Aggregation Group — группа агрегированных каналов.

3Link Aggregation Control Protocol — протокол управления объединением каналов.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

Рубрика: RFC | Комментарии отключены

Протоколы V5

Опубликовано 06.02.2014 автором Nikolai Malykh

Стек протоколов V5 используется для подключения сетей доступа (Access Network – AN) к телефонным станциям LE (Local Exchange). Протоколы V5 используются следующими методами доступа:

Доступ по аналоговым телефонным линиям.
Доступ по каналам ISDN BRI.
Доступ по каналам ISDN PRI (V5.2).
Другие аналоговые или цифровые системы доступа для полупостоянных (semi-permanent) соединений без связанной с ними сигнальной информации, передаваемой по отдельному каналу (outband).

Протокол V5 использует каналы 2048 кб/с; V5.2 может работать одновременно с 16 такими каналами. При аналоговом доступе сигнализация от LE на пользовательском порту ТфОП (PSTN) преобразуется в функциональную часть протокола V5 для передачи в сторону AN. Для пользователей ISDN в стеке V5 определен протокол управления для обмена отдельными функциями и сообщениями, требующимися для координации с процедурами управления вызовами в LE.

Для поддержки более высокого уровня трафика и динамического распределения каналов протокол V5.2 поддерживает дополнительные функции:

Протокол организации опорного канала обеспечивает организацию и восстановление соединений по запросам, идентифицируемым сигнальными сообщениями, под управлением LE.
Протокол управления каналом служит для управления идентификацией каналов, их блокировкой и обработкой ошибок для мультиканальных систем.
Протокол защиты, функционирующий на двух каналах для обеспечения безопасности, управляет коммутацией системы защиты коммуникационных каналов при возникновении сбоев.

На различных уровнях стека V5 определены протоколы: LAPV5-EF, LAPV5, V5- Link Control (управление каналом), V5-BCC, V5-PSTN, V5-Control (управление) и V5-Protection (защита).

Декодирование V5-BCC

На следующем рисунке показано положение стека протоколов V5 и других телефонных протоколов в эталонной модели OSI.

Положение стека телефонных протоколов в эталонной модели OSI

LAPV5-EF

ITU- G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

Подуровень V5 Protocol Envelope Function Sublayer обслуживает обмен информацией между AN и LE. На рисунке показан формат кадров этого протокола.

1		8	Октет
Флаг: 01111110			1
Адрес EF	0	EA 0	1
Адрес EF		EA 1
Информация			4…n-3
FCS			n-2
			n-1
Флаг: 01111110			n

Структура пакета LAPV5-EF

Адрес EF

Поле адреса имеет размер 13 битов. Значения от 0 до 8175 служат для идентификации пользовательских портов ISDN в интерфейсе V5, значения от 8176 до 8191 зарезервированы и используются для идентификации точек, через которые функции сетевого уровня V5 получают доступ к сервису канального уровня V5.

EA

Биты расширения адреса.

Информация

Поле информации пакета содержит целое число октетов. По умолчанию максимальный размер этого поля равен 533 октетам. Минимальный размер информационного поля составляет 3 октета.

FCS

Контрольная сумма кадра в соответствии с в разделом 2.1 стандарта G.921.

LAPV5-DL

ITU- G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

Канальный уровень LAPV5 (LAPV5 Data Link Sublayer) обеспечивает обмен информацией между узлами одного уровня (peer-to-peer) — AN и LE.

Пакеты LAPV5 могут использовать два формата — A (без информационного поля) и B (с информационным полем). Формат обоих типов пакетов показан на рисунках.

8	7	6	5	4	3	2	1	Октет	8	7	6	5	4	3	2	1	Октет
Адрес канала								1	Адрес канала								1
								2									2
Управление								3	Управление								3
								…									…
									Информация								n
Формат A									Формат B

Структура канального уровня V5

Адрес канала

Адрес канала состоит из двух октетов и использует показанный на рисунке формат.

8	7	6	5	4	3	2	1	Октеты
V5DLaddr						C/R	EA 0	1
V5DLaddr (младшая часть)							EA 1	2

Структура адреса канала V5.

V5DLaddr

Поле имеет длину 13 бит. Значение, содержащееся в данном поле, находится в диапазоне от 0 до 8175 и используется для идентификации ISDN-порта пользователя. В протоколе определены следующие значения:

8	7	6	5	4	3	2	1
1	1	1	1	1	1	C/R	EA	Октет 1
								Октет 2
1	1	1	0	0	0	0	EA	Сигнализация ТфОП
1	1	1	0	0	0	1	EA	Протокол управления

EA

Биты расширения адреса.

Управление

Поле управления указывает тип кадра — команда или отклик. В тех случаях, когда это применимо, поле управления содержит также порядковый номер.

Информация

При наличии информационного поля в кадре это поле содержит целое число октетов (до 260).

V5-Link Control

ITU- G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

Протокол управления каналом (V5-Link Control) используется AN и LE для обмена информацией, требуемой для координации функций управления каждым каналом 2048 кбит/с. Формат V5-Link Control показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
Дискриминатор протокола								1
Адрес сетевого уровня								2
Адрес сетевого уровня (младшая часть)								3
0	Тип сообщения							4
Другие информационные элементы								…

Заголовок V5-Link Control

Дискриминатор протокола

Это поле указывает используемый протокол стека V5.

Адрес сетевого уровня

Это поле идентифицирует элемент сетевого уровня интерфейса V5, который принял или передал данный пакет.

Тип сообщения

LINK CONTROL (управление каналом) или LINK CONTROL ACK (отклик).

Другие информационные элементы

Единственным информационным элементом протокола канального уровня является Link Control Function (функция управления каналом). Формат этого информационного элемента показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
0 0 1 0 0 0 0 1								1
Размер функции управления каналом								2
1	Функция управления каналом							4

Информационный элемент функции управления каналом

Функция управления каналом

Функция управления каналом, содержащаяся в данном сообщении.

V5-BCC

ITU- G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

Протокол V5-BCC обеспечивает LE возможность запрашивать у AN организацию и разрыв соединений между указанным пользовательским портом AN и временным интервалом интерфейса V5. Этот протокол позволяет выделять или отменять выделение опорных каналов интерфейса V5 независимым процессам. Такое выделение может осуществляться на основе вызовов, постоянно или полупостоянно (semi-permanent). Для данного порта в любой момент времени может быть активно несколько процессов.

Формат заголовка V5-BCC показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
Дискриминатор протокола								1
Номер ссылки BCC								2
								3
1	Тип сообщения							4
Другие информационные элементы								т. д.

Структура заголовка BCC.

Дискриминатор протокола

Это поле указывает используемый протокол стека V5.

Номер ссылки BCC

Номер ссылки BCC зависит от протокола BCC и использует положение информационного элемента адреса сетевого уровня в общей структуре сообщения V5.

Номер ссылки BCC указывает процесс протокола BCC в интерфейсе V5.2, который принимает или передает данное сообщение.

Значение номера ссылки BCC является случайным числом, генерируемым AN или LE при создании нового процесса BCC. Важно, чтобы номера ссылок не повторялись в сообщениях, для которых требуются разные процессы BCC (для одного направления передачи), пока старое сообщение не будет обработано и удалено. В тех случаях, когда какой-либо процесс генерирует сообщение об ошибке, принадлежащий этому процессу номер ссылки BCC не должен использоваться до тех пор, пока не пройдет время, достаточное для доставки всех сообщений, содержащих этот номер. Размер номера ссылки BCC составляет 2 октета. Формат поля показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
Src ID	Значение номера ссылки BCC							4
0	0	Значение номера ссылки BCC

Структура номера ссылки BCC.

Src ID

Поле идентификации источника, указывающее объект (LE или AN), создавший номер ссылки BCC (т. е. объект, открывший процесс протокола BCC). Процессы, порожденные LE имеют нулевое значение этого поля, а для процессов AN идентификатор равен.

Значение номера ссылки BCC

13-битовое поле, идентифицирующее процесс протокола BCC.

Тип сообщения

Поле типа сообщения указывает назначение сообщения. Используются следующие типы сообщений:

ALLOCATION (выделение).
ALLOCATION COMPLETE (выделение завершено).
ALLOCATION REJECT (отказ выделения).
DE-ALLOCATION (отмена выделения).
DE-ALLOCATION COMPLETE (отмена выделения завершена).
DE-ALLOCATION REJECT (отказ отмены выделения).
AUDIT (аудит).
AUDIT COMPLETE (аудит завершен).
AN FAULT (сбой AN).
AN FAULT ACKNOWLEDGE (подтверждение приема сообщения AN FAULT).
PROTOCOL ERROR (ошибка протокола).

Другие информационные элементы

В сообщениях протокола V5-BCC могут присутствовать следующие информационные элементы:

Идентификация порта пользователя.
Идентификация канала порта ISDN.
Идентификация временного интервала V5.
Множественное отображение (multi-slot map).
Причина отказа.
Причина ошибки протокола.
Соединение не завершено.

V5-PSTN

ITU- G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

Протокол сигнализации и мультиплексирования V5-PSTN служит для передачи информации о состоянии аналоговых линий через интерфейс V5. V5-PSTN используется вместе с объектами национального протокола сигнализации в LE. Объект национального протокола сигнализации в LE, используемый для абонентских линий, подключенных непосредственно к LE, служит также для управления вызовами на абонентских линиях, которые подключены через интерфейс V5. Для критичных к задержкам последовательностей необходимо извлечь некоторые сигналы (например, сигнал завершения) из объекта национального протокола в AN-часть. Протокол V5-PSTN представляет сравнительно небольшой набор процедур, использующихся для установки соединений на интерфейсе V5 или их разрыва, разрешения конфликтов при одновременных вызовах на интерфейсе V5, а также обслуживания вызовов при перегрузке LE. Большинство линейных сигналов не интерпретируется протоколом V5-PSTN — такие сигналы просто передаются без изменения между пользовательским портом AN и объектом национального протокола сигнализации в LE.

Формат заголовка показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
Дискриминатор протокола								1
Адрес сетевого уровня							1	2
Адрес сетевого уровня (младшая часть)								3
0	Тип сообщения							4
Другие информационные элементы								…

Формат заголовка PSTN

Дискриминатор протокола

Это поле указывает используемый протокол стека V5 (для PSTN – 01001000).

Адрес сетевого уровня

Данное поле идентифицирует процесс сетевого уровня на интерфейсе V5, который принимает или передает данный пакет.

Тип сообщения

Определяет назначение принимаемого или передаваемого сообщения. Используются следующие типы сообщений:

ESTABLISH (соединение).
ESTABLISH ACK (подтверждение соединения).
SIGNAL (сигнал).
SIGNAL ACK (подтверждение сигнала).
STATUS (состояние).
STATUS ENQUIRY (запрос состояния).
DISCONNECT (разъединение).
DISCONNECT COMPLETE (подтверждение разъединения).
PROTOCOL PARAMETER (параметры протокола).

Другие информационные элементы

Для протокола PSTN используются следующие информационные элементы:

Однооктетные IE:

Pulse-notification (уведомление об импульсе).
Line-information (информация о линии).
State (Состояние).
Autonomous-signalling-sequence (автономная последовательность сигналов).
Sequence-response (последовательность-отклик).

Информационные элементы переменной длины:

Sequence-number (порядковый номер).
Cadenced-ringing (модулированный звонок).
Pulsed-signal (импульсный сигнал).
Steady-signal (постоянный сигнал).
Digit-signal (цифровой сигнал).
Recognition-time (время распознавания).
Enable-autonomous-acknowledge (разрешить автономные подтверждения).
Disable-autonomous-acknowledge (запретить автономные подтверждения).
Cause (причина).
Resource-unavailable (ресурс недоступен).

V5-Control

ITU- G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

Протокол индикации состояния пользовательского порта V5-Control основан на разделении полномочий между AN и LE. Структура заголовка протокола V5-Control показана на рисунке.

8	7	6	5	4	3	2	1	Октеты
Дискриминатор протокола								1
Адрес сетевого уровня							0	2
Адрес сетевого уровня (младшая часть)							1	3
0	Тип сообщения							4
Другие информационные элементы								…

Формат заголовка Control

Дискриминатор протокола

Это поле указывает используемый протокол стека V5.

Адрес сетевого уровня

Адрес идентифицирует процесс сетевого уровня на интерфейсе V5, который принимает или передает данный пакет.

Тип сообщения

Используются следующие типы сообщений:

PORT CONTROL (управление портом).
PORT CONTROL ACK (подтверждение управления портом)
COMMON CONTROL (общее управление).
COMMON CONTROL ACK (подтверждение общего управления).

Другие информационные элементы

V5-Control использует следующие информационные элементы:

Однооктетные IE:

Performance grading (ранжирование).
Rejection cause (причина отказа).

Информационные элементы переменной длины:

Control function element (элемент управляющей функции).
Control function ID (идентификатор управляющей функции).
Variant Interface ID (идентификатор варианта интерфейса).

V5-Protection

ITU- G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

Интерфейс V5 может поддерживать до 16 каналов 2048 кбит/с. В соответствии с используемой схемой мультиплексирования и архитектурой протокола коммуникационный путь может содержать информацию, связанную с несколькими каналами 2048 кбит/с (неассоциированная передача информации). Сбой в коммуникационном пути оказывает влияние на обслуживание большого числа абонентов в недоступном пути. Результаты этого влияют на работу протоколов BCC, V5-Control и V5-Link Control. Для повышения надежности работы интерфейса V5 обеспечиваются процедуры переключения коммуникационных каналов в случае неисправности.

Механизм защиты используется для предохранения всех активных C-каналов. Обеспечивается также механизм защиты самого C-пути, который служит для управления процедурами переключения каналов. В дополнение к этому на всех физических C-каналах (активных и ждущих — stanby) осуществляется непрерывный мониторинг флагов для предотвращения сбоев, которые еще не обнаружены на физическом уровне. Если сбой детектируется на ждущем C-канале, передается уведомление в систему управления, которая после этого не будет переключать логические каналы C на поврежденных резервный (ждущий) канал.

Формат используемых протоколом V5-Protection заголовков показан на рисунке.

8	7	6	5	4	3	2	1	Октеты
Дискриминатор протокола								1
Адрес сетевого уровня							1	2
Адрес сетевого уровня (младшая часть)								3
0	Тип сообщения							4
Другие информационные элементы								т. д.

Формат заголовка V5-Protection

Дискриминатор протокола

Это поле указывает используемый протокол стека V5.

Адрес сетевого уровня

Адрес идентифицирует процесс сетевого уровня на интерфейсе V5, который принимает или передает данный пакет.

Тип сообщения

Определяет назначение принимаемого или передаваемого сообщения. Используются следующие типы сообщений:

SWITCH-OVER REQ
SWITCH-OVER COM
OS-SWITCH-OVER COM.
SWITCH-OVER ACK.
SWITCH-OVER REJECT.
PROTOCOL ERROR.
RESET SN COM.
RESET SN COM.

Другие информационные элементы

Протокол V5-Control использует следующие информационные элементы:

Информационные элементы переменной длины:

Sequence number (порядковый номер).
Physical C-channel identification (идентификация физического C-канала).
Rejection cause (причина отказа).
Protocol error cause (причина ошибки протокола).

Рубрика: Мир протоколов | Оставить комментарий

Frame Relay

Опубликовано 06.02.2014 автором Nikolai Malykh

Frame Relay представляет собой стандартный протокол объединения локальных сетей, который обеспечивает методы быстрой и эффективной передачи информации от пользовательских устройств до мостов и маршрутизаторов ЛВС.

Протокол Frame Relay использует кадры, подобные по структуре кадрам LAPD и отличающиеся от последних тем, что взамен заголовка кадра помещается 2-байтовое поле заголовка Frame Relay. Заголовок Frame Relay содержит заданное пользователем поле DLCI, которое служит адресом получателя данного кадра. Поле заголовка содержит также биты насыщения и состояния, которые передаются пользователю со стороны сети.

Виртуальные устройства (VC)

Кадры Frame Relay передаются получателям с использованием виртуальных устройств (логический путь между отправителем и получателем). Виртуальные устройства могут быть постоянными (PVC) или коммутируемыми (SVC). PVC организуются административными методами администратором сети для создания соединений «точка-точка». Коммутируемые соединения SVC организуются по мере надобности (подобно телефонным звонкам).

Преимущества Frame Relay

Технология Frame Relay является привлекательной альтернативой использованию выделенных линий и сетей X.25 для соединения мостов и маршрутизаторов ЛВС. Успех протокола Frame Relay обусловлен двумя факторами:

Поскольку виртуальные устройства занимают полосу канала только при реальной передаче данных, в одной линии передачи может сосуществовать множество виртуальных устройств. В дополнение к этому каждое виртуальное устройство может при необходимости использовать более широкую полосу, что обеспечивает повышение скорости передачи данных.
Повышение надежности каналов связи и расширение возможностей обработки ошибок в оконечных устройствах (пользовательских станциях) позволяет протоколу Frame Relay просто отбрасывать кадры с ошибками, снижая затраты времени на процедуры обработки ошибок на уровне протокола.

Эти два фактора делают технологию Frame Relay удобным решением для организации сетей передачи. Однако в силу перечисленных особенностей Frame Relay требуется проверка корректности работы системы и отсутствие потерь при передаче данных.

Структура Frame Relay

Стандарты для протокола Frame Relay были разработаны одновременно ANSI и CCITT. Отдельная спецификация LMI в основном включена в стандарты ANSI. При дальнейшем рассмотрении протоколов описаны основные аспекты обоих вариантов спецификаций.

Структура кадров Frame Relay базируется на протоколе LAPD. В структуре Frame Relay заголовки кадров несколько изменены и включают идентификатор соединения на канальном уровне DLCI (Data Link Connection Identifier) и биты насыщения взамен полей адреса и управления. Структура специфической части заголовка Frame Relay имеет размер 2 байта и показана на рисунке.

Структура заголовка Frame Relay

DLCI

10-битовое поле DLCI представляет собой адрес получателя и соответствующее соединение PVC.

C/R

Указывает, что содержит кадр – команду или отклик.

EA

Поле расширенной адресации занимает до 2 битов заголовка Frame Relay и позволяет увеличить число адресуемых устройств.

FECN

Прямое уведомление о насыщении — Forward Explicit Congestion Notification (см. ECN ниже).

BECN

Обратное уведомление о насыщении — Backward Explicit Congestion Notification (см. ECN ниже).

DE

Возможность отбрасывания — Discard Eligibility (см. DE ниже).

Информация

Информационное поле может включать кадры других протоколов, таких как X.25, IP или SDLC (SNA).

Биты ECN

При возникновении в сети насыщения в точке, которая не может обрабатывать новые данные, начинается отбрасывание кадров. Отброшенные кадры передаются повторно, что усугубляет насыщение сети. Для предотвращения таких ситуаций было разработано несколько механизмов, позволяющих уведомлять пользовательские устройства о приближении к насыщению для того, чтобы устройство могло соответствующим образом управлять потоком данных.

Для оповещения пользовательских устройств о насыщении в линии используются два бита заголовка кадров Frame Relay – бит прямого уведомления FECN (Forward Explicit Congestion Notification) и бит обратного уведомления BECN (Backward Explicit Congestion Notification). Для поля FECN устанавливается значение 1 в кадрах, передаваемых в направлении получателя (downstream) при возникновении насыщения на пути передачи данных. В этом случае все узлы нисходящего потока и подключенные к ним пользовательские устройства узнают о насыщении в линии. Для бита BECN значение 1 устанавливается в кадрах, передаваемых обратно в направлении отправителя кадров. Эти уведомления говорят отправителю о необходимости снижения скорости передачи данных.

Биты насыщения устанавливаются в соответствии с DLCI

Консолидированное управление на канальном уровне (CLLM)

Может возникнуть такая ситуация, что кадров, передаваемых в направлении отправителя просто не будет. В таких случаях сеть разумно будет передавать по инициативе сети сообщения в направлении узла, вызвавшего проблемы. Однако стандарт не позволяет сети передавать свои кадры с использованием DLCI желаемого виртуального устройства. Для решения этой проблемы в ANSI была разработана спецификация консолидированного управления на канальном уровне (Consolidated Link Layer Management или CLLM). При использовании CLLM для передачи пользовательским устройствам управляющих сообщений канального уровня служит специально зарезервированное значение DLCI (номер 1023). Стандарт ANSI T1.618 определяет формат сообщений CLLM. В таких сообщениях указывается причина насыщения и перечисляются все значения DLCI, для которых требуется снижение скорости передачи данных.

Состояние соединения (LMI)

Каждому значению DLCI соответствует постоянное виртуальное устройство PVC (Permanent Virtual Circuit). Иногда возникает необходимость передачи информации о соединении (например, о состоянии активности интерфейса) по корректным значениям DLCI для интерфейса и состояние каждого PVC. Такая информация передается с использованием DLCI 1023 или DLCI 0 (в зависимости от используемого стандарта.

Вместе с LMI может также передаваться информация о состоянии групповых передач (multicast status). Групповой передачей называются такие случаи, когда маршрутизатор передает кадр по зарезервированному значению DLCI, известному как multicast-группа. В таких случаях сеть копирует групповые кадры и доставляет их по предопределенному списку DLCI (группе пользователей сразу).

Возможность отбрасывания (DE)

При возникновении насыщения в линии сеть должна решить какие кадры могут быть отброшены для освобождения полосы канала. Бит DE предоставляет сети информацию для решения вопроса о возможности отбрасывания кадров. Сеть будет в первую очередь отбрасывать кадры с установленным флагом DE (1).

Бит DE может быть установлен пользователем в кадрах, доставка которых может быть задержана (низкий приоритет). Кроме того, сеть может устанавливать флаг DE для того, чтобы показать другим узлам возможность отбрасывания данного кадра при возникновении насыщения.

Стандарты Frame Relay

ANSI T1.618

Стандарт T1.618 описывает протокол, поддерживающий фазу переноса данных сервиса Frame Relay, определенного в стандарте ANSI T1.606. Стандарт T1.618 основан на подмножестве ANSI T1.602 (LAPD), называемом Core Aspects (основные аспекты) и используемом коммутаторами и постоянными виртуальными каналами.

T1.618 также включает механизм консолидированного управления на канальном уровне CLLM. Генерация и передача CLLM являются необязательным сервисом. При использовании CLLM значение DLCI 1023 резервируется для передачи управляющих сообщений канального уровня.

T1.618 использует явные уведомления о насыщении, передаваемые сетью пользовательским устройствам. Уведомления о насыщении содержат код, показывающий причину насыщения, и список всех DLCI, для которых требуется снижение уровня трафика, чтобы преодолеть насыщение.

ANSI T1.617

Для организации коммутируемых виртуальных устройств SVC (Switched Virtual Circuit) пользователи Frame Relay должны открыть диалог с сетью, используя сигнальные спецификации T1.617. Эта процедура приводит к выделению DLCI для коммутируемого виртуального устройства. После открытия диалога применяются процедуры T1.618.

Для организации постоянного виртуального устройства PVC используется протокол организации соединений (setup protocol), идентичный протоколу D-каналов в ISDN и описанный в спецификации T1.617.

При использовании ISDN пользователи могут применять канал D для организации соединений. Для других типов абонентов (не ISDN) канала D не существует, поэтому диалог между пользователем и сетью должен быть отделен от других процедур передачи данных. В стандарте T1.617 для этого зарезервировано значение DLCI 0.

Стандарт T1.617 также содержит спецификации согласования параметров сервиса Frame Relay.

ANSI LMI

ANSI LMI представляет собой систему управления постоянными виртуальными устройствами PVC, определенную в дополнении Annex D к стандарту T1.617. ANSI LMI практически не отличается от LMI производителей, не используя лишь дополнительных расширений. В ANSI LMI зарезервировано значение DLCI 0.

LMI производителей

Manufacturers’ LMI представляет собой спецификацию Frame Relay с расширением, опубликованную в документе 001-208966 от 18 сентября 1990г.

LMI производителей определяет базовый сервис Frame Relay на основе PVC для соединения устройств DTE с сетевым оборудованием Frame Relay. В дополнение к стандарту ANSI эта спецификация включает расширенные функции и процедуры LMI. В Manufacturers’ LMI зарезервировано значение DLCI 1023.

Frame Relay NNI PVC

Интерпретация NNI (Network-to-Network – сеть-сеть) PVC для Frame Relay описана в FRF.2. Интерфейс NNI рассматривает передачу информации планов U и C (U-plane и C-plane) между двумя сетевыми узлами, находящимися в разных сетях Frame Relay.

FRF.3

FRF.3 обеспечивает многопротокольную инкапсуляцию для сетей Frame Relay в кадрах ANSI T1.618. Структура таких кадров Frame Relay показана на рисунке.

8	7	6	5	4	3	2	1	Октеты
Флаг (7Eh)								1
Адрес T1.618 (включая 10 битов DLCI)								2 3
Управление Q.922 (кадр UI или I)								4
Дополнительный байт заполнения (00h)								5
NLPID								6
Данные . . .								7
Последовательность проверки кадра								n-2 n-1
Флаг (7Eh)								n

Структура кадра FRF.3

Поле NLPID (Network Level Protocol ID идентификатор протокола сетевого уровня) обозначает тип инкапсулируемого протокола. На приведенном ниже рисунке показаны значения NLPID и соответствующие протоколы. Например, значение 0xCC говорит об инкапсуляции кадров IP.

Многопротокольная инкапсуляция Frame Relay

UNI SVC

FRF.4 представляет собой соглашение о коммутируемых виртуальных соединениях Frame Relay для интерфейса «пользователь-сеть» (UNI). Это соглашение позволяет использовать оборудование, подключенное к отличным от ISDN сетям Frame Relay или к сетям ISDN, использующим только case A.

Ниже приведен список корректных типов сообщений SVC:

ss
Call proceeding (обработка вызова).
Connect (соединение).
Connect Acknowledge (подтверждение соединения).
Disconnect (разъединение).
Progress (продолжение процесса).
Release (освобождение).
Release complete (освобождение завершено).
Setup (установка).
Status (состояние).
Status enquiry (запрос состояния).

Декодирование UNI SVC

NNI SVC

Анализаторы протоколов RADCOM поддерживают также декодирование кадров NNI (Network-to-Network) SVC в соответствии с соглашением о реализации Frame Relay Forum FRF.10. Это соглашение применяется к коммутируемым виртуальным устройствам SVC для Frame Relay NNI и SPVC. Соглашение применимо также к интерфейсам NNI, в которых обе сети являются частными, одна сеть является частной, а вторая – публичной или обе сети относятся к сетям общего пользования. Такие кадры автоматически распознаются анализатором и корректно декодируются.

FRF.11

Frame Relay в настоящее время является основной компонентой множества крупных сетей. Протокол требует минимального набора функций коммутации для пересылки пакетов переменного размера через сеть. Базовый протокол Frame Relay, описанный в соглашениях о реализации Frame Relay Forum UNI (интерфейс “пользователь-сеть) и NNI (межсетевой интерфейс), был дополнен соглашениями, которые детализируют методы передачи структурированных данных в информационных полях базовых кадров Frame Relay. Эти методы обеспечивают поддержку различных приложений, включая мосты ЛВС, маршрутизацию IP и SNA.

FRF.11 расширяет поддержку приложений Frame Relay, включая сюда возможность передачи голосового (телефонного) трафика. В частности, спецификация FRF.11 предназначена для решения следующих задач:

Передача сжатых голосовых потоков в кадрах Frame Relay.
Поддержка широкого набора алгоритмов компрессии голоса.
Эффективное использование узкополосных соединений Frame Relay.
Мультиплексирование до 256 субканалов в один Frame Relay DLCI.
Поддержка множества голосовых потоков одного или различных субканалов в одном кадре.
Поддержка субканалов передачи данных на мультиплексируемых Frame Relay DLCI.

FRF.12

FRF.12 представляет собой соглашение о реализации фрагментации (Fragmentation Implementation Agreement) в сетях Frame Relay. Фрагментация очередей снижает как абсолютное значение задержки, так и вариации задержки в сетях Frame Relay за счет деления больших пакетов на более мелкие части и последующей сборки исходных пакетов на приемной стороне. Такая возможность особенно существенна при одновременной передаче голоса и другого критичного к задержкам трафика (например, критически важные приложения SNA) с нечувствительными к задержкам данными по одному каналу PVC. Основным достоинством фрагментации является возможность использования общих линий доступа UNI или линий NNI и/или PVC для одновременной передачи больших пакетов и критичного к задержкам трафика.

Фрагментация кадров повышает уровень практичности и однородности сетей Frame Relay, снижая задержки и их вариации при улучшении времени отклика приложений. В результате могут поддерживаться многочисленные типы трафика, включая голос, факсимильные сообщения и данные, с использованием единственного UNI, NNI и/или PVC.

Соглашение о фрагментации обеспечивает для терминального (DTE) и коммуникационного (DCE) оборудования Frame Relay возможность передавать большие пакеты данных в виде кадров меньшего размера с последующей сборкой пакетов устройством DTE или DCE на стороне приемника. Фрагментация кадров требуется для контроля задержки и ее вариаций при передаче чувствительного к задержкам трафика (например, телефонного) через один интерфейс с потоками обычных (нечувствительных к задержкам) данных. Фрагментация позволяет чередовать критичный к задержкам трафик одного PVC с фрагментами больших пакетов другого PVC на одном физическом интерфейсе.

FRF.12 поддерживает три варианта фрагментации:

Локальная с использованием интерфейса Frame Relay UNI между устройствами DTE/DCE одного ранга.
Локальная с использованием интерфейса Frame Relay NNI между устройствами DCE одного ранга.
Сквозная между двумя устройствами Frame Relay DTE, соединенными через одну или несколько сетей Frame Relay.

При использовании сквозного режима процедура фрагментации прозрачна для сетей Frame Relay, расположенных между приемным и передающим устройствами DTE.

FREther

FREther представляет собой вариант Frame Relay, который содержит поле EtherType после заголовка Frame Relay. Этот вариант обеспечивает дополнительный способ инкапсуляции в сетях Frame Relay, используемый некоторыми заказчиками.

Timeplex (BRE2)

Фирменный (proprietary) протокол BRE (Bridge Relay Encapsulation), разработанный компанией Ascom Timeplex, позволяет расширять мосты через WAN-каналы за счет инкапсуляции. BRE2 представляет собой расширенный вариант стандарта, который обеспечивает повышение производительности за счет работы на канальном уровне, требующей меньшей настройки, и поддержки собственного протокола маршрутизации. Протокол BRE2 был реализован в программах маршрутизаторов версии 4.0 и поддерживается программами версий 4.x и 5.x.

Кадры BRE2 имеют следующий формат:

<———— 1 байт —————>	<———— 1 байт —————->
Тип кадра	F	Приоритет
Номер моста Source BRE (2 байта)
Идентификатор домена Source Bridge = 1
Идентификатор VLAN			SRB #
Оставшаяся часть заголовка BRE
7 байтов в нефрагментированном формате
12 байтов в фрагментированном формате


Данные

Формат кадра BRE

Если F = 0, кадр не фрагментирован и заголовок кадра BRE2 имеет длину 17 байтов. Для фрагментированных кадров F = 1 и заголовок BRE2 имеет размер 22 байта. SRB # задает номер моста Source Route (4 бита).

Cascade

Для обеспечения поддержки сервиса Frame Relay компании RBOC (Regional Bell Operating Companies) установили коммутаторы Cascade во множестве LATA и соединили их между собой для организации сервиса через LATA, а также управления коммутаторами во множестве LATA с одной станции.

Формат транкового заголовка для семейства коммутаторов Cascade STDX соответствует спецификации ANSI T1.618-1991 ISDN Core Aspects для использования с Frame Relay Bearer Service.

Формат транкового заголовка Cascade показан на рисунке.

1	2	3	4	8
R	C/R	Версия		Зарезервированы
ODE	DE	BECN	FECN	Приоритет VC
Идентификатор канала
Данные

Формат заголовка транковых кадров Cascade

R

Резервный бит.

C/R

Флаг команда — отклик.

Версия

Версия заголовка, определяющая версию заголовка транкового формата для коммутаторов Cascade STDX. В настоящее время используется версия 0.

ODE

Значение 1 означает, что скорость проникновения (ingress rate) превышает размер «избыточных пакетов» (excess burst size).

DE

Индикатор возможности отбрасывания, устанавливаемый в соответствии со спецификацией ANSI T1.618.

BECN

Обратное уведомление о насыщении в соответствии с ANSI T1.618.

FECN

Прямое уведомление о насыщении в соответствии с ANSI T1.618.

Приоритет VC

Приоритет виртуального устройства, используемый для того, чтобы различить чувствительный к задержкам трафик (например, телефонный) от трафика, некритичного к задержкам (например, передача файлов). Уровень приоритета может принимать значения 1, 2 или 3 (1 означает высший приоритет).

Для данных управления пятый байт содержит сведения о типе PDU:

0 Call request PDU (запрос соединения)

1 Confirmation PDU (подтверждение)

2 Rejected PDU (отказ)

3 Clear PDU (очистка)

4 Disrupt PDU (разрыв)

5 Hello PDU (приветствие)

6 Hello Acknowledgment PDU (подтверждение приветствия)

7 Defined Path Hello PDU (приветствие для заданного пути)

8 Defined Path Hello Acknowledgment PDU (подтверждение приветствия для заданного пути).

LAPF

Назначением протокола LAPF является передача кадров данных канального уровня между пользователями сервиса DL в плоскости U для кадрированного однонаправленного сервиса через пользовательские интерфейсы ISDN на каналах B, D или H. Кадрированные однонаправленные соединения организуются с использованием протоколов, описанных в спецификации Q.933 [3], или (для постоянных виртуальных устройств) путем подписки. LAPF использует сервис физического уровня и позволяет статистически мультиплексировать несколько однонаправленных соединений через один канал ISDN (B, D или H) с помощью процедур LAPF или совместимых с ними процедур HDLC.

Формат заголовка показан на рисунке.


Принятый по умолчанию формат адреса (2 октета)	DLCI верхнего уровня			C/R	EA 0
Принятый по умолчанию формат адреса (2 октета)	DLCI нижнего уровня	FECN	BECN	DE	EA 1

Формат адреса LAPF

Биты поля управления (модуль 128)	8	7	6	5	4	3	2	1
Формат I	N(S)							0	Октет 4
Формат I	N(R)							P/F	Октет 5
Формат S	X	X	X	X	Su	Su	0	1	Октет 4
Формат S	N(R)							P/F	Октет 5
Формат U	M	M	M	P/F	M	M	1	1	Октет 4

Формат LAPF

EA

Бит расширенной адресации.

C/R

Флаг команда — отклик.

FECN

Прямое уведомление о насыщении.

BECN

Обратное уведомление о насыщении.

DLCI

Идентификатор соединения канального уровня.

DE

Флаг возможности отбрасывания.

D/C

Флаг управления DLCI или DL-CORE.

N(S)

Порядковый номер передачи.

N(R)

Порядковый номер приема.

P/F

Бит опроса (Poll) для команд или конечный бит для откликов.

X

Зарезервированное поле (0).

Su

Бит функций наблюдения (Supervisory).

M

Бит модификатора функций.

Multiprotocol over Frame Relay

RFC 1490

RFC 2427

Технология Multiprotocol over Frame Relay обеспечивает методы инкапсуляции различных протоколов ЛВС в сетях Frame Relay. В этом случае для инкапсуляции всех протоколов используются кадры Q.922 Annex A. В дополнение к этому кадры должны содержать информацию, необходимую для идентификации протокола, передаваемого в PDU и позволяющую приемнику соответствующим образом обрабатывать входные пакеты. Формат таких кадров показан на рисунке.

Флаг (7Eh)

Адрес Q.922

Управление

Дополнительное поле заполнения (00h)

NLPID

…

данные

…

FCS

Флаг (7Eh)

Кадр многопротокольной инкапсуляции Frame Relay

Адрес Q.922

2-октетный адрес, содержащий 10-битовое поле DLCI. В некоторых сетях адрес Q.922 может содержать 3 или 4 октета.

Управление

Поле управления Q.922. Если не согласовано иное значение для этого поля, используется принятое по умолчанию значение UI=0x03. Допускается использование XID (0xAF или 0xBF).

Байт заполнения

Используется для выравнивания оставшейся части кадра по границе слова (2 октета). Для заполнения может использоваться один или два октета, содержащие значение 0.

NLPID

Идентификатор протокола сетевого уровня, выдаваемый ISO или CCITT (ITU-T). Этот идентификатор задает инкапсулированный протокол.

FCS

2-байтовая контрольная сумма.

Существует два типа пакетов, передаваемых по сетям Frame Relay – маршрутизируемые пакеты и пакеты мостов. Эти пакеты отличаются форматами и, следовательно, должны содержать идентификатор, позволяющий получателю корректно интерпретировать содержимое пакетов. Индикатор типа кадра встраивается в заголовки SNAP и поле NLPID.

Для тех протоколов, которым не выделены значения NLPID, необходимо обеспечить механизм простой идентификации протокола. Существует значение NLPID, показывающее присутствие индикации в заголовке SNAP. Формат заголовка SNAP показан на рисунке.

Уникальный идентификатор организации (OUI)	Идентификатор протокола (PID)
3 байта	2 байта

Формат заголовка SNAP

Все станции должны быть способны принимать и корректно интерпретировать инкапсуляцию с помощью NLPID и заголовков SNAP для маршрутизируемых пакетов.

Трехоктетный идентификатор OUI указывает организацию, ответственную за администрирование идентификатора протокола (PID), следующего за полем OUI. Оба поля вместе позволяют идентифицировать протокол. Отметим, что OUI=0x00-00-00 указывает, что следующее за ним поле PID содержит значение EtherType.

Некоторые протоколы имеют выделенные для них значения NLPID, но в силу ограниченного числа значений NLPID эти идентификаторы выделяются не для всех протоколов. Когда пакет с таким протоколом (без NLPID) маршрутизируется через сеть Frame Relay, для поля NLPID используется значение 0x80, за которым следует SNAP. Если протокол связан с EtherType, используется OUI=0x00-00-00 и PID=EtherType для используемого протокола. Для выравнивания по границе слова в этом случае используется однобайтовое поле заполнения.

Другой тип трафика Frame Relay составляют пакеты мостов. Для инкапсуляции таких пакетов используется значение NLPID=80, указывающее на использование SNAP. Как и для других протоколов с инкапсуляцией SNAP используется один октет заполнения для выравнивания на границу слова. Заголовок SNAP, следующий за полем NLPID, идентифицирует формат пакета. Значение OUI, используемое при такой инкапсуляции равно 0x00-80-C2. Поле PID заголовка SNAP (два байта после OUI) определяет форму заголовка MAC, который следует после заголовка SNAP. В дополнение к этому PID показывает сохранение исходной контрольной суммы (FCS) в кадре моста.

Рубрика: Мир протоколов | Оставить комментарий

Интерфейс ATM TAXI

Опубликовано 29.01.2014 автором Nikolai Malykh

Интерфейс TAXI компании AMD обеспечивает физический уровень передачи информации со скоростью 100 Мб/с по многомодовому оптическому кабелю. Спецификации TAXI приведены в документах ATM Forum UNI 3.0. Частный интерфейс UNI несложен в использовании и поддержке и не требует каналов значительной протяженности передачи как в телекоммуникационных системах. Кроме того, TAXI позволяет воспользоваться имеющимися комплектами микросхем FDDI за счет применения одинаковой среды передачи и лазеров.

TAXI поддерживает такую же скорость передачи, как интерфейс FDDI (100 Мбит/с), однако не использует кольцевую архитектуру. Каналы строятся по типу «точка-точка» и работают в полнодуплексном режиме. 53-байтовые ячейки ATM передаются напрямую без использования кадров физического уровня.

Рубрика: Физические интерфейсы | Оставить комментарий

Интерфейс ATM 25 Мбит/с

Опубликовано 29.01.2014 автором Nikolai Malykh

Интерфейс ATM 25 Мбит/с работает со скоростью 25,6 Мбит/с по кабелям из скрученных пар (витая пара) в соответствии со спецификациями ATM Forum UNI. Интерфейс использует кодирование 4B/5B NRZI. Для подключения устройств служат разъемы RJ48.

Ниже приведена разводка контактов стандартного кабеля UTP 25Мбит/с:

Контакт	Прямой кабель	Кросс-кабель
1	Rx+ (tip)	Tx+ (tip)
2	Rx- (ring)	Tx- (ring)
7	Tx+ (tip)	Rx+ (tip)
8	Tx- (ring)	Rx- (ring)

Контакты 3, 4, 5 и 6 не используются.

Ниже приведена разводка контактов старого кабеля IBM:

Контакт	Прямой кабель	Кросс-кабель
3	Rx+ (tip)	Tx+ (tip)
4	Tx+ (tip)	Rx+ (tip)
5	Tx- (ring)	Rx- (ring)
6	Rx- (ring)	Tx- (ring)

Контакты 1, 2, 7 и 8 не используются.

Дополнительную информацию можно найти в спецификации ATM Forum Physical Interface Specification for 25.6 Mbps over Twisted Pair Cable, June 1995.

Генерация HEC

Генерация HEC с добавлением COSET.

Скрэмблирование ячеек

Все 53 байта ячейки ATM скрэмблируются пред их передачей, однако скрэмблирование можно отключить. При скрэмблировании используется полином x¹⁰+x⁷+1 и операция XOR для входящих данных каждые 4 периода синхронизации.

Очерчивание (delineation) ячеек

Очерчивание ячеек осуществляется с использованием кодирования 4B5B. X_X обозначает начало ячейки со сбросом скремблера;. X_4 — начало ячейки без сброса скремблера.

Синхросигнал 8 кГц

Маркер сигнализации передается на границе следующего октета после детектирования входящего синхросигнала. Синхронизация имеет более высокий приоритет, нежели другие сигналы.

Кодирование сигналов

Кодирование сигналов может быть запрещено. Все 53 байта ячейки кодируются перед передачей. Ниже приведены команды, передаваемые с использованием кодирования 4B5B:

X_X Начало ячейки со сбросом скремблера.

X_4 Начало ячейки без сброса скремблера.

X_8 Синхронизация.

Получение любых других команд интерпретируется как ошибка и может вести к отбрасыванию ячейки.

Разъем физической среды

Интерфейс 25 Мбит/с поддерживает кабели UTP категорий 3, 4, 5 с волновым сопротивлением 100 Ом.

Рубрика: Физические интерфейсы | Оставить комментарий

Интерфейс ATM SONET OC-3c/SDH STM-1

Опубликовано 29.01.2014 автором Nikolai Malykh

Передача информации со скоростью 155 Мбит/с через интерфейсы SONET или SDH чаще всего связана с ATM. SONET/SDH является частью спецификации ATM Forum UNI 3.0 и обеспечивает один из наиболее скоростных и популярных на сегодняшний день интерфейсов ATM.

При подключении к линиям SONET/SDH могут использоваться многомодовые и одномодовые оптические кабели для длины волны 1300 нм с разъемами SC, а также кабель UTP с разъемами RJ-45.

Ниже приведена стандартная разводка кабеля UTP 155.

Контакт	Прямой кабель	Кросс-кабель
1	Tx+ (tip)	Rx+ (tip)
2	Tx- (ring)	Rx- (ring)
7	Rx+ (tip)	Tx+ (tip)
8	Rx- (ring)	Tx- (ring)

Контакты 3, 4 и 5 не используются.

Оба интерфейса, и SONET (Synchronous Optical NETwork – синхронная оптическая сеть) и SDH (Synchronous Optical Hierarchy – синхронная цифровая иерархия) базируются на скоростях передачи, кратных 51,840 Мбит/с (STS-1). Кадр STS-1 можно представить как матрицу октетов размером девять строк на 90 столбцов. Первые три столбца используются для транспортной информации (Transport Overhead – TOH) — кадрирование, мониторинг ошибок, управление, указатели на содержимое. Оставшиеся 87 столбцов используются для передачи данных — первый столбец содержит маршрутную информацию (Path Overhead — POH). Указатель в TOH идентифицирует начало содержимого и называется конвертом (Synchronous Payload Envelope – SPE).

Скорости передачи OC-3c и STM-1 являются расширениями базовой скорости STS-1 и составляют 155,520 Мбит/с. Данные передаются в виде трех чередующихся кадров STS-1. Таким образом, кадр OC-3c состоит из 9 строк и 270 столбцов, 9 из которых являются TOH. ATM три кадра STS-1 связаны между собой в единый блок данных для повышения эффективности использования полосы. Один столбец из оставшихся 261 столбца используется для POH.

Содержимое может «плавать» внутри кадров OC-3c, если синхронизация при генерации данных не совпадает с синхронизацией при генерации служебной информации. Указатели в заголовках (overhead) всегда идентифицируют начальную точку содержимого.

Из 270 столбцов 10 используются для передачи служебной информации. Таким образом, реальная скорость передачи данных в OC-3c составляет 149,76 Мбит/с. Кроме того, каждая ячейка ATM содержит 5-байтовый заголовок, что ведет к дополнительному снижению скорости до 135,63 Мбит/с.

270 октетов 

Служебная информация секции

H1*

H2*

Служебная информация строки

POH

TOH

Конверт Synchronous

Payload Envelope (SPE)

Не используется ATM

Содерж..

(продолж.)

Структура кадра OC-3c

Служебная информация секции

A1, A2

Выравнивание кадра. Эти октеты содержат значение 0xF628. При получении кадра приемник определяет эти значения во входном потоке битов. Биты выравнивания не скрэмблируются.

C1

Идентификация STS-1. Поскольку OC-3c и STM-1 содержат три потока STS-1, три байта C1 содержат значения 0x01, 0x02 и 0x03 соответственно.

B1

Мониторинг ошибок секции. Это поле содержит контрольную сумму BIP-8 для всех битов в предыдущем кадре до скрэмблирования с использованием контроля на четность.

Служебная информация строки

B2

Мониторинг ошибок строки. Это поле содержит контрольную сумму BIP-24 для всех битов в служебной информации в строке предыдущего кадра с использованием контроля на четность.

H1 (биты 1-4)

Флаг новых данных, указывающий на изменение указателя), путь AIS.

H1 и H2 (биты 7-16)

Значение указателя, путь AIS. Эти поля указывают смещение между указателем и первым байтом содержимого в кадре. Изменения данного поля игнорируется до тех пор, пока не будут получены 3 раза подряд.

H1* и H2*

Индикаторы конкатенации, путь AIS.

H3

Указатель действия (используется для выравнивания частоты), путь AIS.

K2 (биты 6-8)

Сигналы AIS и FERF в линии, отмена FERF.

Z2

Сигнал FEBE в линии. Это поле показывает число ошибок B2 (BIP-24), обнаруженных в предыдущем интервале.

POH

J1

Трассировка маршрута STS. Этот байт используется для повторяющейся передачи 64-байтовой фиксированной строки, позволяющей приемному терминалу проверить состояние соединения с передатчиком. Содержимое данной строки не задано в спецификациях.

B3

Мониторинг ошибок маршрута. Контрольная сумма BIP-8, определяемая для всех битов данных предыдущего кадра до скрэмблирования с использованием контроля на четность.

C2

Индикатор уровня сигнала на маршруте. Содержит один из двух кодов:

0 — указывает на отсутствие содержимого в кадре STS.

1 — указывает на присутствие содержимого в кадре STS.

G1 (биты 1-4)

Ошибка FEBE на пути для мониторинга полнодуплексного маршрута в любой точке составного пути.

G1 (бит 5)

Сигнал «желтой тревоги» для маршрута, RDI (Remote Defect Indicator – индикатор удаленного дефекта) маршрута.

Дополнительную информацию можно найти в перечисленных ниже книгах:

The ATM Forum, ATM User-Network Interface Specifications 3.0 and 3.1, Prentice-Hall, 1993 and 1994.
Bell Communications Research Inc. (Bellcore), «Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria», TR-NWT-000253, December 1991.
American National Standards Institute (ANSI), «Digital Hierarchy — Optical Interface Rates and Formats Specifications (SONET)», T1.105, 1991.

Рубрика: Физические интерфейсы | Оставить комментарий

Интерфейс ATM E3

Опубликовано 29.01.2014 автором Nikolai Malykh

Интерфейс E3 работает на скорости 34,368 Мб/с по коаксиальному кабелю в соответствии со спецификациями ATM Forum UNI. E3 поддерживает PLCP и прямое отображение ячеек и соответствует стандартам G.751 и G.832. Интерфейс использует разъемы BNC.

Прямое отображение

Структура кадра E3 при использовании режима прямого отображения показана на рисунке. 59 столбцов и 9 строк составляют 530 октетов содержимого. 53 байта ячейки ATM помещаются в 59 байтов кадра E3. Между началом кадра при прямом отображении началом ячейки ATM не существует связи.

<——————————————————————————-> 530 байтов содержимого

53 байта ячейки ATM представлены следующим образом:


<——————————————————————————> 53 байта

Структура кадра E1 – прямое отображение

FA 1

Выравнивание кадра 1.

FA 2

Выравнивание кадра 2.

EM

Монитор ошибок, BIP-8.

TR

Трассировка (trail trace).

MA

Поддержка и адаптация (Maintenance and Adaptation).

NR

Сетевой оператор.

GC

Коммуникационный канал общего назначения.

PLCP

Кадр E3 PLCP обеспечивает передачу 9 ячеек ATM каждые 125 мксек. Таким образом, скорость передачи данных составляет 3,456 Мбит/с. Кадры PLCP представляют собой октеты, выровненные по 16 битовым границам в кадрах ITU-T G.751 E1. Связь между началом кадра PLCP и началом кадра E3 не задается. В конце каждого кадра PLCP помещается трейлер.

A1	A2	P8	Z3	Ячейка ATM
A1	A2	P7	Z2	Ячейка ATM
A1	A2	P6	Z1	Ячейка ATM
A1	A2	P5	F1	Ячейка ATM
A1	A2	P4	B1	Ячейка ATM
A1	A2	P3	G1	Ячейка ATM
A1	A2	P2	M1	Ячейка ATM
A1	A2	P1	M2	Ячейка ATM
A1	A2	P0	C1	Ячейка ATM	Трейлер
<—> 1	<—> 1	<—> 1	<—> 1	<—————————-> 53 байта	<——-> 17-21 байт

Структура кадра E3 при использовании отображения PLCP.

A-биты

Октет шаблона (pattern) кадрирования.

P-биты

Идентификатор маршрута.

C1

Счетчик битов заполнения.

M-биты

Управляющая информация SIP уровня 1.

G1

Состояние пути PLCP.

B-бит

Четность чередования битов (Bit-interlaved parity 8 — BIP-8).

F1-бит

Пользовательский канал PLCP.

Z-биты

Зарезервированы для использования в будущем.

Рубрика: Физические интерфейсы | Оставить комментарий

Интерфейс ATM E1

Опубликовано 29.01.2014 автором Nikolai Malykh

Интерфейс E1 работает на скорости 2 Мбит/с по коаксиальным кабелям в соответствии со спецификациями ATM Forum UNI. E1 поддерживает PLCP и прямое отображение ячеек и соответствует стандартам G.704, G.706, G.732. Интерфейс использует разъемы BNC.

Канал передачи E1 содержит 32 канала (0-31), каждый из которых обеспечивает скорость передачи 64 Кбит/с. Общая скорость передачи составляет 2,048 Мбит/с. Каналы 0 и 16 зарезервированы для функций управления, остальные каналы используются для передачи информации. Таким образом, полоса скорость передачи полезной информации составляет 1,920 Мб/с. Поскольку ATM использует 48 байтов из каждой ячейки размером 53 байта, результирующая скорость передачи информации составляет 1,738 Мбит/с.

Канал 0 служит для передачи информации F3-OAM, сигналов потери кадров или синхронизации, а также отвечает за передачу сообщений FERF и LOC. Канал 16 зарезервирован для сигнализации.

Прямое отображение

Прямое отображение ячеек ATM в кадры передачи E1 определяется рекомендацией CCITT G.804. Этот стандарт передачу ячеек ATM передаются в битах 9-28 и 137-356 (каналы 1-15 и 17-31, соответственно).

На рисунке приведена структура кадра E1 при использовании прямого отображения ячеек ATM. 53-байтовые ячейки начинаются ATM с заголовка и передаются в последовательных кадрах E1.

Канал 0				Канал сигнализации 16
256 битов/125 микросекунд 
			Заголовок

		Заголовок
					Заголовок
	Каналы 1-15 			Каналы 17-31 

Структура кадра E1 – прямое отображение

PLCP

Формат PLCP для E1 описан в стандарте ETSI ETS 300 213. Кадр E1 PLCP определяется как последовательность из 10 строк по 57 байтов каждая. К каждой 53-байтовой ячейке добавляется 4 байта для поддержки различных служебных функций.

Структура кадра E1 с отображением ячеек PLCP показана на рисунке.

1 	1 	1 	1 	53 байта 
A1	A2	P9	Z4	Первая ячейка ATM
A1	A2	P8	Z3	Ячейка ATM
A1	A2	P7	Z2	Ячейка ATM
A1	A2	P6	Z1	Ячейка ATM
A1	A2	P5	F1	Ячейка ATM
A1	A2	P4	B1	Ячейка ATM
A1	A2	P3	G1	Ячейка ATM
A1	A2	P2	M1	Ячейка ATM
A1	A2	P1	M2	Ячейка ATM
A1	A2	P0	C1	Последняя ячейка ATM

Структура кадра E1 при использовании отображения PLCP.

A-биты

Биты разделения.

P-биты

Идентификатор маршрута.

C1

Счетчик битов заполнения.

M-биты

Управляющая информация SIP уровеня 1.

G1

Состояние пути PLCP.

B1

Четность чередования битов (Bit-interlaved parity 8 — BIP-8)

F1

Пользовательский канал PLCP.

Z-биты

Зарезервированы для использования в будущем.

Тридцать каналов E1 из 32 доступных используются для передачи кадра PLCP. Оставшиеся 2 канала зарезервированы для кадрирования и сигнализации E1. Кадры PLCP представляют собой октеты, выровавненные на границы кадров E1; таким образом октет A1 первой строки кадра PLCP вставляется в первый временной интервал (тайм-слот) кадра E1.

Рубрика: Физические интерфейсы | Оставить комментарий

Интерфейс ATM DS-3

Опубликовано 29.01.2014 автором Nikolai Malykh

Интерфейс DS-3 работает на скорости 44,736 Мбит/с по коаксиальному кабелю и соответствует спецификациям ATM Forum UNI. DS- поддерживает PLCP и прямое отображение ячеек и соответствует стандартам C-bit/M23. Интерфейс использует разъемы BNC.

Существует три стандарта кадрирования DS-3 — M23, C-bit parity и SYNTRAN. При кадрировании C-bit parity данные передаются одним блоком без мультиплексирования и биты C не используются для заполнения, а служат для реализации иных функций. Схема мультиплексирования M23 обеспечивает возможность передачи семи каналов DS-2. Поскольку каждый канал DS-2 может содержать 4 канала DS-1, через канал DS-3 могут передаваться 28 каналов DS-1 (670 каналов DS-0). Формат сигнала DS-3 в результате является асинхронно-синхронной мультиплексируемой последовательностью.

Сигнал DS-3 делится на M-кадры размером 4760 битов. M-кадры делятся на 7 субкадров размером 680 битов. Далее каждый субкадр делится на 8 блоков по 85 битов каждый. Первый бит блока используется для управления, оставшиеся служат для передачи информации. Кадр содержит 56 битов, используемых для выравнивания M-кадров и субкадров, обеспечения мониторинга работы, передачи сигналов тревоги и реализации других функций.

На рисунке показана M-кадра DS-3. Продолжительность кадра составляет 106402 мксек, а скорость передачи данных — 5,720 Мбит/с.

<———————— 680 битов (8 блоков по 84 + 1 бит 

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

M (0)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

M (1)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

M (0)

84 бита содерж

F (1)

84 бита содерж

F (0)

84 бита содерж

F (0)

84 бита содерж

F (1)

84 бита содерж

M-кадр DS-3

C-бит

Первый бит M-кадра используется для идентификации используемой схемы кадрирования — 100 = SYNTRAN, 111 = C-бит, любое другое значение — M23. Оставшиеся C-биты используются для заполнения (dibble stuffing) или приложений режима кадрирования C-bit.

M-биты

Биты выравнивания мультикадров, находящиеся в пятом, шестом и седьмом субкадрах. M1=0, M2=1 и M3=0.

X-биты

Х-биты помещаются в начале первого и второго субкадров. Эти биты используются для сигналов тревоги (alarm) и внутри одного M-кадра должны быть идентичны (00 или 11). Х-биты могут использоваться для низкочастотной сигнализации, поскольку не могут изменяться чаще одного раза в секунду. Неиспользуемые поля X-битов должны иметь значение 00 (вставка значений 01 или 10 может стать причиной ошибки кадрирования).

P-биты

P-биты помещаются в начале третьего и четвертого субкадров и содержат информацию о четности. Допустимые значения – 11 или 00.

F-биты

Биты выравнивания идентифицирует позиции всех управляющих битов в субкадре. F1=1, F2=0, F3=0 и F4=1.

Кадрирование C-bit

Формат DS-3 C-bit parity был предложен компанией AT&T для повышения эффективности мониторинга удаленной стороны. В этом формате за счет использования битов заполнения в каждом удобном случае биты C можно использовать для реализации дополнительных функций:

Сигнал тревоги на удаленной стороне и сигнал управления (Far End Alarm and Control signal — FEAC). В этом случае C-биты используются для передачи аварийного сигнала или информации о состоянии от удаленных терминалов, а также для инициализации удаленных шлейфов DS-3 и DS-1. Эти сигналы представляют собой 16-битовые повторяющиеся слова, содержащие последовательность битов 0xxxxxx0 11111111. При отсутствии сигнала передаются слова, состоящие только из единиц. Код передается 10 раз или в течении времени действия аварийного сигнала (используется большее из двух значений продолжительности).
Не используется.
Информация о четности маршрута DS-3.
Блокировка ошибок на удаленной стороне.
Поддержка канала связи между терминалами (LAPD, подмножество Q.921).

Прямое отображение

При использовании режима прямого отображения для определения границ ячеек применяется метод очерчивания (delineation). Для очерчивания ячеек служит поле контрольной суммы (HEC) заголовка ячейки ATM. Контрольная сумма вычисляется по модулю 8 для первых 4 байтов заголовка ячейки. При выполнении очерчивания для определения границ ячеек принимается, что контрольная сумма HEC вычислена корректно.

Сначала отыскивается первый бит для корректной суммы HEC (состояние HUNT). После нахождения первого бита определяется граница ячейки (состояние PRESYNC) и поиск продолжается проверки корректности остальной части контрольной суммы. Если в группе принятых ячеек отсутствуют ячейки с ошибками HEC, декларируется переход в состояние SYNC. Данное состояние держится до тех пор, пока не будет получено некоторое количество последовательных ячеек с некорректной суммой HEC.

PLCP

Кадр DS-3 PLCP обеспечивает передачу 12 ячеек ATM каждые 125 мксек, обеспечивая скорость передачи данных 4,608 Мбит/с. Кадры PLCP выравниваются по полубайтам (nibble). В конце каждого кадра помещается трейлер. Число полубайтов (13 или 14) непрерывно изменяется для синхронизации кадров PLCP с частотой 8 кГц.

A1	A2	P11	Z6	Ячейка ATM
A1	A2	P10	Z5	Ячейка ATM
A1	A2	P9	Z4	Ячейка ATM
A1	A2	P8	Z3	Ячейка ATM
A1	A2	P7	Z2	Ячейка ATM
A1	A2	P6	Z1	Ячейка ATM
A1	A2	P5	F1	Ячейка ATM
A1	A2	P4	B1	Ячейка ATM
A1	A2	P3	G1	Ячейка ATM
A1	A2	P2	M1	Ячейка ATM
A1	A2	P1	M2	Ячейка ATM
A1	A2	P0	C1	Ячейка ATM	Трейлер
<—> 1	<—> 1	<—> 1	<—> 1	53 октета	13 или 14 полубайтов

Структура кадра DS-3 при использовании PLCP.

A-биты

Октеты маски кадрирования; A1 = F6, A2 = 28 (шестнадцатеричные значения).

P-биты

Идентификатор маршрута.

C1

Счетчик битов заполнения.

M-биты

Управляющая информация SIP уровня 1. Если M2 содержит поле Type=1, M1 содержит поле Type=0 и наоборот.

G1

Состояние пути PLCP.

Биты 1-4: код FEBE (до 8 возможных ошибок).

Бит 5: Сигнал «желтой тревоги». Такой сигнал подается при наличии сбоя на уровне маршрута PLCP (потеря PLCP-кадра) продолжительность 2,5 секунды. Если сбой прекращается на 15 секунд или больше, состояние «желтой тревоги» аннулируется.

Биты 6-8: Сигнал состояния канала (Link status signal — LLS):

Код LLS	Имя LLS	Состояние канала
000	Connected	Приемный канал подключен.
011	Rx_link_down	Приемный канал не работает, отсутствует сигнал на входе или канал отключен.
110	Rx_link_up	Приемный канал восстановлен.

B-бит

Ошибка Bip-8. Вычисляется для структуры 12 x 54 октетов, включающей Path Overhead и ячейку ATM. Байт G1 обеспечивает счетчик ошибок в предыдущих кадрах.

F1-бит

Пользовательский канал маршрута PLCP.

Z-биты

Для использования в будущем.

Рубрика: Физические интерфейсы | Оставить комментарий