Энциклопедия сетевых протоколов

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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 при подготовке своего предложения.

Адрес автора

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

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

nmalykh@protokols.ru

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 и публикуется для информации.

Документ является результатом работы IRTF¹. 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|², |1⟩ — |b|², где |a|² + |b|² = 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.

Рассмотрим применение вентиля 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]

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

В источнике

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

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

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

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. Классическая сигнализация и поколения обработки ошибок.

Поколения определяются направлениями классической сигнализации, требуемой распределенными протоколами для устойчивости к потерям и ошибкам. Классическая сигнализация передаётся обычными битами, что вносит задержки кругового обхода. Как указано в параграфе 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. участие в управлении сетью (маршрутизация и т. п.).

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

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

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

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

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

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

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

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

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

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»,² 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»,³ 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»,⁴ 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»,⁵ 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»,⁶ 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»,⁷ 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»,⁸ 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»,⁹ 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»,¹⁰ 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»,¹¹ 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»,¹² 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»,¹³ 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»,¹⁴ 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»,¹⁵ 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»,¹⁶ 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»,¹⁷ 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»,¹⁸ 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»,¹⁹ 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»,²⁰ 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»,²¹ 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»,²² 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»,²³ 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»,²⁴ 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»,²⁵ 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»,²⁶ 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»,²⁷ 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»,²⁸ 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»,²⁹ 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»,³⁰ 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»,³¹ 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»,³² 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»,³³ 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»,³⁴ 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»,³⁵ 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»,³⁶ 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»,³⁷ 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»,³⁸ 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»,³⁹ 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»,⁴⁰ 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»,⁴¹ 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»,⁴² 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»,⁴³ 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»,⁴⁴ 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?»,⁴⁵ 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»,⁴⁶ 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»,⁴⁷ 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»,⁴⁸ 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»,⁴⁹ 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»,⁵⁰ 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.

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

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

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

nmalykh@protokols.ru

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 и публикуется лишь для информации.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные 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 — 2³²-1, значения 0 и 4294967295 (2³²-1) являются резервными. Отметим, что в исходном определении PEN не была задана верхняя граница, но позднее её внесли, поскольку протоколы IETF ограничивают размер этих значений. Например, протокол Diameter [RFC6733] ограничивает значения величиной 2³²-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.

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

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

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

nmalykh@protokols.ru

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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)

Flex-Algorithm

Flexible Algorithm Participation

IGP Algorithm

ABR

ASBR

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

Length

Flex-Algorithm

Metric-Type

0

1

2

Calc-Type

Priority

Sub-TLVs

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

Length

Flex-Algorithm

Metric-Type

0

1

2

Calc-Type

Priority

Sub-TLVs

При получении нескольких 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

Length

Extended Administrative Group

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

Length

Extended Administrative Group

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

Length

Extended Administrative Group

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

Length

Flags

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

M

Задан новый реестр 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

Length

Shared Risk Link Group Value

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

Length

Extended Administrative Group

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

Length

Extended Administrative Group

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

Length

Extended Administrative Group

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

Length

Flags

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

M

Задан новый реестр 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

Length

Shared Risk Link Group Value

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

Length

Flex-Algorithm

Metric

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

Length

Flex-Algorithm

Flags

                       0 1 2 3 4 5 6 7
                      +-+-+-+-+-+-+-+-+
                      |E|             |
                      +-+-+-+-+-+-+-+-+

E

Биты 1 — 7

Reserved

Metric

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

Length

ASBR Router ID

Sub-TLVs

В каждом анонсе 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

Length

Flex-Algorithm

Reserved

Metric

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 (2²⁴ -1).

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику TE, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA TE для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение метрики TE (2²⁴ — 1) в IS-IS и (2³² — 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 может потребовать пересчёта SPF⁴ в масштабе сети и повторного схождения. Это следует учитывать при планировании и внесении изменений в 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.

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.

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.

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.

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.

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.

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

18.4.1. Реестр OSPF Router Information (RI) TLVs

Этот документ вносит указанную в таблице 7 запись в реестр OSPF Router Information (RI) TLVs.

Таблица 7. Реестр OSPF Router Information (RI) TLVs.

18.4.2. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs

Этот документ вносит указанную в таблице 8 запись в реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

Таблица 8. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

18.4.3. Реестр OSPFv3 Extended-LSA Sub-TLVs

Этот документ вносит указанные в таблице 9 записи в реестр OSPFv3 Extended-LSA Sub-TLVs.

Таблица 9. Реестр OSPFv3 Extended-LSA Sub-TLVs.

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.

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.

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.

Значения 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.

Значения 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.

Значения 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.

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

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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 и SRv6³. Они включают расширения для анонсирования сведений 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

Length

Flexible Algorithm (Flex Algo)

Metric-Type

Calc-Type

Priority

Sub-TLVs

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

Length

Exclude-Any EAG

Информация 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

Length

Include-Any EAG

Информация 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

Length

Include-All EAG

Информация 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

Length

Flags

Информация 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

Length

Shared Risk Link Group Values

Информация 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

Length

Protocol-ID

sub-TLV types

Узел, создающий анонс, должен включать 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

Length

Flexible Algorithm (Flex Algo)

Flags

Reserved

Metric

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 для гибких алгоритмов.

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 и предложения по улучшению документа.

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

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

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

nmalykh@protokols.ru

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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 для пути.

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

Контроль перегрузки

Настройка фиксированной скорости

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

Рабочие данные 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

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

../iptfs-inner-pkt-stats и ../iptfs-outer-pkt-stats

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.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                    K. De Schepper
Request for Comments: 9332                               Nokia Bell Labs
Category: Experimental                                   B. Briscoe, Ed.
ISSN: 2070-1721                                              Independent
                                                                G. White
                                                               CableLabs
                                                            January 2023

Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)

Двойные связанные очереди для L4S

PDF

Аннотация

Эта спецификация определяет модель связывания алгоритмов активного управления очередями (Active Queue Management или AQM) в 2 очереди, предназначенные для потоков с разными откликами на перегрузку. Это обеспечивает для Internet способ перехода от стандартных (классических) алгоритмов TCP-Reno-friendly, которым присущи проблемы масштабирования к расширяемому (Scalable) контролю перегрузок. Это предназначено для стабильного обеспечения очень малой задержки в буферах, очень низких потерь и расширяемости пропускной способности на уровне потоков за счёт изменённого использования явных уведомлений о перегрузке (Explicit Congestion Notification или ECN). До внедрения связанных двойных очередей (Coupled Dual Queue или DualQ) элементы Scalable L4S могут быть внедрены лишь там, где можно начать работу «с чистого листа», например в частных центрах обработки данных (ЦОД).

Эта спецификация сначала объясняет, как работает Coupled DualQ, затем задаются нормативные требования. Это не зависит от применяемых конкретных AQM и в приложениях приведены примеры псевдокода.

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

Документ не относится к категории Internet Standards Track и публикуется для проверки, экспериментальной реализации и оценки.

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

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

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

Авторские права (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. Введение

Этот документ задаёт модель механизмов DualQ Coupled AQM, которые могут служить сетевой частью архитектуры L4S [RFC9330]. DualQ Coupled AQM включает 2 очереди — L4S и Classic. Очередь L4S предназначена для расширяемого контроля перегрузок и может одновременно обеспечивать очень низкие задержки (доли миллисекунд а среднем) и высокую пропускную способность. Coupled DualQ действует как полупроницаемая мембрана, изолируя очередь L4S с очень малой задержкой от классической очереди при этом сохраняя связь между очередями для объединения пропускной способности так, что произвольное число приложений, которым нужна пропускная способность, получают примерно эквивалентную пропускную способность на уровне потока независимо от используемой очереди. DualQ обеспечивает это опосредованно без необходимости просматривать идентификаторы потоков на транспортном уровне и без ущерба для классического трафика применительно к одной очереди. Устройство DualQ отличается простотой и не требует настройки для общедоступной сети Internet.

1.1. Постановка задачи

Задержки становятся критически важным фактором производительности для многих (возможно, большинства) приложений Internet, например, интерактивных web-приложений и служб, передачи, видео со звуком, интерактивного видео, удалённого присутствия, мгновенного обмена сообщениями, сетевых игр, удалённых рабочих столов, облачных приложений и служб, а также удалённого управления оборудованием и производственными процессами. при достижении в сетях доступа скоростей, распространённых сегодня в развитых странах, повышение пропускной способности канала ведёт к снижению скорости отдачи, если проблема задержки не решена. [Dukkipati06]. В последнее десятилетие или около того было многое сделано для сокращения времени распространения за счёт кэширования и переноса серверов ближе к пользователям. Однако очереди остаются основным, хотя и меняющимся компонентом задержки.

Ранее малые задержки были доступны лишь для немногих избранных низкоскоростных приложений, которые ограничивают скорость отправки специально выделенной долей пропускной способности, имеющей более высокий по отношению к другому трафику приоритет, например, ускоренная пересылка Diffserv (Expedited Forwarding или EF) [RFC3246]. До сих пор не было возможности предоставить любому приложению, которому нужны малые задержки и высокая пропускная способность, стремиться полностью использовать доступные возможности, поскольку процессы поиска высокой пропускной способности сами вносили слишком большие задержки в очередях.

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

• Новейшие механизмы AQM в сети, например, Flow Queue CoDel [RFC8290], PIE³ [RFC8033], ARED⁴ [ARED01]), позволяют сократить задержку в очередях для всего трафика, а не только для нескольких избранных приложений. Однако, независимо от возможностей AQM, (пилообразная) скорость поиска пропускной способности механизмов контроля перегрузок в стиле TCP задаёт нижний предел, по достижении которого начинаются вариации задержки или недогрузка канала. Эти механизмы AQMs настроены так, чтобы типичный поток TCP-Reno-friendly с поиском пропускной способности вносил среднюю задержку приблизительно в 2 интервала кругового обхода (round-trip time или RTT), добавляя в среднем 5-15 мсек ожидания в очереди для сочетания долгосрочных потоков и трафика web (сравн. с 500 мксек для L4S при таком же сочетании трафика [L4Seval22]). Однако для многих приложений малая задержка бесполезна, если она не является стабильно низкой. При использовании этих механизмов AQM задержка в очередях при 99-м процентиле составляет 20-30 мсек (сравн. с 2 мсек для такого же трафика в L4S).

• Недавние исследования сквозного контроля перегрузок без необходимости применения AQM в сети (например, BBR⁵ [BBR-CC]) показали аналогичный минимум задержки около 20 мсек в среднем, наряду с регулярными всплесками в 25 мсек из-за зондирования пропускной способности и 60 мсек в результате замедленного старта.

L4S использует уроки Data Center TCP (DCTCP) [RFC8257], показавшего мощь взаимодополняющих изменений в сети и конечных системах. DCTCP показал необходимость двух незначительных, но радикальных изменений контроля перегрузок, которые требуются для устранения двух основных сохраняющихся причин изменчивости задержки в очередях.

1. Значительно меньшие чем в Reno вариации скорости (зубья пилы — sawteeth) в системе контроля перегрузок.

2. Перенос сглаживания (и связанной с ним задержки) из сети к отправителям.

Без п. 1 RTT классических потоков (например, Reno-friendly) составляет приблизительно от 1 до 2 базовых значение RTT между рассматриваемыми машинами. Без п. 2 реакция классического потока на изменяющиеся события задерживается в худшем случае на величину (трансконтинентального) RTT, которая может в сотни раз превышать фактическую задержку на сглаживание, требуемую для RTT типового трафика из локализованных сетей доставки содержимого (Content Delivery Network или CDN).

Эти изменения являются двумя основными свойствами так называемого расширяемого (Scalable) контроля перегрузок (DCTCP, Prague, SCReAM⁶). Оба изменения сокращают задержку лишь в сочетании с полным изменением в сети и оба доступны только при использовании ECN (а не отбрасывания) для сигнализации.

1. Сокращение размера зубьев пилы обеспечивает очень низкий порог маркировки ECN для пакетов в очереди.

2. Отсутствие сглаживания в сети означает незамедлительную сигнализацию о каждой флуктуации очереди.

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

Однако до настоящего времени масштабируемые элементы контроля перегрузки (например, DCTCP) не совмещались с общей очередью с поддержкой ECN и существующими классическими методами контроля перегрузок (например, Reno [RFC5681] или CUBIC [RFC8312]). Расширяемые средства контроля перегрузок настолько энергичны, что классические алгоритмы приходят в состояние самоограничения пропускной способности. Поэтому до настоящего времени элементы L4S можно было внедрять лишь там, где возможно создание среды «с нуля», например, в частных ЦОД (отсюда и название DCTCP).

Одним из способов обеспечить сосуществование классических и масштабируемых потоков является использование очередей по потокам (per-flow-queuing или FQ), как в FQ-CoDel [RFC8290]. При таком подходе пакеты классифицируются по идентификаторам потоков для изоляции разреженных (sparse) потоков от очередей в нагруженных потоках с большой задержкой. Однако для классических потоков, которым нужна сразу малая задержка и высокая пропускная способность, наличие отдельной очереди не избавляет от вреда, который поток наносит сам себе. Кроме того, для FQ требуется просмотр идентификаторов потоков, что не всегда приемлемо на практике.

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

1.2. Контекст, область действия и применимость

L4S предполагает внесение изменений в сеть и конечные системы

Сеть

Конечная система

Идентификатор пакета

DCTCP [RFC8257] является примером расширяемого контроля перегрузок для контролируемых сред и уже применяется некоторое время в ОС Linux, Windows, FreeBSD. В процессе прохождения этого документа через IETF было реализовано множество других элементов расширяемого контроля перегрузок, например, Prague для TCP и QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], L4S-вариант SCReAM для работы в реальном масштабе времени [SCReAM-L4S] [RFC8298].

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

Модель DualQ Coupled AQM позволяет включать любые механизмы AQM, разработанные для одной очереди и обеспечивающие статистическую или детерминированную вероятность маркировки/отбрасывания, определяемую динамикой очереди. В Приложениях даны примеры двух разных DualQ Coupled AQM. Во многих случаях модель упрощает базовый алгоритм контроля и требует меньше дополнительной обработки. Поэтому предполагается, что Coupled AQM подойдёт для широкого внедрения на всех типах буферов, таких как буферы в массовом недорогом домашнем оборудовании, стеках конечных систем, оборудовании операторского класса, включая серверы доступа, маршрутизаторы, межсетевые экраны и коммутаторы Ethernet, буферы в сетевых адаптерах, виртуализованных сетевых устройствах, гипервизорах и т. д.

Для общедоступной сети Internet почти все преимущества обычно будут достигаться развёртыванием Coupled AQM на любой стороне канала доступа между сайтом и Internet, который всегда является узким местом (см. параграф 6.4 в [RFC9330], где рассматривается внедрение, а также определён термин «сайт» как дом, офис, кампус или мобильное оборудование пользователя).

Задержки не являются единственным вопросом L4S.

• Часть названия Low Loss (малые потери) означает, что L4S обычно обеспечивает нулевые потери при перегрузке (иначе будут возникать задержки, связанные с повтором передачи) в результате применения ECN.

• Часть названия Scalable throughput (масштабируемая пропускная способность) означает, что пропускной способности на уровне потока при расширяемом контроле перегрузок следует расширяться без ограничений, избегая неизбежных проблем масштабирования в алгоритмах TCP-Friendly [RFC3649].

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

В описании архитектуры L4S [RFC9330] приведено больше деталей, включая более широкое рассмотрение совместимости расширяемого контроля перегрузок с прежними версиями в узких местах, где не развернут DualQ Coupled AQM. В статьях [L4Seval22], [DualPI2Linux], [PI2] и [PI2param] приведено полное обоснования устройства AQM как текстом, такие в более точной математической форме, а также указаны результаты оценки производительности. Основные результаты были независимо проверены с использованием контроля перегрузки Prague [Boru20] (эксперименты проводились с Prague и DCTCP, но для проверки подходит лишь первый вариант, поскольку в Prague решён ряд проблем Linux DCTCP, которые делают этот протокол непригодным для общедоступной сети Internet).

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

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

DualQ Coupled AQM использует 2 очереди для двух служб.

Classic Service/Queue — классическая служба/очередь

Low Latency, Low Loss, and Scalable throughput (L4S) Service/Queue — служба/очередь с малыми задержками и потерями, в также расширяемой пропускной способностью (L4S)

Classic Congestion Control — классический контроль перегрузок

Scalable Congestion Control — расширяемый контроль перегрузок

C

L

Reno-friendly — совместимость с Reno

DualQ или DualQ AQM

Classic ECN — классический ECN

1.4. Свойства

AQM связывает маркировку и/или отбрасывание в классической очереди с очередью L4S, чтобы поток получал примерно равную пропускную способность, независимо от применяемого механизма. Поэтому обеим очередям доступна полная пропускная способность канала и для очередей не нужно настраивать скорости. Очередь L4S позволяет расширяемому контролю перегрузок, таком как DCTCP или Prague, обеспечивать постоянно очень малую задержку без ущерба для производительности «классического» трафика Internet.

Были выполнены тысячи тестов при типовых настройках широкополосного домашнего доступа. В экспериментах использовался диапазон базового RTT до 100 мсек и скорость канала до 200 Мбит/с между ЦОД и домашней сетью с разным объёмом фонового трафика в обеих очередях. Для каждого пакета L4S механизм AQM сохранял среднюю задержку менее 1 мсек (или 2 пакетов, если задержка сериализации на медленном канале превышала 1 мсек) и не хуже 2 мсек при 99-м процентиле. Потерь в L4S AQM не возникало совсем. Детали экспериментов приведены в [L4Seval22] и [DualPI2Linux]. Субъективное тестирование с использованием очень требовательных к задержке и пропускной способности приложений через 1 общий канал доступа также описано в [L4Sdemo16] и обобщено в параграфе 6.1 описания архитектуры L4S [RFC9330].

Во всех этих экспериментах хост был подключён к домашней сети кабелем Ethernet, чтобы пользователь мог оценить возможную задержку в очередях. Следует подчеркнуть, что поддержка L4S в узком месте не может «отменить» задержки, внесённые на других каналах пути, например, в устаревшем оборудовании Wi-Fi. Однако при добавлении поддержки L4S в очереди, обслуживающей выходной канал WAN на домашнем шлюзе было бы контрпродуктивно не сократить всплески трафика на входящих соединениях Wi-Fi. Кроме того, продолжаются испытания оборудования Wi-Fi с L4S DualQ Coupled AQM на выходном интерфейсе Wi-Fi и первые результаты оценки L4S DualQ Coupled AQM в тестовой сети радиодоступа 5G с эмуляцией радиосигнала на внешнем (уличном) краю ячейки приведены в [L4S_5G].

В отличие от Diffserv EF, очередь L4S для получения малой задержки необязательно ограничивать небольшой долей пропускной способности канала. Очередь L4S может заполняться большим числом потоков, которым нужна пропускная способность (Prague, BBRv2 и т. п.), сохраняя при этом малую задержку. Очередь L4S не полагается на наличие другого трафика в классической очереди, который можно вытеснить (overtaken). Это обеспечивает малые задержки для трафика L4S независимо от наличия классического трафика. Задержка в хвосте для трафика, обслуживаемого Classic AQM, может немного меняться при наличии трафика L4S.

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

• Большие вариации (пила) классических потоков требуют для полной загрузки канала задержки примерно в размере базового RTT.

• Расширяемым потокам не требуется очередь для сохранения загрузки канала, но они не могут сохранять достаточно малую задержку при наличии также классического трафика.

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

2. DualQ Coupled AQM

Ниже указаны 2 основных аспекта подхода DualQ Coupled AQM.

1. Механизм Coupled AQM обеспечивающий эквивалентность классических (например, Reno или CUBIC) и L4S потоков (соответствуют требованиям Prague L4S).

2. Структура Dual-Queue, обеспечивающая отделение потоков L4S для их изоляции от обычно большой классической очереди.

2.1. Coupled AQM

В 1990-х годах была выведена «формула TCP», связывающая установившееся окно перегрузки cwnd и вероятность отбрасывания p стандартного контроля перегрузок Reno [RFC5681]. В качестве первого приближения можно считать cwnd для Reno обратно пропорциональным квадратному корню от p.

Решение ориентировано на Reno к качестве худшего варианта, поскольку при отсутствии ущерба для Reno его не будет и для CUBIC и иного трафика, совместимого с Reno. TCP CUBIC реализует режим совместимости с Reno, который актуален для типичных RTT менее 20 мсек, пока пропускная способность одного потока меньше приблизительно 350 Мбит/с. В таких случаях можно предполагать, что трафик CUBIC ведёт себя аналогично Reno. Термин «классический» применяется для совместимого с Reno трафика, включая CUBIC и, возможно, другие механизмы контроля перегрузок, предназначенные для того, чтобы не влиять сильно на скорость потока Reno.

В статье [PI2] выведено уравнение эквивалентной скорости для DCTCP, в котором значение cwnd обратно пропорционально вероятности ECN-маркировки p (а не квадратному корню). DCTCP — не единственный механизм контроля перегрузок, который ведёт себя подобным образом, поэтому термин «расширяемый» (Scalable) используется для всех похожих вариантов поведения контроля перегрузки (см. примеры в ). Термин L4S применяется для трафика, управляемого расширяемым контролем перегрузки, который соответствует также требованиям Prague L4S [RFC9331].

Для безопасного сосуществования в стационарных условиях масштабируемый поток должен работать примерно с той же скоростью, что и поток Reno TCP (при прочих равных условиях). Поэтому вероятность отбрасывания или маркировки для классического трафика (p_C) должна отличаться от вероятности маркировки для трафика L4S (p_L). Исходная спецификация ECN [RFC3168] требовала, чтобы вероятности отбрасывания и маркировки были одинаковы, но [RFC8311] обновляет [RFC3168], разрешая эксперименты с разными вероятностями.

Для сохранения стабильности классическим источникам нужно сглаживание p_C в сети, чтобы изменения были достаточно медленными. Сетевому узлу сложно знать RTT для всех потоков, поэтому AQM добавляет задержку сглаживания для худшего RTT (100-200 мсек). L4S переносит ответственность за сглаживание откликов ECN на источник, который задерживает реакции лишь по своему значению RTT, что позволяет реагировать быстрее.

Coupled AQM обеспечивает безопасное сосуществование дела вероятность классического отбрасывания p_C пропорциональной квадрату привязанной вероятности L4S p_CL. Значение p_CL является входом для вероятности мгновенной маркировки L4S p_L, но меняется так же медленно, как p_C. Это делает скорость потока Reno примерно равной скорости потока DCTCP, поскольку возведение p_CL в квадрат уравновешивается квадратным корнем из p_C в «формуле TCP» классического контроля перегрузок Reno.

Связь между вероятностью классического отбрасывания p_C и привязанной вероятностью L4S p_CL выражается как

       p_C = ( p_CL / k )^2,                 (1)

где k — коэффициент пропорциональности, называемый фактором связывания (coupling factor).

2.2. Двойная очередь

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

2.3. Классификация трафика

Механизмам Coupled AQM и DualQ нужен идентификатор, чтобы отличать пакеты L4S (L) от классических (C). Тогда алгоритм связывания может обеспечить сосуществование пакетов без необходимости просмотра идентификаторов потоков, имея возможность применять маркировку и отбрасывание ко всем потокам каждого типа. Спецификация [RFC9331] требует от сети обработки кодов ECT(1) и CE в поле ECN как таких идентификаторов. Потребовалось создать отдельный документ [RFC8311], разрешивший особую обработку кода ECT(1) в экспериментах.

По соображениям политики оператор может предпочесть вывод отдельных пакетов (например, для некоторых потоков по отдельным адресам) из очереди L, даже если они идентифицированы как L4S кодом ECN. Для таких случаев протокол L4S ECN [RFC9331] говорит, что устройству «недопустимо менять сквозной идентификатор L4S ECN». Цель заключается в обеспечении каждому оператору возможности локальной трактовки трафика L4S, но без возможности изменить идентификацию пакетов L4S, что помешало бы другим операторам нисходящего направления принимать своё решение по обработке трафика L4S.

Кроме того, оператор мог бы применять иные идентификаторы для отнесения неких дополнительных типов пакетов к очереди L, если это по мнению оператора не нарушит работу службы L4S. Например, можно выбирать пакеты по адресам конкретных приложений или хостов, кодам Diffserv, таким как EF, Voice-Admit, поэтапное поведение NQB⁸, некоторые протоколы (например, ARP и DNS), как указано в параграфе 5.4.1 [RFC9331]. Отметим, что в [RFC9331] сказано: «узлу сети недопустимо менять код Not-ECT или ECT(0) в поле IP-ECN на идентификатор L4S». Таким образом, очередь L не является исключительно L4S и может рассматриваться просто как очередь с малой задержкой.

2.4. Общая структура DualQ Coupled AQM

На рисунке показана общая структура, которую, вероятно, будет иметь любой механизм DualQ Coupled AQM. Эта схема приведена для облегчения понимания устройства современных DualQ Coupled AQM. Однако она не исключает других вариантов выполнения требований параграфа 2.5, минимально задающих DualQ Coupled AQM. Схема иллюстрирует лишь поведение в обычных условиях, а работа при перегрузке или с заданными оператором классификаторами описана в параграфе 2.5.1.1.

Классификатор слева разделяет входящий трафик между очередями L и C, каждая из которых имеет свой механизм AQM, определяющий вероятность маркировки или отбрасывания (p_L и p_C). В [PI2] было доказано, что предпочтительней управлять нагрузкой с помощью линейного контроллера, затем возводить результат в квадрат до использования в качестве вероятности для трафика Reno-friendly (поскольку контроль перегрузок Reno снижает нагрузку пропорционально квадратному корню увеличения вероятности отбрасывания). Поэтому AQM для классического трафика нужно реализовать в 2 этапа: i) базовое определение внутренней вероятности p’ (произносится p-prime) и ii) извлечение квадратного корня, дающего p_C, т. е.

       p_C = (p')^2.                         (2)

Подстановка вместо p_C в уравнение (1) даёт

       p' = p_CL / k

Таким образом, медленно меняющийся ввод маркировки ECN в очередь L (связанная вероятность L4S) имеет вид

       p_CL = k*p'                          (3)

Фактическая вероятность ECN-маркировки p_L для очереди L, должна отслеживать задержку непосредственно в L при перегрузке только L, а также отслеживать p_CL при связанных условиях перегрузки. Таким образом, L использует «естественный механизм Native AQM» для расчёта вероятности p’_L как функции от мгновенной задержки в очереди L. С учётом условного приоритета очереди L над C при росте очереди L механизм AQM должен применять вероятность маркировки p’_L, но значение p_L не должно опускаться ниже p_CL. Это предполагает

       p_L = max(p'_L, p_CL)                (4)

что хорошо работает на практике.

Два преобразования p’ в уравнениях (2) и (3) реализуют связывание, заданное уравнением (1).

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

                        _________
                               | |    ,------.
                Очередь L4S (L)| |===>|Маркер|
                    ,'| _______|_|    | ECN  |\
                  <'  |         |     `------'\\
                   //`'         v        ^ p_L \\
                  //       ,-------.     |      \\
                 //        |Естеств|p'_L |       \\,.
                //         |  L4S  |--->(MAX)    <  |   ___
   ,----------.//          |  AQM  |     ^ p_CL   `\|.'     `.
   |Классифик.|/           `-------'     |          /Планиров.\
==>|  IP-ECN  |            ,-------.   (k*p')       [приорит. ]==>
   |          |\           |Базовый|     |          \по услов./
   `----------'\\          |  AQM  |---->:        ,'|`-.___.-'
                \\         |       |p'   |      <'  |
                 \\        `-------'   (p'^2)    //`'
                  \\            ^        |      //
                   \\,.         |        v p_C //
                   <  | _________     .------.//
                    `\|  |       |    | Drop |/
         Классическая (C)|очередь|===>|/mark |
                        _|_______|    `------'

===> поток трафика
---> зависимость при управлении

Рисунок . Схема DualQ Coupled AQM.

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

Предоставление приоритета очереди L обеспечивает очень малую задержку в ней, поскольку очередь L сохраняется пустой, когда трафик L контролируется связыванием. Это связывание работает лишь в одном направлении — от классического контроля перегрузки к L4S. Приоритет должен предоставляться по какому-либо условию, чтобы не допустить кратковременного подавления трафика C (), чтобы тот можно было тем или иным способом вытолкнуть, как описано ниже. При нормальной реакции трафика L связанная маркировка ECN предоставляет трафику C возможность прохождения даже при сильной приоритизации за счёт маркировки перегрузки трафика L, чтобы оставить некоторое пространство. Однако при наличии лишь небольшого конечного набора пакетов C (например, запрос DNS или начальное окно данных) некоторые классические AQM не обеспечивают достаточной маркировки ECN в очереди L, независимо от продолжительности ожидания пакетами C. В этом случае при сохранении занятости очереди L трафик C просто не будет учитываться планировщиком со строгим приоритетом. В идеале классическому AQM следует увеличивать вероятность связанной маркировки по мере роста продолжительности ожидания для пакетов C, но это не всегда практично, поэтому следует предоставлять приоритет очереди L при выполнении неких условий. Задание небольшого веса или предела времени ожидания для трафика C улучшает время отклика для коротких классических сообщений, таких запросы DNS, и ускоряет запуск классического потока, поскольку некоторая пропускная способность доступна сразу.

Примеры алгоритмов DualQ Coupled AQM (DualPI2 и Curvy RED) даны в приложениях A и B. Любой из них подходит для связывания маркировки и отбрасывания пакетов в DualQ.

• DualPI2 использует пропорциональный интегральный (Proportional Integral или PI) контроллер в качестве Base AQM. Этот базовый механизм AQM с квадратичным выходом и без очереди L4S может служить заменой PIE [RFC8033] и в этом случае называется PI2 [PI2]. Это принципиальное упрощение PIE, которое является более отзывчивым и стабильным при динамически меняющейся нагрузке.

• Curvy RED является производным от RED [RED], но его конфигурационные параметры основаны на задержке, что делает алгоритм нечувствительным к скорости канала и требует меньше операций на один пакет, чем RED.

DualPI2 более отзывчив и стабилен в широком диапазоне RTT, нежели Curvy RED, поэтому на момент создания документа DualPI2 чаще применялся при разработке и оценке, чем Curvy RED, который не оценён в полной мере.

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

Можно управлять очередями с другими AQM при соблюдении нормативных требований параграфа 2.5.

Две очереди могут не входить в одну иерархию очередей, например, как показано в [L4S-DIFFSERV].

2.5. Нормативные требования для DualQ Coupled AQM

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

2.5.1. Функциональные требования

Реализация DualQ Coupled AQM должна соответствовать требованиям к поведению L4S для любого сетевого узла L4S (не только DualQ), заданным в разделе 5 [RFC9331]. В первую очередь это относится к классификации и перемаркировке, кратко описанным в параграфе 2.3. Параграф 5.5 в [RFC9331] содержит рекомендации по сокращению блочной передачи (burstiness) технологии канального уровня, служащей базой для L4S AQM.

Реализация DualQ Coupled AQM должна применять две очереди, по одной для каждого алгоритма AQM.

Алгоритм AQM для очереди с малой задержкой (L) должен быть способен применять маркировку ECN для поддерживающих ECN пакетов.

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

[RFC9331] определяет значение маркировка ECN для трафика L4S относительно отбрасывания классического трафика. Для сосуществования классического трафика и Scalable L4S, там сказано «вероятность отбрасывания механизмом AQM классического пакета Not-ECT (p_C) должна быть примерно пропорциональна квадратному корню вероятности маркировки, если бы это был пакет L4S (p_L).» Термин «вероятность» (likelihood) здесь имеет смысл, позволяющий маркировке и отбрасыванию быть как вероятностными, так и детерминированными.

Для текущей спецификации из этого следует, что механизм DualQ Coupled AQM должен применять маркировку ECN к трафику в очереди L не реже, чем получено из вероятности отбрасывания (или маркировки ECN) в классической очереди с использованием уравнения (1). Константа k в уравнении (1) указывает относительные скорости потоков Classic и L4S, когда рассматриваемый механизм AQM является узким местом (при прочих равных условиях). Для протокола L4S ECN в [RFC9331] сказано: «Коэффициент пропорциональности (k) не стандартизован для обеспечения функциональной совместимости, но рекомендуется значение 2.»

Допущение, что расширяемый контроль перегрузок в Internet будет столь же энергичным, как DCTCP, гарантирует, что окно перегрузки будет примерно таким, как при стандартном контроле перегрузки TCP Reno (Reno) [RFC5681] и других дружественных к Reno механизмов контроля перегрузки, таких как TCP CUBIC в режиме Reno-friendly.

Выбор значения k определяется оператором и тот может применять разные значения в соответствии с рекомендациями Приложения C.2.

Если пропускная способность узкого места совместно используется разными клиентами или пользователями (например, канал доступа в Internet из сети кампуса), выбор оператором значения k будет определять распределение пропускной способности между потоками разных клиентов. Однако в общедоступной сети Internet операторы сетей доступа обычно изолируют клиентов друг от друга с помощью того или иного мультиплексирования на канальном уровне (OFDM(A) в DOCSIS 3.1, CDMA в 3G, SC-FDMA в LTE) или планирования L3 (WRR⁹ для DSL), не полагаясь на контроль перегрузок в хостах [RFC0970]. В таких случаях выбор значения k влияет лишь на относительные скорости потоков в рамках доступной каждому клиенту пропускной способности, а не между клиентами. Кроме того, k не будет влиять на относительные скорости потоков, когда все потоки являются классическими (или L4S), и на пропускную способность небольших потоков.

2.5.1.1. Требования в неожиданных случаях

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

• Если пакет без кода ECT(1) или CE направляется в очередь L:

  • если пакет содержит код ECT(0), AQM очереди L следует применить маркировку CE используя вероятность, соответствующую классическому контролю перегрузки и подходящую для целевой задержки в очереди L;

  • если это пакет Not-ECT, применяемое действие зависит от применения какой-либо иной функции защиты очереди L от потоков с некорректным поведением (например, защита очередей по потокам [DOCSIS-Q-PROT] или контроль задержки):

    • если предусмотрена защита отдельной очереди, AQM очереди L следует игнорировать пакет и переслать его без изменений, что означает отказ от решения вопроса об отправке уведомления о перегрузке, отбрасывания и CE-маркировки пакета (например, оператор может классифицировать трафик EF, не отвечающий на отбрасывание, в очередь L вместе с отвечающим на перегрузку трафиком L4S-ECN);

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

• Если пакет с кодом ECT(1) направляется в очередь C:

  • AQM очереди C следует применять маркировку CE с использованием вероятности Coupled AQM p_CL (= k*p’).

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

Если DualQ Coupled AQM обнаруживает перегрузку, этот механизм должен применять классическое отбрасывание для обоих типов трафика с поддержкой ECN, пока перегрузка не закончится. Применять отбрасывание при постоянно высокой маркировке ECN рекомендуется в разделе 7 спецификации ECN [RFC3168] и параграфе 4.2.1 [RFC7567].

2.5.2. Требования к управлению

2.5.2.1. Настройка конфигурации

По умолчанию механизму DualQ Coupled AQM не следует требовать какой-либо настройки для использования в узких местах общедоступной сети Internet [RFC7567]. Оператор может настраивать указанные ниже параметры, например, для тонкой настройки, не связанной с Internet.

• Необязательные классификаторы пакетов в дополнение к полю ECN ().

• Ожидаемое типовое значение RTT, которое может служить для определения задержки в очереди Classic AQM в её рабочей точке, чтобы предотвратить недогрузку канала типичными одиночными потоками, например,

  • для алгоритма PI2 (Приложение A) целевая задержка в очереди зависит от типового значения RTT;

  • для алгоритма Curvy RED (Приложение B) целевая задержка в очереди для желаемой рабочей точки curvy ramp настраивается с учётом типового значения RTT;

  • при использовании иных Classic AQM вероятно потребуется рабочая точка для очереди на основе типового значения RTT и в этом случае точку следует задавать в единицах времени.

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

• Ожидаемое максимальное значение RTT, которое может служить для установки параметров стабильности Classic AQM, например,

  • для алгоритма PI2 (Приложение A) параметры усиления алгоритма PI зависят от максимального RTT;

  • для алгоритма Curvy RED (Приложение B) параметры сглаживания, выбираемые для фильтрации переходных процессов в очереди, зависят от максимального RTT.

  Рассчитанные вручную параметр стабильности с учётом максимального RTT можно настраивать напрямую.

• Коэффициент (фактор) связывания k (Приложение C.2).

• Ограничение приоритета L4S по условию. Это зависит от планировщика, но значение следует указывать отношениям максимальной задержки пакетов C и L, например,

  • для планировщика WRR отношение весов L и C, равное w:1, означает, что максимальная задержка пакетов C в w раз больше максимальной задержки пакетов L;

  • для планировщика FIFO с временным сдвигом (TS-FIFO) (см. параграф 4.2.2) смещение tshift означает, что максимальная задержка пакетов C на tshift больше, чем для пакетов L. Значение tshift можно указывать числом типовых интервалов RTT, а не абсолютной задержкой.

• Максимальная вероятность маркировки Classic ECN p_Cmax, после которой начинается отбрасывание.

2.5.2.2. Мониторинг

Экспериментальному механизму DualQ Coupled AQM следует позволять оператору отслеживать по запросу указанные ниже операционные данные статистики по очередям с настраиваемыми интервалами выборки для мониторинга производительности и, возможно, учёта.

• Число пересланных битов, по которому рассчитывается уровень загрузки.

• Общее число пакетов по 3 категориям: принятые, представленные AQM и пересланные. Разница между первыми двумя будет указывать степень отбрасывания хвоста, не связанного с AQM. Разница между двумя последними указывает проактивное отбрасывание в AQM;

• Число промаркированных ECN пакетов, отброшенных пакетов без ECN и отброшенных пакетов ECN, которые могут комбинироваться с тремя общими счётчиками пакетов, указанными выше, для расчёта вероятностей маркировки и отбрасывания.

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

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

2.5.2.3. Обнаружение аномалий

Экспериментальному механизму DualQ Coupled AQM следует асинхронно сообщать об аномальных условиях.

Время начала и продолжительность перегрузки

2.5.2.4. Внедрение, сосуществование, расширяемость

В [RFC5706] предложено включать внедрение, сосуществование и расширение как требования к управлению. Смысл введения DualQ Coupled AQM заключается в обеспечении возможности внедрения и сосуществования расширяемого контроля перегрузки (как поэтапной замены сегодняшнего совместимого с Reno контроля перегрузок, не расширяемого с ростом произведения пропускной способности и задержки). Поэтому нет необходимости повторять мотивирующие проблемы, уже рассмотренные во введении и детализированные в описании архитектуры L4S [RFC9330].

Описания конкретных алгоритмов DualQ Coupled AQM в приложениях охватывают масштабирование их конфигурационных параметров, например в части RTT и частоты выборки.

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

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

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

4.1. Малые задержки без обработки по потокам

Архитектура L4S [RFC9330] сравнивает подходы DualQ и FQ для L4S. При рассмотрении вопросов приватности обосновывается подход DualQ, поскольку в этом случае пользователям, желающим зашифровать идентификаторы потоков (например, с помощью IPsec или иного шифрованного туннеля VPN), не нужно жертвовать малой задержкой ([RFC8404] рекомендует избегать таких компромиссов в отношении приватности).

Обсуждение вопросов безопасности архитектуры L4S [RFC9330] включает параграфы, посвящённые управлению относительной скоростью потоков (параграф 8.1) и управлению потоками, вызывающими чрезмерную задержку в очереди (параграф 8.2). Отмечено, что интересы пользователей в части задержки не сталкиваются так же, как для пропускной способности. Если кто-то получает больше пропускной способности общего канала, кто-то другой получает меньше, тогда как задержки можно сократить для каждого без ущерба для кого бы то ни было. Отмечено также, что сегодня в Internet планирование обычно вынуждает разделять пропускную способность между «сайтами» (например, домовладениями, организациями или мобильными пользователями), но необходимость в планировании пропускной способности для отдельных приложений и управлении ею возникает нечасто.

В свете приведённых выше аргументов управление скоростью по потокам может не потребоваться, а в доверенных средах (например, в частных ЦОД) это, несомненно, маловероятно. Поскольку трудно избежать сложностей и побочных эффектов при управлении скоростью по потокам, его требуется отделять от базового AQM, например, на основании политики. С учётом этого, DualQ Coupled AQM обеспечивает малую задержку, не предопределяя управления скоростью по потокам.

Тем не менее, интересы пользователей могут конфликтовать, например, в результате аварии или злого умысла. Тогда управление скоростью по потокам может стать необходимым. Такое управление при необходимости может быть предоставлено как модульное расширение DualQ. Если нужна защита от чрезмерной задержки в очереди, в DualQ можно добавить защиту очередей по потокам (например, [DOCSIS-Q-PROT]).

4.2. Обработка неотзывчивых пакетов и перегрузки

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

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

• Неотзывчивые потоки (L и/или C) без перегрузки, т. е. суммарный неотзывчивый трафик до внесения какого-либо отзывчивого трафика меньше пропускной способности на выходе. Этот случай обрабатывается обычным механизмом Coupled DualQ (параграф 2.1), но не рассматривается там. В параграфе 4.2.1 разъяснены цели проектирования и их достижение на практике.

• Неотзывчивые потоки (L и/или C), вызывающие постоянную перегрузку, т. е. суммарный неотзывчивый трафик постоянно превышает пропускную способность на выходе. Такие ситуации не обрабатываются обычным механизмом Coupled DualQ (параграф 2.1), но в последнем абзаце параграфа 2.5.1.1 задано требование обработки ситуаций, где трафик с поддержкой ECN может истощать трафик без поддержки ECN. В параграфе 4.2.3 рассматриваются основные варианты решения и приведены конкретные примеры.

• Кратковременная перегрузка (состояние между отсутствием перегрузки и постоянной перегрузкой). До момента, когда перегрузка будет сочтена постоянной в параграфе 4.2.2 рассмотрены варианты более оперативных механизмов в масштабе времени планировщика. Это предотвращает кратковременное истощение трафика из очереди C, делая приоритет очереди L условным, как требует параграф 2.5.1.

4.2.1. Неотзывчивый трафик без перегрузки

Когда 1 или множество потоков L и/или C не отвечают на сигналы перегрузки, но создаваемый ими трафик не превышает пропускную способность канала и связанная маркировка не достигает насыщения (менее 100%), целью DualQ AQM является поведение не хуже, чем у AQM с одной очередью.

Тесты показали, что это действительно так без каких-либо дополнительных механизмов сверх Coupled DualQ из параграфа 2.1 (см. результаты экспериментов с перегрузкой в [L4Seval22]). Возможно, вопреки интуиции, что независимо от классификации неотзывчивых потоков в очередь L или C, система DualQ поведёт себя, как будто она исключена (вычтена) из общей пропускной способности канала. После этого связывание распределит оставшуюся пропускную способность между конкурирующими потоками с реакцией на перегрузку (в любой очереди). Связанные с планировщиком детали рассматриваются в параграфе 4.2.2.

4.2.2. Предотвращение краткосрочного подавления классического трафика

Приоритет L4S должен предоставляться по условию (см. параграфы 2.4 и 2.5.1) , чтобы избежать кратковременного истощения классического трафика. Иначе, как разъяснено в параграфе 2.4, даже 1 отзывчивый поток L4S может временно заблокировать небольшой конечный набор пакетов C (например, начальное окно или запрос DNS). Блокировка будет короткой, но может быть более долгой в некоторых реализациях AQM, которые могут лишь увеличивать сигнализацию перегрузки, связанную с очередью C, когда пакеты C фактически выводятся из очереди. В этом случае возникает вопрос о принесении в жертву пропускной способности или задержки L4S (или иного правила).

Жертва производительностью L4S

Жертва задержкой L4S

Примеры из приложений A и B могут быть реализованы с любым из подходов.

4.2.3. Насыщение L4S ECN — отбрасывание или задержка?

В этом параграфе рассматривается постоянная перегрузка вызванная неотзывчивыми потоками L и/или C. Для сохранения примерно одинаковой пропускной способности потоков L4S и Classic во всем диапазоне нагрузки требуется определить другую стратегию управления при нагрузке выше точки, где L4S AQM постоянно находится (достигает) в насыщении вероятности маркировки ECN (100%), не оставляя места для дополнительной нагрузки. Маркировка L4S ECN будет насыщаться первой (при факторе связывания k>1), даже если насыщение общим неотзывчивым трафиком в одной или обеих очередях, превышающим пропускную способность канала.

Термин «неотзывчивый» относится и к случаям, где поток становится неотзывчивым на время, например, поток в реальном масштабе времени, которому нужно некоторое время на изменение скорости в ответ на перегрузку, или стандартный поток Reno, который обычно отвечает на перегрузку, но при превышении некоторого уровня уже не способен снижать окно перегрузки ниже разрешённого минимума в 2 сегмента [RFC5681], фактически становясь неотзывчивым (отметим, что трафик L4S должен сохранять отзывчивость при размере окна меньше 2 сегментов, как указано в требованиях L4S [RFC9331]).

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

Отбрасывание при насыщении

Задержка при насыщении

В примере реализации из Приложения A применяется лишь правило «отбрасывания при насыщении». Спецификация DOCSIS для DualQ Coupled AQM [DOCSIS3.1] реализует такое же правило с очень маленьким буфером L. Однако добавление защиты очередей по потокам [DOCSIS-Q-PROT] меняет этот подход на «задержку при насыщении», перенаправляя некоторые пакеты потока или потоков, наиболее сильно связанные с перегрузкой очереди L, в очередь C, которая имеет более высокую целевую задержку. Если перегрузка продолжается, механизм возвращается к отбрасыванию при насыщении, поскольку уровень отбрасывания в очереди C растёт для поддержания целевой задержки в C.

4.2.3.1. Защита от перегрузки неотзывчивым трафиком с поддержкой ECN

Без конкретного механизма для перегрузки неотзывчивый трафик получит большее преимущество, если он поддерживает ECN. Это преимущество невозможно обнаружить при обычных низких уровнях маркировки, однако оно становится более значительным при росте уровня маркировки, характерном для перегрузки, когда можно избежать высокого уровня отбрасывания. Эта проблема характерна для поддерживающего ECN трафика L4S и классического трафика. В связи с этим возникает вопрос об использовании отбрасывания трафика с поддержкой ECN (нужно ли и когда), как этого требует раздел 7 спецификации ECN [RFC3168] и параграф 4.2.1 рекомендация для AQM [RFC7567].

Например, эксперименты с DualPI2 AQM (Приложение A) показали что использование отбрасывания при перегрузке при связанной на 100% маркировке L4S решает пробдему неотзывчивого трафика ECN, а также проблему насыщения. При насыщении DualPI2 переходит в режим перегрузки, где механизм Base AQM управляется максимальной задержкой в обеих очередях и вводит вероятностное отбрасывание в равной степени для обеих очередей. Это оставляет лишь небольшой диапазон уровней перегрузки чуть ниже насыщения, где неотзывчивый трафик получает какое-либо преимущество от использования ECN (относительно неотзывчивого трафика без ECN) и это преимущество едва различимо (см. [DualQ-Test] и раздел IV-G в [L4Seval22]). Кроме того, перегрузка неотзывчивым потоком с кодом ECT(1) даёт не больше преимущества в пропускной способности по сравнению с ECT(0).

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

5.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>.

[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>.

[RFC8311] Black, D., «Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation», RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[RFC9331] De Schepper, K. and B. Briscoe, Ed., «The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)», RFC 9331, DOI 10.17487/RFC9331, January 2023, <https://www.rfc-editor.org/info/rfc9331>.

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

[Alizadeh-stability] Alizadeh, M., Javanmard, A., and B. Prabhakar, «Analysis of DCTCP: Stability, Convergence, and Fairness», SIGMETRICS ’11: Proceedings of the ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer Systems, pp. 73-84, DOI 10.1145/1993744.1993753, June 2011, <https://dl.acm.org/citation.cfm?id=1993753>.

[AQMmetrics] Kwon, M. and S. Fahmy, «A Comparison of Load-based and Queue-based Active Queue Management Algorithms», Proc. Int’l Soc. for Optical Engineering (SPIE), Vol. 4866, pp. 35-46, DOI 10.1117/12.473021, 2002, <https://www.cs.purdue.edu/homes/fahmy/papers/ldc.pdf>.

[ARED01] Floyd, S., Gummadi, R., and S. Shenker, «Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management», ACIRI Technical Report 301, August 2001, <https://www.icsi.berkeley.edu/icsi/node/2032>.

[BBR-CC] Cardwell, N., Cheng, Y., Hassas Yeganeh, S., Swett, I., and V. Jacobson, «BBR Congestion Control», Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.

[BBRv2] «TCP BBR v2 Alpha/Preview Release», commit 17700ca, June 2022, <https://github.com/google/bbr>.

[Boru20] Boru Oljira, D., Grinnemo, K-J., Brunstrom, A., and J. Taheri, «Validating the Sharing Behavior and Latency Characteristics of the L4S Architecture», ACM SIGCOMM Computer Communication Review, Vol. 50, Issue 2, pp. 37-44, DOI 10.1145/3402413.3402419, May 2020, <https://dl.acm.org/doi/abs/10.1145/3402413.3402419>.

[CCcensus19] Mishra, A., Sun, X., Jain, A., Pande, S., Joshi, R., and B. Leong, «The Great Internet TCP Congestion Control Census», Proceedings of the ACM on Measurement and Analysis of Computing Systems, Vol. 3, Issue 3, Article No. 45, pp. 1-24, DOI 10.1145/3366693, December 2019, <https://doi.org/10.1145/3366693>.

[CoDel] Nichols, K. and V. Jacobson, «Controlling Queue Delay», ACM Queue, Vol. 10, Issue 5, May 2012, <https://queue.acm.org/issuedetail.cfm?issue=2208917>.

[CRED_Insights] Briscoe, B. and K. De Schepper, «Insights from Curvy RED (Random Early Detection)», BT Technical Report, TR-TUB8-2015-003, DOI 10.48550/arXiv.1904.07339, August 2015, <https://arxiv.org/abs/1904.07339>.

[DOCSIS-Q-PROT] Briscoe, B., Ed. and G. White, «The DOCSIS® Queue Protection to Preserve Low Latency», Work in Progress, Internet-Draft, draft-briscoe-docsis-q-protection-06, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06>.

[DOCSIS3.1] CableLabs, «DOCSIS 3.1 MAC and Upper Layer Protocols Interface Specification», CM-SP-MULPIv3.1, Data-Over-Cable Service Interface Specifications DOCSIS 3.1 Version I17 or later, January 2019, <https://specification-search.cablelabs.com/CM-SP-MULPIv3>.

[DualPI2Linux] Albisser, O., De Schepper, K., Briscoe, B., Tilmans, O., and H. Steen, «DUALPI2 — Low Latency, Low Loss and Scalable (L4S) AQM», Proceedings of Linux Netdev 0x13 , March 2019, <https://www.netdevconf.org/0x13/session.html?talk-DUALPI2-AQM>.

[DualQ-Test] Steen, H., «Destruction Testing: Ultra-Low Delay using Dual Queue Coupled Active Queue Management», Master’s Thesis, Department of Informatics, University of Oslo, May 2017.

[Dukkipati06] Dukkipati, N. and N. McKeown, «Why Flow-Completion Time is the Right Metric for Congestion Control», ACM SIGCOMM Computer Communication Review, Vol. 36, Issue 1, pp. 59-62, DOI 10.1145/1111322.1111336, January 2006, <https://dl.acm.org/doi/10.1145/1111322.1111336>.

[Heist21] «L4S Tests», commit e21cd91, August 2021, <https://github.com/heistp/l4s-tests>.

[L4S-DIFFSERV] Briscoe, B., «Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services», Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-diffserv-02, 4 November 2018, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>.

[L4Sdemo16] Bondarenko, O., De Schepper, K., Tsang, I., Briscoe, B., Petlund, A., and C. Griwodz, «Ultra-Low Delay for All: Live Experience, Live Analysis», Proceedings of the 7th International Conference on Multimedia Systems, Article No. 33, pp. 1-4, DOI 10.1145/2910017.2910633, May 2016, <https://dl.acm.org/citation.cfm?doid=2910017.2910633>.

[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, «Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All», Preprint submitted to IEEE/ACM Transactions on Networking, DOI 10.48550/arXiv.2209.01078, September 2022, <https://arxiv.org/abs/2209.01078>.

[L4S_5G] Willars, P., Wittenmark, E., Ronkainen, H., Östberg, C., Johansson, I., Strand, J., Lédl, P., and D. Schnieders, «Enabling time-critical applications over 5G with rate adaptation», Ericsson — Deutsche Telekom White Paper, BNEW-21:025455, May 2021, <https://www.ericsson.com/en/reports-and-papers/white-papers/enabling-time-critical-applications-over-5g-with-rate-adaptation>.

[Labovitz10] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., and F. Jahanian, «Internet Inter-Domain Traffic», ACM SIGCOMM Computer Communication Review, Vol. 40, Issue 4, pp. 75-86, DOI 10.1145/1851275.1851194, August 2010, <https://doi.org/10.1145/1851275.1851194>.

[LLD] White, G., Sundaresan, K., and B. Briscoe, «Low Latency DOCSIS: Technology Overview», CableLabs White Paper, February 2019, <https://cablela.bs/low-latency-docsis-technology-overview-february-2019>.

[MEDF] Menth, M., Schmid, M., Heiss, H., and T. Reim, «MEDF — A Simple Scheduling Algorithm for Two Real-Time Transport Service Classes with Application in the UTRAN», Proc. IEEE Conference on Computer Communications (INFOCOM’03), Vol. 2, pp. 1116-1122, DOI 10.1109/INFCOM.2003.1208948, March 2003, <https://doi.org/10.1109/INFCOM.2003.1208948>.

[PI2] De Schepper, K., Bondarenko, O., Briscoe, B., and I. Tsang, «PI2: A Linearized AQM for both Classic and Scalable TCP», ACM CoNEXT’16, DOI 10.1145/2999572.2999578, December 2016, <https://dl.acm.org/doi/10.1145/2999572.2999578>.

[PI2param] Briscoe, B., «PI2 Parameters», Technical Report, TR-BB-2021-001, arXiv:2107.01003 [cs.NI], DOI 10.48550/arXiv.2107.01003, July 2021, <https://arxiv.org/abs/2107.01003>.

[PRAGUE-CC] De Schepper, K., Tilmans, O., and B. Briscoe, «Prague Congestion Control», Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-01, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01>.

[PragueLinux] Briscoe, B., De Schepper, K., Albisser, O., Misund, J., Tilmans, O., Kuehlewind, M., and A. Ahmed, «Implementing the ‘TCP Prague’ Requirements for L4S», Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>.

[RED] Floyd, S. and V. Jacobson, «Random Early Detection Gateways for Congestion Avoidance», IEEE/ACM Transactions on Networking, Volume 1, Issue 4, pp. 397-413, DOI 10.1109/90.251892, August 1993, <https://dl.acm.org/doi/10.1109/90.251892>.

[RELENTLESS] Mathis, M., «Relentless Congestion Control», Work in Progress, Internet-Draft, draft-mathis-iccrg-relentless-tcp-00, 4 March 2009, <https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00>.

[RFC0970] Nagle, J., «On Packet Switches With Infinite Storage», RFC 970, DOI 10.17487/RFC0970, December 1985, <https://www.rfc-editor.org/info/rfc970>.

[RFC2914] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.

[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, «An Expedited Forwarding PHB (Per-Hop Behavior)», RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.

[RFC3649] Floyd, S., «HighSpeed TCP for Large Congestion Windows», RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.

[RFC5033] Floyd, S. and M. Allman, «Specifying New Congestion Control Algorithms», BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.

[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>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC5706] Harrington, D., «Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions», RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, «Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem», RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8034] White, G. and R. Pan, «Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems», RFC 8034, DOI 10.17487/RFC8034, February 2017, <https://www.rfc-editor.org/info/rfc8034>.

[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>.

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, «Data Center TCP (DCTCP): TCP Congestion Control for Data Centers», RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, «The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm», RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.

[RFC8298] Johansson, I. and Z. Sarker, «Self-Clocked Rate Adaptation for Multimedia», RFC 8298, DOI 10.17487/RFC8298, December 2017, <https://www.rfc-editor.org/info/rfc8298>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, «CUBIC for Fast Long-Distance Networks», RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., «Effects of Pervasive Encryption on Operators», RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, «Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture», RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/info/rfc9330>.

[SCReAM-L4S] «SCReAM», commit fda6c53, June 2022, <https://github.com/EricssonResearch/scream>.

[SigQ-Dyn] Briscoe, B., «Rapid Signalling of Queue Dynamics», Technical Report, TR-BB-2017-001, DOI 10.48550/arXiv.1904.07044, September 2017, <https://arxiv.org/abs/1904.07044>.

Приложение A. Пример алгоритма DualQ Coupled PI2

В качестве первого конкретного примера ниже рассматривается алгоритм DualPI2, соответствующий схеме DualQ Coupled AQM на рисунке . Для Native L4S AQM применяется функция линейного изменения (ramp) (от времени в очереди) и несглаженной маркировкой ECNи может применяться также ступенчатая функция. Для Classic AQM применяется алгоритм PI2 [PI2], являющийся улучшенным вариантом PIE AQM [RFC8033].

Псевдокод вводится за два прохода. На первом объясняются основные понятия, а на втором — обработка граничных случаев, таких как перегрузка. Для удобства сравнения в обоих проходах применяется общая нумерация строк с буквенными суффиксами в случае добавления строк. Все переменные предполагаются действительными с плавающей запятой указывающими значения в базовых единицах (размер в байтах, время в секундах, скорость в байт/сек, alpha и beta в герцах и вероятности от 0 до 1). Предполагается, что константы, указанные с k (кило), M (мега), G (гига), u (микро), m (милли), % и т. д. преобразуются в соответствующие кратные или дробные значения в базовых единицах. В фактической реализации на основе целых чисел потребуется обработка масштабных коэффициентов и соответствующая разрядность целых чисел (включая временные внутренние значения при расчётах).

Полный исходный код реализации для Linux доступен по ссылке https://github.com/L4STeam/sch_dualpi2_upstream и разъяснён в [DualPI2Linux]. Спецификация DualQ Coupled AQM для кабельных модемов DOCSIS и систем завершения (cable modem termination system или CMTS) приведена в [DOCSIS3.1] и разъяснена в [LLD].

A.1. Проход 1 — базовые концепции

Псевдокод манипулирует 3 основными структурами переменных: пакет (pkt), очередь L4S (lq), классическая очередь (cq). Ниже перечислены 6 функций псевдокода.

• Функция инициализации dualpi2_params_init(…) () устанавливает принятые по умолчанию значения параметров (API для установки других значений опущен для краткости).

• Функция постановки в очередь dualpi2_enqueue(lq, cq, pkt) ().

• Функция извлечения из очереди dualpi2_dequeue(lq, cq, pkt) ().

• Рекуррентная функция recur(q, likelihood) для дерандомизации маркировки ECN (показана в конце рисунка ).

• Функция L4S AQM laqm(qdelay) () для расчёта вероятности маркировки ECN в очереди L4S.

• Функция базового AQM, реализующая алгоритм PI, dualpi2_update(lq, cq) (). Служит для регулярного обновления базовой вероятности (p’), которая возводится в квадрат для Classic AQM, а также связывается с очередью L4S.

Используются также перечисленные ниже функции, которые не показаны полностью:

• scheduler() для выбора пакетов в начале очередей (выбор планировщика рассматривается ниже);

• cq.byt() или lq.byt() возвращает текущий размер (backlog) соответствующей очереди в байтах;

• cq.len() или lq.len() возвращает текущий размер соответствующей очереди в пакетах;

• cq.time() или lq.time() возвращает текущую задержку в соответствующей очереди (в единицах времени, см. примечания ниже);

• mark(pkt) и drop(pkt) для маркировки ECN и отбрасывания пакета.

В проведённых к настоящему времени экспериментах (на основе PIE) на каналах широкополосного доступа от 4 до 200 Мбит/с с базовым RTT от 5 до 100 мсек DualPI2 достигает высоких результатов с принятыми по умолчанию параметрами (). Параметры классифицируются в зависимости от их связи с PI2 AQM, L4S AQM или схеме связывания. Константы и переменные, полученные из этих параметров, указаны в конце каждой категории. Для каждого параметра даны пояснения в точке его применения в псевдокоде с обоснованием заданных по умолчанию значений, чтобы можно было установить разумные значения в вариантах применения, отличающихся от общедоступной сети Internet.

1:  dualpi2_params_init(...) {         % Установка входных параметров по умолчанию
2:    % Параметры схемы Coupled DualQ 
5:    limit = MAX_LINK_RATE * 250 ms                      % Размер двойного буфера
3:    k = 2                                                    % Фактор связывания
4:    % Не показано     % зависящий от планировщика вес или эквивалентный параметр
6:
7:    % Параметры PI2 Classic AQM
8:    target = 15 ms                                  % Целевая задержка в очереди
9:    RTT_max = 100 ms                    % Ожидаемое в худшем случае значение RTT
10:   % Константы PI2, выведенные из приведённых выше параметров PI2
11:   p_Cmax = min(1/k^2, 1)          % Макс. вероятн. отбрасыв./маркир. (Classic)
12:   Tupdate = min(target, RTT_max/3)                       % Интервал выборки PI
13:   alpha = 0.1 * Tupdate / RTT_max^2            % Интегральное усиление PI в Гц
14:   beta = 0.3 / RTT_max                     % Пропорциональное усиление PI в Гц
15:
16:   % Параметры L4S ramp AQM
17:   minTh = 800 us                         % Нижний порог маркировки L4S (время)
18:   range = 400 us                                        % Диапазон L4S (время)
19:   Th_len = 1 pkt                        % Нижний порог маркировки L4S (пакеты)
20:   % Константы L4S
21:   p_Lmax = 1                         % Максимальная вероятность маркировки L4S
22: }

Рисунок . Пример псевдокода заголовка для DualQ Coupled PI2 AQM.

Общая цель заключается в применении вероятности маркировки и отбрасывания для L4S и классического трафика (p_L и p_C). Значения выводятся из базовых вероятностей p’_L и p’, соответственно, в соответствии с трафиком в очередях L и C. Вероятность маркировки в очереди L (p_L) зависит от базовой вероятности для этой очереди (p’_L) и вероятности p_CL, связанной с p’ для очереди C (см. уравнения в параграфе 2.4).

1:  dualpi2_enqueue(lq, cq, pkt) { % Проверка размера и классификация lq или cq
2:    if ( lq.byt() + cq.byt() + MTU > limit)
3:      drop(pkt)                    % Отбрасывание пакета, если буфер заполнен
4:    timestamp(pkt)                     % Требуется лишь для метода пребывания
5:    % Packet classifier
6:    if ( ecn(pkt) modulo 2 == 1 )                  % Биты ECN = ECT(1) или CE
7:      lq.enqueue(pkt)
8:    else                                      % Биты ECN = not-ECT или ECT(0)
9:      cq.enqueue(pkt)
10: }

Рисунок . Пример псевдокода постановки в очередь для DualQ Coupled PI2 AQM.

Вероятности p_CL и p_C выводятся в строках 4 и 5 функции dualpi2_update() () и затем используются функцией dualpi2_dequeue(), где выводится p_L из p_CL в строке 6 (). Приведённое ниже пошаговое описание кода разъясняет эту часть кода, начиная с прибытия пакета.

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

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

В строках 5-9 пакет классифицируется и помещается в очередь Classic или L4S в зависимости от младшего бита (least significant bit или LSB) поля ECN в заголовке IP (строка 6). Пакеты с кодом, имеющим 0 в LSB (Not-ECT и ECT(0)) помещаются в классическую очередь, а пакеты ECT(1) и CE в очередь L4S. Необязательная гибка классификация пакетов для краткости не показана (см. протокол L4S ECN [RFC9331]).

1:  dualpi2_dequeue(lq, cq, pkt) {  % Связывает очереди L4S и Classic
2:    while ( lq.byt() + cq.byt() > 0 ) {
3:      if ( scheduler() == lq ) {
4:        lq.dequeue(pkt)                   % Планировщик выбирает lq
5:        p'_L = laqm(lq.time())                        % Native LAQM
6:        p_L = max(p'_L, p_CL)                 % Функция объединения
7:        if ( recur(lq, p_L) )                 % Линейная маркировка
8:          mark(pkt)
9:      } else {
10:       cq.dequeue(pkt)                   % Планировщик выбирает cq
11:       if ( recur(cq, p_C) ) {            % probability p_C = p'^2
12:         if ( ecn(pkt) == 0 ) {       % Если в ECN указано not-ECT
13:           drop(pkt)                   % Квадратичное отбрасывание
14:           continue                   % Продолжение с начала цикла
15:         }
16:         mark(pkt)                       % Квадратичная маркировка
17:       }
18:     }
19:     return(pkt)                      % Возврат пакета и остановка
20:   }
21:   return(NULL)                       % Нет пакетов для извлечения
22: }
23: recur(q, likelihood) {    % Возврат TRUE с некоторой вероятностью
24:   q.count += likelihood
25:   if (q.count > 1) {
26:     q.count -= 1
27:     return TRUE
28:   }
29:   return FALSE
30: }

Рисунок . Пример псевдокода извлечения из очереди для DualQ Coupled PI2 AQM.

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

Код извлечения из очереди размещается в большом цикле while, поэтому при отбрасывании пакета процесс будет продолжаться, пока не будет выбран пакет для планирования. В строке 3 псевдокода извлечения из очереди планировщик выбирает очередь L4S (lq) или Classic (cq). Детали реализации планировщика не показаны (см. обсуждение ниже).

• Если запланирован пакет L4S строки 7 и 8 устанавливают для него маркер ECN с вероятностью p_L. Используется функция recur() в конце рисунка , которая предпочтительней случайной маркировки, поскольку она позволяет избежать задержки на рандомизацию при интерпретации сигналов перегрузки, сохраняя рассинхронизацию зубьев (пиков) потоков. Строка 6 рассчитывает p_L как большую из вероятностей L4S p_CL и Native L4S AQM p’_L. Это реализует функцию MAX(), показанную на рисунке , для связывания выхода двух AQM. В строке 6 p_L определяется двумя вероятностями:

  • p’_L рассчитывается для пакета в строке 5 с помощью функции laqm() ();

  • p_CL поддерживается функцией dualpi2_update(), которая запускается в каждом интервале выборки Tupdate (строка 12 на рисунке ).

• Если запланирован классический пакет, строки 10 — 17 маркируют или отбрасывают пакет с вероятностью p_C.

Алгоритм Native L4S AQM () — функция линейного изменения (ramp), похожая на упрощённый алгоритм RED:

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

• применяется мгновенное значение задержки в очереди, что позволяет избежать сложностей сглаживания, а также внесения худшего значения RTT в сглаживание задержки в сети (см. параграф 2.1);

• рампа линейно растёт от 0 до 1, а не до промежуточного значения p’_L, как в RED, поскольку не требуется сохранять малую вероятность маркировки ECN;

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

1:  laqm(qdelay) {               % Возвращает вероятность Native L4S AQM
2:    if (qdelay >= maxTh)
3:      return 1
4:    else if (qdelay > minTh)
5:      return (qdelay - minTh)/range  % Деление можно выполнить сдвигом
6:    else
7:      return 0
8:  }

Рисунок . Пример псевдокода Native L4S AQM.

Для ramp-функции нужны 2 параметра конфигурации — нижний порог (minTh) и ширина рампы (диапазон) — , задаваемых в единицах времени, как показано в строках 17 и 18 функции инициализации на рисунке . Функцию рампы можно настроить как этап (примечание c).

Хотя статья о DCTCP [Alizadeh-stability] рекомендует порог маркировки ECN в 0,17*RTT_typ, так также сказано, что порог может быть существенно ниже при едва ли большей недогрузке канала (поскольку амплитуда зубьев в DCTCP достаточно мала). На основе множества экспериментов принятый по умолчанию нижний порог маркировки ECN для общедоступной сети Internet на рисунке (target) считается хорошим компромиссом, даже будучи значительно меньше RTT_typ.

1:  dualpi2_update(lq, cq) {         % Обновление p' в каждом Tupdate
2:    curq = cq.time()  % Используется время в очереди первого входного пакета Classic
3:    p' = p' + alpha * (curq - target) + beta * (curq - prevq)
4:    p_CL = k * p'    % Связанная вероятн. L4S = базовая вероятн. * фактор связывания
5:    p_C = p'^2                  % Классическая вероятность = (базовая вероятность)^2
6:    prevq = curq
7:  }

Рисунок . Пример псевдокода обновления PI для DualQ Coupled PI2 AQM
(контроль диапазона [0,1] для p’ опущен для простоты, см. ниже).

Вероятность связанной маркировки p_CL зависит от базовой вероятности (p’), актуальность которой поддерживается выполнением основного алгоритма PI () в каждом интервале Tupdate.

Отметим, что p’ зависит лишь от времени пребывания в классической очереди. В строке 2 текущая задержка в очереди (curq) вычисляется как время нахождения первого (head) пакета в классической очереди (cq). Функция cq.time() (не показана) вычитает время, установленное при постановке в очередь, из текущего времени (см. примечание a ниже) и неявно принимает для текущей задержки в очереди значение 0, если очередь пуста.

Алгоритм основан на строке 3, которая является классическим контроллером PI, которые меняет значение p’ в зависимости от a) разницы между текущей (curq) и целевой (target) задержкой в очереди и b) изменения задержки в очереди с момента последней выборки. Имя PI отражает то, что второй фактор (скорость роста очереди) пропорционален нагрузке, тогда как первый является интегралом от нагрузки (он исключает любую оставшуюся задержку в очереди сверх целевой).

Параметр target может быть установлен на основе локальных сведений, но цель состоит в том, чтобы принятое по умолчанию значение было хорошим компромиссом для любого места в предполагаемой среде развёртывания (общедоступная сеть Internet). Согласно [PI2param], целевая задержка в очереди (строка 8 на рисунке ) связана с типовым базовым значением RTT по всему миру (RTT_typ) двумя факторами — target = RTT_typ * g * f. Ниже приведено обоснование этих факторов и введены дополнительные корректировки. Эти два фактора гарантируют, что в значительной части случаев (скажем, 90%) вариации зубьев RTT одного потока будут помещаться в буфер без недогрузки канала. Честно говоря, эти факторы являются обоснованными предположениями, но с большим акцентом на обоснованность, нежели предположения (см. [PI2param]).

• Для RTT_typ принимается значение 25 мсек на основе средней задержки CDN, измеренной в каждой стране, с весом, пропорциональным числу пользователей Internet в этой стране, для получения средневзвешенного значения в Internet [PI2param]. Страны ранжируются по числу пользователей Internet и после охвата 90% пользователь более мелкие страны были исключены, чтобы избежать мелких выборок, которые недостаточно представительны. Данные о средней задержке CDN в Китае (самое большое число пользователей) были исключены, поскольку задержка CDN там существенно отличалась, а экспериментальный метод показался неподходящим для Китая.

• Для g принимается значение 0,38. Фактор g является геометрическим коэффициентом, характеризующим форму зубьев в распространённых классических контроллерах перегрузки. Этот фактор указывает долю амплитуды зубьев пилы задержки в очереди, которые ниже цели AQM. Например, при малых скоростях геометрический фактор стандартного механизма Reno составляет 0,5, но при высоких скоростях он стремится к 1. Согласно переписи контроллеров перегрузки, выполненной Mishra с соавторами в июле-октябре 2019 г. [CCcensus19], большая часть трафика Classic TCP применяет CUBIC. Согласно анализу [PI2param], при работе через PI2 AQM большая часть этого трафика CUBIC будет в режиме совместимости с Reno, который имеет g~0,39 (для всех известных реализаций). Остальной трафик CUBIC будет в естественном режиме (true) CUBIC с g~0,36. Без моделирования профилей зубьев для менее распространённых контроллеров перегрузок средневзвешенное отношение этих двух параметров оценено как 7:3, что даёт среднее значение g = 0,38.

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

• [PI2param] рекомендует target = RTT_typ * g * f = 25 ms * 0,38 * 2 = 19 мсек. Однако оправдано дальнейшее уточнение, поскольку цель меняется с годами. Здесь использованы данные 2019 г., где упоминается глобальный индекс Speedtest, предлагающий сократить RTT_typ на 17% для стационарных пользователей и на 12% для мобильных в интервале 2020 — 2021 гг. Поэтому здесь рекомендуется использовать по умолчанию target = 15 мсек на момент написания (2021 г.).

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

Два фактора усиления в строке 3 на рисунке (alpha и beta) определяют, насколько сильно каждый из 2 элементов (интегральный и пропорциональный) меняет p’. Они выражаются в единицах «на секунду задержки» или Гц, поскольку преобразуют разницу задержки в очереди в изменение вероятности (вероятность имеет значения от 0 до 1). Alpha и beta определяют, насколько должно изменяться значение p’ после каждого интервала обновления (Tupdate). Для меньших Tupdate значение p’ следует менять на одну и ту же величину за секунду, но более мелкими и частыми долями. Значение alpha зависит от Tupdate (строка 13 функции инициализации на рисунке ). Лучше обновлять p’ как можно чаще, но значение Tupdate, вероятно, будет ограничено производительностью оборудования. Как показано в строке 12, интервал обновления следует делать достаточно малым, чтобы обновление происходило хотя бы 1 раз за время, требуемое для «осушения» целевой очереди (target) при условии, что она обновляется не меньше 3 раз в течение максимального RTT. По умолчанию Tupdate имеет значение 16 мсек в эталонной реализации Linux, поскольку его следует округлять до значения, кратного 4 мсек. Для скоростей канала от 4 до 200 Мбит/с и максимального RTT в 100 мсек в ходе широкого тестирования подтверждено, что Tupdate = 16 мсек вполне достаточно (это же значение рекомендует спецификация PIE [RFC8033]). Выбор alpha и beta также определяет диапазон стабильной работы AQM. Механизм AQM должен менять p’ как можно быстрее в ответ на изменение нагрузки без перекомпенсации и соответствующий флуктуаций очереди. Поэтому значения alpha и beta зависят также от RTT в ожидаемом худшем случае потока (RTT_max).

Максимальное значение RTT контроллера PI (RTT_max в строке 9 на рисунке ) не является абсолютным максимумом, но для долгосрочных потоков с RTT больше этого значения возникает большая нестабильность (изменчивость очереди). Задержка распространения на полпути вокруг планеты и обратно в стеклянном волокне составляет 200 мсек. Однако почти никакой трафик не проходит по такому пути в результате значительной консолидации трафика Internet в интервале 2007 — 2009 гг. [Labovitz10], а также обслуживания большей и растущей доли трафика Internet (примерно 2/3 на момент написания документа) в CDN или облачных системах, размещённых вблизи пользователей. Internet может снова измениться, но сейчас, проектирование для максимального RTT в 100 мсек является хорошим компромиссом между ускорением контроля очередей при низком RTT и некоторой нестабильностью с случаях длинных путей.

Рекомендуемые производные значения констант усиления alpha и beta можно аппроксимировать для Reno через PI2 AQM выражениями alpha = 0,1 * Tupdate / RTT_max²; beta = 0,3 / RTT_max, как показано в строках 13 и 14 на рисунке . Они получены из анализа стабильности в [PI2]. Для принятых по умолчанию значения Tupdate = 16 мсек и RTT_max = 100 мсек это даёт alpha = 0,16, beta = 3,2 (расхождения обусловлены округлением). Эти принятые по умолчанию значения проверены для широкого диапазона скоростей каналов, целевой задержки и моделей трафика со смешанными и похожими значениями RTT, короткими и долгими потоками и т. п.

В крайних случаях p’ может выходить из диапазона [0,1], поэтому результирующее значение p’ должно ограничиваться (не показано в псевдокоде). Затем, как разъяснено выше, из нового значения p’ выводится связанная и классическая вероятность в строках 4 и 5 на рисунке как p_CL = k*p’ и p_C = p’².

Поскольку вероятность связанной маркировки L4S (p_CL) включает коэффициент k, параметры динамического усиления alpha и beta также умножаются на k для очереди L4S. Таким образом, эффективный коэффициент усиления для очереди L4S имеет значение k*alpha (с принятым по умолчанию alpha = 0,16 Гц и k = 2, эффективное значение для L4S alpha = 0,32 Гц).

В отличие от PIE [RFC8033], значения alpha и beta не требуется корректировать в каждом Tupdate с учётом p’. В PI2 значения alpha и beta не зависят от p’, поскольку возведение в квадрат для классического трафика уже настраивает их. Это разъяснено в [PI2], где также указано, почему этот подход устраняет потребность в большей части эвристики, добавленной в PIE.

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

• Классическая и связанная маркировка или отбрасывание (на основе p_C и p_CL от контроллера PI) не применяются к пакету, если размер агрегированной очереди в байтах < 2 MTU (до включения пакета в очередь или извлечения его в зависимости от места применения AQM).

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

Разработчики могут добавлять и другую эвристику, например обычную [RFC8033] или улучшенную [RFC8034] защиту от всплесков (burst).

Примечания

1. Скорость «осушения» может меняться, если она запланирована для двух очередей или учитывает флуктуации беспроводной среды. Для автоматической адаптации к изменениям скорости очередь должна измеряться во времени, а не в байтах или пакетах [AQMmetrics] [CoDel]. Задержку в очереди можно измерить напрямую как время пребывания в очереди путём записи времени постановки в очередь каждого пакета и вычитания его из системного времени при извлечении пакета из очереди. Если временные метки сложно реализовать в оборудовании, задержку в очереди можно предсказать путём деления размера очереди на прогнозируемую скорость выхода, которую можно узнать точно для некоторых сетевых технологий (см., например, DOCSIS PIE [RFC8034]).

   Однако время пребывания неудобно для обнаружения пиков. Например, если всплеск (burst) пакетов попадает в пустую очередь, время пребывания полностью отражает задержку всплеска лишь при извлечении из очереди последнего пакета, хотя размер всплеска известен очереди с момента постановки в неё последнего пакета этого всплеска, и можно было бы сообщить о перегрузке раньше. Для устранения этой проблемы каждый пакет в начале очереди можно помечать при выходе из очереди на основе ожидаемой задержки последнего пакета, как описано ниже, а не по задержке самого пакета в голове очереди из-за предшествующих пакетов. Недогрузка при пиках трафика в [Heist21] указывает конкретный случай, когда всплеск трафика значительно снижает использование очереди L. Если этот эффект будет применяться шире, использование задержки за головой очереди может повысить производительность.

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

2. Строка 2 в функции dualpi2_enqueue() () предполагает реализацию, где lq и cq используют общий буфер в памяти. Другая реализация ACK может использовать разные буферы для каждой очереди и в этом случае прибывающие пакеты нужно сначала классифицировать, чтобы определить какой буфер нужно проверять на предмет наличия места. Выбор подхода определяется компромиссом, поскольку общий буфер позволяет занять меньше памяти, а раздельные буферы изолируют очередь L4S от отбрасывания хвоста из-за больших всплесков классического трафика (например, Classic Reno TCP во время замедленного старта при большом значении RTT).

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

   Рампа применяется чаще, нежели ступени, поскольку оператор может превратить рампу в ступенчатую функцию, используемую в DCTCP, установив нулевой диапазон. В строке 5 на рисунке не возникает деления на 0, поскольку при minTh = maxTh не может возникнуть условий для расчёта рампы.

A.2. Проход 2 — граничные случаи

Этот параграф содержит второй проход по псевдокоду с добавлением деталей для 2 граничных случаев — малой скорости канала и перегрузки. На рисунке повторена функция извлечения из очереди () с деталями для обоих граничных случаев, а рисунок повторяет базовый алгоритм PI () с деталями для перегрузки. Функции инициализации, извлечения из очереди, L4S AQM и recur остаются неизменными.

Скорость канала может быть настолько низкой, что сериализация одного пакета из очереди может занимать время, превышающее пороговую задержку, при которой маркировка ECN начинает применяться для очереди L. Поэтому параметр нижнего порога маркировки требуется задавать в пакетах, а не по времени (Th_len по умолчанию имеет значение в 1 пакет, строка 19 на рисунке ), чтобы рампа гарантированно не вызывала чрезмерной маркировки на медленных каналах. Когда реализация знает скорость канала, она может установить этот минимум во время настройки. Например, величина в 1 MTU будет делиться на скорость канала для получения времени сериализации, затем, если нижний порог рампы Native L AQM меньше этого времени сериализации, реализация может повысить пороги для сдвига верхней части рампы к значению 2 MTU. Такой подход применяется в DOCSIS [DOCSIS3.1], поскольку настроенная скорость канала предназначена для DualQ.

Приведённый здесь псевдокод применяется, когда скорость соединения неизвестна, что характерно для программных реализаций, которые могут быть развёрнуты там, где канал используется совместно с другими очередями. В строках 5a — 5d на рисунке вероятность естественной маркировки L4S (p’_L) обнуляется, если в очереди имеется лишь 1 пакет (в принятой по умолчанию конфигурации).

Примечание для разработчиков Linux. В Linux проверка того, что очередь превышает Th_len перед маркировкой Native L4S AQM фактически выполняется при постановке в очередь, а не при извлечении, поскольку в ином случае это исключило бы маркировку последнего пакета в пике. Результат проверки передаётся от постановки в очередь к извлечению из неё через логическую переменную (флаг) в метаданных пакета.

Считается, что возникла постоянная перегрузка, когда вероятность классического отбрасывания/маркировки достигает p_Cmax. Выше этого порга классическая вероятность отбрасывания применяется к обеим очередям (L и C) независимо от поддержки ECN в пакетах. Пакеты ECT, которые не отброшены, могут помечаться ECN.

В строке 11 функции инициализации () максимальная вероятность классического отбрасывания p_Cmax = min(1/k², 1) или 1/4 для принятого по умолчанию фактора связывания k = 2. На практике было установлено, что 25% является хорошим значением для порога, чтобы сохранить беспристрастность между пакетами с поддержкой и без поддержки ECN. Это защищает очереди как от временной перегрузки отзывчивыми потоками, так и от более продолжительной перегрузки от любого неотзывчивого трафика, которые ложно объявляет реакцию на ECN.

Когда вероятность маркировки Classic ECN достигает порога p_Cmax (1/k²), с ней связывается вероятность для очереди L4S (p_CL), которая будет равна 100% для любого k (в соответствии с уравнением (1) из параграфа 2.1). Поэтому для удобочитаемости константа p_Lmax указана как 1 в строке 21 функции инициализации (). Это сделано для гарантии того, что очередь L4S начнёт отбрасывать пакеты, как только маркировка ECN достигнет 100% и не сможет расти дальше. Требования Prague L4S [RFC9331] указывают, что при обнаружении контролем перегрузки L4S отбрасывания пакета, он возвращается к откликам, сосуществующим с контролем перегрузки Classic. Таким образом, при отбрасывании пакетов очередью L4S правильно отбрасывать их пропорционально p’², как будто они являются классическими.

Каждая из двух очередей проверяет перегрузку в строках 4b и 12b функции извлечения из очереди (). Строки 8c — 8g отбрасывают пакеты L4S с вероятностью p’², строки 8h — 8i маркируют оставшиеся пакеты с вероятностью p_CL. С учётом p_Lmax = 1, все оставшиеся пакеты будут промаркированы, поскольку для достижения блока else в строке 8b должно выполняться условие p_CL >= 1.

1:  dualpi2_dequeue(lq, cq, pkt) {  % Связывает очереди L4S и Classic
2:    while ( lq.byt() + cq.byt() > 0 ) {
3:      if ( scheduler() == lq ) {
4a:       lq.dequeue(pkt)                         % Запланировано L4S
4b:       if ( p_CL < p_Lmax ) {                 % Проверка насыщения
5a:         if (lq.len()>Th_len)                % >1 пакета в очереди
5b:           p'_L = laqm(lq.time())                    % Native LAQM
5c:         else
5d:           p'_L = 0  % Подавление маркировки в очереди с 1 пакетом
6:          p_L = max(p'_L, p_CL)            % Функция комбинирования
7:          if ( recur(lq, p_L)                  %Линейная маркировка
8a:           mark(pkt)
8b:       } else {                                        % Насыщение
8c:         if ( recur(lq, p_C) ) {          % вероятность p_C = p'^2
8e:           drop(pkt) % Возврат к классич. отбрас. из-за перегрузки
8f:           continue                   % Продолжение с начала цикла
8g:         }
8h:         if ( recur(lq, p_CL) )        % Вероятность p_CL = k * p'
8i:           mark(pkt)      % Линейная маркировка оставшихся пакетов
8j:       }
9:      } else {
10:       cq.dequeue(pkt)           % Запланирован классический пакет
11:       if ( recur(cq, p_C) ) {            % Вероятность p_C = p'^2
12a:        if ( (ecn(pkt) == 0)                      % ECN = not-ECT
12b:             OR (p_C >= p_Cmax) ) {    % Перегрузка отключает ECN
13:           drop(pkt)     % Квадратичное отбрасывание, повтор цикла
14:           continue                   % Продолжение с начала цикла
15:         }
16:         mark(pkt)                       % Квадратичная маркировка
17:       }
18:     }
19:     return(pkt)                      % Возврат пакета и остановка
20:   }
21:   return(NULL)                       % Нет пакетов для извлечения
22: }

Рисунок . Пример псевдокода извлечения из очереди для DualQ Coupled PI2 AQM
(включая код для граничных случаев).

Строка 2a базового алгоритма PI () обрабатывает перегрузку очереди L4S, когда классический трафик мал или отсутствует. Это необходимо, поскольку алгоритм PI поддерживает подходящую вероятность отбрасывания для регулирования перегрузки, но это зависит от размера классической очереди. Если классическая очередь мала или её нет, естественная функция обновления PI () ничего не отбрасывает даже при перегрузке очереди L4S, поэтому приходиться принимать на себя функцию отбрасывания хвоста (строки 2 и 3 на рисунке ).

1:  dualpi2_update(lq, cq) {           % Обновление p' в каждом Tupdate
2a:   curq = max(cq.time(), lq.time()) % Использование большего времени
3:    p' = p' + alpha * (curq - target) + beta * (curq - prevq)
4:    p_CL = p' * k  % Coupled L4S prob = base prob * coupling factor
5:    p_C = p'^2             % Классич. вероятн. = (базовая вероятн.)^2
6:    prevq = curq
7:  }

Рисунок . Пример псевдокода обновления PI для DualQ Coupled PI2 AQM
(включая код перегрузки).

Вместо этого строка 2a полной функции обновления PI () гарантирует, что Base PI AQM в строке 3 определяется тем, какая из двух задержек в очередях больше, но строка 3 всегда использует цель Classic (по умолчанию 15 мсек). Если задержка в очереди L больше лишь потому, что классического трафика мало или нет совсем, она обычно все равно гораздо ниже цели Base AQM. Это связано с тем, что трафик L4S регулируется также низким порогом своего Native AQM (строки 5a — 6 алгоритма извлечения из очереди на рисунке ). Таким образом, Base AQM будет сведён к 0 и не внесёт вклада. Однако при перегрузке очереди L трафиком, не отвечающим на маркировку, max() в строке 2a на рисунке позволяет очереди L плавно перевести Base AQM в режим перегрузки даже при отсутствии или малом объёме классического трафика. После этого Base AQM будет сохранять для очереди L классическую цель (по умолчанию 15 мсек) сбрасывая пакеты L.

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

• Рекомендуется понятный планировщик с поддержкой весов, такой как WRR. Поскольку вес для классического трафика мал (например, 1/16), его точное значение не важно, поскольку он обычно не влияет на распределение пропускной способности. Вес важен только для предотвращения краткосрочного истощения классического трафика неотзывчивым трафиком L4S (см. параграф 4.2.2). Это обусловлено тем, что распределение пропускной способности между очередями обычно определяется связанным сигналом перегрузки, который переопределяет действия планировщика, заставляя источники L4S оставлять для классических потоков примерно равную пропускную способность.

• Как вариант, можно применять FIFO со сдвигом по времени (TS-FIFO). Этот механизм выбирает пакет в начале очереди, который ждёт дольше всего, со смещением относительно классического трафика на величину tshift. Для реализации TS-FIFO функция scheduler() в строке 3 кода извлечения из очереди реализуется просто как функция scheduler() в нижней части рисунка в Приложении B. Для общедоступной сети Internet подходит значение tshift = 50 мсек. Для частных сетей с меньшим диаметром, подойдёт значение около 4*target. Планировщик TS-FIFO очень прост, но может потребовать усложнения, связанного с устранением некоторых недостатков (именно поэтому не рекомендуется применять его вместо WRR).

  • TS-FIFO не обеспечивает полной изоляции задержки в очереди L4S от неконтролируемых всплесков в классической очереди;

  • использование времени пребывания для TS-FIFO осмысленно лишь при поддержке для пакетов временных меток;

  • даже при поддержке временных меток время пребывания для пакета из головы очереди всегда «застывшее» (stale), поэтому можно применять более оперативную (мгновенную) меру задержки в очереди (см. примечания в Приложении A.1).

• Планировщик со строгим приоритетом не подходит, как было отмечено в параграфе 4.2.2.

Приложение B. Пример алгоритма DualQ Coupled Curvy RED

В качестве другого примера DualQ Coupled AQM ниже представлен псевдокод на основе алгоритма Curvy-RED. Хотя механизм AQM разработан для целочисленной арифметики, для упрощения понимания сначала используются действительные числа с плавающей запятой (). Затем показана возможная оптимизация для целочисленной арифметики (). Для удобства сравнения нумерация строк на рисунках общая с использованием буквенных суффиксов в добавленных строках.

B.1. Псевдокод Curvy RED

Псевдокод манипулирует 3 основными структурами переменных: пакет (pkt), очередь L4S (lq), классическая очередь (cq). Ниже перечислены 6 функций псевдокода.

• Функция инициализации dualpi2_params_init(…) () устанавливает принятые по умолчанию значения параметров (API для установки других значений опущен для краткости).

• Функция извлечения из очереди dualpi2_dequeue(lq, cq, pkt) ().

• Функция планирования scheduler(), выбирающая пакет в начале одной из 2 очередей.

Используются также перечисленные ниже функции, которые не показаны полностью:

• функция извлечения из очереди, идентичная применяемой в DualPI2 функции dualpi2_enqueue(lq, cq, pkt) ();

• mark(pkt) и drop(pkt) для маркировки ECN и отбрасывания пакета;

• cq.byt() или lq.byt() возвращает текущий размер (backlog) соответствующей очереди в байтах;

• cq.time() или lq.time() возвращает текущую задержку в соответствующей очереди (в единицах времени, см. примечания в Приложении A.1).

Поскольку Curvy RED был оценён до DualPI2, некоторые улучшения для DualPI2 не оценивались в Curvy RED. В приведённом псевдокоде добавлены прямые улучшения на основе допущения, что они обеспечат аналогичные преимущества, но это не было подтверждено экспериментально. Улучшения включают i) планировщик с приоритетом по условию вместо строго приоритета, ii) временной порог для Native L4S AQM и iii) поддержка ECN для Classic AQM. Недавняя оценка показала, что нижний порог маркировки ECN (minTh) значительно повышает производительность, поэтому он включён в псевдокод.

Защита от перегрузки не включена в псевдокод Curvy RED, чтобы не отвлекать внимание от основных характеристик. Её можно добавить таким же способом, как в Приложении A.2 для псевдокода DualPI2. Native L4S AQM использует ступенчатый порог, но можно использовать и рампу, подобно описанной для DualPI2. Планировщик использует простой алгоритм TS-FIFO, но его можно заменить на WRR.

Алгоритм Curvy RED не поддерживался и не оценивался в той же степени, что и DualPI2. В первых экспериментах на каналах широкополосного доступа со скоростью 4 — 200 Мбит/с и базовым RTT от 5 до 100 мсек алгоритм Curvy RED показал хорошие результаты с установленными по умолчанию параметрами, как показано на рисунке .

1:  cred_params_init(...) {       % Установка параметров по умолчанию
2:    % DualQ Coupled framework parameters
3:    limit = MAX_LINK_RATE * 250 ms         % Размер двойного буфера
4:    k' = 1                        % Фактор связывания как степень 2
5:    tshift = 50 ms             % Сдвиг времени планировщика TS-FIFO
6:    % Константы, выведенные из параметров Classic AQM
7:    k = 2^k'                   % Фактор связывания из уравнения (1)
6:
7:    % Параметры Classic AQM
8:    g_C = 5             % Параметр сглаживания EWMA как степень 1/2
9:    S_C = -1    % Фактор масштабирования Classic ramp как степень 2
10:   minTh = 500 ms       % Ниже этой задержки нет Classic drop/mark 
11:   % Константы, выведенные из параметров Classic AQM
12:   gamma = 2^(-g_C)                    % Параметр сглаживания EWMA 
13:   range_C = 2^S_C                         % Диапазон Classic ramp
14:
15:   % Параметры L4S AQM
16:   T = 1 ms          % Порог задержки в очереди для Native L4S AQM
17:   % Константы, выведенные из приведённых выше параметров
18:   S_L = S_C - k'  % Фактор масштабирования L4S ramp как степень 2
19:   range_L = 2^S_L                             % Диапазон L4S ramp
20: }

Рисунок . Пример псевдокода заголовка для DualQ Coupled Curvy RED AQM.

Параметры классифицированы по принадлежности к Classic AQM, L4S AQM и схеме связывания. Константы и переменные, выведенные из этих параметров включены в конце каждой категории. Это исходные (raw) входные параметры алгоритма. Модуль настройки конфигурации может воспринимать более значимые параметры (например, RTT_max и RTT_typ) и преобразовывать их в необработанные (raw), как было сделано для DualPI2 в Приложении A. При необходимости параметры объясняются в псевдокоде.

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

1:  cred_dequeue(lq, cq, pkt) {       % Связывает очереди L4S и Classic 
2:    while ( lq.byt() + cq.byt() > 0 ) {
3:      if ( scheduler() == lq ) {
4:        lq.dequeue(pkt)                           % Запланировано L4S 
5a:       p_CL = (Q_C - minTh) / range_L
5b:       if ( ( lq.time() > T )
5c:          OR ( p_CL > maxrand(U) ) )
6:          mark(pkt)
7:      } else {
8:        cq.dequeue(pkt)                       % Запланировано Classic 
9a:       Q_C = gamma * cq.time() + (1-gamma) * Q_C % Classic Q EWMA
10a:      sqrt_p_C = (Q_C - minTh) / range_C
10b:      if ( sqrt_p_C > maxrand(2*U) ) {
11:         if ( (ecn(pkt) == 0)  {                     % ECN = not-ECT
12:           drop(pkt)       % Квадратичное отбрасывание, повтор цикла
13:           continue                     % Продолжение с начала цикла
14:         }
15:         mark(pkt)
16:       }
17:     }
18:     return(pkt)                        % Возврат пакета и остановка
19:   }
20:   return(NULL)                          % Нет пакета для извлечения
21: }
22: maxrand(u) {      % Возвращает максимальное из u случайных значений 
23:   maxr=0
24:   while (u-- > 0)
25:     maxr = max(maxr, rand())                   % 0 <= rand() < 1
26:   return(maxr)
27: }
28: scheduler() {
29:   if ( lq.time() + tshift >= cq.time() )
30:     return lq;
31:   else
32:     return cq;
33: }

Рисунок . Пример псевдокода извлечения из очереди для DualQ Coupled Curvy RED AQM.

Код предполагает применение AQM при извлечении из очереди¹¹. Весь код извлечения из очереди размещён в большом цикле while поэтому при отбрасывании пакета процесс будет продолжаться, пока не будет выбран пакет для планирования. Если обе очереди пусты, функция возвращает NULL в строке 20. Строка 3 определяет очередь (L4S (lq) или Classic (cq)), из которой планировщик с условным приоритетом возьмёт пакет. Планировщик TS-FIFO, показанный в строках 28-33, подойдёт, если простота имеет первостепенное значение¹². В каждой очереди решение о пересылке, отбрасывании или маркировке принимается, как описано ниже (для простоты принимается U = 1):

L4S

Classic

Функции AQM в каждой очереди (строки 5c и 10b) являются вариантами нового обобщённого механизма RED, называемого Curvy RED. Когда производительность этого AQM сравнивалась с FQ-CoDel и PIE, цель удержать задержку в очереди на фиксированном уровне сочли ошибочной [CRED_Insights]. Если по мере роста числа потоков AQM не позволяет контроллерам перегрузки на хосте увеличивать задержку в очереди, контроллер будет вносить аномально высокие потери и они, а не очереди, становятся основной причиной задержки коротких потоков из-за тайм-аутов и отбрасывания в хвосте очереди.

Curvy RED ограничивает задержку со смягчённой целью, что позволяет некоторое увеличение задержки при росте нагрузки. Это достигается путём увеличения вероятности отбрасывания на выпуклой кривой относительно роста скорости (квадратичная кривая в классической очереди при U = 1). Как и в RED, кривая огибает нулевое значение оси, пока очередь неглубокая. По мере роста нагрузки вводится возрастающий барьер для высокой задержки. Но, в отличие от RED, используется два параметра, а не три. Недостатком Curvy RED (например, по сравнению с PI) является неприспособленность к широкому диапазону RTT. Curvy RED можно использовать в неизменном виде при ограниченном диапазоне RTT, а иных случаях требуется механизм адаптации.

По результатам ограниченных экспериментов с Curvy RED рекомендуются значения S_C = -1, g_C = 5, T = 5 * MTU при скорости канала (около 1 мсек для 60 Мбит/с) для типичного в общедоступной сети Internet диапазона RTT. В [CRED_Insights] объяснено, почему эти параметры применимы независимо от скорости канала, на котором развёрнута эта реализация AQM и как нужно скорректировать параметры для другого диапазона RTT (например, в ЦОД). Установка k определяется политикой (см. параграф 2.5 и C.2, где указаны значения по умолчанию и варианты).

Имеется также параметр кривизны (cUrviness, U), который задаётся небольшим целым числом. Скорей всего, он будет иметь жёстко заданное значение для всех реализаций по завершении экспериментов. До сих пор эксперименты проводились при U = 1, но результаты могут оказаться лучше при U = 2 или выше.

B.2. Эффективная реализация Curvy RED

Хотя оптимизация кода зависит от платформы, ниже приведены разъяснения эффективности реализации Curvy RED как мотива.

Classic AQM в строке 10b на рисунке вызывается функция maxrand(2*U), что даёт вдвое большую кривизну, нежели maxrand(U), для функции маркировки в строке 5c. Этот трюк реализует правило квадрата в уравнении (1) из параграфа 2.1 на основе того, что при заданном X от 1 до 6 вероятность того, что при двух бросках кости выпадут значения меньше X равна квадрату вероятности того, что при одном броске выпадет значение меньше X. Поэтому при U = 1 функция маркировки L4S линейна, а функция классического отбрасывания квадратична. При U = 2 функция L4S будет квадратичной, а классическая — четвёртой степени и т. д.

Функция maxrand(u) в строках 22-27 просто генерирует u случайных значений и возвращает большее из них. Обычно maxrand(u) можно запускать параллельно. Например, при U = 1 для классической очереди требуется не более 2 случайных значений, поэтому вместо вызова maxrand(2*U) в основном потоке исполнения максимальное значение в каждой паре от генератора псевдослучайных чисел можно получить отдельно и держать в буфере, готовом для передачи в классическую очередь.

1:  cred_dequeue(lq, cq, pkt) {   %  Связывает очереди L4S и Classic
2:    while ( lq.byt() + cq.byt() > 0 ) {
3:      if ( scheduler() == lq ) {
4:        lq.dequeue(pkt)                        % Запланировано L4S
5:        if ((lq.time() > T) OR (Q_C >> (S_L-2) > maxrand(U)))
6:          mark(pkt)
7:      } else {
8:        cq.dequeue(pkt)                    % Запланировано Classic
9:        Q_C += (qc.ns() - Q_C) >> g_C             % Classic Q EWMA
10:       if ( (Q_C >> (S_C-2) ) > maxrand(2*U) ) {
11:         if ( (ecn(pkt) == 0)  {                  % ECN = not-ECT
12:           drop(pkt)       % Квадратный корень, продолжение цикла
13:           continue            % Продолжение с начала цикла while
14:         }
15:         mark(pkt)
16:       }
17:     }
18:     return(pkt)                     % Возврат пакета и остановка
19:   }
20:   return(NULL)                       % Нет пакета для извлечения
21: }

Рисунок . Оптимизированный пример псевдокода извлечения из очереди для DualQ Coupled AQM с использованием целочисленной арифметики.

Диапазоны range_L и range_C выражаются степенью 2, поэтому деление в строках 5 и 11 можно выполнить побитовым сдвигом вправо (bit-shift, >>) для целочисленного варианта псевдокода (). Для этого варианта целочисленная версия функции rand(), используемая в строке 25 функции maxrand() на рисунке будет возвращать целое число 0 <= maxrand() < 2³² (не показано), что будет умножать действительное значение вероятности из диапазона [0,1] на 2³². Задержки в очереди также будут умножаться на 2³², но в два этапа: i) в строке 9 время в очереди qc.ns() возвращается как целое число наносекунд, которое примерно в 2³⁰ больше числа секунд, а ii) в строках 5 и 10, исключение (-2) двух позиций при сдвиге вправо ведёт к увеличению результата в 2² раза для полного умножения на 2³². В строке 8 функции инициализации константа EWMA gamma (g_C) представлена целочисленной степенью 2, поэтому в строке 9 целочисленного кода () требуется деление для взвешивания скользящего среднего значения, которое можно реализовать сдвигом вправо (>> g_C).

Приложение C. Выбор фактора связывания k

C.1. Зависимость от RTT

Когда классические потоки конкурируют за общую пропускную способность, относительные скорости этих потоков зависят не только от вероятности перегрузки, но и от сквозных значений RTT (базовый RTT + задержка в очереди). Скорости потоков Reno [RFC5681], конкурирующих через AQM, примерно обратно пропорциональны их RTT. В CUBIC зависимость от RTT в режиме совместимости с Reno такая же, но в других режимах механизм меньше зависит от RTT.

До первых экспериментов с DualQ Coupled AQM важность достаточно большой классической очереди для снижения зависимости от RTT при низком значении базового RTT не была должным образом оценена. В Приложении A.1.6 к спецификации протокола L4S ECN Protocol [RFC9331] приведены численные примеры, объясняющие, почему раздутые буферы скрывали зависимость классического контроля перегрузки от RTT. Там же разъяснено, почему большее сокращение задержки в очередях усиливает зависимость от RTT — проблема возможного истощения потоков с большим RTT при конкуренции с потоками, имеющими малое значение RTT.

С учётом добровольности контроля перегрузки в конечных системах, нет причин для их добровольной зависимости от RTT. Эту зависимость классического трафика от RTT невозможно «свернуть» (исключить), поэтому [RFC9331] требует от контроля перегрузки L4S значительного сокращения зависимости от RTT по сравнению со стандартным контролем перегрузки [RFC5681], по меньшей мере, при малом RTT. Зависимость от RTT должна быть не хуже, чем при использовании классических буферов подходящего размера. В соответствии с этим подходом сетевым устройствам не требуется решать проблему зависимости от RTT, хотя от этого не было бы никакого вреда, что по сути и делают очереди по потокам.

C.2. Рекомендации по контролю эквивалентности пропускной способности

Фактор связывания k определяет баланс между скоростями потоков L4S и Classic (см. параграф 2.5.2.1 и уравнение (1) в параграфе 2.1). Для общедоступной сети Internet рекомендуется значение k = 2 и обоснование этого дано ниже. Для других сред подходящее значение фактора связывания можно получить подстановкой в уравнение соответствующих значений.

Приведённые ниже математические выкладки ведут к уравнению (7), показывающему, что k = 1,64 теоретически выравнивает пропускную способность L4S и Classic, если сквозные значения RTT для них одинаковы. Однако даже при совпадении базовых RTT фактические значения RTT могут различаться потому, что классическому трафику нужна достаточно длинная очередь для предотвращения недогрузки канала, а для L4S это не нужно.

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

В последующем рассмотрении применяются указанные ниже обозначения.

   r - скорость пакетов [пакет/сек]
   R - RTT [сек/обход]
   p - вероятность маркировки ECN []

С классической стороны Reno представляется наиболее чувствительным и, следовательно, наихудшим классическим средством контроля перегрузки. CUBIC в режиме Reno-friendly (CReno) рассматривается как наиболее распространённый механизм контроля перегрузок, согласно ссылкам и анализу [PI2param]. В любом случае скорость классических пакетов в установившемся состоянии определяется известной формулой квадратного корня для Reno:

       r_C = 1,22 / (R_C * p_C^0,5)          (5)

Со стороны L4S контроль перегрузки Prague [PRAGUE-CC] представляется эталоном для установившегося состояния зависимости от перегрузки. Prague соответствует тому же уравнению, что и DCTCP, но уравнение из описания DCTCP не используется здесь, поскольку оно подходит лишь для ступенчатой маркировки. Связанная маркировка p_CL подходит при рассмотрении эквивалентности пропускной способности с классическими потоками. В отличие от ступенчатой маркировки связанная по своей природе разнесена, поэтому используется формула для скорости пакетов DCTCP с вероятностной маркировкой, выведенную в Приложении A к [PI2]. Уравнение применяется без включения независимости от RTT (это объясняется позже).

       r_L = 2 / (R_L * p_CL)                (6)

Для эквивалентности скорости потоков приравниваются скорости двух пакетов и уравнение приводится к тому же виду, что и уравнение (1) (скопировано из параграфа 2.1), чтобы их можно было приравнять и упростить для получения теоретического значения фактора связывания k*

       r_c = r_L
   =>  p_C = (p_CL/1,64 * R_L/R_C)^2.
       p_C = ( p_CL / k )^2.                 (1)
       k* = 1,64 * (R_C / R_L).              (7)

Фактор связывания назван теоретическим, поскольку он выражается через два RTT, что вызывает два практических вопроса — i) для нескольких потоков с разными RTT, где RTT для каждого класса трафика выводится из RTT всех потоков этого класса (фактически требуется среднее гармоническое значение), и ii) узел сети не может легко узнать RTT потоков.

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

Эквивалентность пропускной способности определяется для потоков при сравнимых условиях, включая одинаковые базовые значения RTT [RFC2914]. Если принять одинаковые базовые RTT (R_b) для сопоставимых потоков, можно выразить R_C и R_L через R_b. Можно аппроксимировать L4S RTT значением чуть больше базового RTT, т.,е R_L ~= R_b. R_C заменяется суммой (R_b + q_C), где значение q_C для классической очереди зависит от целевой задержки в очереди, которую оператор настроил для Classic AQM.

Приняв PI2 как пример Classic AQM, можно просто взять R_C = R_b + target (по умолчанию рекомендуется 15 мсек в Приложении A.1). Однако значение target приблизительно равно глубине очереди по вершинам зубьев пилы в контроле перегрузки, а не среднему значению [PI2param]. Таким образом, R_max = R_b + target. Положение среднего значения относительно максимума зависит от амплитуды и формы зубьев. Рассмотрим два примера: Reno [RFC5681], как наиболее чувствительный худший случай, и CUBIC [RFC8312] в режиме Reno-friendly (Creno), как наиболее распространённый алгоритм контроля перегрузок в Internet, согласно ссылкам из [PI2param]. Оба используют аддитивное увеличение и мультипликативное снижение (Additive Increase Multiplicative Decrease или AIMD), поэтому можно обобщить, используя b как фактор мультипликативного сокращения (b_r = 0,5 для Reno, b_c = 0,7 для CReno).

R_C  = (R_max + b*R_max) / 2
     = R_max * (1+b)/2.
R_reno = 0,75 * (R_b + target);    R_creno = 0,85 * (R_b + target)  (8)

Подстановка в уравнение (7) даёт при любом конкретном RTT (R_b) фиксированный фактор для каждого

   k_reno = 1,64*0,75*(R_b+target)/R_b
          = 1,23*(1 + target/R_b);    k_creno = 1,39 * (1 + target/R_b).

Оператор может выбрать базовое значение RTT, при котором он хочет получить эквивалентную пропускную способность. Например, при выборе R_b = 25 мсек как типичного базового RTT между пользователями Internet и CDN [PI2param] фактор связывания будет

   k_reno = 1,23 * (1 + 15/25)        k_creno  = 1,39 * (1 + 15/25)
          = 1,97                               = 2,22
          ~= 2,                                ~= 2,                 (9)

Такая аппроксимация применима для любого из рассмотренных выше алгоритмов Coupled DualQ, использующему фактор связывания со значением степени 2 для эффективной целочисленной реализации. Он хорошо подходит и для худшего случая (Reno).

Для проверки этого фактора связывания можно выразить отношение пропускных способностей L4S и Classic подстановкой их скоростей из уравнений (5) и (6), а также подстановкой p_C, выраженного через p_CL с использованием уравнения (1) с k = 2, как было указано для Internet

   r_L / r_C  = 2 (R_C * p_C^0,5) / 1,22 (R_L * p_CL)
              = (R_C * p_CL) / (1,22 * R_L * p_CL)
              = R_C / (1,22 * R_L).                                 (10)

