RFC 5880 | Протокол двунаправленного обнаружения переадресации (BFD)

Аннотация

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

Скачать оригинальный документ на английском языке RFC 5880 PDF

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc5880.

Уведомление об авторских правах

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust, касающиеся документов IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

1. Введение

Все более важной особенностью сетевого оборудования является быстрое обнаружение сбоев связи между смежными системами для более быстрого определения альтернативных путей. Обнаружение может происходить довольно быстро при определенных обстоятельствах, когда оборудование линии передачи данных вступает в игру (например, сигналы тревоги синхронной оптической сети (SONET)). Тем не менее, существуют носители, которые не обеспечивают такого рода сигнализацию (например, Ethernet), и некоторые носители могут не обнаруживать определенные виды сбоев в тракте, например, сбойные интерфейсы или компоненты механизма пересылки.

В сетях используются относительно медленные механизмы «приветствия», обычно в протоколах маршрутизации, для обнаружения сбоев, когда отсутствует аппаратная сигнализация. Время обнаружения сбоев («Время обнаружения»), доступное в существующих протоколах, не лучше секунды, что слишком много для некоторых приложений и представляет значительную часть потерянных данных с гигабитной скоростью. Кроме того, протокол маршрутизации Hellos не поможет, когда эти протоколы маршрутизации не используются, а семантика обнаружения несколько отличается — они обнаруживают сбой на пути между двумя механизмами протокола маршрутизации.

Целью обнаружения двунаправленной пересылки (BFD) является обеспечение мало-затратного, кратковременного обнаружения отказов на пути между соседними механизмами пересылки, включая интерфейсы, канал (ы) передачи данных и, насколько это возможно, механизмы пересылки самих себя.

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

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

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

1.1. Соглашения, используемые в этом документе

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

2. Дизайн

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

BFD работает поверх любого протокола данных (сетевой уровень, канальный уровень, туннели и т. д.), Пересылаемого между двумя системами. Он всегда запускается в одноадресном режиме «точка-точка». Пакеты BFD передаются как полезная нагрузка любого инкапсулирующего протокола, подходящего для среды и сети. BFD может работать на нескольких уровнях в системе. Контекст операции любого конкретного сеанса BFD связан с его инкапсуляцией.

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

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

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

3. Обзор протокола

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

Путь объявляется работоспособным только тогда, когда между системами установлена двусторонняя связь, хотя это не исключает использование однонаправленных каналов.

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

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

3.1. Адресация и установление сессии

Сеанс BFD устанавливается на основе потребностей приложения, которое будет его использовать. Это зависит от приложения, чтобы определить необходимость BFD и адреса для использования — в BFD нет механизма обнаружения. Например, реализация OSPF [OSPF] может запросить установление сеанса BFD для соседа, обнаруженного с использованием протокола приветствия OSPF.

3.2. Режимы работы

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

Основной режим известен как асинхронный режим. В этом режиме системы периодически отправляют друг другу пакеты управления BFD, и, если количество этих пакетов в строке не получено другой системой, сеанс объявляется неработающим.

Второй режим называется режимом спроса. В этом режиме предполагается, что система имеет независимый способ проверки того, что она имеет связь с другой системой. Как только сеанс BFD установлен, такая система может попросить другую систему прекратить отправку пакетов управления BFD, за исключением случаев, когда система чувствует необходимость явной проверки возможности подключения, и в этом случае происходит обмен короткой последовательностью пакетов управления BFD, а затем Дальние системные перебои. Режим спроса может работать независимо в каждом направлении или одновременно.

Дополнением к обоим режимам является функция Echo. Когда функция Echo активна, поток эхо-пакетов BFD передается таким образом, чтобы другая система зациклила их обратно по пути пересылки. Если количество пакетов потока отраженных данных не получено, сеанс объявляется неработающим. Функция Echo может использоваться как в асинхронном, так и в режиме запроса. Поскольку функция Echo обрабатывает задачу обнаружения, скорость периодической передачи пакетов управления может быть уменьшена (в случае асинхронного режима) или полностью исключена (в случае режима запроса).

Чистый асинхронный режим имеет то преимущество, что для достижения определенного времени обнаружения требуется вдвое меньше пакетов, чем для функции эха. Он также используется, когда функция Echo по какой-либо причине не поддерживается.

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

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

Режим запроса полезен в ситуациях, когда издержки периодического протокола могут оказаться обременительными, например, в системе с очень большим количеством сеансов BFD. Это также полезно, когда функция Echo используется симметрично. Недостатком режима спроса является то, что времена обнаружения в основном определяются эвристикой реализации системы и не известны протоколу BFD. Режим по требованию может не использоваться, если время прохождения пути больше требуемого времени обнаружения или протокол не будет работать должным образом. См. Раздел 6.6 для более подробной информации.

4. Формат пакета управления BFD

4.1. Общий формат пакета управления BFD

Управляющие пакеты BFD отправляются в инкапсуляции, соответствующей среде. Конкретная инкапсуляция выходит за рамки данной спецификации. См. Соответствующий документ приложения для деталей инкапсуляции.

Пакет управления BFD имеет обязательную секцию и дополнительную секцию аутентификации. Формат секции аутентификации, если таковой имеется, зависит от типа используемой аутентификации.

Обязательный раздел пакета управления BFD имеет следующий формат:

Дополнительный раздел аутентификации МОЖЕТ присутствовать:

Версия (Vers)

Номер версии протокола. Этот документ определяет версию протокола 1.

Диагностика (Diag)

Диагностический код, указывающий причину последнего изменения состояния сеанса в локальной системе. Значения:

0 — нет диагностики
1 — Время обнаружения контроля истекло
2 — Сбой функции эха
3 — Соседская сигнальная сессия выключена
4 — Сброс плоскости пересылки
5 — Путь вниз
6 — Связанный путь вниз
7 — Административно вниз
8 — обратный каскадный путь вниз
9-31 — Зарезервировано для будущего использования

Это поле позволяет удаленным системам, например, определить причину сбоя предыдущего сеанса.

Состояние (Sta)

Текущее состояние сеанса BFD, видимое передающей системой. Значения:

0 — AdminDown
1 — Down
2 — Init
3 — Up

Опрос (P)

Если установлено, передающая система запрашивает подтверждение возможности соединения или изменения параметра и ожидает пакет с последним битом (F) в ответе. Если сброшено, передающая система не запрашивает подтверждение.

Финал (F)

Если установлено, передающая система отвечает на полученный контрольный пакет BFD, для которого установлен бит Poll (P). Если установлено, передающая система не отвечает на опрос.

Независимая плоскость управления (C)

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

Использование этого бита зависит от приложения и выходит за рамки данной спецификации. См. Конкретные спецификации приложений для деталей.

Настоящая аутентификация (A)

Если установлено, секция аутентификации присутствует, и сеанс должен быть аутентифицирован (подробнее см. Раздел 6.7).

Требование (D)

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

Многоточечный (М)

Этот бит зарезервирован для будущих многоадресных расширений BFD. Он ДОЛЖЕН быть нулевым как при передаче, так и при получении.

Обнаружение Mult (Detect Mult)

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

Длина (Length)

Длина контрольного пакета BFD, в байтах.

Мой дискриминатор (My Discriminator)

Уникальное ненулевое значение дискриминатора, генерируемое передающей системой, используется для демультиплексирования нескольких сеансов BFD между одной и той же парой систем.

Ваш дискриминатор (Your Discriminator)

Дискриминатор получен от соответствующей удаленной системы. Это поле отражает полученное значение My Discriminator или равно нулю, если это значение неизвестно.

Желаемый минимальный интервал TX (Desired Min TX Interval)

Это минимальный интервал в микросекундах, который локальная система хотела бы использовать при передаче контрольных пакетов BFD, за исключением примененного дрожания (см. Раздел 6.8.2). Нулевое значение зарезервировано.

Требуемый минимальный интервал приема (Required Min RX Interval)

Это минимальный интервал в микросекундах между полученными пакетами управления BFD, которые может поддерживать эта система, за исключением любого дрожания, примененного отправителем (см. Раздел 6.8.2). Если это значение равно нулю, передающая система не хочет, чтобы удаленная система отправляла какие-либо периодические контрольные пакеты BFD.

Требуется минимальный интервал эха RX (Required Min Echo RX Interval)

Это минимальный интервал в микросекундах между принятыми эхо-пакетами BFD, которые может поддерживать эта система, за исключением любого дрожания, примененного отправителем (см. Раздел 6.8.9). Если это значение равно нулю, передающая система не поддерживает прием эхо-пакетов BFD.

Тип аутентификации (Auth Type)

Используемый тип аутентификации, если установлен бит Authentication Present (A).

0 — зарезервировано
1 — простой пароль
2 — Ключ MD5
3 — Дотошный ключ MD5
4 — Ключ SHA1
5 — Тщательный ключ SHA1
6-255 — Зарезервировано для будущего использования

0 — Reserved
1 — Simple Password
2 — Keyed MD5
3 — Meticulous Keyed MD5
4 — Keyed SHA1
5 — Meticulous Keyed SHA1
6-255 — Reserved for future use

Длина аутентификации (Auth Len)

Длина в байтах секции аутентификации, включая поля Auth Type и Auth Len.

4.2. Формат раздела простой аутентификации по паролю

Если в заголовке установлен бит Authentication Present (A), а поле Authentication Type содержит 1 (простой пароль), секция Authentication имеет следующий формат:

Тип аутентификации (Auth Type)

Тип аутентификации, который в данном случае равен 1 (простой пароль).

Длина аутентификации (Auth Len)

Длина секции аутентификации в байтах. Для простой аутентификации по паролю длина равна длине пароля плюс три.

Идентификатор ключа авторизации (Auth Key ID)

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

Пароль (Password)

Простой пароль, используемый в этом сеансе. Пароль представляет собой двоичную строку и ДОЛЖЕН иметь длину от 1 до 16 байтов. Пароль ДОЛЖЕН быть закодирован и настроен в соответствии с разделом 6.7.2.

4.3. Формат раздела аутентификации с ключом MD5 и Meticulous Keyed MD5

Использование аутентификации на основе MD5 настоятельно не рекомендуется. Однако, здесь задокументировано для совместимости с существующими реализациями.

Если в заголовке установлен бит Authentication Present (A), а поле Authentication Type содержит 2 (MD5 с ключами) или 3 (MD5 с Meticulous Keyed), раздел аутентификации имеет следующий формат:

Тип аутентификации (Auth Type)

Тип аутентификации, который в данном случае равен 2 (с ключом MD5) или 3 (с ключом MD5).

Длина аутентификации (Auth Len)

Длина секции аутентификации в байтах. Для аутентификации Keyed MD5 и Meticulous Keyed MD5 длина составляет 24.

Идентификатор ключа авторизации (Auth Key ID)

Зарезервированный (Reserved)

Этот байт ДОЛЖЕН быть установлен равным нулю при передаче и игнорироваться при получении.

Порядковый номер (Sequence Number)

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

Auth Key / Digest

Это поле содержит 16-байтовый дайджест MD5 для пакета. Когда дайджест рассчитывается, общий ключ MD5 сохраняется в этом поле, дополняется до 16 байтов с конечными нулевыми байтами, если это необходимо. Общий ключ ДОЛЖЕН быть закодирован и настроен в соответствии с разделом 6.7.3.

4.4. Формат раздела аутентификации с ключом SHA1 и метаданным ключом SHA1

Если в заголовке установлен бит Authentication Present (A), а поле «Тип аутентификации» содержит 4 (SHA1 с ключами) или 5 (SHA1 с метилизованным ключом), секция аутентификации имеет следующий формат:

Тип аутентификации (Auth Type)

Тип аутентификации, который в данном случае равен 4 (SHA1 с ключом) или 5 (SHA1 с ключом).

Длина аутентификации (Auth Len)

Длина секции аутентификации в байтах. Для аутентификации с ключом SHA1 и Meticulous Keyed SHA1 длина составляет 28.

Идентификатор ключа авторизации (Auth Key ID)

Зарезервированный (Reserved)

Этот байт ДОЛЖЕН быть установлен равным нулю при передаче и игнорироваться при получении.

Порядковый номер (Sequence Number)

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

Auth Key / Hash

Это поле содержит 20-байтовый хэш SHA1 для пакета. Когда вычисляется хеш, общий ключ SHA1 сохраняется в этом поле, дополняя его длиной до 20 байтов, с последующими нулевыми байтами, если это необходимо. Общий ключ ДОЛЖЕН быть закодирован и настроен в соответствии с разделом 6.7.4.

5. Эхо-пакет BFD

Эхо-пакеты BFD отправляются в инкапсуляции, соответствующей среде. См. Соответствующие документы приложения для специфики конкретной среды.

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

СЛЕДУЕТ включать некоторую форму аутентификации, поскольку эхо-пакеты могут быть подделаны.

6. Элементы процедуры

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

Помните, что все ссылки в форме «bfd.Xx» относятся к внутренним переменным состояния (определенным в разделе 6.8.1), тогда как все ссылки на «поле Xxx» относятся к полям в самих пакетах протокола (определенных в разделе 4).

6.1. Обзор

Система может принимать либо активную роль, либо пассивную роль в инициализации сеанса. Система, принимающая активную роль, ДОЛЖНА отправлять пакеты управления BFD для определенного сеанса независимо от того, получила ли она какие-либо пакеты BFD для этого сеанса. Система, принимающая пассивную роль, НЕ ДОЛЖНА начинать отправку пакетов BFD для конкретного сеанса, пока она не получит пакет BFD для этого сеанса и, таким образом, не узнает значение дискриминатора удаленной системы. По крайней мере, одна система ДОЛЖНА принять активную роль (возможно, обе). Роль, которую система выполняет, специфична для применения BFD и выходит за рамки данной спецификации.

Сеанс начинается с периодической медленной передачи пакетов управления BFD. Когда двунаправленная связь достигнута, сеанс BFD становится Up.

Как только сеанс BFD активен, система может выбрать запуск функции Echo, если она этого пожелает, а другая система подает сигнал, что это разрешит. Скорость передачи пакетов управления обычно поддерживается на низком уровне, когда активна функция Echo.

Если функция эха не активна, скорость передачи пакетов управления может быть увеличена до уровня, необходимого для достижения требований времени обнаружения для сеанса.

Как только сеанс активирован, система может сигнализировать о том, что она вошла в режим запроса, и передача пакетов управления BFD удаленной системой прекращается. Другие средства, подразумевающие возможность подключения, используются для поддержки сеанса. Если любая из систем желает проверить двустороннюю связь, она может инициировать короткий обмен контрольными пакетами BFD («последовательность опроса»; см. Раздел 6.5) для этого.

Если режим по требованию не активен и контрольные пакеты не получены в течение рассчитанного времени обнаружения (см. Раздел 6.8.4), сеанс объявляется неработающим. Это сообщается удаленному концу через поле State (Sta) в исходящих пакетах.

Если потеряно достаточное количество эхо-пакетов, сеанс объявляется выключенным таким же образом. Смотрите раздел 6.8.5.

Если активен режим запроса и не получены соответствующие пакеты управления в ответ на последовательность опроса, сеанс объявляется выключенным таким же образом. Смотрите раздел 6.6.

Если сеанс выходит из строя, передача эхо-пакетов (если таковые имеются) прекращается, и передача пакетов управления возвращается к медленной скорости.

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

Сеанс МОЖЕТ быть заблокирован в административном режиме путем входа в состояние AdminDown и отправки пояснительного диагностического кода в поле Diagnostic.

6.2. BFD State Machine

Конечный автомат BFD довольно прост. Существует три состояния, через которые обычно проходит сеанс: два для установления сеанса (Init и Up) и одно для завершения сеанса (Down). Это допускает трехстороннее рукопожатие как для установления сеанса, так и для разрыва сеанса (гарантируя, что обе системы осведомлены обо всех изменениях состояния сеанса). Существует четвертое состояние (AdminDown), поэтому сеанс может быть отложен на неопределенный срок.

Каждая система сообщает свое состояние сеанса в поле State (Sta) в пакете управления BFD, и это полученное состояние в сочетании с локальным состоянием сеанса управляет конечным автоматом.

Неактивное состояние означает, что сеанс не работает (или только что был создан). Сеанс остается в неактивном состоянии до тех пор, пока удаленная система не покажет, что он согласен с тем, что сеанс не работает, путем отправки контрольного пакета BFD с полем состояния, для которого установлено любое другое значение, кроме Up. Если этот пакет сигнализирует о состоянии Down, сеанс переходит в состояние Init; если этот пакет сигнализирует о состоянии Init, сеанс переходит в состояние Up. Семантически, состояние Down указывает, что путь пересылки недоступен, и что приложения должны выполнять соответствующие действия, отслеживающие состояние сеанса BFD. Система МОЖЕТ удерживать сеанс в выключенном состоянии бесконечно (просто отказываясь продвигать состояние сеанса). Это может быть сделано по эксплуатационным или административным причинам, среди прочего.

Состояние инициализации означает, что удаленная система обменивается данными, и локальная система хочет запустить сеанс, но удаленная система еще не осознает этого. Сеанс будет оставаться в состоянии Init до тех пор, пока не будет получен пакет управления BFD, который сигнализирует о состоянии Init или Up (в этом случае сеанс переходит в состояние Up), или не истечет время обнаружения, означающее, что связь с удаленной системой была потеряна ( в этом случае сеанс переходит в состояние Down).

Состояние «вверх» означает, что сеанс BFD успешно установлен, и подразумевает, что соединение между системами работает. Сеанс будет оставаться в состоянии «Вверх» до тех пор, пока не произойдет сбой подключения или сеанс не будет отключен в административном порядке. Если удаленная система сигнализирует о выключенном состоянии или истекает время обнаружения, сеанс переходит в нерабочее состояние.

Состояние AdminDown означает, что сеанс удерживается административно. Это приводит к тому, что удаленная система переходит в нерабочее состояние и остается там до тех пор, пока локальная система не выйдет из состояния AdminDown. Состояние AdminDown не имеет семантических последствий для доступности пути пересылки.

Следующая диаграмма предоставляет обзор конечной машины состояний. Переходы, включающие состояние AdminDown, удалены для ясности (но полностью определены в разделах 6.8.6 и 6.8.16). Обозначения на каждой дуге представляют состояние удаленной системы (как получено в поле «Состояние» в пакете управления BFD) или указывают истечение таймера обнаружения.

Диаграмма обзора конечной машины состояний

6.3. Демультиплексирование и поля дискриминатора

Поскольку между двумя системами может выполняться несколько сеансов BFD, должен существовать механизм для демультиплексирования принятых пакетов BFD в соответствующий сеанс.

Каждая система ДОЛЖНА выбрать непрозрачное значение дискриминатора, которое идентифицирует каждый сеанс и которое ДОЛЖНО быть уникальным среди всех сеансов BFD в системе. Локальный дискриминатор отправляется в поле «Мой дискриминатор» в пакете управления BFD и возвращается в поле «Ваш дискриминатор» пакетов, отправленных с удаленного конца.

Как только удаленный конец отправляет обратно локальный дискриминатор, все последующие принятые пакеты демультиплексируются только на основе поля «Ваш дискриминатор» (это означает, что, среди прочего, поле адреса источника может измениться, или интерфейс, через который принимаются пакеты, может измениться, но пакеты все равно будут связаны с соответствующим сеансом).

Метод демультиплексирования исходных пакетов (в котором Ваш дискриминатор равен нулю) зависит от приложения и, таким образом, выходит за рамки данной спецификации.

Обратите внимание, что для системы допустимо изменять свой дискриминатор во время сеанса, не влияя на состояние сеанса, поскольку только эта система использует свой дискриминатор для целей демультиплексирования (если другая система отразит его обратно). Последствия для реализации для изменения значения дискриминатора выходят за рамки данной спецификации.

6.4. Эхо-функция и асимметрия

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

Когда система использует функцию Echo, выгодно выбирать частоту приема для пакетов управления, так как обнаружение живучести обрабатывается пакетами Echo. Это можно контролировать, манипулируя полем Required Min RX Interval (см. Раздел 6.8.3).

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

В противном случае система ДОЛЖНА объявить наименьшее значение необходимого минимального интервала приема и необходимого минимального интервала приема, которое она может в сложившихся обстоятельствах, чтобы дать другой системе больше свободы в выборе скорости передачи. Обратите внимание, что система обязуется принимать оба потока пакетов со скоростью, которую она объявляет, поэтому это следует учитывать при выборе значений для рекламы.

6.5. Последовательность опроса

Последовательность опроса — это обмен пакетами управления BFD, который используется в некоторых случаях, чтобы гарантировать, что удаленная система знает об изменениях параметров. Он также используется в режиме спроса (см. Раздел 6.6) для проверки двунаправленного подключения.

Последовательность опроса состоит из системы, отправляющей периодические контрольные пакеты BFD с установленным битом опроса (P). Когда другая система получает опрос, она немедленно передает контрольный пакет BFD с установленным битом Final (F) независимо от каких-либо периодических контрольных пакетов BFD, которые она может отправлять (см. Раздел 6.8.7). Когда система, отправляющая последовательность опроса, получает пакет с окончанием, последовательность опроса завершается, и любые последующие пакеты управления BFD отправляются с очищенным битом опроса. Пакет управления BFD НЕ ДОЛЖЕН иметь биты Poll (P) и Final (F).

Если периодические пакеты управления BFD уже отправляются (удаленная система не находится в режиме запроса), последовательность опросов ДОЛЖНА выполняться путем установки бита Poll (P) в этих запланированных периодических передачах; дополнительные пакеты НЕ ДОЛЖНЫ отправляться.

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

Как правило, вся последовательность состоит из одного пакета в каждом направлении, хотя потери пакетов или относительно длительные задержки пакетов могут привести к отправке нескольких пакетов опроса до завершения последовательности.

6.6. Режим спроса

Режим запроса запрашивается независимо в каждом направлении благодаря системе, устанавливающей бит Demand (D) в своих пакетах управления BFD. Система, принимающая бит запроса, прекращает периодическую передачу пакетов управления BFD. Если обе системы работают в режиме спроса, периодические контрольные пакеты BFD не будут передаваться ни в одном направлении.

Режим спроса требует, чтобы какой-то другой механизм использовался для обеспечения непрерывного соединения между двумя системами. Используемый механизм не обязательно должен быть одинаковым в обоих направлениях и выходит за рамки данной спецификации. Одним из возможных механизмов является получение трафика от удаленной системы; другое — использование функции Echo.

Когда система в режиме «Требование» желает проверить двунаправленную связь, она инициирует последовательность опроса (см. Раздел 6.5). Если на опрос не получен ответ, опрос повторяется до тех пор, пока не истечет время обнаружения, и в этот момент сеанс объявляется выключенным. Обратите внимание, что если режим запроса работает только в локальной системе, последовательность опроса выполняется путем простой установки бита опроса (P) в регулярных периодических пакетах управления BFD, как того требует раздел 6.5.

Время обнаружения в режиме спроса рассчитывается иначе, чем в асинхронном режиме; оно основано на скорости передачи локальной системы, а не на скорости передачи удаленной системы. Это гарантирует, что механизм последовательности опроса работает правильно. См. Раздел 6.8.4 для более подробной информации.

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

Режим запроса МОЖЕТ быть включен или отключен в любое время, независимо в каждом направлении, путем установки или очистки бита запроса (D) в пакете управления BFD, не влияя на состояние сеанса BFD. Обратите внимание, что бит запроса НЕ ДОЛЖЕН быть установлен, если только обе системы не воспримут, что сеанс активирован (локальная система считает, что сеанс активирован, а удаленная система в последний раз сообщила о состоянии «вверх» в поле «Состояние» (Sta) пакета управления BFD).

Когда необходимо изменить передаваемое значение бита запроса (D), передающая система ДОЛЖНА инициировать последовательность опроса в сочетании с изменением бита, чтобы гарантировать, что обе системы осведомлены об изменении.

Если режим запроса активен в одной или обеих системах, последовательность опроса ДОЛЖНА быть инициирована всякий раз, когда содержимое следующего отправляемого пакета управления BFD будет отличаться от содержимого предыдущего пакета, за исключением опроса (P) и Финальные (F) биты. Это гарантирует, что изменения параметров передаются в удаленную систему и что удаленная система подтверждает эти изменения.

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

Обратите внимание, что если режим спроса включен только в одном направлении, непрерывная проверка двунаправленного соединения теряется (будет проверяться только соединение в направлении от системы в режиме спроса к другой системе). Решение проблемы одной системы, запрашивающей режим «Спрос», в то время как другая требует непрерывной проверки двунаправленного соединения, выходит за рамки данной спецификации.

6.7. Аутентификация

Необязательная секция аутентификации МОЖЕТ присутствовать в пакете управления BFD. В своей общей форме целью Секции аутентификации является передача всей необходимой информации, основанной на используемом типе аутентификации, чтобы позволить принимающей системе определить достоверность принятого пакета. Точный механизм зависит от используемого типа аутентификации, но, как правило, передающая система помещает информацию в аутентификацию.

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

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

Обратите внимание, что в подразделах ниже «принять» пакет означает только то, что пакет прошел аутентификацию; на самом деле он может быть отброшен по другим причинам, как описано в общих правилах приема пакетов, описанных в разделе 6.8.6.

Реализации, поддерживающие аутентификацию, ДОЛЖНЫ поддерживать оба типа аутентификации SHA1. Другие формы аутентификации являются необязательными.

6.7.1. Включение и отключение аутентификации

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

В простой реализации сеанс BFD завершится неудачно, когда аутентификация либо включена, либо отключена, поскольку правила принятия пакетов по существу требуют, чтобы локальные и удаленные машины делали это более или менее синхронизированным образом (в течение времени обнаружения) — пакет с аутентификацией будет принят только в том случае, если аутентификация «используется» (и аналогично пакетам без аутентификации).

Один из возможных подходов состоит в том, чтобы создать реализацию, в которой аутентификация настроена, но не считается «используемой» до тех пор, пока не будет получен первый пакет, содержащий соответствующий раздел аутентификации (обеспечивая необходимую синхронизацию). Аналогично, аутентификация может быть отключена, но все еще считается «используемой» до получения первого пакета без секции аутентификации.

Чтобы избежать угроз безопасности, реализациям, использующим этот метод, СЛЕДУЕТ разрешать изменение состояния аутентификации не более одного раза без какого-либо вмешательства (так что аутентификация не может включаться и выключаться повторно просто на основании приема пакетов управления BFD от удаленного устройства). системы). Если не требуется включить или отключить аутентификацию, реализация НЕ ДОЛЖНА позволять изменению состояния аутентификации на основе приема пакетов управления BFD.

6.7.2. Простая аутентификация по паролю

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

Передача с использованием простой аутентификации по паролю

Выбранный в настоящее время пароль и идентификатор ключа для сеанса ДОЛЖНЫ храниться в разделе аутентификации каждого исходящего пакета управления BFD. Поле Auth Type ДОЛЖНО быть установлено в 1 (простой пароль). Поле Auth Len ДОЛЖНО быть установлено на правильную длину (от 4 до 19 байтов).

Пароль представляет собой двоичную строку и ДОЛЖЕН иметь длину от 1 до 16 байтов. Для обеспечения взаимодействия интерфейс управления, с помощью которого настроен пароль, ДОЛЖЕН принимать строки ASCII и ДОЛЖЕН также разрешать настройку любой произвольной двоичной строки в шестнадцатеричной форме. Другие методы настройки МОГУТ поддерживаться.

Прием с использованием простой аутентификации по паролю

Если полученный контрольный пакет BFD не содержит секции аутентификации или тип аутентификации не равен 1 (простой пароль), то полученный пакет ДОЛЖЕН быть отброшен.

Если поле Auth Key ID не совпадает с идентификатором настроенного пароля, полученный пакет ДОЛЖЕН быть отброшен.

Если поле Auth Len не равно длине пароля, выбранного идентификатором ключа, плюс три, пакет ДОЛЖЕН быть отброшен.

Если поле Пароль не соответствует паролю, выбранному идентификатором ключа, пакет ДОЛЖЕН быть отброшен.

В противном случае пакет ДОЛЖЕН быть принят.

6.7.3. Аутентификация с ключами MD5 и Meticulous Keyed MD5

Механизмы аутентификации с ключом MD5 и Meticulous Keyed MD5 очень похожи на те, которые используются в других протоколах. В этих методах аутентификации один или несколько секретных ключей (с соответствующими идентификаторами ключей) настраиваются в каждой системе. Один из ключей включен в дайджест MD5 [MD5], рассчитанный для исходящего пакета управления BFD, но сам ключ не переносится в пакете. Чтобы избежать атак воспроизведения, в каждом пакете также указан порядковый номер. Для Keyed MD5 порядковый номер иногда увеличивается. Для Meticulous Keyed MD5 порядковый номер увеличивается для каждого пакета.

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

Передача с использованием Keyd MD5 и аутентификации Meticulous Keyed MD5

Поле Тип аутентификации ДОЛЖНО быть установлено на 2 (с ключом MD5) или 3 (с ключом MD5). Поле Auth Len ДОЛЖНО быть установлено равным 24. Поле Auth Key ID ДОЛЖНО быть установлено для идентификатора текущего ключа аутентификации. Поле порядкового номера ДОЛЖНО быть установлено в bfd.XmitAuthSeq.

Значение ключа аутентификации представляет собой двоичную строку длиной до 16 байтов, и ДОЛЖНО быть помещено в поле Auth Key / Digest, дополненное по необходимости нулевыми байтами. Для обеспечения взаимодействия интерфейс управления, с помощью которого настроен ключ, ДОЛЖЕН принимать строки ASCII и ДОЛЖЕН также разрешать настройку любой произвольной двоичной строки в шестнадцатеричной форме. Другие методы настройки МОГУТ поддерживаться.

Дайджест MD5 ДОЛЖЕН быть рассчитан на весь контрольный пакет BFD. Полученный дайджест ДОЛЖЕН быть сохранен в поле Auth Key / Digest до передачи (замена секретного ключа, который НЕ ДОЛЖЕН переноситься в пакете).

Для Keyed MD5 значение bfd.XmitAuthSeq МОЖЕТ быть увеличено по кругу (когда рассматривается как 32-разрядное значение без знака). bfd.XmitAuthSeq СЛЕДУЕТ увеличивать при изменении состояния сеанса или когда переданный контрольный пакет BFD несет содержимое, отличное от ранее переданного пакета. Решение о том, когда увеличивать bfd.XmitAuthSeq, выходит за рамки данной спецификации. См. Раздел «Вопросы безопасности» ниже для обсуждения.

Для MD5 с Meticulous Keyed, bfd.XmitAuthSeq ДОЛЖЕН увеличиваться по кругу (когда рассматривается как 32-разрядное значение без знака).

Квитанция с использованием Keyed MD5 и Meticulous Keyed MD5 Authentication

Если полученный контрольный пакет BFD не содержит секции аутентификации или тип аутентификации неверен (2 для MD5 с ключом или 3 для MD5 с тщательным ключом), то полученный пакет ДОЛЖЕН быть отброшен.

Если поле Auth Key ID не совпадает с идентификатором настроенного ключа аутентификации, полученный пакет ДОЛЖЕН быть отброшен. Если поле Auth Len не равно 24, пакет ДОЛЖЕН быть отброшен.

Если bfd.AuthSeqKnown равен 1, проверьте поле порядкового номера. Для ключа MD5, если порядковый номер находится за пределами диапазона от bfd.RcvAuthSeq до bfd.RcvAuthSeq + (3 * Detect Mult) включительно (при обработке как 32-разрядное круговое пространство без знака), полученный пакет ДОЛЖЕН быть отброшен. Для Meticulous Keyed MD5, если порядковый номер находится за пределами диапазона от bfd.RcvAuthSeq + 1 до bfd.RcvAuthSeq + (3 * Detect Mult) включительно (при обработке как 32-битное пространство без знака с круговыми числами), полученный пакет ДОЛЖЕН быть отброшен.

В противном случае (bfd.AuthSeqKnown равен 0), bfd.AuthSeqKnown ДОЛЖЕН быть установлен в 1, а bfd.RcvAuthSeq ДОЛЖЕН быть установлен в значение полученного поля порядкового номера.

Замените содержимое поля Auth Key / Digest на ключ аутентификации, выбранный в полученном поле Auth Key ID. Если дайджест MD5 всего пакета управления BFD равен принятому значению поля Auth Key / Digest, принятый пакет ДОЛЖЕН быть принят. В противном случае (дайджест не соответствует полю Auth Key / Digest), полученный пакет ДОЛЖЕН быть отброшен.

6.7.4. Аутентификация SHA1 с ключами и аутентификация SHA1 с точными ключами

Механизмы аутентификации с ключом SHA1 и Meticulous Keyed SHA1 очень похожи на те, которые используются в других протоколах. В этих методах аутентификации один или несколько секретных ключей (с соответствующими идентификаторами ключей) настраиваются в каждой системе. Один из ключей включен в хеш SHA1 [SHA1], рассчитанный для исходящего пакета управления BFD, но сам ключ не переносится в пакете. Чтобы избежать атак воспроизведения, в каждом пакете также указан порядковый номер. Для ключевого SHA1 порядковый номер иногда увеличивается. Для Meticulous Keyed SHA1 порядковый номер увеличивается на каждый пакет.

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

Передача с использованием SHA1 с ключами и аутентификации SHA1 с точным ключом

Поле Auth Type ДОЛЖНО быть установлено на 4 (с ключом SHA1) или 5 (с ключом SHA1). Поле Auth Len ДОЛЖНО быть установлено на 28. Поле Auth Key ID ДОЛЖНО быть установлено на идентификатор текущего ключа аутентификации. Поле порядкового номера ДОЛЖНО быть установлено в bfd.XmitAuthSeq.

Значение ключа аутентификации представляет собой двоичную строку длиной до 20 байтов, и ДОЛЖНО быть помещено в поле Auth Key / Hash, дополнив его необходимыми нулевыми байтами. Для обеспечения взаимодействия интерфейс управления, с помощью которого настроен ключ, ДОЛЖЕН принимать строки ASCII и ДОЛЖЕН также разрешать настройку любой произвольной двоичной строки в шестнадцатеричной форме. Другие методы настройки МОГУТ поддерживаться.

Хэш SHA1 ДОЛЖЕН быть рассчитан для всего пакета управления BFD. Полученный хэш ДОЛЖЕН быть сохранен в поле Auth Key / Hash до передачи (замена секретного ключа, который НЕ ДОЛЖЕН переноситься в пакете).

Для ключевого SHA1 значение bfd.XmitAuthSeq МОЖЕТ быть увеличено по кругу (когда рассматривается как 32-разрядное значение без знака). bfd.XmitAuthSeq СЛЕДУЕТ увеличивать при изменении состояния сеанса или когда переданный контрольный пакет BFD несет содержимое, отличное от ранее переданного пакета. Решение о том, когда увеличивать bfd.XmitAuthSeq, выходит за рамки данной спецификации. См. Раздел «Вопросы безопасности» ниже для обсуждения.

Для SHA1 с Meticulous Keyed, bfd.XmitAuthSeq ДОЛЖЕН увеличиваться по кругу (когда рассматривается как 32-разрядное значение без знака).

Квитанция с использованием аутентификации по ключу SHA1 и аутентификации по метаданным ключам SHA1

Если полученный контрольный пакет BFD не содержит секции аутентификации или тип аутентификации неверен (4 для SHA1 с ключами или 5 для SHA1 с метиликой), то полученный пакет ДОЛЖЕН быть отброшен.

Если поле Auth Key ID не совпадает с идентификатором настроенного ключа аутентификации, полученный пакет ДОЛЖЕН быть отброшен.

Если поле Auth Len не равно 28, пакет ДОЛЖЕН быть отброшен.

Если bfd.AuthSeqKnown равен 1, проверьте поле порядкового номера. Для SHA1 с ключом, если порядковый номер находится за пределами диапазона от bfd.RcvAuthSeq до bfd.RcvAuthSeq + (3 * Detect Mult) включительно (при обработке как 32-разрядное круговое пространство без знака), полученный пакет ДОЛЖЕН быть отброшен. Для SHA1 с Meticulous Keyed, если порядковый номер находится за пределами диапазона от bfd.RcvAuthSeq + 1 до bfd.RcvAuthSeq + (3 * Detect Mult) включительно (при обработке как 32-битное пространство без знака с круговыми числами, полученный пакет ДОЛЖЕН быть отброшен.

В противном случае (bfd.AuthSeqKnown равен 0), bfd.AuthSeqKnown ДОЛЖЕН быть установлен в 1, bfd.RcvAuthSeq ДОЛЖЕН быть установлен в значение поля полученного номера последовательности, и принятый пакет ДОЛЖЕН быть принят.

Замените содержимое поля Auth Key / Hash на ключ аутентификации, выбранный в полученном поле Auth Key ID. Если хэш SHA1 всего пакета управления BFD равен принятому значению поля Auth Key / Hash, полученный пакет ДОЛЖЕН быть принят. В противном случае (хеш не совпадает с полем Auth Key / Hash), полученный пакет ДОЛЖЕН быть отброшен.

6.8. Функциональные особенности

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

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

Когда говорят, что локальная система имеет «активный режим запроса», это означает, что bfd.DemandMode равен 1 в локальной системе (см. Раздел 6.8.1), сеанс активирован, а удаленная система сигнализирует, что сеанс находится в состояние Up.

Когда говорят, что в удаленной системе активен «режим запроса», это означает, что bfd.RemoteDemandMode равен 1 (удаленная система установила бит Demand (D) в последнем принятом контрольном пакете BFD), сеанс активирован, а удаленный Система сигнализирует, что сеанс находится в состоянии Up.

6.8.1. Переменные состояния

Для отслеживания элементов процедуры, описанных здесь, необходимо отслеживать минимальное количество информации о сеансе. Ниже приведен набор переменных состояния, которые полезны при описании механизмов BFD. Любые средства отслеживания этого состояния могут использоваться при условии, что протокол ведет себя так, как описано.

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

Как только состояние сеанса создано и по меньшей мере один контрольный пакет BFD получен с удаленного конца, он ДОЛЖЕН быть сохранен в течение по меньшей мере одного времени обнаружения (см. Раздел 6.8.4) после получения последнего контрольного пакета BFD независимо от состояние сеанса. Это сохраняет параметры синхронизации на случай, если сеанс завершится. Система МОЖЕТ сохранять состояние сеанса дольше, чем это. Сохранение или уничтожение состояния сеанса, когда от удаленной системы не было получено пакетов управления BFD для этого сеанса, выходит за рамки данной спецификации.

Все переменные состояния в этой спецификации имеют форму «bfd.Xx» и не должны быть перепутаны с полями, переносимыми в пакетах протокола, которые всегда прописаны, чтобы соответствовать именам в разделе 4.

bfd.SessionState

Воспринимаемое состояние сеанса (Init, Up, Down или AdminDown). Точное действие, предпринимаемое при изменении состояния сеанса, выходит за рамки данной спецификации, хотя ожидается, что об этом изменении состояния (в частности, в состояние Up и из него) сообщается другим компонентам системы. Эта переменная ДОЛЖНА быть инициализирована как Down.

bfd.RemoteSessionState

Состояние сеанса в последний раз сообщалось удаленной системой в поле State (Sta) пакета управления BFD. Эта переменная ДОЛЖНА быть инициализирована как Down.

bfd.LocalDiscr

Локальный дискриминатор для этого сеанса BFD, используется для его уникальной идентификации. Он ДОЛЖЕН быть уникальным для всех сеансов BFD в этой системе и отличным от нуля. Это ДОЛЖНО быть установлено на случайное (но все еще уникальное) значение для повышения безопасности. В противном случае значение выходит за рамки данной спецификации.

bfd.RemoteDiscr

Удаленный дискриминатор для этого сеанса BFD. Это дискриминатор, выбранный удаленной системой, и он полностью непрозрачен для локальной системы. Это ДОЛЖНО быть инициализировано в ноль. Если период времени обнаружения проходит без получения действительного аутентифицированного пакета BFD от удаленной системы, эта переменная ДОЛЖНА быть установлена на ноль.

bfd.LocalDiag

Диагностический код, указывающий причину самого последнего изменения в состоянии локального сеанса. Это ДОЛЖНО быть инициализировано в ноль (без диагностики).

bfd.DesiredMinTxInterval

Минимальный интервал в микросекундах между передаваемыми контрольными пакетами BFD, которые эта система хотела бы использовать в текущий момент времени, за вычетом примененного дрожания (см. Раздел 6.8.2). Фактический интервал согласовывается между двумя системами. Это ДОЛЖНО быть инициализировано значением не менее одной секунды (1 000 000 микросекунд) в соответствии с правилами, описанными в разделе 6.8.3. В противном случае настройка этой переменной выходит за рамки данной спецификации.

bfd.RequiredMinRxInterval

Минимальный интервал в микросекундах между полученными пакетами управления BFD, который требуется этой системе, за вычетом любого дрожания, примененного отправителем (см. Раздел 6.8.2). Установка этой переменной выходит за рамки данной спецификации. Нулевое значение означает, что эта система не хочет получать какие-либо периодические контрольные пакеты BFD. Смотрите раздел 6.8.18 для деталей.

bfd.RemoteMinRxInterval

Последнее значение Required Min RX Interval, полученное от удаленной системы в пакете управления BFD. Эта переменная ДОЛЖНА быть инициализирована в 1.

bfd.DemandMode

Установите 1, если локальная система желает использовать режим спроса, или 0, если нет.

bfd.RemoteDemandMode

Установите значение 1, если удаленная система желает использовать режим запроса, или 0, если нет. Это значение бита запроса (D) в последнем принятом контрольном пакете BFD. Эта переменная ДОЛЖНА быть инициализирована нулем.

bfd.DetectMult

Требуемый множитель времени обнаружения для пакетов управления BFD в локальной системе. Согласованный интервал передачи пакета управления, умноженный на эту переменную, будет временем обнаружения для этого сеанса (как видно из удаленной системы). Эта переменная ДОЛЖНА быть ненулевым целым числом и в противном случае выходит за рамки данной спецификации. См. Раздел 6.8.4 для получения дополнительной информации.

bfd.AuthType

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

bfd.RcvAuthSeq

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

bfd.XmitAuthSeq

32-разрядное целое число без знака, содержащее следующий порядковый номер для аутентификации по ключу MD5 или SHA1, подлежащей передаче. Эта переменная ДОЛЖНА быть инициализирована случайным 32-битным значением.

bfd.AuthSeqKnown

Установите в 1, если известен следующий порядковый номер для аутентификации с ключом MD5 или SHA1, который ожидается получить, или в 0, если он не известен. Эта переменная ДОЛЖНА быть инициализирована нулем.

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

6.8.2. Переговоры по таймеру

Значения времени, используемые для определения интервалов передачи пакетов BFD, и времени обнаружения сеанса непрерывно согласовываются и, таким образом, могут быть изменены в любое время. Значения согласования и времени независимы в каждом направлении для каждого сеанса.

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

См. Раздел 6.8.7 для подробной информации о времени передачи пакета и согласовании.

6.8.3. Таймер манипуляции

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

Если либо bfd.DesiredMinTxInterval изменяется, либо bfd.RequiredMinRxInterval изменяется, ДОЛЖНА быть инициирована последовательность опроса (см. Раздел 6.5). Если время таково, что система, получающая последовательность опроса, желает изменить параметры, описанные в этом параграфе, новые значения параметров МОГУТ переноситься в пакетах с установленным битом Final (F), даже если последовательность опроса еще не была отправлена.

Если bfd.DesiredMinTxInterval увеличивается, а bfd.SessionState имеет значение Up, фактический используемый интервал передачи НЕ ДОЛЖЕН изменяться, пока последовательность опроса, описанная выше, не будет завершена. Это необходимо для того, чтобы удаленная система обновила время обнаружения до того, как увеличится интервал передачи.

Если bfd.RequiredMinRxInterval уменьшен, а bfd.SessionState имеет значение Up, предыдущее значение bfd.RequiredMinRxInterval ДОЛЖНО использоваться при вычислении времени обнаружения для удаленной системы, пока описанная выше последовательность опросов не будет завершена. Это должно гарантировать, что удаленная система передает пакеты с более высокой скоростью (и эти пакеты принимаются) до сокращения времени обнаружения.

Когда bfd.SessionState не активен, система ДОЛЖНА установить для bfd.DesiredMinTxInterval значение не менее одной секунды (1 000 000 микросекунд). Это предназначено для того, чтобы гарантировать, что полоса пропускания, потребляемая сеансами BFD, которые не работают, незначительна, особенно в случае, когда сосед может не использовать BFD.

Если локальная система уменьшает свой интервал передачи из-за уменьшения bfd.RemoteMinRxInterval (удаленная система объявила о пониженном значении в поле «Требуемый минимальный интервал RX»), а удаленная система не находится в режиме по требованию, локальная система ДОЛЖНА немедленно выполнить новый интервал. , Другими словами, локальная система не может ждать дольше, чем новый интервал между предыдущей передачей пакета и следующим. Если этот интервал уже прошел с момента последней передачи (поскольку новый интервал значительно короче), локальная система ДОЛЖНА отправить следующий периодический контрольный пакет BFD как можно скорее.

Когда функция Echo активна, система ДОЛЖНА установить значение bfd.RequiredMinRxInterval не менее одной секунды (1 000 000 микросекунд). Это предназначено для поддержания полученного трафика управления BFD на незначительном уровне, поскольку фактическая функция обнаружения выполняется с использованием эхо-пакетов BFD.

В любом случае, кроме тех, которые явно указаны выше, изменения параметров синхронизации ДОЛЖНЫ производиться немедленно (изменение скорости передачи и / или времени обнаружения).

Обратите внимание, что механизм последовательности опроса является неоднозначным, если выполняется более одного изменения параметра, что потребует его использования, и эти множественные изменения распределяются по нескольким пакетам (поскольку семантика возвращающего Final неясна). Следовательно, если внесены множественные изменения, требующие использования последовательности опроса, существует три варианта: 1) они ДОЛЖНЫ быть переданы в одном контрольном пакете BFD (поэтому семантика окончательного ответа ясна), или 2) достаточное время должно было произойти, так как последовательность опроса была завершена, чтобы устранить неоднозначность ситуации (по крайней мере, время прохождения туда-обратно с момента передачи последнего опроса) до инициирования другой последовательности опроса, или 3) дополнительного пакета управления BFD с конечным (F) бит * clear * ДОЛЖЕН быть получен после того, как последовательность опроса завершена до начала другой последовательности опроса (эта опция недоступна, когда активен режим запроса).

6.8.4. Расчет времени обнаружения

Время обнаружения (период времени без получения пакетов BFD, после которого определено, что сеанс потерпел неудачу) явно не указывается в протоколе. Скорее, он рассчитывается независимо в каждом направлении принимающей системой на основе согласованного интервала передачи и умножителя обнаружения. Обратите внимание, что могут быть разные времена обнаружения в каждом направлении.

Расчет времени обнаружения немного отличается в режиме спроса и асинхронного режима.

В асинхронном режиме время обнаружения, рассчитанное в локальной системе, равно значению обнаружения множества, полученного от удаленной системы, умноженному на согласованный интервал передачи удаленной системы (большее из bfd.RequiredMinRxInterval и последнего полученного требуемого минимального времени передачи Интервал). Значение Detect Mult представляет собой (грубо говоря, из-за дрожания) количество пакетов, которые необходимо пропустить в строке, чтобы объявить сеанс неработающим.

Если режим по требованию не активен, и период времени, равный времени обнаружения, проходит без получения контрольного пакета BFD из удаленной системы, а bfd.SessionState имеет значение Init или Up, сеанс завершился — локальная система ДОЛЖНА установить bfd.SessionState для Down и bfd.LocalDiag в 1 (истекло время обнаружения элемента управления).

В режиме запроса время обнаружения, рассчитанное в локальной системе, равно bfd.DetectMult, умноженному на согласованный интервал передачи локальной системы (большее из bfd.DesiredMinTxInterval и bfd.RemoteMinRxInterval). bfd.DetectMult — это (грубо говоря, из-за дрожания) количество пакетов, которые необходимо пропустить в строке, чтобы объявить сеанс неработающим.

Если режим запроса активен и период времени, равный времени обнаружения, проходит после инициирования последовательности опроса (передача первого пакета управления BFD с установленным битом опроса), сеанс завершается — локальная система ДОЛЖЕН установить для bfd.SessionState значение Down, а для bfd.LocalDiag значение 1 (время обнаружения элемента управления истекло).

(Обратите внимание, что пакет считается полученным для целей истечения времени обнаружения, только если он не был «отброшен» в соответствии с правилами раздела 6.8.6).

6.8.5. Обнаружение сбоев с помощью функции эха

Когда функция Echo активна и достаточное количество пакетов Echo не поступило должным образом, сеанс прервался — локальная система ДОЛЖНА установить для bfd.SessionState значение Down, а для bfd.LocalDiag — 2 (функция Echo Failed).

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

6.8.6. Прием контрольных пакетов BFD

