RFC 9407 Tetrys: An On-the-Fly Network Coding Protocol

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

Internet Research Task Force (IRTF)                          J. Detchart
Request for Comments: 9407                                  ISAE-SUPAERO
Category: Experimental                                         E. Lochin
ISSN: 2070-1721                                                     ENAC
                                                                J. Lacan
                                                            ISAE-SUPAERO
                                                                 V. Roca
                                                                   INRIA
                                                               June 2023

Tetrys: An On-the-Fly Network Coding Protocol

Tetrys – протокол сетевого кодирования «на лету»

PDF

Аннотация

Этот документ описывает Tetrys – протокол сетевого кодирования «на лету» (on-the-fly), который можно применять для чувствительной к задержкам и потерям доставки через сеть с потерями. Tetrys может восстанавливаться после удаления данных с независимой от RTT задержкой, благодаря передаче кодированных пакетов. Этот документ представляет отчёт о результатах, полученных автором в процессе разработки и тестирования протокола Tetrys в реальных условиях.

Документ является результатом исследовательской группы NWCRG¹ и соответствует таксономии NWCRG, описанной в RFC 8406.

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

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

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

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

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

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

1. Введение

Этот документ является результатом работы исследовательской группы NWCRG и выражает её согласованное мнение. Документ не является результатом или стандартом IETF.

Документ описывает протокол Tetrys выполняющий сетевое кодирование на лету, который может служить для доставки чувствительных к задержкам и потерям данных через сеть с потерями. Сетевые коды появились в начале 2000-х гг. [AHL-00] и служили для снятия ограничений при передаче через Internet (задержки, пропускная способность, потери пакетов). Хотя сетевые коды получили сравнительно малое распространение в сообществе Internet, использование кодов удаления на уровне приложений уже стандартизовано в рамках IETF рабочими группами RMT [RFC5052] [RFC5445] и FECFRAME [RFC8680]. Представленный здесь протокол можно считать расширением сетевого кодирования на стандартные протоколы индивидуального (unicast) транспорта, а в некоторых случаях также группового и anycast. Текущее предложение можно рассматривать как комбинацию сетевого кодирования стирания и механизмов обратной связи [Tetrys] [Tetrys-RT].

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

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

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

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

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

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

2. Определения, обозначения и сокращения

Используемые в документе обозначения основаны на таксономии NWCRG [RFC8406].

Source Symbol – символ источника

Символ, переносимый между входом и выходом сети.

Coded Symbol – кодированный символ

Линейная комбинация над конечным полем набора символов источника.

Source Symbol ID – идентификатор символа источника

Порядковый номер для идентификации символов источника.

Coded Symbol ID – идентификатор кодированного символа

Порядковый номер для идентификации кодированных символов.

Encoding Coefficients – коэффициенты кодирования

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

Encoding Vector – вектор кодирования

Набор коэффициентов кодирования и идентификаторов входных символов источника.

Source Packet – пакет источника

Пакет источника содержит символы источника с их идентификаторами.

Coded Packet – кодированный пакет

Кодированный пакет содержит кодированные символы, их идентификаторы и вектор кодирования.

Input Symbol – входной символ

Символ на входе кодировщика Tetrys.

Output Symbol – выходной символ

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

Feedback Packet – пакет обратной связи

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

Elastic Encoding Window – эластичное окно кодирования

Буфер на стороне кодера, где хранятся все неподтвержденные пакеты источника из входного потока, вовлечённого в процесс кодировани.

Coding Coefficient Generator Identifier (CCGI) – идентификатор генератора коэффициентов кодирования

Уникальный идентификатор, который указывает функцию или алгоритм, разрешающие генерацию вектора кодирования.

Code Rate – степень кодирования

Отношение между числом входных и выходных символов.

3. Архитектура

3.1. Применение

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

3.2. Обзор

+----------+                +----------+
|          |                |          |
|Приложение|                |Приложение|
|          |                |          |
+----------+                +----------+
      |                           ^
      |  Символы          Символы |
      |  источника      источника |
      |                           |
      v                           |
+----------+                +----------+
|          | Выходные пакеты|          |
|  Кодер   |--------------->| Декодер  |
|  Tetrys  | Пакеты откликов| Tetrys   |
|          |<---------------|          |
+----------+                +----------+

Рисунок . Архитектура Tetrys.

Протокол Tetrys обладает несколькими важными функциональными возможностями. Обязательные функции включают:

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

Необязательные функции включают:

оценку канала;
динамическую подстройку степени кодирования (code rate) и управление потоком данных;
управление контролем перегрузок, когда это приемлемо ().

Функциональность обеспечивается несколькими основными блоками.

Tetrys Building Block – блок Tetrys

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

Window Management Building Block – блок управления окном

Управляет окном кодирования у отправителя Tetrys.

Для упрощения добавления новых компонентов и служб в Tetrys включён механизм расширения заголовка, совместимый с транспортом многоуровневого кодирования (Layered Coding Transport или LCT) [RFC5651], ориентированной на негативные подтверждения надёжной групповой передачей (NACK-Oriented Reliable Multicast или NORM) [RFC5740] и моделью упреждающей коррекции ошибок (FEC Framework или FECFRAME) [RFC8680].

4. Базовые функции Tetrys

4.1. Кодирование

В начале передачи кодер Tetrys должен выбрать степень кодирования (code rate) для добавления избыточности, поскольку он не знает частоту потери пакетов в канале. В установившемся состоянии кодер Tetrys может генерировать кодированные символы при получении символов источника от приложения или какого-либо отклика от блоков декодирования в зависимости от степени кодирования.

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

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

4.2. Эластичное окно кодирования

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

Как разъяснено ниже, декодер Tetrys периодически передаёт отклики, указывающие принятые или декодированные символы источника. При получении отправителем сведений о приёме или декодировании получателем символа источника он удаляет этот символ из окна кодирования.

4.3. Декодирование

Для восстановления удалённого символа источника достаточно стандартного исключения по Гауссу, когда это позволяет ранг матрицы.

5. Формат пакетов

5.1. Формат базового заголовка

Все пакеты Tetrys используют общий формат базового заголовка ().

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   V   | C |S|     Reserved    |   HDR_LEN     |    PKT_TYPE   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Congestion Control Information (CCI, размер = 32*C битов)   |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Transport Session Identifier (TSI, размер = 32*S битов)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Расширения заголовка (если применимо)             |
|                          ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Как отмечено выше, этот формат наследуется из формата заголовка LCT [RFC5651] с незначительными изменениями.

Номер версии Tetrys (V) – 4 бита

Указывает номер версии протокола Tetrys. Эта спецификация Tetrys задаёт версию 1.

Флаг контроля перегрузок (C) – 2 бита

Значение C = 0b00 указывает, что поле сведений контроля перегрузки (Congestion Control Information или CCI) имеет размер 0. C = 0b01 указывает, что поле CCI имеет размер 32 бита, C = 0b10 указывает CCI размером 64 бита, а C = 0b11 – 96 битов.

Флаг идентификатора транспортной сессии (S) – 1 бит

Число полных 32-битовых слов в поле TSI (0 или 1).

Reserved (Resv) – 9 битов

резервные биты, которые отправитель должен сбрасывать (0), а получатель должен игнорировать.

Размер заголовка (HDR_LEN) – 8 битов

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

Тип пакета Tetrys (PKT_TYPE) – 8 битов

Имеется 3 типа пакетов – PKT_TYPE_SOURCE (0b00), параграф 5.2, PKT_TYPE_CODED (0b01), параграф 5.3, и PKT_TYPE_WND_UPT (0b11) для пакетов обновления окна, параграф 5.4.

Congestion Control Information – сведения контроля перегрузки (CCI) – 0, 32, 64 или 96 битов

Служит для передачи сведения о контроле перегрузки и может включать, например, номера уровней, логических каналов и порядковые номера. Данная спецификация не задаёт обработку этого поля (opaque). Поле должно отсутствовать (о битов) при C = 0b00 и должно занимать 32 бита при C = 0b01, 64 – при C = 0b10, 96 – при C = 0b11.

Transport Session Identifier – идентификатор транспортной сессии (TSI) – 0 или 32 бита

TSI однозначно указывает сессию среди имеющихся с конкретным кодером Tetrys. Область действия TSI определяется IP-адресом отправителя, поэтому адрес отправителя и TSI совместно указывают сессию однозначно. Хотя TSI всегда однозначно указывает сессию совместно с IP-адресом отправителя, включение TSI в заголовок Tetrys зависит от того, что применяется в качестве значения TSI. Если базовым транспортом служит UDP, вместо TSI для сессии может служить 16-битовый номер порта UDP у отправителя. Если сетевой транспорт или иной уровень не задаёт базовый идентификатор TSI, значение TSI должно включаться в заголовок Tetrys.

5.1.1. Расширения заголовка

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

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

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

Первый формат служит для расширений переменного размера с типами расширения заголовка (header extension type или HET) от 0 до 127.
Второй тип служит для расширений фиксированного размера (1 слово в 32 бита), использующих HET от 128 до 255.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  HET (<=127)  |       HEL     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
.                                                               .
.              Header Extension Content (HEC)                   .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  HET (>=128)  |       Header Extension Content (HEC)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Тип расширения заголовка (HET) – 8 битов

Этот документ задаёт несколько возможных типов, а новые типы могут вноситься будущими версиями спецификации. Значения HET от 0 до 127 служат для расширений заголовка с переменным размером, от 128 до 255 – для расширений заголовка размером 32 бита.

Размер расширения заголовка (HEL) – 8 битов

Число 32-битовых слов в расширении заголовка. Это поле должно присутствовать в расширениях переменного размера (HET от 0 до 127) и его недопустимо включать в расширения фиксированного размера (HET от 128 до 255).

Header Extension Content – содержимое расширения заголовка (HEC) – переменный размер

Содержимое расширения заголовка, формат которого зависит от типа расширения. Для расширений заголовка с фиксированным размером HEC = 24, для расширений переменного размера значение HEC указывает переменный размер, как задано полем HEL. Отметим, что размер расширения заголовка должен быть кратным 32 битам. Общий размер заголовка Tetrys, включая заголовок расширения и его необязательные поля, не может превышать 255 (32-битовых слов).

5.2. Формат пакета источника

Пакет источника содержит базовый заголовок, идентификатор символа источника и сам символ (payload), который может иметь переменный размер.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Source Symbol ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                            Payload                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета источника.

Common Packet Header

Базовый заголовок пакета, где указан тип 0b00.

Source Symbol ID

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

Payload

Содержимое пакет (символ источника).

5.3. Формат кодированного пакета

Кодированный пакет включает базовый заголовок, идентификатор кодированного символа, связанный вектор кодирования и закодированный символ (payload). Поскольку символы источника могут иметь переменный размер, требуется кодировать размеры всех символов источника. Для генерации этих размеров закодированного содержимого в форме 16-битовых значений без знака используется линейная комбинация с теми же коэффициентами, что и для кодируемого содержимого. Результат должен сохраняться в 16-битовом поле кодированного пакета. Поскольку это поле необязательно, вектор кодирования должен указывать его наличие в поле V ().

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Coded Symbol ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                         Encoding Vector                       /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Encoded Payload Size      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
/                            Payload                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Common Packet Header

Базовый заголовок пакета с типом 0b01.

Coded Symbol ID

Порядковый номер для идентификации кодированного символа.

Encoding Vector

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

Encoded Payload Size

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

Payload

Кодированный символ.

5.3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     EV_LEN    |  CCGI | I |C|V|    NB_IDS     |   NB_COEFS    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        FIRST_SOURCE_ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     b_id      |                                               |
+-+-+-+-+-+-+-+-+            id_bit_vector        +-+-+-+-+-+-+-+
|                                                 |   Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          coef_bit_vector        +-+-+-+-+-+-+-+
|                                                 |   Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат вектора кодирования.

Размер вектора кодирования (EV_LEN) – 8 битов

Число 32-битовых слов.

Идентификатор генератора коэффициентов кодирования (CCGI) – 4 бита

Идентификатор для указания алгоритма или функции, применяемой для генерации коэффициентов. Поскольку CCGI включается в каждый кодированный вектор, значение может динамически меняться между генерацией двух кодированных символов. CCGI задают создание коэффициентов для генерации кодированных символов и должны быть известны всем кодерам и декодерам Tetrys. Заданные в этом документе две схемы RLC FEC используют конечные поля, определённые в параграфе 8.1 [RFC5510]. Элементы поля GF(2^(m)) представлены полиномами с двоичными коэффициентами (т. е. над GF(2)) со степенью не выше m-1. Сложение двух элементов определяется как сложение двоичных полиномов в GF(2), которое эквивалентно побитовой операции XOR над двоичными представлениями этих элементов. При GF(2⁽⁸⁾) перемножение двух элементов является умножением по модулю данного неприводимого полинома степени 8. Для GF(2⁽⁸⁾) применяется неприводимый полином

         x⁽⁸⁾ + x⁽⁴⁾ + x⁽³⁾ + x⁽²⁾ + 1

При GF(2⁽⁴⁾) перемножение двух элементов является умножением по модулю данного неприводимого полинома степени . Для GF(2⁽⁴⁾) применяется неприводимый полином

         x⁽⁴⁾ + x + 1

0b00 – коэффициенты Vandermonde над конечным полем GF(2⁽⁴⁾) в виде alpha^{((source_symbol_id*coded-symbol_id) % 16)}, где alpha – корень примитивного полинома;
0b01 – коэффициенты Vandermonde над конечным полем GF(2⁽⁸⁾) в виде alpha^{((source_symbol_id*coded-symbol_id) % 256)}, где alpha – корень примитивного полинома;
Предположим, что нужно создать кодированный символ 2 как линейную комбинацию символов 1, 2 и 4 с использованием CCGI = 0b01. Коэффициентами будут alpha^{((1 * 1) % 256)}, alpha^{((1 * 2) % 256)} и alpha^{((1 * 4) % 256)}.

Формат хранения идентификаторов символов источника (I) – 2 бита

0b00 – нет сведений об идентификаторе символа источника;
0b01 – вектор кодирования содержит граничные блоки идентификаторов символов источника без сжатия;
0b10 – вектор кодирования содержит сжатый список идентификаторов символов источника;
0b11 – вектор кодирования содержит сжатые граничные блоки идентификаторов символов источника.

Хранение коэффициентов кодирования (C) – 1 бит

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

Наличие символов источника с кодированием переменного размера (V)

V = 0b01, если комбинация, указывающая вектор кодирования, содержит символы источника с переменным размером. В этом случае кодированные пакеты должны включать поле Encoded Payload Size.

NB_IDS

Число идентификаторов источника, сохранённых в векторе кодирования (зависит от I).

Число коэффициентов (NB_COEFS)

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

Первый идентификатор источника (FIRST_SOURCE_ID)

Идентификатор первого символа источника, используемого в комбинации.

Число битов в каждом граничном блоке (b_id)

Число битов, требуемое для сохранения границы (edge).

Сведения об идентификаторах символов источника (id_bit_vector)

При I = 0b01 граничные блоки сохраняются как b_id * (NB_IDS * 2 – 1), при I = 0b10 граничные блоки сжимаются.

Коэффициенты (coef_bit_vector)

Коэффициенты, сохраняемые в зависимости от CCGI (4 или 8 битов на каждый коэффициент).

Padding

Заполнение для выравнивания размера вектора кодирования по 32-битовой границе (для ID и коэффициентов).

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

Для последующих параграфов возьмём пример генерации вектора кодирования для кодированного символа, являющегося линейной комбинацией символов источника с идентификаторами 1, 2, 3, 5, 6, 8, 9, 10 (краевые блоки [1..3], [5..6], [8..10]). Есть несколько способов сохранить идентификаторы символов источника в векторе кодирования.

Если сведения об идентификаторах символов источника не нужны, должно устанавливаться I = 0b00, а b_id и id_bit_vector не используются.
Если граничные блоки сохраняются без сжатия, должно устанавливаться I = 0b01. В этом случае устанавливается b_id = 32 (идентификатор символа содержит 32 бита), а список 32-битовых целых чисел без знака (1, 3, 4, 5, 6, 10) помещается в id_bit_vector.
Если идентификаторы символов источника сохраняются в виде списка со сжатием, должно устанавливаться I = 0b10. Этот случай описан в параграфе 5.3.1.1, но вместо сжатия граничных блоков сжимается весь список идентификаторов символов источника.
Если идентификаторы символов источника сохраняются со сжатием, должно устанавливаться I = 0b11 (см. ).

5.3.1.1. Сжатый список идентификаторов символов источника

Продолжим с определенным в предыдущем параграфе кодированным символом с идентификаторами символов источника в линейной комбинации [1..3], [5..6], [8..10]. Для сжатия и сохранения этого списка в векторе кодирования должна применяться приведённая ниже процедура.

Первый элемент пакета (1) кодируется как first_source_id.
Выполняется дифференциальное преобразование путём вычитания элемента ([3, 5, 6, 8, 10]) из последующего с использованием в качестве «нулевого» элемента значения first_source_id, это даёт список L = [2, 2, 1, 2, 2].
Рассчитывается число битов (b), требуемое для сохранения элемента списка, как ceil(log2(max(L))), где max(L) – самый большой элемент в списке L. В нашем случае будет b = 2.
Значение b записывается в соответствующее поле (b_id), а из элементов списка создаётся вектор вида b * [(2 * NB) – 1], где NB – число элементов. В результате получается вектор битов 10, 10, 01, 10, 10.

5.3.1.2. Декомпрессия идентификаторов символов источника

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

Перестраивается список переданных элементов путём считывания вектора битов и b, а затем преобразования в десятичную форму [10, 10, 01, 10, 10] => [2, 2, 1, 2, 2].
Выполняется обратное прежнему преобразование путём сложения элементов, начиная с first_source_id, т. е. [1, 1 + 2, (1 + 2) + 2, (1 + 2 + 2) + 1, …] => [1, 3, 5, 6, 8, 10].
Перестраиваются блоки с использованием списка и first_source_id [1..3], [5..6], [8..10].

5.4. Формат пакета обновления окна

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

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      Common Packet Header                     /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        nb_missing_src                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   nb_not_used_coded_symb                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         first_src_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      plr      |   sack_size   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
/                          SACK Vector                          /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат пакета обновления окна.

Common Packet Header

Базовый заголовок с полем типа пакета 0b10.

nb_missing_src

Число пропущенных символов источника у получателя с начала сессии.

nb_not_used_coded_symb

Число кодированных символов у получателя, которые ещё не использованы для декодирования (например, в линейной комбинации есть хотя бы 2 неизвестных символа источника).

first_src_id

Идентификатор первого символа источника для указания в векторе частичного подтверждения (SACK).

plr

Доля потерь, выраженная в процентах нормализованным 8-битовым целым числом без знака. Например, 2,5% будут представлены как floor(2,5 * 256/100) = 6. И обратно, если указано значение 6, соответствующая доля теряемых пакетов в процентах будет рассчитываться как 6*100/256 = 2,34%. Значение применяется при динамической степени кодирования (code rate) или для статистики. Выбор расчёта остаётся за декодером Tetrys и зависит от наблюдения за окном, но значение PLR следует просматривать перед декодированием.

sack_size

Размер вектора SACK в 32-битовых словах. Например, значение 2 указывает вектор SACK размером 64 бита.

SACK vector

Битовый вектор, указывающий символы, которые должны быть удалены из окна кодирования, начиная с идентификатора первого символа источника. В большинстве случаев эти символы уже получены приёмником. Иногда это может быть связано с невосстановимыми потерями (например, при всплеске числа потерь), когда лучше отбросить и отказаться от некоторых пакетов и удалить их из окна кодирования, чтобы можно было восстановить последующие пакеты. Первый символ источника (First Source Symbol или first_src_id) включается в этот вектор. Бит со значением 1 в позиции i означает, что этот пакет обновления окна удаляет из окна кодирования символ источника с номером first_src_id + i.

6. Темы исследований

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

6.1. Взаимодействие с контролем перегрузок

Tetrys и компоненты контроля перегрузок создают 2 отдельных канала (см. параграф 2.1 в [RFC9265]).

Канал Tetrys передаёт пакеты источника и кодированные пакеты (от отправителя к получателю), а также информацию от получателя к отправителю (например, сигналы о восстановленных символах, частоте потерь до и/или после декодирования и т. п.).
Канал контроля перегрузки переносит пакеты от отправителя к получателю и сигнальные сведения о сети (например, число принятых пакетов по сравнению с потерянными, маркеры ECN³ и т. п.) от получателя к отправителю.

Ниже указаны темы, отмеченные и рассмотренные в [RFC9265], которые уже адаптированы в конкретных внедрениях Tetrys (на транспортном уровне, а также выше или ниже его).

Связанные с перегрузкой потери могут быть скрыты, если протокол Tetrys развернут ниже транспортного уровня без каких-либо мер предосторожности (т. е. Tetrys восстанавливает пакеты, потерянные из-за перегрузки маршрутизатора), что может существенно влиять на эффективность контроля перегрузок. Подход для предотвращения сокрытия таких сигналов представлен в разделе 5 [RFC9265].
Наличие потоков Tetrys наряду с другими потоками в одном канале сети может препятствовать беспристрастному распределению между потоками. В частности, это зависит от наличия и типа контроля перегрузки на отдельных потоках. Детали этого выходят за рамки документа, но могут оказывать существенное влияние.
Адаптация степени кодирования внутри Tetrys может оказывать сильное влияние на контроль перегрузки при ненадлежащем выполнении (см. ).
Tetrys может использовать передачу по нескольким путём для одной пары отправитель-получатель. Поскольку пути могут существенно различаться, может потребоваться адаптация управления потоком данных и контроля перегрузки на каждом пути.
Защита нескольких потоков приложений внутри одного потока Tetrys вызывает дополнительные вопросы (см. ).

6.2. Адаптивная степень кодирования

Когда условия в сети (например, задержки и частота потерь) сильно меняются со временем, можно использовать адаптивную степень кодирования для динамического повышения или сокращения числа кодированных пакетов при передаче (т. е. добавления избыточности) с помощью специального алгоритма, такого как [A-FEC]. Стратегия различается в зависимости от уровня, где развёрнут протокол Tetrys (по отношению к транспортному уровню). Можно разделить стратегии на 2 класса – внедрение Tetrys на транспортном уровне и вне его (выше или ниже). Развёртывание внутри транспортного уровня означает возможность взаимодействия между транспортными механизмами, такими как восстановление при ошибках, контроль перегрузок и/или управление потоком данных. Внедрение Tetrys в транспортных протоколах без контроля перегрузки, таких как UDP, не дало бы никаких преимуществ перед внедрением за пределами транспортного уровня.

Влияние внедрения механизма FEC внутри транспортного уровня рассмотрено в разделе 4 [RFC9265], где исследуются вопросы взаимодействия контроля перегрузок и степени кодирования, а также влияние беспристрастности. Такая адаптация возможна в сочетании с механизмом контроля перегрузок протокола транспортного уровня, как предложено в [CTCP]. Это позволяет использовать отслеживаемые показатели контроля перегрузок (например, RTT, события перегрузки, текущий размер окна перегрузки) для адаптации степени кодирования с учётом рассчитанной скорости транспортной отправки. Смысл заключается в расчёте объёма ремонтного трафика, который не вызывает перегрузки. Такая связанная оптимизация обязательна для предотвращения захвата потоком всей доступной пропускной способности, как описано в [RMCAT-ADAPTIVE-FEC], где авторы отмечают, что коэффициент восстановления (repair ratio) следует повышать при одновременном снижении скорости передачи от источника.

Адаптация степени кодирования может выполняться вне транспортного уровня без учёта показателей этого уровня. В частности, это можно делать вместе с сетью, как предложено в [RED-FEC]. Авторы этой статьи предлагают механизм случайного раннего обнаружения (Random Early Detection) FEC в контексте передачи видео через беспроводную сеть. Вкратце, идея заключается в увеличении числа избыточных пакетов, когда очередь в точке доступа менее загружена, и наоборот. Предложена первая теоретическая попытка доставки видео с применением Tetrys [THAI]. Этот подход интересен тем, что он показывает взаимодействие между требованиями приложения и условиями в сети, а также объединяет сигналы о потребностях приложения и состоянии сети (т. е. ниже и выше транспортного уровня).

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

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

6.3. Использование Tetrys ниже уровня IP для туннелирования

Применение Tetrys для защиты агрегата потоков требует исследования вопроса восстановления дейтаграмм IP, потерянных при туннелировании. Применение избыточности без дифференциации потоков может противоречить требованиям по обслуживанию отдельных потоков, поскольку некоторые из них могут быть чувствительны к задержкам и их вариациям, а другие – к надёжности доставки. На практике блокировка в голове очереди (head-of-line) аналогично влияет на все потоки, несмотря на их разные потребности, что требует более продуманной стратегии в Tetrys.

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

Для начала следует осознать, что применение защиты FEC для потока данных не обеспечивает безопасности и даже повышает уровень риска. Ситуация с протоколом Tetrys похожа на использование других протоколов доставки содержимого в применением FEC и это хорошо описано в FECFRAME [RFC6363]. Этот раздел основан на данном документе и рассматривает дополнительные соображения, относящиеся к Tetrys, когда это уместно.

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

Целью атакующего может быть содержимое, протокол или сеть. Последствия будут существенно разными в зависимости от целей, таких как получение доступа к конфиденциальным сведениям, повреждение содержимого, компрометация кодера и/или декодера Tetrys, нарушение поведения сети. В частности, некоторые атаки направлены на отказ в обслуживании (Denial-of-Service или DoS) и их последствия могут ограничиваться одним узлом (например, декодером Tetrys) или влиять на все узлы, подключённые к соответствующей сети (например, делая потоки невосприимчивыми к сигналам перегрузки).

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

7.2. Атаки на поток данных

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

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

7.3. Атаки на сигнализацию

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

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

7.4. Атаки на сеть

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

7.5. Базовые операции защиты

Tetrys может использовать IPsec/ESP [RFC4303] для защиты конфиденциальности и целостности, аутентификации источника и предотвращения повторного использования пакетов (replay). IPsec/ESP можно применять для защиты потоков данных Tetrys (в обоих направлениях) от злоумышленников, находящихся в промежуточных сетях или способных перехватывать, внедрять и повторно использовать легитимные пакеты.

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

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

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

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

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

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

[RFC5052] Watson, M., Luby, M., and L. Vicisano, “Forward Error Correction (FEC) Building Block”, RFC 5052, DOI 10.17487/RFC5052, August 2007, <https://www.rfc-editor.org/info/rfc5052>.

[RFC5445] Watson, M., “Basic Forward Error Correction (FEC) Schemes”, RFC 5445, DOI 10.17487/RFC5445, March 2009, <https://www.rfc-editor.org/info/rfc5445>.

[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, “Reed-Solomon Forward Error Correction (FEC) Schemes”, RFC 5510, DOI 10.17487/RFC5510, April 2009, <https://www.rfc-editor.org/info/rfc5510>.

[RFC5651] Luby, M., Watson, M., and L. Vicisano, “Layered Coding Transport (LCT) Building Block”, RFC 5651, DOI 10.17487/RFC5651, October 2009, <https://www.rfc-editor.org/info/rfc5651>.

[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, “NACK-Oriented Reliable Multicast (NORM) Transport Protocol”, RFC 5740, DOI 10.17487/RFC5740, November 2009, <https://www.rfc-editor.org/info/rfc5740>.

[RFC6363] Watson, M., Begen, A., and V. Roca, “Forward Error Correction (FEC) Framework”, RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.

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

[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, “Taxonomy of Coding Techniques for Efficient Network Communications”, RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.

[RFC8680] Roca, V. and A. Begen, “Forward Error Correction (FEC) Framework Extension to Sliding Window Codes”, RFC 8680, DOI 10.17487/RFC8680, January 2020, <https://www.rfc-editor.org/info/rfc8680>.

[RFC9265] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, “Forward Erasure Correction (FEC) Coding and Congestion Control in Transport”, RFC 9265, DOI 10.17487/RFC9265, July 2022, <https://www.rfc-editor.org/info/rfc9265>.

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

[A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, “Adaptive FEC-based error control for Internet telephony”, IEEE INFOCOM ’99, Conference on Computer Communications, New York, NY, USA, Vol. 3, pp. 1453-1460, DOI 10.1109/INFCOM.1999.752166, March 1999, <https://doi.org/10.1109/INFCOM.1999.752166>.

[AHL-00] Ahlswede, R., Cai, N., Li, S., and R. Yeung, “Network information flow”, IEEE Transactions on Information Theory, Vol. 46, Issue 4, pp. 1204-1216, DOI 10.1109/18.850663, July 2000, <https://doi.org/10.1109/18.850663>.

[CTCP] Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli, K., Leith, D., and M. Medard, “Network Coded TCP (CTCP)”, arXiv 1212.2291v3, April 2013, <https://arxiv.org/abs/1212.2291>.

[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and W. Hwang, “A RED-FEC Mechanism for Video Transmission Over WLANs”, IEEE Transactions on Broadcasting, Vol. 54, Issue 3, pp. 517-524, DOI 10.1109/TBC.2008.2001713, September 2008, <https://doi.org/10.1109/TBC.2008.2001713>.

[RMCAT-ADAPTIVE-FEC] Singh, V., Nagy, M., Ott, J., and L. Eggert, “Congestion Control Using FEC for Conversational Media”, Work in Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec-03, 20 March 2016, <https://datatracker.ietf.org/doc/html/draft-singh-rmcat-adaptive-fec-03>.

[Tetrys] Lacan, J. and E. Lochin, “Rethinking reliability for long-delay networks”, International Workshop on Satellite and Space Communications, Toulouse, France, pp. 90-94, DOI 10.1109/IWSSC.2008.4656755, October 2008, <https://doi.org/10.1109/IWSSC.2008.4656755>.

[Tetrys-RT] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and V. Roca, “On-the-Fly Erasure Coding for Real-Time Video Applications”, IEEE Transactions on Multimedia, Vol. 13, Issue 4, pp. 797-812, DOI 10.1109/TMM.2011.2126564, August 2011, <http://dx.doi.org/10.1109/TMM.2011.2126564>.

[THAI] Tran Thai, T., Lacan, J., and E. Lochin, “Joint on-the-fly network coding/video quality adaptation for real-time delivery”, Signal Processing: Image Communication, Vol. 29 Issue 4, pp. 449-461, DOI 10.1016/j.image.2014.02.003, April 2014, <https://doi.org/10.1016/j.image.2014.02.003>.

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

Во-первых, авторы хотят сердечно поблагодарить Marie-Jose Montpetit за постоянную помощь и поддержку Tetrys. Спасибо, Marie-Jo!

Авторы также благодарны членам рабочей группы NWCRG за многочисленные обсуждения кодирования «на лету», которые помогли завершить работу над этим документом.

Наконец, авторы хотели бы поблагодарить Colin Perkins за предоставленные комментарии и отзыв о документе.

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

Jonathan Detchart

ISAE-SUPAERO

BP 54032

10, avenue Edouard Belin

31055 Toulouse CEDEX 4

France

Email: jonathan.detchart@isae-supaero.fr

Emmanuel Lochin

ENAC

7, avenue Edouard Belin

31400 Toulouse

France

Email: emmanuel.lochin@enac.fr

Jerome Lacan

ISAE-SUPAERO

BP 54032

10, avenue Edouard Belin

31055 Toulouse CEDEX 4

France

Email: jerome.lacan@isae-supaero.fr

Vincent Roca

INRIA

Inovallee; Montbonnot

655, avenue de l’Europe

38334 St Ismier CEDEX

France

Email: vincent.roca@inria.fr

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

nmalykh@protokols.ru

1Coding for Efficient NetWork Communications Research Group – исследовательская группа по кодированию для эффективных сетевых коммуникаций.

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

3Explicit Congestion Notification – явное уведомление о перегрузке.

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

Архитектура распределенного коммутатора (DSA)

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

Архитектура распределенного коммутатора

PDF

Оригинал

В этом документе рассматриваются принципы устройства и ограничения подсистемы распределенного коммутатора (Distributed Switch Architecture или DSA), её взаимодействия с другими подсистемами, а также вопросы разработки драйверов и нерешенные вопросы разработки самой подсистемы.

Принципы устройства

Подсистема DSA предназначалась в основном для поддержки коммутаторов Ethernet компании Marvell (MV88E6xxx, линейка Link Street), использующих Linux, но развилась и для поддержки продукции других производителей.

Исходным принципом разработки было сохранение возможности применять неизмененные инструменты Linux, такие как bridge, iproute2, ifconfig для настройки и опроса коммутирующих портов сетевого устройства или обычного сетевого устройства.

Коммутатор Ethernet обычно имеет множество портов на передней панели и 1 или несколько портов CPU или управления. Подсистема DSA в настоящее время полагается на наличие порта управления, соединённого с контроллером Ethernet, способным получать кадры Ethernet от коммутатора. Это очень распространённое решение для всех видов коммутаторов Ethernet в продукции для дома и небольшого офиса (Small Home and Office) – маршрутизаторах, шлюзах и даже стоечных коммутаторах (top-of-rack). Этот хост-контроллер Ethernet далее называется ведущим (master) и cpu в описании и коде DSA.

D в аббревиатуре DSA означает Distributed (распределенный), поскольку подсистема разрабатывается для обеспечения возможности настройки и управления каскадом коммутаторов с использованием восходящих и нисходящих каналов Ethernet между ними. Эти порты называются портами dsa в терминологии и коде DSA. Набор соединённых между собой коммутаторов называется деревом коммутаторов (switch tree).

Для каждого порта на передней панели коммутатора DSA создаёт специализированные сетевые устройства, которые служат конечными точками для управления и потоков данных, используемыми сетевым стеком Linux. Эти специализированные сетевые интерфейсы называются ведомыми (slave) в терминологии и коде DSA.

Идеальным вариантом применения DSA является случай с поддержкой коммутатором Ethernet тега (switch tag), являющегося свойством оборудования, когда коммутатор помещает свой тег для каждого кадра Ethernet, получаемого или передаваемого в конкретные порты, чтобы помочь интерфейсу управления понять:

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

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

Отметим, что в настоящее время DSA не создаёт сетевых интерфейсов для портов cpu и dsa.

Портом cpu является сторона коммутатора Ethernet, обращённая к управляющему контроллеру, поэтому создание порта привело бы к дублированию функций, поскольку было бы 2 интерфейса для одного канала (conduit) master netdev и cpu netdev.
Портами dsa являются просто каналы (conduit) между двумя и более коммутаторами и, поскольку они могут служить корректными сетевыми интерфейсами, в этой модели имеют смысл лишь нисходящие интерфейсы и восходящий интерфейс верхнего уровня.

Протоколы для тегов коммутаторов

DSA поддерживает фирменные протоколы тегов многих производителей, программно определяемый протокол для тегов и режим без тегов (tag-less, DSA_TAG_PROTO_NONE). Точный формат зависит от производителя, но обычно теги содержат:

идентификатор порта Ethernet, связанного с приёмом или передачей кадра;
указание причины, по которой кадр был передан в интерфейс управления.

Все протоколы тегов включены в файлы net/dsa/tag_*.c и реализуют методы структуры dsa_device_ops, описанные ниже.

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

Зависящий от коммутатора заголовок кадра размещается перед заголовком Ethernet, сдвигая вправо (с точки зрения первичного анализатора кадров DSA) поля MAC DA, MAC SA, EtherType и все данные L2 (payload).
Зависящий от коммутатора заголовок кадра размещается перед полем EtherType, сохраняя позиции MAC DA и MAC SA с точки зрения первичного анализатора кадров DSA, но сдвигает поля EtherType и данные L2 вправо.
Зависящий от коммутатора заголовок кадра размещается в конце пакета, сохраняя на месте все заголовки кадра и не меняя представление кадра с точки зрения первичного анализатора DSA.

Протокол тегов может помечать все кадры тегами коммутатора одного размера или применять теги переменного размера (например, пакеты с временными метками PTP могут требовать расширения тегов коммутатора, а также возможно использование тегов разного размера для передачи и приёма). В любом случае драйвер протокола тегов должен заполнять структуру dsa_device_ops::needed_headroom и/или dsa_device_ops::needed_tailroom, размер которой в октетах равен большему из размеров заголовка/трейлера в кадре. DSA автоматически корректирует MTU на первичном интерфейсе с учётом дополнительных полей, чтобы пользовательские порты DSA могли поддерживать стандартное значение MTU (размер данных L2) в 1500 октетов. Свойства needed_headroom и needed_tailroom применяются для запроса у сетевого стека (по возможности – best-effort) выделения пакетов с большим пространством, чтобы вталкивание тега коммутатора при передаче пакета не вызывало повторного выделения из-за нехватки памяти.

Хотя от приложений не ожидается синтаксический анализ связанных с DSA заголовков кадров, формат протокола тегов в линии представляет двоичный интерфейс приложений (Application Binary Interface или ABI), раскрываемый ядром пользовательскому пространству для декодирования (такой как libpcap). Драйвер протокола тегов должен помещать в поле proto структуры dsa_device_ops значение, однозначно описывающее характеристики требуемого взаимодействия между оборудованием коммутатора и драйвером пути данных – смещение каждого битового поля в заголовке кадра и любую обработку с учётом состояния, требуемую для работы с кадром как может требоваться, например, для меток времени PTP).

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

Отметим, что в некоторых случаях формат тегов, используемых коммутатором-листом (не соединён напрямую с CPU) отличается от формата, который видит сетевой стек. Примером этого могут служить деревья коммутаторов Marvell, где порт CPU можно настроить на использование формата DSA или Ethertype DSA (EDSA), а каналы DSA настроены на применение более короткого (без Ethertype) формата кадров DSA для снижения издержек при автономной пересылке пакетов. Если дерево коммутаторов DSA настроено для протокола тегов EDSA, операционная система по-прежнему будет видеть пакеты с тегами EDSA от листовых коммутаторов, которые помечают пакеты более короткими заголовками DSA. Это обусловлено тем, что коммутатор Marvell, напрямую соединённый с CPU настроен на преобразование тегов между DSA и EDSA (это просто добавление или удаление ETH_P_EDSA EtherType и некоторых октетов заполнения).

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

Протокол тегов присоединённого коммутатора DSA можно увидеть из атрибута sysfs dsa/tagging ведущего коммутатора DSA с помощью команды

cat /sys/class/net/eth0/dsa/tagging

Если оборудование и драйвер позволяют это, протокола тегов дерева коммутатора DSA можно сменить в процессе работы. Это делается путём записи имени нового протокола тегов в тот же атрибут устройства sysfs, который указан выше (DSA master и все подключённые порты коммутатора должны быть на это время переведены в состояние down).

Желательно, чтобы все протоколы тегов можно было протестировать с помощью макетного драйвера dsa_loop, который можно присоединить к любому сетевому интерфейсу. Цель заключается в том, чтобы любой сетевой интерфейс был способен передавать один и тот же пакет одним способом, а средству маркировки следует одинаково декодировать один и тот же пакет, независимо от драйвера, применяемого для пути управления в коммутаторе и драйвера, применяемого для DSA master.

Передача пакета осуществляется через вызов функции xmit. В переданной структуре sk_buff элемент *skb содержит указатель skb->data на skb_mac_header(skb), т. е. MAC-адрес получателя, а в переданной структуре net_device элемент *dev представляет виртуальный пользовательский сетевой интерфейс DSA, аппаратному «дубликату» которого должен быть направлен пакет (т. е. swp0). Задача этого метода состоит в подготовке skb так, чтобы коммутатор понимал, какой выходной порт использовать для пакета (и не передавал его в другие порты). Обычно это реализуется вталкиванием заголовка кадра. Проверка достаточности пространства в голове и хвосте skb не требуется при корректном указании needed_headroom и needed_tailroom, поскольку DSA гарантирует наличие свободного пространства перед вызовом этого метода.

Для приёма пакета служит функция rcv. В переданной структуре sk_buff элемент *skb содержит указатель skb->data на skb_mac_header(skb) + ETH_ALEN октетов, т. е. на место, где был бы первый октет EtherType, если бы в кадре не было тега. Роль этого метода заключается в использовании заголовка кадра, настройке skb->data для указания на реально первый октет EtherType и изменения skb->dev для указания виртуального пользовательского сетевого интерфейса DSA, соответствующего физическому порту коммутатора, на котором был получен пакет.

Поскольку протоколы тегов категории 1 и 2 нарушают программное (а чаще всего и аппаратное) разбиение пакета в DSA master, такие свойства, как RPS1 на DSA будут нарушены. Модель DSA справляется с этим, устанавливая ловушку в диссекторе потоков и сеняя смещение, по которому можно найти заголовок IP в кадре с тегом, как его видит DSA master. Это автоматизируется на основе значения overhead в протоколе тегов. Если не все пакеты имеют одинаковый размер, модуль работы с тегами может реализовать метод flow_dissect структуры dsa_device_ops и переопределить принятое по умолчанию поведение, задавая корректное смещение в каждом принятом пакете. Модули включения тегов в конец кадра не вызывают проблем для диссекторов потоков.

Выгрузка контрольных сумм должна работать с тегами категории 1 и 2, когда драйвер DSA master декларирует NETIF_F_HW_CSUM в vlan_features и просматривает csum_start и csum_offset. В этих случаях DSA меняет начало и смещения на величину размера тега. Если драйвер DSA master продолжает использовать устаревшее значение NETIF_F_IP_CSUM или NETIF_F_IPV6_CSUM в vlan_features, выгрузка может работать лишь при условии, когда оборудование выгрузки уже ожидает этот конкретный тег (возможно по соответствию производителя). Ведомые устройства DSA наследуют эти флаги от ведущего порта и драйвер корректно возвращается к программной обработке контрольных сумм, когда заголовок IP размещается не там, где его ждёт оборудование. Если описанная проверка неэффективна, пакеты могут проходить через сеть без подходящей контрольной суммы (в поле контрольной суммы будет указано значение для псевдозаголовка IP). Для категории 3, когда оборудование разгрузки не ждёт использования тегов коммутатора, контрольная сумма должна рассчитываться до вставки тега (т. е. в модуле работы с тегами). Иначе DSA будет включать концевой тег в расчёт (программный или аппаратный) контрольной суммы. Когда коммутатор вырежет тег при передаче, он оставит некорректную контрольную сумму на месте.

В силу разных причин (чаще всего из-за тегов категории 1, связанных с не понимающими DSA ведущими устройствами, может искажаться то, что ведущий считает MAC DA) протокол тегов может требовать от DSA работы в неразборчивом (promiscuous) режиме для приёма кадров независимо от значения MAC DA. Это можно сделать установкой свойства promisc_on_master в структуре dsa_device_ops. Отметим, что это предполагает драйвер ведущего устройства без поддержки DSA, что является нормой.

Ведущие сетевые устройства

Ведущие сетевые устройства – это обычные, не изменённые драйверы сетевых устройств Linux для интерфейсов Ethernet CPU/управления. Таким драйверам иногда может требоваться знать включён ли DSA (например, для включения или выключения конкретных свойств разгрузки), но подтверждена работа подсистемы DSA со стандартными для отрасли драйверами e1000e, mv643xx_eth и т. п. без внесения в них изменений. Такие сетевые устройства часто называют «канальными» (conduit), поскольку они служат каналом между процессором хоста и оборудованием коммутатора Ethernet.

Ловушки сетевого стека

При использовании master netdev с DSA в сетевой стек помещается небольшая ловушка для обработки подсистемой DSA используемого коммутатором Ethernet протокола тегов. DSA делает это путём регистрации в сетевом стеке конкретного (фиктивного) типа Ethernet (далее skb->protocol), который называют также ptype или packet_type. Ниже показана типичная последовательность приёма кадра Ethernet ведущим сетевым устройством (например, e1000e).

Получение сигнала прерывания:
- вызов функции приёма;
- базовая обработка пакета (определение размера, статуса и т. п.);
- подготовка пакета к обработке на уровне Ethernet вызовом функции eth_type_trans.

net/ethernet/eth.c

eth_type_trans(skb, dev)
        if (dev->dsa_ptr != NULL)
                -> skb->protocol = ETH_P_XDSA

drivers/net/ethernet/*

netif_receive_skb(skb)
        -> итерации по зарегистрированным packet_type
                -> вызов обработчика для ETH_P_XDSA, вызов dsa_switch_rcv()

net/dsa/dsa.c

-> dsa_switch_rcv()
        -> вызов зависящего от протокола тегов обработчика в net/dsa/tag_*.c

net/dsa/tag_*.c
- проверка и вырезание (протокола) тега для определения порта-источника;
- нахождение сетевого устройства по порту;
- вызов eth_type_trans() с ведомым сетевым устройством DSA;
- вызов netif_receive_skb().

После этого ведомые сетевые устройства DSA получают обычные кадры Ethernet, которые может обрабатывать сетевой стек.

Ведомые сетевые устройства

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

вставку и удаление тега коммутатора (при наличии) при передаче и приёме через соответствующие порты;
запрос у коммутатора операций ethtool (статистика, состояние канала, WoL2, дампы регистров …);
управление внешним или внутренним PHY (канал, автосогласование и т. п.).

Эти ведомые сетевые устройства имеют указатели на пользовательские функции net_device_ops и ethtool_ops, что позволяет DSA вводить уровень разделения между сетевым стеком/ethtool и реализацией драйвера коммутатора.

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

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

При использовании нескольких портов CPU можно разместить устройство LAG (bonding/team) между ведомыми устройствами DSA и физическими DSA master. Устройство LAG также будет DSA master, но ведомые устройства LAG продолжают оставаться DSA master (просто с ними не связывается физический порт; это нужно для восстановления в случае потери LAG DSA master). Таким образом, путь данных LAG DSA master используется асимметрично. На RX обработчик ETH_P_XDSA, который вызывает dsa_switch_rcv(), вызывается редко (на физическом DSA master, LAG slave). Поэтому путь данных RX в LAG DSA master не используется. С другой стороны, TX работает линейно – dsa_slave_xmit вызывает dsa_enqueue_skb, а эта функция вызывает dev_queue_xmit в направлении LAG DSA master. Последняя вызывает dev_queue_xmit в направлении одного или другого физического DSA master и в обоих случаях пакет выходит из системы по аппаратному пути в направлении коммутатора.

Графическое представление

Вид DSA с точки зрения сетевого устройства показан на рисунке ниже.

             Не осведомлённое приложение
             открывает и привязывает сокет
                    |  ^
                    |  |
        +-----------v--|--------------------+
        |+------+ +------+ +------+ +------+|
        || swp0 | | swp1 | | swp2 | | swp3 ||
        |+------+-+------+-+------+-+------+|
        |      Драйвер коммутатора DSA      |
        +-----------------------------------+
                      |        ^
      Тег, добавленный|        | Тег, воспринятый
 драйвером коммутатора|        | драйвером коммутатора
                      v        |
        +-----------------------------------+
        |Неизменённый драйвер интерф. хоста | Программа
--------+-----------------------------------+-------------
        |       Интерфейс хоста (eth0)      | Оборудование
        +-----------------------------------+
                      |        ^
      Тег, воспринятый|        | Тег, добавленный
 оборудованием коммут.|        | оборудованием коммутатора
                      v        |
        +-----------------------------------+
        |            Коммутатор             |
        |+------+ +------+ +------+ +------+|
        || swp0 | | swp1 | | swp2 | | swp3 ||
        ++------+-+------+-+------+-+------++

Ведомая шина MDIO

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

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

Структуры данных

Структуры данных DSA определены в файлах include/net/dsa.h и net/dsa/dsa_priv.h.

Структура dsa_chip_data содержит данные конфигурации платформы для данного коммутирующего устройства. Эта структура описывает родительское устройство коммутатора, его адрес, а также различные свойства портов (имена, метки) и указывает таблицу маршрутизации (при каскадировании коммутаторов).
Структура dsa_platform_data содержит данные конфигурации платформы, которые могут указывать набор структур dsa_chip_data при каскадировании коммутаторов. Структура должна указывать ведущее сетевое устройство, к которому подключено это дерево коммутаторов.
Структура dsa_switch_tree назначенная ведущему сетевому устройству в dsa_ptr. Эта структура ссылается на структуру dsa_platform_data и указывает протокол тегов, поддерживаемый деревом коммутаторов, а также ловушки функций приёма и передачи, которые следует вызывать и сведения о подключённом напрямую коммутаторе (порт CPU). Для указания отдельных коммутаторов дерева применяется набор структур dsa_switch.
Структура dsa_switch описывает коммутирующее устройство в дереве, ссылаясь на dsa_switch_tree в качестве обратного указателя, а также указывает ведомые и ведущее сетевые устройства резервную структуру dsa_switch_ops.
Структура dsa_switch_ops содержит указатели на функции, описанные ниже.

Ограничения для устройств

Отсутствие сетевых устройств CPU/DSA

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

невозможность извлечь значения счётчиков статистики порта CPU с использованием ethtool, что может осложнять отладку коммутаторов MDIO, подключённых через интерфейс xMII;
невозможность настроить для порта CPU параметры канала с помощью подключённого к нему контроллера Ethernet (см. http://patchwork.ozlabs.org/patch/509806/);
невозможность настроить конкретные VLAN ID и транковые VLAN между коммутаторами в каскаде.

Распространённые ошибки при использовании DSA

После того, как ведущее сетевое устройство настроено для DSA (dev->dsa_ptr отлично от NULL) и размещённый за ним коммутатор ожидает протокол тегов, этот сетевой интерфейс можно использовать лишь в качестве интерфейса «трубы» (conduit). Передача пакетов напрямую через этот интерфейс (например, создание сокета с использованием этого интерфейса) не потребует проходить через функцию передачи протокола тегов, поэтому ожидающий тег коммутатор Ethernet на другой стороне обычно будет отбрасывать такие пакеты.

Взаимодействия с другими подсистемами

Ниже указаны подсистемы, используемые DSA в настоящее время:

библиотека MDIO/PHY – drivers/net/phy/phy.c, mdio_bus.c
switchdev – net/switchdev/*
дерево устройств для различных функций of_*;
devlink – net/core/devlink.c.

Библиотека MDIO/PHY

Сетевые устройства, раскрываемые DSA, не обязательно сопрягаются с устройствами PHY (struct
phy_device, заданная в include/linux/phy.h), но подсистема DSA обрабатывает все возможные комбинации:

внутренние устройства PHY, встроенные в оборудование коммутаторов Ethernet;
внешние устройства PHY, подключённые через внутреннюю или внешнюю шину MDIO;
внутренние устройства PHY, подключённые через внутреннюю шину MDIO;
специальные устройства PHY без автоматического согласования и управления через: SFP, MoCA (fixed PHY).

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

При использовании дерева устройств (Device Tree) устройство PHY отыскивается с помощью стандартного свойства phy-handle и при обнаружении это устройство PHY и регистрируется функцией of_phy_connect().
Если используется дерево устройств и устройство PHY является «фиксированным» (т. е. соответствует определению PHY, управляемого не через MDIO, как указано в файле Documentation/devicetree/bindings/net/fixed-link.txt), PHY регистрируется и подключается «прозрачно» с использованием специального драйвера фиксированной шины MDIO.
Если устройство PHY встроено в коммутатор, как это часто бывает в автономных коммутаторах, PHY проверяется с использованием специальной шины MII, созданной DSA.

SWITCHDEV

DSA напрямую использует SWITCHDEV при взаимодействии с уровнем моста и, более конкретно, с фильтрацией VLAN при настройке VLAN на портах ведомых сетевых устройств. На сегодняшний день DSA поддерживает в SWITCHDEV лишь объекты FDB и VLAN.

Devlink

DSA регистрирует одно устройство devlink на физический коммутатор в модуле коммутации (fabric). Для каждого устройства devlink каждый физический порт (пользовательские порты, порты CPU, каналы DSA и неиспользуемые порты) раскрывается как порт devlink.

Драйверы DSA могут использовать указанные ниже свойства devlink.

Регионы

Отладочное средство, позволяющее пользовательскому пространству выводить определяемые драйвером области аппаратной информации в низкоуровневом двоичном формате. Поддерживаются глобальные регионы и регионы по портам. Возможен экспорт регионов devlink даже для данных, которые уже тем или иным способом раскрыты стандартным программам пользовательского пространства iproute2 (ip-link, bridge), такие как таблицы адресов и VLAN. Это может быть полезно, например, когда таблицы содержат связанные с оборудованием детали, которые не видны через абстракцию iproute2, или для проверки таблиц на портах, не являющихся пользовательскими, которые не видны iproute2, поскольку для них не регистрируются сетевые интерфейсы.

Параметры

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

Ресурсы

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

Общие буферы

Свойство QoS для настройки и разделения памяти и резервирования кадров по портам на входном и выходном направлении так, чтобы объёмный трафик с низким приоритетом не препятствовал обработке высокоприоритетного важного трафика.

Дополнительные сведения можно найти в файлах каталога Documentation/networking/devlink/.

Дерево устройств

В DSA имеется фиксированная привязка, описанная в файле Documentation/devicetree/bindings/net/dsa/dsa.txt. Вспомогательные функции библиотеки PHY/MDIO, такие как of_get_phy_mode(), of_phy_connect(), часто
применяются для запроса связанных с
PHY деталей по портам – соединения интерфейсов, размещение шины MDIO и т. п.

Разработка драйверов

Драйверы коммутаторов DSA должны реализовать структуру dsa_switch_ops,
содержащую описанные ниже элементы.

Проба, регистрация и срок действия устройства

Коммутаторы DSA являются обычными структурами device на шинах (платформа, SPI, I2C, MDIO и пр.). Платформа DSA не участвует в их зондировании ядром устройства.

Регистрация коммутатора с точки зрения драйвера означает передачу действительного указателя на структуру dsa_switch функции dsa_register_switch(), обычно из функции проверки драйвера коммутатора. Ниже указаны элементы предоставляемой структуры, которые должны иметь действительные значения:

ds->dev
используется для синтаксического
анализа данных узла OF или платформы;
ds->num_ports используется для создания списка портов этого коммутатора и проверки индексов портов, предоставляемых в узле OF;
ds->ops содержит указатель на структуру dsa_switch_ops, содержащую реализации методов ;
ds->priv – обратный указатель на частную структуру данных драйвера, которая может извлекаться во всех последующих обратных вызовах (callback) методов DSA.

Кроме того, могут указываться перечисленные ниже флаги структуры dsa_switch для задания конкретного поведения драйвера со стороны ядра DSA. Описание поведения приведено в комментариях к файлу include/net/dsa.h.

ds->vlan_filtering_is_global;
ds->needs_standalone_vlan_filtering;
ds->configure_vlan_while_not_filtering;
ds->untag_bridge_pvid;
ds->assisted_learning_on_cpu_port;
ds->mtu_enforcement_ingress;
ds->fdb_isolation.

DSA сохраняет внутри массив деревьев (групп) коммутаторов, являющийся глобальным для ядра, и связывает с деревом структуру dsa_switch при регистрации. Идентификатор дерева, с которым связан коммутатор, определяется первым числом u32 number свойства dsa,member узла OF коммутатора (0 при отсутствии). Идентификатор коммутатора в дереве определяется вторым числом u32 в том же свойстве OF (0 при отсутствии). Регистрация нескольких коммутаторов с совпадающими идентификаторами коммутатора и дерева некорректна и вызывает ошибку. При использовании данных платформы разрешён 1 коммутатор и одно дерево.

Для дерева с несколькими коммутаторами зондирование выполняется асимметрично. Первые N-1 вызывающих dsa_register_switch() лишь добавляют свои порты в список портов дерева (dst->ports) и каждый порт имеет обратный указатель на связанный с ним коммутатор (dp->ds). Эти коммутаторы заранее завершают свои вызовы dsa_register_switch(), поскольку функция dsa_tree_setup_routing_table() определяет, что дерево ещё не завершено (не все порты, указанные каналами DSA, присутствуют в списке портов дерева). Дерево становится полным, когда последний коммутатор вызывает dsa_register_switch() и это запускает эффективное продолжение инициализации (включая вызов ds->ops->setup()) для всех коммутаторов этого дерева, как часть контекста вызова функции зондирования последним коммутатором.

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

Для драйверов коммутаторов DSA обязательна реализация обратного вызова shutdown() соответствующей шины и вызов dsa_switch_shutdown() из неё (минимальный вариант полного демонтажа, выполняемого dsa_unregister_switch()). Причина заключается в том, что DSA сохраняет ссылку на ведущее сетевое устройство и при отвязывании (unbind) основного устройства при отключении ссылка DSA будет препятствовать завершению операции.

Должна вызываться функция dsa_switch_shutdown() или dsa_unregister_switch(), но не обе, и модель драйвера устройства разрешает вызывать метод шины remove(), даже если уже вызвана функция shutdown(). Поэтому ожидается реализация в драйверах метода взаимного исключения remove() и shutdown() путём установки drvdata = NULL после вызова любой из этих функций и проверка значения drvdata (NULL) перед выполнением какого-либо действия.

После вызова dsa_switch_shutdown() или dsa_unregister_switch() обратные вызовы через предоставленный указатель на dsa_switch_ops не могут выполняться и драйвер может освободить структуры данных, связанные с dsa_switch.

Настройка коммутатора

get_tag_protocol

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

change_tag_protocol

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

setup

Функция установки (setup) коммутатора, отвечающая за установку приватной структуры dsa_switch_ops со всем необходимым – планы регистров, прерывания, мьютексы, блокировки и т. п. Предполагается, что эта функция должным образом настроит конфигурацию коммутатора для отделения сетевых интерфейсов друг от друга, т. е. им следует быть изолировать самому оборудованию коммутатора, обычно путём создания для каждого VLAN ID по порту и разрешая пересылку лишь между портом CPU и конкретным портом. Не используемые платформой порты следует отключать. После вызова этой функции коммутатор предполагается полностью настроенным и готовым к выполнению запросов любого вида. Рекомендуется выполнять программный сброс коммутатора в этой функции настройки для исключения настроек, которые мог установить прежний программный агент, такой как начальный загрузчик или микрокод. Методом, отвечающим за отказ от всех применимых выделений или операций, выполненных здесь, является teardown.

port_setup и port_teardown

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

port_change_master

Метод, с помощью которого можно изменить связность (аффинность – ассоциация для целей завершения трафика) пользовательского порта и порта CPU. По умолчанию все пользовательские порты из дерева связаны с первым доступным портом CPU, имеющим смысл для данного порта (в большинстве случаев это означает, что все пользовательские порты в дереве связаны с одним портом CPU, за исключением топологии H, описанной в представлении 2c0b03258b8b). Аргумент port указывает индекс пользовательского порта, а master представляет новое ведущее устройство DSA master net_device. Порт CPU, связанный с новым ведущим, можно определить поиском в struct dsa_port *cpu_dp = master->dsa_ptr. Кроме того, ведущий может быть устройством LAG, в котором все ведому устройства являются физическими DSA master. Ведущие LAG DSA имеют действительный указатель master->dsa_ptr, однако он не уникален и является дубликатом dsa_ptr первого физического DSA (LAG slave). В случае LAG DSA последующий вызов port_lag_join будет выполняться отдельно для физических портов CPU, связанных с физическими DSA master, с запросом на создание аппаратной группы LAG, связанной с интерфейсом LAG.

Управление PHY и каналом

get_phy_flags

Некоторые коммутаторы имеют интерфейсы для различных типов Ethernet PHY. Если драйвер PHY библиотеки PHY нужны сведения, которые он не может получить сам (например, из регистров, отображённых на память коммутатора), этой функции следует возвращать 32-битовую маску «флагов», которые являются приватными для драйвера коммутатора и драйвера Ethernet PHY из каталога drivers/net/phy/*.

phy_read

Функция вызывается шиной MDIO ведомого DSA для считывания регистров MDIO порта коммутатора. При неудаче считывания функция возвращает 0xffff для каждой операции чтения. Для Ethernet PHY встроенных коммутаторов этой функции следует разрешать считывание статуса канала, результаты автосогласования, страницы партнёра по каналу и т. п.

phy_write

Функция вызывается шиной MDIO ведомого DSA для записи в регистры MDIO порта коммутатора. При невозможности записи функция возвращает отрицательный код ошибки.

adjust_link

Функция вызывается библиотекой PHY, когда ведомое сетевое устройство присоединяется к устройству PHY. Функция отвечает за подобающую настройку параметров канала для порта коммутатора – скорости, дуплекса, паузы на основе представленных в phy_device значений.

fixed_link_update

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

Операции ethtool

get_strings

Функция ethtool для запроса строк драйвера, которые обычно содержат статистику, приватные флаги и т. п.

get_ethtool_stats

Функция ethtool для запроса статистики по порта. DSA накладывает статистику ведомых сетевых устройств на общую статистику – счётчики RX/TX из сетевого устройства со статистикой драйвера коммутатора по портам.

get_sset_count

Функция ethtool для запроса числа элементов статистики.

get_wol

Функция ethtool для получения настроек Wake-on-LAN по портам. В некоторых реализациях функция может также запрашивать настройки Wake-on-LAN ведущего сетевого устройства, если этот интерфейс нужен для участия в Wake-on-LAN.

set_wol

Функция ethtool для настройки Wake-on-LAN по портам.

set_eee

Функция ethtool для настройки параметров EEE (Green Ethernet) порта коммутатора, которая может вызывать библиотеку PHY для включения EEE на уровне PHY, если это уместно. Этой функции следует включать EEE на контроллере MAC и в логике обработки данных порта коммутатора.

get_eee

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

get_eeprom_len

Функция ethtool, возвращающая для данного коммутатора размер EEPROM в байтах.

get_eeprom

Функция ethtool, возвращающая для данного коммутатора содержимое EEPROM.

set_eeprom

Функция ethtool, записывающая указанные данные в EEPROM данного коммутатора.

get_regs_len

Функция ethtool, возвращающая для данного коммутатора размер регистров.

get_regs

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

Управление питанием

suspend

Функция, вызываемая устройством платформы DSA, когда система переходит в режим приостановки (suspend). Функции следует приостанавливать все действия коммутатора Ethernet, оставляя активными порты, участвующие в Wake-on-LAN, а также дополнительную логику пробуждения, если она поддерживается.

resume

Функция, вызываемая устройством платформы DSA при возобновлении работы системы (resume). Функции следует восстанавливать все действия коммутатора Ethernet и реконфигурировать коммутатор, чтобы он находился в полностью активном состоянии.

port_enable

Функция, вызываемая функцией ndo_open ведомого устройства DSA при административной активации порта. Функции следует полностью включать данный физический порт. DSA заботится о маркировке порта BR_STATE_BLOCKING, если порт входит в мост, и BR_STATE_FORWARDING – в противном случае, а также распространении этих изменений в оборудование.

port_disable

Функция, вызываемая функцией ndo_open ведомого устройства DSA при административном отключении порта. Функции следует полностью выключать данный физический порт. DSA заботится о маркировке порта BR_STATE_DISABLED и распространении этих изменений в оборудование, если отключенный порт входит в мост.

Адресные базы данных

Предполагается, что коммуникационное оборудование имеет таблицу для записей FDB, однако не все записи активны в каждый момент времени. База адресных данных является подмножеством (разделом) записей FDB, которые активны (могут быть сопоставлены с изучением адресов на RX или поиском в FDB на TX) в зависимости от состояния порта. В этом документе база адресных данных иногда называется идентификаторами фильтрации (FID или Filtering ID), хотя базовая реализация может выбрать все, что поддерживает оборудование. Например, все порты, принадлежащие мосту, не поддерживающему VLAN (в данный момент), предполагаются изучающими адреса отправителей в адресной базе, связанной драйвером с этим мостом (а не с другими мостами без поддержки VLAN). При пересылке и поиске в FDB пакета, принятого на порту моста без поддержки VLAN, следует обеспечивать возможность поиска не связанной с VLAN записи FDB с тем же MAC DA, что и в пакете, имеющуюся для другого порта того же моста. В тоже время, процесс поиска в FDB должен быть способен не найти (игнорировать) запись FDB с тем же MAC DA, что и в пакете, если эта запись указывает порт другого моста без поддержки VLAN (связана с другой базой адресов).

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

В этом контексте базе данных без VLAN соответствуют все пакеты независимо от VLAN ID (поиск лишь по адресу MAC), а в базе данных с VLAN сопоставление выполняется по VLAN ID из заголовка 802.1Q (или pvid, если тега нет).

На уровне моста записи FDB без поддержки VLAN имеют специальное значение VID 0, а в записях FDB с поддержкой VLAN идентификаторы VID отличны от 0. Отметим что не знающий о VLAN мост может иметь записи FDB с VLAN (ненулевой идентификатор VID), а мост с поддержкой VLAN может иметь записи FDB без VLAN. Как и аппаратные, программные мосты поддерживают раздельные базы адресных данных и выгружают в оборудование записи FDB, относящиеся к этим базам, через switchdev асинхронно относительно моментов их активации (деактивации).

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

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

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

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

Первичные индивидуальный MAC-адреса портов (dev->dev_addr). Эти адреса связаны с приватной базой адресов порта и драйвер уведомляется об их установке через port_fdb_add в направлении порта CPU.
Вторичные индивидуальные и групповые MAC-адреса портов (добавленные через dev_uc_add() и dev_mc_add()). Эти адреса тоже связаны с приватной базой адресов соответствующего пользовательского порта
Локальные/постоянные записи FDB моста (BR_FDB_LOCAL). Это MAC-адреса портов моста, для которых пакеты должны обрабатываться локально, без пересылки. Адреса связаны с базой данных этого моста.
Статические записи FDB моста, установленные для внешних (не DSA) интерфейсов, присутствующих в одном мосту с портами коммутатора DSA. Эти адреса также связаны с базой данных этого моста.
Динамически полученные записи FDB для внешних интерфейсов, присутствующих в одном мосту с портами коммутатора DSA, лишь при установке драйвером значения true для ds->assisted_learning_on_cpu_port. Адреса связаны с базой данных этого моста.

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

DSA_DB_PORT

Устанавливаемая или удаляемая запись FDB (или MDB) для частной базы пользовательского порта db->dp.

DSA_DB_BRIDGE

Запись, относящаяся к одной из баз данных моста db->bridge. Предполагается, что драйвер разделяет базы без VLAN и базы на основе VID в этом мосту.

DSA_DB_LAG

Запись, относящаяся к адресной базе LAG db->lag. Отметим, что DSA_DB_LAG в настоящее время не используется, а в будущем может быть удалена.

Драйверам, использующим аргумент dsa_db в port_fdb_add, port_mdb_add и т. п., следует объявлять ds->fdb_isolation = true.

DSA связывает каждый выгруженный мост и каждую выгруженную группу LAG с идентификатором на основе 1 (struct
dsa_bridge :: num, struct dsa_lag :: id) для подсчёта адресов на совместно используемых портах. Драйверы могут использовать (piggyback) схему нумерации DSA (идентификатор считывается через db->bridge.num и db->lag.id) или реализовать свою схему.

Только драйверы, объявляющие поддержку изоляции FDB, уведомляются о записях FDB на порту CPU, относящихся в базам данных DSA_DB_PORT. Для совместимости адреса DSA_DB_BRIDGE сообщаются драйверам, даже не поддерживающим изоляцию FDB, однако в этом случае db->bridge.num и db->lag.id имеют значение 0 (чтобы указать отсутствие изоляции для целей подсчета).

Отметим, что от драйвера коммутатора не требуется реализация адресных баз данных для каждого автономного пользовательского порта. Поскольку записи FDB в приватных базах портов всегда указывают порт CPU, не возникает риска неверных решений о пересылке. В таких случаях все автономные порты могут пользоваться общей базой, но подсчёт ссылок на отфильтрованные хостом адреса(без удаления записей FDB для MAC-адресов порта, которые используются другими портами) возлагается на драйвер, поскольку DSA не знает, что базы портов на деле являются общими. Это можно обеспечить вызовом dsa_fdb_present_in_other_db() и dsa_mdb_present_in_other_db(). Недостатком является то, что списки входной (RX) фильтрации пользовательских портов фактически являются общими, а это означает, что пользовательский порт A может воспринять пакет с MAC DA, который не следует принимать, лишь потому, что этот MAC-адрес включён в RX-фильтр пользовательского порта B. Однако такие пакеты все равно будут отбрасываться программно.

Уровень моста

Выгрузка плоскости пересылки моста необязательна и обслуживается описанными ниже методами. Эти методы могут отсутствовать и возвращается -EOPNOTSUPP или ds->max_num_bridges может быть ненулевым и превышенным и в этом случае присоединение порта моста остаётся возможным, но пересылка пакетов будет выполняться программно, а порты программного моста должны быть настроены так же, как при автономной работе, т. е. все функции моста (изучение адресов и т. п.) должны быть отключены, а все принятые пакеты должны пересылаться лишь в порт CPU.

Порт начинает выгрузку плоскости пересылки после того, как он успешно выполняет метод port_bridge_join, и прекращает это делать после вызова port_bridge_leave. Выгрузка моста означает автономное изучение адресов (записей FDB) в соответствии с состоянием порта программного моста и автономную пересылку (или лавинную рассылку) полученных пакетов без вовлечения порта CPU. Это необязательно даже при выгрузке порта моста. Предполагается, что драйверы протокола тегов вызывают dsa_default_offload_fwd_mark(skb) для пакетов, которые уже пересылались автономно в домене пересылки входного порта коммутатора. DSA с помощью dsa_port_devlink_setup() считает все порты коммутатора, являющиеся частью одного дерева, относящимися к одному домену пересылки моста (способными автономно пересылать пакеты между собой).

Выгрузка выходного (TX) процесса пересылки моста отличается от простой выгрузки плоскости пересылки и относится к способности определённых комбинаций драйверов и протоколов тегов передавать один блок skb, приходящий от функции пересылки устройства моста, одному или нескольким выходным портам (без программного клонирования).

Пакеты, для которых мост запрашивает такое поведение, называют пакетами плоскости данных и они имеют skb->offload_fwd_mark = true в функции xmit драйвера протокола тегов. Для пакетов плоскости данных выполняется поиск в FDB, аппаратное обучение на порту CPU, а состояние STP для порта не переопределяется. Кроме того, репликация пакетов плоскости данных (групповая и лавинная рассылка) обеспечивается оборудованием, а драйвер моста будет передавать 1 блок skb для каждого пакета, который может реплицироваться.

При включённой выгрузке TX-пересылки драйвер протокола тегов отвечает за внедрение пакетов в плоскость данных оборудования в направлении домена моста (FID), к которому относится порт. Порт может не понимать VLAN и в таком случае идентификатор FID должен совпадать с FID, используемым драйвером для адресной базы без VLAN, связанной с этим мостом. Мост может понимать VLAN и в этом случае гарантируется, что пакет имеет тег VLAN с VLAN ID, где мост обрабатывает этот пакет. Оборудование отвечает за снятие тега VID на выходных портах без тегов и сохранение его на выходных портах с тегами.

port_bridge_join

Функция уровня моста, вызываемая при добавлении в мост данного порта коммутатора. Этой функции следует делать все, что требуется на уровне коммутатора, чтобы разрешить добавление порта в соответствующий логический домен для приёма/передачи трафика других членов моста. Установка для аргумента tx_fwd_offload значения true ведёт к выгрузке и процесса TX-пересылки данного моста.

port_bridge_leave

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

port_stp_state_set

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

port_bridge_flags

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

port_fast_age

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

Фильтрация VLAN в мостах

port_vlan_filtering

Функция уровня моста, вызываемая при включении или отключении на мосту фильтрации VLAN. Если на аппаратном уровне не требуется конкретных действий, этот обратный вызов (callback) можно не реализовать. При включении фильтрации VLAN оборудование должно быть запрограммировано на отклонение кадров 802.1Q, в которых VLAN ID выходит за рамки запрограммированных разрешённых отображений и правил VLAN ID. Если на порту коммутатора не запрограммировано PVID, должны отвергаться и кадры без тегов. При отключённой фильтрации коммутатор должен воспринимать любые кадры 802.1Q независимо от их VLAN ID, а также кадры без тегов.

port_vlan_add

Функция уровня моста, вызываемая при настройке VLAN (с тегами или без них) для данного порта коммутатора. Порт CPU становится членом VLAN лишь в том случае, когда порт другого (foreign) моста также входит в VLAN (и пересылка должна выполняться программно), или VLAN помещается в группу VLAN самого устройства моста для целей завершения (bridge vlan add dev br0 vid 100 self). Ссылки на VLAN общих (shared) портов учитываются и VLAN удаляется, если пользователей не остаётся. Драйвер не обязан вручную устанавливать VLAN на порту CPU.

port_vlan_del

Функция уровня моста, вызываемая при a VLAN is removed from the given switch port

port_fdb_add

Функция уровня моста, вызываемая при желании моста установить запись в базе пересылки FDB. На оборудовании коммутатора следует запрограммировать указанный адрес с VLAN ID в базе пересылки, связанной с этим VLAN ID.

port_fdb_del

Функция уровня моста, вызываемая при желании моста удалить запись из базы пересылки FDB. На оборудовании коммутатора следует запрограммировать удаление указанного MAC-адреса из VLAN ID, если он был отображён на данный порт в базе пересылки.

port_fdb_dump

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

port_mdb_add

Функция уровня моста, вызываемая при желании моста установить запись в групповой базе. На оборудовании коммутатора следует запрограммировать указанный адрес с VLAN ID в базе пересылки, связанной с этим VLAN ID.

port_mdb_del

Функция уровня моста, вызываемая при удалить запись из групповой базы. На оборудовании коммутатора следует запрограммировать удаление указанного MAC-адреса из VLAN ID, если он был отображён на данный порт в базе пересылки.

Агрегирование каналов

Агрегирование каналов реализовано в сетевом стеке Linux драйверами bonding и team, моделируемыми как виртуальные стековые сетевые интерфейсы. DSA может выгружать группы агрегирования каналов (link aggregation group или LAG) в оборудование, поддерживающее эту функцию, и поддерживать мосты между физическими портами и LAG, а также между LAG. Интерфейс bonding/team, содержащий несколько физических портов, представляет собой логический порт, хотя в настоящее время в DSA нет явной концепции логического порта. Поэтому события присоединения и отключения LAG от моста трактуются как присоединение или отключение всех отдельных физических портов данной группы LAG. Атрибуты (фильтрация VLAN, статус STP и т. п.) и объекты (VLAN, записи MDB) порта switchdev, выгруженные в LAG как порт моста, обрабатываются аналогично – DSA выгружает объект или атрибут порта switchdev для всех членов LAG. Статические записи FDB моста для LAG ещё не поддерживаются, поскольку API драйвера DSA не включает концепции идентификатора логического порта.

port_lag_join

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

port_lag_leave

Функция, вызываемая при удалении данного порта из LAG и возвращающая порт в режим автономного.

port_lag_change

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

Драйверы, которым выгодно иметь идентификатор, связанный с каждой выгруженной группой LAG, могут заполнять значение ds->num_lag_ids из метода dsa_switch_ops::setup. LAG ID, связанный с интерфейсом bonding/team в этом случае может быть извлечён драйвером коммутатора DSA с помощью функции dsa_lag_id.

IEC 62439-2 (MRP)

Протокол резервирования среды (Media Redundancy Protocol или MRP) – это протокол управления топологией, оптимизированный для восстановления при отказах в кольцевых сетях, некоторые компоненты которого реализованы как функции драйвера моста. MRP использует управляющие PDU (Test, Topology, LinkDown/Up, Option), передаваемые по групповым MAC-адресам из диапазона 01:15:4e:00:00:0x с EtherType = 0x88e3. В зависимости от роли узла в кольце (MRM – Media Redundancy Manager, MRC – Media Redundancy Client, MRA – Media Redundancy Automanager) для некоторых MRP PDU может требоваться локальное завершение, для других же – пересылка. MRM может выигрывать от выгрузки в оборудование создания и передачи некоторых MRP PDU (Test).

Обычно экземпляр MRP может создаваться на базе любого сетевого интерфейса, однако в случае устройств с выгруженным путём данных, таких как DSA, требуется, чтобы оборудование (даже не поддерживающее MRP) было способно извлекать MRP PDU из модуля коммутации (fabric) до того, как драйвер сможет обработать их в программной реализации. На сегодняшний день в DSA нет драйверов, понимающих MRP, поэтому прослушиваются лишь минимальные объекты switchdev, требуемые для корректной работы программ, которые указаны ниже.

port_mrp_add и port_mrp_del

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

port_mrp_add_ring_role и port_mrp_del_ring_role

Функция, вызываемая при смене роли экземпляра MRP между MRM и MRC. Это определяет, какие MRP PDU следует захватывать (trap) программно, а какие – автономно пересылать.

IEC 62439-3 (HSR/PRP)

Протокол параллельного резервирования (Parallel Redundancy Protocol или PRP) обеспечивает резервирование сети путём дублирования и последовательной нумерации пакетов, передаваемых через 2 независимые сети L2 (которые не знают о наличии в конце пакетов тега PRP), и исключения дубликатов у получателя. Протокол бесшовного резервирования высокой доступности (High-availability Seamless Redundancy или HSR) использует похожие концепции, но все узлы, передающие резервный трафик, знают о тегах HSR (HSR использует заголовок с EtherType – 0x892f) и соединены в кольцо. HSR и PRP используют кадры наблюдения для мониторинга работоспособности сети и обнаружения узлов.

В Linux протоколы HSR и PRP реализованы в драйвере hsr, который создаёт виртуальный стековый сетевой интерфейс с двумя портами. Драйвер реализует лишь базовые роли узла с двойным подключением, реализующего HSR (Doubly Attached Node implementing HSR или DANH) или PRP (Doubly Attached Node implementing PRP или DANP), а роли RedBox и QuadBox не поддерживаются (поэтому мостовое соединения сетевого интерфейса hsr с физическим портом коммутатора не даёт ожидаемого результата).

Драйверу, способному выгружать некоторые функции DANP или DANH, следует объявлять соответствующие свойства netdev, как указано в файле Documentation/networking/netdev-features.rst. Кроме того, должны быть реализованы указанные ниже методы.

port_hsr_join

Функция, вызываемая при добавлении данного порта коммутатора в DANP/DANH. Драйвер может возвращать -EOPNOTSUPP и в таких случаях DSA будет возвращаться к программной реализации, когда весь трафик из этого порта передаётся в CPU.

port_hsr_leave

Функция, вызываемая при удалении данного порта коммутатора из DANP/DANH и возвращающая порт в режим автономного.

Продолжение работы

Объединение базы кода SWITCHDEV и DSA

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

Драйвер коммутатора Ethernet Broadcom RoboSwitch

Семейство коммутаторов Ethernet Broadcom RoboSwitch используется во многих маршрутизаторах xDSL, кабельных модемах и устройствах multimedia. Фактическая реализация поддерживает устройства BCM5325E, BCM5365, BCM539x, BCM53115 и BCM53125, а также BCM63XX.

Детали реализации

Файлы размещены в каталоге drivers/net/dsa/b53/ и реализуют драйвер DSA. Описание подсистемы и её функций приведено в файле Documentation/networking/dsa/dsa.rst.

Коммутатор, по возможности, настраивается на поддержку 4-байтовых тегов коммутатора Broadcom, которые коммутатор помещает в каждый пакет, пересылаемый на интерфейс CPU, а сетевому интерфейсу CPU следует вставлять аналогичный тег во все пакеты, поступающие в порт CPU. Формат тегов описан в файле net/dsa/tag_brcm.c.

Конфигурация устройства зависит от включения или отключения маркировки пакетов тегами.

Имена интерфейсов и примеры сетевой конфигурации соответствуют описанию в параграфе .

Конфигурация с поддержкой тегов

Желательно применять конфигурацию на основе тегов. Она не является специфической для драйвера DSA b53 и будет работать как и с другими драйверами DSA, поддерживающими теги (см . ).

Конфигурация без поддержки тегов

Более старые модели (5325, 5365) применяют иной формат тегов, который ещё не поддерживается. Для 539x и 531×5 требуется управляемый режим и особая обработка, которая также пока не поддерживается. В этих случаях теги не поддерживаются и коммутатору нужна другая конфигурация, несколько отличающаяся от описанной в параграфе .

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

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

Отдельный порт

Конфигурацию можно задать лишь через теги VLAN и настройку моста. По умолчанию применяется vid 1.

# Установка тегов для трафика на порту CPU
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3

# Ведущий интерфейс должен быть поднят до ведомых портов.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up

# Активация ведомых интерфейсов
ip link set wan up
ip link set lan1 up
ip link set lan2 up

# Создание моста
ip link add name br0 type bridge

# Активация фильтров VLAN 
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов в мост
ip link set dev wan master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0

# Установка тегов для трафика на портах
bridge vlan add dev lan1 vid 2 pvid untagged
bridge vlan del dev lan1 vid 1
bridge vlan add dev lan2 vid 3 pvid untagged
bridge vlan del dev lan2 vid 1

# Настройка VLAN
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3

# Активация моста
ip link set br0 up

Мост

# Установка тегов для трафика на порту CPU
ip link add link eth0 name eth0.1 type vlan id 1

# Ведущий интерфейс должен быть поднят до ведомых портов.
ip link set eth0 up
ip link set eth0.1 up

# Активация ведомых интерфейсов
ip link set wan up
ip link set lan1 up
ip link set lan2 up

# Создание моста
ip link add name br0 type bridge

# Активация фильтров VLAN 
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов в мост
ip link set dev wan master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set eth0.1 master br0

# Настройка моста
ip addr add 192.0.2.129/25 dev br0

# Активация моста
ip link set dev br0 up

Шлюз

# Установка тегов для трафика на порту CPU
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2

# Ведущий интерфейс должен быть поднят до ведомых портов.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up

# Активация ведомых интерфейсов
ip link set wan up
ip link set lan1 up
ip link set lan2 up

# Создание моста
ip link add name br0 type bridge

# Активация фильтров VLAN
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов в мост
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0

# Установка тегов для трафика на портах
bridge vlan add dev wan vid 2 pvid untagged
bridge vlan del dev wan vid 1

# Настройка VLAN
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0

# Активация моста
ip link set br0 up

Драйвер коммутатора Ethernet Broadcom Starfighter 2

Аппаратные модули коммутаторов Ethernet Broadcom Starfighter 2 применяются в нескольких типах устройств:

шлюзы xDSL, такие как BCM63138;
приставки (Set Top Box) для потокового вещания и multimedia, такие как BCM7445;
кабельные модемы и домашние шлюзы, такие как BCM7145/BCM3390.

Коммутатор обычно имеет от 5 до 13 портов, обеспечивая ряд встроенных и настраиваемых интерфейсов:

1 встроенный интерфейс Gigabit PHY;
4 встроенных Gigabit PHY;
4 внешних Gigabit PHY с мультиплексором MDIO;
встроенный MoCA PHY
несколько внешних интерфейсов MII/RevMII/GMII/RGMII;

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

Блок аппаратного коммутатора обычно имеет интерфейс с доступом MMIO и содержит набор регистров (субблоков):

SWITCH_CORE
– общие регистры коммутатора;
SWITCH_REG
– регистр внешних интерфейсов коммутатора;
SWITCH_MDIO
– контроллер внешней шины MDIO (в SWITCH_CORE имеется ещё один для непрямого доступа к PHY);
SWITCH_INDIR_RW
– блок вспомогательных 64-битовых регистров;
SWITCH_INTRL2_0/1
– контроллеры прерываний L2;
SWITCH_ACB
– блок управления допуском;
SWITCH_FCB
– блок управления преодолением отказов.

Детали реализации

Драйвер находится в файле drivers/net/dsa/bcm_sf2.c и реализован как драйвер DSA. Подсистема и её функции описаны в файле Documentation/networking/dsa/dsa.rst.

Коммутатор SF2 настраивается на вставку 4-байтовых тегов коммутатора Broadcom, которые помещаются в каждый пакет, пересылаемый на интерфейс CPU, а сетевому интерфейсу CPU следует вставлять аналогичный тег во все пакеты, поступающие в порт CPU. Формат тегов описан в файле net/dsa/tag_brcm.c.

В целом драйвер SF2 является обычным драйвером DSA, но имеет некоторые особенности, описанные ниже.

Зондирование дерева устройств

Драйвер устройства платформы DSA зондируется с использованием специальной строки совместимости, представленной в файле net/dsa/dsa.c. Это связано с тем, что подсистема DSA в настоящее время регистрируется как драйвер устройства платформы. DSA предоставляет требуемые указатели device_node, которые становятся доступными функции установки драйвера устройства для организации ресурсов, таких как диапазоны регистров и прерывания. В настоящее время это работает очень хорошо, поскольку ни одной из используемых драйвером функций of_* не требуется привязка структуры device к структуре device_node, но в будущем это может измениться.

Опосредованный доступ к MDIO

Ограничения при разработке коммутаторов Broadcom требуют для внешних коммутаторов Broadcom, подключённых к SF2, использовать ведомую шину DSA MDIO для их настройки. По умолчанию адреса псевдо-PHY коммутатора SF2 и внешнего коммутатора будут отслеживать входящие транзакции MDIO, поскольку они находятся по одному адресу (30), что ведёт к «двойному» программированию. Использование DSA и установка ds->phys_mii_mask перенаправляют операции чтения и записи на адреса псевдо-PHY внешних коммутаторов Broadcom. В новых версиях оборудования SF2 добавлен настраиваемый адрес псевдо-PHY, что позволяет преодолеть это ограничение.

Мультимедиа через интерфейсы CoAxial (MoCA)

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

Интерфейсы MoCA поддерживаются с использованием фиксированных/эмулируемых устройств PHY библиотеки PHY и драйвер коммутатора регистрирует для таких PHY обратный вызов (callback) fixed_link_update,
который отражает состояние канала, полученное от обработчика прерываний.

Управление питанием

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

отключения внутренних буферов и памяти;
отключения логики обработки пакетов;
перевода встроенных PHY в режим IDDQ/low-power;
снижение тактовой частоты ядра коммутатора в зависимости от числа активных портов;
включение и анонсирование EEE;
отключение логики обработки данных RGMII при обрыве (down) канала связи.

Wake-on-LAN

Функция пробуждения из сети (Wake-on-LAN или WoL) в настоящее время реализована с использованием логики включения контроллера Ethernet MAC на процессоре хоста. При запросе Wake-on-LAN определяется пересечение запроса пользователя и возможностей WoL на интерфейсе Ethernet хоста и используется результат. При остановке и восстановлении работы на уровне системы в целом отключаются лишь порты, не участвующие в Wake-on-LAN.

Драйвер коммутатора Ethernet LAN9303

LAN9303 – это 3-портовый коммутатор Ethernet 10/100 Мбит/с со встроенными PHY для двух внешних портов Ethernet. Третий порт является интерфейсом RMII/MII для первичного сетевого интерфейса хоста (например, постоянного канала).

Детали драйвера

Драйвер реализован как драйвер DSA, см. Documentation/networking/dsa/dsa.rst. Привязки к дереву устройств описаны в файле Documentation/devicetree/bindings/net/dsa/lan9303.txt.

Управление LAN9303 возможно через MDIO и I2C, поддерживаемые драйвером.

При запуске драйвер настраивает устройство для предоставления двух раздельных сетевых интерфейсов (принятое по умолчанию состояние устройства DSA). Из-за аппаратных ограничений в этом режиме не поддерживается аппаратное изучение MAC-адресов.

Когда оба пользовательских порта присоединены к одному мосту, включается обычное аппаратное изучение MAC-адресов. Это означает, что индивидуальный трафик пересылается на аппаратном уровне. Широковещательные и групповые кадры пересылаются лавинно на аппаратном уровне. В этом режиме поддерживается также протокол STP. Драйвер поддерживает операции FDB/MDB, что означает поддержку протокола IGMP.

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

Ограничения драйвера

Не реализована поддержка фильтрации VLAN.
Оборудование не поддерживает связанные с VLAN записи FDB.

Драйвер коммутатора Ethernet NXP SJA1105

Обзор

NXP SJA1105 – это семейство из 10 автомобильных коммутаторов с управлением SPI:

SJA1105E – первое поколение без TTEthernet;
SJA1105T – первое поколение с TTEthernet;
SJA1105P – второе поколение без TTEthernet и SGMII;
SJA1105Q – второе поколение с TTEthernet, но без SGMII;
SJA1105R – второе поколение без TTEthernet, но с SGMII;
SJA1105S – второе поколение с TTEthernet и SGMII;
SJA1110A – третье поколение с TTEthernet, SGMII, встроенными PHY 100base-T1 и 100base-TX PHY;
SJA1110B – третье поколение с TTEthernet, SGMII, 100base-T1, 100base-TX;
SJA1110C – третье поколение с TTEthernet, SGMII, 100base-T1, 100base-TX;
SJA1110D – третье поколение с TTEthernet, SGMII, 100base-T1.

Поскольку коммутаторы являются компонентами автомобиля, их интерфейс настройки ориентирован на принцип «установил и забыл» с минимальным динамическим взаимодействием при работе. Для этого нужно создать статическую конфигурацию программными средствами, упаковать её с CRC и заголовками таблиц и передать через SPI. Статическая конфигурация состоит из нескольких таблиц, часть которых может изменяться (перенастраиваться) в процессе работы. Некоторые таблицы обязательны, другие – нет.

Таблица	Обязательна	Перенастройка
Планирование	нет	нет
Точки входа планирования	При включённом планировании	нет
Поиск VL	нет	нет
Правила VL	При включённом поиске VL	нет
Пересылка VL	При включённом поиске VL	нет
Поиск L2	нет	нет
Правила L2	да	нет
Поиск VLAN	да	да
Пересылка L2	да	частичная (полная на P/Q/R/S)
Конфигурация MAC	да	частичная (полная на P/Q/R/S)
Параметры планирования	При включённом планировании	нет
Параметры точек входа планирования	При включённом планировании	нет
Параметры пересылки VL	При включённой пересылке VL	нет
Параметры поиска L2	нет	частичная (полная на P/Q/R/S)
Параметры пересылки L2	да	нет
Параметры синхронизации часов	нет	нет
Параметры AVB	нет	нет
Общие параметры	да	частичная
Смена тегов	нет	да
Параметры xMII	да	нет
SGMII	нет	да

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

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

Свойства коммутации

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

Оборудование помечает весь трафик тега VLAN по портам (pvid) или декодирует сведения о VLAN из тегов 802.1Q. Расширенная классификация VLAN не поддерживается. После определения тега VLAN кадры проверяются по правилам принадлежности и отбрасываются на входе, если они не соответствуют какой-либо VLAN. Это доступно в случае подключения портов коммутатора к мосту с vlan_filtering = 1.

Обычно оборудование не настраивается в части поддержки VLAN, но изменение TPID, по которому коммутатор ищет теги 802.1Q, позволяет сохранить семантику моста с vlan_filtering = 0 (принимать весь трафик, независимо от тегов), поэтому такой режим тоже поддерживается.

Поддерживается разделение портов коммутатора между несколькими мостами (например, 2 + 2), но всем мостам следует использовать общий уровень осведомлённости о VLAN (значение 0 или 1 для vlan_filtering у всех).

Поддерживается определение топологии и обнаружение петель с помощью протокола STP.

Выгрузка

Планирование с учётом времени

Коммутатор поддерживает вариант усовершенствований для планирования трафика, заданный в IEEE 802.1Q-2018 (ранее 802.1Qbv). Это означает возможность использования коммутатора для обеспечения детерминированной задержки приоритетного трафика, передаваемого вместе (in-band) с событием gate-open в сетевом планировании. Этой возможностью можно управлять через выгрузку tc-taprio (flags 2). Отличие от программной реализации taprio состоит в том, что последняя способна управлять лишь трафиком от CPU, не не пересылаемыми автономно потоками.

Устройство поддерживает 8 классов и отображает входящие кадры на один из них на основе битов VLAN PCP (при отсутствии VLAN используются принятые по умолчанию по портам). Как описано выше, в зависимости от значения vlan_filtering, поле EtherType, распознаваемое коммутатором как VLAN, может иметь значение 0x8100 или настраиваемое значение, используемое драйвером для тегов. Поэтому коммутатор игнорирует VLAN PCP при использовании в автономном режиме или в мосту с vlan_filtering=0, поскольку он не распознаёт EtherType 0x8100. В этих режимах внедрение в конкретную очередь на передачу (TX) возможно лишь для сетевых устройств DSA, которые на выходу включают теги в поле PCP. При vlan_filtering=1
поведение меняется на обратное, выгруженные потоки могут направляться в очереди TX на основе VLAN PCP, но сетевые устройства DSA уже не могут этого делать. Для внедрения кадров в аппаратную очередь TX при включённой поддержке VLAN требуется создать субинтерфейс VLAN на ведущем порту DSA и передавать обычные (0x8100) кадры с тегами VLAN в направлении коммутатора с соответствующей установкой VLAN PCP.

Трафик управления (с DMAC 01-80-C2-xx-xx-xx или 01-19-1B-xx-xx-xx) является исключением и коммутатор всегда обрабатывает его с фиксированным приоритетом без учёта битов VLAN PCP, если они установлены. Для трафика управления в настоящее время используется класс 7 (высший приоритет), который не настраивается в драйвере.

Ниже приведён пример настройки планирования с циклом 500 мсек на выходном порту swp5. Шлюз для управляющего трафика (7) открыт на 100 мсек, для остальных классов – на 400 мсек.

#!/bin/bash

set -e -u -o pipefail

NSEC_PER_SEC="1000000000"

gatemask() {
        local tc_list="$1"
        local mask=0

        for tc in ${tc_list}; do
                mask=$((${mask} | (1 << ${tc})))
        done

        printf "%02x" ${mask}
}

if ! systemctl is-active --quiet ptp4l; then
        echo "Please start the ptp4l service"
        exit
fi

now=$(phc_ctl /dev/ptp1 get | gawk '/clock time is/ { print $5; }')
# Фазовое выравнивание базового времени относительно начала следующей секунды.
sec=$(echo "${now}" | gawk -F. '{ print $1; }')
base_time="$(((${sec} + 1) * ${NSEC_PER_SEC}))"

tc qdisc add dev swp5 parent root handle 100 taprio \
        num_tc 8 \
        map 0 1 2 3 5 6 7 \
        queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
        base-time ${base_time} \
        sched-entry S $(gatemask 7) 100000 \
        sched-entry S $(gatemask "0 1 2 3 4 5 6") 400000 \
        flags 2

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

Маршрутизация (redirect, trap, drop)

Коммутатор способен выгружать основанное на потоках перенаправление в набор портов, заданных пользователем. В коммутаторе это реализовано путём использования виртуальных каналов (Virtual Link или VL) – концепции TTEthernet.

Коммутатор поддерживает для VL 2 типа ключей:

виртуальные каналы с поддержкой VLAN соответствуют MAC-адресу получателя, VLAN ID и VLAN PCP;
виртуальные каналы без поддержки VLAN соответствуют лишь MAC-адресу получателя.

Состояние осведомлённости моста о VLAN (vlan_filtering) не может быть изменено, пока установлены правила для VL. В одном правиле может применяться несколько действий. Если нужна лишь маршрутизация, драйвер создаёт «некритичный» виртуальный канал. Если список действий включает также tc-gate (см. ниже), виртуальный канал становится «критичным по времени» (извлекает буферы кадров из зарезервированного раздела памяти и т. п.).

Поддерживается 3 действия по маршрутизации: ловушка (trap), отбрасывание (drop) и перенаправление (redirect).

Пример 2. Передача кадров, полученных на swp2 с DA 42:be:24:9b:76:20, в CPU и swp3. Этот тип ключа (только DA) относится к отключённой поддержке VLAN на порту

tc qdisc add dev swp2 clsact
tc filter add dev swp2 ingress flower skip_sw dst_mac 42:be:24:9b:76:20 \
        action mirred egress redirect dev swp3 \
        action trap

Пример 2. Отбрасывание кадров, полученных на swp2 с DA of 42:be:24:9b:76:20, VID 100 и PCP 0

tc filter add dev swp2 ingress protocol 802.1Q flower skip_sw \
        dst_mac 42:be:24:9b:76:20 vlan_id 100 vlan_prio 0 action drop

Входные правила с учётом времени

Аппаратные возможности TTEthernet в коммутаторе могут быть ограничены для работы в соответствии с пунктом «Фильтрация и правила по потокам» (Per-Stream Filtering and Policing или PSFP) стандарта IEEE 802.1Q-2018 (ранее 802.1Qci). Это означает возможность жёсткого контроля допуска по времени для множества (до 1024) потоков, задаваемых MAC-адресом получателя, VLAN ID и VLAN PCP. Пакеты, полученные за пределами ожидаемого окна приёма, отбрасываются. Этой возможностью можно управлять путём выгрузки действия tc-gate. Поскольку действия по маршрутизации присущи виртуальным каналам в TTEthernet (явная маршрутизация критичного ко времени трафика без отдачи на откуп FDB, лавинной рассылке и т. п.), действие tc-gate не может возникать само по себе, если запросить у sja1105 выгрузку его. За этим действием должно следовать 1 или несколько действий redirect или trap.

Создадим, например, расписание tc-taprio, согласованное по фазе с расписанием tc-gate (часы должны быть синхронизированы стеком приложения 1588, но это выходит за рамки документа). Ни один из пакетов, доставленных отправителем, не будет отброшен. Отметим, что окно приёма больше окна передачи (в этом примере намного больше) для компенсации задержки распространения в канале (которую может определить стек приложения 1588).

Получатель (sja1105)

tc qdisc add dev swp2 clsact
now=$(phc_ctl /dev/ptp1 get | awk '/clock time is/ {print $5}') && \
        sec=$(echo $now | awk -F. '{print $1}') && \
        base_time="$(((sec + 2) * 1000000000))" && \
        echo "base time ${base_time}"
tc filter add dev swp2 ingress flower skip_sw \
        dst_mac 42:be:24:9b:76:20 \
        action gate base-time ${base_time} \
        sched-entry OPEN  60000 -1 -1 \
        sched-entry CLOSE 40000 -1 -1 \
        action trap

Отправитель

now=$(phc_ctl /dev/ptp0 get | awk '/clock time is/ {print $5}') && \
        sec=$(echo $now | awk -F. '{print $1}') && \
        base_time="$(((sec + 2) * 1000000000))" && \
        echo "base time ${base_time}"
tc qdisc add dev eno0 parent root taprio \
        num_tc 8 \
        map 0 1 2 3 4 5 6 7 \
        queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
        base-time ${base_time} \
        sched-entry S 01  50000 \
        sched-entry S 00  50000 \
        flags 2

Для планирования работы входных шлюзов применяется тот же механизм, что и для выгрузки tc-taprio, поэтому сохраняются ограничения, связанные с невозможностью одновременного (в течение одного интервала в 200 нсек) срабатывания двух шлюзов (tc-gate или tc-taprio).

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

tc qdisc add dev swp2 ingress_block 1 clsact
tc qdisc add dev swp3 ingress_block 1 clsact
tc filter add block 1 flower skip_sw dst_mac 42:be:24:9b:76:20 \
        action gate index 2 \
        base-time 0 \
        sched-entry OPEN 50000000 -1 -1 \
        sched-entry CLOSE 50000000 -1 -1 \
        action trap

Доступна также аппаратная статистика для каждого потока (pkts учитывает число отброшенных кадров, указывающее сумму кадров, отброшенных из-за временных ограничений, отсутствия портов назначения и превышения MTU). Счётчики байтов недоступны.

Ограничения

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

Ключи виртуальных каналов фиксированы {MAC DA, VLAN ID, VLAN PCP}, но драйвер запрашивает VLAN ID и VLAN PCP, если порт относится к мосту с поддержкой VLAN. В иных случаях драйвер автоматически указывает VLAN ID и VLAN PCP в зависимости от того, является порт автономным или относится к мосту без VLAN, и воспринимает лишь ключи tc-flower без поддержки VLAN (MAC DA).

Имеющиеся ключи tc-flower, выгруженные с использованием виртуальных каналов, перестают работать, при возникновении одного из указанных ниже обстоятельств:

автономный ранее порт присоединяется к мосту (с VLAN или без таковых);
порт относится к мосту, в котором меняется статус поддержки VLAN;
порт, входивший в мост, становится автономным;
порт был автономным, но другой порт присоединился к мосту с VLAN и это поменяло статус поддержки VLAN в мосту.

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

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

Этот раздел основан на файле Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml и демонстрирует некоторые предостережения при работе с коммутаторами.

Роль RMII PHY и сигнализация по отдельному каналу

По спецификации RMII тактовые сигналы 50 МГц подаются от MAC или внешнего генератора (но не от PHY). Однако спецификация предоставляет достаточно свободы и устройства часто выходят за её пределы. Некоторые PHY идут наперекор спецификации и предоставляют вывод, на которых они подают сигнал 50 МГц, пытаясь быть полезными. Коммутатор SJA1105 настраивается только двоичным путём и в роли RMII MAC он тоже пытается управлять тактовым сигналом. Чтобы этого не происходило, коммутатор нужно перевести в режим RMII PHY, однако это ведёт к некоторым нежелательным последствиям. По спецификации RMII устройство PHY может передавать дополнительные внеполосные сигналы через RXD[1:0]. Практически это несколько дополнительных кодовых слов ((/J/ и /K/), передаваемых до преамбулы каждого кадра. В MAC нет такого механизма внеполосной сигнализации, определяемого спецификацией RMII. Поэтому при переводе порта SJA1105 в роль PHY для исключения двух источников тактовых сигналов неизбежно возникает соединение RMII PHY-to-PHY. Коммутатор SJA1105 полностью эмулирует интерфейс PHY и генерирует символы /J/ и /K/ перед преамбулой кадра, которые предполагаются непонятными для реального PHY. Поэтому PHY просто кодирует дополнительные символы, полученные от SJA1105 в роли PHY, в линию 100Base-Tx. На другом конце линии некоторые партнёры по каналу могут отбрасывать эти дополнительные символы, но другие могут «подавиться» ими и отбросить весь кадр Ethernet. Это выглядит как потеря пакета на некоторых каналах. Поэтому в режиме RMII коммутатор SJA1105 должен быть способен служить тактовым генератором при соединении с PHY.

RGMII стационарных каналов и внутренние задержки

Второе поколение устройств имеет настраиваемые линии задержки (часть MAC), которые можно использовать для организации корректного бюджета времени RGMII. При включении питания линии могут смещать часы Rx и Tx по фазе на величину от 73,8 до 101,7 градуса. Сложность заключается в том, что линии задержки нужно привязывать к тактовому сигналу со стабильной частотой. Это означает, что между тактовыми сигналами старой и новой частоты должно быть не менее 2 мксек тишины. В противном случае синхронизация теряется и линии задержки нужно сбрасывать (выключать и включать снова). В RGMII тактовая частота зависит от скорости канала (125 МГц для 1000 Мбит/с, 25 МГц для 100 Мбит/с и 2,5 МГц для 10 Мбит/с), которая может меняться в процессе автоматического согласования. В ситуации, когда порт коммутатора подключён к партнёру по стационарному каналу RGMII и состояние этого канала не контролируется Linux (например, другая микросхема SoC), линии задержки остаются разблокированными (и неактивными) без ручного вмешательства (ifdown/ifup на порту коммутатора). В результате этого в режиме RGMII внутренние задержки в коммутаторе будут надёжными лишь в случаях, когда скорость канала к партнёру не меняется или меняется согласованно с портом коммутатора (практически, обе стороны канала находятся под управлением одной системы Linux). В части изменения скорости стационарного канала следует помнить, что есть контроллеры Ethernet, которые при перезапуске устанавливают режим 100 Мбит/с и требуют смены тактовой частоты для перехода не гигабитную скорость.

Шина MDIO и управление PHY

SJA1105 не имеет шины MDIO и не выполняет автонастройки по основному каналу, поэтому от коммутационного устройства не поступает уведомлений о статусе канала. Плате нужно «перехватывать» (hook) PHY коммутатора, подключённые к какой-либо шине MDIO, доступной для Linux внутри системы (например, к шине MDIO ведущего DSA). Управление состоянием канала в этом случае выполняется драйвером «вручную» путём синхронизации (с помощью команд SPI) скорости канала MAC с установками, согласованными PHY.

SJA1110 поддерживает ведомую точку доступа MDIO, через которую с хоста можно обращаться к внутренним 100base-T1 PHY. Однако эта точка не используется драйвером, а доступ к внутренним PHY 100base-T1 и 100base-TX осуществляется через команды SPI, моделируемые в Linux как виртуальные шины MDIO.

Микроконтроллер, подключённый к порту 0 в SJA1110, имеет контроллер MDIO, работающий в режиме первичного (master), однако драйвер его не поддерживает, поскольку микроконтроллер отключается при работе драйвера Linux. Дискретным PHY, подключённым к портам коммутатора, следует иметь интерфейс MDIO, подключённый к контроллеру MDIO хост-системы, а не коммутатора, как в случае SJA1105.

Матрица совместимости портов

Матрица совместимости портов SJA1105 показана в таблице.

Порт	SJA1105E/T	SJA1105P/Q	SJA1105R/S
0	xMII	xMII	xMII
1	xMII	xMII	xMII
2	xMII	xMII	xMII
3	xMII	xMII	xMII
4	xMII	xMII	SGMII

Матрица совместимости портов SJA1110 показана в следующей таблице.

Порт	SJA1110A	SJA1110B	SJA1110C	SJA1110D
0	RevMII (uC)	RevMII (uC)	RevMII (uC)	RevMII (uC)
1	100base-TX или SGMII	100base-TX	100base-TX	SGMII
2	xMII или SGMII	xMII	xMII	xMII или SGMII
3	XMII, SGMII или 2500base-X	XMII, SGMII или 2500base-X	xMII	SGMII или 2500base-X
4	SGMII или 2500base-X	SGMII или 2500base-X	SGMII или 2500base-X	SGMII или 2500base-X
5	100base-T1	100base-T1	100base-T1	100base-T1
6	100base-T1	100base-T1	100base-T1	100base-T1
7	100base-T1	100base-T1	100base-T1	100base-T1
8	100base-T1	100base-T1	–	–
9	100base-T1	100base-T1	–	–
10	100base-T1	–	–	–

Настройка коммутатора из пользовательского пространства

Настройка конфигурации коммутатора DSA в настоящее время не интегрирована с основными пакетами настройки конфигурации сети и должна выполняться вручную.

Варианты конфигурации

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

Одиночный порт

Каждый порт коммутатора выступает как отдельный настраиваемый порт Ethernet.

Мост

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

Шлюз

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

Все настройки выполняются с помощью команд iproute23.

Через DSA каждый порт коммутатора обслуживается как обычный интерфейс Linux Ethernet. Порт CPU в коммутаторе соединён с микросхемой Ethernet MAC. Соответствующий интерфейс Linux Ethernet называется ведущим (master), остальные – ведомыми. Чтобы ведомые интерфейсы могли принимать и передавать трафик, должен быть включён ведущий интерфейс. В ядрах до версии v5.12 состоянием ведущего интерфейса явно управлял пользователь, но в ядрах, начиная с v5.12, поведение изменилось:

при активации ведомого интерфейса DSA ведущий интерфейс активируется автоматически;
при отключении (down) ведущего интерфейса все ведомые интерфейсы DSA отключаются автоматически.

В этом документе используются указанные ниже интерфейсы Ethernet.

eth0

Ведущий интерфейс.

eth1

Второй ведущий интерфейс.

lan1

Ведомый интерфейс.

lan2

Второй ведомый интерфейс.

lan3

Третий ведомый интерфейс.

wan

Ведомый интерфейс, выделенный для восходящего трафика.

Другие интерфейсы Ethernet могут настраиваться аналогично. Адреса IP и сети указаны ниже.

Отдельный порт

lan1: 192.0.2.1/30 (192.0.2.0 – 192.0.2.3)
lan2: 192.0.2.5/30 (192.0.2.4 – 192.0.2.7)
lan3: 192.0.2.9/30 (192.0.2.8 – 192.0.2.11)

Мост

br0: 192.0.2.129/25 (192.0.2.128 – 192.0.2.255)

Шлюз

br0: 192.0.2.129/25 (192.0.2.128 – 192.0.2.255)
wan: 192.0.2.1/30 (192.0.2.0 – 192.0.2.3)

Конфигурация с поддержкой тегов

Конфигурация на основе тегов желательна и поддерживается большинством коммутаторов DSA. Эти коммутаторы способны маркировать входящий и исходящий трафик без использования конфигурации на основе VLAN.

Отдельный порт

# Настройка каждого интерфейса.
ip addr add 192.0.2.1/30 dev lan1
ip addr add 192.0.2.5/30 dev lan2
ip addr add 192.0.2.9/30 dev lan3

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up

# Активация ведомых интерфейсов.
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up

Мост

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up

# Активация ведомых интерфейсов.
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up

# Создание моста.
ip link add name br0 type bridge

# Добавление портов моста.
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0

# Настройка моста.
ip addr add 192.0.2.129/25 dev br0

# Активация моста
ip link set dev br0 up

Шлюз

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up

# Активация ведомых интерфейсов.
ip link set wan up
ip link set lan1 up
ip link set lan2 up

# Настройка восходящего порта.
ip addr add 192.0.2.1/30 dev wan

# Создание моста.
ip link add name br0 type bridge

# Добавление портов моста.
ip link set dev lan1 master br0
ip link set dev lan2 master br0

# Настройка моста.
ip addr add 192.0.2.129/25 dev br0

# Активация моста.
ip link set dev br0 up

Конфигурация без поддержки тегов

Незначительная часть коммутаторов не способна использовать протокол тегов (DSA_TAG_PROTO_NONE). Их можно настраивать на основе VLAN.

Отдельный порт

Конфигурацию можно задать лишь через теги VLAN и организацию (setup) моста.

# Теги трафика на порту CPU.
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up

# Активация ведомых интерфейсов.
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up

# Создание моста.
ip link add name br0 type bridge

# Активация фильтров VLAN.
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов моста.
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0

# Теги трафика на портах.
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 2 pvid untagged
bridge vlan add dev lan3 vid 3 pvid untagged

# Настройка VLAN.
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3

# Активация моста.
ip link set br0 up

Мост

# Теги трафика на порту CPU.
ip link add link eth0 name eth0.1 type vlan id 1

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up
ip link set eth0.1 up

# Активация ведомых интерфейсов.
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up

# Создание моста.
ip link add name br0 type bridge

# Активация фильтров VLAN.
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов моста.
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set eth0.1 master br0

# Теги трафика на портах.
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev lan3 vid 1 pvid untagged

# Настройка моста.
ip addr add 192.0.2.129/25 dev br0

# Активация моста
ip link set dev br0 up

Шлюз

# Теги трафика на порту CPU.
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2

# Для ядер до v5.12 ведущий интерфейс нужно активировать вручную
# до активации любого из ведомых портов.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up

# Активация ведомых интерфейсов.
ip link set wan up
ip link set lan1 up
ip link set lan2 up

# Создание моста.
ip link add name br0 type bridge

# Активация фильтров VLAN.
ip link set dev br0 type bridge vlan_filtering 1

# Добавление портов моста.
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0

# Теги трафика на портах.
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev wan vid 2 pvid untagged

# Настройка VLAN.
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0

# Активация моста.
ip link set br0 up

Управление базой пересылки (FDB)

В имеющихся коммутаторах DSA нет поддержки синхронизации программной базы FDB моста с аппаратными таблицами, поэтому управление этими таблицами выполняется раздельно – команда bridge fdb show запрашивает обе таблицы, а команды bridge fdb add и bridge fdb del применяются к одной или обеим таблицам в зависимости от флагой self и master.

В ядрах до v4.14 управление записями FDB моста поддерживалось DSA из пользовательского пространства лишь с помощью операций обхода моста (обновляют лишь аппаратную таблицу, но не FDB) с флагом self (необязателен).

bridge fdb add dev swp0 00:01:02:03:04:05 self static
# или
bridge fdb add dev swp0 00:01:02:03:04:05 static

Из-за ошибки реализация обхода моста в DSA не различала статические и локальные записи FDB (статические предназначены для пересылки, а локальные – для завершения в коммутаторе, т. е. передачи в порт хоста). Записи FDB с флагом self (явным или неявным) трактовались DSA как статические, даже будучи локальными.

# Приведённая ниже команда
bridge fdb add dev swp0 00:01:02:03:04:05 static
# ведёт себя для DSA как команда
bridge fdb add dev swp0 00:01:02:03:04:05 local
# или сокращённо, поскольку флаг local предполагается, если не задан static.
bridge fdb add dev swp0 00:01:02:03:04:05

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

В ядрах от v4.14 до v5.14 DSA поддерживает параллельно два режима добавления записей FDB в мост – рассмотренный выше обход моста и новый режим с использованием флага master, задающего установку записей FDB и в программный мост.

bridge fdb add dev swp0 00:01:02:03:04:05 master static

Начиная с ядра v5.14 в DSA была достигнута более тесная интеграция с программной FDB моста, а поддержка обхода моста (флаг self) была исключена. Это привело к указанным ниже изменениям.

# Это единственный способ добавления записи FDB, совместимый
# с ядрами, начиная с v4.14.
bridge fdb add dev swp0 00:01:02:03:04:05 master static
# Эта команда больше не является ошибочной и запись корректно
# считается локальной.
bridge fdb add dev swp0 00:01:02:03:04:05
# Эта команда больше не включает статическую запись FDB в оборудование.
bridge fdb add dev swp0 00:01:02:03:04:05 static

При разработке сценариев рекомендуется использовать флаги master и static для работы с записями FDB моста на интерфейсах коммутатора DSA.

Близость пользовательских портов к портам CPU

Обычно коммутатор DSA подключается к хосту через один интерфейс Ethernet, но при использовании дискретных микросхем коммутации оборудование может допускать использование нескольких портов для повышения пропускной способности при завершении трафика. DSA может использовать несколько портов CPU разными способами. Во-первых, можно статически назначить завершение трафика, связанного с неким пользовательским портом, определённому порту CPU. Таким способом пользовательское пространство может реализовать настраиваемые правила статического распределения нагрузки между пользовательскими портами, распределяя близость (affinity) в соответствии с доступными портами CPU. Во-вторых, можно распределять нагрузку между портами CPU на уровне пакетов, не задавая статического сопоставления пользовательских портов с портами CPU. Это можно реализовать, размещая ведущие DSA на интерфейсе LAG (bonding или team). DSA отслеживает это и создаёт зеркало такой программной группы LAG на портах CPU, обращённых к ведущим DSA, связанным с ведомым устройством LAG.

Для использования нескольких портов CPU в описании микрокода (дерево устройств) коммутатора требуется отметить все каналы между портами CPU и их DSA master с использованием ссылок (phandle) Ethernet. При запуске используется лишь 1 порт CPU и DSA (первый по порядку из описания микрокода, имеющий свойство Ethernet). Настройку системы для использования коммутатором других ведущих выполняет пользователь.

DSA использует механизм rtnl_link_ops (с типом dsa) для возможности смены DSA master пользовательского порта. Атрибут netlink IFLA_DSA_MASTER u32 содержит ifindex ведущего устройства, обслуживающего каждое ведомое устройство. DSA master должен быть действительным кандидатом на основе сведений об узле микрокода или интерфейсом LAG, содержащим только ведомые, являющиеся действительными кандидатами.

Ниже приведены манипуляции, доступные с помощью iproute2.

# Просмотр используемого DSA
ip -d link show dev swp0
    (...)
    dsa master eth0

# Статическое распределение порта CPU.
ip link set swp0 type dsa master eth1
ip link set swp1 type dsa master eth0
ip link set swp2 type dsa master eth1
ip link set swp3 type dsa master eth0

# Порты CPU в LAG, использующие явное назначение DSA master.
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth1 down && ip link set eth1 master bond0
ip link set swp0 type dsa master bond0
ip link set swp1 type dsa master bond0
ip link set swp2 type dsa master bond0
ip link set swp3 type dsa master bond0
ip link set eth0 down && ip link set eth0 master bond0
ip -d link show dev swp0
    (...)
    dsa master bond0

# Порты CPU в LAG, полагающиеся на неявный перенос DSA master.
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth0 down && ip link set eth0 master bond0
ip link set eth1 down && ip link set eth1 master bond0
ip -d link show dev swp0
    (...)
    dsa master bond0

Отметим, что для портов CPU в LAG использование атрибута netlink IFLA_DSA_MASTER не является обязательным, а DSA реагирует на изменение атрибута IFLA_MASTER у текущего ведущего устройства (eth0) и переносит все пользовательские порты на новый интерфейс верхнего уровня eth0
(bond0). Аналогично, при удалении bond0 с помощью RTM_DELLINK DSA переносит пользовательские порты, связанные с этим интерфейсом, на первое физическое устройство DSA master, выбираемое по описанию микрокода (фактически происходит возврат к начальной конфигурации).

В системе с числом физических портов CPU больше 2 возможно сочетание статической привязки пользовательских портов к портам CPU с LAG между DSA master. Невозможно статически назначить пользовательский порт в направлении DSA master, имеющего какие-либо интерфейсы верхнего уровня (включая устройства LAG, в этом случае ведущим всегда будет LAG).

Разрешается изменение близости пользовательского порта к DSA master (и порту CPU) для обеспечения динамического перераспределения в зависимости от трафика.

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

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

nmalykh@protokols.ru

1Receive Packet Steering – управление приёмом пакетов.

2Wake-on-LAN – пробуждение из ЛВС.

3См. https://www.kernel.org/pub/linux/utils/net/iproute2/

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

kas

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

Руководство пользователя kas

PDF

По материалам https://kas.readthedocs.io/en/latest/.

Этот инструмент предназначен для упрощения организации проектов на основе bitbake.

Поддержка инструментария OpenEmbedded начинается с bitbake на этапе 2. Загрузка исходных кодов и настройка обычно выполняется вручную, как описано в файлах README. Вместо этого kas использует файл конфигурации проекта и самостоятельно выполняет загрузку и настройку конфигурации.

Основные свойства инструмента сборки включают:

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

Установка

Для работы с kas должны быть установлены пакеты:

Python 3
distro Python 3;
jsonschema Python 3;
PyYAML Python 3 (необязательно, служит для поддержки файлов yaml);
kconfiglib Python 3 (необязательно, служит для подключаемого модуля menu);
NEWT Python 3 distro (необязательно, служит для подключаемого модуля menu).

Для установки kas в репозиторий python site-package служит команда

$ sudo pip3 install .

Работа с пакетом

Имеется по меньшей мере 4 варианта работы с пакетом kas.

Локальная установка с помощью pip (обеспечивает поддержку команды kas).
Использование локального образа контейнера. Для этого загружается сценарий kas-container из репозитория kas, применяемый вместо команды kas. Версия сценария соответствует версии kas и образа kas.
Использование образа контейнера в сценариях интерпретатора команд. Для этого в сценарий включается строка ghcr.io/siemens/kas/kas[-isar][:<x.y>], запрашивающая образ контейнера в качестве рабочей среды. Доступные версии образов можно получить по ссылкам https://github.com/orgs/siemens/packages/container/kas%2Fkas/versions и https://github.com/orgs/siemens/packages/container/kas%2Fkas-isar/versions.
Использование оболочки run-kas. В этом случае в приведённых ниже примерах следует заменять kas на path/to/run-kas.

Для запуска сборки служит команда

$ kas build /path/to/kas-project.yml

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

$ kas shell /path/to/kas-project.yml -c 'bitbake dosfsutils-native'

Пакет kas будет помещать загружаемые файлы и артефакты сборки в текущий каталог (откуда вызывается kas). Можно указать иной каталог с помощью переменной окружения KAS_WORK_DIR.

Примеры использования

Начальная сборка (установка)

$ mkdir $PROJECT_DIR
$ cd $PROJECT_DIR
$ git clone $PROJECT_URL meta-project
$ kas build meta-project/kas-project.yml

Обновление или новая сборка

$ cd $PROJECT_DIR/meta-project
$ git pull
$ kas build kas-project.yml

Интерактивная настройка конфигурации

$ cd $PROJECT_DIR/meta-project
$ kas menu
$ kas build  # необязательно, если не вызывается через меню kas

Подключаемые модули

Субкоманды kas реализованы в форме подключаемых модулей (plugin), каждый из которых обычно поддерживает 1 команду.

build

Этот модуль реализует команду kas build. При выполнении команды kas извлекает (checkout) репозитории, организует среду сборки, а затем вызывает bitbake для сборки целей (target), указанных в файле конфигурации. Например, для сборки с конфигурацией из файла kas-project.yml служит команда

kas build kas-project.yml

checkout

Этот модуль реализует команду kas checkout. При выполнении команды kas извлекает (checkout) репозитории и организует каталог сборки в соответствии с файлом конфигурации. Эта команда полезна в случаях, когда нужно проверить конфигурацию или изменить какой-либо из выбранных уровней до начала сборки. Например, для установки конфигурации, заданной в файле kas-project.yml, служит команда

kas checkout kas-project.yml

dump

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

При запуске с опцией –lock создаётся спецификация блокировки, содержащая лишь точные указания каждого репозитория. Это может быть полезно для фиксации плавающих веток при сохранении простого пути обновления. При задании вместе с опцией –inplace создаётся файл блокировки вместе (см. kas.includehandler.IncludeHandler).

Следует отметить, что

выгруженная конфигурация идентична семантически, но побитово;
все указанные репозитории извлекаются для устранения конфликтов;
все ссылки (refspec) преобразуются (resolv) до применения правок (patch).

Например, для вывода конфигурации, представляющей окончательную конфигурацию сборки kas-project.yml:target-override.yml можно ввести команду

kas dump kas-project.yml:target-override.yml > kas-project-expanded.yml

Созданный файл конфигурации можно использовать для передачи в kas

kas build kas-project-expanded.yml

Ниже представлен пример использования механизма блокировки (повторный вызов для воссоздания файла блокировки) для создания файла блокировки kas-project.lock.yml

kas dump --lock --inplace --update kas-project.yml

Созданный файл блокировки будет автоматически применяться для закрепления версии (ревизии)

kas build kas-project.yml

Отметим, что файлы блокировки следует регистрировать в системе контроля версий (VCS).

for-all-repos

Этот модуль реализует команду kas for-all-repos, при выполнении которой kas просматривает (checkout) указанные в выбранном файле конфигурации репозитории и выполняет для каждого заданную команду. Это может служить для запроса состояний репозиториев, автоматизации операций (таких как архивирование использованных при сборке уровней) или выполнения иных команд.

Например, для вывода хэш-значений представлений (commit), использованных в каждом репозитории из файла kas-project.yml (в предположении, что это репозитории git), можно воспользоваться командой

kas for-all-repos kas-project.yml 'git rev-parse HEAD'

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

KAS_REPO_NAME – имя текущего репозитория, определяемое свойством name или ключом этого репозитория в файле конфигурации.
KAS_REPO_PATH – путь к локальному каталогу, в котором хранится репозиторий, относительно каталога, откуда запускается kas.
KAS_REPO_URL – URL, откуда был извлечён репозиторий, или пустая строка, если в файле конфигурации нет удалённого URL.
KAS_REPO_REFSPEC – ссылка на спецификацию (refspec) для этого репозитория или пустая строка, если в файле конфигурации нет refspec.

Этот модуль реализует команду kas menu, открывая меню конфигурации, как описано в файле Kconfig. Обрабатываются все имеющиеся файлы конфигурации с сохранёнными настройками, записывается окончательный выбор и вызывается модуль сборки (build plugin), если это запрошено пользователем. Для использования этого модуля нужен файл Kconfig. Меня может задавать указанные ниже типы переменных конфигурации, которые модуль будет транслировать в настройки kas.

Файлы конфигурации kas, которые будут включаться в создаваемую конфигурацию. Файлы берутся из строковых переменных kconfig с префиксом KAS_INCLUDE_.
Цели bitbake, которые нужно собрать с помощью создаваемой конфигурации. Цели берутся из строковых переменных kconfig с префиксом KAS_TARGET_.
Используемая система сборки build_system. Значение определяется статической переменной KAS_BUILD_SYSTEM (openembedded, oe или isar).
Переменные конфигурации bitbake, добавляемые к раздел local_conf_header создаваемой конфигурации. Остальные переменные kconfig (string, integer, hex) трактуются обычным способом.

Полное описание языка Kconfig доступно по ссылке https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html.

Модуль menu записывает выбранную конфигурацию в файл .config.yaml в рабочем каталоге kas, а также считывает прежний выбор, если такой файл уже имеется. Файл .config.yaml содержит выбранную конфигурацию (ключ menu_configuration), а также действующие настройки, которые могут использоваться при вызове kas
build или иных команд kas.

shell

Этот модуль реализует команду kas shell, просматривая (checkout) репозитории, организуя среду сборки и запуская в ней интерпретатор команд (shell). Это может служить для запуска bitbake вручную со своими опциями или выполнения таких команд, как runqemu. Например, для запуска оболочки в среде сборки проекта kas-project.yml можно использовать команду

kas shell kas-project.yml

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

kas shell kas-project.yml -c 'runqemu'

Конфигурация проекта

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

# Каждый файл должен иметь заголовок, предоставляющий kas сведения
# о контексте данного файла.
header:
  # Запись version в заголовке указывает, для какой версии формата
  # конфигурации создан файл. Это позволяет kas проверить совместимость.
  # Версия указывается целым числом, которое увеличивается при каждой
  # смене формата.
  version: x
# Машина указывается как в файле local.conf для bitbake.
machine: qemux86-64
# Имя дистрибутива (distro) как в файле local.conf для bitbake.
distro: poky
repos:
  # Эта запись включает репозиторий, где находится файл конфигурации
  # для bblayers.conf
  meta-custom:
  # Здесь указывается список уровней из репозитория poky для 
  # bblayers.conf
  poky:
    url: "https://git.yoctoproject.org/git/poky"
    refspec: 89e6c98d92887913cadf06b2adb97f26cde4849b
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:

Минимальный входной файл содержит разделы header, machine, distro и repos. Можно также включить в файл разделы bblayers_conf_header и local_conf_header, содержащие строки, добавляемые к заголовкам соответствующих файлов (bblayers.conf и local.conf).

bblayers_conf_header:
  meta-custom: |
    POKY_BBLAYERS_CONF_VERSION = "2"
    BBPATH = "${TOPDIR}"
    BBFILES ?= ""
local_conf_header:
  meta-custom: |
    PATCHRESOLVE = "noop"
    CONF_VERSION = "1"
    IMAGE_FSTYPES = "tar"

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

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

Включение файлов конфигурации из основного дерева

Возможно включение конфигурационных файлов kas из того же репозитория или уровня, как показано ниже.

header:
  version: x
  includes:
    - base.yml
    - bsp.yml
    - product.yml

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

Включение файлов из других репозиториев

Можно также включать конфигурационные файлы из других репозиториев, как показано ниже.

header:
  version: x
  includes:
    - repo: poky
      file: kas-poky.yml
    - repo: meta-bsp-collection
      file: hw1/kas-hw-bsp1.yml
    - repo: meta-custom
      file: products/product.yml
repos:
  meta-custom:
  meta-bsp-collection:
    url: "https://www.example.com/git/meta-bsp-collection"
    refspec: 3f786850e387550fdab836ed7e6dc881de23001b
    layers:
      # Кроме уровней, добавленных из этого репозитория в 
      # hw1/kas-hw-bsp1.yml, добавляется метауровень bsp.
      meta-custom-bsp:
  poky:
    url: "https://git.yoctoproject.org/git/poky"
    refspec: 89e6c98d92887913cadf06b2adb97f26cde4849b
    layers:
      # Если kas-poky.yml уже добавляет уровень meta-yocto-bsp и он 
      # не нужен в bblayer этого проекта, его можно переопределить
      meta-yocto-bsp: excluded

Местоположение файлов определяется относительно репозитория git.

Механизм включения собирает и объединяет содержимое сверху вниз (по файлу) и в глубину (структуры). Это означает, что установки из одного включённого файла могут быть переопределены последующими файлами, а установки из последнего включаемого файла – текущим файлом. При слиянии все словари объединяются рекурсивно с сохранением порядка, в котором записи добавляются в словарь. Это означает, что записи local_conf_header добавляются в файл local.conf в том же порядке, как они были указаны в других файлах конфигурации. Отметим, что порядок записей не сохраняется внутри одного включаемого файла, поскольку синтаксический анализатор создаёт обычные неупорядоченные словари.

Включение файлов конфигурации из команды

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

$ kas build kas-base.yml:debug-image.yml:board.yml

Это эквивалентно статическому включению, например, некого файла kas-combined.yml, показанного ниже.

header:
  version: x
  includes:
    - kas-base.yml
    - debug.image.yml
    - board.yml

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

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

Работа с файлами блокировки

В kas поддерживается применение файлов блокировки для привязывания репозиториев к точному указанию ссылок (refspec, например, ссылок SHA-1 для git). Таким образом, файл блокировки переопределяет лишь refspec, заданные в файле kas. При извлечении (checkout) kas проверяет наличие файла <filename>.lock.<ext> рядом с первым файлом, указанным в строке команды kas. Если такой файл имеется, kas добавляет имя этого файла в свою строку команды и выполняет запрошенную операцию.

Ниже приведён пример для файла kas/kas-isar.yml и соответствующего файла блокировки kas/kas-isar.lock.yml.

kas/kas-isar.yml:
# [...]
repos:
  isar: 
    url: https://github.com/ilbers/isar.git
    refspec: next
kas/kas-isar.lock.yml:
header:
  version: 14
overrides:
  repos:
    isar:
      refspec: 0336610df8bb0adce76ef8c5a921c758efed9f45

Модуль dump предоставляет вспомогательные функции для упрощения создания и обновления фалов блокировки.

Содержимое файла конфигурации

header: dict [обязательно]

Заголовок конфигурационного файла kas, содержащий сведения о контексте файла конфигурации.

version: integer [обязательно]

Позволяет kas проверить совместимость с файлом. Описание версий приведено в разделе Версии формата конфигурации.

includes: list [необязательно]

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

- item: string – указывает путь к файлу конфигурации kas от корня репозитория с текущим файлом;
- item: dict – применяется для включения файлов из других репозиториев
  - repo: string [обязательно] – идентификатор репозитория, где размещается файл (репозиторий должен быть указан в словаре репозиториев как <repo-id>
  - file: string [обязательно] – путь к файлу от корня указанного репозитория.

build_system: string [необязательно]

Указывает систему сборки на основе bitbake (openembedded или oe, isar). При установке этой переменной поиск kas сценария инициализации ограничивается ограничивается репозиториями, заданными для oe-init-build-env и isar-init-build-env, соответственно. Если kas-container находит это свойство в файле конфигурации kas верхнего уровня, автоматически выбирается требуемый образ контейнера и режим вызова.

defaults: dict [необязательно]

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

repos: dict [необязательно]

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

refspec: string [необязательно] – задаёт принятое по умолчанию свойство refspec для всех репозиториев, где оно не переопределено.
patches: dict [необязательно] – этот ключ может содержать заданные по умолчанию значения некоторых свойств исправлений (patch) для репозитория. Эти значения можно переопределить установкой иного значения в данном исправлении.
- repo: string [необязательно] – устанавливает применение принятого по умолчанию свойства repo ко всем исправлениям в репозитории, где оно не переопределено.

machine: string [необязательно]

Содержит значение переменной MACHINE, записываемое в файл local.conf. Значение можно переопределить через переменную KAS_MACHINE, по умолчанию задано значение qemux86-64.

distro: string [необязательно]

Содержит значение переменной DISTRO, записываемое в файл local.conf. Значение можно переопределить через переменную KAS_DISTRO, по умолчанию задано значение poky.

target: string [необязательно] or list [необязательно]

Указывает цель (или список целей) сборки с помощью bitbake. Значение можно переопределить через переменную KAS_TARGET, по умолчанию задано значение core-image-minimal. При указании нескольких целей в переменной разделителями целей служат символы пробела.

env: dict [необязательно]

Содержит имена переменных окружения с принятыми по умолчанию значениями или None. Эти переменные доступны bitbake через BB_ENV_EXTRAWHITE и могут быть переопределены переменными окружения, в котором запускается kas. В качестве значения может использоваться строка (string) или ничего (None). Строка задаёт принятое по умолчанию значение, а None ведёт лишь к добавлению переменной в BB_ENV_EXTRAWHITE и не меняет окружение запуска kas.

task: string [необязательно]

Указывает задачу для сборки с помощью bitbake. Может быть переопределена переменной KAS_TASK,
по умолчанию принято значение build.

repos: dict [необязательно]

Содержит определения всех доступных репозиториев и уровней.

<repo-id>: dict [необязательно]

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

name: string [необязательно] – задаёт имя, с которым хранится репозиторий. При отсутствии параметра применяется значение <repo-id>.
url: string [необязательно] – url репозитория. Отсутствие параметра отменяет контроль версий.
type: string [необязательно] – тип репозитория для контроля версий (по умолчанию git,
поддерживается также hg).
refspec: string [необязательно] – спецификация выпуска, который следует использовать. При наличии url без указания refspec получаемый выпуск (revision) зависит от принятых по умолчанию настроек контроля версий.
path: string [необязательно] – путь к сохранённому репозиторию. При отсутствии url и path применяется репозиторий, где размещён текущий файл конфигурации.
При отсутствии url и наличии path запись ссылается на каталог, который указывает path. При наличии url и path значение path применяется для переопределения каталога checkout (по умолчанию kas_work_dir + repo.name). При указании в path относительного значения в начало добавляется kas_work_dir.
layers: dict [необязательно] – указывает уровни из данного репозитория, которые следует включить в bblayers.conf. При отсутствии параметра, значении None или пустом словаре в качестве уровня добавляется путь к самому репозиторию. Можно указать точку (.), если в качестве уровня следует добавить сам репозиторий. Это позволяет создавать комбинации вида
```
repos:
  meta-foo:
    url: https://github.com/bar/meta-foo.git
    path: layers/meta-foo
    refspec: master
    layers:
      .:
      contrib:
```
Приведённый фрагмент добавляет layers/meta-foo и layers/meta-foo/contrib из репозитория meta-foo в файл bblayers.conf.
<layer-path>: enum [необязательно] – добавляет уровень с <layer-path> от корневого каталога репозитория в файл bblayers.conf, если значение этого параметра не является одним из списка [disabled, excluded, n, no, 0, false]. Это позволяет переопределять включение уровня в загружаемых позднее файлах.

patches: dict [необязательно]

Указывает правки (patch), которые следует применить в репозитории до его использования.

<patches-id>: dict [необязательно]

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

repo: string [обязательно] – идентификатор репозитория, от которого идёт путь в данной записи.
path: string [обязательно] – путь к одному из patch-файлов или каталогу patchset в формате quilt.

overrides: dict [необязательно]

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

repos: dict [необязательно]

Задаёт сопоставление с записью репозитория верхнего уровня.

<repo-id>: dict [необязательно] – отображение на запись <repo-id>.
- refspec: string [необязательно] – задаёт refspec для переопределения refspec соответствующего репозитория. Значение refspec должно быть распознаваемым (не включать branch или tag).

bblayers_conf_header: dict [необязательно]

Строки, которые следует добавлять в bblayers.conf перед включением какого-либо уровня.

<bblayers-conf-id>: string [необязательно]

Строка, добавляемая в bblayers.conf. Идентификатор записи (<bblayers-conf-id>) следует делать уникальным, если нужно добавлять строки, и можно применять строки, совпадающие со строками из других включаемых файлов, если запись следует переопределять. Строки добавляются в bblayers.conf по алфавитному порядку <bblayers-conf-id> для обеспечения детерминированной генерации конфигурационных файлов.

local_conf_header: dict [необязательно]

Строки, которые следует добавлять в local.conf.

<local-conf-id>: string [необязательно]

Строка, добавляемая в local.conf. Обработка выполняется так же, как для записей bblayers_conf_header.

menu_configuration:: dict [необязательно]

Указывает выбор пользователя для меню Kconfig в проекте. Каждая переменная соответствует переменной конфигурации Kconfig и может иметь тип string, boolean или integer. Содержимое этого ключа обычно поддерживается подключаемым модулем kas menu в файле .config.yaml.

Использование команд

Пакет kas служит инструментом для проектов на основе bitbake.

kas [-h] [--version] [-d] [-l {debug,info,warning,error,critical}]
           {build,checkout,dump,for-all-repos,shell,menu} …

Позиционные аргументы

build, checkout, dump, for-all-repos, shell, menu, а также субкоманда help.

Именованные аргументы

–version

Выводит номер версии программы и завершает работу.

-d, –debug

Включает запись отладочных сведений в системный журнал. Параметр устарел и заменён –log-level debug.

-l, –log-level

Возможные значения: debug, info (принято по умолчанию), warning, error, critical.

Субкоманды

build

Проверка всех требуемых репозиториев и сборка с помощью bitbake в соответствии с файлом конфигурации.

kas build [-h] [--skip SKIP] [--force-checkout] [--update] [--target TARGET]
          [-c TASK]
          [config] [extra_bitbake_args …]

Позиционные аргументы

config

Файл конфигурации. По умолчанию применяется .config.yaml из каталога KAS_WORK_DIR.

extra_bitbake_args

Дополнительные аргументы для передачи bitbake (обычно требуется разделять с помощью –)

Именованные аргументы

–skip

Пропустить этапы сборки SKIP (по умолчанию список пуст).

–force-checkout

Всегда проверять желаемое значение refspec каждого репозитория, отбрасывая любые локальные изменения. По умолчанию отключено (False).

–update

Вносить (pull) новые изменения (upstream) для желаемого refspec, даже если они внесены (checked out) локально. По умолчанию отключено (False).

–target

Задаёт цель для сборки.

-c, –cmd, –task

Задаёт выполняемую задачу.

checkout

Извлекает все требуемые репозитории и организует каталог сборки в соответствии с файлом конфигурации.

kas checkout [-h] [--skip SKIP] [--force-checkout] [--update] [config]

Позиционные аргументы

config

Файл конфигурации. По умолчанию применяется .config.yaml из каталога KAS_WORK_DIR.

Именованные аргументы

–skip

Пропустить этапы сборки SKIP (по умолчанию список пуст).

–force-checkout

–update

dump

Извлекает окончательную конфигурацию и выводит её на stdout. При обработке refspec она происходит до внесения правок (patch).

kas dump [-h] [--skip SKIP] [--force-checkout] [--update]
         [--format {yaml,json}] [--indent INDENT] [--resolve-refs]
         [--resolve-env | --lock] [-i]
         [config]

Позиционные аргументы

config

Файл конфигурации. По умолчанию применяется .config.yaml из каталога KAS_WORK_DIR.

Именованные аргументы

–skip

Пропустить этапы сборки SKIP (по умолчанию список пуст).

–force-checkout

–update

–format

Задаёт формат вывода и может принимать значение yaml (по умолчанию) или json.

–indent

Отступ строк (число пробелов в начале), по умолчанию 4.

–resolve-refs

Заменять плавающие ссылки точными SHA. По умолчанию отключено (False).

–resolve-env

Устанавливает вместо принятого по умолчанию env указанное значение. По умолчанию отключено (False).

–lock

Создает файл блокировки с точными SHA. По умолчанию отключено (False).

-i, –inplace

Обновить файл блокировки (требует –lock). По умолчанию отключено (False).

for-all-repos

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

kas for-all-repos [-h] [--skip SKIP] [--force-checkout] [--update] [-E]
                  [config] command

Позиционные аргументы

config

Файл конфигурации. По умолчанию применяется .config.yaml из каталога KAS_WORK_DIR.

command

Строка, указывающая команду для выполнения

Именованные аргументы

–skip

Пропустить этапы сборки SKIP (по умолчанию список пуст).

–force-checkout

–update

-E, –preserve-env

Сохранять текущий пользовательский блок окружения. По умолчанию отключено (False).

shell

Запускает интерпретатор команд (shell) в среде сборки.

kas shell [-h] [--skip SKIP] [--force-checkout] [--update] [-E] [-k]
          [-c COMMAND]
          [config]

Позиционные аргументы

config

Файл конфигурации. По умолчанию применяется .config.yaml из каталога KAS_WORK_DIR.

Именованные аргументы

–skip

Пропустить этапы сборки SKIP (по умолчанию список пуст).

–force-checkout

–update

-E, –preserve-env

Сохранять текущий пользовательский блок окружения. По умолчанию отключено (False).

-k, –keep-config-unchanged

Пропустить этапы, изменяющие конфигурацию. По умолчанию отключено (False).

-c, –command

Выполнить указанную команду. По умолчанию команда не задана.

Переменные окружения

KAS_WORK_DIR

Путь к рабочему каталогу kas. По умолчанию текущий рабочий каталог.

KAS_BUILD_DIR

Путь к каталогу сборки, по умолчанию ${KAS_WORK_DIR}/build.

KAS_REPO_REF_DIR

Путь к каталогу образцовых репозиториев, применяемых для клонирования. Чтобы пакет kas находил эти репозитории, они должны именоваться определенным способом – URL репозиториев транслируются, например, https://github.com/siemens/meta-iot2000.git преобразуется в имя github.com.siemens.meta-iot2000.git. Не найденные репозитории будут закрыты. В одном каталоге может работать одновременно
несколько экземпляров kas, если базовая файловая система совместима с POSIX.

KAS_DISTRO KAS_MACHINE KAS_TARGET KAS_TASK

Переопределяют соответствующие установки конфигурационного файла.

KAS_PREMIRRORS DISTRO_APT_PREMIRRORS

Задаёт варианты подстановки для URL репозиториев. Подобно bitbake PREMIRRORS, эта переменная состоит из записей, размещённых по одной в строке. Каждая запись задаёт регулярное выражение для сопоставления с URL и отделённую пробелом замену. Например, http://.*.someurl.io/ http://localmirror.net/

SSH_PRIVATE_KEY

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

SSH_PRIVATE_KEY_FILE

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

SSH_AUTH_SOCK

Сокет аутентификации SSH, служащий для клонирования через SSH (альтернатива SSH_PRIVATE_KEY или SSH_PRIVATE_KEY_FILE).

DL_DIR SSTATE_DIR TMPDIR

Переменные окружения, передаваемые в среду bitbake.

http_proxy https_proxy ftp_proxy no_proxy

Определяют конфигурацию прокси для bitbake.

GIT_PROXY_COMMAND NO_PROXY

Задаёт прокси для естественной выборки git. Значение NO_PROXY преобразуется в сценарий OE oe-git-proxy.

SHELL

Командный интерпретатор для использования с подключаемым модулем shell.

TERM

Опции терминала для подключаемого модуля shell.

AWS_CONFIG_FILE AWS_SHARED_CREDENTIALS_FILE

Путь к файлу конфигурации и свидетельствам (credential), которые копируются в домашний каталог kas.

GIT_CREDENTIAL_HELPER GIT_CREDENTIAL_USEHTTPPATH

Задаёт и настраивает вспомогательную функцию (helper) git для свидетельств в .gitconfig пользователя kas.

NETRC_FILE

Путь к файлу .netrc, который копируется в домашний каталог kas как .netrc.

CI_SERVER_HOST CI_JOB_TOKEN

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

BB_NUMBER_THREADS PARALLEL_MAKE

Переменные окружения для управления одновременной работой.

Версии формата конфигурации

1 (0.10)

Добавлен механизм включения и проверка версии.

2

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

3

Добавлен ключ task, позволяющий указать задачу для выполнения (bitbake
-c).

4

Добавлен ключ target, разрешающий список имён целей.

5

Использование целей multiconfig:* автоматически добавляет подобающие записи BBMULTICONFIG в файл local.conf.

6

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

7

Свойство type для repos позволяет указать применяемую систему сборки.

8

Свойство patches для repos позволяет применить к репозиторию дополнительные изменения (patch).

9

Ключ defaults применяется для задания принятого по умолчанию значения свойство репозитория refspec и свойство исправлений repo. Эти значения применяются, если соответствующие свойства не заданы для репозитория или исправлений.

10

Добавлено свойство build_system для выбора системы сборки OE или Isar.

11

Строковый элемент includes теперь указывает путь относительно репозитория. Пути относительно файла поддерживаются с выдачей предупреждения. Файл bblayers.conf создаётся с принятыми по умолчанию значениями переменных BBPATH и BBFILES, которые можно переопределить через bblayers_conf_headers. Ключ menu_configuration сохраняет выбор, сделанный через kas menu, в файле конфигурации (ключ проверяется только этим модулем).

12

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

13

Переменные из раздела env могут иметь значение None, задающее их экспорт лишь в «белый список» bb env.

14

Запись overrides на верхнем уровне можно применять для фиксации плавающих refspec репозитория.

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

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

nmalykh@protokols.ru

Рубрика: Linux, RISC-V | Оставить комментарий

RFC 9406 HyStart++: Modified Slow Start for TCP

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

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.

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

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

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

К документу применимы права и ограничения, перечисленные в 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] или SCTP³ [RFC9260].

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

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 – это доля⁴ 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

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

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.

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

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

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. Сокращения

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

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

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

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

SLA

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

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 (например, маршруты VRF³, записи MAC⁴, метрика каналов и интерфейсов), могут быть заданы свои уведомления, позволяющие получить более полные данные. Могут быть заданы периодические обновления [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, или ASBR⁵, как определено в [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-\⁶
                                      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

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

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.

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

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 – кот¹

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

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)

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

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.

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

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

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. Уровни требований

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

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

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

Architectural Principles for a Quantum Internet

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

PDF

Аннотация

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

2.2. Кубит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.4. Доставка

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

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

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

5.1. Проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

Registration Procedures for Private Enterprise Numbers (PENs)

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

PDF

Аннотация

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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. Уровни требований

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

Length

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

Flex-Algorithm

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

Metric-Type

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

Метрика IGP

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

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

Length

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

Flex-Algorithm

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

Metric-Type

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

Метрика IGP

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Type

Length

Зависит от размера Extended 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

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

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

Length

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

Flags

                       0 1 2 3 4 5 6 7...
                      +-+-+-+-+-+-+-+-+...
                      |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

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

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

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

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

Length

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

Flags

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

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

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

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

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

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

7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV

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

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

Type

Length

Определяется числом значений 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

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

Флаг в позиции 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

Length

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

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.

Проверяется наличие правил исключения Administrative Group в FAD. Если такие правила имеются, проверяется, не установлен ли для канала цвет, являющийся частью правила, и при обнаружении такого цвета канал должен исключаться из расчёта.
Проверяется наличие правил исключения SRLG в FAD. Если такие правила имеются, проверяется, входит ли канал в исключаемую SRLG, и при обнаружении вхождения канал должен исключаться из расчёта.
Проверяется наличие правил включения любой (include-any) Administrative Group в FAD. Если такие правила имеются, проверяется, установлен ли для канала цвет, являющийся частью правила, и при отсутствии такого цвета канал должен исключаться из расчёта.
Проверяется наличие правил включения всех (include-all) Administrative Group в FAD. Если такие правила имеются, проверяется, установлены ли для канала все цвета, являющиеся частью правила, и если не установлены все эти цвета, канал должен исключаться из расчёта.
Если в FAD применяется что-либо, отличное от метрики IGP (5. Анонсирование определения гибкого алгоритма), и такая метрика не анонсируется для конкретного канала в топологию, где выполняется расчёт, такой канал должен исключаться из расчёта. Метрику со значением 0 недопустимо учитывать в этом случае.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В контексте одного Flex-Algorithm SRLG можно применять для расчёта резервных путей, как описано в [RTGWG-SEGMENT-ROUTING-TI-LFA]. Для этого не требуется связывать какое-либо ограничение SRLG с данным определением Flex-Algorithm.
В контексте нескольких Flex-Algorithm SRLG можно применять для создания непересекающихся наборов путей за счёт исключения каналов, относящихся к конкретной группе SRLG из топологии, где пути рассчитываются с конкретным Flex-Algorithm. Такое исключение:
- упрощает использование уже развёрнутых конфигураций SRLG для организации непересекающихся путей между двумя или более Flex-Algorithms;
- требует явного связывания данного Flex-Algorithm с конкретным набором ограничений SRLG, как указано в параграфах 6.5 и 7.5.

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

15.3. Max-Metric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18.1.1. Реестр IGP Algorithm Types

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

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

Значение	Описание	Документ
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

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

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

[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 | Оставить комментарий