В качестве примера можно рассмотреть конкурирующие одиночные потоки CReno и Prague, выразив их RTT с помощью уравнения (10) через базовые RTT (R_bC и R_bL). Таким образом, R_C заменяется уравнением (8) для CReno, а R_L — функцией max(), приведённой ниже, которая представляет эффективное значение RTT для текущего контроля перегрузок [PRAGUE-CC] в принятом по умолчанию режиме независимости от RTT, поскольку это будет нижний порог эффективного RTT, применяемый для аддитивного увеличения.

   r_L / r_C ~= 0,85 * (R_bC + target) / (1,22 * max(R_bL, R_typ))
             ~= (R_bC + target) / (1,4 * max(R_bL, R_typ)).

Можно видеть, что для базовых RTT меньше target (15 мсек) числитель и знаменатель находятся на плато, что даёт желаемое ограничение зависимости от RTT.

В начале приведённых выше выкладок было обещано объяснение причины того, что приравнивание пропускной способности L4S в уравнении (6) не требуется для моделирования независимости от RTT. Это обусловлено использованием лишь одной точки с типичным значением базового RTT, выбранным оператором для расчёта фактора связывания. Эквивалентность пропускной способности будет наблюдаться, по меньшей мере, в этой точке. Тем не менее, если предположить, что отправитель Prague реализует независимость от RTT в диапазоне RTT ниже этого значения, эквивалентность пропускной способности будет распространяться и на этот диапазон.

Разработчики средств контроля перегрузок могут выбрать разные способы снижения зависимости от RTT. Каждый оператор может выбрать своё значение базового RTT и, следовательно, другое значение k, при котором он хочет получить эквивалентную пропускную способность. Тем не менее, для Internet имеет смысл выбрать значение, которое представляется типичным RTT для большинства пользователей, поскольку целевая задержка в очереди Classic AQM также выводится из типичного значения RTT для Internet.

В качестве примера, не связанного с Internet, для локализованного трафика из ЦОД конкретного ISP с использованием измеренных значений RTT было рассчитано, что значение k = 8 обеспечит эквивалентность пропускной способности и эксперименты подтвердили это с высокой точностью.

Для типовой смеси значений RTT в общедоступной сети Internet рекомендуется значение k = 2 как рабочий компромисс.

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

Спасибо Anil Agarwal, Sowmini Varadhan, Gabi Bracha, Nicolas Kuhn, Greg Skinner, Tom Henderson, David Pullen, Mirja Kühlewind, Gorry Fairhurst, Pete Heist, Ermin Sakic, Martin Duke за подробные комментарии в рецензиях (особенно к приложениям), а также за предложения по улучшению разъяснений. Спасибо Tom Henderson за сведения о выборе планировщиков и методов измерения задержки в очереди. Спасибо рецензентам направления (area) Christer Holmberg, Lars Eggert, Roman Danyliw.

Начальная работа Koen De Schepper, Bob Briscoe, Olga Bondarenko, Inton Tsang частично финансировалась European Community по программе Seventh Framework Programme в рамках проекта Reducing Internet Transport Latency (RITE)(ICT-317700). Работа Koen De Schepper и Olivier Tilmans частично финансировалась по проектам 5Growth и DAEMON EU H2020. Работу Bob Briscoe частично финансировала Comcast Innovation Fund и Research Council of Norway в рамках проекта TimeIn. Выраженные здесь мнения принадлежат исключительно авторам.

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

Ниже перечислены те, кто внёс вклад в реализации и оценки, которые подтвердили и помогли улучшить эту спецификацию. Olga Albisser <olga@albisser.org> из Simula Research Lab, Norway (Olga Bondarenko в ранних черновиках) реализовала прототип DualPI2 AQM для Linux вместе с Koen De Schepper и провела обширные оценки, а также разработала GUI [L4Sdemo16] для визуализации производительности в реальном масштабе времени. Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> из Nokia Bell Labs, Belgium подготовил и поддерживает реализацию Linux DualPI2. Shravya K.S. написал модель для имитатора ns-3 на основе draft-ietf-tsvwg-aqm-dualq-coupled-01 (черновой вариант этого документа). На основе этой работы Tom Henderson <tomh@tomh.org> обновил модель и создал модель для варианта DualQ, указанного как часть спецификации Low Latency DOCSIS, а также выполнил различные оценки. Ing Jyh (Inton) Tsang изи Nokia, Belgium построил тестовый стенд для сквозной доставки между ЦОД и домом, где проверялись реализации DualQ Coupled AQM.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                    K. De Schepper
Request for Comments: 9331                               Nokia Bell Labs
Category: Experimental                                   B. Briscoe, Ed.
ISSN: 2070-1721                                              Independent
                                                            January 2023

The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)

Протокол явных уведомлений о перегрузке для архитектуры L4S

PDF

Аннотация

Эта спецификация определяет протокол, который будет применяться для новой сетевой услуги, названной L4S¹. В L4S используется схема явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) на уровне IP, похожая на исходный («классический») подход ECN с некоторыми отличиями. L4S использует расширяемый (Scalable) контроль перегрузок, включающий более частые сигналы управления из сети и реагирующий на эти сигналы более детальными настройками, так что для трафика L4S становится возможной очень малая (обычно доли миллисекунды в среднем) и стабильная задержка в очередях без ущерба для загрузки каналов. Таким образом, даже трафик, которому нужна пропускная способность (подобный TCP), может получить одновременно высокую пропускную способность и очень малые задержки даже в периоды высокой загрузки.

Определённый в этом документе идентификатор L4S отличает трафик L4S от «классического» (например, TCP-Reno-friendly). Узкие места в сети (bottleneck) могут постепенно обновляться, чтобы отличать и изолировать остающийся «классический» трафик без его ухудшения из-за трафика L4S. Эта экспериментальная спецификация определяет правила для транспорта L4S и элементов сети, чтобы потоки L4S не наносили ущерба производительности друг друга и «классического» трафика. Некоторые вопросы остаются не решёнными и требуют дополнительных исследований. Отдельно приведены примеры новых алгоритмов маркировки для активного управления очередями (Active Queue Management или AQM) и нового транспорта (подобного TCP или трафику в реальном масштабе времени).

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

Документ не относится к категории Internet Standards Track и публикуется для проверки, экспериментальной реализации и оценки.

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

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

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

Авторские права (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. Введение

Эта спецификация определяет протокол, который будет применяться для новой сетевой услуги, названной L4S. В L4S используется схема ECN на уровне IP с тем же набором кодов (и переходами), как в исходном ECN [RFC3168]. [RFC3168] требует, чтобы маркировка ECN была эквивалентна отбрасыванию (drop) при использовании как в сети, так и при откликах транспорта. В отличие от классической маркировки i) сеть применяет маркировку L4S более оперативно и часто, нежели отбрасывание, и ii) реакция транспорта на каждый маркер ускоряется и сглаживается по сравнению с реакцией на отбрасывание. Эти два изменения уравновешивают друг друга и пропускная способность для потока L4S будет сопоставима с потоками без L4S при одних условиях. Тем не менее, более частые сигналы управления ECN и ускоренный отклик на эти сигналы приводят к очень малым задержкам в очередях без ущерба для загрузки каналов и такая низкая задержка может обеспечиваться при высокой нагрузке. Например, задержка постановки в очередь при высокой и сильно меняющейся нагрузке ов описанном ниже примере решения DCTCP/DualQ на канале DSL или Ethernet в среднем составляет доли миллисекунды и примерно 1 — 2 мсек при 99-м процентиле без вреда для использования канала [L4Seval22] [DualPI2Linux]. Отметим, что к отмеченному следует добавлять задержку в очереди доступа к среде передачи, такой как беспроводный канал. Эту задачу также требуется решить, но отдельно (см. параграф 6.3 в описании архитектуры L4S [RFC9330]).

L4S полагается на расширяемые (Scalable) средства контроля перегрузок для снижения задержки и сохранения малой задержки при расширении потоков (отсюда и название). Контроль перегрузок в Data Center TCP (DCTCP) служит примером расширяемого контроля, но DCTCP применяется исключительно в контролируемых средах, таких как ЦОД [RFC8257] по причине избыточной для сосуществования с трафиком TCP-Reno-friendly энергичности. Механизм Dual-Queue Coupled AQM, заданный в дополняющей этот документ экспериментальной спецификации [RFC9332], представляет собой платформу AQM, позволяющую расширяемым средствам контроля перегрузок на основе DCTCP, сосуществовать с имеющимся трафиком, предоставляя обоим примерно одинаковую скорость потока в похожих условиях. Отметим, что расширяемый контроль перегрузок остаётся небезопасным для развёртывания в Internet, пока не выполняются требования, указанные в разделе .

Архитектура L4S предназначена не только для эластичного трафика (похожего на TCP) и имеется расширяемый контроль перегрузок для потоков в реальном масштабе времени (real-time media), такой как вариант L4S [SCReAM-L4S] из SCReAM [RFC8298] методов предотвращения перегрузки среды (RTP Media Congestion Avoidance Techniques или RMCAT). Поведение трафика L4S отличается от классического в части откликов на перегрузку. Протоколы транспортных соединений, такие как TCP, QUIC, SCTP⁴, DCCP⁵, RTP/RTCP ортогональны и по этой причине не позволяют отличать пакеты L4S от классических.

Заданный в этом документе идентификатор L4S является ключевым отличием трафика L4S от «классического» (например, Reno-friendly). Узкие места в сети можно поэтапно изменять для идентификации и изоляции имеющегося классического трафика от L4S с целью предотвратить негативное влияние на классический трафик в результате снижения уровня задержки и потерь для нового масштабируемого транспорта. Хотя для получения преимуществ требуется развёртывание у отправителей и в сети возможные в будущем преимущества послужили стимулом для первоначального внедрения отдельных частей системы.

1.1. Вопросы задержки, потерь и масштабирования

Задержки становятся критически важным фактором производительности для многих (возможно, большинства) приложений Internet, например, интерактивных web-приложений и служб, передачи, видео со звуком, интерактивного видео, удалённого присутствия, мгновенного обмена сообщениями, сетевых игр, удалённых рабочих столов, облачных приложений и служб, а также удалённого управления оборудованием и производственными процессами. Во многих частях мира дальнейший рост битовой скорости сетей доступа ведёт к замедлению отдачи [Dukkipati06] пока задержки остаются проблемой. В результате было многое сделано для сокращения времени распространения за счёт кэширования и переноса серверов ближе к пользователям. Однако очереди остаются основным, хотя и меняющимся компонентом задержки.

Архитектура Diffserv обеспечивает ускоренную пересылку (Expedited Forwarding или EF) [RFC3246], где трафик с малой задержкой может переноситься в очередь другого трафика. Если рост чувствительных к задержке приложений продолжится, периоды лишь с чувствительным к задержкам трафиком будут составлять все большую часть на каналах со слабым агрегированием трафика. Если в течение таких периодов для всего трафика применяется одинаковая обработка, Diffserv становится бесполезным. Каналы со слабым агрегированием также обычно становятся узким местом на пути под нагрузкой, например, это может происходить на каналах доступа, выделенных для отдельных сайтов (дом, небольшое предприятие, мобильное устройство). Таким образом, вместо дифференциации требуется исключить первопричины всех необязательных задержек.

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

Для решения этой и других проблем был разработан механизм AQM. В отличие от Diffserv, где низкая задержка для некоторого трафика обеспечивается за счёт другого трафика, AQM контролирует задержку для всего трафика в классе. В общем случае методы AQM повышают уровень отбрасывания из буферов по мере превышения очередью небольшого заданного порогового размера. Это обеспечивает достаточную сигнализацию для потоков, которым нужна пропускная способность (жадных потоков), чтобы сохранить буферное пространство для основной цели — смягчения (поглощения) пиков. Однако случайное раннее обнаружение (Random Early Detection или RED) и другие алгоритмы 1990-х годов были чувствительны к конфигурации и сложны в настройке [RFC7567]. Поэтому механизмы AQM не получили широкого распространения.

Более современные методы AQM, такие как Flow Queue CoDel [RFC8290], PIE⁶ [RFC8033], Adaptive RED [ARED01], проще в настройке, поскольку они задают пороги для очередей временем, а не числом байтов и конфигурация не меняется в зависимости от скорости канала. Однако «окно пилы» (sawtoothing window) классического контроля перегрузок создаёт для оператора дилемму — i) настроить неглубокую (shallow) рабочую точку AQM, чтобы верхушки зубьев пилы вызывали минимальную задержку в очереди, но тогда канал в остальном используется не полностью, или ii) задать более глубокую рабочую точку в буфере для более эффективного использования канала, но в этом случае пики будут вызывать большие изменения задержки. Даже при совершенной настройке AQM дополнительная задержка в очереди для пиков пилы будет иметь такой же порядок значений, что и базовый интервал кругового обхода (round-trip time или RTT), фактически удваивая суммарное значение RTT.

Если само поведение отправителя вносит вариации задержки, никакой механизм AQM в сети не сможет «отменить» такую задержку без существенного ущерба для использования канала. Даже постановка потока в очередь, изолирующая его от других потоков (например, [RFC8290]), не может воспрепятствовать вариациям задержки, которые создаёт сам поток. Поэтому приложениям, которым нужна высокая пропускная способность и малая задержка, придётся перейти к расширяемому контролю перегрузок, где не возникает значительных пилообразных вариаций.

Однако простой смены поведения хоста недостаточно. Даже при реализации хостом расширяемых элементов контроля перегрузки с малой задержкой требуется изоляция больших вариаций очереди, вносимых имеющимися классическими элементами контроля перегрузки. Механизмы L4S AQM обеспечивают изоляцию задержки в сети, а идентификатор L4S позволяет AQM отличать пакеты L4S от классических. Изоляцию L4S можно обеспечить организацией очередей по потокам (например, [RFC8290]), до DualQ [RFC9332] вполне достаточно и механизм фактически обеспечивает лучшую задержку в «хвосте» [DCttH19]. В этом документе рассматриваются оба подхода.

Решение DualQ было разработано для обеспечения очень малой задержки без создания очередей по потокам в каждом узком месте. Это было полезно, поскольку очереди по потокам (per-flow queuing или FQ) имеют известные недостатки (не в последнюю очередь необходимость просмотра в сети заголовков транспортного уровня), которые делают это решение несовместимым с подходами к приватности, такими как туннели виртуальных частных сетей IPsec (Virtual Private Network или VPN), или управлением очередями на канальном уровне, где транспортные заголовки могут быть скрыты (например, 5G).

Задержки не являются единственной проблемой L4S. При первоначальной разработке механизма предотвращения перегрузок в TCP было известно, что их не удастся расширить для больших произведений пропускной способности и задержки (bandwidth-delay, см. примечание 6 от Jacobson и Karels [TCP-CA]). С учётом выхода Reno за рамки расширяемости уже при обычных скоростях широкополосных сетей WAN [RFC3649], были внедрены «более расширяемые» варианты TCP CUBIC [RFC8312] и Compound [CTCP]. Однако они тоже не решают задачу расширяемости. К сожалению, полностью расширяемые (fully Scalable) механизмы контроля перегрузок, такие как DCTCP [RFC8257], превосходят Classic ECN лишь при использовании общей очереди, поэтому они развёрнуты лишь в частных ЦОД и испытательных стендах.

Эти расширяемые алгоритмы контроля перегрузок, решающие проблему задержки, могут решить также проблему расширяемости классических элементов контроля перегрузки. Более тонкие (finer) зубья пилы в окне перегрузки (congestion window или cwnd) имеют меньшую амплитуду, поэтому они вызывают очень незначительные вариации задержки, а среднее время восстановления от одного сигнала перегрузки до следующего (средняя продолжительность зубы пилы) остаётся неизменным, что обеспечивает постоянный жёсткий контроль при изменении скорости потока. В статье [L4Seval22] дано полное объяснение этого факта как на простом языке, так и в более точной математической форме. Без математических выкладок объяснение приведено также в разделе 4 описания архитектуры L4S [RFC9330].

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

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

Classic Congestion Control — классический контроль перегрузок

Scalable Congestion Control — расширяемый контроль перегрузок

Classic Service — классический сервис

Low Latency, Low Loss, and Scalable throughput (L4S) service — сервис с малыми задержками и потерями, а также расширяемой пропускной способностью

Reno-friendly — совместимость с Reno

Classic ECN — классический механизм явных уведомлений о перегрузке

Site — сайт

1.3. Область действия

Новый идентификатор L4S, заданный в этой спецификации, применим к пакетам IPv4 и IPv6 (как и Classic ECN [RFC3168]). Он подходит для индивидуальной (unicast), групповой (multicast) и anycast-пересылки.

Идентификатор L4S ортогонален классификации пакетов по кодам дифференцированного обслуживания (Differentiated Services Code Point или DSCP) [RFC2474]. Практическое значение этого рассмотрено в параграфе .

Этот документ является экспериментальным и не обновляет какие-либо Standards Track RFC и зависит от [RFC8311] со статусом Standards Track, который:

• обновляет ECN Proposed Standard [RFC3168], позволяя Experimental RFC смягчать требование эквивалентности маркировки ECN отбрасыванию пакета (при маркировке в сети или на отвечающем хосте); например, в эксперименте Alternative Backoff with ECN (ABE) [RFC8511] это смягчение позволяет отправителю слабее реагировать на маркировку ECN, нежели на отбрасывание;

• меняет статус спецификации Experimental ECN nonce [RFC3540] на Historic (устарела);

• вносит соответствующие изменения в перечисленные ниже Proposed Standard RFC:

  • ECN для RTP [RFC6679];

  • спецификации контроля перегрузки различных профилей идентификаторов контроля перегрузки DCCP (Congestion Control Identifier или CCID) [RFC4341] [RFC4342] [RFC5622].

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

2. Идентификация пакетов L4S — структура документа

Обработка маркировки L4S ECN является экспериментальной альтернативой обработке Classic ECN [RFC3168], обновлённой в [RFC8311], чтобы можно было проводить эксперименты, подобные описанным здесь. В [RFC4774] рассмотрены некоторые проблемы и критерии оценки для определения дополнительной семантики ECN, которые обсуждаются также в параграфе .

Архитектура L4S [RFC9330] включает 3 основных компонента: поведение передающего хоста, маркировка в сети и протокол L4S ECN для идентификации пакетов L4S.

В разделе указаны требования, на основании которых был выбран идентификатор L4S. Далее описывается протокол L4S ECN, который i) идентифицирует переданные хостами пакеты, для которых предполагается разнообразное поведение при передаче, и ii) задаёт трактовку маркеров, установка которых ожидается для пакетов L4S на узлах сети.

Чтобы пакет при пересылке трактовался как L4S, отправитель устанавливает в поле ECN заголовка IP код ECT(1). В разделе указаны требования к поведению транспортного уровня, включая обратную связь и реагирование на перегрузку.

Узел сети, реализующий службу L4S, всегда классифицирует пакеты ECT(1) для обработки L4S и по умолчанию классифицирует для такой обработки пакеты CE, если не применяются эвристические методы из параграфа 5.3. Полные требования к поведению элементов сети заданы в разделе 5, включая классификацию, маркировку ECN и взаимодействие идентификаторов L4S с другими идентификаторами, а также поэтапную пересылку.

L4S ECN работает с туннелированием и инкапсуляцией ECN, за исключением одного известного случая, когда нужно особое внимание к конфигурации, рассмотренного подробно в разделе .

Эта спецификация L4S ECN имеет статус экспериментальной. В разделе 7 собраны общие вопросы и проблематика, требующие дальнейшего изучения в ходе экспериментов с L4S. Нерешенные вопросы и проблемы, относящиеся к определенным компонентам, рассмотрены в соответствующих спецификациях, таких как DualQ [RFC9332].

Назначение агентством IANA идентификатора L4S рассмотрено в разделе 8, а раздел 9 посвящён вопросам безопасности, связанным с идентификаторами L4S. Вопросы безопасности системы, такие как правила и приватность, рассмотрены в описании архитектуры L4S [RFC9330].

3. Требования к выбору идентификатора пакетов L4S

В этом разделе кратко описан процесс, в результате которого был выбран идентификатор L4S.

Идентификатору для пакетов L4S следует соответствовать указанным ниже требованиям:

• сквозное прохождение между конечными точками источника и получателя через границы между хостом и сетью, смежными сетями, а также через промежуточные устройства (middlebox);

• видимость на уровне IP;

• эквивалентность для IPv4 и IPv6, независимость от транспорта;

• возможность поэтапного внедрения;

• возможность AQM классифицировать пакеты, инкапсулированные в IP и протоколы нижележащего уровня;

• минимальное число дополнительных кодов (codepoint);

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

Можно было бы учесть фактор восстановления идентификатора при отказе эксперимента. Однако это не требовалось, поскольку давало бы преимущество схемам, где шансы провала превышали вероятность успеха. Было признано, что вряд ли какой-то идентификатор будет соответствовать всем приведённым требованиям, особенно с учётом ограниченности оставшегося пространства в заголовках IP. Поэтому во всех случаях будет нужен компромисс и при указании требования использовать уровень следует (SHOULD), а не необходимо (MUST).

После тщательной оценки разных схем в качестве компромисса был выбран вариант с кодами ECT(1) и CE. Этот выбор подробно описан ниже, а в Приложении B указаны его плюсы и минусы в соответствии с приведёнными требованиями.

4. Поведение транспортного уровня (требования Prague L4S)

В этом разделе заданы требования к поведению L4S на транспортном уровне, известные как Prague L4S Requirements (происхождение названия объяснено в Приложении A).

4.1. Установка кода

Отправитель, желающий для пакета обработки L4S при его пересылке, должен указать в поле ECN заголовка IP (v4 или v6) код ECT(1).

4.2. Требования к откликам транспорта

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

TCP

SCTP

RTP по протоколу UDP

QUIC

DCCP

4.3. Требования к откликам на перегрузку

В качестве условия передачи пакетов с идентификатором L4S (ECT(1)) хосту следует реализовать поведение контроля перегрузок, которое в установившемся состоянии гарантирует, что средняя продолжительность между индуцированными метками ECN не будет возрастать с ростом скорости потока при прочих равных условиях. Это называется расширяемым (Scalable) контролем перегрузки. Неизменный интервал маркировки гарантирует, что по мере роста скорости потока средняя продолжительность интервала без откликов о пропускной способности не будут расти при прочих равных условиях, а также гарантирует отсутствие значительных вариаций размера очереди без ущерба для загрузки канала.

При контроле перегрузки с использованием зубьев пилы для проверки пропускной способности этот интервал называется временем восстановления, поскольку он указывает среднее время после спада зуба пилы до восстановления прежней верхней точки. При расширяемом контроле перегрузки пилы не возникает, но её могут создавать другие механизмы. Например, для DCTCP [RFC8257], TCP Prague [PRAGUE-CC] [PragueLinux] и L4S-варианта SCReAM [SCReAM-L4S] [RFC8298] среднее время восстановления составляет половину интервала кругового обхода (или половину эталонного RTT) независимо от скорости потока.

Как и для всех вариантов поведения транспорта, предполагается детальная спецификация (возможно, в Experimental RFC) для каждого метода контроля перегрузок в соответствии с рекомендациями по заданию новых алгоритмов контроля перегрузок [RFC5033]. Кроме того, ожидается, что в относящихся к L4S материалам будут документированы, в частности, временные рамки усреднения пропорциональности и контроля за пиками (всплесками) трафика. Для требований к времени восстановления выше использован уровень следует (SHOULD), а не должен (MUST) для обеспечения разумной гибкости реализаций.

Толкование «при прочих равных условиях» допускает, что время восстановления может различаться для разных RTT при условии, что оно не будет расти с увеличением скорости потока для любого конкретного RTT.

Утверждение о приблизительном постоянстве времени восстановления эквивалентно утверждению о постоянстве числа маркеров ECN CE за интервал кругового обхода, независимо от скорости потока при прочих равных условиях. Например, среднее время восстановления в половину RTT эквивалентно 2 маркерам ECN за время кругового обхода. Применительно к функциям отклика на установившуюся перегрузку можно также говорить, что окно перегрузки сокращается обратно пропорционально числу байтов в пакетах с маркировкой кодом CE (см. раздел 2 в [PI2]).

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

1. Расширяемый контроль перегрузки должен обеспечивать возможность замены классическим контролем перегрузки (приложением и/или средствами администрирования). При активации классического контроля перегрузок он не будет помечать свои пакеты кодом ECT(1) (см. ).

2. Помимо отклика на маркеры ECN, расширяемый контроль перегрузки должен реагировать на потери пакетов так, чтобы безопасно сосуществовать с классическим контролем перегрузки, таким как Reno [RFC5681], в соответствии с [RFC5033] (см. обоснование в ).

3. В неконтролируемых средах должен быть реализован мониторинг для поддержки обнаружения проблем в AQM с поддержкой ECN на узких местах пути, которые представляются не поддерживающими L4S и могут находиться в общей очереди. Такой мониторинг следует применять к текущему (live), применяющему расширяемый контроль перегрузки. Мониторинг не требуется для текущего трафика при наличии мониторинга тестового трафика, охватывающего соответствующий путь через неконтролируемые среды.

   Должна использоваться функция обнаружения отмеченных выше проблем в AQM с поддержкой ECN. Функции обнаружения следует обеспечивать способность заставить средства контроля перегрузки адаптировать свою реакцию на маркеры ECN в реальном масштабе времени для безопасного сосуществования с классическим контролем перегрузки, таким как Reno [RFC5681], в соответствии с [RFC5033]. Это может дополняться более детальным обнаружением потенциальных проблем автономно (offline). Если при использовании лишь автономного обнаружения на некоторых путях видны проблемы с таким AQM, расширяемый механизм контроля перегрузок должен заменяться классическим по меньшей мере на проблемных путях.

   Обоснование и разъяснения приведены в , и рекомендациях по работе с L4S [L4SOPS].

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

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

5. Расширяемому контролю перегрузок следует сохранять ответственность за перегрузку, когда типичные значения RTT при работе через общедоступную сеть Internet становятся значительно меньше, поскольку в ниже больше не вносятся задержки в очередях. Было бы предпочтительно сделать минимальное окно перегрузки при расширяемом контроле перегрузок размером меньше 1 сегмента вместо использования основанного на тайм-ауте подхода, описанного для TCP в параграфе 6.1.2 спецификации ECN [RFC3168] (или эквивалента для иного транспорта). Однако более низкий минимум не задан в качестве формального требования для экспериментов (см. обоснование в Приложении A.1.7).

6. Обнаружению потерь в расширяемом контроле перегрузки следует быть устойчивым к изменению порядка в адаптивном интервале времени, который изменяется в зависимости от пропускной способности, и приспосабливается к нарушению порядка (как в Recent ACK (RACK) [RFC8985]), в отличие от учёта лишь числа пакетов (как в правиле 3 Duplicate ACK (DupACK) NewReno [RFC5681] [RFC6675] без поддержки масштабирования). По мере роста скорости передачи данных (например, в результате внедрения новой или улучшенной технологии) контроль перегрузок, обнаруживающий потери путём подсчёта пакетов, с большей вероятностью будет некорректно трактовать события нарушения порядка как потери (см. обоснование в Приложении A.1.8). Это требование не относится к элементам контроля перегрузки, применяемым лишь в контролируемых средах, где сеть практически не меняет порядок пакетов.

7. Предполагается, что расширяемый контроль перегрузки ограничит очереди, вызываемые всплесками (burst) пакетов. Не представляется нужным устанавливать ограничение ниже 10% от минимального RTT, ожидаемого в типовом развёртывании (например, дополнительная очередь примерно на 250 мксек для общедоступной сети Internet). Это будет преобразовываться в число пакетов путём умножения на текущую среднюю скорость пакетов. Тогда очередь, вызываемая каждым всплеском в узком месте, не задержит более чем на 250 мксек (в худшем случая использования потоком всей пропускной способности). Здесь не задано нормативного требования по ограничению всплесков и до обретения достаточного опыта из экспериментов L4S даже непонятно, нужно ли такое требование, хотя представляется, что отправитель L4S заинтересован в этом.

Каждый отправитель в сессии может применять расширяемый контроль перегрузки независимо от используемого получателем контроля перегрузки при передаче им данных. Поэтому могут передаваться пакеты ECT(1) в одном направлении и ECT(0) или Not-ECT — в другом.

Ниже в этом документе (параграф 5.4.1.1) рассматриваются условия для смешивания другого «безопасно неотзывчивого трафика» (например, DNS, LDAP⁷, NTP, голос, синхронизация игр) с трафиком L4S. Хотя такой трафик может помещаться в одну очередь с трафиком L4S, отравителям не следует помечать его кодом ECT(1), за исключением (маловероятного) случая, когда он удовлетворяет указанным выше требованиям.

4.3.1. Рекомендации по реагированию на перегрузки в документах RFC

[RFC3168] требует одинаковой реакции на пакет с маркером CE и отбрасывание пакета. [RFC8311] (Standards Track) обновляет [RFC3168] разрешая эксперименты с ECN, включая L4S. [RFC8311] разрешает экспериментальные отклики на маркеры CE, отличающиеся от реакции на отбрасывание пакетов, при условии, что отличия указаны в Experimental RFC, таком как данный документ.

В BCP 124 [RFC4774] представлены рекомендации для разработчиков протоколов при использовании альтернативной семантики поля IP-ECN. В [RFC8311] разъяснено, что описанный в BCP 124 опыт применения не требуется обновлять для смягчения требований к эквивалентности реакции. Хотя в BCP 124 включено требование из [RFC3168], BCP документ не задаёт своих требований на его основе. BCP 124 [RFC4774] описывает три варианта поэтапного внедрения Option 3 (параграф 4.3 в BCP 124 [RFC4774]), наиболее соответствующих L4S. Требования Option 3 к конечным узлам заключаются в реакции на маркер CE «дружественным к потоку способом, соответствующим контролю перегрузок, заданному IETF». Это перекликается с другими базовыми требованиями к контролю перегрузок в RFC Series. Например, в [RFC5033] сказано: «контроллеры перегрузок, оказывающие существенное негативное влияние на трафик, используя стандартный контроль перегрузок, могут быть подозрительными», а в [RFC8085] при рассмотрении контроля перегрузок в UDP сказано: «Приложениям с большим объёмом данных, отказавшимся от реализации TFRC или использования окна в стиле TCP, следует реализовать схему контроля перегрузок, обеспечивающую использование пропускной способности (ёмкости), беспристрастно разделяемой с TCP (по порядку значений).»

Нормативный п. 3 в параграфе 4.3 выше (отклик L4S на перегрузку от Classic ECN AQM) нацелен на выполнение требований сосуществования, но при этом нужно идти на некоторые компромиссы. В этом параграфе рассмотрены и обоснованы некоторые компромиссы, а Приложение A.1.5 и эксплуатационное руководство L4S [L4SOPS] содержат подробный анализ, примеры и ссылки (приведённый здесь нормативный текст имеет приоритет, если возникают противоречия). Подход основан на оценке риска причинения ущерба, сочетающей учёт вероятности условий нанесения ущерба и важность возможных последствий.

Учёт вероятности (распространённости) рассматривает три случая.

Отбрасывание хвоста (Drop Tail)

L4S

Classic ECN

Общая очередь с Classic ECN

Очереди по потокам с Classic ECN

• При очередях по потокам сосуществование классических потоков и L4S обычно не вызывает проблем, поскольку разные потоки не будут попадать в одну очередь (BCP 124 [RFC4774] не предусматривает введение очередей по потокам, которые появились как возможный метод изоляции примерно через 8 лет после публикации BCP).
• Изоляция между классическими потоками и L4S не идеальна в случаях совпадения хэш-значений идентификаторов потоков или при инкапсуляции нескольких потоков внутри Layer 3 VPN с одним идентификатором потока.

Подводя итог, отметим, что проблема сосуществования ограничивается случаями несовершенной изоляции потоков в FQ или развёртыванием классического ECN AQM в общей очереди (см. эксплуатационные рекомендации для L4S [L4SOPS], где вопрос рассмотрен подробно включая недавние исследования с попыткой оценить распространённость). Если один из этих случаев имеет место, проблемы сосуществования не возникает, пока источники классического и L4S трафика (например, разные приложения в одном доме) не используют одновременно общую очередь в узком месте и потоки каждого типа достаточно продолжительны для возникновения дисбаланса. Вопрос частоты возникновения проблемы сосуществования отмечен в разделе 7 как нерешенный, ответ на который должны дать эксперименты с L4S.

Для случая, когда долгосрочные потоки классического трафика и L4S попадают в общую очередь, тестирование одного механизма контроля перегрузок L4S (TCP Prague) показало, что дисбаланс средней пропускной способности может достигать отношения 25:1 в пользу L4S для худшего случая [ecn-fallback]. Однако при более скудной пропускной способности классический поток получает большую долю канала, например для канала 4 Мбит/с отношение будет ниже ~10:1 для путей с базовым RTT менее 100 мсек и падает ниже ~5:1 для базового RTT менее 20 мсек.

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

• Рекомендуемым подходом остаётся обнаружение и адаптация к Classic ECN AQM в реальном масштабе времени, что соответствует всем RFC по сосуществованию. Иными словами, следует в п. 3 параграфа 4.3 выше предполагает, что отправитель реализует что-то похожее на код проверки концепции (proof-of-concept), который обнаруживает наличие Classic ECN AQM и откатывается к классическим откликам на перегрузку в течение нескольких интервалов кругового обхода [ecn-fallback]. Хотя этот код надёжно обнаруживает Classic ECN AQM, текущий код может ошибочно счесть L4S AQM классическим, чаще всего при малой скорости канала или большом RTT. Хотя это безопасный путь обхода и ожидается, что разработчики смогут улучшить доказательство концепции, высказывались опасения в потере разработчиками веры в такое обнаружение и отказе от него.

• П. 3 параграфа 4.3 выше допускает компромисс, когда сосуществование на короткое время может отходить от требований RFC, но требуется обязательный мониторинг для обнаружения таких случаев и принятия мер. Этот подход допускает кратковременное отклонение от RFC с учётом малой распространённости, а ущерб будет заключаться в замедлении продвижения потока. Эксплуатационные рекомендации L4S [L4SOPS] включают ряд примеров корректировочных действий, включая изменения у отправителя или в сети. Однако финальное нормативное требование п. 3 параграфа 4.3 возлагает окончательную ответственность за принятие мер на отправителя. При обнаружении проблемы сосуществования с Classic ECN AQM (не решённой сетью) отправитель, в соответствии с требованием, должен вернуться к классическому контролю перегрузки.

В [L4SOPS] также приведены примеры путей внедрения контроля перегрузок L4S в сценариях с малым риском.

4.4. Фильтрация или сглаживание обратной связи ECN

В параграфе 5.2 ниже указано, что от L4S AQM ожидается незамедлительная сигнализация L4S ECN, чтобы избежать задержки из-за фильтрации или сглаживания. Это отличается от Classic AQM, где изменения в очереди фильтруются перед сигналом с помощью маркера ECN или отбрасывания. В архитектуре L4S [RFC9330] ответственность за сглаживание вариаций очереди перенесена в контроль перегрузок у отправителя. Этот перенос ответственности за сглаживание позволяет каждому отправителю сглаживать вариации в масштабе времени, пропорционального его RTT. В классическом подходе сеть не знает значений RTT для потоков, поэтому для обеспечения стабильности при сглаживании применяется значение RTT для худшего случая. Для потоков с RTT меньше такого худшего значения контроль перегрузок становится неоправданно медленным.

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

5. Поведение узла сети

5.1. Классификация и перемаркировка

Узел сети, реализующий услуги L4S:

• должен классифицировать приходящие пакеты ECT(1) для обработки L4S, если они не будут переопределены другим классификатором (см., например, );

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

  Пакеты CE могут быть созданы как ECT(1) или ECT(0), но приведённое выше правило классификации, как будто они созданы как ECT(1), является безопасным выбором (см. обоснование в Приложении B). Исключением является случай наличия в сети знающего о потоках механизма, отличающего пакеты CE, созданные как ECT(0) (см. параграф 5.3), но обязательность такого механизма не предполагается.

Обработка L4S AQM следует тем же правилам смены кодов, что и [RFC3168]. В частности, код ECT(1) недопустимо менять на какой-либо код, кроме CE, а CE недопустимо заменять любым другим кодом. Пакеты ECT(1) классифицируются как поддерживающие ECN (ECN-capable) и при возникновении перегрузки алгоритм L4S AQM будет все чаще помещать в поле IP-ECN код CE, в остальных случаях просто пересылая пакеты без изменений как ECT(1). Условия для маркировки пакетов в L4S заданы в параграфе 5.2.

При сохраняющейся перегрузке обработка маркировки L4S должна начинать отбрасывание трафика L4S, пока перегрузка не спадёт, как рекомендовано для всех методов AQM в параграфе 4.2.1 [RFC7567], который следует похожим рекомендациям раздела 7 в [RFC3168]. Во время перегрузки для трафика L4S должна применяться такая же вероятность отбрасывания, как для классического трафика.

Если L4S AQM знает о применяемом транспорте, это требование можно выполнить путём отбрасывания лишь в наиболее перегруженных AQM по потокам. В DualQ с защитой очередей по потокам (например, [DOCSIS-QPROT]) этого можно добиться путём перенаправления пакетов в потоках, вносящих наибольший вклад в перегрузку, из очереди L4S, чтобы они отбрасывались по правилам классических очередей.

Для совместимости с прежними решениями в неконтролируемых средах сетевой узел с поддержкой обработки L4S должен реализовать также обработку AQM для классического трафика в соответствии с параграфом 1.2. От этой обработки Classic AQM не требуется маркировать пакеты ECT(0), но если это делается, нужно следовать параграфу 5.2 в части соотношения маркировки и отбрасывания. Прибывающие пакеты ECT(0) и Not-ECT должны классифицироваться для обработки этим механизмом Classic AQM (для DualQ Coupled AQM классификация подробно рассмотрена в параграфах 2.3 и 2.5.1.1 [RFC9332]).

При возникновении непредвиденных проблем в экспериментах с L4S должна быть возможность отключить в реализации L4S обработку L4S. После отключения пакеты ECT(1) должны рассматриваться как Not-ECT.

5.2. Соотношение маркировки L4S CE и отбрасывания

Соотношение в маркировки CE и отбрасывания в L4S не имеет значения, когда применяются механизмы AQM в очередях по потокам приложений, которые затем явно планируются (например, планировщиком FQ в FQ-CoDel [RFC8290]). Тем не менее, это соотношение нужно определять для связывания классических сигналов перегрузки с сигналами L4S в DualQ Coupled AQM [RFC9332], как показано ниже.

Пока узел AQM не планирует потоки приложений явно, вероятность отбрасывания механизмом AQM классического пакета Not-ECT (p_C) должна быть примерно пропорциональна квадратному корню вероятности маркировки, если бы это был пакет L4S (p_L). Т. е.

      p_C ~= (p_L / k)^2

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

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

В архитектуре L4S [RFC9330] отправитель, а не сеть, отвечает за сглаживание вариаций очереди. Поэтому механизм L4S AQM должен сообщать о перегрузке как можно скорее. Отправитель L4S обычно интерпретирует маркировку CE как несглаженный сигнал.

Это требование не мешает L4S AQM смешивать дополнительные сглаженные сигналы перегрузки, такие как сигналы от сглаженные сигналы классического AQM, с несглаженными сигналами L4S в связанном DualQ [RFC9332], но лишь до тех пор, пока о перегрузке можно сигнализировать незамедлительно и сразу же интерпретировать сигналы у отправителя, что важно для функциональной совместимости.

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

Для классификации пакетов L4S узлу сети не требуется идентифицировать потоки транспортного уровня. Тем не менее, если узел L4S классифицирует пакеты по идентификаторам потоков на транспортном уровне и их полям ECN, а все пакеты ECT в потоке имеют код ECT(0), узел может классифицировать пакеты CE в том же потоке, как будто пакеты Classic ECT(0). В остальных случаях узел сети должен классифицировать пакеты CE, как будто ECT(1). Такие случаи возникают когда: i) в потоке ещё не идентифицированы пакеты ECT, ii) для узла нежелательно идентифицировать потоки транспортного уровня, iii) некоторые пакеты ECT в потоке были ECT(1) (это нужно проверить в экспериментах L4S).

5.4. Взаимодействие идентификаторов L4S с другими идентификаторами

Примеры в этом параграфе посвящены использованию идентификаторов, дополняющих идентификатор L4S, для классификации пакетов по очередям на основе классов. В параграфе 5.4.1 рассмотрены 2 очереди (L4S и Classic) как в DualQ Coupled AQM [RFC9332] автономно (параграф 5.4.1.1) или в иерархии очередей (параграф 5.4.1.2). В параграфе 5.4.2 рассматриваются схему, которые могут комбинировать идентификаторы потоков 5-tuple с другими идентификаторами.

5.4.1. Примеры DualQ с идентификаторами, дополняющими идентификатор L4S

5.4.1.1. Включение дополнительного трафика в очередь с L4S

В типичном для общедоступной сети Internet случае элемент сети, реализующий L4S в общей очереди, может захотеть классифицировать некий низкоскоростной, но неотзывчивый (unresponsive) трафик (например, DNS, LDAP, NTP, голос, синхронизация игр) в очередь с малой задержкой, смешивая его с трафиком L4S. В этом случае очередь неуместно называть очередью L4S, поскольку она используется и для другого (не L4S) трафика. Будем называть её очередью с малой задержкой или L-очередью. Для L-очереди возможны 2 варианта работы:

• обработка L4S, сочетающая L4S AQM и планирование с приоритетом;

• обработка с малой задержкой только за счёт планирования с приоритетом без ECN-маркировки в AQM.

Чтобы отобрать пакеты для обработки лишь планировщиком, неуместно применять идентификатор L4S ECT(1), поскольку такой трафик не реагирует на маркировку ECN. Примерами подходящих идентификаторов являются:

• диапазоны адресов конкретных приложений или хостов, настроенных или известных как безопасные, например, жёстко заданные устройства IoT⁸, передающих небольшой трафик;

• некоторые приложения или протоколы с небольшим объёмом данных (например, ARP и DNS);

• конкретные коды Diffserv, указывающие трафик с ограниченными пиками, такие как классы EF [RFC3246], VOICE-ADMIT [RFC5865], NQB⁹ [NQB-PHB] или эквивалентные локальные кода DSCP (см. [L4S-DIFFSERV]).

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

Таким образом, элемент сети, реализующий L4S в общей очереди, может классифицировать дополнительные пакеты в очередь L на основе идентификаторов, не связанных с полем IP-ECN, но этому трафику следует быть «безопасным» для смешивания с трафиком L4S (см. ).

Пакет с одним из таких идентификаторов (не ECN) для включения в очередь L не будет получать маркировку L4S ECN, если он явно не содержит код ECT(1) или CE. Спецификация L4S AQM должна задавать поведение для пакетов с неожиданными комбинациями кодов, например, классификатор, не связанный с ECN для очереди L и ECT(0) в поле IP-ECN (примеры подходящих комбинаций приведены в параграфе 2.5.1.1 спецификации DualQ [RFC9332]).

Отметим для понимания, что некоторые операторы могут применят не связанные с ECN идентификаторы (такие как указаны выше), которые они считают подходящими для идентификации не относящегося к L4S трафика с целью безопасного смешивания с трафиком L4S. Это не является для хостов альтернативой индикации передачи им пакетов L4S. Лишь код ECT(1) ECN указывает элементам сети, что хост передаёт пакеты L4S (а CE указывает, что они могли быть переданы с кодом ECT(1)). В частности, ECT(1) указывает, что хост заявляет о своём соответствии транспортным требованиям, указанным в разделе 4.

Узлу сети недопустимо менять код Not-ECT или ECT(0) в поле IP-ECN на идентификатор L4S для включения не относящихся к L4S пакетов в очередь L. Это гарантирует, что коды сохранятся для возможного последующего использования на пути через сеть. Если несоответствующий или враждебный узел сети заменить ECT(0) на ECT(1), пакет впоследствии может получить маркер ECN от нисходящего L4S AQM, но отправитель отреагирует на индикацию насыщения, считая, что он передал классический пакет. Это может приводить к чрезмерным уступкам в пользу других потоков L4S в том же узком месте нисходящего направления.

5.4.1.1.1. «Безопасный» неотзывчивый трафик

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

Это туманное, но полезное определение, поскольку ему соответствуют многие приложения, заинтересованные в малой задержке, такие как DNS, голос, синхронизация игр, RPC, ACK, keep-alive.

Низкоскоростные потоки, такие как голос и синхронизация игр, могут не применять постоянно адаптирующийся контроль перегрузок на основе ECN, но они должны, по меньшей мере, использовать «автоматический выключатель» (circuit-breaker) в качестве отклика на перегрузку [RFC8083]. Если объем трафика от неотзывчивых приложений достаточно велик для перегрузки канала, это хотя бы защитит пропускную способность, доступную реагирующим на перегрузку приложениям. Однако задержка в очереди L в результате вероятно возрастёт до типичного для Classic AQM (на основе отбрасывания) уровня. Если оператор сочтёт, что такого самоограничения недостаточно, он может захотеть управлять очередью L (см. параграф 8.2 описания архитектуры L4S [RFC9330]).

5.4.1.2. Исключение трафика из обработки L4S

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

Узлу сети недопустимо менять сквозной идентификатор L4S ECN с L4S на Classic, когда решение оператора исключает локально обработку L4S для части трафика. Сквозной идентификатор L4S сохраняется для использования другими операторами или может применяться в политике оператора независимо от заданных локально идентификаторов. Такой подход позволяет любому оператору удалить заданные локально исключения в будущем, например, при распространении преимуществ L4S на всех клиентов. Если несоответствующий или вредоносный сетевой узел меняет код ECT(1) на ECT(0), пакет может быть промаркирован с использованием ECN нисходящим Classic ECN AQM. Отправителям L4S нужно обнаруживать и обрабатывать такую маркировку (п. 3 в параграфе 4.3), но это не делает упомянутую замену кода приемлемой, поскольку обнаружение не будет немедленным и совершенным.

Сетевой узел, поддерживающий L4S, но исключающий некоторые пакеты с идентификатором L4S из обработки L4S, должен все равно применять маркировку или отбрасывание, совместимые с откликами L4S на перегрузку. Например, он может отбрасывать такие пакеты с той же вероятностью, что и классические пакеты, или использовать для них маркировку ECN с вероятностью, соответствующей трафику L4S (например, связанной вероятностью DualQ Coupled AQM), но ориентируясь на классическую целевую задержку. Недопустимо применять для таких пакетов маркировку ECN с классической вероятностью, поскольку это может запутать отправителя.

5.4.1.3. Обобщённая комбинация L4S и других идентификаторов

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

Приведённые выше примеры DualQ были сформулированы в контексте принятого по умолчанию Best Effort PHB¹⁰ с использованием 2 очередей — очереди с малой задержкой (L) и классической (C) очереди. Предполагается, что наиболее распространённой и полезной будет одна структура DualQ. Но в более общем плане оператор может выбрать управление пропускной способностью через иерархию Diffserv PHB на узле и предлагать один (или несколько) вариантов PHB с использованием пары очередей для очереди с малой задержкой и классическим вариантом PHB.

В первом случае, если предположить, что элемент сети не предлагает PHB, кроме DualQ, для пакетов с кодом ECT(1) или CE, элемент сети будет классифицировать их для обработки L4S независимо от кода DSCP. Если пакет имел, например код EF в поле DSCP, элемент сети может классифицировать его в очередь L независимо от кода ECN. Однако при включении DualQ в иерархию других PHB классификатор будет относить часть трафика к другим PHB на основе поля DSCP до распределения между очередью с малой задержкой и классической очередью (на основе ECT(1), CE и, возможно, EF DSCP или иных идентификаторов, как в примере выше). В [L4S-DIFFSERV] дано много примеров для исполнения различных требований.

В [L4S-DIFFSERV] описано, как оператор может использовать L4S для обеспечения малой задержки вместе с Diffserv для распределения пропускной способности. Выделены два основных подхода. Оператор может разделить тот или иной вариант Diffserv PHB между услугами L4S и Classic или распределить услуги L4S и/или Classic между разными Diffserv PHB. В любом случае пакет будет классифицироваться по его кодам Diffserv и ECN.

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

1. Идентификаторы, дополняющие идентификатор L4S.

   1. Включение дополнительного трафика в очередь L (рекомендовано для стандартного и локального применения)

   2. Исключение части трафика из очереди L (для локального применения)

2. Идентификаторы для включения классификации L4S в иерархию PHB (рекомендовано для стандартного и локального применения)

   1. PHB до классификации L4S ECN.

   2. PHB после классификации L4S ECN.

5.4.2. Очереди по потокам с добавлением других идентификаторов к L4S

На узле с очередями по потокам (например, FQ-CoDel [RFC8290]) идентификатор L4S может дополняться идентификатором потока на транспортном уровне в качестве дополнительной детализации (т. е. очереди Not-ECT и ECT(0) отделены от ECT(1) и CE). В Приложении B (Риск нарушения порядка классических пакетов CE внутри потока) рассматривается возникающая неоднозначность, когда пакеты, изначально помеченные кодом ECT(0), маркируются кодом CE восходящим AQM до их прибытия на узел, который классифицирует CE как L4S. Указано, что риск нарушения порядка пренебрежимо мал, а последствия возможного нарушения порядка минимальны.

В качестве альтернативы можно предположить, что смешивание идентификаторов Classic и L4S не соответствует интересам самого потока. Тогда механизм AQM может использовать поле IP-ECN для переключения между классическим поведением и L4S AQM внутри очереди для одного потока. Например, для пакетов с поддержкой ECN механизм AQM может состоять из простого порога маркировки, а идентификатор L4S ECN может просто выбрать более низкий порог, чем это сделал бы идентификатор Classic ECN.

5.5. Ограничение всплесков пакетов из каналов

Так же как отправителям нужно ограничивать всплески (burst) пакетов (параграф 4.3), каналы должны ограничивать вносимые ими всплески (burstiness). В обоих случаях (отправители и каналы) это является компромиссом, поскольку групповая (batch) обработка пакетов выполняется осмысленно, например, для повышения эффективности обработки или более эффективного использования задержки получения доступа к среде. Некоторые придерживаются мнения, что не нужно сокращать всплески у отправителя ниже величины всплесков, возникающих в каналах (и обратно). Однако сокращение наибольшей задержки переносит внимание на следующую по величине и т. д.

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

5.5.1. Ограничение всплесков пакетов из каналов с L4S AQM

Было бы бессмысленно внедрять L4S AQM для конкретной технологии канального уровня, не рассмотрев возможностей сокращения задержки всплесков, вносимой этой технологией. Это по меньшей мере ограничило бы всплески, которые иначе внёс бы канал в проходящий трафик, что вызывало бы «скачки» обратной связи у отправителя, а также возможную дополнительную задержку в очереди нисходящего направления. Этот документ не предполагает даже рекомендаций в части целевого значения задержки всплесков, пока в отрасли не будет набрано достаточного опыта применения L4S. Однако, как предложено в параграфе 4.3, не представляется необходимым ограничивать всплески ниже примерно 10% от минимального базового значения RTT в типовом варианте внедрения (например, длительность всплеска 250 мксек в общедоступной сети Internet).

5.5.2. Ограничение всплесков пакетов из восходящих каналов с L4S AQM

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

Детали таких изменений для каналов выходят за рамки этого документа. Тем не менее, при внедрении технологии L4S на выходном интерфейсе устройства имеет смысл рассмотреть возможности сокращения всплесков, приходящих из других входных интерфейсов. Например, при реализации L4S AQM на соединении с восходящим интерфейсом WAN в домашнем шлюзе можно рассмотреть варианты изменения профилей Wi-Fi для интерфейсов того же шлюза, чтобы смягчить входные пики агрегированных кадров Wi-Fi от других станций Wi-Fi.

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

6.1. Неизменность в туннелях и при инкапсуляции

Предполагается, что идентификаторы L4S будут работать через туннели и внутри их без изменений, пока туннель переносит поля ECN любым из способов, определённых с первого варианта 2001 г. [RFC3168]. L4S будет работать (но не полагаться на них) и последующими обновлениями передачи ECN [RFC4301], [RFC6040], [ECN-SHIM]. Однако имеется вероятность, что до сих пор некоторые туннели совсем не передают ECN. В таких случаях L4S будет работать через туннель, но внутри него внешний заголовок L4S будет выглядеть как Classic.

Механизмы AQM обычно реализуются там, где буфер уровня «питает» нижележащий уровень, поэтому они не зависят от инкапсуляции канального уровня. Если узкое место канала не знает об IP, ожидается, что идентификаторы L4S всё равно будут работать без изменений с любой инкапсуляцией канального уровня, пока они распространяются в поле IP-ECN, как задано для этой канальной технологии (например, MPLS [RFC5129] или TRILL¹¹ [TRILL-ECN-SUPPORT]). В некоторых из таких случаев (например, в коммутаторах L3 Ethernet) AQM обращается к заголовку уровня IP внутри инкапсуляции, поэтому снова ожидается, что идентификатор L4S будет работать без изменений. Тем не менее, программа по определению ECN для других нижележащих уровней продолжается [ECN-ENCAP].

6.2. Поведение VPN для снижения ограничений Anti-Replay

Если смесь пакетов L4S и Classic передаётся в одну защищённую связь (security association или SA) VPN и на выходе VPN реализована необязательная функция предотвращения повторного использования (anti-replay), она может необоснованно отбрасывать классические пакеты (или отвергать записи из них), ошибочно воспринимая их большую задержку в очереди как replay-атаку (см. Dropped Packets for Tunnels with Replay Protection Enabled в [Heist21], где рассматривается возможное влияние на производительность). Эта проблема известна для IPsec [RFC4301] и DTLS [RFC9147] VPN, поскольку в них применяются аналогичные механизмы окна anti-replay, которые способны проверять наличие повтора лишь в рамках окна, поэтому при окне меньше степени нарушения порядка возможны ложные обнаружения атак с отбрасыванием заднего края окна. Спецификации IPsec AH¹² [RFC4302] и ESP¹³ [RFC4303] предлагают разработчикам изменять размер окна anti-replay в зависимости от скорости, а в DTLS v1.3 [RFC9147] сказано: «Получателю следует выбирать достаточно большое окно, чтобы можно было обработать правдоподобное нарушение порядка, которое зависит от скорости передачи данных.» Однако на практике размер окна предотвращения повторов в VPN не всегда масштабируется должным образом.

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

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

• Если VPN можно настроить для классификации в разные SA, индексируемые DSCP, с использованием локально выбранных подходящих DSCP для классических пакетов и L4S. Коды DSCP могут устанавливаться сетью (на основе младшего бита в поле IP-ECN) или передающим хостом и нужны лишь до входа в VPN.

• Если приведённый выше вариант невозможен, а применять L4S нужно, подойдёт любой из 2 вариантов:

  • отключение защиты от повторов на выходе VPN после рассмотрения влияния этого на безопасность (поддержка отключения anti-replay обязательна в IPsec и DTLS);

  • отключение распространения ECN во внешний заголовок на входе туннеля, что приведёт к потере преимуществ L4S и Classic ECN при передаче через VPN.

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

7. Эксперименты с L4S

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

