RFC 9406 HyStart++: Modified Slow Start for TCP

Internet Engineering Task Force (IETF)                P. Balasubramanian
Request for Comments: 9406                                     Confluent
Category: Standards Track                                       Y. Huang
ISSN: 2070-1721                                                 M. Olson
                                                               Microsoft
                                                                May 2023

HyStart++: Modified Slow Start for TCP

HyStart++ – изменённый алгоритм Slow Start для TCP

PDF

Аннотация

В этом документе описывается HyStart++ – простое изменение фазы замедленного старта для алгоритмов контроля перегрузки. Замедленный старт во многих случаях может приводить к превышению идеальной скорости передачи, вызывающему потерю пакетов и снижение производительности. В HyStart++ используется увеличение времени кругового обхода (round-trip delay) в качестве эвристических данных для нахождения точки выхода до возможного превышения скорости. Это также смягчает возникновение вариаций задержки (jitter), приводящих к преждевременному выходу из замедленного старта.

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

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

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

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

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

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

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

1. Введение

В [RFC5681] описан алгоритм замедленного старта для контроля перегрузок в протоколе TCP. Алгоритм замедленного старта применяется в случаях, когда окно перегрузок (congestion window или cwnd) становится меньше порога замедленного старта (slow start threshold или ssthresh). В процессе замедленного старта при отсутствии потерь пакетов протокол TCP экспоненциально увеличивает значение cwnd для определения пропускной способности сети (network capacity). Такой быстрый рост может приводить к тому, что скорость передачи станет выше идеальной и это приведёт к значительным потерям пакетов, которые не всегда можно восстановить.

HyStart++ строится на основе алгоритма Hybrid Start (HyStart), исходно описанного в [HyStart]. HyStart++ использует увеличение времени кругового обхода (round-trip delay) как сигнал для выхода из процедуры замедленного старта до того, как станут возможны потери в результате превышения скорости. Это один из двух алгоритмов, заданных в [HyStart] для поиска безопасной точки выхода из процедуры замедленного старта. После выхода из процедуры замедленного старта используется новая фаза консервативного замедленного старта (Conservative Slow Start или CSS) для решения вопроса, не был ли этот выход преждевременным и возобновления замедленного старта при преждевременному выходе. Такое смягчение повышает производительность при наличии вариаций задержки. Механизм HyStart++ снижает потери пакетов и их повторную передачу, повышая производительность в лабораторных условиях и работающих системах.

Хотя документ описывает HyStart++ для протокола TCP, механизм можно использовать и с другими транспортными протоколами, применяющими замедленный старт, такими как QUIC [RFC9002] или SCTP3 [RFC9260].

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

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

3. Определения

Чтобы помочь читателям, ниже приведены некоторые определения из [RFC5681].

SENDER MAXIMUM SEGMENT SIZE (SMSS) – максимальный размер сегмента для отправителя

Размер самого большого сегмента, который может быть передан отправителем. Это значение может определяться на основе максимального блока данных, передаваемого через сеть, алгоритма определения Path MTU [RFC1191, RFC4821], RMSS (см. следующее определение) и других факторов. Значение не включает размеры заголовков и опций TCP/IP.

RECEIVER MAXIMUM SEGMENT SIZE (RMSS) – максимальный размер сегмента для получателя

RMSS – размер максимального сегмента, который желает принимать получатель. Это значение задаётся в опции MSS, передаваемой хостом при организации соединения. Если опция MSS при организации соединения не была задана, используется значение 536 байтов [RFC1122]. Значение не включает размеры заголовков и опций TCP/IP.

RECEIVER WINDOW (rwnd) – размер окна принимающей стороны

Последнее анонсированное значение размера окна принимающей стороны.

CONGESTION WINDOW (cwnd) – размер окна насыщения (перегрузки)

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

4. Алгоритм HyStart++

4.1. Обзор

В [HyStart] заданы два алгоритма (Delay Increase и Inter-Packet Arrival), которые работают параллельно для определения момента, когда скорость передачи достигает предела возможностей сети (capacity). На практике алгоритм Inter-Packet Arrival не работает достаточно хорошо и не способен обнаруживать перегрузку заранее прежде всего в результате сжатия ACK. Идея алгоритма Delay Increase состоит в поиске скачков времени кругового обхода (round-trip time или RTT), которые указывают заполнение буферов в узком месте сети (bottleneck).

В HyStart++ отправитель TCP использует стандартный замедленный старт и алгоритм увеличения задержки (Delay Increase) для инициирования выхода из процедуры замедленного старта. Но вместо незамедлительного перехода от механизма slow start к предотвращению перегрузки (congestion avoidance), отправитель в течение нескольких интервалов RTT в фазе консервативного замедленного старта (CSS) для решения вопроса о своевременности выхода из процедуры замедленного старта. В процессе CSS окно перегрузок увеличивается экспоненциально, подобно обычной процедуре замедленного старта, но с меньшим показателем, что ведёт к менее агрессивному росту. Если RTT снижается в процессе CSS, считается что скачок RTT не был вызван перегрузкой, связанной с ростом скорости передачи сверх идеальной, и для соединения возобновляется замедленный старт. Если рост RTT продолжается в процессе CSS, соединение переходит в режим предотвращения перегрузки.

4.2. Детали алгоритма

В приведённом ниже псевдокоде предел L служит для управления энергичностью (aggressiveness) увеличения cwnd в стандартном механизме замедленного старта и CSS. Хотя прибытие ACK может заново подтверждать доставку произвольного числа байтов, алгоритм HyStart++ ограничивает число байтов, применяемых для увеличения cwnd значением L*SMSS.

При инициализации для lastRoundMinRTT и currentRoundMinRTT устанавливаются бесконечные значения, currRTT указывает значение RTT, полученное из входящего ACK, и при инициализации также устанавливается бесконечным.

   lastRoundMinRTT = infinity
   currentRoundMinRTT = infinity
   currRTT = infinity

HyStart++ определяет интервал (round) на основе порядковых номеров:

  • определяется windowEnd как порядковый номер, инициализируемый значением SND.NXT;

  • при подтверждении номера windowEnd (ACK) текущий интервал считается завершённым и снова устанавливается windowEnd = SND.NXT.

В начале каждого интервала при стандартном замедленном старте [RFC5681] и CSS инициализируются переменные, применяемые для расчёта минимального значения RTT в текущем интервале

   lastRoundMinRTT = currentRoundMinRTT
   currentRoundMinRTT = infinity
   rttSampleCount = 0

Для каждого прибывающего ACK при замедленном старте (N – число не подтверждённых ранее байтов, подтверждаемых данным ACK)

  • обновляется cwnd

     cwnd = cwnd + min(N, L * SMSS)
  • сохраняется минимальное наблюдавшееся значение RTT

     currentRoundMinRTT = min(currentRoundMinRTT, currRTT)
     rttSampleCount += 1

Для интервалов, в которых получено хотя бы N_RTT_SAMPLE значений RTT и текущие значения currentRoundMinRTT и lastRoundMinRTT действительны, проверяется, вызывает ли рост задержки выход из процедуры замедленного старта

   if ((rttSampleCount >= N_RTT_SAMPLE) AND
       (currentRoundMinRTT != infinity) AND
       (lastRoundMinRTT != infinity))
     RttThresh = max(MIN_RTT_THRESH,
       min(lastRoundMinRTT / MIN_RTT_DIVISOR, MAX_RTT_THRESH))
     if (currentRoundMinRTT >= (lastRoundMinRTT + RttThresh))
       cssBaselineMinRtt = currentRoundMinRTT
       выход из slow start и запуск CSS

Для каждого прибывающего ACK в CSS (N – число не подтверждённых ранее байтов, подтверждаемых данным ACK)

  • обновляется cwnd

   cwnd = cwnd + (min(N, L * SMSS) / CSS_GROWTH_DIVISOR)
  • сохраняется минимальное наблюдавшееся значение RTT

   currentRoundMinRTT = min(currentRoundMinRTT, currRTT)
   rttSampleCount += 1

Для интервалов CSS , в которых получено хотя бы N_RTT_SAMPLE значений RTT, проверяется, не стало ли значение minRTT текущего интервала ниже базового (cssBaselineMinRtt), что указывает на ложный выход из процедуры замедленного старта

   if (currentRoundMinRTT < cssBaselineMinRtt)
     cssBaselineMinRtt = infinity
     возобновление slow start, включая HyStart++

CSS продолжается не более CSS_ROUNDS интервалов. Если переход в CSS произошёл в середине интервала, неполный интервал учитывается.

По истечении CSS_ROUNDS интервалов запускается алгоритм предотвращения перегрузки установкой

   ssthresh = cwnd

При наличии потерь или маркеров явного уведомления о перегрузке (Explicit Congestion Notification или ECN) во время стандартной процедуры замедленного старта или CSS запускается механизм предотвращения перегрузки установкой

   ssthresh = cwnd

4.3. Настройка констант и другие соображения

Реализациям HyStart++ рекомендуется устанавливать приведённые ниже значения констант.

   MIN_RTT_THRESH = 4 мсек
   MAX_RTT_THRESH = 16 мсем
   MIN_RTT_DIVISOR = 8
   N_RTT_SAMPLE = 8
   CSS_GROWTH_DIVISOR = 4
   CSS_ROUNDS = 5
   L = бесконечность в режиме с «прореживанием», L = 8 в ином случае

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

Чувствительность к росту задержки определяется константами MIN_RTT_THRESH и MAX_RTT_THRESH. Меньшие значения MIN_RTT_THRESH могут вызывать необоснованный выход из процедуры slow start, большие значения MAX_RTT_THRESH – препятствовать выходу из slow start до момента возникновения потерь на путях с большим RTT.

MIN_RTT_DIVISOR – это доля4 RTT, применяемая для расчёта порога задержки. Меньшее значение повышает порог, снижая чувствительность к росту задержки.

Хотя от всех реализаций TCP требуется делать хотя бы 1 выборку RTT за каждый интервал, реализациям HyStart++ рекомендуется делать не меньше N_RTT_SAMPLE выборок RTT. Уменьшение N_RTT_SAMPLE будет снижать точность измерения RTT, а большие значения повышают точность за счёт роста издержек на обработку.

Для CSS_GROWTH_DIVISOR должно устанавливаться значение не меньше 2. Значение 1 приведёт к такому же поведению, как при обычном замедленном старте, значения больше 4 снижают энергичность алгоритма и могут снижать производительность.

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

«Прореживание» (pacing) пакетов [ASA00] является одним из возможных механизмов предотвращения значительных пиков трафика и связанного с этим ущерба. В реализации TCP с прореживанием следует устанавливать бесконечное значение L. Прореживание смягчает проблемы, связанные с пиками трафика и такая установка обеспечивает оптимальный рост cwnd в современной сети.

В реализациях TCP с прореживанием для смягчения влияния пиков трафика конечные значения L могут приводить к существенным проблемам производительности в высокоскоростных сетях по причине медленного роста cwnd. Для реализация TCP без прореживания значение L меньше 8 могут приводить к существенным проблемам производительности в высокоскоростных сетях по причине медленного роста cwnd, а значения больше 8 могут способствовать возникновению пиков трафика и соответствующему снижению производительности.

Реализациям следует использовать HyStart++ только в начальной процедуре slow start (когда ssthresh имеет начальное значение, произвольное в соответствии с [RFC5681]) и возвращаться к стандартной процедуре slow start в течение остального времени действия соединения. Это приемлемо, поскольку в последующих процедурах slow start используется обнаруженное значение ssthresh для выхода из процедуры замедленного старта и предотвращения проблемы превышения скорости. Реализация может использовать HyStart++ для увеличения restart window [RFC5681] после длительного бездействия.

В ограниченных приложениями сценариях, где объем находящихся в сети данных (in flight) может быть меньше произведения задержки на пропускную способность (bandwidth-delay product или BDP), снижая число выборок RTT, что может приводить к возврату в slow start. В таких случаях ожидается «колебание» между механизмами CSS и slow start, но такое поведение не будет приводить к преждевременному переходу в режим предотвращения перегрузки или превышению скорости по сравнению с обычным механизмом slow start.

5. Развёртывание и оценка производительности

Во время подготовки этого документа описанный здесь механизм HyStart++ был по умолчанию включён для всех соединений TCP в операционной системе Windows уже более 2 лет с отключённым прореживанием и L = 8.

В лабораторных измерениях с Windows TCP механизм HyStart++ показал улучшение пропускной способности, а также сокращение потери пакетов и повтора передачи по сравнению со стандартным механизмом slow start. Например, различные тесты на каналах 100 Мбит/с размером буфера, ограниченным произведением задержки на пропускную способность, механизм HyStart++ снижает объем повторно передаваемых данных на 50% (в байтах) и тайм-аут повтора (retransmission timeout или RTO) на 36%.

В тесте A/B, где сравнивалась реализация HyStart++ (на основе предварительной версии этого документа) со стандартным механизмом slow start в среде с большим числом устройств Windows из 52 миллиардов соединений TCP лишь 0,7% соединений переходили от 1 RTO к 0 RTO и ещё 0,7% – от 2 RTO к 1 RTO при использовании HyStart++. Этот тест не был сфокусирован на соединениях с отправкой большого объёма данных, где влияние может оказаться существенно сильнее. Планируется проведение дополнительных экспериментов для сбора данных.

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

HyStart++ улучшает механизм slow start и наследует соображения безопасности, отмеченные в [RFC5681].

Атакующий может вызвать преждевременный выход HyStart++ из процедуры замедленного старта и снизить производительность соединения TCP, например, путём отбрасывания пакетов данных или их подтверждения.

Атака ACK division, описанная в [SCWA99]Ю не влияет на HyStart++, поскольку расширение окна перегрузки для HyStart++ основано на числе вновь подтверждённых данных в каждом прибывающем ACK, а не на увеличении на конкретную константу при получении каждого ACK.

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

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

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

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

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

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

[ASA00] Aggarwal, A., Savage, S., and T. Anderson, “Understanding the performance of TCP pacing”, Proceedings IEEE INFOCOM 2000, DOI 10.1109/INFCOM.2000.832483, March 2000, <https://doi.org/10.1109/INFCOM.2000.832483>.

[HyStart] Ha, S. and I. Rhee, “Taming the elephants: New TCP slow start”, Computer Networks vol. 55, no. 9, pp. 2092-2110, DOI 10.1016/j.comnet.2011.01.014, June 2011, <https://doi.org/10.1016/j.comnet.2011.01.014>.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., “QUIC Loss Detection and Congestion Control”, RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.