Когда пакет управления BFD получен, ДОЛЖНА быть выполнена следующая процедура в указанном порядке. Если пакет отбрасывается в соответствии с этими правилами, обработка пакета ДОЛЖНА быть прекращена в этот момент.

Если номер версии неверен (1), пакет ДОЛЖЕН быть отброшен.

Если поле длины меньше минимального правильного значения (24, если бит A сброшен, или 26, если бит A установлен), пакет ДОЛЖЕН быть отброшен.

Если поле длины больше полезной нагрузки протокола инкапсуляции, пакет ДОЛЖЕН быть отброшен.

Если поле Detect Mult равно нулю, пакет ДОЛЖЕН быть отброшен.

Если многоточечный (M) бит ненулевой, пакет ДОЛЖЕН быть отброшен.

Если поле My Discriminator равно нулю, пакет ДОЛЖЕН быть отброшен.

Если поле «Ваш дискриминатор» отлично от нуля, оно ДОЛЖНО использоваться для выбора сеанса, с которым связан этот пакет BFD. Если сеанс не найден, пакет ДОЛЖЕН быть отброшен.

Если поле «Ваш дискриминатор» равно нулю, а поле «Состояние» не равно «Вниз» или «AdminDown», пакет ДОЛЖЕН быть отброшен.

Если поле «Ваш дискриминатор» равно нулю, сеанс ДОЛЖЕН быть выбран на основе некоторой комбинации других полей, возможно, включая информацию об адресации источника, поле «Мой дискриминатор» и интерфейс, через который был получен пакет. Точный метод выбора зависит от приложения и, следовательно, выходит за рамки данной спецификации. Если соответствующий сеанс не найден, МОЖЕТ быть создан новый сеанс или МОЖЕТ быть отброшен пакет. Этот выбор выходит за рамки данной спецификации.

Если бит A установлен и аутентификация не используется (bfd.AuthType равен нулю), пакет ДОЛЖЕН быть отброшен.

Если бит A сброшен и используется аутентификация (bfd.AuthType не равен нулю), пакет ДОЛЖЕН быть отброшен.

Если бит A установлен, пакет ДОЛЖЕН быть аутентифицирован в соответствии с правилами раздела 6.7 на основе используемого типа аутентификации (bfd.AuthType). Это может привести к тому, что пакет будет отброшен.

Установите для bfd.RemoteDiscr значение My Discriminator.

Установите для bfd.RemoteState значение поля State (Sta).

Установите для bfd.RemoteDemandMode значение бита Demand (D).

Установите для bfd.RemoteMinRxInterval значение Обязательного минимального интервала приема.

Если поле Required Min Echo RX Interval равно нулю, передача эхо-пакетов, если таковые имеются, ДОЛЖНА быть прекращена.

Если последовательность опроса передается локальной системой, и последний бит (F) в принятом пакете установлен, последовательность опроса ДОЛЖНА быть завершена.

Обновите интервал передачи, как описано в разделе 6.8.2.

Обновите Время обнаружения, как описано в разделе 6.8.4.

Если bfd.SessionState — AdminDown, (Откажитесь от пакета)

Если получено состояние AdminDown
—Если bfd.SessionState не выключен
—-Установите для bfd.LocalDiag значение 3 (Сеанс оповещения о соседе не работает)
—-Установите для bfd.SessionState значение Down.

Иначе

-Если bfd.SessionState выключен
—Если полученное состояние не работает
—-Установите bfd.SessionState в значение Init
—В противном случае, если получено, государство является инициатором
—-Установите для bfd.SessionState значение Up.

-Иначе, если bfd.SessionState — Init
—Если полученное состояние — Инициализация или Вверх
——Установите для bfd.SessionState значение Up.

-Иначе (bfd.SessionState is Up)
—Если полученное состояние не работает
——Установите для bfd.LocalDiag значение 3 (Сеанс оповещения о соседе не работает)
——Установите для bfd.SessionState значение Down.

Проверьте, должен ли режим спроса активироваться или нет (см. Раздел 6.6).

Если bfd.RemoteDemandMode равен 1, bfd.SessionState — «Вверх», а «bfd.RemoteSessionState» — «Вверх», то режим «Запрос» активен в удаленной системе, и локальная система ДОЛЖНА прекратить периодическую передачу пакетов управления BFD (см. Раздел 6.8.7).

Если bfd.RemoteDemandMode равен 0, или bfd.SessionState не Up, или bfd.RemoteSessionState не Up, режим запроса не активен в удаленной системе, и локальная система ДОЛЖНА отправлять периодические пакеты управления BFD (см. Раздел 6.8.7).

Если бит Poll (P) установлен, отправьте пакет управления BFD в удаленную систему с очищенным битом Poll (P) и установленным битом Final (F) (см. Раздел 6.8.7).

Если пакет не был отброшен, он был получен в соответствии с правилами истечения времени обнаружения в разделе 6.8.4.

6.8.7. Передача контрольных пакетов BFD

За исключением исключений, перечисленных в оставшейся части этого раздела, система НЕ ДОЛЖНА передавать пакеты управления BFD с интервалом, меньшим, чем большее из bfd.DesiredMinTxInterval и bfd.RemoteMinRxInterval, с меньшим применяемым джиттером (см. Ниже). Другими словами, система, сообщающая о более низкой скорости, определяет скорость передачи.

Периодическая передача пакетов управления BFD ДОЛЖНА быть смещена в каждом пакете до 25%, то есть интервал ДОЛЖЕН быть уменьшен на случайное значение от 0 до 25%, чтобы избежать самосинхронизации с другими системами на та же подсеть. Таким образом, средний интервал между пакетами будет примерно на 12,5% меньше согласованного.

Если bfd.DetectMult равен 1, интервал между передаваемыми пакетами управления BFD ДОЛЖЕН составлять не более 90% согласованного интервала передачи и ДОЛЖЕН составлять не менее 75% согласованного интервала передачи. Это необходимо для того, чтобы в удаленной системе рассчитанное время обнаружения не прошло до получения следующего пакета управления BFD.

Интервал передачи ДОЛЖЕН быть пересчитан всякий раз, когда изменяется bfd.DesiredMinTxInterval или всякий раз, когда изменяется bfd.RemoteMinRxInterval, и равен большему из этих двух значений. См. Разделы 6.8.2 и 6.8.3 для подробностей о таймерах передачи.

Система НЕ ДОЛЖНА передавать пакеты управления BFD, если bfd.RemoteDiscr равен нулю, а система выполняет роль пассивного устройства.

Система НЕ ДОЛЖНА периодически передавать контрольные пакеты BFD, если bfd.RemoteMinRxInterval равен нулю.

Система НЕ ДОЛЖНА периодически передавать пакеты управления BFD, если в удаленном режиме активен режим запроса (bfd.RemoteDemandMode равен 1, bfd.SessionState — «Вверх», а bfd.RemoteSessionState — «Вверх»), а последовательность опроса не передается.

Если пакет управления BFD принимается с битом Poll (P), установленным в 1, принимающая система ДОЛЖНА передавать пакет управления BFD с очищенным битом Poll (P) и битом Final (F), установленным как можно скорее, без учета таймеру передачи или любым другим ограничениям передачи, независимо от состояния сеанса и без учета того, активен ли режим запроса в любой из систем. Система МОЖЕТ ограничить скорость передачи таких пакетов. Если действует ограничение скорости, объявленное значение требуемого минимального интервала передачи ДОЛЖНО быть больше или равно интервалу между передаваемыми пакетами, налагаемым функцией ограничения скорости.

Система НЕ ДОЛЖНА устанавливать бит Demand (D), если bfd.DemandMode не равен 1, bfd.SessionState имеет значение Up, а bfd.RemoteSessionState имеет значение Up.

Управляющий пакет BFD СЛЕДУЕТ передавать в течение интервала между периодическими передачами управляющего пакета, когда содержимое этого пакета будет отличаться от содержимого в ранее переданном пакете (кроме битов опроса и конечных битов), чтобы быстрее сообщать об изменении состояния.

Содержимое передаваемых пакетов управления BFD ДОЛЖНО быть установлено следующим образом:

Версия
Установите номер текущей версии (1).

Диагностика (Диаг)
Установите для bfd.LocalDiag.

Состояние (Sta)
Установите значение, указанное в bfd.SessionState.

Опрос (P)
Установите 1, если локальная система отправляет последовательность опроса, или 0, если нет.

Финал (F)
Установите значение 1, если локальная система отвечает на пакет управления, полученный с установленным битом опроса (P), или 0, если нет.

Самолет управления Независимый (C)
Установите в 1, если реализация BFD локальной системы не зависит от плоскости управления (она может продолжать функционировать через нарушение плоскости управления).

Настоящая аутентификация (A)
Установите 1, если аутентификация используется в этом сеансе (bfd.AuthType не равен нулю), или 0, если нет.

Требование (D)
Установите значение bfd.DemandMode, если bfd.SessionState имеет значение Up, а bfd.RemoteSessionState имеет значение Up. Иначе, это установлено в 0.

Многоточечный (М)
Установите на 0.

Обнаружить Мульт
Установите для bfd.DetectMult.

Длина
Установите соответствующую длину на основе фиксированной длины заголовка (24) плюс любой раздел аутентификации.

Мой дискриминатор
Установите в bfd.LocalDiscr.

Ваш дискриминатор
Установите для bfd.RemoteDiscr.

Желаемый минимальный интервал TX
Установите для bfd.DesiredMinTxInterval.

Требуемый минимальный интервал приема
Установите для bfd.RequiredMinRxInterval.

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

Раздел аутентификации
Включается и устанавливается в соответствии с правилами раздела 6.7, если используется аутентификация (bfd.AuthType не равен нулю). В противном случае этого раздела нет.

6.8.8. Прием BFD Echo пакетов

Принятый эхо-пакет BFD ДОЛЖЕН быть демультиплексирован в соответствующий сеанс для обработки. ДОЛЖНО быть реализовано средство обнаружения пропущенных эхо-пакетов, которое, скорее всего, включает обработку принятых эхо-пакетов. В противном случае обработка принятых пакетов Echo выходит за рамки данной спецификации.

6.8.9. Передача эхо-пакетов BFD

Эхо-пакеты BFD НЕ ДОЛЖНЫ передаваться, когда bfd.SessionState не установлен. Эхо-пакеты BFD НЕ ДОЛЖНЫ передаваться, если только последний контрольный пакет BFD, полученный от удаленной системы, не содержит ненулевое значение в Обязательном минимальном интервале эхо-приема.

Эхо-пакеты BFD МОГУТ передаваться, когда bfd.SessionState имеет значение Up. Интервал между передаваемыми эхо-пакетами BFD НЕ ДОЛЖЕН быть меньше значения, объявленного удаленной системой в поле Required Min Echo RX Interval, за исключением следующего:

Джиттер 25% МОЖЕТ быть применен к скорости передачи, так что фактический интервал МОЖЕТ быть между 75% и 100% от объявленного значения. Один эхо-пакет BFD МОЖЕТ быть передан между обычно запланированными интервалами эхо-передачи.

В противном случае передача эхо-пакетов BFD выходит за рамки данной спецификации.

6.8.10. Min Rx Interval Change

Когда необходимо изменить скорость, с которой пакеты управления BFD поступают из удаленной системы, bfd.RequiredMinRxInterval можно изменить в любое время на любое значение. Новое значение будет передано в следующем исходящем управляющем пакете, и удаленная система выполнит соответствующие настройки. См. Раздел 6.8.3 для дальнейших требований.

6.8.11. Минимальное изменение интервала Tx

Когда необходимо изменить скорость, с которой пакеты управления BFD передаются в удаленную систему (с учетом требований соседней системы), bfd.DesiredMinTxInterval может быть изменен в любое время на любое значение. Применяются правила раздела 6.8.3.

6.8.12. Обнаружить изменение множителя

Когда необходимо изменить множитель обнаружения, значение bfd.DetectMult можно изменить на любое ненулевое значение. Новое значение будет передано со следующим пакетом управления BFD, и использование последовательности опроса не обязательно. См. Раздел 6.6 для дополнительных требований.

6.8.13. Включение или отключение функции эха

Если желательно начать или остановить передачу эхо-пакетов BFD, это МОЖЕТ быть сделано в любое время (с учетом требований к передаче, подробно изложенных в разделе 6.8.9).

Если желательно включить или отключить зацикливание принятых эхо-пакетов BFD, это МОЖЕТ быть сделано в любое время путем изменения значения Обязательного минимального интервала приема эхо-сигналов на ноль или ненулевое значение в исходящих пакетах управления BFD.

6.8.14. Включение или отключение режима спроса

Если требуется запустить или остановить режим Demand, это МОЖЕТ быть сделано в любое время, если для bfd.DemandMode установлено правильное значение. Режим спроса впоследствии станет активным в соответствии с правилами, описанными в разделе 6.6.

Если режим запроса больше не активен в удаленной системе, локальная система ДОЛЖНА начать передачу периодических пакетов управления BFD, как описано в разделе 6.8.7.

6.8.15. Переадресация сброса самолета

Когда плоскость пересылки в локальной системе по какой-либо причине сбрасывается, так что удаленная система больше не может полагаться на состояние локальной пересылки, локальная система ДОЛЖНА установить для bfd.LocalDiag значение 4 (Сброс плоскости пересылки) и установить bfd.SessionState. вниз

6.8.16. Административный контроль

Могут быть обстоятельства, когда желательно административно включить или отключить сеанс BFD. Когда это необходимо, ДОЛЖНА следовать следующая процедура:

Если разрешить сеанс
—Установите для bfd.SessionState значение Down.
Иначе
—Установите bfd.SessionState в AdminDown
—Установите bfd.LocalDiag в соответствующее значение
—Прекратить передачу эхо-пакетов BFD.

Если извне BFD получен сигнал о том, что базовый путь не пройден, реализация МОЖЕТ административно отключить сеанс с диагностическим путем вниз.

Другие сценарии МОГУТ использовать диагностику Административно вниз.

Управляющие пакеты BFD ДОЛЖНЫ передаваться в течение, по меньшей мере, времени обнаружения после перехода в состояние AdminDown, чтобы гарантировать, что удаленная система осведомлена об изменении состояния. Управляющие пакеты BFD МОГУТ передаваться бесконечно после перехода в состояние AdminDown, чтобы поддерживать состояние сеанса в каждой системе (см. Раздел 6.8.18 ниже).

6.8.17. Конкатенированные пути

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

Для этой цели определены два диагностических кода: каскадный путь вниз и обратный каскадный путь вниз. Первый распространяет сбои прямого пути (при котором сцепленный путь терпит неудачу в направлении к системе взаимодействия), а второй распространяет сбои обратного пути (при котором каскадный путь терпит неудачу в направлении от системы взаимодействия, предполагая двунаправленную связь).

Система МОЖЕТ сигнализировать об одном из этих состояний отказа, просто установив bfd.LocalDiag в соответствующий диагностический код. Обратите внимание, что сеанс BFD не отключен. Если режим запроса не активен в удаленной системе, никаких других действий не требуется, поскольку диагностический код будет передаваться через периодическую передачу контрольных пакетов BFD. Если режим запроса активен в удаленной системе (локальная система не передает периодические контрольные пакеты BFD), ДОЛЖНА быть инициирована последовательность опроса, чтобы обеспечить передачу диагностического кода. Обратите внимание, что в случае сбоя сеанса BFD диагностический код будет перезаписан кодом, подробно описывающим причину сбоя. Агент взаимодействия должен снова выполнить вышеописанную процедуру, как только сеанс BFD достигнет состояния «Вверх», если распространение сбоя связанного пути должно возобновиться.

6.8.18. Удержание сессий

Система МОЖЕТ выбрать запрет на установление сеанса BFD. Одной из возможных причин может быть управление скоростью, с которой устанавливаются сеансы. Это можно сделать, удерживая сеанс в состоянии Down или AdminDown, в зависимости от ситуации.

Есть два связанных механизма, которые могут помочь с этой задачей. Во-первых, система ОБЯЗАНА поддерживать состояние сеанса (включая параметры синхронизации), даже когда сеанс не работает, до тех пор, пока не пройдет время обнаружения без получения каких-либо пакетов управления BFD. Это означает, что система может завершить сеанс и передать произвольно большое значение в поле Required Min RX Interval, чтобы контролировать скорость, с которой она принимает пакеты.

Кроме того, система МОЖЕТ передать нулевое значение для необходимого минимального интервала приема, чтобы указать, что удаленная система не должна отправлять никаких пакетов вообще.

Пока локальная система продолжает передавать контрольные пакеты BFD, удаленная система обязана подчиняться значению, указанному в обязательном минимальном интервале приема. Если удаленная система не получает никаких пакетов управления BFD в течение времени обнаружения, она ДОЛЖНА сбросить bfd.RemoteMinRxInterval к своему начальному значению 1 (согласно разделу 6.8.1, так как больше не требуется поддерживать предыдущее состояние сеанса), а затем может передавать по собственному тарифу.

7. Эксплуатационные соображения

BFD, вероятно, будет развернут как критическая часть сетевой инфраструктуры. Таким образом, следует позаботиться о том, чтобы избежать сбоев.

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

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

Когда BFD используется в нескольких переходах, ДОЛЖЕН быть реализован механизм управления перегрузкой, а при обнаружении перегрузки реализация BFD ДОЛЖНА сокращать объем генерируемого трафика. Точный используемый механизм выходит за рамки данной спецификации, и требования этого механизма могут отличаться в зависимости от того, как развернут BFD и как он взаимодействует с другими частями системы (например, экспоненциальный откат может не подходить в случаях, когда протоколы маршрутизации тесно взаимодействуют с BFD).

Обратите внимание, что «перегрузка» является не только явлением трафика, но и вычислительным явлением. Системы с большим количеством сеансов BFD и / или очень короткими интервалами между пакетами могут быть привязаны к процессору. Как таковой, алгоритм управления перегрузкой ДОЛЖЕН использоваться даже для отдельных скачков, чтобы избежать возможности катастрофического сбоя системы, поскольку такие сбои неоднократно наблюдались в других периодических протоколах на основе приветствия.

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

Механизмы снижения нагрузки трафика BFD — это управление локальной и удаленной скоростью передачи пакетов через поля Min RX Interval и Min TX Interval.

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

Стоит отметить, что один сеанс BFD не использует большой объем полосы пропускания. Агрессивный сеанс, который достигает времени обнаружения 50 миллисекунд, используя интервал передачи 16,7 миллисекунды и умножитель обнаружения 3, будет генерировать 60 пакетов в секунду. Максимальная длина каждого пакета в проводе составляет порядка 100 байтов, что в сумме составляет около 48 килобит в секунду потребления полосы пропускания в каждом направлении.

8. Соображения IANA

Этот документ определяет два реестра, управляемых IANA. Первый называется «Диагностические коды BFD» (см. Раздел 4.1). Начальные значения для реестра BFD Diagnostic Code приведены ниже. Дальнейшие назначения должны быть сделаны через экспертизу [СООБРАЖЕНИЯ IANA]. Назначения состоят из имени диагностического кода BFD и связанного с ним значения.

Значение — BFD Диагностический код Название
—— ————————
0 Нет диагностики
1 Время обнаружения контроля истекло
2 Сбой функции эха
3 соседа сигнализировали сессию вниз
4 Сброс переадресации
5 Путь вниз
6 каскадный путь вниз
7 Административно вниз
8 Обратный каскадный путь вниз
9-31 Неназначенные

Второй реестр называется «Типы аутентификации BFD» (см. Раздел 4.1). Начальные значения для реестра BFD Authentication Type приведены ниже. Дальнейшие назначения должны быть сделаны через экспертизу [СООБРАЖЕНИЯ IANA]. Назначения состоят из имени кода типа аутентификации BFD и связанного с ним значения.

Значение. Имя типа аутентификации BFD
—— —————————-
0 Зарезервировано
1 простой пароль
2 ключа MD5
3 Дотошный ключ MD5
4-клавишный SHA1
5 дотошный ключ SHA1
6-255 Неназначенные

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

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

Злоумышленник, который полностью контролирует связь между системами, может легко отбросить все пакеты BFD, но переслать все остальное (что приводит к ложному объявлению ссылки), или переслать только пакеты BFD, но ничего больше (вызывая ложную ссылку) объявил). Эта атака не может быть предотвращена BFD.

Чтобы смягчить угрозы от менее способных злоумышленников, BFD определяет два механизма для предотвращения подделки контрольных пакетов BFD. Обобщенный механизм безопасности TTL [GTSM] использует время жизни (TTL) или счетчик прыжков, чтобы не дать злоумышленникам, не подключенным к каналу, подделать пакеты. Секция аутентификации аутентифицирует пакеты управления BFD. Эти механизмы более подробно описаны ниже.

Когда сеанс BFD напрямую подключен по одному каналу (физическому или защищенному туннелю, такому как IPsec), счетчик TTL или переходов ДОЛЖЕН быть установлен на максимум при передаче и проверен, чтобы быть равным максимальному значению при приеме (и пакет отброшен, если это не так). См. [GTSM] для получения дополнительной информации об этой технике. Если BFD выполняется через несколько переходов или небезопасный туннель (такой как Generic Routing Encapsulation (GRE)), СЛЕДУЕТ использовать раздел аутентификации.

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

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

Аутентификация Meticulous Keyed MD5 еще сильнее, поскольку требует увеличения порядкового номера для каждого пакета. Уязвимость повторной атаки снижается из-за требования, что порядковый номер должен увеличиваться для каждого пакета, размер окна приемлемых пакетов мал, а начальный порядковый номер рандомизирован. В начале сеанса все еще есть окно атаки, пока определяется порядковый номер. Эта схема аутентификации требует вычисления MD5 для каждого переданного и полученного пакета.

Считается, что использование SHA1 обладает более высокими защитными свойствами, чем MD5. Все комментарии о MD5 в этом разделе также относятся к SHA1.

И MD5 / SHA1 с ключом, и MD5 / SHA1 с Meticulous Keyed используют конструкцию «секретный суффикс» (также называемую «только добавление»), в которой общий секретный ключ добавляется к данным перед вычислением хеша, вместо более распространенной аутентификации хешированных сообщений. Код (HMAC) строительство [HMAC]. Эта конструкция считается подходящей для BFD, но разработчикам любых дополнительных механизмов аутентификации для BFD рекомендуется прочитать [HMAC] и его ссылки.

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

Последствия для безопасности использования эхо-пакетов BFD зависят от того, как эти пакеты определены, поскольку их структура является локальной для передающей системы и выходит за рамки этой спецификации. Однако, поскольку эхо-пакеты определяются и обрабатываются только передающей системой, использование криптографической аутентификации не гарантирует, что другая система фактически жива; злоумышленник может зациклить эхо-пакеты обратно (не зная никаких секретных ключей) и вызвать ложное объявление о том, что ссылка установлена. Это может быть смягчено путем использования подходящего интервала для пакетов управления BFD. [GTSM] может быть применен к эхо-пакетам BFD, хотя счетчик TTL / Hop будет уменьшен на 1 во время эхо-пакета, поэтому подделка возможна с одного перехода.

10. Ссылки

10.1. Нормативные ссылки

[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, October 2007.

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

[MD5] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[SHA1] Eastlake 3rd, D. and P. Jones, «US Secure Hash Algorithm 1 (SHA1)», RFC 3174, September 2001.

10.2. Информационные ссылки

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[OSPF] Moy, J., «OSPF Version 2», STD 54, RFC 2328, April 1998.

Приложение A. Обратная совместимость (ненормативный раздел)

Хотя версия 0 этого протокола (как определено в ранних версиях Internet-Draft, которая стала настоящим RFC) вряд ли будет широко развернута, некоторые разработчики могут захотеть использовать механизм обратной совместимости. Обратите внимание, что потенциально может использоваться любой механизм, который не изменяет определение протокола, поэтому совместимость не должна быть проблемой.

Предложенный механизм, описанный здесь, обладает тем свойством, что он будет сходиться в версии 1, если обе системы реализуют его, даже если одна система будет обновлена с версии 0 в течение времени обнаружения. Он будет взаимодействовать с системой, которая реализует только одну версию (или настроена на поддержку только одной версии). Система, очевидно, не должна выполнять эту функцию, если она настроена или может использовать только одну версию.

Сеанс BFD войдет в «удержание согласования», если он настроен на автоматическое управление версиями и либо только что запущен, либо сеанс был очищен вручную. Для сеанса установлено состояние AdminDown и версия 1. В течение периода удержания, который длится одно время обнаружения, система отправляет контрольные пакеты BFD как обычно, но игнорирует полученные пакеты. По истечении времени удержания состояние переходит в состояние «Вниз» и возобновляется нормальная работа.

Когда система не находится в режиме ожидания, если она выполняет автоматическое управление версиями и в настоящее время использует версию 1, если для сеанса получен какой-либо пакет версии 0, она немедленно переключается на версию 0. Если она в настоящее время использует версию 0 и пакет версии 1 принимается, что означает, что сосед находится в состоянии AdminDown, он переключается на версию 1. Если используется версия 0 и получен пакет версии 1, указывающий состояние, отличное от AdminDown, пакет игнорируется (согласно спецификации).

Если используемая версия изменяется, сеанс отключается в зависимости от новой версии (состояние «выключено» для версии 1 или состояние «сбой» для версии 0).

Приложение B. Авторы

Кириети Компелла (Kireeti Kompella) и Яков Рехтер (Yakov Rekhter) из Juniper Networks также внесли значительный вклад в этот документ.

Приложение C. Благодарности

Этот документ был вдохновлен (и призван заменить) документом Протокола о жизни, написанным Кириети Компелла.

Режим спроса был основан на «Основанном на трафике способе обнаружения мертвых одноранговых узлов обмена ключами в Интернете (IKE)» Дж. Хуанга и др.

Авторы также хотели бы поблагодарить Майка Шанда, Джона Скаддера, Стюарта Брайанта, Пекку Саволу, Ричарда Спенсера и Паси Эронена за их содержательный вклад.

Авторы также хотели бы поблагодарить Оуэна Уилера за организацию телеконференций между авторами этой спецификации и несколькими поставщиками для решения проблем с реализацией и ясностью.

Адрес автора

Dave Katz
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
EMail: dkatz@juniper.net

Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
EMail: dward@juniper.net

Аннотация

Оглавление

Статус этой заметки

Уведомление об авторских правах

1. Введение

1.1. Соглашения, используемые в этом документе

2. Дизайн

3. Обзор протокола

3.1. Адресация и установление сессии

3.2. Режимы работы

4. Формат пакета управления BFD

4.1. Общий формат пакета управления BFD

Версия (Vers)

Диагностика (Diag)

Состояние (Sta)

Опрос (P)

Финал (F)

Независимая плоскость управления (C)

Настоящая аутентификация (A)

Требование (D)

Многоточечный (М)

Обнаружение Mult (Detect Mult)

Длина (Length)

Мой дискриминатор (My Discriminator)

Ваш дискриминатор (Your Discriminator)

Желаемый минимальный интервал TX (Desired Min TX Interval)

Требуемый минимальный интервал приема (Required Min RX Interval)

Требуется минимальный интервал эха RX (Required Min Echo RX Interval)

Тип аутентификации (Auth Type)

Длина аутентификации (Auth Len)

4.2. Формат раздела простой аутентификации по паролю

Тип аутентификации (Auth Type)

Длина аутентификации (Auth Len)

Идентификатор ключа авторизации (Auth Key ID)

Пароль (Password)

4.3. Формат раздела аутентификации с ключом MD5 и Meticulous Keyed MD5

Тип аутентификации (Auth Type)

Длина аутентификации (Auth Len)

Идентификатор ключа авторизации (Auth Key ID)

Зарезервированный (Reserved)

Порядковый номер (Sequence Number)

Auth Key / Digest

4.4. Формат раздела аутентификации с ключом SHA1 и метаданным ключом SHA1

Тип аутентификации (Auth Type)

Длина аутентификации (Auth Len)

Идентификатор ключа авторизации (Auth Key ID)

Зарезервированный (Reserved)

Порядковый номер (Sequence Number)

Auth Key / Hash

5. Эхо-пакет BFD

6. Элементы процедуры

6.1. Обзор

6.2. BFD State Machine

6.3. Демультиплексирование и поля дискриминатора

6.4. Эхо-функция и асимметрия

6.5. Последовательность опроса

6.6. Режим спроса

6.7. Аутентификация

6.7.1. Включение и отключение аутентификации

6.7.2. Простая аутентификация по паролю

Передача с использованием простой аутентификации по паролю

Прием с использованием простой аутентификации по паролю

6.7.3. Аутентификация с ключами MD5 и Meticulous Keyed MD5

Передача с использованием Keyd MD5 и аутентификации Meticulous Keyed MD5

Квитанция с использованием Keyed MD5 и Meticulous Keyed MD5 Authentication

6.7.4. Аутентификация SHA1 с ключами и аутентификация SHA1 с точными ключами

Передача с использованием SHA1 с ключами и аутентификации SHA1 с точным ключом

Квитанция с использованием аутентификации по ключу SHA1 и аутентификации по метаданным ключам SHA1

6.8. Функциональные особенности

6.8.1. Переменные состояния

bfd.SessionState

bfd.RemoteSessionState

bfd.LocalDiscr

bfd.RemoteDiscr

bfd.LocalDiag

bfd.DesiredMinTxInterval

bfd.RequiredMinRxInterval

bfd.RemoteMinRxInterval

bfd.DemandMode

bfd.RemoteDemandMode