В дополнение к этому разделу i) спецификация DualQ [RFC9332] задаёт требования к эксплуатации и управлению для DualQ Coupled AQM, а ii) общие требования в части эксплуатации и управления для экспериментов с контролем перегрузок L4S приведены выше в разделах 4 и 5 (например, требования к сосуществованию и масштабированию, а также варианты поэтапного развёртывания.

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

7.1. Нерешённые вопросы

Предполагается, что эксперименты с L4S дадут ответы на приведённые ниже вопросы:

• Были ли внедрены все части L4S и, если да, какая часть путей поддерживает их?

  • Какие типы L4S AQM внедрены (например, FQ, связанные и несвязанные DualQ и т. п.)? Насколько превалировал каждый из внедрённых вариантов?

  • Отличаются ли схемы сигнализации развёрнутых AQM от ожидаемых при задании требований Prague для конечных точек?

• Ведёт ли использование L4S через Internet к большей удовлетворённости пользователей?

• Позволяет ли L4S внедрять новые интерактивные приложения?

• Обеспечивает ли внедрение L4S через Internet к улучшению показателей:

  • задержки в очередях (средней и при 99-м процентиле) при разной нагрузке;

  • загрузки каналов;

  • истощения и беспристрастности;

  • диапазон масштабирования скоростей потоков и RTT?

• Насколько зависит производительность услуг L4S от пропускной способности в узком месте и RTT для пути?

• Насколько каналы со всплесками трафика в Internet влияют на производительность L4S (см. Underutilization with Bursty Links в [Heist21]) и сколь часто такие каналы встречаются? Насколько было необходимо и было реализовано ограничение всплесков у отправителей и на каналах (особенно радио) или насколько потребовалось увеличить целевую задержку L4S, чтобы работать с такими всплесками (см. п. 7 в параграфе 4.3 и параграф 5.5.2)?

• Указывает ли начальный эксперимент с ошибочно идентифицированным скачкообразным (bursty) трафиком при большом значении RTT (см. Underutilization with Bursty Traffic в [Heist21]) похожие проблемы при малых RTT и, если да, насколько эффективно решение из Приложения A.1 к спецификации DualQ [RFC9332] (или иное решение)?

• Требовалась ли обычно защита очередей по потокам?

  • Насколько хорошо работала защита от перегрузок или защита очереди?

• Как потоки L4S сосуществовали с классическими потоками в узком месте?

  • Как часто возникали проблемы?

  • Что вызывало проблемы сосуществования и были ли проблемы связаны с механизмами Classic ECN AQM с одной очередью (в предположении возможности отличить очередь Classic ECN AQM от FQ)?

• Насколько распространены проблемы сервиса L4S, связанные с туннелями или инкапсуляцией при отсутствии поддержки декапсуляции ECN?

• Насколько легко было внедрение полностью совместимого с L4S контроля перегрузки для различных транспортных протоколов (TCP, QUIC, RMCAT и т. п.)?

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

7.2. Нерешённые проблемы

• Какой наилучший способ решения задачи для L4S в узких местах с Classic ECN AQM в одной очереди с учётом ошибочного восприятия L4S AQM как ECN AQM? См. эксплуатационные рекомендации для L4S [L4SOPS].

• Решение проблемы недостаточно взаимодействия между текущим контролем перегрузок L4S и CoDel с поддержкой лишь Classic ECN при запуске потока. Исходно это было связано с ошибкой при инициализации среднего уровня перегрузки в Linux-реализации TCP Prague. Ошибка была быстро устранена и исключено соответствующее влияние на производительность, но дальнейшее улучшение будет полезным (например, путём изменение CoDel, расширяемых элементов контроля перегрузки или того и другого сразу).

7.3. Будущий потенциал

Исследователи могут увидеть, что L4S открывает ряд интересных направлений для изучения:

• возможность ускоренного схождения и отслеживает доступной пропускной способности;

• возможность улучшения определённых канальных технологий и межуровневых взаимодействий с ними;

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

• разработка и спецификация контроля перегрузок на пути возврата с использованием элементов L4S (например, AccECN или QUIC);

• определение следующего шага после сокращения задержек (кроме скорости света);

• расширение набора имеющихся L4S AQM;

• новые приложения с поддержкой L4S.

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

Этот экспериментальный документ задаёт семантику кода 01 в поле ECN заголовка IP. Для Experimental RFC процесс выделения кода в заголовках IP (v4 и v6) регулируется предложенным стандартом [RFC8311], обновившим [RFC3168].

Агентство IANA обновило запись 01 в реестре ECN Field (Bits 6-7) (https://www.iana.org/assignments/dscp-registry/).

Таблица . Реестр ECN Field (Bits 6-7).

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

Подходы к обеспечению целостности сигналов, использующих новый идентификатор, представлены в Приложении C.1. Соображения безопасности связанные со злоупотреблениями при использовании идентификаторов приведены в описании архитектуры L4S [RFC9330] и так же рассмотрены вопросы управления скоростью и задержки в L4S.

Выбор ECT(1) в качестве идентификатора L4S задаёт разную трактовку кодов ECT(0) и ECT(1), которые в [RFC3168] указаны как различающиеся, но эквивалентные. В L4S ECN узлам сети также не разрешается менять один код на другой, даже при выборе оператором сети локальной обработки в соответствии с другим кодом (см. и параграфы 5.4.1.1 и 5.4.1.2). В указанных параграфах также рассмотрено возможное влияние замены кода несовместимым или вредоносным узлом сети. Эта спецификация не меняет эффекты других неожиданных изменений поля IP-ECN, описанных в разделе 18 [RFC3168].

Если окно anti-replay на выходе VPN слишком мало, различия в задержке будут ошибочно восприниматься как replay-атака с отбрасыванием задержанных пакетов (например, классических) из одной защищённой связи (SA) с менее задержанными пакетами (например, L4S). В параграфе 6.2 рекомендуется настраивать VPN, применяемые в экспериментах L4S, с достаточно большим окном anti-replay, как того требуют соответствующие спецификации, а также рассматриваются иные варианты.

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

Рекомендации по обнаружению потерь на основе времени предотвращают атаки ACK-splitting, описанные в [Savage-TCP].

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

10.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>.

[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>.

[RFC4774] Floyd, S., «Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field», BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O’Hanlon, P., and K. Carlberg, «Explicit Congestion Notification (ECN) for RTP over UDP», RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.

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

[A2DTCP] Zhang, T., Wang, J., Huang, J., Huang, Y., Chen, J., and Y. Pan, «Adaptive-Acceleration Data Center TCP», IEEE Transactions on Computers, Volume 64, Issue 6, pp. 1522-1533, DOI 10.1109/TC.2014.2345393, June 2015, <https://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6871352>.

[ACCECN] Briscoe, B., Kühlewind, M., and R. Scheffenegger, «More Accurate ECN Feedback in TCP», Work in Progress, Internet-Draft, draft-ietf-tcpm-accurate-ecn-22, 9 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-22>.

[Ahmed19] Ahmed, A.S., «Extending TCP for Low Round Trip Delay», Master’s Thesis, University of Oslo, August 2019, <https://www.duo.uio.no/handle/10852/70966>.

[Alizadeh-stability] Alizadeh, M., Javanmard, A., and B. Prabhakar, «Analysis of DCTCP: Stability, Convergence, and Fairness», SIGMETRICS ’11: Proceedings of the ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer Systems, pp. 73-84, DOI 10.1145/1993744.1993753, June 2011, <https://dl.acm.org/doi/10.1145/1993744.1993753>.

[ARED01] Floyd, S., Gummadi, R., and S. Shenker, «Adaptive RED: An Algorithm for Increasing the Robustness of RED’s Active Queue Management», ACIRI Technical Report 301, August 2001, <https://www.icsi.berkeley.edu/icsi/node/2032>.

[BBR-CC] Cardwell, N., Cheng, Y., Hassas Yeganeh, S., Swett, I., and V. Jacobson, «BBR Congestion Control», Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.

[BBRv2] «TCP BBR v2 Alpha/Preview Release», commit 17700ca, June 2022, <https://github.com/google/bbr>.

[Bufferbloat] The Bufferbloat community, «Bufferbloat», <https://bufferbloat.net/>.

[COBALT] Palmei, J., Gupta, S., Imputato, P., Morton, J., Tahiliani, M. P., Avallone, S., and D. Täht, «Design and Evaluation of COBALT Queue Discipline», IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), DOI 10.1109/LANMAN.2019.8847054, July 2019, <https://ieeexplore.ieee.org/abstract/document/8847054>.

[CTCP] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, «Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks», Work in Progress, Internet-Draft, draft-sridharan-tcpm-ctcp-02, 3 November 2008, <https://datatracker.ietf.org/doc/html/draft-sridharan-tcpm-ctcp-02>.

[DCttH19] De Schepper, K., Bondarenko, O., Tilmans, O., and B. Briscoe, «‘Data Centre to the Home’: Ultra-Low Latency for All», Updated RITE project Technical Report, July 2019, <https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf>.

[DOCSIS-QPROT] Briscoe, B., Ed. and G. White, «The DOCSIS® Queue Protection Algorithm to Preserve Low Latency», Work in Progress, Internet-Draft, draft-briscoe-docsis-q-protection-06, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06>.

[DualPI2Linux] Albisser, O., De Schepper, K., Briscoe, B., Tilmans, O., and H. Steen, «DUALPI2 — Low Latency, Low Loss and Scalable (L4S) AQM», Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-DUALPI2-AQM>.

[Dukkipati06] Dukkipati, N. and N. McKeown, «Why Flow-Completion Time is the Right Metric for Congestion Control», ACM SIGCOMM Computer Communication Review, Volume 36, Issue 1, pp. 59-62, DOI 10.1145/1111322.1111336, January 2006, <https://dl.acm.org/doi/10.1145/1111322.1111336>.

[ECN++] Bagnulo, M. and B. Briscoe, «ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets», Work in Progress, Internet-Draft, draft-ietf-tcpm-generalized-ecn-10, 27 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-10>.

[ECN-ENCAP] Briscoe, B. and J. Kaippallimalil, «Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP», Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-encap-guidelines-17, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>.

[ecn-fallback] Briscoe, B. and A. Ahmed, «TCP Prague Fall-back on Detection of a Classic ECN AQM», Technical Report: TR-BB-2019-002, DOI 10.48550/arXiv.1911.00710, February 2021, <https://arxiv.org/abs/1911.00710>.

[ECN-SHIM] Briscoe, B., «Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim», Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update-shim-15, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-15>.

[Heist21] «L4S Tests», commit e21cd91, August 2021, <https://github.com/heistp/l4s-tests>.

[L4S-DIFFSERV] Briscoe, B., «Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services», Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-diffserv-02, 1 November 2018, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>.

[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, «Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All», Preprint submitted to IEEE/ACM Transactions on Networking, DOI 10.48550/arXiv.2209.01078, September 2022, <https://arxiv.org/abs/2209.01078>.

[L4SOPS] White, G., Ed., «Operational Guidance for Deployment of L4S in the Internet», Work in Progress, Internet-Draft, draft-ietf-tsvwg-l4sops-03, 28 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops-03>.

[LinuxPacedChirping] Misund, J. and B. Briscoe, «Paced Chirping — Rethinking TCP start-up», Proceedings of Linux Netdev 0x13, March 2019, <https://legacy.netdevconf.info/0x13/session.html?talk-chirp>.

[NQB-PHB] White, G. and T. Fossati, «A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services», Work in Progress, Internet-Draft, draft-ietf-tsvwg-nqb-15, 11 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-15>.

[PI2] De Schepper, K., Bondarenko, O., Tsang, I., and B. Briscoe, «PI^2: A Linearized AQM for both Classic and Scalable TCP», Proceedings of ACM CoNEXT 2016, pp. 105-119, DOI 10.1145/2999572.2999578, December 2016, <https://dl.acm.org/citation.cfm?doid=2999572.2999578>.

[PRAGUE-CC] De Schepper, K., Tilmans, O., and B. Briscoe, Ed., «Prague Congestion Control», Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-01, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01>.

[PragueLinux] Briscoe, B., De Schepper, K., Albisser, O., Misund, J., Tilmans, O., Kühlewind, M., and A. Ahmed, «Implementing the ‘TCP Prague’ Requirements for L4S», Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>.

[QV] Briscoe, B. and P. Hurtig, «Report on Prototype Development and Evaluation of Network and Interaction Techniques», RITE Technical Report, Deliverable 2.3, Appendix C.2: «Up to Speed with Queue View», September 2015, <https://riteproject.files.wordpress.com/2015/12/rite-deliverable-2-3.pdf>.

[RELENTLESS] Mathis, M., «Relentless Congestion Control», Work in Progress, Internet-Draft, draft-mathis-iccrg-relentless-tcp-00, 4 March 2009, <https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00>.

[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>.

[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, «An Expedited Forwarding PHB (Per-Hop Behavior)», RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.

[RFC3540] Spring, N., Wetherall, D., and D. Ely, «Robust Explicit Congestion Notification (ECN) Signaling with Nonces», RFC 3540, DOI 10.17487/RFC3540, June 2003, <https://www.rfc-editor.org/info/rfc3540>.

[RFC3649] Floyd, S., «HighSpeed TCP for Large Congestion Windows», RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.

[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>.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.

[RFC4341] Floyd, S. and E. Kohler, «Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control», RFC 4341, DOI 10.17487/RFC4341, March 2006, <https://www.rfc-editor.org/info/rfc4341>.

[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>.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5033] Floyd, S. and M. Allman, «Specifying New Congestion Control Algorithms», BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.

[RFC5129] Davie, B., Briscoe, B., and J. Tay, «Explicit Congestion Marking in MPLS», RFC 5129, DOI 10.17487/RFC5129, January 2008, <https://www.rfc-editor.org/info/rfc5129>.

[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>.

[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. Ramakrishnan, «Adding Explicit Congestion Notification (ECN) Capability to TCP’s SYN/ACK Packets», RFC 5562, DOI 10.17487/RFC5562, June 2009, <https://www.rfc-editor.org/info/rfc5562>.

[RFC5622] Floyd, S. and E. Kohler, «Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)», RFC 5622, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-editor.org/info/rfc5622>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC5706] Harrington, D., «Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions», RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.

[RFC5865] Baker, F., Polk, J., and M. Dolly, «A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic», RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6040] Briscoe, B., «Tunnelling of Explicit Congestion Notification», RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. Briscoe, «Open Research Issues in Internet Congestion Control», RFC 6077, DOI 10.17487/RFC6077, February 2011, <https://www.rfc-editor.org/info/rfc6077>.

[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, «Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)», RFC 6660, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.

[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, «A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP», RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.

[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, «Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback», RFC 7560, DOI 10.17487/RFC7560, August 2015, <https://www.rfc-editor.org/info/rfc7560>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7713] Mathis, M. and B. Briscoe, «Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements», RFC 7713, DOI 10.17487/RFC7713, December 2015, <https://www.rfc-editor.org/info/rfc7713>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, «Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem», RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8083] Perkins, C. and V. Singh, «Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions», RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[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>.

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, «Data Center TCP (DCTCP): TCP Congestion Control for Data Centers», RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, «The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm», RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.

[RFC8298] Johansson, I. and Z. Sarker, «Self-Clocked Rate Adaptation for Multimedia», RFC 8298, DOI 10.17487/RFC8298, December 2017, <https://www.rfc-editor.org/info/rfc8298>.

[RFC8311] Black, D., «Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation», RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, «CUBIC for Fast Long-Distance Networks», RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

[RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, «TCP Alternative Backoff with ECN (ABE)», RFC 8511, DOI 10.17487/RFC8511, December 2018, <https://www.rfc-editor.org/info/rfc8511>.

[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, «RTP Control Protocol (RTCP) Feedback for Congestion Control», RFC 8888, DOI 10.17487/RFC8888, January 2021, <https://www.rfc-editor.org/info/rfc8888>.

[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, «The RACK-TLP Loss Detection Algorithm for TCP», RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9001] Thomson, M., Ed. and S. Turner, Ed., «Using TLS to Secure QUIC», RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, «The Datagram Transport Layer Security (DTLS) Protocol Version 1.3», RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, «Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture», RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/info/rfc9330>.

[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, «Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)», RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.

[Savage-TCP] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control with a Misbehaving Receiver», ACM SIGCOMM Computer Communication Review, Volume 29, Issue 5, pp. 71–78, DOI 10.1145/505696.505704, October 1999, <https://dl.acm.org/doi/abs/10.1145/505696.505704>.

[SCReAM-L4S] «SCReAM», commit 140e292, November 2022, <https://github.com/EricssonResearch/scream>.

[SCTP-ECN] Stewart, R., Tüxen, M., and X. Dong, «ECN for Stream Control Transmission Protocol (SCTP)», Work in Progress, Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January 2014, <https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctpecn-05>.

[sub-mss-prob] Briscoe, B. and K. De Schepper, «Scaling TCP’s Congestion Window for Small Round Trip Times», BT Technical Report: TR-TUB8-2015-002, DOI 10.48550/arXiv.1904.07598, May 2015, <https://arxiv.org/abs/1904.07598>.

[TCP-CA] Jacobson, V. and M. J. Karels, «Congestion Avoidance and Control», Laurence Berkeley Labs Technical Report, November 1988, <https://ee.lbl.gov/papers/congavoid.pdf>.

[TCPPrague] Briscoe, B., «Notes: DCTCP evolution ‘bar BoF’: Tue 21 Jul 2015, 17:40, Prague», message to the tcpPrague mailing list, July 2015, <https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html>.

[TRILL-ECN-SUPPORT] Eastlake 3rd, D. and B. Briscoe, «TRILL (Transparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support», Work in Progress, Internet-Draft, draft-ietf-trill-ecn-support-07, 25 February 2018, <https://datatracker.ietf.org/doc/html/draft-ietf-trill-ecn-support-07>.

[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, «One more bit is enough», SIGCOMM ’05: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 37-48, DOI 10.1145/1080091.1080098, August 2005, <https://doi.acm.org/10.1145/1080091.1080098>.

Приложение A. Обоснование требований Prague L4S

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

Требования и рекомендации раздела 4 называют «требованиями Prague L4S», поскольку они исходно заданы на специальной встрече в рамках конференции IETF 94 в Праге [TCPPrague]. Поначалу их называли требованиями TCP Prague, но они применимы не только к TCP, поэтому название было обобщено для других транспортных протоколов, а TCP Prague применяется для конкретной реализации требований.

На момент создания протокол DCTCP [RFC8257] был наиболее распространенным решением с масштабированием. В своей текущей форме DCTCP предназначен для внедрения лишь в контролируемых средах. Развёртывание в Internet приведёт к многочисленным проблемам в части безопасности и производительности. Указанные в этом приложении изменения и дополнительные механизмы потребуются для внедрения в общедоступной сети Internet. Там, где нужны примеры, DCTCP служит базой, но требования раздела 4 в той же мере применимы к другим элементам расширяемого контроля перегрузок, включая адаптивную передачу в реальном масштабе времени и т. п., а не только приложения, которым нужна пропускная способность.

A.1. Обоснование требований к масштабированию транспорта

A.1.1. Использование идентификатора пакета L4S

Описание

Мотивация

A.1.2. Точные отклики ECN

Описание

Мотивация

A.1.3. Возможность замены классическим контролем перегрузки

Описание

Мотивация

A.1.4. Возврат к классическому контролю при потере пакетов

Описание

Мотивация

Расширяемых контроль перегрузки может применяться для разных видов транспорт, например при передаче в реальном масштабе времени или для гарантированного транспорта, такого как TCP. Поэтому конкретное классическое поведение контроля перегрузки, к которому следует возвращаться, зависит от используемой реализации контроля. В случае DCTCP спецификация протокола [RFC8257] говорит: «Отправитель DCTCP должен реагировать на случаи потерь так же, как традиционный TCP.» Для обеспечения безопасного внедрения расширяемого контроля перегрузок в общедоступной сети Internet п. 2 из параграфа 4.3 в этом документе не требует отклика, в точности совпадающего с Reno TCP, но требует отклика, обеспечивающего безопасное сосуществование с классическим контролем перегрузки, подобным Reno.

Даже при поддержке L4S в узком месте может возникать перегрузка с потерей пакетов. В таких случаях отправитель может получить большое число пакетов с кодом CE, а также столкнуться с потерями. Текущие реализации DCTCP реагируют на такие ситуации по-разному. Одним из подходов является реагирование лишь на сигнал отбрасывания (например, сокращением cwnd вдвое), в другом применяется реакция на оба сигнала с большим сокращением cwnd. Предложен компромисс между этими подходами, где реакция на потерю настраивается так, чтобы привести к сокращению окна вдвое при наличии предшествующего отклика ECN в том же интервале кругового обхода. Представляет разумным проведение дополнительных экспериментов для поиска поведения, наиболее подходящего для общедоступной сети Internet.

A.1.5. Сосуществование с классическим контролем в узких местах с Classic ECN

Описание

Мотивация

• классический поток продолжает работать без истощения, хотя его пропускная способность может существенно снизиться из-за конкурирующего расширяемого потока;
• реализации Classic ECN AQM в очереди для совместного использования считаются редкими;
• обнаружение таких AQM не всегда однозначно, поэтому для уверенности нужно целенаправленное тестирование по отдельному каналу (out-of-band) или даже обращение в соответствующему оператору.

Поэтому соответствующие нормативные требования (параграф 4.3) разделены на 3 части (этапа).

Мониторинг

Обнаружение

Действия

Весь набор нормативных требования, относящихся к Classic ECN AQM, в параграфе 4.3 сформулирован так, что они не применяются в контролируемых средах, таких как частные сети и ЦОД. Серверы CDN, размещённые в сети доступа ISP, можно рассматривать как контролируемую среду, но все сети, обслуживаемые этой сетью доступа, включая сети клиентов, вряд ли будут входить в сферу того же координированного контроля. Для мониторинга таких неконтролируемых сегментов пути (например, в домашней сети за сетью доступа ISP) указан уровень «должен», поскольку для них имеется вероятность наличия общей очереди с Classic ECN AQM. Тем не менее, цель формулировки заключается в требовании лишь эпизодического мониторинга этих неконтролируемых участков сети без обременения операторов CDN, если мониторинг не выявляет каких-либо возможных проблем.

Более подробное рассмотрение всех вариантов можно найти в руководстве по эксплуатации L4S [L4SOPS].

С учётом отмеченного выше, подход, рекомендованный в параграфе 4.3, заключается в мониторинге, обнаружении и действиях по отношению к трафику в реальном масштабе времени. Алгоритм пассивного мониторинга для обнаружения ECN AQM в узких местах и возврата к классическому контролю перегрузок, описан в обширном техническом отчёте [ecn-fallback], где приведены также ссылки на исходный код Linux и сетевую визуализацию результатов оценок. Вкратце, алгоритм в основном отслеживает вариации RTT с использованием того же метода, который поддерживает среднее отклонение сглаженного RTT в TCP, но выполняет сглаживание в интервале того же порядка, что и при классической пиле. Результат зависит и от других показателей, таких как наличие маркировки CE и стабилизации фазы предотвращения перегрузки. В отчёте также указаны направления дальнейшей работы по улучшению подхода, например, для каналов с малой пропускной способностью или для сочетания измерений с кэшированием того, что было известно о пути из прежних соединений. В отчёте предложены и другие подходы.

Хотя использование пассивных инструментов для «живого» трафика (как указано выше) позволяет обнаружить Classic ECN AQM, гораздо сложнее (или невозможно) определить наличие AQM в общей очереди. Это гораздо проще сделать при активном тестировании вне основного канала, поскольку можно применить 2 потока. В разделе 4 отчёта [ecn-fallback] описан простой метод обнаружения Classic ECN AQM и проверки его размещения в общей очереди, который кратко рассмотрен ниже.

Тестовый сервер с поддержкой L4S можно настроить так, что при обращении к нему тестового клиента будет выполняться сценарий, позволяющий клиенту создать 2 параллельных долгосрочных потока. Один поток может работать с классическим контролем перегрузки (C, с установкой ECT(0)), другой — с расширяемым (L, с установкой ECT(1)). Если ни один из потоков не вызывает маркировки ECN, можно предположить, что на пути нет Classic ECN AQM. Если в каком-либо из потоков возникает маркировка ECN, сервер может измерить относительные скорости потоков и время кругового обхода для них. В таблице показаны механизмы AQM, которые можно предположить в разных случаях (в предположении отсутствия других вариантов поведения AQM, кроме известных при написании).

Таблица . Тестирование по отдельному каналу с 2 параллельными потоками.

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

• Если отправитель в соответствии с рекомендациями меняет лишь своё поведение на классическое, но не меняет код, его код остаётся совместимым с L4S или Classic AQM. Если в узком месте фактически поддерживаются оба режима, код ECT(1) будет по-прежнему классифицироваться в ту же очередь L4S и отправитель может понять, что переход к классическому поведению был ошибкой и вернуться назад.

• Если же отправитель меняет поведение и код даже при поддержке в узком месте обоих режимов, он будет классифицировать ECT(0) в классическую очередь, форсируя некорректное решения без возможности возврата.

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

  Отметим, что при настройке потока на применение лишь классического контроля перегрузок вполне уместно не использовать код ECT(1).

A.1.6. Снижение зависимости от RTT

Описание

Мотивация

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

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

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

      rtt_virt = max(rtt, 25 ms)
      rtt_virt = rtt + 10 ms

Функции в этих примерах выбраны так, что по мере снижения фактического RTT от высокого к низкому виртуальное значение RTT сокращается более медленно (см. [PRAGUE-CC]).

Однако потоки с коротким RTT могут быстрее реагировать на изменения доступной пропускной способности, будь то изменение состава потоков или пропускной способности радиоканалов. Таким образом, было бы ошибкой требовать, чтобы потоки с малым RTT были столь же медлительными, как потоки с большим RTT, поскольку это привело бы к ненужно недогрузке каналов и в результате вызывало бы нестабильность. Поэтому вместо строго требования независимости от RTT в п. 4 параграфа 4.3 сказано: «не зависит от RTT, насколько это возможно без ущерба для стабильности и загрузки канала.» Это позволяет потокам с меньшим RTT использовать свои преимущества в гибкости.

A.1.7. Сокращение окна перегрузки

Описание

Мотивация

Механизмы L4S значительно сокращают задержку в очередях, поэтому на одном и том же пути RTT снижается. Эта проблема становится на удивление распространённой [sub-mss-prob], потому что при одинаковой пропускной способности канала меньшее значение RTT подразумевает меньшее окно. Рассмотрим, например, жилое здание с восходящим каналом широкополосного доступа в Internet со скоростью 8 Мбит/с, предполагая максимальный размер сегмента 1500 байт. Каждый из 2 восходящих потоков будет иметь минимальное окно 2 SMSS, если RTT не больше 6 мсек, что достаточно характерно при доступе к ближайшему ЦОД. При наличии 2 таких потоков TCP перестанет отвечать на ECN и задержка в очередях возрастёт.

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

Это, по-видимому, подразумевает, что будут требоваться средства расширяемого контроля перегрузки, способные работать с окном перегрузки меньше 1 SMSS. Например, если TCP с поддержкой ECN получает маркер ECN, уже имея окно в 1 SMSS, [RFC3168], он должен отложить передачу до тайм-аута повтора. Менее радикальный, но более сложный механизм может поддерживать окно перегрузки меньше 1 SMSS (при необходимости, значительно меньше), как описано в [Ahmed19]. Вероятно, возможны и другие подходы.

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

Указание для перехода к окну меньше 1 SMSS уровня «следует» при сохранении требований [RFC3168] позволяет отследить варианты изменения минимального окна в разных масштабируемых контроллерах перегрузки.

A.1.8. Измерение устойчивости к нарушению порядка по времени

Описание

Мотивация

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

Если не применять требования параграфа 4.3 к хостам L4S, даже при отсутствии обременения для хостов все сети столкнулись бы с неопределённостью в части способности некоторых хостов L4S обнаруживать потери по времени. Тогда всем канальным технологиям пришлось бы сокращать время, в течение которого допускается переупорядочение пакетов. Это не является проблемой для некоторых канальных технологий, но для других все сильнее осложняется масштабирование, особенно при использовании группировки каналов (bonding) в таких технологиях как LTE, 5G, DOCSIS¹⁶.

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

Может возникнуть вопрос осмысленности реализации этого требования к обнаружению потерь лишь на хостах L4S, поскольку сети всё равно будут сталкивать с неопределённостью обнаружения потерь с помощью DupACK для потоков без поддержки L4S. Ответ заключается в том, что канальные технологии, где сложно постоянно сокращать интервал переупорядочивания, должны будут решать вопрос лишь для трафика, не относящегося к L4S (это возможно, поскольку идентификатор L4S виден на уровне IP). Поэтому можно сосредоточить внимание на ресурсах обработки и памяти при расширении классического (не L4S) трафика. Тогда рост доли трафика L4S будет смягчать проблемы масштабирования.

В итоге для хостов L4S не никаких причин быть частью проблемы, а не её решения.

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

Детали

A.2. Оптимизация расширяемого транспортного протокола

A.2.1. Установка ECT в пакетах управления и повторных пакетах

Описание

Мотивация для TCP

Мотивация для RTCP

A.2.2. Рост быстрее аддитивного

Описание

Мотивация

A.2.3. Быстрое схождение при замедленном старте

Описание

Мотивация

Приложение B. Компромиссы при выборе идентификатора L4S

Это приложение является информационным, а не нормативным. Как указано в разделе 3, пространства заголовков IP (v4 и v6) не достаточно для полного выполнения требования. Поэтому при выборе идентификатора L4S потребовались компромиссы. В этом приложении приведены аргументы за и против сделанного выбора.

Ниже приведён ненормативный обзор схемы кодов.

Пакеты с кодом ECT(1) и (условно) CE обозначают семантику L4S как альтернативу семантике Classic ECN [RFC3168].

• Код ECT(1) указывает, что пакет передан отправителем, поддерживающим L4S.

• С учётом нехватки кодов L4S AQM и Classic ECN AQM используют общий код CE для индикации встреченной пакетом перегрузки. Если пакета уже получил маркер CE в буфере восходящего направления до поступления в следующий механизм AQM, этот механизм должен угадать для пакета CE классификацию L4S или Classic ECN. Выбор обработки L4S безопасней, поскольку в этом случае несколько классических пакетов могут прибыть раньше, а пакеты L4S не будут задержаны.

• Если классификатор знает о транспорте, может быть доступна дополнительная информация. Тогда классификатор может отнести пакет CE к ECN, если предшествующий пакет ECT из того же потока имел код ECT(0). Однако службе L4S не требуется знать о транспортном уровне.

Возражения

Используется последний код ECN

Сложности ECN на некоторых нижележащих уровнях

Риск нарушения порядка классических пакетов CE внутри потока

1. Достаточно необычно наличие нескольких узких местам на одном пути (доступная пропускная способность должна быть для этого идентична).
2. Лишь в части таких случаев первое узкое место будет поддерживать маркировку Classic ECN, а второе — L4S ECN. Это будет единственным случаем, где пакеты ECT(0) могут получить маркер CE от AQM, поддерживающего Classic ECN, тогда как далее оставшиеся пакеты ECT(0) будут сталкиваться с дальнейшей задержкой на классической части последующего L4S DualQ AQM.
3. Даже при досрочной доставке нескольких пакетов потребуются весьма необычные условия для вызова ложных повторов в отличие от случаев запоздания некоторых пакетов. В первом узком месте маркеры CE будут применены по меньшей мере для N (размер окна переупорядочивания, разрешаемого транспортным протоколом, прежде, чем он сочтёт пакет потерянным) последовательных пакетов, а второе узкое место внедрит непрерывную последовательность и (по меньше мере) N таких пакетов между двумя пакетами потока, переданными ранее.
   Рассмотрим, например, случай N=3 и последовательность пакетов 100, 101, 102, 103, … Предположим, что пакеты 150, 151, 152, переданные в потоке позднее, были внедрены в последовательность 100, 150, 151, 101, 152, 102, 103, … Если бы это было поздним нарушением порядка, даже 1 пакет с нарушением порядка вызвал бы ложный повтор, но здесь этого не происходит, поскольку пакет 101 перемещает счётчик кумулятивных ACK вперёд на 3 пакета, прибывших с нарушением порядка. Позднее, по приходе пакетов 148, 149, 153, … проблем не будет, несмотря на пропуск 3 пакетов, поскольку пакеты для заполнения пропуска уже находятся в приёмном буфере.
4. Даже при текущей рекомендации TCP N=3 [RFC5681] ложные повторы будут маловероятны по указанным выше причинам. По мере внедрения RACK [RFC8985] возникает тенденция к увеличению размера окна разупорядочения (N), что сделает вероятность преждевременного прибытия N пакетов подряд исчезающе малой.
5. Наличие двух маркеров CE в потоке Classic ECN маловероятно с учётом того, что FQ-CoDel является единственным широко развёрнутым AQM с поддержкой маркировки Classic ECN и он очень тщательно разделяет потоки и равномерно распределяет маркировку между потоками.

Недостаточное окно anti-replay в некоторых имеющихся VPN

Трудно отличить Classic ECN AQM

Услуги без L4S для пакетов управления

Поддержка

Нужна сквозная работа

Нужна работа в туннелях

Нужна работа с разными канальными технологиями

Возможен переход к одному коду

L4 не требуется

Приложение C. Возможные конфликты при использовании кода ECT(1)

Код ECT(1) в поле IP-ECN уже был выделен спецификацией ECN nonce [RFC3540], которая признана устаревшей (Historic) [RFC8311]. ECN вероятно является единственным среди протоколов Internet полем, общим для IPv4 и IPv6, сохраняя возможность сквозного применения с туннелями и нижележащими уровнями. Поэтому код ECT(1) не следует переназначать для другого экспериментального использования (L4S) без тщательной оценки возможных конфликтов. Эти вопросы рассматриваются ниже.

C.1. Целостность откликов на перегрузку

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

Устаревшая спецификация ECN nonce [RFC3540] предполагала, что отправитель TCP может устанавливать до ECT(0) или ECT(1) в каждом пакете потока и запоминать последовательность установки. Если какой-либо пакет будет потерян или промаркирован при перегрузке, получатель не увидит соответствующий бит. Получатель ECN nonce отправляет назад младший бит суммы, поэтому он не может скрыть потерю или маркировку без 50% вероятности ошибки в сумме.

Крайне маловероятно, что ECT(1) потребуется в качестве nonce для защиты целостности уведомлений. Спецификация ECN nonce [RFC3540] признана устаревшей отчасти из-за появления других способов (без использования кода в заголовке IP) защиты целостности откликов TCP и другого транспорта [RFC8311]. Ниже дано несколько примеров.

• Отправитель может проверить целостность небольшой случайной выборки откликов получателя, время от времени указывая в поле IP-ECN значение, которое обычно устанавливает сеть. Затем он проверяет, верно ли отклики получателя передают ожидаемое (см. п. 2 в параграфе 20.2 спецификации ECN [RFC3168]). Это работает для потерь и подходит для точных откликов ECN [RFC7560], предназначенных для L4S. Как и (устаревшая) спецификация ECN, этот метод не защищает от некорректного поведение отправителя, но позволяет добросовестному отправителю проверить корректность откликов о перегрузке от получателя.

• Сеть может проверить корректность передачи маркеров ECN (или потери пакетов) по всему контуру обратной связи, отслеживая раскрытие перегрузки (Congestion Exposure или ConEx) [RFC7713]. Это предполагает целостность уведомлений о перегрузке и откликов обратной связи. Сведения ConEx доступны в любой точке пути через сеть, поэтому они могут применяться для принудительных откликов на перегрузку. Независимо от подавления получателем или нисходящим направлением в сети откликов о перегрузке или некорректной реакции отправителя на них, ConEx позволяет нейтрализовать любые преимущества, которые можно получить за счёт такого обмана.

• Поля откликов о перегрузке в заголовках транспортного уровня передаются без изменений насквозь и их целостность может быть защищена. Это сохраняет целостность откликов получателя, но не защищает от некорректного поведения получателя или отправителя. Опция аутентификации TCP (TCP Authentication Option или TCP-AO) [RFC5925], сквозная защита QUIC [RFC9001] или защита целостности IPsec [RFC4303] позволяют обнаружить вмешательство в отклики о перегрузке (случайные или враждебные) в TCP, QUIC и ином транспорте. TCP-AO по умолчанию учитывает основной заголовок TCP и опции TCP, но часто не обеспечивает достаточной прочности для использования на многих сквозных путях, где промежуточные устройства могут приводить к отрицательному результату проверки из-за их попыток улучшить производительность или безопасность (например, путём повторной сегментации или сдвига пространства порядковых номеров).

На момент написания этого документа защита целостности транспортных откликов с использованием QUIC становилась обычным делом. Однако по-прежнему не принято защищать целостность более широкого контура обратной связи на основе потерь или Classic ECN. Если это положение измениться в процессе экспериментов L4S, может потребоваться разработка одного или нескольких методов из числа указанных выше.

C.2. Уведомление о менее значимой по сравнению с CE перегрузкой

Исследователи предлагали использовать код ECT(1) в качестве уведомления о менее серьёзной перегрузке, нежели CE, в частности, для того, чтобы потоки могли быстрее заполнить доступную пропускную способность после периода бездействия, при завершении или запуске других потоков, например, как в VCP¹⁸ [VCP] и Queue View (QV) [QV].

Перед назначением ECT(1) на роль идентификатора L4S нужно было решить, не лучше ли сохранить код для будущей стандартизации быстрого ускорения потоков, которая считается важной и долговременной проблемой [RFC6077].

Уведомление до перегрузки (Pre-Congestion Notification или PCN) является ещё одним вариантом альтернативной семантики IP-ECN. Здесь ECT(1) служит для уведомления о менее серьёзной перегрузке, чем CE [RFC6660], однако поле IP-ECN принимает семантику PCN лишь для пакетов с кодом Diffserv, заданным для указания маркировки PCN в контролируемой среде. PCN требуется применять лишь к внешнему заголовку туннеля через контролируемую область, чтобы не было конфликтов с иным сквозным применением поля ECN. Поэтому регион PCN на пути не помешает идентификатору L4S, заданному в разделе 2.

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

Спасибо Richard Scheffenegger, John Leslie, David Täht, Jonathan Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson, Andrew McGregor за обсуждения, которые привели к созданию этой спецификации. Ing-jyh (Inton) Tsang был одним из авторов предварительных версий документа. Спасибо Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn, Greg White, Tom Henderson, David Black, Gorry Fairhurst, Brian Carpenter, Jake Holland, Rod Grimes, Richard Scheffenegger, Sebastian Moeller, Neal Cardwell, Praveen Balasubramanian, Reza Marandian Hagh, Pete Heist, Stuart Cheshire, Vidhi Goel, Mirja Kühlewind, Ermin Sakic, Martin Duke за помощь и рецензирование документа. Спасибо thanks Ingemar Johansson за рецензирование и предоставление содержательного текста. Спасибо также рецензентам направления: Valery Smyslov, Maria Ines Robles, Bernard Aboba, Lars Eggert, Roman Danyliw, Éric Vyncke. Спасибо Sebastian Moeller за выявление взаимодействия м VPN anti-replay и Jonathan Morton за выявление связанных с этим атак. Отдельная благодарность руководителям tsvwg Gorry Fairhurst, David Black, Wes Eddy за терпеливую помощь для этого и других документов L4S при прохождении процесса IETF. Приложение A с требованием Prague L4S основано на тексте, написанном Marcelo Bagnulo Braun изначально в качестве приложения к [RFC9330]. Этот текст, в свою очередь, был основан на коллективных результатах участников «круглого стола» DCTCP Evolution в рамках IETF 94 [TCPPrague].

Работа авторов частично финансировалась European Community по программе Seventh Framework в рамках проекта Reducing Internet Transport Latency (RITE) (ICT-317700). Работа Koen De Schepper частично финансировалась в рамках проектов 5Growth и DAEMON EU H2020. Работу Bob Briscoe частично финансировалась Research Council of Norway в рамках проекта TimeIn, а также CableLabs и Comcast Innovation Fund. Представленные здесь мнения принадлежат исключительно авторам.

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

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

(nmalykh@protokols.ru)