[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, “Stream Control Transmission Protocol”, RFC 9260, DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.

[SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, “TCP congestion control with a misbehaving receiver”, ACM SIGCOMM Computer Communication Review, vol. 29, issue 5, pp. 71-78, DOI 10.1145/505696.505704, October 1999, <https://doi.org/10.1145/505696.505704>.

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

В процессе обсуждения этой работы в почтовой конференции TCPM и на встречах рабочей группы были получены полезные комментарии и рецензии от (в алфавитном порядке фамилий) Mark Allman, Bob Briscoe, Neal Cardwell, Yuchung Cheng, Junho Choi, Martin Duke, Reese Enghardt, Christian Huitema, Ilpo Järvinen, Yoshifumi Nishida, Randall Stewart, Michael Tüxen.

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

Praveen Balasubramanian
Confluent
899 West Evelyn Ave
Mountain View, CA 94041
United States of America
Email: pravb.ietf@gmail.com
 
Yi Huang
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Phone: +1 425 703 0447
Email: huanyi@microsoft.com
 
Matt Olson
Microsoft
One Microsoft Way
Redmond, WA 98052
United States of America
Phone: +1 425 538 8598
Email: maolson@microsoft.com

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

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

nmalykh@protokols.ru

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

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

3Stream Control Transmission Protocol – протокол управления потоковой передачей.

4Результат деления. Прим. перев.

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

RFC 9375 A YANG Data Model for Network and VPN Service Performance Monitoring

Internet Engineering Task Force (IETF)                        B. Wu, Ed.
Request for Comments: 9375                                    Q. Wu, Ed.
Category: Standards Track                                         Huawei
ISSN: 2070-1721                                        M. Boucadair, Ed.
                                                                  Orange
                                                     O. Gonzalez de Dios
                                                              Telefonica
                                                                  B. Wen
                                                                 Comcast
                                                              April 2023

A YANG Data Model for Network and VPN Service Performance Monitoring

Модель данных YANG для мониторинга производительности сетей и служб VPN

PDF

Аннотация

Модель данных для сетевых топологий, заданная в RFC 8345, вносит вертикальные межуровневые взаимодействия между сетями, которые можно дополнить для других топологий сетей и служб. Этот документ определяет модуль YANG для мониторинга производительности (performance monitoring или PM) базовых сетей и наложенных служб VPN, который может применяться для отслеживания производительности сетей на обоих уровнях и управления ею.

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

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

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

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

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

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. Введение

В [RFC8969] описана модель автоматизации управления сетями и службами с помощью моделей данных YANG [RFC7950]. Там сказано, что модель телеметрических измерений следует связывать с моделями служб (таких как L3 VPN или L2 VPN) или сетей для мониторинга общей производительности сети и соглашений об уровне сервиса (Service Level Agreement или SLA).

Производительность служб VPN связана с изменениями производительности базовых сетей, обеспечивающих услуги VPN. Например, задержка в канале между устройствами на периметре (Provider Edge или PE) и в сети провайдера (Provider или P) и состояние потери пакетов на интерфейсах L2 и L3, соединяющих PE и граничные устройства клиента (Customer Edge или CE), напрямую влияют на производительность услуг VPN. Кроме того, интеграция данных о производительности L2/L3 VPN и сети позволяет оркестраторам выполнять согласованный мониторинг. Поэтому данный документ задаёт модуль YANG для мониторинга производительности (PM) сети и службы VPN. Модуль пригоден для мониторинга и управления производительностью сети на уровне топологии сети или топологии сервиса между сайтами VPN.

Базовую модель из раздела 5. Модуль YANG для мониторинга производительности сетей и VPN можно расширить включением связанных с технологией деталей, например, добавив статистику явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) сетей L3 или служб VPN для поддержки зависящих от производительности приложений.

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

Модуль YANG, определённый здесь, предназначен для дополнения модели данных YANG для топологии сети, заданный в [RFC8345], и использует соответствующие типы YANG из [RFC6991], [RFC8345], [RFC8532], [RFC9181].

В Приложении A представлен набор примеров, иллюстрирующих применение модуля.

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

Ниже указаны используемые к этом документе термины, которые определены в [RFC7950].

  • Augment – дополнение.
  • Data model – модель данных.
  • Data node – узел данных.

Термины для описания моделей данных YANG приведены в [RFC7950].

Деревья представлены в этом документе с использованием нотации [RFC8340].

2.1. Сокращения

CE

Customer Edge – граничное оборудование коиента, как определено в [RFC4026].

L2VPN

Layer 2 Virtual Private Network – виртуальная частная сеть канального уровня, как определено в [RFC4026].

L3VPN

Layer 2 Virtual Private Network – виртуальная частная сеть сетевого уровня, как определено в [RFC4026].

L2NM

L2VPN Network Model – модель сети L2VPN.

L3NM

L3VPN Network Model – модель сети L3VPN.

MPLS

Multiprotocol Label Switching – многопротокольная коммутация по меткам.

OAM

Operations, Administration, and Maintenance – эксплуатация, администрирование, поддержка.

OSPF

Open Shortest Path First – сначала по кратчайшему пути.

OWAMP

One-Way Active Measurement Protocol – протокол активных измерений в одном направлении, заданный в [RFC4656].

P

Provider router – маршрутизатор провайдера, как определено в [RFC4026].

PE

Provider Edge – граничное устройство провайдера, как определено в [RFC4026].

PM

Performance Monitoring – мониторинг производительности.

SLA

Service Level Agreement – соглашение об уровне обслуживания.

TP

Termination Point – точка завершения, как определено в параграфе 4.2 [RFC8345].

TWAMP

Two-Way Active Measurement Protocol – протокол активных измерений в 2 направлениях, заданный в [RFC5357].

VPLS

Virtual Private LAN Service – служба виртуальных частных ЛВС, как определено в [RFC4026].

VPN

Virtual Private Network – виртуальная частная сеть.

3. Использование модели мониторинга производительности

Модели очень важны для автоматизации управления сетью (раздел 3 в [RFC8969]). В частности, нужны модели сети и служб, а также телеметрии производительности для отслеживания производительности сети в соответствии с требованиями сервиса (обычно указываются в SLA).

                     +---------------+
                     |    Клиент     |
                     +-------+-------+
                             |
Модели обслуживания клиентов |
                             |
                     +-------+---------+
                     |  Оркестратор    |
                     |     услуг       |
                     +------+-+--------+
                            | |
    Модели сетевого сервиса | | Модели PM для сети и VPN
                            | |
                     +------+-+--------+
                     |   Контроллер    |
                     |      сети       |
                     +-------+---------+
                             |
     +-----------------------+------------------------+
                           Сеть

Рисунок 1. Пример архитектуры с оркестратором служб.


Модель PM для сети и VPN может служить для раскрытия сведений о рабочей производительности вышележащему уровню, например, оркестратору или иному клиентскому приложению поддержки бизнеса (Business Support System или BSS) или эксплуатации (Operational Support System или OSS) через стандартные API управления сетью. На рисунке 1 показан пример использования многоуровневой архитектуры модели, описанной в [RFC8309].

Перед использованием модели контроллеру нужно обеспечить видимость топологии сети и VPN. Например, контроллер использовать сведения о сети от [RFC8345] и [YANG-SAP] или о VPN от модели L3VPN (L3VPN Network Model или L3NM) [RFC9182] и L2VPN (L2VPN Network Model или L2NM) [RFC9291]. После этого контроллер получает данные о производительности сети или VPN, агрегируя (или фильтруя) данные нижележащих уровней, собранные счётчиками мониторинга на вовлечённых устройствах.

Данные о производительности сети или VPN могут приходить из разных источников. Например, данные мониторинга производительности по каналам базовых сетей можно собирать с помощью методов измерения производительности сети, таких как активные измерения в одном (OWAMP) [RFC4656] или двух (TWAMP) [RFC5357] направлениях, простой протокол двухсторонних активных измерений (Simple Two-way Active Measurement Protocol или STAMP) [RFC8762], измерение потерь и задержек при многопротокольной коммутации по меткам (Multiprotocol Label Switching или MPLS) [RFC6374], In situ OAM (IOAM) [RFC9197]. Данные мониторинга производительности сети, отражающие качество работы сети или службы VPN (например, производительность сети между источником и получателем или между сайтами VPN) могут быть обработаны и агрегированы с использованием, например, сведений из базы данных организации трафика (Traffic Engineering Database или TED) [RFC7471] [RFC8570] [RFC8571] или крупномасштабной измерительной платформы (Large-Scale Measurement Platform или LMAP) [RFC8194].

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

3.1. Сбор данных через механизм публикации и подписки

Некоторые приложения, такие как приложения гарантий обслуживания, которые должны поддерживать постоянное представление рабочих данных и состояния, могут применять модель подписки, заданную в [RFC8641], для предоставления конкретных сведений о производительности сети или службы VPN от источника данных. Например, можно узнать от изменении топологии сети или VPN с помощью уведомлений об изменениях [RFC8641]. Для динамических данных PM (например, маршруты VRF3, записи MAC4, метрика каналов и интерфейсов), могут быть заданы свои уведомления, позволяющие получить более полные данные. Могут быть заданы периодические обновления [RFC8641] для получения данных о производительности в реальном масштабе времени. Для контроллеров и устройств поддерживающих историю производительности в интервале времени, может быть организовано воспроизведение (replay) уведомлений (см. [RFC5277] или [RFC8639]). Можно задать уведомления о сигналах тревоги (alarm) [RFC8632] при выходе показателей производительности за определённые пределы.

Источник данных может использовать модель мониторинга производительности сети или службы VPN, заданную в этом документе, и модель данных YANG-Push [RFC8641] для описания конкретных данных телеметрии.

3.2. Сбор данных по запросу

При получении моментального снимка (snapshot) данных производительности от топологии сети или службы VPN приложение для обеспечения гарантий обслуживания может извлекать сведения с использованием модели PM для сети или службы по протоколу настройки сети (Network Configuration Protocol или NETCONF) [RFC6241] или RESTCONF [RFC8040]. Например, заданный идентификатор link-id для VPN может служить фильтров запроса RESTCONF GET для извлечения данных VPN PM по каналу.

4. Описание модели данных YANG

В этом документе задан модуль YANG ietf-network-vpn-pm, дополняющий модули ietf-network и ietf-network-topology.

4.1. Связи между уровнями топологии

В [RFC8345] задана модель данных YANG для топологии и описи сетей и служб. Топология сервиса, описанная в [RFC8345], включает абстрактную топологию служб выше базовой топологии уровней L1, L2 и L3. Эта топология службы имеет базовые элементы для узлов, каналов и точек завершения. Типовой пример топологии представлен на риснке 3 в [RFC8345] с двумя службами VPN в общей топологии L3. Топология каждой службы VPN отображается на подмножество узлов топологии L3.

На рисунке 2 показан пример иерархии топологий с сопоставлением топологии двух служб VPN и базовой сети L3.

                     VPN 1                       VPN 2
          +------------------------+   +------------------------+
         /                        /   /                        /
        / S1C_[VN3]..........    /   /                        /
       /         \          :   /   / S2A_[VN1]____[VN3]_S2B /
      /           \         :  /   /        *        *      /
     /             \        :............ * ....     *     /
    / S1B_[VN2]____[VN1]_S1A /   /       *     :     *    /
   +---------:-------:------+   +-------*------:-----*---+
             :        :      * * *  * *        :     *
             :         :   *                   :     *
   Сайт-1A   :  +-------:-*--------------------:-----*-----+ Сайт-1C
     [CE1]___:_/_______[N1]___________________[N2]___*____/__[CE3]
             :/       / / \             _____//      *   /
   [CE5]_____:_______/ /    \     _____/     /     *    /
 Сайт-2A    /:        /       \  /          /    *     /
           / :                [N5]         /   *      /
          /   :     /       __/ \__       /  *       /
         /     :   /    ___/       \__   / *        /
Сайт-1B /       : / ___/              \ /*         /  Сайт-2B
[CE2]__/________[N4]__________________[N3]________/____[CE4]
      /                                          /
     +------------------------------------------+
                                     Топология L3
N   Узел
VN  Узел VPN
S   Сайт
CE  Граничное устройство клиента
__  Канал внутри сетевого уровня
:   Сопоставление топологии службы VPN 1 и топологии L3
*   Сопоставление топологии службы VPN 2 и топологии L3

Рисунок 2. Пример сопоставления топологии между VPN и базовой сетью.


VPN 1

Топология этой службы поддерживает соединения «звезда» (Hub-and-Spoke) для «клиента 1», обеспечивающие доступ на трёх сайтах – 1A, 1B, 1C. Эти сайты подключены к узлам, отображённым на узлы 1 (N1), 2 (N2) и 4 (N4) в базовой сети L3. Сайт-1A играет роль концентратора (Hub), 1B и 1C настроены как лучи (Spoke).

VPN 2

Топология этой службы обеспечивает соединения «каждый с каждым» для «клиента 2», обеспечивающие доступ на двух сайтах 2A и 2B. Эти сайты соединены с узлами, которые отображаются на узлы 1 (N1) и 3 (N3) в базовой сети L3.

На основе ассоциация между топологией обеих VPN и топологией базовой сети модуль YANG для PM сетей и служб VPN извлекает сведения о производительности из базовой сети и служб VPN. Например, модуль может отслеживать статистику PM для каналов и статистику портов в базовой сети (сети L1, L2, L3, OSPF). Он может также предоставлять статистику VPN PM, которые можно разделить на PM для туннеля VPN и узлов доступа VPN PE (Рисунок 3).

          +-----------------------------------------------------+
          |                                                     |
          |                      Канал VPN2                     |
          |              |<-------------------->|               |
          |              |                      |               |
          |      VPN2+---+---+              +---+---+VPN2       |
          |       TP1| VN1   |  Туннель PM  |  VN3  |TP2        |
          |       ---+ PE A  |==============|  PE B +----       |
          |vpn-access+-------+              +-------+ vpn-access|
          |-interface|                              | -interface|
          |          |##############################|           |
          |          |inter-vpn-access-interface PM |           |
          |                                                     |
          +-----------------------------------------------------+
          |                                                     |
          |                                                     |
   +----+ |        TP+-----+ Канал +---+ Канал +-----+TP        | +----+
   | CE4+-+----------+ N1  +-------+-N2+-------+  N3 +----------+-+CE5 |
   +----+ |       1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2       | +----+
          |                                                     |
          |                                                     |
          +-----------------------------------------------------+
N   Узел
VN  Узел VPN
TP  Точка завершения
-   Канал

Рисунок 3. Пример VPN PM.


На рисунке 3 приведён пример VPN PM и двух методов измерения VPN PM, включающих туннель VPN и интерфейс между VPN. VPN PM может также предоставлять статистику для интерфейсов доступа VPN, числа текущих маршрутов VRF или записей L2VPN MAC на узле VPN.

4.2. Добавление мониторинга производительности на уровне сети

Описанный ниже модуль может служить для мониторинга производительности базовых сетей и служб VPN, которые будут отдельными записями в списке сетей [RFC8345]. Различия определяются присутствием контейнера service. differences are as follows:

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

  • Наличие контейнера указывает мониторинг производительности службы VPN, заданной листом service-type, например, L3VPN или VPLS. Значения взяты из [RFC9181]. Когда экземпляр топологии сети содержит L3VPN или иные типы сетей L2VPN, он представляет экземпляр VPN способный отслеживать производительность.

Дерево YANG на рисунке 4 является частью дерева ietf-network-vpn-pm и определяет указанные ниже атрибуты сетевого уровня.

vpn-id

Указывает идентификатор службы VPN, определённый в [RFC9181]. Этот идентификатор служит для сопоставления статуса производительности с конфигурацией сетевой службы.

vpn-service-topology

Указывает тип топологии службы VPN. Эта модель поддерживает варианты any-to-any (каждый с каждым), hub-spoke (где концентраторы могут обмениваться трафиком) и hub-spoke-disjoint (концентраторы не могут обмениваться трафиком), взятые из [RFC9181]. Эти типы топологии служб VPN можно использовать для описания взаимодействий между сайтами VPN.
   module: ietf-network-vpn-pm
     augment /nw:networks/nw:network/nw:network-types:
       +--rw service!
          +--rw service-type            identityref
          +--rw vpn-id?                 vpn-common:vpn-id
          +--rw vpn-service-topology?   identityref

Рисунок 4. Дерево YANG сетевого уровня.

4.3. Добавление мониторинга производительности на уровне узла

Дерево YANG на рисунке 5 показывает связанную с узлом часть дерева ietf-network-vpn-pm. Для мониторинга производительности модуль задаёт указанные ниже атрибуты.

node-type

Указывает тип устройства – PE, P, или ASBR5, как определено в [RFC4026] и [RFC4364], чтобы можно было сообщать метрику производительности между двумя любыми узлами определённого типа.

entry-summary

Список наборов параметров статистики IPv4, IPv6 и MAC. Подробная статистика задаётся отдельно.

Для топологии службы VPN модуль определяет ещё один атрибут.

role

Указывает роль в конкретной топологии службы VPN. Роли взяты из [RFC9181] (например, any-to-any-role, spoke-role, hub-role).
     augment /nw:networks/nw:network/nw:node:
       +--rw node-type?       identityref
       +--ro entry-summary
          +--ro ipv4-num
          |  +--ro maximum-routes?        uint32
          |  +--ro total-active-routes?   uint32
          +--ro ipv6-num
          |  +--ro maximum-routes?        uint32
          |  +--ro total-active-routes?   uint32
          +--ro mac-num
             +--ro maximum-mac-entries?        uint32
             +--ro total-active-mac-entries?   uint32
     augment /nw:networks/nw:network/nw:node:
       +--rw role?   identityref

Рисунок 5. Дерево YANG на уровне узла.

4.4. Добавление мониторинга производительности на уровне канала и TP

Дерево YANG на рисунке 6 показывает связанную с каналами и точками завершениячасть дерева ietf-network-vpn-pm.

Каналы делятся на 2 типа – топологические (определены в [RFC8345]) и абстрактные каналы VPN между PE (определены в этом модуле).

Данные производительности для канала – это набор счётчиков и датчиков, сообщающих состояние производительности. Все эти показатели определены как односторонние (unidirectional).

     augment /nw:networks/nw:network/nt:link:
       +--rw perf-mon
          +--rw low-percentile?            percentile
          +--rw intermediate-percentile?   percentile
          +--rw high-percentile?           percentile
          +--rw measurement-interval?      uint32
          +--ro pm* [pm-type]
          |  +--ro pm-type          identityref
          |  +--ro pm-attributes
          |     +--ro start-time?                     yang:date-and-time
          |     +--ro end-time?                       yang:date-and-time
          |     +--ro pm-source?                      identityref
          |     +--ro one-way-pm-statistics
          |     |  +--ro loss-statistics
          |     |  |  +--ro packet-loss-count?   yang:counter64
          |     |  |  +--ro loss-ratio?          percentage
          |     |  +--ro delay-statistics
          |     |  |  +--ro unit-value?                     identityref
          |     |  |  +--ro min-delay-value?                yang:gauge64
          |     |  |  +--ro max-delay-value?                yang:gauge64
          |     |  |  +--ro low-delay-percentile?           yang:gauge64
          |     |  |  +--ro intermediate-delay-percentile?  yang:gauge64
          |     |  |  +--ro high-delay-percentile?          yang:gauge64
          |     |  +--ro jitter-statistics
          |     |     +--ro unit-value?                     identityref
          |     |     +--ro min-jitter-value?               yang:gauge64
          |     |     +--ro max-jitter-value?               yang:gauge64
          |     |     +--ro low-jitter-percentile?          yang:gauge64
          |     |     +--ro intermediate-jitter-percentile? yang:gauge64
          |     |     +--ro high-jitter-percentile?         yang:gauge64
          |     +--ro one-way-pm-statistics-per-class* [class-id]
          |        +--ro class-id             string
          |        +--ro loss-statistics
          |        |  +--ro packet-loss-count?   yang:counter64
          |        |  +--ro loss-ratio?          percentage
          |        +--ro delay-statistics
          |        |  +--ro unit-value?                     identityref
          |        |  +--ro min-delay-value?                yang:gauge64
          |        |  +--ro max-delay-value?                yang:gauge64
          |        |  +--ro low-delay-percentile?           yang:gauge64
          |        |  +--ro intermediate-delay-percentile?  yang:gauge64
          |        |  +--ro high-delay-percentile?          yang:gauge64
          |        +--ro jitter-statistics
          |           +--ro unit-value?                     identityref
          |           +--ro min-jitter-value?               yang:gauge64
          |           +--ro max-jitter-value?               yang:gauge64
          |           +--ro low-jitter-percentile?          yang:gauge64
          |           +--ro intermediate-jitter-percentile? yang:gauge64
          |           +--ro high-jitter-percentile?         yang:gauge64
          +--rw vpn-pm-type
             +--rw inter-vpn-access-interface
             |  +--rw inter-vpn-access-interface?   empty
             +--rw vpn-tunnel!
                +--ro vpn-tunnel-type?   identityref
     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--ro pm-statistics
          +--ro last-updated?               yang:date-and-time
          +--ro inbound-octets?             yang:counter64
          +--ro inbound-unicast?            yang:counter64
          +--ro inbound-broadcast?          yang:counter64
          +--ro inbound-multicast?          yang:counter64
          +--ro inbound-discards?           yang:counter64
          +--ro inbound-errors?             yang:counter64
          +--ro inbound-unknown-protocol?   yang:counter64
          +--ro outbound-octets?            yang:counter64
          +--ro outbound-unicast?           yang:counter64
          +--ro outbound-broadcast?         yang:counter64
          +--ro outbound-multicast?         yang:counter64
          +--ro outbound-discards?          yang:counter64
          +--ro outbound-errors?            yang:counter64
          +--ro vpn-network-access* [network-access-id]
             +--ro network-access-id           vpn-common:vpn-id
             +--ro last-updated?               yang:date-and-time
             +--ro inbound-octets?             yang:counter64
             +--ro inbound-unicast?            yang:counter64
             +--ro inbound-broadcast?          yang:counter64
             +--ro inbound-multicast?          yang:counter64
             +--ro inbound-discards?           yang:counter64
             +--ro inbound-errors?             yang:counter64
             +--ro inbound-unknown-protocol?   yang:counter64
             +--ro outbound-octets?            yang:counter64
             +--ro outbound-unicast?           yang:counter64
             +--ro outbound-broadcast?         yang:counter64
             +--ro outbound-multicast?         yang:counter64
             +--ro outbound-discards?          yang:counter64
             +--ro outbound-errors?            yang:counter64

Рисунок 6. Ветви YANG для канала и точки завершения.

Для узлов данных link, указанных на рисунке 6, модуль YANG задаёт указанный ниже минимальный набор атрибутов производительности на уровне канала.

Параметры в процентилях

Модуль поддерживает указание параметров задержки и её вариаций в процентилях. Имеется три значения в процентилях для настройки разных уровней отчётности. Про умолчанию используется низкий (low, 10-й процентиль), средний (intermediate, 50-й процентиль) и высокий (high, 90-й процентиль). Настройка для процентиля значения 0.000 указывает, что клиент не заинтересован в получении соответствующего процентиля. Если такое значение задано для всех процентилей, для данного показателя не будут сообщаться узлы с процентилями (например, задержки и их вариации в одном направлении), а останутся лишь узлы пиковых и минимальных значений. Например, клиент может указать серверу, что он заинтересован в получении лишь высоких процентилей. Тогда для данного канала в заданные моменты start-time, end-time и measurement-interval будут сообщаться значения high-delay-percentile и high-jitter-percentile. Пример использования процентилей дап в Приложении A.3.

Интервал измерения (measurement-interval)

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

Время старта (start-time)

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

Время окончания (end-time)

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

Источник данных PM (pm-source)

Указывает источник данных мониторинга производительности, например, состояние канала BGP (BGP – Link State или BGP-LS) [RFC8571]. Может собираться статистика абстрактных каналов VPN на основе механизмов VPN OAM, например, механизмов OAM из [RFC9182] или Ethernet OAM [ITU-T-Y-1731] из [RFC9291]. Кроме того, данные могут быть основаны на механизмах OAM базовой технологии, например, OAM туннеля GRE.

Статистика потерь

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

Статистика задержек

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

Статистика вариаций задержки

Набор атрибутов статистики вариаций задержки пакетов IP в одном направлении [RFC3393], которые служат для измерения сквозных вариаций между сайтами VPN или любыми двумя узлами сети. Могут указываться пиковые и минимальные значения или значения процентилей.

Статистика PM по классам (one-way-pm-statistics-per-class)

Односторонняя статистика PM по классам содержит статистику измерений для топологии физических или абстрактных каналов между VPN PE я данными именами class-id. Список задаётся отдельно от one-way-pm-statistics, используемой для сбора базовых показателей для неуказанных class-id.

Тип VPN PM (vpn-pm-type)

Указывает тип мониторинга производительности VPN – inter-vpn-access-interface PM или vpn-tunnel PM, которые являются распространёнными для VPN. Тип inter-VPN-access-interface PM служит для мониторинга производительности логических соединений VPN «точка-точка» (point-to-point) между исходным и целевым интерфейсами доступа VPN. Тип vpn-tunnel PM служит для мониторинга производительности туннелей VPN. Тип inter-VPN-access-interface PM включает мониторинг PE-PE, поэтому обычно применяется лишь 1 из этих двух методов. Тип inter-VPN-access-interface определён как пустой лист, который не привязан к какому-либо конкретному интерфейсу доступа VPN. Исходный и целевой интерфейсы доступа VPN для измерения могут быть добавлены (augment) при необходимости.

Тип туннеля VPN (vpn-tunnel-type)

Указывает тип протокола абстрактного канала VPN, такой как GRE или IP-in-IP. Лист указывает идентификатор базового транспорта (underlay-transport) заданный в [RFC9181], который определяет транспортную технологию для передачи трафика службы VPN. В случае нескольких типов туннелей между одной парой узлов VPN может создаваться отдельный канал для каждого типа туннеля.

Для узлов данных termination-point, показанных на рисунке 6, модуль задаёт показанный ниже минимальный набор параметров статистики.

Время последнего обновления (last-updated)

Показывает дату и время последнего обновления счетчиков.

Входная статистика

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

Выходная статистика

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

Доступ в сеть VPN (vpn-network-access)

Список счётчиков доступа к сети VPN, определённых в L3NM [RFC9182] или L2NM [RFC9291]. При создании нескольких сетевых подключений VPN через один физический порт могут отслежтваться более детализированные показатели. Если точка TP связана лишь с одной VPN, этот список не требуется.

5. Модуль YANG для мониторинга производительности сетей и VPN

Модуль YANG ietf-network-vpn-pm использует определения типов из [RFC6991], [RFC8345], [RFC8532], [RFC9181].

   <CODE BEGINS> file "ietf-network-vpn-pm@2023-03-20.yang"
   module ietf-network-vpn-pm {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";
     prefix nvp;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-vpn-common {
       prefix vpn-common;
       reference
         "RFC 9181: A Common YANG Data Model for Layer 2 and
              Layer 3 VPNs";
     }
     import ietf-network {
       prefix nw;
       reference
         "RFC 8345: A YANG Data Model for Network
              Topologies, Section 6.1";
     }
     import ietf-network-topology {
       prefix nt;
       reference
         "RFC 8345: A YANG Data Model for Network
              Topologies, Section 6.2";
     }
     import ietf-lime-time-types {
       prefix lime;
       reference
         "RFC 8532: Generic YANG Data Model for the Management of
              Operations, Administration, and Maintenance (OAM)
              Protocols That Use Connectionless Communications";
     }

     organization
       "IETF OPSAWG (Operations and Management Area Working Group)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/opsawg/> 
        WG List:  <mailto:opsawg@ietf.org>

        Editor: Bo Wu
             <lana.wubo@huawei.com> 

        Editor: Mohamed Boucadair
             <mohamed.boucadair@orange.com> 

        Editor: Qin Wu
             <bill.wu@huawei.com> 

        Author: Oscar Gonzalez de Dios
             <oscar.gonzalezdedios@telefonica.com> 

        Author: Bin Wen
             <bin_wen@comcast.com>"; 
     description
       "Этот модуль YANG задаёт модель для мониторинга 
        производительности сети или службы VPN.

        Авторские права (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 9375, где правовые
        аспекты приведены более полно.";

     revision 2023-03-20 {
       description
         "Исходная версия.";
       reference
         "RFC 9375: A YANG Data Model for Network and VPN Service
              Performance Monitoring";
     }

     identity node-type {
       description
         "Базовый идентификатор для типа узла";
     }

     identity pe {
       base node-type;
       description
         "Граничное устройство провайдера (PE) - устройство или набор
          устройств на границе сети провайдера, обеспечивающих 
          функциональность, требуемую для взаимодействия с клиентом.";
     }

     identity p {
       base node-type;
       description
         "Маршрутизатор провайдера - маршрутизатор в ядре сети, не 
          имеющий интерфейсов для прямого подключения клиентов.";
     }

     identity asbr {
       base node-type;
       description
         "Граничный маршрутизатор автономной системы (ASBR).";
       reference
         "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)";
     }

     identity pm-source-type {
       description
         "Базовый идентификатор, из которого выводятся конкретные типы
          механизмов мониторинга производительности.";
     }

     identity pm-source-bgpls {
       base pm-source-type;
       description
         "Указывает BGP-LS как источник данных PM.";
       reference
         "RFC 8571: BGP - Link State (BGP-LS) Advertisement of
              IGP Traffic Engineering Performance Metric
              Extensions";
     }

     identity pm-source-owamp {
       base pm-source-type;
       description
         "Указывает протокол OWAMP как источник данных PM.";
       reference
         "RFC 4656: A One-way Active Measurement Protocol (OWAMP)";
     }

     identity pm-source-twamp {
       base pm-source-type;
       description
         "Указывает протокол TWAMP как источник данных PM.";
       reference
         "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)";
     }

     identity pm-source-stamp {
       base pm-source-type;
       description
         "Указывает протокол STAMP как источник данных PM.";
       reference
         "RFC 8762: Simple Two-Way Active Measurement Protocol";
     }

     identity pm-source-y-1731 {
       base pm-source-type;
       description
         "Указывает Ethernet OAM Y.1731 как источник данных PM.";
       reference
         "ITU-T Y.1731: Operations, administration and
                maintenance (OAM) functions and mechanisms
                for Ethernet-based networks";
     }

     identity pm-source-ioam {
       base pm-source-type;
       description
         "Указывает IOAM как источник данных PM.";
       reference
         "RFC 9197: Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)";
     }

     identity pm-type {
       description
         "<Базовый идентификатор для типа PM.";
     }

     identity pm-type-network-link {
       base pm-type;
       description
         "Указывает тип PM для канала в топологии сети.";
     }

     identity pm-type-vpn-inter-access {
       base pm-type;
       description
         "Указывает тип PM для логических соединений VPN «точка-точка»
          между исходным и целевым интерфейсами доступа VPN.";
     }

     identity pm-type-vpn-tunnel {
       base pm-type;
       description
         "Указывает тип PM для туннелей VPN.";
     }

     typedef percentage {
       type decimal64 {
         fraction-digits 5;
         range "0..100";
       }
       description
         "В процентах до 5 знаков после запятой.";
     }

     typedef percentile {
       type decimal64 {
         fraction-digits 3;
         range "0..100";
       }
       description
         "Процентиль - это значение от 0 до 100, имеющее до 3 знаков в
          дробной части, например, 10.000, 99.900, 99.990. Если для
          данного измерения односторонней задержки задан процентиль 
          95.000 и 95-й процентиль односторонней задержки составляет 2
          мсек, тогда 95 процентов значений выборки задержки будут иметь
          значение не больше 2 миллисекунд.";
     }

     grouping entry-summary {
       description
         "Сводная группировка записей, применяемая для дополнения 
          топологии сети.";
       container entry-summary {
         config false;
         description
           "Контейнер для сводки VPN или сети.";
         container ipv4-num {
           leaf maximum-routes {
             type uint32;
             description
               "Максимальное число маршрутов IPv4 для VPN или сети.";
           }
           leaf total-active-routes {
             type uint32;
             description
               "Общее число активных маршрутов IPv4 для VPN или сети.";
           }
           description
             "Параметры, относящиеся к IPv4.";
         }
         container ipv6-num {
           leaf maximum-routes {
             type uint32;
             description
               "Максимальное число маршрутов IPv6 для VPN или сети.";
           }
           leaf total-active-routes {
             type uint32;
             description
               "Общее число активных маршрутов IPv6 для VPN или сети.";
           }
           description
             "Параметры, относящиеся к IPv6.";
         }
         container mac-num {
           leaf maximum-mac-entries {
             type uint32;
             description
               "Максимальное число записей MAC для VPN или сети.";
           }
           leaf total-active-mac-entries {
             type uint32;
             description
               "Общее число активных записей MAC для VPN или сети.";
           }
           description
             "Статистика MAC.";
         }
       }
     }

     grouping link-loss-statistics {
       description
         "Группировка для статистики ошибок на канал.";
       container loss-statistics {
         description
           "Сводка потерь в одном направлении.";
         reference
           "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
            ITU-T Y.1731: Operations, administration and
                  maintenance (OAM) functions and mechanisms
                  for Ethernet-based networks";
         leaf packet-loss-count {
           type yang:counter64;
           description
             "Общее число потерянных пакетов.";
         }
         leaf loss-ratio {
           type percentage;
           description
             "Доля потерянных пакетов в процентах от числа переданных.";
         }
       }
     }

     grouping link-delay-statistics {
       description
         "Группировка для статистики задержки на канал.";
       container delay-statistics {
         description
           "Сводка задержки в одном направлении.";
         reference
           "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
            ITU-T Y.1731: Operations, administration and
                  maintenance (OAM) functions and mechanisms
                  for Ethernet-based networks";
         leaf unit-value {
           type identityref {
             base lime:time-unit-type;
           }
           default "lime:milliseconds";
           description
             "Единицы времени (возможны часы, минуты, секунды, 
              милли-, микро- и наносекунды).";
         }
         leaf min-delay-value {
           type yang:gauge64;
           description
             "Минимальная наблюдаемая односторонняя задержка.";
         }
         leaf max-delay-value {
           type yang:gauge64;
           description
             "Максимальная наблюдаемая односторонняя задержка.";
         }
         leaf low-delay-percentile {
           type yang:gauge64;
           description
             "Низкий процентиль наблюдаемой односторонней задержки
              для конкретного метода измерения.";
         }
         leaf intermediate-delay-percentile {
           type yang:gauge64;
           description
             "Средний процентиль наблюдаемой односторонней задержки
              для конкретного метода измерения.";
         }
         leaf high-delay-percentile {
           type yang:gauge64;
           description
             "Высокий процентиль наблюдаемой односторонней задержки
              для конкретного метода измерения.";
         }
       }
     }

     grouping link-jitter-statistics {
       description
         "Группировка для статистики вариаций задержки на канал.";
       container jitter-statistics {
         description
           "Сводка вариаций задержки в одном направлении.";
         reference
           "RFC 3393: IP Packet Delay Variation Metric
                for IP Performance Metrics (IPPM)
            RFC 4656: A One-way Active Measurement Protocol (OWAMP)
            ITU-T Y.1731: Operations, administration and
                  maintenance (OAM) functions and mechanisms
                  for Ethernet-based networks";
         leaf unit-value {
           type identityref {
             base lime:time-unit-type;
           }
           default "lime:milliseconds";
           description
             "Единицы времени (возможны часы, минуты, секунды, 
              милли-, микро- и наносекунды).";
         }
         leaf min-jitter-value {
           type yang:gauge64;
           description
             "Минимальные наблюдаемые вариации односторонней задержки.";
         }
         leaf max-jitter-value {
           type yang:gauge64;
           description
             "Максимальные наблюдаемые вариации односторонней задержки";
         }
         leaf low-jitter-percentile {
           type yang:gauge64;
           description
             "Низкий процентиль наблюдаемых вариаций односторонней 
              задержки.";
         }
         leaf intermediate-jitter-percentile {
           type yang:gauge64;
           description
             "Средний процентиль наблюдаемых вариаций односторонней 
              задержки.";
         }
         leaf high-jitter-percentile {
           type yang:gauge64;
           description
             "Высокий процентиль наблюдаемых вариаций односторонней 
              задержки.";
         }
       }
     }

     grouping tp-svc-telemetry {
       leaf last-updated {
         type yang:date-and-time;
         config false;
         description
           "Дата и время последнего обновления счетчиков.";
       }
       leaf inbound-octets {
         type yang:counter64;
         description
           "Общее число октетов, полученных интерфейсом, включая
            символы кадрирования.";
       }
       leaf inbound-unicast {
         type yang:counter64;
         description
           "Общее число входящих индивидуальных пакетов.";
       }
       leaf inbound-broadcast {
         type yang:counter64;
         description
           "Общее число входящих широковещательных пакетов.";
       }
       leaf inbound-multicast {
         type yang:counter64;
         description
           "Общее число входящих групповых пакетов.";
       }
       leaf inbound-discards {
         type yang:counter64;
         description
           "Число входящих пакетов, которые были отброшены, несмотря на
            отсутствие обнаруженных ошибок. Причинами отбрасывания могут
            быть освобождение буферного пространства, нехватка буферов
            и т. п.";
       }
       leaf inbound-errors {
         type yang:counter64;
         description
           "Общее число входящих пакетов с ошибками.";
       }
       leaf inbound-unknown-protocol {
         type yang:counter64;
         description
           "Чсило полученных интерфейсом пакетов, которые были отброшены 
            из-за неизвестного или не поддерживаемого протокола.";
       }
       leaf outbound-octets {
         type yang:counter64;
         description
           "Общее число октетов, переданных интерфейсом, включая
            символы кадрирования.";
       }
       leaf outbound-unicast {
         type yang:counter64;
         description
           "Общее число исходящих индивидуальных пакетов.";
       }
       leaf outbound-broadcast {
         type yang:counter64;
         description
           "Общее число исходящих широковещательных пакетов.";
       }
       leaf outbound-multicast {
         type yang:counter64;
         description
           "Общее число исходящих групповых пакетов.";
       }
       leaf outbound-discards {
         type yang:counter64;
         description
           "Число входящих пакетов, которые были отброшены, несмотря на
            отсутствие обнаруженных ошибок, препятствующих передача. 
            Причинами отбрасывания могут быть освобождение буферного 
            пространства, нехватка буферов и т. п.";
       }
       leaf outbound-errors {
         type yang:counter64;
         description
           "Общее число исходящих пакетов с ошибками.";
       }
       description
         "Группировка для телеметрии интерфейсов службы.";
     }

     augment "/nw:networks/nw:network/nw:network-types" {
       description
         "Определяет типы топологии службы.";
       container service {
         presence "Наличие контейнера указывает мониторинг 
                   производительности службы VPN, а отсутствие - 
                   мониторинг производительности сети.";
         description
           "Контейнер для службы VPN.";
         leaf service-type {
           type identityref {
             base vpn-common:service-type;
           }
           mandatory true;
           description
             "Указывает тип сервиса, например, L3VPN, VPLS.";
         }
         leaf vpn-id {
           type vpn-common:vpn-id;
           description
             "Идентификатор VPN.";
         }
         leaf vpn-service-topology {
           type identityref {
             base vpn-common:vpn-topology;
           }
           description
             "Топология службы VPN, например, hub-spoke, any-to-any,
              hub-spoke-disjoint.";
         }
       }
     }

     augment "/nw:networks/nw:network/nw:node" {
       description
         "Добавляет общие атрибуты для узла сети.";
       leaf node-type {
         type identityref {
           base node-type;
         }
         description
           "Тип узла, например, PE, P, ASBR.";
       }
       uses entry-summary;
     }

     augment "/nw:networks/nw:network/nw:node" {
       when '../nw:network-types/nvp:service' {
         description
           "Дополнение для PM службы VPN.";
       }
       description
         "Добавление атрибутов службы VPN узлу сети.";
       leaf role {
         type identityref {
           base vpn-common:role;
         }
         default "vpn-common:any-to-any-role";
         description
           "Роль узла в топологии службы VPN.";
       }
     }

     augment "/nw:networks/nw:network/nt:link" {
       description
         "Добавление атрибутов PM к каналу сетевой топологии.";
       container perf-mon {
         description
           "Контейнер для атрибутов PM.";
         leaf low-percentile {
           type percentile;
           default "10.000";
           description
             "Низкий процентиль для отчёта. Установка значения 0.000
              указывает, что клиент не заинтересован в получении.";
         }
         leaf intermediate-percentile {
           type percentile;
           default "50.000";
           description
             "Средний процентиль для отчёта. Установка значения 0.000
              указывает, что клиент не заинтересован в получении.";
         }
         leaf high-percentile {
           type percentile;
           default "95.000";
           description
             "Высокий процентиль для отчёта. Установка значения 0.000
              указывает, что клиент не заинтересован в получении.";
         }
         leaf measurement-interval {
           type uint32 {
             range "1..max";
           }
           units "seconds";
           default "60";
           description
             "Интервал измерений PM.";
         }
         list pm {
           key "pm-type";
           config false;
           description
             "Список PM по типам PM.";
           leaf pm-type {
             type identityref {
               base pm-type;
             }
             config false;
             description
               "Тип PM для измеренных атрибутов PM.";
           }
           container pm-attributes {
             description
               "Контейнер для атрибутов PM.";
             leaf start-time {
               type yang:date-and-time;
               config false;
               description
                 "Дата и время последнего начала измерения.";
             }
             leaf end-time {
               type yang:date-and-time;
               config false;
               description
                 "Дата и время последнего окончания измерения.";
             }
             leaf pm-source {
               type identityref {
                 base pm-source-type;
               }
               config false;
               description
                 "Инструмент OAM, используемый для сбора данных PM.";
             }
             container one-way-pm-statistics {
               config false;
               description
                 "Контейнер для атрибутов телеметрии канала.";
               uses link-loss-statistics;
               uses link-delay-statistics;
               uses link-jitter-statistics;
             }
             list one-way-pm-statistics-per-class {
               key "class-id";
               config false;
               description
                 "Список данных PM по классам обслуживания.";
               leaf class-id {
                 type string;
                 description
                   "Значение class-id служит для указания класса
                    обслужтвания. Эти идентификаторы находятся в
                    ведении локального администратора.";
               }
               uses link-loss-statistics;
               uses link-delay-statistics;
               uses link-jitter-statistics;
             }
           }
         }
       }
     }

     augment "/nw:networks/nw:network/nt:link/perf-mon" {
       when '../../nw:network-types/nvp:service' {
         description
           "Дополнение PM для службы VPN.";
       }
       description
         "Дополнение атрибутов PM службы VPN к каналу топологии сети.";
       container vpn-pm-type {
         description
           "Тип VPN PM логического одностороннего канала VPN 
            точка-точка.";
         container inter-vpn-access-interface {
           description
             "Указывает inter-vpn-access-interface PM, используемый для
              мониторинга производительности логических соединений VPN
              точка-точка между исходным и целевым интерфейсом доступа 
              VPN.";
           leaf inter-vpn-access-interface {
             type empty;
             description
               "Подстановка (placeholder) для inter-vpn-access-interface 
                PM, не связанного с конкретным интерфейсом доступа VPN.
                Исходный или целевой интерфейс доступ VPN можно
                добавить при необходимости.";
           }
         }
         container vpn-tunnel {
           presence "Включает PM для туннеля VPN.";
           description
             "Указывает PM туннеля VPN, используемый для мониторинга
              производительности туннелей VPN.";
           leaf vpn-tunnel-type {
             type identityref {
               base vpn-common:protocol-type;
             }
             config false;
             description
               "Указывает тип туннеля VPN, например, GRE, Geneve.";
           }
         }
       }
     }

     augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
       description
         "Дополняет точку завершения топологии сети атрибутами PM.";
       container pm-statistics {
         config false;
         description
           "Контейнер для атрибутов PM точки завершения.";
         uses tp-svc-telemetry;
       }
     }

     augment "/nw:networks/nw:network/nw:node"
           + "/nt:termination-point/pm-statistics" {
       when '../../../nw:network-types/nvp:service' {
         description
           "Дополнения для PM службы VPN.";
       }
       description
         "Дополняет точку завершения топологии сети атрибутами PM 
          для службы VPN.";
       list vpn-network-access {
         key "network-access-id";
         description
           "Список PM на основе доступа в сеть VPN.";
         leaf network-access-id {
           type vpn-common:vpn-id;
           description
             "Ссылка на идентификатор доступа в сеть VPN.";
         }
         uses tp-svc-telemetry;
       }
     }
   }
   <CODE ENDS>

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

Заданный здесь модуль YANG определяет схему данных, предназначенных для доступа через протоколы управления сетью, такие как NETCONF [RFC6241] и RESTCONF [RFC8040]. Нижним уровнем для NETCONF является уровень защищённого транспорта с обязательно для реализации поддержкой Secure Shell (SSH) [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].

Модель управления доступом к конфигурации сети (Network Configuration Access Control Model или NACM) [RFC8341] обеспечивает средства для предоставления доступа лишь определенным пользователям NETCONF или RESTCONF к заранее заданному набору содержимого и протокольных операций NETCONF или RESTCONF.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Такие операции записи могут вести к неполноте или неточности измерений, что может влиять на видимость и решения, принимаемые на основе этих сведений. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

Таблица 1. Возможные влияния записи в узлы.

Доступ

Узел

Возможное влияние

/nw:networks/nw:network/nw:network-types

write

service type

Отключение VPN PM

write

VPN identifier

Отключение VPN PM

write

VPN service topology

Сбор непригодных данных

/nw:networks/nw:network/nw:node

write

node type

Сбор непригодных данных

write

VPN topology role

Сбор непригодных данных

/nw:networks/nw:network/nw:link/nvp:perf-mon

write

percentile

Ритм передачи отчетов

write

measurement interval

Достоверность мониторинга

write

vpn-pm-type

Достоверность мониторинга

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

/nw:networks/nw:network/nw:node

Несанкционирование чтение этой ветви может раскрывать сведения рабочего состояния базовой сети или экземпляров VPN.

/nw:networks/nw:network/nt:link/nvp:perf-mon/nvp:one-way-pm-statistics

Несанкционирование чтение этой ветви может раскрывать сведения рабочего состояния каналов базовой сети или абстрактных каналов VPN.

/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-statistics

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

Этот модуль YANG не задаёт операций или действий, связанных с удалёнными вызовами процедур (Remote Procedure Call или RPC).

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

Агентство IANA зарегистрировало указанный ниже URI в субреестре ns реестра IETF XML Registry [RFC3688]

   URI:  urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

Агентство IANA зарегистрировало модуль YANG в субреестре YANG Module Names [RFC6020] реестра YANG Parameters

   Name:  ietf-network-vpn-pm
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
   Maintained by IANA:  N
   Prefix:  nvp
   Reference:  RFC 9375

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

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

[RFC3393] Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)”, RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4364] Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs)”, RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

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

[RFC6374] Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for MPLS Networks”, RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.

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

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

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

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, “A YANG Data Model for Network Topologies”, RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

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

[RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, “Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications”, RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.

[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, “BGP – Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions”, RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.

[RFC8641] Clemm, A. and E. Voit, “Subscription to YANG Notifications for Datastore Updates”, RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, “Simple Two-Way Active Measurement Protocol”, RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, “A Common YANG Data Model for Layer 2 and Layer 3 VPNs”, RFC 9181, DOI 10.17487/RFC9181, February 2022, <https://www.rfc-editor.org/info/rfc9181>.

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

[ITU-T-Y-1731] ITU-T, “Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks”, ITU-T Recommendation G.8013/Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.

[RFC4026] Andersson, L. and T. Madsen, “Provider Provisioned Virtual Private Network (VPN) Terminology”, RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.

[RFC5277] Chisholm, S. and H. Trevino, “NETCONF Event Notifications”, RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

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

[RFC8194] Schoenwaelder, J. and V. Bajpai, “A YANG Data Model for LMAP Measurement Agents”, RFC 8194, DOI 10.17487/RFC8194, August 2017, <https://www.rfc-editor.org/info/rfc8194>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, “Service Models Explained”, RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

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

[RFC8632] Vallin, S. and M. Bjorklund, “A YANG Data Model for Alarm Management”, RFC 8632, DOI 10.17487/RFC8632, September 2019, <https://www.rfc-editor.org/info/rfc8632>.

[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, “Subscription to YANG Notifications”, RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.

[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, “A Framework for Automating Service and Network Management with YANG”, RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/info/rfc8969>.

[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, “A YANG Network Data Model for Layer 3 VPNs”, RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/info/rfc9182>.

[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., “Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)”, RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.

[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, “A YANG Network Data Model for Layer 2 VPNs”, RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/info/rfc9291>.

[YANG-SAP] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, “A YANG Network Model for Service Attachment Points (SAPs)”, Work in Progress, Internet-Draft, draft-ietf-opsawg-sap-15, 18 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-15>.

Приложение A. Иллюстративные примеры

A.1. Пример подписки для производительности VPN

Пример на рисунке 7 показывает, как клиент подписывается на сведения мониторинга производительности между узлами (node-id) A и B в топологии сети L3. Клиента интересуют параметры мониторинга сквозных потерь.

   POST /restconf/operations/ietf-subscribed-notifications:establish-\6
                                      subscription
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-subscribed-notifications:input": {
       "stream-subtree-filter": {
         "ietf-network:networks": {
           "network": {
             "network-id": "example:VPN1",
             "ietf-network-vpn-pm:service": {
               "service-type": "ietf-vpn-common:l3vpn"
             },
             "node": [
               {
                 "node-id": "example:A",
                 "ietf-network-vpn-pm:node-type": "pe",
                 "termination-point": [
                   {
                     "tp-id": "example:1-0-1"
                   }
                 ]
               },
               {
                 "node-id": "example:B",
                 "ietf-network-vpn-pm:node-type": "pe",
                 "termination-point": [
                   {
                     "tp-id": "example:2-0-1"
                   }
                 ]
               }
             ],
             "ietf-network-topology:link": [
               {
                 "link-id": "example:A-B",
                 "source": {
                   "source-node": "example:A"
                 },
                 "destination": {
                   "dest-node": "example:B"
                 },
                 "ietf-network-vpn-pm:perf-mon": {
                   "pm": [
                     {
                       "pm-type": "pm-type-vpn-tunnel",
                       "pm-attributes": {
                         "one-way-pm-statistics": {
                           "loss-statistics": {
                             "packet-loss-count": {}
                           }
                         }
                       }
                     }
                   ],
                   "vpn-pm-type": {
                     "vpn-tunnel": {
                       "vpn-tunnel-type": "ietf-vpn-common:gre"
                     }
                   }
                 }
               }
             ]
           }
         },
         "ietf-yang-push:periodic": {
           "period": "500"
         }
       }
     }
   }

Рисунок 7. Пример извлечения Pub/Sub.

A.2. Пример «снимка» производительности VPN

Пример на рисунке 8 показывает тело сообщения VPN PM с запросом RESTCONF для извлечения данных производительности на канале и точке завершения TP, относящимся к VPN1.

   {
     "ietf-network:networks": {
       "network": {
         "network-id": "example:VPN1",
         "node": [
           {
             "node-id": "example:A",
             "ietf-network-vpn-pm:node-type": "pe",
             "termination-point": [
               {
                 "tp-id": "example:1-0-1",
                 "ietf-network-vpn-pm:pm-statistics": {
                   "inbound-octets": "100",
                   "outbound-octets": "150"
                 }
               }
             ]
           },
           {
             "node-id": "example:B",
             "ietf-network-vpn-pm:node-type": "pe",
             "termination-point": [
               {
                 "tp-id": "example:2-0-1",
                 "ietf-network-vpn-pm:pm-statistics": {
                   "inbound-octets": "150",
                   "outbound-octets": "100"
                 }
               }
             ]
           }
         ],
         "ietf-network-topology:link": [
           {
             "link-id": "example:A-B",
             "source": {
               "source-node": "example:A"
             },
             "destination": {
               "dest-node": "example:B"
             },
             "ietf-network-pm:perf-mon": {
               "pm": [
                 {
                   "pm-type": "pm-type-vpn-tunnel",
                   "pm-attributes": {
                     "one-way-pm-statistics": {
                       "loss-statistics": {
                         "packet-loss-count": "120"
                       }
                     }
                   }
                 }
               ],
               "vpn-pm-type": {
                 "vpn-tunnel": {
                   "vpn-tunnel-type": "ietf-vpn-common:gre"
                 }
               }
             }
           }
         ]
       }
     }
   }

Рисунок 8. Пример VPN PM.

A.3. Пример мониторинга процентилей

Это пример данных измерения в процентилях, которые могут быть возвращаны для канала example:A-B между example:A и example:B.

   {
     "ietf-network-topology:link": [
       {
         "link-id": "example:A-B",
         "source": {
           "source-node": "example:A"
         },
         "destination": {
           "dest-node": "example:B"
         },
         "ietf-network-vpn-pm:perf-mon": {
           "low-percentile": "20.000",
           "intermediate-percentile": "50.000",
           "high-percentile": "90.000",
           "pm": [
             {
               "pm-type": "pm-type-vpn-inter-access",
               "pm-attributes": {
                 "one-way-pm-statistics": {
                   "delay-statistics": {
                     "unit-value": "ietf-lime-time-types:milliseconds",
                     "min-delay-value": "43",
                     "max-delay-value": "99",
                     "low-delay-percentile": "64",
                     "intermediate-delay-percentile": "77",
                     "high-delay-percentile": "98"
                   }
                 }
               }
             }
           ],
           "vpn-pm-type": {
             "inter-vpn-access-interface": {
               "inter-vpn-access-interface": [null]
             }
           }
         }
       }
     ]
   }

Рисунок 9. Пример VPN PM со значениями процентилей.

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

Спасибо Joe Clarke, Adrian Farrel, Tom Petch, Greg Mirsky, Roque Gagliano, Erez Segev, Dhruv Dhody за рецензии и важный вклад в этот документ.

Эта работа частично поддерживалась Европейской комиссией в рамках проекта Horizon 2020 по обеспечения защищенного автономного управления трафиком для Tera-потоков SDN (Teraflow), грант № 101015857.

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

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

Michale Wang
Huawei
Email: wangzitao@huawei.com
 
Roni Even
Huawei
Email: ron.even.tlv@gmail.com
 
Change Liu
China Unicom
Email: liuc131@chinaunicom.cn
 
Honglei Xu
China Telecom
Email: xuhl6@chinatelecom.cn

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

Bo Wu (editor)
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: lana.wubo@huawei.com
 
Qin Wu (editor)
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
 
Mohamed Boucadair (editor)
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
 
Oscar Gonzalez de Dios
Telefonica
Madrid
Spain
Email: oscar.gonzalezdedios@telefonica.com
 
Bin Wen
Comcast
Email: bin_wen@comcast.com

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

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

nmalykh@protokols.ru


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

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

3VPN Routing and Forwarding – маршрутизация и пересылка VPN.

4Media Access Control – управление доступом к среде передачи.

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

6Строка разделена символом \ в соответствии с RFC 8792.

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

RFC 9402 Concat Notation

Independent Submission                                       M. Basaglia
Request for Comments: 9402                                              
Category: Informational                                      J. Bernards
ISSN: 2070-1721                                                         
                                                                 J. Maas
                                                            1 April 2023

Concat Notation

Нотация Concat

PDF

Аннотация

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

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

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

Это независимый вклад в серию RFC, не связанный с каким-либо потоком RFC. Редактор RFC решил опубликовать документ по своему усмотрению и не делает заявлений о его ценности для реализации или внедрения. Документы, одобренные для публикации редактором RFC Editor не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение

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

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

Описанный в документе язык нотации основан на текстовом представлении и ограничивается кодировкой символов US-ASCII [RFC0020], что позволяет передавать связанные с котами материалы в средах с ограниченными возможностями.

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

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

2. Определения

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

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

Subject – субъект, предмет

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

Cat – кот1

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

Container

Термином «контейнер» в этом документе обозначаются неодушевлённые объекты, в которых может размешаться 1 или несколько котов. Чаще всего это картонные коробки, но возможны и иные варианты контейнеров.

2.2. Грамматика

Грамматика языка определена с использованием нотации ABNF [RFC5234].

   SEQUENCE  =  POSITION / POSITION "=>" SEQUENCE
   POSITION  =  ADJACENT
   ADJACENT  =  OVER / ADJACENT "+" OVER
   OVER      =  MULTIPLE / MULTIPLE "/" POSITION
   MULTIPLE  =  CONCAT / NUMBER [ "*" ] MULTIPLE / NUMBER "/" MULTIPLE
   CONCAT    =  SUBJECT [ NUMBER ] / [ PARTIAL ] CONTAINER [ PARTIAL ]
   CONTAINER =  "[" OPT-POS "]" / "(" OPT-POS ")"
   CONTAINER =/ "{" OPT-POS "}" / "<" OPT-POS ">"
   OPT-POS   =  [ POSITION ]
   SUBJECT   =  CAT / 1*ALPHA / "@"
   CAT       =  "cat" / PARTIAL
   PARTIAL   =  "c" / "a" / "t" / "ca" / "at"
   ALPHA     =   %x41-5A / %x61-7A
   NUMBER    =  1*DIGIT
   DIGIT     =  "0" / "1" / "2" / "3" / "4"
   DIGIT     =/ "5" / "6" / "7" / "8" / "9"

3. Элементы

3.1. Субъекты

3.1.1. Коты

Стандартным обозначением кота является слово «кот».

3.1.2. Частичные коты

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

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

Обозначения частичных котов приведены ниже.

   c - голова кота
   a - тело кота
   t - хвост кота
   ca - голова и тело кота
   at - тело и хвост кота.

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

3.1.3. Другие животные

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

3.1.4. Клубки ниток

Клубки ниток (yarn) следует обозначать символом @.

3.2. Контейнеры

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

  • Квадратные скобки [] представляют коробки и другие контейнеры с прямоугольным входным отверстием.

  • Круглые скобки () представляют контейнеры с круглым отверстием или формой.

  • Для представления контейнеров, не имеющих фиксированной формы, нужно применять фигурные скобки {}.

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

3.3. Позиционирование

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

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

3.3.1. Горизонтальная позиция

Для представления расположенных рядом субъектов или контейнеров применяется символ +.

3.3.2. Вертикальная позиция

Для представления субъекта, расположенного над или под другим должен применяться оператор /.

3.3.3. Множество повторяющихся объектов

При повторении нескольких объектов или конфигураций можно применять сокращённую нотацию.

Горизонтальное позиционирование представляется числом, за которым может следовать символ * и повторяющаяся аннотация.

При вертикальном позиционировании повторяющиеся объекты указываются числом, за которым следует символ / и повторяющаяся аннотация.

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

3.4. Изменения с течением времени

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

3.4.1. Устранение неоднозначностей

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

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

4. Применение других языков

Слово кот (cat) является английским и предназначено для передачи нотации Concat лишь с использованием кодировки US-ASCII [RFC0020].

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

Нестандартные слова для котов не следует применять, пока все участники применения нотации Concat не согласовали кодировку символов и язык до передачи аннотаций.

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

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

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

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

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

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

[RFC0020] Cerf, V., “ASCII format for network interchange”, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

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

[RFC5234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

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

Приложение A. Примеры

В этом приложении представлены некоторые примеры нотации Concat.

[cat]

Рисунок 1. Кот в коробке.

[cat] + cat

Рисунок 2. Кот в коробке рядом с котом не в коробке.

cat / [cat]

Рисунок 3. Кот поверх коробки с другим котом.

[c]at

Рисунок 4. Кот с головой в коробке.

3 * cat

Рисунок 5. 3 кота бок о бок.

3 / cat

Рисунок 6. 3 кота каждый поверх другого кота.

cat + cat / [cat]

Рисунок 7. Кот рядом с коробкой, на которой и внутри которой другие коты.

<cat + cat> / [cat]

Рисунок 8. 2 кота на коробке, в которой другой кот.

cat1 + [cat2] => cat2 + [cat1]

Рисунок 9. Коты внутри и вне коробки меняются местами (Swap)

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

Mattia Basaglia
Email: glax@dragon.best
URI: https://dragon.best/
 
Joep Bernards
Email: joep@duali.xyz
 
Joost Maas
Email: J.f.w.maas@tue.nl

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

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

nmalykh@protokols.ru

1Термин «кот» в этом документе можно заменить термином «кошка» на усмотрение читателя, хотя некоторые детали поведения упомянутых существ могут существенно различаться. Прим. перев.

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

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

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

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

3. Субкод BFD Cease NOTIFICATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Адрес автора

Jeffrey Haas
Juniper Networks
Email: jhaas@juniper.net

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

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

nmalykh@protokols.ru


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

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

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

RFC 9340 Architectural Principles for a Quantum Internet

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

Architectural Principles for a Quantum Internet

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

2.2. Кубит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

IN

OUT

00

00

01

01

10

11

11

10

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1. Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2. Пары Белла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В источнике

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.3.1. Очистка

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.4. Доставка

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

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

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

5.1. Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.2. Скорость

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

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

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

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

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

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

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

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

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

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

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

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

6.1. Цели Quantum Internet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nmalykh@protokols.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC 9371 Registration Procedures for Private Enterprise Numbers (PENs)

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

Registration Procedures for Private Enterprise Numbers (PENs)

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nmalykh@protokols.ru

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

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

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

RFC 9350 IGP Flexible Algorithm

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

IGP Flexible Algorithm

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

Flexible Algorithm Definition (FAD)

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

Flex-Algorithm

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

Flexible Algorithm Participation

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

IGP Algorithm

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

ABR

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

ASBR

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

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

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

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

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

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

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

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

5.1. IS-IS FAD Sub-TLV

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

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

Type

26

Length

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

Flex-Algorithm

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

Metric-Type

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

0

Метрика IGP

1

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

2

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

Calc-Type

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

Priority

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

Sub-TLVs

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

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

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

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

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

5.2. OSPF FAD TLV

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

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

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

Type

16

Length

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

Flex-Algorithm

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

Metric-Type

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

0

Метрика IGP

1

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

2

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

Calc-Type

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

Priority

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

Sub-TLVs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Type

1

Length

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

Extended Administrative Group

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

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

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

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

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

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

Type

2

Length

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

Extended Administrative Group

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

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

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

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

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

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

Type

3

Length

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

Extended Administrative Group

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

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

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

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

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

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

Type

4

Length

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

Flags

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

M

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

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

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

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

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

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

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

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

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

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

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

Type

5

Length

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

Shared Risk Link Group Value

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

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

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

7. Sub-TLV для OSPF FAD TLV

7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV

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

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

Type

1

Length

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

Extended Administrative Group

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

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

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

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

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

Type

2

Length

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

Extended Administrative Group

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

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

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

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

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

Type

3

Length

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

Extended Administrative Group

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

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

7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV

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

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

Type

4

Length

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

Flags

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

M

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

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

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

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

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

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

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

7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV

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

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

Type

5

Length

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

Shared Risk Link Group Value

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

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

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

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

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

Type

6

Length

5 октетов

Flex-Algorithm

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

Metric

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

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

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

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

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

9. OSPF Flexible Algorithm Prefix Metric Sub-TLV

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

  • OSPFv2 Extended Prefix TLV [RFC7684];

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

    • Inter-Area Prefix TLV;

    • External-Prefix TLV.

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

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

Type

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

Length

8 октетов.

Flex-Algorithm

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

Flags

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

E

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

Биты 1 – 7

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

Reserved

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

Metric

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

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

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

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

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

10.1. OSPFv2 Extended Inter-Area ASBR LSA

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

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

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

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

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

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

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

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

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

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

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

10.1.1. OSPFv2 Extended Inter-Area ASBR TLV

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

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

Type

1

Length

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

ASBR Router ID

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

Sub-TLVs

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

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

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

10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV

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

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

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

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

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

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

Type

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

Length

8 октетов.

Flex-Algorithm

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

Reserved

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

Metric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определён бит идентификатора приложения (Application Identifier Bit), указывающий, что анонс ASLA связан с приложением Flex-Algorithm. Этот бит устанавливается в маске стандартных битов приложения (Standard Application Bit Mask или SABM), определённой в [RFC8919] и [RFC8920]:

   Bit 3:  Flexible Algorithm (X-bit)

Анонсы ASLA Admin Group для использования гибким алгоритмом могут использовать кодирование Administrative Group или Extended Administrative Group.

Получатель, поддерживающий эту спецификацию, должен воспринимать ASLA Administrative Group и Extended Administrative Group TLV, как указано в [RFC8919] или [RFC8920]. В случае IS-IS при установленном флаге L в анонсе ASLA (см. параграф 4.2 с [RFC8919] получатель должен быть способен воспринимать Administrative Group TLV, заданные в [RFC5305], и Extended Administrative Group TLV, заданные [RFC7308].

13. Расчёт путей по гибкому алгоритму

Маршрутизатор должен быть настроен на участие в данном Flex-Algorithm и должен выбрать FAD на основе правил, заданных в параграфе 5.3. Базовая обработка FAD TLV, прежде чем он сможет рассчитывать пути по данному Flex-Algorithm.

При вычислении пути по гибкому алгоритму не применяется проверки двухсторонней связности, но при расчёте применяется результат независимой от Flex-Algorithm проверки двухсторонней связности.

Как указано в разделе 11, участие в любом конкретном Flex-Algorithm должно анонсироваться по плоскостям данных. Расчёт путей по любому конкретному гибкому алгоритму зависит от плоскости данных. Несколько плоскостей данных могут одновременно применять один гибкий алгоритм и FAD для него. Трафик каждой плоскости данных будет пересылаться на основе записей пересылки для этой конкретной плоскости данных. Определение FAD не зависит от плоскости данных и применяется всеми плоскостями данных Flex-Algorithm.

Обработка плоскостями данных узлов, не участвующих в гибком алгоритме, зависит от конкретной плоскости данных. Если плоскость данных желает при расчёте пути Flex-Algorithm учитывать лишь участвующие в алгоритме узлы, все узлы, которые не анонсируют своего участия в данном Flex-Algorithm для этой плоскости данных, должны вырезаться из топологии. Маршрутизация SR, включая SR-MPLS и SRv6, является плоскостью данных, которая должна применять такое вырезание при расчёте путей Flex-Algorithm.

При расчёте пути для данного Flex-Algorithm должны использоваться значения metric-type и calculation-type из FAD (5. Анонсирование определения гибкого алгоритма).

FAD может включать различные правила включения и исключения, а для указания конкретного бита в Admin Group или Extended Admin Group применяется термин color (цвет).

Для всех каналов топологии должны применяться указанные ниже правила (в приведённом порядке) вырезания каналов из топологии при расчётах Flex-Algorithm.

  1. Проверяется наличие правил исключения Administrative Group в FAD. Если такие правила имеются, проверяется, не установлен ли для канала цвет, являющийся частью правила, и при обнаружении такого цвета канал должен исключаться из расчёта.

  2. Проверяется наличие правил исключения SRLG в FAD. Если такие правила имеются, проверяется, входит ли канал в исключаемую SRLG, и при обнаружении вхождения канал должен исключаться из расчёта.

  3. Проверяется наличие правил включения любой (include-any) Administrative Group в FAD. Если такие правила имеются, проверяется, установлен ли для канала цвет, являющийся частью правила, и при отсутствии такого цвета канал должен исключаться из расчёта.

  4. Проверяется наличие правил включения всех (include-all) Administrative Group в FAD. Если такие правила имеются, проверяется, установлены ли для канала все цвета, являющиеся частью правила, и если не установлены все эти цвета, канал должен исключаться из расчёта.

  5. Если в FAD применяется что-либо, отличное от метрики IGP (5. Анонсирование определения гибкого алгоритма), и такая метрика не анонсируется для конкретного канала в топологию, где выполняется расчёт, такой канал должен исключаться из расчёта. Метрику со значением 0 недопустимо учитывать в этом случае.

13.1. Множество областей и доменов

Любой расчёт дерева кратчайших путей IGP (Shortest Path Tree) ограничен одной областью. Это относится и к расчётам Flex-Algorithm. С учётом того, что рассчитывающий маршрутизатор не видит топологии следующих областей или домена, связанный с Flex-Algorithm путь к префиксу, проходящий через разные области или домены, будет рассчитываться лишь для локальной области. Выходной маршрутизатор L1/L2 (ABR в OSPF) или ASBR для разных доменов будет выбираться на основе лучшего пути для данного Flex-Algorithm в локальной области и такой выходной маршрутизатор ABR или ASBR будет отвечать за расчёт лучшего пути Flex-Algorithm через следующую область или домен. Это может привести к созданию пути, который будет неоптимальным из-за ограничений Flex-Algorithm. Если ABR или ASBR не имеет доступа к префиксу для данного Flex-Algorithm в следующей области или домене, трафик может отбрасываться таким ABR/ASBR.

Для расчёта оптимального сквозного пути через несколько областей или доменов для любого Flex-Algorithm в разделах 8 и 9 определена метрика префикса гибкого алгоритма (FAPM). При расчёте внешних маршрутов для префиксов от ASBR в удалённых областях OSPF в параграфе 10.2 определена метрика FAAM для ABR, указывающая доступность ASBR вместе с метрикой для конкретного Flex-Algorithm.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, маршрутизатор ABR или ASBR должен включать FAPM (разделы 8 и 9) при анонсировании префикса, доступного в данном Flex-Algorithm между областями или доменами. Такая метрика будет совпадать с метрикой для достижения префикса в исходной области или домене для этого Flex-Algorithm. Это похоже на задание метрики при анонсировании между областями или доменами метрики для принятого по умолчанию алгоритма. Когда префикс недоступен в исходной области или домене в конкретном Flex-Algorithm, маршрутизатору ABR или ASBR недопустимо включать FAPM для Flex-Algorithm при анонсировании префикса между областями или доменами.

Если определение FAD, выбранное на основе правил из параграфа 5.3, включает флаг M, метрика FAPM должна применяться при расчёте доступности внешнего или междоменного префикса. Если FAPM для Flex-Algorithm не включается в анонс доступности межобластного или внешнего префикса, такой префикс должен считаться недоступным в этом Flex-Algorithm. В случае OSPF для ASBR при отсутствии FAAM в анонсе локальных ABR маршрутизатор ASBR должен считаться недоступным для этого Flex-Algorithm и анонсы внешних префиксов от такого ASBR не учитываются в данном Flex-Algorithm.

Метрику префикса Flex-Algorithm и метрику OSPF Flex-Algorithm ASBR недопустимо применять в расчёте Flex-Algorithm, если выбранное на основе правил параграфа 5.3 определение FAD не включает флаг M, описанный в параграфах 6.4 и 7.4.

Если для случая OSPF при расчёте внешних маршрутов в Flex-Algorithm выигрышный FAD включает флаг M и анонсирующий ASBR находится в удалённой области, метрика будет суммой указнных ниже значений:

  • метрика FAPM для Flex-Algorithm, анонсированная ASBR с внешним маршрутом;

  • метрика доступа к ASBR для Flex-Algorithm от локального ABR, т. е. метрика FAAM для этого Flex-Algorithm, анонсированная ABR в локальной области этого ASBR;

  • зависимая от Flex-Algorithm метрика для доступа к локальному ABR.

По своей природе это похоже на расчёт метрики для маршрутов, полученных от удалённых ASBR в принятом по умолчанию алгоритме с использованием OSPFv2 Type 4 ASBR summary-LSA и OSPFv3 Inter-Area-Router-LSA.

Если определение FAD, выбранное на основе правил из параграфа 5.3, не включает флаг M, для расчёта маршрутов Flex-Algorithm должна применяться метрика IGP, связанная с достижимостью префикса, используемая базовыми протоколами IS-IS и OSPF. При расчёте внешних маршрутов в OSPF достижимость ASBR определяется на основе OSPFv2 Type 4 summary-LSA и OSFPv3 Inter-Area-Router-LSA.

Использовать Flex-Algorithm для достижимости префиксов между областями или доменами при сброшенном флаге M не рекомендуется. Причина заключается в том, что без явного анонса метрики префикса Flex-Algorithm (и анонса метрики Flex-Algorithm ASBR при расчёте внешних маршрутов OSPF) невозможно сделать вывод о доступности ABR или ASBR для межсетевого или междоменного префикса в следующей области или домене для данного Flex-Algorithm. Передача трафика Flex-Algorithm для такого префикса в сторону ABR или ASBR может привести к петле или постоянному отбрасыванию трафика.

В процессе расчёта маршрутов связанная с Flex-Algorithm метрика может превысить максимальное значение, которое может быть выражено 32-битовым числом без знака. В таких случаях при расчёте и в анонсах должно приниматься значение 0xFFFFFFFF.

FAPM недопустимо анонсировать с маршрутами IS-IS L1 или L2 внутри области, OSPFv2 или OSPFv3 внутри области. Если FAPM анонсируется с маршрутами этих типов, такая метрика должна игнорироваться при расчёте достижимости префиксов.

Флаг M в FAD не применим к префиксам, анонсируемым как локаторы SRv6. IS-IS SRv6 Locator TLV [RFC9352] включает поля Algorithm и Metric. При анонсировании SRv6 Locator между областями или доменами должно применяться поле Metric в Locator TLV для IS-IS независимо от флага M в анонсе FAD.

Анонсы внешних префиксов OSPF и NSSA могут включать ненулевой адрес пересылки в анонсах префиксов базового протокола. В таком случае связанная с Flex-Algorithm достижимость внешнего префикса определяется связанной с Flex-Algorithm достижимостью адреса пересылки.

В OSPF процедуры преобразования анонсов внешних префиксов NSSA в анонсы внешних префиксов, выполняемые NSSA ABR [RFC3101], не зависят от Flex-Algorithm. Транслятор NSSA должен включать OSPF FAPM sub-TLV для всех Flex-Algorithm, которые были в исходном анонсе внешнего префикса NSSA от NSSA ASBR в преобразованный анонс внешнего префикса независимо от его участия в этих Flex-Algorithm или доступности NSSA ASBR в них.

Область может быть разделена с точки зрения Flex-Algorithm из-за ограничений и/или метрики, применяемых в ней, с сохранением неразрывности в базовом алгоритме. В таких случаях некоторые адресаты внутри разделённой области могут стать недоступными в этом Flex-Algorithm и не смогут использовать межобластной путь. Это является следствием того, что анонсы доступности межобластных префиксов станут недоступными для внутренних получателей этой области. Рекомендуется минимизировать риск такого разделения за счёт достаточной избыточности внутри области для каждого применяемого Flex-Algorithm.

14. Flex-Algorithm и плоскость пересылки

В этом разделе описано использование путей Flex-Algorithm для пересылки.

14.1. Пересылка MPLS SR для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SR MPLS.

Анонсы Prefix-SID включают значение SR-Algorithm и поэтому связаны с ним. Prefix-SID также связаны с конкретной топологией, которая наследуется от связанного анонса достижимости префикса. Когда анонсированное значение алгоритма является значением Flex-Algorithm, Prefix-SID связывается с путями, рассчитанными по этому Flex-Algorithm в соответствующей топологии.

Путь Flex-Algorithm должен быть установлен в плоскости пересылки MPLS с использования метки MPLS, соответствующей Prefix-SID, анонсированному для этого Flex-Algorithm. Если Prefix-SID для данного Flex-Algorithm неизвестен, соответствующий Flex-Algorithm путь не может быть установлен в плоскости пересылки MPLS.

Трафик, который предполагается маршрутизировать по путям Flex-Algorithm, должен отбрасываться, если такие пути недоступны.

Дополнительные пути без петель (Loop Free Alternate или LFA) paths ([RFC6571] и его варианты) для данного Flex-Algorithm должны рассчитываться с теми же ограничениями, какие применяются для расчёта основных путей с этим Flex-Algorithm. Пути LFA должны использовать только Prefix-SID, анонсированные специально для данного алгоритма. Путям LFA недопустимо использовать Adjacency SID, относящийся к каналу, который был исключён из расчётов Flex-Algorithm.

Если применяется защита LFA для пути данного алгоритма Flex-Algorithm, всем маршрутизаторам области, участвующим в этом алгоритме, следует анонсировать хотя бы один, связанный с Flex-Algorithm, идентификатор Node-SID. Эти Node-SID служат для направления трафика по резервному пути, рассчитанному LFA.

14.2. Пересылка SRv6 для Flex-Algorithm

В этом параграфе описано использование путей Flex-Algorithm для пересылки SRv6.

В SRv6 узлу предоставляется конкретный (топология, алгоритм) локатор для каждой пары топология-алгоритм, поддерживаемой этим узлом. Каждый локатор является агрегатным префиксом для всех SID с совпадающей топологией и алгоритмом, предоставляемых на этом узле.

Анонс локатора SRv6 в IS-IS [RFC9352] включает значение MTID (Multi-Topology Identifier), связывающее локатор с конкретной топологией. Кроме того, анонс SRv6 включает значение алгоритма, явно связывающее локатор с конкретным алгоритмом. Когда значение алгоритма анонсируется с локатором, представляющим Flex-Algorithm, пути к префиксу локатора должны рассчитываться с использованием указанного Flex-Algorithm в связанной топологии.

Записи пересылки для префикса локатора, анонсированного в IS-IS, должны быть установлены в плоскости пересылки принимающих маршрутизаторов с поддержкой SRv6, когда в них участвует соответствующая топология/алгоритм. Записи пересылки для локаторов, связанных с Flex-Algorithm, в которых узел не участвует, недопустимо устанавливать в плоскости пересылки.

Когда локатор связан с Flex-Algorithm, пути LFA к префиксу локатора должны рассчитываться с применением такого Flex-Algorithm в связанной топологии, чтобы гарантировать соблюдение тех же ограничений, что и в расчёте основного пути. Пути LFA должны использовать лишь SRv6 SID, анонсированные специально для данного Flex-Algorithm.

Если LFA применяется для защиты локаторов, связанных с данным Flex-Algorithm, всем маршрутизаторам области, участвующим в этом Flex-Algorithm, следует анонсировать хотя бы один связанный с Flex-Algorithm локатор и END SID на узел, а также один END.X SID для каждого канала, не исключённого из расчёта с этим Flex-Algorithm. Эти локаторы и SID применяются для направления трафика по резервному пути LFA.

14.3. Пересылка для Flex-Algorithm в других плоскостях данных

Любая плоскость данных, желающая применять связанную с Flex-Algorithm пересылку, должна установить ту или иную форму связанных с Flex-Algorithm записей пересылки. Зависящая от плоскости данных пересылка для Flex-Algorithm должна быть определена для каждой плоскости данных, но это определение выходит за рамки документа.

15. Эксплуатационные соображения

15.1. Работа в нескольких областях

Расчёты Flex-Algorithm и определение FAD действуют в рамках области. В IS-IS элемент Router Capability TLV, где анонсируется FAD sub-TLV, должен иметь сброшенный бит S, чтобы предотвратить лавинную рассылку за пределы уровня, где анонс создан. Хотя в OSPF можно лавинно рассылать FAD sub-TLV в RI LSA в рамках AS, выбор FAD происходит для каждой индивидуальной зоны, где алгоритм будет применяться.

Для конкретного Flex-Algorithm не требуется идентичность FAD во всех областях сети. Например, трафик для одного Flex-Algorithm может оптимизироваться по задержке (например, с метрикой задержки) в одной области и по доступной пропускной способности (например, с метрикой IGP) в другой области или уровне.

Как описано в параграфе 5.1, IS-IS позволяет регенерировать выигрышное определение FAD с уровня 2 на уровень 1 без каких-либо изменений. Это позволяет оператору настроить FAD на одном или нескольких маршрутизаторах уровня 2 без необходимости повторять настройку в каждой области уровня 1, если намерение состоит в использовании одного FAD для конкретного Flex-Algorithm на всех уровнях. Аналогичным способом это можно реализовать в OSPF путём использования лавинной рассылки в AS для RI LSA с анонсами FAD sub-TLV для определённого Flex-Algorithm.

Регенерация FAD с уровня 1 на уровень 2 не поддерживается в IS-IS, поэтому для регенерации FAD между уровнями IS-IS определение FAD должно задаваться на маршрутизаторах уровня 2. В OSPF определение FAD возможно в любой области и оно будет распространяться на весь домен маршрутизации OSPF с использованием лавинной рассылки RI LSA в масштабе AS.

15.2. Использование правила исключения SRLG с Flex-Algorithm

Имеется два разных способа использования информации SRLG с Flex-Algorithm.

  • В контексте одного Flex-Algorithm SRLG можно применять для расчёта резервных путей, как описано в [RTGWG-SEGMENT-ROUTING-TI-LFA]. Для этого не требуется связывать какое-либо ограничение SRLG с данным определением Flex-Algorithm.

  • В контексте нескольких Flex-Algorithm SRLG можно применять для создания непересекающихся наборов путей за счёт исключения каналов, относящихся к конкретной группе SRLG из топологии, где пути рассчитываются с конкретным Flex-Algorithm. Такое исключение:

    • упрощает использование уже развёрнутых конфигураций SRLG для организации непересекающихся путей между двумя или более Flex-Algorithms;

    • требует явного связывания данного Flex-Algorithm с конкретным набором ограничений SRLG, как указано в параграфах 6.5 и 7.5.

Эти варианты применения не связаны между собой.

15.3. Max-Metric

В IS-IS и OSPF имеются механизмы установки значения метрики IGP на канале, делающего этот канал недоступным или применяемым в самом крайнем случае (last resort). Аналогичные функции нужны и для показателей Min Unidirectional Link Delay и TE, поскольку они могут применяться в расчётах путей Flex-Algorithm.

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику Min Unidirectional Link Delay, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA Min Unidirectional Link Delay для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение задержки 16777215 (224 -1).

Канал можно сделать недоступным для всех Flex-Algorithm, использующих метрику TE, как описано в параграфе 5.1, удалив анонсы Flex-Algorithm ASLA TE для этого канала. Канал можно назначить как крайнюю меру, установив в анонсах Flex-Algorithm для задержки ASLA на этом канале значение метрики TE (224 – 1) в IS-IS и (232 – 1) в OSPF.

15.4. Задание и изменение гибкого алгоритма

При настройке узла для участия в конкретном Flex-Algorithm, следует внимательно рассмотреть компоненты FAD (calculation-type, metric-type, ограничения). Настройка участия в определённом Flex-Algorithm не гарантирует, что узел будет активно участвовать в алгоритме, поскольку он может не поддерживать calculation-type, metric-type или некоторые ограничения, анонсируемые выигрышным определением FAD (5.3. Базовая обработка FAD TLV). Изменения в конфигурации FAD также следует рассматривать в свете возможностей участвующих маршрутизаторов в области действия анонсов FAD.

Как отмечено в параграфе 5.3, изменение FAD может потребовать пересчёта SPF4 в масштабе сети и повторного схождения. Это следует учитывать при планировании и внесении изменений в FAD.

15.5. Число гибких алгоритмов

Максимальное число Flex-Algorithm определяется диапазоном 128-255, как указано в разделе 4. Гибкий алгоритм. Хотя такое возможно, но не предполагается, что все такие алгоритмы будут применяться одновременно. Обычно в сети будет использоваться лишь часть возможных Flex-Algorithms.

16. Совместимость с имеющимися расширениями

Это расширение не создаёт проблем совместимости с имеющимися протоколами и расширениями. В IS-IS, OSPFv2 и OSPFv3 чётко задана обработка нераспознанных TLV и sub-TLV, что позволяет создавать новые расширения, подобные описанным здесь, без возникновения проблем совместимости.

17. Вопросы безопасности

Этот документ добавляет две новых возможности нарушить работу сетей IGP.

  • Злоумышленник может захватить конкретный Flex-Algorithm, анонсируя FAD с приоритетом 255 (или иным значением выше, чем у легитимных узлов).

  • Злоумышленник может создать ложное впечатление о поддержке (или её отсутствии) маршрутизатором конкретного Flex-Algorithm.

Обе эти атаки можно предотвратить с помощью имеющихся защитных расширений, как описано в [RFC5304] и [RFC5310] для IS-IS, в [RFC2328] и [RFC7474] для OSPFv2, в [RFC4552] и [RFC5340] для OSPFv3.

Если аутентифицированный узел захвачен злоумышленником, такой мошеннический узел может анонсировать FAD для любого Flex-Algorithm. Это может привести к тому, что трафик для такого Flex-Algorithm будет направлен не туда или не доставлен совсем, например, за счёт использования неподдерживаемых metric-type, calculation-type или ограничений. Такую атаку не удастся предотвратить с помощью аутентификации и она ничем не отличается от других вариантов анонсирования ложных сведений через IS-IS или OSPF.

18. Взаимодействие с IANA

18.1. Взаимодействие с IANA для IGP

18.1.1. Реестр IGP Algorithm Types

Этот документ вносит указанную в таблице 1 запись в реестр IGP Algorithm Types.

Таблица 1. Реестр IGP Algorithm Types.

 

Значение

Описание

Документ

128-255

Гибкие алгоритмы

RFC 9350, раздел 4

 

18.1.2. Реестр IGP Metric-Type

Агентство IANA создало реестр IGP Metric-Type в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action [RFC8126] [RFC7120]. Выделенные здесь значения из диапазона 0-255 указаны в таблице 2.

Таблица 2. Реестр IGP Metric-Type.

Тип

Описание

Документ

0

IGP Metric

RFC 9350, параграф 5.1

1

Min Unidirectional Link Delay в соответствии с параграфом 4.2 в [RFC8570] и 4.2 в [RFC7471]

RFC 9350, параграф 5.1

2

Traffic Engineering Default Metric в соответствии с параграфом 3.7 в [RFC5305] и Traffic Engineering Metric в соответствии с параграфом 2.5.5 в [RFC3630]

RFC 9350, параграф 5.1

18.2. Реестр IGP Flexible Algorithm Definition Flags

Агентство IANA создало реестр IGP Flexible Algorithm Definition Flags в группе реестров Interior Gateway Protocol (IGP) Parameters. Для регистрации применяется процедура Standards Action. Новые значения следует выделять по порядку битов (6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV). Исходное назначение показано в таблице 3.

Таблица 3. Реестр IGP Flexible Algorithm Definition Flags.

 

Бит

Имя

Документ

0

Флаг метрики префикса (M-flag)

RFC 9350, параграфы 6.4 и 7.4

 

18.3. Взаимодействие с IANA для IS-IS

18.3.1. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

Этот документ вносит указанную в таблице 4 запись в реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

Таблица 4. Реестр IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV.

 

Значение

Описание

Документ

26

Определение гибкого алгоритма (FAD)

RFC 9350, параграф 5.1

 

18.3.2. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability

Этот документ вносит указанную в таблице 5 запись в реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.


Таблица 5. Реестр IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability.

 

Тип

Описание

27

135

235

236

237

Документ

6

Flexible Algorithm Prefix Metric (FAPM)

n

y

y

y

y

RFC 9350, раздел 8

 

18.3.3. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV

Агентство IANA создало реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV внутри группы реестров IS-IS TLV Codepoints. Для регистрации применяется процедура Expert Review (отметим, что группа IS-IS TLV Codepoints включает рекомендацию применять Expert Review для всех реестров в ней).

Записи sub-sub-TLV, заданных в этом документе для включения в реестр, показаны в таблице 6.

Таблица 6. Реестр IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV.

 

Тип

Описание

Документ

0

Резерв

RFC 9350

1

Flexible Algorithm Exclude Admin Group

RFC 9350, параграф 6.1

2

Flexible Algorithm Include-Any Admin Group

RFC 9350, параграф 6.2

3

Flexible Algorithm Include-All Admin Group

RFC 9350, параграф 6.3

4

Flexible Algorithm Definition Flags

RFC 9350, параграф 6.4

5

Flexible Algorithm Exclude SRLG

RFC 9350, параграф 6.5

6-255

Не выделены

 

18.4. Взаимодействие с IANA для OSPF

18.4.1. Реестр OSPF Router Information (RI) TLVs

Этот документ вносит указанную в таблице 7 запись в реестр OSPF Router Information (RI) TLVs.

Таблица 7. Реестр OSPF Router Information (RI) TLVs.

 

Значение

Описание

Документ

16

Flexible Algorithm Definition (FAD) TLV

RFC 9350, параграф 5.2

 

18.4.2. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs

Этот документ вносит указанную в таблице 8 запись в реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

Таблица 8. Реестр OSPFv2 Extended Prefix TLV Sub-TLVs.

 

Значение

Описание

Документ

3

Flexible Algorithm Prefix Metric (FAPM)

RFC 9350, раздел 9

 

18.4.3. Реестр OSPFv3 Extended-LSA Sub-TLVs

Этот документ вносит указанные в таблице 9 записи в реестр OSPFv3 Extended-LSA Sub-TLVs.

Таблица 9. Реестр OSPFv3 Extended-LSA Sub-TLVs.

 

Значение

Описание

Документ

26

Flexible Algorithm Prefix Metric (FAPM)

RFC 9350, раздел 9

33

OSPF Flexible Algorithm ASBR Metric

RFC 9350, параграф 10.2

 

18.4.4. Реестр OSPF Flex-Algorithm Prefix Metric Bits

Агентство IANA создало реестр OSPF Flex-Algorithm Prefix Metric Bits внутри реестра Open Shortest Path First (OSPF) Parameters. Регистрация выполняется по процедуре IETF Review. Биты 1-7 не выделены, исходное назначение показано в таблице 10.

Таблица 10. Реестр OSPF Flex-Algorithm Prefix Metric Bits.

 

Номер бита

Описание

Документ

0

E bit – External Type

RFC 9350, раздел 9

 

18.4.5. Реестр Opaque Link-State Advertisements (LSA) Option Types

Этот документ регистрирует указанное в таблице 11 значение в реестре Opaque Link-State Advertisements (LSA) Option Types внутри группы реестров Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types.

Таблица 11. Реестр Opaque Link-State Advertisements (LSA) Option Types.

 

Значение

Неинтерпретируемый тип

Документ

11

OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA

RFC 9350, параграф 10.1

 

18.4.6. Реестр OSPFv2 Extended Inter-Area ASBR TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR TLVs внутри группы реестров Open Shortest Path First v2 (OSPFv2) Parameters. Для реестра применяется процедура IETF Review или IESG Approval. Исходные значения приведены в таблице 12.

Таблица 12. Реестр OSPFv2 Extended Inter-Area ASBR TLVs.

 

Значение

Описание

Документ

1

Extended Inter-Area ASBR

RFC 9350

 

Значения 2-32767 не распределены, значения 32768-33023 выделены для экспериментов (Experimental Use), 0 и 33024-65535 являются резервными.

18.4.7. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs

Агентство IANA создало реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs внутри реестра Open Shortest Path First v2 (OSPFv2) Parameters. Регистрация выполняется по процедуре IETF Review или IESG Approval. Исходные значения приведены в таблице 13.

Таблица 13. Реестр OSPFv2 Extended Inter-Area ASBR Sub-TLVs.

 

Значение

Описание

Документ

1

OSPF Flexible Algorithm ASBR Metric

RFC 9350

 

Значения 2-32767 не распределены, значения 32768-33023 выделены для экспериментов (Experimental Use), 0 и 33024-65535 являются резервными.

18.4.8. Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs

Агентство IANA создало реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs внутри группы реестров Open Shortest Path First (OSPF) Parameters. Для реестра применяется процедура IETF Review или IESG Approval.

Реестр OSPF Flexible Algorithm Definition TLV Sub-TLVs будет определять sub-TLV с любым уровнем вложенности для Flexible Algorithm TLV и новые значения могут выделяться по процедуре регистрации.

Регистрируемые документом sub-TLV указаны в таблице 14.

Таблица 14. Реестр OSPFv2 OSPF Flexible Algorithm Definition TLV Sub-TLVs.

 

Номер бита

Описание

Документ

0

Резерв

RFC 9350

1

Flexible Algorithm Exclude Admin Group

RFC 9350, параграф 7.1

2

Flexible Algorithm Include-Any Admin Group

RFC 9350, параграф 7.2

3

Flexible Algorithm Include-All Admin Group

RFC 9350, параграф 7.3

4

Flexible Algorithm Definition Flags

RFC 9350, параграф 7.4

5

Flexible Algorithm Exclude SRLG

RFC 9350, параграф 7.5

 

Значения 6-32767 не распределены, а значения 32768-33023 выделены для экспериментов (Experimental Use) и не требуют регистрации в IANA. Значения 33024-65535 в настоящее время не выделены. Для получения значений из этого диапазона должна быть выпущена спецификация IETF, с соответствующими запросами к IANA.

18.4.9. Реестр Link Attribute Application Identifiers

Этот документ регистрирует указанные в таблице 15 идентификаторы в реестре Link Attribute Application Identifiers.

Таблица 15. Реестр флагов IGP Flexible Algorithm Definition.

 

Бит

Описание

Документ

3

Гибкий алгоритм (X-bit)

RFC 9350, раздел 12

 

19. Литература

19.1. Нормативные документы

[ISO10589] ISO, “Information technology – Telecommunications and information exchange between systems – Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)”, Second Edition, ISO/IEC 10589:2002, November 2002.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, “The OSPF Opaque LSA Option”, RFC 5250, DOI 10.17487/RFC5250, July 2008, <https://www.rfc-editor.org/info/rfc5250>.

[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., “IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”, RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, “OSPFv2 Prefix/Link Attribute Advertisement”, RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, “Extensions to OSPF for Advertising Optional Router Capabilities”, RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.

[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, “IS-IS Extensions for Advertising Router Information”, RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, “OSPFv3 Link State Advertisement (LSA) Extensibility”, RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing with the MPLS Data Plane”, RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, “OSPF Extensions for Segment Routing”, RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.

[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., “OSPFv3 Extensions for Segment Routing”, RFC 8666, DOI 10.17487/RFC8666, December 2019, <https://www.rfc-editor.org/info/rfc8666>.

[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, “IS-IS Extensions for Segment Routing”, RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, “IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane”, RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/info/rfc9352>.

19.2. Дополнительная литература

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101] Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option”, RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2”, RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

[RFC3906] Shen, N. and H. Smit, “Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels”, RFC 3906, DOI 10.17487/RFC3906, October 2004, <https://www.rfc-editor.org/info/rfc3906>.

[RFC4552] Gupta, M. and N. Melam, “Authentication/Confidentiality for OSPFv3”, RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC5304] Li, T. and R. Atkinson, “IS-IS Cryptographic Authentication”, RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5305] Li, T. and H. Smit, “IS-IS Extensions for Traffic Engineering”, RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, “IS-IS Generic Cryptographic Authentication”, RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6”, RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, “Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks”, RFC 6571, DOI 10.17487/RFC6571, June 2012, <https://www.rfc-editor.org/info/rfc6571>.

[RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.

[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, “OSPF Traffic Engineering (TE) Metric Extensions”, RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., “Security Extension for OSPFv2 When Using Manual Key Management”, RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, “IS-IS Traffic Engineering (TE) Metric Extensions”, RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, “Segment Routing over IPv6 (SRv6) Network Programming”, RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[ROUTING-PLANES-USING-SR] Hegde, S. and A. Gulko, “Separating Routing Planes using Segment Routing”, Work in Progress, Internet-Draft, draft-gulkohegde-routing-planes-using-sr-00, 13 March 2017, <https://datatracker.ietf.org/doc/html/draft-gulkohegde-routing-planes-using-sr-00>.

[RTGWG-SEGMENT-ROUTING-TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, “Topology Independent Fast Reroute using Segment Routing”, Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-09, 23 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-09>.

Благодарности

В этом документе, среди прочего, рассматривается задача, которую пытаются решить в [ROUTING-PLANES-USING-SR]. Все авторы этого документа согласились присоединиться к данному документу.

Спасибо Eric Rosen, Tony Przygienda, William Britto A. J., Gunter Van de Velde, Dirk Goethals, Manju Sivaji, and Baalajee S. за их подробные рецензии и отличные комментарии.

Спасибо Cengiz Halit за его рецензию и отклики на начальном этапе решения.

Спасибо Kenji Kumaki за его комментарии.

Спасибо Acee Lindem за редакционные замечания.

Адреса авторов


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3В полях ASBR Router ID и Sub-TLVs. Прим. перев.

4Shortest Path First – сначала кратчайший путь.

Рубрика: RFC | Оставить комментарий

RFC 9351 Border Gateway Protocol – Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Internet Engineering Task Force (IETF)                K. Talaulikar, Ed.
Request for Comments: 9351                                     P. Psenak
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                                 S. Zandi
                                                                G. Dawra
                                                                LinkedIn
                                                           February 2023

Border Gateway Protocol – Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Расширения BGP-LS для анонсирования гибкого алгоритма

PDF

Аннотация

Гибким алгоритмом (Flexible Algorithm) называется решение, позволяющее некоторым протоколам маршрутизации (например, OSPF и IS-IS) рассчитывать пути через сеть на основе заданных пользователем (поэтому более гибких) ограничений и показателей. Расчёт выполняют маршрутизаторы, участвующие в конкретной сети, распределенно с использованием определения гибкого алгоритма алгоритма (Flexible Algorithm Definition или FAD). Это определение предоставляется не одном или нескольких маршрутизаторах и распространяется через сеть путём лавинной рассылки OSPF и IS-IS.

Состояние канала для протокола граничного шлюза (Border Gateway Protocol – Link State или BGP-LS) позволяет собрать из сети различные сведения. Этот документ задаёт расширения семейства адресов BGP-LS для анонсирования FAD как части топологических сведений о сети.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9351.

Авторские права

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Классический протокол IGP (например, OSPF и IS-IS) рассчитывает лучшие пути через сеть на основе метрики IGP, назначенной для каналов сети. Во многих развёрнутых сетях применяется решение на основе RSVP-TE [RFC3209] или политики маршрутизации по сегментам (Segment Routing или SR) [RFC8402] для передачи трафика по пути, рассчитанному с использованием других показателей или ограничесний, нежели для кратчайшего пути IGP. В [RFC9350] задано решение с гибким алгоритмом, позволяющее самим IGP рассчитывать пути через сеть на основе ограничений.

Алгоритм называется гибким потому, что он обеспечивает пользователю гибкость задания:

  • типа применяемого расчёта (например, кратчайший путь);

  • типа применяемой метрики (например, IGP или TE);

  • набора применяемых ограничений (например, включение или исключение некоторых каналов по близости).

Работа гибкого алгоритма IGP подробно описана в [RFC9350].

Расширения BGP-LS для SR заданы в [RFC9085] и в [IDR-BGPLS-SRV6-EXT] для SR-MPLS и SRv63. Они включают расширения для анонсирования сведений SR, содержащих разные типы идентификаторов сегментов (Segment Identifier или SID).

  • SR Algorithm TLV указывает участие узла в расчёте Flexible Algorithm.

  • Prefix-SID TLV указывает привязку Prefix-SID к конкретному Flexible Algorithm для пересылки SR-MPLS.

  • SRv6 Locator TLV указывает локатор для конкретного Flexible Algorithm при пересылке SRv6.

Этот документ задаёт расширения BGP-LS для анонсирования сведений FAD, чтобы обеспечить возможность изучить сопоставления номера гибкого алгоритма с его определением в каждой области или домене базового протокола IGP. Это определение указывает тип применяемого расчёта и ограничения для данного Flexible Algorithm, которые могут применяться для организации сквозных путей SR Policy через множество доменов с использованием подходящих SID в списке сегментов [RFC9256]. Например, при указании Flexible Algorithm Prefix-SID (для SR-MPLS) или End SID (для SRv6) граничные маршрутизаторы областей (Area Border Router или ABR) или автономных систем (Autonomous System Border Router или ASBR), соответствующие определению, которое оптимизирует показатель задержки, могут построить сквозной путь с малой задержкой через домены IGP с минимальным числом SID в списке SID.

1.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Обзор расширений BGP-LS для гибкого алгоритма

BGP-LS [RFC7752] задаёт Node NLRI для анонсирования узлов и их атрибутов, Link NLRI для анонсирования каналов и их атрибутов, Prefix NLRI для анонсирования префиксов и их атрибутов с применением атрибута BGP-LS.

Анонсируемые узлом FAD считаются атрибутами уровня узла и анонсируются в соответствии с разделом 3.

Различные атрибуты каналов, такие как близость и группы общего риска (Shared Risk Link Group или SRLG), применяемые в расчётах маршрутов с помощью гибкого алгоритма в IS-IS и OSPF, анонсируются в этих протоколах с использованием анонсов зависящих от приложения атрибутов каналов (Application-Specific Link Attribute или ASLA), как описано в [RFC8919], [RFC8920] и [RFC9350]. Расширения BGP-LS для анонсов ASLA заданы в [RFC9294].

Показатель префикса гибкого алгоритма (Flexible Algorithm Prefix Metric или FAPM) считается атрибутом префикса и анонсируется в соответствии с разделом 4.

3. TLV задания гибкого алгоритма

Этот документ задаёт необязательный TLV атрибута BGP-LS, связанного с Node NLRI, который называется Flexible Algorithm Definition TLV или FAD TLV. Формат TLV показан на рисунке 1

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |   Metric-Type |   Calc-Type   |    Priority   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                sub-TLVs       ...                            //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Flexible Algorithm Definition TLV.


Type

1039

Length

Общий размер поля значений (включая любые sub-TLV) в октетах. Размер должен быть не меньше 4.

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Metric-Type

1-октетное значение, указывающее тип метрики в соответствии с [RFC9350].

Calc-Type

1-октетное значение, указывающее тип расчёта в соответствии с [RFC9350].

Priority

1-октетное значение, указывающее анонса FAD в соответствии с [RFC9350].

Sub-TLVs

Необязательные sub-TLV, описанные ниже.

FAD TLV анонсируется в атрибуте BGP-LS вместе с Node NLRI и выводится из анонсов IGP:

  • для IS-IS из IS-IS Flexible Algorithm Definition sub-TLV в [RFC9350];

  • для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Definition TLV в [RFC9350].

Атрибут BGP-LS, связанный с Node NLRI может включать FAD TLV, соответствующие FAD для каждого алгоритма, анонсируемого этим узлом.

В последующих параграфах заданы sub-TLV для FAD TLV.

3.1. Flexible Algorithm Exclude-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Exclude-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и исключения каналов с заданной близостью из расчётов конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Flexible Algorithm Exclude-Any Affinity Sub-TLV.


Type

1040

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Exclude-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Exclude-Any Affinity sub-TLV выводится из Flexible Algorithm Exclude-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.2. Flexible Algorithm Include-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Include-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 3.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Flexible Algorithm Include-Any Affinity Sub-TLV.


Type

1041

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-Any Affinity sub-TLV выводится из Flexible Algorithm Include-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.3. Flexible Algorithm Include-All Affinity Sub-TLV

Необязательный Flexible Algorithm Include-All Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения всех каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Flexible Algorithm Include-All Affinity Sub-TLV.


Type

1042

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-All EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-All Affinity sub-TLV выводится из Flexible Algorithm Include-All Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.4. Flexible Algorithm Definition Flags Sub-TLV

Необязательный Flexible Algorithm Definition Flags sub-TLV служит для переноса связанных с FAD флагов, используемых в расчёте конкретного алгоритма, как описано в [RFC9350]. Формат sub-TLV показан на рисунке 5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Flags (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Flexible Algorithm Definition Flags Sub-TLV.


Type

1043

Length

Общий размер поля значения, зависящий от размера флагов. Значение должно быть больше 0 и кратно 4.

Flags

Битовая маская, служащая для представления фланов FAD, как описано в [RFC9350].

Информация Flexible Algorithm Definition Flags sub-TLV выводится из Flexible Algorithm Definition Flags sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.5. Flexible Algorithm Exclude SRLG Sub-TLV

Необязательный Flexible Algorithm Exclude SRLG sub-TLV служит для переноса сведений SRLG, связанных с FAD, и исключения каналов, связанных с любой из указанных групп SRLG, из расчётов конкретного алгоритма, как описано в [RFC9350]. SRLG, связанные с каналом, передаются в BGP-LS Shared Risk Link Group (TLV 1096) [RFC7752]. Формат sub-TLV показан на рисунке 6.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Shared Risk Link Group Values (переменный)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Flexible Algorithm Exclude SRLG Sub-TLV.


Type

1045

Length

Общий размер поля значения, зависящий от числа значений SRLG. Значение должно быть больше 0 и кратно 4.

Shared Risk Link Group Values

Обно или несколько значений SRLG размером по 4 октета, как описано в [RFC9350].

Информация Flexible Algorithm Exclude SRLG sub-TLV выводится из Flexible Algorithm Exclude SRLG sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.6. Flexible Algorithm Unsupported Sub-TLV

Сигнализация OSPF и IS-IS для FAD допускает расширения через новые sub-TLV в рамках соответствующего IGP Flexible Algorithm Definition TLV. Как указано в параграфе 5.3 [RFC9350], важно, чтобы определение FAD был понятно целиком любому, кто использует его для расчётов. Таким образом, FAD отличается от большинства других расширений протокола, где пропуск или игнорирование непонятных сведений sub-TLV не меняет поведения.

Необязательный Flexible Algorithm Unsupported sub-TLV применяется для индикации наличия неподдерживаемых FAD sub-TLV. Потребность в этом sub-TLV возникает, когда реализация BGP-LS на анонсирующем узле не поддерживает какой-либо из FAD sub-TLV, из имеющихся в анонсе IGP. Формат sub-TLV показан на рисунке 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  | типы sub-TLV (переменный) ...                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Flexible Algorithm Unsupported Sub-TLV.


Type

1046

Length

Общий размер поля значения в октетах (включая любые содержащиеся типы sub-TLV).

Protocol-ID

Указывает BGP-LS Protocol-ID протокола, из которого FAD анонсируется через BGP-LS. Значения берутся из реестра IANA BGP-LS Protocol-IDs” subregistry under the “Border Gateway Protocol – Link State (BGP-LS) Parameters <https://www.iana.org/assignments/bgp-ls-parameters/>.

sub-TLV types

Необязательный набор типов sub-TLV, которые не поддерживаются узлом, создавшим анонс BGP-LS. Размер каждого sub-TLV зависит от протокола, указанного полем Protocol-ID. Например, для IS-IS, каждый тип sub-TLV имеет размер 1 октет, а для OSPF – 2 октета.

Узел, создающий анонс, должен включать Flexible Algorithm Unsupported sub-TLV, когда он сталкивается с неподдерживаемым им sub-TLV в соответствующем FAD анонса IS-IS или OSPF. При анонсировании Flexible Algorithm Unsupported sub-TLV следует включать зависимые от протокола типы неподдерживаемых sub-TLV (для диагностики).

Вопрос использования сведений FAD потребителями данных из BGP-LS выходит за рамки этого документа. Однако рекомендуется выбирать узел, используемый для отправки топологических сведений IGP в BGP-LS, так, чтобы анононсирующий узел поддерживал все использовуемые в его части сети расширения FAD. Это позволит избежать анонсирования неполных FAD в BGP-LS.

4. Flexible Algorithm Prefix Metric TLV

Этот документ задаёт необязательный BGP-LS Attribute TLV, связанный с Prefix NLRI и называемый Flexible Algorithm Prefix Metric TLV или FAPM TLV. Формат TLV показан на рисунке 8.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |     Flags     |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Flexible Algorithm Prefix Metric TLV.


Type

1044

Length

8 октетов

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Flags

1-октетное значение, применимое только для OSPF, как указано в [RFC9350]. Для IS-IS должно быть 0.

Reserved

2-октетное значение, которое должно устанавливаться в 0 источником и должно игнорироваться получателем.

Metric

4-октетное поле для передачи сведений о метрике.

FAPM TLV анонсируется в атрибуте BGP-LS вместе с Prefix NLRI и выводится из анонсов IGP:

  • для IS-IS из IS-IS Flexible Algorithm Prefix Metric sub-TLV в [RFC9350];

  • для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Prefix Metric sub-TLV в [RFC9350].

Атрибут BGP-LS, связанный с Prefix NLRI может включать FAPM TLV, соответствующие Flexible Algorithm Prefix Metric для каждого алгоритма, анонсируемого этим узлом.

5. Взаимодействие с IANA

Агентство IANA выделило в ресстре BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs <https://www.iana.org/assignments/bgp-ls-parameters> коды для TLV и sub-TLV, указанные в таблице 1.

Таблица 1. Коды TLV для гибких алгоритмов.

 

Код TLV

Описание

1039

Определение гибкого алгоритма

1040

Flexible Algorithm Exclude-Any Affinity

1041

Flexible Algorithm Include-Any Affinity

1042

Flexible Algorithm Include-All Affinity

1043

Flexible Algorithm Definition Flags

1044

Flexible Algorithm Prefix Metric

1045

Flexible Algorithm Exclude SRLG

1046

Flexible Algorithm Unsupported

 

6. Вопросы управляемости

Заданные в этом документе расширения дополняют имеющиеся топологические сведения IGP, которые могут распространяться через [RFC7752]. Процедуры и расширения, заданные в этом документе, не влияют на операции и управление протоколом BGP сверх указанного в разделе «Вопросы управляемости» [RFC7752]. В частности проверки формата NLRI из раздела «Контроль отказов» в [RFC7752] охватывают TLV для BGP-LS NLRI из этого документа.

Расширения из этого документа не задают новых аспектов конфигурации или настройки в BGP и BGP-LS. Спецификация моделей BGP на основе [IDR-BGP-MODEL] ещё не завершена.

7. Вопросы безопасности

Вопросы безопасности при получении и распространении сведений BGP-LS рассмотрены в [RFC7752].

TLV, добавленные в этом документе, служат для распространения расширений IGP Flexible Algorithm, заданных в [RFC9350]. Предполагается, что экземпляры IGP, создающие эти TLV, будут обеспечивать безопасность (как указано в [RFC9350]) для внедрения Flexible Algorithm.

Этот документ задаёт расширения для анонсирования сведений Flexible Algorithm, относящихся к узлам и префиксам. Подмена таких сведений может влиять на использующие их приложения, включая расчёт и программирование маршрутов. Поскольку заданные здесь анонсы относятся к конкретной топологии Flexible Algorithm, область влияния подмены ограничена этой топологией.

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP”, RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, “IGP Flexible Algorithm”, RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.

8.2. Дополнительная литература

[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “BGP YANG Model for Service Provider Networks”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-15, 13 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-15>.

[IDR-BGPLS-SRV6-EXT] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, “BGP Link State Extensions for SRv6”, Work in Progress, Internet-Draft, draft-ietf-idr-bgpls-srv6-ext-13, 14 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-13>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, “Border Gateway Protocol – Link State (BGP-LS) Extensions for Segment Routing”, RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/info/rfc9085>.

[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9294] Talaulikar, K., Ed., Psenak, P., and J. Tantsura, “Application-Specific Link Attributes Advertisement ping the Border Gateway Protocol – Link State (BGP-LS)”, RFC 9294, DOI 10.17487/RFC9294, August 2022, <https://www.rfc-editor.org/info/rfc9294>.

Благодарности

Авторы благодарны Les Ginsberg, Amalesh Maity, Y. F. Siu, Vijay Gurbani, Donald Eastlake 3rd за их рецензии и вклад в работу. Спасибо Jie Dong за рецензию курастора. Спасибо Alvaro Retana за подробную рецензию AD и предложения по улучшению документа.

Адреса авторов

Ketan Talaulikar (editor)
Cisco Systems
India
Email: ketant.ietf@gmail.com
 
Peter Psenak
Cisco Systems
Slovakia
Email: ppsenak@cisco.com
 
Shawn Zandi
LinkedIn
United States of America
Email: szandi@linkedin.com
 
Gaurav Dawra
LinkedIn
United States of America
Email: gdawra.ietf@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Segment Routing over IPv6 – маршрутизация по сегментам через IPv6.

Рубрика: RFC | Оставить комментарий

RFC 9349 Definitions of Managed Objects for IP Traffic Flow Security

Internet Engineering Task Force (IETF)                          D. Fedyk
Request for Comments: 9349                                     E. Kinzie
Category: Standards Track                        LabN Consulting, L.L.C.
ISSN: 2070-1721                                             January 2023

Definitions of Managed Objects for IP Traffic Flow Security

Определения управляемых объектов для защиты потоков трафика IP

PDF

Аннотация

Этот документ описывает управляемые объекты дополнений защиты потоков трафика IP (IP Traffic Flow Security) для протокола обмена ключами Internet версии 2 (Internet Key Exchange Protocol Version 2 или IKEv2) и IPsec. Документ представляет доступные лишь для чтения версии объектов, определённых в модуле YANG для тех же целей (A YANG Data Model for IP Traffic Flow Security, RFC 9348).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9349.

Авторские права

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ определяет модуль MIB (Management Information Base) для использования протоколами сетевого управления в сообществе Internet. Расширения для защиты потоков трафика (IP Traffic Flow Security или IP-TFS), заданные в [RFC9347], расширяют защищённые связи IPsec SA для повышения уровня конфиденциальности трафика.

Определяемые здесь объекты совпадают с заданными в [RFC9348], но поддерживаются лишь данные рабочего состояния. За счёт доступности данных рабочего состояния по протоколу SNMP имеющиеся системы управления сетями могут отслеживать IP-TFS. Эти данные указаны в дереве MIB (параграф 4.1). Модуль использует модель данных YANG в качестве отправной точки. Отметим, что модель IETF MIB для IPsec не была стандартизована, однако приведённые здесь структуры можно адаптировать к имеющимся фирменным реализациям MIB, где для управления сетями применяется SNMP.

1.1. Схема стандартов управления Internet

Подробный обзор документов, описывающих современную схему управления (Internet-Standard Management Framework) приведён в разделе 7 [RFC3410].

Доступ к управляемым объектам происходит через виртуальное хранилище информации, называемое базой управляющей информации (Management Information Base или MIB). Доступ к объектам MIB обычно выполняется по простому протоколу управления сетью (Simple Network Management Protocol или SNMP). Объекты MIB определяются с использованием механизмов, заданных структурой управляющей информации (Structure of Management Information или SMI). Этот документ описывает модуль MIB, соответствующий SMIv2, описанной в STD 58, [RFC2578], [RFC2579] и [RFC2580].

2. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Обзор

Этот документ задаёт MIB для доступа к рабочим параметрам IP-TFS. Расширение IP-TFS, определённое в [RFC9347], настраивает защищённые свящи (Security Association или SA) для туннельного режима IPsec с характеристиками, повышающими уровень конфиденциальности трафика и сокращающими расход прорускной способности.

Документ основан на концепциях и модели управления [RFC9348]. Предполагается знакомство читателя с концепциями IPsec [RFC4301], IP-TFS [RFC9347] и моделью управления IP-TFS, описанной в [RFC9348].

Документ задаёт расширяемую операционную модель для IP-TFS, используя модель управления из [RFC9348]. Это позволяет системам SNMP читать рабочие объекты (включая настраиваемые) из IP-TFS.

4. Объекты управления

4.1. Дерево MIB

Ниже представлено дерево регистрации MIB для расширений IP-TFS.

   # дерево регистрации IP-TRAFFIC-FLOW-SECURITY-MIB

   --iptfsMIB(1.3.6.1.2.1.500)
     +--iptfsMIBObjects(1)
     |  +--iptfsGroup(1)
     |  |  +--iptfsConfigTable(1)
     |  |     +--iptfsConfigTableEntry(1) [iptfsConfigSaIndex]
     |  |        |
     |  |        +-- --- Integer32           iptfsConfigSaIndex(1)
     |  |        +-- r-n TruthValue          congestionControl(2)
     |  |        +-- r-n TruthValue          usePathMtuDiscovery(3)
     |  |        +-- r-n UnsignedShort       outerPacketSize(4)
     |  |        +-- r-n CounterBasedGauge64 l2FixedRate(5)
     |  |        +-- r-n CounterBasedGauge64 l3FixedRate(6)
     |  |        +-- r-n TruthValue          dontFragment(7)
     |  |        +-- r-n NanoSeconds         maxAggregationTime(8)
     |  |        +-- r-n UnsignedShort       windowSize(9)
     |  |        +-- r-n TruthValue          sendImmediately(10)
     |  |        +-- r-n NanoSeconds         lostPacketTimerInterval(11)
     |  +--ipsecStatsGroup(2)
     |  |  +--ipsecStatsTable(1)
     |  |     +--ipsecStatsTableEntry(1) [ipsecSaIndex]
     |  |        +-- --- Integer32 ipsecSaIndex(1)
     |  |        +-- r-n Counter64 txPkts(2)
     |  |        +-- r-n Counter64 txOctets(3)
     |  |        +-- r-n Counter64 txDropPkts(4)
     |  |        +-- r-n Counter64 rxPkts(5)
     |  |        +-- r-n Counter64 rxOctets(6)
     |  |        +-- r-n Counter64 rxDropPkts(7)
     |  +--iptfsInnerStatsGroup(3)
     |  |  +--iptfsInnerStatsTable(1)
     |  |     +--iptfsInnerStatsTableEntry(1) [iptfsInnerSaIndex]
     |  |        +-- --- Integer32 iptfsInnerSaIndex(1)
     |  |        +-- r-n Counter64 txInnerPkts(2)
     |  |        +-- r-n Counter64 txInnerOctets(3)
     |  |        +-- r-n Counter64 rxInnerPkts(4)
     |  |        +-- r-n Counter64 rxInnerOctets(5)
     |  |        +-- r-n Counter64 rxIncompleteInnerPkts(6)
     |  +--iptfsOuterStatsGroup(4)
     |     +--iptfsOuterStatsTable(1)
     |        +--iptfsOuterStatsTableEntry(1) [iptfsOuterSaIndex]
     |           +-- --- Integer32 iptfsOuterSaIndex(1)
     |           +-- r-n Counter64 txExtraPadPkts(2)
     |           +-- r-n Counter64 txExtraPadOctets(3)
     |           +-- r-n Counter64 txAllPadPkts(4)
     |           +-- r-n Counter64 txAllPadOctets(5)
     |           +-- r-n Counter64 rxExtraPadPkts(6)
     |           +-- r-n Counter64 rxExtraPadOctets(7)
     |           +-- r-n Counter64 rxAllPadPkts(8)
     |           +-- r-n Counter64 rxAllPadOctets(9)
     |           +-- r-n Counter64 rxErroredPkts(10)
     |           +-- r-n Counter64 rxMissedPkts(11)
     +--iptfsMIBConformance(2)
        +--iptfsMIBConformances(1)
        |  +--iptfsMIBCompliance(1)
        +--iptfsMIBGroups(2)
           +--iptfsMIBConfGroup(1)
           +--ipsecStatsConfGroup(2)
           +--iptfsInnerStatsConfGroup(3)
           +--iptfsOuterStatsConfGroup(4)

4.2. SNMP

Ниже представлен модуль MIB для IP-TFS. Алгоритм контроля перегрузок [RFC5348] указан в тексте MIB.

   <CODE BEGINS> file "iptfs-mib.mib"
   -- *----------------------------------------------------------------
   -- *  Модуль IP-TRAFFIC-FLOW-SECURITY-MIB
   -- *----------------------------------------------------------------

   IP-TRAFFIC-FLOW-SECURITY-MIB DEFINITIONS ::= BEGIN
      IMPORTS
           MODULE-IDENTITY, OBJECT-TYPE,
           Integer32, Unsigned32, Counter64, mib-2
               FROM SNMPv2-SMI
           CounterBasedGauge64
               FROM  HCNUM-TC
           MODULE-COMPLIANCE, OBJECT-GROUP
               FROM SNMPv2-CONF
           TEXTUAL-CONVENTION,
           TruthValue
               FROM SNMPv2-TC;

      iptfsMIB MODULE-IDENTITY
           LAST-UPDATED "202301310000Z"
           ORGANIZATION "IETF IPsecme Working Group"
           CONTACT-INFO
                   "
                      Author: Don Fedyk
                              <mailto:dfedyk@labn.net> 

                      Author: Eric Kinzie
                              <mailto:ekinzie@labn.net>" 

      DESCRIPTION
         "Этот модуль задаёт конфигурацию и рабочее состояние для 
         управления функциональностью IP-TFS (RFC 9348).

         Авторские права (Copyright (c) 2023) принадлежат IETF Trust и
         лицам, указанным как авторы. Все права защищены.

         Распространение и применение модуля в исходной или двоичной 
         форме с изменениями или без таковых разрешено в соответствии с
         лицензией Simplified BSD License, изложенной в параграфе 4.c
         IETF Trust's Legal Provisions Relating to IETF Documents
         (https://trustee.ietf.org/license-info). 

         Эта версия модуля SNMP MIB является частью RFC 9349, где 
         правовые аспекты приведены более полно.";

       REVISION "202301310000Z"
       DESCRIPTION
               "Исходный выпуск, основанный на модели YANG IP-TFS."
       ::= { mib-2 246}
   --
   -- Текстовые соглашения
   --

   UnsignedShort ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS      current
       DESCRIPTION "xs:unsignedShort"
       SYNTAX      Unsigned32 (0 .. 65535)


   NanoSeconds ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d-6"
       STATUS  current
       DESCRIPTION
         "Представляет время в наносекундах."
       SYNTAX      Integer32


   -- Объекты, уведомления, соответствия

      iptfsMIBObjects     OBJECT IDENTIFIER
                  ::= { iptfsMIB 1 }
      iptfsMIBConformance OBJECT IDENTIFIER
                  ::= { iptfsMIB 2}

   --
   -- Группы объектов IP-TFS MIB
   --
      iptfsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 1 }

      ipsecStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 2 }

      iptfsInnerStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 3 }

      iptfsOuterStatsGroup OBJECT IDENTIFIER
                 ::= { iptfsMIBObjects 4 }

      iptfsConfigTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsConfigTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
                  "Таблица конфигурационных данных для IP-TFS."
          ::= { iptfsGroup 1 }

      iptfsConfigTableEntry OBJECT-TYPE
          SYNTAX     IptfsConfigTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Запись (концептуальная строка) со сведениями об 
            отдельной IP-TFS SA."
          INDEX      { iptfsConfigSaIndex }
          ::= { iptfsConfigTable 1 }

     IptfsConfigTableEntry ::= SEQUENCE {
         iptfsConfigSaIndex         Integer32,

      -- Идентификаторы
         congestionControl          TruthValue,
         usePathMtuDiscovery        TruthValue,
         outerPacketSize            UnsignedShort,
         l2FixedRate                CounterBasedGauge64,
         l3FixedRate                CounterBasedGauge64,
         dontFragment               TruthValue,
         maxAggregationTime         NanoSeconds,
         windowSize                 UnsignedShort,
         sendImmediately            TruthValue,
         lostPacketTimerInterval    NanoSeconds
      }

      iptfsConfigSaIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..16777215)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
            "Уникальное значение больше 0 для каждой SA. Рекомендуется
            выделять значения непрерывно, начиная с 1.

            Значение для каждой записи должно сохраняться хотя бы от
            одной инициализации системы сетевого управления объекта 
            до другой."
          ::= { iptfsConfigTableEntry 1 }

       congestionControl OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Принятое по умолчанию значение true разрешает обмен 
             данными контроля перегрузки по линии, требуемый алгоритмами
             контроля перегрузок, как указано в RFC 5348. При значении
             false IP-TFS передаёт через туннель IP-TFS пакеты
             фиксированного размера с постоянной скоростью."
           ::= { iptfsConfigTableEntry 2 }

       usePathMtuDiscovery OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Размер пакета задаётся вручную или определяется 
             автоматически. При usePathMtuDiscovery true система
             использует path-mtu для определения максимального размера
             пакетов IP-TFS. Если размер задан явно, он может лишь
             снижаться при установке use-path-mtu."
           ::= { iptfsConfigTableEntry 3 }

       outerPacketSize OBJECT-TYPE
           SYNTAX      UnsignedShort
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче это размер внешнего инкапсулирующего
             туннельного пакета (т. е. пакета IP с ESP)."
           ::= { iptfsConfigTableEntry 4 }

       l2FixedRate OBJECT-TYPE
           SYNTAX      CounterBasedGauge64
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Битовая скорость IP-TFS может быть указана как скорость в
             линии L2. При передаче это целевая пропускная способность
             (битовая скорость) в бит/сек (bps) для туннеля IP-TFS. Это
             задаёт номинальную синхронизацию передачи пакетов
             фиксированного размера. При включённом контроле перегрузок
             скорость может снижаться."
           ::= { iptfsConfigTableEntry 5 }

       l3FixedRate OBJECT-TYPE
           SYNTAX      CounterBasedGauge64
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "Битовая скорость IP-TFS может быть указана как скорость
             пакетов L3. При передаче это целевая пропускная способность
             (битовая скорость) в бит/сек (bps) для туннеля IP-TFS. Это
             задаёт номинальную синхронизацию передачи пакетов
             фиксированного размера. При включённом контроле перегрузок
             скорость может снижаться."
           ::= { iptfsConfigTableEntry 6 }

       dontFragment OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче запрещает разделять фрагменты пакета по
             разным последовательным пакетам туннеля IP-TFS. Внутренние
             пакеты, размер, не помещающиеся во внешний пакет, будут
             отбрасываться."
           ::= { iptfsConfigTableEntry 7 }

       maxAggregationTime OBJECT-TYPE
           SYNTAX      NanoSeconds
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При передаче максимальным временем агрегирования является
              наибольшее время удержания вложенных пакетов до отправки в
              туннель IP-TFS. Внутренние пакеты, удерживаемые дольше
              этого времени в текущей конфигурации туннеля будут 
              отбрасываться вместо постановки в очередь на передачу."
           ::= { iptfsConfigTableEntry 8 }

       windowSize OBJECT-TYPE
           SYNTAX      UnsignedShort
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении это максимальное число пакетов с нарушением
             порядка, которые будут переупорядочены получателем IP-TFS. 
             Значение 0 отключает восстановление порядка."
           ::= { iptfsConfigTableEntry 9 }

       sendImmediately OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении внутренние пакеты передаются как можно
             быстрее без ожидания потерянных и переупорядоченных внешних
             пакетов. Выбор этой опции сокращает задержку вложенных
             (пользовательских) пакетов, но может усилить нарушение 
             порядка доставки потока пакетов при наличии агрегирования
             или иного переупорядочения."
           ::= { iptfsConfigTableEntry 10 }

       lostPacketTimerInterval OBJECT-TYPE
           SYNTAX      NanoSeconds
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
             "При получении этот интервал задаёт время ожидания
             получателем IP-TFS пропущенных пакетов, прежде чем счесть 
             их потерянными. Если не применяется send-immediately,
             каждая потеря будет задерживать внутренние 
             (пользовательские) пакеты, пока не завершится отсчёт этого
             таймера. Установка слишком малого значения может влиять на
             переупорядочение и сборку."
           ::= { iptfsConfigTableEntry 11 }

      ipsecStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IpsecStatsTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица базовой статистики IPsec."
          ::= { ipsecStatsGroup 1 }


       ipsecStatsTableEntry OBJECT-TYPE
          SYNTAX     IpsecStatsTableEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Запись (концептуальная строка) со сведения о конкретной 
             IKE SA."
          INDEX      { ipsecSaIndex }
          ::= { ipsecStatsTable 1 }

        IpsecStatsTableEntry ::= SEQUENCE {
        ipsecSaIndex               Integer32,
   -- Данные статистики пакетов
        txPkts                     Counter64,
        txOctets                   Counter64,
        txDropPkts                 Counter64,
        rxPkts                     Counter64,
        rxOctets                   Counter64,
        rxDropPkts                 Counter64
      }

      ipsecSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { ipsecStatsTableEntry 1 }


      txPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик исходящих пакетов."
          ::= { ipsecStatsTableEntry 2 }

      txOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик байтов в исходящих пакетах."
          ::= { ipsecStatsTableEntry 3 }

      txDropPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик отброшенных исходящих пакетов."
          ::= { ipsecStatsTableEntry 4 }

      rxPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик входящих пакетов."
          ::= { ipsecStatsTableEntry 5 }

      rxOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик байтов во входящих пакетах."
          ::= { ipsecStatsTableEntry 6 }

      rxDropPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Счётчик отброшенных входящих пакетов."
          ::= { ipsecStatsTableEntry 7 }

      iptfsInnerStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsInnerStatsSaEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица сведений о внутренних пакетах IP-TFS."
          ::= { iptfsInnerStatsGroup 1 }

      iptfsInnerStatsTableEntry OBJECT-TYPE
         SYNTAX     IptfsInnerStatsSaEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
           "Запись со сведения для конкретной IP-TFS SA."
         INDEX      { iptfsInnerSaIndex }
         ::= { iptfsInnerStatsTable 1 }

        IptfsInnerStatsSaEntry ::= SEQUENCE {
        iptfsInnerSaIndex          Integer32,

        txInnerPkts                Counter64,
        txInnerOctets              Counter64,
        rxInnerPkts                Counter64,
        rxInnerOctets              Counter64,
        rxIncompleteInnerPkts      Counter64
       }

      iptfsInnerSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { iptfsInnerStatsTableEntry 1 }

      txInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число переданных внутренних пакетов IP-TFS. Считаются
            лишь целые пакеты, т. е. все фрагменты пакета считаются
            одним пакетом."
          ::= { iptfsInnerStatsTableEntry 2 }

      txInnerOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число переданных внутренних байтов IP-TFS. Считаются
            только байты внутренних пакетов без учёта заполнения."
          ::= { iptfsInnerStatsTableEntry 3 }

      rxInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число полученных внутренних пакетов IP-TFS."
          ::= { iptfsInnerStatsTableEntry 4 }

          rxInnerOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число полученных внутренних байтов IP-TFS. Байты
            заполнения и издержки не учитываются."
          ::= { iptfsInnerStatsTableEntry 5 }

      rxIncompleteInnerPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Общее число неполных внутренних пакетов IP-TFS. Обычно это
            является результатом отсутствия фрагментов, а также может
            быть следствием нарушения порядка или ошибок в полученных
            внешних пакетах."
       ::= { iptfsInnerStatsTableEntry 6 }

     iptfsOuterStatsTable OBJECT-TYPE
          SYNTAX     SEQUENCE OF IptfsOuterStatsSaEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
            "Таблица со сведениями о IP-TFS."
          ::= { iptfsOuterStatsGroup 1 }

      iptfsOuterStatsTableEntry OBJECT-TYPE
         SYNTAX     IptfsOuterStatsSaEntry
         MAX-ACCESS not-accessible
         STATUS     current
         DESCRIPTION
           "Запись со сведениями о конкретной IP-TFS SA."
         INDEX      { iptfsOuterSaIndex }
         ::= { iptfsOuterStatsTable 1 }

        IptfsOuterStatsSaEntry ::= SEQUENCE {
        iptfsOuterSaIndex               Integer32,

     -- Статистика для пакетов iptfs
        txExtraPadPkts             Counter64,
        txExtraPadOctets           Counter64,
        txAllPadPkts               Counter64,
        txAllPadOctets             Counter64,
        rxExtraPadPkts             Counter64,
        rxExtraPadOctets           Counter64,
        rxAllPadPkts               Counter64,
        rxAllPadOctets             Counter64,
        rxErroredPkts              Counter64,
        rxMissedPkts               Counter64
       }


      iptfsOuterSaIndex OBJECT-TYPE
         SYNTAX      Integer32 (1..16777215)
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
           "Уникальное значение больше 0 для каждой SA. Рекомендуется
           выделять значения подряд, начиная с 1. Значение для каждой
           записи должно сохраняться при перезагрузке системы управления
           элемента сети."
         ::= { iptfsOuterStatsTableEntry 1 }

      txExtraPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных внешних пакетов IP-TFS с заполнением."
          ::= { iptfsOuterStatsTableEntry 2 }

      txExtraPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число октетов заполнения, добавленных во внешние пакеты
            IP-TFS с данными."
          ::= { iptfsOuterStatsTableEntry 3 }

      txAllPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных пакетов IP-TFS, содержащих лишь заполнение
            (без данных во внутренних пакетах)."
          ::= { iptfsOuterStatsTableEntry 4 }

      txAllPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число переданных октетов заполнения в пакетах IP-TFS без
            данных во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 5 }

      rxExtraPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением."
          ::= { iptfsOuterStatsTableEntry 6 }

      rxExtraPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением и
            данными во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 7 }

      rxAllPadPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных внешних пакетов IP-TFS с заполнением
            без внутренних пакетов с данными."
          ::= { iptfsOuterStatsTableEntry 8 }

      rxAllPadOctets OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число полученных октетов заполнения в пакетах 
            IP-TFS без данных во внутренних пакетах."
          ::= { iptfsOuterStatsTableEntry 9 }

      rxErroredPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число внешних пакетов IP-TFS, отброшенных из-за ошибок."
          ::= { iptfsOuterStatsTableEntry 10 }

      rxMissedPkts OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
            "Число пропущенных внешних пакетов IP-TFS, указанных
            пропусками порядковых номеров."
          ::= { iptfsOuterStatsTableEntry 11 }

   --
   -- Соответствие модуля iptfs 
   --

   iptfsMIBConformances OBJECT IDENTIFIER
                       ::= { iptfsMIBConformance 1 }

   iptfsMIBGroups OBJECT IDENTIFIER
                       ::= { iptfsMIBConformance 2 }

   iptfsMIBCompliance MODULE-COMPLIANCE
           STATUS  current
           DESCRIPTION
                   "Заявление о соответствии для объектов,
                   реализующих IP-TFS MIB."
           MODULE  -- this module
                   MANDATORY-GROUPS {
                    iptfsMIBConfGroup,
                    ipsecStatsConfGroup,
                    iptfsInnerStatsConfGroup,
                    iptfsOuterStatsConfGroup
                   }

           ::= { iptfsMIBConformances 1 }

   --
   -- Группы MIB (блоки соответствия)
   --

   iptfsMIBConfGroup OBJECT-GROUP
           OBJECTS {
                   congestionControl,
                   usePathMtuDiscovery,
                   outerPacketSize ,
                   l2FixedRate ,
                   l3FixedRate ,
                   dontFragment,
                   maxAggregationTime,
                   windowSize,
                   sendImmediately,
                   lostPacketTimerInterval
           }
           STATUS  current
           DESCRIPTION
                   "Набор объектов, предоставляемых на уровне 
                   конфигурации IP-TFS SA."
           ::= { iptfsMIBGroups 1 }

   ipsecStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txPkts,
                   txOctets,
                   txDropPkts,
                   rxPkts,
                   rxOctets,
                   rxDropPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих базовую статистику по SA."
           ::= { iptfsMIBGroups 2 }

   iptfsInnerStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txInnerPkts,
                   txInnerOctets,
                   rxInnerPkts,
                   rxInnerOctets,
                   rxIncompleteInnerPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих статистику внутренних 
             пакетов IP-TFS по SA."
           ::= { iptfsMIBGroups 3 }


   iptfsOuterStatsConfGroup OBJECT-GROUP
           OBJECTS {
                   txExtraPadPkts,
                   txExtraPadOctets,
                   txAllPadPkts,
                   txAllPadOctets,
                   rxExtraPadPkts,
                   rxExtraPadOctets,
                   rxAllPadPkts,
                   rxAllPadOctets,
                   rxErroredPkts,
                   rxMissedPkts
           }
           STATUS  current
           DESCRIPTION
             "Набор объектов, обеспечивающих статистику внешних 
             пакетов IP-TFS по SA."
             "A collection of objects providing per SA IP-TFS
             outer packet statistics."
           ::= { iptfsMIBGroups 4 }

   END
   <CODE ENDS>

5. Взаимодействие с IANA

Описанный здесь модуль MIB использует выделенное IANA значение OBJECT IDENTIFIER, внесенное в реестр SMI Network Management MGMT Codes Internet-standard MIB.

Таблица 1.

 

Десятичное значение

Имя

Описание

246

iptfsMIB

IP-TRAFFIC-FLOW-SECURITY-MIB

 

6. Вопросы безопасности

Описанный здесь модуль MIB может считывать данные рабочего поведения IP-TFS. Последствия этого рассмотрены в [RFC9347], где описана функциональность.

В описанном модуле MIB нет объектов управления с MAX-ACCESS read-write или read-create, поэтому при корректной реализации модуля MIB не возникает риска изменения или создания злоумышленником объектов управления в этом модуле MIB с помощью прямых операций SNMP SET.

Некоторые из объектов модуля MIB могут быть чувствительными или уязвимыми в отдельных сетевых средах. К таким относятся объекты INDEX с MAX-ACCESS not-accessible и другие индексы из других модулей, раскрываемые через AUGMENT. Важно контролировать доступ к этим объектам даже с помощью GET или NOTIFY и может быть даже шифровать значения объектов при передаче через сеть по протоколу SNMP. Такие таблицы и объекты указаны ниже.

  • iptfsInnerStatsTable и iptfsOuterStatsTable. Доступ к статистике внутренних или внешних пакетов IP-TFS может раскрывать сведения, которые IP-TFS желает скрыть, такие как активность потоков, применяющих IP-TFS.

Версии SNMP до SNMPv3 не обеспечивали должной защиты. Даже в защищённой сети (например, использующей IPsec) не контролируется доступ и операции GET (чтение) для объектов этого модуля MIB.

Реализациям следует обеспечивать функции защиты, описанные в SNMPv3 [RFC3410], а реализации, заявляющие соответствие стандарту SNMPv3, должны включать полную поддержку аутентификации и конфиденциальности с использованием модели защиты по пользователям (User-based Security Model или USM) [RFC3414] с алгоритмом шифрования AES [RFC3826].Реализации могут также поддерживать модель транспортной защиты (Transport Security Model или TSM) [RFC5591] в сочетании с защищённым транспортом, таким как SSH [RFC5592] или TLS/DTLS [RFC6353].

Кроме того, развёртывание версий SNMP до SNMPv3 не рекомендуется. Взамен рекомендуется разворачивать SNMPv3 и включать криптографическую защиту. В дальнейшем клиент (оператор) отвечает за корректную настройку объекта SNMP в части предоставления доступа к экземпляру модуля MIB лишь уполномоченным участникам (пользователям) для выполнения пердусмотренных операций GET или SET (создание, изменение, удаление).

7. Литература

7.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2)”, STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2”, STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <https://www.rfc-editor.org/info/rfc2579>.

[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Conformance Statements for SMIv2”, STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, <https://www.rfc-editor.org/info/rfc2580>.

[RFC3414] Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)”, STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, <https://www.rfc-editor.org/info/rfc3414>.

[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, “The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model”, RFC 3826, DOI 10.17487/RFC3826, June 2004, <https://www.rfc-editor.org/info/rfc3826>.

[RFC5591] Harrington, D. and W. Hardaker, “Transport Security Model for the Simple Network Management Protocol (SNMP)”, STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, <https://www.rfc-editor.org/info/rfc5591>.

[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, “Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)”, RFC 5592, DOI 10.17487/RFC5592, June 2009, <https://www.rfc-editor.org/info/rfc5592>.

[RFC6353] Hardaker, W., “Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)”, STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <https://www.rfc-editor.org/info/rfc6353>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9347] Hopps, C., “Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)”, RFC 9347, DOI 10.17487/RFC9347, January 2023, <https://www.rfc-editor.org/info/rfc9347>.

7.2. Дополнительная литература

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework”, RFC 3410, DOI 10.17487/RFC3410, December 2002, <https://www.rfc-editor.org/info/rfc3410>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC9348] Fedyk, D. and C. Hopps, “A YANG Data Model for IP Traffic Flow Security”, RFC 9348, DOI 10.17487/RFC9348, January 2023, <https://www.rfc-editor.org/info/rfc9348>.

Благодарности

Авторы благодарны Chris Hopps, Lou Berger, Tero Kivinen за помощь и отклики на модель MIB.

Адреса авторов

Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
 
Eric Kinzie
LabN Consulting, L.L.C.
Email: ekinzie@labn.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC, Безопасность, Мониторинг и управление | Оставить комментарий

RFC 9348 A YANG Data Model for IP Traffic Flow Security

Internet Engineering Task Force (IETF)                          D. Fedyk
Request for Comments: 9348                                      C. Hopps
Category: Standards Track                        LabN Consulting, L.L.C.
ISSN: 2070-1721                                             January 2023

A YANG Data Model for IP Traffic Flow Security

Модель данных YANG для IP Traffic Flow Security

PDF

Аннотация

Этот документ описывает модуль YANG для управления дополнениями IP Traffic Flow Security (IP-TFS) для протокола обмена ключами версии 2 (Internet Key Exchange Protocol version 2 или IKEv2) и IPsec.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9348.

Авторские права

Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Этот документ определяет модуль YANG [RFC7950] для управления расширениями IP Traffic Flow Security (IP-TFS), заданными в [RFC9347]. IP-TFS совершенствует защищённые связи (Security Association или SA) через туннели IPsec для усиления конфиденциальности трафика. Конфиденциальность трафика сокращает возможности его анализа для отождествления и сопоставления наблюдаемых картин трафика. IP-TFS обеспечивает эффективность путём агрегирования трафика в туннельные пакеты IPsec с фиксированным размером.

Модель YANG в этом документе соответствует архитектуре хранилищ данных сетевого управления (Network Management Datastore Architecture или NMDA), заданной в [RFC8342].

Опубликованные модули YANG для IPsec заданы в [RFC9061]. Данный документ использует эти модели в качестве базы для IPsec, которая дополняется для IP-TFS. Модель [RFC9061] поддерживает работу с IKE и без IKE.

2. Обзор

Этот документ определяет конфигурационные и рабочие параметры IP-TFS. Расширение IP-TFS, заданное в [RFC9347], определяет защищённые связи для туннельного режима IPsec с характеристиками, усиливающими конфиденциальность трафика и сокращающими снижение потерь пропускной способности. Документы предполагают знакомство читателя с концепциями IPsec, описанными в [RFC4301].

IP-TFS использует туннельный режим для усиления конфиденциальности за счёт сокрытия идентифицируемой информации, размера и времени пакетов. IP-TFS предоставляет базовую возможность агрегирования нескольких пакетов в туннельные пакеты IPsec одинакового размера. Размер внешних пакетов поддерживается за счёт сочетания агрегирования, заполнения и фрагментации внутренних пакетов с целью заполнения внешнего пакета IPsec. Заполнение применяется при отсутствии данных для передачи.

Этот документ задаёт расширяемую модель конфигурации для IP-TFS. Эта версия использует возможности IP-TFS для настройки фиксированного размера пакетов IP-TFS, передаваемых с постоянной скоростью. Модель структурирована для поддержки разных типов операций с помощью будущих дополнений.

Модуль YANG IP-TFS дополняет модуль YANG IPsec из [RFC9061]. IP-TFS использует туннельный режим IPsec и добавляет несколько элементов настройки туннелей IPsec. Как указано в [RFC9347], любая ассоциация SA, настроенная на использование IP-TFS, поддерживает только пакеты IP-TFS (не работает в смешанных режимах IPsec).

Поведение IP-TFS контролируется источником пакетов. Самоописывающий формат пакетов IP-TFS позволяет передающей стороне настраивать размер и время передачи пакетов независимо от получателей. Оба направления трафика независимы, т. е. IP-TFS можно использовать даже в одном направлении. Это означает, что счётчики, заданные здесь для обоих направлений, могут иметь значение 0 или не обновляться, если SA использует IP-TFS лишь в одном направлении.

Ниже указаны случаи, где статистика IP-TFS активна в одном направлении:

  • односторонняя SA при включённом IP-TFS;

  • двухсторонняя SA с IP-TFS лишь для одного направления.

Статистика IP-TFS доступна для обоих направлений при двухсторонней SA и IP-TFS для обоих направлений.

Модель IP-TFS поддерживает конфигурационные и операционные данные IP-TFS.

Этот модуль YANG поддерживает конфигурацию с фиксированным размером и скоростью пакетов, а также элементы, которые могут быть добавлены для поддержки будущих конфигураций. Спецификация протокола [RFC9347] выходит за рамки этого простого, фиксированного режима работы, задавая базовый формат для любого типа схемы. В этом документе внешние пакеты IPsec могут передаваться с фиксированным или переменным размером (без заполнения). Конфигурация позволяет определять фиксированный размер пакетов на основании MTU для пути. Фиксированный размер пакетов можно также задать в конфигурации, если нужно значение меньше MTU для пути.

Другие элементы конфигурации указаны ниже.

Контроль перегрузки

Настройки контроля перегрузки, позволяющие IP-TFS снижать скорость пакетов при возникновении перегрузки.

Настройка фиксированной скорости

Скорость туннеля IP-TFS может настраиваться с учётом издержек уровня L2 или L3. Издержками L3 является скорость данных IP, а издержками L2 является битовая скорость в канале. Сочетание размера пакетов и скорости определяет номинальную максимальную пропускную способность и интервал передачи при использовании пакетов фиксированного размера.

Пользовательский контроль фрагментации пакетов

Хотя фрагментация рекомендуется для повышения эффективности, возможна её настройка, если пользователи хотят видеть влияние отказа от фрагментации на свои потоки данных.

Рабочие данные YANG позволяют считывать параметры конфигурации, а также статистику на уровне SA и счётчики ошибок для IP-TFS. Статистика пакетов IPsec на уровне SA обеспечивается как свойство, а статистика IP-TFS на уровне SA – как другое свойство. Оба набора статистики дополняют модули YANG IPsec счётчиками, которые позволяют наблюдать эффективность пакетов IP-TFS.

Объекты управления YANG IPsec заданы в [RFC9061]. YANG IP-TFS дополняет модели IKE и без IKE. В этих моделях запись базы данных правил безопасности (Security Policy) и запись SA для туннеля IPsec могут дополняться IP-TFS. Кроме того, эта модель YANG использует типы, определённые в [RFC6991].

3. Управление YANG

3.1. Дерево YANG

Ниже представлено дерево YANG [RFC8340] для расширений IP-TFS.

   module: ietf-ipsec-iptfs
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd
               /nsfike:spd-entry/nsfike:ipsec-policy-config
               /nsfike:processing-info/nsfike:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:spd/nsfikels:spd-entry
               /nsfikels:ipsec-policy-config/nsfikels:processing-info
               /nsfikels:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64

3.2. Модуль YANG

Ниже представлен модуль YANG для управления расширениями IP-TFS. Эта модель ссылается на [RFC9347] и [RFC5348].

   <CODE BEGINS> file "ietf-ipsec-iptfs@2023-01-31.yang"
   module ietf-ipsec-iptfs {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs";
     prefix iptfs;

     import ietf-i2nsf-ike {
       prefix nsfike;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.2";
     }
     import ietf-i2nsf-ikeless {
       prefix nsfikels;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.3";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     organization
       "IETF IPSECME Working Group (IPSECME)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/ipsecme/> 
        WG List: <mailto:ipsecme@ietf.org> 

        Author: Don Fedyk
                <mailto:dfedyk@labn.net> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org>"; 

     description
       "Этот модуль задаёт конфигурацию и рабочее состояние для 
        управления функциональностью IP-TFS (RFC 9348).

        Авторские права (Copyright (c) 2023) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9348, где правовые
        аспекты приведены более полно.";

     revision 2023-01-31 {
       description
         "Исходный выпуск";
       reference
         "RFC 9348: A YANG Data Model for IP Traffic Flow Security";
     }

     feature ipsec-stats {
       description
         "Указывает поддержку устройством статистики для IPsec SA.";
     }

     feature iptfs-stats {
       description
         "Указывает поддержку устройством статистики IP TFS для SA.";
     }

     /*--------------------*/
     /*   Группировки      */
     /*--------------------*/

     grouping ipsec-tx-stat-grouping {
       description
         "Выходная статистика IPsec";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик выходных пакетов";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в выходных пакетах";
       }
       leaf tx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных выходных пакетов";
       }
     }

     grouping ipsec-rx-stat-grouping {
       description
         "Входная статистика IPsec";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик входных пакетов";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в входных пакетах";
       }
       leaf rx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных входных пакетов";
       }
     }

     grouping iptfs-inner-tx-stat-grouping {
       description
         "Статистика вложенных выходных пакетов IP-TFS";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных пакетов IP-TFS. Учитываются
            только целые пакеты, все фрагменты пакета считаются за 1.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных октетов IP-TFS. Заполнение
            не учитывается.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-tx-stat-grouping {
       description
         "Статистика выходных вложенных пакетов IP-TFS.";
       leaf tx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных пакетов IP-TFS, содержавших только
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения в пакетах IP-TFS
            без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных внешних пакетов IP-TFS, содержащих
            заполнение.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf tx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения, добавленных во
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
     }

     grouping iptfs-inner-rx-stat-grouping {
       description
         "Входная статистика вложенных пакетов IP-TFS";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных вложенных пакетов IP-TFS.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число принятых вложенных октетов IP-TFS без учёта
            заполнения и издержек.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-incomplete-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число неполных вложенных пакетов IP-TFS. Обычно это
            возникает в результате пропуска фрагментов и может быть
            следствием нарушения порядка или ошибок в полученных внешних
            пакетах.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-rx-stat-grouping {
       description
         "Входная статистика внешних пакетов IP-TFS";
       leaf rx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных пакетов IP-TFS, содержащих лишь
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных 
            в пакеты IP-TFS без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число принятых внешних пакетов IP-TFS с заполнением.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных во 
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-errored-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число внешних пакетов IP-TFS, отброшенных из-за 
            ошибок.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf rx-missed-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число отсутствующих внешних пакетов IP-TFS, указанное
            отсутствующим порядковым номером.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-config {
       description
         "Группировка для конфигурации IP-TFS.";
       container traffic-flow-security {
         description
           "Настраивает IPsec TFS в базе SAD.";
         leaf congestion-control {
           type boolean;
           default "true";
           description
             "Принятое по умолчанию значение true включает обмен данными
              о перегрузке в линии, которые нужны алгоритмам контроля
              перегрузок, как указано в RFC 5348. При установке false 
              IP-TFS передаёт пакеты фиксированного размера через 
              туннель IP-TFS с постоянной скоростью.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.4.2;
              RFC 5348: TCP Friendly Rate Control (TFRC): Protocol
              Specification";
         }
         container packet-size {
           description
             "Размер пакетов задаётся вручную или определяется
              автоматически.";
           leaf use-path-mtu-discovery {
             type boolean;
             default "true";
             description
               "Применяется определение MTU на пути для задания 
                максимального размера пакетов IP-TFS. Если размер задан
                явно, при установке use-path-mtu-discovery он может лишь
                сокращаться.";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
           leaf outer-packet-size {
             type uint16;
             units "bytes";
             description
               "Размер внешнего инкапсулирующего пакета при передаче
                (т. е. пакета IP с содержимым ESP).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
         }
         choice tunnel-rate {
           description
             "Битовая скорость TFS может быть задана скоростью линии L2
              или скоростью пакетов L3.";
           leaf l2-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
           leaf l3-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
         }
         leaf dont-fragment {
           type boolean;
           default "false";
           description
             "При передаче отключает фрагментацию между 
              последовательными пакетами туннеля IP-TFS. Внутренние 
              пакеты, не помещающиеся во внешний пакет, отбрасываются.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.4 and
              6.1.4";
         }
         leaf max-aggregation-time {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При передаче максимальным временем агрегирования является
              максимальное время удержания полученного внутреннего 
              пакета до передачи в туннеле IP-TFS. Внутренние пакеты,
              которые удерживаются дольше этого времени, исходя из
              текущей конфигурации, будут отбрасываться вместо включения
              в очередь передачи. Максимальное время агрегирования 
              задаётся в миллисекундах или долях миллисекунды вплоть
              до 1 наносекунды.";
         }
         leaf window-size {
           type uint16 {
             range "0..65535";
           }
           description
             "Максимальное число полученных с нарушением порядка пакетов,
              для которых получатель IP-TFS будет восстанавливать порядок.
              Значение 0 отключает восстановление порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
         leaf send-immediately {
           type boolean;
           default "false";
           description
             "Задаёт максимально быструю отправку пакетов при получении 
              без ожидания потерянных и разупорядоченных внешних пакетов.
              Выбор этой опции сокращает задержку вложенных 
              (пользовательских) пакетов, но усиливает нарушение порядка
              доставки потока вложенных пакетов при наличии 
              агрегирования или нарушения порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.5";
         }
         leaf lost-packet-timer-interval {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При получении задаёт время ожидания получателем IP-TFS
              пропущенного пакета, прежде чем счесть его потерянным.
              Если не задан лист send-immediately, каждый потерянный
              пакет будет задерживать внутренние (пользовательские)
              пакеты, пока не наступит этот тайм-аут. Установка слишком
              малого значения может влиять на восстановление порядка и
              сборку. Значение задаётся в миллисекундах или долях 
              миллисекунды вплоть до 1 наносекунды.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
       }
     }

     /*
      * Крнфигурация IP-TFS IKE
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/"
           + "nsfike:spd-entry/"
           + "nsfike:ipsec-policy-config/"
           + "nsfike:processing-info/"
           + "nsfike:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Конфигурация IP-TFS без IKE
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:spd/"
           + "nsfikels:spd-entry/"
           + "nsfikels:ipsec-policy-config/"
           + "nsfikels:processing-info/"
           + "nsfikels:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }
   }
   <CODE ENDS>

4. Взаимодействие с IANA

4.1. Обновление реестра IETF XML

В соответствии с этим документом агентство IANA зарегистрировало URI в реестре IETF XML Registry [RFC3688]

   URI:  urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

4.2. Обновление реестра YANG Module Names

В соответствии с этим документом агентство IANA зарегистрировало модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-ipsec-iptfs
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs
   Prefix:  iptfs
   Reference:  RFC 9348

5. Вопросы безопасности

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

../traffic-flow-security

Включение IP-TFS контролируется установкой записей в ветви traffic-flow-security моделей с IKE или без IKE. Параметры в этом дереве устанавливаются для IP-TFS чувствительность к перегрузкам или фиксированную скорость.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

../iptfs-inner-pkt-stats и ../iptfs-outer-pkt-stats

Доступ к статистике IP-TFS даёт сведения о событиях IP-TFS, таких как корректная работа потоков IP-TFS.

6. Литература

6.1. Нормативные документы

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, “A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)”, RFC 9061, DOI 10.17487/RFC9061, July 2021, <https://www.rfc-editor.org/info/rfc9061>.

[RFC9347] Hopps, C., “Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)”, RFC 9347, DOI 10.17487/RFC9347, January 2023, <https://www.rfc-editor.org/info/rfc9347>.

6.2. Дополнительная литература

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

Приложение A. Примеры

Ниже приведены примеры данных конфигурации и рабочего состояния для вариантов использования с IKE и без IKE в формате XML и JSON. Показана также операционная статистика для варианта без IKE.

A.1. Конфигурация XML

Этот пример показывает конфигурацию IP-TFS для варианта без IKE. Отметим, что это дополняет схему для IPsec без IKE, поэтому задана лишь минимальная конфигурация для схемы без IKE.

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:spd>
       <i:spd-entry>
         <i:name>protect-policy-1</i:name>
         <i:direction>outbound</i:direction>
         <i:ipsec-policy-config>
           <i:traffic-selector>
             <i:local-prefix>192.0.2.0/16</i:local-prefix>
             <i:remote-prefix>198.51.100.0/16</i:remote-prefix>
           </i:traffic-selector>
           <i:processing-info>
             <i:action>protect</i:action>
             <i:ipsec-sa-cfg>
               <tfs:traffic-flow-security>
                <tfs:congestion-control>true</tfs:congestion-control>
                 <tfs:packet-size>
                   <tfs:use-path-mtu-discovery
                      >true</tfs:use-path-mtu-discovery>
                 </tfs:packet-size>
                 <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
                 <tfs:max-aggregation-time
                    >0.1</tfs:max-aggregation-time>
                 <tfs:window-size>5</tfs:window-size>
                 <tfs:send-immediately>false</tfs:send-immediately>
                 <tfs:lost-packet-timer-interval
                    >0.2</tfs:lost-packet-timer-interval>
               </tfs:traffic-flow-security>
             </i:ipsec-sa-cfg>
           </i:processing-info>
         </i:ipsec-policy-config>
       </i:spd-entry>
     </i:spd>
   </i:ipsec-ikeless>

Рисунок 1. Пример конфигурации IP-TFS XML.

A.2. Рабочие данные XML

Этот пример показывает рабочие данные для варианта IP-TFS без IKE. Отметим, что это дополняет схему для IPsec без IKE, поэтому задана лишь минимальная конфигурация для схемы без IKE.

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:sad>
       <i:sad-entry>
         <i:name>sad-1</i:name>
         <i:ipsec-sa-config>
           <i:spi>1</i:spi>
           <i:traffic-selector>
             <i:local-prefix>2001:db8:1::/48</i:local-prefix>
             <i:remote-prefix>2001:db8:2::/48</i:remote-prefix>
           </i:traffic-selector>
         </i:ipsec-sa-config>
         <tfs:traffic-flow-security>
           <tfs:congestion-control>true</tfs:congestion-control>
           <tfs:packet-size>
             <tfs:use-path-mtu-discovery
               >true</tfs:use-path-mtu-discovery>
           </tfs:packet-size>
           <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
           <tfs:max-aggregation-time>0.100</tfs:max-aggregation-time>
           <tfs:window-size>0</tfs:window-size>
           <tfs:send-immediately>true</tfs:send-immediately>
           <tfs:lost-packet-timer-interval
             >0.200</tfs:lost-packet-timer-interval>
         </tfs:traffic-flow-security>
       </i:sad-entry>
     </i:sad>
   </i:ipsec-ikeless>

Рисунок 2. Пример рабочих данных IP-TFS XML.

A.3. Конфигурация JSON

Этот пример показывает данные конфигурации для IP-TFS с IKE. Отметим, что это дополняет схему IPsec IKE, , поэтому задана лишь минимальная конфигурация для схемы с IKE.

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
             {
               "id": 1,
               "algorithm-type": 12,
               "key-length": 128
             }
             ],
             "local": {
               "local-pad-entry-name": "local-1"
             },
             "remote": {
               "remote-pad-entry-name": "remote-1"
             },
             "ietf-i2nsf-ike:spd": {
             "spd-entry": [
               {
                 "name": "protect-policy-1",
                 "ipsec-policy-config": {
                   "traffic-selector": {
                     "local-prefix": "192.0.2.0/16",
                     "remote-prefix": "198.51.100.0/16"
                   },
                   "processing-info": {
                     "action": "protect",
                     "ipsec-sa-cfg": {
                       "ietf-ipsec-iptfs:traffic-flow-security": {
                         "congestion-control": true,
                         "l2-fixed-rate": "1000000000",
                         "packet-size": {
                           "use-path-mtu-discovery": true
                         },
                         "max-aggregation-time": "0.1",
                         "window-size": 1,
                         "send-immediately": false,
                         "lost-packet-timer-interval": "0.2"
                       }
                     }
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 3. Пример конфигурации IP-TFS JSON.

A.4. Рабочие данные JSON

Этот пример показывает рабочие данные для варианта IP-TFS с IKE. Отметим, что это дополняет схему IPsec IKE, , поэтому задана лишь минимальная конфигурация для схемы с IKE.

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
           {
             "id": 1,
             "algorithm-type": 12,
             "key-length": 128
           }
           ],
           "local": {
             "local-pad-entry-name": "local-1"
           },
           "remote": {
             "remote-pad-entry-name": "remote-1"
           },
           "ietf-i2nsf-ike:child-sa-info": {
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "congestion-control": true,
               "l2-fixed-rate": "1000000000",
               "packet-size": {
                 "use-path-mtu-discovery": true
               },
               "max-aggregation-time": "0.1",
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             }
           }
         }
       ]
     }
   }

Рисунок 4. Пример операционных данных IP-TFS JSON.

A.5. Операционная статистика JSON

Этот пример показывает статистику IP-TFS в формате JSON. Отметим, что показана передающая сторона двухстороннего IP-TFS в произвольными номерами при передаче.

   {
     "ietf-i2nsf-ikeless:ipsec-ikeless": {
       "sad": {
         "sad-entry": [
           {
             "name": "sad-1",
             "ipsec-sa-config": {
               "spi": 1,
               "traffic-selector": {
                 "local-prefix": "192.0.2.1/16",
                 "remote-prefix": "198.51.100.0/16"
               }
             },
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             },
             "ietf-ipsec-iptfs:ipsec-stats": {
               "tx-pkts": "300",
               "tx-octets": "80000",
               "tx-drop-pkts": "2",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-drop-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-inner-pkt-stats": {
               "tx-pkts": "250",
               "tx-octets": "75000",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-incomplete-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-outer-pkt-stats": {
               "tx-all-pad-pkts": "40",
               "tx-all-pad-octets": "40000",
               "tx-extra-pad-pkts": "200",
               "tx-extra-pad-octets": "30000",
               "rx-all-pad-pkts": "0",
               "rx-all-pad-octets": "0",
               "rx-extra-pad-pkts": "0",
               "rx-extra-pad-octets": "0",
               "rx-errored-pkts": "0",
               "rx-missed-pkts": "0"
             },
             "ipsec-sa-state": {
               "sa-lifetime-current": {
                 "time": 80000,
                 "bytes": "400606",
                 "packets": 1000,
                 "idle": 5
               }
             }
           }
         ]
       }
     }
   }

Рисунок 5. Пример статистики IP-TFS JSON.

Благодарности

Авторы благодарны Eric Kinzie, Jürgen Schönwälder, Lou Berger, Tero Kivinen за отклики и рецензии на модуль YANG.

Адреса авторов

Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
 
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий