RFC 9384 A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)

Internet Engineering Task Force (IETF)                           J. Haas
Request for Comments: 9384                              Juniper Networks
Category: Standards Track                                     March 2023
ISSN: 2070-1721

A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)

Субкод уведомления BGP Cease для BFD

PDF

Аннотация

Протокол обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD, RFC 5880) служит для обнаружения потери связности между двумя машинами (узлами) пересылки, обычно с малой задержкой. BFD применяется протоколами маршрутизации, включая протокол граничного шлюза (Border Gateway Protocol или BGP), для более быстрого отключения (down) соединений протокола по сравнению с обычными протокольными таймерами.

Этот документ задаёт субкод сообщения BGP Cease NOTIFICATION (параграф 6.7 в RFC 4271) для использования при разрыве соединения BGP в результате закрытия сессии BFD.

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

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

Протокол BGP версии 4 (BGP-4) [RFC4271] разрывает соединения по таймеру удержания (Hold Timer), когда узел не получает сообщений BGP в течение согласованного интервала Hold Time. В соответствии с параграфами 4.2 и 4.4 [RFC4271], минимальное значение Hold Time составляет не менее 3 секунд, если только обработка KEEPALIVE не была отключена согласованием нулевого значения Hold Time.

Если узел BGP хочет при потере связности разрывать соединения быстрее, нежели позволяет согласованный BGP Hold Timer, он может воспользоваться протоколом BFD для более быстрого обнаружения прерывания связности узлами BGP. Когда состояние сессии BFD меняется на Down, узел BGP разрывает соединение с помощью сообщения Cease NOTIFICATION, передаваемого соседу, и, если это возможно, разрывает соединение TCP для сессии.

Этот документ определяет для передачи в сообщении Cease NOTIFICATION субкод BFD Down, указывающий эту причину разрыва соединения.

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

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

3. Субкод BFD Cease NOTIFICATION

Для субкода BFD Down сообщений Cease NOTIFICATION агентство IANA выделило значение 10.

При разрыве соединения BGP по переходу сессии BFD в состояние Down узлу BGP следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом BFD Down.

4. Эксплуатационные вопросы

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

При разрыве соединения BGP по событию BFD Down в результате обнаруженной BFD частичной потери связности, удалённый узел BGP может получить сообщение BGP Cease NOTIFICATION с субкодом BFD Down. После этого принявший сообщение узел BGP будет понимать, что соединение разрывается из-за проблемы, обнаруженной BFD, а не из-за проблемы на узле BGP.

В случае полной потери связности между двумя узлами BGP отправка сообщения Cease NOTIFICATION может оказаться невозможной. Тем не менее, узлам BGP следует указать эту причину как часть своего рабочего состояния. Примеры включают bgpPeerLastError в соответствии с BGP MIB [RFC4273] и last-error в [BGP-YANG].

Когда требуются процедуры из [RFC8538] для отправки сообщения NOTIFICATION с кодом ошибки Cease и субкодом Hard Reset, а соединение разрывается по причине перехода BFD в состояние Down, следует инкапсулировать субкод BFD Down в данные Hard Reset сообщения NOTIFICATION.

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

Подобно [RFC4486], этот документ задаёт субкод для сообщений BGP Cease NOTIFICATION, предоставляющий сведения, которые помогают оператору сети сопоставить события в сети и диагностировать проблемы партнёрства BGP. Этот субкод является чисто информационным и не влияет на конечный автомат BGP (Finite State Machine) сверх указанного в параграфах 6.6 и 6.7 [RFC4271].

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

Агентство IANA выбелило значение 10 в реестре BGP Cease NOTIFICATION message subcodes (https://www.iana.org/assignments/bgp-parameters/) с именем BFD Down и ссылкой на этот документ.

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC5880] Katz, D. and D. Ward, “Bidirectional Forwarding Detection (BFD)”, RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.

[RFC5882] Katz, D. and D. Ward, “Generic Application of Bidirectional Forwarding Detection (BFD)”, RFC 5882, DOI 10.17487/RFC5882, June 2010, <https://www.rfc-editor.org/info/rfc5882>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas, “Notification Message Support for BGP Graceful Restart”, RFC 8538, DOI 10.17487/RFC8538, March 2019, <https://www.rfc-editor.org/info/rfc8538>.

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

[BGP-YANG] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “YANG Model for Border Gateway Protocol (BGP-4)”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-16, 1 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16>.

[RFC4273] Haas, J., Ed. and S. Hares, Ed., “Definitions of Managed Objects for BGP-4”, RFC 4273, DOI 10.17487/RFC4273, January 2006, <https://www.rfc-editor.org/info/rfc4273>.

[RFC4486] Chen, E. and V. Gillet, “Subcodes for BGP Cease Notification Message”, RFC 4486, DOI 10.17487/RFC4486, April 2006, <https://www.rfc-editor.org/info/rfc4486>.

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

Спасибо Jeff Tantsura и Dale Carder за их комментарии к этому документу.

Mohamed Boucadair предоставил отзыв на документ в рамках обзора Routing Directorate.

В 2006 г. Bruno Rijsman подготовил предложение, по сути похожее на этот документ, – draft-rijsman-bfd-down-subcode. В тот момент документ не прошёл в рабочей группе междоменной маршрутизации (Inter-Domain Routing или IDR). Автор этого документа не знал о работе Bruno при подготовке своего предложения.

Адрес автора

Jeffrey Haas
Juniper Networks
Email: jhaas@juniper.net

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

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

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

RFC 9340 Architectural Principles for a Quantum Internet

Internet Research Task Force (IRTF)                         W. Kozlowski
Request for Comments: 9340                                     S. Wehner
Category: Informational                                           QuTech
ISSN: 2070-1721                                             R. Van Meter
                                                         Keio University
                                                              B. Rijsman
                                                              Individual
                                                       A. S. Cacciapuoti
                                                              M. Caleffi
                                        University of Naples Federico II
                                                             S. Nagayama
                                                           Mercari, Inc.
                                                              March 2023

Architectural Principles for a Quantum Internet

Архитектурные принципы квантовой сети Internet

PDF

Аннотация

Представление квантовой сети (internet) заключается в улучшении имеющихся технологий Internet за счёт квантовых коммуникаций между любыми двумя точками на Земле. Для достижения этой цели нужно с нуля создать сетевой стек с учётом принципиально новых свойств квантовой запутанности. Были реализованы первые сети с квантовой запутанностью но пока нет практических предложений по организации, использованию и управлению такими сетями. В этом документе предпринята попытка заложить основу и представить некоторые архитектурные принципы квантовых сетей. Документ содержит общие рекомендации и создаёт основу для обсуждения физиками и специалистами по сетям. Документ является результатом работы исследовательской группы Quantum Internet (Quantum Internet Research Group или QIRG).

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Quantum Internet в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

Авторские права (Copyright (c) 2023) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Квантовые сети – это распределенные системы квантовых устройств, использующие фундаментальные явления квантовой механики, такие как суперпозиция, запутанности и квантовые измерения, для достижения возможностей, выходящих за рамки классических (не квантовых) сетей [Kimble08]. В зависимости от стадии развития квантовой сети [Wehner18] такие устройства могут варьироваться от простых фотонных устройств, способных единовременно подготавливать и измерять единственный квантовый бит (кубит – qubit), до крупномасштабных квантовых компьютеров будущего. Квантовые сети предназначены не для замены классических сетей, а скорее для формирования гибридных сетей, поддерживающих новые возможности, которые без этого не реализовать [VanMeterBook]. Например, наиболее известное применение квантовой связи – квантовое распространение ключей (Quantum Key Distribution или QKD) [QKD], может создавать и распространять пару симметричных ключей шифрования так, что безопасность всего процесса опирается на законы физики (и может быть доказана математически), а не на неразрешимость некоторых математических проблем [Bennett14] [Ekert91]. Небольшие сети с QKD уже развёрнуты на небольших (около 100 км) расстояниях [Elliott03] [Peev09] [Aguado19] [Joshi20].

Парадигма квантовых сетей предлагает ещё ряд приложений в дополнение к квантовой криптографии, таких как распределенные квантовые вычисления [Cirac99] [Crepeau02], защищённые квантовые вычисления в облаке [Fitzsimons17], измерительные сети с квантовым улучшением [Giovannetti04], высокоточные телескопы с длинной базой [Gottesman12]. Эти приложения гораздо требовательней, чем QKD, и сети, способные их поддерживать, пока находятся в зачаточном состоянии. Лишь недавно была реализована полностью квантовая сеть с множеством узлов, способная передавать, принимать и обрабатывать распределенную квантовую информацию [Pompili21.1].

Несмотря на предпринятые усилия по физической реализации и подключению устройств, а также повышения их скорости и устойчивости к ошибкам, на момент создания этого документа не было разработано никаких предложений по запуску таких сетей. Если провести аналогию с классической сетью, мы сейчас находимся на этапе, когда можно начать физически подключать устройства и передавать данные, но передача, приём, управление буферами, синхронизация соединений и т. п. должны осуществляться приложением напрямую через низкоуровневые специализированные и привязанные к оборудованию интерфейсы вместо управления через сетевой стек с удобным высокоуровневым интерфейсом, таким как сокеты. Лишь недавно была предпринята первая попытка создания такого стека в лабораторных условиях [Pompili21.2]. Кроме того, несмотря на наличие физических механизмов передачи квантовой информации, нет отказоустойчивых протоколов для управления такой передачей.

Этот документ, созданный исследовательской группой Quantum Internet (QIRG), знакомит с квантовыми сетями и представляет общие рекомендации по проектированию и построению таких сетей. В целом документ задуман как введение в предметную область для сетевых инженеров и исследователей. Его не следует считать окончательным утверждением о способах развёртывания квантовых сетей. Документ обсуждался в почтовой конференции QIRG и на нескольких встречах IETF. Документ представляет согласованный взгляд членов QIRG, как специалистов в предметной области (квантовые и сетевые вопросы), так и новичков, являющихся целевой аудиторией.

2. Квантовая информация

Для понимания квантовых сетей требуется базовое понимание теории квантовой информации. В последующих параграфах приводятся базовые сведения, требуемые для понимания принципов работы квантовой сети, рассчитанные на специалистов по классическим сетям. Знакомство читателя с квантовой физикой не предполагается. Более глубокие сведения о квантовых информационных системах можно получить из [SutorBook] и [NielsenChuang].

2.1. Квантовые состояния

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

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

2.2. Кубит

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

   |qubit⟩ = a |0⟩ + b |1⟩

где |X⟩ обозначение квантового состояния в нотации Дирака (ket) – значение, содержащееся в кубите (0 и 1 – коэффициенты, a и b – комплексные числа, называемые амплитудами вероятности). Физически такое состояние может быть реализовано с использованием разных методов, таких как спин электрона, поляризация фотона, уровни энергии в атоме и т. п.

При измерении кубит теряет суперпозицию и необратимо переходит в одно из двух базовых состояний – |0⟩ или |1⟩. Выбор результирующего состояния может быть недетерминированным, но его можно определить по измерению, результатом которого является классический бит 0 или 1, соответствующий |0⟩ или |1⟩. Вероятность получить при измерении состояние |0⟩ будет |a|2, |1⟩ – |b|2, где |a|2 + |b|2 = 1. Эта случайность связана не с игнорированием лежащих (underlying) механизмов, а с фундаментальным свойством квантовомеханической системы [Aspect81].

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

   NOT (a |0⟩ + b |1⟩) → a |1⟩ + b |0⟩

Важно отметить двусмысленность термина «кубит». В первом значении кубит относится к физической квантовой системе, квантовое состояние которой можно выразить как суперпозицию двух базовых состояний, которые часто обозначают |0⟩ и |1⟩. Здесь кубит относится к физической реализации, аналогичной триггеру (flip-flop), переключателю (switch), напряжению или току для классического бита. Во втором значении кубит относится к абстрактному квантовому состоянию квантовой системы в двумя базовыми состояниями. В этом случае кубит сродни логическому значению бита из классических вычислений, т. е. логическому нулю или логической единице. Эти концепции связаны, поскольку физический кубит (в первом смысле) можно использовать для хранения абстрактного кубита (второй смысл). Оба толкования применяются в литературе и смысл обычно понятен из контекста.

2.3. Множество кубитов

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

   a |00⟩ + b |01⟩ + c |10⟩ + d |11⟩

где коэффициенты имеют такую же интерпретацию амплитуды вероятности как для 1-кубитового состояния. Каждое состояние представляет возможный результат измерения для 2-кубитового регистра state. Например, |01⟩ указывает состояние, где первый кубит находится в состоянии |0⟩, а второй – в состоянии |1⟩.

Однокубитовый вентиль воздействует на соответствующий кубит в каждом из состояний суперпозиции, а двухкубитовый вентиль – на все соответствующие состояния суперпозиции, но результат гораздо интересней. Рассмотрим 2-кубитовый регистр, где первый кубит находится в состоянии суперпозиции(|0⟩ + |1⟩)/sqrt(2), а другой – в состоянии |0⟩. Это можно представить в виде

   (|0⟩ + |1⟩)/sqrt(2) x |0⟩ = (|00⟩ + |10⟩)/sqrt(2)

где x указывает тензорное произведение (математический механизм объединения квантовых состояний).

Константа 1/sqrt(2) называется коэффициентом нормализации и отражает тот факт, что сумма вероятностей получения при измерении значений |0⟩ и |1⟩ для первого кубита равна 1.

Рассмотрим 2-кубитовый вентиль Controlled NOT (CNOT), принимающий на входе 2 кубита – управление (control) и цель (target) и применяющий вентиль NOT для цели, если кубит control установлен.

Таблица 1. Таблица истинности CNOT.

 

IN

OUT

00

00

01

01

10

11

11

10

 

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

   CNOT (|00⟩ + |10⟩)/sqrt(2) → (|00⟩ + |11⟩)/sqrt(2).

Что интересного в этой операции с 2-кубитовым вентилем? Конечное состояние является запутанным. Это состояние невозможно представить как произведение двух отдельных кубитов, они перестали быть независимыми, т. е. невозможно описать квантовое состояние любого из отдельных кубитов способом, не зависящим от другого кубита. Лишь квантовое состояние системы, состоящей из двух кубитов обеспечивает физически полное описание 2-кубитовой системы. Состояния двух отдельных кубитов скоррелированы сверх того, что возможно в классическом случае. Ни один из кубитов не находится в определённом состоянии |0⟩ или |1⟩, а при измерении любого из них результат для второго всегда будет таким же. Конечное состояние (|00⟩ или |11⟩) случайно, как и раньше, но состояния обоих кубитов всегда одинаковы. Это можно представить как бросание «связанных» монет, когда обе всегда выпадают «орлом» или «решкой», что не наблюдается в классическом понимании.

После выполнения измерения два кубита снова становятся независимыми. Конечным состоянием будет |00⟩ или |11⟩ и оба можно тривиально разложить на произведение двух отдельных кубитов. Запутанность была «потреблена» (consume) и запутанное состояние нужно подготавливать заново.

3. Запутанность как фундаментальный ресурс

Запутанность является фундаментальным свойством квантовых сетей. Рассмотрим состояние из предыдущего параграфа

   (|00⟩ + |11⟩)/sqrt(2)

Ни один из кубитов не находится в определённом состоянии |0⟩ или |1⟩ и нужно знать состояние всего регистра, чтобы полностью описать поведение двух кубитов.

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

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

У запутанности есть два очень специфических свойства, из которых можно извлечь некоторые интуитивные сведения о типах приложений, поддерживаемых квантовой сетью. Первое свойство связано с тем фактом, что запутанность включает более сильные по сравнению с классическими корреляции, обеспечивающие возможности решения задач, требующих координации. В качестве тривиального примера рассмотрим согласие между двумя узлами, которые хотят договориться о значении одного бита. Они могут использовать квантовую сеть для подготовки состояния (|00⟩ + |11⟩)/sqrt(2) с каждым узлом, содержащим один из двух кубитов. После измерения на любом из этих узлов состояние двух кубитов схлопывается до |00⟩ или |11⟩, поэтому, несмотря на случайность результата и его отсутствие до измерения, значения для двух узлов всегда будут совпадать. Можно также построить более общее многокубитовое состояние (|00…⟩ + |11…⟩)/sqrt(2) и выполнить такой же алгоритм для произвольного числа узлов. Эти более сильные по сравнению с классическими корреляции обобщаются и на более сложные схемы измерения.

Вторым свойством запутанности является то, что её невозможно обобщить (share), т. е. при максимальной запутанности между парой кубитов для них невозможна запутанность с третьим кубитом [Terhal04]. Поэтому запутанность формирует приватное и по своей природе недоступное (untappable) соединение между двумя узлами.

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

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

На основе запутанных состояний, распределенных по сети, можно создавать более сложные службы и приложения, например, [ZOO].

4. Достижение квантовой связности

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

4.1. Проблемы

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

4.1.1. Проблема измерения

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

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

4.1.2. Теорема о невозможности клонирования

Читать состояние кубита напрямую невозможно и возникает вопрос о возможности скопировать кубит «не глядя» в него. Квантовая механика не позволяет и это [Park70] [Wootters82].

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

4.1.3. Достоверность

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

Для описания качества квантового состояния служит физическая величина, которую называют достоверностью (fidelity) [NielsenChuang]. Достоверность выражается числом от 0 до 1 (большее значение соответствует более высокой достоверности) и при значении меньше 0,5 состояние считается непригодным для использования. Достоверность показывает, насколько квантовое состояние близко к тому, которое пытались создать. Это вероятность того, что состояние будет вести себя так же, как желаемое состояние. Достоверность является важным свойством квантовой системы, позволяющим количественно оценить влияние на конкретное состояние шумов из различных источников (ошибки вентилей, потери в канале, шумы среды).

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

4.1.4. Неадекватность прямой передачи

Концептуально самым простым способом распределить запутанное состояние является простая передача одного из кубитов на другую сторону через цепочку узлов с достаточной упреждающей коррекцией квантовых ошибок (Quantum Error Correction или QEC, см. параграф 4.4.3.2) для снижения потерь до приемлемого уровня. Несмотря на теорему о невозможности клонирования и невозможность прямого измерения квантового состояния, имеются механизмы корректировки ошибок для квантовых коммуникаций [Jiang09] [Fowler10] [Devitt13] [Mural16]. Однако QEC предъявляет очень высокие требования к ресурсам (нужны физические кубиты) и их исходной достоверности. Реализация очень сложна и применение QEC не предполагается, пока не станут доступными новые поколения квантовых сетей (см. рисунок 2 в [Mural16] и 4.4.3.3. Схемы обработки ошибок). Пока же квантовые сети полагаются на обмен запутанностью (entanglement swapping, 4.4.2. Переключение запутанности) и телепортацию (4.3. Телепортация). Этот вариант основан на наблюдении отсутствия необходимости распространения произвольного запутанного квантового состояния. Требуется лишь распространение любого из состояний, известных как пары Белла [Briegel98].

4.2. Пары Белла

Состояния пары Белла являются запутанными состояниями двух кубитов

            |00⟩ + |11⟩,
            |00⟩ - |11⟩,
            |01⟩ + |10⟩,
            |01⟩ - |10⟩,

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

Распространить пару Белла между двумя узлами гораздо проще, чем передать через сеть произвольное квантовое состояние. Поскольку состояние известно, обработка ошибок упрощается, а корректировка ошибок в малом масштабе (например, очистка запутанности, описанная в параграфе 4.4.3.1. Очистка), в сочетании с повторными попытками становится приемлемой стратегией.

Причина использования пар Белла, а не иных 2-кубитовых состояний, заключается в том, что они представляют собой максимально запутанный 2-кубитовый набор базовых состояний. Максимальная запутанность означает, что состояния имеют самые сильные неклассические корреляции среди всех возможных 2-кубитовых состояний. Поскольку 1-кубитовые локальные операции не могут увеличить запутанность, менее запутанные состояния будут вносить некоторые ограничения на распределенные квантовые алгоритмы. Это делает пары Белла особенно полезными в качестве базовых элементов для распределенных квантовых приложений.

4.3. Телепортация

Достаточность распространение лишь пар Белла, основана на факте распространения с их помощью любого другого запутанного состояния. Этого можно достичь с помощью телепортации квантового состояния [Bennett93]. Такая телепортация принимает неизвестное состояние кубита, которое мы хотим передать и восстанавливает его в желаемом месте. Это не нарушает теоремы о невозможности копирования, поскольку исходное состояние разрушается в процессе телепортации.

Для телепортации требуется распространить запутанную пару между источником и получателем до начала телепортации. Затем источник запутывает передаваемый кубит со своей стороной пары и выполняет считывание двух кубитов (сумма этих операций называется измерением состояния Белла). Это поглощает запутанность пары Белла, превращая исходный и целевой кубиты в независимые состояния. Измерение даёт 2 классических бита, которые источник передаёт получателю через классический канал. На основе значений двух полученных классических битов получатель выполняет одну из 4 возможных корректировок (корректировки Паули) на своей стороне пары, что переводит его в неизвестное состояние кубита, которое хотели передать. Необходимость передачи результатов измерения по классическому каналу означает, к сожалению, что запутанность невозможно использовать для передачи информации со скоростью выше скорости света.

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

4.4. Жизненный цикл запутанности

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

4.4.1. Создание элементарного канала

В квантовой сети запутанность всегда создаётся сначала локально (на узле или дополнительном элементе), после чего один или оба запутанных кубита переносятся по квантовому каналу. В этом контексте фотоны (частицы света) являются естественными кандидатами для переноса запутанности. Поскольку эти фотоны передают квантовые состояния из одного места в другое с высокой скоростью, их называют «летающими кубитами (flying qubit). Основа такого выбора связана с обеспечиваемыми фотонами преимуществами, такими как умеренное взаимодействие с окружающей средой, ведущее к умеренной декогеренции, удобное управление стандартными оптическими компонентами, высокая скорость и низкие потери. Однако фотоны сложно сохранить, поэтому преобразователь (transducer) должен переводить состояние летающего кубита в кубит, пригодный для обработки информации и/или хранения, который часто называют материальным кубитом (matter qubit).

Поскольку в этом процессе могут возникать отказы, для эффективной генерации и сохранения запутанности требуется возможность различать успешные и неудачные попытки. Схемы генерации запутанности, способные анонсировать успешное создание, называются схемами генерации объявленной (heralded) запутанности. Имеется три таких базовых схемы генерации объявленной запутанности на основе скоординированных действий на разных концах канала [Cacciapuoti19]

В промежуточной точке

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

В источнике

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

На обеих сторонах

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

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

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

4.4.2. Переключение запутанности

Проблема генерации запутанных пар непосредственно через канал заключается в том, что эффективность снижается с ростом длины канала. При длине больше нескольких десятков километров по оптическому волокну или 1000 км в открытом пространстве (через спутник) скорость фактически снижается до 0, а теорема о невозможности копирования не позволяет усилить сигнал. Решением служит переключение запутанности [Briegel98]. Пара Белла между двумя любыми узлами в сети может быть организована путём комбинирования пар, созданных на каждом отдельном канале пути между двумя конечными точками. Каждый узел на пути может потребить две пары на двух каналах, к которым он подключён, для создания новой запутанной пары между двумя удалёнными концами. Этот процесс называют переключением запутанности (см. рисунок ниже).

+---------+      +---------+      +---------+
|    A    |      |    B    |      |    C    |
|         |------|         |------|         |
|      X1~~~~~~~~~~X2   Y1~~~~~~~~~~Y2      |
+---------+      +---------+      +---------+

Здесь X1 и X2 – кубиты запутанной пары X, а Y1 и Y2 – кубиты запутанной пары Y. Запутанность обозначается символами ~~. На приведённом выше рисунке узлы A и B используют пару X, а B и C – пару Y, но нам нужна запутанность между узлами A и C. Для этого просто телепортируется кубит X2 с использованием пары Y. Это требует от узла B измерить состояние Белла для кубитов X2 и Y1, что приведёт к разрушению запутанности между Y1 и Y2. Однако , X2 заново создаётся на месте Y2, принося с собой запутанность с X1, как показано на рисунке ниже.

   +---------+      +---------+      +---------+
   |    A    |      |    B    |      |    C    |
   |         |------|         |------|         |
   |      X1~~~~~~~~~~~~~~~~~~~~~~~~~~~X2      |
   +---------+      +---------+      +---------+

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

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

4.4.3. Обработка ошибок

4.4.3.1. Очистка

Ни создание пар Белла, ни переключение запутанности не избавлены от шумов, поэтому с каждым каналом и каждым переключением достоверность состояния снижается. Однако можно создать состояния пар белла с более высокой достоверностью из двух или более пар с меньшей достоверностью с помощью процесса, называемого очисткой или дистилляцией (distillation, иногда purification) [Dur07].

Для очистки квантового состояния применяется второе (иногда и третье) состояние в качестве инструмента проверки утверждения из первого состояния, например, чётность/нечётность первого состояния. Состояния тестового инструмента разрушаются в процессе, поэтому для очистки требуются значительные ресурсы. При отказе проверки тестовое состояние также должно отбрасываться. Очистка требует меньшей точности и ресурсов по сравнению с QEC, но распределенные протоколы вносят задержки кругового обхода из-за применения классических коммуникаций [Bennett96].

4.4.3.2. Корректировка квантовых ошибок

Подобно классической корректировке ошибок, QEC кодирует логические кубиты с использованием нескольких физических (raw) кубитов для защиты от ошибок, описанных в параграфе 4.1.3 [Jiang09] [Fowler10] [Devitt13] [Mural16]. Кроме того, как и его классический аналог, QEC может не только исправлять ошибки состояния, но и учитывать потерю кубитов. Если физические кубиты, кодирующие логический кубит, размещены на одном узле, процедура корректировки может выполняться локально даже при запутанности логического кубита с удалёнными кубитами.

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

4.4.3.3. Схемы обработки ошибок

Квантовые сети были разделены на 3 «поколения» (Таблица 2) в зависимости от применяемой схемы обработки ошибок [Mural16]. Эти «поколения» больше похожи на категории и не обязательно предполагают разницу во времени и устаревание, хотя более поздним поколениям требуются более совершенные технологии. Выбор используемого поколения зависит от аппаратной платформы и устройства сети.

Таблица 2. Классическая сигнализация и поколения обработки ошибок.


Первое поколение

Второе поколение

Третье поколение

Устойчивость к потерям

Объявленная генерация запутанности (двухсторонняя классическая сигнализация)

Объявленная генерация запутанности (двухсторонняя классическая сигнализация)

QEC (без классической сигнализации)

Устойчивость к ошибкам

Очистка запутанности (двухсторонняя классическая сигнализация)

Очистка запутанности (односторонняя классическая сигнализация) или QEC (без классической сигнализации)

QEC (без классической сигнализации)

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

Устойчивость к потерям связана с допустимостью к потере кубитов, передаваемых между узлами. Объявленная генерация запутанности, как указано в параграфе 4.4.1, подтверждает приём запутанного кубита с помощью сигнала оповещения. Пара напрямую связанных квантовых узлов пытается создать запутанную пару, пока не будет получен сигнал оповещения (heralding). Как указано в параграфе 4.4.3.2, можно использовать QEC для восполнения потерянных кубитов, что избавляет от необходимости повторных попыток. Поскольку процедура корректировки состоит из локальных операций, ей не требуется сигнал оповещения. Однако это возможно лишь при уровне потери фотонов от передачи до измерения не более 50%.

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

Ниже приведена сводка для трёх «поколений».

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

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

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

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

4.4.4. Доставка

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

5. Архитектура Quantum Internet

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

5.1. Проблемы

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

  1. Пары Белла не эквивалентны пакетам, передающим информацию.

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

    В квантовой сети запутанные пары кубитов являются базовыми единицами сети. Сами кубиты не содержат каких-либо заголовков, поэтому квантовые сети должны будут передавать всю управляющую информацию по отдельным классическим каналам, которые ретрансляторы (повторители) должны сопоставлять с кубитами, хранящимися в их памяти. Кроме того, в отличие от классического пакета, находящегося в одном узле, пара Белла состоит из двух кубитов, размещённых на двух узлах. Это оказывает фундаментальное влияние на управление квантовыми сетями и разработку протоколов для них. Чтобы создать протяжённые (long-distance) пары Белла, узлам, возможно, придётся хранить кубиты в своей квантовой памяти и ждать прихода управляющей информации, прежде чем выполнить следующую операцию. Такая сигнализация внесёт добавочную задержку, которая будет зависеть от расстояния между двумя конечными узлами пары Белла. Обработка ошибок, такая как очистка запутанности, является типичным примером обмена управляющей информацией [Nagayama21] (см. 4.4.3.3. Схемы обработки ошибок).

  2. Квантовые сети store and forward (сохранить и переслать) и store and swap (сохранить и поменять) требуют разных методов управления состоянием.

    Как указано в параграфе 4.4.1, квантовые каналы предоставляют пары Белла, которые являются ненаправленными сетевыми ресурсами, в отличие от направленных кадров в классических сетях. Это феноменологическое различие ведёт к архитектурным различиям между квантовыми и классическими сетями. Квантовые сети объединяют множество пар Белла элементарных каналов для создания сквозной (end-to-end) пары Белла, тогда как классические сети доставляют сообщения с одного конца на другой путём поэтапной (hop by hop) пересылки.

    Классические сети получают данные на один интерфейс, сохраняют их в локальных буферах, а затем пересылают данные через другой подходящий интерфейс. Квантовые сети сохраняют пары Белла, а затем переключают запутанность вместо пересылки в плоскости данных. Такие квантовые сети относятся к типу store and swap и им не нужно заботиться о порядке генерации пар Белла, поскольку они являются ненаправленными. Однако, несмотря на это, очень важно, чтобы переключались нужные запутанные пары, а результаты промежуточных измерений (см. параграф 4.4.2. Переключение запутанности) передавались и сопоставлялись на других узлах с нужными кубитами. Иначе сквозная запутанная пара будет создана не между ожидаемыми конечными точками или будет иметь неожиданное квантовое состояние. Например, Алиса вместо кубита, запутанного с Бобом, получит кубит, запутанный с Чарли. Это различие ведёт к использованию в квантовых сетях алгоритмов управления и оптимизации, отличающихся от принятых в классических сетях в том смысле, что переключение запутанности происходит с учётом состояния, в отличие от пересылки пакетов. Отметим, что квантовые сети третьего поколения (4.4.3.3. Схемы обработки ошибок) могут поддерживать архитектуру store and forward в дополнение к store and swap.

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

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

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

  4. Для создания запутанности требуется временное состояние.

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

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

5.2. Классические коммуникации

В этом документе уже упомянуты две роли классических коммуникаций в квантовой сети:

  • передача классических битов как части распределенных протоколов обмена запутанностью и телепортации;

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

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

5.3. Абстрактная модель сети

5.3.1. Плоскости управления и данных

Протоколы плоскости управления для квантовых сетей будут иметь много обязанностей, подобно их классическим аналогам – изучение топологии сети, управление ресурсами, заполнение таблиц плоскости данных и т. п. Большинству из этих протоколов не нужны манипуляции квантовыми данными и они смогут работать на основе обмена классическими сообщениями. Для некоторых функций плоскости управления может потребоваться обработка квантовых данных [QI-Scenarios]. Поскольку польза определения отдельной квантовой плоскости данных не очевидна и её функциональность в значительной мере совпадает с функциональностью классической плоскости управления, отдельная квантовая плоскость управления здесь не рассматривается.

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

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

5.3.2. Элементы квантовой сети

Квантовые повторители (ретрансляторы) являются основными элементами квантовой сети. Однако эти ретрансляторы не только переключают запутанность в работающей квантовой сети, но и выполняют ещё ряд действий:

  1. создание запутанности на локальной канале между соседними узлами;

  2. расширение запутанности от локальных пар до протяжённых (long-range) через обмен запутанностью;

  3. очистка (distillation) для управления достоверностью созданных пар;

  4. участие в управлении сетью (маршрутизация и т. п.).

Не все квантовые повторители в сети будут одинаковы и здесь выделено насколько категорий.

Квантовые маршрутизаторы (управляемые квантовые узлы)

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

Автоматизированные квантовые узлы

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

Конечные узлы

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

Неквантовые узлы

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

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

Квантовый канал

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

Классический канал

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

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

5.3.3. Сборка воедино

На рисунке ниже представлен двухэтапный путь базовой квантовой сети

   +-----+                                        +-----+
   | App |- - - - - - - - - -CC- - - - - - - - - -| App |
   +-----+                +------+                +-----+
   | EN  |------ CL ------|  QR  |------ CL ------| EN  |
   |     |------ QL ------|      |------ QL ------|     |
   +-----+                +------+                +-----+

   App - приложение пользовательского уровня
   EN - конечный узел
   QL - квантовое соединение (Link)
   CL - классическое соединение (Link)
   CC - классический канал (через одно или несколько соединений CL)
   QR - квантовый повторитель (ретранслятор)

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

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

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

Отметим, что термин сигнализация здесь применяется в очень широком смысле и охватывает множество типов сообщений, требуемых для управления генерацией запутанности. Например, создание анонсированной (heralded) запутанности требует очень точной синхронизации времени между соседними узлами, поэтому инициирование создания и объявления запутанности может происходить по собственному (возможно физически отдельному) соединению CL, как в демонстрации сетевого стека, приведённой в [Pompili21.2]. Сигнализация более высокого уровня с менее жёсткими требованиями к синхронизации (например, сигналы плоскости управления) может выполняться через своё соединение CL.

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

5.4. Физические ограничения

Приведённая выше модель не включает каких-либо деталей аппаратной реализации, однако при создании реальной нужно рассмотреть некоторые физические ограничения. Некоторые из ограничений являются фундаментальными и развитие технологий не устранить их. Другие могут являться особенностями ранних реализаций новой технологии. Здесь рассматривается очень абстрактный сценарий, а ссылки на физические основы приведены в [Wehner18].

5.4.1. Срок действия памяти

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

Срок действия памяти зависит от конкретного физического устройства и в 2020 г. на доступном тогда оборудовании срок хранения имел порядок секунд [Abobeih18], хотя для кубитов, не подключённых к квантовой сети было продемонстрировано хранение в течение минуты [Bradley19]. Продолжительность хранения возросла с развитием технологий и продолжит увеличиваться. Однако при реализации квантовых сетей в ближайшем будущем нужно быть готовыми работать с краткосрочной памятью, например, за счёт сокращения задержки на важных путях.

5.4.2. Скорость

Создание запутанности на канале между двумя соединёнными узлами – не слишком эффективный процесс и требует множества попыток [Hensen15] [Dahlberg19]. Например, максимально достижимыми показателями для узлов «азот-вакансия», которые кроме генерации запутанности способны сохранять и обрабатывать полученные кубиты, является частота порядка 10 Гц. В сочетании с малым сроком действия памяти это сильно сокращает временные рамки для организации связности в масштабе сети.

На других платформах наблюдались более высокие скорости создания запутанности, но обычно это происходило за счёт других возможностей оборудования, таких как отсутствие квантовой памяти и/или ограниченные возможности обработки [Wei22]. Тем не менее, доступных скоростей недостаточно для практического применения, сверх экспериментов по подтверждению концепций. Однако ожидается рост скорости по мере развития технологий квантовых сетей [Wei22].

5.4.3. Коммуникационные кубиты

Большинство вариантов физической архитектуры, способных сохранять кубиты, могут создавать запутанность лишь для подмножества доступных кубитов, называемые коммуникационными [Dahlberg19]. После генерации пары Белла с использованием коммуникационного кубита его состояние можно перенести в память. Это может вносить дополнительные ограничения для сети. В частности, если у данного узла имеется лишь 1 коммуникационный кубит, узел не сможет создать пары Белла по двум каналам одновременно и потребуется создавать их по одной.

5.4.4. Однородность

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

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

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

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

6. Принципы архитектуры

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

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

6.1. Цели Quantum Internet

Излагая любой набор принципов, нужно осознавать конечную цель, поскольку неизбежно придётся идти на компромиссы. Ниже представлен список, созданный на основе истории компьютерных сетей и несомненно похожий на созданный в своё время для классической сети Internet [Clark88]. Однако, несмотря на сходство целей, связанные с их достижением проблемы часто существенно различаются. Приведённый ниже список будет, скорей всего, меняться со временем.

  1. Поддержка распределенных квантовых приложений.

    Эта цель представляется тривиальной, но она указывает тонкий и достаточно важный момент, подчёркивающий существенное различие между квантовыми и классическими сетями. В конечном счёте передача квантовых данных не является целью квантовой сети, это лишь один из возможных компонентов протоколов квантовых приложений [Wehner18]. Хотя передачу, несомненно, можно использовать в качестве основы для квантовых приложений, она не является наиболее базовой из числа возможных. Например, QKD на основе запутанности, являющийся наиболее известным протоколом квантовых приложений, полагается лишь на более строгие по сравнению с классическими корреляции и природную секретность запутанных пар Белла и не передаёт произвольные квантовые состояния [Ekert91].

    Основной целью quantum internet является поддержка протоколов распределенных квантовых приложений и крайне важно, чтобы они могли работать хорошо и эффективно. Поэтому важно разработать показатели производительности, значимые для приложений, чтобы стимулировать разработку протоколов квантовых сетей. Например, скорость генерации пар Белла не будет значимой, если не учитывать также достоверность тих пар. Обычно намного проще создавать пары с низкой достоверностью, но квантовым приложениям может потребоваться несколько попыток, а возможно и прерывание работы, если достоверность будет слишком мала. Обзор требований для различных квантовых приложений приведён в [Wehner18], а обзор вариантов применения – в [QI-Scenarios].

  2. Поддержка «завтрашних» распределенных квантовых приложений.

    Единственным неизменным принципом Internet следует считать постоянную изменчивость [RFC1958]. Технические изменения происходят постоянно, а размер и возможности квантовых сетей будут меняться на порядки. Таким образом, явной целью архитектуры квантовых сетей internet является способность воспринимать такие изменения. Нам посчастливилось быть свидетелями развития классической сети Internet в течение десятилетий и мы видели, что работало, а что нет. Для квантовых сетей очень важно избегать жёстких переходов (flag day, например, от NCP до TCP/IP) или обновлений, внедрение которых тенятся десятилетиями (например, IPv6).

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

  3. Поддержка неоднородности.

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

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

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

  4. Обеспечение безопасности на сетевом уровне.

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

    К счастью, с точки зрения приложений, квантовые криптографические протоколы не требуются в сети для обеспечения гарантий конфиденциальности и целостности передаваемых кубитов или генерируемой запутанности (хотя они могут предъявлять требования к классическим каналам, например, требовать проверку подлинности [Wang21]), пока базовые реализации соответствуют (или являются хорошим приближением) теоретическим моделям квантовой криптографии. Приложения будут использовать классические сети для обеспечения сквозной защиты результатов, полученных при обработке запутанных кубитов. Например, в QKD применяется классическое согласования (reconciliation) [Tang19] для исправления ошибок и усиления приватности [Elkouss11] при создании ключа защиты, но необработанные биты, вводимые в эти протоколы должны приходить от измерения запутанных кубитов [Ekert91]. В другом приложении – защищённых делегированных квантовых вычислениях – клиент скрывает свои расчёты от сервера, передавая тому кубиты и затем запрашивая (в классическом сообщении) измерение их сервером в закодированной форме. После этого клиент декодирует результат, полученный от сервера, для получения окончательного результата вычислений [Broadbent10]. Здесь снова классическая сеть применяется для достижения цели защищённых расчётов, а сами удалённые расчёты являются строго квантовыми.

    Хотя приложения могут обеспечивать свою сквозную защиту, сетевым протоколам следует самостоятельно защищать сеть и ограничивать нарушения её работы. Приложения остаются защищёнными, но они могут не работать или становиться неэффективными при атаках. Например, если злоумышленник может измерять каждый кубит, передаваемый между сторонами, пытающимися создать ключ с помощью QKD, создание секретного ключа станет невозможным. Вопросы безопасности в квантовых сетях более подробно рассматриваются в [Satoh17] и [Satoh20].

  5. Простота мониторинга.

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

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

    Кроме того, по одной стороне запутанной пары невозможно сказать без привлечения дополнительных классических данных, где находится другой кубит. Извлечь эти сведения из самих кубитов невозможно. Это означает, что для отслеживания запутанных пар требуется обмен классическими данными, которые могут включать (i) ссылку на запутанную пару, которая позволяет распределенным приложениям координировать действия с кубитами одной пары, и (ii) два бита из каждого переключения (обмена) запутанности, требуемые для идентификации конечного состояния пары Белла (4.4.2. Переключение запутанности).

  6. Обеспечение доступности и отказоустойчивости.

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

Отметим, что приватность не указана среди явных целей защиты, поскольку эти требования зависят от варианта применения. Например, QKD обеспечивает повышенную защиту лишь для распространения симметричных ключей [Bennett14] [Ekert91]. Обработка, манипуляции, обобщение, шифрование и дешифрование данных остаются полностью классическими, ограничивая преимущества приватности, которые можно получить при использовании квантовой сети. С другой стороны, имеются приложения, такие как квантовые вычисления вслепую, которые дают пользователю возможность выполнить квантовые расчёты на удалённом сервере, который при этом не будет знать сути этих вычислений, а также входные и выходные данные [Fitzsimons17]. Поэтому приватность должна рассматриваться на уровне каждого приложения [QI-Scenarios].

6.2. Принципы Quantum Internet

Принципы поддерживают цели, но сами целями не являются – цели определяют, что мы хотим построить, а принципы задают способы достижения целей. Цели служат также основой для определения показателей успеха, а принципы не разделяют успехи и неудачи. Дополнительные сведения о проектировании квантовых сетей можно найти в [VanMeter13.1] и [Dahlberg19].

  1. Запутанность является фундаментальной службой.

    Ключевой услугой квантовой сети является распространение запутанности между узлами сети и все распределенные квантовые приложения строятся на основе этого ресурса. Приложения, вроде кластеризованных квантовых вычислений, распределенных сетей квантового зондирования и некоторых типов защищённых квантовых сетей, потребляют квантовую запутанность как ресурс. Некоторые приложения (например, QKD) просто измеряют запутанные кубиты для получения общего секретного ключа [QKD], а другие (например, распределенные квантовые вычисления) создают более сложные абстракции и операции над запутанными кубитами, например распределенные вентили CNOT [DistCNOT] или телепортацию произвольных состояний кубитов [Teleportation].

    Квантовая сеть может также распределять многоэлементные (multipartite) запутанные состояния (с 3 и более кубитами) [Meignant19], полезные для таких приложений, как групповое согласование ключей (conference key agreement или CKA) [Murta20], распределенные квантовые вычисления [Cirac99], совместное использование секретов [Qin17] и синхронизация часов [Komar14], хотя следует отметить, что такие состояния можно также создавать из множества запутанных пар, распределенных между конечными узлами.

  2. Пары Белла неразличимы.

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

  3. Достоверность является частью сервиса.

    Пары Белла, доставляемые конечным точкам, должны быть достаточно достоверными. В отличие от классических сетей, где большинство ошибок эффективно устраняется до попадания в приложение, многим квантовым приложениям для работы нужна лишь несовершенная (imperfect) запутанность. Однако у квантовых приложений обычно имеется порог достоверности пар Белла, ниже которого они не могут работать. Требования приложений к достоверности пар различаются и сеть отвечает за баланс использования ресурсов в соответствии с потребностями приложений. Возможно, что для сети будет «дешевле» доставлять пары с малой достоверностью, которая всё же выше требуемого приложением порога, чем гарантировать высокую достоверность пар для всех приложений.

  4. Время является дорогим ресурсом.

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

  5. Гибкость в плане возможностей и ограничений.

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

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

7. Мысленный эксперимент, вызванный классическими сетями

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

Создание сквозных пар Белла между удалёнными конечными точками – это распределенная задача с учётом состояния, требующая значительной предварительной координации. Ориентированный на соединения подход представляется наиболее естественным для квантовых сетей. В ориентированной на соединения квантовой сети при желании пары конечных точек начать создание сквозных пар Белла они должны сначала создать квантовый виртуальный канал (Quantum Virtual Circuit или QVC). По аналогии с сетями MPLS конечные точки должны организовать пути с коммутацией по меткам (Label Switched Path или LSP) до начала обмена трафиком. Ориентированная на соединения квантовая сеть может поддерживать виртуальные каналы с множеством конечных точек для создания групповой (multipartite) запутанности. Аналогией в MPLS являются многоточечные LSP для групповой передачи.

Когда квантовое приложение создаёт QVC, оно может указать параметры качества обслуживания (Quality of Service или QoS), такие как требуемая пропускная способность в сквозных парах Белла за секунду (Bell Pairs Per Second или BPPS) и требуемую достоверность пар Белла. По аналогии в сетях MPLS приложения задают при создании LSP пропускную способность в бит/с (Bits Per Second или BPS) и другие ограничения. Требования QoS у приложений различаются. Например, таким приложениям, как QKD, которым не нужно обрабатывать запутанные кубиты и достаточно просто измерять их и сохранять результат, может требоваться много запутанности, но они будут устойчивы к задержкам и их вариациям для отдельных пар. А приложениям для распределенных или облачных квантовых вычислений может требоваться меньше запутанных пар, но взамен потребуется их генерация в один приём для совместной обработки, прежде чем какая-либо из них будет декогерирована.

Квантовой сети нужна функция маршрутизации для расчёта оптимального пути (последовательности маршрутизаторов и каналов) для каждого нового QVC. Эта функция может быть централизованной или распределенной и в последнем случае квантовой сети нужен распределенный протокол маршрутизации. Классические сети используют такие протоколы маршрутизации как OSPF и IS-IS, однако в квантовых сетях определения кратчайшего пути и наименьшей стоимости могут отличаться с учётом таких характеристик квантовой сети, как достоверность [VanMeter13.2].

С учётом очень ограниченной доступности ресурсов в ранних квантовых сетях функции организации трафика (Traffic Engineering или TE) вряд ли будут полезны. Без TE виртуальные каналы QVC всегда используют кратчайший путь, но и в этом случае нет гарантии получения каждой квантовой конечной точкой пар Белла с требуемой скоростью и достоверностью. Это аналогично услугам доставки по возможности (best effort) в классических сетях. При наличии TE для QVC выбирается путь с гарантией запрошенных ресурсов (например, BPPS), а также учитываются возможности маршрутизаторов и каналов, уже занятые другими виртуальными каналами. Это аналогично расширениям TE для OSPF и IS-IS с целью отслеживания доступных ресурсов и учёту ограничений при выборе кратчайшего пути (Constrained Shortest Path First или CSPF), чтобы при расчёте оптимального пути принимать во внимание доступность ресурсов и другие ограничения. Использование TE предполагает контроль вызовов (Call Admission Control или CAC), когда сеть отклоняет виртуальные соединения, для которых невозможно заранее гарантировать запрошенное качество обслуживания. Как вариант, сеть может вытеснять соединения с низким приоритетом для освобождения ресурсов.

Квантовым сетям нужны сигнальные функции – после расчёта QVC сигнализация служит для установки «правил пересылки» в плоскости данных каждого квантового маршрутизатора на пути. Сигнализация может быть распределенной, подобно протоколу резервирования ресурсов (Resource Reservation Protocol или RSVP) в MPLS, или централизованной, подобно OpenFlow.

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

В квантовых сетях трафик плоскости управления (сообщения маршрутизации и сигнализации) передаётся по классическим каналам, а трафик плоскости данных (кубиты пар Белла) – по отдельным квантовым каналам. Это отличается от большинства классических сетей, где оба типа трафика используют общий канал, а пакет содержит пользовательские данные и заголовки. Однако имеется классическая аналогия работе квантовых сетей – в обобщённых сетях MPLS (GMPLS) для трафика данных и управления применяются разные каналы. Кроме того, сети GMPLS поддерживают плоскости данных, где заголовки плоскости данных отсутствуют, например, сети с мультиплексированием по длине волны (Dense Wavelength Division Multiplexing или DWDM) и времени (Time-Division Multiplexing или TDM).

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

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

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

Этот документ не требует действий IANA.

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

[Abobeih18] Abobeih, M.H., Cramer, J., Bakker, M.A., Kalb, N., Markham, M., Twitchen, D.J., and T.H. Taminiau, “One-second coherence for a single electron spin coupled to a multi-qubit nuclear-spin environment”,2 Nature communications Vol. 9, Iss. 1, pp. 1-8, DOI 10.1038/s41467-018-04916-z, June 2018, <https://www.nature.com/articles/s41467-018-04916-z>.

[Aguado19] Aguado, A., Lopez, V., Lopez, D., Peev, M., Poppe, A., Pastor, A., Folgueira, J., and V. Martin, “The Engineering of Software-Defined Quantum Key Distribution Networks”,3 IEEE Communications Magazine Vol. 57, Iss. 7, pp. 20-26, DOI 10.1109/MCOM.2019.1800763, July 2019, <https://ieeexplore.ieee.org/document/8767074>.

[Askarani21] Askarani, M.F., Chakraborty, K., and G.C. do Amaral, “Entanglement distribution in multi-platform buffered-router-assisted frequency-multiplexed automated repeater chains”,4 New Journal of Physics Vol. 23, Iss. 6, 063078, DOI 10.1088/1367-2630/ac0a35, June 2021, <https://iopscience.iop.org/article/10.1088/1367-2630/ac0a35>.

[Aspect81] Aspect, A., Grangier, P., and G. Roger, “Experimental Tests of Realistic local Theories via Bell’s Theorem”,5 Physical Review Letters Vol. 47, Iss. 7, pp. 460-463, DOI 10.1103/PhysRevLett.47.460, August 1981, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.47.460>.

[Bennett14] Bennett, C.H. and G. Brassard, “Quantum cryptography: Public key distribution and coin tossing”,6 Theoretical Computer Science Vol. 560 (Part 1), pp. 7-11, DOI 10.1016/j.tcs.2014.05.025, December 2014, <https://www.sciencedirect.com/science/article/pii/S0304397514004241?via%3Dihub>.

[Bennett93] Bennett, C.H., Brassard, G., Crépeau, C., Jozsa, R., Peres, A., and W.K. Wootters, “Teleporting an unknown quantum state via dual classical and Einstein-Podolsky-Rosen channels”,7 Physical Review Letters Vol. 70, Iss. 13, pp. 1895-1899, DOI 10.1103/PhysRevLett.70.1895, March 1993, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.70.1895>.

[Bennett96] Bennett, C.H., DiVincenzo, D.P., Smolin, J.A., and W.K. Wootters, “Mixed-state entanglement and quantum error correction”,8 Physical Review A Vol. 54, Iss. 5, pp. 3824-3851, DOI 10.1103/PhysRevA.54.3824, November 1996, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.54.3824>.

[Bradley19] Bradley, C.E., Randall, J., Abobeih, M.H., Berrevoets, R.C., Degen, M.J., Bakker, M.A., Markham, M., Twitchen, D.J., and T.H. Taminiau, “A Ten-Qubit Solid-State Spin Register with Quantum Memory up to One Minute”,9 Physical Review X Vol. 9, Iss. 3, 031045, DOI 10.1103/PhysRevX.9.031045, September 2019, <https://journals.aps.org/prx/abstract/10.1103/PhysRevX.9.031045>.

[Briegel98] Briegel, H.-J., Dür, W., Cirac, J.I., and P. Zoller, “Quantum Repeaters: The Role of Imperfect Local Operations in Quantum Communication”,10 Physical Review Letters Vol. 81, Iss. 26, pp. 5932-5935, DOI 10.1103/PhysRevLett.81.5932, December 1998, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.81.5932>.

[Broadbent10] Broadbent, A., Fitzsimons, J., and E. Kashefi, “Measurement-Based and Universal Blind Quantum Computation”,11 Springer-Verlag 978-3-642-13678-8, DOI 10.1007/978-3-642-13678-8_2, June 2010, <https://link.springer.com/chapter/10.1007/978-3-642-13678-8_2>.

[Cacciapuoti19] Cacciapuoti, A.S., Caleffi, M., Van Meter, R., and L. Hanzo, “When Entanglement Meets Classical Communications: Quantum Teleportation for the Quantum Internet”,12 IEEE Transactions on Communications Vol. 68, Iss. 6, pp. 3808-3833, DOI 10.1109/TCOMM.2020.2978071, June 2020, <https://ieeexplore.ieee.org/document/9023997>.

[Cirac99] Cirac, J.I., Ekert, A.K., Huelga, S.F., and C. Macchiavello, “Distributed quantum computation over noisy channels”,13 Physical Review A Vol. 59, Iss. 6, 4249, DOI 10.1103/PhysRevA.59.4249, June 1999, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.59.4249>.

[Clark88] Clark, D., “The design philosophy of the DARPA internet protocols”,14 SIGCOMM ’88: Symposium proceedings on Communications architectures and protocols, pp. 106-114, DOI 10.1145/52324.52336, August 1988, <https://dl.acm.org/doi/abs/10.1145/52324.52336>.

[Crepeau02] Crépeau, C., Gottesman, D., and A. Smith, “Secure multi-party quantum computation”,15 STOC ’02: Proceedings of the thiry-fourth [sic] annual ACM symposium on Theory of computing, pp. 643-652, DOI 10.1145/509907.510000, May 2002, <https://dl.acm.org/doi/10.1145/509907.510000>.

[Dahlberg19] Dahlberg, A., Skrzypczyk, M., Coopmans, T., Wubben, L., Rozpędek, F., Pompili, M., Stolk, A., Pawełczak, P., Knegjens, R., de Oliveira Filho, J., Hanson, R., and S. Wehner, “A link layer protocol for quantum networks”,16 SIGCOMM ’19 Proceedings of the ACM Special Interest Group on Data Communication, pp. 159-173, DOI 10.1145/3341302.3342070, August 2019, <https://dl.acm.org/doi/10.1145/3341302.3342070>.

[Devitt13] Devitt, S.J., Munro, W.J., and K. Nemoto, “Quantum error correction for beginners”,17 Reports on Progress in Physics Vol. 76, Iss. 7, 076001, DOI 10.1088/0034-4885/76/7/076001, June 2013, <https://iopscience.iop.org/article/10.1088/0034-4885/76/7/076001>.

[DistCNOT] “Distributed CNOT”, Quantum Network Explorer by QuTech, 2023, <https://www.quantum-network.com/applications/7/>.

[Dur07] Dür, W. and H.J. Briegel, “Entanglement purification and quantum error correction”,18 Reports on Progress in Physics Vol. 70, Iss. 8, pp. 1381-1424, DOI 10.1088/0034-4885/70/8/R03, July 2007, <https://iopscience.iop.org/article/10.1088/0034-4885/70/8/R03>.

[Ekert91] Ekert, A.K., “Quantum cryptography based on Bell’s theorem”,19 Physical Review Letters Vol. 67, Iss. 6, pp. 661-663, DOI 10.1103/PhysRevLett.67.661, August 1991, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.67.661>.

[Elkouss11] Elkouss, D., Martinez-Mateo, J., and V. Martin, “Information Reconciliation for Quantum Key Distribution”,20 Quantum Information and Computation Vol. 11, No. 3 and 4, pp. 0226-0238, DOI 10.48550/arXiv.1007.1616, March 2011, <https://arxiv.org/abs/1007.1616>.

[Elliott03] Elliott, C., Pearson, D., and G. Troxel, “Quantum cryptography in practice”,21 SIGCOMM 2003: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 227-238, DOI 10.1145/863955.863982, August 2003, <https://dl.acm.org/doi/abs/10.1145/863955.863982>.

[Fitzsimons17] Fitzsimons, J.F. and E. Kashefi, “Unconditionally verifiable blind quantum computation”,22 Physical Review A Vol. 96, Iss. 1, 012303, DOI 10.1103/PhysRevA.96.012303, July 2017, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.96.012303>.

[Fowler10] Fowler, A.G., Wang, D.S., Hill, C.D., Ladd, T.D., Van Meter, R., and L.C.L. Hollenberg, “Surface Code Quantum Communication”,23 Physical Review Letters Vol. 104, Iss. 18, 180503, DOI 10.1103/PhysRevLett.104.180503, May 2010, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.104.180503>.

[Giovannetti04] Giovannetti, V., Lloyd, S., and L. Maccone, “Quantum-Enhanced Measurements: Beating the Standard Quantum Limit”,24 Science Vol. 306, Iss. 5700, pp. 1330-1336, DOI 10.1126/science.1104149, November 2004, <https://www.science.org/doi/10.1126/science.1104149>.

[Gottesman12] Gottesman, D., Jennewein, T., and S. Croke, “Longer-Baseline Telescopes Using Quantum Repeaters”,25 Physical Review Letters Vol. 109, Iss. 7, 070503, DOI 10.1103/PhysRevLett.109.070503, August 2012, <https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.109.070503>.

[Hensen15] Hensen, B., Bernien, H., Dréau, A.E., Reiserer, A., Kalb, N., Blok, M.S., Ruitenberg, J., Vermeulen, R.F.L., Schouten, R.N., Abellán, C., Amaya, W., Pruneri, V., Mitchell, M.W., Markham, M., Twitchen, D.J., Elkouss, D., Wehner, S., Taminiau, T.H., and R. Hanson, “Loophole-free Bell inequality violation using electron spins separated by 1.3 kilometres”,26 Nature Vol. 526, pp. 682-686, DOI 10.1038/nature15759, October 2015, <https://www.nature.com/articles/nature15759>.

[Jiang09] Jiang, L., Taylor, J.M., Nemoto, K., Munro, W.J., Van Meter, R., and M.D. Lukin, “Quantum repeater with encoding”,27 Physical Review A Vol. 79, Iss. 3, 032325, DOI 10.1103/PhysRevA.79.032325, March 2009, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.79.032325>.

[Joshi20] Joshi, S.K., Aktas, D., Wengerowsky, S., Lončarić, M., Neumann, S.P., Liu, B., Scheidl, T., Currás-Lorenzo, G., Samec, Z., Kling, L., Qiu, A., Razavi, M., Stipčević, M., Rarity, J.G., and R. Ursin, “A trusted node-free eight-user metropolitan quantum communication network”,28 Science Advances Vol. 6, no. 36, eaba0959, DOI 10.1126/sciadv.aba0959, September 2020, <https://www.science.org/doi/10.1126/sciadv.aba0959>.

[Kimble08] Kimble, H.J., “The quantum internet”,29 Nature Vol. 453, Iss. 7198, pp. 1023-1030, DOI 10.1038/nature07127, June 2008, <https://www.nature.com/articles/nature07127>.

[Komar14] Kómár, P., Kessler, E.M., Bishof, M., Jiang, L., Sørensen, A.S., Ye, J., and M.D. Lukin, “A quantum network of clocks”,30 Nature Physics Vol. 10, Iss. 8, pp. 582-587, DOI 10.1038/nphys3000, June 2014, <https://www.nature.com/articles/nphys3000>.

[Meignant19] Meignant, C., Markham, D., and F. Grosshans, “Distributing graph states over arbitrary quantum networks”,31 Physical Review A Vol. 100, Iss. 5, 052333, DOI 10.1103/PhysRevA.100.052333, November 2019, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.100.052333>.

[Moehring07] Moehring, D.L., Maunz, P., Olmschenk, S., Younge, K.C., Matsukevich, D.N., Duan, L.-M., and C. Monroe, “Entanglement of single-atom quantum bits at a distance”,32 Nature Vol. 449, Iss. 7158, pp. 68-71, DOI 10.1038/nature06118, September 2007, <https://www.nature.com/articles/nature06118>.

[Mural16] Muralidharan, S., Li, L., Kim, J., Lütkenhaus, N., Lukin, M.D., and L. Jiang, “Optimal architectures for long distance quantum communication”,33 Scientific Reports Vol. 6, pp. 1-10, DOI 10.1038/srep20463, February 2016, <https://www.nature.com/articles/srep20463>.

[Murta20] Murta, G., Grasselli, F., Kampermann, H., and D. Bruß, “Quantum Conference Key Agreement: A Review”,34 Advanced Quantum Technologies Vol. 3, Iss. 11, 2000025, DOI 10.1002/qute.202000025, September 2020, <https://onlinelibrary.wiley.com/doi/10.1002/qute.202000025>.

[Nagayama16] Nagayama, S., Choi, B.-S., Devitt, S., Suzuki, S., and R. Van Meter, “Interoperability in encoded quantum repeater networks”,35 Physical Review A Vol. 93, Iss. 4, 042338, DOI 10.1103/PhysRevA.93.042338, April 2016, <https://journals.aps.org/pra/abstract/10.1103/PhysRevA.93.042338>.

[Nagayama21] Nagayama, S., “Towards End-to-End Error Management for a Quantum Internet”,36 arXiv 2112.07185, DOI 10.48550/arXiv.2112.07185, December 2021, <https://arxiv.org/abs/2112.07185>.

[NielsenChuang] Nielsen, M.A. and I.L. Chuang, “Quantum Computation and Quantum Information”, Cambridge University Press, 2010, <http://mmrc.amss.cas.cn/tlb/201702/W020170224608149940643.pdf>.

[Park70] Park, J.L., “The concept of transition in quantum mechanics”,37 Foundations of Physics Vol. 1, Iss. 1, pp. 23-33, DOI 10.1007/BF00708652, March 1970, <https://link.springer.com/article/10.1007/BF00708652>.

[Peev09] Peev, M., Pacher, C., Alléaume, R., Barreiro, C., Bouda, J., Boxleitner, W., Debuisschert, T., Diamanti, E., Dianati, M., Dynes, J.F., Fasel, S., Fossier, S., Fürst, M., Gautier, J.-D., Gay, O., Gisin, N., Grangier, P., Happe, A., Hasani, Y., Hentschel, M., Hübel, H., Humer, G., Länger, T., Legré, M., Lieger, R., Lodewyck, J., Lorünser, T., Lütkenhaus, N., Marhold, A., Matyus, T., Maurhart, O., Monat, L., Nauerth, S., Page, J.-B., Poppe, A., Querasser, E., Ribordy, G., Robyr, S., Salvail, L., Sharpe, A.W., Shields, A.J., Stucki, D., Suda, M., Tamas, C., Themel, T., Thew, R.T., Thoma, Y., Treiber, A., Trinkler, P., Tualle-Brouri, R., Vannel, F., Walenta, N., Weier, H., Weinfurter, H., Wimberger, I., Yuan, Z.L., Zbinden, H., and A. Zeilinger, “The SECOQC quantum key distribution network in Vienna”,38 New Journal of Physics Vol. 11, Iss. 7, 075001, DOI 10.1088/1367-2630/11/7/075001, July 2009, <https://iopscience.iop.org/article/10.1088/1367-2630/11/7/075001>.

[Pompili21.1] Pompili, M., Hermans, S.L.N., Baier, S., Beukers, H.K.C., Humphreys, P.C., Schouten, R.N., Vermeulen, R.F.L., Tiggelman, M.J., dos Santos Martins, L., Dirkse, B., Wehner, S., and R. Hanson, “Realization of a multinode quantum network of remote solid-state qubits”,39 Science Vol. 372, No. 6539, pp. 259-264, DOI 10.1126/science.abg1919, April 2021, <https://www.science.org/doi/10.1126/science.abg1919>.

[Pompili21.2] Pompili, M., Delle Donne, C., te Raa, I., van der Vecht, B., Skrzypczyk, M., Ferreira, G., de Kluijver, L., Stolk, A.J., Hermans, S.L.N., Pawełczak, P., Kozlowski, W., Hanson, R., and S. Wehner, “Experimental demonstration of entanglement delivery using a quantum network stack”,40 npj Quantum Information Vol. 8, 121, DOI 10.4121/16912522, October 2022, <https://www.nature.com/articles/s41534-022-00631-2>.

[QI-Scenarios] Wang, C., Rahman, A., Li, R., Aelmans, M., and K. Chakraborty, “Application Scenarios for the Quantum Internet”, Work in Progress, Internet-Draft, draft-irtf- qirg-quantum-internet-use-cases-15, 10 March 2023, <https://datatracker.ietf.org/doc/html/draft-irtf-qirg-quantum-internet-use-cases-15>.

[Qin17] Qin, H. and Y. Dai, “Dynamic quantum secret sharing by using d-dimensional GHZ state”, Quantum information processing Vol. 16, Iss. 3, 64, DOI 10.1007/s11128-017-1525-y, January 2017, <https://link.springer.com/article/10.1007/s11128-017-1525-y>.

[QKD] “Quantum Key Distribution”, Quantum Network Explorer by QuTech, 2023, <https://www.quantum-network.com/applications/5/>.

[RFC1958] Carpenter, B., Ed., “Architectural Principles of the Internet”, RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.

[Sangouard11] Sangouard, N., Simon, C., de Riedmatten, H., and N. Gisin, “Quantum repeaters based on atomic ensembles and linear optics”,41 Reviews of Modern Physics Vol. 83, Iss. 1, pp. 33-80, DOI 10.1103/RevModPhys.83.33, March 2011, <https://journals.aps.org/rmp/abstract/10.1103/RevModPhys.83.33>.

[Satoh17] Satoh, T., Nagayama, S., Oka, T., and R. Van Meter, “The network impact of hijacking a quantum repeater”,42 Quantum Science and Technology Vol. 3, Iss. 3, 034008, DOI 10.1088/2058-9565/aac11f, May 2018, <https://iopscience.iop.org/article/10.1088/2058-9565/aac11f>.

[Satoh20] Satoh, T., Nagayama, S., Suzuki, S., Matsuo, T., Hajdušek, M., and R. Van Meter, “Attacking the Quantum Internet”,43 IEEE Transactions on Quantum Engineering, vol. 2, pp. 1-17, DOI 10.1109/TQE.2021.3094983, September 2021, <https://ieeexplore.ieee.org/document/9477172>.

[SutorBook] Sutor, R.S., “Dancing with Qubits”, Packt Publishing, November 2019, <https://www.packtpub.com/product/dancing-with-qubits/9781838827366>.

[Tang19] Tang, B.-Y., Liu, B., Zhai, Y.-P., Wu, C.-Q., and W.-R. Yu, “High-speed and Large-scale Privacy Amplification Scheme for Quantum Key Distribution”,44 Scientific Reports Vol. 9, DOI 10.1038/s41598-019-50290-1, October 2019, <https://www.nature.com/articles/s41598-019-50290-1>.

[Teleportation] “State teleportation”, Quantum Network Explorer by QuTech, 2023, <https://www.quantum-network.com/applications/1/>.

[Terhal04] Terhal, B.M., “Is entanglement monogamous?”,45 IBM Journal of Research and Development Vol. 48, Iss. 1, pp. 71-78, DOI 10.1147/rd.481.0071, January 2004, <https://ieeexplore.ieee.org/document/5388928>.

[VanMeter13.1] Van Meter, R. and J. Touch, “Designing quantum repeater networks”,46 IEEE Communications Magazine Vol. 51, Iss. 8, pp. 64-71, DOI 10.1109/MCOM.2013.6576340, August 2013, <https://ieeexplore.ieee.org/document/6576340>.

[VanMeter13.2] Van Meter, R., Satoh, T., Ladd, T.D., Munro, W.J., and K. Nemoto, “Path selection for quantum repeater networks”,47 Networking Science Vol. 3, Iss. 1-4, pp. 82-95, DOI 10.1007/s13119-013-0026-2, December 2013, <https://link.springer.com/article/10.1007/s13119-013-0026-2>.

[VanMeterBook] Van Meter, R., “Quantum Networking”, ISTE Ltd/John Wiley and Sons. Inc., Print ISBN 978-1-84821-537-5, DOI 10.1002/9781118648919, April 2014, <https://onlinelibrary.wiley.com/doi/book/10.1002/9781118648919>.

[Wang21] Wang, L.-J., Zhang, K.-Y., Wang, J.-Y., Cheng, J., Yang, Y.-H., Tang, S.-B., Yan, D., Tang, Y.-L., Liu, Z., Yu, Y., Zhang, Q., and J.-W. Pan, “Experimental authentication of quantum key distribution with post-quantum cryptography”,48 npj Quantum Information Vol. 7, pp. 1-7, DOI 10.1038/s41534-021-00400-7, May 2021, <https://www.nature.com/articles/s41534-021-00400-7>.

[Wehner18] Wehner, S., Elkouss, D., and R. Hanson, “Quantum internet: A vision for the road ahead”,49 Science Vol. 362, Iss. 6412, DOI 10.1126/science.aam9288, October 2018, <https://www.science.org/doi/full/10.1126/science.aam9288>.

[Wei22] Wei, S.-H., Jing, B., Zhang, X.-Y., Liao, J.-Y., Yuan, C.-Z., Fan, B.-Y., Lyu, C., Zhou, D.-L., Wang, Y., Deng, G.-W., Song, H.-Z., Oblak, D., Guo, G.-C., and Q. Zhou, “Towards Real-World Quantum Networks: A Review”,50 Laser and Photonics Reviews Vol. 16, 2100219, DOI 10.1002/lpor.202100219, January 2022, <https://onlinelibrary.wiley.com/doi/10.1002/lpor.202100219>.

[Wootters82] Wootters, W.K. and W.H. Zurek, “A single quantum cannot be cloned”, Nature Vol. 299, Iss. 5886, pp. 802-803, DOI 10.1038/299802a0, October 1982, <https://www.nature.com/articles/299802a0>.

[ZOO] “The Quantum Protocol Zoo”, November 2019, <https://wiki.veriqloud.fr/>.

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

Авторы благодарны Carlo Delle Donne, Matthew Skrzypczyk, Axel Dahlberg, Mathias van den Bossche, Patrick Gelard, Chonggang Wang, Scott Fluhrer, Joey Salazar, Joseph Touch и всему сообществу QIRG за очень полезные рецензии и комментарии у документу.

WK и SW подтверждают финансирование от EU Flagship on Quantum Technologies, Quantum Internet Alliance (No. 820445).

rdv подтверждает поддержку Air Force Office of Scientific Research по гранту FA2386-19-1-4038.

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

Wojciech Kozlowski
QuTech
Building 22
Lorentzweg 1
2628 CJ Delft
Netherlands
Email: w.kozlowski@tudelft.nl
 
Stephanie Wehner
QuTech
Building 22
Lorentzweg 1
2628 CJ Delft
Netherlands
Email: s.d.c.wehner@tudelft.nl
 
Rodney Van Meter
Keio University
5322 Endo, Fujisawa, Kanagawa
252-0882
Japan
Email: rdv@sfc.wide.ad.jp
 
Bruno Rijsman
Individual
Email: brunorijsman@gmail.com
 
Angela Sara Cacciapuoti
University of Naples Federico II
Department of Electrical Engineering and Information Technologies
Claudio 21
80125 Naples
Italy
Email: angelasara.cacciapuoti@unina.it
 
Marcello Caleffi
University of Naples Federico II
Department of Electrical Engineering and Information Technologies
Claudio 21
80125 Naples
Italy
Email: marcello.caleffi@unina.it
 
Shota Nagayama
Mercari, Inc.
Roppongi Hills Mori Tower 18F
6-10-1 Roppongi, Minato-ku, Tokyo
106-6118
Japan
Email: shota.nagayama@mercari.com

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

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

nmalykh@protokols.ru

1Internet Research Task Force – комиссия по исследовательским задачам Internet.

2Полный текст доступен по ссылке. Прим. перев.

3Полный текст доступен по ссылке. Прим. перев.

4Полный текст доступен по ссылке. Прим. перев.

5Полный текст доступен по ссылке. Прим. перев.

6Полный текст доступен по ссылке. Прим. перев.

7Полный текст доступен по ссылке. Прим. перев.

8Полный текст доступен по ссылке. Прим. перев.

9Полный текст доступен по ссылке. Прим. перев.

10Полный текст доступен по ссылке. Прим. перев.

11Полный текст доступен по ссылке. Прим. перев.

12Полный текст доступен по ссылке. Прим. перев.

13Полный текст доступен по ссылке. Прим. перев.

14Полный текст доступен по ссылке. Прим. перев.

15Полный текст доступен по ссылке. Прим. перев.

16Полный текст доступен по ссылке. Прим. перев.

17Полный текст доступен по ссылке. Прим. перев.

18Полный текст доступен по ссылке. Прим. перев.

19Полный текст доступен по ссылке. Прим. перев.

20Полный текст доступен по ссылке. Прим. перев.

21Полный текст доступен по ссылке. Прим. перев.

22Полный текст доступен по ссылке. Прим. перев.

23Полный текст доступен по ссылке. Прим. перев.

24Полный текст доступен по ссылке. Прим. перев.

25Полный текст доступен по ссылке. Прим. перев.

26Полный текст доступен по ссылке. Прим. перев.

27Полный текст доступен по ссылке. Прим. перев.

28Полный текст доступен по ссылке. Прим. перев.

29Полный текст доступен по ссылке. Прим. перев.

30Полный текст доступен по ссылке. Прим. перев.

31Полный текст доступен по ссылке. Прим. перев.

32Полный текст доступен по ссылке. Прим. перев.

33Полный текст доступен по ссылке. Прим. перев.

34Полный текст доступен по ссылке. Прим. перев.

35Полный текст доступен по ссылке. Прим. перев.

36Полный текст доступен по ссылке. Прим. перев.

37Полный текст доступен по ссылке. Прим. перев.

38Полный текст доступен по ссылке. Прим. перев.

39Полный текст доступен по ссылке. Прим. перев.

40Полный текст доступен по ссылке. Прим. перев.

41Полный текст доступен по ссылке. Прим. перев.

42Полный текст доступен по ссылке. Прим. перев.

43Полный текст доступен по ссылке. Прим. перев.

44Полный текст доступен по ссылке. Прим. перев.

45Полный текст доступен по ссылке. Прим. перев.

46Полный текст доступен по ссылке. Прим. перев.

47Полный текст доступен по ссылке. Прим. перев.

48Полный текст доступен по ссылке. Прим. перев.

49Полный текст доступен по ссылке. Прим. перев.

50Полный текст доступен по ссылке. Прим. перев.

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

RFC 9371 Registration Procedures for Private Enterprise Numbers (PENs)

Internet Engineering Task Force (IETF)                          A. Baber
Request for Comments: 9371                                          IANA
Category: Informational                                       P. Hoffman
ISSN: 2070-1721                                                    ICANN
                                                              March 2023

Registration Procedures for Private Enterprise Numbers (PENs)

Процедуры регистрации PEN

PDF

Аннотация

В этот документе описано как IANA регистрирует частные номера предприятий (Private Enterprise Number или PEN). Описано, как запросить новое значение PEN и изменить имеющийся PEN, а также приведён краткий обзор использования PEN.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

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

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

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

Авторские права (Copyright (c) 2023) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Частные номера предприятий (PEN) являются идентификаторами, которые можно использовать везде, где могут применяться идентификаторы объектов ASN.1 (object identifier или OID) [ASN1]. Исходно PEN были разработаны для того, чтобы организации, которым нужно указать себя в конфигурации базы данных управления (Management Information Base или MIB) простого протокола управления сетью (Simple Network Management Protocol или SNMP) [RFC3411], могли это сделать достаточно просто. PEN также полезны в приложениях или языке настройки, которым нужны OID для идентификации организаций.

Оператор функций IANA (Functions Operator), который в этом документе обозначается IANA, управляет и поддерживает реестр PEN, консультируясь с IESG. Значения PEN выдаются из префикса OID, выделенного для IANA – 1.3.6.1.4.1. В (устаревшей) нотации имён владельцев в дереве OID это будет иметь вид

   1   3   6   1        4       1
   iso.org.dod.internet.private.enterprise

PEN – это идентификатор OID, начинающийся с префикса PEN, т. е. OID 1.3.6.1.4.1.32473 является PEN.

1.1. Применение PEN

После назначения PEN организации, физическому лицу или иному субъекту тот может использовать PEN сам по себе (возможно для представления уполномоченных) или как корень для других OID, связанных с ним. Например, если кому-то назначен PEN 1.3.6.1.4.1.32473, он может использовать 1.3.6.1.4.1.32473.7 для указания идентификатора протокола, а 1.3.6.1.4.1.32473.12.3 – для указания набора алгоритмов, поддерживающих этот протокол.

Ни IANA, ни IETF не контролируют использование PEN. Фактически, такой контроль не доступен никому, кроме обладателя (assignee), поэтому номера называются частными. Точно так же никто не может помешать обладателю, не являющемуся владельцем зарегистрированного PEN использовать этот или иной номер PEN по своему усмотрению.

Очень часто PEN применяются для представления уникальных идентификаторов протоколов IETF. В файлах конфигурации SNMP MIB значения PEN применяются для указания источников данных. В число протоколов, использующих PEN как идентификаторы, входят RADIUS [RFC2865], Diameter [RFC6733], Syslog [RFC5424], RSVP [RFC5284], vCard [RFC6350].

2. Назначение PEN

Значения PEN выделяет IANA. Реестр доступен по ссылке <https://www.iana.org/assignments/enterprise-numbers> и запросы на выделение новых значений или изменение имеющихся можно представлять по тому же URL.

IANA поддерживает реестр PEN в соответствии с процедурой First Come First Served, описанной в [RFC8126]. Значения выделяются по порядку.

2.1. Запрос выделения PEN

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

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

IANA может отказаться обрабатывать оскорбительные (abusive) запросы.

2.2. Изменение имеющейся записи

Любые сведения, связанные с запрошенным значением могут быть изменены (включая имя обладателя).

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

2.3. Удаление записи PEN

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

3. Специфика реестра PEN

Диапазон значений после префикса PEN составляет 0 – 232-1, значения 0 и 4294967295 (232-1) являются резервными. Отметим, что в исходном определении PEN не была задана верхняя граница, но позднее её внесли, поскольку протоколы IETF ограничивают размер этих значений. Например, протокол Diameter [RFC6733] ограничивает значения величиной 232-1.

Значение PEN 32473 зарезервировано для использования в документации в качестве примера, как указано в [RFC5612].

Значения в реестре с неясной принадлежностью помечены как резервные (Reserved) и не будут выделяться новым организациям или частным лицам без консультации с IESG.

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

В соответствии с этим документом агентство IANA внесло в реестр PEN указанные ниже изменения.

  • Значения 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975 и 11670 – 11769, которые были пропущены в реестре, указаны как резервные (Reserved). В соответствии с [RFC8126] резерв может отменить IESG.

  • Этот документ указан в полее реестра Reference.

  • В качестве процедуры регистрации указано выделение в порядке запросов (First Come First Served).

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

Регистрация PEN на оказывает существенного влияния на безопасность.

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

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

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

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

[ASN1] ITU-T, “Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, ITU-T Recommendation X.690, February 2021, <https://www.itu.int/rec/T-REC-X.690/en>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks”, STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC5284] Swallow, G. and A. Farrel, “User-Defined Errors for RSVP”, RFC 5284, DOI 10.17487/RFC5284, August 2008, <https://www.rfc-editor.org/info/rfc5284>.

[RFC5424] Gerhards, R., “The Syslog Protocol”, RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.

[RFC5612] Eronen, P. and D. Harrington, “Enterprise Number for Documentation Use”, RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/info/rfc5612>.

[RFC6350] Perreault, S., “vCard Format Specification”, RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>.

[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., “Diameter Base Protocol”, RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.

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

Раннюю черновую версию этого документа подготовили Pearl Liang и Alexey Melnikov. Значительный вклад в документ внесли Dan Romascanu, Bert Wijnen, David Conrad, Michelle Cotton, Benoit Claise.

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

Amanda Baber
Internet Assigned Numbers Authority
PTI/ICANN
12025 Waterfront Drive
Los Angeles, 90094
United States of America
Email: amanda.baber@iana.org
 
 
Paul Hoffman
ICANN
12025 Waterfront Drive
Los Angeles, 90094
United States of America
Email: paul.hoffman@icann.org

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

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

RFC 9350 IGP Flexible Algorithm

Internet Engineering Task Force (IETF)                    P. Psenak, Ed.
Request for Comments: 9350                           Cisco Systems, Inc.
Category: Standards Track                                       S. Hegde
ISSN: 2070-1721                                   Juniper Networks, Inc.
                                                             C. Filsfils
                                                     Cisco Systems, Inc.
                                                           K. Talaulikar
                                                      Cisco Systems, Inc
                                                                A. Gulko
                                                            Edward Jones
                                                           February 2023

IGP Flexible Algorithm

Гибкий алгоритм IGP

PDF

Аннотация

Протоколы IGP исторически рассчитывают лучшие пути на основе метрики IGP, назначенной для каналов. Во многих сетях применяется RSVP-TE или SR-TE (Segment Routing – Traffic Engineering) для направления трафика по пути, рассчитанному с использованием иной метрики или ограничений, нежели для лучшего пути IGP. Этот документ предлагает решение, позволяющее протоколам IGP самостоятельно рассчитывать пути через сеть с учётом ограничений. Документ также задаёт способ использования SR Prefix-SID и локаторов SRv6 для направления пакетов по путям, рассчитанным на основе ограничений.

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

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

Для преодоления таких ограничений были развёрнуты различные виды организации трафика (Traffic Engineering или TE), включая RSVP-TE и SR-TE, где компонент TE отвечает за расчёт путей на основе дополнительных показателей и/или ограничений. Такие пути нужно поместить в таблицы пересылки в дополнение или на замену исходных путей, рассчитанных IGP. Часто применяются туннели для представления организованных путей и механизмов, подобных описанному в [RFC3906], служащие заменой для исходных путей IGP.

Этот документ задаёт набор расширений для IS-IS, OSPFv2 и OSPFv3, позволяющих маршрутизатору анонсировать TLV, которые указывают (a) тип расчёта и (b) метрики, а также (c) описывают ограничения топологии, применяемые при расчёте лучшего пути в топологии с ограничениями. Эту комбинацию типа расчёта, типа метрики и ограничений называют определением гибкого алгоритма (Flexible Algorithm Definition или FAD). Маршрутизатор, передающий такие TLV, задаёт значение Flex-Algorithm для выбранной комбинации FAD.

Этот документ также задаёт для маршрутизаторов способ использовать IGP для связывания конкретного Flex-Algorithm с Prefix-SID маршрутизации по сегментам (Segment Routing или SR) с плоскостью данных MPLS (SR-MPLS) [RFC8660] или локаторами SR через IPv6 (SRv6) [RFC8986]. Каждый такой Prefix-SID или локатор SRv6 тогда представляет путь, рассчитанный в соответствии с указанным Flex-Algorithm. В SRv6 это локатор, а не идентификатор сегмента (Segment Identifier или SID), держит привязку алгоритма.

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

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

3. Терминология

В этом разделе даны определения часто используемых в документе терминов.

Flexible Algorithm Definition (FAD)

Определение гибкого алгоритма – (a) тип расчёта, (b) тип метрики, (c) набор ограничений.

Flex-Algorithm

Числовой идентификатор из диапазона 128-255, связанный через конфигурацию с FAD.

Flexible Algorithm Participation

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

IGP Algorithm

Значение из реестра IGP Algorithm Types в группе реестров Interior Gateway Protocol (IGP) Parameters. Алгоритмы IGP представляются триплетом (calculation-type, metric-type, constraints), где второй и третий элементы необязательны.

ABR

Area Border Router – граничный маршрутизатор области. В терминолонии IS-IS называется также маршрутизатором уровня 1 (L1) или уровня 2 (L2).

ASBR

Autonomous System Border Router – граничный маршрутизатор автономной системы.

4. Гибкий алгоритм

При вычислении пути через сеть можно применять много разных ограничений. Некоторые сети развёрнуты как несколько плоскостей и простая форма ограничений может быть связана с использованием конкретной плоскости. Более сложные ограничения могут включать ту или иную расширенную метрику, как описано в [RFC8570]. Возможны также ограничений связанные с выбором определённых каналов или исключением каналов с определённой близостью (affinity). Допускается сочетание разных ограничений.

Для максимальной гибкости предоставляется механизм, позволяющий маршрутизатору указать конкретный тип расчёт (calculation-type) и метрики (metric-type), описать набор ограничений и назначить числовой идентификатор (Flex-Algorithm) такой комбинации. Сопоставление Flex-Algorithm с его предназначением является гибким и задаётся пользователем. Пока у всех маршрутизаторов домена есть общее представление Flex-Algorithm, расчёт маршрутов будет согласованным и трафик не будет попадать в петли.

Набор из (a) типа расчёта, (b) типа метрики и (c) ограничений называют определением гибкого алгоритма (FAD). Flex-Algorithm – это числовой идентификатор из диапазона 128-255, связанный через конфигурацию с FAD.

В реестре IANA IGP Algorithm Types задан набор значений для алгоритмов IGP, где для гибких алгоритмов выделены значения 128-255.

5. Анонсирование определения гибкого алгоритма

Для гарантии отсутствия петель пересылке на путях, рассчитанных с конкретным Flex-Algorithm, все маршрутизаторы, (a) настроенные на участие в определённом Flex-Algorithm и (b) находящиеся в одной области анонсирования FAD, должны согласовать определение Flex-Algorithm, как описано в последующих параграфах.

5.1. IS-IS FAD Sub-TLV

IS-IS Flexible Algorithm Definition (FAD) sub-TLV применяется для анонсирования определения Flex-Algorithm. IS-IS FAD sub-TLV анонсируются как sub-TLV в IS-IS Router CAPABILITY TLV (242), определённом в [RFC7981]. Формат IS-IS FAD sub-TLV приведён ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |Flex-Algorithm |  Metric-Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Calc-Type   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sub-TLVs                             |
   +                                                               +
   |                            ...                                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

26

Length

Число октетов в зависимости от включённых sub-TLV.

Flex-Algorithm

Номер гибкого алгоритма – 1-октетное значение от 128 до 255, включительно.

Metric-Type

Тип метрики из реестра IANA IGP Metric-Type (параграф 18.1.2) для использования в расчётах. Заданы 3 значения:

0

Метрика IGP

1

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC8570], представленная как определяемый приложением атрибут канала в соответствии с [RFC8919] и разделом 12 этого документа.

2

Traffic Engineering Default Metric в соответствии с параграфом 3.7 в [RFC5305], представленная как определяемый приложением атрибут канала в соответствии с [RFC8919] и разделом 12 этого документа.

Calc-Type

Тип расчёта – значение от 0 до 127 (включительно) из реестра IANA IGP Algorithm Types в группе реестрв Interior Gateway Protocol (IGP) Parameters. Алгоритмы IGP из диапазона 0-127 имеют триплет (cтип расчета, тип метрики, ограничения). При использовании для задания calculation-type в FAD sub-TLV применяется лишь calculation-type для соответствующего IGP Algorithm, наследование метрики и ограничений недопустимо. Если требуемым типом расчёта является Shortest Path First, в поле должно помещаться значение 0.

Priority

Значение от 0 до 255 (включительно), задающее приоритет анонса. Большее значение указывает более высокий приоритет. Использование приоритета описано в параграфе 5.3. Базовая обработка FAD TLV.

Sub-TLVs

Необязательные sub-TLV.

IS-IS FAD sub-TLV можно анонсировать в пути с коммутацией по меткам (Label Switched Path или LSP) с любым номером. Маршрутизатор IS-IS может анонсировать более 1 IS-IS FAD sub-TLV для данного гибкого алгоритма (см. 6. Sub-TLV для IS-IS FAD Sub-TLV).

IS-IS FAD sub-TLV имеет область (уровень) действия. В Router Capability TLV с FAD sub-TLV должен быть сброшен флаг S.

Маршрутизатор IS-IS L1/L2 можно настроить для регенерации выигравшего FAD с уровня 2 без изменений в область уровня 1. Регенерация FAD sub-TLV from с уровня 2 на уровень 1 определяется маршрутизатором L1/L2, а не источником анонса FAD на уровне 2. В таких случаях регенерированный FAD sub-TLV будет анонсироваться в Router Capability TLV уровня 1, исходящими от маршрутизатора L1/L2.

Маршрутизатору L1/L2 недопустимо регенерировать какие-либо FAD sub-TLV с уровня 1 на уровень 2.

5.2. OSPF FAD TLV

OSPF FAD TLV анонсируются как TLV верхнего уровня в Router Information (RI) Link State Advertisement (LSA), заданных в [RFC7770]. Формат OSPF FAD TLV показан на рисунке

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |   Metric-Type |   Calc-Type   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sub-TLVs                           |
   +                                                               +
   |                               ...                             |

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

16

Length

Число октетов в зависимости от включённых sub-TLV.

Flex-Algorithm

Номер гибкого алгоритма – 1-октетное значение от 128 до 255, включительно.

Metric-Type

Тип метрики из реестра IANA IGP Metric-Type (параграф 18.1.2) для использования в расчётах. Заданы 3 значения:

0

Метрика IGP

1

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC7471], представленная как определяемый приложением атрибут канала в соответствии с [RFC8920] и разделом 12 этого документа.

2

Traffic Engineering Default Metric в соответствии с параграфом 2.5.5 в [RFC3630], представленная как определяемый приложением атрибут канала в соответствии с [RFC8920] и разделом 12 этого документа.

Calc-Type

См. описание в параграфе 5.1.

Priority

См. описание в параграфе 5.1.

Sub-TLVs

Необязательные sub-TLV.

При получении нескольких OSPF FAD TLV для одного гибкого алгоритма от данного маршрутизатора получатель должен использовать первый экземпляр TLV в RI LSA. Если OSPF FAD TLV для одного Flex-Algorithm присутствуют в нескольких RI LSA с разными сферами лавинной рассылки, должен использоваться OSPF FAD TLV из RI LSA с лавинной рассылкой по области (area-scoped). Если OSPF FAD TLV для одного и того же алгоритма присутствует в разных RI LSA с одинаковой лавинной рассылкой, должен выбираться OSPF FAD TLV в RI LSA с численно наименьшим Instance ID, а последующие экземпляры OSPF FAD TLV должны игнорироваться.

RI LSA могут анонсироваться в любые определённые неинтерпретируемые (opaque) области лавинной рассылки (канал, область AS). Для анонсирования OSPF FAD TLV требуется лавинная рассылка в область (area-scoped). Лавинную рассылку в AS не следует применять, если локальная политика маршрутизатора-источника не указывает лавинную рассылку по домену (domain-wide.

5.3. Базовая обработка FAD TLV

В этом параграфе описана независимая от протокола обработка FAD TLV (OSPF) и FAD sub-TLV (IS-IS). В тексте используется обозначение FAD TLV, но содержимое параграфе применимо и к sub-TLV при использовании IS-IS.

Значение Flex-Algorithm должно быть от 128 до 255 (включительно), в ином случае FAD TLV должен игнорироваться. Анонсировать Flex-Algorithm нужно лишь части маршрутизаторов, участвующих в конкретном гибком алгоритме. Каждый маршрутизатор, настроенный на участие в определённом Flex-Algorithm должен выбрать определение Flex-Algorithm Definition на основе приведённых ниже правил с соблюдением их порядка. Это позволяет согласовать выбор FAD в случаях, когда разные маршрутизаторы анонсируют разные определения для данного Flex-Algorithm.

  1. Из анонсов FAD в области (включая локально созданные и полученные) нужно выбрать анонс с наибольшим значением приоритета.

  2. При наличии нескольких FAD с одинаковым приоритетом выбирается исходящее от маршрутизатора с наибольшим System-ID для IS-IS или Router ID для OSPFv2 и OSPFv3. Описание System-ID для IS-IS приведено в [ISO10589]. Для OSPFv2 и OSPFv3 стандартные Router ID описаны в [RFC2328] и [RFC5340].

Определение FAD, выбранное по этим правилам называют выигрышным (winning) FAD.

Маршрутизаторы, не настроенные на участие в конкретном Flex-Algorithm, должны игнорировать анонсы FAD TLV для таких Flex-Algorithm. Маршрутизатор, не участвующий в конкретном Flex-Algorithm, может анонсировать FAD для алгоритма. Принимающие маршрутизаторы должны рассматривать анонсы FAD независимо от участия их источника в Flex-Algorithm.

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

Если узел настроен на участие в гибком алгоритме, но не имеет доступного FAD или выбранное определение включает не поддерживаемое узлом значение calculation-type, metric-type, constraint, flag или sub-TLV, узел должен прерывать участие в этом алгоритме. Это предполагает, что недопустимо анонсировать участие в алгоритме, как указано в разделе 11 и узел должен удалить все связанные с этим алгоритмом состояния пересылки.

Определение Flex-Algorithm не зависит от топологии и применяется во всех топологиях, где маршрутизатор участвует.

6. Sub-TLV для IS-IS FAD Sub-TLV

Одним из ограничений IS-IS [ISO10589] является размер TLV/sub-TLV – не более 255 октетов. Для FAD sub-TLV имеется множество sub-sub-TLVs (см. ниже). Для данного Flex-Algorithm может оказаться, что общее число октетов для FAD превосходит максимальный размер, поддерживаемый в одном FAD sub-TLV. В таком случае FAD можно разделить на несколько sub-TLV, содержимое которых будет объединяться для полного определения Flex-Algorithm. При этом фиксированная часть FAD (5.1. IS-IS FAD Sub-TLV) должна быть идентична во всех FAD sub-TLV для данного Flex-Algorithm из данной промежуточной системы (IS). Если фиксированные части таких FAD sub-TLV различаются, должна использоваться фиксированная часть FAD sub-TLV из первого появления в LSP с наименьшим номером от данной IS.

Любая спецификация, задающая новый IS-IS FAD sub-sub-TLV, должна указывать, может ли FAD sub-TLV присутствовать в нескольких экземплярах в наборе FAD sub-TLV для данного Flex-Algorithm из данной IS и как их обрабатывать, если несколько экземпляров разрешено.

6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для исключения каналов из расчёта пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Exclude Admin Group (FAEAG) sub-TLV служит для анонсирования правила исключения, применяемого при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS FAEAG sub-TLV является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS FAEAG sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS FAEAG sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS FAEAG sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для включения каналов в расчёт пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Include-Any Admin Group (FAEAG) sub-TLV служит для анонсирования правила включения любых каналов при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS Flexible Algorithm Include-Any Admin Group является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

2

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS Flexible Algorithm Include-Any Admin Group sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV

FAD может задавать «цвета», применяемые оператором для включения каналов в расчёт пути с помощью Flex-Algorithm. IS-IS Flexible Algorithm Include-All Admin Group (FAEAG) sub-TLV служит для анонсирования правила включения всех каналов при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS Flexible Algorithm Include-All Admin Group является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3

Length

Зависит от размера Extended Admin Group и должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

IS-IS Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS Flexible Algorithm Include-All Admin Group sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV

IS-IS Flexible Algorithm Definition Flags (FADF) sub-TLV – это sub-TLV для IS-IS FAD sub-TLV. Формат показан на нисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

4

Length

Число октетов в поле Flags.

Flags

                       0 1 2 3 4 5 6 7...
                      +-+-+-+-+-+-+-+-+...
                      |M| | |          ...
                      +-+-+-+-+-+-+-+-+...

M

При установленном флаге должна применяться связанная с Flex-Algorithm метрика для расчёта межобластных и внешних префиксов. Флаг не применим для префиксов, анонсируемых как локаторы SRv6.

Задан новый реестр IANA IGP Flexible Algorithm Definition Flags для выделения битов поля Flags (см. параграф 18.2).

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

IS-IS FADF sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

IS-IS FADF sub-TLV недопустимо включать более 1 раза в набор FAD sub-TLV для данного Flex-Algorithm из данной IS. При наличии нескольких экземпляров в таком наборе должен применяться IS-IS FADF sub-TLV из первого присутствия в LSP с наименьшим номером из данной IS, а остальные должны игнорироваться.

Если IS-IS FADF sub-TLV нет в IS-IS FAD sub-TLV, предполагается, что все биты флагов сброшены (0).

Если узел настроен на участие в конкретном гибком алгоритме, а выбранное определение Flex-Algorithm содержит в IS-IS FADF sub-TLV неподдерживаемый узлом флаг, узел должен выйти из участия в этом алгоритме. В будущем могут быть определены новые флаги и реализация должна проверять все биты в полученном IS-IS FADF sub-TLV, а не только определённые в данный момент.

M-flag недопустимо применять при расчёте достижимости префиксов SRv6 Locator.

6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV

FAD может задавать группы каналов с общим риском (Shared Risk Link Group или SRLG), которые оператор хочет исключить из расчёта пути по гибкому алгоритму. IS-IS Flexible Algorithm Exclude SRLG (FAESRLG) sub-TLV служит для анонсирования правила исключения при расчёте пути, описанном в разделе 13. Расчёт путей по гибкому алгоритму. IS-IS FAESRLG sub-TLV является sub-TLV для IS-IS FAD sub-TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Shared Risk Link Group Value             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

5

Length

Определяется числом значений SRLG и должно быть кратно 4 октетам.

Shared Risk Link Group Value

Значение SRLG в соответствии с [RFC5307].

IS-IS FAESRLG sub-TLV недопустимо включать более 1 раза в один IS-IS FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать IS-IS FAD sub-TLV.

The IS-IS FAESRLG sub-TLV может неоднократно присутствовать в наборе FAD sub-TLV для данного гибкого алгоритма из данной IS. Это может потребоваться в случаях, когда общее число значение SRLG ведёт к превышению допустимого размера FAD sub-TLV. В таких случаях получатель должен объединять все значения из IS-IS FAESRLG sub-TLV в наборе.

7. Sub-TLV для OSPF FAD TLV

7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV

OSPF Flexible Algorithm Exclude Admin Group (FAEAG) sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF FAEAG sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV

OSPF Flexible Algorithm Include-Any Admin Group sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

2

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF Flexible Algorithm Include-Any Admin Group sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV

OSPF Flexible Algorithm Include-All Admin Group sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Extended Admin Group                     |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3

Length

Переменное значение, зависящее от размера Extended Admin Group. Должно быть кратно 4 октетам.

Extended Administrative Group

Extended Administrative Group в соответствии с [RFC7308].

The OSPF Flexible Algorithm Include-All Admin Group sub-TLV недопустимо включать более 1 раза в OSPF FAD TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD TLV.

7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV

OSPF Flexible Algorithm Definition Flags (FADF) sub-TLV – это sub-TLV для OSPF FAD TLV. Формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

4

Length

Число октетов в поле Flags. Должно быть кратно 4 октетам.

Flags

                       0 1 2 3 4 5 6 7...
                      +-+-+-+-+-+-+-+-+...
                      |M| | |          ...
                      +-+-+-+-+-+-+-+-+...

M

При установленном флаге должна применяться связанная с Flex-Algorithm метрика для расчёта межобластных и внешних префиксов. Флаг не применим для префиксов, анонсируемых как локаторы SRv6.

Задан новый реестр IANA IGP Flexible Algorithm Definition Flags для выделения битов поля Flags (см. параграф 18.2).

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

OSPF FADF sub-TLV недопустимо включать более 1 раза в один OSPF FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD sub-TLV.

Если OSPF FADF sub-TLV нет в OSPF FAD sub-TLV, предполагается, что все биты флагов сброшены (0).

Если узел настроен на участие в конкретном гибком алгоритме, а выбранное определение Flex-Algorithm содержит в OSPF FADF sub-TLV неподдерживаемый узлом флаг, узел должен выйти из участия в этом алгоритме. В будущем могут быть определены новые флаги и реализация должна проверять все биты в полученном OSPF FADF sub-TLV, а не только определённые в данный момент.

M-flag недопустимо применять при расчёте достижимости префиксов SRv6 Locator.

7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV

OSPF Flexible Algorithm Exclude SRLG (FAESRLG) sub-TLV – это sub-TLV для OSPF FAD TLV. Применение описано в параграфе 6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV, а формат показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Shared Risk Link Group Value                |
   +-                                                             -+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

5

Length

Определяется числом значений SRLG и должно быть кратно 4 октетам.

Shared Risk Link Group Value

Значение SRLG в соответствии с [RFC5307].

OSPF FAESRLG sub-TLV недопустимо включать более 1 раза в один OSPF FAD sub-TLV. При наличии нескольких экземпляров получатель должен игнорировать OSPF FAD sub-TLV.

8. IS-IS Flexible Algorithm Prefix Metric Sub-TLV

IS-IS Flexible Algorithm Prefix Metric (FAPM) sub-TLV поддерживает анонсирование связанной с Flex-Algorithm метрики для анонса данного префикса. IS-IS FAPM sub-TLV – это sub-TLV для TLV 135, 235, 236, 237. Формат показан ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |Flex-Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

6

Length

5 октетов

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Metric

4 октета сведений о метрике.

IS-IS FAPM sub-TLV может включаться в родительский TLV в нескольких экземплярах. При указании нескольких экземпляров с одним Flex-Algorithm должен применяться первый экземпляр, а остальные должны игнорироваться.

Если префикс анонсируется с метрикой префикса Flex-Algorithm, превышающей MAX_PATH_METRIC [RFC5305], этот префикс недопустимо учитывать при расчёте по гибкому алгоритму.

Применение метрики префиксов Flex-Algorithm описано в разделе 13. Расчёт путей по гибкому алгоритму.

IS-IS FAPM sub-TLV недопустимо анонсировать как sub-TLV для IS-IS SRv6 Locator TLV [RFC9352]. IS-IS SRv6 Locator TLV включает поля алгоритма и метрики, которые должны использоваться взамен. Если FAPM sub-TLV присутствует как sub-TLV в IS-IS SRv6 Locator TLV полученного LSP, такой FAPM sub-TLV должен игнорироваться.

9. OSPF Flexible Algorithm Prefix Metric Sub-TLV

The OSPF Flexible Algorithm Prefix Metric (FAPM) sub-TLV поддерживает анонсирование связанной с Flex-Algorithm метрики для анонса данного префикса. OSPF FAPM sub-TLV является sub-TLV для:

  • OSPFv2 Extended Prefix TLV [RFC7684];

  • указанных ниже OSPFv3 TLV, заданных в [RFC8362]:

    • Inter-Area Prefix TLV;

    • External-Prefix TLV.

Формат OSPF FAPM sub-TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |     Flags     |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Metric                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3 для OSPFv2, 26 для OSPFv3.

Length

8 октетов.

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Flags

1-октетное значение
                       0 1 2 3 4 5 6 7
                      +-+-+-+-+-+-+-+-+
                      |E|             |
                      +-+-+-+-+-+-+-+-+

E

Флаг в позиции 0, указывающий тип внешней метрики. Установленный бит указывает внешнюю метрику типа 2. Флаг применим лишь для внешних префиксов OSPF и «не вполне тупиковым» (Not-So-Stubby Area или NSSA) внешним префиксам. Это семантически эквивалентно биту E в Приложении A.4.5 к [RFC2328] и Приложении A.4.7 к [RFC5340] для OSPFv2 и OSPFv3, соответственно.

Биты 1 – 7

Должны сбрасываться инициатором и игнорироваться получателем.

Reserved

Должно устанавливаться в 0 и игнорироваться при получении.

Metric

4 октета сведений о метрике.

OSPF FAPM sub-TLV может включаться в родительский TLV в нескольких экземплярах. При указании нескольких экземпляров с одним Flex-Algorithm должен применяться первый экземпляр, а остальные должны игнорироваться.

Применение метрики префиксов Flex-Algorithm описано в разделе 13. Расчёт путей по гибкому алгоритму.

10. Гибкий алгоритм OSPF для анонсирования доступности ASBR

OSPF ABR анонсирует доступность ASBR в подключённых областях, чтобы позволить маршрутизаторам этих областей выполнять расчёт маршрутов для внешних префиксов, анонсируемых ASBR. Для расчётов внешних префиксов Flex-Algorithm нужны также расширения OSPF для анонсирования связанной с Flex-Algorithm доступности и метрики для ASBR, как описано в параграфе 13.1. Множество областей и доменов.

10.1. OSPFv2 Extended Inter-Area ASBR LSA

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA – это OSPF Opaque LSA [RFC5250], применяемый для анонсирования дополнительных атрибутов, связанных с доступностью OSPFv2 ASBR, который является внешним для области, но внутренним для домена OSPF. Семантически OSPFv2 EIA-ASBR LSA является эквивалентом summary-LSA типа 4 с фиксированным форматом [RFC2328]. В отличие от сводного LSA типа 4, Link State ID (LSID) в EIA-ASBR LSA не содержит ASBR Router ID, этот идентификатор передаётся в теле LSA. OSPFv2 EIA-ASBR LSA анонсируется маршрутизатором OSPFv2 ABR и рассылается лавинно внутри области (area-scoped).

OSPFv2 ABR генерирует EIA-ASBR LSA для ASBR когда он анонсирует для того summary-LSA типа 4 и нужно анонсировать 4 дополнительных атрибута для ASBR сверх передаваемых в Type 4 summary-LSA с фиксированным форматом. Маршрутизатору OSPFv2 ABR недопустимо анонсировать EIA-ASBR LSA для ASBR, которому он не анонсирует сводный LSA типа 4. Это гарантирует, что ABR не генерирует EIA-ASBR LSA для ASBR, к которому у него нет доступности при расчёте базовой топологии OSPFv2. OSPFv2 ABR не следует анонсировать EIA-ASBR LSA для ASBR при отсутствии дополнительных атрибутов для этого ASBR.

Формат OSPFv2 EIA-ASBR LSA показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |   LS Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Opaque Type  |                 Opaque ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

Поля LS age и Options определены в Приложении A.4.1 к [RFC2328].

Поле LS Type должно иметь значение 10, указывающее, что лавинная рассылка Opaque LSA происходит в локальной области [RFC5250].

Поле Opaque Type в OSPFv2 EIA-ASBR LSA имеет значение 11 и служит для разделения разных типов OSPFv2 Opaque LSA, описанных в разделе 3 [RFC5250].

Поле Opaque ID содержит произвольное значение , служащее для поддержки множества OSPFv2 EIA-ASBR LSA. Для OSPFv2 EIA-ASBR LSA поле Opaque ID не имеет семантического смысла кроме разделения OSPFv2 EIA-ASBR LSA, исходящих от одного OSPFv2 ABR. Если множество OSPFv2 EIA-ASBR LSA указывает один ASBR, следует использовать атрибуты из Opaque LSA с наименьшим Opaque ID.

Поля Advertising Router, LS sequence number и LS checksum определены в Приложении A.4.1 к [RFC2328].

Поле Length определено в Приложении A.4.1 к [RFC2328] и представляет общий размер (в октетах) Opaque LSA, включая заголовок LSA и все TLV (в том числе заполнение).

TLV в теле OSPFv2 EIA-ASBR LSA имеют такой же формат, который применяется расширениями OSPFv2 для организации трафика (TE) [RFC3630]. Переменный раздел TLV состоит из 1 или нескольких вложенных TLV, которые называют sub-TLV. Поле Length в TLV указывает размер поля значения в октетах (TLV без значения имеют Length = 0). TLV дополняются до 4-октетной границы, заполнение не учитывается в поле Length (т. е. при 3-октетном значении поле Length = 3, но общий размер TLV составит 8 октетов). Вложенные TLV также выравниваются по 32-битовым границам. Например при 1-октетном значении будет Length = 1 и 3 октета заполнения в конце поля значения. Для заполнения применяются нули (0).

10.1.1. OSPFv2 Extended Inter-Area ASBR TLV

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) TLV – это TLV верхнего уровня для OSPFv2 EIA-ASBR LSA и служит для анонсирования дополнительных атрибутов, связанных с достижимостью ASBR. Формат OSPFv2 EIA-ASBR TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ASBR Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1

Length

Число октетов3.

ASBR Router ID

4 октета OSPF Router ID маршрутизатора ASBR, чья информация передается.

Sub-TLVs

Переменный набор sub-TLV.

В каждом анонсе OSPFv2 EIA-ASBR LSA должен содержаться только 1 OSPFv2 EIA-ASBR TLV, а получатель должен игнорировать все остальные экземпляры этого TLV.

OSPFv2 EIA-ASBR TLV должен присутствовать в OSPFv2 EIA-ASBR LSA и должен включать хотя бы 1 sub-TLV, в противном случае получатель должен игнорировать OSPFv2 EIA-ASBR LSA.

10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV

OSPF Flexible Algorithm ASBR Metric (FAAM) sub-TLV поддерживает анонсы связанной с Flex-Algorithm метрики, относящейся к доступности данного ASBR, маршрутизатором ABR.

OSPF FAAM sub-TLV является sub-TLV для:

  • OSPFv2 Extended Inter-Area ASBR TLV, заданного в параграфе 10.1. OSPFv2 Extended Inter-Area ASBR LSA;

  • OSPFv3 Inter-Area-Router TLV, заданного в [RFC8362].

Формат OSPF FAAM sub-TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flex-Algorithm |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Metric                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1 для OSPFv2, 33 для OSPFv3.

Length

8 октетов.

Flex-Algorithm

1-октетное значение от 128 до 255, включительно.

Reserved

3 октета, которые должны устанавливаться в 0 и игнорироваться при получении.

Metric

4 октета сведений о метике.

OSPF FAAM sub-TLV может присутствовать в родительском TLV в нескольких экземплярах. При наличии нескольких экземпляров для одного Flex-Algorithm должен использоваться первый, в прочие должны игнорироваться.

Анонс доступности ASBR с использованием OSPF FAAM sub-TLV внутри OSPFv2 EIA-ASBR LSA соответствует параграфу 12.4.3 в [RFC2328], а внутри OSPFv3 E-Inter-Area-Router-LSA – параграфу 4.8.5 в [RFC5340]. Достижимость ASBR оценивается в контексте когкретного Flex-Algorithm.

Метрика FAAM, рассчитанная ABR, будет равна метрике достижения ASBR для данного Flex-Algorithm в исходной области или кумулятивной метрике через маршрутизаторы ABR, когда ASBR находится в удалённой области. Это по природе похоже на то, как устанавливается метрика при расчёте метрики достижимости ASBR с принятым по умолчанию алгоритмом для OSPFv2 Type 4 ASBR summary-LSA и OSPFv3 Inter-Area-Router-LSA.

OSPF ABR недопустимо включать OSPF FAAM sub-TLV с конкретным Flex-Algorithm в свой анонс доступности для ASBR между областями, пока ASBR не доступен в контексте этого Flex-Algorithm.

OSPF ABR должен включать OSPF FAAM sub-TLV как часть анонса достижимости ASBR между областями для любого Flex-Algorithm, где выигрышный FAD включает флаг M и ASBR доступен в контексте данного Flex-Algorithm.

Маршрутизаторы OSPF должны использовать OSPF FAAM sub-TLV для расчёта достижимости ASBR, если выигрышный FAD для конкретного Flex-Algorithm включает флаг M. Маршрутизаторам OSPF недопустимо использовать OSPF FAAM sub-TLV для расчёта достижимости ASBR для конкретного Flex-Algorithm, если выигрышный FAD для такого Flex-Algorithm не включает флаг M. Взамен должны применяться OSPFv2 Type 4 summary-LSA или OSPFv3 Inter-Area-Router-LSA, как указано в параграфе 16.2 [RFC2328] и параграфе 4.8.5 [RFC5340] для OSPFv2 и OSPFv3, соответственно.

Обработка нового или изменённого OSPF FAAM sub-TLV вызывает обработку внешних маршрутов, аналогично описанному в параграфе 16.5 [RFC2328] для OSPFv2 и параграфе 4.8.5 [RFC5340] для OSPFv3, с конкретным Flex-Algorithm. Расчёт внешнего маршрута OSPF и NSSA следует ограничивать гибкими алгоритмами, для которых выигрышные FAD включают флаг M.

Обработка OSPF FAAM sub-TLV не требует наличия эквивалентного OSPFv2 Type 4 summary-LSA или OSPFv3 Inter-Area-Router-LSA, анонсируемого тем же ABR внутри области. Наличие базового LSA не обязательно для применения расширенного LSA с OSPF FAAM sub-TLV.

11. Анонсирование участия узла в Flex-Algorithm

Алгоритм и IS, анонсирующие своё участие, принимают участие в данном Flex-Algorithm.

Пути для различных плоскостей данных могут рассчитываться с конкретным Flex-Algorithm. Каждая плоскость данных применяет свою пересылку по таким путям Flex-Algorithm. Для гарантиии наличия связанной с плоскостью данных пересылки для определённого Flex-Algorithm маршрутизатор должен анонсировать своё участие в данном Flex-Algorithm для каждой плоскости данных. Некоторые плоскости данных могут иметь общие анонсы участия (например, SR-MPLS и SRv6). Анонсирования участия в любом конкретном Flex-Algorithm в любой плоскости данных, регулируется условием, заданным в параграфе 5.3. Базовая обработка FAD TLV.

11.1. Анонсирование участия узла в SR

В [RFC8665], [RFC8666], [RFC8667] (расширения IGP SR) описывают применение алгоритма SR для расчёта лучшего пути IGP. Маршрутизаторы анонсируют поддержку SR-Algorithm как свойство узла в соответствии с упомянутыми выше расширениями IGP SR. Для анонсирования участия в конкретном Flex-Algorithm для SR, включая SR-MPLS и SRv6, должно анонсироваться значение Flex-Algorithm в SR-Algorithm TLV (OSPF) или sub-TLV (IS-IS).

Анонсы участия в гибком алгоритме маршрутизации по сегментам не зависят от топологии. Когда маршрутизатор анонсирует участие в SR-Algorithm, это применяется ко всем топологиям, в который участвует анонсирующий узел.

11.2. Анонсирование участия узла в других плоскостях данных

В этом параграфе рассмотрены соображения, связанные с возможностями других плоскостей данных объявить своё участие в конкретном Flex-Algorithm. Анонсы связанного с плоскостью данных участия в Flex-Algorithm могут зависеть от топологии и могут быть независимыми от неё в зависимости от самой плоскости данных. Связанные с плоскостью данных анонсы участия в Flex-Algorithm должны определяться для каждой плоскости данных, но в документе это не рассматривается.

12. Анонсирование атрибутов канала для Flex-Algorithm

При расчёте путей по гибкому алгоритму могут использоваться различные атрибуты каналов. Например, правила включения и исключения каналов по их близости (affinitY) может быть частью FAD, как указано в разделах 6 и 7.

Зависящие от приложения атрибуты каналов (заданные в [RFC8919] или [RFC8920]), которые применяются при расчёте Flex-Algorithm, должны использовать зависящие от приложения анонсы атрибутов канала (Application-Specific Link Attribute или ASLA), заданные в [RFC8919] или [RFC8920], если (для IS-IS) не установлен флаг L-flag в анонсе ASLA. Если флаг L установлен, должны применяться традиционные анонсы с учётом процедур и ограничений, заданных в параграфе 4.2 [RFC8919] и разделе 6. Sub-TLV для IS-IS FAD Sub-TLV.

Обязательное использование анонсов ASLA применяется к атрибутам каналов, специально отмеченным в этом документе (Min Unidirectional Link Delay, TE Default Metric, Administrative Group, Extended Administrative Group, Shared Risk Link Group), а также к любым другим атрибутам каналов, которые в будущем могут применяться для поддержки Flex-Algorithm.

Определён бит идентификатора приложения (Application Identifier Bit), указывающий, что анонс ASLA связан с приложением Flex-Algorithm. Этот бит устанавливается в маске стандартных битов приложения (Standard Application Bit Mask или SABM), определённой в [RFC8919] и [RFC8920]:

   Bit 3:  Flexible Algorithm (X-bit)

Анонсы ASLA Admin Group для использования гибким алгоритмом могут использовать кодирование Administrative Group или Extended Administrative Group.

Получатель, поддерживающий эту спецификацию, должен воспринимать ASLA Administrative Group и Extended Administrative Group TLV, как указано в [RFC8919] или [RFC8920]. В случае IS-IS при установленном флаге L в анонсе ASLA (см. параграф 4.2 с [RFC8919] получатель должен быть способен воспринимать Administrative Group TLV, заданные в [RFC5305], и Extended Administrative Group TLV, заданные [RFC7308].

13. Расчёт путей по гибкому алгоритму

Маршрутизатор должен быть настроен на участие в данном Flex-Algorithm и должен выбрать FAD на основе правил, заданных в параграфе 5.3. Базовая обработка FAD TLV, прежде чем он сможет рассчитывать пути по данному Flex-Algorithm.

При вычислении пути по гибкому алгоритму не применяется проверки двухсторонней связности, но при расчёте применяется результат независимой от Flex-Algorithm проверки двухсторонней связности.

Как указано в разделе 11, участие в любом конкретном Flex-Algorithm должно анонсироваться по плоскостям данных. Расчёт путей по любому конкретному гибкому алгоритму зависит от плоскости данных. Несколько плоскостей данных могут одновременно применять один гибкий алгоритм и FAD для него. Трафик каждой плоскости данных будет пересылаться на основе записей пересылки для этой конкретной плоскости данных. Определение FAD не зависит от плоскости данных и применяется всеми плоскостями данных Flex-Algorithm.

Обработка плоскостями данных узлов, не участвующих в гибком алгоритме, зависит от конкретной плоскости данных. Если плоскость данных желает при расчёте пути Flex-Algorithm учитывать лишь участвующие в алгоритме узлы, все узлы, которые не анонсируют своего участия в данном Flex-Algorithm для этой плоскости данных, должны вырезаться из топологии. Маршрутизация SR, включая SR-MPLS и SRv6, является плоскостью данных, которая должна применять такое вырезание при расчёте путей Flex-Algorithm.

При расчёте пути для данного Flex-Algorithm должны использоваться значения metric-type и calculation-type из FAD (5. Анонсирование определения гибкого алгоритма).

FAD может включать различные правила включения и исключения, а для указания конкретного бита в Admin Group или Extended Admin Group применяется термин color (цвет).

Для всех каналов топологии должны применяться указанные ниже правила (в приведённом порядке) вырезания каналов из топологии при расчётах Flex-Algorithm.

  1. Проверяется наличие правил исключения Administrative Group в FAD. Если такие правила имеются, проверяется, не установлен ли для канала цвет, являющийся частью правила, и при обнаружении такого цвета канал должен исключаться из расчёта.

  2. Проверяется наличие правил исключения SRLG в FAD. Если такие правила имеются, проверяется, входит ли канал в исключаемую SRLG, и при обнаружении вхождения канал должен исключаться из расчёта.

  3. Проверяется наличие правил включения любой (include-any) Administrative Group в FAD. Если такие правила имеются, проверяется, установлен ли для канала цвет, являющийся частью правила, и при отсутствии такого цвета канал должен исключаться из расчёта.

  4. Проверяется наличие правил включения всех (include-all) Administrative Group в FAD. Если такие правила имеются, проверяется, установлены ли для канала все цвета, являющиеся частью правила, и если не установлены все эти цвета, канал должен исключаться из расчёта.

  5. Если в FAD применяется что-либо, отличное от метрики IGP (5. Анонсирование определения гибкого алгоритма), и такая метрика не анонсируется для конкретного канала в топологию, где выполняется расчёт, такой канал должен исключаться из расчёта. Метрику со значением 0 недопустимо учитывать в этом случае.

13.1. Множество областей и доменов

Любой расчёт дерева кратчайших путей IGP (Shortest Path Tree) ограничен одной областью. Это относится и к расчётам Flex-Algorithm. С учётом того, что рассчитывающий маршрутизатор не видит топологии следующих областей или домена, связанный с Flex-Algorithm путь к префиксу, проходящий через разные области или домены, будет рассчитываться лишь для локальной области. Выходной маршрутизатор L1/L2 (ABR в OSPF) или ASBR для разных доменов будет выбираться на основе лучшего пути для данного Flex-Algorithm в локальной области и такой выходной маршрутизатор ABR или ASBR будет отвечать за расчёт лучшего пути Flex-Algorithm через следующую область или домен. Это может привести к созданию пути, который будет неоптимальным из-за ограничений Flex-Algorithm. Если ABR или ASBR не имеет доступа к префиксу для данного Flex-Algorithm в следующей области или домене, трафик может отбрасываться таким ABR/ASBR.

Для расчёта оптимального сквозного пути через несколько областей или доменов для любого Flex-Algorithm в разделах 8 и 9 определена метрика префикса гибкого алгоритма (FAPM). При расчёте внешних маршрутов для префиксов от ASBR в удалённых областях OSPF в параграфе 10.2 определена метрика FAAM для ABR, указывающая доступность ASBR вместе с метрикой для конкретного Flex-Algorithm.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, маршрутизатор ABR или ASBR должен включать FAPM (разделы 8 и 9) при анонсировании префикса, доступного в данном Flex-Algorithm между областями или доменами. Такая метрика будет совпадать с метрикой для достижения префикса в исходной области или домене для этого Flex-Algorithm. Это похоже на задание метрики при анонсировании между областями или доменами метрики для принятого по умолчанию алгоритма. Когда префикс недоступен в исходной области или домене в конкретном Flex-Algorithm, маршрутизатору ABR или ASBR недопустимо включать FAPM для Flex-Algorithm при анонсировании префикса между областями или доменами.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, метрика FAPM должна применяться при расчёте доступности внешнего или междоменного префикса. Если FAPM для Flex-Algorithm не включается в анонс доступности межобластного или внешнего префикса, такой префикс должен считаться недоступным в этом Flex-Algorithm. В случае OSPF для ASBR при отсутствии FAAM в анонсе локальных ABR маршрутизатор ASBR должен считаться недоступным для этого Flex-Algorithm и анонсы внешних префиксов от такого ASBR не учитываются в данном Flex-Algorithm.

Метрику префикса Flex-Algorithm и метрику OSPF Flex-Algorithm ASBR недопустимо применять в расчёте Flex-Algorithm, если выбранное на основе правил параграфа 5.3 определение FAD не включает флаг M, описанный в параграфах 6.4 и 7.4.

Если для случая OSPF при расчёте внешних маршрутов в Flex-Algorithm выигрышный FAD включает флаг M и анонсирующий ASBR находится в удалённой области, метрика будет суммой указнных ниже значений:

  • метрика FAPM для Flex-Algorithm, анонсированная ASBR с внешним маршрутом;

  • метрика доступа к ASBR для Flex-Algorithm от локального ABR, т. е. метрика FAAM для этого Flex-Algorithm, анонсированная ABR в локальной области этого ASBR;

  • зависимая от Flex-Algorithm метрика для доступа к локальному ABR.

По своей природе это похоже на расчёт метрики для маршрутов, полученных от удалённых ASBR в принятом по умолчанию алгоритме с использованием OSPFv2 Type 4 ASBR summary-LSA и OSPFv3 Inter-Area-Router-LSA.

Если определение FAD, выбранное на основе правил из параграфа 5.3, не включает флаг M, для расчёта маршрутов Flex-Algorithm должна применяться метрика IGP, связанная с достижимостью префикса, используемая базовыми протоколами IS-IS и OSPF. При расчёте внешних маршрутов в OSPF достижимость ASBR определяется на основе OSPFv2 Type 4 summary-LSA и OSFPv3 Inter-Area-Router-LSA.

Использовать Flex-Algorithm для достижимости префиксов между областями или доменами при сброшенном флаге M не рекомендуется. Причина заключается в том, что без явного анонса метрики префикса Flex-Algorithm (и анонса метрики Flex-Algorithm ASBR при расчёте внешних маршрутов OSPF) невозможно сделать вывод о доступности ABR или ASBR для межсетевого или междоменного префикса в следующей области или домене для данного Flex-Algorithm. Передача трафика Flex-Algorithm для такого префикса в сторону ABR или ASBR может привести к петле или постоянному отбрасыванию трафика.

В процессе расчёта маршрутов связанная с Flex-Algorithm метрика может превысить максимальное значение, которое может быть выражено 32-битовым числом без знака. В таких случаях при расчёте и в анонсах должно приниматься значение 0xFFFFFFFF.

FAPM недопустимо анонсировать с маршрутами IS-IS L1 или L2 внутри области, OSPFv2 или OSPFv3 внутри области. Если FAPM анонсируется с маршрутами этих типов, такая метрика должна игнорироваться при расчёте достижимости префиксов.

Флаг M в FAD не применим к префиксам, анонсируемым как локаторы SRv6. IS-IS SRv6 Locator TLV [RFC9352] включает поля Algorithm и Metric. При анонсировании SRv6 Locator между областями или доменами должно применяться поле Metric в Locator TLV для IS-IS независимо от флага M в анонсе FAD.

Анонсы внешних префиксов OSPF и NSSA могут включать ненулевой адрес пересылки в анонсах префиксов базового протокола. В таком случае связанная с Flex-Algorithm достижимость внешнего префикса определяется связанной с Flex-Algorithm достижимостью адреса пересылки.

В OSPF процедуры преобразования анонсов внешних префиксов NSSA в анонсы внешних префиксов, выполняемые NSSA ABR [RFC3101], не зависят от Flex-Algorithm. Транслятор NSSA должен включать OSPF FAPM sub-TLV для всех Flex-Algorithm, которые были в исходном анонсе внешнего префикса NSSA от NSSA ASBR в преобразованный анонс внешнего префикса независимо от его участия в этих Flex-Algorithm или доступности NSSA ASBR в них.

Область может быть разделена с точки зрения Flex-Algorithm из-за ограничений и/или метрики, применяемых в ней, с сохранением неразрывности в базовом алгоритме. В таких случаях некоторые адресаты внутри разделённой области могут стать недоступными в этом Flex-Algorithm и не смогут использовать межобластной путь. Это является следствием того, что анонсы доступности межобластных префиксов станут недоступными для внутренних получателей этой области. Рекомендуется минимизировать риск такого разделения за счёт достаточной избыточности внутри области для каждого применяемого Flex-Algorithm.

14. Flex-Algorithm и плоскость пересылки

В этом разделе описано использование путей Flex-Algorithm для пересылки.

14.1. Пересылка MPLS SR для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SR MPLS.

Анонсы Prefix-SID включают значение SR-Algorithm и поэтому связаны с ним. Prefix-SID также связаны с конкретной топологией, которая наследуется от связанного анонса достижимости префикса. Когда анонсированное значение алгоритма является значением Flex-Algorithm, Prefix-SID связывается с путями, рассчитанными по этому Flex-Algorithm в соответствующей топологии.

Путь Flex-Algorithm должен быть установлен в плоскости пересылки MPLS с использования метки MPLS, соответствующей Prefix-SID, анонсированному для этого Flex-Algorithm. Если Prefix-SID для данного Flex-Algorithm неизвестен, соответствующий Flex-Algorithm путь не может быть установлен в плоскости пересылки MPLS.

Трафик, который предполагается маршрутизировать по путям Flex-Algorithm, должен отбрасываться, если такие пути недоступны.

Дополнительные пути без петель (Loop Free Alternate или LFA) paths ([RFC6571] и его варианты) для данного Flex-Algorithm должны рассчитываться с теми же ограничениями, какие применяются для расчёта основных путей с этим Flex-Algorithm. Пути LFA должны использовать только Prefix-SID, анонсированные специально для данного алгоритма. Путям LFA недопустимо использовать Adjacency SID, относящийся к каналу, который был исключён из расчётов Flex-Algorithm.

Если применяется защита LFA для пути данного алгоритма Flex-Algorithm, всем маршрутизаторам области, участвующим в этом алгоритме, следует анонсировать хотя бы один, связанный с Flex-Algorithm, идентификатор Node-SID. Эти Node-SID служат для направления трафика по резервному пути, рассчитанному LFA.

14.2. Пересылка SRv6 для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SRv6.

В SRv6 узлу предоставляется конкретный (топология, алгоритм) локатор для каждой пары топология-алгоритм, поддерживаемой этим узлом. Каждый локатор является агрегатным префиксом для всех SID с совпадающей топологией и алгоритмом, предоставляемых на этом узле.

Анонс локатора SRv6 в IS-IS [RFC9352] включает значение MTID (Multi-Topology Identifier), связывающее локатор с конкретной топологией. Кроме того, анонс SRv6 включает значение алгоритма, явно связывающее локатор с конкретным алгоритмом. Когда значение алгоритма анонсируется с локатором, представляющим Flex-Algorithm, пути к префиксу локатора должны рассчитываться с использованием указанного Flex-Algorithm в связанной топологии.

Записи пересылки для префикса локатора, анонсированного в IS-IS, должны быть установлены в плоскости пересылки принимающих маршрутизаторов с поддержкой SRv6, когда в них участвует соответствующая топология/алгоритм. Записи пересылки для локаторов, связанных с Flex-Algorithm, в которых узел не участвует, недопустимо устанавливать в плоскости пересылки.

Когда локатор связан с Flex-Algorithm, пути LFA к префиксу локатора должны рассчитываться с применением такого Flex-Algorithm в связанной топологии, чтобы гарантировать соблюдение тех же ограничений, что и в расчёте основного пути. Пути LFA должны использовать лишь SRv6 SID, анонсированные специально для данного Flex-Algorithm.

Если LFA применяется для защиты локаторов, связанных с данным Flex-Algorithm, всем маршрутизаторам области, участвующим в этом Flex-Algorithm, следует анонсировать хотя бы один связанный с Flex-Algorithm локатор и END SID на узел, а также один END.X SID для каждого канала, не исключённого из расчёта с этим Flex-Algorithm. Эти локаторы и SID применяются для направления трафика по резервному пути LFA.

14.3. Пересылка для Flex-Algorithm в других плоскостях данных

Любая плоскость данных, желающая применять связанную с Flex-Algorithm пересылку, должна установить ту или иную форму связанных с Flex-Algorithm записей пересылки. Зависящая от плоскости данных пересылка для Flex-Algorithm должна быть определена для каждой плоскости данных, но это определение выходит за рамки документа.

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

15.1. Работа в нескольких областях

Расчёты Flex-Algorithm и определение FAD действуют в рамках области. В IS-IS элемент Router Capability TLV, где анонсируется FAD sub-TLV, должен иметь сброшенный бит S, чтобы предотвратить лавинную рассылку за пределы уровня, где анонс создан. Хотя в OSPF можно лавинно рассылать FAD sub-TLV в RI LSA в рамках AS, выбор FAD происходит для каждой индивидуальной зоны, где алгоритм будет применяться.

Для конкретного Flex-Algorithm не требуется идентичность FAD во всех областях сети. Например, трафик для одного Flex-Algorithm может оптимизироваться по задержке (например, с метрикой задержки) в одной области и по доступной пропускной способности (например, с метрикой IGP) в другой области или уровне.

Как описано в параграфе 5.1, IS-IS позволяет регенерировать выигрышное определение FAD с уровня 2 на уровень 1 без каких-либо изменений. Это позволяет оператору настроить FAD на одном или нескольких маршрутизаторах уровня 2 без необходимости повторять настройку в каждой области уровня 1, если намерение состоит в использовании одного FAD для конкретного Flex-Algorithm на всех уровнях. Аналогичным способом это можно реализовать в OSPF путём использования лавинной рассылки в AS для RI LSA с анонсами FAD sub-TLV для определённого Flex-Algorithm.

Регенерация FAD с уровня 1 на уровень 2 не поддерживается в IS-IS, поэтому для регенерации FAD между уровнями IS-IS определение FAD должно задаваться на маршрутизаторах уровня 2. В OSPF определение FAD возможно в любой области и оно будет распространяться на весь домен маршрутизации OSPF с использованием лавинной рассылки RI LSA в масштабе AS.

15.2. Использование правила исключения SRLG с Flex-Algorithm

Имеется два разных способа использования информации SRLG с Flex-Algorithm.

  • В контексте одного Flex-Algorithm SRLG можно применять для расчёта резервных путей, как описано в [RTGWG-SEGMENT-ROUTING-TI-LFA]. Для этого не требуется связывать какое-либо ограничение SRLG с данным определением Flex-Algorithm.

  • В контексте нескольких Flex-Algorithm SRLG можно применять для создания непересекающихся наборов путей за счёт исключения каналов, относящихся к конкретной группе SRLG из топологии, где пути рассчитываются с конкретным Flex-Algorithm. Такое исключение:

    • упрощает использование уже развёрнутых конфигураций SRLG для организации непересекающихся путей между двумя или более Flex-Algorithms;

    • требует явного связывания данного Flex-Algorithm с конкретным набором ограничений SRLG, как указано в параграфах 6.5 и 7.5.

Эти варианты применения не связаны между собой.

15.3. Max-Metric

В IS-IS и OSPF имеются механизмы установки значения метрики IGP на канале, делающего этот канал недоступным или применяемым в самом крайнем случае (last resort). Аналогичные функции нужны и для показателей Min Unidirectional Link Delay и TE, поскольку они могут применяться в расчётах путей Flex-Algorithm.

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику Min Unidirectional Link Delay, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA Min Unidirectional Link Delay для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение задержки 16777215 (224 -1).

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику TE, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA TE для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение метрики TE (224 – 1) в IS-IS и (232 – 1) в OSPF.

15.4. Задание и изменение гибкого алгоритма

При настройке узла для участия в конкретном Flex-Algorithm, следует внимательно рассмотреть компоненты FAD (calculation-type, metric-type, ограничения). Настройка участия в определённом Flex-Algorithm не гарантирует, что узел будет активно участвовать в алгоритме, поскольку он может не поддерживать calculation-type, metric-type или некоторые ограничения, анонсируемые выигрышным определением FAD (5.3. Базовая обработка FAD TLV). Изменения в конфигурации FAD также следует рассматривать в свете возможностей участвующих маршрутизаторов в области действия анонсов FAD.

Как отмечено в параграфе 5.3, изменение FAD может потребовать пересчёта SPF4 в масштабе сети и повторного схождения. Это следует учитывать при планировании и внесении изменений в FAD.

15.5. Число гибких алгоритмов

Максимальное число Flex-Algorithm определяется диапазоном 128-255, как указано в разделе 4. Гибкий алгоритм. Хотя такое возможно, но не предполагается, что все такие алгоритмы будут применяться одновременно. Обычно в сети будет использоваться лишь часть возможных Flex-Algorithms.

16. Совместимость с имеющимися расширениями

Это расширение не создаёт проблем совместимости с имеющимися протоколами и расширениями. В IS-IS, OSPFv2 и OSPFv3 чётко задана обработка нераспознанных TLV и sub-TLV, что позволяет создавать новые расширения, подобные описанным здесь, без возникновения проблем совместимости.

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

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

  • Злоумышленник может захватить конкретный Flex-Algorithm, анонсируя FAD с приоритетом 255 (или иным значением выше, чем у легитимных узлов).

  • Злоумышленник может создать ложное впечатление о поддержке (или её отсутствии) маршрутизатором конкретного Flex-Algorithm.

Обе эти атаки можно предотвратить с помощью имеющихся защитных расширений, как описано в [RFC5304] и [RFC5310] для IS-IS, в [RFC2328] и [RFC7474] для OSPFv2, в [RFC4552] и [RFC5340] для OSPFv3.

Если аутентифицированный узел захвачен злоумышленником, такой мошеннический узел может анонсировать FAD для любого Flex-Algorithm. Это может привести к тому, что трафик для такого Flex-Algorithm будет направлен не туда или не доставлен совсем, например, за счёт использования неподдерживаемых metric-type, calculation-type или ограничений. Такую атаку не удастся предотвратить с помощью аутентификации и она ничем не отличается от других вариантов анонсирования ложных сведений через IS-IS или OSPF.

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

18.1. Взаимодействие с IANA для IGP

18.1.1. Реестр IGP Algorithm Types

Этот документ вносит указанную в таблице 1 запись в реестр IGP Algorithm Types.

Таблица 1. Реестр IGP Algorithm Types.

 

Значение

Описание

Документ

128-255

Гибкие алгоритмы

RFC 9350, раздел 4

 

18.1.2. Реестр IGP Metric-Type

Агентство IANA создало реестр IGP Metric-Type в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action [RFC8126] [RFC7120]. Выделенные здесь значения из диапазона 0-255 указаны в таблице 2.

Таблица 2. Реестр IGP Metric-Type.

Тип

Описание

Документ

0

IGP Metric

RFC 9350, параграф 5.1

1

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC8570] и 4.2 в [RFC7471]

RFC 9350, параграф 5.1

2

Traffic Engineering Default Metric в соответствии с параграфом 3.7 в [RFC5305] и Traffic Engineering Metric в соответствии с параграфом 2.5.5 в [RFC3630]

RFC 9350, параграф 5.1

18.2. Реестр IGP Flexible Algorithm Definition Flags

Агентство IANA создало реестр IGP Flexible Algorithm Definition Flags в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action. Новые значения следует выделять по порядку битов (6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV). Исходное назначение показано в таблице 3.

Таблица 3. Реестр IGP Flexible Algorithm Definition Flags.

 

Бит

Имя

Документ

0

Флаг метрики префикса (M-flag)

RFC 9350, параграфы 6.4 и 7.4

 

18.3. Взаимодействие с IANA для IS-IS

18.3.1. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

Этот документ вносит указанную в таблице 4 запись в реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

Таблица 4. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

 

Значение

Описание

Документ

26

Определение гибкого алгоритма (FAD)

RFC 9350, параграф 5.1

 

18.3.2. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability

Этот документ вносит указанную в таблице 5 запись в реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.


Таблица 5. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.

 

Тип

Описание

27

135

235

236

237

Документ

6

Flexible Algorithm Prefix Metric (FAPM)

n

y

y

y

y

RFC 9350, раздел 8

 

18.3.3. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Агентство IANA создало реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV внутри группы реестров IS-IS TLV Codepoints. Для регистрации применяется процедура Expert Review (отметим, что группа IS-IS TLV Codepoints включает рекомендацию применять Expert Review для всех реестров в ней).

Записи sub-sub-TLV, заданных в этом документе для включения в реестр, показаны в таблице 6.

Таблица 6. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV.

 

Тип

Описание

Документ

0

Резерв

RFC 9350

1

Flexible Algorithm Exclude Admin Group

RFC 9350, параграф 6.1

2

Flexible Algorithm Include-Any Admin Group

RFC 9350, параграф 6.2

3

Flexible Algorithm Include-All Admin Group

RFC 9350, параграф 6.3

4

Flexible Algorithm Definition Flags

RFC 9350, параграф 6.4

5

Flexible Algorithm Exclude SRLG

RFC 9350, параграф 6.5

6-255

Не выделены

 

18.4. Взаимодействие с IANA для OSPF

18.4.1. Реестр OSPF Router Information (RI) TLVs

Этот документ вносит указанную в таблице 7 запись в реестр OSPF Router Information (RI) TLVs.

Таблица 7. Реестр OSPF Router Information (RI) TLVs.

 

Значение

Описание

Документ

16

Flexible Algorithm Definition (FAD) TLV

RFC 9350, параграф 5.2

 

18.4.2. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs

Этот документ вносит указанную в таблице 8 запись в реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

Таблица 8. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

 

Значение

Описание

Документ

3

Flexible Algorithm Prefix Metric (FAPM)

RFC 9350, раздел 9

 

18.4.3. Реестр OSPFv3 Extended-LSA Sub-TLVs

Этот документ вносит указанные в таблице 9 записи в реестр OSPFv3 Extended-LSA Sub-TLVs.

Таблица 9. Реестр OSPFv3 Extended-LSA Sub-TLVs.

 

Значение

Описание

Документ

26

Flexible Algorithm Prefix Metric (FAPM)

RFC 9350, раздел 9

33

OSPF Flexible Algorithm ASBR Metric

RFC 9350, параграф 10.2

 

18.4.4. Реестр OSPF Flex-Algorithm Prefix Metric Bits

Агентство IANA создало реестр OSPF Flex-Algorithm Prefix Metric Bits внутри реестра Open Shortest Path First (OSPF) Parameters. Регистрация выполняется по процедуре IETF Review. Биты 1-7 не выделены, исходное назначение показано в таблице 10.

Таблица 10. Реестр OSPF Flex-Algorithm Prefix Metric Bits.

 

Номер бита

Описание

Документ

0

E bit – External Type

RFC 9350, раздел 9

 

18.4.5. Реестр Opaque Link-State Advertisements (LSA) Option Types

Этот документ регистрирует указанное в таблице 11 значение в реестре Opaque Link-State Advertisements (LSA) Option Types внутри группы реестров Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types.

Таблица 11. Реестр Opaque Link-State Advertisements (LSA) Option Types.

 

Значение

Неинтерпретируемый тип

Документ

11

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA

RFC 9350, параграф 10.1

 

18.4.6. Реестр OSPFv2 Extended Inter-Area ASBR TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR TLVs внутри группы реестров Open Shortest Path First v2 (OSPFv2) Parameters. Для реестра применяется процедура IETF Review или IESG Approval. Исходные значения приведены в таблице 12.

Таблица 12. Реестр OSPFv2 Extended Inter-Area ASBR TLVs.

 

Значение

Описание

Документ

1

Extended Inter-Area ASBR

RFC 9350

 

Значения 2-32767 не распределены, значения 32768-33023 выделены для экспериментов (Experimental Use), 0 и 33024-65535 являются резервными.

18.4.7. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs внутри реестра Open Shortest Path First v2 (OSPFv2) Parameters. Регистрация выполняется по процедуре IETF Review или IESG Approval. Исходные значения приведены в таблице 13.

Таблица 13. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs.

 

Значение

Описание

Документ

1

OSPF Flexible Algorithm ASBR Metric

RFC 9350

 

Значения 2-32767 не распределены, значения 32768-33023 выделены для экспериментов (Experimental Use), 0 и 33024-65535 являются резервными.

18.4.8. Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs

Агентство IANA создало реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs внутри группы реестров Open Shortest Path First (OSPF) Parameters. Для реестра применяется процедура IETF Review или IESG Approval.

Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs будет определять sub-TLV с любым уровнем вложенности для Flexible Algorithm TLV и новые значения могут выделяться по процедуре регистрации.

Регистрируемые документом sub-TLV указаны в таблице 14.

Таблица 14. Реестр OSPFv2 OSPF Flexible Algorithm Definition TLV Sub-TLVs.

 

Номер бита

Описание

Документ

0

Резерв

RFC 9350

1

Flexible Algorithm Exclude Admin Group

RFC 9350, параграф 7.1

2

Flexible Algorithm Include-Any Admin Group

RFC 9350, параграф 7.2

3

Flexible Algorithm Include-All Admin Group

RFC 9350, параграф 7.3

4

Flexible Algorithm Definition Flags

RFC 9350, параграф 7.4

5

Flexible Algorithm Exclude SRLG

RFC 9350, параграф 7.5

 

Значения 6-32767 не распределены, а значения 32768-33023 выделены для экспериментов (Experimental Use) и не требуют регистрации в IANA. Значения 33024-65535 в настоящее время не выделены. Для получения значений из этого диапазона должна быть выпущена спецификация IETF, с соответствующими запросами к IANA.

18.4.9. Реестр Link Attribute Application Identifiers

Этот документ регистрирует указанные в таблице 15 идентификаторы в реестре Link Attribute Application Identifiers.

Таблица 15. Реестр флагов IGP Flexible Algorithm Definition.

 

Бит

Описание

Документ

3

Гибкий алгоритм (X-bit)

RFC 9350, раздел 12

 

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

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

[ISO10589] ISO, “Information technology – Telecommunications and information exchange between systems – Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)”, Second Edition, ISO/IEC 10589:2002, November 2002.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, “The OSPF Opaque LSA Option”, RFC 5250, DOI 10.17487/RFC5250, July 2008, <https://www.rfc-editor.org/info/rfc5250>.

[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., “IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, “OSPFv2 Prefix/Link Attribute Advertisement”, RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, “Extensions to OSPF for Advertising Optional Router Capabilities”, RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.

[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, “IS-IS Extensions for Advertising Router Information”, RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, “OSPFv3 Link State Advertisement (LSA) Extensibility”, RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing with the MPLS Data Plane”, RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, “OSPF Extensions for Segment Routing”, RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.

[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., “OSPFv3 Extensions for Segment Routing”, RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>.

[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, “IS-IS Extensions for Segment Routing”, RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, “IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane”, RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/info/rfc9352>.

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

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101] Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option”, RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

[RFC3906] Shen, N. and H. Smit, “Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels”, RFC 3906, DOI 10.17487/RFC3906, October 2004, <https://www.rfc-editor.org/info/rfc3906>.

[RFC4552] Gupta, M. and N. Melam, “Authentication/Confidentiality for OSPFv3”, RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC5304] Li, T. and R. Atkinson, “IS-IS Cryptographic Authentication”, RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5305] Li, T. and H. Smit, “IS-IS Extensions for Traffic Engineering”, RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, “IS-IS Generic Cryptographic Authentication”, RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6”, RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, “Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks”, RFC 6571, DOI 10.17487/RFC6571, June 2012, <https://www.rfc-editor.org/info/rfc6571>.

[RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, “OSPF Traffic Engineering (TE) Metric Extensions”, RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., “Security Extension for OSPFv2 When Using Manual Key Management”, RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, “IS-IS Traffic Engineering (TE) Metric Extensions”, RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, “Segment Routing over IPv6 (SRv6) Network Programming”, RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[ROUTING-PLANES-USING-SR] Hegde, S. and A. Gulko, “Separating Routing Planes using Segment Routing”, Work in Progress, Internet-Draft, draft-gulkohegde-routing-planes-using-sr-00, 13 March 2017, <https://datatracker.ietf.org/doc/html/draft-gulkohegde-routing-planes-using-sr-00>.

[RTGWG-SEGMENT-ROUTING-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, “Topology Independent Fast Reroute using Segment Routing”, Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-09, 23 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-09>.

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

В этом документе, среди прочего, рассматривается задача, которую пытаются решить в [ROUTING-PLANES-USING-SR]. Все авторы этого документа согласились присоединиться к данному документу.

Спасибо Eric Rosen, Tony Przygienda, William Britto A. J., Gunter Van de Velde, Dirk Goethals, Manju Sivaji, and Baalajee S. за их подробные рецензии и отличные комментарии.

Спасибо Cengiz Halit за его рецензию и отклики на начальном этапе решения.

Спасибо Kenji Kumaki за его комментарии.

Спасибо Acee Lindem за редакционные замечания.

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


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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3В полях ASBR Router ID и Sub-TLVs. Прим. перев.

4Shortest Path First – сначала кратчайший путь.

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

RFC 9351 Border Gateway Protocol – Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Internet Engineering Task Force (IETF)                K. Talaulikar, Ed.
Request for Comments: 9351                                     P. Psenak
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                                 S. Zandi
                                                                G. Dawra
                                                                LinkedIn
                                                           February 2023

Border Gateway Protocol – Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Расширения BGP-LS для анонсирования гибкого алгоритма

PDF

Аннотация

Гибким алгоритмом (Flexible Algorithm) называется решение, позволяющее некоторым протоколам маршрутизации (например, OSPF и IS-IS) рассчитывать пути через сеть на основе заданных пользователем (поэтому более гибких) ограничений и показателей. Расчёт выполняют маршрутизаторы, участвующие в конкретной сети, распределенно с использованием определения гибкого алгоритма алгоритма (Flexible Algorithm Definition или FAD). Это определение предоставляется не одном или нескольких маршрутизаторах и распространяется через сеть путём лавинной рассылки OSPF и IS-IS.

Состояние канала для протокола граничного шлюза (Border Gateway Protocol – Link State или BGP-LS) позволяет собрать из сети различные сведения. Этот документ задаёт расширения семейства адресов BGP-LS для анонсирования FAD как части топологических сведений о сети.

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Классический протокол IGP (например, OSPF и IS-IS) рассчитывает лучшие пути через сеть на основе метрики IGP, назначенной для каналов сети. Во многих развёрнутых сетях применяется решение на основе RSVP-TE [RFC3209] или политики маршрутизации по сегментам (Segment Routing или SR) [RFC8402] для передачи трафика по пути, рассчитанному с использованием других показателей или ограничесний, нежели для кратчайшего пути IGP. В [RFC9350] задано решение с гибким алгоритмом, позволяющее самим IGP рассчитывать пути через сеть на основе ограничений.

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

  • типа применяемого расчёта (например, кратчайший путь);

  • типа применяемой метрики (например, IGP или TE);

  • набора применяемых ограничений (например, включение или исключение некоторых каналов по близости).

Работа гибкого алгоритма IGP подробно описана в [RFC9350].

Расширения BGP-LS для SR заданы в [RFC9085] и в [IDR-BGPLS-SRV6-EXT] для SR-MPLS и SRv63. Они включают расширения для анонсирования сведений SR, содержащих разные типы идентификаторов сегментов (Segment Identifier или SID).

  • SR Algorithm TLV указывает участие узла в расчёте Flexible Algorithm.

  • Prefix-SID TLV указывает привязку Prefix-SID к конкретному Flexible Algorithm для пересылки SR-MPLS.

  • SRv6 Locator TLV указывает локатор для конкретного Flexible Algorithm при пересылке SRv6.

Этот документ задаёт расширения BGP-LS для анонсирования сведений FAD, чтобы обеспечить возможность изучить сопоставления номера гибкого алгоритма с его определением в каждой области или домене базового протокола IGP. Это определение указывает тип применяемого расчёта и ограничения для данного Flexible Algorithm, которые могут применяться для организации сквозных путей SR Policy через множество доменов с использованием подходящих SID в списке сегментов [RFC9256]. Например, при указании Flexible Algorithm Prefix-SID (для SR-MPLS) или End SID (для SRv6) граничные маршрутизаторы областей (Area Border Router или ABR) или автономных систем (Autonomous System Border Router или ASBR), соответствующие определению, которое оптимизирует показатель задержки, могут построить сквозной путь с малой задержкой через домены IGP с минимальным числом SID в списке SID.

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

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

2. Обзор расширений BGP-LS для гибкого алгоритма

BGP-LS [RFC7752] задаёт Node NLRI для анонсирования узлов и их атрибутов, Link NLRI для анонсирования каналов и их атрибутов, Prefix NLRI для анонсирования префиксов и их атрибутов с применением атрибута BGP-LS.

Анонсируемые узлом FAD считаются атрибутами уровня узла и анонсируются в соответствии с разделом 3.

Различные атрибуты каналов, такие как близость и группы общего риска (Shared Risk Link Group или SRLG), применяемые в расчётах маршрутов с помощью гибкого алгоритма в IS-IS и OSPF, анонсируются в этих протоколах с использованием анонсов зависящих от приложения атрибутов каналов (Application-Specific Link Attribute или ASLA), как описано в [RFC8919], [RFC8920] и [RFC9350]. Расширения BGP-LS для анонсов ASLA заданы в [RFC9294].

Показатель префикса гибкого алгоритма (Flexible Algorithm Prefix Metric или FAPM) считается атрибутом префикса и анонсируется в соответствии с разделом 4.

3. TLV задания гибкого алгоритма

Этот документ задаёт необязательный TLV атрибута BGP-LS, связанного с Node NLRI, который называется Flexible Algorithm Definition TLV или FAD TLV. Формат TLV показан на рисунке 1

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |   Metric-Type |   Calc-Type   |    Priority   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                sub-TLVs       ...                            //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Flexible Algorithm Definition TLV.


Type

1039

Length

Общий размер поля значений (включая любые sub-TLV) в октетах. Размер должен быть не меньше 4.

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Metric-Type

1-октетное значение, указывающее тип метрики в соответствии с [RFC9350].

Calc-Type

1-октетное значение, указывающее тип расчёта в соответствии с [RFC9350].

Priority

1-октетное значение, указывающее анонса FAD в соответствии с [RFC9350].

Sub-TLVs

Необязательные sub-TLV, описанные ниже.

FAD TLV анонсируется в атрибуте BGP-LS вместе с Node NLRI и выводится из анонсов IGP:

  • для IS-IS из IS-IS Flexible Algorithm Definition sub-TLV в [RFC9350];

  • для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Definition TLV в [RFC9350].

Атрибут BGP-LS, связанный с Node NLRI может включать FAD TLV, соответствующие FAD для каждого алгоритма, анонсируемого этим узлом.

В последующих параграфах заданы sub-TLV для FAD TLV.

3.1. Flexible Algorithm Exclude-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Exclude-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и исключения каналов с заданной близостью из расчётов конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Flexible Algorithm Exclude-Any Affinity Sub-TLV.


Type

1040

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Exclude-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Exclude-Any Affinity sub-TLV выводится из Flexible Algorithm Exclude-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.2. Flexible Algorithm Include-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Include-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 3.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Flexible Algorithm Include-Any Affinity Sub-TLV.


Type

1041

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-Any Affinity sub-TLV выводится из Flexible Algorithm Include-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.3. Flexible Algorithm Include-All Affinity Sub-TLV

Необязательный Flexible Algorithm Include-All Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения всех каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Flexible Algorithm Include-All Affinity Sub-TLV.


Type

1042

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-All EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-All Affinity sub-TLV выводится из Flexible Algorithm Include-All Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.4. Flexible Algorithm Definition Flags Sub-TLV

Необязательный Flexible Algorithm Definition Flags sub-TLV служит для переноса связанных с FAD флагов, используемых в расчёте конкретного алгоритма, как описано в [RFC9350]. Формат sub-TLV показан на рисунке 5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Flags (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Flexible Algorithm Definition Flags Sub-TLV.


Type

1043

Length

Общий размер поля значения, зависящий от размера флагов. Значение должно быть больше 0 и кратно 4.

Flags

Битовая маская, служащая для представления фланов FAD, как описано в [RFC9350].

Информация Flexible Algorithm Definition Flags sub-TLV выводится из Flexible Algorithm Definition Flags sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.5. Flexible Algorithm Exclude SRLG Sub-TLV

Необязательный Flexible Algorithm Exclude SRLG sub-TLV служит для переноса сведений SRLG, связанных с FAD, и исключения каналов, связанных с любой из указанных групп SRLG, из расчётов конкретного алгоритма, как описано в [RFC9350]. SRLG, связанные с каналом, передаются в BGP-LS Shared Risk Link Group (TLV 1096) [RFC7752]. Формат sub-TLV показан на рисунке 6.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Shared Risk Link Group Values (переменный)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Flexible Algorithm Exclude SRLG Sub-TLV.


Type

1045

Length

Общий размер поля значения, зависящий от числа значений SRLG. Значение должно быть больше 0 и кратно 4.

Shared Risk Link Group Values

Обно или несколько значений SRLG размером по 4 октета, как описано в [RFC9350].

Информация Flexible Algorithm Exclude SRLG sub-TLV выводится из Flexible Algorithm Exclude SRLG sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.6. Flexible Algorithm Unsupported Sub-TLV

Сигнализация OSPF и IS-IS для FAD допускает расширения через новые sub-TLV в рамках соответствующего IGP Flexible Algorithm Definition TLV. Как указано в параграфе 5.3 [RFC9350], важно, чтобы определение FAD был понятно целиком любому, кто использует его для расчётов. Таким образом, FAD отличается от большинства других расширений протокола, где пропуск или игнорирование непонятных сведений sub-TLV не меняет поведения.

Необязательный Flexible Algorithm Unsupported sub-TLV применяется для индикации наличия неподдерживаемых FAD sub-TLV. Потребность в этом sub-TLV возникает, когда реализация BGP-LS на анонсирующем узле не поддерживает какой-либо из FAD sub-TLV, из имеющихся в анонсе IGP. Формат sub-TLV показан на рисунке 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  | типы sub-TLV (переменный) ...                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Flexible Algorithm Unsupported Sub-TLV.


Type

1046

Length

Общий размер поля значения в октетах (включая любые содержащиеся типы sub-TLV).

Protocol-ID

Указывает BGP-LS Protocol-ID протокола, из которого FAD анонсируется через BGP-LS. Значения берутся из реестра IANA BGP-LS Protocol-IDs” subregistry under the “Border Gateway Protocol – Link State (BGP-LS) Parameters <https://www.iana.org/assignments/bgp-ls-parameters/>.

sub-TLV types

Необязательный набор типов sub-TLV, которые не поддерживаются узлом, создавшим анонс BGP-LS. Размер каждого sub-TLV зависит от протокола, указанного полем Protocol-ID. Например, для IS-IS, каждый тип sub-TLV имеет размер 1 октет, а для OSPF – 2 октета.

Узел, создающий анонс, должен включать Flexible Algorithm Unsupported sub-TLV, когда он сталкивается с неподдерживаемым им sub-TLV в соответствующем FAD анонса IS-IS или OSPF. При анонсировании Flexible Algorithm Unsupported sub-TLV следует включать зависимые от протокола типы неподдерживаемых sub-TLV (для диагностики).

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

4. Flexible Algorithm Prefix Metric TLV

Этот документ задаёт необязательный BGP-LS Attribute TLV, связанный с Prefix NLRI и называемый Flexible Algorithm Prefix Metric TLV или FAPM TLV. Формат TLV показан на рисунке 8.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |     Flags     |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Flexible Algorithm Prefix Metric TLV.


Type

1044

Length

8 октетов

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Flags

1-октетное значение, применимое только для OSPF, как указано в [RFC9350]. Для IS-IS должно быть 0.

Reserved

2-октетное значение, которое должно устанавливаться в 0 источником и должно игнорироваться получателем.

Metric

4-октетное поле для передачи сведений о метрике.

FAPM TLV анонсируется в атрибуте BGP-LS вместе с Prefix NLRI и выводится из анонсов IGP:

  • для IS-IS из IS-IS Flexible Algorithm Prefix Metric sub-TLV в [RFC9350];

  • для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Prefix Metric sub-TLV в [RFC9350].

Атрибут BGP-LS, связанный с Prefix NLRI может включать FAPM TLV, соответствующие Flexible Algorithm Prefix Metric для каждого алгоритма, анонсируемого этим узлом.

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

Агентство IANA выделило в ресстре BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs <https://www.iana.org/assignments/bgp-ls-parameters> коды для TLV и sub-TLV, указанные в таблице 1.

Таблица 1. Коды TLV для гибких алгоритмов.

 

Код TLV

Описание

1039

Определение гибкого алгоритма

1040

Flexible Algorithm Exclude-Any Affinity

1041

Flexible Algorithm Include-Any Affinity

1042

Flexible Algorithm Include-All Affinity

1043

Flexible Algorithm Definition Flags

1044

Flexible Algorithm Prefix Metric

1045

Flexible Algorithm Exclude SRLG

1046

Flexible Algorithm Unsupported

 

6. Вопросы управляемости

Заданные в этом документе расширения дополняют имеющиеся топологические сведения IGP, которые могут распространяться через [RFC7752]. Процедуры и расширения, заданные в этом документе, не влияют на операции и управление протоколом BGP сверх указанного в разделе «Вопросы управляемости» [RFC7752]. В частности проверки формата NLRI из раздела «Контроль отказов» в [RFC7752] охватывают TLV для BGP-LS NLRI из этого документа.

Расширения из этого документа не задают новых аспектов конфигурации или настройки в BGP и BGP-LS. Спецификация моделей BGP на основе [IDR-BGP-MODEL] ещё не завершена.

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

Вопросы безопасности при получении и распространении сведений BGP-LS рассмотрены в [RFC7752].

TLV, добавленные в этом документе, служат для распространения расширений IGP Flexible Algorithm, заданных в [RFC9350]. Предполагается, что экземпляры IGP, создающие эти TLV, будут обеспечивать безопасность (как указано в [RFC9350]) для внедрения Flexible Algorithm.

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

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP”, RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, “IGP Flexible Algorithm”, RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.

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

[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “BGP YANG Model for Service Provider Networks”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-15, 13 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-15>.

[IDR-BGPLS-SRV6-EXT] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, “BGP Link State Extensions for SRv6”, Work in Progress, Internet-Draft, draft-ietf-idr-bgpls-srv6-ext-13, 14 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-13>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, “Border Gateway Protocol – Link State (BGP-LS) Extensions for Segment Routing”, RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/info/rfc9085>.

[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9294] Talaulikar, K., Ed., Psenak, P., and J. Tantsura, “Application-Specific Link Attributes Advertisement ping the Border Gateway Protocol – Link State (BGP-LS)”, RFC 9294, DOI 10.17487/RFC9294, August 2022, <https://www.rfc-editor.org/info/rfc9294>.

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

Авторы благодарны Les Ginsberg, Amalesh Maity, Y. F. Siu, Vijay Gurbani, Donald Eastlake 3rd за их рецензии и вклад в работу. Спасибо Jie Dong за рецензию курастора. Спасибо Alvaro Retana за подробную рецензию AD и предложения по улучшению документа.

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

Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
 
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
 
Shawn Zandi
LinkedIn
United States of America
Email: szandi@linkedin.com
 
Gaurav Dawra
LinkedIn
United States of America
Email: gdawra.ietf@gmail.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Segment Routing over IPv6 – маршрутизация по сегментам через IPv6.

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

RFC 9349 Definitions of Managed Objects for IP Traffic Flow Security

Internet Engineering Task Force (IETF)                          D. Fedyk
Request for Comments: 9349                                     E. Kinzie
Category: Standards Track                        LabN Consulting, L.L.C.
ISSN: 2070-1721                                             January 2023

Definitions of Managed Objects for IP Traffic Flow Security

Определения управляемых объектов для защиты потоков трафика IP

PDF

Аннотация

Этот документ описывает управляемые объекты дополнений защиты потоков трафика IP (IP Traffic Flow Security) для протокола обмена ключами Internet версии 2 (Internet Key Exchange Protocol Version 2 или IKEv2) и IPsec. Документ представляет доступные лишь для чтения версии объектов, определённых в модуле YANG для тех же целей (A YANG Data Model for IP Traffic Flow Security, RFC 9348).

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ определяет модуль MIB (Management Information Base) для использования протоколами сетевого управления в сообществе Internet. Расширения для защиты потоков трафика (IP Traffic Flow Security или IP-TFS), заданные в [RFC9347], расширяют защищённые связи IPsec SA для повышения уровня конфиденциальности трафика.

Определяемые здесь объекты совпадают с заданными в [RFC9348], но поддерживаются лишь данные рабочего состояния. За счёт доступности данных рабочего состояния по протоколу SNMP имеющиеся системы управления сетями могут отслеживать IP-TFS. Эти данные указаны в дереве MIB (параграф 4.1). Модуль использует модель данных YANG в качестве отправной точки. Отметим, что модель IETF MIB для IPsec не была стандартизована, однако приведённые здесь структуры можно адаптировать к имеющимся фирменным реализациям MIB, где для управления сетями применяется SNMP.

1.1. Схема стандартов управления Internet

Подробный обзор документов, описывающих современную схему управления (Internet-Standard Management Framework) приведён в разделе 7 [RFC3410].

Доступ к управляемым объектам происходит через виртуальное хранилище информации, называемое базой управляющей информации (Management Information Base или MIB). Доступ к объектам MIB обычно выполняется по простому протоколу управления сетью (Simple Network Management Protocol или SNMP). Объекты MIB определяются с использованием механизмов, заданных структурой управляющей информации (Structure of Management Information или SMI). Этот документ описывает модуль MIB, соответствующий SMIv2, описанной в STD 58, [RFC2578], [RFC2579] и [RFC2580].

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

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

3. Обзор

Этот документ задаёт MIB для доступа к рабочим параметрам IP-TFS. Расширение IP-TFS, определённое в [RFC9347], настраивает защищённые свящи (Security Association или SA) для туннельного режима IPsec с характеристиками, повышающими уровень конфиденциальности трафика и сокращающими расход прорускной способности.

Документ основан на концепциях и модели управления [RFC9348]. Предполагается знакомство читателя с концепциями IPsec [RFC4301], IP-TFS [RFC9347] и моделью управления IP-TFS, описанной в [RFC9348].

Документ задаёт расширяемую операционную модель для IP-TFS, используя модель управления из [RFC9348]. Это позволяет системам SNMP читать рабочие объекты (включая настраиваемые) из IP-TFS.

4. Объекты управления

4.1. Дерево MIB

Ниже представлено дерево регистрации MIB для расширений IP-TFS.

   # дерево регистрации IP-TRAFFIC-FLOW-SECURITY-MIB

   --iptfsMIB(1.3.6.1.2.1.500)
     +--iptfsMIBObjects(1)
     |  +--iptfsGroup(1)
     |  |  +--iptfsConfigTable(1)
     |  |     +--iptfsConfigTableEntry(1) [iptfsConfigSaIndex]
     |  |        |
     |  |        +-- --- Integer32           iptfsConfigSaIndex(1)
     |  |        +-- r-n TruthValue          congestionControl(2)
     |  |        +-- r-n TruthValue          usePathMtuDiscovery(3)
     |  |        +-- r-n UnsignedShort       outerPacketSize(4)
     |  |        +-- r-n CounterBasedGauge64 l2FixedRate(5)
     |  |        +-- r-n CounterBasedGauge64 l3FixedRate(6)
     |  |        +-- r-n TruthValue          dontFragment(7)
     |  |        +-- r-n NanoSeconds         maxAggregationTime(8)
     |  |        +-- r-n UnsignedShort       windowSize(9)
     |  |        +-- r-n TruthValue          sendImmediately(10)
     |  |        +-- r-n NanoSeconds         lostPacketTimerInterval(11)
     |  +--ipsecStatsGroup(2)
     |  |  +--ipsecStatsTable(1)
     |  |     +--ipsecStatsTableEntry(1) [ipsecSaIndex]
     |  |        +-- --- Integer32 ipsecSaIndex(1)
     |  |        +-- r-n Counter64 txPkts(2)
     |  |        +-- r-n Counter64 txOctets(3)
     |  |        +-- r-n Counter64 txDropPkts(4)
     |  |        +-- r-n Counter64 rxPkts(5)
     |  |        +-- r-n Counter64 rxOctets(6)
     |  |        +-- r-n Counter64 rxDropPkts(7)
     |  +--iptfsInnerStatsGroup(3)
     |  |  +--iptfsInnerStatsTable(1)
     |  |     +--iptfsInnerStatsTableEntry(1) [iptfsInnerSaIndex]
     |  |        +-- --- Integer32 iptfsInnerSaIndex(1)
     |  |        +-- r-n Counter64 txInnerPkts(2)
     |  |        +-- r-n Counter64 txInnerOctets(3)
     |  |        +-- r-n Counter64 rxInnerPkts(4)
     |  |        +-- r-n Counter64 rxInnerOctets(5)
     |  |        +-- r-n Counter64 rxIncompleteInnerPkts(6)
     |  +--iptfsOuterStatsGroup(4)
     |     +--iptfsOuterStatsTable(1)
     |        +--iptfsOuterStatsTableEntry(1) [iptfsOuterSaIndex]
     |           +-- --- Integer32 iptfsOuterSaIndex(1)
     |           +-- r-n Counter64 txExtraPadPkts(2)
     |           +-- r-n Counter64 txExtraPadOctets(3)
     |           +-- r-n Counter64 txAllPadPkts(4)
     |           +-- r-n Counter64 txAllPadOctets(5)
     |           +-- r-n Counter64 rxExtraPadPkts(6)
     |           +-- r-n Counter64 rxExtraPadOctets(7)
     |           +-- r-n Counter64 rxAllPadPkts(8)
     |           +-- r-n Counter64 rxAllPadOctets(9)
     |           +-- r-n Counter64 rxErroredPkts(10)
     |           +-- r-n Counter64 rxMissedPkts(11)
     +--iptfsMIBConformance(2)
        +--iptfsMIBConformances(1)
        |  +--iptfsMIBCompliance(1)
        +--iptfsMIBGroups(2)
           +--iptfsMIBConfGroup(1)
           +--ipsecStatsConfGroup(2)
           +--iptfsInnerStatsConfGroup(3)
           +--iptfsOuterStatsConfGroup(4)

4.2. SNMP

Ниже представлен модуль MIB для IP-TFS. Алгоритм контроля перегрузок [RFC5348] указан в тексте MIB.

   <CODE BEGINS> file "iptfs-mib.mib"
   -- *----------------------------------------------------------------
   -- *  Модуль IP-TRAFFIC-FLOW-SECURITY-MIB
   -- *----------------------------------------------------------------

   IP-TRAFFIC-FLOW-SECURITY-MIB DEFINITIONS ::= BEGIN
      IMPORTS
           MODULE-IDENTITY, OBJECT-TYPE,
           Integer32, Unsigned32, Counter64, mib-2
               FROM SNMPv2-SMI
           CounterBasedGauge64
               FROM  HCNUM-TC
           MODULE-COMPLIANCE, OBJECT-GROUP
               FROM SNMPv2-CONF
           TEXTUAL-CONVENTION,
           TruthValue
               FROM SNMPv2-TC;

      iptfsMIB MODULE-IDENTITY
           LAST-UPDATED "202301310000Z"
           ORGANIZATION "IETF IPsecme Working Group"
           CONTACT-INFO
                   "
                      Author: Don Fedyk
                              <mailto:dfedyk@labn.net> 

                      Author: Eric Kinzie
                              <mailto:ekinzie@labn.net>" 

      DESCRIPTION
         "Этот модуль задаёт конфигурацию и рабочее состояние для 
         управления функциональностью IP-TFS (RFC 9348).

         Авторские права (Copyright (c) 2023) принадлежат IETF Trust и
         лицам, указанным как авторы. Все права защищены.

         Распространение и применение модуля в исходной или двоичной 
         форме с изменениями или без таковых разрешено в соответствии с
         лицензией Simplified BSD License, изложенной в параграфе 4.c
         IETF Trust's Legal Provisions Relating to IETF Documents
         (https://trustee.ietf.org/license-info). 

         Эта версия модуля SNMP MIB является частью RFC 9349, где 
         правовые аспекты приведены более полно.";

       REVISION "202301310000Z"
       DESCRIPTION
               "Исходный выпуск, основанный на модели YANG IP-TFS."
       ::= { mib-2 246}
   --
   -- Текстовые соглашения
   --

   UnsignedShort ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION "xs:unsignedShort"
       SYNTAX      Unsigned32 (0 .. 65535)


   NanoSeconds ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d-6"
       STATUS  current
       DESCRIPTION
         "Представляет время в наносекундах."
       SYNTAX      Integer32


   -- Объекты, уведомления, соответствия

      iptfsMIBObjects     OBJECT IDENTIFIER
                  ::= { iptfsMIB 1 }
      iptfsMIBConformance OBJECT IDENTIFIER
                  ::= { iptfsMIB 2}

   --
   -- Группы объектов IP-TFS MIB
   --
      iptfsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 1 }

      ipsecStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 2 }

      iptfsInnerStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 3 }

      iptfsOuterStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 4 }

      iptfsConfigTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsConfigTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                  "Таблица конфигурационных данных для IP-TFS."
          ::= { iptfsGroup 1 }

      iptfsConfigTableEntry OBJECT-TYPE
          SYNTAX     IptfsConfigTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Запись (концептуальная строка) со сведениями об 
            отдельной IP-TFS SA."
          INDEX      { iptfsConfigSaIndex }
          ::= { iptfsConfigTable 1 }

     IptfsConfigTableEntry ::= SEQUENCE {
         iptfsConfigSaIndex         Integer32,

      -- Идентификаторы
         congestionControl          TruthValue,
         usePathMtuDiscovery        TruthValue,
         outerPacketSize            UnsignedShort,
         l2FixedRate                CounterBasedGauge64,
         l3FixedRate                CounterBasedGauge64,
         dontFragment               TruthValue,
         maxAggregationTime         NanoSeconds,
         windowSize                 UnsignedShort,
         sendImmediately            TruthValue,
         lostPacketTimerInterval    NanoSeconds
      }

      iptfsConfigSaIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..16777215)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
            "Уникальное значение больше 0 для каждой SA. Рекомендуется
            выделять значения непрерывно, начиная с 1.

            Значение для каждой записи должно сохраняться хотя бы от
            одной инициализации системы сетевого управления объекта 
            до другой."
          ::= { iptfsConfigTableEntry 1 }

       congestionControl OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Принятое по умолчанию значение true разрешает обмен 
             данными контроля перегрузки по линии, требуемый алгоритмами
             контроля перегрузок, как указано в RFC 5348. При значении
             false IP-TFS передаёт через туннель IP-TFS пакеты
             фиксированного размера с постоянной скоростью."
           ::= { iptfsConfigTableEntry 2 }

       usePathMtuDiscovery OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Размер пакета задаётся вручную или определяется 
             автоматически. При usePathMtuDiscovery true система
             использует path-mtu для определения максимального размера
             пакетов IP-TFS. Если размер задан явно, он может лишь
             снижаться при установке use-path-mtu."
           ::= { iptfsConfigTableEntry 3 }

       outerPacketSize OBJECT-TYPE
           SYNTAX      UnsignedShort
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче это размер внешнего инкапсулирующего
             туннельного пакета (т. е. пакета IP с ESP)."
           ::= { iptfsConfigTableEntry 4 }

       l2FixedRate OBJECT-TYPE
           SYNTAX      CounterBasedGauge64
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Битовая скорость IP-TFS может быть указана как скорость в
             линии L2. При передаче это целевая пропускная способность
             (битовая скорость) в бит/сек (bps) для туннеля IP-TFS. Это
             задаёт номинальную синхронизацию передачи пакетов
             фиксированного размера. При включённом контроле перегрузок
             скорость может снижаться."
           ::= { iptfsConfigTableEntry 5 }

       l3FixedRate OBJECT-TYPE
           SYNTAX      CounterBasedGauge64
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Битовая скорость IP-TFS может быть указана как скорость
             пакетов L3. При передаче это целевая пропускная способность
             (битовая скорость) в бит/сек (bps) для туннеля IP-TFS. Это
             задаёт номинальную синхронизацию передачи пакетов
             фиксированного размера. При включённом контроле перегрузок
             скорость может снижаться."
           ::= { iptfsConfigTableEntry 6 }

       dontFragment OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче запрещает разделять фрагменты пакета по
             разным последовательным пакетам туннеля IP-TFS. Внутренние
             пакеты, размер, не помещающиеся во внешний пакет, будут
             отбрасываться."
           ::= { iptfsConfigTableEntry 7 }

       maxAggregationTime OBJECT-TYPE
           SYNTAX      NanoSeconds
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче максимальным временем агрегирования является
              наибольшее время удержания вложенных пакетов до отправки в
              туннель IP-TFS. Внутренние пакеты, удерживаемые дольше
              этого времени в текущей конфигурации туннеля будут 
              отбрасываться вместо постановки в очередь на передачу."
           ::= { iptfsConfigTableEntry 8 }

       windowSize OBJECT-TYPE
           SYNTAX      UnsignedShort
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении это максимальное число пакетов с нарушением
             порядка, которые будут переупорядочены получателем IP-TFS. 
             Значение 0 отключает восстановление порядка."
           ::= { iptfsConfigTableEntry 9 }

       sendImmediately OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении внутренние пакеты передаются как можно
             быстрее без ожидания потерянных и переупорядоченных внешних
             пакетов. Выбор этой опции сокращает задержку вложенных
             (пользовательских) пакетов, но может усилить нарушение 
             порядка доставки потока пакетов при наличии агрегирования
             или иного переупорядочения."
           ::= { iptfsConfigTableEntry 10 }

       lostPacketTimerInterval OBJECT-TYPE
           SYNTAX      NanoSeconds
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении этот интервал задаёт время ожидания
             получателем IP-TFS пропущенных пакетов, прежде чем счесть 
             их потерянными. Если не применяется send-immediately,
             каждая потеря будет задерживать внутренние 
             (пользовательские) пакеты, пока не завершится отсчёт этого
             таймера. Установка слишком малого значения может влиять на
             переупорядочение и сборку."
           ::= { iptfsConfigTableEntry 11 }

      ipsecStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IpsecStatsTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица базовой статистики IPsec."
          ::= { ipsecStatsGroup 1 }


       ipsecStatsTableEntry OBJECT-TYPE
          SYNTAX     IpsecStatsTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Запись (концептуальная строка) со сведения о конкретной 
             IKE SA."
          INDEX      { ipsecSaIndex }
          ::= { ipsecStatsTable 1 }

        IpsecStatsTableEntry ::= SEQUENCE {
        ipsecSaIndex               Integer32,
   -- Данные статистики пакетов
        txPkts                     Counter64,
        txOctets                   Counter64,
        txDropPkts                 Counter64,
        rxPkts                     Counter64,
        rxOctets                   Counter64,
        rxDropPkts                 Counter64
      }

      ipsecSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { ipsecStatsTableEntry 1 }


      txPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик исходящих пакетов."
          ::= { ipsecStatsTableEntry 2 }

      txOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик байтов в исходящих пакетах."
          ::= { ipsecStatsTableEntry 3 }

      txDropPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик отброшенных исходящих пакетов."
          ::= { ipsecStatsTableEntry 4 }

      rxPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик входящих пакетов."
          ::= { ipsecStatsTableEntry 5 }

      rxOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик байтов во входящих пакетах."
          ::= { ipsecStatsTableEntry 6 }

      rxDropPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик отброшенных входящих пакетов."
          ::= { ipsecStatsTableEntry 7 }

      iptfsInnerStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsInnerStatsSaEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица сведений о внутренних пакетах IP-TFS."
          ::= { iptfsInnerStatsGroup 1 }

      iptfsInnerStatsTableEntry OBJECT-TYPE
         SYNTAX     IptfsInnerStatsSaEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
           "Запись со сведения для конкретной IP-TFS SA."
         INDEX      { iptfsInnerSaIndex }
         ::= { iptfsInnerStatsTable 1 }

        IptfsInnerStatsSaEntry ::= SEQUENCE {
        iptfsInnerSaIndex          Integer32,

        txInnerPkts                Counter64,
        txInnerOctets              Counter64,
        rxInnerPkts                Counter64,
        rxInnerOctets              Counter64,
        rxIncompleteInnerPkts      Counter64
       }

      iptfsInnerSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { iptfsInnerStatsTableEntry 1 }

      txInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число переданных внутренних пакетов IP-TFS. Считаются
            лишь целые пакеты, т. е. все фрагменты пакета считаются
            одним пакетом."
          ::= { iptfsInnerStatsTableEntry 2 }

      txInnerOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число переданных внутренних байтов IP-TFS. Считаются
            только байты внутренних пакетов без учёта заполнения."
          ::= { iptfsInnerStatsTableEntry 3 }

      rxInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число полученных внутренних пакетов IP-TFS."
          ::= { iptfsInnerStatsTableEntry 4 }

          rxInnerOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число полученных внутренних байтов IP-TFS. Байты
            заполнения и издержки не учитываются."
          ::= { iptfsInnerStatsTableEntry 5 }

      rxIncompleteInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число неполных внутренних пакетов IP-TFS. Обычно это
            является результатом отсутствия фрагментов, а также может
            быть следствием нарушения порядка или ошибок в полученных
            внешних пакетах."
       ::= { iptfsInnerStatsTableEntry 6 }

     iptfsOuterStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsOuterStatsSaEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица со сведениями о IP-TFS."
          ::= { iptfsOuterStatsGroup 1 }

      iptfsOuterStatsTableEntry OBJECT-TYPE
         SYNTAX     IptfsOuterStatsSaEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
           "Запись со сведениями о конкретной IP-TFS SA."
         INDEX      { iptfsOuterSaIndex }
         ::= { iptfsOuterStatsTable 1 }

        IptfsOuterStatsSaEntry ::= SEQUENCE {
        iptfsOuterSaIndex               Integer32,

     -- Статистика для пакетов iptfs
        txExtraPadPkts             Counter64,
        txExtraPadOctets           Counter64,
        txAllPadPkts               Counter64,
        txAllPadOctets             Counter64,
        rxExtraPadPkts             Counter64,
        rxExtraPadOctets           Counter64,
        rxAllPadPkts               Counter64,
        rxAllPadOctets             Counter64,
        rxErroredPkts              Counter64,
        rxMissedPkts               Counter64
       }


      iptfsOuterSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { iptfsOuterStatsTableEntry 1 }

      txExtraPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных внешних пакетов IP-TFS с заполнением."
          ::= { iptfsOuterStatsTableEntry 2 }

      txExtraPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число октетов заполнения, добавленных во внешние пакеты
            IP-TFS с данными."
          ::= { iptfsOuterStatsTableEntry 3 }

      txAllPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных пакетов IP-TFS, содержащих лишь заполнение
            (без данных во внутренних пакетах)."
          ::= { iptfsOuterStatsTableEntry 4 }

      txAllPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных октетов заполнения в пакетах IP-TFS без
            данных во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 5 }

      rxExtraPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением."
          ::= { iptfsOuterStatsTableEntry 6 }

      rxExtraPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением и
            данными во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 7 }

      rxAllPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением
            без внутренних пакетов с данными."
          ::= { iptfsOuterStatsTableEntry 8 }

      rxAllPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных октетов заполнения в пакетах 
            IP-TFS без данных во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 9 }

      rxErroredPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число внешних пакетов IP-TFS, отброшенных из-за ошибок."
          ::= { iptfsOuterStatsTableEntry 10 }

      rxMissedPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число пропущенных внешних пакетов IP-TFS, указанных
            пропусками порядковых номеров."
          ::= { iptfsOuterStatsTableEntry 11 }

   --
   -- Соответствие модуля iptfs 
   --

   iptfsMIBConformances OBJECT IDENTIFIER
                       ::= { iptfsMIBConformance 1 }

   iptfsMIBGroups OBJECT IDENTIFIER
                       ::= { iptfsMIBConformance 2 }

   iptfsMIBCompliance MODULE-COMPLIANCE
           STATUS  current
           DESCRIPTION
                   "Заявление о соответствии для объектов,
                   реализующих IP-TFS MIB."
           MODULE  -- this module
                   MANDATORY-GROUPS {
                    iptfsMIBConfGroup,
                    ipsecStatsConfGroup,
                    iptfsInnerStatsConfGroup,
                    iptfsOuterStatsConfGroup
                   }

           ::= { iptfsMIBConformances 1 }

   --
   -- Группы MIB (блоки соответствия)
   --

   iptfsMIBConfGroup OBJECT-GROUP
           OBJECTS {
                   congestionControl,
                   usePathMtuDiscovery,
                   outerPacketSize ,
                   l2FixedRate ,
                   l3FixedRate ,
                   dontFragment,
                   maxAggregationTime,
                   windowSize,
                   sendImmediately,
                   lostPacketTimerInterval
           }
           STATUS  current
           DESCRIPTION
                   "Набор объектов, предоставляемых на уровне 
                   конфигурации IP-TFS SA."
           ::= { iptfsMIBGroups 1 }

   ipsecStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txPkts,
                   txOctets,
                   txDropPkts,
                   rxPkts,
                   rxOctets,
                   rxDropPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих базовую статистику по SA."
           ::= { iptfsMIBGroups 2 }

   iptfsInnerStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txInnerPkts,
                   txInnerOctets,
                   rxInnerPkts,
                   rxInnerOctets,
                   rxIncompleteInnerPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих статистику внутренних 
             пакетов IP-TFS по SA."
           ::= { iptfsMIBGroups 3 }


   iptfsOuterStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txExtraPadPkts,
                   txExtraPadOctets,
                   txAllPadPkts,
                   txAllPadOctets,
                   rxExtraPadPkts,
                   rxExtraPadOctets,
                   rxAllPadPkts,
                   rxAllPadOctets,
                   rxErroredPkts,
                   rxMissedPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих статистику внешних 
             пакетов IP-TFS по SA."
             "A collection of objects providing per SA IP-TFS
             outer packet statistics."
           ::= { iptfsMIBGroups 4 }

   END
   <CODE ENDS>

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

Описанный здесь модуль MIB использует выделенное IANA значение OBJECT IDENTIFIER, внесенное в реестр SMI Network Management MGMT Codes Internet-standard MIB.

Таблица 1.

 

Десятичное значение

Имя

Описание

246

iptfsMIB

IP-TRAFFIC-FLOW-SECURITY-MIB

 

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

Описанный здесь модуль MIB может считывать данные рабочего поведения IP-TFS. Последствия этого рассмотрены в [RFC9347], где описана функциональность.

В описанном модуле MIB нет объектов управления с MAX-ACCESS read-write или read-create, поэтому при корректной реализации модуля MIB не возникает риска изменения или создания злоумышленником объектов управления в этом модуле MIB с помощью прямых операций SNMP SET.

Некоторые из объектов модуля MIB могут быть чувствительными или уязвимыми в отдельных сетевых средах. К таким относятся объекты INDEX с MAX-ACCESS not-accessible и другие индексы из других модулей, раскрываемые через AUGMENT. Важно контролировать доступ к этим объектам даже с помощью GET или NOTIFY и может быть даже шифровать значения объектов при передаче через сеть по протоколу SNMP. Такие таблицы и объекты указаны ниже.

  • iptfsInnerStatsTable и iptfsOuterStatsTable. Доступ к статистике внутренних или внешних пакетов IP-TFS может раскрывать сведения, которые IP-TFS желает скрыть, такие как активность потоков, применяющих IP-TFS.

Версии SNMP до SNMPv3 не обеспечивали должной защиты. Даже в защищённой сети (например, использующей IPsec) не контролируется доступ и операции GET (чтение) для объектов этого модуля MIB.

Реализациям следует обеспечивать функции защиты, описанные в SNMPv3 [RFC3410], а реализации, заявляющие соответствие стандарту SNMPv3, должны включать полную поддержку аутентификации и конфиденциальности с использованием модели защиты по пользователям (User-based Security Model или USM) [RFC3414] с алгоритмом шифрования AES [RFC3826].Реализации могут также поддерживать модель транспортной защиты (Transport Security Model или TSM) [RFC5591] в сочетании с защищённым транспортом, таким как SSH [RFC5592] или TLS/DTLS [RFC6353].

Кроме того, развёртывание версий SNMP до SNMPv3 не рекомендуется. Взамен рекомендуется разворачивать SNMPv3 и включать криптографическую защиту. В дальнейшем клиент (оператор) отвечает за корректную настройку объекта SNMP в части предоставления доступа к экземпляру модуля MIB лишь уполномоченным участникам (пользователям) для выполнения пердусмотренных операций GET или SET (создание, изменение, удаление).

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2)”, STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2”, STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <https://www.rfc-editor.org/info/rfc2579>.

[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Conformance Statements for SMIv2”, STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, <https://www.rfc-editor.org/info/rfc2580>.

[RFC3414] Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)”, STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, <https://www.rfc-editor.org/info/rfc3414>.

[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, “The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model”, RFC 3826, DOI 10.17487/RFC3826, June 2004, <https://www.rfc-editor.org/info/rfc3826>.

[RFC5591] Harrington, D. and W. Hardaker, “Transport Security Model for the Simple Network Management Protocol (SNMP)”, STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, <https://www.rfc-editor.org/info/rfc5591>.

[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, “Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)”, RFC 5592, DOI 10.17487/RFC5592, June 2009, <https://www.rfc-editor.org/info/rfc5592>.

[RFC6353] Hardaker, W., “Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)”, STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <https://www.rfc-editor.org/info/rfc6353>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9347] Hopps, C., “Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)”, RFC 9347, DOI 10.17487/RFC9347, January 2023, <https://www.rfc-editor.org/info/rfc9347>.

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

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework”, RFC 3410, DOI 10.17487/RFC3410, December 2002, <https://www.rfc-editor.org/info/rfc3410>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC9348] Fedyk, D. and C. Hopps, “A YANG Data Model for IP Traffic Flow Security”, RFC 9348, DOI 10.17487/RFC9348, January 2023, <https://www.rfc-editor.org/info/rfc9348>.

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

Авторы благодарны Chris Hopps, Lou Berger, Tero Kivinen за помощь и отклики на модель MIB.

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

Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
 
Eric Kinzie
LabN Consulting, L.L.C.
Email: ekinzie@labn.net

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

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

RFC 9348 A YANG Data Model for IP Traffic Flow Security

Internet Engineering Task Force (IETF)                          D. Fedyk
Request for Comments: 9348                                      C. Hopps
Category: Standards Track                        LabN Consulting, L.L.C.
ISSN: 2070-1721                                             January 2023

A YANG Data Model for IP Traffic Flow Security

Модель данных YANG для IP Traffic Flow Security

PDF

Аннотация

Этот документ описывает модуль YANG для управления дополнениями IP Traffic Flow Security (IP-TFS) для протокола обмена ключами версии 2 (Internet Key Exchange Protocol version 2 или IKEv2) и IPsec.

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ определяет модуль YANG [RFC7950] для управления расширениями IP Traffic Flow Security (IP-TFS), заданными в [RFC9347]. IP-TFS совершенствует защищённые связи (Security Association или SA) через туннели IPsec для усиления конфиденциальности трафика. Конфиденциальность трафика сокращает возможности его анализа для отождествления и сопоставления наблюдаемых картин трафика. IP-TFS обеспечивает эффективность путём агрегирования трафика в туннельные пакеты IPsec с фиксированным размером.

Модель YANG в этом документе соответствует архитектуре хранилищ данных сетевого управления (Network Management Datastore Architecture или NMDA), заданной в [RFC8342].

Опубликованные модули YANG для IPsec заданы в [RFC9061]. Данный документ использует эти модели в качестве базы для IPsec, которая дополняется для IP-TFS. Модель [RFC9061] поддерживает работу с IKE и без IKE.

2. Обзор

Этот документ определяет конфигурационные и рабочие параметры IP-TFS. Расширение IP-TFS, заданное в [RFC9347], определяет защищённые связи для туннельного режима IPsec с характеристиками, усиливающими конфиденциальность трафика и сокращающими снижение потерь пропускной способности. Документы предполагают знакомство читателя с концепциями IPsec, описанными в [RFC4301].

IP-TFS использует туннельный режим для усиления конфиденциальности за счёт сокрытия идентифицируемой информации, размера и времени пакетов. IP-TFS предоставляет базовую возможность агрегирования нескольких пакетов в туннельные пакеты IPsec одинакового размера. Размер внешних пакетов поддерживается за счёт сочетания агрегирования, заполнения и фрагментации внутренних пакетов с целью заполнения внешнего пакета IPsec. Заполнение применяется при отсутствии данных для передачи.

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

Модуль YANG IP-TFS дополняет модуль YANG IPsec из [RFC9061]. IP-TFS использует туннельный режим IPsec и добавляет несколько элементов настройки туннелей IPsec. Как указано в [RFC9347], любая ассоциация SA, настроенная на использование IP-TFS, поддерживает только пакеты IP-TFS (не работает в смешанных режимах IPsec).

Поведение IP-TFS контролируется источником пакетов. Самоописывающий формат пакетов IP-TFS позволяет передающей стороне настраивать размер и время передачи пакетов независимо от получателей. Оба направления трафика независимы, т. е. IP-TFS можно использовать даже в одном направлении. Это означает, что счётчики, заданные здесь для обоих направлений, могут иметь значение 0 или не обновляться, если SA использует IP-TFS лишь в одном направлении.

Ниже указаны случаи, где статистика IP-TFS активна в одном направлении:

  • односторонняя SA при включённом IP-TFS;

  • двухсторонняя SA с IP-TFS лишь для одного направления.

Статистика IP-TFS доступна для обоих направлений при двухсторонней SA и IP-TFS для обоих направлений.

Модель IP-TFS поддерживает конфигурационные и операционные данные IP-TFS.

Этот модуль YANG поддерживает конфигурацию с фиксированным размером и скоростью пакетов, а также элементы, которые могут быть добавлены для поддержки будущих конфигураций. Спецификация протокола [RFC9347] выходит за рамки этого простого, фиксированного режима работы, задавая базовый формат для любого типа схемы. В этом документе внешние пакеты IPsec могут передаваться с фиксированным или переменным размером (без заполнения). Конфигурация позволяет определять фиксированный размер пакетов на основании MTU для пути. Фиксированный размер пакетов можно также задать в конфигурации, если нужно значение меньше MTU для пути.

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

Контроль перегрузки

Настройки контроля перегрузки, позволяющие IP-TFS снижать скорость пакетов при возникновении перегрузки.

Настройка фиксированной скорости

Скорость туннеля IP-TFS может настраиваться с учётом издержек уровня L2 или L3. Издержками L3 является скорость данных IP, а издержками L2 является битовая скорость в канале. Сочетание размера пакетов и скорости определяет номинальную максимальную пропускную способность и интервал передачи при использовании пакетов фиксированного размера.

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

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

Рабочие данные YANG позволяют считывать параметры конфигурации, а также статистику на уровне SA и счётчики ошибок для IP-TFS. Статистика пакетов IPsec на уровне SA обеспечивается как свойство, а статистика IP-TFS на уровне SA – как другое свойство. Оба набора статистики дополняют модули YANG IPsec счётчиками, которые позволяют наблюдать эффективность пакетов IP-TFS.

Объекты управления YANG IPsec заданы в [RFC9061]. YANG IP-TFS дополняет модели IKE и без IKE. В этих моделях запись базы данных правил безопасности (Security Policy) и запись SA для туннеля IPsec могут дополняться IP-TFS. Кроме того, эта модель YANG использует типы, определённые в [RFC6991].

3. Управление YANG

3.1. Дерево YANG

Ниже представлено дерево YANG [RFC8340] для расширений IP-TFS.

   module: ietf-ipsec-iptfs
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd
               /nsfike:spd-entry/nsfike:ipsec-policy-config
               /nsfike:processing-info/nsfike:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:spd/nsfikels:spd-entry
               /nsfikels:ipsec-policy-config/nsfikels:processing-info
               /nsfikels:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64

3.2. Модуль YANG

Ниже представлен модуль YANG для управления расширениями IP-TFS. Эта модель ссылается на [RFC9347] и [RFC5348].

   <CODE BEGINS> file "ietf-ipsec-iptfs@2023-01-31.yang"
   module ietf-ipsec-iptfs {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs";
     prefix iptfs;

     import ietf-i2nsf-ike {
       prefix nsfike;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.2";
     }
     import ietf-i2nsf-ikeless {
       prefix nsfikels;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.3";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     organization
       "IETF IPSECME Working Group (IPSECME)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/ipsecme/> 
        WG List: <mailto:ipsecme@ietf.org> 

        Author: Don Fedyk
                <mailto:dfedyk@labn.net> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org>"; 

     description
       "Этот модуль задаёт конфигурацию и рабочее состояние для 
        управления функциональностью IP-TFS (RFC 9348).

        Авторские права (Copyright (c) 2023) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9348, где правовые
        аспекты приведены более полно.";

     revision 2023-01-31 {
       description
         "Исходный выпуск";
       reference
         "RFC 9348: A YANG Data Model for IP Traffic Flow Security";
     }

     feature ipsec-stats {
       description
         "Указывает поддержку устройством статистики для IPsec SA.";
     }

     feature iptfs-stats {
       description
         "Указывает поддержку устройством статистики IP TFS для SA.";
     }

     /*--------------------*/
     /*   Группировки      */
     /*--------------------*/

     grouping ipsec-tx-stat-grouping {
       description
         "Выходная статистика IPsec";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик выходных пакетов";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в выходных пакетах";
       }
       leaf tx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных выходных пакетов";
       }
     }

     grouping ipsec-rx-stat-grouping {
       description
         "Входная статистика IPsec";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик входных пакетов";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в входных пакетах";
       }
       leaf rx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных входных пакетов";
       }
     }

     grouping iptfs-inner-tx-stat-grouping {
       description
         "Статистика вложенных выходных пакетов IP-TFS";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных пакетов IP-TFS. Учитываются
            только целые пакеты, все фрагменты пакета считаются за 1.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных октетов IP-TFS. Заполнение
            не учитывается.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-tx-stat-grouping {
       description
         "Статистика выходных вложенных пакетов IP-TFS.";
       leaf tx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных пакетов IP-TFS, содержавших только
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения в пакетах IP-TFS
            без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных внешних пакетов IP-TFS, содержащих
            заполнение.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf tx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения, добавленных во
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
     }

     grouping iptfs-inner-rx-stat-grouping {
       description
         "Входная статистика вложенных пакетов IP-TFS";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных вложенных пакетов IP-TFS.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число принятых вложенных октетов IP-TFS без учёта
            заполнения и издержек.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-incomplete-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число неполных вложенных пакетов IP-TFS. Обычно это
            возникает в результате пропуска фрагментов и может быть
            следствием нарушения порядка или ошибок в полученных внешних
            пакетах.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-rx-stat-grouping {
       description
         "Входная статистика внешних пакетов IP-TFS";
       leaf rx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных пакетов IP-TFS, содержащих лишь
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных 
            в пакеты IP-TFS без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число принятых внешних пакетов IP-TFS с заполнением.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных во 
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-errored-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число внешних пакетов IP-TFS, отброшенных из-за 
            ошибок.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf rx-missed-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число отсутствующих внешних пакетов IP-TFS, указанное
            отсутствующим порядковым номером.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-config {
       description
         "Группировка для конфигурации IP-TFS.";
       container traffic-flow-security {
         description
           "Настраивает IPsec TFS в базе SAD.";
         leaf congestion-control {
           type boolean;
           default "true";
           description
             "Принятое по умолчанию значение true включает обмен данными
              о перегрузке в линии, которые нужны алгоритмам контроля
              перегрузок, как указано в RFC 5348. При установке false 
              IP-TFS передаёт пакеты фиксированного размера через 
              туннель IP-TFS с постоянной скоростью.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.4.2;
              RFC 5348: TCP Friendly Rate Control (TFRC): Protocol
              Specification";
         }
         container packet-size {
           description
             "Размер пакетов задаётся вручную или определяется
              автоматически.";
           leaf use-path-mtu-discovery {
             type boolean;
             default "true";
             description
               "Применяется определение MTU на пути для задания 
                максимального размера пакетов IP-TFS. Если размер задан
                явно, при установке use-path-mtu-discovery он может лишь
                сокращаться.";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
           leaf outer-packet-size {
             type uint16;
             units "bytes";
             description
               "Размер внешнего инкапсулирующего пакета при передаче
                (т. е. пакета IP с содержимым ESP).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
         }
         choice tunnel-rate {
           description
             "Битовая скорость TFS может быть задана скоростью линии L2
              или скоростью пакетов L3.";
           leaf l2-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
           leaf l3-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
         }
         leaf dont-fragment {
           type boolean;
           default "false";
           description
             "При передаче отключает фрагментацию между 
              последовательными пакетами туннеля IP-TFS. Внутренние 
              пакеты, не помещающиеся во внешний пакет, отбрасываются.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.4 and
              6.1.4";
         }
         leaf max-aggregation-time {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При передаче максимальным временем агрегирования является
              максимальное время удержания полученного внутреннего 
              пакета до передачи в туннеле IP-TFS. Внутренние пакеты,
              которые удерживаются дольше этого времени, исходя из
              текущей конфигурации, будут отбрасываться вместо включения
              в очередь передачи. Максимальное время агрегирования 
              задаётся в миллисекундах или долях миллисекунды вплоть
              до 1 наносекунды.";
         }
         leaf window-size {
           type uint16 {
             range "0..65535";
           }
           description
             "Максимальное число полученных с нарушением порядка пакетов,
              для которых получатель IP-TFS будет восстанавливать порядок.
              Значение 0 отключает восстановление порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
         leaf send-immediately {
           type boolean;
           default "false";
           description
             "Задаёт максимально быструю отправку пакетов при получении 
              без ожидания потерянных и разупорядоченных внешних пакетов.
              Выбор этой опции сокращает задержку вложенных 
              (пользовательских) пакетов, но усиливает нарушение порядка
              доставки потока вложенных пакетов при наличии 
              агрегирования или нарушения порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.5";
         }
         leaf lost-packet-timer-interval {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При получении задаёт время ожидания получателем IP-TFS
              пропущенного пакета, прежде чем счесть его потерянным.
              Если не задан лист send-immediately, каждый потерянный
              пакет будет задерживать внутренние (пользовательские)
              пакеты, пока не наступит этот тайм-аут. Установка слишком
              малого значения может влиять на восстановление порядка и
              сборку. Значение задаётся в миллисекундах или долях 
              миллисекунды вплоть до 1 наносекунды.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
       }
     }

     /*
      * Крнфигурация IP-TFS IKE
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/"
           + "nsfike:spd-entry/"
           + "nsfike:ipsec-policy-config/"
           + "nsfike:processing-info/"
           + "nsfike:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Конфигурация IP-TFS без IKE
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:spd/"
           + "nsfikels:spd-entry/"
           + "nsfikels:ipsec-policy-config/"
           + "nsfikels:processing-info/"
           + "nsfikels:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }
   }
   <CODE ENDS>

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

4.1. Обновление реестра IETF XML

В соответствии с этим документом агентство IANA зарегистрировало URI в реестре IETF XML Registry [RFC3688]

   URI:  urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

4.2. Обновление реестра YANG Module Names

В соответствии с этим документом агентство IANA зарегистрировало модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-ipsec-iptfs
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs
   Prefix:  iptfs
   Reference:  RFC 9348

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

../traffic-flow-security

Включение IP-TFS контролируется установкой записей в ветви traffic-flow-security моделей с IKE или без IKE. Параметры в этом дереве устанавливаются для IP-TFS чувствительность к перегрузкам или фиксированную скорость.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

../iptfs-inner-pkt-stats и ../iptfs-outer-pkt-stats

Доступ к статистике IP-TFS даёт сведения о событиях IP-TFS, таких как корректная работа потоков IP-TFS.

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

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

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, “A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)”, RFC 9061, DOI 10.17487/RFC9061, July 2021, <https://www.rfc-editor.org/info/rfc9061>.

[RFC9347] Hopps, C., “Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)”, RFC 9347, DOI 10.17487/RFC9347, January 2023, <https://www.rfc-editor.org/info/rfc9347>.

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

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

Приложение A. Примеры

Ниже приведены примеры данных конфигурации и рабочего состояния для вариантов использования с IKE и без IKE в формате XML и JSON. Показана также операционная статистика для варианта без IKE.

A.1. Конфигурация XML

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

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:spd>
       <i:spd-entry>
         <i:name>protect-policy-1</i:name>
         <i:direction>outbound</i:direction>
         <i:ipsec-policy-config>
           <i:traffic-selector>
             <i:local-prefix>192.0.2.0/16</i:local-prefix>
             <i:remote-prefix>198.51.100.0/16</i:remote-prefix>
           </i:traffic-selector>
           <i:processing-info>
             <i:action>protect</i:action>
             <i:ipsec-sa-cfg>
               <tfs:traffic-flow-security>
                <tfs:congestion-control>true</tfs:congestion-control>
                 <tfs:packet-size>
                   <tfs:use-path-mtu-discovery
                      >true</tfs:use-path-mtu-discovery>
                 </tfs:packet-size>
                 <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
                 <tfs:max-aggregation-time
                    >0.1</tfs:max-aggregation-time>
                 <tfs:window-size>5</tfs:window-size>
                 <tfs:send-immediately>false</tfs:send-immediately>
                 <tfs:lost-packet-timer-interval
                    >0.2</tfs:lost-packet-timer-interval>
               </tfs:traffic-flow-security>
             </i:ipsec-sa-cfg>
           </i:processing-info>
         </i:ipsec-policy-config>
       </i:spd-entry>
     </i:spd>
   </i:ipsec-ikeless>

Рисунок 1. Пример конфигурации IP-TFS XML.

A.2. Рабочие данные XML

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

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:sad>
       <i:sad-entry>
         <i:name>sad-1</i:name>
         <i:ipsec-sa-config>
           <i:spi>1</i:spi>
           <i:traffic-selector>
             <i:local-prefix>2001:db8:1::/48</i:local-prefix>
             <i:remote-prefix>2001:db8:2::/48</i:remote-prefix>
           </i:traffic-selector>
         </i:ipsec-sa-config>
         <tfs:traffic-flow-security>
           <tfs:congestion-control>true</tfs:congestion-control>
           <tfs:packet-size>
             <tfs:use-path-mtu-discovery
               >true</tfs:use-path-mtu-discovery>
           </tfs:packet-size>
           <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
           <tfs:max-aggregation-time>0.100</tfs:max-aggregation-time>
           <tfs:window-size>0</tfs:window-size>
           <tfs:send-immediately>true</tfs:send-immediately>
           <tfs:lost-packet-timer-interval
             >0.200</tfs:lost-packet-timer-interval>
         </tfs:traffic-flow-security>
       </i:sad-entry>
     </i:sad>
   </i:ipsec-ikeless>

Рисунок 2. Пример рабочих данных IP-TFS XML.

A.3. Конфигурация JSON

Этот пример показывает данные конфигурации для IP-TFS с IKE. Отметим, что это дополняет схему IPsec IKE, , поэтому задана лишь минимальная конфигурация для схемы с IKE.

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
             {
               "id": 1,
               "algorithm-type": 12,
               "key-length": 128
             }
             ],
             "local": {
               "local-pad-entry-name": "local-1"
             },
             "remote": {
               "remote-pad-entry-name": "remote-1"
             },
             "ietf-i2nsf-ike:spd": {
             "spd-entry": [
               {
                 "name": "protect-policy-1",
                 "ipsec-policy-config": {
                   "traffic-selector": {
                     "local-prefix": "192.0.2.0/16",
                     "remote-prefix": "198.51.100.0/16"
                   },
                   "processing-info": {
                     "action": "protect",
                     "ipsec-sa-cfg": {
                       "ietf-ipsec-iptfs:traffic-flow-security": {
                         "congestion-control": true,
                         "l2-fixed-rate": "1000000000",
                         "packet-size": {
                           "use-path-mtu-discovery": true
                         },
                         "max-aggregation-time": "0.1",
                         "window-size": 1,
                         "send-immediately": false,
                         "lost-packet-timer-interval": "0.2"
                       }
                     }
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 3. Пример конфигурации IP-TFS JSON.

A.4. Рабочие данные JSON

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

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
           {
             "id": 1,
             "algorithm-type": 12,
             "key-length": 128
           }
           ],
           "local": {
             "local-pad-entry-name": "local-1"
           },
           "remote": {
             "remote-pad-entry-name": "remote-1"
           },
           "ietf-i2nsf-ike:child-sa-info": {
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "congestion-control": true,
               "l2-fixed-rate": "1000000000",
               "packet-size": {
                 "use-path-mtu-discovery": true
               },
               "max-aggregation-time": "0.1",
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             }
           }
         }
       ]
     }
   }

Рисунок 4. Пример операционных данных IP-TFS JSON.

A.5. Операционная статистика JSON

Этот пример показывает статистику IP-TFS в формате JSON. Отметим, что показана передающая сторона двухстороннего IP-TFS в произвольными номерами при передаче.

   {
     "ietf-i2nsf-ikeless:ipsec-ikeless": {
       "sad": {
         "sad-entry": [
           {
             "name": "sad-1",
             "ipsec-sa-config": {
               "spi": 1,
               "traffic-selector": {
                 "local-prefix": "192.0.2.1/16",
                 "remote-prefix": "198.51.100.0/16"
               }
             },
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             },
             "ietf-ipsec-iptfs:ipsec-stats": {
               "tx-pkts": "300",
               "tx-octets": "80000",
               "tx-drop-pkts": "2",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-drop-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-inner-pkt-stats": {
               "tx-pkts": "250",
               "tx-octets": "75000",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-incomplete-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-outer-pkt-stats": {
               "tx-all-pad-pkts": "40",
               "tx-all-pad-octets": "40000",
               "tx-extra-pad-pkts": "200",
               "tx-extra-pad-octets": "30000",
               "rx-all-pad-pkts": "0",
               "rx-all-pad-octets": "0",
               "rx-extra-pad-pkts": "0",
               "rx-extra-pad-octets": "0",
               "rx-errored-pkts": "0",
               "rx-missed-pkts": "0"
             },
             "ipsec-sa-state": {
               "sa-lifetime-current": {
                 "time": 80000,
                 "bytes": "400606",
                 "packets": 1000,
                 "idle": 5
               }
             }
           }
         ]
       }
     }
   }

Рисунок 5. Пример статистики IP-TFS JSON.

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

Авторы благодарны Eric Kinzie, Jürgen Schönwälder, Lou Berger, Tero Kivinen за отклики и рецензии на модуль YANG.

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

Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
 
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

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

RFC 9347 Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)

Internet Engineering Task Force (IETF)                          C. Hopps
Request for Comments: 9347                       LabN Consulting, L.L.C.
Category: Standards Track                                   January 2023
ISSN: 2070-1721

Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)

Режим агрегирования и фрагментации для ESP и его применение в IP-TFS

PDF

Аннотация

Документ описывает механизм агрегирования и фрагментирования пакетов IP, инкапсулируемых в защищённые данные (Encapsulating Security Payload или ESP). Этот новый тип содержимого пакетов (payload) может применяться для разных целей, таких как сокращение издержек инкапсуляции для мелких пакетов IP, однако этот документ сосредоточен на улучшении защиты потоков трафика IP (IP Traffic Flow Security или IP-TFS) путём добавления конфиденциальности потока трафика (Traffic Flow Confidentiality или TFC) в трафик с инкапсуляцией IP. TFC обеспечивается путём сокрытия размера и частоты пакетов IP за счёт использования туннеля IPsec с постоянным размером и частотой передачи пакетов. Это позволяет контролировать перегрузку, а также использовать непостоянную скорость передачи трафика.

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

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

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

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

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

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Анализом трафика [RFC4301] [AppCrypt] называют действия по извлечению сведений о данных, передаваемых через сеть. При непосредственном сокрытии данных путём шифрования [RFC4303] картина трафика сообщения может раскрывать некоторые сведения из-за различий в форме и времени отправки [RFC8546] [AppCrypt]. Сокрытие размера и частоты передачи трафика называют конфиденциальностью потока трафика (TFC), в соответствии с [RFC4303].

[RFC4303] обеспечивает TFC за счёт заполнения (padding) шифрованных пакетов IP и возможности передавать пакеты, содержащие лишь заполнение (all-pad), что указывается номером протокола 59. Этому методу присуще важное ограничение, связанное с существенными издержками для пропускной способности.

Этот документ определяет для ESP режим агрегирования и фрагментирования (aggregation and fragmentation или AGGFRAG), а также задаёт применение ESP для IP-TFS. Это решение обеспечивает полную функциональность TFC без отмеченных издержек для пропускной способности. Это достигается за счёт применения туннелей IPsec [RFC4303] с фиксированным размером инкапсулированных пакетов, которые могут содержать целые пакеты IP,их фрашменты или несколько пакетов для максимального использования пропускной способности туннеля. Переменная скорость передачи разрешена, но конфиденциальность при её использовании не рассматривается в этом документе.

Сравнение издержек IP-TFS и решения TFC, предписанного в [RFC4303], дано в Приложении C.

Кроме того, IP-TFS обеспечивает беспристрастность в перегруженных сетях [RFC2914]. Это важно в случаях, когда пользователь IP-TFS не имеет полного контроля над доменами, через которые проходит туннель IP-TFS.

Заданные в этом документе механизмы, такие как AGGFRAG, согласуются с намерением разрешать работу без TFS, но этот вопрос выходит за рамки документа.

1.1. Термины и концепции

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

Документ предполагает знакомство читателя с концепциями защиты IP, включая TFC, как описано в [RFC4301].

2. Туннель AGGFRAG

Как отмечено в разделе 1, режим AGGFRAG использует туннель IPsec [RFC4303] в качестве транспорта. Для целей IP-TFS в туннель AGGFRAG передаются пакеты фиксированного размера с постоянной скоростью.

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

Фиксированный размер пакетов может быть задан вручную или определён с помощью таких методов, как PLMTUD3 [RFC4821] [RFC8899] или PMTUD4 [RFC1191] [RFC8201]. С методом PMTUD связаны известные проблемы, поэтому PLMTUD считается более надёжным вариантом. Для PLMTUD содержимое (payload) контроля перегрузок может применяться в качестве канальных (in-band) зондов (см. параграф 6.1.2 и [RFC8899]).

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

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

2.1. Содержимое туннеля

Как было отмечено, одной из проблем, связанных с заполнением TFC [RFC4303] является избыточный расход пропускной способности, поскольку в инкапсулированном пакете может содержаться лишь 1 пакет IP. Для максимального пропускания в IP-TFS эта зависимость разрывается путём введения режима AGGFRAG для ESP.

Режим AGGFRAG агрегирует и фрагментирует вложенный трафик IP при инкапсуляции в пакеты туннеля IPsec. В IP-TFS инкапсулированные в туннель IPsec пакеты имеют фиксированный размер. Заполнение добавляется в туннельные пакеты лишь при отсутствии данных для передачи на момент отправки следующего пакета или запрете фрагментации получателем.

Это достигается путём использования в поле ESP [RFC4303] Next Header значения AGGFRAG_PAYLOAD (6.1. Содержимое AGGFRAG_PAYLOAD).

Были предложены иные (не IP-TFS) варианты использования режима AGGFRAG, такие как повышение производительности за счёт агрегирования пакетов, а также решение проблемы MTU за счёт фрагментации. Эти вопросы не рассматриваются в документе, но применение таких методов документ не ограничивает.

2.2. Содержимое Payload

Содержимое данных (payload) AGGFRAG_PAYLOAD, определённое этим документом, включает 4- или 24-октетный заголовок, за которым следует полный или неполный блок данных или несколько таких блоков. На рисунке 1 показаны эти поля в пакете ESP. Полное описание AGGFRAG_PAYLOAD дано в параграфе 6.1.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Внешний заголовок инкапсуляции ...                            .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Заголовок ESP  ...                                            .
+---------------------------------------------------------------+
|   [субтип и флаги AGGFRAG]   :           BlockOffset          |
+---------------------------------------------------------------+
:             [Необязательные данные о перегрузке]              :
+---------------------------------------------------------------+
|       DataBlocks ...                                          ~
~                                                               ~
~                                                               |
+---------------------------------------------------------------|
. Трейлер ESP ...                                               .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Рисунок 1. Схема пакета IPsec в режиме AGGFRAG.


BlockOffset имеет значение 0 или указывает некое смещение в DataBlocks или после блока данных. BlockOffset = 0 указывает, что DataBlocks начинается с нового блока данных. Отличное от 0 значение BlockOffset указывает начало нового блока данных, а исходные данные DataBlocks относятся к блоку, которые ещё находится в процессе сборки. Если BlockOffset указывает значение после конца DataBlocks, это говорит, что следующий блок данных размещается в последующем инкапсулированном пакете. Наличие BlockOffset всегда указывает следующий доступный данных, что позволяет восстановить следующий вложенный пакет в случае потери внешнего инкапсулирующего пакета.

Пример потока пакетов для режима AGGFRAG представлен в Приложении A.

2.2.1. Блоки данных

+---------------------------------------------------------------+
| Type  | Остаток IPv4, IPv6 или заполнение ...
+--------

Рисунок 2. Схема блока данных.


Блок данных определяется 4-битовым кодом типа, за которым следует сам блок. Значения типов были аккуратно подобраны в соответствии со значениями полей IPv4 или IPv6, чтобы не возникало связанных с типом блока издержек при инкапсуляции пакетов IP. Размер блока данных извлекается из инкапсулированного поля IPv4 Total Length или IPv6 Payload Length.

2.2.2. Заполнение в конце

Поскольку блок данных указывается первыми 4 битами, заполнение требуется лишь при отсутствии данных для инкапсуляции. Для этого применяется специальный блок данных – Pad Data Block.

2.2.3. Фрагментация, порядковые номера и данные лишь с заполнением

Чтобы получатель мог собрать фрагментированные вложенные пакеты, отправитель должен передавать фрагменты вложенных пакетов вплотную друг к другу в логическом потоке внешних пакетов (т. е. с использованием последовательных порядковых номеров ESP). Однако отправителю разрешено вставлять содержимое (payload), состоящее только из заполнения (all-pad, т. е. данные с BlockOffset = 0 и одним блоком заполнения) между пакетами, передающими фрагменты вложенного пакета. Такое чередование с пакетами all-pad позволяет отправителю передавать туннельные пакеты независимо от вычислительных потребностей при инкапсуляции. Когда получатель собирает вложенный пакет, имея принятые данные all-pad, он инкрементирует порядковый номер пакета, в котором ожидается прибытие следующего фрагмента вложенного пакета.

С учётом изложенного выше, получателю требуется обрабатывать полученные с нарушением порядка внешние пакеты ESP перед сборкой. В ESP уже имеется возможность обнаружения атак с повторным использованием пакетов (replay), которая обычно реализуется на основе окна. Аналогичное скользящее окно на основе порядкового номера может применяться для восстановления порядка в потоке внешних пакетов. При получении большего (более нового) порядкового номера в пакете окно сдвигается вперёд и при получении более старых пакетов ESP с номерами, вне окна такие пакеты отбрасываются. Выбор размера окна зависит от степени нарушения порядка, с которой сталкивается пользователь. Предлагается по умолчанию использовать окно размеров в 3 пакета, если нет причин его менять. Поскольку степень разупорядочения пакетов трудно предсказать, размер окна следует делать настраиваемым пользователем. Реализации могут динамически подстраивать размер окна на основе фактического нарушения порядка доставки пакетов.

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

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

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

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

Примечание по значениям BlockOffset. Отправитель должен кодировать BlockOffset в соответствии с непосредственно предшествовавшим пакетом, содержащим не только заполнение. В частности, если непосредственно предшествующий пакет, содержащий не только заполнение, завершается Pad Data Block, значение BlockOffset должно быть 0, поскольку блоки Pad Data не фрагментируются. Значение BlockOffset должно соответствовать оставшемуся размеру, подразумеваемому полем размера во фрагментированном вложенном пакете.

2.2.3.1. Дополнительное заполнение

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

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

2.2.4. Пустое содержимое

Для поддержки передачи сведений контроля перегрузок (см. ниже) с использованием SA без поддержки AGGFRAG_PAYLOAD разрешено передавать содержимое (payload) AGGFRAG_PAYLOAD без блоков данных (т. е. размер данных ESP совпадает с размером заголовка AGGFRAG_PAYLOAD). Такое содержимое называется пустым (empty payload). В настоящее время это применимо лишь при работе без использования IKEv2.

2.2.5. Отображение полей заголовков IP

В [RFC4301] даны некоторые рекомендации по части отображения значений из внутреннего заголовка IP во внешний, а именно, бита запрета фрагментирования (Don’t Fragment или DF) [RFC0791], поля дифференцированного обслуживания (Differentiated Services или DS) [RFC2474] и поля явного уведомления о перегрузке (Explicit Congestion Notification или ECN) [RFC3168]. В отличие от [RFC4301], режим AGGFRAG может и часто будет инкапсулировать более одного пакета IP в пакет ESP. Это вносит дополнительные ограничения для отображения полей.

2.2.5.1. Бит DF

В режиме AGGFRAG бит DF не отображается во внешний заголовок, поскольку он не связан с функциональностью туннеля AGGFRAG. В режиме AGGFRAG не требуется IP-фрагментация вложенных пакетов и на них не влияет фрагментация внешних пакетов инкапсуляции.

2.2.5.2. Значение ECN

Значение ECN не требуется отображать, поскольку любая перегрузка, связанная с туннелем IP-TFS с постоянной скоростью передачи, по своей природе не связана с потоком вложенного трафика. отправитель может по-прежнему устанавливать ECN во вложенных пакетах в соответствии со спецификацией ECN [RFC3168] [RFC4301] [RFC6040].

2.2.5.3. Поле DS

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

2.2.6. IPv4 TTL, IPv6 Hop Limit и сообщения ICMP

Изменение полей IPv4 TTL [RFC0791] и IPv6 Hop Limit [RFC8200] во внутренних заголовках описано в [RFC4301].

В [RFC4301] указано, как применять политику для аутентифицированных и разрешённых пакетов с ошибками ICMP (например, Destination Unreachable), прибывающих или пересланных через конечныю точку, в частности обрабаьывать, игнорировать или пересылать такие пакеты. За одним исключением этот документ не меняет обработку таких пакетов, заданную в [RFC4301].

Едиственным отличием туннеля AGGFRAG при обработке ошибок ICMP является PMTU. При разрешённой в туннеле AGGFRAG фрагментации, не требуется генерировать ошибку ICMP Too Big при получении входного трафика, поскольку внутренние пакеты естественным путём фрагментируются при инкапсуляции AGGFRAG.

Если фрагментация в туннеле AGGFRAG отключена, обработка входящего трафика в точности соответствует обработке в туннеле ESP без AGGFRAG. В явном виде пакеты IPv4 с флагом DF и пакеты IPv6, которые не помещаются в данные (payload) внешнего пакета, будут вызывать соответствующую ошибку ICMP Too Big, как описано в [RFC4301], а пакеты IPv4 без флага DF будут фрагментироваться IP, как описано в [RFC4301].

Выходящие из туннеля пакеты обрабатываются в соответствии с [RFC4301].

Остальные аспекты PMTU и обработки сообщений ICMP Too Big (т. е. связанные с размером внешних пакетов туннеля AGGFRAG/ESP) также соответствуют [RFC4301].

2.2.7. Эффективное значение MTU для туннеля

В отличие от [RFC4301] в туннелях AGGFRAG обычно не применяется эффективное значение MTU (EMTU), поскольку пакеты IP всех размеров передаются без фрагментации IP перед входом в туннель. При этом отправитель может разрешать явную настройку MTU для туннеля.

Если фрагментация в туннеле AGGFRAG отключена, значение EMTU и поведение туннеля не отличается от обычного для туннелей [RFC4301].

2.3. Исключительное использование SA

Этот документ не задаёт смешанного использования SA с разрешённым AGGFRAG_PAYLOAD. Отправитель должен передавать в SA, настроенных на режим AGGFRAG, только данные (payload) AGGFRAG_PAYLOAD.

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

Как и обычные IPsec/ESP SA, защищённые связи AGGFRAG SA являются односторонними. Двухсторонняя работа IP-TFS обеспечивается организацией двух AGGFRAG SA, по одной для каждого направления.

Туннель AGGFRAG, применяемый для IP-TFS. Может работать в 2 режимах – с контролем и без контроля перегрузок.

2.4.1. Режим без контроля перегрузок

В режиме без контроля перегрузок IP-TFS передаёт пакеты фиксированного размера через туннель AGGFRAG с постоянной скоростью. Размер пакетов постоянный и не подстраивается автоматически независимо от перегрузок (например, потери пакетов).

По тем же причинам, которые указаны в [RFC7510], режим без контроля перегрузок должен применяться лишь в тех случаях, когда у пользователя есть полный административный контроль над всеми участками туннеля. В иных случаях применение этого режима недопустимо. Это нужно для того, чтобы пользователь мог гарантировать пропускную способность а также быть уверенным в отсутствии негативного влияния на перегрузки в сети [RFC2914]. В этом случае администратор уведомляется о потере пакетов (например, через syslog, уведомления YANG, ловушки SNMP и т. п.), чтобы любой отказ, связанный с нехваткой пропускной способности можно было устранить. Рекомендуется также использовать выключатели, описанные в параграфе 2.4.2.1.

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

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

Режим без контроля перегрузок подходит также при работе ESP по протоколу TCP [RFC9329]. Однако использование TCP считается лишь резервным решением для IPsec и крайне нежелательно. Это также является одной из причин, по которым протокол TCP не был выбран для инкапсуляции IP-TFS вместо AGGFRAG.

2.4.2. Режим с контролем перегрузок

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

Результатом алгоритма контроля перегрузок является подстройка скорости отправки пакетов на входе туннеля. Хотя этот документ на требует конкретного алгоритма контроля перегрузок, на основе опыта рекомендуется применять алгоритм, соответствующий [RFC5348]. Принципы контроля перегрузок описаны в [RFC2914]. В [RFC4342] имеется пример алгоритма из [RFC5348], соответствующего требованиям IP-TFS (т. е. предназначенного для пакетов фиксированного размера и скорости отправки, зависящей от насыщения).

Входными данными для дружественного к TCP алгоритма управления скоростью, описанного в [RFC5348], являются частота потерь у получателя и оценка отправителем времени кругового обхода (round-trip time или RTT). Эти значения предоставляются IP-TFS с использованием данных о насыщении в полях заголовка, описанных в разделе 3. В частности, этих значений достаточно для реализации алгоритма, описанного в [RFC5348].

Сведения о перегрузке должны передаваться по меньшей мере 1 раз за интервал RTT. До определения RTT сведения следует постоянно передавать от отправителя и получателя, чтобы можно было оценить значение RTT. Отсутствие этих сведений в течение нескольких интервалов RTT подряд следует считать индикатором перегрузки, заставляющим отправителя снижать скорость передачи. Например, в [RFC4342] это называется «временем ожидания без откликов» (no feedback timeout) и равно 4 интервалам RTT. При возникновении такого тайм-аута скорость отправки снижается вдвое в соответствии с [RFC4342].

Реализация может всегда включать сведения о перегрузке в свой заголовок данных AGGFRAG, если они передаются через SA с поддержкой IP-TFS. Поскольку IP-TFS обычно работает с большим размером пакетов, сведения о перегрузке будут составлять незначительную часть доступной для туннеля пропускной способности. Реализация, выбравшая постоянную передачу сведений о насыщении, может выбрать обновление лишь значения полей заголовка LossEventRate и RTT, передаваемый в каждом интервале RTT.

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

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

2.4.2.1. Выключатели

В дополнение к контролю перегрузок реализациям, поддерживающим режим без контроля перегрузок, следует реализовать выключатели (circuit breaker) [RFC8084] как метод восстановления в крайних случаях. Когда такие выключатели разрешены, реализации следует также разрешать отчёты контроля перегрузок, чтобы выключатели имели сведения, требуемые для их работы.

Соображения о перегрузке псевдопроводов [RFC7893] применимы к заданным в этом документе механизмам, особенно в части текста о неэластичном трафике.

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

2.5. Сводка для обработки у получателя

В SA со включённым AGGFRAG получатель должен выполнять несколько задач.

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

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

Кроме того, при включённом контроле перегрузок получатель передаёт данные такого контроля (6.1.2. Формат содержимого AGGFRAG_PAYLOAD при контроле перегрузок) отправителю, как указано в параграфе 2.4.2 и разделе 3.

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

3. Индикация перегрузки

Для поддержки режима с контролем перегрузок получателю нужно знать частоту потери пакетов и примерное значение RTT [RFC5348]. Чтобы получить эти значения, получатель передаёт данные контроля перегрузок отправителю через свою SA. Таким образом, для поддержки контроля перегрузок получатель должен иметь парную SA к отправителю (это всегда выполняется при создании туннеля с использованием IKEv2). Если SA к отправителю не поддерживает AGGFRAG_PAYLOAD, для передачи сведений служит пустое содержимое AGGFRAG_PAYLOAD (только заголовки).

Для расчёта частоты потерь в соответствии с [RFC5348] получателю нужна оценка RTT, поэтому отправитель сообщает эту оценку в поле заголовка RTT. При старте это 0, пока не будет получена реальная оценка RTT. Для оценки отправителем своего значения RTT он помещает метку времени в поле заголовка TVal. При первом приёме этой метки TVal получатель записывает новое значение TVal вместе с временем прибытия метки. При последующем получении того же TVal недопустимо обновлять записанное время.

Когда получатель передаёт свой заголовок контроля перегрузки, он помещает последнее записанное значение TVal в поле заголовка TEcho вместе с двумя значениями задержки Echo Delay и Transmit Delay. Значение Echo Delay указывает разницу между записанным временем прибытия TVal и текущим временем в микросекундах. Transmit Delay указывает текущую задержку получателя при передаче через туннель (среднее время между отправкой пакетов на его стороне туннеля AGGFRAG).

Когда получатель принимает своё значение TVal в поле заголовка TEcho, он делает две оценки RTT. Первая указывает фактическую задержку, определяемую вычитанием TEcho из текущего времени и последующим вычитанием Echo Delay. Вторая оценка RTT определяется сложением полученного в заголовке значения Transmit Delay с собственной задержкой передачи у отправителя (среднее время между отправкой пакетов на его стороне туннеля AGGFRAG). Большее из полученных значений следует выбирать в качестве RTT. Две оценки RTT нужны для обработки разных комбинаций быстрого и медленного пути через туннель с большей или меньшей фиксированной скоростью в туннеле. Выбор большего из двух значений гарантирует, что RTT не будет меньше совокупной задержки передачи на основе скорости IP-TFS (вторая оценка) и фактического RTT на пути пакетов через туннель (первая оценка).

Получатель также рассчитывает и передаёт в поле заголовка LossEventRate частоту потерь для использования её отправителем. Это несколько отличается от [RFC4342], где отправителю периодически передаются все данные о потере пакетов для выполнения расчётов. В Приложении B представлен способ расчёта частоты потерь. Изначально это 0 (нет потерь), пока получатель не соберёт достаточно данных для оценки частоты потерь.

3.1. Поддержка ECN

В дополнение к обычным сведениям о потере пакетов режим AGGFRAG поддерживает использование битов ECN в заголовке инкапсуляции IP [RFC3168] для идентификации перегрузки. Если применение ECN разрешено и пакет приходит на выходную (приёмную) сторону с установленным битом перегрузки (Congestion Experienced или CE), получатель считает пакет отброшенным, хотя это не так. Получатель должен устанавливать бит E в любом заголовке содержимого AGGFRAG_PAYLOAD, содержащем значение LossEventRate, выведенное из рассматриваемого CE.

В [RFC6040], обновляющем [RFC3168] и [RFC4301], задана маркировка внешнего поля ECN на основе поля ECN во вложенном заголовке. Поскольку в режиме AGGFRAG в одном внешнем пакете может быть несколько вложенных пакетов и нет очевидного способа сопоставить множество значений из вложенных пакетов с ECN в одном внешнем пакете, входной точке туннеля следует работать в режиме совместимости (compatibility), а не в режиме default из [RFC6040]. В частности, это означает, что входная (передающая) конечная точка туннеля всегда устанавливает в поле ECN значение Not-ECT [RFC6040].

4. Конфигурация туннелей AGGFRAG для IP-TFS

IP-TFS служит для развёртывания с минимальной настройкой. Всю конфигурацию IP-TFS следует задавать на входной (передача) стороне одностороннего туннеля. Предполагается поддержка работы без IKEv2 по крайней мере при локальной настройке. Документы YANG и MIB для IP-TFS заданы в [RFC9348] и [RFC9349].

4.1. Пропускная способность

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

4.2. Фиксированный размер пакетов

Фиксированный размер пакетов для использования при туннельной инкапсуляции пакетов может настраиваться вручную или определяться автоматически с использованием таких методов, как PLMTUD [RFC4821] [RFC8899] или PMTUD [RFC1191] [RFC8201]. Поскольку у PMTUD имеются проблемы, PLMTUD считается более предпочтительным вариантом. Стандартизированный метод настройки не требуется.

4.3. Контроль перегрузок

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

5. IKEv2

5.1. Уведомления USE_AGGFRAG

Как отмечено выше, в туннелях AGGFRAG применяется содержимое ESP типа AGGFRAG_PAYLOAD. При использовании IKEv2 новое уведомление USE_AGGFRAG разрешает содержимое AGGFRAG_PAYLOAD для пары Child SA. Используемый метод поход на согласование USE_TRANSPORT_MODE, описанное [RFC7296]. Для запроса применения AGGFRAG_PAYLOAD с парой Child SA инициатор включает уведомление USE_AGGFRAG в содержимое SA, запрашивающее новую связь Child SA (при начальном IKE_AUTH или в процессе обмена CREATE_CHILD_SA). Если запрос принимается, отклик должен включать уведомление типа USE_AGGFRAG. При отклонении запроса Child SA будет создаваться без возможности использовать содержимое AGGFRAG_PAYLOAD. Если инициатора это не устраивает, он должен удалить Child SA.

Поскольку применение AGGFRAG_PAYLOAD в настоящее время определено лишь для туннелей, не использующих транспортный режим, уведомления USE_AGGFRAG недопустимо сочетать в уведомлениями USE_TRANSPORT. Уведомление USE_AGGFRAG содержит 1 октет флагов, задающих требования от отправителя уведомления. Если получатель не знает или не поддерживает какой-либо из флагов, ему не следует разрешать использование AGGFRAG_PAYLOAD (не отвечая уведомлением USE_AGGFRAG или, в случае инициатора, удаляя Child SA, если использования вновь созданной SA без AGGFRAG_PAYLOAD неприемлемо).

Тип уведомления и значения флагов определены в параграфе 6.1.4. Уведомления IKEv2 USE_AGGFRAG.

6. Форматы пакетов и данных

Определённые ниже форматы данных и флагов являются базовыми и могут применяться не только с IP-TFS, но такое использование выходит за рамки этого документа.

6.1. Содержимое AGGFRAG_PAYLOAD

Содержимое AGGFRAG указывается значением AGGFRAG_PAYLOAD (144) в ESP Next Header, зарезервированным в пространстве номеров протоколов IP. Первый октет содержимого указывает формат остальных данных.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-
|   Sub-type    | ...
+-+-+-+-+-+-+-+-+-+-+-

Рисунок 3. Формат содержимого AGGFRAG_PAYLOAD.


Sub-type

8-битовое значение, указывающее формат содержимого.

Этот документ определяет два субтипа содержимого, описанных ниже.

6.1.1. Формат содержимого AGGFRAG_PAYLOAD без контроля перегрузок

Содержимое AGGFRAG_PAYLOAD без контроля перегрузок включает 4 октета заголовка, за которым следует переменной число DataBlocks data, как показано на рисунке 4.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-Type (0) |   Reserved    |          BlockOffset          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+-

Рисунок 4. Формат содержимого без контроля перегрузок.


Sub-type

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

Reserved

Устанавливается значение 0 при создании и игнорируется при получении.

BlockOffset

16-битовое целое число без знака, указывающее количество октетов данных DataBlocks до начала нового блока данных. Если новый блок данных начинается в последующем содержимом (payload), BlockOffset указывает конец данных DataBlocks. В этом случае все данные DataBlocks относятся к текущему собираемому блоку. Если BlockOffset распространяется в последующее содержимое, значение учитывает лишь данные DataBlocks (т. е. не считаются последующие пакеты данных, не являющиеся DataBlocks, такие как октеты заголовка).

DataBlocks

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

6.1.2. Формат содержимого AGGFRAG_PAYLOAD при контроле перегрузок

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-type (1) |  Reserved |P|E|          BlockOffset          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          LossEventRate                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      RTT                  |   Echo Delay ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ... Echo Delay   |           Transmit Delay                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              TVal                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             TEcho                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+-

Рисунок 5. Формат данных контроля перегрузок.


Содержимое AGGFRAG_PAYLOAD с контролем перегрузок включает 24 октета заголовка и переменное число блоков данных DataBlocks, как показано на рисунке 5.

Sub-type

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

Reserved

6-битовое поле, устанавливаемое в 0 при создании и игнорируемое при получении.

P

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

E

Флаг, указывающий, что биты ECN CE были получены и использованы для вывода сообщаемого LossEventRate.

BlockOffset

Такое же значение, как для формата без контроля перегрузок (см. параграф 6.1.1).

LossEventRate

32-битовое значение – 0 при отсутствии потерь, 1/LossEventRate в остальных случаях.

RTT

22-битовое значение, указывающее текущую оценку RTT отправителем (в микросекундах). Поле может иметь значение 0 до расчёта RTT отправителем. Для SA без поддержки AGGFRAG_PAYLOAD следует устанавливать 0. Если RTT не меньше 0x3FFFFF, должно устанавливаться значение 0x3FFFFF.

Echo Delay

21-битовое значение задержки между первым приёмом значения TVal получателем (в микросекундах) и отправкой его обратно в TEcho. Если задержка не меньше 0x1FFFFF, должно устанавливаться значение 0x1FFFFF.

Transmit Delay

21-битовое значение задержки передачи в микросекундах. Это фиксированная (или средняя) задержка между отправкой получателем пакетов в туннель IP-TFS. Если задержка не меньше 0x1FFFFF, должно устанавливаться значение 0x1FFFFF.

TVal

Неанализируемое (opaque) 32-битовое значение, возвращаемое получателем в поле TEcho последующих пакетов вместе со значением Echo Delay, указывающим время, занятое на возврат (echo).

TEcho

Неанализируемое 32-битовое значение из поля TVal в полученном пакете. Полученное значение TVal помещается в TEcho вместе со значением Echo Delay, указывающим время, прошедшее с момента получения TVal.

DataBlocks

Переменное число октетов с начала блока данных или продолжения предыдущего блока, за которыми могут следовать другие блоки данных. Для особого случая передачи данных контроля перегрузки в SA без поддержки IP-TFS это поле должно быть пустым (нулевой размер).

6.1.3. Блоки данных

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | IPv4, IPv6 или заполнение ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 6. Формат блока данных.


Type

4-битовое поле, указывающее тип блока данных – 0x0 Pad Data Block, 0x4 блок данных IPv4, 0x6 блок данных IPv6.
6.1.3.1. Блок данных IPv4
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  0x4  |  IHL  |  TypeOfService  |         TotalLength         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Остаток вложенного пакета ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 7. Формат блока данных IPv4.


Фактическое содержимое инкапсулированного заголовка IPv4, иными словами, начало этого блока является началом инкапсулированного пакета IP.

Type

4-битовое значение 0x4 указывает IPv4 (первый полубайт пакета IPv4).

TotalLength

16-битовое целое число без знака – поле Total Length вложенного пакета IPv4.
6.1.3.2. Блок данных IPv6
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  0x6  | TrafficClass  |               FlowLabel               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         PayloadLength         | Остаток вложенного пакета ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 8. Формат блока данных IPv6.


Фактическое содержимое инкапсулированного заголовка IPv6, иными словами, начало этого блока является началом инкапсулированного пакета IP.

Type

4-битовое значение 0x6 указывает IPv6 (первый полубайт пакета IPv6).

PayloadLength

16-битовое целое число без знака – поле Payload Length вложенного пакета IPv6.
6.1.3.3. Блок данных заполнения
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  0x0  | Заполнение ...
+-+-+-+-+-+-+-+-+-+-+-

Рисунок 9. Формат блока данных заполнения.


Type

4-битовое значение 0x0 указывает блок данных заполнения.

Padding

Финальная часть инкапсулирующего пакета.

6.1.4. Уведомления IKEv2 USE_AGGFRAG

Как указано в параграфе 5.1, уведомление USE_AGGFRAG служит для согласования использования значения поля ESP Next Header AGGFRAG_PAYLOAD.

USE_AGGFRAG Notification Message State Type имеет значение 16442.

Данные (payload) уведомления содержат 1 октет флагов требований. В настоящее время заданы 2 флага, но будущие спецификации могут добавить определения фланов.

+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|C|D|
+-+-+-+-+-+-+-+-+

Рисунок 10. Флаги требований USE_AGGFRAG.


0

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

C

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

D

Флаг запрета фрагментирования, установка которого указывает, что отправитель уведомления не поддерживает приём фрагментов (т. е. вложенный пакет должен передаваться в одном блоке данных). Это значение применяется лишь к тому, что отправитель может получить. Отправитель может продолжать отправку фрагментов, пока получатель не указал аналогичное ограничение в своём уведомлении USE_AGGFRAG.

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

7.1. Значение ESP Next Header

Агентство IANA включило номер протокола IP 144 в реестр Protocol Numbers – Assigned Internet Protocol Numbers.

   Decimal:  144
   Keyword:  AGGFRAG
   Protocol:  AGGFRAG encapsulation payload for ESP
   Reference:  RFC 9347

7.2. Субтипы AGGFRAG_PAYLOAD

Агентство IANA создало реестр AGGFRAG_PAYLOAD Sub-Types в новой категории ESP AGGFRAG_PAYLOAD с политикой регистрации Expert Review [RFC8126] [RFC7120].

   Name:  AGGFRAG_PAYLOAD Sub-Types
   Description:  AGGFRAG_PAYLOAD Payload Formats
   Reference:  RFC 9347

Исходное содержимое реестра приведено в таблице 1.

Таблица 1. Субтипы AGGFRAG_PAYLOAD.

 

Субтип

Имя

Документ

0

Формат без контроля перегрузок

RFC 9347

1

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

RFC 9347

3-255

Резерв

 

7.3. Тип уведомлений о статусе USE_AGGFRAG

Агентство IANA включило тип статуса USE_AGGFRAG в реестр IKEv2 Notify Message Types – Status Types.

   Decimal:  16442
   Name:  USE_AGGFRAG
   Reference:  RFC 9347

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

Этот документ описывает механизмы агрегирования и фрагментирования с целью эффективной реализации TFC для трафика IP. Предполагается, что этот подход осложнит анализ трафика IPsec. В дополнение к обеспечиваемой этим механизмом защите IP-TFS применяет протоколы защиты [RFC4303] [RFC7296], поэтому соображения безопасности для них применимы и к IP-TFS.

Как отмечено в параграфе 3.1, биты ECN не защищены в IPsec и позволяют организовать скрытый канал. По этой причине применение ECN не следует включать по умолчанию.

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

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, “Internet Key Exchange Protocol Version 2 (IKEv2)”, STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

[AppCrypt] Schneier, B., “Applied Cryptography: Protocols, Algorithms, and Source Code in C”, 1996.

[RFC0791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2914] Floyd, S., “Congestion Control Principles”, BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4342] Floyd, S., Kohler, E., and J. Padhye, “Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)”, RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC6040] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, “Encapsulating MPLS in UDP”, RFC 7510, DOI 10.17487/RFC7510, April 2015, <https://www.rfc-editor.org/info/rfc7510>.

[RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, “Pseudowire Congestion Considerations”, RFC 7893, DOI 10.17487/RFC7893, June 2016, <https://www.rfc-editor.org/info/rfc7893>.

[RFC8084] Fairhurst, G., “Network Transport Circuit Breakers”, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., “Path MTU Discovery for IP version 6”, STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8546] Trammell, B. and M. Kuehlewind, “The Wire Image of a Network Protocol”, RFC 8546, DOI 10.17487/RFC8546, April 2019, <https://www.rfc-editor.org/info/rfc8546>.

[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, “Packetization Layer Path MTU Discovery for Datagram Transports”, RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.

[RFC9329] Pauly, T. and V. Smyslov, “TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets”, RFC 9329, DOI 10.17487/RFC9329, November 2022, <https://www.rfc-editor.org/info/rfc9329>.

[RFC9348] Fedyk, D. and C. Hopps, “A YANG Data Model for IP Traffic Flow Security”, RFC 9348, DOI 10.17487/RFC9348, January 2023, <https://www.rfc-editor.org/info/rfc9348>.

[RFC9349] Fedyk, D. and E. Kinzie, “Definitions of Managed Objects for IP Traffic Flow Security”, RFC 9349, DOI 10.17487/RFC9349, January 2023, <https://www.rfc-editor.org/info/rfc9349>.

Приложение A. Пример потока инкапсулированных пакетов IP

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

 Offset: 0        Offset: 100    Offset: 2000    Offset: 600
[ ESP1  (1404) ][ ESP2  (1404) ][ ESP3  (1404) ][ ESP4  (1404) ]
[--750--][--750--][60][-240-][--3000----------------------][pad]

Рисунок 11. Потоки вложенных и внешних пакетов.


Каждое инкапсулирующее пространство ESP имеет фиксированный размер 1404 октета, из которых первые 4 занимает заголовок AGGFRAG. Поток инкапсулируемых пакетов IP (размер включает заголовок IP и данные) включает 2 пакета по 750 октетов, пакет в 60 октетов, пакет в 240 октетов и пакет в 3000 октетов.

BlockOffset в 4 заголовках содержимого AGGFRAG для этого потока пакетов имеют значения 0, 100, 2000 и 600, соответственно. Первый инкапсулирующий пакет (ESP1) имеет значение BlockOffset = 0, указывающее блок данных IP, следующий сразу после заголовка AGGFRAG. В следующем пакете (ESP2) BlockOffset указывает 100 внутрь к началу 60-октетного блока данных. Третий инкапсулирующий пакет (ESP3) содержит среднюю часть 3000-октетного блока данных, поэтому смещение указывает его конец в четвёртом инкапсулирующем пакете (ESP4), где смещение 600 указывает заполнение после завершения 3000-октетного пакета.

Приложение B. Передача и расчёт частоты потерь

Текущий опыт показывает, что контроль перегрузок следует выполнять дружественным к TCP способом. Такой алгоритм описан в [RFC5348]. Для этого варианта применения IP-TFS (как в [RFC4342]) (фиксированный) размер пакетов применяется как размер сегмента для алгоритма. Основная формула расчёта скорости передачи в алгоритме имеет вид

      X = 1 / (R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2)))

X – скорость передачи (пакет/сек), R – оценка RTT, p – частота потерь (обратное ей значение указывает получатель).

Кроме того, алгоритм [RFC5348] использует также значение X_recv (скорость приёма получателем). Для IP-TFS можно установить это значение в соответствии с текущей скоростью передачи туннельного отправителя (X).

Получатель IP-TFS, имеющий оценку RTT от отправителя, может применять описанный в [RFC5348] и [RFC4342] метод для сбора интервалов потерь и расчёта частоты потерь с использованием средневзвешенного значения, как указано. Получатель сообщает обратное этой частоте значение отправителю в поле LossEventRate заголовка содержимого AGGFRAG_PAYLOAD. У отправителя IP-TFS теперь имеются значения R и p, позволяющие корректно рассчитать скорость передачи. В соответствии с [RFC5348] отправителю также следует использовать механизм замедленного старта, при организации IP-TFS SA.

Приложение C. Сравнения для IP-TFS

C.1. Сравнение издержек

Для сравнения издержек нужно рассчитать издержки ESP для обычных туннельных пакетов и пакетов AGGFRAG, поэтому нужно выбрать алгоритм шифрования и аутентификации. В этом примере используется алгоритм AES-GCM-256, что ведёт к издержкам IP+ESP в 54 октета.

     54 = 20 (IP) + 8 (ESPH) + 2 (ESPF) + 8 (IV) + 16 (ICV)

Для IP-TFS были выбраны заголовки AGGFRAG_PAYLOAD без контроля перегрузок, добавляющие 4 октета, что даёт суммарные издержки в 58 октетов.

C.1.1. Издержки IP-TFS

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

      OH = 58 / Размер внешних данных (Payload) / Размер вложенного пакета
      OH % от размера вложенного пакета = 100 * OH / Размер вложенного пакета
      OH % от размера вложенного пакета = 5800 / Размер внешнего пакета

Таблица 2. Издержки IP-TFS в процентах от размера вложенного пакета.

 

Тип

IP-TFS

IP-TFS

IP-TFS

MTU

576

1500

9000

PSize

518

1442

8942

40

11,20%

4,02%

0,65%

576

11,20%

4,02%

0,65%

1500

11,20%

4,02%

0,65%

9000

11,20%

4,02%

0,65%

 

C.1.2. Издержки ESP с заполнением

Издержки в расчёте на вложенный пакет для ESP с постоянной скоростью и заполнением (исходный IPsec TFC) составляют 36 октетов плюс заполнение, пока не требуется фрагментация.

Если нужна фрагментация вложенных пакетов для размещения во внешнем пакете IPsec, издержки составляют число внешних пакетов, требуемых для передачи фрагментированного вложенного пакета, умноженное на сумму внутренних издержек IP (20) и издержек внешнего пакета (54), за вычетом внутренних издержек IP, с добавлением заполнения в конце последнего пакета инкапсуляции. Размер заполнения – это число требуемых пакетов, умноженное на разность размера внешних данных (Outer Payload Size) и издержек IP, за вычетом размера вложенных данных (Inner Payload Size). Таким образом,

   Размер вложенных данных = Размер пакета IP - Издержки IP
   Размер внешних данных = MTU - Издержки IPsec

   NF0 = Размер вложенных данных / (Размер внешних данных — Издержки IP)

   NF = CEILING(NF0)

   OH = NF * (Издержки IP + Издержки IPsec) - Издержки IP
        + NF * (Размер внешних данных - Издержки IP)
        - Размер вложенных данных

   OH = NF * (Издержки IPsec + Размер внешних данных)
        - (Издержки IP + Размер вложенных данных)

   OH = NF * (Издержки IPsec + Размер внешних данных)
        - Размер вложенного пакета

C.2. Сравнение издержек

Ниже приведены значения издержек для некоторых общепринятых значений L3 MTU с целью сравнения. Таблица 3 указывает число добавленных октетов для данного размера пакетов L3 MTU. В таблице 4 приведены издержки в процентах для тех же пакетов размера MTU.

Таблица 3. Сравнение издержек в октетах.

 

Тип

ESP+Pad

ESP+Pad

ESP+Pad

IP-TFS

IP-TFS

IP-TFS

L3 MTU

576

1500

9000

576

1500

9000

PSize

522

1446

8946

518

1442

8942

40

482

1406

8906

4,5

1,6

0,3

128

394

1318

8818

14,3

5,1

0,8

256

266

1190

8690

28,7

10,3

1,7

518

4

928

8428

58,0

20,8

3,4

576

576

870

8370

64,5

23,2

3,7

1442

286

4

7504

161,5

58,0

9,4

1500

228

1500

7446

168,0

60,3

9,7

8942

1426

1558

4

1001,2

359,7

58,0

9000

1368

1500

9000

1007,7

362,0

58,4

 

Таблица 4. Сравнение издержек в % от размера вложенных пакетов.

 

Тип

ESP+Pad

ESP+Pad

ESP+Pad

IP-TFS

IP-TFS

IP-TFS

MTU

576

1500

9000

576

1500

9000

PSize

522

1446

8946

518

1442

8942

40

1205,0%

3515,0%

22265,0%

11,20%

4,02%

0,65%

128

307,8%

1029,7%

6889,1%

11,20%

4,02%

0,65%

256

103,9%

464,8%

3394,5%

11,20%

4,02%

0,65%

518

0,8%

179,2%

1627,0%

11,20%

4,02%

0,65%

576

100,0%

151,0%

1453,1%

11,20%

4,02%

0,65%

1442

19,8%

0,3%

520,4%

11,20%

4,02%

0,65%

1500

15,2%

100,0%

496,4%

11,20%

4,02%

0,65%

8942

15,9%

17,4%

0,0%

11,20%

4,02%

0,65%

9000

15,2%

16,7%

100,0%

11,20%

4,02%

0,65%

 

C.3. Сравнение доступной пропускной способности

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

C.3.1. Ethernet

Для расчёте доступной пропускной способности сначала вычисляются задержки в расчёте на пакет. Суммарные издержки Ethernet включают 14+4 октета заголовка и контрольной суммы (Cyclic Redundancy Check или CRC), а также 20 октетов кадрирования (преамбула, начало пакета и межпакетный интервал), что даёт 38 октетов. Минимальный размер содержимого (payload) составляет 46 октетов.

Таблица 5. Число октетов L2 на пакет.

 

Размер

E + P

E + P

E + P

IPTFS

IPTFS

IPTFS

Enet

ESP

MTU

590

1514

9014

590

1514

9014

любое

любое

OH

92

92

92

96

96

96

38

74

40

614

1538

9038

47

42

40

84

114

128

614

1538

9038

151

136

129

166

202

256

614

1538

9038

303

273

258

294

330

518

614

1538

9038

614

552

523

574

610

576

1228

1538

9038

682

614

582

614

650

1442

1842

1538

9038

1709

1538

1457

1498

1534

1500

1842

3076

9038

1777

1599

1516

1538

1574

8942

11052

10766

9038

10599

9537

9038

8998

9034

9000

11052

10766

18076

10667

9599

9096

9038

9074

 

Таблица 6. Число октетов для 10G Ethernet.

 

Размер

E + P

E + P

E + P

IP-TFS

IP-TFS

IP-TFS

Enet

ESP

MTU

590

1514

9014

590

1514

9014

любое

любое

OH

92

92

92

96

96

96

38

74

40

2,0M

0,8M

0,1M

26,4M

29,3M

30,9M

14,9M

11,0M

128

2,0M

0,8M

0,1M

8,2M

9,2M

9,7M

7,5M

6,2M

256

2,0M

0,8M

0,1M

4,1M

4,6M

4,8M

4,3M

3,8M

518

2,0M

0,8M

0,1M

2,0M

2,3M

2,4M

2,2M

2,1M

576

1,0M

0,8M

0,1M

1,8M

2,0M

2,1M

2,0M

1,9M

1442

678K

812K

138K

731K

812K

857K

844K

824K

1500

678K

406K

138K

703K

781K

824K

812K

794K

8942

113K

116K

138K

117K

131K

138K

139K

138K

9000

113K

116K

69K

117K

130K

137K

138K

137K

 

Таблица 7. Доля пропускной способности для 10G Ethernet.

 

Размер

E + P

E + P

E + P

IP-TFS

IP-TFS

IP-TFS

Enet

ESP

MTU

590

1514

9014

590

1514

9014

любое

любое

OH

92

92

92

96

96

96

38

74

40

6,51%

2,60%

0,44%

84,36%

93,76%

98,94%

47,62%

35,09%

128

20,85%

8,32%

1,42%

84,36%

93,76%

98,94%

77,11%

63,37%

256

41,69%

16,64%

2,83%

84,36%

93,76%

98,94%

87,07%

77,58%

518

84,36%

33,68%

5,73%

84,36%

93,76%

98,94%

93,17%

87,50%

576

46,91%

37,45%

6,37%

84,36%

93,76%

98,94%

93,81%

88,62%

1442

78,28%

93,76%

15,95%

84,36%

93,76%

98,94%

97,43%

95,12%

1500

81,43%

48,76%

16,60%

84,36%

93,76%

98,94%

97,53%

95,30%

8942

80,91%

83,06%

98,94%

84,36%

93,76%

98,94%

99,58%

99,18%

9000

81,43%

83,60%

49,79%

84,36%

93,76%

98,94%

99,58%

99,18%

 

Неожиданным результатом применения туннеля AGGFRAG (или иного туннеля с агрегированием пакетов) является то, что для мелких и средних пакетов доступная пропускная способность фактически больше, чем в обычном Ethernet. Это обусловлено сокращением издержек на кадрирование Ethernet. Платой за такую экономию полосу является рост задержек. Задержка связана определяется временем передачи несвязанных октетов во внешнем заголовке туннельного кадра. В таблице 8 показана задержка для некоторых размеров пакета на канале 10G Ethernet, а также задержка, вносимая заполнением при использовании ESP с заполнением.

Таблица 8. Добавленная задержка.

 

Размер

ESP+Pad

ESP+Pad

IP-TFS

IP-TFS

MTU

1500

9000

1500

9000

40

1.12 мксек

7.12 мксек

1.17 мксек

7.17 мксек

128

1.05 мксек

7.05 мксек

1.10 мксек

7.10 мксек

256

0.95 мксек

6.95 мксек

1.00 мксек

7.00 мксек

518

0.74 мксек

6.74 мксек

0.79 мксек

6.79 мксек

576

0.70 мксек

6.70 мксек

0.74 мксек

6.74 мксек

1442

0.00 мксек

6.00 мксек

0.05 мксек

6.05 мксек

1500

1.20 мксек

5.96 мксек

0.00 мксек

6.00 мксек

 

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

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

Спасибо Don Fedyk за помощь в рецензировании и редактировании этой работы. Спасибо Michael Richardson, Sean Turner, Valery Smyslov, Tero Kivinen за рецензии и многочисленные предложения по улучшению, а также Joseph Touch за рецензию (transport area) и предложения по улучшению.

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

Ниже указан человек, внёсший существенный вклад в этот документ.

Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net

Адрес автора

Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Packetization Layer MTU Discovery – определение MTU для уровня пакетизации.

4Path MTU Discovery – определение MTU для пути.

Рубрика: RFC, Безопасность | Оставить комментарий

RFC 9129 YANG Data Model for the OSPF Protocol

Internet Engineering Task Force (IETF)                          D. Yeung
Request for Comments: 9129                                  Arrcus, Inc.
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                                Futurewei
                                                                J. Zhang
                                                        Juniper Networks
                                                                 I. Chen
                                                   The MITRE Corporation
                                                               A. Lindem
                                                           Cisco Systems
                                                            October 2022

YANG Data Model for the OSPF Protocol

Модель данных YANG для протокола OSPF

PDF

Аннотация

Этот документ задаёт модель данных YANG, которая может служить для настройки и управления OSPF. Модель основана на версии YANG 1.1, определённой в RFC 7950, и соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA), описанной в RFC 8342.

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

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

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

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

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

Copyright (c) 2022. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

YANG [RFC7950] – язык определения данных, служащий для задания содержимого концептуального хранилища данных, позволяющего управлять сетевыми устройствами по протоколу настройки сети (Network Configuration Protocol или NETCONF) [RFC6241], RESTCONF [RFC8040] или иному протоколу управления сетью. Кроме того, модели данных YANG могут служить основой для реализации других интерфейсов, таких как консольный (Command-Line Interface или CLI) и программный API.

Этот документ определяет модель данных YANG, которая может служить для настройки и управления OSPF. Он дополняет модель данных ядра маршрутизации, заданную в [RFC8349], и предоставляет основу для разработки моделей данных протоколов маршрутизации. Модель полностью соответствует архитектуре NMDA [RFC8342]. Модель данных интерфейса определена в [RFC8343] и применяется для ссылки на интерфейсы из протоколов маршрутизации. Модель данных для цепочек ключей [RFC8177] применяется для аутентификации OSPF и обеспечивает ссылки на настроенные цепочки ключей и криптографические алгоритмы.

Поддерживаются оба протокола OSPFv2 [RFC2328] и OSPFv3 [RFC5340]. В дополнение к протоколу ядра OSPF поддерживаются функции из других RFC, связанных с OSPF. Это включает устройства запроса [RFC1793], организацию трафика (Traffic Engineering или TE) [RFC3630], разные семейства адресов [RFC5838], аккуратный перезапуск [RFC3623] [RFC5187], опцию NSSA (Not-So-Stubby Area) [RFC3101] и OSPFv2 или OSPFv3 в качестве протокола между провайдером и клиентом (Provider Edge to Customer Edge или PE-CE) [RFC4577] [RFC6565]. Не входящие в ядро функции в модели OSPF являются необязательными.

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

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

1.2. Диаграммы деревьев

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Устройство модели данных

Хотя базовые элементы конфигурации OSPF (маршрутизаторы, области, интерфейсы) не меняются, детали модели конфигурации зависят от производителя. Различия наблюдаются в разных аспектах, включая привязку экземпляра протокола к домену маршрутизации и создание экземпляров протокола. Цель этого документа состоит в определении модели данных, обеспечивающей пользовательский интерфейс для OSPFv2 и OSPFv3. Обязательных элементов (mandatory) очень немного, что даёт производителям возможность приспособить эту модель данных к своим реализациям.

2.1. Рабочее состояние OSPF

Рабочее состояние OSPF включено в одно дерево с конфигурацией OSPF в соответствии с архитектурой NMDA [RFC8342] и дополняется лишь контейнер routing из ietf-routing [RFC8349], а контейнер routing-state не меняется.

2.2. Обзор

Модуль YANG OSPF, заданный в этом документе, включает все базовые блоки, нужные для протокола OSPF. Модуль дополняет путь /routing/control-plane-protocols/control-plane-protocol, заданный в модуле ietf-routing. Модель ietf-ospf задаёт один экземпляр OSPF, который может быть создан как OSPFv2 или OSPFv3. Несколько экземпляров создаются как экземпляры протоколов плоскости управления.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
             .
             .
          +--rw address-family?       iana-rt-types:address-family
             .
             .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |        .
          |        .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     .
          |     |     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     .
          |     |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           .
          |           .
          +--rw topologies {multi-topology}?
             +--rw topology* [name]
                .
                .

Контейнер ospf включает один экземпляр протокола OSPF, содержащий данные конфигурации и состояния на уровне маршрутизатора OSPF. Каждый экземпляр OSPF сопоставляется с экземпляром протокола плоскости управления в соответствии с [RFC8349].

Контейнеры areas и area/interfaces определяют конфигурацию и рабочее состояние областей и интерфейсов OSPF.

Контейнер topologies определяет конфигурацию и рабочее состояние OSPF для топологий OSPF при поддержке функции (feature) multi-topology.

2.3. OSPFv2 и OSPFv3

Определённая здесь модель данных поддерживает протоколы OSPFv2 и OSPFv3. Обязательное поле version указывает применяемую версию OSPF и в соответствии с этим модель данных использует OSPFv2 или OSPFv3.

2.4. Необязательные функции

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

multi-topology

Поддержка маршрутизации MT Multi-Topology) [RFC4915].

multi-area-adj

Поддержка смежности нескольких областей OSPF [RFC5185].

explicit-router-id

Поддержка явного задания Router ID на уровне экземпляра.

demand-circuit

Поддержа устройств, запрашивающих OSPF [RFC1793].

mtu-ignore

Поддержка запрета проверки MTU пакета OSPF Database Description в соответствии с параграфом 10.6 в [RFC2328].

lls

Поддержка сигнализации LLS (OSPF Link-Local Signaling) [RFC5613].

prefix-suppression

Поддержка подавления анонсов префиксов OSPF [RFC6860].

ttl-security

Поддержка проверки безопасности для OSPF TTL (Time to Live) [RFC5082].

nsr

Поддержка OSPF NSR (Non-Stop Routing), позволяющей маршрутизатору с избыточностью плоскости управления (например, платы с двумя процессорами маршрутов – Route Processor или RP)) поддерживать своё состояние и отношения смежности при плановом или неплановом перезапуске плоскости управления. Это отличается от безостановочной пересылки (Non-Stop Forwarding или NSF) тем, что не требует содействия соседей OSPF для восстановления состояния плоскости управления.

graceful-restart

Поддержка аккуратного (graceful) перезапуска OSPF [RFC3623] [RFC5187].

auto-cost

Поддержка расчёта стоимости для интерфейса OSPF по эталонной пропускной способности [RFC2328].

max-ecmp

Поддержка настройки максимального числа равноценных путей (Equal-Cost Multi-Path или ECMP).

max-lsa

Поддержка настройки максимального числа анонсов состояния канала (Link State Advertisement или LSA), воспринимаемых экземпляром OSPF [RFC1765].

te-rid

Поддержка настройки TE Router ID, т е. Router Address TLV, как указано в параграфе 2.4.1 [RFC3630], или Router IPv6 Address TLV, как указано в разделе 3 [RFC5329].

ldp-igp-sync

Поддержка синхронизации LDP IGP [RFC5443].

ospfv2-authentication-trailer

Поддержка трейлера аутентификации OSPFv2 [RFC5709] [RFC7474].

ospfv3-authentication-ipsec

Поддержка IPsec для аутентификации OSPFv3 [RFC4552].

ospfv3-authentication-trailer

Поддержка трейлера аутентификации OSPFv3 [RFC7166].

fast-reroute

Поддержка IP Fast Reroute (IP-FRR) [RFC5714].

node-flag

Поддержка флагов узла для префиксов for OSPF [RFC7684].

node-tag

Поддержка административных флагов узла для экземпляров OSPF [RFC7777].

lfa

Поддержка беспетлевых вариантов (Loop-Free Alternate или LFA) [RFC5286].

remote-lfa

Поддержка удалённых LFA (Remote LFA или R-LFA) [RFC7490].

stub-router

Поддержка анонсов тупиковых маршрутизаторов OSPF [RFC6987].

pe-ce-protocol

Поддержка OSPF в качестве протокола PE-CE [RFC4577] [RFC6565].

ietf-spf-delay

Поддержка алгоритма задержки IETF Shortest Path First (SPF) [RFC8405].

bfd

Поддержка обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD) для нахождения соседей OSPF [RFC5880] [RFC5881].

hybrid-interface

Поддержка гибридных интерфейсов OSPF (broadcast и point-to-multipoint) [RFC6845].

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

2.5. Конфигурация и рабочее состояние маршрутизатора OSPF

Контейнер ospf размещается на верхнем уровне модели и представляет экземпляр протокола OSPF с конфигурацией и рабочим состоянием на уровне маршрутизатора. Рабочее состояние включает статистику экземпляра, статистику задержки IETF SPF, базу данных LSDB (AS-Scope Link State Database), локальную таблицу RIB, журналы SPF и LSA.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw address-family?       iana-rt-types:address-family
          +--rw enabled?              boolean
          +--rw explicit-router-id?   rt-types:router-id
          |                           {explicit-router-id}?
          +--rw preference
          |  +--rw (scope)?
          |     +--:(single-value)
          |     |  +--rw all?          uint8
          |     +--:(multi-values)
          |        +--rw (granularity)?
          |        |  +--:(detail)
          |        |  |  +--rw intra-area?   uint8
          |        |  |  +--rw inter-area?   uint8
          |        |  +--:(coarse)
          |        |     +--rw internal?     uint8
          |        +--rw external?     uint8
          +--rw nsr {nsr}?
          |  +--rw enabled?  boolean
          +--rw graceful-restart {graceful-restart}?
          |  +--rw enabled?                      boolean
          |  +--rw helper-enabled?               boolean
          |  +--rw restart-interval?             uint16
          |  +--rw helper-strict-lsa-checking?   boolean
          +--rw auto-cost {auto-cost}?
          |  +--rw enabled?               boolean
          |  +--rw reference-bandwidth?   uint32
          +--rw spf-control
          |  +--rw paths?            uint16 {max-ecmp}?
          |  +--rw ietf-spf-delay {ietf-spf-delay}?
          |     +--rw initial-delay?   uint32
          |     +--rw short-delay?     uint32
          |     +--rw long-delay?      uint32
          |     +--rw hold-down?       uint32
          |     +--rw time-to-learn?   uint32
          |     +--ro current-state?             enumeration
          |     +--ro remaining-time-to-learn?
          |                   rt-types:timer-value-milliseconds
          |     +--ro remaining-hold-down?
          |                   rt-types:timer-value-milliseconds
          |     +--ro last-event-received?       yang:timestamp
          |     +--ro next-spf-time?             yang:timestamp
          |     +--ro last-spf-time?             yang:timestamp
          +--rw database-control
          |  +--rw max-lsa?   uint32 {max-lsa}?
          +--rw stub-router {stub-router}?
          |  +--rw (trigger)?
          |     +--:(always)
          |        +--rw always!
          +--rw mpls
          |  +--rw te-rid {te-rid}?
          |  |  +--rw ipv4-router-id?   inet:ipv4-address
          |  |  +--rw ipv6-router-id?   inet:ipv6-address
          |  +--rw ldp
          |     +--rw igp-sync?   boolean {ldp-igp-sync}?
          +--rw fast-reroute {fast-reroute}?
          |  +--rw lfa {lfa}?
          +--rw node-tags {node-tag}?
          |  +--rw node-tag* [tag]
          |     +--rw tag      uint32
          +--ro router-id?          rt-types:router-id
          +--ro local-rib
          |  +--ro route* [prefix]
          |     +--ro prefix        inet:ip-prefix
          |     +--ro next-hops
          |     |  +--ro next-hop* []
          |     |     +--ro outgoing-interface?   if:interface-ref
          |     |     +--ro next-hop              inet:ip-address
          |     +--ro metric?       uint32
          |     +--ro route-type?   route-type
          |     +--ro route-tag?    uint32
          +--ro statistics
          |  +--ro discontinuity-time         yang:date-and-time
          |  +--ro originate-new-lsa-count?   yang:counter32
          |  +--ro rx-new-lsas-count?         yang:counter32
          |  +--ro as-scope-lsa-count?        yang:gauge32
          |  +--ro as-scope-lsa-chksum-sum?   uint32
          |  +--ro database
          |  |  +--ro as-scope-lsa-type*
          |  |     +--ro lsa-type?        uint16
          |  |     +--ro lsa-count?       yang:gauge32
          |  |     +--ro lsa-cksum-sum?   uint32
          |  +--ro protected-routes {fast-reroute}?
          |  |  +--ro address-family-stats*
          |  |         [address-family prefix alternate]
          |  |     +--ro address-family
          |  |         iana-rt-types:address-family
          |  |     +--ro prefix                  inet:ip-prefix
          |  |     +--ro alternate               inet:ip-address
          |  |     +--ro alternate-type?         enumeration
          |  |     +--ro best?                   boolean
          |  |     +--ro non-best-reason?        string
          |  |     +--ro protection-available?   bits
          |  |     +--ro alternate-metric-1?     uint32
          |  |     +--ro alternate-metric-2?     uint32
          |  |     +--ro alternate-metric-3?     uint32
          |  +--ro unprotected-routes {fast-reroute}?
          |  |  +--ro address-family-stats* [address-family prefix]
          |  |     +--ro address-family    iana-rt-types:address-family
          |  |     +--ro prefix            inet:ip-prefix
          |  +--ro protection-statistics* [frr-protection-method]
          |     +--ro frr-protection-method    string
          |     +--ro address-family-stats* [address-family]
          |        +--ro address-family
          |             iana-rt-types:address-family
          |        +--ro total-routes?           uint32
          |        +--ro unprotected-routes?     uint32
          |        +--ro protected-routes?       uint32
          |        +--ro linkprotected-routes?   uint32
          |        +--ro nodeprotected-routes?   uint32
          +--ro database
          |  +--ro as-scope-lsa-type* [lsa-type]
          |     +--ro as-scope-lsas
          |        +--ro as-scope-lsa* [lsa-id adv-router]
          |           +--ro lsa-id               union
          |           +--ro adv-router           inet:ipv4-address
          |           +--ro decoded-completed?   boolean
          |           +--ro raw-data?            yang:hex-string
          |           +--ro (version)?
          |              +--:(ospfv2)
          |              |  +--ro ospfv2
          .              .
          .              .
          |              +--:(ospfv3)
          |                 +--ro ospfv3
          .
          .
          +--ro spf-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro spf-type?             enumeration
          |     +--ro schedule-timestamp?   yang:timestamp
          |     +--ro start-timestamp?      yang:timestamp
          |     +--ro end-timestamp?        yang:timestamp
          |     +--ro trigger-lsa*
          |        +--ro area-id?      area-id-type
          |        +--ro type?         uint16
          |        +--ro lsa-id?       union
          |        +--ro adv-router?   rt-types:router-id
          |        +--ro seq-num?      uint32
          +--ro lsa-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro lsa
          |     |  +--ro area-id?      area-id-type
          |     |  +--ro type?         uint16
          |     |  +--ro lsa-id?       union
          |     |  +--ro adv-router?   rt-types:router-id
          |     |  +--ro seq-num?      uint32
          |     +--ro received-timestamp?   yang:timestamp
          |     +--ro reason?               identityref
          .
          .

2.6. Конфигурация и рабочее состояние области OSPF

Контейнер area содержит конфигурацию области OSPF и список контейнеров для всех интерфейсов OSPF в эту область. Рабочее состояние области включает статистику и LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |     +--rw area-type?                identityref
          |     +--rw summary?                  boolean
          |     +--rw default-cost?             ospf-metric
          |     +--rw ranges
          |     |  +--rw range* [prefix]
          |     |     +--rw prefix       inet:ip-prefix
          |     |     +--rw advertise?   boolean
          |     |     +--rw cost?        ospf-metric
          |     +--rw topologies {ospf:multi-topology}?
          |     |  +--rw topology* [name]
          |     |     +--rw name  -> ../../../../../../../../
          |     |                    ../../../rt:ribs/rib/name
          |     |     +--rw summary?        boolean
          |     |     +--rw default-cost?   ospf-metric
          |     |     +--rw ranges
          |     |         +--rw range* [prefix]
          |     |            +--rw prefix       inet:ip-prefix
          |     |            +--rw advertise?   boolean
          |     |            +--rw cost?        ospf-metric
          |     +--ro statistics
          |     |  +--ro discontinuity-time           yang:date-and-time
          |     |  +--ro spf-runs-count?              yang:counter32
          |     |  +--ro abr-count?                   yang:gauge32
          |     |  +--ro asbr-count?                  yang:gauge32
          |     |  +--ro ar-nssa-translator-event-count?
          |     |                                     yang:counter32
          |     |  +--ro area-scope-lsa-count?        yang:gauge32
          |     |  +--ro area-scope-lsa-cksum-sum?    uint32
          |     |  +--ro database
          |     |     +--ro area-scope-lsa-type*
          |     |        +--ro lsa-type?        uint16
          |     |        +--ro lsa-count?       yang:gauge32
          |     |        +--ro lsa-cksum-sum?   uint32
          |     +--ro database
          |     |  +--ro area-scope-lsa-type* [lsa-type]
          |     |     +--ro lsa-type           uint16
          |     |     +--ro area-scope-lsas
          |     |        +--ro area-scope-lsa* [lsa-id adv-router]
          |     |           +--ro lsa-id               union
          .     .           .
          .     .           .
          |     |           +--ro (version)?
          |     |              +--:(ospfv2)
          |     |              |  +--ro ospfv2
          |     |              |     +--ro header
          .     .              .     .
          .     .              .     .
          |     |              |     +--ro body
          |     |              |        +--ro router
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro network
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro summary
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro external
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro opaque
          .     .              .        .
          .     .              .        .
          |     |              +--:(ospfv3)
          |     |                 +--ro ospfv3
          |     |                    +--ro header
          .     .                    .
          .     .                    .
          |     |                    +--ro body
          |     |                       +--ro router
          .     .                       .
          .     .                       .
          |     |                       +--ro network
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-router
          .     .                       .
          .     .                       .
          |     |                       +--ro as-external
          .     .                       .
          .     .                       .
          |     |                       +--ro nssa
          .     .                       .
          .     .                       .
          |     |                       +--ro link
          .     .                       .
          .     .                       .
          |     |                       +--ro intra-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro router-information
          .     .                       .
          .     .                       .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     +--rw transit-area-id       -> ../../../../
          |     |                                    area/area-id
          |     |     +--rw router-id             rt-types:router-id
          |     |     +--rw hello-interval?       uint16
          |     |     +--rw dead-interval?        uint32
          |     |     +--rw retransmit-interval?  uint16
          |     |     +--rw transmit-delay?       uint16
          |     |     +--rw lls?                  boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?              boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--ro cost?              ospf-link-metric
          |     |     +--ro state?             if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?      rt-types:router-id
          |     |     +--ro dr-ip-addr?        inet:ip-address
          |     |     +--ro bdr-router-id?     rt-types:router-id
          |     |     +--ro bdr-ip-addr?       inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   int32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     +--rw local-id               inet:ip-address
          |     |     +--rw remote-id              inet:ip-address
          |     |     +--rw hello-interval?        uint16
          |     |     +--rw dead-interval?         uint32
          |     |     +--rw retransmit-interval?   uint16
          |     |     +--rw transmit-delay?        uint16
          |     |     +--rw lls?                   boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?            boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--rw cost?               ospf-link-metric
          |     |     +--rw mtu-ignore?         boolean
          |     |                               {mtu-ignore}?
          |     |     +--rw prefix-suppression? boolean
          |     |                               {prefix-suppression}?
          |     |     +--ro state?              if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?       rt-types:router-id
          |     |     +--ro dr-ip-addr?         inet:ip-address
          |     |     +--ro bdr-router-id?      rt-types:router-id
          |     |     +--ro bdr-ip-addr?        inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   uint32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro cost?           ospf-link-metric
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time?
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .

2.7. Конфигурация и рабочее состояние интерфейса OSPF

Контейнер interface содержит конфигурацию и рабочее состояние интерфейса OSPF. Рабочее состояние интерфейса включает статистику интерфейса, список соседей и link-local LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     .
          |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           +--rw name                   if:interface-ref
          |           +--rw interface-type?        enumeration
          |           +--rw passive?               boolean
          |           +--rw demand-circuit?        boolean
          |                                        {demand-circuit}?
          |           +--rw priority?              uint8
          |           +--rw multi-areas {multi-area-adj}?
          |           |  +--rw multi-area* [multi-area-id]
          |           |     +--rw multi-area-id      area-id-type
          |           |     +--rw cost?              ospf-link-metric
          |           +--rw static-neighbors
          |           |  +--rw neighbor* [identifier]
          |           |     +--rw identifier       inet:ip-address
          |           |     +--rw cost?            ospf-link-metric
          |           |     +--rw poll-interval?   uint16
          |           |     +--rw priority?        uint8
          |           +--rw node-flag?             boolean
          |                                        {node-flag}?
          |           +--rw bfd {bfd}?
          |           |  +--rw enabled?            boolean
          |           |  +--rw local-multiplier?   multiplier
          |           |  |      {client-base-cfg-parms}?
          |           |  +--rw (interval-config-type)?
          |           |  |      {client-base-cfg-parms}?
          |           |     +--:(tx-rx-intervals)
          |           |     |  +--rw desired-min-tx-interval?  uint32
          |           |     |  +--rw required-min-rx-interval? uint32
          |           |     +--:(single-interval)
          |           |     |   {single-minimum-interval}?
          |           |        +--rw min-interval?             uint32
          |           +--rw fast-reroute {fast-reroute}?
          |           |  +--rw lfa {lfa}?
          |           |     +--rw candidate-enabled?  boolean
          |           |     +--rw enabled?            boolean
          |           |     +--rw remote-lfa {remote-lfa}?
          |           |        +--rw enabled?  boolean
          |           +--rw hello-interval?        uint16
          |           +--rw dead-interval?         uint32
          |           +--rw retransmit-interval?   uint16
          |           +--rw transmit-delay?        uint16
          |           +--rw lls?                   boolean {lls}?
          |           +--rw ttl-security {ttl-security}?
          |           |  +--rw enabled?  boolean
          |           |  +--rw hops?     uint8
          |           +--rw enabled?               boolean
          |           +--rw authentication
          |           |  +--rw (auth-type-selection)?
          |           |     +--:(ospfv2-auth)
          |           |     |  +--rw ospfv2-auth-trailer-rfc?
          |           |     |  |       ospfv2-auth-trailer-rfc-version
          |           |     |  |        {ospfv2-authentication-trailer}?
          |           |     |  +--rw (ospfv2-auth-specification)?
          |           |     |     +--:(auth-key-chain) {key-chain}?
          |           |     |     |  +--rw ospfv2-key-chain?
          |           |     |     |         key-chain:key-chain-ref
          |           |     |     +--:(auth-key-explicit)
          |           |     |        +--rw ospfv2-key-id?     uint32
          |           |     |        +--rw ospfv2-key?        string
          |           |     |        +--rw ospfv2-crypto-algorithm?
          |           |     |                identityref
          |           |     +--:(ospfv3-auth-ipsec)
          |           |     |      {ospfv3-authentication-ipsec}?
          |           |     |  +--rw sa?                       string
          |           |     +--:(ospfv3-auth-trailer)
          |           |        |  {ospfv3-authentication-trailer}?
          |           |        +--rw (ospfv3-auth-specification)?
          |           |           +--:(auth-key-chain) {key-chain}?
          |           |           |  +--rw ospfv3-key-chain?
          |           |           |          key-chain:key-chain-ref
          |           |           +--:(auth-key-explicit)
          |           |              +--rw ospfv3-sa-id?        uint16
          |           |              +--rw ospfv3-key?          string
          |           |              +--rw ospfv3-crypto-algorithm?
          |           |                      identityref
          |           +--rw cost?               ospf-link-metric
          |           +--rw mtu-ignore?         boolean
          |           |                         {mtu-ignore}?
          |           +--rw prefix-suppression? boolean
          |           |                         {prefix-suppression}?
          |           +--ro state?                 if-state-type
          |           +--ro hello-timer?       rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro wait-timer?        rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro dr-router-id?       rt-types:router-id
          |           +--ro dr-ip-addr?         inet:ip-address
          |           +--ro bdr-router-id?      rt-types:router-id
          |           +--ro bdr-ip-addr?        inet:ip-address
          |           +--ro statistics
          |           |  +--ro discontinuity-time?    yang:date-and-time
          |           |  +--ro if-event-count?        yang:counter32
          |           |  +--ro link-scope-lsa-count?  yang:gauge32
          |           |  +--ro link-scope-lsa-cksum-sum?
          |           |                               uint32
          |           |  +--ro database
          |           |     +--ro link-scope-lsa-type*
          |           |        +--ro lsa-type?        uint16
          |           |        +--ro lsa-count?       yang:gauge32
          |           |        +--ro lsa-cksum-sum?   int32
          |           +--ro neighbors
          |           |  +--ro neighbor* [neighbor-router-id]
          |           |     +--ro neighbor-router-id
          |           |                           rt-types:router-id
          |           |     +--ro address?        inet:ip-address
          |           |     +--ro dr-router-id?   rt-types:router-id
          |           |     +--ro dr-ip-addr?     inet:ip-address
          |           |     +--ro bdr-router-id?  rt-types:router-id
          |           |     +--ro bdr-ip-addr?    inet:ip-address
          |           |     +--ro state?          nbr-state-type
          |           |     +--ro dead-timer? rt-types:
          |           |     |                  rtimer-value-seconds16
          |           |     +--ro statistics
          |           |        +--ro discontinuity-time?
          |           |                           yang:date-and-time
          |           |        +--ro nbr-event-count?
          |           |                           yang:counter32
          |           |        +--ro nbr-retrans-qlen?
          |           |                           yang:gauge32
          |           +--ro database
          |           .  +--ro link-scope-lsa-type* [lsa-type]
          |           .     +--ro lsa-type           uint16
          |           .     +--ro link-scope-lsas
          .           .
          .           .
          |           +--rw topologies {ospf:multi-topology}?
          |           |  +--rw topology* [name]
          |           |     +--rw name  -> ../../../../../../../../
          |           |                    ../../../rt:ribs/rib/name
          |           |     +--rw cost? ospf-link-metric
          |           +--rw instance-id?           uint8
          .
          .

2.8. Уведомления OSPF

Эта модель YANG содержит все уведомления, информирующие клиентов YANG о важных событиях при работе протокола. Уведомления включают базовый набор ловушек (trap) из OSPFv2 MIB [RFC4750] и OSPFv3 MIB [RFC5643].

     notifications:
       +---n if-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro state?                   if-state-type
       +---n if-config-error
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       |  +--ro error?                   enumeration
       +---n nbr-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro state?                   nbr-state-type
       +---n nbr-restart-helper-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro status?                  restart-helper-status-type
       |  +--ro age?                     rt-types:timer-value-seconds16
       |  +--ro exit-reason?             restart-exit-reason-type
       +---n if-rx-bad-packet
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       +---n lsdb-approaching-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n lsdb-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n nssa-translator-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro area-id?                 area-id-type
       |  +--ro status?                  nssa-translator-state-type
       +---n restart-status-change
          +--ro routing-protocol-name?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol/name
          +--ro address-family?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol[rt:name=current()/../
          +         routing-protocol-name]/ospf/address-family
          +--ro status?                  restart-status-type
          +--ro restart-interval?        uint16
          +--ro exit-reason?             restart-exit-reason-type

2.9. Операции OSPF RPC

Модуль ietf-ospf задаёт две операции RPC.

clear-database

Сброс содержимого конкретной базы OSPF LSDB с переводом отношений смежности в состояние DOWN и повторным созданием собственных анонсов LSA.

clear-neighbor

Сброс конкретного соседа или группы соседей OSPF, связанных с интерфейсом OSPF.
     rpcs:
       +---x clear-neighbor
       |  +---w input
       |     +---w routing-protocol-name
       |     +     -> /rt:routing/control-plane-protocols/
       |     +         control-plane-protocol/name
       |     +---w interface?               if:interface-ref
       +---x clear-database
          +---w input
             +---w routing-protocol-name
                   -> /rt:routing/control-plane-protocols/
                       control-plane-protocol/name

3. Модуль YANG OSPF

Модуль YANG ietf-ospf ссылается на [RFC0905], [RFC1765], [RFC1793], [RFC2328], [RFC3101], [RFC3623], [RFC3630], [RFC4552], [RFC4576], [RFC4577], [RFC4915], [RFC4973], [RFC5082], [RFC5185], [RFC5187], [RFC5250], [RFC5286], [RFC5309], [RFC5329], [RFC5340], [RFC5443], [RFC5613], [RFC5642], [RFC5709], [RFC5714], [RFC5838], [RFC5880], [RFC5881], [RFC6565], [RFC6845], [RFC6860], [RFC6987], [RFC6991], [RFC7166], [RFC7474], [RFC7490], [RFC7684], [RFC7770], [RFC7777], [RFC7884], [RFC8177], [RFC8294], [RFC8343], [RFC8349], [RFC8405], [RFC8476], [RFC9314].

   <CODE BEGINS> file "ietf-ospf@2022-10-19.yang"
   module ietf-ospf {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospf";

     prefix ospf;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import iana-routing-types {
       prefix iana-rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     import ietf-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     organization
       "IETF Link State Routing (lsr) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lsr/> 
        WG List:  <mailto:lsr@ietf.org> 

        Editor:   Derek Yeung
                  <mailto:derek@arrcus.com> 
        Author:   Acee Lindem
                  <mailto:acee@cisco.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.qu@futurewei.com> 
        Author:   Jeffrey Zhang
                  <mailto:zzhang@juniper.net> 
        Author:   Ing-Wher Chen
                  <mailto:ingwherchen@mitre.org>"; 

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

        Эта модель YANG соответствует архитектуре NMDA (RFC 8342).

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

        Авторские права (Copyright (c) 2022) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9129, где правовые
        аспекты приведены более полно.";

     revision 2022-10-19 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     feature multi-topology {
       description
         "Поддержка маршрутизации Multi-Topology (MT).";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     feature multi-area-adj {
       description
         "Поддержка смежности с несколькими областями (RFC 5185).";
       reference
         "RFC 5185: OSPF Multi-Area Adjacency";
     }

     feature explicit-router-id {
       description
         "Явно задаёт Router ID на уровне экземпляра.";
     }

     feature demand-circuit {
       description
         "Поддержка устройств OSPF demand (RFC 1793).";
       reference
         "RFC 1793: Extending OSPF to Support Demand Circuits";
     }

     feature mtu-ignore {
       description
         "Запрет проверки несоответствия MTU для пакетов OSPF 
          Database Description, описанной в спецификации OSPFv2
          (RFC 2328). Проверка применима и к OSPFv3 (RFC 5340).";
       reference
         "RFC 2328: OSPF Version 2, Section 10.6
          RFC 5340: OSPF for IPv6";
     }

     feature lls {
       description
         "Сигнализация OSPF LLS, определённая в RFC 5613.";
       reference
         "RFC 5613: OSPF Link-Local Signaling";
     }

     feature prefix-suppression {
       description
         "Поддержка подавления префиксов OSPF, описанная в RFC 6860.";
       reference
         "RFC 6860: Hiding Transit-Only Networks in OSPF";
     }

     feature ttl-security {
       description
         "Поддержка проверки безопасности OSPF Time TTL.";
       reference
         "RFC 5082: The Generalized TTL Security Mechanism (GTSM)";
     }

     feature nsr {
       description
         "Поддержка безостановочной маршрутизации (NSR). Функция 
          позволяет маршрутизатору с избыточностью плоскости управления
          (например, с двойными платами RP) поддерживать своё состояние
          и смежности при плановом или неплановом перезапуске экземпляра
          OSPF. Это отличается от аккуратного перезапуска и 
          безостановочной пересылки (NSF) тем, что для восстановления
          состоянии плоскости управления не требуется протокол
          сигнализации или содействие соседей OSPF .";
     }

     feature graceful-restart {
       description
         "Аккуратный перезапуск OSPF в соответствии с RFC 3623 и 5187.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     feature auto-cost {
       description
         "Расчёт стоимости для интерфейса OSPF по эталонной пропускной
          способности.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     feature max-ecmp {
       description
         "Задаёт максимальное число путей ECMP.";
     }

     feature max-lsa {
       description
         "Максимальной число анонсов LSA, воспринимаемых экземпляром.";
       reference
         "RFC 1765: OSPF Database Overflow";
     }

     feature te-rid {
       description
         "Поддержка настройки TE Router ID, т. е. Router Address TLV 
          (параграф 2.4.1 в RFC 3630) или Router IPv6 Address TLV
          (раздел 3 в RFC 5329).";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2, Section 2.4.1
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3,
          Section 3";
     }

     feature ldp-igp-sync {
       description
         "Синхронизация LDP IGP.";
       reference
         "RFC 5443: LDP IGP Synchronization";
     }

     feature ospfv2-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv2.";
       reference
         "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
          RFC 7474: Security Extension for OSPFv2 When
          Using Manual Key Management";
     }

     feature ospfv3-authentication-ipsec {
       description
         "Поддержка IPsec для аутентификации OSPFv3.";
       reference
         "RFC 4552: Authentication/Confidentiality for OSPFv3";
     }

     feature ospfv3-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv3.";
       reference
         "RFC 7166: Supporting Authentication Trailer for OSPFv3";
     }

     feature fast-reroute {
       description
         "Поддержка IP Fast Reroute (IP-FRR).";
       reference
         "RFC 5714: IP Fast Reroute Framework";
     }

     feature key-chain {
       description
         "Поддержка цепочки ключей для аутентификации.";
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     feature node-flag {
       description
         "Поддержка флагов узла для префиксов OSPF.";
       reference
         "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
     }

     feature node-tag {
       description
         "Поддержка административных флагов узла для экземпляров 
          маршрутизации OSPF.";
       reference
         "RFC 7777: Advertising Node Administrative Tags in OSPF";
     }

     feature lfa {
       description
         "Поддержка Loop-Free Alternate (LFA).";
       reference
         "RFC 5286: Basic Specification for IP Fast Reroute:
          Loop-Free Alternates";
     }

     feature remote-lfa {
       description
         "Поддержка Remote LFA (R-LFA).";
       reference
         "RFC 7490: Remote Loop-Free Alternate (LFA) Fast Reroute
          (FRR)";
     }

     feature stub-router {
       description
         "Поддержка анонсов тупиковых маршрутизаторов OSPF (RFC 6987).";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     feature pe-ce-protocol {
       description
         "Поддержка OSPF в качестве протокола PE-CE.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
          for BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE)
          Routing Protocol";
     }

     feature ietf-spf-delay {
       description
         "Поддержка алгоритма задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     feature bfd {
       description
         "Поддержка BFD для обнаружения доступности соседей OSPF.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)
          RFC 5881: Bidirectional Forwarding Detection
          (BFD) for IPv4 and IPv6 (Single Hop)";
     }

     feature hybrid-interface {
       description
         "Поддержка гибридных интерфейсов OSPF.";
       reference
         "RFC 6845: OSPF Hybrid Broadcast and
          Point-to-Multipoint Interface Type";
     }

     identity ospf {
       base rt:routing-protocol;
       description
         "Любая версия протокола OSPF.";
     }

     identity ospfv2 {
       base ospf;
       description
         "Протокол OSPFv2.";
     }

     identity ospfv3 {
       base ospf;
       description
         "Протокол OSPFv3.";
     }

     identity area-type {
       description
         "Базовый идентификатор для типа области OSPF.";
     }

     identity normal-area {
       base area-type;
       description
         "Обычная область OSPF.";
     }

     identity stub-nssa-area {
       base area-type;
       description
         "Тупиковая или NSSA область OSPF.";
     }

     identity stub-area {
       base stub-nssa-area;
       description
         "Тупиковая область OSPF.";
     }

     identity nssa-area {
       base stub-nssa-area;
       description
         "OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-lsa-type {
       description
         "Базовый идентификатор типов LSA для OSPFv2 и OSPFv3.";
     }

     identity ospfv2-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv2 LSA.";
     }

     identity ospfv2-router-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Router-LSA - тип 1.";
     }

     identity ospfv2-network-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Network-LSA - тип 2.";
     }

     identity ospfv2-summary-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 summary LSA.";
     }

     identity ospfv2-network-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 Network summary LSA - тип 3.";
     }

     identity ospfv2-asbr-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 ASBR summary LSA - тип 4.";
     }

     identity ospfv2-external-lsa-type {
       base ospfv2-lsa-type;
       description
         "OSPFv2 External-LSA.";
     }

     identity ospfv2-as-external-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 AS-External-LSA - тип 5.";
     }

     identity ospfv2-nssa-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 NSSA-LSA - тип 7.";
     }

     identity ospfv2-opaque-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 Opaque-LSA.";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity ospfv2-link-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Link-Scope Opaque-LSA - тип 9.";
     }

     identity ospfv2-area-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Area-Scope Opaque-LSA - тип 10.";
     }

     identity ospfv2-as-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 AS-Scope Opaque-LSA - тип 11.";
     }

     identity ospfv2-unknown-lsa-type {
       base ospfv2-lsa-type;
       description
         "Неизвестный тип OSPFv2 LSA.";
     }

     identity ospfv3-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv3 LSA.";
       reference
         "RFC 5340: OSPF for IPv6";
     }

     identity ospfv3-router-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-LSA - тип 0x2001.";
     }

     identity ospfv3-network-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Network-LSA - тип 0x2002.";
     }

     identity ospfv3-summary-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 summary LSA.";
     }

     identity ospfv3-inter-area-prefix-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Prefix-LSA - тип 0x2003.";
     }

     identity ospfv3-inter-area-router-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Router-LSA - тип 0x2004.";
     }

     identity ospfv3-external-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 External-LSA.";
     }

     identity ospfv3-as-external-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 AS-External-LSA - тип 0x4005.";
     }

     identity ospfv3-nssa-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 NSSA-LSA - тип 0x2007.";
     }

     identity ospfv3-link-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Link-LSA - тип 0x0008.";
     }

     identity ospfv3-intra-area-prefix-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Intra-Area-Prefix-LSA - тип 0x2009.";
     }

     identity ospfv3-router-information-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-Information-LSA - тип 0x800C, 0xA00C, 0xC00C.";
     }

     identity ospfv3-unknown-lsa-type {
       base ospfv3-lsa-type;
       description
         "Неизвестный тип OSPFv3 LSA.";
     }

     identity lsa-log-reason {
       description
         "Базовый идентификатор для причины записи LSA.";
     }

     identity lsa-refresh {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате приёма обновления LSA.";
     }

     identity lsa-content-change {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате изменения содержимого.";
     }

     identity lsa-purge {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате очистки.";
     }

     identity informational-capability {
       description
         "Базовый идентификатор возможностей маршрутизатора.";
     }

     identity graceful-restart {
       base informational-capability;
       description
         "Маршрутизатор поддерживает аккуратный перезапуск.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity graceful-restart-helper {
       base informational-capability;
       description
         "Маршрутизатор способен помогать аккуратному перезапуску.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity stub-router {
       base informational-capability;
       description
         "Маршрутизатор способен быть тупиковым OSPF stub.";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     identity traffic-engineering {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать OSPF TE.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3";
     }

     identity p2p-over-lan {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать соединения OSPF «точка-точка»
          через ЛВС.";
       reference
         "RFC 5309: Point-to-Point Operation over LAN in Link State
          Routing Protocols";
     }

     identity experimental-te {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать экспериментальный OSPF TE.";
       reference
         "RFC 4973: OSPF-xTE: Experimental Extension to OSPF for
          Traffic Engineering";
     }

     identity router-lsa-bit {
       description
         "Базовый идентификатор для битов Router-LSA.";
     }

     identity vlink-end-bit {
       base router-lsa-bit;
       description
         "Бит V, указывающий, что маршрутизатор является конечной
          точкой одного или нескольких виртуальных каналов.";
     }

     identity asbr-bit {
       base router-lsa-bit;
       description
         "Бит E, указывающий, что маршрутизатор является ASBR.";
     }

     identity abr-bit {
       base router-lsa-bit;
       description
         "Бит B, указывающий, что маршрутизатор является ABR.";
     }

     identity nssa-bit {
       base router-lsa-bit;
       description
         "Бит Nt, указывающий, что маршрутизатор является граничным для
          NSSA и безусловно транслирует NSSA-LSA в AS-External-LSA.";
     }

     identity ospfv3-lsa-option {
       description
         "базовый идентификатор для опций OSPF LSA.";
     }

     identity af-bit {
       base ospfv3-lsa-option;
       description
         "Бит AF, указывающий поддержку маршрутизатором семейств адресов
          OSPFv3, как описано в RFC 5838.";
       reference
         "RFC 5838: Support of Address Families in OSPFv3";
     }

     identity dc-bit {
       base ospfv3-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity r-bit {
       base ospfv3-lsa-option;
       description
         "Бит R, указывающий активность инициатора.";
     }

     identity n-bit {
       base ospfv3-lsa-option;
       description
         "Бит N, указывающий подключение маршрутизатора к NSSA.";
     }

     identity e-bit {
       base ospfv3-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity v6-bit {
       base ospfv3-lsa-option;
       description
         "Бит V6, сброс которого исключает маршрутизатор/канал из
          расчётов маршрутизации IPv6.";
     }

     identity ospfv3-prefix-option {
       description
         "Базовый идентификатор для опций префиксов OSPFv3.";
     }

     identity nu-bit {
       base ospfv3-prefix-option;
       description
         "Бит NU, указывающий исключение префикса из расчётов 
          IPv6 unicast.";
     }

     identity la-bit {
       base ospfv3-prefix-option;
       description
         "Бит LA, указывающий, что префикс является адресом IPv6
          интерфейса анонсирующего маршрутизатора.";
     }

     identity p-bit {
       base ospfv3-prefix-option;
       description
         "Бит P, указывающий, что префикс NSSA следует транслировать в
          AS-External-LSA и анонсировать транслирующему граничному
          маршрутизатору NSSA.";
     }

     identity dn-bit {
       base ospfv3-prefix-option;
       description
         "Бит DN, указывающий, что Inter-Area-Prefix-LSA или префикс
          AS-External-LSA анонсируется как префикс L3VPN.";
     }

     identity ospfv2-lsa-option {
       description
         "базовый идентификатор для опций OSPFv2 LSA.";
     }

     identity mt-bit {
       base ospfv2-lsa-option;
       description
         "Бит MT, указывающий что маршрутизатор поддерживает несколько
          топологий, как описано в RFC 4915.";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     identity v2-dc-bit {
       base ospfv2-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity v2-p-bit {
       base ospfv2-lsa-option;
       description
         "Бит P, используемый только для LSA типа 7 и указывающий, что
          граничному маршрутизатору NSSA следует транслировать LSA типа
          7 в LSA типа 5.";
     }

     identity mc-bit {
       base ospfv2-lsa-option;
       description
         "Бит MC, указывающий поддержку маршрутизатором MOSPF.";
     }

     identity v2-e-bit {
       base ospfv2-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity o-bit {
       base ospfv2-lsa-option;
       description
         "Бит O, указывающий поддержку опции Opaque LSA (RFC 5250).";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity v2-dn-bit {
       base ospfv2-lsa-option;
       description
         "Бит DN, который должен устанавливаться при передаче LSA типов
          3, 5, 7 от PE к CE (RFC 4576).";
       reference
         "RFC 4576: Using a Link State Advertisement (LSA) Options Bit
          to Prevent Looping in BGP/MPLS IP Virtual Private Networks
          (VPNs)";
     }

     identity ospfv2-extended-prefix-flag {
       description
         "Базовый идентификатор для флага Extended Prefix TLV.";
     }

     identity a-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг присоединения, указывающий что префикс соответствует
          маршруту, напрямую соединённому с анонсирующим 
          маршрутизатором.";
     }

     identity node-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг узла, указывающий, что префикс служит для представления
          анонсирующего узла (т. е. адреса loopback.";
     }

     typedef ospf-metric {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Метрика OSPF. 24-битовое целое число без знака.";
     }

     typedef ospf-link-metric {
       type uint16 {
         range "0 .. 65535";
       }
       description
         "метрика канала OSPF.  16-битовое целое число без знака .";
     }

     typedef opaque-id {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Opaque-LSA ID. 24-битовое целое число без знака .";
     }

     typedef area-id-type {
       type yang:dotted-quad;
       description
         "Тип Area ID.";
     }

     typedef route-type {
       type enumeration {
         enum intra-area {
           description
             "Внутриобластной маршрут OSPF.";
         }
         enum inter-area {
           description
             "Межобластной маршрут OSPF.";
         }
         enum external-1 {
           description
             "Внешний маршрут OSPF типа 1.";
         }
         enum external-2 {
           description
             "Внешний маршрут OSPF типа 2.";
         }
         enum nssa-1 {
           description
             "Маршрут OSPF NSSA типа 1.";
         }
         enum nssa-2 {
           description
             "Маршрут OSPF NSSA типа 2.";
         }
       }
       description
         "Тип маршрута OSPF.";
     }

     typedef if-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Интерфейс в состоянии Down.";
         }
         enum loopback {
           value 2;
           description
             "Интерфейс в состоянии Loopback.";
         }
         enum waiting {
           value 3;
           description
             "Интерфейс в состоянии Waiting.";
         }
         enum point-to-point {
           value 4;
           description
             "Интерфейс в состоянии Point-to-point.";
         }
         enum dr {
           value 5;
           description
             "Интерфейс в состоянии DR.";
         }
         enum bdr {
           value 6;
           description
             "Интерфейс в состоянии Backup.";
         }
         enum dr-other {
           value 7;
           description
             "Интерфейс в состоянии DR Other.";
         }
       }
       description
         "Тип состояния интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef router-link-type {
       type enumeration {
         enum point-to-point-link {
           value 1;
           description
             "Канал «точка-точка» к другому маршрутизатору.";
         }
         enum transit-network-link {
           value 2;
           description
             "Канал в транзитную сеть, указанную DR.";
         }
         enum stub-network-link {
           value 3;
           description
             "Канал в тупиковую сеть (stub), указанную подсетью.";
         }
         enum virtual-link {
           value 4;
           description
             "Виртуальный канал через транзитную область.";
         }
       }
       description
         "Тип канала маршрутизатора OSPF.";
     }

     typedef nbr-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Сосед в состоянии Down.";
         }
         enum attempt {
           value 2;
           description
             "Сосед в состоянии Attempt.";
         }
         enum init {
           value 3;
           description
             "Сосед в состоянии Init.";
         }
         enum 2-way {
           value 4;
           description
             "Сосед в состоянии 2-Way.";
         }
         enum exstart {
           value 5;
           description
             "Сосед в состоянии ExStart (начало обмена).";
         }
         enum exchange {
           value 6;
           description
             "Сосед в состоянии Exchange.";
         }
         enum loading {
           value 7;
           description
             "Сосед в состоянии Loading.";
         }
         enum full {
           value 8;
           description
             "Сосед в состоянии Full.";
         }
       }
       description
         "Тип состояния соседа OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef restart-helper-status-type {
       type enumeration {
         enum not-helping {
           value 1;
           description
             "Состояние помощника в перезапуске not-helping.";
         }
         enum helping {
           value 2;
           description
             "Состояние помощника в перезапуске helping.";
         }
       }
       description
         "Состояние помощника в перезапуске.";
     }

     typedef restart-exit-reason-type {
       type enumeration {
         enum none {
           value 1;
           description
             "Перезапуск не предпринимался.";
         }
         enum in-progress {
           value 2;
           description
             "Перезапуск выполняется.";
         }
         enum completed {
           value 3;
           description
             "Перезапуск завершен.";
         }
         enum timed-out {
           value 4;
           description
             "Тайм-аут при перезапуске.";
         }
         enum topology-changed {
           value 5;
           description
             "Перезапуск прерван из-за изменения топологии.";
         }
       }
       description
         "Описывает результат последней попытки аккуратного перезапуска.
          Локальный маршрутизатор перезапускается или помогает.";
     }

     typedef packet-type {
       type enumeration {
         enum hello {
           value 1;
           description
             "Пакет OSPF Hello.";
         }
         enum database-description {
           value 2;
           description
             "Пакет OSPF Database Description.";
         }
         enum link-state-request {
           value 3;
           description
             "Пакет OSPF Link State Request.";
         }
         enum link-state-update {
           value 4;
           description
             "Пакет OSPF Link State Update.";
         }
         enum link-state-ack {
           value 5;
           description
             "Пакет OSPF Link State Acknowledgment.";
         }
       }
       description
         "Типы пакетов OSPF.";
     }

     typedef nssa-translator-state-type {
       type enumeration {
         enum enabled {
           value 1;
           description
             "NSSATranslatorState enabled.";
         }
         enum elected {
           value 2;
           description
             "NSSATranslatorState elected.";
         }
         enum disabled {
           value 3;
           description
             "NSSATranslatorState disabled.";
         }
       }
       description
         "Тип состояния транслятора OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     typedef restart-status-type {
       type enumeration {
         enum not-restarting {
           value 1;
           description
             "Маршрутизатор не перезапускается.";
         }
         enum planned-restart {
           value 2;
           description
             "Маршрутизатор выполняет плановый перезапуск.";
         }
         enum unplanned-restart {
           value 3;
           description
             "Маршрутизатор выполняет неплановый перезапуск.";
         }
       }
       description
         "Тип состояния аккуратного перезапуска OSPF.";
     }

     typedef fletcher-checksum16-type {
       type string {
         pattern '(0x)?[0-9a-fA-F]{4}';
       }
       description
         "16-битовая контрольная сумма Fletcher в форме строки 0xXXXX.";
       reference
         "RFC 905: ISO Transport Protocol Specification ISO DP 8073";
     }

     typedef ospfv2-auth-trailer-rfc-version {
       type enumeration {
         enum rfc5709 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 5709.";
           reference
             "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication";
         }
         enum rfc7474 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 7474.";
           reference
             "RFC 7474: Security Extension for OSPFv2
              When Using Manual Key Management";
         }
       }
       description
         "Поддержка трейлера аутентификации OSPFv2.";
     }

     grouping tlv {
       description
         "Тип-Размер-Значение (Type-Length-Value или TLV).";
       leaf type {
         type uint16;
         description
           "Тип TLV.";
       }
       leaf length {
         type uint16;
         description
           "Размер TLV в октетах.";
       }
       leaf value {
         type yang:hex-string;
         description
           "Значение TLV.";
       }
     }

     grouping unknown-tlvs {
       description
         "Группировка служит для неизвестных TLV и суб-TLV.";
       container unknown-tlvs {
         description
           "Все неизвестные TLV.";
         list unknown-tlv {
           description
             "Неизвестный TLV.";
           uses tlv;
         }
       }
     }

     grouping node-tag-tlv {
       description
         "Группировка OSPF Node Admin Tag TLV.";
       list node-tag {
         leaf tag {
           type uint32;
           description
             "Значение административного тега узла.";
         }
         description
           "Список тегов.";
       }
     }

     grouping router-capabilities-tlv {
       description
         "Группировка для TLV возможностей маршрутизатора OSPF.";
       reference
         "RFC 7770: Extensions to OSPF for Advertising Optional
          Router Capabilities";
       container router-informational-capabilities {
         leaf-list informational-capabilities {
           type identityref {
             base informational-capability;
           }
           description
             "Список идентификаторов поддерживаемых маршрутизатором 
              информационных возможностей.";
         }
         description
           "Определения OSPF Router Informational Flag.";
       }
       list informational-capabilities-flags {
         leaf informational-flag {
           type uint32;
           description
             "Флаг отдельной информационной возможности.";
         }
         description
           "Список флагов информационных возможностей. Возвращаются все
            32-битовые информационные флаги, независимо от их
            известности устройству.";
       }
       list functional-capabilities {
         leaf functional-flag {
           type uint32;
           description
             "Флаг отдельной функциональной возможности.";
         }
         description
           "Список флагов функциональных возможностей. Возвращаются все
            32-битовые функциональные флаги, независимо от их
            известности устройству.";
       }
     }

     grouping dynamic-hostname-tlv {
       description
         "TLV динамического имени хоста.";
       reference
         "RFC 5642: Dynamic Hostname Exchange Mechanism for OSPF";
       leaf hostname {
         type string {
           length "1..255";
         }
         description
           "Динамическое имя хоста.";
       }
     }

     grouping sbfd-discriminator-tlv {
       description
         "S-BFD Discriminator TLV.";
       reference
         "RFC 7884: OSPF Extensions to Advertise Seamless Bidirectional
          Forwarding Detection (S-BFD) Target Discriminators";
       list sbfd-discriminators {
         leaf sbfd-discriminator {
           type uint32;
           description
             "Индивидуальный S-BFD Discriminator.";
         }
         description
           "Список дискриминаторов S-BFD.";
       }
     }

     grouping maximum-sid-depth-tlv {
       description
         "TLV узла для Maximum SID Depth (MSD).";
       reference
         "RFC 8476: Signaling Maximum SID Depth (MSD) Using OSPF";
       list msd-type {
         leaf msd-type {
           type uint8;
           description
             "Тип MSD.";
         }
         leaf msd-value {
           type uint8;
           description
             "Значение MSD для типа.";
         }
         description
           "Список кортежей MSD.";
       }
     }

     grouping ospf-router-lsa-bits {
       container router-bits {
         leaf-list rtr-lsa-bits {
           type identityref {
             base router-lsa-bit;
           }
           description
             "Список битов Router-LSA, содержащий идентификаторы для 
              всех битов, установленных в Router-LSA.";
         }
         description
           "Биты Router-LSA.";
       }
       description
         "Биты Router-LSA. В настоящее время одинаковы для OSPFv2 и
          OSPFv3, но могут быть разделены будущими дополнениями.";
     }

     grouping ospfv2-router-link {
       description
         "Канал маршрутизатора OSPFv2.";
       leaf link-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Router-LSA Link ID.";
       }
       leaf link-data {
         type union {
           type inet:ipv4-address;
           type uint32;
         }
         description
           "Данные канала Router-LSA.";
       }
       leaf type {
         type router-link-type;
         description
           "Тип канала Router-LSA.";
       }
     }

     grouping ospfv2-lsa-body {
       description
         "Тело OSPFv2 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-router-lsa')" {
           description
             "Применимо только к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         leaf num-of-links {
           type uint16;
           description
             "Число каналов в Router-LSA.";
         }
         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             uses ospfv2-router-link;
             container topologies {
               description
                 "Все топологии для канала.";
               list topology {
                 description
                   "Зависящая от топологии информация.";
                 leaf mt-id {
                   type uint8;
                   description
                     "MT-ID для топологии разрешён на канале.";
                 }
                 leaf metric {
                   type uint16;
                   description
                     "Метрика для топологии.";
                 }
               }
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";
         leaf network-mask {
           type yang:dotted-quad;
           description
             "Маска IP-адреса для сети.";
         }
         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type inet:ipv4-address;
             description
               "Список маршрутизаторов, присоединённых к сети.";
           }
         }
       }
       container summary {
         when "derived-from(../../header/type, "
            + "'ospfv2-summary-lsa-type')" {
           description
             "Применимо только к summary LSA.";
         }
         description
           "Summary LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для summary LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён в summary.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
           }
         }
       }
       container external {
         when "derived-from(../../header/type, "
            + "'ospfv2-external-lsa-type')" {
           description
             "Применимо только к AS-External-LSA и NSSA-LSA.";
         }
         description
           "External-LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для External-LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён для внешних и
                  NSSA-префиксов.";
             }
             leaf flags {
               type bits {
                 bit E {
                   description
                     "Указывает внешнюю метрику типа 2.";
                 }
               }
               description
                 "Флаги топологии.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
             leaf forwarding-address {
               type inet:ipv4-address;
               description
                 "Адрес IPv4 Forwarding.";
             }
             leaf external-route-tag {
               type uint32;
               description
                 "Флаг маршрута для топологии.";
             }
           }
         }
       }
       container opaque {
         when "derived-from(../../header/type, "
            + "'ospfv2-opaque-lsa-type')" {
           description
             "Применимо только для Opaque-LSA.";
         }
         description
           "Opaque-LSA.";

         container ri-opaque {
           description
             "OSPF Router-Information-Opaque-LSA.";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";

           container router-capabilities-tlv {
             description
               "Информационные и функциональные возможности 
                маршрутизатора.";
             uses router-capabilities-tlv;
           }

           container node-tag-tlvs {
             description
               "Все Node Admin Tag TLV.";
             list node-tag-tlv {
               description
                 "Node Admin Tag TLV.";
               uses node-tag-tlv;
             }
           }

           container dynamic-hostname-tlv {
             description
               "OSPF Dynamic Hostname TLV.";
             uses dynamic-hostname-tlv;
           }

           container sbfd-discriminator-tlv {
             description
               "OSPF S-BFD Discriminator TLV.";
             uses sbfd-discriminator-tlv;
           }

           container maximum-sid-depth-tlv {
             description
               "OSPF Node MSD TLV.";
             uses maximum-sid-depth-tlv;
           }
           uses unknown-tlvs;
         }

         container te-opaque {
           description
             "OSPFv2 TE Opaque-LSA.";
           reference
             "RFC 3630: Traffic Engineering (TE) Extensions to
              OSPF Version 2";

           container router-address-tlv {
             description
               "TLV с адресом маршрутизатора.";
             leaf router-address {
               type inet:ipv4-address;
               description
                 "Адрес маршрутизатора.";
             }
           }

           container link-tlv {
             description
               "Описывает один канал и состоит из набора суб-TLV.";
             leaf link-type {
               type router-link-type;
               mandatory true;
               description
                 "Тип канала.";
             }
             leaf link-id {
               type union {
                 type inet:ipv4-address;
                 type yang:dotted-quad;
               }
               mandatory true;
               description
                 "Link ID.";
             }
             container local-if-ipv4-addrs {
               description
                 "Все адреса IPv4 локального интерфейса.";
               leaf-list local-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 локального интерфейса.";
               }
             }
             container remote-if-ipv4-addrs {
               description
                 "Все адреса IPv4 удалённого интерфейса.";
               leaf-list remote-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 удалённого интерфейса.";
               }
             }
             leaf te-metric {
               type uint32;
               description
                 "TE metric.";
             }
             leaf max-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная пропускная способность.";
             }
             leaf max-reservable-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная резервируемая пропускная способность.";
             }
             container unreserved-bandwidths {
               description
                 "Вся незарезервированная пропускная способность.";
               list unreserved-bandwidth {
                 leaf priority {
                   type uint8 {
                     range "0 .. 7";
                   }
                   description
                     "Приоритет от 0 до 7.";
                 }
                 leaf unreserved-bandwidth {
                   type rt-types:bandwidth-ieee-float32;
                   description
                     "Незарезервированная пропускная способность.";
                 }
                 description
                   "Список значение незарезервированной пропускной
                    способности для разных приоритетов.";
               }
             }
             leaf admin-group {
               type uint32;
               description
                 "Административная группа-Класс ресурсов-Цвет.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-prefix-opaque {
           description
             "Все Extended Prefix TLV в LSA.";
           list extended-prefix-tlv {
             description
               "Extended Prefix TLV.";
             leaf route-type {
               type enumeration {
                 enum unspecified {
                   value 0;
                   description
                     "Не задано.";
                 }
                 enum intra-area {
                   value 1;
                   description
                     "Маршрут внутри области OSPF.";
                 }
                 enum inter-area {
                   value 3;
                   description
                     "Маршрут между областями OSPF.";
                 }
                 enum external {
                   value 5;
                   description
                     "Внешний маршрут OSPF.";
                 }
                 enum nssa {
                   value 7;
                   description
                     "Внешний маршрут OSPF NSSA.";
                 }
               }
               description
                 "Тип маршрута.";
             }
             container flags {
               leaf-list extended-prefix-flags {
                 type identityref {
                   base ospfv2-extended-prefix-flag;
                 }
                 description
                   "Список флагов Extended Prefix TLV, содержащий
                    идентификаторы для флагов префикса, устанавливаемые
                    во флагах расширенного префикса.";
               }
               description
                 "Флаги префикса.";
             }
             leaf prefix {
               type inet:ip-prefix;
               description
                 "Адресный префикс.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-link-opaque {
           description
             "Все Extended Link TLV в LSA.";
           reference
             "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
           container extended-link-tlv {
             description
               "Extended Link TLV.";
             uses ospfv2-router-link;
             container maximum-sid-depth-tlv {
               description
                 "OSPF Node MSD TLV.";
               uses maximum-sid-depth-tlv;
             }
             uses unknown-tlvs;
           }
         }
       }
     }

     grouping ospfv3-lsa-options {
       description
         "Опции OSPFv3 LSA.";
       container lsa-options {
         leaf-list lsa-options {
           type identityref {
             base ospfv3-lsa-option;
           }
           description
             "Список опций OSPFv3 LSA, содержащий идентификаторы
              OSPFv3 LSA Option, устанавливаемых для LSA.";
         }
         description
           "Опции OSPFv3 LSA.";
       }
     }

     grouping ospfv3-lsa-prefix {
       description
         "Префикс OSPFv3 LSA.";

       leaf prefix {
         type inet:ip-prefix;
         description
           "Префикс LSA.";
       }
       container prefix-options {
         leaf-list prefix-options {
           type identityref {
             base ospfv3-prefix-option;
           }
           description
             "Список опций префиксов OSPFv3, содержащий идентификаторы
              опций OSPFv3, устанавливаемых для префикса OSPFv3.";
         }
         description
           "Опции префикса.";
       }
     }

     grouping ospfv3-lsa-external {
       description
         "AS-External-LSA or NSSA-LSA.";
       leaf metric {
         type ospf-metric;
         description
           "Метрика AS-External-LSA или NSSA-LSA.";
       }
       leaf flags {
         type bits {
           bit E {
             description
               "Указывает внешнюю метрику типа 2.";
           }
           bit F {
             description
               "Указывает включение пересылающего адреса в LSA.";
           }
           bit T {
             description
               "Указывает включение тега внешнего маршрута в LSA.";
           }
         }
         description
           "Флаги AS-External-LSA или NSSA-LSA.";
       }

       leaf referenced-ls-type {
         type identityref {
           base ospfv3-lsa-type;
         }
         description
           "Referenced Link State (LS) Type.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
       leaf unknown-referenced-ls-type {
         type uint16;
         description
           "Значение для неизвестного Referenced LS Type.";
       }

       uses ospfv3-lsa-prefix;

       leaf forwarding-address {
         type inet:ipv6-address;
         description
           "Адрес IPv6 Forwarding.";
       }

       leaf external-route-tag {
         type uint32;
         description
           "Тег маршрута.";
       }
       leaf referenced-link-state-id {
         type uint32;
         description
           "Referenced Link State ID.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
     }

     grouping ospfv3-lsa-body {
       description
         "Тело OSPFv3 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-lsa')" {
           description
             "Применимо лишь к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         uses ospfv3-lsa-options;

         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             leaf interface-id {
               type uint32;
               description
                 "Interface ID для канала.";
             }
             leaf neighbor-interface-id {
               type uint32;
               description
                 "Interface ID соседа по каналу.";
             }
             leaf neighbor-router-id {
               type rt-types:router-id;
               description
                 "Router ID соседа по каналу.";
             }
             leaf type {
               type router-link-type;
               description
                 "Ти канала: 1 - «точка-точка»
                             2 — транзитная сеть
                             3 — резерв для каналов OSPFv3
                             4 — виртуальный канал.";
             }
             leaf metric {
               type uint16;
               description
                 "Метрика канала.";
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";

         uses ospfv3-lsa-options;

         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type rt-types:router-id;
             description
               "Список присоединённых к сети маршрутизаторов.";
           }
         }
       }
       container inter-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-prefix-lsa')" {
           description
             "Применимо только к Inter-Area-Prefix-LSA.";
         }
         leaf metric {
           type ospf-metric;
           description
             "Метрика префикса Inter-Area Prefix.";
         }
         uses ospfv3-lsa-prefix;
         description
           "Prefix-LSA.";
       }
       container inter-area-router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-router-lsa')" {
           description
             "Применимо только к Inter-Area-Router-LSA.";
         }
         uses ospfv3-lsa-options;
         leaf metric {
           type ospf-metric;
           description
             "Метрика граничного маршрутизатора AS (ASBR).";
         }
         leaf destination-router-id {
           type rt-types:router-id;
           description
             "Router ID маршрутизатора ASBR из LSA.";
         }
         description
           "Inter-Area-Router-LSA.";
       }
       container as-external {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-as-external-lsa')" {
           description
             "Применимо только к AS-External-LSA.";
         }

         uses ospfv3-lsa-external;

         description
           "AS-External-LSA.";
       }
       container nssa {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-nssa-lsa')" {
           description
             "Применимо только к NSSA-LSA.";
         }
         uses ospfv3-lsa-external;

         description
           "NSSA-LSA.";
       }
       container link {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-link-lsa')" {
           description
             "Применимо только к Link-LSA.";
         }
         leaf rtr-priority {
           type uint8;
           description
             "Приоритет маршрутизатора для выбора DR. Предпочитается
              маршрутизатор с наибольшим значением, 0 указывает, что
              маршрутизатор нежелателен в качестве DR или BDR.";
         }
         uses ospfv3-lsa-options;

         leaf link-local-interface-address {
           type inet:ipv6-address;
           description
             "Адрес link-local интерфейса создавшего анонс 
              маршрутизатора для этого канала.";
         }

         leaf num-of-prefixes {
           type uint32;
           description
             "Число префиксов.";
         }

         container prefixes {
           description
             "Все префиксы для канала.";
           list prefix {
             description
               "Список связанных с каналом префиксов.";
             uses ospfv3-lsa-prefix;
           }
         }
         description
           "Link-LSA.";
       }
       container intra-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-intra-area-prefix-lsa')" {
           description
             "Применимо только к Intra-Area-Prefix-LSA.";
         }
         description
           "Intra-Area-Prefix-LSA.";

         leaf referenced-ls-type {
           type identityref {
             base ospfv3-lsa-type;
           }
           description
             "Referenced LS Type.";
         }
         leaf unknown-referenced-ls-type {
           type uint16;
           description
             "Значение для неизвестного Referenced LS Type.";
         }
         leaf referenced-link-state-id {
           type uint32;
           description
             "Referenced Link State ID.";
         }
         leaf referenced-adv-router {
           type rt-types:router-id;
           description
             "Referenced Advertising Router.";
           reference
             "RFC 5340: OSPF for IPv6";
         }

         leaf num-of-prefixes {
           type uint16;
           description
             "Число префиксов.";
         }
         container prefixes {
           description
             "Все префиксы в этом анонсе LSA.";
           list prefix {
             description
               "Список префиксов в LSA.";
             uses ospfv3-lsa-prefix;
             leaf metric {
               type uint16;
               description
                 "Метрика перфикса.";
             }
           }
         }
       }
       container router-information {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-information-lsa')" {
           description
             "Применимо только к Router-Information-LSA (RFC 7770).";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";
         }
         container router-capabilities-tlv {
           description
             "Информационные и функциональные возможности 
              маршрутизатора.";
           uses router-capabilities-tlv;
         }
         container node-tag-tlvs {
           description
             "Все Node Admin Tag TLV.";
           list node-tag-tlv {
             description
               "Node Admin Tag TLV.";
             uses node-tag-tlv;
           }
         }
         container dynamic-hostname-tlv {
           description
             "OSPF Dynamic Hostname TLV.";
           uses dynamic-hostname-tlv;
         }

         container sbfd-discriminator-tlv {
           description
             "OSPF S-BFD Discriminator TLV.";
           uses sbfd-discriminator-tlv;
         }

         description
           "Router-Information-LSA.";
         reference
           "RFC 7770: Extensions to OSPF for Advertising Optional
            Router Capabilities";
       }
     }

     grouping lsa-header {
       description
         "LSA для OSPFv2 и OSPFv3.";
       leaf age {
         type uint16;
         mandatory true;
         description
           "Возраст LSA.";
       }
       leaf type {
         type identityref {
           base ospf-lsa-type;
         }
         mandatory true;
         description
           "Тип LSA.";
       }
       leaf adv-router {
         type rt-types:router-id;
         mandatory true;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         mandatory true;
         description
           "Порядковый номер LSA.";
       }
       leaf checksum {
         type fletcher-checksum16-type;
         mandatory true;
         description
           "Контрольная сумма LSA.";
       }
       leaf length {
         type uint16;
         mandatory true;
         description
           "Размер LSA с учётом заголовка.";
       }
     }

     grouping ospfv2-lsa {
       description
         "OSPFv2 LSA. Анонсы LSA однозначно указываются триплетом
          <LSA Type, Link State ID, Advertising Router> с разделением
          экземпляров по порядковым номерам LSA.";
       container header {
         must "(derived-from(type, "
            + "'ospfv2-opaque-lsa-type') and "
            + "opaque-id and opaque-type) or "
            + "(not(derived-from(type, "
            + "'ospfv2-opaque-lsa-type')) "
            + "and not(opaque-id) and not(opaque-type))" {
           description
             "Значение opaque-type и opaque-id применимы лишь 
              к Opaque-LSA.";
         }
         description
           "Декодированные данные заголовка OSPFv2 LSA.";

         container lsa-options {
           leaf-list lsa-options {
             type identityref {
               base ospfv2-lsa-option;
             }
             description
               "Список опций LSA, содержащий идентификаторы 
                установленных опций OSPFv2 LSA.";
           }
           description
             "Опции LSA.";
         }

         leaf lsa-id {
           type yang:dotted-quad;
           mandatory true;
           description
             "Link State ID.";
         }

         leaf opaque-type {
           type uint8;
           description
             "Тип Opaque-LSA.";
         }

         leaf opaque-id {
           type opaque-id;
           description
             "Opaque-LSA ID.";
         }

         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPFv2 LSA.";
         uses ospfv2-lsa-body;
       }
     }

     grouping ospfv3-lsa {
       description
         "Декодированный анонс OSPFv3 LSA.";
       container header {
         description
           "Декодированные данные заголовка OSPFv3 LSA.";
         leaf lsa-id {
           type uint32;
           mandatory true;
           description
             "OSPFv3 LSA ID.";
         }
         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPF LSA.";
         uses ospfv3-lsa-body;
       }
     }
     grouping lsa-common {
       description
         "Общие поля для представления OSPF LSA.";
       leaf decode-completed {
         type boolean;
         description
           "Тело OSPF LSA было декодировано за исключением
            неизвестных TLV. Типы неизвестных LSA и OSPFv2 Opaque-LSA
            не декодированы. Некорректно сформированные LSA обычно не
            воспринимаются м не включаются в LSDB.";
       }
       leaf raw-data {
         type yang:hex-string;
         description
           "Шестнадцатеричное представление полного анонса LSA, как
            он получен или передан, с сетевым порядком байтов.";
       }
     }

     grouping lsa {
       description
         "OSPF LSA.";
       uses lsa-common;
       choice version {
         description
           "Тело OSPFv2 или OSPFv3 LSA.";
         container ospfv2 {
           description
             "OSPFv2 LSA.";
           uses ospfv2-lsa;
         }
         container ospfv3 {
           description
             "OSPFv3 LSA.";
           uses ospfv3-lsa;
         }
       }
     }

     grouping lsa-key {
       description
         "Ключ OSPF LSA. Ключ базы данных для каждого анонса LSA данного
          типа в базе LSDB.";
       leaf lsa-id {
         type union {
           type yang:dotted-quad;
           type uint32;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий маршрутизатор.";
       }
     }

     grouping instance-stat {
       description
         "Статистика для экземпляра.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого экземпляра OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации экземпляра OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании экземпляра OSPF.";
       }
       leaf originate-new-lsa-count {
         type yang:counter32;
         description
           "Число созданных LSA. Разрыв этого счётчика может происходить
            при реинициализации экземпляра OSPF.";
       }
       leaf rx-new-lsas-count {
         type yang:counter32;
         description
           "Число принятых новых LSA.  Разрыв этого счётчика может
            происходить при реинициализации экземпляра OSPF.";
       }
       leaf as-scope-lsa-count {
         type yang:gauge32;
         description
           "Число AS-Scope LSA.";
       }
       leaf as-scope-lsa-chksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для AS-Scope LSA.
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA,
            эквивалентные контрольные суммы не гарантируют совпадения
            LSA, поскольку разные комбинации могут давать одну
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики на уровне AS-Scope LSA.";
         list as-scope-lsa-type {
           description
             "Список статистики AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип AS-Scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
       uses instance-fast-reroute-state;
     }

     grouping area-stat {
       description
         "Per-area statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этой области OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации области OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании области OSPF.";
       }
       leaf spf-runs-count {
         type yang:counter32;
         description
           "Число запусков внутриобластного алгоритма SPF. Разрыв этого
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf abr-count {
         type yang:gauge32;
         description
           "Число доступных в области граничных маршрутизаторов (ABR).";
       }
       leaf asbr-count {
         type yang:gauge32;
         description
           "Общее число граничных маршрутизаторов AS (ASBR), доступных
            внутри этой области.";
       }
       leaf ar-nssa-translator-event-count {
         type yang:counter32;
         description
           "Общее число изменения состояния транслятора NSSA. Разрыв 
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf area-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Area-scope LSA в области.";
       }
       leaf area-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Area-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Area-scope LSA.";
         list area-scope-lsa-type {
           description
             "Список статистики Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Area-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping interface-stat {
       description
         "Per-interface statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого интерфейса OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации интерфейса OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании интерфейса OSPF.";
       }
       leaf if-event-count {
         type yang:counter32;
         description
           "Число изменений состояния интерфейса или ошибок на нем.
            Разрыв счётчика может возникать при реинициализации
            интерфейса OSPF.";
       }
       leaf link-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Link-scope LSA.";
       }
       leaf link-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Link-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Link-scope LSA.";
         list link-scope-lsa-type {
           description
             "Список статистики Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Link-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping neighbor-stat {
       description
         "Статистика на уровне соседа.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            для этого соседа OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации соседа OSPF,
            узел содержит время инициализации, которое обычно происходит
            при динамическом обнаружении соседа OSPF.";
       }
       leaf nbr-event-count {
         type yang:counter32;
         description
           "Число изменений состояния соседа или ошибок для него.
            Разрыв счётчика может возникать при реинициализации
            соседа OSPF.";
       }
       leaf nbr-retrans-qlen {
         type yang:gauge32;
         description
           "Текущий размер очереди на повтор передачи.";
       }
     }

     grouping instance-fast-reroute-config {
       description
         "Эта группа задаёт глобальную конфигурацию 
          IP Fast Reroute (IP-FRR).";
       container fast-reroute {
         if-feature "fast-reroute";
         description
           "Этот контейнер может дополняться глобальными параметрами
            для IP-FRR.";
         container lfa {
           if-feature "lfa";
           description
             "Этот контейнер может дополняться глобальными параметрами
              для Loop-Free Alternate (LFA). Создание контейнера не
              влияет на активацию LFA.";
         }
       }
     }

     grouping instance-fast-reroute-state {
       description
         "Группировка данных состояния IP-FRR.";

       container protected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Статистика защиты экземпляра.";

         list address-family-stats {
           key "address-family prefix alternate";
           description
             "Сведения о защищённом префиксе на семейство адресов.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Защищённый префикс.";
           }
           leaf alternate {
             type inet:ip-address;
             description
               "Другой next-hop для префикса.";
           }
           leaf alternate-type {
             type enumeration {
               enum equal-cost {
                 description
                   "Вариант на основе ECMP.";
               }
               enum lfa {
                 description
                   "Вариант на основе LFA.";
               }
               enum remote-lfa {
                 description
                   "Вариант на основе Remote-LFA.";
               }
               enum tunnel {
                 description
                   "Вариант на основе туннеля (RSVP-TE или GRE).";
               }
               enum ti-lfa {
                 description
                   "Вариант на основе TI-LFA.";
               }
               enum mrt {
                 description
                   "Вариант на основе MRT.";
               }
               enum other {
                 description
                   "Вариант неизвестного типа.";
               }
             }
             description
               "Тип варианта.";
           }
           leaf best {
             type boolean;
             description
               "Указывает предпочтительность этого варианта.";
           }
           leaf non-best-reason {
             type string {
               length "1..255";
             }
             description
               "Описывает причину того, что вариант не является
                лучшим выбором.";
           }
           leaf protection-available {
             type bits {
               bit node-protect {
                 position 0;
                 description
                   "Доступна защита узла.";
               }
               bit link-protect {
                 position 1;
                 description
                   "Доступна защита канала.";
               }
               bit srlg-protect {
                 position 2;
                 description
                   "Доступна защита SRLG.";
               }
               bit downstream-protect {
                 position 3;
                 description
                   "Доступна защита нисходящего направления.";
               }
               bit other {
                 position 4;
                 description
                   "Доступна иная защита.";
               }
             }
             description
               "Защита обеспечивается вариантом (альтернативой).";
           }
           leaf alternate-metric-1 {
             type uint32;
             description
               "Метрика от точки локального ремонта (PLR) до адресата
                по альтернативному пути.";
           }
           leaf alternate-metric-2 {
             type uint32;
             description
               "Метрика от PLR до альтернативного узла.";
           }
           leaf alternate-metric-3 {
             type uint32;
             description
               "Метрика от альтернативного узла до адресата.";
           }
         }
       }

       container unprotected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Список незащищённых префиксов.";

         list address-family-stats {
           key "address-family prefix";
           description
             "Статистика незащищённых префиксов на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Незащищённый префикс.";
           }
         }
       }

       list protection-statistics {
         key "frr-protection-method";
         config false;
         description
           "Список статистики методов защиты.";

         leaf frr-protection-method {
           type string;
           description
             "Используемый метод защиты.";
         }
         list address-family-stats {
           key "address-family";
           description
             "Статистика защиты на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf total-routes {
             type uint32;
             description
               "Общее число префиксов.";
           }
           leaf unprotected-routes {
             type uint32;
             description
               "Общее число незащищённых префиксов.";
           }
           leaf protected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
           leaf linkprotected-routes {
             type uint32;
             description
               "Общее число префиксов с защитой канала.";
           }
           leaf nodeprotected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
         }
       }
     }

     grouping interface-fast-reroute-config {
       description
         "Эта группа определяет конфигурацию интерфейса IP-FRR.";
       container fast-reroute {
         if-feature "fast-reroute";
         container lfa {
           if-feature "lfa";
           leaf candidate-enabled {
             type boolean;
             default "true";
             description
               "Разрешает применять интерфейс как резервный.";
           }
           leaf enabled {
             type boolean;
             default "false";
             description
               "Активирует LFA. Предполагается расчёт LFA на префикс.";
           }
           container remote-lfa {
             if-feature "remote-lfa";
             leaf enabled {
               type boolean;
               default "false";
               description
                 "Активирует Remote LFA (R-LFA).";
             }
             description
               "Конфигурация R-LFA.";
           }
           description
             "Конфигурация LFA.";
         }
         description
           "Конфигурация интерфейса IP-FRR.";
       }
     }

     grouping interface-physical-link-config {
       description
         "Конфигурация стоимости интерфейса, применяемая только к
          физическим (не виртуальным) интерфейсам и и sham-каналам.";
       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса.";
       }
       leaf mtu-ignore {
         if-feature "mtu-ignore";
         type boolean;
         description
           "Управляет обходом проверки несоответствия MTU для пакетов
            Database Description (параграф 10.6 в RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2, Section 10.6";
       }
       leaf prefix-suppression {
         if-feature "prefix-suppression";
         type boolean;
         description
           "Подавляет анонсы префиксов, связанных с интерфейсом.";
       }
     }

     grouping interface-common-config {
       description
         "Общая конфигурация для всех типов интерфейсов, включая
          виртуальные и sham-каналы (фиктивные).";

       leaf hello-interval {
         type uint16;
         units "seconds";
         description
           "Интервал между пакетами Hello (в секундах), который должен
            совпадать для всех маршрутизаторов в одной сети. Разные
            реализации и развёртывания применяют разные интервалы Hello.
            Примером значения для ЛВС служит интервал в 10 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf dead-interval {
         type uint16;
         units "seconds";
         must '../dead-interval > ../hello-interval' {
           error-message "Интервал «умирания» (dead) должен быть "
                       + "больше интервала Hello";
           description
             "Значение должно быть больше hello-interval.";
         }
         description
           "Интервал, после которого сосед считается отключённым 
            (в секундах), если от него нет пакетов Hello. Обычно это
            в 3 - 4 раза больше hello-interval. Типовое значение для
            ЛВС составляет 40 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf retransmit-interval {
         type uint16 {
           range "1..3600";
         }
         units "seconds";
         description
           "Интервал повтора неподтвержденных анонсов LSA (в секундах).
            Значение должно быть больше RTT между любыми двумя 
            маршрутизаторами в сети. Примером служит значение 5 сек.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf transmit-delay {
         type uint16;
         units "seconds";
         description
           "Оценка времени передачи пакетов обновления состояния канала
            (LSU) на интерфейсе (в секундах). Возраст LSA увеличивается
            на это значение при анонсировании через интерфейс. Примером
            значения является 1 секунда.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf lls {
         if-feature "lls";
         type boolean;
         description
           "Управляет поддержкой сигнализации LLS.";
       }

       container ttl-security {
         if-feature "ttl-security";
         description
           "Проверка безопасности TTL.";
         leaf enabled {
           type boolean;
           description
             "Управляет проверкой безопасности TTL.";
         }
         leaf hops {
           type uint8 {
             range "1..254";
           }
           default "1";
           description
             "Максимальное число пересылок (hop), которые пакет OSPF
              может пройти до получения.";
         }
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Управляет протоколом OSPF на интерфейсе.";
       }

       container authentication {
         description
           "Конфигурация проверки подлинности.";
         choice auth-type-selection {
           description
             "Опции для настройки аутентификации OSPFv2/OSPFv3.";
           case ospfv2-auth {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv2')" {
               description
                 "Применимо только к OSPFv2.";
             }
             leaf ospfv2-auth-trailer-rfc {
               if-feature "ospfv2-authentication-trailer";
               type ospfv2-auth-trailer-rfc-version;
               description
                 "Поддержка трейлера аутентификации OSPFv2 (RFC 5709
                  и RFC 7474).";
               reference
                 "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
                  RFC 7474: Security Extension for OSPFv2 When Using
                  Manual Key Management";
             }
             choice ospfv2-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv2-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv2-key-id {
                   type uint32;
                   description
                     "Идентификатор ключа.";
                 }
                 leaf ospfv2-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv2. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv2-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
           case ospfv3-auth-ipsec {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-ipsec";
             leaf sa {
               type string;
               description
                 "Имя защищённой связи (SA).";
             }
           }
           case ospfv3-auth-trailer {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-trailer";
             choice ospfv3-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv3-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv3-sa-id {
                   type uint16;
                   description
                 "Имя защищённой связи (SA).";
                 }
                 leaf ospfv3-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv3. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv3-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-config {
       description
         "Конфигурация для обычных интерфейсов OSPF (не виртуальных
          или фиктивных - sham).";

       leaf interface-type {
         type enumeration {
           enum broadcast {
             description
               "Широковещательная сеть с множественным доступом.";
           }
           enum non-broadcast {
             description
               "Сеть с множественным доступом без широковещания (NBMA).";
           }
           enum point-to-multipoint {
             description
               "Сеть «один со многими» (point-to-multipoint).";
           }
           enum point-to-point {
             description
                "Сеть «точка-точка».";
              "Specifies an OSPF point-to-point network.";
           }
           enum hybrid {
             if-feature "hybrid-interface";
             description
               "Гибридная сеть (широковещание/point-to-multipoint).";
           }
         }
         description
           "Тип интерфейса.";
       }

       leaf passive {
         type boolean;
         description
           "Управляет пассивным интерфейсом. Префикс пассивного
            интерфейса анонсируется, но смежность не создается.";
       }

       leaf demand-circuit {
         if-feature "demand-circuit";
         type boolean;
         description
           "Управляет demand-устройством.";
       }

       leaf priority {
         type uint8;
         description
           "Задаёт приоритет маршрутизатора OSPF. В сети с множественным
            доступом это служит для выбора DR. На интерфейсах других
            типов приоритет игнорируется. Маршрутизатор с высоким 
            приоритетом предпочитается при выборе. Значение 0 указывает,
            что маршрутизатору нежелательно быть DR или BDR.";
       }

       container multi-areas {
         if-feature "multi-area-adj";
         description
           "Контейнер для конфигурации с множеством областей.";
         list multi-area {
           key "multi-area-id";
           description
             "Настраивает смежность между областями OSPF.";
           leaf multi-area-id {
             type area-id-type;
             description
               "Идентификатор области для смежности областей.";
           }
           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса для смежности областей.";
           }
         }
       }

       container static-neighbors {
         description
           "Статически заданные соседи.";

         list neighbor {
           key "identifier";
           description
             "Статически заданный сосед OSPF.";

           leaf identifier {
             type inet:ip-address;
             description
               "Router ID, адрес IPv4 или IPv6 у соседа.";
           }

           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса. Разные реализации по умолчанию 
                задают разную стоимость, при этом у некоторых стоимость
                обратно пропорциональная значения. Некоторые задают по
                умолчанию 1, считая стоимостью число пересылок (hop).";
           }
           leaf poll-interval {
             type uint16;
             units "seconds";
             description
               "Интервал опроса (в секундах) для отправки пакетов
                OSPF Hello с целью обнаружения соседей в сети NBMA.
                Этот интервал задаёт детализацию поиска новых соседей.
                Примером может служить интервал 120 секунд (2 минуты)
                для унаследованных пакетных сетей (PDN) X.25.";
             reference
               "RFC 2328: OSPF Version 2, Appendix C.5";
           }
           leaf priority {
             type uint8;
             description
               "Приоритет соседа при выборе DR. Маршрутизатор с высоким 
                приоритетом предпочитается при выборе, 0, указывает,
                что маршрутизатору нежелательно быть DR или BDR.";
           }
         }
       }

       leaf node-flag {
         if-feature "node-flag";
         type boolean;
         default "false";
         description
           "Набор префиксов, указывающих анонсирующий маршрутизатор.";
         reference
           "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
       }

       container bfd {
         if-feature "bfd";
         description
           "Конфигурация интерфейса BFD.";
         uses bfd-types:client-cfg-parms;
         reference
           "RFC 5880: Bidirectional Forwarding Detection (BFD)
            RFC 5881: Bidirectional Forwarding Detection
            (BFD) for IPv4 and IPv6 (Single Hop)
            RFC 9314: YANG Data Model for Bidirectional Forwarding
            Detection (BFD)";
       }

       uses interface-fast-reroute-config;
       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping neighbor-state {
       description
         "Рабочее состояние соседа OSPF.";

       leaf address {
         type inet:ip-address;
         config false;
         description
           "Адрес соседа.";
       }
       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "Router ID у DR соседа.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у DR соседа.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
          "Router ID у BDR соседа.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у BDR соседа.";
       }
       leaf state {
         type nbr-state-type;
         config false;
         description
           "Состояние соседа OSPF.";
       }
       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость доступа к соседу для сетей point-to-multipoint
            и Hybrid.";
       }
       leaf dead-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента, когда
            сосед будет сочтён «мертвым».";
       }
       container statistics {
         config false;
         description
           "Статистика для соседа.";
         uses neighbor-stat;
       }
     }

     grouping interface-common-state {
       description
         "Базовое рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       leaf state {
         type if-state-type;
         config false;
         description
           "Состояние интерфейса.";
       }

       leaf hello-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента отправки
            через интерфейс следующего сообщения Hello.";
       }

       leaf wait-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента выхода
            интерфейса из состояния Waiting.";
       }

       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "DR Router ID.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес DR.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
           "BDR Router ID.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес BDR.";
       }

       container statistics {
         config false;
         description
           "Статистика для интерфейса.";
         uses interface-stat;
       }

       container neighbors {
         config false;
         description
           "Все соседи на интерфейсе.";
         list neighbor {
           key "neighbor-router-id";
           description
             "Список соседей OSPF на интерфейсе.";
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
           uses neighbor-state;
         }
       }
       container database {
         config false;
         description
           "Link-scope LSDB.";
         list link-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Link-scope LSA.";
           }
           container link-scope-lsas {
             description
               "Все Link-scope LSA этого типа.";
             list link-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Link-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-state {
       description
         "Рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       uses interface-common-state;
     }

     grouping virtual-link-config {
       description
         "Состояние конфигурации виртуального канала OSPF.";

       uses interface-common-config;
     }

     grouping virtual-link-state {
       description
         "Рабочее состояние виртуального канала OSPF.";

       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость интерфейса виртуального канала.";
       }
       uses interface-common-state;
     }

     grouping sham-link-config {
       description
         "Состояние конфигурации фиктивного канала OSPF.";

       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping sham-link-state {
       description
         "Рабочее состояние фиктивного канала OSPF.";
       uses interface-common-state;
     }

     grouping address-family-area-config {
       description
         "Состояние конфигурации области OSPF для семейства адресов.";

       container ranges {
         description
           "Контейнер для сводных (summary) диапазонов.";

         list range {
           key "prefix";
           description
             "Сводка маршрутов, соответствующих адресу и маске.
              Применима лишь для маршрутизаторов ABR.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс IPv4 или IPv6.";
           }
           leaf advertise {
             type boolean;
             description
               "Аносируется или скрыт.";
           }
           leaf cost {
             type ospf-metric;
             description
               "Анонсируемая стоимость сводного маршрута.";
           }
         }
       }
     }

     grouping area-common-config {
       description
         "Базовое состояние конфигурации области OSPF.";

       leaf summary {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет анонсами в тупиковые области или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Стоимость LSA принятого по умолчанию маршрута,
              анонсируемого у тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводную стоимость маршрута по умолчанию для
            тупиковой области или NSSA.";
       }
     }

     grouping area-config {
       description
         "Состояние конфигурации области OSPF.";

       leaf area-type {
         type identityref {
           base area-type;
         }
         default "normal-area";
         description
           "Тип области.";
       }

       uses area-common-config;
       uses address-family-area-config;
     }

     grouping area-state {
       description
         "Рабочее состояние области OSPF.";

       container statistics {
         config false;
         description
           "Статистика для области.";
         uses area-stat;
       }

       container database {
         config false;
         description
           "Area-scope LSDB.";
         list area-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Area-scope LSA.";
           }
           container area-scope-lsas {
             description
               "Все Area-scope LSA.";
             list area-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Area-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping local-rib {
       description
         "Локальная таблица RIB для маршрутов, рассчитанных
          локальным экземпляром маршрутизации OSPF.";
       container local-rib {
         config false;
         description
           "Local RIB.";
         list route {
           key "prefix";
           description
             "Локальные маршруты экземпляра OSPF.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс адресата.";
           }
           container next-hops {
             description
               "Следующие узлы (next-hop) для маршрута.";
             list next-hop {
               description
                 "Список next-hop для маршрута.";
               leaf outgoing-interface {
                 type if:interface-ref;
                 description
                   "Имя выходного интерфейса.";
               }
               leaf next-hop {
                 type inet:ip-address;
                 description
                   "Адрес next-hop.";
               }
             }
           }
           leaf metric {
             type uint32;
             description
               "Метрика маршрута.";
           }
           leaf route-type {
             type route-type;
             description
               "Тип маршрута.";
           }
           leaf route-tag {
             type uint32;
             description
               "Тег для маршрута.";
           }
         }
       }
     }

     grouping ietf-spf-delay {
       leaf initial-delay {
         type uint32;
         units "milliseconds";
         default "50";
         description
           "Задержка, применяемая в состоянии QUIET (мсек).";
       }
       leaf short-delay {
         type uint32;
         units "milliseconds";
         default "200";
         description
           "Задержка, применяемая в состоянии SHORT_WAIT (мсек).";
       }
       leaf long-delay {
         type uint32;
         units "milliseconds";
         default "5000";
         description
           "Задержка, применяемая в состоянии LONG_WAIT (мсек).";
       }
       leaf hold-down {
         type uint32;
         units "milliseconds";
         default "10000";
         description
           "Таймер для интервала без изменений, когда IGP
            считается стабильным (мсек).";
       }
       leaf time-to-learn {
         type uint32;
         units "milliseconds";
         default "500";
         description
           "Продолжительность изучения всех событий IGP, относящихся
            к одному сетевому событию (мсек).";
       }
       leaf current-state {
         type enumeration {
           enum quiet {
             description
               "Состояние QUIET.";
           }
           enum short-wait {
             description
               "Состояние SHORT_WAIT.";
           }
           enum long-wait {
             description
               "Состояние LONG_WAIT.";
           }
         }
         config false;
         description
           "Текущее состояние алгоритма отсрочки SPF (back-off).";
       }
       leaf remaining-time-to-learn {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения time-to-learn.";
       }
       leaf remaining-hold-down {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения hold-down.";
       }
       leaf last-event-received {
         type yang:timestamp;
         config false;
         description
           "Время последнего события-триггера SPF.";
       }
       leaf next-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время следующего запланированного SPF.";
       }
       leaf last-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время последнего расчёта SPF.";
       }
       description
         "Группировка для конфигурации и состояния задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     grouping node-tag-config {
       description
         "Состояние конфигурации тега узла OSPF.";
       container node-tags {
         if-feature "node-tag";
         list node-tag {
           key "tag";
           leaf tag {
             type uint32;
             description
               "Значение тега узла.";
           }
           description
             "Список тегов узлов.";
         }
         description
           "Контейнер для административных тегов узла.";
       }
     }

     grouping instance-config {
       description
         "Состояние конфигурации экземпляра OSPF.";

       leaf enabled {
         type boolean;
         default "true";
         description
           "Включает и выключает протокол.";
       }

       leaf explicit-router-id {
         if-feature "explicit-router-id";
         type rt-types:router-id;
         description
           "Уникальный 32-битовый идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       container preference {
         description
           "Конфигурация предпочтений для маршрутизатора. Во многих
            реализациях называется административной дистанцией.";
         reference
           "RFC 8349: A YANG Data Model for Routing Management
            (NMDA Version)";
         choice scope {
           description
             "Опции выражения предпочтений одним или несколькими
              значениями.";
           case single-value {
             leaf all {
               type uint8;
               description
                 "Предпочтение для внутриобластных, межобластных
                  и внешних маршрутов.";
             }
           }
           case multi-values {
             choice granularity {
               description
                 "Опции для указания предпочтений внутриобластных
                  и межобластных маршрутов.";
               case detail {
                 leaf intra-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри области.";
                 }
                 leaf inter-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов между областями.";
                 }
               }
               case coarse {
                 leaf internal {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри и между 
                      областями.";
                 }
               }
             }
             leaf external {
               type uint8;
               description
                 "Предпочтение для маршрутов внешних AS и NSSA.";
             }
           }
         }
       }

       container nsr {
         if-feature "nsr";
         description
           "Состояние настройки безостановочной маршрутизации (NSR).";
         leaf enabled {
           type boolean;
           description
             "Включает и выключает NSR.";
         }
       }

       container graceful-restart {
         if-feature "graceful-restart";
         description
           "Состояние конфигурации аккуратного перезапуска.";
         reference
           "RFC 3623: Graceful OSPF Restart
            RFC 5187: OSPFv3 Graceful Restart";
         leaf enabled {
           type boolean;
           description
             "Управляет аккуратным перезапуском (RFC 3623 для
              OSPFv2 и RFC 5187 для OSPFv3).";
         }
         leaf helper-enabled {
           type boolean;
           description
             "Включает поддержку помощника при аккуратном перезапуске
              маршрутизаторов (раздел 3 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Section 3";
         }
         leaf restart-interval {
           type uint16 {
             range "1..1800";
           }
           units "seconds";
           default "120";
           description
             "Интервал попыток аккуратного перезапуска (в секундах)
              до отказа (Приложение B.1 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.1";
         }
         leaf helper-strict-lsa-checking {
           type boolean;
           description
             "Прерывает аккуратный перезапуск при смене топологии LSA
              (Приложение B.2 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.2";
         }
       }

       container auto-cost {
         if-feature "auto-cost";
         description
           "Состояние автоматического расчёта стоимости интерфейса.";
         leaf enabled {
           type boolean;
           description
             "Управляет автоматическим расчётом стоимости интерфейса.";
         }
         leaf reference-bandwidth {
           when "../enabled = 'true'" {
             description
               "Применимо лишь при автоматическом расчёте стоимости.";
           }
           type uint32 {
             range "1..4294967";
           }
           units "Mbits";
           description
             "Эталонная пропускная способность для автоматического
              расчёта стоимости интерфейса (Мбит/с). Это значение
              делится на скорость интерфейса и 1 указывает
              минимальную стоимость.";
         }
       }

       container spf-control {
         leaf paths {
           if-feature "max-ecmp";
           type uint16 {
             range "1..65535";
           }
           description
             "Максимальное число равноценных путей (ECMP).";
         }
         container ietf-spf-delay {
           if-feature "ietf-spf-delay";
           uses ietf-spf-delay;
           description
             "Конфигурация алгоритма задержки IETF SPF.";
         }
         description
           "Управление расчётом SPF.";
       }

       container database-control {
         leaf max-lsa {
           if-feature "max-lsa";
           type uint32 {
             range "1..4294967294";
           }
           description
             "Максимальное число OSPF LSA, принимаемых маршрутизатором";
         }
         description
           "Управление поддержкой базы данных.";
       }

       container stub-router {
         if-feature "stub-router";
         description
           "Задаёт конфигурацию максимальной метрики.";

         choice trigger {
           description
             "Триггеры, разрешающие состояние маршрутизатора-заглушки.";
           container always {
             presence "Разрешает безусловную поддержку stub router.";
             description
               "Безусловное состояние stub router (анонсы транзитных
                каналов с MaxLinkMetric).";
             reference
               "RFC 6987: OSPF Stub Router Advertisement";
           }
         }
       }

       container mpls {
         description
           "Состояние конфигурации OSPF MPLS.";
         container te-rid {
           if-feature "te-rid";
           description
             "Стабильный IP-адрес маршрутизатора OSPF для TE.";
           leaf ipv4-router-id {
             type inet:ipv4-address;
             description
               "Явно заданный TE IPv4 Router ID.";
           }
           leaf ipv6-router-id {
             type inet:ipv6-address;
             description
               "Явно заданный TE IPv6 Router ID.";
           }
         }
         container ldp {
           description
             "Состояние конфигурации OSPF MPLS LDP.";
           leaf igp-sync {
             if-feature "ldp-igp-sync";
             type boolean;
             description
               "Включает синхронизацию LDP IGP.";
           }
         }
       }
       uses instance-fast-reroute-config;
       uses node-tag-config;
     }

     grouping instance-state {
       description
         "Рабочее состояние экземпляра OSPF.";

       leaf router-id {
         type rt-types:router-id;
         config false;
         description
           "32-битовый уникальный идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       uses local-rib;

       container statistics {
         config false;
         description
           "Статистика для экземпляра.";
         uses instance-stat;
       }

       container database {
         config false;
         description
           "AS-Scope LSDB.";
         list as-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF AS-Scope LSA.";
           }
           container as-scope-lsas {
             description
               "Все AS-Scope LSA этого типа.";
             list as-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF AS-Scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
       uses spf-log;
       uses lsa-log;
     }

     grouping multi-topology-area-common-config {
       description
         "Базовое состояние конфигурации области OSPF с несколькими 
          топологиями.";
       leaf summary {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет сводными анонсами в топологию тупиковой области
            или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Стоимость для LSA маршрута по умолчанию, анонсируемого 
              в тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводный маршрут по умолчанию для тупиковой области
            или NSSA.";
       }
     }

     grouping multi-topology-area-config {
       description
         "Состояние конфигурации области OSPF с разными топологиями.";

       uses multi-topology-area-common-config;
       uses address-family-area-config;
     }

     grouping multi-topology-state {
       description
         "Рабочее состояние OSPF с несколькими топологиями.";

       uses local-rib;
     }

     grouping multi-topology-interface-config {
       description
         "Состояние конфигурации OSPF с несколькими топологиями.";

       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса для этой топологии.";
       }
     }

     grouping ospfv3-interface-config {
       description
         "Связанное с интерфейсом состояние конфигурации OSPFv3.";

       leaf instance-id {
         type uint8;
         default "0";
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping ospfv3-interface-state {
       description
         "Связанное с интерфейсом рабочее состояние OSPFv3.";

       leaf interface-id {
         type uint32;
         config false;
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping lsa-identifiers {
       description
         "Параметры, однозначно указывающие LSA.";
       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }
       leaf type {
         type uint16;
         description
           "Тип LSA.";
       }
       leaf lsa-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         description
           "Порядковый номер LSA.";
       }
     }

     grouping spf-log {
       description
         "Группировка для журнальных записей SPF (log).";
       container spf-log {
         config false;
         description
           "Контейнер с записями SPF.";
         list event {
           key "id";
           description
             "Список записей SPF в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо внутреннее значение).";
           }
           leaf spf-type {
             type enumeration {
               enum full {
                 description
                   "Расчёт SPF был выполнен для всего SPF.";
               }
               enum intra {
                 description
                   "Расчёт SPF лишь для маршрутов внутри области.";
               }
               enum inter {
                 description
                   "Расчёт SPF для сводных маршрутов между областями.";
               }
               enum external {
                 description
                   "Расчёт SPF лишь для маршрутов внешних AS и NSSA.";
               }
             }
             description
               "Расчёт SPF лишь для для записи журнала SPF.";
           }
           leaf schedule-timestamp {
             type yang:timestamp;
             description
               "Временная метка для запланированного расчёта.";
           }
           leaf start-timestamp {
             type yang:timestamp;
             description
               "Временная метка начала расчёта.";
           }
           leaf end-timestamp {
             type yang:timestamp;
             description
               "Временная метка завершения расчёта.";
           }
           list trigger-lsa {
             description
               "Список LSA, вызвавших расчёт.";
             uses lsa-identifiers;
           }
         }
       }
     }

     grouping lsa-log {
       description
         "Группировка для системного журнала LSA (log).";
       container lsa-log {
         config false;
         description
           "Контейнер со списком записей журнала LSA, включая локальные
            изменения LSA.";
         list event {
           key "id";
           description
             "Список записей LSA в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо локальное значение).";
           }
           container lsa {
             description
               "Контейнер, описывающий LSA, записанные в журнал.";
             uses lsa-identifiers;
           }
           leaf received-timestamp {
             type yang:timestamp;
             description
               "Временная метка получения LSA. При локальном обновлении
                LSA это будет время создания LSA.";
           }
           leaf reason {
             type identityref {
               base lsa-log-reason;
             }
             description
               "Причина внесения записи в журнал LSA.";
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol" {
       when "derived-from(rt:type, 'ospf')" {
         description
           "Это дополнение пригодно лишь для экземпляра протокола
            маршрутизации OSPF (типа ospfv2 или ospfv3).";
       }
       description
         "Дополнение OSPF control-plane-protocol для модуля 
          ietf-routing.";

       container ospf {
         description
           "Экземпляр протокола OSPF.";

         leaf address-family {
           when "derived-from-or-self(../../rt:type, 'ospfv3')" {
             description
               "Применимо только для OSPFv3.";
           }
           type iana-rt-types:address-family;
           description
             "Семейство адресов для экземпляра.";
         }

         uses instance-config;
         uses instance-state;

         container areas {
           description
             "Все области OSPF.";
           list area {
             key "area-id";
             description
               "Список областей OSPF.";
             leaf area-id {
               type area-id-type;
               description
                 "Area ID.";
             }

             uses area-config;
             uses area-state;

             container virtual-links {
               when "derived-from-or-self(../area-type, 'normal-area') "
                  + "and ../area-id = '0.0.0.0'" {
                 description
                   "Виртуальные каналы должны быть в магистральной 
                    (backbone) области.";
               }
               description
                 "Все виртуальные каналы.";
               list virtual-link {
                 key "transit-area-id router-id";
                 description
                   "Виртуальный канал OSPF.";
                 leaf transit-area-id {
                   type leafref {
                     path "../../../../area/area-id";
                   }
                   must "derived-from-or-self("
                      + "../../../../area[area-id=current()]"
                      + "/area-type, 'normal-area') and "
                      + "../../../../area[area-id=current()]"
                      + "/area-id != '0.0.0.0'" {
                     error-message "Транзитной области виртуального "
                             + "канала недопустимо быть магистральной.";
                     description
                       "Транзитной области виртуального канала 
                        недопустимо быть магистральной (0.0.0.0).";
                   }
                   description
                     "Идентификатор транзитной области виртуального 
                      канала.";
                 }
                 leaf router-id {
                   type rt-types:router-id;
                   description
                     "Router ID удалённой конечной точки виртуального
                      канала.";
                 }

                 uses virtual-link-config;
                 uses virtual-link-state;
               }
             }
             container sham-links {
               if-feature "pe-ce-protocol";
               description
                 "Все фиктивные (sham) каналы.";
               list sham-link {
                 key "local-id remote-id";
                 description
                   "Фиктивный канал OSPF.";
                 leaf local-id {
                   type inet:ip-address;
                   description
                     "Адрес локальной конечной точки фиктивного канала";
                 }
                 leaf remote-id {
                   type inet:ip-address;
                   description
                     "Адрес удалённой конечной точки фиктивного канала";
                 }
                 uses sham-link-config;
                 uses sham-link-state;
               }
             }
             container interfaces {
               description
                 "Все интерфейсы OSPF.";
               list interface {
                 key "name";
                 description
                   "Список интерфейсов OSPF.";
                 leaf name {
                   type if:interface-ref;
                   description
                     "Ссылка на имя интерфейса.";
                 }
                 uses interface-config;
                 uses interface-state;
               }
             }
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf" {
       when "derived-from(../rt:type, 'ospf')" {
         description
           "Это дополнение действительно лишь для OSPF
            (тип ospfv2 или ospfv3).";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации экземпляра OSPF
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии.";
         list topology {
           key "name";
           description
             "Топология OSPF. Семейство адресов топологии OSPF 
              должно совпадать с семейством экземпляра маршрутизации.";
           leaf name {
             type leafref {
               path "../../../../../../rt:ribs/rt:rib/rt:name";
             }
             description
               "Имя таблицы RIB, соответствующей топологии OSPF.";
           }

           uses multi-topology-state;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area" {
       when "derived-from-or-self(../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации области OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для области.";
         list topology {
           key "name";
           description
             "Топология области OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этой области.";
           }

           uses multi-topology-area-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации интерфейса OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для интерфейса.";
         list topology {
           key "name";
           description
             "Топология для интерфейса OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этого интерфейса.";
           }

           uses multi-topology-interface-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv3')" {
         description
           "Это дополнение действительно лишь для OSPFv3.";
       }
       description
         "Дополнение состояния конфигурации OSPFv3, связанной 
          с интерфейсом.";
       uses ospfv3-interface-config;
       uses ospfv3-interface-state;
     }

     grouping route-content {
       description
         "Эта группировка определяет атрибуты маршрута,
          связанные с OSPF.";
       leaf metric {
         type uint32;
         description
           "Метрика маршрута OSPF.";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Тег маршрута OSPF.";
       }
       leaf route-type {
         type route-type;
         description
           "Тип маршрута OSPF.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
       when "derived-from(rt:source-protocol, 'ospf')" {
         description
           "Это дополнение действительно лишь для маршрутов,
            полученных от протокола OSPF.";
       }
       description
         "Связанные с OSPF атрибуты маршрута.";
       uses route-content;
     }

     /*
      * RPC
      */

     rpc clear-neighbor {
       description
         "Этот вызов RPC очищает указанный набор соседей OSPF.
          При отказе по внутренним причинам OSPF следует возвращать
          error-tag и error-app-tag, соответствующие ошибке.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }

         leaf interface {
           type if:interface-ref;
           description
             "Имя экземпляра OSPF, для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag ospf-interface-not-found.";
         }
       }
     }

     rpc clear-database {
       description
         "Этот вызов RPC очищает указанную базу OSPF Link State. Кроме 
          того, все отношения соседства переводятся в состояние DOWN,
          а самосозданные LSA реорганизуются. При отказе операции по
          внутренним причинам OSPF следует указывать причину в error-tag
          и error-app-tag.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF, для которого очищается LSDB.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }
       }
     }

     /*
      * Уведомления
      */

     grouping notification-instance-hdr {
       description
         "Группировка с описаниями связанных с экземпляром общих
          уведомления OSPF.";

       leaf routing-protocol-name {
         type leafref {
           path "/rt:routing/rt:control-plane-protocols/"
              + "rt:control-plane-protocol/rt:name";
         }
         must "derived-from( "
            + "/rt:routing/rt:control-plane-protocols/"
            + "rt:control-plane-protocol[rt:name=current()]/"
            + "rt:type, 'ospf')";
         description
           "Имя экземпляра протокола маршрутизации OSPF.";
       }

       leaf address-family {
         type leafref {
           path "/rt:routing/"
              + "rt:control-plane-protocols/rt:control-plane-protocol"
              + "[rt:name=current()/../routing-protocol-name]/"
              + "ospf/address-family";
         }
         description
           "Семейство адресов экземпляра OSPF.";
       }
     }

     grouping notification-interface {
       description
         "Группировка для сведений об интерфейсе в связанных с
          интерфейсами уведомлениях OSPF.";

       choice if-link-type-selection {
         description
           "Варианты типов канала.";
         container interface {
           description
             "Обычный интерфейс.";
           leaf interface {
             type if:interface-ref;
             description
               "Интерфейс.";
           }
         }
         container virtual-link {
           description
             "Виртуальный канал.";
           leaf transit-area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
         }
         container sham-link {
           description
             "Фиктивный канал.";
           leaf area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf local-ip-addr {
             type inet:ip-address;
             description
               "Локальный адрес фиктивного канала.";
           }
           leaf remote-ip-addr {
             type inet:ip-address;
             description
               "Удаленный адрес фиктивного канала.";
           }
         }
       }
     }

     grouping notification-neighbor {
       description
         "Группировка для сведений о соседе в связанных
          с соседями уведомлениях.";

       leaf neighbor-router-id {
         type rt-types:router-id;
         description
           "Router ID соседа.";
       }

       leaf neighbor-ip-addr {
         type inet:ip-address;
         description
           "Адрес соседа.";
       }
     }

     notification if-state-change {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf state {
         type if-state-type;
         description
           "Состояние интерфейса.";
       }
       description
         "Это уведомление передаётся при обнаружении
          смены состояния интерфейса.";
     }

     notification if-config-error {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       leaf error {
         type enumeration {
           enum bad-version {
             description
               "Непригодня версия.";
           }
           enum area-mismatch {
             description
               "Несоответствие областей.";
           }
           enum unknown-nbma-nbr {
             description
               "Неизвестный сосед NBMA.";
           }
           enum unknown-virtual-nbr {
             description
               "Неизвестный сосед по виртуальному каналу.";
           }
           enum auth-type-mismatch {
             description
               "Несоответствие типа аутентификации.";
           }
           enum auth-failure {
             description
               "Отказ при аутентификации.";
           }
           enum net-mask-mismatch {
             description
               "Несоответствие маски сети.";
           }
           enum hello-interval-mismatch {
             description
               "Несоответствие интервала Hello.";
           }
           enum dead-interval-mismatch {
             description
               "Несоответствие интервала Dead.";
           }
           enum option-mismatch {
             description
               "Несоответствие опций.";
           }
           enum mtu-mismatch {
             description
               "Несоответствие MTU.";
           }
           enum duplicate-router-id {
             description
               "Дубликат Router ID.";
           }
           enum no-error {
             description
               "Нет ошибок.";
           }
         }
         description
           "Коды ошибок.";
       }
       description
         "Это уведомление передаётся при получении пакета, указывающего
          ошибку настройки интерфейса передающего маршрутизатора OSPF.";
     }

     notification nbr-state-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf state {
         type nbr-state-type;
         description
           "Состояние соседа.";
       }

       description
         "Это уведомление передаётся при обнаружении смены состояния
          соседа.";
     }

     notification nbr-restart-helper-status-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf status {
         type restart-helper-status-type;
         description
           "Состояние помошника в перезапуске.";
       }

       leaf age {
         type rt-types:timer-value-seconds16;
         description
           "Оставшееся время текущего интервала аккуратного перезапуска
            OSPF, когда маршрутизатор служит помощником для соседа.";
       }

       leaf exit-reason {
         type restart-exit-reason-type;
         description
           "Причина завершения помощника при перезапуске.";
       }
       description
         "Это уведомление передаётся при обнаружении смены состояния
          помощника при перезапуске соседа.";
     }

     notification if-rx-bad-packet {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       description
         "Это уведомление передаётся при невозможности анализа пакета
          OSPF, принятого на интерфейсе OSPF.";
     }

     notification lsdb-approaching-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит 90% от предела ext-lsdb-limit.";
     }

     notification lsdb-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит предел ext-lsdb-limit.";
     }

     notification nssa-translator-status-change {
       uses notification-instance-hdr;

       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }

       leaf status {
         type nssa-translator-state-type;
         description
           "Состояние транслятора NSSA.";
       }

       description
         "Это уведомление передаётся при смене роли маршрутизатора в
          трансляции OSPF NSSA-LSA в OSPF AS-External-LSA.";
     }

     notification restart-status-change {
       uses notification-instance-hdr;

       leaf status {
         type restart-status-type;
         description
           "С