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

Internet Engineering Task Force (IETF)                K. Talaulikar, Ed.
Request for Comments: 9351                                     P. Psenak
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                                 S. Zandi
                                                                G. Dawra
                                                                LinkedIn
                                                           February 2023

Border Gateway Protocol – Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Расширения BGP-LS для анонсирования гибкого алгоритма

PDF

Аннотация

Гибким алгоритмом (Flexible Algorithm) называется решение, позволяющее некоторым протоколам маршрутизации (например, OSPF и IS-IS) рассчитывать пути через сеть на основе заданных пользователем (поэтому более гибких) ограничений и показателей. Расчёт выполняют маршрутизаторы, участвующие в конкретной сети, распределенно с использованием определения гибкого алгоритма алгоритма (Flexible Algorithm Definition или FAD). Это определение предоставляется не одном или нескольких маршрутизаторах и распространяется через сеть путём лавинной рассылки OSPF и IS-IS.

Состояние канала для протокола граничного шлюза (Border Gateway Protocol – Link State или BGP-LS) позволяет собрать из сети различные сведения. Этот документ задаёт расширения семейства адресов BGP-LS для анонсирования FAD как части топологических сведений о сети.

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

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

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

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

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

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

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

1. Введение

Классический протокол IGP (например, OSPF и IS-IS) рассчитывает лучшие пути через сеть на основе метрики IGP, назначенной для каналов сети. Во многих развёрнутых сетях применяется решение на основе RSVP-TE [RFC3209] или политики маршрутизации по сегментам (Segment Routing или SR) [RFC8402] для передачи трафика по пути, рассчитанному с использованием других показателей или ограничесний, нежели для кратчайшего пути IGP. В [RFC9350] задано решение с гибким алгоритмом, позволяющее самим IGP рассчитывать пути через сеть на основе ограничений.

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

• типа применяемого расчёта (например, кратчайший путь);

• типа применяемой метрики (например, IGP или TE);

• набора применяемых ограничений (например, включение или исключение некоторых каналов по близости).

Работа гибкого алгоритма IGP подробно описана в [RFC9350].

Расширения BGP-LS для SR заданы в [RFC9085] и в [IDR-BGPLS-SRV6-EXT] для SR-MPLS и SRv6³. Они включают расширения для анонсирования сведений SR, содержащих разные типы идентификаторов сегментов (Segment Identifier или SID).

• SR Algorithm TLV указывает участие узла в расчёте Flexible Algorithm.

• Prefix-SID TLV указывает привязку Prefix-SID к конкретному Flexible Algorithm для пересылки SR-MPLS.

• SRv6 Locator TLV указывает локатор для конкретного Flexible Algorithm при пересылке SRv6.

Этот документ задаёт расширения BGP-LS для анонсирования сведений FAD, чтобы обеспечить возможность изучить сопоставления номера гибкого алгоритма с его определением в каждой области или домене базового протокола IGP. Это определение указывает тип применяемого расчёта и ограничения для данного Flexible Algorithm, которые могут применяться для организации сквозных путей SR Policy через множество доменов с использованием подходящих SID в списке сегментов [RFC9256]. Например, при указании Flexible Algorithm Prefix-SID (для SR-MPLS) или End SID (для SRv6) граничные маршрутизаторы областей (Area Border Router или ABR) или автономных систем (Autonomous System Border Router или ASBR), соответствующие определению, которое оптимизирует показатель задержки, могут построить сквозной путь с малой задержкой через домены IGP с минимальным числом SID в списке SID.

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

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

2. Обзор расширений BGP-LS для гибкого алгоритма

BGP-LS [RFC7752] задаёт Node NLRI для анонсирования узлов и их атрибутов, Link NLRI для анонсирования каналов и их атрибутов, Prefix NLRI для анонсирования префиксов и их атрибутов с применением атрибута BGP-LS.

Анонсируемые узлом FAD считаются атрибутами уровня узла и анонсируются в соответствии с разделом 3.

Различные атрибуты каналов, такие как близость и группы общего риска (Shared Risk Link Group или SRLG), применяемые в расчётах маршрутов с помощью гибкого алгоритма в IS-IS и OSPF, анонсируются в этих протоколах с использованием анонсов зависящих от приложения атрибутов каналов (Application-Specific Link Attribute или ASLA), как описано в [RFC8919], [RFC8920] и [RFC9350]. Расширения BGP-LS для анонсов ASLA заданы в [RFC9294].

Показатель префикса гибкого алгоритма (Flexible Algorithm Prefix Metric или FAPM) считается атрибутом префикса и анонсируется в соответствии с разделом 4.

3. TLV задания гибкого алгоритма

Этот документ задаёт необязательный TLV атрибута BGP-LS, связанного с Node NLRI, который называется Flexible Algorithm Definition TLV или FAD TLV. Формат TLV показан на рисунке 1

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

Рисунок 1. Flexible Algorithm Definition TLV.

Type

1039

Length

Общий размер поля значений (включая любые sub-TLV) в октетах. Размер должен быть не меньше 4.

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Metric-Type

1-октетное значение, указывающее тип метрики в соответствии с [RFC9350].

Calc-Type

1-октетное значение, указывающее тип расчёта в соответствии с [RFC9350].

Priority

1-октетное значение, указывающее анонса FAD в соответствии с [RFC9350].

Sub-TLVs

Необязательные sub-TLV, описанные ниже.

FAD TLV анонсируется в атрибуте BGP-LS вместе с Node NLRI и выводится из анонсов IGP:

• для IS-IS из IS-IS Flexible Algorithm Definition sub-TLV в [RFC9350];

• для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Definition TLV в [RFC9350].

Атрибут BGP-LS, связанный с Node NLRI может включать FAD TLV, соответствующие FAD для каждого алгоритма, анонсируемого этим узлом.

В последующих параграфах заданы sub-TLV для FAD TLV.

3.1. Flexible Algorithm Exclude-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Exclude-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и исключения каналов с заданной близостью из расчётов конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Flexible Algorithm Exclude-Any Affinity Sub-TLV.

Type

1040

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Exclude-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Exclude-Any Affinity sub-TLV выводится из Flexible Algorithm Exclude-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.2. Flexible Algorithm Include-Any Affinity Sub-TLV

Необязательный Flexible Algorithm Include-Any Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 3.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Flexible Algorithm Include-Any Affinity Sub-TLV.

Type

1041

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-Any EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-Any Affinity sub-TLV выводится из Flexible Algorithm Include-Any Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.3. Flexible Algorithm Include-All Affinity Sub-TLV

Необязательный Flexible Algorithm Include-All Affinity sub-TLV служит для переноса ограничений близости, связанных с FAD, и включения всех каналов с заданной близостью в расчёт конкретного алгоритма, как описано в [RFC9350]. Близость выражается в терминах расширенной группы администрирования (Extended Admin Group или EAG), заданных в [RFC7308]. Формат sub-TLV показан на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Flexible Algorithm Include-All Affinity Sub-TLV.

Type

1042

Length

Общий размер поля значения, зависящий от размера EAG. Значение должно быть больше 0 и кратно 4.

Include-All EAG

Значение EAG в соответствии с [RFC9350].

Информация Flexible Algorithm Include-All Affinity sub-TLV выводится из Flexible Algorithm Include-All Admin Group sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.4. Flexible Algorithm Definition Flags Sub-TLV

Необязательный Flexible Algorithm Definition Flags sub-TLV служит для переноса связанных с FAD флагов, используемых в расчёте конкретного алгоритма, как описано в [RFC9350]. Формат sub-TLV показан на рисунке 5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Flags (переменный)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Flexible Algorithm Definition Flags Sub-TLV.

Type

1043

Length

Общий размер поля значения, зависящий от размера флагов. Значение должно быть больше 0 и кратно 4.

Flags

Битовая маская, служащая для представления фланов FAD, как описано в [RFC9350].

Информация Flexible Algorithm Definition Flags sub-TLV выводится из Flexible Algorithm Definition Flags sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.5. Flexible Algorithm Exclude SRLG Sub-TLV

Необязательный Flexible Algorithm Exclude SRLG sub-TLV служит для переноса сведений SRLG, связанных с FAD, и исключения каналов, связанных с любой из указанных групп SRLG, из расчётов конкретного алгоритма, как описано в [RFC9350]. SRLG, связанные с каналом, передаются в BGP-LS Shared Risk Link Group (TLV 1096) [RFC7752]. Формат sub-TLV показан на рисунке 6.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Shared Risk Link Group Values (переменный)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Flexible Algorithm Exclude SRLG Sub-TLV.

Type

1045

Length

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

Shared Risk Link Group Values

Обно или несколько значений SRLG размером по 4 октета, как описано в [RFC9350].

Информация Flexible Algorithm Exclude SRLG sub-TLV выводится из Flexible Algorithm Exclude SRLG sub-TLV для IS-IS и OSPF в соответствии с [RFC9350].

3.6. Flexible Algorithm Unsupported Sub-TLV

Сигнализация OSPF и IS-IS для FAD допускает расширения через новые sub-TLV в рамках соответствующего IGP Flexible Algorithm Definition TLV. Как указано в параграфе 5.3 [RFC9350], важно, чтобы определение FAD был понятно целиком любому, кто использует его для расчётов. Таким образом, FAD отличается от большинства других расширений протокола, где пропуск или игнорирование непонятных сведений sub-TLV не меняет поведения.

Необязательный Flexible Algorithm Unsupported sub-TLV применяется для индикации наличия неподдерживаемых FAD sub-TLV. Потребность в этом sub-TLV возникает, когда реализация BGP-LS на анонсирующем узле не поддерживает какой-либо из FAD sub-TLV, из имеющихся в анонсе IGP. Формат sub-TLV показан на рисунке 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  | типы sub-TLV (переменный) ...                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Flexible Algorithm Unsupported Sub-TLV.

Type

1046

Length

Общий размер поля значения в октетах (включая любые содержащиеся типы sub-TLV).

Protocol-ID

Указывает BGP-LS Protocol-ID протокола, из которого FAD анонсируется через BGP-LS. Значения берутся из реестра IANA BGP-LS Protocol-IDs” subregistry under the “Border Gateway Protocol – Link State (BGP-LS) Parameters <https://www.iana.org/assignments/bgp-ls-parameters/>.

sub-TLV types

Необязательный набор типов sub-TLV, которые не поддерживаются узлом, создавшим анонс BGP-LS. Размер каждого sub-TLV зависит от протокола, указанного полем Protocol-ID. Например, для IS-IS, каждый тип sub-TLV имеет размер 1 октет, а для OSPF – 2 октета.

Узел, создающий анонс, должен включать Flexible Algorithm Unsupported sub-TLV, когда он сталкивается с неподдерживаемым им sub-TLV в соответствующем FAD анонса IS-IS или OSPF. При анонсировании Flexible Algorithm Unsupported sub-TLV следует включать зависимые от протокола типы неподдерживаемых sub-TLV (для диагностики).

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

4. Flexible Algorithm Prefix Metric TLV

Этот документ задаёт необязательный BGP-LS Attribute TLV, связанный с Prefix NLRI и называемый Flexible Algorithm Prefix Metric TLV или FAPM TLV. Формат TLV показан на рисунке 8.

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

Рисунок 8. Flexible Algorithm Prefix Metric TLV.

Type

1044

Length

8 октетов

Flexible Algorithm (Flex Algo)

1-октетное значение, указывающее номер гибкого алгоритма (128 – 255) в соответствии с [RFC9350].

Flags

1-октетное значение, применимое только для OSPF, как указано в [RFC9350]. Для IS-IS должно быть 0.

Reserved

2-октетное значение, которое должно устанавливаться в 0 источником и должно игнорироваться получателем.

Metric

4-октетное поле для передачи сведений о метрике.

FAPM TLV анонсируется в атрибуте BGP-LS вместе с Prefix NLRI и выводится из анонсов IGP:

• для IS-IS из IS-IS Flexible Algorithm Prefix Metric sub-TLV в [RFC9350];

• для OSPFv2 и OSPFv3 из OSPF Flexible Algorithm Prefix Metric sub-TLV в [RFC9350].

Атрибут BGP-LS, связанный с Prefix NLRI может включать FAPM TLV, соответствующие Flexible Algorithm Prefix Metric для каждого алгоритма, анонсируемого этим узлом.

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

Агентство IANA выделило в ресстре BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs <https://www.iana.org/assignments/bgp-ls-parameters> коды для TLV и sub-TLV, указанные в таблице 1.

Таблица 1. Коды TLV для гибких алгоритмов.

 

Код TLV	Описание
1039	Определение гибкого алгоритма
1040	Flexible Algorithm Exclude-Any Affinity
1041	Flexible Algorithm Include-Any Affinity
1042	Flexible Algorithm Include-All Affinity
1043	Flexible Algorithm Definition Flags
1044	Flexible Algorithm Prefix Metric
1045	Flexible Algorithm Exclude SRLG
1046	Flexible Algorithm Unsupported

 

6. Вопросы управляемости

Заданные в этом документе расширения дополняют имеющиеся топологические сведения IGP, которые могут распространяться через [RFC7752]. Процедуры и расширения, заданные в этом документе, не влияют на операции и управление протоколом BGP сверх указанного в разделе «Вопросы управляемости» [RFC7752]. В частности проверки формата NLRI из раздела «Контроль отказов» в [RFC7752] охватывают TLV для BGP-LS NLRI из этого документа.

Расширения из этого документа не задают новых аспектов конфигурации или настройки в BGP и BGP-LS. Спецификация моделей BGP на основе [IDR-BGP-MODEL] ещё не завершена.

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

Вопросы безопасности при получении и распространении сведений BGP-LS рассмотрены в [RFC7752].

TLV, добавленные в этом документе, служат для распространения расширений IGP Flexible Algorithm, заданных в [RFC9350]. Предполагается, что экземпляры IGP, создающие эти TLV, будут обеспечивать безопасность (как указано в [RFC9350]) для внедрения Flexible Algorithm.

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

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

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

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

[RFC7308] Osborne, E., “Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)”, RFC 7308, DOI 10.17487/RFC7308, July 2014, <https://www.rfc-editor.org/info/rfc7308>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP”, RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.

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

[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, “IGP Flexible Algorithm”, RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.

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

[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “BGP YANG Model for Service Provider Networks”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-15, 13 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-15>.

[IDR-BGPLS-SRV6-EXT] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, “BGP Link State Extensions for SRv6”, Work in Progress, Internet-Draft, draft-ietf-idr-bgpls-srv6-ext-13, 14 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-13>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, “IS-IS Application-Specific Link Attributes”, RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.

[RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, “OSPF Application-Specific Link Attributes”, RFC 8920, DOI 10.17487/RFC8920, October 2020, <https://www.rfc-editor.org/info/rfc8920>.

[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, “Border Gateway Protocol – Link State (BGP-LS) Extensions for Segment Routing”, RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/info/rfc9085>.

[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9294] Talaulikar, K., Ed., Psenak, P., and J. Tantsura, “Application-Specific Link Attributes Advertisement ping the Border Gateway Protocol – Link State (BGP-LS)”, RFC 9294, DOI 10.17487/RFC9294, August 2022, <https://www.rfc-editor.org/info/rfc9294>.

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

Авторы благодарны Les Ginsberg, Amalesh Maity, Y. F. Siu, Vijay Gurbani, Donald Eastlake 3rd за их рецензии и вклад в работу. Спасибо Jie Dong за рецензию курастора. Спасибо Alvaro Retana за подробную рецензию AD и предложения по улучшению документа.

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

Ketan Talaulikar (editor)

Cisco Systems

India

Email: ketant.ietf@gmail.com

 

Peter Psenak

Cisco Systems

Slovakia

Email: ppsenak@cisco.com

 

Shawn Zandi

LinkedIn

United States of America

Email: szandi@linkedin.com

 

Gaurav Dawra

LinkedIn

United States of America

Email: gdawra.ietf@gmail.com

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          D. Fedyk
Request for Comments: 9348                                      C. Hopps
Category: Standards Track                        LabN Consulting, L.L.C.
ISSN: 2070-1721                                             January 2023

A YANG Data Model for IP Traffic Flow Security

Модель данных YANG для IP Traffic Flow Security

PDF

Аннотация

Этот документ описывает модуль YANG для управления дополнениями IP Traffic Flow Security (IP-TFS) для протокола обмена ключами версии 2 (Internet Key Exchange Protocol version 2 или IKEv2) и IPsec.

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

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

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

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

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

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

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

1. Введение

Этот документ определяет модуль YANG [RFC7950] для управления расширениями IP Traffic Flow Security (IP-TFS), заданными в [RFC9347]. IP-TFS совершенствует защищённые связи (Security Association или SA) через туннели IPsec для усиления конфиденциальности трафика. Конфиденциальность трафика сокращает возможности его анализа для отождествления и сопоставления наблюдаемых картин трафика. IP-TFS обеспечивает эффективность путём агрегирования трафика в туннельные пакеты IPsec с фиксированным размером.

Модель YANG в этом документе соответствует архитектуре хранилищ данных сетевого управления (Network Management Datastore Architecture или NMDA), заданной в [RFC8342].

Опубликованные модули YANG для IPsec заданы в [RFC9061]. Данный документ использует эти модели в качестве базы для IPsec, которая дополняется для IP-TFS. Модель [RFC9061] поддерживает работу с IKE и без IKE.

2. Обзор

Этот документ определяет конфигурационные и рабочие параметры IP-TFS. Расширение IP-TFS, заданное в [RFC9347], определяет защищённые связи для туннельного режима IPsec с характеристиками, усиливающими конфиденциальность трафика и сокращающими снижение потерь пропускной способности. Документы предполагают знакомство читателя с концепциями IPsec, описанными в [RFC4301].

IP-TFS использует туннельный режим для усиления конфиденциальности за счёт сокрытия идентифицируемой информации, размера и времени пакетов. IP-TFS предоставляет базовую возможность агрегирования нескольких пакетов в туннельные пакеты IPsec одинакового размера. Размер внешних пакетов поддерживается за счёт сочетания агрегирования, заполнения и фрагментации внутренних пакетов с целью заполнения внешнего пакета IPsec. Заполнение применяется при отсутствии данных для передачи.

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

Модуль YANG IP-TFS дополняет модуль YANG IPsec из [RFC9061]. IP-TFS использует туннельный режим IPsec и добавляет несколько элементов настройки туннелей IPsec. Как указано в [RFC9347], любая ассоциация SA, настроенная на использование IP-TFS, поддерживает только пакеты IP-TFS (не работает в смешанных режимах IPsec).

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

Ниже указаны случаи, где статистика IP-TFS активна в одном направлении:

• односторонняя SA при включённом IP-TFS;

• двухсторонняя SA с IP-TFS лишь для одного направления.

Статистика IP-TFS доступна для обоих направлений при двухсторонней SA и IP-TFS для обоих направлений.

Модель IP-TFS поддерживает конфигурационные и операционные данные IP-TFS.

Этот модуль YANG поддерживает конфигурацию с фиксированным размером и скоростью пакетов, а также элементы, которые могут быть добавлены для поддержки будущих конфигураций. Спецификация протокола [RFC9347] выходит за рамки этого простого, фиксированного режима работы, задавая базовый формат для любого типа схемы. В этом документе внешние пакеты IPsec могут передаваться с фиксированным или переменным размером (без заполнения). Конфигурация позволяет определять фиксированный размер пакетов на основании MTU для пути. Фиксированный размер пакетов можно также задать в конфигурации, если нужно значение меньше MTU для пути.

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

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

Настройки контроля перегрузки, позволяющие IP-TFS снижать скорость пакетов при возникновении перегрузки.

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

Скорость туннеля IP-TFS может настраиваться с учётом издержек уровня L2 или L3. Издержками L3 является скорость данных IP, а издержками L2 является битовая скорость в канале. Сочетание размера пакетов и скорости определяет номинальную максимальную пропускную способность и интервал передачи при использовании пакетов фиксированного размера.

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

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

Рабочие данные YANG позволяют считывать параметры конфигурации, а также статистику на уровне SA и счётчики ошибок для IP-TFS. Статистика пакетов IPsec на уровне SA обеспечивается как свойство, а статистика IP-TFS на уровне SA – как другое свойство. Оба набора статистики дополняют модули YANG IPsec счётчиками, которые позволяют наблюдать эффективность пакетов IP-TFS.

Объекты управления YANG IPsec заданы в [RFC9061]. YANG IP-TFS дополняет модели IKE и без IKE. В этих моделях запись базы данных правил безопасности (Security Policy) и запись SA для туннеля IPsec могут дополняться IP-TFS. Кроме того, эта модель YANG использует типы, определённые в [RFC6991].

3. Управление YANG

3.1. Дерево YANG

Ниже представлено дерево YANG [RFC8340] для расширений IP-TFS.

   module: ietf-ipsec-iptfs
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd
               /nsfike:spd-entry/nsfike:ipsec-policy-config
               /nsfike:processing-info/nsfike:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:spd/nsfikels:spd-entry
               /nsfikels:ipsec-policy-config/nsfikels:processing-info
               /nsfikels:ipsec-sa-cfg:
       +--rw traffic-flow-security
          +--rw congestion-control?           boolean
          +--rw packet-size
          |  +--rw use-path-mtu-discovery?   boolean
          |  +--rw outer-packet-size?        uint16
          +--rw (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--rw l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--rw l3-fixed-rate?          yang:gauge64
          +--rw dont-fragment?                boolean
          +--rw max-aggregation-time?         decimal64
          +--rw window-size?                  uint16
          +--rw send-immediately?             boolean
          +--rw lost-packet-timer-interval?   decimal64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro traffic-flow-security
          +--ro congestion-control?           boolean
          +--ro packet-size
          |  +--ro use-path-mtu-discovery?   boolean
          |  +--ro outer-packet-size?        uint16
          +--ro (tunnel-rate)?
          |  +--:(l2-fixed-rate)
          |  |  +--ro l2-fixed-rate?          yang:gauge64
          |  +--:(l3-fixed-rate)
          |     +--ro l3-fixed-rate?          yang:gauge64
          +--ro dont-fragment?                boolean
          +--ro max-aggregation-time?         decimal64
          +--ro window-size?                  uint16
          +--ro send-immediately?             boolean
          +--ro lost-packet-timer-interval?   decimal64
     augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64
     augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry:
       +--ro ipsec-stats {ipsec-stats}?
       |  +--ro tx-pkts?        yang:counter64
       |  +--ro tx-octets?      yang:counter64
       |  +--ro tx-drop-pkts?   yang:counter64
       |  +--ro rx-pkts?        yang:counter64
       |  +--ro rx-octets?      yang:counter64
       |  +--ro rx-drop-pkts?   yang:counter64
       +--ro iptfs-inner-pkt-stats {iptfs-stats}?
       |  +--ro tx-pkts?              yang:counter64
       |  +--ro tx-octets?            yang:counter64
       |  +--ro rx-pkts?              yang:counter64
       |  +--ro rx-octets?            yang:counter64
       |  +--ro rx-incomplete-pkts?   yang:counter64
       +--ro iptfs-outer-pkt-stats {iptfs-stats}?
          +--ro tx-all-pad-pkts?       yang:counter64
          +--ro tx-all-pad-octets?     yang:counter64
          +--ro tx-extra-pad-pkts?     yang:counter64
          +--ro tx-extra-pad-octets?   yang:counter64
          +--ro rx-all-pad-pkts?       yang:counter64
          +--ro rx-all-pad-octets?     yang:counter64
          +--ro rx-extra-pad-pkts?     yang:counter64
          +--ro rx-extra-pad-octets?   yang:counter64
          +--ro rx-errored-pkts?       yang:counter64
          +--ro rx-missed-pkts?        yang:counter64

3.2. Модуль YANG

Ниже представлен модуль YANG для управления расширениями IP-TFS. Эта модель ссылается на [RFC9347] и [RFC5348].

   <CODE BEGINS> file "ietf-ipsec-iptfs@2023-01-31.yang"
   module ietf-ipsec-iptfs {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs";
     prefix iptfs;

     import ietf-i2nsf-ike {
       prefix nsfike;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.2";
     }
     import ietf-i2nsf-ikeless {
       prefix nsfikels;
       reference
         "RFC 9061: A YANG Data Model for IPsec Flow Protection Based on
          Software-Defined Networking (SDN), параграф 5.3";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     organization
       "IETF IPSECME Working Group (IPSECME)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/ipsecme/> 
        WG List: <mailto:ipsecme@ietf.org> 

        Author: Don Fedyk
                <mailto:dfedyk@labn.net> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org>"; 

     description
       "Этот модуль задаёт конфигурацию и рабочее состояние для 
        управления функциональностью IP-TFS (RFC 9348).

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

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9348, где правовые
        аспекты приведены более полно.";

     revision 2023-01-31 {
       description
         "Исходный выпуск";
       reference
         "RFC 9348: A YANG Data Model for IP Traffic Flow Security";
     }

     feature ipsec-stats {
       description
         "Указывает поддержку устройством статистики для IPsec SA.";
     }

     feature iptfs-stats {
       description
         "Указывает поддержку устройством статистики IP TFS для SA.";
     }

     /*--------------------*/
     /*   Группировки      */
     /*--------------------*/

     grouping ipsec-tx-stat-grouping {
       description
         "Выходная статистика IPsec";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик выходных пакетов";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в выходных пакетах";
       }
       leaf tx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных выходных пакетов";
       }
     }

     grouping ipsec-rx-stat-grouping {
       description
         "Входная статистика IPsec";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Счётчик входных пакетов";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Число байтов в входных пакетах";
       }
       leaf rx-drop-pkts {
         type yang:counter64;
         config false;
         description
           "Число отброшенных входных пакетов";
       }
     }

     grouping iptfs-inner-tx-stat-grouping {
       description
         "Статистика вложенных выходных пакетов IP-TFS";
       leaf tx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных пакетов IP-TFS. Учитываются
            только целые пакеты, все фрагменты пакета считаются за 1.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных вложенных октетов IP-TFS. Заполнение
            не учитывается.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-tx-stat-grouping {
       description
         "Статистика выходных вложенных пакетов IP-TFS.";
       leaf tx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных пакетов IP-TFS, содержавших только
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения в пакетах IP-TFS
            без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf tx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число переданных внешних пакетов IP-TFS, содержащих
            заполнение.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf tx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число переданных октетов заполнения, добавленных во
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
     }

     grouping iptfs-inner-rx-stat-grouping {
       description
         "Входная статистика вложенных пакетов IP-TFS";
       leaf rx-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных вложенных пакетов IP-TFS.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-octets {
         type yang:counter64;
         config false;
         description
           "Общее число принятых вложенных октетов IP-TFS без учёта
            заполнения и издержек.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2";
       }
       leaf rx-incomplete-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число неполных вложенных пакетов IP-TFS. Обычно это
            возникает в результате пропуска фрагментов и может быть
            следствием нарушения порядка или ошибок в полученных внешних
            пакетах.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-outer-rx-stat-grouping {
       description
         "Входная статистика внешних пакетов IP-TFS";
       leaf rx-all-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число полученных пакетов IP-TFS, содержащих лишь
            заполнение (без данных).";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-all-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных 
            в пакеты IP-TFS без вложенных данных.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3";
       }
       leaf rx-extra-pad-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число принятых внешних пакетов IP-TFS с заполнением.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-extra-pad-octets {
         type yang:counter64;
         config false;
         description
           "Общее число полученных октетов заполнения, добавленных во 
            внешние пакеты IP-TFS с данными.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS), Section 2.2.3.1";
       }
       leaf rx-errored-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число внешних пакетов IP-TFS, отброшенных из-за 
            ошибок.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
       leaf rx-missed-pkts {
         type yang:counter64;
         config false;
         description
           "Общее число отсутствующих внешних пакетов IP-TFS, указанное
            отсутствующим порядковым номером.";
         reference
           "RFC 9347: Aggregation and Fragmentation Mode for
            Encapsulating Security Payload (ESP) and Its Use for
            IP Traffic Flow Security (IP-TFS)";
       }
     }

     grouping iptfs-config {
       description
         "Группировка для конфигурации IP-TFS.";
       container traffic-flow-security {
         description
           "Настраивает IPsec TFS в базе SAD.";
         leaf congestion-control {
           type boolean;
           default "true";
           description
             "Принятое по умолчанию значение true включает обмен данными
              о перегрузке в линии, которые нужны алгоритмам контроля
              перегрузок, как указано в RFC 5348. При установке false 
              IP-TFS передаёт пакеты фиксированного размера через 
              туннель IP-TFS с постоянной скоростью.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.4.2;
              RFC 5348: TCP Friendly Rate Control (TFRC): Protocol
              Specification";
         }
         container packet-size {
           description
             "Размер пакетов задаётся вручную или определяется
              автоматически.";
           leaf use-path-mtu-discovery {
             type boolean;
             default "true";
             description
               "Применяется определение MTU на пути для задания 
                максимального размера пакетов IP-TFS. Если размер задан
                явно, при установке use-path-mtu-discovery он может лишь
                сокращаться.";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
           leaf outer-packet-size {
             type uint16;
             units "bytes";
             description
               "Размер внешнего инкапсулирующего пакета при передаче
                (т. е. пакета IP с содержимым ESP).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.2";
           }
         }
         choice tunnel-rate {
           description
             "Битовая скорость TFS может быть задана скоростью линии L2
              или скоростью пакетов L3.";
           leaf l2-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
           leaf l3-fixed-rate {
             type yang:gauge64;
             units "bits/second";
             description
               "Целевая пропускная способность/битовая скорость туннеля 
                IP-TFS при передаче в бит/сек. Эта фиксированная скорость
                задаёт номинальное время передачи пакетов фиксированного
                размера. Если включён контроль перегрузок, скорость может
                снижаться (или увеличиваться, если не была задана).";
             reference
               "RFC 9347: Aggregation and Fragmentation Mode for
                Encapsulating Security Payload (ESP) and Its Use for
                IP Traffic Flow Security (IP-TFS), Section 4.1";
           }
         }
         leaf dont-fragment {
           type boolean;
           default "false";
           description
             "При передаче отключает фрагментацию между 
              последовательными пакетами туннеля IP-TFS. Внутренние 
              пакеты, не помещающиеся во внешний пакет, отбрасываются.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.4 and
              6.1.4";
         }
         leaf max-aggregation-time {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При передаче максимальным временем агрегирования является
              максимальное время удержания полученного внутреннего 
              пакета до передачи в туннеле IP-TFS. Внутренние пакеты,
              которые удерживаются дольше этого времени, исходя из
              текущей конфигурации, будут отбрасываться вместо включения
              в очередь передачи. Максимальное время агрегирования 
              задаётся в миллисекундах или долях миллисекунды вплоть
              до 1 наносекунды.";
         }
         leaf window-size {
           type uint16 {
             range "0..65535";
           }
           description
             "Максимальное число полученных с нарушением порядка пакетов,
              для которых получатель IP-TFS будет восстанавливать порядок.
              Значение 0 отключает восстановление порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
         leaf send-immediately {
           type boolean;
           default "false";
           description
             "Задаёт максимально быструю отправку пакетов при получении 
              без ожидания потерянных и разупорядоченных внешних пакетов.
              Выбор этой опции сокращает задержку вложенных 
              (пользовательских) пакетов, но усиливает нарушение порядка
              доставки потока вложенных пакетов при наличии 
              агрегирования или нарушения порядка.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.5";
         }
         leaf lost-packet-timer-interval {
           type decimal64 {
             fraction-digits 6;
           }
           units "milliseconds";
           description
             "При получении задаёт время ожидания получателем IP-TFS
              пропущенного пакета, прежде чем счесть его потерянным.
              Если не задан лист send-immediately, каждый потерянный
              пакет будет задерживать внутренние (пользовательские)
              пакеты, пока не наступит этот тайм-аут. Установка слишком
              малого значения может влиять на восстановление порядка и
              сборку. Значение задаётся в миллисекундах или долях 
              миллисекунды вплоть до 1 наносекунды.";
           reference
             "RFC 9347: Aggregation and Fragmentation Mode for
              Encapsulating Security Payload (ESP) and Its Use for
              IP Traffic Flow Security (IP-TFS), Section 2.2.3";
         }
       }
     }

     /*
      * Крнфигурация IP-TFS IKE
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/"
           + "nsfike:spd-entry/"
           + "nsfike:ipsec-policy-config/"
           + "nsfike:processing-info/"
           + "nsfike:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Конфигурация IP-TFS без IKE
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:spd/"
           + "nsfikels:spd-entry/"
           + "nsfikels:ipsec-policy-config/"
           + "nsfikels:processing-info/"
           + "nsfikels:ipsec-sa-cfg" {
       description
         "Конфигурация IP-TFS для этого правила.";
       uses iptfs-config;
     }

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "IP-TFS настроено для этой SA.";
       uses iptfs-config {
         refine "traffic-flow-security" {
           config false;
         }
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfike:ipsec-ike/nsfike:conn-entry/"
           + "nsfike:child-sa-info" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }

     /*
      * Счётчики пакетов
      */

     augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
           + "nsfikels:sad-entry" {
       description
         "Счётчики на уровне SA";
       container ipsec-stats {
         if-feature "ipsec-stats";
         config false;
         description
           "Счётчики пакетов IPsec на уровне SA.
            tx = выходные, rx = входные";
         uses ipsec-tx-stat-grouping;
         uses ipsec-rx-stat-grouping;
       }
       container iptfs-inner-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внутренних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-inner-tx-stat-grouping;
         uses iptfs-inner-rx-stat-grouping;
       }
       container iptfs-outer-pkt-stats {
         if-feature "iptfs-stats";
         config false;
         description
           "Счётчики внешних пакетов IP-TFS на уровне SA.
            tx = выходные, rx = входные";
         uses iptfs-outer-tx-stat-grouping;
         uses iptfs-outer-rx-stat-grouping;
       }
     }
   }
   <CODE ENDS>

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

4.1. Обновление реестра IETF XML

В соответствии с этим документом агентство IANA зарегистрировало URI в реестре IETF XML Registry [RFC3688]

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

4.2. Обновление реестра YANG Module Names

В соответствии с этим документом агентство IANA зарегистрировало модуль YANG в реестре YANG Module Names [RFC6020]

   Name:  ietf-ipsec-iptfs
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs
   Prefix:  iptfs
   Reference:  RFC 9348

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

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

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

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

../traffic-flow-security

Включение IP-TFS контролируется установкой записей в ветви traffic-flow-security моделей с IKE или без IKE. Параметры в этом дереве устанавливаются для IP-TFS чувствительность к перегрузкам или фиксированную скорость.

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

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

Доступ к статистике IP-TFS даёт сведения о событиях IP-TFS, таких как корректная работа потоков IP-TFS.

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

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

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, “A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)”, RFC 9061, DOI 10.17487/RFC9061, July 2021, <https://www.rfc-editor.org/info/rfc9061>.

[RFC9347] Hopps, C., “Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)”, RFC 9347, DOI 10.17487/RFC9347, January 2023, <https://www.rfc-editor.org/info/rfc9347>.

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

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

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

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

Ниже приведены примеры данных конфигурации и рабочего состояния для вариантов использования с IKE и без IKE в формате XML и JSON. Показана также операционная статистика для варианта без IKE.

A.1. Конфигурация XML

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

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:spd>
       <i:spd-entry>
         <i:name>protect-policy-1</i:name>
         <i:direction>outbound</i:direction>
         <i:ipsec-policy-config>
           <i:traffic-selector>
             <i:local-prefix>192.0.2.0/16</i:local-prefix>
             <i:remote-prefix>198.51.100.0/16</i:remote-prefix>
           </i:traffic-selector>
           <i:processing-info>
             <i:action>protect</i:action>
             <i:ipsec-sa-cfg>
               <tfs:traffic-flow-security>
                <tfs:congestion-control>true</tfs:congestion-control>
                 <tfs:packet-size>
                   <tfs:use-path-mtu-discovery
                      >true</tfs:use-path-mtu-discovery>
                 </tfs:packet-size>
                 <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
                 <tfs:max-aggregation-time
                    >0.1</tfs:max-aggregation-time>
                 <tfs:window-size>5</tfs:window-size>
                 <tfs:send-immediately>false</tfs:send-immediately>
                 <tfs:lost-packet-timer-interval
                    >0.2</tfs:lost-packet-timer-interval>
               </tfs:traffic-flow-security>
             </i:ipsec-sa-cfg>
           </i:processing-info>
         </i:ipsec-policy-config>
       </i:spd-entry>
     </i:spd>
   </i:ipsec-ikeless>

Рисунок 1. Пример конфигурации IP-TFS XML.

A.2. Рабочие данные XML

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

   <i:ipsec-ikeless
     xmlns:i="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
     xmlns:tfs="urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs">
     <i:sad>
       <i:sad-entry>
         <i:name>sad-1</i:name>
         <i:ipsec-sa-config>
           <i:spi>1</i:spi>
           <i:traffic-selector>
             <i:local-prefix>2001:db8:1::/48</i:local-prefix>
             <i:remote-prefix>2001:db8:2::/48</i:remote-prefix>
           </i:traffic-selector>
         </i:ipsec-sa-config>
         <tfs:traffic-flow-security>
           <tfs:congestion-control>true</tfs:congestion-control>
           <tfs:packet-size>
             <tfs:use-path-mtu-discovery
               >true</tfs:use-path-mtu-discovery>
           </tfs:packet-size>
           <tfs:l2-fixed-rate>1000000000</tfs:l2-fixed-rate>
           <tfs:max-aggregation-time>0.100</tfs:max-aggregation-time>
           <tfs:window-size>0</tfs:window-size>
           <tfs:send-immediately>true</tfs:send-immediately>
           <tfs:lost-packet-timer-interval
             >0.200</tfs:lost-packet-timer-interval>
         </tfs:traffic-flow-security>
       </i:sad-entry>
     </i:sad>
   </i:ipsec-ikeless>

Рисунок 2. Пример рабочих данных IP-TFS XML.

A.3. Конфигурация JSON

Этот пример показывает данные конфигурации для IP-TFS с IKE. Отметим, что это дополняет схему IPsec IKE, , поэтому задана лишь минимальная конфигурация для схемы с IKE.

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
             {
               "id": 1,
               "algorithm-type": 12,
               "key-length": 128
             }
             ],
             "local": {
               "local-pad-entry-name": "local-1"
             },
             "remote": {
               "remote-pad-entry-name": "remote-1"
             },
             "ietf-i2nsf-ike:spd": {
             "spd-entry": [
               {
                 "name": "protect-policy-1",
                 "ipsec-policy-config": {
                   "traffic-selector": {
                     "local-prefix": "192.0.2.0/16",
                     "remote-prefix": "198.51.100.0/16"
                   },
                   "processing-info": {
                     "action": "protect",
                     "ipsec-sa-cfg": {
                       "ietf-ipsec-iptfs:traffic-flow-security": {
                         "congestion-control": true,
                         "l2-fixed-rate": "1000000000",
                         "packet-size": {
                           "use-path-mtu-discovery": true
                         },
                         "max-aggregation-time": "0.1",
                         "window-size": 1,
                         "send-immediately": false,
                         "lost-packet-timer-interval": "0.2"
                       }
                     }
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 3. Пример конфигурации IP-TFS JSON.

A.4. Рабочие данные JSON

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

   {
     "ietf-i2nsf-ike:ipsec-ike": {
       "ietf-i2nsf-ike:conn-entry": [
         {
           "name": "my-peer-connection",
           "ike-sa-encr-alg": [
           {
             "id": 1,
             "algorithm-type": 12,
             "key-length": 128
           }
           ],
           "local": {
             "local-pad-entry-name": "local-1"
           },
           "remote": {
             "remote-pad-entry-name": "remote-1"
           },
           "ietf-i2nsf-ike:child-sa-info": {
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "congestion-control": true,
               "l2-fixed-rate": "1000000000",
               "packet-size": {
                 "use-path-mtu-discovery": true
               },
               "max-aggregation-time": "0.1",
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             }
           }
         }
       ]
     }
   }

Рисунок 4. Пример операционных данных IP-TFS JSON.

A.5. Операционная статистика JSON

Этот пример показывает статистику IP-TFS в формате JSON. Отметим, что показана передающая сторона двухстороннего IP-TFS в произвольными номерами при передаче.

   {
     "ietf-i2nsf-ikeless:ipsec-ikeless": {
       "sad": {
         "sad-entry": [
           {
             "name": "sad-1",
             "ipsec-sa-config": {
               "spi": 1,
               "traffic-selector": {
                 "local-prefix": "192.0.2.1/16",
                 "remote-prefix": "198.51.100.0/16"
               }
             },
             "ietf-ipsec-iptfs:traffic-flow-security": {
               "window-size": 5,
               "send-immediately": false,
               "lost-packet-timer-interval": "0.2"
             },
             "ietf-ipsec-iptfs:ipsec-stats": {
               "tx-pkts": "300",
               "tx-octets": "80000",
               "tx-drop-pkts": "2",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-drop-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-inner-pkt-stats": {
               "tx-pkts": "250",
               "tx-octets": "75000",
               "rx-pkts": "0",
               "rx-octets": "0",
               "rx-incomplete-pkts": "0"
             },
             "ietf-ipsec-iptfs:iptfs-outer-pkt-stats": {
               "tx-all-pad-pkts": "40",
               "tx-all-pad-octets": "40000",
               "tx-extra-pad-pkts": "200",
               "tx-extra-pad-octets": "30000",
               "rx-all-pad-pkts": "0",
               "rx-all-pad-octets": "0",
               "rx-extra-pad-pkts": "0",
               "rx-extra-pad-octets": "0",
               "rx-errored-pkts": "0",
               "rx-missed-pkts": "0"
             },
             "ipsec-sa-state": {
               "sa-lifetime-current": {
                 "time": 80000,
                 "bytes": "400606",
                 "packets": 1000,
                 "idle": 5
               }
             }
           }
         ]
       }
     }
   }

Рисунок 5. Пример статистики IP-TFS JSON.

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

Авторы благодарны Eric Kinzie, Jürgen Schönwälder, Lou Berger, Tero Kivinen за отклики и рецензии на модуль YANG.

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

Don Fedyk

LabN Consulting, L.L.C.

Email: dfedyk@labn.net

 

Christian Hopps

LabN Consulting, L.L.C.

Email: chopps@chopps.org

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

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

nmalykh@protokols.ru

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

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сеть

DualQ Coupled AQM (задан в этом документе) или модификация AQM с очередями для потоков (п. b в параграфе 4.2 описания архитектуры L4S [RFC9330]).

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

Расширяемый контроль перегрузки (раздел 4 спецификации протокола L4S ECN [RFC9331]).

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

Компоненты L4S в сети и на конечных системах можно внедрять постепенно, поскольку пакеты L4S указываются в них выделенными для экспериментов кодами ECN в заголовке IP – ECT(1) и CE [RFC8311] [RFC9331].

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

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

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

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

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

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

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

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

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

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

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

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

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

Классический сервис предназначен для всех вариантов поведения контроля перегрузок, сосуществующих с Reno [RFC5681] (например, сам Reno, CUBIC [RFC8312], Compound [CTCP], TFRC [RFC5348]). «Классической очередью» называется очередь, обеспечивающая классический сервис.

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

Сервис L4S предназначен для трафика с расширяемыми алгоритмами контроля перегрузок, такими как Prague [PRAGUE-CC], который был выведен из DCTCP [RFC8257]. Сервис L4S предназначен для более широкого класса трафика, нежели просто Prague, и позволяет развивать набор средств контроля перегрузок, аналогичных Prague, таких как отмечены выше (Relentless, SCReAM и т. п.). Очередью L4S называется очередь, обеспечивающая услуги L4S.

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

Поведение контроля перегрузок, способное сосуществовать со стандартным Reno [RFC5681] без существенного негативного влияния на скорость потока [RFC5033]. Поскольку скорости потоков выросли с момента разработки контроля перегрузок TCP в 1988 г., в классических алгоритмах, таких как Reno и CUBIC, для достаточно продолжительных потоков на восстановление (в результате маркировки ECN или потери пакетов) затрачиваются сотни круговых обходов (round trip), как показано в примерах параграфа 5.1 и в [RFC3649], и их число продолжает расти. Поэтому контроль за постановкой в очередь и её использованием ослабляется и малейшие нарушения (например, появление новых потоков) препятствуют достижению высокой скорости.

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

Контроль перегрузок, где среднее время от одного сигнала насыщения до следующего (время восстановления) не зависит от скорости потока при прочих равных условиях. Это обеспечивает одинаковую степень контроля над очередями и загрузкой канала независимо от скорости потока, а также гарантирует устойчивость высокой пропускной способности к нарушениям. Например, DCTCP усредняет 2 сигнала пересылки за интервал кругового обхода, независимо от скорости потока, как и другие недавно разработанные расширяемые механизмы контроля перегрузок, такие как Relentless TCP [RELENTLESS], Prague для TCP и QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], L4S-вариант SCReAM для потоков в реальном масштабе времени [SCReAM-L4S] [RFC8298]. Для общедоступной сети Internet расширяемый (Scalable) транспорт должен соответствовать требованиям раздела 4 в [RFC9331] (Требования Prague L4S).

C

Сокращение для Classic, например, при использовании в качестве подстрочного индекса.

L

Сокращение для L4S, например, при использовании в качестве подстрочного индекса.

Атрибуты Classic и L4S могут применяться к очередям (queue), кодам (codepoint), идентификаторам (identifier), классификации (classification), пакетам (packet), потокам (flow). Например термин «пакет L4S» относится к пакету с идентификатором L4S, переданному из системы контроля перегрузок L4S.

Оба типа сервиса (Classic и L4S) могут справляться с некоторой долей неотзывчивого и слабо отзывающегося трафика, но в случае L4S скорость должна быть достаточно плавной или низкой, чтобы не возникала очередь (например, DNS, VoIP, синхронизация игр и т. п.). Поведение DualQ Coupled AQM задано похожим на очередь FIFO⁷ в части не отвечающего и перегруженного трафика.

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

Часть классического трафика, совместимая со стандартным контролем перегрузок Reno, заданным для TCP в [RFC5681]. Спецификация TFRC [RFC5348] косвенно подразумевает, что дружественностью (совместимостью) считается «нахождение обычно в пределах двухкратного отличия скорости передачи потока TCP при одинаковых условиях». Термин Reno-friendly используется здесь вместо TCP-friendly, поскольку последнее выражение стало неточным, так как протокол TCP сейчас использует много разных вариантов контроля перегрузок, а Reno применяется не только в TCP, но и в других транспортных протоколах (например, QUIC [RFC9000]).

DualQ или DualQ AQM

Применяется свободно в качестве сокращения Dual-Queue Coupled AQM, где из контекста очевидно Coupled AQM.

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

Исходный протокол явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) [RFC3168], требующий считать сигналы ECN эквивалентом отбрасывания (при генерации в сети или на отвечающем хосте).

В L4S имена, используемые для четырёх кодов в 2-битовом поле IP-ECN, сохраняются такими же, как было задано в спецификации ECN [RFC3168], т. е. Not-ECT, ECT(0), ECT(1) и CE, где ECT означает транспорт с поддержкой ECN (ECN-Capable Transport), а CE (Congestion Experienced) – возникновение перегрузки. Пакеты, помеченные кодом CE, называются ECN-marked или просто помеченными, если контекст указывает ECN.

1.4. Свойства

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

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

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

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

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

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

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

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

2. DualQ Coupled AQM

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

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

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

2.1. Coupled AQM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       p' = p_CL / k

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

       p_CL = k*p'                          (3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя предполагается, что планирование WRR будет решать проблему лишь при краткосрочной перегрузке, имеются (достаточно редкие) случаи, когда WRR влияет на распределение пропускной способности в более продолжительном интервале. Однако это влияние невелико и не наносит вреда. В частности, когда отношение потоков L4S и Classic (например, 19:1) больше отношения отношения их весов в планировщике (например, 15:1), потоки L4S получат немного меньше равной доли пропускной способности. Например, при указанных соотношениях каждый поток L4S получит долю (15/16)/19 = 4.9%, тогда как в идеальном случае он получил бы 1/20 = 5%. В довольно специфическом случае неотзывчивого трафика, занимающего пропускную способность чуть меньше отведённой для L4S (например, 14/16 для описанного выше случая), применение WRR может существенно сокращать пропускную способность, оставляемую для любых отзывчивых потоков L4S.

Вес при планировании для классической очереди не следует делать слишком малым, иначе пакет C в начале очереди может быть чрезмерно задержан постоянно занятой очередью L. Например, если вес классической очереди составляет 1/16, максимальная задержка классического пакета в начале очереди из-за трафика L будет равна задержке сериализации пакетов размером 15 MTU.

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

Оператор может выбрать контроль перегрузки в классической очереди, позволив некоторой задержке «перетечь» в очередь L4S. Планировщик может вести себя как одна очередь FIFO с разным временем обслуживания, реализуя очень простой планировщик с приоритетом по условию, называемый FIFO со сдвигом по времени (time-shifted FIFO или TS-FIFO, см. планировщик MEDF¹⁰ [MEDF]). Этот планировщик добавляет tshift к задержке в очереди для следующего пакета L4S до её сравнения с задержкой в очереди для следующего классического пакета, а затем выбирает пакет с большим значением (скорректированной) задержки. При обычных условиях планировщик TS-FIFO ведёт себя как строгий планировщик по приоритету, но при умеренной или сильной перегрузке он предотвращает истощение для классической очереди, поскольку сдвиг времени (tshift) определяет максимальную дополнительную задержку классических пакетов относительно L4S. Это позволяет контролировать умеренную перегрузку отзывчивого трафика путём внесения задержки для отсрочки вызова механизмов, описанных в параграфе 4.2.3, особенно при приближении к максимальному сигналу перегрузки.

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

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

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

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

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

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

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

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

Когда маркировка L4S достигает насыщения, вместо отбрасывания L4S можно ограничить вероятность отбрасывания и маркировки в обеих очередях. После этого задержка будет расти в очереди с неотзывчивым трафиком (если применяется WRR) или в обеих очередях (если применяется TS-FIFO). В любом случае более высокая задержка должна контролировать временную высокую перегрузку. При более длительной перегрузке в конечном итоге произойдёт переполнение комбинированных DualQ и перегрузку будет контролировать отбрасывание в конце очереди (tail drop).

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

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

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

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

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

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

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

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L4S

Если проверка в строке 3 указывает извлечение из очереди L4S, проверка в строках 5b и 5c решает вопрос о маркировке. Строка 5b сравнивает задержку в очереди L4S (lq.time()) с порогом ступени T¹³, а строка 5c похожа на случайную маркировку ECN в RED, но i) решение зависит от времени в очереди, а не от байтов для возможности изменения скорости канала без перенастройки, ii) маркировка в очереди L4S зависит от логического ИЛИ двух проверок – по времени в этой и другой (Classic) очереди, iii) проверки выполняются для мгновенного значения времени в очереди L4S и сглаженного среднего в очереди Classic, iv) очередь сравнивается с максимальным из U случайных значений (при U = 1 это совпадает с использованием одного случайного значения в RED).

В строке 5a для связанной вероятности маркировки p_CL устанавливается значение, определяемое разностью усреднённой задержки в очереди Classic (Q_C) и нижнего порога задержки в очереди (minTh), разделённой на параметр масштабирования L4S (range_L). Значение range_L представляет добавленную к minTh задержку в очереди (в секундах), при которой вероятность маркировки составит 100%. В строке 5c (если U = 1) результат сравнивается с однородно распределенной случайной величиной из диапазона от 0 до 1, что гарантирует для range_L линейный рост вероятности маркировки при увеличении времени в очереди.

Classic

Если планировщик в строке 3 выбирает классический пакет и переходит в строку 7, проверка в строке 10b решает вопрос о маркировке или отбрасывания пакета. Но пред этим строка 9a обновляет значение Q_C, которое является экспоненциально взвешенным скользящим средним значением ¹⁴ времени пребывания в классической очереди, где cq.time() – текущее мгновенное время пребывания пакета в голове классической очереди (0, если очередь пуста), а gamma – константа экспоненциально взвешенного скользящего среднего значения (exponentially weighted moving average или EWMA), по умолчанию равная 1/32 (строка 12 функции инициализации ).

Строки 10a и 10b реализуют Classic AQM. В строке 10a средневзвешенное время Q_C делится на параметр классического масштабирования range_C, как для при масштабировании времени в очереди для маркировки L4S. Это масштабированное время в очереди будет возводиться в квадрат для определения вероятности классического отбрасывания. До возведения в квадрат оно фактически является квадратным корнем из вероятности отбрасывания, поэтому переменная названа sqrt_p_C. Возведение в квадрат выполняется путём сравнения значения с большим из 2 случайных чисел (при U = 1), эквивалентного логической операции И для двух проверок, что обеспечивает квадратичный рост вероятности отбрасывания в зависимости от времени пребывания в очереди.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Koen De Schepper

Nokia Bell Labs

Antwerp

Belgium

Email: koen.de_schepper@nokia.com

URI: https://www.bell-labs.com/about/researcher-profiles/koende_schepper/

 

Bob Briscoe (editor)

Independent

United Kingdom

Email: ietf@bobbriscoe.net

URI: https://bobbriscoe.net/

 

Greg White

CableLabs

Louisville, CO

United States of America

Email: G.White@CableLabs.com

---

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

nmalykh@protokols.ru

---

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

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поведение контроля перегрузок, способное сосуществовать со стандартным Reno [RFC5681] без существенного негативного влияния на скорость потока [RFC5033]. Поскольку с 1988 г., когда был разработан механизм контроля перегрузок в TCP, скорости потоков возросли, при классическим контроле перегрузок, таком как Reno или CUBIC, восстановление после сигнала перегрузки (потеря или маркер ECN) может занимать сотни интервалов кругового обхода (и растёт), как показано в параграфе |5.1 описания архитектуры L4S [RFC9330] и в [RFC3649]. Поэтому контроль очередей и загрузки каналов становится очень слабым и малейшие помехи (например, появление нового потока) препятствуют достижению высокой скорости.

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

Контроль перегрузок, где среднее время от одного сигнала насыщения до следующего (время восстановления) независимо от скорости потока при прочих равных условиях. Это обеспечивает некоторый контроль над очередями и загрузкой канала, а также гарантирует высокую пропускную способность, устойчивую к нарушениям. Например, DCTCP усредняет 2 сигнала пересылки за интервал кругового обхода, независимо от скорости потока, как и другие недавно разработанные расширяемые механизмы контроля перегрузок, такие как Relentless TCP [RELENTLESS], Prague для TCP и QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], L4S-вариант SCReAM для потоков в реальном масштабе времени [SCReAM-L4S] [RFC8298]. Дополнительные сведения можно найти в параграфе 4.3 [RFC9331].

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

Классический сервис предназначен для всех вариантов поведения контроля перегрузок, сосуществующих с Reno [RFC5681] (например, сам Reno, CUBIC [RFC8312], Compound [CTCP], TFRC [RFC5348]). «Классической очередью» называется очередь, обеспечивающая классический сервис.

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

Сервис L4S предназначен для трафика с расширяемыми алгоритмами контроля перегрузок, такими как Prague [PRAGUE-CC], который был выведен из DCTCP [RFC8257]. Сервис L4S предназначен для более широкого класса трафика, нежели просто Prague, и позволяет развивать набор средств контроля перегрузок, аналогичных Prague, такик как отмечены выше (Relentless, SCReAM и т. п.). Очередью L4S называется очередь, предоставляющая услуги L4S.

Атрибуты Classic и L4S могут применяться к очередям (queue), кодам (codepoint), идентификаторам (identifier), классификации (classification), пакетам (packet), потокам (flow). Например термин «пакет L4S» относится к пакету с идентификатором L4S, переданному из системы контроля перегрузок L4S.

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

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

Часть классического трафика, совместимая со стандартным контролем перегрузок Reno, заданным для TCP в [RFC5681]. Спецификация TFRC [RFC5348] косвенно подразумевает, что дружественностью (совместимостью) считается «нахождение обычно в пределах двухкратного отличия скорости передачи потока TCP при одинаковых условиях». Термин Reno-friendly используется здесь вместо TCP-friendly, поскольку последнее выражение стало неточным, так как протокол TCP сейчас использует много разных вариантов контроля перегрузок, а Reno применяется не только в TCP, но и в других транспортных протоколах (например, QUIC [RFC9000]).

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

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

Для L4S имена кодов 2-битового поля IP-ECN не отличаются от заданных в спецификации ECN [RFC3168] – Not-ECT, ECT(0), ECT(1), CE, где ECT указывает поддержку ECN в транспорте (ECN-Capable Transport), а CE – возникновение перегрузки (Congestion Experienced). Пакеты с кодом CE называют промаркированными ECN (ECN-marked), а иногда – просто маркированными, если наличие ECN ясно из контекста.

Site – сайт

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

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

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

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

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

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

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

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

  • ECN для RTP [RFC6679];

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TCP

Поддержка требования точных откликов ECN [RFC7560] (например, как в AccECN [ACCECN]) на обеих сторонах является обязательным условием для расширяемого контроля перегрузки в TCP. Поэтому наличие ECT(1) в заголовках IP даже для одного направления в соединении TCP означает, что обе стороны поддерживают точные отклики ECN. Однако обратное неверно, т. е. даже если обе стороны поддерживают AccECN, любая из них может отказаться от использования расширяемого контроля перегрузок независимо от другой стороны.

SCTP

Подходящий механизм откликов ECN для SCTP мог бы добавить блок (chunk) с информацией о числе полученных маркеров CE (как описано в давно устаревшем документе [SCTP-ECN] и очерчено в Приложении A к уже отменённой спецификации стандарта SCTP [RFC4960]).

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

Для расширяемого контроля перегрузок обе (все) стороны одного интервала пересылки (hop) на уровне среды (media-level) должны сообщить о поддержке ECN [RFC6679] и применять новый базовый формат откликов RTCP [RFC8888]. Наличие ECT(1) означает, что обе (все) стороны этого media-level hop поддерживают ECN. Однако обратное неверно,т. е. каждая из сторон media-level hop может отказаться от использования расширяемого контроля перегрузок, даже если обе поддерживают ECN.

QUIC

Поддержка достаточно подробных откликов ECN обеспечивается транспортом IETF QUIC v1 [RFC9000].

DCCP

Вектора подтверждения (Acknowledgement или ACK) в DCCP [RFC4340] уже достаточно для информирования о маркировке CE, требуемого для расширяемого контроля перегрузок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сосуществование классических потоков с L4S не вызывает сомнений, если в узком месте не поддерживается ECN, что остаётся наиболее распространенным случаем с момента публикации спецификации ECN [RFC3168] в 2001 г.

L4S

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

Classic ECN

Компромиссы связаны со случаями поддержки в узком месте Classic ECN [RFC3168] без поддержки L4S.

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

На момент написания документа членам рабочей группы Transport не было известно внедрений Classic ECN с общей очередью в узком месте Internet. Тем не менее, в масштабе Internet редкий не означает малочисленный, а в будущем может стать и не столь редким.

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

В большинстве AQM (в частности, FQ-CoDel [RFC8290] и COBALT [COBALT]) с очередями по потокам, развёрнутых с 2012 г. по умолчанию включён механизм Classic ECN. Но компромиссы применяются лишь ко второму из указанных ниже случаев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      p_C ~= (p_L / k)^2

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

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

Отметим, что вопреки [RFC3168], механизм AQM, реализующий обработку L4S и Classic, не устанавливает для пакета маркер ECT(1) при таких же условиях, когда он отбросил бы пакет Not-ECT, как разрешает [RFC8311], обновляющий [RFC3168]. Однако такой механизм применяет маркировку ECT(0) при тех же условиях, при которых он отбросил бы пакет Not-ECT в соответствии с [RFC3168].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Значение	Обозначение	Документ
01	ECT(1) (ECN-Capable Transport(1))14	[RFC8311] [RFC Errata 5399] RFC 9331

 

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

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

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

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

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

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

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

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

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

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

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

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

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

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

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

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

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

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

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

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

[Bufferbloat] The Bufferbloat community, “Bufferbloat”, <https://bufferbloat.net/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

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

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

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

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

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

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

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

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

[RFC4342] Floyd, S., Kohler, E., and J. Padhye, “Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)”, RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.

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

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

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

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RFC9001] Thomson, M., Ed. and S. Turner, Ed., “Using TLS to Secure QUIC”, RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

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

[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, “Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)”, RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.

[Savage-TCP] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, “TCP Congestion Control with a Misbehaving Receiver”, ACM SIGCOMM Computer Communication Review, Volume 29, Issue 5, pp. 71–78, DOI 10.1145/505696.505704, October 1999, <https://dl.acm.org/doi/abs/10.1145/505696.505704>.

[SCReAM-L4S] “SCReAM”, commit 140e292, November 2022, <https://github.com/EricssonResearch/scream>.

[SCTP-ECN] Stewart, R., Tüxen, M., and X. Dong, “ECN for Stream Control Transmission Protocol (SCTP)”, Work in Progress, Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January 2014, <https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctpecn-05>.

[sub-mss-prob] Briscoe, B. and K. De Schepper, “Scaling TCP’s Congestion Window for Small Round Trip Times”, BT Technical Report: TR-TUB8-2015-002, DOI 10.48550/arXiv.1904.07598, May 2015, <https://arxiv.org/abs/1904.07598>.

[TCP-CA] Jacobson, V. and M. J. Karels, “Congestion Avoidance and Control”, Laurence Berkeley Labs Technical Report, November 1988, <https://ee.lbl.gov/papers/congavoid.pdf>.

[TCPPrague] Briscoe, B., “Notes: DCTCP evolution ‘bar BoF’: Tue 21 Jul 2015, 17:40, Prague”, message to the tcpPrague mailing list, July 2015, <https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html>.

[TRILL-ECN-SUPPORT] Eastlake 3rd, D. and B. Briscoe, “TRILL (Transparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support”, Work in Progress, Internet-Draft, draft-ietf-trill-ecn-support-07, 25 February 2018, <https://datatracker.ietf.org/doc/html/draft-ietf-trill-ecn-support-07>.

[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, “One more bit is enough”, SIGCOMM ’05: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 37-48, DOI 10.1145/1080091.1080098, August 2005, <https://doi.acm.org/10.1145/1080091.1080098>.

Приложение A. Обоснование требований Prague L4S

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

Требования и рекомендации раздела 4 называют «требованиями Prague L4S», поскольку они исходно заданы на специальной встрече в рамках конференции IETF 94 в Праге [TCPPrague]. Поначалу их называли требованиями TCP Prague, но они применимы не только к TCP, поэтому название было обобщено для других транспортных протоколов, а TCP Prague применяется для конкретной реализации требований.

На момент создания протокол DCTCP [RFC8257] был наиболее распространенным решением с масштабированием. В своей текущей форме DCTCP предназначен для внедрения лишь в контролируемых средах. Развёртывание в Internet приведёт к многочисленным проблемам в части безопасности и производительности. Указанные в этом приложении изменения и дополнительные механизмы потребуются для внедрения в общедоступной сети Internet. Там, где нужны примеры, DCTCP служит базой, но требования раздела 4 в той же мере применимы к другим элементам расширяемого контроля перегрузок, включая адаптивную передачу в реальном масштабе времени и т. п., а не только приложения, которым нужна пропускная способность.

A.1. Обоснование требований к масштабированию транспорта

A.1.1. Использование идентификатора пакета L4S

Описание

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

Мотивация

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

A.1.2. Точные отклики ECN

Описание

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

Мотивация

Для классического контроля перегрузки требуется лишь отклик о возникновении перегрузки в интервале кругового обхода без точного указания отброшенных или помеченных кодом ECN пакетов. Поэтому при добавлении откликов ECN для TCP в 2001 г. [RFC3168] можно было не информировать отправителя о нескольких маркерах ECN в течение RTT. С тех пол были заданы более точные требования к маркировке ECN для TCP в [RFC7560], а в [ACCECN] задано обновление протокола TCP с учётом этих требований. В большинстве других транспортных протоколов эти требования уже выполняются (параграф ).

A.1.3. Возможность замены классическим контролем перегрузки

Описание

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

Мотивация

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

A.1.4. Возврат к классическому контролю при потере пакетов

Описание

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

Мотивация

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

Расширяемых контроль перегрузки может применяться для разных видов транспорт, например при передаче в реальном масштабе времени или для гарантированного транспорта, такого как TCP. Поэтому конкретное классическое поведение контроля перегрузки, к которому следует возвращаться, зависит от используемой реализации контроля. В случае DCTCP спецификация протокола [RFC8257] говорит: «Отправитель DCTCP должен реагировать на случаи потерь так же, как традиционный TCP.» Для обеспечения безопасного внедрения расширяемого контроля перегрузок в общедоступной сети Internet п. 2 из параграфа 4.3 в этом документе не требует отклика, в точности совпадающего с Reno TCP, но требует отклика, обеспечивающего безопасное сосуществование с классическим контролем перегрузки, подобным Reno.

Даже при поддержке L4S в узком месте может возникать перегрузка с потерей пакетов. В таких случаях отправитель может получить большое число пакетов с кодом CE, а также столкнуться с потерями. Текущие реализации DCTCP реагируют на такие ситуации по-разному. Одним из подходов является реагирование лишь на сигнал отбрасывания (например, сокращением cwnd вдвое), в другом применяется реакция на оба сигнала с большим сокращением cwnd. Предложен компромисс между этими подходами, где реакция на потерю настраивается так, чтобы привести к сокращению окна вдвое при наличии предшествующего отклика ECN в том же интервале кругового обхода. Представляет разумным проведение дополнительных экспериментов для поиска поведения, наиболее подходящего для общедоступной сети Internet.

A.1.5. Сосуществование с классическим контролем в узких местах с Classic ECN

Описание

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

Мотивация

Подобно обсуждению в Приложении A.1.4, требование из параграфа 4.3 является условием безопасного сосуществования контроля перегрузок L4S с классическими потоками при создании очереди в общем узком месте сети, не обновлённом для поддержки L4S. Тем не менее, считается разумным при необходимости решать такие задачи в установленные сроки (возможно, с участием человека), поскольку:

• классический поток продолжает работать без истощения, хотя его пропускная способность может существенно снизиться из-за конкурирующего расширяемого потока;
• реализации Classic ECN AQM в очереди для совместного использования считаются редкими;
• обнаружение таких AQM не всегда однозначно, поэтому для уверенности нужно целенаправленное тестирование по отдельному каналу (out-of-band) или даже обращение в соответствующему оператору.

Поэтому соответствующие нормативные требования (параграф 4.3) разделены на 3 части (этапа).

Мониторинг

Мониторинг включает сбор измерительных данных для анализа. Мониторинг указан как обязательный (должен) для неконтролируемых сред, хотя место размещения функции мониторинга не указано. Для мониторинга в реальном масштабе времени указано требование «следует», что допускает возможность предпочтения оператором отправителя L4S (например, CDN¹⁵) проверки по отдельному каналу наличия признаков Classic ECN AQM, возможно, для предотвращения расхода ресурсов на мониторинг «живого» трафика.

Обнаружение

Обнаружение включает анализ данных мониторинга для определения вероятности наличия Classic ECN AQM. Обнаружение может непосредственно выявлять проблемы сосуществования потоков или нацеливаться на идентификацию технологий AQM, которые могут вызывать проблемы сосуществования, на основе сведений о развёрнутых AQM. Рекомендуется выполнять обнаружение в реальном масштабе времени, однако оно может быть и отложенным (например, может включать дополнительное тестирование, нацеленное не конкретные AQM).

Действия

Действия включают переход отправителя к классическому контролю перегрузки, который может выполняться в реальном масштабе времени в рамках контроля перегрузки или с участием администратора, переключающего контроль перегрузки на классический для конкретного интерфейса или набора адресатов.

Оператор отправителя(например, CDN) может вместо самого отправителя попросить оператора сети изменить обработку Classic AQM для пакетов L4S, обеспечивая им обход AQM, или обновить AQM для поддержки L4S (см. эксплуатационные рекомендации для L4S [L4SOPS]). Если потоки L4S больше не проходят через Classic ECN AQM, они уже не будут видеть эти механизмы и требование к действиям теряет актуальность.

Весь набор нормативных требования, относящихся к Classic ECN AQM, в параграфе 4.3 сформулирован так, что они не применяются в контролируемых средах, таких как частные сети и ЦОД. Серверы CDN, размещённые в сети доступа ISP, можно рассматривать как контролируемую среду, но все сети, обслуживаемые этой сетью доступа, включая сети клиентов, вряд ли будут входить в сферу того же координированного контроля. Для мониторинга таких неконтролируемых сегментов пути (например, в домашней сети за сетью доступа ISP) указан уровень «должен», поскольку для них имеется вероятность наличия общей очереди с Classic ECN AQM. Тем не менее, цель формулировки заключается в требовании лишь эпизодического мониторинга этих неконтролируемых участков сети без обременения операторов CDN, если мониторинг не выявляет каких-либо возможных проблем.

Более подробное рассмотрение всех вариантов можно найти в руководстве по эксплуатации L4S [L4SOPS].

С учётом отмеченного выше, подход, рекомендованный в параграфе 4.3, заключается в мониторинге, обнаружении и действиях по отношению к трафику в реальном масштабе времени. Алгоритм пассивного мониторинга для обнаружения ECN AQM в узких местах и возврата к классическому контролю перегрузок, описан в обширном техническом отчёте [ecn-fallback], где приведены также ссылки на исходный код Linux и сетевую визуализацию результатов оценок. Вкратце, алгоритм в основном отслеживает вариации RTT с использованием того же метода, который поддерживает среднее отклонение сглаженного RTT в TCP, но выполняет сглаживание в интервале того же порядка, что и при классической пиле. Результат зависит и от других показателей, таких как наличие маркировки CE и стабилизации фазы предотвращения перегрузки. В отчёте также указаны направления дальнейшей работы по улучшению подхода, например, для каналов с малой пропускной способностью или для сочетания измерений с кэшированием того, что было известно о пути из прежних соединений. В отчёте предложены и другие подходы.

Хотя использование пассивных инструментов для «живого» трафика (как указано выше) позволяет обнаружить Classic ECN AQM, гораздо сложнее (или невозможно) определить наличие AQM в общей очереди. Это гораздо проще сделать при активном тестировании вне основного канала, поскольку можно применить 2 потока. В разделе 4 отчёта [ecn-fallback] описан простой метод обнаружения Classic ECN AQM и проверки его размещения в общей очереди, который кратко рассмотрен ниже.

Тестовый сервер с поддержкой L4S можно настроить так, что при обращении к нему тестового клиента будет выполняться сценарий, позволяющий клиенту создать 2 параллельных долгосрочных потока. Один поток может работать с классическим контролем перегрузки (C, с установкой ECT(0)), другой – с расширяемым (L, с установкой ECT(1)). Если ни один из потоков не вызывает маркировки ECN, можно предположить, что на пути нет Classic ECN AQM. Если в каком-либо из потоков возникает маркировка ECN, сервер может измерить относительные скорости потоков и время кругового обхода для них. В таблице показаны механизмы AQM, которые можно предположить в разных случаях (в предположении отсутствия других вариантов поведения AQM, кроме известных при написании).

Таблица . Тестирование по отдельному каналу с 2 параллельными потоками.

 

Скорость	RTT	Предполагаемый AQM
L > C	L = C	Classic ECN AQM (FIFO)
L = C	L = C	Classic ECN AQM (FQ)
L = C	L < C	FQ-L4S AQM
L ~= C	L < C	DualQ Coupled AQM
L = L4S, C = Classic

 

Ещё одним мотивом рекомендаций из параграфа 4.3 является то, что в расширяемом контроле перегрузки не предполагается смена на установку ECT(0) при изменении поведения для сосуществования с классическими потоками. Это обусловлено тем, что отправитель должен продолжать проверку правильности решения о переходе и обратного переключения в случае ошибки или переносе узкого места на другой канал.

• Если отправитель в соответствии с рекомендациями меняет лишь своё поведение на классическое, но не меняет код, его код остаётся совместимым с L4S или Classic AQM. Если в узком месте фактически поддерживаются оба режима, код ECT(1) будет по-прежнему классифицироваться в ту же очередь L4S и отправитель может понять, что переход к классическому поведению был ошибкой и вернуться назад.

• Если же отправитель меняет поведение и код даже при поддержке в узком месте обоих режимов, он будет классифицировать ECT(0) в классическую очередь, форсируя некорректное решения без возможности возврата.

• Кроме того, отказ от смены кода позволяет исключить риск перехода на другой путь через балансировщик нагрузки или маршрутизацию по нескольким путям, в которой хэшируется весь байт прежнего типа обслуживания (Type-of-Service или ToS), что к сожалению ещё является распространённой патологией.

  Отметим, что при настройке потока на применение лишь классического контроля перегрузок вполне уместно не использовать код ECT(1).

A.1.6. Снижение зависимости от RTT

Описание

Расширяемому контролю перегрузки нужно максимально сокращать смещение (bias) RTT по меньшей мере в диапазоне от малых до типичных значений RTT, которые будут взаимодействовать в предполагаемом сценарии внедрения (см. нормативные требования в п. 4 параграфа ).

Мотивация

Известно, что пропускная способность при классическом контроле перегрузки обратно пропорциональна RTT, поэтому можно предполагать, что потоки на путях с очень малым RTT будут истощать потоки путей с большими RTT. Однако классический контроль перегрузки не допускает наличия очень малых RTT, поскольку они вызывают большие очереди. Рассмотрим, например, два пути с базовыми RTT в 1 и 100 мсек. Если классический контроль перегрузки создаёт очередь с задержкой 100 мсек, эти значения RTT превратятся в 101 и 200 мсек, что ведёт к отношению пропускной способности потоков примерно 2:1. Если же классический контроль перегрузок вносит задержку в очереди лишь на 1 мсек, отношение будет 2:101, а для пропускной способности около 50:1.

Поэтому при очень коротких очередях потоки с большим RTT будут истощаться, если расширяемый контроль перегрузки не будет выполнять требования параграфа 4.3.

При RTT больше типичных потоки L4S могут применять такое же смещение RTT как в текущем классическом контроле перегрузок и работать по-прежнему удовлетворительно. Поэтому в параграфе 4.3 нет дополнительных требований к потокам L4S с большим RTT в части смещения RTT.

Одним из способов выполнения этих требований в масштабируемом контроле перегрузки является поведение, при котором аддитивный рост происходит как для стандартного потока Reno, но с большим RTT, путём использования виртуального значения RTT (rtt_virt), являющегося функцией от фактического RTT (rtt). Примеры функций даны ниже.

      rtt_virt = max(rtt, 25 ms)
      rtt_virt = rtt + 10 ms

Функции в этих примерах выбраны так, что по мере снижения фактического RTT от высокого к низкому виртуальное значение RTT сокращается более медленно (см. [PRAGUE-CC]).

Однако потоки с коротким RTT могут быстрее реагировать на изменения доступной пропускной способности, будь то изменение состава потоков или пропускной способности радиоканалов. Таким образом, было бы ошибкой требовать, чтобы потоки с малым RTT были столь же медлительными, как потоки с большим RTT, поскольку это привело бы к ненужно недогрузке каналов и в результате вызывало бы нестабильность. Поэтому вместо строго требования независимости от RTT в п. 4 параграфа 4.3 сказано: «не зависит от RTT, насколько это возможно без ущерба для стабильности и загрузки канала.» Это позволяет потокам с меньшим RTT использовать свои преимущества в гибкости.

A.1.7. Сокращение окна перегрузки

Описание

Расширяемый контроль перегрузки должен сохранять свою реакцию на перегрузки, когда типичные значения RTT через общедоступную сеть Internet становятся существенно меньше в результате меньшей задержки в очередях (см. нормативные требования в п. 5 параграфа ).

Мотивация

В настоящее время предполагается, что минимальное окно перегрузки для TCP (и производных протоколов) с поддержкой ECN составляет 2 максимальных размера сегмента у отправителя (sender maximum segment size или SMSS) или 1 SMSS после тайм-аута повторной передачи. Когда окно перегрузки достигает этого минимума, при наличии дополнительной маркировки ECN протокол TCP должен дождаться тайм-аута повторной передачи, прежде чем отправить новый сегмент,(см. Параграф 6.1.2 в спецификации ECN [RFC3168]). На практике большинство известных алгоритмов контроля перегрузки на основе окна в этот момент перестают реагировать на сигналы ECN и окно перегрузки больше не сокращается независимо от степени маркировки ECN. Отсутствие дополнительной реакции отправителя на перегрузку ведёт к росту очереди, переопределяя любой механизм AQM, и дополнительной задержке в очереди (делая окно достаточно большим для возвращения реакции на перегрузку). Это может приводить к стабильной, но более длинной очереди или вызывать потери в очереди, когда механизм тайм-аута повторной передачи выступает заслоном.

В большинстве элементов контроля перегрузки на основе окна для других протоколов используется похожее минимальное окно, измеряемое в байтах для протоколов, использующих более мелкие пакеты.

Механизмы L4S значительно сокращают задержку в очередях, поэтому на одном и том же пути RTT снижается. Эта проблема становится на удивление распространённой [sub-mss-prob], потому что при одинаковой пропускной способности канала меньшее значение RTT подразумевает меньшее окно. Рассмотрим, например, жилое здание с восходящим каналом широкополосного доступа в Internet со скоростью 8 Мбит/с, предполагая максимальный размер сегмента 1500 байт. Каждый из 2 восходящих потоков будет иметь минимальное окно 2 SMSS, если RTT не больше 6 мсек, что достаточно характерно при доступе к ближайшему ЦОД. При наличии 2 таких потоков TCP перестанет отвечать на ECN и задержка в очередях возрастёт.

Пока расширяемый контроль перегрузки не выполняет с самого начала требования параграфа 4.3, он будет часто показывать невосприимчивость к ECN, сводя на нет преимущества L4S в части малой задержки для себя и других.

Это, по-видимому, подразумевает, что будут требоваться средства расширяемого контроля перегрузки, способные работать с окном перегрузки меньше 1 SMSS. Например, если TCP с поддержкой ECN получает маркер ECN, уже имея окно в 1 SMSS, [RFC3168], он должен отложить передачу до тайм-аута повтора. Менее радикальный, но более сложный механизм может поддерживать окно перегрузки меньше 1 SMSS (при необходимости, значительно меньше), как описано в [Ahmed19]. Вероятно, возможны и другие подходы.

Однако в требованиях параграфа 4.3 указано «следует», поскольку наличие минимального окна не представляется плохим. При конкуренции с неотзывчивым потоком такое окно обеспечивает естественную защиту потока от истощения, сохраняя некоторый поток данных.

Указание для перехода к окну меньше 1 SMSS уровня «следует» при сохранении требований [RFC3168] позволяет отследить варианты изменения минимального окна в разных масштабируемых контроллерах перегрузки.

A.1.8. Измерение устойчивости к нарушению порядка по времени

Описание

При обнаружении потерь масштабируемый контроль перегрузки должен быть устойчив к изменению порядка в адаптивном интервале времени, который меняется в зависимости от пропускной способности, а не только для фиксированного числа пакетов (см. нормативные требования в п. 6 параграфа ).

Мотивация

Основной целью L4S является масштабируемая пропускная способность (отсюда название). Расширяемость во всех измерениях является целью всех технологий IETF. Обратная линейная зависимость реакции (параграф 4.3) необходима, но не достаточна для решения задачи расширяемости контроля перегрузки, указанной в [RFC3649]. Помимо роста частоты сигналов ECN с повышением скорости важно обеспечить отсутствие ограничений на расширение пропускной способности из-за ложного восприятия потерь.

Конечные системы не могут определить причину пропуска пакета – потеря или нарушение порядка. Они могут лишь считать, что произошла потеря, если пропуск в порядковых номерах не был заполнен после поступления определённого числа пакетов (например, правило 3 DupACK стандартного контроля перегрузки TCP [RFC5681]) или по истечении некоторого времени (например, RACK [RFC8985]).

Многолетний рост скорости передачи пакетов, привёл к указанным ниже наблюдениям.

• Даже когда лишь некоторые передающие узлы считают, что произошла потеря на основании подсчёта переупорядоченных пакетов, все сети будут сокращать время, в течение которого они сохраняют порядок пакетов. В некоторых канальных технологиях сохранение примерно неизменным времени, в течение которого изменяется порядок, ведёт с годами к росту числа потерь на этих каналах, предполагаемых хостами.
• Если же все хосты фиксируют потери по времени, интервал времени, в течение которого сеть сохраняет порядок, остаётся практически постоянным.

Поэтому у хостов есть мотивы для обнаружения потерь в интервале времени (чтобы не обманывать себя потерями, которых нет). Для хостов, переходящих на контроль перегрузок L4S, не возникает никакого ущерба при включении кода обнаружения потерь по времени (аппаратное восстановление потерь является исключением, которое будет рассмотрено позже). Поэтому требование к хостам L4S выполнять обнаружение потерь по времени не является обременительным.

Если не применять требования параграфа 4.3 к хостам L4S, даже при отсутствии обременения для хостов все сети столкнулись бы с неопределённостью в части способности некоторых хостов L4S обнаруживать потери по времени. Тогда всем канальным технологиям пришлось бы сокращать время, в течение которого допускается переупорядочение пакетов. Это не является проблемой для некоторых канальных технологий, но для других все сильнее осложняется масштабирование, особенно при использовании группировки каналов (bonding) в таких технологиях как LTE, 5G, DOCSIS¹⁶.

С учётом разных технологий на путях Internet любые ограничения расширяемости для канальных технологий в сетях доступа приведут к ограничению масштабируемости для Internet в целом.

Может возникнуть вопрос осмысленности реализации этого требования к обнаружению потерь лишь на хостах L4S, поскольку сети всё равно будут сталкивать с неопределённостью обнаружения потерь с помощью DupACK для потоков без поддержки L4S. Ответ заключается в том, что канальные технологии, где сложно постоянно сокращать интервал переупорядочивания, должны будут решать вопрос лишь для трафика, не относящегося к L4S (это возможно, поскольку идентификатор L4S виден на уровне IP). Поэтому можно сосредоточить внимание на ресурсах обработки и памяти при расширении классического (не L4S) трафика. Тогда рост доли трафика L4S будет смягчать проблемы масштабирования.

В итоге для хостов L4S не никаких причин быть частью проблемы, а не её решения.

Должно или следует? Как отмечено выше, этот тонкая проблема взаимодействия между хостами и сетями, которая должна быть решена. Если сети не могут быть уверенными, что все хосты L4S перешли к обнаружению потерь по времени, им приходиться принимать худший вариант, постоянно сокращая интервал переупорядочивания, для хостов, использующих подсчёт. Однако было принято решение использовать уровень «следует». Основной причиной послужило то, что сети могут быть достаточно уверены в выполнении требования хостами L4S, поскольку это даёт преимущества и не вызывает проблем.

Детали

Время, затрачиваемое на восстановление потерь, более значимо для краткосрочных потоков, поэтому хорошим компромиссом служит изменение окна переупорядочения от небольшой доли RTT в начале потока до большей части RTT по истечении множества интервалов кругового обхода.

Этот подход в основном принят в RACK [RFC8985]. Однако работа RACK начинается с подхода 3 DupACK, поскольку оценка RTT может быть нестабильной. Пока начальное окно успевает за изменениями, подсчёт 3 DupACK даёт такой же результат, что и обнаружение потерь по времени, поэтому соответствует рекомендациям параграфа 4.3. Это связано с тем, что начальное окно гарантирует, что подсчёт 3 DupACK в начале соединения распространяется на небольшую часть интервала кругового обхода.

Как отмечено выше, имеются аппаратные реализации восстановления потерь с использованием подсчёта DupACK (например, некоторые реализации RoCEv2¹⁷). При малой задержке эти реализации могут сменить свой контроль перегрузок на L4S, поскольку тот (в отличие от восстановления потерь) реализуется программно, но не удаётся выполнить все требования восстановления потерь. Однако считается, что в этом нет необходимости, поскольку сетевые технологии обеспечивают крайне низкую степень нарушения порядка. Поэтому контролируемые среды, где порядок практически не меняется, исключены из нормативных рекомендаций параграфа 4.3.

Обнаружение потерь по времени также предотвращает атаки ACK-splitting, описанные в [Savage-TCP].

A.2. Оптимизация расширяемого транспортного протокола

A.2.1. Установка ECT в пакетах управления и повторных пакетах

Описание

Этот параграф касается TCP и производных от него протокол (например, SCTP), а также RTP/RTCP [RFC6679]. Исходная спецификация ECN для TCP использование ECN для пакетов управления и повторной передачи, а [RFC6679] исключает применение ECT в дейтаграммах RTCP в случаях изменения пути после его проверки на прохождение ECN. Для повышения производительности масштабируемые транспортные протоколы должны разрешать ECN на уровне IP в пакетах управления TCP (SYN, SYN-ACK, ACK и т. п.) и повторно передаваемых пакетах. Это справедливо и для другого транспорта, например, SCTP и RTCP.

Мотивация для TCP

[RFC3168] запрещает применять ECN в указанных типах пакетов TCP по многим причинам. Это означает, что такие пакеты не защищены ECN от потерь при перегрузке, что существенно снижает производительность, особенно для коротких потоков. В ECN++ [ECN++] предложен эксперимент по использованию ECN со всеми типами пакетов TCP, пока доступны отклики AccECN [ACCECN] (что соответствует требованиям параграфа 4.2 для расширяемого контроля перегрузок).

Мотивация для RTCP

В экспериментах L4S нужно в общем случае соблюдать правило спецификации RTP ECN [RFC6679], исключающее ECT в дейтаграммах RTCP. Тем не менее, применение ECN расширяется и будет полезно выполнить некоторые эксперименты для RTCP с поддержкой ECN, чтобы собрать данные о нужности такой предосторожности.

A.2.2. Рост быстрее аддитивного

Описание

Производительность возросла бы, если бы расширяемый контроль перегрузки не ограничивал расширение окна перегрузки стандартным аддитивным увеличением на 1 SMSS за интервал кругового обхода [RFC5681] во время предотвращения перегрузки. Это верно для контроля перегрузки в TCP и производных протоколах, включая аналогичные подходы, применяемые в реальном масштабе времени.

Мотивация

В соответствии с пекущим определением [RFC8257] протокол DCTCP использует обычное аддитивное увеличение Reno в фазе предотвращения перегрузки. Когда доступная пропускная способность увеличивается внезапно (например, при завершении другого потока или увеличении скорости радио-канала), может потребоваться очень много интервалов кругового подхода, чтобы воспользоваться вновь доступной пропускной способностью. Для решения проблемы был разработан протокол TCP CUBIC [RFC8312], но в результате продолжающегося роста скоростей потоков задержка при разгоне до доступной пропускной способностью снова стала чрезмерной (см., например параграф 5.1 в описании архитектуры L4S [RFC9330]). Даже при выходе из режима совместимости с Reno на каждое 8-кратное увеличение скорости потока CUBIC задержка ускорения вырастает вдвое.

В установившемся состоянии DCTCP устанавливает примерно 2 маркера ECN за интервал кругового обхода, поэтому можно быстро определить, когда эти сигналы исчезли и искать доступную пропускную способность быстрее с минимальным влиянием на другие потоки (классические и расширяемые) [LinuxPacedChirping]. В качестве варианта решения проблемы предложен протокол TCP для ЦОД с адаптивным ускорением (Adaptive-Acceleration Data Center TCP или A2DTCP) [A2DTCP]), который можно внедрить в общедоступной сети Internet.

A.2.3. Быстрое схождение при замедленном старте

Описание

Производительность возросла бы, если бы расширяемый контроль перегрузки сходился (к установившемуся состоянию раздела пропускной способности) быстрее (или, хотя бы не медленней), чем классический контроль перегрузки. Это влияет на поведение при запуске потока во всех средствах контроля перегрузки L4S, выведенных из классического транспорта, использующего процедуру замедленного старта TCP (slow start), включая работающие в реальном масштабе времени средства.

Мотивация

Новому потоку DCTCP требуется для получения своей доли пропускной способности в узком месте с наличием других потоков, использующих пропускную способность, больше времени, чем при классическом контроле перегрузки. В среде ЦОД время схождения для DCTCP больше в 1,5 – 2 раза из-за существенно большего уровня маркировки ECN, вызываемой фоновым трафиком DCTCP, что вынуждает новые потоки раньше выходить из режима замедленного старта [Alizadeh-stability]. В тестах для применения в общедоступной сети Internet время схождения DCTCP по сравнению с обычным TCP slow start на основе потери пакетов оказалось ещё хуже [LinuxPacedChirping] из-за низкого порога маркировки ECN, требуемого для L4S. Это усугубляется обычно большим несоответствием скорости канала передающего хоста и типичного узкого места доступа в Internet. Это пагубно в общем случае и особенно сильно влияет на производительность коротких потоков по сравнению с классическим контролем перегрузок.

Приложение B. Компромиссы при выборе идентификатора L4S

Это приложение является информационным, а не нормативным. Как указано в разделе 3, пространства заголовков IP (v4 и v6) не достаточно для полного выполнения требования. Поэтому при выборе идентификатора L4S потребовались компромиссы. В этом приложении приведены аргументы за и против сделанного выбора.

Ниже приведён ненормативный обзор схемы кодов.

Пакеты с кодом ECT(1) и (условно) CE обозначают семантику L4S как альтернативу семантике Classic ECN [RFC3168].

• Код ECT(1) указывает, что пакет передан отправителем, поддерживающим L4S.

• С учётом нехватки кодов L4S AQM и Classic ECN AQM используют общий код CE для индикации встреченной пакетом перегрузки. Если пакета уже получил маркер CE в буфере восходящего направления до поступления в следующий механизм AQM, этот механизм должен угадать для пакета CE классификацию L4S или Classic ECN. Выбор обработки L4S безопасней, поскольку в этом случае несколько классических пакетов могут прибыть раньше, а пакеты L4S не будут задержаны.

• Если классификатор знает о транспорте, может быть доступна дополнительная информация. Тогда классификатор может отнести пакет CE к ECN, если предшествующий пакет ECT из того же потока имел код ECT(0). Однако службе L4S не требуется знать о транспортном уровне.

Возражения

Используется последний код ECN

Служба L4S потенциально может заменить услуги, предоставляемые Classic ECN, поэтому использование ECT(1) для идентификации L4S может в конечном итоге означать, что код ECT(0) потрачен «впустую» лишь для того, чтобы различать две формы ECN.

Сложности ECN на некоторых нижележащих уровнях

Не всегда возможна поддержка эквивалента поля IP-ECN в AQM, работающих в буфере ниже уровня IP [ECN-ENCAP]. В зависимости от схемы нижележащего уровня службе L4S может потребоваться отбрасывать кадр вместо маркировки, даже если она может инкапсулировать пакет с поддержкой ECN.

Риск нарушения порядка классических пакетов CE внутри потока

Отнесение всех пакетов CE к очереди L4S создаёт риск ошибочной классификации пакетов CE, изначально имевших код ECT(0), к L4S. Если в классической очереди имеется задержка, эти некорректно классифицированные пакеты CE придут раньше, вызывая нарушение порядка. Переупорядочение внутри микропотока может вынудить отправителя TCP (и аналогичного транспорта) к ненужным повторам передачи. Однако этот риск чрезвычайно мал в силу указанных ниже причин.

1. Достаточно необычно наличие нескольких узких местам на одном пути (доступная пропускная способность должна быть для этого идентична).
2. Лишь в части таких случаев первое узкое место будет поддерживать маркировку Classic ECN, а второе – L4S ECN. Это будет единственным случаем, где пакеты ECT(0) могут получить маркер CE от AQM, поддерживающего Classic ECN, тогда как далее оставшиеся пакеты ECT(0) будут сталкиваться с дальнейшей задержкой на классической части последующего L4S DualQ AQM.
3. Даже при досрочной доставке нескольких пакетов потребуются весьма необычные условия для вызова ложных повторов в отличие от случаев запоздания некоторых пакетов. В первом узком месте маркеры CE будут применены по меньшей мере для N (размер окна переупорядочивания, разрешаемого транспортным протоколом, прежде, чем он сочтёт пакет потерянным) последовательных пакетов, а второе узкое место внедрит непрерывную последовательность и (по меньше мере) N таких пакетов между двумя пакетами потока, переданными ранее.
   Рассмотрим, например, случай N=3 и последовательность пакетов 100, 101, 102, 103, … Предположим, что пакеты 150, 151, 152, переданные в потоке позднее, были внедрены в последовательность 100, 150, 151, 101, 152, 102, 103, … Если бы это было поздним нарушением порядка, даже 1 пакет с нарушением порядка вызвал бы ложный повтор, но здесь этого не происходит, поскольку пакет 101 перемещает счётчик кумулятивных ACK вперёд на 3 пакета, прибывших с нарушением порядка. Позднее, по приходе пакетов 148, 149, 153, … проблем не будет, несмотря на пропуск 3 пакетов, поскольку пакеты для заполнения пропуска уже находятся в приёмном буфере.
4. Даже при текущей рекомендации TCP N=3 [RFC5681] ложные повторы будут маловероятны по указанным выше причинам. По мере внедрения RACK [RFC8985] возникает тенденция к увеличению размера окна разупорядочения (N), что сделает вероятность преждевременного прибытия N пакетов подряд исчезающе малой.
5. Наличие двух маркеров CE в потоке Classic ECN маловероятно с учётом того, что FQ-CoDel является единственным широко развёрнутым AQM с поддержкой маркировки Classic ECN и он очень тщательно разделяет потоки и равномерно распределяет маркировку между потоками.

Крайне маловероятно, что указанные выше 5 весьма необычных ситуаций возникнут одновременно. Но даже в этом случае последствия вряд ли будут ужасными – неоправданный быстрый повтор передачи. Всякий раз, когда источник трафика (классический контроль перегрузки) ошибочно считает нарушение порядка пакетов CE потерей, можно полагать, что он уменьшит своё окно перегрузки и без необходимости отправит пакет повторно. Однако окно перегрузки уже было бы сокращено при получении маркеров CE. Если отправитель использует ABE [RFC8511], он может сократить cwnd немного сильнее при потере, чем при маркировке CE. Но он вернёт сокращение, как только обнаружит, что повтор передачи был ошибочным.

Отметим, в заключение, что влияние раннего нарушения порядка на ненужные повторы передачи из-за неоднозначности CE, как правило, будет исчезающе малым.

Недостаточное окно anti-replay в некоторых имеющихся VPN

Если задержка сокращается для части потоков внутри VPN, функция anti-replay в некоторых VPN может ошибочно считать задержку replay-атакой. В параграфе 6.2 рекомендуется устанавливать достаточно большое окно anti-replay на выходе VPN в соответствии с требованиями спецификации. Однако в некоторых реализациях VPN максимальный размер окна недостаточно велик для учёта большой разницы в задержке при преобладающих скоростях передачи. В параграфе 6.2 предложены обходные пути, но конечным пользователям L4S через VPN нужно уметь распознавать эти проблемы, чтобы воспользоваться обходными путями.

Трудно отличить Classic ECN AQM

В этой схеме источнику, получившему отклик ECN, не вполне ясно, к какому типу AQM относится маркер CE. Это не является проблемой для источников Classic ECN, которые передают пакеты ECT(0), поскольку L4S AQM считает пакеты ECT(0) классическими и применяет для них маркировку Classic ECN.

Однако без явного устранения неоднозначности маркировки CE источникам L4S приходится применять эвристические методы для выбора реакции на перегрузку (см. Приложение A.1.5). В противном случае при прохождении долгосрочных классических потоков через узкое место с Classic ECN AQM вместе с долгосрочными потоками L4S и применением для потоков L4S отклика L4S на сигналы Classic CE, потоки L4S будут превосходить классические. Эксперименты показали, что потоки L4S могут занять примерно в 20 раз больше общей пропускной способности, чем эквивалентные классические потоки. При сокращении пропускной способности канала (например, до 4 Мбит/с) неравенство уменьшается и классические потоки продолжаются без истощения.

Когда L4S предложили впервые (2015 г., на 14 позже публикации Classic ECN [RFC3168]), считалось, что классические Classic ECN AQM не были внедрены из-за того, что измерения при исследовании не выявили практически никаких признаков маркировки CE. Позднее Classic ECN включили в развёртывание FQ, однако планировщики FQ тормозят потоки L4S, конкурирующие с классическими, поскольку они обеспечивают равенство скоростей потоков. Неизвестно, были ли не связанные с FQ внедрения Classic ECN AQM в последующие годы и будет ли это впредь.

Был предложен алгоритм обнаружения Classic ECN AQM при стабилизации потока после его запуска [ecn-fallback] (см. Приложение A.1.5). Тесты для второй версии алгоритма показали достаточно хорошее обнаружение Classic ECN AQM в разных обстоятельствах, однако алгоритм часто работал некорректно при малой пропускной способности канала и/или больших RTT. Хотя этот обход является безопасным, имеется риск того, что он будет препятствовать применению алгоритма.

Услуги без L4S для пакетов управления

Исключительно для TCP в RFC Classic ECN [RFC3168] и [RFC5562] требуют очистки отправителем поля IP-ECN (Not-ECT) при повторной передаче и в некоторых пакетах управления (в частности, «чистых» ACK, пробы окна, SYN). При классификации пакетов L4S по полю IP-ECN эти пакеты управления TCP не будут отнесены к очереди L4S и в результате могут быть задержаны относительно других пакетов потока. Это не вызовет нарушение порядка (повторные передачи уже нарушают порядок, а пакеты управления обычно не содержат данных), однако повысит уязвимость пакетов управления TCP к потерям и задержке. Для решения проблемы в ECN++ [ECN++] предложен эксперимент по поддержке ECN для всех пакетов управления и повторов TCP, пока доступны отклики ECN.

Поддержка

Нужна сквозная работа

Поле IP-ECN обычно распространяется через Internet без удаления и искажения, по крайней мере в стационарных сетях. В отличие от DSCP, поле ECN пересылается без изменений сетями, не поддерживающими ECN.

Нужна работа в туннелях

Идентификаторы L4S работают через туннели (и в них), передающие поле IP-ECN любым из возможных способов, заданных с момента спецификации туннелирования ECN в 2001 г. [RFC3168]. Однако вполне возможно, что некоторые туннели до сих пор не реализуют распространения ECN.

Нужна работа с разными канальными технологиями

В большинстве (но не во всех) узких местах пути известен протокол IP и L4S AQM могут размещаться там, где возможны манипуляции с полем IP-ECN. Узкие места на узлах нижнего уровня, не знающих IP, будут отбрасывать пакеты для сигнализации перегрузки или применять свои уведомления, заданные канальной технологией, включая обмен сигналами с полем IP-ECN. Программы по определению таких сигналов разрабатываются и схемы, уже определённые для ECN, наследуют и поддержку L4S ().

Возможен переход к одному коду

Если все отправители Classic ECN в конечном итоге перейдут на услуги L4S, код ECT(0) можно будет отдать на другие цели, когда прежнее использование ECT(0) прекратится или сильно сократится (возможно, этого не будет).

L4 не требуется

Будучи основанной на поле IP-ECN, эта схема не нуждается в доступе к идентификаторам потоков транспортного уровня. Тем не менее, она не исключает таких решений.

Приложение C. Возможные конфликты при использовании кода ECT(1)

Код ECT(1) в поле IP-ECN уже был выделен спецификацией ECN nonce [RFC3540], которая признана устаревшей (Historic) [RFC8311]. ECN вероятно является единственным среди протоколов Internet полем, общим для IPv4 и IPv6, сохраняя возможность сквозного применения с туннелями и нижележащими уровнями. Поэтому код ECT(1) не следует переназначать для другого экспериментального использования (L4S) без тщательной оценки возможных конфликтов. Эти вопросы рассматриваются ниже.

C.1. Целостность откликов на перегрузку

Принимающие хосты могут обманывать отправителя для ускорения загрузки, подавляя отклики в маркерах ECN (или потерях, если повтор передачи не требуется или доступен иным способом).

Устаревшая спецификация ECN nonce [RFC3540] предполагала, что отправитель TCP может устанавливать до ECT(0) или ECT(1) в каждом пакете потока и запоминать последовательность установки. Если какой-либо пакет будет потерян или промаркирован при перегрузке, получатель не увидит соответствующий бит. Получатель ECN nonce отправляет назад младший бит суммы, поэтому он не может скрыть потерю или маркировку без 50% вероятности ошибки в сумме.

Крайне маловероятно, что ECT(1) потребуется в качестве nonce для защиты целостности уведомлений. Спецификация ECN nonce [RFC3540] признана устаревшей отчасти из-за появления других способов (без использования кода в заголовке IP) защиты целостности откликов TCP и другого транспорта [RFC8311]. Ниже дано несколько примеров.

• Отправитель может проверить целостность небольшой случайной выборки откликов получателя, время от времени указывая в поле IP-ECN значение, которое обычно устанавливает сеть. Затем он проверяет, верно ли отклики получателя передают ожидаемое (см. п. 2 в параграфе 20.2 спецификации ECN [RFC3168]). Это работает для потерь и подходит для точных откликов ECN [RFC7560], предназначенных для L4S. Как и (устаревшая) спецификация ECN, этот метод не защищает от некорректного поведение отправителя, но позволяет добросовестному отправителю проверить корректность откликов о перегрузке от получателя.

• Сеть может проверить корректность передачи маркеров ECN (или потери пакетов) по всему контуру обратной связи, отслеживая раскрытие перегрузки (Congestion Exposure или ConEx) [RFC7713]. Это предполагает целостность уведомлений о перегрузке и откликов обратной связи. Сведения ConEx доступны в любой точке пути через сеть, поэтому они могут применяться для принудительных откликов на перегрузку. Независимо от подавления получателем или нисходящим направлением в сети откликов о перегрузке или некорректной реакции отправителя на них, ConEx позволяет нейтрализовать любые преимущества, которые можно получить за счёт такого обмана.

• Поля откликов о перегрузке в заголовках транспортного уровня передаются без изменений насквозь и их целостность может быть защищена. Это сохраняет целостность откликов получателя, но не защищает от некорректного поведения получателя или отправителя. Опция аутентификации TCP (TCP Authentication Option или TCP-AO) [RFC5925], сквозная защита QUIC [RFC9001] или защита целостности IPsec [RFC4303] позволяют обнаружить вмешательство в отклики о перегрузке (случайные или враждебные) в TCP, QUIC и ином транспорте. TCP-AO по умолчанию учитывает основной заголовок TCP и опции TCP, но часто не обеспечивает достаточной прочности для использования на многих сквозных путях, где промежуточные устройства могут приводить к отрицательному результату проверки из-за их попыток улучшить производительность или безопасность (например, путём повторной сегментации или сдвига пространства порядковых номеров).

На момент написания этого документа защита целостности транспортных откликов с использованием QUIC становилась обычным делом. Однако по-прежнему не принято защищать целостность более широкого контура обратной связи на основе потерь или Classic ECN. Если это положение измениться в процессе экспериментов L4S, может потребоваться разработка одного или нескольких методов из числа указанных выше.

C.2. Уведомление о менее значимой по сравнению с CE перегрузкой

Исследователи предлагали использовать код ECT(1) в качестве уведомления о менее серьёзной перегрузке, нежели CE, в частности, для того, чтобы потоки могли быстрее заполнить доступную пропускную способность после периода бездействия, при завершении или запуске других потоков, например, как в VCP¹⁸ [VCP] и Queue View (QV) [QV].

Перед назначением ECT(1) на роль идентификатора L4S нужно было решить, не лучше ли сохранить код для будущей стандартизации быстрого ускорения потоков, которая считается важной и долговременной проблемой [RFC6077].

Уведомление до перегрузки (Pre-Congestion Notification или PCN) является ещё одним вариантом альтернативной семантики IP-ECN. Здесь ECT(1) служит для уведомления о менее серьёзной перегрузке, чем CE [RFC6660], однако поле IP-ECN принимает семантику PCN лишь для пакетов с кодом Diffserv, заданным для указания маркировки PCN в контролируемой среде. PCN требуется применять лишь к внешнему заголовку туннеля через контролируемую область, чтобы не было конфликтов с иным сквозным применением поля ECN. Поэтому регион PCN на пути не помешает идентификатору L4S, заданному в разделе 2.

Благодарности

Спасибо Richard Scheffenegger, John Leslie, David Täht, Jonathan Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson, Andrew McGregor за обсуждения, которые привели к созданию этой спецификации. Ing-jyh (Inton) Tsang был одним из авторов предварительных версий документа. Спасибо Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn, Greg White, Tom Henderson, David Black, Gorry Fairhurst, Brian Carpenter, Jake Holland, Rod Grimes, Richard Scheffenegger, Sebastian Moeller, Neal Cardwell, Praveen Balasubramanian, Reza Marandian Hagh, Pete Heist, Stuart Cheshire, Vidhi Goel, Mirja Kühlewind, Ermin Sakic, Martin Duke за помощь и рецензирование документа. Спасибо thanks Ingemar Johansson за рецензирование и предоставление содержательного текста. Спасибо также рецензентам направления: Valery Smyslov, Maria Ines Robles, Bernard Aboba, Lars Eggert, Roman Danyliw, Éric Vyncke. Спасибо Sebastian Moeller за выявление взаимодействия м VPN anti-replay и Jonathan Morton за выявление связанных с этим атак. Отдельная благодарность руководителям tsvwg Gorry Fairhurst, David Black, Wes Eddy за терпеливую помощь для этого и других документов L4S при прохождении процесса IETF. Приложение A с требованием Prague L4S основано на тексте, написанном Marcelo Bagnulo Braun изначально в качестве приложения к [RFC9330]. Этот текст, в свою очередь, был основан на коллективных результатах участников «круглого стола» DCTCP Evolution в рамках IETF 94 [TCPPrague].

Работа авторов частично финансировалась European Community по программе Seventh Framework в рамках проекта Reducing Internet Transport Latency (RITE) (ICT-317700). Работа Koen De Schepper частично финансировалась в рамках проектов 5Growth и DAEMON EU H2020. Работу Bob Briscoe частично финансировалась Research Council of Norway в рамках проекта TimeIn, а также CableLabs и Comcast Innovation Fund. Представленные здесь мнения принадлежат исключительно авторам.

Адреса авторов

Koen De Schepper

Nokia Bell Labs

Antwerp

Belgium

Email: koen.de_schepper@nokia.com

URI: https://www.bell-labs.com/about/researcher-profiles/koende_schepper/

 

Bob Briscoe (editor)

Independent

United Kingdom

Email: ietf@bobbriscoe.net

URI: https://bobbriscoe.net/

---

Перевод на русский язык

(nmalykh@protokols.ru)

---

Internet Engineering Task Force (IETF)                   B. Briscoe, Ed.
Request for Comments: 9330                                   Independent
Category: Informational                                   K. De Schepper
ISSN: 2070-1721                                          Nokia Bell Labs
                                                              M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                                G. White
                                                               CableLabs
                                                            January 2023

Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture

Архитектура службы Internet L4S

PDF

Аннотация

Этот документ описывает архитектуру L4S с малыми задержками и потерями в сочетании с расширяемым управлениям пропускной способностью. Основой L4S является осознание того. Что основной причиной задержки в очередях являются контроллеры перегрузки у отправителей, а не сами очереди. Архитектура L4S позволяет (но не требует) всем приложениям Internet отказаться от алгоритмов контроля перегрузок, которые ведут к существенным задержкам в очередях, и применять вместо них новый класс средств контроля перегрузок, способных определять пропускную способность с очень малыми задержками в очередях. Это достигается за счёт изменения явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) из сети. Новая архитектура обеспечивает приложениям малые задержки и высокую пропускную способность.

Архитектура сосредоточена в основном на поэтапном развёртывании и задаёт механизм, обеспечивающий сосуществование новых механизмов контроля перегрузок L4S с «классическим» контролем в общей сети. Цель заключается в обеспечении с помощью L4S задержки и пропускной способности существенно лучших (редко, худших) обычно без влияния на работу «классических» механизмов.

Статус документа

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус стандартов Internet, см. раздел 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9330.

Авторские права

Авторские права (Copyright (c) 2023) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Трафик из узких каналов (например, домашний доступ в Internet или Wi-Fi) все чаща приходит из приложений, которые предпочитают малые задержки – интерактивные web-приложения и службы, голосовая связь, видео со звуком и интерактивные видеосистемы, интерактивное удалённое присутствие, мгновенный обмен сообщениями, сетевые и облачные игры, удалённые рабочие столы, облачные приложения и дополненная реальность, а также дистанционное управления промышленным оборудованием и процессами с визуальным сопровождением. За последнее десятилетие или около того было много сделано для сокращения задержки путём кэширования и переноса серверов ближе к пользователям. Однако очереди остаются основным, хотя и меняющимся компонентом задержки. Например, всплески задержки до сотен миллисекунд не являются редкостью даже при использовании современного активного управления очередями (Active Queue Management или AQM) [COBALT] [DOCSIS3AQM]. Классический механизм AQM в узких местах сетей доступа обычно настраивается для буферизации пилообразности (sawteeth) отдельных потоков, что может приводить примерно к удвоению задержки во время продолжительных потоков по сравнению с ожидаемой задержкой для незагруженного пути [BufferSize]. Малые потери тоже важны, поскольку для интерактивных приложений потери транслируются в дополнительные задержки, связанные с повтором передачи.

Было показано, что при достижении в сетях доступа скоростей, распространённых сегодня в развитых странах, повышение пропускной способности канала ведёт к снижению скорости отдачи, если проблема задержки не решена. [Dukkipati06] [Rajiullah15]. Поэтому целью является служба Internet с очень малыми задержками в очередях и потерями, а также расширяемой пропускной способностью. Очень малыми считаются задержки меньше 1 мсек в среднем и меньше 2 мсек при 99-м процентиле. Сквозная задержка выше 50 мсек [Raaen14] или даже 20 мсек [NASA04] начинает казаться неестественной для требовательных интерактивных приложений. Поэтому устранение ненужной изменчивости задержек увеличивает зону охвата таких приложений (дальность, при которой использование остаётся комфортным) и/или обеспечивает дополнительный запас времени, который можно использовать для улучшения обработки. Этот документ описывает архитектуру L4S для достижения указанных целей.

Дифференцированное обслуживание (Differentiated service или Diffserv) предлагает ускоренную пересылку (Expedited Forwarding или EF) [RFC3246] для некоторых пакетов за счёт других, но даёт эффекта, когда весь (или большая часть) трафик в узких местах требует малой задержки. L4S хорошо работает в таких случаях, когда весь трафик относится к L4S, поскольку служба «отдаёт не забирая», не требует настройки и управления (регулирование трафика или контракты), связанных с предпочтением одних потоков перед другими.

Задержка в очередях время от времени ведёт к снижению производительности [Hohlfeld14]. Это происходит i) при наличии потока с достаточно большой потребностью в пропускной способности (например, TCP) наряду с другим пользовательским трафиком в узком канале или ii) когда само приложение с малой задержкой запрашивает высокую пропускную способность или адаптивное управление скоростью (например, интерактивное видео). В настоящее время повышенид производительности за счёт L4S должно быть достаточным мотивом для внедрения операторами сетей.

AQM служит частью решения для очередей под нагрузкой, повышая производительность всего трафика, но этому методу присущи ограничения в части сокращения задержки в очереди при изменении сети без устранения причин проблемы.

Первопричиной проблемы является присутствие стандартного контроля перегрузок (Reno [RFC5681]) или совместимых с ним вариантов (например, CUBIC [RFC8312]) в TCP и другом транспорте, таком как QUIC [RFC9000]. Далее в документе похожие на Reno механизмы контроля перегрузок называются «классическими». Эти механизмы вызывают сравнительно большие пилообразные колебания заполнения очередей. Если оператор наивно пытается сократить задержки в очереди путём настройки AQM для работы с уменьшенной очередью, классический контроль перегрузок приведёт к значительному недоиспользованию канала в ниженей части каждого зубца пилы. Продолжительность зубьев увеличивается по мере роста скорости потока (см. параграф 5.1 и [RFC3649]).

Было показано, что при замене на передающем узле классического контроля перегрузок расширяемым (Scalable) производительность упомянутых выше приложений под нагрузкой может существенно возрастать после внедрения в сети подходящего механизма AQM. В приведённом ниже примере решения с использованием ЦОД TCP (Data Center TCP или DCTCP) [RFC8257] Dual-Queue Coupled AQM [RFC9332] на канале DSL или Ethernet задержка в очереди при значительной нагрузке составляет 1-2 мсек при 99-м процентиле без потери полезной загрузки (utilization) [L4Seval22] [DualPI2Linux] (для других типов каналов ситуация описана в параграфе 6.3). Это сопоставимо со средней задержкой 5-20 мсек для классического контроля перегрузки и современных AQM, таких как Flow Queue CoDel [RFC8290], Proportional Integral controller Enhanced (PIE) [RFC8033], DOCSIS PIE [RFC8034] и 20-30 мсек при 99-м процентиле [DualPI2Linux].

Архитектура L4S предназначена для поэтапного внедрения. Можно развернуть службу L4S в узком месте одновременно с имеющимися службами best efforts [DualPI2Linux], чтобы неизмененные приложения могли начать использование службы сразу же по обновлении сетевого стека отправителя. В сетях доступа обычно узким место является одиночный канал для каждого сайт (дом, небольшое предприятие или мобильное устройство), поэтому развёртывание службы на одной или обеих сторонах такого канала должно обеспечить почти все преимущества в соответствующем направлении. Для TCP [ACCECN] отправитель проверяет предоставление получателем более точных откликов, а для иного транспорта, такого как QUIC [RFC9000] и DCCP³ [RFC4340] подходят любые получатели.

В этом документе представлена архитектура L4S, состоящая из 3 компонентов: изоляция в сети трафика L4S от классического, свойства протокола, позволяющие элементам сети идентифицировать трафик L4S и поддержка контроля перегрузок L4S на хосте. Протокол определён отдельно в [RFC9331] как экспериментальное изменение явных уведомлений о перегрузке (ECN). Этот документ описывает и обосновывает составные части архитектуры и их взаимодействия для обеспечения малой задержки и потерть, а также расширяемых услуг Internet. Кроме того, в документе подробно рассматривается поэтапное развёртывание, упомянутое здесь.

1.1. Структура документа

Этот документ описывает архитектуру L4S в три приёма. В разделе 2 приведён краткий обзор идеи на высоком уровне и описаны основные компоненты с минимальным обоснованием. Это предназначено лишь для организации контекста определения терминов в разделе 3 и разъяснения структуры оставшейся части документа. Раздел 4 содержит более подробное описание каждого компонента с обоснованиями, но по-прежнему описывает архитектуру, а не способы реализации. В разделе 5 объясняется выбор каждого элемента решения () и отличия от других подходов ().

После описания архитектуры в разделе 6 рассмотрена её применимость путём описания возможных применений и вариантов использования, которые послужили мотивами для разработки. Рассмотрены проблемы, связанные с применением архитектуры для разных технологий канального уровня, модели поэтапного внедрения (включая 2 основных топологии развёртывания, различные последовательности внедрения и взаимодействие с существующими подходами). Документ завершается обычными заключительными частями, включая подробное рассмотрение вопросов организации трафика и соображений безопасности в разделе 8.

2. Обзор архитектуры L4S

Ниже очерчены три основных компонента архитектуры L4S: 1) расширяемые (Scalable) элементы контроля перегрузок на передающем хосте, 2) механизм AQM в узких местах сети (bottleneck), 3) протокол взаимодействия.

Сначала нужно уяснить главное – малые задержки не обеспечиваются сетью, а являются результатом осторожного поведения контроллеров перегрузки с масштабированием, используемых отправителями L4S. Сеть играет определённую роль в первую очередь для изоляции трафика L4S с малыми задержками от очередей с большой задержкой, требуемых для имеющегося трафика с «классическим» поведением. Сеть также изменяет способ сигнализации транспорту о росте очередей. Сеть использует протокол ECN, но сигнализирует о начале роста очереди незамедлительно без задержки, связанной со сглаживанием, характерной для Classic AQM. Поскольку поддержка ECN важна для L4S, отправители используют поле ECN как протокол, позволяющий сети отличать пакеты L4S от классических.

1. Хост

   Расширяемые элементы контроля перегрузок уже имеются. Они решают задачи масштабирования для классических элементов контроля перегрузок, таких как Reno или CUBIC. Поскольку скорости потоков выросли с момента разработки контроля перегрузок TCP в 1988 г., для достаточно продолжительных потоков на восстановление (в результате маркировки ECN или потери пакетов) затрачиваются сотни круговых обходов (round trip), как показано в примерах параграфа 5.1 и в [RFC3649], и их число продолжает расти. Поэтому контроль за постановкой в очередь и её использованием ослабляется и малейшие нарушения (например, появление новых потоков) препятствуют достижению высокой скорости.

   При расширяемом контроле перегрузок среднее время от одного сигнала перегрузки до следующего (время восстановления) инвариантно к изменению скорости потока при сохранении прочих условий. Это обеспечивает одинаковый уровень контроля за постановкой в очередь и её использованием независимо от скорости потока, а также гарантирует устойчивость к нарушениям при высокой скорости потока. Наиболее распространенным расширяемым контролем перегрузок (в контролируемых средах) является протокол DCTCP [RFC8257], реализованный и развёрнутый в серверных версиях Windows (Server Edition), начиная с 2012 г., а также в Linux и FreeBSD. Несмотря на хорошую работу функций DCTCP в широком диапазоне значений времени кругового обхода (round-trip time или RTT), в большинстве реализацию отсутствуют некоторые функции защиты, которые требуются для работы за пределами контролируемых сред, таких как ЦОД (см. ). Поэтому нужно реализовать расширяемые элементы контроля перегрузок в TCP и других транспортных протоколах (QUIC, SCTP⁴, RTP/RTCP, RMCAT⁵ и т. п.). За время подготовки и публикации этого документа были реализованы расширяемые элементы контроля перегрузок Prague для TCP и QUIC [PRAGUE-CC] [PragueLinux], вариант L4S контроллера RMCAT SCReAM [SCReAM-L4S] и связанная с L4S ECN часть BBRv2⁶ [BBRv2] для транспорта TCP и QUIC.

2. Сеть

   Трафик L4S нужно изолировать от задержки в очередях классического трафика. Одним из путей решения является поддержка одной очереди на поток приложения (FQ), например, FQ-CoDel [RFC8290]. Однако достаточно использовать лишь две очереди и не требовать проверки транспортных заголовков в сети, что возможно не всегда (см. ). При наличии лишь двух очередей может показаться невозможным узнать, какая пропускная способность нужно запланировать для каждой очереди, без определения числа потоков, использующих каждую очередь в каждый момент. И нежелательно произвольно делить пропускную способность сети доступа на две части. Для решения этой задачи с минимальными сложностями был разработан механизм Dual-Queue Coupled AQM. Он действует как полупроницаемая мембрана, которая разделяет задержку, но не пропускную способность. Таким образом, две очереди предназначены для перехода от классического поведения к L4S, а не для приоритизации полосы.

   В разделе 4 дано высокоуровневое объяснение работы вариантов FQ и DualQ для L4S, а в [RFC9332] дано полное объяснение модели DualQ Coupled AQM. Конкретный алгоритм маркировки не задан для L4S AQM и в приложениях к [RFC9332] приведены ненормативные примеры, которые были реализованы и оценены, а также даны рекомендации для принятых по умолчанию значений параметров. Предполагается, что эксперименты с L4S улучшат понимание настройки параметров и выбора алгоритмов маркировки.

3. Протокол

   Передающий хост должен отмечать пакеты L4S и классические разными идентификаторами, чтобы сеть могла классифицировать их для разной обработки. В спецификации идентификатора L4S [RFC9331] сделано заключение, что все варианты требуют компромиссов, но коды ECT(1) и CE⁷ в поле ECN представляют работоспособное решение. Как уже отмечено, сеть также использует ECN для незамедлительной сигнализации транспорту о самом начале роста очереди.

3. Терминология

Classic Congestion Control – классический контроль перегрузок

Поведение контроля перегрузок, способное сосуществовать со стандартным Reno [RFC5681] без существенного негативного влияния на скорость потока [RFC5033]. Проблема расширяемости классического контроля перегрузок рассмотрена на примерах в параграфе и [RFC3649].

Scalable Congestion Control – расширяемый контроль перегрузок

Контроль перегрузок, где среднее время от одного сигнала насыщения до следующего (время восстановления) не зависит от скорости потока при прочих равных условиях. Например, DCTCP усредняет 2 сигнала пересылки за интервал кругового обхода, независимо от скорости потока, как и другие недавно разработанные расширяемые механизмы контроля перегрузок, такие как Relentless TCP [RELENTLESS], Prague для TCP и QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], L4S-вариант SCReAM для потоков в реальном масштабе времени [SCReAM-L4S] [RFC8298]. Дополнительные сведения можно найти в параграфе 4.3 [RFC9331].

Classic Service – классический сервис

Классический сервис предназначен для всех вариантов поведения контроля перегрузок, сосуществующих с Reno [RFC5681] (например, сам Reno, CUBIC [RFC8312], Compound [CTCP], TFRC [RFC5348]). «Классической очередью» называется очередь, обеспечивающая классический сервис.

Low Latency, Low Loss, and Scalable throughput (L4S) service – сервис с малыми задержками и потерями, а также расширяемой пропускной способностью

Сервис L4S предназначен для трафика с расширяемыми алгоритмами контроля перегрузок, такими как Prague [PRAGUE-CC], который был выведен из DCTCP [RFC8257]. Сервис L4S предназначен для более широкого класса трафика, нежели просто Prague, и позволяет развивать набор средств контроля перегрузок, аналогичных Prague, таких как отмечены выше (Relentless, SCReAM и т. п.). Очередью L4S называется очередь, обеспечивающая услуги L4S.

Атрибуты Classic и L4S могут применяться к очередям (queue), кодам (codepoint), идентификаторам (identifier), классификации (classification), пакетам (packet), потокам (flow). Например термин «пакет L4S» относится к пакету с идентификатором L4S, переданному из системы контроля перегрузок L4S.

Оба типа сервиса (Classic и L4S) могут справляться с некоторой долей неотзывчивого и слабо отзывающегося трафика, но в случае L4S скорость должна быть достаточно плавной или низкой, чтобы не возникала очередь (например, DNS, VoIP, синхронизация игр и т. п.).

Reno-friendly – совместимость с Reno

Часть классического трафика, совместимая со стандартным контролем перегрузок Reno, заданным для TCP в [RFC5681]. Спецификация TFRC [RFC5348] косвенно подразумевает, что дружественностью (совместимостью) считается «нахождение обычно в пределах двухкратного отличия скорости передачи потока TCP при одинаковых условиях». Термин Reno-friendly используется здесь вместо TCP-friendly, поскольку последнее выражение стало неточным, так как протокол TCP сейчас использует много разных вариантов контроля перегрузок, а Reno применяется не только в TCP, но и в других транспортных протоколах (например, QUIC [RFC9000]).

Classic ECN – классический механизм явных уведомлений о перегрузке

Исходный механизм явных уведомлений о перегрузке (ECN) [RFC3168] требует считать сигналы ECN эквивалентом отбрасывания пакетов как при генерации в сети, так и отвечающим хостом.

Для L4S имена кодов 2-битового поля IP-ECN не отличаются от заданных в спецификации ECN [RFC3168] – Not-ECT, ECT(0), ECT(1), CE, где ECT указывает поддержку ECN в транспорте (ECN-Capable Transport), а CE – возникновение перегрузки (Congestion Experienced). Пакеты с кодом CE называют промаркированными ECN (ECN-marked), а иногда – просто маркированными, если наличие ECN ясно из контекста.

Site – сайт

Дом, мобильное устройство, небольшое предприятие или кампус, где узким местом сети является канал доступа. Этому определению соответствуют не все сети, но оно является полезным и широко распространенным.

Traffic Policing – надзор за трафиком

Ограничение трафика путём отбрасывания пакетов или их перевода в более низкий класс обслуживания (в отличие от внесения задержки, называемого формированием или формовкой трафика – traffic shaping). Надзор может включать ограничение скорости и/или размера всплесков (пиков). Надзор, сосредоточенный на ограничении очередей, а не средней скорости потока, в этом документе называется надзором за перегрузкой (congestion policing), задержкой (latency policing), всплесками (burst policing) или защитой очередей (queue protection). В иных случаях применяется термин «надзор за скоростью (rate policing).

4. Компоненты архитектуры L4S

Элементы архитектуры L4S описаны в следующих 3 параграфах.

4.1. Протокольные механизмы

Архитектура L4S включает a) отмену прежнего использования идентификатора, b) новое назначение того же идентификатора, c) дополнение необязательных идентификаторов, как описано ниже.

1. Важным аспектом расширяемого контроля перегрузок является использование явных сигналов о перегрузке. В классическом ECN [RFC3168] требуется считать сигнал ECN эквивалентом отбрасывания независимо от генерации сигнала в сети или на отвечающем хосте. L4S требует от сетей и хостов поддерживать более чёткую трактовку каждого сигнала ECN, который менее важен, чем отбласывание. Поэтому сигнала L4S:

• • могут быть более частыми;

  • могут передаваться незамедлительно (без задержки, требуемой для сглаживания флуктуаций очереди.

Для поддержки L4S, пришлось изменить стандартную спецификацию ECN [RFC3168], чтобы пакеты L4S могли передаваться не только как эквивалент отбрасывания. [RFC8311] является обновлением стандарта, смягчающим требования [RFC3168] (и некоторых других Standards Track RFC) и обеспечивающим возможность экспериментальных изменений, предложенных для L4S. Кроме того, ког ECT(1), ранее считавшийся экспериментальным ECN nonce [RFC3540], в [RFC8311] перенесён в число устаревших (historic), чтобы код можно было использовать заново.

1. В [RFC9331] указано, что ECT(1) служит идентификатором для пакетов L4S при отдельной от классических пакетов обработке. Это соответствует требованиям по указанию альтернативной обработки ECN в [RFC4774].

   Ко CE служит для индикации возникновения перегрузки в обоих случаях (L4S и Classic). Это вызывает опасение, что прежний механизм Classic AQM на пути может пометить некоторые пакеты ECT(0) как CE и затем они будут ошибочно отнесены к очереди L4S. В Приложении B к [RFC9331] разъяснено, что должны совпасть 5 маловероятных условий, чтобы возникли нежелательные эффекты, которые и в этом случае приведут лишь к пренебрежимо малой вероятности ненужного повтора передачи.

2. Оператор сети может захотеть включать определённый не отвечающий трафик, не относящийся к L4S, в очередь L4S, если он представляется достаточно сглаженным и низкоскоростным, чтобы не создавать очередь (например, VoIP, дейтаграммы синхронизации сетевых игр с малой скоростью, DNS, LDAP⁸ и т. п.). Такой трафик требуется помечать конкретными идентификаторами, например кодом Diffserv для малой задержки, таким как EF [RFC3246], NQB⁹ [NQB-PHB], или своим идентификатором оператора.

4.2. Сетевые компоненты

Архитектура L4S нацелена на обеспечение малой задержки без необходимости выполнять в элементах сети операции на уровне отдельных потоков. Тем не менее, архитектура не отвергает решений по потокам. Ниже описаны известные схемы: a) DualQ Coupled AQM с L4S AQM в одной очереди, связанным с Classic AQM в другой, b) очереди по потокам с экземпляром Classic и L4S AQM в каждой очереди, c) двойные очереди с AQM для каждого потока, но без очередей по потокам.

1. Dual-Queue Coupled AQM () обеспечивает упомянутую выше полупроницаемую мембрану.

• • Изоляция задержки. Применяются 2 отдельных очереди для изоляции задержки в очереди L4S от большей задержки, требуемой для поддержки полной загрузки канала классическим трафиком.

  • Объединение пропускной способности. Две очереди действуют так, будто они имеют общую пропускную способность, где потоки любого типа получают примерно равные доли без необходимости идентификации потоков в планировщике. Это достигается за счёт наличия AQM в каждой очереди с передачей сигналов перегрузки от Classic AQM в обе очереди так, чтобы обеспечить согласованную реакцию обоих классов контроля перегрузки. В частности, Classic AQM выдаёт сигналы отбрасывания и маркировки на основе перегрузки в его очереди и это влияет на вероятность маркировки в очереди L4S. Степень связывания сигналов перегрузки между двумя очередями достаточна для того, чтобы потоки L4S замедлялись, оставляя нужную долю пропускной способности классическим потокам (как будто это потоки одного типа, использующие общую очередь).

После этого планировщик может обслуживать очередь L4S с приоритетом (вход с высшим приоритетом указан 1 на рисунке), поскольку объём трафик L4S недостаточно велик для полного использования предоставленного приоритета. Поэтому:

• • для кратковременной изоляции задержек (доли RTT) приоритизация очереди L4S защищает малую задержку, позволяя всплескам (пикам) быстро рассеиваться;

  • для объединения пропускной способности в более продолжительных интервалах времени (RTT и больше) классическая очередь создаёт равное и противонаправленное давление на трафик L4S, чтобы ни один из типов не получил преимущества при разделении пропускной способности; противоречие между приоритизацией L4S и связыванием с маркировкой из Classic AQM обеспечивает приблизительную беспристрастность по отношению к потокам.

Для предотвращения приоритизации трафика L4S, на некоторое время блокирующей классическую очередь в отдельных реализациях, рекомендуется задавать приоритет по условию, а не строго (см. Приложение A к спецификации DualQ [RFC9332]).

При отсутствии классического трафика в дело включается AQM очереди L4S, начиная маркировку перегрузки с очень малой очереди, поэтому для трафика L4S обеспечивается очень малая задержка в очереди.

Если какая-либо из очередей становится постоянно перегруженной, происходит отбрасывание некоторых пакетов с поддержкой ECN, как рекомендует раздел 7 спецификации ECN [RFC3168] и параграф 4.2.1 рекомендация для AQM [RFC7567]. Компромиссы разных подходов обсуждаются в параграфе 4.2.3 спецификации DualQ [RFC9332] (на рисунке не показано).

Механизм Dual-Queue Coupled AQM задан максимально обобщенно [RFC9332] без указания конкретных AQM в очередях, чтобы разработчики могли реализовать разные идеи. Информационные приложения к спецификации содержат примеры псевдокода для двух разных подходов AQM – DualPI2 (произносится как Dual PI Squared) [DualPI2Linux] с использованием PI2-варианта PIE и не требующий настройки (zero-config) вариант RED, называемый Curvy RED. DualQ Coupled AQM на основе PIE был также задан и реализован для Low Latency DOCSIS [DOCSIS3.1].

1.                (3)                  (2)
                  .-------^------..------------^------------------.
    ,-(1)------.                               _____
   ; _________  :            L4S  -------.    |     |
   :|Расшир.  | :               _\      ||__\_|марк.|
   :|отправит.| :  __________  / /      ||  / |_____|\   ___________
   :|_________|\; |          |/   -------'       ^    \1|Планировщик|
    `----------'\_|Классифик.|        Связывание :     \|приоритета |_\
     _________  / |  IP-ECN  |                   :     /|по условию | /
    |Классич. |/  |__________|\   -------.     __:__  / |___________|
    |отправит.|                \_\ || | ||__\_|марк/|/
    |_________|                  / || | ||  / |отбр.|
                          Classic -------'    |_____|
   
   
   (1) Передающий хост с масштабированием
   (2) Изоляция в разных сетевых очередях
   (3) Протокол идентификации пакетов

   Рисунок . Компоненты решения L4S DualQ Coupled AQM.

   
   Очереди по потокам и AQM. Для L4S можно использовать планировщик с очередями по потокам, такой как FQ-CoDel или FQ-PIE. Например, в каждой очереди системы FQ-CoDel, а также CoDel AQM обычно имеется опция маркировки ECN с незамедлительным (не сглаженным) низким порогом для поддержки использования в ЦОД (см. параграф 5.2.7 спецификации FQ-CoDel [RFC8290]). В Linux это было изменено так, что низкий порог может применяться исключительно к пакетам ECT(1) [FQ_CoDel_Thresh]. Затем при наличии в очереди потока потока пакетов Not-ECT или ECT(0) применяется Classic AQM (например, CoDel), а если в очереди имеется поток пакетов ECT(1), применяется более низкий порог (обычно доли миллисекунды). Кроме того пакеты ECT(0) и Not-ECT могут выделяться в отдельную от пакетов ECT(1) и CE очередь, чтобы избежать смешивания при использовании ими общего идентификатора потока (например, в VPN).

2. Двойные очереди с AQM по потокам. Следует также обеспечивать возможность использовать двойные очереди для изоляции, но с маркировкой по потокам для управления их скоростями (вместо связанной маркировки по потокам Dual-Queue Coupled AQM). Одна из двух очередей будет изолировать пакеты L4S, которые помечались бы кодом ECN. Скорости потоков можно регулировать с помощью маркировки в конкретном потоке. Целью маркировки может быть дифференциация (например, [Nadas20], где требуется передача дополнительных сигнальных значений по потокам) или выравнивание скоростей потоков (возможно, аналогично Approx Fair CoDel [AFCD] [CODEL-APPROX-FAIR], но с двумя очередями).

   Отметим, что при использовании DualQ без указания маркировки по очередям или потокам это означает AQM с двойной очередью и маркировкой по очередям.

4.3. Механизмы хостов

Архитектура L4S включает на конечных хостах 2 механизма, указанных ниже.

1. Расширяемый контроль перегрузок у отправителя. В разделе 2 для расширяемого контроля перегрузок задано поведение расширяемого контроля перегрузок, при котором среднее время от одного сигнала перегрузки до следующего (время восстановления) не зависит от скорости потока при прочих равных условиях. Наиболее распространенным примером является DCTCP, описанный в информационном документе [RFC8257] для протокола, применяемого в настоящее время в контролируемых средах. Составлен список улучшений безопасности и производительности для расширяемого контроля перегрузок, применимого в общедоступной сети Internet (см. Приложение A. Обоснование требований Prague L4S к [RFC9331]). Часть требований, с которыми может быть связан ущерб для других, перечислена в нормативном разделе 4 [RFC9331]. TCP Prague [PRAGUE-CC] реализован в Linux в качестве образца для выполнения этих требований [PragueLinux].

   Транспортные протоколы, отличные от TCP, используют различные элементы контроля перегрузок, разработанные для совместимости с Reno. Прежде, чем они смогут использовать услуги L4S, эти механизмы нужно обновить для реализации масштабируемых откликов на перегрузку, которые используют код ECT(1). Рассматриваются расширяемые варианты для недавних транспортных протоколов (например, QUIC), а связанная с L4S ECN часть of BBRv2 [BBRv2] [BBR-CC] является расширяемым контролем перегрузок, предназначенным, среди прочего, для транспорта TCP и QUIC. Реализован также L4S-вариант контроллера RMCAT SCReAM [RFC8298] для потоков, доставляемых по протоколу RTP [SCReAM-L4S].

   В параграфе 4.3 спецификации L4S ECN [RFC9331] расширяемый контроль перегрузок определён более подробно и заданы требования для L4S Scalable congestion control.

2. Отклики ECN в некоторых транспортных протоколах уже достаточно детализированы для L4S (в частности, DCCP [RFC4340] и QUIC [RFC9000]), но другие нужно обновлять или они находятся в процесс обновления.

• • Для TCP протокол обратной связи ECN использует допущение из Classic ECN [RFC3168] об эквивалентности маркировки ECN отбрасыванию пакета, что делает его непригодным для Scalable TCP. Поэтому реализации получателей TCP нужно обновлять [RFC7560]. Работы по стандартизации и реализации более точных откликов ECN для TCP (AccECN) ещё не завершены [ACCECN] [PragueLinux].

  • Отклики ECN лишь очерчены в приложениях к признанной устаревшей второй спецификации SCTP [RFC4960], а более полная спецификация предложена в давно просроченном документе [ECN-SCTP]. Нужно разработать и внедрить новое решение для поддержки L4S в SCTP.

  • Для RTP отклики ECN заданы в [RFC6679], а [RFC8888] предлагает последние улучшения Standards Track.

5. Обоснование

5.1. Почему эти компоненты выбраны основными?

Явные сигналы о перегрузке (протокол)

Явные сигналы о перегрузке являются важнейшей частью L4S. Использование отбрасывания в качестве сигнала перегрузки создаёт напряжённость, поскольку отбрасывание является одновременно ущербом (чем меньше, тем лучше) и полезным сигналом (чем больше, тем лучше).

• Явные сигналы о перегрузке можно использовать неоднократно в интервале кругового обхода для обеспечения жёсткого контроля без нанесения вреда. При высокой нагрузке могут передаваться ещё более явные сигналы, чтобы очередь оставалась короткой при любой нагрузке. В отличие от этого, механизмы Classic AQM должны часто отбрасывать пакеты при высокой нагрузке для сохранения короткой очереди. При использовании ECN в контроле перегрузки L4S сокращается размер зубьев пилы и возврат к рабочей точке происходит чаще и можно не заботиться о росте числа сигналов из-за увеличения числа зубьев. Сокращение амплитуды зубьев соответствует меньшему интервалу между пустой очередью и очень низким порогом маркировки (~1 мсек в общедоступной сети Internet), поэтому вариации задержки будут очень малы без риска недогрузки каналов.
• Явные сигналы о перегрузке могут передаваться незамедлительно для отслеживания флуктуаций очереди. L4S переносит сглаживание от сетевых устройств к хостам. Сеть не знает RTT для каких-либо потоков, поэтому при сглаживании в сети (как в классическом подходе) предполагается худшее значение RTT, поскольку иначе потоки с большим RTT становятся нестабильными. Это задерживает классические сигналы перегрузки на 100-200 мсек. В отличие от сети, хосты знают своё значение RTT, поэтому в модели L4S хост может сглаживать каждой поток по своему значению RTT, внося при этом лишь незначительную задержку (обычно несколько миллисекунд). Хост может даже не вносить задержку на сглаживание, если это приемлемо (например, при запуске потока).

Оба указанных выше пункта неосуществимы, если явная сигнализация о перегрузке считается «эквивалентом отбрасывания» (как в Classic ECN [RFC3168]), поскольку отбрасывание является не только сигналом, но и «повреждением». Поэтому отбрасывание не может быть очень частым и не может происходить сразу же, иначе пакеты будут слишком часто отбрасываться просто из-за кратковременных флуктуаций в очереди. В результате в L4S AQM очередь L4S использует новый вариант L4S ECN, который не эквивалентен отбрасыванию (параграф 5.2 в спецификации L4S ECN [RFC9331]), тогда как в классических очередях применяется Classic ECN [RFC3168] или отбрасывание, которые по-прежнему эквивалентны друг другу.

До стандартизации Classic ECN были различные предложения придать маркировке ECN значение, отличное от отбрасывания. Однако не было веских причин принимать эти предложения, поэтому был выбран вариант эквивалентности. В [RFC3168] указано:

Среда, где все конечные узлы поддерживают ECN, позволяет разработать новые критерии установки маркера CE и механизмы контроля перегрузки для реакции конечных узлов на CE-пакеты. Однако рассмотрение этого вопроса выходит за рамки данного документа.

Изоляция очередей (сеть)

Контроль перегрузки L4S сохраняет задержку в очереди достаточно низкой, тогда как классическому контролю нужна задержка в очереди порядка RTT, чтобы избежать недогрузки канала. Одна очередь не может иметь двух размеров, поэтому трафик L4S нужно выделять в отдельную очередь (например, DualQ) или очереди (скажем, FQ).

Связанные уведомления о перегрузке

Связывание уведомлений о перегрузке между двумя очередями, как в DualQ Coupled AQM, не требуется, но обеспечивает простой способ позволить отправителям определять свою скорость пакет за пакетом, вместо её переопределения сетевым планировщиком. Альтернативой является управление скоростью каждого прикладного потока сетевым планировщиком (см. обсуждение в параграфе ).

Идентификатор пакета L4S (протокол)

При наличии в сети хотя бы 2 вариантов обработки пакетов, хостам нужен идентификатор на уровне IP для указания желаемого типа обработки.

Расширяемые уведомления о перегрузке

Расширяемый контроль перегрузки на хосте поддерживает высокую частоту передачи сигналов из сети независимо от скорости потока, поэтому вариации задержки в очередях могут быть малы при стабильных условиях, а скорость может отслеживать изменения доступной пропускной способности насколько возможно быстро.

Низкие потери

Задержки не являются единственной проблемой, решаемой L4S. Связанная с малыми потерями (Low Loss) часть имени указывает, что L4S обычно обеспечивает отсутствие потерь при перегрузке благодаря применению ECN. Иначе сами потери вызывали бы задержку из-за повтора передачи, особенно для коротких потоков [RFC2884].

Расширяемая пропускная способность

Связанная с расширяемостью пропускной способности (Scalable throughput) часть имени означает расширяемые элементы контроля перегрузки по потокам с неограниченным расширением, что позволяет избежать проблем, неизбежных при использовании алгоритмов Reno-friendly [RFC3649]. При разработке в 1988 г. механизмов предотвращения перегрузки TCP было известно, что это не будет расширяться до случаев с большим произведением пропускной способности на загрузку (bandwidth-delay product, см. примечание 6 в [TCP-CA]). Сегодня скорости потоков в широкополосных каналах WAN уже вышли за пределы расширяемости контроля перегрузок Classic Reno, поэтому были развёрнуты более расширяемые варианты TCP CUBIC [RFC8312] и Compound [CTCP]. Однако они тоже уже приближаются к своим пределам масштабируемости.

Рассмотрим в качестве примера сценарий с максимальным RTT 30 мсек на пике каждого зуба пилы. Если скорость передачи пакетов Reno увеличивается в 8 раз (с 1250 до 10000 пакет/с или с 15 до 120 Мбит/с при размере пакетов 1500 байт), время восстановления после перегрузки также растёт в 8 раз от 422 мсек до 3,38 сек. Очевидно, что контролю перегрузки потребуется на восстановление после каждого факта перегрузки несколько секунд. Механизм CUBIC [RFC8312] был разработан для увеличения масштабируемости, но он приближается к своему пределу. При том же максимальном RTT 30 мсек и скорости 120 Мбит/с CUBIC остаётся в режиме полной совместимости с Reno и восстановление займёт около 4,3 сек. Однако при следующем увеличении скорости в 8 раз до 960 Мбит/с алгоритм переходит в режим CUBIC со временем восстановления 12,2 сек. С этого момента каждое следующее увеличение скорости в 8 раз удваивает время восстановления CUBIC (кубический корень от 8 равен 2), например, при скорости 7,68 Гбит/с время восстановления будет 24,3 сек. При расширяемом контроле перегрузок, таком как DCTCP или Prague выдаётся в среднем 2 сигнала на интервал кругового обхода независимо от скорости потока, что делает динамический контроль очень строгим.

Представление о скорости отдельного потока загрузки (download) на момент написания документа (2021 г.) можно составить по данным [BDPdata] – усреднённая глобально средняя скорость стационарного доступа в 2020 г. составляла 103 Мбит/с, а среднее базовое значение RTT для CDN¹⁰ – от 25 до 34 мсек (2019 г.). Усреднение по странам выполнялось с учётом числа пользователей Internet (данные, собранные по миру, имеют разную достоверность, но в документе применена двойная проверка и результаты хорошо согласуются с другим источником). Таким образом, одиночному потоку CUBIC в лучшем случае потребовалось бы около 200 интервалов RTT (5 секунд) для восстановления после каждого спада пилы, если поток был достаточно долгим. Это указано как «лучший случай», поскольку предполагается, что все применяют AQM, тогда как на деле большинство пользователей имеет (возможно раздутый) буфер tail-drop. В этом случае (tail-drop) вероятное среднее время восстановления было бы не меньше 20 сек. (4 раза по 5 сек), поскольку RTT под нагрузкой будет по меньшей мере вдвое превышать значение для AQM, а время восстановления потоков Reno-friendly пропорционально квадрату RTT.

Хотя работа по масштабированию средств контроля перегрузок обычно начинается с транспорта TCP, сказанное выше относится и к другому транспорту (например, SCTP и QUIC) и менее гибким алгоритмам (например, RMCAT), которые обычно основаны на похожих разработках.

5.2. Что L4S добавляет к имеющимся подходам

Ниже указаны связанные с тем же пространством проблем подходы, для которых L4S что-то добавляет или улучшает.

Diffserv

Diffserv решает задачу выделения пропускной способности для важного трафика, а также сокращения задержки в очередях для трафика, чувствительного к задержкам. L4S решает лишь задачу сокращения задержки в очереди. Потребность в Diffserv сохраняется там, где нужно отдать приоритет важному трафику (например, из коммерческих соображений или для защиты важного инфраструктурного трафика) [L4S-DIFFSERV]. L4S может обеспечивать малые задержки для всего трафика в каждом классе Diffserv (включая случай наличия лишь принятого по умолчанию класса Diffserv).

Diffserv может сокращать задержки лишь для малой части трафика в узком месте канала. Как уже сказано, этот метод влияет лишь на часть приложений, которым нужны малые задержки, работающих одновременно на сайте (например, дома, в небольшом офисе или на мобильном устройстве). L4S, напротив, работает для всего трафика и не вносит издержек управления (правила или соглашения для трафика), связанных с предпочтением для отдельных пакетов по отношению к другим. Это даёт L4S больше шансов на сквозное внедрение.

В частности, если сеть не доверяет конечным системам в части приоритизации пакетов, она самостоятельно задаёт для пакетов класс Diffserv. Однако доступные в таких сетях методы, такие как проверка идентификаторов потоков или более глубокий анализ сигнатур приложений, не всегда совмещаются с шифрованием на уровне выше IP [RFC8404]. В таких случаях пользователям приходится выбирать между конфиденциальностью и качеством обслуживания (Quality of Service или QoS).

Как и в Diffserv, идентификатор L4S размещается в заголовке IP. Но, в отличие от Diffserv, идентификатор L4S не указывает желание или необходимость некого уровня обслуживания. Скорее, этот метод обещает некое поведение (расширяемые отклики на перегрузку), которое сеть может при необходимости проверить объективно. Это связано с тем, что малые задержки зависят от коллективного поведения хостов, а приоритизация пропускной способности – от сети.

Современные механизмы AQM

Механизмы AQM для классического трафика, такие как PIE и FQ-CoDel, значительно снижают задержку в очередях по сравнению с работой без AQM. L4S дополняет эти AQM и ему не следует препятствовать как можно более широкому развёртыванию этих механизмов. Тем не менее, AQM сами по себе не могут существенно сократить задержку в очередях без значительного снижения уровня использования канала, поскольку корнем проблемы является хост, где классические методы контроля перегрузок вносят большие пилообразные вариации скорости. L4S разрешает этот конфликт между задержкой и загрузкой канала, позволяя хосту минимизировать амплитуду зубьев пилы. Classic AQM с одной очередью недостаточно, чтобы хосты могли использовать меньшую амплитуду пилы, по двум причинам: i) сокращение не будет снижать задержку в AQM, разработанном для большей амплитуды классической пилы, поскольку очередь в каждый момент может иметь лишь один размер и ii) сокращение амплитуды предполагает повышение частоты зубьев, поэтому потоки L4S будут вызывать в Classic AQM частую маркировку ECN, которая будет выглядеть как очень значительная перегрузка классических потоков и в результате значительно снижать их скорость ().

Очереди и маркировка по потокам

Подходя на уровне потоков, такие как FQ-CoDel и Approx Fair CoDel [AFCD], не совместимы с L4S. Однако очереди на уровне потока самой по себе недостаточно, она лишь изолирует один поток от других, но не от себя. В реализации на уровне потоков требуется добавлять расширяемый контроль перегрузок, что уже сделано в Linux FQ-CoDel (см. параграф 5.2.7 в [RFC8290] и [FQ_CoDel_Thresh]). Без такого простого изменения AQM на уровне потоков, такие как FQ-CoDel, не способны поддерживать приложения которым нужны сразу высокая пропускная способность и малая задержка, например, основанное на видео управление удалёнными процедурами или интерактивное видео на основе облака¹¹.

Хотя методы, работающие на уровне потока, не совместимы с L4S, важно иметь альтернативу DualQ, поскольку обработка сквозных потоков (L4) в сети (L3 и L2) препятствует некоторым сквозным функциям.

1. Варианты L4S на уровне потоков, подобные FQ-CoDel, не совместимы с полным сквозным шифрованием идентификаторов транспортного уровня для приватности и конфиденциальности (например, IPsec или шифрованные туннели VPN в отличие от DTLS через UDP), поскольку им нужно заглядывать в пакеты для получения идентификаторов сквозных транспортных потоков.
   В отличие от этого DualQ L4S не требует заглядывать в пакет глубже уровня IP. Пока операторы применяют подход DualQ, пользователи получают очень малые задержки при сквозном шифрованием [RFC8404].
2. При использовании L4S на уровне потоков сеть берет на себя контроль относительной скорости каждого прикладного потока. Некоторые видят в этом преимущество, поскольку сеть не позволяет отдельному потоку работать быстрей других, другие считают неотъемлемым свойством Internet возможность каждого потока контролировать свою скорость, принимая во внимание другие потоки через сигналы перегрузки. Последние считают, что это позволяет развивать приложения, заинтересованные в скорости, например, i) видеопотоки с переменной скоростью, которая выделяется примерно поровну для каждого вместо принудительного постоянного значения, или ii) сквозная «сборка мусора» [RFC6817] с использованием меньшей (чем поровну) пропускной способности [LEDBAT_AQM].
   Архитектура L4S не требует от IETF предпочтения одного подхода перед другими, поскольку поддерживает оба, позволяя «рынку» принять решение. Тем не менее, в духе принципа «делать что-то одно и делать это хорошо» [McIlroy78] вариант DualQ обеспечивает малые задержки, не предрешая вопрос управления скоростью потоков, которое при желании может быть добавлено отдельно. В отличие от планирования, «регулировщик» (policer) будет разрешать приложению контролировать скорость до определённого момента, но сеть все равно может установить точку вмешательства для предотвращения захвата ресурсов отдельным потоком.

ABE

L4S является не альтернативой, а дополнением к ABE (Alternative Back-off ECN), обеспечивающим меньшую задержку в очереди. ABE [RFC8511] меняет поведения хоста при откликах на маркеры ECN для более полного использования канала связи и обеспечения потокам ECN большей пропускной способности. ABE использует ECT(0) и предполагает, в сети одинаковую трактовку ECN и отбрасывания, используя меньшую задержку в очередях, которую могут обеспечить методы AQM. Однако, как отмечено выше, AQM все равно не могут существенно сократить задержки без потери загрузки канала (для не связанных с ABE потоков).

BBR

BBR¹² [BBR-CC] контролирует сквозную задержку в очередях без какой-либо специальной логики в сети (такой как AQM) и поэтому может работать практически на любом пути. BBR сохраняет достаточно малую задержку в очередях, но иногда не столь малую, как в современных AQM, таких как PIE или FQ-CoDel, и уж точно не такую малую, как при использовании L4S. Задержка не остаётся малой постоянно из-за регулярных всплесков при зондировании пропускной способности и энергичной фазы запуска потока.

L4S дополняет BBR. В BBRv2 может применяться L4S ECN (при доступности) и расширяемый контроль перегрузок L4S в ответ на сигналы ECN из точек пути [BBRv2]. Сигналы L4S ECN дополняют основанные на задержке аспекты контроля перегрузки BBR явной индикацией, которую хосты могут использовать для схождения на беспристрастной скорости и сохранения задержки ниже установленной сетью цели. Без L4S ECN оба эти аспекта требуется предполагать или оценивать.

6. Применимость

6.1. Приложения

Транспортный уровень, решающий текущие проблемы с задержками, обеспечит новые возможности для услуг, продукции и приложений. Благодаря L4S указанные ниже имеющиеся приложения будут значительно лучше работать под нагрузкой:

• игры, включая облачные;

• VoIP;

• видеоконференции;

• просмотр web-страниц;

• (адаптивные) видео-потоки;

• мгновенные сообщения.

Значительное сокращение задержек позволит перенести в облако некоторые функции интерактивных приложений, включая:

• облачные интерактивные видео-приложения;

• виртуальная и добавленная реальность на основе облака.

Два упомянутых приложения были успешно продемонстрированы с L4S при работе по каналу доступа 40 Мбит/с загруженному множеством чувствительных к задержкам приложений из приведённого выше списка работающих одновременно через одну очередь в узком месте [L4Sdemo16] [L4Sdemo16-Video]. В первом случае видео-панораму футбольного стадиона можно было поворачивать и сжимать так, что прокси в облаке мог на лету генерировать субокно видео потока матча под управлением движениями пальцев со стороны каждого пользователя. Во втором гарнитура виртуальной реальности отображала картинку с 360-градусной камеры в гоночном автомобиле. Отображаемое поле определялось поворотом головы пользователя и извлекалось из облачного прокси. В обоих случаях при базовой сквозной задержке в 7 мсек дополнительная задержка в очереди (около 1 мсек) была столь мала, что изображение казалось созданным локально.

Управление пальцами или поворотом головы при просмотре круговой панорамы очень чувствительно к задержкам (значительно сильнее, чем VoIP), поскольку человеческий глаз способен замечать очень малую задержку (порядка 1 мсек) при отставании изображения от действия (движение пальцев или поворот головы), воспринимаемого вестибулярным аппаратом внутреннего уха. При использования вариант AQM изображение заметно отставало.

Без малой задержки в очереди, обеспеченной L4S, облачным приложениям, подобным этим, потребовалась бы гораздо большая пропускная способность сети доступа (выгрузка из облака полной панорамы) и дополнительная локальная обработка, которая повысила бы энергопотребление и массу устройств отображения в шлеме. При выполнении всей интерактивной обработки в облаке передавать нужно лишь данные, отображаемые конечному пользователю.

Другие высокоскоростные приложения с малыми задержками, такие как интерактивное удалённое присутствие и удалённое управления машинами и производственными процессами с использованием видео, просто не могут работать без обеспечения малой задержки в очереди. Потерю времени здесь не скомпенсировать локальной обработкой и расширением пропускной способности при доступе.

6.2. Варианты применения

Ниже приведены варианты применения L4S, рассматриваемые различными заинтересованными сторонами.

• Узкое место в какой-либо сети доступа, например, DSL, пассивная оптическая сеть (Passive Optical Network или PON), кабель DOCSIS, мобильная или спутниковая сеть, канал Wi-Fi (см. , где рассмотрены различные канальные технологии).

• Частные сети с неоднородными ЦОД без единого администрирования, позволяющего одновременно вносить изменения для отправителей, получателей и сетей, требуемые для внедрения DCTCP:

  • частные ЦОД, соединённые через распределенные сети, с раздельным администрированием внутри одной компании;

  • ЦОД, управляемые разными компаниями и соединённые в сеть с общими интересами (например, финансы);

  • ЦОД с арендаторами (облако), использующими стек выбранной операционной системы (Infrastructure as a Service или IaaS);

• Различный контроль перегрузок на уровне транспорта (или приложений):

  • эластичный контроль (TCP/SCTP);

  • приложения в реальном масштабе времени (RTP, RMCAT);

  • запрос-отклик (DNS/LDAP).

• Потребность в QoS с малой задержкой но без проверки и вмешательства со стороны уровня IP [RFC8404]:

  • мобильные и другие сети, как правило, проверяют вышележащие уровни для понимания потребностей приложений в QoS, однако с ростом потребностей в обеспечении приватности и шифрования L4S предоставляет альтернативное решение; не нужно выбирать, предпочтительный трафик в очереди, когда L4S может обеспечить благоприятную постановку в очередь для всего трафика.

• При минимизации задержки в очередях приложения с фиксированным бюджетом задержки могут взаимодействовать на больших расстояниях или по обходным путям, например, через более длинные цепочки сервисных функций [RFC7665] или маршрутизаторы для анонимизации (onion router).

• При минимизации вариаций задержки можно сократить размер компенсационных буферов (dejitter) на приёмной стороне, что должно улучшить интерактивный интерфейс.

6.3. Применимость для конкретных канальных технологий

Некоторые технологии канального уровня объединяют множество пакетов в блоки (burst), буферизуя для этого входящие пакеты. Такое агрегирование применяется в Wi-Fi, PON, кабельных модемах, тогда как проводные сети Ethernet и DSL не делают этого. Ни один отправитель (независимо от L4S) не может каким-либо способом сократить буферизацию, требуемую для агрегирования пакетов. Механизмам AQM не следует считать эти буферы частью управляемой очереди, поскольку никакие сигналы перегрузки не могут сократить размер буфера.

Некоторые канальные технологии добавляют буферизацию по иным причинам.

• Радиоканалы (сотовые и спутниковые сети, Wi-Fi) с удаленным источником являются наиболее сложным случаем. Пропускная способность такого канала может быстро изменяться на порядки, поэтому считается желательным наличие постоянной очереди для использования внезапно возросшей пропускной способности.

• В сотовых сетях дополнительные сложности связаны с буферизацией требуемой для незаметного перехода между сотами (hand-over).

L4S не может устранить необходимость этих различных форм буферизации. Однако, устраняя буферизацию для больших зубьев пила классического контроля перегрузки, L4S раскрывает более мелкие зубья для наблюдения.

До сих пор буферизация, обусловленная этими дополнительными причинами, обычно завышалась под предлогом того, что не одна из них не считалась самой большой (наиболее важной). Однако после устранения такой причины становится возможным их минимизация, например, за счёт снижения размера блоков агрегирования и интервалов планирования MAC.

Кроме того, некоторые каналы (особенно радио) более подвержены потерям при передаче. В параграфе 6.4.3 указано, реакция L4S на потери должна быть столь же резкой, как и при классическом отклике. Однако упомянутое там же исследование показало возможность существенно более эффективного восстановления потерь на канальном уровне за счёт смягчения ограничений для упорядоченности пакетов L4S.

6.4. Вопросы развёртывания

Механизмы L4S AQM, будь то DualQ [RFC9332] или FQ [RFC8290], сами являются механизмами поэтапного внедрения L4S, где трафик L4S может сосуществовать с имеющимся классическим трафиком (Reno-friendly). В параграфе 6.4.1 описано, как внедрение L4S AQM лишь на одном узле с каждой стороны канала доступа обеспечивает почти все преимущества L4S.

L4S включает как сеть, так и конечные системы и в параграфе 6.4.2 предложены некоторые типовые последовательности внедрения каждой части и разъяснено, почему внедрение лишь одной части сразу обеспечивает значительные преимущества.

В параграфах 6.4.3 и 6.4.4 описан случай обратного поэтапного внедрения, где L4S AQM не развёртывается в узком месте сети и любой поток L4S, проходящий через это место, должен учитывать конкуренцию с классическим трафиком.

6.4.1. Топология развёртывания

L4S AQM не потребуется внедрять во всей сети Internet, пока L4S не принесёт пользы кому бы то ни было. Операторы открытых сетей доступа в Internet обычно проектируют свои сети так, что узкое место почти всегда возникает на одном известном (логическом) канале. Это сокращает издержки на управление очередями.

Ситуация в многосвязных (mesh) сетях отличается и будет рассмотрена ниже. Вариант с известным узким местом в общем случае применим к доступу в Internet для всех сайтов, включая домашние сети, мелкие и средние кампусы и предприятия и даже сотовые устройства (). Кроме того, вариант с известным узким местом обычно применим к разным канальным технологиям доступа, таким как xDSL, кабельные модемы, PON, сотовые сети, прямые оптические каналы, спутниковые системы.

Поэтому всем достоинствам услуг L4S следует быть доступными при внедрении L4S AQM на входе в узкий канал. Все достоинства в восходящем направлении обычно становятся доступными при внедрении L4S AQM на входе восходящего канала. Многодомные сайты смогут полностью воспользоваться такими преимуществами после внедрения служб на всех своих каналах доступа.

                                         ______
                                        (      )
                      __          __  (          )
                     |DQ\________/DQ|( Предприятие)
                 ___ |__/        \__| (или кампус)
                (   )                   (______)
              (      )                           ___||_
+----+      (          )  __                 __ /      \
| DC |-----(    Ядро    )|DQ\_______________/DQ|| Дом  |
+----+      (          ) |__/               \__||______|
               (_____) __
                      |DQ\__/\        __ ,===.
                      |__/    \  ____/DQ||| ||Мобильное
                               \/    \__|||_||устройство
                                         | o |
                                         `---'

Рисунок . Вероятное размещение DualQ (DQ) в базовой топологии доступа.

Внедрение в mesh-топологии зависит от уровня перегрузки в ядре сети. Если перегрузки в ядре нет или производительность достаточно высока и узкими местами почти всегда являются ребра, достаточно будет внедрить L4S AQM на таких рёбрах. Например, некоторые сети ЦОД спроектированы так, что узким местом является гипервизор или сетевые контроллеры (Network Interface Controller или NIC) хостов, а другая узость возникает в коммутаторе стойки (top-of-rack), на портах, обращённых к хосту и ядру.

Затем L4S AQM потребуется там, где узким местом в доме становятся каналы Wi-Fi. L4S AQM может потребоваться в любых сохраняющихся узких местах, таких как соединения между сетями, например в некоторых точках обмена Internet, а также на входах и выходах каналов WAN между ЦОД.

6.4.2. Последовательность внедрения

Чтобы отдельный поток L4S обеспечивал преимущества нужно развернуть 3 (иногда 2) элемента: i) контроль перегрузки у отправителя, ii) AQM в узком месте и iii) обновление старого транспорта (а именно, TCP) в части обратной связи от получателя. С этими же проблемами столкнулось внедрение ECN [RFC8170], откуда были извлечены уроки.

Во-первых, при развёртывании L4S используется наличие DCTCP уже на многих хостах Internet (например, клиенты и серверы Windows, FreeBSD, Linux). Поэтому L4S AQM можно внедрить в узком месте сети, чтобы сразу же получить рабочее развёртывание всех частей L4S для тестирования при условии смены кода ECT(0) на ECT(1). В DCTCP нужно устранить несколько проблем безопасности для базового применения в общедоступной сети Internet (см. параграф 4.3 спецификации L4S ECN [RFC9331]), но протокол DCTCP по умолчанию не включён и эти вопросы можно решать в рамках контролируемых внедрений или экспериментов.

Во-вторых, повышение производительности с помощью L4S столь значительно, что позволяет создавать новые интерактивные службы и продукцию, которое до этого не были возможны. Компаниям гораздо проще начать работы по внедрению, если имеется бюджет на пробные версии продукции. Если бы происходило лишь постепенное повышение производительности (как в Classic ECN), расходы на внедрение оправдать, скорей всего, было бы гораздо сложнее.

В-третьих, идентификатор L4S выбран так, что сетевые операторы могут сначала включить L4S лишь для некоторых клиентов или отдельных приложений. Выбор идентификатора тщательно продуман, чтобы не поставить под угрозу будущее развитие в направлении внедрения L4S как всеобщего сервиса Internet. Это обусловлено тем, что идентификатор L4S задан не только как сквозное поле ECN, но и может сочетаться с другими заголовками пакетов или статусом клиента или его канала доступа (см. параграф 5.4 в [RFC9331]). Операторы могли бы сделать это даже без одобрения IETF, однако IETF лучше указать, что локальный идентификатор должен применяться в сочетании с идентификатором IETF – ECT(1). Если оператор выбрал подход лишь с локальным применением, он просто будет удалять дополнительное правило, чтобы сервис работал через Internet (промежуточные устройства, партнёров и т. п.).

 

	Серверы или прокси	Канал доступа	Клиенты
0	DCTCP (имеющийся)		DCTCP (имеющийся)
1		Добавление L4S AQM в нисходящем канале
	Работа в нисходящем направлении по внедрению в контролируемой среде (пробному)
2	Обновление DCTCP до TCP Prague		Замена откликов DCTCP на AccECN
	Полностью работающее нисходящее направление
3		Добавление L4S AQM в восходящем канале	Обновление DCTCP до TCP Prague
	Полностью работающие нисходящее и восходящее направление

 

Рисунок . Пример последовательности развёртывания L4S.

На рисунке 3 приведён пример последовательности внедрения элементов L4S при наличии DCTCP с обеих сторон.

1. DCTCP не применяется в общедоступной сети Internet, поэтому здесь подчёркнуто, что поток DCTCP полностью локализован в контролируемой среде развёртывания. Внутри этой среды сразу после внедрения L4S AQM пробный поток DCTCP получает выгоду даже без дополнительного внедрения. В этом примере внедрение происходит сначала в нисходящем направлении, но в других ситуациях внедрение может начинаться с восходящего направления. Если ранее для нисходящего доступа не был развернут механизм AQM, L4S AQM существенно улучшает классические услуги (а также добавляет услуги L4S). Если AQM уже был внедрён, классические услуги не изменяются (а L4S добавит улучшения).

2. Здесь TCP Prague [PRAGUE-CC] представляет вариант DCTCP, разработанный для применения в рабочей среде Internet (т. е. он соответствует всем требованиям раздела 4 в спецификации L4S ECN [RFC9331], что означает возможность использования в общедоступной сети Internet). Если приложение в основном однонаправленное, TCP Prague на передающей стороне обеспечит все требуемые преимущества при условии поддержки принимающей стороной откликов Accurate ECN (AccECN) [ACCECN].

   Для TCP нужны отклики AccECN от другой стороны, но это базовые отклики ECN, внедрение которых уже запланировано для других целей, таких как DCTCP и BBR. Внедрение на обеих сторонах может происходить в любом порядке, поскольку в TCP контроль перегрузок L4S включается лишь при указании поддержки AccECN в процессе начального согласования. Таким образом, внедрение TCP Prague на сервере позволяет пробному внедрению L4S перейти в рабочее состояние для одного направления, независимо от развёртывания AccECN на другой стороне. Дополнительным мотивом для этого этапа может быть большая производительность TCP Prague по сравнению с DCTCP (см. Приложение A.2 к спецификации L4S ECN [RFC9331]).

   В отличие от TCP, отклики QUIC ECN [RFC9000] с самого начала поддерживают L4S. Поэтому для транспорта QUIC внедрение на этом этапе контроля перегрузок Prague является простым и достаточным.

   Если при использовании транспорта QUIC прокси размещается на пути между серверами-источниками и узким местом доступа для множества клиентов, обновление этого прокси с внедрением расширяемого контроля перегрузок обеспечит преимущества L4S в нисходящем направлении сразу для всех таких клиентов независимо от обновления серверов источников. Если же прокси не обновить, клиенты не смогут воспользоваться преимуществами L4S в нисходящем направлении даже при обновлении любого из серверов-источников для поддержки L4S.

   В случае TCP обновление прокси для поддержки TCP Prague обеспечит преимущества L4S в нисходящем направлении всем клиентам, поддерживающим AccECN (независимо от поддержки ими L4S). В восходящем направлении прокси будет поддерживать AccECN как получатель и любой клиент, внедривший у себя L4S получит преимущества в восходящем направлении независимо от поддержки AccECN серверами за прокси.

3. Этот этап состоит из 2 шагов для включения L4S в восходящем направлении. L4S AQM или TCP Prague можно развернуть в любом порядке, как уже описано. Для мотивирования первого шага отложенная выгода от включения новых услуг после второго шага должна превышать инвестиционные риски первого шага. Как уже отмечено, потенциал новых интерактивных услуг обеспечивает такую мотивацию. L4S AQM также значительно улучшает классические услуги в восходящем направлении, если механизм AQM не был внедрён ранее.

Отметим, что последовательность внедрения может быть иной. Например, сначала можно обновить восходящее направление, использовать сквозной протокол, отличный от TCP (например, QUIC и RTP). Устройства, подобные 3GPP, могут потребовать внедрения L4S в пользовательском оборудовании 5G и т. д.

6.4.3. Поток L4S с узким местом без ECN

Если L4S включён между двумя хостами, отправитель L4S должен безопасно сосуществовать с Reno при реакции на какое-либо отбрасывание пакета (см. параграф 4.3 в спецификации L4S ECN [RFC9331]). К сожалению, помимо защиты классического трафика это ухудшает работу сервиса L4S при возникновении какой-либо потели, даже если её причиной не является перегрузка в узком месте. Это может быть, например,

• потеря в другом узком месте пути (например, в результате всплеска пакетов в мелких очередях);

• ошибки при передаче (например, электрические помехи);

• правила управления скоростью.

Для решения этой проблемы разрабатывается 3 взаимодополняющих подхода, но они ещё в стадии исследования.

• В контроле перегрузок Prague игнорируются некоторые потери, связь которых с перегрузкой представляется маловероятной (применяются некоторые идеи из BBR [BBR-CC] в части изолированных потерь). Это позволяет маскировать любые из указанных выше потерь, сосуществуя с контролем перегрузки по потерям.

• Сочетание недавнего подтверждения (Recent Acknowledgement или RACK) [RFC8985], L4S и повторов передачи на канальном уровне без изменения порядка может исправлять ошибки передачи без задержки из-за блокировки в начале линии (head of line), обычно связанной с повтором передачи на канальном уровне [UnorderedLTE] [RFC9331].

• Гибридное управление скоростью по ECN и отбрасыванию ().

Сценарии внедрения L4S, минимизирующие эти проблемы (например, через проводные сети), могут реализоваться в параллель с исследованиями в надежде на то, что успех исследований может расширить применимость L4S.

6.4.4. Поток L4S с Classic ECN в узком месте

Поддержка Classic ECN начинает реализовываться в Internet как повышение уровня (объёма) маркировки CE. Сложно понять, связано это с добавлением поддержки ECN в реализации FQ-CoDel и/или FQ-COBALT, что обычно не вызывает проблем, поскольку планирование в очередях по потокам (flow queue или FQ) по своей природе предотвращает превышение потоком «справедливой» скорости независимо от энергичности этого потока. Однако некоторые маркировки Classic ECN могут быть вызваны внедрением ECN с одной очередью. Этот случай рассматривается в параграфе 4.3 спецификации L4S ECN [RFC9331].

6.4.5. Развёртывание L4S AQM внутри туннеля

В L4S AQM поле ECN служит для сигналов о перегрузке. Поэтому, как и в Classic ECN, при размещении AQM внутри туннеля или на нижележащем уровне для корректной работы сигнализации ECN нужно соответствующее стандартам распространение поля ECN по уровням [RFC6040] [ECN-SHIM] [ECN-ENCAP].

7. Взаимодействие с IANA

Этот документ не требует действий IANA.

8. Вопросы безопасности

8.1. Ограничение скорости трафика

8.1.1. Ограничение скорости на уровне потока

В современной сети Internet провайдеры (ISP) обычно принудительно разделяют пропускную способность общих каналов, выделенных различным сайтам (например, домовладениям, организациям или мобильным пользователям, см. ), с помощью той или иной формы планировщика [RFC0970]. ISP также применяют различные методы (например, перенаправление на средства очистки) для борьбы с лавинными рассылками (flooding). Однако никогда не возникало универсальной необходимости контролировать скорость отдельных потоков приложений, Internet обычно полагается на самоограничение контроля перегрузки у отправителей для совместного использования «внутрисайтовой» пропускной способности.

При разработке L4S это сложившееся состояние было сохранено. Для предоставления услуг L4S с использованием DualQ параграф 4.2 в [RFC9332] разъясняет, как неотзывчивым потокам предоставляется не больше преимуществ, чем AQM с одной очередью, независимо от наличия перегрузки.

Если когда либо потребуется управление скоростью по потокам, его можно будет добавить, поскольку оно ортогонально разделению классического трафика и L4S. Как разъяснено в параграфе 5.2, L4S с DualQ обеспечивает малые задержки без необходимости управлять скоростью на уровне потока. Поэтому при потребности в контроле скорости по потокам можно использовать очереди по потокам (FQ) с поддержкой L4S или добавить контроль скорости потока как модульное расширение DualQ. Однако контроль скорости на уровне потока обычно не внедряется в качестве механизма защиты, поскольку активный злоумышленник может просто разделить свой трафик между разными идентификаторами потоков, если скорость каждого потока ограничена.

8.1.2. Ограничение скорости для L4S

В параграфе 5.2 разъяснено, что Diffserv различает пакеты лишь в случае, когда одним пакетам нужно более приоритетное обслуживание, чем другим, и это обычно требует управления скоростью для класса трафика с малой задержкой. Для L4S, напротив, не возникает потребности в ограничении скорости доступа к услугам L4S для защиты классического обслуживания, поскольку L4S снижает свои задержки без ущерба для задержки и скорости любого классического трафика.

На ранних этапах развёртывания (а, возможно, и всегда) некоторые сети не будут предоставлять услуг L4S. В общем случае этим сетям не нужны правила для трафика L4S. От них требуется (в соответствии со спецификациями ECN [RFC3168] и L4S ECN [RFC9331]) не менять идентификатор L4S, поскольку это нарушит сквозной контроль перегрузок. Если сеть уже рассматривает трафик ECN как Not-ECT, она может относить и трафик L4S к Not-ECT. В узком месте такой сети может возникать очередь и отбрасывание пакетов. При обнаружении отбрасывания расширяемым протоколом контроля перегрузки он должен реагировать безопасно для классического контроля перегрузки, как требует параграф 4.3 в [RFC9331]. Это ухудшит сервис L4S, чтобы он был не лучше (и не хуже) классического сервиса best efforts при наличии на пути узкого места без ECN ().

В представляющихся редкими случаях сеть с поддержкой только Classic ECN [RFC3168] в узком месте с одной очередью, может начать ограничивать трафик L4S для защиты конкурирующего с ним трафика Classic ECN (см., например, параграф 6.1.3 эксплуатационных рекомендация L4S [L4SOPS]). Однако параграф 4.3 спецификации L4S ECN [RFC9331] рекомендует отправителю адаптировать свою реакцию на перегрузку для надлежащего сосуществования с потоками Classic ECN, т. е. вернуться к самоограничению.

Некоторые операторы сетей могут ограничивать доступ к услугам L4S, предоставляя его лишь части клиентов. Их классификаторы пакетов (2 на рисунке ) могут идентифицировать клиентов но некоторым полям (например, диапазону адресов отправителей) в дополнение к классификации по полю ECN. Если соответствует лишь идентификатор ECN L4S, но не адрес отправителя (например), классификатор может направить пакеты (клиентов без доступа к L4S) в классическую очередь. Чёткое разъяснение способов использования операторами дополнительных локальных классификаторов (см. параграф 5.4 в [RFC9331]) призвано устранить любые мотивы сброса идентификаторов L4S. Тогда сквозное сохранение идентификатора L4S ECN будет более вероятным даже без поддержки сервиса на некоторых интервалах пересылки. Такие локальные соглашения будут требовать лишь простой классификации по факту регистрации, а не управляемой и зависящей от приложения проверки трафика на соответствие контракту, как принято в Diffserv.

8.2. Дружественность к задержкам

Подобно классическому сервису, L4S полагается на самоограничение скорости в ответ на перегрузку. Кроме того, L4S требует самоограничения с точки зрения задержки (скачкообразности). Есть надежда, что личной заинтересованности и руководства по динамическому поведению (особенно при запуске потока, который, возможно, придётся стандартизировать) будет достаточно для предотвращения на транспортном уровне чрезмерных всплесков (burst) трафика L4S с учётом того, что от таких всплесков больше всего пострадает задержка передающего приложения.

Поскольку служба L4S может сокращать задержку без заметного роста задержки классического трафика, не должно возникать необходимости ограничивать трафик L4S для защиты задержки классического трафика. Однако ещё предстоит выяснить, не потребуется ли ограничивать всплески для защиты другого трафика L4S. Без этого может возникнуть возможность атак для увеличения задержки сервиса L4S. Для решения этой задачи можно использовать разные механизмы, указанные ниже.

Локальная защита очереди в узком месте

Функция защиты очередей по потокам (5-tuple) [DOCSIS-Q-PROT] была разработана для очереди с малой задержкой в DOCSIS, где применяется архитектура DualQ L4S. Она защищает сервис с малой задержкой от любых потоков, создающих очереди, которые случайно или злонамеренно классифицируют себя в очередь с малой задержкой. Функция предназначена для оценки потоков исключительно по их вкладу в очередь, а не по скорости потока. Если для общей очереди с малой задержкой возникает риск превышения порога, функция перенаправляет достаточное число пакетов с высокой оценкой в классическую очередь, чтобы сохранить малую задержку.

Очистка распределенного трафика

Вместо локального ограничения в каждом узком месте можно решать проблему реактивно, например, «наказывая» любые развёртывания новых вредоносных программ со всплесками трафика, аналогично перенаправлению трафика от источников лавинных атак через средства очистки.

Локальное планирование по потокам в узком месте

Планированию по потокам следует по своей природе изолировать потоки без всплесков (non-bursty) от потоков со всплесками (пиками) трафика (сравнение ограничения и планирования на уровне потоков дано в параграфе 5.2).

Защита очереди подсети распределенного доступа

Защита очередей по потокам может быть организована для структуры очередей, распределенной по подсети, использующей управляющие сообщения нижележащих уровней (см. параграф 2.1.4 в [QDyn]). Например, в сети радиодоступа пользовательское оборудование уже передаёт регулярные отчёты о состоянии буфера контроллеру сети, который может использовать эти сведения для удалённого ограничения отдельных потоков.

Раскрытие распределенной перегрузки входным ограничителям

Архитектура раскрытия перегрузки (Congestion Exposure или ConEx) [RFC7713] использует аудит на выходе для побуждения отправителей правдиво сообщать о перегрузке пути по основному каналу, где это может использоваться входными ограничителями. Возможен и сквозной вариант этой архитектуры.

Распределенное кондиционирование трафика на границе домена

Может быть предпочтительной архитектура, подобная Diffserv [RFC2475], где трафик заранее (проактивно) кондиционируется на входе в домен вместо реактивного ограничения при возникновении очереди в узком месте после объединения с другим трафиком.

Защита очередей распределенного ядра сети

Функция ограничения (policing) может быть распределена между механизмами на уровне потоков на входе в сеть, которые характеризуют склонность к пикам (burstiness) каждого потока сигналом, передаваемым с трафиком, и механизмами на уровне классов в узком месте, которые воздействуют на эти сигналы, если постановка в очередь действительно происходит после схождения трафика. Это чем-то похоже на [Nadas20], что, в свою очередь, похоже на идею беспристрастной очереди без учёта состояний.

Ни один из этих вариантов защиты очередей не считается неотъемлемой частью архитектуры L4S, которая работает без всех этих вариантов при отсутствии атак (примерно так же, как Internet обычно работает без ограничения скорости по потокам). Действительно, даже при внедрении правил для задержки при нормальных условиях эти механизмы не вмешивались бы и операторы могли бы отключить их. Частью экспериментов с L4S будет выяснение потребности в такой функции и выбор наиболее подходящих механизмов.

8.3. Взаимодействие ограничения скорости и L4S

Как отмечено в параграфе 5.2, L4S следует исключать потребность в классах Diffserv с малой задержкой. Однако классы Diffserv, дающие некоторым приложениям или пользователям преимущество в выделении пропускной способности, останутся применимыми в определённых ситуациях (например, в корпоративных сетях). В рамках таких классов Diffserv зачастую может применяться L4S для обеспечения трафику малой задержки и малых потерь. В рамках таких классов Diffserv доступная пользователю или приложению пропускная способность часто ограничивается регулятором скорости. Аналогично, в принятом по умолчанию классе Diffserv иногда применяются регуляторы скорости для разделения общей пропускной способности.

Классические ограничители скорости отбрасывают все пакеты, превышающие установленный предел скорости, обычно разрешая всплески (есть варианты, где ограничитель перемаркировывает несоответствующий трафик кодом Diffserv, подходящим для отбрасывания, поэтому пакеты при перегрузке могут быть отброшены где угодно). Когда трафик L4S сталкивается с таким регулятором скорости, он испытывает потери пакетов и источник будет возвращаться к классическому контроля перегрузки, теряя преимущества L4S (). Поэтому в сетях где уже имеются регуляторы скорости и планируется внедрение L4S, предпочтительно перепроектировать ограничители скорости, чтобы они стали более дружественны к сервисуL4S. Совместимое с L4S ограничение скорости в настоящее время является областью исследований (отметим, что это отличается от управления задержкой). Можно было бы установить порог начала маркировки ECN чуть ниже порога ограничения скорости или чуть ниже величины пиков, при которой начинается отбрасывание. Например, при 3-цветной маркировке в двумя скоростями [RFC2698] или пороге PCN и маркере избыточной скорости [RFC5670] можно применять маркировку ECN при низкой скорости и отбрасывание – при высокой. Или можно было добавить к имеющемуся ограничителю скорости управление «скоростью перегрузки», например, с использованием «локального» варианта агрегатного регулятора ConEx [CONG-POLICING]. Может быть удастся разработать элементы расширяемого контроля перегрузок, позволяющие менее катастрофически реагировать на потери, которым не предшествовал интервал роста задержки.

Устройству совместимых с L4S регуляторов скорости должен быть посвящен отдельный специальный документ. Обсуждение взаимодействия L4S и Diffserv приведено в [L4S-DIFFSERV].

8.4. Целостность ECN

Разработаны разные варианты защиты целостности в контуре откликов на перегрузку (по потерям, Classic ECN, L4S ECN) от некорректного поведения получателей, отправителей и сети. Краткое описание таких методов в рассмотрением применимости, доводов за и против дано в Приложении C.1 к спецификации L4S ECN [RFC9331].

8.5. Вопросы приватности

Как отмечалось в параграфе 5.2, архитектура L4S не исключает подходов с проверкой сквозных идентификаторов транспортного уровня. Например, поддержка L4S добавлена в FQ-CoDel, где происходит классификация в сети по идентификатору потока приложения. Однако основным нововведением L4S является модель DualQ AQM, не требующая заглядывать внутрь пакета дальше внешнего заголовка IP, поскольку идентификатор L4S помещается в поле IP-ECN.

Таким образом, архитектура L4S обеспечивает очень малую задержку в очереди без необходимости просмотра информации выше уровня IP. Это означает, что пользователям, желающим шифровать идентификаторы потоков приложений, например в туннелях IPsec или иных туннелях VPN с шифрованием, не придётся жертвовать малой задержкой [RFC8404].

Поскольку L4S может обеспечить малые задержки для широкого класса приложений, которе решат использовать эту службу, не возникает потребности тем или иным способом различать отдельные приложения или классы при прохождении через сеть. Это в значительной степени исключает возможность сопоставить требования к задержке трафика с другими идентифицирующими признаками [RFC6973]. Возможно, некоторые типы трафика предпочтут не применять L4S, но грубая бинарная классификация трафика мало что даёт для нарушения приватности.

9. Литература

[ACCECN] Briscoe, B., Kühlewind, M., and R. Scheffenegger, “More Accurate ECN Feedback in TCP”, Work in Progress, Internet-Draft, draft-ietf-tcpm-accurate-ecn-22, 9 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-22>.

[AFCD] Xue, L., Kumar, S., Cui, C., Kondikoppa, P., Chiu, C-H., and S-J. Park, “Towards fair and low latency next generation high speed networks: AFCD queuing”, Journal of Network and Computer Applications, Volume 70, pp. 183-193, DOI 10.1016/j.jnca.2016.03.021, July 2016, <https://doi.org/10.1016/j.jnca.2016.03.021>.

[BBR-CC] Cardwell, N., Cheng, Y., Hassas Yeganeh, S., Swett, I., and V. Jacobson, “BBR Congestion Control”, Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.

[BBRv2] “TCP BBR v2 Alpha/Preview Release”, commit 17700ca, June 2022, <https://github.com/google/bbr>.

[BDPdata] Briscoe, B., “PI2 Parameters”, TR-BB-2021-001, arXiv:2107.01003 [cs.NI], DOI 10.48550/arXiv.2107.01003, October 2021, <https://arxiv.org/abs/2107.01003>.

[BufferSize] Appenzeller, G., Keslassy, I., and N. McKeown, “Sizing Router Buffers”, SIGCOMM ’04: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 281-292, DOI 10.1145/1015467.1015499, October 2004, <https://doi.org/10.1145/1015467.1015499>.

[COBALT] Palmei, J., Gupta, S., Imputato, P., Morton, J., Tahiliani, M. P., Avallone, S., and D. Täht, “Design and Evaluation of COBALT Queue Discipline”, IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), DOI 10.1109/LANMAN.2019.8847054, July 2019, <https://ieeexplore.ieee.org/abstract/document/8847054>.

[CODEL-APPROX-FAIR] Morton, J. and P. Heist, “Controlled Delay Approximate Fairness AQM”, Work in Progress, Internet-Draft, draft-morton-tsvwg-codel-approx-fair-01, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-morton-tsvwg-codel-approx-fair-01>.

[CONG-POLICING] Briscoe, B., “Network Performance Isolation using Congestion Policing”, Work in Progress, Internet-Draft, draft-briscoe-conex-policing-01, 14 February 2014, <https://datatracker.ietf.org/doc/html/draft-briscoe-conex-policing-01>.

[CTCP] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, “Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks”, Work in Progress, Internet-Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, <https://datatracker.ietf.org/doc/html/draft-sridharan-tcpm-ctcp-02>.

[DOCSIS-Q-PROT] Briscoe, B., Ed. and G. White, “The DOCSIS® Queue Protection Algorithm to Preserve Low Latency”, Work in Progress, Internet-Draft, draft-briscoe-docsis-q-protection-06, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06>.

[DOCSIS3.1] CableLabs, “MAC and Upper Layer Protocols Interface (MULPI) Specification, CM-SP-MULPIv3.1”, Data-Over-Cable Service Interface Specifications DOCSIS 3.1 Version i17 or later, 21 January 2019, <https://specification-search.cablelabs.com/CM-SP-MULPIv3.1>.

[DOCSIS3AQM] White, G., “Active Queue Management Algorithms for DOCSIS 3.0: A Simulation Study of CoDel, SFQ-CoDel and PIE in DOCSIS 3.0 Networks”, CableLabs Technical Report, April 2013, <https://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf>.

[DualPI2Linux] Albisser, O., De Schepper, K., Briscoe, B., Tilmans, O., and H. Steen, “DUALPI2 – Low Latency, Low Loss and Scalable (L4S) AQM”, Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-DUALPI2-AQM>.

[Dukkipati06] Dukkipati, N. and N. McKeown, “Why Flow-Completion Time is the Right Metric for Congestion Control”, ACM SIGCOMM Computer Communication Review, Volume 36, Issue 1, pp. 59-62, DOI 10.1145/1111322.1111336, January 2006, <https://dl.acm.org/doi/10.1145/1111322.1111336>.

[ECN-ENCAP] Briscoe, B. and J. Kaippallimalil, “Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-encap-guidelines-17, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>.

[ECN-SCTP] Stewart, R., Tuexen, M., and X. Dong, “ECN for Stream Control Transmission Protocol (SCTP)”, Work in Progress, Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January 2014, <https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctpecn-05>.

[ECN-SHIM] Briscoe, B., “Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update-shim-15, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-15>.

[FQ_CoDel_Thresh] “fq_codel: generalise ce_threshold marking for subset of traffic”, commit dfcb63ce1de6b10b, October 2021, <https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=dfcb63ce1de6b10b>.

[Hohlfeld14] Hohlfeld, O., Pujol, E., Ciucu, F., Feldmann, A., and P. Barford, “A QoE Perspective on Sizing Network Buffers”, IMC ’14: Proceedings of the 2014 Conference on Internet Measurement, pp. 333-346, DOI 10.1145/2663716.2663730, November 2014, <https://doi.acm.org/10.1145/2663716.2663730>.

[L4S-DIFFSERV] Briscoe, B., “Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services”, Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-diffserv-02, 4 November 2018, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>.

[L4Sdemo16] Bondarenko, O., De Schepper, K., Tsang, I., Briscoe, B., Petlund, A., and C. Griwodz, “Ultra-Low Delay for All: Live Experience, Live Analysis”, Proceedings of the 7th International Conference on Multimedia Systems, Article No. 33, pp. 1-4, DOI 10.1145/2910017.2910633, May 2016, <https://dl.acm.org/citation.cfm?doid=2910017.2910633>.

[L4Sdemo16-Video] “Videos used in IETF dispatch WG ‘Ultra-Low Queuing Delay for All Apps’ slot”, <https://riteproject.eu/dctth/#1511dispatchwg>.

[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, “Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All”, TR-BB-2022-001, arXiv:2209.01078 [cs.NI], DOI 10.48550/arXiv.2209.01078, September 2022, <https://arxiv.org/abs/2209.01078>.

[L4SOPS] White, G., Ed., “Operational Guidance for Deployment of L4S in the Internet”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-l4sops-03, 28 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops-03>.

[LEDBAT_AQM] Al-Saadi, R., Armitage, G., and J. But, “Characterising LEDBAT Performance Through Bottlenecks Using PIE, FQ-CoDel and FQ-PIE Active Queue Management”, IEEE 42nd Conference on Local Computer Networks (LCN), DOI 10.1109/LCN.2017.22, October 2017, <https://ieeexplore.ieee.org/document/8109367>.

[lowat] Meenan, P., “Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowat”, Cloudflare Blog, October 2018, <https://blog.cloudflare.com/http-2-prioritization-with-nginx/>.

[McIlroy78] McIlroy, M.D., Pinson, E. N., and B. A. Tague, “UNIX Time-Sharing System: Foreword”, The Bell System Technical Journal 57: 6, pp. 1899-1904, DOI 10.1002/j.1538-7305.1978.tb02135.x, July 1978, <https://archive.org/details/bstj57-6-1899>.

[Nadas20] Nádas, S., Gombos, G., Fejes, F., and S. Laki, “A Congestion Control Independent L4S Scheduler”, ANRW ’20: Proceedings of the Applied Networking Research Workshop, pp. 45-51, DOI 10.1145/3404868.3406669, July 2020, <https://doi.org/10.1145/3404868.3406669>.

[NASA04] Bailey, R., Trey Arthur III, J., and S. Williams, “Latency Requirements for Head-Worn Display S/EVS Applications”, Proceedings of SPIE 5424, DOI 10.1117/12.554462, April 2004, <https://ntrs.nasa.gov/api/citations/20120009198/downloads/20120009198.pdf?attachment=true>.

[NQB-PHB] White, G. and T. Fossati, “A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-nqb-15, 11 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-15>.

[PRAGUE-CC] De Schepper, K., Tilmans, O., and B. Briscoe, Ed., “Prague Congestion Control”, Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-01, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01>.

[PragueLinux] Briscoe, B., De Schepper, K., Albisser, O., Misund, J., Tilmans, O., Kühlewind, M., and A.S. Ahmed, “Implementing the ‘TCP Prague’ Requirements for Low Latency Low Loss Scalable Throughput (L4S)”, Proceedings Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>.

[QDyn] Briscoe, B., “Rapid Signalling of Queue Dynamics”, TR-BB-2017-001, arXiv:1904.07044 [cs.NI], DOI 10.48550/arXiv.1904.07044, April 2019, <https://arxiv.org/abs/1904.07044>.

[Raaen14] Raaen, K. and T-M. Grønli, “Latency Thresholds for Usability in Games: A Survey”, Norsk IKT-konferanse for forskning og utdanning (Norwegian ICT conference for research and education), 2014, <http://ojs.bibsys.no/index.php/NIK/article/view/9/6>.

[Rajiullah15] Rajiullah, M., “Towards a Low Latency Internet: Understanding and Solutions”, Dissertation, Karlstad University, 2015, <https://www.diva-portal.org/smash/get/diva2:846109/FULLTEXT01.pdf>.

[RELENTLESS] Mathis, M., “Relentless Congestion Control”, Work in Progress, Internet-Draft, draft-mathis-iccrg-relentless-tcp-00, 4 March 2009, <https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00>.

[RFC0970] Nagle, J., “On Packet Switches With Infinite Storage”, RFC 970, DOI 10.17487/RFC0970, December 1985, <https://www.rfc-editor.org/info/rfc970>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC2698] Heinanen, J. and R. Guerin, “A Two Rate Three Color Marker”, RFC 2698, DOI 10.17487/RFC2698, September 1999, <https://www.rfc-editor.org/info/rfc2698>.

[RFC2884] Hadi Salim, J. and U. Ahmed, “Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks”, RFC 2884, DOI 10.17487/RFC2884, July 2000, <https://www.rfc-editor.org/info/rfc2884>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, “An Expedited Forwarding PHB (Per-Hop Behavior)”, RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.

[RFC3540] Spring, N., Wetherall, D., and D. Ely, “Robust Explicit Congestion Notification (ECN) Signaling with Nonces”, RFC 3540, DOI 10.17487/RFC3540, June 2003, <https://www.rfc-editor.org/info/rfc3540>.

[RFC3649] Floyd, S., “HighSpeed TCP for Large Congestion Windows”, RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP)”, RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.

[RFC4774] Floyd, S., “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field”, BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.

[RFC4960] Stewart, R., Ed., “Stream Control Transmission Protocol”, RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5033] Floyd, S. and M. Allman, “Specifying New Congestion Control Algorithms”, BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.

[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.

[RFC5670] Eardley, P., Ed., “Metering and Marking Behaviour of PCN-Nodes”, RFC 5670, DOI 10.17487/RFC5670, November 2009, <https://www.rfc-editor.org/info/rfc5670>.

[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>.

[RFC6040] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O’Hanlon, P., and K. Carlberg, “Explicit Congestion Notification (ECN) for RTP over UDP”, RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, “Low Extra Delay Background Transport (LEDBAT)”, RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, “Privacy Considerations for Internet Protocols”, RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, “Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback”, RFC 7560, DOI 10.17487/RFC7560, August 2015, <https://www.rfc-editor.org/info/rfc7560>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., “IETF Recommendations Regarding Active Queue Management”, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., “Service Function Chaining (SFC) Architecture”, RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.

[RFC7713] Mathis, M. and B. Briscoe, “Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements”, RFC 7713, DOI 10.17487/RFC7713, December 2015, <https://www.rfc-editor.org/info/rfc7713>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, “Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem”, RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8034] White, G. and R. Pan, “Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems”, RFC 8034, DOI 10.17487/RFC8034, February 2017, <https://www.rfc-editor.org/info/rfc8034>.

[RFC8170] Thaler, D., Ed., “Planning for Protocol Adoption and Subsequent Transitions”, RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, “Data Center TCP (DCTCP): TCP Congestion Control for Data Centers”, RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, “The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm”, RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.

[RFC8298] Johansson, I. and Z. Sarker, “Self-Clocked Rate Adaptation for Multimedia”, RFC 8298, DOI 10.17487/RFC8298, December 2017, <https://www.rfc-editor.org/info/rfc8298>.

[RFC8311] Black, D., “Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation”, RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, “CUBIC for Fast Long-Distance Networks”, RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., “Effects of Pervasive Encryption on Operators”, RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.

[RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, “TCP Alternative Backoff with ECN (ABE)”, RFC 8511, DOI 10.17487/RFC8511, December 2018, <https://www.rfc-editor.org/info/rfc8511>.

[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, “RTP Control Protocol (RTCP) Feedback for Congestion Control”, RFC 8888, DOI 10.17487/RFC8888, January 2021, <https://www.rfc-editor.org/info/rfc8888>.

[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, “The RACK-TLP Loss Detection Algorithm for TCP”, RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[RFC9331] De Schepper, K. and B. Briscoe, Ed., “The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)”, RFC 9331, DOI 10.17487/RFC9331, January 2023, <https://www.rfc-editor.org/info/rfc9331>.

[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, “Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)”, RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.

[SCReAM-L4S] “SCReAM”, commit fda6c53, June 2022, <https://github.com/EricssonResearch/scream>.

[TCP-CA] Jacobson, V. and M. Karels, “Congestion Avoidance and Control”, Laurence Berkeley Labs Technical Report , November 1988, <https://ee.lbl.gov/papers/congavoid.pdf>.

[UnorderedLTE] Austrheim, M., “Implementing immediate forwarding for 4G in a network simulator”, Master’s Thesis, University of Oslo, 2018.

Благодарности

Спасибо Richard Scheffenegger, Wes Eddy, Karen Nielsen, David Black, Jake Holland, Vidhi Goel, Ermin Sakic, Praveen Balasubramanian, Gorry Fairhurst, Mirja Kuehlewind, Philip Eardley, Neal Cardwell, Pete Heist, Martin Duke за их рецензии и комментарии. Спасибо также рецензентам от направления Marco Tiloca, Lars Eggert, Roman Danyliw, Éric Vyncke.

Работа Bob Briscoe и Koen De Schepper частично финансировалась Европейской комиссией в рамках программы Seventh Framework через проект Reducing Internet Transport Latency (RITE) (ICT-317700). Работа Koen De Schepper частично финансировалась также в рамках проектов 5Growth и DAEMON EU H2020, работа Bob Briscoe частично финансировалась также Research Council of Norway по проекту TimeIn, CableLabs и Comcast Innovation Fund. Выраженные здесь мнения принадлежат исключительно авторам.

Адреса авторов

Bob Briscoe (editor)

Independent

United Kingdom

Email: ietf@bobbriscoe.net

URI: https://bobbriscoe.net/

 

Koen De Schepper

Nokia Bell Labs

Antwerp

Belgium

Email: koen.de_schepper@nokia.com

URI: https://www.bell-labs.com/about/researcher-profiles/koende_schepper/

 

Marcelo Bagnulo

Universidad Carlos III de Madrid

Av. Universidad 30

28911 Madrid

Spain

Phone: 34 91 6249500

Email: marcelo@it.uc3m.es

URI: https://www.it.uc3m.es

 

Greg White

CableLabs

United States of America

Email: G.White@CableLabs.com

---

Перевод на русский язык

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                          D. Yeung
Request for Comments: 9129                                  Arrcus, Inc.
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                                Futurewei
                                                                J. Zhang
                                                        Juniper Networks
                                                                 I. Chen
                                                   The MITRE Corporation
                                                               A. Lindem
                                                           Cisco Systems
                                                            October 2022

YANG Data Model for the OSPF Protocol

Модель данных YANG для протокола OSPF

PDF

Аннотация

Этот документ задаёт модель данных YANG, которая может служить для настройки и управления OSPF. Модель основана на версии YANG 1.1, определённой в RFC 7950, и соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA), описанной в RFC 8342.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9129.

Авторские права

Copyright (c) 2022. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

YANG [RFC7950] – язык определения данных, служащий для задания содержимого концептуального хранилища данных, позволяющего управлять сетевыми устройствами по протоколу настройки сети (Network Configuration Protocol или NETCONF) [RFC6241], RESTCONF [RFC8040] или иному протоколу управления сетью. Кроме того, модели данных YANG могут служить основой для реализации других интерфейсов, таких как консольный (Command-Line Interface или CLI) и программный API.

Этот документ определяет модель данных YANG, которая может служить для настройки и управления OSPF. Он дополняет модель данных ядра маршрутизации, заданную в [RFC8349], и предоставляет основу для разработки моделей данных протоколов маршрутизации. Модель полностью соответствует архитектуре NMDA [RFC8342]. Модель данных интерфейса определена в [RFC8343] и применяется для ссылки на интерфейсы из протоколов маршрутизации. Модель данных для цепочек ключей [RFC8177] применяется для аутентификации OSPF и обеспечивает ссылки на настроенные цепочки ключей и криптографические алгоритмы.

Поддерживаются оба протокола OSPFv2 [RFC2328] и OSPFv3 [RFC5340]. В дополнение к протоколу ядра OSPF поддерживаются функции из других RFC, связанных с OSPF. Это включает устройства запроса [RFC1793], организацию трафика (Traffic Engineering или TE) [RFC3630], разные семейства адресов [RFC5838], аккуратный перезапуск [RFC3623] [RFC5187], опцию NSSA (Not-So-Stubby Area) [RFC3101] и OSPFv2 или OSPFv3 в качестве протокола между провайдером и клиентом (Provider Edge to Customer Edge или PE-CE) [RFC4577] [RFC6565]. Не входящие в ядро функции в модели OSPF являются необязательными.

1.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

1.2. Диаграммы деревьев

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Устройство модели данных

Хотя базовые элементы конфигурации OSPF (маршрутизаторы, области, интерфейсы) не меняются, детали модели конфигурации зависят от производителя. Различия наблюдаются в разных аспектах, включая привязку экземпляра протокола к домену маршрутизации и создание экземпляров протокола. Цель этого документа состоит в определении модели данных, обеспечивающей пользовательский интерфейс для OSPFv2 и OSPFv3. Обязательных элементов (mandatory) очень немного, что даёт производителям возможность приспособить эту модель данных к своим реализациям.

2.1. Рабочее состояние OSPF

Рабочее состояние OSPF включено в одно дерево с конфигурацией OSPF в соответствии с архитектурой NMDA [RFC8342] и дополняется лишь контейнер routing из ietf-routing [RFC8349], а контейнер routing-state не меняется.

2.2. Обзор

Модуль YANG OSPF, заданный в этом документе, включает все базовые блоки, нужные для протокола OSPF. Модуль дополняет путь /routing/control-plane-protocols/control-plane-protocol, заданный в модуле ietf-routing. Модель ietf-ospf задаёт один экземпляр OSPF, который может быть создан как OSPFv2 или OSPFv3. Несколько экземпляров создаются как экземпляры протоколов плоскости управления.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
             .
             .
          +--rw address-family?       iana-rt-types:address-family
             .
             .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |        .
          |        .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     .
          |     |     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     .
          |     |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           .
          |           .
          +--rw topologies {multi-topology}?
             +--rw topology* [name]
                .
                .

Контейнер ospf включает один экземпляр протокола OSPF, содержащий данные конфигурации и состояния на уровне маршрутизатора OSPF. Каждый экземпляр OSPF сопоставляется с экземпляром протокола плоскости управления в соответствии с [RFC8349].

Контейнеры areas и area/interfaces определяют конфигурацию и рабочее состояние областей и интерфейсов OSPF.

Контейнер topologies определяет конфигурацию и рабочее состояние OSPF для топологий OSPF при поддержке функции (feature) multi-topology.

2.3. OSPFv2 и OSPFv3

Определённая здесь модель данных поддерживает протоколы OSPFv2 и OSPFv3. Обязательное поле version указывает применяемую версию OSPF и в соответствии с этим модель данных использует OSPFv2 или OSPFv3.

2.4. Необязательные функции

Указанные ниже необязательные функции (feature) выходят за рамки базовой конфигурации OSPF и производители сами решают, какие из этих функций поддерживать на конкретном устройстве.

multi-topology

Поддержка маршрутизации MT Multi-Topology) [RFC4915].

multi-area-adj

Поддержка смежности нескольких областей OSPF [RFC5185].

explicit-router-id

Поддержка явного задания Router ID на уровне экземпляра.

demand-circuit

Поддержа устройств, запрашивающих OSPF [RFC1793].

mtu-ignore

Поддержка запрета проверки MTU пакета OSPF Database Description в соответствии с параграфом 10.6 в [RFC2328].

lls

Поддержка сигнализации LLS (OSPF Link-Local Signaling) [RFC5613].

prefix-suppression

Поддержка подавления анонсов префиксов OSPF [RFC6860].

ttl-security

Поддержка проверки безопасности для OSPF TTL (Time to Live) [RFC5082].

nsr

Поддержка OSPF NSR (Non-Stop Routing), позволяющей маршрутизатору с избыточностью плоскости управления (например, платы с двумя процессорами маршрутов – Route Processor или RP)) поддерживать своё состояние и отношения смежности при плановом или неплановом перезапуске плоскости управления. Это отличается от безостановочной пересылки (Non-Stop Forwarding или NSF) тем, что не требует содействия соседей OSPF для восстановления состояния плоскости управления.

graceful-restart

Поддержка аккуратного (graceful) перезапуска OSPF [RFC3623] [RFC5187].

auto-cost

Поддержка расчёта стоимости для интерфейса OSPF по эталонной пропускной способности [RFC2328].

max-ecmp

Поддержка настройки максимального числа равноценных путей (Equal-Cost Multi-Path или ECMP).

max-lsa

Поддержка настройки максимального числа анонсов состояния канала (Link State Advertisement или LSA), воспринимаемых экземпляром OSPF [RFC1765].

te-rid

Поддержка настройки TE Router ID, т е. Router Address TLV, как указано в параграфе 2.4.1 [RFC3630], или Router IPv6 Address TLV, как указано в разделе 3 [RFC5329].

ldp-igp-sync

Поддержка синхронизации LDP IGP [RFC5443].

ospfv2-authentication-trailer

Поддержка трейлера аутентификации OSPFv2 [RFC5709] [RFC7474].

ospfv3-authentication-ipsec

Поддержка IPsec для аутентификации OSPFv3 [RFC4552].

ospfv3-authentication-trailer

Поддержка трейлера аутентификации OSPFv3 [RFC7166].

fast-reroute

Поддержка IP Fast Reroute (IP-FRR) [RFC5714].

node-flag

Поддержка флагов узла для префиксов for OSPF [RFC7684].

node-tag

Поддержка административных флагов узла для экземпляров OSPF [RFC7777].

lfa

Поддержка беспетлевых вариантов (Loop-Free Alternate или LFA) [RFC5286].

remote-lfa

Поддержка удалённых LFA (Remote LFA или R-LFA) [RFC7490].

stub-router

Поддержка анонсов тупиковых маршрутизаторов OSPF [RFC6987].

pe-ce-protocol

Поддержка OSPF в качестве протокола PE-CE [RFC4577] [RFC6565].

ietf-spf-delay

Поддержка алгоритма задержки IETF Shortest Path First (SPF) [RFC8405].

bfd

Поддержка обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD) для нахождения соседей OSPF [RFC5880] [RFC5881].

hybrid-interface

Поддержка гибридных интерфейсов OSPF (broadcast и point-to-multipoint) [RFC6845].

Предполагается, что производители будут применять дополнения (augment) для поддержки дополнительных функций.

2.5. Конфигурация и рабочее состояние маршрутизатора OSPF

Контейнер ospf размещается на верхнем уровне модели и представляет экземпляр протокола OSPF с конфигурацией и рабочим состоянием на уровне маршрутизатора. Рабочее состояние включает статистику экземпляра, статистику задержки IETF SPF, базу данных LSDB (AS-Scope Link State Database), локальную таблицу RIB, журналы SPF и LSA.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw address-family?       iana-rt-types:address-family
          +--rw enabled?              boolean
          +--rw explicit-router-id?   rt-types:router-id
          |                           {explicit-router-id}?
          +--rw preference
          |  +--rw (scope)?
          |     +--:(single-value)
          |     |  +--rw all?          uint8
          |     +--:(multi-values)
          |        +--rw (granularity)?
          |        |  +--:(detail)
          |        |  |  +--rw intra-area?   uint8
          |        |  |  +--rw inter-area?   uint8
          |        |  +--:(coarse)
          |        |     +--rw internal?     uint8
          |        +--rw external?     uint8
          +--rw nsr {nsr}?
          |  +--rw enabled?  boolean
          +--rw graceful-restart {graceful-restart}?
          |  +--rw enabled?                      boolean
          |  +--rw helper-enabled?               boolean
          |  +--rw restart-interval?             uint16
          |  +--rw helper-strict-lsa-checking?   boolean
          +--rw auto-cost {auto-cost}?
          |  +--rw enabled?               boolean
          |  +--rw reference-bandwidth?   uint32
          +--rw spf-control
          |  +--rw paths?            uint16 {max-ecmp}?
          |  +--rw ietf-spf-delay {ietf-spf-delay}?
          |     +--rw initial-delay?   uint32
          |     +--rw short-delay?     uint32
          |     +--rw long-delay?      uint32
          |     +--rw hold-down?       uint32
          |     +--rw time-to-learn?   uint32
          |     +--ro current-state?             enumeration
          |     +--ro remaining-time-to-learn?
          |                   rt-types:timer-value-milliseconds
          |     +--ro remaining-hold-down?
          |                   rt-types:timer-value-milliseconds
          |     +--ro last-event-received?       yang:timestamp
          |     +--ro next-spf-time?             yang:timestamp
          |     +--ro last-spf-time?             yang:timestamp
          +--rw database-control
          |  +--rw max-lsa?   uint32 {max-lsa}?
          +--rw stub-router {stub-router}?
          |  +--rw (trigger)?
          |     +--:(always)
          |        +--rw always!
          +--rw mpls
          |  +--rw te-rid {te-rid}?
          |  |  +--rw ipv4-router-id?   inet:ipv4-address
          |  |  +--rw ipv6-router-id?   inet:ipv6-address
          |  +--rw ldp
          |     +--rw igp-sync?   boolean {ldp-igp-sync}?
          +--rw fast-reroute {fast-reroute}?
          |  +--rw lfa {lfa}?
          +--rw node-tags {node-tag}?
          |  +--rw node-tag* [tag]
          |     +--rw tag      uint32
          +--ro router-id?          rt-types:router-id
          +--ro local-rib
          |  +--ro route* [prefix]
          |     +--ro prefix        inet:ip-prefix
          |     +--ro next-hops
          |     |  +--ro next-hop* []
          |     |     +--ro outgoing-interface?   if:interface-ref
          |     |     +--ro next-hop              inet:ip-address
          |     +--ro metric?       uint32
          |     +--ro route-type?   route-type
          |     +--ro route-tag?    uint32
          +--ro statistics
          |  +--ro discontinuity-time         yang:date-and-time
          |  +--ro originate-new-lsa-count?   yang:counter32
          |  +--ro rx-new-lsas-count?         yang:counter32
          |  +--ro as-scope-lsa-count?        yang:gauge32
          |  +--ro as-scope-lsa-chksum-sum?   uint32
          |  +--ro database
          |  |  +--ro as-scope-lsa-type*
          |  |     +--ro lsa-type?        uint16
          |  |     +--ro lsa-count?       yang:gauge32
          |  |     +--ro lsa-cksum-sum?   uint32
          |  +--ro protected-routes {fast-reroute}?
          |  |  +--ro address-family-stats*
          |  |         [address-family prefix alternate]
          |  |     +--ro address-family
          |  |         iana-rt-types:address-family
          |  |     +--ro prefix                  inet:ip-prefix
          |  |     +--ro alternate               inet:ip-address
          |  |     +--ro alternate-type?         enumeration
          |  |     +--ro best?                   boolean
          |  |     +--ro non-best-reason?        string
          |  |     +--ro protection-available?   bits
          |  |     +--ro alternate-metric-1?     uint32
          |  |     +--ro alternate-metric-2?     uint32
          |  |     +--ro alternate-metric-3?     uint32
          |  +--ro unprotected-routes {fast-reroute}?
          |  |  +--ro address-family-stats* [address-family prefix]
          |  |     +--ro address-family    iana-rt-types:address-family
          |  |     +--ro prefix            inet:ip-prefix
          |  +--ro protection-statistics* [frr-protection-method]
          |     +--ro frr-protection-method    string
          |     +--ro address-family-stats* [address-family]
          |        +--ro address-family
          |             iana-rt-types:address-family
          |        +--ro total-routes?           uint32
          |        +--ro unprotected-routes?     uint32
          |        +--ro protected-routes?       uint32
          |        +--ro linkprotected-routes?   uint32
          |        +--ro nodeprotected-routes?   uint32
          +--ro database
          |  +--ro as-scope-lsa-type* [lsa-type]
          |     +--ro as-scope-lsas
          |        +--ro as-scope-lsa* [lsa-id adv-router]
          |           +--ro lsa-id               union
          |           +--ro adv-router           inet:ipv4-address
          |           +--ro decoded-completed?   boolean
          |           +--ro raw-data?            yang:hex-string
          |           +--ro (version)?
          |              +--:(ospfv2)
          |              |  +--ro ospfv2
          .              .
          .              .
          |              +--:(ospfv3)
          |                 +--ro ospfv3
          .
          .
          +--ro spf-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro spf-type?             enumeration
          |     +--ro schedule-timestamp?   yang:timestamp
          |     +--ro start-timestamp?      yang:timestamp
          |     +--ro end-timestamp?        yang:timestamp
          |     +--ro trigger-lsa*
          |        +--ro area-id?      area-id-type
          |        +--ro type?         uint16
          |        +--ro lsa-id?       union
          |        +--ro adv-router?   rt-types:router-id
          |        +--ro seq-num?      uint32
          +--ro lsa-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro lsa
          |     |  +--ro area-id?      area-id-type
          |     |  +--ro type?         uint16
          |     |  +--ro lsa-id?       union
          |     |  +--ro adv-router?   rt-types:router-id
          |     |  +--ro seq-num?      uint32
          |     +--ro received-timestamp?   yang:timestamp
          |     +--ro reason?               identityref
          .
          .

2.6. Конфигурация и рабочее состояние области OSPF

Контейнер area содержит конфигурацию области OSPF и список контейнеров для всех интерфейсов OSPF в эту область. Рабочее состояние области включает статистику и LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |     +--rw area-type?                identityref
          |     +--rw summary?                  boolean
          |     +--rw default-cost?             ospf-metric
          |     +--rw ranges
          |     |  +--rw range* [prefix]
          |     |     +--rw prefix       inet:ip-prefix
          |     |     +--rw advertise?   boolean
          |     |     +--rw cost?        ospf-metric
          |     +--rw topologies {ospf:multi-topology}?
          |     |  +--rw topology* [name]
          |     |     +--rw name  -> ../../../../../../../../
          |     |                    ../../../rt:ribs/rib/name
          |     |     +--rw summary?        boolean
          |     |     +--rw default-cost?   ospf-metric
          |     |     +--rw ranges
          |     |         +--rw range* [prefix]
          |     |            +--rw prefix       inet:ip-prefix
          |     |            +--rw advertise?   boolean
          |     |            +--rw cost?        ospf-metric
          |     +--ro statistics
          |     |  +--ro discontinuity-time           yang:date-and-time
          |     |  +--ro spf-runs-count?              yang:counter32
          |     |  +--ro abr-count?                   yang:gauge32
          |     |  +--ro asbr-count?                  yang:gauge32
          |     |  +--ro ar-nssa-translator-event-count?
          |     |                                     yang:counter32
          |     |  +--ro area-scope-lsa-count?        yang:gauge32
          |     |  +--ro area-scope-lsa-cksum-sum?    uint32
          |     |  +--ro database
          |     |     +--ro area-scope-lsa-type*
          |     |        +--ro lsa-type?        uint16
          |     |        +--ro lsa-count?       yang:gauge32
          |     |        +--ro lsa-cksum-sum?   uint32
          |     +--ro database
          |     |  +--ro area-scope-lsa-type* [lsa-type]
          |     |     +--ro lsa-type           uint16
          |     |     +--ro area-scope-lsas
          |     |        +--ro area-scope-lsa* [lsa-id adv-router]
          |     |           +--ro lsa-id               union
          .     .           .
          .     .           .
          |     |           +--ro (version)?
          |     |              +--:(ospfv2)
          |     |              |  +--ro ospfv2
          |     |              |     +--ro header
          .     .              .     .
          .     .              .     .
          |     |              |     +--ro body
          |     |              |        +--ro router
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro network
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro summary
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro external
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro opaque
          .     .              .        .
          .     .              .        .
          |     |              +--:(ospfv3)
          |     |                 +--ro ospfv3
          |     |                    +--ro header
          .     .                    .
          .     .                    .
          |     |                    +--ro body
          |     |                       +--ro router
          .     .                       .
          .     .                       .
          |     |                       +--ro network
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-router
          .     .                       .
          .     .                       .
          |     |                       +--ro as-external
          .     .                       .
          .     .                       .
          |     |                       +--ro nssa
          .     .                       .
          .     .                       .
          |     |                       +--ro link
          .     .                       .
          .     .                       .
          |     |                       +--ro intra-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro router-information
          .     .                       .
          .     .                       .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     +--rw transit-area-id       -> ../../../../
          |     |                                    area/area-id
          |     |     +--rw router-id             rt-types:router-id
          |     |     +--rw hello-interval?       uint16
          |     |     +--rw dead-interval?        uint32
          |     |     +--rw retransmit-interval?  uint16
          |     |     +--rw transmit-delay?       uint16
          |     |     +--rw lls?                  boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?              boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--ro cost?              ospf-link-metric
          |     |     +--ro state?             if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?      rt-types:router-id
          |     |     +--ro dr-ip-addr?        inet:ip-address
          |     |     +--ro bdr-router-id?     rt-types:router-id
          |     |     +--ro bdr-ip-addr?       inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   int32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     +--rw local-id               inet:ip-address
          |     |     +--rw remote-id              inet:ip-address
          |     |     +--rw hello-interval?        uint16
          |     |     +--rw dead-interval?         uint32
          |     |     +--rw retransmit-interval?   uint16
          |     |     +--rw transmit-delay?        uint16
          |     |     +--rw lls?                   boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?            boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--rw cost?               ospf-link-metric
          |     |     +--rw mtu-ignore?         boolean
          |     |                               {mtu-ignore}?
          |     |     +--rw prefix-suppression? boolean
          |     |                               {prefix-suppression}?
          |     |     +--ro state?              if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?       rt-types:router-id
          |     |     +--ro dr-ip-addr?         inet:ip-address
          |     |     +--ro bdr-router-id?      rt-types:router-id
          |     |     +--ro bdr-ip-addr?        inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   uint32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro cost?           ospf-link-metric
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time?
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .

2.7. Конфигурация и рабочее состояние интерфейса OSPF

Контейнер interface содержит конфигурацию и рабочее состояние интерфейса OSPF. Рабочее состояние интерфейса включает статистику интерфейса, список соседей и link-local LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     .
          |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           +--rw name                   if:interface-ref
          |           +--rw interface-type?        enumeration
          |           +--rw passive?               boolean
          |           +--rw demand-circuit?        boolean
          |                                        {demand-circuit}?
          |           +--rw priority?              uint8
          |           +--rw multi-areas {multi-area-adj}?
          |           |  +--rw multi-area* [multi-area-id]
          |           |     +--rw multi-area-id      area-id-type
          |           |     +--rw cost?              ospf-link-metric
          |           +--rw static-neighbors
          |           |  +--rw neighbor* [identifier]
          |           |     +--rw identifier       inet:ip-address
          |           |     +--rw cost?            ospf-link-metric
          |           |     +--rw poll-interval?   uint16
          |           |     +--rw priority?        uint8
          |           +--rw node-flag?             boolean
          |                                        {node-flag}?
          |           +--rw bfd {bfd}?
          |           |  +--rw enabled?            boolean
          |           |  +--rw local-multiplier?   multiplier
          |           |  |      {client-base-cfg-parms}?
          |           |  +--rw (interval-config-type)?
          |           |  |      {client-base-cfg-parms}?
          |           |     +--:(tx-rx-intervals)
          |           |     |  +--rw desired-min-tx-interval?  uint32
          |           |     |  +--rw required-min-rx-interval? uint32
          |           |     +--:(single-interval)
          |           |     |   {single-minimum-interval}?
          |           |        +--rw min-interval?             uint32
          |           +--rw fast-reroute {fast-reroute}?
          |           |  +--rw lfa {lfa}?
          |           |     +--rw candidate-enabled?  boolean
          |           |     +--rw enabled?            boolean
          |           |     +--rw remote-lfa {remote-lfa}?
          |           |        +--rw enabled?  boolean
          |           +--rw hello-interval?        uint16
          |           +--rw dead-interval?         uint32
          |           +--rw retransmit-interval?   uint16
          |           +--rw transmit-delay?        uint16
          |           +--rw lls?                   boolean {lls}?
          |           +--rw ttl-security {ttl-security}?
          |           |  +--rw enabled?  boolean
          |           |  +--rw hops?     uint8
          |           +--rw enabled?               boolean
          |           +--rw authentication
          |           |  +--rw (auth-type-selection)?
          |           |     +--:(ospfv2-auth)
          |           |     |  +--rw ospfv2-auth-trailer-rfc?
          |           |     |  |       ospfv2-auth-trailer-rfc-version
          |           |     |  |        {ospfv2-authentication-trailer}?
          |           |     |  +--rw (ospfv2-auth-specification)?
          |           |     |     +--:(auth-key-chain) {key-chain}?
          |           |     |     |  +--rw ospfv2-key-chain?
          |           |     |     |         key-chain:key-chain-ref
          |           |     |     +--:(auth-key-explicit)
          |           |     |        +--rw ospfv2-key-id?     uint32
          |           |     |        +--rw ospfv2-key?        string
          |           |     |        +--rw ospfv2-crypto-algorithm?
          |           |     |                identityref
          |           |     +--:(ospfv3-auth-ipsec)
          |           |     |      {ospfv3-authentication-ipsec}?
          |           |     |  +--rw sa?                       string
          |           |     +--:(ospfv3-auth-trailer)
          |           |        |  {ospfv3-authentication-trailer}?
          |           |        +--rw (ospfv3-auth-specification)?
          |           |           +--:(auth-key-chain) {key-chain}?
          |           |           |  +--rw ospfv3-key-chain?
          |           |           |          key-chain:key-chain-ref
          |           |           +--:(auth-key-explicit)
          |           |              +--rw ospfv3-sa-id?        uint16
          |           |              +--rw ospfv3-key?          string
          |           |              +--rw ospfv3-crypto-algorithm?
          |           |                      identityref
          |           +--rw cost?               ospf-link-metric
          |           +--rw mtu-ignore?         boolean
          |           |                         {mtu-ignore}?
          |           +--rw prefix-suppression? boolean
          |           |                         {prefix-suppression}?
          |           +--ro state?                 if-state-type
          |           +--ro hello-timer?       rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro wait-timer?        rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro dr-router-id?       rt-types:router-id
          |           +--ro dr-ip-addr?         inet:ip-address
          |           +--ro bdr-router-id?      rt-types:router-id
          |           +--ro bdr-ip-addr?        inet:ip-address
          |           +--ro statistics
          |           |  +--ro discontinuity-time?    yang:date-and-time
          |           |  +--ro if-event-count?        yang:counter32
          |           |  +--ro link-scope-lsa-count?  yang:gauge32
          |           |  +--ro link-scope-lsa-cksum-sum?
          |           |                               uint32
          |           |  +--ro database
          |           |     +--ro link-scope-lsa-type*
          |           |        +--ro lsa-type?        uint16
          |           |        +--ro lsa-count?       yang:gauge32
          |           |        +--ro lsa-cksum-sum?   int32
          |           +--ro neighbors
          |           |  +--ro neighbor* [neighbor-router-id]
          |           |     +--ro neighbor-router-id
          |           |                           rt-types:router-id
          |           |     +--ro address?        inet:ip-address
          |           |     +--ro dr-router-id?   rt-types:router-id
          |           |     +--ro dr-ip-addr?     inet:ip-address
          |           |     +--ro bdr-router-id?  rt-types:router-id
          |           |     +--ro bdr-ip-addr?    inet:ip-address
          |           |     +--ro state?          nbr-state-type
          |           |     +--ro dead-timer? rt-types:
          |           |     |                  rtimer-value-seconds16
          |           |     +--ro statistics
          |           |        +--ro discontinuity-time?
          |           |                           yang:date-and-time
          |           |        +--ro nbr-event-count?
          |           |                           yang:counter32
          |           |        +--ro nbr-retrans-qlen?
          |           |                           yang:gauge32
          |           +--ro database
          |           .  +--ro link-scope-lsa-type* [lsa-type]
          |           .     +--ro lsa-type           uint16
          |           .     +--ro link-scope-lsas
          .           .
          .           .
          |           +--rw topologies {ospf:multi-topology}?
          |           |  +--rw topology* [name]
          |           |     +--rw name  -> ../../../../../../../../
          |           |                    ../../../rt:ribs/rib/name
          |           |     +--rw cost? ospf-link-metric
          |           +--rw instance-id?           uint8
          .
          .

2.8. Уведомления OSPF

Эта модель YANG содержит все уведомления, информирующие клиентов YANG о важных событиях при работе протокола. Уведомления включают базовый набор ловушек (trap) из OSPFv2 MIB [RFC4750] и OSPFv3 MIB [RFC5643].

     notifications:
       +---n if-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro state?                   if-state-type
       +---n if-config-error
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       |  +--ro error?                   enumeration
       +---n nbr-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro state?                   nbr-state-type
       +---n nbr-restart-helper-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro status?                  restart-helper-status-type
       |  +--ro age?                     rt-types:timer-value-seconds16
       |  +--ro exit-reason?             restart-exit-reason-type
       +---n if-rx-bad-packet
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       +---n lsdb-approaching-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n lsdb-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n nssa-translator-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro area-id?                 area-id-type
       |  +--ro status?                  nssa-translator-state-type
       +---n restart-status-change
          +--ro routing-protocol-name?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol/name
          +--ro address-family?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol[rt:name=current()/../
          +         routing-protocol-name]/ospf/address-family
          +--ro status?                  restart-status-type
          +--ro restart-interval?        uint16
          +--ro exit-reason?             restart-exit-reason-type

2.9. Операции OSPF RPC

Модуль ietf-ospf задаёт две операции RPC.

clear-database

Сброс содержимого конкретной базы OSPF LSDB с переводом отношений смежности в состояние DOWN и повторным созданием собственных анонсов LSA.

clear-neighbor

Сброс конкретного соседа или группы соседей OSPF, связанных с интерфейсом OSPF.

     rpcs:
       +---x clear-neighbor
       |  +---w input
       |     +---w routing-protocol-name
       |     +     -> /rt:routing/control-plane-protocols/
       |     +         control-plane-protocol/name
       |     +---w interface?               if:interface-ref
       +---x clear-database
          +---w input
             +---w routing-protocol-name
                   -> /rt:routing/control-plane-protocols/
                       control-plane-protocol/name

3. Модуль YANG OSPF

Модуль YANG ietf-ospf ссылается на [RFC0905], [RFC1765], [RFC1793], [RFC2328], [RFC3101], [RFC3623], [RFC3630], [RFC4552], [RFC4576], [RFC4577], [RFC4915], [RFC4973], [RFC5082], [RFC5185], [RFC5187], [RFC5250], [RFC5286], [RFC5309], [RFC5329], [RFC5340], [RFC5443], [RFC5613], [RFC5642], [RFC5709], [RFC5714], [RFC5838], [RFC5880], [RFC5881], [RFC6565], [RFC6845], [RFC6860], [RFC6987], [RFC6991], [RFC7166], [RFC7474], [RFC7490], [RFC7684], [RFC7770], [RFC7777], [RFC7884], [RFC8177], [RFC8294], [RFC8343], [RFC8349], [RFC8405], [RFC8476], [RFC9314].

   <CODE BEGINS> file "ietf-ospf@2022-10-19.yang"
   module ietf-ospf {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospf";

     prefix ospf;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import iana-routing-types {
       prefix iana-rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     import ietf-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     organization
       "IETF Link State Routing (lsr) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lsr/> 
        WG List:  <mailto:lsr@ietf.org> 

        Editor:   Derek Yeung
                  <mailto:derek@arrcus.com> 
        Author:   Acee Lindem
                  <mailto:acee@cisco.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.qu@futurewei.com> 
        Author:   Jeffrey Zhang
                  <mailto:zzhang@juniper.net> 
        Author:   Ing-Wher Chen
                  <mailto:ingwherchen@mitre.org>"; 

     description
       "Этот модуль определяет базовую конфигурацию и рабочее состояние
        для протокола OSPF, общие для реализаций всех производителей.
        Предполагается, что производители будут расширять модуль, 
        задавая зависимые от реализации параметры и правила, например,
        карты и политику для маршрутов.

        Эта модель YANG соответствует архитектуре NMDA (RFC 8342).

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

        Авторские права (Copyright (c) 2022) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9129, где правовые
        аспекты приведены более полно.";

     revision 2022-10-19 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     feature multi-topology {
       description
         "Поддержка маршрутизации Multi-Topology (MT).";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     feature multi-area-adj {
       description
         "Поддержка смежности с несколькими областями (RFC 5185).";
       reference
         "RFC 5185: OSPF Multi-Area Adjacency";
     }

     feature explicit-router-id {
       description
         "Явно задаёт Router ID на уровне экземпляра.";
     }

     feature demand-circuit {
       description
         "Поддержка устройств OSPF demand (RFC 1793).";
       reference
         "RFC 1793: Extending OSPF to Support Demand Circuits";
     }

     feature mtu-ignore {
       description
         "Запрет проверки несоответствия MTU для пакетов OSPF 
          Database Description, описанной в спецификации OSPFv2
          (RFC 2328). Проверка применима и к OSPFv3 (RFC 5340).";
       reference
         "RFC 2328: OSPF Version 2, Section 10.6
          RFC 5340: OSPF for IPv6";
     }

     feature lls {
       description
         "Сигнализация OSPF LLS, определённая в RFC 5613.";
       reference
         "RFC 5613: OSPF Link-Local Signaling";
     }

     feature prefix-suppression {
       description
         "Поддержка подавления префиксов OSPF, описанная в RFC 6860.";
       reference
         "RFC 6860: Hiding Transit-Only Networks in OSPF";
     }

     feature ttl-security {
       description
         "Поддержка проверки безопасности OSPF Time TTL.";
       reference
         "RFC 5082: The Generalized TTL Security Mechanism (GTSM)";
     }

     feature nsr {
       description
         "Поддержка безостановочной маршрутизации (NSR). Функция 
          позволяет маршрутизатору с избыточностью плоскости управления
          (например, с двойными платами RP) поддерживать своё состояние
          и смежности при плановом или неплановом перезапуске экземпляра
          OSPF. Это отличается от аккуратного перезапуска и 
          безостановочной пересылки (NSF) тем, что для восстановления
          состоянии плоскости управления не требуется протокол
          сигнализации или содействие соседей OSPF .";
     }

     feature graceful-restart {
       description
         "Аккуратный перезапуск OSPF в соответствии с RFC 3623 и 5187.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     feature auto-cost {
       description
         "Расчёт стоимости для интерфейса OSPF по эталонной пропускной
          способности.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     feature max-ecmp {
       description
         "Задаёт максимальное число путей ECMP.";
     }

     feature max-lsa {
       description
         "Максимальной число анонсов LSA, воспринимаемых экземпляром.";
       reference
         "RFC 1765: OSPF Database Overflow";
     }

     feature te-rid {
       description
         "Поддержка настройки TE Router ID, т. е. Router Address TLV 
          (параграф 2.4.1 в RFC 3630) или Router IPv6 Address TLV
          (раздел 3 в RFC 5329).";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2, Section 2.4.1
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3,
          Section 3";
     }

     feature ldp-igp-sync {
       description
         "Синхронизация LDP IGP.";
       reference
         "RFC 5443: LDP IGP Synchronization";
     }

     feature ospfv2-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv2.";
       reference
         "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
          RFC 7474: Security Extension for OSPFv2 When
          Using Manual Key Management";
     }

     feature ospfv3-authentication-ipsec {
       description
         "Поддержка IPsec для аутентификации OSPFv3.";
       reference
         "RFC 4552: Authentication/Confidentiality for OSPFv3";
     }

     feature ospfv3-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv3.";
       reference
         "RFC 7166: Supporting Authentication Trailer for OSPFv3";
     }

     feature fast-reroute {
       description
         "Поддержка IP Fast Reroute (IP-FRR).";
       reference
         "RFC 5714: IP Fast Reroute Framework";
     }

     feature key-chain {
       description
         "Поддержка цепочки ключей для аутентификации.";
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     feature node-flag {
       description
         "Поддержка флагов узла для префиксов OSPF.";
       reference
         "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
     }

     feature node-tag {
       description
         "Поддержка административных флагов узла для экземпляров 
          маршрутизации OSPF.";
       reference
         "RFC 7777: Advertising Node Administrative Tags in OSPF";
     }

     feature lfa {
       description
         "Поддержка Loop-Free Alternate (LFA).";
       reference
         "RFC 5286: Basic Specification for IP Fast Reroute:
          Loop-Free Alternates";
     }

     feature remote-lfa {
       description
         "Поддержка Remote LFA (R-LFA).";
       reference
         "RFC 7490: Remote Loop-Free Alternate (LFA) Fast Reroute
          (FRR)";
     }

     feature stub-router {
       description
         "Поддержка анонсов тупиковых маршрутизаторов OSPF (RFC 6987).";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     feature pe-ce-protocol {
       description
         "Поддержка OSPF в качестве протокола PE-CE.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
          for BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE)
          Routing Protocol";
     }

     feature ietf-spf-delay {
       description
         "Поддержка алгоритма задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     feature bfd {
       description
         "Поддержка BFD для обнаружения доступности соседей OSPF.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)
          RFC 5881: Bidirectional Forwarding Detection
          (BFD) for IPv4 and IPv6 (Single Hop)";
     }

     feature hybrid-interface {
       description
         "Поддержка гибридных интерфейсов OSPF.";
       reference
         "RFC 6845: OSPF Hybrid Broadcast and
          Point-to-Multipoint Interface Type";
     }

     identity ospf {
       base rt:routing-protocol;
       description
         "Любая версия протокола OSPF.";
     }

     identity ospfv2 {
       base ospf;
       description
         "Протокол OSPFv2.";
     }

     identity ospfv3 {
       base ospf;
       description
         "Протокол OSPFv3.";
     }

     identity area-type {
       description
         "Базовый идентификатор для типа области OSPF.";
     }

     identity normal-area {
       base area-type;
       description
         "Обычная область OSPF.";
     }

     identity stub-nssa-area {
       base area-type;
       description
         "Тупиковая или NSSA область OSPF.";
     }

     identity stub-area {
       base stub-nssa-area;
       description
         "Тупиковая область OSPF.";
     }

     identity nssa-area {
       base stub-nssa-area;
       description
         "OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-lsa-type {
       description
         "Базовый идентификатор типов LSA для OSPFv2 и OSPFv3.";
     }

     identity ospfv2-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv2 LSA.";
     }

     identity ospfv2-router-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Router-LSA - тип 1.";
     }

     identity ospfv2-network-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Network-LSA - тип 2.";
     }

     identity ospfv2-summary-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 summary LSA.";
     }

     identity ospfv2-network-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 Network summary LSA - тип 3.";
     }

     identity ospfv2-asbr-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 ASBR summary LSA - тип 4.";
     }

     identity ospfv2-external-lsa-type {
       base ospfv2-lsa-type;
       description
         "OSPFv2 External-LSA.";
     }

     identity ospfv2-as-external-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 AS-External-LSA - тип 5.";
     }

     identity ospfv2-nssa-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 NSSA-LSA - тип 7.";
     }

     identity ospfv2-opaque-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 Opaque-LSA.";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity ospfv2-link-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Link-Scope Opaque-LSA - тип 9.";
     }

     identity ospfv2-area-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Area-Scope Opaque-LSA - тип 10.";
     }

     identity ospfv2-as-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 AS-Scope Opaque-LSA - тип 11.";
     }

     identity ospfv2-unknown-lsa-type {
       base ospfv2-lsa-type;
       description
         "Неизвестный тип OSPFv2 LSA.";
     }

     identity ospfv3-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv3 LSA.";
       reference
         "RFC 5340: OSPF for IPv6";
     }

     identity ospfv3-router-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-LSA - тип 0x2001.";
     }

     identity ospfv3-network-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Network-LSA - тип 0x2002.";
     }

     identity ospfv3-summary-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 summary LSA.";
     }

     identity ospfv3-inter-area-prefix-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Prefix-LSA - тип 0x2003.";
     }

     identity ospfv3-inter-area-router-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Router-LSA - тип 0x2004.";
     }

     identity ospfv3-external-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 External-LSA.";
     }

     identity ospfv3-as-external-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 AS-External-LSA - тип 0x4005.";
     }

     identity ospfv3-nssa-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 NSSA-LSA - тип 0x2007.";
     }

     identity ospfv3-link-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Link-LSA - тип 0x0008.";
     }

     identity ospfv3-intra-area-prefix-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Intra-Area-Prefix-LSA - тип 0x2009.";
     }

     identity ospfv3-router-information-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-Information-LSA - тип 0x800C, 0xA00C, 0xC00C.";
     }

     identity ospfv3-unknown-lsa-type {
       base ospfv3-lsa-type;
       description
         "Неизвестный тип OSPFv3 LSA.";
     }

     identity lsa-log-reason {
       description
         "Базовый идентификатор для причины записи LSA.";
     }

     identity lsa-refresh {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате приёма обновления LSA.";
     }

     identity lsa-content-change {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате изменения содержимого.";
     }

     identity lsa-purge {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате очистки.";
     }

     identity informational-capability {
       description
         "Базовый идентификатор возможностей маршрутизатора.";
     }

     identity graceful-restart {
       base informational-capability;
       description
         "Маршрутизатор поддерживает аккуратный перезапуск.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity graceful-restart-helper {
       base informational-capability;
       description
         "Маршрутизатор способен помогать аккуратному перезапуску.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity stub-router {
       base informational-capability;
       description
         "Маршрутизатор способен быть тупиковым OSPF stub.";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     identity traffic-engineering {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать OSPF TE.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3";
     }

     identity p2p-over-lan {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать соединения OSPF «точка-точка»
          через ЛВС.";
       reference
         "RFC 5309: Point-to-Point Operation over LAN in Link State
          Routing Protocols";
     }

     identity experimental-te {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать экспериментальный OSPF TE.";
       reference
         "RFC 4973: OSPF-xTE: Experimental Extension to OSPF for
          Traffic Engineering";
     }

     identity router-lsa-bit {
       description
         "Базовый идентификатор для битов Router-LSA.";
     }

     identity vlink-end-bit {
       base router-lsa-bit;
       description
         "Бит V, указывающий, что маршрутизатор является конечной
          точкой одного или нескольких виртуальных каналов.";
     }

     identity asbr-bit {
       base router-lsa-bit;
       description
         "Бит E, указывающий, что маршрутизатор является ASBR.";
     }

     identity abr-bit {
       base router-lsa-bit;
       description
         "Бит B, указывающий, что маршрутизатор является ABR.";
     }

     identity nssa-bit {
       base router-lsa-bit;
       description
         "Бит Nt, указывающий, что маршрутизатор является граничным для
          NSSA и безусловно транслирует NSSA-LSA в AS-External-LSA.";
     }

     identity ospfv3-lsa-option {
       description
         "базовый идентификатор для опций OSPF LSA.";
     }

     identity af-bit {
       base ospfv3-lsa-option;
       description
         "Бит AF, указывающий поддержку маршрутизатором семейств адресов
          OSPFv3, как описано в RFC 5838.";
       reference
         "RFC 5838: Support of Address Families in OSPFv3";
     }

     identity dc-bit {
       base ospfv3-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity r-bit {
       base ospfv3-lsa-option;
       description
         "Бит R, указывающий активность инициатора.";
     }

     identity n-bit {
       base ospfv3-lsa-option;
       description
         "Бит N, указывающий подключение маршрутизатора к NSSA.";
     }

     identity e-bit {
       base ospfv3-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity v6-bit {
       base ospfv3-lsa-option;
       description
         "Бит V6, сброс которого исключает маршрутизатор/канал из
          расчётов маршрутизации IPv6.";
     }

     identity ospfv3-prefix-option {
       description
         "Базовый идентификатор для опций префиксов OSPFv3.";
     }

     identity nu-bit {
       base ospfv3-prefix-option;
       description
         "Бит NU, указывающий исключение префикса из расчётов 
          IPv6 unicast.";
     }

     identity la-bit {
       base ospfv3-prefix-option;
       description
         "Бит LA, указывающий, что префикс является адресом IPv6
          интерфейса анонсирующего маршрутизатора.";
     }

     identity p-bit {
       base ospfv3-prefix-option;
       description
         "Бит P, указывающий, что префикс NSSA следует транслировать в
          AS-External-LSA и анонсировать транслирующему граничному
          маршрутизатору NSSA.";
     }

     identity dn-bit {
       base ospfv3-prefix-option;
       description
         "Бит DN, указывающий, что Inter-Area-Prefix-LSA или префикс
          AS-External-LSA анонсируется как префикс L3VPN.";
     }

     identity ospfv2-lsa-option {
       description
         "базовый идентификатор для опций OSPFv2 LSA.";
     }

     identity mt-bit {
       base ospfv2-lsa-option;
       description
         "Бит MT, указывающий что маршрутизатор поддерживает несколько
          топологий, как описано в RFC 4915.";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     identity v2-dc-bit {
       base ospfv2-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity v2-p-bit {
       base ospfv2-lsa-option;
       description
         "Бит P, используемый только для LSA типа 7 и указывающий, что
          граничному маршрутизатору NSSA следует транслировать LSA типа
          7 в LSA типа 5.";
     }

     identity mc-bit {
       base ospfv2-lsa-option;
       description
         "Бит MC, указывающий поддержку маршрутизатором MOSPF.";
     }

     identity v2-e-bit {
       base ospfv2-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity o-bit {
       base ospfv2-lsa-option;
       description
         "Бит O, указывающий поддержку опции Opaque LSA (RFC 5250).";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity v2-dn-bit {
       base ospfv2-lsa-option;
       description
         "Бит DN, который должен устанавливаться при передаче LSA типов
          3, 5, 7 от PE к CE (RFC 4576).";
       reference
         "RFC 4576: Using a Link State Advertisement (LSA) Options Bit
          to Prevent Looping in BGP/MPLS IP Virtual Private Networks
          (VPNs)";
     }

     identity ospfv2-extended-prefix-flag {
       description
         "Базовый идентификатор для флага Extended Prefix TLV.";
     }

     identity a-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг присоединения, указывающий что префикс соответствует
          маршруту, напрямую соединённому с анонсирующим 
          маршрутизатором.";
     }

     identity node-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг узла, указывающий, что префикс служит для представления
          анонсирующего узла (т. е. адреса loopback.";
     }

     typedef ospf-metric {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Метрика OSPF. 24-битовое целое число без знака.";
     }

     typedef ospf-link-metric {
       type uint16 {
         range "0 .. 65535";
       }
       description
         "метрика канала OSPF.  16-битовое целое число без знака .";
     }

     typedef opaque-id {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Opaque-LSA ID. 24-битовое целое число без знака .";
     }

     typedef area-id-type {
       type yang:dotted-quad;
       description
         "Тип Area ID.";
     }

     typedef route-type {
       type enumeration {
         enum intra-area {
           description
             "Внутриобластной маршрут OSPF.";
         }
         enum inter-area {
           description
             "Межобластной маршрут OSPF.";
         }
         enum external-1 {
           description
             "Внешний маршрут OSPF типа 1.";
         }
         enum external-2 {
           description
             "Внешний маршрут OSPF типа 2.";
         }
         enum nssa-1 {
           description
             "Маршрут OSPF NSSA типа 1.";
         }
         enum nssa-2 {
           description
             "Маршрут OSPF NSSA типа 2.";
         }
       }
       description
         "Тип маршрута OSPF.";
     }

     typedef if-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Интерфейс в состоянии Down.";
         }
         enum loopback {
           value 2;
           description
             "Интерфейс в состоянии Loopback.";
         }
         enum waiting {
           value 3;
           description
             "Интерфейс в состоянии Waiting.";
         }
         enum point-to-point {
           value 4;
           description
             "Интерфейс в состоянии Point-to-point.";
         }
         enum dr {
           value 5;
           description
             "Интерфейс в состоянии DR.";
         }
         enum bdr {
           value 6;
           description
             "Интерфейс в состоянии Backup.";
         }
         enum dr-other {
           value 7;
           description
             "Интерфейс в состоянии DR Other.";
         }
       }
       description
         "Тип состояния интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef router-link-type {
       type enumeration {
         enum point-to-point-link {
           value 1;
           description
             "Канал «точка-точка» к другому маршрутизатору.";
         }
         enum transit-network-link {
           value 2;
           description
             "Канал в транзитную сеть, указанную DR.";
         }
         enum stub-network-link {
           value 3;
           description
             "Канал в тупиковую сеть (stub), указанную подсетью.";
         }
         enum virtual-link {
           value 4;
           description
             "Виртуальный канал через транзитную область.";
         }
       }
       description
         "Тип канала маршрутизатора OSPF.";
     }

     typedef nbr-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Сосед в состоянии Down.";
         }
         enum attempt {
           value 2;
           description
             "Сосед в состоянии Attempt.";
         }
         enum init {
           value 3;
           description
             "Сосед в состоянии Init.";
         }
         enum 2-way {
           value 4;
           description
             "Сосед в состоянии 2-Way.";
         }
         enum exstart {
           value 5;
           description
             "Сосед в состоянии ExStart (начало обмена).";
         }
         enum exchange {
           value 6;
           description
             "Сосед в состоянии Exchange.";
         }
         enum loading {
           value 7;
           description
             "Сосед в состоянии Loading.";
         }
         enum full {
           value 8;
           description
             "Сосед в состоянии Full.";
         }
       }
       description
         "Тип состояния соседа OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef restart-helper-status-type {
       type enumeration {
         enum not-helping {
           value 1;
           description
             "Состояние помощника в перезапуске not-helping.";
         }
         enum helping {
           value 2;
           description
             "Состояние помощника в перезапуске helping.";
         }
       }
       description
         "Состояние помощника в перезапуске.";
     }

     typedef restart-exit-reason-type {
       type enumeration {
         enum none {
           value 1;
           description
             "Перезапуск не предпринимался.";
         }
         enum in-progress {
           value 2;
           description
             "Перезапуск выполняется.";
         }
         enum completed {
           value 3;
           description
             "Перезапуск завершен.";
         }
         enum timed-out {
           value 4;
           description
             "Тайм-аут при перезапуске.";
         }
         enum topology-changed {
           value 5;
           description
             "Перезапуск прерван из-за изменения топологии.";
         }
       }
       description
         "Описывает результат последней попытки аккуратного перезапуска.
          Локальный маршрутизатор перезапускается или помогает.";
     }

     typedef packet-type {
       type enumeration {
         enum hello {
           value 1;
           description
             "Пакет OSPF Hello.";
         }
         enum database-description {
           value 2;
           description
             "Пакет OSPF Database Description.";
         }
         enum link-state-request {
           value 3;
           description
             "Пакет OSPF Link State Request.";
         }
         enum link-state-update {
           value 4;
           description
             "Пакет OSPF Link State Update.";
         }
         enum link-state-ack {
           value 5;
           description
             "Пакет OSPF Link State Acknowledgment.";
         }
       }
       description
         "Типы пакетов OSPF.";
     }

     typedef nssa-translator-state-type {
       type enumeration {
         enum enabled {
           value 1;
           description
             "NSSATranslatorState enabled.";
         }
         enum elected {
           value 2;
           description
             "NSSATranslatorState elected.";
         }
         enum disabled {
           value 3;
           description
             "NSSATranslatorState disabled.";
         }
       }
       description
         "Тип состояния транслятора OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     typedef restart-status-type {
       type enumeration {
         enum not-restarting {
           value 1;
           description
             "Маршрутизатор не перезапускается.";
         }
         enum planned-restart {
           value 2;
           description
             "Маршрутизатор выполняет плановый перезапуск.";
         }
         enum unplanned-restart {
           value 3;
           description
             "Маршрутизатор выполняет неплановый перезапуск.";
         }
       }
       description
         "Тип состояния аккуратного перезапуска OSPF.";
     }

     typedef fletcher-checksum16-type {
       type string {
         pattern '(0x)?[0-9a-fA-F]{4}';
       }
       description
         "16-битовая контрольная сумма Fletcher в форме строки 0xXXXX.";
       reference
         "RFC 905: ISO Transport Protocol Specification ISO DP 8073";
     }

     typedef ospfv2-auth-trailer-rfc-version {
       type enumeration {
         enum rfc5709 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 5709.";
           reference
             "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication";
         }
         enum rfc7474 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 7474.";
           reference
             "RFC 7474: Security Extension for OSPFv2
              When Using Manual Key Management";
         }
       }
       description
         "Поддержка трейлера аутентификации OSPFv2.";
     }

     grouping tlv {
       description
         "Тип-Размер-Значение (Type-Length-Value или TLV).";
       leaf type {
         type uint16;
         description
           "Тип TLV.";
       }
       leaf length {
         type uint16;
         description
           "Размер TLV в октетах.";
       }
       leaf value {
         type yang:hex-string;
         description
           "Значение TLV.";
       }
     }

     grouping unknown-tlvs {
       description
         "Группировка служит для неизвестных TLV и суб-TLV.";
       container unknown-tlvs {
         description
           "Все неизвестные TLV.";
         list unknown-tlv {
           description
             "Неизвестный TLV.";
           uses tlv;
         }
       }
     }

     grouping node-tag-tlv {
       description
         "Группировка OSPF Node Admin Tag TLV.";
       list node-tag {
         leaf tag {
           type uint32;
           description
             "Значение административного тега узла.";
         }
         description
           "Список тегов.";
       }
     }

     grouping router-capabilities-tlv {
       description
         "Группировка для TLV возможностей маршрутизатора OSPF.";
       reference
         "RFC 7770: Extensions to OSPF for Advertising Optional
          Router Capabilities";
       container router-informational-capabilities {
         leaf-list informational-capabilities {
           type identityref {
             base informational-capability;
           }
           description
             "Список идентификаторов поддерживаемых маршрутизатором 
              информационных возможностей.";
         }
         description
           "Определения OSPF Router Informational Flag.";
       }
       list informational-capabilities-flags {
         leaf informational-flag {
           type uint32;
           description
             "Флаг отдельной информационной возможности.";
         }
         description
           "Список флагов информационных возможностей. Возвращаются все
            32-битовые информационные флаги, независимо от их
            известности устройству.";
       }
       list functional-capabilities {
         leaf functional-flag {
           type uint32;
           description
             "Флаг отдельной функциональной возможности.";
         }
         description
           "Список флагов функциональных возможностей. Возвращаются все
            32-битовые функциональные флаги, независимо от их
            известности устройству.";
       }
     }

     grouping dynamic-hostname-tlv {
       description
         "TLV динамического имени хоста.";
       reference
         "RFC 5642: Dynamic Hostname Exchange Mechanism for OSPF";
       leaf hostname {
         type string {
           length "1..255";
         }
         description
           "Динамическое имя хоста.";
       }
     }

     grouping sbfd-discriminator-tlv {
       description
         "S-BFD Discriminator TLV.";
       reference
         "RFC 7884: OSPF Extensions to Advertise Seamless Bidirectional
          Forwarding Detection (S-BFD) Target Discriminators";
       list sbfd-discriminators {
         leaf sbfd-discriminator {
           type uint32;
           description
             "Индивидуальный S-BFD Discriminator.";
         }
         description
           "Список дискриминаторов S-BFD.";
       }
     }

     grouping maximum-sid-depth-tlv {
       description
         "TLV узла для Maximum SID Depth (MSD).";
       reference
         "RFC 8476: Signaling Maximum SID Depth (MSD) Using OSPF";
       list msd-type {
         leaf msd-type {
           type uint8;
           description
             "Тип MSD.";
         }
         leaf msd-value {
           type uint8;
           description
             "Значение MSD для типа.";
         }
         description
           "Список кортежей MSD.";
       }
     }

     grouping ospf-router-lsa-bits {
       container router-bits {
         leaf-list rtr-lsa-bits {
           type identityref {
             base router-lsa-bit;
           }
           description
             "Список битов Router-LSA, содержащий идентификаторы для 
              всех битов, установленных в Router-LSA.";
         }
         description
           "Биты Router-LSA.";
       }
       description
         "Биты Router-LSA. В настоящее время одинаковы для OSPFv2 и
          OSPFv3, но могут быть разделены будущими дополнениями.";
     }

     grouping ospfv2-router-link {
       description
         "Канал маршрутизатора OSPFv2.";
       leaf link-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Router-LSA Link ID.";
       }
       leaf link-data {
         type union {
           type inet:ipv4-address;
           type uint32;
         }
         description
           "Данные канала Router-LSA.";
       }
       leaf type {
         type router-link-type;
         description
           "Тип канала Router-LSA.";
       }
     }

     grouping ospfv2-lsa-body {
       description
         "Тело OSPFv2 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-router-lsa')" {
           description
             "Применимо только к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         leaf num-of-links {
           type uint16;
           description
             "Число каналов в Router-LSA.";
         }
         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             uses ospfv2-router-link;
             container topologies {
               description
                 "Все топологии для канала.";
               list topology {
                 description
                   "Зависящая от топологии информация.";
                 leaf mt-id {
                   type uint8;
                   description
                     "MT-ID для топологии разрешён на канале.";
                 }
                 leaf metric {
                   type uint16;
                   description
                     "Метрика для топологии.";
                 }
               }
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";
         leaf network-mask {
           type yang:dotted-quad;
           description
             "Маска IP-адреса для сети.";
         }
         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type inet:ipv4-address;
             description
               "Список маршрутизаторов, присоединённых к сети.";
           }
         }
       }
       container summary {
         when "derived-from(../../header/type, "
            + "'ospfv2-summary-lsa-type')" {
           description
             "Применимо только к summary LSA.";
         }
         description
           "Summary LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для summary LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён в summary.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
           }
         }
       }
       container external {
         when "derived-from(../../header/type, "
            + "'ospfv2-external-lsa-type')" {
           description
             "Применимо только к AS-External-LSA и NSSA-LSA.";
         }
         description
           "External-LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для External-LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён для внешних и
                  NSSA-префиксов.";
             }
             leaf flags {
               type bits {
                 bit E {
                   description
                     "Указывает внешнюю метрику типа 2.";
                 }
               }
               description
                 "Флаги топологии.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
             leaf forwarding-address {
               type inet:ipv4-address;
               description
                 "Адрес IPv4 Forwarding.";
             }
             leaf external-route-tag {
               type uint32;
               description
                 "Флаг маршрута для топологии.";
             }
           }
         }
       }
       container opaque {
         when "derived-from(../../header/type, "
            + "'ospfv2-opaque-lsa-type')" {
           description
             "Применимо только для Opaque-LSA.";
         }
         description
           "Opaque-LSA.";

         container ri-opaque {
           description
             "OSPF Router-Information-Opaque-LSA.";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";

           container router-capabilities-tlv {
             description
               "Информационные и функциональные возможности 
                маршрутизатора.";
             uses router-capabilities-tlv;
           }

           container node-tag-tlvs {
             description
               "Все Node Admin Tag TLV.";
             list node-tag-tlv {
               description
                 "Node Admin Tag TLV.";
               uses node-tag-tlv;
             }
           }

           container dynamic-hostname-tlv {
             description
               "OSPF Dynamic Hostname TLV.";
             uses dynamic-hostname-tlv;
           }

           container sbfd-discriminator-tlv {
             description
               "OSPF S-BFD Discriminator TLV.";
             uses sbfd-discriminator-tlv;
           }

           container maximum-sid-depth-tlv {
             description
               "OSPF Node MSD TLV.";
             uses maximum-sid-depth-tlv;
           }
           uses unknown-tlvs;
         }

         container te-opaque {
           description
             "OSPFv2 TE Opaque-LSA.";
           reference
             "RFC 3630: Traffic Engineering (TE) Extensions to
              OSPF Version 2";

           container router-address-tlv {
             description
               "TLV с адресом маршрутизатора.";
             leaf router-address {
               type inet:ipv4-address;
               description
                 "Адрес маршрутизатора.";
             }
           }

           container link-tlv {
             description
               "Описывает один канал и состоит из набора суб-TLV.";
             leaf link-type {
               type router-link-type;
               mandatory true;
               description
                 "Тип канала.";
             }
             leaf link-id {
               type union {
                 type inet:ipv4-address;
                 type yang:dotted-quad;
               }
               mandatory true;
               description
                 "Link ID.";
             }
             container local-if-ipv4-addrs {
               description
                 "Все адреса IPv4 локального интерфейса.";
               leaf-list local-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 локального интерфейса.";
               }
             }
             container remote-if-ipv4-addrs {
               description
                 "Все адреса IPv4 удалённого интерфейса.";
               leaf-list remote-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 удалённого интерфейса.";
               }
             }
             leaf te-metric {
               type uint32;
               description
                 "TE metric.";
             }
             leaf max-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная пропускная способность.";
             }
             leaf max-reservable-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная резервируемая пропускная способность.";
             }
             container unreserved-bandwidths {
               description
                 "Вся незарезервированная пропускная способность.";
               list unreserved-bandwidth {
                 leaf priority {
                   type uint8 {
                     range "0 .. 7";
                   }
                   description
                     "Приоритет от 0 до 7.";
                 }
                 leaf unreserved-bandwidth {
                   type rt-types:bandwidth-ieee-float32;
                   description
                     "Незарезервированная пропускная способность.";
                 }
                 description
                   "Список значение незарезервированной пропускной
                    способности для разных приоритетов.";
               }
             }
             leaf admin-group {
               type uint32;
               description
                 "Административная группа-Класс ресурсов-Цвет.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-prefix-opaque {
           description
             "Все Extended Prefix TLV в LSA.";
           list extended-prefix-tlv {
             description
               "Extended Prefix TLV.";
             leaf route-type {
               type enumeration {
                 enum unspecified {
                   value 0;
                   description
                     "Не задано.";
                 }
                 enum intra-area {
                   value 1;
                   description
                     "Маршрут внутри области OSPF.";
                 }
                 enum inter-area {
                   value 3;
                   description
                     "Маршрут между областями OSPF.";
                 }
                 enum external {
                   value 5;
                   description
                     "Внешний маршрут OSPF.";
                 }
                 enum nssa {
                   value 7;
                   description
                     "Внешний маршрут OSPF NSSA.";
                 }
               }
               description
                 "Тип маршрута.";
             }
             container flags {
               leaf-list extended-prefix-flags {
                 type identityref {
                   base ospfv2-extended-prefix-flag;
                 }
                 description
                   "Список флагов Extended Prefix TLV, содержащий
                    идентификаторы для флагов префикса, устанавливаемые
                    во флагах расширенного префикса.";
               }
               description
                 "Флаги префикса.";
             }
             leaf prefix {
               type inet:ip-prefix;
               description
                 "Адресный префикс.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-link-opaque {
           description
             "Все Extended Link TLV в LSA.";
           reference
             "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
           container extended-link-tlv {
             description
               "Extended Link TLV.";
             uses ospfv2-router-link;
             container maximum-sid-depth-tlv {
               description
                 "OSPF Node MSD TLV.";
               uses maximum-sid-depth-tlv;
             }
             uses unknown-tlvs;
           }
         }
       }
     }

     grouping ospfv3-lsa-options {
       description
         "Опции OSPFv3 LSA.";
       container lsa-options {
         leaf-list lsa-options {
           type identityref {
             base ospfv3-lsa-option;
           }
           description
             "Список опций OSPFv3 LSA, содержащий идентификаторы
              OSPFv3 LSA Option, устанавливаемых для LSA.";
         }
         description
           "Опции OSPFv3 LSA.";
       }
     }

     grouping ospfv3-lsa-prefix {
       description
         "Префикс OSPFv3 LSA.";

       leaf prefix {
         type inet:ip-prefix;
         description
           "Префикс LSA.";
       }
       container prefix-options {
         leaf-list prefix-options {
           type identityref {
             base ospfv3-prefix-option;
           }
           description
             "Список опций префиксов OSPFv3, содержащий идентификаторы
              опций OSPFv3, устанавливаемых для префикса OSPFv3.";
         }
         description
           "Опции префикса.";
       }
     }

     grouping ospfv3-lsa-external {
       description
         "AS-External-LSA or NSSA-LSA.";
       leaf metric {
         type ospf-metric;
         description
           "Метрика AS-External-LSA или NSSA-LSA.";
       }
       leaf flags {
         type bits {
           bit E {
             description
               "Указывает внешнюю метрику типа 2.";
           }
           bit F {
             description
               "Указывает включение пересылающего адреса в LSA.";
           }
           bit T {
             description
               "Указывает включение тега внешнего маршрута в LSA.";
           }
         }
         description
           "Флаги AS-External-LSA или NSSA-LSA.";
       }

       leaf referenced-ls-type {
         type identityref {
           base ospfv3-lsa-type;
         }
         description
           "Referenced Link State (LS) Type.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
       leaf unknown-referenced-ls-type {
         type uint16;
         description
           "Значение для неизвестного Referenced LS Type.";
       }

       uses ospfv3-lsa-prefix;

       leaf forwarding-address {
         type inet:ipv6-address;
         description
           "Адрес IPv6 Forwarding.";
       }

       leaf external-route-tag {
         type uint32;
         description
           "Тег маршрута.";
       }
       leaf referenced-link-state-id {
         type uint32;
         description
           "Referenced Link State ID.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
     }

     grouping ospfv3-lsa-body {
       description
         "Тело OSPFv3 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-lsa')" {
           description
             "Применимо лишь к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         uses ospfv3-lsa-options;

         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             leaf interface-id {
               type uint32;
               description
                 "Interface ID для канала.";
             }
             leaf neighbor-interface-id {
               type uint32;
               description
                 "Interface ID соседа по каналу.";
             }
             leaf neighbor-router-id {
               type rt-types:router-id;
               description
                 "Router ID соседа по каналу.";
             }
             leaf type {
               type router-link-type;
               description
                 "Ти канала: 1 - «точка-точка»
                             2 — транзитная сеть
                             3 — резерв для каналов OSPFv3
                             4 — виртуальный канал.";
             }
             leaf metric {
               type uint16;
               description
                 "Метрика канала.";
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";

         uses ospfv3-lsa-options;

         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type rt-types:router-id;
             description
               "Список присоединённых к сети маршрутизаторов.";
           }
         }
       }
       container inter-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-prefix-lsa')" {
           description
             "Применимо только к Inter-Area-Prefix-LSA.";
         }
         leaf metric {
           type ospf-metric;
           description
             "Метрика префикса Inter-Area Prefix.";
         }
         uses ospfv3-lsa-prefix;
         description
           "Prefix-LSA.";
       }
       container inter-area-router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-router-lsa')" {
           description
             "Применимо только к Inter-Area-Router-LSA.";
         }
         uses ospfv3-lsa-options;
         leaf metric {
           type ospf-metric;
           description
             "Метрика граничного маршрутизатора AS (ASBR).";
         }
         leaf destination-router-id {
           type rt-types:router-id;
           description
             "Router ID маршрутизатора ASBR из LSA.";
         }
         description
           "Inter-Area-Router-LSA.";
       }
       container as-external {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-as-external-lsa')" {
           description
             "Применимо только к AS-External-LSA.";
         }

         uses ospfv3-lsa-external;

         description
           "AS-External-LSA.";
       }
       container nssa {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-nssa-lsa')" {
           description
             "Применимо только к NSSA-LSA.";
         }
         uses ospfv3-lsa-external;

         description
           "NSSA-LSA.";
       }
       container link {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-link-lsa')" {
           description
             "Применимо только к Link-LSA.";
         }
         leaf rtr-priority {
           type uint8;
           description
             "Приоритет маршрутизатора для выбора DR. Предпочитается
              маршрутизатор с наибольшим значением, 0 указывает, что
              маршрутизатор нежелателен в качестве DR или BDR.";
         }
         uses ospfv3-lsa-options;

         leaf link-local-interface-address {
           type inet:ipv6-address;
           description
             "Адрес link-local интерфейса создавшего анонс 
              маршрутизатора для этого канала.";
         }

         leaf num-of-prefixes {
           type uint32;
           description
             "Число префиксов.";
         }

         container prefixes {
           description
             "Все префиксы для канала.";
           list prefix {
             description
               "Список связанных с каналом префиксов.";
             uses ospfv3-lsa-prefix;
           }
         }
         description
           "Link-LSA.";
       }
       container intra-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-intra-area-prefix-lsa')" {
           description
             "Применимо только к Intra-Area-Prefix-LSA.";
         }
         description
           "Intra-Area-Prefix-LSA.";

         leaf referenced-ls-type {
           type identityref {
             base ospfv3-lsa-type;
           }
           description
             "Referenced LS Type.";
         }
         leaf unknown-referenced-ls-type {
           type uint16;
           description
             "Значение для неизвестного Referenced LS Type.";
         }
         leaf referenced-link-state-id {
           type uint32;
           description
             "Referenced Link State ID.";
         }
         leaf referenced-adv-router {
           type rt-types:router-id;
           description
             "Referenced Advertising Router.";
           reference
             "RFC 5340: OSPF for IPv6";
         }

         leaf num-of-prefixes {
           type uint16;
           description
             "Число префиксов.";
         }
         container prefixes {
           description
             "Все префиксы в этом анонсе LSA.";
           list prefix {
             description
               "Список префиксов в LSA.";
             uses ospfv3-lsa-prefix;
             leaf metric {
               type uint16;
               description
                 "Метрика перфикса.";
             }
           }
         }
       }
       container router-information {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-information-lsa')" {
           description
             "Применимо только к Router-Information-LSA (RFC 7770).";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";
         }
         container router-capabilities-tlv {
           description
             "Информационные и функциональные возможности 
              маршрутизатора.";
           uses router-capabilities-tlv;
         }
         container node-tag-tlvs {
           description
             "Все Node Admin Tag TLV.";
           list node-tag-tlv {
             description
               "Node Admin Tag TLV.";
             uses node-tag-tlv;
           }
         }
         container dynamic-hostname-tlv {
           description
             "OSPF Dynamic Hostname TLV.";
           uses dynamic-hostname-tlv;
         }

         container sbfd-discriminator-tlv {
           description
             "OSPF S-BFD Discriminator TLV.";
           uses sbfd-discriminator-tlv;
         }

         description
           "Router-Information-LSA.";
         reference
           "RFC 7770: Extensions to OSPF for Advertising Optional
            Router Capabilities";
       }
     }

     grouping lsa-header {
       description
         "LSA для OSPFv2 и OSPFv3.";
       leaf age {
         type uint16;
         mandatory true;
         description
           "Возраст LSA.";
       }
       leaf type {
         type identityref {
           base ospf-lsa-type;
         }
         mandatory true;
         description
           "Тип LSA.";
       }
       leaf adv-router {
         type rt-types:router-id;
         mandatory true;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         mandatory true;
         description
           "Порядковый номер LSA.";
       }
       leaf checksum {
         type fletcher-checksum16-type;
         mandatory true;
         description
           "Контрольная сумма LSA.";
       }
       leaf length {
         type uint16;
         mandatory true;
         description
           "Размер LSA с учётом заголовка.";
       }
     }

     grouping ospfv2-lsa {
       description
         "OSPFv2 LSA. Анонсы LSA однозначно указываются триплетом
          <LSA Type, Link State ID, Advertising Router> с разделением
          экземпляров по порядковым номерам LSA.";
       container header {
         must "(derived-from(type, "
            + "'ospfv2-opaque-lsa-type') and "
            + "opaque-id and opaque-type) or "
            + "(not(derived-from(type, "
            + "'ospfv2-opaque-lsa-type')) "
            + "and not(opaque-id) and not(opaque-type))" {
           description
             "Значение opaque-type и opaque-id применимы лишь 
              к Opaque-LSA.";
         }
         description
           "Декодированные данные заголовка OSPFv2 LSA.";

         container lsa-options {
           leaf-list lsa-options {
             type identityref {
               base ospfv2-lsa-option;
             }
             description
               "Список опций LSA, содержащий идентификаторы 
                установленных опций OSPFv2 LSA.";
           }
           description
             "Опции LSA.";
         }

         leaf lsa-id {
           type yang:dotted-quad;
           mandatory true;
           description
             "Link State ID.";
         }

         leaf opaque-type {
           type uint8;
           description
             "Тип Opaque-LSA.";
         }

         leaf opaque-id {
           type opaque-id;
           description
             "Opaque-LSA ID.";
         }

         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPFv2 LSA.";
         uses ospfv2-lsa-body;
       }
     }

     grouping ospfv3-lsa {
       description
         "Декодированный анонс OSPFv3 LSA.";
       container header {
         description
           "Декодированные данные заголовка OSPFv3 LSA.";
         leaf lsa-id {
           type uint32;
           mandatory true;
           description
             "OSPFv3 LSA ID.";
         }
         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPF LSA.";
         uses ospfv3-lsa-body;
       }
     }
     grouping lsa-common {
       description
         "Общие поля для представления OSPF LSA.";
       leaf decode-completed {
         type boolean;
         description
           "Тело OSPF LSA было декодировано за исключением
            неизвестных TLV. Типы неизвестных LSA и OSPFv2 Opaque-LSA
            не декодированы. Некорректно сформированные LSA обычно не
            воспринимаются м не включаются в LSDB.";
       }
       leaf raw-data {
         type yang:hex-string;
         description
           "Шестнадцатеричное представление полного анонса LSA, как
            он получен или передан, с сетевым порядком байтов.";
       }
     }

     grouping lsa {
       description
         "OSPF LSA.";
       uses lsa-common;
       choice version {
         description
           "Тело OSPFv2 или OSPFv3 LSA.";
         container ospfv2 {
           description
             "OSPFv2 LSA.";
           uses ospfv2-lsa;
         }
         container ospfv3 {
           description
             "OSPFv3 LSA.";
           uses ospfv3-lsa;
         }
       }
     }

     grouping lsa-key {
       description
         "Ключ OSPF LSA. Ключ базы данных для каждого анонса LSA данного
          типа в базе LSDB.";
       leaf lsa-id {
         type union {
           type yang:dotted-quad;
           type uint32;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий маршрутизатор.";
       }
     }

     grouping instance-stat {
       description
         "Статистика для экземпляра.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого экземпляра OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации экземпляра OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании экземпляра OSPF.";
       }
       leaf originate-new-lsa-count {
         type yang:counter32;
         description
           "Число созданных LSA. Разрыв этого счётчика может происходить
            при реинициализации экземпляра OSPF.";
       }
       leaf rx-new-lsas-count {
         type yang:counter32;
         description
           "Число принятых новых LSA.  Разрыв этого счётчика может
            происходить при реинициализации экземпляра OSPF.";
       }
       leaf as-scope-lsa-count {
         type yang:gauge32;
         description
           "Число AS-Scope LSA.";
       }
       leaf as-scope-lsa-chksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для AS-Scope LSA.
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA,
            эквивалентные контрольные суммы не гарантируют совпадения
            LSA, поскольку разные комбинации могут давать одну
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики на уровне AS-Scope LSA.";
         list as-scope-lsa-type {
           description
             "Список статистики AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип AS-Scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
       uses instance-fast-reroute-state;
     }

     grouping area-stat {
       description
         "Per-area statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этой области OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации области OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании области OSPF.";
       }
       leaf spf-runs-count {
         type yang:counter32;
         description
           "Число запусков внутриобластного алгоритма SPF. Разрыв этого
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf abr-count {
         type yang:gauge32;
         description
           "Число доступных в области граничных маршрутизаторов (ABR).";
       }
       leaf asbr-count {
         type yang:gauge32;
         description
           "Общее число граничных маршрутизаторов AS (ASBR), доступных
            внутри этой области.";
       }
       leaf ar-nssa-translator-event-count {
         type yang:counter32;
         description
           "Общее число изменения состояния транслятора NSSA. Разрыв 
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf area-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Area-scope LSA в области.";
       }
       leaf area-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Area-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Area-scope LSA.";
         list area-scope-lsa-type {
           description
             "Список статистики Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Area-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping interface-stat {
       description
         "Per-interface statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого интерфейса OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации интерфейса OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании интерфейса OSPF.";
       }
       leaf if-event-count {
         type yang:counter32;
         description
           "Число изменений состояния интерфейса или ошибок на нем.
            Разрыв счётчика может возникать при реинициализации
            интерфейса OSPF.";
       }
       leaf link-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Link-scope LSA.";
       }
       leaf link-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Link-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Link-scope LSA.";
         list link-scope-lsa-type {
           description
             "Список статистики Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Link-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping neighbor-stat {
       description
         "Статистика на уровне соседа.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            для этого соседа OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации соседа OSPF,
            узел содержит время инициализации, которое обычно происходит
            при динамическом обнаружении соседа OSPF.";
       }
       leaf nbr-event-count {
         type yang:counter32;
         description
           "Число изменений состояния соседа или ошибок для него.
            Разрыв счётчика может возникать при реинициализации
            соседа OSPF.";
       }
       leaf nbr-retrans-qlen {
         type yang:gauge32;
         description
           "Текущий размер очереди на повтор передачи.";
       }
     }

     grouping instance-fast-reroute-config {
       description
         "Эта группа задаёт глобальную конфигурацию 
          IP Fast Reroute (IP-FRR).";
       container fast-reroute {
         if-feature "fast-reroute";
         description
           "Этот контейнер может дополняться глобальными параметрами
            для IP-FRR.";
         container lfa {
           if-feature "lfa";
           description
             "Этот контейнер может дополняться глобальными параметрами
              для Loop-Free Alternate (LFA). Создание контейнера не
              влияет на активацию LFA.";
         }
       }
     }

     grouping instance-fast-reroute-state {
       description
         "Группировка данных состояния IP-FRR.";

       container protected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Статистика защиты экземпляра.";

         list address-family-stats {
           key "address-family prefix alternate";
           description
             "Сведения о защищённом префиксе на семейство адресов.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Защищённый префикс.";
           }
           leaf alternate {
             type inet:ip-address;
             description
               "Другой next-hop для префикса.";
           }
           leaf alternate-type {
             type enumeration {
               enum equal-cost {
                 description
                   "Вариант на основе ECMP.";
               }
               enum lfa {
                 description
                   "Вариант на основе LFA.";
               }
               enum remote-lfa {
                 description
                   "Вариант на основе Remote-LFA.";
               }
               enum tunnel {
                 description
                   "Вариант на основе туннеля (RSVP-TE или GRE).";
               }
               enum ti-lfa {
                 description
                   "Вариант на основе TI-LFA.";
               }
               enum mrt {
                 description
                   "Вариант на основе MRT.";
               }
               enum other {
                 description
                   "Вариант неизвестного типа.";
               }
             }
             description
               "Тип варианта.";
           }
           leaf best {
             type boolean;
             description
               "Указывает предпочтительность этого варианта.";
           }
           leaf non-best-reason {
             type string {
               length "1..255";
             }
             description
               "Описывает причину того, что вариант не является
                лучшим выбором.";
           }
           leaf protection-available {
             type bits {
               bit node-protect {
                 position 0;
                 description
                   "Доступна защита узла.";
               }
               bit link-protect {
                 position 1;
                 description
                   "Доступна защита канала.";
               }
               bit srlg-protect {
                 position 2;
                 description
                   "Доступна защита SRLG.";
               }
               bit downstream-protect {
                 position 3;
                 description
                   "Доступна защита нисходящего направления.";
               }
               bit other {
                 position 4;
                 description
                   "Доступна иная защита.";
               }
             }
             description
               "Защита обеспечивается вариантом (альтернативой).";
           }
           leaf alternate-metric-1 {
             type uint32;
             description
               "Метрика от точки локального ремонта (PLR) до адресата
                по альтернативному пути.";
           }
           leaf alternate-metric-2 {
             type uint32;
             description
               "Метрика от PLR до альтернативного узла.";
           }
           leaf alternate-metric-3 {
             type uint32;
             description
               "Метрика от альтернативного узла до адресата.";
           }
         }
       }

       container unprotected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Список незащищённых префиксов.";

         list address-family-stats {
           key "address-family prefix";
           description
             "Статистика незащищённых префиксов на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Незащищённый префикс.";
           }
         }
       }

       list protection-statistics {
         key "frr-protection-method";
         config false;
         description
           "Список статистики методов защиты.";

         leaf frr-protection-method {
           type string;
           description
             "Используемый метод защиты.";
         }
         list address-family-stats {
           key "address-family";
           description
             "Статистика защиты на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf total-routes {
             type uint32;
             description
               "Общее число префиксов.";
           }
           leaf unprotected-routes {
             type uint32;
             description
               "Общее число незащищённых префиксов.";
           }
           leaf protected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
           leaf linkprotected-routes {
             type uint32;
             description
               "Общее число префиксов с защитой канала.";
           }
           leaf nodeprotected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
         }
       }
     }

     grouping interface-fast-reroute-config {
       description
         "Эта группа определяет конфигурацию интерфейса IP-FRR.";
       container fast-reroute {
         if-feature "fast-reroute";
         container lfa {
           if-feature "lfa";
           leaf candidate-enabled {
             type boolean;
             default "true";
             description
               "Разрешает применять интерфейс как резервный.";
           }
           leaf enabled {
             type boolean;
             default "false";
             description
               "Активирует LFA. Предполагается расчёт LFA на префикс.";
           }
           container remote-lfa {
             if-feature "remote-lfa";
             leaf enabled {
               type boolean;
               default "false";
               description
                 "Активирует Remote LFA (R-LFA).";
             }
             description
               "Конфигурация R-LFA.";
           }
           description
             "Конфигурация LFA.";
         }
         description
           "Конфигурация интерфейса IP-FRR.";
       }
     }

     grouping interface-physical-link-config {
       description
         "Конфигурация стоимости интерфейса, применяемая только к
          физическим (не виртуальным) интерфейсам и и sham-каналам.";
       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса.";
       }
       leaf mtu-ignore {
         if-feature "mtu-ignore";
         type boolean;
         description
           "Управляет обходом проверки несоответствия MTU для пакетов
            Database Description (параграф 10.6 в RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2, Section 10.6";
       }
       leaf prefix-suppression {
         if-feature "prefix-suppression";
         type boolean;
         description
           "Подавляет анонсы префиксов, связанных с интерфейсом.";
       }
     }

     grouping interface-common-config {
       description
         "Общая конфигурация для всех типов интерфейсов, включая
          виртуальные и sham-каналы (фиктивные).";

       leaf hello-interval {
         type uint16;
         units "seconds";
         description
           "Интервал между пакетами Hello (в секундах), который должен
            совпадать для всех маршрутизаторов в одной сети. Разные
            реализации и развёртывания применяют разные интервалы Hello.
            Примером значения для ЛВС служит интервал в 10 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf dead-interval {
         type uint16;
         units "seconds";
         must '../dead-interval > ../hello-interval' {
           error-message "Интервал «умирания» (dead) должен быть "
                       + "больше интервала Hello";
           description
             "Значение должно быть больше hello-interval.";
         }
         description
           "Интервал, после которого сосед считается отключённым 
            (в секундах), если от него нет пакетов Hello. Обычно это
            в 3 - 4 раза больше hello-interval. Типовое значение для
            ЛВС составляет 40 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf retransmit-interval {
         type uint16 {
           range "1..3600";
         }
         units "seconds";
         description
           "Интервал повтора неподтвержденных анонсов LSA (в секундах).
            Значение должно быть больше RTT между любыми двумя 
            маршрутизаторами в сети. Примером служит значение 5 сек.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf transmit-delay {
         type uint16;
         units "seconds";
         description
           "Оценка времени передачи пакетов обновления состояния канала
            (LSU) на интерфейсе (в секундах). Возраст LSA увеличивается
            на это значение при анонсировании через интерфейс. Примером
            значения является 1 секунда.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf lls {
         if-feature "lls";
         type boolean;
         description
           "Управляет поддержкой сигнализации LLS.";
       }

       container ttl-security {
         if-feature "ttl-security";
         description
           "Проверка безопасности TTL.";
         leaf enabled {
           type boolean;
           description
             "Управляет проверкой безопасности TTL.";
         }
         leaf hops {
           type uint8 {
             range "1..254";
           }
           default "1";
           description
             "Максимальное число пересылок (hop), которые пакет OSPF
              может пройти до получения.";
         }
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Управляет протоколом OSPF на интерфейсе.";
       }

       container authentication {
         description
           "Конфигурация проверки подлинности.";
         choice auth-type-selection {
           description
             "Опции для настройки аутентификации OSPFv2/OSPFv3.";
           case ospfv2-auth {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv2')" {
               description
                 "Применимо только к OSPFv2.";
             }
             leaf ospfv2-auth-trailer-rfc {
               if-feature "ospfv2-authentication-trailer";
               type ospfv2-auth-trailer-rfc-version;
               description
                 "Поддержка трейлера аутентификации OSPFv2 (RFC 5709
                  и RFC 7474).";
               reference
                 "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
                  RFC 7474: Security Extension for OSPFv2 When Using
                  Manual Key Management";
             }
             choice ospfv2-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv2-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv2-key-id {
                   type uint32;
                   description
                     "Идентификатор ключа.";
                 }
                 leaf ospfv2-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv2. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv2-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
           case ospfv3-auth-ipsec {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-ipsec";
             leaf sa {
               type string;
               description
                 "Имя защищённой связи (SA).";
             }
           }
           case ospfv3-auth-trailer {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-trailer";
             choice ospfv3-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv3-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv3-sa-id {
                   type uint16;
                   description
                 "Имя защищённой связи (SA).";
                 }
                 leaf ospfv3-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv3. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv3-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-config {
       description
         "Конфигурация для обычных интерфейсов OSPF (не виртуальных
          или фиктивных - sham).";

       leaf interface-type {
         type enumeration {
           enum broadcast {
             description
               "Широковещательная сеть с множественным доступом.";
           }
           enum non-broadcast {
             description
               "Сеть с множественным доступом без широковещания (NBMA).";
           }
           enum point-to-multipoint {
             description
               "Сеть «один со многими» (point-to-multipoint).";
           }
           enum point-to-point {
             description
                "Сеть «точка-точка».";
              "Specifies an OSPF point-to-point network.";
           }
           enum hybrid {
             if-feature "hybrid-interface";
             description
               "Гибридная сеть (широковещание/point-to-multipoint).";
           }
         }
         description
           "Тип интерфейса.";
       }

       leaf passive {
         type boolean;
         description
           "Управляет пассивным интерфейсом. Префикс пассивного
            интерфейса анонсируется, но смежность не создается.";
       }

       leaf demand-circuit {
         if-feature "demand-circuit";
         type boolean;
         description
           "Управляет demand-устройством.";
       }

       leaf priority {
         type uint8;
         description
           "Задаёт приоритет маршрутизатора OSPF. В сети с множественным
            доступом это служит для выбора DR. На интерфейсах других
            типов приоритет игнорируется. Маршрутизатор с высоким 
            приоритетом предпочитается при выборе. Значение 0 указывает,
            что маршрутизатору нежелательно быть DR или BDR.";
       }

       container multi-areas {
         if-feature "multi-area-adj";
         description
           "Контейнер для конфигурации с множеством областей.";
         list multi-area {
           key "multi-area-id";
           description
             "Настраивает смежность между областями OSPF.";
           leaf multi-area-id {
             type area-id-type;
             description
               "Идентификатор области для смежности областей.";
           }
           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса для смежности областей.";
           }
         }
       }

       container static-neighbors {
         description
           "Статически заданные соседи.";

         list neighbor {
           key "identifier";
           description
             "Статически заданный сосед OSPF.";

           leaf identifier {
             type inet:ip-address;
             description
               "Router ID, адрес IPv4 или IPv6 у соседа.";
           }

           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса. Разные реализации по умолчанию 
                задают разную стоимость, при этом у некоторых стоимость
                обратно пропорциональная значения. Некоторые задают по
                умолчанию 1, считая стоимостью число пересылок (hop).";
           }
           leaf poll-interval {
             type uint16;
             units "seconds";
             description
               "Интервал опроса (в секундах) для отправки пакетов
                OSPF Hello с целью обнаружения соседей в сети NBMA.
                Этот интервал задаёт детализацию поиска новых соседей.
                Примером может служить интервал 120 секунд (2 минуты)
                для унаследованных пакетных сетей (PDN) X.25.";
             reference
               "RFC 2328: OSPF Version 2, Appendix C.5";
           }
           leaf priority {
             type uint8;
             description
               "Приоритет соседа при выборе DR. Маршрутизатор с высоким 
                приоритетом предпочитается при выборе, 0, указывает,
                что маршрутизатору нежелательно быть DR или BDR.";
           }
         }
       }

       leaf node-flag {
         if-feature "node-flag";
         type boolean;
         default "false";
         description
           "Набор префиксов, указывающих анонсирующий маршрутизатор.";
         reference
           "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
       }

       container bfd {
         if-feature "bfd";
         description
           "Конфигурация интерфейса BFD.";
         uses bfd-types:client-cfg-parms;
         reference
           "RFC 5880: Bidirectional Forwarding Detection (BFD)
            RFC 5881: Bidirectional Forwarding Detection
            (BFD) for IPv4 and IPv6 (Single Hop)
            RFC 9314: YANG Data Model for Bidirectional Forwarding
            Detection (BFD)";
       }

       uses interface-fast-reroute-config;
       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping neighbor-state {
       description
         "Рабочее состояние соседа OSPF.";

       leaf address {
         type inet:ip-address;
         config false;
         description
           "Адрес соседа.";
       }
       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "Router ID у DR соседа.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у DR соседа.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
          "Router ID у BDR соседа.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у BDR соседа.";
       }
       leaf state {
         type nbr-state-type;
         config false;
         description
           "Состояние соседа OSPF.";
       }
       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость доступа к соседу для сетей point-to-multipoint
            и Hybrid.";
       }
       leaf dead-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента, когда
            сосед будет сочтён «мертвым».";
       }
       container statistics {
         config false;
         description
           "Статистика для соседа.";
         uses neighbor-stat;
       }
     }

     grouping interface-common-state {
       description
         "Базовое рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       leaf state {
         type if-state-type;
         config false;
         description
           "Состояние интерфейса.";
       }

       leaf hello-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента отправки
            через интерфейс следующего сообщения Hello.";
       }

       leaf wait-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента выхода
            интерфейса из состояния Waiting.";
       }

       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "DR Router ID.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес DR.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
           "BDR Router ID.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес BDR.";
       }

       container statistics {
         config false;
         description
           "Статистика для интерфейса.";
         uses interface-stat;
       }

       container neighbors {
         config false;
         description
           "Все соседи на интерфейсе.";
         list neighbor {
           key "neighbor-router-id";
           description
             "Список соседей OSPF на интерфейсе.";
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
           uses neighbor-state;
         }
       }
       container database {
         config false;
         description
           "Link-scope LSDB.";
         list link-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Link-scope LSA.";
           }
           container link-scope-lsas {
             description
               "Все Link-scope LSA этого типа.";
             list link-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Link-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-state {
       description
         "Рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       uses interface-common-state;
     }

     grouping virtual-link-config {
       description
         "Состояние конфигурации виртуального канала OSPF.";

       uses interface-common-config;
     }

     grouping virtual-link-state {
       description
         "Рабочее состояние виртуального канала OSPF.";

       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость интерфейса виртуального канала.";
       }
       uses interface-common-state;
     }

     grouping sham-link-config {
       description
         "Состояние конфигурации фиктивного канала OSPF.";

       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping sham-link-state {
       description
         "Рабочее состояние фиктивного канала OSPF.";
       uses interface-common-state;
     }

     grouping address-family-area-config {
       description
         "Состояние конфигурации области OSPF для семейства адресов.";

       container ranges {
         description
           "Контейнер для сводных (summary) диапазонов.";

         list range {
           key "prefix";
           description
             "Сводка маршрутов, соответствующих адресу и маске.
              Применима лишь для маршрутизаторов ABR.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс IPv4 или IPv6.";
           }
           leaf advertise {
             type boolean;
             description
               "Аносируется или скрыт.";
           }
           leaf cost {
             type ospf-metric;
             description
               "Анонсируемая стоимость сводного маршрута.";
           }
         }
       }
     }

     grouping area-common-config {
       description
         "Базовое состояние конфигурации области OSPF.";

       leaf summary {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет анонсами в тупиковые области или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Стоимость LSA принятого по умолчанию маршрута,
              анонсируемого у тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводную стоимость маршрута по умолчанию для
            тупиковой области или NSSA.";
       }
     }

     grouping area-config {
       description
         "Состояние конфигурации области OSPF.";

       leaf area-type {
         type identityref {
           base area-type;
         }
         default "normal-area";
         description
           "Тип области.";
       }

       uses area-common-config;
       uses address-family-area-config;
     }

     grouping area-state {
       description
         "Рабочее состояние области OSPF.";

       container statistics {
         config false;
         description
           "Статистика для области.";
         uses area-stat;
       }

       container database {
         config false;
         description
           "Area-scope LSDB.";
         list area-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Area-scope LSA.";
           }
           container area-scope-lsas {
             description
               "Все Area-scope LSA.";
             list area-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Area-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping local-rib {
       description
         "Локальная таблица RIB для маршрутов, рассчитанных
          локальным экземпляром маршрутизации OSPF.";
       container local-rib {
         config false;
         description
           "Local RIB.";
         list route {
           key "prefix";
           description
             "Локальные маршруты экземпляра OSPF.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс адресата.";
           }
           container next-hops {
             description
               "Следующие узлы (next-hop) для маршрута.";
             list next-hop {
               description
                 "Список next-hop для маршрута.";
               leaf outgoing-interface {
                 type if:interface-ref;
                 description
                   "Имя выходного интерфейса.";
               }
               leaf next-hop {
                 type inet:ip-address;
                 description
                   "Адрес next-hop.";
               }
             }
           }
           leaf metric {
             type uint32;
             description
               "Метрика маршрута.";
           }
           leaf route-type {
             type route-type;
             description
               "Тип маршрута.";
           }
           leaf route-tag {
             type uint32;
             description
               "Тег для маршрута.";
           }
         }
       }
     }

     grouping ietf-spf-delay {
       leaf initial-delay {
         type uint32;
         units "milliseconds";
         default "50";
         description
           "Задержка, применяемая в состоянии QUIET (мсек).";
       }
       leaf short-delay {
         type uint32;
         units "milliseconds";
         default "200";
         description
           "Задержка, применяемая в состоянии SHORT_WAIT (мсек).";
       }
       leaf long-delay {
         type uint32;
         units "milliseconds";
         default "5000";
         description
           "Задержка, применяемая в состоянии LONG_WAIT (мсек).";
       }
       leaf hold-down {
         type uint32;
         units "milliseconds";
         default "10000";
         description
           "Таймер для интервала без изменений, когда IGP
            считается стабильным (мсек).";
       }
       leaf time-to-learn {
         type uint32;
         units "milliseconds";
         default "500";
         description
           "Продолжительность изучения всех событий IGP, относящихся
            к одному сетевому событию (мсек).";
       }
       leaf current-state {
         type enumeration {
           enum quiet {
             description
               "Состояние QUIET.";
           }
           enum short-wait {
             description
               "Состояние SHORT_WAIT.";
           }
           enum long-wait {
             description
               "Состояние LONG_WAIT.";
           }
         }
         config false;
         description
           "Текущее состояние алгоритма отсрочки SPF (back-off).";
       }
       leaf remaining-time-to-learn {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения time-to-learn.";
       }
       leaf remaining-hold-down {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения hold-down.";
       }
       leaf last-event-received {
         type yang:timestamp;
         config false;
         description
           "Время последнего события-триггера SPF.";
       }
       leaf next-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время следующего запланированного SPF.";
       }
       leaf last-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время последнего расчёта SPF.";
       }
       description
         "Группировка для конфигурации и состояния задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     grouping node-tag-config {
       description
         "Состояние конфигурации тега узла OSPF.";
       container node-tags {
         if-feature "node-tag";
         list node-tag {
           key "tag";
           leaf tag {
             type uint32;
             description
               "Значение тега узла.";
           }
           description
             "Список тегов узлов.";
         }
         description
           "Контейнер для административных тегов узла.";
       }
     }

     grouping instance-config {
       description
         "Состояние конфигурации экземпляра OSPF.";

       leaf enabled {
         type boolean;
         default "true";
         description
           "Включает и выключает протокол.";
       }

       leaf explicit-router-id {
         if-feature "explicit-router-id";
         type rt-types:router-id;
         description
           "Уникальный 32-битовый идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       container preference {
         description
           "Конфигурация предпочтений для маршрутизатора. Во многих
            реализациях называется административной дистанцией.";
         reference
           "RFC 8349: A YANG Data Model for Routing Management
            (NMDA Version)";
         choice scope {
           description
             "Опции выражения предпочтений одним или несколькими
              значениями.";
           case single-value {
             leaf all {
               type uint8;
               description
                 "Предпочтение для внутриобластных, межобластных
                  и внешних маршрутов.";
             }
           }
           case multi-values {
             choice granularity {
               description
                 "Опции для указания предпочтений внутриобластных
                  и межобластных маршрутов.";
               case detail {
                 leaf intra-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри области.";
                 }
                 leaf inter-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов между областями.";
                 }
               }
               case coarse {
                 leaf internal {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри и между 
                      областями.";
                 }
               }
             }
             leaf external {
               type uint8;
               description
                 "Предпочтение для маршрутов внешних AS и NSSA.";
             }
           }
         }
       }

       container nsr {
         if-feature "nsr";
         description
           "Состояние настройки безостановочной маршрутизации (NSR).";
         leaf enabled {
           type boolean;
           description
             "Включает и выключает NSR.";
         }
       }

       container graceful-restart {
         if-feature "graceful-restart";
         description
           "Состояние конфигурации аккуратного перезапуска.";
         reference
           "RFC 3623: Graceful OSPF Restart
            RFC 5187: OSPFv3 Graceful Restart";
         leaf enabled {
           type boolean;
           description
             "Управляет аккуратным перезапуском (RFC 3623 для
              OSPFv2 и RFC 5187 для OSPFv3).";
         }
         leaf helper-enabled {
           type boolean;
           description
             "Включает поддержку помощника при аккуратном перезапуске
              маршрутизаторов (раздел 3 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Section 3";
         }
         leaf restart-interval {
           type uint16 {
             range "1..1800";
           }
           units "seconds";
           default "120";
           description
             "Интервал попыток аккуратного перезапуска (в секундах)
              до отказа (Приложение B.1 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.1";
         }
         leaf helper-strict-lsa-checking {
           type boolean;
           description
             "Прерывает аккуратный перезапуск при смене топологии LSA
              (Приложение B.2 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.2";
         }
       }

       container auto-cost {
         if-feature "auto-cost";
         description
           "Состояние автоматического расчёта стоимости интерфейса.";
         leaf enabled {
           type boolean;
           description
             "Управляет автоматическим расчётом стоимости интерфейса.";
         }
         leaf reference-bandwidth {
           when "../enabled = 'true'" {
             description
               "Применимо лишь при автоматическом расчёте стоимости.";
           }
           type uint32 {
             range "1..4294967";
           }
           units "Mbits";
           description
             "Эталонная пропускная способность для автоматического
              расчёта стоимости интерфейса (Мбит/с). Это значение
              делится на скорость интерфейса и 1 указывает
              минимальную стоимость.";
         }
       }

       container spf-control {
         leaf paths {
           if-feature "max-ecmp";
           type uint16 {
             range "1..65535";
           }
           description
             "Максимальное число равноценных путей (ECMP).";
         }
         container ietf-spf-delay {
           if-feature "ietf-spf-delay";
           uses ietf-spf-delay;
           description
             "Конфигурация алгоритма задержки IETF SPF.";
         }
         description
           "Управление расчётом SPF.";
       }

       container database-control {
         leaf max-lsa {
           if-feature "max-lsa";
           type uint32 {
             range "1..4294967294";
           }
           description
             "Максимальное число OSPF LSA, принимаемых маршрутизатором";
         }
         description
           "Управление поддержкой базы данных.";
       }

       container stub-router {
         if-feature "stub-router";
         description
           "Задаёт конфигурацию максимальной метрики.";

         choice trigger {
           description
             "Триггеры, разрешающие состояние маршрутизатора-заглушки.";
           container always {
             presence "Разрешает безусловную поддержку stub router.";
             description
               "Безусловное состояние stub router (анонсы транзитных
                каналов с MaxLinkMetric).";
             reference
               "RFC 6987: OSPF Stub Router Advertisement";
           }
         }
       }

       container mpls {
         description
           "Состояние конфигурации OSPF MPLS.";
         container te-rid {
           if-feature "te-rid";
           description
             "Стабильный IP-адрес маршрутизатора OSPF для TE.";
           leaf ipv4-router-id {
             type inet:ipv4-address;
             description
               "Явно заданный TE IPv4 Router ID.";
           }
           leaf ipv6-router-id {
             type inet:ipv6-address;
             description
               "Явно заданный TE IPv6 Router ID.";
           }
         }
         container ldp {
           description
             "Состояние конфигурации OSPF MPLS LDP.";
           leaf igp-sync {
             if-feature "ldp-igp-sync";
             type boolean;
             description
               "Включает синхронизацию LDP IGP.";
           }
         }
       }
       uses instance-fast-reroute-config;
       uses node-tag-config;
     }

     grouping instance-state {
       description
         "Рабочее состояние экземпляра OSPF.";

       leaf router-id {
         type rt-types:router-id;
         config false;
         description
           "32-битовый уникальный идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       uses local-rib;

       container statistics {
         config false;
         description
           "Статистика для экземпляра.";
         uses instance-stat;
       }

       container database {
         config false;
         description
           "AS-Scope LSDB.";
         list as-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF AS-Scope LSA.";
           }
           container as-scope-lsas {
             description
               "Все AS-Scope LSA этого типа.";
             list as-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF AS-Scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
       uses spf-log;
       uses lsa-log;
     }

     grouping multi-topology-area-common-config {
       description
         "Базовое состояние конфигурации области OSPF с несколькими 
          топологиями.";
       leaf summary {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет сводными анонсами в топологию тупиковой области
            или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Стоимость для LSA маршрута по умолчанию, анонсируемого 
              в тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводный маршрут по умолчанию для тупиковой области
            или NSSA.";
       }
     }

     grouping multi-topology-area-config {
       description
         "Состояние конфигурации области OSPF с разными топологиями.";

       uses multi-topology-area-common-config;
       uses address-family-area-config;
     }

     grouping multi-topology-state {
       description
         "Рабочее состояние OSPF с несколькими топологиями.";

       uses local-rib;
     }

     grouping multi-topology-interface-config {
       description
         "Состояние конфигурации OSPF с несколькими топологиями.";

       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса для этой топологии.";
       }
     }

     grouping ospfv3-interface-config {
       description
         "Связанное с интерфейсом состояние конфигурации OSPFv3.";

       leaf instance-id {
         type uint8;
         default "0";
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping ospfv3-interface-state {
       description
         "Связанное с интерфейсом рабочее состояние OSPFv3.";

       leaf interface-id {
         type uint32;
         config false;
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping lsa-identifiers {
       description
         "Параметры, однозначно указывающие LSA.";
       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }
       leaf type {
         type uint16;
         description
           "Тип LSA.";
       }
       leaf lsa-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         description
           "Порядковый номер LSA.";
       }
     }

     grouping spf-log {
       description
         "Группировка для журнальных записей SPF (log).";
       container spf-log {
         config false;
         description
           "Контейнер с записями SPF.";
         list event {
           key "id";
           description
             "Список записей SPF в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо внутреннее значение).";
           }
           leaf spf-type {
             type enumeration {
               enum full {
                 description
                   "Расчёт SPF был выполнен для всего SPF.";
               }
               enum intra {
                 description
                   "Расчёт SPF лишь для маршрутов внутри области.";
               }
               enum inter {
                 description
                   "Расчёт SPF для сводных маршрутов между областями.";
               }
               enum external {
                 description
                   "Расчёт SPF лишь для маршрутов внешних AS и NSSA.";
               }
             }
             description
               "Расчёт SPF лишь для для записи журнала SPF.";
           }
           leaf schedule-timestamp {
             type yang:timestamp;
             description
               "Временная метка для запланированного расчёта.";
           }
           leaf start-timestamp {
             type yang:timestamp;
             description
               "Временная метка начала расчёта.";
           }
           leaf end-timestamp {
             type yang:timestamp;
             description
               "Временная метка завершения расчёта.";
           }
           list trigger-lsa {
             description
               "Список LSA, вызвавших расчёт.";
             uses lsa-identifiers;
           }
         }
       }
     }

     grouping lsa-log {
       description
         "Группировка для системного журнала LSA (log).";
       container lsa-log {
         config false;
         description
           "Контейнер со списком записей журнала LSA, включая локальные
            изменения LSA.";
         list event {
           key "id";
           description
             "Список записей LSA в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо локальное значение).";
           }
           container lsa {
             description
               "Контейнер, описывающий LSA, записанные в журнал.";
             uses lsa-identifiers;
           }
           leaf received-timestamp {
             type yang:timestamp;
             description
               "Временная метка получения LSA. При локальном обновлении
                LSA это будет время создания LSA.";
           }
           leaf reason {
             type identityref {
               base lsa-log-reason;
             }
             description
               "Причина внесения записи в журнал LSA.";
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol" {
       when "derived-from(rt:type, 'ospf')" {
         description
           "Это дополнение пригодно лишь для экземпляра протокола
            маршрутизации OSPF (типа ospfv2 или ospfv3).";
       }
       description
         "Дополнение OSPF control-plane-protocol для модуля 
          ietf-routing.";

       container ospf {
         description
           "Экземпляр протокола OSPF.";

         leaf address-family {
           when "derived-from-or-self(../../rt:type, 'ospfv3')" {
             description
               "Применимо только для OSPFv3.";
           }
           type iana-rt-types:address-family;
           description
             "Семейство адресов для экземпляра.";
         }

         uses instance-config;
         uses instance-state;

         container areas {
           description
             "Все области OSPF.";
           list area {
             key "area-id";
             description
               "Список областей OSPF.";
             leaf area-id {
               type area-id-type;
               description
                 "Area ID.";
             }

             uses area-config;
             uses area-state;

             container virtual-links {
               when "derived-from-or-self(../area-type, 'normal-area') "
                  + "and ../area-id = '0.0.0.0'" {
                 description
                   "Виртуальные каналы должны быть в магистральной 
                    (backbone) области.";
               }
               description
                 "Все виртуальные каналы.";
               list virtual-link {
                 key "transit-area-id router-id";
                 description
                   "Виртуальный канал OSPF.";
                 leaf transit-area-id {
                   type leafref {
                     path "../../../../area/area-id";
                   }
                   must "derived-from-or-self("
                      + "../../../../area[area-id=current()]"
                      + "/area-type, 'normal-area') and "
                      + "../../../../area[area-id=current()]"
                      + "/area-id != '0.0.0.0'" {
                     error-message "Транзитной области виртуального "
                             + "канала недопустимо быть магистральной.";
                     description
                       "Транзитной области виртуального канала 
                        недопустимо быть магистральной (0.0.0.0).";
                   }
                   description
                     "Идентификатор транзитной области виртуального 
                      канала.";
                 }
                 leaf router-id {
                   type rt-types:router-id;
                   description
                     "Router ID удалённой конечной точки виртуального
                      канала.";
                 }

                 uses virtual-link-config;
                 uses virtual-link-state;
               }
             }
             container sham-links {
               if-feature "pe-ce-protocol";
               description
                 "Все фиктивные (sham) каналы.";
               list sham-link {
                 key "local-id remote-id";
                 description
                   "Фиктивный канал OSPF.";
                 leaf local-id {
                   type inet:ip-address;
                   description
                     "Адрес локальной конечной точки фиктивного канала";
                 }
                 leaf remote-id {
                   type inet:ip-address;
                   description
                     "Адрес удалённой конечной точки фиктивного канала";
                 }
                 uses sham-link-config;
                 uses sham-link-state;
               }
             }
             container interfaces {
               description
                 "Все интерфейсы OSPF.";
               list interface {
                 key "name";
                 description
                   "Список интерфейсов OSPF.";
                 leaf name {
                   type if:interface-ref;
                   description
                     "Ссылка на имя интерфейса.";
                 }
                 uses interface-config;
                 uses interface-state;
               }
             }
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf" {
       when "derived-from(../rt:type, 'ospf')" {
         description
           "Это дополнение действительно лишь для OSPF
            (тип ospfv2 или ospfv3).";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации экземпляра OSPF
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии.";
         list topology {
           key "name";
           description
             "Топология OSPF. Семейство адресов топологии OSPF 
              должно совпадать с семейством экземпляра маршрутизации.";
           leaf name {
             type leafref {
               path "../../../../../../rt:ribs/rt:rib/rt:name";
             }
             description
               "Имя таблицы RIB, соответствующей топологии OSPF.";
           }

           uses multi-topology-state;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area" {
       when "derived-from-or-self(../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации области OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для области.";
         list topology {
           key "name";
           description
             "Топология области OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этой области.";
           }

           uses multi-topology-area-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации интерфейса OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для интерфейса.";
         list topology {
           key "name";
           description
             "Топология для интерфейса OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этого интерфейса.";
           }

           uses multi-topology-interface-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv3')" {
         description
           "Это дополнение действительно лишь для OSPFv3.";
       }
       description
         "Дополнение состояния конфигурации OSPFv3, связанной 
          с интерфейсом.";
       uses ospfv3-interface-config;
       uses ospfv3-interface-state;
     }

     grouping route-content {
       description
         "Эта группировка определяет атрибуты маршрута,
          связанные с OSPF.";
       leaf metric {
         type uint32;
         description
           "Метрика маршрута OSPF.";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Тег маршрута OSPF.";
       }
       leaf route-type {
         type route-type;
         description
           "Тип маршрута OSPF.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
       when "derived-from(rt:source-protocol, 'ospf')" {
         description
           "Это дополнение действительно лишь для маршрутов,
            полученных от протокола OSPF.";
       }
       description
         "Связанные с OSPF атрибуты маршрута.";
       uses route-content;
     }

     /*
      * RPC
      */

     rpc clear-neighbor {
       description
         "Этот вызов RPC очищает указанный набор соседей OSPF.
          При отказе по внутренним причинам OSPF следует возвращать
          error-tag и error-app-tag, соответствующие ошибке.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }

         leaf interface {
           type if:interface-ref;
           description
             "Имя экземпляра OSPF, для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag ospf-interface-not-found.";
         }
       }
     }

     rpc clear-database {
       description
         "Этот вызов RPC очищает указанную базу OSPF Link State. Кроме 
          того, все отношения соседства переводятся в состояние DOWN,
          а самосозданные LSA реорганизуются. При отказе операции по
          внутренним причинам OSPF следует указывать причину в error-tag
          и error-app-tag.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF, для которого очищается LSDB.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }
       }
     }

     /*
      * Уведомления
      */

     grouping notification-instance-hdr {
       description
         "Группировка с описаниями связанных с экземпляром общих
          уведомления OSPF.";

       leaf routing-protocol-name {
         type leafref {
           path "/rt:routing/rt:control-plane-protocols/"
              + "rt:control-plane-protocol/rt:name";
         }
         must "derived-from( "
            + "/rt:routing/rt:control-plane-protocols/"
            + "rt:control-plane-protocol[rt:name=current()]/"
            + "rt:type, 'ospf')";
         description
           "Имя экземпляра протокола маршрутизации OSPF.";
       }

       leaf address-family {
         type leafref {
           path "/rt:routing/"
              + "rt:control-plane-protocols/rt:control-plane-protocol"
              + "[rt:name=current()/../routing-protocol-name]/"
              + "ospf/address-family";
         }
         description
           "Семейство адресов экземпляра OSPF.";
       }
     }

     grouping notification-interface {
       description
         "Группировка для сведений об интерфейсе в связанных с
          интерфейсами уведомлениях OSPF.";

       choice if-link-type-selection {
         description
           "Варианты типов канала.";
         container interface {
           description
             "Обычный интерфейс.";
           leaf interface {
             type if:interface-ref;
             description
               "Интерфейс.";
           }
         }
         container virtual-link {
           description
             "Виртуальный канал.";
           leaf transit-area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
         }
         container sham-link {
           description
             "Фиктивный канал.";
           leaf area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf local-ip-addr {
             type inet:ip-address;
             description
               "Локальный адрес фиктивного канала.";
           }
           leaf remote-ip-addr {
             type inet:ip-address;
             description
               "Удаленный адрес фиктивного канала.";
           }
         }
       }
     }

     grouping notification-neighbor {
       description
         "Группировка для сведений о соседе в связанных
          с соседями уведомлениях.";

       leaf neighbor-router-id {
         type rt-types:router-id;
         description
           "Router ID соседа.";
       }

       leaf neighbor-ip-addr {
         type inet:ip-address;
         description
           "Адрес соседа.";
       }
     }

     notification if-state-change {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf state {
         type if-state-type;
         description
           "Состояние интерфейса.";
       }
       description
         "Это уведомление передаётся при обнаружении
          смены состояния интерфейса.";
     }

     notification if-config-error {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       leaf error {
         type enumeration {
           enum bad-version {
             description
               "Непригодня версия.";
           }
           enum area-mismatch {
             description
               "Несоответствие областей.";
           }
           enum unknown-nbma-nbr {
             description
               "Неизвестный сосед NBMA.";
           }
           enum unknown-virtual-nbr {
             description
               "Неизвестный сосед по виртуальному каналу.";
           }
           enum auth-type-mismatch {
             description
               "Несоответствие типа аутентификации.";
           }
           enum auth-failure {
             description
               "Отказ при аутентификации.";
           }
           enum net-mask-mismatch {
             description
               "Несоответствие маски сети.";
           }
           enum hello-interval-mismatch {
             description
               "Несоответствие интервала Hello.";
           }
           enum dead-interval-mismatch {
             description
               "Несоответствие интервала Dead.";
           }
           enum option-mismatch {
             description
               "Несоответствие опций.";
           }
           enum mtu-mismatch {
             description
               "Несоответствие MTU.";
           }
           enum duplicate-router-id {
             description
               "Дубликат Router ID.";
           }
           enum no-error {
             description
               "Нет ошибок.";
           }
         }
         description
           "Коды ошибок.";
       }
       description
         "Это уведомление передаётся при получении пакета, указывающего
          ошибку настройки интерфейса передающего маршрутизатора OSPF.";
     }

     notification nbr-state-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf state {
         type nbr-state-type;
         description
           "Состояние соседа.";
       }

       description
         "Это уведомление передаётся при обнаружении смены состояния
          соседа.";
     }

     notification nbr-restart-helper-status-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf status {
         type restart-helper-status-type;
         description
           "Состояние помошника в перезапуске.";
       }

       leaf age {
         type rt-types:timer-value-seconds16;
         description
           "Оставшееся время текущего интервала аккуратного перезапуска
            OSPF, когда маршрутизатор служит помощником для соседа.";
       }

       leaf exit-reason {
         type restart-exit-reason-type;
         description
           "Причина завершения помощника при перезапуске.";
       }
       description
         "Это уведомление передаётся при обнаружении смены состояния
          помощника при перезапуске соседа.";
     }

     notification if-rx-bad-packet {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       description
         "Это уведомление передаётся при невозможности анализа пакета
          OSPF, принятого на интерфейсе OSPF.";
     }

     notification lsdb-approaching-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит 90% от предела ext-lsdb-limit.";
     }

     notification lsdb-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит предел ext-lsdb-limit.";
     }

     notification nssa-translator-status-change {
       uses notification-instance-hdr;

       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }

       leaf status {
         type nssa-translator-state-type;
         description
           "Состояние транслятора NSSA.";
       }

       description
         "Это уведомление передаётся при смене роли маршрутизатора в
          трансляции OSPF NSSA-LSA в OSPF AS-External-LSA.";
     }

     notification restart-status-change {
       uses notification-instance-hdr;

       leaf status {
         type restart-status-type;
         description
           "Состояние перезапуска.";
       }

       leaf restart-interval {
         type uint16 {
           range "1..1800";
         }
         units "seconds";
         default "120";
         description
           "Интервал перезапуска.";
       }

       leaf exit-reason {
         type restart-exit-reason-type;
         description
           "Причина выхода для перезапуска.";
       }

       description
         "Это уведомление передаётся при смене состояния аккуратного
          перезапуска для маршрутизатора.";
     }
   }
   <CODE ENDS>

4. Вопросы безопасности

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/ospf

/ospf/areas/

/ospf/areas/area[area-id]

/ospf/virtual-links/

/ospf/virtual-links/virtual-link[transit-area-id router-id]

/ospf/areas/area[area-id]/interfaces

/ospf/areas/area[area-id]/interfaces/interface[name]

/ospf/area/area[area-id]/sham-links

/ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id]

Доступные для записи узлы данных представляют конфигурацию экземпляров, областей, виртуальных каналов, фиктивных (sham) каналов и интерфейсов и соответствуют указанным выше узлам схемы.

Для OSPF возможность изменения конфигурации позволяет скомпрометировать целиком домен OSPF, включая партнерство с несанкционированными маршрутизаторами для нарушения маршрутизации трафика и организацию массированных атак на службы (Denial-of-Service или DoS). Например, активизация OSPF на любом незащищённом интерфейсе позволить организовать смежность OSPF с несанкционированным и враждебным соседом. После организации смежности возможен перехват трафика. Например, может быть организована DoS-атака путём изменения стоимости интерфейса OSPF с введением асимметрии и возникновением жёсткой петли. Как правило, несанкционированное изменение большинства функций OSPF создаёт свой риск безопасности. Следует обратиться к разделу Security Considerations в соответствующих RFC.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/ospf/database

/ospf/areas/area[area-id]/database

/ospf/virtual-links/virtual-link[transit-area-id router-id]/database

/ospf/areas/area[area-id]/interfaces/interface[name]/database

/ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id]/database

Раскрытие базы состояний каналов (LSDB) будет подробно показывать топологию сети. Имеются отдельные базы LSDB для каждого интерфейса, области, виртуального и фиктивного канала, интерфейса. Соответствующие узлы данных показаны выше.

Раскрытие LSDB включает сведения, выходящие за рамки маршрутизатора OSPF. Это может быть нежелательно, поскольку может приводить к атакам. Кроме того, в случае раскрытия LSDB области можно восстановить целиком топологию IP-сети, а при развёртывании TE – и этой топологии. Операторы могут считать свою топологию конфиденциальной.

Для аутентификации OSPF конфигурация поддерживается через указание цепочек ключей [RFC8177] или прямое указание ключа и алгоритма проверки подлинности. Поэтому настройка аутентификации с использованием варианта (case) auth-key-chain в контейнере ospfv2-auth-specification или ospfv3-auth-specification наследует вопросы безопасности [RFC8177]. Это включает соображения о локальном хранении и обработке ключей аутентификации.

Кроме того, поддерживается локальное задание ключей аутентификации OSPF и связанных с ними алгоритмов для унаследованных реализаций, не поддерживающих цепочки ключей [RFC8177]. реализациям рекомендуется переходить на цепочки ключей, поскольку они обеспечивают (1) бесшовную смену ключей и алгоритмов, (2) задании ключей в шестнадцатеричном формате, повышающем энтропию ключа и (3) шифрование ключей с использованием алгоритма AES Key Wrap с заполнением (Padding) [RFC5649].

Некоторые из операций RPC в этом модуле YANG могут быть чувствительны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким операциям. Ниже указаны такие операции.

• Модуль YANG OSPF поддерживает RPC clear-neighbor и clear-database, компрометация доступа к которым позволяет использовать временные отказы сети для организации DoS-атаки.

Фактические данные ключа аутентификации (заданного локально или полученного из цепочки) являются конфиденциальными и их нужно хранить в секрете от посторонних. Компрометация этих данных позволит злоумышленнику подделать трафик OSPF, что позволяет скомпрометировать домен OSPF целиком.

5. Взаимодействие с IANA

Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688] в соответствии с форматом [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-ospf
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

Документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-ospf
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospf
   Prefix:  ospf
   Reference:  RFC 9129

6. Литература

6.1. Нормативные документы

[RFC1765] Moy, J., “OSPF Database Overflow”, RFC 1765, DOI 10.17487/RFC1765, March 1995, <https://www.rfc-editor.org/info/rfc1765>.

[RFC1793] Moy, J., “Extending OSPF to Support Demand Circuits”, RFC 1793, DOI 10.17487/RFC1793, April 1995, <https://www.rfc-editor.org/info/rfc1793>.

[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>.

[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>.

[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, “Graceful OSPF Restart”, RFC 3623, DOI 10.17487/RFC3623, November 2003, <https://www.rfc-editor.org/info/rfc3623>.

[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>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[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>.

[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, “Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)”, RFC 4576, DOI 10.17487/RFC4576, June 2006, <https://www.rfc-editor.org/info/rfc4576>.

[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, “OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)”, RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, “Multi-Topology (MT) Routing in OSPF”, RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC4973] Srisuresh, P. and P. Joseph, “OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering”, RFC 4973, DOI 10.17487/RFC4973, July 2007, <https://www.rfc-editor.org/info/rfc4973>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, “The Generalized TTL Security Mechanism (GTSM)”, RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, “OSPF Multi-Area Adjacency”, RFC 5185, DOI 10.17487/RFC5185, May 2008, <https://www.rfc-editor.org/info/rfc5185>.

[RFC5187] Pillay-Esnault, P. and A. Lindem, “OSPFv3 Graceful Restart”, RFC 5187, DOI 10.17487/RFC5187, June 2008, <https://www.rfc-editor.org/info/rfc5187>.

[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>.

[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., “Basic Specification for IP Fast Reroute: Loop-Free Alternates”, RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.

[RFC5309] Shen, N., Ed. and A. Zinin, Ed., “Point-to-Point Operation over LAN in Link State Routing Protocols”, RFC 5309, DOI 10.17487/RFC5309, October 2008, <https://www.rfc-editor.org/info/rfc5309>.

[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., “Traffic Engineering Extensions to OSPF Version 3”, RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.

[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>.

[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, “OSPF Link-Local Signaling”, RFC 5613, DOI 10.17487/RFC5613, August 2009, <https://www.rfc-editor.org/info/rfc5613>.

[RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, “Dynamic Hostname Exchange Mechanism for OSPF”, RFC 5642, DOI 10.17487/RFC5642, August 2009, <https://www.rfc-editor.org/info/rfc5642>.

[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, “OSPFv2 HMAC-SHA Cryptographic Authentication”, RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.

[RFC5714] Shand, M. and S. Bryant, “IP Fast Reroute Framework”, RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, “Support of Address Families in OSPFv3”, RFC 5838, DOI 10.17487/RFC5838, April 2010, <https://www.rfc-editor.org/info/rfc5838>.

[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>.

[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, “OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol”, RFC 6565, DOI 10.17487/RFC6565, June 2012, <https://www.rfc-editor.org/info/rfc6565>.

[RFC6845] Sheth, N., Wang, L., and J. Zhang, “OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type”, RFC 6845, DOI 10.17487/RFC6845, January 2013, <https://www.rfc-editor.org/info/rfc6845>.

[RFC6860] Yang, Y., Retana, A., and A. Roy, “Hiding Transit-Only Networks in OSPF”, RFC 6860, DOI 10.17487/RFC6860, January 2013, <https://www.rfc-editor.org/info/rfc6860>.

[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, “OSPF Stub Router Advertisement”, RFC 6987, DOI 10.17487/RFC6987, September 2013, <https://www.rfc-editor.org/info/rfc6987>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7166] Bhatia, M., Manral, V., and A. Lindem, “Supporting Authentication Trailer for OSPFv3”, RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.

[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>.

[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, “Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)”, RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.

[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>.

[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, “Advertising Node Administrative Tags in OSPF”, RFC 7777, DOI 10.17487/RFC7777, March 2016, <https://www.rfc-editor.org/info/rfc7777>.

[RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, “OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators”, RFC 7884, DOI 10.17487/RFC7884, July 2016, <https://www.rfc-editor.org/info/rfc7884>.

[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>.

[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>.

[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, “YANG Data Model for Key Chains”, RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/info/rfc8177>.

[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, “Common YANG Data Types for the Routing Area”, RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.

[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>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, “A YANG Data Model for Routing Management (NMDA Version)”, RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, “Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs”, RFC 8405, DOI 10.17487/RFC8405, June 2018, <https://www.rfc-editor.org/info/rfc8405>.

[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>.

[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, “Signaling Maximum SID Depth (MSD) Using OSPF”, RFC 8476, DOI 10.17487/RFC8476, December 2018, <https://www.rfc-editor.org/info/rfc8476>.

[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed., Pallagatti, S., and G. Mirsky, “YANG Data Model for Bidirectional Forwarding Detection (BFD)”, RFC 9314, DOI 10.17487/RFC9314, September 2022, <https://www.rfc-editor.org/info/rfc9314>.

6.2. Дополнительная литература

[RFC0905] International Organization for Standardization, “ISO Transport Protocol specification ISO DP 8073”, RFC 905, DOI 10.17487/RFC0905, April 1984, <https://www.rfc-editor.org/info/rfc905>.

[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, “OSPF Version 2 Management Information Base”, RFC 4750, DOI 10.17487/RFC4750, December 2006, <https://www.rfc-editor.org/info/rfc4750>.

[RFC5443] Jork, M., Atlas, A., and L. Fang, “LDP IGP Synchronization”, RFC 5443, DOI 10.17487/RFC5443, March 2009, <https://www.rfc-editor.org/info/rfc5443>.

[RFC5643] Joyal, D., Ed. and V. Manral, Ed., “Management Information Base for OSPFv3”, RFC 5643, DOI 10.17487/RFC5643, August 2009, <https://www.rfc-editor.org/info/rfc5643>.

[RFC5649] Housley, R. and M. Dworkin, “Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm”, RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.

[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>.

[RFC5881] Katz, D. and D. Ward, “Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)”, RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.

Благодарности

Авторы благодарны Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta, Michael Darwish, Alan Davey, Renato Westphal за подробные рецензии и полезные замечания.

Спасибо Tom Petch за рецензию Last Call и улучшение организации документа.

Спасибо Alvaro Retana за комментарии AD.

Спасибо Benjamin Kaduk, Suresh Krishnan, Roman Danyliw за комментарии IESG review.

Принадлежность автора к MITRE Corporation указана лишь для идентификации и не означает явного согласия или поддержки корпорацией MITRE высказанных суждений, мнений ил точек зрения. Корпорация MITRE одобрила публикацию этого документа для Public Release, Distribution Unlimited с Public Release Case Number 18-3194.

Участники работы

Адреса авторов

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Research Task Force (IRTF)                                C. Li
Request for Comments: 9316                                 China Telecom
Category: Informational                                         O. Havel
ISSN: 2070-1721                                                A. Olariu
                                                     Huawei Technologies
                                                       P. Martinez-Julia
                                                                    NICT
                                                                J. Nobre
                                                                   UFRGS
                                                                D. Lopez
                                                         Telefonica, I+D
                                                            October 2022

Intent Classification

Классификация намерений

PDF

Аннотация

Намерения являются абстрактной политикой высокого уровня, используемой для работы сети. Система управления на основе намерений включает интерфейс для пользователей, чтобы вводить запросы, и машину трансляции намерений в конфигурацию сети и управления жизненным циклом намерений.

В этом документе в основном рассматривается концепция сетевых намерений, но обсуждаются и иные типы намерений. В частности, документ освещает намерения с точки зрения заинтересованных сторон (stakeholder), методы классификации и представления намерений, их таксономию, а также определяет связанные с намерениями термины, когда это требуется, обеспечивает основу для связанных с намерениями исследований и облегчает разработку решений.

Документ является результатом работы исследовательской группы IRTF Network Management Research Group (NMRG).

Статус документа

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IRTF¹. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Coding for Efficient Network Communications в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9316.

Авторские права

Авторские права (Copyright (c) 2022) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение

Концепция основанных на намерениях сетей привлекла широкое внимание, поскольку она обещает упростить управления сетям с участием людей. Это достигается простым указанием того, что должно происходить в сети без задания инструкций, как это делать. Такая перспектива побудила многих исследователей и коммуникационные компании изучать это новое представление, а множество органов стандартизации Standards Development Organization или SDO) – предлагать различные модели намерений.

Этот документ предлагает методику классификации и таксономию намерений. Задача состоит в обеспечении общего понимания в исследовательском сообществе сути намерений, их типов, применяемых решений и т. п. для конкретных сценариев, которые будут рассматриваться.

Документ представляет согласованный взгляд исследовательской группы по управлению сетями (NMRG). Документ прошёл тщательное рецензирование членами исследовательской группы, активно вовлеченными в разработки и исследование рассматриваемой в документе технологии. Документ не является результатом работы IETF и стандартом.

1.1. Исследования

Сети на основе намерений активно исследуются в разных сферах, которые могут выиграть от классификации и таксономии намерений. Некоторые примеры указаны ниже.

• Выражение и распознавание намерений ([Bezahaf21], [Bezahaf19], [Jacobs18]). Использование единой классификации может обеспечить согласованное понимание различных предлагаемых и исследуемых форм выражения намерений.

• Организация (оркестровка) интеллектуальных автономных сетей радиодоступа (radio access network или RAN) [Banerjee21], где намерения классифицируются по их содержимому.

• Верификация сети намерений [Tian19], где ведётся работа над созданием языка намерений.

Этот документ уже оказался весьма актуальным для сообщества исследователей, поскольку он послужил основой для предложения самогенерируемых систем на основе намерений [Bezahaf19], для продвижения виртуальных сетевых функций (Virtual Network Function или VNF) на основе сетей IBN², которые полагаются на определения профилей намерений пользователя, соответствующих абстрактным сетевым службам [Leivadeas21], для повышения эффективности решений по предоставлению сетей на основе намерений, создания новых подходов к управлению службами [Davoli21] и даже определения для пользователей грамматики задания высокоуровневых требований к выбору blockchain в форме намерений [Padovan20]. Этот документ был упомянут в исследованиях, посвящённых интеллектуальным автономным сетям на основе намерений [Mehmood21] [Szilagyi21].

В документе также описан пример успешного применения этого предложения в академической среде [POC-IBN] исследователями в сфере программно-определяемых сетей и виртуализации сетевых функций (Software-Defined Networking / Network Function Virtualization или SDN/NFV) для определения сферы действия их проекта. Конкретная задача, которую решают исследователи, состоит в определении способов применения концепции намерений на разных уровнях, соответствующих разным заинтересованным сторонам.

Технический комитет IEEE по эксплуатации и управлению сетями (IEEE Communications Society Technical Committee on Network Operation and Management или IEEE-CNOM), исследовательская группа IRTF Network Management и IFIP WG6.6 разработали таксономию для управления сетями и службами [IFIP-NSM], применяемую исследовательским сообществом в сфере управления и эксплуатации сетей для структурирования сферы исследований с помощью чётко заданного набора ключевых слов и повышения катества обзоров в журнальных публикациях, конференциях и семинарах. Предложенная здесь таксономия намерений может послужить расширением для управления на основе намерений.

1.2. Стандарты и открытый код

Несколько SDO и проектов с открытым кодом, такие как IRTF NMRG, Open Networking Foundation (ONF) [ONF] / Open Network Operating System (ONOS) [ONOS], European Telecommunications Standards Institute (ETSI) / Experiential Networked Intelligence (ENI) и TMF с его автономными сетями, высказали намерения определить набор сетевых операций для декларативного выполнения.

Совсем недавно в IRTF NMRG был выпущен документ «Intent-Based Networking – Concepts and Definitions» [RFC9315], разъясняющий концепцию намерений (Intent) и содержащий обзор связанной с ней функциональности. Цель документа состоит в продвижении единому базовому пониманию терминов, концепций и функциональности, которое может послужить основой для последующего определения связанных исследовательских и инженерных задач и способов их решения.

Данный документ вместе с [RFC9315] предназначен служить основой для будущих дискуссий, связанных с намерениями, применительно к NMRG.

SDO обычно предлагают свои способы задания намерений и своё понимание сути намерений. Кроме того, каждый орган SDO задаёт набор терминов и уровень абстракции, пользователей намерений, приложения и варианты применения. Однако большинство подходов SDO в части намерений имеют общие свойства.

• Подход должен иметь декларативную природу, означающую, что пользователь намерений задаёт цель для сети, не указывая способ её достижения.

• Подход должен быть независимым от производителя в части абстрагирования возможностей или инфраструктуры сетей от намерений пользователей и возможности переноса на разные платформы.

• Должен обеспечиваться простой в использовании интерфейс, упрощающий взаимодействие пользователей намерения с системой намерений за счёт применения знакомой терминологии и концепций.

• Должна обеспечиваться возможность обнаруживать и разрешать конфликты намерения, включая, например, статические (при компиляции) и динамические (при работе) конфликты.

1.3. Область действия

Основное внимание в этом документе уделено определению критериев, позволяющих классифицировать намерения с точки зрения заинтересованных сторон. Концепции и определения, связанные с IBN представлены в [RFC9315]. Намерения рассмотрены, прежде всего, в контексте сети, однако не исключаются и другие типы намерений, представленные в параграфах 4.4 и 6.2.

Невозможно полностью дифференцировать намерения на основе лишь общих характеристик, за которыми следуют концепции, термины и намерения. В документе разъясняется, что представляют собой намерения для разных заинтересованных сторон путём классификации по различным измерениям, таким как решения, намерения пользователей и типы намерений. Такая классификация обеспечивает единое для всех участников понимание и служит для определения области действия и приоритета отдельных проектов, подтверждения концепций (proof of concept или PoC), исследований и проектов с открытым кодом.

Сфера классификации намерений в этом документе включает решения, намерения пользователей и типы намерений. Исходные таблицы классификации приведены для этих областей. Представленную здесь методику можно использовать для обновления таблиц классификации путём добавления или удаления различных решений, намерений пользователей, типов намерений в соответствии с будущими вариантами примерения, приложениями и доменами.

2. Сокращения

AI

Artificial Intelligence – искусственный интеллект.

CE

Customer Equipment – клиентское оборудование.

CFS

Customer Facing Service – обслуживание клиентов.

CLI

Command-Line Interface – интерфейс командной строки, командный интерфейс.

DB

Database – база данных.

DC

Data Center – центр обработки данных, ЦОД

ECA

Event Condition Action – действие по событию.

GBP

Group-Based Policy – политика по группам.

GPU

Graphics Processing Unit – графический процессор.

IBN

Intent-Based Network – сеть на основе намерений.

NFV

Network Function Virtualization – виртуализация сетевой функции.

O&M

OAM & Maintenance – OAM и техническое обслуживание (поддержка).

ONF

Open Networking Foundation – фонд открытых сетей.

ONOS

Open Network Operating System – открытая сетевая операционная система (ОС).

PNF

Physical Network Function – функция физической сети.

QoE

Quality of Experience – качество опыта (работы).

RFS

Resource Facing Service – обслуживание ресурсов.

SDO

Standards Development Organization – орган стандартизации.

SD-WAN

Software-Defined Wide-Area Network – программно-управляемая распределенная сеть (WAN).

SLA

Service Level Agreement – соглашение об уровне обслуживания.

SUPA

Simplified Use of Policy Abstractions – упрощенное применение абстракций.

VM

Virtual Machine – виртуальная машина.

VNF

Virtual Network Function – виртуальная сетевая функция.

3. Определения

Единое базовое понимание терминов и определений для IBN представлено в [RFC9315], как показано ниже.

Intent – намерения

Набор операционных целей (которым следует соответствовать сети) и результатов (которые сети следует обеспечивать), определённый декларативно без указания способов их достижения и реализации.

Intent-Based Network

Сеть, управляемая с использованием намерений.

Policy – правила (политика)

Набор правил, определяющих выбор поведения системы.

Intent User – пользователь намерений

Пользователь, задающий и вносящий запросы намерений для системы управления на основе намерений.

Другие определения, относящиеся к этому документу, такие как область действия намерений (intent scope), сетевая область действия намерений (intent network scope), абстракция намерений (intent abstraction), жизненный цикл намерений (intent life cycle) представлены в разделе 5. Функциональные характеристики и поведение.

4. Абстрактные требования к намерениям

Для понимания различных требований к намерениям, влияющим на их классификацию, нужно понять, что означают намерения для различных пользователей намерений.

4.1. Что такое намерения?

Термин «намерения» (Intent) получил очень широкое распространение в отрасли для разных целей, иногда не согласующихся с общими принципами SDO, отмеченными в разделе 1. В [RFC9315] даны разъяснения относительно того, что считать намерениями и чем намерения отличаются от правил и служб.

У разных заинтересованных сторон различаются взгляды на сети, поэтому они предъявляют разные требования к намерениям. Их намерения могут быть техническими или нетехническими, абстрактными или связанными с технологией. Поэтому важно начать обсуждение в отраслевом и исследовательском сообществе намерений для различных решений и пользователей. Также крайне важно попытаться предложить некие категории и классификацию намерений, которые будут понятны широкой аудитории. Это поможет определить интерфейсы намерений, зависящие от сферы применения языки и модели.

4.2. Решения и пользователи намерений

Типы намерений определяются всеми аспектами, которые требуются для профилирования разных требований, чтобы они легко различались. Однако для упрощения кластеризованной классификации можно сосредоточиться на двух аспектах – решение и пользователь намерений. Их можно считать основными ключами для классификации намерений, поскольку те легко сгруппировать по решениям и пользователям.

С другой стороны, разные решения и пользователи намерений имеют различные требования, ожидание и приоритеты в части сетей на основе намерений. Поэтому пользователям намерений нужны разные типы намерений в зависимости от контекста, поскольку они участвуют в разных вариантах применения. Например, некоторые пользователи намерений более подкованы технически и ребуют намерений с большим объёмом технических сведений. Другие пользователи не знают инфраструктуры сети и им нужны намерения, не включающие сетевых концепций и технологий.

В таблице 1 указаны решения и пользователи намерения, которые необходимо поддерживать сети IBN.

Таблица 1. Решения и пользователи намерений.

Решения	Пользователи намерений
Сети операторов	Сетевые операторы, Разработчики услуг и приложений, операторы услуг, клиенты и подписчики
Сети ЦОД	Администраторы облаков и базовых сетей, разработчики приложений, клиенты и арегдаторы
Сети предприятий	Администраторы корпоративных сетей, разработчики приложений, конечные пользователи

Эти решения и пользователи намерений являются стартовой точкой для классификации и применяются методикой , представленной в параграфе 6.1. Методика классификации намерений.

• Например, для сетей операторов желание клиента (подписчика) смотреть видео с высоким разрешением ведёт к представлению его намерений преобразованием видеороликов в формат 1080p.

• Для ЦОД у администраторов имеются свои чёткие намерения для сети, такие как распределение нагрузки. Для всех потоков трафика, требующих цепочки услуг NFV, они могут ограничить максимальную загрузку любого узла/контейнера VNF значением 50%, а для сетевых каналов – не более 70%.

• Для корпоративных сетей при проведении видеоконференций требуется множественный удалённый доступ. Намерения администратора сети могут быть выражены, например, обеспечить для каждого пользователя этого приложения время доставки голографических объектов в интервал 50 мсек.

4.3. Преимущества намерений для заинтересованных сторон

Современные сетевые API и CLI стали слишком сложными по причине глубокой интеграции с низкоуровневыми концепциями сетей. От клиентов, разработчиков приложений и конечных пользователей не следует требовать установки адресов IP, VLAN, подсетей, портов, тогда как операторы сетей могут хотеть сохранения технического и сетевого контроля. Все заинтересованные стороны получат преимущества от упрощений интерфейсов, таких как:

• запрос приоритетного (gold) VPN-сервиса между сайтами A, B, C;

• резервирование CE между сайтами клиента;

• добавление правил доступа к сетевой служте.

Операторы и администраторы вручную ищут неполадки и исправляют свои сети и службы. Вместо этого они хотят:

• упрощения и автоматизации сетевых операций;

• упрошения определений сетевых служб;

• предоставления простых клиентских API для дополнительных услуг (операторов);

• информирования об отличии поведения сети или службы от запрошенного;

• возможности автоматической оптимизации и корректировки для выбранных сценариев;

• наличия систем, обучающихся на основе исторической информации и поведения.

В настоящее время пользователи намерений не могут выстраивать свои службы и правила без технических знаний и выполнения ручных операций по обслуживанию. Взамен их пользователи хотят получить возможность:

• выстраивать свои сетевые службы и правила через простые интерфейсы без необходимости технических знаний о сетях;

• запускать свои сетевые службы на основе лишь намерений и автоматизации без выполнения действий вручную.

4.4. Типы намерений, которые необходимо поддерживать

Помимо решений для намерений и пользователей намерений можно классифицировать намерения по их типам. Ниже перечислены типы и субтипы намерений, которые требуется поддерживать для исполнений требований разнах решений и пользователей намерений.

• Намерения для обслуживания клиентов

  • самообслуживание клиентов с SLA;

  • заказы операторов служб.

• Намерения для служб сети и базовой (underlay) сети

  • заказы операторов служб;

  • настройка, проверка, корректировка и оптимизация конфигурации сети на основе намерений;

  • намерения, созданные и представленные администратором базовой сети.

• Намерения для сети и базовой сети

• • настройка конфигурации сети;

  • увтоматизированное управление жизненным циклом сетевых конфигураций;

  • сетевые ресурсы (коммутаторы, маршрутизаторы, маршрутизация, правила, базовая сеть).

• Намерения для управления облаком

  • конфигурация ЦОД, VM, серверы баз данных и приложений;

  • связь между VM.

• Намерения для управления ресурсами облака

  • управление жизненным циклом ресурсов облака (самонастройка по правилам, автоматической масштабирование, восстановление и оптимизация).

• Стратегические намерения

  • безопасность, QoS, политика приложений, управление трафиком и т. п.;

  • настройка и монитринг правил, генерация сигналов при несоответствии, автоматическое восстановление;

  • создание моделей и правил для сетей и сетевых служб;

  • создание рабочих процессов, моделей и правил для намерений управления эксплуатацией.

• Намерения для задач эксплуатации

  • перенос сетей;

  • замена устройств;

  • обновление сетевых программ;

  • автоматизация любых задач, часто выполняемых операторами и администраторами.

Важно упомянуть, что все указанные типы и субтипы могут влиять на другие намерения. Например, намерения для задач эксплуатации могут менять многие другие намерения. Сама задача недолговечна, но изменение других намерений влияет на жизненный цикл, поэтому изменения нужно постоянно отслеживать и самостоятельно корректировать/оптимизировать.

5. Функциональные характеристики и поведение

Намерения могут служить для немедленного воздействия на цель (во многом похоже на команды) или при возникновении соответствующих условий (например, по событию). В любом случае намерение имеет варианты поведения, которы служат для дальнейшей организации его назначения, как описано в последующих параграфах.

5.1. Абстрагирование намерений

Моделирование намерений можно абстрагировать с помощью триплетов {контекст, возможности, ограничения}.

• Контекст обосновывает намерение и определяет, уместно ли оно в текущей ситуации, т.е выбирает намерения на основе применимости.

• Возможности описывают доступную намерению функциональность и могут меняться в зависимости от выразительности намерения и применяемой парадигмы программирования.

• Ограничения задают пределы возможностей, доступных в конкретном контексте.

Можно добавлять метаданные к каждому элементу триплета через шаблоны стратегии и применять их для описания способов использования намерений, их работы, а также предписания операционных зависимостей, которые требуется учитывать.

Хотя разные категории намерений используют одну абстрактную модель, у каждой категории есть свой контекст, возможности и ограничения.

5.2. Типы пользователей намерений

Типы пользователей намерений представляют пользователей, определяющих и представляющих запросы намерений. Возможные пользователи зависят от решения для намерения. Примерами пользователей намерений являются клиенты, сетевые операторы, операторы служб, администраторы корпоративных сетей, облаков и базовых сетей, разработчики приложений.

• Клиенты и конечные пользователи могут не знать функциональные и рабочие детали используемой ими сети. Кроме того, у них недостаточно навыков для понимания таких деталей, поскольку эти знания обычно не связаны с их работой. К тому же сеть может не раскрывать своих деталей пользователям намерений. Этот класс пользователей сосредоточен на приложениях, которые они запускают, и пользуется предлагаемыми сетью услугами. Поэтому они хотят задавать правила, которые обеспечат согласованное с их деловыми потребностями поведение. Им не нужно заботиться о реализации намерений в базовой сети и преобразовании намерений в различные формы, понятные элементам сети.

• Разработчики приложений имеют дело с набором аьстракций, определяемых их приложением и средой программирования. Например, многие разработчики решают задачи на уровне объектов (например, VPN). Хотя это имеет смысл для разработчиков приложений, многие сетевые устройства не имеют объекта VPN, как такового, и VPN формируется набором операторов конфигурации для устройства в сочетании с операторами конфигурации других устройств, совместно образующих VPN. Поэтому представление разработчиков приложений соответствует предоставляемым сетью услугам но не соответствует напрямую представлениям других пользователей намерения.

• Сетевые операторы могут иметь сведения о базовой сети, однако они могут не понимать деталей работы приложений и клиентских служб.

5.3. Область действия намерений

Намерения служат для управления поведением сетей, в которых они применяются, и все намерения испольняются в конкретной области (scope), такой как:

• область связности, если намерение создаёт или изменяет соединения;

• область безопасности/приватности, если намерение меняет защитные характеристики для сети, клиентов, конечных пользователей;

• область приложения, если намерение задаёт приложение для воздействия;

• область QoS, когда намерение задаёт характеристики QoS для сети.

Эти области действия намерений применяются методикой, представленной в параграфе 6.1. Методика классификации намерений.

5.4. Намерения для сети

Независимо от типа пользователей намерений, их запросы влияют на сеть или её компоненты, служащие целью намерения. Таким образом, область действия намерения в сети или цель политики (в сфере декларативно политики) может представлять VNF или PNF, элементы физической сети, кампусные сети, SD-WAN, RAN, границы облаков, облака, филиалы и т. п..

5.5. Абстракция намерений

Намерения можно классифицировать по необходимости возвращать по исполнении пользователю техническую или нетехническую информацию. Кроме того, абстракция намерения охватывает технические детали самого намерения.

• Пользователям нетехнических намерений не важно, как намерения исполняются, и не интересны детали сети. В результате им не нужно знать о конфигурации базовой сети. Они сосредоточены лишь на соответствии результатов исполнения намерений заданной цели и эффекте исполнения, таком как качество и продолжительность выполнения намерений. В таких случаях говорят об абстракции без технической обратной связи.

• Администраторы выполняют намерения, такие как выделение сетевых ресурсов, выбор путей передачи, обработка отказов в сети и т. п. После выполнения мм нужны отклики о состоянии сетевых ресурсов, перегрузки, отказов и т. п. В этом случае говорят об абстракции с технической обратной связью.

В соответствии с определением термина «намерения» в [RFC9315], низкоуровневые намерения не считаются намерениями. Однако эта классификация сохраняется здесь для идентификации PoC, демонстраций, примеров использования, которые по-прежнему требуют или применяют низкий уровень абстакции для намерений.

5.6. Жизненный цикл намерений

Намерения можно разделить на временные и постоянные (сохраняющиеся).

Transient – временные

Для намерения нет управления жизненным циклом. После успешного завершения заданной операции намерение завершается и больше не может влиять на целевой объект.

Persistent – постоянные

Намерение имеет управляемый жизненный цикл. После успешной активации и развёртывания намерения система сохраняет все относящиеся к делу намерения активными, пока они не будут деактивированы или удалены.

5.7. Уровни самоуправления

На разных фазах сетей с самоуправлением [TMF-AUTO] намерения различаются. В зависимости от уровня автономности сети для общего решения могут быть разные требования и типы намерений. Например, на нижних уровнях намерения клиента:

• автоматически преобразуются в правила конфигурации лишь на более высоких уровнях;

• охватывают весь жизненный цикл;

• преобразуются в правила конфигурации и мониторинга;

• обеспечивают сами себя с помощью AI.

Ниже приведены типовые примеры автономных (самоуправляемых) сетей уровня 0 – 5.

Уровень 0 – традиционная сеть с ручным управлением

Персонал O&M вручную управляет сетью, получая сигналы тревоги и записи системного журнала.

• Нет намерений.

Уровень 1 – частично автоматизированная сеть

Применяются автоматизированные сценарии для предоставления услуг, развёртывания и поддержки сети. Сеть обеспечивает поверхностное представление состояния и предложения по принятию решений.

• Нет намерений.

Уровень 2 – автоматизированная сеть

Автоматизация предоставления большинства услуг, развёртывания и поддержки сети, комплексное представление состояния сети, принятие решений на локальной машине.

• Простые намерения по предоставлению услуг.

Уровень 3 – сеть с самооптимизацией

Глубокое понимание состояния сети и автоматическое управление сетью в соответствии с требованиями пользователей намерений в сети.

• Намерения, основанные на понимании состояния сети.

Уровень 4 – сеть с частичным самоуправлением

В ограниченной среде людям не нужно участвовать в принятии решений и сеть может настраиваться сама.

• Намерения на основе ограниченного AI.

Уровень 5 – автономная (самоуправляемая) сеть

В разных сетевых средах и условиях сеть может автоматически приспосабливаться и выполнять намерения людей.

• Намерения на основе AI.

6. Классификация намерений

В этом разделе предлагается подход к классификации намерений, который может помочь в классификации основных демонстраций и инструментов, связанных с намерениями.

Три классификации в этом документе разработаны с нуля в соответствии с представленной методикой) посредством трёх итераций – для решения в сетях операторов, ЦОД и сетях предприятий. Для каждого из решений указаны конкретные типы намерений и их пользователи. Затем идентифицируется область действия намерений и сети, абстракции и требования жизненного цикла.

Эту классификацию и приведённые таблицы легко расширить. Например для решения в ЦОД указана новая категория «область действия ресурса (resource scope) и соответственно расширена таблица классификации. В будущем, по мере появления новых сценариев, приложений и домено можно будет определить новые классификации и таксономию, следуя предложенной методике.

Классификация намерений была документирована на основе сведений, доступных во время создания документа. В будущем, скорей всего, появятся дополнительные классификации.

Результатом классификации является таксономия намерений, представленная в параграфах этого раздела.

Таким образом, раздел 6 представляет методику классификации намерений, консолидированную таксономию намерений для трёх решений и конкретные примеры классификации намерений для этих трёх решений (сети операторов, ЦОД и сети предприятий), которые были выведены с использованием предложенной методики и могут быть заполнены для PoC, демонстраций, исследовательских проектов и будущих документов.

6.1. Методика классификации намерений

В этом параграфе описана методика, использованная для первоначальной классификации, предложенной в этом документе. Методику можно применять для создания новых классификаций намерений с нуля путём анализа знаний о решениях. Прдходит методика и для обновления имеющихся таблиц классификации путём добавления или удаления решений, пользователей или типов намерений в соответствии с будущими сценариями, приложениями или доменами.

          +------------------------------------------+
          |Знание решений (требования, примеры       |
          |использования, тезнологии, сеть, намерения|
          |пользователей, требования к намерениям)   |
          +----------------+-------------------------+
                           | Ввод              Rx=чтение
                           |                   Ux=обновление 
                  +--------V--------+          (добавить/удалить)
                  |1. Идентификация |
                  |   намерений     +------------+
                  |                 |            |
                  +---------^-+-----+            |
                         R1 | | U1               |
+---------------+ U8        | |    R2         +--v----------------+
|8.Идентификация+---------+ | |   +-----------> 2.Идентификация   |
|  новых        | R8      | | |   | U2        |   типов пользоват.|
|  категорий    <-------- | | |   | +---------+   намерений       |
+--------^------+       | | | |   | |         +-------|-----------+
         |              | | | |   | |                 |
         |             ++-+-v-v---+-v-+               |
+--------+------+ U7   |              | R3     +------v------------+
|7.Идентификация+------> Классификация+--------> 3.Идентификация   |
|  требований   | R7   |  намерений   | U3     |   типа            |
|  жизн. цикла  <------+              <--------+   намерений       |
+--------^------+      +^--^-+--^-+---+        +------|------------+
         |              || | |  | |                   |
         |              || | |  | |                   |
+--------+-----+        || | |  | | R4        +-------v-----------+
|6.Идентификац.| U6     || | |  | +-----------> 4.Идентификация   |
|  абстракций  +---------| | |  |   U4        |   области действия|
|              <---------+ | |  +-------------+   намерений       |
+-------^------+ R6        | |                +-------+-----------+
        |                  | |                        |
        |               U5 | |R5                      |
        |          +-------+-v--------+               |
        |          |5.Идентификация   |               |
        +----------+  области сети    <---------------+
                   +------------------+

Рисунок 1. Методика классификации намерений.

Рабочий процесс классификации намерений начинается со сведений о решении, которые могут дать информацию о требованиях, примерах использования, применяемых технологиях, свойствах сети, пользователях намерений, задающих и представляющих запросы намерений и требования. Ниже указаны этапы классификации намерений.

1. Получение сведений из знаний о решении как входных данных для идентификации решения (например, оператор, предприятие, ЦОД). Решения с намерениями проверяются на соответствие имеющейся классификации и могут использоваться (при наличии), добавляться (при отсутствии) или удаляться (при ненужности) из классификации. (R1-U1)

2. Определяются типы пользователей намерения (клиент, оператор сети или сервиса и т. п.). Просматривается имеющаяся классификация и тип пользователя применяется (при наличии), добавляется (при отсутствии) или удаляется (при ненужности). (R2-U2)

3. Определяется тип намерения (намерение для сети или обслуживания пользователей и т. п. Просматривается имеющаяся классификация и тип намерения применяется, добавляется или удаляется. (R3-U3)

4. Определяется область действия намерения (например, связность, приложение) на основе знаний о решении. Просматривается имеющаяся классификация и область действия применяется, добавляется или удаляется. (R4-U4)

5. Определяются области сети (например, кампус, радидоступ). Просматривается имеющаяся классификация и область применяется, добавляется или удаляется. (R5-U5)

6. Определяются абстракции (например, технические, нетехнические). Просматривается имеющаяся классификация и абстракции применяются, добавляются или удаляются. (R6-U6)

7. Определяются требования к жизненному циклу намерения (постоянное, временное). Просматривается имеющаяся классификация и требования применяются, добавляются или удаляются. (R7-U7).

8. Идентифицируются любые новые категории с применением и добавлением найденных. Новые категории могут появляться по мере возникновения новых доменов или приложений, а также предметных областей (например, приватность, соответствие), не учтённых в текущей методике.

6.2. Таксономия намерений

Приведённая ниже таксономия описывает разные решения для намерений, типы пользователей намерений, типы намерений, сферу намерений, область действия сети, абстракци и жизненные циклы. Таксономия является выводом таблиц классификации намерений для каждого из рассмотренных решений (оператор, ЦОД, предприятие).

Категории сферы намерений на рисунке 2 являются общими для всех 3 решений (операторы, ЦОД, предприятия). Сокращения (Cx) в параграфах 6.3.2 и 6.4.2 указываются в соответствии со столбцами в последующих таблицах.

                             +--------------------------------+
                         +-->|  Оператор   Предприятие   ЦОД  |
                         |   +--------------------------------+
                         |   +--------------------------------+
                         |   |Клиент, подписч., конечн. польз.|
           +----------+  |   |Оператор сети или сервиса       |
         +>+ Решение  +--+   |Разработчик приложений          |
         | +----------+   +->|Администратор предприятия       |
         |                |  |Администратор облака            |
         | +----------+   |  | Администратор базовой сети     |
         +>+Тип       +---+  +--------------------------------+
         | |пользоват.|      +--------------------------------+
         | |намерений |      |Намерения обслуживания клиентов |
         | +----------+      |Стратегические намерения        |
         | +----------+      |Намерения сетевых служб         |
         +>+Тип       +----->|Намерения служб базовой сети    |
+------+ | |намерений |      |Намерения для сети              |
|Намер.+-+ +----------+      |Намерения для базовой сети      |
+------+ |                   |Намерения для эксплуат. задач   |
         | +----------+      |Намерения для управления облаком|
         +>+Сфера     +---+  |Намерения управл. ресурс. облака|
         | |намерений |   |  +--------------------------------+
         | +----------+   |  +--------------------------------+
         |                +->|  Связность   Приложение  QoS   |
         | +----------+      | Безопасность Хранилище Расчёты |
         +>+Сфера     +---+  +--------------------------------+
         | |сети      |   |  +--------------------------------+
         | +----------+   |  |Радиодоступ       Филиал        |
         |                +->|Транспорт. доступ SD-WAN        |
         | +----------+      |Транспорт. агрег. VNF      PNF  |
         +>+Абстракция+----+ |Ядро транспорта   Физическая    |
         | |          |    | |Коай облака       Логическая    |
         | +----------+    | |Ядро облака       Кампус        |
         | +----------+    | +--------------------------------+
         +>+Жизненный |    | +--------------------------------+
           |цикл      +--+ +>|Тезническая       Нетехническая |
           +----------+  |   +--------------------------------+
                         |   +--------------------------------+
                         +-->|Постоянно         Временно      |
                             +--------------------------------+

Рисунок 2. Таксономия намерений.

6.3. Классификация намерений для операторских решений

6.3.1. Пользователи и типы намерений

В этом параграфе выполнены пп. 1 – 3 с рисунка 1, а таблица 2 описывает пользователей и типы намерений в операторских решениях.

Таблица 2. Классификация намерений для операторских решений.

Пользователь	Тип намерения	Описание намерения
Клиент, подписчик	Обслуживание клиентов	Самообслуживание клиента с SLA и дополнительными услугами. Пример. Всегда поддерживать высокое качество обслуживания и пропускную способность для приоритетных (gold-level) подписчиков. Описание операций. Измерение состояния перегрузки в сети, задание различных адаптивных параметров для станций с разным приоритетом. Таким образом, при сильной загрузке гарантируется пропускная способность для приоритетных клиентов. В то же время обеспечивается общая загрузка системы и повышается общая пропускная способность.
	Стратегические намерения	Клиент создаёт модели и правила для намерений для примеенния в намерениях обслуживание клиентов. Пример. Запрос надёжного обслуживания в пиковые периоды для видео-приложений.
Сетевой оператор	Намерения сетевой службы	Услуги, предоставляемые оператором сетевой службы клиентам (например, оператор сервиса). Пример. Запрос сетевого сервиса с гарантиями по задержкам для доступа клиента A.
	Намерения для сети	Запрос от сетевого оператора общесетевой (основа службы или другие настройки в масштабе сети) конфигурации или настройки ресурсов сети (коммутаторы, маршрутизаторы, маршрутизация, правила). Включает связность, маршрутизацию, QoS, безопасность, правила для приложений и управления трафиком, сигнализация несоответствия, автоматическое восстановление и т. п. Пример. Запрос очередей с высоким приоритетом для трафика класса A.
	Задачи эксплуатации	Оператор сети запрашивает выполнение автоматизированной задачи, отличающейся от намерений для сетевой службы и сети (например, перенос сети, замена сервера или устройства, обновление сетевых программ). Пример. Запрос переноса всех услуг сети N на резервный путь P.
	Стратегические намерения	Оператор сети создаёт модели, намерения политики и рабочие процессы, которые будут применяться намерениями сетевых служб, а также намерениями для сетей и эксплуатационных задач. Рабочие процессы могут автоматизировать любые задачи, которые оператор часто выполняет в дополнение к намерениям для сетевых служб и сети. Пример. Обеспечение на любом канале в сети нагрузки не выше 50%.
Оператор сервиса	Обслуживание клиентов	Заказы клиентов оператора сервиса, обслуживания клиентов или SLA. Пример. Обеспечить услугу S с гарантированной пропускной способностью для клиента A.
	Намерения для сетевой службы	Сетевые заказы оператора сервиса, SLA для сети. Пример. Предоставить сетевые гарантии безопасности, малой задержки и высокой пропускной способности.
	Задачи эксплуатации	Оператор службы запрашивает выполнение автоматизированной задачи, отличающейся от намерений обслуживания клиентов и намерений для сетевых служб. Пример. Регулярное обновление платформ и программ оператора сервиса. Перенос службы из сети оператора 1 в сеть оператора 2.
	Стратегические намерения	Оператор сети создаёт модели, намерения политики и рабочие процессы, которые будут применяться намерениями отбслуживания клиентов, намерениями сетевых служб и намерениями эксплуатации. Рабочие процессы могут автоматизировать любые задачи, которые оператор часто выполняет в дополнение к намерениям для сетевых служб и сети. Пример. Запрос гарантий сетевого обслуживания, позволяющих избежать перегрузок в такие периоды как «Черная пятница» и Рождество.
Разработчик приложений	Обслуживание клиентов	API для намерений обслуживания клиентов, предоставляемый разработчикам приложений. Пример. API для запроса у сети просмотра HD-видео (4K/8K).
	Намерения для сетевой службы	API намерений сетевой службы для разработчиков приложений. Пример. API для запроса сетевого сервиса, мониторинга и обработки трафика.
	Намерения для сети	API намерений для сети, предоставляемые разработчикам приложений. Пример. API для запроса конфигурации сетевых ресурсов.
	Задачи эксплуатации	API для намерений эксплуатационных задач, предоставляемые разработчикам приложений. Предназначены для доверенных внутренних операторов, сервис-провайдеров, клиентских разработчиков (DevOps). Пример. API для запроса переноса сервера.
	Стратегические намерения	Разработчики приложений создают модели, правила и рабочие процессы, которые можно применять в намерениях обслуживания клиентов, намерениях для сетевых служб и задач эксплуатации. Они предназначены для доверенных внутренних операторов, сервис-провайдеров, клиентских разработчиков (DevOps). Пример. API для создания стратегии распределения сеетвой нагрузки в пиковые периоды.

6.3.2. Категории намерений

В этом параграфе выполнены пп. 4 – 7 с рисунка 1, а ниже указаны предложенные категории.

Область намерений

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS

Область сети

Домен сети

C1=радиодоступ, C2=транспортный доступ, C3=транспортное агрегирование, C4=ядро транспорта, C5=граница облака, C6=ядро облака

Область сетевой функции (NF)

C1=VNF, C2=PNF

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (см. параграф 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

6.3.3. Пример классификации намерений

В этом параграфе дан пример применения методики из параграфа 6.1 для классификации намерений, представленных в демонстрации PoC «A Multi-Level Approach to IBN» [POC-IBN]. Это подтверждения выполнено исследователями в сфере SDN/NFV, решающими задачу применения концепции намерений на разных уровнях, соответствующих различным заинтересованным сторонам. Для исследования применялись два типа намерений – намерения среза (slice) и намерения цепочки услуг (service chain). В PoC [POC-IBN] намерения для среза выражали запрос сетевого среза с 2 типами компонентов – набором виртуальных функций верхнего уровня и набором виртуальных коммутаторов и/или маршрутизаторов L2/ L3 VNF. Намерение для цепочки услуг выражалось запросом услуги, предоставляемой через цепочку компонентов в виртуальных функциях L4-L7.

В соответствии с методикой классификации из параграфа 6.1 можно вывести следующее:

1. решением для обоих намерений служит сеть оператора;

2. пользователем намерений является оператор сети для среза и оператор службы для цепочки услуг;

3. типом намерения является намерение для сетевой службы в случае среза и намерение обслуживания клиентов для цепочки услуг;

4. областью намерений являются связность и приложение;

5. областью сети являются VNF, граница и ядро облака;

6. абстракции возвращают технические сведения для среза и не возвращают для цепочки услуг;

7. жизненный цикл является постоянным.

На рисунке 3 показано табличное представление этих сведений. X в таблице относится к намерению для среза, Y – для цепочки услуг.

Пользователь	Тип намерений	Область намерений				Обл. NF		Область сети						ABS		L-C
		C1	C2	C3	C4	C1	C2	C1	C2	C3	C4	C5	C6	C1	C2	C1
Клиент, подписчик	Обслуживание клиентов
	Стратегические намерения
Сетевой оператор	Намерения для сетевой службы	X		X		X						X		X		X
	Намерения для сети
	Задачи эксплуатации
	Стратегические намерения
Оператор сервиса	Намерения клиента	Y		Y		Y						Y	Y		Y	Y
	Намерения для сетевой службы
	Задачи эксплуатации
	Стратегические намерения
Разработчик приложений	Намерения клиента
	Намерения для сетевой службы
	Намерения для сети
	Задачи эксплуатации
	Стратегические намерения

Рисунок 3. Пример классификации намерений для операторского решения.

6.4. Классификация намерений для решений ЦОД

6.4.1. Пользователи и типы намерений

В таблице 3 описаны пользователи и типы намерений для решения ЦОД.

Таблица 3. Классификация намерений для ЦОД.

Пользователь	Тип намерения	Описание намерения
Клиент, арендатор	Обслуживание клиентов	Самообслуживание клиентов через портал арендаторов. Пример. Запрос расчётов на GPU и ресурсов хранилища для поддержки 10 тысяч служб видеонаблюдения.
	Стратегические намерения	Намерения для моделей и политики, созданные клиентами/арендаторами, пригодные для повторного использования путём создания экземпляров. Пример. Запрос динамических ресурсов для расчётов и хранения в указанное время или по дням.
Администратор облака	Управление облаком	Настройка VM, серверов DB, серверов приложений и связи между серверами и VM. Пример. Запрос связности между VM A, B, C в сети N1.
	Намерения управления облачными ресурсами	Самонастройка по правилам, а также восстановление и оптимизация. Пример. Запрос автоматического управления жизненным циклом облачных ресурсов VM.
	Задачи эксплуатации	Администратор облака запрашивает выполнение автоматизированных задач, отличных от намерений по управлению облаком и облачными ресурсами. Пример. Запрос на обновление операционной системы до версии X на всех VM в сети N1. Описание операций. Намерение обновить систему может изменить топологию (соединения со службами и партнерами), вызывать обмен данными (обновление содержмого) и придерживаться определённого уровня QoE (выделение достаточных ресурсов). Таким образом, сеть выполняет нужную настройку конфигурации для лучшего исполнения намерения, например, организуются прямые восходящие соединения между трминалами и справедливо выделяются очереди на маршрутизаторах с учётом других сетевых служб.
	Стратегические намерения	Администратор облака создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач в дополнение к намерениям по управлению жизненным циклом и ресурсами облака. Пример. При возникноверии угрозы все облачные ресурсы автоматически переносятся в DC2.
Администратор базовой сети	Намерения для базовой сетевой службы	Услуга, создаваемые и предоставляемая администратором базовой сети. Пример. Запрос базовой службы между DC1 и DC2 с полосой B.
	Намерения для базовой сети	Администратор базовой сети запрашивает в масштабе DCN некую конфигурацию базовой сети или её ресурсов. Пример. Организация и выбеление пула адресов DHCP.
	Задачи эксплуатации	Администратор базовой сети запрашивает выполнение автоматизированных задач, отличных от намерений для базовых сетевых служб и ресурсов. Пример. Запрос быстрого автоматического обнаружения отказов устройств и сопоставление условий перед сигналом тревоги.
	Стратегические намерения	Администратор облака создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач. Пример. Для потоков трафика, которым нужны цепочки услуг NFV, ограничивается загрузка любого узла или контейнера VNF значением 50%, а максимальная загрузка сетевых каналов – значением 70%.
Разработчик приложений	Управление облаком	API намерений управления облаком для разрабочиков приложений. Пример. API для запроса конфигурации VM или серверов баз данных.
	Управление ресурсами облака	API намерений управления ресурсами облака для разрабочиков приложений. Пример. API для запроса автоматического управления жизненным циклом ресурсов облака.
	Намерения для базовой сетевой службы	API базовой сетевой службы для разрабочиков приложений. Пример. API для запроса мониторинга устройств в реальном масштабе времени.
	Намерения для базовой сети	API управления ресурсами базовой сети для разрабочиков приложений. Пример. API для запроса динамического управления пулами адресов IPv4.
	Задачи эксплуатации	API намерений для задач эксплуатации, предоставляемый доверенным разработчикам приложений (внутренние DevOps). Пример. API для запроса быстрого автоматического отказов устройств и сопоставление условий перед сигналом тревоги.
	Стратегические намерения	Разработчик приложений создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Предназначено для внутренних DCN DevOps. Пример. API для запроса порогов распределения нагрузки.

6.4.2. Категории намерений

Ниже представлены предложенные категории

Область намерений

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS, C5=хранилище, C6=расчёты

Область сети

Домен сети

Сеть ЦОД

Область сети DCN (DCN Net)

C1=логическая, C2=физическая

Область ресурса DCN (DCN Res)

C1=виртуальный, C2=физический

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (см. параграф 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

6.4.3. Пример классификации намерений

В этом параграфе приведён пример использования методики из параграфа 6.1 исследовательским сообществом для классификации намерений. Как указано в параграфе 6.3.3, успешное применение предложенной в документе классификации продемонстрировано в PoC «A Multi-Level Approach to IBN» [POC-IBN]. Это подтверждения выполнено исследователями в сфере SDN/NFV, решающими задачу применения концепции намерений на разных уровнях, соответствующих различным заинтересованным сторонам.

Для исследования применялись два типа намерений – намерения среза (slice) и намерения цепочки услуг (service chain). Для решения ЦОД применимы лишь намерения среза. Как указано в параграфе 6.3.3 намерения для среза выражали запрос сетевого среза с 2 типами компонентов – набором виртуальных функций верхнего уровня и набором виртуальных коммутаторов и/или маршрутизаторов L2/ L3 VNF.

В соответствии с методикой классификации из параграфа 6.1 можно вывести следующее:

1. решением для обоих намерений служит сеть оператора;

2. пользователем намерений является оператор сети для среза и оператор службы для цепочки услуг;

3. типом намерения является намерение для сетевой службы в случае среза и намерение обслуживания клиентов для цепочки услуг;

4. областью намерений являются связность и приложение;

5. областью сети являются VNF, граница и ядро облака;

6. абстракции возвращают технические сведения для среза и не возвращают для цепочки услуг;

7. жизненный цикл является постоянным.

На рисунке 4 показано табличное представление этих сведений. X в таблице относится к намерению для среза.

Пользователь	Тип намерений	Область намерения						DCN Res		DCN Net		ABS		L-C
		C1	C2	C3	C4	C5	C6	C1	C2	C1	C2	C1	C2	C1	C2
Клиент, арендатор	Обслуживание клиентов
	Стратегические намерения
Администратор облака	Управление облаком	X		X				X		X		X		X
	Управление ресурсами облака
	Задачи эксплуатации
	Стратегические намерения
Администратор базовой сети	Намерения для базовой сети
	Намерения для ресурсов базовой сети
	Задачи эксплуатации
	Стратегические намерения
Разработчик приложений	Управление облаком
	Управление ресурсами облака
	Намерения для базовой сети
	Намерения для ресурсов базовой сети
	Задачи эксплуатации
	Стратегические намерения

Рисунок 4. Пример классификации намерений для ЦОД.

6.5. Классификация намерений для корпоративных решений

6.5.1. Пользователи и типы намерений

В таблице 4 описаны пользователи и типы намерений для решения в сети предприятия.

Таблица 4. Классификация намерений для корпоративных решений.

Пользователь	Тип намерения	Описание намерения
Конечный пользователь	Обслуживание клиентов	Самообслуживание или приложения конечного пользоватля корпоративной сети. В сети могут быть разные типы конечных пользователей. Пример. Запрос доступа в VPN. Запрос видеосвязи между пользователями A и B.
	Стратегические намерения	Модели и правила намерений, созданные конечным пользователем для применения в намерениях и приложениях конечных пользователей. Пример. Создание типа видеоконференции для еженедельных совещаний.
Администратор корпоративной сети (внутренний или MSP)	Намерения для сетевой службы	Сервис, предоставляемый администраторам конечным пользователям и их приложениям. Пример. Для всех конечного пользователя приложения X нужно синхронизировать прибытие голографических объектов в интервале 50 мсек. Соединение с VPN управления для типа сервиса A. Описание операций. Работа сетевого уровня состоит в обеспечении задержки в алгоритме маршрутизации от 50 до 70 мсек. В то же время нужны сетевые ресурсы для обеспечения пропускной способности видеоконференций 4K.
	Намерения для сети	Администратор запрашивает настройку в масштабе сети (например, базовой или кампусной) или настроку ресурсов (коммутаторы, маршрутизаторы, правила). Пример. Настроить на коммутаторах кампусной сети 1 приоритизацию трафика типа A. Настроить YouTube как не имеющий отношения к бизнесу сервис.
	Задачи эксплуатации	Администратор запрашивает выполнение автомтизированной задачи, отличной от намерений для сетевой службы или сети. Пример. Запрос автоматизированных задач защиты, таких как фильтрация web и защита облака от DDoS.
	Стратегические намерения	Администратор создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач. Пример. При возникновении угрозы автоматически переместить весь трафика типа A в сеть N.
Разработчик приложений	Намерения конечного пользователя	API намерений для служб и приложений конечного пользователя, предоставляемый разработчикам приложений. Пример. API для запроса доступа к сервису VPN.
	Намерения для сетевой службы	API сетевого сервиса для разработчиков приложений. Пример. API для запроса полосы и задержки для хостинга видеоконференций.
	Намерения для сети	Сетевой API для разработчиков приложений. Пример. API для запроса настройки конфигурации сетевого устройства.
	Задачи эксплуатации	API намерений для задач эксплуатации, предоставляемый доверенным разработчикам приложение (внутренние DevOps). Пример. API для запроса автоматического мониторинга и перехвата для защиты сети.
	Стратегические намерения	Разработчик приложений создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Это предназначено для доверенных внутренних DevOps. Пример. API для стратегических намерений в случае опасности (угрозы).

6.5.2. Категории намерений

Ниже указаны предложенные категории.

Область намерения

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS

Область сети (Net)

C1=кампус, C2=филиал, C3=SD-WAN

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (see Section 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

На рисунке 5 приведено табличное представление классификации для решения в сети предприятия.

Пользователь	Тип намерений	Область намерений				Net			ABS		L-C
		C1	C2	C3	C4	C1	C2	C3	C1	C2	C1	C2
Конечный пользователь	Обслуживание клиентов
	Стратегические намерения
Администратор корпоративной сети	Намерения для сетевой службы
	Намерения для сети
	Задачи эксплуатации
	Стратегические намерения
Разработчик приложений	Намерения конечного пользователя
	Намерения для сетевой службы
	Намерения для сети
	Задачи эксплуатации
	Стратегические намерения

Рисунок 5. Категории намерений для корпоративных решений.

7. Заключение

Этот документ согласуется с целями исследовательской группы и поддерживает изучение сетей на основе намерений, предлагая методику и таксономию. Это разъясняет, что такое намерения для разных заинтересованных сторон посредством предложения подхода к классификации намерений, обеспечивающего единое понимание среди всех участников. Вместе с предложенной таксономией это обеспечивает прочную основу для будущих дискуссий, связанных с намерениями, в рамках NMRG.

Достоинства этого документа о классификации в сообществе исследователей были показаны в реализации PoC [POC-IBN], где концепции документа были применены на разных уровнях, соответствующих различным заинтересованным сторонам.

8. Вопросы безопасности

Этот документ указывает безопасность и приватность как категории области действия намерений. Намерения могут быть связаны исключительно с безопасностью или приватностью, а также могут включать безопасность и/или приватность наряду с областями связности, приложений и QoS.

Область безопасности и приватности задаёт характеристики безопасности сети, клиентов или конечных пользователей и приватности клиентов и конечных пользователей.

Более подробные сведения о намерениях защиты (безопасности) будут приведены в будущих документах, задающих архитектуру, функциональность, пользовательские намерения и модели. Анализ вопросов безопасности основанных на намерениях систем в целом приведён в разделе 9 [RFC9315].

9. Взаимодействие с IANA

Документ не требует действий IANA.

10. Литература

[Banerjee21] Banerjee, A., Mwanje, S., and G. Carle, “Contradiction Management in Intent-driven Cognitive Autonomous RAN”, September 2021.

[Bezahaf19] Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E., Broadbent, M., King, D., and D. Hutchison, “Self-Generated Intent-Based System”, 10th International Conference on Networks of the Future (NoF), DOI 10.1109/NoF47743.2019.9015045, October 2019, <https://doi.org/10.1109/NoF47743.2019.9015045>.

[Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C., and N. Race, “To All Intents and Purposes: Towards Flexible Intent Expression”, IEEE 7th International Conference on Network Softwarization (NetSoft), DOI 10.1109/NetSoft51509.2021.9492554, July 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492554>.

[Davoli21] Davoli, G., “Programmability and Management of Software-Defined Network Infrastructures”, 2021.

[IFIP-NSM] IFIP, “Network and Service Management Taxonomy”, <https://www.simpleweb.org/ifip/taxonomy.html>.

[Jacobs18] Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville, “Refining Network Intents for Self-Driving Networks”, Proceedings of the Afternoon Workshop on Self-Driving Networks (SelfDN), DOI 10.1145/3229584.3229590, August 2018, <https://doi.org/10.1145/3229584.3229590>.

[Leivadeas21] Leivadeas, A. and M. Falkner, “VNF Placement Problem: A Multi-Tenant Intent-Based Networking Approach”, 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553, March 2021, <https://doi.org/10.1109/ICIN51074.2021.9385553>.

[Mehmood21] Mehmood, K., Kralevska, K., and D. Palma, “Intent-driven Autonomous Network and Service Management in Future Networks: A Structured Literature Review”, DOI 10.48550/arXiv.2108.04560, August 2021, <https://doi.org/10.48550/arXiv.2108.04560>.

[ONF] Open Networking Foundation, “Intent NBI – Definition and Principles”, October 2016, <https://opennetworking.wpengine.com/wp-content/uploads/2014/10/TR-523_Intent_Definition_Principles.pdf>.

[ONOS] Koshibe, A., “Intent Framework”, 2016, <https://wiki.onosproject.org/display/ONOS/Intent+Framework/>.

[Padovan20] Padovan, S., “Design and Implementation of a Blockchain Intent Management System”, November 2020.

[POC-IBN] Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti, “A Multi-Level Approach to IBN”, IETF 108 Hackathon Report, July 2020, <https://www.ietf.org/proceedings/108/slides/slides-108-nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02>.

[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, “Intent-Based Networking – Concepts and Definitions”, RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/info/rfc9315>.

[Szilagyi21] Szilágyi, P., “I2BN: Intelligent Intent Based Networks”, Journal of ICT Standardization, Volume 9, Issue 2, DOI 10.13052/jicts2245-800X.926, June 2021, <https://doi.org/10.13052/jicts2245-800X.926>.

[Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C., Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C., Zheng, H., and B. Zhao, “Safely and automatically updating in-network ACL configurations with intent language”, SIGCOMM ’19: Proceedings of the ACM Special Interest Group on Data Communication, DOI 10.1145/3341302.3342088, August 2019, <https://doi.org/10.1145/3341302.3342088>.

[TMF-AUTO] Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C., Domingos, J., Troullides, Y., Mas, I., Traver, G., and G. Lupo, “Autonomous Networks: Empowering Digital Transformation For The Telecoms Industry”, May 2019.

Благодарности

Этот документ был подготовлен с учётом рецензий, предложений, комментариев и предложенного текста от указанных в алфавитном порядке людей: Mehdi Bezahaf, Brian E. Carpenter, Laurent Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff Tantsura.

Спасибо Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide Borsatti за их вклад в демонстрацию PoC «A multi-level approach to IBN» – первую попытку применить методику классификации намерений.

Участники работы

Ниже указаны люди, внесшие вклад в создание этого документа.

Написали значительную часть текста:

Xueyuan Sun

China Telecom

 

Will (Shucheng) Liu

Huawei

Написали текст ранних вариантов этого документа:

Ying Chen

China Unicom

 

John Strassner

Huawei

 

Weiping Xu

Huawei

 

Richard Meade

Huawei

Адреса авторов

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru